6 Surveillance des fichiers journaux

Aperçu

Zabbix peut être utilisé pour la surveillance centralisée et l’analyse des fichiers journaux, avec ou sans prise en charge de la rotation des journaux.

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

Pour surveiller un fichier journal, vous devez disposer de :

• l’agent Zabbix en cours d’exécution sur l’hôte
• un élément de surveillance des journaux configuré

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 le frontend.
• les serveurs du paramètre ServerActive sont spécifiés pour le traitement des contrôles actifs.

Configuration de l’élément

Configurez un item de surveillance des journaux.

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

Plus précisément, pour les éléments de surveillance des journaux, vous devez saisir :

Remarques importantes

• Le serveur et l’agent conservent la trace de la taille d’un journal surveillé et de sa dernière heure de modification (pour logrt) dans deux compteurs. En outre :
  • L’agent utilise également en interne les numéros d’inode (sur UNIX/GNU/Linux), les index de fichier (sur Microsoft Windows) et les sommes MD5 des 512 premiers octets du fichier journal afin d’améliorer les décisions lorsque les fichiers journaux sont tronqués et pivotés.
  • Sur les systèmes UNIX/GNU/Linux, on suppose que les systèmes de fichiers où sont stockés les fichiers journaux rapportent des numéros d’inode, qui peuvent être utilisés pour suivre les fichiers.
  • Sur 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, des index de fichier sur 64 bits.
    • Sur les systèmes de fichiers ReFS (uniquement à partir de Microsoft Windows Server 2012), des ID de fichier sur 128 bits.
    • Sur les systèmes de fichiers où les index de fichier changent (par ex. FAT32, exFAT), un algorithme de repli est utilisé afin d’adopter une approche raisonnable dans des conditions incertaines lorsque la rotation des fichiers journaux produit plusieurs fichiers journaux avec la même heure de dernière modification.
  • Les numéros d’inode, les index de fichier 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 dernière modification d’un fichier journal (par exemple avec touch) et ne remplacez pas un fichier journal surveillé en recopiant un fichier sous son nom d’origine (cela crée un nouvel inode). Dans l’un ou l’autre cas, Zabbix peut traiter le fichier comme un fichier différent et le relire depuis le début, ce qui peut produire des alertes en double.
  • S’il existe plusieurs fichiers journaux correspondants pour l’élément logrt[] et que l’agent Zabbix suit le plus récent d’entre eux, puis que ce fichier journal le plus récent est supprimé, un message d’avertissement "there are no files matching "<regexp mask>" in "<directory>" est consigné. L’agent Zabbix ignore les fichiers journaux 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 point où il s’était 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 à partir de ce point lorsque l’agent vient juste de démarrer ou a reçu des éléments qui étaient auparavant désactivés ou non pris en charge. Cependant, si l’agent a reçu du serveur un compteur de taille non nul, mais que l’élément logrt[] ou logrt.count[] ne parvient pas à trouver des fichiers correspondants, le compteur de taille est réinitialisé à 0 afin d’analyser depuis le début si les fichiers apparaissent plus tard.
• Chaque fois que le fichier journal devient plus petit que le compteur de taille du journal connu par l’agent, le compteur est réinitialisé à zéro et l’agent commence à lire le fichier journal depuis le début en tenant compte du compteur de temps.
• S’il existe dans le répertoire plusieurs fichiers correspondants ayant la même heure de dernière modification, l’agent essaie alors d’analyser correctement tous les fichiers journaux ayant la même heure de modification et d’éviter de sauter des données ou d’analyser deux fois les mêmes données, bien que cela ne puisse pas être garanti dans toutes les situations. L’agent ne suppose aucun schéma particulier de rotation des fichiers journaux et n’en détermine aucun. Lorsqu’il est confronté à plusieurs fichiers journaux ayant la même heure de dernière modification, l’agent les traite dans un ordre lexicographique décroissant. Ainsi, pour certains schémas de rotation, les fichiers journaux seront analysés et signalés dans leur ordre d’origine. Pour d’autres schémas de rotation, l’ordre d’origine des fichiers journaux ne sera pas respecté, ce qui peut entraîner le signalement des enregistrements de fichiers journaux correspondants dans un ordre modifié (ce problème ne se produit pas si les fichiers journaux ont des heures de dernière modification différentes).
• L’agent Zabbix traite les nouveaux enregistrements d’un fichier journal une fois toutes les Update interval secondes.
• L’agent Zabbix n’envoie pas plus de maxlines d’un fichier journal par seconde. Cette 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.
• Pour trouver la chaîne requise, Zabbix traitera 10 fois plus de nouvelles lignes que la valeur définie dans MaxLinesPerSecond. Ainsi, par exemple, si un élément log[] ou logrt[] a un Update interval de 1 seconde, par défaut l’agent n’analysera pas plus de 200 enregistrements de fichier journal et n’enverra pas plus de 20 enregistrements correspondants au serveur Zabbix lors d’une 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 fichier journal analysés et 1000 enregistrements correspondants envoyés au serveur Zabbix lors d’une vérification. Si Update interval est défini sur 2 secondes, les limites pour une vérification seront 2 fois plus élevées qu’avec un Update interval de 1 seconde.
• En outre, les valeurs log et log.count sont toujours limitées à 50 % de la taille du tampon d’envoi de l’agent, même s’il n’y a pas de valeurs non-log dedans. Ainsi, pour que les valeurs maxlines soient envoyées en une seule connexion (et non en plusieurs connexions), le paramètre BufferSize de l’agent doit être au moins égal à maxlines x 2. L’agent Zabbix peut téléverser des données pendant la collecte des journaux et ainsi libérer le tampon, tandis que l’agent Zabbix 2 arrêtera la collecte des journaux jusqu’à ce que les données soient téléversées et que le tampon soit libéré, ce qui est effectué de manière asynchrone.
• En l’absence d’éléments de journal, toute la taille du tampon de l’agent est utilisée pour les valeurs non-log. Lorsque des valeurs de journal arrivent, elles remplacent les anciennes valeurs non-log selon les besoins, jusqu’aux 50 % désignés.
• Pour les enregistrements de fichier journal de plus de 256kB, seuls les 256kB premiers sont comparés à 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é à nouveau et différemment après le redémarrage de l’agent.
• Remarque spéciale concernant les séparateurs de chemin "\" : si file_format est "file\.log", alors il ne doit pas y avoir de répertoire "file", car il n’est pas possible de définir sans ambiguïté si "." est échappé ou s’il s’agit du premier symbole du nom de fichier.
• Les expressions régulières pour logrt ne sont prises en charge que dans le nom de fichier ; la correspondance par expression régulière sur le répertoire n’est pas prise en charge.
• Sur les plateformes UNIX, un élément logrt[] devient NOTSUPPORTED si un répertoire dans lequel les fichiers journaux sont censés se trouver n’existe pas.
• Sur Microsoft Windows, si un répertoire n’existe pas, l’élément ne devient pas NOTSUPPORTED (par exemple, si le nom du répertoire est mal orthographié dans la clé de l’élément).
• L’absence de fichiers journaux pour un élément logrt[] ne le rend pas NOTSUPPORTED. Les erreurs de lecture des fichiers journaux pour un élément logrt[] sont consignées comme avertissements dans le fichier journal de l’agent Zabbix, mais ne rendent pas l’élément NOTSUPPORTED.
• Le fichier journal de l’agent Zabbix peut être utile pour déterminer pourquoi un élément log[] ou logrt[] est devenu NOTSUPPORTED. Zabbix peut surveiller le fichier journal de son agent, sauf lorsque DebugLevel=4 ou DebugLevel=5.
• La recherche d’un point d’interrogation à l’aide d’une expression régulière, par ex. \?, peut produire des faux positifs si le fichier texte contient des symboles NUL, car ceux-ci sont remplacés par "?" par Zabbix afin de poursuivre le traitement de la ligne jusqu’au caractère de nouvelle ligne.

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

Il peut parfois être utile d'extraire uniquement la valeur intéressante d'un fichier cible au lieu de renvoyer toute la ligne lorsqu'une correspondance avec une expression régulière est trouvée.

Les éléments de journal ont la capacité d'extraire les valeurs souhaitées à partir des lignes correspondantes. Cela est réalisé grâce au paramètre supplémentaire output dans les éléments log et logrt.

L'utilisation du paramètre « output » permet d'indiquer le « groupe de capture » de la correspondance qui nous intéresse.

Ainsi, par exemple

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

doit permettre de renvoyer le nombre d'entrées tel qu'il apparaît dans le contenu suivant :

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

Seul le nombre sera renvoyé, car \1 fait référence au premier et unique groupe de capture : ([0-9]+).

Et, grâce à la possibilité d'extraire et de renvoyer un nombre, cette 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’analyser les lignes les plus récentes dans le délai de maxdelay secondes.

Par défaut, les éléments de surveillance des journaux suivent toutes les nouvelles lignes apparaissant dans les fichiers journaux. Cependant, certaines applications commencent, dans certaines situations, à écrire un très grand nombre de messages dans leurs fichiers journaux. Par exemple, si une base de données ou un serveur DNS est indisponible, de telles applications inondent les fichiers journaux de milliers de messages d’erreur presque identiques jusqu’au rétablissement du fonctionnement normal. Par défaut, tous ces messages seront consciencieusement analysés et les lignes correspondantes seront 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 maxlines configurable (protège le serveur contre un trop grand nombre de lignes de journal correspondantes entrantes) et une limite de 10*maxlines (protège le CPU et les E/S de l’hôte contre une surcharge causée par l’agent lors d’une vérification). Il subsiste néanmoins 2 problèmes avec la protection intégrée. Premièrement, 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 prendre des heures de retard par rapport aux enregistrements les plus récents du journal. Il est fort probable que vous préfériez être informé plus rapidement de la situation actuelle dans les fichiers journaux plutôt que de parcourir d’anciens enregistrements pendant des heures.

La solution à ces deux problèmes consiste à utiliser le paramètre maxdelay. Si maxdelay > 0 est spécifié, à 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 valeurs, l’agent calcule un retard estimé : le nombre de secondes qu’il faudrait pour analyser tous les enregistrements restants dans un fichier journal.

Si le retard ne dépasse pas maxdelay, l’agent continue alors à analyser le fichier journal comme d’habitude.

Si le retard est supérieur à maxdelay, alors l’agent ignore une partie d’un fichier journal en la « sautant » vers une nouvelle position estimée afin que les lignes restantes puissent être analysées dans le délai de 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 le 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 « to byte » 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 se trouver plus loin dans le fichier ou plus tôt.

Selon la comparaison entre la vitesse de croissance et la vitesse d’analyse du fichier journal, vous pouvez ne voir aucun « saut », des « sauts » rares ou fréquents, des « sauts » grands ou petits, voire un petit « saut » à chaque vérification. Les fluctuations de la charge du système et de la latence réseau affectent également le calcul du retard et, par conséquent, le « saut » en avant pour respecter le paramètre maxdelay.

Il n’est pas recommandé de définir maxdelay < update interval (cela peut entraîner de fréquents petits « sauts »).

Remarques sur la gestion de la rotation des fichiers journaux avec « copytruncate »

logrt avec l’option copytruncate suppose que différents fichiers journaux contiennent des enregistrements différents (au moins leurs horodatages sont différents), par conséquent les sommes MD5 des blocs initiaux (jusqu’aux 512 premiers octets) seront différentes. Deux fichiers ayant les mêmes sommes MD5 des 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 de doublons. Cependant, il n’est pas recommandé de produire plusieurs copies de fichiers journaux avec le même horodatage, d’effectuer une rotation des fichiers journaux plus fréquemment que l’intervalle de mise à jour de l’élément logrt[], ni de redémarrer fréquemment l’agent. L’agent essaie de gérer toutes ces situations de manière raisonnablement correcte, mais de bons résultats ne peuvent pas être garantis dans toutes les 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 de contrôles actifs du serveur Zabbix ou du proxy. Pour les métriques log*[], il reçoit la taille du journal traitée et l'heure de modification afin de déterminer à partir de quel point commencer la surveillance du fichier journal. En fonction de la taille réelle du fichier journal et de l'heure de modification signalées 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ée, soit de réanalyser le fichier journal depuis le début.

Un agent en cours d'exécution conserve un ensemble plus important d'attributs pour suivre tous les fichiers journaux surveillés entre les contrôles. Cet état en mémoire est perdu lorsque l'agent est arrêté.

Le nouveau paramètre optionnel 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'utilisation est la surveillance d'un 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 séparés. Sur la copie active, le fichier journal continue de croître et de recevoir de nouveaux enregistrements. L'agent Zabbix l'analyse et envoie au serveur la taille des journaux traités et l'heure de modification. Sur la copie passive, le fichier journal reste inchangé, bien en retard par rapport à 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ée et l'heure de modification que l'agent Zabbix reçoit du serveur peuvent ne pas être valides dans la situation de la copie passive. Pour poursuivre la surveillance du fichier journal à partir de l'endroit où l'agent s'était arrêté au moment de la séparation du miroir du système de fichiers, l'agent restaure son état à partir du fichier persistant.

Fonctionnement de l'agent avec un fichier persistant

Au démarrage, l'agent Zabbix ne connaît rien des fichiers persistants. Ce n'est qu'après avoir reçu une liste de contrôles actifs du serveur Zabbix (proxy) que l'agent voit que certains éléments de journal doivent être sauvegardés par des fichiers persistants dans les 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 avec les données les plus récentes. La probabilité de perdre les données du fichier persistant si l'écrasement et la séparation du miroir du système de fichiers se produisent au même moment est très faible, aucune gestion particulière n'est prévue pour cela. L'écriture dans le fichier persistant n'est PAS suivie d'une synchronisation forcée vers le support de stockage (fsync() n'est pas appelé).

L'écrasement avec les données les plus récentes est effectué après le signalement réussi de l'enregistrement de fichier journal correspondant ou des métadonnées (taille du journal traitée et heure de modification) au serveur Zabbix. Cela peut se produire aussi souvent qu'à chaque vérification d'élément si le fichier journal continue de changer.

Aucune action particulière lors de l'arrêt de l'agent.

Après avoir reçu une liste de contrôles actifs, l’agent marque les fichiers persistants obsolètes en vue de leur 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 utilisé auparavant.

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 contrôles actifs, mais ils peuvent redevenir SUPPORTED plus tard et leurs fichiers persistants seront alors utiles.

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

Nommage et emplacement des fichiers persistants

L'agent Zabbix distingue les contrôles actifs 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] dans le frontend en logrt[/home/zabbix/test.log,,,20] entraînera la suppression de l'élément logrt[/home/zabbix/test.log,,,10] de la liste des contrôles actifs de l'agent et la création de l'élément logrt[/home/zabbix/test.log,,,20] (certains attributs sont conservés lors de la modification dans le frontend/serveur, mais pas dans l'agent).

Le nom du fichier est composé de la somme MD5 de la clé de l'élément, avec la longueur de la clé ajoutée afin de réduire le risque 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 de 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, ainsi que de la configuration de la mise en miroir du stockage ; le fichier persistant doit se trouver sur le même système de fichiers mis 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 de 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 persistant sont supprimés pendant le fonctionnement de l'agent ou si d'autres erreurs surviennent (par exemple, disque plein), les erreurs sont alors consignées dans le fichier journal de l'agent, mais l'élément journal ne devient pas NOTSUPPORTED.

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, la valeur par défaut de BufferSize est 100. Si un élément de journal a trouvé 70 enregistrements correspondants, alors les 50 premiers enregistrements seront envoyés dans un lot, le fichier persistant sera mis à jour, puis les 20 enregistrements restants seront envoyés (éventuellement avec un certain délai, lorsque davantage de données sont accumulées) dans le 2e lot, et le fichier persistant sera de nouveau mis à jour.

Actions en cas d’échec de la communication entre l’agent et le serveur

Chaque ligne correspondante d’un élément log[] et logrt[], ainsi que chaque résultat d’une vérification d’élément log.count[] et logrt.count[], nécessite un emplacement libre dans la zone réservée de 50 % du tampon d’envoi de l’agent. Les éléments du tampon sont régulièrement envoyés au serveur (ou au proxy) et les emplacements du tampon sont de nouveau libérés.

Tant qu’il reste des emplacements libres dans la zone réservée aux journaux du tampon d’envoi de l’agent et que la communication entre l’agent et le serveur (ou le proxy) échoue, les résultats de surveillance des journaux sont accumulés dans le tampon d’envoi. Cela permet d’atténuer les courtes interruptions de communication.

En cas d’interruptions de communication plus longues, tous les emplacements réservés aux journaux 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 libres sont disponibles dans le tampon, les vérifications reprennent à partir de la position précédente. Aucune ligne correspondante n’est perdue, elles sont simplement signalé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 à celui des éléments log[] et logrt[] décrit ci-dessus. Notez que cela peut affecter les résultats de log.count[] et logrt.count[] : par exemple, une vérification compte 100 lignes correspondantes dans un fichier journal, mais comme il n’y a pas d’emplacements libres dans le tampon, la vérification est arrêtée. Lorsque la communication est rétablie, l’agent compte les mêmes 100 lignes correspondantes ainsi que 70 nouvelles lignes correspondantes. L’agent envoie alors count = 170 comme si elles avaient été trouvées lors d’une seule 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, le comportement est similaire à celui décrit ci-dessus. Si un « saut » au-dessus de lignes du fichier journal a eu lieu, alors la position après le « saut » est conservée et le résultat compté est ignoré. Ainsi, l’agent essaie de suivre la croissance d’un fichier journal même en cas d’échec de la communication.

Gestion de la compilation des expressions régulières et des erreurs d'exécution

Si une expression régulière utilisée dans un élément log[], logrt[], log.count[] ou logrt.count[] ne peut pas être compilée par la bibliothèque PCRE ou PCRE2, alors l'élément passe à l'état NOTSUPPORTED avec un message d'erreur. Pour continuer à surveiller l'élément de journal, l'expression régulière doit être corrigée.

Si l'expression régulière est compilée avec succès, mais échoue à l'exécution (sur certains ou sur tous les enregistrements du journal), alors l'élément de journal reste pris en charge et la surveillance continue. L'erreur d'exécution est consignée dans le fichier journal de l'agent Zabbix (sans l'enregistrement du fichier journal).

Le taux de journalisation est limité à une erreur d'exécution par vérification afin de permettre à l'agent Zabbix de surveiller son propre fichier journal. Par exemple, si 10 enregistrements sont analysés et que 3 enregistrements échouent avec une erreur d'exécution d'expression régulière, un enregistrement est produit dans le journal de l'agent.

Exception : si MaxLinesPerSecond=1 et intervalle de mise à jour=1 (un seul enregistrement est autorisé à être analysé par vérification), alors les erreurs d'exécution d'expression régulière ne sont pas consignées.

zabbix_agentd consigne la clé de l'élément en cas d'erreur d'exécution, zabbix_agent2 consigne l'ID de l'élément afin d'aider à identifier quel élément de journal présente des erreurs d'exécution. Il est recommandé de repenser l'expression régulière en cas d'erreurs d'exécution.