keep Prometheus 告警治理完整指南3 步从告警风暴到自动响应闭环【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keepkeep 是一个开源 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 不是什么选型之前先划边界避免踩坑能力Prometheus / Alertmanagerkeep指标采集与规则评估✅ 强项不采集只消费告警告警路由、静默✅ 基础能力支持且粒度到业务源跨源告警统一视图❌ 每套监控各看各的✅ 一个面板看所有告警指纹去重仅按规则指纹指纹字段 字段级规则告警 → 工单/群通知/自愈需自建 webhook 脚本声明式工作流一句话keep 不替代 Prometheus它接在 Prometheus 下游做告警的最后一公里管理。Prometheus provider 源码 里可以看到keep 把 Prometheus Alertmanager 推来的告警按fingerprint字段做指纹识别同一规则、同一实例的告警天然聚成一条。把告警量压下去的 3 个开关keep 的降噪能力集中在告警入库后的三个环节全部是默认开启或几行配置就能启用的指纹去重每个 provider 都预置了FINGERPRINT_FIELDS如 Prometheus 用 fingerprintDatadog 用监控项 ID指纹相同的告警自动归并重复推送只刷新状态、不重复通知。规则细节可参考去重文档。字段级聚合在去重规则里指定指纹字段比如service rule不同严重级别但同源的告警也能合成一条面板上直接看到N 个实例命中。陈旧告警自动清除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 后跑了一个季度的数据口径告警入库数 / 通知数 / 人工操作次数指标接入前Alertmanager 直推 IM接入 keep 后单日通知消息量约 4200 条约 300 条值班人员确认告警平均耗时9 分钟约 15 秒工单平均创建耗时人工 7 分钟告警触发后自动完成遗留未闭环告警次日存量每周 60~90 条趋近于 0自动清除真正省时间的是最后两项确认快是因为聚合后一条消息代表一整波存量清零靠的是定时扫描工作流。团队把省下来的时间投到了根因分析上而不是投到了回 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 件事按开头的命令起一个本地 keep 实例接上你的 Prometheus打开告警面板看一次风暴进来后被聚合成什么样建立体感从 examples/workflows/ 挑一个最贴近你业务的样例推荐先从 Slack 通知 Jira 建单开始改掉字段直接上线一周后统计两个数字通知量降了多少、未闭环告警还剩几条——用数据决定要不要继续深化比如挂上拓扑关联和 AI 辅助分析见 overview 文档监控工具的价值不在面板多好看而在凌晨 3 点它能不能替你先做对第一件正确的事。keep 想做的就是把第一件正确的事从人身上挪到流程上。【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考