Keep 开源 AIOps 告警关联与根因定位如何把告警风暴变成可执行事件【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keepKeep 是一款开源的 AIOps 与告警管理平台定位是告警的瑞士军刀统一视图、去重、富化、过滤、关联与自动化。典型场景是——当 Prometheus、Datadog、CloudWatch 同时把几十个告警打到你的值班群时你想把它们合并成一条事件、标出最可能的源头再自动开一张 Jira 工单。Keep 做的就是这件事核心关键词是告警关联与根因定位。它和同类方案的差别Keep 不是一套监控采集系统而是架在你已有监控工具之上的一层。它的取舍集中在三点而不是功能堆叠维度常见商业/传统方案Keep 的取舍数据关系每个工具各自独立靠人脑拼接用统一的告警模型把多源告警拉平再靠指纹字段fingerprint和关联规则把分散信号聚成事件关联方式规则硬编码或纯人工判断基于CEL 表达式的关联引擎规则引擎条件可组合、可版本化集成方式每家一套私有插件统一的 Provider 抽象仓库内置126 个provider新增只需实现基类部署与协作企业版为主、价格高、配置重开源优先docker-compose/helm一键起几乎所有对象作为代码供给需要说明的边界文档里演示的全自动 AI 关联基于历史数据训练的聚类属于 Cloud / 企业版能力开源版提供的是规则/CEL 驱动的关联与 AI 富化用 OpenAI、Anthropic 等 provider 给告警补充上下文。下面能力拆解都以开源版为准。核心能力拆解1. 告警去重Deduplication—— 先把重复的压成一条原理每条告警进入后会走富化 → 去重两步用一组指纹字段判断是否为重复。分两种模式——部分去重按你指定的字段分组如serviceerror_message和完全去重所有字段一致即丢弃默认忽略lastReceived。价值同样的数据库连接失败连发 20 条只留 1 条并更新其状态值班群不再刷屏。最小示例部分去重{ service: payment, error_message: Database connection failed } { service: payment, error_message: Database connection failed }两条因指纹字段相同被合并service或error_message任一变就视为新告警。2. 关联引擎Correlation—— 把多条相关告警升成一个事件原理一条规则就是一组条件命中即创建 incident 或 incident 候选。条件基于告警属性source、severity、labels 等可用 AND/OR 组合并支持用{{ alert.attribute }}做动态事件命名例如把命中告警的 host 值自动拼进事件名、去重。价值它回答的不是这条告警重不重要而是哪些告警属于同一件事。最小示例severity critical AND source Prometheus的告警归入高优先级事件事件名可用Service Issue on {{ alert.labels.host }}动态生成。3. 服务拓扑Service Topology—— 让根因定位有图可依原理Keep 不是只存告警还维护服务间的依赖关系拓扑模块把告警落到拓扑节点上。价值某个节点报警时你能顺依赖边看到上游谁可能引发、下游谁会受波及定位路径从翻十几个界面变成看图。4. 工作流Workflows—— 告警来了自动做动作原理一个 Keep Workflow 是一段声明式 YAML由Triggers触发→ Steps取数/富化→ Actions执行操作组成支持if条件分支和foreach循环模板变量{{ alert.* }}与{{ step.* }}串联上下文。价值告警触发后能自动开 Jira 工单、发 Slack、调 bash 重启并把执行结果回写到告警上enrich_alert。最小示例Sentry 关键告警 → 通知 建 Jira 工单workflow: id: sentry-alerts triggers: - type: alert filters: - key: source value: sentry - key: severity value: critical actions: - name: create-jira-ticket if: {{ alert.service }} ftp and not {{ alert.ticket_id }} provider: type: jira with: issuetype: Task summary: {{ alert.name }} (created by Keep)上手路径以下按能不能跑起来排序每条都标注它解决什么、为什么需要。准备 Docker 与端口—— 前提。Keep 默认用 Docker Compose 起三个服务机器需装好 Docker 并预留 8080后端 API、3000前端等端口否则起不来。获取部署文件—— 把docker-compose.yml与docker-compose.common.yml放到工作目录可 clone 仓库https://gitcode.com/GitHub_Trending/kee/keep后复制这两个文件避免手抄出错。它解决的是服务编排定义从哪来。docker compose up -d—— 拉起全部服务。它会启动keep-backendFastAPI、keep-frontendNext.js、keep-websocket-server实时推送三个容器并把状态写到本地state/目录。浏览器打开前端接入第一个 Provider—— 验证数据链路。先接一个你最熟的监控源如 Prometheus / Datadog确认告警能进入统一视图再去调关联规则。配一条去重或关联规则—— 验证降噪是否生效。观察重复告警是否被合并、相关告警是否聚成事件这是判断 Keep 是否值回时间的最快信号。决策点只验证能力就到此为止要上生产再补认证AUTH_TYPE支持 SSO/SAML/OIDC/LDAP、把state/换成持久卷、并接上你已有的 Prometheus Grafana 监控栈仓库自带 可观测性配置 与 otel-shared。关键设计点选读统一 Provider 抽象用字段约定而非代码约定做扩展Keep 把 126 个集成都收敛到一个基类上。看 base_provider.py 的类属性就能理解它的扩展模型class BaseProvider(metaclassabc.ABCMeta): FINGERPRINT_FIELDS: list[str] [] # 决定该 provider 默认如何去重 PROVIDER_TAGS: list[...] [...] # alert / ticketing / topology ... PROVIDER_CATEGORY: list[...] [...] # Monitoring / Incident Management ...设计动机每个 provider 自带默认指纹字段与能力标签接入方不写一行关联代码就能开箱去重。权衡是——灵活性换标准化非标准告警源需要显式覆盖字段映射但对绝大多数监控工具这是划算的默认值。CEL 表达式做关联条件可读、可组合、可安全执行关联引擎rulesengine.py用celpy解释 CEL 表达式而不是自定义 DSL。好处是条件语法短、跨语言一致、可安全沙箱执行方便把哪些告警算同一件事写成可版本化、可测试的规则。代价是它对极复杂的统计型判断不如纯 SQL/ML 灵活——这也正是 Keep 把深度 ML 关联放到企业版、开源版聚焦规则关联的原因。适用与不适用场景适合已有多个监控/告警源Prometheus、Datadog、CloudWatch、Sentry 等需要一个统一视图 降噪层的小到中团队。想把告警 → 工单 → 通知 → 自愈做成可版本化的 YAML 工作流。需要本地/私有化/离线部署不想被商业 AIOps 的许可成本卡住。不适合只有一两个监控源、告警量很小的场景直接看原始告警更省事Keep 的关联价值体现不出来。指望开源版全自动、零规则地做 ML 根因定位——深度 AI 关联在开源版不可用需要自己写 CEL 规则或升级到企业版。需要采集指标/日志本身Keep 不做采集只做告警进来之后的处理。边界Keep 站在你现有监控栈的上层不替代 Prometheus/Grafana 的可视化与指标采集它的收益与告警源数量、重复率正相关——源越多、重复越多降噪与关联带来的价值越大。结尾先接一个你最熟的监控源、配一条去重规则看重复告警是否被合并——这一步能在几分钟内告诉你 Keep 是否值得继续投入。【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Keep 开源 AIOps 告警关联与根因定位：如何把告警风暴变成可执行事件
Keep 开源 AIOps 告警关联与根因定位如何把告警风暴变成可执行事件【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keepKeep 是一款开源的 AIOps 与告警管理平台定位是告警的瑞士军刀统一视图、去重、富化、过滤、关联与自动化。典型场景是——当 Prometheus、Datadog、CloudWatch 同时把几十个告警打到你的值班群时你想把它们合并成一条事件、标出最可能的源头再自动开一张 Jira 工单。Keep 做的就是这件事核心关键词是告警关联与根因定位。它和同类方案的差别Keep 不是一套监控采集系统而是架在你已有监控工具之上的一层。它的取舍集中在三点而不是功能堆叠维度常见商业/传统方案Keep 的取舍数据关系每个工具各自独立靠人脑拼接用统一的告警模型把多源告警拉平再靠指纹字段fingerprint和关联规则把分散信号聚成事件关联方式规则硬编码或纯人工判断基于CEL 表达式的关联引擎规则引擎条件可组合、可版本化集成方式每家一套私有插件统一的 Provider 抽象仓库内置126 个provider新增只需实现基类部署与协作企业版为主、价格高、配置重开源优先docker-compose/helm一键起几乎所有对象作为代码供给需要说明的边界文档里演示的全自动 AI 关联基于历史数据训练的聚类属于 Cloud / 企业版能力开源版提供的是规则/CEL 驱动的关联与 AI 富化用 OpenAI、Anthropic 等 provider 给告警补充上下文。下面能力拆解都以开源版为准。核心能力拆解1. 告警去重Deduplication—— 先把重复的压成一条原理每条告警进入后会走富化 → 去重两步用一组指纹字段判断是否为重复。分两种模式——部分去重按你指定的字段分组如serviceerror_message和完全去重所有字段一致即丢弃默认忽略lastReceived。价值同样的数据库连接失败连发 20 条只留 1 条并更新其状态值班群不再刷屏。最小示例部分去重{ service: payment, error_message: Database connection failed } { service: payment, error_message: Database connection failed }两条因指纹字段相同被合并service或error_message任一变就视为新告警。2. 关联引擎Correlation—— 把多条相关告警升成一个事件原理一条规则就是一组条件命中即创建 incident 或 incident 候选。条件基于告警属性source、severity、labels 等可用 AND/OR 组合并支持用{{ alert.attribute }}做动态事件命名例如把命中告警的 host 值自动拼进事件名、去重。价值它回答的不是这条告警重不重要而是哪些告警属于同一件事。最小示例severity critical AND source Prometheus的告警归入高优先级事件事件名可用Service Issue on {{ alert.labels.host }}动态生成。3. 服务拓扑Service Topology—— 让根因定位有图可依原理Keep 不是只存告警还维护服务间的依赖关系拓扑模块把告警落到拓扑节点上。价值某个节点报警时你能顺依赖边看到上游谁可能引发、下游谁会受波及定位路径从翻十几个界面变成看图。4. 工作流Workflows—— 告警来了自动做动作原理一个 Keep Workflow 是一段声明式 YAML由Triggers触发→ Steps取数/富化→ Actions执行操作组成支持if条件分支和foreach循环模板变量{{ alert.* }}与{{ step.* }}串联上下文。价值告警触发后能自动开 Jira 工单、发 Slack、调 bash 重启并把执行结果回写到告警上enrich_alert。最小示例Sentry 关键告警 → 通知 建 Jira 工单workflow: id: sentry-alerts triggers: - type: alert filters: - key: source value: sentry - key: severity value: critical actions: - name: create-jira-ticket if: {{ alert.service }} ftp and not {{ alert.ticket_id }} provider: type: jira with: issuetype: Task summary: {{ alert.name }} (created by Keep)上手路径以下按能不能跑起来排序每条都标注它解决什么、为什么需要。准备 Docker 与端口—— 前提。Keep 默认用 Docker Compose 起三个服务机器需装好 Docker 并预留 8080后端 API、3000前端等端口否则起不来。获取部署文件—— 把docker-compose.yml与docker-compose.common.yml放到工作目录可 clone 仓库https://gitcode.com/GitHub_Trending/kee/keep后复制这两个文件避免手抄出错。它解决的是服务编排定义从哪来。docker compose up -d—— 拉起全部服务。它会启动keep-backendFastAPI、keep-frontendNext.js、keep-websocket-server实时推送三个容器并把状态写到本地state/目录。浏览器打开前端接入第一个 Provider—— 验证数据链路。先接一个你最熟的监控源如 Prometheus / Datadog确认告警能进入统一视图再去调关联规则。配一条去重或关联规则—— 验证降噪是否生效。观察重复告警是否被合并、相关告警是否聚成事件这是判断 Keep 是否值回时间的最快信号。决策点只验证能力就到此为止要上生产再补认证AUTH_TYPE支持 SSO/SAML/OIDC/LDAP、把state/换成持久卷、并接上你已有的 Prometheus Grafana 监控栈仓库自带 可观测性配置 与 otel-shared。关键设计点选读统一 Provider 抽象用字段约定而非代码约定做扩展Keep 把 126 个集成都收敛到一个基类上。看 base_provider.py 的类属性就能理解它的扩展模型class BaseProvider(metaclassabc.ABCMeta): FINGERPRINT_FIELDS: list[str] [] # 决定该 provider 默认如何去重 PROVIDER_TAGS: list[...] [...] # alert / ticketing / topology ... PROVIDER_CATEGORY: list[...] [...] # Monitoring / Incident Management ...设计动机每个 provider 自带默认指纹字段与能力标签接入方不写一行关联代码就能开箱去重。权衡是——灵活性换标准化非标准告警源需要显式覆盖字段映射但对绝大多数监控工具这是划算的默认值。CEL 表达式做关联条件可读、可组合、可安全执行关联引擎rulesengine.py用celpy解释 CEL 表达式而不是自定义 DSL。好处是条件语法短、跨语言一致、可安全沙箱执行方便把哪些告警算同一件事写成可版本化、可测试的规则。代价是它对极复杂的统计型判断不如纯 SQL/ML 灵活——这也正是 Keep 把深度 ML 关联放到企业版、开源版聚焦规则关联的原因。适用与不适用场景适合已有多个监控/告警源Prometheus、Datadog、CloudWatch、Sentry 等需要一个统一视图 降噪层的小到中团队。想把告警 → 工单 → 通知 → 自愈做成可版本化的 YAML 工作流。需要本地/私有化/离线部署不想被商业 AIOps 的许可成本卡住。不适合只有一两个监控源、告警量很小的场景直接看原始告警更省事Keep 的关联价值体现不出来。指望开源版全自动、零规则地做 ML 根因定位——深度 AI 关联在开源版不可用需要自己写 CEL 规则或升级到企业版。需要采集指标/日志本身Keep 不做采集只做告警进来之后的处理。边界Keep 站在你现有监控栈的上层不替代 Prometheus/Grafana 的可视化与指标采集它的收益与告警源数量、重复率正相关——源越多、重复越多降噪与关联带来的价值越大。结尾先接一个你最熟的监控源、配一条去重规则看重复告警是否被合并——这一步能在几分钟内告诉你 Keep 是否值得继续投入。【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考