簡介面向Zabbix網絡運維人員的交換機監(jiān)控模板資源解決手動配置SNMP監(jiān)控項繁瑣、效率低的問題。壓縮包內共2個XML模板文件整體僅3KB分別適用于SNMP v1與v2公共協(xié)議便于兼容不同交換機的SNMP配置環(huán)境。模板預設了端口入/出帶寬、接口狀態(tài)、丟包率、錯誤統(tǒng)計等常見監(jiān)控項導入Zabbix并關聯(lián)主機后即可自動生成對應指標采集、閾值觸發(fā)器和可視化圖形幫助運維團隊快速掌握設備運行狀況既可用于日常健康監(jiān)測也可在故障排查時快速定位異常端口。模板基于公共社區(qū)字符串設計默認端口161可批量納管多臺交換機通過預定義告警規(guī)則能對接口宕機、帶寬突增等異常及時發(fā)送通知。資源同時提示SNMP版本差異若網絡環(huán)境安全要求較高建議優(yōu)先采用具備身份驗證與加密能力的v3而v1/v2適用于內網或低敏感場景。目前已有2790人學習下載文件結構清晰、體量輕量適合需要快速上手Zabbix交換機監(jiān)控的入門運維人員也可為有經驗的管理員提供模板編寫與排錯參考。1. zabbix_交換機模板把一臺臺手工登錄的網管設備變成平臺自動納管網絡工程師最容易遇到的一件難受事不是交換機壞了而是“壞的時候你才知道它壞了”。zabbix_交換機模板這個項目做的就是給 Zabbix 監(jiān)控平臺補上一套專門面向交換機的監(jiān)控能力不裝 agent、不靠 SSH 一條條抓命令而是統(tǒng)一走 SNMP 協(xié)議把華為、H3C、銳捷這些網管型交換機納管進來一次把模板調好之后每新增一臺設備就復制一臺主機端口狀態(tài)、流量、CPU、光模塊信息自動出現(xiàn)在同一個大屏里。對正在搭運維監(jiān)控、又不想寫一堆腳本輪詢的人來說這套方案能直接把“手工登錄看交換機狀態(tài)”變成“告警主動找上門”。這篇筆記從協(xié)議選型講到模板導入、LLD 端口發(fā)現(xiàn)最后是生產環(huán)境里最容易翻車的幾個坑。2. 用 SNMP 而不是 agent交換機模板的協(xié)議選型與監(jiān)控項基本盤2.1 為什么交換機監(jiān)控幾乎不用 Zabbix agentZabbix 常規(guī)的監(jiān)控路徑是往 Linux 或 Windows 主機上裝一個 agent由 agent 把系統(tǒng)指標上報給 server。但交換機是另一類設備大部分交換機的操作系統(tǒng)是廠商私有固件不開放 arbitrary 軟件安裝哪怕少數(shù)型號支持 Python 腳本也不會為監(jiān)控平臺單獨跑一個 agent 進程。所以交換機的監(jiān)控在協(xié)議層面基本只有一條主流路線——SNMP簡單網絡管理協(xié)議端口 161/UDP由設備內置的 SNMP agent 響應查詢。Zabbix 對 SNMP 的支持非常成熟模板本質上就是一組預定義好的 SNMP OID 集合套上設備地址和 community 就能采集。SNMP 還有一個天然優(yōu)勢廠商基本把交換機所有對外可見的硬件狀態(tài)都掛在 MIB 樹上了從 CPU 利用率、內存占用、端口收發(fā)計數(shù)到風扇轉速、溫度、光模塊收發(fā)功率。這意味著只要 MIB 樹里有的信息Zabbix 就能收不用等廠商為 Zabbix 專門寫插件。Zabbix agent 辦不到的事SNMP 模板反而辦得更干凈。2.2 模板里到底有什么五類監(jiān)控項按需決定留還是刪打開一個成熟的 zabbix_交換機模板你會發(fā)現(xiàn)監(jiān)控項并不是隨便堆的大致分成五類我這里給你一張可以直接用的分類表監(jiān)控項分組典型數(shù)據來源作用模板里默認保留建議設備存活ICMP ping、sysUpTime判斷交換機是否在線、是否重啟過務必保留系統(tǒng)資源CPU 利用率、內存利用率判斷設備是否過載務必保留閾值要按廠商建議調接口狀態(tài)ifOperStatus、ifAdminStatus端口 Up/Down、管理員是否手動禁用務必保留這是交換機最核心的監(jiān)控接口流量ifHCInOctets、ifHCOutOctets端口出入帶寬務必保留注意選 64 位計數(shù)器光模塊/溫度廠商私有 MIB如華為的實體傳感器光功率、溫度、電壓視型號保留默認模板不一定覆蓋我一般拿到模板第一步不是直接關聯(lián)到所有交換機而是先展開模板看兩個地方第一流量相關的監(jiān)控項是不是用的 ifHCInOctets 這種 64 位計數(shù)器第二接口發(fā)現(xiàn)用的是 ifIndex 還是 ifDescr。這兩點直接決定你后面會不會半夜被誤報吵醒具體原因到第 5 章細說。前一類錯了流量圖會出現(xiàn)負值和尖刺后一類錯了交換機重啟后端口監(jiān)控可能直接張冠李戴。模板里少量不必要的項刪掉也沒有問題比如不監(jiān)控 VoIP 語音 VLAN 的話和語音相關的 MIB 監(jiān)控項可以直接禁用減少不必要的 SNMP 輪詢壓力。2.3 先做 SNMP 握手再改模板三個命令判斷設備 MIB 是否正常模板關聯(lián)到設備之前一定要先確認交換機的 SNMP 服務真的能通。常見做法不是直接去 Zabbix 前端測試而是在你本機先裝好 snmp 工具包用命令行做一次握手。以一臺華為交換機為例先看系統(tǒng)基本信息# 語法: snmpget -v版本 -c community 交換機IP OID snmpget -v2c -c Zabbix2024 192.168.10.1 1.3.6.1.2.1.1.1.0這里的-v2c表示使用 SNMP v2c 協(xié)議-c Zabbix2024是交換機上配置的只讀 community 字符串1.3.6.1.2.1.1.1.0是 sysDescr 的 OID返回內容應該是“Huawei Versatile Routing Platform Software”之類的設備描述。能返回就說明基礎通路沒問題。接著查一下接口表能不能正常枚舉這決定后面 LLD 端口發(fā)現(xiàn)是否可行# 枚舉交換機所有物理和虛擬接口的 ifName snmpwalk -v2c -c Zabbix2024 192.168.10.1 1.3.6.1.2.1.31.1.1.1.1這條命令會列出一串接口名比如 GigabitEthernet0/0/1、Vlanif10、NULL0 等等。如果你只關心接口名是否齊全這步足夠了。如果你還要驗證光模塊的 OID 是否可用就用 snmpwalk 去探測廠商私有節(jié)點。但廠商私有 MIB 節(jié)點在不同型號上差異很大不要直接照抄網上的 OID正確做法是先下載對應型號的 MIB 文件再用snmptranslate或snmpwalk定位傳感器節(jié)點。沒有做這步握手就導入模板最常見的后果是模板里的監(jiān)控項全部報“Not supported”前端的報錯能刷一整頁。3. 把模板落到設備上導入模板、關聯(lián)主機、交換機側 SNMP 配置3.1 從官方模板倉庫拿到 XML 之后的三個動作Zabbix 官方維護了一套面向網絡設備的模板倉庫里面就有專門為交換機設計的模板比如 “Template Network Generic by SNMP” 這類。拿到 XML 文件后我不建議立刻上傳先做三個動作第一用文本編輯器打開掃一眼模板里是否包含ifHCInOctets和ifHCOutOctets兩個關鍵監(jiān)控項鍵值防止拿到的是個閹割版第二確認模板里的宏定義了哪些比如{$SNMP_COMMUNITY}、{$IFNAME_MATCHES}、{$IFNAME_NOT_MATCHES}這些宏后面要在主機級別覆蓋第三把原始 XML 備份一份到本地模板升級前后要能對比差異。導入動作本身很簡單在 Zabbix 前端進入 “Data collection → Templates”點右上角 “Import”選擇 XML 文件導入后會提示成功或報錯。報錯最常見的原因是模板依賴的另一個模板不存在比如模板聲明依賴 “Template Module Interfaces” 而你沒一起導入。這時別慌去模板倉庫把依賴模板一并下載導入即可一般情況下官方會把依賴關系寫在模板描述里。3.2 交換機側 SNMP 配置華為命令行與 H3C 命令行對照模板準備好之后還得讓交換機愿意被讀。華為和 H3C 的命令行習慣不一樣我列出最常見的最小配置以只讀 communityZabbix2024為例。華為 VRP 平臺交換機上# 進入系統(tǒng)視圖 system-view # 啟用 SNMP v2c同時保留 v3 不開啟以免兼容性問題 snmp-agent sys-info version v2c # 配置只讀 community snmp-agent community read cipher Zabbix2024 # 只允許 Zabbix server 的 IP 訪問 SNMP 服務 acl number 2001 rule 5 permit source 192.168.100.10 0 quit snmp-agent community read cipher Zabbix2024 acl 2001這里的cipher關鍵字表示在配置文件中加密存儲 community防止別人登錄設備后直接看到明文。ACL 限制來源是為了避免 community 泄露后被內網任意機器輪詢這在辦公網里尤其重要。配置完成后可以用display snmp-agent community查看當前生效的 community 列表確認無誤。H3C Comware 平臺的交換機配置思路相同但關鍵字有差異system-view snmp-agent sys-info version v2c snmp-agent community read simple Zabbix2024 acl basic 2001 rule 0 permit source 192.168.100.10 0 quit snmp-agent community read simple Zabbix2024 acl 2001H3C 用的是simple而不是cipher表示 community 以明文顯示這是兩個平臺最容易搞混的地方。另外華為有些老款交換機默認snmp-agent沒啟用需要先執(zhí)行snmp-agent再配置其他參數(shù)。這些命令只是最小可用配置生產環(huán)境里如果你的交換機開啟了 SNMP v3建議直接走 v3 用戶認證Zabbix 模板同樣支持只是需要在主機配置里選擇安全級別并填入用戶名、上下文等參數(shù)比 v2c 多幾步但安全性高一個量級。3.3 創(chuàng)建主機并關聯(lián)模板頁面操作和 API 腳本兩種路線交換機側的 SNMP 就緒后回到 Zabbix 前端創(chuàng)建一臺主機。主機類型選 “SNMP”IP 地址填交換機管理地址端口默認 161。關鍵一步是在 “Macros” 標簽頁里新增一個宏{$SNMP_COMMUNITY}值填Zabbix2024這一步容易被忽略——如果你不填模板會嘗試用模板里默認的 community通常是public和交換機實際配置對不上監(jiān)控項全部報錯。填完宏之后在 “Templates” 標簽頁鏈接你導入的交換機模板保存即可。保存后不要立刻看數(shù)據等兩分鐘讓 Zabbix 完成第一次輪詢再進 “Monitoring → Latest data” 看結果。如果你需要一次性接入幾十臺交換機前端一臺臺點太慢可以用 Zabbix API 腳本來做。常見做法是寫一個 bash 腳本用 curl 調 API 創(chuàng)建主機并關聯(lián)模板。下面是核心的請求體# 用 curl 調用 Zabbix API 創(chuàng)建主機并關聯(lián)模板 curl -s -X POST http://192.168.100.10/api_jsonrpc.php \ -H Content-Type: application/json \ -d { jsonrpc: 2.0, method: host.create, params: { host: sw-core-01, interfaces: [{ type: 2, main: 1, ip: 192.168.10.1, dns: , port: 161, details: {version: 2c, community: {$SNMP_COMMUNITY}} }], templates: [{templateid: 10001}], macros: [{ macro: {$SNMP_COMMUNITY}, value: Zabbix2024 }] }, auth: your-auth-token, id: 1 }代碼里type: 2表示 SNMP 接口類型templateid需要先從template.get接口查到實際 IDmacros數(shù)組里定義了主機級別宏。注意 curl 的-d參數(shù)里不要用單引號包 JSON 時出現(xiàn)未轉義字符建議把 JSON 寫入文件再用-d body.json方式提交避免轉義地獄。這樣批量創(chuàng)建主機的速度比前端點按快很多而且可以配合host.get接口做冪等判斷已經存在的設備就直接跳過。4. 模板的靈魂是 LLD端口自動發(fā)現(xiàn)、宏映射與過濾規(guī)則4.1 發(fā)現(xiàn)規(guī)則讓 Zabbix 自己把交換機所有接口摸出來交換機模板和服務器模板最大的一點不同就是它必須依賴 LLDLow Level Discovery。一臺 48 口交換機有幾十個接口不可能人肉一個個添加監(jiān)控項而且不同型號接口數(shù)量還不一樣。LLD 規(guī)則就是讓 Zabbix 周期性地去讀ifTable或ifXTable這張接口表自動把每個接口“發(fā)現(xiàn)”出來再根據模板里的“監(jiān)控項原型”自動生成每個接口對應的監(jiān)控項、觸發(fā)器和圖形。LLD 規(guī)則本身也是模板里的一部分導入模板時自動就有了。Zabbix 官方模板里 LLD 規(guī)則的鍵值通常是net.if.discovery它內部封裝了讀取1.3.6.1.2.1.31.1.1這段 OID 的邏輯。這個規(guī)則運行后Zabbix 會把每個接口的ifIndex、ifName、ifDescr、ifAlias、ifOperStatus等屬性抓回來作為后續(xù)宏映射的數(shù)據源。默認情況下 LLD 規(guī)則的更新周期我不會用 1 小時以內的值因為接口列表基本固定太頻繁的掃描徒增交換機 CPU 壓力。4.2 宏映射與監(jiān)控項原型端口 Down 報警是怎么自動生成的發(fā)現(xiàn)規(guī)則拿到接口列表之后最關鍵的一步就落到了“宏映射”上。一個接口在 Zabbix 內部需要有穩(wěn)定標識常見的宏有{#SNMPINDEX}、{#IFNAME}、{#IFDESCR}。官方模板的默認映射是{#IFNAME}映射到ifName{#SNMPINDEX}映射到ifIndex。monitoring 項原型的鍵里會引用這些宏例如端口出入流量的監(jiān)控項原型鍵可以寫成net.if.in[ifHCInOctets.{#IFNAME}]和net.if.out[ifHCOutOctets.{#IFNAME}]。宏在運行時會自動替換成實際值這樣每個接口都會生成一對獨立的流量監(jiān)控項。舉個模板 XML 里的片段幫助你理解原型的結構item_prototype nameInterface {#IFNAME}: Inbound traffic/name typeSNMP_AGENT/type keynet.if.in[ifHCInOctets.{#IFNAME}]/key delay60s/delay history31d/history trends365d/trends valuemapNone/valuemap unitsbps/units preprocessing step typeCHANGE_PER_SECOND/type params8/params /step /preprocessing master_itemNone/master_item /item_prototype注意這里有個關鍵預處理CHANGE_PER_SECOND和參數(shù)8。SNMP 計數(shù)器拿到的原始數(shù)字是累計字節(jié)數(shù)要變成流量速率必須做差分換算乘以 8 轉成比特。如果不做這層預處理圖形上顯示的會是累計字節(jié)不斷增長的曲線而不是帶寬曲線也不會有速率峰值。這個預處理步驟是官方模板里最容易在導入后被“優(yōu)化”掉的某些人嫌模板太復雜把預處理刪了最后流量圖完全沒法看。除了監(jiān)控項原型模板里還帶觸發(fā)器原型。比如端口 Down 的觸發(fā)器原型邏輯就是檢測ifOperStatus變?yōu)?2down時觸發(fā)告警表達式大致形態(tài)如下last(/host/net.if.status[{#IFNAME}],0)2這里的{HOST.HOST}在真實模板中會被主機的技術名稱替換{#IFNAME}會被具體的接口名替換。觸發(fā)器原型的好處是它和檢測項一起隨 LLD 自動創(chuàng)建不需要你手動給每個端口建一條告警規(guī)則。實際導出模板時你會看到觸發(fā)器原型的表達式里還帶了{$IFSTATUS_CRITICAL}這樣的宏方便在不同交換機上覆蓋閾值。生產環(huán)境里我一般會把 MTU 相關的接口狀態(tài)排除在觸發(fā)器之外避免有人改了 MTU 配置導致誤報。4.3 過濾規(guī)則把 Vlanif、NULL0 這些虛擬接口擋在監(jiān)控外面LLD 發(fā)現(xiàn)的是交換機的全部接口而交換機的接口不等于物理口。一臺交換機上可能有十幾個 Vlanif 虛擬接口、NULL0、LoopBack、隧道口這些接口大多不需要監(jiān)控流量和狀態(tài)如果全部納入告警噪音會非常大。模板里 LLD 規(guī)則帶了一個過濾條件就是用來干這個的。過濾規(guī)則的常見寫法是按接口名做正則以匹配({#IFNAME} not like Vlanif and {#IFNAME} not like Vlan and {#IFNAME} not like NULL and {#IFNAME} not like LoopBack)同時再配合包含規(guī)則確認接入類型比如({#IFNAME} matches ^(GigabitEthernet|XGE|Eth|GE|Ten-GigabitEthernet|HundredGE))第一段過濾掉虛擬接口第二段只保留物理以太網口。注意兩個條件之間用 and 連接缺一不可否則要么虛擬接口混進來要么物理口被誤殺。不同廠商的接口命名前綴差異很大華為用 GigabitEthernet、EthH3C 也用 GigabitEthernet銳捷可能是 Gi 前綴。你在寫過濾正則前建議先用 4.3 節(jié)的 snmpwalk 那條命令把實際接口名拉一遍再照著真實命名寫正則不要憑空猜。過濾規(guī)則寫錯最典型的現(xiàn)象是模板關聯(lián)后某一臺交換機上所有端口監(jiān)控項全部消失該設備前端顯示“接口數(shù) 0”。5. 交換機模板上線后的 5 個高頻翻車點與避坑方案5.1 ifIndex 漂移交換機重啟后端口監(jiān)控全對不上現(xiàn)象一臺 H3C 交換機重啟后原來接口名對應到監(jiān)控項全亂了流量圖斷掉LLD 重新發(fā)現(xiàn)后又出現(xiàn)一批新的監(jiān)控項舊監(jiān)控項全部變成 “Not supported”。原因如果模板的宏映射使用{#SNMPINDEX}作為主鍵而設備在重啟或配置變更后 ifIndex 重新分配同一個物理口對應的 ifIndex 變了數(shù)據就對不上了。解決不要用 ifIndex 做唯一主鍵改用{#IFNAME}或{#IFDESCR}作為宏映射主鍵同時在 LLd 規(guī)則里把周期調短到 1530 分鐘讓重啟后的設備盡快重新發(fā)現(xiàn)。我在核心交換機上還會手工把端口對應關系記在 ifAlias 里用{#IFALIAS}做輔助標識值可讀性高排查時一眼識別。5.2 32 位計數(shù)器翻轉流量圖出現(xiàn)負數(shù)與尖峰現(xiàn)象某個千兆口流量圖偶爾出現(xiàn)很大的負值或瞬間出現(xiàn) 40Gbps 尖峰然后歸零。原因模板或你手工添加的監(jiān)控項用的是 32 位計數(shù)器ifInOctets32 位最大計數(shù)到約 4.2 億字節(jié)千兆口幾分鐘就會翻轉一次翻轉瞬間差分計算得到負數(shù)。解決統(tǒng)一換成 64 位計數(shù)器ifHCInOctets/ifHCOutOctets這兩個是 64 位計數(shù)萬兆口也要很久才翻一次處理代碼上天然規(guī)避問題。老舊的百兆交換機有的不支持 HC 計數(shù)器那就只能降低輪詢頻率以緩解翻轉速度并接受偶爾數(shù)據異常這是硬件限制沒有后悔藥。5.3 光功率監(jiān)控項總是 No data先分清 OID 歸屬現(xiàn)象模板關聯(lián)后設備 CPU、流量全部正常但光模塊溫度和光功率的監(jiān)控項全部顯示 “Not supported” 或 “No data”。原因光模塊所在的 MIB 是廠商私有節(jié)點不是 RFC 標準節(jié)點華為和 H3C 的光模塊傳感器 OID 完全不一樣甚至同一廠商不同系列也不一樣。官方通用模板無法窮舉廠商私有 OID這類監(jiān)控項默認是缺失的。解決先去下載對應型號的 MIB 文件用 snmpwalk 探測光模塊傳感器節(jié)點比如華為部分設備可以在實體傳感器 MIB 下找到溫度、電壓、光功率的數(shù)據確認 OID 后在模板里復制一份監(jiān)控項原型改成私有 OID再用主機宏區(qū)分不同型號。注意不要照抄網上的 OID 到不同型號上大概率無效。5.4 輪詢頻率太密20 臺交換機把監(jiān)控服務器和網絡都拖垮現(xiàn)象Zabbix 服務器 load 飆升交換機 CPU 也跟著高snmpwalk 手動執(zhí)行時響應變慢。原因模板里監(jiān)控項更新周期設成了 10s又開了大量 LLD 規(guī)則48 口交換機每輪光接口監(jiān)控項就有上百條幾十臺設備疊加后 SNMP 請求風暴打滿網絡設備和監(jiān)控服務器。解決默認模板里把普通監(jiān)控項更新周期改到 60sLLD 規(guī)則周期 30 分鐘以上即可。核心交換機的關鍵接口可以單獨復制一份監(jiān)控項設成 30s 快速輪詢但一定不要全局生效。Zabbix 里每個監(jiān)控項都可以單獨覆蓋 delay 值這個能力用得好才能兼顧實時性和性能。5.5 community 用 public 還裸奔在整個網段現(xiàn)象交換機配置了 SNMP v2ccommunity 是默認的public沒有 ACL 限制幾個月后發(fā)現(xiàn)交換機 CPU 負荷高排查發(fā)現(xiàn)有人在全網段掃描 SNMP 端口。原因v2c 是明文協(xié)議community 等于密碼默認值毫無防備掃描器很容易發(fā)現(xiàn)并持續(xù)輪詢你的設備。解決社區(qū)字符串改成和密碼同等復雜度的只讀值比如Zabbix2024#Core同時在交換機上配置 ACL 只允許 Zabbix server 的 IP 訪問 161 端口前文 4.2 節(jié)已經給出了配置示例。如果你設備和 Zabbix 都支持 SNMP v3建議直接升級 v3用認證和加密即便報文中途被截獲也拿不到明文數(shù)據。6. 最后一道工序用圖表和觸發(fā)器表達式給模板做驗收模板部署完不等于結束上線之前一定要做一次完整驗收。我最常做的第一步不是看 Latest data而是用圖表原型跑一張流量圖。Zabbix 圖形分為“圖形原型”和“自定義圖形”前者會隨 LLD 自動生成每個端口的圖后者是手動建圖。在模板的 “Graph prototypes” 里確認存在類似 “Interface {#IFNAME}: Network traffic” 的圖形原型后找到一臺已關聯(lián)的交換機直接打開對應接口的圖形看波形是否光滑。如果圖形里有毛刺或負值回頭看監(jiān)控項預處理是否缺失。第二步是驗證觸發(fā)器表達式是否誤報。交換機模板里最煩的告警是端口 Down 告警接入層辦公網的終端經常有人拔網線每拔一次就報警一次半夜能煩死人。我會把接入交換機的模板里端口 Down 觸發(fā)器表達式加條件比如只在 5 分鐘持續(xù) Down 后才告警而核心交換機端口 Down 必須立即告警用不同的模板副本區(qū)分接入層和核心層。表達式形態(tài)參考# 接入層: 持續(xù) 5 分鐘 Down 才告警 last(/sw-access-01/net.if.status[{#IFNAME}],300s)2參數(shù)300s表示最近 300 秒的最后一次值是 2才滿足觸發(fā)條件。換成0就是立即告警核心交換機用。這樣改完后接入層掉線的誤報能減少大半核心鏈路的狀態(tài)仍然秒級感知。這種驗證思路同樣適用于其他模板有問題先看圖形再看觸發(fā)器歷史最后反查監(jiān)控項鍵值。我自己吃過最大的虧是把所有交換機不分角色套同一個模板結果機房維護時接入層幾十條端口 Down 告警同時炸出來值班手機卡了五分鐘。后來把模板拆成 core 和 access 兩個版核心口用立即告警接入口加 delay世界安靜了。希望這篇筆記里的選型和避坑經驗能幫到你哪怕只避掉 ifIndex 和計數(shù)器這兩個坑也算值回票價。本文還有配套的精品資源點擊獲取