跳转到主要内容
通过 Dash0 的 Webhook 通知渠道将 Check Rule 告警同步到 Flashduty On-call。每个 Dash0 Issue 标识（Check Rule 与资源的组合）对应一条 Flashduty 告警；同一标识下的触发和恢复会持续更新这条告警。

在 Flashduty On-call

您可通过以下两种方式获取集成推送地址，任选其一即可。

使用专属集成

  1. 进入 Flashduty 控制台，选择 协作空间，打开一个协作空间
  2. 选择 配置 → 集成数据 → 专属集成，点击 新增集成
  3. 选择 Dash0，点击 保存
  4. 打开生成的集成卡片，复制 推送地址

使用共享集成

  1. 进入 Flashduty 控制台，选择 集成中心 → 告警事件
  2. 选择 Dash0，填写集成名称
  3. 配置默认路由并选择协作空间；创建后可在 路由 中增加更多规则
  4. 点击 保存，复制生成的 推送地址

在 Dash0 中配置

1

在 Dash0 中创建 Webhook 通知渠道

操作路径：Dash0 › Settings › Notification Channels › Add › Webhook保存渠道。
2

在 Check Rule 中使用该渠道

操作路径：Dash0 › 新建或编辑 Check Rule › Notifications › Channels › Add notification channel需要只在严重时通知，可使用 Dash0 按严重程度路由的选项。
3

发送测试通知并用真实告警验证

操作路径：Dash0 › Settings › Notification Channels在渠道列表中对 Flashduty 渠道点击 Send test notification。测试通知只能证明推送地址可达：Flashduty 对 Dash0 未公开说明的事件类型返回成功但不创建告警。要验证完整流程，请让 Check Rule 真正命中阈值，确认 Flashduty 收到活动告警；再让指标恢复正常，确认原告警恢复。Dash0 发送的是固定格式的 JSON，无需自定义 Payload。几秒后回到 Flashduty，集成显示 最新事件时间，说明配置成功。

Alert Key

Flashduty 直接使用 data.issue.issueIdentifier 作为 Alert Key。Dash0 官方将其定义为“Check Rule 与资源的组合的标识，在不同的 Issue 实例之间保持稳定”，因此触发、更新和恢复携带同一个值。 data.issue.id 是单个 Issue 实例的 ID，data.issue.checkrules[].id 是 Check Rule 的 ID，二者都只作为标签，不参与 Alert Key。标题、状态、描述、开始时间和 Check Rule 版本的变化都不会改变 Alert Key。缺少 issueIdentifier 的告警类型请求会被拒绝，因为无法可靠关联后续恢复。

事件类型和告警等级

Dash0 未公开说明 alert.closed 和 alert.superseded 的具体语义。Flashduty 按保守方式处理：closed 视为 Issue 已结束，superseded 认为同一标识随后会有新的 alert.ongoing，因此不改变告警状态。

排查问题

  • Dash0 返回非 2xx：确认推送地址完整且包含 integration_key
  • Flashduty 返回参数错误：确认请求体是有效 JSON，且 data.issue.issueIdentifier 非空
  • 告警没有恢复：确认渠道接收恢复通知（alert.resolved / alert.closed），并检查 Check Rule 的路由是否只在严重时通知
  • 收到请求但没有告警：alert.superseded 和未知类型会被忽略
更多字段含义请参阅 Dash0 Webhook 集成 和 Send Alert Check Notifications。