Conferenza Checkmk #7, Giorno 2 - Sguardo ravvicinato a Checkmk 2.1

Dopo aver parlato dello stato attuale di Checkmk 2.0 nel primo giorno della Checkmk Conference #7, il secondo giorno dell'evento si è concentrato sullo sviluppo futuro di Checkmk. Durante le presentazioni della conferenza, i partecipanti hanno avuto la possibilità di influenzare lo sviluppo di Checkmk votando su potenziali modifiche, funzionalità, miglioramenti, ecc.

Il programma delle presentazioni del secondo giorno è stato inaugurato da Simon Meggle di Elabit e Jens Dunkelberg di Abraxas Informatik AG, che nella loro sessione tecnica hanno spiegato il monitoraggio end-to-end con Checkmk utilizzando il plug-in Robotmk. Simon ha sviluppato Robotmk come ponte tra Robot Framework e Checkmk. Ciò consente di integrare in Checkmk i risultati di Robot Framework, uno strumento open source per il test automatico delle applicazioni. In questo modo, Robotmk estende il monitoraggio IT di Checkmk con il monitoraggio end-to-end, cioè il monitoraggio dell'esperienza dell'utente quando interagisce con l'infrastruttura IT.

Secondo Simon, Checkmk è ideale per monitorare l'infrastruttura IT e quindi garantire che anche le applicazioni che vi girano sopra, come ad esempio un web store, funzionino senza problemi. Tuttavia, Checkmk non può monitorare il modo in cui l'utente interagisce con il web store. Questo può essere fatto dallo strumento open-source Robot Framework con i suoi test automatici. Simon ha spiegato come l'integrazione di Robot Framework in Checkmk renda ora possibile monitorare anche la vista dell'utente in Checkmk.

Abraxas Informatik AG utilizza già il plug-in Robotmk per il monitoraggio end-to-end delle applicazioni del governo svizzero. Jens ha spiegato ai partecipanti come funziona Robotmk nella pratica e quali funzionalità può fornire.

Nella sessione tecnica, Simon ha anche fornito una descrizione più dettagliata delle funzionalità del plug-in, come l'estrazione delle metriche in modo che Checkmk possa mostrare le prestazioni di un'applicazione. Poiché il Robot Framework mostra solo se un test è riuscito o fallito, ma non lo stato e le prestazioni dell'applicazione, si tratta di un'estensione utile.

L'interfaccia utente sarà ulteriormente ottimizzata

Nella prima presentazione della giornata sul palco principale, il fondatore di tribe29 Mathias Kettner ha illustrato i prossimi cambiamenti previsti per l'interfaccia utente di Checkmk. Con il lancio della versione 2.0, Checkmk ha ricevuto un'interfaccia utente e una navigazione completamente ridisegnate. Il team di sviluppo sta attualmente lavorando a ulteriori miglioramenti della nuova UX.

I quattro nuovi elementi della dashboard introdotti con Checkmk 2.0 saranno integrati da quattro ulteriori dashboard incluse nel prossimo pacchetto di funzionalità. Tra le altre cose, queste mostreranno se lo stato di un host o di un servizio è OK, WARN o CRIT, oppure quanti host o servizi sono OK, WARN o CRIT. Sono previsti anche un esagono per le statistiche degli eventi e un dashlet dell'inventario che visualizza le informazioni dell'inventario, ad esempio il numero di core della CPU disponibili.

I partecipanti potrebbero votare un elemento a ciambella come alternativa al dashlet dell'indicatore, oppure un intervallo di tempo come grafico a barre con funzione di drill-down. Mathias ha anche presentato possibili estensioni dell'esagono ospite, ad esempio per il clustering o per incorporare una mappa nella dashboard.

Altri piani per l'ulteriore sviluppo dell'UX includono l'implementazione di dashboard specifiche per le applicazioni, ad esempio per i server Linux e Windows o per gli ambienti vSphere, ha spiegato Mathias. Le dashboard conterranno le metriche più importanti e fornire una panoramica utile.

Altre possibili innovazioni presentate da Mathias sono mini-dashboard opzionali integrate nella vista host. Queste sono destinate a fornire informazioni aggiuntive utili sul rispettivo host. Anche l'idea che gli utenti di Checkmk possano condividere le proprie dashboard come file MKP attraverso l'Exchange è stata ben accolta dai partecipanti. Il pubblico ha risposto positivamente anche all'idea di condividere le dashboard tramite un URL, ad esempio per la visualizzazione su uno schermo a parete.

Oltre al miglioramento della dashboard di Checkmk, è necessario migliorare anche l'uso delle singole pagine di Checkmk. Ciò include innanzitutto una strutturazione più chiara delle pagine più utilizzate e la semplificazione dei flussi di lavoro associati. Un'opzione che Mathias ha mostrato, ad esempio, è quella di finestre pop-up con suggerimenti per le azioni.

Facendo clic sul pulsante Attiva modifiche, ad esempio, viene generato un pop-up che mostra dove vengono apportate le modifiche. Inoltre, un pop-up presenta il vantaggio di poter attivare le modifiche senza dover lasciare la pagina corrente. Un'altra possibile miglioria è che Checkmk suggerisca le fasi successive, come il passaggio alla visualizzazione host. Infine, un ulteriore modo per semplificare i flussi di lavoro sarebbe che Checkmk verificasse quali protocolli o agenti siano in esecuzione sul sistema dopo aver inserito l'IP o il DNS al momento di aggiungere un host, e quindi suggerisse una configurazione predefinita per l'host.

Un altro argomento affrontato da Mathias nella sua presentazione è stata la revisione della struttura delle cartelle. Con una nuova gestione delle cartelle, soprattutto la panoramica in ambienti di grandi dimensioni con molte cartelle dovrebbe diventare migliore. Una considerazione, ad esempio, è la visualizzazione delle cartelle in una tabella. Facendo clic su una cartella, si potrebbe vedere quali sottocartelle e/o host contiene e quali attributi e regole si applicano alla cartella. I piani per la nuova gestione delle cartelle hanno riscosso grande consenso tra i partecipanti.

Monitoraggio dal cloud con Checkmk

Un altro importante punto all'ordine del giorno per l'ulteriore sviluppo di Checkmk è l'espansione dell'attuale monitoraggio del cloud ibrido. Nella sua presentazione, Thomas Lippert, Product Manager di tribe29, ha illustrato le quattro aree su cui si concentra attualmente l'attenzione. Si tratta di migliorare l'esperienza cloud-native rendendo più semplice l'impostazione di Checkmk nel cloud e semplificando la configurazione in modo che le risorse on-premise possano essere monitorate più facilmente dal cloud. Inoltre, secondo Thomas, è stata migliorata la gestione dei carichi di lavoro dinamici e ampliato il numero di servizi cloud che possono essere monitorati da Checkmk.

In futuro, sarà possibile ottenere Checkmk tramite il Marketplace di AWS e successivamente anche direttamente su Microsoft Azure. L'immagine di Checkmk può essere configurata come istanza EC2 nel cloud in pochi minuti. Le licenze per AWS possono essere concesse tramite licenza "bring-your-own-license" o tramite licenza di piattaforma. L'istanza di monitoraggio è inoltre già preconfigurata per l'uso sicuro del cloud, ha sottolineato Thomas.

Una volta configurato, Checkmk dovrebbe consentire di monitorare dal cloud sia gli asset in cloud che quelli on-premise. Tuttavia, questo richiede di cambiare la direzione in cui l'agente trasmette i dati, ha spiegato Thomas. Il "Push Agent" sviluppato a questo scopo raccoglierà i dati di monitoraggio e poi li trasmetterà al server di monitoraggio per evitare problemi di firewall. Il trasferimento dei dati al cloud è criptato tramite TLS. Checkmk comprime inoltre i dati per ridurre al minimo i costi di trasferimento nel cloud. Per una maggiore economia dei dati, anche la tariffa standard per il "data push" deve essere ridotta.

Per i dispositivi in sede, come quelli SNMP, sui quali non è possibile installare un agente, è prevista l'introduzione di un proxy SNMP locale nell'ambiente di rete. Questo proxy 'Checkmk Light' si occupa del monitoraggio attivo dei componenti SNMP, compresa l'elaborazione dei trap SNMP. Il proxy SNMP trasmette poi i risultati aggregati al cloud.

Per monitorare i carichi di lavoro dinamici nel cloud, questi devono essere in grado di registrarsi con Checkmk, che li aggiunge automaticamente al monitoraggio. In base alla configurazione, alle etichette e alle regole applicative, Checkmk assegna questi host a una cartella e applica le regole impostate sulle cartelle. I servizi sull'host verranno rilevati automaticamente.

Inoltre, il monitoraggio dei servizi cloud sarà ulteriormente ampliato. Per AWS, questo potrebbe includere AuroraDB, DocumentDB, SQS e Lambda. I partecipanti hanno votato anche per la possibilità di monitorare AWS ECS, AWS Health o AWS Route 52 con Checkmk.

Per Azure, il monitoraggio deve essere esteso ai servizi Database for PostgreSQL/MySQL, CosmosDB, Service Bus e Load Balancer. I partecipanti alla conferenza hanno richiesto anche il monitoraggio dei servizi Service Health e Traffic Manager.

Integrazioni, automazione e sicurezza per il mondo IT ibrido

La vita quotidiana delle organizzazioni con grandi infrastrutture IT è oggi determinata prevalentemente da carichi di lavoro dinamici ed estesi. Per far fronte a queste esigenze, esse dipendono sempre più dall'automazione IT. Ciò è spesso reso più difficile dalla grande varietà di strumenti utilizzati, sia per il monitoraggio generale, ad esempio con Checkmk, sia per strumenti speciali per applicazioni, cluster o Kubernetes. Allo stesso tempo, gli incidenti di sicurezza che hanno attirato l'attenzione dei media hanno aumentato la consapevolezza della sicurezza informatica e dei relativi prodotti nelle aziende, come ha spiegato Lars Michelsen, responsabile dello sviluppo di tribe29, nella sua presentazione "Integrazioni, automazione e sicurezza".

Lars ha inoltre spiegato che questo è il motivo per cui tribe29 continuerà a concentrarsi sull'integrazione degli strumenti di osservabilità e dell'IT aziendale, sull'automazione del monitoraggio e sulla sicurezza dei prodotti nell'ulteriore sviluppo di Checkmk.

Secondo Lars, esistono due opzioni per integrare altri strumenti: Esportare i dati di monitoraggio in un altro strumento, come Checkmk fa già con Grafana, ad esempio, oppure integrare i dati di altri strumenti in Checkmk, come è previsto con la nuova interfaccia con DataDog. Checkmk integra già i dati di strumenti come ntop, Prometheus, Grafana o InfluxDB. Per Checkmk 2.1, la roadmap prevede la revisione delle integrazioni esistenti, come quelle per Grafana o InfluxDB, ma anche la creazione di nuove interfacce.

Grafana: L'integrazione con Grafana deve essere modernizzata e adattata alla nuova API di Grafana. Inoltre, in futuro il plug-in dell'origine dati sarà disponibile nello store di Grafana per semplificarne l'installazione. Le nuove funzioni includono l'autenticazione da parte del server di Grafana, le annotazioni ed eventualmente la trasmissione di variabili.

InfluxDB: è previsto che con la nuova versione di Checkmk sarà possibile estendere l'esportazione di metriche affidabili a InfluxDB. Attualmente Checkmk utilizza ancora la vecchia connessione Carbon basata su UDP. Tuttavia, in futuro l'esportazione dei dati passerà all'API nativa di InfluxDB per poter utilizzare HTTP(S) per il trasferimento. Secondo Lars, questo renderà possibile anche la trasmissione di metadati aggiuntivi come soglie, stati, etichette o tag. Dovrebbe anche essere possibile configurare tramite regole le metriche che si desidera esportare in InfluxDB. Sarebbe quindi possibile estendere questo principio anche a sistemi simili, come Splunk o Elastic.

DataDog: L'interfaccia creata di recente per DataDog ha lo scopo di consentire alle organizzazioni che utilizzano anche DataDog oltre a Checkmk di integrare i dati di monitoraggio provenienti da DataDog, come stati ed eventi, per poi gestirli come di consueto in Checkmk, ad esempio per ricevere allarmi e notifiche. Anche in questo caso, dovrebbe essere possibile specificare quali dati Checkmk deve integrare da DataDog, in modo da avere a disposizione in Checkmk solo i dati rilevanti.

Per quanto riguarda l'ulteriore automazione del monitoraggio con Checkmk, i nostri sviluppatori stanno attualmente lavorando all'obiettivo di mappare un ciclo completo di distribuzione e configurazione con Checkmk. Dovrebbe essere possibile impostare il monitoraggio di Checkmk in modo automatico fino a un certo punto, mentre la messa a punto sarà ancora gestita manualmente. Secondo Lars, la nuova API REST introdotta con la versione 2.0 svolge un ruolo importante nei processi successivi alla configurazione dell'istanza. Attualmente, i set di regole non sono ancora mappati nell'API, ma ciò dovrebbe essere possibile a partire dalla versione 2.1. Inoltre, è prevista la connessione automatica di siti remoti. Lars ha aggiunto che è in programma anche l'aggiunta di un livello di astrazione all'API REST. Questo dovrebbe facilitare l'aggiunta di ulteriori API all'API REST, ad esempio per effettuare chiamate API per eseguire determinate azioni, come la creazione di un host o l'esecuzione di determinate funzioni.

Per una maggiore sicurezza, è prevista la crittografia dei dati trasmessi dagli agenti. Pertanto, il Push Agent progettato utilizzerà la crittografia TLS per impostazione predefinita. La crittografia simmetrica attualmente facoltativa degli agenti Pull funzionerà su TLS come standard a partire dalla versione 2.1. Secondo Lars, tuttavia, l'introduzione di funzioni di sicurezza è sempre un gioco di equilibri tra sicurezza e usabilità. L'obiettivo, tuttavia, è quello di mantenere semplice l'impegno e la complessità di Checkmk nonostante l'aumento della sicurezza, ha spiegato. Gli utenti dell'Enterprise Edition, ad esempio, dovrebbero utilizzare l'Agent Bakery per la distribuzione e devono solo configurare un plug-in Bakery aggiuntivo. L'impegno manuale per gli utenti della Raw Edition, tuttavia, aumenterà leggermente a causa di queste nuove funzionalità di sicurezza.

Poiché molte organizzazioni utilizzano soluzioni di autenticazione centralizzate come SSO o 2FA, vogliamo renderle disponibili anche per Checkmk. Con la versione 2.0, ad esempio, Checkmk è già predisposto per l'utilizzo di SAML; una connessione ad Azure AD potrebbe essere un altro esempio per la connessione di tali soluzioni centrali.

Monitoraggio di Kubernetes – orientarsi nella giungla dei dati

Un argomento che ha sempre avuto un ruolo importante nelle conferenze degli ultimi anni è stato quello che non abbiamo potuto evitare anche nella conferenza di quest'anno: Il monitoraggio di Kubernetes. Come ha sottolineato Martin Hirschvogel di tribe29 nella sua presentazione, ciò è dovuto principalmente al crescente utilizzo dei container negli ambienti di produzione. Questi container sono per lo più orchestrati tramite Kubernetes. Questo sviluppo significa che i requisiti per il monitoraggio delle infrastrutture IT stanno contemporaneamente aumentando. Dopo tutto, oltre ai classici componenti IT, deve essere monitorato anche il crescente numero di container, cluster, pod, ecc.

Dal 2018, Checkmk può monitorare Kubernetes tramite l'API Kubernetes. Questo ha il vantaggio che il monitoraggio è facile da impostare e che è già possibile ottenere una buona visione dello stato di salute dei cluster con i dati disponibili tramite l'API e con le informazioni fornite dall'agente con Checkmk. L'integrazione con Prometheus ha aggiunto un'altra opzione per il monitoraggio di pod e container. In particolare, le aziende che già utilizzano Prometheus per il monitoraggio di Kubernetes possono ridurre il carico di lavoro sugli host monitorati, evitando che due strumenti di monitoraggio utilizzino gli stessi dati. Entrambe le opzioni saranno ulteriormente ampliate e ottimizzate dagli sviluppatori di Checkmk.

Secondo Martin, è proprio la grande complessità di Kubernetes che rende difficile per gli amministratori sapere quali informazioni sono rilevanti per loro, data l'abbondanza di dati. Di conseguenza, c'è il rischio che il sovraccarico di dati travolga rapidamente gli utenti. Tuttavia, uno dei punti di forza di Checkmk è stato quello di fornire sempre le informazioni più rilevanti tra l'abbondanza di dati.

Per semplificare il monitoraggio di Kubernetes, il primo passo è rendere più facile la configurazione e l'installazione di Checkmk. A questo scopo, tribe29 rende disponibili tutte le edizioni di Checkmk nel registro Docker. Inoltre, i manifesti predefiniti e i diagrammi di helm consentono la distribuzione e l'aggiornamento in un solo clic. Checkmk Enterprise Edition e Checkmk Trial sono già disponibili nel registro.

Anche la preparazione del cluster Kubernetes per il monitoraggio dovrebbe diventare più semplice. Ciò sarà possibile da un lato con un nuovo agente per Kubernetes e dall'altro attraverso un rollout con manifesti predefiniti e diagrammi di helm. Tra le altre cose, sono previsti flussi di lavoro guidati che includono una configurazione preconfigurata e dinamica con cartelle per facilitare la configurazione. Sono in programma anche una denominazione robusta per tutti gli oggetti ed etichette coerenti per i filtri, la visualizzazione e gli allarmi.

Il monitoraggio stesso dovrebbe essere semplice anche per i non professionisti di Kubernetes. Il nuovo agente Kubernetes dovrebbe fornire agli utenti una panoramica immediata della salute e delle prestazioni dei loro cluster e dei loro componenti. Il debugging dei problemi è possibile, ad esempio, tramite drill-down. Le dashboard predefinite hanno lo scopo di aiutare gli utenti a monitorare diversi aspetti e diversi requisiti dell'ambiente Kubernetes, come il cluster, la rete o l'infrastruttura applicativa. Inoltre, ognuna di queste dashboard predefinite dovrebbe includere tutti i dati importanti per il rispettivo caso d'uso, in modo che anche gli utenti meno esperti possano ottenere immediatamente una buona panoramica dello stato del loro monitoraggio di Kubernetes.

In futuro ci sarà un pod con un agente K8s su ogni nodo worker che raccoglie i dati per il monitoraggio di Kubernetes con Checkmk. Un agente aggiuntivo sul cluster è responsabile della strutturazione di questi dati e funge da gateway per il server Checkmk.

La roadmap per le versioni 2.1 e 2.2

Alla fine del secondo e ultimo giorno di conferenza, Thomas e Lars hanno nuovamente riassunto tutti i cambiamenti previsti e hanno spiegato quali funzionalità saranno disponibili in Checkmk 2.1 e 2.2. Il rilascio della nuova versione 2.1 del prodotto è attualmente previsto per la fine del 2021. Prima di allora, tuttavia, sarà disponibile un pacchetto di funzionalità per la versione 2.0.

Tra gli altri sviluppi, Checkmk 2.1 sarà disponibile come immagine macchina di Amazon e forse anche come immagine standardizzata per Azure. In questo modo, vogliamo semplificare il monitoraggio in-cloud delle risorse cloud, come ha spiegato Thomas. Parte della release dovrebbe essere anche il nuovo Push Agent per le piattaforme Linux e Windows. Non è ancora prevedibile se il supporto per il monitoraggio dei carichi di lavoro creati dinamicamente sarà già possibile con la versione 2.1. Inoltre, il monitoraggio del cloud sarà esteso ad altri servizi Azure e AWS con la prossima release. Nel farlo, terremo conto anche del feedback dei partecipanti alla conferenza di quest'anno", ha affermato Thomas.

L'estensione dell'agente Push ad altre piattaforme è prevista per Checkmk 2.2. Il proxy on-premises, che raccoglie i dati SNMP in un ambiente e li trasmette al cloud, ad esempio, farà parte di Checkmk.

Per quanto riguarda il monitoraggio di Kubernetes, per la versione 2.1 è previsto un agente Kubernetes dedicato, che raccoglierà i dati di monitoraggio nell'ambiente Kubernetes e li aggregherà in modo significativo. È prevista anche una dashboard del cluster per fornire una panoramica di tutte le metriche importanti. Con la versione 2.1, Checkmk supporterà inizialmente Vanilla Kubernetes, ma in futuro verranno aggiunte altre distribuzioni come EKS o OpenShift.

Per la versione 2.2 sono previsti altre dashboard standard, come quelli dedicate alla distribuzione o a un nodo. Inoltre, è prevista una revisione dell'integrazione con Prometheus, in modo che Prometheus trasmetta a Checkmk gli stessi dati dell'agente Kubernetes. In questo modo, gli utenti dovrebbero essere liberi di scegliere la propria fonte di dati, ma ricevere alla fine lo stesso risultato. Tra gli altri argomenti della roadmap figurano anche il monitoraggio degli eventi e l'impostazione automatica del monitoraggio di Kubernetes.

Per quanto riguarda le dashboard, con la versione 2.1 saranno disponibili nuove opzioni di visualizzazione, come lo stato degli host e dei servizi, i dati di inventario, ecc. Inoltre, sono previste dashboard specifiche per le applicazioni Linux, Windows e vSphere, nonché miglioramenti alla funzionalità delle dashboard sensibili al contesto.

In linea di principio, Checkmk 2.1 dovrebbe anche migliorare ulteriormente l'interfaccia utente. Ciò significa che le pagine utilizzate più di frequente diventeranno più chiare e comprensibili. Allo stesso tempo, vogliamo rivedere i flussi di lavoro, ad esempio quelli per l'attivazione delle modifiche.

Le già citate modifiche alle integrazioni sono già state pianificate per la versione 2.1. Tra queste, la nuova interfaccia DataDog per l'importazione dei dati in Checkmk, la revisione dell'integrazione di Grafana, che sarà adattata alle nuove API, e l'integrazione nativa di InfluxDB.

Vogliamo inoltre offrire Checkmk in più lingue. I primi pacchetti linguistici sono già disponibili in Exchange. La versione iniziale delle traduzioni è stata realizzata con l’assistenza di strumenti automatici. Per la versione finale, tuttavia, invitiamo a collaborare anche la comunità.

Nella seconda parte della presentazione della roadmap, Lars ha approfondito le idee e le possibili direzioni di sviluppo di Checkmk a lungo termine. Anche in questo caso i partecipanti alla conferenza hanno avuto l'opportunità di votare la direzione preferita. I quattro argomenti principali sono stati l'estensione del monitoraggio delle applicazioni, la gestione dei log, il rilevamento delle dipendenze e delle correlazioni e il monitoraggio E2E con Robotmk.

È possibile guardare le presentazioni della Checkmk Conference #7 sul nostro canale YouTube.