OpenTelemetry 日志与指标关联为什么需要统一上下文

OpenTelemetry 日志与指标关联需要统一上下文，核心原因不是“把三种数据放进同一个平台”，而是让它们能回答同一个问题：这条异常日志属于哪一次请求，这个请求对应哪个 Span，指标上的异常观测又来自哪个执行上下文。2026 年 5 月，CNCF 宣布 OpenTelemetry 毕业，生态成熟度提高后，真正值得落地的重点也从“能不能采集”转向“能不能关联”。

官方地址：https://opentelemetry.io/

如果日志、指标和 Trace 只共享时间，却没有共享 trace context 与 Resource 属性，排障时仍然要靠人工猜测。统一 Context、日志中的 TraceId/SpanId、指标 exemplar 和资源字段，才会形成可跳转、可解释的证据链。

为什么三类数据都采集了，定位仍然很慢

最常见的场景是接口延迟升高：指标告诉你某个接口变慢，日志里有一条超时记录，Trace 后端也能看到请求，但三者无法互相跳转。原因通常不是数据缺失，而是关联键不一致。

只按时间关联很脆弱。同一秒内可能有成百上千个请求；只按服务名关联又太粗，无法区分一个请求经过的多个 Span。OpenTelemetry 把关联拆成三层：执行上下文用于识别一次请求，Resource 用于说明数据来自哪个服务实例、容器或主机，时间只作为辅助线索。

这也是日志不能只保留一段 message 的原因。结构化日志至少要有稳定的时间、严重级别、消息字段，以及在请求处理上下文存在时写入的 TraceId 和 SpanId。指标则不应把每个 TraceId 都直接做成高基数标签，而是通过 exemplar 保存少量观测值与 Trace context 的关联。

统一上下文到底统一了什么

Context 不是一张全局表，而是随执行单元传递的上下文对象。服务入口从请求头提取远端传播信息，创建或继续本地 Span；调用下游服务时再注入传播信息。这样，跨进程的请求才可能维持同一个 Trace 的因果关系。

在应用内部，日志和指标也要使用同一个 Context。下面是一个示意片段，重点不是某一家后端的初始化，而是让日志写入和指标记录共享 ctx：

func handle(ctx context.Context, counter metric.Int64Counter, logger *slog.Logger) {
    span := trace.SpanFromContext(ctx)
    traceID := span.SpanContext().TraceID().String()

    // 日志沿用当前 Context，桥接层才能补齐 TraceId 和 SpanId。
    logger.InfoContext(ctx, "开始处理订单", "trace_id", traceID)

    // 指标记录使用同一个 Context；exemplar 可保存这次观测对应的 Trace。
    counter.Add(ctx, 1, metric.WithAttributes(attribute.String("route", "/orders")))

    // 业务结束前仍要保留错误和资源属性，便于在采集端统一关联。
    logger.InfoContext(ctx, "订单处理完成", "result", "ok")
}

这里有三个边界需要分清：TraceId 是请求级身份，SpanId 是请求中某个操作的身份，Resource 属性则描述服务实例或运行环境。把 Pod 名、服务名等资源信息误当成请求 ID，仍然会导致同一实例上的日志彼此混淆。

从应用到 Collector，关联链要经过哪些阶段

可以把一条可关联的遥测管线拆成四个阶段。第一阶段是入口：HTTP 服务、消息消费者或 RPC 适配层提取传播头，并把结果放入当前 Context。第二阶段是应用内传递：函数调用、异步任务和下游客户端不能把 Context 丢在半路。

第三阶段是信号生产。日志桥接或 SDK 在 LogRecord 中写入 TraceId、SpanId；指标记录保留可关联的 exemplar，并使用稳定的业务维度，而不是把请求 ID 变成普通标签。第四阶段是 Collector 处理：接收器、处理器和导出器要保留这些字段，并用一致的 Resource 属性补充来源。

这套设计不要求所有日志都拥有 TraceId。系统日志、基础设施事件或脱离请求的后台任务可能只有 Resource context。关键是不要伪造 TraceId；没有执行上下文时，明确保留资源和时间信息，比写入一个无法追溯的占位符更可靠。

关联链断了时先查哪一层

第一检查入口传播：上游是否发送了标准传播头，服务入口是否真正提取并创建了当前 Context。第二检查异步边界：把工作交给队列、线程或后台协程时，是否显式传递了与任务相关的上下文；不要假设全局变量会自动跟随。

第三检查日志写入位置。OpenTelemetry 的日志关联依赖“写日志时仍能看到当前上下文”，如果日志由另一个无上下文的线程异步刷新，TraceId 可能自然缺失。第四检查 Collector 解析：纯文本日志需要可靠解析，结构化日志要避免在采集过程中丢掉字段。

第五检查指标维度。TraceId 不适合直接作为普通指标标签，因为每个请求都会制造新时间序列；应使用 exemplar 保存少量样本关联，再用低基数的路由、状态和服务属性做聚合。这样既保留从指标跳到 Trace 的入口，也不会用关联需求破坏指标系统。

采用前的四项检查

• 入口检查：跨服务请求是否提取并注入同一种传播上下文。
• 字段检查：日志是否能保留 TraceId、SpanId 和 Resource，指标是否支持 exemplar。
• 管线检查：Collector 的解析、处理和导出是否会删掉关联字段。
• 容量检查：指标标签是否保持低基数，日志和 Trace 的关联是否有明确采样策略。

OpenTelemetry 的统一上下文不是要求所有信号长得一样，而是给它们一套共同的身份、来源和关联规则。先把 Context 在入口、异步边界和信号写入处传对，再谈后端界面上的跳转体验，排障链才不会停在“看起来都采集到了”。

相关问题

日志没有 TraceId，是 OpenTelemetry 失效了吗？

不一定。脱离请求的系统日志、基础设施日志和后台任务可能没有 Trace context，但仍可通过 Resource、时间和结构化字段参与定位。

为什么不把 TraceId 直接加成指标标签？

因为 TraceId 通常是高基数且近似每请求变化，直接做普通标签会放大时间序列数量。exemplar 更适合保存观测值与 Trace 的少量关联。