OpenTelemetry SDK 默认采样策略在 TracerProvider 初始化时固定，后续修改无效；必须在创建 trace.NewTracerProvider 时传入采样器，且高QPS接口需组合 ParentBased 与自定义采样器实现差异化采样。
Go 的 oteltrace.SpanContext 为什么采样结果总和预期不一致
根本原因不是代码写错了，而是 OpenTelemetry SDK 默认采样器在进程启动后就固定了策略，后续修改 TracerProvider 配置不会影响已创建的 Tracer 实例。常见现象是：改了 TraceConfig.Sampler 但日志里依然看到大量 span 被丢弃，或本该采样的请求没进 Jaeger。
- 必须在初始化
trace.NewTracerProvider时传入采样器，之后替换TracerProvider不生效 - 自研系统常犯的错：把采样逻辑写在 HTTP 中间件里动态判断，但采样决策发生在
StartSpan时，此时 span 已被创建或丢弃 -
oteltrace.AlwaysSample()和oteltrace.NeverSample()是确定性策略；oteltrace.ParentBased(oteltrace.TraceIDRatioBased(0.1))才真正按比例采样，且只对 root span 生效 - 如果用的是
go.opentelemetry.io/otel/sdk/tracev1.20+，注意TraceIDRatioBased的参数是 float64，传1不等于 100%，得传1.0
如何让高 QPS 接口只采样 0.1% 而错误请求 100% 上报
靠单一采样器做不到，得组合使用 ParentBased + 自定义采样器。OpenTelemetry 的采样决策是分层的：先看 parent 是否已采样，再决定是否基于当前 span 属性做二次判断。
- 错误请求全采样的关键：在 span 创建时通过
WithAttributes注入status.code或自定义 tag（如error=true），再在自定义采样器里读取 - 示例逻辑：
if attrs.Contains(semconv.HTTPStatusCodeKey) && attrs.Value(semconv.HTTPStatusCodeKey).AsInt64() >= 400 { return trace.SamplingResult{Decision: trace.RecordAndSample} } - 避免在采样器里调用外部服务或加锁，否则会拖慢整个请求链路；属性读取必须用
span.SpanContext().TraceID()等只读方法 - 不要依赖
span.Name()做判断——它可能被中间件重写，也不稳定
otel-collector 配置里 tail_sampling 和应用端采样的区别在哪
应用端采样是“丢弃前决策”，tail_sampling 是“接收后筛选”，二者不互斥但目标不同：前者省 CPU 和网络，后者省存储和查询压力。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 应用端未采样的 span 根本不会发给 collector；
tail_sampling只能对已送达的 span 做聚合判断，比如“只要这个 trace 里有 error span，就把整条链路保留” - 开启
tail_sampling后，collector 内存占用明显上升，尤其在 trace 数量大、平均 span 数多时，需调大decision_wait和num_traces - 自研监控系统若已有 trace ID 黑白名单机制，建议优先在应用层用
TraceIDRatioBased控制总量，再用tail_sampling补漏，别全压给 collector -
tail_sampling规则不支持正则匹配 span name，只能用string_attribute或numeric_attribute，字段必须提前通过SetAttributes打点
Go 应用里降低采样开销最有效的三个动作
不是调低采样率，而是砍掉采样过程中的非必要计算。实测显示，80% 的采样 CPU 开销来自属性序列化和 trace ID 生成逻辑。
立即学习“go语言免费学习笔记（深入）”；
- 禁用默认的
runtime和process自动注入：初始化TracerProvider时显式传空resource.Empty()，否则每个 span 都会采集 goroutine 数、内存分配等高成本指标 - 避免在
StartSpan时传大量attribute.KeyValue；高频接口只留http.method、http.status_code、rpc.system这几个关键字段 - 如果用的是
net/http标准库，别用otelhttp.NewHandler的默认配置——它会自动记录所有请求头；改成otelhttp.WithFilter(func(r *http.Request) bool { return r.URL.Path != "/healthz" })显式过滤
采样本身不耗资源，耗资源的是你让它“顺便干的那些事”。越早明确哪些字段真有用，越不容易在流量高峰被自己的监控拖垮。
