我做了快十年網(wǎng)絡(luò)運維接手過的網(wǎng)絡(luò)環(huán)境從幾十臺設(shè)備到上千臺都有印象最深的往往不是那些復(fù)雜的架構(gòu)設(shè)計反而是深更半夜被電話叫醒說核心交換機流量跑滿、業(yè)務(wù)卡死結(jié)果登錄上去一看連監(jiān)控都沒有。沒有監(jiān)控就沒有數(shù)據(jù)就沒有判斷依據(jù)一切只能靠猜。而SNMPSimple Network Management Protocol簡單網(wǎng)絡(luò)管理協(xié)議是解決這個問題的老牌、通用、成本最低的方案沒有之一。幾乎所有帶網(wǎng)管的設(shè)備交換機、路由器、防火墻、服務(wù)器、UPS甚至部分PDU都內(nèi)置了對SNMP的支持。這篇文章我就用實際踩過的坑和驗證過的經(jīng)驗把SNMP網(wǎng)絡(luò)監(jiān)控這件事聊透設(shè)備性能怎么采集、流量數(shù)據(jù)怎么分析、故障怎么通過告警和趨勢提前預(yù)判以及那些文檔里不會寫但實戰(zhàn)中一定會遇到的坑。1. 先搞懂SNMP到底在干什么原理與選型考量1.1 MIB和OID讀懂設(shè)備“說明書”SNMP的核心思想很簡單設(shè)備上運行一個Agent對外暴露一個“資料庫”監(jiān)控端用管理協(xié)議去查詢這個資料庫拿到各種指標(biāo)。這個“資料庫”就是MIBManagement Information Base里面的每一項記錄都有一個唯一的編號叫OIDObject Identifier。我打一個比方MIB就像一本設(shè)備的完整說明書OID就是說明書前面的目錄頁碼。比如你想看某臺交換機某個端口的入流量就需要找到“接口表”這一章下面的“接口入方向字節(jié)數(shù)”這一頁也就是一個類似.1.3.6.1.2.1.2.2.1.10這樣的OID。這串?dāng)?shù)字不是隨便寫的它是一棵全球統(tǒng)一管理的樹形結(jié)構(gòu)從根開始一層層往下編號。理解了OID你就掌握了SNMP的鑰匙。很多新人上手時最容易懵的點就是想監(jiān)控“CPU使用率”卻不知道這個指標(biāo)對應(yīng)哪個OID。這很正常因為不同廠商甚至同一廠商不同型號的設(shè)備CPU相關(guān)OID都可能是私有節(jié)點。標(biāo)準(zhǔn)MIB IIRFC 1213里只規(guī)定了接口、系統(tǒng)信息、IP、ICMP、TCP、UDP、SNMP這些通用組而CPU、內(nèi)存、溫度這種偏硬件的信息大多要翻廠商的MIB文件。提示拿到一臺新設(shè)備第一件事就是去官網(wǎng)下載對應(yīng)的MIB文件用MIB Browser或者snmpwalk把整棵樹拉下來慢慢找關(guān)鍵OID。這個過程看起來笨但最可靠。1.2 v1、v2c、v3怎么選SNMP經(jīng)歷了v1、v2c、v3三個主要版本能跑在UDP 161Agent監(jiān)聽和162Trap發(fā)送端口上。版本選擇直接影響你后續(xù)的安全策略和兼容性。版本安全性兼容性性能實際建議v1無認(rèn)證明文團體字符串所有老設(shè)備都支持效率低不建議用除非有古董設(shè)備v2c仍用團體字符串明文傳輸最廣幾乎所有設(shè)備支持支持GETBULK批量取數(shù)效率高內(nèi)網(wǎng)環(huán)境的首選v3支持用戶名密碼、加密傳輸部分老設(shè)備不支持相對慢一點CPU開銷高跨公網(wǎng)或強安全要求時用我的建議是如果是純內(nèi)網(wǎng)且有獨立監(jiān)控網(wǎng)段v2c配合一個足夠復(fù)雜的團體字符串Community String就能滿足99%的場景?！皃ublic”“private”這種默認(rèn)字符串務(wù)必?fù)Q掉這一點后面單講。v3雖然能加密但實際部署時你會發(fā)現(xiàn)很多老設(shè)備固件對v3的支持不全有的只支持noAuthNoPriv有的配置界面寫著支持但跑起來經(jīng)常超時排查起來非常折騰。所以不要為了“看起來安全”盲目上v3先評估設(shè)備兼容性再決定。如果你的監(jiān)控端和被監(jiān)控設(shè)備之間有VLAN隔離或防火墻規(guī)則v2c的明文風(fēng)險是可控的。1.3 輪詢的節(jié)奏與開銷平衡SNMP采集機制是輪詢Polling也就是監(jiān)控端按固定周期向設(shè)備發(fā)起請求。這個機制有好有壞。好處是簡單可靠你控制了節(jié)奏設(shè)備不會主動騷擾你壞處是它天生不自帶“心跳”如果設(shè)備不回應(yīng)你需要自己判斷是它死了還是網(wǎng)絡(luò)斷了。輪詢周期設(shè)多短是個權(quán)衡。設(shè)成30秒數(shù)據(jù)線條很平滑但一臺設(shè)備同時要處理幾百次獨立的GET請求對設(shè)備控制平面有壓力設(shè)成5分鐘CPU負(fù)擔(dān)小但故障發(fā)現(xiàn)會延遲。我實測下來常規(guī)網(wǎng)絡(luò)設(shè)備性能指標(biāo)CPU、內(nèi)存、端口流量用60秒到300秒的周期比較合理。核心設(shè)備設(shè)60秒接入層和分支機構(gòu)設(shè)備設(shè)300秒就夠了。再短的周期收益很低只會增加設(shè)備負(fù)擔(dān)。另外v2c支持GETBULK批量抓取一次請求可以拿回一整組連續(xù)OID的數(shù)據(jù)效率比v1一個個GET快幾個量級。這也是不推薦v1的另一個實際原因。2. 設(shè)備性能監(jiān)控從部署到關(guān)鍵指標(biāo)2.1 采集端選型Prometheus、Zabbix還是Cacti采集端是整個監(jiān)控系統(tǒng)的“大腦”。目前主流方案有三個我分別說下適用場景。Zabbix算是傳統(tǒng)老牌它原生支持SNMP模板市場里有大量現(xiàn)成的設(shè)備模板裝上就能用。告警規(guī)則、圖表、自動發(fā)現(xiàn)都內(nèi)置了對傳統(tǒng)運維團隊友好。缺點是數(shù)據(jù)庫和前端在后端重一點大規(guī)模部署需要調(diào)優(yōu)。Prometheus snmp_exporter是我現(xiàn)在的主力方案。它的優(yōu)勢是抓取模型和SNMP天生的輪詢模型高度契合配置靈活配合Grafana做可視化非常漂亮。snmp_exporter支持通過模塊來定義抓取哪些OID還能自動從MIB文件生成配置屬于新一代監(jiān)控棧的主流選擇。缺點是對新手有一定門檻很多概念up、metric、relabel需要學(xué)習(xí)成本。Cacti算是老前輩RRDTool畫圖輕量簡單。但現(xiàn)在看來功能太單一了告警配置也比較原始除非你維護的是很老的環(huán)境否則不建議新部署。如果讓我給一個“抄作業(yè)”的選擇團隊熟悉Linux和容器選Prometheus團隊習(xí)慣傳統(tǒng)的“一鍵裝好”選Zabbix。兩者的底層數(shù)據(jù)都來自SNMP不影響你的業(yè)務(wù)理解。2.2 設(shè)備側(cè)要做的幾件事被監(jiān)控設(shè)備的開啟配置很簡單但有三個細(xì)節(jié)常被忽略。第一團體字符串不要用默認(rèn)值。不要圖省事把交換機的SNMP團體字符串從public改成類似Mon$2024Network這種越亂越好。很多人會問內(nèi)網(wǎng)泄不泄露無所謂真不是。一旦有設(shè)備被攻破或惡意掃描第一眼就能通過SNMP讀取到整個內(nèi)網(wǎng)的路由表和ARP表比掃描端口還直觀。第二ACL限制源地址。所有主流網(wǎng)絡(luò)設(shè)備在開啟SNMP時都可以配置ACL只允許監(jiān)控服務(wù)器的IP來訪問。這個動作相當(dāng)于給SNMP加了一層網(wǎng)絡(luò)層面的保險即使字符串泄露外部也訪問不了。第三確認(rèn)SNMP服務(wù)和監(jiān)控端之間的UDP通路。很多網(wǎng)絡(luò)管理員會忘記常規(guī)防火墻策略里一般放行TCP 80、443之類但UDP 161很容易被漏掉。UDP通信沒有狀態(tài)抓包經(jīng)?？吹秸埱蟀l(fā)出去了、設(shè)備也回了但監(jiān)控端收不到多半就是中間設(shè)備的防火墻策略在作怪。2.3 必盯的幾類性能指標(biāo)結(jié)合我多年運維經(jīng)驗設(shè)備性能監(jiān)控至少要覆蓋這幾類指標(biāo)系統(tǒng)資源類CPU平均利用率特別是交換機背板CPU內(nèi)存使用率如果有對應(yīng)OID系統(tǒng)運行時間uptime用來確認(rèn)設(shè)備是否重啟過接口鏈路類端口入/出字節(jié)數(shù)吧是流量分析的基礎(chǔ)入/出包數(shù)結(jié)合字節(jié)數(shù)可以算出平均包長入/出錯誤包、丟棄包端口故障的早期信號接口狀態(tài)up/down這個變化本身就是一個告警事件設(shè)備環(huán)境類有的話盡量采電源狀態(tài)、風(fēng)扇狀態(tài)、溫度值。這些聽上去不性感但機房空調(diào)掛了最早報警的往往不是溫度傳感器而是交換機光模塊的DDM溫度先飆升。我見過很多團隊只盯著接口流量CPU和內(nèi)存都沒采結(jié)果設(shè)備轉(zhuǎn)發(fā)性能下降、CPU打滿業(yè)務(wù)已經(jīng)卡了才發(fā)現(xiàn)。性能指標(biāo)的最大價值在于“橫向?qū)Ρ取焙汀摆厔蓊A(yù)測”不是“事后查看”。2.4 數(shù)據(jù)存儲與精度怎么取舍監(jiān)控數(shù)據(jù)存多久、什么粒度這是設(shè)計監(jiān)控系統(tǒng)時必須想清楚的問題。SNMP采集出來的原始數(shù)據(jù)是單調(diào)遞增的計數(shù)器Counter真正有意義的是兩次取值之間的差值。比如端口入字節(jié)數(shù)這個值上一次取是1000這一次取是1500那在這段時間內(nèi)就傳了500字節(jié)。這個差值除以時間間隔才是你看到的“速率”。這也是所有SNMP監(jiān)控工具內(nèi)部都在做的事把計數(shù)器轉(zhuǎn)成速率。原始數(shù)據(jù)建議保留比較短周期比如30天的秒級/分鐘級數(shù)據(jù)歷史歸檔可以保留月級或年級的5分鐘聚合數(shù)據(jù)。存儲上Prometheus用本地TSDBZabbix用數(shù)據(jù)庫都涉及清理策略。我認(rèn)為最合理的做法是熱數(shù)據(jù)顆粒度細(xì)一點比如60秒粒度保留30天冷數(shù)據(jù)顆粒度粗一點比如1小時粒度保留1年這樣既滿足日常巡檢和歷史回溯又不至于把存儲打爆。3. 流量分析SNMP能做和不能做的事3.1 讀懂接口計數(shù)器的真正含義接口流量是所有監(jiān)控里最基礎(chǔ)、也最容易誤讀的一項。SNMP的接口表里入方向字節(jié)數(shù)ifInOctets和出方向字節(jié)數(shù)ifOutOctets是核心計數(shù)器但有個細(xì)節(jié)它們不是精確的流量值而是“累計字節(jié)數(shù)”。這意味著什么假設(shè)我昨天看到入方向字節(jié)數(shù)是1.2GB今天看變成了2.4GB那說明昨天到今天一共進了1.2GB的流量。如果你只盯著原始值看會覺得“流量在變大”但實際上這只是累計值在增加。真正有意義的指標(biāo)是單位時間內(nèi)的速率比如“5分鐘內(nèi)平均每秒多少Mbps”。所以做流量分析一定要先把原始計數(shù)器轉(zhuǎn)成速率。具體的計算邏輯(當(dāng)前值 - 上一次值) / 時間間隔。如果你的監(jiān)控工具沒做這個轉(zhuǎn)換那一定是你配置不對不是工具不好。另外32位計數(shù)器有個著名的回繞問題。在1Gbps鏈路上32位計數(shù)器大約每4.3天就會溢出回繞到0。如果監(jiān)控端沒做處理會看到一個“流量瞬間變成負(fù)數(shù)”的詭異數(shù)據(jù)點?，F(xiàn)在的監(jiān)控工具一般都能正確處理但如果你是自己寫腳本采集一定要用64位計數(shù)器HC-前綴的OID比如ifHCInOctets并且正確處理回繞。這是很細(xì)節(jié)但很重要的坑。3.2 從“流量高不高”到“誰在跑流量”SNMP只能告訴你“這個端口有多少流量”但它無法告訴你“這些流量是什么應(yīng)用、哪臺主機在跑”。這是一個經(jīng)常被誤解的邊界。要做更細(xì)粒度的流量分析必須引入其他技術(shù)最常見的是NetFlow、sFlow和IPFIX。這些技術(shù)由設(shè)備直接采樣或鏡像轉(zhuǎn)發(fā)報文可以輸出五元組源IP、目標(biāo)IP、源端口、目標(biāo)端口、協(xié)議級別的流量臺賬。只有到了這個粒度你才能回答“誰在下載業(yè)務(wù)系統(tǒng)數(shù)據(jù)”“為什么某臺服務(wù)器出方向流量這么大”這類問題。對于沒有NetFlow能力的設(shè)備也可以采取鏈路鏡像的方式接探針設(shè)備或者直接在宿主機上用軟件采集。但作為基礎(chǔ)監(jiān)控SNMP的端口級流量已經(jīng)能應(yīng)付大多數(shù)“容量規(guī)劃”和“鏈路擁塞”的判斷。說白了先知道“哪里堵”再知道“誰在跑”這兩步是遞進關(guān)系。3.3 流量突增的判斷基準(zhǔn)基線怎么建立監(jiān)控新手最容易犯的錯就是設(shè)置一個固定閾值比如超過80%就打告警。流量是有潮汐效應(yīng)的辦公網(wǎng)白天高、晚上低電商網(wǎng)活動日高、平常低。用一個固定閾值判斷幾乎必然會誤報或者漏報。正確做法是建立基線。把歷史流量數(shù)據(jù)按“周同比”或“日同一時段”做對比。比如工作日早上9點到10點過去4周的平均端口利用率是40%波動范圍是±10%今天突然到了80%這就算異常。Prometheus結(jié)合Grafana可以輕松實現(xiàn)這種動態(tài)基線Zabbix里也有相應(yīng)的觸發(fā)器函數(shù)?；€的意義不只是“更準(zhǔn)的告警”更是“早期發(fā)現(xiàn)”。很多故障在真正爆發(fā)前會有一個小時甚至幾個小時的“緩慢爬坡”過程。比如某臺主機中了挖礦木馬內(nèi)存和CPU會慢慢攀升出方向流量也會逐漸增加。如果沒有基線這個信號很難被察覺等指標(biāo)破頂時已經(jīng)晚了。4. 故障診斷監(jiān)控數(shù)據(jù)怎么派上用場4.1 告警閾值怎么設(shè)才不會“狼來了”告警閾值設(shè)計得好不好直接決定監(jiān)控系統(tǒng)的價值。閾值太靈敏每天幾十封告警郵件大家麻木了真出大事反而沒人看閾值太遲鈍監(jiān)控形同虛設(shè)。我給個參考做法核心指標(biāo)分三級告警分別用“異常”“警告”“嚴(yán)重”三個級別。端口流量利用率持續(xù)5分鐘超過80%算警告超過90%持續(xù)10分鐘算嚴(yán)重。CPU使用率持續(xù)10分鐘超過85%算警告持續(xù)30分鐘超過95%算嚴(yán)重。接口down事件直接算嚴(yán)重因為無論影響大小它都代表了一次鏈路變更必須人工確認(rèn)。關(guān)鍵在“持續(xù)”兩個字。不要用瞬時值直接觸發(fā)而是用“最近N次采樣中有M次超過閾值”這種模式就能過濾掉絕大多數(shù)瞬時抖動。我見過太多誤報都是因為閾值設(shè)置成瞬時值。另外告警一定要有聚合和抑制機制。同一臺設(shè)備所有端口都down很可能整臺設(shè)備掉電了這時只發(fā)一條“設(shè)備不可達”就夠不必每個端口各發(fā)一條。這個邏輯很多團隊忽略結(jié)果告警風(fēng)暴把值班人員淹沒了。4.2 事后排查用歷史趨勢縮小故障范圍故障發(fā)生后的第一件事很多人習(xí)慣直接登錄設(shè)備看現(xiàn)狀但我會先看監(jiān)控趨勢圖尤其是故障發(fā)生前后各一小段時間的曲線。假設(shè)某個業(yè)務(wù)凌晨2點報障“訪問特別慢”我先看核心交換機出口流量曲線如果2點前后流量從300Mbps驟降到50Mbps說明鏈路本身出問題了如果流量沒變但是CPU和內(nèi)存飆高那多半是設(shè)備轉(zhuǎn)發(fā)能力出問題如果監(jiān)控數(shù)據(jù)一切正常那問題可能不在網(wǎng)絡(luò)鏈路而在應(yīng)用層或DNS解析。趨勢圖的作用是“快速縮小范圍”能幫你省下大量逐臺登錄排查的時間。有一次我們排查核心交換機周期性業(yè)務(wù)卡頓就是通過歷史曲線發(fā)現(xiàn)CPU每隔2小時有一個尖峰順著時間點排查最后定位到是某臺服務(wù)器的備份腳本定時發(fā)SNMP大量掃描設(shè)備把設(shè)備控制平面打滿了。4.3 常見故障與SNMP特征的對應(yīng)關(guān)系故障現(xiàn)象SNMP監(jiān)控中看到的特征可能原因業(yè)務(wù)偶發(fā)卡頓出口端口利用率周期性沖到95%以上某主機定時任務(wù)/備份流量擠占帶寬設(shè)備整機無響應(yīng)CPU持續(xù)100%SNMP輪詢超時設(shè)備遭攻擊或有異常協(xié)議泛洪接口頻繁up/down接口狀態(tài)在“up”和“down”之間快速抖動光模塊老化、線纜松動、協(xié)商異常設(shè)備自動重啟系統(tǒng)uptime變成很小的值其他指標(biāo)全部歸零電源故障、過熱保護、固件崩潰端口大量錯包錯誤包計數(shù)快速增長但利用率不高雙工不匹配、網(wǎng)線質(zhì)量差、光模塊光衰太大這張表我建議運維新人收藏。很多時候監(jiān)控數(shù)據(jù)不是用來“證明設(shè)備壞了”而是用來“翻譯”癥狀背后的物理原因。5. 常見問題與排查技巧實錄5.1 OID取不到值先分清是“不存在”還是“權(quán)限不夠”實際運行中最常見的問題是snmpwalk 拿不到預(yù)想的OID。這種情況要先區(qū)分三種可能第一OID拼錯了。很多人喜歡在網(wǎng)上抄OID另一些OID只有特定廠商的設(shè)備才有。同一個功能思科的OID和華為的可能完全不一樣。建議先在設(shè)備官網(wǎng)核對你手里這個OID對應(yīng)的MIB模塊。第二是私有MIB沒加載。大部分CPU和內(nèi)存OID屬于廠商私有MIB監(jiān)控工具默認(rèn)不帶。你需要把廠商MIB文件導(dǎo)入到監(jiān)控系統(tǒng)或者在exporter里手動指定私有OID。這一點最容易被忽視因為標(biāo)準(zhǔn)MIB里不包含這些。第三是SNMP版本或團體字符串權(quán)限限制。有些設(shè)備在配置v2c時區(qū)分了只讀和讀寫字符串只讀字符串看不到某些私有OID。另外部分設(shè)備v3用戶只授權(quán)了指定范圍的視圖也會出現(xiàn)“能找到部分OID但找不到另外一部分”的情況。排查思路先在本機用snmpwalk加-v和-c參數(shù)跑一遍如果本機能取到、監(jiān)控系統(tǒng)取不到問題在監(jiān)控端如果本機也取不到問題在設(shè)備和OID。5.2 數(shù)據(jù)斷檔和超時的處理SNMP走的是UDP本身沒有重傳機制所以網(wǎng)絡(luò)擁塞、設(shè)備CPU高、UDP被防火墻丟棄都會造成數(shù)據(jù)丟失。數(shù)據(jù)斷檔不全是壞事它有診斷價值如果你發(fā)現(xiàn)斷檔的規(guī)律和某些設(shè)備CPU上漲的時間吻合那就能反過來定位設(shè)備的性能瓶頸。處理措施有三個層面輪詢超時時間要合理。默認(rèn)5秒超時如果設(shè)備CPU高導(dǎo)致回應(yīng)慢會頻繁超時。建議改成10秒并設(shè)置重試1次這樣既不會因為一次丟包就斷檔也不會因為長期等待拖垮采集線程。采集端日志要保留。很多監(jiān)控系統(tǒng)把“取不到數(shù)據(jù)”當(dāng)正常間隔處理不寫日志排查時很難回溯。建議把采集失敗次數(shù)單獨匯總成一個指標(biāo)超過一定比例就告警。定期檢查UDP 161通路?？梢栽诒O(jiān)控服務(wù)器上用snmpwalk手動驗證被監(jiān)控設(shè)備如果手動能取到但系統(tǒng)隔一段時間就斷檔那大概率是網(wǎng)絡(luò)鏈路偶爾擁塞或設(shè)備控制平面壓力大。5.3 安全暴露面SNMP可能是最容易被忽略的入口SNMP的問題在于它長年跑在UDP 161端口上容易被防火墻策略忽略很多管理員甚至忘記給這個端口做限制。而且v1/v2c的團體字符串是明文傳輸抓包就能看到。我在安全審計時見過這樣一種環(huán)境辦公網(wǎng)和監(jiān)控網(wǎng)沒有隔離某臺交換機的SNMP團體字符串還是public只要有人在內(nèi)網(wǎng)跑一個掃描工具就能把整個網(wǎng)段所有設(shè)備的路由表、ARP表、接口狀態(tài)全部讀走。這些信息可以作為后續(xù)攻擊的內(nèi)網(wǎng)情報。所以安全基線建議列這樣幾條所有設(shè)備SNMP團體字符串不使用默認(rèn)值定期更換。通過ACL僅允許監(jiān)控服務(wù)器的IP訪問SNMP端口。監(jiān)控網(wǎng)段與業(yè)務(wù)網(wǎng)段進行隔離。對公網(wǎng)方向一律不放行UDP 161端口。SNMP服務(wù)如果暴露在公網(wǎng)歷史上多次出現(xiàn)過被惡意利用的情況不要抱僥幸心理。5.4 采集腳本的性能陷阱如果你是自己寫腳本采集SNMP有兩點要注意。第一不要用for循環(huán)逐條GET大量OID應(yīng)該用GETBULK或者SNMP協(xié)議本身支持的多OID GET。一個幾千條OID的循環(huán)在設(shè)備端會產(chǎn)生大量解析工作對設(shè)備CPU消耗非常大。比如用net-snmp的Python綁定盡量用snmpgetnext或getbulk或者直接交給snmp_exporter這類批量采集工具。第二控制并發(fā)度。監(jiān)控多個網(wǎng)段的設(shè)備時如果腳本一口氣開幾百個線程同時去請求設(shè)備會瞬間被打滿。穩(wěn)妥的做法是控制單個采集器的并發(fā)請求數(shù)在20以下打散采集時間避免所有設(shè)備同時發(fā)起請求。6. 監(jiān)控體系建設(shè)之外的一些體會文章寫到這SNMP的核心知識基本講完了。不過我還是想補充幾個經(jīng)驗層面的事這些屬于不在文檔上、但實際很重要的小體會。第一SNMP不是萬能的。它能看到“設(shè)備怎么樣”但看不到“應(yīng)用怎么樣”。想監(jiān)控業(yè)務(wù)視角得配合日志系統(tǒng)、APM工具和主動撥測這樣才能真正做到端到端可觀測。我見過很多團隊花了大精力做SNMP但業(yè)務(wù)故障時還是兩眼一抹黑就是因為沒有把“基礎(chǔ)設(shè)施監(jiān)控”和“業(yè)務(wù)監(jiān)控”串起來。第二告警一定是要能落地行動的否則寧可不配。我曾經(jīng)見過一個監(jiān)控系統(tǒng)每天產(chǎn)生幾千條告警運維人員已經(jīng)麻木到只看“嚴(yán)重”級別甚至嚴(yán)重級別都太多最后真正核心的故障被淹沒在噪音里。告警設(shè)計要遵循一條原則每一條告警都對應(yīng)一個可以直接行動的預(yù)案。沒有預(yù)案的告警就下調(diào)級別或者關(guān)掉。第三SNMP的基線數(shù)據(jù)是長期積累的財富。監(jiān)控系統(tǒng)剛上線時你只覺得它在“看數(shù)據(jù)”但運行半年、一年以后歷史趨勢圖的價值才會顯現(xiàn)出來。擴容容量的判斷、設(shè)備生命周期的規(guī)劃甚至年度預(yù)算匯報都能從這些數(shù)據(jù)里找到強有力依據(jù)。所以我建議數(shù)據(jù)保留周期寧長勿短壞的存儲策略是“只存了最近7天”。第四不要排斥用簡單工具先跑起來。團隊有成熟的商業(yè)監(jiān)控平臺當(dāng)然好但如果現(xiàn)在什么都沒有直接用snmpwalk加上Prometheus的snmp_exporter一個下午就能搞定一套基礎(chǔ)監(jiān)控先跑起來再迭代。與其追求一開始就完美不如先用起來讓數(shù)據(jù)先積累起來。我在實際運維中體會最深的就是網(wǎng)絡(luò)監(jiān)控這件事真正的門檻不在技術(shù)而在堅持。設(shè)備裝上、采集跑起來只是起點持續(xù)沉淀、持續(xù)優(yōu)化告警策略才是讓監(jiān)控系統(tǒng)真正產(chǎn)生價值的過程。希望這篇文章能幫你把SNMP這套底子打扎實后面無論換成什么平臺核心思路都不會變。