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

最近在 GitHub 上发现一个项目：DataBuff。它是一个基于 OpenTelemetry 的 APM 平台，和 Datadog、SkyWalking 类似，服务、链路、拓扑、指标都能直接查看。但不同的是，它内置了一个AI 大脑。

直接用自然语言问一句"order-service 错误率突然升高，是什么原因？"它就能自动拉取指标、Trace、拓扑，给出诊断结论。有趣的是，它不是外挂一个聊天框，而是让 AI 直接读取遥测数据，根据真实数据作答。

AI 原生排障

假设要排查 service-a 响应变慢的原因。直接在 AI 平台输入："service-a 最近响应时间怎么样？"

AI 会自动获取 service-a 的响应时间趋势，发现最近 1 小时平均响应有问题（240 毫秒）。然后查看拓扑，显示 service-a 调用了 service-g，而 service-g 连接到了 MySQL 数据库节点。

接着找到执行速度慢的 SQL。在接口调用分析中，按响应时间排序，发现 SELECT * FROM history LIMIT ? 这个查询花费时间最长，平均 1.03 秒。点击图表下钻 Trace，找到根因 Span，确认是这条 SQL 拖垮了整个链路。

和别的 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 巡检专家还能主动发现服务异常，降低漏报率。

快速部署

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

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

注意事项

• 目前只支持 OpenTelemetry 和 SkyWalking 两种协议。如果使用了 Pinpoint、Zipkin 等专用 Agent，需要通过 Collector 转换。
• MVP 版本没有独立的 MCP API Token，安全上依靠内网或 VPN 隔离。公网暴露请自己加网关或防火墙。
• 告警通知（Webhook、邮件等）尚未实现，后续版本会加入。

总结

以前排查应用性能问题，需要在指标图表、Trace 列表、拓扑图之间来回切换。现在直接问 AI 一句，就能得到诊断结论。DataBuff 把应用性能监控中最重要的部分全打通了。

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

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

官网：databuff.ai