AI 排障答不上来很多人先怪 Prompt、再怪模型。更常见的原因其实在上游监控交给 AI 的数据不合格——接口、SQL、入口、链路跳数对不上模型再强也只能让你「自己去翻调用链」。这和 RAG、AI 客服是同一条铁律数据不过关上层再花哨也白搭。怎么判断「及格」本文按三步走先定四句话及格线 → 用同一把尺子对照 DataBuff、SkyWalking、Jaeger、Pinpoint、SigNoz、OpenObserve → 再看 DataBuffGitHub Star →怎样用 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。能力项DataBuffSkyWalkingJaegerPinpointSigNozOpenObserve1. 全局拓扑✅✅△✅✅❌2. 服务列表 / 黄金指标✅✅❌✅✅✅3. 服务级拓扑✅✅△✅△❌4. 服务级调用分析上下游 Metric Trace✅❌❌❌❌❌5. 实例级黄金指标✅✅❌△❌❌6. 实例级拓扑✅❌❌❌❌❌7. 实例级调用分析✅❌❌❌❌❌8. 接口级拓扑✅❌❌❌❌❌9. 接口级调用分析接口上下游 Metric Trace✅❌❌△❌❌10. 服务流Trace 级 Metric✅❌❌❌❌❌11. 中间件专页库/缓存/MQ · 对应第 2、3 题✅❌❌△❌❌12. 错误分析✅❌❌△❌△13. Trace 列表 / 搜索✅✅✅✅✅✅14. Trace 详情✅✅✅✅✅✅15. Span 关联日志✅✅△❌✅✅16. 日志列表 / 搜索✅✅❌❌✅✅17. 日志详情✅✅❌❌✅✅18. 日志关联 Trace✅✅❌❌✅✅读表结论Trace 搜索六家都能做差距在调用分析、服务流、中间件专页。人盯 UISkyWalking / Pinpoint 往往够用要 AI 直接答四句话靠的是这些纵深。这些能力不是多几个菜单而是故障因果链的基石哪个接口、哪条 SQL、谁触发、哪一跳拖后腿能直接串成因果。四、怎么准备及格的数据集第三节高亮能力调用分析、服务流、中间件专页不是事后拼页面而是调用链进来时就按类型写进固定表。DataBuff 把这件事落成12 张metric_service_*表——先认全这 12 张再谈怎么查。调用链Span进来 ↓ 按类型分表HTTP / DB / Redis / MQ / RPC…各一张不混在 Span 名里 ↓ 关键列写死入口 API、SQL 摘要、路径 hop 等与指标同行 ↓ 查表即可串因果产品面自然长出专页 / 服务流 / 调用分析12 张表一览名字固定AI / Text-to-SQL 不用猜 schema#表名存什么主要答什么1metric_service服务入口 RED这个服务稳不稳QPS / 错误率 / 延迟2metric_service_trace整条 Trace 根节点端到端一单的成败与耗时3metric_service_httpHTTP 接口分型哪个 URL / 方法 / 状态码有问题4metric_service_db数据库调用哪条 SQL 慢、哪个库、谁触发入口同行5metric_service_flow入口路径树从入口展开哪一跳拖后腿6metric_service_rpcRPC 调用gRPC / Dubbo 方法、状态码7metric_service_redis缓存调用GET/SET 等命令谁在打、是否慢8metric_service_mq消息队列topic 生产/消费、积压与延迟9metric_service_remote外部依赖外部 API 的 QPS / 延迟10metric_service_exception入口异常异常名 / 异常码仅入口报错11metric_service_config配置中心读取Nacos / ZK 等读取是否慢12metric_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 服务名里。图HTTP / DB / MQ / 缓存分型进拓扑——来自上表各组件表不是 Span 名一把梭五、四句话 → 查哪张表先看总表再按「预热 → 第 14 题」展开。每张只列答题用到的 tag。问题主查表关键 tag服务整体稳不稳预热metric_serviceservice、errorType1. 哪个接口有问题metric_service_httpurl、httpMethod、httpCode2. 哪条 SQL 慢metric_service_dbsqlContent、isSlow3. 慢 SQL 谁触发metric_service_dbrootResource与 sqlContent 同行4. 哪一跳拖后腿metric_service_flowentryInterfacePathId、pathId、parentService① metric_service — 服务稳不稳预热答「service-a 今天 QPS、错误率、平均耗时」何时写一行只有入口请求用户打进来的那一次过滤掉 DB / Redis / MQ 等组件 Span。关键 tagtag含义service服务名服务列表 KPI 主键errorTypeok / error 分行存算错误率时不混维度serviceInstance哪台 Pod / 实例拖后腿常用 fieldcnt→QPSerror÷cnt→错误率sumDuration÷cnt→平均耗时。图服务列表 —metric_service的产品面QPS / 错误率 / 耗时② metric_service_http — 第 1 题哪个接口慢答「哪个 URL 最慢GET 还是 POST4xx 还是 5xx」关键 tagtag含义url规范化 HTTP 路径接口 TOP 慢榜httpMethod/httpCode方法、状态码分开统计rootResource出站调用也能挂回「谁发起的」durationRange延迟分桶GROUP BY 即分布图图接口分析 · HTTP —/demo/checkout等 URL 独立成行metric_service_http③ metric_service_db — 第 2、3 题慢 SQL 谁触发答「哪条 SQL 慢是哪个入口触发的」——两问查同一张表、同一行。关键 tagtag含义sqlContent语句摘要SQL 级 TOPisSlow1 慢 SQL 行rootResource入口 API与 sqlContent 同行 → 不必回 Trace 找谁触发sqlDatabase/dbType哪个库、哪种引擎库在拓扑上是虚拟服务如[mysql]demo_apm专页列表来自本表聚合sqlContentrootResource同行是及格线最关键的设计。图数据库专页 —[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 …关键 tagtag含义entryInterfacePathId从哪个入口进来的指纹pathId当前 hop 在路径树中的位置parentService上一跳服务resource当前 hop 的 operation图服务流 — 入口 service-a 展开下游与响应贡献度metric_service_flow六、端到端checkout 慢怎么串表把上面几张表串成一条路——还是开篇那句「checkout 为什么慢」入口稳不稳—metric_serviceservice-a 错误率、平均耗时有没有飙。锁慢接口—metric_service_http按url确认是/demo/checkout。锁慢 SQL 谁触发—metric_service_dbrootResource/demo/checkout AND isSlow1同行出语句摘要。哪一跳拖后腿—metric_service_flow从入口 service-a 展开比每 hop 响应贡献度。可选哪台机器—serviceInstanceJOINmetric_service_instance。所以叫「数据质量」全程是固定列上的过滤与聚合——不是让模型猜 Span 名也不是让人回原始调用链翻入口。七、三步自检你的数据集及格了吗用四句话考一遍— 有一题要你「自己去翻调用链」就不及格。能聊天 ≠ 能排障。对照第三节高亮行— 调用分析 / 服务流 / 中间件专页——你的栈是 ✅ 还是 ❌尤其是「慢 SQL → 入口」。不及格怎么办— 写入时补上入口 API、SQL 摘要等固定列或换整理更完整的数据集。收束AI 时代先问数据质量及格了吗——再谈 Prompt 和模型。四句话定及格线对照表看产品面12 张表是原因。体验 DataBuff开源 · OpenTelemetry · 数据集为 AI 问数预设计在线 Demohttps://demo.databuff.ai觉得有帮助在 GitHub 上给我们一个 Star → 点击这里四句话你能答几题用的哪家栈留言区聊聊——也欢迎对照第三节说说最缺哪几行高亮能力。