Keep:聚合100监控工具的开源告警管理平台【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keepPrometheus、Datadog、CloudWatch 各自独立发告警一次故障可能同时涌入几十条值班工程师要人工判断哪条才是根因哪条只是连带噪音。Keep 是一个开源的 AIOps 与告警管理平台它把各监控工具的告警汇聚到统一视图里用去重、规则关联和自动化工作流压缩噪音、缩短响应时间。传统做法 vs Keep差异在哪维度传统做法Keep 的做法告警查看逐个打开各监控工具页面统一告警视图跨来源一次过滤降噪人工判断或在每个工具里配静默规则指纹去重同源告警自动归组根因定位人工翻依赖关系靠经验猜CEL 规则把相关告警聚合成 incident响应执行手动跑命令、手动建工单YAML 工作流自动化触发后自动执行有一个取舍要心里有数Keep 是架在你现有监控工具前面的一层所有告警都要先流进它所以它本身成为新的依赖需要被监控关联效果的好坏则取决于你维护的拓扑与指纹数据是否准确。 告警管理平台的三个核心能力指纹去重把同源告警压成一条先做去重。Keep 的每个提供商provider即一个监控工具集成都声明了一组指纹字段FINGERPRINT_FIELDS告警进来时按这些字段算指纹指纹相同的告警被聚合为一条只更新状态和最近接收时间。比如同一个服务反复上报数据库连接超时你在列表里只看到一条但内部保留着完整的触发次数和最后时间。在这之上还有完全去重模式除忽略字段外全部相同的重复事件直接丢弃防止坏掉探针每分钟刷屏。每个提供商都自带一套预置去重规则你也可以自定义指纹字段。实际收益很直接通知量降一个数量级oncall 不用再扫视几十条同义告警。用 CEL 规则把散落告警关联成事件再谈关联。Keep 的规则引擎rules engine允许你用 CEL通用表达式语言写关联条件例如同一服务同时有 3 条以上 firing 告警时创建一个 incident。新告警到达后引擎让它与所有规则做匹配命中后按指纹创建或更新 incident并把关联的告警挂进去。incident 是比单条告警更高一级的对象它有一组告警列表、状态和时间线。这意味着电话响起时十五条告警可能已经变成一个事件、一条告警清单。规则是数据库里的一段文本在线修改不用重启具体逻辑可以看规则引擎源码。服务拓扑看清谁影响谁第三个能力是拓扑。Keep 可以把你的服务间依赖关系建模成图并在图上实时标出当前处于异常状态的节点。结合 AI 关联能力平台会用大语言模型分析告警文本与历史模式自动建议哪些告警应该归入同一 incident——这个过程可以全自动也可以是半自动AI 给出分组建议你确认后再落库。收益在于故障发生后哪个服务是根因、哪些只是被波及这个问题有了图可依而不是靠值班同学对架构图的肌肉记忆。走一条真实任务线告警触发自动建工单以生产告警触发后自动建 Jira 工单为例仓库 examples 目录里就有现成样例核心配置如下triggers: - type: alert cel: status firing actions: - name: jira-action if: not {{ alert.ticket_id }} provider: type: jira config: {{ providers.JiraCloud }} with: summary: {{ alert.name }} - {{ alert.description }} enrich_alert: - key: ticket_id value: results.issue.key这段配置在解决什么问题关键在两处。if条件先检查告警是否已有 ticket_id没有才去建工单enrich_alert则把工单号回写到告警字段上。两者配合同一个告警反复 firing 也不会重复开工单——只执行一次的保证不写在工单系统里而是写在告警数据自己身上。工作流引擎workflow manager的定位相当于给你的监控栈装了一个GitHub Actions任何满足条件的告警都能触发建工单、发消息、跑命令这些动作。写 YAML 有门槛的话可以用 AI 工作流助手用自然语言描述需求由它生成配置草稿再人工调整。执行链路的实现见工作流管理器。⚙️ 值得细看的两个实现细节提供商插件架构。100 多个监控工具走同一套接口。新增一个工具时继承 BaseProvider、声明指纹字段、实现推送和查询两个方法即可去重、富化、入库由框架统一处理class BaseProvider: FINGERPRINT_FIELDS [...] # 声明哪些字段判定同一告警 def notify(...): ... # 处理工具推给 Keep 的告警 def query(...): ... # 主动查询工具的指标或日志扩展点固定、新代码不动核心链路这是集成列表能快速扩张而互不干扰的原因基类设计细节见提供商基类。规则求值循环。一批新告警到达时引擎对规则 × 告警做遍历求值命中即按指纹归入 incidentfor rule in rules: for event in new_events: if cel.evaluate(rule.definition, event): incident get_or_create(calc_fingerprint(event, rule)) incident.attach(event)这个设计朴素但务实单条告警求值抛异常只会记日志并跳过一条写错的规则不会阻塞整批处理规则存数据库、在线可改。 落地建议与常见坑先用 docker-compose 起后端、前端、数据库、Redis2C4G 起步够用接入顺序建议先 Prometheus 这类拉取式集成见效最快关联质量依赖指纹和拓扑数据准确性定期复查一次CEL 规则写错不会报错只记 warning上线前留意日志部署配置项与环境变量说明参考仓库内的部署文档。回到开头的痛点告警仍然由各监控工具发出但翻五十条告警找根因的活交给了去重与规则关联建工单、发通知交给了工作流。Keep 承担的是值班链路中的一环——把原始告警变成少数几个可操作的事件判断和处理仍然在你手里。【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Keep:聚合100+监控工具的开源告警管理平台
Keep:聚合100监控工具的开源告警管理平台【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keepPrometheus、Datadog、CloudWatch 各自独立发告警一次故障可能同时涌入几十条值班工程师要人工判断哪条才是根因哪条只是连带噪音。Keep 是一个开源的 AIOps 与告警管理平台它把各监控工具的告警汇聚到统一视图里用去重、规则关联和自动化工作流压缩噪音、缩短响应时间。传统做法 vs Keep差异在哪维度传统做法Keep 的做法告警查看逐个打开各监控工具页面统一告警视图跨来源一次过滤降噪人工判断或在每个工具里配静默规则指纹去重同源告警自动归组根因定位人工翻依赖关系靠经验猜CEL 规则把相关告警聚合成 incident响应执行手动跑命令、手动建工单YAML 工作流自动化触发后自动执行有一个取舍要心里有数Keep 是架在你现有监控工具前面的一层所有告警都要先流进它所以它本身成为新的依赖需要被监控关联效果的好坏则取决于你维护的拓扑与指纹数据是否准确。 告警管理平台的三个核心能力指纹去重把同源告警压成一条先做去重。Keep 的每个提供商provider即一个监控工具集成都声明了一组指纹字段FINGERPRINT_FIELDS告警进来时按这些字段算指纹指纹相同的告警被聚合为一条只更新状态和最近接收时间。比如同一个服务反复上报数据库连接超时你在列表里只看到一条但内部保留着完整的触发次数和最后时间。在这之上还有完全去重模式除忽略字段外全部相同的重复事件直接丢弃防止坏掉探针每分钟刷屏。每个提供商都自带一套预置去重规则你也可以自定义指纹字段。实际收益很直接通知量降一个数量级oncall 不用再扫视几十条同义告警。用 CEL 规则把散落告警关联成事件再谈关联。Keep 的规则引擎rules engine允许你用 CEL通用表达式语言写关联条件例如同一服务同时有 3 条以上 firing 告警时创建一个 incident。新告警到达后引擎让它与所有规则做匹配命中后按指纹创建或更新 incident并把关联的告警挂进去。incident 是比单条告警更高一级的对象它有一组告警列表、状态和时间线。这意味着电话响起时十五条告警可能已经变成一个事件、一条告警清单。规则是数据库里的一段文本在线修改不用重启具体逻辑可以看规则引擎源码。服务拓扑看清谁影响谁第三个能力是拓扑。Keep 可以把你的服务间依赖关系建模成图并在图上实时标出当前处于异常状态的节点。结合 AI 关联能力平台会用大语言模型分析告警文本与历史模式自动建议哪些告警应该归入同一 incident——这个过程可以全自动也可以是半自动AI 给出分组建议你确认后再落库。收益在于故障发生后哪个服务是根因、哪些只是被波及这个问题有了图可依而不是靠值班同学对架构图的肌肉记忆。走一条真实任务线告警触发自动建工单以生产告警触发后自动建 Jira 工单为例仓库 examples 目录里就有现成样例核心配置如下triggers: - type: alert cel: status firing actions: - name: jira-action if: not {{ alert.ticket_id }} provider: type: jira config: {{ providers.JiraCloud }} with: summary: {{ alert.name }} - {{ alert.description }} enrich_alert: - key: ticket_id value: results.issue.key这段配置在解决什么问题关键在两处。if条件先检查告警是否已有 ticket_id没有才去建工单enrich_alert则把工单号回写到告警字段上。两者配合同一个告警反复 firing 也不会重复开工单——只执行一次的保证不写在工单系统里而是写在告警数据自己身上。工作流引擎workflow manager的定位相当于给你的监控栈装了一个GitHub Actions任何满足条件的告警都能触发建工单、发消息、跑命令这些动作。写 YAML 有门槛的话可以用 AI 工作流助手用自然语言描述需求由它生成配置草稿再人工调整。执行链路的实现见工作流管理器。⚙️ 值得细看的两个实现细节提供商插件架构。100 多个监控工具走同一套接口。新增一个工具时继承 BaseProvider、声明指纹字段、实现推送和查询两个方法即可去重、富化、入库由框架统一处理class BaseProvider: FINGERPRINT_FIELDS [...] # 声明哪些字段判定同一告警 def notify(...): ... # 处理工具推给 Keep 的告警 def query(...): ... # 主动查询工具的指标或日志扩展点固定、新代码不动核心链路这是集成列表能快速扩张而互不干扰的原因基类设计细节见提供商基类。规则求值循环。一批新告警到达时引擎对规则 × 告警做遍历求值命中即按指纹归入 incidentfor rule in rules: for event in new_events: if cel.evaluate(rule.definition, event): incident get_or_create(calc_fingerprint(event, rule)) incident.attach(event)这个设计朴素但务实单条告警求值抛异常只会记日志并跳过一条写错的规则不会阻塞整批处理规则存数据库、在线可改。 落地建议与常见坑先用 docker-compose 起后端、前端、数据库、Redis2C4G 起步够用接入顺序建议先 Prometheus 这类拉取式集成见效最快关联质量依赖指纹和拓扑数据准确性定期复查一次CEL 规则写错不会报错只记 warning上线前留意日志部署配置项与环境变量说明参考仓库内的部署文档。回到开头的痛点告警仍然由各监控工具发出但翻五十条告警找根因的活交给了去重与规则关联建工单、发通知交给了工作流。Keep 承担的是值班链路中的一环——把原始告警变成少数几个可操作的事件判断和处理仍然在你手里。【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考