Deux écrans décident de ce que devient chaque alerte reçue :
- Rattachement aux CI : à quel élément de la CMDB l'alerte se rapporte ;
- Règles de traitement : ce qu'il faut en faire, par exemple l'ignorer, prévenir une équipe ou ouvrir un incident.
Ces écrans sont réservés aux groupes Administrateurs Supervision, Administrateurs Service Desk et Administrateurs. On les ouvre depuis la Console des alertes. Chaque décision prise est inscrite dans la Chronologie de l'alerte, avec sa justification.
Rattacher les alertes aux CI
Chaque alerte est rattachée une seule fois, à sa réception. Les règles de rattachement sont essayées dans l'ordre de la liste ; la première qui trouve un CI unique l'emporte. Une règle qui trouve plusieurs CI ne rattache rien, pour éviter une erreur : la règle suivante est essayée. Si aucune règle ne trouve un CI unique, l'alerte reste non rattachée. Sans aucune règle, le nom d'hôte envoyé par l'outil est cherché dans la CMDB.
Cliquez sur Nouvelle règle de rattachement et renseignez :
- Nom, Actif et, si besoin, la Source concernée (par défaut Toutes les sources) ;
- Valeur lue : l'information de l'alerte à utiliser — Hôte (payload.source), Composant, Groupe, Classe, Résumé, ou Détail libre (custom_details) avec son Chemin dans les détails ;
- Extraction (facultative) : une expression régulière qui isole une partie de la valeur. Le premier groupe capturant est cherché, ou à défaut la correspondance entière ;
- Recherche : comment trouver le CI —
- Nom d'hôte : un nom complet trouve aussi le nom court ;
- Adresse IP : celle d'une interface réseau renvoie le poste ou l'équipement ;
- Identifiant externe : les références des imports (Intune, Ivanti, inventaire réseau…) ;
- Valeur d'un champ : avec le Champ CMDB (slug) à comparer ;
- Type de CI (facultatif) : limite la recherche à un type.
Les boutons Monter et Descendre changent l'ordre des règles. Une alerte qui n'a trouvé aucun CI est signalée « Non rattachée à un CI » dans la console.
Si la CMDB est désactivée, aucune alerte n'est rattachée ; les règles de traitement sans condition de CI continuent de s'appliquer.
Les règles de traitement
Les règles sont évaluées dans l'ordre de la liste : la première dont toutes les conditions sont remplies s'applique. Une alerte qu'aucune règle ne prend reste dans la console, sans incident.
Cliquez sur Nouvelle règle, donnez-lui un Nom, puis choisissez :
Conditions (une condition laissée vide est toujours vraie) :
- Source et Gravité minimale ;
- Type de CI ou un CI précis ;
- Texte : cherché sans tenir compte de la casse ni des accents dans le résumé, l'hôte, le composant, le groupe et la classe ;
- Alerte rattachée à un CI : la règle ne prend que les alertes rattachées.
Action :
- Ignorer (bruit) : l'alerte passe au statut Supprimée (bruit), avec le nom de la règle pour motif ;
- Journaliser seulement : l'alerte reste dans la console, rien d'autre ;
- Notifier : l'alerte reste dans la console et un groupe est prévenu ;
- Créer ou mettre à jour un incident : un incident est ouvert dans le Service Desk (voir ci-dessous).
Créer ou mettre à jour un incident
- Occurrences requises … en (minutes) : l'incident n'est ouvert qu'après N occurrences en M minutes. Ce seuil évite d'ouvrir un incident pour une alerte qui apparaît et disparaît aussitôt ;
- Regroupement par CI (minutes) : les alertes d'un même CI dans cette fenêtre partagent un seul incident ; chaque alerte qui le rejoint y ajoute une note interne. Inclure les CI reliés étend le regroupement aux CI reliés directement dans la CMDB ;
- Résolution automatique : l'incident passe à Résolu quand toutes ses alertes sont résolues ; le demandeur confirme ensuite comme d'habitude ;
- Catégorie, Priorité forcée (sinon Calculée (impact × urgence)), Groupe assigné (sinon Routage de la catégorie) ;
- Demandeur de l'incident : un compte de service est conseillé. Laissé vide, c'est l'auteur de la règle ;
- Gravité → impact et urgence : l'impact et l'urgence de l'incident pour chaque gravité d'alerte.
L'incident est lié au CI de l'alerte. Une alerte qui se rouvre ou s'aggrave ajoute une note à l'incident. Un incident déjà résolu ou clos n'est jamais rouvert : une nouvelle alerte ouvre un nouvel incident.
Si le Service Desk est désactivé, les règles « incident » sont tracées sur l'alerte mais n'ouvrent aucun ticket.
Notification
Pour les actions Journaliser seulement, Notifier et Créer ou mettre à jour un incident, la section Notification désigne le Groupe à prévenir ; l'option Personne ne prévient aucun groupe. L'option Prévenir seulement la personne d'astreinte du groupe s'appuie sur le planning d'astreinte du Service Desk ; sans astreinte en cours, tout le groupe est prévenu.
La notification part une fois par alerte, et de nouveau à chaque réouverture. Chacun la reçoit dans sa langue, par la cloche et par e-mail selon ses préférences. Aucune notification n'est envoyée pendant une fenêtre de maintenance ; pour une règle « incident », pas avant que le seuil soit atteint.
Simuler avant d'enregistrer
Simuler sur 7 jours rejoue la règle sur les alertes des 7 derniers jours, sans rien modifier : Alertes examinées, Prises par la règle, Seuil atteint, Incidents estimés, et pour chaque alerte la règle placée avant qui l'aurait déjà prise (Prise avant par).
Ordre des règles
Les boutons Monter et Descendre de la liste changent l'ordre d'évaluation. Placez les règles les plus précises en premier.
Réduire le bruit avec l'IA
Si un fournisseur d'IA est configuré, la carte Réduire le bruit de la liste des règles propose Suggérer des règles. L'IA analyse les alertes répétées des 7 derniers jours qui n'ont ouvert aucun incident et propose au plus cinq règles Ignorer (bruit) ou Journaliser seulement, jamais une règle d'incident. Créer la règle ouvre le formulaire prérempli : rien n'est créé sans votre validation.
Quand l'IA est désactivée, la carte Réduire le bruit n'apparaît pas. Le rattachement, les règles, la simulation et les incidents fonctionnent à l'identique.