尧图网页设计 
OneUptime × Opsgenie 集成实战用 Workflow 把事件自动创建为 Opsgenie 告警并闭环解决【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime本篇技术指南讲解如何在 OneUptime 中通过内置的 Workflow 自动化引擎与 Atlassian Opsgenie 打通当 OneUptime 事件Incident创建时自动调用 Opsgenie Alert API 创建告警并在 OneUptime 解决该事件时按alias自动关闭对应 Opsgenie 告警。读完本文你将掌握 Opsgenie API Key 的安全存放、Incident → On Create / On Update事件触发器的使用、API 组件构造POST /v2/alerts请求、通过alias幂等关联两条系统的事件以及 401/404 等常见故障的排查方法。集成原理一次出站Outbound集成该集成属于出站方向Outbound数据流动方向是从 OneUptime 指向 Opsgenie——OneUptime 调用 Opsgenie Alert API 自动化引擎**承载核心要素有两个一个Incident → On Create触发器触发条件新事件创建一个API 组件执行对 Opsgenie 的 HTTP 调用。无需安装任何第三方插件或中间网关集成过程本质上就是在拖拽画布上把触发器与 API 组件连线。数据流如下OneUptime Incident → On Create ──► API component (POST /v2/alerts) ──► Opsgenie alert从 OneUptime 源码看API 组件的实现位于 Common/Server/Types/Workflow/Components/API 目录其中 Post.ts 负责执行 POST 请求它通过API.post()发出请求并把响应整理成response-status、response-body、response-headers与error四个返回值然后根据结果走Success2xx或Error非 2xx/网络失败两个输出端口。这意味着你完全可以在 Opsgenie 返回202 Accepted时把它接进下一个组件做后续处理。前提条件开始配置前需要准备以下三样东西Opsgenie API Key在 Opsgenie 中通过Settings → Integrations → Add → API创建一个 API 集成然后复制生成的 Key。注意必须是API类型的集成——只有它具备调用 Alert API 的权限。确认 Opsgenie 的区域Region默认 API 主机是https://api.opsgenie.com如果你的账号属于欧盟EU区域请改用https://api.eu.opsgenie.com。区域选错是后面出现 401/403 的常见原因之一。一个可创建 Workflow 的 OneUptime 项目。提示OneUptime 本身自带 On Call 与升级escalation能力参见 On Call。本集成适合希望在 Opsgenie 中也同步出现告警的场景例如 Opsgenie 承担了贵团队的排班与通知职责而 OneUptime 负责监控数据源。Step 1 — 用全局变量安全存放 API Key直接在 API 组件里粘贴 API Key 是不推荐的它会被写进工作流的配置甚至可能出现在运行日志里。OneUptime Workflow 提供全局变量Global Variables机制来解决这个问题进入Workflows → Global Variables → Create。变量名填OPSGENIE_KEY。粘贴 Opsgenie API Key 到值中。打开Is Secret是否为机密开关。保存后该变量在界面中会被隐藏并且运行时会被从日志与步骤追踪step trace中擦除。从源码看这一脱敏逻辑是实打实的在 RunWorkflow.ts 中敏感字段isSensitive标记的参数与返回值在写入WorkflowLog前会被替换为脱敏占位符SecretRedaction.ts 则进一步递归地在日志、追踪与错误信息中擦除机密变量的具体取值连 JSON 属性名中出现密钥片段的情况也会被处理见 RunWorkflow.ts。在 API 组件的 Headers 或 Body 中用如下模板引用这个变量注意全局变量的引用前缀是{{variable.NAME}}完整规则见 Variables{{variable.OPSGENIE_KEY}}Step 2 — 构建创建告警工作流按以下步骤搭建第一条工作流打开Workflows → Create Workflow命名如Incidents → Opsgenie然后进入Builder构建器。添加一个Incident事件触发器事件类型选On Create创建时触发。把该触发块重命名为Incident。在触发块后面连接一个API组件按如下配置方法MethodPOSTURLhttps://api.opsgenie.com/v2/alerts欧盟区域请使用https://api.eu.opsgenie.com/v2/alerts请求头HeadersAuthorization: GenieKey {{variable.OPSGENIE_KEY}} Content-Type: application/json请求体Body{ message: {{Incident.title}}, alias: oneuptime-{{Incident._id}}, description: {{Incident.description}}, priority: P1, source: OneUptime }关键字段解析alias告警别名这是整个集成最重要的字段。Opsgenie 允许用alias唯一标识一条告警OneUptime 用oneuptime-{{Incident._id}}把 Opsgenie 告警与 OneUptime 事件一对一绑定。事件 ID 全局唯一且不可变所以这个 alias 天然具有唯一性与可预测性——这正是后续按 alias 关闭告警的前提。实际上PagerDuty 集成也采用同样的思路dedup_key见 pagerduty.md。Authorization头Opsgenie 的认证格式是字面量GenieKey加一个空格再加你的 Key即GenieKey API_KEY。这与常见的Bearer方案不同不要写错。OneUptime 官方集成认证速查表里也明确列出了这一格式见 integrations/index.md。priority直接写死为P1即可先跑通如果希望按 OneUptime 严重级别动态映射见下文优先级映射一节。模板变量{{Incident.title}}、{{Incident.description}}、{{Incident._id}}来自 Incident 触发器的输出。从源码看OneUptime 事件触发器会把完整的事件记录传递给下一个组件参见 triggers.md因此事件的所有字段——标题、描述、严重级别、当前状态等——都可以直接引用。在构建器中建议使用**组件值选择器component-value picker**插入引用它会自动填入精确的组件 ID避免手拼路径出错。验证点击Save保存然后在工作流Overview页面把工作流启用Enable——新工作流默认是禁用状态禁用的工作流会拒绝一切运行。手动创建一个测试事件。打开Workflows → Runs Logs查看本次运行如果 API 组件返回202 Accepted说明 Opsgenie 已接受并排队创建了告警。关于运行日志的使用方法可参考 runs-and-logs.md在 Runs Logs 中展开某一步Received显示的是变量解析后的组件入参Returned显示其返回值失败步骤会标红并默认展开显示错误信息。源码层面的实现细节补充API POST 组件在发出请求前会先经过ApiComponentUtils.sanitizeArgs校验参数并对 URL 做 SSRF 防护校验同时所有 API 组件都强制不跟随重定向doNotFollowRedirects: true防止通过302跳转到内网地址详见 Utils.ts。请求发出后POST组件会把 4xx/5xx 响应路由到Error 端口而不是 Success 端口见 Post.ts。这意味着你可以把 Error 端口接到一个通知组件上在 Opsgenie 调用失败时立刻得到告警而不是等到手动查看日志才发现。工作流实际由 Worker 进程执行而不是在 API 进程内运行每个组件执行后都会记录步骤追踪工作流还有整体执行超时控制见 RunWorkflow.ts 中的 deadline 检查。Step 3 — 在 OneUptime 解决事件时自动关闭 Opsgenie 告警推荐创建告警只是第一步。如果 OneUptime 的事件解决了而 Opsgenie 里的告警还挂着值班人员会收到永不停歇的噪声。为此需要第二条工作流创建第二条工作流命名为Close Opsgenie触发器选择Incident → On Update更新时触发。注意OneUptime 的每个工作流只能有一个触发器参见 triggers.md。所以创建告警与关闭告警必须拆成两条独立的工作流而不能在一条工作流里放两个触发器。添加一个Conditions条件组件检查事件现在是否已解决在条件中基于{{Incident.currentIncidentState.name}}进行分支判断例如等于你的已解决状态名称如Resolved。从源码看currentIncidentState正是事件模型上的多对一关联字段指向当前所处的事件状态见 Incident.ts因此在模板中引用{{Incident.currentIncidentState.name}}可以拿到状态名称。从条件的Yes分支接一个API组件方法POSTURLhttps://api.opsgenie.com/v2/alerts/oneuptime-{{Incident._id}}/close?identifierTypealias欧盟区域把主机换成api.eu.opsgenie.com请求头与创建告警一致Authorization: GenieKey {{variable.OPSGENIE_KEY}}请求体{ source: OneUptime, note: Resolved in OneUptime }这个 URL 的含义是告诉 Opsgenie 用identifierTypealias方式定位告警alias值即oneuptime-{{Incident._id}}——与创建时构造的 alias 完全一致。Opsgenie 会按 alias 找到对应告警并执行关闭。注意关闭调用里的 alias 必须与创建调用逐字符一致且identifierTypealias必须作为查询参数出现在 URL 中二者缺一都会导致404。优先级映射可选Opsgenie 的优先级范围为P1到P5P1最严重。OneUptime 事件有自己的严重级别incidentSeverity见 Incident.ts 中的关联字段。如果希望两者对应在 API 组件之前添加Conditions组件基于{{Incident.incidentSeverity.name}}做多个分支例如严重级别 Critical→ 请求体中使用priority: P1严重级别 High→priority: P2其余 →priority: P3每个分支各接一个 API 组件或使用变量把优先级拼进请求体从而让 Opsgenie 的告警优先级真实反映 OneUptime 的事件严重程度。常见故障排查症状原因与解决办法401/403Key 不正确、区域主机选错用了api.opsgenie.com但账号在 EU反之亦然、或所用集成类型没有 alert-create 权限。确认使用的是API类型集成的 Key且主机与你账号的区域匹配。关闭时返回404关闭调用中的alias与创建调用不一致哪怕差一个字符或 URL 查询串里漏了identifierTypealias。逐字符比对两条工作流里的oneuptime-{{Incident._id}}。完全没有反应工作流没有启用。新工作流默认是Disabled请在工作流 Overview 页面把它Enabled同时确认触发器事件类型正确创建用 On Create、关闭用 On Update。关于工作流没运行的更多排查思路事件是否真的发生、触发器类型、运行状态表等可参阅 runs-and-logs.md。另外注意如果一个 API 块通过其Error输出端口交接例如 4xx该步骤会画红但整条运行仍会以Executed结束——所以排查时不要只看运行整体状态要展开步骤查看。延伸阅读本集成建立在 OneUptime Workflow 引擎之上推荐继续阅读以下资料Integrations Overview —— 入站/出站两种集成模式与各类认证方式速查表Opsgenie 的GenieKey格式也在此汇总。PagerDuty 集成 —— 完全同构的思路用dedup_key关联触发与解决。Workflows 总览 —— 自动化引擎的整体工作原理。Triggers —— 四种触发器Manual / Schedule / Webhook / OneUptime 事件的详细说明。Components —— API 组件及其他内置组件的完整目录。Variables —— 全局变量与机密变量的使用规则。On Call —— OneUptime 自带的排班与升级能力若不想依赖 Opsgenie 的排班可考虑直接使用内置能力。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OneUptime × Opsgenie 集成实战：用 Workflow 把事件自动创建为 Opsgenie 告警并闭环解决
OneUptime × Opsgenie 集成实战用 Workflow 把事件自动创建为 Opsgenie 告警并闭环解决【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime本篇技术指南讲解如何在 OneUptime 中通过内置的 Workflow 自动化引擎与 Atlassian Opsgenie 打通当 OneUptime 事件Incident创建时自动调用 Opsgenie Alert API 创建告警并在 OneUptime 解决该事件时按alias自动关闭对应 Opsgenie 告警。读完本文你将掌握 Opsgenie API Key 的安全存放、Incident → On Create / On Update事件触发器的使用、API 组件构造POST /v2/alerts请求、通过alias幂等关联两条系统的事件以及 401/404 等常见故障的排查方法。集成原理一次出站Outbound集成该集成属于出站方向Outbound数据流动方向是从 OneUptime 指向 Opsgenie——OneUptime 调用 Opsgenie Alert API 自动化引擎**承载核心要素有两个一个Incident → On Create触发器触发条件新事件创建一个API 组件执行对 Opsgenie 的 HTTP 调用。无需安装任何第三方插件或中间网关集成过程本质上就是在拖拽画布上把触发器与 API 组件连线。数据流如下OneUptime Incident → On Create ──► API component (POST /v2/alerts) ──► Opsgenie alert从 OneUptime 源码看API 组件的实现位于 Common/Server/Types/Workflow/Components/API 目录其中 Post.ts 负责执行 POST 请求它通过API.post()发出请求并把响应整理成response-status、response-body、response-headers与error四个返回值然后根据结果走Success2xx或Error非 2xx/网络失败两个输出端口。这意味着你完全可以在 Opsgenie 返回202 Accepted时把它接进下一个组件做后续处理。前提条件开始配置前需要准备以下三样东西Opsgenie API Key在 Opsgenie 中通过Settings → Integrations → Add → API创建一个 API 集成然后复制生成的 Key。注意必须是API类型的集成——只有它具备调用 Alert API 的权限。确认 Opsgenie 的区域Region默认 API 主机是https://api.opsgenie.com如果你的账号属于欧盟EU区域请改用https://api.eu.opsgenie.com。区域选错是后面出现 401/403 的常见原因之一。一个可创建 Workflow 的 OneUptime 项目。提示OneUptime 本身自带 On Call 与升级escalation能力参见 On Call。本集成适合希望在 Opsgenie 中也同步出现告警的场景例如 Opsgenie 承担了贵团队的排班与通知职责而 OneUptime 负责监控数据源。Step 1 — 用全局变量安全存放 API Key直接在 API 组件里粘贴 API Key 是不推荐的它会被写进工作流的配置甚至可能出现在运行日志里。OneUptime Workflow 提供全局变量Global Variables机制来解决这个问题进入Workflows → Global Variables → Create。变量名填OPSGENIE_KEY。粘贴 Opsgenie API Key 到值中。打开Is Secret是否为机密开关。保存后该变量在界面中会被隐藏并且运行时会被从日志与步骤追踪step trace中擦除。从源码看这一脱敏逻辑是实打实的在 RunWorkflow.ts 中敏感字段isSensitive标记的参数与返回值在写入WorkflowLog前会被替换为脱敏占位符SecretRedaction.ts 则进一步递归地在日志、追踪与错误信息中擦除机密变量的具体取值连 JSON 属性名中出现密钥片段的情况也会被处理见 RunWorkflow.ts。在 API 组件的 Headers 或 Body 中用如下模板引用这个变量注意全局变量的引用前缀是{{variable.NAME}}完整规则见 Variables{{variable.OPSGENIE_KEY}}Step 2 — 构建创建告警工作流按以下步骤搭建第一条工作流打开Workflows → Create Workflow命名如Incidents → Opsgenie然后进入Builder构建器。添加一个Incident事件触发器事件类型选On Create创建时触发。把该触发块重命名为Incident。在触发块后面连接一个API组件按如下配置方法MethodPOSTURLhttps://api.opsgenie.com/v2/alerts欧盟区域请使用https://api.eu.opsgenie.com/v2/alerts请求头HeadersAuthorization: GenieKey {{variable.OPSGENIE_KEY}} Content-Type: application/json请求体Body{ message: {{Incident.title}}, alias: oneuptime-{{Incident._id}}, description: {{Incident.description}}, priority: P1, source: OneUptime }关键字段解析alias告警别名这是整个集成最重要的字段。Opsgenie 允许用alias唯一标识一条告警OneUptime 用oneuptime-{{Incident._id}}把 Opsgenie 告警与 OneUptime 事件一对一绑定。事件 ID 全局唯一且不可变所以这个 alias 天然具有唯一性与可预测性——这正是后续按 alias 关闭告警的前提。实际上PagerDuty 集成也采用同样的思路dedup_key见 pagerduty.md。Authorization头Opsgenie 的认证格式是字面量GenieKey加一个空格再加你的 Key即GenieKey API_KEY。这与常见的Bearer方案不同不要写错。OneUptime 官方集成认证速查表里也明确列出了这一格式见 integrations/index.md。priority直接写死为P1即可先跑通如果希望按 OneUptime 严重级别动态映射见下文优先级映射一节。模板变量{{Incident.title}}、{{Incident.description}}、{{Incident._id}}来自 Incident 触发器的输出。从源码看OneUptime 事件触发器会把完整的事件记录传递给下一个组件参见 triggers.md因此事件的所有字段——标题、描述、严重级别、当前状态等——都可以直接引用。在构建器中建议使用**组件值选择器component-value picker**插入引用它会自动填入精确的组件 ID避免手拼路径出错。验证点击Save保存然后在工作流Overview页面把工作流启用Enable——新工作流默认是禁用状态禁用的工作流会拒绝一切运行。手动创建一个测试事件。打开Workflows → Runs Logs查看本次运行如果 API 组件返回202 Accepted说明 Opsgenie 已接受并排队创建了告警。关于运行日志的使用方法可参考 runs-and-logs.md在 Runs Logs 中展开某一步Received显示的是变量解析后的组件入参Returned显示其返回值失败步骤会标红并默认展开显示错误信息。源码层面的实现细节补充API POST 组件在发出请求前会先经过ApiComponentUtils.sanitizeArgs校验参数并对 URL 做 SSRF 防护校验同时所有 API 组件都强制不跟随重定向doNotFollowRedirects: true防止通过302跳转到内网地址详见 Utils.ts。请求发出后POST组件会把 4xx/5xx 响应路由到Error 端口而不是 Success 端口见 Post.ts。这意味着你可以把 Error 端口接到一个通知组件上在 Opsgenie 调用失败时立刻得到告警而不是等到手动查看日志才发现。工作流实际由 Worker 进程执行而不是在 API 进程内运行每个组件执行后都会记录步骤追踪工作流还有整体执行超时控制见 RunWorkflow.ts 中的 deadline 检查。Step 3 — 在 OneUptime 解决事件时自动关闭 Opsgenie 告警推荐创建告警只是第一步。如果 OneUptime 的事件解决了而 Opsgenie 里的告警还挂着值班人员会收到永不停歇的噪声。为此需要第二条工作流创建第二条工作流命名为Close Opsgenie触发器选择Incident → On Update更新时触发。注意OneUptime 的每个工作流只能有一个触发器参见 triggers.md。所以创建告警与关闭告警必须拆成两条独立的工作流而不能在一条工作流里放两个触发器。添加一个Conditions条件组件检查事件现在是否已解决在条件中基于{{Incident.currentIncidentState.name}}进行分支判断例如等于你的已解决状态名称如Resolved。从源码看currentIncidentState正是事件模型上的多对一关联字段指向当前所处的事件状态见 Incident.ts因此在模板中引用{{Incident.currentIncidentState.name}}可以拿到状态名称。从条件的Yes分支接一个API组件方法POSTURLhttps://api.opsgenie.com/v2/alerts/oneuptime-{{Incident._id}}/close?identifierTypealias欧盟区域把主机换成api.eu.opsgenie.com请求头与创建告警一致Authorization: GenieKey {{variable.OPSGENIE_KEY}}请求体{ source: OneUptime, note: Resolved in OneUptime }这个 URL 的含义是告诉 Opsgenie 用identifierTypealias方式定位告警alias值即oneuptime-{{Incident._id}}——与创建时构造的 alias 完全一致。Opsgenie 会按 alias 找到对应告警并执行关闭。注意关闭调用里的 alias 必须与创建调用逐字符一致且identifierTypealias必须作为查询参数出现在 URL 中二者缺一都会导致404。优先级映射可选Opsgenie 的优先级范围为P1到P5P1最严重。OneUptime 事件有自己的严重级别incidentSeverity见 Incident.ts 中的关联字段。如果希望两者对应在 API 组件之前添加Conditions组件基于{{Incident.incidentSeverity.name}}做多个分支例如严重级别 Critical→ 请求体中使用priority: P1严重级别 High→priority: P2其余 →priority: P3每个分支各接一个 API 组件或使用变量把优先级拼进请求体从而让 Opsgenie 的告警优先级真实反映 OneUptime 的事件严重程度。常见故障排查症状原因与解决办法401/403Key 不正确、区域主机选错用了api.opsgenie.com但账号在 EU反之亦然、或所用集成类型没有 alert-create 权限。确认使用的是API类型集成的 Key且主机与你账号的区域匹配。关闭时返回404关闭调用中的alias与创建调用不一致哪怕差一个字符或 URL 查询串里漏了identifierTypealias。逐字符比对两条工作流里的oneuptime-{{Incident._id}}。完全没有反应工作流没有启用。新工作流默认是Disabled请在工作流 Overview 页面把它Enabled同时确认触发器事件类型正确创建用 On Create、关闭用 On Update。关于工作流没运行的更多排查思路事件是否真的发生、触发器类型、运行状态表等可参阅 runs-and-logs.md。另外注意如果一个 API 块通过其Error输出端口交接例如 4xx该步骤会画红但整条运行仍会以Executed结束——所以排查时不要只看运行整体状态要展开步骤查看。延伸阅读本集成建立在 OneUptime Workflow 引擎之上推荐继续阅读以下资料Integrations Overview —— 入站/出站两种集成模式与各类认证方式速查表Opsgenie 的GenieKey格式也在此汇总。PagerDuty 集成 —— 完全同构的思路用dedup_key关联触发与解决。Workflows 总览 —— 自动化引擎的整体工作原理。Triggers —— 四种触发器Manual / Schedule / Webhook / OneUptime 事件的详细说明。Components —— API 组件及其他内置组件的完整目录。Variables —— 全局变量与机密变量的使用规则。On Call —— OneUptime 自带的排班与升级能力若不想依赖 Opsgenie 的排班可考虑直接使用内置能力。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考