Jaeger客户端初始化为什么总报错 nil pointer dereference
常见原因是没传入有效的 tracer，或在调用 opentracing.StartSpan 前没完成初始化。Jaeger 的 Go SDK 不会自动 fallback，opentracing.GlobalTracer() 默认返回空实现，直接用它开 Span 就 panic。
必须显式创建并设置全局 tracer：opentracing.SetGlobalTracer(tracer)，且这行要在任何 Span 创建之前执行推荐在 main() 开头、配置加载后立即初始化，不要懒加载或放 goroutine 里如果用 jaeger.NewTracer，注意第 2 个参数（jaeger.Configuration.Sampler）不能为 nil；采样器至少得是 jaeger.NewConstSampler(true)本地调试时，jaeger.NewCollector() 若连不上 Agent，默认会静默失败——加 jaeger.WithLogger 才能看到连接错误
怎么让 HTTP 请求自动带上 TraceID 并透传到下游服务
Go 标准库不自动注入/提取 trace 上下文，必须手动做。核心是用 opentracing.HTTPHeadersCarrier 在请求头中写入 uber-trace-id。
发起请求前：从当前 Span 获取上下文，用 tracer.Inject(span.Context(), opentracing.HTTPHeaders, carrier)接收请求时：用 tracer.Extract(opentracing.HTTPHeaders, carrier) 恢复 SpanContext，再 StartSpanFromContext别直接读写 r.Header.Get("uber-trace-id")——要用 opentracing.HTTPHeadersCarrier 包装 map，否则大小写、空格处理不一致如果下游是 Python/Java 服务，确保 header key 是小写 uber-trace-id（Jaeger Go SDK 默认用这个），不是 Uber-Trace-Id
为什么 Span 看不到日志（Log）或 Tag，或者 Tag 值是 <nil>
Jaeger Go SDK 对 Log 和 Tag 的类型很敏感：Tag 值必须是基础类型（string、int64、bool）或实现了 String() 方法的 struct；Log 字段值不能是 nil 指针。
写 Tag 时避免 span.SetTag("user_id", &u.ID)——&u.ID 是指针，显示为 <nil> 或地址；应写 span.SetTag("user_id", u.ID)Log 事件字段值不能为 nil：span.LogFields(log.String("error", err.Error())) 比 log.Object("err", err) 更稳，后者在 err == nil 时会崩Tag 键名别用空格或特殊字符，Jaeger UI 可能解析失败；推荐全小写 + 下划线，如 http_status_codeLog 时间戳默认用 time.Now()，但如果你手动传 log.Timestamp，注意单位是 time.Time，不是 Unix 时间戳整数
Agent 连不上或 Span 全丢，怎么快速定位是网络还是配置问题
Jaeger Go 默认走 UDP 发给 localhost:6831，但这个端口容易被防火墙、Docker 网络或 SELinux 拦住，且无重试、无确认机制，丢了就真丢了。
立即学习“go语言免费学习笔记（深入）”；
先用 nc -u localhost 6831 测试端口是否通（UDP 需配合 timeout 1 判断）启动时加 jaeger.WithReporter(jaeger.NewLocalAgentReporter(…)) 并设 logger，看日志里有没有 "failed to write span" 或 "connection refused"Docker 场景下，Go 服务容器里 localhost 指自己，不是宿主机——得用 host.docker.internal 或 –network=host高并发下 UDP 丢包率上升，可临时切 TCP reporter：jaeger.NewTUDPReporter("agent:6831", …)（需 Jaeger >= 1.22）
链路追踪不是“配完就跑”，Span 生命周期、上下文传递、序列化细节任何一个环节断掉，数据就不可见。最常被忽略的是：tracer 初始化时机、HTTP header carrier 的正确封装、以及 UDP 在容器环境下的实际可达性。
评论(0)