Pour configurer les notifications de monitor héritées à l’aide de @servicenow-<INSTANCE_NAME> :

1. Dans Datadog, accédez à la page paramètres d’intégration ServiceNow.

2. Accédez à l’onglet Configurer, puis à l’onglet ITOM/ITSM, et enfin à l’onglet monitors.

3. Sous Gérer les notifications de monitor héritées, sélectionnez l’instance pour laquelle vous souhaitez configurer les notifications, puis sélectionnez le tableau dans lequel les notifications de monitor héritées doivent être écrites.

4. Pour valider que l’intégration est correctement configurée, ajoutez @servicenow-<INSTANCE_NAME> dans une notification de monitor ou d’événement. Vous pouvez définir les valeurs Impact et Urgency afin que ServiceNow puisse les utiliser pour calculer la priorité de l’incident. Les données brutes remplissent des lignes dans le tableau intermédiaire et sont transmises au tableau ServiceNow spécifiée par l’intégration.

5. Utilisez des transform maps dans ServiceNow pour personnaliser la transformation des données envoyées aux tableaux intermédiaires.

6. Personnalisez la charge utile de notification avec les variables Datadog disponibles ou des chaînes personnalisées.

Remarque : Impact et Urgency dans les descriptions de monitor ne fonctionnent que pour les configurations de monitor héritées. Pour les monitors basés sur des modèles, configurez le mappage de priorité d’instance. Le champ priority dans les incidents ServiceNow est en lecture seule et ne peut être mis à jour qu’à l’aide de règles de recherche de priorité.

action

Type: Chaîne
L’action effectuée sur le monitor: create, update, acknowledge ou resolve

additional_information

Type: Chaîne
Transformation ITOM: additional_info
Chaîne formatée contenant tous les détails de l’événement

aggreg_key

Type: Chaîne
Clé d’agrégation représentant un hachage de l’ID du monitor d’alerte

alert_cycle_key

Type: Chaîne
Clé représentant un hachage du cycle d’alerte d’un seul monitor (suit Alerte → Avertissement → Résolution)

alert_id

Type: Chaîne
ID du monitor d’alerte

alert_metric

Type: Chaîne
Transformation ITOM: metric_name
Métrique ayant déclenché l’alerte

alert_query

Type: Chaîne
Requête ayant déclenché l’alerte

alert_scope

Type: Chaîne
Périmètre ayant déclenché l’alerte

alert_status

Type: Chaîne
État actuel de l’alerte

alert_title

Type: Chaîne
Nom de l’alerte

alert_transition

Type: Chaîne
Transformation ITSM: (script) -> état
État de transition de l’alerte: Triggered, Warn ou Recovered

assignment_group_sys_id

Type: Référence
Transformation ITSM: assignment_group
Reference Table: Groupe
sys_id ServiceNow pour le groupe d’affectation du gestionnaire basé sur un modèle

business_service_sys_id

Type : Référence
Transformation ITSM : business_service
Reference Table : Service
sys_id ServiceNow pour le service métier du gestionnaire basé sur un modèle

custom_fields

Type : Chaîne
Champs clé-valeur configurés par l’utilisateur formatés sous forme de chaîne convertible en JSON

datadog_tags : Type : Chaîne
Tags Datadog du monitor d’alerte

description : Type : Chaîne
Transformation ITSM : description
Transformation ITOM : description
Description sommaire de l’alerte du monitor

event_details : Type : Chaîne
Transformation ITSM : work_notes
Détails de l’événement avec des liens formatés et cliquables vers Datadog

event_id : Type : Chaîne
ID Datadog de l’événement

event_link : Type : Chaîne
Lien vers l’événement créé à partir de l’alerte du monitor

event_msg : Type : Chaîne
Message de l’événement

event_title : Type : Chaîne
Transformation ITSM : short_description
Titre de l’événement.

event_type : Type : Chaîne
Transformation ITOM : type
Type d’événement

hostname : Type : Chaîne
Transformation ITSM : cmdb_ci
Transformation ITOM : node
Host du monitor affecté

impact

Type : Entier
Transformation ITSM : impact
Valeur d’impact basée sur le mappage défini par l’utilisateur de la priorité du monitor

logs_sample : Type : Chaîne
Échantillon de logs pertinents

monitor_priority

Type : Entier
Transformation ITOM : severity
Priorité du monitor d’alerte sous forme d’entier

org_name : Type : Chaîne
Nom de l’organisation du monitor d’alerte

sys_created_by : Type : Chaîne
Transformation ITSM : caller_id
Créateur de l’enregistrement (généralement le compte API ServiceNow configuré)

ticket_state : Type : Chaîne
Transformation ITSM : state, (script) -> close_code, (script) -> close_notes
Transformation ITOM : (script) -> resolution_notes
État de l’enregistrement ServiceNow : new ou resolved

u_correlation_id : Type : Chaîne
Transformation ITSM : correlation_id
Transformation ITOM : message_key
Combinaison de alert_cycle_key et aggreg_key utilisée pour fusionner les enregistrements vers le même incident cible

urgency

Type : Entier
Transformation ITSM : urgency
Urgence définie à partir du mappage défini par l’utilisateur sur la tuile d’intégration en fonction de la priorité définie par le monitor

user_sys_id

Type : Référence
Transformation ITSM : assigned_to
Reference Table : Utilisateur
sys_id provenant du handle de modèle transmis pour l’utilisateur.

Pour éviter que le tableau de jeu d’importation x_datad_datadog_import_host n’accumule trop de lignes, une règle de vidage automatique a été ajoutée à l’outil Table Cleaner afin de ne conserver que les dernières 24 heures de données. Ce paramètre de configuration peut être modifié selon les besoins en accédant à sys_auto_flush_list.do dans le navigateur de filtres et en allant dans la règle pour le tableau x_datad_datadog_import_host. Le champ Age in seconds peut être mis à jour en conséquence.

Pour créer un mappage de champ personnalisé dans ServiceNow :

1. Cliquez sur l’un des tableaux (par exemple, Datadog Monitors ITSM Tables), puis faites défiler jusqu’en bas de l’enregistrement pour voir le lien vers la transform map associée.

2. Cliquez sur le nom de la transform map pour afficher l’enregistrement :

   En haut se trouvent deux champs importants sur l'enregistrement de transformation : Source table et Target table:

3. Cliquez sur New :

4. Sélectionnez les champs source et cible pour les mappages un à un :

   Ou cochez la case Use source script et définissez les transformations :

Pour mapper des champs personnalisés dans la tuile d’intégration, vous pouvez utiliser le script suivant pour les transform maps Datadog Monitors ITOM et Datadog Monitors ITSM. Dans cet exemple, le champ my_field est défini comme un champ personnalisé dans la tuile d’intégration :

answer = (function transformEntry(source)
{
    var additional_info = JSON.parse(source.additional_info);
    return additional_info.my_field;
})(source);

Notes:

• La source est le tableau de jeu d’importation que vous avez sélectionné (dans cet exemple, Datadog Monitors ITSM Tables) et la cible est votre tableau d’incident (ou tableau d’événement) réel où les événements sont stockés.

• Les mappages de champs se trouvent en bas de l’enregistrement. Certains mappages de base sont inclus. C’est ici que vous sélectionnez les champs à inclure, définissez le format et sélectionnez les champs cibles dans votre instance ServiceNow.

Pour utiliser les informations issues d’alertes corrélées afin de renseigner des valeurs dans ServiceNow, ajoutez un nouveau script de transformation onBefore sous la transform map du tableau Datadog Cases ITSM/ITOM.

Pour renseigner des données dans l’incident ServiceNow, vous devez modifier votre script afin d’analyser les données envoyées depuis Datadog et stockées dans la colonne EM Correlated Alert, et spécifier les champs de l’incident vers lesquels vous souhaitez envoyer les données analysées. Vous trouverez ci-dessous un exemple de script que vous pouvez personnaliser selon vos besoins :

(function runTransformScript(source, map, log, target /*undefined onStart*/ ) {
    // We do not need to process non-correlated-alert events
    if (!source.em_correlated_alert_id) {
        return;
    }

    // Create a GlideRecord for the table
    var gr = new GlideRecord('x_datad_datadog_case_incident_table');
    gr.addQuery('case_id', source.case_id);
    gr.addNotNullQuery('em_correlated_alert_id');
    gr.orderByDesc('sys_created_on');
    gr.query();

    // Ensure we process each alert_id only once
    var seenAlert = {};

    // Add relevant correlated alert fields here
    var alertNames = [];


    // Loop through list of correlated_alerts associated with the same case_id
    while (gr.next()) {
        var emAlertId = gr.getValue('em_correlated_alert_id');

        if (!seenAlert.hasOwnProperty(emAlertId)) {
            seenAlert[emAlertId] = true;
            var changeType = gr.getValue('em_change_type');
            if (changeType == "added") {
                var correlatedAlert = gr.getValue("em_correlated_alert");
                var jsonAlert = JSON.parse(correlatedAlert);

                // Get relevant fields from the JSON event
                var alertName = jsonAlert['alert_message'];
                alertNames.push(alertName);
            }
        }
    }

    // Set the corresponding value on the incident table
    // target.impact = 1;

})(source, map, log, target);

Si vous recevez un message d’erreur dans votre tuile d’intégration Datadog, ou une notification Error while trying to post to your ServiceNow instance :

• Vérifiez que seul le sous-domaine a été utilisé lors de la saisie du nom de votre instance.

• Vérifiez que l’utilisateur que vous avez créé dispose des autorisations requises.

• Vérifiez que le nom d’utilisateur et le mot de passe sont corrects.

Si l’intégration est configurée et qu’une alerte est déclenchée, mais qu’aucun ticket n’est créé :

• Confirmez que le tableau intermédiaire est rempli. Si c’est le cas, le problème vient des mappages et des transformations. Vous pouvez déboguer davantage vos mappages et scripts en accédant à Transform Errors dans ServiceNow.
• Confirmez que vous travaillez avec le tableau intermédiaire que vous avez spécifié dans la tuile.

L’utilisateur ServiceNow a besoin des rôles rest_service et x_datad_datadog.user pour pouvoir accéder aux tables d’importation. Si vous utilisez l’ancienne méthode consistant à envoyer des notifications directement vers le tableau Incident ou Événement, vous avez besoin des autorisations itil et evt_mgmt_integration.

Si vous voyez des mises à jour de Datadog Work Management vers ServiceNow, mais pas de mises à jour de ServiceNow vers Datadog, il s’agit du comportement attendu pour ServiceNow ITOM. La synchronisation bidirectionnelle avec Work Management n’est prise en charge que pour ServiceNow ITSM.

Si un monitor rouvre le même incident au lieu d’en créer un nouveau pour chaque avertissement, assurez-vous qu’il n’est pas défini comme une alerte simple. Convertissez le monitor en multi-alert en le regroupant à l’aide d’un tag dans la métrique. De cette façon, chaque alerte déclenchera un incident distinct.