记录一次线上排除故障的经历

记录一次线上排除故障的经历

这篇博客是用来记录一次紧急线上排除故障的经历，仅供参考使用。

时间发生在2021年3月的某一天，我还记得那天是一个阴天，我正在乘坐地铁前往公司，但是在8点31分左右，手机上打来了一个电话，是和我对接客户打来的，大意现在系统出现了网络不稳定，出现了许多业务响应时间过长，刷新偏慢的问题。于是，打算9点上班排查一下问题。此时，我还不知道这个非常紧急，因为此时业务还是能正常使用的，就是比较慢。

但是， 当第二个电话打来的时候，我不淡定了，窗口服务停止，此时我看了手机8点46分，于是开始在前往公司的路上进行狂奔，于是在8点54分到达了公司，开始排查问题。在整个排查中间，客户以3分钟一次电话微信，电话的方式催促我们技术支持方。

首先，我们排查该Java程序是否启动，发现几台生产环境服务器都在启动，于是开始查看日志文件。

查看日志得知，在负载均衡下，一台机子S1在前一天23点56分31秒 出现宕机的现象，服务没有停止但是已经僵死，于是所有的服务请求在负载均衡的作用下转移至另一台机器S2，但是由于早上流量太大，导致了上午8点29分S2也出现了服务不稳定，长时间响应的问题，于是在，由于处理总业务的两台服务器S1宕机和S2不稳定于是服务开始出现问题，这时候其他的业务C1和C2服务器，P1和P2服务器，D1服务器，Pos1、Pos2、Pos3服务器等等（还有很多服务器这里就不详细阐述了），其他服务器连接至总的S2服务器所构成的负载均衡很不稳定。

仔细看日志发现一条错误，如图：

看到这里，大家知道出现锁的问题，仔细查看之后，是由于一个服务器长时间执行某一个操作，但是由于不知道为什么没有释放锁，导致其他集群进不到这个服务器S1上。

于是我们进行了重新启动但是没有成功，总是在进行生成entity的时候，system shutdown，于是我们查看负载，排除了OOM的原因，此时，一个同事说，会不会是磁盘空间满了，于是我们df -h进行了空间的查看，果然， 使用率 100% ,于是我们紧急转移部分日志文件（kite和catalina日志文件），腾出了2G空间，然后重启服务器，目的是想先让服务起来，至于是清理也好，还是扩容，挂载磁盘也好，都可以日后商量，此时是9点07分。

但是事与愿违，启动S1服务器，还是报错了，但是很奇怪的是UTF-8编码的错误

看到这个，我们第一想到的是，配置文件应该有编码问题，但是一个疑惑出现了，因为是负载均衡，我们的程序会部署至两个服务器上，而且都是一样的代码，那么为什么S2没问题，S1有问题？为什么之前部署升级的时候没有出现这个问题？虽然心中有疑惑但我们还是紧急备份了该项目所有文件，当然包括配置文件。

然后开始观察比较两个服务器S1和S2上配置文件，检查一遍配置文件之后，发现S1的hbm文件出现问题，因为该文件涉及表结构和初始配置，所以才会在启动的时候出现问题，于是将另一台服务器上的hbm文件复制过来，然后启动，之后线上服务器就启动起来了。

总结

1.需要有一个良好的服务器维护管理机制，每周对某一个项目进行运行情况的查看和维护，如果有相关问题，就像这次磁盘占用满了，当磁盘达到70%的时候，就应该要联系技术人员进行磁盘的清理、扩容或者挂载
2.还需要定位为什么配置文件不一样的问题，这个还在讨论中。