Commande docker logs : 7 astuces pour diagnostiquer rapidement un conteneur

docker logs payment-service — vous appuyez sur Entrée, et des milliers de lignes INFO défilent à l’écran. Le service de paiement vient de tomber en production : où se cache la ligne ERROR qui pourrait tout expliquer ?

Logs qui défilent trop vite, surveillance en temps réel, filtrage par plage horaire, localisation rapide des erreurs — ces problèmes sont plus difficiles à gérer qu’on ne le croit au moment critique. Cet article partage 7 astuces pratiques autour de docker logs, du basique à l’avancé, pour diagnostiquer rapidement un conteneur.

Consultation de base des logs

1. La commande la plus simple

Commençons par l’usage le plus élémentaire. Vous connaissez sûrement cette commande :

docker logs <nom-du-conteneur>
# ou avec l'ID du conteneur
docker logs abc123def456

Elle affiche tous les logs du conteneur depuis son démarrage. En théorie, c’est pratique — en pratique, les logs défilent comme une cascade et on ne voit plus rien.

La première fois que j’ai rencontré ce cas, le conteneur tournait depuis trois jours et accumulait des dizaines de milliers de lignes. Le terminal défilait sans fin ; j’ai fixé l’écran longtemps sans attraper un seul ERROR. J’ai appris plus tard qu’il ne faut surtout pas utiliser cette commande « nue » dans ce genre de situation.

Quand utiliser cette commande de base ?

Honnêtement, dans deux cas seulement :

• le conteneur vient de démarrer et les logs sont encore limités ;
• vous devez exporter l’intégralité des logs dans un fichier pour archivage.

Dans tous les autres cas, évitez-la. Il existe de bien meilleures approches.

2. Consulter les N dernières lignes

C’est l’astuce que j’utilise le plus au quotidien :

docker logs --tail 50 my-container

Le paramètre --tail n’affiche que les N dernières lignes. J’ai l’habitude de prendre 50 ou 100 lignes : assez pour repérer un problème, sans se noyer dans l’information.

Scénario concret :

La semaine dernière, notre API est devenue soudainement lente. Ma première réaction :

docker logs --tail 100 api-server

Dans les 100 dernières lignes, j’ai immédiatement vu des avertissements de timeout de connexion à la base de données. Le périmètre du problème s’est réduit tout de suite — ce n’était pas un bug de code, mais un souci côté base de données.

L’idée centrale : commencer par les logs récents pour orienter le diagnostic. Si vous ne trouvez rien, creusez avec d’autres méthodes.

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

Commencer →Pub

Au passage, si vous voulez cibler un problème sans savoir combien de lignes lire, commencez par 50. Passez à 100, puis 200 si nécessaire. C’est bien plus efficace que de tout charger d’un coup.

Surveillance en temps réel

3. Suivre le flux de logs en direct

Cette astuce est particulièrement utile en débogage — comme tail -f sous Linux, elle permet de surveiller les logs au fil de l’eau :

docker logs -f my-container

Avec le paramètre -f (follow), les logs continuent de s’afficher et chaque nouvelle ligne apparaît immédiatement.

Je l’utilise surtout dans ces situations :

1. Surveiller le démarrage d’un conteneur
   Après le déploiement d’un service, je lance le conteneur puis j’ajoute -f pour observer les logs de démarrage. Si un fichier de configuration est incorrect, l’erreur apparaît tout de suite — pas besoin d’attendre que le service tombe.

2. Capturer un bug au moment où il se produit
   Un bug ne se déclenche que dans un scénario précis ? Je lance docker logs -f, je reproduis l’action, et l’erreur apparaît en direct.

Une combinaison encore plus pratique :

docker logs -f --tail 100 my-container

Vous voyez les 100 dernières lignes d’historique, puis le suivi en temps réel. Au démarrage de la surveillance, vous comprenez d’abord ce qui s’est passé récemment, puis vous observez la suite.

À ce propos, un collègue utilisait -f pour déboguer un conteneur et a fixé l’écran pendant une demi-heure sans qu’une seule ligne ne bouge — le conteneur était déjà arrêté. Avant d’utiliser -f, vérifiez que le conteneur tourne : docker ps.

Filtrage précis

4. Filtrer par plage horaire

C’est l’une de mes fonctionnalités préférées. Vous connaissez ce scénario : la supervision signale « une erreur à 3 h du matin », mais vous ne voyez l’alerte qu’au réveil et des milliers de lignes se sont accumulées. Comment retrouver les logs de ce moment précis ?

Utilisez --since et --until :

# Logs après un instant donné
docker logs --since "2025-12-18T03:00:00" my-container

# Logs dans une plage horaire
docker logs --since "2025-12-18T03:00:00" --until "2025-12-18T04:00:00" my-container

Le format de date suit la norme ISO 8601, mais Docker accepte aussi des durées relatives :

# Logs de la dernière heure
docker logs --since 1h my-container

# Logs des 30 dernières minutes
docker logs --since 30m my-container

# Logs depuis hier
docker logs --since 24h my-container

Cas concret :

Un matin, notre service de commandes était tombé vers 4 h ; à 9 h, cinq heures de logs s’étaient accumulées. J’ai lancé :

docker logs --since "2025-12-18T03:30:00" --until "2025-12-18T04:30:00" order-service

Une heure de logs autour de l’incident — et j’ai trouvé immédiatement la stack trace d’un dépassement de mémoire. En consultant tout le flux, j’aurais probablement perdu une demi-journée.

5. Afficher les horodatages

Parfois vous voyez un ERROR dans les logs, mais vous ignorez quand il s’est produit — impossible de le recouper avec les données de supervision. Il faut alors les horodatages :

docker logs -t my-container

Le paramètre -t ajoute un horodatage devant chaque ligne, par exemple :

2025-12-18T10:23:45.123456789Z [INFO] Server started
2025-12-18T10:23:47.234567890Z [ERROR] Database connection failed

Vous savez exactement quand chaque log a été émis. Je combine souvent ce paramètre avec d’autres :

# Logs des 30 dernières minutes avec horodatages
docker logs -t --since 30m my-container

# Suivi en temps réel avec horodatages
docker logs -f -t my-container

Pour l’analyse de performance, les horodatages sont particulièrement utiles : vous voyez précisément combien de temps une requête met du départ à la fin, et où se situe le goulot d’étranglement.

6. Filtrer avec grep

Les logs ne contiennent que des INFO et vous voulez uniquement les ERROR ? Utilisez grep :

docker logs my-container | grep "ERROR"

Seules les lignes contenant « ERROR » s’affichent. Mais attention à un piège :

Parfois grep ne trouve rien !

La première fois, j’étais perplexe : les logs du conteneur contenaient bien des ERROR, mais grep ne renvoyait rien. La cause : Docker peut écrire les logs sur stderr (flux d’erreur standard) plutôt que sur stdout (flux de sortie standard), et le pipe | ne traite que stdout par défaut.

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

Obtenir -15 % →Pub

La solution : rediriger stderr vers stdout :

docker logs my-container 2>&1 | grep "ERROR"

2>&1 redirige stderr (descripteur 2) vers stdout (descripteur 1), et grep capture alors tous les logs.

Combinaisons plus utiles :

# Contexte de 10 lignes autour de chaque ERROR
docker logs my-container 2>&1 | grep -C 10 "ERROR"

# Recherche insensible à la casse
docker logs my-container 2>&1 | grep -i "error"

# 20 dernières erreurs
docker logs -t my-container 2>&1 | grep -i "error" | tail -20

Le paramètre -C 10 est très pratique : il affiche 10 lignes avant et après chaque correspondance. Parfois, la ligne ERROR seule ne suffit pas — il faut le contexte pour comprendre la séquence complète.

Astuces avancées

7. Emplacement physique du fichier de logs

Vous le savez peut-être déjà : les logs des conteneurs sont aussi stockés physiquement sur l’hôte. Pour connaître le chemin :

docker inspect --format='{{.LogPath}}' my-container

Le résultat ressemble généralement à :

/var/lib/docker/containers/abc123.../abc123...-json.log

À quoi ça sert ?

1. Consulter le fichier directement
   docker logs peut solliciter le daemon Docker (surtout avec de gros volumes de logs) ; lire le fichier est parfois plus rapide :

   sudo tail -f /var/lib/docker/containers/abc123.../abc123...-json.log

2. Sauvegarder les logs
   Besoin d’archiver ? Copiez simplement le fichier :

   sudo cp /var/lib/docker/containers/abc123.../abc123...-json.log ./backup/

3. Analyser avec des outils plus puissants
   Ouvrir le fichier dans vim ou un autre éditeur offre des fonctions de recherche plus flexibles que grep.

Attention : ce fichier est au format JSON — chaque ligne est encapsulée dans un objet JSON, ce qui peut sembler confus. Pour du texte brut lisible, docker logs reste plus pratique.

Exporter les logs dans un fichier :

Pour une sauvegarde en texte brut :

docker logs my-container > container.log

L’export est en texte simple, prêt pour l’analyse ou le partage.

Bonnes pratiques en production

8. Configurer la rotation des logs (éviter le disque plein)

Franchement, c’est la configuration la plus souvent oubliée en production — et pourtant la plus critique.

Cas réel désastreux :

J’ai vu une fois un conteneur tourner plusieurs mois sans rotation. Le fichier de logs a grossi jusqu’à saturer le disque de l’hôte. Tous les conteneurs du serveur sont tombés, la base de données ne pouvait plus écrire, le site était hors ligne. Deux heures de diagnostic pour découvrir que les logs avaient tout rempli.

Comment éviter ça ?

Configurez la rotation des logs (log rotation). Dans /etc/docker/daemon.json :

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

Signification des paramètres :

• max-size : taille maximale d’un fichier de log (10 Mo)
• max-file : nombre maximum de fichiers conservés (3)

Avec cette configuration, chaque conteneur occupe au maximum 10 Mo × 3 = 30 Mo d’espace de logs. Quand un fichier atteint 10 Mo, Docker en crée un nouveau ; au-delà de 3 fichiers, le plus ancien est supprimé.

Appliquer la configuration :

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

Commencer →Pub

Après modification de daemon.json, redémarrez Docker :

sudo systemctl restart docker

Attention : le redémarrage de Docker relance tous les conteneurs — choisissez une fenêtre de maintenance adaptée en production.

Configuration pour un conteneur spécifique :

Pour un seul conteneur, au lancement :

docker run -d \
  --log-opt max-size=10m \
  --log-opt max-file=3 \
  my-image

Les autres conteneurs ne sont pas affectés.

9. Stratégie de gestion des logs en production

Après un certain temps avec docker logs, vous remarquerez un problème : quand le volume de logs est élevé, la commande devient lente et peut bloquer le terminal. docker logs sollicite fortement le daemon Docker.

Arbitrages selon la taille du projet :

• Petit projet (1 à 10 conteneurs) :

  • docker logs + rotation des logs = suffisant
  • Simple, sans infrastructure supplémentaire

• Projet moyen ou grand (plus de 10 conteneurs, ou architecture microservices) :

  • Un système de logs centralisé devient indispensable
  • Solution courante : ELK (Elasticsearch + Logstash + Kibana)
  • Autres options : Loki, Fluentd, Splunk

Pourquoi les grands projets ne peuvent pas s’en tenir à docker logs ?

1. Performance : consulter les logs de plusieurs conteneurs en parallèle surcharge le daemon Docker
2. Agrégation : en microservices, une requête peut traverser 10 services — les logs sont dispersés dans 10 conteneurs
3. Historique : docker logs ne couvre que le conteneur actuel ; après un redémarrage, les anciens logs disparaissent
4. Collaboration : demander à ops, dev et QA de se connecter au serveur pour taper des commandes n’est pas viable

Mes recommandations :

• Vous débutez avec Docker ? Maîtrisez d’abord docker logs
• Projet personnel ou petite équipe ? Configurez la rotation et utilisez docker logs
• Plus de 10 conteneurs en production ? Envisagez sérieusement un système centralisé
• Architecture microservices ? Les logs centralisés ne sont pas un luxe — c’est une nécessité

Conclusion

Revenons au scénario de 3 h du matin du début de l’article. Si je revivais la situation aujourd’hui, voici ce que je ferais :

1. docker logs --tail 100 payment-service pour un aperçu rapide des logs récents
2. Si rien d’évident, filtrage par plage : docker logs --since "2025-12-18T03:00:00" --until "2025-12-18T03:30:00" payment-service
3. Horodatages + grep : docker logs -t payment-service 2>&1 | grep -i "error" | tail -20

Trois étapes, deux minutes maximum — diagnostic terminé.

C’est la valeur d’une bonne maîtrise de docker logs : pas mémoriser tous les paramètres, mais savoir quelle combinaison utiliser selon le contexte.

Dernier rappel : si vos conteneurs tournent en production, configurez la rotation des logs maintenant. N’attendez pas que le disque soit plein. Quelques lignes de configuration peuvent vous éviter une grosse crise.

Fiche de référence rapide

# Consultation de base
docker logs <nom-du-conteneur>                    # Tous les logs
docker logs --tail 50 <nom-du-conteneur>         # 50 dernières lignes

# Surveillance en temps réel
docker logs -f <nom-du-conteneur>                # Suivi en direct
docker logs -f --tail 100 <nom-du-conteneur>     # 100 dernières lignes + suivi

# Filtrage par date
docker logs --since 1h <nom-du-conteneur>        # Dernière heure
docker logs --since "2025-12-18T03:00:00" <nom-du-conteneur>  # Après une date précise

# Recherche ciblée
docker logs -t <nom-du-conteneur>                           # Horodatages
docker logs <nom-du-conteneur> 2>&1 | grep -i "error"      # Rechercher les erreurs
docker logs <nom-du-conteneur> 2>&1 | grep -C 10 "error"   # Erreurs avec contexte

# Astuces avancées
docker inspect --format='{{.LogPath}}' <nom-du-conteneur>   # Chemin du fichier de logs
docker logs <nom-du-conteneur> > log.txt                   # Exporter les logs

Gardez cette fiche sous la main : la prochaine fois qu’un conteneur posera problème, vous saurez quoi lancer.