4、分布式追踪基础：Trace与Span的概念、TraceId与SpanId的传播机制、OpenTelemetry标准简介

4.1 Trace 与 Span：分布式追踪的原子单元

在分布式系统中，一次完整的业务请求（例如用户下单、支付回调）会穿越多个微服务、中间件和数据库。分布式追踪的核心任务就是将这条请求路径完整地还原出来。为此，业界抽象出两个基础概念：Trace（追踪）和 Span（跨度）。

Span 的生命周期包含四个核心事件：Start（开始）、End（结束）、Error（错误记录）、Event（自定义事件）。在 MTTR 复盘场景中，我们重点关注 Span 的 Duration（耗时）和 StatusCode（状态码），它们是判断服务是否出现性能劣化或错误的关键指标。

4.2 TraceId 与 SpanId 的传播机制

分布式追踪的核心挑战在于：如何在跨进程、跨线程的调用中，将同一个 Trace 的上下文信息（Context）传递下去。这依赖于两个关键 ID 的传播：TraceId 和 SpanId。

4.2.1 核心 ID 定义

• TraceId：全局唯一的 128-bit 或 64-bit 标识符，用于标记一次完整的请求链路。所有参与该请求的服务和 Span 共享同一个 TraceId。
• SpanId：每个 Span 的唯一标识符，64-bit。用于在 Trace 内部定位具体的操作单元。
• ParentSpanId：当前 Span 的父 Span 的 SpanId。通过这个字段，所有 Span 可以串联成完整的调用链。

4.2.2 传播机制：W3C TraceContext 标准

业界主流采用 W3C TraceContext 标准来传播追踪上下文。该标准定义了两种 HTTP 头：

4.3 OpenTelemetry 标准简介

OpenTelemetry (OTel) 是 CNCF 旗下的可观测性标准，旨在统一分布式追踪、指标和日志的采集与导出。它解决了过去 OpenTracing 和 OpenCensus 两个标准分裂的问题，成为业界事实标准。

4.3.1 OpenTelemetry 核心组件

4.3.2 OpenTelemetry 追踪数据模型

OTel 的追踪数据模型与 W3C TraceContext 完全对齐，并扩展了更丰富的语义：

• SpanKind：标识 Span 的角色（CLIENT、SERVER、PRODUCER、CONSUMER、INTERNAL），帮助理解调用方向。
• Attributes：键值对标签，用于附加业务元数据（如 http.method、db.system、user.id）。
• Events：带时间戳的日志事件，用于记录异常、断点等关键信息。
• Links：允许一个 Span 关联到其他 Trace 的 Span，适用于异步消息、批处理等复杂场景。

4.3.3 一个完整的 Span 数据结构示例（JSON）

{
  "traceId": "0af7651916cd43dd8448eb211c80319c",
  "spanId": "b7ad6b7169203331",
  "parentSpanId": "9c8d7e6f5a4b3c2d",
  "name": "HTTP GET /api/orders",
  "kind": "SERVER",
  "startTimeUnixNano": "1678901234567890000",
  "endTimeUnixNano": "1678901234567890500",
  "attributes": {
    "http.method": "GET",
    "http.url": "https://api.example.com/orders",
    "http.status_code": 200,
    "service.name": "order-service"
  },
  "events": [
    {
      "timeUnixNano": "1678901234567890200",
      "name": "exception",
      "attributes": {
        "exception.type": "TimeoutException",
        "exception.message": "Connection timed out"
      }
    }
  ],
  "status": {
    "code": "ERROR",
    "message": "Database timeout"
  }
}