3 行配置把 go-zero 服务接上 Prometheus 监控完整上手指南【免费下载链接】go-zeroA cloud-native Go microservices framework with cli tool for productivity.项目地址: https://gitcode.com/GitHub_Trending/go/go-zero运维说接口变慢了你去查查时你最好的回应不是服务没挂而是一张延迟分布大盘。如果你的服务是用 go-zero一个云原生 Go 微服务框架写的这事比你想的简单框架内置了监控底座你只需在 YAML 里加一段配置就能拿到一个 Prometheus 兼容的指标出口默认端口 9101不用手写任何埋点代码。写正文前先把大家最常问的 4 个问题列出来开指标出口最少要改多少代码Prometheus 怎么配置采集有什么坑指标里的延迟直方图怎么读告警阈值定多少才算合理下面按顺序回答。问题一怎么启用指标暴露RPC 服务默认就开着 Prometheus 开关你真正要补的只是往哪暴露这一段配置。go-zero 的 RPC 服务配置里zrpc/internal/config.go 的Middlewares.Prometheus字段默认为true服务端启动时会自动挂上指标拦截器自动记录每次调用的耗时和错误码这部分你一个字符都不用写。REST 服务的配置rest/config.go里也有同样的开关。所以你唯一要做的是告诉它监听哪个地址Prometheus: Host: 0.0.0.0 # 不填的话 agent 根本不会启动 Port: 9101 # 默认 9101 Path: /metrics # 默认 /metrics配置结构定义在 core/prometheus/config.go服务启动时由 core/service/serviceconf.go 自动调用 StartAgent 拉起这个 HTTP 服务。这里有个最容易踩的坑Host 为空时 StartAgent 直接返回9101 端口不会监听。只写 Port 忘了 Host抓包抓半天找不到原因初期联调尤其要小心。服务起来后一条命令验证链路通了没有curl http://localhost:9101/metrics看到rpc_server_requests_duration_ms开头的行说明出口已经就绪。出口既然通了剩下就是让 Prometheus 知道去哪儿抓数据。问题二Prometheus 怎么配采集在 prometheus.yml 里加一个 job把服务地址填进 targetsscrape_configs: - job_name: go-zero scrape_interval: 5s static_configs: - targets: [10.0.0.5:9101]多实例部署时别手写静态列表用 Kubernetes Service 注解或 PodMonitor 做自动发现服务扩缩容后采集目标自动增减。几个实操参数建议参数建议值说明scrape_interval5s采集粒度与开销的平衡点采集窗口5m 起算PromQL 里 rate 的窗口别小于采集间隔的 10 倍9101 端口仅限内网明文 HTTP无任何鉴权9101 是个裸 HTTP 端口没有鉴权机制千万不要暴露到公网用安全组或内网策略限制访问来源。数据抓进来之后真正要回答的问题是这些指标里哪几个值得盯。问题三两个核心指标怎么读/metrics 输出里最值得看的是这两条都由服务端拦截器产生指标名类型标签作用rpc_server_requests_duration_mshistogrammethod各方法请求耗时分布rpc_server_requests_code_totalcountermethod, code各方法错误码计数直方图的桶边界预定义为 1, 2, 5, 10, 25, 50, 100, 250, 500, 1000, 2000, 5000单位毫秒。桶越密分位数算得越准500 恰好是一个桶边界所以P95 超 500ms可以直接写成一条告警线。如果你的业务接口基本都在 50ms 内返回可以参照 core/metric/histogram.go 在低延迟区间补更细的桶。P95 在大盘里用这个公式查histogram_quantile(0.95, sum(rate(rpc_server_requests_duration_ms_bucket[5m])) by (le, method))别看均值微服务场景看分位数——均值会被大量快请求拉低把偶发的慢调用藏得无影无踪而用户感知到的恰恰是那些慢的。指标会看了下一步是让它在异常时主动喊你而不是等人去刷大盘。问题四告警阈值怎么定阈值不拍脑袋每一条都挂在一个已存在的指标上告警规则级别服务不可用连续 3 次抓取失败P0错误率升高5 分钟窗口内非零码占比 1%P2延迟劣化P95 500ms 持续 5 分钟P3P2 那条对应的 PromQLsum(rate(rpc_server_requests_code_total{code!0}[5m])) / sum(rate(rpc_server_requests_code_total[5m])) 0.01两个容易写错的地方这里的 code 是 gRPC status code不是 HTTP 状态码所以非零即异常在 RPC 服务上是成立的别套 5xx 的写法QPS 上万的高频接口抓取间隔可以放到 15s存储压力小很多5 分钟窗口的告警精度不受影响如果你还想把单次调用的链路日志串起来go-zero 的 core/trace/ 内置了 OpenTelemetry 支持那是另一篇话题。到这一步你的服务从挂了没有升级到了P95 多少毫秒、哪个方法在报错代价只是一段 YAML 加一个 scrape job。**监控的价值不在于多了一张大盘而在于故障发生时你手里有具体数字可以说话。**现在就去把你的服务配置里加上那三行 Prometheus 配置重启后用 curl 确认 /metrics 有输出再把第一个抓取 job 接进 Prometheus。【免费下载链接】go-zeroA cloud-native Go microservices framework with cli tool for productivity.项目地址: https://gitcode.com/GitHub_Trending/go/go-zero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
3 行配置把 go-zero 服务接上 Prometheus 监控：完整上手指南
3 行配置把 go-zero 服务接上 Prometheus 监控完整上手指南【免费下载链接】go-zeroA cloud-native Go microservices framework with cli tool for productivity.项目地址: https://gitcode.com/GitHub_Trending/go/go-zero运维说接口变慢了你去查查时你最好的回应不是服务没挂而是一张延迟分布大盘。如果你的服务是用 go-zero一个云原生 Go 微服务框架写的这事比你想的简单框架内置了监控底座你只需在 YAML 里加一段配置就能拿到一个 Prometheus 兼容的指标出口默认端口 9101不用手写任何埋点代码。写正文前先把大家最常问的 4 个问题列出来开指标出口最少要改多少代码Prometheus 怎么配置采集有什么坑指标里的延迟直方图怎么读告警阈值定多少才算合理下面按顺序回答。问题一怎么启用指标暴露RPC 服务默认就开着 Prometheus 开关你真正要补的只是往哪暴露这一段配置。go-zero 的 RPC 服务配置里zrpc/internal/config.go 的Middlewares.Prometheus字段默认为true服务端启动时会自动挂上指标拦截器自动记录每次调用的耗时和错误码这部分你一个字符都不用写。REST 服务的配置rest/config.go里也有同样的开关。所以你唯一要做的是告诉它监听哪个地址Prometheus: Host: 0.0.0.0 # 不填的话 agent 根本不会启动 Port: 9101 # 默认 9101 Path: /metrics # 默认 /metrics配置结构定义在 core/prometheus/config.go服务启动时由 core/service/serviceconf.go 自动调用 StartAgent 拉起这个 HTTP 服务。这里有个最容易踩的坑Host 为空时 StartAgent 直接返回9101 端口不会监听。只写 Port 忘了 Host抓包抓半天找不到原因初期联调尤其要小心。服务起来后一条命令验证链路通了没有curl http://localhost:9101/metrics看到rpc_server_requests_duration_ms开头的行说明出口已经就绪。出口既然通了剩下就是让 Prometheus 知道去哪儿抓数据。问题二Prometheus 怎么配采集在 prometheus.yml 里加一个 job把服务地址填进 targetsscrape_configs: - job_name: go-zero scrape_interval: 5s static_configs: - targets: [10.0.0.5:9101]多实例部署时别手写静态列表用 Kubernetes Service 注解或 PodMonitor 做自动发现服务扩缩容后采集目标自动增减。几个实操参数建议参数建议值说明scrape_interval5s采集粒度与开销的平衡点采集窗口5m 起算PromQL 里 rate 的窗口别小于采集间隔的 10 倍9101 端口仅限内网明文 HTTP无任何鉴权9101 是个裸 HTTP 端口没有鉴权机制千万不要暴露到公网用安全组或内网策略限制访问来源。数据抓进来之后真正要回答的问题是这些指标里哪几个值得盯。问题三两个核心指标怎么读/metrics 输出里最值得看的是这两条都由服务端拦截器产生指标名类型标签作用rpc_server_requests_duration_mshistogrammethod各方法请求耗时分布rpc_server_requests_code_totalcountermethod, code各方法错误码计数直方图的桶边界预定义为 1, 2, 5, 10, 25, 50, 100, 250, 500, 1000, 2000, 5000单位毫秒。桶越密分位数算得越准500 恰好是一个桶边界所以P95 超 500ms可以直接写成一条告警线。如果你的业务接口基本都在 50ms 内返回可以参照 core/metric/histogram.go 在低延迟区间补更细的桶。P95 在大盘里用这个公式查histogram_quantile(0.95, sum(rate(rpc_server_requests_duration_ms_bucket[5m])) by (le, method))别看均值微服务场景看分位数——均值会被大量快请求拉低把偶发的慢调用藏得无影无踪而用户感知到的恰恰是那些慢的。指标会看了下一步是让它在异常时主动喊你而不是等人去刷大盘。问题四告警阈值怎么定阈值不拍脑袋每一条都挂在一个已存在的指标上告警规则级别服务不可用连续 3 次抓取失败P0错误率升高5 分钟窗口内非零码占比 1%P2延迟劣化P95 500ms 持续 5 分钟P3P2 那条对应的 PromQLsum(rate(rpc_server_requests_code_total{code!0}[5m])) / sum(rate(rpc_server_requests_code_total[5m])) 0.01两个容易写错的地方这里的 code 是 gRPC status code不是 HTTP 状态码所以非零即异常在 RPC 服务上是成立的别套 5xx 的写法QPS 上万的高频接口抓取间隔可以放到 15s存储压力小很多5 分钟窗口的告警精度不受影响如果你还想把单次调用的链路日志串起来go-zero 的 core/trace/ 内置了 OpenTelemetry 支持那是另一篇话题。到这一步你的服务从挂了没有升级到了P95 多少毫秒、哪个方法在报错代价只是一段 YAML 加一个 scrape job。**监控的价值不在于多了一张大盘而在于故障发生时你手里有具体数字可以说话。**现在就去把你的服务配置里加上那三行 Prometheus 配置重启后用 curl 确认 /metrics 有输出再把第一个抓取 job 接进 Prometheus。【免费下载链接】go-zeroA cloud-native Go microservices framework with cli tool for productivity.项目地址: https://gitcode.com/GitHub_Trending/go/go-zero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考