OpenTelemetry 日志信号如何与现有采集链衔接

OpenTelemetry 日志信号的实际价值，不是把所有日志立刻换成一种新格式，而是给应用日志、文件日志和 Syslog 建立一套可以互相理解的字段语义。CNCF 在 2026 年宣布 OpenTelemetry 毕业后，日志、指标和追踪继续沿着同一套采集与处理思路演进；已有采集链完全可以采用渐进式接入。

官方地址：https://opentelemetry.io/docs/specs/otel/logs/

先理解日志信号要统一什么

OpenTelemetry 的日志数据模型把一条记录拆成几个稳定部分：Timestamp 表示事件发生时间，ObservedTimestamp 表示采集系统看到它的时间；SeverityText 与 SeverityNumber 用于展示和排序；Body 保存字符串或结构化内容；Resource 描述产生日志的服务或主机；Attributes 描述本次事件；TraceId 和 SpanId 则用于和追踪关联。

迁移时最容易混淆的是 Resource 和 Attributes。服务名、部署环境这类稳定信息应放在 Resource；请求编号、订单号或错误类型这类随事件变化的信息放在 Attributes。只把原始文本塞进 Body，后端虽然能收日志，却很难做可靠筛选和关联。

按来源选择接入方式

已经写入文件的应用或系统日志，通常先由 Collector 的 filelog receiver 读取，再完成解析、字段映射和导出；Syslog 则按现有网络入口接收。新写的应用可以使用语言日志库的 OpenTelemetry 桥接，把既有日志调用保留下来，同时补充上下文。

因此，第一阶段不必同时改应用、采集器和后端。更稳妥的顺序是：保留原有日志格式，新增一个 Collector 旁路；确认解析后的 Body、Severity 和 Resource 正确后，再逐步让应用输出结构化日志。

用 Collector 串起接收、处理和输出

Collector 的组件职责很清楚：receiver 负责接入，processor 负责过滤、补字段或批处理，exporter 负责送往后端。下面是一份表达结构的最小配置片段，具体 receiver 与 exporter 名称要按所使用的发行版组件清单调整。

receivers:
  filelog/app:
    include: [/var/log/app/*.log]
    # 先限定文件范围，避免把系统无关日志混入业务流

processors:
  batch/logs:
    # 批量发送可减少连接与请求开销，大小需按延迟目标调整

exporters:
  otlphttp/backend:
    endpoint: https://observability.example/v1/logs
    # 这里只示意输出位置，生产环境还应配置认证和超时

service:
  pipelines:
    logs:
      receivers: [filelog/app]
      processors: [batch/logs]
      exporters: [otlphttp/backend]

先补关联字段，再谈全面迁移

如果目标是把日志和追踪串起来，优先检查应用是否能把请求上下文写入 TraceId、SpanId，而不是先追求所有日志格式完全一致。对无法修改的第三方程序，先接受其原始文本，再在 Collector 中解析稳定字段；解析失败时保留原始 Body，并记录失败原因，避免为了规范化而丢失原始信息。

灰度阶段至少观察四项：解析成功率、字段缺失率、单条日志体积、后端查询成本。新链路只要能稳定解释来源、级别和关联 ID，就具备继续扩大范围的条件。若后端暂时不支持 OTLP，也可以让 Collector 继续导出到原有日志接口，先把统一模型放在采集层。

常见问题

必须重写所有日志代码吗？

不必须。文件日志、Syslog 和现有日志库都可以先由 Collector 或桥接层接入，重写应用只在需要更丰富结构化事件时进行。

Timestamp 和 ObservedTimestamp 都要保存吗？

能保留就都保留。前者回答事件何时发生，后者回答采集系统何时看到它，跨主机时钟或传输延迟异常时尤其有用。

Resource 能不能放请求字段？

不建议。Resource 描述稳定的产生者，请求级数据放在 Attributes，避免同一服务因为每个请求不同而产生大量资源组合。

什么时候适合让应用直接发 OTLP？

当应用能控制日志结构、后端支持网络接收，并且已经明确评估本地文件可读性、重试和网络故障处理后，再考虑直接发送。

OpenTelemetry 日志信号更适合作为现有采集链的统一语义层。先从一个服务或一类文件日志开始，验证字段和成本，再扩展到更多来源，迁移风险会明显低于一次性替换整套日志系统。