|
Manuel de l'administrateur | Table des matières | |
|
La corrélation d’événements permet de surveiller un ou des enchaînement(s) d’événements attendus et consécutifs sur une période de temps bornée. L’apparition ou l’absence de la séquence d’événements attendus permet d’alerter un administrateur d’une anomalie de fonctionnement.
Il est fréquent que dans un contexte de supervision des événements ne doivent déclencher une action qu’après un certain laps de temps. Ce temps étant mis à profit pour recevoir un autre événement qui annulerait le premier.
La corrélation peut de cette façon s’appliquer à tous les événements qui fonctionnent par paires avec un événement d’alarme puis un événement d’acquittement de cette alarme.
Dans le cas des Trap SNMP il sera nécessaire de créer un événement LoriotPro pour chaque Trap (Utilisation des filtres de TRAP) si l’on veut utiliser le module (Plugin) de corrélation.
L’exemple le plus fréquemment rencontré ou la corrélation de Trap se justifie est celui des interfaces réseaux qui peuvent momentanément être hors service (envoi d’un Trap Link down) suivi dans les secondes qui suivent d’un retour à la normal « link up ». La corrélation permet ici de surveiller l’intervalle de temps entre le Link Down et le Link Up et d’informer l’administrateur en cas de non retour à l’état UP dans un délai prédéfinit.
Un nouveau Plugin de service LoriotPro (Pending Events Correlator) associé à des filtres d'événements ou un programme ligne de commande permet de corréler des événements successifs.
Le plugin (Pending Events Correlator) doit être chargé dans les services pour assurer le mécanisme de corrélation.
Pour réaliser de la corrélation d'événement, il faut définir deux filtres d'événements.
Le filtre sur l'événement X doit être satisfait en premier et doit être corrélé avec le filtre associé à l'événement Y.
De manière succinte, l'événement Y doit acquitter l'événement X dans un laps de temps imparti sinon un événement Z est généré.
Pour expliquer le principe d’utilisation de ce plugin il sera fait appel à un exemple simple et classique.
Un host passe en état « down » (il ne répond plus au polling de LoriotPro) mais on désire lui donner le temps de repasser « up » (le host répond de nouveau au polling). Si il ne repasse pas « up » dans un temps donné alors on génère un événement pour prévenir l’administrateur du réseau.
LoriotPro émet un message référencé 101 lorsqu’un host passe down (level 4)
Et un message 100 lorsque le host passe up (level 1 ou 2)
Cette option se configure avec le module Poller Process.
Les paramètres de polling d’un host sont définis dans le module de propriété du host.
Ce host sera down après 4 non réponse (4*5) = 20 s « environ » et un événement 101 sera émit avec les paramètres du host concerné.
Pour réaliser de la corrélation d'événement, il faut définir deux filtres d'événements.
Le filtre sur l'événement X doit être satisfait en premier et doit être corrélé avec le filtre associé à l'événement Y.
De manière succinte, l'événement Y doit acquitter l'événement X dans un laps de temps imparti sinon un événement Z est généré.
Il est possible de définir un filtre sur la réception de l’événement 101 qui va réaliser une action de mémorisation de l’événement.
Le message 101 suivant :
<4> Session ip [12.1.1.250] Router1603 is not longer responding to LoriotPro Polling (old status 3)
Il indique que le host 12.1.1.250 ne répond plus (down) et que son ancien statut était 3.
Le wizard propose de créer un nouveau filtre d’événement.
CHoisir l'option dans les Action Type « Send to correlator Plugin »
La fenêtre de configuration s'affiche:
| Option | Description |
|---|---|
Send Event |
|
At Level |
Le niveau de sévérité de l'événement précédemment défini (0-9) |
if not correlated after |
le temps d’attente en secondes avant d’envoyer un nouveau message avec le numero_event et le level contenant le message. |
Use reference |
une référence (un nombre quelconque mais unique) pour identifier l’événement dans le correlator |
For ip |
l’adresse IP concerné par cet événement, ici la variable %I est utilisée |
With mask |
le mask de l’adresse IP |
Comments |
le message accompagnant l’émission de l’événement ici on réutilise le message d’origine %3%m%3 le message doit être encadré par %3message%3 si il contient des blancs. Il ne doit pas contenir de caractères « . |
On choisit l’option Match All.
Quitter maintenant la création du filtre. Vérifier dans les filtres que votre filtre existe bien.
Maintenant lorsque un message 101 arrive pour ce host il y a un fichier stocké dans le répertoire bin/events
Le plugin de corrélation (Pending Events Correlator) balaye a intervalle régulier ce répertoire et éxecute l'action prévu si l'événements n’est pas acquitté (correlé) à temps.
Exemple d'événement dans la file de traitement (Queue) en attente de corrélation.
20 secondes, dans notre exemple, après la réception de l'événement 101, un événement 100250 de niveau 4 sera émis si l'événement 100 du filtre de correlation n’est pas reçus. Par défaut le plugin (Pending Events Correlator) balaye le répertoire toutes les 20secondes mais il est possible de changer ce paramètre (minimum 5s).
Le message 100250 pourra être filtré à son tour par LoriotPro et réaliser une action d'alerte auprès de l'administrateur du réseau
Il est nécessaire ensuite de définir un filtre (réception de l’événement 100 dans notre exemple) qui va permettre au module plugin (Pending Events Correlator) de réaliser l'action d’acquittement de l’événement 101 traité précédemment.
L’événement 100 est utilisé pour différent type de passe du host dans un état up il faudra donc analyser les variable de l’événement.
le message 100 suivant :
<1> session 12.1.1.250 router-1603-cisco responding to loriotpro polling (old status 1)
Indique que le host 12.1.1.250 était déjà UP mais a un niveau ICMP (1) uniquement. Ce message ne nous intéresse pas.
Nous sommes uniquement intéressé par un message 100 avec l’information suivante :
<1> session 82.250.213.11 linksys wag54g responding to loriotpro snmp polling (old status 4)
Notre filtre sera plus complexe :
Il intègre une recherche sur la chaîne de caractères (strings) (old status 4) pour être sûr qu’il s’agit bien d’un passage du mode down à un mode up.
Le wizard propose de créer un nouveau filtre d’événement.
Sélectionnez l'action d'acquittement d'événement (Ack Correlated Event) dans la liste Action Type
La fenêtre de configuration de la correlation est affichée.
Renseignez les paramètres
Ack event filter reference |
La référence de l'événement à acquitter et défini dans le filtre précédent |
IP |
l’adresse IP concerné par cet événement, ici la variable %I est utilisée |
Mask |
le mask de l’adresse IP |
Numero_event |
Un numéro d’événement généré si l'événement filtré (à corréler) n’est pas acquitté dans le temps imparti (secondes) |
Level |
le level du message renvoyer (0-9) |
Message |
le message accompagnant l’émission de l’événement ici ont réutilise le message d’origine %3%m%3 le message doit être encadré par %3message%3 si il contient des blanc. Il ne doit pas contenir de caractère « . |
Pour les paramètres avancés du filtre
On sélectionne l’option « Match all » pour tous les événements de ce type.
Quitter maintenant la création du filtre. Vérifier dans les filtres que votre filtre existe bien.
A la réception de cet événement un fichier de type ack est créé dans le répertoire bin/events
Si l'événement d'acquittement arrive avant que le délai d'acquittement ne soit expiré alors, le plugin de corrélation n’envoie pas le message 60000 et supprime les fichiers.
On peut vouloir temporiser une action sur l’événement « host down » de façon globale pour éviter les flux de messages « host goes down » en cas de coupure de ligne avec un rétablissement rapide.
Exemple de filtre down sur 101 pour un ensemble de machines (dans notre cas toutes)
Exemple de filtre down sur 100 pour un ensemble de machines
Les fichiers générés seront personnalisés par adresse IP. Dans ce cas car nous utilisons comme variable l’adresse IP du host en défaut.
On sélectionne le programme _EventToFile.exe présent dans le répertoire bin de LoriotPro.
On utilise la syntaxe suivante :
_EvenToFile temps numero ip mask numero_event level %3message%3
Si on désire envoyer un événement sur un acquittement « ack » qui arrive trop tard la syntaxe est la suivante :
_EventToFile ack numero ip mask numero_event level %3message%3
ack |
le mot ack (pour différencié la syntaxe associée a un événement de type down) |
Numéro |
une référence pour identifier l’événement sauvegardé |
IP |
l’adresse IP concerné par cet événement, ici la variable %I est utilisée |
Mask |
le mask de l’adresse IP |
Numero_event |
le numéro d’événement utilisé pour envoyer un événement si cette événement n’est pas acquitté dans (temps) secondes |
Level |
le level du message renvoyer (0-9) |
Message |
le message accompagnant l’émission de l’événement ici ont réutilise le message d’origine %3%m%3 le message doit être encadré par %3message%3 si il contient des blanc. Il ne doit pas contenir de caractère « . |
Il n’y a pas de lien réel entre le fichier généré au « down » et le fichier généré au « up » (autre que des références temporelles – time stamp) si plusieurs fichiers de type down arrive durant la période down+temps alors un fichier de up peut annulé un fichier down qui n’est pas le sien. C’est pour cela que le système ne marche bien que sur des mécanismes down/up et des paramètres de temps cohérent. Les filtres doivent être le plus précis possible.
 www.loriotpro.com |
|