Principi di base del monitoraggio con Checkmk

In Checkmk tutto ruota attorno agli host e ai servizi. Un host può essere molte cose, ad esempio:

Nel monitoraggio, un host ha sempre uno dei seguenti stati:

Oltre allo stato, un host ha una serie di altri attributi che possono essere configurati dall'utente, ad esempio:

Affinché il monitoraggio possa determinare lo stato dell'UNREACH, deve sapere quale percorso può utilizzare per contattare ogni singolo host. A questo scopo, per ogni host è possibile specificare uno o più cosiddetti host genitori. Ad esempio, se un server A, dal punto di vista del monitoraggio, è raggiungibile solo tramite un router B, allora B è un host padre di A. In Checkmk vengono configurati solo i genitori diretti. Questo porta a una struttura ad albero con l'istanza Checkmk al centro (qui mostrato come ):

Supponiamo che nell'esempio di topologia di rete mostrato sopra, gli host myhost e myhost4 non siano più raggiungibili. Il guasto di myhost4 può essere spiegato dal fatto che myhost ha smesso di funzionare. Pertanto, myhost4 viene classificato come "UNREACH" nel monitoraggio. Semplicemente non è possibile determinare chiaramente perché Checkmk non riesca più a raggiungere myhost4, e lo stato "DOWN" sarebbe quindi fuorviante in alcune circostanze. Invece, l'UNREACHe ha l'effetto di sopprimere le notifiche per impostazione predefinita. Questo è dopotutto il compito più importante del concetto di "parents", ovvero evitare notifiche di massa nel caso in cui un intero segmento di rete dipendente diventi non raggiungibile per il monitoraggio a causa di un'interruzione in un singolo punto.

La prevenzione dei falsi allarmi è garantita anche da una funzionalità del Checkmk Micro Core (CMC) utilizzato nelle edizioni commerciali. In questo caso, il cambio di stato per un host in errore viene trattenuto per qualche istante e procede solo quando è certo che il genitore sia ancora raggiungibile. Se, invece, il genitore è definitivamente DOWN, l’host passerà a UNREACH — senza che venga attivata alcuna notifica.

In alcuni casi un host potrebbe avere più host genitori, ad esempio quando un router è in esecuzione in modalità ad alta disponibilità in un cluster. È sufficiente che Checkmk sia in grado di determinare in modo univoco lo stato dell’host quando una di queste host genitori è raggiungibile. Pertanto, quando un host ha più host genitori e almeno una di queste è UP, l’host viene considerato raggiungibile nel monitoraggio. In altre parole, in una situazione del genere, l’host non passerà automaticamente allo stato UNREACH.

Un host dispone di una serie di servizi. Un servizio può essere qualsiasi cosa — non confonderlo con i servizi di Windows. Un servizio è qualsiasi parte o aspetto dell'host che può essere OK o non OK. Naturalmente lo stato può essere determinato solo se l'host si trova nello stato UP.

Un servizio sottoposto a monitoraggio può avere i seguenti stati:

Per stabilire quale condizione sia "peggiore", Checkmk utilizza la seguente sequenza:

OK → WARN → SCONOSCIUTO → CRIT

Un check garantisce che a un host o a un servizio possa essere assegnato uno stato. Quali stati possano essere è descritto nella sezione precedente. I servizi e i controlli sono strettamente correlati. Per questo motivo questi termini sono talvolta usati in modo intercambiabile, forse anche in questo manuale, sebbene siano in realtà cose diverse.

Nella configurazione puoi visualizzare quale plug-in di controllo è responsabile di ciascun servizio. Apri le proprietà di un host con "Setup > Hosts" e poi, nel menu "Host > Run service discovery", l'elenco dei servizi per questo host. Quindi usa "Display > Show plugin names" per visualizzare una nuova colonna che mostrerà il plug-in di controllo responsabile di ciascun servizio:

Come puoi vedere dall'esempio del plug-in di controllo df, un plug-in di controllo può essere responsabile di più di un servizio. A proposito, i nomi dei plug-in di controllo elencati nella colonna sono anche link che mostrano una descrizione del plug-in di controllo.

La connessione e la dipendenza tra servizi e controlli sono visibili anche nel monitoraggio. Nell'elenco dei servizi per un host nel monitoraggio, puoi notare che nel menu azione di , alla voce "Reschedule", per alcuni servizi è presente una freccia gialla (), mentre per la maggior parte degli altri è presente una freccia grigia (). Un servizio con la freccia gialla si basa su un active check:

Tale active check viene eseguito direttamente da Checkmk. I servizi con la freccia grigia si basano su controlli passivi i cui dati vengono recuperati da un altro servizio, il servizio Check_MK. Questo viene fatto per motivi di performance ed è una caratteristica speciale di Checkmk.

Checkmk identifica come problema ogni host che non è UP e ogni servizio che non è OK. Un problema può avere due stati: non gestito e gestito. La procedura prevede che un nuovo problema venga inizialmente trattato come non gestito. Non appena qualcuno conferma il problema, questo verrà contrassegnato come gestito; ovviamente, i problemi non gestiti sono quelli a cui non è stata ancora prestata attenzione. La panoramica nella barra laterale distingue quindi questi due tipi di problemi:

A proposito: i problemi di servizio provenienti da host che al momento non sono UP non vengono identificati come problemi.

Maggiori dettagli sui riconoscimenti sono disponibili in un articolo dedicato.

Quando lo stato dell'host cambia (ad esempio da "OK" a "CRIT"), Checkmk registra un evento di monitoraggio. Questi eventi possono generare o meno una notifica. Checkmk è progettato in modo tale che ogni volta che un host o un servizio presenta un problema, venga inviata un'e-mail ai contatti dell'oggetto (tieni presente che ogni utente appena creato, per impostazione predefinita, non è un contatto per nessun oggetto). Tuttavia, queste impostazioni possono essere personalizzate in modo molto flessibile. Le notifiche dipendono anche da una serie di parametri. È più semplice esaminare i casi in cui le notifiche non vengono inviate. Le notifiche vengono soppresse …​

Se nessuno di questi prerequisiti per la soppressione delle notifiche è soddisfatto, il nucleo di monitoraggio crea una notifica, che in un secondo passo passa attraverso una catena di regole. In queste regole puoi definire ulteriori criteri di esclusione e decidere chi deve essere avvisato e in che forma (e-mail, SMS, ecc.)

Tutti i dettagli relativi alle notifiche sono disponibili nell'articolo dedicato alle Notifiche.

A volte capita che un servizio cambi continuamente e rapidamente la propria condizione. Per evitare notifiche continue, Checkmk mette tale servizio nello stato irregolare. Questo è indicato dal simbolo "".

Quando un servizio entra in stato irregolare, viene generata una notifica che informa l'utente della situazione e silenzia le ulteriori notifiche. Dopo un tempo adeguato, se non si verificano ulteriori cambiamenti rapidi ed è evidente uno stato finale (buono o cattivo), lo stato irregolare scompare e riprendono le normali notifiche.

Se esegui lavori di manutenzione su un server, un dispositivo o del software, normalmente vorrai evitare notifiche di problemi durante questo periodo. Inoltre, probabilmente vorrai avvisare i tuoi colleghi che i problemi che compaiono nel monitoraggio durante questo periodo possono essere temporaneamente ignorati.

A questo scopo puoi inserire una condizione di tempo di manutenzione programmata su un host o un servizio. Questo può essere fatto direttamente prima di iniziare il lavoro o in anticipo. Il tempo di manutenzione programmata è indicato dai simboli:

Mentre un host o un servizio è in fase di tempo di manutenzione programmata:

Inoltre, se in seguito desideri documentare le statistiche sulla disponibilità di host e servizi è consigliabile includere i tempi di manutenzione programmati. Questi possono essere presi in considerazione nelle successive valutazioni di disponibilità.

Se lavori con Checkmk da un po', è possibile che nelle tue visualizzazioni di host e servizi vengano visualizzate delle ragnatele. Per i servizi, ad esempio, appare così:

Queste ragnatele simboleggiano lo stato in stallo. Ogni volta che c'è un host o un servizio in stallo, questo verrà mostrato anche nello snap-in "Overview", che verrà esteso dalla colonna "Stale".

Ma cosa significa esattamente lo stato "stale"? In generale, un host o un servizio viene contrassegnato come "stale" quando Checkmk non riceve più informazioni aggiornate sul suo stato per un periodo di tempo prolungato:

Puoi regolare il limite di tempo dopo il quale gli host e i servizi diventano obsoleti. A tal fine, leggi la sezione sugli intervalli di tempo.

Puoi limitare gli intervalli di tempo in cui vengono eseguiti i controlli. A questo scopo servono i set di regole Check period for hosts, Check period for active services e Check period for passive Checkmk services. Usa queste regole per selezionare uno degli intervalli di tempo disponibili come periodo di check.

I controlli vengono eseguiti a intervalli fissi nell'ambito del monitoraggio basato sullo stato. Checkmk utilizza un intervallo predefinito di un minuto per i controlli dei servizi e di 6 secondi per i controlli degli host con Smart Ping.

Questi valori predefiniti possono essere sovrascritti utilizzando i set di regole Normal check interval for service checks e Normal check interval for host checks:

Se ora combini un periodo di check con un intervallo di controllo, puoi assicurarti che un active check venga eseguito esattamente una volta al giorno in un momento molto specifico. Ad esempio, se imposti l'intervallo di controllo a 24 ore e il periodo di check dalle 2:00 alle 2:01 ogni giorno (cioè solo un minuto al giorno), Checkmk farà in modo che il controllo venga effettivamente spostato in questa breve finestra temporale.

Lo stato dei servizi non verrà più aggiornato al di fuori di questo periodo di check definito e i servizi verranno contrassegnati come obsoleti con il simbolo . Con l'impostazione globale Staleness value to mark hosts / services stale puoi definire quanto tempo deve trascorrere prima che un host/servizio diventi obsoleto. Questa impostazione si trova in Setup > General > Global settings > User interface:

Questo fattore rappresenta n volte l'intervallo di controllo. Quindi, se il tuo intervallo di controllo è impostato su un minuto (60 secondi), un servizio per il quale non ci sono nuovi risultati di controllo verrà messo in stallo dopo 1,5 volte il tempo, ovvero dopo 90 secondi.

Con l'aiuto dell'opzione "tentativi di controllo" puoi evitare le notifiche in caso di errori sporadici. Questo rende il check meno sensibile, per così dire. A questo scopo puoi utilizzare i set di regole Maximum number of check attempts for host e Maximum number of check attempts for service.

Se i check sono impostati su 3, ad esempio, e il servizio corrispondente diventa "CRIT", inizialmente non viene attivata alcuna notifica. Solo se anche i due check successivi producono un risultato che non è "OK", il conteggio dei check attuali aumenterà a 3 e verrà inviata la notifica.

Un servizio che si trova in questo stato intermedio — cioè non è OK ma non ha ancora raggiunto il numero massimo di tentativi di controllo — avrà uno stato soft. Solo uno stato hard attiverà effettivamente una notifica.