3. OpenTelemetry Collector 架构：Receiver、Processor、Exporter、Pipeline、Connector 组件详解

OpenTelemetry Collector 是整个可观测性生态的“数据中枢”。它不依赖特定厂商，能够接收、处理、导出遥测数据（Trace、Metric、Log），并通过 Pipeline 和 Connector 实现灵活的数据路由与聚合。理解 Collector 的组件架构，是构建自动化告警规则模板的基础——因为告警数据的质量、延迟、标签完整性，都取决于 Collector 内部的组件编排。

3.1 组件总览与职责边界

Collector 由五大核心组件构成，下表总结了每个组件的职责、典型场景与告警相关性：

3.2 Receiver：数据入口

Receiver 是 Collector 的“耳朵”，负责监听或拉取数据。每个 Receiver 通常对应一种数据源协议或格式。常见的 Receiver 包括：

• OTLP Receiver：接收原生 OpenTelemetry 协议数据（gRPC/HTTP），是 Collector 间通信的标准方式。
• Prometheus Receiver：抓取 Prometheus 暴露的指标端点，将 Prometheus 指标转换为 OTel 指标模型。
• Jaeger Receiver：接收 Jaeger 格式的 Trace 数据，兼容 Jaeger 客户端。
• Filelog Receiver：读取日志文件，支持多行日志合并、自动发现。
• Kubernetes Events Receiver：从 K8s API Server 拉取事件，用于基础设施告警。

Receiver 的配置通常包含 端点（endpoint）、认证、TLS 和 资源限制。以下是一个 OTLP Receiver 的典型配置片段：

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
    # 限制接收速率，防止过载
    limits:
      max_recv_msg_size_mib: 4

3.3 Processor：数据加工厂

Processor 是 Collector 中最具可编程性的组件。它位于 Receiver 和 Exporter 之间，对数据进行 过滤、转换、采样、聚合、增强。对于告警规则自动化，Processor 承担以下关键职责：

• 标签增强（Attributes Processor）：为所有指标添加固定标签，如 datacenter=us-east-1，使告警规则模板可以按数据中心路由。
• 指标过滤（Filter Processor）：排除不需要的指标，例如排除 container_*_total 这类计数器，减少告警噪音。
• 采样（Sampling Processor）：对 Trace 进行头部或尾部采样，控制存储成本，同时保留关键错误 Trace 用于告警关联。
• 指标聚合（Metric Transform Processor）：将高基数标签降维，例如将 pod_name 聚合为 deployment_name，使告警规则更稳定。
• 批处理（Batch Processor）：将数据打包后发送，提高导出效率，减少后端压力。

以下是一个 Processor 配置示例，展示如何为告警指标添加环境标签并过滤健康检查：

processors:
  attributes/alert:
    actions:
      - key: env
        value: "production"
        action: upsert
      - key: alert_source
        value: "otel-collector"
        action: insert
  filter/health:
    metrics:
      exclude:
        match_type: regexp
        metric_names:
          - ".*_health_check.*"
          - ".*_uptime_seconds"

3.4 Exporter：数据出口

Exporter 将处理后的数据发送到后端系统。对于告警场景，Exporter 的目标通常是 Alertmanager、Prometheus、Elasticsearch 或 自定义 Webhook。常见的 Exporter 包括：

• OTLP Exporter：将数据发送到另一个 Collector 或 OTel 后端。
• Prometheus Exporter：暴露 /metrics 端点供 Prometheus 抓取，适合与 Alertmanager 集成。
• Logging Exporter：将数据打印到控制台，用于调试和验证告警规则。
• Kafka Exporter：将数据写入 Kafka 主题，供下游告警引擎消费。

Exporter 的配置通常包含 端点、认证、重试策略 和 队列设置。以下是一个 Prometheus Exporter 配置，用于暴露告警指标：

exporters:
  prometheus:
    endpoint: "0.0.0.0:8889"
    namespace: "otel"
    const_labels:
      collector_id: "dc-01"
    resource_to_telemetry_conversion:
      enabled: true

3.5 Pipeline：数据流编排

Pipeline 是 Collector 的“骨架”，它将 Receiver、Processor、Exporter 串联成一个完整的数据流。一个 Pipeline 由三部分组成：

• receivers：数据源列表
• processors：处理步骤列表（可选，按顺序执行）
• exporters：数据目标列表

Pipeline 支持按数据类型（traces / metrics / logs）独立定义。这意味着你可以为告警指标设计一个独立的 Pipeline，与 Tracing Pipeline 完全隔离，避免互相影响。

以下是一个典型的双 Pipeline 配置：

service:
  pipelines:
    metrics/alert:
      receivers: [otlp, prometheus]
      processors: [attributes/alert, filter/health, batch]
      exporters: [prometheus, logging]
    traces/frontend:
      receivers: [otlp]
      processors: [batch, sampling]
      exporters: [otlp]

3.6 Connector：跨 Pipeline 桥梁

Connector 是 Collector 0.80.0 版本引入的组件，用于连接两个 Pipeline。它允许一个 Pipeline 的 Exporter 输出直接作为另一个 Pipeline 的 Receiver 输入，实现 数据跨管道流动 和 聚合计算。

Connector 的典型应用场景包括：

• Trace → Metrics：从 Trace 中提取延迟、错误率等指标，输出到 Metrics Pipeline 用于告警。
• Metrics → Logs：当指标超过阈值时，生成一条日志记录，供日志告警系统处理。
• Logs → Metrics：从日志中统计错误频率，生成计数器指标。

以下是一个 Connector 配置示例，将 Trace 中的请求延迟转换为告警指标：

connectors:
  spanmetrics:
    latency_histogram_buckets: [10ms, 50ms, 100ms, 200ms, 500ms, 1s]
    dimensions:
      - http.method
      - http.status_code
    dimensions_cache_size: 1000
    aggregation_temporality: "cumulative"

service:
  pipelines:
    traces/in:
      receivers: [otlp]
      processors: [batch]
      exporters: [spanmetrics]  # 输出到 Connector
    metrics/alert:
      receivers: [spanmetrics]  # 从 Connector 接收
      processors: [filter/health, attributes/alert]
      exporters: [prometheus]

3.7 组件协作架构图

下图展示了 Collector 内部各组件如何通过 Pipeline 和 Connector 协作，形成完整的数据流：

3.8 组件配置清单与告警自动化映射

下表将每个组件的配置项与告警规则自动化的具体需求进行映射，帮助你在设计 Collector 配置时直接对齐告警目标：

3.9 组件选型决策树

在实际部署中，你需要根据数据源类型、告警需求和性能要求选择合适的组件组合。以下决策树可以帮助你快速确定 Collector 配置：

3.10 组件性能与可靠性考量

在告警场景中，Collector 组件的性能直接影响告警的实时性和可靠性。以下是每个组件的性能关键点：

• Receiver：配置 limits.max_recv_msg_size_mib 防止大包导致 OOM；使用 tls 加密时注意 CPU 开销。
• Processor：batch processor 的 timeout 和 send_batch_size 影响延迟；attributes processor 的 actions 数量过多会增加处理时间。
• Exporter：retry_on_failure 的 initial_interval 和 max_interval 决定告警数据恢复速度；queue 的 queue_size 影响背压处理能力。
• Connector：dimensions_cache_size 控制内存使用；aggregation_temporality 选择 cumulative 或 delta 影响指标计算精度。