Supervision de Docker

Bien sûr, l’aspect intéressant réside dans la supervision des conteneurs Docker. Celle-ci sera mise en œuvre automatiquement lors de l’installation des plugins ; toutefois, les services ne seront pas attribués au Docker node, mais Checkmk suppose un seul ordinateur hôte par conteneur Docker.

Le mécanisme utilisé ici s’appelle « piggyback » : Le plugin d’agent ou l’agent spécial transporte les données d’autres hôtes — « piggybackées », pour ainsi dire — en plus de ses propres données. Checkmk place ces données dans le répertoire ~/tmp/check_mk/piggyback. Il vous suffit, lors de la Configuration, de créer des hôtes avec les noms corrects, et les services leur seront alors automatiquement attribués.

Dans les éditions commerciales, vous pouvez faire créer ces ordinateurs hôtes automatiquement. Utilisez le type de connexion « Piggyback data » dans la gestion dynamique des hôtes. Veuillez noter ce qui suit si vous créez les ordinateurs hôtes manuellement :

Une fois les hôtes de conteneurs créés, et après avoir effectué une reconnaissance du service, de nouveaux services apparaissent sur ceux-ci.

Si un agent Linux est installé dans le conteneur, il sera exécuté automatiquement. Cependant, comme de nombreux services surveillés par l’agent au sein des conteneurs affichent en réalité des informations provenant du nœud (par exemple, la charge CPU, la température et de nombreux autres paramètres du système d’exploitation), ceux-ci ont été supprimés.

Par défaut — comme mentionné ci-dessus — l’identifiant court à 12 caractères du conteneur est utilisé comme nom pour l’hôte du conteneur. Il est possible de configurer cela différemment. Pour ce faire, dans le fichier de configuration docker.cfg (voir Réglage fin du plugin), définissez l’option container_id sur long afin d’utiliser l’identifiant complet du conteneur comme nom, ou sur name afin d’utiliser le nom du conteneur.

Les utilisateurs des éditions commerciales peuvent configurer cela dans la boulangerie d’agents à l’aide de la règle Docker node and containers, option Host name used for containers.

À propos : la règle « Host name translation for piggybacked hosts » vous permet de définir des règles très flexibles pour renommer les noms de domaine contenus dans les données ferroutées. Cette méthode vous permet également de résoudre le problème lié à la présence de conteneurs portant le même nom sur deux Docker nodes différents, par exemple.

Consultez l'article « Le mécanisme de ferroutage » pour découvrir d'autres options et une description plus détaillée de cette fonction.

Étant donné que l’état de l’ordinateur hôte d’un conteneur ne peut pas vraiment être vérifié à l’aide de paquets TCP ou ICMP, il doit être déterminé d’une autre manière. Le service Docker container status facilite cette tâche : il checke en tout cas si le conteneur est en cours d’exécution et peut donc être utilisé comme un outil sûr pour détecter l’état de l’ordinateur hôte. Définissez une règle dans le jeu de règles « Host check command » à cette fin, et configurez l’option « Use the status of the service…​ » sur le service mentionné. N’oubliez pas de définir les conditions de manière à ce que seuls les conteneurs soient concernés. Dans notre exemple, tous les conteneurs se trouvent dans un dossier portant le même nom :

Pour surveiller les détails au sein même du conteneur (par exemple, les processus en cours d’exécution, les bases de données, les fichiers journaux, etc.), il est nécessaire que l’agent Checkmk soit installé et exécuté dans le conteneur lui-même. Cela vaut tout particulièrement pour le déploiement des plugins d’agent. Les trois plugins mem, cpu et diskstat (E/S disque) fonctionnent toutefois sans agent dans le conteneur et sont analysés par l’agent Checkmk sur le nœud lui-même.

En particulier pour les images Docker que vous avez créées vous-même, vous souhaiterez peut-être déployer l’agent lui-même dans le conteneur. Dans ce cas, les données ne sont plus analysées — comme décrit ci-dessus — par l’agent du Docker node. À la place, un agent distinct s’exécute dans chaque conteneur. L’appel de cet agent sera toutefois toujours intégré dans une procédure de ferroutage via le Docker node.

Toutefois, l’agent installé dans le conteneur ne fonctionne que si toutes les instructions nécessaires sont également présentes dans le conteneur. En particulier avec les conteneurs minimalistes basés sur Alpine Linux, il est tout à fait possible que des éléments fondamentaux tels que Bash ne soient pas présents. Dans une telle situation, vous devriez surveiller le conteneur à partir du Docker node.

L'utilisation du jeu de règles « Host check command » ne sera dans ce cas nécessaire que si le conteneur n'est pas joignable par ping — mais elle fonctionnera sinon exactement comme décrit ci-dessus.