OneUptime 与 ServiceNow 双向集成实战用 Workflow 自动创建与关闭 ITSM 工单【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime本篇技术指南讲解如何在 OneUptime 中通过内置的 Workflow 自动化引擎把每次新创建的事件Incident自动同步为 ServiceNow 的 incident 工单并在 OneUptime 事件解决时反向关闭 ServiceNow 工单让 ITSM 流程与监控告警保持步调一致。读完本文你将掌握 ServiceNow Table API 的出站调用、凭据安全存储、correlation_id关联策略以及一套可复现的故障排查方法。OneUptime 与 ServiceNow 的集成属于出站outbound集成OneUptime 主动调用 ServiceNow 的 Table API在外部系统创建记录。整个链路不依赖任何专有的集成插件而是由 OneUptime 内置的工作流引擎以可视化画布方式搭建官方文档将其概括为一条清晰的流水线OneUptime Incident → On Create ──► API component (POST /api/now/table/incident) ──► ServiceNow incident集成原理Workflow 三步走OneUptime 的工作流由三个基本部分组成一个**触发器Trigger决定何时运行一个或多个组件Component执行具体动作以及连接它们的连线Connections**决定执行顺序。所有集成都在可视化画布上完成大多数场景无需编写代码。ServiceNow 集成正是这一模型的典型应用组成部分本集成中的角色触发器Incident → On Create事件创建时触发组件API组件发起 HTTP 调用这里为POST到 Table API连接从触发器的成功输出连接到 API 组件的输入工作流相关的完整知识可参考 Workflows Overview、Triggers 与 Components。前置条件开始搭建前需要准备好以下三样东西一个可访问的 ServiceNow 实例例如https://your-instance.service-now.com。一个具备足够权限的 ServiceNow 用户官方推荐拥有rest_api_explorer/itil角色或至少具备创建incident记录权限。起步阶段使用该用户的 Basic 认证最简单生产环境则建议使用 OAuth。一个可创建工作流的 OneUptime 项目Workflow 功能随项目计划提供。第一步把凭据作为 Secret 存储ServiceNow 的 Table API 接受Basic 认证即把username:password拼接后做一次 base64 编码放入Authorization请求头。整个集成只编码一次之后通过全局变量反复引用。1. 生成 base64 凭据串在 macOS / Linux 终端执行printf %s integration_user:password | base64关键细节务必使用printf而非echo。echo会在字符串末尾追加一个换行符换行符会被一并编码进凭据串导致 ServiceNow 返回401而且从你粘贴的字符串上完全看不出来问题。这是本集成最常见的翻车点。2. 在 OneUptime 中保存为 Secret 全局变量进入Workflows → Global Variables → Create变量命名为SERVICENOW_AUTH将上一步生成的 base64 字符串粘贴为Content打开Is Secret开关。将变量标记为 Secret 后它的值会在保存后隐藏并且会从运行日志run logs和步骤跟踪中自动脱敏。工作流中任何位置都可以通过{{global.variables.SERVICENOW_AUTH}}引用它而令牌本身永远不会出现在工作流或日志里。全局变量的完整规则命名、作用域、更新方式见 Variables 文档。第二步构建「事件创建 → 建单」工作流1. 创建工作流并打开 Builder进入Workflows → Create Workflow命名为Incidents → ServiceNow然后打开Builder画布。2. 添加 Incident 触发器添加一个Incident触发器事件设为On Create并将其重命名为Incident。事件触发器会把完整的记录对象传给后续组件因此后续的 API 组件可以直接读取新事件的title、description、_id等字段。3. 添加 API 组件并配置从触发器的输出端口拖出一条线连接到新添加的API组件然后按如下配置MethodPOSTURLhttps://your-instance.service-now.com/api/now/table/incidentHeadersAuthorization: Basic {{variable.SERVICENOW_AUTH}} Content-Type: application/json Accept: application/jsonBody{ short_description: OneUptime: {{Incident.title}}, description: {{Incident.description}}, urgency: 1, impact: 1, correlation_id: oneuptime-{{Incident._id}} }请求体字段说明字段含义与取值short_description工单标题直接拼接 OneUptime 事件的标题description工单正文填入事件的详细描述urgency紧急程度ServiceNow 取值1高、2中、3低impact影响范围取值同上correlation_id关联标识这里写入oneuptime-{{Incident._id}}用于把 ServiceNow 工单与 OneUptime 事件唯一对应correlation_id是双向同步的关键设计它把 OneUptime 事件的_id带到 ServiceNow之后无论是追加解决步骤还是反向查找都能据此精确定位工单。4. 保存、启用并验证点击Save在Overview页面把工作流切换为**启用Enabled**状态——注意禁用状态下的工作流完全无法运行手动触发也不行。随后创建一个测试事件打开Runs Logs查看执行记录如果 ServiceNow 返回201 Created响应体中会带有新工单的sys_id和number例如INC0012345说明建单成功。从源码看API POST 组件会把请求通过 OneUptime 的API.post发出2xx 响应走Success端口并把状态码、响应头、响应体一并作为组件输出传给后续块非 2xx4xx/5xx则走Error端口并携带错误信息。这也意味着如果你想在成功后继续处理响应体比如提取sys_id只需把下一个组件接到该 API 块的Success输出上即可。API 组件还支持GET、PUT、PATCH、DELETE可参考 Components 文档。第三步可选事件解决时自动关闭 ServiceNow 工单当 OneUptime 事件被标记为已解决时把对应的 ServiceNow 工单也同步关闭。由于一个工作流只能有一个触发器这一步需要再建一个独立工作流1. 创建第二个工作流Workflows → Create Workflow添加Incident → On Update触发器事件更新时触发覆盖「已确认」「已解决」等状态变更再添加一个Conditions组件画布上的If / Else块判断事件是否已解决。2. 定位目标工单sys_id的两种获取方式要更新正确的 ServiceNow 工单必须拿到它的sys_id二选一方式 A推荐建单时就把sys_id存下来。在第二步的 API 组件后追加一个组件读取{{CreateRecord.response-body.result.sys_id}}用Update Incident组件把它写入 OneUptime 事件的某个标签Label中。方式 B查询定位。通过 ServiceNow Table API 的查询参数按correlation_id反查GET https://your-instance.service-now.com/api/now/table/incident?sysparm_querycorrelation_idoneuptime-{{Incident._id}}3. 发送关闭请求添加API组件配置如下MethodPATCHURLhttps://your-instance.service-now.com/api/now/table/incident/sys_idBody{ state: 6, close_code: Resolved by monitoring, close_notes: Resolved in OneUptime }state取值6在 ServiceNow 默认的 ITIL 工作流中代表Resolved已解决。close_code和close_notes则是关闭工单时填写的原因与备注Resolved by monitoring表明该工单由监控系统自动闭环。故障排查速查表集成完成后如果出现问题按下面清单逐项排查症状原因与对策401base64 编码有问题。用printf而非echo重新编码username:password并更新SERVICENOW_AUTH变量403用户没有incident表的写入权限为该用户添加itil角色400请求体里的字段名或字段值与你实例的自定义配置不符。到System Definition → Tables → incident核对真实字段名实例直接拒绝调用部分实例限制了 Table API 的访问。确认 REST 已启用且你的出口 IP 没有被 ACL 拦截进阶技巧与最佳实践用全局变量管理凭据除SERVICENOW_AUTH外建议把所有第三方 URL、令牌都收进全局变量避免在工作流里复制粘贴。非 Secret 变量与 Secret 变量的管理方式一致但只有 Secret 会从日志中脱敏。引用组件输出API 组件执行后后续块可通过{{local.components.组件ID.returnValues.response-body}}读取响应体例如{{local.components.create-record.returnValues.response-body.result.sys_id}}。建议在编辑器中使用**组件值选择器component-value picker**插入引用它会写入运行器期望的精确 ID避免手误。correlation_id是幂等同步的锚点无论采用查询反查还是存储sys_id都以它作为 OneUptime 事件与 ServiceNow 工单的关联键防止重复建单或误关他人的工单。同模式推广出站集成模式是通用的——Jira 集成、PagerDuty、Opsgenie 都遵循「事件触发器 API 组件 Secret 变量」的同一配方只是 URL 与请求体不同。关于入站/出站两类模式的整体说明见 Integrations Overview。自托管部署注意网络可达性出站集成要求 OneUptime 服务能够访问 ServiceNow 实例的对外地址自托管环境下请确认网络与 ACL 放行相关说明见 Integrations Overview 的 Network access 小节。继续阅读Integrations Overview — 入站/出站两种模式与各工具认证方式速查表Jira 集成 — 同样的出站模式在 Jira 上的完整双向实现含反向往回同步API 组件 — 如何读取 API 组件的响应体Variables 文档 — Secret 变量的行为与变量引用的注意事项Triggers 文档 — OneUptime 事件触发器的三种事件On Create / On Update / On Delete。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考