Observability

OpenTelemetry Collector 深度解析：Pipeline 架构、采样策略与大规模部署

OpenTelemetry Collector 是可观测性体系中的核心数据管道：应用通过 OTel SDK 埋点产生的 Metrics/Logs/Traces，全部汇聚到这里，经过接收、处理、导出三个阶段，再分发到 Prometheus、Loki、Tempo、Jaeger 等后端。它是连接"埋点"与 …

spcent 2026-09-26 7 分钟阅读 3241 字

OpenTelemetry Collector 是可观测性体系中的核心数据管道：应用通过 OTel SDK 埋点产生的 Metrics/Logs/Traces，全部汇聚到这里，经过接收、处理、导出三个阶段，再分发到 Prometheus、Loki、Tempo、Jaeger 等后端。它是连接"埋点"与"存储"的必经之路，也是规模化可观测性架构里第一个要设计好的组件。本指南深入 Collector 的 Pipeline 架构，覆盖接收器/处理器/导出器的设计、采样策略、性能调优、多后端路由、高可用与安全加固，最后给出大规模生产部署的完整示例。

一、Collector 在 OTel 架构中的定位

1.1 两种部署模式

Agent 模式（每节点一个）：
  应用 → OTel SDK ──► Collector(Agent) ──► 后端
                         ↑ 本地采集、批处理、采样、过滤

Gateway 模式（集中式）：
  应用 → OTel SDK ──► Collector(Agent) ──► Collector(Gateway) ──► 后端
                          ↑ 边缘处理            ↑ 集中处理、路由、聚合

模式	部署	职责	适用
Agent	DaemonSet/边车	就近采集、批处理、采样、脱敏	每个节点必备
Gateway	独立集群	集中路由、多后端分发、认证、降采样	多集群/多后端场景

ℹ️ 关键实践：Agent 负责"轻处理"（采样、脱敏、批处理），Gateway 负责"重处理"（多后端路由、认证、降采样、长期存储对接）。两层职责分离，让 Agent 保持轻量、故障不外泄。

1.2 Collector 与 SDK 的分工

SDK 做：
  · 生成数据（Span/Metric/Log）
  · 上下文传播（traceparent 头）
  · 本地采样（head sampling）
  · 内置 exporter（OTLP/console）

Collector 做：
  · 接收聚合（多语言 SDK 统一入口）
  · 集中处理（采样/过滤/脱敏/聚合）
  · 多后端分发（无需改应用代码）
  · 认证与访问控制（统一在此层做）

二、Pipeline 架构：Receivers / Processors / Exporters

2.1 核心概念

# collector.yml — 最小 Pipeline 配置
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:
    timeout: 2s
    send_batch_size: 8192

exporters:
  otlp/tempo:
    endpoint: tempo.monitoring.svc:4317
  prometheusremotewrite:
    endpoint: http://mimir.monitoring.svc:9009/api/v1/push
  otlp/loki:
    endpoint: http://loki-gw.monitoring.svc:4317

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp/tempo]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [prometheusremotewrite]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp/loki]

2.2 Pipeline 的数据流

Receivers(接收) → Processors(处理链) → Exporters(导出)
      ↑                                      ↓
  数据入口(OTLP/Jaeger/Prometheus...)   数据出口(OTLP/PRW/Loki/Kafka...)

三条独立 Pipeline：
  traces   → OTLP → batch → Tempo
  metrics  → OTLP → batch → Mimir(PRW)
  logs     → OTLP → batch → Loki

2.3 关键 Processor 一览

Processor	作用	适用场景
`batch`	合并数据批量发送，降低开销	必配
`memory_limiter`	内存水位保护，防止 OOM	必配
`tail_sampling`	尾部采样（按 Trace 条件）	高流量 Trace
`head_sampling`	头部采样（按 Span 属性）	低开销 Trace
`attributes`	增删改 Span/Metric 属性	统一标签
`resource`	修改 Resource 信息	补充集群/环境信息
`filter`	丢弃/保留满足条件的数据	降噪
`redaction`	脱敏敏感字段	合规
`transform`	OTTL 表达式处理	复杂变换
`routing`	按条件路由到不同导出器	多后端

三、批处理与采样：控制成本的第一道闸门

3.1 Batch：吞吐与开销

processors:
  batch:
    timeout: 5s               # 攒批等待时间
    send_batch_size: 10000    # 触发发送的最大条数
    send_batch_max_size: 10000
    # 三条 Pipeline 可各自配置不同的批参数

3.2 Head Sampling（头部采样）

头部采样在 Span 创建时决定：概率采样，简单但会丢完整 Trace。

processors:
  probabilistic_sampler:
    sampling_percentage: 20     # 20% 的 Span 被采样

3.3 Tail Sampling（尾部采样）

尾部采样先收集部分 Span，再按整条 Trace 的条件决定是否保留——保证错误 Trace 100% 保留，健康 Trace 低概率保留。

processors:
  tail_sampling:
    decision_cache:
      # 决策缓存：Trace 等待时限内收集全部 Span
      max_size: 5000
      ttl: 1m
    policies:
      - name: keep-errors
        type: status_code
        status_code:
          status_codes: [ERROR]
      - name: keep-slow-traces
        type: latency
        latency:
          threshold_ms: 2000
      - name: random-sampling
        type: probabilistic
        probabilistic:
          sampling_percentage: 10

ℹ️ 成本洞察：Tail sampling 是控制 Trace 成本的核心武器——错误与慢请求全留，成功快请求只留 10%，可把 Trace 存储量砍掉 80-90% 而几乎不丢失排查价值。

3.4 Span Metrics：采样后的指标补偿

采样会破坏指标统计（只统计到被采的 Span）。用 spanmetrics 处理器重建指标：

processors:
  spanmetrics:
    metrics_exporter: prometheusremotewrite
    latency_histogram_buckets:
      - 0.01, 0.025, 0.05, 0.1, 0.25, 0.5, 1.0, 2.5
    dimensions:
      - http.method
      - http.route
      - status.code

四、内存与性能调优

4.1 Memory Limiter：防止 Collector OOM

processors:
  memory_limiter:
    check_interval: 1s
    limit_mib: 4096          # 硬上限 4GB
    spike_limit_mib: 512     # 瞬时波动允许 512MB
    # 超过 limit 时拒绝新数据并丢弃，保护进程存活

4.2 队列与背压

exporters:
  otlp/tempo:
    endpoint: tempo:4317
    sending_queue:
      enabled: true
      queue_size: 10000      # 待发送队列
      num_consumers: 8       # 并行发送
    retry_on_failure:
      enabled: true
      max_elapsed_time: 5m
      max_interval: 30s
    compression: gzip

4.3 性能清单

高吞吐 Collector 调优清单：
  · GOMEMLIMIT 与 memory_limiter 同时设置（GC 更积极）
  · batch 调大（send_batch_size 8192-32768）
  · 关闭不需要的 processor（filter 优于后处理）
  · gzip 压缩导出（节省网络带宽 5-10x）
  · 水平扩展 + 按 Pipeline 拆分实例
  · 监控自身指标（otelcol_receiver_accepted_* 等）

五、核心处理器实战

5.1 Attributes：统一标签与脱敏

processors:
  attributes:
    actions:
      - key: http.user_agent
        action: delete                      # 删除高基数/敏感属性
      - key: account_id
        action: hash                        # 哈希化（保留可聚合性）
      - key: environment
        value: production
        action: upsert                      # 统一注入环境标签
      - key: db.connection_string
        action: extract                      # 提取子字段

5.2 Redaction：敏感信息脱敏

processors:
  redaction:
    # 允许的键外全部删除
    allow_all_keys: false
    allowed_keys:
      - http.method
      - http.route
      - http.status_code
    blocked_values:
      - "password"
      - "authorization"
    ignore_keys:
      - message                     # 允许 message 原样

5.3 Filter：降噪

processors:
  filter/traces:
    traces:
      span:
        - attributes["http.route"] == "/healthz"      # 丢弃健康检查
        - attributes["http.route"] == "/metrics"      # 丢弃自监控
  filter/logs:
    logs:
      log_record:
        - IsMatch(body, "DEBUG") == true              # 丢弃 DEBUG

六、导出与多后端路由

6.1 单一导出器 vs 多路由

# 方式一：全部发给一个后端（简单）
exporters:
  otlp/central:
    endpoint: gateway.monitoring:4317

# 方式二：按条件路由（生产推荐）
processors:
  routing:
    table:
      - service: ai-team
        receivers: [otlp]
        pipeline: traces
        exporters: [otlp/tempo, jaeger/ai-team]
    default_exporters: [otlp/tempo]

6.2 同时发送到多个后端

exporters:
  prometheusremotewrite/central:
    endpoint: http://mimir-central:9009/api/v1/push
  prometheusremotewrite/backup:
    endpoint: http://mimir-backup:9009/api/v1/push

service:
  pipelines:
    metrics:
      processors: [batch]
      receivers: [otlp]
      exporters: [prometheusremotewrite/central, prometheusremotewrite/backup]

6.3 Kafka 作为缓冲层（大规模）

exporters:
  otlp/kafka:
    protocol: otlp
    brokers: [kafka-0:9092, kafka-1:9092]
    topic: otel-traces
  otlp/loki:
    endpoint: loki-gw:4317

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp/kafka]       # 先入 Kafka 缓冲
    # 下游独立 Pipeline 从 Kafka 消费后再导出

七、高可用与水平扩展

7.1 Gateway 模式的扩展性

水平扩展设计：
  · Collector Gateway 无状态，可任意横向扩容
  · 前端用负载均衡（K8s Service / Nginx / Envoy）
  · Trace 完整性：Tail sampler 需按 TraceID 一致哈希，
    保证同一 Trace 落到同一 Collector 实例
  · 各实例间用共享状态（Redis/Jaeger 采样策略）可选

7.2 K8s 部署示例

# collector-daemonset.yaml — Agent 模式
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: otel-collector-agent
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: otel-agent
  template:
    metadata:
      labels:
        app: otel-agent
    spec:
      tolerations:
        - operator: Exists
      containers:
        - name: collector
          image: otel/opentelemetry-collector-contrib:0.100.0
          args: ["--config=/etc/otel/config.yaml"]
          resources:
            limits:
              memory: 1Gi
          env:
            - name: MY_POD_IP
              valueFrom:
                fieldRef:
                  fieldPath: status.podIP
          volumeMounts:
            - name: config
              mountPath: /etc/otel
      volumes:
        - name: config
          configMap:
            name: otel-agent-config

7.3 一致性哈希与 Tail Sampling 扩展

Tail sampler 水平扩展的关键：
  同一 TraceID 的所有 Span 必须路由到同一实例。
  方案：
    · 前端 LB 按 TraceID 哈希（nginx hash $traceparent）
    · 或使用支持 consistent-hash 的网关（Envoy 自定义）
  否则采样决策会基于不完整的 Trace 做出

八、安全与访问控制

8.1 TLS 与认证

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
        tls:
          cert_file: /etc/otel/server.crt
          key_file: /etc/otel/server.key
          ca_file: /etc/otel/ca.crt
        # 客户端证书双向认证
        auth:
          type: mTLS

exporters:
  otlp/tempo:
    endpoint: tempo:4317
    tls:
      ca_file: /etc/otel/ca.crt
    headers:
      Authorization: "Bearer ${TEMPO_TOKEN}"

8.2 限流与配额

receivers:
  otlp:
    protocols:
      http:
        endpoint: 0.0.0.0:4318
        # 每个客户端限流（保护 Collector）
        auth:
          # 自定义认证扩展，返回限流决策
          type: auth_limiter

8.3 网络安全

Collector 安全清单：
  · 只暴露内部端口（4317/4318），不暴露公网
  · Agent 通过 DaemonSet hostPort 供本节点应用访问
  · Gateway 放在内网 Service 之后
  · 数据中敏感字段用 redaction 处理器脱敏
  · 审计 Collector 自身指标与配置变更

九、大规模生产部署参考

9.1 完整架构

应用(SDK) ──► OTLP ──► Agent Collector ──► Gateway Collector ──► 后端
  多语言        │           │ 采样/脱敏/批      │ 路由/认证/降采样
  埋点         │           └─► Kafka(可选缓冲)──┘
              └───────────────────────────────────► 直连后端(小流量)

后端拆分：
  traces  → Tempo（+ Parquet 长期存储）
  metrics → Mimir / Thanos（PRW 写入）
  logs    → Loki（对象存储）

9.2 配置管理（GitOps）

# 配置用 ConfigMap/Helm 管理，版本化可回滚
# 建议监控以下 Collector 自身指标：
otelcol_receiver_accepted_spans
otelcol_processor_batch_batch_send_size
otelcol_exporter_sent_spans
otelcol_exporter_send_failed_spans
otelcol_processor_tailsampling_sample_received
otelcol_processor_tailsampling_sample_decision_latency_milliseconds

9.3 容量规划

容量估算（粗略）：
  · Agent 单实例：稳定承载 10k-50k Spans/s（取决于采样与脱敏开销）
  · Gateway 单实例：50k-200k Spans/s（纯转发）
  · 内存：1 Span ≈ 300-500B（未采样原始），采样后显著降低
  · 规划公式：总采样率 × 原始吞吐 = 后端存储吞吐

调优经验：
  · 先 Tail sampling 砍存储，再调 batch 提吞吐
  · Gateway 每个 Pipeline 拆独立实例（traces 与 logs 分开扩）
  · 用 otelcol 自身指标做告警，别等存储爆了才发现

总结：OTel Collector 的核心要点

层	关键决策
部署模式	Agent（轻处理）+ Gateway（重处理）两层
Pipeline	Receivers → Processors → Exporters 解耦数据流
成本控制	Tail sampling（错误全留+概率采样）+ Batch
性能	memory_limiter + 大 batch + gzip + 队列背压
多后端	routing 处理器 / 多 exporter + Kafka 缓冲
高可用	无状态水平扩展 + TraceID 一致哈希
安全	mTLS + 认证 + redaction 脱敏 + 内网隔离

OTel Collector 是可观测性架构的"路由器与净化器"——所有数据在此汇聚、被采样、被脱敏、被分发给正确后端。把 Collector 设计好，后续存储成本、排查效率、合规要求都建立在可靠的基础上。落地时记住三条主线：采样策略决定成本，Pipeline 解耦决定灵活性，安全加固决定可信度。先设计好这条管道，再谈后端的规模化。

继续阅读

探索更多技术文章

浏览归档，发现更多关于系统设计、工具链和工程实践的内容。

全部文章返回首页