Limites de ressources Docker : surveillance, alertes et opérations pratiques

Introduction

Les conteneurs Docker sont isolés, mais pas automatiquement limités. Sans limites de ressources explicites, un seul conteneur peut consommer tous les cycles CPU disponibles ou chaque octet de mémoire de l'hôte, affamant les services voisins, déclenchant le tueur OOM (Out Of Memory) du noyau et dégradant l'ensemble du nœud. La surveillance et les alertes transforment ce risque silencieux en un problème visible et gérable.

Ce guide présente une approche pratique de bout en bout : inventorier votre environnement Docker actuel, activer la collecte de métriques, configurer Prometheus et cAdvisor, définir des règles d'alerte, les valider sous charge réelle et répondre aux incidents. Vous apprendrez quelles métriques comptent vraiment, comment éviter les faux positifs courants et comment faire de la surveillance une pratique opérationnelle routinière plutôt qu'une réflexion après coup.

À la fin, vous disposerez d'un flux de travail reproductible. Nous utiliserons les capacités natives de Docker ainsi qu'une pile basée sur Prometheus comme exemples concrets, mais les principes sont transférables à tout système de surveillance. L'objectif n'est pas seulement de voir des chiffres sur un tableau de bord ; c'est de savoir quand un conteneur est sur le point de dépasser ses limites et d'agir avant que les utilisateurs ne s'en aperçoivent.

Inventaire des versions et de l'environnement

Avant de pouvoir définir des seuils significatifs, vous devez savoir ce que vous exécutez et quelles limites existent déjà. Commencez par un inventaire complet de vos hôtes Docker.

Vérifier les versions de Docker et du système d'exploitation

Exécutez ce qui suit sur chaque hôte Docker :

docker version
cat /etc/os-release
uname -r

Exemple de sortie (tronqué pour lisibilité) :

Client: Docker Engine - Community
 Version:           24.0.7
 API version:       1.43
 Go version:        go1.20.10
 Git commit:        afdd53b
 Built:             Thu Oct 26 09:11:35 2023
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          24.0.7
  API version:      1.43 (minimum version 1.12)
  Go version:        go1.20.10
  Git commit:        afdd53b
  Built:             Thu Oct 26 09:09:17 2023
  OS/Arch:           linux/amd64
  Experimental:      false

Cela confirme Docker Engine 24.0.7 sur un hôte Linux (Ubuntu 22.04 dans cet exemple). La version de l'API est 1.43. Notez la version du système d'exploitation et du noyau ; les fonctionnalités de comptabilité des ressources comme cgroup v2 se comportent différemment selon les versions du noyau, et vous devez connaître votre base de référence.

Lister les conteneurs et leurs limites de ressources

Utilisez docker ps pour lister les conteneurs en cours d'exécution :

docker ps --format "table {{.ID}}\t{{.Names}}\t{{.Image}}\t{{.Status}}"

Ensuite, inspectez un conteneur spécifique (remplacez <conteneur> par son nom ou son ID) pour voir ses paramètres de ressources à l'exécution :

docker inspect <conteneur> --format '{{.HostConfig.Memory}} {{.HostConfig.NanoCpus}} {{.HostConfig.CpuShares}}'

Exemple de sortie :

1073741824 500000000 1024

Interprétation :

• Limite mémoire : 1073741824 octets = 1 Gio
• NanoCpus : 500000000 = 0,5 CPU (les nano CPU valent 1e-9 de CPU)
• CpuShares : 1024 (poids par défaut, pertinent uniquement en cas de contention CPU)

Si aucune limite n'est définie, vous verrez généralement 0 pour la mémoire et 0 pour NanoCpus. Un zéro signifie que le conteneur peut utiliser toutes les ressources de l'hôte, ce qui est souvent la cause première des incidents de voisin bruyant.

Résumer votre environnement

Créez un tableau des conteneurs et de leurs limites pour évaluer les risques. Par exemple :

Ce tableau indique immédiatement quels conteneurs sont les plus contraints. Dans cet exemple, cache a la limite mémoire la plus stricte et mérite une surveillance plus étroite. Le conteneur web n'a pas encore d'historique ; vous devriez le surveiller pendant quelques jours avant de faire confiance à ses limites.

Responsable et cadence : Affectez un ingénieur infrastructure (par exemple, Jordan Lee) pour maintenir cet inventaire et le mettre à jour chaque semaine ou chaque fois que des conteneurs sont ajoutés ou supprimés. La mise à jour doit faire partie de votre processus régulier de revue des changements.

Chemin de configuration sûr

Ne déployez pas la surveillance et les limites sur tout en une seule fois. Commencez par un seul conteneur non critique afin de valider votre configuration sans risquer la production.

Étape 1 : Activer le point de terminaison de métriques Docker

Le moteur Docker peut exposer des métriques au format Prometheus. Sous Linux, configurez le démon pour qu'il écoute sur un socket TCP local. Créez ou modifiez /etc/docker/daemon.json :

{
  "metrics-addr": "127.0.0.1:9323",
  "experimental": true
}

Puis redémarrez Docker :

sudo systemctl restart docker

Vérifiez le point de terminaison :

curl http://127.0.0.1:9323/metrics | head -n 20

La sortie attendue comprend des lignes telles que :

# HELP engine_daemon_container_states_containers The count of containers in various states
# TYPE engine_daemon_container_states_containers gauge
engine_daemon_container_states_containers{state="running"} 3
engine_daemon_container_states_containers{state="paused"} 0
engine_daemon_container_states_containers{state="stopped"} 0

Remarque : la clé experimental est requise sur certaines versions de Docker pour activer le point de terminaison de métriques. Consultez la documentation de votre version spécifique de Docker si le point de terminaison n'apparaît pas.

Étape 2 : Définir des limites de ressources sur un conteneur pilote

Si vos conteneurs manquent de limites, ajoutez-les d'abord à un conteneur de test. Par exemple, exécutez un conteneur nginx avec des limites de mémoire et de CPU :

docker run -d --name web-pilote --memory=512m --cpus=0.5 -p 8080:80 nginx:1.25

Vérifiez que les limites sont appliquées :

docker inspect web-pilote --format '{{.HostConfig.Memory}} {{.HostConfig.NanoCpus}}'

Sortie :

536870912 500000000

Cela correspond à 512 Mio et 0,5 CPU.

Étape 3 : Déployer cAdvisor pour des métriques détaillées sur les conteneurs

Bien que les métriques natives de Docker incluent certaines informations sur les conteneurs, l'utilisation des ressources par conteneur comme la mémoire de l'ensemble de travail ou l'étranglement CPU est mieux exportée par cAdvisor. Exécutez cAdvisor en tant que conteneur :

docker run -d \
  --name=cadvisor \
  --volume=/:/rootfs:ro \
  --volume=/var/run:/var/run:ro \
  --volume=/sys:/sys:ro \
  --volume=/var/lib/docker/:/var/lib/docker:ro \
  --publish=8080:8080 \
  gcr.io/cadvisor/cadvisor:v0.47.0

Accédez aux métriques de cAdvisor à l'adresse http://<hôte>:8080/metrics. Vous verrez des métriques détaillées comme container_memory_working_set_bytes, container_cpu_usage_seconds_total et container_spec_memory_limit_bytes.

Étape 4 : Configurer Prometheus pour collecter les métriques

Ajoutez des configurations de scraping à votre prometheus.yml pour le démon Docker et cAdvisor :

scrape_configs:
  - job_name: 'docker'
    static_configs:
      - targets: ['<ip-hôte>:9323']
  - job_name: 'cadvisor'
    static_configs:
      - targets: ['<ip-hôte>:8080']

Rechargez Prometheus pour appliquer la configuration.

Étape 5 : Définir des règles d'alerte

Une alerte à forte valeur ajoutée concerne l'utilisation de la mémoire d'un conteneur proche de sa limite. Dans votre fichier de règles Prometheus :

groups:
  - name: docker_container_alerts
    rules:
      - alert: ContainerMemoryUsageHigh
        expr: (container_memory_working_set_bytes / container_spec_memory_limit_bytes) > 0.9
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Le conteneur {{ $labels.name }} utilise plus de 90 % de sa limite mémoire"
          description: "Le conteneur {{ $labels.name }} a utilisé {{ $value | humanizePercentage }} de sa limite mémoire pendant 5 minutes."

Cette alerte se déclenche lorsqu'un conteneur utilise plus de 90 % de sa limite mémoire pendant 5 minutes consécutives. La clause for évite les battements dus à de brefs pics.

Responsable et cadence : Les règles d'alerte sont la propriété du responsable de l'équipe de surveillance de la plateforme (par exemple, Alex Morgan). Révisez les seuils d'alerte mensuellement et après tout changement majeur d'application pour vous assurer qu'ils correspondent toujours aux modèles d'utilisation attendus.

Vérification et diagnostics

Après avoir configuré la surveillance, vérifiez que les métriques sont collectées, que les alertes se déclenchent réellement et que vos tableaux de bord affichent des données utiles.

Vérifier l'état des cibles Prometheus

Interrogez Prometheus pour connaître l'état des cibles :

curl -s http://<prometheus>:9090/api/v1/targets | jq '.data.activeTargets[] | {job: .job, health: .health, lastError: .lastError}'

La sortie attendue montre "health":"up" pour chaque cible. Si une cible est en panne, vérifiez le conteneur exportateur ou l'état du démon.

Inspecter les métriques clés

Utilisez le navigateur de requêtes Prometheus ou l'API pour exécuter ces requêtes :

• Utilisation de la mémoire du conteneur par rapport à la limite (ratio) :

container_memory_working_set_bytes{name="web-pilote"} / container_spec_memory_limit_bytes{name="web-pilote"}

• Taux d'étranglement CPU du conteneur (secondes étranglées par seconde, sur 5 minutes) :

rate(container_cpu_cfs_throttled_seconds_total{name="web-pilote"}[5m])

Un taux d'étranglement non nul signifie que le conteneur est restreint en dessous de sa limite CPU, souvent en raison de charges de travail en rafale.

Générer une charge de test

Pour vérifier les alertes, créez une charge à l'intérieur du conteneur pilote. Pour le stress mémoire, exécutez une commande qui alloue de la mémoire. L'outil stress est idéal mais peut ne pas être installé. Vous pouvez utiliser une simple boucle shell avec head de /dev/zero comme solution de repli :

docker exec web-pilote sh -c "tail /dev/zero -c 400M | head -c 400M > /dev/null & sleep 60; kill %1"

Cela alloue environ 400 Mio et les conserve pendant 60 secondes. Étant donné que la limite du conteneur est de 512 Mio, cela devrait pousser l'utilisation au-dessus de 90 % si le conteneur utilisait déjà une partie de la mémoire. Observez l'augmentation du ratio de la métrique dans Prometheus, et après 5 minutes (si vous avez défini for: 5m), l'alerte devrait se déclencher.

Vérifier la livraison des alertes

Confirmez que vous avez reçu une notification via votre configuration Alertmanager. Sinon, vérifiez les journaux d'Alertmanager et les règles de routage. Une erreur courante est d'oublier de router les alertes vers un récepteur ; vérifiez que votre alertmanager.yml inclut une route et un récepteur pour la sévérité warning.

Modes de défaillance et récupération

Les systèmes de surveillance eux-mêmes peuvent échouer. Voici les modes de défaillance courants et comment les récupérer.

Battement d'alerte

Si une alerte se déclenche et se résout à plusieurs reprises, le seuil est probablement trop strict ou la durée for trop courte. Augmentez for à 10 minutes ou ajustez le seuil. Par exemple, si un conteneur monte régulièrement à 91 % pendant 4 minutes, mais est autrement sain, un seuil de 90 % avec for: 5m va battre. Soit augmentez le seuil à 95 %, soit prolongez for à 15 minutes.

Métriques manquantes en raison d'un crash de l'exportateur

Si cAdvisor ou le point de terminaison de métriques Docker tombe en panne, Prometheus affichera la cible comme down. Configurez une alerte pour cela :

- alert: ExporterDown
  expr: up == 0
  for: 1m
  labels:
    severity: critical
  annotations:
    summary: "L'exportateur {{ $labels.job }} est en panne"

Pour récupérer, redémarrez le conteneur ou le service et vérifiez que la cible revient en ligne. Pour cAdvisor, docker restart cadvisor fonctionne généralement. S'il plante à plusieurs reprises, vérifiez ses journaux pour trouver la cause première.

Mauvaise configuration des règles d'alerte

Si les alertes ne se déclenchent pas comme prévu, vérifiez l'évaluation des règles dans l'interface Prometheus sous Statut > Règles. Recherchez les erreurs. Validez la syntaxe YAML et rechargez. Une erreur de syntaxe courante est une indentation incorrecte dans le fichier de règles.

Faux positifs dus à une mauvaise lecture des limites

cAdvisor peut signaler container_spec_memory_limit_bytes comme 0 pour les conteneurs sans limite explicite, provoquant une division par zéro dans votre requête. Modifiez l'expression d'alerte pour filtrer les limites nulles :

(container_memory_working_set_bytes / container_spec_memory_limit_bytes) > 0.9
and
container_spec_memory_limit_bytes > 0

Cela évite les fausses alarmes pour les conteneurs sans limites. Mieux encore, définissez des limites sur tous les conteneurs pour que ce cas limite disparaisse.

Revenir en arrière sur les changements de surveillance

Si un changement de configuration cause des problèmes, revenez à la configuration précédente. Pour les modifications de daemon.json de Docker, restaurez le fichier d'origine et redémarrez Docker. Pour la configuration de Prometheus, restaurez le fichier et rechargez. Conservez des sauvegardes versionnées de ces configurations.

Pièges courants et comment les éviter

Au fil des années d'exploitation de flottes de conteneurs, certaines erreurs apparaissent de manière répétée. Voici comment les contourner.

Piège 1 : Définir des limites de mémoire sans surveiller l'ensemble de travail par rapport à RSS.

Les limites de mémoire s'appliquent à l'utilisation totale de la mémoire du conteneur, mais le tueur OOM du noyau utilise une métrique plus large que container_memory_working_set_bytes. L'ensemble de travail de cAdvisor exclut le cache de fichiers inactifs, de sorte que votre alerte peut se déclencher après que le conteneur est déjà en difficulté. Pour éviter cela, surveillez également container_memory_usage_bytes et définissez des alertes à 85 % de la limite pour l'ensemble de travail et à 95 % pour l'utilisation totale.

Piège 2 : Ignorer l'étranglement CPU.

Un conteneur peut rester en dessous de sa limite CPU en moyenne mais être étranglé pendant les rafales. Cela provoque des pics de latence que les utilisateurs remarquent. Alertez toujours sur container_cpu_cfs_throttled_seconds_total avec un taux non nul sur 5 minutes. Si l'étranglement est courant, augmentez la limite CPU ou ajustez le comportement de l'application.

Piège 3 : Faire confiance aux modèles d'alerte par défaut sans les tester.

Les expressions d'alerte Prometheus semblent souvent correctes mais échouent silencieusement parce que les étiquettes ne correspondent pas ou que les métriques sont manquantes. Testez toujours les alertes avec une charge connue. Utilisez promtool test rules pour valider les fichiers de règles avant de les déployer.

Piège 4 : Définir des limites sans effectuer de benchmarking au préalable.

Choisir des limites arbitraires comme 512 Mio pour une base de données peut provoquer des arrêts OOM pendant le trafic de pointe. Benchmarkez votre application sous une charge réaliste et définissez des limites au moins 20 % au-dessus de l'utilisation maximale observée. Révisez les limites après chaque changement de code significatif.

Piège 5 : Oublier de surveiller la pile de surveillance elle-même.

Si Prometheus ou cAdvisor tombe en panne, vous perdez la visibilité. Placez la pile de surveillance sur un hôte séparé ou au moins dans un domaine de défaillance différent, et configurez des vérifications de santé externes.

Liste de contrôle des opérations

Utilisez cette liste de contrôle pour les revues régulières et la réponse aux incidents.

Contrôles quotidiens

• [ ] Vérifiez que les cibles Prometheus sont en ligne : up == 1 dans l'interface Prometheus ou via l'API.
• [ ] Vérifiez les alertes actives dans Alertmanager. Acquittez-les si elles sont en cours de traitement.
• [ ] Examinez les 5 principaux conteneurs par utilisation mémoire et CPU : requête topk(5, container_memory_working_set_bytes) et topk(5, rate(container_cpu_usage_seconds_total[5m])).
• [ ] Responsable : SRE d'astreinte (rotation).

Revue hebdomadaire

• [ ] Analysez les tendances d'utilisation des ressources pour tous les conteneurs. Identifiez tout conteneur ayant dépassé 80 % de sa limite pendant plus d'une heure au cours de la semaine écoulée.
• [ ] Testez l'alerte en simulant un pic de ressources dans un conteneur de test dédié. Responsable : ingénieur plateforme (par exemple, Jordan Lee).
• [ ] Vérifiez les mises à jour de cAdvisor et des exportateurs Prometheus. Planifiez les mises à niveau pendant les fenêtres de maintenance.
• [ ] Responsable : responsable surveillance (Alex Morgan). Fréquence : tous les lundis.

Étapes de réponse aux incidents

Lorsqu'une alerte de ressource se déclenche, suivez cette séquence :

1. Acquittez l'alerte dans Alertmanager et notez l'heure.
2. Identifiez le ou les conteneurs affectés. Interrogez Prometheus pour la métrique spécifique : container_memory_working_set_bytes{name="db"}.
3. Vérifiez l'utilisation actuelle des ressources sur l'hôte : docker stats --no-stream pour voir la mémoire, le CPU et les PIDs.
4. Inspectez les journaux du conteneur pour les erreurs : docker logs <conteneur> --tail 100.
5. Si le conteneur ne répond pas en raison d'un OOM, redémarrez-le : docker restart <conteneur>.
6. Si le problème persiste, augmentez temporairement les limites de ressources : docker update --memory 1g --cpus 1 <conteneur>.
7. Après résolution, recherchez la cause première et ajustez les limites ou le code de l'application. Documentez l'incident.

Tableau des métriques clés

Conclusion

La surveillance des limites de ressources Docker transforme un risque caché en une pratique opérationnelle gérée. Dans ce guide, nous avons couvert un flux de travail complet : inventorier votre environnement, activer les métriques avec Docker et cAdvisor, configurer les alertes Prometheus, valider avec une charge de test, gérer les modes de défaillance courants et suivre une liste de contrôle quotidienne et hebdomadaire.

Commencez petit : choisissez un conteneur non critique, appliquez des limites et surveillez-le pendant une semaine. Observez son comportement sous un trafic réel. Ensuite, étendez à tous les conteneurs, intégrez les alertes dans votre outil de gestion des incidents et faites des revues hebdomadaires une habitude. L'effort est récompensé par moins de surprises OOM, moins d'incidents de voisin bruyant et une plateforme plus stable pour tous.