Surveillance et alertes Docker avec exemples pratiques : guide d'implémentation

Introduction

Une bonne surveillance Docker répond à trois questions rapides lors d'un incident : qu'est‑ce qui a changé, qu'est‑ce qui casse et où intervenir. Pour la plupart des équipes, cela signifie surveiller l'utilisation CPU (Central Processing Unit) : unité centrale de traitement et mémoire des conteneurs, les redémarrages et les OOM (Out Of Memory) : mémoire insuffisante, la dérive d'images, ainsi que la pression réseau ou disque. Ce guide propose un pilote pratique et ciblé, exécutable sur un seul hôte, pour démontrer rapidement la valeur, puis l'étendre en toute confiance. Il couvre les métriques à collecter, des règles d'alerte concrètes, les signaux de logs, les tableaux de bord, les étapes de vérification, les modes de défaillance courants et les instructions de restauration.

L'approche est délibérément simple : activer l'endpoint de métriques du moteur Docker, ajouter cAdvisor pour les statistiques par conteneur, collecter avec Prometheus, router les alertes via Alertmanager et appliquer une rotation des logs. Toutes les étapes sont sûres à tester localement avant tout déploiement multi‑hôtes.

Inventaire des versions et de l'environnement

Avant toute modification, dressez l'inventaire de l'existant afin de mesurer l'amélioration et de pouvoir revenir en arrière en toute sécurité.

Enregistrer les versions et la topologie
Exécutez docker version et conservez les versions client et serveur.
Exécutez docker info et notez le pilote de stockage, le pilote de journalisation, le pilote cgroup et le nombre de conteneurs en cours d'exécution.
Système d'exploitation (OS, Operating System) : système d'exploitation : uname -a et /etc/os-release.
Nom d'hôte et adresses IP (IP, Internet Protocol) : adresse IP : hostname -f et ip -br a.
Réseaux : docker network ls et docker network inspect <réseau> pour les réseaux de production.
Configuration de référence
Sauvegardez : sudo cp -a /etc/docker/daemon.json /etc/docker/daemon.json.bak.$(date +%s) 2>/dev/null || true
Validez le format JSON (JavaScript Object Notation) : format d'échange de données : sudo sh -c 'test -f /etc/docker/daemon.json && jq . /etc/docker/daemon.json >/dev/null' || echo ok
Notez les options de log actuelles : docker info | grep -i 'Logging Driver' -A2
Accès et sécurité
Assurez‑vous de disposer des droits sudo pour redémarrer Docker : sudo systemctl status docker.
Fenêtre de maintenance : le redémarrage du démon Docker est bref mais peut interrompre les opérations du plan de contrôle (démarrage/arrêt, pulls). Les conteneurs en cours d'exécution continuent normalement ; planifiez pendant une période à faible trafic.

Chemin de configuration sécurisé

L'objectif est un pilote restreint sur un seul hôte : lier les métriques à localhost, confirmer la collecte, puis ajouter quelques alertes ciblées. Maintenez l'exposition des identifiants et du réseau au minimum.

Choisir un périmètre de pilote étroit

Utilisez le périmètre suivant comme valeur par défaut et élargissez ultérieurement.

Hôte Docker unique – Facile à comprendre et à restaurer ; limite le rayon d'impact.
Métriques liées à localhost – Évite d'exposer les métriques sur le réseau ; réduit le risque.
cAdvisor pour les statistiques des conteneurs – Métriques de conteneur stables et granulaires ; permet des alertes au niveau conteneur.
Prometheus + Alertmanager – Configuration et règles basées sur des fichiers, simples ; vérification rapide.

Configurer les métriques du moteur Docker et la rotation des logs

Créez ou modifiez /etc/docker/daemon.json avec des valeurs par défaut prudentes. Exemple :

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  },
  "experimental": true,
  "metrics-addr": "127.0.0.1:9323"
}

Notes :

experimental doit être true pour exposer l'endpoint de métriques.
Lier à 127.0.0.1 évite l'exposition réseau ; la collecte se fait localement.
Si vous utilisez déjà un pilote de log non standard, conservez‑le et ajoutez simplement les paramètres de métriques.

Validez le JSON et redémarrez Docker en toute sécurité :

sudo jq . /etc/docker/daemon.json >/dev/null
sudo systemctl restart docker
Vérifiez : curl -s http://127.0.0.1:9323/metrics | head -n 5 doit afficher des lignes au format Prometheus.

Ajouter cAdvisor pour les métriques par conteneur

Lancez cAdvisor avec des montages hôte en lecture seule. La commande suivante le maintient local et n'expose pas son interface utilisateur.

sudo docker run -d \
  --name=cadvisor \
  --restart unless-stopped \
  -p 127.0.0.1:8080:8080 \
  -v /:/rootfs:ro \
  -v /var/run:/var/run:ro \
  -v /sys:/sys:ro \
  -v /var/lib/docker/:/var/lib/docker:ro \
  gcr.io/cadvisor/cadvisor:latest

Vérifiez : curl -s http://127.0.0.1:8080/metrics | head -n 5

Exécuter un pilote local Prometheus et Alertmanager

Utilisez des fichiers de configuration locaux pour que tout soit auditable et facile à restaurer.

Créez ./prometheus/ avec :

prometheus.yml :

global:
  scrape_interval: 15s
  evaluation_interval: 15s
rule_files:
  - /etc/prometheus/alerts.yml
scrape_configs:
  - job_name: 'docker-engine'
    static_configs:
      - targets: ['127.0.0.1:9323']
  - job_name: 'cadvisor'
    static_configs:
      - targets: ['127.0.0.1:8080']

alerts.yml avec des alertes ciblées :

# CPU proche d'un cœur complet pendant 5 min
- alert: ContainerHighCPU
  expr: rate(container_cpu_usage_seconds_total{container!=""}[5m]) > 0.9
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "{{ $labels.container }} CPU élevé"
    description: "CPU du conteneur > 90 % d'un cœur pendant 5 min"

# Mémoire > 90 % de la limite (quand une limite est définie)
- alert: ContainerMemoryNearLimit
  expr: (container_memory_working_set_bytes{container!=""} / container_spec_memory_limit_bytes{container!=""} > 0.9) and on(container) (container_spec_memory_limit_bytes{container!=""} > 0)
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "{{ $labels.container }} mémoire proche de la limite"
    description: "Ensemble de travail > 90 % de la limite pendant 5 min"

# Détection de boucle de redémarrage via les changements d'heure de démarrage
- alert: ContainerCrashLoop
  expr: changes(container_start_time_seconds{container!=""}[5m]) > 2
  for: 2m
  labels:
    severity: critical
  annotations:
    summary: "{{ $labels.container }} boucle de crash"
    description: "Conteneur redémarré plusieurs fois en 5 min"

# Signal OOM kill (si exposé par cAdvisor)
- alert: ContainerOOMKilled
  expr: increase(container_oom_events_total{container!=""}[5m]) > 0
  for: 0m
  labels:
    severity: critical
  annotations:
    summary: "{{ $labels.container }} tué par OOM"
    description: "Un ou plusieurs événements OOM au cours des 5 dernières minutes"

Démarrez Prometheus, lié à localhost :

sudo docker run -d \
  --name=prometheus \
  --restart unless-stopped \
  -p 127.0.0.1:9090:9090 \
  -v $(pwd)/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml:ro \
  -v $(pwd)/prometheus/alerts.yml:/etc/prometheus/alerts.yml:ro \
  prom/prometheus:latest

Démarrez un Alertmanager minimal et routez les alertes localement. Créez ./alertmanager/alertmanager.yml :

route:
  receiver: 'stdout'
receivers:
  - name: 'stdout'
    webhook_configs:
      - url: 'http://127.0.0.1:5001/'
        send_resolved: true

Démarrez Alertmanager :

sudo docker run -d \
  --name=alertmanager \
  --restart unless-stopped \
  -p 127.0.0.1:9093:9093 \
  -v $(pwd)/alertmanager/alertmanager.yml:/etc/alertmanager/alertmanager.yml:ro \
  prom/alertmanager:latest

Pour un récepteur local rapide, vous pouvez lancer un serveur HTTP simple dans un autre terminal afin d'observer les payloads d'alerte :

python3 -m http.server 5001

Alternativement, configurez votre webhook de messagerie ou d'email après avoir vérifié les alertes localement.

Question rapide 1 sur 2

Quelles sont les trois questions rapides auxquelles un bon monitoring Docker doit répondre pendant les incidents ?

La section d'introduction indique explicitement : « Un bon monitoring Docker répond à trois questions rapides pendant les incidents : ce qui a changé, ce qui se casse et où le corriger. »

Métriques et signaux clés à surveiller

Utilisez les éléments suivants comme palette initiale de tableau de bord et d'alertes.

Saturation CPU – Confirme les processus incontrôlés ou des limites mal dimensionnées. Exemple de requête : rate(container_cpu_usage_seconds_total{container!=""}[5m])
Pression mémoire – Détecte les fuites et le risque OOM. Exemple : container_memory_working_set_bytes{container!=""}
Redémarrages – Détecte les boucles de crash et le flap. Exemple : changes(container_start_time_seconds{container!=""}[5m])
OOM kills – Alerte critique immédiate. Exemple : increase(container_oom_events_total{container!=""}[5m])
Santé du moteur – Confirme l'état du plan de contrôle Docker. Commande : curl -s 127.0.0.1:9323/metrics | head

Signaux utiles dans les logs Docker

Sorties et redémarrages de conteneurs : docker ps --format '{{.Names}} {{.Status}}' et docker inspect -f '{{.Name}} RestartCount={{.RestartCount}}' <conteneur>
Drapeau OOMKilled : docker inspect -f '{{.Name}} OOMKilled={{.State.OOMKilled}}' <conteneur>
Événements au niveau moteur : docker events --since 10m --filter type=container --filter event=oom --filter event=die
Erreurs d'application : docker logs --since 10m <conteneur> ; recherchez les traces de pile et le taux d'erreurs par minute.

Vérification et diagnostics

Prouvez que chaque composant fonctionne avant de passer à l'étape suivante. Les étapes suivantes gardent la vérification ciblée et réversible.

1) Vérifier les endpoints de métriques

Métriques moteur : curl -s 127.0.0.1:9323/metrics | grep -m1 ^# doit afficher une ligne HELP ou TYPE.
Métriques cAdvisor : curl -s 127.0.0.1:8080/metrics | grep -m1 ^# doit afficher les en‑têtes Prometheus.
Cibles Prometheus : ouvrez http://127.0.0.1:9090/targets dans un navigateur ou via port‑forwarding ; les deux jobs doivent être UP.

2) Déclencher une alerte CPU

Créez un conteneur consommant du CPU :

docker run -d --name cpuhog --rm alpine:3 sh -c 'while :; do :; done'

Requête dans Prometheus : rate(container_cpu_usage_seconds_total{container="cpuhog"}[5m]) doit tendre vers 1,0 sur un cœur unique.
Dans les 5 à 10 minutes, l'alerte ContainerHighCPU doit se déclencher.
Arrêtez le test : docker rm -f cpuhog

3) Déclencher une alerte de boucle de crash

Démarrez un conteneur qui échoue immédiatement et redémarre :

docker run -d --name crashloop --restart always alpine:3 sh -c 'echo boom; sleep 1; exit 1'

Vérifiez les redémarrages : docker ps --format '{{.Names}} {{.Status}}' | grep crashloop
Requête : changes(container_start_time_seconds{container="crashloop"}[5m])
L'alerte ContainerCrashLoop doit se déclencher. Nettoyez : docker rm -f crashloop

4) Optionnel : simuler une pression mémoire

Si vous disposez d'une image de test capable d'allouer de la mémoire (par exemple, un petit utilitaire interne), exécutez‑la avec une limite mémoire basse et tentez de la dépasser. Confirmez que container_oom_events_total augmente et que les alertes se déclenchent. Si vous ne pouvez pas simuler OOM en toute sécurité, validez en inspectant un conteneur d'application après un incident OOM connu :

docker inspect -f '{{.Name}} OOMKilled={{.State.OOMKilled}}' <conteneur>

5) Valider le routage des alertes

Ouvrez http://127.0.0.1:9093/#/alerts pour voir les alertes actives.
Confirmez que votre récepteur webhook local affiche des POST lorsque les alertes se déclenchent.
Si vous intégrez une messagerie ou un email, abaissez temporairement les seuils et confirmez qu'une seule notification arrive.

Modes de défaillance et récupération

Problèmes courants et correctifs rapides

Endpoint de métriques inaccessible
Symptôme : curl 127.0.0.1:9323/metrics échoue.
Cause : experimental non activé, port déjà utilisé ou erreur de syntaxe dans daemon.json.
Correctif : validez le JSON avec jq ., définissez experimental: true, confirmez metrics-addr, redémarrez Docker.

Problèmes de permissions ou de montage cAdvisor
Symptôme : cible cAdvisor DOWN ou métriques de conteneur manquantes.
Cause : montages manquants ou erreurs de lecture sur /var/lib/docker ou /sys.
Correctif : assurez‑vous que les montages sont présents et en lecture seule, redémarrez cAdvisor.

Alertes bavardes ou dupliquées
Symptôme : flot de notifications.
Cause : durées for: trop courtes, requêtes bruyantes, absence de group_by dans les récepteurs.
Correctif : augmentez les seuils, ajoutez des fenêtres for:, dé‑dupliquez au niveau Alertmanager, utilisez des étiquettes pour grouper.

Conteneurs ne respectant pas les alertes mémoire
Symptôme : alerte mémoire se déclenche mais aucune limite n'est définie ; l'alerte semble inactionnable.
Cause : conteneurs sans limite mémoire rapportent une spécification illimitée ; les alertes basées sur le ratio ne sont pas pertinentes.
Correctif : utilisez des seuils absolus d'ensemble de travail par hôte ou imposez des limites avec docker update --memory lorsque c'est approprié.

Effets secondaires du redémarrage Docker
Symptôme : brèves interruptions du plan de contrôle.
Cause : redémarrage du démon.
Correctif : planifiez pendant une fenêtre ; vérifiez après redémarrage que docker ps et docker pull fonctionnent.

Procédures de restauration et de retour arrière

Restaurer la configuration du démon Docker
sudo cp -a /etc/docker/daemon.json.bak.* /etc/docker/daemon.json (choisissez la dernière sauvegarde saine)
sudo systemctl restart docker
Vérifiez : docker ps et curl 127.0.0.1:9323/metrics (échec attendu si les métriques ont été retirées ; c'est normal après restauration)

Désactiver rapidement les composants de surveillance
Arrêter cAdvisor : docker rm -f cadvisor
Arrêter Prometheus : docker rm -f prometheus
Arrêter Alertmanager : docker rm -f alertmanager

Réduire le bruit des alertes pendant l'investigation
Dans Alertmanager, créez un silence temporaire correspondant à severity=warning ou au nom d'alerte spécifique.
Augmentez la durée for: dans alerts.yml de 5 min à 15 min pour les alertes non critiques, rechargez Prometheus en redémarrant le conteneur.

Récupérer l'espace disque suite à des logs incontrôlés
Confirmez le pilote de log et la rotation : docker info | grep -i 'Logging Driver' -A2
Si json-file est utilisé, assurez‑vous que max-size et max-file sont définis ; mettez à jour daemon.json et redémarrez Docker.

Question rapide 2 sur 2

Selon les points clés, quelles informations doivent être enregistrées lors de l'étape d'inventaire de l'environnement avant de modifier quoi que ce soit ?

L'étape d'inventaire de l'environnement demande d'exécuter `docker version`, `docker info`, de noter l'OS, le nom d'hôte et les IP, et aussi d'enregistrer les réseaux Docker, ce qui inclut le Storage Driver, le Logging Driver, le Cgroup Driver et le nombre de conteneurs en cours d'exécution. Le passage liste tous ces éléments.

Liste de contrôle opérationnelle

Utilisez cette liste chaque semaine et lors des incidents.

Référence et capacité

Examinez les 5 principaux conteneurs par CPU et mémoire dans Prometheus sur les 7 derniers jours.
Confirmez qu'aucun conteneur ne s'exécute sans limite mémoire prévue si vous dépendez d'alertes basées sur le ratio mémoire.
Vérifiez l'espace disque sur /var/lib/docker : df -h /var/lib/docker.

Signaux et alertes

Assurez‑vous que les cibles Prometheus sont UP.
Revoyez l'historique des alertes et confirmez l'absence de bruit persistant ; ajustez les seuils ou les fenêtres for: si nécessaire.
Confirmez qu'au moins une alerte de test atteint votre canal choisi.

Logs et événements

Recherchez les redémarrages fréquents : docker ps --format '{{.Names}} {{.Status}}' | grep -E 'Up|Restarting'.
Échantillonnez les événements moteur : docker events --since 24h --filter type=container --filter event=oom --filter event=die | head -n 20.

Flux de réponse aux incidents (suivre dans l'ordre)

Identifiez le conteneur le plus bruyant grâce au contexte de l'alerte.
Inspectez rapidement l'état : docker inspect -f '{{.Name}} State={{.State.Status}} OOM={{.State.OOMKilled}} Restarts={{.RestartCount}}' <conteneur>.
Obtenez les logs autour de l'échec : docker logs --since 10m <conteneur>.
Si emballement CPU, envisagez un plafonnement temporaire : docker update --cpus 1.0 <conteneur> (vérifiez l'impact d'abord).
Si boucle de crash, désactivez --restart ou réduisez à zéro le temps de triage : docker update --restart=no <conteneur> ou recréez sans redémarrage.
Documentez la cause racine et la prévention (limite, correction de code, modification de probe de démarrage) avant de réactiver le redémarrage automatique.

Tableaux de bord pratiques (requêtes à copier‑coller)

CPU : topk(10, rate(container_cpu_usage_seconds_total{container!=""}[5m]))
Ensemble de travail mémoire : topk(10, container_memory_working_set_bytes{container!=""})
Redémarrages : sum by (container) (changes(container_start_time_seconds{container!=""}[1h]))
Événements OOM : increase(container_oom_events_total{container!=""}[1h])

Étendre après que le pilote est silencieux

Ajoutez des collecteurs au niveau nœud (système de fichiers, réseau) et des alertes pour la pression disque et l'épuisement des inodes.
Introduisez des tableaux de bord pour la dérive d'images et de tags afin de détecter les mises à niveau inattendues.
Sécurisez les métriques avec TLS (Transport Layer Security) : sécurité de la couche transport ou isolez les scrapeurs sur un réseau de surveillance dédié lors du passage au‑delà de localhost.
Intégrez Alertmanager à la messagerie, au ticketing et aux systèmes d'astreinte, avec un routage par service ou équipe.

Conclusion

Vous disposez désormais d'une base fonctionnelle et vérifiable pour la surveillance et les alertes Docker : métriques moteur et conteneur collectées localement, règles d'alerte actionnables pour CPU, mémoire, redémarrages et OOM kills, et une liste de contrôle qui rend les opérations répétables. Comme le pilote est étroit et inspectable localement, il est facile d'ajuster les seuils, de valider le routage et de revenir en arrière si nécessaire. Une fois vos alertes silencieuses, précises et dignes de confiance, étendez la couverture aux ressources nœud, aux tableaux de bord par équipe et au routage d'alertes de niveau production.