OpenTelemetry 全链路接入：日志、指标、追踪一次配齐

为什么用 OpenTelemetry

接入可观测平台最常见的错误，是给日志、指标、追踪各装一套 Agent，三套配置、三套上报，改起来互相打架。更糟的是，三套数据之间没有关联：日志里没有 trace_id，指标里没有服务维度，出问题时你只能在三个页面之间来回跳。

OpenTelemetry（OTel）的思路是把采集统一起来：应用侧一个 SDK 埋点，采集侧一个 Collector 汇聚，再统一走 OTLP 协议上报到后端。日志、指标、追踪共享同一套资源标签和 trace context，天然能关联起来。

炬鲸 OBSERVE 原生支持 OTLP，只要把数据推到平台，日志、链路、指标就都进来了。

第一步：起一个 Collector

Collector 是 OTel 的核心，负责接收（receiver）、处理（processor）、导出（exporter）三类信号。用 Docker 起一个：

receivers:
  otlp:
    protocols:
      grpc: { endpoint: 0.0.0.0:4317 }
      http: { endpoint: 0.0.0.0:4318 }
processors:
  batch: { timeout: 5s }
exporters:
  otlphttp:
    endpoint: https://ob.example.com/otlp
    headers: { Authorization: "Bearer <token>" }
service:
  pipelines:
    traces:  { receivers: [otlp], processors: [batch], exporters: [otlphttp] }
    metrics: { receivers: [otlp], processors: [batch], exporters: [otlphttp] }
    logs:    { receivers: [otlp], processors: [batch], exporters: [otlphttp] }

docker run -v $PWD/otel-collector.yaml:/etc/otel/config.yaml   otel/opentelemetry-collector-contrib:0.90.0

batch processor 很关键：它把零散信号攒成批再发，减少网络开销和后端压力，别删掉。

第二步：应用侧埋点

Java 用 opentelemetry-javaagent，启动时加 JVM 参数即可，无需改代码：

java -javaagent:opentelemetry-javaagent.jar   -Dotel.service.name=order-service   -Dotel.exporter.otlp.endpoint=http://localhost:4317   -jar app.jar

Go 用 SDK 手动埋点，或直接接 otelhttp、otelgrpc 等 instrumentation 库。最关键的是把 trace context 在进程间传下去——HTTP 客户端要注入 traceparent 头，gRPC 要透传 metadata——否则链路到每个服务边界就断掉。

第三步：对资源打标签

在 Collector 里给所有信号统一加 service.name、env、cluster 等资源属性，检索和告警就能按这些维度过滤。建议遵循 OTel 语义约定，字段名保持一致，别各团队各写各的：

processors:
  resource:
    attributes:
      - key: env
        value: prod
        action: upsert

常见坑

• 链路断了：检查 HTTP/gRPC 客户端是否也注入了 trace context（otelhttp / otelgrpc）
• 日志和 Trace 对不上：确认日志里带了 trace_id、span_id，可在日志 exporter 里补上
• 时间漂移：所有主机开启 NTP，避免跨服务对时间对不上
• 采样丢了关键链路：高流量服务全量采集太贵，用尾部采样（tail sampling）保住错误和慢请求，别一刀切按比例丢

一次把三类信号配齐，后续新增服务只需复用同一套 Collector 和上报地址，不用再逐个折腾。