Gestion des logs Docker en pratique : de la configuration des drivers à la collecte centralisée

Le téléphone vibre. Alerte disque sur le serveur de production, seuil à 85 %.

Je me redresse, ouvre le portable, me connecte en SSH. df -h : il ne reste que 12 % d’espace sur la partition racine. Après une série de vérifications, le coupable se trouve dans /var/lib/docker/containers — un conteneur Nginx actif depuis deux semaines, avec un fichier de logs gonflé à 12 Go.

Beaucoup ignorent que Docker ne limite pas la taille des logs par défaut. Ce conteneur crachait des dizaines de milliers de lignes d’accès par jour ; le driver json-file tout enregistrait fidèlement, et en deux semaines le disque était plein.

J’ai supprimé ce fichier de logs et ajouté la rotation sur tous les conteneurs. Ça m’a occupé jusqu’à quatre heures du matin.

Depuis cette nuit-là, j’ai passé une semaine à structurer la gestion des logs Docker — choix du driver, paramètres de rotation, collecte centralisée en environnement multi-conteneurs. Cet article résume ces galères.

1. Panorama des drivers de logs Docker

Concept de base : les logs d’un conteneur Docker ne sont pas écrits n’importe comment ; un « driver de logs » décide où ils vont et comment ils sont stockés.

Docker prend en charge plusieurs drivers, chacun adapté à un contexte. Par défaut, c’est json-file — stdout et stderr sont écrits au format JSON dans un fichier local, sous /var/lib/docker/containers/<ID du conteneur>/<ID du conteneur>-json.log.

json-file est simple : pas de config supplémentaire, format uniforme, lecture directe via docker logs. Mais le piège est évident : pas de limite de taille par défaut. Un conteneur qui tourne longtemps accumule les logs jusqu’à saturer le disque.

Le tableau suivant compare six drivers courants :

json-file et syslog sont les plus courants. json-file pour le debug local et les déploiements légers ; syslog quand l’entreprise a déjà rsyslog ou syslog-ng — les logs sont centralisés en aval.

Le driver journald délègue à systemd journal. Sur un serveur géré par systemd (la plupart des Linux modernes), c’est pratique : consultation via journalctl.

fluentd et gelf visent la collecte centralisée. fluentd peut envoyer vers Elasticsearch, Kafka, stockage cloud, etc. ; gelf est le format dédié Graylog. Idéal en cluster multi-conteneurs, mais nécessite un service de collecte.

none désactive les logs — utile pour des conteneurs éphémères ou des tâches batch où les logs n’importent pas.

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

Comment choisir ?

Mono-machine, dev : json-file suffit, avec rotation (section suivante). Entreprise avec syslog : syslog, réutilisez l’existant. Cluster, logs centralisés : fluentd ou Loki (détaillé plus bas). Conteneur temporaire : none.

2. Rotation des logs en pratique

Retour au problème initial : un fichier de logs à 12 Go. Comment l’éviter ? Configurer la rotation.

json-file expose trois paramètres clés :

• max-size : taille max. d’un fichier. Au-delà, Docker crée un nouveau fichier et numérote l’ancien. Ex. max-size=10m → 10 Mo max. par fichier.
• max-file : nombre de fichiers historiques conservés. Au-delà, le plus ancien est supprimé. Ex. max-file=3 → 3 fichiers historiques + le fichier courant.
• compress : compression des fichiers rotés. Par défaut false. true économise l’espace disque, avec un léger surcoût CPU.

La combinaison limite l’occupation disque. Ex. max-size=10m, max-file=3 → 30 Mo max. (moins avec compression).

Configuration : global vs conteneur

Trois niveaux possibles :

1. Configuration globale (daemon.json)

Pour tous les conteneurs, une fois pour toutes. Dans /etc/docker/daemon.json :

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3",
    "compress": "true"
  }
}

Redémarrez le daemon : sudo systemctl restart docker. Les nouveaux conteneurs héritent de cette config.

Attention : seuls les conteneurs créés après coup en bénéficient. Les existants doivent être traités séparément ou recréés.

2. Configuration par conteneur (docker run)

Pour des paramètres spécifiques :

docker run -d \
  --name nginx \
  --log-driver json-file \
  --log-opt max-size=50m \
  --log-opt max-file=5 \
  --log-opt compress=true \
  nginx:alpine

Applications à fort trafic : assouplir, ex. max-size=50m, max-file=10.

3. Configuration Docker Compose

Le plus courant en production :

version: "3.9"
services:
  webapp:
    image: webapp:latest
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"
        compress: "true"

  nginx:
    image: nginx:alpine
    logging:
      driver: "json-file"
      options:
        max-size: "50m"
        max-file: "5"

Chaque service peut avoir sa propre config.

Valeurs recommandées en production

Le guide pratique SigNoz 2024 propose :

• Dev/test : max-size=10m, max-file=3, suffisant.
• Trafic moyen : max-size=50m, max-file=5, plus d’historique pour le debug.
• Fort trafic : max-size=100m, max-file=10, éviter une rotation trop agressive.

Les valeurs exactes dépendent de votre contexte. Principe : équilibrer capacité disque et importance des logs. Disque large et logs critiques → garder plus ; disque serré → resserrer.

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

3. Comparaison des solutions de collecte centralisée

La rotation suffit en mono-machine. Avec des dizaines de conteneurs sur plusieurs hôtes, les logs éparpillés compliquent le debug — il faut se connecter partout et lancer docker logs un par un.

La collecte centralisée regroupe tout : stockage et requêtes unifiés.

Trois familles dominantes :

Stack ELK (Elasticsearch + Logstash + Kibana)

Classique et éprouvée. Logstash collecte, Elasticsearch indexe, Kibana visualise.

Points forts : recherche full-text, requêtes complexes, graphiques, écosystème mature. Faiblesses : gourmande en ressources — Elasticsearch pèse souvent plusieurs Go de RAM ; Logstash aussi, config complexe.

Adaptée aux grandes entreprises avec équipe ops dédiée, gros volumes et besoins de requêtes avancées.

EFK (Fluentd à la place de Logstash)

Variante ELK : Fluentd remplace Logstash. Plus léger (quelques centaines de Mo de RAM), riche en plugins, multiples sources et sorties.

Config plus claire que Logstash, mais Elasticsearch reste lourd. Consommation globale encore élevée — équipes moyennes à grandes.

Loki + Promtail + Grafana

Loki (Grafana Labs) : pas d’index full-text, seulement les labels (nom du conteneur, application) ; le contenu est stocké compressé, requêtes type grep, performances suffisantes.

Résultat : très léger (quelques centaines de Mo de RAM), stockage bien moins cher qu’Elasticsearch. Promtail collecte ; Grafana interroge, intégration native.

Idéal cloud native, surtout Kubernetes. Petites équipes, budget serré : excellent rapport qualité-prix.

Tableau comparatif

Comment choisir ?

• Petite équipe (< 10 personnes), budget limité : Loki. Simple, léger, interface Grafana agréable.
• Équipe moyenne (10-50), capacité ops : Loki ou EFK selon le volume.
• Grande entreprise, équipe ops dédiée : ELK. Complet, mature, investissement justifié.

Si Grafana monitor déjà votre infra, Loki s’impose — métriques et logs dans la même interface.

4. Pièges en production

Quelques erreurs que j’ai commises, pour vous éviter la même galère.

1. Oublier la rotation → disque plein

Le piège le plus fréquent. Déploiement sans penser aux logs ; quelques mois plus tard, alerte disque, fichiers à plusieurs dizaines de Go.

Conseil : defaults globaux dans daemon.json. Ne comptez pas sur votre mémoire à chaque docker run — la config, elle, n’oublie pas.

Railway - Plateforme de déploiement moderne, sans opérations complexes, en ligne en quelques minutes

Commencer →Pub

2. Redémarrage = perte de logs

Avec json-file, supprimer le conteneur supprime les logs. docker rm + docker run au lieu de docker restart → logs perdus.

Problème pour l’analyse rétrospective : crash à 3 h du matin, conteneur recréé, logs d’avant-crash disparus.

Conseils :

• Préférez docker restart à supprimer/recréer.
• Applications critiques : driver fluentd ou syslog vers stockage externe.
• Sauvegardez régulièrement les logs importants en production.

3. Adresse Fluentd incorrecte

Avec fluentd, les logs partent en TCP vers le service. Mauvaise adresse : le conteneur démarre sans erreur, mais rien n’est collecté — vous croyez centraliser, les logs se perdent en route.

Exemple :

docker run -d \
  --log-driver fluentd \
  --log-opt fluentd-address=127.0.0.1:24224 \
  --log-opt tag="docker.{{.Name}}" \
  my-web-app

fluentd-address doit correspondre à l’écoute réelle de Fluentd. Port par défaut 24224, TCP.

Diagnostic :

• Fluentd actif : curl http://localhost:24224 ou netstat -tlnp | grep 24224.
• docker inspect <ID du conteneur> pour la config du driver.
• Logs Fluentd : flux Docker reçus ou non.

4. Monitoring et alertes

La gestion des logs ne s’arrête pas à la configuration.

Deux métriques clés :

• Espace disque : surveiller /var/lib/docker/containers. Seuil d’alerte, ex. 10 Go.
• Latence d’écriture : en collecte centralisée, latence Fluentd ou Loki. Latence élevée → réseau ou goulot stockage.

Prometheus + Grafana, ou un script Cron simple.

Synthèse

Points clés de la gestion des logs Docker :

1. Choix du driver : json-file le plus universel ; syslog pour infra existante ; fluentd pour collecte centralisée.
2. Rotation : combinaison max-size + max-file ; global pour la simplicité, par conteneur pour la flexibilité.
3. Collecte centralisée : Loki pour petites équipes, ELK pour grandes — selon échelle et budget.
4. Pièges : rotation par défaut, éviter la perte de logs, vérifier Fluentd, surveiller le disque.

Modèle rapide :

// /etc/docker/daemon.json
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3",
    "compress": "true"
  }
}

Action immédiate : si la rotation n’est pas en place, vérifiez maintenant. Regardez /var/lib/docker/containers pour des fichiers géants, ajoutez les paramètres dans daemon.json, redémarrez Docker. Quelques minutes pour éviter de vous lever à 2 h du matin pour une alerte disque.