Monitoraggio di Docker

Naturalmente l’aspetto interessante è il monitoraggio dei Docker container. Questo verrà implementato automaticamente durante l’installazione dei plug-in, tuttavia i servizi non verranno assegnati al nodo Docker, ma Checkmk presuppone un singolo host per ogni Docker container.

Il meccanismo utilizzato in questo caso si chiama piggyback: Il plug-in o l’special agent trasporta i dati di altri host — “piggyback”, per così dire — insieme ai propri dati. Checkmk colloca questi dati nella directory ~/tmp/check_mk/piggyback. Tutto quello che devi fare nel Setup è creare host con i nomi corretti, e i servizi verranno poi assegnati automaticamente a essi.

Nelle edizioni commerciali puoi far creare questi host automaticamente. Usa il tipo di connessione Piggyback data nella gestione dinamica degli host. Se crei gli host manualmente, tieni presente quanto segue:

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

Se hai un agente Linux installato nel container, verrà eseguito automaticamente. Tuttavia, poiché molti servizi monitorati dall'agente all'interno dei container mostrano in realtà informazioni provenienti dal nodo (ad esempio, carico della CPU, temperatura e molti altri parametri del sistema operativo), questi sono stati rimossi.

Per impostazione predefinita — come menzionato sopra — l’ID breve di 12 caratteri del container viene utilizzato come nome per l’host del container. Questo può essere configurato in modo diverso, se lo desideri. Per farlo, nel file di configurazione docker.cfg (vedi Regolazione 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 configurare questa opzione in agent bakery utilizzando la regola Docker node and containers e l'opzione Host name used for containers.

A proposito: con il set di regole "Host name translation for piggybacked hosts" puoi definire regole piuttosto 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, per esempio.

Consulta l'articolo Il meccanismo piggyback per ulteriori opzioni e una descrizione più dettagliata di questa funzione.

Poiché lo stato dello host di un container non può essere realmente verificato utilizzando pacchetti TCP o ICMP, questo deve essere determinato in un altro modo. Il servizio Docker container status facilita questa operazione: in ogni caso checka se il container è in esecuzione e può quindi essere utilizzato come strumento sicuro per rilevare lo stato dello host. Definisci una regola 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 all’interno del container stesso (ad es. processi in esecuzione, database, file di log, ecc.), è necessario che l’agente Checkmk sia installato ed eseguito all’interno del container stesso. Ciò vale in particolare per l’implementazione dei plug-in dell’agente. I tre plug-in mem, cpu e diskstat (Disk I/O) funzionano comunque senza un agente nel container e vengono analizzati dall’agente Checkmk sul nodo stesso.

Soprattutto per le immagini Docker create autonomamente, potresti voler distribuire l'agente stesso nel container. In questo caso i dati non vengono più analizzati — come descritto sopra — dall'agente del nodo Docker. Al suo posto, in ogni container viene eseguito un agente separato. La chiamata a questo agente sarà comunque integrata in una procedura piggyback tramite il nodo Docker.

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

L'uso del set di regole Host check command in questo caso sarà necessario solo se il container non è raggiungibile via ping, ma per il resto funzionerà esattamente come descritto sopra.