背景
生产环境API Gateway运行一段时间后，一般为48小时，监控模块产生jvm down的告警信息。
排查JVM Exporter
查看网关日志，发现日志输出正常。然后直接访问API Gateway所在机器的jvm监控exporter控制台发现：采集一次指标需要50秒左右的时间。prometheus配置的采集的超时时间为30秒，指标获取不到，触发jvm down告警。访问其他正常微服务所在机器上的exporter，采集指标很快，在秒级。怀疑是网关压力过大引起，我们先查询网关机器上的链接数。
查看连接数
netstat -tan|awk '$1~/tcp/{print $NF}'|sort|uniq -c|sort -nr
发现链接数不大，排除是由于压力过大引起。然后jps找到进程号。查看网关服务进程的句柄使用情况。
查看句柄数
lsof -p 6946 | wc -l
我们间隔2-3秒执行一次，发现句柄不释放，一直在大量增长。结合连接数数据来看，链接数一直没有大的增长，怀疑网关模块有句柄泄露问题。
查看句柄详细信息
ll /proc/6946/fd
发现有网关服务进程打开了大量的socket，超过70万，但是我们实际的连接数才700多。
结论&总结
到目前为止基本推断出：网关存在句柄泄露，建立的socket占用的句柄一直存在，没有释放。然后就是代码具体的定位问题了：目前还没找到很好的办法，直接定位到具体的原因。我们只能基于经验来进行推断，我们使用的Spring Boot 2.3.1，问题是出现在socket网络层面，与业务代码关联不大，先查看框架本身的问题：访问社区，很幸运找到了issue。最后将Spring Boot 2.3.1版本升级到Spring Boot 2.3.2问题解决。
https://github.com/spring-projects/spring-boot/issues/21934
1、问题排查是困难的
涉及的知识太多，而我们能获取的信息又太少。如果我能获取到句柄耗尽时候的异常信息，将会大大加速问题处理的速度。
2、需要完备的压力测试
上线前我们是做过压力测试的，包括测试环境也出现过句柄泄露的问题。当时只是简单的将句柄修改为百万而临时规避这个问题。
当然不是我负责的，对技术应该有敬畏心，羞耻心，上进心。
3、框架版本选择
版本的选择还是应该要深入的想一想，去除历史原因，我们应该选择个稳定的版本，尤其是小版本号，应该适当的大一些。
网友评论