2. OTel Collector 核心组件：Receiver、Processor、Exporter、Pipeline 的配置与数据流

OpenTelemetry Collector 是一个可扩展的、与厂商无关的遥测数据接收、处理与导出中间件。其内部架构围绕四个核心组件构建：Receiver（接收器）、Processor（处理器）、Exporter（导出器）以及将它们串联成工作流的 Pipeline（管道）。理解这些组件的职责、配置方式以及数据在管道中的流动路径，是进行故障定位与 Runbook 执行的基础。

2.1 核心组件职责与配置

每个组件通过 YAML 配置文件中的顶级区块进行定义。以下表格总结了各组件的核心职责与典型配置片段。

组件 职责 典型配置示例（YAML）
Receiver 接收来自各种来源的遥测数据（gRPC、HTTP、文件、Kubernetes API 等），并将其转换为 Collector 内部的数据模型。 
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
Processor 在接收和导出之间对数据进行过滤、修改、采样、聚合、附加元数据等操作。处理器可以串联使用。 
processors:
  batch:
    timeout: 1s
    send_batch_size: 1024
  memory_limiter:
    check_interval: 1s
    limit_mib: 512
Exporter 将处理后的数据发送到一个或多个后端系统（如 Prometheus、Jaeger、Datadog、S3、Kafka 等）。 
exporters:
  otlp:
    endpoint: my-backend:4317
    tls:
      insecure: true
  logging:
    loglevel: debug
Pipeline 定义数据流路径：将一组 Receiver、Processor（可选）和 Exporter 按顺序连接起来，形成一条完整的数据处理链路。 
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp, logging]
关键原则： 一个 Pipeline 必须至少包含一个 Receiver 和一个 Exporter。Processor 是可选的，但强烈建议在生产环境中至少配置 batch 和 memory_limiter 处理器，以保障 Collector 的稳定性。

2.2 Pipeline 数据流与组件串联机制

数据在 Collector 内部的流动遵循严格的顺序：Receiver → Processor(s) → Exporter。每个 Pipeline 是独立的，数据不会跨 Pipeline 混合。下图展示了典型的单 Pipeline 数据流架构。

OTel Collector 单 Pipeline 数据流架构 单 Pipeline 数据流架构 数据源 Receiver otlp / jaeger / prometheus / filelog Processor batch memory_limiter filter / transform Exporter otlp / prometheus logging / kafka 后端 数据流方向：从左至右 每个 Pipeline 独立运行，数据在 Processor 链中按配置顺序依次处理

2.3 多 Pipeline 与数据隔离

生产环境中通常需要为不同的信号类型（Traces、Metrics、Logs）配置独立的 Pipeline，以实现资源隔离和差异化处理策略。下图展示了多 Pipeline 的典型部署模式。

多 Pipeline 数据隔离架构 多 Pipeline 数据隔离架构 Pipeline: traces otlp batch otlp logging Pipeline: metrics prometheus filter prometheus Pipeline: logs filelog batch loki
故障定位要点： 当某个信号类型（如日志）出现数据丢失时，应首先检查该信号对应的 Pipeline 配置。检查点包括：Receiver 端口是否被占用、Processor 是否因内存限制丢弃了数据、Exporter 连接后端是否超时。多 Pipeline 之间互不影响，但会共享 Collector 的全局资源（CPU、内存、网络连接）。

2.4 组件配置的常见陷阱与验证方法

在配置 Collector 时，以下问题经常导致管道故障：

  • Receiver 端口冲突： 多个 Receiver 监听同一端口会导致 Collector 启动失败。使用 netstat -tulpn | grep 4317 验证端口占用。
  • Processor 顺序错误： memory_limiter 应放在 batch 之前，以确保在内存压力下优先丢弃数据而非 OOM。
  • Exporter 端点不可达： 后端地址拼写错误或 TLS 证书不匹配会导致数据积压。启用 logging Exporter 进行调试。
  • Pipeline 名称不匹配： service.pipelines 下定义的名称必须与 receivers、processors、exporters 区块中的键名完全一致。
生产环境建议： 始终在 service.telemetry.metrics 中启用 Collector 自身指标（level: detailed），并暴露 prometheus Exporter 用于监控 Collector 内部组件的处理延迟、错误率和队列积压情况。这是故障定位的第一道防线。

2.5 数据流故障排查清单

当管道出现数据中断或延迟时，按以下步骤进行排查：

  1. 检查 Collector 启动日志： 确认所有组件加载成功，无配置解析错误。
  2. 验证 Receiver 端点： 使用 curl 或 grpcurl 测试 gRPC/HTTP 端点是否响应。
  3. 检查 Processor 指标： 查看 processor/batch 的 batch_send_size 和 batch_timeout 指标，确认数据是否在处理器中积压。
  4. 验证 Exporter 连接： 检查 exporter/*/send_failed_requests 指标是否增长，确认后端可达性。
  5. 启用 Debug Exporter： 在 Pipeline 中临时添加 logging Exporter 并设置 loglevel: debug，观察数据是否到达导出阶段。

通过系统化地理解 Receiver、Processor、Exporter 和 Pipeline 的配置与数据流，SRE 团队能够快速定位管道瓶颈与故障点，为后续 Runbook 的执行奠定坚实基础。

← 上一章 📖 返回目录 下一章 →