Superviser un hôte Docker et ses conteneurs : espace disque et images orphelines, redémarrages en boucle, limites mémoire et OOM, sondes de santé et métriques par conteneur.
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.
| Niveau | Ce qu'on mesure | Pourquoi |
|---|---|---|
| Hôte | Disque, mémoire, charge, démon Docker | Sa défaillance emporte tous les conteneurs |
| Conteneur | État, redémarrages, mémoire, processeur | Détecte un conteneur en boucle ou étranglé |
| Application | Réponse HTTP, file d'attente, latence | Le service rendu, seul indicateur qui compte pour l'utilisateur |
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.
Les autres services
Ce que la supervision d'un serveur Linux détecte avant l'incident : saturation disque, fuite mémoire, processus zombie, échec de sauvegarde, certificat expiré. Avec les commandes de diagnostic.
Comment surveiller l'espace disque d'un serveur Windows ou Linux : quels seuils choisir, pourquoi la tendance compte plus que le pourcentage, et comment éviter la saturation avant l'incident.
Les métriques indispensables à surveiller sur un serveur Windows ou Linux : disque, mémoire, processeur, services, réseau. Seuils recommandés, pièges de lecture et ordre de priorité.
C'est de loin l'incident Docker le plus fréquent. Docker accumule silencieusement :
json-file, grossissent sans aucune limiteCe 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.logLa 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" }
}Cette configuration ne s'applique qu'aux conteneurs créés après le redémarrage du démon. Les conteneurs existants conservent leur configuration d'origine : il faut les recréer.
Surveillez le volume hébergeant /var/lib/docker en priorité — sur beaucoup d'installations, il s'agit de /var, voire de /.
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 dockerSi 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.
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)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.
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.
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-agent2Ajouter un utilisateur au groupe docker équivaut à lui accorder les privilèges root sur l'hôte : le socket Docker permet de démarrer un conteneur privilégié. C'est un compromis à évaluer consciemment, en particulier sur un serveur exposé.
Le niveau application relève de contrôles HTTP ou applicatifs, indépendants de Docker.
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.
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.
Disque, mémoire, charge, services systemd et réseau, avec découverte automatique des volumes.
Le plugin Docker de l'Agent 2 existe mais demande une configuration dédiée et l'accès au socket.
Couvert par la supervision disque standard, sans configuration supplémentaire.
Logiserv supervise votre parc à partir de cet article : essai gratuit sans carte bancaire.