opentelemetry（otel）是微服务链路追踪的主流解决方案，它提供了一套标准的可观测性工具，用于采集分布式系统中的trace、metric和log。其核心概念span代表一次操作的执行时间段，通过sdk可便捷集成到go语言编写的微服务中。接入步骤包括安装依赖包、初始化tracerprovider并设置采样策略、配置exporter导出span数据、以及在服务中注入中间件或手动添加span。以chi路由库为例，通过引入otelhttp中间件可以自动为每个http请求创建span，并通过grpc协议将数据发送至opentelemetry collector。验证方法是启动collector并配置输出目标如jaeger，访问服务后在jaeger ui查看是否有追踪记录。建议生产环境控制采样率、确保服务名唯一、对无中间件覆盖的逻辑手动埋点，并注意跨服务调用时的上下文传递。
微服务架构下，链路追踪几乎是标配功能。Go语言写的微服务要实现这个能力，OpenTelemetry（简称OTel）是目前比较主流的选择。它不仅能收集Span数据，还支持多种导出方式，对接Prometheus、Jaeger、Zipkin等系统都不是问题。
OpenTelemetry是什么？
简单来说，OpenTelemetry是一套可观测性工具，用来采集分布式系统的追踪（Trace）、指标（Metric）和日志（Log）。其中的Trace部分，就是我们常说的链路追踪。它的核心概念是Span，代表一次操作的执行时间范围，比如一个HTTP请求、一次数据库查询或者RPC调用。
在Go项目中集成OTel，主要是通过SDK来生成、传播和导出这些Span信息。你不需要自己实现整套链路追踪逻辑，只需要引入相关依赖，做一些配置即可。
立即学习“go语言免费学习笔记（深入）”；
如何给Golang微服务接入OpenTelemetry？
接入过程大致可以分为以下几个步骤：
- 安装必要的依赖包
- 初始化TracerProvider并设置采样策略
- 配置Exporter将Span数据发送出去
- 在服务中注入中间件或手动添加Span
以HTTP服务为例，假设你使用的是chi路由库，你可以这样快速接入：
-
安装依赖：
go get go.opentelemetry.io/otel go get go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp
-
初始化TracerProvider并注册HTTP中间件：
import ( "context" "net/http" "go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp" "go.opentelemetry.io/otel" "go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc" "go.opentelemetry.io/otel/propagation" "go.opentelemetry.io/otel/sdk/resource" sdktrace "go.opentelemetry.io/otel/sdk/trace" semconv "go.opentelemetry.io/otel/semconv/v1.4.0" "google.golang.org/grpc" ) func initTracer() func() { ctx := context.Background() // 使用gRPC方式导出到Collector exporter, err := otlptracegrpc.New(ctx, otlptracegrpc.WithInsecure(), otlptracegrpc.WithEndpoint("localhost:4317"), otlptracegrpc.WithDialOption(grpc.WithBlock()), ) if err != nil { panic(err) } tp := sdktrace.NewTracerProvider( sdktrace.WithSampler(sdktrace.AlwaysSample()), sdktrace.WithBatcher(exporter), sdktrace.WithResource(resource.NewWithAttributes( semconv.SchemaURL, semconv.ServiceNameKey.String("your-service-name"), )), ) otel.SetTracerProvider(tp) otel.SetTextMapPropagator(propagation.TraceContext{}) return func() { _ = tp.Shutdown(ctx) } } func main() { shutdown := initTracer() defer shutdown() r := chi.NewRouter() r.Use(otelhttp.Middleware("main-handler")) http.ListenAndServe(":8080", r) }
这段代码初始化了一个TracerProvider，并通过HTTP中间件自动为每个请求创建Span。然后通过gRPC协议将Span数据发送到OpenTelemetry Collector。
怎么验证链路数据是否正常？
最直接的方式是启动一个OpenTelemetry Collector，并配置好输出目标（如Jaeger、Zipkin或Prometheus + Tempo），然后发几个请求看看有没有追踪数据出来。
Collector的配置文件（例如config.yaml）大概长这样：
receivers:
otlp:
protocols:
grpc:
exporters:
jaeger:
endpoint: jaeger-collector:14250
insecure: true
service:
pipelines:
traces:
receivers: [otlp]
exporters: [jaeger]然后启动Collector：
docker run -d -p 4317:4317 -v $(pwd)/config.yaml:/etc/otel/config.yaml otel/opentelemetry-collector
接着访问你的Go服务接口几次，再打开Jaeger UI查看是否有对应的Service和Trace记录。
如果你看到类似GET /some-endpoint这样的Span记录，并且能展开看到详细的调用链，说明整个流程已经跑通了。
最后一些小建议
-
采样率控制：生产环境不要全部采样，会浪费很多资源。可以通过
sdktrace.WithSampler(sdktrace.ParentBasedTraceIDRatioBased(0.1))设置10%采样。 -
服务名区分清楚：微服务多了之后，一定要确保每个服务的
service.name属性不重复，否则在UI上不好看。 -
中间件不是万能的：像HTTP请求这种有标准库支持的场景，中间件很方便。但有些业务逻辑需要手动埋点，记得用
tracer.Start()创建子Span。 - 注意上下文传递：跨服务调用时，比如发MQ消息或调用其他服务，需要显式地把trace信息带过去，不然链路就断了。
基本上就这些。刚开始可能觉得有点复杂，但一旦搭起来，后续加新服务基本都是复制粘贴。
