Disponibilità

Poiché Checkmk effettua il monitoraggio continuo di tutti gli host e i servizi a intervalli regolari, fornisce una base eccezionale per la successiva valutazione della loro disponibilità. E non solo: è anche possibile calcolare per quale percentuale di un determinato periodo di tempo un oggetto si trovava in uno o più stati specifici, con quale frequenza si è verificato tale stato, la durata del suo arresto più lungo e molto altro ancora.

Ogni calcolo si basa su una selezione di oggetti e su un determinato periodo di tempo nel passato. Checkmk ricostruisce quindi, all’interno di questo periodo di tempo, una sequenza cronologica degli stati di tutti gli oggetti selezionati. Per ogni stato, i tempi vengono sommati e visualizzati in una tabella. Questa tabella può, ad esempio, mostrare che un determinato servizio ha registrato stati del 99,95% OK e dello 0,005% WARN nel periodo di tempo definito.

Quando esegue questi calcoli, Checkmk tiene correttamente conto anche di fattori quali i tempi di manutenzione programmati, i tempi di manutenzione dei servizi, i periodi di tempo non monitorati e altri fattori speciali, consentendo il riepilogo degli stati e l'ignorare le "brevi interruzioni". Sono disponibili anche numerose opzioni di personalizzazione. È inoltre possibile l'utilizzo di aggregazioni BI.

Grazie all’inclusione dei tempi di manutenzione programmati e di stati speciali simili, in teoria esiste un gran numero di possibili combinazioni di stati, ad esempio: CRIT + In Tempo di manutenzione programmata + In Tempo di servizio + Irregolare. Poiché la maggior parte di queste combinazioni non è molto utile, Checkmk le riduce a un numero limitato e, nel farlo, procede secondo un principio di priorità. Dato che nell'esempio sopra il servizio era in un periodo di tempo di manutenzione programmata, si applica semplicemente lo stato "in scheduled downtime" e lo stato effettivo viene ignorato. Questo riduce l'elenco degli stati possibili a quanto segue:

Questo grafico mostra l'ordine in cui gli stati vengono classificati per priorità. Più avanti mostreremo come alcuni stati possano essere ignorati o combinati. Ecco di nuovo gli stati, in dettaglio:

Generare un'analisi di disponibilità è molto semplice. Per prima cosa recupera una qualsiasi visualizzazione di host, servizi o aggregazioni BI. Lì troverai nel menu "Services" o "Hosts" l'elemento "Availability", che ti porta direttamente al calcolo della disponibilità degli oggetti selezionati. I dati verranno visualizzati sotto forma di tabella:

La tabella mostra gli stessi oggetti che erano visibili nella visualizzazione precedente. In ogni colonna è indicata la percentuale del periodo di tempo richiesto in cui un oggetto si trovava nello stato oggetto della query. Il valore è espresso in percentuale, per impostazione predefinita con due cifre decimali, che puoi facilmente personalizzare.

Il periodo di tempo della query può essere personalizzato con la voce di menu "Availability > Change display options > Time Range". Ne parleremo più avanti…​

Hai la possibilità di ricevere la tabella in formato PDF (solo nelle edizioni commerciali). È anche possibile effettuare lo scaricamento dei dati in formato CSV tramite (Export as CSV). Per l'esempio sopra riportato, il risultato sarà simile a questo:

Con l'aiuto di un utente automazione, che può autenticarsi tramite l'URL, puoi anche recuperare i dati — ad esempio con wgeto curl — ed elaborarli automaticamente tramite script.

Il simbolo si trova in ogni riga della tabella. Questo pulsante ti porta a una visualizzazione della timeline per l'oggetto in questione, in cui è indicato con precisione quali cambiamenti di stato si sono verificati nel periodo di tempo specificato (qui abbreviato):

Alcuni consigli utili:

Come appena accennato, con il simbolo "" le linee temporali offrono la possibilità di aggiungere un'annotazione a un periodo di tempo. Viene fornito un modulo precompilato ("Properties") in cui è possibile inserire dei commenti:

In questo modo puoi definire ed estendere il periodo di tempo con valori diversi a seconda delle necessità. Ciò è utile, ad esempio, se desideri annotare un periodo di tempo più ampio che ha subito ripetuti cambiamenti di stato. Se ometti di inserire un servizio, l'annotazione verrà creata per l'host. Questa verrà poi automaticamente associata a tutti i servizi dell'host.

In ogni visualizzazione di disponibilità, tutte le annotazioni applicabili al periodo di tempo e agli oggetti visualizzati saranno automaticamente visibili.

Ma le annotazioni hanno una funzione aggiuntiva. I tempi di manutenzione programmata possono essere inseriti a posteriori — o, al contrario, rimossi. L'analisi della disponibilità tiene conto di queste correzioni esattamente allo stesso modo dei tempi di manutenzione programmata "normali". Ci sono almeno due valide giustificazioni per questo:

Per riclassificare i tempi di manutenzione programmata, basta selezionare la checkbox "Reclassify downtime of this period":

Nella tabella di disponibilità, accanto al simbolo della timeline, si trova un altro simbolo: . Questo ti porta a una visualizzazione della cronologia di monitoraggio con un filtro precompilato per l'oggetto rilevante e il periodo di tempo della query. Qui non vedrai solo l'evento su cui si basa l'analisi di disponibilità (i cambiamenti di stato), ma anche le notifiche associate ed eventi simili:

Ciò che qui non è visibile è lo stato dell'oggetto all'inizio del periodo di tempo della query. Il calcolo della disponibilità risale ancora più indietro nel tempo per determinare in modo affidabile lo stato iniziale.

Molte opzioni influenzano il formato delle visualizzazioni, mentre altre a loro volta influenzano i metodi di calcolo. Per cominciare, diamo un’occhiata alle visualizzazioni:

Gli stati descritti nell'introduzione possono essere personalizzati e raggruppati in moltissimi modi. In questo modo si possono generare in modo flessibile moduli di valutazione molto diversi. Ci sono varie opzioni per farlo.

A volte il monitoraggio genera spesso messaggi di errore momentanei, ma in condizioni normali l'oggetto è già OKe quando viene eseguito il check successivo (dopo un minuto) — e non è stato trovato alcun modo, tramite la regolazione delle soglie o simili, per gestire in modo pulito questi casi. Una soluzione comune è impostare il Maximum number of check attempts da 1 a 3 per consentire più errori prima che venga attivata una notifica. È stato così sviluppato il concetto di "Soft states" — ovvero gli stati WARN, CRIT o SCONOSCIUTO — purché non siano stati "esauriti" tutti i tentativi consentiti.

A volte gli utenti che usano questa funzione ci chiedono perché il modulo Availability di Checkmk non abbia una funzione per il calcolo basato esclusivamente sull'Hard states. Il motivo è semplice: c'è una soluzione migliore! Si potrebbero usare gli hard state come base…​

L'opzione "Short time Intervals" è molto più flessibile e allo stesso tempo molto semplice. Basta definire un intervallo di tempo che deve essere superato prima che gli stati vengano valutati.

Supponiamo che il valore temporale sia stato impostato su 2,5 minuti (150 secondi). Se un servizio è stato continuamente OK, poi è CRIT per 2 minuti e poi torna a OK, il breve intervallo CRIT verrà semplicemente valutato come OK! Anche la situazione opposta funziona, tra l’altro! Un breve OK all’interno di una lunga fase WARN verrà allo stesso modo valutato come WARN.

In generale, gli intervalli brevi in cui prima e dopo prevale lo stesso stato riceveranno quello stesso stato. Per una sequenza diOK , seguita da un intervallo di 2 minutiWARN , e poi daCRIT , lo statoWARN persisterà — anche se è durato meno del tempo definito!

Tieni presente, quando definisci il tempo, che in Checkmk l'intervallo di controllo standard è di un minuto. Quindi ogni stato ha una durata pari a multipli di circa un minuto. Poiché i tempi di risposta effettivi dell'agente variano leggermente, questo può facilmente essere 61 o 59 secondi. Pertanto è più sicuro non inserire minuti esatti come valore, ma includere un margine di sicurezza — da qui l'esempio con 2,5 minuti.

Una funzione importante dei calcoli di disponibilità nelle edizioni commerciali di Checkmk è che questi calcoli possono essere resi dipendenti da periodi di tempo. In questo modo è possibile definire degli orari per ogni singolo host o servizio. In questi orari ci si aspetta che l'host/servizio sia disponibile e lo stato verrà quindi utilizzato per i calcoli. Pertanto ogni oggetto ha l'attributo Service period. La procedura è la seguente:

Qui ci sono tre semplici possibilità. L' Base report only on service timespredefinito nasconde i tempi al di fuori degli orari di servizio definiti. Questi tempi nascosti non vengono quindi conteggiati nel 100%. Verranno effettivamente considerati solo i periodi di tempo compresi negli orari di servizio. Nella visualizzazione della timeline i tempi rimanenti saranno "disattivati".

Base report only on non-service times fa il contrario, e di fatto calcola la visualizzazione inversa: com'era la disponibilità al di fuori degli orari di servizio?

La terza opzione Include both service and non-service times disattiva completamente il concetto di orari di servizio e mostra i calcoli per tutti i tempi da lunedì 00:00 a domenica 24:00.

A proposito: se un host non rientra nell'orario di servizio, per Checkmk ciò non significa automaticamente che questo valga anche per i servizi presenti sull'host. I servizi richiedono sempre una propria regola in Service period for services.

Quando si calcola la disponibilità, è necessario riaprire la cronologia completa dell'oggetto selezionato. Come funziona nel dettaglio lo scoprirai più avanti. Soprattutto in una Comunità Checkmk , l'analisi può richiedere un po' di tempo, poiché il suo core non dispone di una cache per i dati richiesti e i dati di log testuali devono essere cercati in modo sequenziale.

Affinché una query eccessivamente complessa — che potrebbe essere stata avviata involontariamente — non blocchi un processo Apache, consumi CPU e quindi “si blocchi”, ci sono due opzioni per limitare la durata del calcolo. Entrambe sono attivate di default:

L'opzione "Query time limit" limita la durata della query sottostante al nucleo di monitoraggio a un tempo specificato. Questo è predefinito a trenta secondi. Se questo tempo viene superato, l'analisi verrà interrotta e verrà segnalato un errore. Se sei sicuro che l'analisi possa essere eseguita più a lungo, basta aumentare manualmente il timeout.

L'opzione "Limit processed data" protegge dai calcoli con molti oggetti. Qui verrà applicato un limite che funziona in modo analogo a quello nelle visualizzazioni. Se la query al nucleo di monitoraggio produrrà più di 5000 periodi di tempo, il calcolo verrà interrotto con un avviso. La limitazione sarà stata pre-elaborata nel core — dove i dati vengono raccolti.

Una potente funzionalità del calcolo della disponibilità di Checkmk è la possibilità di calcolare la disponibilità dalle aggregazioni BI. Il grande vantaggio è che, a questo scopo, Checkmk ricostruisce retroattivamente lo stato preciso dei rispettivi aggregati in un determinato momento utilizzando i protocolli degli stati degli host e dei servizi.

Perché tanto tempo e tanta fatica? Perché non interrogare semplicemente l'aggregazione BI con un active check e poi mostrare la sua disponibilità? Beh, questo sforzo offre un bel po' di vantaggi per l'utente:

Il recupero della visualizzazione di disponibilità è inizialmente analogo a quello per gli host e i servizi. Seleziona una visualizzazione con una o più aggregazioni BI e seleziona l'elemento di menu "BI Aggregations > Availability". Qui c'è anche un secondo metodo: ogni aggregazione BI ha un percorso diretto alla sua disponibilità utilizzando il simbolo "":

Di per sé il calcolo è inizialmente simile a quello dei servizi, ma senza le colonne "Host down" e "flapping", poiché questi stati non esistono per la BI:

La grande differenza sta nella visualizzazione della linea temporale "". L'esempio seguente mostra un aggregato nel nostro server demo, che è stato "CRIT" per un brevissimo intervallo di tempo di un secondo (questo sarebbe un ottimo esempio per l' uso dell'opzione "Short time intervals").

Vuoi sapere qual è stata la causa dell'interruzione? Basta un semplice clic sulla bacchetta magica. Questo ti permette di fare un viaggio nel tempo fino al momento esatto in cui si è verificata l'interruzione, e apre una visualizzazione dell'aggregazione BI in quel momento — nell'immagine seguente, già aperta nella posizione corretta:

Per calcolare la disponibilità, Checkmk accede alla cronologia storica di monitoraggio archiviata e, per farlo, si basa sui cambiamenti di stato. Se, ad esempio, alle 17:14 del 20/10/2021 un servizio cambia il proprio stato in CRIT , e poi alle 17:24 torna a OK , allora sai che durante questo periodo di tempo di 10 minuti il servizio era in uno stato CRIT.

Questi cambiamenti di stato vengono registrati nel log di monitoraggio, hanno il tipo di avviso HOST ALERTo SERVICE ALERT e si presentano ad esempio in questo modo:

C'è sempre un file di log attuale che include le voci relative alle attività più recenti fino al momento presente, oltre a una directory con un archivio dei periodi precedenti. La posizione di questi file varia a seconda del nucleo di monitoraggio in uso:

L'interfaccia utente non accede direttamente a questi file, ma li interroga tramite una query Livestatus emessa dal nucleo di monitoraggio. Tra le altre cose, questo è importante perché in un monitoraggio distribuito i file di cronologia non vengono memorizzati sullo stesso sistema della GUI.

La query Livestatus utilizza la tabella statehist. A differenza della tabella log – che fornisce un accesso "nudo" alla cronologia – qui viene utilizzata la tabella statehist perché ha già eseguito le fasi iniziali di calcolo che richiedono molto tempo. Tra le altre cose, si occupa di controllare la cronologia per determinare lo stato iniziale e di calcolare i periodi di tempo con lo stesso stato, con le loro date di inizio, durata e fine.

La procedura di condensazione degli stati viene eseguita nella panoramica utente dal Modulo di Disponibilità, come descritto all’inizio di questo articolo.