OpenTelemetry Collector 接入实战：一套配置收齐 K8s 的日志、指标、链路

为什么用 Collector 而不是直连 SDK

给每个服务逐个接 SDK、各自配上报地址，服务多了之后就是一场噩梦：上报地址改了要改几十个服务，采样策略没法统一，网络抖动时 SDK 的重试逻辑各不相同。更麻烦的是，日志、指标、链路往往要走三个不同的接收端，配置重复且容易漏。

OpenTelemetry Collector 把这些收口到一处：它作为集群内的一个（或一组）常驻采集器，统一接收来自各服务的 OTLP 数据，做采样、批处理、脱敏，再转发到炬鲸 OBSERVE。应用侧只关心一件事——把数据发到本地的 Collector，剩下的事交给它。

部署 Collector：Helm 三步

官方 Helm Chart 是最省事的方式。三步完成：

# 1. 添加仓库
helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
helm repo update

# 2. 安装（DaemonSet 模式，每个节点一个实例，就近接收日志）
helm install otel-collector open-telemetry/opentelemetry-collector \
  --set mode=daemonset \
  --set config.exporters.otlp.endpoint=ob.example.com:4317

# 3. 查看状态
kubectl get pods -l app.kubernetes.io/name=opentelemetry-collector

选择 DaemonSet 而不是 Deployment，是因为日志采集通常要读取节点上的容器日志文件，一个节点一个实例更直接；纯指标/链路场景也可以用 Deployment 做负载均衡。

配置三类数据接收与转发

核心是 config.yaml 里的 pipeline。下面这份配置同时接收日志、指标、链路，统一用 OTLP 协议转发到炬鲸 OBSERVE：

receivers:
  otlp:
    protocols:
      grpc: { endpoint: 0.0.0.0:4317 }
      http: { endpoint: 0.0.0.0:4318 }
  filelog:
    include: [/var/log/pods/*/*/*.log]
    operators:
      - type: container
        id: container-parser

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

exporters:
  otlp:
    endpoint: ob.example.com:4317
    headers:
      Authorization: "Bearer <你的接入Token>"

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

要点：memory_limiter 放在最前面，防止上游突发流量把 Collector 打爆；batch 把零散数据打包再发，降低下游压力；鉴权用 Header 里的 Token，在 exporters.otlp.headers 里配置。

验证与常见坑

部署完成后，制造几条日志和一次请求，回到炬鲸 OBSERVE 控制台用类 SQL 查询验证：

SELECT * FROM logs WHERE service = 'your-service' ORDER BY ts DESC LIMIT 20;

常见的坑：

• 收不到数据：先看 Collector 日志有没有 exporter 报错，八成是 Token 或 endpoint 写错
• 日志重复/丢失：检查 DaemonSet 是否每个节点都起来了，以及 filelog 的 include 路径是否匹配
• 时区错乱：容器内时区与宿主机不一致，日志时间会整体偏移，统一用 UTC 或统一设 TZ
• 内存飙升：memory_limiter 没生效时，高峰流量会撑爆 Pod，确认 limit_mib 设置合理

把 Collector 当成集群的基础设施来运维：固定版本、统一配置、监控它自身的健康度。它稳定了，上游所有服务的数据才有保障。