Conferenza Checkmk #6: Strada verso la 2.0 e oltre

L'ultima sessione della Checkmk Conference #6 è stata ancora una volta affidata a Lars Michelsen che, in qualità di nostro capo sviluppatore, ha fornito ai partecipanti una panoramica delle innovazioni implementate in Checkmk fino ad oggi e ha presentato la nostra roadmap per Checkmk 2.0 e oltre.

Secondo il nostro capo sviluppatore, siamo a buon punto per Checkmk 2.0, che vorremmo rilasciare in versione stabile in autunno, anche se vi è ancora molto da fare dopo la conferenza. Soprattutto per quanto riguarda la nuova esperienza utente (UX), il progetto presentato da Mathias Kettner nella sua sessione, dobbiamo ancora provare e testare i concetti sviluppati in modo che possano essere inclusi nella versione 2.0, ha spiegato Lars.

Abbiamo già realizzato una prima versione dell'integrazione con Prometheus, che è stata inclusa nel Feature Pack 2 per la versione 1.6. Siamo ansiosi di ricevere i vostri commenti, ad esempio su come ha funzionato l'integrazione di Prometheus in Checkmk e in quali scenari la utilizzate. Solo grazie al vostro feedback potremo continuare a sviluppare Checkmk in base alle vostre esigenze, come sottolineato da Lars.

Per quanto riguarda l'integrazione di ntop, la maggior parte dell'implementazione è stata completata, ma dobbiamo integrare meglio la funzione nel look and feel di Checkmk. Anche le funzioni di avviso non sono ancora state ancora del tutto completate.

Per quanto concerne l'automazione e l'espandibilità di Checkmk, Lars ha tratto una conclusione positiva nel suo intervento. Per la Check-API e le API di programmazione correlate, come l'API dell'inventario, l'API della Agent Bakery e così via, vanno chiariti soltanto alcuni dettagli, prima dell'implementazione. Si aspetta quindi che il lavoro di base sull'API sia completato nelle prossime settimane e che si possa iniziare a migrare i plug-in.

Per quanto riguarda la REST-API, invece, non siamo ancora a buon punto. Abbiamo scelto le basi tecnologiche e implementato alcune importanti call API, ma dobbiamo ancora sviluppare molte altre call API in modo da poter offrire un set di funzionalità utili per Checkmk 2.0. Il nostro obiettivo è quello di poter offrire un servizio di assistenza tecnica di alto livello e di coprire la maggior parte dei casi d'uso della Web-API esistente con la nuova REST-API.

I cambi strutturali devono essere implementati con attenzione

In termini di prestazioni, secondo Lars, in alcuni casi apportiamo modifiche fondamentali ai componenti principali. Ad esempio, la modifica dei processi di helper rappresenta un grave impatto sull'architettura degli helper, e deve essere eseguita con la dovuta attenzione. In questo momento, stiamo ancora ricostruendo e testando molte cose. Lars prevede, tuttavia, che presto saremo in grado di iniziare a collegare i nuovi helper al Micro Core e a maggio o giugno di valutare se le nuove funzionalità forniranno anche l'aumento di prestazioni previsto.

Abbiamo anche quasi completato il lavoro preparatorio sulla questione dell'Attivazione delle modifiche, in modo da poter presto incorporare una sincronizzazione incrementale della configurazione nelle configurazioni di monitoraggio distribuite.

Lars ha riferito che abbiamo implementato i check previsti per la versione 2.0. Nelle prossime settimane e fino al rilascio di Checkmk 2.0, tuttavia, potrebbero essere aggiunti diversi check su input degli ordini dei clienti.

Il ritorno dell'Innovation Release

Lars ha parlato anche delle modifiche al nostro ciclo di rilascio - i nuovi Feature Pack. Vogliamo rendere disponibili a tutti gli utenti di Checkmk le funzioni utili che abbiamo già completato in una versione stabile. Forniamo le funzioni come MKP, che sono disattivate in Checkmk per impostazione predefinita. Nella Enterprise Edition, le funzioni desiderate possono essere attivate o disattivate tramite WATO. Gli utenti della Raw Edition possono attivare le funzioni tramite la CLI.

Lars ha parlato anche delle nostre Innovation Release. In passato le abbiamo utilizzate per rendere testabili grandi funzionalità per i nostri utenti, durante il periodo dello sviluppo. Come ha spiegato Lars, queste innovation release sono un ottimo strumento per ottenere un feedback dagli utenti di Checkmk prima della fase beta e, allo stesso tempo, per dare loro un'anteprima delle funzioni in arrivo. Abbiamo pianificato una innovation release per la versione 2.0.

Abbiamo già introdotto due pacchetti di funzioni per Checkmk 1.6. Tuttavia, non è ancora chiaro se ne rilasceremo anche un terzo. "A seconda delle nuove funzioni disponibili, potrebbe esserci anche un terzo feature pack per la versione 1.6 in estate", ha dichiarato Lars. Ciò che è certo, tuttavia, è che vogliamo iniziare a rilasciare innovazioni per Checkmk 2.0 all'inizio dell'estate. Per noi questo significa che, a questo punto, dovremo aver già implementato la maggior parte delle funzioni, ma non aver ancora effettuato il feature freeze. Ciò ci consentirebbe di apportare ulteriori modifiche alle funzioni in questa fase, se necessario.

Il blocco delle funzioni per la versione 2.0 è quindi previsto per l'estate, in modo da poter procedere in modo intensivo con i test. Poiché stiamo apportando numerosi cambiamenti su larga scala a Checkmk con la migrazione a Python 3, l'introduzione del nuovo design UX, nonché la nuova REST-API, la nuova Check-API e l'helper split, vogliamo che il processo di test per la versione 2.0 sia significativamente più completo rispetto alle versioni precedenti per garantire una elevata stabilità, come rimarcato da Lars.

Per questo abbiamo bisogno anche di voi, la nostra comunità. A questo punto Lars ha rinnovato la richiesta ai partecipanti e agli utenti di Checkmk di utilizzare le opzioni di test e di inviarci i loro feedback. Vi informeremo poi, attraverso i nostri consueti canali, su quando inizieremo le varie fasi di test.

Checkmk 2.1

Inoltre, Lars ci ha anche illustrato le idee e i progetti che abbiamo già in cantiere per la versione 2.1. Un tema importante dopo la 2.0 è ancora il miglioramento dell'esperienza utente. Sebbene nella versione 2.0 siano stati ridisegnati i flussi di lavoro e gli elementi più importanti di Checkmk, il prossimo passo, secondo Lars, sarà quello di rendere le finestre di dialogo e le viste dettagliate più coerenti e intuitive per gli utenti. Vogliamo anche continuare a ottimizzare le dashboard e i report, continuando il percorso iniziato con la versione 2.0.

Un altro punto cruciale è l'espansione del monitoraggio degli ambienti cloud. Abbiamo già fornito integrazioni per Azure e AWS. In futuro verrà aggiunta un'integrazione per Google Cloud Platform (GCP). Come già facciamo con Azure e AWS, questa integrazione sarà effettuata da uno special agent e consentirà il monitoraggio dei servizi più importanti. Vogliamo anche ampliare il nostro portafoglio esistente per quanto riguarda Azure e AWS in base alle esigenze della comunità.

Approfondiremo anche l'integrazione con Prometheus. Con Checkmk 2.0 siamo già in grado di integrare i principali exporter. In futuro, vogliamo anche espandere gradualmente il numero di exporter in base alle richieste di funzionalità, ed essere in grado di connetterci agli exporter di Prometheus direttamente con Checkmk senza dover passare per Prometheus stesso.

2.000 plug-in e autenticazione a due fattori

Allo stesso tempo, l'obiettivo della 2.1 è quello di completare la REST-API introdotta con la 2.0, in modo che possa mappare tutte le funzioni di Checkmk. Vogliamo anche portare avanti i miglioramenti delle prestazioni che sono già stati avviati. Nella suo discorso, Lars ha parlato anche dello sviluppo di nuovi plug-in. Il nostro obiettivo è quello di implementare ulteriormente i desideri dei clienti e della comunità.

Per quanto riguarda la sicurezza di Checkmk, secondo Lars si sta pensando di introdurre l'autenticazione a due fattori per proteggere ulteriormente il login. Ad esempio, ciò potrebbe avvenire sotto forma di implementazione di un'autenticazione a due fattori opzionale che supporti lo standard U2F sulla GUI. Stiamo anche valutando se Checkmk stesso debba fornire un server di convalida locale su cui registrare il token per la 2FA. In una fase successiva, la connessione di server di convalida a livello enterprise potrebbe essere un'opzione.

Monitoraggio dei moderni hypervisor e monitoraggio E2E

Lars ha inoltre trattato un'ampia gamma di argomenti, che abbiamo intenzione di affrontare in futuro. Ad esempio, il monitoraggio dei moderni hypervisor. Il mondo della containerizzazione si sta avvicinando sempre di più al mondo della virtualizzazione, come ha sottolineato Lars con l'esempio di VMware vSphere 7. Egli ipotizza che altri hypervisor seguiranno questo sviluppo. Con Checkmk è possibile monitorare molto bene gli ambienti container e gli hypervisor, ma vogliamo anche continuare a monitorare in modo ottimale gli ambienti 'merged' ed essere in grado di fornire informazioni utili su condizioni e relazioni.

Per quanto riguarda il cloud, Checkmk è stato finora in grado di monitorare tutto ciò che i nostri utenti fanno nel cloud. Vogliamo però considerare anche come, in futuro, poter facilitare migliori implementazioni di Checkmk nel cloud. Un'idea che Lars ha condiviso è, ad esempio, la fornitura di immagini standard sulle grandi piattaforme cloud come GCP, AWS e Azure, in modo che l'utente possa lanciare un'istanza Checkmk su una piattaforma semplicemente premendo un pulsante.

Lars ha anche approfondito il tema del monitoraggio end-to-end, su cui vogliamo concentrarci in futuro. Sulla base del modello ntop, Lars ha menzionato la possibilità di fornire integrazioni ragionevoli a questo scopo, supportate ad esempio attraverso articoli nella nostra guida utente, tutorial o integrazioni nei prodotti. L'obiettivo è quello di consentire l'esecuzione di un monitoraggio end-to-end con Checkmk al centro.

Più intelligenza e automazione in Checkmk

Lars ha parlato molto anche delle "dipendenze automatizzate". La fusione delle informazioni dovrebbe aiutare a mostrare le dipendenze nell'IT, per aiutare l'utente a risolvere i problemi più velocemente, ad esempio.

Attualmente stiamo immaginando l'argomento come un puzzle composto da molte fonti di informazioni sulle interrelazioni tra servizi, sistemi o singole applicazioni. In futuro vogliamo riunire queste informazioni e costruire un modello in grado di rappresentare queste dipendenze e le loro conseguenze per il sistema nel suo complesso. Sulla base di questo modello, con tutte le informazioni relative alle dipendenze, Checkmk dovrebbe aiutare l'utente a comprendere più facilmente la complessità dell'IT e a risolvere i problemi più rapidamente. I problemi a cascata possono così essere identificati e risolti in una fase iniziale, prima che diventi molto difficile farlo. Inoltre, questo renderebbe possibile evitare allarmi inutili. Vogliamo portare il ben noto concetto di "Service Dependencies" in Nagios molto più avanti, poiché molte dipendenze possono essere riconosciute automaticamente, in particolare attraverso le informazioni di rete.

Inoltre, vogliamo continuare a lavorare sul tema degli 'Analytics' in Checkmk. Da un lato, Checkmk dovrebbe rilevare automaticamente le anomalie e presentarle all'utente. Dall'altro, se si verifica un'anomalia in un servizio, Checkmk dovrebbe mostrare automaticamente altri servizi con un comportamento simile. Poiché tale correlazione non deve necessariamente essere una connessione causale, il collegamento con le "dipendenze" rende questa analisi davvero potente. Per questo motivo vediamo i due argomenti "Analisi" e "Dipendenze" come strettamente collegati e complementari tra loro. Insieme, entrambi gli strumenti consentono all'utente di avere una visione senza precedenti del pool di dati di monitoraggio e aiutano a trovare più rapidamente la radice di un problema.

Lontano dal classico approccio SNMP?

Lars ha parlato anche dell'evoluzione del monitoraggio di rete, che si sta allontanando dal classico approccio SNMP. L'approccio attuale prevede che Checkmk invii regolarmente polls ai dispositivi per conoscere il loro stato attuale. Questo ha il vantaggio di mantenere uno stato definito in un momento specifico dell'interrogazione. Lo svantaggio, tuttavia, è che i pollings generano un carico continuo sui sistemi. Inoltre, non è chiaro cosa succeda tra le interrogazioni sul sistema. Quest'ultimo aspetto può essere risolto con le trap SNMP, che inviano informazioni basate su eventi al sistema di monitoraggio, ma che presentano i loro problemi.

Alcuni produttori di hardware stanno attualmente promuovendo la telemetria in streaming come alternativa all'SNMP sulle loro piattaforme. Essa comprende vari protocolli e API con l'obiettivo di combinare i vantaggi del polling e del monitoraggio basato sugli eventi. Un altro vantaggio della telemetria in streaming è che i protocolli preparano i dati in modo moderno, in modo da renderli disponibili in un formato neutro. Questo potrebbe consentire a Checkmk di ottenere informazioni più velocemente e quindi di diventare più performante, ad esempio. Secondo Lars, continueremo a occuparci di argomenti che semplificano e migliorano ulteriormente il lavoro di e con Checkmk.

Riassumendo: per Lars, l'anno prossimo avremo in agenda molti argomenti che vogliamo affrontare insieme a voi. Durante la conferenza, voi utenti avete fatto ampio uso della votazione sui punti sollevati da lui sollevati. Come sempre, incorporeremo i risultati di questi vostri feedback nella roadmap di sviluppo. Abbiamo ancora molto in cantiere per Checkmk. Potete essere entusiasti!