CNCF 多信号根因分析为什么不能只看告警：时间、拓扑与证据链的落地边界

生产事故里最先跳出来的通常是一条告警，但告警只说明“某个指标越过了阈值”，并不能直接回答“谁先坏了、故障怎样传播、现在看到的异常是不是同一条链”。CNCF 近期分享的自动化根因分析实践，把问题拆成信号类型、时间和服务拓扑三个维度。这个拆分很适合落地：先缩小用户影响范围，再把 metrics、logs、traces 放进同一条时间线，最后沿依赖关系形成可验证的候选根因。

下面的服务名、数值和字段是原创示例，用来说明工程边界，不代表某个厂商的固定实现。

一、先把告警还原成用户影响链

第一步不是把所有服务的日志都拉出来，而是先定义这次事故影响了哪条用户路径。例如结算接口出现 500，就从入口请求对应的调用链得到 checkout-service → payment-service → database 这个候选子图。排查范围从全平台缩小到几十个相关节点，噪声会明显下降。

OpenTelemetry 将 traces、metrics、logs 作为不同观测信号；它们只有在服务身份、时间戳和关联上下文足够稳定时，才有机会被放到同一张排查图里。实际接入时至少保留 service.name、事件时间、环境和请求关联标识，并把部署事件、开关变更作为独立事件记录。

二、把三类信号统一成可关联事件

不同探测器不要直接把结果写成各自的长文本。可以先归一成一个小事件结构，再由下游负责排序和聚合：

{
  "time": "2026-09-04T09:24:00Z",
  "service": "payment-service",
  "signal": "metric",
  "severity": 0.85,
  "kind": "error-rate-spike",
  "evidence_ref": "metric://payment/error-rate?p95"
}

日志探测器可以引用异常簇，追踪探测器可以引用 trace ID，指标探测器则保留观测值和基线。关键不是把三类数据变成同一种数据，而是让每条异常都有相同的服务身份、时间和证据引用。这样新增一种探测器时，不必重写相关引擎。

三、用时间窗口和序列指纹去掉重复噪声

同一故障可能每几秒重复传播：数据库先报错，支付服务随后超时，结算接口再返回 500。如果每次传播都生成一个候选，值班人员看到的会是几十条重复结论。可先用可配置的滑动窗口聚合，例如以事故时间点前后 5 分钟作为初始范围，再按服务序列生成指纹，把重复路径折叠成“5 分钟内重复 47 次”。

时间相关性只能说明“可能同时发生”。窗口过大，会把无关发布和流量波峰混在一起；窗口过小，又可能错过跨服务的传播延迟。因此聚合结果要保留原始事件列表、窗口大小和重复次数，方便复盘时重新调整，而不是只保存一个不可解释的总分。

四、沿拓扑判断因果方向

同一时间窗口里，多个服务都可能异常，但下游异常不等于下游是根因。沿依赖图反向查看：如果 payment-service 的错误先于 checkout-service 的延迟上升，并且两者存在调用边，那么支付服务更值得优先验证；如果只有下游有异常，拓扑关系就不能凭空推导出上游故障。

候选路径可以综合四类信息：节点异常强度、调用边可信度、异常先后和路径长度。不要把结果写成“分数最高所以确定”，而应写成“依据是什么、还缺哪一项证据”。例如：支付服务错误率从基线 0.2% 升到 0.8%，早于结算接口 p99 从 340ms 升到 2100ms；对应 trace ID 能回查到数据库异常，则形成一条优先验证路径。

五、用证据链生成可验证的候选根因

一次合格的输出至少包含：疑似起点服务、传播路径、用户可见症状、每个节点的 metric/log/trace 引用、置信度拆解，以及一段人能读懂的叙述。值班工程师可以按这段叙述快速回查，而不是重新打开三个系统凭经验拼图。

最后必须留下反馈闭环：工程师接受、驳回或修正了哪条假设，采取的缓解动作是否有效。只有把反馈与原始证据绑定，后续才知道是探测器阈值、拓扑关系还是时间窗口需要调整。LLM 或自动化编排可以帮助补充查询，但应受限于权限、速率和来源记录，不能绕过人工确认直接执行高风险操作。

相关问题

为什么不能只用告警名称判断根因？

告警通常是某个观测点的结果，可能描述的是传播后的症状。至少要补齐时间先后、调用关系和可回查的原始信号。

没有完整 traces 还能做多信号关联吗？

可以先用 metrics、logs 和部署事件做有限关联，但拓扑方向和请求级证据会变弱，应明确标注证据缺口。

候选根因的置信度高就能自动回滚吗？

不能。置信度是排序依据，不是授权条件；回滚、关闭开关等动作仍应经过变更权限和人工确认。

参考：CNCF 多信号根因分析实践、OpenTelemetry Signals、OpenTelemetry Observability primer。