←

技术博客

阅读约 6 分钟

OTel 统一可观测：SkyWalking 生态用户的开源 APM 选型指南

SkyWalking 生态用户 OTel 统一可观测路径：采集层 OTel 化、后端并存、四阶段路线图与开源 APM 选型要点。

SkyWalkingOpenTelemetry开源APM全链路追踪统一可观测

OTel 统一可观测：SkyWalking 生态用户的开源 APM 选型指南

SkyWalking 生态用户 OTel 统一可观测路径：采集层 OTel 化、后端并存、四阶段路线图与开源 APM 选型要点。

结论先行：统一可观测的正确拆法是采集层 OTel 化、后端可并存——SkyWalking 存量继续服务探针，新服务 OTLP 4317/4318 进评估后端；本文给出组织战略、并行对照与四阶段路线图。

1组织级 OpenTelemetry 战略怎么定

先写清「统一什么、不统一什么」，再动探针

技术委员会常把「上 OTel」误解成「立刻下线 SkyWalking」。更可行的战略是三层分离：

  • 采集层统一 — 应用只维护 OpenTelemetry SDK / Auto-Instrumentation，出口协议为 OTLP
  • 汇聚层可选 — OTel Collector 负责路由、采样、PII 脱敏、多租户属性注入
  • 后端可并存 — 并行期 SkyWalking OAP 与 OTLP 原生开源 APM 同时接收，按服务逐步切主
战略要素建议写法SkyWalking 存量怎么处理
唯一采集标准新服务必须 OTel；存量 12 个月内完成 Agent 替换旧 SW Agent 列入退役清单，禁止新接入
唯一传输协议OTLP gRPC 4317 优先；HTTP 4318 用于受限网络OAP 11800/12800 仅作并行期接收，非长期标准
后端解耦换后端不改应用，只改 Collector exporterCollector 双 export 到 OAP + 新 Ingest
AI / 问数入口统一 Web 或 MCP，避免 N 个 UI 值班Remote MCP 读 SW Open API 作过渡

边界声明：若团队重度依赖 Service Mesh 零代码覆盖、eBPF K8s 监控或四支柱一体且 OAP 运维体系成熟，继续以 SkyWalking 为主栈仍合理。本文路径面向「OTel 统一 + 运维减负 + AI 排障」三类诉求。

◆ ◆ ◆

2Agent / SDK 替换：从 SkyWalking 探针到 OTel

概念映射 + 分批顺序，避免「大爆炸」改启动参数

SkyWalking 侧OpenTelemetry 等价迁移注意点
agent.service_nameOTEL_SERVICE_NAME服务名保持一致，拓扑与告警规则才能对照
collector.backend_serviceOTEL_EXPORTER_OTLP_ENDPOINT指向 Collector 或 Ingest，如 http://<host>:4318
-javaagent:skywalking-agent.jar-javaagent:opentelemetry-javaagent.jar移除 SW Agent，避免双探针性能损耗
SW 插件开关OTEL_INSTRUMENTATION_*如 JDBC、Kafka 等价环境变量
SW 采样OTEL_TRACES_SAMPLER并行期可 100%；切流后用 parentbased_traceidratio

Java 微服务替换示例（最常见第一批）：

# 替换前 java -javaagent:/path/skywalking-agent.jar \ -Dskywalking.agent.service_name=order-service \ -Dskywalking.collector.backend_service=oap:11800 \ -jar order-service.jar # 替换后 export OTEL_SERVICE_NAME=order-service export OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector:4318 export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf export OTEL_RESOURCE_ATTRIBUTES=deployment.environment=prod java -javaagent:opentelemetry-javaagent.jar -jar order-service.jar

SkyWalking 自 v9 起支持 OTLP Trace 接收——短期无法改 Agent 时，可让 Collector 把 OTLP 转发至 OAP，但长期仍建议应用直出 OTLP，减少中间格式转换。

推荐分批顺序：边缘 BFF / 网关 → 非核心后台 → 核心交易链路。每批只动采集层，后端保持双接收直到对照期通过。

◆ ◆ ◆

3并行对照期：验证「数据对等」再切主

迁移成败取决于可量化对照，而非新 UI 能打开

阶段 A · 部署对照后端（约 1 周） 拉起 OTLP 原生开源 APM；确认 4317/4318 与 Web 27403 可达 ↓ 阶段 B · Collector 双 export（约 2–4 周） 一路 → SkyWalking OAP :11800；一路 → 新 Ingest :4317 ↓ 阶段 C · 固定窗口对比（约 1–2 周） 压测 / 回放流量；核对 Trace 量、错误率、P95、拓扑边 ↓ 阶段 D · 按服务切主 告警与值班视图迁移；OAP _exporter 从 Collector 摘除
对照项通过标准（示例）
服务注册两平台服务列表差异 < 5%
Trace / Span 量同一小时计数偏差 < 10%
错误率曲线形态一致，无系统性偏高/偏低
黄金链路 P993–5 条关键接口偏差 < 15%
拓扑完整性上下游边无缺失
图 1 · 并行期：全局拓扑应与 SkyWalking UI 中的依赖关系大体一致

图 1 · 并行期：全局拓扑应与 SkyWalking UI 中的依赖关系大体一致

图 1 · 并行期：全局拓扑应与 SkyWalking UI 中的依赖关系大体一致

图 2 · 链路追踪列表 — 核对 Trace 总量、慢请求分布是否与原平台同量级

图 2 · 链路追踪列表 — 核对 Trace 总量、慢请求分布是否与原平台同量级

图 2 · 链路追踪列表 — 核对 Trace 总量、慢请求分布是否与原平台同量级

◆ ◆ ◆

4何时引入 Databuff 作为 OTLP 原生后端

additive 共存：不是「二选一」，而是在战略匹配时加一轮并行评估

你的组织状态是否建议并行评估 Databuff理由
已确定 OTel 为唯一采集标准，后端待选型是OTLP 为唯一接入；gRPC 4317 / HTTP 4318 与 Collector 规划一致
OAP + ES/BanyanDB 运维占用大量 SRE，无专职团队是Ingest + Doris + Web 三组件；Demo 约 8G 内存可跑
需要对话式查 Trace、MCP 接 IDE 的 AI 排障是AI 原生问数；可与 Remote MCP 读 SkyWalking 过渡共存
Mesh/eBPF 零代码覆盖是核心诉求，Agent 改动困难暂缓继续发挥 SkyWalking 基础设施探针优势
存量 Agent 稳定，无 OTel 规划与后端减负诉求观望无驱动力时不应为了换而换

Databuff 与 SkyWalking 的差异不在「能不能做全链路追踪」，而在接入模型与运维面：前者 OTLP 唯一入口 + 三组件 + AI/MCP；后者成熟社区 + 四支柱 + 多存储选型。并行期两者同时接收 Trace，用 §3 对照表做决策，而非营销话术。

新平台默认端口（与 Collector exporter 对齐）：

  • OTLP gRPC：4317
  • OTLP HTTP：4318（路径 /v1/traces）
  • Web 控制台：27403

过渡期若暂不能下线 OAP，可采用「数据面 OTLP 统一 + 查询面 Remote MCP」：Databuff Web 通过 MCP 读 SkyWalking Open API，值班只开一个控制台。

◆ ◆ ◆

5四阶段路线图（SkyWalking → OTel 统一）

12 个月视角的渐进路径，每阶段有明确退出标准

阶段时间盒动作退出标准
① 战略对齐2–4 周发布 OTel 采集标准；新服务禁 SW Agent；选型 1–2 个试点服务架构评审签字；Collector 骨架上线
② 采集替换1–3 月分批改 OTel Agent；Collector 双 export试点服务 §3 对照表全绿
③ 后端切主3–6 月告警/看板迁移；按服务摘 OAP exporter80% 核心服务值班视图已切换
④ 统一入口6–12 月OAP 只读或下线；AI/MCP 统一问数On-call 单入口；SW 仅历史归档

整条路径的核心原则：应用侧先 OTel 化，后端侧 additive 并行，切主靠数据对照而非行政命令。SkyWalking 在并行期继续提供可信基准，Databuff 等 OTLP 原生方案提供更轻的运维面与 AI 能力增量——验证通过后再收敛，而非一次性「大爆炸」。

◆ ◆ ◆

6常见问题

问题简要回答
OTel 统一是否等于下线 SkyWalking？否。采集统一 + 后端并存是更稳妥路径。
统一路径第一步做什么？写清三层战略：采集统一、Collector 可选、后端可并存。
选型何时引入 OTLP 原生 APM？OTel 战略明确且需降运维面或补 AI 问数时。

◆ ◆ ◆

行业视角下，Gartner 指出 outages 与性能劣化直接冲击营收与品牌；组织级 Legacy APM → OTel 战略的价值在于提升关键数字业务的可用性、性能与韧性。

◆ ◆ ◆

7引用资料

  • [1] : https://opentelemetry.io/docs/concepts/observability-primer/
  • [2] : https://skywalking.apache.org/docs/main/latest/en/setup/backend/otlp-trace/
  • [3] : https://opentelemetry.io/docs/specs/otlp/
  • [4] : https://skywalking.apache.org/docs/main/latest/en/concepts-and-designs/overview/
  • [5] : https://opentelemetry.io/docs/collector/configuration/
  • [6] : https://github.com/databufflabs/databuff?utm_source=article&utm_medium=web&utm_campaign=viral-10

◆ ◆ ◆

◆ ◆ ◆

了解更多：github.com/databufflabs/databuff