6 Supervision des fichiers journaux

Aperçu

Zabbix peut être utilisé pour la surveillance centralisée et l'analyse des fichiers journaux avec/sans support de rotation des fichiers journaux.

Les notifications peuvent être utilisées pour avertir les utilisateurs lorsqu'un fichier journal contient certaines chaînes ou certains modèles de chaîne.

Pour superviser un fichier journal, vous devez avoir :

• Un agent Zabbix en cours d'exécution sur l'hôte
• Un paramètre de supervision de fichier journal mis en place

Configuration

Vérifier les paramètres de l'agent

Assurez-vous que dans le fichier de configuration de l'agent :

• Le paramètre 'Hostname' correspond au nom d'hôte dans l’interface Web
• Les serveurs dans le paramètre 'ServerActive' sont spécifiés pour le traitement des vérifications actives

Configuration d'un élément

Configurer un élément de supervision de fichier journal :

Tous les champs de saisie obligatoires sont marqués d'un astérisque rouge.

Spécifiquement pour les éléments de supervision de fichiers journaux vous devez entrer :

Notes importantes

• Le serveur et l'agent conservent la trace de la taille d'un journal surveillé et l'heure de la dernière modification (pour logrt) dans deux compteurs. Additionellement : · - · L'agent utilise également en interne des numéros d'inode (sous UNIX/GNU/Linux), des index de fichiers (sur Microsoft Windows) et des sommes MD5 des 512 premiers octets de fichier journal pour améliorer les décisions lorsque les fichiers de logs sont tronqués et pivotés. · - · Sur les systèmes UNIX/GNU/Linux, il est supposé que les systèmes de fichiers où sont stockés les fichiers journaux renvoient des numéros d'inode, qui peuvent être utilisés pour suivre les fichiers. · - · Sous Microsoft Windows, l'agent Zabbix détermine le type de système de fichiers sur lequel résident les fichiers journaux et utilise : · - · Sur les systèmes de fichiers NTFS index de fichiers 64 bits. · - · Sur les systèmes de fichiers ReFS (uniquement à partir de Microsft Windows Server 2012) ID de fichier 128 bits. · - · Sur les systèmes de fichiers où les index de fichiers changent (par exemple FAT32, exFAT) un algorithme de repli est utilisé pour adopter une approche sensée dans des conditions incertaines lorsque la rotation du fichier journal entraîne plusieurs fichiers de logs avec la même heure de modification. · - · Les numéros d'inode, les index de fichiers et les sommes MD5 sont collectés en interne par l'agent Zabbix. Ils ne sont pas transmis au serveur Zabbix et sont perdus lorsque l'agent Zabbix est arrêté. · - · Ne modifiez pas l'heure de la dernière modification des fichiers de logs avec l'utilitaire 'touch', ne restaurez pas un fichier de logs en gardant son nom d'origine (cela changera le numéro d'inode du fichier). Dans les deux cas, le fichier sera considéré comme différent et sera analysé dès le début, ce qui peut entraîner des alertes en double. · - · S'il y a plusieurs fichiers journaux correspondants pour l'élément ''logrt[]'' et que l'agent Zabbix suit le plus récent d'entre eux et que ce fichier journal le plus récent est supprimé, un message d'avertissement ''"there are no files matching ”<regexp mask>“ in ”<directory>"'' est enregistré. L'agent Zabbix ignore les fichiers de logs dont l'heure de modification est inférieure à l'heure de modification la plus récente vue par l'agent pour l’élément ''logrt[]'' en cours de vérification.
• L'agent commence à lire le fichier journal à partir du moment où il s'est arrêté la fois précédente.
• Le nombre d'octets déjà analysés (le compteur de taille) et l'heure de dernière modification (le compteur de temps) sont stockés dans la base de données Zabbix et envoyés à l'agent pour s'assurer que l'agent commence à lire le fichier journal depuis cet emplacement dans le cas où l’agent vienne juste de démarrer ou a reçu des éléments précédemment désactivés ou non supportés. Toutefois, si l'agent a reçu un compteur de taille différent de zéro du serveur, mais que l'élément logrt[] ou logrt.count[] n'a pas été trouvé et ne trouve pas de fichiers correspondants, le compteur de taille est réinitialisé à 0 si les fichiers apparaissent plus tard.
• Chaque fois que le fichier journal devient plus petit que le compteur de taille du fichier journal connu par l'agent, le compteur est remis à zéro et l'agent commence à lire le fichier journal depuis le début en tenant compte du compteur de temps.
• S'il y a plusieurs fichiers correspondants avec la même heure de modification dans le répertoire, l'agent analyse correctement tous les fichiers journaux avec la même heure de modification et évite de sauter les données ou d'analyser deux fois les mêmes données, même si cela ne peut pas être garanti. L'agent n'assume aucun schéma de rotation de fichier de logs particulier et n'en détermine aucun. Lorsque plusieurs fichiers de logs sont présentés avec la même heure de dernière modification, l'agent les traite dans un ordre décroissant lexicographique. Ainsi, pour certains schémas de rotation, les fichiers de logs seront analysés et rapportés dans leur ordre d'origine. Pour les autres schémas de rotation, l'ordre des fichiers de logs d'origine ne sera pas respecté, ce qui peut entraîner la génération de rapports dans les fichiers de logs correspondants (le problème ne se produit pas si les fichiers de logs ont des temps de modification différents).
• L'agent Zabbix traite les nouveaux enregistrements d'un fichier journal une fois par //intervalle d’actualisation// en secondes.
• L'agent Zabbix n'envoie pas plus le maxlines d'un fichier journal par seconde. La limite empêche la surcharge des ressources réseau et CPU et remplace la valeur par défaut fournie par le paramètre MaxLinesPerSecond dans le fichier de configuration de l'agent](/manual/appendix/config/zabbix_agentd).
• Pour trouver la chaîne requise, Zabbix traitera 10 fois plus de nouvelles lignes que dans MaxLinesPerSecond. Par exemple, si un élément ''log[]'' ou ''logrt[]'' a un //intervalle d’actualisation// de 1 seconde, l'agent analysera par défaut pas plus de 200 enregistrements de fichiers de logs et n'enverra pas plus de 20 enregistrements correspondants au serveur Zabbix en une seule vérification. En augmentant MaxLinesPerSecond dans le fichier de configuration de l'agent ou en définissant le paramètre maxlines dans la clé de l'élément, la limite peut être augmentée jusqu'à 10000 enregistrements de fichiers de logs analysés et 1000 enregistrements correspondants envoyés au serveur Zabbix en une seule vérification. Si l'//intervalle d’actualisation// est défini sur 2 secondes, les limites pour une vérification seront définies 2 fois plus haut qu'avec l'//intervalle d’actualisation// de 1 seconde.
• · De plus, les valeurs log et log.count sont toujours limitées à 50% de la taille du buffer d'envoi de l'agent, même s'il n'y a pas de valeurs non log. Ainsi, pour que les valeurs maxlines soient envoyées dans une connexion (et non dans plusieurs connexions), le paramètre BufferSize de l'agent doit être au moins maxlines x 2
• · En l'absence d'éléments journaux, toute la taille du buffer d'agent est utilisée pour les valeurs non log. Lorsque les valeurs des fichiers journaux arrivent, elles remplacent les anciennes valeurs non log, selon les besoins, jusqu'à 50%.
• · Pour les enregistrements de fichiers journaux de plus de 256 Ko, seuls les 256 premiers Ko correspondent à l'expression régulière et le reste de l'enregistrement est ignoré. Cependant, si l'agent Zabbix est arrêté alors qu'il traite un enregistrement long, l'état interne de l'agent est perdu et l'enregistrement long peut être analysé de nouveau et différemment après le redémarrage de l'agent.
• · Remarque spéciale pour les séparateurs de chemin "\" : si file_format est "fichier.log", il ne doit pas y avoir de répertoire "fichier" car il est impossible de définir sans ambiguïté si "." est échappé ou est le premier symbole du nom du fichier.
• · Les expressions régulières pour ''logrt'' sont prises en charge dans le nom de fichier uniquement, la correspondance d'expression régulière du répertoire n'est pas prise en charge.
• · Sur les plates-formes UNIX, ''logrt[]'' devient NON SUPPORTÉ si un répertoire dans lequel les fichiers journaux doivent être trouvés n'existe pas.
• · Sur Microsoft Windows, si un répertoire n'existe pas, l'élément ne deviendra pas NON SUPPORTÉ (par exemple, si le répertoire est mal orthographié dans la clé de l'élément).
• · Une absence de fichiers journaux pour ''logrt[]'' ne le rend pas NON SUPPORTÉ. Les erreurs de lecture des fichiers journaux pour ''logrt[]'' sont consignées comme des avertissements dans le fichier journal de l'agent Zabbix mais ne font pas apparaître l'élément NON SUPPORTÉ.
• · Le fichier journal de l'agent Zabbix peut être utile pour savoir pourquoi un élément ''log[]'' ou ''logrt[]'' est devenu NON SUPPORTÉ. Zabbix peut surveiller son fichier journal de l'agent sauf au niveau DebugLevel=4.

Extraction de la partie correspondante de l'expression régulière

Nous pouvons parfois vouloir extraire uniquement la valeur intéressante d'un fichier cible au lieu de renvoyer la ligne entière lorsqu'une correspondance d'expression régulière est trouvée.

Depuis Zabbix 2.2.0, les éléments de fichiers journaux ont la possibilité d'extraire les valeurs souhaitées des lignes correspondantes. Ceci est accompli par le paramètre supplémentaire output dans les éléments log et logrt.

L'utilisation du paramètre 'output' permet d'indiquer le "groupe capturé" de la correspondance qui pourrait nous intéresser.

Ainsi, par exemple :

log[/path/to/the/file,"large result buffer allocation.*Entries: ([0-9]+)",,,,\1]

devrait permettre de renvoyer le nombre d'entrées tel que trouvé dans le contenu de :

Fr Feb 07 2014 11:07:36.6690 */ Thread Id 1400 (GLEWF) large result
       buffer allocation - /Length: 437136/Entries: 5948/Client Ver: >=10/RPC
       ID: 41726453/User: AUser/Form: CFG:ServiceLevelAgreement

Le nombre uniquement sera retourné parce que \1 se réfère au premier et seul groupe capturé : ([0-9]+)

Et, avec la possibilité d'extraire et de renvoyer un nombre, la valeur peut être utilisée pour définir des déclencheurs.

Utilisation du paramètre maxdelay

Le paramètre 'maxdelay' dans les éléments de journal permet d'ignorer certaines lignes plus anciennes des fichiers journaux afin d'obtenir les lignes les plus récentes analysées dans les secondes 'maxdelay'.

Par défaut, les éléments de surveillance des journaux suivent toutes les nouvelles lignes apparaissant dans les fichiers journaux. Cependant, il existe des applications qui, dans certaines situations, commencent à écrire un nombre énorme de messages dans leurs fichiers journaux. Par exemple, si une base de données ou un serveur DNS est indisponible, ces applications inondent les fichiers journaux de milliers de messages d'erreur presque identiques jusqu'à ce que le fonctionnement normal soit rétabli. Par défaut, tous ces messages seront consciencieusement analysés et les lignes correspondantes envoyées au serveur comme configuré dans les éléments log et logrt.

La protection intégrée contre la surcharge consiste en un paramètre configurable 'maxlines' (protège le serveur contre trop de lignes de journal correspondantes entrantes) et une limite de 10*'maxlines' (protège le processeur hôte et les E/S de la surcharge par l'agent en une seule vérification) . Pourtant, il y a 2 problèmes avec la protection intégrée. Tout d'abord, un grand nombre de messages potentiellement peu informatifs sont signalés au serveur et consomment de l'espace dans la base de données. Deuxièmement, en raison du nombre limité de lignes analysées par seconde, l'agent peut être en retard sur les enregistrements de journal les plus récents pendant des heures. Très probablement, vous préférerez peut-être être informé plus tôt de la situation actuelle dans les fichiers journaux au lieu de parcourir les anciens enregistrements pendant des heures.

La solution aux deux problèmes consiste à utiliser le paramètre 'maxdelay'. Si 'maxdelay' > 0 est spécifié, lors de chaque vérification, le nombre d'octets traités, le nombre d'octets restants et le temps de traitement sont mesurés. À partir de ces chiffres, l'agent calcule un délai estimé - le nombre de secondes qu'il faudrait pour analyser tous les enregistrements restants dans un fichier journal.

Si le délai ne dépasse pas 'maxdelay', l'agent procède à l'analyse du fichier journal comme d'habitude.

Si le délai est supérieur à 'maxdelay', l'agent ignore un morceau d'un fichier journal en "sautant" par dessus vers une nouvelle position estimée afin que les lignes restantes puissent être analysées dans les 'maxdelay' secondes.

Notez que l'agent ne lit même pas les lignes ignorées dans le tampon, mais calcule une position approximative vers laquelle sauter dans un fichier.

Le fait de sauter des lignes du fichier journal est consigné dans le fichier journal de l'agent comme ceci :

14287:20160602:174344.206 item:"logrt["/home/zabbix32/test[0-9].log",ERROR,,1000,,,120.0]"
       logfile:"/home/zabbix32/test1.log" skipping 679858 bytes
       (from byte 75653115 to byte 76332973) to meet maxdelay

Le nombre "à l'octet" est approximatif car après le "saut", l'agent ajuste la position dans le fichier au début d'une ligne de journal qui peut être plus loin dans le fichier ou plus tôt.

Selon la façon dont la vitesse de croissance se compare à la vitesse d'analyse du fichier journal, vous pouvez ne voir aucun "saut", voir de rares ou fréquents "sauts", de grands ou petits "saut", ou même un petit "saut" à chaque vérification. Les fluctuations de la charge du système et de la latence du réseau affectent également le calcul du délai et, par conséquent, "sautent" en avant pour suivre le paramètre "maxdelay".

Définir 'maxdelay' < 'update interval' n'est pas recommandé (cela peut entraîner de petits "sauts" fréquents).

Remarques sur la gestion de 'copytruncate' dans la rotation des fichiers journaux

logrt avec l'option copytruncate suppose que différents fichiers journaux ont des enregistrements différents (au moins leurs horodatages sont différents), donc les sommes MD5 des blocs initiaux (jusqu'à 512 premiers octets) seront différentes. Deux fichiers avec les mêmes sommes MD5 de blocs initiaux signifient que l'un d'eux est l'original, l'autre - une copie.

logrt avec l'option copytruncate s'efforce de traiter correctement les copies de fichiers journaux sans signaler les doublons. Cependant, des choses telles que la production de plusieurs copies de fichiers journaux avec le même horodatage, la rotation du fichier journal plus souvent que l'intervalle de mise à jour de l'élément logrt[], le redémarrage fréquent de l'agent ne sont pas recommandés. L'agent essaie de gérer raisonnablement toutes ces situations, mais de bons résultats ne peuvent pas être garantis en toutes circonstances.

Remarques sur les fichiers persistants pour les éléments log*[]

Objectif des fichiers persistants

Lorsque l'agent Zabbix est démarré, il reçoit une liste des vérifications actives du serveur ou du proxy Zabbix. Pour les métriques log*[], il reçoit la taille du journal traité et l'heure de modification pour trouver où commencer la surveillance du fichier journal. En fonction de la taille réelle du fichier journal et de l'heure de modification signalée par le système de fichiers, l'agent décide soit de poursuivre la surveillance du fichier journal à partir de la taille du journal traité, soit de ré-analyser le fichier journal depuis le début.

Un agent en cours d'exécution conserve un plus grand ensemble d'attributs pour le suivi de tous les fichiers journaux surveillés entre les vérifications. Cet état en-mémoire est perdu lorsque l'agent est arrêté.

Le nouveau paramètre facultatif persistent_dir spécifie un répertoire pour stocker cet état de l'élément log[], log.count[], logrt[] ou logrt.count[] dans un fichier . L'état de l'élément de journal est restauré à partir du fichier persistant après le redémarrage de l'agent Zabbix.

Le principal cas d'usage est la surveillance du fichier journal situé sur un système de fichiers en miroir. Jusqu'à un certain moment, le fichier journal est écrit sur les deux miroirs. Ensuite, les miroirs sont divisés. Sur la copie active, le fichier journal continue de croître, obtenant de nouveaux enregistrements. L'agent Zabbix l'analyse et envoie la taille et l'heure de modification des journaux traités au serveur. Sur la copie passive, le fichier journal reste le même, bien derrière la copie active. Plus tard, le système d'exploitation et l'agent Zabbix sont redémarrés à partir de la copie passive. La taille du journal traité et l'heure de modification que l'agent Zabbix reçoit du serveur peuvent ne pas être valides pour la situation sur la copie passive. Pour continuer la surveillance du fichier journal à partir de l'endroit où l'agent s'est arrêté au moment de la division du miroir du système de fichiers, l'agent restaure son état à partir du fichier persistant.

Fonctionnement de l'agent avec fichier persistant

Au démarrage, l'agent Zabbix ne sait rien des fichiers persistants. Ce n'est qu'après avoir reçu une liste des vérifications actives du serveur Zabbix (proxy) que l'agent constate que certains éléments du journal doivent être sauvegardés par des fichiers persistants dans des répertoires spécifiés.

Pendant le fonctionnement de l'agent, les fichiers persistants sont ouverts en écriture (avec fopen(filename, "w")) et écrasés par les dernières données. Le risque de perdre des données de fichiers persistantes si l'écrasement et la séparation du miroir du système de fichiers se produisent en même temps est très faible, aucune gestion spéciale n'est nécessaire. L'écriture dans un fichier persistant N'EST PAS suivie d'une synchronisation forcée avec le support de stockage (fsync() n'est pas appelé).

L'écrasement avec les dernières données est effectué après le signalement réussi de l'enregistrement de fichier journal ou des métadonnées correspondants (taille du journal traité et heure de modification) au serveur Zabbix. Cela peut se produire aussi souvent que chaque élément vérifie si le fichier journal continue de changer.

Aucune action spéciale lors de l'arrêt de l'agent.

Après avoir reçu une liste de vérifications actives, l'agent marque les fichiers persistants obsolètes pour suppression. Un fichier persistant devient obsolète si : 1) l'élément de journal correspondant n'est plus surveillé, 2) un élément de journal est reconfiguré avec un emplacement persistent_dir différent de celui d'avant.

La suppression est effectuée avec un délai de 24 heures car les fichiers journaux à l'état NOTSUPPORTED ne sont pas inclus dans la liste des vérifications actives, mais ils peuvent devenir SUPPORTED plus tard et leurs fichiers persistants seront utiles.

Si l'agent est arrêté avant l'expiration de 24 heures, les fichiers obsolètes ne seront pas supprimés car l'agent Zabbix ne reçoit plus d'informations sur leur emplacement depuis le serveur Zabbix.

Nommage et emplacement des fichiers persistants

L'agent Zabbix distingue les vérifications actives par leurs clés. Par exemple, logrt[/home/zabbix/test.log] et logrt[/home/zabbix/test.log,] sont des éléments différents. La modification de l'élément logrt[/home/zabbix/test.log,,,10] en frontend vers logrt[/home/zabbix/test.log,,,20] entraînera la suppression de l'élément logrt[/home /zabbix/test.log,,,10] de la liste des vérifications actives de l'agent et la création de l'élément logrt[/home/zabbix/test.log,,,20] (certains attributs sont transmis lors de la modification dans le frontend/serveur , pas dans agent).

Le nom du fichier est composé de la somme MD5 de la clé d'élément avec la longueur de la clé d'élément ajoutée pour réduire les risques de collisions. Par exemple, l'état de l'élément logrt[/home/zabbix50/test.log,,,,,,,,/home/zabbix50/agent_private] sera conservé dans le fichier persistant c963ade4008054813bbc0a650bb8e09266.

Plusieurs éléments de journal peuvent utiliser la même valeur persistent_dir.

persistent_dir est spécifié en tenant compte des dispositions spécifiques du système de fichiers, des points de montage et des options de montage et de la configuration de la mise en miroir du stockage - le fichier persistant doit se trouver sur le même système de fichiers en miroir que le fichier journal surveillé.

Si le répertoire persistent_dir ne peut pas être créé ou n'existe pas, ou si les droits d'accès pour l'agent Zabbix ne permettent pas de créer/écrire/lire/supprimer des fichiers, l'élément de journal devient NOTSUPPORTED.

Si les droits d'accès aux fichiers de stockage persistants sont supprimés pendant le fonctionnement de l'agent ou si d'autres erreurs se produisent (par exemple, disque plein), les erreurs sont consignées dans le fichier journal de l'agent mais l'élément de journal ne devient NON SUPPORTÉ.

Charge sur les E/S

Le fichier persistant de l'élément est mis à jour après l'envoi réussi de chaque lot de données (contenant les données de l'élément) au serveur. Par exemple, 'BufferSize' par défaut est 100. Si un élément de journal a trouvé 70 enregistrements correspondants, les 50 premiers enregistrements seront envoyés en un seul lot, le fichier persistant sera mis à jour, puis les 20 enregistrements restants seront envoyés (peut-être avec un certain retard lorsque plus de données sont accumulées ) dans le 2e lot, et le fichier persistant sera à nouveau mis à jour.

Actions si la communication échoue entre l'agent et le serveur

Chaque ligne correspondante de l'élément log[] et logrt[] et le résultat de chaque log.count[] et logrt.count[] requièrent un emplacement libre dans la zone de 50% désignée dans le buffer d'envoi de l'agent. Les éléments buffers sont régulièrement envoyés au serveur (ou proxy) et les emplacements de mémoire tampon sont à nouveau libres.

Bien qu'il existe des emplacements libres dans la zone des fichiers journaux désignée dans le buffer d'envoi de l'agent et que la communication échoue entre l'agent et le serveur (ou le proxy), les résultats de la surveillance des fichiers journaux sont accumulés dans le buffer d'envoi. Cela aide à atténuer les échecs de communication ponctuel.

Pendant les échecs de communication plus longs, tous les emplacements de logs sont occupés et les actions suivantes sont effectuées :

• Les vérifications des éléments log[] et logrt[] sont arrêtées. Lorsque la communication est rétablie et que des emplacements sont libérés dans la mémoire tampon, les vérifications reprennent à partir de la position précédente. Aucune ligne correspondante n'est perdue, elles sont juste reportées plus tard.
• Les vérifications log.count[] et logrt.count[] sont arrêtées si maxdelay = 0 (par défaut). Le comportement est similaire aux éléments log[] et logrt[] décrits ci-dessus. Notez que cela peut affecter les résultats de log.count[] et de logrt.count[] : par exemple, une vérification compte 100 lignes correspondantes dans un fichier journal, mais comme il n'y a pas d'espace libre dans la mémoire tampon, la vérification est arrêtée. Lorsque la communication est restaurée, l'agent compte les mêmes 100 lignes correspondantes et 70 nouvelles lignes correspondantes. L'agent envoie maintenant compteur = 170 comme s'il avait été trouvé dans une vérification.
• Les vérifications log.count[] et logrt.count[] avec maxdelay > 0 : s'il n'y a pas eu de "saut" pendant la vérification, alors le comportement est similaire à celui décrit ci-dessus. Si un "saut" sur les lignes du fichier journal a eu lieu, la position après le "saut" est conservée et le résultat compté est ignoré. Ainsi, l'agent essaie de suivre un fichier journal en expansion, même en cas d'échec de la communication

Handling of regular expression compilation and runtime errors

If a regular expression used in log[], logrt[], log.count[] or logrt.count[] item cannot be compiled by PCRE or PCRE2 library then the item goes into NOTSUPPORTED state with an error message. To continue monitoring the log item, the regular expression should be fixed.

If the regular expression compiles successfully, but fails at runtime (on some or on all log records), then the log item remains supported and monitoring continues. The runtime error is logged in the Zabbix agent log file (without the log file record).

Note that the logging of regular expression runtime errors is supported since Zabbix 6.0.21.

The logging rate is limited to one runtime error per check to allow Zabbix agent to monitor its own log file. For example, if 10 records are analyzed and 3 records fail with a regexp runtime error, one record is produced in the agent log.

Exception: if MaxLinesPerSecond=1 and update interval=1 (only 1 record is allowed to analyze per check) then regexp runtime errors are not logged.

zabbix_agentd logs the item key in case of a runtime error, zabbix_agent2 logs the item ID to help identify which log item has runtime errors. It is recommended to redesign the regular expression in case of runtime errors.