Nginx是一個開源、免費、高性能的HTTP和反向代理服務器，也可以用於IMAP/POP3代理服務器。充分利用Nginx的特性，可以有效解決流量高並發請求、cc攻擊等問題。
本文探討了電商場景下Nginx的監控方案，並將使用過程中遇到的問題和解決方案與大家一起分享。
一、對於Nginx你一定了解的基礎
1、特性
作為Web服務器，Nginx不免要與Apache進行比較。相比Apache服務器，Nginx因其采用的異步非阻塞工作模型，使其具備高並發、低資源消耗的特性，高度模塊化設計使Nginx具備很好的擴展性；在處理靜態文件、反向代理請求等方面，Nginx表現出很大的優勢。
2、常見的使用方式
Nginx可以作為反向代理服務器來轉發用戶請求；並能夠在處理請求的過程中實現后端實例負載均衡，實現分發請求的功能；也可將Nginx配置為本地靜態服務器，處理靜態請求。
二、對於Nginx你需要懂得的監控
1、監控指標梳理
Nginx處理請求的全過程應被監控起來，以便我們及時發現服務是否能夠正常運轉。Nginx處理請求的過程被詳細地記錄在access.log以及error.log文件中，我們給出以下需要監控的關鍵指標：
2、監控實踐
從延遲、錯誤、流量以及飽和度四個指標對Nginx監控實踐進行說明。
延遲監控：
延遲監控主要關注對$request_time的監控，並繪制tp指標圖，來確認tp99指標值。另外，我們還可以增加對$upstream_response_time指標的監控，來輔助定位延遲問題的原因。
下圖展示了過去15min內Nginx處理用戶請求的時間：
可以看出用戶90%的請求可以在0.1s內處理完成，99%的請求可以在0.3s內完成。根據tp指標值，並結合具體業務對延遲的容忍度，來設置延遲的報警閾值。
錯誤監控：
Nginx作為web服務器，不但要對Nginx本身運行狀態進行監控，還必須對Nginx的各類錯誤響應進行監控，HTTP錯誤狀態碼以及error.log中記錄的錯誤詳細日志都應被監控起來以協助解決問題。
1）基於HTTP語義的Nginx端口監控
單純的Nginx端口監控無法反映服務真實運行狀態，我們要關注的是Nginx本身存活以及是否可以正常提供服務；基於我們的實踐，我們推薦用語義監控代替端口監控，即從Nginx本機以http://local_ip:port/的方式進行訪問，校驗返回的數據格式、內容及HTTP狀態碼是否符合預期。
2）錯誤碼監控
必須添加對諸如500/502/504等5xx服務類錯誤狀態碼的監控，它們告訴我們服務本身出現了問題。
5xx類錯誤每分鍾出現的頻率應該在個位數，太多的5xx應及時排查問題並解決；4xx類錯誤，在協助解決一些非預期的權限錯誤、資源丟失或性能等問題上可以給予幫助；可以選擇性得對301/302重定向類監控，應對特殊配置跳轉的監控，如后端服務器返回5xx后，Nginx配置重定向跳轉並返回跳轉后的請求結果。
狀態碼監控
3）對錯誤日志監控
Nginx內部實現了對請求處理錯誤的詳細記錄，並保存在error.log文件中。錯誤類型有很多種，我們主要針對關鍵的、能體現服務端異常的錯誤進行采集並監控，以協助我們進行故障定位：
錯誤日志信息
流量監控：
1）Nginx所接受請求總量的監控
關注流量波動周期，並捕獲流量突增、突降的情況；通常穩態下流量低峰和高峰浮動20%需要關注下原因；對於有明顯波動周期的服務，我們也可以采用同環比增漲/降低的告警策略，來及時發現流量的變化。
下圖為京東雲某平台一周內的流量波動圖：
pv流量圖
流量存在明顯低峰和高峰並有天級別的周期性，基於網站運行特性，根據低峰、高峰的值來監控網站流量的波動，並通過自身的監控儀表盤配置網站關鍵頁面的流量圖，以協助故障排查：
關鍵流量圖
2）對網卡IO等機器級別流量的進行監控
可以及時發現服務器硬件負載的壓力，當Nginx被用於搭建文件服務器時，此監控指標需要我們尤為關注。
網卡流量圖
飽和度監控：
Google SRE中提到，飽和度應關注服務對資源的利用率以及服務在當前運行情況下還可以承受多少負載。
Nginx是低資源消耗的高性能服務器，但諸如在電商場景下，新產品搶購則會在短時間內造成cpu利用率、請求連接數、磁盤寫入的飆升；cpu利用率還要考慮通過worker_cpu_affinity綁定worker進程到特定cpu核心的使用情況，處理高流量時，該配置可以減少cpu切換的性能損耗。
Nginx可以接受的最大連接數在配置文件nginx.conf中由worker_processes和worker_connections 兩個參數的乘積決定；通過Nginx自帶的模塊http_stub_status_module 可以對Nginx的實時運行信息進行監控：
因我們更關心當前Nginx運行情況，不對已處理的請求做過多關注，所以我們只對如下指標進行采集監控：
指標含義
三、基於開源軟件搭建Nginx可視化監控系統
1、采用Elasticsearch + Logstash + Kibana搭建可視化日志監控
針對以上四個監控黃金指標，搭建的ELK棧儀表盤，設置常用的Nginx日志過濾規則，以便可以快速定位分析問題：
ELK棧架構圖
ELK儀表盤
2）采用Kibana + Elasticsearch + Rsyslog + Grafana搭建可視化日志監控
相較於kibana能快速地對日志進行檢索，Grafana則在數據展示方面體現了更多的靈活性，某些情況下二者可以形成互補：
Grafana可視化架構圖
Grafana儀表盤
我們在實踐中實現上述兩種架構的Nginx日志可視化監控：
-
從需求本身來講，ELK棧模型可以提供實時的日志檢索，各種日志規則的過濾和數據展示，基本可以滿足Nginx日志監控的需求；
-
Grafana架構模型無法進行日志檢索和瀏覽，但提供了角色權限的功能，來防護一些敏感數據的訪問；
-
另外，Grafana更為豐富的圖表類型和數據源支持，使其具有更多的應用場景。
四、基於Nginx監控發現並定位問題案例
案例1：大流量沖擊
問題：某平台，進行了一次新產品的搶購活動。活動期間因流量飆升導致商品詳情頁、下單等核心功能處理耗時增加的情況：
PV飆升圖
解決：訂單監控及Nginx的PV、請求時間等監控指標發出報警后，運維人員迅速通過自建的ELK監控儀表盤，關注網站流量變化，查看用戶請求top IP、top URL；發現存在大量黃牛的惡意搶購行為，導致服務后端處理延時。因此，我們通過降低高防產品、Nginx限流配置中相關接口防攻擊閾值，及時攔截了對系統負載造成壓力的刷單行為，保障了新品促銷活動順利開展。
案例2：Nginx錯誤狀態碼警示服務異常
問題：某平台進行后端服務器調整，某個Nginx的upstream指向的后端服務器配置錯誤，指向了一個非預期的后端服務；當錯誤的配置被發布到線上后，網站開始出現概率性的異常，並伴有500和302錯誤狀態碼數量的飆升。
302錯誤碼統計
解決：Nginx錯誤狀態碼告警后，通過ELK平台過濾302錯誤碼下用戶請求的URL，發現請求錯誤的URL均與后端的某個模塊相關，該請求都被重定向到了網站首頁；進一步定位發現，某台Nginx的指向了錯誤的后端服務器，導致服務器返回大量500錯誤，但因Nginx配置中對500錯誤做了重定向，並因此產生了很多302狀態碼。
在后續改進中，我們通過升級Nginx，采用openresty+lua方式來對后端服務器進行健康監測，以動態更新upstream中的server，可以快速摘除異常的后端服務器，達到快速止損的目的：
配置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，並且運營方進行了新產品推廣活動，用戶上傳圖片量激增快速打滿磁盤空間所致