簡(jiǎn)介一份面向網(wǎng)絡(luò)運(yùn)維人員的H3C交換機(jī)日常巡檢命令整理文檔聚焦設(shè)備狀態(tài)監(jiān)控與隱患排查適合網(wǎng)絡(luò)管理員與H3C設(shè)備維護(hù)人員參考。文檔以H3C S5500系列為示例系統(tǒng)梳理8條高頻巡檢指令包括查看CPU使用率display cpu-usage、內(nèi)存占用display memory、設(shè)備溫度display environment、設(shè)備匯總信息display device verbose、風(fēng)扇狀態(tài)display fan、電源狀態(tài)display power、系統(tǒng)時(shí)間display clock以及接口簡(jiǎn)要信息display interface brief。每條命令均提供實(shí)際輸出示例并解釋關(guān)鍵字段如CPU 5秒/1分鐘/5分鐘平均使用率、內(nèi)存總?cè)萘颗c已用量、入風(fēng)口與熱點(diǎn)溫度、設(shè)備型號(hào)與運(yùn)行時(shí)間、風(fēng)扇及電源Normal/Fault狀態(tài)、接口Link/Protocol狀態(tài)等方便管理員快速判斷設(shè)備健康度并定位故障。整個(gè)資源為1個(gè)doc文件壓縮包僅21KB內(nèi)容精煉實(shí)用適合作為日常巡檢速查手冊(cè)。目前已有588人學(xué)習(xí)下載適合需要快速掌握H3C交換機(jī)巡檢要領(lǐng)的網(wǎng)絡(luò)工程師。1. H3C交換機(jī)巡檢命令不是背命令是建立一條能救命的檢查鏈H3C交換機(jī)巡檢命令說白了就是十來個(gè)display命令但真正把巡檢當(dāng)回事的人都明白命令敲一遍十分鐘把設(shè)備狀態(tài)看明白才是一整天的事。這張命令清單不是給新手背的是給那些網(wǎng)絡(luò)出過事的人用的——交換機(jī)動(dòng)不動(dòng)跑一兩年不重啟風(fēng)扇堵灰、電源掉壓、單核CPU打滿這些都不會(huì)主動(dòng)上報(bào)到網(wǎng)管只有巡檢時(shí)看到了才能救回來。我見過太多“巡檢做了但沒發(fā)現(xiàn)問題”的翻車現(xiàn)場(chǎng)原因從來不是命令沒敲而是沒按順序敲、沒把輸出留下來、沒和上次的記錄做對(duì)比。2. 巡檢順序怎么定按「硬件—系統(tǒng)—接口—日志」四層過先看命再看病2.1 硬件層風(fēng)扇、電源、溫度這三樣先查再談性能H3C的網(wǎng)絡(luò)操作系統(tǒng)從Comware V5到V7巡檢命令變化不大硬件層我一般固定敲這一組display device display environment display fan display powerdisplay device看的是單板、電源模塊的在線狀態(tài)和狀態(tài)字段。輸出里每一行都有Slot、Status、Type信息Slot 0是主控板Status必須是Normal。如果看到Fault或者Absent基本可以判定硬件故障這種屬于必須當(dāng)天處理的級(jí)別。display environment一條命令能把溫度、風(fēng)扇轉(zhuǎn)速都拉出來。H3C交換機(jī)在V7版本里溫度告警閾值一般是高溫告警在65℃左右但真正需要關(guān)注的不是絕對(duì)值而是趨勢(shì)。我巡檢時(shí)習(xí)慣把歷史溫度記錄翻出來比比如上次38℃、這次52℃哪怕沒到告警閾值十幾度的漲幅也說明散熱通道在惡化。常見原因是設(shè)備間積灰、風(fēng)扇轉(zhuǎn)速下降或者機(jī)柜氣流被堵這類問題靠一次display環(huán)境看不出來必須留記錄。display fan和display power在盒式設(shè)備上基本上就是確認(rèn)Present和Normal。這里有一個(gè)容易被忽略的細(xì)節(jié)部分風(fēng)扇模塊是支持調(diào)速的輸出里能看到轉(zhuǎn)速檔位如果長(zhǎng)時(shí)間跑在高檔位說明設(shè)備自己在被動(dòng)散熱環(huán)境溫度可能已經(jīng)偏高。電源模塊則要關(guān)注是否處于冗余狀態(tài)如果兩個(gè)電源里有一個(gè)Failed但設(shè)備還在運(yùn)行巡檢時(shí)必須馬上安排更換因?yàn)楫?dāng)前是單電源撐著再壞一個(gè)就整機(jī)斷電。2.2 系統(tǒng)層與NTP版本、時(shí)間、堆疊狀態(tài)時(shí)間不對(duì)全盤皆錯(cuò)系統(tǒng)層看四條命令就夠display version、display clock、display irf、display ntp-status。但恰恰是最便宜的一條命令埋了很多坑。display version要看的其實(shí)不是版本號(hào)本身而是設(shè)備的運(yùn)行時(shí)間。輸出末尾有“H3C Comware Software, Version 7.1.064”和系統(tǒng)啟動(dòng)時(shí)間uptime只有幾天說明設(shè)備最近重啟過。注意重點(diǎn)是異常重啟還是人為重啟這個(gè)需要對(duì)照日志確認(rèn)。常見認(rèn)知是交換機(jī)uptime都很長(zhǎng)如果某臺(tái)設(shè)備的uptime只有三天那大概率發(fā)生過掉電或死機(jī)這種設(shè)備在跑核心業(yè)務(wù)時(shí)要高度警惕必要時(shí)安排窗口期重啟一次。display clock看的是設(shè)備本地時(shí)間。這里有一個(gè)絕大多數(shù)人都會(huì)踩的坑H3C交換機(jī)的本地時(shí)間如果不做NTP同步跑幾個(gè)月就會(huì)慢幾分鐘甚至十幾分鐘。時(shí)間不準(zhǔn)的直接后果是日志時(shí)間戳錯(cuò)亂排障時(shí)把事件順序完全顛倒。很多盒式設(shè)備比如H3C S1850系列默認(rèn)通過DHCP獲取地址時(shí)可以從Option 4拿到NTP服務(wù)器地址或者通過在Web界面配置NTP。命令行下可以這樣檢查display ntp-status輸出里看Clock source是NTP還是LOCAL。如果是LOCAL說明設(shè)備在用本地時(shí)鐘這個(gè)必須處理。命令行配置NTP的常見做法是ntp-service unicast-server 192.168.10.1設(shè)備側(cè)配置完NTP后還有一個(gè)細(xì)節(jié)display ntp-status里看到的Clock offset要小于100ms才算正常否則即使同步了時(shí)間線也還是對(duì)不齊。2.3 接口與鏈路層聚合口、物理口、光模塊狀態(tài)對(duì)不上就是事故前兆接口層是巡檢里信息量最大的一塊但大多數(shù)人只敲一條display interface brief就完事了。這條命令看的是所有接口的物理狀態(tài)和鏈路協(xié)議狀態(tài)第三列Physical和第四列Link的狀態(tài)組合是關(guān)鍵Physical down, Link down物理不通查光模塊、網(wǎng)線、對(duì)端設(shè)備Physical up, Link down物理層通了但協(xié)議起不來查配置、VLAN、鏈路協(xié)商實(shí)際環(huán)境里最容易出問題的不是普通物理口而是聚合口。H3C的聚合命令在V7里叫display link-aggregation summary在V5里叫display link-aggregation verbose。巡檢時(shí)要核對(duì)聚合組里的成員口是不是和設(shè)計(jì)一致。很多事故是這樣的聚合口兩端都正常但成員口全Down了流量實(shí)際上在走透?jìng)骰蛘咭呀?jīng)斷掉只看聚合接口狀態(tài)根本發(fā)現(xiàn)不了。光模塊是另一個(gè)巡檢盲區(qū)。display transceiver interface Ten-GigabitEthernet 1/0/1能看光模塊的收發(fā)光功率一般模塊接收功率在-20dBm以上、發(fā)送功率在-3到-8dBm之間算正常。但更關(guān)鍵的是看趨勢(shì)接收功率從-15dBm掉到-19dBm雖然還在閾值內(nèi)但光鏈路在劣化。巡檢時(shí)把重要鏈路的光功率記錄下來做對(duì)比比看任何告警都管用。有些老模塊還會(huì)出現(xiàn)溫度偏高的問題display transceiver diagnosis可以看模塊內(nèi)部溫度超過70℃就要警惕了。2.4 日志層display logbuffer 不看等于白巡日志是最后一道關(guān)卡也是最容易被忽略的。display logbuffer默認(rèn)顯示的是最新的一部分日志很多人敲完看到?jīng)]有ERROR就跳過了。實(shí)際上要看的是三類東西接口反復(fù)Up/Down、CPU沖擊記錄、協(xié)議狀態(tài)機(jī)異常。接口反復(fù)Up/Down在日志里的表現(xiàn)是大量“Ten-GigabitEthernet1/0/5 link state change to DOWN”和“UP”交替出現(xiàn)這種問題在日志里刷屏但網(wǎng)管軟件往往顯示為“當(dāng)前正?！币?yàn)樗豢醋詈鬆顟B(tài)。巡檢時(shí)遇到這類日志要順著光纖去找原因大概率是對(duì)端設(shè)備重啟或光模塊不穩(wěn)定。CPU沖擊記錄要看的是“Task ran too long”或“CPU usage is high”這一類信息。Comware V7會(huì)在CPU持續(xù)超過80%時(shí)周期性輸出日志日志里會(huì)帶出具體的任務(wù)名。如果是“VIDL”任務(wù)占用高一般是硬件轉(zhuǎn)發(fā)異常如果是某些協(xié)議任務(wù)占用高比如BFD、OSPF通常是網(wǎng)絡(luò)內(nèi)有震蕩。這些信息在網(wǎng)管軟件里不一定有但日志里看得清清楚楚。3. 落一條可復(fù)現(xiàn)的巡檢命令鏈從登錄方式到批量抓取按這套流程走3.1 登錄準(zhǔn)備Console線連接參數(shù)和會(huì)話初始化三條命令做巡檢第一件事不是敲display而是把登錄環(huán)境準(zhǔn)備好。H3C交換機(jī)的Console口線序是固定的RJ45口的第3腳是TX、第6腳是RX用標(biāo)準(zhǔn)Console線連接時(shí)不需要管交叉不交叉設(shè)備端會(huì)自動(dòng)翻轉(zhuǎn)。串口參數(shù)固定為9600波特率、8位數(shù)據(jù)位、1位停止位、無校驗(yàn)、無流控。CRT或Xshell里新建串口會(huì)話時(shí)按這個(gè)填填錯(cuò)最典型的癥狀是屏幕出現(xiàn)亂碼不是連不上。登錄成功后先敲三條命令這也是很多老工程師的習(xí)慣screen-length disable temporary undo terminal monitorscreen-length disable temporary是關(guān)掉分頁(yè)顯示。默認(rèn)情況下設(shè)備輸出超過一屏?xí)Ｏ聛淼冉换パ矙z時(shí)這種交互會(huì)打斷腳本自動(dòng)抓取。加上temporary參數(shù)只對(duì)當(dāng)前會(huì)話有效不寫入配置不影響其他登錄用戶。undo terminal monitor是關(guān)閉日志輸出到當(dāng)前終端否則巡檢過程中設(shè)備產(chǎn)生的實(shí)時(shí)日志會(huì)混進(jìn)命令輸出里機(jī)器抓取時(shí)容易被干擾。有一個(gè)小細(xì)節(jié)如果通過SSH登錄而非Console關(guān)掉分頁(yè)之后建議順手做一次display clock確認(rèn)設(shè)備時(shí)間因?yàn)镾SH登錄的設(shè)備如果沒有NTP時(shí)間偏差可能很大后續(xù)所有日志排查都建立在錯(cuò)誤的時(shí)間線上。3.2 核心巡檢命令串十一個(gè)命令按順序執(zhí)行每個(gè)輸出都有明確目的下面這一段是我在實(shí)際環(huán)境里固定使用的巡檢命令串適用于Comware V5和V7盒式和框式都通用screen-length disable temporary display device display environment display version display clock display irf display interface brief display link-aggregation summary display cpu display memory display logbuffer reverse save force逐條說明執(zhí)行后看什么display device所有單板Status為Normal如果有Fault直接進(jìn)入故障流程。display environment溫度和風(fēng)扇狀態(tài)?？蚴皆O(shè)備能看到每個(gè)槽位的溫度重點(diǎn)看與上次巡檢對(duì)比的差值溫差超過10℃就要查散熱。display version確認(rèn)運(yùn)行時(shí)間。uptime超過300天屬于正常少于30天要回頭查日志看重啟原因。display clock確認(rèn)當(dāng)前時(shí)間。和你的電腦時(shí)間或NTP服務(wù)器時(shí)間相差超過1分鐘記為待整改項(xiàng)。display irf只有堆疊設(shè)備需要執(zhí)行?？碔RF的Role是Master還是Standby再看Member數(shù)量是否和實(shí)際設(shè)備數(shù)一致。堆疊分裂是重大事故巡檢時(shí)看到Master和Standby不在同一個(gè)框里就要立刻處理。display interface brief掃一眼所有接口狀態(tài)正常情況管理口Up、業(yè)務(wù)口按設(shè)計(jì)狀態(tài)存在其余接口基本是DOWN狀態(tài)。display link-aggregation summary核對(duì)聚合組狀態(tài)。Selected成員數(shù)量必須大于1如果看到只有1個(gè)Selected或者0個(gè)Selected聚合組已經(jīng)是單鏈路承載或完全故障了。display cpuV5設(shè)備看CPU占用率V7設(shè)備看各核占用率。單核100%時(shí)總占用率可能只有20%這種也要標(biāo)記為異常。display memory看內(nèi)存使用率。盒式設(shè)備內(nèi)存占用超過70%要留意超過85%基本可以認(rèn)定存在內(nèi)存泄漏需要計(jì)劃重啟或升級(jí)版本。display logbuffer reverse用reverse參數(shù)讓最新的日志顯示在最前面。重點(diǎn)看First Time和Last Time之間有沒有嚴(yán)重級(jí)別以上日志以及有沒有接口翻動(dòng)記錄。save force這條不是查看命令是保存配置。很多工程師巡檢查完不保存結(jié)果下次設(shè)備重啟回滾到兩個(gè)月前的配置所有巡檢期間的臨時(shí)改動(dòng)全沒了。save force會(huì)將當(dāng)前配置寫入下次啟動(dòng)配置文件這個(gè)動(dòng)作要有意識(shí)地養(yǎng)成習(xí)慣。3.3 三條高危命令單獨(dú)說CPU、內(nèi)存、日志緩沖區(qū)的輸出怎么讀display cpu在V7版本里的輸出會(huì)細(xì)分為Total CPU使用率、每個(gè)核的使用率和任務(wù)級(jí)占用列表。讀的時(shí)候先看總占用率是否超過70%再看有沒有單核跑滿——V7設(shè)備上單核跑滿但整體不高的情況很常見通常是某個(gè)協(xié)議任務(wù)如OSPF的IPC任務(wù)出現(xiàn)異常循環(huán)導(dǎo)致。接著看任務(wù)列表里占用率最高的幾個(gè)任務(wù)名正常的最高任務(wù)一般是“VIDL”空閑任務(wù)如果“VIDL”排不進(jìn)前三說明系統(tǒng)負(fù)載異常。display memory要看兩行Memory Used和Memory Free。注意Comware V5顯示的是“System Total Memory Bytes”和“Total Memory Used Low/LowWater”這類字符串V7里變成百分比顯示。讀的時(shí)候關(guān)鍵是看Used比例的變化趨勢(shì)因?yàn)槲乙娺^內(nèi)存使用率緩慢爬升直到85%后整機(jī)重啟的案例。如果兩次巡檢之間內(nèi)存使用率漲了超過10%要當(dāng)作內(nèi)存異常增長(zhǎng)處理不能等它漲到告警閾值。display logbuffer有一個(gè)容易混淆的參數(shù)問題設(shè)備默認(rèn)只輸出最近的一部分日志緩沖區(qū)本身有容量上限默認(rèn)256條級(jí)別以上日志。想完整導(dǎo)出得用display logbuffer reverse或者加| include做過濾。最實(shí)用的做法是抓全部日志存到本地后再用文本工具做二次篩選。因?yàn)檠矙z當(dāng)時(shí)人眼掃一遍只能看到最后一屏歷史日志里往往藏著重要線索比如一周前某接口抖動(dòng)了五次而網(wǎng)管系統(tǒng)沒有告警。4. 常見問題與避坑五個(gè)真實(shí)翻車場(chǎng)景每個(gè)都有后悔藥4.1 display logbuffer刷屏?xí)捒ǖ角妹顩]反應(yīng)現(xiàn)象執(zhí)行display logbuffer后終端輸出持續(xù)滾動(dòng)命令完全無法中斷等了幾分鐘還在刷。原因設(shè)備日志緩沖區(qū)里積累了數(shù)千條日志其中大部分是接口翻動(dòng)或合規(guī)審計(jì)類的低級(jí)別日志。默認(rèn)分頁(yè)被關(guān)閉后所有內(nèi)容一次性輸出串口帶寬只有9600bps刷完整個(gè)緩沖區(qū)需要很長(zhǎng)時(shí)間。解決登錄后不要直接執(zhí)行display logbuffer先執(zhí)行display logbuffer summary看日志總量。如果條數(shù)超過500條先過濾再抓取比如用display logbuffer | include link state只抓接口狀態(tài)變化記錄或者指定時(shí)間范圍display logbuffer log-buffer size 200。抓取前也可以通過info-center loghost把日志轉(zhuǎn)發(fā)到日志服務(wù)器減輕設(shè)備側(cè)緩沖區(qū)壓力。4.2 聚合口狀態(tài)明明是Up流量卻斷斷續(xù)續(xù)現(xiàn)象某業(yè)務(wù)網(wǎng)段的流量時(shí)通時(shí)不通查看display link-aggregation summary看到聚合口狀態(tài)是Up但實(shí)際轉(zhuǎn)發(fā)異常。原因聚合組成員口狀態(tài)和聚合口狀態(tài)不一致。成員口中部分接口物理Down或協(xié)商失敗但聚合組仍處于Loaded狀態(tài)流量被哈希到失效的成員口上導(dǎo)致部分會(huì)話丟包。解決巡檢時(shí)不僅要看聚合口還要逐成員核對(duì)。常見做法是執(zhí)行display link-aggregation member-port display interface Ten-GigabitEthernet 1/0/1逐一確認(rèn)成員口的Last 300 seconds input/output速率如果某個(gè)成員口速率接近0而其他口有流量說明哈希不均勻或成員口異常。另外V7里可以執(zhí)行display link-aggregation load-sharing查看是否啟用了增強(qiáng)負(fù)載均衡默認(rèn)按報(bào)文五元組取模哈希如果流數(shù)量較少很容易出現(xiàn)流量集中在單成員口的情況這種不算故障但需要調(diào)整負(fù)載均衡模式。4.3 堆疊設(shè)備只看了主框備框的告警全瞎現(xiàn)象IRF堆疊環(huán)境里巡檢時(shí)只在當(dāng)前登錄的框上敲了一遍display命令沒有切到備框查看結(jié)果備框單板Fault一直沒有被發(fā)現(xiàn)。原因IRF堆疊后通過任意一個(gè)成員框登錄命令默認(rèn)只作用于當(dāng)前框。很多命令不帶slot參數(shù)時(shí)只顯示當(dāng)前框的信息特別是display device不同版本行為不一致有的顯示全量有的只顯示本框。解決巡檢IRF堆疊時(shí)養(yǎng)成帶irf參數(shù)的暴力習(xí)慣display irf display device irf display environment irfdisplay device irf會(huì)列出所有成員框的單板狀態(tài)。如果只想看某個(gè)成員框用display device slot 1或display device slot 2分別查看。另外要注意文本框和備框的版本一致性display version的輸出里如果看到兩個(gè)成員框的軟件版本不同要立刻安排升級(jí)否則堆疊系統(tǒng)在角色切換時(shí)會(huì)出現(xiàn)兼容性問題。4.4 save force把上線配置覆蓋了回滾不了現(xiàn)象巡檢時(shí)執(zhí)行了save force第二天發(fā)現(xiàn)設(shè)備重啟后配置變成了舊版本某些業(yè)務(wù)VLAN的接口配置缺失業(yè)務(wù)中斷。原因save force保存的是當(dāng)前運(yùn)行配置到下次啟動(dòng)配置。如果巡檢前有人調(diào)試過配置但沒有確認(rèn)正確性運(yùn)行配置里可能殘留錯(cuò)誤或中間態(tài)配置此時(shí)保存就把壞配置寫死了。更常見的是巡檢人員登錄后什么都不改直接save但之前另一位工程師已經(jīng)改了運(yùn)行配置且還沒保存save操作把半成品配置固化。解決save 前先執(zhí)行一次display current-configuration | include vlan和display startup確認(rèn)下次啟動(dòng)配置文件的修改時(shí)間與當(dāng)前配置一致。最穩(wěn)妥的做法是保存前先備份現(xiàn)有啟動(dòng)配置copy startup.cfg backup_20240601.cfg然后才執(zhí)行save force。這樣即使保存出錯(cuò)還能用startup saved-configuration backup_20240601.cfg回滾。巡檢命令串聯(lián)里save force必須排在所有檢查命令之后并且保存前確認(rèn)無人正在設(shè)備上調(diào)試這是血的教訓(xùn)。4.5 設(shè)備時(shí)間沒同步日志對(duì)不上網(wǎng)管時(shí)間線現(xiàn)象網(wǎng)絡(luò)出故障后回溯日志設(shè)備日志時(shí)間比網(wǎng)管系統(tǒng)時(shí)間慢了一個(gè)多小時(shí)事件順序錯(cuò)亂無法定位真正的故障起點(diǎn)。原因設(shè)備沒有正確配置NTP或者NTP服務(wù)指向的服務(wù)器不可達(dá)。很多H3C盒式設(shè)備比如S1850默認(rèn)開啟DHCP時(shí)自動(dòng)從Option 4獲取NTP服務(wù)器但如果使用靜態(tài)IPNTP服務(wù)就是空的設(shè)備時(shí)間靠手動(dòng)設(shè)置跑幾天就會(huì)漂移。解決巡檢時(shí)把display ntp-status作為必查項(xiàng)看到Clock source為L(zhǎng)OCAL就是問題。命令行配置NTP的完整做法ntp-service unicast-server 192.168.10.1 ntp-service enable配置完成后等待幾分鐘再執(zhí)行display ntp-status確認(rèn)Clock source變成NTP、Clock offset降到100ms以下。如果NTP服務(wù)器不可達(dá)至少也要保證每月手動(dòng)校準(zhǔn)一次否則時(shí)間漂移到小時(shí)級(jí)后日志排查完全失效。這個(gè)問題在巡檢命令里特別容易被忽略但它是最便宜、收益最高的一個(gè)動(dòng)作。4.6 光模塊功率是負(fù)的但鏈路正常三個(gè)月的趨勢(shì)線才見分曉現(xiàn)象某條鏈路偶爾出現(xiàn)丟包每次持續(xù)幾分鐘后自動(dòng)恢復(fù)。檢查光模塊接收功率在-20dBm邊緣但接口狀態(tài)一直是Up設(shè)備沒有告警。原因光模塊接收功率處于靈敏度和飽和點(diǎn)之間的邊緣區(qū)域。多數(shù)光模塊的告警閾值設(shè)得很寬從-30dBm到-3dBm都不告警但實(shí)際鏈路質(zhì)量已經(jīng)在劣化偶發(fā)誤碼導(dǎo)致丟包。解決巡檢時(shí)對(duì)重要鏈路執(zhí)行display transceiver interface記錄收發(fā)光功率。我的做法是把功率數(shù)據(jù)寫進(jìn)巡檢表每次巡檢后對(duì)比上一次的值如果接收功率下降超過3dB就列入觀察名單再降3dB就該換模塊或清洗光纖接頭。這種方法比等設(shè)備告警可靠得多因?yàn)楣饽K故障從來不是突變的都是慢慢劣化而網(wǎng)管軟件不會(huì)給你畫功率趨勢(shì)線。5. 進(jìn)階一點(diǎn)把巡檢命令固化成腳本跑完自動(dòng)留痕對(duì)比基線巡檢不能永遠(yuǎn)靠人肉敲命令。到了這一步我的做法是把整套命令寫進(jìn)Python腳本借助paramiko庫(kù)批量SSH登錄設(shè)備執(zhí)行并抓取輸出然后存儲(chǔ)為帶日期的文本文件再和上次的基線做diff。一個(gè)最小可用的腳本長(zhǎng)這樣import paramiko import datetime # 定義設(shè)備清單按實(shí)際環(huán)境修改IP、賬號(hào)、密碼 devices [ {host: 192.168.10.1, username: admin, password: passwd}, {host: 192.168.10.2, username: admin, password: passwd}, ] # 巡檢命令串每條命令之間留一點(diǎn)間隔等待輸出 commands [ screen-length disable temporary, display device, display environment, display clock, display interface brief, display cpu, display memory, display logbuffer reverse, ] for dev in devices: ssh paramiko.SSHClient() ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy()) ssh.connect(dev[host], port22, usernamedev[username], passworddev[password], timeout10) # 通過invoke_shell進(jìn)入交互式shell逐條執(zhí)行命令 shell ssh.invoke_shell() output for cmd in commands: shell.send(cmd \n) time.sleep(2) # 等待設(shè)備輸出可根據(jù)設(shè)備性能調(diào)整 # 讀取全部回顯 while shell.recv_ready(): output shell.recv(65535).decode(utf-8, errorsignore) # 保存為帶日期的文件文件名格式IP_YYYYMMDD.txt date_str datetime.datetime.now().strftime(%Y%m%d) filename f{dev[host]}_{date_str}.txt with open(filename, w, encodingutf-8) as f: f.write(output) ssh.close()這個(gè)腳本里的每個(gè)參數(shù)都值得說明shell.send每次發(fā)一個(gè)命令加換行符發(fā)送后sleep 2秒是因?yàn)镠3C設(shè)備執(zhí)行display命令需要時(shí)間sleep太短會(huì)導(dǎo)致輸出和下一屏內(nèi)容拼接在一起抓到的文本就對(duì)不上號(hào)了。shell.recv_ready()循環(huán)讀取回顯是一次性把緩沖區(qū)內(nèi)容取空避免部分輸出殘留到下一個(gè)設(shè)備。腳本跑完后的關(guān)鍵動(dòng)作是留痕和對(duì)比。我習(xí)慣把巡檢文本按設(shè)備分目錄存放然后每周用diff工具和上周的記錄比一遍。重點(diǎn)看的是設(shè)備重啟時(shí)間變化、CPU使用率波動(dòng)、日志緩沖區(qū)里有沒有新的嚴(yán)重告警。有條件的團(tuán)隊(duì)還可以再進(jìn)一步把巡檢腳本掛到計(jì)劃任務(wù)里每周固定時(shí)間跑一次輸出文件自動(dòng)歸檔到共享盤。設(shè)備超過十條以后人肉巡檢本質(zhì)上已經(jīng)不可靠了定期巡檢的收益并不在于每條命令的執(zhí)行而在于那根橫跨兩周時(shí)間、爬升了10℃的溫度曲線或者一條悄悄從-15dBm掉到-19dBm的光路功率。我自己現(xiàn)在的習(xí)慣是每次巡檢完順手用display save存一份配置快照哪怕不改任何配置也存。三個(gè)月后設(shè)備出了問題拿著當(dāng)時(shí)的配置文件和日志對(duì)著查比現(xiàn)場(chǎng)翻設(shè)備省力十倍。希望這份命令清單和腳本思路幫到你少踩幾個(gè)我當(dāng)年踩過的坑。本文還有配套的精品資源點(diǎn)擊獲取