用 OpenTelemetry Collector 统一接入日志、指标与链路

为什么要用 Collector，而不是逐个接 SDK

直接给每个应用接入 OpenTelemetry SDK 当然可行，可一旦服务多起来问题就来了：每种语言都要维护一套 SDK 版本和一套导出配置，改个上报地址要动几十个服务；SDK 升级、采样策略调整，都要跟着每个应用重新发版。对运维和开发都是持续的负担。

Collector 把这些收口到一处——应用只负责把数据交给本机或集群内的 Collector，由它统一做接收、处理、导出。你改一次导出地址，所有应用跟着生效；想加字段过滤、脱敏、采样，也只在 Collector 里配一次。

对炬鲸 OBSERVE 来说，你只需要维护一个 Collector，所有应用的日志、指标、链路都从它汇入平台，接入面从「每个应用一份配置」变成「一份 Collector 配置」。

部署 Collector：一份配置搞定三类数据

推荐每台主机跑一个 Agent 模式的 Collector 就近采集，再（可选）加一个 Gateway 做集中处理和转发。最小配置一个单文件即可：

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

exporters:
  otlphttp:
    endpoint: https://ob.example.com/v1/otlp
    headers: { Authorization: "Bearer <token>" }

service:
  pipelines:
    traces:  { receivers: [otlp], exporters: [otlphttp] }
    metrics: { receivers: [otlp], exporters: [otlphttp] }
    logs:    { receivers: [otlp, filelog], exporters: [otlphttp] }

关键点：三个 pipeline 复用同一个 otlphttp exporter，把日志、指标、链路一起推到炬鲸 OBSERVE，平台端按数据类型自动入库，你不需要在平台侧做任何分类配置。

应用侧只需三行环境变量

应用不用关心导出细节，只用 SDK 把数据发到本机 Collector：

OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317
OTEL_SERVICE_NAME=order-service
OTEL_RESOURCE_ATTRIBUTES=service.name=order-service,env=prod

Java 应用加 -javaagent:opentelemetry-javaagent.jar 自动埋点，Python 用 opentelemetry-instrument 包一层，Go 用 go.opentelemetry.io/otel 的默认导出器，都不用改业务代码。埋点范围建议先从 HTTP 入口、数据库访问、消息队列这三类开始，覆盖 80% 的常见故障。

用 Processor 做字段注入与脱敏

Collector 的 processor 是接入层最值得挖的部分。三个高频用法：

1. 统一注入资源属性：用 attributes processor 给所有数据打上 env、region、team 标签，检索时维度统一
2. 日志脱敏：用 redaction processor 把手机号、身份证号、Token 等敏感字段打码后再上报
3. 批量发送：用 batch processor 攒一批再发，减少请求、降低平台压力

processors:
  attributes:
    actions:
      - key: env
        value: prod
        action: upsert
  redaction:
    allow_all_keys: true
    blocked_values: ["\\d{11}", "\\d{17}[\\dXx]"]
  batch:
    timeout: 5s
    send_batch_size: 1024

service:
  pipelines:
    logs:
      receivers: [otlp, filelog]
      processors: [attributes, redaction, batch]
      exporters: [otlphttp]

脱敏一定要放在上报之前——敏感字段一旦落到平台存储里，再删就麻烦了。这也是为什么在 Collector 统一处理，比在每个应用里各写一份脱敏逻辑更可靠。

生产环境四条建议

1. 用 filelog 收存量日志：老应用没接 SDK 也没关系，Collector 直接读日志文件解析，先让日志进平台，再逐步迁移到 OTLP
2. buffer 兜底：给 exporter 配 sending_queue 和 retry_on_failure，平台短暂不可用时不丢数据
3. 资源属性统一：env、region、team 这些维度在 Collector 里统一注入，别让每个应用各写一套，否则检索时维度对不齐
4. 注意采样：链路量大的话在 Collector 里配 tail_sampling，只保留慢请求和出错请求，兼顾成本与覆盖

验证接入

接入后到控制台，用一条类 SQL 查询确认三类数据都到了：

SELECT * FROM logs WHERE service = 'order-service' LIMIT 10

再到「链路追踪」里按 trace id 串出完整调用链，确认 span 没有断层。日志、指标、链路三者时间对齐，排查时才不用来回翻页面。

常见问题

• 日志一直不上来：先看 Collector exporter 有没有 4xx/5xx，再确认 Token 和网络连通性，注意 OTLP HTTP 与 gRPC 端口别配反
• 时间戳对不上：检查应用与服务器时区，Collector 只透传时间、不改写
• trace 有断层：确认下游 HTTP/消息客户端也注入了 trace 上下文并正确透传，否则链路在中途断开
• 内存占用偏高：给 Collector 配 memory_limiter processor 限制内存上限，别把采集主机拖垮