nginx中健康檢查(health_check)機制深入分析

HmyBmny 發布于2019-07-25 13:27 / 1315人閱讀

摘要：很多人都知道可以做反向代理和負載均衡，但是關于的健康檢查機制了解的不多。觀察日志發現在兩臺啟動過程中，發送一次請求，會自動幫我們進行重試所有的后端服務器，最后會報錯誤。

很多人都知道nginx可以做反向代理和負載均衡，但是關于nginx的健康檢查(health_check）機制了解的不多。其實社區版nginx提供的health_check機制其實很薄弱，主要是通過在upstream中配置max_fails和fail_timeout來實現，這邊文章主要是深入分析社區版的health_check機制，當然還有更好的一些建議，比如商業版的nginx plus或者阿里的tengine,他們包含的健康檢查機制更加完善和高效，如果你堅持使用nginx社區版，當然還可以自己寫或者找第三方模塊來編譯了。

首先說下我的測試環境，CentOS release 6.4 (Final) + nginx_1.6.0 + 2臺tomcat8.0.15作為后端服務器。（聲明:以下所有配置僅僅為測試所用，不代表線上環境真實所用，真正的線上環境需要更多配置和優化。）
nginx配置如下:

#user  nobody;
worker_processes  1;
#pid        logs/nginx.pid;
events {
worker_connections  1024;
}

http {
include       mime.types;
default_type  application/octet-stream;

log_format  main  "$remote_addr - $remote_user [$time_local] "$request" "
                  "$status $body_bytes_sent "$http_referer" "
                  ""$http_user_agent" "$http_x_forwarded_for"";

access_log  logs/access.log  main;

sendfile        on;
keepalive_timeout  65;
upstream backend {
    server localhost:9090 max_fails=1 fail_timeout=40s;
    server localhost:9191 max_fails=1 fail_timeout=40s;
}
server {
    listen       80;
    server_name  localhost;
    location / {
        proxy_pass http://backend;
        proxy_connect_timeout 1;
        proxy_read_timeout 1;
    }
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   html;
    }   
}

}

關于nginx和tomcat的配置的基本配置不再說明，大家可以去看官方文檔。
我們可以看到我在upstream 指令中配置了兩臺server,每臺server都設置了max_fails和fail_timeout值。

現在開始啟動nginx，然后啟動后臺的2臺server, 故意把在Tomcat Listener中Sleep 10分鐘，也就是tomcat啟動要花費10分鐘左右，端口已開，但是沒有接收請求,然后我們訪問http://localhost/response/ (response這個接口是我在tomcat中寫的一個servlet接口，功能很簡單，如果是9090的server接收請求則返回9090，如果是9191端口的server則返回9191.),現在觀察nginx的表現。

我們查看nginx中

access.log

192.168.42.254 - - [29/Dec/2014:11:24:23 +0800] "GET /response/ HTTP/1.1" 504 537 720 380 "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36" 2.004 host:health.iflytek.com
192.168.42.254 - - [29/Dec/2014:11:24:24 +0800] "GET /favicon.ico HTTP/1.1" 502 537 715 311 "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36" 0.000 host:health.iflytek.com

error.log

2014/12/29 11:24:22 [error] 6318#0: *4785892017 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.42.254, server: health.iflytek.com, request: "GET /response/ HTTP/1.1", upstream: "http://192.168.42.249:9090/response/", host: "health.iflytek.com"
2014/12/29 11:24:23 [error] 6318#0: *4785892017 upstream timed out (110: Connection timed out) while reading response header from upstream, client:     192.168.42.254, server: health.iflytek.com, request: "GET /response/ HTTP/1.1", upstream: "http://192.168.42.249:9191/response/", host: "health.iflytek.com"
2014/12/29 11:24:24 [error] 6318#0: *4785892017 no live upstreams while connecting to upstream, client: 192.168.42.254, server: health.iflytek.com, request: "GET /favicon.ico HTTP/1.1", upstream: "http://health/favicon.ico", host: "health.iflytek.com"

（為什么要在listener中設置睡眠10分鐘，這是因為我們的業務中需要做緩存預熱，所以這10分鐘就是模擬服務器啟動過程中有10分鐘的不可用。）

觀察日志發現在兩臺tomcat啟動過程中，發送一次請求，nginx會自動幫我們進行重試所有的后端服務器，最后會報 no live upstreams while connecting to upstream錯誤。這也算是nginx做health_check的一種方式。這里需要特別強調一點，我們設置了proxy_read_timeout 為 1秒。后面再重點講解這個參數，很重要。

等待40s,現在把9090這臺服務器啟動完成，但是9191這臺服務器仍然是正在啟動，觀察nginx日志表現。

access.log

192.168.42.254 - - [29/Dec/2014:11:54:18 +0800] "GET /response/ HTTP/1.1" 200 19 194 423 "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36" 0.210 host:health.iflytek.com
192.168.42.254 - - [29/Dec/2014:11:54:18 +0800] "GET /favicon.ico HTTP/1.1" 404 453 674 311 "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36" 0.212 host:health.iflytek.com

error.log

沒有打印任何錯誤

瀏覽器返回9090,說明nginx正常接收請求。

我們再次請求一次。

access.log

192.168.42.254 - - [29/Dec/2014:13:43:13 +0800] "GET /response/ HTTP/1.1" 200 19 194 423 "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36" 1.005 host:health.iflytek.com

說明正常返回，同時返回9090

error.log

2014/12/29 13:43:13 [error] 6323#0: *4801368618 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.42.254, server: health.iflytek.com, request: "GET /response/ HTTP/1.1", upstream: "http://192.168.42.249:9191/response/", host: "health.iflytek.com"

發現nginx error.log 增加了一行upstream time out的錯誤。但是客戶端仍然正常返回，upstream默認是輪訓的負載，所以這個請求默認會轉發到9191這臺機器，但是因為9191正在啟動，所以這次請求失敗，然后有nginx重試轉發到9090機器上面。

OK，但是fail_timeout=40s是什么意思呢？我們要不要重現一下這個參數的重要性？Let"s go !
現在你只需要靜靜的做個美男子，等待9191機器啟動完畢！多發送幾次請求！然后咦,你發現9191機器返回9191響應了噢！fail_timeout=40s其實就是如果上次請求發現9191無法正常返回，那么有40s的時間該server會不可用，但是一旦超過40s請求也會再次轉發到該server上的，不管該server到底有沒有真正的恢復。所以可見nginx社區版的health_check機制有多么的薄弱啊，也就是一個延時屏蔽而已，如此周而復始！如果你用過nginx plus其實你會發現nginx plus 提供的health_check機制更加強大，說幾個關鍵詞，你們自己去查! zone slow_start health_check match ! 這個slow_start其實就很好的解決了緩存預熱的問題，比如nginx發現一臺機器重啟了，那么會等待slow_starts設定的時間才會再次發送請求到該服務器上，這就給緩存預熱提供了時間。

GPU云服務器云服務器容器健康檢查健康檢查地址健康檢查方式健康檢查原理

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/39118.html

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

摘要：服務器被標記為不健康，并且在再次通過運行狀況檢查之前不會向其發送客戶端請求。對于上面聲明的樣本組中的第一個服務器，運行狀況檢查會請求。響應必須滿足塊中定義的所有條件，以便服務器通過運行狀況檢查。原文鏈接：何曉東博客翻譯自官方文檔被動檢查對于被動健康檢查，NGINX 和 NGINX Plus 會在事件發生時對其進行監控，并嘗試恢復失敗的連接。如果仍然無法恢復正常，NGINX...

animabear 2019-07-01 12:48 評論0 收藏0
Nginx http運行狀況健康檢查配置

摘要：服務器被標記為不健康，并且在再次通過運行狀況檢查之前不會向其發送客戶端請求。對于上面聲明的樣本組中的第一個服務器，運行狀況檢查會請求。響應必須滿足塊中定義的所有條件，以便服務器通過運行狀況檢查。原文鏈接：何曉東博客翻譯自官方文檔被動檢查對于被動健康檢查，NGINX 和 NGINX Plus 會在事件發生時對其進行監控，并嘗試恢復失敗的連接。如果仍然無法恢復正常，NGINX...

daydream 2019-07-25 14:45 評論0 收藏0
nginx的upstream異常

摘要：異常與默認值為默認值為秒。實驗請求里頭的會發起一個，請求請求一次對逐個請求，都失敗，則的返回，對返回的取決于腳本再請求一次該下面的都掛的情況下出現中健康檢查機制深入分析容錯機制原創胡志廣線上的一次分析異常 upstream server temporarily disabled while connecting to upstream no live upstreams while...

kun_jian 2019-07-25 13:52 評論0 收藏0
nginx做負載均衡器以及proxy緩存配置

摘要：這個指令屬于模塊的，指定后端返回什么樣的異常響應時，使用另一個是專門提供負載均衡器內節點的健康檢查的外部模塊，由淘寶的姚偉斌大神開發，通過它可以用來檢測后端的健康狀態。關于nginx的安裝和基本配置請參考nginx，本文在原基礎上完成以下幾個功能：結合proxy和upstream模塊實現nginx負載均衡結合nginx_upstream_check_module模塊實現后端服...

Moxmi 2019-07-25 13:32 評論0 收藏0

發表評論

登陸后可評論

0條評論

HmyBmny

男|高級講師

我要關注我要私信

TA的文章

tensorflow搭建卷積神經網絡

閱讀 671·2023-04-25 18:59
虛擬主機可以做什么-虛擬主機是什么概念？

閱讀 1211·2021-09-22 16:00
如何遠程云主機ip-云主機怎么遠程操作？

閱讀 1889·2021-09-22 15:42
什么叫云主機-云主機是什么？

閱讀 3594·2021-09-22 15:27
css--下拉菜單

閱讀 1246·2019-08-30 15:54
2019年7月所遇知識點整理

閱讀 1104·2019-08-30 11:16
關于sass、scss、less的概念性知識匯總

閱讀 2445·2019-08-29 16:24
orderBy排序與篩選的例子

閱讀 820·2019-08-29 12:14

国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

上云采購季！| 2核2G4M爆款云服務器低至59元/年，更有多臺、長期優惠，快來選購！

nginx中健康檢查(health_check)機制深入分析

相關文章

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

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

nginx的upstream異常

nginx做負載均衡器以及proxy緩存配置

發表評論

0條評論

HmyBmny

男|高級講師

TA的文章

tensorflow搭建卷積神經網絡

虛擬主機可以做什么-虛擬主機是什么概念？

如何遠程云主機ip-云主機怎么遠程操作？

什么叫云主機-云主機是什么？

css--下拉菜單

2019年7月所遇知識點整理

關于sass、scss、less的概念性知識匯總

orderBy排序與篩選的例子

最新活動

資訊專欄INFORMATION COLUMN

上云采購季！| 2核2G4M爆款云服務器低至59元/年，更有多臺、長期優惠，快來選購！

nginx中健康檢查(health_check)機制深入分析

相關文章

發表評論

0條評論

男|高級講師

TA的文章

最新活動

上云采購季！| 2核2G4M爆款云服務器低至59元/年，更有多臺、長期優惠，快來選購！