Pilotes de journalisation Docker et bases de l’observabilité des conteneurs : guide pratique d’implémentation

Introduction

Les pilotes de journalisation Docker et les bases de l’observabilité des conteneurs sont essentiels car les conteneurs démarrent rapidement, mais les exploiter de manière cohérente est plus difficile. Un guide pratique montre quoi configurer, quelle commande prouve que la configuration fonctionne et à quoi ressemble l’échec lorsque le paramétrage est absent, mal fait ou transféré sur un hôte de type production.

Ce guide explique le fonctionnement de la journalisation Docker, comment inspecter les journaux des conteneurs, l’influence des pilotes de logs sur l’observabilité et comment prévenir la croissance incontrôlée du disque due à des fichiers de logs non rotés.

L’objectif est pratique : comprendre les éléments mobiles, les tester localement et éviter les surprises lorsque le même schéma est réutilisé dans un pipeline CI/CD (Continuous Integration/Continuous Deployment : intégration continue / déploiement continu) ou un environnement de type production.

Vue d’ensemble du workflow

Commencez par identifier la ressource, le changement de configuration et la commande de vérification. Gardez le workflow simple : configurez une seule chose, vérifiez l’état observé, puis documentez ce qui casse lorsque le paramétrage est manquant, mal configuré ou déplacé sur un hôte de type production.

Concepts clés : journalisation Docker, pilotes de logs, docker logs, rotation des logs, observabilité des conteneurs. Les domaines connexes tels que le débogage Docker, le dépannage en production et les opérations sur les conteneurs sont importants car le choix du stockage influence le déploiement, le débogage, la sauvegarde et les décisions de rollback.

Vérifications pratiques

Lister les conteneurs en cours avec détails : docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"
Afficher les dernières lignes de log : docker logs <conteneur> --tail 100
Inspecter la configuration du conteneur : docker inspect <conteneur> (affiche montages, réseaux, variables d’environnement, état de santé)
Pour les projets Compose : docker compose ps, docker compose logs -f <service>, docker compose exec <service> sh

Connaissance de l’emplacement des données

Avant de modifier les conteneurs, confirmez où les fichiers sont stockés.

Volume nommé (géré par Docker) : app_data:/var/lib/app – plus facile à réutiliser lors des reconstructions.
Bind mount (répertoire hôte) : ./data:/var/lib/app – utile en développement local mais peut exposer des problèmes de permissions, de portabilité et de sauvegarde si le chemin n’existe pas sur une autre machine.

Test de redémarrage

Effectuez un petit test de type production : arrêtez le conteneur, recréez-le et vérifiez que l’application retrouve bien les fichiers attendus. Si les données disparaissent, le service écrivait probablement dans la couche writable du conteneur au lieu d’un volume ou d’un mount.

Principaux pilotes de logs en un coup d’œil

Pilote	Usage courant	Support rotation	Destination distante
json-file	Défaut sur la plupart des hôtes Linux ; stockage local en fichiers	Taille et nombre via `max-size`, `max-file`	Non
syslog	Serveur syslog centralisé	Géré par le démon syslog	Oui (UDP/TCP)
journald	Intégration au journal systemd	Géré par journald	Non (local)
gelf	Graylog / Logstash	Géré par le point de terminaison distant	Oui (UDP/TCP)
fluentd	Forwarder Fluentd	Géré par Fluentd	Oui (TCP)

Hypothèses cachées à faire émerger

Le pilote par défaut sur de nombreuses distributions est json-file, mais certaines (ex. Fedora, RHEL) utilisent journald par défaut.
Le chemin hôte /var/lib/docker doit disposer d’assez d’espace libre pour les fichiers de logs.
L’utilisateur exécutant Docker doit avoir la permission de lire le répertoire de logs pour inspection manuelle.
Dans les runners CI, le pilote de logs par défaut peut être none ; définissez explicitement le pilote dans la définition du job.

Plan pilote local

Appliquez le même workflow à un pilote local. Choisissez un seul service, activez un pilote de logs avec rotation et vérifiez le comportement avant d’étendre.

Exemple : activer le pilote json‑file avec rotation basée sur la taille

docker run -d \
  --name webapp \
  --log-driver json-file \
  --log-opt max-size=10m \
  --log-opt max-file=3 \
  nginx:alpine

Vérifier le pilote et ses options

docker inspect --format '{{.HostConfig.LogConfig}}' webapp
# Résultat attendu : map[Type:json-file Config:map[max-size:10m max-file:3]]

Observer la rotation en action

Générez suffisamment de données de log pour déclencher la rotation, puis listez les fichiers de logs sur l’hôte :

# Trouver le chemin du log
docker inspect --format '{{.LogPath}}' webapp
# Exemple de sortie : /var/lib/docker/containers/<id>/<id>-json.log
ls -lh /var/lib/docker/containers/<id>/

Vous devriez voir jusqu’à trois fichiers, chacun ≤ 10 MiB. Sans max-size et max-file, le fichier de log unique grossit jusqu’à remplir le disque hôte – une défaillance courante en production.

Équivalent Compose

services:
  webapp:
    image: nginx:alpine
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

Lancez docker compose up -d et vérifiez avec docker compose logs -f webapp.

Commandes de vérification supplémentaires

Afficher l’utilisation disque des logs : docker system df -v (regardez la colonne "Log\)).
Filtrer les logs par période : docker logs --since 1h --until 2h webapp.
Suivre la sortie en direct avec horodatage : docker logs --follow --timestamps webapp.

Simuler la croissance des logs pour test

docker run --rm \
  --log-driver json-file \
  --log-opt max-size=1m \
  --log-opt max-file=2 \
  alpine sh -c 'for i in $(seq 1 5000); do echo "log line $i\); done'

Après la fin de la commande, inspectez le répertoire de logs du conteneur pour confirmer la présence de deux fichiers rotés d’environ 1 MiB chacun.

Conclusion

Les pilotes de journalisation Docker et les bases de l’observabilité des conteneurs fonctionnent le mieux lorsque l’équipe considère la configuration comme quelque chose à tester, pas seulement à copier. Gardez les exemples petits, exécutez les commandes localement et confirmez le comportement attendu avant d’ajouter d’autres services ou de l’automatisation.

Prochaine étape : choisissez un service, documentez les commandes exactes utilisées pour le construire, le lancer, l’inspecter, l’arrêter et le recréer. Comparez les résultats avec les domaines connexes tels que le débogage Docker, le dépannage en production et les opérations sur les conteneurs afin que l’implémentation s’intègre au modèle d’exploitation global.

Un workflow de conteneur fiable rend l’échec visible : les logs sont faciles à localiser, les données persistantes survivent aux reconstructions de conteneurs, et le comportement local est suffisamment proche de la production pour détecter les erreurs tôt.