Keep 告警聚合平台：把 12 个监控源的告警压成 1 条根因事件

Keep 告警聚合平台把 12 个监控源的告警压成 1 条根因事件【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep本周架构评审团队要评估一个决策是否把散落在 Prometheus、Datadog、CloudWatch 里的告警通道合并到一个统一面板。我们用了两天验证 Keep 这个开源 AIOpsIT 运维人工智能平台重点看它的告警聚合、根因分析、自动化响应三条链路这篇文章记录结论。项目定位不是第 13 个监控源Keep 是开源 AIOps 告警管理平台它架在你现有监控体系之上把多源告警收进统一视图做关联分析定位根因再通过工作流触发自动动作。它不是又一个数据采集器不会替代 Prometheus 采集指标也不是传统 SIEM安全信息与事件管理不做日志安全审计专注告警全生命周期管理。典型场景Keep 处理方式传统做法多源同时告警指纹去重后进入统一列表逐个控制台切换比对同一事件触发 30 条告警关联引擎合并为一个事件值班群人工归类下游服务报障找根因沿拓扑边回溯上游故障节点逐条查日志和调用链重复噪音告警映射规则自动抑制或改派人工反复调阈值核心能力拆解从数据进来到触发行动多源告警如何在 3 秒内聚合成一个事件Keep 通过 Provider第三方集成组件后文直接用 Provider机制接入 Prometheus、Datadog、Kafka、Webhook 等来源把每条告警归一化成统一结构包含指纹告警的唯一标识、严重度、标签三个核心字段。归一化之后关联引擎沿时间窗口、指纹、服务拓扑三条线做匹配数据库连接超时告警先触发时同窗口内、同一服务或其上下游触发的告警会自动并入同一个事件AI 模块随后生成一段根因摘要。事件时间线会告诉你谁先触发、谁被连带、哪个节点最可能是源头。这个过程相当于把散落的监控日志做了一次 JOIN返回单一结果集。从拓扑图里直接定位故障上游服务拓扑不是静态配置图而是从告警字段动态构建的依赖关系图。Keep 的拓扑处理模块根据告警里的服务名、类型和标签推断节点与边你在界面上点任意节点就能看到它的上下游服务当前异常节点会被标出。下游 API 延迟告警触发时不用先翻架构文档确认它依赖哪个数据库直接看拓扑图上游亮红的节点就是首要怀疑对象。恢复时间取决于你看图的速度而不是翻多少个仪表盘。边推断逻辑在 keep/topologies/可以直接读源码确认。用一句话描述需求自动生成响应流程运维自动化工作流是 Keep 的执行层触发条件命中后按步骤顺序执行查询数据、条件分支、调用 Provider 动作每个步骤都有超时、重试和上下文回写。界面上的 AI 助手接收自然语言描述比如每 5 分钟检查 Pod 状态失败就自动重启生成对应的工作流 YAML执行后可在历史里回看每一步的输入输出。用三行伪代码概括这个模型条件命中进入触发按序执行动作步骤结果回写上下文并通知。你不需要背字段名助手负责把模板填完整。Keep 部署教程5 分钟接上 Prometheus先拉代码启动最简部署不需要外部数据库git clone https://gitcode.com/GitHub_Trending/kee/keep cd keep docker-compose up -d启动后是三个容器UI 前端、API 后端和 WebSocket 服务状态存在 ./state 目录适合先做内部验证。UI 就绪后进入 Providers 菜单接第一个监控源。以 Prometheus 为例只需给查询地址和令牌- type: prometheus id: prometheus-prod # Keep 定期拉取 /api/v1/alerts 并解析为统一告警模型 prometheus_url: https://prometheus.example.com api_token: ${PROM_TOKEN}type 字段决定加载哪个 Provider 实现id 是后续工作流里引用它的名字。prometheus_url 指向你的 Prometheus 实例处于 alerting 状态的告警会被拉进 Keep。接其他源是同一套路换 type 和对应配置项即可各源完整配置见 docs/providers 下的文档。架构要点速览Provider 插件机制每种监控源一个独立目录新增数据源只需对基类实现少量标准接口现有实现看 Provider 插件目录class BaseProvider(abc.ABC): abc.abstractmethod def validate_config(self): ... abc.abstractmethod def dispose(self): ... def query(self, **kwargs): ... # 拉取数据 def notify(self, **kwargs): ... # 发送通知关联引擎输入输出输入是归一化告警流加时间窗口与拓扑边输出是带关联关系的事件核心逻辑在 keep/rulesengine/。工作流执行模型解析定义逐步评估条件顺序执行动作并回写上下文支持分支、foreach 与重试入口在 keep/workflowmanager/。落地建议先做什么何时别用先接两个噪音最大的告警源不要一次全量接入。先接告警频率最高、噪音最重的两个源通常是 Prometheus 加一个云厂商监控只用 Keep 做聚合和去重跑一周确认指纹策略合理后再扩源。再上关联规则和一条自动化工作流视图稳定后沿服务维度定义第一条关联规则再写一条步骤最明确的自动化工作流比如重复告警自动关闭。关联与工作流配置都是声明式 YAML可以进版本库管理变更。什么场景不建议直接上告警源少于 3 个、没有服务拓扑需求、流程只是告警进群时Keep 对你属于过度设计原生 Alertmanager 加值班路由就够了。Keep 的价值集中在关联层与自动化层这两块没有需求就不要为它买单。Keep 目前处于稳定日常运营阶段社区活跃provider 生态仍在增长。告警源超过 5 个的团队值得花半天做一轮验证。【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考