系列：Spring AI + MCP------大数据智能运维实战
本篇目标：从一次任务延迟出发，梳理运维助手需要哪些数据，以及 Spring AI、MCP 和已有平台分别负责什么。
阅读基础：了解 Spring Boot，知道接口和数据库查询的基本概念即可。
案例说明：本系列中的人物、平台、节点、任务和数据均为虚构教学设定，示例独立设计，不对应任何真实生产系统。
1. 小周又来找小林了，这次不是查数
上一个系列里，小林给小周做了一个查数助手。
小周输入一句"帮我看看每天的订单金额"，助手就能寻找数据、调用查询工具，再把结果解释清楚。
这天上午，小周又发来一条消息：
"今天的门店经营日报怎么还没更新？平时这个点早就有了。"
小林打开调度页面，发现任务还在运行。
他又打开监控页面，看了看机器的 CPU 和内存，再翻出任务日志，准备找找有没有报错。
几分钟过去，浏览器已经打开了好几个标签页，小周又补了一句：
"是不是机器不够用了？"
小林没有马上回答。
任务还在运行，可能是启动得晚，也可能是执行得慢；机器当前比较忙，也不能直接说明一小时前就在忙。光看一个状态、一个数字，很难把事情讲清楚。
他想起了之前做查数助手的过程：
既然程序已经能查询这些信息，能不能让助手把它们按排查顺序组织起来？
这个系列，就从这里开始。
我们要做一个运维助手，让它利用已有的节点信息、监控指标、调度记录和日志，帮助值班同学回答三个问题：
- 现在发生了什么？
- 哪些数据支持这个判断？
- 接下来应该查哪里？
2. 先别急着接模型，把"慢"拆开看看
为了让后面的讨论有共同背景，我们先约定一个虚构环境：青禾数据平台。
平台每天早上运行一次"门店经营日报"任务，汇总前一天的经营数据。
这次排查固定在 2026 年 9 月 16 日 09:10。全文时间均按北京时间理解，不随着读者打开文章的时间变化。
教学记录如下：
| 项目 | 虚构记录 |
|---|---|
| 任务名称 | 门店经营日报 |
| 本次处理的业务日期 | 2026-09-15 |
| 计划启动时间 | 2026-09-16 08:00 |
| 进入调度等待队列 | 2026-09-16 08:00 |
| 调度侧实际启动时间 | 2026-09-16 08:35 |
| 查询时刻 | 2026-09-16 09:10 |
| 查询时刻的状态 | 运行中 |
| 调度执行节点 | demo-worker-b |
| 前 7 次成功运行的执行耗时中位数 | 30 分钟 |
小周说"一个多小时还没完成"，这句话没有问题。
但如果助手直接回答"任务已经执行了 70 分钟"，就把两段时间混在一起了。
我们手动算一下：
图 1：从计划启动到查询时刻经过了 70 分钟，需要按调度阶段拆开理解。
这里至少有两个问题：
第一，为什么启动前等了 35 分钟？
第二，启动后已经过去 35 分钟，任务执行过程有没有异常？
它们需要不同的证据。前一个问题主要看调度队列和资源分配，后一个问题还要看计算引擎状态、指标趋势和执行日志。
而且，这里的"启动"按调度平台记录划分。进入执行阶段后，是否还在计算引擎里等待资源，需要继续查询，不能把这 35 分钟都理解为实际计算时间。
历史执行耗时的中位数是 30 分钟，也只是一个比较基准。今天启动后经过 35 分钟，尚不足以单独证明发生了严重性能问题。
做运维助手的第一步，是把问题和时间口径讲清楚。后面的查询、计算和解释，都要沿着这个口径走。
3. 我们需要的数据，大部分已经在那里
小林整理了一下，发现自己刚才打开的几个页面，其实分别回答不同的问题。
| 已有信息 | 能帮助回答什么 | 使用时还要注意什么 |
|---|---|---|
| 节点与组件信息 | 有哪些机器，部署了什么，最近上报什么状态 | 当前登记状态能否代表查询时刻 |
| 监控指标 | CPU、内存、磁盘等在某个时间段如何变化 | 单位、采样时间、聚合方式 |
| 调度队列 | 任务在等待还是运行，什么时候进入队列 | 调度等待与引擎内部等待要区分 |
| 任务运行记录 | 哪次运行、在哪台节点、是否失败或重试 | 同一个任务可能有多次运行和执行尝试 |
| 执行日志 | 出现过哪些错误，前后发生了什么 | 日志是否完整，是否属于本次执行 |
这些数据不必全部放在同一个地方。
节点信息可能来自管理平台，指标可能存放在监控系统，运行记录由调度系统保存，日志通过已有的日志服务查询。
本系列的前提是：这些信息已经被采集或记录，我们在已有查询能力之上组织工具。
教学环境里，我们会用本地模拟数据代替这些来源。这样读者不用先搭一整套大数据集群，也能练习完整的查询和排查过程。
不过，"已经上报"还需要再多问一句：什么时候上报的？
假设查询时刻是 09:10，节点信息如下：
| 节点 | 最近一次 CPU 使用率 | 对应采样时间 |
|---|---|---|
demo-worker-a |
34% | 09:09 |
demo-worker-b |
88% | 09:09 |
demo-worker-c |
17% | 08:20 |
看到第三行，助手不能直接说：
"节点 C 很空闲，可以把任务分过去。"
这个 17% 已经是 50 分钟前的记录了。
同样，节点 B 在 09:09 的 CPU 使用率是 88%，也不能证明它在 08:00 到 08:35 之间一直繁忙，更不能直接解释任务为什么排队。
数据除了数值，还需要带上时间。否则，助手很容易把"以前看到的情况"说成"现在正在发生的情况"。
4. Spring AI、MCP 和模型，各自负责哪一段
小周听到这里，问了一个很直接的问题：
"所以，装上 MCP，就能查出为什么慢了？"
还需要把几个角色接起来。
MCP 的全称是 Model Context Protocol 。在这个系列里，我们主要使用它的工具能力：让应用能够按统一协议发现工具、了解参数并发起调用。MCP 还支持其他能力，本篇先聚焦查询工具。MCP 官方架构说明
可以沿用之前查数系列的"点菜单"类比。
工具服务提供一张菜单，写清楚：
- 可以查询什么。
- 调用时要提供哪些条件。
- 返回的结果表示什么。
例如，"查看某次任务运行记录"这个工具，需要一个明确的运行标识；"查看节点指标趋势"需要节点和时间范围。
模型根据问题和工具说明提出调用请求，应用负责组织调用，服务端检查参数和权限后执行查询。
各个角色的分工如下：
| 角色 | 本系列里的职责 |
|---|---|
| 用户 | 提出问题，必要时补充任务、日期等条件 |
| 模型 | 理解问题、提出工具调用、根据结果组织解释 |
| 助手应用 | 管理对话和调用流程，把工具结果交回模型 |
| MCP 客户端 | 在助手应用中与工具服务通信 |
| MCP 服务端 | 提供查询工具，执行校验并返回数据 |
| 已有平台或教学数据源 | 提供节点、指标、任务和日志等记录 |
Spring AI 则帮助我们在 Java 应用里接入模型、组织工具调用，并集成 MCP 客户端和服务端能力。后续我们会使用它把这些角色连接起来。Spring AI MCP 说明
熟悉 Spring Boot 的读者，可以先把业务代码理解为：
接收参数，检查条件，调用查询服务，返回结构清楚的结果。
你仍然需要写好这些代码。模型不会替我们决定某个字段的业务含义，也不会自动把不完整的数据补成事实。
5. 先把一条完整线路画出来
小林在纸上画了这样一张图：
图 2：助手应用组织排查，MCP 工具服务执行查询，结果返回后再交给模型解释。
模型通过助手应用参与分析；真正访问数据的，是我们编写并授权的查询程序。
第一版可以先准备几类职责清楚的工具：
| 工具能力 | 输入条件示例 | 返回内容示例 |
|---|---|---|
| 查找任务 | 任务名称关键词 | 候选任务及其标识 |
| 查看某次运行 | 任务标识、运行日期 | 状态、时间、执行节点 |
| 查看节点趋势 | 节点、开始时间、结束时间 | 指标值及对应时间 |
| 查看执行日志 | 本次执行标识、查询范围 | 日志片段、完整性说明 |
这里展示的是教学设计，具体名称和参数会在后续代码中逐步确定。
小林特别加了一条约定：
标识从查询结果里拿，不让模型凭空猜。
用户说"门店日报"，系统里可能存在多个相近任务。助手应先查询候选项；如果仍然无法确定，就请用户补充。
同样，查到了某个任务，也要继续确定是哪一天、哪一次运行。不能拿昨天失败的日志解释今天的任务。
至于时间差、耗时等能够确定计算的内容，我们会尽量让程序算好，再交给模型解释。这样更容易检查结果，也便于后面做测试。
6. 查到结果以后，助手还要守住三条边界
工具能调用成功，只说明查询线路通了。
接下来，小林还得防止助手把结果解释错。
第一条：查不到数据，要说明查不到
如果某个时间段没有指标记录，助手应该说明：
"这个时间段缺少监控数据，暂时无法判断资源变化。"
不能自动把缺失值补成零，再得出"机器一直很空闲"。
日志也是一样。只返回了部分内容，就应该注明范围和完整性，不能声称已经检查过全部日志。
第二条：把事实和原因假设分开
在我们的虚构案例里，任务启动前等待了 35 分钟，这是调度记录能够支持的事实。
"可能是可用执行资源不足"，属于需要继续验证的原因假设。
要验证这个假设，可能还需要查询当时的队列情况、资源分配记录，以及符合任务执行条件的节点状态。
看到一个 CPU 数字，或者找到一条带有 ERROR 的日志，都只是增加了一条线索。它是否能解释当前问题，还要检查时间、对象和上下文是否一致。
第三条：查询范围要由程序控制
用户问某次任务，工具就围绕这次运行查询；需要查看指标，再限定节点和时间窗口。
这些约束应该落实在服务端，例如检查必要参数、限制返回数量、控制查询时间范围。
只在提示词里写"请不要查询太多"，不足以代替程序校验。
本系列第一阶段只提供查询和诊断建议。重启服务、终止任务、修改资源配置等操作，需要另外设计操作权限和执行流程，不属于这一阶段的交付范围。
7. 我们希望它最后怎样回答
现在可以回到小周最初的问题：
"今天的门店经营日报为什么一个多小时还没完成？"
图 3：已确认事实、待验证假设和下一步查询，需要分别说明。
下面是依据前文虚构数据编写的回答样稿，用于说明预期效果，尚未接入模型运行。
截至 2026 年 9 月 16 日 09:10，这次任务仍在运行。启动前的调度等待占用了 35 分钟；具体等待原因还需要继续查询。
已确认的情况：
- 本次任务处理的业务日期为 2026-09-15。
- 08:00 进入调度等待队列，08:35 实际启动，等待了 35 分钟。
- 从实际启动到查询时刻，经过了 35 分钟。
- 前 7 次成功运行的执行耗时中位数为 30 分钟。当前运行尚未结束，最终耗时还不确定。
- 调度执行节点
demo-worker-b在 09:09 上报的 CPU 使用率为 88%。
目前不能确认：
- 08:00---08:35 的等待是否由执行资源不足导致。
- 节点在启动前的等待期间是否持续繁忙。
- 进入执行阶段后，是否仍存在计算引擎内部排队或其他阻塞。
建议继续查询：
- 08:00---08:35 的调度队列及资源分配记录。
- 对应时间段内相关执行节点的资源趋势。
- 本次运行关联的计算引擎状态和执行日志。
以上判断来自教学任务记录与节点样本；历史队列、资源趋势和日志尚未查询。
小周看完，至少能明白一件事：
"这 70 分钟里，有 35 分钟是在启动前等待，不能全部算成任务执行慢。"
而小林也能直接沿着建议继续排查。
一个有用的回答，需要让人看得出哪些事情已经确认、哪些还不确定，以及下一步查什么。
8. 开始之前，三个常见问题
"是不是要先训练一个懂 Hadoop 的模型？"
这个系列不要求先训练模型。
我们先通过工具把明确的问题和相关数据交给模型，再检查它能否正确选择工具、理解结果、表达不确定性。
第一阶段更值得花时间的地方，是整理数据口径、工具说明和可复现案例。
"现有平台已经有监控页面，为什么还要做助手？"
页面仍然很有用，尤其适合查看曲线和细节。
助手的目标，是帮用户找到相关信息、组织查询顺序，并把分散在不同地方的结果解释清楚。
比如，小周只知道"日报没更新"，并不知道应该先看哪条任务、哪个队列和哪台节点。这个从问题到查询条件的过程，就是我们希望助手协助完成的部分。
"可以把所有监控数据和日志一次性发给模型吗？"
本系列会按问题逐步查询。
先确定任务和运行实例，再寻找相关节点、时间窗口和日志。这样既能控制查询量，也更容易核对每一步结论来自哪里。
如果第一步已经发现任务根本没有启动，后续排查重点就应放在启动前的环节，而不是马上搜索所有执行日志。
9. 小林先准备了一份"故障样本"
思路理顺以后，小林没有急着把所有大数据组件都接进来。
他先列了一份教学数据清单：
- 一个虚构集群和三台节点。
- 一项每日运行的统计任务。
- 几次历史成功运行记录。
- 一次启动前等待较久的运行记录。
- 对应的指标样本和日志片段。
- 一组故意缺失或过期的数据。
为什么还要准备缺失数据？
因为我们既要检查助手能否读懂已有记录，也要检查它在证据不足时，能否停在合理的位置。
后续文章会沿着这套环境往前走：先让工具返回节点和任务信息，再加入健康状态、指标趋势、调度排查和日志查询，最后串成一次完整诊断。
小周看了看这份清单，问：
"所以，下一步是先把这次'日报迟到'准备出来？"
小林点点头：
"对。先把场景和预期结果固定下来，后面每增加一项能力，我们都能检查它到底有没有查对。"
下一篇，我们就来准备这个本地实验环境。即使手边没有真实集群，也能跟着创建数据，手动还原这次任务延迟，为后续的 MCP 工具提供可验证的输入。
下一篇：《大数据智能运维实战（二）：准备一个可复现的运维实验环境》