背景

nginx 499在服務(wù)端推送流量高峰期長(zhǎng)期以來(lái)都是存在的，間或還能達(dá)到告警閾值觸發(fā)一小波告警，但主觀上一直認(rèn)為499是客戶端主動(dòng)斷開(kāi)，可能和推送高峰期的用戶打開(kāi)推送后很快殺死app有關(guān)，沒(méi)有進(jìn)一步探究問(wèn)題根源。
然而近期在非高峰期也存在499超過(guò)告警閾值的偶發(fā)情況，多的時(shí)候一天幾次，少的時(shí)候則幾天一次，持續(xù)一般也就數(shù)分鐘，并且該類(lèi)告警一般集中于一臺(tái)api機(jī)器，與推送高峰時(shí)多臺(tái)機(jī)器同時(shí)499告警明顯不同，不由得腦海中升起了問(wèn)號(hào)，經(jīng)過(guò)和小伙伴的共同探究，最后發(fā)現(xiàn)之前對(duì)于499是客戶端主動(dòng)斷開(kāi)因而和服務(wù)端關(guān)系不大的想當(dāng)然認(rèn)知是錯(cuò)誤的，這里記錄一下。

499的含義與可能原因

499其實(shí)并不是HTTP協(xié)議的標(biāo)準(zhǔn)狀態(tài)碼，而是nginx自定義的狀態(tài)碼，并沒(méi)有在nginx官方文檔中找到對(duì)該狀態(tài)碼的明確說(shuō)明，這里引用一個(gè)感覺(jué)比較專(zhuān)業(yè)的博文上的解釋?zhuān)?/p>

HTTP error 499 simply means that the client shut off in the middle of processing the request through the server. The 499 error code puts better light that something happened with the client, that is why the request cannot be done. So don’t fret: HTTP response code 499 is not your fault at all.

大意是499一般意味著客戶端在HTTP請(qǐng)求還在處理時(shí)主動(dòng)結(jié)束的處理過(guò)程--斷開(kāi)了對(duì)應(yīng)的網(wǎng)絡(luò)連接，499一般意味著客戶端側(cè)發(fā)生了一些問(wèn)題，和服務(wù)端沒(méi)有關(guān)系。
以下則是nginx源碼中的注釋說(shuō)明：

/*
* HTTP does not define the code for the case when a client closed
* the connection while we are processing its request so we introduce
* own code to log such situation when a client has closed the connection
* before we even try to send the HTTP header to it
*/
#define NGX_HTTP_CLIENT_CLOSED_REQUEST     499

意思是nginx引入了自定義的code 499來(lái)記錄客戶端斷開(kāi)連接時(shí)nginx還沒(méi)有處理完其請(qǐng)求的場(chǎng)景。
回想多年以前首次碰到499場(chǎng)景時(shí)在網(wǎng)絡(luò)搜索資料也是看到了類(lèi)似的解答，所以一直認(rèn)為499和服務(wù)端關(guān)系不大，應(yīng)該都是客戶端的原因。

一個(gè)客戶端主動(dòng)行為導(dǎo)致499的例子

曾經(jīng)遇到過(guò)一個(gè)搜索聯(lián)想接口，其499比例比其他api高上幾十倍--一騎絕塵，單看該api基本上長(zhǎng)期位于告警閾值之上，也追蹤過(guò)其具體異常原因，最后聯(lián)合客戶端小伙伴給出了結(jié)論：搜索聯(lián)想接口的499比例偏高時(shí)正常的，因?yàn)椋?/p>

• 該api的調(diào)用場(chǎng)景是用戶在搜索框輸入搜索詞時(shí)，用戶每輸入一個(gè)字符都會(huì)立刻用最新的輸入調(diào)用api并將返回的聯(lián)想結(jié)果展示給用戶，以此達(dá)到一個(gè)近實(shí)時(shí)搜索聯(lián)想的功能。
• 既然每次用戶輸入新字符都觸發(fā)了最新的api調(diào)用請(qǐng)求，那即便之前的調(diào)用請(qǐng)求還在進(jìn)行中，客戶端也應(yīng)該直接結(jié)束這些已無(wú)實(shí)際作用的舊請(qǐng)求，這反映在nginx log上就是客戶端主動(dòng)斷開(kāi)了連接的499。

所以搜索聯(lián)想api雖然有異于普通api的高比例499，卻是完全合理的，客戶端要負(fù)主動(dòng)斷開(kāi)連接的責(zé)任，但是并沒(méi)有做錯(cuò)任何事情，服務(wù)端也沒(méi)有任何問(wèn)題。

一個(gè)客戶端被動(dòng)行為導(dǎo)致499的例子

另一個(gè)之前認(rèn)為客戶端行為導(dǎo)致499的例子是推送高峰，部分用戶在通過(guò)推送打開(kāi)app后可能會(huì)秒殺app，而推送高峰時(shí)期一般服務(wù)端壓力比較大本身響應(yīng)就會(huì)比平峰時(shí)期慢一些，此時(shí)有些api請(qǐng)求可能還正在進(jìn)行中，此時(shí)用戶殺死了app--app含冤而死無(wú)能為力--對(duì)應(yīng)連接自然就被OS斷開(kāi)回收了，于是也導(dǎo)致了499，這種場(chǎng)景下服務(wù)端也是沒(méi)有問(wèn)題的。

服務(wù)端問(wèn)題可能導(dǎo)致499？

通過(guò)上面兩個(gè)例子乍看下去，499都是客戶端側(cè)的原因，無(wú)論是其主動(dòng)還是被動(dòng)行為，也正是這兩個(gè)例子加深了博主心中對(duì)于499服務(wù)端應(yīng)該無(wú)責(zé)任的意識(shí)。
總結(jié)服務(wù)端出錯(cuò)可能導(dǎo)致的nginx錯(cuò)誤碼，主要應(yīng)該是以下幾個(gè)場(chǎng)景：

• 500： 內(nèi)部錯(cuò)誤，一般為請(qǐng)求參數(shù)直接導(dǎo)致了upstream 的處理線程執(zhí)行代碼出錯(cuò)，業(yè)務(wù)代碼或者框架直接返回 Internal Error
• 502： 一般為upstream server直接掛了無(wú)法連接，nginx無(wú)法訪問(wèn)upstream所以返回 Bad Gateway
• 503： upstream負(fù)載過(guò)高--但是沒(méi)掛，直接返回了Service Unavailable
• 504: upstream處理請(qǐng)求時(shí)間過(guò)長(zhǎng)，nginx等待upstream返回超時(shí)返回Gateway Timeout

所以無(wú)論是代碼執(zhí)行出錯(cuò)、服務(wù)掛了、服務(wù)過(guò)于繁忙、請(qǐng)求處理耗時(shí)過(guò)長(zhǎng)導(dǎo)致HTTP請(qǐng)求失敗，都是返回的5XX，壓根不會(huì)觸發(fā)499。
一般情況來(lái)說(shuō)確實(shí)是這樣的，但是這次新出現(xiàn)的平峰499并非一般情況，在網(wǎng)上查找資料時(shí)時(shí)有人提出過(guò)nginx 499可能是服務(wù)端處理耗時(shí)過(guò)長(zhǎng)導(dǎo)致客戶端超時(shí)后主動(dòng)斷開(kāi)，但是這種情況按照上面的描述不應(yīng)該屬于場(chǎng)景4-- upstream處理請(qǐng)求時(shí)間過(guò)長(zhǎng)，nginx返回504才對(duì)嗎？
所以看上去服務(wù)端處理耗時(shí)過(guò)長(zhǎng)既可能導(dǎo)致客戶端主動(dòng)斷開(kāi)的499也可能導(dǎo)致nginx返回Gateway Timeout的504，那導(dǎo)致這個(gè)區(qū)別的關(guān)鍵因素是什么？
簡(jiǎn)單來(lái)說(shuō)就是如果客戶端先斷開(kāi)被nginx檢測(cè)到那就是499，而如果upstream 耗時(shí)過(guò)長(zhǎng)超時(shí)先被nginx判定就是504，所以關(guān)鍵就是nginx對(duì)于upstream 超時(shí)的時(shí)間設(shè)置，捋到這里趕緊去看了下nginx的超時(shí)相關(guān)配置，嗯，沒(méi)有明確配置相關(guān)超時(shí)時(shí)間--！

nginx中的504判定相關(guān)超時(shí)配置

由于api與nginx是通過(guò)uwsgi協(xié)議通信，因此關(guān)鍵的超時(shí)配置參數(shù)如下：

Syntax:	uwsgi_connect_timeout time;
Default:	
uwsgi_connect_timeout 60s;
Context:	http, server, location
Defines a timeout for establishing a connection with a uwsgi server. It should be noted that this timeout cannot usually exceed 75 seconds.
Syntax:	uwsgi_send_timeout time;
Default:	
uwsgi_send_timeout 60s;
Context:	http, server, location
Sets a timeout for transmitting a request to the uwsgi server. The timeout is set only between two successive write operations, not for the transmission of the whole request. If the uwsgi server does not receive anything within this time, the connection is closed.
Syntax:	uwsgi_read_timeout time;
Default:	
uwsgi_read_timeout 60s;
Context:	http, server, location
Defines a timeout for reading a response from the uwsgi server. The timeout is set only between two successive read operations, not for the transmission of the whole response. If the uwsgi server does not transmit anything within this time, the connection is closed.

在未明確指定的情況下其超時(shí)時(shí)間均默認(rèn)為60s，簡(jiǎn)單來(lái)說(shuō)（實(shí)際情況更復(fù)雜一些但這里不進(jìn)一步探討）只有在upstream處理請(qǐng)求耗時(shí)超過(guò)60s的情況下nginx才能判定其Gateway Timeout 并按照504處理，然而客戶端設(shè)置的HTTP請(qǐng)求超時(shí)時(shí)間其實(shí)只有15s--這其中還包括外網(wǎng)數(shù)據(jù)傳輸?shù)臅r(shí)間，于是問(wèn)題來(lái)了：每一個(gè)服務(wù)端處理耗時(shí)超過(guò)15s的請(qǐng)求，nginx由于還沒(méi)達(dá)到60s的超時(shí)閾值不會(huì)判定504，而客戶端則會(huì)由于超過(guò)本地的15s超時(shí)時(shí)間直接斷開(kāi)連接，nginx于是就會(huì)記錄為499。
通過(guò)回查nginx log，非高峰期的499告警時(shí)段確實(shí)是存在單臺(tái)upstream 請(qǐng)求處理緩慢，耗時(shí)過(guò)長(zhǎng)，于是可能導(dǎo)致：

• 用戶在需要block等待請(qǐng)求的頁(yè)面等待雖然不到15s但是已經(jīng)不耐煩了，直接采取切頁(yè)面或者殺死app重啟的方式結(jié)束當(dāng)前請(qǐng)求。
• 用戶耐心等待了15s、或者非阻塞的后臺(tái)HTTP請(qǐng)求超過(guò)了15s超過(guò)超時(shí)閾值主動(dòng)斷開(kāi)連接結(jié)束了當(dāng)前請(qǐng)求。

服務(wù)端耗時(shí)過(guò)長(zhǎng)導(dǎo)致的499

上面已經(jīng)知道近期新出現(xiàn)的單臺(tái)upstream 偶發(fā)499是由于響應(yīng)緩慢引起的，既然是由于客戶端超時(shí)時(shí)間(15s)遠(yuǎn)小于nginx upstream超時(shí)時(shí)間(60s)引起的，這應(yīng)該屬于一個(gè)明顯的配置不當(dāng)，會(huì)導(dǎo)致三個(gè)明顯的問(wèn)題：

• 將用戶由于各種原因(如殺app)很快主動(dòng)斷開(kāi)連接導(dǎo)致的499與客戶端達(dá)到超時(shí)時(shí)間(這里是15s)導(dǎo)致的499混在了一起，無(wú)法區(qū)分客戶端責(zé)任與服務(wù)端責(zé)任導(dǎo)致499問(wèn)題。
• 對(duì)于nginx判定為499的請(qǐng)求，由于認(rèn)為是客戶端主動(dòng)斷開(kāi)，不會(huì)被認(rèn)為是服務(wù)端導(dǎo)致的unsuccessful attempt而被計(jì)入用于failover判定的max_fails計(jì)數(shù)中，所以即便一個(gè)upstream大量觸發(fā)了499，nginx都不會(huì)將其從可用upstream中摘除，相當(dāng)于摘除不可用節(jié)點(diǎn)的功能失效，而由于負(fù)載過(guò)高導(dǎo)致499的upstream收到的請(qǐng)求依然不斷增加最終可能導(dǎo)致更大的問(wèn)題。
• 對(duì)于判定為499的請(qǐng)求，也是由于不會(huì)被認(rèn)為是unsuccessful attempt，所以u(píng)wsgi_next_upstream這一配置也不會(huì)work，于是當(dāng)?shù)谝粋€(gè)處理請(qǐng)求的upstream耗時(shí)過(guò)長(zhǎng)超時(shí)后，nginx不會(huì)嘗試將其請(qǐng)求轉(zhuǎn)發(fā)為下一個(gè)upstream嘗試處理后返回，只能直接失敗。

那是不是把客戶端超時(shí)時(shí)間調(diào)大？或者把nginx upstream超時(shí)時(shí)間調(diào)小解決呢？
調(diào)大客戶端超時(shí)時(shí)間當(dāng)然是不合理的，任何用戶請(qǐng)求15s還未收到響應(yīng)肯定是有問(wèn)題的，所以正確的做法應(yīng)該是調(diào)小upstream的超時(shí)時(shí)間，一般來(lái)說(shuō)服務(wù)端對(duì)于客戶端請(qǐng)求處理時(shí)間應(yīng)該都是在數(shù)十、數(shù)百ms之間，超過(guò)1s就已經(jīng)屬于超長(zhǎng)請(qǐng)求了，所以不但默認(rèn)的60s不行，客戶端設(shè)置的15s也不能用于upstream的超時(shí)判定。
最終經(jīng)過(guò)綜合考慮服務(wù)端各api的耗時(shí)情況，先敲定了一個(gè)upstream 5s的超時(shí)時(shí)間配置--由于之前沒(méi)有經(jīng)驗(yàn)首次修改步子不邁太大，觀察一段時(shí)間后繼續(xù)調(diào)整，這樣做已經(jīng)足以很大程度解決以上的3個(gè)問(wèn)題：

• 將用戶由于各種原因(如殺app)很快主動(dòng)斷開(kāi)連接導(dǎo)致的499與nginx達(dá)到upstream超時(shí)時(shí)間時(shí)主動(dòng)結(jié)束的504區(qū)分開(kāi)了。
• 504會(huì)被納入max_fails計(jì)算，觸發(fā)nginx摘除失敗節(jié)點(diǎn)邏輯，在單臺(tái)機(jī)器故障響應(yīng)緩慢時(shí)可以被識(shí)別出來(lái)暫時(shí)摘除出可用節(jié)點(diǎn)列表，防止其負(fù)載進(jìn)一步加大并保證后續(xù)請(qǐng)求均被正?？捎霉?jié)點(diǎn)處理返回。
• 當(dāng)nginx等待upstream處理達(dá)到5s觸發(fā)超時(shí)時(shí)，其會(huì)按照uwsgi_next_upstream配置嘗試將請(qǐng)求(默認(rèn)僅限冪等的GET請(qǐng)求)轉(zhuǎn)交給下一個(gè)upstream嘗試處理后返回，這樣在單一upstream由于異常負(fù)載較高超時(shí)時(shí)，其他正常的upstream可以作為backup兜底處理其超時(shí)請(qǐng)求，這里客戶端原本等待15s超時(shí)的請(qǐng)求一般在5~10s內(nèi)可以兜底返回。

通過(guò)proxy_ignore_client_abort配置解決499問(wèn)題？

在網(wǎng)上查找資料時(shí)還有網(wǎng)友提出解除nginx 499問(wèn)題的一個(gè)思路是設(shè)置proxy_ignore_client_abort參數(shù)，該參數(shù)默認(rèn)為off，將其設(shè)置為on 后，對(duì)于客戶端主動(dòng)斷開(kāi)請(qǐng)求的情況，nginx會(huì)ignore而以u(píng)pstream實(shí)際返回的狀態(tài)為準(zhǔn)，nginx官方文檔說(shuō)明如下：

Syntax:	proxy_ignore_client_abort on | off;
Default:	
proxy_ignore_client_abort off;
Context:	http, server, location
Determines whether the connection with a proxied server should be closed when a client closes the connection without waiting for a response.

但是在客戶端主動(dòng)斷開(kāi)連接時(shí)，設(shè)置這個(gè)參數(shù)的意義除了使nginx log中記錄的狀態(tài)碼完全按照upstream返回確定，而非表示客戶端斷連的499之外，對(duì)于實(shí)際問(wèn)題解決完全沒(méi)有任何幫助，感覺(jué)頗有把頭埋進(jìn)沙子的鴕鳥(niǎo)風(fēng)格，不知道這個(gè)參數(shù)設(shè)置到底會(huì)有什么實(shí)用的場(chǎng)景。

非高峰時(shí)期單個(gè)upstream偶發(fā)響應(yīng)緩慢、導(dǎo)致超時(shí)的原因

這是個(gè)好問(wèn)題，這個(gè)問(wèn)題是近期才出現(xiàn)的，在解決了上面說(shuō)的nginx錯(cuò)配問(wèn)題后嘗試排查這個(gè)問(wèn)題，從現(xiàn)象上看應(yīng)該是某些特定請(qǐng)求觸發(fā)了upsteam CPU飆升，響應(yīng)緩慢后進(jìn)一步影響了后續(xù)請(qǐng)求的處理，最終導(dǎo)致所有請(qǐng)求響應(yīng)緩慢觸發(fā)客戶端499。
在nginx錯(cuò)配問(wèn)題解決后，再次出現(xiàn)這種單臺(tái)upstream緩慢超時(shí)情況后，nginx會(huì)很快通過(guò)failover摘除掉問(wèn)題upstream避免情況進(jìn)一步惡化，而對(duì)于首次訪問(wèn)問(wèn)題upstream超時(shí)的GET請(qǐng)求也會(huì)backup轉(zhuǎn)發(fā)至其他可用upstream處理后返回，已經(jīng)很大程度上降低了此類(lèi)異常情況的影響。
最終，修正配置后單upstream的偶發(fā)異常會(huì)以幾天一次的頻率觸發(fā)部分POST api的少量504閾值告警，其問(wèn)題的根本原因還在探尋中。

總結(jié)

人生有太多錯(cuò)誤的想當(dāng)然，nginx 499一般是客戶端責(zé)任便是一個(gè)例證，對(duì)于線上長(zhǎng)期存在的少量異常告警，還是要懷有一絲敬畏之心，小心溫水煮青蛙，在時(shí)間允許的情況下多探究、多思考。

轉(zhuǎn)載請(qǐng)注明出處，原文地址：https://www.cnblogs.com/AcAc-t/p/nginx_499_and_504_for_uwsgi.html

參考資料

https://www.belugacdn.com/499-error-code/

https://juejin.cn/post/6844903876315873293http://nginx.org/en/docs/

http/ngx_http_uwsgi_module.html#uwsgi_read_timeout

https://www.cnblogs.com/AcAct/p/nginx_499_and_504_for_uwsgi.html

http://nginx.org/en/docs/http/ngx_http_upstream_module.html

http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_ignore_client_abort

到此這篇關(guān)于記一次nginx配置不當(dāng)引發(fā)的499與failover 機(jī)制失效問(wèn)題的文章就介紹到這了,更多相關(guān)nginx配置不當(dāng)引發(fā)的499與failover 機(jī)制失效 內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論