Go语言怎么做链路追踪_Go语言分布式链路追踪教程【精选】

OpenTelemetry Go SDK是Go链路追踪首选方案需区分自动注入HTTP/gRPC与手动埋点DB/消息队列TracerProvider须全局复用context传span需确保下游显式读取K8s部署需校准exporter地址与collector配置trace_id/span_id默认随机生成即满足唯一性。Go 里怎么用 OpenTelemetry 做链路追踪直接上手Go 官方推荐、社区主流、云厂商兼容性最好的方案就是 OpenTelemetry Go SDK不是 Jaeger 原生客户端也不是 Zipkin 直传——前者已停更维护后者缺语义约定和上下文传播标准。关键点在于「自动注入」和「手动埋点」的边界要划清HTTP/gRPC 框架能自动抓 request ID 和 span context但数据库调用、消息队列消费、本地方法耗时统计必须手动加 span.AddEvent() 或新起 tracer.Start()。别用 opentracing-go它已归档otelcol 不再接收其数据升级成本高TracerProvider 必须全局复用不能每次请求都 new否则 metrics 乱、exporter 连接泄漏HTTP 中间件里调 otelhttp.NewHandler() 时确保 handler 是最终业务 handler不是嵌套在其他中间件之后的“半成品”context.WithValue 传 span 会丢吗会丢而且很常见。Go 的 context.WithValue() 本身没问题但问题出在「谁往 context 里塞了 span」以及「下游是否真的从 context 里取」。典型翻车场景你用 req.Context() 提取了 span调了 db.QueryContext(ctx, ...)结果链路断在数据库层——因为 database/sql 默认不读 context 里的 span除非你用 go.opentelemetry.io/contrib/instrumentation/database/sql 包重写 driver且显式调 otel.WrapDriver()。立即学习“go语言免费学习笔记深入”gRPC 客户端必须用 grpc.WithUnaryInterceptor(otelgrpc.UnaryClientInterceptor())光传 context 不够自定义 goroutine 启动比如 go func() { ... }()必须显式传入带 span 的 context不能依赖闭包捕获外层 contextlog.Printf() 不会自动带 trace_id得自己从 trace.SpanFromContext(ctx).SpanContext().TraceID().String() 拿出来打日志为什么本地跑通了上 K8s 就看不到完整链路大概率是 exporter 配置没对齐本地直连 localhost:4317K8s 里服务发现走的是 service name而你的 exporter endpoint 写死了 IP 或 localhost。 稿定AI 拥有线稿上色优化、图片重绘、人物姿势检测、涂鸦完善等功能