AIOps 落地复盘：智能告警合并的准确率和漏报率权衡

发布时间：2026/7/25 1:18:33

AIOps 落地复盘：智能告警合并的准确率和漏报率权衡

一、告警风暴下的运维困境：为什么告警合并不是简单的"压数量"

生产环境里最让人头疼的不是故障，而是故障来临时 Prometheus + Alertmanager 发出的 200 条关联告警。节点 OOM 引发 Pod Evicted，Pod 退出触发 Service 不可用，链路超时又拉高 P99 延迟——一条物理故障像多米诺骨牌一样推倒整条告警链。值班工程师在海量通知中翻找根因、逐条确认涉及哪些服务、判断是否需要立即升级，这个过程消耗的不只是时间，还有团队的判断力。

做过运维的同学都清楚，降噪不是一道数学题。单纯的去重——按告警名称和时间窗口合并——看似把 200 条压到 20 条，实际上反而把真正关键的信息淹没掉了。Kubelet 不可用和 Ingress 路由失败绑定在同一个合并组，前者的严重性是后者无法比拟的，但合并算法并不在意区别。当你事后复盘才发现，合并策略的激进程度跟漏报率是一对双胞胎，压得越狠，丢的信息越多。

这就是 AIOps 智能告警合并要解决的核心问题：在告警压缩率和信息保真度之间找到工程上可接受的平衡点。它不是告警去重器的升级版，而是一个需要持续调参、持续跑回归测试的系统工程。

二、告警合并引擎的内部机制：从相关性计算到动态分组

合并引擎的工作不是静态的。它分成三个关键阶段：

第一阶段是预处理与实体抽取。告警原始文本里混杂着 CPU 百分比、内存字节数、节点名、命名空间、Deployment 标签。如果不清洗就直接做关联，两件完全不相干的事因为同属default命名空间就被分到一组。预处理层先把数值做离散化——CPU 从87.2%映射为高负载标签，内存从4096Mi映射为接近限额，再把实体（Pod、Node、Service）提取成结构化特征向量。

第二阶段是时序关联计算。这是引擎真正的核心。我们用的不是简单的关键词匹配，而是基于时间窗口计算告警间的 Jaccard 相似度——两批告警在 5 分钟时间窗口内涉及的拓扑实体交集越大、时序间隔越小，关联权重就越高。举例来说，Nodeworker-3的 DiskPressure 告警和同一节点上三个 Pod 的 Evicted 告警在 30 秒内相继触发，Jaccard 系数高达 0.92，引擎会判定为强关联。

第三阶段是分组决策。这里有两种路线：基于密度聚类的 DBSCAN 和基于预定义规则的约束分组。前者更灵活，能自动发现未知关联模式，但分组结果波动大，同一个集群今天分 3 组明天分 8 组。规则约束稳定可解释，但需要人工维护规则库。在生产实践中，我们采用的是先规则后聚类——规则覆盖 80% 的已知场景，聚类兜底处理未覆盖的 20%。

三、Go 实现：告警关联度的实时计算

以下是告警相关性计算的核心代码，强调实时性和可维护性：

// alert_merge.go package merge import ( "sync" "time" ) // AlertVector 告警特征向量，用于关联计算 type AlertVector struct { Timestamp time.Time NodeName string Namespace string PodLabels map[string]string Severity int // 1=info, 2=warning, 3=critical AlertType string } // JaccardSimilarity 计算两个告警向量在拓扑实体维度上的 Jaccard 相似度 // 相似度越高，表示两条告警涉及的实体交集越大，越可能同属一个根因 func JaccardSimilarity(a, b AlertVector) float64 { entitiesA := collectEntities(a) entitiesB := collectEntities(b) if len(entitiesA) == 0 && len(entitiesB) == 0 { return 0 } intersection := make(map[string]struct{}) union := make(map[string]struct{}) for _, e := range entitiesA { union[e] = struct{}{} } for _, e := range entitiesB { union[e] = struct{}{} if _, ok := makeSet(entitiesA)[e]; ok { intersection[e] = struct{}{} } } return float64(len(intersection)) / float64(len(union)) } // TimeDecay 时间衰减函数：告警时间间隔越大，关联权重越低 // 衰减因子默认 0.7，5 分钟后关联度衰减到原始值的约 15% func TimeDecay(t1, t2 time.Time, decayFactor float64) float64 { delta := t2.Sub(t1).Minutes() if delta < 0 { delta = -delta } // 使用指数衰减模型 weight := 1.0 for i := 0.0; i < delta; i++ { weight *= decayFactor } // 低于 5% 的关联忽略，避免无关告警污染分组 if weight < 0.05 { return 0 } return weight } // CompositeScore 综合评分：实体交集 × 时间衰减 × 严重度权重 // 严重度差异过大的告警即使实体交集大，也要降低分组概率 func CompositeScore(a, b AlertVector, decayFactor float64) float64 { jaccard := JaccardSimilarity(a, b) timeScore := TimeDecay(a.Timestamp, b.Timestamp, decayFactor) // 严重度差异惩罚：level-3 告警不应与 level-1 随便分组 sevPenalty := 1.0 diff := a.Severity - b.Severity if diff < 0 { diff = -diff } if diff >= 2 { sevPenalty = 0.3 // 严重度跨 2 级以上的告警，强制降低合并倾向 } return jaccard * timeScore * sevPenalty } func collectEntities(v AlertVector) []string { entities := []string{v.NodeName, v.Namespace} for k, v := range v.PodLabels { entities = append(entities, k+":"+v) } return entities } func makeSet(s []string) map[string]struct{} { m := make(map[string]struct{}, len(s)) for _, item := range s { m[item] = struct{}{} } return m }

这段代码的核心设计思路：合并决策不是二元的"合并 / 不合并"，而是连续的置信度分数。CompositeScore输出的值在 0 到 1 之间，排障平台据此决定以什么粒度展示合并结果。分数低于 0.3 的告警直接独立展示，0.3-0.7 的以轻量摘要合并，高于 0.7 的完全折叠只展示根因候选。

四、准确率与漏报率的工程权衡：边界条件分析

合并策略的参数调整是一个典型的 Pareto 优化问题。我们做过一次系统的回溯测试：在 14 天的历史告警数据上，遍历 5 组不同的时间窗口和衰减因子组合，统计自动分组结果与人工标注结果的匹配度。

衰减因子	时间窗口	准确率	漏报率	合并压缩比
0.5	3 min	92.3%	8.7%	3.2:1
0.7	5 min	87.1%	5.2%	4.8:1
0.85	10 min	76.4%	2.1%	7.1:1

三组参数的取舍非常直观：

激进合并（衰减 0.85、10 分钟窗口）：压缩比高达 7:1，告警数量大幅下降，但准确率跌到 76%，意味着每 4 条合并告警里就有 1 条是将无关告警错误捆绑——工程师会被误导，可能错过关键信号。
保守合并（衰减 0.5、3 分钟窗口）：准确率 92.3%，但压缩比只有 3.2:1，告警数量仍然偏多，人工排查负担没有实质性降低。
均衡策略（衰减 0.7、5 分钟窗口）：这是我们的生产选择。准确率 87% 在可接受范围内，5.2% 的漏报通过事后日报补充兜底。

必须明确指出，智能告警合并有一个根本性局限：它对模式已知的级联故障合并效果好，但对孤立的新类型故障无能为力。一个新出现的内核模块崩溃只在三台节点上产生 3 条告警，关联引擎找不到足够的相似信号，所有 3 条都会独立发出——但这恰好是正确的行为。基础设施不需要漂亮话，算法设计上必须承认：在某些场景下，少合并比多合并更安全。