跨机房链路追踪不准的根本原因是span耗时未与网络层延迟对齐，jaeger/otel记录的end时间掩盖了tcp缓冲、tls重协商、nat丢包等真实网络开销，需补net.conn建连耗时和请求级往返时间观测，并确保traceparent头透传及连接池按机房隔离。
跨机房调用的链路追踪不能只靠埋点，必须和网络层延迟特征对齐——否则看到的 Span 耗时里混着大量不可控的网络抖动、TLS 重协商、中间设备静默断连，根本分不清是代码慢还是线路差。
为什么 Jaeger/OTel 显示的 Span 耗时不准？
跨机房场景下，Span.End() 记录的是服务端 WriteHeader 或 gRPC SendMsg 返回的时间点，但此时数据可能还卡在 TCP 发送缓冲区、被 NAT 设备丢包重传、或正等 TLS session resumption。真实网络耗时被掩盖了。
- 典型表现：同一对服务间，
Span耗时在 80–350ms 波动，但tcpdump抓包显示 SYN-ACK 平均就占 40ms，TLS 握手再加 60ms，纯网络开销已超 100ms - 根本原因：OpenTelemetry 默认不采集网络层指标，
http.Client的Transport也不暴露底层连接建立细节 - 解决方案不是“换更准的 tracer”，而是补两层观测：
net.Conn级别的建连耗时（用http.Transport.DialContexthook），以及每个请求实际的write+read往返时间（用自定义RoundTripper）
如何让 TraceId 在跨机房 HTTP 头中稳定透传？
机房间通常有统一 LB（如 F5、Nginx Ingress Controller），它们默认会清洗或重写 traceparent 这类非标准头。光在 Go 代码里调用 propagators.TraceContext{}.Inject 没用。
- 必须确认 LB 是否开启
underscores_in_headers on（否则trace_id这种带下划线的 header 会被直接丢弃） - 推荐改用 W3C 标准的
traceparent和tracestate头，它们是连 LB 都不敢乱删的“白名单字段” - Go 侧初始化时显式指定传播器：
otel.SetTextMapPropagator(propagation.TraceContext{})，别依赖默认 - 如果 LB 强制小写 header 名（如 AWS ALB），需在服务入口加一层 middleware 将
traceparent→Traceparent重写，否则 OTel SDK 解析失败
HTTP 客户端连接池必须按机房维度隔离
跨机房调用若复用同一个 http.Client，MaxIdleConnsPerHost 会把北京和新加坡两个 endpoint 的空闲连接混在一起管理，导致连接复用率暴跌、频繁重建。
- 错误做法：
var client = &http.Client{Transport: defaultTransport}全局复用 - 正确做法：为每个目标机房地址单独初始化
http.Client，并配独立Transport，例如：beijingClient := &http.Client{Transport: newTransport("beijing")} -
IdleConnTimeout必须设为 ≤30s：跨机房 NAT 设备普遍在 60s 后静默回收空闲连接，超时设太长会导致下次请求触发connect: connection refused - 禁用
http.DefaultClient—— 它的连接池是全局共享的，一旦某个机房接口抖动，会拖垮所有其他机房的连接复用
gRPC 跨机房调用必须启用 Keepalive 和 Channelz
gRPC 默认的 Keepalive 参数对跨机房极不友好：心跳间隔 2h，而多数云厂商 LB 的 idle timeout 是 60s，结果就是连接长期空闲后被 LB 断开，首次请求必卡在 reconnect 上。
- 必须显式配置客户端
keepalive.ClientParameters：Time: 30s（比 LB timeout 小）、Timeout: 10s（防心跳超时阻塞） - 服务端同步配
keepalive.ServerParameters，且MaxConnectionAge设为 25min（避免与客户端心跳错峰） - 上线前用
grpcurl -plaintext -v localhost:9090 grpc.channelz.v1.Channelz/GetTopChannels查看实际连接状态，确认state是READY而非IDLE或CONNECTING - 别信
WithBlock()：它会让grpc.Dial卡死在 DNS + TLS 阶段，跨机房环境下极易超时；改用WithTimeout+ 异步健康检查
真正难的不是埋点或配 collector，而是把链路追踪的 Span 时间戳和网络层 RTT、TLS 握手耗时、LB 转发延迟这三者对齐——否则你永远不知道那个 200ms 的 Span，到底是业务逻辑花了 180ms，还是光握手就用了 190ms。
