En tant qu'administrateur système Linux, inspecter les fichiers journaux est l'une des tâches les plus courantes que vous pourriez avoir à effectuer.
Journaux Linux sont cruciaux :ils stockent des informations importantes sur certaines erreurs qui peuvent survenir sur votre système.
Ils peuvent également stocker des informations sur qui essaie d'accéder à votre système, ce que fait un service spécifique ou sur un plantage du système qui s'est produit plus tôt.
Par conséquent, savoir localiser , manipuler et analyser les fichiers journaux est définitivement une compétence que vous devez maîtriser.
Dans ce tutoriel, nous allons dévoiler tout ce qu'il y a à savoir sur la journalisation Linux.
On vous présentera la façon dont la journalisation est architecturée sur les systèmes Linux et comment différents périphériques et processus virtuels interagissent pour enregistrer les entrées.
Nous allons approfondir le protocole Syslog et comment il est passé de syslogd (sur les anciens systèmes) à journalctl propulsé par systemd sur les systèmes récents.
Types de journalisation Linux
Lorsque vous traitez avec la journalisation Linux, vous devez comprendre quelques notions de base avant de taper des commandes dans le terminal.
Sous Linux, vous disposez de deux types de mécanismes de journalisation :
- Journalisation du noyau :liés aux erreurs, avertissements ou entrées d'informations que votre noyau peut écrire ;
- Journalisation des utilisateurs :liées à l'espace utilisateur, ces entrées de journal sont liées à des processus ou des services susceptibles de s'exécuter sur la machine hôte.
En divisant la journalisation en deux catégories, nous dévoilons essentiellement que la mémoire elle-même est divisée en deux catégories sous Linux :l'espace utilisateur et espace noyau .
Journalisation du noyau
Commençons d'abord par la journalisation associée à l'espace du noyau, également appelée journalisation du noyau.
Sur l'espace noyau, la journalisation est effectuée via le Kernel Ring Buffer.
Le tampon en anneau du noyau est un tampon circulaire qui est la première structure de données stockant les messages de journal lorsque le système démarre.
Lorsque vous démarrez votre machine Linux, si des messages de journal sont affichés à l'écran, ces messages sont stockés dans le tampon en anneau du noyau.
La journalisation du noyau est lancée avant la journalisation des utilisateurs (géré par le démon syslog ou par rsyslog sur les distributions récentes).
Le tampon circulaire du noyau, à peu près comme tous les autres fichiers journaux de votre système, peut être inspecté.
Afin d'ouvrir les journaux liés au noyau sur votre système, vous devez utiliser le "dmesg ” commande.
Remarque :vous devez exécuter cette commande en tant que root ou avoir des droits privilégiés afin d'inspecter le tampon circulaire du noyau.
$ dmesg
Comme vous pouvez le voir, depuis le démarrage du système jusqu'au moment où vous avez exécuté la commande, le noyau garde une trace de toutes les actions, avertissements ou erreurs qui peuvent se produire dans l'espace du noyau.
Si votre système a du mal à détecter ou à monter un disque, c'est probablement là que vous souhaitez inspecter les erreurs.
Comme vous pouvez le voir, la commande dmesg est une interface assez agréable pour voir les journaux du noyau, mais comment la commande dmesg vous renvoie-t-elle ces résultats ?
Afin de dévoiler les différents mécanismes utilisés, voyons quels processus et appareils prennent en charge la journalisation du noyau .
Les composants internes de la journalisation du noyau
Comme vous l'avez probablement déjà entendu, sous Linux,tout est un fichier.
Si tout est un fichier, cela signifie également que les appareils sont des fichiers.
Sous Linux, le tampon en anneau du noyau est matérialisé par un fichier de périphérique de caractères dans le répertoire /dev et il est nommé kmsg.
$ ls -l /dev/ | grep kmsg
Si nous devions décrire la relation entre le périphérique kmsg et le tampon circulaire du noyau, voici comment nous le représenterions.
Comme vous pouvez le voir, le périphérique kmsg est une abstraction utilisé pour lire et écrire dans le tampon circulaire du noyau.
Vous pouvez essentiellement le voir comme un point d'entrée pour les processus de l'espace utilisateur afin d'écrire dans le tampon en anneau du noyau.
Cependant, le schéma ci-dessus est incomplet car un fichier spécial est utilisé par le noyau pour vider les informations du journal du noyau dans un fichier.
Si nous devions le résumer, nous dirions essentiellement que le périphérique virtuel kmsg agit comme un point d'entrée pour le tampon en anneau du noyau tandis que la sortie de ce processus (les lignes de journal) est imprimée dans le fichier /proc/kmsg.
Ce fichier ne peut être parsé que par un seul processus qui est la plupart du temps l'utilitaire de journalisation utilisé sur l'espace utilisateur. Sur certaines distributions, il peut s'agir de syslogd, mais sur les distributions plus récentes, il est intégré à rsyslog.
L'utilitaire rsyslog possède un ensemble de modules intégrés qui redirigeront les journaux du noyau vers des fichiers dédiés sur le système de fichiers.
Historiquement, les journaux du noyau étaient récupérés par le démon klogd sur les systèmes précédents, mais il a été remplacé par rsyslog sur la plupart des distributions.
D'un côté, vous avez des utilitaires de journalisation qui lisent depuis le ring buffer mais vous avez aussi des programmes en espace utilisateur qui écrivent dans le ring buffer :systemd (avec le fameux systemd-journal) sur les distributions récentes par exemple.
Maintenant que vous en savez plus sur la journalisation du noyau, voyons comment la journalisation est effectuée sur l'espace utilisateur.
Journalisation côté utilisateur avec Syslog
La connexion à l'espace utilisateur est très différente de la connexion à l'espace noyau.
Côté utilisateur, la journalisation est basée sur le protocole Syslog .
Syslog est utilisé comme standard pour produire, transférer et collecter les journaux produits sur une instance Linux.
Syslog définit des niveaux de gravité ainsi que des niveaux d'installation aidant les utilisateurs à mieux comprendre les journaux produits sur leurs ordinateurs.
Les journaux peuvent ensuite être analysés et visualisés sur des serveurs appelés serveurs Syslog.
En bref, le protocole Syslog est un protocole utilisé pour définir les messages de journal sont formatés, envoyés et reçus sur les systèmes Unix.
Syslog est connu pour définir le format syslog qui définit le format qui doit être utilisé par les applications pour envoyer les journaux.
Ce format est bien connu pour définir deux termes importants :installations et priorités .
Fonctionnalités Syslog expliquées
En bref, un niveau d'établissement est utilisé pour déterminer le programme ou la partie du système qui a produit les journaux.
Sur votre système Linux, de nombreux utilitaires et programmes différents envoient des journaux. Afin de déterminer quel processus a envoyé le journal en premier lieu, Syslog définit les numéros, les numéros d'installation, qui sont utilisés par les programmes pour envoyer les journaux Syslog.
Il existe plus de 23 fonctions Syslog différentes décrites dans le tableau ci-dessous.
| Code numérique | Mot clé | Nom de l'établissement |
| 0 | kern | Messages du noyau |
| 1 | utilisateur | Messages au niveau de l'utilisateur |
| 2 | courrier | Système de messagerie |
| 3 | démon | Démons système |
| 4 | authentification | Messages de sécurité |
| 5 | syslog | Messages Syslogd |
| 6 | lpr | Sous-système d'imprimante en ligne |
| 7 | actualités | Sous-système d'actualités du réseau |
| 8 | uucp | Sous-système UUCP |
| 9 | cron | Démon d'horloge |
| 10 | authpriv | Messages de sécurité |
| 11 | ftp | Démon FTP |
| 12 | ntp | Sous-système NTP |
| 13 | sécurité | Audit du journal de sécurité |
| 14 | console | Alertes du journal de la console |
| 15 | solaris-cron | Journaux de planification |
| 16-23 | local0 à local7 | Installations utilisées localement |
La plupart de ces fonctionnalités sont réservées aux processus système (tels que le serveur de messagerie si vous en avez un ou l'utilitaire cron). Certains d'entre eux (du numéro d'installation 16 à 23) peuvent être utilisés par des clients Syslog personnalisés ou des programmes utilisateur pour envoyer des journaux.
Priorités Syslog expliquées
Niveaux de gravité Syslog sont habitués à la gravité d'un événement de journal et vont du débogage, des messages d'information aux niveaux d'urgence.
Comme pour les niveaux d'installation Syslog, les niveaux de gravité sont divisés en catégories numériques allant de 0 à 7, 0 étant le niveau d'urgence le plus critique .
Encore une fois, voici un tableau de tous les niveaux de priorité disponibles avec Syslog.
Voici les niveaux de gravité syslog décrits dans un tableau :
| Valeur | Gravité | Mot clé |
| 0 | Urgence | emerg |
| 1 | Alerte | alert |
| 2 | Critique | crit |
| 3 | Erreur | err |
| 4 | Avertissement | warning |
| 5 | Avis | notice |
| 6 | Informationnel | info |
| 7 | Débogage | debug |
Architecture Syslog
Syslog définit également quelques termes techniques qui sont utilisés pour construire l'architecture des systèmes de journalisation :
- Auteur :également connu sous le nom de "client Syslog", un expéditeur est responsable de l'envoi du message au format Syslog sur le réseau ou à la bonne application ;
- Relais :un relais est utilisé pour acheminer les messages sur le réseau. Un relais peut transformer les messages afin de l'enrichir par exemple (des exemples célèbres incluent Logstash ou fluentd);
- Collectionneur :également appelés « serveurs Syslog », les collecteurs sont utilisés pour stocker, visualiser et récupérer les journaux de plusieurs applications. Le collecteur peut écrire des journaux dans une grande variété de sorties différentes :fichiers locaux, bases de données ou caches.
Comme vous pouvez le voir, le protocole Syslog suit l'architecture client-serveur nous avons vu dans les tutoriels précédents.
Un client Syslog crée des messages et les envoie à des relais locaux ou distants facultatifs qui peuvent ensuite être transférés vers des serveurs Syslog.
Maintenant que vous savez comment le protocole Syslog est architecturé, qu'en est-il de notre propre système Linux ?
Suive-t-il cette architecture ?
Architecture de journalisation locale Linux
La connexion sur un système Linux local suit les principes exacts que nous avons décrits précédemment.
Sans plus tarder, voici comment la journalisation est architecturée sur un système Linux (sur les distributions récentes)
Suivant l'architecture originator-relay-collector décrite précédemment, dans le cas d'un système Linux local :
- Les initiateurs sont des applications clientes pouvant intégrer des bibliothèques syslog ou journald afin d'envoyer des journaux ;
- Aucun relais n'est implémenté localement par défaut ;
- Les collecteurs sont rsyslog et le démon journald écoute sur des sockets prédéfinis pour les journaux entrants.
Alors, où sont stockés les journaux après avoir été reçus par les collecteurs ?
Emplacement du fichier journal Linux
Sur votre système Linux, les journaux sont stockés dans /var/log répertoire.
Les journaux du répertoire /var/log sont divisés en fonctionnalités Syslog que nous avons vues précédemment, suivies du suffixe de journal :auth.log, daemon.log, kern.log ou dpkg.log.
Si vous inspectiez le fichier auth.log, les journaux liés à l'authentification et à l'autorisation sur votre système Linux vous seraient présentés.
De même, le fichier cron.log affiche des informations relatives au service cron sur votre système.
Cependant, comme vous pouvez le voir sur le schéma ci-dessus, il existe une coexistence de deux systèmes de journalisation différents sur votre serveur Linux :rsyslog et systemd-journal.
Coexistence de Rsyslog et systemd-journal
Historiquement, un démon était responsable de la collecte des journaux de vos applications sous Linux.
Sur de nombreuses anciennes distributions, cette tâche était assignée à un démon appelé syslogd mais il a été remplacé dans les distributions récentes par le démon rsyslog .
Lorsque systemd a remplacé le processus init existant sur les distributions récentes, il est venu avec sa propre façon de récupérer et de stocker les journaux :systemd-journal.
Maintenant, les deux systèmes coexistent mais leur coexistence était considérée comme rétrocompatible avec la manière dont les journaux étaient architecturés dans le passé.
La principale différence entre rsyslog et systemd-journal est que rsyslog conservera les journaux dans les fichiers journaux disponibles sur /var/log alors que journald ne le sera pas conserver les données à moins qu'elles ne soient configurées pour le faire.
Emplacement des fichiers journaux du journal
Comme vous l'avez compris dans la dernière section, le systemd-journal L'utilitaire garde également une trace des activités de journalisation sur votre système.
Certaines applications configurées en tant que services (un serveur HTTP Apache par exemple) peuvent communiquer directement avec le journal systemd.
Le journal systemd stocke les journaux de manière centralisée est le /run/log/journal répertoire.
Les fichiers journaux sont stockés sous forme de fichiers binaires par systemd, vous ne pourrez donc pas inspecter les fichiers à l'aide des commandes cat ou less habituelles.
Au lieu de cela, vous souhaitez utiliser le "journalctl ” afin d'inspecter les fichiers journaux créés par systemd-journal.
$ journalctl
Il existe de nombreuses options différentes que vous pouvez utiliser avec journalctl, mais la plupart du temps, vous souhaitez vous en tenir aux options "-r" et "-u".
Pour voir les dernières entrées de journal, utilisez "journalctl " avec le "-r ".
$ journalctl -r
Si vous souhaitez voir les journaux liés à un service spécifique , utilisez l'option "-u" et spécifiez le nom du service.
$ journalctl -u <service>Par exemple, pour voir les journaux liés au service SSH, vous devez exécuter la commande suivante
$ journalctl -u sshMaintenant que vous avez vu comment lire les fichiers de configuration, voyons comment configurer facilement vos utilitaires de journalisation.
Configuration de la journalisation Linux
Comme vous l'avez probablement compris dans les sections précédentes, la journalisation Linux est basée sur deux composants importants :rsyslog et systemd-journal.
Chacun de ces utilitaires a son propre fichier de configuration et nous allons voir dans les chapitres suivants comment ils peuvent être configurés.
Configuration du journal Systemd
Les fichiers de configuration du journal systemd se trouvent dans le répertoire /etc/systemd répertoire.
$ sudo vi /etc/systemd/journald.confLe fichier nommé "journald.conf ” est utilisé pour configurer le démon de journal sur les distributions récentes.
L'une des options les plus importantes dans la configuration du journal est le "Stockage ” paramètre.
Comme précisé précédemment, les fichiers journaux ne sont pas conservés sur votre système et ils seront perdus au prochain redémarrage.
Pour rendre vos journaux de journal persistants, assurez-vous de modifier ce paramètre sur "persistant" et de redémarrer votre démon de journal systemd.
Pour redémarrer le démon de journalisation, utilisez la commande "systemctl" avec l'option "restart" et spécifiez le nom du service.
$ sudo systemctl restart systemd-journaldPar conséquent, les journaux de journal seront stockés dans le répertoire /var/log/journal à côté des fichiers journaux rsyslog.
$ ls -l /var/log/journal
Si vous êtes curieux de connaître la configuration de systemd-journal, assurez-vous de lire la documentation fournie par FreeDesktop.
Configuration Rsyslog
D'autre part, le service rsyslog peut être configuré via le fichier /etc/rsyslog.conf fichier de configuration.
$ sudo vi /etc/rsyslog.confComme spécifié précédemment, rsyslog est essentiellement un collecteur Syslog mais le concept principal que vous devez comprendre est que Rsyslog fonctionne avec des modules.
Son architecture modulaire fournit des plugins tels que des moyens natifs de transférer les journaux vers un fichier, un shell, une base de données ou des sockets.
En travaillant avec rsyslog, il y a deux sections principales qui méritent votre attention :modules et règles .
Rsyslog Modules
Par défaut, deux modules sont activés sur votre système :imuxsock (écoute sur le socket syslog) et imjournal (transfert essentiellement les journaux de journal vers rsyslog).
Remarque :le imklog (responsable de la collecte des journaux du noyau) peut également être activé.
Règles Rsyslog
Les règles section de rsyslog est probablement la plus importante.
Sur rsyslog, mais vous pouvez trouver les mêmes principes sur les anciennes distributions avec systemd, la section des règles définit quel journal doit être stocké dans votre système de fichiers en fonction de sa facilité et de sa priorité.
Comme exemple, prenons le fichier de configuration rsyslog suivant.
La première colonne décrit les règles appliquées :à gauche du point, vous définissez la installation et à droite la sévérité .
Un symbole générique "*" signifie qu'il fonctionne pour toutes les gravités.
Par conséquent, si vous souhaitez modifier votre configuration de journalisation dans l'ordre, disons par exemple que vous n'êtes intéressé que par des gravités spécifiques, c'est le fichier que vous modifierez.
Utilitaires de surveillance des journaux Linux
Dans la section précédente, nous avons vu comment configurer facilement vos utilitaires de journalisation, mais quels utilitaires pouvez-vous utiliser pour lire facilement vos journaux Linux ?
Le moyen le plus simple de lire et de surveiller vos journaux Linux consiste à utiliser la commande tail avec l'option "-f" pour suivre.
$ tail -f <file>Par exemple, pour lire les journaux écrits dans le fichier auth.log, vous exécuterez la commande suivante.
$ tail -f /var/log/auth.logUn autre excellent moyen de lire les journaux Linux consiste à utiliser des applications graphiques si vous utilisez un environnement de bureau Linux.
Les "Journaux ” est une application graphique conçue pour répertorier les journaux des applications et du système pouvant être stockés dans divers fichiers journaux (soit dans rsyslog, soit dans journald).
Utilitaires de journalisation Linux
Maintenant que vous avez vu comment la journalisation peut être configurée sur un système Linux, voyons quelques utilitaires que vous pouvez utiliser au cas où vous voudriez journaliser des messages.
Utiliser l'enregistreur
Le enregistreur est probablement l'un des clients de journalisation les plus simples à utiliser.
Logger est utilisé pour envoyer des messages de journal au journal système et il peut être exécuté en utilisant la syntaxe suivante.
$ logger <options> <message>Supposons, par exemple, que vous souhaitiez envoyer un message d'urgence de la fonction d'authentification à votre utilitaire rsyslog, vous exécuterez la commande suivante.
$ logger -p auth.emerg "Somebody tried to connect to the system"Maintenant, si vous deviez inspecter le fichier /var/log/auth.log, vous seriez en mesure de trouver le message que vous venez de consigner sur le serveur rsyslog.
$ tail -n 10 /var/log/auth.log | grep --color connect
Le logger est très utile lorsqu'il est utilisé dans des scripts Bash par exemple.
Mais que se passerait-il si vous vouliez journaliser des fichiers en utilisant le systemd-journal ?
Utiliser systemd-cat
Pour envoyer des messages au journal systemd, vous devez utiliser la commande "systemd-cat" et spécifier la commande que vous souhaitez exécuter.
$ systemd-cat <command> <arguments>Si vous souhaitez envoyer la sortie de la commande "ls -l" au journal, vous devez écrire la commande suivante
$ systemd-cat ls -l
Il est également possible d'envoyer des journaux en "texte brut" au journal en redirigeant la commande echo vers l'utilitaire systemd-cat.
$ echo "This is a message to journald" | systemd-catUtiliser le mur
La commande wall n'est pas directement liée aux utilitaires de journalisation, mais elle peut être très utile pour l'administration du système Linux.
La commande wall est utilisée pour envoyer des messages à tous les utilisateurs connectés.
$ wall -n <message>Si vous deviez par exemple écrire un message à tous les utilisateurs connectés pour les informer du prochain redémarrage du serveur, vous exécuteriez la commande suivante.
$ wall -n "Server reboot in five minutes, close all important applications"
Conclusion
Dans ce didacticiel, vous en avez appris davantage sur la journalisation Linux :comment il est architecturé et comment les différents composants de journalisation (à savoir rsyslog et journal ) interagir ensemble.
Vous en avez appris plus sur le protocole Syslog et comment les collecteurs peuvent être configurés afin de consigner des événements spécifiques sur votre système.
La journalisation Linux est un vaste sujet et il existe de nombreux autres sujets à explorer sur le sujet.
Saviez-vous que vous pouvez créer des systèmes de journalisation centralisés afin de surveiller les journaux sur plusieurs machines ?
Si la journalisation centralisée vous intéresse, assurez-vous de lire notre guide !
De plus, si vous êtes passionné par l'administration système Linux, nous avons une section complète qui lui est dédiée sur le site Web, alors assurez-vous de la consulter !