上個(gè)月幫同事排查一套 Zabbix 監(jiān)控 Nginx 數(shù)據(jù)一直為空的問(wèn)題。一開(kāi)始我們都把注意力放在 Zabbix Web 端反復(fù)檢查模板、主機(jī)、宏折騰了一上午。最后才發(fā)現(xiàn)真正斷掉的環(huán)節(jié)是 Nginx 的 stub_status 狀態(tài)頁(yè)根本沒(méi)有暴露出來(lái)agent 自然也就拿不到任何數(shù)據(jù)。更讓我意外的是同事的配置是從一篇兩三年前的教程里抄來(lái)的那篇教程里的模板名稱、agent 類型和現(xiàn)在的環(huán)境已經(jīng)對(duì)不上。這不是個(gè)案。Zabbix 監(jiān)控 Nginx 這件事最常見(jiàn)的坑不是 Zabbix 不會(huì)裝而是安裝配置流程里塞滿了舊資料。所以下面我不打算只給一個(gè)固定命令序列而是想把 Zabbix 監(jiān)控 Nginx 的鏈路重新拆一遍Nginx 怎么暴露狀態(tài)agent 怎么讀到數(shù)據(jù)模板怎么匹配以及當(dāng)你拿到一臺(tái)新機(jī)器時(shí)應(yīng)該按什么順序驗(yàn)證。核心判斷只有一句——真正決定這套監(jiān)控能不能跑通的往往不是 Zabbix 本身而是 Nginx 狀態(tài)頁(yè)、agent 采集和模板匹配這三個(gè)環(huán)節(jié)有沒(méi)有全部連上。1. 先想清楚Zabbix 監(jiān)控 Nginx 到底在監(jiān)控什么1.1 表面是進(jìn)程存活本質(zhì)是連接和請(qǐng)求很多入門教程會(huì)把 Zabbix 監(jiān)控 Nginx 簡(jiǎn)單理解成“Nginx 掛了就報(bào)警”。這個(gè)理解不算錯(cuò)但太單薄。Nginx 是應(yīng)用入口它的價(jià)值不在于進(jìn)程起沒(méi)起來(lái)而在于它當(dāng)前扛了多少連接、請(qǐng)求處理得是否順暢、有沒(méi)有異常堆積。Zabbix 之所以能監(jiān)控 Nginx核心不是直接讀進(jìn)程狀態(tài)而是通過(guò) Nginx 自身的狀態(tài)接口或模塊拿到一組結(jié)構(gòu)化指標(biāo)。最常見(jiàn)的數(shù)據(jù)源是 Nginx 官方自帶的 stub_status 模塊。打開(kāi)狀態(tài)頁(yè)后你會(huì)看到類似這樣的一小段文本Active connections: 3 server accepts handled requests 12 12 15 Reading: 0 Writing: 1 Waiting: 2這幾個(gè)數(shù)字的含義值得記住Active connections當(dāng)前活躍連接數(shù)。acceptsNginx 啟動(dòng)以來(lái)成功接受的連接總數(shù)。handled成功處理的連接總數(shù)。正常情況下 accepts 和 handled 應(yīng)該接近。requests總請(qǐng)求數(shù)。Reading / Writing / Waiting分別表示正在讀請(qǐng)求頭、正在寫響應(yīng)、以及空閑 keep-alive 連接的數(shù)量。這些指標(biāo)能幫你看清什么比如 Reading 長(zhǎng)時(shí)間很高說(shuō)明請(qǐng)求堆積在讀取階段背后可能是客戶端沒(méi)有把請(qǐng)求發(fā)完整Waiting 大量存在不是壞事只能說(shuō)明 keep-alive 連接占著資源accepts 和 handled 差距持續(xù)增大則可能說(shuō)明有連接在中間環(huán)節(jié)被丟掉。1.2 為什么很多“監(jiān)控沒(méi)數(shù)據(jù)”其實(shí)和 Zabbix 無(wú)關(guān)排查過(guò)幾次就會(huì)發(fā)現(xiàn)Zabbix 監(jiān)控 Nginx 沒(méi)數(shù)據(jù)絕大多數(shù)原因不在 Zabbix要么是 Nginx 狀態(tài)頁(yè)沒(méi)開(kāi)啟要么是狀態(tài)頁(yè)返回的是 HTML 而不是純文本要么是 agent 訪問(wèn)不到狀態(tài)頁(yè)要么是模板里的宏路徑和實(shí)際路徑不一致。Zabbix 本身只是在按固定周期向 agent 要數(shù)據(jù)agent 再去請(qǐng)求 Nginx 狀態(tài)頁(yè)。這一條數(shù)據(jù)鏈上有任何一個(gè)環(huán)節(jié)斷了儀表盤就永遠(yuǎn)是空的。所以我建議把這條鏈路拆成三段來(lái)理解Nginx 負(fù)責(zé)提供數(shù)據(jù)agent 負(fù)責(zé)搬運(yùn)數(shù)據(jù)Zabbix 負(fù)責(zé)展示和告警。后兩段的問(wèn)題通常都有日志可查反而是第一段最容易被人忽略。很多“監(jiān)控沒(méi)數(shù)據(jù)”的案例其實(shí)和你選的模板、版本的關(guān)聯(lián)沒(méi)有想象中那么大問(wèn)題往往出在數(shù)據(jù)源這一層。2. Nginx 側(cè)的狀態(tài)頁(yè)配置先把數(shù)據(jù)源打開(kāi)2.1 先確認(rèn)模塊再改配置順序不要反Nginx 狀態(tài)頁(yè)依賴 http_stub_status_module 這個(gè)模塊。問(wèn)題在于不是所有 Nginx 環(huán)境都默認(rèn)包含它。源碼編譯安裝時(shí)如果沒(méi)有帶 --with-http_stub_status_module后面想加模塊就得重新編譯發(fā)行版?zhèn)}庫(kù)里的 nginx 通常已經(jīng)包含這個(gè)模塊但不同發(fā)行版、不同倉(cāng)庫(kù)之間也可能有差異容器鏡像則更不一定一些精簡(jiǎn)鏡像會(huì)把用不到的模塊裁掉。所以第一步是確認(rèn)模塊存在。常見(jiàn)做法是查看編譯參數(shù)nginx -V 21 | tr \n | grep stub_status如果輸出里能看到 http_stub_status_module說(shuō)明模塊沒(méi)問(wèn)題。如果什么都沒(méi)有就不要繼續(xù)往下配狀態(tài)頁(yè)了先解決模塊問(wèn)題。否則你配置再正確curl 訪問(wèn)時(shí)也只能看到 404。注意有些系統(tǒng)里 nginx 不在 PATH 中可能需要寫全路徑比如/usr/local/nginx/sbin/nginx -V或者先執(zhí)行which nginx確認(rèn)一下。2.2 一個(gè)穩(wěn)妥的 stub_status 配置示例確認(rèn)模塊存在后再修改 Nginx 配置。常見(jiàn)的做法是在一個(gè) server 塊里加一個(gè) location只讓狀態(tài)頁(yè)從指定路徑訪問(wèn)server { listen 80; server_name _; location /nginx_status { stub_status; allow 127.0.0.1; allow 192.168.10.0/24; deny all; } }這里有幾個(gè)細(xì)節(jié)要說(shuō)明。location /nginx_status是精確匹配避免掩蓋其他路徑規(guī)則stub_status;是常見(jiàn)寫法如果你看到的舊教程里寫的是stub_status on;通常也能兼容但更推薦按當(dāng)前版本的標(biāo)準(zhǔn)寫法來(lái)allow 和 deny 用來(lái)限制來(lái)源 IP避免狀態(tài)頁(yè)暴露到公網(wǎng)。雖然狀態(tài)頁(yè)內(nèi)容看起來(lái)不敏感但泄露給外界等于給攻擊者多一個(gè)信息采集入口沒(méi)有理由不做限制。寫完配置后先檢查配置再重載nginx -t nginx -s reload # 如果使用 systemd 管理也可以寫成 systemctl reload nginx然后用 curl 驗(yàn)證curl -s http://127.0.0.1/nginx_status如果能看到開(kāi)頭那段純文本說(shuō)明 Nginx 側(cè)已經(jīng)通了。注意curl 的來(lái)源 IP 要和 allow 規(guī)則匹配否則你會(huì)看到 403。2.3 容器化和非默認(rèn)端口環(huán)境的特殊點(diǎn)如果你的 Nginx 跑在容器里情況會(huì)稍微復(fù)雜一點(diǎn)。agent 要么和 Nginx 在同一個(gè)容器內(nèi)要么通過(guò)容器 IP 或映射端口訪問(wèn)狀態(tài)頁(yè)。容器內(nèi)的 Nginx 如果只監(jiān)聽(tīng)了容器內(nèi)部端口agent 在宿主機(jī)上直接 curl 127.0.0.1 是拿不到響應(yīng)的。這類問(wèn)題用 curl 驗(yàn)證時(shí)最容易暴露但很多人會(huì)誤以為是自己配置寫錯(cuò)了。另外狀態(tài)頁(yè)不一定只能放在 80 端口。有的環(huán)境為了安全和便于管理會(huì)把狀態(tài)頁(yè)放在 8080 或單獨(dú)一個(gè) server 塊里。這樣的設(shè)計(jì)沒(méi)問(wèn)題但模板里的宏就要跟著改。這里的重點(diǎn)是先想清楚 agent 要從哪個(gè)地址訪問(wèn) Nginx然后保證這個(gè)地址上的 TCP 連通性和 ACL 都允許。不要只在 Zabbix 里把宏改來(lái)改去主機(jī)上卻訪問(wèn)不到。我在很多環(huán)境里見(jiàn)過(guò)一種最隱蔽的錯(cuò)誤狀態(tài)頁(yè)本身配置正確但 allow 規(guī)則只放行了 127.0.0.1agent 卻通過(guò)內(nèi)網(wǎng) IP 去訪問(wèn)狀態(tài)頁(yè)。agent 請(qǐng)求時(shí)Nginx 看到的來(lái)源 IP 是內(nèi)網(wǎng)地址命中 deny all于是返回 403監(jiān)控項(xiàng)自然拿不到數(shù)據(jù)。所以配置 allow 時(shí)要想著 agent 會(huì)從哪個(gè) IP 過(guò)來(lái)而不是只寫 127.0.0.1。3. Zabbix agent 這一層不是安裝了就行3.1 配置 Server 地址和 Hostname一致性是第一原則Nginx 狀態(tài)頁(yè)通了之后才輪到 agent。agent 安裝本身不復(fù)雜麻煩的是配置。以最常見(jiàn)的 zabbix-agent 為例配置文件里幾個(gè)關(guān)鍵參數(shù)一定要理解Server192.168.10.20 ServerActive192.168.10.20 Hostnameweb01Server 和 ServerActive 不是一回事。Server 是被動(dòng)模式下允許從 Zabbix Server 拉取 item 的地址白名單ServerActive 是主動(dòng)模式下 agent 向哪個(gè) Zabbix Server 或 Proxy 上報(bào)數(shù)據(jù)的地址。如果你只配置了 Serveragent 就會(huì)等 Server 來(lái)問(wèn)如果你用了主動(dòng)模式ServerActive 也要填。很多舊教程只寫一個(gè)值換到新環(huán)境就出問(wèn)題。比這更容易出錯(cuò)的是 Hostname。Zabbix Web 端添加主機(jī)時(shí)填的主機(jī)名必須和 agent 配置里的 Hostname 保持一致。如果 Web 端寫的是 web01agent 里配的是 nginx-web-1那么即使在 Zabbix 里能看到主機(jī)監(jiān)控項(xiàng)也始終是 no data。在新版本 agent 里你還會(huì)看到HostnameItemsystem.hostname這樣的配置意思是讓 agent 用系統(tǒng)本身的 hostname 作為上報(bào)名稱。這個(gè)機(jī)制可以避免手工維護(hù) Hostname但前提是系統(tǒng) hostname 必須和 Zabbix Web 里的主機(jī)名一致。所以不管用哪種方式原則都是同一個(gè)兩邊名字要對(duì)上。3.2 agent 與 agent2模板和 key 可能不一樣這里要說(shuō)一個(gè)“和過(guò)去不一樣”比較明顯的點(diǎn)現(xiàn)在 Zabbix 官方推薦使用 Zabbix agent 2也就是 agent2。agent2 不僅在采集能力上更豐富還支持一些內(nèi)置插件但對(duì)應(yīng)的模板、監(jiān)控項(xiàng) key 和舊 agent 不完全一樣。在 Zabbix Web 里搜索 Nginx 時(shí)你可能會(huì)看到多個(gè)模板有些名字類似 Nginx by HTTP有些類似 Nginx by Zabbix agent 2。如果你在主機(jī)上裝的是 agent2卻鏈接了舊 agent 版本的模板可能會(huì)出現(xiàn) unsupported item。反過(guò)來(lái)也一樣。所以我的建議是在鏈接模板之前先打開(kāi)模板里的監(jiān)控項(xiàng)預(yù)覽看它使用的采集類型是 Zabbix agent、HTTP agent還是依賴 agent2 插件。確認(rèn)它跟你實(shí)際安裝的 agent 類型對(duì)得上再鏈接。這一步只要花兩分鐘卻可以省掉后面一晚上的排查時(shí)間。agent 和 agent2 的服務(wù)名也不一樣常見(jiàn)的有 zabbix-agent、zabbix-agent2系統(tǒng)服務(wù)名可能是 zabbix-agentd.service 或 zabbix-agent2.service。啟動(dòng)服務(wù)后用systemctl status看一下是否 active再看一眼日志路徑常見(jiàn)的是/var/log/zabbix/下面。出現(xiàn)問(wèn)題時(shí)日志里通常直接會(huì)告訴你 key 不支持還是連接失敗。3.3 用 zabbix_get 快速驗(yàn)證采集鏈路在 Web 端排查前可以先在 Zabbix Server 上用 zabbix_get 做一次最直接的驗(yàn)證確認(rèn) agent 是否正常工作zabbix_get -s 192.168.10.11 -k agent.ping如果返回 1說(shuō)明 Server 能連上 agent。如果返回值不是 1就別急著去 Web 端看模板先解決網(wǎng)絡(luò)、端口和 Hostname 問(wèn)題。agent.ping 是通用探活 key驗(yàn)證通過(guò)后再去模板里找到你想測(cè)的監(jiān)控項(xiàng) key比如和 Nginx 狀態(tài)頁(yè)相關(guān)的 key繼續(xù)用 zabbix_get 測(cè)試。不同版本、不同模板的 key 名稱會(huì)有差異所以這里不列具體 key但思路是一樣的先用 curl 確認(rèn)狀態(tài)頁(yè)存在再用 zabbix_get 確認(rèn) agent 能取到值最后才去 Web 端看圖表。鏈路從底層往上逐層打通比在界面上猜效率高得多。4. 在 Zabbix Web 端鏈接模板別被舊截圖帶偏4.1 模板名稱已經(jīng)變過(guò)好幾輪Zabbix 的模板策略在過(guò)去幾年變化很大。這次部署里我在模板列表里搜索 nginx出來(lái)的已經(jīng)不是早期教程里那張截圖上的名字了。官方模板按采集方式做了拆分有的走 HTTP agent有的走 Zabbix agent有的專門適配 agent2。這本身是好事但如果你照著一個(gè)兩三年前的教程去選模板很可能選錯(cuò)。我的建議是以當(dāng)前 Zabbix 版本實(shí)際加載的模板列表為準(zhǔn)不要憑記憶點(diǎn)。鏈接模板后立刻去“監(jiān)測(cè) – 最新數(shù)據(jù)”里過(guò)濾這個(gè)主機(jī)等一到兩個(gè)更新周期看有沒(méi)有數(shù)據(jù)進(jìn)來(lái)。如果 Zabbix 的刷新周期是 30 秒或 1 分鐘通常幾分鐘內(nèi)就能看到。另外一個(gè)主機(jī)通常只需要鏈接一個(gè)對(duì)應(yīng)當(dāng)前采集方式的 Nginx 模板不需要把所有 Nginx 模板全鏈接上。鏈接多個(gè)模板并不會(huì)讓數(shù)據(jù)更豐富反而會(huì)讓監(jiān)控項(xiàng)沖突、重復(fù)告警排查起來(lái)也更亂。4.2 宏參數(shù)路徑、協(xié)議、端口都是變量模板鏈接后還有一層容易被忽略宏參數(shù)。官方 Nginx 模板里通常會(huì)定義一組宏用來(lái)告訴 agent 去哪個(gè)地址、哪個(gè)路徑、用什么協(xié)議獲取狀態(tài)頁(yè)。常見(jiàn)宏名可能包括{$NGINX.SCHEME}、{$NGINX.PORT}、{$NGINX.STUB_STATUS.PATH}具體名稱以你當(dāng)前模板為準(zhǔn)。它們的作用就是把狀態(tài)頁(yè)的訪問(wèn)信息從監(jiān)控項(xiàng)中抽出來(lái)這樣同一套模板可以復(fù)用在不同的 Nginx 主機(jī)上。如果你的狀態(tài)頁(yè)地址不是默認(rèn)值就不用改監(jiān)控項(xiàng)直接在主機(jī)層級(jí)覆蓋宏就行。比如狀態(tài)頁(yè)路徑是 /nginx_status 而不是 /status就在主機(jī)的宏里把對(duì)應(yīng)宏改成實(shí)際路徑。改完后等下一次采集生效再看最新數(shù)據(jù)。要注意的是宏的生效范圍有層級(jí)全局宏、模板宏、主機(jī)宏。主機(jī)宏優(yōu)先級(jí)最高。如果模板里已經(jīng)定義了默認(rèn)值主機(jī)上沒(méi)改也沒(méi)關(guān)系但如果狀態(tài)頁(yè)地址做了修改一定要記得改對(duì)應(yīng)主機(jī)的宏而不是只在模板里改一個(gè)默認(rèn)值因?yàn)槟０迥J(rèn)值會(huì)影響所有鏈接該模板的主機(jī)。還有一個(gè)容易出錯(cuò)的地方狀態(tài)頁(yè)地址如果是 https但宏里用的是 http監(jiān)控項(xiàng)會(huì)一直返回錯(cuò)誤。這種問(wèn)題在視覺(jué)上非常隱蔽因?yàn)?Nginx 和 agent 都正常只有協(xié)議不匹配。4.3 驗(yàn)證模板是否能出數(shù)據(jù)鏈接模板和配好宏之后不要直接離開(kāi)頁(yè)面。花一分鐘做兩件事第一到主機(jī)監(jiān)控項(xiàng)列表里看有沒(méi)有出現(xiàn)紅色 error 狀態(tài)的監(jiān)控項(xiàng)第二到最新數(shù)據(jù)里過(guò)濾該主機(jī)確認(rèn)有非空數(shù)據(jù)。如果看到 error 狀態(tài)的監(jiān)控項(xiàng)先點(diǎn)擊進(jìn)去看錯(cuò)誤信息。常見(jiàn)的有 unsupported item key、Cannot connect to [...]: 10060、Connection refused 這類。每一條錯(cuò)誤信息其實(shí)都指向了數(shù)據(jù)鏈路的具體環(huán)節(jié)比你在外面猜模板要快得多。如果最新數(shù)據(jù)里有值但看起來(lái)不對(duì)比如 Reading 是 0、Writing 是 0也不要慌先用 curl 手動(dòng)看一次狀態(tài)頁(yè)確認(rèn)源數(shù)據(jù)里就是這些值然后判斷是 Nginx 本身空閑還是采集路徑不對(duì)。如果源數(shù)據(jù)是對(duì)的Zabbix 只是如實(shí)展示不用改 Zabbix。5. 沒(méi)數(shù)據(jù)的排查鏈路按順序查別亂試5.1 四個(gè)環(huán)節(jié)從上到下檢查如果你最終面對(duì)的是一臺(tái)沒(méi)數(shù)據(jù)的 Nginx 主機(jī)不要先懷疑 Zabbix更不要反復(fù)重新鏈接模板。按下面的順序逐層排查通常能在十分鐘內(nèi)定位問(wèn)題。第一層Nginx 狀態(tài)頁(yè)是否可訪問(wèn)。curl -s http://127.0.0.1:80/nginx_status如果 curl 能返回純文本進(jìn)入下一層。如果返回 403、404 或 HTML 頁(yè)面問(wèn)題在 Nginx 側(cè)。第二層agent 能否讀到狀態(tài)頁(yè)。注意 agent 的運(yùn)行身份和權(quán)限。你可以切換到 agent 運(yùn)行用戶或者用 sudo 模擬執(zhí)行同樣的 curl 命令確認(rèn) agent 視角下能訪問(wèn)。如果 agent 在容器里還要確認(rèn)容器網(wǎng)絡(luò)。第三層Server 和 agent 之間是否連通且 Hostname 匹配。zabbix_get -s agent_ip -k agent.ping如果 zabbix_get 返回 1說(shuō)明網(wǎng)絡(luò)層通。然后再確認(rèn) Web 端主機(jī)名和 agent Hostname 一致。第四層模板宏和監(jiān)控項(xiàng)是否匹配。打開(kāi)監(jiān)控項(xiàng)列表查看具體監(jiān)控項(xiàng)的 key、宏替換后的實(shí)際地址用測(cè)試功能跑一次。如果返回錯(cuò)誤根據(jù)錯(cuò)誤信息調(diào)整宏。這個(gè)順序的核心思路是先確定是哪一層壞了再?zèng)Q定修哪里。不要在不知道哪一層出問(wèn)題的時(shí)候改配置改來(lái)改去只會(huì)讓狀態(tài)更亂。5.2 高頻錯(cuò)誤對(duì)照表下面這張表基本覆蓋了 Zabbix 監(jiān)控 Nginx 時(shí)最容易遇到的幾類現(xiàn)象現(xiàn)象常見(jiàn)原因處理思路狀態(tài)頁(yè) curl 返回 404沒(méi)有配置 location 或模塊缺失先查 nginx -V 里的 stub_status 模塊狀態(tài)頁(yè) curl 返回 403allow/deny 沒(méi)有放行 agent 來(lái)源 IP調(diào)整 allow 規(guī)則思考 agent 從哪個(gè) IP 訪問(wèn)監(jiān)控項(xiàng)顯示 unsupported itemagent 版本或模板類型不匹配確認(rèn)是 agent 還是 agent2換對(duì)應(yīng)模板或 key最新數(shù)據(jù)一直是空Hostname 不匹配、宏路徑不對(duì)、采集周期長(zhǎng)檢查主機(jī)名一致性測(cè)試宏替換后的地址監(jiān)控項(xiàng)返回 Connection refusedagent 未啟動(dòng)、端口不通、防火墻攔截systemctl status 看服務(wù)再用 zabbix_get 驗(yàn)證狀態(tài)頁(yè)返回的是 HTML 而非純文本location 配置被其他規(guī)則截獲檢查 server 塊順序確認(rèn)精確匹配位置這張表不是讓你背下來(lái)而是給你一個(gè)參考坐標(biāo)。遇到問(wèn)題時(shí)先看現(xiàn)象再判斷屬于哪一層然后去對(duì)應(yīng)位置檢查。5.3 沉淀一個(gè)“四層驗(yàn)收清單”最后一個(gè)能長(zhǎng)期復(fù)用的經(jīng)驗(yàn)把 Zabbix 監(jiān)控 Nginx 的鏈路固定成一張驗(yàn)收清單每次新接入一臺(tái) Nginx 主機(jī)時(shí)按順序過(guò)一遍。Nginx 狀態(tài)層模塊存在、location 配置正確、curl 返回純文本、allow 已放行 agent 來(lái)源 IP。Agent 采集層服務(wù)已啟動(dòng)、配置了正確的 Server/ServerActive、Hostname 與 Web 端一致、zabbix_get 驗(yàn)證 agent.ping 返回 1。Server 接入層Web 端主機(jī)存在、agent 接口可達(dá)、主機(jī)名匹配。模板匹配層鏈接了適配 agent 類型的 Nginx 模板、宏路徑/協(xié)議/端口正確、最新數(shù)據(jù)出現(xiàn)非空值。這個(gè)清單不是固定不變的但它能幫你把一次復(fù)雜的排查變成一次順序的確認(rèn)。以后不管是三臺(tái)機(jī)器還是三十臺(tái)機(jī)器先讓這種驗(yàn)證順序變成肌肉記憶再談自動(dòng)化。6. 適用邊界這套方案不是所有 Nginx 環(huán)境都適合6.1 適合誰(shuí)Zabbix 監(jiān)控 Nginx 這套方案適合的場(chǎng)景其實(shí)很清楚你已經(jīng)在用 Zabbix手里是一批長(zhǎng)期存在的虛擬機(jī)或物理機(jī)核心關(guān)注的是連接數(shù)、請(qǐng)求數(shù)、握手狀態(tài)等基礎(chǔ)指標(biāo)。這種情況下引入一套新的監(jiān)控系統(tǒng)成本遠(yuǎn)大于收益直接在 Zabbix 里接 Nginx 模板是最順的路。從我個(gè)人經(jīng)驗(yàn)看當(dāng)一個(gè)團(tuán)隊(duì)已經(jīng)用 Zabbix 管了幾百臺(tái)機(jī)器再為了 Nginx 單獨(dú)部署一套 Prometheus、Grafana反而不劃算。不是因?yàn)?Prometheus 不好而是你的告警、權(quán)限、儀表盤、值班流程都已經(jīng)長(zhǎng)在 Zabbix 上了新增一套系統(tǒng)意味著要同時(shí)維護(hù)兩套監(jiān)控體系的賬號(hào)、存儲(chǔ)和告警規(guī)則。6.2 不適合誰(shuí)反過(guò)來(lái)如果你的環(huán)境是大量短生命周期容器Nginx 實(shí)例像 Pod 一樣隨時(shí)擴(kuò)縮容Zabbix 這種以主機(jī)為單位的管理模型就會(huì)變得很吃力。每來(lái)一個(gè)新實(shí)例都要?jiǎng)?chuàng)建主機(jī)、鏈接模板、維護(hù) Hostname規(guī)模一大這些動(dòng)作本身就是運(yùn)維負(fù)擔(dān)。另外如果業(yè)務(wù)需要按 URL、按狀態(tài)碼、按 upstream 做細(xì)粒度 SLA 分析單靠 Zabbix 的 Nginx 狀態(tài)頁(yè)數(shù)據(jù)也不夠。狀態(tài)頁(yè)給的是連接數(shù)和請(qǐng)求總數(shù)拿不到每個(gè)接口的響應(yīng)時(shí)間分布。這種需求更適合讓 Nginx 輸出 access log 結(jié)構(gòu)化、再送進(jìn)時(shí)序數(shù)據(jù)庫(kù)或者日志系統(tǒng)或者直接采用具有服務(wù)發(fā)現(xiàn)能力的監(jiān)控方案。這不是說(shuō) Zabbix 不能做擴(kuò)展而是說(shuō)你要先判斷值不值得。任何方案都有維護(hù)成本Zabbix Nginx 監(jiān)控的優(yōu)勢(shì)是簡(jiǎn)單直接代價(jià)是深度有限。認(rèn)清這個(gè)邊界比盲目堆監(jiān)控項(xiàng)更重要。6.3 重要的不是某一個(gè)命令而是適應(yīng)變化的能力回到標(biāo)題里那半句“和過(guò)去有一點(diǎn)不同”。這句話其實(shí)很適合用來(lái)概括這類監(jiān)控方案的常態(tài)Nginx 的編譯參數(shù)在變agent 從舊版走向 agent2模板名稱和宏定義在變安裝方式從裸機(jī)走向容器。過(guò)兩年你再回頭看今天這篇文章里的具體配置很可能又有出入。但有一點(diǎn)不會(huì)變數(shù)據(jù)從 Nginx 到 agent 再到 Server 這條鏈路的邏輯是穩(wěn)定的。你只要掌握了“先 curl 狀態(tài)頁(yè)、再 zabbix_get 探活、最后看模板宏”的驗(yàn)證順序無(wú)論版本怎么升級(jí)你都能在最短時(shí)間內(nèi)判斷出問(wèn)題出在哪一層。這才是比某一條命令更有價(jià)值的東西。所以我的長(zhǎng)期建議是不要只收藏某個(gè)版本的配置片段而是順手把自己的環(huán)境、模板名稱、宏定義、驗(yàn)證命令寫成一個(gè)簡(jiǎn)短文檔或腳本。下次再遇到 Nginx 監(jiān)控沒(méi)數(shù)據(jù)你不是回去翻舊教程而是打開(kāi)自己的排查清單?；氐介_(kāi)頭那個(gè)案例。我們最后做的事情其實(shí)很簡(jiǎn)單把 stub_status 狀態(tài)頁(yè)配置好allow 規(guī)則放行 agent 來(lái)源 IP再把 Web 端主機(jī)名和 agent Hostname 改成一致。數(shù)據(jù)在第二個(gè)更新周期就出現(xiàn)了。整個(gè)過(guò)程沒(méi)有任何懸案只是之前分散在不同教程里的經(jīng)驗(yàn)沒(méi)有串成一條完整的鏈路。Nginx 側(cè)會(huì)變、Zabbix 會(huì)變、模板會(huì)變但驗(yàn)證順序不會(huì)變。下次再看到最新數(shù)據(jù)為空時(shí)不要急著在界面上反復(fù)點(diǎn)先打開(kāi)一個(gè)終端curl 一下?tīng)顟B(tài)頁(yè)很多時(shí)候答案早就寫在響應(yīng)里了。