通过Context传递trace_id实现RPC调用追踪，结合OpenTelemetry生成分布式追踪信息，使用zap等结构化日志输出，并通过gRPC metadata在服务间传播trace_id，最终将日志收集至ELK或类似系统实现全链路可观测性。
在Go语言构建的RPC服务中，请求追踪与日志收集是保障系统可观测性的关键。尤其在微服务架构下，一次调用可能经过多个服务节点，缺乏统一追踪机制会导致排查问题困难。实现有效的追踪和日志管理，核心在于上下文传递、唯一标识生成、结构化日志输出以及与集中式日志系统的集成。
使用Context传递追踪信息
Go的context.Context是跨函数、跨服务传递请求范围数据的标准方式。在RPC调用中，通过Context携带追踪ID（如trace_id）和跨度ID（span_id），确保整个调用链的信息一致性。
示例代码：
func handleRequest(ctx context.Context, req *Request) (Response, error) {
立即学习“go语言免费学习笔记（深入）”；
traceID := ctx.Value("trace_id")
if traceID == nil {
traceID = generateTraceID()
ctx = context.WithValue(ctx, "trace_id", traceID)
}
// 将trace_id传入日志
log.Printf("[trace_id=%v] handling request", traceID)
return process(req)
}
在实际项目中，建议封装一个自定义Context工具，避免直接使用context.Value导致类型断言错误。
集成OpenTelemetry实现分布式追踪
OpenTelemetry是当前主流的可观测性框架，支持自动注入trace_id和span_id，并能将数据导出到Jaeger、Zipkin等系统。
步骤如下：
- 引入依赖：go.opentelemetry.io/otel 和对应exporter
- 初始化TracerProvider，配置采样策略和导出器
- 在RPC入口（如gRPC拦截器）中启动Span
- 将trace_id注入日志字段
gRPC服务器端拦截器示例：
func tracingInterceptor(ctx context.Context, req interface{}, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (interface{}, error) {
ctx, span := tracer.Start(ctx, info.FullMethod)
defer span.End()
return handler(ctx, req)
}
这样每个RPC调用都会自动创建Span，并关联到全局Trace。
结构化日志输出与集中收集
传统fmt.Println或log包输出的日志难以解析。应使用结构化日志库如zap或logrus，将trace_id、method、耗时等作为独立字段输出。
使用zap记录带追踪信息的日志：
logger := zap.NewExample()
logger.Info("request received",
zap.String("trace_id", getTraceIDFromContext(ctx)),
zap.String("method", "UserService.Get"),
zap.Int64("user_id", req.UserID),
)
结合Filebeat或Fluentd将日志发送至Elasticsearch，再通过Kibana进行检索和可视化。搜索时可通过trace_id:"abc123"快速定位整条调用链日志。
客户端注入追踪头
在发起RPC调用前，客户端需生成或继承trace_id，并通过metadata（gRPC）或HTTP Header（REST）传递给下游服务。
gRPC客户端注入示例：
md := metadata.Pairs("trace_id", traceID)
ctx = metadata.NewOutgoingContext(ctx, md)
response, err := client.GetUser(ctx, &GetUserRequest{ID: 1})
服务端从metadata中提取trace_id并注入Context，实现跨进程传播。
基本上就这些。关键是建立统一的trace_id生成与传递机制，结合OpenTelemetry标准和结构化日志，就能实现清晰的RPC调用追踪。系统复杂度越高，这套机制越不可少。
