Skip to main content
版本要求:此功能需要 On-call 标准版及以上订阅。了解更多
配置告警 Webhook,当告警发生特定操作(如触发、关闭)时,系统通过 HTTP 回调您配置的地址。回调内容将包含告警最新关键信息,您可以与自研工具进行集成。

一、事件类型

目前支持以下事件类型,未来可能会增加。

二、推送描述

请求方式

POST, Content-Type:“application/json”

请求 Payload:

Person:Alert:Incident:

请求响应

HTTP status code 为 200,认为推送成功。

请求示例

三、配置指南

进入 集成中心Webhook → 添加或编辑 告警 Webhook 集成。

基础设置

填写集成名称和描述,便于后续管理。

Webhook 设置

关闭 TLS 证书验证可能存在中间人攻击风险,建议仅在测试环境或使用自签名证书时关闭。

四、调用历史

告警 Webhook 提供完整的调用历史记录,方便你排查推送是否成功以及调试回调接口。

查看调用历史

进入告警 Webhook 集成详情页,切换到 调用历史 页签即可查看。

筛选与搜索

历史记录字段

查看调用详情

点击某条记录的 查看详情,可查看完整的请求和响应信息:
  • Request:包括 Endpoint、Request Headers 和 Request Payload
  • Response:成功时显示 Response Headers 和 Response Body;失败时显示 Error Message

五、常见问题

  1. 服务是否有响应超时时间?
    • 服务需要在 2 秒内返回响应,超过 2 秒则认为响应失败
  2. 推送失败后是否会持续推送?
针对特定的网络错误,会进行重试,最多重试1次:
  • context deadline exceeded (排除 awaiting headers)
  • i/o timeout
  • eof
  1. 如何保证推送顺序?
    • 理论上同一个告警的事件是按照时间顺序进行推送,但是重试等情况可能会导致乱序
    • 服务可以根据 event_time 进行过滤,如果已经收到了更晚的事件,可以直接过滤掉更早的事件,每一次推送都会携带最新的、完整的信息,偶尔丢失事件是可以容忍的
  2. 推送来源可信 IP 白名单?
    • 未来可能会更新,请定期查验