Liaison des alertes à un CI hôte spécifique (liaison par défaut)

  • Rversion finale: Australia
  • Mis à jour 16 juin 2026
  • 4 minutes de lecture

    • La liaison d’alertes à des éléments de configuration (CI) à l’aide du champ Nœud ou du champ Identificateur CI garantit une association précise des événements. En comparant la valeur du nœud ou del’identificateur CI d’un enregistrement d’événement, les alertes sont liées au système approprié. Cela améliore la réponse, l’analyse de la cause première et l’évaluation de l’impact en fournissant une visibilité claire sur les actifs affectés.

    Fonctionnement de la liaison par défaut

    Le système peut effectuer la liaison par défaut à l’aide du champ Nœud ou du champ Identificateur CI de l’enregistrement d’événement.

    Lorsqu’un événement entre dans le système, un champ clé comme Nœud est disponible dans l’enregistrement de l’événement. Cependant, il n’existe aucun champ Nœud dans le CI. Au lieu de cela, la valeur du nœud de l’événement est comparée à divers attributs du CI hôte, tels que le nom, le nom de domaine complet (FQDN), l’adresse IP ou MAC. Si une correspondance est trouvée, l’alerte est liée au CI correspondant. Il s’agit de la méthode par défaut pour lier les alertes aux CI.

    La propriété sa.active_operation_status est utilisée par le mécanisme de liaison par défaut, en particulier lors de la liaison via IP/MAC à l’aide du champ de nœud dans l’événement. Lorsqu’un événement tente de se lier à un hôte via le champ de nœud (à l’aide d’IP/MAC), le système ignore les hôtes dont le statut opérationnel n’est pas inclus dans cette propriété et le statut opérationnel de l’hôte ne doit pas non plus être nul. Par défaut, la valeur de la propriété est « 1 », ce qui correspond à Opérationnel. Vous pouvez étendre la liste pour inclure des états supplémentaires, et tout état figurant dans la liste n’est pas ignoré pendant la liaison.

    Exemple : Si sa.active_operational_status = « 1,2 », alors les hôtes opérationnels et non opérationnels sont considérés comme valides pour la liaison. L’attribut status est défini par les valeurs suivantes :
    • 1 – Opérationnel
    • 2 – Non opérationnel
    • 3 – Réparation en cours
    • 4 – Récupération d’urgence en veille
    • 6 – Mis hors service
    Remarque :
    Dans ce processus de liaison, le CI doit être un hôte. Les CI hôtes comprennent les ordinateurs, les systèmes d’exploitation (OS), les commutateurs, les routeurs ou tout type/classe de CI qui étend la table [cmdb_ci_hardware], ce qui signifie que le type ou la classe de CI doit être un composant matériel.

    Si aucune correspondance n’est trouvée à l’aide du nœud, le système examine le champ Identificateur CI sur l’enregistrement de l’événement. L’identificateur CI est une structure JSON contenant des noms de colonnes et des valeurs à des fins de comparaison (par exemple, Nom, Nom de domaine complet, Adresse IP ou Adresse MAC). Le JSON est : {"column_name » :"<column_value>"}. Par exemple, si nous voulons effectuer une liaison à un CI identifié par serial_number dont la valeur est Ordinateur portable Dell Latitude 7420, le JSON est : {"serial_number » :"Ordinateur portable Dell Latitude 7420"}. Si une correspondance est trouvée, l’alerte est liée au CI correspondant.

    Différence entre la liaison avec Node et Identificateur CI

    Dans la liaison par défaut, le système prend en compte tous les champs dans le champ Information supplémentaire et tente de faire correspondre leurs valeurs avec la table de CI. Le champ Identificateur CI permet de spécifier des champs particuliers pour la correspondance, même s’ils ne sont pas présents dans Informations supplémentaires. Ce processus utilise une structure JSON prédéfinie et s’applique uniquement lorsque le CI est un hôte.

    Remarque :
    Même si le nœud ou l’identificateur CI réussit à lier l’alerte au CI, les règles d’événements déterminent davantage la façon dont la liaison se produit à l’aide de la case à cocher Remplacer la liaison par défaut disponible dans les règles d’événements. Cela garantit que les alertes sont correctement liées en fonction de la logique métier, et pas seulement des correspondances directes. Cela garantit que les alertes sont correctement liées en fonction de la logique métier, et pas seulement des correspondances directes.

    Exemple : résolution d’un CI à l’aide de règles de nœud et d’événements

    Imaginez qu’un serveur (Serveur-123) de votre réseau génère un événement. L’enregistrement d’événement contient un champ Nœud avec la valeur « Server-123.example.com ».
    1. Correspondance avec les attributs CI :
      1. Le système vérifie la valeur du nœud par rapport à la CMDB.
      2. Il compare « Server-123.example.com » avec le nom de domaine complet, l’adresse IP, l’adresse MAC ou le nom des CI hôtes existants.
      3. Si une correspondance est trouvée (par exemple, « FQDN » dans la CMDB est aussi « Server-123.example.com »), l’alerte est liée à ce CI.
    2. Application de règles d’événements : même si le nœud résout le serveur 123, des règles d’événements supplémentaires peuvent déterminer si l’alerte doit être liée différemment. Par exemple, une règle d’événement peut spécifier que les alertes du serveur-123 doivent être liées à un CI parent (comme une grappe) au lieu du serveur individuel.