Catégories
Devops

Rsyslog

Rsyslog est un outil de gestion des logs que l’on retrouve dans une grande partie des distributions Linux.
L’avantage de ce système est qu’il permet de centraliser la gestion des logs en local ou sur le réseau sur un serveur de log car Rsyslog implémente RELP (protocole fiable de journalisation d’évènements).
Un exemple d’application serait de centraliser sur un même serveur de log tous les logs des serveurs web Nginx ce qui rendrait l’analyse et le debugging plus simple (tuto Nginx).

Notions

Pour manipuler Rsyslog il faut comprendre les notions de sélecteurs (et le couple facility priority) ainsi que la notion d’actions:

Sélecteurs

Un sélecteur, est un couple facility.priority qui va déterminer la provenance des logs à traiter.

  • Facility désigne un sous-système applicatif concerné (par ex cron, daemon, auth, mail etc.), c’est une sorte de catégorisation des applications qui seront les sources de l’envoi de logs (liste)
  • Priority désigne la priorité des messages à traiter

Dans la configuration du client, il est possible de spécifier un ensemble de couples facility.priority séparés par des virgules, et/ou des * (joker).

Voir la liste des Facilities et Priorities

Actions

Les actions déterminent simplement la destination des logs.

A chaque sélecteur (ou ensemble de sélecteurs) nous associons une action qui consiste à dire où on souhaite envoyer ces logs (vers un fichier ou vers un serveur de logs).

Configuration

Le fichier de configuration nous permet de spécifier les sélecteurs (le couple facility.priority) et l’action associée.

Il existe un fichier de configuration principal /etc/rsyslog.conf qui peut inclure d’autres fichiers (situés par ex dans /etc/rsyslog.d/) grâce à la directive $IncludeConfig /etc/rsyslog.d/*.conf .

Coté clients

Les clients doivent déterminer s’ils doivent envoyer leurs logs dans un fichier local ou à travers le réseau en TCP ou en UDP, mais surtout indiquer quels logs, à quel niveau de sévérité ils souhaitent envoyer, et où l’envoyer, voici quelques exemples.

logs locaux

cron.*                              /var/log/cron.log
auth,authpriv.err                     /var/log/auth.log
*.*;cron,auth,authpriv.none        -/var/log/syslog
  1. nous souhaitons envoyer tous les niveaux de logs de cron vers le fichier spécifié
  2. nous avons la notation facility1,facility2.priority qui spécifie que les logs de priorité (ici error) des 2 facilities spécifiés partirons vers auth.log
  3. tous les messages en dehors des logs des 3 services spécifiés (par le .none)

logs distants

Pour sélectionner les logs à envoyer (car il est souvent inutile d’envoyer les logs de criticité info par ex) voici des exemples, du plus spécifique au plus général (tout envoyer):

auth.err @monserveurdelog:514
*.notice;*.warn;*.err;*.crit;*.alert;*.emerg @monserveurdelog:514
*.* @monserveurdelog:514
  • *.* : indique d’envoyer tous les logs
  • @ ou @@ : indique d’envoyer en UDP ou TCP
  • monserveurdelog.fr:514 : adresse et port du serveur de logs

Coté serveur

modifier le fichier de façon à permettre la réception des logs en UDP et/ou TCP:

$ModLoad imudp
$UDPServerRun 514
$ModLoad imtcp
$InputTCPServerRun 514

puis paramétrer la whiteliste d’IP autorisés etc.

Voir doc Debian.

Troubleshooting

logger le CLI

Pour tester si notre configuration fonctionne bien et que le client envoi bien ses erreurs au serveur (ou en local), il est possible de générer une fausse erreur via la commande logger :

logger -p authpriv.alert "ca fonctionne 🤜🤛"

log automatique au reboot

Il est possible d’utiliser une fonctionnalité de crontab le @reboot qui permet d’indiquer à crontab d’exécuter la commande suivante au reboot de la machine uniquement. Cela permet d’avoir une vision clair des reboot intempestif ou non de nos machine

@reboot /bin/sleep 30; /usr/bin/logger -p cron.notice "💥 Reboot de $(hostname) il y a 30 sec"

Documentation

source

Liste des Facilities

auth/authpriv 	# concernent l'authentification
cron 		# provient des services de planification de tâches, cron et atd
daemon 		# concerne un démon sans classification particulière (serveur DNS, NTP, etc.)
ftp 		# concerne le serveur FTP
kern 		# message provenant du noyau
lpr 		# provient du sous-système d'impression
mail 		# provient de la messagerie électronique
news 		# message du sous-système Usenet (notamment du serveur NNTP — Network News Transfer Protocol, ou protocole de transfert des nouvelles sur le réseau — gérant les forums de discussion)
syslog 		# message du serveur syslogd lui-même
user 		# messages utilisateur (générique)
uucp 		# messages du sous-système UUCP (Unix to Unix Copy Program, ou programme de copie d'Unix à Unix, un vieux protocole employé pour faire circuler entre autres des messages électroniques)
local0 à local7 # réservés pour les utilisations locales. 

Liste des Priorities

emerg 		# « Au secours ! » le système est probablement inutilisable .
alert 		# vite, il y a péril en la demeure, des actions doivent être entreprises immédiatement
crit 		# les conditions sont critiques
err 		# erreur
warn 		# avertissement (erreur potentielle)
notice 		# condition normale mais message significatif
info 		# message informatif
debug 		# message de débogage