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