AFFICHER TOUT LE CONTENU

Table des matières

Survol

Le module de gestion des événements doit son bon fonctionnement à la configuration du moteur de corrélation intégré au module. Le présent article explique les différentes configurations à appliquer afin d’exploiter au mieux les fonctionnalités offertes.

Le rôle du moteur de corrélation est de transformer des courriels reçus en événements, d’associer le bon CI en cause, de définir sa catégorisation, de créer automatiquement un incident si les conditions sont réunies, et tenter de déterminer, parmi une liste de CIs en panne, la cause probable de la défaillance.

Articles reliés

Prérequis

Au moins un système apte à livrer des notifications courriel via SMTP.
Au moins une boîte de courriel destinée à recevoir les notifications du système de surveillance, accessible via POP3.
Au moins un compte système capable d’exécuter la tâche d’importation des courriels via MailIntegration.
Le module Configuration configuré de manière analogue au système de surveillance.
Au moins un intervenant ou un groupe assigné à la prise en charge des événements.

Éléments à configurer

Plage de service d’un CI

Destinée à déterminer les périodes pendant lesquelles le CI doit être fonctionnel. Le moteur de corrélation créera un incident si une panne est signifiée pendant la plage de service. Le moteur de corrélation va continuer de surveiller une panne jusqu’à ce que le CI entre dans sa plage de service (déclenchant la création de l’incident) ou que le système de surveillance indique un retour à la normale.

Les plages horaires sont définies dans le menu Outils > Gestion des données de référence… > CI > Plages horaires.

Elles nécessitent au moins une description française et anglaise.
Vous pouvez désigner les jours et les heures qui définissent la plage.
L’option Inclure les jours fériés permet de considérer ou d’ignorer les jours fériés définis dans Outils > Options.
Au besoin, vous pouvez faire dépasser la plage horaire sur la journée suivante, par exemple le lundi, de 6h00 du matin à 1h00 du matin le mardi.
Une fois les plages horaires configurées, chaque CI surveillé devra se voir attribué une plage de service.

Identification d’un responsable de la maintenance d’un CI

Permet d’identifier le groupe ou l’intervenant qui sera responsable de la maintenance d’un type de CI.

La configuration du responsable s’effectue à partir du menu Outils > Gestion des données de référence… > CI > votre type de CI > onglet Maintenance. Le moteur de corrélation assignera les événements et incidents générés au groupe responsable du CI en défaut. Chaque CI va hériter des configurations de son type, mais il pourrait aussi être redéfini directement dans sa fiche.

Relations entre les différents types de CI

Lorsque plusieurs événements sont générés, le moteur de corrélation va tenter de déterminer la source en cause en se fiant aux relations existantes entre les CI.

Avant de pouvoir établir une relation entre deux CI, vous devez :

Définir les types de relation via le menu Outils > Gestion des données de référence > CI > Types de relations.
Configurer les relations acceptées entre deux types de CI donnés via le menu Outils > Gestion des données de référence… > CI > votre type de CI > onglet Relations.

Pour que le moteur de corrélation suive une relation, celle-ci doit être identifiée comme étant Nécessaire au fonctionnement. Pour inverser le sens d’une relation, appuyer sur l’icône de flèches vert et rouge.

Préparation des CI pour la gestion des événements

Les équipements configurés sur votre système de surveillance et vos CI doivent porter des noms identiques pour qu’ils puissent être reconnus dans Octopus. Le moteur de corrélation doit pouvoir suivre une relation établie dans Octopus pour être capable de déterminer la source d’une défaillance. Les relations doivent être faites dans le même sens que ce que votre système de surveillance peut observer.

Nouveaux champs événements

Type des événements

Il existe 3 types d'événements :

Information	Sert à identifier les événements qui contiennent des données factuelles ne nécessitant pas d’action immédiate ou à long terme. Les événements de type informations sont automatiquement marqués comme étant traités.
Avertissement	Sert à identifier les événements qui contiennent des avertissements d’état, sans constituer des exceptions, qui pourraient avoir à être évaluées ou surveillées par un intervenant sans constituer un incident. Ces événements doivent être traités manuellement.
Exception	Sert à identifier les événements qui nécessitent une prise en charge immédiate (sous forme d’incident) de la part du responsable de la maintenance du CI. À la création de l’incident, le système relie automatiquement l’événement à cet incident, et tout autre événement qui pourrait s’appliquer. L’engin de corrélation va effectuer la surveillance du retour des exceptions.

Catégorisation des événements

La catégorisation sert à regrouper un même genre d'événements pour faciliter le tri du travail à faire ou pour analyser des données dans un rapport. Une fois les catégories créées via le menu Outils > Gestion des données de référence... > Événement > Catégories., elles pourront être sélectionnées à partir d'une liste déroulante lors de la création ou la modification des événements.

Source des événements

L’adresse courriel utilisée pour recevoir la notification du système de surveillance sera indiquée dans le champ source.

Règles de traitement des événements

Le module de Gestion des événements traite les événements selon des règles configurables.
Une règle regroupe des informations générales, les critères à satisfaire, la détection automatique du CI en cause, et la détection du retour à la normale dans le cas d’une exception.
La détection du retour à la normale est réservée aux exceptions.
Les règles sont évaluées selon leur rang (1 en premier).
La première à satisfaire les critères sera celle utilisée.
La création des règles de traitement s’exécute via le menu Outils > Gestion des données de référence… > Événements > Règles.

Ce qu'il faut savoir :

À partir du moment qu'un événement est créé et qu'il est associé à un CI, le CI est automatiquement identifié comme non fonctionnel.
Si la même règle de traitement génère un nouveau courriel pour ce CI, aucun autre événement ne sera créé, aucun incident et aucune activité ne sera ajouté dans l'événement et l'incident précédemment créés.
Lorsque le CI est à nouveau fonctionnel, la gestion des événements pour ce CI va reprendre son cours normal.

Paramètre d’une règle de traitement

Une règle de traitement nécessite au minimum un nom, un type et un critère.

Si plusieurs règles de même rang ont des critères qui se chevauchent, un événement sans catégorisation sera créé.

La section Courriel permet de définir les critères basés sur :
- l’expéditeur
- le sujet
- le contenu
- n’importe quelle ligne contenue dans l’entête du message.
La section Détection du CI est utilisée pour tenter d’associer le bon CI à l’événement ou à l’incident. Vous devrez sélectionner :
- Un type de CI et un champ spécifique pour l'activer.
- Indiquer dans quel champ effectuer la recherche du nom (Contenu, Entête, Expéditeur ou sujet).
- Le système parcourra le contenu du champ spécifié pour essayer d'y retrouver le ou les attributs choisis.
- La détection automatique ne fonctionnera que si un seul CI a été identifié comme candidat. Une information ambiguë présentée dans le champ mettra en échec la détection.
La recherche Contient ou Automatique.
- La recherche par défaut va parcourir simplement le champ et tenter de retrouver de manière unique l'information spécifiée.
- Lorsque vous utilisez la recherche par défaut, il n’est pas nécessaire d’utiliser de caractère générique (wildcard).
- Si plusieurs informations sont trouvées de telle sorte que l'identification de la règle ou de l'objet est ambiguë, un événement sans catégorisation ou CI sera créé.
La recherche par Expression régulière (regex).
- La recherche par expression régulière permet de spécifier au système comment il doit traiter le champ pour y retrouver l'information désirée. Celle-ci est normalement utilisée si l'information dans le champ est ambiguë et présente des risques de doublons.
- L'utilisation typique de cette recherche est d'aller chercher une ligne particulière au sein d'un courriel formaté.
- La recherche par expression régulière utilise la spécification de .Net.
- L'expression régulière doit être construite de manière à retourner uniquement la valeur à retrouver.
- Utilisez le site RegexStorm.net, une ressource d'assistance, pour visualiser un exemple de la recherche d'expression régulière.
La section Données de test permet d'ouvrir un courriel déjà existant pour vous aider à configurer la règle. Un crochet vert apparaîtra si vos critères correspondent au courriel ouvert.

Détection du retour de panne

Octopus permet, pour une même règle de type Exception, de suivre autant les événements de panne que de retour à la normale. L’onglet Détection Retour contient les mêmes fonctionnalités que l’onglet de détection de panne.

Les paramètres de détection du CI sont automatiquement hérités de la détection de la panne.
Le champ En attente de retour indique lorsqu’un événement de type exception a une détection de retour configurée et que le retour à la normale n’a pas été signifié par le système de surveillance.
Lorsque de nouveaux événements sont créés pour une panne en attente de résolution, le moteur va simplement les ignorer.

Création automatisée d’incidents

Lorsqu’un courriel est reçu et répond aux critères d’une règle de type Exception, le système crée un incident avec les informations suivantes :

La source des incidents est indiquée comme étant Événement.
Le CI en cause de l’incident est le CI reconnu de l’événement.
L’incident est assigné au responsable de la maintenance du CI reconnu.
Le site est le site par défaut configuré dans Octopus.
Le demandeur et l’utilisateur sont l’utilisateur par défaut configuré dans Octopus.
Le sujet de l’incident est le sujet du courriel.
La description détaillée est le corps du courriel.
L’incident est créé sans priorité.
Le système va créer un incident uniquement pendant la plage de service d’un CI.
- Si c’est reçu à l’extérieur de la plage de service, le système va attendre le début de la plage pour créer l’incident, sauf si un retour à la normale est reçu.
Si le courriel de retour de panne est reçu avant que l’incident soit modifié ou pris en charge, l’incident sera résolu. L'incident ne doit pas être assigné à un intervenant pour qu'il soit résolu automatiquement.

Exemple de fonctionnement du moteur de corrélation

Le système de surveillance détecte que deux serveurs (S1, S2) et un commutateur (C1) sont en panne. Celui-ci envoie les alertes de panne appropriées.

Octopus reçoit les courriels qui sont convertis en événements, chacun contenant son CI en cause.
Le moteur de corrélation détermine que les trois équipements sont en panne dans la plage horaire, ils sont donc candidats à la création d’incidents.
Le moteur de corrélation analyse les événements candidats et détermine que la cause probable de la panne est le commutateur en panne, puisque celui-ci a des relations nécessaires au fonctionnement des deux serveurs.
Un seul incident est créé, il est assigné au groupe de maintenance du commutateur, mais les trois événements y sont reliés.

Délai de création des incidents

Pour pouvoir faire la corrélation des incidents, le moteur attend un certain délai à partir de la réception du premier courriel de panne avant de faire la création de l’incident. Vous devez configurer les délais de création dans les options, en fonction du temps requis par votre système de surveillance.

Retour de panne pour les incidents chapeautant multiples événements

Si des événements sont toujours indiqués comme étant en attente de retour de panne après la résolution de l’incident, un nouvel incident est créé.

Création d’incidents pour des événements orphelins

Si plusieurs exceptions sont reçues pendant le délai et qu’il est impossible de les relier, un incident sera créé pour chaque événement (orphelin). Si vous avez configuré un seuil pour les événements orphelins et qu’il est dépassé, un seul incident sera créé. L’incident sera assigné au groupe d’intervenants commun à tous les CIs, sinon le système va utiliser le groupe responsable par défaut configuré dans les options.

Aidez-nous à améliorer l’article

Gestion des Événements - Module Octopus