OneUptime 与 PagerDuty 集成用 Workflow 将 OneUptime 事件推送到 PagerDuty 并自动解决【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime本篇指南讲解 OneUptime 与 PagerDuty 的事件联动集成借助 OneUptime 的 Workflow工作流机制在 OneUptime 事件Incident创建时通过 PagerDuty Events API v2 触发对应告警并在 OneUptime 侧解决事件时自动关闭 PagerDuty 中的告警。读完本文你将掌握路由密钥routing key的安全存储方式、dedup_key双向关联原理、触发/解决两个工作流的完整搭建步骤以及结合源码确认的模板引用语法、日志脱敏机制和故障排查方法。集成原理一条出站事件链该集成的目标是每当 OneUptime 创建一个事件就在 PagerDuty 中解决触发一个对应的事件当 OneUptime 将事件解决时同步关闭 PagerDuty 侧的告警。这在 PagerDuty 已承担你的升级策略Eskalation与值班排班Rufbereitschaftspläne、而你希望用 OneUptime 的监控数据为其供数时特别有用。该集成是**出站ausgehend的OneUptime 主动调用 PagerDuty 的 Events API v2由一个Vorfall事件→ On Create触发器驱动后接一个API 组件OneUptime Incident → On Create ──► API component (POST /v2/enqueue) ──► PagerDuty incident从源码结构看这条链路的每个环节都有对应的实现支撑API 组件工作流组件库内置API Post (JSON)ComponentID.ApiPost等组件定义在 Common/Types/Workflow/Components/API.ts 中支持任意 URL 的 JSON POST 请求返回error、response-status、response-headers、response-body四个值并暴露Success/Error两个输出端口。组件注册表见 Common/Types/Workflow/Components.ts。事件触发器触发器组件不是手写的而是由 Common/Types/Workflow/Components/BaseModel.ts 中的BaseModelComponentFactory根据各数据模型的enableWorkflowOn配置自动生成组件元数据装配见 App/FeatureSet/Workflow/Utils/ComponentMetadata.ts。Incident 模型开启了工作流触发能力因此在 Builder 中才能看到Vorfall触发器及其 On Create / On Update 等触发点。模板渲染与执行组件参数中的{{...}}模板在运行时由执行器解析并写入存储映射storage map再逐组件渲染执行与状态维护位于 App/FeatureSet/Workflow/Services/RunWorkflow.ts。注意OneUptime 自带值班与升级能力——见 On Call。只有当你确实需要把事件额外同步到 PagerDuty 时才应使用本集成。前置条件在动手之前确认以下两项一个 PagerDuty Service且配置了Events API v2集成在 PagerDuty 中依次进入Service → Integrations → Add integration → Events API v2复制Integration Key也称routing key。务必确认是 Events APIv2而不是旧版 v1——这是后续400 invalid routing key报错的最常见原因。一个 OneUptime 项目且你在其中拥有创建工作流的权限。第 1 步 — 安全保存 Routing Key进入Arbeitsabläufe工作流→ Globale Variablen全局变量→ Erstellen创建。将变量命名为PAGERDUTY_ROUTING_KEY粘贴 Integration Key并勾选Is Secret。为什么必须勾选Is Secret源码给出了明确答案全局/局部变量在执行时会被解析进运行时的存储映射供模板引用App/FeatureSet/Workflow/Services/RunWorkflow.ts 中local.variables与global.variables的赋值。每一步执行都会把渲染后的参数写入 WorkflowLog 日志行。若变量未标记为机密routing key 的明文会原样落进日志任何有项目读权限的人都能从日志里看到它。日志脱敏由 App/FeatureSet/Workflow/Utils/SecretRedaction.ts 完成getSecretWorkflowVariableValues只筛选isSecret为真的变量第 56–69 行redactSecretsFromString将这些值在日志文本中统一替换为[REDACTED]第 76–99 行。脱敏清单按最长优先排序避免token这类短机密先替换、把token-with-suffix的后缀留在日志里。isSecret字段本身的语义也值得注意它是布尔列描述为 “If true, then itll not be in the logs”默认falseCommon/Models/DatabaseModels/WorkflowVariable.ts。源码注释还强调了一个“棘轮”设计变量可以后被标记为机密但不能取消标记WorkflowVariableService.onBeforeUpdate拒绝解除——否则一个只能写不能读变量的调用方可以通过取消机密标记、触发一次运行、再从日志里读回明文值。模板引用语法提示文档中的请求体使用{{variable.PAGERDUTY_ROUTING_KEY}}的简写形式。需要注意从源码结构看Builder 校验所接受的规范引用形式只有三种根见 Common/Types/Workflow/TemplateSyntax.ts{{local.variables.name}}— 本工作流变量{{global.variables.name}}— 项目全局变量{{local.components.componentId.returnValues.returnValueId[...path]}}— 上游组件返回值由于PAGERDUTY_ROUTING_KEY在第 1 步中创建为全局变量规范写法是{{global.variables.PAGERDUTY_ROUTING_KEY}}。这一点在实操中格外重要模板引擎采用非贪婪匹配/{{(.*?)}}/gTemplateSyntax.ts而运行时的策略是“解析不到的引用保持原样”Skip replacement if the variable is not found in the storageMap——也就是说写错引用前缀不会让运行失败错误字面量会被原封不动地发往 PagerDuty请求才会以失败告终。配置后务必通过一次测试运行核对 Workflow 日志确认引用已正确解析。第 2 步 — 创建“触发”工作流打开Arbeitsabläufe → Workflow erstellen命名为Incidents → PagerDuty打开Builder。添加一个Vorfall事件触发器触发点选On Create并将其重命名为Incident这个名称就是后续模板引用{{Incident.*}}的命名空间。添加一个与触发器相连的API块API Post (JSON)MethodPOSTURLhttps://events.pagerduty.com/v2/enqueueHeadersContent-Type: application/jsonBody{ routing_key: {{variable.PAGERDUTY_ROUTING_KEY}}, event_action: trigger, dedup_key: oneuptime-{{Incident._id}}, payload: { summary: {{Incident.title}}, source: OneUptime, severity: critical, custom_details: { description: {{Incident.description}} } } }关于这个请求体源码与 API 组件定义可以补充几点理解dedup_key是整个集成的锚点。oneuptime-{{Incident._id}}将 PagerDuty 侧的告警与 OneUptime 事件一一绑定使用 OneUptime 事件 ID 可保证 key 唯一且可预测——第 3 步的解决调用正是靠它找回原始告警。event_action取trigger/resolvev2 API 是事件队列模型trigger打开告警resolve按dedup_key关闭告警因此两个方向的请求体共享同一个 key。请求头参数是敏感参数request-headers在组件元数据中被标记为isSensitive: trueAPI.ts——头正是 Authorization 令牌通常书写的地方未脱敏的解析值会被逐字写入 WorkflowLog。这里我们只传Content-Type无密钥暴露问题。可验证的执行结果组件返回的response-status值会出现在运行日志中。保存并启用工作流然后创建一个测试事件。Workflow 日志中出现202状态码说明 PagerDuty 已接受该事件v2 enqueue 端点对成功接收返回 202 Accepted。第 3 步 — 在 OneUptime 解决时同步关闭推荐不要试图在同一个工作流里再加第二个 Vorfall 触发器——一个工作流只有一个触发器。正确做法是创建第二个工作流命名为Resolve PagerDuty使用Vorfall → On Update触发器。添加一个Bedingungen条件块条件组件类别在 Components.ts 中注册判断事件是否已进入已解决状态将{{Incident.currentIncidentState.name}}与你项目中的“已解决”状态名称比较。从Ja是分支挂接一个 API 块指向 PagerDuty使用相同的dedup_key并把event_action设为resolve{ routing_key: {{variable.PAGERDUTY_ROUTING_KEY}}, event_action: resolve, dedup_key: oneuptime-{{Incident._id}} }PagerDuty 按dedup_key匹配找到并关闭最初由trigger打开的那个告警。两个请求体的dedup_key必须逐字符一致——这是“解决调用不生效”这一故障的唯一根源见下文故障排查。严重度映射可选PagerDuty 的severity字段接受critical、error、warning或info四个值。如果你想按 OneUptime 事件的严重度动态映射而不是固定发送critical在 API 块之前添加一组Bedingungen分支条件为{{Incident.incidentSeverity.name}}的不同取值每个分支发送各自请求体仅severity字段不同routing_key、dedup_key、payload结构保持一致。入站方向可选上述流程是“OneUptime → PagerDuty”。反向亦然若希望由 PagerDuty 事件在 OneUptime 中开事件添加一个带Webhook触发器的工作流在 PagerDuty 侧配置一个 V3 Webhook或通过 Event Orchestration指向该工作流的 URL再在工作流中使用Vorfall 创建Incident Create组件落库。完整的入站模式参见 Integrationen – Überblick 中的“inbound”一节。故障排查症状原因与处理返回400报invalid routing key集成必须是Events API v2而不是旧版 Events API v1 或其他集成类型。回到 PagerDuty 的 Service → Integrations 重新复制 Key。解决调用resolve什么都没关闭解决请求中的dedup_key必须与触发请求完全一致包括oneuptime-前缀与事件 ID 的拼接方式。Workflow 日志中什么都没有确认工作流处于启用状态且触发器触发点是On Create解决工作流则是 On Update。请求发出但 key 是字面量{{...}}文本模板引用未解析。运行时对解析不到的引用采取“原样保留”策略因此这类错误不会使运行失败——请核对引用前缀是否为全局变量对应的规范形式见上文“模板引用语法提示”。相关文件与延伸阅读PagerDuty 集成文档德文原文Integrationen – Überblick — 集成模式总览与鉴权速查表On Call — OneUptime 内置值班与升级Opsgenie — 同一套模式在 Opsgenie 上的应用Workflow 文档 — 工作流构建器全貌关键源码Common/Types/Workflow/Components/API.tsAPI 组件参数与返回值定义、Common/Types/Workflow/TemplateSyntax.ts模板语法与引用路径规范、App/FeatureSet/Workflow/Utils/SecretRedaction.ts日志机密脱敏、Common/Models/DatabaseModels/WorkflowVariable.tsisSecret字段与权限、App/FeatureSet/Workflow/Services/RunWorkflow.ts变量解析与执行存储映射【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考