奇怪的接口请求失败问题排查

起因

程序组正在开晨会，项目经理突然跑过来十分慌张的说:APP挂了赶紧找人看一下，程序组立即开始排查问题，首先发现并不是所有人都用不了APP，顿时淡定了很多，然后发现是某个主页面接口返回报错导致APP不能使用，然后发现是某些用户才有这个现象，然后发现是关注的人比较多的用户才会接口报错（关注的人越多，该接口返回的数据量越大），然后发现同样的接口只有APP请求报错，web请求不会报错…然后发现问题复杂了，很有技术含量。

排查

作为一个处理网络问题经验老道的同学，第一反应就是先抓包看看呗，得到如下结果:

上图可以看出，接口请求的返回发生了乱序丢包，然后服务端主动断开了链接，于是确定了是丢包问题，10.73.15.46是我们的客户端机器，101.227.160.107是我们现网接入的TGW网关IP，于是问TGW的人，得到的结果是我们配置的是4层转发，TGW是透传的，TGW完美的把锅甩回给了我们，这里要简单介绍一下我们现网的架构了，TGW做对外网关，将请求转发给前端机器，前端机器使用nginx做反向代理，如果是后台请求再转发给后台机器，这里庆幸的是还好我们业务量不大~~前端只有4台机器，于是决定前端4台机器同时抓包，看看服务端的抓包情况。

服务端抓包时一开始就发现有一台机器不能将抓报数据写入本地文件（老司机看到这里基本不用看了），把能抓包的机器抓下来的包download下来分析，发现该接口所有请求都是返回成功了，这就不得不找个必现的人发请求试了，还好我们项目经理手机端必现，然后发现居然抓不到他发的包，于是再看了下后台的nginx日志，发现项目经理的请求都是那台抓不到包的有问题的机器转发过来的，这下问题就清晰了，然后该机器上执行df -h，磁盘空间100%…

处理及原因分析

首先是把该机器从TGW下线，项目经理的手机访问立马正常了，问题解决；然后是找锅，理论上公司现网的磁盘空间是有告警的，然而并没有人处理，估计是设置了告警屏蔽之类的问题；再然后就是为啥磁盘空间满了会导致接口请求也有问题了，这里问题可能会有很多方便，从这个现象上来看我猜测是因为nginx做反向代理时上游返回的数据量较大时会落地磁盘，之前看过nginx的源码，有看到这一块，和我们现网的现象很符合，但是我们前端的nginx日志是关闭的，这里我并不知道怎么验证。

总结

有些一开始看起来很高深的问题，最后往往是低级运维事故-_-