Keep：把 20 条告警压成 1 个事件，AIOps 告警关联的开源解法

Keep：把 20 条告警压成 1 个事件，AIOps 告警关联的开源解法

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

如果你的团队一次故障能收到几十条告警、却没人说得清从哪条查起，那你需要的就是一个靠谱的告警根因分析工具。Keep 是一个开源 AIOps 平台，它把散落在 Prometheus、Datadog、CloudWatch 里的告警收进同一处，做聚合、去重、关联，再靠工作流自动执行后续动作。这篇文章不吹架构，只讲它实际能干什么、怎么跑起来、边界在哪。

🔍 从一次故障复盘说起：20 条告警，没人找到根因

上个月一次大促后故障，复盘会上拉了那晚的时间线：10 分钟内值班群刷了 20 条告警——数据库延迟、Pod 重启、网关 5xx、Kafka 积压，一条接一条。每个人盯着自己那块监控屏，折腾两小时才定位到一块存储盘的问题。有同事说了句扎心的话："这些其实是一回事，只是没人把它们当成一回事。"问题不在监控工具不够多，而在告警之间缺一层关联。

Keep 能干的三件事，和你能拿它干嘛

告警聚合去重。它把不同来源的告警先翻译成统一的数据模型，再按指纹去重。你拿到手的效果是：同一个 Pod 在三个节点反复重启，不再刷三遍群消息，而是合成一条，还能看到"这条 1 小时内出现过 6 次"这种上下文。说白了，这是给告警装了一个"已读合并"。

拓扑依赖可视化。它从已连接的数据源（Datadog、Cilium、ArgoCD、Grafana 等）里提取服务依赖关系，画成节点和边的图。你拿到手的效果是：某个服务挂了，直接看哪些上游依赖它、哪些下游会被拖下水，爆炸半径不用靠脑补。这张图的价值在故障初期最明显，省掉的是你逐台机器排查的那半小时。

自然语言驱动工作流。你用大白话说一句"告警来了，查一下相关 Pod 状态，再发条消息到 Slack"，AI 助手会帮你生成对应的工作流配置。你拿到手的效果是：写自动化不再是"会写 YAML 的那个人"的专属活，新人半天就能搭出第一条响应链路。工作流本身由 workflowmanager 里的引擎调度，触发器支持告警触发和手动触发。

从零跑起来：最短路径（Keep 安装教程）

最快的方式是 docker compose。官方镜像默认用 sqlite 存储、免登录模式，拉起来就能用：

git clone https://gitcode.com/GitHub_Trending/kee/keep cd keep docker compose up -d

起完之后，后端监听 8080，UI 在 3000。如果不止是跑着玩玩，建议改两个环境变量：

• KEEP_JWT_SECRET：登录 token 的签名密钥。开启数据库认证（AUTH_TYPE=DB）时必填，别用默认值，自己生成一串随机字符串。
• DATABASE_CONNECTION_STRING：数据库地址。默认指向本地 sqlite，文件放在 state 目录里；生产环境建议换成 PostgreSQL 或 MySQL，把告警数据和容器生命周期解耦。

接着连接第一个监控源。Keep 内置了 100 多个 Provider，接入方式大致三种：

加一个 Provider 本质就是填一段配置，比如接 Prometheus：

provider: name: prometheus-prod type: prometheus config: base_url: http://prometheus:9090

这里的设计值得说一句：所有 Provider 都继承同一个基类，配置校验、通知、查询走的是同一套接口，见 providers 基类实现。所以不管后端接的是 Datadog 还是自研工具，用法和管理方式都是齐的。

深入一层：关联是怎么算出来的

很多人以为 Keep 的关联就是"同时段告警归一堆"，其实它是个三层漏斗，一层比一层细：

第一层，时间窗。先按时间窗口把涌入的告警聚成候选组。告警风暴里大部分重复项在这一步就被压掉了，剩下的才是需要认真看的。规则引擎基于 CEL 表达式，你可以自己写规则，比如"同一命名空间下的 critical 告警合成一个事件"，关联引擎源码 不长，值得翻一遍。

第二层，拓扑依赖。对还显得零散的一组告警，对照服务拓扑加权：处在同一条依赖链上的服务同时报警，相关性就高。这一步的实现可以看 topologies 模块，它负责从各 Provider 拉依赖关系并维护这张图。

第三层，语义匹配。接上 AI 后端（OpenAI、Anthropic、Ollama 都行）后，它还会"读"告警的标题和描述，判断"Pod OOM"和"网关超时"是不是同一件事，并给事件写一段总结。没接 AI 也不是不能用，只是这一层跳过，纯走规则和拓扑。

生产环境怎么用，哪些边界要心里有数

先说适合谁。团队里已经有 Prometheus、Datadog 这类监控在跑、日告警量上百条、值班超过一个人的，收益最直接。如果整个系统一天就三五条告警，一套简单的通知渠道也够，不必为此多养一个平台。

再说边界，几条实话：

• 多租户隔离：代码里有租户概念，但自托管场景基本按单团队使用，多个 BU 想共用一套实例要自己评估。
• 数据库：默认 sqlite 只适合小规模，告警量大之后务必换真数据库，不然查询会先于功能拖垮你。
• AI 关联：质量取决于你接的模型，内网环境可以接 Ollama 这类本地模型，但效果要自己验收。
• 高可用：官方给了 Docker 和 K8s 两种部署，多副本、数据库主备这些要按你们的环境自己规划，没有开箱即用的"一键高可用"。

下一步最值得做的两件事：一是接上 PagerDuty 或 Opsgenie 做双向同步，让 Keep 里的事件和你们现有的值班体系对齐；二是参考 providers 目录 的结构写一个自定义 Provider，把内部系统接进来。

Keep 不是告警的万灵药，它只是把过去靠人脑串联的那层"关联"放进了系统里。有了它，值班的人可以多花时间解决问题，少花时间切屏幕。

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