2. OpenTelemetry 核心概念：Trace、Span、Metric、Log、Context Propagation、Exporter

OpenTelemetry（简称 OTel）是 CNCF 孵化的可观测性标准框架，它通过一套统一的 API、SDK 和协议，将应用程序的 Trace（链路）、Metric（指标）、Log（日志） 三大信号进行标准化采集与导出。理解其核心概念是构建自动化 Runbook 响应体系的基础。

2.1 核心信号概览

OTel 将可观测性数据抽象为三种主要信号，它们共同覆盖了系统行为的“发生了什么”、“为什么发生”和“趋势如何”。

2.2 Trace 与 Span：分布式追踪的基石

Trace 代表一个请求或事务在分布式系统中经过的完整路径。一个 Trace 由一个或多个 Span 组成，Span 是追踪的最小工作单元，描述了一个具体的操作（如一次数据库查询、一个 RPC 调用）。

• Span 属性：每个 Span 包含名称、开始/结束时间戳、状态（OK/Error）、Span 上下文（Trace ID、Span ID、Parent Span ID）以及可选的属性（Attributes）和事件（Events）。
• 父子关系：Span 之间通过 Parent Span ID 形成树状结构，完整还原请求的调用拓扑。
• Span 状态：当 Span 状态为 Error 时，通常意味着该操作失败，是 Runbook 自动响应的重要触发点。

2.3 Metric：聚合与告警的量化基础

Metric 是随时间变化的数值型数据，用于衡量系统的状态和性能。OTel 定义了三种主要的 Metric 类型：

• Counter（计数器）：只增不减的值，如请求总数、错误总数。
• Histogram（直方图）：对观测值进行采样并统计分布，如请求延迟的 P50/P90/P99。
• Gauge（仪表盘）：可增可减的瞬时值，如当前内存使用量、活跃连接数。

2.4 Log：事件记录的标准化

OTel 的 Log 信号旨在将传统日志与 Trace 关联起来。通过 Trace ID 和 Span ID，日志可以自动关联到对应的请求链路，实现“日志即事件”。

// 结构化日志示例（JSON 格式）
{
  "timestamp": "2025-04-10T14:30:00.123Z",
  "severity": "ERROR",
  "body": "数据库连接超时",
  "trace_id": "abc123",
  "span_id": "s3",
  "attributes": {
    "db.system": "mysql",
    "db.operation": "SELECT",
    "error.message": "Connection refused"
  }
}

2.5 Context Propagation：跨服务传递追踪上下文

Context Propagation 是分布式追踪的核心机制。它确保一个请求在跨越多个服务（如 A → B → C）时，Trace ID 和 Span ID 能够被正确传递，从而将所有 Span 关联到同一个 Trace 中。

• 传播方式：通常通过 HTTP 头（如 traceparent）、gRPC 元数据或消息队列的 Header 进行传递。
• W3C Trace Context：OTel 默认遵循 W3C 标准，使用 traceparent 和 tracestate 头。
• 自动化 Runbook 意义：当 Runbook 自动调用下游服务进行诊断时，必须正确传递上下文，否则无法形成完整的故障链路视图。

2.6 Exporter：数据导出与后端集成

Exporter 负责将 OTel SDK 采集到的 Trace、Metric、Log 数据发送到后端分析系统（如 Prometheus、Jaeger、Grafana、Datadog 等）。

2.7 概念关系总结

下图展示了 OTel 核心概念之间的协作关系：应用程序通过 SDK 生成 Trace/Metric/Log，Context Propagation 确保跨服务关联，最终由 Exporter 统一导出。