在gRPC ServerInterceptor中加Histogram指标需在包初始化时用prometheus.NewHistogramVec定义，拦截器内用WithLabelValues(method, code).Observe(latency.Seconds())记录延迟，注意defer测耗时、code取status.Code(err)、buckets按5ms起始2倍递增，并区分streaming场景；client侧也应监控但目的不同，告警应基于server指标；不推荐go-grpc-prometheus，建议手写轻量拦截器。
gRPC ServerInterceptor 里怎么加 Histogram 指标
直接在 grpc.UnaryServerInterceptor 或 grpc.StreamServerInterceptor 中记录延迟，是最轻量、侵入性最小的方式。Prometheus 的 histogram_vec 必须在拦截器外初始化，否则每次请求都新建指标会崩溃或内存泄漏。
- 用
prometheus.NewHistogramVec在包初始化时（如init()或main()开头）定义指标，标签建议至少含method和code - 拦截器内调用
histogram.WithLabelValues(method, code).Observe(latency.Seconds())，注意code要从status.Code(err)提取，不是 HTTP 状态码 - 别漏掉
defer计算耗时 —— 要在 handler 执行完才测，不能在 interceptor 入口就打点
为什么 Histogram.Buckets 设成 [0.001, 0.01, 0.1, 1, 10] 容易出问题
默认 buckets 对 gRPC 延迟不友好：gRPC 多数请求在毫秒级，0.001（1ms）太小，0.01（10ms）又可能覆盖不了网络抖动场景；而 10s 上限对服务端来说往往过大，导致高延迟请求全堆在最后一个 bucket，看不出分布细节。
- 推荐起始值从
0.005（5ms）开始，按 2 倍递增：[0.005, 0.01, 0.02, 0.05, 0.1, 0.2, 0.5, 1, 2, 5] - 如果服务有长周期流式响应（如实时日志推送），单独为 streaming 方法设另一组更大 buckets
- 别硬编码在
NewHistogramVec里 —— 把 buckets 提成变量，方便压测时动态调整
client-side 延迟监控要不要做 Histogram
要，但和 server-side 目的不同：server 看处理耗时，client 看端到端感知延迟，包含网络、重试、DNS、TLS 握手等。两者偏差大时，才是定位网络或客户端配置问题的关键信号。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 在 client interceptor 里同样用
prometheus.NewHistogramVec，但标签建议加host或service，便于区分下游依赖 - 注意 client interceptor 的
ctx可能带 timeout，实际观测到的延迟可能被截断 —— 如果超时后err是context.DeadlineExceeded，仍应记录（此时 latency = timeout 值） - 避免同时开 server + client histogram 后重复报警 —— 建议告警规则只基于 server 指标，client 指标仅用于对比分析
go-grpc-prometheus 库现在还值得用吗
不推荐新项目引入 go-grpc-prometheus。它已归档（archived），最后更新是 2020 年，不支持 gRPC-Go v1.40+ 的新拦截器签名，且内置 metrics 名称和标签设计僵化（比如强制带 grpc_server_handled_latency_ms_bucket 这种过长前缀，与 Prometheus 社区惯例冲突）。
立即学习“go语言免费学习笔记（深入）”；
- 自己写 30 行以内的 interceptor 更可控，还能按需加 traceID、region 等业务标签
- 如果已有项目在用，升级 gRPC 版本前务必验证
UnaryServerInfo和StreamServerInfo结构是否匹配 - 替代方案可参考官方示例中的
prometheus.ToHistogram辅助函数（v1.6+），但它只适配grpc.ServerStatsHandler，不如 interceptor 灵活
真正难的不是打点，而是怎么让 method 标签稳定 —— protobuf 接口名带包路径，不同版本 proto 文件微小变更可能导致 label 值突变，进而让 Prometheus 的 series 数暴增。这个得靠 CI 阶段校验 proto 生成的 service name 是否符合约定。
