系统出故障时，我们缺的往往不是日志，而是日志太多。
一次接口报错，前后可能同时冒出数据库连接池等待、SQL 超时、网关 500、缓存重试。每一行都在说话，可它们说的不是同一种语言。人工排查得先筛出异常，再顺着时间、请求 ID 和服务调用关系把碎片拼起来。
找出 ERROR 不难。难的是回答这几个问题：这些错误是不是同一条故障链？哪一个更接近起点？接下来该先查连接池、慢 SQL，还是网关？更关键的是，每个判断能不能回到日志原文。
我想验证的不是“大模型能不能解释日志”，而是它能不能被嵌进一条真正可用的排障流程。
于是有了这个本地 Web 工具：上传或粘贴日志，本地程序先做预处理，再调用蓝耘 MaaS 的 qwen3.7-plus，把零散记录整理成一份可复核的异常清单。每条异常都带着原文证据、可能原因和下一步动作，最后还能查看、导出原始 JSON。
先说明一下：本文用的五份日志都是人工编写的虚构测试数据，不含真实账号、主机、客户信息或生产密钥。工具给出的“可能原因”也只是排查线索，不等于已经确认的根因。
一、先确定工具的边界：AI 提供线索，不替人下结论
如果只是把日志丢给模型问一句“哪里有问题”，拿到的通常是一段自然语言。它读起来可能很完整，却很难回答三个关键问题：
- 结论对应哪一行原始日志？
- 哪些内容是日志事实，哪些只是模型推测？
- 后续应该执行什么具体排查动作？
所以我把工具的输出限定为五个部分：
- 总体摘要与总体风险级别；
- 异常类型、所属服务和置信度；
- 必须逐字摘自输入日志的证据；
- 明确标为“推测”的可能原因；
- 下一步排查动作、重复模式和待补充信息。
日志里没有明显异常时，模型应该返回空的异常数组，而不是为了让页面好看去编造故障。输入过长时，程序也会在本地截断并追加标记，提醒模型和使用者：当前结论只覆盖了一部分内容。
最终形成的处理链路如下：
上传 .log/.txt/.json 或粘贴日志
-> 本地读取并兼容常见编码
-> 保留行号，提取时间和日志级别
-> 控制送模文本长度
-> 调用蓝耘 MaaS
-> 校验结构化 JSON
-> 展示异常、证据、推测和排查动作
-> 查看或导出原始 JSON
程序首页做得很朴素，既可以选择日志文件，也可以直接粘贴内容。
二、模型只是能力，蓝耘 MaaS 负责把能力接进工具
做日志分析工具，模型只是链路里的一环。真正决定能否落地的，是另外几件看起来不够“智能”的事：模型好不好选、现有代码能不能低成本接入、密钥能不能独立管理、长日志的调用成本是否看得清。
这正是我引入蓝耘 MaaS 的原因。模型广场把不同提供方、模型类型、上下文长度和价格信息摊在同一个控制台里；选定模型后，又能通过统一的 API 方式嵌进应用。对已经在用 OpenAI Python SDK 的项目来说，业务代码不需要围绕专用 SDK 重写，只要配好 Base URL、API Key 和模型名，调用就能接进现有流程。
这次我选的是 qwen3.7-plus。它是 Qwen3.7 系列里性价比很高的 Plus 模型，具备视觉理解能力和 1024k 上下文。日志助手用到的是它的文本理解、归纳与结构化输出能力；视觉能力则为后续分析监控截图、告警截图这类图文输入留出了扩展空间。
控制台截图还给出了分段计费信息：输入 2 元/M tokens，输出 8 元/M tokens，缓存命中输入 0.4 元/M tokens。对日志分析这种输入可能很长的工具来说，选型阶段就能同时看到上下文和价格，便于一并权衡能力与成本。
API Key 可以在蓝耘控制台的“API KEY 管理”页面创建，控制台也会明确提醒妥善保存密钥，不要上传或公开分享。我的做法是只把 Key 写进本地 .env，代码里不出现任何真实值。
所以蓝耘在这里并不是一个被动应答的接口，而是连接“模型选型”和“应用开发”的中间层：前面能按能力、上下文和价格筛模型，后面能用熟悉的 SDK 接入，密钥则与业务代码隔离。模型广场里还有其他模型，也为后续做模型对比或按任务调整选型留了余地。不过本文只实测了 qwen3.7-plus，不据此评价其他模型。
三、把蓝耘接进来，业务代码不需要改头换面
项目用 Flask 提供本地 Web 页面，用 OpenAI Python SDK 调用蓝耘 MaaS。核心配置放在 .env 里：
BLUEYUN_API_KEY=你的蓝耘API密钥
BLUEYUN_BASE_URL=
BLUEYUN_MODEL=qwen3.7-plus
BLUEYUN_JSON_MODE=true
MAX_LOG_CHARS=30000
安装依赖并启动程序：
python -m venv .venv
.\.venv\Scripts\Activate.ps1
pip install -r requirements.txt
python app.py
浏览器打开 ` 即可使用。
模型调用被收拢在一个函数里。蓝耘提供的是 OpenAI 兼容端点，请求由 SDK 发往 /chat/completions：
client = OpenAI(
api_key=API_KEY,
base_url="
timeout=180.0,
)
response = client.chat.completions.create(
model="qwen3.7-plus",
messages=[
{"role": "system", "content": SYSTEM_PROMPT},
{"role": "user", "content": f"请分析以下日志：\n\n{log_text}"},
],
response_format={"type": "json_object"},
temperature=0.1,
max_tokens=4000,
)
提示词要求模型只依据给定日志做分析，证据必须逐字摘录，同时把结果固定成 summary、overall_level、anomalies、repeated_patterns 和 missing_context 等字段。
程序不会把模型吐出的任意文本直接当成“成功结果”展示。它会先解析 JSON，并检查 anomalies 是否为数组；调用失败、JSON 解析不了或字段不符合约定时，接口会明确报错。这一步让模型能力进入了受程序约束的工作流，而不是躲在页面后面的聊天框。
四、五组日志，分别追问五件事
我准备了五组用途不同的输入，分别追问：已知异常能不能串成故障链、正常日志会不会被误判、重复错误能不能归并、超长输入能不能暴露边界、跨服务事件能不能被拆开。
五组日志都通过蓝耘 MaaS 的 Qwen3.7-Plus 完成了真实调用。下表里的耗时来自页面运行结果，只代表本次样例、网络与运行环境，不构成性能基准。
| 样例 | 日志行数 | 调用耗时 | 主要验证点 | 实际结果 |
|---|---|---|---|---|
| 已知异常基线 | 8 | 34444 ms | 数据库、网关和缓存异常 | 输出 4 类异常，并保留原文证据 |
| 仅 INFO 日志 | 12 | 14725 ms | 是否会强行编造故障 | 未输出异常项，判断系统整体健康 |
| 重复错误日志 | 15 | 36450 ms | 能否归并重复事件 | 归纳为连接池耗尽、查询超时和 API 失败 |
| 超长日志 | 420 | 17953 ms | 长度边界与信息缺失提示 | 未发现已读取片段中的错误，并提示日志被截断 |
| 脱敏生产风格日志 | 17 | 42047 ms | 多服务事件链与结构化导出 | 识别认证、超时、熔断和订单失败事件 |
1. 已知异常：从八行日志还原故障链
第一组日志只有八行，却同时包含数据库连接池等待、两次数据库超时、两次 /orders 接口 500，以及一次 Redis 连接重试。
模型给出的总体级别为“高”，摘要指出数据库连接池耗尽导致 order.service 多次数据库超时，并引发 /orders 接口 500，同时观察到 Redis 重试。页面进一步拆出了四类异常：
- 数据库连接池耗尽；
- 数据库超时；
- 接口 500 错误；
- Redis 连接重试。
这里最要紧的不是异常叫什么，而是证据能回到原文。比如连接池问题引用了 pool wait exceeded threshold wait_ms=812 active=20 idle=0，接口错误引用了两个请求的 route=/orders status=500。可能原因前保留了“推测”字样，排查动作则落到连接池配置、慢查询、数据库负载、接口错误率和熔断降级等具体方向。
结果页下方还展示了重复模式、待补充信息和原始 JSON。模型指出数据库超时后紧跟 /orders 500，需要进一步补充数据库慢查询日志、连接池参数、Redis 后续状态和流量变化等信息。
2. 仅 INFO 日志：验证模型能否克制输出
第二组共有 12 行，全部为 INFO，覆盖网关、订单、支付、缓存、数据库连接池、指标上报和健康检查。各项状态均为成功或正常。
模型没有为了“完成分析”而生成异常卡片，而是给出低级别摘要：各服务运行正常，没有错误或异常指标，系统整体健康。页面耗时为 14725 ms。
这组测试很有必要。日志助手如果只会在错误样例里挑毛病，却把正常日志写成故障，那它在真实工作流里反而是在制造噪声。
3. 重复错误：把多行报错归并为事件模式
第三组日志模拟了连接池逐步被耗尽的过程：idle 降到 0，waiting 从 4 涨到 9；相同的 find_orders 查询连续超时，随后 /orders 多次返回 500；最后连接池恢复为 idle=8, waiting=0。
模型没有把每一行都拆成一个独立问题，而是归并为三类异常：数据库连接池耗尽、数据库查询超时和 API 请求失败。它还注意到了最后的恢复状态，并建议检查 find_orders SQL 执行计划与耗时、数据库慢查询、连接池最大连接数和该时段流量。
这样的结果更贴近真实排障需要。使用者看到的是一条“连接池等待、查询超时、网关失败”的关联链，而不是十几条彼此割裂的错误复述。
4. 超长输入：主动暴露分析边界
第四组日志共有 420 行，原始文件约 5 万字符。程序在预处理时加入行号、时间和级别标记，并按 MAX_LOG_CHARS=30000 控制送入模型的正文长度。
模型在已读取内容中没有发现错误：日志均为 INFO、状态码为 200、延迟稳定在 24 ms。与此同时，它在“待补充信息”中明确指出日志被截断，缺少后续是否存在错误日志的信息，也缺少其他服务或模块的日志来确认整体状态。
这正是我想保留的边界意识：面对被截断的局部日志，工具可以总结它看到的部分，但不能据此宣称全量日志都正常。
5. 脱敏生产风格日志：识别跨服务事件链
第五组是完全虚构且已脱敏的生产风格日志，共 17 行。它包含两条主要事件链：一条是同一测试用户连续三次签名校验失败后被临时封禁；另一条是库存服务先出现高延迟，随后两次超时，熔断器打开，订单创建失败并由网关返回 503，之后熔断器进入半开状态并恢复关闭。
模型输出了认证失败、服务超时、熔断触发和订单创建失败等异常，并分别保留了日志证据。以认证失败为例，证据包含三次 invalid_signature 和 temporary_block；排查动作包括检查客户端签名配置、确认测试用户凭证状态和监控该 IP 的后续行为。
对于库存链路，模型将高延迟和两次超时归入服务异常，同时把熔断器 state=OPEN 单独识别出来，并建议检查服务健康状态、资源使用、网络链路和依赖服务日志。这里仍需强调：诸如“负载过高”“网络延迟或丢包”只是待验证的可能原因，不能直接当成根因结论。
五、从页面结果到可继续处理的 JSON
页面展示是给人看的，JSON 则是给后续流程用的。工具保留了“查看原始 JSON”区域，并提供“导出 JSON”按钮。把第五组样例导出后可以看到，每条异常都包含 actions、confidence、evidence、level、possible_causes、service 和 type 等字段。
结构化结果意味着这份 Demo 后续可以继续扩展，例如把高风险项推送到告警系统、把排查动作写入工单、按服务聚合历史问题，或者加入人工确认状态。本文没有实现这些功能，但当前输出已经不再局限于一次性的聊天回答。
六、回头看，蓝耘的价值落在三个具体节点
跑完五组样例回头看，蓝耘的价值并不只发生在“发请求、收回答”的那几秒，而是落在三个具体节点上：选型、接入和运行。
- 选型时，模型广场把能力标签、上下文长度和价格放在同一个界面里；
- 接入时，OpenAI 兼容端点让现有 Python SDK 可以直接进入项目；
- 运行时，
qwen3.7-plus承担日志语义理解、异常归并和结构化输出。
与此同时，本地程序与模型服务的职责保持分开：
- 本地程序负责文件读取、编码兼容、日志编号、长度限制、JSON 校验、页面展示和结果导出；
- 蓝耘 MaaS 的
qwen3.7-plus负责理解日志语义、归并异常、摘取证据，并生成可能原因和排查动作。
这种分工很关键。蓝耘提供模型能力和稳定的接入方式，程序负责约束输入输出，人负责确认根因。三方各自守住边界，模型的语义理解才不会变成一段无法审计的长篇大论。
五组实测也从侧面验证了这套组合：异常日志能形成排查链，正常日志没有被强行制造故障，重复日志可以归并，超长日志会暴露信息不完整，复杂日志则能按服务和事件拆分。对于希望把大模型嵌入现有工具的开发者，蓝耘缩短的正是从“选到一个模型”到“让它进入业务流程”之间的距离。
结语
回到开头那 8 行日志。
它们原本只是连接池等待、数据库超时、网关 500 和 Redis 重试。经过本地预处理与蓝耘 MaaS 的分析之后，被整理成了一条可以继续推进的路径：异常是什么、证据在哪、哪些只是推测、下一步查什么、还缺哪些信息。
这次借助蓝耘 MaaS 的 qwen3.7-plus，我把这条路径做成了一个可实际运行的日志分析助手。它能从少量错误中整理故障链，对正常日志保持克制，也能输出便于查看和继续处理的结构化 JSON。
我对蓝耘 MaaS 的感受也落在这里：它把模型能力、上下文与价格信息、API 接入和密钥管理放进同一个平台，让开发者可以把精力放回问题本身，而不是停在接口适配和一次性演示上。
日志排障不需要大模型替代工程师。只要能借助蓝耘，把分散的日志整理成有证据、有边界、可复核的排查线索，这套组合就已经找到了自己的位置。
评论0