SupportConsoleDéveloppeursCommencer un essaiContact

20.2. Configuration de base de Rsyslog

Le fichier de configuration principal de rsyslog est /etc/rsyslog.conf. Vous pouvez y spécifier des directives globales, des modules, et des règles consistant en une partie « filter » (filtre) et une partie « action ». Vous pouvez également ajouter des commentaires sous la forme d'un texte suivant un caractère dièse (#).

20.2.1. Filtres

Une règle est spécifiée par une partie filtre, qui sélectionne un sous-ensemble de messages syslog, et une partie action, qui spécifie quoi faire avec les messages sélectionnés. Pour définir une règle dans votre fichier de configuration /etc/rsyslog.conf, définissez un filtre et une action, un par ligne, et séparez-les par un ou plusieurs espaces ou par une ou plusieurs tabulations.
rsyslog offre diverses manières de filtrer les messages syslog en fonction des propriétés sélectionnées. Les méthodes de filtrage disponibles peuvent être divisées en filtres basés Facility/Priorité, basés Propriété, et basés Expression.
Filtres basés Facility/Priorité
La manière la plus utilisée et la plus connue de filtrer des messages syslog consiste à utiliser les filtres basés facility/priorité (type/priorité), qui filtrent les messages syslog en se basant sur deux conditions : facility (ou type) et priorité séparés par un point. Pour créer un sélecteur, veuillez utiliser la syntaxe suivante : 
FACILITY.PRIORITY
où :
  • FACILITY spécifie le sous-système produisant un message syslog particulier. Par exemple, le sous-système mail gère tous les messages syslog concernant le courrier. FACILITY peut être représenté par l'un des mots-clés suivants (ou par un code numérique) : kern (0), user (1), mail (2), daemon (3), auth (4), syslog (5), lpr (6), news (7), uucp (8), cron (9), authpriv (10), ftp (11), et local0 via local7 (16 - 23).
  • PRIORITY spécifie la priorité d'un message syslog. PRIORITY peut être représenté par l'un des mots-clés suivants (ou par un numéro) : debug (7), info (6), notice (5), warning (4), err (3), crit (2), alert (1), et emerg (0).
    La syntaxe susmentionnée sélectionne les messages syslog avec la priorité définie ou avec une priorité supérieure. En faisant précéder tout mot-clé de priorité par le caractère égal (=), vous spécifiez que seuls les messages syslog avec la priorité spécifiée seront sélectionnés. Toutes les autres priorités seront ignorées. De même, faire précéder un mot-clé de priorité par un point d'exclamation (!) sélectionne tous les messages syslog sauf ceux dont la priorité est définie.
En plus des mots-clés spécifiés ci-dessus, vous pouvez également utiliser un astérisque (*) pour définir tous les types (« Facilities ») ou priorités (selon l'endroit où vous placez l'astérisque, avant ou après la virgule). Spécifier le mot-clé de priorité none (aucun) sert aux types sans priorité donnée. Les conditions du type et de la priorité ne respectent pas la casse.
Pour définir de multiples types et priorités, veuillez les séparer par une virgule (,). Pour définir de multiples sélecteurs sur une seule ligne, séparez-les avec un point-virgule (;). Remarquez que chaque sélecteur dans le champ des sélecteurs est capable d'outrepasser les précédents, ce qui peut exclure certaines priorités du modèle.

Exemple 20.1. Filtres basés Facility/Priorité

Ci-dessous figurent quelques exemples de filtres basés facility/priorité simples pouvant être spécifiés dans /etc/rsyslog.conf. Pour sélectionner tous les messages syslog du noyau avec n'importe quelle priorité, ajoutez le texte suivant dans le fichier de configuration. 
kern.*
Pour sélectionner tous les messages syslog de courrier avec une priorité crit ou supérieure, veuillez utiliser le format ci-dessous : 
mail.crit
Pour sélectionner tous les messages syslog cron sauf ceux avec la priorité info ou debug, paramétrez la configuration sous le format suivant : 
cron.!info,!debug
Filtres basés Propriété
Les filtres basés propriété vous permettent de filtrer les messages syslog par toute propriété, comme timegenerated ou syslogtag. Pour obtenir davantage d'informations sur les propriétés, veuillez consulter la section intitulée « Propriétés ». Vous pouvez comparer chacune des propriétés spécifiées avec une valeur particulière en utilisant l'une des opérations de comparaison répertoriées dans la Tableau 20.1, « Opération de comparaison basée propriété ». Les noms des propriétés et les opérations de comparaison respectent la casse.
Un filtre basé propriété doit commencer par un caractère des deux-points (:). Pour définir le filtre, veuillez utiliser la syntaxe suivante : 
:PROPERTY, [!]COMPARE_OPERATION, "STRING"
où :
  • L'attribut PROPERTY spécifie la propriété souhaitée.
  • Le point d'exclamation optionnel (!) ignore la sortie de l'opération de comparaison. D'autres opérateurs booléens ne sont pas actuellement pris en charge par les filtres basés propriété.
  • L'attribut COMPARE_OPERATION spécifie l'une des opérations de comparaison répertoriée dans la Tableau 20.1, « Opération de comparaison basée propriété ».
  • L'attribut STRING spécifie la valeur à laquelle est comparé le texte fourni par la propriété. Cette valeur doit se trouver entre guillemets. Pour échapper certains caractères se trouvant dans la chaîne (par exemple un guillemet (")), veuillez utiliser le caractère de la barre oblique inversée (\).
Tableau 20.1. Opération de comparaison basée propriété
Opération de comparaisonDescription
containsVérifie si la chaîne fournie correspond à toute partie du texte fourni par la propriété. Pour effectuer des comparaisons ne respectant pas la casse, veuillez utiliser contains_i.
isequalCompare la chaîne fournie avec tout le texte de la propriété. Ces deux valeurs doivent être exactement pareilles pour correspondre.
startswithVérifie si la chaîne fournie est trouvée précisément au début du texte fourni par la propriété. Pour effectuer des comparaisons ne respectant pas la casse, veuillez utiliser startswith_i.
regexCompare l'expression BRE (« Basic Regular Expression ») POSIX fournie avec le texte fourni par la propriété.
ereregexCompare l'expression régulière ERE (« Extended Regular Expression ») POSIX fournie avec le texte fourni par la propriété.
isemptyVérifie si la propriété est vide. La valeur est abandonnée. Ceci est particulièrement utile lors de l'utilisation de données normalisées, avec lesquelles certains champs peuvent être remplis en se basant sur le résultat de la normalisation.

Exemple 20.2. Filtres basés Propriété

Ci-dessous figurent quelques exemples de filtres basés propriété pouvant être spécifiés dans /etc/rsyslog.conf. Pour sélectionner les messages syslog qui contiennent la chaîne error dans leur texte, veuillez utiliser : 
:msg, contains, "error"
Le filtre suivant sélectionne les messages syslog reçus du nom d'hôte host1 : 
:hostname, isequal, "host1"
Pour sélectionner les messages syslog qui ne mentionnent pas les mots fatal et error avec ou sans texte entre ces mots (par exemple, fatal lib error), veuillez saisir : 
:msg, !regex, "fatal .* error"
Filtres basés Expression
Les filtres basés Expression sélectionnent des messages syslog en fonction de l'arithmétique définie, ou des opérations des booléens et des chaînes. Les filtres basés Expression utilisent un langage propre à rsyslog, nommé RainerScript, pour créer des filtres complexes.
La syntaxe de base des filtres basés expression ressemble à ceci : 
if EXPRESSION then ACTION else ACTION
où :
  • L'attribut EXPRESSION représente une expression à évaluer, par exemple : $msg startswith 'DEVNAME' ou $syslogfacility-text == 'local0'. Il est possible de spécifier plus d'une expression dans un seul filtre en utilisant les opérateurs and et or.
  • L'attribut ACTION représente une action à effectuer si l'expression retourne la valeur true. Ceci peut être une action unique, ou un script complexe arbitraire se trouvant entre des accolades.
  • Les filtres basés Expression sont indiqués par le mot-clé if au début d'une nouvelle ligne. Le mot-clé then sépare l'EXPRESSION de l'ACTION. Optionnellement, il est possible d'utiliser le mot-clé else pour spécifier l'action à effectuer au cas où la condition n'est pas remplie.
Avec les filtres basés expression, il est possible d'imbriquer les conditions en utilisant un script se trouvant entre des accolades, comme dans l'Exemple 20.3, « Filtres basés Expression ». Le script vous permet d'utiliser des filtres basés facility/priorité dans l'expression. D'autre part, les filtres basés propriété ne sont pas recommandés ici. RainerScript prend en charge les expressions régulières avec les fonctions spécialisées re_match() et re_extract().

Exemple 20.3. Filtres basés Expression

L'expression suivante contient deux conditions imbriquées. Les fichiers journaux créés par un programme nommé prog1 sont divisés en deux fichiers basés sur la présence de la chaîne « test » dans le message. 
if $programname == 'prog1' then {
   action(type="omfile" file="/var/log/prog1.log")
   if $msg contains 'test' then
     action(type="omfile" file="/var/log/prog1test.log")
   else
     action(type="omfile" file="/var/log/prog1notest.log")
}
Voir la section intitulée « Documentation en ligne » pour obtenir d'autres exemples de filtres basés expression. RainerScriptr est la base du nouveau format de configuration de rsyslog, voir Section 20.3, « Utiliser le nouveau format de configuration »

20.2.2. Actions

Les actions spécifient ce qui doit être fait avec les messages filtrés par un sélecteur défini au préalable. Ci-dessous figurent certaines des actions pouvant être définies dans la règle :
Enregistrer des messages syslog dans les fichiers journaux
La majorité des actions spécifient le fichier journal sur lequel un message syslog est enregistré. Ceci peut être effectué en spécifiant un chemin de fichier après le sélecteur défini au préalable : 
FILTER PATH
où FILTER correspond au sélecteur spécifié par l'utilisateur et PATH est le chemin d'un fichier cible.
Par exemple, la règle suivante comprend un sélecteur, qui sélectionne tous les messages syslog cron et une action qui les enregistre sans le fichier journal /var/log/cron.log : 
cron.* /var/log/cron.log
Par défaut, le fichier journal est synchronisé chaque fois qu'un message syslog est généré. Utilisez un tiret (-) comme préfixe du chemin du fichier que vous spécifiez pour omettre la synchronisation : 
FILTER -PATH
Remarquez que vous pourriez perdre des informations si le système quitte juste après une tentative d'écriture. Cependant ce paramètre peut améliorer les performances, particulièrement si vous exécutez des programmes produisant des messages de journaux très détaillés.
Le chemin du fichier spécifié peut être statique ou dynamique. Les fichiers statiques sont représentés par un chemin de fichier fixe, comme décrit dans l'exemple ci-dessus. Des chemins de fichier dynamiques peuvent être différents en fonction du message reçu. Les chemins de fichiers dynamiques sont représentés par un modèle et un point d'interrogation (?) comme préfixe : 
FILTER ?DynamicFile
où DynamicFile est le nom d'un modèle prédéfini qui modifie les chemins de sortie. Il est possible d'utiliser un tiret (-) comme préfixe pour désactiver la synchronisation. Il est également possible d'utiliser de multiples modèles séparés par un point-virgule (;). Pour obtenir davantage d'informations sur les modèles, veuillez consulter la section intitulée « Générer des noms de fichiers dynamiques ».
Pendant l'utilisation du système X Window, si le fichier spécifié est un terminal ou un périphérique /dev/console, des messages syslog seront envoyés respectivement dans la sortie standard (à l'aide d'une gestion spéciale du terminal), ou dans la console (à l'aide d'une gestion spéciale de /dev/console).
Envoyer des messages syslog sur le réseau
rsyslog permet d'envoyer et de recevoir des messages syslog sur le réseau. Cette fonctionnalité permet d'administrer des messages syslog d'hôtes multiples sur une seule machine. Pour transférer des messages syslog sur une machine distante, veuillez utiliser la syntaxe suivante : 
@[(zNUMBER)]HOST:[PORT]
où :
  • Le caractère arobase (@) indique que les messages syslog sont transférés sur un hôte utilisant le protocole UDP. Pour utiliser le protocole TCP, utilisez deux caractères arobase sans les espacer (@@).
  • Le paramètre optionnel zNUMBER active la compression zlib des messages syslog. L'attribut NUMBER spécifie le niveau de compression (de 1 – le plus bas à 9 – maximum). Le gain de compression est automatiquement vérifié par rsyslogd, les messages sont uniquement compressés s'il y a un gain de compression et les messages faisant moins de 60 octets ne sont jamais compressés.
  • L'attribut HOST spécifie l'hôte qui reçoit les messages syslog sélectionnés.
  • L'attribut PORT spécifie le port de la machine hôte.
Lors de la spécification d'une adresse IPv6 en tant qu'hôte, veuillez ajouter l'adresse entre crochets ([, ]).

Exemple 20.4. Envoyer des messages syslog sur le réseau

Ci-dessous figurent quelques exemples d'actions qui transfèrent des messages syslog sur le réseau (remarquez que toutes les actions sont précédées d'un sélecteur qui sélectionne tous les messages prioritaires). Pour transférer des messages sur 192.168.0.1 via le protocole UDP, veuillez saisir : 
*.* @192.168.0.1
Pour transférer des messages sur « example.com » en utilisant le port 6514 et le protocole TCP, veuillez utiliser : 
*.* @@example.com:6514
La commande ci-dessous compresse les messages avec zlib (compression de niveau 9) et les transfère vers 2001:db8::1 en utilisant le protocole UDP 
*.* @(z9)[2001:db8::1]
Canaux de sortie
Les canaux de sortie sont principalement utilisés pour spécifier la taille maximum qu'un fichier journal peut faire. Ceci est particulièrement utile lors des rotations de fichiers journaux (pour obtenir davantage d'informations, veuillez consulter la Section 20.2.5, « Rotation de journaux »). Un canal de sortie est une collection d'informations sur l'action de sortie. Les canaux de sortie sont définis par la directive $outchannel. Pour définir un canal de sortie dans /etc/rsyslog.conf, veuillez utiliser la syntaxe suivante : 
$outchannel NAME, FILE_NAME, MAX_SIZE, ACTION
où :
  • L'attribut NAME spécifie le nom du canal de sortie.
  • L'attribut FILE_NAME spécifie le nom du fichier de sortie. Les canaux de sortie peuvent uniquement écrire dans des fichiers, et non dans les tubes, dans un terminal ou dans tout autre type de sortie.
  • L'attribut MAX_SIZE représente la taille maximale que le fichier spécifié (dans FILE_NAME) peut faire. Cette valeur est spécifiée en octets.
  • L'attribut ACTION spécifie l'action qui est prise lorsque la taille maximale, définie dans MAX_SIZE, est atteinte.
Pour utiliser la canal de sortie défini comme action à l'intérieur d'une règle, veuillez saisir : 
FILTER :omfile:$NAME

Exemple 20.5. Rotation du journal d'un canal de sortie

La sortie suivante affiche une simple rotation de journal à travers l'utilisation d'un canal de sortie. Avant tout, le canal est défini via la directive $outchannel : 
 $outchannel log_rotation, /var/log/test_log.log, 104857600, /home/joe/log_rotation_script
puis, il est utilisé dans une règle qui sélectionne chaque message syslog avec une priorité, et exécute le canal de sortie défini au préalable sur les messages syslog acquis : 
*.* :omfile:$log_rotation
Une fois la limite atteinte (dans l'exemple 100 Mo), /home/joe/log_rotation_script est exécuté. Ce script peut contenir une instruction souhaitée, que ce soit de déplacer le fichier dans un autre répertoire, modifier un contenu particulier, ou simplement le supprimer.
Envoyer des messages syslog à des utilisateurs particuliers
rsyslog peut envoyer des messages syslog à des utilisateurs particuliers en spécifiant le nom d'utilisateur de l'utilisateur auquel vous souhaitez envoyer les messages (comme décrit dans l'Exemple 20.7, « Spécifier de multiples actions »). Pour spécifier plus d'un utilisateur, séparez chaque nom d'utilisateur par une virgule (,). Pour envoyer des messages à chaque utilisateur actuellement connecté, veuillez ajouter un astérisque (*).
Exécuter un programme
rsyslog permet d'exécuter un programme pour les messages syslog sélectionnés et utilise l'appel system() pour exécuter le programme dans un shell. Pour spécifier l'exécution d'un programme, ajoutez un préfixe avec le caractère caret (^). Par conséquent, spécifiez un modèle qui formate le message reçu et le passe à l'exécutable spécifié en tant que paramètre sur une seule ligne (pour obtenir davantage d'informations sur les modèles, veuillez consulter la Section 20.2.3, « Modèles »). 
FILTER ^EXECUTABLE; TEMPLATE
Ici, une sortie de la condition FILTER est traitée par un programme représenté par EXECUTABLE. Ce programme peut être n'importe quel exécutable valide. Remplacez TEMPLATE par le nom du modèle de formatage.

Exemple 20.6. Exécuter un programme

Dans l'exemple suivante, tout message syslog avec une priorité est sélectionné, formaté avec le modèle template et passé en tant que paramètre sur le programme test-program, qui est ensuite exécuté avec le paramètre fourni : 
*.* ^test-program;template

Avertissement

Lorsque vous acceptez des messages d'un hôte, et que vous utilisez l'action « shell execute », vous pouvez être vulnérable à une injection de commande. Un attaquant peut tenter d'injecter et d'exécuter des commandes dans le programme dont vous avez spécifié l'exécution dans votre action. Pour éviter toute menace de sécurité possible, considérez bien l'utilisation de l'action « shell execute ».
Stocker les messages syslog dans une base de données
Les messages syslog sélectionnés peuvent être écrits directement dans une table de base de données en utilisant l'action d'écriture sur base de données « database writer ». L'écriture sur base de données utilise la syntaxe suivante : 
:PLUGIN:DB_HOST,DB_NAME,DB_USER,DB_PASSWORD;[TEMPLATE]
où :
  • PLUGIN appelle le greffon spécifié qui gère l'écriture sur la base de données (par exemple, le greffon ommysql).
  • L'attribut DB_HOST spécifie le nom d'hôte de la base de données.
  • L'attribut DB_NAME spécifie le nom de la base de données.
  • L'attribut DB_USER spécifie l'utilisateur de la base de données.
  • L'attribut DB_PASSWORD spécifie le mot de passe utilisé avec l'utilisateur de la base de données susmentionné.
  • L'attribut TEMPLATE spécifie une utilisation optionnelle d'un modèle qui modifie le message syslog. Pour obtenir davantage d'informations sur les modèles, veuillez consulter la Section 20.2.3, « Modèles ».

Important

Actuellement, rsyslog fournit uniquement la prise en charge des bases de données MySQL et PostgreSQL. Pour utiliser les fonctionnalités d'écriture sur base de données de MySQL et PostgreSQL, veuillez installer les paquets rsyslog-mysql et rsyslog-pgsql, respectivement. Veuillez également vous assurez de charger les modules appropriés dans votre fichier de configuration /etc/rsyslog.conf : 
$ModLoad ommysql    # Output module for MySQL support
$ModLoad ompgsql    # Output module for PostgreSQL support
Pour obtenir davantage d'informations sur les modules rsyslog, veuillez consulter la Section 20.6, « Utiliser des modules Rsyslog ».
Alternativement, vous pouvez utiliser une interface de base de données générique fournie par le module omlibdb (prise en charge : Firebird/Interbase, MS SQL, Sybase, SQLLite, Ingres, Oracle, mSQL).
Abandonner des messages syslog
Pour abandonner les messages sélectionnés, veuillez utiliser le caractère tilde (~). 
FILTER ~
L'action « discard » est principalement utilisée pour filtrer les messages avant de continuer à les traiter. Celle-ci peut être efficace si vous souhaitez omettre certains message répétitifs qui auraient rempli les fichiers journaux. Les résultats de l'action discard dépendent de l'endroit où elle se trouve dans le fichier de configuration. Pour de meilleurs résultats, veuillez placer ces actions tout en haut de la liste des actions. Veuillez remarquer qu'une fois qu'un message a été abandonné, il est impossible de le récupérer dans les lignes suivantes du fichier de configuration.
Par exemple, la règle suivante abandonne tout message syslog cron : 
cron.* ~

Spécifier de multiples actions

Pour chaque sélecteur, vous êtes autorisé à spécifier de multiples actions. Pour spécifier de multiples actions pour un sélecteur, écrivez chaque action sur un ligne différente et faites-la précéder d'un caractère perluète (&) : 
FILTER ACTION
& ACTION
& ACTION
Spécifier de multiples actions améliore les performances générales du résultat souhaité car le sélecteur spécifié ne doit être évalué qu'une seule fois.

Exemple 20.7. Spécifier de multiples actions

Dans l'exemple suivant, tous les messages syslog du noyau avec la priorité critique (crit) sont envoyés à l'utilisateur user1, traités par le modèle temp et passés sur l'exécutable test-program, puis transférés sur 192.168.0.1 via le protocole UDP. 
kern.=crit user1
& ^test-program;temp
& @192.168.0.1
Toute action peut être suivie d'un modèle qui formate le message. Pour spécifier un modèle, ajoutez un suffixe à l'action avec un point-virgule (;) et spécifiez le nom du modèle. Pour obtenir davantage d'informations sur les modèles, veuillez consulter la Section 20.2.3, « Modèles ».

Avertissement

Un modèle doit être défini avant d'être utilisé dans une action, sinon il sera ignoré. Autrement dit, les définitions de modèles doivent toujours précéder les définitions de règles dans /etc/rsyslog.conf.

20.2.3. Modèles

Toute sortie générée par rsyslog peut être modifiée et formatée selon vos besoins en utilisant des modèles. Pour créer un modèle, veuillez utiliser la syntaxe suivante dans /etc/rsyslog.conf : 
$template TEMPLATE_NAME,"text %PROPERTY% more text", [OPTION]
où :
  • $template est la directive du modèle indiquant que le texte la suivant définit un modèle.
  • TEMPLATE_NAME est le nom du modèle. Utilisez ce nom pour faire référence au modèle.
  • Tout ce qui se trouve entre deux guillemets ("…") fait partie du texte du modèle. Avec ce texte, des caractères spéciaux, tels que \n pour une nouvelle ligne, ou \r pour un retour chariot, peuvent être utilisés. d'autres caractères, tels que % ou ", doivent être échappés si vous souhaitez utiliser ces caractères de manière litérale.
  • Tout texte se trouvant entre deux caractères de pourcentage (%) indique une propriété vous permettant d'accéder au contenu particulier d'un message syslog. Pour obtenir davantage d'informations sur les propriétés, veuillez consulter la section intitulée « Propriétés ».
  • L'attribut OPTION spécifie une option qui modifie la fonctionnalité du modèle. Les options de modèle actuellement prises en charge incluent sql et stdsql, qui sont utilisées pour formater le texte en tant que requête SQL.

    Note

    Remarquez que le programme d'écriture sur base de données vérifie si les options sql ou stdsql sont spécifiées dans le modèle. Si ce n'est pas le cas, le programme d'écriture sur base de données n'effectuera aucune action. Cela permet d'empêcher toute menace de sécurité, comme les injections SQL.
    Veuillez consulter la section Stocker des messages syslog dans une base de donneés dans Section 20.2.2, « Actions » pour obtenir davantage d'informations.

Générer des noms de fichiers dynamiques

Les modèles peuvent être utilisés pour générer des noms de fichiers dynamiques. En spécifiant une propriété faisant partie de ce chemin de fichier, un nouveau fichier sera créé pour chaque propriété unique, ce qui est une manière pratique de classifier les messages syslog.
Par exemple, utilisez la propriété timegenerated, qui extrait un horodatage du message pour générer un nom de fichier unique pour chaque message syslog : 
$template DynamicFile,"/var/log/test_logs/%timegenerated%-test.log"
N'oubliez pas que la directive $template indique uniquement le modèle. Vous devez l'utiliser dans une règle pour qu'elle puisse entrer en vigueur. Dans le fichier /etc/rsyslog.conf, utilisez le point d'interrogation (?) dans une définition d'action pour marquer le modèle du nom de fichier dynamique : 
*.* ?DynamicFile

Propriétés

Les propriétés définies dans un modèle (entre deux caractères de pourcentage (%) permettent l'accès à divers contenus d'un message syslog par l'utilisation d'un remplaçant de propriété (property replacer). Pour définir une propriété située dans un modèle (entre les deux guillemets ("…"), veuillez utiliser la syntaxe suivante : 
%PROPERTY_NAME[:FROM_CHAR:TO_CHAR:OPTION]%
où :
  • L'attribut PROPERTY_NAME spécifie le nom de la propriété. Une liste de toutes les propriétés disponibles et leur description détaillée peut être trouvée dans la page man de rsyslog.conf(5) sous la section Propriétés disponibles.
  • Les attributs FROM_CHAR et TO_CHAR dénotent une gamme de caractères qui déclencheront une réaction de la part de la propriété spécifiée. Alternativement, des expressions régulières peuvent être utilisées pour spécifier une gamme de caractères. Pour effectuer cela, paramétrez la lettre R comme attribut FROM_CHAR et spécifiez l'expression régulière souhaitée comme attribut TO_CHAR.
  • L'attribut OPTION spécifie toute option de propriété, comme l'option lowercase, qui permet de convertir l'entrée en minuscules. Une liste de toutes les options des propriétés disponibles et leur description détaillée se trouve dans la page man rsyslog.conf(5), sous la section Options des propriétés.
Ci-dessous figurent quelques exemples de propriétés simples :
  • La propriété ci-dessous obtient le texte du message complet d'un message syslog : 
    %msg%
  • La propriété ci-dessous obtient les deux premiers caractères du texte d'un message syslog : 
    %msg:1:2%
  • La propriété ci-dessous obtient le texte du message complet d'un message syslog et abandonne le dernier caractère de saut de ligne : 
    %msg:::drop-last-lf%
  • La propriété suivante obtient les 10 premiers caractères de l'horodatage généré lorsque le message syslog est reçu et le formate en fonction du standard de date RFC 3999. 
    %timegenerated:1:10:date-rfc3339%

Exemples de modèles

Cette section présente quelques exemples de modèles rsyslog.
L'Exemple 20.8, « Un modèle de message syslog détaillé » affiche un modèle qui formate un message syslog de manière à inclure dans sa sortie la sévérité du message, son type, l'horodatage du moment auquel il a été reçu, le nom de l'hôte, la balise du message, son texte, le tout se terminant par une nouvelle ligne.

Exemple 20.8. Un modèle de message syslog détaillé

$template verbose, "%syslogseverity%, %syslogfacility%, %timegenerated%, %HOSTNAME%, %syslogtag%, %msg%\n"
L'Exemple 20.9, « Modèle de message « wall » » affiche un modèle qui ressemble à un message « wall » traditionnel (un message envoyé à tous les utilisateurs connectés dont la permission mesg(1) est paramétrée sur yes). Ce modèle inclut le texte du message dans sa sortie, ainsi qu'un nom d'hôte, une balise de message et un horodatage sur une nouvelle ligne (en utilisant \r et \n, et émet un son (en utilisant \7).

Exemple 20.9. Modèle de message « wall »

$template wallmsg,"\r\n\7Message from syslogd@%HOSTNAME% at %timegenerated% ...\r\n %syslogtag% %msg%\n\r"
L'Exemple 20.10, « Modèle de message formaté base de données » affiche un modèle qui formate un message syslog de manière à pouvoir l'utiliser en tant que requête de base de données. Remarquez l'utilisation de l'option sql à la fin du modèle spécifié en tant qu'option de modèle. Elle indique au programme d'écriture sur base de données de formater le message en tant que requête SQL MySQL.

Exemple 20.10. Modèle de message formaté base de données

$template dbFormat,"insert into SystemEvents (Message, Facility, FromHost, Priority, DeviceReportedTime, ReceivedAt, InfoUnitID, SysLogTag) values ('%msg%', %syslogfacility%, '%HOSTNAME%', %syslogpriority%, '%timereported:::date-mysql%', '%timegenerated:::date-mysql%', %iut%, '%syslogtag%')", sql
rsyslog contient également un ensemble de modèles prédéfinis identifiés par le préfixe RSYSLOG_. Ceux-ci sont réservés à l'utilisation de syslog et il est recommandé de ne pas créer de modèle en utilisant ce préfixe afin d'éviter les conflits. Ci-dessous figure une liste de ces modèles prédéfinis ainsi que leurs définitions.
RSYSLOG_DebugFormat
Format spécial utilisé pour résoudre les problèmes de propriétés. 
"Debug line with all properties:\nFROMHOST: '%FROMHOST%', fromhost-ip: '%fromhost-ip%', HOSTNAME: '%HOSTNAME%', PRI: %PRI%,\nsyslogtag '%syslogtag%', programname: '%programname%', APP-NAME: '%APP-NAME%', PROCID: '%PROCID%', MSGID: '%MSGID%',\nTIMESTAMP: '%TIMESTAMP%', STRUCTURED-DATA: '%STRUCTURED-DATA%',\nmsg: '%msg%'\nescaped msg: '%msg:::drop-cc%'\nrawmsg: '%rawmsg%'\n\n\"
RSYSLOG_SyslogProtocol23Format
Format spécifié sur IETF internet-draft ietf-syslog-protocol-23, qui est supposé devenir le nouveau standard RFC de syslog. 
"%PRI%1 %TIMESTAMP:::date-rfc3339% %HOSTNAME% %APP-NAME% %PROCID% %MSGID% %STRUCTURED-DATA% %msg%\n\"
RSYSLOG_FileFormat
Format logfile moderne similaire à TraditionalFileFormat, mais avec un horodatage de haute précision et des informations sur les fuseaux horaires. 
"%TIMESTAMP:::date-rfc3339% %HOSTNAME% %syslogtag%%msg:::sp-if-no-1st-sp%%msg:::drop-last-lf%\n\"
RSYSLOG_TraditionalFileFormat
Ancien format de fichier journal par défaut avec un horodatage peu précis. 
"%TIMESTAMP% %HOSTNAME% %syslogtag%%msg:::sp-if-no-1st-sp%%msg:::drop-last-lf%\n\"
RSYSLOG_ForwardFormat
Format de transfert avec horodatage de haute précision et informations sur les fuseaux horaires. 
"%PRI%%TIMESTAMP:::date-rfc3339% %HOSTNAME% %syslogtag:1:32%%msg:::sp-if-no-1st-sp%%msg%\"
RSYSLOG_TraditionalForwardFormat
Format de transfert traditionnel avec un horodatage peu précis. 
"%PRI%%TIMESTAMP% %HOSTNAME% %syslogtag:1:32%%msg:::sp-if-no-1st-sp%%msg%\"

20.2.4. Directives globales

Les directives globales sont des options de configuration qui s'appliquent au démon rsyslogd. Elles indiquent habituellement la valeur d'une variable prédéfinie qui affecte le comportement du démon rsyslogd ou une règle qui suit. Toutes les directives globales doivent commencer par le caractère du dollar ($). Une seule directive peut être spécifiée sur chaque ligne. Ci-dessous figure un exemple de directive globale qui spécifie la taille maximale de la file d'attente des messages syslog : 
$MainMsgQueueSize 50000
La taille par défaut définie pour cette directive (10,000 messages) peut être outrepassée en spécifiant une valeur différente (comme montré dans l'exemple ci-dessus).
Vous pouvez définir plusieurs directives dans le fichier de configuration /etc/rsyslog.conf. Une directive affecte le comportement de toutes les options de configuration jusqu'à ce qu'une autre occurrence de cette même directive soit détectée. Les directives globales peuvent être utilisées pour configurer des actions, des files d'attente, et pour le débogage. Une liste complète des toutes les directives de configuration disponibles se trouve dans la section intitulée « Documentation en ligne ». Actuellement, un nouveau format de configuration a été développé pour remplacer la syntaxe basée $ (veuillez consulter la Section 20.3, « Utiliser le nouveau format de configuration »). Cependant, les directives globales classiques sont toujours prises en charge comme format hérité.

20.2.5. Rotation de journaux

Ci-dessous figure un exemple du fichier de configuration /etc/logrotate.conf : 
# rotate log files weekly
weekly
# keep 4 weeks worth of backlogs
rotate 4
# uncomment this if you want your log files compressed
compress
Toutes les lignes dans l'exemple de fichier de configuration définissent des options globales qui s'appliquent à tous les fichiers journaux. Dans cet exemple, les fichiers journaux sont mis en rotation chaque semaine, les fichiers journaux en rotation sont gardés pendant quatre semaines, et tous les fichiers journaux rotatifs sont compressés par gzip sous le format .gz. Toute ligne commençant par le caractère dièse (#) est un commentaire et ne sera donc pas traité.
Vous pouvez définir les options de configuration d'un fichier journal spécifique et le placer sous les options globales. Cependant, il est recommandé de créer un fichier de configuration séparé pour tout fichier journal spécifique dans le répertoire /etc/logrotate.d/ et d'y définir les options de configuration souhaitées.
Ci-dessous figure un exemple de fichier de configuration placé dans le répertoire /etc/logrotate.d/ : 
/var/log/messages {
    rotate 5
    weekly
    postrotate
    /usr/bin/killall -HUP syslogd
    endscript
}
Les options de configuration dans ce fichier sont spécifiques au fichier journal /var/log/messages. Les paramètres spécifiés ici outrepassent les paramètres globaux lorsque possible. Ainsi, le fichier journal rotatif /var/log/messages sera conservé pendant cinq semaines au lieu des quatre semaines définies dans les options globales.
Ci-dessous figure une liste de quelques directives que vous pouvez spécifier dans le fichier de configuration logrotate :
  • weekly — spécifie la rotation hebdomadaire des fichiers journaux à effectuer. Les directives similaires incluent :
    • daily
    • monthly
    • yearly
  • compress — active la compression des fichiers journaux dont la rotation a été effectuée. Les directives similaires incluent :
    • nocompress
    • compresscmd — spécifie la commande à utiliser pour la compression.
    • uncompresscmd
    • compressext — spécifie quelle extension doit être utilisée pour la compression.
    • compressoptions — permet de spécifier toute option pouvant être passée au programme de compression utilisé.
    • delaycompress — reporte la compression des fichiers journaux jusqu'à la prochaine rotation des fichiers journaux.
  • rotate INTEGER — spécifie le nombre de rotations qu'un fichier journal effectue avant d'être supprimé ou envoyé à une adresse spécifique. Si la valeur 0 est spécifiée, les anciens fichiers journaux sont supprimés au lieu d'être mis en rotation.
  • mail ADDRESS — cette option active l'envoi vers une adresse spécifiée pour les fichiers journaux qui ont été mis en rotation le nombre de fois défini par la directive rotate. Directives similaires :
    • nomail
    • mailfirst — indique que seuls les fichiers journaux qui viennent d'effectuer une rotation doivent être envoyés, au lieu d'envoyer les fichiers journaux sur le point d'expirer.
    • maillast — spécifie que les fichiers journaux sur le point d'expirer doivent être envoyés, au lieu d'envoyer les fichiers journaux qui viennent d'effectuer une rotation. Cette option est utilisée par défaut lorsque mail est activé.
Pour obtenir la liste complète des directives et des diverses options de configuration, veuillez consulter la page man de logrotate(5).
Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.