Nginx通過max_fails和fail_timeout在進行HTTP運行狀況檢查

?

英文來源：https://docs.nginx.com/nginx/admin-guide/load-balancer/http-health-check/

?

HTTP運行狀況檢查

本文介紹如何在NGINX Plus和NGINX Open Source中配置和使用HTTP運行狀況檢查。

• 介紹
• 先決條件
• 被動健康檢查
  • 服務器慢啟動
• 主動健康檢查
  • 指定請求的URI
  • 定義自定義條件

?

介紹

NGINX和NGINX Plus可以持續檢查您所部署的上游服務器，避免出現故障的服務器，并可以將恢復的服務器正常地添加到負載平衡組中。

?

先決條件

• 對于被動健康檢查，可以使用NGINX Open Source或NGINX Plus
• 對于主動健康檢查和實時活動監控儀表板，NGINX Plus
• 一個負載均衡的HTTP上游服務器組

?

被動健康檢查

對于被動運行狀況檢查，NGINX和NGINX Plus會監視事務的發生，并嘗試恢復失敗的連接。如果仍然無法恢復交易，則NGINX Open Source和NGINX Plus將服務器標記為不可用，并暫時停止向其發送請求，直到再次將其標記為活動。

對于每個上游服務器，使用塊中server指令的參數定義了標記上游服務器不可用的條件upstream：

• fail_timeout?– 多次嘗試失敗而將服務器標記為不可用的時間，以及將服務器標記為不可用的時間（默認為10秒）。
• max_fails?– 在服務器被標記為不可用的時間內必須發生的失敗嘗試次數（默認為1次嘗試）。

在下面的示例中，如果NGINX無法在30秒內向服務器發送請求或沒有收到3次響應，則將服務器標記為30秒鐘不可用：

upstream backend {server backend1.example.com;server backend2.example.com max_fails=3 fail_timeout=30s; }

請注意，如果組中只有一臺服務器，則fail_timeout和max_fails參數將被忽略，并且服務器永遠不會被標記為不可用。

?

?

服務器慢啟動

最近恢復的服務器很容易被連接淹沒，這可能導致服務器再次標記為不可用。慢速啟動允許上游服務器在恢復或可用后將其權重從零逐漸恢復到其標稱值。這可以通過slow_start指令參數來完成：

upstream backend {server backend1.example.com slow_start=30s;server backend2.example.com;server 192.0.0.1 backup; }

請注意，如果組中只有一臺服務器，則slow_start參數將被忽略，并且永遠不會將服務器標記為不可用。慢速啟動是NGINX Plus獨有的。

?

主動健康檢查

NGINX Plus可以通過向每臺服務器發送特殊的運行狀況檢查請求并驗證正確的響應來定期檢查上游服務器的運行狀況。

要啟用主動健康檢查：

在location將請求（proxy_pass）傳遞到上游組的中，包括health_check指令：

server {location / {proxy_pass http://backend;health_check;} }

此代碼段定義了一個服務器，該服務器將所有請求（）location?/傳遞給名為的上游組backend。它還使用以下health_check指令啟用高級運行狀況監視：默認情況下，NGINX Plus每五秒鐘向組中的每個服務器發送一個“?/?”?請求backend。如果發生任何通信錯誤或超時（服務器以從200到的范圍之外的狀態代碼響應399），則運行狀況檢查將失敗。服務器被標記為不正常，NGINX Plus不會再次向其發送客戶端請求，直到它再次通過健康檢查。

（可選）您可以指定另一個端口進行運行狀況檢查，例如，用于監視同一主機上許多服務的運行狀況。使用指令的port參數指定一個新端口health_check：

server {location / {proxy_pass http://backend;health_check port=8080;} } ?

?

在上游服務器組中，使用以下zone指令定義共享內存區域：

http {upstream backend {zone backend 64k;server backend1.example.com;server backend2.example.com;server backend3.example.com;server backend4.example.com;} }

該區域在所有工作進程之間共享，并存儲上游組的配置。這使工作進程可以使用同一組計數器來跟蹤來自組中服務器的響應。

可以使用health_check偽指令的參數覆蓋活動運行狀況檢查的默認值：

location / {proxy_pass http://backend;health_check interval=10 fails=3 passes=2; }

在此，interval參數將運行狀況檢查之間的延遲從默認的5秒增加到10秒。該fails參數要求服務器未能通過三項健康檢查，以將其標記為不健康（高于默認狀態）。最后，該passes參數表示服務器必須通過兩次連續檢查才能再次標記為運行狀況正常，而不是默認情況。

?

指定請求的URI

使用指令的uri參數health_check來設置要在運行狀況檢查中請求的URI：

location / {proxy_pass http://backend;health_check uri=/some/path; }

指定的URI會附加到upstream塊中為服務器設置的服務器域名或IP地址上。對于backend上面聲明的樣本組中的第一臺服務器，運行狀況檢查將請求URI?http://backend1.example.com/some/path。

?

定義自定義條件

您可以設置響應必須滿足的自定義條件，服務器才能通過運行狀況檢查。條件在一個match塊中定義，該塊match在health_check指令的參數中引用。

在級別上，指定塊并為其命名，例如：http?{}match?{}server_ok

http {#...match server_ok {# tests are here} }

health_check通過指定match參數和match塊名稱，從指令中引用該塊：

http {#...match server_ok {status 200-399;body !~ "maintenance mode";}server {#...location / {proxy_pass http://backend;health_check match=server_ok;}} }

如果響應的狀態代碼在200–?范圍內399，并且其主體不包含字符串，則在此處通過運行狀況檢查。maintenance?mode

該match指令使NGINX Plus可以檢查狀態碼，標頭字段和響應的正文。使用此偽指令，可以驗證狀態是否在指定范圍內，響應是否包含標頭，或者標頭或正文是否與正則表達式匹配。該match指令可以包含一個狀態條件，一個主體條件和多個標頭條件。響應必須滿足match塊中定義的所有條件，服務器才能通過運行狀況檢查。

例如，下面的match指令匹配有狀態代碼響應200，精確值text/html的Content-Type標題，文字的身體：Welcome?to?nginx!

match welcome {status 200;header Content-Type = text/html;body ~ "Welcome to nginx!"; }

以下示例使用感嘆號（!）定義響應不必通過運行狀況檢查的特征。在這種情況下，健康檢查通過在狀態代碼比其他東西301，302，303，或307，并沒有Refresh頭。

match not_redirect {status ! 301-303 307;header ! Refresh; }

還可以為非HTTP協議（例如FastCGI，memcached，SCGI，uwsgi）以及TCP和UDP啟用運行狀況檢查。

參考資料： https://blog.51cto.com/kexiaoke/2316851 參考原文： https://docs.nginx.com/nginx/admin-guide/load-balancer/http-health-check/

總結

以上是生活随笔為你收集整理的Nginx通过max_fails和fail_timeout在进行HTTP运行状况检查的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。