Comment surveiller Docker et ses conteneurs

Superviser Docker soulève une question préalable : superviser quoi, exactement ? L'hôte qui exécute le démon, les conteneurs individuellement, ou les applications qui tournent dedans ? Les trois répondent à des besoins différents, et la confusion entre eux explique la plupart des supervisions Docker inefficaces.

Les trois niveaux

Une erreur courante consiste à ne surveiller que le niveau conteneur. Un conteneur peut être « en cours d'exécution » avec son application complètement bloquée — l'état Docker ne dit rien de ce qui se passe à l'intérieur.

Niveau hôte : là où se produisent les vrais incidents

L'espace disque, encore

C'est de loin l'incident Docker le plus fréquent. Docker accumule silencieusement :

• les images téléchargées et leurs couches intermédiaires, jamais supprimées automatiquement
• les conteneurs arrêtés qui conservent leur système de fichiers
• les volumes orphelins dont plus aucun conteneur ne se sert
• les journaux de conteneurs qui, avec le pilote par défaut json-file, grossissent sans aucune limite

Ce dernier point mérite une insistance particulière : un conteneur bavard peut produire plusieurs gigaoctets de journaux en quelques jours, sur le volume qui héberge /var/lib/docker.

docker system df          # répartition de l'espace consommé
docker system df -v       # détail par image, conteneur et volume
du -sh /var/lib/docker/containers/*/*-json.log

La correction préventive tient en une configuration de rotation dans /etc/docker/daemon.json :

{
  "log-driver": "json-file",
  "log-opts": { "max-size": "50m", "max-file": "3" }
}

Surveillez le volume hébergeant /var/lib/docker en priorité — sur beaucoup d'installations, il s'agit de /var, voire de /.

Le démon Docker

L'arrêt du service docker emporte tous les conteneurs qui ne sont pas configurés pour redémarrer automatiquement. C'est un service à surveiller au même titre qu'une base de données.

systemctl is-active docker

La mémoire de l'hôte

Si les conteneurs n'ont pas de limite mémoire définie, l'un d'eux peut consommer toute la mémoire de l'hôte. Le tueur de processus du noyau intervient alors et arrête un processus — pas nécessairement le coupable.

Niveau conteneur : ce qui mérite une alerte

Les redémarrages en boucle

C'est le symptôme le plus révélateur. Un conteneur avec une politique restart: always qui plante au démarrage entre dans une boucle : il redémarre, échoue, redémarre. Vu de l'extérieur, il apparaît régulièrement « en cours d'exécution ».

Surveillez le compteur de redémarrages, pas seulement l'état. Un conteneur dont le compteur augmente est en échec permanent.

docker ps --format "table {{.Names}}\t{{.Status}}"
docker inspect --format '{{.Name}} {{.RestartCount}}' $(docker ps -aq)

Les arrêts pour dépassement mémoire

Un conteneur avec une limite mémoire dépassée est arrêté par le noyau. Le conteneur redémarre, refonctionne, puis est de nouveau arrêté — un cycle qui peut durer des jours sans que personne ne le remarque.

docker inspect --format '{{.Name}} OOMKilled={{.State.OOMKilled}}' $(docker ps -aq)

C'est un signal fort : il indique un sous-dimensionnement ou une fuite mémoire applicative.

Les sondes de santé

Une sonde HEALTHCHECK définie dans l'image permet à Docker de connaître l'état réel de l'application, pas seulement celui du processus. Un conteneur unhealthy est un conteneur qui tourne mais ne rend pas son service.

C'est le meilleur indicateur disponible au niveau conteneur — à condition que les images en définissent, ce qui est loin d'être systématique.

Comment collecter ces métriques

Le niveau hôte se supervise avec un agent standard : disque, mémoire, charge, état du service docker. C'est la partie la plus simple et la plus rentable, puisqu'elle couvre l'incident le plus fréquent.

Le niveau conteneur demande d'interroger l'API Docker. Zabbix Agent 2 dispose d'un plugin Docker intégré qui expose l'état des conteneurs, leur consommation et les informations du démon, à condition que l'utilisateur zabbix ait accès au socket Docker.

sudo usermod -aG docker zabbix
sudo systemctl restart zabbix-agent2

Le niveau application relève de contrôles HTTP ou applicatifs, indépendants de Docker.

Ce qui suffit dans la plupart des cas

Sur un hôte Docker de production classique, une supervision qui couvre l'espace disque du volume Docker, la mémoire de l'hôte, l'état du démon et la disponibilité des applications exposées détecte la quasi-totalité des incidents réels.

Les métriques par conteneur apportent surtout du confort de diagnostic — utile, mais rarement ce qui déclenche la détection.

Avec Logiserv

L'hôte Docker est supervisé comme un serveur Linux standard : disque avec découverte automatique des volumes, mémoire, charge, services systemd et réseau. Cela couvre l'incident le plus fréquent, la saturation du volume Docker.

Les métriques par conteneur ne sont pas incluses dans les templates fournis. Le plugin Docker de Zabbix Agent 2 étant disponible, leur activation relève d'une configuration spécifique à votre installation.

Supervision de l'hôte

Native

Disque, mémoire, charge, services systemd et réseau, avec découverte automatique des volumes.

Métriques par conteneur

Non incluses

Le plugin Docker de l'Agent 2 existe mais demande une configuration dédiée et l'accès au socket.

Incident le plus fréquent

Saturation de /var/lib/docker

Couvert par la supervision disque standard, sans configuration supplémentaire.

Pour aller plus loin

• Surveiller l'espace disque d'un serveur — l'incident Docker numéro un
• Pourquoi superviser un serveur Linux — la supervision de l'hôte
• Installer Zabbix Agent sur Ubuntu ou Debian
• Quelles métriques surveiller sur un serveur — le plan général
• Supervision serveur Windows et Linux : le guide — la démarche complète