systemd Archives - XpresServers

Comment utiliser Journalctl pour consulter et manipuler les journaux Systemd

Introduction

L’un des avantages les plus éloquents de systemd est la journalisation des processus et des systèmes. Lorsque vous utilisez d’autres outils, les journaux se retrouvent généralement dispersés dans le système, traités par différents daemons et processus et leur interprétation peut s’avérer difficile lorsqu’ils s’étendent sur plusieurs applications. Systemd tente de résoudre ces problèmes en offrant une solution de gestion centralisée pour la journalisation de tous les processus du noyau et de l’espace utilisateur. Le système qui collecte et gère ces journaux est ce que l’on nomme le journal.

Le journal est implémenté avec le daemon journald, qui gère tous les messages produits par le noyau, initrd, services, etc. Dans ce guide, nous allons traiter de la façon d’utiliser l’utilitaire journalctl qui peut servir à accéder et manipuler les données contenues dans le journal.

Concept général

L’une des principales motivations du journal systemd consiste à centraliser la gestion des journaux, quelle que soit l’origine des messages. Comme une grande partie du processus de démarrage et de gestion des services est traitée par le processus systemd, il est logique de normaliser la méthode de collecte et d’accès aux journaux. Le daemon journald collecte des données de toutes les sources disponibles et les stocke sous un format binaire qui permet une manipulation facile et dynamique.

Cela nous offre un certain nombre d’avantages importants. En interagissant avec les données à l’aide d’un seul utilitaire, les administrateurs peuvent afficher les données du journal de façon dynamique en fonction de leurs besoins. Vous pouvez tout simplement visualiser les données de démarrage sur les trois derniers démarrages ou combiner les entrées du journal de manière séquentielle à partir de deux services liés pour déboguer un problème de communication.

Le stockage des données du journal sous un format binaire signifie également que vous pouvez afficher les données sous des formats de sortie arbitraires en fonction de ce dont vous avez besoin à un moment donné. Par exemple, pour assurer une gestion quotidienne des journaux, vous avez peut-être l’habitude de visualiser les journaux sous un format syslog standard, mais si vous décidez ultérieurement de présenter les interruptions de service sous forme de graphique, vous pouvez générer chaque entrée en tant qu’objet JSON pour que votre service de graphique puisse le prendre en charge. Étant donné que les données ne sont pas écrites sur le disque en texte clair, vous n’aurez besoin d’aucune conversion si vous avez besoin d’un format à la demande différent.

Le journal systemd peut soit être utilisé avec une implémentation syslog existante, soit remplacer la fonctionnalité syslog en fonction de vos besoins. Bien que le journal systemd couvre la plupart des besoins de journalisation de l’administrateur, il peut également venir compléter les mécanismes de journalisation existants. Par exemple, il se peut que vous utilisiez un serveur syslog centralisé pour compiler des données à partir de plusieurs serveurs, mais vous souhaitez peut-être également pouvoir imbriquer les journaux de plusieurs services sur un seul système avec le journal systemd. Vous pouvez faire les deux en combinant ces technologies.

Configurer l’heure du système

L’un des avantages de l’utilisation d’un journal binaire pour la journalisation est la possibilité d’afficher les enregistrements de journaux en UTC ou à l’heure locale selon les besoins. Par défaut, systemd affichera les résultats en utilisant l’heure locale.

Pour cette raison, avant de commencer à travailler sur le journal, nous veillerons à ce que le fuseau horaire soit correctement défini. En fait, la suite systemd est fournie avec un outil nommé timedatectl qui peut vous y aider.

Tout d’abord, déterminez quels sont les fuseaux horaires disponibles avec l’option list-timezones :

timedatectl list-timezones

Cela répertoriera les fuseaux horaires disponibles sur votre système. Une fois que vous trouverez celui qui correspond à l’emplacement de votre serveur, vous pouvez le configurer en utilisant l’option set-timezone :

sudo timedatectl set-timezone zone

Pour vous assurer que votre machine utilise maintenant l’heure qui convient, utilisez la commande timedatectl seule ou avec l’option status. L’affichage sera le même :

timedatectl status

      Local time: Thu 2015-02-05 14:08:06 EST
  Universal time: Thu 2015-02-05 19:08:06 UTC
        RTC time: Thu 2015-02-05 19:08:06
       Time zone: America/New_York (EST, -0500)
     NTP enabled: no
NTP synchronized: no
 RTC in local TZ: no
      DST active: n/a

La première ligne devrait afficher la bonne heure.

Visualisation du journal de base

Pour voir les journaux collectés par le daemon journald, utilisez la commande journalctl.

Lorsqu’utilisée seule, chaque entrée de journal qui se trouve dans le système s’affichera dans un pager (généralement less) pour que vous puissiez y naviguer. Les entrées les plus anciennes seront les premières :

journalctl

-- Logs begin at Tue 2015-02-03 21:48:52 UTC, end at Tue 2015-02-03 22:29:38 UTC. --
Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49.
Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49.
Feb 03 21:48:52 localhost.localdomain systemd-journald[139]: Received SIGTERM from PID 1 (systemd).
Feb 03 21:48:52 localhost.localdomain kernel: audit: type=1404 audit(1423000132.274:2): enforcing=1 old_en
Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
Feb 03 21:48:52 localhost.localdomain kernel: input: ImExPS/2 Generic Explorer Mouse as /devices/platform/
Feb 03 21:48:52 localhost.localdomain kernel: SELinux:  8 users, 102 roles, 4976 types, 294 bools, 1 sens,
Feb 03 21:48:52 localhost.localdomain kernel: SELinux:  83 classes, 104131 rules

. . .

Vous aurez probablement des pages et des pages de données à consulter, ce qui peut représenter des dizaines ou des centaines de milliers de lignes si systemd est installé sur votre système depuis longtemps. Cela montre combien de données sont disponibles dans la base de données du journal.

Le format sera familier pour ceux qui sont habitués à la journalisation standard des syslog. Cependant, les données collectées proviennent d’un nombre plus important de sources que ne le permettent les implémentations syslog traditionnelles. Cela inclut les journaux des premiers processus de démarrage, le noyau, l’initrd et l’erreur standard d’application. Tous ces éléments sont disponibles dans le journal.

Vous remarquerez peut-être que toutes les heures affichées sont à l’heure locale. Maintenant que nous notre heure locale est configurée sur notre système, elle est disponible pour chaque entrée du journal. Tous les journaux sont affichés en utilisant cette nouvelle information.

Si vous souhaitez afficher les heures en UTC, vous pouvez utiliser la balise --utc.

journalctl --utc

Filtrage des journaux par heure

Même s’il est très pratique d’avoir accès à une série aussi grande de données, il peut s’avérer difficile, voire impossible, d’inspecter et de traiter mentalement une telle quantité de données. Par conséquent, ses options de filtrage font partie des fonctionnalités les plus importantes de journalctl.

Affichage des journaux du démarrage en cours

L’option la plus basique que vous utiliserez éventuellement quotidiennement est la balise -b. Elle affichera toutes les entrées qui ont été recueillies depuis le dernier démarrage.

journalctl -b

Vous pourrez ainsi identifier et gérer plus facilement les informations qui correspondent à votre environnement actuel.

Dans les cas où vous n’utilisez pas cette fonctionnalité et affichez plusieurs jours de démarrages, vous verrez que journalctl a inséré une ligne qui ressemble à ce qui suit à chaque défaillance du système :

. . .

-- Reboot --

. . .

Vous pouvez utiliser cela pour vous aider à séparer logiquement les informations en sessions de démarrage.

Démarrages précédents

Bien que, de manière générale, vous souhaitez afficher les informations du démarrage en cours, il arrivera parfois que les démarrages passés vous soient également utiles. Le journal peut enregistrer des informations de nombreux démarrages précédents, de sorte que journalctl puisse être créé pour afficher les informations facilement.

Certaines distributions permettent de sauvegarder les informations des démarrages précédents par défaut, d’autres désactivent cette fonctionnalité. Pour activer les informations de démarrage persistantes, vous pouvez soit créer le répertoire pour stocker le journal en saisissant ce qui suit :

sudo mkdir -p /var/log/journal

Ou vous pouvez modifier le fichier de configuration du journal :

sudo nano /etc/systemd/journald.conf

Sous la section [Journal], configurez l’option Storage= sur « persistent » pour activer la journalisation persistante :

/etc/systemd/journald.conf

. . .
[Journal]
Storage=persistent

Lorsque la sauvegarde des démarrages précédents est activée sur votre serveur, journalctl intègre quelques commandes pour vous aider à travailler avec des démarrages comme unité de division. Pour voir les démarrages dont journald a connaissance, utilisez l’option --list-boots avec journalctl :

journalctl --list-boots

-2 caf0524a1d394ce0bdbcff75b94444fe Tue 2015-02-03 21:48:52 UTC—Tue 2015-02-03 22:17:00 UTC
-1 13883d180dc0420db0abcb5fa26d6198 Tue 2015-02-03 22:17:03 UTC—Tue 2015-02-03 22:19:08 UTC
 0 bed718b17a73415fade0e4e7f4bea609 Tue 2015-02-03 22:19:12 UTC—Tue 2015-02-03 23:01:01 UTC

Vous verrez s’afficher une ligne pour chaque démarrage. La première colonne représente la valeur offset du démarrage que vous pouvez utiliser pour facilement référencer le démarrage avec journalctl. Si vous avez besoin d’une référence absolue, l’ID de démarrage se trouve dans la deuxième colonne. Vous pouvez déterminer l’heure à laquelle la session de démarrage renvoie en utilisant les deux spécifications chronologiques listées vers la fin.

Pour afficher les informations de ces démarrages, vous pouvez utiliser des informations provenant de la première ou de la deuxième colonne.

Par exemple, pour consulter le journal du démarrage précédent, utilisez le pointeur relatif -1 avec la balise -b :

journalctl -b -1

Vous pouvez également utiliser l’ID de démarrage pour rappeler les données d’un démarrage :

journalctl -b caf0524a1d394ce0bdbcff75b94444fe

Fenêtres d’heures

Bien que la consultation des entrées du journal par démarrage soit très utile, il se peut que vous souhaitiez demander des fenêtres d’heures qui ne s’alignent pas correctement sur les démarrages du système. Cela peut être particulièrement pratique lorsque vous travaillez avec des serveurs de longue durée avec un temps de disponibilité significatif.

Vous pouvez filtrer par des périodes de temps arbitraires en utilisant les options --since et --until, qui limitent respectivement les entrées affichées à celles qui suivent ou précèdent l’heure donnée.

Les valeurs de l’heure peuvent se présenter sous différents formats. Pour les valeurs de temps absolus, vous devez utiliser le format suivant :

YYYY-MM-DD HH:MM:SS

Par exemple, nous pouvons voir toutes les entrées depuis le 10 janvier 2015 à 17 h 15 en saisissant ce qui suit :

journalctl --since "2015-01-10 17:15:00"

Si les composants du format ci-dessus sont supprimés, certaines valeurs par défaut seront appliquées. Par exemple, si la date est omise, le système supposera qu’il s’agit de la date du jour. Si le composant de l’heure est manquant, « 00:00 » (minuit) sera remplacé. Le champ des secondes peut également être laissé à la valeur par défaut de « 00 » :

journalctl --since "2015-01-10" --until "2015-01-11 03:00"

Le journal comprend également certaines valeurs relatives, nommées raccourcis. Par exemple, vous pouvez utiliser les mots « yesterday », « today », « tomorrow » ou « now ». Vous pouvez indiquer des heures relatives en préfixant la valeur numérotée de « – » ou « + » ou en utilisant des mots comme « ago » dans une construction de phrases.

Pour obtenir les données de la veille, vous pourriez taper :

journalctl --since yesterday

Si vous recevez des rapports indiquant une interruption de service qui commence à 9 h 00 et s’est achevée il y a une heure, vous pourriez taper :

journalctl --since 09:00 --until "1 hour ago"

Comme vous pouvez le voir, il est relativement facile de définir des fenêtres flexibles de temps pour filtrer les entrées que vous souhaitez voir.

Filtrer par intérêt des messages

Nous avons précédemment appris certaines des façons qui vous permettent de filtrer les données du journal en utilisant des contraintes de temps. Au cours de cette section, nous allons discuter de la façon de filtrer vos données en fonction du service ou du composant qui vous intéresse. Le journal systemd intègre différents moyens de le faire.

Par unité

La façon probablement la plus pratique de filtrer vos données est de le faire par l’unité qui vous intéresse. Nous pouvons utiliser l’option -u pour filtrer nos données de cette façon.

Par exemple, pour consulter tous les journaux d’une unité Nginx sur notre système, nous pouvons taper :

journalctl -u nginx.service

Généralement, vous voudrez probablement filtrer vos données par heure afin d’afficher les lignes qui vous intéressent. Par exemple, pour vérifier comment le service fonctionne aujourd’hui, vous pouvez taper :

journalctl -u nginx.service --since today

Ce type de concentration peut s’avérer extrêmement utile si vous souhaiter profiter de la capacité du journal à imbriquer les enregistrements de différentes unités. Par exemple, si votre processus Nginx est connecté à une unité PHP-FPM pour traiter le contenu dynamique, vous pouvez fusionner les entrées des deux par ordre chronologique en spécifiant les deux unités :

journalctl -u nginx.service -u php-fpm.service --since today

Cela peut grandement faciliter la détection des interactions entre les différents programmes et les systèmes de débogages au lieu de processus individuels.

Par processus, utilisateur ou ID de groupe

Afin de fonctionner correctement, certains services génèrent tout un panel de processus enfants. Si vous avez mis en évidence le PID exact du processus qui vous intéresse, vous pouvez également filtrer vos données par cette valeur.

Pour ce faire, nous pouvons appliquer notre filtre en renseignant le champ _PID. Par exemple, si le PID qui nous intéresse est 8088, nous pourrions taper :

journalctl _PID=8088

À d’autres moments, vous voudrez afficher toutes les entrées enregistrées par un utilisateur ou un groupe spécifique. Vous pouvez le faire avec les filtres _UID ou _GID. Par exemple, si votre serveur web fonctionne sous l’utilisateur www-data, vous pouvez trouver l’ID de l’utilisateur en tapant ce qui suit :

id -u www-data

Ensuite, vous pouvez utiliser l’ID qui a été renvoyé pour filtrer les résultats du journal :

journalctl _UID=33 --since today

Le journal systemd intègre de nombreux champs qui peuvent être utilisés pour le filtrage. Certaines d’entre eux sont passés à partir du processus en cours d’enregistrement et d’autres appliqués par journald en utilisant les informations qu’il recueille à partir du système au moment de la journalisation.

Le résultat principal indique que le champ _PID est de ce dernier type. Le journal enregistre et indexe automatiquement le PID du processus en cours de journalisation qui permet un filtrage ultérieur. Pour en savoir plus sur tous les champs disponibles des journaux, saisissez :

man systemd.journal-fields

Nous allons traiter de certains de ces éléments dans ce guide. Cependant, pour le moment, nous allons étudier une option plus utile liée au filtrage de ces champs. Vous pouvez utiliser l’option -F pour afficher toutes les valeurs disponibles pour un champ donné du journal.

Par exemple, pour consulter pour quels groupes d’ID le journal systemd dispose d’entrées, vous pouvez saisir :

journalctl -F _GID

Cela affichera toutes les valeurs que le journal a stockées pour le champ de l’ID du groupe. Cela peut vous aider à construire vos filtres.

Par chemin de composants

Nous pouvons également filtrer nos données en renseignant un emplacement de chemin.

Si le chemin mène à un exécutable, journalctl affichera toutes les entrées qui impliquent l’exécutable en question. Par exemple, pour trouver les entrées qui impliquent l’exécutable bash, vous pouvez taper :

journalctl /usr/bin/bash

Généralement, si une unité est disponible pour l’exécutable, cette méthode est plus propre et donne de meilleures informations (entrées des processus enfants associés, etc). Cependant, il arrivera parfois que cela ne soit pas possible.

Afficher les messages du noyau

Les messages du noyau, ceux qui se trouvent généralement dans la sortie dmesg peuvent également être récupérés dans le journal.

Pour afficher uniquement ces messages, nous pouvons ajouter les balises -k ou --dmesg à notre commande :

journalctl -k

Par défaut, cela affichera les messages du noyau du démarrage actuel. Vous pouvez spécifier un démarrage alternatif en utilisant les balises usuelles de sélection de démarrage dont nous avons précédemment parlé. Par exemple, pour obtenir les messages des cinq derniers démarrages, vous pourriez taper :

journalctl -k -b -5

Par priorité

L’un des filtres auxquels s’intéressent souvent les administrateurs de système est la priorité des messages. Bien qu’il soit souvent utile de consigner les informations à un niveau très verbeux, pour digérer les informations disponibles, les journaux de faible priorité peuvent être déroutants et confus.

Vous pouvez utiliser journalctl pour afficher uniquement les messages d’une priorité spécifiée ou au-dessus en utilisant l’option -p. Cela vous permet de filtrer les messages de priorité inférieure.

Par exemple, pour afficher uniquement les entrées enregistrées au niveau des erreurs ou au-dessus, vous pouvez taper :

journalctl -p err -b

Cela vous montrera tous les messages indiquant une erreur, un état critique, un avertissement ou une urgence. Le journal implémente les niveaux de messages syslog standard. Vous pouvez utiliser soit le nom de la priorité, soit la valeur numérique correspondante. En partant de la plus haute à la plus basse, les priorités sont les suivantes :

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

Vous pouvez utiliser les numéros ou noms ci-dessus de manière interchangeable avec l’option -p. En sélectionnant une priorité, vous afficherez les messages marqués au niveau indiqué et aux niveaux supérieurs.

Modification de l’affichage du journal

Précédemment, nous vous avons montré comment utiliser le filtrage pour sélectionner des données. Il existe cependant d’autres façons de modifier la sortie. Nous pouvons ajuster l’affichage journalctl en fonction de divers besoins.

Tronquer ou étendre le résultat

Nous pouvons ajuster la façon dont journalctl affiche les données en l’instruisant de réduire ou d’étendre la sortie.

Par défaut, journalctl affichera l’intégralité du résultat dans un pager, ce qui permet aux entrées de se diriger vers la droite de l’écran. Pour accéder à cette information, appuyez sur la touche de flèche droite.

Si vous souhaitez tronquer le résultat, en insérant une ellipse à l’endroit où les informations ont été supprimées, vous pouvez utiliser l’option --no-full :

journalctl --no-full

. . .

Feb 04 20:54:13 journalme sshd[937]: Failed password for root from 83.234.207.60...h2
Feb 04 20:54:13 journalme sshd[937]: Connection closed by 83.234.207.60 [preauth]
Feb 04 20:54:13 journalme sshd[937]: PAM 2 more authentication failures; logname...ot

Vous pouvez également aller dans la direction inverse et demander à journalctl d’afficher toutes les informations dont il dispose, qu’il inclut des caractères non imprimables ou pas. Nous pouvons le faire avec la balise -a :

journalctl -a

Sortie sur Standard

Par défaut, journalctl affiche la sortie dans un pager pour faciliter la consommation des données. Cependant, si vous prévoyez de traiter les données avec des outils de manipulation de texte, vous voudrez probablement pouvoir produire une sortie standard sur la sortie.

Vous pouvez le faire avec l’option --no-pager :

journalctl --no-pager

Vous pouvez immédiatement acheminer votre résultat dans un utilitaire de traitement ou le rediriger vers un fichier sur le disque, en fonction de vos besoins.

Formats de sortie

Si vous traitez des entrées de journaux, comme mentionné ci-dessus, il vous sera probablement plus facile d’analyser les données si elles sont dans format plus digeste. Heureusement, le journal peut s’afficher sous divers formats selon les besoins. Vous pouvez le faire en utilisant l’option -o et un spécificateur de format.

Par exemple, vous pouvez générer les entrées du journal dans JSON en tapant :

journalctl -b -u nginx -o json

{ "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635", "__REALTIME_TIMESTAMP" : "1422990364739502", "__MONOTONIC_TIMESTAMP" : "27200938", "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d", "PRIORITY" : "6", "_UID" : "0", "_GID" : "0", "_CAP_EFFECTIVE" : "3fffffffff", "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee", "_HOSTNAME" : "desktop", "SYSLOG_FACILITY" : "3", "CODE_FILE" : "src/core/unit.c", "CODE_LINE" : "1402", "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading", "SYSLOG_IDENTIFIER" : "systemd", "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5", "_TRANSPORT" : "journal", "_PID" : "1", "_COMM" : "systemd", "_EXE" : "/usr/lib/systemd/systemd", "_CMDLINE" : "/usr/lib/systemd/systemd", "_SYSTEMD_CGROUP" : "/", "UNIT" : "nginx.service", "MESSAGE" : "Starting A high performance web server and a reverse proxy server...", "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973" }

. . .

Très utile pour l’analyse avec les utilitaires. Vous pourriez utiliser le format json-pretty pour obtenir une meilleure maîtrise sur la structure des données avant de les passer au consommateur JSON :

journalctl -b -u nginx -o json-pretty

{
    "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635",
    "__REALTIME_TIMESTAMP" : "1422990364739502",
    "__MONOTONIC_TIMESTAMP" : "27200938",
    "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d",
    "PRIORITY" : "6",
    "_UID" : "0",
    "_GID" : "0",
    "_CAP_EFFECTIVE" : "3fffffffff",
    "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee",
    "_HOSTNAME" : "desktop",
    "SYSLOG_FACILITY" : "3",
    "CODE_FILE" : "src/core/unit.c",
    "CODE_LINE" : "1402",
    "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading",
    "SYSLOG_IDENTIFIER" : "systemd",
    "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5",
    "_TRANSPORT" : "journal",
    "_PID" : "1",
    "_COMM" : "systemd",
    "_EXE" : "/usr/lib/systemd/systemd",
    "_CMDLINE" : "/usr/lib/systemd/systemd",
    "_SYSTEMD_CGROUP" : "/",
    "UNIT" : "nginx.service",
    "MESSAGE" : "Starting A high performance web server and a reverse proxy server...",
    "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973"
}

. . .

Les formats d’affichage disponibles sont les suivants :

cat : affiche uniquement le champ du message en lui-même.
export : un format binaire adapté au transfert ou à la sauvegarde de données.
json : JSON standard avec une entrée par ligne.
json-pretty : JSON formaté pour une meilleure lisibilité par l’homme
json-sse : résultat formaté sous JSON enveloppé pour que l’événement add server-sen soit compatible
short : la sortie de style syslog par défaut
short-iso :le format par défaut a été augmenté pour afficher les horodatages d’horloge murale ISO 8601
short-monotonic : le format par défaut avec des horodatages monotones.
short-precise : le format par défaut avec précision à la microseconde près
verbose : affiche chaque champ de journal disponible pour l’entrée, y compris ceux généralement cachés en interne.

Ces options vous permettent d’afficher les entrées du journal dans le format le plus adapté à vos besoins actuels.

Surveillance active des processus

La commande journalctl imite le nombre d’administrateurs qui utilisent tail pour la surveillance d’une activité active ou récente. Cette fonctionnalité est intégrée dans journalctl et vous permet d’accéder à ces fonctionnalités sans avoir à vous diriger vers un autre outil.

Affichage des journaux récents

Pour afficher une quantité d’enregistrements définie, vous pouvez utiliser l’option -n, qui fonctionne exactement comme tail -n.

Par défaut, les 10 entrées les plus récentes s’afficheront :

journalctl -n

Vous pouvez spécifier le nombre d’entrées que vous souhaitez consulter en ajoutant un numéro après le -n :

journalctl -n 20

Suivi des journaux

Pour suivre activement les journaux à mesure de leur écriture, vous pouvez utiliser la balise -f. Encore une fois, cela fonctionne comme vous pouvez vous y attendre si vous déjà utilisé tail -f:

journalctl -f

Maintenance des journaux

Vous devez éventuellement vous demander combien coûte le stockage de toutes ces données que nous avons vues jusqu’à présent. En outre, vous pourriez vouloir nettoyer certains journaux anciens et libérer de l’espace.

Trouver l’utilisation actuelle du disque

Vous pouvez trouver la quantité d’espace que le journal occupe actuellement sur le disque en utilisant la balise --disk-usage :

journalctl --disk-usage

Journals take up 8.0M on disk.

Suppression des anciens journaux

Si vous souhaitez réduire votre journal, vous disposez de deux façons différentes de le faire (disponibles avec les versions 218 et ultérieures de systemd).

Si vous utilisez l’option --vacuum-size, vous pouvez réduire votre journal en indiquant une taille. Les anciennes entrées seront supprimées jusqu’à que l’espace de journal total occupé sur le disque atteigne la taille demandée :

sudo journalctl --vacuum-size=1G

Il existe une autre façon de réduire le journal, qui consiste à fournir une heure de calcul avec l’option --vacuum-time. Le système supprime toutes les entrées au-delà de cette heure. Vous pourrez ainsi conserver les entrées qui ont été créées après une heure spécifique.

Par exemple, pour conserver les entrées de l’année dernière, vous pouvez taper :

sudo journalctl --vacuum-time=1years

Limitation de l’expansion du journal

Vous pouvez configurer votre serveur de manière à ce qu’il place des limites sur la quantité d’espace que le journal peut prendre. Pour cela, vous devez éditer le fichier /etc/systemd/journald.conf.

Vous pouvez utiliser les éléments suivants pour limiter l’expansion du journal :

SystemMaxUse= : Spécifie l’espace disque maximal qui peut être utilisé par le journal dans un stockage persistant.
SystemKeepFree= : Spécifie la quantité d’espace libre que le journal doit laisser lors de l’ajout d’entrées du journal au stockage persistant.
SystemMaxFileSize= : contrôle la taille que les fichiers journaux individuels peuvent atteindre dans le stockage persistant avant la rotation.
RuntimeMaxUse= : Spécifie l’espace disque maximal qui peut être utilisé dans le stockage volatile (dans le système de fichiers /run).
RuntimeKeepFree= : Spécifie la quantité d’espace à mettre de côté pour d’autres utilisations lors de l’écriture des données sur un stockage volatile (dans le système de fichiers /run).
RuntimeMaxFileSize= : Spécifie la quantité d’espace qu’un fichier de journal individuel peut prendre en charge dans un stockage volatile (dans le système de fichiers /run) avant la rotation.

En configurant ces valeurs, vous pouvez contrôler la façon dont journald consomme et conserve l’espace sur votre serveur. Gardez à l’esprit que SystemMaxFileSize et RuntimeMaxFileSize cibleront les fichiers archivés pour atteindre les limites indiquées. Ceci est important à retenir lors de l’interprétation du nombre de fichiers après une opération de nettoyage.

Conclusion

Comme vous pouvez le voir, le journal systemd est très utile pour collecter et gérer les données de votre système et de l’application. Une grande partie de la flexibilité provient des métadonnées complètes automatiquement enregistrées et de la nature centralisée du journal. La commande journalctl permet de profiter des fonctionnalités avancées du journal et de faire une analyse et un débogage relationnel des différents composants de l’application.

Source link

Cómo usar Journalctl para ver y manipular los registros de Systemd

Introducción

Algunas de las ventajas más convincentes de systemd son las que se relacionan con el proceso y registro del sistema. Al usar otros sistemas, los registros suelen estar dispersos por todo el sistema, son manejados por diferentes demonios y herramientas, y puede ser bastante difícil de interpretar cuando abarcan varias aplicaciones. Systemd intenta resolver estos problemas al proporcionar una solución de administración centralizada para registrar todos los procesos del kernel y del usuario. El sistema que recopila y administra estos registros se conoce como diario.

El diario se implementa con el demonio journald, que gestiona todos los mensajes producidos por el kernel, initrd, servicios, etc. En esta guía, veremos cómo usar la utilidad journalctl, que puede usarse para acceder y manipular los datos que se encuentran dentro del diario.

Idea general

Uno de los impulsos detrás del diario systemd es centralizar la administración de los registros, independientemente de dónde se originen los mensajes. Dado que el proceso systemd gestiona gran parte del proceso de arranque y administración de servicios, tiene sentido estandarizar la forma en que se recopila y acceden a estos registros. El demonio journald recopila datos de todas las fuentes disponibles y los almacena en un formato binario para una manipulación fácil y dinámica.

Eso nos proporciona varias ventajas significativas. Al interactuar con los datos usando una sola utilidad, los administradores pueden mostrar datos de registro de forma dinámica según sus necesidades. Esto puede ser tan simple como ver los datos del arranque de hace tres arranques o combinar las entradas de registro de forma secuencial de dos servicios relacionados para depurar un problema de comunicación.

Almacenar los datos de registro en formato binario también significa que los datos pueden mostrarse en formatos de salida arbitrarios dependiendo de lo que se necesite en el momento. Por ejemplo, para la gestión de los registros diarios puede que esté acostumbrado a ver los registros en el formato estándar de syslog, pero si decide graficar las interrupciones del servicio más adelante, puede mostrar cada entrada como un objeto JSON para que sea consumible en su servicio gráfico. Dado que los datos no se escriben en el disco en texto plano, no es necesario convertirlos cuando se necesita un distinto formato bajo demanda.

El diario systemd puede usarse con una implementación de syslog existente o puede sustituir la funcionalidad syslog, según sus necesidades. Aunque el diario systemd cubrirá la mayoría de las necesidades de registro del administrador, también puede complementar los mecanismos de registro existentes. Por ejemplo, es posible que tenga un servidor syslog centralizado que utilice para compilar datos de varios servidores, pero también es posible que quiera interconectar los registros de varios servicios en un solo sistema con el diario systemd. Puede hacer ambas cosas combinando estas tecnologías.

Configurar la hora del sistema

Una de las ventajas de usar un diario binario para el registro es la posibilidad de ver los registros en hora UTC o local libremente. systemd mostrará los resultados en hora local de manera predeterminada.

Debido a esto, antes de comenzar con el diario, nos aseguraremos de que la zona horaria esté configurada correctamente. El paquete de systemd realmente viene con una herramienta llamada timedatectl que puede ayudar con esto.

Primero, consulte qué zonas horarias están disponibles con la opción list-timezones:

timedatectl list-timezones

Esto mostrará la lista de zonas horarias disponibles en su sistema. Cuando encuentre la que coincida con la ubicación de su servidor, puede configurarla usando la opción set-timezone:

sudo timedatectl set-timezone zone

Para asegurarse de que su máquina esté usando la hora correcta actual, utilice el comando timedatectl solo o con la opción status. En la pantalla, se mostrará lo mismo:

timedatectl status

      Local time: Thu 2015-02-05 14:08:06 EST
  Universal time: Thu 2015-02-05 19:08:06 UTC
        RTC time: Thu 2015-02-05 19:08:06
       Time zone: America/New_York (EST, -0500)
     NTP enabled: no
NTP synchronized: no
 RTC in local TZ: no
      DST active: n/a

La primera línea debe mostrar la hora correcta.

Visualización básica de registros

Para ver los registros que el demonio journald ha recopila el comando journalctl.

Cuando se utilice solo, cada entrada de diario que se encuentre en el sistema se mostrará dentro de un localizador (por lo general, less) para que pueda navegar en él Las entradas más antiguas estarán arriba:

journalctl

-- Logs begin at Tue 2015-02-03 21:48:52 UTC, end at Tue 2015-02-03 22:29:38 UTC. --
Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49.
Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49.
Feb 03 21:48:52 localhost.localdomain systemd-journald[139]: Received SIGTERM from PID 1 (systemd).
Feb 03 21:48:52 localhost.localdomain kernel: audit: type=1404 audit(1423000132.274:2): enforcing=1 old_en
Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
Feb 03 21:48:52 localhost.localdomain kernel: input: ImExPS/2 Generic Explorer Mouse as /devices/platform/
Feb 03 21:48:52 localhost.localdomain kernel: SELinux:  8 users, 102 roles, 4976 types, 294 bools, 1 sens,
Feb 03 21:48:52 localhost.localdomain kernel: SELinux:  83 classes, 104131 rules

. . .

Es probable que tenga que desplazarse por páginas y páginas de datos, que pueden ser decenas o cientos de miles de líneas si systemd ha estado en su sistema por mucho tiempo. Esto demuestra la cantidad de datos disponibles en la base de datos del diario.

El formato será familiar para aquellos que se utilizan para el registro syslog estándar. Sin embargo, esto realmente recopila datos de más fuentes de las que las implementaciones syslog tradicionales son capaces de recopilar. Incluye registros del proceso de arranque inicial, el kernel, el initrd, el error de estándar de la aplicación y la salida. Todos ellos están disponibles en el diario.

Es posible que observe que todas las marcas de tiempo que se muestran son de hora local. Esto está disponible para cada entrada de registro ahora que tenemos nuestro tiempo local correctamente configurado en el sistema. Todos los registros se muestran usando esta nueva información.

Si desea mostrar las marcas de tiempo en hora UTC, puede usar el indicador --utc:

journalctl --utc

Filtrado del diario por hora

A pesar de que tener acceso a una colección tan grande de datos es definitivamente útil, es difícil o imposible inspeccionar y procesar mentalmente tal gran cantidad de datos. Debido a esto, una de las características más importantes de journalctl son sus opciones de filtrado.

Mostrar los registros del arranque actual

La más básica de estas que puede usar diariamente, es el indicador -b. Este indicador mostrará todas las entradas del diario que se recopilaron desde el reinicio más reciente.

journalctl -b

Esto le ayudará a identificar y administrar la información que sea pertinente para su entorno actual.

En los casos en que no se usa esta función y se muestran más de un día de arranques, verá que journalctl insertó una línea parecida a la siguiente cada vez que el sistema se cae:

. . .

-- Reboot --

. . .

Lo puede usar para separar la información de manera lógica en sesiones de arranque.

Arranques anteriores

Aunque por lo general querrá mostrar la información del arranque actual, hay ocasiones en que los arranques anteriores también son útiles. El diario puede guardar la información de varios arranques anteriores, por lo que journalctl puede usarse para mostrar la información más fácilmente.

Algunas distribuciones permiten guardar la información de los arranques anteriores de manera predeterminada, mientras que otras deshabilitan esta función. Para habilitar la información de arranque persistente, puede crear el directorio para almacenar el diario escribiendo lo siguiente:

sudo mkdir -p /var/log/journal

O puede editar el archivo de configuración del diario:

sudo nano /etc/systemd/journald.conf

En la sección [Journal], establezca la opción Storage= en “persistent” (persistente) para habilitar el registro persistente:

/etc/systemd/journald.conf

. . .
[Journal]
Storage=persistent

Cuando la opción de guardar los arranques anteriores está habilitada en su servidor, journalctl proporciona algunos comandos para ayudarlo a trabajar con los arranques como unidad de división. Para ver los arranques que journald conoce, utilice la opción --list-boots con journalctl:

journalctl --list-boots

-2 caf0524a1d394ce0bdbcff75b94444fe Tue 2015-02-03 21:48:52 UTC—Tue 2015-02-03 22:17:00 UTC
-1 13883d180dc0420db0abcb5fa26d6198 Tue 2015-02-03 22:17:03 UTC—Tue 2015-02-03 22:19:08 UTC
 0 bed718b17a73415fade0e4e7f4bea609 Tue 2015-02-03 22:19:12 UTC—Tue 2015-02-03 23:01:01 UTC

Esto mostrará una línea para cada arranque. La primera columna es la compensación del arranque que puede usarse para hacer referencia fácilmente al arranque con journalctl. Si necesita una referencia absoluta, el ID del arranque está en la segunda columna. Puede saber la hora a la que se refiere la sesión de arranque con las dos especificaciones de hora que aparecen al final.

Para mostrar la información de estos arranques, puede usar la información de la primera o la segunda columna.

Por ejemplo, para ver el diario del arranque anterior, utilice el puntero relativo -1 con el indicador -b:

journalctl -b -1

También puede usar el ID de arranque invocar los datos de un arranque:

journalctl -b caf0524a1d394ce0bdbcff75b94444fe

Ventanas de tiempo

Aunque ver las entradas de registro por arranque es increíblemente útil, en ocasiones es posible que quiera solicitar ventanas de tiempo que no se alinean bien con el arranque del sistema. Este puede ser el caso especialmente cuando se trata de servidores de larga duración con un tiempo de actividad significativo.

Puede filtrar por límites de tiempo arbitrarios usando las opciones --since y --until, que restringen las entradas mostradas a aquellas posteriores o anteriores al tiempo indicado, respectivamente.

Los valores de tiempo pueden venir en varios formatos. Para los valores absolutos de tiempo, debe usar el siguiente formato:

YYYY-MM-DD HH:MM:SS

Por ejemplo, podemos ver todas las entradas desde el 10 de enero de 2015 a las 5:15 p. m. escribiendo:

journalctl --since "2015-01-10 17:15:00"

Si se omiten los componentes del formato anterior, se aplicarán algunos valores predeterminados. Por ejemplo, si se omite la fecha, se asumirá la fecha actual. Si falta el componente que hace referencia a la hora, se sustituirá por “00:00:00” (medianoche). El campo de los segundos también se puede omitir para que aparezca “00” de manera predeterminada:

journalctl --since "2015-01-10" --until "2015-01-11 03:00"

El diario también comprende algunos valores relativos y los accesos directos con nombre. Por ejemplo, puede usar las palabras “yesterday”, “today”, “tomorrow”, o “now”. Puede hacer referencia a tiempos relativos anteponiendo “-” o “+” a un valor numérico o utilizando palabras como “ago” en la construcción de las instrucciones.

Para obtener los datos del día de ayer, puede escribir lo siguiente:

journalctl --since yesterday

Si recibió informes de una interrupción del servicio que comenzó a las 9:00 a.m. y continuó hasta hace una hora, puede escribir lo siguiente:

journalctl --since 09:00 --until "1 hour ago"

Como puede ver, es relativamente fácil definir ventanas de tiempo flexibles para filtrar las entradas que desea ver.

Filtrado por interés de mensaje

En la sección anterior hemos aprendido algunas formas de filtrar los datos del diario utilizando restricciones de tiempo. En esta sección, veremos cómo filtrar según el servicio o componente que le interese. El diario systemd proporciona varias formas de hacer esto.

Por unidad

Probablemente la forma más útil de filtrar es por la unidad que le interesa. Podemos usar la opción -u para filtrar de esta manera.

Por ejemplo, para ver todos los registros de una unidad de Nginx en nuestro sistema, podemos escribir lo siguiente:

journalctl -u nginx.service

Por lo general, también querrá filtrar por tiempo para mostrar las líneas que le interesa. Por ejemplo, para comprobar cómo se está ejecutando el servicio hoy, puede escribir lo siguiente:

journalctl -u nginx.service --since today

Este tipo de enfoque resulta extremadamente útil cuando se aprovecha la capacidad del diario para intercalar registros de varias unidades. Por ejemplo, si su proceso de Nginx está conectado a una unidad PHP-FPM para procesar contenido dinámico, puede combinar las entradas de ambos en orden cronológico especificando ambas unidades:

journalctl -u nginx.service -u php-fpm.service --since today

Eso puede hacer que sea mucho más fácil detectar las interacciones entre diferentes programas y sistemas de depuración en vez de procesos individuales.

Por proceso, usuario o ID de grupo

Algunos servicios generan varios procesos secundarios para realizar el trabajo. Si ha localizado el PID exacto del proceso que le interesa, también se puede hacer un filtrado basándonos en eso.

Para hacer esto, podemos filtrar especificando el campo _PID. Por ejemplo, si el PID que nos interesa es 8088, podemos escribir lo siguiente:

journalctl _PID=8088

En otras ocasiones, es posible que quiera mostrar todas las entradas registradas de un usuario o de un grupo específico. Esto puede hacerse con los filtros _UID o _GID. Por ejemplo, si su servidor web se ejecuta bajo el usuario www-data, puede encontrar el ID de usuario escribiendo lo siguiente:

id -u www-data

Luego, puede usar el ID que salió en la búsqueda para filtrar los resultados del diario:

journalctl _UID=33 --since today

El diario systemd tiene muchos campos que pueden usarse para filtrar. Algunos de estos son pasados desde el proceso que se está registrando y otros son aplicados por journald usando la información que recopila del sistema en el momento del registro.

El símbolo inicial de guion bajo indica que el campo _PID es de este último tipo. El diario registra e indexa automáticamente el PID del proceso que está registrando para filtrarlo después. Puede obtener información sobre todos los campos disponibles del diario escribiendo lo siguiente:

man systemd.journal-fields

En esta guía, veremos algunas de estas opciones. Por ahora, sin embargo, vamos a repasar una opción más útil que tiene que ver con el filtrado mediante estos campos. La opción -F puede usarse para mostrar todos los valores disponibles para un determinado campo del diario.

Por ejemplo, para ver qué ID de grupo tiene entradas el diario systemd, puede escribir lo siguiente:

journalctl -F _GID

Esto mostrará todos los valores que el diario almacenó para el campo del ID de grupo. Esto puede ayudarlo a crear sus filtros.

Por ruta de componente

También podemos filtrar proporcionando una ubicación de ruta.

Si la ruta conduce a un ejecutable, journalctl mostrará todas las entradas que implican el ejecutable en cuestión. Por ejemplo, para encontrar aquellas entradas que implican el ejecutable bash, puede escribir lo siguiente:

journalctl /usr/bin/bash

Por lo general, si una unidad está disponible para el ejecutable, ese método es más limpio y proporciona mejor información (entradas de procesos secundarios asociados, etc.). A veces, sin embargo, eso no es posible.

Mostrar mensajes de kernel

Los mensajes de kernel, que suelen encontrarse en el resultado de dmesg, también se pueden recuperar del diario.

Para mostrar solo estos mensajes, podemos añadir los indicadores -k o --dmesg a nuestro comando:

journalctl -k

De manera predeterminada, esto mostrará los mensajes del kernel del arranque actual. Puede especificar un arranque alternativo usando los indicadores normales de selección de arranque que se mostraron anteriormente. Por ejemplo, para obtener los mensajes de hace cinco arranques, puede escribir lo siguiente:

journalctl -k -b -5

Por prioridad

Un filtro que suele interesar a los administradores de sistemas es el de prioridad de mensaje. Aunque a menudo es útil registrar información a un nivel muy verboso, cuando realmente se asimila la información disponible, los registros de baja prioridad pueden distraer y confundir.

Puede usar journalctl para mostrar solo mensajes de una prioridad especifica o superior usando la opción -p. Esto le permite filtrar mensajes de menor prioridad.

Por ejemplo, para mostrar solo las entradas registradas en el nivel de error o superior, puede escribir lo siguiente:

journalctl -p err -b

Esto le mostrará todos los mensajes marcados como error, crítico, alerta o emergencia. El diario implementa los niveles de mensaje syslog estándar. Puede usar el nombre de prioridad o su valor numérico correspondiente. En orden de mayor a menor prioridad, estos son:

0: emergencia
1: alerta
2: crítico
3: error
4: advertencia
5: aviso
6: información
7: depuración

Los números o nombres anteriores pueden usarse indistintamente con la opción -p. Al seleccionar una prioridad, se mostrarán los mensajes marcados en el nivel especificado y aquellos que se encuentran por encima.

Modificar la pantalla del diario

Anteriormente, hemos demostrado la selección de entradas mediante el filtrado. Sin embargo, hay otras formas de modificar el resultado. Podemos ajustar la pantalla journalctl para que se adapte a varias necesidades.

Truncar o ampliar el resultado

Podemos ajustar la forma en que journalctl muestra datos indicándole que reduzca o amplíe el resultado.

Por defecto, journalctl mostrará toda la entrada en el localizador, permitiendo que las entradas se desplacen a la derecha de la pantalla. Se puede acceder a esta información presionando la tecla de flecha derecha.

Si prefiere truncar el resultado, insertar un elipses donde se eliminó la información, puede usar la opción --no-full:

journalctl --no-full

. . .

Feb 04 20:54:13 journalme sshd[937]: Failed password for root from 83.234.207.60...h2
Feb 04 20:54:13 journalme sshd[937]: Connection closed by 83.234.207.60 [preauth]
Feb 04 20:54:13 journalme sshd[937]: PAM 2 more authentication failures; logname...ot

También puede hacer lo opuesto e indicarle a journalctl que muestre toda la información, independientemente de si incluye caracteres no imprimibles. Podemos hacerlo con el indicador -a:

journalctl -a

Resultado a la salida estándar

Por defecto, journalctl muestra el resultado en un localizador para un uso más sencillo. Sin embargo, si está planeando procesar los datos con herramientas de manipulación de texto, es probable que quiera poder mostrar un resultado estándar.

Puede hacer esto con la opción --no-pager:

journalctl --no-pager

Se puede canalizar inmediatamente a una utilidad de procesamiento o redireccionar a un archivo en el disco, dependiendo de sus necesidades.

Formatos de resultado

Si está procesando las entradas del diario, como se mencionó anteriormente, es probable que le resulte más fácil analizar los datos si están en un formato más fácil de usar. Afortunadamente, el diario puede mostrarse en varios formatos según sea necesario. Puede hacerlo usando la opción -o con un especificador de formato.

Por ejemplo, puede mostrar las entradas del diario en JSON escribiendo lo siguiente:

journalctl -b -u nginx -o json

{ "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635", "__REALTIME_TIMESTAMP" : "1422990364739502", "__MONOTONIC_TIMESTAMP" : "27200938", "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d", "PRIORITY" : "6", "_UID" : "0", "_GID" : "0", "_CAP_EFFECTIVE" : "3fffffffff", "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee", "_HOSTNAME" : "desktop", "SYSLOG_FACILITY" : "3", "CODE_FILE" : "src/core/unit.c", "CODE_LINE" : "1402", "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading", "SYSLOG_IDENTIFIER" : "systemd", "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5", "_TRANSPORT" : "journal", "_PID" : "1", "_COMM" : "systemd", "_EXE" : "/usr/lib/systemd/systemd", "_CMDLINE" : "/usr/lib/systemd/systemd", "_SYSTEMD_CGROUP" : "/", "UNIT" : "nginx.service", "MESSAGE" : "Starting A high performance web server and a reverse proxy server...", "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973" }

. . .

Eso es útil para el análisis sintáctico con utilidades. Puede usar el formato json-pretty para obtener un mejor manejo de la estructura de datos antes de transmitirla al consumidor JSON:

journalctl -b -u nginx -o json-pretty

{
    "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635",
    "__REALTIME_TIMESTAMP" : "1422990364739502",
    "__MONOTONIC_TIMESTAMP" : "27200938",
    "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d",
    "PRIORITY" : "6",
    "_UID" : "0",
    "_GID" : "0",
    "_CAP_EFFECTIVE" : "3fffffffff",
    "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee",
    "_HOSTNAME" : "desktop",
    "SYSLOG_FACILITY" : "3",
    "CODE_FILE" : "src/core/unit.c",
    "CODE_LINE" : "1402",
    "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading",
    "SYSLOG_IDENTIFIER" : "systemd",
    "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5",
    "_TRANSPORT" : "journal",
    "_PID" : "1",
    "_COMM" : "systemd",
    "_EXE" : "/usr/lib/systemd/systemd",
    "_CMDLINE" : "/usr/lib/systemd/systemd",
    "_SYSTEMD_CGROUP" : "/",
    "UNIT" : "nginx.service",
    "MESSAGE" : "Starting A high performance web server and a reverse proxy server...",
    "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973"
}

. . .

Se pueden usar los siguientes formatos para la visualización:

cat: Muestra solo el campo de mensaje.
export: Formato binario adecuado para transferir o hacer copias de seguridad.
json: JSON estándar con una entrada por línea.
json-pretty: JSON formateado para una mejor legibilidad humana
json-sse: Resultado formateado JSON envuelto para hacer que el evento enviado por servidor sea compatible
short: El resultado de estilo syslog predeterminado
short-iso: El formato predeterminado aumentado para mostrar las marcas de tiempo del reloj de pared ISO 8601.
short-monotonic: El formato predeterminado con marcas de tiempo monotónicas.
short-precise: El formato predeterminado con precisión de microsegundos.
verbose: Muestra todos los campos del diario disponibles para la entrada, incluidos los que suelen estar ocultos internamente.

Estas opciones le permiten mostrar las entradas del diario en el formato que mejor se adapte a sus necesidades actuales.

Supervisión activa de procesos

El comando journalctl imita la cantidad de administradores que utilizan tail para supervisar la actividad activa o reciente. Esta funcionalidad está incorporada en journalctl, lo que le permite acceder a estas funciones sin necesidad de recurrir a otra herramienta.

Cómo mostrar los registros recientes

Para mostrar una cantidad determinada de registros, puede usar la opción -n, que funciona exactamente igual que tail -n.

Por defecto, se mostrarán las 10 entradas más recientes:

journalctl -n

Puede especificar el número de entradas que desea ver agregando un número después de -n:

journalctl -n 20

Cómo hacer un seguimiento de los registros

Para seguir activamente los registros a medida que se escriben, puede usar el indicador -f. Una vez más, esto funciona de la manera prevista si tiene experiencia usando tail -f:

journalctl -f

Mantenimiento del diario

Es posible que se esté preguntando sobre el costo de almacenar todos los datos que hemos visto hasta ahora. Además, puede que le interese limpiar algunos registros antiguos y liberar espacio.

Cómo encontrar el uso actual de disco

Puede averiguar la cantidad de espacio que el diario está ocupando actualmente en el disco usando la opción el indicador --disk-usage:

journalctl --disk-usage

Journals take up 8.0M on disk.

Cómo eliminar registros antiguos

Si desea reducir su diario, puede hacerlo de dos distintas formas (disponibles en la versión 218 y posterior de systemd).

Si usa la opción --vacuum-size, puede reducir su diario indicando un tamaño. Esto eliminará las entradas antiguas hasta que el espacio total del diario ocupado en el disco sea del tamaño solicitado:

sudo journalctl --vacuum-size=1G

Otra forma de reducir el diario es proporcionar un tiempo límite con la opción --vacuum-time. Cualquier entrada que sobrepase ese límite de tiempo será eliminada. Esto le permite mantener las entradas que se han creado después de un tiempo específico.

Por ejemplo, para guardar las entradas del último año, puede escribir lo siguiente:

sudo journalctl --vacuum-time=1years

Cómo limitar la expansión del diario

Puede configurar su servidor para que ponga límites sobre cantidad de espacio que puede ocupar el diario. Puede hacer esto editando el archivo /etc/systemd/journald.conf

Puede usar los siguientes elementos para limitar la expansión del diario:

SystemMaxUse=: especifica el espacio máximo de disco que puede usar el diario en el almacenamiento persistente.
SystemKeepFree=: especifica la cantidad de espacio que el diario debe dejar libre al añadir entradas del diario al almacenamiento persistente.
SystemMaxFileSize=: controla el tamaño que pueden alcanzar los archivos individuales del diario en el almacenamiento persistente antes de rotar.
RuntimeMaxUse=: especifica el espacio máximo de disco que puede usarse en el almacenamiento volátil (dentro del sistema de archivos /run).
RuntimeKeepFree=: especifica la cantidad de espacio que debe reservarse para otros usos al escribir datos en el almacenamiento volátil (dentro del sistema de archivos /run).
RuntimeMaxFileSize=: especifica la cantidad de espacio que puede ocupar un archivo de diario individual en el almacenamiento volátil (dentro del sistema de archivos /run) antes de rotar.

Al establecer estos valores, puede controlar la forma en que journald utiliza y preserva el espacio en su servidor. Tenga en cuenta que SystemMaxFileSize y RuntimeMaxFileSize orientarán los archivos para llegar a los límites indicados. Es importante recordar esto al interpretar el recuento de archivos después de una operación vaciado.

Conclusión

Como puede ver, el diario systemd es increíblemente útil para recopilar y administrar los datos de su sistema y aplicación. Su flexibilidad proviene, en mayor parte, de los amplios metadatos registrados automáticamente y del carácter centralizado del registro. El comando journalctl hace que sea fácil aprovechar las funciones avanzadas del diario, realizar amplios análisis y depurar de forma relacional los diferentes componentes de la aplicación.

Source link

Como usar o Journalctl para visualizar e manipular registros do systemd

Introdução

Algumas das vantagens mais interessantes do systemd são aquelas envolvidas com o registro de processos e do sistema. Ao usar outros sistemas, os registros ficam geralmente dispersos, e são manuseados por daemons e processos diferentes. Isso torna a interpretação deles bastante difícil quando englobam vários aplicativos. O systemd tenta resolver esses problemas fornecendo uma solução de gerenciamento centralizada para registrar todos os processos do kernel e do userland. O sistema que coleta e gerencia esses registros é conhecido como journal (diário).

O diário é implementado com o daemon journald, que manuseia todas as mensagens produzidas pelo kernel, initrd, serviços etc. Neste guia, vamos discutir como utilizar o utilitário journalctl, que pode ser usado para acessar e manipular os dados mantidos dentro do diário.

Ideal geral

Um dos motivos da existência do diário do systemd é o de centralizar o gerenciamento de registros independentemente de onde as mensagens estão sendo originadas. Como uma grande parte do processo de inicialização do sistema e gerenciamento de serviços é manuseada pelo processo systemd, faz sentido padronizar a maneira como os registros são coletados e acessados. O daemon journald coleta dados de todas as fontes disponíveis e os armazena em um formato binário para uma manipulação fácil e dinâmica.

Isso nos dá várias vantagens significativas. Ao interagir com os dados usando um único utilitário, os administradores são capazes de exibir dinamicamente dados de registro de acordo com suas necessidades. Isso pode ser algo simples como visualizar os dados de inicialização de três inicializações de sistema atrás ou combinar as entradas de registro sequencialmente de dois serviços relacionados para consertar um problema de comunicação.

Armazenar os dados de registro em um formato binário também faz com que eles possam ser exibidos em formatos de saída arbitrários, dependendo da sua necessidade naquele momento. Por exemplo, para o gerenciamento de registros diários, você pode estar acostumado a visualizar os registros no formato syslog padrão. No entanto, se você quiser representar interrupções de serviço em gráficos mais tarde, é possível gerar um objeto JSON para cada entrada para que seja consumível pelo seu serviço de criação de gráficos. Como os dados não são escritos no disco em texto simples, nenhuma conversão é necessária quando houver a demanda por um formato diferente.

O diário do systemd pode ser usado com uma implementação do syslog existente, ou pode substituir a funcionalidade syslog, dependendo das suas necessidades. Embora o diário do systemd atenda a maioria das necessidades de registro de administrador, ele também pode complementar mecanismos de registro existentes. Por exemplo, pode ser que você tenha um servidor syslog centralizado que usa para compilar dados de vários servidores, mas também queira intercalar os registros de vários serviços em um único sistema com o diário do systemd. É possível fazer as duas coisas combinando essas tecnologias.

Configurando o horário do sistema

Um dos benefícios do uso de um diário binário para registro é a capacidade de visualizar registros em UTC ou em seu horário local à vontade. Por padrão, o systemd irá exibir resultados no horário local.

Por conta disso, antes de começarmos com o diário, vamos garantir que o fuso horário esteja configurado corretamente. O pacote do systemd vem com uma ferramenta chamada timedatectl que pode ajudar com isso.

Primeiramente, consulte quais fusos horários estão disponíveis com a opção list-timezones:

timedatectl list-timezones

Isso irá listar os fusos horários disponíveis no seu sistema. Depois de encontrar aquele que corresponde ao local do seu servidor, defina-o usando a opção set-timezone:

sudo timedatectl set-timezone zone

Para garantir que sua máquina esteja usando o horário correto neste momento, use o comando timedatectl sozinho, ou com a opção status. O resultado será o mesmo:

timedatectl status

      Local time: Thu 2015-02-05 14:08:06 EST
  Universal time: Thu 2015-02-05 19:08:06 UTC
        RTC time: Thu 2015-02-05 19:08:06
       Time zone: America/New_York (EST, -0500)
     NTP enabled: no
NTP synchronized: no
 RTC in local TZ: no
      DST active: n/a

A primeira linha deve exibir o horário correto.

Visualização básica de registros

Para ver os registros que o daemon do journald coletou, use o comando journalctl.

Quando usado sozinho, todas as entradas no diário que estão no sistema serão exibidas dentro de um pager (geralmente less (menos)) para você navegar. As entradas mais antigas estarão no topo:

journalctl

-- Logs begin at Tue 2015-02-03 21:48:52 UTC, end at Tue 2015-02-03 22:29:38 UTC. --
Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49.
Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49.
Feb 03 21:48:52 localhost.localdomain systemd-journald[139]: Received SIGTERM from PID 1 (systemd).
Feb 03 21:48:52 localhost.localdomain kernel: audit: type=1404 audit(1423000132.274:2): enforcing=1 old_en
Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
Feb 03 21:48:52 localhost.localdomain kernel: input: ImExPS/2 Generic Explorer Mouse as /devices/platform/
Feb 03 21:48:52 localhost.localdomain kernel: SELinux:  8 users, 102 roles, 4976 types, 294 bools, 1 sens,
Feb 03 21:48:52 localhost.localdomain kernel: SELinux:  83 classes, 104131 rules

. . .

É provável que você tenha páginas e páginas de dados para percorrer, que podem ser dezenas ou centenas de milhares de linhas se o systemd estiver em seu sistema há bastante tempo. Isso demonstra a quantidade de dados que está disponível no banco de dados do diário.

O formato será conhecido por aqueles que estão acostumados com o registro padrão do syslog. No entanto, este processo coleta dados de mais fontes do que as implementações tradicionais do syslog são capazes de fazer. Ele inclui registros do processo de inicialização inicial, do kernel, do initrd e do erro padrão de aplicativo e mais. Todos eles estão disponíveis no diário.

Note que todos os carimbos de data/hora estão sendo exibidos no horário local. Isso está disponível para toda entrada de registro agora que temos nosso horário local configurado corretamente em nosso sistema. Todos os registros são exibidos usando essas novas informações.

Se quiser exibir os carimbos de data/hora em UTC, use o sinalizador --utc:

journalctl --utc

Filtrar o diário pela hora

Embora ter acesso a uma grande coleção de dados seja definitivamente útil, essa grande quantidade de informações pode ser difícil ou impossível de ser inspecionada e processada mentalmente. Por conta disso, uma das características mais importantes do journalctl é suas opções de filtragem.

Exibir registros da inicialização atual

A opção mais básica existente que pode ser usada diariamente, é o sinalizador -b. Ele irá mostrar todas as entradas do diário que foram coletadas desde a reinicialização mais recente.

journalctl -b

Isso ajudará você a identificar e gerenciar informações pertinentes ao seu ambiente atual.

Nos casos em que você não estiver usando esse recurso e estiver exibindo mais de um dia de inicializações, verá que o journalctl insere uma linha que se parece com esta, sempre que o sistema foi desligado:

. . .

-- Reboot --

. . .

Isso pode ser usado para ajudar a separar as informações em sessões de inicialização de maneira lógica.

Inicializações passadas

Embora seja comum querer exibir as informações da inicialização atual, certamente existem momentos em que as inicializações passadas também podem ser úteis. O diário pode salvar informações de várias inicializações anteriores, de modo que o journalctl pode ser usado para exibir essas informações facilmente.

Algumas distribuições habilitam o salvamento de informações de inicializações anteriores por padrão, enquanto outras desativam esse recurso. Para habilitar as informações de inicialização persistentes, crie o diretório para armazenar o diário digitando:

sudo mkdir -p /var/log/journal

Ou edite o arquivo de configuração do diário:

sudo nano /etc/systemd/journald.conf

Na seção [Journal], defina a opção Storage= como “persistent” para habilitar o registro persistente:

/etc/systemd/journald.conf

. . .
[Journal]
Storage=persistent

Quando o salvamento de inicializações anteriores está habilitado no seu servidor, o journalctl fornece alguns comandos para ajudar a trabalhar com as inicializações como uma unidade de divisão. Para ver as inicializações das quais o journald tem conhecimento, use a opção --list-boots com o journalctl:

journalctl --list-boots

-2 caf0524a1d394ce0bdbcff75b94444fe Tue 2015-02-03 21:48:52 UTC—Tue 2015-02-03 22:17:00 UTC
-1 13883d180dc0420db0abcb5fa26d6198 Tue 2015-02-03 22:17:03 UTC—Tue 2015-02-03 22:19:08 UTC
 0 bed718b17a73415fade0e4e7f4bea609 Tue 2015-02-03 22:19:12 UTC—Tue 2015-02-03 23:01:01 UTC

Isso irá exibir uma linha para cada inicialização. A primeira coluna é o deslocamento da inicialização em relação à atual que pode ser usado para identificá-la com facilidade com o journalctl. Se precisar de uma referência absoluta, o ID de inicialização está na segunda coluna. É possível identificar o tempo da sessão com as duas especificações de data/hora no final da linha.

Para exibir informações dessas inicializações, use as informações da primeira ou segunda coluna.

Por exemplo, para ver o diário da inicialização anterior, use o ponteiro relativo -1 com o sinalizador -b:

journalctl -b -1

Também é possível usar o ID de inicialização para retornar os dados de uma inicialização específica:

journalctl -b caf0524a1d394ce0bdbcff75b94444fe

Intervalos de tempo

Embora a visualização de entradas de registro com base na inicialização seja incrivelmente útil, muitas vezes é desejável solicitar intervalos de tempo que não se alinham com as inicializações do sistema. Isso pode ser especialmente válido ao lidar com servidores de execução prolongada com um tempo de atividade significativo.

É possível filtrar por limites arbitrários de data/hora usando as opções --since e --until, que restringem as entradas exibidas a aquelas que sucedem ou antecedem um determinado tempo, respectivamente.

Os valores de data/hora podem ser usados em uma variedade de formatos. Para valores de data/hora absolutos, use o seguinte formato:

YYYY-MM-DD HH:MM:SS

Por exemplo, podemos ver todas as entradas desde 10 de janeiro de 2015 às 5:15 PM digitando:

journalctl --since "2015-01-10 17:15:00"

Se algum componente do formato acima for deixado de fora, o padrão será aplicado. Por exemplo, se a data for omitida, a data atual será empregada. Se o componente de hora estiver faltando, “00:00:00” (meia-noite) será utilizado. O campo de segundos também pode ser deixado de fora e o padrão “00” é empregado:

journalctl --since "2015-01-10" --until "2015-01-11 03:00"

O diário também compreende alguns valores relativos e seus atalhos nomeados. Por exemplo, é possível usar as palavras “yesterday” (ontem), “today” (hoje), “tomorrow” (amanhã) ou “now” (agora). É possível criar datas/horas relativas prefixando “-” ou “+” a um valor numerado ou usando palavras como “ago” (atrás) em uma construção de sentenças.

Para obter os dados de ontem, pode-se digitar:

journalctl --since yesterday

Se tiver recebido relatórios de uma interrupção de serviço iniciada às 9:00 AM que durou até uma hora atrás, você pode digitar:

journalctl --since 09:00 --until "1 hour ago"

Como se vê, é relativamente fácil definir intervalos flexíveis de tempo para filtrar as entradas que você deseja visualizar.

Filtrar por interesse de mensagens

Aprendemos acima algumas maneiras de filtrar os dados do diário usando restrições de tempo. Nesta seção, vamos discutir como filtrar com base em qual serviço ou componente você está interessado. O diário do systemd oferece diversas maneiras de fazer isso.

Por unidade

Talvez a maneira mais útil de filtrar seja pela unidade na qual você está interessado. Podemos usar a opção -u para filtrar dessa maneira.

Por exemplo, para ver todos os registros de uma unidade Nginx em nosso sistema, digitamos:

journalctl -u nginx.service

Normalmente, também seria interessante filtrar pela data/hora para exibir as linhas nas quais você está interessado. Por exemplo, para verificar como o serviço está funcionando hoje, digite:

journalctl -u nginx.service --since today

Esse tipo de foco torna-se extremamente útil quando se aproveita da capacidade do diário de intercalar os registros de várias unidades. Por exemplo, se seu processo Nginx estiver conectado a uma unidade PHP-FPM para processar conteúdo dinâmico, é possível fundir as entradas de ambos em ordem cronológica especificando ambas as unidades:

journalctl -u nginx.service -u php-fpm.service --since today

Isso pode facilitar a detecção de interações entre diferentes programas e sistemas de depuração, em vez de processos individuais.

Por processo, usuário ou ID de grupo

Alguns serviços geram uma variedade de processos filhos para funcionar. Se você tiver pesquisado o PID exato do processo em que está interessado, também é possível filtrar por ele.

Para fazer isso, especificamos o campo _PID. Por exemplo, se o PID em que estivermos interessados for 8088, digitamos:

journalctl _PID=8088

Em outros momentos, pode ser desejável exibir todas as entradas registradas a partir de um usuário ou grupo específico. Isso pode ser feito com os filtros _UID ou _GID. Por exemplo, se seu servidor Web estiver sendo executado sob o usuário www-data, é possível encontrar o ID do usuário digitando:

id -u www-data

Depois disso, use o ID retornado para filtrar os resultados do diário:

journalctl _UID=33 --since today

O diário do systemd possui muitos campos que podem ser usados para a filtragem. Alguns deles são passados do processo que está sendo registrado e alguns são aplicados pelo journald usando informações que ele coleta do sistema no momento do registro.

O sublinhado inicial indica que o campo _PID pertence ao segundo tipo. O diário registra e classifica automaticamente o PID do processo que está sendo registrado para a filtragem posterior. É possível descobrir todos os campos de diário disponíveis digitando:

man systemd.journal-fields

Vamos discutir alguns deles neste guia. Por enquanto, vamos analisar mais uma opção útil relacionada com a filtragem por esses campos. A opção -F pode ser usada para mostrar todos os valores disponíveis para um campo de diário específico.

Por exemplo, para ver quais entradas para IDs de grupo o diário do systemd possui, digite:

journalctl -F _GID

Isso irá mostrar todos os valores que o diário armazenou para o campo ID de grupo. Isso pode ajudar a construir seus filtros.

Por caminho de componente

Também podemos filtrar fornecendo um caminho de pesquisa.

Se o caminho levar a um executável, o journalctl irá exibir todas as entradas relacionadas ao executável em questão. Por exemplo, para encontrar essas entradas que estão relacionadas ao executável bash, digite:

journalctl /usr/bin/bash

Normalmente, se uma unidade estiver disponível para o executável, esse método é mais organizado e fornece informações mais completas (entradas de processos filhos associados, etc). Às vezes, no entanto, isso não é possível.

Exibir mensagens de kernel

As mensagens de kernel, que são aquelas geralmente encontradas na saída do dmesg, também podem ser recuperadas do diário.

Para exibir apenas essas mensagens, podemos adicionar os sinalizadores -k ou --dmesg ao nosso comando:

journalctl -k

Por padrão, isso irá exibir as mensagens do kernel da inicialização atual. É possível especificar uma outra inicialização usando os sinalizadores de seleção de inicialização discutidos anteriormente. Por exemplo, para obter as mensagens de cinco inicializações atrás, digite:

journalctl -k -b -5

Por prioridade

Um filtro no qual os administradores de sistema estão geralmente interessados é a prioridade de mensagem. Embora seja muitas vezes útil registrar informações em um nível bastante detalhado, ao resumir as informações disponíveis, o registro de baixa prioridade pode ser confuso.

É possível usar o journalctl para exibir apenas mensagens de uma prioridade especificada ou superior usando a opção -p. Isso permite filtrar mensagens com níveis de prioridade inferiores.

Por exemplo, para mostrar apenas entradas registradas no nível de erro ou acima, digite:

journalctl -p err -b

Isso irá exibir todas as mensagens marcadas como erro, crítico, alerta ou emergência. O diário implementa os níveis de mensagem padrão do syslog. É possível usar o nome da prioridade ou seu valor numérico correspondente. As prioridades, ordenadas da maior para a menor, são:

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

Os números ou nomes acima podem ser usados de maneira intercambiável com a -p opção. A seleção de uma prioridade irá exibir mensagens marcadas no nível especificado e acima.

Modificar a exibição do diário

Acima, demonstramos a seleção de entradas através da filtragem. No entanto, existem outras maneiras com as quais podemos modificar o resultado. Podemos ajustar a exibição do journalctl para atender diversas necessidades.

Truncar ou expandir o resultado

Podemos ajustar como o journalctl exibe os dados, dizendo-lhe para reduzir ou expandir o resultado.

Por padrão, o journalctl irá mostrar a entrada inteira no pager, permitindo que as entradas se expandam à direita da tela. Essa informação pode ser acessada pressionando a tecla de seta para a direita.

Se preferir o resultado truncado, inserindo reticências onde as informações foram removidas, use a opção --no-full:

journalctl --no-full

. . .

Feb 04 20:54:13 journalme sshd[937]: Failed password for root from 83.234.207.60...h2
Feb 04 20:54:13 journalme sshd[937]: Connection closed by 83.234.207.60 [preauth]
Feb 04 20:54:13 journalme sshd[937]: PAM 2 more authentication failures; logname...ot

Também é possível ir na direção oposta e dizer ao journalctl para exibir todas as suas informações, mesmo se forem incluídos caracteres não imprimíveis. Podemos fazer isso com o sinalizador -a:

journalctl -a

Resultados em formato padrão

Por padrão, o journalctl exibe o resultado em um pager para um consumo mais simples. No entanto, se você estiver planejando processar os dados com ferramentas de manipulação de texto, irá querer ser capaz de gerar resultados no formato padrão.

Faça isso com a opção --no-pager:

journalctl --no-pager

Isso pode ser canalizado imediatamente em um utilitário de processamento ou redirecionado para um arquivo no disco, dependendo das suas necessidades.

Formatos de saída

Se você estiver processando entradas de diário, como mencionado acima, provavelmente será mais fácil analisar os dados se eles estiverem em um formato mais consumível. Felizmente, o diário pode ser exibido em uma variedade de formatos conforme a necessidade. Faça isso usando a opção -o com um especificador de formato.

Por exemplo, gere um arquivo JSON a partir de entradas no diário digitando:

journalctl -b -u nginx -o json

{ "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635", "__REALTIME_TIMESTAMP" : "1422990364739502", "__MONOTONIC_TIMESTAMP" : "27200938", "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d", "PRIORITY" : "6", "_UID" : "0", "_GID" : "0", "_CAP_EFFECTIVE" : "3fffffffff", "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee", "_HOSTNAME" : "desktop", "SYSLOG_FACILITY" : "3", "CODE_FILE" : "src/core/unit.c", "CODE_LINE" : "1402", "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading", "SYSLOG_IDENTIFIER" : "systemd", "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5", "_TRANSPORT" : "journal", "_PID" : "1", "_COMM" : "systemd", "_EXE" : "/usr/lib/systemd/systemd", "_CMDLINE" : "/usr/lib/systemd/systemd", "_SYSTEMD_CGROUP" : "/", "UNIT" : "nginx.service", "MESSAGE" : "Starting A high performance web server and a reverse proxy server...", "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973" }

. . .

Isso é útil para análise com utilitários. Você poderia usar o formato json-pretty para ter uma melhor ideia melhor da estrutura de dados antes de passá-lo para o consumidor de JSON:

journalctl -b -u nginx -o json-pretty

{
    "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635",
    "__REALTIME_TIMESTAMP" : "1422990364739502",
    "__MONOTONIC_TIMESTAMP" : "27200938",
    "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d",
    "PRIORITY" : "6",
    "_UID" : "0",
    "_GID" : "0",
    "_CAP_EFFECTIVE" : "3fffffffff",
    "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee",
    "_HOSTNAME" : "desktop",
    "SYSLOG_FACILITY" : "3",
    "CODE_FILE" : "src/core/unit.c",
    "CODE_LINE" : "1402",
    "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading",
    "SYSLOG_IDENTIFIER" : "systemd",
    "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5",
    "_TRANSPORT" : "journal",
    "_PID" : "1",
    "_COMM" : "systemd",
    "_EXE" : "/usr/lib/systemd/systemd",
    "_CMDLINE" : "/usr/lib/systemd/systemd",
    "_SYSTEMD_CGROUP" : "/",
    "UNIT" : "nginx.service",
    "MESSAGE" : "Starting A high performance web server and a reverse proxy server...",
    "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973"
}

. . .

Os formatos a seguir podem ser usados para exibição:

cat: exibe apenas o campo de mensagem em si.
export: um formato binário adequado para transferir e fazer um backup.
json: JSON padrão com uma entrada por linha.
json-pretty: JSON formatado para uma melhor legibilidade humana
json-sse: saída formatada em JSON agrupada para tornar um evento enviado ao servidor compatível
short: o estilo de saída padrão do syslog
short-iso: o formato padrão aumentado para mostrar as carimbos de data/hora da ISO 8601.
short-monotonic: o formato padrão com carimbos de data/hora monotônicos.
short-precise: o formato padrão com precisão de microssegundos
verbose: exibe todas os campos de diário disponíveis para a entrada, incluindo aqueles que geralmente estão escondidos internamente.

Essas opções permitem exibir as entradas do diário no formato que melhor atende às suas necessidades atuais.

Monitoramento de processo ativo

O comando journalctl imita a forma como muitos administradores usam tail para monitorar atividades ativas ou recentes. Essa funcionalidade está embutida no journalctl, permitindo acessar esses recursos sem precisar utilizar uma outra ferramenta.

Exibir registros recentes

Para exibir uma quantidade definida de registros, use a opção -n, que funciona exatamente como tail -n.

Por padrão, ele irá exibir as 10 entradas mais recentes:

journalctl -n

Especifique o número de entradas que quer ver com um número após o -n:

journalctl -n 20

Acompanhar registros

Para acompanhar ativamente os registros à medida que são escritos, use o sinalizador -f. Novamente, isso funciona como o esperado, caso você tenha experiência usando o tail -f:

journalctl -f

Manutenção do diário

Você deve estar se perguntando sobre o custo do armazenamento de todos os dados que vimos até agora. Além disso, você pode estar interessado em limpar alguns registros mais antigos e liberar o espaço.

Descobrir o uso atual em disco

É possível descobrir a quantidade de espaço que diário está ocupando no disco usando o sinalizador --disk-usage:

journalctl --disk-usage

Journals take up 8.0M on disk.

Deletar registros antigos

Se quiser reduzir o tamanho do seu diário, você pode fazer isso de duas maneiras diferentes (disponível com a versão 218 do systemd ou superior).

Usando a opção --vacuum-size, você pode reduzir o tamanho do diário indicando um tamanho. Isso irá remover entradas antigas até o espaço total que o diário ocupa em disco esteja no tamanho solicitado:

sudo journalctl --vacuum-size=1G

Outra maneira para reduzir o tamanho do diário é fornecendo um tempo de corte com a opção --vacuum-time. Todas as entradas além daquele momento são excluídas. Isso permite manter as entradas que foram criadas após um tempo específico.

Por exemplo, para manter as entradas do último ano, digite:

sudo journalctl --vacuum-time=1years

Limitar a expansão do diário

É possível configurar seu servidor para colocar limites sobre a quantidade de espaço que diário pode ocupar. Isso pode ser feito editando o arquivo /etc/systemd/journald.conf.

Os itens a seguir podem ser usados para limitar o crescimento do diário:

SystemMaxUse=: especifica o espaço máximo em disco que pode ser usado pelo diário em armazenamento persistente.
SystemKeepFree=: especifica a quantidade de espaço que o diário deve deixar livre no armazenamento persistente ao adicionar entradas.
SystemMaxFileSize=: controla o tamanho máximo até o qual os arquivos de diário individuais podem crescer em armazenamento persistente antes de serem girados.
RuntimeMaxUse=: especifica o espaço máximo em disco que pode ser usado como armazenamento volátil (dentro do sistema de arquivos /run).
RuntimeKeepFree=: especifica a quantidade de espaço a ser reservada para outros usos ao escrever dados no armazenamento volátil (dentro do sistema de arquivos /run).
RuntimeMaxFileSize=: especifica a quantidade de espaço que um arquivo de diário individual pode ocupar em armazenamento volátil (dentro do sistema de arquivos /run) antes de ser girado.

Ao definir esses valores, você pode controlar como o journald consome e preserva o espaço no seu servidor. Tenha em mente que o SystemMaxFileSize e o RuntimeMaxFileSize irão mirar em arquivos arquivados para alcançar os limites declarados. Isso é importante de lembrar ao interpretar contagens de arquivos após uma operação de limpeza.

Conclusão

Como foi visto, o diário do systemd é incrivelmente útil para coletar e gerenciar seus dados de sistema e de aplicativo. A maior parte da sua flexibilidade vem da grande quantidade de metadados que são registrados automaticamente e da natureza centralizada do registro. O comando journalctl torna mais fácil aproveitar as funcionalidades avançadas do diário e fazer análises extensas e depuração relacional de diferentes componentes de aplicativos.

Source link

Shared

Cloud VPS

Dedicated

systemd

Comment utiliser Journalctl pour consulter et manipuler les journaux Systemd

Introduction

Concept général

Configurer l’heure du système

Visualisation du journal de base

Filtrage des journaux par heure

Affichage des journaux du démarrage en cours

Démarrages précédents

Fenêtres d’heures

Filtrer par intérêt des messages

Par unité

Par processus, utilisateur ou ID de groupe

Par chemin de composants

Afficher les messages du noyau

Par priorité

Modification de l’affichage du journal

Tronquer ou étendre le résultat

Sortie sur Standard

Formats de sortie

Surveillance active des processus

Affichage des journaux récents

Suivi des journaux

Maintenance des journaux

Trouver l’utilisation actuelle du disque

Suppression des anciens journaux

Limitation de l’expansion du journal

Conclusion

Cómo usar Journalctl para ver y manipular los registros de Systemd

Introducción

Idea general

Configurar la hora del sistema

Visualización básica de registros

Filtrado del diario por hora

Mostrar los registros del arranque actual

Arranques anteriores

Ventanas de tiempo

Filtrado por interés de mensaje

Por unidad

Por proceso, usuario o ID de grupo

Por ruta de componente

Mostrar mensajes de kernel

Por prioridad

Modificar la pantalla del diario

Truncar o ampliar el resultado

Resultado a la salida estándar

Formatos de resultado

Supervisión activa de procesos

Cómo mostrar los registros recientes

Cómo hacer un seguimiento de los registros

Mantenimiento del diario

Cómo encontrar el uso actual de disco

Cómo eliminar registros antiguos

Cómo limitar la expansión del diario

Conclusión

Como usar o Journalctl para visualizar e manipular registros do systemd

Introdução

Ideal geral

Configurando o horário do sistema

Visualização básica de registros

Filtrar o diário pela hora

Exibir registros da inicialização atual

Inicializações passadas

Intervalos de tempo

Filtrar por interesse de mensagens

Por unidade

Por processo, usuário ou ID de grupo

Por caminho de componente

Exibir mensagens de kernel

Por prioridade

Modificar a exibição do diário

Truncar ou expandir o resultado

Resultados em formato padrão

Formatos de saída

Monitoramento de processo ativo

Exibir registros recentes

Acompanhar registros