控Nginx：stub_status+UserParameter配置實戰(zhàn)指南)
Nginx 監(jiān)控這件事很多人一開始想復雜了。Zabbix 要拿到 Nginx 的運行狀態(tài)并不需要裝額外探針也不一定非要解析訪問日志最穩(wěn)定的入口其實是 Nginx 自帶的 stub_status 狀態(tài)頁。只要把它打開再用 Zabbix Agent 把里面的幾個數(shù)字讀回來就能完成請求量、并發(fā)連接、讀寫狀態(tài)的監(jiān)控再配上觸發(fā)器和圖形連接數(shù)異常、請求速率突變這些情況都能直接看到。這篇內(nèi)容按實際落地順序來拆先講 Nginx 狀態(tài)頁每個字段是什么意思再講怎么讓 Zabbix Agent 把數(shù)據(jù)采回來然后是 Zabbix 前端里的監(jiān)控項、觸發(fā)器和圖形怎么配最后做一輪實測把請求打起來再去看統(tǒng)計結(jié)果怎么解讀。適合剛接觸 Zabbix 監(jiān)控 Nginx 的人也適合已經(jīng)在用 shell 腳本采集、但想轉(zhuǎn)成 Zabbix 規(guī)范化監(jiān)控的人。1. 先搞清楚 nginx 狀態(tài)頁Zabbix 監(jiān)控 Nginx 的數(shù)據(jù)從哪來1.1 stub_status 輸出字段對照Zabbix 監(jiān)控 Nginx底層數(shù)據(jù)源不是日志而是 Nginx 自己維護的計數(shù)器。只要在 Nginx 配置里啟用 stub_status訪問狀態(tài)頁就能看到一小段純文本Active connections: 291 server accepts handled requests 16630948 16630948 31070465 Reading: 6 Writing: 179 Waiting: 106這段文本雖然短但每個字段都有明確含義。字段含義類型Active connections當前活動連接數(shù)瞬時值acceptsNginx 啟動以來累計接受的客戶端連接總數(shù)累計值handled成功處理的連接總數(shù)累計值requests累計處理的客戶端請求總數(shù)累計值Reading正在讀取請求頭的連接數(shù)瞬時值Writing正在讀取請求體、處理請求或?qū)戫憫倪B接數(shù)瞬時值Waiting空閑的 keep-alive 連接數(shù)瞬時值第一行Active connections是當前活動連接數(shù)。注意它包含后面 Reading、Writing、Waiting 三類的總和所以只要 Nginx 活著這個數(shù)值通常不會是 0。第二行是固定表頭server accepts handled requests。第三行的三個數(shù)字分別對應表頭都是只增不減的累計計數(shù)器只有 Nginx 重啟才會歸零。第四行的 Reading、Writing、Waiting 是三個瞬時值。一個請求從進入到結(jié)束通常會依次經(jīng)過 Reading、Writing 兩個階段最后進入 Waiting或者直接關閉連接。這幾個字段之間的換算關系是Active connections Reading Writing Waiting。理解這個關系后面看圖形和觸發(fā)器才不會被數(shù)字騙到。1.2 哪些指標值得接進 Zabbix不是每個字段都必須接進來但下面這幾個我建議至少都要有。請求速率是最核心的指標對應 requests 計數(shù)器看的是單位時間內(nèi)處理了多少請求也就是平時說的 QPS。只看累計值沒有意義必須換算成速率。新建連接速率對應 accepts 計數(shù)器看的是單位時間內(nèi)來了多少新連接。這個值和 QPS 的區(qū)別在于keep-alive 生效的情況下一個連接上可以連續(xù)發(fā)多個請求所以請求速率通常遠大于連接速率。當前并發(fā)連接數(shù)對應 Active connections是最直觀的負載指標。但它不能單獨說明問題必須結(jié)合 Reading、Writing、Waiting 一起看。Reading 如果持續(xù)偏高說明有一些客戶端請求頭發(fā)得很慢或者請求頭一直沒發(fā)完。Writing 持續(xù)偏高說明 Nginx 正在大量往客戶端寫響應這時候要關注帶寬和上游服務能不能跟上。Waiting 高反而是正?，F(xiàn)象說明大量連接是空閑 keep-alive對靜態(tài)資源或高并發(fā) Web 服務很常見。把這些字段全部接進 Zabbix才算真正把 Nginx 的運行狀態(tài)看完整。2. 環(huán)境準備與最小配置讓 Nginx 先吐出狀態(tài)數(shù)據(jù)2.1 確認 Nginx 是否支持 stub_statusstub_status 不是所有 Nginx 都默認包含。編譯 Nginx 時如果沒有加--with-http_stub_status_module這個功能就不存在配置寫了也會報錯。先檢查當前 Nginx 有沒有這個模塊nginx -V 21 | grep -o http_stub_status_module如果輸出里有http_stub_status_module說明支持。如果沒有有兩個方向重新編譯 Nginx 時加上這個模塊或者換成已經(jīng)默認包含該模塊的發(fā)行版軟件包。很多發(fā)行版和官方倉庫自帶的 Nginx 都已經(jīng)開啟了這個模塊但自編譯版本一定要單獨確認。這里提醒一下執(zhí)行nginx -V時編譯參數(shù)是在標準錯誤輸出里所以我加了21把錯誤輸出重定向到同一路。很多人第一次只看第一行 version以為不支持其實是沒看全。2.2 Nginx 狀態(tài)頁配置示例與安全限制確認模塊存在后在 Nginx 的 server 配置里加一個 location。以下是一份最小配置server { listen 80; server_name _; location /nginx_status { stub_status on; access_log off; allow 127.0.0.1; deny all; } }這里最關鍵的是allow和deny。stub_status 本身沒有任何認證機制任何人能訪問就能看到你的連接數(shù)、請求量和連接狀態(tài)。如果把狀態(tài)頁暴露到公網(wǎng)內(nèi)部運行信息等于公開了。所以默認只允許本機訪問是最穩(wěn)妥的做法。如果你的 Zabbix Agent 和 Nginx 不在同一臺機器上不要直接把deny all刪掉應該改成只允許采集機 IP 訪問location /nginx_status { stub_status on; access_log off; allow 192.168.1.100; deny all; }改完配置先檢查再重載nginx -t nginx -s reloadnginx -t這一步不能省。stub_status 的 location 如果配置在錯誤的上下文里或者和已有配置沖突reload 會直接失敗。2.3 用 curl 驗證狀態(tài)頁是否生效配置完成之后先在 Nginx 所在機器上驗證curl -s http://127.0.0.1/nginx_status如果能看到開頭那段文本說明狀態(tài)頁已經(jīng)可以訪問了。如果返回 404說明 location 沒生效或者配置在了錯誤的 server 塊里。如果返回 403大概率是deny all生效了而你的請求來源 IP 不在allow列表里。這里有個容易忽略的點如果你的 Nginx 不是監(jiān)聽 80 端口或者同時有 HTTPSURL 里要帶上實際協(xié)議和端口例如http://127.0.0.1:8080/nginx_status。先花一分鐘把 curl 這步跑通后面會省很多時間。3. Zabbix Agent 接入一條 UserParameter 和一個監(jiān)控項的關系3.1 安裝與基礎配置 Zabbix AgentZabbix Agent 是部署在 Nginx 所在機器上的采集程序。它的作用和 Nginx 狀態(tài)頁互補狀態(tài)頁負責提供數(shù)據(jù)Agent 負責把數(shù)據(jù)讀出來再交給 Zabbix Server。安裝方式要看你的系統(tǒng)和 Zabbix 版本直接使用官方倉庫安裝 zabbix-agent 即可。裝完需要修改配置文件常見要確認三個參數(shù)Server192.168.1.10 ServerActive192.168.1.10 Hostnameweb01Server是允許給這臺 Agent 下發(fā)被動采集請求的 Zabbix Server 地址。ServerActive是主動上報要連接的 Server 地址。Hostname是 Agent 上報時使用的名字在 Zabbix 前端添加主機時要保持一致特別是主動檢查時Hostname 對不上會直接導致數(shù)據(jù)丟失。這里解釋一下被動檢查和主動檢查的區(qū)別。被動檢查是 Zabbix Server 主動連接 Agent 的 10050 端口要數(shù)據(jù)主動檢查是 Agent 主動連接 Server 的 10051 端口上報數(shù)據(jù)。自定義 UserParameter 兩種方式都支持但排查問題時的思路不一樣后面會詳細說。改完配置啟動服務systemctl restart zabbix-agent systemctl status zabbix-agent3.2 通過 UserParameter 把 nginx_status 轉(zhuǎn)成監(jiān)控項Zabbix Agent 默認不認識 nginx 的 key需要通過 UserParameter 來定義。UserParameter 的格式很簡單一個 key一個命令Agent 執(zhí)行命令把標準輸出作為監(jiān)控值返回。在/etc/zabbix/zabbix_agentd.d/目錄下創(chuàng)建一個 nginx.conf寫入以下內(nèi)容UserParameternginx.active,/usr/bin/curl -s --max-time 3 http://127.0.0.1/nginx_status | awk /Active connections/{print $3} UserParameternginx.accepts,/usr/bin/curl -s --max-time 3 http://127.0.0.1/nginx_status | awk NR3{print $1} UserParameternginx.handled,/usr/bin/curl -s --max-time 3 http://127.0.0.1/nginx_status | awk NR3{print $2} UserParameternginx.requests,/usr/bin/curl -s --max-time 3 http://127.0.0.1/nginx_status | awk NR3{print $3} UserParameternginx.reading,/usr/bin/curl -s --max-time 3 http://127.0.0.1/nginx_status | awk /Reading/{print $2} UserParameternginx.writing,/usr/bin/curl -s --max-time 3 http://127.0.0.1/nginx_status | awk /Writing/{print $4} UserParameternginx.waiting,/usr/bin/curl -s --max-time 3 http://127.0.0.1/nginx_status | awk /Waiting/{print $6}逐個拆一下。每行都是一個 key例如nginx.active。后面的命令先用 curl 抓取狀態(tài)頁再用 awk 提取對應字段。awk 的寫法要特別注意。第三行的 accepts、handled、requests 是三個連續(xù)數(shù)字所以分別用NR3定位到第三行再打印第 1、2、3 列。Reading、Writing、Waiting 在同一行里所以要先用正則匹配到這一行再打印對應列。Writing 是第 4 列Waiting 是第 6 列這個順序很多人會弄錯。命令里的--max-time 3不是隨便加的。如果狀態(tài)頁異常導致 curl 一直掛住Agent 執(zhí)行這個 UserParameter 就會卡住嚴重時會占滿 Agent 的檢查線程影響這臺機器上的其他監(jiān)控項。加上超時時間最壞 3 秒也會退出。改完配置后重啟 Agentsystemctl restart zabbix-agent3.3 先用 zabbix_get 還是前端測試功能配置完 UserParameter不要急著去 Zabbix 前端創(chuàng)建主機先在命令行驗證一遍 key 能不能查到值。在有 zabbix-get 工具的機器上執(zhí)行它通常在 Zabbix Server 或 Proxy 上zabbix_get -s 192.168.1.20 -k nginx.requests返回一個數(shù)字說明這條鏈路通了。如果提示 Not supported 或者沒有輸出先不要懷疑 Zabbix 配置回到 Nginx 機器上直接執(zhí)行那條 UserParameter 命令看有沒有結(jié)果。這里有個容易踩的坑你手動執(zhí)行命令時用的是 root 用戶而 Zabbix Agent 運行時的用戶通常是 zabbix兩個用戶的環(huán)境變量、權(quán)限、可執(zhí)行路徑可能都不一樣。比如 zabbix 用戶沒有權(quán)限訪問某個目錄或者 SELinux 攔截了 zabbix 用戶執(zhí)行 curl都會導致手動執(zhí)行正常、Agent 執(zhí)行失敗。新版 Zabbix 前端在監(jiān)控項配置里也有一個 Test 按鈕可以直接測試當前主機上的 key返回結(jié)果和報錯更直觀。實際排查時我一般按三個地方順序看Agent 所在機器手動執(zhí)行命令、zabbix_get 從 Server 端測試、前端 Test 按鈕看報錯。4. 創(chuàng)建主機、監(jiān)控項、觸發(fā)器數(shù)據(jù)到告警的完整鏈路4.1 在 Zabbix 前端添加主機與監(jiān)控項命令行驗證通過后進入 Zabbix Web 界面按照 配置 → 主機 → 創(chuàng)建主機 的路徑添加一臺主機。填寫主機名時要注意Agent 配置文件里的 Hostname 和這里的主機名必須一致否則主動檢查會失敗。接口配置里選擇 Agent填寫 Nginx 所在機器的 IP 和默認端口 10050。添加監(jiān)控項有兩條路線。一條是直接鏈接模板Zabbix 模板庫里有 Nginx by HTTP、Nginx by Zabbix agent 2 這類現(xiàn)成模板不同版本的模板數(shù)量和名稱會有差異底層采集方式也是去讀狀態(tài)頁適合不想自己維護 key 的人。另一條是手動創(chuàng)建監(jiān)控項用剛才定義的 UserParameter 鍵值自由度更高也更容易理解每個數(shù)字怎么來的。如果你是第一次做我更建議先手動創(chuàng)建。原因很簡單自動模板會隱藏很多細節(jié)一旦出了問題你很難判斷是狀態(tài)頁的問題、Agent 的問題還是模板映射的問題。手動創(chuàng)建一遍等于把鏈路里的每個環(huán)節(jié)都摸清楚了。手動創(chuàng)建監(jiān)控項時以nginx.requests為例名稱Nginx Requests類型Zabbix Agent鍵值nginx.requests信息類型數(shù)字無正負更新間隔1m 或 30s 都可以歷史數(shù)據(jù)保留7d趨勢數(shù)據(jù)保留365d其他幾個 key 按同樣方法創(chuàng)建。4.2 請求速率、連接數(shù)怎么存儲和計算單位這里要解決一個關鍵問題accepts、handled、requests 這三個字段是累計值直接存進 Zabbix 只能看到一根一直向上的線很難判斷當前請求量到底是多少。所以必須讓 Zabbix 把累計值換算成速率。在 Zabbix 監(jiān)控項配置里有一個字段叫“存儲值”可以選“原樣存儲”“增量簡單變化”和“增量每秒速率”。存儲方式適用場景示例原樣存儲瞬時值當前是多少就存多少active、reading、writing、waiting增量簡單變化累計值的兩次差值accepts 每次變化量增量每秒速率累計值換算成每秒速率requests、accepts、handled對 requests、accepts、handled 這三個累計計數(shù)器應該選擇“增量每秒速率”單位寫成 req/s 或 conn/s。這樣 Zabbix 會在后臺自動計算兩次采集之間的差值再除以時間間隔得到每秒速率。如果你不想在監(jiān)控項里改存儲方式也可以用預處理步驟里的“每秒更改量”來實現(xiàn)同樣效果。兩者本質(zhì)上是一樣的看你習慣哪種。唯一要注意的是如果 Nginx 在兩次采集之間重啟過計數(shù)器歸零速率可能會出現(xiàn)一次很大的負值或異常值統(tǒng)計圖形上會出現(xiàn)明顯的斷點這是正?，F(xiàn)象不是系統(tǒng)崩潰。active、reading、writing、waiting 這四個瞬時值就保持“原樣存儲”它們的數(shù)值本身就是當前狀態(tài)不需要做速率換算。4.3 觸發(fā)器和告警閾值怎么定監(jiān)控項建好后數(shù)據(jù)會不斷進入 Zabbix但沒人盯著圖形的話異常還是發(fā)現(xiàn)不了。觸發(fā)器的意義就是自動判斷數(shù)值是否超過預期。觸發(fā)器配置路徑是 配置 → 主機 → 觸發(fā)器 → 創(chuàng)建觸發(fā)器。以活躍連接數(shù)為例一個簡單表達式last(/web01/nginx.active)10000含義是當前活躍連接數(shù)大于 10000 時觸發(fā)警告。再比如請求速率min(/web01/nginx.requests,5m)5000含義是最近 5 分鐘請求速率平均值超過 5000 req/s 時觸發(fā)。閾值定多少沒有標準答案取決于你的業(yè)務。我建議先讓 Zabbix 跑兩三天積累一段基線數(shù)據(jù)再根據(jù)圖形里的峰值來定警告和嚴重閾值不要憑感覺拍腦袋。第一次設置可以把閾值放寬一點確認告警鏈路能正常觸發(fā)后再往回收。觸發(fā)器還可以設置恢復表達式也就是數(shù)值降到多少以下時自動恢復為正常。這個最好一起配好否則每次數(shù)值震蕩都會反復觸發(fā)、恢復告警會很吵。要測試告警鏈路的完整效果除了觸發(fā)器還需要配置好動作和通知方式。如果暫時沒配郵件或其他通知也可以先只做觸發(fā)器通過 Zabbix 首頁的告警記錄來確認觸發(fā)是否成功。5. 實測一輪用請求壓一壓再去看統(tǒng)計結(jié)果和圖形5.1 制造流量curl 循環(huán)或 ab 簡單壓測配置完成之后最關鍵的一步就是實測。沒有流量監(jiān)控圖形是一條平線你很難判斷數(shù)據(jù)到底有沒有采集成功。最簡單的測試方法是用 curl 發(fā)一批請求。在 Nginx 機器上執(zhí)行for i in $(seq 1 1000); do curl -s -o /dev/null http://127.0.0.1/; done這個循環(huán)會向本機 Nginx 發(fā)送 1000 次請求每次丟棄響應內(nèi)容。優(yōu)點是環(huán)境干凈不需要額外工具。缺點是速度不夠快產(chǎn)生的請求速率不會特別高。如果你機器上有 ab也就是 ApacheBench可以壓得更明顯一些ab -n 5000 -c 100 -k http://127.0.0.1/這條命令的含義是總共發(fā)送 5000 個請求同時保持 100 個并發(fā)連接-k表示啟用 keep-alive。ab 在測試時會持續(xù)請求能把 Nginx 的請求速率和活躍連接數(shù)明顯拉起來。執(zhí)行的時候建議一次只跑一種跑完等一分鐘讓 Zabbix 完成幾個采集周期再去前端看數(shù)據(jù)。如果立刻去看采集周期還沒到可能什么都看不到。5.2 分析 Latest data 和 Graphs進入 Zabbix 前端的“監(jiān)測 → 最新數(shù)據(jù)”選擇剛才創(chuàng)建的主機就能看到每條監(jiān)控項的當前值。這時候你看到的應該是有具體數(shù)字的綠色狀態(tài)而不是“不支持”或“無數(shù)據(jù)”。以剛才 ab 壓測為例壓測過程中可以看到 requests 數(shù)值沖上去壓測結(jié)束后又會回落。如果配上圖形把請求速率、活躍連接、Reading、Writing、Waiting 放在同一張圖里觀察能很直觀地看到整個請求生命周期的變化。如果你沒有在監(jiān)控項里單獨創(chuàng)建圖形也可以在儀表盤中添加一個圖表組件數(shù)據(jù)源選擇對應主機的監(jiān)控項。Zabbix 的圖表組件支持把多個監(jiān)控項疊加到同一張圖上非常適合對比 Active connections、Reading、Writing、Waiting 這幾個相關指標。5.3 從數(shù)據(jù)反向判斷 Nginx 狀態(tài)是否健康數(shù)據(jù)有了接下來的重點是怎么讀這些數(shù)字。先看 active connections 和 waiting 的關系。如果活躍連接數(shù)很高但 waiting 也很高說明大量連接是空閑 keep-aliveNginx 實際壓力不大只是在維持長連接。如果活躍連接數(shù)高waiting 卻很低說明連接都在真正干活這時候負載才是真的高。再看 accepts 和 handled 的對比。正常情況下這兩個數(shù)值應該非常接近。如果 handled 長期明顯小于 accepts說明有一部分連接沒有被 Nginx 成功處理可能原因是 worker_connections 配置過低連接數(shù)被系統(tǒng)層面拒絕了。通過 Zabbix 監(jiān)控這兩個值的曲線差值能比看錯誤日志更早發(fā)現(xiàn)問題。再看請求速率和連接速率的關系。用 requests 速率除以 accepts 速率可以得到平均每個連接上的請求數(shù)。如果這個值接近 1說明 keep-alive 基本沒起作用客戶端每次請求都新建連接連接效率很低。如果明顯大于 1說明 keep-alive 生效良好一個連接上處理了多個請求。Reading 和 Writing 是更細的觀察點。靜態(tài)資源站點在壓測時Writing 會明顯升高因為 Nginx 正在往客戶端輸出響應。如果 Writing 持續(xù)高位但 requests 并不高可能是網(wǎng)絡帶寬打滿了響應寫不出去。Reading 持續(xù)高位則要小心可能是客戶端請求頭發(fā)送緩慢也可能是存在慢連接這種情況即使活躍連接數(shù)不高worker 也可能被拖住。這些判斷不能只看一兩個采樣點最好結(jié)合 5 分鐘、1 小時的時間窗口來看趨勢。這也是為什么前面建議把趨勢數(shù)據(jù)保留時間設長一些。6. 常見問題排查與生產(chǎn)環(huán)境落地的邊界6.1 Agent 顯示 Not supported 時按什么順序查Zabbix Agent 返回 Not supported 是監(jiān)控 Nginx 時最常遇到的問題。很多人第一反應是去改 Zabbix 配置其實大多數(shù)時候問題出在 Agent 側(cè)。我的排查順序是固定的。第一步直接手動執(zhí)行那條 UserParameter 命令看有沒有輸出。如果命令本身就沒輸出說明狀態(tài)頁、curl、awk 里有一環(huán)斷了。第二步確認執(zhí)行用戶。Zabbix Agent 通常以 zabbix 用戶運行手動用 root 執(zhí)行成功不代表 zabbix 用戶能執(zhí)行。可以用su - zabbix -s /bin/bash -c 命令來模擬 Agent 的執(zhí)行環(huán)境。第三步看 Agent 日志默認在 /var/log/zabbix/zabbix_agentd.log。日志里會記錄 key 對應的錯誤信息比如命令找不到、執(zhí)行超時、權(quán)限不足等。第四步改完 UserParameter 后確認重啟了 Agent。UserParameter 是在 Agent 啟動時讀取的不重啟不會生效。第五步從 Server 端用 zabbix_get 測試連通性。這一步能區(qū)分問題是出在 Agent 執(zhí)行命令還是 Server 與 Agent 之間的網(wǎng)絡、端口、密鑰配置上。還有一個常見問題Linux 有 SELinux 或 AppArmor 環(huán)境時zabbix 用戶執(zhí)行 curl 連接本機端口可能會被攔截。手動執(zhí)行正常Agent 執(zhí)行就是失敗排查到這一步時要看安全審計日志確認是不是被策略攔截了。6.2 狀態(tài)頁不能直接暴露在公網(wǎng)前面配置 Nginx 狀態(tài)頁時寫了 allow 和 deny這個限制在正式環(huán)境同樣重要。stub_status 只有數(shù)據(jù)輸出沒有認證、沒有訪問控制任何人拿到狀態(tài)頁地址就能看到你所有虛擬主機的連接數(shù)、請求量等信息。這些數(shù)據(jù)單獨看不算機密但結(jié)合業(yè)務時序可能暴露促銷活動、低谷期等運營信息。所以生產(chǎn)環(huán)境要遵守幾個原則狀態(tài)頁只監(jiān)聽內(nèi)網(wǎng)地址或只允許內(nèi)網(wǎng)訪問。Zabbix Agent 與 Nginx 部署在一起時直接限制為 127.0.0.1。如果需要遠程采集優(yōu)先讓 Agent 本機讀取不要讓其他機器直接 HTTP 訪問狀態(tài)頁。Nginx 服務本身就開啟了公網(wǎng)監(jiān)聽時更要檢查 allow 列表不要把公網(wǎng)網(wǎng)段放進去。另外狀態(tài)頁建議使用獨立 location不要放在一個會匹配大量路徑的通用規(guī)則里避免被掃描工具順帶發(fā)現(xiàn)。access_log off也要保留否則每個狀態(tài)頁請求都會寫一條訪問日志白白增加磁盤 IO。6.3 多實例和規(guī)范化模板、宏、命名規(guī)則如果只有一臺機器手動創(chuàng)建監(jiān)控項沒什么問題。一旦機器多起來比如七八臺 Nginx 都要監(jiān)控逐臺手動創(chuàng)建就很痛苦而且容易漏配。這時候應該把監(jiān)控項、觸發(fā)器、圖形整理成模板。在模板里創(chuàng)建好 nginx.active、nginx.requests 這些監(jiān)控項和對應的觸發(fā)器再把模板鏈接到主機上所有主機自動繼承配置。后續(xù)要加閾值、加圖形只需要改模板一處所有主機同步生效。模板里的閾值可以做成宏比如{$NGINX_ACTIVE_WARN}、{$NGINX_REQ_HIGH}。這樣在不同業(yè)務機器上可以差異化覆蓋不用復制整個模板。比如 A 機器請求量本來就大警告閾值定 8000B 機器是小業(yè)務閾值定 1000。用宏就能在同一套模板下按主機單獨調(diào)整。key 的命名也要規(guī)范。前面用的 nginx.active、nginx.requests 就是比較清晰的命名方式。如果一臺機器上有多個 Nginx 實例建議在 key 里帶實例編號比如 nginx1.active、nginx2.active避免數(shù)據(jù)串臺。6.4 歷史數(shù)據(jù)保留和監(jiān)控頻率最后聊一下采集頻率和數(shù)據(jù)保留。對 Nginx 監(jiān)控來說30 秒到 1 分鐘的采集間隔已經(jīng)足夠。不要看到別人用 1 秒間隔就覺得越快越好越短的間隔意味著越多的 Agent 執(zhí)行、越多的 Server 輪詢和越大的存儲開銷。尤其是自定義 UserParameter 每次都執(zhí)行 curl 命令如果一臺機器上有 7 個 nginx key每個采集周期就有 7 次 curl。機器數(shù)量一多這個開銷會被明顯放大。如果想降低開銷有兩個方向。一個方向是把采集間隔統(tǒng)一調(diào)大成 1 分鐘。Nginx 的指標本來就是慢變量1 分鐘內(nèi)的尖峰對告警影響不大。另一個方向是寫一個單獨的采集腳本一次抓取狀態(tài)頁把結(jié)果寫到臨時文件再由多個 UserParameter 去讀文件避免每次都重新 curl。后一種方案適合機器多、又不愿意放寬采集間隔的場景但腳本邏輯和錯誤處理要寫得更嚴謹否則一個腳本崩了所有 nginx key 都會失效。歷史數(shù)據(jù)保留方面原始監(jiān)控值保留 7 到 14 天足夠趨勢數(shù)據(jù)保留 365 天用于回顧容量。如果你發(fā)現(xiàn)自己經(jīng)常要回溯更久之前的 Nginx 指標建議單獨導出到外部存儲不要無限拉長 Zabbix 的保留周期否則數(shù)據(jù)庫膨脹之后整個監(jiān)控系統(tǒng)的查詢速度都會受影響。我個人更建議按這個順序落地先把狀態(tài)頁和 curl 驗證跑通再用 zabbix_get 確認 key 有數(shù)據(jù)然后創(chuàng)建主機和監(jiān)控項最后才是觸發(fā)器和圖形?？雌饋砹鞒谈L但每一步都有明確的成功標準出了問題也知道在哪一段排查。真正跑過一輪測試之后你會發(fā)現(xiàn) Zabbix 監(jiān)控 Nginx 并不復雜難點反而不是工具而是你愿不愿意把一個累計計數(shù)器、一個狀態(tài)頁字段吃透。 Zabbix監(jiān)控Nginx：stub_status+UserParameter配置實戰(zhàn)指南
Nginx 監(jiān)控這件事很多人一開始想復雜了。Zabbix 要拿到 Nginx 的運行狀態(tài)并不需要裝額外探針也不一定非要解析訪問日志最穩(wěn)定的入口其實是 Nginx 自帶的 stub_status 狀態(tài)頁。只要把它打開再用 Zabbix Agent 把里面的幾個數(shù)字讀回來就能完成請求量、并發(fā)連接、讀寫狀態(tài)的監(jiān)控再配上觸發(fā)器和圖形連接數(shù)異常、請求速率突變這些情況都能直接看到。這篇內(nèi)容按實際落地順序來拆先講 Nginx 狀態(tài)頁每個字段是什么意思再講怎么讓 Zabbix Agent 把數(shù)據(jù)采回來然后是 Zabbix 前端里的監(jiān)控項、觸發(fā)器和圖形怎么配最后做一輪實測把請求打起來再去看統(tǒng)計結(jié)果怎么解讀。適合剛接觸 Zabbix 監(jiān)控 Nginx 的人也適合已經(jīng)在用 shell 腳本采集、但想轉(zhuǎn)成 Zabbix 規(guī)范化監(jiān)控的人。1. 先搞清楚 nginx 狀態(tài)頁Zabbix 監(jiān)控 Nginx 的數(shù)據(jù)從哪來1.1 stub_status 輸出字段對照Zabbix 監(jiān)控 Nginx底層數(shù)據(jù)源不是日志而是 Nginx 自己維護的計數(shù)器。只要在 Nginx 配置里啟用 stub_status訪問狀態(tài)頁就能看到一小段純文本Active connections: 291 server accepts handled requests 16630948 16630948 31070465 Reading: 6 Writing: 179 Waiting: 106這段文本雖然短但每個字段都有明確含義。字段含義類型Active connections當前活動連接數(shù)瞬時值acceptsNginx 啟動以來累計接受的客戶端連接總數(shù)累計值handled成功處理的連接總數(shù)累計值requests累計處理的客戶端請求總數(shù)累計值Reading正在讀取請求頭的連接數(shù)瞬時值Writing正在讀取請求體、處理請求或?qū)戫憫倪B接數(shù)瞬時值Waiting空閑的 keep-alive 連接數(shù)瞬時值第一行Active connections是當前活動連接數(shù)。注意它包含后面 Reading、Writing、Waiting 三類的總和所以只要 Nginx 活著這個數(shù)值通常不會是 0。第二行是固定表頭server accepts handled requests。第三行的三個數(shù)字分別對應表頭都是只增不減的累計計數(shù)器只有 Nginx 重啟才會歸零。第四行的 Reading、Writing、Waiting 是三個瞬時值。一個請求從進入到結(jié)束通常會依次經(jīng)過 Reading、Writing 兩個階段最后進入 Waiting或者直接關閉連接。這幾個字段之間的換算關系是Active connections Reading Writing Waiting。理解這個關系后面看圖形和觸發(fā)器才不會被數(shù)字騙到。1.2 哪些指標值得接進 Zabbix不是每個字段都必須接進來但下面這幾個我建議至少都要有。請求速率是最核心的指標對應 requests 計數(shù)器看的是單位時間內(nèi)處理了多少請求也就是平時說的 QPS。只看累計值沒有意義必須換算成速率。新建連接速率對應 accepts 計數(shù)器看的是單位時間內(nèi)來了多少新連接。這個值和 QPS 的區(qū)別在于keep-alive 生效的情況下一個連接上可以連續(xù)發(fā)多個請求所以請求速率通常遠大于連接速率。當前并發(fā)連接數(shù)對應 Active connections是最直觀的負載指標。但它不能單獨說明問題必須結(jié)合 Reading、Writing、Waiting 一起看。Reading 如果持續(xù)偏高說明有一些客戶端請求頭發(fā)得很慢或者請求頭一直沒發(fā)完。Writing 持續(xù)偏高說明 Nginx 正在大量往客戶端寫響應這時候要關注帶寬和上游服務能不能跟上。Waiting 高反而是正?，F(xiàn)象說明大量連接是空閑 keep-alive對靜態(tài)資源或高并發(fā) Web 服務很常見。把這些字段全部接進 Zabbix才算真正把 Nginx 的運行狀態(tài)看完整。2. 環(huán)境準備與最小配置讓 Nginx 先吐出狀態(tài)數(shù)據(jù)2.1 確認 Nginx 是否支持 stub_statusstub_status 不是所有 Nginx 都默認包含。編譯 Nginx 時如果沒有加--with-http_stub_status_module這個功能就不存在配置寫了也會報錯。先檢查當前 Nginx 有沒有這個模塊nginx -V 21 | grep -o http_stub_status_module如果輸出里有http_stub_status_module說明支持。如果沒有有兩個方向重新編譯 Nginx 時加上這個模塊或者換成已經(jīng)默認包含該模塊的發(fā)行版軟件包。很多發(fā)行版和官方倉庫自帶的 Nginx 都已經(jīng)開啟了這個模塊但自編譯版本一定要單獨確認。這里提醒一下執(zhí)行nginx -V時編譯參數(shù)是在標準錯誤輸出里所以我加了21把錯誤輸出重定向到同一路。很多人第一次只看第一行 version以為不支持其實是沒看全。2.2 Nginx 狀態(tài)頁配置示例與安全限制確認模塊存在后在 Nginx 的 server 配置里加一個 location。以下是一份最小配置server { listen 80; server_name _; location /nginx_status { stub_status on; access_log off; allow 127.0.0.1; deny all; } }這里最關鍵的是allow和deny。stub_status 本身沒有任何認證機制任何人能訪問就能看到你的連接數(shù)、請求量和連接狀態(tài)。如果把狀態(tài)頁暴露到公網(wǎng)內(nèi)部運行信息等于公開了。所以默認只允許本機訪問是最穩(wěn)妥的做法。如果你的 Zabbix Agent 和 Nginx 不在同一臺機器上不要直接把deny all刪掉應該改成只允許采集機 IP 訪問location /nginx_status { stub_status on; access_log off; allow 192.168.1.100; deny all; }改完配置先檢查再重載nginx -t nginx -s reloadnginx -t這一步不能省。stub_status 的 location 如果配置在錯誤的上下文里或者和已有配置沖突reload 會直接失敗。2.3 用 curl 驗證狀態(tài)頁是否生效配置完成之后先在 Nginx 所在機器上驗證curl -s http://127.0.0.1/nginx_status如果能看到開頭那段文本說明狀態(tài)頁已經(jīng)可以訪問了。如果返回 404說明 location 沒生效或者配置在了錯誤的 server 塊里。如果返回 403大概率是deny all生效了而你的請求來源 IP 不在allow列表里。這里有個容易忽略的點如果你的 Nginx 不是監(jiān)聽 80 端口或者同時有 HTTPSURL 里要帶上實際協(xié)議和端口例如http://127.0.0.1:8080/nginx_status。先花一分鐘把 curl 這步跑通后面會省很多時間。3. Zabbix Agent 接入一條 UserParameter 和一個監(jiān)控項的關系3.1 安裝與基礎配置 Zabbix AgentZabbix Agent 是部署在 Nginx 所在機器上的采集程序。它的作用和 Nginx 狀態(tài)頁互補狀態(tài)頁負責提供數(shù)據(jù)Agent 負責把數(shù)據(jù)讀出來再交給 Zabbix Server。安裝方式要看你的系統(tǒng)和 Zabbix 版本直接使用官方倉庫安裝 zabbix-agent 即可。裝完需要修改配置文件常見要確認三個參數(shù)Server192.168.1.10 ServerActive192.168.1.10 Hostnameweb01Server是允許給這臺 Agent 下發(fā)被動采集請求的 Zabbix Server 地址。ServerActive是主動上報要連接的 Server 地址。Hostname是 Agent 上報時使用的名字在 Zabbix 前端添加主機時要保持一致特別是主動檢查時Hostname 對不上會直接導致數(shù)據(jù)丟失。這里解釋一下被動檢查和主動檢查的區(qū)別。被動檢查是 Zabbix Server 主動連接 Agent 的 10050 端口要數(shù)據(jù)主動檢查是 Agent 主動連接 Server 的 10051 端口上報數(shù)據(jù)。自定義 UserParameter 兩種方式都支持但排查問題時的思路不一樣后面會詳細說。改完配置啟動服務systemctl restart zabbix-agent systemctl status zabbix-agent3.2 通過 UserParameter 把 nginx_status 轉(zhuǎn)成監(jiān)控項Zabbix Agent 默認不認識 nginx 的 key需要通過 UserParameter 來定義。UserParameter 的格式很簡單一個 key一個命令Agent 執(zhí)行命令把標準輸出作為監(jiān)控值返回。在/etc/zabbix/zabbix_agentd.d/目錄下創(chuàng)建一個 nginx.conf寫入以下內(nèi)容UserParameternginx.active,/usr/bin/curl -s --max-time 3 http://127.0.0.1/nginx_status | awk /Active connections/{print $3} UserParameternginx.accepts,/usr/bin/curl -s --max-time 3 http://127.0.0.1/nginx_status | awk NR3{print $1} UserParameternginx.handled,/usr/bin/curl -s --max-time 3 http://127.0.0.1/nginx_status | awk NR3{print $2} UserParameternginx.requests,/usr/bin/curl -s --max-time 3 http://127.0.0.1/nginx_status | awk NR3{print $3} UserParameternginx.reading,/usr/bin/curl -s --max-time 3 http://127.0.0.1/nginx_status | awk /Reading/{print $2} UserParameternginx.writing,/usr/bin/curl -s --max-time 3 http://127.0.0.1/nginx_status | awk /Writing/{print $4} UserParameternginx.waiting,/usr/bin/curl -s --max-time 3 http://127.0.0.1/nginx_status | awk /Waiting/{print $6}逐個拆一下。每行都是一個 key例如nginx.active。后面的命令先用 curl 抓取狀態(tài)頁再用 awk 提取對應字段。awk 的寫法要特別注意。第三行的 accepts、handled、requests 是三個連續(xù)數(shù)字所以分別用NR3定位到第三行再打印第 1、2、3 列。Reading、Writing、Waiting 在同一行里所以要先用正則匹配到這一行再打印對應列。Writing 是第 4 列Waiting 是第 6 列這個順序很多人會弄錯。命令里的--max-time 3不是隨便加的。如果狀態(tài)頁異常導致 curl 一直掛住Agent 執(zhí)行這個 UserParameter 就會卡住嚴重時會占滿 Agent 的檢查線程影響這臺機器上的其他監(jiān)控項。加上超時時間最壞 3 秒也會退出。改完配置后重啟 Agentsystemctl restart zabbix-agent3.3 先用 zabbix_get 還是前端測試功能配置完 UserParameter不要急著去 Zabbix 前端創(chuàng)建主機先在命令行驗證一遍 key 能不能查到值。在有 zabbix-get 工具的機器上執(zhí)行它通常在 Zabbix Server 或 Proxy 上zabbix_get -s 192.168.1.20 -k nginx.requests返回一個數(shù)字說明這條鏈路通了。如果提示 Not supported 或者沒有輸出先不要懷疑 Zabbix 配置回到 Nginx 機器上直接執(zhí)行那條 UserParameter 命令看有沒有結(jié)果。這里有個容易踩的坑你手動執(zhí)行命令時用的是 root 用戶而 Zabbix Agent 運行時的用戶通常是 zabbix兩個用戶的環(huán)境變量、權(quán)限、可執(zhí)行路徑可能都不一樣。比如 zabbix 用戶沒有權(quán)限訪問某個目錄或者 SELinux 攔截了 zabbix 用戶執(zhí)行 curl都會導致手動執(zhí)行正常、Agent 執(zhí)行失敗。新版 Zabbix 前端在監(jiān)控項配置里也有一個 Test 按鈕可以直接測試當前主機上的 key返回結(jié)果和報錯更直觀。實際排查時我一般按三個地方順序看Agent 所在機器手動執(zhí)行命令、zabbix_get 從 Server 端測試、前端 Test 按鈕看報錯。4. 創(chuàng)建主機、監(jiān)控項、觸發(fā)器數(shù)據(jù)到告警的完整鏈路4.1 在 Zabbix 前端添加主機與監(jiān)控項命令行驗證通過后進入 Zabbix Web 界面按照 配置 → 主機 → 創(chuàng)建主機 的路徑添加一臺主機。填寫主機名時要注意Agent 配置文件里的 Hostname 和這里的主機名必須一致否則主動檢查會失敗。接口配置里選擇 Agent填寫 Nginx 所在機器的 IP 和默認端口 10050。添加監(jiān)控項有兩條路線。一條是直接鏈接模板Zabbix 模板庫里有 Nginx by HTTP、Nginx by Zabbix agent 2 這類現(xiàn)成模板不同版本的模板數(shù)量和名稱會有差異底層采集方式也是去讀狀態(tài)頁適合不想自己維護 key 的人。另一條是手動創(chuàng)建監(jiān)控項用剛才定義的 UserParameter 鍵值自由度更高也更容易理解每個數(shù)字怎么來的。如果你是第一次做我更建議先手動創(chuàng)建。原因很簡單自動模板會隱藏很多細節(jié)一旦出了問題你很難判斷是狀態(tài)頁的問題、Agent 的問題還是模板映射的問題。手動創(chuàng)建一遍等于把鏈路里的每個環(huán)節(jié)都摸清楚了。手動創(chuàng)建監(jiān)控項時以nginx.requests為例名稱Nginx Requests類型Zabbix Agent鍵值nginx.requests信息類型數(shù)字無正負更新間隔1m 或 30s 都可以歷史數(shù)據(jù)保留7d趨勢數(shù)據(jù)保留365d其他幾個 key 按同樣方法創(chuàng)建。4.2 請求速率、連接數(shù)怎么存儲和計算單位這里要解決一個關鍵問題accepts、handled、requests 這三個字段是累計值直接存進 Zabbix 只能看到一根一直向上的線很難判斷當前請求量到底是多少。所以必須讓 Zabbix 把累計值換算成速率。在 Zabbix 監(jiān)控項配置里有一個字段叫“存儲值”可以選“原樣存儲”“增量簡單變化”和“增量每秒速率”。存儲方式適用場景示例原樣存儲瞬時值當前是多少就存多少active、reading、writing、waiting增量簡單變化累計值的兩次差值accepts 每次變化量增量每秒速率累計值換算成每秒速率requests、accepts、handled對 requests、accepts、handled 這三個累計計數(shù)器應該選擇“增量每秒速率”單位寫成 req/s 或 conn/s。這樣 Zabbix 會在后臺自動計算兩次采集之間的差值再除以時間間隔得到每秒速率。如果你不想在監(jiān)控項里改存儲方式也可以用預處理步驟里的“每秒更改量”來實現(xiàn)同樣效果。兩者本質(zhì)上是一樣的看你習慣哪種。唯一要注意的是如果 Nginx 在兩次采集之間重啟過計數(shù)器歸零速率可能會出現(xiàn)一次很大的負值或異常值統(tǒng)計圖形上會出現(xiàn)明顯的斷點這是正?，F(xiàn)象不是系統(tǒng)崩潰。active、reading、writing、waiting 這四個瞬時值就保持“原樣存儲”它們的數(shù)值本身就是當前狀態(tài)不需要做速率換算。4.3 觸發(fā)器和告警閾值怎么定監(jiān)控項建好后數(shù)據(jù)會不斷進入 Zabbix但沒人盯著圖形的話異常還是發(fā)現(xiàn)不了。觸發(fā)器的意義就是自動判斷數(shù)值是否超過預期。觸發(fā)器配置路徑是 配置 → 主機 → 觸發(fā)器 → 創(chuàng)建觸發(fā)器。以活躍連接數(shù)為例一個簡單表達式last(/web01/nginx.active)10000含義是當前活躍連接數(shù)大于 10000 時觸發(fā)警告。再比如請求速率min(/web01/nginx.requests,5m)5000含義是最近 5 分鐘請求速率平均值超過 5000 req/s 時觸發(fā)。閾值定多少沒有標準答案取決于你的業(yè)務。我建議先讓 Zabbix 跑兩三天積累一段基線數(shù)據(jù)再根據(jù)圖形里的峰值來定警告和嚴重閾值不要憑感覺拍腦袋。第一次設置可以把閾值放寬一點確認告警鏈路能正常觸發(fā)后再往回收。觸發(fā)器還可以設置恢復表達式也就是數(shù)值降到多少以下時自動恢復為正常。這個最好一起配好否則每次數(shù)值震蕩都會反復觸發(fā)、恢復告警會很吵。要測試告警鏈路的完整效果除了觸發(fā)器還需要配置好動作和通知方式。如果暫時沒配郵件或其他通知也可以先只做觸發(fā)器通過 Zabbix 首頁的告警記錄來確認觸發(fā)是否成功。5. 實測一輪用請求壓一壓再去看統(tǒng)計結(jié)果和圖形5.1 制造流量curl 循環(huán)或 ab 簡單壓測配置完成之后最關鍵的一步就是實測。沒有流量監(jiān)控圖形是一條平線你很難判斷數(shù)據(jù)到底有沒有采集成功。最簡單的測試方法是用 curl 發(fā)一批請求。在 Nginx 機器上執(zhí)行for i in $(seq 1 1000); do curl -s -o /dev/null http://127.0.0.1/; done這個循環(huán)會向本機 Nginx 發(fā)送 1000 次請求每次丟棄響應內(nèi)容。優(yōu)點是環(huán)境干凈不需要額外工具。缺點是速度不夠快產(chǎn)生的請求速率不會特別高。如果你機器上有 ab也就是 ApacheBench可以壓得更明顯一些ab -n 5000 -c 100 -k http://127.0.0.1/這條命令的含義是總共發(fā)送 5000 個請求同時保持 100 個并發(fā)連接-k表示啟用 keep-alive。ab 在測試時會持續(xù)請求能把 Nginx 的請求速率和活躍連接數(shù)明顯拉起來。執(zhí)行的時候建議一次只跑一種跑完等一分鐘讓 Zabbix 完成幾個采集周期再去前端看數(shù)據(jù)。如果立刻去看采集周期還沒到可能什么都看不到。5.2 分析 Latest data 和 Graphs進入 Zabbix 前端的“監(jiān)測 → 最新數(shù)據(jù)”選擇剛才創(chuàng)建的主機就能看到每條監(jiān)控項的當前值。這時候你看到的應該是有具體數(shù)字的綠色狀態(tài)而不是“不支持”或“無數(shù)據(jù)”。以剛才 ab 壓測為例壓測過程中可以看到 requests 數(shù)值沖上去壓測結(jié)束后又會回落。如果配上圖形把請求速率、活躍連接、Reading、Writing、Waiting 放在同一張圖里觀察能很直觀地看到整個請求生命周期的變化。如果你沒有在監(jiān)控項里單獨創(chuàng)建圖形也可以在儀表盤中添加一個圖表組件數(shù)據(jù)源選擇對應主機的監(jiān)控項。Zabbix 的圖表組件支持把多個監(jiān)控項疊加到同一張圖上非常適合對比 Active connections、Reading、Writing、Waiting 這幾個相關指標。5.3 從數(shù)據(jù)反向判斷 Nginx 狀態(tài)是否健康數(shù)據(jù)有了接下來的重點是怎么讀這些數(shù)字。先看 active connections 和 waiting 的關系。如果活躍連接數(shù)很高但 waiting 也很高說明大量連接是空閑 keep-aliveNginx 實際壓力不大只是在維持長連接。如果活躍連接數(shù)高waiting 卻很低說明連接都在真正干活這時候負載才是真的高。再看 accepts 和 handled 的對比。正常情況下這兩個數(shù)值應該非常接近。如果 handled 長期明顯小于 accepts說明有一部分連接沒有被 Nginx 成功處理可能原因是 worker_connections 配置過低連接數(shù)被系統(tǒng)層面拒絕了。通過 Zabbix 監(jiān)控這兩個值的曲線差值能比看錯誤日志更早發(fā)現(xiàn)問題。再看請求速率和連接速率的關系。用 requests 速率除以 accepts 速率可以得到平均每個連接上的請求數(shù)。如果這個值接近 1說明 keep-alive 基本沒起作用客戶端每次請求都新建連接連接效率很低。如果明顯大于 1說明 keep-alive 生效良好一個連接上處理了多個請求。Reading 和 Writing 是更細的觀察點。靜態(tài)資源站點在壓測時Writing 會明顯升高因為 Nginx 正在往客戶端輸出響應。如果 Writing 持續(xù)高位但 requests 并不高可能是網(wǎng)絡帶寬打滿了響應寫不出去。Reading 持續(xù)高位則要小心可能是客戶端請求頭發(fā)送緩慢也可能是存在慢連接這種情況即使活躍連接數(shù)不高worker 也可能被拖住。這些判斷不能只看一兩個采樣點最好結(jié)合 5 分鐘、1 小時的時間窗口來看趨勢。這也是為什么前面建議把趨勢數(shù)據(jù)保留時間設長一些。6. 常見問題排查與生產(chǎn)環(huán)境落地的邊界6.1 Agent 顯示 Not supported 時按什么順序查Zabbix Agent 返回 Not supported 是監(jiān)控 Nginx 時最常遇到的問題。很多人第一反應是去改 Zabbix 配置其實大多數(shù)時候問題出在 Agent 側(cè)。我的排查順序是固定的。第一步直接手動執(zhí)行那條 UserParameter 命令看有沒有輸出。如果命令本身就沒輸出說明狀態(tài)頁、curl、awk 里有一環(huán)斷了。第二步確認執(zhí)行用戶。Zabbix Agent 通常以 zabbix 用戶運行手動用 root 執(zhí)行成功不代表 zabbix 用戶能執(zhí)行。可以用su - zabbix -s /bin/bash -c 命令來模擬 Agent 的執(zhí)行環(huán)境。第三步看 Agent 日志默認在 /var/log/zabbix/zabbix_agentd.log。日志里會記錄 key 對應的錯誤信息比如命令找不到、執(zhí)行超時、權(quán)限不足等。第四步改完 UserParameter 后確認重啟了 Agent。UserParameter 是在 Agent 啟動時讀取的不重啟不會生效。第五步從 Server 端用 zabbix_get 測試連通性。這一步能區(qū)分問題是出在 Agent 執(zhí)行命令還是 Server 與 Agent 之間的網(wǎng)絡、端口、密鑰配置上。還有一個常見問題Linux 有 SELinux 或 AppArmor 環(huán)境時zabbix 用戶執(zhí)行 curl 連接本機端口可能會被攔截。手動執(zhí)行正常Agent 執(zhí)行就是失敗排查到這一步時要看安全審計日志確認是不是被策略攔截了。6.2 狀態(tài)頁不能直接暴露在公網(wǎng)前面配置 Nginx 狀態(tài)頁時寫了 allow 和 deny這個限制在正式環(huán)境同樣重要。stub_status 只有數(shù)據(jù)輸出沒有認證、沒有訪問控制任何人拿到狀態(tài)頁地址就能看到你所有虛擬主機的連接數(shù)、請求量等信息。這些數(shù)據(jù)單獨看不算機密但結(jié)合業(yè)務時序可能暴露促銷活動、低谷期等運營信息。所以生產(chǎn)環(huán)境要遵守幾個原則狀態(tài)頁只監(jiān)聽內(nèi)網(wǎng)地址或只允許內(nèi)網(wǎng)訪問。Zabbix Agent 與 Nginx 部署在一起時直接限制為 127.0.0.1。如果需要遠程采集優(yōu)先讓 Agent 本機讀取不要讓其他機器直接 HTTP 訪問狀態(tài)頁。Nginx 服務本身就開啟了公網(wǎng)監(jiān)聽時更要檢查 allow 列表不要把公網(wǎng)網(wǎng)段放進去。另外狀態(tài)頁建議使用獨立 location不要放在一個會匹配大量路徑的通用規(guī)則里避免被掃描工具順帶發(fā)現(xiàn)。access_log off也要保留否則每個狀態(tài)頁請求都會寫一條訪問日志白白增加磁盤 IO。6.3 多實例和規(guī)范化模板、宏、命名規(guī)則如果只有一臺機器手動創(chuàng)建監(jiān)控項沒什么問題。一旦機器多起來比如七八臺 Nginx 都要監(jiān)控逐臺手動創(chuàng)建就很痛苦而且容易漏配。這時候應該把監(jiān)控項、觸發(fā)器、圖形整理成模板。在模板里創(chuàng)建好 nginx.active、nginx.requests 這些監(jiān)控項和對應的觸發(fā)器再把模板鏈接到主機上所有主機自動繼承配置。后續(xù)要加閾值、加圖形只需要改模板一處所有主機同步生效。模板里的閾值可以做成宏比如{$NGINX_ACTIVE_WARN}、{$NGINX_REQ_HIGH}。這樣在不同業(yè)務機器上可以差異化覆蓋不用復制整個模板。比如 A 機器請求量本來就大警告閾值定 8000B 機器是小業(yè)務閾值定 1000。用宏就能在同一套模板下按主機單獨調(diào)整。key 的命名也要規(guī)范。前面用的 nginx.active、nginx.requests 就是比較清晰的命名方式。如果一臺機器上有多個 Nginx 實例建議在 key 里帶實例編號比如 nginx1.active、nginx2.active避免數(shù)據(jù)串臺。6.4 歷史數(shù)據(jù)保留和監(jiān)控頻率最后聊一下采集頻率和數(shù)據(jù)保留。對 Nginx 監(jiān)控來說30 秒到 1 分鐘的采集間隔已經(jīng)足夠。不要看到別人用 1 秒間隔就覺得越快越好越短的間隔意味著越多的 Agent 執(zhí)行、越多的 Server 輪詢和越大的存儲開銷。尤其是自定義 UserParameter 每次都執(zhí)行 curl 命令如果一臺機器上有 7 個 nginx key每個采集周期就有 7 次 curl。機器數(shù)量一多這個開銷會被明顯放大。如果想降低開銷有兩個方向。一個方向是把采集間隔統(tǒng)一調(diào)大成 1 分鐘。Nginx 的指標本來就是慢變量1 分鐘內(nèi)的尖峰對告警影響不大。另一個方向是寫一個單獨的采集腳本一次抓取狀態(tài)頁把結(jié)果寫到臨時文件再由多個 UserParameter 去讀文件避免每次都重新 curl。后一種方案適合機器多、又不愿意放寬采集間隔的場景但腳本邏輯和錯誤處理要寫得更嚴謹否則一個腳本崩了所有 nginx key 都會失效。歷史數(shù)據(jù)保留方面原始監(jiān)控值保留 7 到 14 天足夠趨勢數(shù)據(jù)保留 365 天用于回顧容量。如果你發(fā)現(xiàn)自己經(jīng)常要回溯更久之前的 Nginx 指標建議單獨導出到外部存儲不要無限拉長 Zabbix 的保留周期否則數(shù)據(jù)庫膨脹之后整個監(jiān)控系統(tǒng)的查詢速度都會受影響。我個人更建議按這個順序落地先把狀態(tài)頁和 curl 驗證跑通再用 zabbix_get 確認 key 有數(shù)據(jù)然后創(chuàng)建主機和監(jiān)控項最后才是觸發(fā)器和圖形?？雌饋砹鞒谈L但每一步都有明確的成功標準出了問題也知道在哪一段排查。真正跑過一輪測試之后你會發(fā)現(xiàn) Zabbix 監(jiān)控 Nginx 并不復雜難點反而不是工具而是你愿不愿意把一個累計計數(shù)器、一個狀態(tài)頁字段吃透。