---
sourceDocument: Gestion des opérations IT Australie
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/fr-FR/it-operations-management

 Release :

    - australia

ft:locale :

    - fr-FR

ft:publication_title :

    - Gestion des opérations IT Australie

ft:clusterId :

    - itom

bundleId :

    - itom

workflow :

    - Technology


---

# Regroupement d'alertes basé sur des règles

# Regroupement d'alertes basé sur des règles {#ariaid-title1}

* Rversion finale: Australia
* 
* Mis à jour 12 mars 2026
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 minutes de lecture

Le regroupement d'alertes basé sur des règles est créé par des règles de corrélation des alertes. Ces règles vous permettent de classer manuellement les alertes comme primaires ou secondaires et d'établir une relation entre elles. Utilisez les règles de corrélation des alertes pour regrouper des alertes connexes. La règle s'exécute uniquement pour les nouvelles alertes ou les alertes dont l'état est passé de Fermé/Instable à Ouvert/Rouvert.

Exemple : si le regroupement d'alertes basé sur des règles est appliqué, les alertes secondaires indiquant que les machines virtuelles ou les applications sur le serveur hors ligne sont également en panne sont regroupées sous l'alerte principale, qui est l'alerte racine pour le serveur hors ligne. Vous pouvez afficher le regroupement d'alertes Espace de travail pour l'exploitation des services basé sur des règles dans Liste express (ITOM). Pour plus d'informations, consultez [Affichage des liens entre les alertes dans des groupes d'alertes basés sur des règles](https://servicenow-prod.fluidtopics.net/D80YlLhE~3ReO8kzf1t_0Q "Affichez les connexions entre les alertes d’un groupe d’alertes basé sur des règles à Liste express l’aide de la vue du lien. La vue du lien montre comment les attributs des alertes du groupe sont liés les uns aux autres.").

## Alertes primaires et secondaires

* Alerte primaire : identifie la cause première d'un groupe d'alertes et représente ses alertes secondaires.
* Alerte secondaire : liées au même problème, elles sont regroupées sous l'alerte primaire. L'objectif des alertes secondaires est de déterminer les alertes à supprimer, ce qui réduit le bruit des alertes et vous permet de vous concentrer sur l'alerte primaire.
{#c_EMEventCorrelationRules__ul_eq3_g3g_s5}

## Comment les alertes primaires et secondaires interagissent

Dans le regroupement d'alertes basé sur des règles, l'une des alertes réelles est désignée comme l'alerte primaire. Les conditions de filtre des alertes primaires et secondaires spécifient quelles alertes sont classifiées comme primaires et lesquelles comme secondaires. Les critères de filtre sont appliqués à la table Alerte \[em_alert\].

Dans ce groupe d'alertes, les alertes primaires et secondaires sont visibles, mais les alertes secondaires sont regroupées sous l'alerte primaire. La propriété Conserver l'alerte secondaire ouverte même lorsque l'alerte primaire est fermée. Alerte manuelle ou basée sur une règle (evt_mgmt.rule_based_manual_closure) Contrôle si les alertes secondaires restent ouvertes ou si elles sont fermées lorsque l'alerte primaire est fermée.

Si la propriété n'est pas sélectionnée (c'est-à-dire qu'elle est définie sur Non), une fois l'alerte primaire fermée, la référence parent est supprimée des alertes secondaires (le regroupement est dissous), et les alertes secondaires sont fermées et deviennent autonomes. Si vous cochez la case de la propriété (c'est-à-dire si vous la définissez sur Oui) et que l'alerte primaire est fermée, la référence parent est supprimée des alertes secondaires (le regroupement est dissous), ce qui en fait des alertes ouvertes autonomes.

## Hiérarchie des alertes {#c_EMEventCorrelationRules__alert_heirarchy}

Un seul niveau d'alertes secondaires est autorisé. Dans les situations où une alerte secondaire possède sa propre alerte secondaire, l'application Gestion des événements aplatit la hiérarchie pour ne conserver que deux niveaux.

Par exemple, supposons que l'alerte A est l'alerte primaire et que l'alerte B est l'alerte secondaire. Si l'alerte C devient une alerte secondaire pour l'alerte B, l'application aplatit la hiérarchie de sorte que A reste la alerte primaire et B et C deviennent des alertes secondaires sœurs, un niveau en dessous de A.  
Autre exemple, supposons qu'il existe trois règles de corrélation qui produisent les résultats suivants :

* Règle 1 (avec une valeur d'ordre de 1) : B devient une alerte primaire pour A.
* Règle 2 (avec une valeur d'ordre de 2) : A devient une alerte primaire pour C et D.
* Règle 3 (avec une valeur d'ordre de 3) : E devient une alerte primaire pour A.
{#c_EMEventCorrelationRules__ul_azx_ng1_1v}

Lorsque les alertes B, C, D et E sont déclenchées, elles apparaissent toutes séparément dans la liste d'alertes, car il n'existe aucune corrélation entre elles.  
Lorsque l'alerte A est déclenchée :

1. La règle 1 fait de A une alerte secondaire sous l'alerte B.
2. La règle 2 définit les alertes secondaires C et D sous l'alerte A, et la hiérarchie est aplatie de sorte que A, C et D deviennent des alertes secondaires de l'alerte primaire B.
3. La règle 3 n'est pas appliquée car plusieurs parents ne sont pas autorisés - A a déjà B comme primaire.
{#c_EMEventCorrelationRules__ol_f31_mk1_1v}

Par conséquent, si toutes les alertes sont déclenchées, seul B apparaît comme alerte primaire pour A, D et C, tandis que E reste une alerte autonome.
* **[Créer une règle de corrélation des alertes](https://servicenow-prod.fluidtopics.net/2FsLPtpRydMbFNRKwyxKzg)**   
  Créez une règle de corrélation des alertes pour désigner les alertes primaires et secondaires. L'alerte primaire est identifiée comme la cause première du groupe d'alertes et les alertes secondaires sont regroupées sous l'alerte primaire.