NotificationCommand 用 Icinga 2 自带的 Json.encode 把运行时宏组装成 JSON,再调用 curl 推送到 Flashduty。每个 Icinga 2 主机或服务对应一条 Flashduty 告警:出现问题时触发,恢复时自动关闭。
在 Flashduty On-call
您可通过以下两种方式获取集成推送地址,任选其一即可。
使用专属集成
- 进入 Flashduty 控制台,选择 协作空间,打开一个协作空间
- 选择 配置 → 集成数据 → 专属集成,点击 新增一个集成
- 选择 Icinga,点击 保存
- 打开生成的集成卡片,复制 推送地址
使用共享集成
- 进入 Flashduty 控制台,选择 集成中心 → 告警事件
- 选择 Icinga,填写集成名称
- 配置默认路由并选择协作空间;创建后可在 路由 中增加更多规则
- 点击 保存,复制生成的 推送地址
在 Icinga 2 中配置
以下配置适用于 Icinga 2.11 及以上版本。通知命令只依赖
curl,需要安装在执行通知的 Icinga 2 节点上,并且该节点能访问 Flashduty 推送地址。
1
添加 Flashduty 配置
在 Icinga 2 主节点(master)上创建文件 说明:
/etc/icinga2/conf.d/flashduty.conf,内容如下,并把 vars.flashduty_push_url 替换为上一步复制的推送地址:- 通知命令由 Icinga 2 直接执行,不经过 shell,插件输出中的引号或换行不会破坏 JSON
macro需要先赋给局部变量resolve:在{ }字典内部直接调用macro会失败,Icinga 2 日志报Argument is not a callable object,通知不会发出- 主机通知中
service.*宏没有值,会以null发送,Flashduty 据此识别为主机通知 assign where true表示所有主机和服务都推送。只想推送部分对象时,改成自己的条件,例如assign where host.vars.flashduty == true- 如果
curl不在/usr/bin/curl,请改为which curl的输出
分布式监控中,通知在 master 区域执行,配置文件和
curl 放在 master 节点上即可。使用 Icinga Director 管理配置时,同样可以把此文件放在 master 的 conf.d 目录下,与 Director 部署的对象共存。2
检查并重新加载配置
icinga2 daemon -C 没有报错后再重新加载。3
验证生命周期
在 Icinga Web 中打开一个服务,选择 Process check result,提交
CRITICAL 结果,确认 Flashduty 收到活动告警;再提交 OK 结果,确认原告警关闭。Icinga 2 只在进入硬状态(HARD)时发送问题通知,服务会在连续 max_check_attempts 次非 OK 结果后才进入硬状态(示例模板 generic-service 为 5 次),所以请重复提交 CRITICAL,直到状态类型显示为 HARD。也可以在服务页面选择 Send custom notification 确认链路连通。自定义通知(CUSTOM)会推送到 Flashduty,Flashduty 返回成功,不会生成告警。Alert Key
Flashduty 用主机名
host_name 加服务名 service_name 计算 Alert Key;主机通知的服务名为空。Icinga 2 的服务对象以 主机名!服务名 作为完整名称,同一主机下服务名唯一,因此同一个主机或服务的问题和恢复通知落在同一条告警上。
状态、插件输出、显示名称、主机地址和分组的变化都不会改变 Alert Key。重命名主机或服务后,新名称会产生新的告警;改名前未恢复的告警需要手动关闭。
请求缺少 host_name 或 notification_type,主机通知缺少 host_state,或服务通知缺少 service_state 时,Flashduty 会拒绝该请求。
告警生命周期
Icinga 2 只在发出过问题通知之后才会发送恢复通知。确认、维护、抖动和自定义通知如果用来打开告警,之后可能没有恢复通知来关闭。因此只有问题通知会打开告警,Flashduty 按通知类型
notification_type 处理:
问题持续期间,Icinga 2 默认每 30 分钟重发一次
PROBLEM 通知(Notification 的 interval),这些通知更新同一条告警。不需要时可在两条 apply Notification 中加上 interval = 0。
配置中的 apply Notification 没有设置 types 和 states,Icinga 2 默认发送全部通知类型。维护期被移除时 Icinga 2 发送的类型是 DOWNTIMECANCELLED。被忽略的通知返回成功。
告警等级
告警等级来自当前状态:服务通知取
service_state,主机通知取 host_state。
恢复事件的等级取恢复前的状态(
service_last_state 或 host_last_state)。
告警内容
- 标题:服务通知为
<服务显示名称> on <主机显示名称>,主机通知为Host <主机显示名称>;未设置显示名称时使用对象名称 - 描述:插件输出
service_output或host_output - 标签:
host、resource(主机名)、service、check(服务名,仅服务通知)、notification_type、state、host_display_name、host_address、host_groups、service_display_name和service_groups(仅服务通知)。多个分组以英文逗号连接
排查问题
- 通知没有发出:在 Icinga Web 中查看对象的通知历史,确认
flashduty通知对象存在(先执行icinga2 daemon -C --dump-objects生成对象缓存,再执行icinga2 object list --type Notification --name '*flashduty'),并确认主机或服务没有关闭通知 - Icinga 2 日志出现
exit code 22:curl收到了 HTTP 4xx/5xx。确认vars.flashduty_push_url是完整推送地址且包含integration_key - Icinga 2 日志出现
exit code 6、7或28:执行通知的节点无法解析、连接或在 10 秒内访问推送地址,请检查 DNS、防火墙和代理 - 同一条通知推送了多次:
apply Notification中配置了多个用户,改为只保留flashduty - 服务变为 CRITICAL 但没有推送:对象仍处于软状态(SOFT),达到
max_check_attempts次后进入硬状态才会发送通知 - 告警没有恢复:确认对象已真正恢复为
OK或UP,且没有在 Notification 或flashduty用户上设置排除Recovery的types过滤