最近遇到一个突发问题：服务器没报警但是应用接口崩了…
为其他业务系统提供一个接口，平时好好的，突然就嚷嚷反馈说访问不了了，吓得我赶紧跳起来！
正常情况下在系统崩溃前，我会收到很多系统报警，但是这次它悄无声息的出问题，还是挺恐怖的
然后我立马看了下服务器的情况，服务器没有报警，也可以ping通，就是服务接口确实访问不了了
然后，还给我竖了个中指。。。。
好好好，现在都是这么折磨打工人的是吧。
随后我又看了下数据库的使用率，也没打满
然后随即查看对外提供接口的性能监控情况：除了9点15那会有点慢，其他一切正常，而且这个接口本身调用量不高的，系统完全可以hold住，为什么还是有问题？
于是怀疑是不是9点15那会接口慢了导致的。询问调用方之后，说超时连接时间设置的是5s。那这个接口完全可以在5s内返回。
随后我又找调用方拿到了这个日志信息：
RPC框架抛出异常cause: java.util.concurrent.RejectedExecutionException: Biz thread pool of provider has bean exhausted 它的意思是说线程池已经耗尽了，所以导致系统异常了。
目前系统最大设置的线程数量是300，我将配置提升到400，
随后对日志中这个关键词：Biz thread pool of provider has bean exhausted 做监控，之前都是系统CPU、TCP连接、内存、磁盘、以及方法调用时长以及可用率的报警，但是这些报警配置，没办法监控到此情况的发生。于是当系统报线程池满了之后，就需要赶紧调整下配置。
当然线程池的最大线程数也不是能无限增加的，这取决于系统负载能力。最大线程数越大，系统负载也会增大，数据库压力也会越大，如果慢sql较多，很可能数据库马上cpu就打满了，所以关键还是要从代码层面，解决一些长链接的慢sql，长事物。
具体可以参考下这篇：线程池队列已满时会发生什么？如何解决这个问题？
希望我的悲惨经历能给其他人排查问题带来一点思路吧…
