2. OpenTelemetry 核心概念回顾:Span、Trace、Metric、Log、Context Propagation

在构建自动化事件触发 Runbook 之前,必须统一团队对 OpenTelemetry 数据模型的理解。本章回顾五大核心概念:Span、Trace、Metric、Log 以及 Context Propagation。这些概念是后续定义告警规则、关联事件上下文、触发自动化动作的基石。

2.1 Span:可观测性的基本工作单元

Span 是分布式追踪中最小的逻辑单元,代表一次具有开始时间和结束时间的操作。每个 Span 包含以下关键属性:

属性 说明 示例值
Span ID 全局唯一标识符 a1b2c3d4e5f6g7h8
Trace ID 所属 Trace 的标识 trace-001-xyz
Parent Span ID 父 Span 标识(根 Span 为空) p9o8i7u6y5t4r3e2
Span Name 操作名称 HTTP GET /api/orders
Start / End Timestamp 操作起止时间 2025-03-01T10:00:00Z
Attributes 键值对元数据 http.status_code=200
Status 操作结果状态 OK / ERROR / UNSET
Events Span 生命周期内的结构化日志 exception.stacktrace
Runbook 关联点: 当 Span 状态为 ERROR 且包含特定属性(如 http.status_code=500)时,可作为自动化事件触发的信号源。

2.2 Trace:端到端请求的完整视图

Trace 由一组具有相同 Trace ID 的 Span 组成,描述一个请求从入口到出口的完整路径。Trace 的核心价值在于:

  • 因果链可视化:通过 Parent-Child 关系还原调用拓扑。
  • 延迟分解:定位耗时最长的 Span(瓶颈分析)。
  • 错误传播追踪:快速找到根因 Span。

下图展示了一个典型 Trace 的结构,包含三个服务之间的调用关系:

Trace 结构示例:服务调用链 Trace 结构示例:服务调用链 Span A: API Gateway — /checkout (Trace ID: tr-001) Span B: Order Service — validateCart (Parent: Span A) Span C: Payment Service — charge (Parent: Span B) Span D: Inventory Service — reserveStock (Parent: Span B) 说明:同一 Trace ID 下所有 Span 共享上下文,通过 Parent Span ID 形成树状结构

2.3 Metric:聚合后的量化指标

Metric 是随时间聚合的数值数据,用于监控系统健康状态和性能趋势。OpenTelemetry 支持三种基本 Metric 类型:

类型 行为 典型用例 示例
Counter 单调递增,只增不减 请求总数、错误计数 http.requests.total
Histogram 记录值的分布(分桶) 请求延迟、响应大小 http.request.duration
Gauge 可增可减,反映当前快照 CPU 使用率、内存占用 system.memory.usage
Runbook 集成提示: 当 Histogram 的 p99 延迟超过阈值时,可触发自动扩容 Runbook;当 Counter 错误率突增时,可触发日志采集和根因分析流程。

2.4 Log:带上下文的事件记录

在 OpenTelemetry 体系中,Log 不再是孤立的文本行,而是与 Trace 和 Metric 关联的结构化记录。每个 Log Record 可以包含:

  • Timestamp:事件发生时间。
  • Severity:日志级别(TRACE / DEBUG / INFO / WARN / ERROR / FATAL)。
  • Body:日志消息体(支持结构化 JSON)。
  • Trace ID & Span ID:关联到具体的 Span,实现日志与追踪的联动。
  • Attributes:自定义键值对,如 user.id、transaction.type。
// 结构化日志示例(JSON 格式)
{
  "timestamp": "2025-03-01T10:00:05.123Z",
  "severity": "ERROR",
  "body": "Database connection timeout",
  "traceId": "tr-001",
  "spanId": "a1b2c3d4e5f6",
  "attributes": {
    "db.system": "postgresql",
    "db.operation": "SELECT",
    "error.type": "timeout"
  }
}

2.5 Context Propagation:跨服务传递上下文

Context Propagation 是 OpenTelemetry 的“神经系统”,确保 Trace、Baggage 等信息在微服务间正确传递。其核心机制包括:

  1. W3C Trace Context 标准:通过 HTTP 头 traceparent 和 tracestate 传递 Trace ID 和 Span ID。
  2. Baggage:携带业务上下文(如用户 ID、租户 ID),跨服务共享。
  3. Propagator:负责序列化/反序列化上下文,支持 HTTP、gRPC、消息队列等协议。

下图展示了 Context Propagation 在三个服务间的传递流程:

Context Propagation 跨服务传递流程 Context Propagation 跨服务传递流程 服务 A API Gateway 服务 B Order Service 服务 C Payment Service traceparent tracestate traceparent baggage: user_id=123 Context Propagation 关键点 1. 服务 A 创建 Trace ID,通过 HTTP 头传递给服务 B 2. 服务 B 提取上下文,创建子 Span,继续传递给服务 C 3. 所有服务共享同一 Trace ID,实现端到端关联

2.6 概念关系总结

下表梳理了五大核心概念在自动化 Runbook 场景中的角色:

概念 数据特征 Runbook 触发场景 关联动作
Span 单次操作,含状态和属性 Span 状态为 ERROR 采集日志、创建事件
Trace Span 集合,树状结构 Trace 中任一 Span 失败 追踪根因、回滚操作
Metric 聚合数值,时间序列 阈值告警(如 p99 > 500ms) 自动扩缩容、限流
Log 结构化事件记录 ERROR 级别日志出现 通知、创建工单
Context Propagation 跨服务上下文传递 上下文丢失导致链路断裂 修复传播配置、重试
常见误区: 不要将 Span 和 Log 视为独立数据。在 OpenTelemetry 中,Log 应始终关联 Trace ID 和 Span ID,否则在事件调查时将无法从日志回溯到具体的调用链路,导致 Runbook 自动化流程中断。