Docker logs : lire les journaux et configurer leur rotation

La commande docker logs lit la sortie enregistrée pour un conteneur. Commencez par quelques lignes récentes, précisez une période, puis suivez les nouveaux messages si l’incident continue. Si les journaux sont vides ou occupent trop d’espace, vérifiez la sortie de l’application et le pilote de journalisation avant de modifier la configuration.

Ce guide suppose que Docker Engine est installé et que vous disposez d’un accès autorisé. Les exemples utilisent un conteneur nommé api : remplacez ce nom par le vôtre. Les pipelines et l’export de fichier utilisent un shell POSIX sous Linux ou macOS. Pour l’installation sur une VM, consultez notre guide pour exécuter Docker sur Compute with Hivenet.

Trouver le bon conteneur et lire les dernières lignes

Vérifiez le contexte Docker, surtout si vous alternez entre un ordinateur et une VM distante. Listez ensuite les conteneurs, y compris ceux qui sont arrêtés, puis affichez les 100 dernières lignes :

docker context show
docker ps -a
docker logs --tail 100 --timestamps api

La commande de contexte indique le contexte sélectionné. Tenez aussi compte des variables d’environnement ou options qui remplacent les paramètres de connexion. La liste des conteneurs affiche leurs noms et identifiants. Un conteneur arrêté peut conserver des journaux lisibles jusqu’à sa suppression, selon le pilote et la rétention.

Les journaux mêlent souvent démarrage, requêtes, avertissements et erreurs. L’absence de message d’erreur ne prouve pas qu’une requête a réussi. Reliez les horaires et identifiants de requête à l’incident étudié.

Suivre la sortie et limiter la période

Pour afficher les dernières lignes puis recevoir les suivantes :

docker logs --follow --tail 50 api

Ctrl+C arrête cette consultation, sans arrêter le conteneur. Si le flux est trop volumineux, réduisez la période :

docker logs --since 30m --timestamps api
docker logs --since "2026-10-29T09:00:00Z" --until "2026-10-29T09:10:00Z" api

La première commande utilise une durée relative. La seconde emploie des horaires UTC, signalés par Z. Remplacez les dates par celles de votre incident. Un fuseau explicite évite les confusions entre votre ordinateur et le serveur. La référence docker logs détaille ces options et les formats acceptés.

Pour une recherche textuelle rapide dans un shell POSIX :

docker logs --since 30m api 2>&1 | grep -i -E 'error|timeout|exception'

2>&1 réunit la sortie d’erreur et la sortie standard avant la recherche. Sans cette redirection, des erreurs peuvent contourner le pipeline. Ce filtre ne classe pas les événements par gravité : il peut manquer des données structurées, masquer une partie de la trace d’erreur ou retenir un message ordinaire contenant « error ». Relisez la période sans filtre avant de conclure.

Consulter les journaux Docker Compose par service

Dans le répertoire du fichier Compose concerné, utilisez les noms des services plutôt que de deviner ceux des conteneurs :

docker compose ps -a
docker compose logs --tail 100 --timestamps api
docker compose logs --follow --tail 50 api worker

La dernière commande suit deux services. Sans nom de service, docker compose logs sélectionne ceux du projet. La limite --tail s’applique à chaque conteneur : 100 lignes ne signifie donc pas 100 lignes au total. Conservez les préfixes pour rapprocher les erreurs de l’API et du worker. L’option --no-color produit une sortie sans couleur. Voir la référence Compose logs.

Pourquoi docker logs ne renvoie rien

Docker capture normalement les sorties standard et d’erreur du processus du conteneur. Il ne collecte pas automatiquement tous les fichiers journaux de l’application. Si celle-ci écrit uniquement dans un fichier, il faut éventuellement modifier sa configuration ou utiliser un collecteur. Vérifiez ses réglages avant de créer des liens symboliques. La présentation des journaux Docker explique cette distinction.

Comparez ensuite le pilote par défaut du démon avec la configuration du conteneur :

docker info --format '{{.LoggingDriver}}'
docker inspect --format '{{json .HostConfig.LogConfig}}' api

La première commande concerne les nouveaux conteneurs. La seconde montre le pilote et les options de ce conteneur. Avec none, Docker ne conserve pas de journaux. Le réglage par défaut ne suffit pas à connaître la configuration d’un conteneur créé la semaine précédente.

Un pilote distant ne rend pas systématiquement docker logs indisponible. Docker peut conserver un cache local grâce à la double journalisation. Si ce cache est désactivé et que le pilote ne permet pas la lecture locale, consultez la destination distante. Ce cache offre un historique récent limité : des échecs d’écriture distante et d’autres limites documentées peuvent créer des lacunes. Ce n’est pas une archive durable.

Exporter un extrait limité à l’incident

Ne conservez que la période utile. Dans un shell POSIX, choisissez un nouveau nom de fichier, puis lancez :

umask 077
docker logs --since 30m --timestamps api > incident-api-20261029-0900.txt 2>&1

Le umask restrictif limite les permissions du fichier nouvellement créé. Il ne corrige pas celles d’un fichier existant, que > écraserait. Vérifiez donc le nom avant l’export. La sortie fusionnée peut inclure des diagnostics Docker, en plus des messages de l’application.

Relisez l’extrait avant de le partager. Retirez les jetons, en-têtes d’autorisation, données personnelles et URL signées. Notez le conteneur, la version de l’image, le fuseau de l’incident et les changements récents de déploiement. Ces éléments rendent quelques lignes plus utiles qu’un journal complet sans contexte.

Configurer la rotation avant de saturer le disque

Le pilote json-file utilisé par défaut n’impose aucune limite de taille sans configuration. Pour un usage Docker autonome courant, Docker recommande le pilote local, qui assure une rotation par défaut. Consultez la configuration des pilotes et vérifiez la compatibilité de votre collecteur avant de changer de pilote.

Pour un service Compose, fusionnez cet extrait avec sa définition actuelle. Conservez son image, ses variables, volumes, ports et autres paramètres :

services:
  api:
    logging:
      driver: local
      options:
        max-size: "10m"
        max-file: "3"

L’attribut logging de Compose définit le pilote et ses options par service. Cet extrait ne constitue pas un déploiement complet.

Avec le pilote local, ces paramètres déclenchent une rotation à 10 Mo et conservent jusqu’à trois fichiers. Les plus anciens sont supprimés au fil des rotations. Les fichiers ayant subi une rotation sont compressés par défaut. Cette limite porte sur la taille, sans garantir plusieurs jours d’historique. Un service bavard peut remplacer rapidement ses anciennes entrées. Ces options ne limitent ni les fichiers propres à l’application ni l’utilisation totale du disque de la VM.

Si un collecteur exige des fichiers JSON, conservez json-file et configurez les deux options. Pour ce pilote, max-file ne prend effet que si max-size est défini. La référence du pilote JSON déconseille aussi de manipuler les fichiers gérés par Docker avec des outils externes. Ne fondez pas un nettoyage automatique sur leur troncature manuelle.

Appliquer les changements par une recréation planifiée

Un changement de journalisation ne reconfigure pas un conteneur existant. Avant de recréer le service, sauvegardez les éléments utiles de l’incident, vérifiez que les données persistantes utilisent les volumes prévus et anticipez l’interruption. Dans le bon projet Compose, validez la configuration fusionnée puis appliquez-la au service :

docker compose config --quiet
docker compose up -d --no-deps api
docker compose ps -a
docker compose logs --tail 50 --timestamps api

Compose up recrée les conteneurs dont la configuration a changé. L’option --no-deps évite de démarrer leurs dépendances. Un service à une seule réplique peut être interrompu. Un simple redémarrage ne suffit pas à adopter une nouvelle configuration de journalisation.

Vérifiez le résultat avec l’identifiant affiché par docker compose ps -a :

docker inspect --format '{{json .HostConfig.LogConfig}}' CONTAINER_ID

Confirmez le pilote et ses options, déclenchez une requête de test normale et vérifiez son apparition dans les journaux. Contrôlez également l’état de l’application par son point d’accès habituel. Des journaux lisibles ne prouvent pas son bon fonctionnement. Modifier le pilote par défaut du démon exige un redémarrage Docker planifié séparément et concerne toujours les nouveaux conteneurs, sans modifier rétroactivement les anciens.

Distinguer les journaux des conteneurs et du démon Docker

Si Docker ne peut pas démarrer un conteneur ou contacter un pilote, l’erreur utile peut se trouver dans les journaux du démon. Sous Linux avec Docker exécuté comme service systemd :

journalctl -u docker.service --since "30 minutes ago" --no-pager

L’accès au journal dépend de vos permissions. Docker Desktop et les installations rootless utilisent d’autres emplacements ou services. Suivez les instructions relatives au démon correspondant à votre installation. Ne supposez pas qu’un chemin sous /var/lib/docker/containers existe sur tous les hôtes ou contient les journaux recherchés.

Définir la durée de conservation nécessaire

La rotation locale réserve un espace limité. Si les journaux doivent survivre à la suppression du conteneur ou de la VM, envoyez-les vers une destination distincte avec une rétention définie, des contrôles d’accès et des alertes en cas d’échec de collecte. Distinguez les événements à conserver longtemps des messages de débogage à supprimer rapidement.

Sur une VM que vous administrez avec Compute with Hivenet, prévoyez la journalisation et la surveillance du disque. Notre guide VM ou conteneur aide à distinguer ces environnements. Les commandes de cet article supposent un accès au démon Docker ; elles ne garantissent pas que les mêmes contrôles existent dans un service de conteneurs géré.