5 分钟跑通 Keep：AIOps 告警聚合与降噪怎么做到的

5 分钟跑通 Keep：AIOps 告警聚合与降噪怎么做到的

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

凌晨三点，Prometheus、Datadog、CloudWatch 同时炸出两三百条告警，你分不清哪条是真问题。Keep 是一个开源的 AIOps 告警管理平台，把散落在各监控工具里的告警收进一个界面，并替你完成去重、关联和自动化处置。它面向的主要是刚接手告警治理的 SRE 和后端值班工程师。

Keep 告警管理解决的三个告警痛点

同一个问题被推三次。一个服务挂掉，主机层、应用层、网关层各报一条，内容大同小异。Keep 的去重规则按你指定的字段生成指纹，指纹相同的告警只保留一条，你看到的是"1 个问题"而不是"30 条通知"。

工具各管各的。告警在 A 平台、拓扑在 B 平台、工单在 C 平台，值班的人需要在三个浏览器窗口之间来回切。Keep 把所有数据源的告警拉进同一张 Feed，统一加 severity、status、assignee 等字段，一处过滤即可。

根因找不到。微服务里上游超时、下游变慢、数据库连接池打满，三条告警指向同一个根因，但人眼很难把它们串起来。Keep 提供 AI 关联分析和基于服务拓扑的归并，帮你把"相关"的告警归到同一事件下。

Keep 部署：从克隆仓库到看到告警 ⚡

前置条件只有一个：Docker。下面这条路径从克隆到打开首页大约需要几分钟。

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

compose 文件里起了三个容器：keep-frontend（Next.js 界面，映射 3000 端口）、keep-backend（FastAPI，映射 8080 端口）、websocket-server（实时推送）。浏览器打开http://localhost:3000就是首页。仓库自带的docker-compose.yml是免登录模式，直接可用；如果你需要账号体系，仓库里另有docker-compose-with-auth.yml，默认账号密码是 keep/keep，登录后第一件事是改掉它。

容器全部变绿之后，部署这一步就结束了。

默认配置下数据写在当前目录的state/里，数据库是 SQLite。够本地体验，但离生产还差得远，下面先讲怎么用。

Keep 告警聚合与根因分析怎么用

告警降噪：用去重规则合并重复告警

当同一故障持续触发同一告警时，你可以进入左侧栏 Noise Reduction → Deduplication，给某个 Provider 建一条规则：指定参与指纹的字段（比如groups、monitor_id、name、lastReceived），其余字段忽略。之后所有指纹相同的告警会折叠成一条，页面右侧能看到规则各自消化了多少条。

根因分析：让 AI 关联相关告警

当多条告警疑似同一个根因时，你可以打开 Noise Reduction → Correlations 下的 AI Plugins，用 Transformers 关联算法处理。它会按租户的历史告警数据训练模型，两条滑杆控制阈值：Model Accuracy Threshold 决定模型准不准到够格上线，Correlation Threshold 决定相似度多高才算"同事件"。跑起来之后，执行日志里会直接列出高相似度的告警被归到了哪个 incident，根因分析报告不用自己拼。

自动化工作流：用自然语言生成处置流程

当你想让某类告警自动处置时，你可以不手写 YAML：打开 Workflow Builder，直接打字描述，比如"每分钟查一次 CloudWatch 日志，发现 error 就发 Slack"，AI 会把触发器、条件、动作拆成步骤让你逐步确认，右侧同步生成流程图。确认无误后点 Save，这条工作流就开始跑。不习惯对话式操作的人也可以直接写 YAML，examples/workflows/ 目录里有上百个现成样例可以抄。

Keep 接入 Prometheus 等现有监控栈

接入的思路对所有工具都一样，三步：选 Provider、填凭据、验证连通。

1. 首页进入 Providers 页，左侧是已连接的，右侧是待安装的，点一下就能展开配置表单。
2. 表单字段跟着 Provider 走。以 Prometheus 为例，核心就是prometheus_url，实例有认证就补上 token；Datadog 则是 API key。
3. 保存时会自动做一次连通性校验，报错的话按提示改凭据或网络即可。

Provider 本质是 Python 写的可扩展组件，既能拉数据、收告警，也能反向操作第三方系统（比如给 Jira 建单、给 Slack 发消息），所以"通知渠道"和"数据源"在 Keep 里是同一类东西。完整列表和每个 Provider 的字段说明在 docs/providers/overview.mdx。

上生产前值得确认的几件事

• 锁镜像版本：compose 里别用 latest，生产环境把keep-api、keep-ui固定到具体 tag，升级才有回滚点。
• 换掉默认认证：用带认证的 compose 启动，NEXTAUTH_SECRET和KEEP_JWT_SECRET改成随机长串——这两个是会话签发用的密钥，泄漏等于全站可登录。
• 走 HTTPS：在 3000/8080 前面挂一层反代（Nginx 或网关），告警数据里常有主机名、报错栈，不应明文走 HTTP。
• 数据库换掉 SQLite：把DATABASE_CONNECTION_STRING指到 PostgreSQL，SQLite 单文件扛不住并发写入；无论哪种库，配好定期备份。
• 给容器加资源上限：告警洪峰时 backend 的内存会涨，设了 limit 才能防止单容器拖垮整机。
• 留审计线索：把 backend 日志接到你现有的日志系统（或启用仓库自带的 OTEL 链路），事后追责"谁在什么时候改了规则"要靠它。

Keep 部署后的常见问题排查 📌

服务起不来。先看容器状态，再看 backend 日志：

docker compose ps docker compose logs --tail=100 keep-backend

端口被占用（3000/8080 已有进程）和state/目录权限不足是最高频的两类报错，前者改 compose 里的端口映射，后者确认挂载目录对容器可写。

连不上数据源。在 Providers 页重新点一次该 Provider 的保存，触发 validate，然后看 backend 日志里的具体异常：凭据错误会返回 401/403 类信息；如果是超时，多半是容器网络到不了你的监控实例——Prometheus 这类内网地址要么把容器接到同一网络，要么按 Provider 文档配代理。

Keep 适合告警来源在 2 个以上、且还没有专人值班降噪的团队，单机就能跑起来，数据量上来之后再考虑扩容。想系统了解概念，从 docs/overview/introduction.mdx 读起；想抄自动化作业，直接翻 examples/workflows/ 里的真实样例。

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