Pendant des décennies, la journalisation Linux a été gérée par le démon syslogd.
Syslogd collecterait les messages de journal que les processus système et les applications envoyaient au pseudo-périphérique /dev/log. Ensuite, il dirigerait les messages vers les fichiers journaux en texte brut appropriés dans le répertoire /var/log/.
Syslogd saurait où envoyer les messages car chacun comprend des en-têtes contenant des champs de métadonnées (y compris un horodatage, ainsi que l'origine et la priorité du message).
Dans le sillage du mastodonte implacable et conquérant du monde de systemd, la journalisation Linux est désormais également gérée par journald. Je dis aussi parce que syslogd n'est allé nulle part et que vous pouvez toujours trouver la plupart de ses fichiers journaux traditionnels dans /var/log/. Mais vous devez savoir qu'il y a un nouveau shérif en ville dont le nom (ligne de commande) est journalctl.
Mais cet article ne concerne pas journald. Ici, l'accent est mis sur systemd, alors creusons un peu plus.
Journalisation avec syslogd
Tous les journaux générés par les événements sur un système syslogd sont ajoutés au fichier /var/log/syslog. Mais, selon leurs caractéristiques d'identification, ils peuvent également être envoyés vers un ou plusieurs autres fichiers du même répertoire.
Avec syslogd, la façon dont les messages sont distribués est déterminée par le contenu du 50-default.conf fichier qui vit dans le /etc/rsyslog.d/ annuaire.
Cet exemple de 50-default.conf montre comment les messages de journal marqués comme liés à cron seront écrits dans le fichier cron.log. Dans ce cas, l'astérisque (*) indique à syslogd d'envoyer des entrées avec n'importe quel niveau de priorité (par opposition à un seul niveau comme emerg ou err) :
cron.* /var/log/cron.logTravailler avec les fichiers journaux syslogd ne nécessite aucun outil spécial comme journalctl. Mais si vous voulez vous perfectionner dans ce domaine, vous devez savoir quel type d'informations est conservé dans chacun des fichiers journaux standard.
Le tableau ci-dessous répertorie les fichiers journaux syslogd les plus courants et
leurs fins.
| Nom du fichier | Objectif |
|---|---|
| auth.log | Authentification système et événements de sécurité |
| boot.log | Un enregistrement des événements liés au démarrage |
| dmesg | Événements de tampon en anneau du noyau liés aux pilotes de périphérique |
| dpkg.log | Événements de gestion de packages logiciels |
| kern.log | Événements du noyau Linux |
| syslog | Une collection de tous les journaux |
| wtmp | Suivre les sessions utilisateur (accessibles via les commandes who et last) |
De plus, les applications individuelles écrivent parfois dans leurs propres fichiers journaux. Vous verrez souvent aussi des répertoires entiers comme /var/log/apache2/ ou /var/log/mysql/ créés pour recevoir des données d'application.
La redirection des journaux peut également être contrôlée via l'un des huit niveaux de priorité, en plus du symbole * (pour tous les niveaux de priorité) que vous avez vu auparavant.
| Niveau | Description |
|---|---|
| débogage | Utile pour le débogage |
| infos | Informationnel |
| avis | Conditions normales |
| avertir | Conditions nécessitant des avertissements |
| erreur | Conditions d'erreur |
| critique | Conditions critiques |
| alerte | Action immédiate requise |
| urgence | Système inutilisable |
Gestion des fichiers journaux avec sysglogd
Par défaut, syslogd gère la rotation, la compression et la suppression des journaux en arrière-plan sans aucune aide de votre part. Mais vous devez savoir comment procéder au cas où vous auriez des journaux nécessitant un traitement spécial.
Quel type de traitement spécial une simple bûche pourrait-elle exiger ? Eh bien, supposons que votre entreprise doive se conformer aux règles de déclaration des transactions associées aux normes réglementaires ou industrielles telles que Sarbanes-Oxley ou PCI-DSS. Si les enregistrements de votre infrastructure informatique doivent rester accessibles pendant de plus longues périodes, vous voudrez certainement
savoir se repérer dans les fichiers clés.
Pour voir le système logrotate en action, répertoriez une partie du contenu du répertoire /var/log/. Le fichier auth.log, par exemple, apparaît dans trois formats différents :
- auth.log - La version actuellement active, avec les nouveaux messages d'authentification qui y sont écrits.
- auth.log.1 - Le fichier le plus récent à avoir été mis hors service. Il est conservé dans un format non compressé pour faciliter sa remise en action rapide en cas de besoin.
- auth.log.2.gz - Une ancienne collection (comme vous pouvez le voir à partir de l'extension de fichier .gz dans la liste suivante) qui a été compressée pour économiser de l'espace.
Après sept jours, lorsque la prochaine date de rotation arrivera, auth.log.2.gz sera renommé auth.log.3.gz, auth.log.1 sera compressé et renommé auth.log.2.gz, auth.log deviendra auth.log.1, et un nouveau fichier sera créé et nommé auth.log.
Le cycle de rotation des journaux par défaut est contrôlé dans le fichier /etc/logrotate.conf. Les valeurs illustrées dans cette liste font pivoter les fichiers après une seule semaine active et suppriment les anciens fichiers après quatre semaines.
# rotate log files weekly
weekly
# keep 4 weeks worth of backlogs
rotate 4
# create new (empty) log files after rotating old ones
create
# packages drop log rotation information into this directory
include /etc/logrotate.Le répertoire /etc/logrotate.d/ contient également des fichiers de configuration personnalisés pour gérer la rotation des journaux de services ou d'applications individuels. En listant le contenu de ce répertoire, vous voyez ces fichiers de configuration :
$ ls /etc/logrotate.d/
apache2 apt dpkg mysql-server
rsyslog
samba
unattended-upgradeVous pouvez afficher leur contenu pour voir quel type de configuration ils ont sur la rotation des journaux.
💡De nombreux administrateurs choisissent de rediriger les entrées de journal vers des serveurs de journaux distants spécialement conçus où les données peuvent recevoir toute l'attention spécialisée qu'elles méritent. Cela peut libérer les serveurs d'applications pour leurs tâches immédiates et consolider les données des journaux dans un emplacement central unique et facilement accessible.Comment lire les fichiers syslog
Vous savez que vous avez mieux à faire de votre temps que de lire des millions de lignes d'entrées de journal.
L'utilisation de chat doit être totalement évitée ici. Il va simplement vider des milliers de lignes sur votre écran.
Je suggère d'utiliser grep pour filtrer le texte dans les fichiers.
L'utilisation de la commande tail -f vous permet de lire le fichier journal actuel en temps réel. Vous pouvez le combiner avec grep pour filtrer le texte souhaité.
Dans certains cas, vous devrez peut-être accéder aux anciens journaux compressés. Vous pouvez toujours extraire le fichier en premier, puis utiliser grep, less et d'autres commandes pour lire son contenu, cependant, il existe une meilleure option. Il existe des commandes z telles que zcat, zless, etc. qui vous permettent de travailler sur les fichiers compressés sans les extraire explicitement.
Un exemple pratique d'analyse de log
Voici un exemple évident qui recherchera dans le fichier auth.log des preuves de tentatives de connexion infructueuses. La recherche du mot échec
renvoie toute ligne contenant la phrase échec d'authentification.
Vérifier cela de temps en temps peut vous aider à repérer les tentatives de compromission d'un compte en devinant le mot de passe correct. N'importe qui peut tromper un mot de passe une ou deux fois, mais trop de tentatives infructueuses devraient vous rendre suspect :
$ cat /var/log/auth.log | grep 'Authentication failure'
Sep 6 09:22:21 workstation su[21153]: pam_authenticate: Authentication failureSi vous êtes le genre d'administrateur qui ne fait jamais d'erreurs, cette recherche peut être vide. Vous pouvez vous garantir au moins un résultat en générant manuellement une entrée de journal à l'aide d'un programme appelé logger. Essayez-le en faisant quelque chose comme ceci :
logger "Authentication failure"Vous pouvez également présélectionner une véritable erreur en vous connectant à un compte d'utilisateur et en saisissant le mauvais mot de passe.
Comme vous pouvez le constater, grep a fait le travail pour vous, mais tout ce que vous pouvez voir dans les résultats, c'est qu'il y a eu un échec d'authentification. Ne serait-il pas utile de savoir de quel compte il s'agit ? Vous pouvez développer les résultats renvoyés par grep en lui indiquant d'inclure les lignes immédiatement avant et après la correspondance.
Cet exemple imprime la correspondance avec les lignes qui l'entourent. Il vous indique qu'une personne utilisant le compte david a tenté sans succès d'utiliser su (changer d'utilisateur) pour se connecter au compte studio :
$ cat /var/log/auth.log | grep -C1 failure
Sep 6 09:22:19 workstation su[21153]: pam_unix(su:auth): authentication
failure; logname= uid=1000 euid=0 tty=/dev/pts/4 ruser=david rhost=
user=studio
Sep 6 09:22:21 workstation su[21153]: pam_authenticate:
Authentication failure
Sep 6 09:22:21 workstation su[21153]: FAILED su for studio by davidEt ensuite ?
Connaître les bases est une chose et appliquer les connaissances en est une autre. Cependant, la connaissance des fondamentaux aide dans diverses situations.
Maintenant que vous connaissez l'essentiel des syslogs sous Linux, vous aurez peut-être un peu plus de temps pour gérer les journaux.
Cet article est un extrait du livre Linux in Action de David Clinton. Il est publié par Manning Publication et vous pouvez obtenir 30 % de réduction sur tous les livres de Manning en utilisant le code nlitsfoss22 au moment du paiement.
Livre Linux en actionProfitez de l'apprentissage de Linux.