OpenTelemetry Collector 接入实战：采样、批处理与常见报错排查

为什么需要 Collector

直接让每个服务把数据推给平台，简单但脆弱：服务要感知采集端地址，网络抖动会丢数据，采样策略改一次要改所有服务。加一层 OpenTelemetry Collector 做中转，服务只连本机或内网 Collector，由它统一负责采样、批处理、重试和转发，职责更清晰。

一个可直接用的配置

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

processors:
  batch:
    send_batch_size: 512
    timeout: 5s
  memory_limiter:
    limit_mib: 512
    spike_limit_mib: 128
  tail_sampling:
    decision_wait: 10s
    policies:
      - name: errors-and-slow
        type: and
        and:
          and_sub_policy:
            - name: keep-errors
              type: status_code
              status_code: { status_codes: [ERROR] }
            - name: keep-slow
              type: latency
              latency: { threshold_ms: 500 }

exporters:
  otlphttp:
    endpoint: https://ob.example.com/v1/traces
    headers:
      Authorization: 'Bearer <token>'

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch, tail_sampling]
      exporters: [otlphttp]

三个关键点

• memory_limiter 放最前：它拦截内存尖峰，防止 Collector 因瞬时大流量被 OOM 杀掉。
• batch 合并请求：把零散 span 攒成批再发，显著降低网络和采集端压力。
• 尾采样看结果再决定：头采样在入口随机丢弃，尾采样等整条 trace 结束，只保留「出错或慢」的样本，排查时不会发现关键链路被采没了。日志和链路数据量是最大的成本来源，一个常用策略是：错误和超过 500ms 的请求 100% 保留，正常流量按 10% 采样，压住存储成本的同时保证慢请求和出错请求一条不漏。

最常见的三类报错

1. context deadline exceeded：Collector 到平台的网络超时。检查 endpoint 是否可达、是否有代理挡路，先用 curl -v 测一次。
2. 401 unauthorized：Token 错误或过期。在控制台重新生成，别把 Token 写进代码仓库。
3. 数据能采到但查不到：多半是时区不一致，span 时间戳和查询时间对不上。统一用 UTC 或显式配置时区。

验证链路是否打通

启动 Collector 后，用一个最小 demo 服务发一条 trace，回到控制台按 trace id 检索。能看到完整的调用链、span 属性和耗时，就说明链路通了。生产环境建议至少跑两个 Collector 实例挂在负载均衡后面，服务侧配好故障转移，同时把 Collector 本身也纳入监控——它出问题，等于所有服务的可观测都断了。