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

Vue d'ensemble

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

Bien qu'en général un événement OK puisse fermer tous les événements de problème 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 de fichiers journaux, vous pouvez vouloir détecter certains problèmes dans un fichier journal et les fermer individuellement plutôt que tous ensemble.

C'est le cas des déclencheurs dont le paramètre mode de génération d'événements PROBLEM est défini sur Multiple. Ces déclencheurs sont normalement utilisés pour la surveillance des journaux, le traitement des traps, etc.

Dans Zabbix, il est possible de relier des événements de problème en fonction du marquage. Les balises sont utilisées pour extraire des valeurs et créer une identification pour les événements de problème. En tirant parti de cela, les problèmes peuvent également être fermés individuellement en fonction de la balise correspondante.

En d'autres termes, le même déclencheur peut créer des événements distincts identifiés par la balise de l'événement. Les événements de problème peuvent donc être identifiés un par un et fermés séparément en fonction de l'identification fournie par la balise de l'événement.

Comment cela fonctionne

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

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

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

Ligne1: Service 1 stopped
Ligne3: Service 1 was restarted #problem from Line 1 closed

Ligne2: Service 2 stopped
Ligne4: Service 2 was restarted #problem from Line 2 closed

Pour cela, vous devez étiqueter ces événements liés, par exemple, "Service 1" et "Service 2". Cela peut être fait en appliquant une expression régulière à la ligne du journal afin d'extraire la valeur de l'étiquette. Ensuite, lorsque les événements sont créés, ils sont étiquetés respectivement "Service 1" et "Service 2", et le problème peut être associé à la résolution.

Configuration

Élément

Pour commencer, vous pouvez 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 prises en compte, puis allez dans Latest data pour vous assurer que l'élément a commencé à collecter des données.

Déclencheur

Avec l'élément en fonctionnement, vous devez configurer le déclencheur. Il est important de décider quelles entrées du fichier journal méritent votre attention. Par exemple, l'expression de déclencheur suivante recherchera une chaîne comme 'Stopping' pour signaler des problèmes potentiels :

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

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

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

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

Les problèmes et les rétablissements peuvent être mis en correspondance en spécifiant un tag dans la configuration du déclencheur. Les paramètres suivants doivent être définis :

• Mode de génération des événements de problème : Multiple
• L'événement OK ferme : Tous les problèmes si les valeurs des tags correspondent
• Saisissez le nom du tag pour la correspondance des événements

• configurez les tags pour extraire les valeurs des tags à partir des lignes du journal

Si la configuration est correcte, vous pourrez voir les événements de problème tagués par application et associés à leur rétablissement dans Monitoring > Problèmes.

• Les macros indexées font toujours référence au champ Expression de la configuration du déclencheur, et non à l'expression de rétablissement. Par exemple, dans un événement de rétablissement, {ITEM.VALUE1} résoudra la dernière valeur du premier élément dans l'expression de problème au moment du rétablissement. Si l'expression de rétablissement est basée sur un élément différent et que la valeur de l'élément de l'expression de problème change d'ici le rétablissement, les événements auront des tags différents et ne seront pas corrélés.

• Avec deux applications écrivant des messages d'erreur et de rétablissement dans le même fichier journal, un utilisateur peut décider d'utiliser deux tags service dans le même déclencheur avec des valeurs de tag différentes en utilisant des expressions régulières distinctes dans les valeurs des tags pour extraire les noms, par exemple, du service A et du service B à partir de la macro {ITEM.VALUE} (par exemple, lorsque les formats des messages 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 sans correspondance produiront des valeurs de tag vides, et une seule valeur de tag vide dans les événements de problème et OK suffit pour les corréler. Ainsi, un message de rétablissement du service A peut accidentellement fermer un message d'erreur du service B.

• Les tags réels et les valeurs des tags ne deviennent visibles que lorsqu'un déclencheur se déclenche. Si l'expression régulière utilisée est invalide, 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é, il peut apparaître ensuite des événements OK 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 du journal sont longs et que les 255 premiers caractères ne sont pas spécifiques, cela peut également entraîner des tags d'événements similaires pour des problèmes sans rapport.