OneUptime Datadog 集成指南：用 Webhook 工作流把 Datadog 监控告警转换为事故与状态页

OneUptime Datadog 集成指南用 Webhook 工作流把 Datadog 监控告警转换为事故与状态页【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptimeDatadog 负责检测OneUptime 负责响应——本文讲解如何把 Datadog 的监控告警monitor alerts通过其官方Webhooks 集成转发到 OneUptime 的Webhook 触发器并借助拖拽式Workflow自动创建事故Incident让 Datadog 的检测结果直接驱动 OneUptime 的事故响应、告警通知与状态页发布。这是一条典型的入站Inbound集成链路读完本文你将掌握从零搭建 Webhook 工作流、配置 Datadog 自定义 payload、按transition分支创建/解决事故以及用运行日志定位没触发、字段为空、重复事故三大常见问题的完整实战方案。集成原理入站Inbound模式与完整调用链OneUptime 的集成体系不依赖独立的插件包而是全部通过内置自动化引擎Workflows拼装而成见 Integrations 总览。Datadog 集成属于其中典型的Inbound外部工具 → OneUptime模式Datadog monitor alerts ──► Webhook integration ──► OneUptime Webhook trigger ──► Create Incident从源码层面看这条链路的第一步由一个专门的触发器类实现Webhook.ts 继承自TriggerCode在工作流 API 上注册了 GET 与 POST 两条路由/trigger/:secretkey。当 Datadog 的 Webhooks 集成向该 URL 发来请求时触发器会从路径参数中取出secretkey用webhookSecretKey在数据库中反查对应的工作流查询实现见 Webhook.ts#L94-L104把请求的headers、query 参数、body原样封装进工作流上下文const executeWorkflow: ExecuteWorkflowType { workflowId: new ObjectID(workflow._id), returnValues: { request-headers: req.headers, request-params: req.query, request-body: req.body, }, };随后工作流被放入队列异步执行入队逻辑见 ComponentCode.ts 中的QueueWorkflow.addWorkflowToQueue调用方立即收到{ status: Scheduled }的确认响应。这意味着整个工作流在后台运行Datadog 无需等待处理完成。关于触发器的官方说明见 Webhook 组件文档 与 Triggers 文档。理解这一点对排障很有价值只要 Datadog 侧显示发送成功、而工作流没有执行问题几乎都出在请求没到达正确 URL或工作流未启用而不是网络丢包。前置条件一个可以配置集成Integrations与监控器Monitors的 Datadog 账号一个可以创建工作流的 OneUptime 项目。第一步构建 OneUptime 工作流进入Workflows → Create Workflow命名为Datadog → Incidents打开Builder。添加一个Webhook触发器trigger复制它的 URL并把该块重命名为Datadog。Webhook 触发器的 URL 由 OneUptime 根据该工作流唯一的webhookSecretKey生成格式为{{serverUrl}}workflow/trigger/{{webhookSecretKey}}该密钥相当于触发器的密码任何拿到此 URL 的人都能启动你的工作流因此要像对待密钥一样保管。如果怀疑它已泄露可以在 Workflow Settings 页面重置webhookSecretKey参见 Webhook 组件文档。URL 同时接受GET和POST两种方法。添加一个Conditions条件判断在 Add Component 面板中叫If / Else块连接到触发器之后Left左值{{Datadog.Request Body.transition}}Operator运算符Right右值Triggered在编辑器中使用**值选择器picker**插入引用而不是手打。选择器会生成运行器真正认得的引用 id其实际形式与源码中request-body这个返回字段一一对应例如{{local.components.块标识.returnValues.request-body.transition}}。触发器输出的完整字段为Request Headers / Request Query Params / Request Body详见 Webhook 组件文档 与 Triggers 文档块 ID 与返回字段的变量语法规则见 Variables 文档。从Yes分支接出一个Create Incident块Title标题{{Datadog.Request Body.title}}Description描述{{Datadog.Request Body.body}} Host: {{Datadog.Request Body.host}} {{Datadog.Request Body.link}}Severity严重级别按你的团队规范选择一档。数据组件Create Incident 属于 OneUptime 数据组件之一的字段名与 API 中的列名column一致而不是表单上的显示标签_id是记录的主键字段。详见 Components 文档。保存。新工作流默认是**禁用disabled**状态——禁用状态下连手动运行都会被拒绝——测试前先保持禁用即可。第二步在 Datadog 创建 Webhook在 Datadog 进入Integrations → Webhooks未安装则先安装Webhooks集成。点击Add a webhook填写Nameoneuptime保存后即成为webhook-oneuptime句柄供监控器通知消息引用URL第一步复制的工作流 Webhook URLPayloadDatadog 允许用模板变量template variables自定义 JSON 请求体直接粘贴如下模板{ title: $EVENT_TITLE, body: $TEXT_ONLY_MSG, alert_type: $ALERT_TYPE, transition: $ALERT_TRANSITION, id: $ALERT_ID, host: $HOSTNAME, link: $LINK, priority: $PRIORITY }各模板变量语义如下模板变量含义在本文工作流中的用途$EVENT_TITLE事件标题写入事故 Title$TEXT_ONLY_MSG去掉 Markdown 的纯文本消息写入事故 Description$ALERT_TYPE告警类型如error/warning可选可用于严重级别映射$ALERT_TRANSITION状态转移Triggered/Recovered分支条件与恢复时自动解决$ALERT_ID告警 ID事故去重与匹配Find Incident$HOSTNAME触发告警的主机名写入事故 Description$LINK指向该事件的链接写入事故 Description$PRIORITY优先级可选保存该 Webhook。注意Datadog 只会替换当前事件实际适用的模板变量——例如事件没有关联主机时$HOSTNAME会被替换为空串。因此下游字段为空时优先怀疑 payload 中对应变量未被替换详见下文故障排查。第三步把监控器告警转发到 Webhook在希望转发的每个 Datadog 监控器的notification message通知消息中加上 webhook 句柄{{#is_alert}}webhook-oneuptime{{/is_alert}} {{#is_recovery}}webhook-oneuptime{{/is_recovery}}这样告警alert与恢复recovery都会发送到 OneUptime为后续恢复时自动解决打好基础。如果希望该监控器的所有状态变化都无条件转发也可以直接把webhook-oneuptime写进通知消息不包在is_alert/is_recovery条件里。第四步测试回到 OneUptime启用Enable刚才保存的工作流。在 Datadog 某个监控器上使用Test Notifications → Alert或等一个真实监控器触发告警。打开该工作流的Logs标签页确认有运行记录并到Incidents列表确认事故已创建。运行记录是排查工作流的核心依据每次运行都会保存何时运行、是否成功、每个块做了什么。在Workflows → Runs Logs可查看项目内所有工作流的运行在单个工作流的Runs Logs中可按 Run ID 过滤点击运行的View Logs进入Steps视图逐块查看Received变量解析后的实际入参与Returned块输出失败步骤会标红并默认展开。运行状态与调试方法的完整说明见 Runs Logs 文档。恢复时自动解决可选Datadog 监控器恢复后$ALERT_TRANSITION的值变为Recovered。复用第一步的Conditions思路增加第二个分支添加第二个Conditions块transition Recovered左值同样取{{Datadog.Request Body.transition}}。在其Yes分支上添加Find Incident块以你发送的id{{Datadog.Request Body.id}}作为查询条件匹配到此前创建的那条事故记录。再接Update Incident块把匹配到的事故移动到已解决resolved状态。查询条件Query的键是列名、值是要匹配的内容且查询自动限定在当前工作流所属项目内无需手动附加项目条件详见 Components 文档。故障排查没有运行记录No run appears确认监控器通知消息中确实包含webhook-oneuptime确认工作流处于Enabled状态——新工作流默认禁用禁用状态下任何请求都会被拒绝包括手动运行在 Datadog 侧确认 Webhook 确实发出了请求多数工具会记录发送日志。字段为空Fields are empty这是 Datadog 模板变量的特性只替换当前事件适用的变量不适用的会替换为空。此时应打开工作流的Logs标签查看触发器输出的Received内容逐字段核对 payload 中哪些变量被替换、哪些为空再据此调整 Webhook payload 或下游引用。重复事故Duplicate incidents监控器开启 renotify重复告警时同一次故障会发送多个Triggered事件从而创建多条事故。解法是在Create Incident 之前用Find Incident块按id{{Datadog.Request Body.id}}先查一遍命中已存在→ 走Update Incident或直接结束未命中 → 走Create Incident。对应数据组件如 FindOneBaseModel.ts的成功/错误端口只反映查询是否执行成功查不到记录0 条同样走 Success 而不是失败——要分支判断是否命中需要读取返回的计数再用 If / Else 判断。变量引用没有生效补充提示如果你的引用中出现字面量{{local.components.…}}原样文本说明引用未被解析通常是块标识Identifier拼写错误、变量不存在或括号内带了空格{{ var }}与{{var}}是不同的查找。未解析的引用会被原样透传而不是置空且运行仍会显示Executed——此时看运行日志中的警告行能最快定位详见 Variables 文档 的 Gotchas 一节。延伸阅读Integrations 总览 —— 入站/出站两种集成模式以及 Slack、Teams 等原生工作区连接的区别Prometheus Alertmanager 集成 与 Grafana 集成 —— 其他同构的入站告警源Workflows 总览 —— 自动化引擎的整体工作方式Triggers —— Webhook 触发器的 URL、输出与使用场景Components —— Conditions、Find/Create/Update Incident 等数据组件的完整目录Variables —— 块间传值与全局变量的语法Runs Logs —— 运行状态机与逐块调试方法。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考