Guide complet du nettoyage des logs Docker : 5 méthodes pour éviter que json.log sature le disque

Conclusion rapide (d’abord stopper l’hémorragie, puis gouverner)

Face à des logs Docker qui saturent le disque, l’ordre le plus efficace est :
d’abord truncate pour libérer l’espace, puis max-size + max-file pour la rotation, enfin recréer les conteneurs pour appliquer la config.
Nettoyer sans configurer, c’est reculer l’incident ; configurer sans recréer, les anciens conteneurs continuent de gonfler.

3 h 17 du matin, le téléphone vibre et m’arrache d’un sommeil léger.

À l’écran, une alerte rouge : « Disque production à 100 %, tous les services arrêtés ». J’ai eu un coup au cœur — une plateforme e-commerce avec des centaines de milliers d’utilisateurs : chaque minute d’arrêt, c’est de l’argent perdu.

SSH immédiat. df -h confirme : la partition racine est pleine. Après inspection, le coupable est dans /var/lib/docker/containers/ : le fichier xxx-json.log d’un conteneur fait 82 Go !

Franchement, j’étais sidéré. Le conteneur tournait normalement — comment les logs ont-ils autant gonflé ?

Ce n’est pas un cas isolé. Docker ne limite pas la taille des logs par défaut : tout ce qui sort sur stdout/stderr va dans json.log, qui grossit jusqu’à saturer le disque.

Si les logs Docker vous posent problème, cet article couvre : nettoyage d’urgence, rotation pour éviter la récidive, choix du driver. J’ai regroupé les pièges que j’ai rencontrés pour vous aider à les éviter.

Pourquoi les logs Docker saturent le disque

Mécanisme de stockage

Quand un conteneur écrit sur stdout/stderr (console.log(), System.out.println(), etc.), Docker enregistre tout dans un fichier JSON : /var/lib/docker/containers/<container-id>/<container-id>-json.log.

Le problème : Docker ne fait aucune rotation par défaut.

Le fichier grossit sans limite. Un jour : 1 Go, une semaine : 7 Go, un mois : 30 Go. Avec un niveau DEBUG, la croissance est encore plus rapide.

Calcul rapide pour une app web à trafic moyen, 100 lignes/s, ~100 octets/ligne :

100 lignes/s × 86400 s × 100 octets ≈ 864 Mo/jour ≈ 25 Go/mois

Dix conteneurs similaires peuvent remplir 100 Go en moins d’un mois — estimation conservative.

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

Obtenir -15 % →Pub

Scénarios à risque

1. Niveau de logs trop bas en production

DEBUG ou INFO laissés après le dev : chaque requête HTTP génère des tonnes de lignes. J’ai vu un service Node.js logger le corps des uploads en base64 : quelques Mo par requête, disque 200 Go plein en trois jours.

2. Boucle d’erreurs

Un bug qui relance des exceptions en boucle fait exploser les logs. Un microservice avec un pool DB mal configuré : des centaines de tentatives/seconde avec stack trace complète — de 2 Go à 120 Go en 3 heures, disque HS.

3. Conteneurs de prod longue durée

Sans rotation, des mois d’accumulation. Un Nginx tournant 8 mois : 150 Go de logs ; docker logs devient très lent.

4. Fort trafic

Même une ligne d’accès par requête, sur des millions de PV/jour, donne des volumes énormes. Beaucoup ne s’en rendent compte qu’à l’alerte disque plein.

Nettoyage d’urgence : libérer l’espace tout de suite

Disque plein, services down, le boss vous ping. D’abord : libérer de l’espace.

Étape 1 : identifier les coupables

find /var/lib/docker/ -name "*.log" -exec ls -sh {} \; | sort -h -r | head -20

Exemple de sortie :

82G /var/lib/docker/containers/a1b2c3d4.../a1b2c3d4...-json.log
35G /var/lib/docker/containers/e5f6g7h8.../e5f6g7h8...-json.log
...

Chemin d’un conteneur précis :

docker inspect --format='{{.LogPath}}' <container_name_or_id>

Étape 2 : vider les logs en sécurité

Ne faites surtout pas rm sur le fichier de logs !

Docker garde le descripteur ouvert : après rm, l’espace disque n’est souvent pas libéré.

Videz le contenu, ne supprimez pas le fichier.

Méthode 1 — cat

cat /dev/null > $(docker inspect --format='{{.LogPath}}' <container_id>)

Méthode 2 — truncate (recommandé)

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

Commencer →Pub

truncate -s 0 $(docker inspect --format='{{.LogPath}}' <container_id>)

Méthode 3 — tous les conteneurs (attention)

sudo sh -c 'truncate -s 0 /var/lib/docker/containers/*/*-json.log'

Efface tous les logs de tous les conteneurs — à réserver à l’urgence.

Vérifier

df -h /var/lib/docker/

Si l’usage ne baisse pas, un conteneur écrit peut-être encore trop (DEBUG, boucle d’erreurs). Après mon fichier à 82 Go, le disque est passé de 100 % à 60 % — mais sans rotation, le problème reviendra.

Solution durable : configurer la rotation

Configuration globale dans daemon.json

Fichier : /etc/docker/daemon.json

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

• max-size : taille max. d’un fichier avant rotation
• max-file : nombre de fichiers conservés
• compress : compression des anciens fichiers

Ici : au plus 10 Mo × 3 = 30 Mo par conteneur (hors compression).

Prod (exemple) :

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

Ajustez selon le volume : 10m/50m/100m et max-file 3 ou 5. Toutes les valeurs doivent être des chaînes : "10m", pas 10m sans guillemets.

Redémarrer Docker

sudo systemctl restart docker

Important : la config globale ne s’applique qu’aux nouveaux conteneurs. Les conteneurs existants doivent être recréés.

docker-compose down puis docker-compose up -d, ou stop/rm/run pour docker run.

Par conteneur

docker run -d \
  --name my-app \
  --log-opt max-size=10m \
  --log-opt max-file=3 \
  nginx:latest

docker-compose.yml :

version: '3.8'
services:
  web:
    image: nginx:latest
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"
        compress: "true"

Vérifier la config

docker inspect <container_name> | grep -A 10 LogConfig

Si Config est {}, le conteneur est encore en mode illimité — recréez-le.

Guide des drivers de logs

json-file (défaut)

• Avantages : docker logs, config simple, stockage local rapide
• Inconvénients : pas de rotation par défaut, logs perdus si le conteneur est supprimé

Recommandé avec rotation :

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

local (recommandé en prod, Docker 18.09+)

Rotation automatique, format plus efficace, docker logs supporté. Logs binaires (pas de cat direct).

{
  "log-driver": "local",
  "log-opts": {
    "max-size": "100m",
    "max-file": "3"
  }
}

journald (systemd)

Intégration système, rotation native, métadonnées structurées.

{
  "log-driver": "journald"
}

journalctl -u docker.service -f CONTAINER_NAME=my-app

syslog

Envoi vers serveur distant — pas de docker logs. Utile si vous avez déjà une infra syslog centralisée.

🔥 Ne perdez plus des mois sur des produits sans demande ! Validez vos promesses SaaS avec Adsterra à petit budget →

Tester l'MVP →Pub

{
  "log-driver": "syslog",
  "log-opts": {
    "syslog-address": "tcp://192.168.1.100:514",
    "syslog-facility": "daemon",
    "tag": "{{.Name}}/{{.ID}}"
  }
}

Recommandations

Principe : toujours limiter la taille des logs locaux.

Bonnes pratiques et exploitation

Checklist production

1. Config globale (local ou json-file avec rotation, voir exemples ci-dessus).

2. Script de contrôle

#!/bin/bash
for container in $(docker ps -q); do
  name=$(docker inspect --format='{{.Name}}' $container | sed 's/\///')
  logconfig=$(docker inspect --format='{{json .HostConfig.LogConfig}}' $container)
  echo "Conteneur: $name"
  echo "Config logs: $logconfig"
  echo "---"
done

3. Alertes : disque > 80 % (avertissement), > 90 % (critique), taille de /var/lib/docker/containers/.

Exemple Prometheus :

- alert: HighDiskUsage
  expr: (node_filesystem_size_bytes - node_filesystem_free_bytes) / node_filesystem_size_bytes > 0.8
  for: 5m
  annotations:
    summary: "Utilisation disque > 80 %"

4. Inspection régulière

du -sh /var/lib/docker/
du -sh /var/lib/docker/containers/
find /var/lib/docker/containers/ -name "*-json.log" -exec du -h {} \; | sort -h -r | head -10

Côté application

• Niveaux : WARN/ERROR en prod, INFO en test, DEBUG en dev (−80 % de volume possible)
• Systèmes dédiés : ELK, Loki+Grafana, services cloud — Docker ne garde qu’un tampon récent
• Logs structurés JSON et échantillonnage pour les flux très volumineux

FAQ rapide

• Redémarrer Docker ne stoppe pas les conteneurs ; la nouvelle config ne vise que les nouveaux conteneurs.
• truncate n’impacte pas l’application.
• Avec journald, pas besoin de max-size.
• Logs encore énormes ? Conteneurs recréés ? Lignes monstrueuses dans une seule entrée ?
• Fichiers rotés (.1.gz) : supprimables ; le *-json.log courant : truncate, pas rm.

Points clés

1. daemon.json → nouveaux conteneurs seulement
2. Guillemets obligatoires sur les valeurs
3. truncate oui, rm non
4. docker logs : json-file/local/journald oui, syslog non
5. Redémarrer Docker après modification
6. Contrôler les nouveaux déploiements

Configurez à l’avance, vérifiez régulièrement — n’attendez pas le disque plein.

Conclusion

Retour à l’alerte de 3 h du matin : nettoyage, rotation, monitoring, recréation des conteneurs — terminé vers 6 h.

Les logs Docker ne sont pas un détail : bombe à retardement invisible jusqu’à l’explosion.

Urgence : truncate pour libérer l’espace.
Prévention : rotation dans daemon.json, driver adapté (local ou json-file), recréer les conteneurs.
Long terme : alertes disque, audits de config, logs applicatifs raisonnables.

Vérifiez maintenant :

1. find /var/lib/docker/ -name "*.log" -exec ls -sh {} \; | sort -h -r | head -10
2. /etc/docker/daemon.json et la rotation
3. docker inspect sur tous les conteneurs

N’attendez pas l’alerte à l’aube. Partagez l’article si elle vous a été utile.

Prochaines lectures

• Docker : dépannage des sorties anormales (Exit Code 137/1)
• Guide des limites de ressources Docker : CPU, mémoire et stabilité
• Guide de consultation et d’analyse des logs Docker