Go服务可观测性:Prometheus指标与Grafana面板摘要: 本篇讲解Go服务可观测性建设涵盖Prometheus client_golang暴露指标、四种指标类型(Counter/Gauge/Histogram/Summary)的使用场景与代码示例、Grafana Dashboard配置JSON、PromQL查询语句分享Histogram bucket设置不合理导致P99分位数计算严重偏差的踩坑经历对比Prometheus、InfluxDB、OpenTSDB、Datadog四款监控方案。开篇故事去年我们有个支付服务上线后用户反馈偶尔慢。我登服务器看日志一切正常。问运维有没有监控说只有CPU和内存的系统级监控。服务本身的QPS、延迟、错误率完全看不到。出了问题只能靠猜加日志重启看一遍然后等下次复现。后来花了一周接了Prometheus和Grafana。给每个HTTP接口加了延迟Histogram给支付成功率加了Counter。Grafana面板上一看支付接口的P99延迟在每天下午两点准时飙升。查了那个时段的请求特征发现是某个银行的回调接口超时导致连接池占满。加了个超时控制就解决了。可观测性这个东西没有的时候你不知道自己丢了什么有了之后再也回不去了。一、Prometheus指标暴露Prometheus用pull模式采集指标服务需要暴露一个/metrics端点。Go用client_golang库来做这件事。packagemainimport(net/httptimegithub.com/prometheus/client_golang/prometheusgithub.com/prometheus/client_golang/prometheus/promhttp)// 定义全局指标变量在init中注册var(// Counter:只增不减的计数器适合请求数、错误数httpRequestsTotalprometheus.NewCounterVec(prometheus.CounterOpts{Name:http_requests_total,Help:HTTP请求总数,},// 标签维度:接口路径和HTTP状态码[]string{path,status},)// Gauge:可增可减的瞬时值适合连接数、队列长度activeConnectionsprometheus.NewGauge(prometheus.GaugeOpts{Name:active_connections,Help:当前活跃连接数,},)// Histogram:分桶统计适合延迟分布httpRequestDurationprometheus.NewHistogramVec(prometheus.HistogramOpts{Name:http_request_duration_seconds,Help:HTTP请求延迟分布,// bucket定义很关键后面会详细讲Buckets:[]float64{0.005,0.01,0.025,0.05,0.1,0.25,0.5,1,2.5,5,10,},},[]string{path,method},)// Summary:客户端计算分位数httpRequestSummaryprometheus.NewSummaryVec(prometheus.SummaryOpts{Name:http_request_summary_seconds,Help:HTTP请求延迟摘要,// 客户端计算分位数直接输出P50/P90/P99Objectives:map[float64]float64{0.5:0.05,// P50误差5%0.9:0.01,// P90误差1%0.99:0.001,// P99误差0.1%},},[]string{path},))funcinit(){// 注册指标到默认注册表prometheus.MustRegister(httpRequestsTotal)prometheus.MustRegister(activeConnections)prometheus.MustRegister(httpRequestDuration)prometheus.MustRegister(httpRequestSummary)}// metricsMiddleware 包装HTTP handler自动采集指标funcmetricsMiddleware(next http.Handler)http.Handler{returnhttp.HandlerFunc(func(w http.ResponseWriter,r*http.Request){start:time.Now()// 用responseWriter包装器捕获状态码ww:statusWriter{ResponseWriter:w,status:200}// 活跃连接数1activeConnections.Inc()deferactiveConnections.Dec()// 请求结束-1next.ServeHTTP(ww,r)// 记录请求计数httpRequestsTotal.WithLabelValues(r.URL.Path,http.StatusText(ww.status)).Inc()// 记录延迟duration:time.Since(start).Seconds()httpRequestDuration.WithLabelValues(r.URL.Path,r.Method).Observe(duration)httpRequestSummary.WithLabelValues(r.URL.Path).Observe(duration)})}// statusWriter 包装http.ResponseWriter捕获状态码typestatusWriterstruct{http.ResponseWriter statusint}func(w*statusWriter)WriteHeader(statusint){w.statusstatus w.ResponseWriter.WriteHeader(status)}funcmain(){mux:http.NewServeMux()mux.HandleFunc(/api/pay,func(w http.ResponseWriter,r*http.Request){// 模拟业务逻辑time.Sleep(50*time.Millisecond)w.Write([]byte({status:ok}))})// 注册/metrics端点Prometheus从这里采集mux.Handle(/metrics,promhttp.Handler())// 用中间件包装http.ListenAndServe(:8080,metricsMiddleware(mux))}四种指标类型的适用场景要分清。Counter只增不减适合请求数和错误数。Gauge可增可减适合当前连接数和队列长度。Histogram做分桶统计适合延迟分布。Summary在客户端直接算分位数适合需要精确P99的场景。二、Histogram与Summary的选择很多人在Histogram和Summary之间纠结。核心区别在于分位数在哪里算。// Histogram:客户端只做分桶分位数由Prometheus服务端用PromQL算// 优势:可以在服务端做聚合多个实例的分位数可以合并计算// 劣势:分位数是近似值精度受bucket划分影响// 查询P99延迟(PromQL)// histogram_quantile(0.99,// rate(http_request_duration_seconds_bucket[5m]))// Summary:客户端直接算分位数// 优势:分位数精确不需要额外计算// 劣势:多个实例的分位数无法聚合只能取平均值// 查询P99延迟(PromQL)// http_request_summary_seconds{quantile0.99}生产环境推荐用Histogram。原因很简单多实例部署时你需要看整体P99。Summary的P99无法跨实例聚合只能看单机数据。Histogram的bucket数据可以跨实例相加后再算分位数。三、Grafana Dashboard配置Grafana通过JSON文件定义面板可以导入导出。下面是一个监控支付服务的Dashboard配置。{title:Go支付服务监控,timezone:browser,panels:[{title:QPS(每秒请求数),type:graph,datasource:Prometheus,targets:[{expr:sum(rate(http_requests_total[1m])) by (path),legendFormat:{{path}}}]},{title:P99延迟,type:graph,datasource:Prometheus,targets:[{expr:histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, path)),legendFormat:{{path}} P99}]},{title:错误率,type:stat,datasource:Prometheus,targets:[{expr:sum(rate(http_requests_total{status\Internal Server Error\}[5m])) / sum(rate(http_requests_total[5m])) * 100}]},{title:活跃连接数,type:gauge,datasource:Prometheus,targets:[{expr:active_connections}]}],templating:{list:[{name:instance,type:query,datasource:Prometheus,query:label_values(up, instance)}]}}Prometheus的配置文件也要对应设置抓取规则。# prometheus.ymlglobal:scrape_interval:15sevaluation_interval:15sscrape_configs:# 采集Go服务指标-job_name:go-payment-servicestatic_configs:-targets:[localhost:8080]# 采集超时设置scrape_timeout:10s四、独家踩坑:Histogram bucket导致P99失真这个坑很隐蔽。上线后Grafana显示P99延迟200ms但用户反馈偶尔要等2秒。我以为是采样间隔的问题把scrape_interval从15秒改到5秒还是200ms。问题出在bucket定义。当时我用了默认的bucket配置。// 错误的bucket配置:默认bucket上限太小prometheus.HistogramOpts{Name:http_request_duration_seconds,// 默认bucket: 0.005, 0.01, 0.025, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5, 10// 看起来覆盖了0到10秒的范围Buckets:prometheus.DefBuckets,}看起来没问题对吧。但实际请求分布是这样的。99%的请求在200ms内完成0.9%在200-500ms之间0.1%在2秒左右。bucket的粒度在200ms到2秒之间太粗了。0.5秒和1秒之间没有任何分界点。当P99落在1秒到2.5秒这个区间时Prometheus只能用线性插值估算结果严重偏低。// 正确的bucket配置:根据业务SLA自定义prometheus.HistogramOpts{Name:http_request_duration_seconds,Help:HTTP请求延迟分布,// 根据业务场景定义bucket// SLA要求99%请求在500ms内// 在关键区间加密bucketBuckets:[]float64{0.005,0.01,0.025,0.05,0.1,0.15,0.2,0.25,0.3,0.4,0.5,0.75,1,1.5,2,3,5,10,},}修改bucket后在200ms到500ms之间加了多个分界点1秒到2秒之间也加了1.5秒这个点。P99从200ms变成了真实的480ms。和用户反馈的偶尔2秒对上了因为P99.9确实在2秒左右。bucket设计的原则。覆盖你的SLA目标值在SLA附近加密分桶。上限要覆盖最慢的请求。不要直接用DefBuckets每个服务的延迟特征不同bucket要定制。五、对比分析特性PrometheusInfluxDBOpenTSDBDatadog数据模型多维标签时间序列时间序列多维标签查询语言PromQLInfluxQL/FluxTSDB APIDatadogQL采集模式PullPushPushAgent Push集群支持联邦集群企业版原生支持云托管存储引擎TSDBTSMHBase专有部署方式自建自建或云自建SaaSGo生态官方库支持客户端库客户端库客户端库费用免费社区版免费免费按主机收费适用场景中大规模时序数据超大规模商业方案Prometheus是云原生监控的事实标准Go生态支持最好。InfluxDB适合IoT等高频时序数据。OpenTSDB适合超大规模但维护成本高。Datadog开箱即用但要花钱。总结与预告可观测性建设的核心三件事。定义好指标四种类型各司其职。Histogram的bucket要按业务SLA定制别用默认值。Grafana面板要覆盖QPS、延迟、错误率三大黄金指标。有了这些数据线上问题排查从猜变成看。下一篇讲Go性能分析利器pprof线上服务只在高峰期卡顿用pprof web在线采样定位瓶颈。
