2. OpenTelemetry 核心概念回顾：Trace、Span、Metrics、Logs 与 Context 传播

在深入 Mock 依赖隔离与性能优化之前，必须重新校准对 OpenTelemetry（OTel）核心数据模型的理解。OTel 并非简单的“链路追踪工具”，而是一个统一的可观测性数据面标准。本章将聚焦于三大信号（Trace、Metrics、Logs）及其底层支撑机制——Context 传播，为后续的 Mock 注入与性能压测建立共同语言。

2.1 三大信号与 Span 的基石地位

OTel 将可观测性数据归纳为三种信号（Signal），它们共享相同的元数据模型与传播机制：

其中 Span 是 OTel 数据模型的基石。一个 Trace 由一个或多个 Span 组成，每个 Span 代表一个具有开始时间、结束时间、属性（Attributes）、事件（Events）和状态（Status）的工作单元。

2.2 Span 的完整生命周期与属性结构

一个 Span 从创建到结束经历以下阶段，每个阶段都可能成为 Mock 注入的切入点：

1. Span 创建（Start）：从 Context 中提取父 Span，生成新的 SpanContext，分配 TraceId 与 SpanId。
2. 属性注入（Attributes）：添加业务标签（如 HTTP 方法、状态码、数据库语句）。
3. 事件记录（Events）：记录带时间戳的异常或关键日志。
4. Span 结束（End）：记录结束时间，计算耗时，将 Span 导出到 Processor。

以下是一个典型的 Span 结构示例（Java SDK 伪代码）：

Span span = tracer.spanBuilder("processOrder")
    .setSpanKind(SpanKind.SERVER)
    .setAttribute("order.id", "12345")
    .setAttribute("payment.method", "credit_card")
    .start();

try (Scope scope = span.makeCurrent()) {
    // 业务逻辑
    Thread.sleep(100);
} catch (Exception e) {
    span.recordException(e);
    span.setStatus(StatusCode.ERROR);
} finally {
    span.end();
}

2.3 Context 传播：连接所有信号的隐形管道

Context 传播是 OTel 最容易被低估的核心机制。它负责在进程内（线程、协程）和进程间（HTTP、gRPC、消息队列）传递 Trace 上下文、Baggage 以及自定义上下文值。

Context 传播的典型流程如下：

2.4 Metrics 与 Logs 的上下文关联

Metrics 和 Logs 虽然不直接参与 Trace 的树形结构，但它们通过 Attributes 和 Context 与 Trace 建立关联：

• Metrics 关联：OTel 的 Exemplar 机制允许在 Histogram 中嵌入 TraceId/SpanId，实现“指标可追溯”。
• Logs 关联：LogRecord 可以携带 SpanContext，将日志行直接挂载到对应的 Span 下。

2.5 核心概念对比总结