必须导入promhttp并用其Handler挂载/metrics，启动前显式注册指标（如http_requests_total）到DefaultRegisterer，避免手写响应、混用路由或中间件干扰。
如何用 Go 暴露标准 Prometheus 指标端点
Go 微服务要接入统一监控看板，第一步不是写 UI，而是让指标能被 Prometheus 抓取。核心是启用 promhttp 处理器并注册基础指标，而不是自己拼 HTTP 响应。
- 必须导入
github.com/prometheus/client_golang/prometheus/promhttp，直接用promhttp.Handler()作为 HTTP handler，不要手写text/plain响应体 - 在启动 HTTP server 前，调用
prometheus.MustRegister()注册自定义指标（如http_requests_total、service_up），否则抓不到数据 - 避免把指标 endpoint（如
/metrics）和业务路由混在一起——用独立的 mux 或单独的 server 监听，防止中间件干扰指标格式 - 若服务部署在 Kubernetes 中，确保 readiness probe 不检查
/metrics，否则可能因指标采集超时误判服务不可用
用 Go 实现服务健康状态上报（/health）与指标联动
/health 端点本身不产生 Prometheus 指标，但它的响应逻辑直接影响 service_up 这类布尔型指标的准确性。不能只返回 JSON，还要同步更新指标值。
- 在
/healthhandler 中，调用upGauge.Set(1)或upGauge.Set(0)显式设置指标，而不是依赖 exporter 自动推断 - 数据库连接、下游 RPC 超时等检查项，应封装为独立函数并返回 error；每个失败项触发对应指标（如
db_connected{service="user"} 0），而非只靠一个总开关 - 避免在
/health中做耗时操作（如查 Redis key TTL），超时会拖慢 Prometheus 抓取，建议缓存最近一次检查结果，用 goroutine 异步刷新 - 如果用
uber-go/zap打日志，健康检查失败时记录 level=error + error field，方便和指标告警对齐时间点
Go 中聚合多个微服务实例的指标（Service Discovery 场景）
Prometheus 本身负责拉取和聚合，Go 服务只需保证单实例指标格式合规。但常见误区是试图在 Go 层做跨实例汇总，这既没必要也容易出错。
- 每个 Go 实例暴露自己的
/metrics，Prometheus 配置static_configs或kubernetes_sd_config自动发现，聚合由 PromQL 完成（如sum(http_requests_total) by (service)） - 若需区分实例，必须在指标 label 中带上唯一标识：用环境变量注入
instance_id，或从 k8s downward API 取pod_name，不要用随机 UUID - 避免在 Go 代码里用
prometheus.NewCounterVec动态生成大量 label 组合（如按 user_id），会导致 cardinality 爆炸，Prometheus 内存飙升 - 服务重启后指标重置是正常行为，Prometheus 的
rate()函数能自动处理计数器翻转，无需在 Go 层持久化 counter 值
为什么 Go 的 pprof 端点不该暴露在生产 /metrics 下
/debug/pprof 和 /metrics 是两类完全不同的端点：前者用于性能诊断，后者用于长期监控。混用会导致安全风险和数据污染。
-
/debug/pprof必须绑定到独立监听地址（如localhost:6060），绝不能和对外服务端口共用，更不能加到 Prometheus scrape config 中 - 如果误将 pprof 页面返回的 HTML 当作指标抓取，Prometheus 会报
invalid metric name或expected float as value错误，日志里能看到类似text format parsing error in line 1: invalid metric name - 真正需要暴露的调试指标只有
go_goroutines、go_memstats_alloc_bytes这些已内置的 runtime 指标，它们默认就注册在prometheus.DefaultRegisterer里 - 想临时开启火焰图，应该用
curl http://localhost:6060/debug/pprof/profile?seconds=30单次采集，而不是长期开着 pprof web UI
服务状态监控看板的可靠性，不取决于前端图表多炫，而取决于每个 Go 实例暴露的指标是否稳定、label 是否一致、错误是否可追溯。最容易被忽略的是 label 设计——比如用 env=prod 而不是 environment=prod，会导致 PromQL 聚合失效；还有 metrics path 被反向代理 strip 掉导致 404，这些细节比写 dashboard 花的时间多得多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
