Chapitre 04
Journaux avec `journalctl`

Objectifs du chapitre

Comprendre le journal systemd (journald) : un seul endroit pour tous les logs du système et des services.
Filtrer efficacement : par unité (-u), par priorité (-p), par temps (--since, -b), suivre en direct (-f).
Rendre le journal persistant (survivre aux reboots) et maîtriser sa rotation pour ne pas remplir le disque.
Corréler un incident dans le temps : relier une panne du service edge à ce qui s'est passé juste avant.

1. Un journal unique pour tout le système

Sur une Debian moderne, on ne court plus après une dizaine de fichiers dans /var/log. Le démon journald collecte au même endroit : la sortie de chaque service géré par systemd, les messages du noyau (dmesg), l'authentification, le démarrage… le tout indexé et interrogeable par journalctl. Sans argument, il déroule tout, du plus ancien au plus récent ; on ne fait jamais ça sur un edge qui tourne depuis 87 jours — on filtre.

maint@edge-cell12:~$ journalctl -e
# -e (end) saute directement à la fin, les messages les plus récents
Jul 04 08:20:41 edge-cell12 edge-gateway[834]: OPC-UA session established (ns=3;s=Line12)
Jul 04 08:20:42 edge-cell12 edge-gateway[834]: published 128 tags to mqtt://localhost:1883

Chaque ligne de journal porte les mêmes colonnes : horodatage, hostname, identifiant du service[PID], puis le message. C'est cette régularité qui rend le filtrage puissant : on peut trancher par n'importe laquelle de ces dimensions.

2. Filtrer par unité : `-u`

Le filtre le plus utile : ne voir que les lignes d'un service.

maint@edge-cell12:~$ journalctl -u edge-gateway -e
Jul 04 08:03:09 edge-cell12 systemd[1]: Starting Edge Gateway (OPC-UA → MQTT)...
Jul 04 08:03:11 edge-cell12 docker[21874]: Error: port 1883 already allocated
Jul 04 08:03:11 edge-cell12 systemd[1]: edge-gateway.service: Failed with result 'exit-code'.
Jul 04 08:05:22 edge-cell12 systemd[1]: Starting Edge Gateway (OPC-UA → MQTT)...
Jul 04 08:05:24 edge-cell12 edge-gateway[834]: OPC-UA session established

On lit toute la vie du service : l'échec de 08:03 (port occupé), puis la reprise réussie de 08:05. C'est exactement le fil qu'on veut après un systemctl status … failed (chapitre 3).

Sur un edge, les logs applicatifs sont souvent doubles : journalctl -u edge-gateway montre ce que systemd et le lanceur voient, mais l'intérieur du conteneur se lit plutôt avec docker logs (chapitre 6). Les deux sont complémentaires : journald pour « le service a-t-il démarré/planté ? », docker logs pour « que dit l'application à l'intérieur ? ».

3. Filtrer par priorité : `-p`

Chaque message porte une priorité (niveau de gravité, hérité de syslog), de 0 (le plus grave) à 7 (le plus verbeux) :

N°	Nom	Sens
0–2	`emerg`, `alert`, `crit`	critique : système/matériel en péril
3	`err`	erreur : un service a échoué
4	`warning`	avertissement
5–6	`notice`, `info`	information normale
7	`debug`	détail de mise au point

-p err ne garde que le niveau err et au-dessus (donc err, crit, alert, emerg) — la façon la plus rapide de voir « qu'est-ce qui a vraiment cloché » :

maint@edge-cell12:~$ journalctl -p err -b
Jul 04 08:03:11 edge-cell12 docker[21874]: Error: port 1883 already allocated
Jul 04 06:14:55 edge-cell12 kernel: EXT4-fs warning: ext4_dx_add_entry: Directory index full

4. Filtrer par temps : `-b`, `--since`

Le temps est la dimension reine du diagnostic. Deux outils :

Par démarrage : `-b`

maint@edge-cell12:~$ journalctl --list-boots | tail -3
 -2 8f3c... Tue 2026-04-08 06:13:40 CEST—...
 -1 a10d... Fri 2026-06-20 22:01:11 CEST—...
  0 7a1e... Sat 2026-07-04 06:14:02 CEST—Sat 2026-07-04 08:22:10 CEST

journalctl -b = journal depuis le dernier démarrage (le boot courant, index 0).
journalctl -b -1 = le boot précédent — précieux pour voir ce qui s'est passé juste avant un redémarrage inattendu.

Par fenêtre : `--since` / `--until`

maint@edge-cell12:~$ journalctl -u edge-gateway --since "08:00" --until "08:10"
maint@edge-cell12:~$ journalctl --since "2 hours ago" -p warning
maint@edge-cell12:~$ journalctl --since yesterday -u chronyd

--since accepte l'heure, la date, ou des expressions humaines ("2 hours ago", yesterday, "09:15"). C'est ce qui permet de zoomer sur la minute d'un incident.

5. Suivre en direct : `-f`

Pour observer un service pendant qu'on agit (redémarrage, test), on suit le journal en temps réel, comme un tail -f :

maint@edge-cell12:~$ journalctl -u edge-gateway -f
Jul 04 08:24:01 edge-cell12 edge-gateway[834]: published 128 tags to mqtt://localhost:1883
Jul 04 08:24:03 edge-cell12 edge-gateway[834]: published 128 tags to mqtt://localhost:1883
^C  (Ctrl-C pour arrêter de suivre)

Le combo gagnant pour tester une remise en route : ouvrir journalctl -u edge-gateway -f dans une session, et lancer sudo systemctl restart edge-gateway dans une autre. Tu vois défiler en direct l'arrêt, le redémarrage et le rétablissement (ou l'échec) — bien plus parlant qu'un status figé.

6. Rendre le journal persistant

Par défaut, sur certaines installations, journald garde ses logs en RAM (dans /run/log/journal) — ils disparaissent à chaque reboot. Pour un edge, c'est un handicap : après un redémarrage nocturne inexpliqué, on n'a plus rien pour comprendre. On rend le journal persistant sur disque :

maint@edge-cell12:~$ journalctl --disk-usage
Archived and active journals take up 48.0M in the file system.
# S'il répond « in /run/... », c'est volatile. On persiste : 
maint@edge-cell12:~$ sudo mkdir -p /var/log/journal
maint@edge-cell12:~$ sudo systemd-tmpfiles --create --prefix /var/log/journal
# ou : Storage=persistent dans /etc/systemd/journald.conf, puis restart systemd-journald

7. Rotation : ne pas remplir le disque

Un journal persistant qui grossit sans limite finit par… remplir le disque — la panne nº 1 du chapitre 1. On borne sa taille dans /etc/systemd/journald.conf :

# /etc/systemd/journald.conf — bornes de taille
[Journal]
Storage=persistent
SystemMaxUse=500M          # le journal ne dépassera pas 500 Mo au total
SystemMaxFileSize=50M      # chaque fichier segment plafonne à 50 Mo
MaxRetentionSec=1month     # et on ne garde pas plus d'un mois

On peut aussi purger à la demande :

maint@edge-cell12:~$ sudo journalctl --vacuum-size=200M   # réduit à 200 Mo
maint@edge-cell12:~$ sudo journalctl --vacuum-time=2weeks  # efface plus vieux que 2 semaines

Attention au piège inverse : sur un edge à faible disque, un service applicatif trop bavard (qui logue chaque cycle) peut, même avec la rotation, écraser en continu les logs utiles — tu perds les erreurs importantes noyées sous le bruit, ou la rotation efface le passé en quelques heures. Deux réponses : réduire la verbosité de l'application, et pour les conteneurs, borner leurs logs Docker (option max-size, chapitre 6) séparément du journal systemd.

8. Corréler un incident dans le temps

Le vrai pouvoir de journald : mettre côte à côte, à la même minute, ce qu'ont dit tous les services. Scénario : le service edge est tombé à 08:03 ; qu'y avait-il autour ?

maint@edge-cell12:~$ journalctl --since "08:02" --until "08:04"
Jul 04 08:02:58 edge-cell12 systemd[1]: Stopping Docker Application Container Engine...
Jul 04 08:03:01 edge-cell12 kernel: Out of memory: Killed process 811 (mqtt-broker)
Jul 04 08:03:11 edge-cell12 docker[21874]: Error: port 1883 already allocated
Jul 04 08:03:11 edge-cell12 systemd[1]: edge-gateway.service: Failed with result 'exit-code'.

Sans filtre par unité, on voit la chaîne causale : le noyau a tué le broker MQTT par manque de mémoire (08:03:01), ce qui a laissé le port 1883 dans un état bancal, d'où l'échec du redémarrage (08:03:11). La cause racine n'est pas « port occupé » mais « OOM » — on ne l'aurait pas vue en filtrant seulement sur edge-gateway. Élargir la fenêtre, croiser les services : c'est là que le diagnostic se joue.

Côté S7-1500, le tampon de diagnostic (buffer de diag dans TIA) joue exactement ce rôle : un journal horodaté des événements du CPU (défauts, passages STOP, alarmes). La démarche est identique — on lit le buffer autour de l'heure de l'incident. L'edge et l'automate ont chacun leur journal ; un bon diagnostic croise souvent les deux, à condition qu'ils soient à la même heure — d'où l'importance du NTP, prochain chapitre.

Récapitulatif

journald centralise tous les logs ; on interroge avec journalctl, toujours en filtrant.
Filtres clés : -u <unité> (service), -p err (gravité), -b/-b -1 (boot courant/précédent), --since/--until (fenêtre), -f (suivi direct), -e (aller à la fin).
Rendre le journal persistant (/var/log/journal, Storage=persistent) pour survivre aux reboots.
Borner sa taille (SystemMaxUse, --vacuum-size) pour ne pas remplir le disque.
Diagnostic : élargir la fenêtre temporelle et croiser les services révèle la chaîne causale (ex. un OOM qui provoque un « port occupé » en aval).

Exercices

Exercice 1 — Les erreurs depuis le dernier boot

Tu arrives sur un edge et veux, en une commande, ne voir que les erreurs survenues depuis le dernier démarrage. Laquelle ?

Voir la solution

$ journalctl -p err -b

-p err garde err et au-dessus ; -b limite au boot courant. C'est le premier coup d'œil « quelque chose a-t-il cassé depuis qu'on a démarré ? ». Pour inclure le boot précédent (utile après un reboot surprise) : journalctl -p err -b -1.

Exercice 2 — Que s'est-il passé juste avant le reboot ?

L'edge a redémarré tout seul cette nuit. Tu veux lire les toutes dernières lignes de journal d'avant le redémarrage. Comment ?

Voir la solution

$ journalctl --list-boots        # repérer l'index du boot d'avant (-1)
$ journalctl -b -1 -e            # fin du journal du boot précédent
$ journalctl -b -1 -p warning    # ou seulement warnings+erreurs

Cela suppose que le journal est persistant (§6) : sinon, le journal du boot précédent a disparu au redémarrage et --list-boots ne montre que le boot courant. C'est exactement la situation qui justifie de persister le journal sur un edge.

Exercice 3 — Le disque se remplit de logs

df -h montre / à 95 %, et journalctl --disk-usage annonce 6 Go de journaux. Que fais-tu dans l'immédiat, puis pour que ça ne se reproduise pas ?

Voir la solution

Immédiat — récupérer de la place sans tout perdre :

$ sudo journalctl --vacuum-size=500M

Durable — borner dans /etc/systemd/journald.conf : SystemMaxUse=500M (+ éventuellement MaxRetentionSec=1month), puis sudo systemctl restart systemd-journald. Et si la cause est un conteneur bavard, borner aussi ses logs Docker (chapitre 6). On traite à la fois le symptôme (place) et la cause (volume de logs).

Chapitre 04Journaux avec journalctl

Objectifs du chapitre

1. Un journal unique pour tout le système

2. Filtrer par unité : -u

3. Filtrer par priorité : -p

4. Filtrer par temps : -b, --since

Par démarrage : -b

Par fenêtre : --since / --until

5. Suivre en direct : -f

6. Rendre le journal persistant

7. Rotation : ne pas remplir le disque

8. Corréler un incident dans le temps

Récapitulatif

Exercices

Exercice 1 — Les erreurs depuis le dernier boot

Exercice 2 — Que s'est-il passé juste avant le reboot ?

Exercice 3 — Le disque se remplit de logs

Chapitre 04
Journaux avec `journalctl`

2. Filtrer par unité : `-u`

3. Filtrer par priorité : `-p`

4. Filtrer par temps : `-b`, `--since`

Par démarrage : `-b`

Par fenêtre : `--since` / `--until`

5. Suivre en direct : `-f`