Como conectar o ServiceNow e o Elasticsearch para comunicação bidirecional

O Elastic Stack (ELK) tem sido usado para observabilidade e segurança há muitos anos, razão pela qual agora oferecemos os dois como soluções prontas para uso. No entanto, identificar problemas e encontrar a causa raiz é apenas parte do processo. É comum que as organizações queiram integrar o Elastic Stack em seus fluxos de trabalho diários para que possam resolver esses problemas rapidamente. Isso normalmente envolve a integração com alguma forma de framework de controle de tíquetes/incidentes. Algumas equipes usam o Slack ou e-mails, enquanto outras usam ferramentas como o ServiceNow ou o Jira. Nesta série de três partes, vamos mostrar como configurar o ServiceNow e o Elasticsearch para automatizar o gerenciamento de incidentes, além de montar um workpad do Canvas para visualizar, apresentar e gerenciar incidentes.

Neste primeiro post do blog, vamos explorar a configuração de um relacionamento bidirecional entre o Elasticsearch e o ServiceNow, uma ferramenta de gerenciamento de fluxo de trabalho popular, frequentemente usada por seus recursos de central de atendimento. A ideia é (1) criar um tíquete automaticamente por meio de alertas baseados em anomalias gerados com machine learning e (2) atualizar automaticamente o Elasticsearch sempre que esse tíquete for atualizado. Por quê? Para a obtenção de uma visão geral de 360 graus de todo o seu ecossistema — da detecção de incidentes à investigação e gerenciamento. Como parte desse processo, calcularemos estas métricas de resiliência:

• Tempo médio de reconhecimento (MTTA) — uma métrica importante, usada para monitorar a capacidade de resposta. Se o MTTA é alto, muitas vezes pode indicar que a equipe está sofrendo com uma quantidade excessiva de alertas e, portanto, demorando muito para responder.
• Tempo médio de resolução (MTTR) — excelente para ver quanto tempo os tíquetes levam para serem resolvidos. Isso é calculado com base no tempo médio que leva para um tíquete ir do estado “Em andamento” a “Resolvido” ou “Fechado”.
• Tempo médio entre falhas (MTBF) — útil para entender o nível de resiliência. O MTBF mais baixo significa que o ecossistema falha rápida e frequentemente. Essa métrica é mensurada em horas e é calculada dividindo o total de horas de execução pelo número de incidentes em que o sistema fica offline.

É sempre melhor ter uma visualização unificada do que ficar pulando entre uma infinidade de ferramentas. Com a exposição do MTTA, do MTTR e do MTBF na mesma ferramenta usada para identificar e buscar os dados, as equipes podem ver como aplicações, serviços, projetos, equipes, departamentos ou qualquer entidade especificamente começam a afetar as métricas de resiliência acima. Ao analisar os mesmos dados sob diferentes lentes no Kibana, você pode fornecer insights organizados especificamente para seus SREs, analistas de SOC e executivos.

Exemplo de projeto

Neste post, vamos usar o Elasticsearch, o ServiceNow e o Heartbeat (nosso monitor de tempo de funcionamento) e configurá-los para o seguinte:

1. O Heartbeat monitora continuamente nossas aplicações para garantir que estejam online e responsivas.
2. O Watcher (um framework de alerta integrado ao Elasticsearch) cria um tíquete de incidente no ServiceNow quando uma aplicação fica inativa por mais de cinco minutos; porém, para reduzir a fadiga do alerta, ele só faz isso quando não há um tíquete do ServiceNow aberto ou ativo para essa aplicação específica.
3. Alex (eu!) atribui o tíquete a si mesmo e começa a trabalhar nele adicionando notas.
4. Sempre que o tíquete é atualizado no ServiceNow, o registro é atualizado no Elasticsearch. 
5. O(A) gerente de Alex usa o Canvas para controlar tíquetes abertos, MTTA, MTTR, MTBF, quais aplicações são as mais problemáticas e muito mais.

O resultado final será o seguinte dashboard do Canvas:

Haverá algumas seções neste projeto:

1. Configurar o ServiceNow
2. Configurar uma regra de negócios no ServiceNow para atualizar automaticamente o Elasticsearch
3. Configurar o Heartbeat para monitorar nossas aplicações
4. Configurar os índices do Elasticsearch 
5. Criar algumas transformações para calcular continuamente nossas métricas
6. Usar machine learning e alerta para criar automaticamente o tíquete no ServiceNow, mas apenas se não existir um tíquete
7. Montar o dashboard do Canvas acima usando Elasticsearch SQL avançado, como dinamização e expressões do Canvas 

Se você não tem uma implantação do Elasticsearch para acompanhar, pode criar uma avaliação gratuita do nosso Elasticsearch Service no Elastic Cloud ou instalá-lo localmente de forma gratuita. E se você não tem uma instância do ServiceNow, pode ativar uma instância de desenvolvedor pessoal.

Preparação do ServiceNow

Personalização do formulário Incident (Incidente)

Este post presume que você tenha uma instância nova do ServiceNow, embora, na maioria das vezes, esse não seja o caso. No entanto, as etapas são muito simples, mesmo com uma configuração existente. Para começar, vamos atualizar o app Incident para adicionar um novo campo chamado Application (Aplicação) a fim de monitorar a aplicação que está com problema:

1. Abra o app Incident no ServiceNow.
2. Crie um incidente temporário; os valores realmente não importam.
3. Vá para o assistente Form Design:

4. Para simplificar, vamos apenas adicionar um campo String para monitorar o nome da aplicação em questão. Em uma configuração de produção real, provavelmente é melhor configurar a aplicação como uma entidade específica no ServiceNow. Defina o seu novo campo String com as seguintes configurações:

5. Salve, volte para o formulário de incidente e configure-o usando o ícone para personalizar quais campos estão presentes.

6. Neste ponto, temos um formulário Incident (Incidente) com nosso novo campo específico, que determina qual aplicação está com problema. Agora, precisamos configurar o ServiceNow para que ele atualize automaticamente o Elasticsearch quando nossos incidentes forem atualizados de alguma forma.

Criar um usuário do ServiceNow para incidentes criados pelo Elasticsearch

É importante saber a origem de um incidente e, para fazer isso, o ServiceNow usa o campo Caller (Chamador). Devemos definir esse campo quando criamos nosso tíquete para que saibamos que se trata de um tíquete gerado automaticamente. Para criar um novo usuário, vá para o app Users no ServiceNow e crie e salve um novo usuário com os seguintes campos:

• Id: elastic_watcher
• First name (Nome): Elasticsearch Watcher
• Email: admin@elasticutilities.co

Comunicação bidirecional do ServiceNow

A criação de um incidente no ServiceNow é uma solicitação POST simples da REST API, mas configurar o ServiceNow para que ele atualize automaticamente o Elasticsearch é um pouco diferente. Vamos aproveitar uma regra de negócios do ServiceNow. Essa regra vai “monitorar” a tabela Incidents (Incidentes) e, se algum dos poucos campos especificados mudar, ela executará uma lógica que indexará as alterações no Elasticsearch. Como as credenciais são necessárias para o Elasticsearch, faremos as coisas de maneira adequada:

1. Criação de uma nova função e usuário no Elasticsearch (princípio do menor privilégio)
2. Configuração da mensagem REST e do perfil de autenticação no ServiceNow
3. Criação da regra de negócios

Criação da função e do usuário do Elasticsearch

Esse é um processo muito bem documentado, então não passarei muito tempo aqui. Precisamos ter uma função que possa apenas indexar documentos dentro do alias de índice servicenow-incident-updates. É aconselhável ter uma função específica para esse recurso, a fim de aderir ao princípio do menor privilégio. Descrevi as opções abaixo, mostrando as etapas para usar o Kibana ou a API:

Kibana

1. Management (Gerenciamento) -> Role (Função)
2. Criar função
3. Defina os campos da seguinte forma:
   • Indices (Índices): servicenow-incident-updates
   • Privileges (Privilégios): index

API

Você pode usar o Console no Kibana para isto:

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

Agora, criamos um usuário que tenha essa função.

Kibana

4. Management (Gerenciamento) -> Users (Usuários)
5. Criar usuário
6. Defina os campos da seguinte forma:
   • Username (Nome de usuário): ServiceNowUpdater
   • Password (Senha): Você escolhe
   • Role (Função): servicenow_updater

API

POST /_security/user/ServiceNowUpdater 
{ 
  "password" : “MUDE PARA ALGO APROPRIADO”, 
  "roles" : [ "servicenow_updater" ], 
  "full_name" : "ServiceNow Incident Updater", 
  "email" : "admin@example.com" 
}

Criar uma mensagem REST do Elasticsearch e um perfil de autenticação no ServiceNow

Agora que o Elasticsearch tem um usuário configurado para a funcionalidade, podemos trabalhar no ServiceNow. No ServiceNow, abra o app REST Messages e crie um novo registro. Defina o nome como “Elasticsearch” e o endpoint como o seu endpoint do Elasticsearch. Como eu estou executando-o no Elastic Cloud, meu endpoint é https://[CloudID].westeurope.azure.elastic-cloud.c....

Nossa próxima etapa é configurar a autenticação. Para fazer isso, definimos o tipo de autenticação como Basic (Básico) e clicamos na lupa no campo Basic auth profile (Perfil de autenticação básico). 

Vamos criar um novo registro de configuração de autenticação básica. Defina o nome desse registro como “ElasticsearchIncidentUpdater” e defina os campos de nome de usuário e senha com os respectivos valores usados acima. Para mim, seriam:

• Username (Nome de usuário): ServiceNowUpdater
• Password (Senha): [MUDE PARA ALGO APROPRIADO]

Salve esse registro e volte para o registro do Elasticsearch no app REST Message. Verifique se o nosso novo perfil de autenticação básico está sendo usado. Se a seção “HTTP Methods” (Métodos HTTP) estiver visível, você precisará clicar em Submit (Enviar) e reabrir a Mensagem REST que chamamos de Elasticsearch acima. 

Ela deverá ficar assim:

A seguir, vamos criar um novo registro de método HTTP no ServiceNow. Há várias coisas a serem feitas aqui, então preste muita atenção:

1. Clique no botão New (Novo) ao lado de onde está escrito “HTTP Methods” (Métodos HTTP).
2. Defina Name (Nome) como UpdateIncident.
3. Defina HTTP method (Método HTTP) como POST.
4. Verifique se o tipo de autenticação está definido para herdar do pai.
5. Defina o endpoint como o seu endpoint do Elasticsearch (incluindo a porta) e anexe /servicenow-incident-updates/_doc a ele; por exemplo: https://[CloudID].westeurope.azure.elastic-cloud.c...
6. Crie um cabeçalho HTTP com nome “Content-Type” e valor “application/json”.
7. Defina o campo Content (Conteúdo) como:

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

8. Crie as seguintes substituições de variáveis usando o botão New (Novo) e especificando os “Nomes” encontrados na captura de tela abaixo (você pode precisar clicar no botão Submit (Enviar) e voltar ao endpoint antes de o componente da UI de substituição de variável ser exibido). Em “Related Links” (Links relacionados) há um link que diz “Auto-generate variables” (Gerar variáveis automaticamente); recomendo que você use isso.

9. Clique em Update (Atualizar) no canto superior direito, o que levará você de volta ao formulário da mensagem REST.
10. Clique em Update (Atualizar) para salvar.

OK — muita coisa aconteceu! A maior parte deve ser fácil de seguir, mas as etapas 7 e 8 podem precisar de uma explicação, que será melhor se feita na ordem inversa. A etapa 8 adiciona variáveis ao registro para que, ao realizar a solicitação, essas variáveis possam ser substituídas no conteúdo da mensagem REST de saída. A etapa 7 aproveita essas variáveis e criamos o campo de conteúdo da solicitação POST. É importante notar que esse campo de conteúdo será enviado ao Elasticsearch. 

Criar a regra de negócios do ServiceNow

Esta seção é o componente principal que nos permite enviar atualizações ao Elasticsearch sempre que um incidente é criado ou atualizado. Para fazer isso, precisamos abrir o app Business Rules no ServiceNow e criar uma nova regra. Existem algumas partes para fazer isso: precisamos configurar a tabela na qual executar, quando executar e, em seguida, a lógica de execução. Primeiro, ela precisa de um nome. Defina o campo de nome como “Elasticsearch Update Incident” (Incidente de atualização do Elasticsearch) e defina a tabela como “incident” (incidente). É importante selecionar também a caixa “Advanced” (Avançado), pois usaremos um script customizado. 

Defina a caixa “When to run” (Quando executar) para que fique assim:

Essa configuração significa que a regra de negócios será executada após o incidente ser inserido, atualizado ou excluído. A regra deverá ser executada quando os campos State (Estado), Work notes (Notas de trabalho), Assigned to (Atribuído a) ou Updated (Atualizado) forem atualizados.

Nosso próximo passo é a cola que une tudo o que fizemos. Precisamos ir para a guia Advanced (Avançado) e definir o script para ser o mesmo que este snippet:

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

Esse script usa a mensagem REST do Elasticsearch que criamos. Em particular, ele usa a solicitação POST UpdateIncident, preenche as substituições de variáveis que criamos com os campos relevantes do incidente e, em seguida, envia para o servicenow-incidente-updates dentro do Elasticsearch.

Salve e pronto.

Uso do Heartbeat para monitorar nossas aplicações

Uma das perguntas que o monitoramento de tempo de funcionamento responde é “Está ativo ou inativo?” Ele faz isso usando os dados gerados pelo Heartbeat. O Heartbeat periodicamente executa ping em um endpoint por meio de TCP, HTTP ou ICMP, reunindo parte da história para observabilidade. Saber se o seu host, serviço, website ou API está ativo é importante para entender a disponibilidade do seu ecossistema. O Heartbeat vai mais longe, reunindo tempos de resposta e códigos de resposta. Isso, combinado com logs, métricas e dados de APM, torna simples conectar os pontos e correlacionar a atividade em todo o seu ecossistema.

É fácil começar a usar o Heartbeat. Basta seguir as etapas da nossa documentação do Heartbeat.

Para este projeto, eu configurei o Heartbeat para verificar quatro serviços. Este é um snippet do arquivo 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

Comunicações bidirecionais estabelecidas!

E é isso! Estamos ingerindo dados de tempo de funcionamento no Elasticsearch, e o Elasticsearch está conectado ao ServiceNow para comunicação bidirecional. Conforme mencionado acima, isso faz parte de uma série de três seções. Se você estiver pronto(a) para mais, vá para a parte 2, onde abordamos como configurar o Elasticsearch para que, se algo der errado, um incidente seja criado no ServiceNow! 

Tem interesse em experimentar? A maneira mais fácil de fazer isso é usar o Elastic Cloud. Faça login no console Elastic Cloud ou inscreva-se para fazer uma avaliação gratuita de 14 dias. Você pode seguir as etapas acima com a sua instância existente do ServiceNow ou ativar uma instância de desenvolvedor pessoal.

Além disso, se você quer fazer buscas em dados do ServiceNow junto com outras fontes, como GitHub, Google Drive e outras, o Elastic Workplace Search tem um conector pré-criado para ServiceNow. O Workplace Search oferece uma experiência de busca unificada para as suas equipes, com resultados relevantes em todas as suas fontes de conteúdo. Ele também está incluído na sua avaliação do Elastic Cloud.

Não deixe de conferir a aplicação Uptime no Kibana. Você pode estender minha configuração do Heartbeat acima para apontar para o seu ecossistema e começar a monitorar o desempenho dele enquanto verifica o status do certificado TLS.