Cómo conectar ServiceNow y Elasticsearch para la comunicación bidireccional

El Elastic Stack (ELK) se ha usado para observabilidad y seguridad durante muchos años, tanto que ahora ofrecemos las dos como soluciones listas para usar. Sin embargo, identificar problemas y encontrar la causa raíz es solo una parte del proceso. A menudo, las organizaciones desean integrar el Elastic Stack en sus flujos de trabajo diarios para poder resolver esos problemas rápidamente. Por lo general, esto implica la integración con algún tipo de marco de trabajo de seguimiento de incidentes/tickets. Algunos equipos usan Slack o correos electrónicos, mientras que otros usan herramientas como ServiceNow o Jira. En esta serie de tres partes, te guiaremos en la configuración de ServiceNow y Elasticsearch para automatizar la gestión de incidentes, así como en la creación de un panel de trabajo Canvas para visualizar, presentar y gestionar incidentes.

En este primer blog, exploraremos la configuración de una relación bidireccional entre Elasticsearch y ServiceNow, una popular herramienta de gestión de flujo de trabajo que se usa a menudo por su capacidad de mesa de servicio. La idea es (1) crear un ticket automáticamente a través de alertas basadas en anomalías desarrolladas por machine learning y (2) actualizar Elasticsearch automáticamente cada vez que se actualice ese ticket. ¿Por qué? Para obtener una visión general completa de 360 grados de todo tu ecosistema, desde la detección de incidentes hasta la investigación y la gestión. Como parte de este proceso, calcularemos estas métricas de resistencia:

• Tiempo medio de reconocimiento (MTTA): una métrica clave que se usa para rastrear la capacidad de respuesta. Si el MTTA es alto, a menudo puede indicar que el equipo está sufriendo un desbordamiento de alertas y, por lo tanto, tarda demasiado en responder.
• Tiempo medio de resolución (MTTR): excelente para ver cuánto tardan los tickets en resolverse. Esto se calcula en función del tiempo promedio que tarda un ticket en pasar del estado "En curso" a "Resuelto" o "Cerrado".
• Tiempo medio entre fallas (MTBF): útil para comprender qué tan resistente es algo. El MTBF más bajo significa que falla rápidamente y con frecuencia. Esto se mide en horas y se calcula dividiendo el total de horas de funcionamiento por el número de incidentes en los que está sin conexión.

Un único panel siempre es mejor que alternar entre una gran cantidad de herramientas. Exponer MTTA, MTTR y MTBF en la misma herramienta usada para identificar y buscar los datos significa que esos equipos pueden ver cómo aplicaciones, servicios, proyectos, equipos, departamentos o cualquier entidad específicos comienzan a afectar las métricas de resistencia anteriores. Al aplicar diferentes lentes sobre los mismos datos en Kibana, puedes proporcionar información seleccionada para tus SRE, analistas de SOC y ejecutivos.

Proyecto de ejemplo

En este blog, usaremos Elasticsearch, ServiceNow y Heartbeat (nuestro monitor de tiempo de actividad) y los configuraremos para que ocurra lo siguiente:

1. Heartbeat observa continuamente nuestras aplicaciones para asegurarse de que estén en línea y respondan adecuadamente.
2. Watcher (un marco de trabajo de alerta integrado en Elasticsearch) crea un ticket de incidente en ServiceNow cuando una aplicación ha estado inactiva durante más de 5 minutos, pero, para reducir la fatiga de las alertas, solo lo hace cuando no hay un ticket de ServiceNow abierto o activo para la aplicación específica.
3. Alex (¡yo!) se asigna el ticket a sí mismo y comienza a trabajar en él agregando notas.
4. Siempre que el ticket se actualiza en ServiceNow, el registro se actualiza en Elasticsearch. 
5. La gerencia de Alex usa Canvas para realizar un seguimiento de los tickets abiertos, MTTA, MTTR, MTBF, qué aplicaciones son las más problemáticas y mucho más.

El resultado final será el siguiente dashboard de Canvas:

Habrá algunas secciones en este proyecto:

1. Configurar ServiceNow
2. Configurar una regla comercial en ServiceNow para actualizar Elasticsearch automáticamente
3. Configurar Heartbeat para monitorear nuestras aplicaciones
4. Configurar índices de Elasticsearch 
5. Crear algunas transformaciones para calcular continuamente nuestras métricas
6. Usar machine learning y las alertas para crear automáticamente el ticket en ServiceNow, pero solo si no existe un ticket
7. Crear el dashboard de Canvas anterior usando Elasticsearch SQL avanzado, como la reorganización y las expresiones de Canvas 

Si no tienes un despliegue de Elasticsearch para seguir, puedes activar una prueba gratuita de nuestro Elasticsearch Service en Elastic Cloud o instalarlo de forma gratuita localmente. Y si no tienes una instancia de ServiceNow, puedes activar una instancia de desarrollador personal.

Preparación de ServiceNow

Personalizar el formulario Incidente

Este blog supone que tienes una instancia limpia y completamente nueva de ServiceNow; la mayoría de las veces, este no es el caso. Sin embargo, los pasos son muy simples incluso con una configuración existente. Para empezar, actualizaremos la app Incident (Incidente) para que agreguemos un nuevo campo llamado Aplicación para rastrear qué aplicación tiene un problema:

1. Abre la app Incident (Incidente) en ServiceNow.
2. Crea un incidente temporal; los valores realmente no importan.
3. Ve al asistente de Form Design (Diseño de formulario):

4. Para hacerlo simple, solo agregaremos el campo String (Texto) para rastrear el nombre de la aplicación en cuestión. En una configuración de producción real, probablemente sea mejor configurar la aplicación como una entidad específica dentro de ServiceNow. Configura tu nuevo campo String (Texto) con la siguiente configuración:

5. Guárdalas y vuelve al formulario de incidentes y configúralo usando el ícono para personalizar los campos que están presentes.

6. En este punto, tenemos un formulario de Incidente con nuestro nuevo campo específico, que determina qué aplicación está en un aprieto. Ahora, necesitamos configurar ServiceNow para que actualice automáticamente Elasticsearch cuando nuestros incidentes se actualicen de alguna manera.

Crear un usuario de ServiceNow para los incidentes creados por Elasticsearch

Es importante conocer el origen de un incidente y, para ello, ServiceNow utiliza el campo Caller (Llamador). Debemos configurar este campo cuando creamos nuestro ticket para que sepamos que es un ticket generado automáticamente. Para crear un nuevo usuario, ve a la app Users (Usuarios) dentro de ServiceNow y crea y guarda un nuevo usuario con los siguientes campos:

• ID: elastic_watcher
• Nombre: Elasticsearch Watcher
• Correo electrónico: admin@elasticutilities.co

Comunicaciones bidireccionales de ServiceNow

Crear un incidente en ServiceNow es una simple solicitud POST de la API REST, pero configurar ServiceNow para que actualice automáticamente Elasticsearch es ligeramente diferente. Vamos a aprovechar una regla comercial de ServiceNow. Esta regla "monitoreará" la tabla de incidentes y, si alguno de los pocos campos especificados cambia, ejecutará alguna lógica que indexará los cambios en Elasticsearch. Como se requieren credenciales para Elasticsearch, vamos a hacer las cosas correctamente:

1. Crear un nuevo rol y usuario en Elasticsearch (principio de privilegio mínimo)
2. Configurar el mensaje REST y el perfil de autenticación en ServiceNow
3. Crear la regla comercial

Crear el rol y el usuario de Elasticsearch

Este es un proceso muy bien documentado, por lo que no pasaré mucho tiempo con esto. Necesitamos tener un rol que solo pueda indexar documentos dentro del alias de índice servicenow-incidente-updates. Se recomienda tener un rol específico para que esta capacidad se adhiera al principio de privilegio mínimo. He descrito las opciones a continuación, mostrando los pasos para usar Kibana o la API:

Kibana

1. Management (Administración) -> Role (Rol)
2. Crear rol
3. Establece los campos en lo siguiente
   • Índices: servicenow-incident-updates
   • Privilegios: index

API

Puedes usar la consola de Kibana para esto:

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

Ahora, creamos un usuario que tenga ese rol.

Kibana

4. Management (Administración) -> Users (Usuarios)
5. Crear usuario
6. Establece los campos en lo siguiente
   • Nombre de usuario: ServiceNowUpdater
   • Contraseña: usa tu iniciativa
   • Rol: servicenow_updater

API

POST /_security/user/ServiceNowUpdater 
{ 
  "password" : "CAMBIA ESTO A ALGO BUENO", 
  "roles" : [ "servicenow_updater" ], 
  "full_name" : "ServiceNow Incident Updater", 
  "email" : "admin@example.com" 
}

Crear un mensaje REST de Elasticsearch y un perfil de autenticación en ServiceNow

Ahora que Elasticsearch tiene un usuario configurado para la funcionalidad, podemos trabajar en ServiceNow. En ServiceNow, abre la aplicación REST Messages (Mensajes REST) y crea un nuevo registro. Establece el nombre en "Elasticsearch" y establece el endpoint a tu endpoint de Elasticsearch. Como lo estoy ejecutando en Elastic Cloud, mi endpoint es https://[CloudID].westeurope.azure.elastic-cloud.c....

Nuestro siguiente paso es configurar la autenticación. Para hacer esto, configuramos el Authentication type (Tipo de autenticación) en Basic (Básico) y hacemos clic en la lupa en el campo Basic auth profile (Perfil de autenticación básico). 

Vamos a crear un nuevo registro de configuración de autenticación básica. Establece el nombre de este registro en "ElasticsearchIncidentUpdater" y establece el campo de nombre de usuario y contraseña en los valores respectivos usados anteriormente. En mi caso, sería:

• Nombre de usuario: ServiceNowUpdater
• Contraseña: [CAMBIA ESTO A ALGO BUENO]

Guarda este registro y vuelve al registro de Elasticsearch en la app REST Message (Mensajes REST). Asegúrate de que se esté utilizando nuestro nuevo perfil de autenticación básico. Si la sección “HTTP Methods” (Métodos HTTP) está visible, deberás hacer clic en Submit (Enviar) y luego volver a abrir REST Message (Mensajes REST) que llamamos Elasticsearch arriba. 

Debería verse así:

A continuación, crearemos un nuevo registro de método HTTP en ServiceNow. Hay algunas cosas que hacer aquí, así que presta mucha atención:

1. Haz clic en el botón New (Nuevo) junto a donde dice "HTTP Methods" (Métodos HTTP).
2. Establece el nombre en UpdateIncident.
3. Establece el método HTTP en POST.
4. Asegúrate de que el tipo de autenticación esté configurada para heredar de la principal.
5. Establece el endpoint a tu endpoint de Elasticsearch (incluido el puerto) y luego adjúntale /servicenow-incident-updates/_doc, por ejemplo: https://[CloudID].westeurope.azure.elastic-cloud.c...
6. Crea un encabezado HTTP con el nombre de "Content-Type" y el valor de "application/json".
7. Establece el campo Content (Contenido) en:

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

8. Crea las siguientes sustituciones de variables utilizando el botón New (Nuevo) y especificando los "Nombres" especificados que se encuentran en la siguiente captura de pantalla (es posible que debas hacer clic en el botón Submit [Enviar] y volver al endpoint antes de que se muestre el componente de UI de sustitución de variables). En "Related Links" (Enlaces relacionados) hay un enlace que dice "Auto-generate variables" (Generar variables automáticamente); te recomiendo que lo uses.

9. Haz clic en Update (Actualizar) en la parte superior derecha, que te lleva de regreso al formulario de mensaje REST.
10. Haz clic en Update (Actualizar) para guardar.

De acuerdo, ¡han pasado muchas cosas! La mayor parte debería ser fácil de seguir, pero los pasos 7 y 8 pueden necesitar una explicación, que es mejor hacerla al revés. El paso 8 agrega variables al registro para que, al realizar la solicitud, esas variables puedan ser sustituidas en el contenido del mensaje REST saliente. El paso 7 aprovecha esas variables y construimos el campo de contenido de la solicitud POST. Es importante tener en cuenta que este campo de contenido se enviará a Elasticsearch. 

Crear la regla comercial de ServiceNow

Esta sección es el componente central que nos permite enviar actualizaciones a Elasticsearch cada vez que se crea o actualiza un incidente. Para hacer esto, necesitamos abrir la app Business Rules (Reglas comerciales) en ServiceNow y crear una nueva regla. Hay algunas partes para hacer esto; necesitamos configurar la tabla para que se ejecute, cuándo ejecutar y luego la lógica de ejecución. Primero, necesita un nombre. Establece el campo de nombre en "Incidente de actualización de Elasticsearch" y establece la tabla en "incidente". Aquí es importante seleccionar también el cuadro "Advanced" (Avanzado) ya que vamos a utilizar un script personalizado. 

Configura el cuadro "When to run" (Cuándo ejecutar) para que se vea así:

Esta configuración significa que la regla comercial se ejecutará después de que se haya insertado, actualizado o eliminado el incidente. La regla debe ejecutarse cuando se actualizan el estado, las notas de trabajo, el campo asignado o actualizado.

Nuestro siguiente paso es el pegamento que une todo lo que hemos hecho. Necesitamos ir a la pestaña Advanced (Avanzado) y configurar el script para que sea el mismo que este fragmento:

(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);

Este script usa el mensaje REST de Elasticsearch que creamos. En particular, usa la solicitud de POST UpdateIncident, completa las sustituciones de variables que creamos con los campos relevantes del incidente y luego lo envía a servicenow-incidente-updates dentro de Elasticsearch.

Guárdalo y ya está listo.

Usar Heartbeat para monitorear nuestras aplicaciones

Una de las preguntas que responde el monitoreo de tiempo de actividad es "¿Está activo o inactivo?". Para ello, usa los datos que genera Heartbeat. Heartbeat hace ping periódicamente a un endpoint usando TCP, HTTP o ICMP, reuniendo parte de la historia para la observabilidad. Saber si tu host, servicio, sitio web o API está activo es importante para comprender la disponibilidad de tu ecosistema. Heartbeat lleva esto más allá al recopilar tiempos de respuesta y códigos de respuesta. Esto, combinado con registros, métricas y datos de APM hace que conectar los puntos y correlacionar la actividad en todo tu ecosistema sea simple.

Comenzar con Heartbeat es fácil. Simplemente sigue los pasos en nuestra documentación de Heartbeat.

Para este proyecto, configuré Heartbeat para comprobar cuatro servicios. Este es un fragmento del archivo 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

¡Comunicaciones bidireccionales activadas!

Eso es todo. Estamos ingiriendo datos de tiempo de actividad en Elasticsearch y Elasticsearch está conectado a ServiceNow para la comunicación bidireccional. Como se mencionó anteriormente, esto es parte de una serie de tres secciones. Si estás listo para más, pasa a la parte 2, donde cubrimos la configuración de Elasticsearch para que, si algo sale mal, se cree un incidente en ServiceNow. 

¿Estás interesado en intentarlo? La forma más sencilla de hacerlo es usar Elastic Cloud. Inicia sesión en la consola de Elastic Cloud o regístrate para una prueba gratuita de 14 días. Puedes seguir los pasos anteriores con tu instancia de ServiceNow existente o crear una instancia de desarrollador personal.

Además, si estás interesado en buscar datos de ServiceNow junto con otras fuentes como GitHub, Google Drive y más, Elastic Workplace Search tiene un conector ServiceNow prediseñado. Workplace Search proporciona una experiencia de búsqueda unificada para tus equipos, con resultados relevantes en todas tus fuentes de contenido. También se incluye en tu prueba de Elastic Cloud.

Asegúrate de revisar la aplicación de tiempo de actividad dentro de Kibana. Puedes extender la configuración de Heartbeat de mi prueba anterior para apuntar a tu ecosistema y comenzar a monitorear su desempeño mientras también comprueba el estado del certificado TLS.