Quand j’étais enfant, les samedis étaient les jours où mon père travaillait sur la voiture. Il ouvrait le capot et regardait à l’intérieur de manière significative. Il avait déjà une idée de ce qui devait être réglé ou réparé parce qu’il écrivait des journaux. Il tenait un registre méticuleux de sa consommation d’essence, des vidanges d’huile, des remplacements de filtres et de tuyaux, etc. Il connaissait l’âge, la qualité et les attentes en matière de service des pièces de sa voiture parce qu’il enregistrait toutes ces informations.
Comme je le fais avec ma brillante boîte Linux, mon père tenait des journaux des performances de sa voiture. Mais alors qu’il écrivait dans un nombre infini de cahiers à reliure spirale, mon ordinateur rassemble automatiquement mes données de journal. Par défaut, Linux utilise le démon syslog pour enregistrer des journaux sur la façon dont le système fonctionne, en les plaçant dans un dépôt central (/var/log) où je peux les examiner.
C’est tout ce que les démons comme syslog, rsyslog et syslog-ng sont vraiment : Des services qui enregistrent des données sur mon système, en postant ces données à un endroit où je peux ouvrir les journaux et y jeter un œil.
Si vous êtes nouveau dans l’administration de votre propre système, il est bon de connaître ces différents démons. Vous pourriez décider que le syslog par défaut vous sert très bien, ou peut-être que rsyslog ou syslog-ng, avec leurs fonctionnalités plus avancées, sont de meilleurs choix.
Syslog est l’original. Son nom seul peut être un obstacle pour le nouvel administrateur car il y a syslog le démon, syslog le protocole et syslog le message. Le démon syslog écoute les messages sur le socket syslog et crée ensuite une entrée dans le fichier journal approprié. Il utilise le format syslog pour les champs et les données du message. Voici un exemple de message syslog concernant une tentative de connexion échouée :
<>1 2003-10-11T22:14:15.003Z server1.com sshd – – pam_unix(sshd:auth) : authentication failure ; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.0.2.2
Vous pouvez en savoir plus sur les champs de messages syslog dans cet article : Notions de base de la journalisation Linux.
Syslog crée des fichiers journaux qui sont techniquement lisibles. Il suffit de savoir ce que tous les champs représentent et la signification de leurs valeurs. Franchement, à moins que vous ne vouliez avoir la crédibilité de manier les outils de nos ancêtres sur vos systèmes Linux, je vous encourage à regarder plutôt rsyslog.
Rsyslog s’appuie sur syslog, en lui donnant de la flexibilité. Vous le configurez dans un langage appelé RainerScript, et l’une des premières choses que vous voulez probablement faire est d’indiquer à rsyslog où envoyer vos données de journal. Dans cet exemple, nous envoyons nos données de journal à un serveur appelé BEBOP.
action(type= »omfwd » protocol= »tcp » target= »BEBOP » port= »514″)
Puisque votre système est probablement venu avec rsyslog déjà chargé et configuré, diriger les données de journal vers un serveur particulier pourrait être toute la configuration que vous devez faire.
Jusqu’à ce que votre disque de données de journal soit plein, c’est-à-dire. C’est pourquoi vous pourriez vouloir configurer une tâche cron pour logrotate, qui tronque les fichiers journaux vieillissants et les archive. Sans rotation des journaux, rsyslog continue à collecter les données de journal, les tronquant, écrasant les données plus anciennes, et si tout va mal, allant jusqu’à planter votre système lorsque le disque devient plein. L’anarchie !
Alternativement, vous pouvez configurer rsyslog pour envoyer toutes vos données de log à une solution de gestion des logs comme Loggly, qui archive vos données et vous les présente de manière à ce que vous puissiez facilement les rechercher et les analyser. Pas l’anarchie !
Entre syslog et rsyslog, syslog-ng est arrivé pour ajouter plus de fonctionnalités au démon syslog. Il possède d’excellentes capacités de filtrage. Il peut filtrer les messages de journal en fonction de leur contenu, et pas seulement sur des champs comme l’horodatage. Lorsque j’examine des milliers de messages de journal, pouvoir mettre à zéro ma recherche sur un contenu spécifique fait la différence entre résoudre mon problème et traiter mon système de noms peu amènes.
Syslog-ng traite automatiquement les messages de journal dans un référentiel central et leur applique un filtrage complexe. Syslog-ng peut même analyser vos données de journal en messages JSON, que vous pouvez utiliser dans un outil de gestion des journaux comme Loggly. Voyez comme il est facile de voir d’un coup d’œil qui s’est connecté à votre système et à quelle fréquence ! Trop cool !
Pour en revenir à ma petite machine Linux, syslog-ng a plus que ce que j’utilise. Ce système est l’endroit où j’écris, stockant mon travail dans le cloud. Je ne gère pas de centres de données ni même de multiples utilisateurs. C’est juste mon propre équivalent de la voiture de papa, je la règle de temps en temps, je la répare quand elle est un peu en panne. J’utilise rsyslog parce que c’est ce qui est sur mon système. Je ne suis ni un amateur ni un administrateur système, donc « parce que c’est ce qu’il y a sur mon système » est un bon choix pour moi. Vos propres besoins sont probablement différents.