Nginx实战：故障处理_后端服务正常,nginx偶发502(Bad Gateway)

一、故障场景

用户访问服务偶发报错【502 Bad Gateway】，但是服务后端正常运行。架构如下：

#mermaid-svg-4dDszusKEuPgIPlt {font-family:”trebuchet ms”,verdana,arial,sans-serif;font-size:16px;fill:#333;}#mermaid-svg-4dDszusKEuPgIPlt .error-icon{fill:#552222;}#mermaid-svg-4dDszusKEuPgIPlt .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-4dDszusKEuPgIPlt .edge-thickness-normal{stroke-width:2px;}#mermaid-svg-4dDszusKEuPgIPlt .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-4dDszusKEuPgIPlt .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-4dDszusKEuPgIPlt .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-4dDszusKEuPgIPlt .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-4dDszusKEuPgIPlt .marker{fill:#333333;stroke:#333333;}#mermaid-svg-4dDszusKEuPgIPlt .marker.cross{stroke:#333333;}#mermaid-svg-4dDszusKEuPgIPlt svg{font-family:”trebuchet ms”,verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-4dDszusKEuPgIPlt .label{font-family:”trebuchet ms”,verdana,arial,sans-serif;color:#333;}#mermaid-svg-4dDszusKEuPgIPlt .cluster-label text{fill:#333;}#mermaid-svg-4dDszusKEuPgIPlt .cluster-label span{color:#333;}#mermaid-svg-4dDszusKEuPgIPlt .label text,#mermaid-svg-4dDszusKEuPgIPlt span{fill:#333;color:#333;}#mermaid-svg-4dDszusKEuPgIPlt .node rect,#mermaid-svg-4dDszusKEuPgIPlt .node circle,#mermaid-svg-4dDszusKEuPgIPlt .node ellipse,#mermaid-svg-4dDszusKEuPgIPlt .node polygon,#mermaid-svg-4dDszusKEuPgIPlt .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-4dDszusKEuPgIPlt .node .label{text-align:center;}#mermaid-svg-4dDszusKEuPgIPlt .node.clickable{cursor:pointer;}#mermaid-svg-4dDszusKEuPgIPlt .arrowheadPath{fill:#333333;}#mermaid-svg-4dDszusKEuPgIPlt .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-4dDszusKEuPgIPlt .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-4dDszusKEuPgIPlt .edgeLabel{background-color:#e8e8e8;text-align:center;}#mermaid-svg-4dDszusKEuPgIPlt .edgeLabel rect{opacity:0.5;background-color:#e8e8e8;fill:#e8e8e8;}#mermaid-svg-4dDszusKEuPgIPlt .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-4dDszusKEuPgIPlt .cluster text{fill:#333;}#mermaid-svg-4dDszusKEuPgIPlt .cluster span{color:#333;}#mermaid-svg-4dDszusKEuPgIPlt div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:”trebuchet ms”,verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-4dDszusKEuPgIPlt :root{–mermaid-font-family:”trebuchet ms”,verdana,arial,sans-serif;}

偶发502

转发

偶发502

用户

Nginx

B服务

A服务

二、问题线索

服务正常，但是nginx报错【502 Bad Gateway】，这代表nginx认为后端服务都不存活

首先会想到网络问题，是不是网络抖动导致的，检查没有问题，那么只能看看nginx的日志了

在nginx的日志中看到三个报错：

1. 502 Bad Gateway (各个接口都有，不固定)
2. 504 upstream teime out （单个接口报错，都是接口A）
3. no live upstream while connect (各个接口都有，不固定)

三、问题原因

看到nginx的日志之后，就可以明确定位到原因了，是nginx的健康检查机制导致。

3.1、nginx的健康检查介绍

nginx的upstream有默认的健康检查机制（max_fails和fail_timeout）

这个健康检查机制的逻辑是：
在fail_timeout时间段之内，如果该节点累计异常次数大于或等于max_fails，那么这个节点就会被摘除fail_timeout时间，fail_timeout时间之后该实例会被重新加入，并且该节点的异常次数重置为0，重新开始进行新一轮的检查

fail_timeout默认值为10S，max_fails默认值为1。

【举个例子】

后端两个实例，1.1.1.1 实例卡死（进程在，无响应，访问到会报504），2.2.2.2正常

Nginx配置如下

	upstream test {
	        server 1.1.1.1:8081 weight=1;
	        server 2.2.2.2:8081 weight=1;
	}

那么用户第一次访问，如果访问到1.1.1.1实例，实例无响应，超过超时时间，报错504，1.1.1.1的fail次数达到1次（max_fails默认值为1）

1.1.1.1实例被剔除10秒（fail_timeout默认值为10秒）

这10秒内存访问都会落在正常的2.2.2.2实例上，访问正常

直到10秒之后，异常实例1.1.1.1被重新加入转发，用户访问到之后再次报错504，1.1.1.1再次被剔除10秒，周而复始

这就会出现一个很规律的异常现象，每10秒就会出现一次504访问超时（访问到1.1.1.1异常实例无响应，超时报错）

3.2、本次异常原因梳理

本次异常是几个因素配到一起导致出现的异常现象

1. 一个高频接口响应时间长，超过60秒
2. fail_timeout是默认值10S，max_fails是默认值1
3. proxy_read_timeout后端响应超时时间设置的是60S

有一个接口响应时间大部分都大于proxy_read_timeout设置的后端响应超时时间60秒，每次请求到这个接口，这个接口转发到后端实例，这个后端实例在proxy_read_timeout时间内没有返回，nginx直接返回504，并且记录失败次数为1，因为达到最大失败次数1（max_fails默认值为1），所以将该后端直接剔除10秒（fail_timeout默认值为10秒）

而这个接口被调用频繁，有几率出现短暂时间，所有实例都被nginx剔除的情况，如下图所示：

所以会出现一个接口报错504（响应慢的接口），全部接口偶发502的情况（所有节点被剔除的时间段），并且nginx error日志偶发出现【no live upstream while connect 】

四、处理方法

1、根本解决还是优化那个慢接口
2、或者为耗时较长的慢接口单独设置upstream和server，这样不会影响其他接口。
3、调大proxy_read_timeout，不让慢接口出现504。
4、提高检测是否可用的频率，即调大max_fails，调小fail_timeout，使 fail_timeout/max_fails变小。