从 8 行报错到一条故障链：我用蓝耘 MaaS 做了一个 AI 日志分析助手

应用出现故障时，我们往往不是没有日志，而是日志太多了。

一次接口报错，前后可能同时出现数据库连接池等待、SQL 超时、网关 500、缓存重试。每一行都在说话，但它们说的不是同一种语言。人工排查要先筛出异常，再沿时间、请求 ID 和服务调用关系把碎片拼起来。

找到 ERROR 并不难。难的是回答：这些错误是不是同一条故障链？哪一个更接近起点？接下来应该先查连接池、慢 SQL，还是网关？更重要的是，每个判断能不能回到日志原文。

我想验证的不是"大模型会不会解释日志"，而是它能不能进入一条真正可用的排障流程。

于是有了这个本地 Web 工具：上传或粘贴日志，本地程序先预处理，再调用蓝耘 MaaS 的 qwen3.7-plus，把零散记录整理成可复核的异常清单。每条异常都带着原文证据、可能原因和下一步动作，最终还能查看、导出原始 JSON。

需要提前说明的是，本文使用的五份日志都是人工编写的虚构测试数据，不含真实账号、主机、客户信息或生产密钥。工具给出的"可能原因"也只是排查线索，不等同于已经确认的根因。

一、先确定工具的边界：AI 提供线索，不替人下结论

如果只是把日志直接交给模型并询问"哪里有问题"，得到的往往是一段自然语言。它可能读起来很完整，却很难回答三个关键问题：

1. 结论对应哪一行原始日志？
2. 哪些内容是日志事实，哪些只是模型推测？
3. 后续应该执行什么具体排查动作？

所以我把工具输出约束为五部分：

• 总体摘要与总体风险级别；
• 异常类型、所属服务和置信度；
• 必须逐字摘自输入日志的证据；
• 明确标为"推测"的可能原因；
• 下一步排查动作、重复模式和待补充信息。

当日志没有明显异常时，模型应返回空的异常数组，而不是为了让页面有内容而编造故障。输入过长时，程序也会在本地截断并追加标记，提醒模型和使用者当前结论只覆盖部分内容。

最终形成的处理链路如下：

上传 .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=https://maas-api.lanyun.net/v1
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

浏览器打开 http://127.0.0.1:5100 即可使用。

模型调用集中在一个函数里。蓝耘提供 OpenAI 兼容端点，实际请求由 SDK 发往 /chat/completions：

client = OpenAI(
    api_key=API_KEY,
    base_url="https://maas-api.lanyun.net/v1",
    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 接入和密钥管理放进同一个平台，让开发者可以把精力放回问题本身，而不是停在接口适配和一次性演示上。

日志排障不需要大模型替代工程师。只要能借助蓝耘，把分散的日志整理成有证据、有边界、可复核的排查线索，这套组合就已经找到了自己的位置。