直接暴露 /metrics 接口仅是基础，生产环境必须显式绑定到实际路由复用器、避免高基数标签（如 user_id）、合理设置 Histogram 桶并确保 rate() 查询窗口大于抓取间隔，否则将引发查询超时、内存暴涨与分位数失真。
直接暴露 /metrics 接口就能被 Prometheus 抓取，但光有接口远远不够——指标设计不合理、标签爆炸、直方图桶设置失当，都会让 Grafana 面板卡顿、查询超时，甚至把 Prometheus 存储撑爆。
为什么 promhttp.Handler() 不能直接用在生产路由里
它默认只暴露内置运行时指标（go_goroutines、process_cpu_seconds_total 等），不包含任何业务逻辑；且它注册在全局 http.DefaultServeMux，一旦你的服务用了 gin、echo 或自定义 http.ServeMux，/metrics 就会 404。
- 必须显式将
promhttp.Handler()绑定到你实际使用的 multiplexer：比如r.Handle("/metrics", promhttp.Handler())（gin.Engine）或mux.Handle("/metrics", promhttp.Handler()) - 不要在中间件里调用
promhttp.Handler()—— 它不是中间件，是完整 handler，会直接写响应并结束请求 - 若启用了 HTTPS 或反向代理（如 Nginx），确认
X-Forwarded-For和 Host 头未被过滤，否则 Prometheus 抓取时可能因重定向失败
CounterVec 和 HistogramVec 的标签怎么设才不会崩
标签（label）是 Prometheus 的核心维度，但滥用会导致高基数（high cardinality）——每个唯一标签组合都生成独立时间序列，10 个用户 ID × 100 个路径 × 5 个状态 = 5000 条序列，一天就存数百万样本，Prometheus 内存和查询性能直线下降。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 禁止用动态值做标签：如
user_id、request_id、email—— 改用Gauge或日志关联 - 只保留强聚合维度：
method（GET/POST）、path（归一化为/api/v1/user/{id}而非带真实 ID 的路径）、status_code（200/404/500） -
HistogramVec的Buckets要贴合真实延迟分布：用预估 P99 值设上限，避免[0.01, 0.1, 1, 10, 100]这种跨三个数量级的桶——查rate(http_request_duration_seconds_sum[1m]) / rate(http_request_duration_seconds_count[1m])比直接看histogram_quantile更稳
Grafana 里写 rate() 为什么总是 0 或 NaN
rate() 是 PromQL 最易出错的函数之一，它依赖单调递增的计数器和足够长的查询窗口来拟合斜率。Golang 的 Counter 虽然保证递增，但以下情况仍会导致结果异常：
- 抓取间隔（
scrape_interval）大于rate()窗口：比如 Prometheus 配了scrape_interval: 30s，却在 Grafana 用rate(http_requests_total[10s])—— 至少需要 2 个样本点，10s 窗口大概率只拿到 0 或 1 个点 - 服务重启后计数器归零：Prometheus 自动处理重置（reset detection），但若你在代码里手动调用
Inc()前没检查是否已注册，或用了多个同名指标实例，就会触发误判 - 标签不匹配：
rate(http_requests_total{job="go-service"}[1m])中的{job="go-service"}必须和 Prometheusscrape_configs里定义的job_name严格一致，大小写、下划线都不能错
真正麻烦的不是写不出第一个面板，而是当请求量上万、延迟毛刺频发、标签维度交叉爆炸时，rate() 查询变慢、histogram_quantile() 返回空、Grafana 刷新卡住——这时候得回头砍标签、调桶、改抓取频率，而不是堆更多面板。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
