首頁 資訊 nginx中健康檢查(health

nginx中健康檢查(health

來源:泰然健康網(wǎng) 時間:2024年12月04日 01:22

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

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

worker_processes 1; 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; } }

}

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

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

我們查看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中設(shè)置睡眠10分鐘,這是因為我們的業(yè)務(wù)中需要做緩存預(yù)熱,所以這10分鐘就是模擬服務(wù)器啟動過程中有10分鐘的不可用。)

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

等待40s,現(xiàn)在把9090這臺服務(wù)器啟動完成,但是9191這臺服務(wù)器仍然是正在啟動,觀察nginx日志表現(xiàn)。

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"

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

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

相關(guān)知識

Nginx被動健康檢查和主動健康檢查
Oracle健康監(jiān)控及健康檢查(Health Monitor)
Health Matters vBlog – Alternative health news testimonials...
spring boot 應(yīng)用在 k8s 中的健康檢查(一)
《口腔健康調(diào)查 檢查方法》標(biāo)準(zhǔn)解讀
“Public Health”應(yīng)譯為“公共健康”
健康檢查動起來
國際旅行健康檢查證明書
華為運動健康app最新版本(huawei health)
查找: 關(guān)鍵字=health culture

網(wǎng)址: nginx中健康檢查(health http://m.u1s5d6.cn/newsview249583.html

推薦資訊