如何监控Golang数据库连接池及导出DBStats指标？

本文共计792个文字，预计阅读时间需要4分钟。

sqlDB.Stats() 返回的是 sql.DBStats 结构体，它反映了连接池当前的实时快照，而不是历史累计值。

关键字段包括：

导出 DBStats 到 Prometheus 的常见错误

直接在 HTTP handler 里调用 db.Stats() 并返回指标，容易踩两个坑：一是没加锁（Stats() 内部是原子读，安全）；二是误把瞬时值当速率用，比如对 WaitCount 做 rate() 计算——这是错的，WaitCount 是单调递增计数器，Prometheus 客户端应使用 prometheus.NewCounterFunc 包装，而不是 Gauge。

• 用 prometheus.NewCounterFunc 暴露 WaitCount 和 MaxOpenConnections 这类只增或固定值
• 用 prometheus.NewGaugeFunc 暴露 OpenConnections、InUse、Idle 这类可升可降的瞬时状态
• 避免每秒调用 db.Stats() 多次——它轻量，但高频采集无意义；10s 间隔足够

为什么 MaxIdleConns 设太小会导致 WaitCount 突增

MaxIdleConns 控制空闲连接上限，但它和连接复用效率强相关。如果设为 0 或过小（如 2），高并发下空闲连接很快被回收，新请求只能新建连接或排队等——哪怕 MaxOpenConnections 还有余量，只要没有空闲连接可用，就会触发等待逻辑，WaitCount 就会涨。典型现象是 p95 延迟毛刺 + WaitDuration 上升。

• 生产建议：设 MaxIdleConns == MaxOpenConnections，除非你明确要限制空闲资源
• 注意 SetConnMaxLifetime 和 SetConnMaxIdleTime 会主动 kill 连接，可能加剧空闲连接流失
• 验证方式：压测时观察 Idle 是否长期趋近于 0，同时 WaitCount 持续增加

DBStats 不显示连接泄漏，但能帮你定位

db.Stats() 本身不报错，也不告警，但它暴露的几个数字组合起来就是泄漏信号：InUse 持续增长不回落、Idle 趋近于 0、OpenConnections 逼近 MaxOpenConnections —— 这大概率说明有 *sql.Rows 没 Close，或事务没 Commit/Rollback。尤其注意 Rows.Close() 必须显式调用，defer 不可靠（比如函数提前 return）。

立即学习“go语言免费学习笔记（深入）”；

• 临时诊断：在 panic hook 或健康检查 endpoint 打印 db.Stats()，看是否随请求累积上涨
• 更准的方式：结合 runtime.SetFinalizer 给 *sql.Rows 加日志（仅开发环境），或用 go tool trace 抓 goroutine 阻塞点
• 别依赖 MaxLifetime 当兜底——它只管连接年龄，不管业务逻辑是否卡住连接

监控不是贴个 metrics endpoint 就完事；真正难的是把 InUse 和业务路径对上，搞清哪个接口、哪段 SQL、哪种参数组合在持续 hold 住连接。