In questo blog post, presentiamo le varie innovazioni di Checkmk 2.0, dirette in particolare a migliorare in modo significativo le prestazioni del monitoraggio. Ad esempio, la nuova architettura del CMC (Checkmk Micro Core) riduce l'ingombro della memoria e della CPU di Checkmk.
Consumo di memoria fino a 4 volte inferiore
Per Checkmk 2.0 sono stati apportati alcuni miglioramenti anche al Checkmk Micro Core, utilizzato nell'Enterprise Edition. Il risultato della modifica del core è che Checkmk 2.0 necessita ora di una quantità di RAM fino a quattro volte inferiore rispetto a prima, a parità di prestazioni. Per questo abbiamo completamente rivisto i processi Helper.
L'architettura degli Helper in Checkmk 1.6 era così composta: Il core invia un compito a uno degli Helper di Checkmk, ad esempio per eseguire una query sull'host. Dopo aver ricevuto il task dal Micro Core, l'Helper inizia a elaborarlo. A tal fine, raccoglie innanzitutto i dati dall'host desiderato, ad esempio tramite un agente o SNMP. L'Helper elabora quindi il risultato del controllo a partire dai dati raccolti. Il risultato viene quindi inoltrato al CMC, dove viene trasmesso come nuovo stato del servizio. L'intera procedura è un unico processo.
Il problema è che questi processi sono molto pesanti in termini di memoria, soprattutto in ambienti di grandi dimensioni. Inoltre, potrebbero dover attendere l'I/O di rete. Di conseguenza, questi processi affamati di memoria rimangono inattivi durante l'attesa dell'I/O di rete e sono quindi inefficienti.
Abbiamo quindi rivisto l'architettura e rivisto l'intero processo. In Checkmk 2.0 abbiamo ovviamente ancora il nucleo di monitoraggio, ma adesso abbiamo anche due processi ausiliari separati: i Fetchers e i Checkers.
I Fetchers sono responsabili della raccolta dei dati di monitoraggio grezzi, ad esempio tramite agenti o SNMP. Trattandosi di processi molto piccoli, un ambiente di monitoraggio può averne molti. Inoltre, richiedono poca memoria, quindi l'attesa dell'I/O di rete non è più un problema. Quando un Fetcher riceve i suoi dati o un timeout, li inoltra al Core.
Il CMC invia poi questi dati ai processi Checker, che sono ancora molto pesanti dal punto di vista della memoria, molto simili agli Helper di Checkmk 1.6, in quanto, oltre ai dati di monitoraggio grezzi, devono anche conoscere tutte le configurazioni dei check. Tuttavia, poiché il nucleo fornisce i dati di monitoraggio, i Checker possono elaborarli direttamente e fornire lo stato dei servizi. Poiché i Checker non sono più inattivi, Checkmk ha bisogno di un numero inferiore di essi, riducendo così l'ingombro in termini di memoria e CPU.
Negli ambienti in cui abbiamo già testato la nuova architettura, siamo riusciti a ridurre il consumo di memoria di quattro volte. Ciò significa che con la nuova architettura è possibile monitorare in Checkmk un numero di sistemi fino a quattro volte superiore, a parità di prestazioni CMC.
Per impostazione predefinita, Checkmk 2.0 dispone di 13 processi Fetcher e quattro Checker. Tuttavia, è possibile apportare modifiche granulari se la latenza dei controlli è troppo elevata o se l'utilizzo di Checker e Fetcher è troppo elevato. Ad esempio, aumentando manualmente il numero di un pool per ottenere le migliori prestazioni possibili per l'ambiente di monitoraggio.
Prestazioni più elevate negli ambienti distribuiti
Inoltre, con Checkmk 2.0 stiamo introducendo ulteriori miglioramenti delle prestazioni. Negli ambienti di monitoraggio distribuiti, il meccanismo di sincronizzazione funzionerà in futuro in modo incrementale. Ciò significa che istanze centrali e siti remoti comunicheranno tra loro prima della sincronizzazione e poi scambieranno solo i dati di configurazione modificati.
In questo modo, le modifiche alla configurazione negli ambienti di monitoraggio distribuiti dovrebbero essere molto più efficienti. In precedenza, Checkmk sincronizzava sempre l'intero pacchetto di configurazione. Il nuovo approccio richiede quindi meno larghezza di banda e potenza di CPU.
Risolvere i colli di bottiglia delle prestazioni su tutta la linea
Inoltre, abbiamo esaminato molti scenari individuali e valutato come migliorare le prestazioni per ogni caso d'uso specifico e per il monitoraggio in generale. La nostra motivazione è quella di migliorare in modo duraturo le prestazioni di Checkmk dal punto di vista dell'utente, analizzando in modo specifico i diversi scenari di utilizzo di Checkmk nella pratica.
Il risultato di questo approccio è stato, ad esempio, la modifica di quasi tutti i componenti, in particolare del check engine e dell'elaborazione della configurazione, consentendo una valutazione più rapida delle regole per gli attributi espliciti degli host, una migliore gestione di un numero maggiore di host piggyback, un aggiornamento fino a cento volte più rapido delle voci DNS degli host e un tempo di caricamento della configurazione sei volte più rapido. Inoltre, abbiamo accelerato il rendering dei grafici ad alta risoluzione nell'interfaccia grafica.
Nella configurazione, abbiamo migliorato l'ordinamento di migliaia di gruppi di tag host e il completamento automatico di host e servizi. Inoltre, le pagine rilevanti per l'host si caricano più velocemente e anche il rendering di tabelle lunghe è più rapido. Abbiamo anche migliorato la ricerca di set di regole con molti riferimenti temporali e gruppi di contatti, host e servizi.
Ulteriori informazioni su Checkmk 2.0
Per approfondire i numerosi cambiamenti e le caratteristiche che Checkmk 2.0 ha in serbo, leggete uno dei nostri blog post su un argomento specifico:
- Più moderna, intuitiva e personalizzata - la nuova UX
- Cloud e container - monitoraggio dei moderni asset IT
- Monitoraggio della rete: approfondimenti e configurazione migliorata
- Le nuove API offrono automazione e maggiore stabilità
- Un'ampia base per il monitoraggio IT
Ulteriori informazioni su Checkmk 2.0 sono disponibili nel forum Checkmk, nella nostra documentazione o sul nostro canale YouTube.