AI 时代下，你的数据质量及格了吗？

AI 排障答不上来，很多人先怪 Prompt、再怪模型。更常见的原因其实在上游：监控交给 AI 的数据不合格——接口、SQL、入口、链路跳数对不上，模型再强也只能让你「自己去翻调用链」。这和 RAG、AI 客服是同一条铁律：数据不过关，上层再花哨也白搭。

怎么判断「及格」？本文按三步走：先定四句话及格线 → 用同一把尺子对照 DataBuff、SkyWalking、Jaeger、Pinpoint、SigNoz、OpenObserve → 再看 DataBuff 怎样用 12 张 metric_service_* 固定表，解决这个及格线。

一、一个你很可能遇过的场景

线上 checkout 变慢，你在 APM 里接了 AI，问了一句：

「checkout 为什么慢？慢在哪条 SQL？」

不及格

「请打开调用链详情，手动找根节点，再关联数据库 Span……」

AI 变成了高级搜索框，跟你没接 AI 差不多。

及格

「慢在 SELECT … FROM orders，由 /checkout 触发；payment 那一跳延迟最高。」

不用翻原始调用链，直接给结论。

AI 时代拼的是数据质量。Prompt 人人会抄，整理好的指标表抄不走。不及格的数据集，换再强的模型也只是让你「自己去翻」。

打个比方：原始监控像没目录的录像；高质量数据集像列名固定的 Excel——哪个接口、哪条 SQL、谁触发的，AI 拿来就能答。

二、及格线：AI 排障至少要答四句话

不用记字段名。拿下面四句话考你现在的 APM（接没接 AI 都一样）——能不能直接答，就是及格线；下一节用同一把尺子对照六家产品面。

哪个接口有问题？ HTTP、DB、MQ 不能混在一堆 Span 名里。Redis GET 和 checkout POST 必须分开统计。
哪条 SQL / 哪个库慢？ 不能只有「MySQL 平均 50ms」，得能点到具体语句。
慢 SQL 是哪个页面触发的？ 最关键的一问。很多栈答不了，只能让你回监控里人肉找入口。
调用链哪一跳拖后腿？ order → payment → MySQL，每一跳各多少流量、多少错误，不能只有一张拓扑缩略图。

及格 = 四句话都能直接答。有一题要让你「自己去翻调用链」，数据集就不及格。

三、应用性能对照：六家差在哪

及格线有了，落到产品面看一眼。下表是同环境实测的应用性能对照——基础项（拓扑 / 服务列表 / Trace）多家都有；真正拉开差距的是高亮行：调用分析、服务流、中间件专页。

✅ 可验证 △ 有入口 / 深度有限 ❌ 无等价能力

实测版本：DataBuff v0.1.4 · SkyWalking 10.4.0 · Jaeger 1.76 · Pinpoint 3.1.0 · SigNoz 0.133 · OpenObserve 0.91-rc1。

能力项	DataBuff	SkyWalking	Jaeger	Pinpoint	SigNoz	OpenObserve
1. 全局拓扑	✅	✅	△	✅	✅	❌
2. 服务列表 / 黄金指标	✅	✅	❌	✅	✅	✅
3. 服务级拓扑	✅	✅	△	✅	△	❌
4. 服务级调用分析上下游的 Metric 分析 + Trace 关联	✅	❌	❌	❌	❌	❌
5. 实例级黄金指标	✅	✅	❌	△	❌	❌
6. 实例级拓扑	✅	❌	❌	❌	❌	❌
7. 实例级调用分析	✅	❌	❌	❌	❌	❌
8. 接口级拓扑	✅	❌	❌	❌	❌	❌
9. 接口级调用分析接口级上下游的 Metric 分析 + Trace 关联	✅	❌	❌	△	❌	❌
10. 服务流Trace 级别的 Metric 分析	✅	❌	❌	❌	❌	❌
11. 中间件专页库/缓存/MQ · ≈②③	✅	❌	❌	△	❌	❌
12. 错误分析	✅	❌	❌	△	❌	△
13. Trace 列表 / 搜索	✅	✅	✅	✅	✅	✅
14. Trace 详情	✅	✅	✅	✅	✅	✅
15. Span 关联日志	✅	✅	△	❌	✅	✅
16. 日志列表 / 搜索	✅	✅	❌	❌	✅	✅
17. 日志详情	✅	✅	❌	❌	✅	✅
18. 日志关联 Trace	✅	✅	❌	❌	✅	✅

读表结论

1. Trace 搜索六家都能做，差距在高亮行：调用分析、服务流、中间件专页。

2. 人盯 UI，SkyWalking / Pinpoint 往往够用；要 AI 直接答四句话，靠的是这些纵深。

3. 高亮绿格不是多几个菜单，而是故障因果链的基石：哪个接口、哪条 SQL、谁触发、哪一跳拖后腿，能直接串成因果。

四、怎么准备及格的数据集？

第三节高亮能力（调用分析、服务流、中间件专页）不是事后拼页面，而是调用链进来时就按类型写进固定表。DataBuff 把这件事落成 12 张 metric_service_* 表——先认全这 12 张，再谈怎么查。

调用链（Span）进来
↓ 按类型分表：HTTP / DB / Redis / MQ / RPC…各一张，不混在 Span 名里
↓ 关键列写死：入口 API、SQL 摘要、路径 hop 等与指标同行
↓ 查表即可串因果；产品面自然长出专页 / 服务流 / 调用分析

12 张表一览（名字固定，AI / Text-to-SQL 不用猜 schema）：

#	表名	存什么	主要答什么
1	`metric_service`	服务入口 RED	这个服务稳不稳（QPS / 错误率 / 延迟）
2	`metric_service_trace`	整条 Trace 根节点	端到端一单的成败与耗时
3	`metric_service_http`	HTTP 接口分型	哪个 URL / 方法 / 状态码有问题
4	`metric_service_db`	数据库调用	哪条 SQL 慢、哪个库、谁触发（入口同行）
5	`metric_service_flow`	入口路径树	从入口展开，哪一跳拖后腿
6	`metric_service_rpc`	RPC 调用	gRPC / Dubbo 方法、状态码
7	`metric_service_redis`	缓存调用	GET/SET 等命令谁在打、是否慢
8	`metric_service_mq`	消息队列	topic 生产/消费、积压与延迟
9	`metric_service_remote`	外部依赖	外部 API 的 QPS / 延迟
10	`metric_service_exception`	入口异常	异常名 / 异常码（仅入口报错）
11	`metric_service_config`	配置中心读取	Nacos / ZK 等读取是否慢
12	`metric_service_instance`	实例元数据	Pod / 主机 / Java 版本（JOIN 用）

可粗分成三组：入口与整单（1–2）· 按组件分型（3–4、6–11，对应中间件专页）· 路径与实例（5 服务流、12 实例）。答四句话，主用 1 / 3 / 4 / 5；其余答题时再用。

读表前认三个词

tag: 筛选用的列（如 url、sqlContent、rootResource）——WHERE / GROUP BY。
field: 数字列（如 cnt、sumDuration）——算 QPS、错误率、平均延迟。
虚拟服务: 如 [mysql]demo_apm：把库 / 缓存当成拓扑上的独立节点，而不是埋在 Web 服务名里。

DataBuff 全局拓扑 — 图：HTTP / DB / MQ / 缓存分型进拓扑——来自上表各组件表，不是 Span 名一把梭

五、四句话 → 查哪张表

先看总表，再按「预热 → 第 1～4 题」展开。每张只列答题用到的 tag。

问题	主查表	关键 tag
服务整体稳不稳？（预热）	`metric_service`	`service`、`errorType`
1. 哪个接口有问题？	`metric_service_http`	`url`、`httpMethod`、`httpCode`
2. 哪条 SQL 慢？	`metric_service_db`	`sqlContent`、`isSlow`
3. 慢 SQL 谁触发？	`metric_service_db`	`rootResource`（与 sqlContent 同行）
4. 哪一跳拖后腿？	`metric_service_flow`	`entryInterfacePathId`、`pathId`、`parentService`

① metric_service — 服务稳不稳（预热）

答：「service-a 今天 QPS、错误率、平均耗时？」

何时写一行？ 只有入口请求（用户打进来的那一次），过滤掉 DB / Redis / MQ 等组件 Span。

关键 tag

`service`	服务名，服务列表 KPI 主键
`errorType`	ok / error 分行存，算错误率时不混维度
`serviceInstance`	哪台 Pod / 实例拖后腿

常用 field：cnt→QPS；error÷cnt→错误率；sumDuration÷cnt→平均耗时。

服务列表 RED 指标 — 图：服务列表 — `metric_service` 的产品面（QPS / 错误率 / 耗时）

② metric_service_http — 第 1 题：哪个接口慢

答：「哪个 URL 最慢？GET 还是 POST？4xx 还是 5xx？」

关键 tag

`url`	规范化 HTTP 路径，接口 TOP 慢榜
`httpMethod` / `httpCode`	方法、状态码分开统计
`rootResource`	出站调用也能挂回「谁发起的」
`durationRange`	延迟分桶，GROUP BY 即分布图

接口分析 HTTP 分型 — 图：接口分析 · HTTP — `/demo/checkout` 等 URL 独立成行（`metric_service_http`）

③ metric_service_db — 第 2、3 题：慢 SQL + 谁触发

答：「哪条 SQL 慢？是哪个入口触发的？」——两问查同一张表、同一行

关键 tag

`sqlContent`	语句摘要，SQL 级 TOP
`isSlow`	1 = 慢 SQL 行
`rootResource`	入口 API，与 sqlContent 同行 → 不必回 Trace 找谁触发
`sqlDatabase` / `dbType`	哪个库、哪种引擎

库在拓扑上是虚拟服务（如 [mysql]demo_apm），专页列表来自本表聚合；sqlContent + rootResource 同行是及格线最关键的设计。

数据库列表 — 图：数据库专页 — `[mysql]demo_apm` / ES 作为虚拟服务独立统计（`metric_service_db`）

④ metric_service_flow — 第 4 题：哪一跳拖后腿

答：「从 service-a 进来，每一跳各贡献多少响应？」

注意：一条 Trace 收齐后整棵树算一次，不是来一个 Span 就写一跳。

service-a（入口，240ms）
  → service-b（响应贡献度 58%）
    → [mysql]demo_apm
  → [elasticsearch] / [mysql]demo_apm …

关键 tag

`entryInterfacePathId`	从哪个入口进来的指纹
`pathId`	当前 hop 在路径树中的位置
`parentService`	上一跳服务
`resource`	当前 hop 的 operation

服务流路径树 — 图：服务流 — 入口 service-a 展开下游与响应贡献度（`metric_service_flow`）

六、端到端：checkout 慢怎么串表

把上面几张表串成一条路——还是开篇那句「checkout 为什么慢」：

入口稳不稳 — metric_service：service-a 错误率、平均耗时有没有飙。
锁慢接口 — metric_service_http：按 url 确认是 /demo/checkout。
锁慢 SQL + 谁触发 — metric_service_db：rootResource='/demo/checkout' AND isSlow=1，同行出语句摘要。
哪一跳拖后腿 — metric_service_flow：从入口 service-a 展开，比每 hop 响应贡献度。
（可选）哪台机器 — serviceInstance JOIN metric_service_instance。

所以叫「数据质量」：全程是固定列上的过滤与聚合——不是让模型猜 Span 名，也不是让人回原始调用链翻入口。

七、三步自检：你的数据集及格了吗？

用四句话考一遍有一题要你「自己去翻调用链」就不及格。能聊天 ≠ 能排障。
对照第三节高亮行调用分析 / 服务流 / 中间件专页——你的栈是 ✅ 还是 ❌？尤其是「慢 SQL → 入口」。
不及格怎么办？写入时补上入口 API、SQL 摘要等固定列；或换整理更完整的数据集。

收束：AI 时代，先问数据质量及格了吗——再谈 Prompt 和模型。四句话定及格线，对照表看产品面，12 张表是原因。

体验 DataBuff

开源 · OpenTelemetry · 数据集为 AI 问数预设计

在线 Demo：https://demo.databuff.ai

GitHub：https://github.com/databufflabs/databuff

💬 互动

四句话你能答几题？用的哪家栈？留言区聊聊——也欢迎对照第三节，说说最缺哪几行高亮能力。

字段权威定义：仓库 metric-catalog.json · 实现：DcSpanUtil · ServiceFlowExtractor