skywalking 的开源平替来了

摘要：我们发布了一款全新的开源APM项目，能够满足AI 时代的很多需求，弥补skywalking的不足，它完全拥抱 opentelemetry 顶级生态，自带AI智能体，基础功能非常完善，部署简单，看到这篇文章的同学可以尝试一下

SkyWalking 是APM领域的老牌开源项目，很多团队的第一套 APM 都来自它。但随着系统复杂度上升、AI 智能体进入生产，「只给数据」越来越不够，「能讲清楚、帮着查问题」才是值班工程师真正想要的。 总结了下，Skywalking目前存在的短板：

LLM / 智能体的监控能力不足
项目缺乏 AI 智能体层
止步于监控，告警的治理链路断裂
项目架构封闭笨重，与 Otel 顶级生态脱节

如果你正在评估 SkyWalking 的部署成本、存储选型，或者想要 OTel 原生 + 内置 AI 诊断 ，或者这款全新的APM 开源项目值得看一眼：DataBuff Open。

图：标准 OTLP 接入打底，AI 长在真实 Trace/指标/拓扑/告警上------不是外挂聊天框。

下面，我们就来看看 DataBuff 这款开源APM的功能如何，能不能解决上面的问题？

一、入口：从对话开始，而不是一堆看板

打开 DataBuff 项目，迎接你的不是密密麻麻的图表，而是一个自然语言对话框。如果你想了解数据，直接跟它对话。比如我想了解 「最近1小时的服务列表？每个服务最近1小时的请求量趋势？」，就直接在对话框里这样问：

图：问「最近 1 小时的服务列表」------ AI 多步推理后返回结构化表格（web / db / cache / mq），相当于有人帮你在 SkyWalking Service 视图里筛了一轮。

再追问趋势，一句话就够：

图：「查询每个服务最近 1 小时的请求量趋势图」------ 自动拉出多服务与 MySQL、Redis、Kafka 等组件趋势；过去要在多个 Dashboard 间切换。

SkyWalking 给你面板，很多你想要的面板没有，只能写语句查询，DataBuff 直接给你 「会查数的同事」------思考过程与工具调用全程可见，结论有数据支撑。

你还可以这样问：

场景	你可以这样问
看服务健康	「哪些服务错误率最高？」
查性能趋势	「order 服务最近 1 小时延迟怎么样？」
追慢请求	「找 5 条最慢的 Trace」
理清依赖	「payment 调了谁、被谁调？」
故障定位	「service-a 错误率突然升高，什么原因？」

不用记指标名，不用写 SQL。AI 大脑 会派内置的 问数专家 、巡检专家 查真实监控数据，思考过程与工具调用全程可见。

二、AI 工作台：多专家协同，还能接 SkyWalking

很多团队不是立刻替换 SkyWalking，而是：存量链路继续用 OAP，先加一层能读监控数据的 AI。

比如这个场景：公司架构师说「别动 SkyWalking，先让 AI 能列出当前有哪些服务、哪些 Layer」

图：用户问「通过外部 API 查询 SkyWalking 当前有哪些服务」------ AI 大脑 派给开放 API 助手，依次调用 listSkyWalkingLayers、listSkyWalkingServices，每步可审计。

这就是 并存路线 ：SkyWalking 继续采集，DataBuff 作 AI 排障层 。若走 替换路线，则用 DataBuff 的 OTel 底座承接拓扑、链路、告警，AI 直接读 Doris 里的真数据。

这就是 DataBuff AI 大脑的外部能力，通过 MCP 接进对话------GitHub、浏览器、知识库、其他 APM：

图：MCP 工具列表在对话中展开------不是聊天框外挂，是排障流程里的「手」。

与「APM + 通用 ChatGPT」的本质区别------Brain + 垂域专家 + Tool，必须调 APM 工具查真数，不是陪聊。

三、应用性能：拓扑 → 指标 → 链路 → 慢 SQL

DataBuff 底座基于 OpenTelemetry，目前应用性能监控功能已经覆盖 SkyWalking 用户最熟悉的使用路径：

复制代码

① 全局拓扑 → ② 服务详情 → ③ 上下游 → ④ 接口/组件分析
→ ⑤ 点图表下钻 Trace → ⑥ 调用链详情

① 全局拓扑 · 异常节点变红

图：调用关系一屏呈现------ 与 SkyWalking 拓扑图同类能力。

② 服务详情 · 指标印证异常

图：响应时间尖峰近 9s，错误率从 0% 升到约 15%。

③④ 沿下游追 · 慢 SQL 定位

图：select * from tableA limit ? 响应时间从 300ms 飙到 1.2s------ 点击可下钻 Trace。

图：慢调用次数与 Trace 结论交叉验证。

⑤ 链路追踪 · 错误与延迟同屏

图：Trace 错误统计突增，最大响应时间飙至近 9s。

入口变红，根因往往在下游。SkyWalking 老手都懂这条铁律------ DataBuff 把这条路径做成了 可点的六步 ，也可以 一句丢给 AI。

四、AI 应用的监控：智能体上了生产，监控跟上了吗？

前面几章讲的是：用 AI 帮你查传统微服务 。但 LLM / Agent 应用本身，怎么被看见、被治理。

大模型和 Agent 不是「多一个 HTTP 接口」。花钱、变慢、出错 的方式都不一样：一次对话可能跨多轮模型调用、多个 Skill、十几步工具链------SkyWalking 能画 order-service 的拓扑，却很难回答：

这次对话烧了多少 Token、花了多少钱？
Agent 调了哪些工具、哪一步最慢？
多轮推理里，是 哪次模型调用 把延迟拉垮的？

这就是在 AI 应用监控的落地：智能体进了生产，观测却还停在接口有没有 500。

LLM 观测 + AI Agent 观测

DataBuff 按 AI 可观测 单独建一层，与「AI 工作台帮你查数」互补：

层级	看什么
LLM 观测	模型调用链 · Token 消耗与成本 · 延迟/错误率 · Prompt 版本影响 · 多模型对比
AI Agent 观测	Agent 拓扑 · 技能调用 · 工具调用 · 模型调用 · 对话追踪 · Agent 错误分析

落地后，你关心的四件事都能收口：

价值	说明
一眼看拓扑	Agent 和普通应用谁调谁，地图里全有
成本可控	按服务、按 Agent 统计 Token 与花费
链路可追	模型 → 技能 → 工具，步步可查
出错能复盘	对话回溯，快速定位 bad case

LLM 观测 + AI Agent 观测 ------这是 SkyWalking、Pinpoint、Jaeger 一类传统 APM 不具备 的观测层；也是 DataBuff 相对「平替」最硬的差异化之一。

五、架构：OTel 进，Doris 存，三组件够轻

图：OpenTelemetry OTLP 进 Ingest，Doris 统一存储，Web 承载 APM 与 AI------ 无 OAP + ES 式的多层堆砌。

协议：OpenTelemetry OTLP，与 Collector、现有 OTel Agent 直接对接
存储：Apache Doris，面向 Trace / 指标的分析型查询
部署：Docker / K8s 脚本开箱（见 docker 安装部署）

若你受够了可观测工具组件集群的运维负担，这套 三组件架构 是「平替」最直观的理由之一。

六、五分钟跑起来：不是 SaaS 试用，是你自己的系统

bash 复制代码

# 安装平台（约 5 分钟）
curl -fsSL https://databuff.ai/databuff/ai-apm-install.sh | bash

# 可选：Demo 持续上报 Trace
curl -fsSL https://databuff.ai/databuff/ai-apm-demo-install.sh | bash

图：一条命令安装完成，终端输出 Web UI 地址、账号与 OTLP 接入信息

结语：SkyWalking 的「轻 + 智能」开源平替

SkyWalking 把 分布式追踪 做成了 Apache 标杆；DataBuff 想补的是下一格：在同样看得见链路的前提下，让 AI 直接读遥测数据、拼证据、给结论------ 部署更轻，私有化更省心。

模块	它替你做的事	SkyWalking 用户熟悉的能力
🤖 AI 工作台	中文问数、Brain 派专家	---
🔭 AI 可观测	LLM/Agent 调用链、Token、工具链追踪	---
eBPF 应用性能监控	基于 eBPF 技术实现无侵入的应用性能监控（roadmap）	---
Opentelemetry 生态	顶级 Otel 生态兼容良好	---
🚦 故障排查	服务健康全景、异常标红	Service 健康度 / 告警
🌐 全局拓扑	调用关系、节点变红	Topology Map
⚡ 服务详情	延迟 / 错误率 / QPS	Service Metrics
🔗 链路追踪	Trace 列表与下钻	Trace / Segment
🗄 数据库分析	慢 SQL、组件调用	DB 相关插件能力
📡 OTel + Doris	标准接入、三组件	OAP + 存储后端
🔌 MCP	可接 SkyWalking 等外部源	---

采集、拼图、翻链路的脏活交给 Agent；判断和决策留给人。

老 APM 给你图，DataBuff 给你结论。

DataBuff 项目的目标不是 1:1 克隆 SkyWalking 每个插件，而是在 「应用性能监控 + 智能排障」 这条主线上，给出更轻、更 AI 原生、更易私有化的开源方案------让应用从观测走向治理，实现自主化运维。

⭐ GitHub： https://github.com/databufflabs/databuff