Journaux des conteneurs : comment ne pas les perdre

Quand un service tombe, le journal est la seule source de vérité. Par défaut, Docker l’écrit dans un fichier à côté du conteneur et ne plafonne pas sa taille : une application bavarde peut remplir tout le disque en une semaine.

Comment lire

docker logs -f --tail 100 <container>
docker compose logs -f app
docker compose logs --since 30m --timestamps app
docker logs <container> 2>&1 | grep -i error | tail -50

À retenir : Docker affiche ce que l’application écrit sur la sortie standard et l’erreur standard. Si elle écrit dans son propre fichier à l’intérieur du conteneur, docker logs n’affichera rien — il faut chercher le journal à l’intérieur ou rediriger la sortie.

docker compose exec app ls -la /var/log

Plafonner la taille dès maintenant

Le réglage global pour tous les conteneurs se trouve dans /etc/docker/daemon.json :

{
  "log-driver": "json-file",
  "log-opts": { "max-size": "20m", "max-file": "3" }
}

sudo systemctl restart docker

Le réglage s’applique aux conteneurs créés après un redémarrage. Les conteneurs en cours d’exécution doivent être recréés. Pour un seul service, la même chose s’ajoute dans Compose :

services:
  app:
    logging:
      driver: json-file
      options:
        max-size: "20m"
        max-file: "3"

Le résultat : pas plus de 60 Mo par service au lieu d’une croissance illimitée.

Vérifiez la taille actuelle avant qu’elle ne vous surprenne : sudo du -sh /var/lib/docker/containers/*/*-json.log | sort -h | tail. Vous ne pouvez pas tronquer un fichier en cours d’exécution avec rm — l’espace n’est pas libéré tant que Docker détient le descripteur. La bonne méthode : recréer le conteneur ou sudo truncate -s 0 <file>.

Faire survivre les journaux au conteneur

Le fichier de journal est supprimé en même temps que le conteneur. Si l’historique compte, confiez-le au journal système :

logging:
  driver: journald
  options:
    tag: "myapp"

journalctl -t myapp -n 200 --since today
journalctl -t myapp -p err --since "2 days ago"

journald fait tourner les enregistrements de lui-même et est plafonné par le réglage SystemMaxUse dans /etc/systemd/journald.conf. Pour vérifier l’espace qu’il occupe : journalctl --disk-usage.

Pour plusieurs services à la fois, il est plus pratique de tout collecter au même endroit — par exemple avec un conteneur collecteur dédié qui stocke les enregistrements dans des fichiers par jour. Mais commencez par journald : il est déjà là et ne coûte rien.

Ce qu’il faut regarder lors du débogage d’une panne

1. Les 200 dernières lignes avant le crash : docker logs --tail 200 <container>.
2. Le code de sortie : docker inspect -f '{{.State.ExitCode}} {{.State.OOMKilled}}' <container>. Le code 137 et true dans OOMKilled signifient que le noyau a tué le processus par manque de mémoire — voir limites de ressources.
3. Le journal système de la machine : sudo dmesg -T | tail -50 affichera les kills pour manque de mémoire et les erreurs de disque.

Erreurs courantes

• Le disque s’est rempli de journaux et tous les services sont tombés. Plafonner la taille est indispensable juste après l’installation de Docker.
• Regarder le journal d’un conteneur déjà supprimé. Après docker compose down, il a disparu. Collectez les enregistrements dans journald à l’avance.
• Des secrets dans le journal. Les applications adorent imprimer des chaînes de connexion avec des mots de passe. Quiconque a accès à la machine peut lire le journal.
• Chercher l’erreur dans la console texte. Elle fait toujours 80×24 et les lignes longues sont coupées. Pour lire les journaux, SSH ou la console « Screen » est plus pratique.