本文介绍: 客户端请求后端服务时一直报错查看后端的服务是正常启动的。后来又查看Nginx错误日志发现请求后端接口时Nginx报错查看错误解释可以得到的结果upstream没有可以提供服务server,即Nginx已经发现不了存活的后端了,但是,我直接访问后端的server却是可以使用的,证明server端可用。最后查找文档,发现问题出现在业务上要求保持会话,但是Nginx到后端并没有保持会话,那么,Nginx当然就找不到后端可用服务,就会报。

1、问题描述

生产环境Nginx间歇性502的事故分析过程

客户端请求后端服务时一直报错 502 bad gateway查看后端的服务是正常启动的。后来又查看Nginx的错误日志发现请求后端接口时Nginx报错no live upstreams while connecting to upstream,查看该错误解释可以得到的结果upstream中没有可以提供服务server,即Nginx已经发现不了存活的后端了,但是,我直接访问后端的server却是可以使用的,证明server端可用。
最后查找文档,发现问题出现在业务上要求保持会话,但是Nginx到后端并没有保持会话,那么,Nginx当然就找不到后端可用服务,就会报no live upstream

参考文档https://xiezefan.me/2017/09/27/nginx-502-bug-trace/

2、服务架构如下:

+--------+  HTTP   +-------+  HTTP   +-------+
| Client | ------> |       | ------> | API A |
+--------+         |       |         +-------+
                   |       |  HTTP   +-------+
                   |       | ------> | API B |
                   |       |         +-------+
                   |       |  HTTP   +-------+
                   | Nginx | ------> | API C |
                   |       |  HTTP   +-------+
                   |       | ------> | API D |
                   |       |  HTTP   +-------+
                   |       | ------> | API E |
                   |       |  HTTP   +-------+
                   |       | ------> | API F |
                   +-------+         +-------+

3、排查思路

一般讲,Nginx 502就是后端处理不过来,但查看监控后端几个API的负载均很低,当前请求的QPS远远低于服务的上限。而且同一瞬间多套独立部署的API均处理不过来的概率比较低。

我们简单做了个对比测试,分别对域名(请求走Nginx)与直接通过IP对内网一个API通过进行小规模压测

对比测试发现,直接通过域名走Nginx对API进行压测的话,QPS远远小于预期,并且存在大量失败请求。基本断定问题出在Nginx —> API 这条链路上。同时排除了后端服务响应不过来的可能性。网络问题可能性大一点。

一开始我们怀疑云服务商内网带宽做了限制,我们观察内网带宽达到在200MB/S后就上不去了,所以我们在Nginx机器ping后端服务,观察一段时间现有小量抖动,但基本延迟正常。那云服务商网络做限制的可能性就变小了很多。

我们观察Nginx错误日志:

2023/08/26 14:23:00 [error] 5950#5950: *5172133211 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机器上查看链接状态

shell > netstat -n | awk '/^tcp/ {++state[$NF]} END {for(key in state) print key,"t",state[key]}'
SYN_RECV 	 1
ESTABLISHED 	 656
FIN_WAIT1 	 4
TIME_WAIT 	 153429

TIME_WAIT特别的多,大量的连接被API侧主动关闭了。这说明Nginx->API这一步请求并没有Keep-Alive,我们检查Nginx,确定是配置了Keep-Alive

4、解决办法

修改nginx的配置

  location ^~ /xxxxxx/ {
    ...
    proxy_http_version 1.1;
    proxy_set_header Connection "";     //规制强制指定使用1.1协议
    ...
}

原文地址:https://blog.csdn.net/wts563540/article/details/132345591

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任

如若转载,请注明出处:http://www.7code.cn/show_33306.html

如若内容造成侵权/违法违规/事实不符,请联系代码007邮箱suwngjj01@126.com进行投诉反馈,一经查实,立即删除

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注