2. OpenTelemetry Collector 架构：核心组件与数据流模型
在构建多租户数据管道之前，必须深入理解 OpenTelemetry Collector 的内部架构。Collector 采用高度模块化的设计，其核心由 Receiver、Processor、Exporter 三大组件以及 Pipeline 概念构成。本章将逐一剖析这些组件，并揭示数据在 Collector 内部的流转模型。
2.1 核心组件：Receiver、Processor、Exporter
Collector 的组件设计遵循单一职责原则，每个组件只负责数据生命周期中的一个特定阶段。下表总结了三大组件的核心职责与典型实现：
| 组件 | 职责 | 典型实现（举例） | 多租户关注点 |
|---|---|---|---|
| Receiver | 接收来自不同数据源的遥测数据（traces、metrics、logs） | otlp、jaeger、prometheus、kafka | 租户身份识别（通过 headers 或资源属性） |
| Processor | 对数据进行过滤、转换、丰富、采样、批处理等 | batch、filter、attributes、transform、tailsampling | 租户级数据隔离、标签注入、采样策略 |
| Exporter | 将处理后的数据发送到后端存储或分析系统 | otlp、prometheus、jaeger、elasticsearch、splunk | 租户级路由、目标后端隔离、认证凭据管理 |
otlp 既是 Receiver 也是 Exporter，这使得 Collector 可以级联部署，形成多层数据管道。在多租户场景中，这一特性常用于在边缘 Collector 完成租户识别，在中心 Collector 完成聚合与路由。
2.2 Pipeline 概念：数据管道的编排单元
Pipeline 是 OpenTelemetry Collector 中最重要的编排概念。一个 Pipeline 定义了从数据接收到导出的完整路径，它由三部分组成：
- Receivers：一个或多个数据接收器，作为管道的入口。
- Processors：零个或多个处理器，按声明顺序串联执行。
- Exporters：一个或多个数据导出器，作为管道的出口。
Pipeline 在 Collector 配置文件中通过 service.pipelines 节定义，支持按信号类型（traces、metrics、logs）分别声明。以下是一个典型的 Pipeline 配置片段：
service:
pipelines:
traces:
receivers: [otlp]
processors: [batch, attributes]
exporters: [otlp]
metrics:
receivers: [otlp]
processors: [batch]
exporters: [prometheus]2.3 数据流模型：从接收到导出的完整路径
理解数据在 Collector 内部的流动模型，是设计多租户隔离方案的基础。下图展示了单个 Pipeline 内部的数据流：
上图清晰地展示了数据在 Pipeline 中的单向流动特性。数据从左侧的 Receiver 进入，经过中间串联的多个 Processor 依次处理，最终到达右侧的 Exporter 被发送到后端。这种线性模型保证了处理逻辑的可预测性。
2.4 多 Pipeline 与信号类型隔离
OpenTelemetry Collector 支持同时运行多个 Pipeline，每个 Pipeline 可以处理不同的信号类型（traces、metrics、logs）。这种设计天然支持了按信号类型进行的数据隔离。下图展示了多 Pipeline 架构：
2.5 组件生命周期与并发模型
理解 Collector 组件的生命周期有助于诊断多租户场景下的资源竞争问题：
- 启动阶段：Collector 按配置顺序初始化所有组件，Receiver 开始监听端口，Exporter 建立与后端的连接。
- 运行阶段：每个 Pipeline 独立运行，数据在组件间通过 Go channel 传递，实现高效的并发处理。
- 关闭阶段：Collector 按逆序关闭组件，先停止 Receiver 接收新数据，等待 Processor 处理完缓冲区数据，最后关闭 Exporter 连接。