大数据智能运维实战（十）：把查询工具串起来，完成一次任务变慢诊断

系列：Spring AI + MCP——大数据智能运维实战
本篇目标：用“确认对象—获取状态—比较指标—查日志—形成结论”的流程完成一次诊断，区分事实、假设和待验证项。
阅读基础：第七至九篇；沿用 lab-07-12 和同一组虚构快照。
案例说明：本篇是固定流程调用真实教学工具的演示，不连接生产数据，也不把规则脚本结果宣称为模型实测回答。

1. 工具都能用了，为什么回答还是可能不靠谱

“现在能查运行、查引擎、查指标、查日志，是不是让模型自己发挥就行？”小周问。

小林把刚才的查询记录排了一下：先查了节点 C 的 CPU，又查到另一次手工重跑的日志，最后拿当前运行的状态做结论。

每个工具都成功了，但它们说的不是同一件事。

诊断不是把几份 JSON 放到一起。它需要把对象、时间和证据来源保持一致，还要决定：什么情况下继续查，什么情况下应该停下来说明缺口。

本篇回到一个具体问题：

门店经营日报这次为什么还没完成？请看 run-current-0917。

用户给出了准确运行标识。为了展示完整入口，实验仍会查询同日运行列表，再检查指定标识确实在返回候选中。它不会按“最新一条”替用户选对象。

2. 先确定五步流程，再给每一步一个出口

本篇流程如下：

图 1：每一步都可能返回缺失或失败；后续查询只能使用已经确认的对象和权限。

每一步都要有停止条件。例如候选不唯一而用户没有指定运行，先列出差异等待选择；引擎关联冲突，就暂停针对某个应用下结论；工具超时，则记录缺口，不能把超时当成空结果继续证明“没有异常”。

为了让调用过程容易检查，本实验使用固定编排脚本 scripts/diagnose.py。模型可以以后接入同一套工具，但当前演示不需要模型密钥。

3. 第一步先锁定本次尝试，时间窗口随后再定

查询运行时间线后得到：

runId：run-current-0917
attemptId：a1
执行节点：demo-worker-b
入队：09:00
执行器启动：09:05
观察时刻：09:40
状态：RUNNING

因此，可以确定的时间口径是：

入队后经过：40 分钟
首次启动前等待：5 分钟
执行器启动后经过：35 分钟

本次没有结束时间，不能把观察时刻当作任务结束时间。35 分钟也不等于实际计算时间。

接下来指标和日志窗口统一设为 [09:05, 09:40)，+08:00。节点由运行尝试解析，客户端不另外猜一台“看起来可能有关”的机器。

用户说任务“慢”，但这组样本没有提供历史正常运行耗时、输入数据量或业务 SLA。我们能诊断“为什么截至当前仍未完成”，还不能量化“比正常慢了多少倍”。如果需要这个比较，必须补充可比基线。

这一步看起来很普通，却能避免后面一整段错误归因。

4. 第二步追引擎，第三步用趋势检验一个具体假设

ops_trace_engine 用本次 runId + attemptId 找到了模拟提交回执。引擎在 09:39 上报：

应用：demo-app-20
状态：QUEUED
队列：demo-batch
运行名额：8 / 8
原因：QUEUE_RUNNING_LIMIT

这让“计算队列准入受限”成为当前有直接记录支持的排查方向。

小周又提出一个假设：“是不是执行节点 CPU 打满，提交和轮询都卡了？”

我们用 ops_run_metrics 检查同一尝试对应的节点 B。窗口内每 5 分钟一个样本：

工具计算得到：样本均值 21%，已观测峰值 24%，最新样本是 09:35 的 18%，返回点数 7/7。

这组样本没有显示持续 CPU 高负载，因此不支持直接把执行节点 CPU 饱和作为结论。但它也没有证明所有资源都正常：5 分钟间隔可能漏掉短时峰值，CPU 之外还有内存、I/O、网络和执行槽位等维度。

第八篇里的引擎应用与本次执行器节点，也不一定代表同一组计算资源。不能用提交节点 B 的低 CPU，证明整个计算集群空闲。

这里的“比较指标”首先是比较同一窗口内的样本与具体假设。没有历史基线，就不编造“正常时平均只要 10 分钟”之类的数据。

5. 第四步读日志，把超时放回上下文

日志按第九篇的方式分三页读取，每页 3 条，共得到 8 条可用记录。

它们补充了几件事：

• L02、L03 记录提交及关联标识，能和引擎回执相互核对。
• L04、L07 记录应用仍在排队；它们是离散观测，不能填满中间每一秒。
• L05 记录轮询响应超时，但后续仍有状态记录，不能直接判定执行失败。
• L08 在 09:39 记录队列名额和限制原因，与引擎快照一致。

同时，日志存在 09:12—09:15 的采集缺口，L07 被截断。L06 的外部指令文本只作为日志内容保留，不改变查询流程。

“日志和引擎快照说法一致，是不是就能百分之百确认根因？”小周问。

还不行。两份记录可能来自同一底层状态源，不能仅因为出现了两次就当成两份独立证明。它们支持的是相同观测点上的一致解释；要解释整个等待区间，还需要准入、资源释放和阶段变化事件。

6. 最终报告分三层，读者才知道该相信到什么程度

图 2：事实附带来源，假设说明支持程度，待验证项指向具体缺口。

根据当前工具结果，可以形成如下预期报告：

已确认事实

run-current-0917/a1 从 09:05 开始由节点 B 处理，截至教学观察时刻 09:40 尚未结束。入队后经过 40 分钟，其中执行器启动后经过 35 分钟。依据：run-current-0917/timeline。

模拟回执将本次尝试关联到 demo-app-20。引擎在 09:39 上报 QUEUED，队列运行名额为 8/8，原因是 QUEUE_RUNNING_LIMIT。依据：run-current-0917/receipt-1、run-current-0917/engine-0939。

节点 B 在 [09:05, 09:40) 的 7 个 CPU 样本均值为 21%，已观测峰值为 24%。日志可用记录已翻完，但存在采集缺口和单条截断。依据：run-current-0917/metrics 与日志 L05、L07、L08。

原因假设与当前判断

当前最有依据的排查方向是引擎队列准入限制。现有 CPU 样本不支持“提交节点持续 CPU 饱和”的说法；但不能排除其他资源问题，也不能确认整个等待时段均由同一限制导致。

待验证项

补齐等待期间的准入与释放事件，确认限制持续的范围；核对采集缺口；如需继续判断其他资源瓶颈，再查对应计算资源的内存、I/O 和阶段信息。需要衡量“比平时慢多少”时，另取同口径历史基线。

这样的结论已经能帮助值班同学选择下一步，而不必硬写一个缺乏证据的最终根因。

7. 给查询设置预算，也给报告设置停下来的理由

固定流程的主路径共调用 7 次工具：候选查询、时间线、引擎关联、指标各 1 次，日志 3 次。

脚本设置最多 8 次工具调用、最多 3 页日志。任何一次工具返回错误就停止并保留错误，而不是无限重试。日志达到页数预算仍有 hasMore=true 时，报告必须说明尚未读完。

这 7 次只是本例的实际流程数量，不是任务复杂度指标，也不是模型使用成本。若接入模型，还应分别记录模型请求数、输入输出 token、端到端耗时和工具等待时间。

配套脚本的调用约束可以理解为下面这段伪代码，完整可执行版本见工程：

# 流程示意；每次 call 都检查预算与 isError。
核对用户指定的运行(查询候选())
本次尝试 = 查询时间线(运行标识)
引擎关联 = 查询引擎(运行标识, 本次尝试)
指标 = 查询指标(运行标识, 本次尝试, 时间窗口)
日志 = 限制页数地续查日志(运行标识, 本次尝试, 时间窗口)
报告 = 按事实、假设、待验证项组织(全部工具结果)

在本机服务已启动且令牌已设置时执行：

python3 scripts/diagnose.py run-current-0917

自动验收脚本也会调用这条流程，并保存结果。它验证的是工具链与确定性编排，没有证明某个模型一定会主动选对工具或正确理解日志。这一层需要第十二篇的模型验收用例继续检查。

8. 换一个反例，看流程会不会机械套答案

另一个独立样本 run-resource-0917 使用节点 C。

它的 7 个 CPU 样本是 93%、95%、97%、96%、94%、93%、92%，已观测峰值 97%；引擎状态是 RUNNING，日志记录了模拟阶段的 spill 现象。

这时不能照抄主样本的“当前正在等待队列准入”。应该把持续高 CPU 样本和引擎阶段现象作为新的调查方向，继续核对资源与数据量等信息。spill 本身也不能直接证明 CPU 是根因。

一套诊断流程是否有用，不仅看它能不能把主案例讲顺，还要看换成相反证据后，它会不会改变判断。

下一篇把查询背后的工程边界补齐：谁能查、一次能查多少、超时怎么报、审计记什么。否则，流程写得再清楚，也可能被一次无限制查询拖垮。