凌晨的告警群还在刷屏？Keep 告警管理平台的完整上手指南

凌晨的告警群还在刷屏？Keep 告警管理平台的完整上手指南

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

凌晨 3 点，告警群 200 条消息还在刷，没人敢先点哪一条。Keep 是一个开源 AIOps 告警管理平台：把 Datadog、Prometheus 等 130 多个监控源的告警汇进同一张表，用去重、关联和自动化工作流，把 MTTR 从 30 分钟压到 5 分钟。

项目全景速览

先说它能干嘛，你就当朋友安利工具：

• 一个入口看全部告警：Datadog、Prometheus、Grafana、PagerDuty……130 多种监控和协作工具，双向同步，不用开 5 个标签页。
• 降噪三件套：去重、关联、维护窗口，重复告警不再重复弹窗。
• 自动化工作流：触发条件 + 动作，YAML 写好就行，号称"监控工具的 GitHub Actions"。
• AI 能力：告警智能归集成事件、自动生成事件摘要，还能用自然语言直接生成工作流。

核心功能拆解

5 分钟把 Prometheus 或 Datadog 告警接进来

场景：你的告警散落在 Prometheus、Zabbix、Datadog 里，每个工具一套 UI，值班的人根本记不住该看哪个。

功能：Provider 就像翻译官，把每家监控平台的"方言"统一成普通话。在 Providers 页面挑一个，填地址和凭证，保存就连上了。支持两种模式：告警源推给 Keep（webhook），或者 Keep 定时去拉。

推模式就是把 webhook 指到这个端点：

POST /alerts/event/prometheus Authorization: Api-Key YOUR_API_KEY

效果：不管告警从哪个平台来，进来后统一变成同样的结构——severity、status、source，列表页一眼看完。

想自己接一个平台没覆盖的系统？继承 BaseProvider 就行，模板在 Provider 基类，照着写个鉴权、查询、清理三个方法。

用一条正则从告警正文里抠出工单号

场景：上游告警把客户 ID、工单号塞在自由文本里，下游自动化想按工单号分派，却拿不到结构化字段。

功能：提取规则（Extraction）就是干这个的——起个名字，填目标属性、写正则，还能加 CEL 条件限定只处理某类告警：

name: "Extract customer ID" attribute: "customer_id" regex: "customer_id=([A-Z0-9]+)" condition: 'source.contains("Datadog")'

效果：这就像快递员从面单上摘出收件号码，摘完直接写进告警属性，后面的工作流、筛选、关联都能用上。

Keep 去重规则：别让重复告警被当成新事件

场景：同一个 monitor 一分钟内触发 30 次，事件数原地起飞，看板全是假繁荣。

功能：去重规则按"指纹字段"判断两条告警是不是同一个。哪几个字段算指纹你说了算，还能勾选忽略字段，比如description、lastReceived这种每次都变的：

name: "datadog_default" fingerprint_fields: ["groups", "name"] full_deduplication: true

效果：去重像大楼门口的门禁，ID 一样的人不管刷多少次卡，都只记一次进场。重复告警变成"同一条告警又响了一次"，而不是 30 个新事件。

用 YAML 配置 Keep 工作流，接管重复的工单动作

场景："收到告警 → 通知 Slack → 建 Jira 工单 → 更新状态"，这套动作如果全靠手，值班的人光搬砖就搬一下午。

功能：工作流 = 触发器 + 动作。触发器可以是告警过滤条件、定时或手动；动作就是调任意 Provider。条件判断支持 CEL 和模板变量：

triggers: - type: alert filters: [{ key: source, value: cloudwatch }] actions: - name: trigger-slack provider: { type: slack }

效果：写一次，跑一辈子。嫌写 YAML 麻烦？AI 工作流助手可以用一句"每分钟查 CloudWatch 日志，出错就发 Slack"直接生成配置。现成写法可以翻 官方工作流示例，几十个模板从 Jira 到 Kafka 都有。

上手实操

最小路径五步，半小时能跑通：

1. 拿代码：git clone https://gitcode.com/GitHub_Trending/kee/keep
2. 一条命令拉起：docker compose up -d，前端在 3000 端口，API 在 8080。
3. 浏览器打开http://localhost:3000，进 Providers，选 Prometheus，填地址和密码，保存连接。
4. 把告警源的 webhook 指向 Keep 的事件接口，或者让 Keep 主动拉取：

curl -X POST -H "Authorization: Api-Key $KEY" \ http://localhost:8080/alerts/event/prometheus \ -d @alert.json

5. 建一条工作流：YAML 上传或 AI 助手生成，选个触发器，点一次手动运行验证。

⚠️ 三个容易卡的点：

• 默认 compose 是免鉴权模式；一旦开启 API Key 认证，请求头必须带Authorization: Api-Key，不然全是 401。
• 前端 3000、API 8080、WebSocket 6001 三个端口要分别映射，漏一个就是"能连上但页面空白"。
• Provider 类型名必须精确匹配，比如prometheus，拼错的话告警会静默走进死胡同。

真实场景举例

支付服务 critical 告警自动升级值班人

问题：凌晨 critical 告警响了，值班人没在群里，没人认领，一拖就是半小时。

配置思路：仓库里有个incident-tier-escalation模板可以直接抄。触发器挂在事件的 created/updated 上；第一次触发发 tier 0 到 Slack 并 @值班人，用enrich_incident把当前层级写回事件；条件检测到"层级还是 0 且又出了更重的告警"就自动升到 tier 1，@leader。层级是事件上的字段，升级判断全走条件表达式，不需要写代码。

结果：值班人先被精准 @，15 分钟没响应 leader 自动被拉进来。"这个谁管"的来回沟通时间省掉了，响应从平均 25 分钟压到 5 分钟以内。

周五维护窗口静默数据库噪音

问题：周五晚上升数据库，397 条非关键告警灌进来，真出事反而淹在里头。

配置思路：建一条维护窗口规则：CEL 过滤写service == 'database'，选上开始时间和相对时长，再决定被压制的告警还显示不显示在列表里。注意 Keep 刻意不压制 RESOLVED 和 ACKNOWLEDGED 状态，这样升级期间告警照常能关闭事件，流程不会断。

结果：我们当时就是这么干的——窗口期内 500 多条噪音归零，窗口一结束告警自动恢复正常，全程零人工清理。

进阶技巧与避坑

💡 划重点，都是踩过坑之后才信的话：

• 用批量接口推告警，别一条一条调，高并发下 API 会先扛不住。
• 读接口带上 ETag 条件请求，没变过的数据别重复拉。
• 打开KEEP_METRICS，把 Keep 自己暴露给 Prometheus 再挂上 Grafana，告警平台也得盯着自己。
• 多团队用 RBAC 加独立 API Key，按团队发最小权限，别共用一个超级管理员。
• 自研 Provider 记住三件事：继承 BaseProvider、实现鉴权/查询/清理、在注册表里挂上，少一步都跑不起来。
• 长任务走异步接口，拿X-Request-ID轮询状态，别把请求吊在半空。

选型参考

适合什么样的团队？监控源在 5 个以上、每天告警上千条、又想把"通知、建工单、升级、静默"这些动作自动化的团队，Keep 基本就是为这个场景做的。部署上 Docker 或 Kubernetes 一把梭，数据全在自己手里。

和 PagerDuty 这类 SaaS 的核心差异一句话：Keep 是开源自托管、工作流可以完全自定义，你改代码改配置都自由；代价是升级、扩容、安全都得自己管。规模小、求省事选 SaaS，要可控和可改造选 Keep。

下一步

1. 本地 Docker 跑起来
2. 先接上 Prometheus
3. 写第一条去重规则
4. 接一条 Slack 工作流

告警还是那些告警，只是从今往后，只有真问题才会敲你的窗。

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