從理論到案例，請收下這篇Nginx監控運維乾貨

導語

作為Web伺服器，Nginx不免要與Apache進行比較。相比Apache伺服器，Nginx因其採用的非同步非阻塞工作模型，使其具備高併發、低資源消耗的特性，高度模組化設計使Nginx具備很好的擴充套件性；在處理靜態檔案、反向代理請求等方面，Nginx表現出很大的優勢。

Nginx可以作為反向代理伺服器來轉發使用者請求；並能夠在處理請求的過程中實現後端例項負載均衡，實現分發請求的功能；也可將Nginx配置為本地靜態伺服器，處理靜態請求。

監控指標梳理

Nginx處理請求的全過程應被監控起來，以便我們及時發現服務是否能夠正常運轉。Nginx處理請求的過程被詳細地記錄在access.log以及error.log檔案中，我們給出以下（表1）需要監控的關鍵指標：

表1 關鍵指標

監控實踐

從延遲、錯誤、流量以及飽和度四個指標對Nginx監控實踐進行說明。

延遲監控：延遲監控主要關注對$request_time的監控，並繪製tp指標圖，來確認tp99指標值。另外，我們還可以增加對$upstream_response_time指標的監控，來輔助定位延遲問題的原因。圖1展示了過去15min內Nginx處理使用者請求的時間，可以看出使用者90%的請求可以在0.1s內處理完成，99%的請求可以在0.3s內完成。根據tp指標值，並結合具體業務對延遲的容忍度，來設定延遲的報警閾值。

圖1 tp指標

錯誤監控：Nginx作為web伺服器，不但要對Nginx本身執行狀態進行監控，還必須對Nginx的各類錯誤響應進行監控，HTTP錯誤狀態碼以及error.log中記錄的錯誤詳細日誌都應被監控起來以協助解決問題。

（1）基於HTTP語義的Nginx埠監控

單純的Nginx埠監控無法反映服務真實執行狀態，我們要關注的是Nginx本身存活以及是否可以正常提供服務；基於我們的實踐，我們推薦用語義監控代替埠監控，即從Nginx本機以的方式進行訪問，校驗返回的資料格式、內容及HTTP狀態碼是否符合預期。

（2）錯誤碼監控

必須新增對諸如500/502/504等5xx服務類錯誤狀態碼的監控，它們告訴我們服務本身出現了問題；5xx類錯誤每分鐘出現的頻率應該在個位數，太多的5xx應及時排查問題並解決。4xx類錯誤，在協助解決一些非預期的許可權錯誤、資源丟失或效能等問題上可以給予幫助；可以選擇性得對301/302重定向類監控，應對特殊配置跳轉的監控，如後端伺服器返回5xx後，Nginx配置重定向跳轉並返回跳轉後的請求結果。

圖2 狀態碼監控

（3）對錯誤日誌監控

Nginx內部實現了對請求處理錯誤的詳細記錄，並儲存在error.log檔案中。錯誤型別有很多種，我們主要針對關鍵的、能體現服務端異常的錯誤進行採集並監控，以協助我們進行故障定位：

表2 錯誤日誌資訊

流量監控：（1）Nginx所接受請求總量的監控。關注流量波動週期，並捕獲流量突增、突降的情況；通常穩態下流量低峰和高峰浮動20%需要關注下原因；對於有明顯波動週期的服務，我們也可以採用同環比增漲/降低的告警策略，來及時發現流量的變化；圖3為京東雲某平臺一週內的流量波動圖，流量存在明顯低峰和高峰並有天級別的週期性，基於網站執行特性，根據低峰、高峰的值來監控網站流量的波動，並透過自身的監控儀表盤配置網站關鍵頁面的流量圖（圖4），以協助故障排查。

圖3 pv流量圖

圖4 關鍵流量圖

（2）對網路卡IO等機器級別流量的進行監控，可以及時發現伺服器硬體負載的壓力，當Nginx被用於搭建檔案伺服器時，此監控指標需要我們尤為關注。

圖5 網路卡流量圖

飽和度監控：Google SRE中提到，飽和度應關注服務對資源的利用率以及服務在當前執行情況下還可以承受多少負載。Nginx是低資源消耗的高效能伺服器，但諸如在電商場景下，新產品搶購則會在短時間內造成cpu利用率、請求連線數、磁碟寫入的飆升；cpu利用率還要考慮透過worker_cpu_affinity繫結worker程式到特定cpu核心的使用情況，處理高流量時，該配置可以減少cpu切換的效能損耗。

Nginx可以接受的最大連線數在配置檔案nginx.conf中由worker_processes和worker_connections 兩個引數的乘積決定；透過Nginx自帶的模組http_stub_status_module 可以對Nginx的實時執行資訊（圖6）進行監控：

圖6

因我們更關心當前Nginx執行情況，不對已處理的請求做過多關注，所以我們只對如下指標進行採集監控：

表3 指標含義

基於開源軟體搭建Nginx視覺化

（1）採用Elasticsearch+Logstash+Kibana搭建視覺化日誌監控

針對以上四個監控黃金指標，搭建的ELK棧儀表盤，設定常用的Nginx日誌過濾規則（圖8），以便可以快速定位分析問題

圖7 ELK棧架構圖

圖8 ELK儀表盤

（2）採用

Kibana+Elasticsearch+Rsyslog+Grafana

搭建視覺化日誌監控

相較於kibana能快速地對日誌進行檢索，Grafana則在資料展示方面體現了更多的靈活性，某些情況下二者可以形成互補。

圖 9 Grafana視覺化架構圖

圖10 Grafana儀表盤

我們在實踐中實現上述兩種架構的Nginx日誌視覺化監控；從需求本身來講，ELK棧模型可以提供實時的日誌檢索，各種日誌規則的過濾和資料展示，基本可以滿足Nginx日誌監控的需求；Grafana架構模型無法進行日誌檢索和瀏覽，但提供了角色許可權的功能，來防護一些敏感資料的訪問；另外，Grafana更為豐富的圖表型別和資料來源支援，使其具有更多的應用場景。

案例1：大流量衝擊

問題：某平臺，進行了一次新產品的搶購活動。活動期間因流量飆升導致商品詳情頁、下單等核心功能處理耗時增加的情況。

圖 11 PV飆升圖

解決：訂單監控及Nginx的PV、請求時間等監控指標發出報警後，運維人員迅速透過自建的ELK監控儀表盤，關注網站流量變化,檢視使用者請求top IP、top URL;發現存在大量黃牛的惡意搶購行為，導致服務後端處理延時。因此，我們透過降低高防產品、Nginx限流配置中相關介面防攻擊閾值，及時攔截了對系統負載造成壓力的刷單行為，保障了新品促銷活動順利開展。

案例2：Nginx錯誤狀態碼警示服務異常

問題:某平臺進行後端伺服器調整，某個Nginx 的upstream指向的後端伺服器配置錯誤，指向了一個非預期的後端服務；當錯誤的配置被髮布到線上後，網站開始出現機率性的異常，並伴有500和302錯誤狀態碼數量的飆升。

圖12 302錯誤碼統計

解決：Nginx錯誤狀態碼告警後，透過ELK平臺過濾302錯誤碼下使用者請求的URL，發現請求錯誤的URL均與後端的某個模組相關，該請求都被重定向到了網站首頁；進一步定位發現，某臺Nginx的指向了錯誤的後端伺服器，導致伺服器返回大量500錯誤，但因Nginx配置中對500錯誤做了重定向，並因此產生了很多302狀態碼；在後續改進中，我們透過升級Nginx，採用openresty+lua方式來對後端伺服器進行健康監測（圖13），以動態更新upstream中的server，可以快速摘除異常的後端伺服器，達到快速止損的目的。

圖13 配置upstream健康監測

案例3：nginx伺服器磁碟空間耗盡導致服務異常

問題：Nginx作為圖片伺服器前端，某天其中一例項在生產環境無任何變更的情況下收到報警提示：500狀態碼在整體流量中佔比過高。

解決：快速將此機器從生產環境中摘除，不再提供服務；

經排查nginx錯誤日誌發現如下報錯“open() "/home/work/upload/client_body_temp/0000030704" failed (28: No space left on device)”；

Nginx處理請求時，會將客戶端POST長度超過client_body_buffer_size請求的部分或者全部內容暫存到client_body_temp_path目錄，當磁碟空間被佔滿時，產生了以上的報錯；

最終，我們確認了本次異常是產品後升級支援上傳的圖片大小由15MB改為50MB，並且運營方進行了新產品推廣活動，使用者上傳圖片量激增快速打滿磁碟空間所致。