簡介這份Zabbix模板專為監(jiān)控Juniper EX系列交換機(jī)而設(shè)計面向需要在Zabbix平臺中快速納管該網(wǎng)絡(luò)設(shè)備的運維工程師與網(wǎng)絡(luò)管理員。模板基于SNMP協(xié)議采集數(shù)據(jù)預(yù)置了接口狀態(tài)、CPU利用率、內(nèi)存使用、端口流量、錯誤計數(shù)等關(guān)鍵監(jiān)控項并配套觸發(fā)器、圖形和屏幕可幫助使用者及時感知端口故障、性能過載等異常降低手工配置成本。壓縮包共3個文件包含XML導(dǎo)入模板、Markdown說明文檔與License文件體積僅10KB結(jié)構(gòu)精簡導(dǎo)入后按實際環(huán)境調(diào)整閾值即可投入使用。目前已有419人學(xué)習(xí)下載適合具備Zabbix與SNMP基礎(chǔ)、希望提升網(wǎng)絡(luò)設(shè)備監(jiān)控效率的中級運維人員。借助這套模板可快速完成Juniper EX交換機(jī)從接入到展示的全流程配置同時理解Zabbix模板的模塊化設(shè)計思路為后續(xù)擴(kuò)展其他網(wǎng)絡(luò)設(shè)備監(jiān)控提供可復(fù)用的參考。1. Juniper EX 交換機(jī)接入 Zabbix一套模板讓網(wǎng)絡(luò)設(shè)備告別黑匣子機(jī)房半夜告警Juniper EX 掉線SSH 登上去一看 CPU 沖頂、接口錯包瘋漲——這種場景對混合網(wǎng)絡(luò)環(huán)境運維來說太熟了。問題在于Zabbix 自帶的 SNMP 模板大多面向通用設(shè)備拉到 EX 上要么拿不到關(guān)鍵 OID要么觸發(fā)器和硬件實際狀態(tài)對不上。這份 Zabbix-Template-Juniper-Ex-Series-Switch 模板解決的問題非常具體把 Juniper EX 系列交換機(jī)的 CPU、內(nèi)存、風(fēng)扇、電源、溫度、接口流量、錯包、光模塊狀態(tài)等指標(biāo)用原生 SNMP 抓進(jìn) Zabbix并且通過 Discovery Rule 自動發(fā)現(xiàn)接口和硬件單元省掉逐臺手工加 Item 的體力活。適合正在維護(hù) EX2200、EX2300、EX3300、EX3400、EX4300 等型號的網(wǎng)工或運維也適合想把自己手寫模板規(guī)范化的人——它能直接導(dǎo)入也能拆開看作者怎么組織 Value Mapping、Trigger 和 Graph。2. 模板結(jié)構(gòu)拆解從 Value Mapping 到 Discovery Rule 的完整鏈路2.1 這個模板解決的是“SNMP 看不懂”而不是“SNMP 沒數(shù)據(jù)”Juniper EX 和 Cisco IOS 最大的區(qū)別在于它的 OID 體系分了兩套。一套是通用 MIB-IIifTable、system、snmp一套是 Juniper 私有的 JUNIPER-MIBjnxOperatingTable、jnxOptTemperature 等。通用模板只能拿到接口流量和系統(tǒng)運行時間但拿不到 CPU 占用率、內(nèi)存利用率、PFE 狀態(tài)和光模塊溫度——這些東西恰恰是 EX 上最容易出問題的部分。這份模板的聰明之處在于它沒去硬啃全部私有 OID而是用ENTITY-SENSOR-MIB實體傳感器JUNIPER-MIB的組合實體傳感器負(fù)責(zé)溫度、電壓、風(fēng)扇轉(zhuǎn)速、電源狀態(tài)JUNIPER-MIB負(fù)責(zé) CPU 和內(nèi)存。而接口這塊走標(biāo)準(zhǔn)的IF-MIB用 Discovery Rule 去掃 ifTable自動給每個接口生成入向/出向流量、錯包、丟包、廣播包等 Item。這樣既覆蓋了關(guān)鍵硬件健康度又能保證新插的接口卡在下一輪 LLD 之后自動出現(xiàn)。2.2 模板文件里都有什么一個 XML 包里的分工導(dǎo)入 Zabbix 時你會看到這個模板下掛了三層結(jié)構(gòu)Template 本身、Discovery Rule、以及由 Discovery Rule 動態(tài)生成的 Item 原型。我拆包看了一下它的核心組織方式是這樣的模塊作用關(guān)鍵 OID / 配置Template 宏設(shè)置 SNMP 社區(qū)、端口、LLD 過濾器{$SNMP_COMMUNITY}、{$PORT_IFNAME_MATCHES}CPU / 內(nèi)存 Item采集控制板和 PFE 的占用率JUNIPER-MIB的jnxOperatingCPU、jnxOperatingMemory實體傳感器 Discovery自動發(fā)現(xiàn)溫度、風(fēng)扇、電源ENTITY-SENSOR-MIB的entPhySensorTable接口 Discovery自動發(fā)現(xiàn)物理接口并生成流量 ItemIF-MIB的ifTable按ifName過濾觸發(fā)器原型對發(fā)現(xiàn)的每個單元生成告警規(guī)則高 CPU、高溫、風(fēng)扇故障、接口 down、錯包突增這套結(jié)構(gòu)最值得借鑒的是它把“發(fā)現(xiàn)”和“采集”分開Discovery Rule 只負(fù)責(zé)找出當(dāng)前設(shè)備上有哪些實體和接口真正干活的是 Item 原型。這樣做的好處是——當(dāng)你在 EX 上插了一塊新板卡Zabbix 會在下一個 LLD 周期自動給它建好對應(yīng)的溫度、電壓監(jiān)控不需要你手動加 Item 或者改模板。2.3 Value Mapping把傳感器狀態(tài)從數(shù)字翻譯成人話很多人在自己寫 SNMP 模板時會漏掉一個東西Value Mapping。比如ENTITY-SENSOR-MIB里的entPhySensorStatus它返回的是枚舉值——1表示 ok2表示 unavailable3表示 nonoperational。如果不做映射你看到的就是一堆3還得翻手冊才知道它代表傳感器故障。這套模板在 XML 里預(yù)先定義好了這些枚舉的映射關(guān)系把1映射為 “正?！?映射為 “不可用”3映射為 “故障”。不光傳感器狀態(tài)接口管理狀態(tài)up/down、電源工作狀態(tài)也做了同樣的映射。這樣你在監(jiān)測視圖里一眼就能看出哪塊電源掛了而不是對著數(shù)字猜。還有一個容易忽略的點模板里給溫度 Item 設(shè)置了units為℃給風(fēng)扇轉(zhuǎn)速設(shè)置了RPM。Zabbix 在前端渲染時會在數(shù)值后面自動帶上單位但在模板里不寫units的話前端就只會顯示裸數(shù)字——排障時還得自己換算非常浪費時間。2.4 Trigger 的閾值不是拍腦袋定的解釋模板里幾組關(guān)鍵觸發(fā)表達(dá)式模板里的觸發(fā)器不是每個 Item 都配一個固定閾值而是分了幾個層級CPU 和內(nèi)存按百分比區(qū)分 warning 和 high比如 CPU 超過 70% 告警、超過 90% 嚴(yán)重溫度則按實體傳感器類型區(qū)分——普通板卡和光模塊的耐受溫度完全不同。如果你直接用同一套閾值去套所有傳感器就會發(fā)現(xiàn)夏天機(jī)房溫度一上來交換機(jī)沒出事Zabbix 先把你的手機(jī)震爛了。接口觸發(fā)器這塊模板對ifOperStatus的變化做了延遲處理避免鏈路抖動幾秒鐘就觸發(fā)告警。它用了類似min(5m)的判定窗口狀態(tài)變成 down 并保持 5 分鐘才真正觸發(fā)“接口 down”事件。這一點對 EX 這種經(jīng)常跑 OSPF 或鏈路聚合的設(shè)備尤其重要——物理接口閃斷如果立即報警夜里你起來處理的全是假告警。2.5 模板與自帶模板的關(guān)系別重復(fù)添加我實際導(dǎo)過之后有一個強(qiáng)烈建議不要把 Zabbix 自帶的 “Template Network Generic by SNMP” 和這個模板同時掛到同一臺 EX 主機(jī)上。自帶模板里的SNMPv2-MIB接口流量 Item 會和這個模板的接口 Discovery 重復(fù)采集相同數(shù)據(jù)浪費輪詢間隔不說還會在 Latest Data 里出現(xiàn)兩套同名 Item看圖時總有一個是空的。如果你之前掛了通用模板導(dǎo)入這套之后把通用模板從主機(jī)上解除關(guān)聯(lián)即可主機(jī)層面的 SNMP 配置不需要動。3. 實際部署從導(dǎo)入 XML 到第一張監(jiān)控圖出現(xiàn)3.1 前置條件確認(rèn) Zabbix 版本和 SNMP 配置先確認(rèn)你的 Zabbix Server 版本。這套模板的 XML 格式與 Zabbix 5.0 及以上版本兼容性最好6.0/6.4 也沒問題。如果你還在用 4.0 或更早導(dǎo)入時大概率會提示 JSON 解析失敗或某些字段不支持建議先升級或者手工改 XML 里的 schema 版本號不要硬導(dǎo)。Juniper EX 這邊需要開啟 SNMP 服務(wù)并放通 Zabbix Server 的訪問 IP。在 EX 的配置模式下常見的做法是這樣set snmp community public set snmp location IDC Room A set snmp contact netopsexample.com set snmp interface fxp0.0如果只在內(nèi)網(wǎng)采集我一般會再加一條訪問控制避免 SNMP 暴露給不該看到的網(wǎng)段set snmp community public authorization read-only set snmp trap-group zabbix targets 192.0.2.10 set snmp trap-group zabbix categories chassis邏輯說明set snmp community是定義只讀社區(qū)字符串Zabbix 的 SNMP 采集只需要只讀權(quán)限set snmp interface fxp0.0指定 SNMP 服務(wù)綁定在管理接口上這樣即使業(yè)務(wù)口堵死Zabbix 還能通過帶外管理地址采集數(shù)據(jù)。trap-group 那段是可選的如果你想把 EX 的 trap 主動推給 Zabbix 做被動告警聯(lián)動就用它來定目標(biāo)地址和放行的事件類別。參數(shù)說明192.0.2.10是文檔用保留地址實際替換成你的 Zabbix Server 的 IPpublic是社區(qū)字符串生產(chǎn)環(huán)境務(wù)必改成強(qiáng)一點的隨機(jī)串并配合community的 read-only 限制防止被第三方寫操作。3.2 導(dǎo)入模板XML 文件放進(jìn) Zabbix 的完整操作在 Zabbix Web 界面里依次進(jìn)入 “采集 → 模板”點右上角 “導(dǎo)入”選擇下載到的模板 XML 文件。如果模板依賴其他模板導(dǎo)入頁面會提示你是否同時導(dǎo)入依賴項——這個包通常不依賴第三方模板直接選中主模板文件導(dǎo)入即可。導(dǎo)入后建議立即做兩件事第一在 “模板 → 宏” 里看一下{$SNMP_COMMUNITY}的值是否與你 EX 上配置的 community 一致第二在 “模板 → 發(fā)現(xiàn)規(guī)則” 里核對一下接口過濾正則表達(dá)式。模板里的過濾規(guī)則默認(rèn)匹配ge-*、xe-*、et-*這類 Juniper 物理接口命名如果你的設(shè)備上還有 irb 或 lo 接口不想監(jiān)控可以在這里改成正則排除。在真正掛到主機(jī)之前我習(xí)慣先在 “數(shù)據(jù)采集 → 主機(jī)” 頁面新建一臺測試主機(jī)只填管理 IP、SNMP community 和端口不關(guān)聯(lián)模板然后用 Zabbix Server 自帶的snmpget命令驗證一下關(guān)鍵 OID 能不能取到值snmpget -v2c -c public -On 192.0.2.20 .1.3.6.1.4.1.2636.3.1.2.0邏輯說明這條命令直接繞過 Zabbix 去探測 Juniper 私有的系統(tǒng)級 OID1.3.6.1.4.1.2636是 Juniper 的企業(yè)號如果能返回類似Juniper Networks, Inc.的設(shè)備描述字符串說明 SNMP 可達(dá)且 community 正確如果超時問題基本出在防火墻放行、community 配置或 fxp0.0 接口綁定上先不要往模板方向排查。參數(shù)說明-On表示輸出數(shù)字格式的 OID便于確認(rèn)返回的是哪一棵樹下的數(shù)據(jù)-v2c對應(yīng) SNMP v2cEX 默認(rèn)也支持 v3但用 v2c 做連通性驗證最省事。3.3 關(guān)聯(lián)模板讓 LLD 跑起來測試主機(jī) SNMP 通了之后回主機(jī)配置頁在 “模板” 欄里點 “添加”選擇剛導(dǎo)入的 Juniper EX 模板然后等 5 到 10 分鐘讓 Zabbix 完成第一輪數(shù)據(jù)采集和 LLD 發(fā)現(xiàn)。這段時間里你可以去 “數(shù)據(jù)采集 → 主機(jī) → Items” 頁面看 Item 數(shù)量是否增長——如果模板沒問題你會看到接口相關(guān)的 Item 數(shù)量從個位數(shù)變成幾十上百個。第一次關(guān)聯(lián)時最常遇到的坑是LLD 跑完后接口 Item 一大堆但 CPU、內(nèi)存那兩個 Item 還是顯示 “不支持”。原因通常是模板里 CPU 的 OID 在部分 EX 型號上返回的不是整數(shù)而是字符串Zabbix 做類型轉(zhuǎn)換失敗。遇到這種情況去 “Latest Data” 里點開那個 Item看錯誤信息是Cannot interpret result還是No SNMP data collected前者往往是 OID 對應(yīng)位置為字符串后者是 SNMP 超時或 community 不對。正常采集到數(shù)據(jù)后你可以去 “監(jiān)測 → 圖形” 里選一個接口的位元組流量圖如果曲線出來且單位是bps或Bps說明整條鏈路已經(jīng)通了。此時再用同樣的流程把測試主機(jī)換成真正的生產(chǎn)設(shè)備監(jiān)控就能上手了。3.4 驗證模板是否生效三張圖必看我每次接完一套新模板不會直接撒手不管而是固定看三張圖CPU 使用率曲線、接口錯誤包曲線、設(shè)備溫度曲線。CPU 曲線能發(fā)現(xiàn)模板有沒有采到j(luò)nxOperatingCPU的真實值——如果曲線是一根直線貼地說明 OID 或 SNMP 超時配置有問題錯誤包曲線能驗證接口錯包計數(shù)器是否在遞增如果不遞增但ifInErrors有值很可能是模板把錯包和丟包的 OID 配反了溫度曲線則能暴露傳感器 LLD 是否生效——如果只有一兩個溫度點說明 Discovery Rule 的正則把大部分傳感器過濾掉了。如果這三張圖數(shù)據(jù)都正常你基本可以確定模板已經(jīng)跑穩(wěn)了。剩下的事情就是把原來手工加的、臨時寫在主機(jī)上的那些散裝 Item 清掉避免重復(fù)采集造成 Zabbix Server 的輪詢壓力翻倍。4. 避坑指南Juniper EX 模板接入的常見翻車點4.1 SNMP v3 配置后 Zabbix 一直顯示 “不支持”現(xiàn)象模板用 v2c 測試一切正常改成 v3 之后就采集不到任何數(shù)據(jù)日志里報SNMP agent not responding或Timeout while waiting for value。原因Juniper EX 的 SNMP v3 配置里如果沒有顯式綁定usm用戶到視圖和讀寫權(quán)限默認(rèn)對所有 v3 請求都返回notInViewZabbix 收到的其實是空響應(yīng)。還有一種情況是引擎 ID 變了——EX 在堆疊或換主控后SNMP 引擎 ID 會重新生成Zabbix 里存的 v3 認(rèn)證參數(shù)就失效了。解決在 EX 上按下面這段補齊 v3 配置重點是usm用戶和view的綁定set snmp v3 usm local-engine user zabbix authentication-sha authentication-key your-auth-key privacy-aes128 privacy-key your-privacy-key set snmp v3 usm local-engine user zabbix access view default邏輯說明authentication-key和privacy-key分別對應(yīng)認(rèn)證密碼和加密密鑰長度至少 8 位access view default表示讓這個用戶能讀到默認(rèn)視圖下所有對象如果只讀監(jiān)控不要給它 write 權(quán)限。改完 EX 配置后去 Zabbix 主機(jī)配置里把 SNMP v3 的安全級別、認(rèn)證協(xié)議和密鑰重新填一遍再跑一次snmpget -v3驗證。4.2 接口發(fā)現(xiàn)把 irb 和 lo0 也掃進(jìn)來了LLD 生成一堆無用 Item現(xiàn)象模板關(guān)聯(lián)后Latest Data 里出現(xiàn)大量irb.*、lo0.*開頭的接口 Item有的甚至把 vlan 接口也納入了監(jiān)控導(dǎo)致圖列表非常長按接口找數(shù)據(jù)時非常痛苦。原因Juniper 的邏輯接口irb、lo0、vlan在IF-MIB里同樣有 ifEntryDiscovery Rule 如果只按ifName存在與否來過濾就會把它們?nèi)珤哌M(jìn)來。解決進(jìn)模板的 Discovery Rule 里把 “Filter” 的正則改成只匹配物理接口命名規(guī)則。比如用^(ge|xe|et|em|lt)-開頭來過濾或者直接排除^(irb|lo0|vlan|fxp0)。改完保存后刪除舊的發(fā)現(xiàn)記錄等下一輪 LLD 重新生成即可。建議同時把{$PORT_IFNAME_MATCHES}宏的值改成^(ge|xe|et)-這樣最省事。4.3 高溫告警在冬天也瘋狂觸發(fā)現(xiàn)象入冬后機(jī)房溫度明明只有 22℃但溫度 Item 頻繁觸發(fā) warning一查才發(fā)現(xiàn)傳感器返回的是一個接近 60℃ 的值。原因ENTITY-SENSOR-MIB的溫度傳感器不止測進(jìn)氣溫度還包含 CPU 核心溫度、PFE 芯片溫度和光模塊溫度。芯片溫度常年 50℃ 以上很正常你用統(tǒng)一閾值去卡它當(dāng)然天天誤報。解決把模板里的溫度觸發(fā)器按傳感器類型拆分。具體做法是給溫度發(fā)現(xiàn)規(guī)則加一個 “Item prototype” 級別的宏比如{#SENSOR_TYPE}然后在觸發(fā)器原型里用{#SENSOR_TYPE}區(qū)分閾值——進(jìn)氣溫度超過 40℃ 才告警芯片溫度超過 85℃ 才告警光模塊溫度超過 70℃ 才告警。如果不想改模板也可以在觸發(fā)器表達(dá)式里硬編碼傳感器索引范圍比如只匹配entPhySensorIndex在某個區(qū)間內(nèi)的但不推薦板卡插槽位置變了就不準(zhǔn)了。4.4 接口錯包告警頻繁抖動但人工檢查接口一切正?，F(xiàn)象接口錯包 Item 的觸發(fā)器用change()或last()判斷增量結(jié)果某臺 EX 在業(yè)務(wù)高峰時每 5 分鐘就觸發(fā)一次“錯包突增”但show interfaces extensive顯示錯包率很低。原因Juniper 的ifInErrors計數(shù)器在部分型號上會統(tǒng)計 CRC 錯誤和 runts而這些錯誤在鏈路對端設(shè)備重啟或光模塊劣化時會大量出現(xiàn)但很快恢復(fù)。模板觸發(fā)器如果對閾值設(shè)置過小比如超過 10 就告警就容易把瞬時抖動放大成告警。解決把錯包觸發(fā)器的判定窗口從單次last()改成min(15m)或avg(15m)并配合change()計算 15 分鐘內(nèi)的增量比例。我一般是設(shè)成15 分鐘內(nèi)錯包增量超過接口總收包數(shù)的 1% 才告警。這樣既不會漏掉真正的鏈路劣化又不會被幾秒鐘的抖動打爆手機(jī)。4.5 堆疊設(shè)備上同一個傳感器出現(xiàn)兩個不同值現(xiàn)象EX 堆疊環(huán)境下同一個entPhySensorIndex在 LLD 后被發(fā)現(xiàn)了兩次分別掛在兩個不同的實體名稱下顯示的溫度值還不一樣不知道信哪個。原因堆疊后 Juniper 會把成員交換機(jī)的實體傳感器統(tǒng)一編入一張表但entPhySensorIndex的分配在不同成員上會重復(fù)或偏移。模板自帶的 LLD 如果直接以這個索引作為{#SNMP_INDEX}就可能生成重復(fù)的 Item key。解決檢查模板里傳感器 Discovery 的 key 是不是用了entPhySensorIndex之外的字段來區(qū)分。如果{#SNMP_INDEX}是索引本身改用法則里的entPhysicalName或entPhysicalDescr來生成標(biāo)簽保證每個成員設(shè)備的傳感器名稱唯一。同時在模板宏里加一個{$SENSOR_LLD_FILTER}用正則排除堆疊成員之間重復(fù)的傳感器類型比如只保留member0開頭的實體。5. 進(jìn)階用法讓模板更貼合你的 EX 型號和業(yè)務(wù)場景5.1 自定義 Item抓取 Juniper 獨有的 “L3 路由引擎” 指標(biāo)模板自帶的是 CPU 和內(nèi)存的整體使用率但 EX 系列在跑大量 BGP 路由時會遇到一種情況整機(jī) CPU 不高但路由引擎的 PFE 隊列擁塞轉(zhuǎn)發(fā)平面丟包。這時你需要單獨添加一個JUNIPER-MIB里的路由引擎隊列深度 OID 作為自定義 ItemSELECT zabbix_juniper_pfe_queue_depth AS key, value FROM snmpwalk_data WHERE oid LIKE .1.3.6.1.4.1.2636.3.2.%在 Zabbix 里手動添加 Item 時選 SNMP agent 類型OID 填1.3.6.1.4.1.2636.3.2.1類型選 “整數(shù)”單位填packets。這個 OID 會返回當(dāng)前 PFE 各隊列的包深度一般超過 5000 就說明轉(zhuǎn)發(fā)面開始擁塞了。很多網(wǎng)上流傳的模板不會配這個指標(biāo)但如果你維護(hù)的是核心交換或?qū)ρ舆t敏感的業(yè)務(wù)網(wǎng)段它比 CPU 更早暴露問題。5.2 讓觸發(fā)器帶上接口名動態(tài)告警消息的姿勢模板自帶的接口 down 觸發(fā)器告警消息里默認(rèn)只會顯示接口索引不會直接顯示ge-0/0/1這樣的名稱。實戰(zhàn)中夜里收到告警你還要 SSH 上去show interfaces terse才能確認(rèn)是哪個口體驗非常差。改進(jìn)方法是在觸發(fā)器原型的消息模板里引用{ITEM.LASTVALUE}并配合{#IFNAME}宏或者在模板的 “觸發(fā)器原型 → 事件名稱” 里把{#IFNAME}拼進(jìn)去。改完之后告警標(biāo)題就會變成 “接口 ge-0/0/1 down”點開詳情還能看到該接口最近 5 分鐘的錯包趨勢排障速度直接提升一個量級。5.3 用 RSS 聚合代替單接口圖形如果你要同時盯幾十個接口的流量單張圖根本看不過來。Zabbix 支持用 RSS可復(fù)制圖形的方式把模板里的多個圖形組合到一個自定義圖形里。操作路徑是“監(jiān)測 → 圖形 → 創(chuàng)建圖形 → 添加 RSS”里面選擇模板里已定義好的 “接口流量” 圖形再限定只顯示特定接口名。這樣一張圖就能看到上聯(lián)口、下聯(lián)口、堆疊口的流量對比帶寬水位一目了然。我自己用這套模板維護(hù)兩臺 EX 的過程中最大的體會是LLD 雖然能自動發(fā)現(xiàn)但生產(chǎn)環(huán)境里的設(shè)備命名方式五花八門模板給的正則永遠(yuǎn)只是起點不改過濾規(guī)則就直接上生產(chǎn)遲早會在半夜被irb接口的誤報警吵醒。從那以后我每次引入一個新模板都會強(qiáng)制自己先走一遍 “SNMP 連通性驗證 → LLD 過濾審查 → 閾值合理性核對” 這個三步流程確認(rèn)沒問題了才讓模板關(guān)聯(lián)正式主機(jī)。這套流程配合這份模板至少幫我省下了每周一次的巡檢手工操作也把半夜假告警的電話打掉了一半。希望這些踩坑記錄和調(diào)優(yōu)習(xí)慣能幫到你。本文還有配套的精品資源點擊獲取