Nginx http運行情況健康檢查配置

原文連接：何曉東 博客

翻譯自 官方文檔

被動檢查

對於被動健康檢查，NGINX 和 NGINX Plus 會在事件發生時對其進行監控，並嘗試恢復失敗的鏈接。若是仍然沒法恢復正常，NGINX 開源版和 NGINX Plus 會將服務器標記爲不可用，並暫時中止向其發送請求，直到它再次標記爲活動狀態。

上游服務器標記爲不可用的條件是爲每一個上游服務器定義的，其中包含塊中 server 指令的參數 upstream：

• fail_timeout - 設置服務器標記爲不可用時必須進行屢次失敗嘗試的時間，以及服務器標記爲不可用的時間（默認爲 10 秒）。
• max_fails - 設置在 fail_timeout 服務器標記爲不可用期間必須發生的失敗嘗試次數（默認爲 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 參數被忽略，服務器永遠不會標記爲不可用。

服務器慢啓動

最近恢復的服務器很容易被鏈接淹沒，這可能致使服務器再次被標記爲不可用。慢啓動容許上游服務器在恢復或變得可用以後逐漸將其權重從零恢復到其標稱值。這能夠指定 upstream 的 server 模塊的 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的主動檢查

NGINX Plus 能夠經過向每一個服務器發送特殊的健康檢查請求並驗證正確的響應來按期檢查上游服務器的運行情況。

要啓用活動運行情況檢查：

1. 在 location 區塊將 requests（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;
    }
}

1. 在上游服務器組，使用 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 參數意味着服務器必須經過兩次連續檢查才能再次標記爲健康，而不是默認值。

指定請求的URL

在 health_check 指令中指定 uri 參數來設置健康檢查請求的路由：

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

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

定義自定義條件

您能夠設置響應必須知足的自定義條件，以便服務器經過運行情況檢查。條件在match塊中定義，該塊match在health_check指令的參數中引用。

1. 在 http {} 級別，指定 match {} 塊併爲其命名，例如：'server_ok'

http {
    #...

    match server_ok {
        # tests are here
        
    }
}

1. 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。

不少很好的特性，就是須要 Nginx Plus 才能使用。

順道推薦幾個質量不錯的小冊 → 去看看