Flashduty Docs
中文EnglishRoadmapAPI官网控制台
中文EnglishRoadmapAPI官网控制台
  1. Webhooks
  • 快速开始
    • 入门介绍
    • 快速开始
    • 常见问题
    • 产品对比
  • 故障管理
    • 什么是故障
    • 检索与查看故障
    • 处理与更新故障
    • 升级与分派故障
    • 自定义字段
    • 自定义操作
    • 了解降噪过程
    • 了解历史故障
    • 了解新奇故障
  • 配置Flashduty
    • 协作空间管理
    • 多种方式接入告警
    • 配置路由规则
    • 配置标签增强
    • 配置告警降噪
    • 配置分派策略
    • 故障静默与抑制
    • 配置值班规则
    • 配置通知模板
    • 配置服务日历
    • 配置个人信息
    • 配置过滤条件
    • 通知机器人
    • 告警处理 pipeline
  • 平台功能
    • 团队和成员
    • 了解权限设计
    • 配置单点登录
    • 分析数据
  • 高级功能
    • 引用变量
    • 动态分派
  • 集成引导
    • 告警集成
      • 邮件 Email 集成指引
      • 夜莺 Flashcat 集成指引
      • Prometheus 集成指引
      • 标准告警事件集成指引
      • Grafana 集成指引
      • Zabbix 集成指引
      • Uptime Kuma 集成指引
      • 阿里云 ARMS 集成指引
      • 阿里云监控 CM 事件集成指引
      • 阿里云监控 CM 指标集成指引
      • 阿里云 SLS 集成指引
      • AWS CloudWatch 集成指引
      • Azure Monitor 集成指引
      • 百度云监控 BCM 集成指引
      • 华为云监控 CES 集成指引
      • 腾讯云 CLS 集成指引
      • 腾讯云监控 CM 集成指引
      • 腾讯云 Event Bridge 集成指引
      • Influxdata 集成指引
      • Open Falcon 集成指引
      • Pagerduty 集成指引
      • 蓝鲸智云集成指引
      • OceanBase 集成指引
      • Graylog 集成指引
      • Skywalking 集成指引
      • Sentry 集成指引
      • 监控宝告警集成指引
      • AWS EventBridge 集成指引
      • Dynatrace 集成指引
      • 华为云 LTS 集成指引
      • GoogleCloud 集成指引
      • Splunk 集成指引
      • AppDynamics 集成指引
      • SolarWinds 集成指引
      • 火山引擎CM 指标集成指引
      • 火山引擎CM 事件集成指引
      • 火山引擎日志服务 TLS 集成指引
      • Opmanager 告警事件
      • Meraki 告警事件
      • 天翼云告警集成
      • 观测云告警事件
      • zilliz 告警事件
      • 华为云 APM 告警事件
      • zstack 告警事件
      • Keep 告警集成指引
      • ElastAlert2 告警集成
    • 即时消息
      • 飞书 Lark 集成指引
      • 钉钉 Dingtalk 集成指引
      • 企业微信 Wecom 集成指引
      • Slack 集成指引
      • Microsoft Teams 集成指引
    • 单点登录
      • Authing 集成指引
      • Keycloak 集成指引
      • OpenLDAP 集成指引
    • Webhooks
      • 告警 webhook
      • 故障 webhook
      • 自定义操作
    • 变更集成
      • 标准变更事件集成指引
  • 服务协议
    • 服务条款
    • 用户协议/隐私政策
    • SLA承诺
    • 数据安全
  1. Webhooks

故障 webhook

配置故障 Webhook,当故障发生特定操作(如触发、关闭)时,系统通过 HTTP 回调您配置的地址。回调内容将包含故障最新关键信息,您可以与自研工具进行集成。

一、事件类型#

目前支持以下事件类型,未来可能会增加。
事件类型释义
i_new创建故障(自动或手动创建)
i_assign分派故障(自动或手动分派)
i_snooze手动暂缓故障
i_wake取消暂缓故障
i_ack手动认领故障
i_unack取消认领故障
i_storm触发风暴提醒
i_custom触发自定义操作
i_rslv关闭故障(自动或手动关闭)
i_reopen重新打开故障
i_merge手动合并故障
i_r_title更新故障标题
i_r_desc更新故障描述
i_r_impact更新故障影响
i_r_rc更新故障根因
i_r_rsltn更新故障解决办法
i_r_severity更新故障严重程度
i_r_field更新故障自定义字段

二、推送描述#

请求方式#

POST, Content-Type:"application/json"

请求 Payload:#

字段类型必含释义
event_timeint64是事件发生毫秒时间戳
event_typestring是事件类型,枚举值见事件类型
event_idstring是事件 ID,同一个事件可能因为超时等原因重试多次,接收方需要能够去重
personPerson否操作人,仅人为动作时存在
incidentIncident是故障详情
Person:
字段类型必含释义
person_idint64是人员 ID
person_namestring是人员名称
emailstring是邮件地址
Responder:
字段类型必含释义
person_idint64是人员 ID
person_namestring是人员名称
emailstring是邮件地址
assigned_atint64否分派时间
acknowledged_atint64否认领时间
Incident:
字段类型必含释义
incident_idstring是故障 ID
titlestring是故障标题
descriptionstring否故障描述
impactstring否故障影响
root_causestring否故障根本原因
resolutionstring否故障解决办法
incident_severitystring是严重程度,枚举值:Critical,Warning,Info
incident_statusstring是故障状态,枚举值:Critical,Warning,Info,Ok
progressstring是处理进度,枚举值:Triggered,Processing,Closed
created_atint64是创建时间
updated_atint64是更新时间
start_timeint64是触发时间,Unix 秒时间戳
last_timeint64否最新事件时间,关联告警中的最新事件推送时间,Unix 秒时间戳,默认为 0
end_timeint64否恢复时间,关联的告警全部恢复时,故障也会自动恢复,Unix 秒时间戳,默认为 0
ack_timeint64否首次认领时间,故障可被多人认领,此时间为最早的认领时间。Unix 秒时间戳,默认为 0
close_timeint64否关闭时间,end_time代表故障恢复时间,close_time代表处理进度的关闭时间,故障恢复时会同时关闭,故障关闭时不影响故障恢复。Unix 秒时间戳,默认为 0
snoozed_beforeint64否暂缓截止时间
labelsmap[string]string否标签 KV,Key 和 Value 均为字符串。手动创建时无此信息,自动创建时为聚合的第一条告警的标签信息
fieldsmap[string]interface{}否自定义字段 KV,Key 为字符串,Value 可能为任意类型,取决于字段类型
creatorPerson否创建人员信息,仅手动创建故障时存在
closerPerson否关闭人员信息,仅手动关闭故障时存在
responders[]Responder否处理人员信息列表
alert_cntint64否关联告警个数
channel_idint64否协作空间ID,为0代表不属于任何空间
channel_namestring否协作空间名称
detail_urlstring是详情地址
group_methodstring否聚合方式,枚举值:n:不聚合,p:按规则聚合,i:智能聚合

请求响应#

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

请求示例#

三、常见问题#

1.
服务是否有响应超时时间?
服务需要在 1 秒内返回响应,超过 1 秒则认为响应失败
2.
推送失败后是否会持续推送?
目前 FlashDuty 最多推送一次,未来可能会引入重试机制,也可能因为中间链路超时导致重试,您需要做好幂等处理
3.
如何保证推送顺序?
理论上同一个故障的事件是按照时间顺序进行推送,但是重试等情况可能会导致乱序
服务可以根据 event_time 进行过滤,如果已经收到了更晚的事件,可以直接过滤掉更早的事件,每一次推送都会携带最新的、完整的信息,偶尔丢失事件是可以容忍的
4.
推送来源可信 IP 白名单?
{ip_whitelist}
未来可能会更新,请定期查验
修改于 2024-11-28 08:32:07
上一页
告警 webhook
下一页
自定义操作
Built with