OpenTelemetry 在 Golang 微服务中全量追踪引入 0.3–1.2ms/请求开销，高频场景下 P99 延迟上浮 8–15%，需通过采样控制、Span 生命周期管理、Exporter 背压调优及跨机房链路校准来平衡可观测性与性能。
OpenTelemetry 在 Golang 微服务中默认启用全量追踪时，单请求 Span 创建+序列化+上报开销约 0.3–1.2ms，高频服务（QPS > 5k）可能因 goroutine 和 buffer 竞争导致 P99 延迟上浮 8–15%，这不是“能不能用”的问题，而是“怎么配才不拖慢业务”的问题。
Span 创建和上下文传播的实际 CPU 占比
每次 tracer.Start() 都会分配新 Span 对象、生成 ID、拷贝 Context，并触发 propagator.Inject；在 HTTP handler 中自动注入时，这部分开销稳定在 5–15μs/请求（实测 AMD EPYC 7742）。但真正吃 CPU 的是后续的序列化和 exporter 批处理——尤其当使用 jaeger.New() 直连 Agent 时，JSON 编码 + UDP 发包会显著抬高 syscall 调用频次。
- 禁用采样（
AlwaysSample()）会使 Span 数量暴涨，CPU 使用率在高并发下可能翻倍 -
otelhttp.NewHandler包裹后，每个请求至少创建 2 个 Span（server + client），若内部还调用 DB/gRPC，数量线性增长 - 避免在循环内反复调用
tracer.Start()，Span 对象不是零成本，GC 压力会随 Span 生命周期延长而累积
Exporter 上报对延迟的隐性影响
Jaeger Agent 模式看似异步，但 sdktrace.NewTracerProvider 默认使用的 BatchSpanProcessor 仍依赖 channel + goroutine 协作，当上报队列积压（如网络抖动或 Agent 不可用），span.End() 可能阻塞在 processor 的 buffer push 阶段——实测 buffer 满时单次 End() 最长卡住 12ms。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 务必设置
sdktrace.WithSyncer()替代默认异步 processor，仅在调试期启用；生产环境用WithBatcher(exporter, sdktrace.WithMaxQueueSize(2048))控制背压 - 不要把
otlphttp.NewClient的 timeout 设为 0 或过大，否则失败重试会拖住整个 batch flush 流程 - 如果服务本身 P99 已接近 SLA（如 100ms），建议关闭非核心路径的 Span（例如健康检查 /metrics 接口），用
otelhttp.WithFilter过滤掉
跨机房调用时的网络层开销放大效应
链路追踪本身不加重网络负担，但跨机房场景下，Span 耗时失真会让性能归因完全错误：你看到一个 280ms 的 Span，实际可能是 40ms TCP 建连 + 60ms TLS 握手 + 10ms NAT 重传 + 170ms 业务逻辑——而 OTel 默认只记录最后 170ms。这时强行开启全量追踪，反而掩盖了真实瓶颈。
立即学习“go语言免费学习笔记（深入）”；
- 别在跨机房 HTTP 客户端里复用同一个
http.Client，连接池混用会导致DialContext耗时统计失效，建连延迟被平均化 - 若必须观测网络层，需手动 patch
http.Transport.DialContext，用net.Conn的RemoteAddr()和LocalAddr()区分机房，再打点到 metrics，而非塞进 Span - traceparent 头透传失败时，OTel 会 fallback 创建新 Trace，此时 Span 看似“快”，实则是链路断裂——用
otel.GetTextMapPropagator().Extract()日志打点验证 header 是否真的被 LB 放行
最常被忽略的是：Span 的生命周期管理比创建更关键。一个没被 span.End() 的 Span 会卡在 processor buffer 里直到超时释放，而超时时间（默认 30s）远大于请求耗时，这种“幽灵 Span”在长连接或流式接口中极易堆积，最终拖垮整个 tracer provider 的 flush 效率。
