同一个 checkout 变慢场景跑一遍：从指标到 Tempo、再到 Loki，要切 4 段；DataBuff 从服务列表一路下钻，后面还能问 AI、看平台状态。
DataBuff 是 AI Native 的 APM，支持 OpenTelemetry 和 SkyWalking 数据接入，内置 7 大 AI 能力。GitHub：github.com/databufflab...
同一个 checkout 慢：Grafana 要进 3 套系统，DataBuff 在 1 套里走完。
| 排查什么 | Grafana：3 套系统 / 3 个分开的页面 | DataBuff：1 套系统 / 3 个串联页面 |
|---|---|---|
| Metric：谁慢了 | Grafana：Service Map | 服务列表 |
| Trace：慢在哪一段 | Tempo：trace 列表、瀑布图 | 链路追踪：从服务页直接下钻 |
| Log：当时发生了什么 | Loki：带 traceId 查日志 | 日志分析：点 Trace 回到链路 |
排障时它们是不是同一条路，比有没有这三支柱更影响手感。
这套 LGTM：Metric / Trace / Log 得顺着三条线查
场景是 service-a 的 GET /demo/checkout 变慢。先看 Metric 找到谁慢，再进 Trace 看哪条请求、哪段 span，最后翻 Log 补上下文。这套环境里，三个入口对应不同 datasource，筛选方式也不一样。
Metric · ① 服务谁慢：metrics-generator → 指标存储 → Service Map
这里的 Tempo 存的是 span。要看服务拓扑，得由 metrics-generator 把 span 聚成时序指标，再写到独立的指标存储，Grafana 才能画出 Service Map。
Metric · Service Map（metrics-generator 产出，非 Tempo 直出）
Trace · ② 定位请求：Explore 切 Tempo，搜 trace 列表
从 Service Map 切到 Explore 的 Tempo 数据源，按 service / operation 筛 checkout 那条慢 trace，记下 traceId。
Trace · Explore → Tempo：查询入口和筛选语法都换了
Trace · ③ 看瀑布：span 耗时拆在哪
点进 trace 详情，看 service-a → service-b → service-c 哪一段拖慢。还在 Tempo，Log 还没碰。
Trace · Tempo 瀑布图：定位慢 span
Log · ④ 对日志：Explore 切 Loki，手动粘 traceId
Log 又是另一条：Explore → Loki，把 traceId 带进 LogQL 查上下文。这套环境没配好 tracesToLogs 时，就得手动做这一步。
Log · Explore → Loki：换 LogQL，手动带 traceId
这套环境里，Metric、Trace、Log 对应多个 datasource
这次走下来： 4 段操作，查日志还得手动带 traceId。
DataBuff：同一件事故，从服务列表一路下钻
还是 checkout 慢。OTLP 进 DataBuff 后，Metric / Trace / Log 已经按同一套数据关联好。服务、链路、日志在一个产品里继续点；查日志时也不用手动把 traceId 填进查询条件。
Metric · ① 应用性能 → 服务列表：异常服务一眼看见
服务列表里 service-a 响应时间、错误率、流量直接展示，点服务名下钻。Metric 和 Trace 同源，不用从 span 抽到别处。
Metric · 服务异常：响应 / 错误 / 流量
Trace · ② 链路追踪：点慢 trace 看瀑布
从服务详情进 Trace，打开 checkout 240ms 那条链。中间件 span 在同一张图里，不用换系统。
Trace · 瀑布图 + 调用链
Log · ③ 日志分析：行尾 Trace 入口，一键回链
日志行右侧有 Trace 按钮，点一下就能回到对应链路。这里省掉的是值班时手动复制 traceId、再改查询条件的动作。
Log · 日志 → 链路：同一产品内关联
拓扑、服务异常、瀑布同一套数据，不用 metrics-generator 另抽一层
走到这儿，两边差的已经不是「能不能看到数据」------DataBuff 后面还能接着问、接着看平台，这套 LGTM 没配出这两层入口。
在这个路径后面，DataBuff 还接了 AI 和自监控
DataBuff 的服务、链路、日志走完后，页面上还接着两件事：直接用自然语言问数据 ，以及看平台自身的状态。这两块是这次跑下来感受差最多的。
AI · 问数 / 巡检 / 答疑，读的是刚下钻的那套数据
打开 AI 平台，不用先选 Tempo 还是 Loki，也不用写 TraceQL / LogQL。页面上已有智能问数、智能巡检、产品答疑、运维专家；示例问法也很具体：最近一小时服务列表、service-b 上下游拓扑、各服务请求量和异常量趋势。
模型仍要自己配，这套测试环境接的是 DeepSeek。差别在于专家和工具已经在产品里，问数时不用先处理三个 datasource 的上下文。
AI 平台 · 问数、巡检、答疑、运维专家，和 Metric / Trace / Log 在同一套菜单里
这套 Grafana 11.5 没有把这一步做成对话入口。想在 Grafana 里也这么问，需要另接 LLM 插件，再把 Tempo、Loki 和指标存储接进模型上下文。
自监控 · 部署状态：平台把自己当业务系统看
安装部署 → 部署状态。一页上能看到 ingest 入站 TPS、写出失败、Doris 磁盘、查询失败；图例按 trace / metric / log 分三条线。入站请求、入站字节、入站耗时、出站丢弃也放在同一时间轴。
部署状态 · ingest 总览：入站 32.9/s，Doris 磁盘 49%；trace / metric / log 同页
半夜碰到「业务慢，还是平台自己堵住了」这种问题，先看这一页就能排掉一批可能：三条线还在不在涨、写出有没有失败、Doris 磁盘有没有顶满。这套 LGTM 环境里，要看这些组件状态仍得分别进 Tempo、Loki、指标存储和 Grafana 的页面。
LGTM：查到数据为止。DataBuff：查完还能问、看平台。
| 你想做的事 | Grafana LGTM | DataBuff |
|---|---|---|
| 用自然语言问「谁慢、拓扑什么样」 | 自己写查询；或另接 LLM 插件和数据上下文 | AI 对话：示例问法就是服务列表 / 拓扑 / 流量 |
| 巡检出一份能转发的结论 | 自行组合 Dashboard 与告警规则 | 智能巡检，专家查同一套指标出报告 |
| 平台自己堵没堵 | 这套环境里分别看组件健康页 | 部署状态一页，ingest + Doris |
| 组件账 | Tempo + metrics-generator + 指标存储 + Loki + Grafana | ingest + 统一引擎 + Web（含 AI、部署状态） |
怎么试：OTLP 双写，不用推倒重来
采集端本来就是 OTLP。在 Alloy / Collector 里加一个 DataBuff exporter，和 Tempo 并行写几天；先确认同一批 span 都能对上，再决定是否下掉 Tempo 那路。整个过程可回滚。
可以按这条顺序跑一遍：服务异常 → 链路 → 日志 → AI 平台问一句服务列表或拓扑 → 部署状态看 ingest 三条线。LGTM 不用退场，就看这条值班路顺不顺。
DataBuff
AI Native 的 APM，支持 OpenTelemetry 和 SkyWalking 数据接入，内置 7 大 AI 能力
GitHub： github.com/databufflab...
在线 Demo： demo.databuff.ai