AI 日志摘要：别把关键上下文压没了

AI 日志摘要：别把关键上下文压没了

一、日志摘要不是把几万行压成三句话

线上故障时，日志量很大。AI 日志摘要可以帮助快速提取异常模式、错误堆栈和时间线，但摘要做得不好，也会把关键上下文压没。排障需要证据，不需要过度文学化的总结。日志摘要的目标是保留定位所需的信息。

最危险的做法，是把所有日志直接塞给模型，然后让它总结原因。日志里有大量重复、噪声和无关请求，模型可能被稀释重点。正确流程是先过滤、聚合、排序，再摘要。

二、摘要链路：过滤比生成更重要

flowchart TD A[原始日志] --> B[时间窗口过滤] B --> C[错误级别筛选] C --> D[traceId 聚合] D --> E[异常模式提取] E --> F[AI 摘要] F --> G[排障报告]

过滤条件应来自告警事件：服务名、时间窗口、traceId、错误码、接口路径和版本号。没有这些条件，日志摘要会变成全局搜索，成本高且效果差。日志平台先把候选证据找准，AI 才有发挥空间。

摘要要保留样本。比如某类错误出现 120 次，报告里应附 1 到 3 条代表性日志和 traceId。只写“出现数据库超时”不够，排障人员需要能跳回原始日志验证。

三、输出格式：摘要要带证据引用

下面是一份摘要输出结构。

{ "summary": "checkout-api 在 10:02 后出现数据库连接池等待超时", "top_patterns": [ { "message": "Timeout waiting for connection from pool", "count": 128, "sample_trace_id": "tr_abc123" } ], "time_range": "10:00-10:10" }

这种输出比自然语言段落更适合排障。可以按错误模式排序，点击 traceId 回到日志平台。AI 摘要不是终点，它应该是进入证据的导航。

还要注意敏感信息。日志可能包含 token、手机号、邮箱、订单号和内部 IP。进入模型前应脱敏，摘要输出也不要暴露敏感字段。运维效率不能换来数据泄露。

四、落地边界：摘要不能替代原始日志

AI 摘要适合作为第一视图，但原始日志必须可追溯。模型可能遗漏少量但关键的异常，也可能把相似错误合并得过粗。值班人员需要能展开查看原始证据。

摘要质量要评估。可以在故障复盘时标记哪些摘要有帮助，哪些误导，哪些缺少关键字段。反馈回流后，调整过滤规则和 Prompt。日志摘要不是一次性功能，需要跟着故障类型演进。

最后，摘要要快。故障中等 3 分钟生成报告，可能已经太慢。可以先给轻量摘要，再异步补充深度分析。排障工具也要考虑时效性。

摘要结果也要支持时间线。故障排查不只关心发生了什么，还关心先后顺序：先发布，还是先报错；先数据库慢，还是先应用超时。AI 摘要如果能把关键事件按分钟排列，值班人员会更容易判断因果。没有时间线，很多结论都只是相关性。

对于重复错误，摘要要合并，但不能丢失样本差异。比如同一个异常码在两个接口出现，可能影响范围不同。合并时保留接口、实例和 traceId 分布，才能避免过度压缩。

日志摘要还可以和 Runbook 关联。若摘要识别到连接池等待超时，就自动附上对应排查步骤和常用命令。这样 AI 负责把现场和知识库接起来，值班人员不用在多个系统之间来回翻。

五、总结

AI 日志摘要的关键不是压缩文字，而是保留证据上下文。先按告警过滤日志，再提取模式和样本，最后生成带引用的摘要。摘要是导航，不是原始日志的替代品。