Go 并发治理监控：只看 QPS 远远不够

并发治理不是改完代码就结束。你需要知道限流有没有生效、连接池是否排队、goroutine 是否回落、降级是否频繁发生。监控指标是治理闭环。

入口指标

QPS、错误率、P95/P99、429 数量和请求超时数量能说明用户侧压力和体验。限流后要看错误率是否从 5xx 转为可解释的 429。

内部资源指标

goroutine 数、队列长度、worker 忙闲、DBStats、HTTP 连接池和缓存回源次数能说明压力在哪里累积。

治理动作指标

singleflight shared 次数、fallback 次数、重试次数、context timeout 次数都应该可见。否则你无法判断策略是否真的工作。

生产场景

适用于已经引入限流、队列、singleflight、连接池和降级的服务。治理动作越多，越需要指标确认它们真的在保护系统。

关键指标

• 入口 QPS、错误率、P95/P99 和 429
• goroutine、队列、DBStats、HTTP 连接池和缓存回源
• 重试、降级、限流、singleflight shared 与 context timeout

常见误区

• 指标标签使用用户 ID 或请求 ID 造成高基数
• 只看业务 QPS，不看内部资源
• 没有把指标和发布版本、依赖名关联

落地建议

建议按入口、内部队列、下游依赖、治理动作四层组织仪表盘。每个报警都要能指向处理动作，例如扩容、降级、限流调参或回滚。

代码示例

var queueLength = prometheus.NewGauge(prometheus.GaugeOpts{
    Name: "worker_queue_length",
    Help: "Current worker queue length.",
})

queueLength.Set(float64(len(jobs)))

上线检查

• 每个治理动作都有指标。
• 指标标签不要过高基数。
• 仪表盘能从入口一路看到下游资源。