3. OpenTelemetry 标准
OpenTelemetry（简称 OTel）是 CNCF 的第二个毕业级可观测性项目，它统一了指标、日志、链路三大信号的采集、关联与导出标准。本章聚焦 OTel 的顶层架构、核心数据模型以及 Collector 组件的部署模式，为后续“标准模板驱动”的接入设计奠定基础。
3.1 OTel 整体架构
OTel 采用 Instrumentation → Collector → Backend 的三层架构。应用通过 SDK 或自动注入生成信号，Collector 负责接收、处理、转发，后端负责存储与可视化。
关键设计原则：OTel 不绑定任何特定后端，Collector 作为中间层实现协议转换、数据富化与流量控制，使应用层与存储层解耦。
3.2 数据模型：三大信号的标准定义
OTel 为每种信号定义了独立但可关联的数据模型，所有模型均以 Protobuf 序列化，支持 gRPC 和 HTTP 传输。
| 信号类型 | 核心数据结构 | 关键字段 | 关联方式 |
|---|---|---|---|
| Traces | Span | TraceId, SpanId, ParentSpanId, StartTime, EndTime, Attributes, Events | TraceId 串联整条链路，SpanId 标识单个操作 |
| Metrics | Metric (DataPoint) | Name, Description, Unit, AggregationTemporality, Attributes, Value | 通过 Resource 和 InstrumentationScope 关联到服务 |
| Logs | LogRecord | Timestamp, SeverityText, SeverityNumber, Body, Attributes, TraceId, SpanId | 可嵌入 TraceId/SpanId 实现日志与链路关联 |
语义约定（Semantic Conventions）：OTel 定义了标准化的属性键名（如
http.method、db.system），确保不同语言 SDK 生成的信号具有一致的字段结构，这是模板驱动接入的核心前提。
3.3 Collector 组件详解
OTel Collector 是一个可插拔的二进制组件，核心由 Receiver → Processor → Exporter 三个管道阶段组成。每个阶段均可通过配置文件声明式定义。
3.3.1 管道阶段与职责
| 阶段 | 职责 | 常用组件示例 |
|---|---|---|
| Receiver | 接收来自 SDK 或其他源的信号 | otlp、jaeger、prometheus、filelog |
| Processor | 数据加工：批处理、采样、过滤、重命名、属性修改 | batch、memory_limiter、filter、attributes、tailsampling |
| Exporter | 将处理后的数据发送到后端存储或分析平台 | otlp、prometheus、loki、datadog、logging |
3.3.2 部署模式
Collector 支持两种主流部署拓扑，根据规模与管控粒度选择：
- Agent 模式（Sidecar / DaemonSet）：每个节点或 Pod 部署一个 Collector 实例，负责本地信号采集与预处理，降低网络开销。
- Gateway 模式（集中式）：独立部署 Collector 集群，接收所有 Agent 转发来的数据，执行全局策略（如采样、路由、脱敏），再导出到后端。
3.3.3 配置文件示例
以下是一个典型的 Collector 配置，展示如何定义 Receiver、Processor、Exporter 并组装为管道：
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
http:
endpoint: 0.0.0.0:4318
processors:
batch:
timeout: 1s
send_batch_size: 1024
memory_limiter:
check_interval: 1s
limit_mib: 512
attributes:
actions:
- key: environment
value: "production"
action: upsert
exporters:
otlp:
endpoint: "backend.example.com:4317"
tls:
insecure: false
logging:
loglevel: debug
service:
pipelines:
traces:
receivers: [otlp]
processors: [memory_limiter, batch, attributes]
exporters: [otlp, logging]
metrics:
receivers: [otlp]
processors: [memory_limiter, batch]
exporters: [otlp]
logs:
receivers: [otlp]
processors: [memory_limiter, batch]
exporters: [otlp]
生产注意事项：务必配置
memory_limiter 和 batch 处理器，防止 Collector 因流量突发导致 OOM；Gateway 模式下建议启用 tailsampling 处理器实现头部采样与尾部采样策略。
3.4 标准模板驱动的接入切入点
OTel 的标准化数据模型和可插拔 Collector 架构，为“标准模板驱动”提供了天然基础：
- 数据模型统一：三大信号使用相同的 Protobuf 定义，模板只需关注属性映射规则，无需关心底层序列化差异。
- Collector 配置可模板化：Receiver、Processor、Exporter 的声明式配置可以抽象为 YAML 模板，通过参数化注入环境变量、后端地址、采样率等变量。
- 语义约定可复用：标准化的属性键名（如
http.status_code）使模板可以在不同服务间直接复用，只需替换service.name等资源属性。