在 Flashduty On-call
您可通过以下两种方式获取集成推送地址,任选其一即可。
使用专属集成
- 进入 Flashduty 控制台,选择 协作空间,打开一个协作空间
- 选择 配置 → 集成数据 → 专属集成,点击 新增一个集成
- 选择 Zenoss,点击 保存
- 打开生成的集成卡片,复制 推送地址
使用共享集成
- 进入 Flashduty 控制台,选择 集成中心 → 告警事件
- 选择 Zenoss,填写集成名称
- 配置默认路由并选择协作空间;创建后可在 路由 中增加更多规则
- 点击 保存,复制生成的 推送地址
在 Zenoss 中配置
Zenoss 通过 目的地(Destination)、触发器(Trigger) 和 规则(Rule) 三部分发送通知。创建规则需要 Manager 角色。
1
添加 Webhook 目的地
- 进入 ADMIN > Actions,打开 DESTINATIONS 标签,点击 ADD DESTINATION
- 目的地类型选择 Webhook,填写 Destination name
- 将 Flashduty 集成的完整推送地址粘贴到 URL,地址中需包含
integration_key - Headers 留空,Custom Payload 保持关闭:Flashduty 解析 Zenoss 的默认消息,自定义 JSON 会导致无法识别事件
- 点击 SAVE
2
添加事件触发器
- 打开 TRIGGERS 标签,点击 ADD TRIGGER,Type 保持 Events
- 在 Trigger criteria 中设置需要值班处理的事件,例如严重程度为 critical 或 error。建议增加
Entity: Production State equal to Production,避免非生产设备产生告警 - Match multiple events 保持关闭,开启后 Zenoss 会把多个事件合并成一条通知,Flashduty 无法按单个事件处理
3
添加规则并开启更新通知
- 打开 RULES 标签,点击 ADD RULE,填写 Rule name
- 在 Triggers 选择上一步的触发器,在 Destinations 选择第一步的目的地
- 开启 Send updates:事件关闭或严重程度变化时 Zenoss 会再发一条通知,Flashduty 靠它恢复和更新告警。不开启则告警不会自动恢复
- 点击 SAVE
4
保存并验证
- 让 Zenoss 产生一条命中触发器的事件,确认 Flashduty 收到活动告警
- 关闭该事件(或等它自动关闭),确认原告警恢复
Alert Key
Flashduty 用事件的 ID(消息中
context.Context.Event.id)生成 Alert Key。Zenoss 用事件名称加维度(dimensions)确定一个事件,并把事件 ID 作为查询该事件的键,因此同一个事件的重复通知、更新和关闭应当带同一个 ID,对应同一个 Alert Key。Zenoss 文档没有明确写出关闭通知沿用同一个 ID:上线前请关闭一个测试事件,确认对应告警变为已恢复,而不是新开一条告警。严重程度、摘要、状态和时间变化不会改变 Alert Key。
消息最外层的 id 是通知 ID,每次发送都不同,不参与计算。缺少事件 ID 的消息会被拒绝。
状态和告警等级
消息里没有事件内容的通知(例如非事件类触发器)不会创建告警,Flashduty 收到后直接返回成功。
标签
事件摘要(
summary)作为告警描述。
排查问题
- Flashduty 返回参数错误:确认 URL 完整且包含
integration_key,并且目的地没有开启 Custom Payload - 告警没有恢复:确认规则已开启 Send updates,并且触发器没有把 Closed 事件排除在外
- Flashduty 里没有收到事件:确认规则已启用且触发器命中;Suppressed 状态的事件不会创建告警
- 同一个事件重复通知:Zenoss 规则的 Repeat notification 会按间隔重发,这些通知合并到同一条告警