3. 主流协议对比：OpenTracing、OpenCensus、OpenTelemetry 标准演进与选型

分布式追踪的标准化历程经历了从碎片化到统一的过程。理解 OpenTracing、OpenCensus 和 OpenTelemetry 三者的关系与差异，是选型与部署追踪系统的前提。本章从演进脉络、核心能力、协议差异和选型建议四个维度进行对比分析。

3.1 标准演进脉络

分布式追踪的标准化大致分为三个阶段：

• 第一阶段（2016-2019）：OpenTracing 由 CNCF 孵化，提供厂商无关的 API 规范，解决追踪数据采集的接口统一问题。
• 第二阶段（2018-2020）：OpenCensus 由 Google 和微软主导，聚焦于指标与追踪的联合采集，并提供内置导出器。
• 第三阶段（2019-至今）：OpenTelemetry 合并前两者，成为 CNCF 的毕业项目，统一了追踪、指标和日志的信号采集标准。

3.2 核心能力对比

下表从协议范围、数据模型、导出机制、语言支持和社区活跃度五个维度进行对比：

3.3 协议差异详解

三个标准在 Span 定义、上下文传播和采样策略上存在显著差异：

• Span 定义：
  • OpenTracing：Span 包含 operationName、startTime、duration、tags、logs、references。
  • OpenCensus：Span 包含 name、startTime、endTime、attributes、annotations、links、status。
  • OpenTelemetry：Span 包含 name、kind、startTime、endTime、attributes、events、links、status、resource。
• 上下文传播：
  • OpenTracing：使用 Tracer.inject() 和 Tracer.extract()，支持 TextMap、HTTPHeaders、Binary 格式。
  • OpenCensus：使用 PropagationComponent，支持 B3、TraceContext、Jaeger 格式。
  • OpenTelemetry：使用 Propagator 接口，默认支持 W3C TraceContext，同时兼容 B3、Jaeger、Zipkin 等格式。
• 采样策略：
  • OpenTracing：通过 Sampler 接口，支持 ConstSampler、ProbabilisticSampler、RateLimitingSampler。
  • OpenCensus：通过 Sampler 接口，支持 AlwaysSample、NeverSample、ProbabilitySampler。
  • OpenTelemetry：通过 Sampler 接口，支持 AlwaysOn、AlwaysOff、TraceIdRatioBased、ParentBased，并支持自定义 Sampler。

3.4 选型建议

基于当前技术生态和社区趋势，给出以下选型建议：

3.5 协议选型决策树

以下决策树可以帮助你在实际项目中快速确定协议选型：

1. 是否为新项目？
   • 是 → 直接选择 OpenTelemetry。
   • 否 → 检查现有追踪库。
2. 现有追踪库是什么？
   • OpenTracing → 使用 OpenTelemetry 的 OpenTracing 桥接库，逐步迁移。
   • OpenCensus → 使用 OpenTelemetry 的 OpenCensus 桥接库，逐步迁移。
   • 其他（如 Jaeger Thrift、Zipkin 原生） → 直接集成 OpenTelemetry SDK，配置对应 Exporter。
3. 是否需要同时采集指标和日志？
   • 是 → OpenTelemetry 统一采集，减少运维复杂度。
   • 否 → OpenTelemetry 仍是最佳选择，可以按需启用信号。
4. 是否需要与现有监控系统集成？
   • 是 → OpenTelemetry 提供丰富的 Exporter（Prometheus、Jaeger、Zipkin、Datadog 等）。
   • 否 → 使用 OTLP 协议，保持厂商无关。