keep + Prometheus 告警治理完整指南：3 步从告警风暴到自动响应闭环

keep + Prometheus 告警治理完整指南：3 步从告警风暴到自动响应闭环

【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep

keep 是一个开源 AIOps 告警管理平台，负责把 Prometheus、Datadog 等监控源产生的告警统一收口，通过指纹去重、工作流自动化和多云通知，把"告警"变成"可执行的事件"。如果你正在被 Prometheus 告警风暴困扰，这篇指南会带你 3 步跑通从采集、降噪到自动响应的完整闭环。

一次发布夜，217 条告警的复盘

去年双 11 前夜，某支付平台的 SRE 老周做了一次常规的灰度发布。23 点 40 分，第一个节点滚动更新完成，Alertmanager 立刻向值班群推了 3 条 CPU 告警；23 点 50 分，全量 42 个节点更新完，群里 10 分钟内涌入 217 条告警——本质上是同一个问题：发布期间瞬时负载打高了阈值。

老周后来复盘时画了一张时间线，结论很扎心：

• 前 15 分钟，团队在"确认告警"，没人敢先动手处理，怕误判
• 真正的故障根因（一个配置推送错误）直到第 40 分钟才被定位
• 发布回滚后，217 条告警没有一条被标记为 resolved，第二天告警面板还是满屏红

问题不在 Prometheus 采集不到，也不在阈值设得不对，而在告警产生之后，没有任何系统在"管理"它们。确认、归并、建单、回写状态，全靠人肉在 IM 群里喊。

先把定位说清楚：keep 不是什么

选型之前先划边界，避免踩坑：

一句话：keep 不替代 Prometheus，它接在 Prometheus 下游，做告警的"最后一公里"管理。Prometheus provider 源码 里可以看到，keep 把 Prometheus Alertmanager 推来的告警按fingerprint字段做指纹识别，同一规则、同一实例的告警天然聚成一条。

把告警量压下去的 3 个开关

keep 的降噪能力集中在告警入库后的三个环节，全部是默认开启或几行配置就能启用的：

1. 指纹去重：每个 provider 都预置了FINGERPRINT_FIELDS（如 Prometheus 用 fingerprint，Datadog 用监控项 ID），指纹相同的告警自动归并，重复推送只刷新状态、不重复通知。规则细节可参考去重文档。
2. 字段级聚合：在去重规则里指定指纹字段（比如service + rule），不同严重级别但同源的告警也能合成一条，面板上直接看到"N 个实例命中"。
3. 陈旧告警自动清除：keep 支持声明式工作流定时扫描 firing 状态超过 N 小时、却不再更新的告警并自动置为 resolved——复盘里"第二天满屏红"的问题，靠这一条就能根治。示例工作流仓库里就有现成的：resolve_old_alerts.yml。

降噪后的告警面板是这样的，每条告警可追溯、可筛选、可操作：

去重效果直观对比，同一波风暴从几十条变成一条：

5 分钟跑通最小闭环

不需要 K8s，不需要改 Prometheus 配置，一条命令起环境：

git clone https://gitcode.com/GitHub_Trending/kee/keep && cd keep && docker-compose -f docker-compose.yml -f docker-compose-with-otel.yaml up -d

启动后前端跑在 3000 端口，后端 API 在 8080。接下来做两件事：

• 在 Providers 里接入你的 Prometheus（粘贴 Base URL + API Key 即可）
• 上传一段工作流 YAML，让告警进来时自动通知 + 建单

下面这段是最小可用工作流：告警触发 → 查一下 Prometheus 拿到当前指标 → 推 Slack 并自动在 Jira 开单：

workflow: id: payment-cpu-guard name: 支付链路 CPU 告警自动响应 triggers: - type: alert cel: source.contains("prometheus") && labels.job == "payment-gateway" steps: - name: fetch-current-cpu provider: type: prometheus config: "{{ providers.prometheus }}" with: query: "avg(rate(container_cpu_usage_seconds_total{job=\"payment-gateway\"}[5m]))" actions: - name: notify-slack provider: type: slack config: "{{ providers.slack }}" with: message: "payment-gateway CPU 当前值 {{ steps.fetch-current-cpu.results }}，已自动建单" - name: open-jira provider: type: jira config: "{{ providers.jira }}" with: project: "PAY" summary: "payment-gateway CPU 超限（自动创建）"

triggers 支持 CEL 表达式做条件过滤（source.contains(...)这类写法），steps 拿数据、actions 执行动作，这是 keep 工作流的固定三段式，仓库里 examples/workflows/ 目录有 100+ 个可直接抄的样例，从 Slack 通知到 Kubernetes 扩缩容都有。

用新案例对比效果：从"人肉救火"到"自动闭环"

换个场景看收益。某物流 SaaS 接入 keep 后，跑了一个季度的数据（口径：告警入库数 / 通知数 / 人工操作次数）：

真正省时间的是最后两项：确认快，是因为聚合后一条消息代表一整波；存量清零，靠的是定时扫描工作流。团队把省下来的时间投到了根因分析上，而不是投到了"回 IM"上。

告警还可以和拓扑、AI 关联一起看，多条告警的因果链一目了然：

踩坑记录：3 个真实翻车现场

• 指纹字段没对齐：早期把 Datadog 和 Prometheus 的告警混用默认指纹，同一次故障在两个源各算一条，聚合失效。解法：给对应 provider 显式配置去重字段，按service + 业务规则名对齐。
• 阈值工作流写成了轮询风暴：有人在 workflow 里用 interval 5 秒查一次 Prometheus，直接把查询接口打满。keep 的工作流是给"告警/事件"用的，不是指标采集器，定期取数请用 Prometheus 自己的 recording rule。
• 通知渠道没分级：所有告警都推同一个群，等于没降噪。建议在 CEL 条件里按 severity 分流：critical 推值班群 + 电话，warning 只进面板，info 级别连工作流都不挂。

适合谁，不适合谁

适合：

• 已有一套或多套监控（Prometheus、Grafana、云厂商监控），但告警出口分散、没人管的团队
• 想把"告警 → 通知 → 工单 → 自愈"固化成流程、而不是每次现场写脚本的团队
• 告警量级在每天几百条以上、值班开始麻木的场景

不适合：

• 还没部署任何监控系统——先解决采集，keep 不负责指标抓取
• 只需要"阈值告警推企业微信"这种单点需求——Alertmanager 原生 receiver 就够了，上平台是过度设计

行动清单：今天就做的 4 件事

1. 按开头的命令起一个本地 keep 实例，接上你的 Prometheus
2. 打开告警面板，看一次"风暴"进来后被聚合成什么样，建立体感
3. 从 examples/workflows/ 挑一个最贴近你业务的样例（推荐先从 Slack 通知 + Jira 建单开始），改掉字段直接上线
4. 一周后统计两个数字：通知量降了多少、未闭环告警还剩几条——用数据决定要不要继续深化（比如挂上拓扑关联和 AI 辅助分析，见 overview 文档）

监控工具的价值，不在面板多好看，而在凌晨 3 点它能不能替你先做对第一件正确的事。keep 想做的就是把"第一件正确的事"从人身上挪到流程上。

【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep