📚 课程目录第3章 OpenTelemetry架构总览

3. OpenTelemetry 架构总览：Collector、Exporter、Processor、Pipeline、SDK 与 API

OpenTelemetry（OTel）的架构设计遵循“数据产生 → 数据处理 → 数据导出”的管道模式。其核心组件包括 API、SDK、Collector、Processor、Exporter 以及将它们串联起来的 Pipeline。理解这些组件之间的协作关系，是构建多租户可观测性系统的基础。

3.1 核心组件与职责

下表总结了 OTel 架构中每个核心组件的定位与主要职责：

组件	定位	主要职责
API	规范与接口层	定义 Traces、Metrics、Logs 的数据模型与操作接口，不依赖具体实现。
SDK	实现与运行时层	实现 API 接口，负责采样、上下文传播、Span 创建与结束、指标聚合等。
Collector	数据管道中间件	接收、处理、转发遥测数据；支持多租户隔离、数据过滤、批处理与重试。
Processor	数据处理单元	在 Collector Pipeline 中执行过滤、采样、属性修改、批处理等操作。
Exporter	数据输出适配器	将处理后的数据发送到后端存储（如 Jaeger、Prometheus、Datadog、OTLP）。
Pipeline	数据流编排	定义 Receivers → Processors → Exporters 的有向无环图（DAG）执行路径。

架构要点： API 与 SDK 的分离使得应用代码只需依赖抽象接口，而 Collector 作为独立进程，承担了数据路由、降级与多租户策略的核心逻辑，是后端架构中的关键枢纽。

3.2 架构总览：从 SDK 到 Collector 再到后端

下图展示了从应用内 SDK 产生数据，经过 Collector 处理，最终导出到多个后端存储的完整数据流。该图突出了 Collector 内部 Pipeline 的分阶段处理逻辑。

  关键路径解读： 应用通过 SDK 的 API 产生遥测数据，以 OTLP 协议发送至 Collector 的 Receiver。数据进入 Pipeline 后，依次经过 Processor 链（过滤、采样、批处理），最后由 Exporter 分发至一个或多个后端。Collector 的独立部署使得后端切换、数据降级与多租户策略对应用完全透明。

3.3 Pipeline：数据流的编排核心

Pipeline 是 Collector 内部的数据流编排单元，采用 Receivers → Processors → Exporters 的有向无环图（DAG）结构。每个 Pipeline 可以独立配置，支持多租户场景下的数据隔离。

以下是一个典型的 Pipeline 配置片段，展示了如何串联组件：

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

processors:
  batch:
    timeout: 1s
    send_batch_size: 1024
  memory_limiter:
    check_interval: 1s
    limit_mib: 512

exporters:
  otlp:
    endpoint: "jaeger-collector:4317"
    tls:
      insecure: true
  prometheus:
    endpoint: "0.0.0.0:8889"

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [prometheus]

多租户注意事项： 在多租户架构中，Pipeline 的 Processor 链应包含租户识别与隔离逻辑（如通过 attributes 处理器注入租户 ID），避免不同租户的数据在批处理或采样阶段互相干扰。

3.4 Processor 与 Exporter 的协作模式

Processor 与 Exporter 的协作决定了数据的最终形态与投递目标。下表列出了常见的 Processor 类型及其与 Exporter 的典型配合：

Processor 类型	功能	典型 Exporter 配合
batch	合并多个 Span/Metric 为一批，减少网络开销	所有 Exporter（通用优化）
memory_limiter	防止 Collector OOM，丢弃或降级数据	所有 Exporter（保护机制）
attributes	增删改 Span/Metric 的属性标签	otlp、jaeger、prometheus
filter	根据条件丢弃或保留数据（如只保留错误 Span）	otlp、datadog
tailsampling	基于完整 Trace 的尾部采样决策	otlp、jaeger
k8sattributes	自动注入 Kubernetes Pod/Node 元数据	otlp、prometheus

3.5 SDK 与 API 的交互细节

SDK 是 API 的具体实现，负责在应用运行时管理上下文、创建 Span、聚合指标。下图展示了 SDK 内部的核心模块及其与 API 的交互关系：

  SDK 关键职责： SDK 实现了 API 定义的接口，并通过 SpanProcessor 将 Span 传递给 Exporter。Sampler 在 Span 创建时决定是否记录，Exporter 负责将数据序列化并发送至 Collector 或后端。在多租户场景中，SDK 可通过 Resource 属性注入租户标识，实现数据源头隔离。

3.6 多租户视角下的架构要点

API 层： 定义租户无关的数据模型，所有租户共用同一套接口规范。
SDK 层： 通过 Resource 属性携带租户 ID，支持按租户配置采样率与导出目标。
Collector 层： 利用 Processor 链实现租户数据路由、过滤与隔离；支持为不同租户配置独立的 Pipeline。
Exporter 层： 可根据租户 ID 将数据分发至不同的后端存储或命名空间。

架构建议： 在多租户部署中，推荐将 Collector 的 Pipeline 设计为“共享 Receiver + 按租户分流 Processor + 独立 Exporter”的模式，既保证数据接收的统一性，又实现租户级别的处理与存储隔离。