Introduction à rsyslog
1. Le rôle de syslog et ses limites
Qu'est-ce que syslog ?
syslog est un protocole et un service de journalisation standard pour les systèmes Unix/Linux (et certains systèmes BSD).
Son rôle est de :
- Collecter les messages de log générés par diverses applications, daemons ou services du système. Sur le système et depuis d'autres machines du réseau.
- Les enregistrer dans des fichiers appropriés (généralement dans /var/log).
- Les envoyer (ou transmettre) à d'autres machines distantes si on le souhaite.
De nombreux services se reposent sur syslog pour archiver les événements (authentification, kernel, applications, etc.).
Cependant, le démon syslog traditionnel (comme syslogd ou syslog-ng) peut avoir des limites en termes de performances, de flexibilité et de fonctionnalités avancées (filtrage granulaire, modularité, formats, etc.).
2. Présentation générale de rsyslog
Qu'est-ce que rsyslog ?
rsyslog (Rocket-fast System for Log Processing) est un démon de journalisation qui vient souvent remplacer ou compléter le syslog historique.
Il a été introduit pour apporter :
- Une meilleure performance : il est multi-threadé et peut traiter un grand volume de logs plus rapidement.
- Une meilleure modularité : il est extensible via des modules (imptcp, ommysql, omkafka, etc.).
- De nouvelles fonctionnalités de filtrage et de routage : possibilité de filtrer selon le contenu, l'origine, le programme, etc.
- Des formats avancés : JSON, structures personnalisées, etc.
- Des destinations multiples : bases de données (MySQL, PostgreSQL), files Kafka, services cloud, etc.
Architecture générale
- Entrée : Les messages proviennent de sources locales (via /dev/log, journald) ou distantes (TCP/UDP/syslog, protocoles propriétaires).
- Traitement / filtrage : rsyslog applique des règles et filtres sur la base des propriétés de chaque log (priorité, facility, contenu...).
- Sortie : Les messages validés sont ensuite redirigés vers différentes cibles (fichiers, bases de données, systèmes distants...).
3. Installation et configuration de base
Installation
Sur la majorité des distributions Linux récentes, rsyslog est installé par défaut. Sinon, on peut l'installer via le gestionnaire de paquets :
apt update
apt install rsyslog -y
Fichiers de configuration
- Le fichier principal de configuration : /etc/rsyslog.conf.
- Les fichiers de configuration additionnels : souvent dans /etc/rsyslog.d/.
- Les fichiers de log par défaut sont généralement dans /var/log/.
La configuration de base ressemble souvent à :
# /etc/rsyslog.conf
# Module d'entrée (exemple) : permet d'écouter sur le socket local
module(load="imuxsock") # pour les logs système
module(load="imjournal") # pour les logs du journal systemd
# Modules de transport
module(load="imudp") # pour écouter en UDP
input(type="imudp" port="514")
module(load="imtcp") # pour écouter en TCP
input(type="imtcp" port="514")
# Règles de filtrage simples
*.info;mail.none;authpriv.none;cron.none /var/log/messages
authpriv.* /var/log/secure
mail.* -/var/log/maillog
# Exemple de log distant
*.* @@logs.serveur-distant.local:10514 # envoi en TCP (notation @@)
Démarrer et activer rsyslog
- Debian / Ubuntu (avec systemd) :
systemctl enable rsyslog
systemctl start rsyslog
systemctl enable rsyslog
systemctl start rsyslog
4. Les avantages et intérêts de rsyslog
- Performance et multithreading
rsyslog est capable de gérer un grand volume de messages avec un traitement parallèle. Dans des environnements critiques (serveurs de production, SI à forte volumétrie), c'est un atout considérable.
- Excellente modularité
L'architecture de rsyslog est basée sur des modules (entrées, sorties, parsers, etc.). On peut ainsi :
- Ajouter ou supprimer des plugins selon les besoins.
- Gérer de nombreux protocoles d'entrée (imtcp, imudp, imrelp, etc.).
- Envoyer les logs vers de multiples destinations (bases SQL, Kafka, Elasticsearch, etc.).
- Filtrage et routage très flexibles
rsyslog permet un filtrage avancé basé sur :
- Les priorités et catégories syslog (authpriv.*, mail.*, kern.*, etc.).
- Le contenu du message (regex, propriétés, tags).
- La structure JSON (si les messages sont au format JSON).
On peut donc construire un routage logique élaboré, envoyer certaines logs à un serveur distant précis, tout en stockant d'autres logs localement.
- Support de formats enrichis
Au-delà du format syslog classique, rsyslog sait parser et générer du JSON, ce qui facilite l'intégration avec des outils d'analyse (ELK/Elastic Stack par exemple).
- Centralisation des logs
- On peut configurer un serveur rsyslog central qui reçoit les journaux de dizaines, voire de centaines de serveurs.
- La centralisation facilite l'analyse, la corrélation, et permet une meilleure traçabilité en cas d'incident ou d'audit.
- Fiabilité et tolérance aux pannes
- Protocoles fiables (TCP, RELP) pour ne pas perdre de messages.
- Possibilité de bufferiser en local si le serveur distant est indisponible (délai de reconnexion, etc.).
- Sécurité
- Chiffrement TLS/SSL possible pour la transmission de logs critiques.
- Gestion granulaire des droits d'écriture (notamment dans des environnements multi-utilisateurs).
5. Cas d'usage et configuration avancée
5.1. Mise en place d'un serveur de logs centralisé
Sur le serveur central (récepteur)
Activer l'écoute en TCP/UDP :
# /etc/rsyslog.conf
module(load="imudp")
input(type="imudp" port="514")
module(load="imtcp")
input(type="imtcp" port="514")
# Optionnel : loguer ce qui arrive dans /var/log/remote/
template(name="RemoteFormat" type="string"
string="/var/log/remote/%HOSTNAME%/%syslogfacility-text%.log")
*.* ?RemoteFormat
Ouvrir le port 514 (UDP/TCP) dans le firewall si nécessaire :
sudo ufw allow 514/udp
sudo ufw allow 514/tcp
Sur les clients (envoyeurs)
Transmettre les logs au serveur rsyslog central :
# /etc/rsyslog.conf
*.* @@mon-serveur-logs.local:514 # @@ pour TCP, @ pour UDP
Redémarrer le service rsyslog :
sudo systemctl restart rsyslog
5.2. Stockage dans une base de données SQL
- Charger le module de sortie MySQL (ommysql) ou PostgreSQL (ompgsql).
- Définir les tables attendues (rsyslog propose des scripts SQL de création de tables).
- Configurer la règle d'écriture :
module(load="ommysql")
# Ex : pour envoyer tout dans une base MySQL
*.* :ommysql:serveur_bdd,nom_de_la_base,utilisateur,motdepasse
5.3. Filtrage avancé avec expressions
if ($programname == "sshd") then {
/var/log/sshd.log
stop
}
On peut utiliser des expressions, regex, comparaisons de champs, etc., pour un contrôle fin.
5.4. Envoi vers une stack de logs (Elasticsearch/Kibana)
- Charger le module approprié (par ex. omelasticsearch).
- Envoyer les messages en JSON.
- Permet une visualisation avancée et une recherche dans Kibana.
6. Conclusion
rsyslog est devenu un standard de facto dans beaucoup de distributions Linux grâce à :
- Sa haute performance (multithreading, buffers).
- Ses capacités de filtrage et d'enrichissement des logs.
- Sa modularité (plugins multiples d'entrée et de sortie).
- Son intégration facilitée avec des solutions de stockage et d'analyse.
En centralisant les logs avec rsyslog, vous pouvez :
- Simplifier les audits et la supervision.
- Gagner du temps en cas d'incident ou de débogage.
- Gérer efficacement un grand volume de logs (notamment dans des environnements distribués).
C'est un outil puissant et personnalisable qui s'adapte aussi bien aux besoins d'un petit serveur qu'à un écosystème très large (cluster, containers, microservices, etc.).
On profite généralement de sa flexibilité pour construire son propre pipeline de logs ou l'intégrer dans une solution plus complète comme l'Elastic Stack, Splunk ou Grafana Loki.