主流追踪系统对比：Jaeger、Zipkin、SkyWalking、Datadog
说句实话，选追踪系统这事，坑真的不少。我自己前前后后用过三四套方案，踩过存储爆掉的坑，也遇到过采样率设错导致关键调用链丢失的尴尬。你想想看，分布式链路追踪解决的是“查问题慢”的问题，但如果工具本身选错了，反而会引入一堆新麻烦。
系统选型没有银弹。我习惯从四个维度去评估：部署成本、数据量级、查询灵活性、生态兼容性。下面我把市面上最主流的四个方案拆开来讲，把各自的优点和痛点都说清楚。
Zipkin——轻量级的老牌选手
Zipkin 是 Twitter 开源的项目，讲道理，它在 2015 年前后几乎是链路追踪的代名词。我刚开始接触分布式追踪时，第一套实践方案就是 Zipkin + Brave。
优点：
- 部署极其简单。 单节点几分钟就能跑起来，适合做概念验证。我曾经在一台 2C4G 的机器上同时跑了 Collector、Query 和 UI，扛住了日均 200 万 span 的压测。
- 客户端库覆盖广。 官方支持 Java、Go、Python、Ruby 等，社区还有 C#、PHP 的实现。你如果项目语言杂，Zipkin 的适配成本很低。
- 体系成熟，文档齐全。 遇到问题搜 stackoverflow 基本都有答案。
缺点：
- 存储选择性有限。 原生支持 Elasticsearch、Cassandra、MySQL。但你想想看，MySQL 存调用链简直是在开历史倒车，ES 和 Cassandra 才是正解。可一旦数据量到了 TB 级，ES 的写性能就成了瓶颈。
- 缺乏采样策略灵活性。 我记得有次排查一个问题，因为默认采样率设得太低（0.01%），导致关键慢调用根本没落库，查了个寂寞。
- 没有告警和聚合分析。 它就是个单纯的数据展示工具，你想做基于调用链的失败率告警？抱歉，得自己对接 Prometheus。
适用场景： 小团队起步、研发环境调试、不想引入太重运维负担的团队。如果日调用链数据量在 1TB 以下，Zipkin 完全够用，性价比很高。
Jaeger——云原生的宠儿
Jaeger 是 Uber 捐给 CNCF 的项目，一路走到了毕业状态。我目前的主力追踪系统就是它。为什么？因为它跟 Kubernetes 生态融合得特别好。
优点：
- 原生 OpenTelemetry。 Jaeger 是早期支持 OpenTracing 的标杆，现在全面拥抱 OpenTelemetry。我建议你用 Jaeger 就直接走 OTLP gRPC 上报，性能比 HTTP-JSON 高出一大截。
- 多存储后端。 支持 Elasticsearch、Cassandra、Badger、Kafka。Badger 嵌入式的方案很有意思，做单机验证不用搭 ES。我自己在本地开发环境就用 Badger，省心。
- 采样策略灵活。 支持基于 head 的固定采样、概率采样、速率采样，还能通过配置中心动态调整。我曾经在线上把某个核心接口的采样率临时从 0.01% 提到 10%，一分钟后就找出了内存泄漏的根因。
- Spark 集成做依赖分析。 可以画出服务依赖图，调用关系一目了然。
缺点：
- UI 功能偏弱。 说实话，Jaeger 的查询页面用起来不太顺手，筛选条件少，没法做深度的聚合统计。对比一下 SkyWalking 的拓扑图，差距蛮大的。
- 资源占用中等偏上。 Agent 侧还好，但 Collector 和 Query 组件如果没配置好，内存很容易飙升。我踩过 collector 不限制内存，直接 OOM 的坑。
- Elasticsearch 版本适配问题。 Jaeger 对 ES 版本很敏感，升级 ES 时经常要同步升级 Jaeger，否则数据索引会异常。
踩坑提醒： 如果你用 Jaeger 的 gRPC 上报，记得关注客户端的重试和超时设置。曾经某次 Collector 节点滚动重启，所有 Agent 同时重连，大量重复 span 写入 ES，直接把集群写挂了。建议加一层 Kafka 做缓冲。
SkyWalking——天生的APM选手
SkyWalking 是中国开源界的代表作品，吴晟团队的贡献很大。它的定位不是纯粹的追踪，而是 APM（应用性能管理）。说白了，它把链路追踪、指标监控、告警统统打包了。
优点：
- 无侵入探针。 基于 Java Agent 或 .NET Core 的诊断 API，一行代码都不用改就能接入。对于遗留系统或停止维护的服务，这简直是救命稻草。我迁移过一个跑了 6 年的老项目，用 SkyWalking 的 agent 挂上，十分钟就看到调用链了。
- 完整的 APM 能力。 包含服务拓扑、JVM 监控、数据库调用分析、端点慢查询等。一个界面解决所有问题，不用切到 Prometheus 再查一遍。
- 多语言支持。 Java、.NET、Go、Node.js、PHP 等都有 agent。Go 版的 agent 采用 eBPF 方式集成，性能损耗很低。
- 告警引擎内置。 支持基于规则（如错误率 > 10% 持续 3 分钟）的告警，对接钉钉、邮件、Webhook 很方便。
缺点：
- 学习和运维复杂度高。 组件太多了：OAP Server、UI、Storage、Agent、Receiver。我第一次搭建时花了一整天才跑通全链路。小型团队慎入。
- 定制化难度大。 底层协议是自家的，如果想扩展自定义埋点或接入非官方语言，需要自己写 receiver 和 parser，工作量不小。
- 生态偏向 Java。 虽然支持多语言，但 Java Agent 体验最好，其他语言的 Agent 功能相对简化。比如 Node.js 的 Agent 对异步调用链支持就不太完美。
Datadog——SaaS集成王者
Datadog 是商业产品里做得最好的。如果你预算充足，又不想自建维护，直接上 Datadog 真的省心。我见过不少中大型企业，买 Datadog 的 APM 加日志管理套餐，业务方反馈非常好。
优点：
- 分钟级接入。 安装一个 Agent，配置好 ，链路数据就自动上报了。不需要操心 Collector、Storage、UI 的任何运维问题。
- 全栈可观测性。 追踪、日志、指标、基础设施监控、网络、安全检测，全在一个平台联动。我遇到过最爽的场景：查 CPU 飙升，点开容器指标，关联到慢 span 日志，再跳到异常堆栈，全程不离开 Datadog。
- 强大的可视化。 火焰图、服务图谱、依赖分析、动态标签聚合，查询语言灵活。尤其是它的 Trace-Search，支持用标签和布尔逻辑组合过滤，很强大。
- 自动化关联。 Datadog 可以自动把 APM 和 Infrastructure 关联起来，比如某个 Pod 内存被打满，自动关联那段时间的调用链。
缺点：
- 成本高。 按 span 条数 + Host 数 + 日志流量三重计费。我见过一个月花 10 万美元的案例。小公司慎入，不然月底看到账单会心梗的。
- 数据主权和安全问题。 所有数据都要传到 Datadog 的 AWS 云上。如果公司有数据合规要求（比如金融、政务），这条路基本走不通。
- Agent 资源占用。 Datadog Agent 功能太全了，走全量采集时 CPU 占用率可能到 5%~8%。我优化过一轮，把不需要的集成模块删掉，降到 2% 左右。
选型建议总结
说回选型，我觉得没有标准答案，但可以给出几条我自己的判断原则，你结合实际看看：
| 选型维度 | Zipkin | Jaeger | SkyWalking | Datadog |
|---|---|---|---|---|
| 部署成本 | 低，单机可跑 | 中，需 Collector 和 ES | 高，组件多 | 无需部署，SaaS |
| 数据规模支持 | 中等（TB 级） | 良好（多存储扩展） | 良好（支持 ES / TiDB） | 不限（按量付费） |
| 查询灵活性 | 一般 | 良好 | 优秀 | 优秀 |
| APM 能力 | 基本没有 | 弱（依赖外部系统） | 强，内置告警 | 强，全栈可观测 |
| 运维工作量 | 低 | 中 | 高 | 极低 |
| 成本 | 0（开源） | 0（开源） | 0（开源） | 高（按量计费） |
| 推荐团队 | 初创/小团队 | 云原生/k8s 团队 | Java 为主 / APM 一体化 | 预算充足 / 不想自建 |
我的一点建议： 如果团队刚起步，日 span 量少于 500 万，Zipkin + ES 是最快的起点。如果已经在用 Kubernetes，直接上 Jaeger + OpenTelemetry，未来拓展性更强。如果需要 APM 一体化和告警闭环，SkyWalking 是首选。预算上不封顶、不想碰运维，直接签 Datadog 的合同，省下来的研发时间远比工具费贵。
总结一下，没有完美的工具，只有合适的场景。你想想看，做链路追踪的最终目的是快速定位故障，而不是折腾工具本身。所以我的原则是：选能让你安心写业务代码而不焦虑运维的那套方案。