生产经过nginx转发后交易超时问题分析解决
  skA6WysNXsa9 2023年11月09日 28 0

问题现象:

一个客户的生产环境中,由于灾备切换,将原有环境切换到灾备环境后出现了问题,在通过走nginx转发链路触发保存pdf的交易过程,会存在2分钟以上的等待时间,但是直接访问后端服务器地址,不会有耗时的问题,但是目前由于网络限制,业务无法直接访问服务机器,只有运维可以在内网直接操作验证,影响业务交易;

问题分析:

  1. 首先通过问题的现象分析,通过直接访问后端服务的情况可以正常执行,但是通过nginx跳转到服务的情况无法成功,所以问题一定是与访问链路因素有关,但具体影响在什么地方,需要我们通过细节进行分析;

生产经过nginx转发后交易超时问题分析解决_nginx

异常链路表示

2.目前对于问题链路中,需要分析的点有两个,一个是nginx是否存在转发过程中的异常,另一个是服务本身自己存在异常,在生产环境中,无法根据日志或者debug进行定位的前提下,我们这里提供一个工具,在linux系统层面可以使用strace来跟踪系统调用,在java应用层可以用jstack或者arthas监控缓慢点;

3.首先通过strace对nginx进行系统调用的跟踪,由于nginx是多进程服务,需要找出每个进程ID 命令如: ps -ef | grep nginx 找到nginx worker进程 ,然后每个进程都进行strace ,命令如: strace -v -tt -T -p 每个nginx进程ID > 进程ID.log 2>&1 ,在进行交易操作,根据获得的跟踪系统系统调用分析如下:

生产经过nginx转发后交易超时问题分析解决_链路_02

ng收到浏览器请求

生产经过nginx转发后交易超时问题分析解决_链路_03

ng转发请求到业务

生产经过nginx转发后交易超时问题分析解决_nginx_04

ng转发的业务socket信息

处理进程在收到浏览器请求调用recvfrom(读与浏览器套接字的请求信息)到转发给服务调用writev(写与服务套接字的转发请求信息)的过程在nginx中几乎没有时间的损耗;所以nginx的怀疑点解除;

4.开始分析应用服务的阻塞点,对于一个交易存在2分钟的耗时,一定是在某个慢调用上有等待操作,所以对于通过tomcat部署的java程序,自然会想到使用jstack去抓下线程的方法栈调用链,来分析阻塞的方法是什么,但是由于客户现场环境问题和用户问题,运维没能正确使用jstack来抓到快照,反馈说无法执行,这就浪费了一个很大的工具优势,只能想其他办法;

5.在分析应用是否慢之前,还考虑对nginx到应用的网络节点中是否有慢的地方进行了分析,需要证明请求到达应用机器后,返回这段时间的损耗都是消耗在业务应用机器中,使用了tcpdump进行抓包分析,工具命令: tcpdump -i 网卡名称 port 8080 -w 8080.pcap ;

生产经过nginx转发后交易超时问题分析解决_直接访问_05

访问正常机器的抓包

生产经过nginx转发后交易超时问题分析解决_链路_06

访问异常机器的抓包

经过对两个不同网络链路分析,正常直接访问服务的44机器,耗时在1秒多正常返回,经过nginx转发到45的访问,耗时确实2分钟左右,所以证明就是在业务机器中存在的时间损耗;

6.由于客户运维不能正常使用jstack抓取快照,只能还使用strace进行跟踪,因为对于此类异常,如果在慢调用中存在时间损耗,通常多是和系统调用资源访问条件不满足时等待有关,所以通过strace应该可以发现一些线索,所以工具命令执行 strace -v -tt -T -F -p tomcat进程ID > 进程ID.log 2>& ;

生产经过nginx转发后交易超时问题分析解决_nginx_07

tomcat进行strace跟踪比对

经过抓取tomcat中线程的系统调用,将44和45两台机器的访问链路进行比对,发现一个奇怪的问题,直接访问44的业务应用有反向请求45自己服务的情况,应该是业务层有自身发起交易联动的,但是45机器的业务却是去访问了128(是ngin机器地址),所以问题的差别就是,45存在联动访问请求nginx现象,可能这过程有时间损耗,但是具体不明确为什么会请求128nginx而不去请求45,所以在测试环境进行验证进行抓包如下:

生产经过nginx转发后交易超时问题分析解决_直接访问_08

测试环境验证业务方向请求ng的抓包

发现在测试环境也存在这个现象,通过nginx转发的链路,确实会有从业务服务反向请求到nginx再回到业务的路由链路,但是这个过程在生产就从来没有抓到过这个反向请求出来,所以断定,可能是生产环境中,45机器到nginx的网络策略存在问题,只有ng->45的,没有45->ng的;

生产经过nginx转发后交易超时问题分析解决_nginx_09

7.目前问题就比较清楚了,怎么验证45->ng的网络策略存在问题呢?这就比较简答了,通过curl命令,去执行那个访问ng的get请求,看结果是不是也存在阻塞就可以了,客户通过验证后,确实存在不通的现象,所以问题基本明确,就是生产环境的网络策略导致交易链路中的一个环节不通,所以阻塞到一个网络超时就中断了;

8.以上问题分析,我们使用到了linux的strace跟踪工具(早期的aix或unix是truss),以及网络抓包工具tcpdump,具体这些工具的使用和抓取信息的详细说明,后续我还可以针对这些数据的如何查看进行分享;

【版权声明】本文内容来自摩杜云社区用户原创、第三方投稿、转载,内容版权归原作者所有。本网站的目的在于传递更多信息,不拥有版权,亦不承担相应法律责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@moduyun.com

  1. 分享:
最后一次编辑于 2023年11月09日 0

暂无评论

推荐阅读
skA6WysNXsa9