Span.End()记录的是服务端WriteHeader或gRPC SendMsg返回时间，但此时数据可能滞留TCP缓冲区、未完成TLS握手或遭遇NAT重传，导致真实网络延迟（如SYN-ACK 40ms、TLS 60ms）未被观测。
跨机房链路追踪不准，不是 tracer 本身有问题，而是 span 耗时没对齐真实网络开销——tcp 建连、tls 握手、nat 重传这些耗时全被吞掉了。
Span.End() 记录的时间点为什么不能反映真实网络延迟
OpenTelemetry 默认在服务端 WriteHeader 或 gRPC 的 SendMsg 返回时调用 span.End()，但此时数据可能还卡在 TCP 发送缓冲区，甚至还没发出去。真实网络延迟（SYN-ACK、TLS 握手、中间设备丢包重传）完全没被观测到。
- 典型表现：
Span耗时在 80–350ms 波动，而tcpdump显示仅 SYN-ACK 就占 40ms，TLS 再加 60ms，纯网络已超 100ms -
http.Client.Transport不暴露底层连接建立细节，net.Conn的DialContext耗时默认不可见 - 解决方案不是换 tracer，而是补两层观测：
net.Conn级建连耗时（用Transport.DialContexthook），以及每个请求级 write+read 往返时间（用自定义RoundTripper）
traceparent 头在跨机房 LB 后丢失的常见原因
机房间通常有统一 LB（如 F5、Nginx Ingress Controller），它们默认清洗非标准 header，trace_id 这种带下划线的字段极易被静默丢弃。
- 必须确认 LB 是否开启
underscores_in_headers on；否则即使 Go 侧调用propagators.TraceContext{}.Inject也没用 - 强制使用 W3C 标准头：
traceparent和tracestate是 LB 的“白名单字段”，几乎不会被删 - Go 初始化时显式指定传播器：
otel.SetTextMapPropagator(propagation.TraceContext{})，别依赖默认行为 - 若 LB 强制小写 header 名（如 AWS ALB），需在服务入口加 middleware 将
traceparent→Traceparent重写，否则 OTel SDK 解析失败
HTTP 客户端连接池必须按机房维度隔离
复用同一个 http.Client 会导致北京和新加坡 endpoint 的空闲连接混管，连接复用率暴跌，频繁重建连接。
-
MaxIdleConnsPerHost是按 Host 隔离的，但跨机房服务往往共用同一域名（如user-service.prod.internal），DNS 解析后 IP 才不同——此时连接池无法区分物理位置 - 正确做法：为每个机房 endpoint 单独初始化
http.Client，并配置独立Transport，设置MaxIdleConns、IdleConnTimeout（建议 30s） - 避免复用
http.DefaultClient，它共享全局连接池，易被其他模块干扰 - 连接池未隔离的后果：P99 延迟毛刺明显，实测跨机房场景下连接重建占比可达 30%+
采样策略与导出方式不当会把可观测性变成性能负担
全量采样在跨机房高 QPS 场景下极易拖垮服务，尤其当链路深、Span 多时，CPU 和出口带宽会迅速成为瓶颈。
- 禁用
trace.AlwaysSample()；改用trace.ParentBased(trace.TraceIDRatioBased(0.01))（即 1% 采样） - 对已知慢请求（如耗时 >500ms）可临时标记
span.SetAttributes(attribute.Bool("force_sample", true))，并在 Exporter 中识别该 tag 后 bypass 采样判断 - 导出必须走
OTLP/gRPC+ TLS 复用 + gzip 压缩；禁用 Jaeger Thrift over UDP 或 Zipkin HTTP JSON —— 跨机房丢包率高、无重试、不可压缩 -
*grpc.ClientConn必须全局单例复用；每次新建 conn 都触发跨机房 DNS 查询 + TLS 握手（平均 +120ms）
真正难的不是埋点，是让 Span 时间戳能对齐网络层；不是传对 traceparent，是确保它不被中间设备截断或改写；不是开了采样，是让采样策略和导出链路扛得住跨机房抖动。
