Golang怎么实现自定义指标采集_Golang如何用Prometheus的Histogram统计请求延时分布【进阶】-Golang-PHP中文网

必须显式指定Buckets，否则所有观测值落入+Inf桶导致分布图失真；需按真实延时范围配置，避免默认值；业务耗时应排除中间件开销；推荐用HistogramVec按method/path/status等维度统计，禁用动态path防基数爆炸。

golang怎么实现自定义指标采集_golang如何用prometheus的histogram统计请求延时分布【进阶】

不设 Buckets，Histogram 就不会分桶统计，所有观测值全塞进 +Inf 桶，查出来的分布图是一条竖线。Golang 的 prometheus.HistogramOpts 要求你显式传入 Buckets 字段，空切片或 nil 都会 panic。

Buckets 应覆盖真实延时范围：比如 HTTP 请求常见是 []float64{0.005, 0.01, 0.025, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5, 10}（单位秒）
别直接抄默认 DefBuckets（0.005~10 秒），它不适合高并发低延时服务（如内部 RPC 延时多在毫秒级）
如果延时偶尔毛刺到 30s，但 99% 在 200ms 内，把 10 改成 30 会稀释精度；更稳妥的是加一个 30 桶，保留原有密集区间

很多人直接在 handler 入口打点，结果把日志、鉴权、反序列化等中间件耗时也计入「业务延时」，导致 P99 看着很高，实际业务逻辑只占 1/3。Prometheus 的 histogram 不支持嵌套观测，得靠代码位置控制。

在 handler 最内层业务逻辑执行前后取 time.Now()，而不是整个 http.HandlerFunc 包裹
避免用 defer 记录（如 defer hist.Observe(time.Since(start).Seconds())），因为 defer 执行在函数 return 后，可能错过 panic 捕获或 context cancel 后的提前退出
如果用了 Gin/Echo，务必在自定义中间件里区分「框架层耗时」和「用户 handler 耗时」，不要复用同一个 histogram

同一指标名被注册两次，MustRegister 会 panic 并输出类似 duplicate metrics collector registration attempted，但不告诉你哪个包、哪行代码重复了。尤其在多个 package 都 init 自己的 metrics 时极易中招。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

改用 prometheus.Register + 显式错误处理，打印调用栈：if err := prometheus.Register(hist); err != nil { log.Printf("failed to register histogram: %v", err) }
全局指标建议统一放在 metrics/ 包里集中初始化，其他模块只通过函数获取已注册的 prometheus.Histogram 实例
测试时用 prometheus.Unregister 清理，但注意它不保证 goroutine 安全，别在采集期间调用

想按 path、method、status_code 分维度看延时？别手写 map 存一堆 histogram 实例——内存泄漏+竞态风险高。官方 Vec 类型才是正解，但它要求你在 Observe 前就确定所有 label 值。

声明：httpReqDurHist = prometheus.NewHistogramVec(prometheus.HistogramOpts{...}, []string{"method", "path", "status"})
使用：httpReqDurHist.WithLabelValues(r.Method, r.URL.Path, strconv.Itoa(status)).Observe(d.Seconds())
注意 WithLabelValues 参数顺序必须和 []string 定义一致，错位不会报错，但指标名拼错，查不到数据
避免用动态 path（如 /user/123）做 label，会导致 cardinality 爆炸；应预定义路由模板（如 /user/{id}）并在中间件里提取

Golang 的 histogram 本身不保存历史，所有聚合计算都在 Prometheus server 端完成；但如果你漏掉了 bucket 划分、label 控制或注册时机，server 拿到的就是残缺甚至错误的原始样本。这些地方没对齐，再好的 PromQL 也画不出真实分布。