Principi di base del monitoraggio con Checkmk

Tutto in Checkmk 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 di UNREACH, deve sapere quale percorso può utilizzare per contattare ogni singolo host. A tale scopo, per ogni host è possibile specificare uno o più host padre. Ad esempio, se un server A , visto dal monitoraggio, è raggiungibile solo tramite un router B, allora B è un host padre di A. In Checkmk vengono configurati solo i genitori diretti. Si ottiene così una struttura ad albero con l'istanza Checkmk al centro (qui rappresentata come ):

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

La prevenzione di falsi allarmi è garantita anche dalla funzione Checkmk Micro Core (CMC) utilizzata nelle edizioni commerciali. In questo caso, il cambiamento di stato di un host guasto viene trattenuto per alcuni istanti e procede solo quando è certo che il padre è ancora raggiungibile. Se, invece, il padre è definitivamente " DOWN", l'host passa a " UNREACH" senza che venga attivata alcuna notifica.

In alcuni casi un host potrebbe avere più host padre, ad esempio quando un router è in esecuzione con alta disponibilità in un cluster. È sufficiente che Checkmk sia in grado di determinare in modo univoco lo stato dell'host quando uno di questi host padre è raggiungibile. Pertanto, quando un host ha più host padre e almeno uno di questi è UP, l'host è 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 è nello stato UP.

Un servizio monitorato può avere i seguenti stati:

Per determinare quale condizione è "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. Gli stati possibili sono descritti nella sezione precedente. I servizi e i check sono strettamente correlati. Per questo motivo questi termini sono talvolta utilizzati in modo intercambiabile, forse anche in questo manuale, sebbene si tratti di cose diverse.

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

Come si può vedere dall'esempio del plug-in di controllo df, un plug-in di controllo può essere responsabile di più servizi. 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 dei servizi e dei controlli sono visibili anche nel monitoraggio. Nell'elenco dei servizi per un host in monitoraggio, è possibile notare che nel menu azione 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 passive check i cui dati vengono recuperati da un altro servizio, il servizio Check_MK. Ciò avviene 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 viene contrassegnato come gestito e, ovviamente, i problemi non gestiti sono quelli che non sono ancora stati risolti. La panoramica nella barra laterale distingue quindi questi due tipi di problemi:

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

Ulteriori dettagli sulle conferme sono disponibili in un articolo dedicato.

Quando lo stato di un 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, viene inviata un'e-mail ai contatti dell'oggetto (si noti che ogni utente appena creato, per impostazione predefinita, non è un contatto per nessun oggetto). Tuttavia, questi possono essere personalizzati 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 una seconda fase passa attraverso una catena di regole. In queste regole è possibile definire ulteriori criteri di esclusione e decidere chi deve essere notificato e in quale modulo (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 commuta tale servizio nello stato irregolare. Ciò è indicato dal simbolo .

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

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

A tale scopo è possibile inserire una condizione di tempi di manutenzione programmata su un host o un servizio. Ciò può essere fatto direttamente prima di iniziare il lavoro o in anticipo. I tempi di manutenzione programmata sono indicati dai simboli:

Mentre un host o un servizio ha un tempo di manutenzione programmata:

Inoltre, se si desidera documentare in un secondo momento le statistiche sulla disponibilità degli host e dei servizi è consigliabile includere i tempi di manutenzione programmata. Questi possono essere presi in considerazione nelle valutazioni di disponibilità successive.

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

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

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

È possibile regolare il limite di tempo dopo il quale gli host e i servizi diventano in stallo. A tal fine, consultare la sezione relativa agli intervalli di check.

È possibile limitare i periodi di tempo in cui vengono eseguiti i check. A tale scopo servono i set di regole " Check period for hosts", " Check period for active services " e " Check period for passive Checkmk services ". Utilizzare queste regole per selezionare uno dei periodi di tempo disponibili come periodo di check.

I check vengono eseguiti a intervalli fissi nell'ambito del monitoraggio basato sullo stato. Checkmk utilizza un intervallo predefinito di un minuto per i check dei servizi e di 6 secondi per i check 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 si combina un periodo di check con un intervallo di check, è possibile garantire che un active check venga eseguito esattamente una volta al giorno in un momento ben preciso. Ad esempio, se si imposta l'intervallo di check su 24 ore e il periodo di check su 2:00-2:01 ogni giorno (cioè solo un minuto al giorno), Checkmk garantirà che il check 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 in stallo con il simbolo . Con l'impostazione globale Staleness value to mark hosts / services stale è possibile definire quanto tempo deve trascorrere prima che un host/servizio passi allo stato di stallo. Questa impostazione si trova sotto Setup > General > Global settings > User interface:

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

Con l'opzione tentativi di check è possibile evitare notifiche in caso di errori sporadici. In questo modo il check diventa meno sensibile, per così dire. A tale scopo è possibile utilizzare i set di regole Maximum number of check attempts for host e Maximum number of check attempts for service.

Se i tentativi di 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 diverso da " OK", il conteggio dei tentativi correnti aumenta a 3 e viene inviata la notifica.

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