结合ELK日志MCP的AI问题排查工作流：从页面报错到数据验证

前言

前后端融合的工程里，排查一个「页面保存失败」的问题要横跨好几层：前端控制台、网关、后端多个服务、中间件、数据库。以前的处理路径是：找前端看请求 → 找后端捞日志 → 对 traceId → 查库验证，几个人来回扯半天。现在把这些能力都接成 MCP 工具给 AI（ELK 日志查询 MCP + 数据库 CLI，数据库那篇见 agent-database-cli），一句话描述问题，AI 按固定工作流自己跑完全程。这篇整理这套工作流。

1、工具组成

工具	能力	在工作流里的角色
ELK 日志 MCP	`searchLog`（按应用名/时间窗/级别/关键词查日志）、`searchByTraceId`（按 traceId 拉全链路日志）、`getCurrentTime`（当前服务器时间）	发现与串联
数据库 CLI（agent-database-cli）	只读执行 SQL、查元信息	数据验证

日志 MCP 的三个工具各有分工：getCurrentTime 看着不起眼，其实是第一步——AI 自己猜的时间和服务器时间经常差着时区，时间窗错了后面全白查。

2、五步工作流

以一个真实场景走一遍：用户反馈「订单页面点保存，转圈之后报保存失败」。

第一步：时间对齐

1
2


调用 getCurrentTime，确认服务器当前时间。
问用户/前端拿到操作发生的大致时间，换算成服务器时间。

为什么要先做这步：日志平台的时间和应用服务器可能有几小时偏差（时区配置），不先对齐，按「刚刚」去查要么查到明天要么查到上周。

第二步：错误初筛

1
2
3
4
5


调用 searchLog：
  appName = 订单服务
  startTime/endTime = 操作时间 ± 5 分钟
  logLevel = ERROR
  keyword = 保存失败 或 订单号

关键词的选择有讲究：用业务单号、订单号这种精确值，别用「失败」「错误」这种泛词——泛词能把整个服务的噪音全捞回来。这一步的目标不是找根因，是找到那条带 traceId 的错误日志。

第三步：traceId 串联全链路（核心）

从错误日志里取出 traceId：

1
2


调用 searchByTraceId：
  traceId = 上一步拿到的 traceId

这一步是工作流的核心价值：一个 traceId 把网关 → 服务 A → 服务 B → DAO 层的所有日志按时间串起来。AI 拿到的是一条完整时间线：

1
2
3
4
5
6


14:32:01.123 [gateway]  POST /api/order/save  → 路由到 order-svc
14:32:01.130 [order-svc] 收到保存请求, orderId=xxx
14:32:01.201 [order-svc] 调用库存服务扣减...
14:32:01.355 [stock-svc] 库存不足, sku=xxx, need=5, left=0
14:32:01.360 [order-svc] 抛出 BusinessException: 库存不足
14:32:01.362 [gateway] 返回 500

根因往往就藏在这条时间线的中间某一行——库存不足、下游超时、SQL 报错，一眼可见。人肉排查时这步最费时间（要挨个系统翻日志），AI 三五秒串完。

第四步：查库验证数据

日志给出怀疑方向后，用数据库 CLI 验证数据状态（只读连接）：

1
2


调用 agent-database-cli：
  exec stock-db "select sku, stock, version from stock where sku='xxx'"

比如日志说库存不足，查库确认 stock 确实是 0；日志说唯一键冲突，查库看那条冲突数据是谁插的。日志定方向，数据定实锤——只看日志不下结论，是给 AI 定的规矩。

第五步：输出结论

要求 AI 按固定结构输出排查报告：

1
2
3
4
5
6
7


## 排查结论
- 现象：订单保存失败
- 根因：库存不足（stock-svc 返回 BusinessException）
- 证据链：
  1. traceId=xxx 时间线：14:32:01.355 库存服务返回库存不足
  2. DB 验证：sku=xxx 当前库存 0
- 建议：前端拦截库存为 0 的下单；后端将「库存不足」错误码透传给前端友好提示

3、给 AI 的提示词模板

把工作流固化成一段提示词，每次排查直接贴：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


你是资深全栈排查工程师，按以下流程排查我描述的问题，不要跳步：

1. 先调 getCurrentTime 对齐服务器时间，再结合我给的操作时间确定查询窗口
2. 用 searchLog 按应用名+ERROR+我给的业务单号初筛，找到 traceId
3. 用 searchByTraceId 拉全链路日志，整理成按时间排序的时间线
4. 从时间线里定位第一个报错点，说明是哪一层（前端参数/网关/服务/DB）
5. 如需验证数据，用 agent-database-cli 只读查询（先说 SQL 再执行）
6. 按「现象/根因/证据链/建议」四段输出结论，证据必须带具体时间和日志原文

问题描述：【这里填用户反馈】
涉及应用：【这里填服务名】
业务单号或 traceId：【这里填，没有就说没有】

用了几次之后可以把这段直接存成自定义 Skill，触发词「排查问题」自动加载， teammates 也能复用同一套标准。

4、实战技巧

时间窗先宽后窄：第一轮 ±5 分钟，找不到再放宽到 ±30 分钟，避免一上来查一小时把 token 烧光
traceId 是灵魂：推动团队在网关入口生成 traceId 并全链路透传（MDC 塞进每行日志），没有 traceId 的系统这套工作流效率折半。没有的话用业务单号 + 时间窗硬查也能兜住
级别分层次：先 ERROR 找报错点，ERROR 没有就降 WARN、INFO（有些问题被 catch 了没打 ERROR，但 INFO 里有业务流水）
让 AI 输出时间线：别让它直接给结论，强制要求先整理按时间排序的日志时间线——中间过程可见，错了能发现是哪步歪的
多轮追问：第一轮定位到「库存不足」，可以继续追问「这个 sku 最近的库存变更日志」，AI 会带着新时间窗再来一轮

5、安全边界

数据库连接保持只读（agent-database-cli 默认 readonly），AI 只查不改
日志里可能带手机号、地址等个人信息，AI 的排查结论里要求引用时做脱敏（尾号掩盖），排查报告不要直接外发
生产日志平台的 MCP 凭证按只读账号最小化授权，和 db-cli 一个原则：AI 负责查和推理，变更的扳机在人手里

总结

这套工作流的本质是把老师傅的排查路径固化成 AI 的执行流程：时间对齐 → 错误初筛 → traceId 串联 → 数据验证 → 结构化结论。ELK 日志 MCP 负责「看得见全过程」，数据库 CLI 负责「验得了实锤」，前后端融合工程里的大部分线上问题，从描述到根因只需要几分钟。

文章目录