使用gRPC拦截器捕获错误并结合结构化日志库（如zap）记录，通过Unary Server Interceptor在调用后检查err，区分业务与系统错误，提取metadata中的trace_id等上下文信息，实现可追溯的错误日志收集。
在Gola
ng中实现RPC错误日志收集，核心在于拦截RPC调用过程中的异常信息，并将其结构化输出到日志系统。通常结合中间件（如gRPC的Interceptor）或自定义RPC框架钩子来捕获错误，再通过日志库进行记录。
使用gRPC Interceptor捕获错误
在gRPC服务中，可以通过Unary Server Interceptor统一处理请求和响应中的错误。拦截器在每个RPC调用前后执行，适合注入日志、监控和错误处理逻辑。
示例代码：
func ErrorLoggingInterceptor(ctx context.Context, req interface{}, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (resp interface{}, err error) {
// 调用实际的RPC方法
resp, err = handler(ctx, req)
// 记录错误日志
if err != nil {
log.Printf("RPC Error: method=%s, error=%v, request=%+v", info.FullMethod, err, req)
}
return resp, err
}
注册拦截器：
server := grpc.NewServer(
grpc.UnaryInterceptor(ErrorLoggingInterceptor),
)
结构化日志输出
建议使用结构化日志库如zap或logrus，便于后续日志采集与分析。
以zap为例：
logger, _ := zap.NewProduction()
defer logger.Sync()
if err != nil {
logger.Error("RPC call failed",
zap.String("method", info.FullMethod),
zap.Error(err),
zap.Any("request", req),
)
}
这样输出的日志可被ELK或Loki等系统解析，支持字段检索和告警。
区分业务错误与系统错误
不是所有err都需要当作异常记录。可通过自定义错误类型或状态码判断是否为预期错误。
例如：
if status.Code(err) >= codes.Internal {
// 只记录服务器内部错误
logger.Error("Internal RPC error", ...)
}
避免将用户输入错误（如InvalidArgument）误判为系统故障。
添加上下文信息
结合context传递trace_id、user_id等信息，有助于链路追踪。
可以在拦截器中从metadata提取：
md, _ := metadata.FromIncomingContext(ctx)
traceID := md.Get("trace_id")
并将这些字段一并写入日志，提升排查效率。
基本上就这些。关键是利用拦截机制统一捕获错误，配合结构化日志和上下文信息，实现清晰、可追溯的RPC错误记录。不复杂但容易忽略细节。
