Quand quelque chose ne fonctionne plus sur un serveur Linux, votre premier reflexe est de consulter les logs. Sur toute distribution Linux moderne utilisant systemd, l’outil principal pour cette tache est journalctl. Il fournit une interface unique pour interroger les logs structures de chaque service, du noyau et du processus de demarrage — le tout indexe et filtrable par temps, priorite, unite de service et des dizaines d’autres champs.

Ce guide couvre tout ce dont vous avez besoin pour utiliser journalctl efficacement dans l’administration quotidienne et la resolution d’incidents, des requetes basiques au filtrage avance, en passant par la configuration du stockage persistant et l’integration avec des outils externes d’analyse de logs.

Prerequis

Avant de commencer, assurez-vous d’avoir :

  • Un systeme Linux avec systemd (Ubuntu 20.04+, Debian 11+, RHEL/CentOS 8+, Fedora, Arch ou similaire)
  • Acces au terminal avec des privileges sudo
  • Une familiarite basique avec les services systemd (systemctl start, systemctl status)

Comprendre le Journal systemd

Le journal systemd est un systeme de journalisation centralise gere par le service systemd-journald. Contrairement au syslog traditionnel, qui ecrit du texte brut dans des fichiers dans /var/log/, le journal stocke les entrees dans un format binaire structure qui inclut des metadonnees avec chaque ligne de log :

  • Horodatage avec precision a la microseconde
  • ID de demarrage — quelle session de demarrage a produit l’entree
  • Nom d’unite — quel service systemd l’a generee
  • PID et UID — identificateurs de processus et d’utilisateur
  • Niveau de priorite — de urgence (0) a debogage (7)
  • ID de machine — utile dans les configurations multi-serveurs

Cette structure est ce qui rend journalctl si puissant : vous pouvez filtrer sur n’importe quelle combinaison de ces champs sans ecrire des expressions grep complexes.

Verifiez que journald est en cours d’execution sur votre systeme :

systemctl status systemd-journald

Consultez combien d’espace disque le journal utilise actuellement :

journalctl --disk-usage

Utilisation Basique de journalctl

Voir Tous les Logs

journalctl

Cela ouvre le journal complet dans un paginateur (generalement less). Appuyez sur q pour quitter, / pour rechercher et G pour aller a la fin (entrees les plus recentes).

Voir les Entrees les Plus Recentes

# Afficher les 50 dernieres lignes
journalctl -n 50

# Afficher les 100 dernieres lignes sans paginateur (sortie directe)
journalctl -n 100 --no-pager

Suivre les Logs en Temps Reel

journalctl -f

Cela fonctionne comme tail -f mais pour l’ensemble du journal. Appuyez sur Ctrl+C pour arreter. Vous pouvez combiner -f avec n’importe quel filtre :

# Suivre uniquement les logs de nginx
journalctl -f -u nginx.service

Ordre Inverse (Plus Recents en Premier)

journalctl -r

Filtrage par Temps

Le filtrage temporel est l’une des fonctionnalites les plus utiles de journalctl pour l’investigation d’incidents.

Plages Horaires Absolues

# Logs depuis une date et heure specifiques
journalctl --since "2025-12-26 08:00:00"

# Logs entre deux horodatages
journalctl --since "2025-12-25 18:00" --until "2025-12-26 06:00"

# Logs d'un jour specifique (journee entiere)
journalctl --since "2025-12-25" --until "2025-12-26"

Plages Horaires Relatives

# Logs de la derniere heure
journalctl --since "1 hour ago"

# Logs des 30 dernieres minutes
journalctl --since "30 min ago"

# Depuis hier
journalctl --since yesterday

# Aujourd'hui uniquement
journalctl --since today

Demarrage Actuel vs. Demarrages Precedents

# Logs du demarrage actuel uniquement
journalctl -b

# Logs du demarrage precedent
journalctl -b -1

# Logs d'il y a deux demarrages
journalctl -b -2

# Lister tous les demarrages disponibles
journalctl --list-boots

La sortie de --list-boots affiche les IDs de demarrage et les horodatages, ce qui est inestimable pour investiguer ce qui s’est passe avant un redemarrage inattendu.

Filtrage par Unite de Service

C’est ici que journalctl fait gagner le plus de temps par rapport a l’analyse de logs traditionnelle.

Service Individuel

# Tous les logs de nginx
journalctl -u nginx.service

# Tous les logs du daemon SSH
journalctl -u sshd.service

# Tous les logs de PostgreSQL
journalctl -u postgresql.service

Plusieurs Services

# Logs de nginx et PHP-FPM
journalctl -u nginx.service -u php8.1-fpm.service

Combiner Filtres de Service et de Temps

# Erreurs nginx des 2 dernieres heures
journalctl -u nginx.service --since "2 hours ago" -p err

Services Utilisateur

# Logs d'un service au niveau utilisateur
journalctl --user -u myapp.service

Filtrage par Priorite

Les niveaux de priorite syslog vont de 0 (urgence) a 7 (debogage) :

PrioriteMot-cleDescription
0emergSysteme inutilisable
1alertAction immediate requise
2critConditions critiques
3errConditions d’erreur
4warningConditions d’avertissement
5noticeNormal mais significatif
6infoInformatif
7debugMessages de debogage

Filtrer par Priorite Maximale

# Afficher les erreurs et niveaux superieurs (0-3)
journalctl -p err

# Afficher les avertissements et niveaux superieurs (0-4)
journalctl -p warning

# Afficher les critiques et niveaux superieurs (0-2)
journalctl -p crit

Plage de Priorite

# Afficher uniquement les avertissements et erreurs (exclure critiques/urgence)
journalctl -p warning..err

Combiner avec d’Autres Filtres

# Erreurs nginx des dernieres 24 heures
journalctl -u nginx.service -p err --since "24 hours ago"

Filtrage par Autres Champs

journalctl peut filtrer sur n’importe quel champ stocke dans le journal. Listez les champs disponibles :

journalctl --fields

Filtres de Champs Courants

# Logs d'un PID specifique
journalctl _PID=1234

# Logs d'un utilisateur specifique
journalctl _UID=1000

# Logs du noyau
journalctl -k
# ou de maniere equivalente :
journalctl _TRANSPORT=kernel

# Logs d'un binaire specifique
journalctl /usr/sbin/sshd

# Logs d'un hostname specifique (dans les configurations multi-serveurs)
journalctl _HOSTNAME=webserver01

Combiner les Filtres de Champ

Lorsque vous specifiez plusieurs champs differents, ils sont combines avec une logique AND :

# Logs de l'UID 1000 ET priorite erreur
journalctl _UID=1000 -p err

Lorsque vous specifiez le meme champ plusieurs fois, ils sont combines avec une logique OR :

# Logs du PID 1234 OU PID 5678
journalctl _PID=1234 _PID=5678

Formats de Sortie

journalctl supporte plusieurs formats de sortie pour differents cas d’utilisation :

# Format court par defaut (similaire a syslog)
journalctl -o short

# Format court avec horodatages ISO
journalctl -o short-iso

# Sortie structuree complete
journalctl -o verbose

# Format JSON (un objet par ligne)
journalctl -o json

# JSON formate pour la lecture
journalctl -o json-pretty

# Message uniquement (sans metadonnees)
journalctl -o cat

# Format d'export binaire (pour journalctl --merge)
journalctl -o export

Sortie JSON pour l’Analyse de Logs

Le format JSON est particulierement utile pour envoyer vers des outils d’analyse :

# Extraire toutes les erreurs nginx en JSON
journalctl -u nginx.service -p err -o json --no-pager | jq '.'

# Obtenir des champs specifiques
journalctl -u sshd.service -o json --no-pager | jq '{timestamp: .__REALTIME_TIMESTAMP, message: .MESSAGE, pid: ._PID}'

Configuration du Stockage Persistant

Par defaut, certaines distributions stockent les logs du journal uniquement en memoire (/run/log/journal/), ce qui signifie qu’ils sont perdus au redemarrage.

Activer le Stockage Persistant

# Creer le repertoire de stockage persistant
sudo mkdir -p /var/log/journal

# Definir les permissions correctes
sudo systemd-tmpfiles --create --prefix /var/log/journal

# Redemarrer journald
sudo systemctl restart systemd-journald

Configurer les Limites de Retention

Editez /etc/systemd/journald.conf :

[Journal]
# Espace disque maximum pour les fichiers du journal
SystemMaxUse=500M

# Taille maximale des fichiers individuels du journal
SystemMaxFileSize=50M

# Duree maximale de conservation des entrees
MaxRetentionSec=1month

# Espace disque maximum pour le journal en memoire (volatil)
RuntimeMaxUse=100M

Apres modification, redemarrez le service :

sudo systemctl restart systemd-journald

Nettoyage Manuel

# Supprimer les entrees anterieures a 2 semaines
sudo journalctl --vacuum-time=2weeks

# Reduire le journal a un maximum de 500 Mo
sudo journalctl --vacuum-size=500M

# Conserver uniquement les 5 fichiers de journal les plus recents
sudo journalctl --vacuum-files=5

Verifier la Configuration

# Verifier l'utilisation disque actuelle
journalctl --disk-usage

# Afficher la configuration du journal
systemd-analyze cat-config systemd/journald.conf

Messages du Noyau

Pour le diagnostic au niveau du noyau, journalctl remplace la commande dmesg avec un meilleur filtrage :

# Tous les messages du noyau
journalctl -k

# Messages du noyau du demarrage actuel
journalctl -k -b

# Uniquement les erreurs du noyau
journalctl -k -p err

# Messages du noyau d'un demarrage precedent
journalctl -k -b -1

C’est essentiel pour diagnostiquer les problemes materiels, les pilotes, les erreurs du systeme de fichiers et les OOM (manque de memoire).

Exemples Pratiques de Diagnostic

Investiguer un Crash de Service

# Verifier quand le service a echoue pour la derniere fois
systemctl status myapp.service

# Voir les 200 dernieres lignes avant le crash
journalctl -u myapp.service -n 200 --no-pager

# Chercher des OOM kills autour du meme moment
journalctl -k --since "1 hour ago" | grep -i "oom\|killed process"

Diagnostiquer les Echecs de Connexion SSH

# Tous les messages d'authentification SSH
journalctl -u sshd.service | grep -i "failed\|invalid\|accepted"

# Tentatives SSH echouees des dernieres 24 heures
journalctl -u sshd.service --since "24 hours ago" -p warning

Surveiller les Problemes de Disque et Systeme de Fichiers

# Erreurs du systeme de fichiers depuis le noyau
journalctl -k | grep -i "ext4\|xfs\|btrfs\|i/o error\|read-only"

# Messages lies aux disques
journalctl -k | grep -i "sd[a-z]\|nvme\|ata"

Verifier les Problemes de Demarrage

# Log complet du dernier demarrage en echec
journalctl -b -1 -p err

# Lister tous les demarrages pour trouver le problematique
journalctl --list-boots

# Afficher uniquement les services ayant echoue au demarrage
journalctl -b -p err | grep "Failed to start"

Integration avec des Outils Externes

Transferer vers rsyslog

Si vous avez besoin de fichiers de log traditionnels en plus du journal, configurez rsyslog pour lire depuis le journal. Dans /etc/rsyslog.conf :

module(load="imjournal")

Exporter pour Elasticsearch/Loki

# Exporter en JSON pour ingestion
journalctl -o json --since "1 hour ago" --no-pager > /tmp/journal-export.json

# Envoyer vers un endpoint distant
journalctl -f -o json | curl -X POST -H "Content-Type: application/json" -d @- http://logserver:9200/journal/_bulk

Utiliser avec systemd-journal-remote

Pour la journalisation centralisee sur plusieurs serveurs, systemd fournit systemd-journal-remote :

# Installer sur le serveur central
sudo apt install systemd-journal-remote

# Activer le recepteur
sudo systemctl enable --now systemd-journal-remote.socket

Resolution de Problemes

Fichiers du Journal Corrompus

# Verifier l'integrite du journal
journalctl --verify

# Si corrompus, effectuer une rotation et repartir a zero
sudo journalctl --rotate
sudo journalctl --vacuum-time=1s

Pas de Logs d’un Service Specifique

  1. Verifiez que le service utilise la sortie standard :
systemctl show myapp.service | grep -i "standard\|log"
  1. Assurez-vous que le fichier d’unite redirige la sortie vers le journal :
[Service]
StandardOutput=journal
StandardError=journal

journalctl est Lent avec des Journals Volumineux

# Utilisez --since pour limiter la plage de recherche
journalctl --since "1 hour ago" -u myapp.service

# Reduisez la taille du journal
sudo journalctl --vacuum-size=200M

Resume

journalctl est l’outil standard pour interroger les logs sur les systemes Linux bases sur systemd. Points cles :

  • Utilisez -u pour filtrer par service, -p pour filtrer par priorite, et --since/--until pour les plages temporelles
  • Combinez les filtres pour des recherches ciblees : journalctl -u nginx -p err --since "1 hour ago"
  • Utilisez -b pour limiter les requetes au demarrage actuel ou aux sessions de demarrage precedentes
  • Activez le stockage persistant avec mkdir -p /var/log/journal si votre distribution utilise le stockage volatil par defaut
  • Configurez les limites de retention dans /etc/systemd/journald.conf pour eviter l’epuisement du disque
  • Utilisez -o json pour l’integration avec des pipelines d’analyse de logs comme Elasticsearch ou Loki
  • Utilisez journalctl -f au lieu de tail -f pour la surveillance en temps reel avec filtrage

Pour des sujets connexes, consultez nos guides sur Logrotate : Gerer les Fichiers de Log sous Linux et Configuration d’Elasticsearch pour l’Analyse de Logs.