在 Flashduty On-call
您可通过以下两种方式获取集成推送地址，任选其一即可。
使用专属集成
- 进入 Flashduty 控制台，选择 协作空间，打开一个协作空间
- 选择 配置 → 集成数据 → 专属集成，点击 新增一个集成
- 选择 Pingdom，点击 保存
- 打开生成的集成卡片，复制 推送地址
使用共享集成
- 进入 Flashduty 控制台，选择 集成中心 → 告警事件
- 选择 Pingdom，填写集成名称
- 配置默认路由并选择协作空间；创建后可在 路由 中增加更多规则
- 点击 保存，复制生成的 推送地址
在 Pingdom 中配置
1
创建 Webhook 集成
- 登录 My Pingdom，进入 Settings → Integrations（左侧栏齿轮图标）
- 点击右上角 Add integration，类型选择 Webhook
- 名称可填写
Flashduty - 将 Flashduty 集成的完整推送地址粘贴到 URL
- 点击 Save integration
DOWN，description 为 test。Flashduty 返回成功，不会生成告警。2
在检查中启用该集成
- Uptime 检查：进入 Synthetics → Uptime，点击检查所在行末尾的菜单，选择 Edit，在集成列表中勾选
Flashduty - Transaction 检查：编辑需要告警的 Transaction 检查，在告警设置的集成列表中同样勾选
Flashduty
UP 与 DOWN 之间变化，Transaction 检查在 SUCCESS 与 FAILING 之间变化。检查持续失败期间不会重复发送。新建检查的第一次结果（从未知变为 UP）不会发送。When down, alert after 默认为 5 分钟，因此检查开始失败约 5 分钟后才会发出 DOWN Webhook；需要更快告警时可在检查的告警设置中调小。3
验证生命周期
让检查真正失败（例如暂时指向一个不可访问的地址），确认 Flashduty 收到活动告警；再恢复检查目标，确认原告警恢复。
Alert Key
Flashduty 用检查类别（Uptime 或 Transaction）加
check_id 计算 Alert Key。同一个检查的失败和恢复 Webhook 携带相同的 check_id，因此会落在同一条告警上。Uptime 检查与 Transaction 检查分属不同的检查列表，加入类别后，即使两者数字 ID 相同也不会互相覆盖。
检查名称、importance_level、状态、时间、错误描述和探测节点的变化都不会改变 Alert Key。请求缺少 check_id 时 Flashduty 会拒绝，因为无法关联后续恢复。
状态和告警等级
空值或其他
current_state 会被拒绝，避免把无法判断状态的请求写入错误的告警生命周期。
告警等级来自检查的重要程度 importance_level：
恢复事件保留原告警等级。
告警内容
- 标题：检查名称
check_name - 描述：
long_description，为空时使用description - 标签：
check_id、check_name、check_type、importance_level、previous_state、current_state、hostname、full_url、url、tags（逗号分隔）、state_changed_timestamp、state_changed_utc_time、first_probe_location、second_probe_location、check（检查名称）、source（固定为pingdom），以及resource（优先取full_url，其次hostname、url）
check_params 中的请求头和认证设置不会写入标签。
排查问题
- Pingdom 返回非 2xx：确认 URL 是完整推送地址且包含
integration_key - Flashduty 返回参数错误：确认请求中有
check_id和current_state - 告警没有恢复：确认检查已真正恢复为
UP或SUCCESS，且该检查仍勾选了Flashduty集成 - 集成的 Test 按钮：测试消息指向一个真实检查且状态为
DOWN，description为test，long_description以 “This is a test message triggered by a user” 开头。Flashduty 返回成功且不生成告警，不会影响该检查的真实告警 - 使用 BeepManager Webhook：本集成接收的是检查状态变化 Webhook，不支持旧版 BeepManager 告警格式