一份配置接入日志、指标、链路：OpenTelemetry Collector 接入炬鲸 OBSERVE

为什么用 Collector 而不是应用直连

应用直接上报到后端看起来简单，但坑不少：每个语言都要装对应 SDK，后端地址变更要改所有应用，网络抖动时没有缓冲和重试，采样策略散落在各个服务里难以统一。OpenTelemetry Collector 作为统一采集网关，把“接收、处理、导出”三段式架构收口到一处，应用只负责发，策略全在 Collector 上维护。

部署有两种形态：跑在每台机器上做 agent（就近采集、分担后端的协议转换压力），或集中部署做 gateway（统一认证、统一采样、统一路由）。规模小的时候一台 gateway 就够，规模大了建议“agent + gateway”两层。

部署 Collector

Collector 一个二进制即可部署。核心配置文件 otel-collector-config.yaml：

receivers:
  otlp:
    protocols:
      grpc: { endpoint: 0.0.0.0:4317 }
      http: { endpoint: 0.0.0.0:4318 }
processors:
  memory_limiter:
    check_interval: 1s
    limit_mib: 512
  batch:
    timeout: 1s
    send_batch_size: 1024
exporters:
  otlphttp:
    endpoint: https://ob.example.com/otlp
    headers:
      Authorization: "Bearer <接入Token>"
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlphttp]
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlphttp]
    logs:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlphttp]

启动：

otelcol --config otel-collector-config.yaml

应用侧接入

Java 应用用 javaagent 最省事，无需改代码，启动参数加上：

java -javaagent:opentelemetry-javaagent.jar \
  -Dotel.traces.exporter=otlp \
  -Dotel.metrics.exporter=otlp \
  -Dotel.logs.exporter=otlp \
  -Dotel.exporter.otlp.endpoint=http://collector:4317 \
  -Dotel.service.name=order-service \
  -jar app.jar

Go、Python、Node.js 同理，配好 OTEL_EXPORTER_OTLP_ENDPOINT 环境变量即可。注意 service.name 要规范统一，它决定了服务在控制台里的分组。

采样与过滤：控制成本

生产环境全量采集代价高，Collector 支持分层采样：

• 头部采样：在 SDK 端按比例丢弃，开销最小但可能丢掉重要链路
• 尾部采样：在 Collector 端等整条链路结束后再决定保留与否，能“错误全保留、正常按比例采”

建议配置：错误链路 100% 保留，正常链路按 1% 采样。日志侧可用 processor 过滤掉 DEBUG 级和敏感字段，减少无效存储。

验证关联性

发几笔带错误的请求，到控制台用 trace id 查一条链路，确认日志、指标、链路三者能通过 trace id 关联起来；再停掉一个下游服务，确认告警能触发。两个都通过，接入才算完成。