NOTIFY_* 变量)以 JSON 推送到 Flashduty。每个 Checkmk 主机或服务对应一条 Flashduty 告警:出现问题时触发,恢复时自动关闭。
在 Flashduty On-call
您可通过以下两种方式获取集成推送地址,任选其一即可。
使用专属集成
- 进入 Flashduty 控制台,选择 协作空间,打开一个协作空间
- 选择 配置 → 集成数据 → 专属集成,点击 新增一个集成
- 选择 Checkmk,点击 保存
- 打开生成的集成卡片,复制 推送地址
使用共享集成
- 进入 Flashduty 控制台,选择 集成中心 → 告警事件
- 选择 Checkmk,填写集成名称
- 配置默认路由并选择协作空间;创建后可在 路由 中增加更多规则
- 点击 保存,复制生成的 推送地址
在 Checkmk 中配置
以下步骤基于 Checkmk 2.5,其他 2.x 版本菜单名称可能略有不同。脚本只依赖 Checkmk 自带的 Python 3,不需要安装其他软件。
1
安装通知脚本
以站点用户登录 Checkmk 服务器(例如 然后赋予执行权限:脚本第二行的注释
omd su mysite),创建文件 ~/local/share/check_mk/notifications/flashduty,内容如下:# Flashduty 是它在 Checkmk 界面中显示的名称。推送地址作为脚本的第一个参数传入,不会写进请求体。网络错误或 Flashduty 返回 5xx、429 时脚本以退出码 1 结束,Checkmk 会稍后重试;其他错误以退出码 2 结束,不再重试。分布式监控中,通知由哪个站点发出,脚本就要放在哪个站点上。如果启用了通知转发,放在中心站点即可。
2
创建通知规则
进入 Setup → Events → Notifications,点击 Add notification rule,按向导填写:
- Triggering events:勾选 Host events 与 Service events 中的全部 State change,并勾选 Start or end of downtime 与 Start or end of flapping state(原因见下方「告警生命周期」)
- Filter for hosts/services:按需限定主机或服务,不限定则所有对象都会推送
- Notification method (plug-in):Method 选择 Flashduty;在 Select parameters 旁新建一组参数,第一个参数填写 Flashduty 集成的完整推送地址
- Recipient:选择 Specific users,只选一个用户(该用户不能关闭通知)
- 其余步骤保持默认,保存规则。若页面提示有待激活的更改,点击 Activate changes
3
验证生命周期
让一个服务真正进入 WARN 或 CRIT(例如调低阈值),确认 Flashduty 收到活动告警;再恢复该服务,确认原告警关闭。也可以在 Setup → Events → Notifications 的 Test notifications 中发送测试通知,确认链路连通。测试通知带有 Checkmk 的测试标记,Flashduty 返回成功,不会生成告警。
Alert Key
Flashduty 用主机名
HOSTNAME 加服务名 SERVICEDESC 计算 Alert Key;主机通知的服务名为空。同一个主机或服务的问题和恢复通知携带相同的主机名和服务名,因此落在同一条告警上。状态升到更高等级时(例如服务从 WARN 变为 CRIT),Flashduty 会新建一条更高等级的告警,原告警保持触发;恢复通知会同时关闭这两条告警。
状态、插件输出、通知序号、时间、主机地址、站点和标签的变化都不会改变 Alert Key。重命名主机或服务后,新名称会产生新的告警;改名前未恢复的告警需要手动关闭。
请求缺少 HOSTNAME、WHAT、当前状态或 NOTIFICATIONTYPE,或服务通知缺少 SERVICEDESC 时,Flashduty 会拒绝该请求。
告警生命周期
Checkmk 只在发出过问题通知之后才会发送恢复通知。确认、维护、抖动和自定义通知在问题通知被抑制时(例如服务正在抖动)也会发出,如果用它们打开告警,之后不会有恢复通知来关闭。因此只有问题通知会打开告警,Flashduty 按通知类型
NOTIFICATIONTYPE 处理:
服务抖动期间 Checkmk 不发送状态变化通知:抖动期间恢复为
OK 时不会发出恢复通知,抖动结束后也不会补发。所以规则要勾选 Start or end of flapping state 和 Start or end of downtime,让抖动或维护期结束时的通知关闭已恢复的告警。
被忽略的通知返回成功,Checkmk 不会重试。
告警等级
告警等级来自当前状态:服务通知取
SERVICESTATE,主机通知取 HOSTSTATE。
恢复事件的等级取恢复前的硬状态(
PREVIOUSSERVICEHARDSTATE 或 PREVIOUSHOSTHARDSTATE)。
告警内容
- 标题:服务通知为
<服务名> on <主机名>,主机通知为Host <主机名> - 描述:插件输出
SERVICEOUTPUT或HOSTOUTPUT,有长输出时附在后面 - 标签:
host、resource(主机名)、service、check(服务名,仅服务通知)、what(HOST或SERVICE)、notification_type、state、site、host_alias、host_address、host_groups、service_groups(仅服务通知),以及 Checkmk 的主机标签和服务标签:HOSTLABEL_env写为host_label_env,SERVICELABEL_app写为service_label_app,键名中的/、.等字符替换为_
排查问题
- Checkmk 界面找不到 Flashduty 方法:确认脚本位于站点目录的
local/share/check_mk/notifications/下,文件名为flashduty,有执行权限,第二行是# Flashduty - 通知没有发出:查看站点的
var/log/notify.log,确认规则匹配到了该事件,且 Recipient 中的用户没有关闭通知 - 脚本报 HTTP 4xx:确认参数 1 是完整推送地址且包含
integration_key - 同一条通知推送了多次:Recipient 选中了多个联系人,改为只选一个用户
- 告警没有恢复:确认对象已真正恢复为
OK或UP;若问题发生在抖动或维护期内,确认规则勾选了 Start or end of flapping state 和 Start or end of downtime