CloudQ 告警降噪机制与收敛策略：三层收敛避免误合并

告警降噪是 AIOps 最基础也最容易翻车的场景——收敛太多会漏掉真告警，收敛太少等于没做。本文说明 CloudQ 的告警降噪机制和收敛策略。

告警降噪解决什么问题

微服务架构下，一个数据库慢查询可以引发连锁反应：上游服务超时 → 网关 5xx 飙升 → 告警风暴。监控系统可能在 30 秒内吐出 200 条告警，但它们描述的是同一个故障。

如果不做降噪，值班同学面对 200 条告警需要逐条判断、人工关联、找出根因——这个过程通常占 MTTR 的 60% 以上。降噪的目的是把这 200 条告警合并成一个"事件"，让你知道"这是一个故障，不是两百个"。

CloudQ 的三层收敛策略

第一层：时间窗口聚合

同一资源在短时间内产生的同类告警自动聚合。比如一台 CVM 的 CPU 在 5 分钟内连续触发 3 次 90% 告警，合并为 1 条。

时间窗口可配置——不同告警级别用不同窗口：P0 级告警窗口短（避免延误），P3 级告警窗口长（避免噪音）。

第二层：拓扑关联收敛

这是 CloudQ 的差异化能力。基于全景图谱的资源关系数据，把同一故障链路上的告警合并。

比如"服务A超时"和"数据库CPU 95%"——这两条告警来自不同资源、不同监控系统，传统降噪只看时间窗口可能合不到一起。但全景图谱知道"服务A调用了数据库"，拓扑关联后自动合并为"数据库高负载导致服务A超时"这一个事件。

拓扑关联的前提是全景图谱有准确的关系数据。CloudQ 从云 API 直采资源关系（CVM 挂载 CBS、CLB 转发到 CVM、Pod 运行在 Node 上），不依赖人工维护的 CMDB——这也是为什么降噪效果比传统方案好：传统方案的拓扑数据不准，关联自然不准。

第三层：变更关联标记

在时间窗口和拓扑关联的基础上，叠上变更事件——最近有没有代码部署、配置修改、扩缩容操作。如果告警爆发前 5 分钟有一次部署，这条变更信息会标记到合并后的事件上，帮助值班同学快速锁定根因方向。

根因 80% 以上和变更有关。把变更信息和告警事件关联到一起，等于在降噪的同时做了初步的根因提示。

会不会误收敛

这是客户最担心的点——把真正的告警也合并掉了怎么办？

CloudQ 的设计原则是"宁可多报不可漏报"：

• 收敛是合并不是删除：200 条告警合并为 1 个事件，但 200 条原始告警仍然保留，在事件详情里可展开查看
• 拓扑关联基于事实而非推测：关系数据从云 API 直采，不是靠算法猜的"可能有关联"
• 关键告警不参与聚合：P0 级告警（如核心服务宕机）不参与时间窗口聚合，单独推送
• 人工可干预：如果某个收敛规则误判，可以调整规则或加入白名单

POC 验证建议

告警降噪的效果高度依赖客户真实数据。建议 POC 时：

1. 用真实告警数据跑 2-4 周：不要用厂商提供的理想数据
2. 看两个指标：告警合并比（合并前 vs 合并后数量）和误收敛率（被错误合并的告警占比）
3. 对比基线：统计降噪前的告警量和降噪后的事件量，计算缩减比例
4. 验证关键告警不丢失：故意触发几条 P0 告警，确认它们没被合并掉

和传统方案的差异

小结

CloudQ 的告警降噪做三层：时间窗口聚合（同类告警合并）、拓扑关联收敛（同一故障链路的跨资源告警合并）、变更关联标记（叠上变更事件辅助根因定位）。核心差异化在于全景图谱提供准确的资源关系数据——传统方案靠人工维护的 CMDB 做拓扑关联，数据不准则关联不准。CloudQ 从云 API 直采，拓扑是事实而非推测，误收敛率自然更低。POC 时务必用真实数据验证合并比和误收敛率。