Go语言gRPC服务端监控拦截器需用Prometheus HistogramVec打点，耗时用time.Since(start)在handler后立即计算，状态码用status.Convert(err).Code()获取，方法名取info.FullMethod，label避免高基数字段，monitor应置于拦截器链最外层确保全覆盖。

gRPC服务端监控拦截器怎么写才不丢指标

直接用 log.Printf 打点会丢数据、压垮日志系统，真正能落地的监控必须用 prometheus.HistogramVec 或类似原子指标库。关键不是“打了没”，而是“聚合准不准”“维度炸不炸”。

• 耗时打点必须在 handler(ctx, req) 返回后立刻计算，用 time.Since(start)，别放 defer 里——handler panic 时 defer 不执行，指标就丢了
• 状态码不能靠 err.Error() 字符串匹配，必须用 status.Convert(err).Code()；err == nil 时对应 codes.OK，漏判会导致成功请求被统计成错误
• 方法名统一取 info.FullMethod，格式固定为 /package.Service/Method，别 parse request body 或 ctx key，否则字段缺失时维度为空
• label 值严禁塞参数内容（如 user_id）、request ID 或原始 error message，cardinality 爆炸后 Prometheus 会 OOM

多个监控拦截器叠加时顺序为什么影响上报结果

注册顺序 = 执行顺序，最外层拦截器最先执行、最后返回，最内层离业务 handler 最近。比如 grpc.UnaryInterceptor(auth, log, monitor) 中，auth 包最外层，monitor 在最里层。

• 如果 auth 拦截器鉴权失败直接 return status.Error(codes.Unauthenticated, ...)，那 log 和 monitor 根本收不到 handler 返回值，耗时和状态码就无法上报
• 想确保所有监控项都覆盖，得把 monitor 放最外层，或让每个拦截器都调用 handler（哪怕只是透传），再各自处理返回值
• 用 go-grpc-middleware.ChainUnaryServer 组合时，链式调用保证每个拦截器都能拿到前一个的 ctx 和 resp/err，但依然要自己判断是否需要短路

客户端监控拦截器怎么避免拖慢请求

客户端拦截器里做同步上报（比如直连 Pushgateway）会让每个 RPC 请求多一次网络 IO，QPS 上千就明显卡顿。监控逻辑必须异步且轻量。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• 不要在 invoker 调用前后做 HTTP POST、SQL 写入等重操作
• 推荐模式：拦截器里只做 time.Now() 打点 + 把指标写进内存 channel，由单独 goroutine 批量 flush 到监控后端
• 超时控制交给上游 context，拦截器里别调 context.WithTimeout —— 会覆盖业务方设的 deadline，导致请求提前中断
• 元数据注入必须用 metadata.AppendToOutgoingContext，写成 "Authorization" 或 "authorization" 都行，但大小写要和服务端解析逻辑一致，否则认证头被忽略

流式 RPC 的监控为什么不能照搬一元拦截器

流式拦截器（grpc.StreamServerInterceptor）拿不到完整请求体和响应体，handler 返回的是 error，不是 resp, err，耗时、状态、消息数都得靠包装 ServerStream 才能捕获。

立即学习“go语言免费学习笔记（深入）”；

• 想统计每条消息耗时，必须实现自定义 RecvMsg/SendMsg 方法，在包装 stream 里埋点，再把包装后的 stream 传给 handler
• 流可能持续几分钟，不能像一元那样在函数开头/结尾打 start/end 时间——得靠 RecvMsg 入口和 SendMsg 出口事件驱动计时
• 官方没提供流式拦截器链式组合工具，硬写容易漏掉 CloseSend、Context().Done() 等生命周期事件，建议直接用 go-grpc-middleware.ChainStreamServer
• 常见报错 "stream terminated by RST_STREAM" 往往是包装 stream 时没正确代理 SetHeader/SendHeader，导致 header 写失败触发连接重置

监控真正难的不是打点，是指标语义对不对、维度控得住、链路不断档。一元拦截器看着简单，但 handler panic、metadata 解析失败、status code 分类错误，任何一个环节出问题，指标就失真。流式更得小心 stream 生命周期，稍不注意就漏消息或卡死连接。