詳解Nginx 被動檢查服務(wù)器的存活狀態(tài)
介紹
通過發(fā)送定期健康檢查來監(jiān)控上游組中 HTTP 服務(wù)器的健康狀況。Nginx 可以持續(xù)測試您的上游服務(wù)器,避免出現(xiàn)故障的服務(wù)器,并將恢復(fù)的服務(wù)器優(yōu)雅地添加到負(fù)載均衡組中。
被動健康檢查
對于被動健康檢查,Nginx 會在事務(wù)發(fā)生時(shí)對其進(jìn)行監(jiān)控,并嘗試恢復(fù)失敗的連接。如果事務(wù)仍然無法恢復(fù),Nginx 將服務(wù)器標(biāo)記為不可用并暫時(shí)停止向其發(fā)送請求,直到它再次標(biāo)記為活動狀態(tài)。
上游服務(wù)器標(biāo)記為不可用的條件是通過上游塊中服務(wù)器指令的參數(shù)為每個(gè)上游服務(wù)器定義的:
fail_timeout
:設(shè)置要將服務(wù)器標(biāo)記為不可用,必須進(jìn)行多次失敗嘗試的時(shí)間,以及服務(wù)器標(biāo)記為不可用的時(shí)間(默認(rèn)值為10秒)。max_fails
:設(shè)置在fail_timeout
期間必須發(fā)生的失敗嘗試次數(shù),以便將服務(wù)器標(biāo)記為不可用(默認(rèn)值為1次嘗試)。
在以下示例中,如果Nginx在30秒內(nèi)3次未能向服務(wù)器發(fā)送請求或未收到來自服務(wù)器的響應(yīng),則會在30秒內(nèi)將服務(wù)器標(biāo)記為不可用:
upstream backend { server backend1.example.com; server backend2.example.com max_fails=3 fail_timeout=30s; }
注意 :如果組中只有一臺服務(wù)器,則會忽略fail_timeout和max_fails參數(shù),并且服務(wù)器永遠(yuǎn)不會標(biāo)記為不可用。
服務(wù)器慢啟動
最近恢復(fù)的服務(wù)器很容易被連接淹沒,這可能會導(dǎo)致服務(wù)器再次被標(biāo)記為不可用。慢啟動允許上游服務(wù)器在恢復(fù)或可用后逐漸從零恢復(fù)其權(quán)重到其標(biāo)稱值。這可以通過 slow_start
上游server指令的參數(shù)來完成:
upstream backend { server backend1.example.com slow_start=30s; server backend2.example.com; server 192.0.0.1 backup; }
注意:如果組中只有一個(gè)服務(wù)器,
slow_start
則忽略該參數(shù)并且該服務(wù)器永遠(yuǎn)不會標(biāo)記為不可用。慢啟動是 NGINX Plus(商業(yè)版) 獨(dú)有的。
到此這篇關(guān)于Nginx 被動檢查服務(wù)器的存活狀態(tài)的文章就介紹到這了,更多相關(guān)Nginx檢查服務(wù)器存活狀態(tài)內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
nginx-ingress-controller日志持久化方案的解決
這篇文章主要介紹了nginx-ingress-controller日志持久化方案的解決,文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2020-03-03Nginx實(shí)現(xiàn)if多重判斷配置方法示例
這篇文章主要介紹了Nginx實(shí)現(xiàn)if多重判斷配置方法示例,本文直接給出實(shí)現(xiàn)代碼,需要的朋友可以參考下2015-05-05