Le monitoring Docker Swarm casse discrètement la plupart des outils de monitoring Docker. Ils se connectent, listent les conteneurs, tout paraît normal — et ils ne mentionnent jamais qu’un service tourne à deux réplicas sur cinq depuis quatre heures.
La raison est que Swarm change l’unité de travail. Un outil qui ne comprend que les conteneurs observe l’ombre de ce qu’il devrait surveiller.
Services, tâches et nœuds
Trois objets remplacent l’abstraction unique du conteneur, et les confondre est à l’origine de la plupart des angles morts en supervision Swarm.
Un service est une déclaration : cette image, tant de réplicas, ces contraintes, cette politique de mise à jour. C’est ce que vous déployez.
Une tâche est une instance planifiée de ce service, liée à exactement un conteneur sur exactement un nœud. Les tâches sont immuables : quand l’une échoue, Swarm ne la redémarre pas. Il planifie une nouvelle tâche et laisse l’ancienne dans un état terminal.
Un nœud est une machine du cluster, soit un manager participant au quorum Raft, soit un worker exécutant des tâches.
La conséquence est précise et facile à manquer. Un outil au niveau conteneur voit trois conteneurs en cours pour un service et rapporte trois conteneurs sains. Il ne peut pas vous dire que vous en avez demandé cinq. L’écart entre le désiré et le réel est un concept propre à Swarm, et c’est le chiffre le plus utile d’un cluster.
Seconde conséquence : parce que les tâches échouées sont remplacées et non redémarrées, un compteur de redémarrages au niveau conteneur reste à zéro pendant qu’un service se dégrade. Vingt tâches replanifiées en une heure ressemblent, pour un outil orienté conteneur, à un conteneur parfaitement stable qui se trouve être récent.
Quoi surveiller
Réplicas désirés contre réplicas réels, par service. La métrique phare. Alertez quand l’écart persiste au-delà de votre fenêtre de déploiement.
Le quorum des managers. Les managers Swarm utilisent Raft ; perdre le quorum rend le cluster non planifiable pendant que les tâches existantes continuent de tourner. C’est le pire type de panne : tout semble normal jusqu’à ce que vous tentiez un déploiement. Suivez le nombre de managers, la joignabilité de chacun, et quel nœud est leader.
Disponibilité et état de drain des nœuds. Un nœud passé en drain pour maintenance et jamais remis en active est une perte de capacité permanente que personne ne remarque avant que la panne suivante n’ait nulle part où aller.
Codes de sortie et taux de replanification des tâches. Pas seulement le nombre de tâches actives mais le renouvellement : un service qui tient son compte de réplicas en replanifiant sans cesse est en train d’échouer, lentement.
L’état des déploiements. Pendant un docker service update, savoir si la mise à jour progresse, est en pause ou a été annulée. Un déploiement bloqué en « paused » après un health check échoué y restera indéfiniment.
Les ressources par nœud. CPU, mémoire et disque par machine, parce que l’ordonnanceur place les tâches selon les contraintes et les réservations, pas selon la charge réelle d’un nœud.
Et tout ce qui relève de Docker simple. La joignabilité des endpoints, l’expiration TLS, l’exécution des crons et la dérive des images ne disparaissent pas parce que vous avez ajouté un orchestrateur. Le guide général du monitoring Docker couvre ces six signaux.
Pourquoi docker service ps n’est pas de la supervision
Les commandes intégrées sont de bons outils de diagnostic et pas un système de supervision :
docker service ls # désiré contre réel, à l'instant T
docker service ps web --no-trunc # tâches et erreurs, à l'instant T
docker node ls # nœuds et statut manager, à l'instant T
docker events --filter scope=swarm # un flux live, perdu dès que vous fermez
Chacune répond à « qu’est-ce qui est vrai à cet instant, sur une machine connectée à un manager ». Aucune ne conserve d’historique, n’évalue de seuil, ni ne prévient qui que ce soit. docker events est la plus proche d’une primitive de supervision, et c’est un flux éphémère : rien ne le consomme tant que vous n’écrivez pas le consommateur.
Le problème swarmprom
Pendant des années, la réponse standard au monitoring Swarm a été swarmprom : un assemblage soigné de Prometheus, Grafana, cAdvisor, node-exporter, Alertmanager et de tableaux de bord Swarm, déployable en une seule stack.
C’était réellement bon. C’est aussi archivé sur GitHub, dernier commit en juillet 2020.
On peut encore le déployer, et des gens le font. Mais vous exploitez alors un assemblage d’images figées vieux de cinq ans, vous maintenez les tableaux de bord vous-même, et vous portez les CVE accumulées dans ce jeu d’images. Ce qu’il démontre surtout aujourd’hui, c’est qu’assembler six composants pour superviser Swarm représentait assez de travail pour qu’on veuille un paquet tout prêt — et assez de travail pour que, le paqueteur parti, rien d’équivalent ne l’ait remplacé.
Si vous voulez le modèle Prometheus sur Swarm en 2026, vous l’assemblez à partir des images amont actuelles et vous écrivez vous-même la configuration de découverte de services Swarm. C’est un choix légitime à l’échelle. Cela fait beaucoup de machinerie pour un cluster de trois nœuds.
Superviser un cluster Swarm depuis un seul conteneur
Maintenant lit l’API Docker depuis un nœud manager et comprend directement le modèle objet Swarm : informations du cluster, nœuds avec leur rôle et leur disponibilité, services avec réplicas désirés et réels, et tâches derrière chaque service avec leurs codes de sortie.
Déployez-le en stack, contraint sur un manager :
version: "3.8"
services:
maintenant:
image: ghcr.io/kolapsis/maintenant:latest
ports:
- "8080:8080"
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro
- maintenant-data:/data
deploy:
replicas: 1
placement:
constraints:
- node.role == manager
volumes:
maintenant-data:
docker stack deploy -c maintenant-stack.yml monitoring
Un détail mérite d’être connu, car il piège tout outil lisant le socket sur Swarm : docker stack deploy ignore silencieusement group_add. Un conteneur qui fonctionne sous Compose parce que vous lui avez accordé le groupe docker échouera sur Swarm avec une erreur de permission sur le socket, sans que le fichier de stack n’en donne la moindre indication. Maintenant résout le groupe du socket monté dans son entrypoint, ce qui rend le montage ci-dessus suffisant ; avec un socket proxy ou un chemin de socket non standard, figez le groupe avec DOCKER_GID (stat -c '%g' /var/run/docker.sock).
Pour le CPU, la mémoire et le disque par nœud à l’échelle du cluster, déployez le même binaire en mode agent sur les autres nœuds : il détecte le runtime local, renvoie son état à l’instance manager, et chaque entité surveillée reste attribuée à son hôte d’origine.
La même instance couvre aussi, depuis le même tableau de bord, les signaux non-Swarm : sondes HTTP et TCP contre les services que votre cluster publie, expiration TLS des domaines que vous terminez, heartbeats pour les tâches planifiées, et détection des mises à jour d’images sur les services que vous exécutez.
À lire ensuite
- Monitoring Docker : le guide complet — les six signaux et les quatre architectures, pour Docker simple
- Alternative à Prometheus + Grafana — ce que vous échangez en quittant le modèle des exporteurs
- Monitoring des tâches cron — le motif heartbeat, d’autant plus important dans un cluster où les tâches se déplacent entre nœuds