最近線上用戶(hù)請(qǐng)求時(shí)不時(shí)返回502讹俊，并且沒(méi)多大規(guī)律，我們的部署架構(gòu)是Nginx + web應(yīng)用辈讶，nginx中的upstream配置了兩個(gè)web做負(fù)載均衡。
經(jīng)過(guò)分析web應(yīng)用娄猫，出現(xiàn)502的時(shí)候請(qǐng)求并沒(méi)有到達(dá)web應(yīng)用贱除，所以可以斷定請(qǐng)求502是Nginx直接返回，查看Nginx的access.log可以查到對(duì)應(yīng)的請(qǐng)求信息媳溺，確實(shí)返回502
GET /api/app/1 HTTP/1.1" 502 541 17.340
Nginx 的error.log日志相關(guān)異常：
upstream server temporarily disabled while reading response header from upstream, client..
no live upstreams while connecting to upstream, client..
可以看到月幌，是因?yàn)閡pstream server無(wú)效了，沒(méi)有可用的web應(yīng)用導(dǎo)致褂删，看到這個(gè)異常時(shí)飞醉，第一個(gè)反應(yīng)是難不成兩臺(tái)web會(huì)都掛了？屯阀？缅帘？
但是查看web的運(yùn)行日志和服務(wù)狀態(tài)service xx status，當(dāng)出現(xiàn)502時(shí)难衰，web應(yīng)用的運(yùn)行都是正常的钦无，并沒(méi)有重啟或是宕機(jī)，所以排除web應(yīng)用問(wèn)題盖袭，那會(huì)不會(huì)是之前有其他異常導(dǎo)致這個(gè)502Ｊг荨彼宠？繼續(xù)分析了出現(xiàn)502之前的日志，果然弟塞，在502之前都有一個(gè)500異常凭峡，并且這個(gè)異常很有頻率的出現(xiàn)。
"GET /api/project HTTP/1.1" 500 214 0.087 "http://xx.com/" "Mozilla/5.0 (Win
dows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36" "-" "-" xxx.net "10.x.x.x:8081, 10.x.x.x:8081" "500, 500" "0.045, 0.042"
通過(guò)url分析發(fā)現(xiàn)决记，這個(gè)是因?yàn)轫?yè)面有一個(gè)定時(shí)任務(wù)摧冀，會(huì)十秒刷新一次，而這個(gè)api正好因?yàn)橛衎ug系宫，請(qǐng)求會(huì)返回500索昂，不過(guò)有點(diǎn)想不通的是500為什么會(huì)導(dǎo)致后續(xù)正常請(qǐng)求出現(xiàn)502，后來(lái)通過(guò)分析nginx的nginx.conf扩借，原來(lái)nginx配置了proxy_next_upstream屬性椒惨，這個(gè)屬性作用是如果發(fā)現(xiàn)請(qǐng)求返回的是后面的配置狀態(tài)時(shí)就會(huì)轉(zhuǎn)發(fā)到下一個(gè)upstream，例如：500
location / {
? ? ? proxy_pass? ? ? ? http://app-proxy;
? ? ? proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
? ? ? proxy_next_upstream_tries 3;
? ? ? proxy_connect_timeout 60s;
? ? ? proxy_read_timeout 60s;
? ? ? proxy_send_timeout 60s;
? ? ? proxy_pass_request_headers? ? ? on;
? ? ? proxy_set_header? Host? ? ? ? ? ? $host:$server_port;
? ? ? proxy_set_header? X-Real-IP? ? ? ? $remote_addr;
? ? ? proxy_set_header? X-Forwarded-For? $proxy_add_x_forwarded_for;
? ? ? set $domain default;
結(jié)果測(cè)試發(fā)現(xiàn)潮罪，如果每個(gè)實(shí)例都返回500后康谆，接下來(lái)的請(qǐng)求就會(huì)出現(xiàn)502，如果訪問(wèn)正常的api错洁，又會(huì)恢復(fù)正常秉宿，說(shuō)明nginx當(dāng)發(fā)現(xiàn)upstream都為500的時(shí)候，就會(huì)臨時(shí)disable所有upstream屯碴，也就是上面error.log上出現(xiàn)的“upstream server temporarily disabled”描睦，后續(xù)請(qǐng)求就會(huì)有“no live upstreams”問(wèn)題，但是出現(xiàn)502后导而，新請(qǐng)求會(huì)重新檢測(cè)忱叭，當(dāng)請(qǐng)求是200，就會(huì)恢復(fù)正常今艺。
解決：?jiǎn)栴}原因找到了韵丑，解決辦法也就簡(jiǎn)單了，這個(gè)500一般是服務(wù)器端的bug虚缎，一般請(qǐng)求都不會(huì)直接返回500撵彻，出現(xiàn)問(wèn)題及時(shí)解決就好，另外這個(gè)使用這個(gè)屬性時(shí)得注意实牡，如果請(qǐng)求是后面枚舉的狀態(tài)時(shí)陌僵，nginx會(huì)直接轉(zhuǎn)到另外一個(gè)upstream，所以會(huì)出現(xiàn)多個(gè)實(shí)例都接收到請(qǐng)求的情況创坞，有些情況下是不允許的碗短，所以使用的時(shí)候需要分析一下。
