One place for hosting & domains

      journalctl

      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
      
      33
      

      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
      
      32
      99
      102
      133
      81
      84
      100
      0
      124
      87
      

      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

      Verwenden von Journalctl zum Anzeigen und Manipulieren von Systemd-Protokollen


      Einführung

      Einige der überzeugendsten Vorteile von systemd sind diejenigen, die mit der Prozess- und Systemprotokollierung verbunden sind. Bei der Verwendung anderer Tools werden Protokolle normalerweise im gesamten System verteilt, von verschiedenen Daemons und Prozessen bearbeitet und können ziemlich schwer zu interpretieren, wenn sie sich über mehrere Anwendungen erstrecken. Systemd versucht, diese Probleme zu lösen, indem es eine zentralisierte Verwaltungslösung zur Protokollierung aller Kernel- und Userland-Prozesse bereitstellt. Das System, das diese Protokolle sammelt und verwaltet, wird als Journal bezeichnet.

      Das Journal wird mit dem Daemon journald implementiert, der alle vom Kernel, initrd, services etc. erzeugten Nachrichten verarbeitet. In diesem Leitfaden besprechen wir die Verwendung des Dienstprogramms journalctl, mit dem Sie auf die in dem Journal gespeicherten Daten zugreifen und diese manipulieren können.

      Allgemeiner Gedanke

      Eine der Triebfedern hinter dem Journal systemd ist die Zentralisierung der Verwaltung von Protokollen, unabhängig davon, woher die Nachrichten stammen. Da ein Großteil des Boot-Prozesses und der Verwaltung von Diensten durch den Prozess systemd abgewickelt wird, ist es sinnvoll, die Art und Weise, wie Protokolle gesammelt und darauf zugegriffen wird, zu standardisieren. Der Daemon journald sammelt Daten aus allen verfügbaren Quellen und speichert sie in einem Binärformat für einfache und dynamische Manipulation.

      Dies bringt eine Reihe von bedeutenden Vorteilen mit sich. Durch die Interaktion mit den Daten über ein einziges Dienstprogramm sind Administratoren in der Lage, Protokolldaten dynamisch nach ihren Bedürfnissen anzuzeigen. Dies kann so einfach sein, wie das Anzeigen der Boot-Daten von vor drei Boot-Vorgängen oder das Kombinieren der Protokolleinträge von zwei verwandten Diensten nacheinander, um ein Kommunikationsproblem zu beheben.

      Das Speichern der Protokolldaten in einem Binärformat bedeutet auch, dass die Daten in beliebigen Ausgabeformaten angezeigt werden können, je nachdem, was Sie gerade benötigen. Für die tägliche Protokollverwaltung sind Sie eventuell daran gewöhnt, die Protokolle im Standard-Format syslog anzuzeigen, aber wenn Sie sich später entscheiden, Dienstunterbrechungen grafisch darzustellen, können Sie jeden Eintrag als JSON-Objekt ausgeben, um ihn für Ihren grafischen Dienst konsumierbar zu machen. Da die Daten nicht im Klartext auf die Festplatte geschrieben werden, ist keine Konvertierung erforderlich, wenn Sie ein anderes On-Demand-Format benötigen.

      Das Journal systemd kann entweder mit einer vorhandenen syslog-Implementierung verwendet werden oder es kann die Funktionalität syslog ersetzen, je nach Ihren Bedürfnissen. Während das Journal systemd die meisten Protokollierungsanforderungen von Administratoren abdeckt, kann es auch bestehende Protokollierungsmechanismen ergänzen. Sie haben vielleicht einen zentralisierten syslog-Server, den Sie verwenden, um Daten von mehreren Servern zu kompilieren, aber Sie möchten die Protokolle auch von mehreren Diensten auf einem einzigen System mit dem Journal systemd zusammenführen. Sie können beides tun, indem Sie diese Technologien kombinieren.

      Einstellen der Systemzeit

      Einer der Vorteile der Verwendung eines binären Journals für die Protokollierung ist die Fähigkeit, Protokolldatensätze in UTC oder lokaler Zeit anzuzeigen. Standardmäßig zeigt systemd Ergebnisse in der lokalen Zeit an.

      Aus diesem Grund stellen wir, bevor wir mit dem Journal beginnen, sicher, dass die Zeitzone korrekt eingestellt ist. Die Suite systemd verfügt über ein Tool namens timedatectl, das dabei helfen kann.

      Sehen Sie zuerst nach, welche Zeitzonen mit der Option list-timezones verfügbar sind:

      timedatectl list-timezones
      

      Dadurch werden die auf Ihrem System verfügbaren Zeitzonen aufgelistet. Wenn Sie diejenige gefunden haben, die dem Standort Ihres Servers entspricht, können Sie sie mit der Option set-timezone einstellen:

      sudo timedatectl set-timezone zone
      

      Um sicherzustellen, dass Ihr Rechner jetzt die richtige Zeit verwendet, verwenden Sie den Befehl timedatectl allein oder mit der Option status. Die Anzeige wird die gleiche sein:

      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
      

      In der ersten Zeile sollte die korrekte Zeit angezeigt werden.

      Grundlegendes Anzeigen von Protokollen

      Um die Protokolle zu sehen, die der Daemon journald gesammelt hat, verwenden Sie den Befehl journalctl.

      Bei alleiniger Verwendung wird jeder im System vorhandene Journaleintrag innerhalb eines Pager (normalerweise less) angezeigt, damit Sie durchsuchen können. Die ältesten Einträge werden oben angezeigt:

      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
      
      . . .
      

      Sie werden wahrscheinlich seitenweise Daten durchblättern müssen, die zehn- oder hunderttausende Zeilen lang sein können, wenn sich systemd schon lange auf Ihrem System befindet. Dies demonstriert, wie viele Daten in der Journal-Datenbank vorhanden sind.

      Das Format wird denjenigen vertraut sein, die an die Standard-Protokollierung syslog gewöhnt sind. Allerdings werden hier tatsächlich Daten aus mehr Quellen gesammelt als traditionelle syslog-Implementierungen in der Lage sind. Es beinhaltet Protokolle des frühen Boot-Prozesses, des Kernel, der initrd und der Anwendungsstandardfehler und -ausgänge. Diese sind alle im Journal verfügbar.

      Vielleicht fällt Ihnen auf, dass alle angezeigten Zeitstempel in lokaler Zeit sind. Dies ist für jeden Protokolleintrag verfügbar, da die lokale Zeit auf unserem System korrekt eingestellt ist. Alle Protokolle werden mit dieser neuen Information angezeigt.

      Wenn Sie die Zeitstempel in UTC anzeigen möchten, können Sie das Flag --utc verwenden:

      journalctl --utc
      

      Journal-Filterung nach Zeit

      Obwohl der Zugriff auf eine so große Datensammlung durchaus nützlich ist, kann es schwierig oder unmöglich sein, eine so große Menge mental zu untersuchen und zu verarbeiten. Aus diesem Grund ist eine der wichtigsten Funktionen von journalctl seine Filteroptionen.

      Anzeigen von Protokollen aus dem aktuellen Boot

      Die grundlegendste dieser Optionen, die Sie möglicherweise täglich verwenden, ist das Flag -b. Damit werden Ihnen alle Journaleinträge angezeigt, die seit dem neuesten Neustart gesammelt wurden.

      journalctl -b
      

      Dies hilft Ihnen, Informationen zu identifizieren und zu verwalten, die für Ihre aktuelle Umgebung relevant sind.

      In Fällen, in denen Sie diese Funktion nicht verwenden und mehr als einen Tag von Bootvorgängen anzeigen, werden Sie sehen, dass journalctl eine Zeile eingefügt hat, die so aussieht, wann immer das System heruntergefahren wurde:

      . . .
      
      -- Reboot --
      
      . . .
      

      Dies kann verwendet werden, um Ihnen dabei zu helfen, die Informationen logisch in Boot-Sitzungen aufzuteilen.

      Vergangene Bootvorgänge

      Während Sie in der Regel die Informationen aus dem aktuellen Bootvorgang anzeigen möchten, gibt es sicherlich Zeiten, in denen auch vergangene Bootvorgänge hilfreich sind. Das Journal kann Informationen von vielen vorherigen Bootvorgängen speichern, sodass journalctl eingestellt werden kann, um Informationen einfacher anzuzeigen.

      Bei einigen Distributionen ist das Speichern von Informationen zu früheren Bootvorgängen standardmäßig aktiviert, bei anderen ist diese Funktion deaktiviert. Um persistente Boot-Informationen zu aktivieren, können Sie entweder das Verzeichnis zum Speichern des Journals erstellen, indem Sie Folgendes eingeben:

      • sudo mkdir -p /var/log/journal

      Oder Sie können die Journal-Konfigurationsdatei bearbeiten:

      • sudo nano /etc/systemd/journald.conf

      Setzen Sie unter dem Abschnitt [Journal] die Option Storage= auf „persistent“, um die persistente Protokollierung zu aktivieren:

      /etc/systemd/journald.conf

      . . .
      [Journal]
      Storage=persistent
      

      Wenn das Speichern von vorherigen Bootvorgängen auf Ihrem Server aktiviert ist, stellt journalctl einige Befehle bereit, um Ihnen die Arbeit mit Bootvorgängen als Einheit der Division zu erleichtern. Um die Bootvorgänge zu sehen, von denen journald weiß, verwenden Sie die Option --list-boots mit 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
      

      Dies zeigt eine Zeile für jeden Bootvorgang an. Die erste Spalte ist der Offset für den Bootvorgang, der verwendet werden kann, um den Bootvorgang mit journalctl einfach zu referenzieren. Wenn Sie eine absolute Referenz benötigen, steht die Boot-ID in der zweiten Spalte. Die Zeit, auf die sich die Boot-Sitzung bezieht, erkennen Sie an den beiden Zeitangaben, die am Ende aufgeführt sind.

      Um Informationen von diesen Bootvorgängen anzuzeigen, können Sie entweder Informationen aus der ersten oder zweiten Spalte verwenden.

      Um beispielsweise das Journal von dem vorherigen Boot zu sehen, verwenden Sie den relativen Zeiger -1 mit dem Flag -b:

      journalctl -b -1
      

      Zum Abrufen von Daten aus einem Boot können Sie auch die Boot-ID verwenden:

      journalctl -b caf0524a1d394ce0bdbcff75b94444fe
      

      Zeitfenster

      Während es unglaublich nützlich ist, Protokolleinträge nach Bootvorgang zu sehen, möchten Sie vielleicht oft Zeitfenster abfragen, die nicht gut mit Systemstarts übereinstimmen. Dies kann besonders bei lang laufenden Servern mit erheblicher Betriebszeit der Fall sein.

      Sie können nach beliebigen Zeitgrenzen filtern, indem Sie die Optionen --since und --until verwenden, die die angezeigten Einträge auf diejenigen nach bzw. vor der angegebenen Zeit einschränken.

      Die Zeitwerte können in einer Vielzahl von Formaten vorliegen. Für absolute Zeitwerte sollten Sie das folgende Format verwenden:

      YYYY-MM-DD HH:MM:SS
      

      Beispielsweise können wir alle Einträge seit dem 10. Januar 2015 um 17:15 Uhr sehen, indem wir eingeben:

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

      Wenn Komponenten des obigen Formats weggelassen werden, werden einige Standardwerte angewendet. Wenn beispielsweise das Datum weggelassen wird, wird das aktuelle Datum angenommen. Wenn die Zeitkomponente fehlt, wird „00:00:00“ (Mitternacht) ersetzt. Das Sekundenfeld kann auch weggelassen werden, sodass standardmäßig „00“ verwendet wir:

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

      Das Journal versteht auch einige relative Werte und benannte Abkürzungen. Beispielsweise können Sie die Wörter „gestern“, „heute“, „morgen“ oder „jetzt“ verwenden. Relative Zeiten geben Sie an, indem Sie einem nummerierten Wert ein „-“ oder „+“ voranstellen oder Wörter wie „vor“ in einem Satzbau verwenden.

      Um die Daten von gestern zu erhalten, könnten Sie eingeben:

      journalctl --since yesterday
      

      Wenn Sie Berichte über eine Dienstunterbrechung erhalten haben, die um 9:00 Uhr begann und bis vor einer Stunde andauerte, könnten Sie eingeben:

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

      Wie Sie sehen können, ist es relativ einfach, flexible Zeitfenster zu definieren, um die Einträge zu filtern, die Sie sehen möchten.

      Filtern nach Nachrichteninteresse

      Wir haben vorstehend einige Möglichkeiten kennengelernt, wie Sie die Journaldaten anhand von Zeiteinschränkungen filtern können. In diesem Abschnitt werden wir besprechen, wie Sie basierend auf dem Dienst oder der Komponente filtern können, an der Sie interessiert sind. Das Journal systemd bietet eine Vielzahl von Möglichkeiten, dies zu tun.

      Nach Einheit

      Die vielleicht nützlichste Art der Filterung ist nach der Einheit, an der Sie interessiert sind. Wir können die Option -u verwenden, um auf diese Weise zu filtern.

      Um beispielsweise alle Protokolle einer Nginx-Einheit auf unserem System zu sehen, können wir eingeben:

      journalctl -u nginx.service
      

      Normalerweise würden Sie wahrscheinlich auch nach der Zeit filtern wollen, um die Zeilen anzuzeigen, an denen Sie interessiert sind. Um beispielsweise zu überprüfen, wie der Dienst heute ausgeführt wird, können Sie eingeben:

      journalctl -u nginx.service --since today
      

      Diese Art der Fokussierung wird extrem hilfreich, wenn Sie die Fähigkeit des Journals nutzen, Datensätze aus verschiedenen Einheiten zusammenzuführen. Wenn Ihr Nginx-Prozess beispielsweise mit einer PHP-FPM-Einheit verbunden ist, um dynamischen Inhalt zu verarbeiten, können Sie die Einträge von beiden in chronologischer Reihenfolge zusammenführen, indem Sie beide Einheiten angeben:

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

      Dies kann es wesentlich einfacher machen, die Interaktionen zwischen verschiedenen zu erkennen und System zu debuggen, anstatt einzelne Prozesse.

      Nach Prozess, Benutzer oder Gruppen-ID

      Einige Dienste spawnen eine Vielzahl von untergeordneten Prozesse, um die Arbeit zu erledigen. Wenn Sie die genaue PID des Prozesses, an dem Sie interessiert sind, ausgekundschaftet haben, können Sie auch nach dieser filtern.

      Dazu können wir durch Angabe des Feldes _PID filtern. Wenn die PID, an der wir interessiert sind, beispielsweise 8088 ist, könnten wir eingeben:

      journalctl _PID=8088
      

      Zu anderen Zeiten möchten Sie möglicherweise alle Einträge anzeigen, die von einem bestimmten Benutzer oder einer Gruppe protokolliert wurden. Dies kann mit den Filtern _UID oder _GID geschehen. Wenn Ihr Webserver beispielsweise unter dem Benutzer www-data läuft, können Sie die Benutzer-ID finden, indem Sie eingeben:

      id -u www-data
      
      33
      

      Anschließend können Sie die zurückgegebene ID verwenden, um die Journalergebnisse zu filtern:

      journalctl _UID=33 --since today
      

      Das Journal systemd hat viele Felder, die für die Filterung verwendet werden können. Einige davon werden von dem zu protokollierenden Prozess übergeben und einige werden von journald anhand von Informationen angewendet, die es zum Zeitpunkt der Protokollierung aus dem System sammelt.

      Der führende Unterstrich gibt an, dass das Feld _PID von dem letzteren Typ ist. Das Journal zeichnet automatisch die PID des protokollierenden Prozesses auf und indexiert sie für spätere Filterungen. Sie können sich über alle verfügbaren Journalfelder informieren, indem Sie eingeben:

      man systemd.journal-fields
      

      Wir werden einige davon in diesem Leitfaden besprechen. Für den Moment werden wir jedoch eine weitere nützliche Option bespreche, die mit der Filterung nach diesen Feldern zu tun hat. Die Option -F kann verwendet werden, um alle verfügbaren Werte für ein bestimmtes Journalfeld anzuzeigen.

      Um beispielsweise zu sehen, für welche Gruppen-IDs das Journal systemd Einträge aufweist, können Sie eingeben:

      journalctl -F _GID
      
      32
      99
      102
      133
      81
      84
      100
      0
      124
      87
      

      Dies zeigt Ihnen alle Werte, die das Journal für das Feld Gruppen-ID gespeichert hat. Dies kann Ihnen beim Erstellen Ihrer Filter helfen.

      Nach Komponentenpfad

      Wir können auch filtern, indem wir eine Pfadposition bereitstellen.

      Wenn der Pfad zu einer ausführbaren Datei führt, zeigt journalctl alle Einträge an, die die betreffende ausführbare Datei betreffen. Um beispielsweise die Einträge zu finden, die die ausführbare Datei bash betreffen, können Sie eingeben:

      journalctl /usr/bin/bash
      

      Wenn eine Einheit für die ausführbare Datei verfügbar ist, ist diese Methode sauberer und bietet bessere Informationen (Einträge aus zugehörigen untergeordneten Prozessen usw.). Manchmal ist dies jedoch nicht möglich.

      Anzeigen von Kernel-Meldungen

      Kernel-Meldungen, die normalerweise in der Ausgabe dmesg zu finden sind, können ebenfalls aus dem Journal abgerufen werden.

      Um nur diese Meldungen anzuzeigen, können wir die Flags -k oder --dmesg zu unserem Befehl hinzufügen:

      journalctl -k
      

      Standardmäßig werden damit die Kernel-Meldungen des aktuellen Bootvorgangs angezeigt. Sie können einen alternativen Bootvorgang angeben, indem Sie die zuvor besprochenen Boot-Auswahl-Flags verwenden. Um beispielsweise die Meldungen von vor fünf Bootvorgängen zu erhalten, könnten Sie eingeben:

      journalctl -k -b -5
      

      Nach Priorität

      Ein Filter, an dem Systemadministratoren oft interessiert sind, ist die Meldungspriorität. Während es oft nützlich ist, Informationen auf einem sehr ausführlichen Niveau zu protokollieren, können Protokolle mit niedriger Priorität beim tatsächlichen Verarbeiten der verfügbaren Informationen ablenken und verwirrend sein.

      Sie können journalctl verwenden, um nur Meldungen einer bestimmten Priorität oder höher anzuzeigen, indem Sie die Option -p verwenden. Dadurch können Sie Meldungen mit niedrigerer Priorität herausfiltern.

      Um beispielsweise nur Einträge anzuzeigen, die auf der Fehlerebene oder höher protokolliert wurden, können Sie eingeben:

      journalctl -p err -b
      

      Dies zeigt Ihnen alle Meldungen an, die als Fehler, kritisch, Alarm oder Notfall gekennzeichnet sind. Das Journal implementiert die Standard-syslog-Meldungsebenen. Sie können entweder den Namen der Priorität oder den entsprechenden numerischen Wert verwenden. In der Reihenfolge von höchster bis niedrigster Priorität sind dies:

      • 0: emerg (Notfall)
      • 1: alert (Alarm)
      • 2: crit (kritisch)
      • 3: err (Fehler)
      • 4: warning (Warnung)
      • 5: notice (Hinweis)
      • 6: info (Information)
      • 7: debug (Fehlersuche)

      Die vorstehenden Zahlen oder Namen können austauschbar mit der Option -p verwendet werden. Wenn Sie die Priorität auswählen, werden Meldungen angezeigt, die auf der angegebenen Ebene markiert sind, und solche, die darüber liegen.

      Ändern der Journalanzeige

      Vorstehend haben wir die Auswahl von Einträgen durch Filterung demonstriert. Es gibt jedoch noch andere Möglichkeiten, die Ausgabe zu ändern. Wir können die Anzeige journalctl an verschiedene Bedürfnisse anpassen.

      Kürzen oder Erweitern der Ausgabe

      Wir können anpassen, wie journalctl Daten anzeigt, indem wir ihn anweisen, die Ausgabe zu verkürzen oder zu erweitern.

      Standardmäßig zeigt journalctl den gesamten Eintrag in dem Pager an und lässt die Einträge rechts am Bildschirm auslaufen. Auf diese Informationen können Sie durch Drücken der rechten Pfeiltaste zugreifen.

      Wenn Sie die Ausgabe lieber gekürzt haben möchten, wobei an den Stellen, an denen Informationen entfernt wurden, eine Ellipse eingefügt wird, können Sie die Option --no-full verwenden:

      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
      

      Sie können damit auch in die entgegengesetzte Richtung gehen und journalctl anweisen, alle Informationen anzuzeigen, unabhängig davon, ob sie nicht druckbare Zeichen enthält. Wir können dies mit dem Flag -a tun:

      journalctl -a
      

      Ausgabe auf Standardausgabe

      Standardmäßig zeigt journalctl die Ausgabe in einem Pager an, um den Konsum zu erleichtern. Wenn Sie jedoch vorhaben, die Daten mit Textmanipulationswerkzeugen zu verarbeiten, möchten Sie wahrscheinlich in der Lage sein, auf die Standardausgabe auszugeben.

      Sie können dies mit der Option --no-pager tun:

      journalctl --no-pager
      

      Dies kann direkt in ein Verarbeitungsprogramm geleitet oder in eine Datei auf der Festplatte umgeleitet werden, je nach Ihren Bedürfnissen.

      Ausgabeformate

      Wenn Sie, wie oben erwähnt, Journaleinträge verarbeiten, wird es Ihnen die Analyse der Daten wahrscheinlich leichter fallen, wenn sie in einem besser konsumierbaren Format vorliegen. Glücklicherweise kann das Journal in einer Vielzahl von Formaten angezeigt werden, wenn es erforderlich ist. Dazu können Sie die Option -o mit einem Formatbezeichner verwenden.

      Sie können die Journaleinträge beispielsweise in JSON ausgeben, indem Sie eingeben:

      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" }
      
      . . .
      

      Dies ist nützlich für das Parsen mit Dienstprogrammen. Sie könnten das Format json-pretty verwenden, um die Datenstruktur besser in den Griff zu bekommen, bevor Sie sie an den JSON-Verbraucher übergeben:

      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"
      }
      
      . . .
      

      Die folgenden Formate können für die Anzeige verwendet werden:

      • cat: Zeigt nur das Meldungsfeld selbst an.
      • export: Ein Binärformat, das sich zum Übertragen oder Sichern eignet.
      • json: Standard-JSON mit einem Eintrag pro Zeile.
      • json-pretty: JSON, das für eine bessere menschliche Lesbarkeit formatiert ist.
      • json-sse: JSON-formatierte Ausgabe, die eingehüllt ist, um das Hinzufügen von vom Server gesendeten Ereignissen zu ermöglichen.
      • short: Die Standardausgabe im syslog-Stil.
      • short-iso: Das Standardformat, das zum Anzeigen von ISO-8601 Wallclock-Zeitstempeln erweitert wurde.
      • short-monotonic: Das Standardformat mit monotonen Zeitstempeln.
      • short-precise: Das Standardformat mit Mikrosekundengenauigkeit.
      • verbose: Zeigt jedes für den Eintrag verfügbare Journalfeld an, einschließlich derjenigen, die normalerweise intern verborgen sind.

      Mit diesen Optionen können Sie die Journaleinträge in dem Format anzeigen, das Ihren aktuellen Bedürfnissen am besten entspricht.

      Aktive Prozessüberwachung

      Der Befehl journalctl imitiert, wie viele Administratoren tail zur Überwachung der aktiven oder jüngsten Aktivität verwenden. Diese Funktionalität ist in journalctl eingebaut, sodass Sie auf diese Funktionen zugreifen können, ohne eine Pipe zu einem anderen Tool verwenden zu müssen.

      Anzeigen aktueller Protokolle

      Um eine bestimmte Anzahl von Datensätzen anzuzeigen, können Sie die Option -n verwenden, die genau wie tail -n funktioniert.

      Sie zeigt standardmäßig die letzten 10 Einträge an:

      journalctl -n
      

      Sie können die Anzahl der Einträge, die Sie sehen möchten, mit einer Zahl nach dem -n angeben:

      journalctl -n 20
      

      Verfolgen von Protokollen

      Um die Protokolle aktiv zu verfolgen, während sie geschrieben werden, können Sie das Flag -f verwenden. Auch dies funktioniert so, wie Sie es vielleicht erwarten, wenn Sie Erfahrung mit der Verwendung von tail -f haben:

      journalctl -f
      

      Journalwartung

      Vielleicht fragen Sie sich, was es kostet, all die Daten zu speichern, die wir bisher gesehen haben. Außerdem sind Sie vielleicht daran interessiert, einige ältere Protokolle aufzuräumen und Speicherplatz freizugeben.

      Ermitteln der aktuellen Festplattenbelegung

      Sie können herausfiden, wie viel Platz das Journal derzeit auf der Festplatte belegt, indem Sie das Flag --disk-usage verwenden:

      journalctl --disk-usage
      
      Journals take up 8.0M on disk.
      

      Löschen alter Protokolle

      Wenn Sie Ihr Journal verkleinern möchten, können Sie dies auf zwei verschiedene Arten tun (verfügbar mit systemd Version 218 und höher).

      Wenn Sie die Option --vacuum-size verwenden, können Sie Ihr Journal durch Angabe einer Größe verkleinern. Dadurch werden alte Einträge entfernt, bis der gesamte auf der Festplatte belegte Journal-Speicherplatz die angeforderte Größe erreicht hat:

      sudo journalctl --vacuum-size=1G
      

      Eine weitere Möglichkeit, das Journal zu verkleinern, ist die Angabe einer Sperrzeit mit der Option --vacuum-time. Alle Einträge, die über diese Zeit hinausgehen, werden gelöscht. Dadurch können Sie die Einträge behalten, die nach einer bestimmten Zeit erstellt wurden.

      Um beispielsweise Einträge aus dem letzten Jahr zu behalten, können Sie eingeben:

      sudo journalctl --vacuum-time=1years
      

      Begrenzen der Journal-Erweiterung

      Sie können Ihren Server so konfigurieren, dass er den Speicherplatz, den das Journal einnehmen kann, begrenzt. Dies kann durch die Bearbeitung der Datei /etc/systemd/journald.conf erfolgen.

      Die folgenden Einträge können verwendet werden, um das Wachstum des Journals zu begrenzen:

      • SystemMaxUse=: Gibt den maximalen Festplattenplatz an, den das Journal im permanenten Speicher belegen kann.
      • SystemKeepFree=: Gibt den Speicherplatz an, den das Journal beim Hinzufügen von Journaleinträgen im permanenten Speicher frei lassen soll.
      • SystemMaxFileSize=: Kontrolliert, wie große einzelne Journaldateien im persistenten Speicher werden können, bevor sie rotiert werden.
      • RuntimeMaxUse=: Gibt den maximalen Festplattenspeicher an, der im flüchtigen Speicher (innerhalb des Dateisystems /run) verwendet werden kann.
      • RuntimeKeepFree=: Gibt an, wie viel Speicherplatz beim Schreiben von Daten in den flüchtigen Speicher (innerhalb des Dateisystems /run) für andere Verwendungen freigehalten werden soll.
      • RuntimeMaxFileSize=: Gibt an, wie viel Speicherplatz eine einzelne Journaldatei im flüchtigen Speicher (innerhalb des Dateisystems /run) einnehmen kann, bevor sie rotiert wird.

      Durch die Einstellung dieser Werte können Sie kontrollieren, wie journald den Speicherplatz auf Ihrem Server verbraucht und bewahrt. Denken Sie daran, dass SystemMaxFileSize und RuntimeMaxFileSize darauf abzielen, dass archivierte Dateien die angegebenen Grenzen erreichen. Dies ist wichtig zu bedenken, wenn Sie Dateizählungen nach einer Vakuum-Operation interpretieren.

      Zusammenfassung

      Wie Sie sehen können, ist das Journal systemd unglaublich nützlich für das Erfassen und Verwalten Ihrer System- und Anwendungsdaten. Die meiste Flexibilität ergibt sich aus den umfangreichen Metadaten, die automatisch aufgezeichnet werden, und der zentralisierten Natur des Protokolls. Der Befehl journalctl macht es einfach, die erweiterten Funktionen des Journals zu nutzen und umfangreiche Analysen und relationales Debugging verschiedener Anwendungskomponenten durchzuführen.



      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
      
      33
      

      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
      
      32
      99
      102
      133
      81
      84
      100
      0
      124
      87
      

      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