架构师技能：技术深度硬实力透过问题看本质--深入分析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.

3、接口xxxx/container大量请求超时

依赖底层一个服务出现变动，导致接口处理超时。

四、解决问题

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

方案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数量，这样业务nginx完全被剔除概率就更低

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;

server 192.168.1.23 max_fails=3 fail_timeout=60s;

server 192.168.1.24 max_fails=3 fail_timeout=60s;
}

方案三：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博客

五、技术深度硬实力：透过问题看本质，解决问题和绕开问题。

透过问题看本质则是由虚到实，往深层次地挖掘：

大部分人看到这个502，就表面的认为偶尔服务异常不用关注。但问题的本质原因是什么？没深层次去挖掘。

在实践中遇到问题，不仅只解决问题，还要对问题刨根问底，深入挖掘问题发生的根本原因，这样可以系统性地修复问题，从而使其永久消失。从问题本身着手,沿着因果关系链条,顺藤摸瓜,穿越不同的抽象层面,直至找出原有问题的根本原因.

我们中国古代以来就有“打破沙锅问到底”的习惯;“打破沙锅问到底”是一句俗语,形象表达了锲而不舍、不断探索的精神,这是人们常挂在嘴边的一句口头禅。

我们遇到问题，从外到里，逐层分析：
1、问题表象是什么
2、直接原因是什么？
3、中间原因是什么？
4、根本原因是什么？

深层次挖掘：接入nginx-》业务nginx-》service 。

直接原因：直接原因是接口xxxx/container大量请求超时，解决接口xxxx/container超时后，到这虽然可以解决本次问题，但下次是否还会出现？

中间原因：接入层nginx健康检查机制配置不合理，负责nginx的人员应该具备这些专业知识。作为接入层，是不能拦截正常的业务请求，要确保业务请求流量都转发待业务nignx，如果不解决好，下次另外的接口处理频繁处理超时，是不是也要剔除业务nginx？

根本原因：接入层单纯做负载均衡，健康检查最好是使用只检测端口存活，具体http异常应该由业务nginx进行处理。

表象：是http应用协议调用，接口xxxx/container大量请求超时导致。

中层：tcp/ip跨网络调用。

底层：操作系统如何封装tcp/ip，然后通过网卡，路由器等介质进行传输。

透过问题看本质能够敏锐地发现底层之真实，系统性端到端地思考问题，识别木桶的短板并解决之。

4、挖掘本质

又回到由浅入深学习层次：了解——熟悉——掌握——精通——专家

1、了解：入门，简单的认知和记忆，表示知道。是最低水平的认知学习结果。

2、熟悉：概念，了解概念得清楚，清楚地知道概念；（对某种技术或学问）侧重于知道得清楚，比了解更进一层。

2、掌握：规则、应用规则到实践，是在熟悉的基础上能充分加以运用。

3、精通：高级规则，深入底层。

4、专家：扩展创新。

将世界万物理解为原子，将整个互联网理解成0和1，这倒的确是非常本质了，不过并不能解答任何问题。从问题现象看本质，实质上是一个从表层逐步深入的过程。

说到透过现象看本质，其实就是黄金思维圈，你在技术上遇到每一件事情，首先问“为什么”，所谓黄金思维圈，其实是我们认知世界的方式。我们看问题的方式。
可以分为三个层面——

第一个层面是what层面，也就是事情的表象，我们具体做的每一件事；

第二个层面是how层面，也就是我们如何实现我们想要做的事情；

第三个层面是why层面，也就是我们为什么做这样的事情。

六、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)”