Golang怎么实现链路追踪_Golang如何用OpenTelemetry接入分布式调用追踪【实战】-Golang-PHP中文网

根本原因是 handler 链路断裂——otelhttp.newhandler 包裹后的 handler 未被正确注册或被中间件覆盖，导致 server 端 span 无法生成。

golang怎么实现链路追踪_golang如何用opentelemetry接入分布式调用追踪【实战】

常见现象是服务启动后没任何 trace 数据，或只看到 client 端 span、看不到 server 端 span。根本原因往往是 handler 链路断了——otelhttp.NewHandler 返回的新 handler 没被真正注册进路由，或者被中间件顺序覆盖了。

确保你用的是 otelhttp.NewHandler 包裹后的 handler，而不是原始 handler；比如 http.Handle("/api", otelhttp.NewHandler(myHandler, "api"))，不是 http.Handle("/api", myHandler)
如果你用的是 chi、gin 等框架，别直接传 http.Handler，得用对应适配器：chi.WrapHandler 或 gin.WrapH(otelhttp.NewHandler(...))
检查是否在 handler 执行前就返回了（如 panic、early return、超时中断），span 会在 defer 的 span.End() 中结束，提前退出会导致 span 被丢弃
确认 otelhttp.NewHandler 的第二个参数（span name）不是空字符串，否则部分 exporter（如 Jaeger）会忽略该 span

Go 的 context 是链路追踪的载体，但默认 goroutine 不继承父 context，DB 驱动也不自动读取 context 中的 span。不显式传递，trace 就断了。

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

下载

所有新起 goroutine 必须显式传入带 span 的 context：go doWork(ctx)，而不是 go doWork()
数据库操作必须用带 context 的方法：用 db.QueryContext(ctx, ...) 替代 db.Query(...)；ORM 如 gorm 要启用 WithContext(ctx) 链式调用
日志打点如果想关联 traceID，别用全局 logger，改用 log.WithValues("trace_id", trace.SpanContext().TraceID().String())，或集成 otellogrus 这类桥接器
注意：context.Background() 或 context.TODO() 会彻底切断链路，生产代码里禁止出现

OpenTelemetry Go SDK 要求 Resource 必须在创建 TracerProvider 前就准备好，并作为选项传入。写反了不会报错，但 service.name、host.ip 等关键属性全丢失，后台（如 Tempo、Jaeger）无法按服务维度聚合数据。

正确顺序：resource.MustNewWithAttributes(...) → otlphttp.NewClient(...) → sdktrace.NewTracerProvider(..., sdktrace.WithResource(res))
Resource 至少包含 service.name，建议加上 service.version 和 telemetry.sdk.language（值为 "go"）
不要在多个地方重复调用 otel.SetTracerProvider，它只会生效第一次；多模块共用一个 provider，避免内存泄漏和 span 丢失
如果用 OTEL_RESOURCE_ATTRIBUTES 环境变量注入，也要确保它在 TracerProvider 初始化前已加载（比如 main 函数开头就 os.Setenv 不可靠，应由部署层注入）

典型表现：本地 curl localhost:8080 能查到 trace，K8s 里 cURL ingress 地址却无数据。问题不在代码，而在网络和配置漏项。

确认 collector 地址可连通：telnet otel-collector.default.svc.cluster.local 4318（HTTP endpoint）或 4317（gRPC），K8s DNS 解析失败是高频原因
检查 collector 接收端口是否暴露：OTEL_EXPORTER_OTLP_ENDPOINT 应设为 http://otel-collector.default.svc.cluster.local:4318，不是 localhost:4318
确认 collector 配置支持接收（比如 otlphttp receiver 是否启用，exporters 是否配了 logging 或 jaeger 用于调试）
Pod 内 DNS 缓存可能延迟，加个 sleep 2 && curl -v http://otel-collector... 在 initContainer 里验证更稳