Gestion des logs Linux : commandes journalctl et systemd | INTROSERV
EUR
european

EUR

usa

USD

French Fr
Ex. VAT Ex. VAT 0%

Gestion des logs Linux : utiliser les commandes journalctl pour les logs systemd

Niveau : Débutant
Durée estimée : ~20 minutes
Objectif : Apprendre à interroger, filtrer et gérer les journaux système et ceux des services, en utilisant les journaux Linux pour le dépannage afin de résoudre les problèmes et de maintenir la disponibilité du serveur.

Introduction

Une gestion des journaux sous Linux fiable est essentielle pour maintenir la disponibilité du serveur et effectuer le diagnostic d'un serveur Linux. Lors de l'administration de serveurs web, vous devez analyser rapidement les journaux système avec journalctl pour identifier la cause première d'un problème. Systemd (le système d'initialisation et gestionnaire de services de la plupart des distributions Linux modernes) collecte les journaux système (enregistrements généraux des opérations du système et des événements à l'échelle du système). Chaque journal (log) (un enregistrement des événements qui se produisent au sein d'un système d'exploitation ou d'une application) est collecté par Systemd-journald (un service système qui collecte et stocke les données de journalisation) et conservé dans le Journal (les données de journalisation au format binaire générées et gérées par systemd-journald). Pour consulter ces données, on utilise Journalctl (un utilitaire en ligne de commande permettant d'interroger et d'afficher les journaux de systemd). Ce tutoriel porte sur l'utilisation des commandes journalctl pour interroger, filtrer et gérer les journaux systemd avec journalctl. À la fin, vous naviguerez avec aisance en ligne de commande et utiliserez efficacement les journaux Linux pour le dépannage.

Prérequis

Avant de commencer, assurez-vous que les conditions suivantes sont remplies :

  • Système d'exploitation : Ubuntu 20.04/22.04/24.04 LTS, Debian 11/12/13 ou AlmaLinux/Rocky 8/9/10
  • Exigences matérielles et réseau : aucune (ce guide utilise des utilitaires de base en ligne de commande)
  • Accès : accès sudo ou root au serveur
  • Connaissances requises : utilisation de base de la ligne de commande Linux

Étape 1 : Gestion des journaux sous Linux : journaux volatils et persistants

Par défaut, certains systèmes configurent le journal pour utiliser des journaux volatils (journaux stockés uniquement en RAM et perdus au redémarrage). Pour une gestion des journaux sous Linux efficace, il faut des journaux persistants (journaux enregistrés sur disque et conservés d'un redémarrage à l'autre), afin de pouvoir analyser les plantages après un redémarrage.

Exécutez la commande suivante pour vérifier votre configuration de stockage :

sudo grep -i 'storage' /etc/systemd/journald.conf

Sortie attendue :

#Storage=auto

Vous devriez voir une sortie indiquant si le stockage est défini sur auto, persistent ou volatile. La ligne commentée #Storage=auto signifie que le comportement par défaut auto est appliqué.

Info

Sur RHEL/AlmaLinux/Rocky, le fichier /etc/systemd/journald.conf peut être absent par défaut. Dans ce cas, vous pouvez consulter /usr/lib/systemd/journald.conf ou configurer le service en créant /etc/systemd/journald.conf.d/persistent.conf.

Sur Ubuntu 24.04 et Debian 13, le répertoire /var/log/journal existe déjà et la journalisation persistante fonctionne sans configuration supplémentaire. Si le répertoire est absent (par exemple sur une installation neuve d'AlmaLinux) et que vous souhaitez forcer la journalisation persistante, créez le répertoire et redémarrez le système de journalisation de systemd (le service systemd-journald gère ce répertoire) :

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

Sur les systèmes AlmaLinux/RHEL, vous devez en outre transférer (flush) les journaux de l'emplacement volatil /run/log/journal vers le nouveau stockage persistant sur disque :

sudo journalctl --flush

Aucune sortie ne devrait s'afficher. Cela confirme que le service a redémarré correctement et qu'il écrira désormais des données persistantes sur le disque.

Étape 2 : Commandes journalctl de base pour les journaux systemd

Pour afficher toutes les entrées disponibles, utilisez la commande par défaut.

Exécutez la commande suivante :

sudo journalctl

Sortie attendue :

May 20 10:00:00 server systemd[1]: Started Logging Service. May 20 10:00:01 server kernel: Linux version 5.15.0-101-generic...

Vous devriez voir une liste paginée de tous les journaux systemd de votre serveur. Appuyez sur q pour quitter le paginateur.

Info

À partir de la version 255 de systemd (par exemple sur Ubuntu 24.04, Debian 13 et AlmaLinux 10), l'en-tête -- Logs begin at... n'est plus affiché par défaut.

Pour analyser efficacement les journaux avec journalctl, vous voudrez rarement tout lire depuis le début. Vous pouvez inverser l'ordre d'affichage pour voir d'abord les entrées les plus récentes avec l'option -r.

Exécutez la commande suivante :

sudo journalctl -r

Sortie attendue :

May 23 20:00:00 server sshd[1234]: Accepted publickey for user from 192.168.1.50... May 23 19:59:58 server systemd[1]: Session 4 created for user.

Vous devriez voir les entrées de journal les plus récentes en haut de l'écran. C'est une technique essentielle pour analyser rapidement les journaux avec journalctl après un incident.

Info

L'option -r est particulièrement utile lorsque votre serveur fonctionne depuis des mois, car elle permet d'ignorer instantanément des milliers d'anciens événements.

Étape 3 : Comment consulter les journaux d'un service

Il est fréquent de devoir diagnostiquer une unité (unit) précise (un objet que systemd sait gérer), par exemple une unité de service (service unit) (un type d'unité qui contrôle un service, comme nginx ou sshd). Utilisez l'option -u pour consulter les journaux d'un service donné, comme le serveur web nginx.

Exécutez la commande suivante (en supposant que le service soit installé, par exemple via sudo apt install nginx -y ou sudo dnf install nginx -y) :

sudo journalctl -u nginx

Sortie attendue :

May 23 18:00:00 server systemd[1]: Starting A high performance web server and a reverse proxy server... May 23 18:00:01 server systemd[1]: Started A high performance web server and a reverse proxy server.

Vous devriez voir uniquement les entrées de journal générées par le service nginx. Cela permet d'isoler les erreurs du trafic web des autres événements système en arrière-plan. Si le service n'est pas installé, vous verrez simplement -- No entries --.

Pour consulter les journaux du démon SSH, le nom de l'unité varie selon la distribution.

Pour Ubuntu/Debian, exécutez :

sudo journalctl -u ssh

Pour AlmaLinux/RHEL/Rocky, exécutez :

sudo journalctl -u sshd

Sortie attendue :

May 23 19:50:00 server sshd[1234]: Invalid user admin from 10.0.0.5 port 55432 May 23 19:55:00 server sshd[1235]: Accepted publickey for root from 10.0.0.2 port 44322

Vous devriez voir les tentatives d'authentification et les événements du démon SSH.

Étape 4 : Filtrage des journaux avec journalctl par période et par type

Face à de grandes quantités de données, vous avez besoin du filtrage des journaux (le processus consistant à restreindre la sortie des journaux selon des critères précis). Le filtrage des journaux avec journalctl par période est extrêmement utile lorsqu'une panne s'est produite à un moment connu.

Pour afficher les messages générés depuis le dernier démarrage, on consulte les journaux de démarrage (enregistrements des événements survenant pendant le processus de démarrage du système).

Exécutez la commande suivante :

sudo journalctl -b

Sortie attendue :

May 23 08:00:00 server kernel: Linux version 5.15.0-101-generic... May 23 08:00:00 server kernel: Command line: BOOT_IMAGE=/boot/vmlinuz...

La sortie devrait commencer par le tout premier événement de la séquence de démarrage actuelle.

Pour le filtrage des journaux avec journalctl selon le temps, utilisez --since et --until.

Exécutez la commande suivante :

sudo journalctl --since "1 hour ago"

Sortie attendue :

May 23 19:00:00 server cron[567]: (root) CMD (/usr/local/bin/backup.sh) May 23 19:05:00 server sudo[580]: user : TTY=pts/0 ; PWD=/home/user ; USER=root ; COMMAND=/bin/ls

Vous devriez voir tous les événements survenus au cours des 60 dernières minutes.

Pour afficher les journaux du noyau (messages générés par le noyau Linux, généralement des événements matériels et de pilotes), utilisez l'option -k.

Exécutez la commande suivante :

sudo journalctl -k

Sortie attendue :

May 23 08:00:00 server kernel: e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex May 23 08:00:01 server kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

Vous devriez voir des messages de bas niveau du noyau, utiles pour diagnostiquer des problèmes matériels ou de pilotes.

Étape 5 : Filtrage par priorité

Chaque entrée possède une priorité (le niveau de gravité attribué à un message de journal). Les niveaux vont de Debug (le niveau de priorité le plus bas, utilisé pour des informations de dépannage détaillées) à Error (un niveau de priorité indiquant une défaillance d'un service ou d'un processus). Un niveau fréquemment consulté est Warning (un niveau de priorité indiquant des problèmes potentiels qui ne sont pas encore des erreurs).

Pour le filtrage des journaux avec journalctl par priorité, utilisez l'option -p.

Exécutez la commande suivante pour n'afficher que les erreurs :

sudo journalctl -p err

Sortie attendue :

May 23 10:15:20 server systemd[1]: Failed to start Custom Application Service. May 23 14:30:00 server sshd[1122]: error: kex_exchange_identification: Connection closed by remote host

Vous devriez voir une liste condensée ne contenant que les messages de niveau erreur, le fonctionnement normal étant filtré.

Exécutez la commande suivante pour afficher les avertissements et les erreurs :

sudo journalctl -p warning

Sortie attendue :

May 23 10:15:15 server systemd-udevd[330]: vda: Process '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/vda' failed with exit code 1. May 23 10:15:20 server dhcpcd[400]: eth0: no IPv6 Routers available

Vous devriez voir à la fois les avertissements et les erreurs, ce qui offre une vision plus large des problèmes potentiels. Sur un système d'exploitation fraîchement installé, il est courant de voir des avertissements de routine émis par des services tels que multipathd, irqbalance, dhcpcd ou udev, plutôt que des défaillances critiques de services. La sortie exacte dépend fortement de la configuration et de l'environnement de votre système.

Étape 6 : Comment surveiller les journaux Linux en temps réel

Lorsque vous appliquez des modifications de configuration ou reproduisez un problème, il est préférable de surveiller les journaux Linux en temps réel. Utilisez l'option -f (follow).

Exécutez la commande suivante :

sudo journalctl -f

Sortie attendue :

May 23 20:05:00 server sudo[2001]: user : TTY=pts/1 ; PWD=/ ; USER=root ; COMMAND=/bin/bash May 23 20:05:00 server su[2002]: (to root) user on pts/1 May 23 20:05:00 server su[2002]: pam_unix(su:session): session opened for user root by user(uid=1000)

Vous devriez voir les dernières entrées de journal, puis le terminal reste actif et affiche les nouveaux événements au fur et à mesure. Appuyez sur Ctrl+C pour quitter.

Pour surveiller en temps réel les journaux du démon SSH, le nom de l'unité varie selon la distribution.

Pour Ubuntu/Debian, exécutez :

sudo journalctl -u ssh -f

Pour AlmaLinux/RHEL/Rocky, exécutez :

sudo journalctl -u sshd -f

Sortie attendue :

May 23 20:10:15 server sshd[2100]: Connection from 192.168.1.100 port 45678 May 23 20:10:17 server sshd[2100]: Accepted publickey for admin from 192.168.1.100 port 45678 May 23 20:10:17 server sshd[2100]: pam_unix(sshd:session): session opened for user admin by (uid=0)

Vous devriez voir en direct les tentatives d'authentification SSH au moment où elles se produisent.

Étape 7 : Espace disque et rotation des journaux

Le journal systemd peut devenir volumineux avec le temps. La pratique consistant à archiver et à supprimer les anciens journaux pour économiser de l'espace s'appelle la rotation des journaux. Vous pouvez vérifier l'espace actuellement utilisé par le journal systemd.

Exécutez la commande suivante :

sudo journalctl --disk-usage

Sortie attendue :

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

Vous devriez voir une sortie indiquant l'espace total utilisé par vos fichiers journaux.

Pour effectuer une rotation manuelle des journaux et libérer de l'espace disque, vous pouvez purger les données (vacuum) par durée ou par taille.

Exécutez la commande suivante pour ne conserver que les 500 derniers Mo de données :

sudo journalctl --vacuum-size=500M

Sortie attendue :

Vacuuming done, freed 0B of archived journals from /var/log/journal.

Vous devriez voir une sortie indiquant que les anciens fichiers ont été supprimés jusqu'à ce que la taille totale passe sous 500 Mo.

Warning

La purge (vacuum) du journal supprime définitivement les entrées les plus anciennes. Assurez-vous de ne pas en avoir besoin pour des raisons de conformité ou d'investigation avant d'exécuter cette commande.

Tip

Le service systemd-journald gère la rotation automatique selon les limites définies dans /etc/systemd/journald.conf. Vous n'avez généralement pas besoin d'exécuter un vacuum manuel, sauf si le disque se remplit soudainement.

Vérification

Pour vous assurer que votre configuration de journalisation fonctionne correctement et que le stockage persistant est actif :

  1. Vérifiez que l'emplacement de stockage des journaux a bien été créé :

    ls -ld /var/log/journal

    Vous devriez voir un répertoire appartenant à root. Selon votre distribution, le groupe peut être systemd-journal ou root (les deux sont normaux).

  2. Confirmez que journald est en cours d'exécution :

    sudo systemctl status systemd-journald

    Vous devriez voir que le service est dans l'état active (running).

Dépannage

Si vous rencontrez des problèmes lors de la gestion des journaux, vérifiez ces scénarios courants :

  • Journaux de service vides (-- No entries --) : Assurez-vous que le service est bien installé et en cours d'exécution. Vérifiez également que vous utilisez le bon nom d'unité pour votre distribution (par exemple ssh sur Debian/Ubuntu contre sshd sur RHEL/AlmaLinux).
  • /var/log/journal manquant : Sur certains systèmes (comme AlmaLinux), vous devez créer manuellement ce répertoire et redémarrer le service de journalisation pour activer les journaux persistants. Si vous omettez cette étape, les journaux resteront en mémoire volatile (/run/log/journal).
  • Permission refusée (Permission denied) : Si vous ne pouvez pas lire les journaux sans sudo, vérifiez que votre utilisateur appartient au groupe systemd-journal ou adm (sudo usermod -aG systemd-journal $USER).

Annulation des modifications

Si vous souhaitez désactiver la journalisation persistante et revenir aux journaux volatils (par exemple pour économiser de l'espace disque) :

  1. Supprimez le répertoire de stockage persistant :

    sudo rm -rf /var/log/journal

  2. Redémarrez le service de journalisation pour recréer le stockage volatil dans /run/log/journal :

    sudo systemctl restart systemd-journald

Conclusion

Voilà. Vous maîtrisez désormais les bases de la gestion des journaux sous Linux. Avec les bonnes commandes journalctl, vous pouvez parcourir efficacement les journaux systemd, appliquer des filtres et gérer l'espace disque. Que vous ayez besoin d'analyser les journaux avec journalctl après un plantage ou simplement de vérifier l'état d'un service, maîtriser journalctl est une étape déterminante pour maintenir une infrastructure saine.

Version du document : 1.0
Dernière mise à jour : mai 2026
Responsable : Équipe de documentation technique

VAT

  • Other

    Ex. VAT

    0%
  • austria

    Austria

    20%
  • Belgium

    Belgium

    21%
  • Bulgaria

    Bulgaria

    20%
  • Croatia

    Croatia

    25%
  • Cyprus

    Cyprus

    19%
  • Czech Republic

    Czech Republic

    21%
  • Denmark

    Denmark

    25%
  • Estonia

    Estonia

    22%
  • France

    France

    20%
  • Finland

    Finland

    24%
  • Germany

    Germany

    19%
  • Greece

    Greece

    24%
  • Hungary

    Hungary

    27%
  • Ireland

    Ireland

    23%
  • Italy

    Italy

    22%
  • Latvia

    Latvia

    21%
  • Lithuania

    Lithuania

    21%
  • Luxembourg

    Luxembourg

    17%
  • Malta

    Malta

    18%
  • Netherlands

    Netherlands

    21%
  • Poland

    Poland

    23%
  • Portugal

    Portugal

    23%
  • Romania

    Romania

    19%
  • Slovakia

    Slovakia

    20%
  • Slovenia

    Slovenia

    22%
  • Spain

    Spain

    21%
  • Sweden

    Sweden

    25%
  • USA

    USA

    0%
european
states
  • germany
  • Español
  • Italiano
  • Poland
  • Русский
  • Slovenski
  • Türkçe
  • ukraine
  • kingdom
  • French
  • Hrvatska
  • Other
  • Austria
  • Belgium
  • Bulgaria
  • Croatia
  • Cyprus
  • Czech Republic
  • Denmark
  • Estonia
  • Finland
  • France
  • Germany
  • Greece
  • Hungary
  • Ireland
  • Italy
  • Latvia
  • Lithuania
  • Luxembourg
  • Malta
  • Netherlands
  • Poland
  • Portugal
  • Romania
  • Slovakia
  • Slovenia
  • Spain
  • Sweden
  • USA