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