OpenTracing 是一个分布式链路追踪（Distributed Tracing）的行业标准接口规范。它不提供具体的实现，而是定义了一套 API，让开发者能够以统一的方式在代码中进行埋点。
核心概念
OpenTracing 的数据模型可以概括为以下三个关键术语：
| 术语 | 定义 |
|---|---|
| Trace (追踪) | 一个完整请求在分布式系统中的全路径。逻辑上可以看作是由多个 Span 组成的有向无环图 (DAG)。 |
| Span (跨度) | 链路中的最小工作单元。代表了系统中的一个逻辑操作（如一次 RPC 调用、一次数据库查询）。 |
| SpanContext | 携带跨服务传递的状态信息（如 Trace ID, Span ID），用于将不同服务的 Span 串联起来。 |
为什么需要 OpenTracing？
在没有统一规范之前，每个链路追踪系统（如 Zipkin, Jaeger）都有自己的 API。这导致了以下问题：
- 厂商锁定：一旦选择了某个追踪系统，业务代码中就会充斥着该系统的私有 API。如果想更换系统，需要重写所有埋点。
- 库/框架适配困难：开源框架（如 gRPC, Gin）很难为每一个追踪系统都写一套适配代码。
OpenTracing 的价值：解耦了“埋点代码”与“追踪系统实现”。业务代码只依赖 OpenTracing API，底层实现可以像换插件一样随时更换。
业务团队与基础架构的协作
在实际落地中，链路追踪通常由基础架构团队和业务团队共同维护：
- 基础架构团队 (Infrastructure)：
- 搭建追踪后端（如 Jaeger 集群、Elasticsearch 存储）。
- 提供通用插件（如 HTTP 中间件、RPC 拦截器）实现自动埋点。
- 业务团队 (Business)：
- 手动埋点：记录业务内部的关键逻辑耗时（如复杂算法、循环处理）。
- 上下文传递：在异步调用（线程池、消息队列）中确保
SpanContext不丢失，维持链路完整。
现状：OpenTelemetry
OpenTracing 目前已经进入 CNCF 归档状态，并与 OpenCensus 合并为 OpenTelemetry。
关于 OpenCensus
OpenCensus 是由 Google 发起并开源的一套库，它的侧重点与 OpenTracing 有所不同：
- 不仅是 API：OpenCensus 不仅定义了规范，还提供了多语言的 SDK 库（如 Go, Java, C++），开发者可以直接集成。
- 多维观测：除了链路追踪 (Tracing)，它还内置了对指标 (Metrics) 的支持，这在当时是一个巨大的优势。
- 内置导出器：它自带了许多后端导出器 (Exporters)，可以直接将数据推送到 Stackdriver, Prometheus, Zipkin 等。
合并的必然性：由于 OpenTracing 强于规范和生态适配，而 OpenCensus 强于实现和多维数据，两者的合并标志着观测性领域从“百家争鸣”走向了“大一统”的 OpenTelemetry 时代。