#Baggage 与业务数据传递

链路追踪记录的是请求在服务间的流转路径，但如果只有 TraceID 和 Span 信息，很多分析场景是不够的。例如，你想分析「来自某个营销活动的请求延迟是否更高」，这需要知道请求携带的「活动 ID」；你想分析「VIP 用户的请求质量」，这需要知道请求关联的「用户等级」。

Baggage 是 OpenTelemetry 提供的跨进程传递业务上下文的机制。它允许在请求入口注入键值对，这些键值对会随着 Trace 的传播自动携带到所有下游服务，无需在每个服务手动传递。

#Baggage vs Span Attributes

Baggage 和 Span Attributes 都用于存储键值对，但语义和用途不同：

Span Attributes 是 Span 的元数据，描述这个 Span 的执行上下文（如 HTTP 方法、URL 路径、数据库名称）。Attributes 只属于当前 Span，不会自动传播到下游。

Baggage 是请求级别的上下文，会随着 Trace 传播自动注入到所有下游请求的 Baggage 中。它用于传递「请求从哪来、属于哪个业务场景」这类贯穿整个请求链路的信息。

#使用场景

Baggage 的典型使用场景：

灰度发布分析：在请求入口注入 x-canary-version 标签，追踪不同版本的性能差异。无需修改业务代码，下游服务通过读取 Baggage 中的 canary-version 即可按版本聚合分析。

多租户隔离分析：SaaS 系统中，注入 tenant-id，追踪不同租户的请求质量。当某个租户投诉时，可以通过 tenant-id 快速过滤出该租户的完整调用链。

AB Test 分析：注入 experiment-id 和 variant，追踪不同实验组的转化率和性能差异。

#实现机制

Baggage 通过 HTTP Header 传播。OpenTelemetry SDK 会在发送 HTTP 请求时，自动将 Baggage 内容序列化到 tracestate 和 baggage Header 中；接收方 SDK 自动解析这些 Header，将 Baggage 内容注入到本地 Context。

Baggage 的数据量和传播深度需要控制：每个 Baggage 项建议不超过 1KB；Baggage 会随每个请求传播，过多的 Baggage 项会增加网络开销和序列化成本。