Disponibilità

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

Ogni calcolo si basa su una selezione di oggetti e su un determinatoperiodo di tempo nel passato. Checkmk ricostruisce quindi, all'interno di questo intervallo 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 particolare servizio ha sperimentato stati del 99,95% OK e dello 0,005% WARN nel periodo di tempo definito.

Nell'effettuare questi calcoli, Checkmk tiene conto correttamente anche di fattori come i tempi di manutenzione programmata, i tempi di inattività del servizio, i periodi di tempo non monitorati e altri fattori speciali, permette di riassumere gli stati e di ignorare le "brevi interruzioni". Sono inoltre disponibili numerose opzioni di personalizzazione e la possibilità di effettuare aggregazioni BI.

Grazie all'inclusione dei tempi di manutenzione programmata e di altri stati speciali simili, esiste in teoria un gran numero di combinazioni possibili di stati, ad esempio: Poiché la maggior parte di queste combinazioni non sono molto utili, Checkmk le riduce a un numero ridotto e procede secondo un principio di priorità. Poiché nell'esempio precedente il servizio si trovava in un tempo di manutenzione programmata, si applica semplicemente lo stato in scheduled downtime e lo stato attuale viene ignorato. Questo riduce l'elenco dei possibili stati ai seguenti:

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

Generare un'analisi della disponibilità è molto semplice. Per prima cosa recupera una qualsiasivisualizzazione di host, servizi o aggregazioni BI. Troverai nel menu Services o Hosts la voce di menu Availability, che ti porterà direttamente al calcolo della disponibilità degli oggetti selezionati. I dati verranno visualizzati sotto forma di tabella:

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

L'interrogazione del periodo di tempo può essere personalizzata con la voce di menu Availability > Change display options > Time Range Più avanti...

Hai la possibilità di ricevere la tabella in formato PDF (solo per le edizioni commerciali). È anche possibile scaricare i dati in formato CSV (Export as CSV). L'aspetto sarà il seguente per l'esempio precedente:

Con l'aiuto di un utente automazione, che può autenticare se stesso tramite l'URL, puoi anche recuperare i dati - ad es. conwget o curl) - e processare automaticamente i dati sotto il controllo di script.

Questo pulsante, che si trova in ogni riga della tabella, ti porta alla visualizzazione della timeline dell'oggetto in questione, in cui sono indicati con precisione gli elementi che si sono verificati nel periodo di tempo specificato (qui abbreviato):

Alcuni suggerimenti 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 ("Proprietà") in cui è possibile inserire dei commenti:

In questo modo puoi definire ed estendere il periodo di tempo con valori diversi a seconda delle esigenze. Questo è pratico, ad esempio, se desideri annotare un intervallo di tempo più ampio che ha subito ripetuti cambiamenti di stato. Se non inserisci un servizio, l'annotazione verrà creata per l'host e sarà automaticamente collegata a tutti i servizi dell'host.

In ogni visualizzazione della 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 inattività possono essere inseriti a posteriori o, al contrario, rimossi. L'analisi della disponibilità tiene conto di queste correzioni esattamente come avviene per i tempi di manutenzione programmata "normali". Ci sono almeno due giustificazioni legittime per questo:

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

Nella tabella della disponibilità, accanto al simbolo della linea temporale si trova un altro simbolo: . Questo ti porta a unavisualizzazione della cronologia dell'oggetto con un filtro precompilato per l'oggetto in questione e il periodo di tempo per la query. Qui potrai vedere non solo l'evento su cui si basa l'analisi della disponibilità (i cambiamenti di stato), ma anche le notifiche associate e gli eventi simili:

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

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

Gli stati descritti nell'introduzione possono essere personalizzati e condensati in molti modi. In questo modo è possibile generare in modo flessibile moduli di valutazione molto diversi tra loro. Esistono varie opzioni per questo scopo.

A volte i monitoraggi producono messaggi di problemi momentanei, ma in condizioni normali l'oggetto è già OK nel momento in cui viene eseguito il controllo successivo (dopo un minuto) - e non è stato trovato un modo, attraverso la regolazione di threshold o simili, per risolvere questi casi. Una soluzione comune è quella di impostare il parametroMaximum number of check attempts da 1 a 3 per consentire un numero maggiore di guasti prima che venga attivata una notifica. È stato quindi sviluppato il concetto di Soft states, ovvero gli stati WARN, CRIT oSCONOSCIUTO, a condizione che non siano stati "esauriti" tutti i tentativi consentiti.

Di tanto in tanto gli utenti che utilizzano questa funzione ci chiedono perché il modulo di disponibilità di Checkmk non ha una funzione per calcolare solo Hard states. Il motivo è che esiste una soluzione migliore! Esiste una soluzione migliore: si potrebbero utilizzare gli hard state come base...

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

Supponiamo che il valore di tempo sia stato impostato a 2,5 minuti (150 secondi). Se un servizio è stato continuamente OK, poi è stato CRIT per 2 minuti e poi è tornato ad essere OK, il breve intervallo di tempo CRIT sarà semplicemente valutato come OK! Tra l'altro, funziona anche la situazione opposta! Un breve OK all'interno di una lungafase WARN verrà valutato come WARN.

In generale, brevi intervalli di tempo in cui prima e dopo prevale lo stesso stato riceveranno lo stesso stato. Per una sequenza di OK, poi un WARN di 2 minuti, seguito da CRIT, il WARNpersisterà, anche se la sua durata è inferiore a quella definita!

Quando definisci il tempo, tieni presente che in Checkmk l'intervallo di tempo standard è di un minuto. Quindi ogni stato ha una durata multipla dicirca un minuto. Poiché i tempi di risposta effettivi dell'agente variano leggermente, è facile che si tratti di 61 o 59 secondi. Per questo motivo è meglio non inserire i minuti esatti per il valore, ma piuttosto includere un buffer: ecco l'esempio con 2,5 minuti.

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

In questo caso ci sono tre semplici possibilità. L'opzione predefinitaBase report only on service times nasconde gli orari al di fuori degli orari di servizio definiti. Questi tempi nascosti non vengono conteggiati per raggiungere il 100 %. Solo i periodi di tempo all'interno dei tempi di servizio saranno effettivamente considerati. Nella visualizzazione della timeline i tempi rimanenti saranno "grigi".

Base report only on non-service times esegue il contrario e calcola la visualizzazione inversa: Quanto è stata buona la disponibilitàal di fuori degli orari di servizio?

La terza opzione Include both service and non-service times disattiva il concetto completo di orari di servizio e mostra i calcoli per tutti gli orari che vanno dalle 00:00 del lunedì alle 24:00 della domenica.

A proposito: Se un host non rientra nell'orario di servizio, per Checkmk nonsignifica automaticamente che questo vale anche per i servizi dell'host. I servizi richiedono sempre una regola propria in Service period for services.

Quando si calcola la disponibilità, è necessario riaprire la cronologia completa dell'oggetto selezionato. Per sapere come funziona in dettaglio, leggipiù avanti. Soprattutto in Checkmk Raw, l'analisi può richiedere un po' di tempo, poiché il suo core non ha una cache per i dati richiesti e i dati di log basati sul testo devono essere cercati in sequenza.

Affinché una query eccessivamente complessa, che potrebbe essere stata avviata involontariamente, non blocchi un processo Apache, non consumi CPU e quindi non si "blocchi", esistono due opzioni per limitare la durata del calcolo. Entrambe sono attivate per impostazione predefinita:

Query time limit limita la durata della query sottostante al nucleo di monitoraggio a un tempo specifico. Se questo tempo viene superato, l'analisi verrà interrotta e verrà evidenziato un errore. Se sei sicuro che l'analisi possa essere eseguita più a lungo, aumenta il timeout manualmente.

L'opzione Limit processed data protegge dai calcoli con molti oggetti. In questo caso verrà applicato un limite analogo a quello dellevisualizzazioni. 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-processata nel nucleo, dove vengono raccolti i dati.

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

Perché tanto tempo e fatica? Perché non basta interrogare l'aggregazione BI con un Check attivo e mostrarne la disponibilità? Questo sforzo comporta una serie di vantaggi per l'utente:

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

Il calcolo è inizialmente analogo 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 CRITper un brevissimo intervallo di tempo di un secondo (questo sarebbe un buon 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 permette di viaggiare 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 agli archivi dei log della cronologia di monitoraggio e per farlo si orienta sui cambiamenti di stato. Se, ad esempio, alle 17:14 del 20/10/2021 un servizio cambia il suo stato in CRIT e poi alle 17:24 torna a OK, allora saprai che in questo periodo di tempo di 10 minuti il servizio era in stato CRIT.

Questi cambiamenti di stato vengono registrati nel log di monitoraggio, hanno il tipo di avvisoHOST ALERT o SERVICE ALERT e hanno un aspetto simile a questo, ad esempio:

Esiste sempre un file di log corrente che include le voci relative all'attività più recente fino al momento attuale, 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 utilizzando una query Livestatus emessa dal nucleo di monitoraggio. Tra gli altri fattori, questo è importante perché in unmonitoraggio distribuito i file di cronologia non sono memorizzati sullo stesso sistema del GUI.

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

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