Go RPC性能监控需串联pprof、trace、Prometheus与压测工具：pprof定位CPU/内存瓶颈，trace分析调度与GC影响，Prometheus实现指标告警闭环，压测验证优化效果，四者时间戳与标签需对齐。
Go 的 RPC 性能监控不是“配个指标就完事”，而是得把 pprof、trace、Prometheus 和压测工具串成一条链——缺哪一环，都可能让你在高负载时抓瞎。
用 :6060/debug/pprof/ 快速定位 CPU 和内存瓶颈
这是最轻量、最直接的现场诊断入口。RPC 服务一旦变慢，第一反应不该是改代码，而是先看它在忙什么。
-
top查看哪个函数吃掉了最多 CPU 时间（注意：要采样 30 秒以上才准，go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30） -
heap看是否有 goroutine 持有大量响应体没释放，或反复json.Marshal生成新字节流 -
goroutine如果数量持续 >1k 且不回落，大概率是连接没关、channel 没收、context 没 cancel - 别只看首页汇总页——点进具体函数，看调用栈深度和自耗时（inclusive vs flat），很多性能问题藏在
rpc.(*Server).ServeConn下游的序列化或锁竞争里
用 runtime/trace 捕捉调度与 GC 对 RPC 延迟的真实影响
pprof 告诉你“谁慢”，trace 告诉你“为什么慢”。尤其当平均延迟稳定但 P99 突然飙升时，trace 是唯一能还原时间线的工具。
- 必须在 RPC 入口（比如
handleRPC或拦截器开头）启动 trace：trace.Start(f)；不能只在 main 启动——那样会混入初始化噪音 - 每个 RPC 请求建议单独 trace 一段（用
trace.NewTask），否则所有请求堆在一起，看不出单次耗时分布 - 重点看 “Goroutine blocked on chan send/receive” 和 “GC pause” 区域——如果 RPC 耗时峰值总对齐 GC 标记阶段，说明对象分配太猛，要考虑复用
sync.Pool缓冲结构体 - 导出后用
go tool trace trace.out打开，按w键放大到某次请求，再按l键查看该 goroutine 生命周期
用 grpc-prometheus + Prometheus 实现可告警的指标闭环
光看实时数据不够，得让系统自己发现异常。错误率、P95 延迟、QPS 这三类指标必须能被 Prometheus 拉取并触发告警。
立即学习“go语言免费学习笔记（深入）”；
- 拦截器注册顺序很重要：
grpc.UnaryInterceptor(grpc_prometheus.UnaryServerInterceptor)必须在自定义日志拦截器之后——否则日志里看不到真实耗时（Prometheus 拦截器会提前结束计时） - 暴露
/metrics的 HTTP server 不能和 RPC 端口共用一个net.Listener，否则健康检查失败会导致整个服务不可用；推荐独立端口如:8080 - 告警规则别写死阈值。例如
rate(grpc_server_handled_total{code!="OK"}[5m]) / rate(grpc_server_handled_total[5m]) > 0.1在低流量时段极易误报，应加条件rate(grpc_server_handled_total[5m]) > 10过滤噪声 - 务必启用 gRPC 健康检查接口（
grpc_health_v1），并在 Prometheus 中配置up == 0告警——很多“性能问题”本质是服务已僵死，只是没被发现
用 ghz 压测 + 实时 pprof 采样验证优化效果
改完代码后不压测，等于没改。但压测方式不对，结果就全是假象。
- 别用单机
ghz直接打满——网络栈和客户端 CPU 会先瓶颈。至少用 2–3 台机器分布式压测，或用k6控制并发模型 - 压测中每 30 秒自动抓一次
profile：curl -s "http://localhost:6060/debug/pprof/profile?seconds=30" > cpu-$(date +%s).pprof，最后对比前后火焰图 - 关注
grpc_server_handling_seconds_bucket的直方图指标——如果le="0.1"（100ms 内完成）占比从 95% 掉到 70%，说明小延迟请求开始排队，可能是锁或数据库连接池不足 - 压测后立刻查
goroutines：如果数量随 QPS 线性上涨且不回收，基本确认是 context 泄漏或 defer 里忘了cancel()
真正卡住人的从来不是“怎么加监控”，而是指标之间互不说话——trace 里看到 GC 停顿长，prometheus 却没报警，pprof 又没采到那一秒。把这三者的时间戳对齐、标签打通（比如都带上 service_name 和 deployment_version），才是监控落地的关键一步。
