Go HTTP服务暴露Prometheus指标应直接用promhttp.Handler()注册/metrics端点，避免手写逻辑；需绑定0.0.0.0监听、禁用metrics路径中间件，并按SLA自定义histogram桶以提升P99精度。
Go HTTP 服务怎么暴露 Prometheus 指标端点
直接在 http.ServeMux 里注册 /metrics 就行，别自己手写指标收集逻辑。用官方推荐的 promhttp.Handler()，它自动处理 Content-Type、gzip、HEAD 请求和错误响应。
常见错误是把指标 handler 和业务路由混在一起，比如用 http.HandleFunc("/metrics", ...) 自己实现，结果漏掉缓存头或不支持 gzip，导致 Grafana 抓不到数据或超时。
- 必须用
promhttp.Handler()，不是promhttp.HandlerFor()（后者要自己传 registry，新手容易传错） - 端点路径固定为
/metrics，Prometheus 默认只 scrape 这个路径，改了要同步调scrape_configs - 不要在
/metrics前加中间件（如 JWT 验证），Prometheus client 不带 Authorization header - 示例：
http.Handle("/metrics", promhttp.Handler())
哪些 Go HTTP 指标真正有用，哪些该关掉
默认注册的 promhttp.DefaultGatherer 会暴露 Go 运行时指标（go_goroutines、go_memstats_alloc_bytes 等），这些有用；但 http_* 默认指标是空的——因为 net/http 不自动打点，得自己加中间件。
别一上来就 promauto.NewCounterVec 埋一堆请求计数器，先盯住三个核心维度：请求量、延迟、错误率。其余像按 path、method、status 分桶的指标，等压测时发现瓶颈再开，否则 cardinality 爆炸，Prometheus 内存飙升。
立即学习“go语言免费学习笔记（深入）”；
- 必开：
http_request_duration_seconds_bucket（用promhttp.InstrumentRoundTripperDuration或gorilla/mux的 middleware） - 必开：
http_requests_total（按 status code 分组，{code="200"}、{code="500"}） - 慎开：
http_request_size_bytes和http_response_size_bytes，除非真要分析 payload 趋势，否则浪费存储 - runtime 指标不用动，
prometheus.MustRegister(prometheus.NewGoCollector())已包含
Grafana 里查 Go API 延迟，为什么 P99 总是不准
根本原因是 Prometheus 的 histogram_quantile() 函数依赖直方图桶（bucket）分布，而 Go 默认的 promhttp 中间件用的是固定桶（0.001, 0.002, 0.004...），对长尾延迟不敏感。比如你 API 大部分请求 50ms，但有少量 2s 超时，P99 就卡在 1s 桶里，实际值被抹平。
解决办法不是换 Summary，而是重定义 bucket 边界，让高延迟段分辨率更高。别照抄文档里的指数桶，按你 SLA 调整：如果 SLO 是 200ms，桶就设成 []float64{0.05, 0.1, 0.2, 0.5, 1.0, 2.0}。
- 用
promhttp.InstrumentHandlerDuration时传自定义prometheus.HistogramOpts.Buckets - 避免用
time.Since()手动打点再塞进 histogram，精度不如中间件原生 hook - Grafana 查询写法：
histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[1h])) by (le, handler))
- 注意：rate() 时间窗口至少 2 倍于 scrape interval，否则 rate 计算为空
生产环境部署时，Prometheus 抓不到 Go 服务的 /metrics
最常见原因是容器网络不通或服务没监听 0.0.0.0。Go 默认 http.ListenAndServe(":8080", nil) 绑定 localhost，K8s Pod 内其他容器（比如 Prometheus sidecar）根本连不上。
另一个隐形坑是 readiness probe 和 metrics 端点共用一个端口又没隔离健康检查逻辑，导致 /metrics 返回 503（因为后端还没 ready），Prometheus 就标记 target down。
- 启动时明确绑定
":8080"，不是"localhost:8080"或"127.0.0.1:8080" - K8s Service 的
targetPort必须和 Go listen 的端口一致，别写错成 8081 - 用
curl -v http://在集群内实测，别只看本地 curl localhost:8080/metrics - 如果用了 Istio，确认 mTLS 没拦截
/metrics，可加 destination rule 白名单
指标采集链路越长，丢数据的环节越多：Go runtime 指标是内存快照，HTTP 指标靠中间件采样，Prometheus 抓取靠定时轮询，Grafana 查询又做二次聚合。任何一个环节的配置偏差，都会让 P99 或错误率看起来“不对”。盯住 scrape duration、target up 状态、histogram bucket count 这三个基础信号，比调 fancy 的 dashboard 更管用。
