尧图网页设计 
Keep 告警管理指南如何把上万条告警压缩成几个可处理事件【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep一个中型云团队每天从 Prometheus、Datadog、云厂商监控里收到的告警数以万计而值班人一天真正能认真看的只有几十条。Keep 是一个开源的 AIOps 告警管理平台它要解决的就是这个缺口不替你减少告警的产生而是把告警压缩成少数几个可以真正动手处理的事件Incident。告警管理的账进来 1 万条能处理几条多数监控链路止步于触发→通知。告警从工具里涌出来之后中间缺了一个处理层后果是三笔坏账重复账同一台机器 CPU 高每 30 秒生成一条新告警通知队列被同一条消息刷穿关联账一次数据库故障会派生出 12 条看起来各自独立的告警逐条排查等于盲猜响应账人需要登录五六个控制台手动确认平均响应时间被切屏消耗掉。层面传统做法有处理层之后的差距重复同一告警反复推送按指纹合并重复只计数、不重发关联逐条人工分拣规则 拓扑自动聚合成事件响应人肉登录多个控制台工作流自动触发动作Keep 的开源实现恰好覆盖了这三层且每一层都可以独立启用。三条防线去重、关联、拓扑一句话定位Keep 不是又一个告警聚合入口而是架在告警源和响应动作之间的统一处理层。所有 100 数据源提供商见 keep/providers/都先把异构告警字段归一化成同一个AlertDto之后的去重、关联、拓扑、工作流只认这一种结构。去重先让重复的告警闭嘴每个提供商都内置了预置的去重规则源码中为FINGERPRINT_FIELDS实现见 keep/api/alert_deduplicator/。部分去重Partial把指纹字段相同的告警归并成一条完全去重Full则直接丢弃除忽略字段外完全一致的事件。30 秒一轮的 CPU 告警变成一条持续中的告警这是降噪收益最大、配置成本最低的一步。关联把相关告警缝成一个事件规则引擎用 CEL 表达式书写聚合条件例如severity 为 critical 且 source 为 prometheus的告警命中后聚入同一事件事件名还能用{{ alert.labels.host }}这类模板从告警字段动态生成见 keep/rulesengine/。规则可以创建候选事件等待人工确认也可以直接开事件颗粒度由你控制。拓扑顺着依赖关系找源头配置好服务依赖图后拓扑处理器每 10 秒默认值回看 15 分钟窗口内的告警按服务分组当同一应用的多个服务同时告警就自动创建或更新该应用的事件。等于把哪几个服务一起挂了这个问题从人工判断变成了图上的事实。最短路径 一条命令起服务一份 YAML 接第一个告警# 默认 compose 只起 前端后端websocket状态存本地 ./state # 不依赖外部数据库先跑通告警进得来这一件事 git clone https://gitcode.com/GitHub_Trending/kee/keep cd keep docker compose up -d然后在 UI 里配好一个 Slack provider放一份最小工作流完整示例可参考 examples/workflows/slack_basic.yml# 最小工作流任何告警进来就推 Slack workflow: id: first-alert-to-slack triggers: - type: alert # 不限来源先验证告警链路是通的 actions: - name: notify provider: type: slack # 前提UI 里已配好该 provider 凭证 with: message: {{ alert.name }} {{ alert.service }}为什么这么配Keep 的集成顺序是provider 先行、workflow 后置。先用一个最粗的触发器确认告警进了系统、字段解析正确再去叠加精确的过滤条件——否则你分不清是工作流没写对还是告警根本没进来。机制拆解拓扑处理器到底在算什么最见工程含量的模块是拓扑处理器keep/topologies/topology_processor.py。它的核心循环很短# 默认每 10 秒跑一轮process_interval # 回看窗口 15 分钟look_back_window while not self._stop_event.is_set(): self._process_all_tenants() # 按租户隔离互不影响 self._stop_event.wait(self.process_interval)关键在两个默认值的设计意图为什么是短周期 长回看因为告警是分批到的单次事件无法判断影响面。处理器周期性地把最近 15 分钟的告警拉出来、按服务分组不在拓扑图里的服务直接忽略发现同一应用的多个服务都在告警时才开事件。依赖图在这里充当了隐式的关联规则——你不必手写若 A 且 B 则聚合图本身就是规则。这也是它敢用 10 秒这种激进周期跑库查询的原因窗口短、数据量可控且每个租户独立隔离异常。落地与调优按阶段做减法如果你刚跑起来先只调去重。给告警量最大的 1~2 个 provider 核对指纹字段确认合并前后数量的下降幅度再谈别的——去重没做好时上层关联统计出来的都是虚数。如果你的告警已带 service/labels优先接入服务拓扑并开启应用级事件。一次故障从 N 条告警变成 1 个事件这是最直观的体感收益也是后面写工作流的前提。如果你想上自动化只挑一类处理次数最多的故障写第一个工作流触发过滤器从窄起步限定 source severity在 UI 里验证过 provider 配置再放开范围。开篇那本账的结论其实很简单告警量不会自己变少唯一能调的是压缩比。Keep 的路径是按顺序压缩——先去重、再聚合、后自动化。如果你团队正被告警量淹没从上面调去重那一步开始就够了。【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Keep 告警管理指南：如何把上万条告警压缩成几个可处理事件
Keep 告警管理指南如何把上万条告警压缩成几个可处理事件【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep一个中型云团队每天从 Prometheus、Datadog、云厂商监控里收到的告警数以万计而值班人一天真正能认真看的只有几十条。Keep 是一个开源的 AIOps 告警管理平台它要解决的就是这个缺口不替你减少告警的产生而是把告警压缩成少数几个可以真正动手处理的事件Incident。告警管理的账进来 1 万条能处理几条多数监控链路止步于触发→通知。告警从工具里涌出来之后中间缺了一个处理层后果是三笔坏账重复账同一台机器 CPU 高每 30 秒生成一条新告警通知队列被同一条消息刷穿关联账一次数据库故障会派生出 12 条看起来各自独立的告警逐条排查等于盲猜响应账人需要登录五六个控制台手动确认平均响应时间被切屏消耗掉。层面传统做法有处理层之后的差距重复同一告警反复推送按指纹合并重复只计数、不重发关联逐条人工分拣规则 拓扑自动聚合成事件响应人肉登录多个控制台工作流自动触发动作Keep 的开源实现恰好覆盖了这三层且每一层都可以独立启用。三条防线去重、关联、拓扑一句话定位Keep 不是又一个告警聚合入口而是架在告警源和响应动作之间的统一处理层。所有 100 数据源提供商见 keep/providers/都先把异构告警字段归一化成同一个AlertDto之后的去重、关联、拓扑、工作流只认这一种结构。去重先让重复的告警闭嘴每个提供商都内置了预置的去重规则源码中为FINGERPRINT_FIELDS实现见 keep/api/alert_deduplicator/。部分去重Partial把指纹字段相同的告警归并成一条完全去重Full则直接丢弃除忽略字段外完全一致的事件。30 秒一轮的 CPU 告警变成一条持续中的告警这是降噪收益最大、配置成本最低的一步。关联把相关告警缝成一个事件规则引擎用 CEL 表达式书写聚合条件例如severity 为 critical 且 source 为 prometheus的告警命中后聚入同一事件事件名还能用{{ alert.labels.host }}这类模板从告警字段动态生成见 keep/rulesengine/。规则可以创建候选事件等待人工确认也可以直接开事件颗粒度由你控制。拓扑顺着依赖关系找源头配置好服务依赖图后拓扑处理器每 10 秒默认值回看 15 分钟窗口内的告警按服务分组当同一应用的多个服务同时告警就自动创建或更新该应用的事件。等于把哪几个服务一起挂了这个问题从人工判断变成了图上的事实。最短路径 一条命令起服务一份 YAML 接第一个告警# 默认 compose 只起 前端后端websocket状态存本地 ./state # 不依赖外部数据库先跑通告警进得来这一件事 git clone https://gitcode.com/GitHub_Trending/kee/keep cd keep docker compose up -d然后在 UI 里配好一个 Slack provider放一份最小工作流完整示例可参考 examples/workflows/slack_basic.yml# 最小工作流任何告警进来就推 Slack workflow: id: first-alert-to-slack triggers: - type: alert # 不限来源先验证告警链路是通的 actions: - name: notify provider: type: slack # 前提UI 里已配好该 provider 凭证 with: message: {{ alert.name }} {{ alert.service }}为什么这么配Keep 的集成顺序是provider 先行、workflow 后置。先用一个最粗的触发器确认告警进了系统、字段解析正确再去叠加精确的过滤条件——否则你分不清是工作流没写对还是告警根本没进来。机制拆解拓扑处理器到底在算什么最见工程含量的模块是拓扑处理器keep/topologies/topology_processor.py。它的核心循环很短# 默认每 10 秒跑一轮process_interval # 回看窗口 15 分钟look_back_window while not self._stop_event.is_set(): self._process_all_tenants() # 按租户隔离互不影响 self._stop_event.wait(self.process_interval)关键在两个默认值的设计意图为什么是短周期 长回看因为告警是分批到的单次事件无法判断影响面。处理器周期性地把最近 15 分钟的告警拉出来、按服务分组不在拓扑图里的服务直接忽略发现同一应用的多个服务都在告警时才开事件。依赖图在这里充当了隐式的关联规则——你不必手写若 A 且 B 则聚合图本身就是规则。这也是它敢用 10 秒这种激进周期跑库查询的原因窗口短、数据量可控且每个租户独立隔离异常。落地与调优按阶段做减法如果你刚跑起来先只调去重。给告警量最大的 1~2 个 provider 核对指纹字段确认合并前后数量的下降幅度再谈别的——去重没做好时上层关联统计出来的都是虚数。如果你的告警已带 service/labels优先接入服务拓扑并开启应用级事件。一次故障从 N 条告警变成 1 个事件这是最直观的体感收益也是后面写工作流的前提。如果你想上自动化只挑一类处理次数最多的故障写第一个工作流触发过滤器从窄起步限定 source severity在 UI 里验证过 provider 配置再放开范围。开篇那本账的结论其实很简单告警量不会自己变少唯一能调的是压缩比。Keep 的路径是按顺序压缩——先去重、再聚合、后自动化。如果你团队正被告警量淹没从上面调去重那一步开始就够了。【免费下载链接】keepThe open-source AIOps and alert management platform项目地址: https://gitcode.com/GitHub_Trending/kee/keep创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考