如果这篇对你有帮助，还请麻烦转发。谢谢。
数据库的连接池的监控的重要性
假如，我们在公有云上存在一个数据库数据库实例X。公有云配置中已经说明X所支持的最大连接数是1000。
如果数据库X的实际连接数达到了1000，那么，新的连接就无法再与该数据库连接。
造成的直接问题是：某些应用可能无法写入或者读取数据。注意是“可能”。所以，这个“直接问题”非常的随机。
还没完。根据你的业务，你可能还会产生一系列连锁反应，比如：
1. 缓存与数据库数据不一致；
2. 应用线程数暴增；
3. 服务CPU使用率暴增。
连锁反应可能是爆炸式的，总的一句话：你根本不知道会发生什么。
所以，数据库的连接池的监控非常的重要。
常规方案
常规的监控方案是，当数据库实例的实际连接数到达800，并持续5分钟时，进行warning级别的通知。到达950，并持续1分钟时，进行critical级别的通知。
这个方案是可行的，但是不够好，因为当出现告警时：
1. 你无法根据这个告警通知，分析出是哪个应用发起的连接数过多导致的；
2. 事故可能已经发生了，我们希望更早的阶段知道，并且避免这个事故。
有没有更好的解决方案呢？
另类方案的思路
常规的监控方案还是必须要有的。因为那是针对的数据库实例本身的监控。
我们需要另一个方案进行补充，即标题所写：另类方案。
之所以另类，是因为在行业里，我还没有发现有人这么做的（所以也可能是我孤陋寡闻）。
思路如下：
存在一个数据库，它所支持的最大连接数是 S。
存在一个需要连接数据库的应用A，它配置了最小连接数为5。同时，A应用在环境中有10个实例。所以，A应用总共需要10 * 5=50个连接数。
我们只需要在配置编译打包pipeline过程中，进行判断 S > 50。这个判断我们称之为连接数配置合法性校验。
如果是false，那么整个pipeline failed。
另类方案的实现
思路是这样。但是如何实现呢？这取决于你的配置方案的实现。
如果配置存在CMDB中，应用也从CMDB中获取，那么，连接数配置合法性校验就实现在CMDB中。
如果配置被当成代码进行管理，那么，在配置代码被编译打包的阶段实现。
如果配置存放在基于自建的，界面（GUI）的配置管理系统中，那么，你就需要修改这个配置管理系统。
换一句话说：实现方案取决于配置的来源。
本文完。
往期好文推荐：
另类的思路CMDB建设思路
微服务架构下的配置治理模式
Everything as Code 并没有你想象中的那么美好
