← Back to all guides

用 AI 分析日志并定位线上故障：从脱敏到可执行修复

为什么 AI 适合处理日志

线上日志通常混杂请求参数、调用链、堆栈和重复报错。人工排查容易遗漏时间关联，也很难快速从数万行内容中区分根因与连带异常。AI 的价值不是替代监控系统，而是把已筛选的日志转成可验证的假设、排查顺序和修复建议。关键原则是：先缩小范围，再把结构化上下文交给模型。

第一步：截取并脱敏故障窗口

假设支付服务在 14:05 到 14:10 出现大量 502。先按 request_id、时间和错误级别提取上下文，而不是把整天日志直接发送给模型：

kubectl logs deploy/payment-api --since-time=2025-03-08T14:05:00Z | rg "ERROR|WARN|502" | head -n 300 > incident.log

随后删除或替换手机号、Cookie、Authorization、银行卡号等敏感字段。生产环境应在日志管道中预先掩码；临时处理时也要检查文件内容。保留时间戳、服务名、trace_id、HTTP 状态、异常类型和关键耗时，这些字段决定模型能否建立因果关系。

第二步：让模型按证据输出结论

不要只问“哪里出错了”。给 AI 明确角色、日志范围和输出格式，避免它把猜测写成事实。下面的 Python 示例通过 OpenAI SDK 调用兼容接口：

from openai import OpenAI
client = OpenAI(base_url="https://api.59api.com/v1", api_key="YOUR_API_KEY")
logs = open("incident.log", encoding="utf-8").read()
prompt = f"""你是资深 SRE。分析以下已脱敏日志。
输出：1. 证据最多的根因；2. 相关 trace_id；3. 时间线；4. 需验证的假设；5. 最小修复建议。
不要编造日志中没有的信息。日志：{logs}"""
result = client.chat.completions.create(model="gpt-4.1-mini", messages=[{"role":"user","content":prompt}])
print(result.choices[0].message.content)

当日志包含复杂堆栈、跨服务调用或需要更强推理时，可切换到 Claude Sonnet 或 Opus；当只需按字段聚类、归纳重复错误时，使用更快的 Haiku 或经济型 GPT 模型更合适。59API 提供按量付费的 Claude 与 GPT 原生质量模型，并兼容 Claude Code、Codex 和 OpenAI SDK，因此无需为不同排障脚本维护多套调用方式。

第三步：把 AI 结论变成验证动作

模型若指出“数据库连接池耗尽”，应要求它列出对应日志证据，例如连接等待时间上升、timeout 数量和首个异常时间。再用监控数据确认：检查数据库连接数、应用实例数、慢查询和发布记录。可继续追问：

基于现有日志，为“连接池耗尽”设计三个验证命令。每条命令说明预期结果、反证结果和下一步，不要建议直接重启服务。

这样能把自然语言分析落到可复现的操作上。修复后，用同一提示词分析新时间窗口，比较 5xx 比例、P95 延迟和异常关键词是否回落，并把确认过的根因、修复提交和预防告警写入事故复盘。

成本与安全实践

• 先用规则、SQL 或 rg 过滤日志，再调用模型，减少 token 消耗。
• 大型日志按 trace_id 或五分钟窗口分批摘要，最后让模型汇总摘要。
• 将 API 密钥放入环境变量或密钥管理服务，不要写进仓库。
• 把 AI 输出标记为“待验证”，涉及删库、扩容和重启的动作必须经人工审批。

对需要频繁排障、但又不希望预付高额模型成本的团队，59API 的低价按量计费和推荐返利能降低试用门槛。可以注册 59API，先用一段脱敏的历史事故日志验证提示词和模型选择，再接入日常排障流程。

Pricing · Docs