Golang实现分布式链路追踪_使用Jaeger框架分析调用-Golang-PHP中文网

jaeger客户端初始化报nil pointer dereference的根本原因是未检查jaeger.newtracer()返回的tracer是否为nil且未调用opentracing.setglobaltracer()注册，导致opentracing.startspan()调用空指针panic；必须显式校验err和tracer非nil、设置servicename、正确关闭closer并确保reporter地址可达。

golang实现分布式链路追踪_使用jaeger框架分析调用

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

常见原因是未正确初始化 tracer 就直接调用 opentracing.StartSpan()。Jaeger 的 jaeger.NewTracer() 返回两个值：tracer 和 closer，漏掉 closer 或忽略错误会导致后续 panic。

必须检查 err：如果 Agent 地址不可达或配置为空，NewTracer 会返回 nil, err
closer 不能丢弃：即使只做测试，也要在 main 退出前调用 closer.Close()，否则 span 可能丢失
全局 tracer 要用 opentracing.SetGlobalTracer() 注册，否则 opentracing.GlobalTracer() 返回的是空实现

示例片段：

tracer, closer, err := jaeger.NewTracer(
    "my-service",
    jaeger.NewConstSampler(true),
    jaeger.NewRemoteReporter(jaeger.LocalAgentHostPort("localhost:6831")),
)
if err != nil {
    log.Fatal(err)
}
defer closer.Close()
opentracing.SetGlobalTracer(tracer)

HTTP 请求注入/提取 context 失败，链路断在中间服务

根本原因常是 header key 不一致或未启用 Zipkin B3 兼容模式。Jaeger 默认使用 uber-trace-id，但很多 Go HTTP 中间件（如 gorilla/mux）默认不透传该 header。

确保下游服务读取的 header 名和上游写入的一致；推荐统一用 opentracing.HTTPHeadersCarrier，它自动处理大小写和多值
若对接 Python/Node.js 服务，需启用 B3：在初始化 reporter 时加 jaeger.NewB3HTTPHeaderCodec()
不要手动拼接 req.Header.Set("uber-trace-id", ...) —— 缺少 tracestate 和采样标记会导致子 span 被丢弃

正确做法：

Alibabacloud Sdk Client Initialization For Golang

初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。

下载

span := opentracing.SpanFromContext(ctx)
err := span.Tracer().Inject(
    span.Context(),
    opentracing.HTTPHeaders,
    opentracing.HTTPHeadersCarrier(req.Header),
)

本地跑通了，但部署到 Kubernetes 后 spans 全丢

不是代码问题，而是网络和配置没对齐。Jaeger Agent 默认监听 0.0.0.0:6831 UDP，K8s Pod 网络策略或 Service 配置常阻断 UDP 流量。

确认 Agent Service 类型为 ClusterIP（非 NodePort），且端口协议明确声明为 UDP
Client 初始化时地址要写成 "jaeger-agent:6831"（Service 名），不能写 "localhost:6831"
检查 Pod DNS 是否生效：kubectl exec -it <pod> -- nslookup jaeger-agent</pod>
更稳妥的做法是改用 jaeger.NewCollectorReporter() 直连 Jaeger Collector HTTP API（http://jaeger-collector:14268/api/traces），规避 UDP 不稳定问题

Span 显示 duration 为 0ms，但实际耗时明显很长

典型表现是 span 有 start time 但 finish time 没设，或者 finish 被多次调用。Jaeger 的 Finish() 是幂等的，但重复调用可能覆盖时间戳。

避免在 defer 里无条件调用 span.Finish()，尤其当 span 可能已被提前 finish（例如 error 分支里已 finish）
务必用 span = span.SetTag(...) 而非 span.SetTag(...)（后者不返回新 span，易误以为修改了当前 span）
跨 goroutine 使用 span 时，必须用 opentracing.ContextWithSpan(ctx, span) 传递，不能只传 span 指针

最简验证方式：在 span 创建后立刻 log.Printf("start: %v", span.Context())，finish 后再打一次，看是否匹配。

链路追踪真正难的不是埋点，而是让 span 生命周期和业务逻辑生命周期严格对齐——尤其是超时、重试、recover 这些边界场景，稍不注意就断链或污染数据。