Calcul de l'impact de l'alerte

  • Rversion finale: Yokohama
  • Mis à jour 30 janv. 2025
  • 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 divers 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 de l’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 associées.
    • Historique passé du CI impacté.
    • Relations entre les CI pour un ou plusieurs 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 à l'état 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.

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

    Figure 1. Calculs d'impact utilisant des informations provenant de diverses sources pour définir la gravité de l'alerte
    Facteurs qui affectent l’état de l’impact

    Mode de calcul de l'impact

    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 dans lesquelles la panne n'a pas d'incidence sur un réseau ou un périphérique de stockage réseau. Dans Gestion des événements, procédez comme suit :
    1. Créez une carte de services. Utilisez les tables Associations d’éléments de configuration de service [svc_ci_assoc] et Relations CI [cmdb_rel_ci] pour créer des relations enfant-parent dans le ou les services d’application.
    2. S’il n’existe 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, aucune connexion ne s'affiche.
    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 du formulaire service(s) d'application. En l’absence 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. Indiquez l'ampleur d'une panne (en panne à 100 %, impacté à 60 %, altéré à 40 % ou altéré à 20 %). Si les éléments de deux clusters ou plus sont concernés, l'impact indique une panne à 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 d'impact affiche le CI en vert avec la note (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 à l'état 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 d'impact. Pour un hôte avec une demande de changement active, les applications de l'hôte sont considérées comme une seule unité. Toutes les applications enfant 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 en savoir plus, consultez la rubrique Mode de fonctionnement des alertes avec les CI en cours de maintenance.

    Chemins d'accès réseau
    Pour prendre en compte la redondance réseau, Gestion des événements utilise un calcul d'impact distinct. Vous pouvez afficher 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 dans lesquelles un chemin d'accès réseau est impliqué. Procédez comme suit dans Gestion des événements :
    1. Créez une carte de service d’application pour le réseau affecté.
      • Utilisez l'ID hôte et les informations IP cibles de l'alerte, ainsi que 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 provenant de la table Élément de configuration [cmdb_ci]. Utilisez également les éléments associés au chemin d'accès provenant 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 Relation CI [cmdb_rel_ci]. Dans la relation, le CI d'application est le parent et l'élément dans le chemin d'accès réseau est l'enfant.
    2. Calculez une gravité distincte pour chaque élément régulier du chemin d'accès. Chaque élément régulier du chemin d'accès apporte sa propre gravité à ses ancêtres jusqu'au CI d'application à l'origine du chemin d'accès.
    3. Calculez tous les éléments redondants dans le chemin d'accès avec la règle de redondance en réduisant la gravité des CI impactés d'un niveau. 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. Indiquez l'ampleur d'une panne (en panne à 100 %, impacté à 60 %, altéré à 40 % ou altéré à 20 %). Si les éléments de deux clusters ou plus sont concernés, l'impact indique une panne à 100 %.
    Chemins de stockage
    Pour prendre en compte la redondance de l'appareil de stockage, Gestion des événements utilise un calcul d'impact distinct. Vous pouvez afficher les mises à jour de l’arborescence d’impact lorsque la topologie de stockage réseau change par rapport au 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’équipement de stockage affecté :
      • Utilisez l'appareil 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 provenant de la table Élément de configuration [cmdb_ci]. Utilisez également les éléments associés au chemin d'accès provenant 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 Relation CI [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 d'accès. Chaque élément régulier du chemin d'accès apporte sa propre gravité à ses ancêtres jusqu'au CI d'application à l'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é des CI impactés. Par exemple, si la gravité est Critical, la règle de redondance diminue d'un niveau à Major.
    4. Créez l'arborescence des impacts. Indiquez l'ampleur d'une panne (en panne à 100 %, impacté à 60 %, altéré à 40 % ou altéré à 20 %). Si les éléments de deux clusters ou plus sont concernés, l'impact indique une panne à 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, ils 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 connexes qui sont considérés comme extérieurs au service d’application. Gestion des événements Effectue les opérations suivantes :
    1. Dérivez les relations entre les CI du service d’application et les CI connexes. Utilisez les relations, les règles d'impact et d'autres données de la table Relations d'infrastructure [em_impact_infra_rel_def].
    2. Ajoutez des CI associés à l'arborescence des impacts et à la liste d'alertes sur le tableau de bord Gestion des événements.
      • Utilisez les données de la table Relation d'infrastructure [em_impact_infra_rel_def] pour afficher les liens d'imbrication vers 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, utilisées pour le calcul de l'impact, évaluent l'ampleur ou la gravité d'une panne en fonction des CI impacté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 comment les membres de la grappe d'applications affectent l'impact global de la grappe. Par exemple, si un cluster de trois membres a besoin de 90 % d’influence pour définir la gravité de l’ensemble du cluster 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 et ainsi 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 sur sa grappe parente différemment pour chaque grappe
    la sévérité du CI enfant est propagée différemment à chaque service parent

    Dans l’exemple ci-dessus, il y a deux points d’entrée. Le cluster d’Osaka sur le côté droit comporte trois CI. La grappe Tokyo sur le côté gauche comporte deux CI. Le serveur de sauvegarde de Tokyo et d’Osaka a des parents partagés : le cluster Tokyo et le cluster Osaka. Sur le panneau de droite, vous pouvez voir l’arbre 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 grappes, il existe deux lignes : Impact de l’application et Membre de la grappe d’applications. Les enfants sont affichés puisque le champ Impact sur a été sélectionné comme parent et non comme service d’application. Dans la ligne Membre de 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 les serveurs 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 y 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 de 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 parent ou enfant qui font partie d'un service d'application.
    Impact du CI
    s’applique aux services d’application. Détermine la relation entre les membres du service. L'impact des CI enfant aux CI parent est toujours de 100 %. Par exemple, la gravité de l'impact parent dérive du CI enfant avec la gravité la plus élevée.
    Parent de CI dans l'application
    définit l'impact uniquement sur l'entité parent.
    Chemin d'accès réseau
    détermine comment l'impact s'applique aux entités parent ou enfant qui font partie d'un réseau traditionnel.
    Membre du cluster du système d'exploitation
    détermine comment les membres de la grappe hôte affectent l'état global de la grappe en fonction d'un pourcentage ou d'un nombre de membres de grappes. Par exemple, si un cluster à trois hôtes a besoin de 60 % d’influence pour définir la gravité de Major, 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 ou plus de membres ont une gravité Majeure. La grappe entière est également considérée 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 les règles d'impact, vous pouvez configurer des propriétés pour le calcul de l'impact.
    Configurez les propriétés suivantes, le cas échéant :
    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 Délai minimum, en secondes, pour vérifier la maintenance du CI : vérifie à la fois le champ État sur le CI et toute planification de demande de changement pour le CI.
    evt_mgmt.impact_calculation.alert_copy_delay Délai qui se produit après la création ou la mise à jour d'une alerte, avant que celle-ci ne soit utilisée pour le calcul de l'impact et le groupement. Cette propriété permet de compenser les envois tardifs ou les règles métier lentes définies sur la table em_alert. Par défaut = 2 000 ms.

    Cette propriété est 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 qui se produit après la création ou la mise à jour d'une alerte, avant que celle-ci ne soit utilisée pour le calcul de l'impact et le groupement. Cette propriété permet de compenser les envois tardifs ou les règles métier lentes définies sur la table em_alert. 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).