深入分析nginx偶尔502错误根因-以及常见错误总结

以架构师的能力标准去分析每个问题，过后由表及里分析问题的本质，复盘总结经验，并把总结内容记录下来。当你解决各种各样的问题，也就积累了丰富的解决问题的经验，解决问题的能力也将自然得到极大的提升。励志做架构师的撸码人，认知很重要。

本文主要想表达的是解决问题的态度。

一、问题和目的

1、问题现象：

接入层nginx集群某个接口偶尔出现502，但是业务nginx没有看到502日志，业务服务端口正常。

2、本次总结的目的：积累沉淀

1)、知识学习路径：

1、最好的学习，实现90%的知识转化，分享是最好的方式。

2、知识输出：把知识内化为自己的智慧。

3、把智慧升华为世界观和方法论。

2)、不要轻视任何小问题，追根溯源问题的本质，才积累丰富的解决问题的经验。

首先需要了解nginx运行原理。Nginx工作原理和优化总结。_nginx原理-CSDN博客

nginx的健康检查机制：Nginx健康检查机制-CSDN博客

海恩法则

· 事故的发生是量的积累的结果。
· 再好的技术、再完美的规章，在实际操作层面也无法取代人自身的素质和责任心。

薛定谔的猫

“薛定谔的猫”告诉我们，事物发展不是确定的，而是量子态的叠加。

墨菲定律

    · 任何事情都没有表面看起来那么简单。
    · 所有事情的发展都会比你预计的时间长。
    · 会出错的事总会出错。
    · 如果你担心某种情况发生，那么它更有可能发生。

蝴蝶效应

世界会因一些微小因素的变动，而发生很大的变化。

熵增原理

“热力学第二定律”（熵增原理）告诉我们，世界总是在变得更加混乱无序。

警示我们对生产环境发生的任何怪异现象和问题都不要轻易忽视，对于其背后的原因一定要彻查。同样，海恩法则也强调任何严重事故的背后都是多次小问题的积累，积累到一定的量级后会导致质变，严重的问题就会浮出水面。那么，我们需要对线上服务产生的任何征兆，哪怕是一个小问题，也要刨根问底: 这就需要我们有技术攻关的能力，对任何现象都要秉着以下原则：为什么发生？发生了怎么应对？怎么恢复？怎么避免？对问题要彻查，不能因为问题的现象不明显而忽略。

3)、总结错误处理经验，快速定位和解决问题。

不回避问题,不怕攻关,不惧挑战。在其位要积极主动去分析排查问题，而不是被动去接受问题。

解决问题的思路是一种思维工具，通过提出问题、分析问题和解决问题的过程，可以帮助我们主动思考和积极学习。在解决问题过程中帮助我们更深入地理解和应用知识技能。

二、问题定位

出现这种问题，肯定是需要彻查日志定位和分析。

1、查接入层nginx日志：

nginx出现错误日志：(110: Connection timed out) while reading response header from upstream 一般是nginx读取来自upstream的响应头时超时。

主要接口xxxx/container请求超时。

2、排查是否存在：no live upsteams

接口/user/autch/check出现no live upsteams，即报出502错误。

3、业务nginx查询接口xxxx/container日志情况：

接口xxxx/container请求频繁（相对历史），http code=499，即service服务处理超时，接入层直接断开请求了。

初步定位：

由于接口接口xxxx/container大量请求超时，可能导致接入层nginx会剔除业务nginx服务，然后接口/user/autch/check出现no live upsteams，即报出502错误。

验证定位：

接口xxxx/container限流降级,在业务nginx特殊处理直接返回200：

localtion /xxxx/container {

return 200 "ok";

}

nginx -s reload后，接入层nginx的502日志消失。确定接口xxxx/container大量请求超时引起。

三、问题分析

1、为啥业务nginx明明存活负载很低，但是接入层偶尔出现502。

这个就需要了解nginx的健康检查机制：

我们接入层nginx upstream配置：

upstream upstream_6f6a3h8a0e5e1
{

server 192.168.1.21;

server 192.168.1.22;
}

nginx本身是没有针对负载均衡后端节点的健康检查的，但是可以通过默认自带的 ngx_http_proxy_module 模块和ngx_http_upstream_module模块中的相关指令来完成当后端节点出现故障时，自动切换到健康节点来提供访问。

ngx_http_upstream_module模块中的server指令范例：

upstream name {
                server 10.1.1.110:8080 max_fails=1 fail_timeout=10s;
                server 10.1.1.122:8080 max_fails=1 fail_timeout=10s;
        }
当upstream没有配置max_fails和fail_timeout，即nginx使用默认值fail_timeout为10s,max_fails为1次。

由于Nginx ngx_http_upstream_module模块是基于连接探测的，如果发现后端异常，在单位周期为fail_timeout设置的时间中失败次数达到max_fails次，这个周期次数内，如果后端同一个节点不可用，那么就将把节点标记为不可用，并等待下一个周期（同样时长为fail_timeout）再一次去请求，判断是否连接是否成功。
即在10s以内后端失败了1次【即一次请求超时】，那么这个后端就被标识为不可用了，所以在接下来的10s期间，nginx都会把请求分配给正常的后端【即多次的请求正常】。

关于502伴随出现错误no live upstreams while connecting to upstream的原因：在文章Nginx中常见问题与错误处理-CSDN博客

2、为啥业务nginx 出现499，接入层nginx显示响应超时。

这是因为接入层nginx配置响应超时为30s：

proxy_read_timeout 30s;
proxy_connect_timeout 5s;

而业务nginx超时是60s，即接入层nginx超时30s会主动断开和业务nginx连接。

此时业务nginx请求日志就会出现499.

四、解决问题

本质还是需要优化超时接口，但是为了预防某个接口出现问题进而导致整个服务不能用的情况，需要做一些预防措施。

方案1：优化 upstream 默认健康检测，主要降低出现502到概率。

upstream upstream_6f6a3h8a0e5e1 {

server 192.168.1.21 max_fails=3 fail_timeout=60s;

server 192.168.1.22 max_fails=3 fail_timeout=60s;
}

即在30s以内后端失败了3次那么这个后端才被标识为不可用了。

方案二：nginx_upstream_check_module模块主动检测：

在nginx.conf配置文件里面的upstream加入健康检查，如下：    upstream name {
           server 192.168.0.21:80;
           server 192.168.0.22:80;
           check interval=3000 rise=2 fall=5 timeout=1000 type=tcp;

    }

对name这个负载均衡条目中的所有节点，每个3秒检测一次端口是否存活，请求2次正常则标记 realserver状态为up，如果检测 5 次都失败，则标记 realserver的状态为down，超时时间为1秒。

目前这个是比较好的解决方案，确保正常流量都能进入到后端业务服务进行处理。

具体安装：

yum -y install pcre-devel openssl openssl-devel

cd /usr/local/src/
wget http://nginx.org/download/nginx-1.12.1.tar.gz
tar -zxvf nginx-1.12.1.tar.gz

cd /usr/local/src
wget https://codeload.github.com/openresty/echo-nginx-module/tar.gz/refs/tags/v0.62
tar zxvf v0.62

#下载 nginx_upstream_check_module模块
cd /usr/local/src
wget https://codeload.github.com/yaoweibin/nginx_upstream_check_module/zip/master
unzip master

#为nginx打补丁
cd nginx-1.12.1
#查看对应nginx版本： ll ../nginx_upstream_check_module-master/
patch -p1 < ../nginx_upstream_check_module-master/check_1.12.1+.patch

#安装nginx
./configure --prefix=/usr/local/nginx --with-http_stub_status_module --with-http_ssl_module --with-http_stub_status_module --with-http_ssl_module --add-module=/usr/local/src/echo-nginx-module-0.62 --add-module=/usr/local/src/nginx_upstream_check_module-master

make -j2
make install

原因：我安装的nginx版本为1.12.1，在安装nginx_upstream_check_module模块时忘记修改补丁文件版本（先安装了1.5.12+，后面发现错了又安装1.12.1+），导致在在make时报错.

关于nginx健康检查机制：Nginx健康检查机制-CSDN博客

五、nginx常见错误总结

Nginx中常见问题与错误处理-CSDN博客

错误日志[Error.log]

错误信息	错误说明
“upstream prematurely（过早的） closed connection”	请求uri的时候出现的异常，是由于upstream还未返回应答给用户时用户断掉连接造成的，对系统没有影响，可以忽略
“recv() failed (104: Connection reset by peer)”	（1）服务器的并发连接数超过了其承载量，服务器会将其中一些连接Down掉；（2）客户关掉了浏览器，而服务器还在给客户端发送数据；（3）浏览器端按了Stop
“(111: Connection refused) while connecting to upstream”	用户在连接时，若遇到后端upstream挂掉或者不通，会收到该错误
“(111: Connection refused) while reading response header from upstream”	用户在连接成功后读取数据时，若遇到后端upstream挂掉或者不通，会收到该错误
“(111: Connection refused) while sending request to upstream”	Nginx和upstream连接成功后发送数据时，若遇到后端upstream挂掉或者不通，会收到该错误
“(110: Connection timed out) while connecting to upstream”	nginx连接后面的upstream时超时
“(110: Connection timed out) while reading upstream”	nginx读取来自upstream的响应时超时
“(110: Connection timed out) while reading response header from upstream”	nginx读取来自upstream的响应头时超时
“(110: Connection timed out) while reading upstream”	nginx读取来自upstream的响应时超时
“(104: Connection reset by peer) while connecting to upstream”	upstream发送了RST，将连接重置
“upstream sent invalid header while reading response header from upstream”	upstream发送的响应头无效
“upstream sent no valid HTTP/1.0 header while reading response header from upstream”	upstream发送的响应头无效
“client intended to send too large body”	用于设置允许接受的客户端请求内容的最大值，默认值是1M，client发送的body超过了设置值
“reopening logs”	用户发送kill -USR1命令
“gracefully shutting down”,	用户发送kill -WINCH命令
“no servers are inside upstream”	upstream下未配置server
“no live upstreams while connecting to upstream”	upstream下的server全都挂了
“SSL_do_handshake() failed”	SSL握手失败
“SSL_write() failed (SSL:) while sending to client”
“(13: Permission denied) while reading upstream”
“(98: Address already in use) while connecting to upstream”
“(99: Cannot assign requested address) while connecting to upstream”
“ngx_slab_alloc() failed: no memory in SSL session shared cache”	ssl_session_cache大小不够等原因造成
“could not add new SSL session to the session cache while SSL handshaking”	ssl_session_cache大小不够等原因造成
“send() failed (111: Connection refused)”