Comment réunir ServiceNow et Elasticsearch dans une communication bidirectionnelle

La Suite Elastic (ELK) est utilisée pour Observability et Security depuis si longtemps que nous les proposons désormais comme des solutions prêtes à l'emploi. Cependant, la détection des problèmes et l'identification de la cause première constituent seulement une partie du processus. Il n'est pas rare que les organisations souhaitent intégrer la Suite Elastic à leurs workflows quotidiens afin de résoudre rapidement ces problèmes. Cela implique généralement une intégration avec une forme de framework de suivi des incidents. Certaines équipes utilisent Slack ou des e-mails, tandis que d'autres utilisent des outils comme ServiceNow ou Jira. Dans cette série, divisée en trois parties, nous vous accompagnons dans la configuration de la gestion automatique des incidents pour ServiceNow et Elasticsearch, ainsi que dans la création d'une présentation Canvas pour visualiser, présenter et gérer les incidents.

Dans ce premier blog, nous allons explorer la configuration d'une relation bidirectionnelle entre Elasticsearch et ServiceNow, un outil de gestion de workflow répandu et souvent utilisé pour ses performances en bureau de service. L'idée est de (1) créer automatiquement un ticket via un système d'alerte basé sur les anomalies et pris en charge par le machine learning et (2) de mettre automatiquement à jour Elasticsearch une fois le ticket à jour. Pourquoi ? Pour obtenir un aperçu à 360 degrés de votre écosystème, de la détection des incidents à l'analyse et la gestion. Dans le cadre de ce processus, nous calculons les indicateurs de résilience :

• Temps moyen de reconnaissance (MTTA) : un indicateur essentiel dédié au suivi de la réactivité. Si le MTTA est élevé, cela indique souvent que l'équipe souffre d'une avalanche d'alertes et qu'elle met donc trop de temps à répondre.
• Temps moyen de résolution (MTTR) : idéal pour connaître le temps de résolution des tickets. Il est calculé en fonction du temps moyen qu'il faut à un ticket pour passer de l'état "En cours" à "Résolu" ou "Fermé".
• Temps moyen entre les défaillances (MTBF) : très utile pour mesurer la résilience d'un élément. Le MTBF le plus faible désigne une défaillance rapide et récurrente. Il est mesuré en heures et calculé en divisant le nombre total d'heures d'exécution par le nombre d'incidents lorsqu'il est hors ligne.

Un point de surveillance unique vaut toujours mieux que de jongler entre une multitude d'outils. Présenter le MTTA, le MTTR et le MTBF dans un même outil d'identification et de recherche de données signifie que ces équipes ont accès à la manière dont les applications, services, projets, équipes, départements spécifiques, ou toute autre entité impactent les indicateurs de résilience précédemment cités. En appliquant différentes données Lens sur les mêmes données dans Kibana, vous pouvez fournir des informations pertinentes pour vos équipes SRE, vos analystes SOC et vos dirigeants.

Exemple de projet

Dans ce blog, nous allons utiliser Elasticsearch, ServiceNow et Heartbeat (notre système de monitoring de la disponibilité), et les configurer pour qu'il se produise ce qui suit :

1. Heartbeat surveille en permanence nos applications pour garantir qu'elles sont en ligne et réactives.
2. Watcher (un framework d'alerte intégré à Elasticsearch) crée un ticket d'incident dans ServiceNow lorsqu'une application est hors ligne au-delà de 5 minutes. Cependant, pour réduire le nombre de fausses alertes, il ne fonctionne que quand il n'y a pas un ticket ServiceNow déjà ouvert ou actif pour l'application en question.
3. Alex (moi-même !) attribue le ticket lui-même et commence à l'exploiter en ajoutant des notes.
4. Dès que le ticket est à jour dans ServiceNow, l'enregistrement est mis à jour dans Elasticsearch. 
5. Alex utilise Canvas comme méthode de gestion de suivi des tickets ouverts, des indicateurs MTTA, MTTR et MTBF et des applications les plus problématiques, et bien plus encore.

Le résultat final correspond au tableau de bord Canvas suivant :

Ce projet comprend plusieurs étapes :

1. Installer ServiceNow.
2. Configurer une règle commerciale dans ServiceNow pour mettre à jour automatiquement Elasticsearch.
3. Installer Heartbeat pour le monitoring de nos applications.
4. Configurer les index Elasticsearch. 
5. Créer des transformations pour calculer vos indicateurs sans interruption.
6. Utiliser le machine learning et les alertes pour créer automatiquement le ticket dans ServiceNow, mais uniquement si un ticket n'existe pas déjà.
7. Construire le tableau de bord Canvas cité plus haut en utilisant les fonctions avancées d'Elasticsearch SQL, comme le pivotement et les expressions Canvas. 

Si vous n'avez aucun déploiement Elasticsearch que vous pouvez suivre, vous pouvez profiter d'un essai gratuit de notre solution Elasticsearch Service sur Elastic Cloud, ou l'installer localement sans rien débourser. Si vous ne possédez pas d'instance ServiceNow, vous pouvez déployer une instance de développeur personnelle.

Préparation de ServiceNow

Personnalisation du formulaire de signalement d'incident

Ce blog part du principe que vous avez une toute nouvelle instance de ServiceNow, ce qui n'est pas du tout le cas la plupart du temps. Cependant, les étapes sont très simples à réaliser, même avec une configuration préexistante. Avant tout, nous mettons à jour l'application Incident pour ajouter un nouveau champ au doux nom d'Application afin de suivre quelle application rencontre un problème :

1. Ouvrez l'application Incident dans ServiceNow.
2. Créez un incident temporaire ; les valeurs importent peu.
3. Accédez à l'assistant FormDesign :

4. Pour plus de simplicité, nous ajoutons seulement un champ de chaîne pour suivre le nom de l'application en question. Dans une véritable installation opérationnelle, il vaut sans doute mieux configurer l'application comme une entité spécifique intégrée à ServiceNow. Configurez votre nouveau champ de chaîne selon les paramètres suivants :

5. Enregistrez et revenez au formulaire d'incident pour le configurer en utilisant l'icône et pour personnaliser les champs à afficher.

6. Nous avons à présent un formulaire d'incident avec notre nouveau champ spécifique qui détermine quelle application est dans le pétrin. Maintenant, nous devons configurer ServiceNow de façon à ce qu'il mette automatiquement à jour Elasticsearch dès que des incidents sont enregistrés.

Création d'un utilisateur ServiceNow pour les incidents causés par Elasticsearch

Il est important de connaître l'origine d'un incident. Pour ce faire, ServiceNow fait appel au champ Caller. Il est conseillé de configurer ce champ lors de la création de notre ticket pour que nous sachions qu'il s'agit d'un ticket généré automatiquement. Pour créer un nouvel utilisateur, accédez à l'application dédiée aux utilisateurs de ServiceNow. Créez et enregistrez un nouvel utilisateur à l'aide des champs suivants :

• ID : elastic_watcher
• Prénom : Elasticsearch Watcher
• E-mail : admin@elasticutilities.co

Communications bidirectionnelles ServiceNow

Créer un incident dans ServiceNow consiste simplement en une demande POST à l'API REST, mais la configuration de ServiceNow pour qu'il mette à jour automatiquement Elasticsearch est légèrement différente. Nous utilisons une règle commerciale ServiceNow. Cette règle "monitore" le tableau des incidents, et en cas de modification d'un des champs spécifiques, elle applique une logique pour indexer les changements dans Elasticsearch. Les informations d'identification étant requises pour Elasticsearch, nous allons faire les choses correctement :

1. Créez un nouveau rôle et un nouvel utilisateur dans Elasticsearch (principe du moindre privilège).
2. Configurez le message REST et le profil d'authentification dans ServiceNow.
3. Créez la règle commerciale.

Création du rôle et de l'utilisateur Elasticsearch

Il s'agit d'un processus très bien documenté, nous n'allons donc pas y passer trop de temps. Il nous faut un rôle qui peut uniquement indexer les documents dans l'alias d'indexation servicenow-incident-updates. Il est conseillé d'avoir un rôle spécifique à cette capacité pour adhérer au principe du moindre privilège. J'ai mis en évidence les options ci-dessous, affichant les étapes à suivre pour l'utilisation de Kibana ou de l'API :

Kibana

1. Gestion -> Rôle
2. Créez le rôle
3. Configurez les champs comme suit
   • Indices : "servicenow-incident-updates"
   • Privilèges : "index"

API

Vous pouvez utiliser la console dans Kibana pour :

POST /_security/role/servicenow_updater 
{ 
  "indices": [ 
    { 
      "names": [ "servicenow-incident-updates" ], 
      "privileges": ["index"] 
    } 
  ] 
}

Maintenant, nous créons un utilisateur qui a ce même rôle.

Kibana

4. Gestion -> Utilisateurs
5. Créez l'utilisateur
6. Configurez les champs comme suit
   • Nom d'utilisateur : ServiceNowUpdater
   • Mot de passe : À vous de jouer
   • Rôle : servicenow_updater

API

POST /_security/user/ServiceNowUpdater 
{ 
  "password" : "MODIFIEZ-LE PAR UN BON MOT DE PASSE", 
  "roles" : [ "servicenow_updater" ], 
  "full_name" : "ServiceNow Incident Updater", 
  "email" : "admin@example.com" 
}

Création d'un message REST Elasticsearch et d'un profil d'authentification dans ServiceNow

Maintenant qu'un utilisateur Elasticsearch est configuré pour la fonctionnalité, nous pouvons travailler sur ServiceNow. Dans ServiceNow, ouvrez l'application REST Messages et créez un nouveau dossier. Utilisez le nom "Elasticsearch" et réglez le point de terminaison sur votre point de terminaison Elasticsearch. Quand je l'utilise dans Elastic Cloud, mon point de terminaison est <a href="https://[CloudID].westeurope.azure.elastic-cloud.com:9243">https://[CloudID].westeurope.azure.elastic-cloud.c...</a>.

La prochaine étape est la configuration de l'authentification. Pour ce faire, nous configurons le type d'Authentification sur Basic et nous cliquons sur la loupe située dans le champ du profil d'authentification "Basic". 

Nous créons un nouvel enregistrement de configuration d'authentification de base. Nommez cet enregistrement "ElasticsearchIncidentUpdater", puis configurez les champs du nom d'utilisateur et du mot de passe selon les valeurs indiquées ci-dessus. Pour moi, cela donnerait :

• Nom d'utilisateur : ServiceNowUpdater
• Mot de passe : [MODIFIEZ-LE PAR UN BON MOT DE PASSE]

Enregistrez et revenez au dossier Elasticsearch dans l'application REST Messages. Assurez-vous que le nouveau profil d'authentification de base est utilisé. Si la section "Méthodes HTTP" est disponible, vous devez cliquer sur "Envoyer" et ouvrir à nouveau l'application REST Messages que nous avons nommée plus haut Elasticsearch. 

Cela devrait ressembler à ceci :

Ensuite, nous créons un nouvel enregistrement de méthode HTTP dans ServiceNow. Il y a quelques réglages à faire ici, faites donc bien attention :

1. Cliquez sur le bouton Nouveau à côté de la case "Méthodes HTTP".
2. Configurez le Nom sur UpdateIncident.
3. Configurez la méthode HTTP sur POST.
4. Veillez à ce que la configuration du type d'authentification soit "hériter d'un parent".
5. Reliez votre point de terminaison à votre point de terminaison Elasticsearch (port compris), puis ajoutez-y /servicenow-incident-updates/_doc, par exemple : <a href="https://[CloudID].westeurope.azure.elastic-cloud.com:9243/servicenow-incident-updates/_doc">https://[CloudID].westeurope.azure.elastic-cloud.c...</a>
6. Créez un en-tête HTPP avec le nom du "Type de contenu" et la valeur pour "application/json".
7. Entrez ce qui suit dans le champ de Contenu :

   {"@timestamp": "${timestamp}", "incidentID": "${incidentID}", "assignedTo": "${assignedTo}",  "description": "${description}",  "state": "${state}",  "updatedDate": "${updatedDate}",  "workNotes": "${workNotes}",  "app_name": "${appName}"}
       

8. Créez les variables de substitutions suivantes en utilisant le bouton Nouveau et en précisant les "Noms" spécifiques trouvés dans la capture d'écran ci-dessous (vous devrez peut-être cliquez sur le bouton Envoyer et revenir au point de terminaison avant que le composant de la variable de substitution de l'interface utilisateur ne s'affiche). Sous "Liens associés", vous trouverez un lien indiquant "Autogénérer les variables", je vous conseille de l'utiliser.

9. Cliquez sur Mettre à jour au haut à droite, ce qui vous renvoie au formulaire du message REST.
10. Cliquez sur Mettre à jour pour enregistrer.

Bien, il s'en est passé des choses ! La plupart des étapes devraient être faciles à suivre, mais les étapes 7 et 8 peuvent demander plus d'explications, qu'il vaut mieux effectuer à l'envers. L'étape 8 ajoute des variables au dossier pour qu'au moment d'exécuter la demande, ces variables puissent être substituées dans le contenu dans le message REST sortant. L'étape 7 utilise ces variables et c'est là que nous créons le champ de contenu de la demande POST. Il est important de prendre en compte que le champ de contenu est par la suite envoyé à Elasticsearch. 

Création de la règle commerciale ServiceNow

Cette partie est le composant essentiel nous permettant d'envoyer des mises à jour à Elasticsearch lorsqu'un incident est créé ou mis à jour. Pour ce faire, nous devons ouvrir l'application Règles commerciales dans ServiceNow pour en créer une nouvelle. Cela se déroule en plusieurs étapes, nous devons configurer le tableau d'exécution, l'heure d'exécution et, enfin, la logique d'exécution. Tout d'abord, il lui faut un nom. Saisissez "Mise à jour incident Elasticsearch" dans le champ du nom et nommez le tableau "incident". Pensez bien à sélectionner également la case "Avancés" dans la mesure où nous utilisons un script personnalisé. 

Configurez la case "Horaires d'exécution" de façon à obtenir le résultat suivant :

Cette configuration signifie que la règle commerciale s'exécutera après l'insertion, la mise à jour ou la suppression de l'incident. La règle doit s'exécuter lorsque les champs de l'état, des remarques, d'attribution ou de mise à jour sont à jour.

L'étape suivante est le ciment qui maintient tout ce que nous avons fait jusqu'à maintenant. Nous devons aller dans le tableau Avancé et configurer le script pour qu'il soit identique à cet extrait :

(function executeRule(current, previous) { 
    try { 
        var r = new sn_ws.RESTMessageV2('Elasticsearch', 'UpdateIncident'); 
        r.setStringParameterNoEscape('incidentID', current.number); 
        r.setStringParameterNoEscape('description', current.description); 
        r.setStringParameterNoEscape('updatedDate', current.sys_updated_on); 
        r.setStringParameterNoEscape('assignedTo', current.getDisplayValue("assigned_to")); 
        r.setStringParameterNoEscape('state', current.getDisplayValue("state")); 
        r.setStringParameterNoEscape('workNotes', current.work_notes); 
        r.setStringParameterNoEscape('appName', current.u_application); 
        r.setStringParameterNoEscape('timestamp', new GlideDateTime().getValue()); 
        r.execute(); 
    } catch (ex) { 
    gs.info(ex.message); 
    } 
})(current, previous);

Ce script utilise le REST message d'Elasticsearch que nous avons créé. Plus précisément, il utilise la demande POST "UpdateIncident", propage les variables de substitution créées avec les champs pertinents de l'incident, puis l'envoie vers servicenow-incident-updates dans Elasticsearch.

Enregistrez, et vous voilà prêt à vous lancer.

Utilisation de Heartbeat pour monitorer nos applications

L'une des questions auxquelles répond ce monitoring de la disponibilité est : "Est-il en forme ou mal en point ?" Pour réaliser le diagnostic, il utilise les données générées par Heartbeat. Heartbeat envoie périodiquement des rappels au point de terminaison via TCP, HTTP ou ICMP, regroupant une partie de l'histoire pour Observability. Connaître si votre hôte, service, site web ou API est en direct est important afin de comprendre la disponibilité de votre écosystème. Heartbeat va encore plus loin en rassemblant les temps et les codes de réponse. Ajouté aux logs, aux indicateurs et aux données APM font de la connexion et de la corrélation de l'activité au sein de votre écosystème un jeu d'enfants.

Les premiers pas avec Heartbeat sont à la portée de tous. Il suffit de suivre les étapes indiquées dans la documentation de Heartbeat.

Pour ce projet, j'ai configuré Heartbeat pour analyser quatre services. Voici un extrait du fichier heartbeat.yml : 

heartbeat.monitors: 
- name: "Authentication Service" 
  type: http 
  urls: ["192.168.1.38/status"] 
  schedule: '@every 1m' 
  check.response.status: 200   
- name: "Search Service" 
  type: http 
  urls: ["192.168.1.109/status"] 
  schedule: '@every 1m' 
  check.response.status: 200 
- name: "Frontend" 
  type: http 
  urls: ["192.168.1.95/status"] 
  schedule: '@every 1m' 
  check.response.status: 200 
- name: "API Gateway" 
  type: http 
  urls: ["192.168.1.108/status"] 
  schedule: '@every 1m' 
  check.response.status: 200

Communications bidirectionnelles engagées !

Et le tour est joué ! Nous ingérons des données de disponibilité dans Elasticsearch, qui se connecte ensuite à ServiceNow dans le cadre d'une communication bidirectionnelle. Comme indiqué plus haut, cela fait partie d'une série en trois étapes. Si vous voulez aller plus loin, passez à la partie 2, qui couvre la configuration d'Elasticsearch afin qu'en cas de problème, un incident soit créé dans ServiceNow. 

Tenté par un petit essai ? La manière la plus simple de procéder est d'utiliser Elastic Cloud. Connectez-vous à la console Elastic Cloud ou inscrivez-vous pour un essai gratuit de 14 jours. Vous pouvez suivre les étapes ci-dessus sur votre instance ServiceNow ou lancer une instance de développeur personnelle.

De plus, si vous souhaitez rechercher parmi les données de ServiceNow avec d'autres sources comme GitHub, Google Drive, etc., Elastic Workplace Search possède un connecteur ServiceNow intégré. Workplace Search vous offre une expérience de recherche uniforme pour vos équipes, avec affichage des résultats pertinents dans l'ensemble des sources de contenu. Il est également inclus dans votre essai Elastic Cloud.

Pensez bien à vérifier l'application de disponibilité de Kibana. Vous pouvez étendre la configuration de mon jouet Heartbeat de façon à analyser votre écosystème et commencer à monitorer ses performances tout en vérifiant le statut du certificat TLS.