5 分钟跑通 Keep：从告警风暴到自动响应的实战指南
【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep
Keep 是一个开源的 AIOps 和告警管理平台，核心做的事是把分散在各监控工具里的告警收进一个面板，做去重、关联、富化，再用工作流自动处理。如果你现在每天要盯 Prometheus、Datadog、PagerDuty 好几块屏幕，它值得花一个下午评估。
它到底解决了什么问题
场景很典型：一次数据库连接池耗尽，上游 10 个服务各报一条告警，Slack 里 5 分钟弹出 40 多条通知，真正要看的只有 1 条根因。Keep 把这类告警按指纹合并、按规则聚成 incident，再把"通知人、开工单"这些动作交给工作流。适合已经在用多套监控工具、被重复告警折磨的团队，不适合只跑一套 Prometheus 且告警量很小的场景。
部署起来比想象中快，先看怎么拉起来。
环境准备与 5 分钟部署
仓库里的 docker-compose.yml 是开箱即用的起点，clone 下来直接起容器：
git clone https://gitcode.com/GitHub_Trending/kee/keep cd keep docker compose up -dcompose 文件里是 3 个服务：keep-backend（FastAPI）、keep-frontend（Next.js）、keep-websocket-server（Soketi，负责实时推送告警），数据库默认是内置的 MySQL，所有状态落在宿主机./state目录。需要 Prometheus/Grafana 监控 Keep 自身时，加--profile grafana即可。生产上想上 K8s 或 OpenShift，docs/deployment/kubernetes/ 下有现成的安装文档；AWS ECS 同理，见 docs/deployment/ecs.mdx。
起来之后登录界面，先看到的就是一张统一的告警表：
跑起来之后你会发现，价值主要落在四个功能上，下面逐个拆。
核心功能拆解：去重、关联、工作流、拓扑
告警去重：指纹字段是关键配置项
- 能做什么：把同一根因的重复告警合并成一条，减少通知噪音。
- 怎么触发：每条告警入库时先算指纹再入库，指纹由 provider 声明的字段决定。
- 效果是什么：指纹相同的告警只展示一条，工作流和富化也不会对同一告警重复触发。
具体机制在 keep/api/alert_deduplicator/，规则文档在 docs/overview/deduplication.mdx：
- 部分去重（默认）：按指定指纹字段匹配，字段相同即合并
- 完全去重：除忽略字段外全部字段相同则直接丢弃
- 默认忽略
lastReceived，避免时间戳差异导致漏合并 - 每个 provider 内置默认指纹字段，例如 Datadog 用
groups+monitor_id
最容易忽略的一点：provider 没声明指纹字段时，默认退回用告警名做指纹。也就是说如果你的自定义 webhook 告警名字都叫 "Error"，它们会全部合并成一条——这既是风险也是降噪利器，接入新数据源前先确认指纹字段。
关联规则：把散告警聚成 incident
- 能做什么：按条件把多条告警归并成 incident，支持手动审批或自动建 incident。
- 怎么触发：在 Correlation 界面建规则，条件基于告警属性（source、severity 等），可用 AND/OR 组合。
- 效果是什么：incident 名称可用模板变量动态生成，比如
"Service Issue on {{alert.labels.host}}"，多主机告警进来后会自动拼成host1,host2。
规则引擎逻辑在 keep/rulesengine/，文档见 docs/overview/correlation-rules.mdx。另外要提醒一句：文档里那套 AI 自动关联（用历史告警训练模型、5–15 分钟一个周期）目前标注为 Keep Cloud / Enterprise 能力，开源版没有，评估时别按 AI 关联来打预期，规则引擎才是开源版的主力。
工作流编排：给监控工具装一个 GitHub Actions
- 能做什么：告警进来后自动执行动作——发 Slack、建 Jira 工单、跑脚本、调任意 HTTP 接口。
- 怎么触发：YAML 声明式定义，trigger 支持 alert（可带 CEL 过滤）、interval（定时）、manual。
- 效果是什么：动作可带
if条件、foreach循环，执行结果还能回写富化到告警上。
引擎实现看 keep/workflowmanager/，一个典型例子是"Datadog 的 critical 告警按服务分流到不同 Slack 频道"：
triggers: - type: alert cel: source.contains("datadog") && severity == "critical"仓库里 examples/workflows/ 有 100+ 个可直接抄的 YAML 示例，从查 ClickHouse 到给 Jira 转状态都有。
服务拓扑：故障传播路径一眼看清
- 能做什么：把服务和依赖关系画成节点+边的拓扑图，节点带告警和指标推导的健康状态。
- 怎么触发：接入支持拓扑的 provider（Datadog、PagerDuty、ArgoCD、Cilium、Grafana、ServiceNow）自动发现；也可以手动加节点、拖拽连边。
- 效果是什么：incident 触发时直接在图上标出受影响节点，排查"谁拖累了谁"不用翻文档。
功能说明在 docs/overview/servicetopology.mdx，拓扑图数据支持 YAML 导入导出，可以当配置管理用。
这四个功能里，去重和工作流是日常用的高频项，建议先把这两块调顺再碰拓扑。
进阶配置：两个值得折腾的玩法
玩法一：定制指纹字段组合
默认指纹字段是按 provider 一刀切的，实际跑起来你会发现粒度不合心意。指纹字段是可配置的（文档 docs/overview/fingerprints.mdx 的 Customization 一节明确说可以改），取舍逻辑很简单：
| 组合方式 | 例子 | 后果 |
|---|---|---|
| 字段太宽 | 只用service | 同服务不同问题合并，漏掉独立故障 |
| 字段太窄 | service+instance+error_message | 每条都独立，去重失效 |
| 常用甜点 | service+ 告警名或labels里的关键标签 | 同根因合并、异根因分开 |
改完先拿一批历史告警回放验证（scripts/下有 simulate_alerts 相关脚本），确认合并数符合预期再上线。
玩法二：工作流里的多级条件分支
trigger 层的 CEL 决定"要不要跑"，action 层的if决定"跑哪条路"，两层配合才能写出像业务逻辑的东西。比如同一个告警：payments 服务只通知对应频道，其他服务再查一遍 ClickHouse 取最近错误日志后决定是否开工单——这在 examples/workflows/ 里能找到完整对照，if条件里能直接引用前面 step 的输出。再叠一个 interval 触发加内置函数（文档提到is_business_hours这类），就能做出"工作时间才推 P2 告警，其余进日报"这种策略，不用自己写 cron。
条件写完之后，规模到了什么程度该加什么组件，官方压测文档给得明明白白。
踩坑记录与常见问题（Q&A）
Q1：开源版能用 AI 自动关联吗？不能。docs/overview/ai-correlation.mdx 里明确标注开源版不支持，该功能属于 Keep Cloud / Enterprise。开源版用手动关联规则引擎替代。
Q2：指纹字段能改吗，要动源码吗？能改，不用动源码。文档写明指纹字段支持自定义配置；provider 未声明字段时默认用告警名。
Q3：告警量大了先加什么？总量超过 5 万条或搜索变慢，上 Elasticsearch；入库速率超过 1000 条/分钟，加 Redis + ARQ 做队列。这两条判断标准来自官方压测文档 FAQ。
Q4：docker compose 起来的数据会丢吗？不会。所有状态挂载在宿主机./state目录，容器重建数据还在；但官方文档同时警告，执行清理重装（down -v+ 清 state）会擦掉全部配置。
Q5：CEL 过滤写错了会怎样？工作流对每条告警执行，过滤条件写宽等于全量触发。建议先在 UI 的告警表用同样条件筛一遍，确认命中量级再提交工作流。
这些坑都解决后，剩下的就是按自己的告警规模配资源。
性能与规模参考
以下数据全部来自官方压测文档 docs/deployment/stress-testing.mdx，按累计告警总量分档：
| 累计告警总量 | Keep Backend 推荐配置 | 附加组件 |
|---|---|---|
| < 10,000 | 1 vCPU / 2GB（DB：2 vCPU / 8GB） | 无，默认关系型数据库即可 |
| 10,000 – 100,000 | 4 vCPU / 8GB（DB：8 vCPU / 32GB，优化索引） | 无 |
| > 100,000 | 8 vCPU / 16GB（DB：8 vCPU / 32GB） | Elasticsearch（2–3 节点）+ Redis（4 vCPU / 8GB） |
另外两组压测数字可以当容量参考：500 条/分钟的告警消化在 8 vCPU / 16GB 下约 1 秒完成；100 个工作流/分钟在 16 vCPU / 32GB 下约 3 秒。调优旋钮主要是 Gunicorn worker 数、把 API worker 和告警消化 worker 拆开、以及数据库内存和索引。
配置定下来后，剩下就是持续喂它真实数据。
资源导航与下一步
- docs/：官方文档总入口，providers、workflows、deployment 三大块都在这里，查配置项先看这里。
- keep/api/：后端主逻辑，告警入库、去重、路由都在这一层，读懂请求链路从这里入手。
- keep/providers/：全部 provider 实现，每个目录里的
FINGERPRINT_FIELDS和 provider 方法值得翻一翻。 - examples/workflows/：100+ 个工作流 YAML 示例，基本覆盖了 Slack、Jira、SMTP、数据库查询等常见动作。
- scripts/：告警模拟脚本，压测和验证去重规则时用它灌数据。
下一步建议：
- 接入一个真实数据源（Prometheus 或 Datadog provider 都有现成文档），先让告警表里有真数据。
- 对最吵的那个 provider 调一遍指纹字段，用模拟脚本回放验证合并效果，再开去重。
- 从 examples/workflows/ 挑一个最贴近你场景的 YAML（比如
create_jira_ticket_upon_alerts.yml），改两个字段跑通第一个自动化。
【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
