Une place pour une véritable innovation. Partagez vos propres utilitaires créés avec la communauté Manjaro.
Questions et discussions sur la programmation et le codage.
Répondre

Un tuto pour Journalctl [collaboratif]

#1Messageil y a 3 ans

Bonjour @ tous :salut:
On voit souvent des incompréhensions (compréhensibles :gsourire: ) avec l'utilisation de journalctl. Il existe bien des descriptions plus ou moins claires sur le sujet , mais la plupart sont en Rosbif....
Je me suis attelé a en traduire une qui me paraissait intéressante .
Je me suis servi d'un robot , puis ai tenté de retraduire en français potable. Je compte sur vous pour améliorer cette traduction en corrigeant surtout les terme techniques ou du moins le sens original que mes maigres connaissances ont certainement déformé.
J’espère que ça vous sera utile.


Comment utiliser Journalctl pour visualiser et manipuler les logs de systemd


Introduction
Certains des avantages les plus convaincants de systemd sont ceux qui sont impliqués avec le processus et de journalisation du système. Lors de l'utilisation d'autres outils, les journaux sont généralement dispersés dans tout le système, gérés par différents démons et les processus, et peuvent être assez difficiles à interpréter lorsqu'elles couvrent plusieurs applications. Systemd tente de répondre à ces questions en fournissant une solution de gestion centralisée pour connecter tous noyaux et processus utilisateurs. Le système qui recueille et gère ces journaux est connu comme le Journal.
Le journal est mis en œuvre avec le démon journald , qui gère tous les messages produits par le noyau, initrd, services, etc... Dans ce guide, nous allons discuter de la façon d'utiliser l'utilitaire journalctl , qui peut être utilisé pour accéder et manipuler les données contenues dans la journalisation.

Idée générale
Le concept de base du journal de systemd est de centraliser la gestion des journaux, peu importe d'où les messages sont originaires. Comme une grande partie de la gestion du processus de démarrage et les services sont gérés par le processus systemd, il est logique de normaliser la façon dont les journaux sont collectées et accessibles. Le démon journald recueille des données auprès de toutes les sources disponibles et les stocke dans un format binaire pour une manipulation aisée et dynamique.
Cela nous donne un certain nombre d'avantages significatifs. En interagissant avec les données en utilisant un utilitaire unique, les administrateurs sont en mesure d'afficher dynamiquement et d' enregistrer des données en fonction de leurs besoins. Cela peut être aussi simple que de consulter les données de démarrage en remontant à 3 boots, ou en combinant les entrées du journal de manière séquentielle à partir de deux services liés au débogage d' un problème de communication.
Stocker les données du journal dans un format binaire signifie également que les données peuvent être affichées dans des formats de sortie arbitraires en fonction de ce que vous avez besoin pour le moment. Par exemple pour la gestion quotidienne du journal que vous avez peut être utilisé pour afficher les journaux dans la norme au format syslog, mais aussi si vous décidez de représenter graphiquement les interruptions de service plus tard, vous pouvez sortir chaque entrée comme un objet JSON pour la visualiser en graphique. Comme les données ne sont pas écrites sur le disque dans le texte brut, aucune conversion n'est nécessaire lorsque vous avez besoin d'un format différent .
Le journal systemd peut être utilisé soit avec un syslog existant , soit il peut remplacer les fonctionnalités de syslog en fonction de vos besoins.
Ainsi, le journal systemd couvrira les besoins d'administrateurs multiples , il peut aussi compléter les mécanismes d'exploitation existants. Par exemple, vous pouvez avoir un système centralisé « syslog-server » que vous utilisez pour compiler les données de plusieurs serveurs, mais vous pouvez également souhaiter pour entrelacer les logs provenant de multiples services sur un seul système avec le Journal systemd. Vous pouvez faire les deux de ceux-ci en combinant ces technologies.

Réglage de l'heure système
Un des avantages de l'utilisation d'un journal binaire pour la journalisation des logs est la capacité de voir les enregistrements de journaux dans UTC ou heure locale à volonté. Par défaut, systemd va afficher les résultats en heure locale.
Pour cette raison, avant que nous commencions avec la journalisation, nous nous assurerons que le fuseau horaire est configuré correctement. La suite systemd dispose d' un outil appelé timedatectl qui peut aider.
Tout d'abord, vérifiez que les fuseaux horaires soient disponibles à la list-timezones

 timedatectl list-timezones 

Cela va lister les fuseaux horaires disponibles sur votre système. Lorsque vous trouvez celui qui correspond à l'emplacement de votre serveur, vous pouvez le régler en utilisant l'option « set-timezone »:

 sudo timedatectl set-timezone zone

Pour vous assurer que votre machine utilise le bon fuseau, utilisez le timedatectl seul 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 doit afficher l'heure exacte.
Affichage du journal de base
Pour voir les journaux que le démon journald a recueillies, utilisez la commande journalctl.
Utilisée seul, chaque entrée de journal qui est dans le système sera affiché dans un pager (généralement less pour vous permettre de naviguer. Les entrées les plus anciennes seront en-haut:

 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 à faire défiler, ce qui peut représenter des dizaines ou des centaines de milliers de lignes longues selon l'ancienneté du système.Cela démontre la quantité de données disponibles dans la base de données de journal.
Le format sera familier à ceux qui sont habitués à la norme syslog . Toutefois, journald collecte effectivement bien plus de données et provenant de plusieurs sources que les traditionnels syslog . Il comprend les journaux du processus de démarrage rapide, le noyau, l' initrd, et l'application d'erreur standard . Elles sont toutes disponibles dans le journal.
Vous remarquerez peut-être que tous les horodateurs étant affichées en heure locale. Cette option est disponible pour chaque entrée du journal, maintenant que nous avons notre heure locale réglée correctement sur notre système. Tous les journaux sont affichés en utilisant cette nouvelle information.
Si vous souhaitez afficher les horodateurs dans UTC, vous pouvez utiliser l'option --utc :

journalctl --utc


Journal Filtrage par Time
Bien qu' ayant accès à une telle collecte de données est certainement utile, une telle quantité d'informations peut être difficile, voire impossible, a appréhender. Pour cette raison, l'une des caractéristiques les plus importantes de journalctl est ses options de filtrage.
Afficher les journaux du démarrage en cours
La plus fondamentale fonction que vous pouvez utiliser quotidiennement est journalctl avec l'option -b . Cela va vous montrer toutes les entrées de journal qui ont été recueillies depuis le redémarrage le plus récent.

 journalctl -b 

Cela vous aidera à identifier et à gérer les informations qui sont pertinentes à votre environnement actuel.
Vous remarquerez que journalctl a inséré une ligne qui ressemble à ceci lorsque vous éteignez votre machine:
. . . -- Reboot -- . . .
Ceci peut être utilisé pour vous aider à séparer logiquement les informations dans les sessions de démarrage.
Précédents démarrages
Si la plupart du temps vous consulterez les informations de l'amorçage en cours, il y aura certainement des moments où vous aimerez aussi obtenir les journaux des boots précédents .
Le journal peut enregistrer des informations à partir de nombreux boots précédents, et est conçu pour afficher ces informations facilement.
Certaines distributions permettent d'enregistrer des informations d'amorçage précédente par défaut, tandis que d'autres désactiveront cette fonction. Pour activer les informations de démarrage persistant, vous pouvez soit créer le répertoire de stockage du journal en tapant:

sudo mkdir -p / var / log / Journal

Ou soit vous pouvez éditer le fichier de configuration de la journalisation:

  sudo nano /etc/systemd/journald.conf

A la section[Journal], modifiez [Journal] Storage= persistent pour activer la journalisation persistante.
Lors de l'enregistrement des boots précédents est activé sur votre serveur, journalctl fournit quelques commandes pour vous aider à travailler avec des boots comme une unité de la division. Pour voir les boots que journald connaît, utilisez --list-boots :

 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

Cela permet d'afficher une ligne pour chaque démarrage. La première colonne est le référencement du boot qui peut être utilisé pour repérer facilement la cible avec journalctl Si vous avez besoin d'une référence absolue, l'ID de démarrage est dans la deuxième colonne. Vous pouvez utiliser indifféremment les deux indications.
Pour afficher des informations à partir de ces boots, vous pouvez utiliser l'information de la première ou de la seconde colonne.
Par exemple, pour voir la journalisation de l'amorçage précédent, utilisez le pointeur -1 par rapport à l'option -b :

 journalctl -b -1

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

 journalctl -b caf0524a1d394ce0bdbcff75b94444fe 


La notion de temps
On constate que les entrées de journal par boot sont incroyablement utiles. Bien souvent, vous voudrez peut-être demander des affichages de temps qui ne cadrent pas bien avec le système démarré. Cela peut être particulièrement vrai lorsqu'on traite avec des serveurs de longue haleine qui ont une disponibilité importante.
Vous pouvez filtrer par des délais arbitraires en utilisant les options --since et --until, qui limitent respectivement les entrées affichées avant ou après le moment donné.
Les valeurs de temps peuvent venir dans une variété de formats. Pour les valeurs de temps absolu, 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:15 en tapant:

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

Si des éléments au format ci-dessus sont ignorés, certains paramètres par défaut seront appliqués. Par exemple, si la date est omise, la date actuelle sera assumée. Si la composante de temps est manquant, "00:00:00" (minuit) seront remplacés. Le champ des secondes peut être laissé ainsi par défaut à "00":

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

La journalisation comprend aussi des valeurs relatives . Par exemple, vous pouvez utiliser les mots "yesterday", "today", "tomorrow", ou "now". On peut utiliser des temps relatifs en faisant précéder "-" ou "+" pour une valeur numérotée ou en utilisant des mots comme "ago" dans une construction de phrase.
Pour obtenir les données d'hier, vous pouvez taper:

 journalctl --since yesterday 

Si vous voulez des rapports sur une interruption de service à partir de 09h00 jusqu' il y a une heure, vous pouvez 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 et de filtrer les entrées que vous souhaitez voir.

Filtrage par un message d'intérêt
Nous avons appris ci-dessus quelques façons que vous pouvez filtrer les données de journalisation en utilisant des paramètres de temps. Dans cette section, nous allons aborder la notion de filtre basé sur ce service ou composant qui vous intéresse. Le Journal systemd offre une variété de façons de le faire.

Par Unité
La plus façon la plus utile de filtrage est par l'unité qui nous intéresse. Nous pouvons pour ça utiliser l'option -u .
Par exemple, pour voir tous les journaux à partir d'une unité Nginx sur notre système, nous pouvons taper:

 journalctl -u nginx.service 

Typiquement, vous souhaiterez filtrer chronologiquement afin d'afficher les lignes qui vous intéressent, par exemple, pour vérifier la façon dont le service est lancé aujourd'hui, vous pouvez taper.:

 journalctl -u nginx.service --since today 

Ce type de mise au point devient extrêmement utile lorsque vous comprenez l' avantage de la capacité de la journalisation pour entrelacer les enregistrements de différentes unités. Par exemple, si votre processus Nginx est relié à une unité PHP-FPM pour traiter du contenu dynamique, vous pouvez fusionner les entrées à la fois dans l'ordre chronologique en spécifiant les deux unités:

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

Cela peut rendre plus aisé le repérage des interactions entre les différents processus individuels et les systèmes de débogage.

Par processus, utilisateur ou groupe ID
Certains services engendrent une variété de processus fils pour faire le travail. Si vous avez repéré le PID du processus qui vous intéresse, vous pouvez filtrer en l'utilisant.
Pour cela, nous pouvons filtrer en spécifiant le _PID . Par exemple, si le PID qui nous intéresse est 8088, nous pouvons taper:

 journalctl _PID=8088

À d'autres moments, vous pouvez afficher toutes les entrées enregistrées par un utilisateur ou un groupe spécifique. Cela peut être fait avec les filtres _UID ou _GID. Par exemple, si votre serveur web fonctionne sous le www-data utilisateur, vous pouvez trouver l'ID de l'utilisateur en tapant:

 id -u www-data 
 33

Ensuite, vous pouvez utiliser l'ID qui a été retourné pour filtrer les résultats de journalisations:

 journalctl _UID= 33 --since today 

Le Journal systemd comporte de nombreux domaines qui peuvent être utilisés pour le filtrage. Par exemple ceux qui sont passés par le processus en étant connectés et ceux qui sont appliqués par journald en utilisant les informations qu'il recueille dans le système au moment de l'enregistrement du log.
Le symbole « _ » indique que le _PID est de ce dernier type. Le journal enregistre et indexe le PID du processus qui se connecte pour le filtrage automatiquement. Vous pouvez vous renseigner sur tous les champs de journalisations disponibles en tapant:

man systemd.journal-fields 

Nous allons voir certains d'entre eux dans ce guide. Pour l'instant , nous allons passer en revue une option des plus utile en rapport avec le filtrage par ces champs. L'option -F peut être utilisée pour afficher toutes les valeurs disponibles pour un champ journal donné.
Par exemple, pour voir quels groupes d'ID sont connus du Journal systemd , vous pouvez taper:

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

Cela va vous montrer toutes les valeurs stockées par la journalisation pour le champ de groupe ID. Cela peut vous aider à construire vos filtres.

Par le chemin du composant
Nous pouvons également filtrer en fournissant un chemin d'accès.
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 

Habituellement, si une unité est disponible pour l'exécutable, cette méthode est plus propre et permet une meilleure information (entrées provenant de processus enfants associés, etc). Parfois, cependant, cela est impossible.
Affichage des messages du Noyau
Les messages du noyau, ces trouve habituellement dans la sortie de dmesg. Ils peuvent être récupérés à partir de la journalisation ainsi.
Pour afficher uniquement ces messages, nous pouvons ajouter l'option -k ou --dmesg à notre commande:

 journalctl -k 

Par défaut, cette affichera les messages du noyau en cours d'utilisation . Vous pouvez spécifier un boot spécifique en utilisant les options de sélection de boot . Par exemple, pour obtenir les messages remontant à 5 boots, vous pouvez taper:

 journalctl -k -b -5 


Par priorité
Un filtre qui intéresse souvent les administrateurs système est la priorité du message. Il est souvent utile d'enregistrer des informations à un niveau très détaillé mais dès lors la digestion des informations disponibles devient lourde , avec notamment les journaux de faible priorité, ce qui peut être gênant et déroutant.
Vous pouvez utiliser journalctl pour afficher uniquement les messages d'une priorité indiquée ci-dessus ou 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 va vous montrer tous les messages marqués comme une erreur, critique, alerte ou d'urgence. Le journal met en œuvre les standards syslog niveaux de message. Vous pouvez utiliser le nom de la priorité ou sa valeur numérique correspondante. Dans l'ordre de priorité décroissant, ce sont:
0: Emerg
1: Alerte
2: crit
3: err
4: avertissement
5: avis
6: infos
7: debug
Les numéros ou les noms ci-dessus peuvent être utilisés de façon interchangeable avec l' option -p. La sélection une priorité affichera les messages marqués au niveau spécifié et ceux au-dessus.
Modification de l'affichage Journal
Ci-dessus, nous avons démontré la sélection d'entrée par le filtrage. Il y a d'autres façons pour modifier la sortie . Nous pouvons régler l' affichage de journalctl pour répondre à divers besoins.
Tronquer ou élargir les retours
Nous pouvons ajuster la manière dont journalctl affiche les données .
Par défaut, journalctl montrera toute l'entrée dans le pager . Ça permet de voir les entrées longues et donc masquées sur la droite de l'écran. Cette information peut être accessible en appuyant sur la touche flèche droite.
Si vous préférez que la sortie tronquéesoit visible en insérant une ellipse où l'information a été supprimé, vous pouvez utiliser la variante --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 aussi aller dans l'autre sens et dire à journalctl d'afficher toutes ses informations, sans se soucier de savoir si elle comporte des caractères imprimables ou non . Nous pouvons le faire avec l'option -a :

 journalctl -a 


Sortie sur la sortie standard
Par défaut, journalctl affiche les données dans un pager pour faciliter la consultation. Si vous avez décidé de traiter les données avec du traitement de texte, vous utiliserez alors la sortie standard.
Vous pouvez faire cela avec l'option --no-pager:

 journalclt --no-pager 

Cela peut être canalisé immédiatement dans un utilitaire de traitement ou redirigé vers un fichier sur le disque, en fonction de vos besoins.

Formats de sortie
Si vous traitez les écritures de journal, comme mentionné ci-dessus, vous aurez probablement plus de facilité à analyser les données si elles sont dans un format plus accessible. Heureusement, le journal peut être affiché dans une variété de formats en fonction des besoins. Vous pouvez le faire en utilisant le -o option avec un spécificateur de format.
Par exemple, vous pouvez afficher les entrées de journal en 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" } . .
.
Ceci est utile pour l'analyse avec ces services Vous pouvez utiliser la forme json-pretty pour obtenir un meilleur contrôle sur la structure de données avant de les transmettre à 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 suivants peuvent être utilisés pour l'affichage:
cat: Affiche uniquement le champ de message lui-même.
export: Un format binaire approprié pour le transfert ou la sauvegarde.
json: standard json avec une entrée par ligne.
json-pretty: JSON formaté pour une meilleure lisibilité humaine
json-sse: sortie json formatée qui permet d'ouvrir une connexion vers le serveur
short: La valeur par défaut en sortie de style syslog
short-iso: Le format conforme à ISO 8601 pour le format numérique de l'horodatage .
short-monotonic: Le format par défaut avec horodateurs monotones.
short-precise: Le format par défaut avec une précision d'une microseconde
verbose: Affiche tous les domaines de la journalisation disponible pour l'entrée, y compris ceux qui sont habituellement cachés à l'intérieur.
Ces options permettent d'afficher les entrées de journal dans les format qui correspondent le mieux à vos besoins actuels.
Surveillance de processus actif
La commande journalctl s'inspire de la méthode des administrateurs qui utilisent tail pour surveiller l'activité actuelle ou récente. Cette fonctionnalité intégrée à journalctl vous permettent d'accéder à ces fonctions sans avoir à canaliser vers un autre outil.

Affichage de journaux récents
Pour afficher un nombre fixe de dossiers, vous pouvez utiliser l' option -n, qui fonctionne exactement comme tail -n
Par défaut, il affiche les 10 dernières entrées:

 journalctl -n 

Vous pouvez spécifier le nombre d'entrées que vous souhaitez voir

 journalctl -n 20 

Journaux en temps réels
Pour suivre les journaux en temps réels, vous pouvez utiliser -f . Encore une fois, cela fonctionne comme vous pourriez vous y attendre de la même manière qu'en utilisant tail -f

 journalctl -f 


Maintenance du Journal
Vous vous inquiétez peut-être sur le poids de toutes ces données que nous avons vu jusqu'à présent. En outre, vous pouvez être intéressés par le nettoyage de journaux plus anciens afin de libérer de l'espace.
Connaître l'espace disque alloué
Vous pouvez découvrir la quantité d'espace que la journalisation occupe actuellement sur ​​le disque en utilisant l'option --disk-usage :

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


Suppression des anciens journaux
Si vous souhaitez réduire votre journal, vous pouvez le faire de deux manières différentes (disponible depuis la version systemd 218 ).
Si vous utilisez l'option --vacuum-size, vous pouvez réduire votre journal en indiquant une taille. Cela permettra d'éliminer les anciennes entrées jusqu'à ce que l'espace total de la journalisation repris sur le disque est à la taille souhaitée:

 sudo journalctl --vacuum-size=1G

L'autre façon qui vous permet de réduire la journalisation est de fournir un temps de coupure avec l'option --vacuum-time. Toutes les entrées au-delà de ce temps sont supprimés. Cela vous permet de garder les entrées qui ont été créés après un temps spécifique.
Par exemple, pour garder les entrées de l'année dernière, vous pouvez taper:

 sudo journalctl --vacuum-time=1years 

Limiter l'Expansion du Journal
Vous pouvez configurer votre serveur afin d'imposer des limites sur la quantité d'espace que le journal peut prendre . Cela peut être fait en éditant le fichier /etc/systemd/journald.conf .
Les éléments suivants peuvent être utilisés pour limiter la croissance de la journalisation:
SystemMaxUse= Indique l'espace disque maximal qui peut être utilisé par la journalisation dans un stockage persistant.
SystemKeepFree= Indique la quantité d'espace que le journal devra laisser libres pour pouvoir ajouter des entrées de journal pour le stockage persistant.
SystemMaxFileSize= Contrôle la façon dont les grands fichiers journaux individuels peuvent se développer dans le stockage persistant avant d'être écrases.
RuntimeMaxUse= Indique l'espace disque maximal qui peut être utilisé dans le stockage volatile (dans le /run système de fichiers).
RuntimeKeepFree= Indique la quantité d'espace pouvant être mise de côté pour d'autres usages lors de l'écriture de données à mémoire volatile (dans le /run système de fichiers).
RuntimeMaxFileSize= Indique la quantité d'espace qu'un fichier individuel de la journalisation peut prendre jusqu'à en mémoire volatile (dans le /run système de fichiers) avant d'être tourné.
En définissant ces valeurs, vous pouvez contrôler la façon dont journald consomme et préserve l'espace sur votre serveur.

Conclusion
Comme vous pouvez le voir, la journalisation de systemd est incroyablement utile pour collecter et gérer les données de votre système et des applications. Sa grande souplesse provient des vastes métadonnées enregistrées automatiquement et du caractère centralisé du journal. Il est facile avec la commande journalctl de profiter des fonctionnalités avancées de la journalisation et de faire une analyse approfondie et de débogage relationnel des différents composants de l'application.

Un tuto pour Journalctl [collaboratif]

#2Messageil y a 3 ans

Merci à toi pour ce super tuto.

Répondre