20.8. Journalisation structurée avec Rsyslog

Sur les systèmes produisant de grandes quantités de données de journalisation, il est plus pratique de maintenir les messages journaux sous un format structuré. Avec des messages structurés, il est plus facile de rechercher des informations particulières, de produire des statistiques et de gérer les changements et incohérences dans la structure du message. Rsyslog utilise le format JSON (« JavaScript Object Notation ») pour la structure des messages journaux.
Comparez le message journal non structuré suivant :
Oct 25 10:20:37 localhost anacron[1395]: Jobs will be executed sequentially
Avec un message structuré :
{"timestamp":"2013-10-25T10:20:37", "host":"localhost", "program":"anacron", "pid":"1395", "msg":"Jobs will be executed sequentially"}
Rechercher des données structurées en utilisant des paires clé-valeur est plus rapide et plus précis qu'effectuer des recherches de fichiers texte avec des expressions régulières. La structure permet également de rechercher la même entrée dans des messages produits par différentes applications. Les fichiers JSON peuvent aussi être stockés dans une base de données de documents, comme MongoDB, qui fournit de meilleures performances et capacités d'analyses. D'autre part, un message structuré requiert davantage d'espace disque qu'un message non structuré.
Dans rsyslog, les messages journaux avec des métadonnées sont extraits de Journal à l'aide du module imjournal. Avec le module mmjsonparse, vous pouvez analyser des données importées de Journal et d'autres sources, puis les traiter davantage, par exemple en tant que sortie de base de données. Pour que l'analyse réussisse, mmjsonparse requiert que les messages d'entrée soient structurés d'une manière définie par le projet Lumberjack.
Le projet Lumberjack vise à ajouter la journalisation structurée à rsyslog de manière rétro-compatible. Pour identifier un message structuré, Lumberjack spécifie la chaîne @cee: qui ajoute la structure JSON au début. Lumberjack définit également la liste des noms de champ standard devant être utilisés pour les entités dans la chaîne JSON. Pour obtenir davantage d'informations sur Lumberjack, veuillez consulter la section intitulée « Documentation en ligne ».
Ci-dessous figure un exemple de message formaté lumberjack :
 @cee: {"pid":17055, "uid":1000, "gid":1000, "appname":"logger", "msg":"Message text."} 
Pour créer cette structure dans Rsyslog, un modèle est utilisé, veuillez consulter la Section 20.8.2, « Filtrer des messages structurés ». Les applications et serveurs peuvent utiliser la bibliothèque libumberlog pour générer des messages sous un format compatible avec lumberjack. Pour obtenir davantage d'informations sur libumberlog, veuillez consulter la section intitulée « Documentation en ligne ».

20.8.1. Importer des données de Journal

Le module imjournal est le module d'entrée de Rsyslog permettant de lire les fichiers journaux de manière native (consultez la Section 20.7, « Interaction de Rsyslog et de Journal »). Les messages Journal sont ensuite journalisés en format texte comme les autres messages rsyslog. Cependant, avec un traitement supplémentaire, il est possible de traduire les métadonnées fournies par Journal en message structuré.
Pour importer les données de Journal sur Rsyslog, veuillez utiliser la configuration suivante dans le fichier /etc/rsyslog.conf :
$ModLoad imjournal

$imjournalPersistStateInterval number_of_messages
$imjournalStateFile path
$imjournalRatelimitInterval seconds
$imjournalRatelimitBurst burst_number
$ImjournalIgnorePreviousMessages off/on
  • Avec number_of_messages, il est possible de spécifier la fréquence à laquelle les données Journal doivent être enregistrées. Ceci se produit chaque fois que le nombre spécifié de messages est atteint.
  • Remplacez path par un chemin vers le fichier d'état. Ce fichier surveille la dernière entrée de journal traitée.
  • Avec seconds, il est possible de définir la longueur de l'intervalle de limite du taux. Le nombre de messages traités pendant cet intervalle ne peut pas dépasser la valeur spécifiée dans burst_number. Le paramètre par défaut s'élève à 20,000 messages pour 600 secondes. Rsyslog abandonne les messages arrivant après la rafale maximale dans le délai spécifié.
  • Avec $ImjournalIgnorePreviousMessages, vous pouvez ignorer les messages se trouvant actuellement dans le Journal et importer les nouveaux messages uniquement, ce qui est utilisé lors qu’aucun fichier d'état n'est spécifié. Le paramètre par défaut est « off ». Veuillez remarquer que si ce paramètre est inactif et qu'il n'y a pas de fichier d'état, tous les messages dans le Journal sont traités, même s'ils ont déjà été traités dans une session rsyslog précédente.

Note

Vous pouvez utiliser imjournal simultanément avec le module imuxsock qui est l'entrée de journal système traditionnelle. Cependant, pour éviter la duplication de messages, vous devez empêcher imuxsock de lire le socket du système du Journal. Pour cela, veuillez utiliser la directive $OmitLocalLogging :
$ModLoad imuxsock
$ModLoad imjournal

$OmitLocalLogging on
$AddUnixListenSocket /run/systemd/journal/syslog
Vous pouvez traduire toutes les données et métadonnées stockées par le Journal en messages structurés. Certaines entrées de métadonnées sont répertoriées dans l'Exemple 20.19, « Sortie détaillée de journalctl ». Pour une liste complète des champs de Journal, veuillez consulter la page man de systemd.journal-fields(7). Par exemple, il est possible de se concentrer sur les champs de journal du noyau, qui sont utilisés par des messages provenant du noyau.

20.8.2. Filtrer des messages structurés

Pour créer un message formaté lumberjack requis par le module d'analyse rsyslog, utilisez le modèle suivant :
template(name="CEETemplate" type="string" string="%TIMESTAMP% %HOSTNAME% %syslogtag% @cee: %$!all-json%\n")
Ce modèle ajoute la chaîne @cee: au début de la chaîne JSON et peut être appliqué, par exemple, pendant la création d'un fichier de sortie avec le module omfile. Pour accéder aux noms de champ JSON, veuillez utiliser le préfixe $!. Ainsi, la condition de filtre suivante recherche des messages avec un nom d'hôte et un UID spécifique :
($!hostname == "hostname" && $!UID== "UID")

20.8.3. Analyser JSON

Le module mmjsonparse est utilisé pour analyser les messages structurés. Ces messages peuvent provenir de Journal ou d'autres sources d'entrées, et doivent être formatés d'une manière définie par le projet Lumberjack. Ces messages sont identifiés par la présence de la chaîne @cee:. mmjsonparse vérifie si la structure JSON est valide, puis le message est analysé.
Pour analyser des messages JSON formatés lumberjack avec mmjsonparse, veuillez utiliser la configuration suivante dans le fichier /etc/rsyslog.conf :
$ModLoad mmjsonparse

*.* :mmjsonparse:
Dans cet exemple, le module mmjsonparse est chargé sur la première ligne, puis tous les messages y sont transférés. Aucun paramètre de configuration n'est actuellement disponible pour mmjsonparse.

20.8.4. Stocker des messages dans MongoDB

Rsyslog prend en charge le stockage des journaux JSON dans la base de données de documents MongoDB à travers le module de sortie ommongodb.
Pour transférer des messages journaux dans MongoDB, veuillez utiliser la syntaxe suivante dans le fichier /etc/rsyslog.conf (les paramètres de configuration de ommongodb sont uniquement disponibles sous le nouveau format de configuration ; veuillez consulter la Section 20.3, « Utiliser le nouveau format de configuration ») :
$ModLoad ommongodb

*.* action(type="ommongodb" server="DB_server" serverport="port" db="DB_name" collection="collection_name" uid="UID" pwd="password")
  • Remplacez DB_server par le nom ou l'adresse du serveur MongoDB. Spécifiez port pour sélectionner un port non standard du serveur MongoDB. La valeur port par défaut est 0, et il n'est pas habituellement nécessaire de modifier ce paramètre.
  • Avec DB_name, il est possible d'identifier la base de données sur le serveur MongoDB sur laquelle vous souhaitez diriger la sortie. Remplacez collection_name par le nom d'une collection dans cette base de données. Dans MongoDB, une collection est un groupe de documents, l'équivalent d'une table RDBMS.
  • Vous pouvez définir vos détails de connexion en remplaçant l'UID et le mot de passe.
Vous pouvez façonner la forme de la sortie finale de la base de données en utilisant des modèles. Par défaut, rsyslog utilise un modèle basé sur les noms de champs lumberjack standard.