排查服务慢不用在图表间来回切：DataBuff让AI直接读Trace和拓扑，用自然语言定位慢SQL和链路根因

做运维的人都知道，应用一上线性能问题就接踵而来：响应慢、错误率飙升、服务拓扑一团乱麻。光是定位哪个服务慢了、哪条 SQL 耗时高、哪次调用拖垮了整条链路，就得在指标图表、Trace 列表、拓扑图之间来回切换。

DataBuff 是一个基于 OpenTelemetry 的 APM 平台，和 Datadog、SkyWalking 类似，服务、链路、拓扑、指标这些都能直接查看。不同的是它里面有一个 AI 大脑——直接用自然语言问一句"order-service 错误率突然升高，是什么原因？"，它就可以自动拉取指标、Trace、拓扑，给你一个诊断结论。它不是外挂一个聊天框，而是让 AI 直接读取遥测数据，根据真实数据作答。

实际使用体验

假设要排查 service-a 响应变慢的原因，直接在 AI 平台输入"service-a 最近响应时间怎么样？"，它就开始查指标：自动获取 service-a 的响应时间趋势，发现最近 1 小时平均响应有问题。

然后看拓扑：显示 service-a 调用了 service-g，而 service-g 又连接到了数据库节点。接着找到执行速度慢的 SQL，在接口调用分析中按响应时间从大到小排列，可以发现某个查询花费时间最长。最后点击图表下钻 Trace，进入 Trace 列表找到根因 Span，确认是这条 SQL 拖垮了整个链路。

核心功能

AI 原生排障。 和别的 APM 只挂一个聊天框不同，DataBuff 的 AI 会直接查询 Trace、指标、拓扑、告警。平台内含"AI 大脑"、"智能问数专家"、"巡检专家"三个层次，复杂问题可以由多个专家同时合作，最后得出一份诊断报告。

OpenTelemetry 原生支持。 按照 OTLP 标准，Ingest 服务暴露了 gRPC 4317 和 HTTP 4318 端口。应用侧只需要配置 Exporter 指向后端地址，不需要绑定专用 Agent，支持任意的 OTel SDK 或自动插件。

服务拓扑自动绘制。 根据 Trace 中 Span 父子关系自动画出服务和中间件的依赖图，用不同颜色表示健康状况（红、黄、绿），可以很快发现是哪个服务或组件出了问题。不需要手工维护 CMDB，平台可以自动识别虚拟服务节点的类型，中间件维度更清晰。

慢 SQL 一键定位。 数据库详情页的慢 SQL Tab 按调用次数排序，可以快速找到性能瓶颈。点击 SQL 行可以跳转到接口调用详情或 Trace，实现双向验证，确定是不是这条语句导致了整个链路变慢。

告警闭环和智能巡检。 告警模块支持阈值和突变检测规则，每分钟对核心服务指标进行一次评估，触发后记录告警事件，指标恢复后自动标记为已解决。AI 巡检专家还可以主动发现服务异常，降低漏报率。告警详情页可以自动追问根因，AI 自动查数据并给出诊断，不需要人工翻图表。

安装方式

Docker 一条命令就可以跑起来，从执行命令到看到 Demo 数据大约 5 分钟：

curl -fsSL https://databuff.ai/databuff/ai-apm-install.sh | bash

安装完毕后，访问 http://YOUR_HOST:27403，默认账号为 admin，密码为 Databuff@123。

如果要试用 Demo 应用，再安装一个：

curl -fsSL https://databuff.ai/databuff/ai-apm-demo-install.sh | bash

Demo 会一直向 Ingest 报告模拟的 Trace，打开 UI 就可以看到服务拓扑和链路追踪。

架构非常简单，只有三个主要部分：Ingest（接入）→ Doris（存储）→ Web（平台），与传统 APM 多组件栈相比，运维成本大大降低。

注意事项

目前只支持 OpenTelemetry 和 SkyWalking 两种协议，如果使用了 Pinpoint、Zipkin 等专用 Agent，需要通过 Collector 进行转换。

MVP 版本没有独立的 MCP API Token，安全上依靠内网或 VPN 来隔离，公网暴露请自己加网关或防火墙。

告警通知（Webhook、邮件等）还没有实现，要等后面的版本，目前主要是记录告警事件，指标恢复后自动标记为已解决。

项目基于 AGPL-3.0 协议开放。

开源地址：https://github.com/databufflabs/databuff

官网：https://databuff.ai