20.4. Utiliser des files d'attente dans Rsyslog

Les files sont utilisées pour transférer des contenus, principalement des messages syslog, entre composants de rsyslog. Avec les files, rsyslog est capable de traiter de multiples messages simultanément et d'appliquer plusieurs actions à un seul message à la fois. Le flux de données dans rsyslog peut être illustré comme ceci :
Flux de messages dans Rsyslog

Figure 20.1. Flux de messages dans Rsyslog

Lorsque rsyslog reçoit un message, celui-ci est transféré vers le pré-processeur, puis il est placé dans la file des messages principaux (« main message queue »). Les messages attendent ainsi d'être retirés de cette file et transférés vers le processeur de règles (« rule processor »).
Le processeur de règles (« rule processor ») est un moteur d'analyse syntaxique et de filtrage. Ici, les règles définies dans /etc/rsyslog.conf sont appliquées. Basé sur ces règles, le processeur de règles évalue quelles sont les actions devant être effectuées. Chaque action possède sa propre file d'attente d'actions. Les messages sont transférés à travers cette file vers le processeur d'action respectif, qui créera la sortie finale. Remarquez qu'à ce moment, plusieurs actions peuvent être exécutées simultanément sur un seul message. Dans ce but précis, un message est dupliqué et transféré vers de multiples processeurs d'actions.
Seule une file d'attente par action est possible. Selon la configuration, les messages peuvent être envoyés directement vers le processeur d'actions sans file d'attente d'actions. Ce comportement est celui des files directes (veuillez voir ci-dessous). Au cas où l'action sortie échoue, le processeur d'actions notifie la file d'actions, qui reprendra ensuite un élément non traité, et après un certain temps, l'action sera tentée à nouveau.
Pour résumer, il existe deux positions dans lesquelles les files sont utilisées dans rsyslog: soit en face du processeur de règles en tant que file principale de messages unique, ou en face de divers types d'actions de sortie en tant que files d'action. Les files fournissent deux avantages principaux, menant tous deux à une amélioration des performances du traitement des messages :
  • elles servent de tampon, découplant les producteurs et consommateurs dans la structure de rsyslog
  • elles permettent la parallélisation des actions effectués sur des messages
À part cela, les files peuvent être configurées avec plusieurs directives pour fournir des performances optimales à votre système. Il est question de ces options de configuration dans les sections suivantes.

Avertissement

Si un greffon de sortie est incapable de remettre un message, il est stocké dans la file de messages précédente. Si la file est remplie, les entrées sont bloquées jusqu'à ce qu'elle ne soit plus remplie. Cela empêchera les nouveaux messages d'être journalisés via la file bloquée. En l'absence de files d'actions séparées, ceci peut avoir de sérieuses conséquences, comme la prévention de la journalisation SSH, ce qui peut ensuite interdire l'accès SSH. Il est donc recommandé d'utiliser des files d'actions dédiées pour les sorties transférées à travers un réseau ou une base de données.

20.4.1. Définir des files d'attente

Basé sur l'emplacement de stockage des messages, il existe plusieurs types de files d'attente : les files les plus couramment utilisées sont nommées direct (file directe), in-memory (file en mémoire), disk (file de disque), et disk-assisted in-memory (file en mémoire assistée par disques). Il est possible de choisir l'un de ces types comme file principale et pour les files d'actions. Ajoutez ce qui suit au fichier /etc/rsyslog.conf :
$objectQueueType queue_type
Ici, vous pouvez appliquer le paramètre de la file principale des messages (remplacez object par MainMsg) ou pour une file d'actions (remplacez object par Action). Remplacez queue_type par direct, linkedlist ou fixedarray (qui sont des files en mémoire), ou par disk.
Le paramètre par défaut pour une file de message principale est la file FixedArray avec une limite de 10,000 messages. Les files d'actions sont définies par défaut comme des files « Direct » (directes).

Files « Direct »

Pour de nombreuses opérations simples, comme lors de l'écriture de la sortie sur un fichier local, la création d'une file devant chaque action n'est pas nécessaire. Pour éviter la mise en file d'attente, veuillez utiliser :
$objectQueueType Direct
Remplacez object par MainMsg ou par Action pour utiliser cette option sur la file de messages principale ou pour une file d'actions, respectivement. Avec une file « Direct », les messages sont immédiatement et directement transférés du producteur au consommateur.

Files « Disk »

Les files « Disk » stockent les messages strictement sur un disque dur, ce qui les rend très fiables, mais ce mode est également le plus lent des modes de files. Ce mode peut être utilisé pour empêcher la perte de données de journaux extrêmement importants. Cependant, les files de disques ne sont pas recommandées dans la plupart des cas. Pour définir une file « Disk », veuillez saisir ce qui suit dans le fichier /etc/rsyslog.conf :
$objectQueueType Disk
Veuillez remplacer object par MainMsg ou par Action pour utiliser cette option pour la file de messages principale ou pour une file d'actions, respectivement. Les files « Disk » sont écrites sur différentes parties, avec une taille par défaut de 10 Mo. Cette taille par défaut peut être modifiée avec la directive de configuration suivante :
$objectQueueMaxFileSize size
size représente la taille spécifiée de la partie de la file « Disk ». La limite de taille définie n'est pas restrictive, rsyslog écrit toujours une entrée de file complète, même si elle transgresse la limite de taille. Chaque partie d'une file de disque correspond à un fichier individuel. La directive du nom de ces fichiers est similaire à ceci :
$objectQueueFilename name
Cela définit un préfixe name pour le fichier, suivi d'un numéro à 7 chiffres commençant par le chiffre un et incrémenté pour chaque fichier.

Files « In-memory »

Avec les files en mémoire, les messages mis en file d'attente sont conservés dans la mémoire, ce qui rend le processus très rapide. Les données mises en file seront perdues si l'ordinateur est éteint ou redémarré. Cependant, il est possible d'utiliser le paramètre $ActionQueueSaveOnShutdown pour enregistrer les données avant la fermeture. Il existe deux types de files en mémoire :
  • La file FixedArray — mode par défaut de la file de messages principale, avec une limite de 10,000 éléments. Ce type de file utilise une matrice fixée, pré-allouée qui contient des pointeurs vers des éléments de files d'attente. À cause de ces pointeurs, même si la file est vide, une bonne quantité de mémoire est utilisée. Cependant, FixedArray offre des meilleures performances de temps d'activité et est optimal lorsque vous vous attendez à un nombre relativement faible de messages en file d'attente et à des performances élevées.
  • File LinkedList — ici, toutes les structures sont allouées dynamiquement dans une liste liée. Ainsi, la mémoire est uniquement allouée lorsque nécessaire. Les files LinkedList gèrent également très bien les rafales occasionnelles de messages.
En général, veuillez utiliser les files LinkedList lorsque vous avez des doutes. Comparé à FixedArray, ces files consomment moins de mémoire et réduisent la charge de traitement.
Veuillez utiliser la syntaxe suivante pour configurer les files en mémoire :
$objectQueueType LinkedList
$objectQueueType FixedArray
Remplacez object par MainMsg ou par Action pour utiliser cette option sur la file de messages principale ou la file d'actions, respectivement.

Files « Disk-Assisted In-memory »

Les files de disque et en mémoire ont chacune leurs avantages, et rsyslog permet de les combiner en files en mémoire assistées par disque. Pour faire cela, veuillez configurer une file en mémoire normale, puis ajoutez la directive $objectQueueFileName pour définir un nom de fichier pour l'assistance disque. Cette file deviendra ainsi une file assistée par disque, ce qui signifie qu'une file en mémoire est combinée à une file de disque et celles-ci fonctionneront en tandem.
La file de disque est activée si la file en mémoire est pleine ou doit persister après une fermeture du système. Avec une file assistée par disque, il est possible de définir des paramètres de configuration spécifiques aux files de disque et spécifiques aux files en mémoire. Ce type de file est probablement le plus couramment utilisé, il est particulièrement utile pour les actions potentiellement longues et peu fiables.
Pour spécifier le fonctionnement d'une file en mémoire assistée par disque, veuillez utiliser les filigranes :
$objectQueueHighWatermark number
$objectQueueLowWatermark number
Veuillez remplacer object par MainMsg ou par Action pour utiliser cette option pour la file de messages principale ou pour une file d'actions, respectivement. Remplacez number par le nombre de messages mis en file d'attente. Lorsqu'une file en mémoire atteint le nombre défini par le filigrane du haut, les messages commencent à être écrits sur le disque et cela continue jusqu'à ce que la taille de la file en mémoire passe sous le nombre défini par le filigrane du bas. La définition correcte des filigranes minimise les écritures sur disque non nécessaires, mais cela laisse également de l'espace mémoire pour les rafales de messages, puisque l'écriture sur fichiers de disque est relativement longue. Ainsi, le filigrane du haut doit être plus bas que la totalité de la capacité de la file définie avec $objectQueueSize. La différence entre le filigrane du haut et la taille de la file en général est un tampon de mémoire supplémentaire réservé aux rafales de message. D'autre part, définir le filigrane du haut trop bas activera l'assistance par disque trop souvent.

Exemple 20.12. Transférer des messages journaux sur un serveur de manière fiable

Rsyslog est souvent utilisé pour maintenir un système de journalisation centralisé, où les messages sont transférés sur un serveur à travers le réseau. Pour éviter que des pertes de messages se produisent lorsque le serveur est indisponible, il est recommandé de configurer une file d'actions pour l'action de transfert. Ainsi, les messages dont l'envoi a échoué sont stockés localement jusqu'à ce que le serveur soit à nouveau joignable. Remarquez que de telles files ne sont pas configurables pour les connexions utilisant le protocole UDP.

Procédure 20.1. Effectuer un transfert sur un seul serveur

Supposez que la tâche consiste à transférer les messages de journalisation d'un système à un serveur avec le nom d'hôte example.com, et à configurer une file d'actions pour mettre les messages dans un tampon en cas de panne du serveur. Pour cela, veuillez effectuer les étapes suivantes :
  • Veuillez utiliser la configuration suivante dans /etc/rsyslog.conf ou créez un fichier avec le contenu suivant dans le répertoire /etc/rsyslog.d/ :
    $ActionQueueType LinkedList
    $ActionQueueFileName example_fwd
    $ActionResumeRetryCount -1
    $ActionQueueSaveOnShutdown on
    *.*       @@example.com:6514
    Où :
    • $ActionQueueType active une file en mémoire LinkedList,
    • $ActionFileName définit un stockage sur disque. Dans ce cas, les fichiers de sauvegarde sont créés dans le répertoire /var/lib/rsyslog/ avec le préfixe example_fwd,
    • le paramètre $ActionResumeRetryCount -1 empêche rsyslog d'abandonner des messages lorsqu'il essaie de se connecter à nouveau si le serveur ne répond pas,
    • $ActionQueueSaveOnShutdown activé enregistre les données en mémoire si rsyslog s'éteint,
    • la dernière ligne transfère tous les messages reçus au serveur d'enregistrement, la spécification de port est optionnelle.
    Avec la configuration ci-dessus, rsyslog conserve les messages en mémoire si le serveur distant n'est pas joignable. Un fichier sur disque est uniquement créé si rsyslog ne possède plus d'espace configuré de file d'attente en mémoire ou s'il doit s'éteindre, ce qui profite aux performances système.

Procédure 20.2. Effectuer un transfert vers plusieurs serveurs

Le processus de transfert de messages de journalisation vers des serveurs multiples est similaire à la procédure précédente :
  • Chaque serveur destinataire requiert une règle de transfert séparée, une spécification de file d'actions séparée, et un fichier de sauvegarde sur disque séparé. Par exemple, veuillez utiliser la configuration suivante dans /etc/rsyslog.conf ou créez un fichier avec le contenu suivant dans le répertoire /etc/rsyslog.d/ :
    $ActionQueueType LinkedList
    $ActionQueueFileName example_fwd1
    $ActionResumeRetryCount -1
    $ActionQueueSaveOnShutdown on
    *.*       @@example1.com
    
    $ActionQueueType LinkedList
    $ActionQueueFileName example_fwd2 
    $ActionResumeRetryCount -1
    $ActionQueueSaveOnShutdown on
    *.*       @@example2.com

20.4.2. Créez un nouveau répertoire pour les fichiers de journalisation rsyslog

Rsyslog exécute en tant que démon syslogd et est géré par SELinux. De ce fait, tous les fichiers dans lesquels rsyslog écrit doivent posséder le contexte de fichier SELinux qui convient.

Procédure 20.3. Création d'un nouveau répertoire de travail

  1. Si vous avez besoin d'un répertoire différent pour stocker les fichiers de travail, créer un répertoire comme suit :
    ~]# mkdir /rsyslog
  2. Installer les utilitaires requis pour la Stratégie SELinux :
    ~]# yum install policycoreutils-python
  3. Définir le contexte de répertoire SELinux pour qu'il corresponde à celui du répertoire /var/lib/rsyslog/ :
    ~]# semanage fcontext -a -t syslogd_var_lib_t /rsyslog
  4. Appliquer le contexte SELinux :
    ~]# restorecon -R -v /rsyslog
    restorecon reset /rsyslog context unconfined_u:object_r:default_t:s0->unconfined_u:object_r:syslogd_var_lib_t:s0
  5. Si nécessaire, vérifiez le contexte SELinux comme suit :
    ~]# ls -Zd /rsyslog
    drwxr-xr-x. root root system_u:object_r:syslogd_var_lib_t:s0   /rsyslog
  6. Créer des sous-répertoires selon les besoins. Exemple :
    ~]# mkdir /rsyslog/work/
    Les sous-répertoires seront créés avec le même contexte SELinux que le répertoire parent.
  7. Ajouter la ligne suivante dans /etc/rsyslog.conf juste avant qu'elle puisse entrer en vigueur :
    $WorkDirectory /rsyslog/work
    Ce paramétre demeurera valide jusqu'à ce que l'on rencontre une nouvelle directive de WorkDirectory lors de l'analyse des fichiers de configuration.

20.4.3. Gestion des files

Tous les types de files peuvent être configurés davantage, afin de correspondre à vos besoins. Il est possible d'utiliser plusieurs directives pour modifier les files d'actions et la file de messages principale. Actuellement, il existe plus de 20 paramètres de file disponibles, veuillez consulter la section intitulée « Documentation en ligne ». Certains de ces paramètres sont couramment utilisés, tandis que d'autres, comme la gestion de threads de travail (« worker thread management »), fournissent un contrôle plus précis du comportement des files et sont réservés aux utilisateurs avancés. Avec des paramètres avancés, il est possible d'optimiser les performances de rsyslog, de planifier la mise en file d'attente, ou de modifier le comportement d'une file pendant la fermeture système.

Limiter la taille de file d'attente

Vous pouvez limiter le nombre de messages contenus dans une file d'attente avec le paramètre suivant :
$objectQueueHighWatermark number
Remplacez objet par MainMsg ou par Action pour utiliser cette option pour la file de messages principale ou pour une file d'actions, respectivement. Remplacez nombre par le nombre de messages mis en file d'attente. Vous pouvez uniquement définir la taille de la file en tant que nombre de messages, et non en tant que taille de mémoire. La taille de la file par défaut s'élève à 10,000 messages pour la file de messages principale et les files ruleset, et à 1000 pour les files d'actions.
Les files assistées par disque sont illimitées par défaut et ne peuvent pas être limitées par cette directive, mais vous pouvez leur réserver de l'espace physique en octets avec les paramètres suivants :
$objectQueueMaxDiscSpace number
Remplacez objet par MainMsg ou par Action. Lorsque la limite de la taille spécifiée par le nombre est atteinte, les messages sont abandonnés jusqu'à ce que suffisamment d'espace soit libéré par les messages sortis de la file.

Abandonner des messages

Lorsqu'une file atteint un certain nombre de messages, vous pouvez abandonner les messages moins importants afin d'économiser de l'espace dans la file pour les entrées de plus haute priorité. La limite qui lance le processus d'abandon peut être définie avec l'indication discard :
$objectQueueDiscardMark number
Remplacez objet par MainMsg ou par Action pour utiliser cette option sur la file de messages principale ou sur une file d'actions, respectivement. Le nombre correspond au nombre de messages qui doit se trouver dans la file pour lancer le processus d'abandon. Pour définir quels messages abandonner, veuillez utiliser :
$objectQueueDiscardSeverity priority
Remplacez priorité 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). Avec ce paramètre, les messages entrants et les messages se trouvant déjà en file d'attente avec une priorité plus basse que celle qui est définie, sont effacés de la file dès que la marque d'abandon aura été atteinte.

Utiliser des délais

Il est possible de configurer rsyslog pour traiter des files d'attente pendant une période spécifique. Par exemple, avec cette option, il est possible de transférer une partie du traitement pendant les heures creuses. Pour paramétrer un délai, veuillez utiliser la syntaxe suivante :
$objectQueueDequeueTimeBegin hour
$objectQueueDequeueTimeEnd hour
Avec heure, vous pouvez spécifier les heures qui limitent votre délai. Veuillez utiliser le format 24 heures sans les minutes.

Configurer les threads de travail

Un thread de travail effectue une action spécifiée sur le message mis en file d'attente. Par exemple, dans la file de messages principale, une tâche de travail consiste à appliquer une logique de filtrage sur chaque message puis de l'ajouter à la file d'action correspondante. Lorsqu'un message arrive, un thread de travail est lancé automatiquement. Lorsque le nombre de messages atteint un certain niveau, un autre thread de travail est allumé. Pour spécifier ce nombre, veuillez utiliser :
$objectQueueWorkerThreadMinimumMessages number
Remplacez nombre par le nombre de messages qui déclenchera un thread de travail supplémentaire. Par exemple, si le nombre est paramétré sur 100, un nouveau thread de travail sera lancé lorsque plus de 100 messages seront reçus. Lorsque plus de 200 seront reçus, un troisième thread de travail sera lancé, et ainsi de suite. Cependant, trop de threads de travail fonctionnant en parallèle deviendront inefficaces, vous pouvez donc limiter le nombre maximum en utilisant :
$objectQueueWorkerThreads number
où le nombre correspond au nombre maximal de threads de travail pouvant être exécutés en parallèle. Pour la file de messages principale, la limite par défaut est fixée à 1 thread. Une fois qu'un thread de travail a été lancé, il restera en cours d'exécution jusqu'à ce qu'un délai d'inactivité apparaisse. Pour définir la longueur du délai, veuillez saisir :
$objectQueueWorkerTimeoutThreadShutdown time
Remplacez durée par la durée en millisecondes. Sans ce paramètre, un délai d'expiration fixé à zéro sera appliqué, et un thread de travail sera terminé dès qu'il ne contiendra plus de messages. Si vous spécifiez durée avec -1, aucun thread ne sera fermé.

Retirer un lot de la file

Pour améliorer les performances, vous pouvez configurer rsyslog pour retirer de multiples messages de la file à la fois. Pour définir la limite supérieure de ce type de suppression de la file :
$objectQueueDequeueBatchSize number
Remplacez nombre par le nombre maximal de messages pouvant être supprimés de la file à la fois. Remarquez qu'un paramètre plus élevé combiné à un nombre plus élevé de threads de travail autorisés se traduit par une consommation de mémoire plus importante.

Terminer des files d'attente

Lorsqu'une file qui contient encore des messages est terminée, vous pouvez minimiser la perte de données en spécifiant un intervalle pour que les threads de travail puisse finir le traitement de la file :
$objectQueueTimeoutShutdown time
Spécifiez time en millisecondes. Si certains messages sont toujours en file d'attente après cette période, les threads de travail finiront l'élément de données actuel et se termineront. Des messages non traités seront donc perdus. Un autre intervalle peut également être paramétré pour que les threads de travail puissent traiter l'élément final :
$objectQueueTimeoutActionCompletion time
Au cas où le délai d'expiration se termine, tout thread de travail restant sera éteint. Pour enregistrer les données pendant la fermeture, veuillez utiliser :
$objectQueueTimeoutSaveOnShutdown time
Si définis, tous les éléments de la file seront enregistrés sur le disque avant que rsyslog ne se termine.

20.4.4. Utilisation d'une nouvelle syntaxe pour les files d'attente rsyslog

Dans la nouvelle syntaxe qui se trouve dans rsyslog 7, les files d'attente se trouvent dans l'objet action() qui peut être utilisé à la fois séparemment ou à l'intérieur d'un ruleset dans /etc/rsyslog.conf. Le format d'une file d'attente d'action ressemble à ce qui suit :
action(type="action_type" queue.size="queue_size" queue.type="queue_type" queue.filename="file_name")
Remplacer action_type par le nom du module qui doit effectuer l'action et remplacer queue_size par le nombre maximum de messages que la file d'attente puisse contenir. Pour queue_type, sélectionner disk ou bien, parmi l'une des files d'attente en mémoire : direct, linkedlist ou fixedarray. Pour file_name ne spécifier qu'un nom de fichier, et non pas un chemin. Notez que si vous créez une nouveau répertoire contenant les fichiers de journalisation, le context SELinux devra être défini. Voir un exemple dans Section 20.4.2, « Créez un nouveau répertoire pour les fichiers de journalisation rsyslog ».

Exemple 20.13. Définir une File d'attente d'action

Pour configurer l'action de sortie avec une file d'attente d'actions asynchrones basées sur une liste chaînée, qui peut contenir un maximum de 10 000 messages, saisir la commande suivante :
action(type="omfile" queue.size="10000" queue.type="linkedlist" queue.filename="logfile")
La syntaxe rsyslog 7 de files d'attentes d'actions directes ressemble à ceci :
*.* action(type="omfile" file="/var/lib/rsyslog/log_file
     )
La syntaxe rsyslog 7 d'une file d'attente ayant plusieurs paramètres peut s'écrire ainsi :
*.* action(type="omfile"
              queue.filename="log_file"
              queue.type="linkedlist"
              queue.size="10000"
     )
Le répertoire de travail par défaut, ou le dernier répertoire de travail à définir, sera utilisé. Si l'on doit utiliser un autre répertoire de travail, ajouter une ligne comme suit devant la file d'attente d'action :
global(workDirectory="/directory")

Exemple 20.14. Redirection vers un Serveur unique avec la nouvelle Syntaxe

L'exemple suivant est basé sur la procédure Procédure 20.1, « Effectuer un transfert sur un seul serveur » afin de montrer la différence entre la syntaxe traditionnelle et la syntaxe rsyslog 7. Le greffon omfwd est utilisé pour le transfert via UDP ou TCP. La valeur par défaut est UDP. Comme le greffon est intégré, il n'a pas besoin d'être téléchargé.
Veuillez utiliser la configuration suivante dans /etc/rsyslog.conf ou créez un fichier avec le contenu suivant dans le répertoire /etc/rsyslog.d/ :
*.* action(type="omfwd"
      queue.type="linkedlist"
      queue.filename="example_fwd"
      action.resumeRetryCount="-1"
      queue.saveOnShutdown="on"
      target="example.com" port="6514" protocol="tcp"
     )
Où :
  • queue.type="linkedlist" permet d'avoir une file d'attente LinkedList en mémoire,
  • queue.filename définit un stockage sur disque. Les fichiers de sauvegarde sont créés avec le préfixe example_fwd, dans le répertoire de travail spécifié par la directive workDirectory globale qui précède,
  • le paramètre action.resumeRetryCount -1 empêche rsyslog d'abandonner des messages lorsqu'il essaie de se connecter à nouveau si le serveur ne répond pas,
  • queue.saveOnShutdown="on" activé enregistre les données en mémoire si rsyslog s'éteint,
  • la dernière ligne transfère tous les messages reçus au serveur d'enregistrement, la spécification de port est optionnelle.