2. 分布式追踪基础：Trace、Span、SpanContext 核心概念与 OpenTelemetry 协议简介
在平台工程与 SRE 值班场景中，分布式追踪是定位跨服务故障与性能瓶颈的核心手段。本章从最基础的 Trace、Span、SpanContext 三个概念出发，逐步引入 OpenTelemetry 协议的设计思路，为后续标准化部署流程打下理论基础。
2.1 三大核心概念
分布式追踪的本质是记录一次请求在多个服务间的完整执行路径。以下三个概念构成了追踪数据模型的基础：
| 概念 | 英文 | 定义 | 类比（快递追踪） |
|---|---|---|---|
| Trace | Trace | 一次完整请求的端到端执行轨迹，由多个 Span 组成的有向无环图（DAG） | 一个快递从寄件到签收的完整物流记录 |
| Span | Span | Trace 中的一个工作单元，记录单一操作（如 RPC 调用、数据库查询）的开始、结束、状态与元数据 | 快递经过的每个（揽收、分拣、运输、派送） |
| SpanContext | SpanContext | 跨进程传递的追踪标识集合，包含 TraceID、SpanID、采样标记等，用于串联上下游 Span | 快递单号 + 当前站点编号 + 是否加急标记 |
2.2 Trace 与 Span 的关系模型
一个 Trace 由根 Span（Root Span）和若干子 Span（Child Span）组成。根 Span 代表请求的入口，子 Span 代表内部调用的细分步骤。每个 Span 通过 parent_span_id 指向其父 Span，形成层级结构。
- TraceID：全局唯一，标识一次完整请求，长度 16 字节（128 位），通常以 32 位十六进制字符串表示。
- SpanID：每个 Span 的唯一标识，长度 8 字节（64 位），16 位十六进制字符串。
- ParentSpanID：父 Span 的 SpanID，根 Span 此字段为空。
- SpanKind：Span 的角色类型（Client、Server、Producer、Consumer、Internal），用于区分调用方向。
下面通过一个内联 SVG 展示一次典型的三层微服务调用中 Trace 与 Span 的层级关系：
2.3 SpanContext：跨进程传递的纽带
SpanContext 是分布式追踪中最重要的“信使”。当服务 A 调用服务 B 时，必须将 SpanContext 通过 HTTP 头、gRPC 元数据或消息队列属性传递给下游，否则两个服务产生的 Span 将无法关联到同一个 Trace。
SpanContext 的核心字段：
- TraceID：全局唯一，下游服务必须原样传递。
- SpanID：当前 Span 的 ID，下游服务将其作为 ParentSpanID 使用。
- TraceFlags：采样标记（如
01表示已采样，00表示未采样）。 - TraceState：供应商特定的键值对，用于传递额外追踪上下文（如 W3C Trace Context 标准中的
tracestate）。
2.4 OpenTelemetry 协议简介
OpenTelemetry（简称 OTel）是 CNCF 孵化的可观测性标准，统一了分布式追踪、指标和日志的数据采集与导出协议。在追踪领域，OTel 定义了以下关键组件：
| 组件 | 作用 | 值班关注点 |
|---|---|---|
| OTel API | 提供 Tracer、Span 等编程接口，供应用代码调用 | 版本兼容性，API 与 SDK 版本需匹配 |
| OTel SDK | 实现 API，负责 Span 的创建、采样、上下文传播 | 采样率配置、Span 处理器（Processor）与导出器（Exporter） |
| OTel Collector | 独立代理服务，接收、处理、导出遥测数据 | 部署位置（Sidecar / DaemonSet）、内存与网络配置 |
| OTel Protocol (OTLP) | gRPC/HTTP 协议，定义 Span 数据的序列化与传输格式 | gRPC 端口 4317、HTTP 端口 4318，需确保网络可达 |
OTel 的追踪数据模型与 W3C Trace Context 标准（traceparent / tracestate 头）完全兼容，这意味着使用 OTel SDK 的应用可以自动与支持 W3C 标准的其他追踪系统（如 Jaeger、Zipkin）互操作。
下面通过一个内联 SVG 展示 OTel 追踪数据的采集与流转架构：
2.5 OTLP 协议核心要点
OTLP（OpenTelemetry Protocol）是 OTel 生态中所有组件之间通信的标准协议。值班团队需要掌握以下关键信息：
- 传输方式：支持 gRPC（默认端口 4317）和 HTTP/JSON（默认端口 4318）。gRPC 性能更高，HTTP 便于调试。
- 数据模型：使用 Protobuf 序列化，
ResourceSpans包含资源属性（如服务名、主机名），ScopeSpans包含 Instrumentation Scope（如库名、版本），Span包含 TraceID、SpanID、名称、开始/结束时间、属性、事件、状态等。 - 压缩：默认支持 gzip 压缩，建议在生产环境开启以减少网络带宽消耗。
- 重试与背压：OTel SDK 和 Collector 内置指数退避重试机制，Collector 支持基于内存队列的背压控制。
- 确认所有服务已注入 OTel SDK，并正确配置 OTLP 导出地址。
- 验证 Collector 的 4317/4318 端口在服务网络可达范围内。
- 检查 Span 数据是否包含完整的 TraceID 和 SpanID，避免因上下文传播缺失导致断链。
- 确认采样策略：生产环境建议使用基于错误率的自适应采样，而非固定比例采样。