Monitoraggio di Docker

Naturalmente l'aspetto interessante è il monitoraggio dei Docker container, che verrà implementato automaticamente con l'installazione dei plug-in, tuttavia i servizi non saranno assegnati al nodo Docker, piuttosto Checkmk ipotizza un singolo host per ogni container Docker.

Il meccanismo utilizzato in questo caso è chiamato piggyback: il plug-in o lo special agent trasporta i dati di altri host - per così dire "piggyback" - insieme ai propri dati. Checkmk colloca questi dati nella directory tmp/check_mk/piggyback. Tutto ciò che devi fare nel Setup è creare host con i nomi corretti e i servizi saranno assegnati automaticamente a questi.

Nelle edizioni commerciali puoi fare in modo che questi host vengano creati automaticamente. Utilizza il connettore Piggyback nella configurazione dinamica. Tieni presente quanto segue, se crei gli host manualmente:

Una volta creati gli host dei container e dopo aver eseguito la scoperta del servizio, su questi appariranno nuovi servizi.

Tuttavia, poiché molti servizi monitorati dall'agente di monitoraggio all'interno dei container mostrano in realtà informazioni provenienti dal nodo (ad esempio il carico della CPU, la temperatura e molti altri parametri del sistema operativo), questi sono stati rimossi.

Per impostazione predefinita, come già detto, l'ID breve di 12 caratteri del container viene utilizzato come nome host del container. Questo può essere configurato in modo diverso. Per farlo, nel file di configurazione docker.cfg (vedi Messa a punto del plug-in) imposta l'opzione container_id su long per utilizzare l'ID completo del container come nome, oppure su name per utilizzare il nome del container.

Gli utenti delle edizioni commerciali possono impostarlo nell'Agent bakery utilizzando la regola Docker node and containers, opzione Host name used for containers.

Per inciso: Con il set di regole Access to agents > General settings > Hostname translation for piggybacked hosts puoi definire regole abbastanza flessibili per rinominare i nomi host contenuti nei dati piggyback. Con questo metodo puoi anche risolvere il problema di avere container con lo stesso nome su due nodi Docker diversi, ad esempio.

Per ulteriori opzioni e una descrizione più dettagliata di questa funzione, consulta l'articolo Il meccanismo del piggyback.

Poiché non è possibile verificare lo stato dell'host di un container utilizzando i pacchetti TCP o ICMP, è necessario determinarlo in un altro modo. Il servizio Docker container status facilita questo compito: in ogni caso controlla se il container è in esecuzione e può quindi essere utilizzato come strumento sicuro per rilevare lo stato dell'host. Definisci un set di regole nel set di regole Host Check Command a questo scopo e imposta l'opzione Use the status of the service…​ sul servizio menzionato. Non dimenticare di impostare le condizioni in modo che siano interessati solo i container. Nel nostro esempio tutti i container si trovano in una cartella con lo stesso nome:

Per monitorare i dettagli nel container stesso (es. processi in esecuzione, database, file di log, ecc.), è necessario che l'agente Checkmk sia installato ed eseguito nel container stesso. Questo vale soprattutto per il roll-out dei plug-in dell'agente. I tre plug-in mem, cpu e diskstat (Disk I/O) funzionano però senza un agente nel container e vengono analizzati dall'agente Checkmk sul nodo stesso.

Soprattutto per le immagini Docker auto-create, potresti voler installare l'agente stesso nel container. In questo caso i dati non vengono più analizzati, come descritto sopra, dall'agente del nodo Docker. Al posto di questo, un agente separato viene eseguito in ogni container. La chiamata di questo agente verrà comunque eseguita in una procedura di piggyback tramite il nodo Docker.

Tuttavia, l'agente installato nel container funziona solo se tutti i comandi necessari sono presenti anche nel container. Soprattutto con i container minimamente integrati, basati su Docker container e Linux, è possibile che elementi come Bash non siano presenti. In una situazione del genere, dovresti monitorare il container dal nodo Docker.

In questo caso, l'uso del set di regole Host Check Command sarà necessario solo se il container non è pingabile, ma altrimenti funzionerà esattamente come descritto sopra.