Journaux et supervision des conteneurs

Superviser des conteneurs, c'est collecter leurs journaux (ce qu'ils écrivent sur leur sortie standard), surveiller leur état et leur santé, et mesurer leur consommation de processeur, de mémoire et de disque, pour être alerté avant que les utilisateurs ne le soient. Ce chapitre règle la journalisation de Docker (pilotes, rotation, centralisation vers le serveur de journaux), puis branche srv-gestion sur Zabbix et Grafana pour les métriques et les alertes, et sur Wazuh pour les événements de sécurité.

Où vont les journaux d'un conteneur

Une application conteneurisée écrit ses journaux sur sa sortie standard et sa sortie d'erreur, pas dans des fichiers. Le démon les capture et les confie à un pilote de journalisation (logging driver). docker logs et docker compose logs les relisent :

docker compose logs --tail 100 -t api      # 100 dernières lignes, avec l'horodatage de Docker
docker compose logs -f --since 15m         # tous les services, en continu, depuis 15 minutes

Le pilote peut aussi se régler service par service dans compose.yaml :

services:
  api:
    logging:
      driver: local
      options:
        max-size: "20m"
        max-file: "5"

Centraliser les journaux vers srv-journaux

Des journaux qui restent sur srv-gestion disparaissent avec lui, et un attaquant qui prend la main sur le serveur peut les effacer. Chez Sorbier, tous les serveurs envoient leurs journaux à srv-journaux (192.168.10.180), en syslog chiffré par TLS sur le port TCP 6514, la même règle que pour le serveur web de la DMZ (cours Cybersécurité des infrastructures). Deux façons de faire :

1. Le pilote journald, et l'envoi par l'hôte. Les conteneurs écrivent dans le journal de systemd de srv-gestion, et le service rsyslog de l'hôte, déjà configuré pour transmettre ses journaux à srv-journaux, transmet aussi ceux des conteneurs. Dans daemon.json :

{
  "log-driver": "journald",
  "log-opts": {
    "tag": "{{.Name}}"
  }
}

Si srv-journaux est injoignable, rien ne se perd : les journaux attendent dans le journal local, et les conteneurs ne sont pas gênés.

2. Le pilote syslog, directement depuis Docker, service par service :

services:
  proxy:
    logging:
      driver: syslog
      options:
        syslog-address: "tcp+tls://192.168.10.180:6514"
        syslog-tls-ca-cert: "/etc/ssl/certs/sorbier-ca.pem"
        syslog-format: "rfc5424"
        tag: "{{.Name}}"

Plus direct, mais plus fragile : par défaut, si le serveur syslog est injoignable au démarrage, le conteneur ne démarre pas.

Surveiller l'état et la santé

Un conteneur peut être en marche sans que son service fonctionne. Trois signaux à surveiller :

Le flux d'événements du démon montre tout ce qui arrive, en direct :

docker events --filter event=die --filter event=health_status --filter event=oom

2026-11-03T14:02:11.508+01:00 container health_status: unhealthy 8b1e… (image=ghcr.io/sorbier/sorbier-frais:2.5.0, name=gestion-api-1)
2026-11-03T14:02:41.932+01:00 container die 8b1e… (exitCode=1, image=ghcr.io/sorbier/sorbier-frais:2.5.0, name=gestion-api-1)

Les métriques : docker stats et au-delà

docker stats donne la consommation instantanée de chaque conteneur (chapitre 3). Pour garder un historique, tracer des courbes et être alerté, on branche l'hôte sur l'outil de supervision de l'entreprise. Ce qu'il faut surveiller sur un hôte Docker :

Superviser Docker avec Zabbix et Grafana

Chez Sorbier, les métriques et les alertes sont dans Zabbix, et les tableaux de bord dans Grafana, branché sur Zabbix (cours Supervision). Zabbix fournit un modèle prêt à l'emploi, « Docker by Zabbix agent 2 » : l'agent 2, installé sur srv-gestion, interroge l'API du démon par son socket et découvre automatiquement chaque conteneur (état, processeur, mémoire, réseau, redémarrages), avec des déclencheurs prêts à l'emploi.

1. Sur srv-gestion, installe l'agent 2 depuis le dépôt de Zabbix et déclare le serveur Zabbix dans /etc/zabbix/zabbix_agent2.conf (Server= et ServerActive=).

2. Donne à l'agent l'accès au socket. La documentation propose d'ajouter l'utilisateur zabbix au groupe docker, puis de redémarrer l'agent :

   bashCopier le code de la section Superviser Docker avec Zabbix et Grafana

   sudo usermod -aG docker zabbix
   sudo systemctl restart zabbix-agent2
   

3. Dans l'interface de Zabbix, menu Data collection > Hosts, ouvre l'hôte srv-gestion et ajoute le modèle « Docker by Zabbix agent 2 » à côté de « Linux by Zabbix agent ».

4. Vérifie la remontée dans Monitoring > Latest data, filtré sur l'hôte.

Complète la supervision de l'hôte par celle du service rendu : un scénario web Zabbix qui ouvre https://gestion.ad.sorbier.example/api/health toutes les minutes vérifie, du point de vue des utilisateurs, que la chaîne complète (DNS, pare-feu, proxy, API, base) fonctionne. L'expiration du certificat se surveille avec le modèle « Website certificate by Zabbix agent 2 » : sur l'hôte srv-gestion, la macro {$CERT.WEBSITE.HOSTNAME} reçoit le nom gestion.ad.sorbier.example, et la macro {$CERT.EXPIRY.WARN} (7 jours par défaut) passe à 21 jours, pour avoir le temps de faire signer un nouveau certificat.

Les événements de sécurité avec Wazuh

La supervision dit si le service fonctionne ; la détection dit si quelqu'un fait quelque chose d'anormal. L'agent Wazuh installé sur srv-gestion peut écouter les événements de Docker grâce à son module Docker listener : chaque pull, création, démarrage, arrêt et chaque docker exec dans un conteneur remonte au serveur Wazuh. On l'active dans /var/ossec/etc/ossec.conf de l'agent :

<wodle name="docker-listener">
  <disabled>no</disabled>
</wodle>

Le module est écrit en Python et demande la bibliothèque Python docker sur l'hôte, dans la version indiquée par la documentation de ta version de Wazuh. Ce qu'on cherche à repérer :

• un docker exec dans un conteneur de production en dehors d'une intervention planifiée ;
• la création d'un conteneur privilégié, ou qui monte la racine de l'hôte ou le socket Docker ;
• une image inconnue téléchargée sur le serveur ;
• un conteneur qui redémarre en boucle (souvent le signe d'un problème, parfois d'une attaque).

La collecte des journaux de sécurité et la corrélation des alertes sont traitées dans le cours Cybersécurité des infrastructures.

Exercices

02:14:07 image pull alpine:3.24
02:14:09 container create (image=alpine:3.24, name=maintenance)
02:14:09 container start (name=maintenance)
02:14:40 container die (exitCode=0, name=maintenance)
02:14:41 container destroy (name=maintenance)