Calcul de l’impact de l’alerte

  • Rversion finale: Australia
  • Mis à jour 12 mars 2026
  • 12 minutes de lecture

    • Le calcul de l’impact montre l’ampleur d’une panne sur les CI, les services, les alertes et les groupes d’alertes. Le système utilise des facteurs tels que les règles d’impact et les relations CI pour calculer la gravité d’une alerte générée. La gravité apparaît sur l’arborescence des impacts, les cartes des services d’application et les tableaux de bord.

    Les calculs d’impact sont disponibles pour les groupes d’alertes des services d’application. Les facteurs suivants sont utilisés pour calculer l’impact global d’une panne.
    • Règles d’impact.
    • Nombre d’alertes actives connexes.
    • Historique du CI affecté.
    • Relations entre les CI pour un ou des services d’application particuliers.
    • Si l’élément CI inclut un réseau ou des appareils de stockage.
    • Les alertes sur les CI à l’état de maintenance sont exclues du calcul de l’impact.
      Remarque :
      • Les CI sont considérés comme étant en cours de maintenance non seulement lorsqu’une demande de changement active est planifiée, mais également lorsque le champ État du CI est défini sur En cours de maintenance.
      • Lorsqu'un CI enfant passe à l'état de maintenance, le CI parent passe également à l'état de maintenance.
    • Par défaut, l’impact est calculé pour tous les services d’application opérationnels. Le système vous permet toutefois de filtrer le calcul de l’impact par classe de service ou par service d’application individuel. Pour plus d'informations, consultez Ajouter des CMDB tables ou des classes pour le calcul de l’impact et Ajouter des services d’application pour le calcul de l’impact.

    S'il existe une connexion entre les services, l'impact d'un service sur l'autre est également calculé.

    Figure 1. Les calculs d’impact utilisent des informations provenant de diverses sources pour définir la gravité de l’alerte
    Facteurs qui affectent l’état de l’impact

    Comment l’impact est calculé

    Le calcul de l’impact varie en fonction des relations CI d’un ou plusieurs services d’application. D’autres facteurs, tels que les demandes de changement, les chemins d’accès réseau, les chemins de stockage et les CI associés ont tous une incidence sur le calcul de l’impact.

    Services
    Le flux de calcul d’impact suivant s’applique aux alertes pour lesquelles la panne n’affecte pas un réseau ou un stockage réseau. Gestion des événements Effectue les étapes suivantes :
    1. Créez une carte de services. Utilisez les tables Associations d’éléments de configuration de service [svc_ci_assoc] et Relations de CI [cmdb_rel_ci] pour créer des relations enfant-parent dans le ou les services d’application.
    2. S’il n’y a pas de chemin CMDB entre le service et le CI, mais qu’une association apparaît dans la table svc_ci_assoc, affichez une relation dépendante entre le service d’application et le CI. Sinon, ne montrez aucune connexion.
    3. Pour les services d’application, si les CI affectés au service sont également connectés au service dans la CMDB, la carte conserve la hiérarchie entre les CI telle qu’elle apparaît dans la CMDB. Les affectations de service CI s’affichent dans la section Associations d’éléments de configuration de service Service d'application du formulaire. S’il n’y a pas de connexion au service dans la CMDB, les CI apparaissent directement sous les services d’application sur la carte.
    4. Créez l’arborescence des impacts. Évaluez l’ampleur d’une panne de 100 % en panne, de 60 % touchée, de 40 % altérée ou de 20 % altérée. Si les éléments de deux clusters ou plus sont affectés, l’impact est inférieur de 100 %.
    Demandes de changement et état En cours de maintenance

    si une demande de changement active est planifiée pour le CI ou si l’état d’installation du CI est En cours de maintenance, toutes les alertes sur le CI affecté sont exclues du calcul de l’impact. L’onglet Alertes masque également temporairement toutes les alertes correspondantes. L’arborescence des impacts affiche le CI en vert avec la mention (En cours de maintenance). L’arborescence des impacts et la carte de services affichent temporairement les CI en vert.

    Remarque :
    • Les CI sont considérés comme étant en cours de maintenance non seulement lorsqu’une demande de changement active est planifiée, mais également lorsque le champ État du CI est défini sur En cours de maintenance.
    • Lorsqu'un CI enfant passe à l'état de maintenance, le CI parent passe également à l'état de maintenance.

    pour un service, toutes les alertes sur les CI du service sont également masquées dans l’onglet Alertes. L’ensemble du service est affiché en vert sur l’arborescence des impacts. Pour un hôte avec une demande de changement active, les applications hôtes sont considérées comme une seule unité. Toutes les applications enfants sont traitées de la même manière que l’hôte jusqu’à ce que la demande de changement ne soit plus active. Pour plus d’informations, reportez-vous à la section Fonctionnement des alertes avec les CI en maintenance.

    Chemins d’accès réseau
    Pour tenir compte de la redondance du réseau, Gestion des événements un calcul d’impact distinct est utilisé. Vous pouvez voir les changements de topologie ou de chemin d’accès du réseau dans le service d’application. Le flux de calcul d’impact suivant s’applique aux alertes lorsqu’un chemin d’accès réseau est affecté. Gestion des événements Effectue les étapes suivantes :
    1. Créez une carte de service d’application pour le réseau affecté.
      • Utilisez les informations d’ID d’hôte et d’adresse IP cible de l’alerte et le chemin d’accès réseau de la table Chemins d’accès réseau [sa_network_paths].
      • Utilisez les éléments du chemin d’accès réseau qui dérivent de la table Configuration Item (Élément de configuration) [cmdb_ci]. Utilisez également les éléments associés au chemin d’accès de la table Chemin d’accès d’infrastructure aux éléments [sa_infra_path_assoc].
      • Définissez les relations. Le CI d’application a une relation Depends on ::Used by sur un élément du chemin d’accès qui est défini dans la table CI Relationship [cmdb_rel_ci]. Dans la relation, le CI d’application est le parent et l’élément du chemin d’accès réseau est l’enfant.
    2. Calculez une gravité distincte pour chaque élément régulier du chemin. Chaque élément régulier du chemin d’accès apporte sa propre sévérité à ses ancêtres jusqu’au CI de l’application d’où provient le chemin d’accès.
    3. Calculez tous les éléments redondants sur le chemin d’accès avec la règle de redondance en réduisant d’un niveau la gravité sur les CI impactés. Par exemple, si la gravité est Critical, la règle de redondance diminue la gravité d’un niveau à Major.
    4. Créez l’arborescence des impacts. Évaluez l’ampleur d’une panne de 100 % en panne, de 60 % touchée, de 40 % altérée ou de 20 % altérée. Si les éléments de deux clusters ou plus sont affectés, l’impact est inférieur de 100 %.
    Chemins de stockage
    Pour tenir compte de la redondance des appareils de stockage, Gestion des événements un calcul d’impact distinct est utilisé. Vous pouvez afficher les mises à jour de l’arborescence d’impact lorsque la topologie de stockage réseau change à partir du service d’application. Gestion des événements effectue les étapes suivantes pour les alertes qui contiennent des CI de stockage :
    1. Créez une carte de service d’application pour l’appareil de stockage concerné :
      • Utilisez l’unité de stockage dans la table sa_fs_to_storage_path. La définition de l’appareil de stockage utilise les informations du système de fichiers dans le chemin d’accès.
      • Utilisez les éléments du chemin de stockage qui dérivent de la table Configuration Item (Élément de configuration) [cmdb_ci]. Utilisez également les éléments associés au chemin d’accès de la table Chemin d’accès d’infrastructure aux éléments [sa_infra_path_assoc].
      • Définissez les relations. Le CI d’application a une relation Depends on ::Used by sur un élément du chemin d’accès qui est défini dans la table CI Relationship [cmdb_rel_ci]. Dans la relation, le CI d’application est le parent et l’élément dans le chemin de stockage est l’enfant.
    2. Calculez une gravité distincte pour chaque élément régulier du chemin. Chaque élément régulier du chemin d’accès apporte sa propre sévérité à ses ancêtres jusqu’au CI d’application d’origine du chemin d’accès.
    3. Utilisez la règle de redondance pour calculer les éléments redondants dans le chemin d’accès en réduisant d’un niveau la gravité sur les CI impactés. Par exemple, si la gravité est Critical, la règle de redondance diminue d’un niveau jusqu’à Major.
    4. Créez l’arborescence des impacts. Évaluez l’ampleur d’une panne de 100 % en panne, de 60 % touchée, de 40 % altérée ou de 20 % altérée. Si les éléments de deux clusters ou plus sont affectés, l’impact est inférieur de 100 %.
    CI associés

    Lorsque des alertes sont générées pour un CI, des calculs d’impact supplémentaires s’exécutent pour les CI associés. Par exemple, des calculs d’impact supplémentaires s’exécutent pour une dépendance de service d’application à un CI qui ne fait pas réellement partie du service d’application. Ces CI associés ne sont pas détectés dans le cadre du service. Au lieu de cela, les CI connexes sont spécifiés par une définition de relation d’infrastructure.

    Le flux de calcul de l’impact suivant s’applique aux alertes avec des CI qui ont une dépendance à des CI associés et qui sont considérés comme extérieurs au service d’application. Gestion des événements Effectue les étapes suivantes :
    1. Dérivez les relations entre les CI du service d’application et les CI associés. Utilisez les relations, les règles d’impact et les autres données de la table Relations d’infrastructure [em_impact_infra_rel_def].
    2. Ajoutez les CI associés à l’arborescence des impacts et à la liste des alertes sur le tableau de Gestion des événements bord.
      • Utilisez les données de la table Relation d’infrastructure [em_impact_infra_rel_def] pour afficher les liens d’imbrication à l’hôte.
      • Utilisez les tables État de l’impact [em_impact_status] et Historique des alertes [em_alert_history] pour déterminer l’état.

    Règles d’impact

    Les règles d’impact, qui sont utilisées pour le calcul de l’impact, estiment l’ampleur ou la gravité d’une panne en fonction des CI affectés.
    La table Règle d’impact [em_impact_rule] contient des règles d’impact qui affichent les CI, les services d’application et les paramètres d’impact applicables. Les règles d’impact par défaut suivantes sont disponibles.
    Membre de la grappe d’applications
    détermine la façon dont les membres de la grappe d’applications affectent l’impact global de la grappe. Par exemple, si une grappe de trois membres a besoin de 90 % d’influence pour définir la gravité de l’ensemble de la grappe sur Majeure, chaque membre a 30 % d’influence (90 % divisé par 3). La gravité de l’ensemble de la grappe ne peut passer à Majeure que lorsque les trois membres ont une gravité Majeure.
    Vous pouvez configurer différentes règles d’impact par grappe, de sorte que la propagation de l’impact du CI enfant vers le parent (pour le même CI enfant) sera différente. Par conséquent, vous pouvez créer manuellement des groupes de CI (également appelés grappes manuelles) et configurer la règle d’impact au niveau de la grappe pour l’aval vers les enfants de grappe.
    Figure 2. Exemple où le même CI enfant propagera son impact à sa grappe parente différemment dans chaque grappe.
    la gravité du CI enfant est propagée différemment à chaque service parent

    Dans l’exemple ci-dessus, il y a deux points d’entrée. L’amas d’Osaka sur le côté droit comporte trois CI. Le cluster Tokyo sur le côté gauche comporte deux CI. Le serveur de sauvegarde de Tokyo et d’Osaka a des parents communs - le cluster Tokyo et le cluster Osaka. Sur le panneau de droite, vous pouvez voir l’arborescence des impacts où le cluster Tokyo a deux membres du cluster d’applications avec 50 % d’influence chacun et le cluster d’Osaka en a trois avec 34 % d’influence chacun.

    Pour une configuration manuelle de grappe, il existe deux lignes : Impact de l’application et Membre de la grappe d’applications. Les enfants sont affichés car le champ Impact sur a été sélectionné comme parent et non comme service d’application. Dans la ligne Membre de la grappe d’applications, le champ Influence est configuré sur deux. Cela implique que le nombre minimum d’enfants qui échouent (et qu’ils propagent l’échec à leurs parents) est de deux. Le cluster d’Osaka est configuré pour trois. Le pourcentage est différent pour le serveur de sauvegarde de Tokyo et d’Osaka pour chaque cluster (50 % et 34 %). Comme vous pouvez le constater, même si la panne du serveur de sauvegarde de Tokyo et d’Osaka est Red Critical, elle influence les parents différemment. L’amas d’Osaka reste vert même si l’échec de l’amas de Tokyo est Orange Major.

    Cliquez sur un service ou un CI pour afficher les alertes qui lui sont associées. Par exemple, si vous cliquez sur le service d’application de haut niveau, les alertes qui lui sont associées s’affichent dans la zone d’alerte sous la vue de carte lorsque vous sélectionnez Alertes. Les alertes répertoriées sont celles du service sélectionné. Les alertes des services enfants sont répertoriées lorsque ces services sont sélectionnés.

    Les champs d’impact suivants s’affichent lorsque vous sélectionnez Impact.

    Inclusion
    détermine l’impact sur les entités ayant une relation Contient. Cette règle est en lecture seule.
    Dépendances d’infrastructure
    détermine la définition de la propagation de l’impact pour les CI dans les relations d’infrastructure.
    Service d’application CI
    détermine comment l’impact s’applique aux entités parentes ou enfants qui font partie d’un service d’application.
    CI Impact
    s’applique aux services d’application. Détermine la relation entre les membres du service. L’impact des CI enfants sur les CI parents est toujours de 100 %. Par exemple, la gravité de l’impact parent est dérivée du CI enfant avec la gravité la plus élevée.
    Parent de CI dans l’application
    l’application : définit l’impact uniquement sur l’entité parente.
    Chemin d’accès réseau
    détermine comment l’impact s’applique aux entités parents ou enfants qui font partie d’un réseau traditionnel.
    Membre de la grappe du système d’exploitation
    détermine la façon dont les membres de la grappe hôte affectent l’état global de la grappe en fonction d’un pourcentage ou du nombre de membres de la grappe. Par exemple, si un cluster de trois hôtes a besoin de 60 % d’influence pour définir la gravité de la majeure, chaque membre a 20 % d’influence (60 % divisé par 3). La gravité de l’ensemble de la grappe ne peut passer à Majeure que lorsque deux membres ou plus de la grappe ont une gravité Majeure. L’ensemble du cluster est également considéré comme étant en panne.
    Chemin de stockage
    détermine comment l’impact s’applique aux entités parent ou enfant qui font partie d’un réseau de stockage.

    Propriétés

    En plus de configurer des règles d’impact, vous pouvez configurer des propriétés pour le calcul de l’impact.
    Configurez ces propriétés, comme il convient :
    Tableau 1. Propriétés du calcul de l’impact
    Nom de la propriété Description
    evt_mgmt.impact_calculation.alert_group_support Activez la prise en charge des groupes d’alertes.
    evt_mgmt.impact_maintenance.sleep_time_sec Durée minimale, en secondes, pour la vérification de la maintenance du CI : vérifie à la fois le champ État sur le CI et tout calendrier des demandes de changement pour le CI.
    evt_mgmt.impact_calculation.alert_copy_delay Délai après la création ou la mise à jour d’une alerte, avant qu’elle ne soit utilisée pour le calcul et le regroupement de l’impact. Utilisé pour compenser les arrivées tardives ou les règles métier lentes définies sur la table em_alert. Valeur par défaut = 2 000 ms.

    Utilisée lorsque les alertes et les événements sont traités un par un (lorsque la propriété evt_mgmt.max_objs_in_alert_query n’est pas définie ou est définie sur 1).
    evt_mgmt.impact_calculation.alert_copy_delay_when_alerts_are_processed_in_batch_msec Délai après la création ou la mise à jour d’une alerte, avant qu’elle ne soit utilisée pour le calcul et le regroupement de l’impact. Utilisé pour compenser les arrivées tardives ou les règles métier lentes définies sur em_alert table. Valeur par défaut = 30 000 ms.

    Utilisé dans les environnements clients volumineux avec un trafic élevé, lorsque les alertes et les événements sont traités par lots (lorsque la propriété evt_mgmt.max_objs_in_alert_query est définie sur une valeur supérieure à 1).

    Pour plus d’informations, voir Gestion des événements - Calcul de l’impact [KB1157218].