企业官网建设流程全解析

凌晨 3 点被 200 条告警轰炸？用 Keep 三步控住你的 AIOps 告警

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

凌晨三点，值班手机又震了：Prometheus、Datadog、CloudWatch 里堆了两百多条告警，真正的原因淹没在噪音里。AIOps 告警管理平台 Keep 就是为这种局面准备的：它把各家监控工具的告警拉进同一个库里，先去噪、再关联、然后自动处置，让你看到的是 1～2 个值得处理的 incident，而不是一屏幕通知。

一条告警的旅程：从接入到自动处置

不按功能模块平铺，跟着一条告警的流转顺序走一遍更直观。

接入。Keep 通过 Provider 对接上百个监控、工单和协作工具，告警可以走 webhook 推送，也可以定时拉取。Prometheus 的规则告警、Datadog 的 monitor、CloudWatch 的 alarm，格式各不相同，但进 Keep 之后会被归一成统一的告警结构，带上来源、服务、严重级别、指纹这些字段，后面的去重和关联才有统一的操作面。告警、incident、工作流执行记录都落在同一个库里，重启之后历史照样可查。

去噪。去重发生在告警落库之前。部分去重用指纹字段（比如 service + 错误信息）把"同一个问题反复上报"合并成一条；全量去重则会丢弃完全相同的事件，避免重复推送把系统压垮。每个 Provider 都自带一套默认去重规则，开箱就能用，指纹字段也可以按你的业务再调。配合维护窗口，发布期间的告警还能直接静掉，不打扰值班。

关联分析。这是 AIOps 告警管理真正见效的地方。Keep 可以用 AI 自动把相关告警聚成一个 incident，也可以自己写关联规则，比如"10 分钟内同一个服务的 critical Prometheus 告警加 high Datadog 告警算同一个事件"。对自动关联结果不放心时，还有半自动模式：AI 只给分组建议，人工点一下确认才成事。incident 名字支持用告警属性动态生成，多条告警进来会自动合并，不用手工改名。

自动处置。关联完成后交给工作流：按告警属性触发，补充上下文，往 Slack、Teams 发消息，开 Jira 工单，甚至重启服务都行。工作流就是一段 YAML，可以版本管理、按代码重新部署；用 AI 助手还能从一句自然语言生成初版，改到满意再保存。

Docker Compose 部署 Keep

本地有 Docker 的话，三条命令就能玩起来：

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

等几分钟，浏览器打开http://localhost:3000就能进。默认的 compose 是免登录（NO_AUTH），想体验账号体系可以切到带认证的版本，用默认账号 keep/keep 登录。后端 API 在 8080，告警、工作流、密钥这些状态都写在./state目录，重启时挂同一个目录就行。玩完docker-compose down全部带走，想重来直接删掉 state 再启动。

几个日常用得到的配置，都在docker-compose.yml里：

想带认证跑的话，仓库里现成有docker-compose-with-auth.yml可以参考；想把可观测链路也搭起来，otel 版 compose 可以一起拉起来。

接入 Prometheus 等监控系统

接自己的监控工具路径都一样：选 Provider → 填凭证 → 验证连通。

1. 在 Providers 页面挑你用到的工具，Prometheus、Datadog、AWS CloudWatch 是出场率最高的三个；
2. 按向导填必要信息，API key 或端点地址。Prometheus 的 alertmanager 模式走 webhook 就能收，甚至不用填密钥；
3. 跑一次连通性测试，再丢一条真实告警过去，看它是否进了 Keep 的告警表、字段是否对得上。

接入之后，告警进来就是统一字段，去重和关联规则可以直接复用，不用为每家工具单独适配。同一个 Provider 还能用不同凭证建多份，比如生产、预发各一套 Prometheus，告警不会混在一起。支持的工具清单和各家的字段说明在 docs/providers/ 里。

Helm 部署 Keep 到生产环境

上集群推荐走 Helm：

helm repo add keep https://keephq.github.io/helm-charts kubectl create ns keep helm install keep keep/keep -n keep

后端建议多副本加弹性伸缩，避免单点：

backend: replicaCount: 3 autoscaling: enabled: true minReplicas: 2 maxReplicas: 5

监控接入 OpenTelemetry，让 Keep 自己的健康状态也能进同一套可观测链路：

backend: env: - name: OTEL_EXPORTER_OTLP_ENDPOINT value: "http://otel-collector:4317" - name: OTEL_SERVICE_NAME value: "keep-backend"

数据库记得开持久化并换成独立 PostgreSQL。要对外提供访问的话，在集群里装 ingress-nginx 做 TLS 终结。上线前把默认密码改掉、HTTPS 开起来、按角色配好 RBAC 权限，细节可以看 docs/deployment/。

Keep 能扛住哪些场景

大促容量：问题——大促前 CPU、内存、数据库连接数容量告警同时炸开，值班分不清先处理谁。Keep 怎么做——关联规则把这些容量告警归成同一个 incident，并触发扩容与呼叫值班的工作流。结果——一整套事件对应一张工单，第一响应不再靠人肉翻屏。

微服务故障定位：问题——核心服务挂了，上下游依赖各自触发告警，传播路径说不清。Keep 怎么做——服务拓扑图画出调用链并标出故障源服务，关联分析指向根因组件。结果——值班能直接看到上游慢查询，不用逐个服务猜。

踩坑与调优速查

提 issue 之前，先自查这几个高频问题会更快：

性能调优就抓四条：

• 数据库换成独立 PostgreSQL，给常查的告警字段加索引
• 开 Redis 缓存，加速告警列表和检索查询
• 调大告警批量入库的批次，减少逐条写的数据库压力
• 把非关键的富化动作挪到异步队列，主链路保持快

文档与源码去哪找

• 官方文档在 docs/，从概念、部署到各 provider 细节都有
• Provider 源码在 keep/providers/，每家工具一个目录，加新集成照着现有例子写
• 现成的工作流 YAML 在 examples/workflows/，通知、开工单类很多可以直接抄
• 部署章节 docs/deployment/ 给了 Docker、Kubernetes 和认证三套方案

Keep 用 AIOps 告警管理把几十家工具的噪音收敛成少数可处理的 incident，所有配置都能写成代码、进版本库、随时回滚。接下来可以试试：

• 在测试机用 Docker Compose 部署，接上 Prometheus 看统一告警表
• 给团队噪音最大的通道加一条去重规则
• 从 examples/workflows/ 抄一条工作流，把 Slack 通知接上

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