技术选型对比：OpenTelemetry vs Zipkin vs Jaeger vs SkyWalking
做溯源链路搭建，第一件事就是选工具。这个坑我踩过两回——第一次选了过重的方案，团队没人能hold住；第二次选了太轻的，排查问题又差点意思。所以今天咱们把市面上主流的四款工具拉出来，硬碰硬比一比。
先看选手阵容
这四个家伙都不是等闲之辈。我按自己的习惯分了个类：
- OpenTelemetry – 不是具体产品，而是一套标准+SDK集合。它统一了数据采集格式，背后是CNCF和各大云厂商。
- Zipkin – 老牌分布式追踪系统，Go语言写的，Twitter开源。主打轻量、极简。
- Jaeger – Uber开源，同样是CNCF项目。功能比Zipkin丰富，自带UI和存储策略。
- SkyWalking – 中国团队主导，Apache顶级项目。除了追踪，还管性能监控和日志。
我的经验：如果你团队里有人用过Zipkin，那迁移到Jaeger上手很快。Zipkin的API在Jaeger里几乎都兼容。
核心能力对比
我做过一个内部选型表，这里把它整理出来。注意看黑体字部分——那是最容易踩坑的点。
| 维度 | OpenTelemetry | Zipkin | Jaeger | SkyWalking |
|---|---|---|---|---|
| 数据格式 | OTLP（自研） | JSON/Thrift | Protobuf | 自研gRPC/HTTP |
| 部署复杂度 | 低（仅SDK+Collector） | 低（单jar/docker） | 中（需配置存储后端） | 高（需OAP、存储、UI三大件） |
| 存储支持 | 可插拔（内存/ES/Cassandra等） | 内存/ES/Cassandra | 内存/ES/Badger/Cassandra | ES/H2/MySQL/PostgreSQL |
| 链路采样 | Head-Based + 可扩展 | 采样率可配置 | Head/Tail/K8s聚合采样 | 自适应采样+采样率规则 |
| 报警接入 | 无内置报警 | 无内置报警 | 通过Alertmanager集成 | 内置报警规则+Webhook |
| 多语言SDK完整度 | ★★★★★ | ★★★★ | ★★★★ | ★★★（Java/Go/.NET为主） |
| 学习曲线 | 中（概念多） | 低（API风格直观） | 中（功能多但文档全） | 中高（Agent配置复杂） |
避坑指南：我曾经在一个微服务项目里直接上了SkyWalking全套，结果因为业务方需要跨语言（PHP+Node.js），但SkyWalking对PHP的支持还停留在实验阶段，最后不得不切回Jaeger。多语言场景下，OpenTelemetry或者Jaeger更稳妥。
时序图：选型决策流程
下面这张图帮你快速判断：你的团队规模和技术栈决定该选谁。
具体场景怎么选
我总结了一套粗暴但管用的法则：
- 新项目，未来要接云原生 – 直接上OpenTelemetry。别管Zipkin或者Jaeger多顺手，OTel是未来方向。接入成本不高，后面换后端存储也灵活。
- 历史包袱重，团队小 – Zipkin最省心。十分钟跑起来，SDK也简单。缺点是功能太少，查询不太方便。
- 中型团队，需要成熟方案 – Jaeger是均衡之选。采样策略丰富，UI比Zipkin好用，社区活跃。我上一家公司就靠它撑了两年。
- 喜欢全家桶，要求报警和拓扑 – SkyWalking。只要你的技术栈以Java/Go为主，而且愿意费点劲配置agent，它给你的是一个完整的APM平台，不止追踪。
一句话总结：没有最好的工具，只有最合适的。选型前先画清楚你们团队的“能力边界”和“未来半年要解决的痛点”。如果拿不准，先从OpenTelemetry标准开始，后面切换后端存储无非改个Collector配置。
别忘了兼容性
我在项目里犯过一个低级错误：选了SkyWalking，但对接方用的是Jaeger协议。后来不得不加一层转换代理，延迟一下就上去了。所以选型时多问自己一句：上下游系统怎么传trace？
核心数据流长这样：
应用A（SDK） ——> 本地Agent/Collector ——> 后端存储 ——> UI查询只要中间交换协议统一（比如都支持OTLP），后续换后端或UI都方便。这也是为什么现在很多公司以OpenTelemetry作为“总线”，后面自由组合Jaeger做UI、Elasticsearch做存储——嗯，各取所长。
我的经验：如果你初步选定Zipkin或Jaeger，我建议在SDK层还是走OTel协议。这样以后想换SkyWalking或者自己搭，迁移工作几乎为零。