企业官网建设流程全解析

OneUptime × Datadog 集成实战：用 Webhook 工作流把 Datadog 监控告警转成事件

【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime

本文基于 OneUptime 官方集成文档（de/integrations/datadog.md，英文版见 en/integrations/datadog.md）整理，讲解如何通过 OneUptime 的 Workflow 工作流把 Datadog 的 Monitor 告警（alert）转换为 OneUptime 的 Incident（事件），使 Datadog 的检测能力直接接入 OneUptime 的事件响应与状态页体系。读完并照做之后，你将掌握完整的四步落地流程：构建工作流、配置 Datadog Webhook 与 Payload 模板变量、在 Monitor 通知消息中挂载 Webhook、以及测试验证与告警恢复自动关闭事件的进阶方案。

集成架构：一个典型的“入站（Inbound）”集成

这条集成是**入站（inbound）**方向：由 Datadog 侧的 [Webhooks 集成] 通过 HTTP POST 主动向 OneUptime 推送，OneUptime 侧用一个以Webhook 触发器（Webhook trigger）开头的工作流接收并处理。整体数据流如下：

Datadog monitor alerts ──► Webhook integration ──► OneUptime Webhook trigger ──► Create Incident

也就是说，OneUptime 不轮询、不拉取 Datadog，而是被动接收 Datadog 事件驱动的推送；收到后由工作流里的条件判断决定“创建事件”还是“恢复事件”。

从源码结构看，工作流的 Webhook 触发器对应一个对外暴露的 HTTP 端点，其 URL 形如{{serverUrl}}workflow/trigger/{{webhookSecretKey}}，其中 secret key 是每条工作流唯一的密钥，可在 Workflow Settings 页面重置（见 Webhook 触发器组件文档）。该端点支持 GET 或 POST，请求头与请求体都会进入工作流上下文，供下游任意组件读取——这正是后文所有{{Datadog.Request Body.xxx}}变量能生效的原因。手动触发 API（见 Manual.ts）中的注释也印证了这一设计：程序化调用方应通过工作流自身的 API/Webhook 触发器（/workflow/trigger/:secretkey，凭工作流密钥鉴权）来触发，而非手动运行路由。

工作流收到请求后进入队列执行，相关执行链落在 QueueWorkflow.ts 与 RunWorkflow.ts，这也解释了为什么调试时要看工作流的Logs页签——每次触发（run）都会留痕。

前置条件

• 一个可以配置集成和 Monitor 的 Datadog 账号；
• 一个可以创建工作流（Workflow）的 OneUptime 项目。

步骤 1 — 创建 OneUptime 工作流

1. 打开Workflows → Create Workflow（工作流 → 创建工作流），命名为Datadog → Incidents，并打开Builder（构建器）。
2. 添加一个Webhook触发器并复制它的 URL。把该触发器块重命名为Datadog——这个名字很重要，后面所有模板变量都通过{{Datadog.Request Body.xxx}}的形式引用。
3. 添加一个与触发器相连的Conditions（条件）块：
   • Left（左值）：{{Datadog.Request Body.transition}}
   • Operator（操作符）：==
   • Right（右值）：Triggered
4. 从条件的Yes（是）分支添加一个Create Incident（创建事件）块：
   • Title（标题）：{{Datadog.Request Body.title}}
   • Description（描述）：{{Datadog.Request Body.body}}\nHost: {{Datadog.Request Body.host}}\n{{Datadog.Request Body.link}}
   • Severity（严重级别）：选择一个合适级别。
5. 保存，测试完成之前保持禁用状态。

这里的条件判断刻意只放行transition == Triggered的推送：Datadog 每次状态迁移（触发、恢复、重新告警）都会 POST 一次，先过滤出“触发”事件，避免恢复通知或重复通知误创建事件。

步骤 2 — 在 Datadog 侧创建 Webhook

1. 进入 Datadog 的Integrations → Webhooks（如未安装先安装Webhooks集成）。
2. 添加一个 Webhook：
   • Name（名称）：oneuptime（Datadog 会把它变成句柄@webhook-oneuptime）；
   • URL：填写步骤 1 中复制的 OneUptime 工作流 Webhook URL；
   • Payload（负载）：Datadog 允许用模板变量自定义 JSON 请求体，推荐如下：

{ "title": "$EVENT_TITLE", "body": "$TEXT_ONLY_MSG", "alert_type": "$ALERT_TYPE", "transition": "$ALERT_TRANSITION", "id": "$ALERT_ID", "host": "$HOSTNAME", "link": "$LINK", "priority": "$PRIORITY" }

各字段在 OneUptime 侧的用途：title直接作为事件标题；body、host、link拼进事件描述；transition用于条件分支；id（$ALERT_ID）是后续去重与恢复匹配的关键字段。

3. 保存该 Webhook。

步骤 3 — 让 Monitor 的告警发送到该 Webhook

在需要转发的事件notification message（通知消息）中加入 Webhook 句柄：

{{#is_alert}}@webhook-oneuptime{{/is_alert}} {{#is_recovery}}@webhook-oneuptime{{/is_recovery}}

这样告警（alert）与恢复（recovery）两类事件都会推送到 OneUptime。如果想把所有状态迁移都转发，也可以不加条件块直接写@webhook-oneuptime。

步骤 4 — 测试验证

1. 启用（Enable）该工作流；
2. 在某个 Monitor 上使用Test Notifications → Alert，或直接等待一个真实 Monitor 被触发；
3. 查看工作流的Logs页签确认收到了触发请求，再到Incidents列表确认事件已生成。

进阶：告警恢复时自动关闭事件（可选）

当 Monitor 恢复正常时，$ALERT_TRANSITION的值是Recovered。此时可以在工作流中加第二个Conditions分支（transition == Recovered），用之前推送的id（$ALERT_ID）匹配到对应事件，再通过Update Incident组件把它移动到已解决（resolved）状态。这样就能实现“Datadog 报障 → OneUptime 开事件；Datadog 恢复 → OneUptime 自动关事件”的闭环。

故障排查

• 工作流没有 run 记录（No run appears）：确认 Monitor 的通知消息里确实包含了@webhook-oneuptime，且工作流处于Enabled（启用）状态。
• 部分字段为空（Fields are empty）：Datadog 只会替换该事件真正适用的模板变量。到工作流Logs页签查看触发时的实际输出，再按需调整 Webhook Payload 的字段。
• 出现重复事件（Duplicate incidents）：会重新告警（renotify）的 Monitor 会发送多个Triggered事件。建议在创建事件前，先用Find Incident组件按id做去重判断，命中已存在的事件就不重复创建。

延伸阅读

• 集成总览（Integrations Overview）：入站集成的一般模式；
• Prometheus Alertmanager 集成 与 Grafana 集成：其他两类入站告警源；
• Webhook 触发器说明：接收 URL 的工作机制。
• 工作流组件体系可参考 工作流组件文档 与 运行与日志。

【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime