APP提示网络连接错误问题排查

2020-09-29  本文已影响0人  ArthurIsUsed

问题

最近几天同事一直反馈,APP有时候会提示网络错误,请检查网络后重试

排查

一天后

相隔一天,同事反馈问题依旧,查看内存依然还有5G的剩余,判断不是内存问题,便排查nginx的错误日志。结果发现,关于app.kmb2b.com域名有比较多的报错。

2020/09/29 06:29:59 [error] 29862#0: *245179747 upstream prematurely closed connection while reading response header from upstream, client: 39.144.25.40, server: *.kmb2b.com, request: "POST /app/supplyRecommondList.action HTTP/1.1", upstream: "http://183.61.111.54:37580/app/supplyRecommondList.action", host: "app.kmb2b.com"

upstream prematurely......表示上游服务器过早关闭连接,上游服务器是有两个IP的37580端口作为负载均衡,日志内只发现54这个IP。由此判断就是这个183.61.111.54的37580端口过早关闭与该nginx的连接。

问题点,排查为何54这个IP会过早关闭连接

过早关闭连接的问题排查

采用tcpdump命令,抓对端IP为: 183.61.111.54, 端口为: 37850的流量

[root@izwz9d6vcg0qeb2kppr2udz pachong_log]#  tcpdump  tcp port 37580 and host 183.61.111.54 -w app_timeout.pcap

结果发现nginx向上游(183.61.111.54)建立三次握手,然后请求一个资源,上游发完资源后就立马断开连接了。

结合开发人员发的502状态码,请求只有72ms秒就返回了502,这个说明在nginx跟上游建立连接,还没完全断开,准备发送数据交互时,上游就自动断开连接。

修改上游nginx的upstream配置,修改前:

max_fails=10 fail_timeout=10s;
max_fails=10 fail_timeout=10s;

修改后:

max_fails=3 fail_timeout=300s;
max_fails=3 fail_timeout=300s;

表示nginx连接上游三次都失败,那么300秒内不会再建立连接,之后重新启用对该地址的监听。

再次观察日志,upstream prematurely closed....的报错少了很多,测试APP也都正常,目前算是稳定。

至于对比日志发现,54的IP数量是139的十几倍的问题,怀疑是QingCloud云平台中的监听器软件有问题。183.64.111.54的37580端口就对应一个监听器,监听的是中药城项目的内部nginx 80端口。而且之前也出现过监听器不生效的问题,删除重新添加恢复。

[root@izwz9d6vcg0qeb2kppr2udz nginx]#  cat error.log | grep "upstream prematurely closed" | grep ".kmb2b.com" > kmb2b_error.log
[root@izwz9d6vcg0qeb2kppr2udz nginx]# grep "111.54" kmb2b_error.log | wc -l
5363
[root@izwz9d6vcg0qeb2kppr2udz nginx]# grep ".139" kmb2b_error.log  | wc -l
317

现在暂时恢复,继续观察。若再出现,可抓139IP的包分析对比,并且重新添加监听器。

上一篇 下一篇

猜你喜欢

热点阅读