企业官网建设流程全解析

如何用 Keep 把告警从"人肉值班"变成自动流水线？Keep 告警自动化完整指南

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

Keep 是一款开源 AIOps 告警管理平台，面向告警聚合与自动化。本文带你把 Keep 告警自动化跑起来：接入 Datadog、Prometheus 等监控源，清洗数据，让工作流引擎替人处理告警，把值班人解放出来。

凌晨的告警风暴，到底卡在哪儿？

凌晨三点的电话，通常不是被一条告警叫醒的，而是被两百条一起叫醒的。

数据库磁盘满了、上游服务抖了一下，指标、日志、拨测系统同时开火。你打开列表：约四成是重复的，三成指向同一个根因，剩下的散落在 Datadog、PagerDuty、Slack 三个工具里。分拣、去重、升级，全靠手。

代价不只是熬夜。响应时间从分钟级拖到小时级，每个值班的人都得背一份"哪些告警可以不看"的私人清单——这就是典型的告警风暴，也是告警风暴治理最难的地方。

Keep 的思路是把这件事变成流水线：一个开源 AIOps 平台，先聚合多源告警，再把重复性的工作交给工作流引擎。

Keep 凭什么接得住 130+ 监控源？

答案是一组双核：Provider + Workflow。

Provider 是桥。每一个 Provider 负责对接一类监控系统，做协议适配和格式转换——比如datadog_provider处理 Datadog 的告警，prometheus_provider承接 Prometheus 的告警规则。Workflow 是流水线，告警满足条件后自动执行对应动作。两者配合，Keep 接得住 130+ 种监控与协作工具，这也是多源告警聚合的地基：Datadog、Prometheus、Grafana、PagerDuty 都在支持清单里。

你平时最常用的 3 个接口：

拓扑视图还能帮你核对"管道"有没有接对。不过告警刚进来时还不好用，下一节看怎么把它们洗干净。

🧼 告警进来后，怎么"洗干净"？

原始告警通常是脏的：关键字段埋在文本里、缺属性、重复投递。Keep 的处理管道分三步走：提取 → 映射 → 去重。

提取：用正则从消息体里抠出关键信息。比如订单号藏在描述里，就把它变成独立字段：

name: "Extract customer ID" regex: "customer_id=([A-Z0-9]+)" attribute: "customer_id"

提取出来的字段是一等公民，可以被检索、过滤，也能直接喂给工作流条件。

映射：把外部数据源的属性叠加到告警上，比如用服务拓扑表补全"这个服务归谁管"：

name: "Service topology mapping" type: "topology" matchers: ["service"]

配完之后，每条告警都带上了归属和责任人。

去重：靠指纹字段判断"两条告警是不是同一条"，重复的只保留一份：

name: "datadog_default" fingerprint_fields: ["monitor_id", "description"] full_deduplication: true

指纹字段选哪几个，决定去重的粒度：太松会漏掉不同事件，太紧会把不同事件压成一条。

洗完的告警只是及格线，真正的省钱在"让它自己跑"，那才是工作流自动化登场的时候。

如何让 80% 的告警自己跑掉？

工作流用 CEL（通用表达式语言）写触发条件，整个定义装在一个 YAML 里。看个"支付服务出现 critical 告警就升级"的例子：

name: "critical-alert-escalation" trigger: type: "alert" conditions: - severity == "critical" - service == "payment-service" actions: - name: "notify-oncall" provider: "pagerduty-provider"

条件同时成立就触发动作，调用 PagerDuty 把通知推给值班人。想换动作或目标，只改 action 部分，不用碰其他逻辑。仓库里还附带大量现成样例，可以直接翻 examples/workflows/ 找模板。

不想手写 YAML 也可以。AI 助手接受自然语言，比如"每分钟查询 Cloudwatch 日志并检测错误，发送 Slack 消息"，它直接帮你生成对应的工作流。但工作流跑起来之后，告警还是可能吵——下一节解决这件事。

📉 告警太吵，怎么降噪？

告警降噪不靠单个功能，靠四板斧的组合。

AI 关联：相关告警被 Transformer 模型自动聚成事件簇，值班人看到的是"一个事件"而不是一堆碎片，噪音在这一层被砍掉一大截。

拓扑分析：把服务间依赖画出来，看清一条告警沿什么路径扩散，顺藤摸瓜找根因。

维护窗口：计划内维护期间抑制非关键告警。写一条cel_query（例如service == 'database'）加起止时间，命中的告警在窗口内自动静音。

RBAC 与多租户：用户、角色、权限都走 API 管理，不同团队可以用不同权限共用同一套平台。

四板斧可以叠加：先去重、再关联把量压下来，最后用维护窗口把可预期的部分静音。

上生产前必须过的 4 道关

生产上线前，有 4 件事值得各花十分钟确认。

第一关，认证：生产环境建议用 API Key，一行命令就能验证：

curl -H "Authorization: Api-Key YOUR_API_KEY" https://your-keep-instance/api/v1/alerts

OAuth2、Basic 也支持，按你企业的认证体系选。

第二关，性能三板斧：

• 批量：一次调用推送多条告警，别一条一条发；
• ETag：条件请求，内容没变就不重传；
• 异步：长任务走异步接口，拿X-Request-ID查状态。

第三关，自定义 Provider 四步法，给 Keep 还没覆盖的系统打补丁：

1. 继承BaseProvider基类；
2. 用数据类定义认证参数；
3. 实现validate_config()、_query()、dispose()三个方法；
4. 在__init__.py中注册导出。

完整模板和最佳实践放在 keep/providers/base/。

第四关，可观测性：Keep 在/api/v1/metrics端点暴露自身关键指标：

接进现有 Grafana，平台自己是否健康一眼可见。

四道关都过了，才轮到部署。

怎么部署、怎么扩？

部署没有玄学：Docker Compose 快速起，Kubernetes 上高可用。仓库里附了完整编排文件，拉代码即可开始：

git clone https://gitcode.com/GitHub_Trending/kee/keep

关键组件一览：

扩展按三条规律走：API 服务水平扩容扛并发；加工作流执行器实例提自动化吞吐；分布式队列削峰填谷。存储也分工明确：PostgreSQL 主存储，Elasticsearch 负责搜索与分析，Redis 管缓存和会话。

部署和扩展讲完，最后的问题是算账：值不值得上？

算笔账：值不值得上？

账很好算，成本侧是可控的：

收益侧给三个数字：

• 单条告警的平均处理时间，从 30 分钟压到 5 分钟；
• MTTR（平均修复时间）下降 40%；
• 80% 的常见告警场景交给自动化兜底。

对每天处理几百条告警的团队，这个比例基本站得住。账算完，再看两件事：路往哪走，坑在哪。

下一步往哪走，以及容易踩的坑

两个信息：平台的走向，和大多数人会踩的坑。

Keep 的演进方向有四个：AI 根因定位更精准，并走向预测性告警；边缘场景下做本地化处理；合规能力对齐 GDPR、HIPAA；吞吐上限做到每秒 10 万+ 条。

坑则大多出在工程习惯上，三条通用建议：

• 工作流和 Provider 配置进 git 版本管理——它们是代码，不是网页里的一堆文件；
• 关键工作流先在影子环境试跑，看指标再上生产；
• 告警量本身就是压测，大促前检查 Redis 和 PostgreSQL 的余量。

⚠️ 上线第一周别急着全自动。先跑只读的通知类工作流，等结果可信，再逐步放开自动处理。

方向是长期故事，短期能落地的是一份清单。

✅ 5 步上线清单

1. 评估现状：盘点监控工具、日均告警量、现有值班流程；
2. 选集成点：先接 Datadog、Prometheus 这类最关键的 1-2 个源；
3. 设计工作流：从最高频的场景写起——去重、通知、升级；
4. 小规模试点：先覆盖一个服务或一个团队，不推全量；
5. 看指标验收：盯alerts_total、处理时长和 MTTR，用数据决定下一步。

告警治理不是一次性工程，但走完这五步，凌晨三点的电话至少会少一大半。

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