Golang中的分布式追踪实战 使用Jaeger与OpenTelemetry分析链路

4次阅读

jaeger客户端初始化报nil pointer dereference主因是未传有效reporter或sampler,或opentelemetry未调用otel.settracerprovider();http透传需统一用otelhttp中间件;context.withvalue()不安全,须用标准propagator;本地调试应配对agent udp端口与采样率。

Golang中的分布式追踪实战 使用Jaeger与OpenTelemetry分析链路

Jaeger客户端初始化为什么总报nil pointer dereference

常见于直接用jaeger.NewTracer()但没传入有效ReporterSampler,尤其在测试环境漏掉jaeger.NewConstSampler(true)时。OpenTelemetry迁移后也容易因otel.Tracer未绑定全局otel.SetTracerProvider()导致后续Tracer.Start()返回nil

  • 初始化Jaeger必须显式构造ReporterSampler,不能只传nil;本地调试建议用jaeger.NewLocalAgentReporterlocalhost:6831
  • OpenTelemetry需在main()最开始调用otel.SetTracerProvider(tp),否则所有Tracer.Start()都静默失败
  • 检查Tracer是否为nil:用if tracer == nil { log.Fatal("tracer not initialized") },别依赖panic捕获

HTTP中间件里怎么透传trace_id而不污染业务逻辑

核心是复用http.RoundTripperhttp.Handler,把注入/提取逻辑收进独立函数,避免每个http.Request都手动读写uber-trace-id头。

  • 服务端用otelhttp.NewHandler()包装http.Handler,它自动从traceparentuber-trace-id提取上下文
  • 客户端发请求前,用otelhttp.NewTransport()包装http.DefaultTransport,它自动注入traceparent
  • 别混用Jaeger旧头(uber-trace-id)和W3C标准头(traceparent),OpenTelemetry默认走W3C,Jaeger 1.22+才支持双向兼容

context.WithValue()传span真的安全吗

不安全——context.WithValue()只是临时挂载,一旦中间件或goroutine没正确传递ctx,span就断了。OpenTelemetry明确要求用trace.SpanFromContext(ctx)取span,而不是自己存spanctx

  • 永远用otel.GetTextMapPropagator().Inject()注入,Extract()提取,别手写ctx = context.WithValue(ctx, key, span)
  • goroutine启动时必须显式传ctxgo doWork(ctx),不能在goroutine里用闭包捕获外层ctx
  • 数据库调用要用otelmysqlotelgorm等插件,它们内部已处理ctx透传,别自己包装db.QueryContext()

本地开发时Jaeger ui看不到链路,但日志显示上报成功

大概率是采样率设太高或时间窗口没对齐。Jaeger Agent默认只接受localhost:6831的UDP包,而OpenTelemetry Exporter默认走gRPC或HTTP,协议不匹配。

立即学习go语言免费学习笔记(深入)”;

  • 确认Agent监听地址:运行docker run -d -p 6831:6831/udp -p 16686:16686 jaegertracing/all-in-one,不是14268(Collector HTTP端口)
  • OpenTelemetry Exporter要配jaegerthrift协议,或改用otlphttp并让Collector接收OTLP再转给Jaeger
  • 本地调试把采样率设成1.0jaeger.NewConstSampler(true)otel.NewParentBased(otel.AlwaysSample())

跨服务传播最脆弱的环节永远在HTTP头解析和goroutine上下文传递,这两处漏一个,整条链就断成孤点。

text=ZqhQzanResources