Conferenza Checkmk #6: Sguardo rivolto allo sviluppo

In occasione della Checkmk Conference #6, il nostro capo sviluppatore Lars Michelsen ha parlato dei progetti a cui il nostro team di sviluppo sta attualmente lavorando e di ciò che abbiamo in programma per voi con i miglioramenti della Versione 2.0. Abbiamo quindi selezionato alcuni aspetti importanti del suo intervento alla conferenza, che naturalmente non vogliamo nascondervi.

Una componente importante dell'ulteriore sviluppo di Checkmk è il miglioramento dell'esperienza utente. L'UX è così importante per noi che il nostro fondatore Mathias Kettner ha tenuto una lezione dettagliata alla conferenza e vi ha fornito un feedback utilizzando varie anteprime tecniche. Vogliamo anche creare un articolo apposito per voi, sull'argomento UX e Checkmk. Tuttavia, in questa sede ci concentreremo sui punti toccati da Lars nel suo intervento.

In primis, la Raw Edition riceverà una grafica modernizzata, già utilizzata nella Enterprise Edition. Il nostro obiettivo è fornire un look and feel coerente per tutte le edizioni. Ciò significa che i grafici HTML5 dell'Enterprise Edition sostituiranno completamente il PNP4Nagios precedentemente utilizzato per le visualizzazioni nella Raw Edition - ma non con l'intera gamma di funzioni, come ha sottolineato Lars. Ad esempio, i grafici singoli o combinati sono ancora disponibili solo nell'Enterprise Edition di Checkmk. La conversione tecnica che ne è alla base consente ora l'integrazione di Grafana anche per la Raw Edition.

Per la versione 2.0 abbiamo in programma anche alcune innovazioni per quanto riguarda l'analisi dei dati storici. Alcune funzioni possono essere utilizzate già nella versione 1.6., quindi esiste già la possibilità di prevedere l'andamento futuro delle metriche. Questo può aiutare a identificare i problemi in anticipo e ad anticipare i requisiti di capacità. Questa funzione può anche essere incorporata nei report.

Reporting migliorato e dashboard sensibili al contesto

Con la versione 2.0 stiamo ampliando le opzioni di reporting di Checkmk. Abbiamo previsto che i report in formato PDF possano contenere, a scelta, un indice e una copertina. Inoltre, dovrebbe essere possibile definire periodi specifici per i singoli elementi. Finora era possibile assegnare a tutti gli elementi lo stesso periodo di tempo.

Anche per quanto riguarda le dashboard ci saranno molte novità, come nuove forme di visualizzazione (dashlet) o la creazione più semplice delle stesse dashboard. Queste ultime sono ora sensibili al contesto e consentono di presentare fatti specifici, come ad esempio tutte le informazioni relative all'Host X. Per la versione 2.0 intendiamo rendere disponibili le dashboard per determinate applicazioni, oltre a Checkmk per vSphere, Linux o Windows.

Il nostro team di sviluppo ha lavorato anche alla cosiddetta panoramica sull'utilizzo dei tag. Questa vista consente all'utente di valutare dove vengono utilizzati i tag e i gruppi di tag in quali cartelle, host o regole.

Lars ha anche annunciato ulteriori sviluppi per il tema del cloud e dei container. Dall'introduzione del monitoraggio AWS con la release 1.6, abbiamo aggiunto ulteriori controlli a Checkmk, ad esempio per AWS Glacier o DynamoDB. Secondo Lars, questi controlli sono nati principalmente dalle richieste degli utenti. Per quanto riguarda Microsoft Azure, ultimamente abbiamo dedicato più tempo a migliorare il monitoraggio di AWS. Per il monitoraggio di Azure, invece, abbiamo creato una funzione importante per il monitoraggio dell'accoppiamento di Active Directory, che è rilevante per la maggior parte degli ambienti Azure.

Secondo Lars, il monitoraggio di Kubernetes funziona già bene. Abbiamo anche aggiunto ulteriori check alle funzionalità del nostro monitoraggio di Kubernetes, come il check degli oggetti Ingress e un plug-in per l'inventario. Checkmk è ora in grado di determinare i dati di inventario dei lavori nei cluster Kubernetes e di valutarne lo stato tramite un controllo. Anche l'integrazione di Prometheus svolge un ruolo importante nel monitoraggio degli ambienti Kubernetes con Checkmk: presto vi forniremo informazioni più dettagliate al riguardo.

Una parte essenziale della connessione al cloud e ai container in Checkmk è il demone di configurazione dinamica (DCD). Esso garantisce che Checkmk si occupi automaticamente delle modifiche alla configurazione. In questo modo, Checkmk rileva, ad esempio, gli elementi volatili nelle infrastrutture dinamiche e li rimuove automaticamente dopo la loro scadenza. Anche in questo caso, il nostro reparto di sviluppo ha contribuito a ottimizzare l'elaborazione dei dati piggyback in Checkmk, consentendo ad esempio di configurare liberamente la durata dei dati. È inoltre possibile estendere il DCD con connettori personalizzati per collegare le proprie fonti di dati, come ad esempio un CMDB. Per rendere tutto ciò ancora più semplice, abbiamo in programma di documentare e migliorare l'API dei plug-in del DCD.

Più opzioni per l'analisi dei problemi di rete

Oltre al monitoraggio dei server, anche il monitoraggio della rete svolge un ruolo importante per i nostri utenti Checkmk. In futuro, come tribe29, vogliamo offrire opportunità ancora migliori per quanto riguarda l'analisi dei problemi di rete. Con la versione 2.0 Checkmk offrirà la possibilità di analizzare i flussi di rete grazie all'integrazione con ntop.

Inoltre, abbiamo già presentato una serie di nuovi check, ad esempio per il monitoraggio delle connessioni VPN che, secondo Lars, sono sempre più richieste a causa degli attuali sviluppi di Covid-19 e della crescente pratica del lavoro da casa. Abbiamo anche aggiunto di recente alcuni nuovi plug-in di controllo e inventario per vari produttori.

Durante la conferenza, Lars ha anche spiegato molte cose sull'automazione all'interno di Checkmk: In futuro, l'Agent Bakery dovrebbe essere in grado di gestire meglio le reti segmentate per risparmiare larghezza di banda. La Distributed Agent Bakery implementa questa funzione. La novità è che non tutti gli agenti aggiornati comunicano con l'agent bakery centrale, ma parlano prima con il rispettivo sito locale. Gli agenti che non esistono nel sito remoto vengono recuperati dall'istanza centrale e messi in cache localmente, se ha senso. Inoltre, abbiamo implementato i bakelet come concetto generale per supportare la distribuzione automatica di dati personalizzati. Finora, le modifiche ai plug-in installati potevano essere distribuite tramite la bakery solo se un bakelet lo supportava. Oltre al plug-in Notification già disponibile per Cisco Webex Teams, è in preparazione un altro plug-in per Microsoft Teams.

Lars ha anche affrontato un altro importante progetto del nostro team di sviluppo di quest'anno: la sostituzione della precedente API Web con un'API REST. In questo caso, le basi tecniche sono già pronte e ora vogliamo riempirle di vita. Christoph Rauch, sviluppatore di Checkmk, ha fornito un approfondimento sulla nuova API REST durante il secondo giorno della conferenza.

Stiamo anche lavorando alla revisione della precedente Check API. Poiché, secondo Lars, si tratta dell'API per plug-in più importante del software di monitoraggio, il primo passo è stato quello di sviluppare un buon concetto. Lo sviluppatore Moritz Kiemer ha anche spiegato come dovrebbe essere la nuova Check API durante il secondo giorno dell'evento. Presto presenteremo le informazioni su questa e sull'API REST qui nel blog.

Migliori prestazioni in Checkmk

Poiché abbiamo numerosi clienti di fascia enterprise in tutto il mondo e più della metà delle società quotate al DAX si affidano a Checkmk per il monitoraggio della loro infrastruttura IT, la scalabilità della soluzione è per noi un must assoluto. Attualmente i cosiddetti processi helper si occupano sia del calcolo dei risultati dei check che della raccolta dei dati grezzi di monitoraggio. Il processo helper di controllo, che richiede molta RAM, deve spesso attendere gli I/O di rete, limitando così la scalabilità degli helper.

Per ridurre la dipendenza dall'I/O di rete, il nostro sviluppo ha diviso il processo helper in due. Dalla versione 2.0, i processi fetcher devono raccogliere i dati di monitoraggio grezzi. Secondo Lars, i fetcher hanno bisogno solo di una piccola quantità di RAM per questo processo. Sono anche in grado di attendere gli I/O di rete. È anche possibile impostare una finestra di timeout per una query. Pertanto, un gran numero di processi Fetcher può essere eseguito in parallelo sul sistema senza richiedere molta RAM come in precedenza, ha spiegato Lars.

Un processo checker valuta quindi i dati raccolti. Questi processi corrispondono agli attuali processi helper, solo che non comunicano, sono legati alla CPU e non dovrebbero consumare più RAM di prima. Poiché non sono più bloccati in cicli di attesa, possono calcolare direttamente i dati grezzi raccolti. Separando il processo helper, consentiamo alle aziende di scalare ulteriormente il monitoraggio con Checkmk, utilizzando il nostro software per sfruttare le risorse hardware esistenti in modo molto più efficiente e con prestazioni migliori.

Oltre allo scaling, abbiamo lavorato anche sul flusso di lavoro per l'attivazione delle modifiche. Finora, per ogni attivazione Checkmk ha impacchettato l'intera configurazione in un'istantanea, l'ha sincronizzata e l'ha spacchettata di nuovo nei siti di monitoraggio desiderati. In futuro accelereremo questo processo facendo in modo che Checkmk sincronizzi la configurazione in modo incrementale quando vengono attivate le modifiche. Per l'utente non cambia nulla in superficie: "sotto il cofano" Checkmk sincronizza solo una frazione dei dati precedenti, poiché trasmette solo le modifiche effettivamente apportate.

Infine, Lars ha illustrato lo stato attuale della migrazione di Python 3 da Checkmk. I nostri sviluppatori sono già sulla buona strada per sostituire il Python 2.7, non più supportato. Tuttavia, poiché Python 3 non è retrocompatibile, i nostri sviluppatori hanno dovuto riprogrammare le oltre 760.000 righe di codice di Checkmk da Python 2.7 a Python 3. "Quindi non basta cambiare cinque righe di codice..." ha scherzato Lars a proposito del carico di lavoro della migrazione. Tuttavia, gli sviluppatori di Checkmk hanno già migrato la base di Checkmk, i plug-in di controllo e molti altri moduli. Inoltre, stiamo già costruendo tutti i nuovi special agent su Python 3. Tuttavia, gli agenti più datati devono ancora essere migrati. I nostri sviluppatori hanno anche completato i primi preparativi per l'interfaccia grafica. Siamo fiduciosi di poter completare la migrazione con la release di Checkmk 2.0.

Presto, nel prossimo articolo dedicato, vi spiegheremo esattamente come immaginiamo che sarà l'integrazione dell'analisi dei flussi di rete di ntop.