尧图网页设计 
RPC 延迟飙升别再靠猜了go-zero 监控Prometheus 3 个指标搞定【免费下载链接】go-zeroA cloud-native Go microservices framework with cli tool for productivity.项目地址: https://gitcode.com/GitHub_Trending/go/go-zero周三下午 3 点订单接口 P99 从 80ms 跳到 2.3sGrafana 上 CPU、内存全绿没人说得清是哪个下游拖的。翻了 40 分钟日志才定位到某个方法一次慢查询最后发现不是哪台机器的问题是哪个方法的问题。当时最缺的不是硬件监控是方法级的耗时数据。go-zero 的监控恰好补的就是这块配置里加两个开关RPC 方法级的延迟直方图、错误码计数自动产出。这篇讲怎么把 go-zero 的 Prometheus 指标从 0 拉起来10 分钟能跑通全程不用改业务代码。你能带走什么3 行配置让/metrics端口吐出来curl 即见 12 个桶的延迟直方图3 行 YAML 配好 Prometheus 采集 go-zero 服务不用自写 exporter2 条 PromQL 直接算出 P99 延迟和错误率不是抄指标名2 条告警规则模板错误率 P99改个阈值就能上生产 选型逻辑为什么是 Prometheus 这套监控选型的核心取舍不是功能多少而是采集成本go-zero 的指标出口是寄生在业务进程里的没有独立 collector、不引入额外协议延迟敏感的服务零负担。这也是它比自建 APM 轻的地方。配置结构里预留了标准 Prometheus 出口core/service/serviceconf.go 里服务启动时自动拉起指标 HTTP 端口默认 9101zrpc 内置拦截器 zrpc/internal/serverinterceptors/prometheusinterceptor.go 给每个方法自动记耗时和 gRPC 错误码你一行代码不用写没配指标 Host 时所有 Observe 操作直接短路core/metric/metric.go不开监控时业务路径零开销 Phase 1让指标端口活过来交付物curl localhost:9101/metrics能拉到带rpc_server_前缀的指标行。在服务配置里加一段Prometheus: Host: 0.0.0.0 # 填了 Host 才启用 Port: 9101 # 指标端口默认即此值启动逻辑在 core/prometheus/agent.goStartAgent判断 Host 非空后起一个独立 HTTP 服务挂/metrics和 gRPC 业务端口互不干扰。验证点curl -s localhost:9101/metrics | grep rpc_server启动服务后能看到rpc_server_requests_duration_ms_bucket之类的输出说明出口通了。此时曲线还没数据——方法级指标要等 Phase 2 的拦截器。端口通了数据面还差一个开关。⚡ Phase 2打开方法级指标采集交付物Prometheus 里出现每个 RPC 方法的延迟桶和 code 计数。RPC 服务端配置里打开 Middlewares 的 Prometheus 开关Middlewares: Prometheus: true # 注册 Prometheus 拦截器注册发生在 zrpc/server.go 的setupUnaryInterceptors拦截器本体逻辑只有 4 行startTime : timex.Now() resp, err : handler(ctx, req) metricServerReqDur.Observe(timex.Since(startTime).Milliseconds(), info.FullMethod) metricServerReqCodeTotal.Inc(info.FullMethod, strconv.Itoa(int(status.Code(err))))两个指标rpc_server_requests_duration_msHistogrammethod 标签和rpc_server_requests_code_totalCountermethod code 标签。客户端侧同理RpcClientConf.Middlewares也支持这个开关zrpc/internal/clientinterceptors/prometheusinterceptor.go 记的是我调下游的耗时。验证点发起一次 RPC 调用后curl -s localhost:9101/metrics | grep -E duration_ms_bucket|code_total到这一步每个方法的耗时分布和 gRPC 错误码分布都有了PromQL 想怎么写都行。采集端还差一个 job。 Phase 3Prometheus 采集 2 条告警交付物P99 曲线和错误率曲线出现在 Grafana告警规则入库。scrape_configs: - job_name: go-zero static_configs: - targets: [10.0.0.5:9101] # 换成你的实例 scrape_interval: 15s两条最常用的查询直接建面板# P99 延迟 histogram_quantile(0.99, sum(rate(rpc_server_requests_duration_ms_bucket[5m])) by (le, method)) # 错误率code 0 即 gRPC 无错 sum(rate(rpc_server_requests_code_total{code!0}[5m])) / sum(rate(rpc_server_requests_code_total[5m]))告警规则模板- alert: GoZeroRpcErrorRate expr: | sum(rate(rpc_server_requests_code_total{code!0}[5m])) / sum(rate(rpc_server_requests_code_total[5m])) 0.01 for: 5mP99 那条把表达式里的分位数换成 0.99、阈值按你的业务 SLO 定for建议 5m避免单次毛刺刷告警。 一个设计细节值得展开延迟桶为什么这么切拦截器里那 12 个桶不是随手写的Buckets: []float64{1, 2, 5, 10, 25, 50, 100, 250, 500, 1000, 2000, 5000}core/metric/histogram.go 里NewHistogramVec把这组桶透传给 client_golangprom.MustRegister注册时还会做冲突检查——两个同名指标重复注册会直接 panic而不是悄悄覆盖这其实是帮你兜底配置错误的设计。桶的逻辑le是小于等于语义P99 落在哪个桶分辨率就是相邻两个桶之间的差值。1ms10ms 是缓存命中的常见区间切得密500ms 以后单次请求已经算事故级再细分没意义所以 2000 直接跳 5000。如果你的业务 P99 稳定在 20ms 以内这组桶在 10~25 这一段会浪费精度——Buckets字段是开放的fork 改桶分布是合法的调优手段。 我踩过的坑端口开着但只有 runtime 指标→ 原因没开Middlewares.Prometheus。StartAgent只起端口方法级指标全靠拦截器开关在 RPC 配置里不在 ServiceConf 里。解法Phase 2 那行开关补上重启。curl 9101 拒绝连接日志没报错→ 原因StartAgent对 Host 为空直接 return监听失败也只在日志里记一条。解法ss -lntp | grep 9101确认端口归属再回配置确认 Host 没拼错。Prometheus 侧内存涨得快→ 原因标签基数问题。method标签基数 方法数几十个没问题但如果哪天有人往code位置塞了业务自定义串比如把错误信息塞进 code基数就爆了。解法Grafana 里对rpc_server_requests_code_total的 code 值做一次count by (code)巡检采集间隔保持 15s 起步别用 1s。效果Before vs After以下为示例数据实际因业务而异指标接入前接入后变化幅度单次慢查询定位耗时40min翻日志重启复现5min 内P99 曲线 code 分布约 8 倍慢方法发现时机用户反馈后告警先于用户由被动转主动P99 回归确认人工压测对比一条 PromQL由天级到分钟级新增监控点成本每接口手写埋点零代码开关默认存在从代码级到配置级核心变化一句话定位问题从猜哪台机器变成查哪个 method。下一步接上调用链—— zrpc 的Telemetry配置位已就位指标和 trace 用同一套 id 关联补下游视角—— 客户端侧拦截器已内置我慢还是下游慢一眼分出来持续剖析——ServiceConf里的Profiling配置接 Pyroscope不用等 OOM 才开 pprof最小行动今晚把 Phase 1 和 Phase 2 那两段配置加到 staging 环境明天就能看到第一条方法级 P99 曲线。【免费下载链接】go-zeroA cloud-native Go microservices framework with cli tool for productivity.项目地址: https://gitcode.com/GitHub_Trending/go/go-zero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 RPC 延迟飙升别再靠猜了：go-zero 监控+Prometheus 3 个指标搞定
RPC 延迟飙升别再靠猜了go-zero 监控Prometheus 3 个指标搞定【免费下载链接】go-zeroA cloud-native Go microservices framework with cli tool for productivity.项目地址: https://gitcode.com/GitHub_Trending/go/go-zero周三下午 3 点订单接口 P99 从 80ms 跳到 2.3sGrafana 上 CPU、内存全绿没人说得清是哪个下游拖的。翻了 40 分钟日志才定位到某个方法一次慢查询最后发现不是哪台机器的问题是哪个方法的问题。当时最缺的不是硬件监控是方法级的耗时数据。go-zero 的监控恰好补的就是这块配置里加两个开关RPC 方法级的延迟直方图、错误码计数自动产出。这篇讲怎么把 go-zero 的 Prometheus 指标从 0 拉起来10 分钟能跑通全程不用改业务代码。你能带走什么3 行配置让/metrics端口吐出来curl 即见 12 个桶的延迟直方图3 行 YAML 配好 Prometheus 采集 go-zero 服务不用自写 exporter2 条 PromQL 直接算出 P99 延迟和错误率不是抄指标名2 条告警规则模板错误率 P99改个阈值就能上生产 选型逻辑为什么是 Prometheus 这套监控选型的核心取舍不是功能多少而是采集成本go-zero 的指标出口是寄生在业务进程里的没有独立 collector、不引入额外协议延迟敏感的服务零负担。这也是它比自建 APM 轻的地方。配置结构里预留了标准 Prometheus 出口core/service/serviceconf.go 里服务启动时自动拉起指标 HTTP 端口默认 9101zrpc 内置拦截器 zrpc/internal/serverinterceptors/prometheusinterceptor.go 给每个方法自动记耗时和 gRPC 错误码你一行代码不用写没配指标 Host 时所有 Observe 操作直接短路core/metric/metric.go不开监控时业务路径零开销 Phase 1让指标端口活过来交付物curl localhost:9101/metrics能拉到带rpc_server_前缀的指标行。在服务配置里加一段Prometheus: Host: 0.0.0.0 # 填了 Host 才启用 Port: 9101 # 指标端口默认即此值启动逻辑在 core/prometheus/agent.goStartAgent判断 Host 非空后起一个独立 HTTP 服务挂/metrics和 gRPC 业务端口互不干扰。验证点curl -s localhost:9101/metrics | grep rpc_server启动服务后能看到rpc_server_requests_duration_ms_bucket之类的输出说明出口通了。此时曲线还没数据——方法级指标要等 Phase 2 的拦截器。端口通了数据面还差一个开关。⚡ Phase 2打开方法级指标采集交付物Prometheus 里出现每个 RPC 方法的延迟桶和 code 计数。RPC 服务端配置里打开 Middlewares 的 Prometheus 开关Middlewares: Prometheus: true # 注册 Prometheus 拦截器注册发生在 zrpc/server.go 的setupUnaryInterceptors拦截器本体逻辑只有 4 行startTime : timex.Now() resp, err : handler(ctx, req) metricServerReqDur.Observe(timex.Since(startTime).Milliseconds(), info.FullMethod) metricServerReqCodeTotal.Inc(info.FullMethod, strconv.Itoa(int(status.Code(err))))两个指标rpc_server_requests_duration_msHistogrammethod 标签和rpc_server_requests_code_totalCountermethod code 标签。客户端侧同理RpcClientConf.Middlewares也支持这个开关zrpc/internal/clientinterceptors/prometheusinterceptor.go 记的是我调下游的耗时。验证点发起一次 RPC 调用后curl -s localhost:9101/metrics | grep -E duration_ms_bucket|code_total到这一步每个方法的耗时分布和 gRPC 错误码分布都有了PromQL 想怎么写都行。采集端还差一个 job。 Phase 3Prometheus 采集 2 条告警交付物P99 曲线和错误率曲线出现在 Grafana告警规则入库。scrape_configs: - job_name: go-zero static_configs: - targets: [10.0.0.5:9101] # 换成你的实例 scrape_interval: 15s两条最常用的查询直接建面板# P99 延迟 histogram_quantile(0.99, sum(rate(rpc_server_requests_duration_ms_bucket[5m])) by (le, method)) # 错误率code 0 即 gRPC 无错 sum(rate(rpc_server_requests_code_total{code!0}[5m])) / sum(rate(rpc_server_requests_code_total[5m]))告警规则模板- alert: GoZeroRpcErrorRate expr: | sum(rate(rpc_server_requests_code_total{code!0}[5m])) / sum(rate(rpc_server_requests_code_total[5m])) 0.01 for: 5mP99 那条把表达式里的分位数换成 0.99、阈值按你的业务 SLO 定for建议 5m避免单次毛刺刷告警。 一个设计细节值得展开延迟桶为什么这么切拦截器里那 12 个桶不是随手写的Buckets: []float64{1, 2, 5, 10, 25, 50, 100, 250, 500, 1000, 2000, 5000}core/metric/histogram.go 里NewHistogramVec把这组桶透传给 client_golangprom.MustRegister注册时还会做冲突检查——两个同名指标重复注册会直接 panic而不是悄悄覆盖这其实是帮你兜底配置错误的设计。桶的逻辑le是小于等于语义P99 落在哪个桶分辨率就是相邻两个桶之间的差值。1ms10ms 是缓存命中的常见区间切得密500ms 以后单次请求已经算事故级再细分没意义所以 2000 直接跳 5000。如果你的业务 P99 稳定在 20ms 以内这组桶在 10~25 这一段会浪费精度——Buckets字段是开放的fork 改桶分布是合法的调优手段。 我踩过的坑端口开着但只有 runtime 指标→ 原因没开Middlewares.Prometheus。StartAgent只起端口方法级指标全靠拦截器开关在 RPC 配置里不在 ServiceConf 里。解法Phase 2 那行开关补上重启。curl 9101 拒绝连接日志没报错→ 原因StartAgent对 Host 为空直接 return监听失败也只在日志里记一条。解法ss -lntp | grep 9101确认端口归属再回配置确认 Host 没拼错。Prometheus 侧内存涨得快→ 原因标签基数问题。method标签基数 方法数几十个没问题但如果哪天有人往code位置塞了业务自定义串比如把错误信息塞进 code基数就爆了。解法Grafana 里对rpc_server_requests_code_total的 code 值做一次count by (code)巡检采集间隔保持 15s 起步别用 1s。效果Before vs After以下为示例数据实际因业务而异指标接入前接入后变化幅度单次慢查询定位耗时40min翻日志重启复现5min 内P99 曲线 code 分布约 8 倍慢方法发现时机用户反馈后告警先于用户由被动转主动P99 回归确认人工压测对比一条 PromQL由天级到分钟级新增监控点成本每接口手写埋点零代码开关默认存在从代码级到配置级核心变化一句话定位问题从猜哪台机器变成查哪个 method。下一步接上调用链—— zrpc 的Telemetry配置位已就位指标和 trace 用同一套 id 关联补下游视角—— 客户端侧拦截器已内置我慢还是下游慢一眼分出来持续剖析——ServiceConf里的Profiling配置接 Pyroscope不用等 OOM 才开 pprof最小行动今晚把 Phase 1 和 Phase 2 那两段配置加到 staging 环境明天就能看到第一条方法级 P99 曲线。【免费下载链接】go-zeroA cloud-native Go microservices framework with cli tool for productivity.项目地址: https://gitcode.com/GitHub_Trending/go/go-zero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考