Visualiser et manipuler les journaux Systemd avec Journalctl

La journalisation système et de processus ne sont que deux des avantages les plus cruciaux de systemd. Lorsque les journaux sont dispersés dans tout le système, couvrent plusieurs applications et sont gérés par différents processus et démons, ils peuvent être difficiles à interpréter. Systemd fournit une solution centralisée pour gérer tous les journaux de processus du noyau et de l'espace utilisateur dans un support de compilation appelé journal. Vous pouvez en savoir plus sur systemd dans notre tutoriel sur la façon de gérer les services et les unités systemd avec systemctl. Tous les messages générés par les services, initrd, les noyaux, etc. dans un journal sont gérés par le démon journal. Le but de ce guide est d'illustrer comment accéder aux données du journal et les manipuler à l'aide de journalctl.

Principe de base

Quelle que soit l'origine d'un message, l'un des objectifs principaux de systemd est de permettre la centralisation de leur gestion. Comme une grande partie des processus de démarrage et de la gestion des services est prise en charge par le processus systemd, la manière dont les journaux sont compilés et consultés devrait être standardisée. En collectant les données de toutes les sources disponibles dans un outil unique et global, journald les stocke dans un format binaire. Cela permet aux données d'être facilement disponibles pour une manipulation dynamique et simple.

Cette approche présente plusieurs avantages clés. En disposant d'un emplacement central pour collecter toutes les données, les administrateurs peuvent filtrer et afficher uniquement les données dont ils ont besoin. Par exemple, on peut afficher les données de démarrage d'il y a trois démarrages système. Cela peut également signifier la journalisation séquentielle des entrées de services connexes et un suivi plus efficace d'un problème de communication entre eux.

Grâce au stockage binaire, les données peuvent être affichées dans une variété de formats de sortie en fonction des besoins de l'utilisateur à ce moment-là. Par exemple, un journal quotidien peut être visualisé dans un format syslog standard. Mais si vous devez analyser les interruptions de service sous forme de graphique, l'entrée peut être générée sous la forme d'un objet JSON, ce qui le rend exploitable avec un service de création de graphiques. Lorsque vous devez changer de format en fonction des exigences de la situation, aucune conversion n'est nécessaire car les données sont binaires et ne sont pas écrites sur le disque en texte brut.

Selon les besoins, vous pouvez implémenter le journal systemd avec un syslog existant ou il peut en remplacer la fonctionnalité. Systemd peut même compléter les mécanismes de journalisation existants. Par exemple, plusieurs services sur un seul système peuvent voir leurs données compilées entrelacées sur un seul système avec le journal systemd.

Configuration de l'heure du système

Systemd affichera, par défaut, les résultats à l'heure locale, un avantage de la journalisation binaire dans la façon dont les enregistrements de journal peuvent être visualisés. Alternativement, ils peuvent être visualisés en UTC. Ainsi, il est important de s'assurer que le fuseau horaire est correctement configuré avant de commencer la journalisation. Pour ce faire, systemd est équipé d'un outil appelé timedatectl. Nous commençons par voir quels fuseaux horaires sont disponibles en affichant une liste avec les options list-timezones :

Après avoir trouvé le fuseau horaire correspondant à l'emplacement de votre serveur, le fuseau horaire peut être défini à l'aide de l'option set-timezone :

Pour tester et vérifier que le fuseau horaire s'affiche désormais correctement, vous pouvez utiliser la commande timedatectl seule ou en y ajoutant 'status' :

La première ligne indique l'heure locale. Cette ligne doit contenir l'heure correcte pour votre région.

Visualisation générale des journaux

La commande journalctl vous permettra de visualiser les journaux que le démon journald a collectés. Lorsque vous utilisez journalctl, chaque entrée de journal du système s'affiche à l'écran, les entrées les plus anciennes étant répertoriées vers le haut. La liste complète des données sera toutefois longue de plusieurs dizaines de milliers de lignes.

Ceux qui ont utilisé la journalisation syslog standard trouveront le format familier, mais c’est important de garder à l'esprit que cette compilation de données provient de nombreuses sources, contrairement à la méthode syslog. Les journaux incluront le processus de démarrage initial, l'initrd et le noyau, ainsi que les erreurs standard des applications.

Maintenant que l'heure locale est définie, toutes les entrées commenceront par des horodatages exprimés en heure locale, et cela est disponible pour chaque journal actuellement stocké sur le système, toute la logique étant affichée en utilisant ces nouvelles informations. Vous n'êtes cependant pas limité à l'heure locale. En utilisant le drapeau –utc, vous pouvez également afficher les horodatages en UTC :

Filtrage du journal par heure

Disposer d'autant de données est fantastique, mais les passer au peigne fin et être capable de les assimiler, sans parler de les traiter mentalement, peut être une tâche ardue. C'est dans cette optique que nous arrivons à la partie la plus importante de la fonction journalctl : le filtrage.

Affichage des journaux du démarrage actuel

Si vous recherchez les données du journal depuis le dernier redémarrage, vous pouvez utiliser la fonction journalctl avec un drapeau -b. Cela affichera toutes les informations de journal pertinentes du redémarrage le plus récent de votre système. Cette commande vous permettra de trouver et de gérer les informations les plus pertinentes pour l'environnement de travail actuel :

Si l'observateur choisit de ne pas évaluer chaque entrée individuellement, journalctl affichera plus d'une journée de démarrages qui s'afficheront dans journalctl avec des séparateurs pratiques « Reboot ». Cela permet de séparer logiquement les informations des différentes sessions de démarrage pour examen :

Informations sur les démarrages passés

Bien que l'affichage des informations du démarrage actuel ait tendance à être le plus utile, il existe des situations où les informations sur les démarrages passés s'avèrent utiles. Journal enregistre les informations de plusieurs démarrages antérieurs, de sorte que journalctl peut facilement afficher les informations pour n'importe quelle période.

Certaines distributions désactivent la sauvegarde des informations de démarrage précédentes, tandis que d'autres l'activent par défaut. L'activation des informations de démarrage persistantes peut être réalisée en créant un répertoire pour le stockage du journal en saisissant ce qui suit :

Alternativement, vous pouvez modifier le fichier de configuration du journal de la manière suivante :

Définir l'option Storage= sur « persistent » sous la section [Journal] activera la journalisation persistante :

Une fois cela activé, journalctl met à disposition certaines commandes qui vous aident à désigner ces démarrages comme unités de division. Pour afficher les démarrages qui ont été enregistrés dans journald, vous pouvez utiliser l'option –list-boots via journalctl :

Comme illustré, chaque démarrage sera répertorié sur sa propre ligne, la première colonne reflétant les démarrages antérieurs dans l'ordre du plus ancien au plus récent. Si une référence plus absolue est nécessaire, la deuxième colonne contient l'identifiant du démarrage. Après cela, deux spécifications de temps sont répertoriées. Les informations de la première ou de la deuxième colonne peuvent être utilisées pour afficher les informations du journal d'un démarrage spécifique. For exemple, vous pouvez utiliser le drapeau -b avec le pointeur de démarrage relatif -1 pour afficher les informations du deuxième redémarrage le plus récent :

De même, l'identifiant de démarrage de la deuxième colonne peut également être utilisé de cette façon :

Fenêtres de temps

Afficher les démarrages par ID est une option, mais il est souvent plus utile de pouvoir référencer les démarrages antérieurs par une fenêtre de temps dans le passé qui ne s'aligne pas nécessairement avec des démarrages spécifiques. Par exemple, cela est pertinent dans une situation où l'on travaille avec des serveurs à long terme qui ne sont pas redémarrés fréquemment. Le filtrage des limites de temps peut être effectué avec des limites de temps arbitraires. Cela affichera uniquement les informations sur les redémarrages qui s'inscrivent dans une fenêtre de temps particulière. Les paramètres de cette fenêtre sont désignés par les options –since et –until. Plusieurs formats sont disponibles pour les options de temps. Le format de valeur de temps absolu est le suivant :

Ainsi, si vous souhaitez voir tous les démarrages depuis le 10 janvier 2015 à 17h15, tapez la commande suivante :

Si l'un des composants est omis, des valeurs par défaut intégrées sont utilisées. De plus, si une date est omise, la date actuelle est utilisée par défaut. Si le composant temporel est absent, minuit est la valeur par défaut (00:00:00). Si vous omettez les secondes du composant temporel, elles prendront par défaut la valeur initiale de cette minute (00) :

Le journal peut comprendre des raccourcis temporels comme « today », « tomorrow », « yesterday » et « now ». Des mots comme « ago », en conjonction avec les qualificatifs préfixés « - » et « + », peuvent être utilisés pour construire une commande de type phrase :

Si vous avez été informé d'une interruption de service qui a commencé à 9h00 et que vous souhaitez vérifier les journaux jusqu'à il y a une heure, vous pouvez le faire avec la commande suivante :

Comme on peut le constater, définir une fenêtre de temps flexible pour afficher les entrées souhaitées est très simple.

Filtrer par intérêt de message

Outre le filtrage du journal par contraintes de temps, les données peuvent également être filtrées en fonction du composant de service d'intérêt. Systemd fournit plusieurs méthodes pour ce faire.

Par unité

Le paramètre de filtrage le plus utile est sans doute celui de l'unité d'intérêt. Pour filtrer par unité, l'option -u peut être exploitée. Par exemple, si vous souhaitez voir tous les journaux relatifs à l'unité Nginx, tapez la commande suivante :

En réalité, vous voudriez associer cela à un filtre temporel afin d'afficher les lignes intéressantes. Si vous souhaitez vérifier le service ci-dessus et ses performances d'aujourd'hui, vous pouvez procéder comme suit :

Ceci est particulièrement utile lorsque l'on utilise la capacité du journal à compiler des enregistrements provenant de plusieurs unités, en particulier celles qui collaborent. Si le processus Nginx est connecté à une unité PHP-FPN pour le traitement de contenu dynamique, les entrées peuvent être fusionnées par ordre chronologique en spécifiant les deux unités :

Cela peut grandement aider à observer l'interaction des programmes et faciliter le débogage des systèmes plutôt que des processus individuels.

Par ID de groupe, processus ou utilisateur

De nombreux services lancent une multitude de sous-processus (processus enfants) pour effectuer un travail spécifique. Si l'ID d'un processus particulier est disponible, il peut également être filtré en spécifiant le champ _PID. Si le PID intéressant est 8088, vous pouvez procéder comme suit :

Vous pouvez également souhaiter voir les entrées enregistrées pour un groupe particulier ou un utilisateur particulier. Cela peut être accompli en utilisant les filtres _GID et _UID. Si un serveur web s'exécute sous l'utilisateur www-data, la commande suivante permet de trouver l'ID nécessaire :

En utilisant cet ID, vous pouvez ensuite afficher les résultats du journal correspondants :

Systemd met de nombreux champs à disposition pour le filtrage. Certains champs sont appliqués par journald sur la base d'informations collectées sur le système au moment de la journalisation, tandis que d'autres sont transmis par le processus en cours d'enregistrement.

Un pré-qualificateur de _PID indique que l'information a été collectée sur le système au moment de la journalisation. Le journal enregistre et indexe automatiquement le PID pendant le processus de journalisation afin de rendre le filtrage possible ultérieurement. Pour connaître les champs de journal disponibles, vous pouvez taper :

Nous aborderons certains d'entre eux plus tard dans ce guide, mais pour l'instant, nous allons évoquer d'autres options utiles relatives à ces champs. Si vous souhaitez voir toutes les valeurs disponibles pour un champ de journal particulier, vous pouvez utiliser l'option -F. Si vous souhaitez voir ce que le journal systemd contient pour les identifiants de groupe (GID), vous pouvez faire ce qui suit :

Cela peut aider à construire des filtres en fournissant une liste complète des valeurs stockées dans le champ d'identifiant de groupe (GID) du journal.

Par chemin de composant

Le filtrage peut également être effectué en fournissant un chemin d'accès. Si le chemin mène à un exécutable, les entrées de journalctl seront affichées si elles concernent cet exécutable. Si l'exécutable concerné est « bash », vous pouvez taper :

Bien que ce ne soit pas toujours possible, si l'unité de l'exécutable est disponible, elle peut générer une méthode de filtrage plus claire et plus informative.

Afficher les messages du noyau

Les messages du noyau, généralement trouvés dans la sortie de dmesg, peuvent également être récupérés à partir du journal. Afin de n'afficher que ces messages, nous utilisons les options -k ou -dmesg dans notre commande :

Les messages du démarrage actuel s'affichent par défaut, mais les démarrages précédents peuvent être spécifiés en utilisant l'option de sélection mentionnée précédemment. Si vous recherchez les messages d'il y a cinq démarrages, taper ceci vous donnera les résultats nécessaires :

Par priorité

Les administrateurs système préfèrent souvent filtrer par priorité. Les journaux de faible priorité, bien qu'utiles à consulter, peuvent être déroutants et contenir de nombreuses distractions, ce qui les rend moins digestes lors de l'analyse. L'utilisation de l'option -p dans journalctl permet d'afficher uniquement les messages d'une priorité spécifiée, en filtrant toutes les autres priorités. Si vous souhaitez afficher les entrées de niveau d'erreur ou supérieur, saisissez ce qui suit :

Cette commande renverra tous les messages désignés comme erreurs, alertes, urgences ou critiques, le journal utilisant les niveaux de messagerie syslog standard. Les niveaux de priorité sont définis selon une valeur numérique, classée de la plus élevée à la plus basse :

• 0 : emerg
• 1 : alert
• 2 : crit
• 3 : err
• 4 : warning
• 5 : notice
• 6 : info
• 7 : debug

N'importe laquelle des options ci-dessus est utilisable de manière interchangeable avec l'option -p. Sélectionner l'une des priorités comme décrit ci-dessus filtrera toutes les priorités de ce niveau et des niveaux supérieurs.

Modifier l'affichage dans le journal

En plus d'utiliser le filtrage pour la sélection des entrées, nous disposons d'autres méthodes pour modifier la sortie, en adaptant l'affichage de journalctl à nos besoins.

Tronquer/Développer la sortie

Nous pouvons ajuster l'affichage de notre sortie en choisissant de réduire ou de développer les données dans journalctl. Par défaut, journalctl affiche l'entrée complète, les entrées les plus longues se prolongeant vers la droite de l'écran. Vous pouvez visualiser les entrées dans leur intégralité en faisant défiler l'écran à l'aide de la touche fléchée droite. Un utilisateur peut préférer tronquer la sortie, avec des points de suspension indiqués sur les lignes qui dépasseraient de l'écran. Pour cela, une option –no-full peut être utilisée :

Alternativement, vous pouvez également autoriser l'affichage de l'intégralité des données, indépendamment de leur longueur ou de la présence de caractères non imprimables, en utilisant l'option -a :

Sortie vers la sortie standard

Journalctl affiche la sortie dans un pagineur par défaut, mais si vous souhaitez manipuler les données avec des outils d'édition de texte, vous aurez probablement besoin que la sortie soit générée vers une option de sortie standard. Vous pouvez y parvenir avec l'option –no-pager :

Selon les besoins de l'utilisateur, cela peut être redirigé vers un fichier sur le disque ou un utilitaire de traitement.

Formats de sortie

Les données sont toujours plus faciles à analyser lorsqu'elles sont présentées dans un format plus consommable. Le journal offre plusieurs options d'affichage en utilisant le qualificateur -o suivi d'un format spécifiquement désigné.

Si vous souhaitez exporter les entrées du journal au format JSON, vous pouvez le faire de la manière suivante :

Cette stratégie est particulièrement utile pour les utilitaires d'analyse. Le format json-pretty peut être préférable pour afficher les structures de données avant de les transmettre au consommateur JSON :

Il existe plusieurs formats que vous pouvez utiliser pour l'affichage :

• cat : Affiche uniquement le champ de message lui-même.
• export : Un format binaire adapté au transfert ou à la sauvegarde.
• json : JSON standard avec une entrée par ligne.
• json-pretty : JSON formaté pour une meilleure lisibilité par l'homme
• json-sse : Sortie formatée en JSON enveloppée pour la rendre compatible avec les événements envoyés par le serveur (server-sent events)
• short : La sortie par défaut de style syslog
• short-iso : Le format par défaut augmenté pour afficher les horodatages de l'horloge système au format ISO 8601.
• short-monotonic : Le format par défaut avec des horodatages monotoniques.
• short-precise : Le format par défaut avec une précision à la microseconde
• verbose : Affiche tous les champs de journal disponibles pour l'entrée, y compris ceux habituellement masqués en interne.

Les options ci-dessus permettent d'afficher le journal dans votre format préféré.

Surveillance active des processus

Le journal permet d'accéder aux fonctionnalités de surveillance de l'activité active ou récente sans avoir à faire appel à un autre outil. Vous pouvez le faire avec la commande journalctl dotée d'une fonction « tail ».

• Affichage des journaux récents

L'utilisation de l'option -n (qui fonctionne exactement comme la commande tail -n) permettra d'afficher un certain nombre d'enregistrements :

Le nombre d'entrées que vous souhaitez afficher peut être spécifié avec un nombre particulier après le qualificateur -n :

• Suivi des journaux

Vous pouvez également suivre activement les journaux au fur et à mesure qu'ils sont écrits sur le système avec le drapeau -f. Cela fonctionne également de la même manière que la commande tail -f :

Maintenance du journal

Les journaux prennent de la place. Il est intéressant d'explorer cela, potentiellement pour supprimer certains des journaux les plus anciens afin de libérer de l'espace.

Recherche de l'utilisation actuelle du disque

Le drapeau –disk-usage peut aider à identifier l'espace que la journalisation occupe actuellement sur le disque :

Suppression des anciens journaux

Avec systemd version 218 (et les versions ultérieures), vous pouvez réduire le journal de deux manières différentes. L'une est l'option –vacuum-size. Cela permet de réduire le journal en indiquant sa taille. En d'autres termes, les entrées les plus anciennes seront purgées du journal jusqu'à ce que l'espace occupé atteigne le paramètre demandé :

L'option –vacuum-time permet de réduire l'occupation de l'espace du journal en indiquant une date limite, au-delà de laquelle toutes les entrées seront supprimées, tandis que celles créées après l'heure spécifiée seront conservées. Si vous souhaitez conserver uniquement les entrées de la dernière année civile, vous pouvez utiliser :

Limiter l'expansion du journal

Vous pouvez également limiter l'espace que le journal occupera. Pour ce faire, modifiez le fichier /etc/systemd.journald.conf. La croissance du journal peut être limitée en utilisant l'une des méthodes suivantes :

• SystemMaxUse= : Indique l'espace disque maximal que le journal est autorisé à utiliser dans le stockage persistant.
• SystemKeepFree= : Indique l'espace qui doit être laissé libre lorsque les entités du journal sont ajoutées dans le stockage persistant.
• SystemMaxFileSize= : Spécifie la taille maximale que les fichiers de journal sont autorisés à atteindre avant la rotation dans le stockage persistant.
• RuntimeMaxUse= : Spécifie l'espace disque autorisé à être utilisé dans le stockage volatil (au sein du système de fichiers /run).
• RuntimeKeepFree= : Lors de l'écriture de données sur le stockage volatil, cette fonction indique la quantité d'espace qui doit être dédiée à d'autres utilisations (au sein du système de fichiers /run).
• RuntimeMaxFileSize= : Indique l'espace qu'un journal de log individuel peut occuper sur le stockage volatil (au sein du système de fichiers /run) avant de devoir être limité.

Ces options peuvent toutes aider à contrôler la consommation de stockage par le journal. Un fait important à noter est que les options SystemMaxFileSize et RuntimeMaxFileSize cibleront les fichiers archivés pour atteindre les limites indiquées. C'est un fait important à garder à l'esprit lors de l'interprétation du nombre de fichiers après les opérations de nettoyage.

Conclusion

Il est évident que le journal systemd est un outil incroyablement utile à exploiter, la majorité de ses avantages découlant de la nature centralisée des journaux et du volume important de métadonnées enregistrées. Les fonctionnalités étendues du journal peuvent être exploitées grâce à l’utilisation de la commande journalctl, favorisant une méthode plus simple pour effectuer un débogage relationnel des composants d’application, ainsi qu’une analyse approfondie du système.

Bonne informatique !