Keep把 20 条告警压成 1 个事件AIOps 告警关联的开源解法【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep如果你的团队一次故障能收到几十条告警、却没人说得清从哪条查起那你需要的就是一个靠谱的告警根因分析工具。Keep 是一个开源 AIOps 平台它把散落在 Prometheus、Datadog、CloudWatch 里的告警收进同一处做聚合、去重、关联再靠工作流自动执行后续动作。这篇文章不吹架构只讲它实际能干什么、怎么跑起来、边界在哪。 从一次故障复盘说起20 条告警没人找到根因上个月一次大促后故障复盘会上拉了那晚的时间线10 分钟内值班群刷了 20 条告警——数据库延迟、Pod 重启、网关 5xx、Kafka 积压一条接一条。每个人盯着自己那块监控屏折腾两小时才定位到一块存储盘的问题。有同事说了句扎心的话这些其实是一回事只是没人把它们当成一回事。问题不在监控工具不够多而在告警之间缺一层关联。Keep 能干的三件事和你能拿它干嘛告警聚合去重。它把不同来源的告警先翻译成统一的数据模型再按指纹去重。你拿到手的效果是同一个 Pod 在三个节点反复重启不再刷三遍群消息而是合成一条还能看到这条 1 小时内出现过 6 次这种上下文。说白了这是给告警装了一个已读合并。拓扑依赖可视化。它从已连接的数据源Datadog、Cilium、ArgoCD、Grafana 等里提取服务依赖关系画成节点和边的图。你拿到手的效果是某个服务挂了直接看哪些上游依赖它、哪些下游会被拖下水爆炸半径不用靠脑补。这张图的价值在故障初期最明显省掉的是你逐台机器排查的那半小时。自然语言驱动工作流。你用大白话说一句告警来了查一下相关 Pod 状态再发条消息到 SlackAI 助手会帮你生成对应的工作流配置。你拿到手的效果是写自动化不再是会写 YAML 的那个人的专属活新人半天就能搭出第一条响应链路。工作流本身由 workflowmanager 里的引擎调度触发器支持告警触发和手动触发。从零跑起来最短路径Keep 安装教程最快的方式是 docker compose。官方镜像默认用 sqlite 存储、免登录模式拉起来就能用git clone https://gitcode.com/GitHub_Trending/kee/keep cd keep docker compose up -d起完之后后端监听 8080UI 在 3000。如果不止是跑着玩玩建议改两个环境变量KEEP_JWT_SECRET登录 token 的签名密钥。开启数据库认证AUTH_TYPEDB时必填别用默认值自己生成一串随机字符串。DATABASE_CONNECTION_STRING数据库地址。默认指向本地 sqlite文件放在 state 目录里生产环境建议换成 PostgreSQL 或 MySQL把告警数据和容器生命周期解耦。接着连接第一个监控源。Keep 内置了 100 多个 Provider接入方式大致三种集成方式典型工具一句话说明拉取式Prometheus、DatadogKeep 定期去查监控数据适合持续观测的指标推送式Webhook、Kafka监控工具主动把告警推给 Keep适合实时事件双向同步PagerDuty、Opsgenie告警和状态来回同步适合做事件管理闭环加一个 Provider 本质就是填一段配置比如接 Prometheusprovider: name: prometheus-prod type: prometheus config: base_url: http://prometheus:9090这里的设计值得说一句所有 Provider 都继承同一个基类配置校验、通知、查询走的是同一套接口见 providers 基类实现。所以不管后端接的是 Datadog 还是自研工具用法和管理方式都是齐的。深入一层关联是怎么算出来的很多人以为 Keep 的关联就是同时段告警归一堆其实它是个三层漏斗一层比一层细第一层时间窗。先按时间窗口把涌入的告警聚成候选组。告警风暴里大部分重复项在这一步就被压掉了剩下的才是需要认真看的。规则引擎基于 CEL 表达式你可以自己写规则比如同一命名空间下的 critical 告警合成一个事件关联引擎源码 不长值得翻一遍。第二层拓扑依赖。对还显得零散的一组告警对照服务拓扑加权处在同一条依赖链上的服务同时报警相关性就高。这一步的实现可以看 topologies 模块它负责从各 Provider 拉依赖关系并维护这张图。第三层语义匹配。接上 AI 后端OpenAI、Anthropic、Ollama 都行后它还会读告警的标题和描述判断Pod OOM和网关超时是不是同一件事并给事件写一段总结。没接 AI 也不是不能用只是这一层跳过纯走规则和拓扑。生产环境怎么用哪些边界要心里有数先说适合谁。团队里已经有 Prometheus、Datadog 这类监控在跑、日告警量上百条、值班超过一个人的收益最直接。如果整个系统一天就三五条告警一套简单的通知渠道也够不必为此多养一个平台。再说边界几条实话多租户隔离代码里有租户概念但自托管场景基本按单团队使用多个 BU 想共用一套实例要自己评估。数据库默认 sqlite 只适合小规模告警量大之后务必换真数据库不然查询会先于功能拖垮你。AI 关联质量取决于你接的模型内网环境可以接 Ollama 这类本地模型但效果要自己验收。高可用官方给了 Docker 和 K8s 两种部署多副本、数据库主备这些要按你们的环境自己规划没有开箱即用的一键高可用。下一步最值得做的两件事一是接上 PagerDuty 或 Opsgenie 做双向同步让 Keep 里的事件和你们现有的值班体系对齐二是参考 providers 目录 的结构写一个自定义 Provider把内部系统接进来。Keep 不是告警的万灵药它只是把过去靠人脑串联的那层关联放进了系统里。有了它值班的人可以多花时间解决问题少花时间切屏幕。【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Keep：把 20 条告警压成 1 个事件，AIOps 告警关联的开源解法
Keep把 20 条告警压成 1 个事件AIOps 告警关联的开源解法【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep如果你的团队一次故障能收到几十条告警、却没人说得清从哪条查起那你需要的就是一个靠谱的告警根因分析工具。Keep 是一个开源 AIOps 平台它把散落在 Prometheus、Datadog、CloudWatch 里的告警收进同一处做聚合、去重、关联再靠工作流自动执行后续动作。这篇文章不吹架构只讲它实际能干什么、怎么跑起来、边界在哪。 从一次故障复盘说起20 条告警没人找到根因上个月一次大促后故障复盘会上拉了那晚的时间线10 分钟内值班群刷了 20 条告警——数据库延迟、Pod 重启、网关 5xx、Kafka 积压一条接一条。每个人盯着自己那块监控屏折腾两小时才定位到一块存储盘的问题。有同事说了句扎心的话这些其实是一回事只是没人把它们当成一回事。问题不在监控工具不够多而在告警之间缺一层关联。Keep 能干的三件事和你能拿它干嘛告警聚合去重。它把不同来源的告警先翻译成统一的数据模型再按指纹去重。你拿到手的效果是同一个 Pod 在三个节点反复重启不再刷三遍群消息而是合成一条还能看到这条 1 小时内出现过 6 次这种上下文。说白了这是给告警装了一个已读合并。拓扑依赖可视化。它从已连接的数据源Datadog、Cilium、ArgoCD、Grafana 等里提取服务依赖关系画成节点和边的图。你拿到手的效果是某个服务挂了直接看哪些上游依赖它、哪些下游会被拖下水爆炸半径不用靠脑补。这张图的价值在故障初期最明显省掉的是你逐台机器排查的那半小时。自然语言驱动工作流。你用大白话说一句告警来了查一下相关 Pod 状态再发条消息到 SlackAI 助手会帮你生成对应的工作流配置。你拿到手的效果是写自动化不再是会写 YAML 的那个人的专属活新人半天就能搭出第一条响应链路。工作流本身由 workflowmanager 里的引擎调度触发器支持告警触发和手动触发。从零跑起来最短路径Keep 安装教程最快的方式是 docker compose。官方镜像默认用 sqlite 存储、免登录模式拉起来就能用git clone https://gitcode.com/GitHub_Trending/kee/keep cd keep docker compose up -d起完之后后端监听 8080UI 在 3000。如果不止是跑着玩玩建议改两个环境变量KEEP_JWT_SECRET登录 token 的签名密钥。开启数据库认证AUTH_TYPEDB时必填别用默认值自己生成一串随机字符串。DATABASE_CONNECTION_STRING数据库地址。默认指向本地 sqlite文件放在 state 目录里生产环境建议换成 PostgreSQL 或 MySQL把告警数据和容器生命周期解耦。接着连接第一个监控源。Keep 内置了 100 多个 Provider接入方式大致三种集成方式典型工具一句话说明拉取式Prometheus、DatadogKeep 定期去查监控数据适合持续观测的指标推送式Webhook、Kafka监控工具主动把告警推给 Keep适合实时事件双向同步PagerDuty、Opsgenie告警和状态来回同步适合做事件管理闭环加一个 Provider 本质就是填一段配置比如接 Prometheusprovider: name: prometheus-prod type: prometheus config: base_url: http://prometheus:9090这里的设计值得说一句所有 Provider 都继承同一个基类配置校验、通知、查询走的是同一套接口见 providers 基类实现。所以不管后端接的是 Datadog 还是自研工具用法和管理方式都是齐的。深入一层关联是怎么算出来的很多人以为 Keep 的关联就是同时段告警归一堆其实它是个三层漏斗一层比一层细第一层时间窗。先按时间窗口把涌入的告警聚成候选组。告警风暴里大部分重复项在这一步就被压掉了剩下的才是需要认真看的。规则引擎基于 CEL 表达式你可以自己写规则比如同一命名空间下的 critical 告警合成一个事件关联引擎源码 不长值得翻一遍。第二层拓扑依赖。对还显得零散的一组告警对照服务拓扑加权处在同一条依赖链上的服务同时报警相关性就高。这一步的实现可以看 topologies 模块它负责从各 Provider 拉依赖关系并维护这张图。第三层语义匹配。接上 AI 后端OpenAI、Anthropic、Ollama 都行后它还会读告警的标题和描述判断Pod OOM和网关超时是不是同一件事并给事件写一段总结。没接 AI 也不是不能用只是这一层跳过纯走规则和拓扑。生产环境怎么用哪些边界要心里有数先说适合谁。团队里已经有 Prometheus、Datadog 这类监控在跑、日告警量上百条、值班超过一个人的收益最直接。如果整个系统一天就三五条告警一套简单的通知渠道也够不必为此多养一个平台。再说边界几条实话多租户隔离代码里有租户概念但自托管场景基本按单团队使用多个 BU 想共用一套实例要自己评估。数据库默认 sqlite 只适合小规模告警量大之后务必换真数据库不然查询会先于功能拖垮你。AI 关联质量取决于你接的模型内网环境可以接 Ollama 这类本地模型但效果要自己验收。高可用官方给了 Docker 和 K8s 两种部署多副本、数据库主备这些要按你们的环境自己规划没有开箱即用的一键高可用。下一步最值得做的两件事一是接上 PagerDuty 或 Opsgenie 做双向同步让 Keep 里的事件和你们现有的值班体系对齐二是参考 providers 目录 的结构写一个自定义 Provider把内部系统接进来。Keep 不是告警的万灵药它只是把过去靠人脑串联的那层关联放进了系统里。有了它值班的人可以多花时间解决问题少花时间切屏幕。【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考