Maîtriser les journaux système avec journalctl sous Linux

journalctl est la commande pour consulter les logs système sur toute distribution utilisant systemd. Elle remplace la lecture manuelle des fichiers dans /var/log/ en offrant un journal structuré, filtrable par service, par priorité, par date et par boot. C’est l’outil de diagnostic principal de l’administrateur Linux.

Ce que vous allez apprendre

Consulter les logs système et les logs d’un service spécifique
Filtrer les logs par date, priorité et boot
Suivre les logs en temps réel avec -f
Configurer la rétention et la taille maximale du journal
Gérer les permissions d’accès aux logs
Utiliser les formats de sortie avancés

Dans quel contexte ?

journalctl intervient dans toutes les situations de diagnostic :

Un service refuse de démarrer — les logs expliquent l’erreur
Le système a redémarré de façon inattendue — consulter les boots précédents
Une application produit des erreurs intermittentes — filtrer par priorité
L’espace disque est consommé par les logs — vérifier et configurer la rétention
Un problème de sécurité nécessite d’analyser les connexions récentes

Le journal systemd

journald (systemd-journald) collecte les logs de trois sources :

Source	Contenu
Messages du noyau	Équivalent de `dmesg`
Syslog	Messages des services via la socket `/dev/log`
stdout/stderr	Sorties des services gérés par systemd

Le journal est stocké sous forme binaire dans /var/log/journal/ (persistant) ou /run/log/journal/ (volatile, perdu au reboot).

# Vérifier l'espace utilisé par le journal
journalctl --disk-usage

Archived and active journals take up 632.5M in the file system.

Persistance du journal

Par défaut sur la plupart des distributions, le journal est persistant si /var/log/journal/ existe :

# Vérifier que le répertoire existe
ls -ld /var/log/journal/

Si le répertoire n’existe pas, le journal est volatil (perdu au reboot). Pour activer la persistance :

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald

Consulter les logs

Logs du dernier boot

# Tous les logs depuis le dernier démarrage
journalctl -b

# Logs du boot précédent
journalctl -b -1

# Lister les boots disponibles
journalctl --list-boots

-2 abc123... Thu 2026-06-26 08:14:21 CEST — Thu 2026-06-26 22:30:05 CEST
-1 def456... Fri 2026-06-27 07:45:12 CEST — Fri 2026-06-27 23:15:33 CEST
 0 ghi789... Sat 2026-06-28 06:32:15 CEST — Sat 2026-06-28 12:50:14 CEST

Logs d’un service

# Logs de nginx
journalctl -u nginx

# Logs de nginx depuis le dernier boot
journalctl -u nginx -b

# Logs de plusieurs services
journalctl -u nginx -u postgresql

Suivre les logs en temps réel

# Équivalent de tail -f
journalctl -f

# Suivre un service spécifique
journalctl -fu nginx

Filtrer par date

# Depuis une date
journalctl --since "2026-06-28 08:00"

# Jusqu'à une date
journalctl --until "2026-06-28 12:00"

# Combiné
journalctl --since "1 hour ago"

# Les 30 dernières minutes
journalctl --since "30 min ago"

# Hier
journalctl --since yesterday --until today

Filtrer par priorité

Le journal utilise les niveaux de priorité syslog (0 = le plus critique, 7 = le plus verbeux) :

Niveau	Nom	Signification
0	`emerg`	Système inutilisable
1	`alert`	Action immédiate requise
2	`crit`	Erreur critique
3	`err`	Erreur
4	`warning`	Avertissement
5	`notice`	Normal mais significatif
6	`info`	Information
7	`debug`	Debug (très verbeux)

# Erreurs et au-dessus (0 à 3)
journalctl -p err

# Erreurs depuis le dernier boot
journalctl -p err -b

# Avertissements et au-dessus pour un service
journalctl -u nginx -p warning

Rechercher dans les logs

# Recherche textuelle (grep intégré)
journalctl -b --grep "error|fail"

# Recherche insensible à la casse
journalctl -b --grep "timeout" --case-sensitive=no

Logs du noyau

# Équivalent de dmesg avec horodatage
journalctl -k

# Messages noyau du boot actuel
journalctl -k -b

Formats de sortie

journalctl propose plusieurs formats avec l’option -o :

Format	Usage
`short`	Format par défaut (similaire à syslog)
`short-precise`	Avec microsecondes
`verbose`	Tous les champs structurés
`json`	JSON (pour parsing automatisé)
`json-pretty`	JSON indenté (lecture humaine)
`cat`	Uniquement le message (sans métadonnées)

# Format verbeux (tous les champs)
journalctl -u nginx -n 1 -o verbose

Sat 2026-06-28 06:32:15.123456 CEST [s=abc123;i=1;b=def456;m=789...]
    _TRANSPORT=syslog
    _UID=0
    _GID=0
    _SYSTEMD_UNIT=nginx.service
    MESSAGE=Starting A high performance web server...
    PRIORITY=6
    SYSLOG_FACILITY=3

# Format JSON pour un outil de centralisation
journalctl -u nginx -n 5 -o json

Configuration de journald

Le fichier de configuration principal est /etc/systemd/journald.conf :

sudo nano /etc/systemd/journald.conf

Options essentielles

[Journal]
# Persistance du journal (persistent, volatile, auto, none)
Storage=persistent

# Taille maximale du journal
SystemMaxUse=500M

# Taille maximale par fichier
SystemMaxFileSize=50M

# Durée maximale de rétention
MaxRetentionSec=3month

# Compression des anciens fichiers
Compress=yes

# Taux de limitation (messages par intervalle par service)
RateLimitIntervalSec=30s
RateLimitBurst=10000

Option	Effet
`Storage=persistent`	Le journal survit aux reboots
`SystemMaxUse`	Taille totale maximale du journal
`SystemMaxFileSize`	Taille maximale de chaque fichier journal
`MaxRetentionSec`	Durée maximale de conservation
`RateLimitBurst`	Nombre max de messages par intervalle (par service)

Après modification :

sudo systemctl restart systemd-journald

Nettoyage du journal

Réduire par taille

# Réduire le journal à 200 Mo
sudo journalctl --vacuum-size=200M

Réduire par ancienneté

# Supprimer les logs de plus de 2 semaines
sudo journalctl --vacuum-time=2weeks

Réduire par nombre de fichiers

# Garder uniquement les 5 derniers fichiers
sudo journalctl --vacuum-files=5

# Vérifier l'espace après nettoyage
journalctl --disk-usage

Permissions

Par défaut, seuls root et les membres du groupe systemd-journal peuvent lire le journal complet :

# Ajouter un utilisateur au groupe
sudo usermod -aG systemd-journal mon-utilisateur

Les utilisateurs non privilégiés ne voient que les logs de leurs propres services (timers/services utilisateur).

Journal et sécurité

Vérifier l’intégrité

journald peut sceller (seal) les fichiers pour détecter toute altération :

[Journal]
Seal=yes

Forward vers syslog

Pour utiliser journald en parallèle d’un serveur syslog traditionnel (rsyslog, syslog-ng) :

[Journal]
ForwardToSyslog=yes

Dépannage

Symptôme	Cause probable	Solution
Journal vide après reboot	Persistance non configurée	Créer `/var/log/journal/` et configurer `Storage=persistent`
`No entries` pour un service	Mauvais nom d’unité	Vérifier avec `systemctl list-units \| grep nom`
`Suppressed N messages`	Rate limiting actif	Augmenter `RateLimitBurst` ou corriger le service
Journal trop volumineux	Pas de limite configurée	Configurer `SystemMaxUse` et `MaxRetentionSec`
Utilisateur ne voit pas les logs	Pas dans le groupe	`sudo usermod -aG systemd-journal user`
Logs des boots précédents absents	Journal volatil	Activer `Storage=persistent`

# Diagnostic rapide
journalctl --disk-usage                    # Espace utilisé
journalctl --list-boots                     # Boots disponibles
journalctl -p err -b                        # Erreurs du boot actuel
systemctl status systemd-journald           # État du démon

Bonnes pratiques

Toujours activer la persistance — sans /var/log/journal/, les logs sont perdus au reboot
Configurer SystemMaxUse — éviter que le journal remplisse le disque (200-500 Mo est un bon compromis)
Configurer MaxRetentionSec — 1 à 3 mois selon les besoins de conformité
Commencer le diagnostic par journalctl -p err -b — les erreurs du boot actuel sont le point de départ
Utiliser -u service pour cibler un service — ne pas parcourir tout le journal
Planifier le nettoyage — journalctl --vacuum-size ou --vacuum-time régulièrement
Centraliser les logs en production — journald seul ne suffit pas pour un audit ou une corrélation multi-serveurs

À retenir

journalctl consulte le journal binaire de systemd — c’est l’outil de diagnostic principal sous Linux
Filtrer par service (-u), par priorité (-p), par date (--since) et par boot (-b) pour cibler les informations utiles
La persistance nécessite /var/log/journal/ et Storage=persistent dans journald.conf
Les priorités vont de 0 (emerg) à 7 (debug) — commencer par -p err en cas de problème
SystemMaxUse et MaxRetentionSec contrôlent la taille et la rétention du journal
journalctl --vacuum-size et --vacuum-time permettent de nettoyer manuellement
Le format JSON (-o json) facilite la centralisation vers Loki, Elasticsearch ou Graylog

Prochaines étapes

Gestion des services avec systemd Démarrer, diagnostiquer et durcir vos services

Rotation des logs avec logrotate Gérer la taille des fichiers de log texte

Planifier avec cron Automatiser le nettoyage des logs et les sauvegardes

Timers systemd L'alternative moderne à cron pour les tâches planifiées