Caratteristiche speciali del CMC

I controlli dell'host non servono solo a far scattare le notifiche in caso di guasto totale dell'host, ma anche a sopprimere le notifiche di problemi di servizio durante il periodo di inattività dell'host. I problemi di servizio possono sorgere e non essere responsabilità del servizio stesso, ma piuttosto di una condizione di guasto dell'host. Può accadere che un host sia effettivamente DOWN anche se il suo ultimo stato noto in Checkmk è UP, come risulta dal risultato dell'ultimo controllo dell'host. In questa condizione, più controlli di servizio potrebbero restituire problemi che dipendono dallo stato DOWN dell'host, con conseguente invio di notifiche di servizio - erroneamente. È quindi importante determinare prima la condizione di un host, in caso di problemi di servizio.

Il CMC risolve questo problema in modo molto semplice: se si verifica un problema di servizio e l'host si trova in uno stato UP, il CMC aspetterà il prossimo controllo dell'host. Dato che l'intervallo è molto breve (per impostazione predefinita), solo 6 secondi, il ritardo della notifica è trascurabile se l'host è ancora UP e quindi è necessario inviare la notifica per il servizio.

A titolo di esempio, prendiamo il caso di un plug-in di controllo di check_http che rilascia uno stato CRIT a causa dell'indisponibilità del servizio web interrogato. In questa situazione, dopo l'avvio del controllo del servizio, il componente icmpreceiver riceverà da questo server un pacchetto TCP RST(connessione rifiutata). Il CMC sa quindi con certezza che l'host è UP e può quindi inviare la notifica senza ritardi.

Lo stesso principio viene utilizzato per calcolare le interruzioni di rete se sono stati definiti degli host padre. Anche in questo caso le notifiche saranno a volte ritardate brevemente per attendere una verifica dello stato.

Questa procedura offre una serie di vantaggi:

C'è però uno svantaggio da non trascurare: i controlli host Smart Ping non generano dati sulle prestazioni (tempi di esecuzione dei pacchetti).

Per gli host in cui questi dati sono necessari, puoi semplicemente impostare un active check tramite ping con il set di regole Check hosts with PING (ICMP Echo Request).

In pratica, non tutti gli host possono essere controllati tramite ping. In questi casi, per il controllo dell'host possono essere utilizzati anche altri metodi di CMC, ad es. una connessione TCP. Poiché si tratta generalmente di eccezioni, non hanno un impatto negativo sulle prestazioni complessive. Il set di regole in questo caso è Host Check Command.

Esistono firewall che rispondono ai pacchetti di connessione TCP verso host inaccessibili con un pacchetto TCP RST. Il trucco sta nel fatto che il firewall non può registrarsi come mittente di questo pacchetto, ma deve specificare l'indirizzo IP dell'host di destinazione. Smart Ping visualizzerà questo pacchetto come un segno di vita e supporrà erroneamente che l'host di destinazione sia accessibile.

In questa (rara) situazione, tramite Global settings > Monitoring Core > Tuning of Smart PING hai la possibilità di attivare l'opzione Ignore TCP RST packets when determining host state. Oppure, con check_icmp puoi selezionare un ping convenzionale come verifica degli host interessati.

Per evitare il fork del core, durante l'avvio del programma il CMC crea un numero fisso di processi ausiliari molto snelli il cui compito è quello di avviare i plug-in di controllo attivi: i check helper.Non solo questi si biforcano molto più rapidamente, ma il fork si estende anche a tutti i core disponibili perché il core stesso non è più bloccato. In questo modo, l'esecuzione dei controlli attivi (es. check_http) - i cui tempi di esecuzione sono in realtà piuttosto brevi - viene notevolmente accelerata.

Il CMC compie un ulteriore passo avanti, perché in un ambiente Checkmk i check attivi rappresentano un'eccezione: qui si utilizzano principalmente i check basati su Checkmk, che richiedono un solo fork per host e per intervallo.

Per ottimizzare l'esecuzione di questi controlli, il CMC mantiene altri due tipi di processi ausiliari: i Checkmk Fetcher e i Checker.

Per impostazione predefinita, vengono avviati 5 check helper, 13 Checkmk fetcher e 4 Checkmk Checker. Questi valori sono impostati in Global settings > Monitoring Core e possono essere personalizzati da te:

Per sapere se e come modificare i valori predefiniti, hai a disposizione diverse opzioni:

Nella barra laterale, lo snap-in Core statistics mostra la percentuale di utilizzo media degli ultimi 10-20 secondi:

Per tutti i tipi di processi ausiliari, dovrebbero esserci sempre abbastanza processi per eseguire i controlli configurati. Se un pool viene utilizzato al 100%, i controlli non verranno eseguiti in tempo, la latenza aumenterà e gli stati dei servizi non saranno aggiornati.

L'utilizzo non dovrebbe superare l'80% pochi minuti dopo l'avvio di un sito. Per percentuali più elevate, dovresti aumentare il numero di processi. Poiché il numero necessario di Checkmk Fetcher cresce con il numero di host e servizi monitorati, è molto probabile che venga apportata una correzione. Tuttavia, fai attenzione a creare solo il numero di processi ausiliari realmente necessari, poiché ogni processo occupa risorse. Inoltre, tutti i processi ausiliari vengono inizializzati in parallelo all'avvio del CMC, il che può portare a picchi di carico.

Lo snap-in Core statistics ti mostra non solo l'utilizzo, ma anche la latenza. Per questi valori vale la semplice regola: più basso è, meglio è - e 0 secondi è quindi il valore migliore.

In alternativa allo snap-in Core statistics, puoi anche far analizzare la tua configurazione da Checkmk, con Setup > Maintenance > Analyze configuration. Il vantaggio: in questo caso ottieni una valutazione immediata da Checkmk sullo stato dei processi ausiliari. Molto utile: se uno dei processi ausiliari non è OK, puoi aprire dal testo di aiuto l'opzione Global settings corrispondente per modificare il valore.