Quale dovrebbe essere lo scopo di un controllo dello stato di un sistema che distribuisce una webapp?

This is hard to implement because of the definition of what is healthy

Hai risposto alla tua domanda qui. La definizione di un controllo sanitario sta per variare, perché ciò che è sano varia. Dipende anche da cosa sta emettendo lo healthcheck.

Una buona domanda da porsi è, "dal punto di vista del richiedente, il servizio controllato funziona come previsto?" Se sei tu, puoi definirlo. Se si tratta di un altro team / servizio, è necessario identificare lo standard / le specifiche per i controlli di sicurezza.

Probabilmente in una grande organizzazione, avrai una sorta di standard per ciò che un healthcheck dovrebbe fare. Scoprilo.

In particolare qui, il tuo esempio webapp significa che non dovrebbe tornare sano perché la webapp non è salutare. Ma forse la tua definizione di "sano" includerebbe questo come "ok". Questo è parte della discussione sui requisiti di cui sopra (anche in questo caso, è solo il tuo codice).

La mia raccomandazione supponendo che non sia specificata altrove sarebbe quella di avere un qualche tipo di codice di stato associato a diversi errori. Quando si esegue una query sulla webapp, è possibile che venga restituito un errore indicante che "il servizio dipendente è morto" e quindi il client (o qualsiasi altra cosa sta eseguendo lo healthcheck) può conoscere il motivo il client è morto.

Per le domande modificate:

Is it good enough to consider the service healthy if the orchestration system reports that the task is running?

No, solo perché un processo è in esecuzione non significa che non è bloccato, totalmente non funzionante, o una grande varietà di altre possibilità.

Or should we manually ping each service?

Potrebbe funzionare, a seconda dell'ambito della funzionalità dell'applicazione. Se la verifica del servizio risponde a un "sei vivo?" ping allora questo potrebbe essere tutto ciò che è richiesto. Ma se il servizio potrebbe facilmente essere "vivo e reattivo ma non funzionante" allora forse è necessario controllare anche altre cose.

Or should it go further and attempt to ensure that the web-app does what it is supposed to do, like show a web page?

Il tuo healthcheck deve garantire che la funzionalità richiesta prevista funzioni come previsto.

Se la tua app restituisce "sano" e non può fare ciò che deve fare, puoi anche eliminare l'intero healthcheck in quanto fornirà falsi positivi (per non parlare di confondere diamine di persone che cercano di eseguire il debug del problema - "hey il nostro server web mostra salutare, perché non possiamo vedere la pagina?").

Does the healthcheck also have to check that some dependent services are also running? Like a database or the orchestration system itself. Or is that the responsibility of another health check?

Questo dipende in qualche modo. Se il tuo servizio dipende da un altro servizio, la natura di tale interazione dovrebbe riflettersi nelle chiamate API / di rete inviate nella tua app e incorporate nello healthcheck.

Ad esempio, la lettura di un server web da un database deve avere informazioni sullo stato del database incorporato, oppure l'applicazione web si bloccherà semplicemente se le chiamate API falliscono. Puoi banalmente modificare queste chiamate da incorporare nel tuo healthcheck.

Tuttavia, se il tuo servizio sta inviando eventi ai consumatori che ascoltano, senza alcuna convalida, allora è meno importante per la funzionalità della tua app che i consumatori sono vivi. "Sano" per la tua app sta inviando i messaggi, in realtà non li sta ricevendo.

Fondamentalmente, se il tuo servizio ha bisogno di parlare con altri servizi e verificare la loro salute in ogni caso, ha senso avere almeno un livello base di controllo per lo stato di salute del tuo servizio. Questo dovrebbe avere un senso concettualmente dato quello che ho appena detto, poiché la tua applicazione lo gestirà già (o casualmente in modo anomalo, suppongo).

And last of all, if one of the dependent services are dead, and the web-app subsequently fails, should the web-app report a bad health, or is it good health, because it is not the web-apps fault?

Questo è fondamentalmente la risposta sopra. La mia raccomandazione sarebbe di avere il vostro healthcheck per restituire un codice / messaggio / qualunque cosa dia queste informazioni. Entrambe le informazioni sono importanti: il servizio dipendente di cui il tuo servizio ha bisogno è e che il tuo servizio non funzionerà come previsto.

Generalmente un controllo sanitario significa semplicemente "è vivo e sta rispondendo". Ulteriori controlli rispetto a quelli sono altamente specializzati e dipendono interamente dall'uso del sistema. Che tu faccia il miglio supplementare per verificare che un sistema stia elaborando le richieste correttamente dipende da te, ma prima devi fare le basi - controlla che sia lì, controlla che possa ricevere richieste e che restituisca una risposta.

Il modo più semplice per implementare un controllo dello stato è semplicemente scrivere un comando che il servizio elabora utilizzando lo stesso meccanismo utilizzato da altri comandi, che non fa altro che restituire un riconoscimento. Questo mostrerà live-ness, e che il sistema sta ricevendo ed elaborando le risposte.

Il controllo dei sistemi dipendenti non fa parte del controllo di integrità, è necessario mantenerlo semplice e autonomo. Aggiungi a turno un controllo sanitario a ciascun servizio dipendente. In questo modo puoi ottenere un elenco di sistemi sani e funzionanti e capire facilmente quando uno va male, quale è!

Nella mia esperienza, i servizi critici tendono ad avere le seguenti caratteristiche:

Heartbeat

Se il servizio viene eseguito su base regolare, questo semplicemente scrive una riga in un file di registro o simile insieme a un timestamp per indicare che il corpo del servizio ha dato il via a un dato momento.

Pangrattato

Come in precedenza, i breadcrumb di solito sono solo un dump del nome del metodo (e occasionalmente dei parametri) per mostrare che il servizio sta elaborando il corpo del servizio come previsto e dove si trova nel flusso. Dal momento che questi possono generare più output, questi sono comunemente controllati dai file di configurazione o simili in modo che possano essere disattivati una volta che il servizio è stato inserito.

Può essere allettante aggiungere molte altre cose come lo stato di vari server, servizi e database e simili. Anche se questo è senza dubbio prezioso, consiglierei di scrivere qualcosa di troppo esteso. Questi potrebbero essere utili per la tua tranquillità, ma tali salvaguardie tendono a subire abusi una volta che le parti responsabili dei vari punti di contatto sanno che sono lì. Prima che tu te ne accorga, potresti scrivere un'app di diagnostica per l'intera azienda.