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


13

Oggi ho avuto il compito di "scrivere un controllo sanitario" per un servizio di lunga durata che è un sistema di orchestrazione per distribuire un'app Web.

Sto cercando di determinare quale sarebbe la portata di tale controllo sanitario e ho formulato queste domande relative all'ambito del controllo sanitario:

  1. È sufficiente considerare sano il servizio se il sistema di orchestrazione segnala che l'attività è in esecuzione?
  2. O dovremmo eseguire manualmente il ping di ciascun servizio?
  3. O dovrebbe andare oltre e cercare di garantire che l'app Web faccia quello che dovrebbe fare, come mostrare una pagina web?
  4. Healthcheck deve anche verificare che anche alcuni servizi dipendenti siano in esecuzione? Come un database o il sistema di orchestrazione stesso. O è la responsabilità di un altro controllo sanitario?
  5. E, infine, se uno dei servizi dipendenti è morto e successivamente l'app Web non riesce, l'app Web dovrebbe riportare una cattiva salute o è buona salute, perché non è colpa delle app web?

So che si tratta di 5 domande separate, ma tutte riguardano l'ambito di un controllo dello stato di un servizio di lunga durata che distribuisce un'app Web, quindi ho pensato che avrebbe più senso tenerli raggruppati in un'unica domanda.

Questo è difficile da attuare per me perché non sono sicuro della definizione di ciò che è salutare o di come dovrebbe essere un controllo sanitario standard per qualcosa del genere.

Cosa dovrebbe contenere un controllo dello stato di questo servizio specifico?


2
Non fidarti mai dei rapporti di stato automatizzati. Controlla sempre tu stesso lo stato. Curiosità: una delle cause dell'incidente di Tree Mile Island è stata un indicatore di "valvola chiusa" che indicava solo che era stato emesso il comando "Chiudi valvola" , non che la valvola era effettivamente chiusa .
Kilian Foth,

@KilianFoth: su una nota simile: conosco un'azienda che ha testato religiosamente e accuratamente che i loro backup funzionavano. Poi, un giorno, hanno avuto un catastrofico errore del disco e lo hanno scoperto: il loro ripristino no.
Jörg W Mittag,

7
Sto pensando che sia il lavoro della persona che ti ha chiesto di "scrivere un controllo sanitario" per definire cosa significano per "salute". Altrimenti, sono solo congetture.
Jörg W Mittag,

1
Sono d'accordo con il commento di @ JörgWMittag, ma farei anche un passo avanti. Dovresti ottenere i tuoi requisiti non solo dalla persona che ti ha detto che devi progettare un "controllo dello stato", ma anche capire chi sono le persone o i sistemi che usano i dati che fanno parte di un controllo dello stato e capire cosa bisogno o come ne hanno bisogno. Questi sono i tuoi requisiti che guideranno il tuo design.
Thomas Owens

1
L'ho chiarito leggermente e ho votato per riaprire, poiché penso che la domanda principale sia in tema. Comprendere come identificare cosa dovrebbe essere incluso in un controllo di salute è una cosa del tutto normale per la progettazione del software, anche se la vera risposta è "chiedere requisiti" (o una variazione al riguardo).
Enderland

Risposte:


15

Questo è difficile da attuare a causa della definizione di ciò che è salutare

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

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

Probabilmente in una grande organizzazione, avrai una sorta di standard per ciò che dovrebbe fare un controllo sanitario. Trova una soluzione.

Nello specifico qui, l'esempio della tua webapp significa che non dovrebbe tornare sano perché la webapp non è sana. Ma forse la tua definizione di "sano" includerebbe questo come "ok". Questo fa parte della discussione sui requisiti sopra (di nuovo, anche se è solo il tuo codice).

La mia raccomandazione, supponendo che non sia specificata altrove, sarebbe quella di avere una sorta di codice di stato associato a diversi errori. Quando si interroga la webapp, potrebbe restituire un errore che dice "il servizio dipendente è morto" e quindi il client (o qualunque cosa stia eseguendo il controllo di salute) può sapere il motivo per cui il client è morto.

Per le domande modificate:

È sufficiente considerare sano il servizio se il sistema di orchestrazione segnala che l'attività è in esecuzione?

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

O dovremmo eseguire manualmente il ping di ciascun servizio?

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

O dovrebbe andare oltre e cercare di garantire che l'app Web faccia quello che dovrebbe fare, come mostrare una pagina web?

Il controllo sanitario deve garantire che la funzionalità richiesta prevista funzioni come previsto.

Se la tua app torna "sana" e non può fare ciò che deve fare, potresti anche sbarazzarti dell'intero controllo di salute in quanto fornirà falsi positivi (per non parlare di confondere il diavolo delle persone che cercano di eseguire il debug del problema - 'hey il nostro server web mostra sano, perché non possiamo vedere la pagina? ').

Healthcheck deve anche verificare che anche alcuni servizi dipendenti siano in esecuzione? Come un database o il sistema di orchestrazione stesso. O è la responsabilità di un altro controllo sanitario?

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

Ad esempio, un server web che legge da un database deve disporre di informazioni sullo stato del database in esso incorporato o l'app Web si arresterà in modo anomalo se le chiamate API non riescono. È possibile modificare banalmente queste chiamate per essere incorporate nel controllo della salute.

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

Fondamentalmente, se il tuo servizio deve parlare con altri servizi e verificarne comunque lo stato, ha senso almeno un livello base di controllo in questo per il controllo dello stato del tuo servizio. Ciò dovrebbe avere senso concettualmente, dato quello che ho appena detto, poiché l'applicazione lo gestirà già (o arresta in modo casuale, immagino).

E, infine, se uno dei servizi dipendenti è morto e successivamente l'app Web non riesce, l'app Web dovrebbe riportare una cattiva salute o è buona salute, perché non è colpa delle app web?

Questa è sostanzialmente una risposta sopra. La mia raccomandazione sarebbe di fare in modo che il tuo healthcheck restituisca un codice / messaggio / qualunque cosa fornisca queste informazioni. Entrambe le informazioni sono importanti: che il servizio dipendente di cui il tuo servizio ha bisogno è morto e che il tuo servizio non funzionerà come previsto di conseguenza.


2

Generalmente un controllo sanitario significa semplicemente "è vivo e risponde". Ulteriori controlli sono altamente specializzati e dipendono interamente dall'uso del sistema. Che tu faccia il possibile per verificare che un sistema stia elaborando correttamente le richieste dipende da te, ma dovresti prima fare le basi: controlla che sia lì, controlla che possa ricevere richieste e restituirà 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. Ciò mostrerà vivacità e che il sistema sta ricevendo ed elaborando le risposte.

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


Nel sistema che sto scrivendo, eseguo semplicemente una query su ciascun servizio dipendente per le informazioni sulla sua versione. Se risponde in modo tempestivo (2500ms nel mio caso), viene considerato "attivo". Li interrogo tutti in parallelo, quindi il mio tempo di risposta nel caso peggiore è limitato.
TMN

1

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

Battito cardiaco

Se il servizio viene eseguito su base regolare, questo scrive solo una riga in un file di registro o simile insieme a un timestamp per indicare che il corpo del servizio è entrato in un determinato momento.

Briciole di pane

Analogamente a quanto sopra, il pangrattato di solito è 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 da file di configurazione o simili, quindi possono essere disattivati ​​una volta inserito il servizio.


Può essere allettante aggiungere molte altre cose come lo stato di vari server, servizi, database e simili. Anche se questo è senza dubbio prezioso, sconsiglio di scrivere qualcosa di troppo ampio. Questi potrebbero essere utili per la tua tranquillità, ma tali garanzie tendono ad essere abusate quando le parti responsabili dei vari punti di contatto sanno che sono lì. Prima di conoscerlo, potresti scrivere un'app di diagnostica per l'intera azienda.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.