Monitoring Docker : le guide complet

La plupart des guides sur le monitoring Docker commencent par lister des outils. L’ordre est inversé : les outils ne prennent leur sens qu’une fois identifiés les six signaux indépendants dont vous avez réellement besoin — car presque aucun n’en couvre plus de deux.

Ce guide couvre ce que recouvre le monitoring Docker en pratique, les quatre architectures qui l’implémentent, un comparatif honnête de dix outils, et une méthode pour choisir.

Ce que recouvre réellement le monitoring Docker

« Est-ce que mon conteneur tourne ? » est une seule question avec six réponses sans rapport. Un conteneur peut tourner et ne servir à rien. Un service peut répondre parfaitement pendant que son certificat expire dans deux jours. Traiter tout cela comme un seul problème, c’est ainsi qu’on se retrouve avec cinq tableaux de bord.

Le cycle de vie des conteneurs. Leur existence, leur état, leur nombre de redémarrages et leur code de sortie. Un conteneur en boucle de crash apparaît souvent « running » si vous l’échantillonnez au mauvais moment : le signal utile est le compteur de redémarrages, pas l’état.

La consommation de ressources. CPU, mémoire, réseau et I/O disque par conteneur, et les mêmes pour l’hôte. Ce qui compte n’est pas la valeur instantanée mais la tendance : un chiffre de mémoire ne veut rien dire tant qu’on ignore s’il grimpe depuis six heures.

La joignabilité des services. Est-ce que ce qui tourne dans le conteneur répond. Un conteneur peut être parfaitement sain au niveau du runtime et renvoyer 500 à chaque requête. Seule une sonde HTTP ou TCP depuis l’extérieur le détecte, et seules des assertions de contenu confirment que la réponse est correcte et pas seulement présente.

Les certificats TLS. Les dates d’expiration de chaque domaine que vous terminez. C’est la panne parfaitement prévisible qui continue pourtant d’arriver, parce que l’expiration vit dans un système différent de celui qu’on surveille.

Les tâches planifiées. Est-ce que vos sauvegardes, purges et conteneurs cron se sont réellement terminés. Rien ne détecte une absence silencieuse : un cron qui a cessé de se déclencher ne produit ni erreur, ni ligne de log, ni alerte. Le détecter demande le motif inverse — une URL de heartbeat que la tâche appelle en cas de succès, avec une alarme quand l’appel n’arrive pas.

La dérive des images. L’écart entre le tag que vous exécutez et ce qui a été publié en amont, y compris si l’image plus récente corrige une CVE connue. :latest ne se met pas à jour tout seul.

Six signaux. Passons aux architectures.

Les quatre architectures

Exporteurs et base de séries temporelles

Le modèle Prometheus. De petits processus exposent des métriques sur un endpoint HTTP, un serveur central les collecte à intervalle régulier et les stocke, un composant distinct évalue les règles d’alerte, et une couche de visualisation interroge le stockage.

Pour Docker, cela signifie généralement Prometheus, cAdvisor pour les métriques de conteneurs, node-exporter pour l’hôte, Alertmanager pour le routage, Blackbox exporter pour les sondes, et Grafana par-dessus. Six composants avant le premier tableau de bord.

Le bénéfice est réel : PromQL est authentiquement puissant, la rétention se configure, et l’écosystème couvre tout. Le coût l’est tout autant — vous exploitez une infrastructure de supervision en plus de celle que vous vouliez superviser, et c’est la couche de stockage qui vous réveille à 3 h du matin.

Un agent par hôte

Un petit binaire tourne sur chaque machine, collecte localement, et sert une interface ou expédie ses données vers un hub. Netdata, Beszel et Zabbix fonctionnent ainsi.

La force est la profondeur du détail système et la granularité à la seconde. Le coût est la gestion de parc : un agent par hôte, c’est un déploiement, un chemin de mise à jour et une règle de pare-feu par hôte. Cela passe techniquement à l’échelle et ajoute de la friction opérationnelle.

La lecture du socket Docker

Un conteneur monte /var/run/docker.sock et demande au démon Docker ce qui existe. Pas d’exporteurs, pas d’instrumentation par conteneur, pas d’agent sur chaque machine. Les conteneurs sont découverts au démarrage ; des labels sur le service configurent la manière de le surveiller.

C’est de loin l’option la plus légère — les implémentations tiennent typiquement dans quelques dizaines de mégaoctets — et la seule où ajouter un service à votre docker-compose.yml constitue l’intégralité de la configuration.

Le compromis porte sur l’accès. Le socket Docker est l’API Docker : le monter en lecture seule protège le fichier, pas l’API derrière. Tout ce qui lit le socket doit être placé derrière une authentification, et en production le socket doit être atteint via un socket proxy qui filtre les endpoints.

Le SaaS hébergé

Datadog, New Relic, Dynatrace. Un agent expédie tout chez un éditeur qui possède le stockage, la corrélation et les alertes.

Vous obtenez une couverture qu’aucun outil auto-hébergé n’égale, et l’APM, les logs et les traces au même endroit. Vous obtenez aussi une facturation à l’hôte qui croît linéairement avec votre parc, votre télémétrie d’infrastructure sur les serveurs d’un tiers, et — pour la plupart des équipes qui partent — une facture qui a grossi plus vite que le parc.

Dix outils, comparés honnêtement

Aucun outil de cette liste n’est mauvais. Ils visent des problèmes différents, et c’est l’écart entre ce qu’un outil fait et ce dont une équipe a besoin qui produit l’empilement décrit plus haut.

Deux observations à partir de ce tableau.

Chaque ligne forte sur un signal est muette sur quatre autres. Ce n’est pas un défaut de ces outils — Dozzle est un visualiseur de logs et il excelle à cela. C’est la raison pour laquelle l’auto-hébergeur médian fait tourner Uptime Kuma pour le HTTP, Healthchecks pour les crons, Netdata ou Beszel pour les ressources, un script de certificats, et une cinquième chose pour les mises à jour d’images.

Et la colonne licence compte plus qu’il n’y paraît. L’AGPL-3.0 vous oblige à publier vos modifications si vous proposez le logiciel comme service en réseau ; la MIT non. Si vous intégrez un outil de supervision dans un produit que vous vendez, lisez la licence avant la liste de fonctionnalités.

Choisir, selon le contexte

Un homelab, un hôte, une douzaine de conteneurs. Vous voulez l’auto-découverte sans configuration et un seul conteneur. Beszel, Dozzle ou Maintenant conviennent, selon que vous vous souciez des ressources, des logs, ou des six signaux. Prometheus ici relève du loisir, pas de la solution.

Production, 2 à 20 hôtes, petite équipe. La gestion de parc devient le facteur décisif. Un lecteur de socket avec un agent léger par hôte distant bat un empilement d’exporteurs qu’il faut exploiter. Il vous faut un routage d’alertes qui atteint là où l’équipe se trouve vraiment, et une page de statut pour ceux qui demandent si c’est en panne.

Une agence ou un MSP, plusieurs clients, un seul parc. Les facteurs décisifs passent du technique au contractuel : une licence qui couvre l’infrastructure exploitée pour autrui, des alertes qui escaladent, et une page de statut lisible par le client. Voir Monitoring Docker pour les agences et les MSP.

Production, 50 hôtes et plus, équipe plateforme dédiée. Prometheus justifie ici sa complexité. Vous avez des gens qui maîtrisent PromQL, des exigences de rétention à régler, et une échelle suffisante pour amortir la charge opérationnelle. Associez-le à Grafana et Alertmanager, en acceptant que cet empilement soit un système que vous possédez.

Environnement régulé, isolé, ou contraint par la souveraineté. L’auto-hébergement est une exigence, pas une préférence. Privilégiez un binaire unique sans dépendance externe : moins de pièces mobiles, c’est moins de choses à faire certifier.

Vous payez déjà Datadog et vous relisez la facture. La question technique est : lesquels des six signaux utilisez-vous vraiment ? Les équipes qui utilisent l’APM et le tracing distribué ont une migration réellement difficile. Celles qui consultent surtout des tableaux de bord d’infrastructure découvrent en général qu’elles paient un prix de plateforme pour des métriques de conteneurs et des checks de disponibilité.

Superviser Docker depuis un seul conteneur

Maintenant est le lecteur de socket du tableau ci-dessus, conçu autour du constat que ces six signaux vont ensemble. C’est un binaire Go unique avec un frontend Vue embarqué et SQLite, tournant autour de 20 Mo de RAM au repos, sous AGPL-3.0.

services:
  maintenant:
    image: ghcr.io/kolapsis/maintenant:latest
    ports:
      - "8080:8080"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - maintenant-data:/data
    restart: unless-stopped

volumes:
  maintenant-data:

docker compose up -d, ouvrez le port 8080, et tous les conteneurs en cours d’exécution sont déjà découverts. Pas d’agent, pas d’exporteur, pas de configuration de scrape, pas de base à provisionner.

Deux avertissements qui valent ici comme pour tout outil lisant le socket. Publier 8080 sur toutes les interfaces expose l’API d’administration à quiconque atteint l’hôte : placez-la derrière un reverse proxy qui authentifie. Et le drapeau :ro protège le fichier socket, pas l’API Docker derrière : en production, atteignez Docker via un socket proxy.

Les checks d’endpoints, les heartbeats et les certificats se configurent depuis l’interface ou avec des labels Docker dans votre fichier compose, ce qui garde la configuration versionnée à côté du service qu’elle décrit. Le tour en 2 minutes détaille le premier lancement.

Pour aller plus loin

Si vous êtes arrivé ici en comparant avec un outil précis, les comparatifs détaillés sont plus utiles que cette vue d’ensemble :

• Alternative à Prometheus + Grafana — quand l’empilement dépasse le besoin
• Alternative à Netdata — métriques système à la seconde contre couverture unifiée
• Alternative à Uptime Kuma — sondes de disponibilité contre conscience des conteneurs
• Alternative à Beszel — la comparaison la plus proche, et là où les deux divergent
• Alternative à Datadog — ce que l’auto-hébergement vous coûte réellement en fonctionnalités

Et si vous êtes sur Swarm, l’orchestrateur change le problème : monitoring Docker Swarm traite des services, des tâches et de l’état des nœuds plutôt que de simples conteneurs.