这篇文章主要讲解了“nginx大量502异常错误的排查过程”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“nginx大量502异常错误的排查过程”吧！
问题背景：118机器出现接口不通报警，一段时间后恢复
排查过程：
1、确认问题：nginx大量502异常，即nginx对应的后端服务可能处理很慢或者将请求丢弃了。
2、检查118机器的cpu，内存，网络等基础指标，发现eth0这段时间入口流量骤减，几乎为0，而且出问题的几天，时间吻合，其它指标正常，说明流量减少一定是问题的一个主要突破口。
3、eth0网络入口流量为0，有两种可能：1、网络问题导致机器不通；2、tomcat服务负载太高，导致新的socket请求连接被拒绝；
4、检查网络：发现本机的ping检测无丢包现象，另外，同个机房的其它机器也都没有丢包的情况，那么网络问题就可以被排除了。
5、tomcat问题：由于之前调整过acceptcount到10000（当连接数20000左右的时候，会导致队列中的请求等待的时间很长），第一反应是：这个时间段，肯定有一些请求导致tomcat的请求队列满了，导致请求在排队，从而时间比较长。其它请求由于队列已经满了于是被丢弃，tomcat则不会接受TCP连接，从而导致入口流量降低。于是，在tomcat的log中增加了请求时间%T，希望在出问题的时间段找出有请求时间很长的请求。
6、等待了一天。
7、观察昨天的数据：发现在相同的时间段，出现了很多简单的请求却需要花大概将近2分钟，而且很多花了将近1分钟，
分析的命令：sort -k11rg file.txt：简单解释：按照空格分割，分割后按照第11列的数据排序，-r是倒叙排序，-g是将字符串转成数值再排序
8、找到对应的请求地址，以及客户端，找到客户端对应的负责人，和其沟通发现：会在每天凌晨大批量调用这个接口导致。
感谢各位的阅读，以上就是“nginx大量502异常错误的排查过程”的内容了，经过本文的学习后，相信大家对nginx大量502异常错误的排查过程这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是亿速云，小编将为大家推送更多相关知识点的文章，欢迎关注！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
