Principi di base del monitoraggio con Checkmk

Tutto in Checkmk ruota intorno agli host e ai servizi. Un host può essere molte cose, es:

Nello stato di 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 es:

Affinché il monitoraggio possa determinare lo stato di RAGGIUNGIBILE, deve sapere quale percorso può utilizzare per contattare ogni singolo host. A questo scopo, è possibile specificare uno o più cosiddetti host padre per ogni host. Ad esempio, se un server A visto dal monitoraggio può essere raggiunto solo tramite un router B, allora B è un host padre di A. In Checkmk vengono configurati solo i genitori diretti. Questo risulta in una struttura ad albero con il sito Checkmk al centro (mostrato qui come ):

Supponiamo che nella topologia di rete mostrata sopra, gli host myhost e myhost4 non siano più raggiungibili. Il fallimento di myhost4 può essere spiegato dal fatto che myhost è fallito. Pertanto, myhost4 viene classificato come NON RAGGIUNGIBILE nel monitoraggio. Semplicemente non è possibile determinare chiaramente il motivo per cui Checkmk non riesce più a raggiungere myhost4 e lo stato DOWN sarebbe quindi fuorviante in alcune circostanze. NON RAGGIUNGIBILE ha invece l'effetto di sopprimere le notifiche per impostazione predefinita, il che è in fondo il compito più importante del concetto di genitorialità, ossia evitare notifiche di massa nell'evento in cui un intero segmento di rete dipendente diventa irraggiungibile per il monitoraggio a causa di un'interruzione in un singolo punto.

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

In alcuni casi un host potrebbe avere più genitori, ad esempio quando un router è in esecuzione ad alta disponibilità in un cluster. È sufficiente che Checkmk sia in grado di determinare in modo univoco lo stato dell'host quando uno di questi genitori è raggiungibile. Pertanto, quando un host ha più genitori e almeno uno di essi è UP, l'host è considerato raggiungibile nel monitoraggio. In altre parole, in questa situazione l'host non passerà automaticamente allo stato NON RAGGIUNGIBILE.

Un host ha una serie di servizi. Un servizio può essere qualsiasi cosa - non confonderti 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 è in stato UP.

Un servizio da monitorare può avere i seguenti stati:

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

OK → WARN → SCONOSCIUTO → CRIT

Un controllo assicura che a un host o a un servizio possa essere assegnato uno stato. Quali siano questi stati è stato descritto nella sezione precedente. Servizi e controlli sono strettamente correlati. Per questo motivo a volte questi termini vengono utilizzati in modo intercambiabile, forse anche in questo manuale, anche se in realtà si tratta di cose diverse.

Nel Setup puoi visualizzare quale plug-in di controllo è responsabile di ogni servizio. Apri le proprietà di un host con Setup > Hosts e poi nel menu Hosts > Service Configuration l'elenco dei servizi per questo host. Poi usa Display > Show plugin names per visualizzare una nuova colonna che mostrerà il plug-in di controllo responsabile di ogni 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. Inoltre, i nomi del plug-in di controllo elencati nella colonna sono anche dei link che mostrano una descrizione del plug-in di controllo.

La connessione e la dipendenza tra servizi e controlli può essere vista anche nel monitoraggio. Nell'elenco dei servizi di un host in monitoraggio, puoi vedere che nel menu azione alla voce dell'elenco Reschedule c'è una freccia gialla per alcuni servizi (), ma una freccia grigia per la maggior parte degli altri (). Un servizio con la freccia gialla è basato su un active check:

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 avviene per motivi di prestazioni ed è una caratteristica speciale di Checkmk.

Checkmk identifica ogni host che non è UP e ogni servizio che non è OK come un problema. 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 segnalato come gestito e, non a caso, i problemi non gestiti sono quelli che non sono ancora stati presi in considerazione. La panoramica nella barra laterale differenzia 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.

Ulteriori dettagli sulla conferma dei problemi sono disponibili nell'articolo dedicato, " Confermare i problemi".

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 ha un problema, viene inviata un'e-mail ai contatti dell'oggetto (nota che l'utente cmkadmin, per impostazione predefinita, non è un contatto per nessun oggetto). Le notifiche possono essere personalizzate in modo molto flessibile. Le notifiche dipendono anche da una serie di parametri. La cosa più semplice è osservare i casi in cui le notifiche non vengono inviate. Le notifiche vengono soppresse ...

Se nessuno di questi prerequisiti per sopprimere le notifiche è soddisfatto, il nucleo di monitoraggio crea una notifica, che in un secondo momento passa attraverso una catena di regole. In queste regole puoi definire ulteriori criteri di esclusione e decidere chi deve essere notificato e in quale modulo (e-mail, SMS, ecc.).

Tutti i dettagli sulle notifiche si trovano nell'articolo dedicato alle notifiche.

A volte capita che un servizio cambi continuamente e rapidamente le sue condizioni. Per evitare notifiche continue, Checkmk commuta tale servizio nello stato di flapping, come illustrato dal simbolo . Quando un servizio entra nello stato di flapping, viene generata una notifica che informa l'utente della situazione e silenzia ulteriori notifiche. Dopo un tempo adeguato, se non si verificano altri cambiamenti rapidi e se è evidente uno stato finale (buono o cattivo), lo stato di flapping scompare e riprendono le normali notifiche.

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

A questo scopo puoi inserire una condizione di tempi di manutenzione programmata su un host o un servizio. Questo può essere fatto direttamente prima di iniziare il lavoro o in anticipo. I tempi di manutenzione programmata sono illustrati dai simboli:

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

Inoltre, quando desideri documentare in seguito le statistiche sulla disponibilità di host e servizi, è una buona idea includere i tempi di manutenzione programmata, che possono essere presi in considerazione nelle valutazioni successive della disponibilità.

Se lavori con Checkmk da un po' di tempo, è possibile che nelle visualizzazioni degli host e dei servizi vengano visualizzate delle ragnatele. Per i servizi, ad esempio, l'aspetto è questo:

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

In generale, un host o un servizio viene contrassegnato come stallo quando Checkmk non riceve più informazioni aggiornate sul suo stato per un lungo periodo di tempo:

Puoi regolare il limite di tempo dopo il quale gli host e i servizi diventano in stallo. Per questo, leggi la sezione sugli intervalli di controllo.

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

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

Questi intervalli predefiniti possono essere modificati 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 check, puoi assicurarti che un controllo attivo venga eseguito esattamente una volta al giorno in un momento molto specifico. Ad esempio, se imposti l'intervallo di check a 24 ore e il periodo di check a 2:00 - 2:01 ogni giorno (cioè solo un minuto al giorno), Checkmk si assicurerà che il controllo venga effettivamente spostato in questa breve finestra temporale.

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

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

Con l'aiuto dell'opzione tentativi di controllo puoi evitare le notifiche in caso di errori sporadici. In questo modo un controllo diventa per così dire meno sensibile. 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 tentativi di controllo sono impostati a 3, ad esempio, e il servizio corrispondente diventa CRIT, inizialmente non viene attivata alcuna notifica. Solo se anche i due controlli successivi producono un risultato non OK, il conteggio dei tentativi in corso aumenta a 3 e viene 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 verifica - avrà uno stato soft. Solo uno stato hard attiverà effettivamente una notifica.