4. OpenTelemetry(OTel)基础：OTel架构、Trace/Metric/Log信号模型与采集原理

在云原生网关回滚护栏中，可观测性是决策的“眼睛”。OpenTelemetry（OTel）作为CNCF的标准化可观测性框架，统一了Trace、Metric、Log三大信号的采集与导出。本节将深入OTel的架构分层、信号模型定义以及采集器的工作原理，为后续WAF策略与OTel协同提供数据基础。

4.1 OTel整体架构分层

OTel架构采用“API → SDK → Exporter → Collector”的四层模型，每一层职责清晰，解耦了数据产生、处理与导出。

4.2 三大信号模型与数据模型

OTel将可观测性数据抽象为三种信号（Signal），每种信号有独立的数据模型和采集路径。

4.3 Trace信号模型详解

Trace由一组Span构成有向无环图（DAG），每个Span代表一个操作单元。Span之间通过ParentSpanId建立父子关系，形成调用链。

• SpanKind：标识Span的角色——INTERNAL（内部方法）、SERVER（服务端接收）、CLIENT（客户端发起）、PRODUCER/CONSUMER（消息生产/消费）。
• Attributes：键值对元数据，用于附加业务上下文，如 http.method、http.url、waf.rule_id。
• Events：Span内的时间戳事件，适合记录异常或关键日志点。
• Status：Unset / Ok / Error，标识操作结果。

// Span 数据模型示例（Protobuf 简化）
message Span {
  bytes trace_id = 1;
  bytes span_id = 2;
  bytes parent_span_id = 3;
  string name = 4;
  SpanKind kind = 5;
  fixed64 start_time_unix_nano = 6;
  fixed64 end_time_unix_nano = 7;
  repeated KeyValue attributes = 8;
  repeated Event events = 9;
  Status status = 10;
}

4.4 Metric信号模型详解

Metric用于聚合型数值观测，OTel定义了三种基本Instrument类型：

4.5 Log信号模型与关联

OTel Log模型兼容现有日志标准（如syslog、JSON日志），并增加了与Trace的关联字段。LogRecord不要求必须与Trace绑定，但推荐在可能的情况下填充TraceId和SpanId。

// LogRecord 数据模型示例
message LogRecord {
  fixed64 time_unix_nano = 1;
  SeverityNumber severity_number = 2;
  string severity_text = 3;
  any Value body = 4;
  repeated KeyValue attributes = 5;
  bytes trace_id = 6;   // 关联Trace
  bytes span_id = 7;    // 关联Span
}

4.6 采集原理：从应用到Collector的管道

OTel数据采集分为“应用内采集”和“Collector采集”两个阶段。

1. 应用内采集：通过OTel SDK在进程中创建Span/Metric/LogRecord，经过Sampler（采样器）和Processor（处理器）后，由Exporter发送给Collector或后端。
2. Collector采集：Collector通过Receiver接收数据，经过Processor链（过滤、批处理、属性修改、重试），最后由Exporter分发到多个后端（如Jaeger、Prometheus、Elasticsearch）。

4.7 采样策略与数据质量

在高并发网关场景下，全量采集Trace会产生巨大开销。OTel支持多种采样策略：

• Head-based Sampling：在Span创建时决定是否采样，简单但无法基于完整链路信息决策。
• Tail-based Sampling：在Collector端根据完整链路特征（如包含错误、延迟超过阈值）决定保留哪些Trace，适合回滚护栏场景中保留异常请求的完整链路。
• Probabilistic Sampling：按固定比例随机采样，适用于低优先级指标。

4.8 与WAF策略协同的OTel关键点