基于OpenTelemetry的DORA数据采集方案 - 第2节

2.1 OpenTelemetry 项目背景

OpenTelemetry（简称 OTel）是由 OpenTracing 与 OpenCensus 两大项目于 2019 年合并而成的统一可观测性标准。其诞生背景源于可观测性领域长期存在的“碎片化”问题：不同厂商、不同语言、不同协议各自为政，导致数据采集、传输、处理链路割裂，运维团队被迫维护多套 SDK 和 Agent。

2.2 三大信号：Traces、Metrics、Logs

OpenTelemetry 将可观测性数据抽象为三种信号（Signals），它们从不同维度描述系统状态，共同构成 DORA 数据采集的原始素材。

2.2.1 Traces（分布式追踪）

Traces 记录请求在分布式系统中的完整调用路径，以 Span 为基本单元。每个 Span 包含操作名称、开始/结束时间戳、属性（Attributes）、事件（Events）以及父子关系。DORA 中的变更前置时间和故障恢复时间可以通过 Trace 中的关键 Span 时间戳计算得出。

2.2.2 Metrics（指标）

Metrics 是聚合后的数值型数据，支持 Counter、Gauge、Histogram 等类型。DORA 中的部署频率和变更失败率本质上是基于事件计数的指标。OTel Metrics 通过 Exponential Histogram 等数据结构，能够在高基数场景下保持精度。

2.2.3 Logs（日志）

Logs 是带有时间戳的结构化或非结构化文本记录。OTel 将 Logs 与 Traces 通过 TraceId 关联，实现“日志即事件”的上下文打通。在故障恢复场景中，日志是定位根因的关键信号。

2.3 OTel 架构与核心组件

OpenTelemetry 采用 采集器（Collector） 为中心的架构，将数据面与控制面分离。整体架构分为三层：应用层（SDK/API）、传输层（OTLP 协议）、处理层（Collector Pipeline）。

2.3.1 核心组件一览

2.3.2 Collector Pipeline 工作流

Collector 内部通过 Receivers → Processors → Exporters 三段式 Pipeline 处理数据。每个阶段均可配置多个插件，实现数据过滤、采样、增强、路由等操作。

1. Receivers：接收来自 SDK 或其他源的 OTLP 数据，也支持 Prometheus、Zipkin、Fluentd 等协议。
2. Processors：对数据进行批处理、属性修改、采样、内存控制等。DORA 场景中常用 batch 处理器合并 Span，attributes 处理器注入部署标签。
3. Exporters：将处理后的数据写入后端。支持多路导出，例如同时写入 Jaeger 和 S3 归档。

2.3.3 部署模式对比