Skywalking已全面拥抱AI！

前言

分布式链路追踪的"最后一公里"，终于被AI打通了

最近在做线上故障排查的时候，发现了一个非常普遍的现象------大家都会用Skywalking看链路，但真正能"看懂"的人不多。

链路追踪工具把分布式调用链画出来了，但排查问题的核心环节------"从一堆Span里找出那个慢的"、"从告警里定位根因"、"从海量Trace里归纳规律"------全部要靠人工完成。

有个小伙伴给我看了他们团队的排障流程：告警来了，看一眼Skywalking的拓扑图，发现有根红线；

切到Trace列表，筛服务、筛接口、翻页，找到几条慢的；

点开Span树，自己读、自己比、自己猜；

然后切到日志系统对TraceID，再切到监控系统看指标。

一套流程走下来，少则20分钟，多则一两个小时。

他说了一句话让我印象很深："Skywalking把链路画出来了，但看懂它、用它解决问题的'最后一公里'，还得靠人。"

现在，这个问题终于有解了。

Apache Skywalking正式接入AI能力！

这不是一个概念，而是一整套已经落地、正在快速演进的可观测性AI能力矩阵。

从Horizon UI的AI智能问答助手 ，到Virtual GenAI的大模型应用监控 ，再到AI Pipeline的机器学习异常检测------Skywalking正在从一个"链路展示工具"，进化成一个"智能诊断平台"。

今天这篇文章就专门跟大家一起聊聊这个话题，希望对你会有所帮助。

更多项目实战在我的技术网站：susan.net.cn/project

一、接入的AI功能是什么？

在深入之前，我们先建立整体认知。

Skywalking的AI能力不是"加了一个聊天框"这么简单，它覆盖了三个不同的层面：

第一层：Horizon UI AI Assistant------用自然语言问你的观测数据

这是2026年7月刚发布的Horizon UI 1.0的核心特性。

简单说，你不用再在一堆仪表盘里点来点去找数据了------直接问AI就行。

你可以直接问："系统里现在有哪些不健康的东西？ "或者"帮我查一下某某服务的响应时间为什么变慢了"。

AI会从OAP后端读取实时数据，然后给你生成带有真实图表的可读报告。

它不是"把仪表盘上的数字翻译成文字"，而是真正读懂你的观测数据，然后给你讲清楚。

第二层：Virtual GenAI------让你的大模型调用不再"黑盒"

如果你的应用用到了Spring AI或OpenAI SDK来调用大模型，Skywalking 10.4的Virtual GenAI 能让你看到：每一次LLM调用的延迟（Latency） 、Token用量（输入/输出） 、预估成本 ，以及流式调用的首字延迟（TTFT） 。

"你的应用在调用哪个模型、花了多少钱、用户体感快不快"------以前这些全是黑盒，现在Skywalking全部给你可视化出来。

第三层：AI Pipeline------机器学习让运维变"主动"

Skywalking的AI Pipeline 模块通过gRPC协议与第三方AI服务通信，提供智能基线计算 和HTTP URI模式识别两大核心能力。

它利用机器学习算法自动学习应用行为的正常模式，当检测到异常偏差时立即告警，无需手动配置阈值。

同时，Skywalking还支持RESTful API的智能URI模式识别，自动聚合和分类大量HTTP请求。

这三层能力加起来，Skywalking正在从一个"链路展示工具"变成真正的"智能可观测性平台"。

二、Horizon UI AI Assistant

它能用对话代替点鼠标。

2.1 它到底是什么？

Horizon UI是Skywalking的下一代Web控制台。

而AI Assistant是Horizon UI 1.0内置的一个AI智能助手。

它最核心的设计理念就一句话："Show, don't describe"（展示，而不是描述） 。

什么意思呢？

一般的AI问答，给你一大堆文字。

AI Assistant不一样------它写一两句总结，然后直接画一张真实的图表，再解释这张图说明了什么。

每张图都是真实的实时渲染，不是截图，也不是编造的数字。

2.2 它能看到什么？

AI Assistant通过三个数据来源来回答问题，三者结合才能把零散信号拼成完整图景：

① 实时观测数据 它走的是和仪表盘完全相同的OAP查询协议，所以它看到的数据和你仪表盘上看到的一模一样。

② Layer配置（作为技能库） Layer配置就像是AI Assistant的"知识目录"，告诉它每个Layer测量什么指标、每个指标的实体范围是什么。

③ 权限体系 它是只读的，继承你的权限。你只能看到你有权看到的数据。

2.3 它默认是关闭的

AI Assistant默认是关闭的，需要运维人员手动启用，并指向一个模型服务。

你可以用自己的模型（可以是本地Ollama，也可以是云端API），成本可控、数据不出境。

三、Virtual GenAI

它是LLM调用的"数字仪表盘"。

3.1 痛点：应用在"吃"大模型，监控却留了盲区

很多开发团队在用Spring AI或OpenAI SDK快速集成了大模型能力之后，发现了一个尴尬的问题------对这些调用的实际表现，几乎一无所知。

你只知道每个月给某家Provider付了一大笔钱，但这笔账在应用内部的"投入产出比"是多少？

花几倍的Token成本换了旗舰模型，它在你的真实业务场景下真的更快吗？

想给LLM调用设置超时时间，是设30秒还是60秒？

拍脑袋决定的结果，往往是设太短导致请求被频繁中断，设太长导致请求堆积把整个Java应用拖垮。

Skywalking 10.4引入的Virtual GenAI能力，正是为了解决这个"观测真空"。

3.2 技术原理

当Skywalking Java Agent或OTLP探针拦截到对主流AI框架（如Spring AI、OpenAI SDK）的调用时，它们会向Skywalking OAP上报Trace数据。

这些Trace数据遵循GenAI语义约定，包含Provider名称、模型名称、输入/输出Token数量、首字延迟（TTFT）等关键信息。

OAP从分布式追踪数据中提取这些指标，在GenAI仪表盘上展示流量、延迟、成功率、Token用量（输入/输出）和预估成本。

3.3 你能看到什么？

接入Virtual GenAI后，你可以在GenAI仪表盘上看到Provider级别 和Model级别的详细指标：

指标分类	具体指标	说明
流量与成功率	CPM（每分钟调用次数）、SLA（成功率）	调用量和健康度
延迟	P50/P90/P99延迟百分位	真实波动曲线，为动态超时提供依据
TTFT（首字延迟）	流式调用的首字延迟	UX的核心指标
Token用量	输入Token/输出Token	用量统计
预估成本	基于配置的单位成本估算	每一笔账都算得清

配置成本估算 ：在gen-ai-config.yml中配置Provider和Model的定价，Skywalking会自动计算每次调用的预估成本。

3.4 两种监控模式

Skywalking支持两种大模型监控模式：

模式一：网关侧监控（Envoy AI Gateway） 通过Envoy AI Gateway统一接入LLM流量，网关通过OTLP gRPC直接将GenAI指标和访问日志推送到SkyWalking OAP。适合统一管理多Provider调用的场景。

模式二：应用侧监控（Virtual GenAI） 通过Java Agent在客户端视角采集最真实的数据。适合精细到每一次SDK调用的监控。

四、AI Pipeline

它是机器学习驱动的智能运维。

如果说Horizon UI AI Assistant解决的是"怎么查"的问题，Virtual GenAI解决的是"LLM怎么监控"的问题，那么AI Pipeline 解决的就是"怎么让运维变主动"的问题。

4.1 架构原理

Skywalking的AI Pipeline模块采用gRPC协议与第三方AI服务进行通信，支持异步处理大规模遥测数据。

核心包含以下组件：

基线查询服务：支持时间序列数据的智能基线计算
HTTP URI识别服务：实现URL模式的智能识别和分类
预测服务指标：提供机器学习模型的性能监控和评估能力

4.2 四大核心AI功能

① 智能异常检测 Skywalking利用机器学习算法自动学习应用行为的正常模式 ，当检测到异常偏差时立即告警，无需手动配置阈值。

② 根因分析加速 通过关联分析多维度指标，AI引擎能够快速定位问题根源，大幅减少平均修复时间。

③ 自适应基线计算 系统能够自动适应业务流量的周期性变化，区分真正的异常和正常的业务波动。

④ 智能URI模式识别 自动识别和分类HTTP请求URL模式，帮助运维人员理解API使用情况。基于R3算法（RESTful Pattern Recognition）实现，它利用机器学习对RESTful API进行模式识别和分组。

4.3 部署配置

在application.yml中启用AI Pipeline模块并配置gRPC端点：

yaml 复制代码

ai-pipeline:
  enabled: true
  grpc-endpoint: "your-ai-service:50051"

系统支持TensorFlow/PyTorch模型集成 、实时流式数据处理 、分布式模型推理 和模型性能监控等能力。

五、如何接入Skywalking AI？

5.1 接入Horizon UI AI Assistant

Step 1：部署Horizon UI

Horizon UI作为一个独立的容器镜像发布，可从Docker Hub获取：

bash 复制代码

docker pull apache/skywalking-ui:horizon-latest
docker run -d -p 8080:8080 \
  -e OAP_BACKEND_URL=http://your-oap:12800 \
  apache/skywalking-ui:horizon-latest

Step 2：启用AI Assistant

在Horizon UI的配置文件中启用AI Assistant，并配置模型服务端点：

yaml 复制代码

ai:
  assistant:
    enabled: true
    model:
      endpoint: "http://your-llm-service:8000/v1"
      api_key: "your-api-key"  # 可选

支持Ollama本地模型、OpenAI API、Gemini API等多种模型服务。

Step 3：开始提问

登录Horizon UI后，点击AI Assistant图标，直接输入自然语言问题，例如：

"系统里现在有哪些不健康的服务？ "
"order-service最近为什么变慢了？ "
"帮我看看payment接口的P99延迟趋势"

5.2 接入Virtual GenAI（Java应用）

Step 1：升级Agent版本

确保Skywalking Java Agent版本 >= 9.7。

Step 2：在pom.xml中添加依赖

xml 复制代码

<dependency>
    <groupId>org.apache.skywalking</groupId>
    <artifactId>apm-toolkit-trace</artifactId>
    <version>9.7.0</version>
</dependency>

Step 3：配置成本估算

在Skywalking OAP的config/gen-ai-config.yml中配置模型定价：

yaml 复制代码

providers:
  - provider: openai
    prefix-match:
      - gpt
    models:
      - name: gpt-4o
        input-estimated-cost-per-m: 2.5
        output-estimated-cost-per-m: 10

Step 4：启动应用并查看GenAI仪表盘

启动应用后，在Horizon UI中找到GenAI Dashboard ，即可看到所有LLM调用的流量、延迟、Token用量和预估成本。

5.3 接入AI Pipeline

Step 1：部署AI服务

部署一个实现了Skywalking AI Pipeline gRPC协议的服务（可使用开源R3算法实现）。

Step 2：配置OAP

在OAP的application.yml中启用AI Pipeline：

yaml 复制代码

ai-pipeline:
  enabled: true
  grpc-endpoint: "your-ai-service:50051"

Step 3：启用URI模式识别

在OAP配置中启用HTTP URI模式识别，AI会自动对RESTful API进行模式识别和分组。

六、优缺点

优点

1. 自然语言智能问答，排障效率大幅提升 AI Assistant让排查从"翻列表、读Span树、写故障群"变成"问一句→拿traceId→看图核实"。一个原本需要20分钟的排障流程，可能压缩到5分钟以内。

2. LLM调用可观测，每一分钱都算得清 Virtual GenAI让LLM调用从"黑盒"变成"白盒"------Token用量、预估成本、TTFT等关键指标一目了然。

3. 机器学习智能运维，告别手动配置阈值 AI Pipeline自动学习应用行为模式，智能告警和根因分析无需人工干预。

4. 分层接入，渐进式落地 AI能力分三层独立接入，你可以从最需要的那个开始，不用一次性全上。

5. 模型灵活，成本可控 AI Assistant支持接入本地Ollama或云端API，数据不出境、成本自己说了算。

6. 开源生态持续进化 Skywalking作为Apache顶级项目，9年历史、数千集群部署验证，AI能力还在快速迭代中。

缺点与注意事项

1. AI Assistant默认关闭，需要手动配置 AI Assistant默认是关闭的，需要运维人员手动启用并配置模型服务。

2. Virtual GenAI需要升级Agent版本 需要Skywalking Java Agent >= 9.7，老版本需要升级。

3. AI Pipeline需要第三方AI服务 AI Pipeline本身不包含AI模型，需要部署额外的AI服务（如R3算法实现）。

4. 成本估算需要手动配置 Virtual GenAI的成本估算需要在gen-ai-config.yml中手动配置各模型的定价。

5. AI能力仍在快速演进中 部分AI功能（如自然语言转BydbQL）仍处于开发或预览阶段。

七、适用场景

场景	推荐程度	推荐能力	理由
日常排障/On-Call	✅✅✅ 强烈推荐	AI Assistant	从"翻日志"变成"问AI"
大模型应用开发	✅✅✅ 强烈推荐	Virtual GenAI	监控LLM调用的性能与成本
多Provider LLM管理	✅✅✅ 强烈推荐	Virtual GenAI + Envoy AI Gateway	统一观测多Provider的Token和成本
大规模微服务运维	✅✅ 推荐	AI Pipeline	智能异常检测+根因分析
电商大促容量规划	✅✅ 推荐	AI Pipeline	预测流量峰值，提前预警瓶颈
资源利用率优化	✅✅ 推荐	AI Pipeline	AI推荐最优资源分配策略

更多项目实战在我的技术网站：susan.net.cn/project

总结

回到最初的问题：Skywalking接入AI，到底解决了什么问题？

它解决了链路追踪工具的"最后一公里"问题。

以前的Skywalking，像一台X光机 ------能拍出清晰的骨骼图像，但看懂片子、下诊断还得靠医生。

现在的Skywalking + AI，像一台AI辅助诊断系统 ------不仅拍片，还能自动识别病灶、给出诊断建议、回答你的提问。

Horizon UI AI Assistant 让你用自然语言问观测数据；Virtual GenAI 让LLM调用从黑盒变白盒；AI Pipeline让运维从被动响应变主动预测。

这三层能力叠加在一起，Skywalking正在从一个"链路展示工具"，进化成一个真正能帮开发者和运维人员"看懂系统、快速定位问题"的智能可观测性平台。

如果你还在用"翻Trace列表、读Span树、手动关联日志"的方式排查问题，建议你花一个下午把Horizon UI + AI Assistant跑起来试试。

感受一下"问一句就能拿到答案"的排障体验------你会发现，以前花20分钟做的事，现在可能只需要3分钟。