Nginx开启的前提下:
Nginx 502就是后端对请求无法处理,
查看监控后端几个API的负载均很低,当前请求的QPS远远低于服务的上限。
一、(有可能是负载均衡问题导致服务器挂掉了)通过监控。查看QPS数量
而且同一瞬间,多套独立部署的API均处理不过来的概率也比较低。
我们简单做了个对比测试,分别对域名(请求走Nginx)与直接通过IP对内网一个API通过wrk进行小规模压测
直接通过域名走Nginx对API进行压测的话,QPS远远小于预期,并且存在大量失败请求。基本断定问题出在Nginx —> API 这条链路上。同时排除了后端服务响应不过来的可能性。网络问题可能性大一点。
二、对nginx转发和直接访问两种方式进行压测
一开始我们怀疑云服务商对内网带宽做了限制,我们观察内网带宽达到在200MB/S后就上不去了,所以我们在Nginx机器上ping后端服务,观察一段时间发现有小量抖动,但基本延迟正常。那云服务商对网络做限制的可能性就变小了很多。
三、怀疑nginx转发的带宽受到限制,用nginx来ping后端查看延迟
四、查看nginx错误日志
观察Nginx错误日志:
2021/09/26 14:23:00 [error] 4950#4950: *4162133210 no live upstreams while connecting to upstream, client: xxx.xxx.xxx.xxx, server: api.xx.xxxxxxx.cn, request: "POST /xx/xxxxxx/bidder HTTP/1.1", upstream: "http://xxxxxxxxxx/bidder", host: "api.xx.xxxxxxx.cn"
这里出现no live upstreams while connecting to upstream
, 也就说一瞬间Nginx检测不到任何存活的后端服务,而网络又没有大波动,那就可能是TCP链接出问题。打开Zabbix监控发现TCP连接数的确发生剧烈的波动现象。
五、锁定是TCP连接的问题
这时候问题很明显,Nginx->API这一链路存在大量的TCP链接被回收的情况,我们马上在API机器上查看链接状态
原因:
记一次生产环境Nginx间歇性502的事故分析过程 - 简书
但整个事故中,仍然存在几个疑点:
- 为什么Nginx转发的流量中,会混入1.0协议的请求呢?
- 是什么原因导致Nginx或Nginx所在服务器的操作系统在对TCP链接大量回收,并且把正常连接也回收掉导致后端Server "no live upstreams"了呢?
https://www.jianshu.com/p/0843be9d8d35