Drivers de logs Docker et bases de l'observabilité des conteneurs : guide pratique

Introduction

Les drivers de logs Docker et les bases de la container observability deviennent critiques dès que l'on opère des services au-delà d'un simple prototype. Démarrer un conteneur en local est facile ; le faire tourner de façon prévisible en CI/CD ou en production l'est beaucoup moins. Un guide utile explique quoi configurer, quelle commande démontre que la configuration fonctionne, et comment reconnaître l'échec quand la mise en place est incomplète ou erronée.

Ce guide reste volontairement pratique. Il connecte Docker logging, logging drivers, docker logs, log rotation et container observability pour vous aider à passer du concept à la vérification locale. Objectif : comprendre les pièces mobiles, tester sur votre machine, et éviter les mauvaises surprises quand vous réutilisez le même pattern en environnement proche de la production.

Aperçu du flux de travail

La démarche conseillée pour Docker logging est directe :

Identifier la ressource visée

Conteneur unique (docker run) ou service Docker Compose.
Application et image, réseaux, volumes, limites (CPU/RAM), variables d'environnement.

Appliquer une configuration qui a un impact mesurable

Choix du logging driver (souvent "json-file" en local), ou "journald" selon l'hôte.
Options de log rotation (max-size, max-file) pour éviter de remplir le disque.
Pour Compose : section logging par service.

Prouver que cela marche, puis documenter l'échec attendu

Vérifier la sortie avec docker logs <container> --tail 100 et docker compose logs -f <service>.
Inspecter la config : docker inspect <container> pour trouver réseaux, montages, env et santé.
Documenter ce qui casse si la config manque (ex. driver "none", pas de rotation, app qui n'écrit pas sur stdout/stderr).

Commandes de base pour observer rapidement :

Conteneurs actifs : docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"
Dernières lignes de logs : docker logs <container> --tail 100
Inspecter un conteneur : docker inspect <container>
Avec Compose : docker compose ps, docker compose logs -f <service>, docker compose exec <service> sh

Gardez à l'esprit que les hypothèses locales (chemins bind-mount, tags d'image, noms de réseaux, fichiers .env, limites de ressources, permissions) varient d'une machine à l'autre et entre runners et hôtes de production. Mieux vaut les rendre explicites avant d'industrialiser.

Plan pilote local

Le plan pilote local doit ressembler à une mini-prod : configurer, vérifier, et rejouer. Voici un scénario reproductible qui couvre Docker logging, logging drivers, log rotation, Compose logging, et les flux stdout/stderr.

S'assurer que l'application écrit bien sur stdout/stderr

Les outils comme docker logs lisent les flux stdout/stderr du processus PID 1.
Évitez d'écrire exclusivement dans un fichier interne au conteneur (sinon, aucun log ne sortira via docker logs).

Exemple minimal avec Python (Dockerfile) :

FROM python:3.12-slim
WORKDIR /app
COPY app.py .
# app.py doit écrire sur stdout/stderr
CMD ["python", "app.py"]

Exemple d'application (app.py) qui log sur stdout et stderr :

import sys, time
i = 0
while True:
    print(f"INFO tick={i}", flush=True)
    print(f"WARN tick={i}", file=sys.stderr, flush=True)
    time.sleep(1)
    i += 1

Construisez et lancez :

docker build -t demo-logs: local .
docker run --name demo --rm demo-logs: local
# Ouvrez un autre terminal
docker logs -f demo

Vous devez voir alterner des lignes INFO (stdout) et WARN (stderr).

Configurer le logging driver et la rotation des logs

Pour un test local, "json-file" avec rotation est un choix courant.
Évitez de laisser des logs grandir sans limite.

En ligne de commande :

docker run -d --name demo \
  --log-driver json-file \
  --log-opt max-size=10m \
  --log-opt max-file=3 \
  demo-logs: local

docker logs --tail 50 demo

Faire la même chose avec Docker Compose

services:
  app:
    build: .
    image: demo-logs: local
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

Lancez et suivez les logs :

docker compose up -d
docker compose logs -f app

Vérifier l'état et le comportement attendu

Trop de logs ? Confirmez la rotation : si max-file: 3, les fichiers plus anciens disparaissent au fur et à mesure.
La commande de lecture :

docker inspect --format='{{.HostConfig.LogConfig.Type}}' demo

Si le driver est "none" ou un driver ne prenant pas en charge la lecture via docker logs, vous n'obtiendrez rien. Basculez sur "json-file" (ou un driver compatible avec votre hôte) pour faciliter l'observation locale.

Quand des fichiers sont impliqués, vérifiez où ils sont stockés avant de recréer le conteneur :

Données et redémarrages (proche de la prod)

Volume nommé, ex. app_data:/var/lib/app : géré par Docker, facile à réutiliser après rebuild.
Bind mount, ex. ./data:/var/lib/app : pratique en dev local, mais peut exposer des soucis de permissions et de portabilité.

Faites un test de redémarrage :

docker compose down && docker compose up -d
# Ou côté docker run
docker rm -f demo && docker run ...

Si des données attendues disparaissent, c'est probablement que l'application écrivait dans le filesystem du conteneur au lieu d'un volume/montage.

Modèles stdout/stderr, options Compose et dépannage

Modèle conseillé : l'application écrit ses logs applicatifs vers stdout/stderr. Les niveaux (INFO/WARN/ERROR) et formats (texte/JSON) restent visibles via docker logs et docker compose logs.
Compose logging : définissez logging.driver et logging.options par service. Évitez de définir driver: "none" sauf besoin explicite.
Rotation (log rotation) : spécifiez max-size et max-file pour contenir la croissance. Sur un service très bavard, une valeur trop faible peut supprimer trop vite l'historique ; adaptez au besoin.

Dépannage des logs manquants ou incomplets :

Le driver bloque la lecture

docker inspect --format='{{.HostConfig.LogConfig.Type}}' <container>

Si vous voyez "none" (ou un driver qui ne supporte pas docker logs), changez la configuration et recréez le conteneur.

L'application n'écrit pas sur stdout/stderr

Rejoignez le conteneur : docker compose exec <service> sh puis regardez si un fichier de log interne grossit.
Ajustez l'app ou son entrée de commande (Dockerfile/CMD) pour rediriger les logs vers stdout/stderr.

La rotation a supprimé l'historique

Si max-file est atteint, les segments anciens peuvent avoir été supprimés. Augmentez max-file ou exportez les logs ailleurs si vous devez conserver l'historique.

Le conteneur n'est pas démarré ou redémarre en boucle

docker ps -a pour vérifier Status.
docker logs --tail 200 <container> pour capter le dernier crash.

Permissions et chemins en Compose

Un bind mount mal résolu peut empêcher l'app d'écrire et donc de produire des logs utiles (si l'app s'arrête). Vérifiez les chemins et l'utilisateur effectif dans le conteneur.

Conclusion

Docker logging drivers et container observability fonctionnent mieux quand la configuration est traitée comme un sujet à tester, pas seulement à copier. Le chemin le plus sûr consiste à garder des exemples petits, exécuter les commandes localement et confirmer le comportement attendu avant d'ajouter d'autres services ou d'automatiser.

Prochaine étape : choisissez un service et documentez précisément les commandes pour construire, lancer, inspecter, arrêter et recréer. Comparez ensuite le résultat avec les domaines proches (Docker debugging, production troubleshooting, container operations) afin que l'implémentation s'inscrive dans votre modèle d'exploitation. Un workflow fiable rend l'échec visible : des logs faciles à trouver, des données persistantes malgré les rebuilds, et un comportement local suffisamment proche de la production pour détecter les erreurs tôt.