公司内部系统早上九点突然卡顿，用户登录要等十几秒。运维老张一查日志，数据库连接超时，再一看连接池监控——活跃连接数早就飙到上限，可没人收到告警。这种事在日常维护中太常见了。
连接池不是设完就没事了
很多项目上线时配置了 HikariCP 或 Druid 连接池，参数一填，测试通过就交付。但业务量上来后，数据库连接成了瓶颈。连接池就像餐厅的餐桌，来吃饭的人（请求）多了，桌不够用，客人就得排队。监控指标就是告诉你现在有多少人等着吃饭、有多少桌空着、有没有人吃完不走。
关键指标得盯着看
活跃连接数是最直观的一个。如果它长期接近最大连接数，说明池子快满了，新请求只能等。这时候要么优化 SQL 减少占用时间，要么考虑扩容。
空闲连接数也不能忽视。如果这个值一直很低甚至为零，说明连接用完就没还回来，可能是代码里没正确关闭连接，或者事务拖得太久。
等待线程数更危险。当没有可用连接时，新请求会进入等待队列。这个数值大于零，说明已经有请求开始排队了。如果持续增长，系统响应就会明显变慢。
连接获取超时次数是事后记录。一旦出现这个计数增加，意味着有请求因为拿不到连接直接失败了。这时候用户可能已经看到报错页面了。
怎么把指标加进去
以 Spring Boot 集成 HikariCP 为例，加上 micrometer 后可以直接暴露连接池状态：
management.endpoints.web.exposure.include=health,metrics
management.endpoint.metrics.enabled=true然后通过 /actuator/metrics/hikaricp.connections.active 这类接口就能拿到实时数据。配合 Prometheus + Grafana，画个面板贴在办公室大屏上，谁都能一眼看出问题。
别只看数字，要看趋势
某天下午三点，活跃连接从平时的 20 跳到 80，但没超限。看起来还能接受？可结合业务一查，是某个定时任务拉了全表数据，占着连接不放。虽然没炸，但隐患就在那里。定期翻翻图表，比等到出事再救火强得多。
连接池监控不是高级功能，而是基础保障。就像家里的水电气表，平时没人注意，可一旦漏了、爆了，才知道早该装个报警器。