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