Flapjack维护窗口与告警确认怎么做:从计划维护到API一键确认的完整运维流程
【免费下载链接】flapjackMonitoring notification routing + event processing system. For issues with the Flapjack packages, please see https://github.com/flapjack/omnibus-flapjack/项目地址: https://gitcode.com/gh_mirrors/fl/flapjack
Flapjack 是一款灵活的监控告警路由与事件处理系统,负责判断告警该通知谁、以什么方式通知,以及处理计划维护窗口、告警确认(ack)等标准运维任务。本文将带你从 0 到 1 走通一套完整的运维流程:👉 创建计划维护窗口 → 让维护期间的告警自动静默 → 通过 JSON API 一键确认告警 → 确认后的行为验证。全程只需 CLI 和 API 两种方式,新手也能直接上手。
一、先理解两个核心概念 🔑
| 概念 | 英文 | 含义 | 典型场景 |
|---|---|---|---|
| 计划维护窗口 | Scheduled Maintenance | 指定某检查(check)在未来某个时间段内静默 | 凌晨 2 点升级数据库,预计 30 分钟 |
| 未计划维护窗口 | Unscheduled Maintenance | 从当前时刻开始的临时静默 | 正在排查问题,先别打电话 |
| 告警确认 | Acknowledgement | 声明"这个问题我已接手",默认静默 4 小时 | 值班同事在手机上点一下确认 |
Flapjack 中这两类数据分别由以下模型定义:
- 计划维护:
lib/flapjack/data/scheduled_maintenance.rb(含开始时间、结束时间、原因说明三个属性,并强制校验"结束时间必须晚于开始时间") - 未计划维护:
lib/flapjack/data/unscheduled_maintenance.rb(开始时间默认取当前时间) - 告警确认:
lib/flapjack/data/acknowledgement.rb(默认时长 4 小时,可自定义)
二、用 CLI 创建维护窗口(最快方式)
Flapjack 内置了flapjack maintenance命令族,支持 show / create / delete 三个子命令,实现代码在lib/flapjack/cli/maintenance.rb。
1. 创建:一句话预约"今晚升级"
flapjack maintenance create \ --check "db-primary:disk" \ --type scheduled \ --start "on 2026-08-24 02:00" \ --duration "equal to 30 minutes" \ --reason "计划升级数据库"要点说明:
--check支持逗号分隔的多个检查名,也可以写正则(如http*)批量覆盖- 时间参数支持自然语言:
after 1 hour、between 3 and 4 hours ago等,底层用 Chronic 解析 - 如果该检查尚不存在,Flapjack 会自动创建检查再挂上维护窗口,不用提前准备
2. 查看:确认窗口已生效
flapjack maintenance show --type scheduled --start "after now"输出是一张包含 Check、Start、Duration、Reason、End 五列的表格,方便快速核对。
3. 删除:取消不再需要的维护
# 第一次运行只是"预演",列出将要删除的窗口 flapjack maintenance delete --type scheduled --check "db-primary:disk" # 加 --apply true 才真正删除(且只允许删除尚未结束的窗口) flapjack maintenance delete --apply true --type scheduled --check "db-primary:disk"这种"先预演、后确认"的双段式设计,能有效避免误删,非常适合作为运维操作规范 🧹
三、维护窗口期间,告警真的会消失吗?
会的。Flapjack 的事件管线中设有过滤器(filter),事件在路由成通知前会逐一经过它们:
- 计划维护过滤:
lib/flapjack/filters/scheduled_maintenance.rb - 未计划维护过滤:
lib/flapjack/filters/unscheduled_maintenance.rb - 确认状态过滤:
lib/flapjack/filters/acknowledgement.rb
只要检查处于维护窗口内(或已被确认且未超时),对应事件就不会生成新的告警通知。官方用验收测试锁定了这个行为,可参考features/ack_after_sched_maint.feature:检查处于计划维护中时,收到 critical 事件不发送任何邮件;60 分钟后维护结束,critical 事件才正常触发 problem 告警,随后确认事件会生成 acknowledgement 通知。
四、JSON API 一键创建维护 / 一键确认
Flapjack 自带 JSON:API 网关(默认端口 3081),代码位于lib/flapjack/gateways/jsonapi/,接口文档由 Swagger 自动生成(lib/flapjack/gateways/jsonapi/helpers/swagger_docs.rb)。这是最推荐的"自动化"方式:值班工具、聊天机器人、工单系统都可以直接对接。
1. 一键创建计划维护窗口
curl -X POST http://localhost:3081/api/v2/scheduled_maintenances \ -H "Content-Type: application/json" \ -d '{ "data": { "id": "f47ac10b-58cc-4372-a567-0e02b2c3d479", "type": "scheduled_maintenance", "attributes": { "start_time": "2026-08-24T02:00:00Z", "end_time": "2026-08-24T02:30:00Z", "summary": "计划升级数据库" }, "relationships": { "check": { "data": { "type": "check", "id": "db-primary:disk" } } } } }'💡 小技巧:relationships里也可以把check换成tag,Flapjack 会自动为该 tag 下的每一个检查各创建一条维护窗口,非常适合"整条业务线停机"的场景。
2. 一键确认告警(Ack)
curl -X POST http://localhost:3081/api/v2/acknowledgements \ -H "Content-Type: application/json" \ -d '{ "data": { "id": "d1b2a0c9-8e3f-4a71-9c55-2f6b1a0e4d38", "type": "acknowledgement", "attributes": { "duration": 3600, "summary": "已接手,正在排查磁盘" }, "relationships": { "check": { "data": { "type": "check", "id": "db-primary:disk" } } } } }'两个参数值得注意(详见lib/flapjack/data/acknowledgement.rb):
duration:确认时长(秒),不传则默认 4 小时(4 × 60 × 60)relationships:check与tag二选一。传 tag 时,该 tag 下所有失败中且启用的检查会一起被确认
确认成功后,Flapjack 会向相关联系人发送 acknowledgement 类型的通知,让团队知道"有人在处理了",避免重复派单。
五、最佳实践清单 ✅
- 能用 tag 就别逐个填 check:按业务线打标签,维护窗口和确认都能一次覆盖整组检查。
- 维护窗口宁短勿长:只覆盖必须静默的时段,结束后问题会立即重新告警,这正是验收测试验证过的行为。
- 确认时写明 summary:这是写给交接人的"便签",
正在重启服务比空值有用得多。 - 危险操作走双段式:
maintenance delete不带--apply先预演一遍再执行。 - 接入前先读 Swagger:接口字段以运行时生成的文档为准,
GET /api/v2即可查看。
六、常见问题速答 📮
Q:未计划维护(unscheduled)能用 API 直接 POST 创建吗?不能。lib/flapjack/data/unscheduled_maintenance.rb只开放了 GET / PATCH / DELETE,创建请走 CLI 的--type unscheduled,语义上它就是"此刻开始"的临时静默。
Q:确认一个没有失败的检查会生效吗?不会。Acknowledgement的check=逻辑会先判断检查是否处于失败且启用状态,不是就不创建确认,属于静默空操作。
Q:维护窗口和确认能叠加吗?能。过滤器按序执行,维护窗口内的事件被丢弃,窗口结束后若检查仍失败则重新告警;之后的确认操作照常生效。
写在最后
维护窗口解决"计划内的静默",告警确认解决"已接手的静默"——两者配合,就能让 Flapjack 在风暴时刻保持安静、又绝不遗漏真正的新问题。建议按本文顺序实操一遍:CLI 创建窗口 → 触发一次失败事件验证静默 → API 确认告警 → 用flapjack maintenance show收尾。祝值班愉快 🌙
【免费下载链接】flapjackMonitoring notification routing + event processing system. For issues with the Flapjack packages, please see https://github.com/flapjack/omnibus-flapjack/项目地址: https://gitcode.com/gh_mirrors/fl/flapjack
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考