 |
This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved. |
1. Le caratteristiche speciali del Checkmk Micro Core
I vantaggi più significativi di CMC sono la performance superiore e i tempi di risposta più rapidi rispetto al nucleo di monitoraggio del progetto open source Nagios. Presenta inoltre altri vantaggi interessanti di cui dovresti essere a conoscenza, i più importanti dei quali sono:
Smart Ping — Controlli host intelligenti
Processi ausiliari Check helper, Checkmk Fetcher e Checkmk Checker
Pianificazione iniziale
Elaborazione dei dati sulle prestazioni
Alcune funzioni di Nagios non vengono utilizzate o vengono realizzate con una procedura diversa nel CMC. I dettagli al riguardo sono disponibili nell'articolo sulla migrazione al CMC.
2. Smart Ping — Controlli intelligenti degli host
Con Nagios, la disponibilità degli host viene solitamente verificata tramite un Ping.
A tal fine, per ogni host viene eseguito un plug-in come check_ping o check_icmp una volta per intervallo (generalmente una volta al minuto).
Questo invia, ad esempio, cinque pacchetti ping e attende il loro ritorno.
La creazione dei processi per l'esecuzione dei plug-in occupa preziose risorse della CPU.
Inoltre, questi possono formare un backlog per un periodo piuttosto lungo se un host non è raggiungibile e si devono sopportare lunghi timeout.
Al contrario, CMC esegue i controlli degli host — a meno che non sia configurato diversamente — utilizzando una procedura chiamata Smart Ping.
Smart Ping si basa su un componente interno chiamato icmpsender, che ha una propria implementazione di ping.
Dato che Checkmk con CMC non si affida a un binary esterno, non c'è bisogno di avviare un nuovo processo per ogni pacchetto ping inviato.
Inoltre, il comportamento predefinito di icmpsender differisce da quello della sua controparte Nagios.
Invece di inviare una serie rapida di pacchetti in attesa di risposta, icmpsender invia solo un pacchetto ICMP per host ogni n secondi (il valore predefinito è 6 secondi, configurabile tramite il set di regole Normal check interval for host checks).
Questo comportamento riduce drasticamente il consumo di risorse e il traffico dati.
Le risposte ai ping non vengono attese in modo esplicito.
Il componente "icmpreceiver" del CMC è responsabile di decidere se lo stato di un host è "UP" o "DOWN".
Il CMC considera i pacchetti ping in arrivo da un host come un check dell'host riuscito e quindi contrassegna l'host come "UP".
Se non viene ricevuto alcun pacchetto da un host entro un tempo definito, questo host verrà contrassegnato come "DOWN".
Il timeout è preimpostato a 15 secondi (2,5 intervalli di tempo) e può essere modificato per ogni host con il set di regole "Settings for host checks via Smart PING".
Il componente icmpreceiver ascolta anche i pacchetti TCP SYN (sincronizzazione) e RST (reset) provenienti da un host.
Quando riceve tali pacchetti, l'host viene considerato UP.
Questo meccanismo può portare a stati irregolari degli host in infrastrutture in cui il traffico ICMP non è consentito ma quello TCP sì.
 |
|
2.1. Nessun check degli host su richiesta
I controlli degli host non servono solo a attivare notifiche in caso di guasto totale dell'host, ma anche a sopprimere le notifiche di problemi di servizio durante il tempo di manutenzione programmata dell'host. Possono verificarsi problemi di servizio che non sono imputabili al servizio stesso, ma piuttosto a una condizione di guasto dell'host. Può succedere che un host sia in realtà in stato "DOWN" anche se il suo ultimo stato conosciuto in Checkmk è "UP", secondo l'ultimo risultato del controllo dell'host. In tali condizioni, più controlli del servizio potrebbero segnalare problemi che dipendono dallo stato "DOWN" dell'host, con conseguente invio di notifiche di servizio — erroneamente. In caso di un problema di servizio è quindi importante determinare prima la condizione dell'host del servizio.
Il CMC risolve questo problema in modo molto semplice: se si verifica un problema di servizio e l'host è in stato "UP", il CMC attenderà il prossimo check dell'host. Dato che l'intervallo è molto breve (di default solo 6 secondi), il ritardo nella notifica è trascurabile — se l'host è ancora "UP" e quindi la notifica deve essere inviata per il servizio.
Prendiamo ad esempio il caso di un plug-in check_http che segnala uno stato "CRIT", perché il server web interrogato non è disponibile.
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 stesso è "UP" e può quindi inviare la notifica senza ritardi.
Lo stesso principio viene utilizzato nel calcolo delle interruzioni di rete se sono stati definiti host padre. Anche in questo caso le notifiche a volte subiranno un breve ritardo per attendere uno stato verificato.
2.2. I vantaggi
Questa procedura offre una serie di vantaggi:
Carico della CPU praticamente insignificante derivante dai checks degli host: anche senza hardware particolarmente potente è possibile effettuare il monitoraggio di decine di migliaia di host.
Nessun ostacolo al monitoraggio dovuto a ingorghi nei check degli host su richiesta se gli host sono in modalità "DOWN".
Nessun falso allarme da parte dei servizi quando lo stato dello host non è aggiornato.
C'è però uno svantaggio da non sottovalutare: i controlli host Smart Ping non generano dati sulle prestazioni (tempi di esecuzione dei pacchetti).
Sugli host in cui questi sono necessari, puoi semplicemente impostare un active check tramite ping con il set di regole "Check hosts with PING (ICMP Echo Request)".
2.3. Host non raggiungibili tramite ping
In pratica, non tutti gli host sono controllabili tramite ping. In questi casi, per il controllo dell'host si possono utilizzare anche altri metodi in CMC, ad esempio una connessione TCP. Poiché si tratta generalmente di eccezioni, non hanno alcun impatto negativo sulla performance complessiva. Il set di regole qui è Host check command.
2.4. Problemi con i firewall
Esistono firewall che rispondono ai pacchetti di connessione TCP verso host inaccessibili con un pacchetto TCP RST. Il trucco sta nel fatto che al firewall non è permesso registrarsi come mittente di questo pacchetto, ma deve essere specificato l'indirizzo IP dell'host di destinazione. Smart Ping interpreterà questo pacchetto come un segno di vita e supporrà erroneamente che l'host di destinazione sia accessibile.
In una situazione del genere (rara), 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 check host per gli host interessati.
3. Processi ausiliari
Una lezione che si può trarre dalle scarse prestazioni di Nagios in ambienti di grandi dimensioni è che la creazione di processi è un'operazione che richiede risorse e tempo. La dimensione del processo padre è il fattore decisivo in questo caso. Per ogni esecuzione di un active check, il processo Nagios completo deve prima essere duplicato (forkato) prima di essere sostituito dal nuovo processo: il plug-in di controllo. Più host e servizi devono essere monitorati, più grande è questo processo e più tempo richiede il fork. Nel frattempo, le altre attività del core devono aspettare — e qui 24 core di CPU non sono di grande aiuto.
3.1. Check helper
Per evitare di eseguire il fork del core, all’avvio del programma il CMC crea un numero fisso di processi ausiliari molto snelli il cui compito è avviare i plug-in di controllo attivo: i check helper.
Non solo questi si duplicano molto più rapidamente, ma il fork si espande fino a coprire tutti i core disponibili perché il core stesso non è più bloccato.
In questo modo, l'esecuzione dei controlli attivi (ad es. check_http) — i cui tempi di esecuzione sono in realtà piuttosto brevi — viene notevolmente accelerata.
3.2. Checkmk Fetcher e Checkmk Checker
Il CMC fa però un passo avanti significativo — perché in un ambiente Checkmk gli active checks sono piuttosto un'eccezione. Qui si utilizzano principalmente controlli basati su Checkmk — in cui è richiesto un solo fork per host e intervallo.
Per ottimizzare l'esecuzione di questi controlli, il CMC gestisce altri due tipi di processi ausiliari: i Checkmk Fetcher e i Checkmk Checker.
I Checkmk Fetcher
I Checkmk Fetcher recuperano le informazioni necessarie dagli host monitorati, ovvero i dati dai serviziCheck_MK eCheck_MK Discovery . I Fetcher si occupano quindi della comunicazione di rete con gli agenti Checkmk, gli agenti SNMP e gli special agents. La raccolta di queste informazioni richiede un po' di tempo, ma dato che in genere sono necessari meno di 50 megabyte per processo — che è relativamente poca memoria — è possibile configurare più processi senza problemi. Tieni presente che i processi possono essere sottoposti a swap solo in parte o per niente e devono quindi essere sempre mantenuti nella memoria fisica. Il fattore limitante in questo caso è la memoria disponibile nel server Checkmk.
|
I 50 megabyte menzionati sopra sono una stima di massima. Il valore effettivo potrebbe essere più alto in circostanze specifiche — ad esempio perché IPMI è stato configurato sulla scheda di gestione. |
Checkmk Checker
I Checkmk Checker analizzano e valutano le informazioni raccolte dai Checkmk Fetcher e generano i risultati dei controlli per i servizi. I Checkmk Checker richiedono molta memoria perché devono includere la configurazione di Checkmk. Un processo di Checkmk Checker occupa almeno circa 90 megabyte — tuttavia, potrebbe essere necessario un multiplo di questo valore, a seconda di come sono configurati i controlli. D'altra parte, i checker non generano alcun carico di rete e vengono eseguiti molto rapidamente. Il numero di checker dovrebbe essere pari solo a quello che il tuo server Checkmk è in grado di elaborare in parallelo. Di norma, questo numero corrisponde al numero di core del tuo server. Poiché i checker non sono vincolati dall'I/O, sono più efficaci se ogni checker ha un proprio core.
La divisione dei due diversi compiti "raccolta" ed "esecuzione" tra il Checkmk Fetcher e il Checkmk Checker esiste dalla versione 2.0.0 di Checkmk. In precedenza c'era un solo tipo di processo ausiliario responsabile di entrambi: i cosiddetti helper Checkmk.
Con il modello fetcher/checker, entrambe le attività sono ora suddivise in due pool separati di processi: il recupero delle informazioni dalla rete con molti piccoli processi fetcher e il controllo, che richiede un'elevata potenza di calcolo, con pochi grandi processi checker. Di conseguenza, un CMC utilizza fino a quattro volte meno memoria a parità di performance (controlli al secondo)!
3.3. Impostare correttamente il numero di processi ausiliari
Il numero di check helper (active checks), Checkmk Fetcher e Checkmk Checker avviati di default è definito in Global settings > Monitoring core e può essere personalizzato da te:
Per capire se e come devi modificare i valori predefiniti, hai 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 processi sufficienti 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'istanza. Per percentuali più elevate, dovresti aumentare il numero di processi. Dato che il numero necessario di Checkmk Fetcher cresce con il numero di host e servizi monitorati, qui è molto probabile che sia necessaria una correzione. Tuttavia, fai attenzione a creare solo il numero di processi ausiliari realmente necessario, 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 mostra non solo l'utilizzo, ma anche la latenza. Per questi valori vale la semplice regola: più basso è, meglio è — e quindi 0 secondi è l'ideale.
|
Puoi anche visualizzare i valori mostrati nello snap-in per la tua istanza nei dettagli del servizio OMD <site_name> performance. |
In alternativa allo snap-in "Core statistics", puoi anche far analizzare la tua configurazione da Checkmk, con l'opzionSetup > Maintenance > Analyze configuration. Il vantaggio in questo caso è che ottieni una valutazione immediata da parte di Checkmk dello stato dei processi ausiliari. È molto utile che, se uno dei processi ausiliari non è "OK", dal testo di aiuto puoi aprire l'opzione corrispondente "Global settings" per modificare il valore del processo.
4. Pianificazione iniziale
Durante la pianificazione si definisce quali controlli devono essere eseguiti e in quali momenti. Nagios ha implementato numerose procedure che dovrebbero garantire che i controlli siano distribuiti regolarmente nell'intervallo. Allo stesso modo, Nagios cercherà di distribuire le query da eseguire in modo uniforme su un singolo sistema di destinazione nell'intervallo di tempo.
Il CMC ha una propria procedura, più semplice, a questo scopo. Questa tiene conto del fatto che Checkmk effettua già un contatto con un host una volta per intervallo. Inoltre, il CMC garantisce che i nuovi controlli vengano eseguiti immediatamente e non distribuiti su diversi minuti. Questo è molto comodo per l'utente, poiché un nuovo host verrà interrogato non appena la configurazione sarà stata attivata. Per evitare che un gran numero di nuovi controlli causi un picco di carico, i nuovi controlli il cui numero supera un limite definibile possono essere distribuiti sull'intero intervallo. L'opzione per farlo si trova in Global settings > Monitoring core > Initial scheduling.
5. Elaborazione dei dati sulla performance
Una funzione importante di Checkmk è l'elaborazione dei dati di misurazione, come l'utilizzo della CPU, e la loro conservazione per un lungo periodo di tempo. Nella Comunità Checkmk, a questo scopo si usa PNP4Nagios, che a sua volta si basa su RRDtool.
Il software svolge due funzioni:
La creazione e l'aggiornamento dei database Round Robin (RRD).
La rappresentazione grafica dei dati nella GUI.
In un'operazione core di Nagios, la funzione menzionata al punto 1. sopra è un processo piuttosto lungo.
A seconda del metodo, vengono utilizzati file di spool, script Perl e un processo ausiliario (npcd) scritto in C.
Infine, i dati parzialmente convertiti vengono scritti nel socket Unix del daemon della cache RRD.
Il CMC accorcia questa catena scrivendo direttamente nel daemon della cache RRD — tutti i passaggi intermedi vengono eliminati. L'analisi e la conversione dei dati nel formato RRDtool vengono eseguite direttamente in C++. Questo metodo è possibile e sensato al giorno d'oggi, poiché il daemon della cache RRD ha già implementato un proprio spooling molto efficiente e, con l'aiuto dei file di journal, ciò significa che nessun dato va perso in caso di evento di crash del sistema.
I vantaggi:
Riduzione dell'I/O su disco e del carico della CPU
Implementazione più semplice con una stabilità notevolmente maggiore
Il CMC crea nuovi RRD utilizzando un altro helper, che viene chiamato tramite cmk-create-rrd.
Questo helper crea i file in un formato compatibile con PNP o, in alternativa, nel nuovo formato Checkmk (vale solo per le nuove installazioni).
Il switch da Nagios a CMC non ha quindi alcun effetto sui file RRD esistenti.
Questi continuano a essere gestiti senza problemi.
Nelle edizioni commerciali la visualizzazione grafica dei dati nella GUI è handled direttamente dalla GUI di Checkmk stessa, quindi non è coinvolto alcun componente PNP4Nagios.