给Skywalking一套更强的后端

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

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

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

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

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

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

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

它叫 DataBuff。

开源的AI APM。

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

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

怎么接：改上报地址就行

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

最小配置就两行。

properties 复制代码

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

启动时挂上 javaagent 即可：

bash 复制代码

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

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

bash 复制代码

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 小时服务列表，按业务 / 数据库 / 缓存消息 / 远程调用分类回来。

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

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

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

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

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

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

调用链详情：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 问数、巡检和链路纵深接上，是顺着行业方向在走，不是噱头。

引用资料

Gartner Magic Quadrant for Observability Platforms --- https://www.gartner.com/en/documents/5663323
Network World：Gartner 强调可观测平台的 AI 能力 --- https://www.networkworld.com/article/4032218/in-crowded-observability-market-gartner-calls-out-ai-capabilities-cost-optimization-devops-integration.html
Gartner：到 2028 年约 40% 部署 AI 的组织将采用 AI observability（APMdigest 转述）--- https://www.apmdigest.com/gartner-40-organizations-deploying-ai-will-use-ai-observability-monitor-model-performance-2028
https://databuff.ai/docs/zh/manual/skywalking-ingestion
https://databuff.ai/docs/zh/comparison/databuff-vs-skywalking
https://github.com/databufflabs/databuff
https://demo.databuff.ai/
https://www.databuff.ai/
😕/databuff.ai/docs/zh/comparison/databuff-vs-skywalking
https://github.com/databufflabs/databuff
https://demo.databuff.ai/
https://www.databuff.ai/