如何连接 ServiceNow 和 Elasticsearch 以实现双向通信

多年来,Elastic Stack (ELK) 一直用于提升可观测性安全性,而现在我们推出了这两种开箱即用型解决方案。然而,查明问题和找出根本原因只是进程的一个环节。通常,组织都希望将 Elastic Stack 集成到他们的日常工作流中,以便能够快速解决这些问题。这通常涉及到与某种形式的工单处理/事件跟踪框架的集成。有一些团队使用 Slack 或电子邮件,也有一些团队使用 ServiceNow 或 Jira 等工具。在本系列的三个部分中,我们将简要介绍如何设置 ServiceNow 和 Elasticsearch 以自动进行事件管理,以及如何整合 Canvas workpad 以可视化、展示和管理事件

在第一篇博文中,我们将探索如何在 Elasticsearch 和 ServiceNow 之间建立双向关系;ServiceNow 是一款颇受欢迎的工作流管理工具,因其服务台功能而经常被使用。构想则是 (1) 通过由机器学习提供支持的基于异常的警报自动创建工单;(2) 每当更新该工单时,将自动更新 Elasticsearch。原因何在?为了 360 度全方位概述整个生态系统,从事件检测到调查和管理一应俱全。在此进程中,我们将测算以下弹性指标:

  • 平均确认时间 (MTTA) - 用于追踪响应的关键指标。MTTA 高,则说明团队收到了过多的警报,因此需要的响应时间过长。
  • 平均解决时间 (MTTR) - 非常适用于查看解决工单所用的时间。这项指标根据工单从“进行中”状态到“已解决”或“已关闭”所需的平均时间来计算。
  • 平均故障间隔时间 (MTBF) - 有助于了解一个事物的弹性程度。MTBF 越低,说明故障发生得越快、越频繁。该指标以小时为单位,计算方法是用运行的总小时数除以离线的事件数。

相比在多种不同的工具之间来回切换,使用单一平台始终要更具优势。在用于识别和搜索数据的同一工具中呈现 MTTA、MTTR 和 MTBF,这意味着各团队可以了解特定应用程序、服务、项目、团队、部门或任何实体开始影响上述弹性指标的具体方式。通过针对 Kibana 的相同数据应用不同的 Lens,您可以为 SRE、SOC 分析师和高管提供精选的洞见。

示例项目

在本篇博客中,我们将使用 Elasticsearch、ServiceNow 和 Heartbeat(我们的运行时间监测器),并对它们进行设置,以便达成以下目标:

  1. Heartbeat 持续监测我们的应用程序,确保这些应用程序处于在线和响应状态。
  2. 应用程序关闭超过 5 分钟时,Watcher(Elasticsearch 的内置警报框架)会在 ServiceNow 中创建事件工单,但为了减少警报疲劳,只有在特定应用程序没有开放的或有效的 ServiceNow 工单时才会进行此项操作。
  3. Alex(我本人)将工单分配给自己,并通过添加备注的方式开始着手对其进行处理。
  4. 只要 ServiceNow 中的工单有更新,Elasticsearch 中的记录就会随之更新。 
  5. Alex 的管理团队使用 Canvas 来持续追踪待处理的工单、MTTA、MTTR、MTBF,了解哪些应用程序最为麻烦等。

最终结果将是下面的 Canvas 仪表板:

本系列的最后我们将在 Canvas 中创建的事件管理仪表板。

本项目将包括几个部分:

  1. 设置 ServiceNow
  2. 在 ServiceNow 中配置业务规则,以自动更新 Elasticsearch
  3. 设置 Heartbeat 以监测我们的应用程序
  4. 配置 Elasticsearch 索引 
  5. 创建一些转换,以持续测算我们的指标
  6. 在 ServiceNow 中利用机器学习和警报自动创建工单,但前提是其中还不存在工单
  7. 使用高级 Elasticsearch SQL 构建上述 Canvas 仪表板,如数据透视和 Canvas 表达式 

如果您没有部署 Elasticsearch 来进行相应操作,可以在 Elastic Cloud 免费试用我们的 Elasticsearch Service,或在本地免费安装。如果没有 ServiceNow 实例,可以快速部署个人开发人员实例

准备 ServiceNow

对事件表单进行个性化设置

本篇博客假设您有一个全新的 ServiceNow 实例,不过大多数时候情况并非如此。然而,即使使用现有设置,步骤也非常简单。首先,我们将更新事件应用,添加一个名为应用程序的新字段,以便追踪有问题的应用程序:

  1. 打开 ServiceNow 中的事件应用。
  2. 创建临时事件;其中的值并不重要。
  3. 前往 FormDesign 向导:

ServiceNow 表单设计向导。

  1. 为了简单起见,我们只需要添加一个字符串字段来追踪有问题应用程序的名称。在实际的生产设置中,最好在 ServiceNow 内将应用程序设置为特定实体。使用以下设置配置新的字符串字段:

配置 ServiceNow 中的字符串属性。

  1. 保存配置,然后返回到事件表单,并使用 blog-es-servicenow-1-settings.png 图标对其进行配置,以个性化已有的字段。

个性化 ServiceNow 中的字段选择。

  1. 我们有一个带有新的特定字段的事件表单,这个字段用于确定哪个是有问题的应用程序。现在,我们需要配置 ServiceNow,以便在事件以任何方式更新时,其都会自动更新 Elasticsearch。

为 Elasticsearch 创建的事件创建 ServiceNow 用户

了解事件的来源很重要,为实现这一点,ServiceNow 使用的是 Caller 字段。创建工单时,我们会设置此字段,以便表明它是自动生成的工单。若要创建新用户,请前往 ServiceNow 中的用户应用,并使用以下字段创建和保存新用户:

ServiceNow 双向通信

在 ServiceNow 中创建事件是简单的 REST API POST 请求,但配置 ServiceNow 让它自动更新 Elasticsearch 则略有不同。我们在下面利用的是 ServiceNow 业务规则。此规则将“监测”事件表,如果任一指定字段出现更改,它将运行一些逻辑,将更改索引到 Elasticsearch 中。由于 Elasticsearch 需要凭据,我们将以正确的方式操作:

  1. 在 Elasticsearch 中创建新角色和用户(最低权限原则
  2. 在 ServiceNow 中设置 REST 消息和 auth 配置文件
  3. 创建业务规则

创建 Elasticsearch 角色和用户

进程的记录非常详尽,所以在此不予赘述。我们需要一个只能在 servicenow-incident-updates 索引别名中索引文档的角色。建议为这一功能创建特定的角色,坚持最低权限原则。本人列出了下面的选项,展示使用 Kibana 或 API 的步骤:

Kibana

  1. 管理 -> 角色
  2. 创建角色
  3. 将字段设置为以下项
    • 索引:servicenow-incident-updates
    • 权限:索引

API

您可以使用 Kibana 中的控制台

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

现在我们来创建一个拥有该角色的用户。

Kibana

  1. 管理 -> 用户
  2. 创建用户
  3. 将字段设置为以下项
    • 用户名:ServiceNowUpdater
    • 密码:自行设置
    • 角色:servicenow_updater

API

POST /_security/user/ServiceNowUpdater 
{ 
  "password" :"随意更改",
  "roles" : [ "servicenow_updater" ],
  "full_name" :"ServiceNow Incident Updater",
  "email" : "admin@example.com" 
}

在 ServiceNow 中创建 Elasticsearch REST 消息和 auth 配置文件

Elasticsearch 已经针对这一功能设置了用户,我们可以进行 ServiceNow 相关操作。在 ServiceNow 中打开 REST 消息应用,并创建新记录。将名称设置为“Elasticsearch”,并将终端设置为 Elasticsearch 终端。在 Elastic Cloud 中运行时,我的终端是 <a href="https://[CloudID].westeurope.azure.elastic-cloud.com:9243">https://[CloudID].westeurope.azure.elastic-cloud.c...</a>

下一步是设置身份验证。要进行此操作,我们将身份验证类型设置为“基础级”,然后单击基础级 auth 配置文件字段上的放大镜。 

将身份验证类型设置为“基础级”。

我们将创建新的基础级 auth 配置记录。将这一记录的名称设置为“ElasticsearchIncidentUpdater”,并将用户名和密码字段设置为上面使用的相应值。我的用户名和密码分别是:

  • 用户名:ServiceNowUpdater
  • 密码:[随意更改]

在 REST 消息应用中保存这一记录,并返回到 Elasticsearch 记录。确保正在使用新的基础级 auth 配置文件。如果“HTTP 方法”部分可见,则您需要单击提交,然后重新打开上面我们称之为 Elasticsearch 的 REST 消息。 

显示内容为:

ServiceNow 中的记录。

接下来,我们将在 ServiceNow 中创建新的 HTTP 方法记录。接下来需要进行几项操作,请注意:

  1. 单击“HTTP 方法”旁边的新增按钮。
  2. 将名称设置为 UpdateIncident。
  3. 将 HTTP 方法设置为 POST。
  4. 确保将身份验证类型设置成承继于父项。
  5. 将终端设置为 Elasticsearch 终端(包括端口),然后将 /servicenow-incident-updates/_doc 附加于该终端,例如:<a href="https://[CloudID].westeurope.azure.elastic-cloud.com:9243/servicenow-incident-updates/_doc">https://[CloudID].westeurope.azure.elastic-cloud.c...</a>
  6. 创建名为“内容-类型”且值为“application/json”的 HTTP 标头。
  7. 将内容字段设置为:
    {"@timestamp": "${timestamp}", "incidentID": "${incidentID}", "assignedTo": "${assignedTo}",  "description": "${description}",  "state": "${state}",  "updatedDate": "${updatedDate}",  "workNotes": "${workNotes}",  "app_name": "${appName}"}
        
  8. 使用新增按钮并指定下面屏幕截图中提供的指定“名称”,创建以下变量替换(您可能需要在显示变量替换 UI 组件前单击提交按钮,并返回到终端)。建议使用“相关链接”下标有“Auto-generate variables”(自动生成变量)字样的链接。

创建替换变量

  1. 单击右上方的更新,返回到 REST 消息表单。
  2. 单击更新进行保存。

好吧 - 步骤很多!大部分操作都很简单,但是步骤 7 和 8 可能需要解释一下,最好是反向操作。步骤 8 将变量添加到记录中,以便在执行请求时,可以在出站 REST 消息内容中替换这些变量。步骤 7 利用这些变量,构建 POST 请求的内容字段。重要的是要注意,这一内容字段将发送到 Elasticsearch。 

创建 ServiceNow 业务规则

这部分是核心组件,在创建或更新了事件时,让我们能够将更新发送到 Elasticsearch。为此,我们需要在 ServiceNow 中打开业务规则应用,并创建新规则。要进行上述操作,需完成几个环节,我们需要配置要运行的表格、运行时机和运行逻辑。首先,需要一个名称。将名称字段设置为“Elasticsearch 更新事件”,并将表格设置为“事件”。重要的是还要选择“高级”框,因为我们将使用自定义脚本。 

设置“运行时机”框,显示内容为:

ServiceNow 中的“运行时机”框。

此项配置意味着业务规则将在插入、更新或删除事件后运行。状态、工作备注、分配对象或已更新字段更新时,应该运行该规则。

下一步是将我们已经完成的所有内容联系在一起。前往“高级”选项卡,将脚本设置成与这一片段相同:

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

此脚本使用我们创建的 Elasticsearch REST 消息。特别值得一提的是,它使用 UpdateIncident POST 请求,填充我们用事件中的相关字段创建的变量替换,然后将其发送到Elasticsearch 内的 servicenow-incident-updates。

保存一下就可以了。

使用 Heartbeat 监测我们的应用程序

运行时间监测解答的其中一个问题是“打开还是关闭?” 其通过使用 Heartbeat 生成的数据实现这一点。Heartbeat 使用 TCP、HTTP 或 ICMP 周期性地查验终端,收集部分案例,提升可观测性。了解主机、服务、网站或 API 是否活跃是了解生态系统可用性的重要因素。Heartbeat 通过收集响应时间和响应代码进一步达成这一点。这与日志、指标和 APM 数据相结合,轻松连接各点,使生态系统的各项活动相互关联。

Heartbeat 入门很容易。按照 Heartbeat 文档中的步骤进行即可。

对于这个项目,我设置了 Heartbeat,以便检查四项服务。这是 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

双向通信启动!

大功告成!我们将运行时间数据引入 Elasticsearch 中,并将 Elasticsearch 连接到 ServiceNow 以进行双向通信。如上所述,本系列共分成三部,这是其中的一个部分。如果您想了解更多,请跳转到第 2 部分,在这部分中,我们涵盖了设置 Elasticsearch,如此万一出现问题,即会在 ServiceNow 中创建事件! 

有兴趣试一试吗?最简单的方法是使用 Elastic Cloud。登录 Elastic Cloud 控制台或注册免费试用 14 天。您可以通过现有的 ServiceNow 实例按照上述步骤进行,或快速部署个人开发人员实例

此外,如果想要搜索 ServiceNow 数据以及 GitHub、Google Drive 等其他资源,Elastic Workplace Search 提供有预先构建的 ServiceNow 连接器。Workplace Search 提供所有内容来源范围内的相关结果,让您的团队享有一致标准的搜索体验。Elastic Cloud 试用也包括 Workplace Search。

务必查看 Kibana 内的运行时间应用程序。您可以扩展我在上面示范的 Heartbeat 配置,指向您自己的生态系统,并开始监测其执行方式,同时检查 TLS 证书状态。