跨机房链路追踪需规避性能负担：禁用全量采样，改用ParentBased+TraceIDRatioBased(0.01)；导出必须用OTLP/gRPC+TLS复用与gzip压缩；HTTP头传播需精简tracestate或改用缓存引用；延迟归因须剥离网络RTT。
跨机房调用本身就会引入几十毫秒级的网络延迟，链路追踪若再叠加上下文传递开销、采样策略不当或导出瓶颈，很容易把可观测性变成性能负担。关键不是“要不要追踪”，而是“怎么让追踪不拖慢请求”。
OpenTelemetry SDK 初始化必须禁用全量采样
默认 trace.AlwaysSample() 在跨机房场景下是高危配置：每个 Span 都要序列化、编码、打包、发送，尤其当链路深（>5 跳）、QPS 高（>1k）时，CPU 和网络出口带宽会迅速成为瓶颈。实测显示，在北京→新加坡机房调用中，全量采样会使平均请求延迟抬升 80ms+，且 p99 毛刺明显。
- 生产环境应改用
trace.ParentBased(trace.TraceIDRatioBased(0.01))，即仅对 1% 的 Trace 采样（可根据 P99 延迟和日志量动态调整） - 对已知慢请求（如耗时 >500ms）可临时启用强制采样：
span.SetAttributes(attribute.Bool("force_sample", true))，并在 Exporter 中识别该 tag 后 bypass 采样判断 - 避免在中间件里反复调用
tracer.Start()创建嵌套 Span 而不结束——未 finish 的 Span 会阻塞 batcher 缓冲区，导致后续请求卡在span.End()调用上
跨机房 Span 导出必须走 OTLP/gRPC + TLS 复用
Jaeger Thrift over UDP 或 Zipkin HTTP JSON 在跨机房场景下丢包率高、无重试、不可压缩，极易造成 Span 数据丢失或延迟堆积。OTLP/gRPC 是唯一能兼顾可靠性与效率的选择，但需注意三点：
- 必须复用
*grpc.ClientConn：每次新建 conn 都会触发跨机房 DNS 查询 + TLS 握手（平均 +120ms），应全局单例并设置grpc.WithTransportCredentials(credentials.NewTLS(...)) - 显式启用压缩：
otlpgrpc.WithGRPCDialOption(grpc.WithCompressor(gzip.NewGZIPCompressor()))，实测对典型 Span（含 service.name、http.route、error 等标签）可压缩 60%+ 体积，降低跨机房带宽压力 - 导出超时设为
5s，并配置WithRetry(otlpretry.NewExponential())：跨机房网络抖动常见，短超时会导致 Span 丢弃，长超时又拖慢业务请求
HTTP 客户端传播 TraceContext 必须绕过 Header 大小限制
跨机房调用常经多层 LB、API 网关、WAF，它们普遍对 HTTP Header 总长有限制（常见 8KB～32KB）。OpenTelemetry 默认将 TraceID、SpanID、TraceFlags、TraceState 全部注入 traceparent 和 tracestate，若链路跳数多（>8）、自定义属性多（如 user.id、tenant.id），Header 很容易超限，被网关截断或拒绝。
- 优先使用 W3C Trace Context 标准，禁用旧版
b3或jaegerheader 格式——后者字段冗余、长度不可控 - 精简
tracestate：默认会透传所有上游服务的 vendor state，跨机房时建议只保留本集群内必需字段，用otel.SetTextMapPropagator自定义 propagator 过滤掉非关键 vendor - 对超长 context，改用“引用传递”：将完整 tracestate 存入中心缓存（如 Redis），Header 中只传 short-id，下游按需拉取——适合对一致性要求不极端的分析场景
延迟归因必须区分网络传输 vs. 服务处理
跨机房链路中，Span.End() - Span.Start() 给出的是“端到端耗时”，但真正要优化的是“服务处理时间”。如果不对网络延迟做剥离，你会误判瓶颈——比如看到库存服务 Span 耗时 320ms，实际其中 210ms 是北京→上海的 RTT，真实处理只占 110ms。
- 在客户端 Span 上打标：
attribute.String("net.peer.ip", "10.10.20.5")和attribute.Int("net.peer.port", 8080)，后端可据此匹配地理信息库估算理论最小 RTT - 服务端 Span 记录接收时间戳（
time.Now()在读取完 request body 后），而非 handler 入口时间——这样才能排除 TCP 接收缓冲区排队影响 - 在 Jaeger/Tempo 中用
duration - (rtt_estimate / 2)作为服务真实耗时指标，避免把网络抖动当成业务慢
跨机房链路追踪最易被忽略的点，是把“采集完成”等同于“数据可用”：Span 导出成功 ≠ 后端已索引 ≠ 可视化界面能查到。务必在 Collector 层开启 OTLP 接收成功率、batcher drop rate、exporter queue length 三项监控，否则你看到的“低延迟链路图”，可能只是尚未导出的幻觉。
