1 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 même 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 PROBLEM event generation mode 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 d'associer des événements de problème sur la base des tags. Les tags sont utilisés 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 sur la base d'un tag correspondant.

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

Fonctionnement

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

Ligne1 : Service 1 arrêté
Ligne2 : Service 2 arrêté
Ligne3 : Service 1 a été redémarré
Ligne4 : Service 2 a été redémarré

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

Ligne1 : Service 1 arrêté
Ligne3 : Service 1 a été redémarré #problème de la Ligne 1 fermé

Ligne2 : Service 2 arrêté
Ligne4 : Service 2 a été redémarré #problème de la Ligne 2 fermé

Pour ce faire, vous devez étiqueter ces événements liés, par exemple, avec « 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 mis en correspondance avec 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

Une fois l’élément opérationnel, 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 telle que 'Stopping' afin de signaler des problèmes potentiels :

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

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 du journal contenant la chaîne "Starting" est trouvée :

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

Comme ce n’est pas ce que nous voulons, 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 simplement tous les problèmes. C’est là que le marquage par tags peut aider.

Les problèmes et leurs résolutions peuvent être associés 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
• Les événements OK ferment : 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 de tag à partir des lignes du journal

Si la configuration est correcte, vous pourrez voir les événements de problème marqués par application et associés à leur résolution dans Surveillance → Problèmes.

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

• 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 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 de tag pour extraire les noms, par exemple, du service A et du service B à partir de la macro {ITEM.VALUE} (par ex. 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 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 à les corréler. Ainsi, un message de récupération du service A peut accidentellement fermer un message d’erreur du service B.

• Les tags réels et leurs valeurs 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é, des événements OK ultérieurs avec la même valeur de tag *UNKNOWN* peuvent apparaître et 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 limitation à 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énement similaires pour des problèmes sans rapport.