部署 keep：开源告警管理平台从本地体验到生产落地的完整路径
【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep
keep 告警管理平台把多来源的告警统一接进来，做去重、关联和自动化处置。这篇文章以 keep 部署为主线，走完从本地体验到生产落地的路径：部署命令、生产配置、集成接入，每一步都可以直接照做。
一、它解决什么问题
告警风暴。一个上游依赖抖动，多个监控工具同时报出几百条子告警，值班的人打开控制台，找不到先处理哪一条。
多源分散。Prometheus、Datadog、CloudWatch 各有控制台，同一次故障散落在三块屏幕里，谁也拼不出完整视图。
流转靠人肉。告警到达后，建工单、通知值班人、跑处置脚本，全靠人复制粘贴，凌晨三点最容易出错。
keep 告警管理平台做的事就是把这三件事收进一个系统：统一接入告警，然后去重、关联、富化，再用工作流触发自动化处置。
判断标准：上面三个场景命中两个，keep 部署就值得开始。
二、先做判断：keep 适不适合你
适合你的情况：
- 有 2 个以上告警源，想合并到一个界面处理
- 想把「告警 → 工单 / 通知 / 脚本」从手工变成工作流
- 值班噪音大，需要靠去重和关联压缩告警量
不适合的情况：
- 只有单一来源的阈值告警，不需要聚合，Alertmanager 自己就够用
- 希望完全托管的 SaaS 服务，不想自己跑任何容器
- 打算深度改源码做二次平台，应该先 fork 再开发
命中任何一条「不适合」，先别部署，回头把场景想清楚。
三、跑起来：最小部署路径
🐳 Docker Compose 三步起服务
前提只有一项：装好 Docker 和 Docker Compose v2。然后执行三条命令：
git clone https://gitcode.com/GitHub_Trending/kee/keep cd keep docker compose up -d这份 compose 会一次拉起三个服务：前端（3000 端口）、后端 API（8080 端口）、WebSocket（实时推送告警更新）。keep Docker Compose 部署到此结束，剩下的都是验证。
首次登录检查项
- 打开 http://localhost:3000 ，应直接进入告警列表页。默认
docker-compose.yml是AUTH_TYPE=NO_AUTH，没有登录页。 - 执行
docker compose ps，确认三个容器全部 running。 - 数据统一落在本地
state/目录，升级或迁移前先备份它。 - 需要登录时改用
docker-compose-with-auth.yml，默认用户名密码均为 keep，首次登录后立即改密码！
⚙️ 官方文档明确标注 NO_AUTH 不适用于生产环境，它只是体验用的快捷模式。
其余部署方式对比
| 方式 | 适用 | 代价 | 一句话建议 |
|---|---|---|---|
| Docker Compose（默认） | 本地体验、开发测试 | 单机单点，无高可用 | 本文推荐路径，默认用它 |
| Compose + DB 鉴权（docker-compose-with-auth.yml） | 需要登录的小团队 | 要自行设置 JWT secret | 团队内共享实例时用 |
| Kubernetes + Helm | 生产、多副本高可用 | 需要 K8s 集群和 Ingress 控制器 | keep Kubernetes 生产部署的正式路径 |
| 云托管（GKE、ECS 等） | 全托管运维 | 云成本、厂商绑定 | 有云预算的团队再考虑 |
更多环境变量见部署配置说明。启动后先做一件事：打开空告警列表，确认前端、后端、WebSocket 全链路可用。
四、三个最值得看的场景
告警列表：筛选与处理
你看到什么：所有告警排成一张表，带严重程度、状态、标签和时间戳，支持按条件筛选和排序。
你能做什么：用筛选条件定位目标告警；对反复上报的同一条告警，开启告警去重（去重文档），按指纹字段或全量字段去重。
AI 工作流助手
你看到什么：一个用自然语言生成工作流定义的对话框。
你能做什么：直接描述「每隔 N 分钟查一次某日志源，包含某关键字就发消息」，助手生成对应的工作流步骤，你检查后保存即可。
告警关联与拓扑视图
你看到什么：相互关联的告警被画成拓扑，根告警带着相关子告警一起展示。
你能做什么：点一根根告警，查看它带出的全部关联告警，快速圈定排查范围；再写关联规则，让同类告警自动归组。
本节动作：挑出你最近一周最高频的一类告警，给它配一条去重或关联规则，第二天看效果。
五、上生产前必须做的四件事
1. 副本数。单副本挂掉或滚动更新期间，告警接入会断流。
backend: replicaCount: 2 resources: requests: { cpu: 200m, memory: 512Mi } limits: { cpu: 1000m, memory: 1Gi } frontend: replicaCount: 22. 数据持久化。卷丢了，告警历史、工作流、Provider 配置全部丢失。
database: persistence: enabled: true size: 10Gi3. TLS 与鉴权。NO_AUTH 模式下任意 x-api-key 都会被接受，生产必须切到 DB 鉴权并启用 TLS。
global: ingress: tls: true annotations: cert-manager.io/cluster-issuer: "letsencrypt-prod"4. 日志与监控。把OTEL_EXPORTER_OTLP_ENDPOINT指向你的 OTel collector，LOG_LEVEL默认 INFO 即可。keep 本身也是被观测对象，自己的遥测开着，出问题才找得到。
判断标准：上线后执行一次kubectl get deploy，确认前后端副本数都是 2 且全部 ready。
六、把 keep 接进你的链路
数据流向是一条单向管道：监控源（Prometheus、CloudWatch、Datadog 等）把告警通过 webhook 或 API 发给 keep；keep 做去重、富化、关联；然后由工作流触发下游动作——发通知、建工单，或者回写监控系统把告警置为已解决。
典型集成按你的链路挑：
- Prometheus / Grafana：告警接入与指标查询
- Slack / Teams：值班通知与 @ 人
- Jira：自动建单并流转状态
- AWS CloudWatch：接入云监控告警
- PagerDuty：对接值班，告警解决后自动关单
- Webhook：对接任意 HTTP 端点
以上都在这一个页面管理：
你看到什么：已安装 Provider 的列表与状态，未安装的可以一键添加。
你能做什么：先接一个监控源加一个通知渠道，发一条测试告警，确认端到端通路是通的。
七、排障速查
| 现象 | 常见原因 | 处理动作 |
|---|---|---|
| 页面打不开 | 3000 端口被占用或前端容器未起 | docker compose ps看容器状态，docker compose logs keep-frontend看报错 |
| 页面能开但接口全挂 | 后端未就绪，或前后端 AUTH_TYPE 不一致 | 等后端 ready；核对两份 compose 的 AUTH_TYPE 一致 |
| 重启后数据没了 | state/目录未挂载或被清空 | 检查 compose 中./state:/state挂载，备份 state 目录 |
| 同一条告警反复上报 | 去重指纹字段与告警实际字段对不上 | 打开去重规则，改成该告警稳定存在的字段 |
| K8s Ingress 404/503 | Ingress 控制器未装或 class 没设 | kubectl get ingressclass确认控制器与 class |
兜底动作：任何异常先跑docker compose logs --tail 100，再回来对照这张表。
八、三步行动清单
- 按第三节三条命令启动，打开 http://localhost:3000 ，确认告警列表页可用。
- 接一个监控源（如 Prometheus）和一个通知渠道（如 Slack），发一条测试告警，确认去重规则生效。
- 在 K8s 集群上用 Helm 完成 keep Kubernetes 生产部署，逐项核对第五节四件事，步骤见 Helm 安装文档。
【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
