Go服务接入OpenTelemetry必须配对初始化TracerProvider与SpanProcessor，否则StartSpan为空转；K8s中需客户端和服务端同时埋点，用otelhttp.NewHandler和otelhttp.NewClient保障traceparent自动提取与注入，gRPC须同步配置UnaryClientInterceptor和UnaryServerInterceptor。
Go服务接入OpenTelemetry SDK必须配对的初始化步骤
不配置正确的 TracerProvider 和 SpanProcessor，后续所有 StartSpan 调用都只是空转，不会上报任何数据到后端（如Jaeger、Zipkin或OTLP Collector）。Kubernetes环境里，服务间通过HTTP/gRPC通信，埋点必须在客户端和服务端同时生效，否则链路会断。
关键操作有三步：
- 用
otlptracehttp.NewClient或otlptracegrpc.NewClient创建OTLP传输客户端，指向集群内部署的otel-collectorService（如http://otel-collector.default.svc.cluster.local:4318） - 调用
sdktrace.NewTracerProvider时传入BatchSpanProcessor，别用SimpleSpanProcessor——它同步阻塞，压测时直接拖垮QPS - 把生成的
TracerProvider设为全局：otel.SetTracerProvider(tp)，否则otel.Tracer(...)拿到的是默认 noop 实例
HTTP Handler中间件里提取和注入trace context的坑
Kubernetes中Pod间调用走Service ClusterIP，但HTTP Header里的 traceparent 字段大小写敏感，且必须符合W3C Trace Context规范。手动解析/拼接极易出错，导致下游Span丢失parent。
正确做法是复用OpenTelemetry官方中间件：
立即学习“go语言免费学习笔记（深入）”；
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
- 用
otelhttp.NewHandler包裹你的http.Handler，它自动从traceparent提取context并创建server Span - 用
otelhttp.NewClient替代原生http.Client，它自动在请求头注入traceparent和tracestate - 若需自定义Header名（比如旧系统用
X-B3-TraceId），得额外加otelhttp.WithPropagators配置B3Propagator，但K8s新集群强烈建议统一用W3C标准
gRPC服务埋点必须同时处理客户端拦截器和服务端拦截器
Go的gRPC默认不透传trace context，context.Context 里的span信息不会自动跨网络边界。只加客户端拦截器，服务端收到的是无parent的root span；只加服务端拦截器，则上游调用链断裂。
两处拦截器缺一不可：
- 客户端拦截器用
otelgrpc.UnaryClientInterceptor()，它从当前context读取span，并写入metadata.MD发送到服务端 - 服务端拦截器用
otelgrpc.UnaryServerInterceptor()，它从metadata.MD解析出traceparent，恢复context并续接span - 注意gRPC健康检查（
/grpc.health.v1.Health/Check）这类非业务方法，建议用otelgrpc.WithFilter过滤掉，避免污染真实链路指标
Pod启动时等待otel-collector就绪再对外提供流量
Kubernetes里Service Endpoint可能先于otel-collector Ready，导致服务启动瞬间大量span上报失败，SDK内部错误日志刷屏（如 rpc error: code = Unavailable desc = connection closed before server preface received），甚至触发panic（某些老版本SDK）。
解决方式不是重试，而是依赖就绪探针（readiness probe）：
- 在服务HTTP Server里暴露一个
/healthz端点，内部调用tp.ForceFlush(context.WithTimeout(ctx, 500*time.Millisecond))测试collector连通性 - K8s readiness probe配置
httpGet.path: /healthz，失败则不加入Endpoint，避免流量进入 - 别用
liveness probe做这个判断——它重启Pod反而加剧上报抖动
链路追踪不是“加了SDK就完事”，真正难的是让每个Pod在分布式环境中稳定地维持trace context传递，而Kubernetes的网络模型和调度行为会让context丢失变得隐蔽又顽固。
