全链路 Skywalking 的更强开源后端，具备AI能力

SkyWalking 在国内运维圈很常见：探针多、文档全、上手路径也清晰。

真正费劲的，往往不是 Agent。

卡点常常在后半段：OAP 怎么部署、存储怎么选、UI 够不够用来排障。

作为一名资深的运维工程师，这么多年用下来，最深的体会：

不是 SkyWalking 不行，AI时代了后端功能依然非常传统羸弱。

尤其是在把故障的关键环节卡壳，支撑能力弱。

最近在 GitHub 上发现了一款宝藏工具，能够解决我的烦恼。

它叫 DataBuff。

开源的AI APM。

在这里插入图片描述

它能无缝接管 SkyWalking Agent 的上报。

skywalking Agent 还在，后端换一换——这就是我想要的效果。

怎么接：改上报地址就行

官方接入文档写得很直白：Trace、JVM 指标、Log 三个 gRPC 服务，都打到 Ingest 的 11800。4

最小配置就两行。

# agent.config
agent.backend_service=<ingest-host>:11800
agent.service_name=my-service

启动时挂上 javaagent 即可：

java -javaagent:/path/to/skywalking-agent.jar \
     -Dskywalking_config=/path/to/agent.config \
     -jar my-service.jar

不想改配置文件，也能用系统属性覆盖：

java -javaagent:/path/to/skywalking-agent.jar \
     -Dskywalking.agent.service_name=my-service \
     -Dskywalking.collector.backend_service=<ingest-host>:11800 \
     -jar my-service.jar

和 OTLP 可以并存：SkyWalking 走 11800，OTLP 仍是常见的 4317 / 4318，互不打架。4

环境里部分应用继续用 SkyWalking Agent，部分走 OTLP，也行。

同一条 Trace 若跨协议混报，要自己协商 TraceId 传播格式（SW8 与 W3C traceparent 不同）——这个边界文档里也写了，别踩坑。4

接上之后，Web 里看服务是否出现、Trace 是否进来，就够验证了。

公网 Demo 也能先点一遍效果，不必一上来就装全套。7

接入后来看看新后端的效果

接上只是第一步。

真正想验证的是：后端换了之后，值班时能不能少翻几层菜单。

下面三下，都是 Demo 现场点出来的。

01 · AI 问数：大白话问出服务家底

第一句就问：「查询最近 1 小时的服务列表」。

回来不是空泛闲聊——业务服务、数据库、缓存、消息队列、远程调用，按类别列成表。

现场这一下：service-a / service-b 是 Java 业务服务，底下还挂着 MySQL、ES、Redis、Kafka 和远程支付接口。

值班时最烦的是：想看家底，还得先记指标名、切 Dashboard。

这一下省掉了——问得动真实遥测，不是陪聊。

AI 问数：最近 1 小时服务列表

AI 问数：最近 1 小时服务列表，按业务 / 数据库 / 缓存消息 / 远程调用分类回来。

02 · 链路追踪详情：瀑布图把耗时摊开

问数看清家底，下一刀就抠单笔请求。

打开调用链详情：入口是 GET /demo/checkout，落在 service-a，总耗时大约 240ms。

瀑布图里 Redis、HTTP、MySQL、Elasticsearch、Dubbo、Kafka 一层层排开，谁吃时间一目了然。

右侧还能点开 Span 属性：主机、实例、状态码，排障时不用再猜「这一跳到底是啥」。

Agent 还是熟悉的那套上报；看 Trace 的方式，却更顺手了。

调用链详情瀑布图 GET /demo/checkout

调用链详情：GET /demo/checkout，约 240ms；瀑布图展开 Redis / MySQL / Dubbo / Kafka 等 Span。

03 · 全局拓扑：一眼看清谁连谁

第三下看全局拓扑。

service-a、service-b，再到 MySQL、ES、Redis、Kafka、远程支付——节点和边都在图上。

健康色标能帮你先盯住「该先看谁」；再下钻到服务级、调用分析，才是排障的第二步。

拓扑回答「连谁」；后面的调用分析、服务流，才回答「谁拖慢、怎么落到 Trace」。

这三下串起来：问清家底 → 抠清单笔 → 看清全局。

全局拓扑图

全局拓扑：service-a / service-b 与 MySQL、ES、Redis、Kafka、远程支付的依赖关系一目了然。

三下下来，感觉不像在翻产品说明书，更像验证一件事：Agent 不用换，后端能力能不能再往前走一截。

收束：客观比一比就够了

公开对比文档里，两边基础面其实都不弱：全局拓扑、服务列表、Trace、日志，SkyWalking 和 DataBuff 都能做。5

DataBuff 多出来的，主要是 AI 这一层。

自然语言问数、巡检、诊断等，以及服务级 / 实例级 / 接口级调用分析、服务流这类 APM 纵深：从「看见连谁」，走到「谁拖慢、再点进 Trace」。5

所以适用场景其实很实在——

已有大量 SkyWalking Agent、想先摸 AI 和 APM 专页：改上报地址并跑就行。

回到标题那句话。

不是要把 SkyWalking 踢出局，而是：探针还在，后端可以更强一点。

接入成本很低——端口还是 11800，配置就那几行。

开箱三下能复现；边界也写在对比文档里。

亲手点一遍，比看任何口号都踏实。

行业侧看一眼：可观测正在往 AI 走

Gartner 在 Observability Platforms 研究里写得很直白：可观测平台要把遥测变成洞察和行动，靠的是分析、可视化、自动化——而且越来越离不开 AI。1

行业侧复述的同一条主线是：平台在拼的，不只是「看得见 metrics / logs / traces」，还有用 AI/ML 做异常检测、告警降噪、根因关联，以及面向 GenAI 负载的 AI observability。2

还有一个常被引用的判断：到 2028 年，部署 AI 的组织里，约四成会用专门的 AI observability 去盯模型表现、偏差与输出——本质是系统越复杂，越需要「问得动、解释得清」的一层能力。3

放到 SkyWalking / DataBuff 这场讨论里，其实就一句：探针还在，后端若能把 AI 问数、巡检和链路纵深接上，是顺着行业方向在走，不是噱头。

引用资料

1. Gartner Magic Quadrant for Observability Platforms — [https://www.gartner.com/en/documents/5663323