SkyWalking 简介Apache SkyWalking 是一套完整的应用性能监控APM与可观测性分析系统[1]。与只做链路展示的轻量工具不同它在同一平台内聚合五类遥测数据Tracing链路追踪原生 Segment 格式兼容 Zipkin v1/v2Metrics指标原生 Meter、OpenTelemetry Metrics、Telegraf可与 Istio/Envoy 集成Logging日志磁盘或网络采集Agent 可自动绑定 Trace 上下文Profiling性能剖析语言 Agent 与 eBPF Agent 提供代码级热点分析Event事件记录发布、配置变更等关键事件与指标/链路关联排障1.1 逻辑四层架构官方文档将 SkyWalking 逻辑划分为四段[2]理解这四层是快速入门的前提[ Probe 探针 ] → gRPC / OTLP / Zipkin / Prometheus …↓[ OAP 平台后端 ] → 聚合 · 流式分析 · 告警规则↓[ Storage 存储 ] → Elasticsearch / BanyanDB / JDBC …↓[ UI ] → 拓扑 · Trace · 指标 · 日志 · ProfilingSkyWalking 官方架构Probe、OAP、Storage、UI图 1-1 · Probe 采集多协议遥测OAP 承担分析与聚合Storage 插件化选型UI 提供可视化控制台。v10.x 起 Booster UI 逐步演进为 Horizon UI。1.2 核心数据模型SkyWalking 用 Service → Service Instance → Endpoint → Process 描述观测对象[2]Service一组提供相同行为的工作负载如 order-serviceService InstanceService 下的单个实例Java Agent 场景通常对应一个 OS 进程EndpointHTTP URI 或 gRPC 方法签名等入口路径Process进程级元数据便于与 K8s Pod 关联跨 K8s、Mesh、OS 等多 Layer 时可通过 Service Hierarchy 关联同一逻辑服务在不同层级的视图。这也是 Horizon UI 左侧按 Layer 分组导航的原因。Probe 形态丰富 除 Java/C#/Go/Node.js/PHP/Python 等语言 Agent 外还支持 Service Mesh Receiver、eBPF K8s 监控以及 OpenTelemetry、Prometheus、Zipkin 等第三方格式接入——适合「存量 Agent 新 OTel 数据」并存的渐进路线。§2 SkyWalking 简单使用三步跑通起后端 → 挂 Java Agent → 在 UI 中验证数据。2.1 后端部署Docker Quick Start 是最快的体验路径生产环境需单独规划 Storage 集群。官方一键脚本SkyWalking 文档页提供交互式脚本启动时会提示选择 Elasticsearch 或 BanyanDB 作为存储后端并拉起 OAP UI[3]。Linux / macOS / WSLbash (curl -sSL https://skywalking.apache.org/quickstart-docker.sh)Windows PowerShellInvoke-Expression ([System.Text.Encoding]::UTF8.GetString((Invoke-WebRequest -Uri https://skywalking.apache.org/quickstart-docker.ps1 -UseBasicParsing).Content))脚本完成后典型端口如下[4]Agent / gRPC 上报11800OAP 默认 collector 端口OAP HTTP REST12800UI 控制台8080浏览器访问体验结束后销毁环境docker compose --project-nameskywalking-quickstart down自定义 compose 配置若需指定镜像版本或存储类型可在官方仓库使用 profile 启动[4]Elasticsearch 存储docker compose --profile elasticsearch upBanyanDB 存储SkyWalking 自研时序追踪库docker compose --profile banyandb up也可单独运行 OAP 容器并指定 BanyanDB 后端export RELEASE_VERSION10.4.0docker run --name oap -d --restart always-e SW_STORAGEbanyandb-e SW_STORAGE_BANYANDB_TARGETSbanyandb:17912apache/skywalking-oap-server:${RELEASE_VERSION}运维提示 生产环境常见拓扑是「OAP 集群 ES/OpenSearch 或 BanyanDB 集群 UI」。Storage 选型直接决定磁盘成本与 Trace 查询延迟10.x 版本在 BanyanDB 集成上持续加深适合新项目评估。2.2 Java 探针安装字节码增强、无侵入接入JDK 8–25 可用[5]。获取 Agent 包从 Apache SkyWalking Java Agent 发行包中解压 agent/ 目录核心文件为 skywalking-agent.jar插件位于 plugins/配置位于 config/agent.config[5]。关键配置项编辑 agent.config或通过环境变量覆盖服务名英文标识UI 中展示agent.service_name${SW_AGENT_NAME:YourAppName}OAP 地址默认本机 11800collector.backend_service${SW_AGENT_COLLECTOR_BACKEND_SERVICES:127.0.0.1:11800}在 Docker Compose 或 K8s 中常用环境变量写法SW_AGENT_NAMEorder-serviceSW_AGENT_COLLECTOR_BACKEND_SERVICESoap:11800挂载到 JVM可执行 JARjava -javaagent:/path/to/skywalking-agent/skywalking-agent.jar-jar yourApp.jarIDEA 本地调试在 Run Configuration → VM options 中添加-javaagent:D:\skywalking-agent\skywalking-agent.jar-Dskywalking.agent.service_namedemo-app-Dskywalking.collector.backend_service127.0.0.1:11800Tomcatcatalina.sh 首行CATALINA_OPTS“$CATALINA_OPTS -javaagent:/path/to/skywalking-agent.jar”; export CATALINA_OPTS注意 -javaagent 必须放在 -jar 之前[5]。启动后等待数十秒在 UI「General Service」拓扑中应能看到对应 Service 节点。插件管理plugins/ 目录下插件默认全部启用覆盖 Dubbo、Feign、HttpClient、JDBC 等常见中间件删除某个 jar 即可禁用对应探针。可选插件在 optional-plugins/按需拷贝到 plugins/ 激活[5]。2.3 功能界面解释以 Horizon UI 为例对照官方 Demo 讲解核心视图。完成部署与探针接入后打开 UI默认 8080 端口Demo 地址为 demo.skywalking.apache.org。Horizon UI 左侧按 Layer 分组「通用服务General Service」是最常用的入口。下面结合现场截图说明三个核心面板。服务拓扑Topology拓扑图展示服务间的调用依赖关系节点大小反映流量连线颜色标识健康状态。点击某个 Service 可下钻到实例、API 与 Trace 列表——这是排障时「先看全局、再定位单点」的第一步。SkyWalking Horizon UI 服务拓扑视图图 2-1 · 拓扑视图展示 gateway、app、user 等服务的调用关系与 RPM/错误率指标可直观发现异常节点。服务仪表板Services Dashboard仪表板按 Layer 汇总所有 Service 的 RED 指标请求量、错误率、响应延迟支持按 APDEX、SLA 等维度排序。适合值班同学快速扫描「哪个服务今天变慢了」。SkyWalking 服务仪表板 RED 指标图 2-2 · 服务仪表板列出各 Service 的 RPM、成功率、P99 延迟顶部告警入口显示当前活跃告警数。链路追踪TracesTrace 面板支持按实例、Endpoint、状态成功/错误、耗时区间、Trace ID 等条件筛选。点击「执行查询」后列表展示每条 Trace 的 Endpoint、耗时条与状态标签右侧分布图用散点标识正常与异常请求的时间分布。SkyWalking Trace 列表与耗时分布图 2-3 · Trace 列表展示 /homepage 等 Endpoint 的耗时条绿色正常、红色错误可进一步点开查看 Span 瀑布图定位慢调用。除上述三视图外Horizon UI 还提供 Logs日志与 Trace 关联、告警规则触发与通知、ProfilingTrace Profiling / eBPF等进阶能力。入门阶段掌握拓扑 Trace 即可覆盖 80% 的日常排障场景。§3 AI 原生能力SkyWalking 主路径与 Databuff OTLP 双轨架构速览sw-dual-track-a图 3-0 · 同一 Probe 可经 gRPC 11800 走 SkyWalking 四层栈或经 OTLP 4318 接入 Databuff 三组件栈后者在 Web 平台内置 AI 问数能力。需要说明的是SkyWalking 目前尚未提供内置的 AI 智能体能力——控制台以拓扑、Trace、指标、日志等可视化查询为主尚不支持自然语言问数或多智能体协同排障。若团队希望在跑通 SkyWalking 之后进一步探索「AI 辅助值班」可以了解一下另一款国产开源项目 Databuff它在 APM 存储之上内置了 AI 平台模块下文作简要介绍。3.1 Databuff 简介Databuff 是面向 OpenTelemetry 标准的开源 APM默认接收 OTLP Trace 与 Metrics在同一存储上提供查询、告警与 AI 辅助排障[6]。Databuff 已收录于 OpenTelemetry.io 官方 Vendors 生态名单标注 Native OTLP 原生消费遥测数据可在 OpenTelemetry 官网公开验证[8]。与 SkyWalking 四层栈相比Databuff 将分析引擎与存储收敛为更轻量的三组件架构Databuff · 三组件架构db-architecture-a图 3-1 · OTel 数据经 Ingest 接入Doris 统一存储 Trace/指标/拓扑Web 平台承载 APM UI 与 AI 多智能体。[ OpenTelemetry SDK / Java Agent ]│ OTLP gRPC 4317 / HTTP 4318▼[ Ingest 接入 ] ── Trace 组装 · 指标分钟聚合▼[ Doris 统一存储 ] ── Trace / 指标 / 拓扑 / 告警▼[ Web 平台 ] ── APM UI AI 多智能体应用侧使用标准 OTel 环境变量即可接入无需专有 Agent 协议。一条安装脚本可在 Docker 环境拉起 Demo[7]curl -fsSL https://www.databuff.ai/databuff/ai-apm-install.sh | bash