用 OpenTelemetry Collector 统一上报日志、指标和链路

为什么需要一个 Collector

很多团队接入可观测平台的方式是：日志用 Logback Appender，指标用 Micrometer，链路用 OTel SDK，各自为政。应用一旦多了，这三套配置就成了维护负担，改一个采集地址要动几十个服务。更糟的是，三条链路各管各的采样、缓冲、重试，三类信号越来越难对齐，故障时根本对不上号。

OpenTelemetry Collector 把这个问题收口到一处：应用只管把遥测数据发到 Collector，由 Collector 统一做过滤、脱敏、路由和上报。要切后端，改 Collector 一处即可。

四个概念串起整份配置

Collector 的组织方式围绕四个概念，弄懂它们，配置就没那么吓人了：

• Receivers：接收或拉取遥测，比如 OTLP（gRPC/HTTP）收链路和指标，filelog 收日志文件；
• Processors：处理在途数据，比如批量、内存上限、脱敏、过滤；
• Exporters：把数据发到后端，这里就是指向炬鲸 OBSERVE 的 OTLP HTTP exporter；
• Pipelines：把上面三者串起来，每种信号各有一条「receivers → processors → exporters」链路。

正因为这种分层，一个 Collector 才能同时服务日志、指标、链路，而且每种信号可以挂不同的 processor。

部署 Collector

推荐用二进制或容器跑单实例（Agent 模式），和你的服务放在同一台机器或同一个 Pod 里，数据先本地汇聚再统一外发：

docker run -d --name otelcol \
  -v ./otelcol-config.yaml:/etc/otelcol/config.yaml \
  otel/opentelemetry-collector-contrib:0.95.0

下面是一份把三类信号一起送进炬鲸 OBSERVE 的配置骨架：

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: regex_parser
        regex: '^(?P<ts>[^ ]+) (?P<level>\w+) (?P<msg>.*)$'

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

exporters:
  otlphttp:
    endpoint: https://ob.example.com/otlp
    headers:
      Authorization: "Bearer ${OBSERVE_TOKEN}"

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

三个 pipeline 复用同一个 otlphttp exporter，日志、指标、链路一次配置到位。规模大了之后，可以再加一台 Gateway 模式的 Collector 汇聚多台 Agent，但先从 Agent 模式起步。

应用侧改动

应用不用直连平台，统一指向本机 Collector 的 4317 端口：

export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317
export OTEL_SERVICE_NAME=order-service
java -javaagent:opentelemetry-javaagent.jar -jar app.jar

Java、Go、Python 都有现成的 Agent 或 SDK，挂上之后日志、指标、链路会按 OTLP 协议自动上报。应用如果加不了依赖，也可以靠上面的 filelog receiver 直接 tail 日志文件，转成结构化记录发出去。

脱敏和过滤要放这里

Collector 是统一做数据治理的最佳位置。生产日志里常混着手机号、身份证号，建议在 processors 里加 redaction 或 transform，把敏感字段在上报前就抹掉，而不是等数据进了平台再补救：

processors:
  redaction:
    allow_all_keys: false
    blocked_values: ["\d{11}", "\d{18}"]

验证数据真的进来了

应用启动后，在控制台用类 SQL 查一下：

SELECT * FROM logs WHERE service = 'order-service' ORDER BY ts DESC LIMIT 10

再到链路列表里找一条最近的请求点开，确认 span 嵌套正常。如果日志到了、链路没到，多半是 trace pipeline 漏配了 receiver，或者 exporter 写错了。

排障检查清单

• 数据没上来：先 curl http://localhost:4318/v1/traces 看 Collector 是否活着；
• 只有一种信号：检查对应的 pipeline 是否漏配了 receiver；
• 报 401：确认 Authorization 头里的 Token 和平台「服务管理」里的一致；
• 时区对不上：统一用 UTC 或显式配置时区，避免链路时间和日志时间错位。