Keep 实战指南：三步接入开源 AIOps 告警管理，把响应时间压到 5 分钟

Keep 实战指南：三步接入开源 AIOps 告警管理，把响应时间压到 5 分钟

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

凌晨两点，第一条告警弹出，工程师往往还要再等近一小时才接手——这是多数监控体系的日常。Keep 是一款开源 AIOps 与告警管理平台：把 Prometheus、Datadog 等监控源的告警统一接入，先聚合降噪，再用 AI 关联定位故障，最后用工作流自动处置，目标把 MTTR（平均修复时间，从发现到恢复的时长）从常见的 120 分钟压回 30 分钟以内。

告警疲劳：值班表背后的三笔账

一个微服务故障能同时触发几百条告警。行业数据有点扎心：其中约 40% 是误报或重复，工程师约 70% 的时间耗在重复告警上；告警又分散在 Prometheus、Datadog、Slack 等好几个系统里，拼一个故障全貌要切三四个界面。两笔延迟的账随之而来：从告警发生到人工响应平均 45 分钟，MTTR 平均 120 分钟。Keep 的解法分三步，后文也按这三步展开：管得住噪音、看得清关联、跑得动自动化。

🧹 管得住：告警聚合与指纹去重

去重引擎基于指纹识别（代码在 keep/api/ 的 alert_deduplicator 模块）：按你指定的字段给每条告警算一个"身份证号"，指纹相同的告警在时间窗口内合并成一条，原始上下文仍可在详情里展开，不会丢信息。

去重规则怎么配才不丢关键告警

原则只有一条：指纹字段选"稳定且能区分故障源"的，忽略字段放"每条都在变"的。

fingerprint_fields: [service, alert_name, host] ignore_fields: [timestamp, alert_id] time_window: 300

时间窗口从 5 分钟到 24 小时可调。窗口太小聚合不上，太大可能把两个独立故障捏成一条，建议先按 5 分钟跑一周，看合并率再调。

50+ 数据源靠 Provider 架构接入

接入层统一走 Provider 插件机制，keep/providers/ 下每个子目录就是一个集成：Prometheus、Grafana、Datadog 等监控源和 Slack、Teams、邮件等通知渠道实现的是同一套接口。要接新工具，照基类实现 validate_config、notify、query 三个方法即可，主流程不用动。

🔍 看得清：AI 关联与服务拓扑

聚合解决"别吵"，关联解决"为什么"。

AI 关联引擎能做什么

引擎把时间窗内语义相近的告警串成因果链：基于 Transformer（一种能理解序列上下文的深度模型）做模式分析，再结合时间序列依赖和服务拓扑判断，每组关联带一个置信度分数，阈值在 0.4–0.9 可调。调高更稳但漏得多，调低更全但噪音多，建议从 0.7 起步。

服务拓扑图怎么读

拓扑模块自动发现组件间的依赖关系并实时标记健康状态。故障发生时，沿依赖边向上游找第一个异常节点，基本就是根因候选；再看受影响的下游范围，决定先降级还是先扩容。

⚡ 跑得快：工作流把处置自动化

告警又少又准之后，剩下的是"谁来处置"。Keep 用声明式 YAML 定义工作流：触发条件（如 severity 为 critical）→ 富化步骤（拉日志、查数据库）→ 动作（扩容、建工单、发通知），支持条件分支、循环和失败重试，不用写胶水代码。

一个电商大促样本

某头部电商双 11 前接入 Keep，峰值日均 20,000+ 条告警，其中数据库连接池耗尽的告警反复刷屏。第一阶段配指纹聚合，日均降到 3,000 条，减少 85%；第二阶段开 AI 关联，把连接池、慢查询、上游超时串进同一故障场景；第三阶段用工作流自动响应，数据库故障响应从 15 分钟压到 30 秒。夜间值班从 8 人减到 2 人，系统可用性从 99.5% 提到 99.99%，客户投诉率从 0.8% 降到 0.1%。

Keep 部署：从 Docker Compose 到 Kubernetes

开发环境十分钟跑起来

默认栈包含 API、UI、Postgres、Redis，4 核 8G 的机器足够：

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

告警源节点少于 100 的环境，把 API 侧 WORKER_COUNT 设为 4、容器内存限 2G 即可。

生产环境怎么扩

100–500 节点建议 Kubernetes：8 核 16G 起步，配 HPA 弹性伸缩，Redis 换集群版提升缓存吞吐。超 500 节点再上多区域部署、数据库读写分离和消息队列缓冲；纯云团队可选 AWS ECS，数据不出域要求高的环境走本地部署（16 核 32G 参考）。

这笔账怎么算：收益与演进路线

收益与回收周期

按行业口径折算：日均告警 5000→500 条、响应 45→5 分钟、MTTR 120→30 分钟、团队 5 人→2 人、误报率 40%→8%，年化价值约 120 万美元。成本端软件免费（开源），一次性实施约 5 万、年维护 3 万，三年总投入约 14 万美元，对应 ROI 约 2571%，回收期约 1.4 个月。数字是行业估算，落地幅度取决于接入源数量，但量级可参考。

平台在往哪里走

官方路线图分三段：6 个月内做预测性告警（历史数据外推）、告警摘要自动生成和多租户；6–12 个月补因果推断式根因分析、成本异常检测和合规自动化；1–2 年目标是接近自愈的自主运维，以及告警与业务指标的智能关联。能力多以 Provider 插件形式放出，接入点值得提前规划。

快速上手：五步接入与治理节奏

首次接入按此顺序最顺：① 在 Providers 界面连上 Prometheus 等数据源；② 配去重与聚合规则；③ 建一条只做通知的最小工作流验证链路；④ 接 Slack/邮件等通知渠道；⑤ 配 RBAC 权限。之后把治理当节奏：每月复盘告警处理效果并调阈值，每季度做故障演练验证自动化，每年审计一次 ROI。分级策略建议从 P0 起步：P0 定 5 分钟响应并挂自动动作，P1 15 分钟，P2 1 小时，P3 进周报。更多配置细节见 docs/。

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