📚 课程目录第3章 OpenTelemetry架构与组件

3. OpenTelemetry 架构与组件：SDK、API、Collector、OTLP 协议、采样策略、传播上下文

OpenTelemetry（OTel）是 CNCF 孵化的可观测性标准框架，提供一套与厂商无关的 API、SDK 和工具，用于生成、采集、处理和导出遥测数据（Trace、Metric、Log）。在自动回滚场景中，OTel 负责实时捕获部署后的异常信号，并触发 Runbook 决策。理解其核心组件是构建可靠回滚链路的基础。

3.1 整体架构概览

OTel 架构分为三层：Instrumentation 层（应用内）、Collector 层（数据管道）、Backend 层（存储与分析）。下图展示了从应用埋点到回滚决策的数据流。

3.2 核心组件详解

3.2.1 OTel API 与 SDK

API：定义 Tracer、Meter、Logger 等接口，与厂商无关。应用代码只依赖 API，不绑定具体实现。
SDK：实现 API 的具体逻辑，包括 Span 创建、上下文管理、采样、导出等。SDK 通过 SpanProcessor 和 Exporter 将数据发送给 Collector。

实战建议：在 Java/Go/Python 服务中引入 OTel SDK 时，优先使用自动埋点（Agent/Library），减少代码侵入。对于关键业务路径（如支付、下单），补充手动埋点以捕获自定义属性。

3.2.2 OTel Collector

Collector 是数据管道核心，支持三种组件模式：

组件	功能	回滚场景示例
Receiver	接收来自 SDK 或其他源的遥测数据	OTLP Receiver 接收应用 Trace
Processor	处理、过滤、采样、修改数据	Tail-Based Sampler 保留错误 Trace
Exporter	将数据发送至后端存储	Prometheus Exporter 导出 Metric

3.2.3 OTLP 协议

OTLP（OpenTelemetry Protocol）是 OTel 原生通信协议，支持 gRPC 和 HTTP/Protobuf 两种传输方式。SDK 与 Collector、Collector 与 Collector 之间默认使用 OTLP。

gRPC：低延迟、双向流，适合高吞吐场景。
HTTP/Protobuf：兼容性好，适合边缘节点或受限网络。

# OTLP gRPC Exporter 配置示例（collector.yaml）
exporters:
  otlp:
    endpoint: "otel-collector:4317"
    tls:
      insecure: true

3.3 采样策略

采样控制数据量，降低存储成本，同时保证关键数据不丢失。自动回滚场景下，采样策略直接影响异常检测的完整性。

策略	原理	适用场景	回滚风险
Head-Based	在 Trace 起点按概率采样	低流量、全量采样可接受	可能漏采错误 Trace
Tail-Based	在 Collector 端根据结果采样	高流量、需保留错误/慢 Trace	低风险，保留异常数据
概率采样	固定比例（如 10%）	容量规划、成本控制	高，可能错过回滚触发
一致性采样	根据 Trace ID 哈希决定	分布式系统保持完整 Trace	中，需合理配置哈希范围

回滚场景警告：不要在生产回滚链路中使用纯概率采样。建议采用 Tail-Based 采样，确保所有错误和慢 Trace 被完整保留，同时降低正常 Trace 的存储开销。

3.4 上下文传播（Context Propagation）

上下文传播是分布式追踪的基石，确保跨服务调用链的 Trace 信息不丢失。OTel 使用 W3C TraceContext 标准，通过 HTTP 头 traceparent 和 tracestate 传递上下文。

# traceparent 格式示例
traceparent: 00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01
# 字段说明：
# 00        - 版本号
# 0af7...   - Trace ID（16字节十六进制）
# b7ad...   - Span ID（8字节十六进制）
# 01        - Trace Flags（01 表示采样）

在自动回滚场景中，上下文传播帮助 Runbook 将告警事件与具体的部署版本、请求链路关联，快速定位异常根因。

3.5 组件协作流程

下图展示一次部署后，从埋点到回滚触发的完整组件协作时序。

3.6 关键配置清单

部署 OTel 用于自动回滚时，以下配置项必须确认：

配置项	推荐值	说明
采样策略	Tail-Based + 错误全采	保留所有错误 Trace，正常 Trace 按 10% 采样
OTLP 端点	gRPC (端口 4317)	低延迟，适合内网传输
上下文传播	W3C TraceContext	标准协议，跨语言兼容
Collector 部署	Kubernetes DaemonSet	每个节点一个，减少网络跳转
导出目标	Prometheus + Jaeger	Metric 用于告警，Trace 用于根因分析

  本章小结：OTel 的 SDK/API 负责数据生成，Collector 负责数据处理与路由，OTLP 协议保障传输效率，采样策略平衡成本与完整性，上下文传播确保分布式链路可追踪。在自动回滚场景中，这五个组件缺一不可，共同构成从部署到回滚的完整可观测性闭环。