从 SkyWalking 迁移 OpenTelemetry：双栈共存与全链路追踪实战

SkyWalking · 开源 APM · OpenTelemetry · Databuff · 全链路追踪

结论先行：不必一次性下线 SkyWalking——先把应用侧采集切到 OTel SDK/Collector，用 OTLP 双出口并行验证全链路追踪，再逐步把新流量接到 OTLP 原生开源 APM。本文给出采集替换、Checklist 与 Remote MCP 过渡期共存方案。

1什么时候该启动 SkyWalking → OTel 迁移

迁移不是否定 SkyWalking 的价值，而是当组织战略变化时，把全链路追踪接入层对齐到新目标

Apache SkyWalking 是 ASF 顶级项目，Probe + OAP + Storage + UI 四层架构在 Trace / Metrics / Logs 上生态成熟。许多团队并非「弃用」，而是在以下节点评估双栈共存——存量继续 SkyWalking，新服务走 OpenTelemetry。

触发场景	典型痛点	迁移方向
OTLP 统一战略	同时维护 SkyWalking Agent 与 OTel SDK，换后端就要改探针	采集层统一到 OpenTelemetry，后端只认 OTLP gRPC 4317 / HTTP 4318
AI 原生运维	缺少对话式查 Trace、MCP 对接 IDE 工作流	评估 AI Native 开源 APM：LLM 查 Trace 与指标，Remote MCP 过渡期读存量
组件与运维减负	OAP + ES/BanyanDB 等多组件，存储升级占用 SRE 精力	后端收敛为 Ingest + Doris + Web 三组件，一键脚本分钟级 POC

推荐路径：并行双写验证 → 告警与看板逐步切换 → Remote MCP 过渡期读旧平台——而非一次性下线 OAP。若团队重度依赖 Mesh/eBPF 零代码覆盖，继续以 SkyWalking 为主栈仍合理。

层级	SkyWalking 典型形态	迁移后（Databuff 示例）
应用采集	SkyWalking Java/Node Agent	OTel SDK / Auto-Instrumentation，标准 OTLP 出口
可选汇聚	Agent → OAP（11800/12800 等）	OTel Collector（可选）→ Ingest 4317/4318
后端存储	ES / BanyanDB / H2 等	Apache Doris 统一存 Trace + 指标
控制台	SkyWalking UI	Web UI（27403）+ AI 平台 + MCP

一键安装：curl -fsSL https://databuff.ai/databuff/ai-apm-install.sh | bash。Ingest 默认暴露 OTLP 端口 4317（gRPC）与 4318（HTTP）。

◆ ◆ ◆

2数据采集层：SkyWalking Agent → OpenTelemetry

先理解映射关系，再按语言分批改启动参数或 Collector 路由

SkyWalking 侧	OTel 侧等价物	迁移注意点
`agent.service_name`	`OTEL_SERVICE_NAME`	服务名保持一致，便于拓扑与告警对照
`collector.backend_service`	`OTEL_EXPORTER_OTLP_ENDPOINT`	指向 Ingest：`http://<host>:4318`
`-javaagent:skywalking-agent.jar`	`-javaagent:opentelemetry-javaagent.jar`	移除 SW Agent，避免双探针性能损耗
SW 采样	`OTEL_TRACES_SAMPLER`	并行期可 100% 采样，切流后再调 `parentbased_traceidratio`

替换前（SkyWalking Agent）：

java -javaagent:/path/skywalking-agent.jar \
  -Dskywalking.agent.service_name=order-service \
  -Dskywalking.collector.backend_service=oap:11800 \
  -jar order-service.jar

替换后（OTel Java Agent → Databuff Ingest）：

export OTEL_SERVICE_NAME=order-service
export OTEL_EXPORTER_OTLP_ENDPOINT=http://<ingest-host>:4318
export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf

java -javaagent:opentelemetry-javaagent.jar -jar order-service.jar

SkyWalking 自 v9 起支持 OTLP Trace 接收——短期不能改 Agent 时，可让 OTel Collector 一份 OTLP 进、两路出。长期仍建议应用直出 OTLP。

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

exporters:
  otlp/skywalking:
    endpoint: oap:11800
    tls:
      insecure: true
  otlp/databuff:
    endpoint: <ingest-host>:4317
    tls:
      insecure: true

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [otlp/skywalking, otlp/databuff]

OAP OTLP 端口以实际部署为准。Collector 双出口比应用双探针更省 CPU。

◆ ◆ ◆

3并行运行与数据对比验证

迁移成败取决于「可量化的对等性」，而非「新 UI 能打开」

步骤 1 — 安装 Databuff 三组件，确认 4317/4318 与 27403 可达
        ↓
步骤 2 — Collector 双出口或灰度 Pod 只向 Databuff 上报
        ↓
步骤 3 — 固定压测 / 回放流量，同一时段对比两平台
        ↓
步骤 4 — Checklist 签字后再切告警与值班视图
        

#	验证项	通过标准（示例）
1	服务注册完整性	两平台服务列表差异 < 5%
2	Trace 量	同一小时 Span 计数偏差 < 10%
3	错误率 / P95	关键接口趋势一致，偏差可解释
4	拓扑边	上下游依赖无缺失边、无幽灵节点
5	慢 Trace 可下钻	Top N 慢请求在两平台均可定位 Span

图 1 · 步骤 3 对照 — 核对服务列表是否完整注册（验收项 ①：两平台服务差异 < 5%）

图 2 · 步骤 3 对照 — 核对上下游边与中间件节点无缺失（验收项 ④：拓扑边一致）

图 3 · 以入口服务 service-a 为锚点，验证调用链分解与响应贡献度是否可解释延迟来源

图 4 · 链路追踪概览 — 对比 Trace 数量与 P50–Max 响应时间分布（验收项 ②③：Span 计数与分位趋势）

图 5 · 慢 Trace 下钻 — 调用次序瀑布图可定位 Redis / MySQL / 下游服务等 Span（验收项 ⑤）

推荐排查路径：服务列表确认注册 → 全局拓扑发现缺失边 → 服务流确认入口链路 → 链路追踪下钻慢 Span。

◆ ◆ ◆

4双栈共存收尾：历史数据 · 告警 · Remote MCP

Trace 难以「无损搬家」——重点是留存只读访问与规则语义对齐

策略	做法	适用场景
双栈只读并存	SkyWalking 缩容为只读 30–90 天；新数据只进 Databuff	合规保留历史、审计回溯
硬切无回迁	并行验证通过后下线 OAP，历史随 TTL 过期	POC / 非生产

SkyWalking 存储后端多样（ES、BanyanDB 等），不存在通用「一键导入」工具。生产环境多采用双栈只读：新平台承担实时应用性能监控，旧平台只读兜底。

告警切流顺序：先在 Databuff 创建静默规则观察 3 天 → 对比噪声率 → 再打开通知并关闭 SW 对应规则，避免双倍 paging。

并行期值班要在两个 UI 间切换。Databuff 支持 Remote MCP：把 SkyWalking Open API 注册为外部 Tool，AI 对话可同时查询 Doris 中的 OTLP 数据与 SkyWalking 存量——「一个聊天窗口、两套后端」。

阶段	时长（参考）	采集	值班视图
P0 POC	1–3 天	单服务 OTel 上报	仅 Databuff 验证
P1 并行	2–4 周	Collector 双出口	SW 主 + Databuff 对照
P2 切主	1–2 周	全量 OTel，SW Agent 下线	Databuff 主告警
P3 收尾	按留存策略	仅 OTLP	SW 只读或下线

◆ ◆ ◆

5常见问题

问题	简要回答
迁移一定要停 SkyWalking 吗？	不需要。推荐 Collector 双出口，SkyWalking 与 OTLP 后端并行接收，对照验证后再切主。
OTLP 端口用 4317 还是 4318？	HTTP 4318 对 Demo 与多数 SDK 最友好；gRPC 4317 适合高吞吐生产。
并行期告警以谁为准？	P1 阶段以 SkyWalking 为主告警，Databuff 做对照；P2 切主后再迁移告警规则。

◆ ◆ ◆

行业视角下，Gartner 认为可观测性平台须分析多类遥测以识别影响终端用户体验的行为变化；迁移实战中的服务列表、拓扑、服务流与 Trace 瀑布对照，正是把 Gartner 所强调的「用户体验锚点」落实为可签字验收的 Checklist。。

◆ ◆ ◆

6引用资料

[1] : https://skywalking.apache.org/docs/main/latest/en/concepts-and-designs/overview/
[2] : https://skywalking.apache.org/docs/main/next/en/setup/ai-pipeline/introduction/
[3] : https://databuff.ai/databuff/ai-apm-install.sh
[4] : https://skywalking.apache.org/docs/main/latest/en/setup/backend/otlp-trace/
[5] : https://skywalking.apache.org/docs/skywalking-banyandb/latest/concept/clustering/
[6] : https://github.com/databufflabs/databuff?utm_source=article&utm_medium=web&utm_campaign=viral-03
[7] : https://www.gartner.com/reviews/market/observability-platforms (Gartner Observability Platforms 市场定义与能力说明)

◆ ◆ ◆

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