4. 可观测性三大支柱：日志、指标、链路追踪在 gRPC 中的角色

在 gRPC 分布式系统中，故障排查的难点在于调用链跨越多个进程、语言和网络边界。可观测性的三大支柱——日志（Logs）、指标（Metrics）、链路追踪（Traces）——各自从不同维度提供故障线索。理解它们在 gRPC 上下文中的具体角色，是构建高效排查体系的前提。

4.1 三大支柱的核心定位与差异

下表从数据形态、gRPC 典型场景和排查价值三个维度，对比三大支柱在 gRPC 中的角色差异：

4.2 日志（Logs）：gRPC 请求的“黑匣子”

gRPC 日志是排查故障时最直接的证据来源。与 HTTP REST 不同，gRPC 使用二进制 Protobuf 序列化，日志中需要记录的关键信息包括：

• 请求/响应元数据：gRPC 状态码（Status Code）、超时时间、请求 ID。
• 关键字段摘要：避免打印完整 Protobuf 二进制体，应提取业务关键字段（如订单 ID、用户 ID）。
• 拦截器日志：在 gRPC 客户端/服务端拦截器中统一记录入站和出站日志，确保覆盖所有 RPC 调用。

// 服务端拦截器示例：记录 gRPC 调用日志
func LoggingInterceptor(ctx context.Context, req interface{},
    info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (interface{}, error) {
    start := time.Now()
    // 提取元数据中的 trace ID
    md, _ := metadata.FromIncomingContext(ctx)
    traceID := md["x-trace-id"]
    // 记录入站请求
    log.Printf("[gRPC IN] method=%s traceID=%s", info.FullMethod, traceID)
    resp, err := handler(ctx, req)
    // 记录出站响应及耗时
    log.Printf("[gRPC OUT] method=%s duration=%v status=%v",
        info.FullMethod, time.Since(start), status.Code(err))
    return resp, err
}

4.3 指标（Metrics）：gRPC 服务的“仪表盘”

指标提供聚合视图，帮助快速判断系统健康状态。gRPC 核心指标应覆盖 RED 方法论（Rate、Errors、Duration）：

• Rate（速率）：每秒请求数（RPS），按方法、状态码、来源服务维度聚合。
• Errors（错误）：错误率，区分 gRPC 状态码（如 Unavailable、DeadlineExceeded、Internal）。
• Duration（延迟）：P50、P90、P99 延迟，按方法和服务端/客户端分别统计。

以下 SVG 展示了 gRPC 指标采集的典型架构：

4.4 链路追踪（Traces）：gRPC 调用链的“地图”

链路追踪通过 Trace ID 和 Span 将一次跨服务请求串联起来。在 gRPC 中，链路追踪的核心机制是上下文传播（Context Propagation）：

• Trace ID：全局唯一标识一次完整请求。
• Span：每个 gRPC 调用对应一个 Span，记录方法名、开始时间、结束时间、状态码。
• 传播方式：通过 gRPC 元数据（Metadata）传递 Trace Context，通常使用 W3C Trace Context 或 Zipkin B3 格式。

以下 SVG 展示了一个典型的 gRPC 跨服务调用链路：

// 服务端拦截器：自动创建 Span
import (
    "go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc"
    "google.golang.org/grpc"
)

func main() {
    s := grpc.NewServer(
        grpc.StatsHandler(otelgrpc.NewServerHandler()),
    )
    // 客户端同理使用 otelgrpc.NewClientHandler()
}

4.5 三大支柱的协同排查流程

在实际故障场景中，三大支柱按以下顺序协同工作：

1. 指标告警：Prometheus 告警规则检测到 grpc_server_handling_seconds_p99 > 500ms，触发告警。
2. 链路定位：通过 Jaeger 或 Zipkin 查看对应时间窗口的 Trace，发现 /payment.Charge 方法延迟异常。
3. 日志深挖：根据 Trace ID 关联到支付服务的日志，发现 DeadlineExceeded 错误和第三方支付接口超时堆栈。
4. 根因确认：结合指标（支付服务连接池耗尽）和日志（连接池等待超时），确认根因为第三方支付接口响应变慢导致连接池阻塞。