从一堆报错到一条结论：AI 辅助故障排查的落地方法

为什么"看日志"会越看越乱

线上出问题，工程师的第一反应是打开日志检索，搜一个 ERROR，结果刷出来几千行。逐条看、逐条猜，半小时过去，结论还是"好像是订单服务超时了"。这类排查的瓶颈通常不在检索速度，而在信息量太大、人脑处理不过来——尤其是凌晨值班、状态不佳的时候。

典型场景是这样的：上游支付渠道开始返回 502，订单、支付、通知三个服务同时受波及，各自抛各自的堆栈，一个工程师面对的是几万行交错的日志。搜索引擎再快也没用，因为你根本不知道该搜什么。这就是"草堆里找针、而草还在长"的问题。

AI 辅助排查就是针对这个环节：让模型先做聚类和摘要，把几千行日志压缩成十几条结论，人再做判断。核心设计是"人拍板、机器读日志"——模型不替你"修复"任何东西，它只是缩短从告警到假设之间的距离。

聚类是怎么做的

聚类不是按字符串简单比对，而是按"归一化指纹"分组：把堆栈里的时间戳、请求 ID、端口号等易变字段先掩码掉，再做哈希。于是"同一个 bug 触发了 400 次"会聚成一条、计数 400，而不是 400 条独立日志。

聚类质量取决于两件事：掩码对了哪些易变字段、时间窗口设多大。窗口太宽会把无关故障混到一起，太窄又会把一个故障拆成好几个。平台默认用滚动窗口，可以按需调整。

三步：聚类、摘要、定位

1. 错误聚类：把选定时间窗口内的报错按堆栈签名、错误类型、服务名自动分组，几千行压缩成十几类，每类带条数和占比
2. 智能摘要：对每一类生成一句话结论，例如"order-service 的支付回调接口从 14:20 起大量返回 502，占比 87%，疑似上游 payment-gateway 连接池耗尽"
3. 定位辅助：点击某一类，直接下钻到对应日志、Trace 和指标，串起完整证据链

[cluster-3] 87% (412 条) order-service /pay/callback -> 502
  根因提示: payment-gateway 连接池耗尽 (pool max=50, waiters=312)
  关联 Trace: 8f3a9c2e | 首次出现 14:20:03

自然语言转查询（NL2Query）

记不住字段名、SQL 函数也没关系。直接输入"查一下支付服务最近一小时的报错，按数量排个序"，平台会转成类 SQL 并执行，同时把生成的 SQL 原样展示出来，方便核对，也方便新同学照着学：

SELECT level, count(*) AS cnt
FROM logs
WHERE service = 'pay-service' AND ts > now() - 1h
GROUP BY level ORDER BY cnt DESC

实践建议与边界

• 先聚类再下钻，别一上来就翻原始日志
• 摘要结论当线索、不当定论，关键分支仍要回看原始堆栈
• 对聚类结果和摘要做反馈（打勾/纠正），模型会随使用越用越准
• 把聚类和摘要直接塞进告警通知里，把"出事了"的告警升级成"大概出了什么事"

它擅长处理大批量、重复性的故障（502 风暴、N+1 查询、每次请求都报的配置错误），对低频、一次性、或者"不写日志的静默故障"帮助有限。把它当排查加速器，而不是对系统的替代理解——最会用的人，是那些本来就懂自己架构、用它更快跳到正确位置的人。