尧图网站建设 
go-zero 监控实战5 步把 /metrics 接到 Grafana慢接口一次看清【免费下载链接】go-zeroA cloud-native Go microservices framework with cli tool for productivity.项目地址: https://gitcode.com/GitHub_Trending/go/go-zero上周一个 go-zero 服务被反馈偶发超时日志里只留下一行 502。这类平时很快、偶尔很慢的问题靠翻日志很难收敛。go-zero 自带的监控能力正好补上这一环框架内置 Prometheus 指标出口和 RPC 埋点不改业务代码就能把接口耗时、错误率变成可查询、可告警的数字。go-zero 内置的可观测能力一览先交代清楚框架里已经有什么避免重复造轮子能力说明对应模块指标出口配置里加一段 Prometheus 配置框架即在 9101 端口提供 /metrics HTTP 端点core/prometheus/RPC 自动埋点一元调用的耗时直方图 错误码计数按方法名打标签zrpc/internal/serverinterceptors/prometheusinterceptor.goREST 指标HTTP 请求侧有对应的指标处理器rest/handler/metrichandler.go追踪代理基于 OpenTelemetry调用链 trace id 可落入日志core/trace/持续性能分析CPU 超过阈值才自动采样平时零开销internal/profiling/profiling.go指标原语counter、gauge、histogram、summary 四类基础指标core/metric/配置的统一入口在 core/service/serviceconf.goServiceConf解析完配置后自动调用 core/prometheus/agent.go 里的StartAgent也就是说指标端点不需要你手动启动。最小可行链路从配置到看板只走 5 步下面按真实操作顺序走最短链路每步附一个如何确认成功的验收点。第 1 步go-zero Prometheus 配置加一段就行在现有服务配置yaml/json里加一段字段默认值见 core/prometheus/config.goPrometheus: Host: 0.0.0.0 # 不填则不开启指标端点 Port: 9101 # 默认 9101 Path: /metrics # 默认 /metrics验收重启服务启动日志出现Starting prometheus agent at 0.0.0.0:9101。第 2 步给 RPC 服务挂上监控拦截器拦截器interceptor可以理解为自动包在每个 RPC 调用外面的一层函数调用前记开始时间调用后记耗时和状态码业务代码完全无感知。s : zrpc.MustNewServer(c.RpcServerConf, func(gs *grpc.Server) { gs.Use(serverinterceptors.UnaryPrometheusInterceptor) }) defer s.Stop()验收进程正常启动且发一次任意方法请求后不报错。第 3 步3 分钟启用 /metrics 验证直接请求指标端点curl http://127.0.0.1:9101/metrics返回的是 Prometheus 文本格式重点确认两项rpc_server_requests_duration_ms_bucket{method...,le...}耗时直方图按方法分标签rpc_server_requests_code_total{method...,code0}错误码计数code0表示成功。验收发过请求后对应 method 的各桶计数不再是 0。第 4 步接入 Prometheus 抓取在 prometheus.yml 里加一个 jobscrape_configs: - job_name: go-zero scrape_interval: 15s static_configs: - targets: [10.0.0.11:9101, 10.0.0.12:9101]验收Prometheus 的 Targets 页面中实例状态为 UPup指标值为 1。第 5 步go-zero 接入 Grafana出第一块面板Grafana 新建 Prometheus 数据源用下面这条 PromQL 按接口统计 P95 耗时就能画出第一块有信息量的面板histogram_quantile(0.95, sum by (method, le) (rate(rpc_server_requests_duration_ms_bucket[5m])))验收面板出现曲线方法名与代码里的 RPC 方法一一对应。到这里监控盲区就有了第一束光。指标怎么读盯住这两个数字指标不在多读得懂才有用。下面两个覆盖了绝大多数接口慢、接口错的初判。耗时直方图P95 落在哪个桶直方图histogram就是按区间分桶计数请求耗时落在哪个区间哪个桶加一。go-zero 默认桶边界为 1、2、5、10、25、50、100、250、500、1000、2000、5000 毫秒定义在 zrpc/internal/serverinterceptors/prometheusinterceptor.go。看到数字怎么解读某接口计数集中在le10说明绝大多数请求 10ms 内完成如果曲线尾部向le1000一侧堆积说明出现长尾慢请求——接口慢从一句抱怨变成了具体形态。桶分布可按业务调整原语在 core/metric/histogram.go。错误码计数哪个方法在报错code_total是只增计数器code 取 gRPC 状态码。看的是非 0 code 的增速比如 5 分钟内某方法code14Unavailable从 0 涨到 200基本可以断定是下游不可用而不是业务逻辑问题排查方向立刻收窄。从监控到定位用追踪 ID 串起日志与性能数据指标回答哪个方法慢、错得多定位还要把三个数据源串成一条线追踪 ID 定现场。go-zero 的追踪代理基于 OpenTelemetrycore/trace/agent.gotrace id 会自动带进日志。先用告警时间点从 Grafana 锁定异常方法再按 trace id 过滤日志即可拿到单次调用的完整上下文internal/trace/trace.go 提供了从 context 中提取 trace id 的工具函数。持续性能分析定函数。internal/profiling/profiling.go 接入了 Grafana Pyroscope只有 CPU 使用率超过阈值默认 700‰约 70%时才自动开始采样并上传平时不产生额外开销避免为了监控反而拖慢服务。组合顺序指标定时间窗 → 日志按 trace id 定现场 → 火焰图定到具体函数。生产落地清单 上生产前逐项过一遍每条都能直接执行采集间隔 15s 起步实例数量多再放宽别让监控系统本身成为负载桶分布对齐 SLA业务关注 100ms 内响应就把桶向低延迟段加密而不是均匀铺开错误码看板按方法 × code分组只盯非 0 code 的增速减少噪音告警分级错误率 5 分钟 1% 记 P2P95 500ms 记 P3健康检查连续失败记 P09101 端口只对监控网段开放不暴露到业务网络Grafana 数据源和面板配置纳入版本管理防止人员变动后配置丢失下一步这条链路里 go-zero 只暴露一个 HTTP 端点重活交给 Prometheus 和 Grafana改动集中在一段配置和一行拦截器注册对业务代码几乎零侵入。现在就打开你的服务配置加上 Prometheus 那段配置重启后curl一下 9101 端口——十分钟就能看到第一组指标。【免费下载链接】go-zeroA cloud-native Go microservices framework with cli tool for productivity.项目地址: https://gitcode.com/GitHub_Trending/go/go-zero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 go-zero 监控实战：5 步把 /metrics 接到 Grafana，慢接口一次看清
go-zero 监控实战5 步把 /metrics 接到 Grafana慢接口一次看清【免费下载链接】go-zeroA cloud-native Go microservices framework with cli tool for productivity.项目地址: https://gitcode.com/GitHub_Trending/go/go-zero上周一个 go-zero 服务被反馈偶发超时日志里只留下一行 502。这类平时很快、偶尔很慢的问题靠翻日志很难收敛。go-zero 自带的监控能力正好补上这一环框架内置 Prometheus 指标出口和 RPC 埋点不改业务代码就能把接口耗时、错误率变成可查询、可告警的数字。go-zero 内置的可观测能力一览先交代清楚框架里已经有什么避免重复造轮子能力说明对应模块指标出口配置里加一段 Prometheus 配置框架即在 9101 端口提供 /metrics HTTP 端点core/prometheus/RPC 自动埋点一元调用的耗时直方图 错误码计数按方法名打标签zrpc/internal/serverinterceptors/prometheusinterceptor.goREST 指标HTTP 请求侧有对应的指标处理器rest/handler/metrichandler.go追踪代理基于 OpenTelemetry调用链 trace id 可落入日志core/trace/持续性能分析CPU 超过阈值才自动采样平时零开销internal/profiling/profiling.go指标原语counter、gauge、histogram、summary 四类基础指标core/metric/配置的统一入口在 core/service/serviceconf.goServiceConf解析完配置后自动调用 core/prometheus/agent.go 里的StartAgent也就是说指标端点不需要你手动启动。最小可行链路从配置到看板只走 5 步下面按真实操作顺序走最短链路每步附一个如何确认成功的验收点。第 1 步go-zero Prometheus 配置加一段就行在现有服务配置yaml/json里加一段字段默认值见 core/prometheus/config.goPrometheus: Host: 0.0.0.0 # 不填则不开启指标端点 Port: 9101 # 默认 9101 Path: /metrics # 默认 /metrics验收重启服务启动日志出现Starting prometheus agent at 0.0.0.0:9101。第 2 步给 RPC 服务挂上监控拦截器拦截器interceptor可以理解为自动包在每个 RPC 调用外面的一层函数调用前记开始时间调用后记耗时和状态码业务代码完全无感知。s : zrpc.MustNewServer(c.RpcServerConf, func(gs *grpc.Server) { gs.Use(serverinterceptors.UnaryPrometheusInterceptor) }) defer s.Stop()验收进程正常启动且发一次任意方法请求后不报错。第 3 步3 分钟启用 /metrics 验证直接请求指标端点curl http://127.0.0.1:9101/metrics返回的是 Prometheus 文本格式重点确认两项rpc_server_requests_duration_ms_bucket{method...,le...}耗时直方图按方法分标签rpc_server_requests_code_total{method...,code0}错误码计数code0表示成功。验收发过请求后对应 method 的各桶计数不再是 0。第 4 步接入 Prometheus 抓取在 prometheus.yml 里加一个 jobscrape_configs: - job_name: go-zero scrape_interval: 15s static_configs: - targets: [10.0.0.11:9101, 10.0.0.12:9101]验收Prometheus 的 Targets 页面中实例状态为 UPup指标值为 1。第 5 步go-zero 接入 Grafana出第一块面板Grafana 新建 Prometheus 数据源用下面这条 PromQL 按接口统计 P95 耗时就能画出第一块有信息量的面板histogram_quantile(0.95, sum by (method, le) (rate(rpc_server_requests_duration_ms_bucket[5m])))验收面板出现曲线方法名与代码里的 RPC 方法一一对应。到这里监控盲区就有了第一束光。指标怎么读盯住这两个数字指标不在多读得懂才有用。下面两个覆盖了绝大多数接口慢、接口错的初判。耗时直方图P95 落在哪个桶直方图histogram就是按区间分桶计数请求耗时落在哪个区间哪个桶加一。go-zero 默认桶边界为 1、2、5、10、25、50、100、250、500、1000、2000、5000 毫秒定义在 zrpc/internal/serverinterceptors/prometheusinterceptor.go。看到数字怎么解读某接口计数集中在le10说明绝大多数请求 10ms 内完成如果曲线尾部向le1000一侧堆积说明出现长尾慢请求——接口慢从一句抱怨变成了具体形态。桶分布可按业务调整原语在 core/metric/histogram.go。错误码计数哪个方法在报错code_total是只增计数器code 取 gRPC 状态码。看的是非 0 code 的增速比如 5 分钟内某方法code14Unavailable从 0 涨到 200基本可以断定是下游不可用而不是业务逻辑问题排查方向立刻收窄。从监控到定位用追踪 ID 串起日志与性能数据指标回答哪个方法慢、错得多定位还要把三个数据源串成一条线追踪 ID 定现场。go-zero 的追踪代理基于 OpenTelemetrycore/trace/agent.gotrace id 会自动带进日志。先用告警时间点从 Grafana 锁定异常方法再按 trace id 过滤日志即可拿到单次调用的完整上下文internal/trace/trace.go 提供了从 context 中提取 trace id 的工具函数。持续性能分析定函数。internal/profiling/profiling.go 接入了 Grafana Pyroscope只有 CPU 使用率超过阈值默认 700‰约 70%时才自动开始采样并上传平时不产生额外开销避免为了监控反而拖慢服务。组合顺序指标定时间窗 → 日志按 trace id 定现场 → 火焰图定到具体函数。生产落地清单 上生产前逐项过一遍每条都能直接执行采集间隔 15s 起步实例数量多再放宽别让监控系统本身成为负载桶分布对齐 SLA业务关注 100ms 内响应就把桶向低延迟段加密而不是均匀铺开错误码看板按方法 × code分组只盯非 0 code 的增速减少噪音告警分级错误率 5 分钟 1% 记 P2P95 500ms 记 P3健康检查连续失败记 P09101 端口只对监控网段开放不暴露到业务网络Grafana 数据源和面板配置纳入版本管理防止人员变动后配置丢失下一步这条链路里 go-zero 只暴露一个 HTTP 端点重活交给 Prometheus 和 Grafana改动集中在一段配置和一行拦截器注册对业务代码几乎零侵入。现在就打开你的服务配置加上 Prometheus 那段配置重启后curl一下 9101 端口——十分钟就能看到第一组指标。【免费下载链接】go-zeroA cloud-native Go microservices framework with cli tool for productivity.项目地址: https://gitcode.com/GitHub_Trending/go/go-zero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考