Go Prometheus 指标设计：RED、USE 与自定义业务指标落地

很多 Go 服务只暴露 CPU 和内存，真正接口慢、错误率高、队列堆积时没有指标可看。可观测性要先从指标开始，把请求、资源和业务状态都变成可告警的数据。

解决方案思路

接口层用 RED：请求量、错误率、延迟分布；资源层用 USE：使用率、饱和度、错误；业务层只保留能指导决策的 Counter、Gauge、Histogram。标签必须控制基数，route 使用模板名，不直接放 user_id、order_id。

核心代码示例

requestDuration := prometheus.NewHistogramVec(
    prometheus.HistogramOpts{Name: "http_request_duration_seconds"},
    []string{"route", "method", "code"},
)
http.Handle("/metrics", promhttp.Handler())

运行逻辑

请求经过指标中间件时记录 route、status code 和耗时，Prometheus 定时抓取 /metrics，告警规则再根据错误率、P99 和饱和度触发通知。

重点观察指标

• http_request_duration_seconds P95/P99
• http_requests_total 错误率
• goroutines、heap、GC pause、队列长度和业务积压量

常见误区

• 标签基数过高压垮 Prometheus
• 只看平均值，不看分位数和错误率
• 业务指标没有 owner，告警触发后无人处理

参考方案

• Prometheus Go client
• runtime/metrics 官方文档

落地检查

• 字段、指标和 Span 名称要稳定，便于长期聚合。
• 上线前先在灰度环境验证采集成本和数据量。
• 告警必须能指向 owner、排查入口和回滚方案。