Quand plusieurs machines produisent des journaux, retrouver un incident dans des fichiers dispersés devient vite un travail minutieux. Rsyslog complète journald avec des règles de filtrage, des destinations variées et le transfert des journaux vers un point central. Ce guide vous aide à choisir une configuration adaptée, à la tester et à éviter les pièges classiques avant de mettre en place un serveur de logs.
L’article en bref
Rsyslog transforme les journaux Linux en données plus faciles à trier, transmettre et exploiter. Voici les étapes essentielles pour construire une configuration claire et vérifier son fonctionnement.
- Choisir le bon rôle : Comprenez comment Rsyslog complète journald et quand l’utiliser.
- Poser les bases : Installez le service et validez ses fichiers de configuration.
- Trier les événements : Filtrez les messages selon leur origine et leur gravité.
- Centraliser avec méthode : Transférez les journaux et sécurisez leur réception.
Une configuration testée étape par étape rend la collecte des logs plus fiable et plus simple à dépanner.
Rsyslog et journald : choisir la bonne configuration des logs
Sur les systèmes Linux utilisant systemd, journald collecte les événements des services et du noyau. Rsyslog peut récupérer ces messages et leur donner une suite : filtrage, écriture dans des fichiers, transfert vers un serveur distant ou alimentation d’une plateforme d’analyse.
Les deux outils ne s’opposent donc pas nécessairement. Pour une machine isolée, journald peut suffire ; lorsque plusieurs serveurs doivent partager une politique de collecte, Rsyslog apporte des règles et des sorties particulièrement souples. Imaginez une petite équipe informatique qui suit trois serveurs web : regrouper les journaux d’authentification et les erreurs applicatives facilite la comparaison après un incident.
Syslog, dont les premières spécifications remontent aux années 1980, a posé les bases de la transmission des messages système. Rsyslog, développé par Rainer Gerhards au début des années 2000, a étendu cet usage avec des modules, plusieurs protocoles et des mécanismes de filtrage plus fins. En pratique, le choix dépend surtout du nombre de machines, des besoins d’archivage et des outils d’analyse déjà en place.
Installer Rsyslog et vérifier les fichiers de configuration
Rsyslog est disponible dans les dépôts des principales distributions. Sur Debian ou Ubuntu, installez-le avec sudo apt install rsyslog. Sur Fedora, RHEL, Rocky Linux ou AlmaLinux, utilisez généralement sudo dnf install rsyslog ; les versions plus anciennes peuvent encore employer yum.
Vérifiez ensuite l’état du service avec sudo systemctl status rsyslog, puis activez son lancement au démarrage si nécessaire avec sudo systemctl enable –now rsyslog. La configuration principale se trouve dans /etc/rsyslog.conf ; les fichiers placés dans /etc/rsyslog.d/ sont également lus, ce qui permet de séparer les règles par usage.
Avant une modification, gardez une copie du fichier concerné. Pour contrôler la syntaxe sans redémarrer le service, lancez sudo rsyslogd -N1 : cette vérification repère notamment les directives mal formées. C’est l’équivalent d’un montage à blanc avant de coller une pièce de maquette : quelques secondes de contrôle évitent une remise en état plus longue.
La configuration est généralement organisée autour du chargement des modules, des directives globales et des règles de traitement. Les noms de modules indiquent souvent leur fonction : imuxsock reçoit des messages locaux, imjournal lit journald, tandis que imtcp et imudp reçoivent des messages réseau.
Filtrer et rediriger les journaux avec des règles Rsyslog
Une règle classique associe une facility — la catégorie du message, comme auth, kern ou mail — à une severity, c’est-à-dire son niveau de gravité, puis à une destination. Cette logique permet, par exemple, de séparer les événements d’authentification des messages généraux du système.
| Facility | Type d’événements | Exemple d’usage |
|---|---|---|
| auth, authpriv | Authentification et sécurité | Suivre les connexions et les refus d’accès |
| kern | Messages du noyau Linux | Repérer des alertes liées au matériel ou aux pilotes |
| daemon | Services et processus système | Surveiller les démons et services d’arrière-plan |
| mail, cron | Messagerie et tâches planifiées | Contrôler les envois et les exécutions récurrentes |
| local0 à local7 | Catégories réservées aux usages locaux | Classer les événements d’une application spécifique |
Dans le format traditionnel, authpriv.* /var/log/auth.log envoie les messages d’authentification vers un fichier dédié, tandis que *.err /var/log/syslog-errors.log retient les erreurs et les niveaux plus graves. Selon la distribution, les fichiers habituels et les règles déjà installées diffèrent : vérifiez les règles existantes avant d’ajouter une destination, afin d’éviter les doublons.
Une règle de filtrage moderne peut aussi s’écrire avec un bloc conditionnel. Par exemple, if $programname == ‘sshd’ then /var/log/sshd.log dirige les messages associés à sshd vers un fichier distinct. Les droits de lecture de ce fichier doivent rester limités, car les journaux de sécurité peuvent révéler des informations sensibles.
Rsyslog n’assure pas à lui seul la rotation habituelle des fichiers écrits sur disque. Sur la plupart des distributions, logrotate archive, compresse et supprime les anciens journaux selon une politique configurée, souvent dans /etc/logrotate.d/rsyslog. Une règle bien triée n’est utile que si l’espace disque et la durée de conservation sont également maîtrisés.
Centralisation des journaux : configurer un serveur de logs
La centralisation des journaux donne aux équipes un point de consultation commun pour comparer les incidents et conserver une copie séparée des machines sources. Elle améliore la visibilité, mais ne remplace ni les sauvegardes ni les contrôles d’accès. Un serveur central doit être dimensionné selon le volume reçu, le débit réseau et la durée de rétention attendue : les besoins d’un petit parc ne sont pas ceux d’une infrastructure à fort trafic.
Sur le serveur, activez la réception TCP dans un fichier dédié, par exemple /etc/rsyslog.d/10-remote.conf. Les directives de base sont module(load= »imtcp ») et input(type= »imtcp » port= »514″). TCP offre une transmission plus fiable qu’UDP, même s’il ne garantit pas à lui seul la livraison après toute panne ; les files d’attente et la supervision restent importantes pour les environnements sensibles.
Pour séparer les sources, une règle peut construire le chemin à partir du nom d’hôte : template(name= »RemoteLogs » type= »string » string= »/var/log/remote/%HOSTNAME%/syslog.log »), puis *.* ?RemoteLogs. Créez ou vérifiez le répertoire de destination et ses permissions, puis limitez l’accès réseau au port choisi dans le pare-feu. Sur un serveur exposé à des réseaux non maîtrisés, ne laissez pas une réception non chiffrée accessible sans restriction.
Du côté client, la ligne *.* @@adresse-du-serveur:514 envoie tous les messages par TCP ; un seul arobase, @, désigne UDP. Remplacez l’adresse par le nom DNS ou l’adresse IP du collecteur. Vous pouvez aussi limiter le transfert à une catégorie ou à un programme, afin de réduire le bruit et le volume transmis.
Sécuriser le transfert des journaux
Les journaux peuvent contenir des noms de comptes, des adresses ou des informations utiles à un attaquant. Pour renforcer la sécurité informatique, privilégiez TLS sur les réseaux non fiables, protégez les clés privées et vérifiez l’identité du serveur au lieu de vous reposer sur un mode anonyme. La configuration TLS dépend des modules disponibles et des certificats : suivez la documentation correspondant à la version installée plutôt que de recopier un exemple générique sans l’adapter.
Ajoutez aussi une règle de pare-feu limitée aux machines clientes attendues, appliquez des permissions strictes aux fichiers reçus et surveillez l’espace disponible. Une bonne politique de centralisation associe donc chiffrement, contrôle d’accès, rotation et rétention définie.
Personnaliser les messages avec les templates Rsyslog
Un template définit la forme des messages écrits ou transmis. Il peut inclure l’heure, le nom d’hôte, le programme d’origine et le contenu du message, pour faciliter la lecture humaine ou l’ingestion par un outil d’analyse. Dans la syntaxe moderne, les propriétés sont généralement définies avec property(), plutôt qu’en assemblant directement des variables entourées de pourcentages.
Voici un exemple simple de template texte : template(name= »FormatSimple » type= »list ») { property(name= »timereported » dateFormat= »rfc3339″) constant(value= » « ) property(name= »hostname ») constant(value= » « ) property(name= »programname ») constant(value= »: « ) property(name= »msg ») constant(value= »n ») }. Pour l’utiliser, associez son nom à une action d’écriture dans un fichier, en vérifiant la syntaxe adaptée à la version de Rsyslog et aux règles déjà présentes.
Pour une plateforme qui attend du JSON, un template de type liste avec des propriétés au format JSON aide à produire des champs structurés. Avant de l’envoyer vers Elasticsearch, Splunk ou un autre outil, testez le résultat avec quelques messages : un JSON valide doit rester valide même si le contenu d’un message comporte des guillemets ou des caractères spéciaux.
Tester la collecte des logs et dépanner Rsyslog
Après chaque changement, contrôlez d’abord les fichiers de configuration avec sudo rsyslogd -N1, puis redémarrez le service avec sudo systemctl restart rsyslog. Sur une machine cliente, la commande logger -p user.notice « Test de centralisation Rsyslog » produit un message identifiable que vous pouvez rechercher dans le fichier attendu ou sur le serveur central.
Si le message n’arrive pas, procédez dans l’ordre : vérifiez que le service est actif, que la règle de transfert est chargée, que le serveur écoute sur le bon port et que le pare-feu autorise la connexion. Consultez ensuite le journal du service avec sudo journalctl -u rsyslog. Ce dépannage Rsyslog méthodique distingue rapidement une erreur de syntaxe d’un problème réseau ou de permissions.
- La configuration est-elle valide ? Exécutez rsyslogd -N1 avant le redémarrage.
- Le service fonctionne-t-il ? Contrôlez son état avec systemctl et ses messages avec journalctl.
- Le port répond-il ? Vérifiez l’écoute du serveur et les règles du pare-feu.
- Le fichier est-il accessible ? Contrôlez son chemin, son propriétaire et ses permissions.
- La règle correspond-elle au message ? Testez la facility, la severity et le programme émetteur.
Pour un parc en croissance, ajoutez progressivement la supervision des files d’attente et du stockage. Les logs n’ont de valeur que s’ils restent disponibles au moment où une panne ou une anomalie doit être comprise.
Questions fréquentes sur la configuration Rsyslog
Rsyslog remplace-t-il journald ?
Pas nécessairement. Sur les systèmes Linux avec systemd, journald collecte les événements locaux et Rsyslog peut les récupérer pour les filtrer, les écrire dans des fichiers ou les transmettre à distance.
Faut-il choisir TCP ou UDP pour le transfert des journaux ?
TCP est généralement préférable lorsque la fiabilité compte, car il gère les connexions et les erreurs de transmission. UDP peut convenir à certains usages peu sensibles à la perte de messages, mais il n’offre pas les mêmes garanties.
Comment vérifier rapidement une règle Rsyslog ?
Validez d’abord la syntaxe avec sudo rsyslogd -N1, redémarrez le service, puis générez un événement de test avec logger. Vérifiez ensuite le fichier de destination ou le serveur central.
Rsyslog effectue-t-il la rotation des fichiers ?
Pour les fichiers locaux, la rotation est généralement gérée par logrotate, et non par Rsyslog lui-même. Vérifiez la configuration de rotation, la compression et la durée de conservation prévues par votre système.
