This is a translation of the original English documentation page. Help us make it better.

1 Corrélation d'événements basée sur les déclencheurs

Aperçu

La corrélation d'événements basée sur les déclencheurs permet de corréler des problèmes distincts signalés par un déclencheur.

Bien qu'en général un événement OK puisse fermer tous les événements problématiques créés par un déclencheur, il existe des cas où une approche plus détaillée est nécessaire. Par exemple, lors de la surveillance des fichiers journaux, vous souhaiterez peut-être découvrir certains problèmes dans un fichier journal et les fermer individuellement plutôt que tous ensemble.

C'est le cas des déclencheurs pour lesquels la génération d'événements à problèmes multiples est activée. Ces déclencheurs sont normalement utilisés pour la surveillance des journaux, le traitement des interruptions, etc.

Il est possible dans Zabbix de relier les événements problématiques en fonction du tagging. Les tags sont utilisées pour extraire des valeurs et créer une identification pour les événements problématiques. En profitant de cela, les problèmes peuvent également être fermés individuellement en fonction du tag correspondante.

En d'autres termes, le même déclencheur peut créer des événements distincts identifiés par le tag d'événement. Par conséquent, les événements problématiques peuvent être identifiés un par un et fermés séparément sur la base de l'identification par tag d'événement.

Comment cela fonctionne

Dans la surveillance des journaux, vous pouvez rencontrer des lignes similaires à celles-ci :

Ligne1: Application 1 stopped
       Ligne2: Application 2 stopped
       Ligne3: Application 1 was restarted
       Ligne4: Application 2 was restarted

L'idée de la corrélation d'événements est de pouvoir faire correspondre l'événement problème de Ligne1 à la résolution de Ligne3 et l'événement problème de Ligne2 à la résolution de Ligne4, et fermer ces problèmes un par un :

Ligne1: Application 1 stopped
       Ligne3: Application 1 was restarted #problem from Line 1 closed
       
       Ligne2: Application 2 stopped
       Ligne4: Application 2 was restarted #problem from Line 2 closed

Pour ce faire, vous devez tagger ces événements associés comme, par exemple, "Application 1" et "Application 2". Cela peut être fait en appliquant une expression régulière à la ligne de journal pour extraire la valeur de tag. Ensuite, lorsque des événements sont créés, ils sont taggés respectivement "Application 1" et "Application 2" et le problème peut être associé à la résolution.

Configuration

Elément

Pour commencer, vous souhaiterez peut-être configurer un élément qui surveille un fichier journal, par exemple :

log[/var/log/syslog]

Une fois l'élément configuré, attendez une minute que les modifications de configuration soient récupérées, puis accédez aux Dernières données pour vous assurer que l'élément a commencé à collecter des données.

Déclencheur

Lorsque l'élément fonctionne, vous devez configurer un déclencheur. Il est important de décider à quelles entrées du fichier journal il convient de prêter attention. Par exemple, l'expression de déclencheur suivante recherchera une chaîne telle que 'Stopping' pour signaler des problèmes potentiels :

find(/My host/log[/var/log/syslog],,"regexp","Stopping")=1 

Pour vous assurer que chaque ligne contenant la chaîne "Stopping" est considérée comme un problème, définissez également le Mode de génération d'événement de problème dans la configuration du déclencheur sur 'Multiple'.

Définissez ensuite une expression de récupération. L'expression de récupération suivante résoudra tous les problèmes si une ligne de journal contenant la chaîne "Starting" est trouvée :

find(/My host/log[/var/log/syslog],,"regexp","Starting")=1 

Puisque nous ne voulons pas cela, il est important de s'assurer d'une manière ou d'une autre que les problèmes racines correspondants sont fermés, pas seulement tous les problèmes. C'est là que le marquage peut aider.

Les problèmes et les résolutions peuvent être mis en correspondance en spécifiant un tag dans la configuration du déclencheur. Les réglages suivants doivent être effectués :

  • Mode de génération d'événement de problème: Multiple
  • Un évènement OK ferme: Tous les problèmes si les valeurs de tag correspondent
  • Entrez le nom de la balise pour la correspondance d'événements

  • configurez les tags pour extraire les valeurs de tag des lignes de journal

S'il est configuré avec succès, vous pourrez voir les événements de problème marqués par application et correspondant à leur résolution dans SurveillanceProblèmes.

Étant donné qu'une mauvaise configuration est possible, lorsque des tags d'événement similaires peuvent être créées pour des problèmes non liés, veuillez examiner les cas décrits ci-dessous !

  • Avec deux applications écrivant des messages d'erreur et de récupération dans le même fichier journal, un utilisateur peut décider d'utiliser deux tags * Application * dans le même déclencheur avec des valeurs de tag différentes en utilisant des expressions régulières distinctes dans les valeurs de tag pour extraire les noms de, par exemple, l'application A et l'application B à partir de la macro {ITEM.VALUE} (par exemple, lorsque les formats de message diffèrent). Cependant, cela peut ne pas fonctionner comme prévu s'il n'y a pas de correspondance avec les expressions régulières. Les expressions régulières non correspondantes produiront des valeurs de balise vides et une seule valeur de balise vide dans les événements problème et OK suffit pour les corréler. Ainsi, un message de récupération de l'application A peut accidentellement fermer un message d'erreur de l'application B.
  • Les tags réels et les valeurs de tag ne deviennent visibles que lorsqu'un déclencheur se déclenche. Si l'expression régulière utilisée n'est pas valide, elle est silencieusement remplacée par une chaîne *UNKNOWN*. Si l'événement de problème initial avec une valeur de tag *UNKNOWN* est manqué, des événements OK ultérieurs peuvent apparaître avec la même valeur de tag *UNKNOWN* qui peuvent fermer des événements de problème qu'ils n'auraient pas dû fermer.
  • Si un utilisateur utilise la macro {ITEM.VALUE} sans fonctions de macro comme valeur de tag, la limite de 255 caractères s'applique. Lorsque les messages de journal sont longs et que les 255 premiers caractères ne sont pas spécifiques, cela peut également entraîner des tags d'événement similaires pour des problèmes sans rapport.