Go mod 好菜系列 - 0x0F prometheus/client_golang 这口指标菜该怎么摆上桌

当项目开始上线、有人开始盯服务状态时，你会发现光有日志是不够的。日志适合查具体问题，但它不擅长回答“整体现在怎么样”。这时候监控指标就来了，而在 Go 生态里，prometheus/client_golang 是非常常见的一口菜。

它解决的不是日志问题，而是观测问题

比如这些问题，日志不太好直接回答：

• 接口每分钟多少请求
• 错误率是不是在升高
• 耗时分布是否变差
• 队列堆积是不是越来越多

这些更适合交给指标系统，而不是靠人翻日志拼图。

最常见的三类指标先分清

• Counter：只增不减，适合总次数
• Gauge：可升可降，适合当前值
• Histogram：适合延迟、大小这类分布统计

这三类一旦分不清，后面你写指标时就很容易“虽然看起来有数据，但完全不回答问题”。

Counter 的典型例子

var httpRequests = prometheus.NewCounterVec(
    prometheus.CounterOpts{
        Name: "http_requests_total",
        Help: "Total number of HTTP requests",
    },
    []string{"path", "method", "status"},
)

httpRequests.WithLabelValues("/users", "GET", "200").Inc()

这类指标很适合看总量、错误量、命中次数之类的趋势。

Gauge 的典型例子

var queueSize = prometheus.NewGauge(
    prometheus.GaugeOpts{
        Name: "queue_size",
        Help: "Current queue size",
    },
)

它更适合“当前有多少”的场景，比如队列长度、在线连接数、当前协程数等。

Histogram 是接口监控的常见主力

var httpDuration = prometheus.NewHistogramVec(
    prometheus.HistogramOpts{
        Name:    "http_request_duration_seconds",
        Help:    "HTTP request latency",
        Buckets: prometheus.DefBuckets,
    },
    []string{"path", "method"},
)

start := time.Now()
// handle request
httpDuration.WithLabelValues("/users", "GET").Observe(time.Since(start).Seconds())

这类指标的价值在于：你不只是知道请求花了多久，而是知道“快的有多少、慢的有多少、慢到了什么区间”。

接入 HTTP 暴露端点

http.Handle("/metrics", promhttp.Handler())

这一步会把指标暴露出来，交给 Prometheus 去抓取。也就是说，这个库本身只负责“把数据准备好”，真正的监控平台和告警逻辑是在外面那一层。

指标设计别一上来就标签爆炸

这是很常见的坑。很多人一开始会想：多打点标签，信息不就更全了吗？结果最后 cardinality 爆炸，监控系统本身先吃不消。

比如用户 id、请求参数、订单号，这些高基数标签就很危险。指标是宏观观测工具，不是把日志字段直接搬进来。

小结

prometheus/client_golang 这道菜很适合成熟一点的服务项目：

• 它解决的是指标观测，不是日志记录
• Counter、Gauge、Histogram 要分场景用
• 接口耗时和错误率非常值得做成指标
• 标签设计要克制，不要把监控做成高基数地雷

下一篇我们补 casbin。有了 JWT 只是知道“你是谁”，权限细则这件事，通常还得靠另一个层次的工具来扛。