簡介面向網(wǎng)絡(luò)運(yùn)維人員與H3C設(shè)備管理員這份H3C交換機(jī)巡檢命令文檔系統(tǒng)梳理了日常設(shè)備巡檢中最關(guān)鍵的八類檢查項(xiàng)CPU使用率、內(nèi)存占用、設(shè)備溫度、硬件匯總信息、風(fēng)扇運(yùn)行狀態(tài)、電源健康狀態(tài)、系統(tǒng)時(shí)鐘準(zhǔn)確性以及接口鏈路狀態(tài)。每個(gè)命令都配有作用說明、具體執(zhí)行方式與典型輸出示例并對(duì)關(guān)鍵輸出字段進(jìn)行了解讀如內(nèi)存使用率百分比、溫度傳感器的入風(fēng)與熱點(diǎn)閾值、風(fēng)扇和電源的Normal/Fault狀態(tài)標(biāo)識(shí)、設(shè)備型號(hào)與運(yùn)行時(shí)間、接口的Link/Protocol狀態(tài)等。通過對(duì)照這些信息運(yùn)維人員可以快速識(shí)別設(shè)備潛在風(fēng)險(xiǎn)并采取修復(fù)措施有效避免因資源耗盡、高溫或硬件故障導(dǎo)致的業(yè)務(wù)中斷。資源為單個(gè)doc文檔體積僅21KB內(nèi)容緊湊實(shí)用適合打印或在終端旁快速查閱。目前已有588人學(xué)習(xí)下載可作為H3C交換機(jī)日常維護(hù)與故障排查的入門參考。1. 先把H3C交換機(jī)巡檢命令.doc這件事說清楚它解決什么、適合誰每天早上到客戶機(jī)房我習(xí)慣先把核心交換機(jī)登錄上去看一眼CPU、光衰、日志有沒有異常確認(rèn)昨晚沒出幺蛾子才敢開始動(dòng)配置。H3C交換機(jī)巡檢命令.doc就是這個(gè)動(dòng)作的物化把散在官方手冊(cè)里的display命令挑出十幾條排成一張固定順序的檢查清單讓任何接手的人都能在半小時(shí)內(nèi)完成一次“不漏項(xiàng)、結(jié)果可對(duì)比”的設(shè)備體檢。它不是網(wǎng)管系統(tǒng)的替代品但對(duì)剛接手H3C設(shè)備、沒有統(tǒng)一監(jiān)控平臺(tái)、或者要替客戶做例行巡檢的工程師來說比翻手冊(cè)高效得多。這篇文章就圍繞命令怎么選、執(zhí)行順序怎么排、輸出怎么判讀來講。2. 巡檢前先處理三件事登錄方式、會(huì)話設(shè)置和配置基線2.1 登錄方式怎么選Console、Telnet、SSH各有各的脾氣巡檢第一步是登錄設(shè)備但登錄方式選不對(duì)后面全白搭。常見做法是優(yōu)先走SSH因?yàn)樗用苓h(yuǎn)程改配置不會(huì)明文暴露Console口留給設(shè)備失聯(lián)或SSH登錄不了時(shí)的最后手段Telnet能用但明文傳輸我在生產(chǎn)環(huán)境基本不碰除非客戶內(nèi)網(wǎng)隔離得足夠干凈。如果你用的是SecureCRT或者M(jìn)obaXtermConsole登錄就是選Serial波特率9600數(shù)據(jù)位8無校驗(yàn)。MobaXterm的Session面板里直接選Serial端口會(huì)自動(dòng)識(shí)別USB轉(zhuǎn)串口的那個(gè)COM號(hào)連上后回車就能看到H3C的提示符。這里有個(gè)容易被忽略的點(diǎn)H3C設(shè)備默認(rèn)不一定開啟SSH服務(wù)很多新拿到的設(shè)備只配了Telnet或者Console你直接用CRT去SSH連接會(huì)卡在“Connection failed”上——這不是密碼錯(cuò)了是設(shè)備壓根沒開這個(gè)服務(wù)。在設(shè)備上按下面方式開啟SSH以Comware V7為主V5大體類似system-view ssh server enable # 創(chuàng)建一個(gè)本地用戶并讓它能通過SSH登錄 local-user admin class manage password simple YourPassword service-type ssh authorization-attribute user-role network-admin quit這段配置的關(guān)鍵在于local-user admin class manage里的service-type ssh。很多踩坑的人只開了ssh server enable忘了給本地用戶加SSH服務(wù)類型結(jié)果就是“密碼正確但登錄被拒”。V5設(shè)備上不用寫class manage直接local-user admin即可。巡檢建議不要用超級(jí)管理員賬號(hào)做日常登錄能用一個(gè)只讀級(jí)別賬號(hào)最好但現(xiàn)實(shí)是客戶給的往往是admin所以至少要做到巡檢時(shí)不亂敲配置命令。2.2 會(huì)話設(shè)置關(guān)閉分頁和日志回顯讓命令輸出不被截?cái)嗟卿浿笙葎e急著敲巡檢命令把會(huì)話環(huán)境調(diào)好。H3C默認(rèn)開啟分屏顯示輸出長一點(diǎn)就會(huì)停在---- More ----等你按空格。巡檢時(shí)如果你用的是CRT或MobaXterm這一屏一屏翻過去既慢又容易漏而且腳本批量操作時(shí)會(huì)直接卡死。我的習(xí)慣是登錄后先執(zhí)行下面兩條screen-length disable undo terminal monitorscreen-length disable在用戶視圖下執(zhí)行只對(duì)當(dāng)前會(huì)話生效作用是臨時(shí)關(guān)閉分屏讓display輸出一次性完整滾出來不會(huì)卡在More上。注意它是“臨時(shí)”的重登就恢復(fù)默認(rèn)所以不用擔(dān)心影響其他運(yùn)維同事。undo terminal monitor是關(guān)掉終端的日志回顯——設(shè)備上有接口up/down、OSPF鄰居抖動(dòng)之類的信息時(shí)會(huì)往終端刷屏把命令輸出和日志混在一起影響判斷。巡檢時(shí)把它關(guān)掉輸出干凈巡檢完建議重新登錄或者直接不管因?yàn)闀?huì)話結(jié)束就恢復(fù)。還有一條容易被忽略但很重要先執(zhí)行display clock確認(rèn)設(shè)備時(shí)間。日志里的事件時(shí)間全靠這個(gè)時(shí)鐘如果時(shí)間不對(duì)后面所有告警分析全是錯(cuò)的。display clock這一步我一般放在會(huì)話設(shè)置之后、正式巡檢之前幾秒鐘的事但能避免后面分析日志時(shí)發(fā)現(xiàn)時(shí)間基準(zhǔn)是歪的。常見做法是把display clock作為巡檢命令模板的第一條固定命令。2.3 巡檢前的基線備份先留后路再動(dòng)手巡檢不只是“看狀態(tài)”還要和上次的狀態(tài)做對(duì)比所以巡檢前把當(dāng)前配置備份下來是鐵律。很多剛?cè)胄械墓こ處熈?xí)慣最后才備份但巡檢過程中可能會(huì)因?yàn)檎`操作改到配置或者發(fā)現(xiàn)某個(gè)配置不對(duì)勁順手調(diào)了一下這時(shí)如果已經(jīng)備份過至少有個(gè)后悔藥。display current-configuration save cfg-backup-YYYYMMDD.cfgdisplay current-configuration是查看運(yùn)行配置輸出很長建議配合前面的screen-length disable一起用輸出重定向到本地保存。save命令是把運(yùn)行配置保存到下次啟動(dòng)的配置文件里文件名里帶上日期比如cfg-backup-20250611.cfg。需要注意save會(huì)覆蓋設(shè)備默認(rèn)的啟動(dòng)配置。如果只是巡檢、沒有改動(dòng)需求不要隨便save如果確實(shí)改了配置需要保存先display current-configuration看一眼改動(dòng)是否合理再執(zhí)行save。我見過有人巡檢時(shí)順手save結(jié)果把之前臨時(shí)調(diào)試用的interface shutdown配置固化了設(shè)備重啟后端口起不來——這就是典型的“巡檢變事故”。3. 日常巡檢命令組從硬件到日志一路查過來3.1 系統(tǒng)和硬件狀態(tài)版本、序列號(hào)、風(fēng)扇、電源和溫度巡檢命令不是亂敲的我按“從底層到上層”的順序來。第一組關(guān)注設(shè)備本身能不能穩(wěn)定運(yùn)行。display version display device display fan display power display environmentdisplay version看軟件版本和系統(tǒng)運(yùn)行時(shí)間重點(diǎn)看版本是否已知有Bug以及設(shè)備是否剛重啟過。display device看板卡狀態(tài)重點(diǎn)看State是不是Normal如果有Fault就要留意了。display fan和display power分別看風(fēng)扇和電源Status字段為Normal才算正常。display environment看溫度H3C設(shè)備一般有當(dāng)前溫度、上下限閾值溫度接近上限說明機(jī)房通風(fēng)有問題需要處理。這幾個(gè)命令都比較短輸出也不長適合巡檢模板開頭先打出來。如果設(shè)備是堆疊環(huán)境再加一條display irf看堆疊成員是否齊全、角色是否正常。堆疊設(shè)備巡檢漏掉IRF狀態(tài)是常見失誤——單臺(tái)設(shè)備看著正常但堆疊分裂了業(yè)務(wù)其實(shí)已經(jīng)出問題了。3.2 接口與光模塊光衰怎么看、什么范圍算健康接口是交換機(jī)最核心的資源。巡檢時(shí)我通常先看接口概覽再重點(diǎn)查光模塊收發(fā)光。display interface brief display transceiver diagnosis interface Ten-GigabitEthernet 1/0/1display interface brief列出所有接口的Link狀態(tài)和Protocol狀態(tài)一眼就能看出哪些端口down了。如果某個(gè)關(guān)鍵業(yè)務(wù)端口down可能只是對(duì)端設(shè)備關(guān)機(jī)也可能是光纜斷了需要進(jìn)一步排查。光模塊是另一個(gè)高頻問題點(diǎn)。display transceiver diagnosis interface會(huì)輸出光模塊的收發(fā)光功率、溫度、電壓等數(shù)字診斷信息。注意這個(gè)命令需要光模塊支持DDM數(shù)字診斷監(jiān)控功能原廠模塊基本都支持有些第三方模塊會(huì)顯示--這是模塊不帶監(jiān)控或兼容性問題不代表光路正常。紫光等國產(chǎn)設(shè)備命令風(fēng)格與H3C相近也適用這個(gè)思路。光衰的參數(shù)解釋需要單獨(dú)說清楚收發(fā)光功率的單位是dBm數(shù)值越小表示功率越低。常見閾值是接收光功率在-3dBm到-14dBm之間屬于正常低于-20dBm就要警惕可能出現(xiàn)誤碼低于-27dBm基本會(huì)閃斷甚至完全不通。發(fā)送光功率一般比接收高不同模塊差異大但關(guān)鍵是看它是否穩(wěn)定不要忽高忽低。如果這條命令不支持退一步用display transceiver interface Ten-GigabitEthernet 1/0/0看模塊基礎(chǔ)信息至少能確認(rèn)模塊是否被識(shí)別、溫度是否異常。3.3 CPU、內(nèi)存與日志系統(tǒng)是否在“帶病運(yùn)行”CPU和內(nèi)存代表設(shè)備當(dāng)前的負(fù)載日志則記錄它過去發(fā)生過什么。三者一起看才能判斷設(shè)備是健康還是“帶病運(yùn)行”。display cpu-usage display memory display logbufferComware V7用display cpu-usageV5上是display cpu注意區(qū)分。CPU使用率看兩個(gè)值當(dāng)前值和5秒內(nèi)峰值。H3C交換機(jī)轉(zhuǎn)發(fā)主要靠芯片CPU高不一定影響轉(zhuǎn)發(fā)但如果長期超過50%要查是不是有大量控制報(bào)文沖擊比如ARP攻擊、路由震蕩。display memory看內(nèi)存使用率長期超過70%就要關(guān)注是否有內(nèi)存泄漏常見誘因是開啟了過多NetStream采樣或大量ACL統(tǒng)計(jì)。display logbuffer看的是設(shè)備內(nèi)存里的日志緩沖區(qū)重點(diǎn)看有沒有反復(fù)出現(xiàn)的告警比如接口頻繁up/down、光模塊告警、協(xié)議鄰居震蕩。日志緩沖區(qū)容量有限如果設(shè)備長時(shí)間未重啟老日志會(huì)被覆蓋所以巡檢發(fā)現(xiàn)重要日志時(shí)建議用display logbuffer看完后關(guān)鍵內(nèi)容截取保存。有一條命令容易被忽略display ntp-status。設(shè)備時(shí)間如果通過NTP同步這里能看到同步狀態(tài)。沒有NTP的設(shè)備日志時(shí)間會(huì)慢慢漂移出現(xiàn)問題后回溯時(shí)對(duì)不上時(shí)間點(diǎn)。巡檢時(shí)發(fā)現(xiàn)NTP未同步可以在后續(xù)整改時(shí)把NTP配置補(bǔ)上。3.4 鏈路與冗余聚合口、STP狀態(tài)看一眼更安心如果設(shè)備承擔(dān)著核心或匯聚角色鏈路冗余狀態(tài)必須納入巡檢范圍。display link-aggregation summary display stp brief display mac-addressdisplay link-aggregation summary看聚合口成員是否都在Selected狀態(tài)如果成員口是Unselected說明鏈路有問題或者對(duì)端配置不一致。display stp brief看STP端口狀態(tài)正常應(yīng)該是FORWARDING出現(xiàn)BLOCKING不一定有問題——可能是冗余路徑故意阻塞但如果是應(yīng)該轉(zhuǎn)發(fā)的端口在Blocking就要檢查配置了。display mac-address看MAC表項(xiàng)數(shù)量是否正常數(shù)量異常波動(dòng)可能意味著環(huán)路或MAC漂移。這一組命令通常不用每次巡檢都完整執(zhí)行。我一般每周做一次完整巡檢時(shí)跑一遍每日快速巡檢只跑接口和CPU。4. 把命令固化成doc模板腳本采集和判讀標(biāo)準(zhǔn)一起落地4.1 doc模板怎么排先結(jié)構(gòu)后命令別讓巡檢變成碰運(yùn)氣“H3C交換機(jī)巡檢命令.doc”這個(gè)標(biāo)題的關(guān)鍵在“doc”也就是巡檢模板本身。模板的價(jià)值在于固定順序、固定項(xiàng)目、留出判讀空間。我見過不少人把命令直接堆在一個(gè)文檔里巡檢時(shí)照著敲但輸出沒有對(duì)齊過幾天就忘了上次結(jié)果是什么。我習(xí)慣的模板結(jié)構(gòu)分六塊設(shè)備基本信息、硬件狀態(tài)、接口狀態(tài)、光模塊、CPU內(nèi)存、日志告警。每塊列出對(duì)應(yīng)的命令、預(yù)期輸出字段、以及“正常/異?！迸凶x標(biāo)準(zhǔn)。設(shè)備基本信息用display version和display clock開頭記錄巡檢日期讓每次巡檢都有時(shí)間錨點(diǎn)。模板里給每條命令留一個(gè)“判讀”列不寫死結(jié)果而是寫閾值比如“CPU使用率50%峰值80%”這樣巡檢人有據(jù)可依。表格在doc里有獨(dú)特價(jià)值。比如光模塊判讀表參數(shù)正常范圍關(guān)注范圍異常范圍接收光功率-3dBm ~ -14dBm-14dBm ~ -20dBm低于-20dBm發(fā)送光功率穩(wěn)定在模塊標(biāo)稱范圍波動(dòng)超過3dB明顯衰減或無輸出模塊溫度低于報(bào)警閾值接近閾值超過閾值電壓標(biāo)準(zhǔn)值±5%偏差較大嚴(yán)重偏差這個(gè)表格我每次都會(huì)放進(jìn)巡檢doc里比單純列命令有用得多。華為、思科、銳捷的命令與H3C有相似之處尤其華為和H3C同源display風(fēng)格接近思科更偏show體系。做巡檢模板時(shí)如果團(tuán)隊(duì)同時(shí)管多種設(shè)備建議按設(shè)備品牌分sheet命令不要混在一個(gè)模板里容易敲串。4.2 用Python批量采集命令輸出解放雙手但別盲目自動(dòng)化手動(dòng)逐條敲命令適合少數(shù)幾臺(tái)設(shè)備設(shè)備一多就容易漏。我自己會(huì)用Python的paramiko庫寫一個(gè)批量巡檢腳本把命令輸出按設(shè)備存檔。腳本邏輯很簡單連接設(shè)備→執(zhí)行命令列表→把輸出寫入txt文件。import paramiko import datetime devices [ {host: 192.168.1.10, username: admin, password: YourPass}, ] commands [ display clock, display version, display device, display interface brief, display transceiver diagnosis interface, display cpu-usage, display memory, display logbuffer, ] today datetime.datetime.now().strftime(%Y%m%d) 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) output_lines [] for cmd in commands: stdin, stdout, stderr ssh.exec_command(cmd \n, timeout30) output stdout.read().decode(utf-8, errorsignore) output_lines.append(f {cmd} ) output_lines.append(output) ssh.close() filename fh3c_{dev[host]}_{today}.txt with open(filename, w, encodingutf-8) as f: f.write(\n.join(output_lines)) print(f已保存 {filename})腳本里要注意幾個(gè)參數(shù)paramiko本身需要pip install paramiko安裝exec_command每執(zhí)行一條命令都是獨(dú)立的SSH會(huì)話命令之間不保留上下文所以screen-length disable這類會(huì)話級(jí)設(shè)置要放進(jìn)每條命令之前或者在命令列表里把每條display命令后面加上分頁關(guān)閉參數(shù)。更穩(wěn)妥的方式是連接后先執(zhí)行screen-length disable但exec_command之間的會(huì)話不共享這確實(shí)是個(gè)坑。我一般會(huì)改成用ssh.invoke_shell()創(chuàng)建交互式shell先發(fā)screen-length disable再逐條發(fā)送命令這樣能模擬手動(dòng)操作時(shí)的完整會(huì)話。timeout參數(shù)建議設(shè)30秒以上某些命令如display current-configuration在設(shè)備繁忙時(shí)會(huì)很慢超時(shí)太短會(huì)導(dǎo)致輸出截?cái)唷?.3 判讀標(biāo)準(zhǔn)要寫在doc里輸出不等于結(jié)論采集完輸出最關(guān)鍵的是怎么判讀。很多巡檢表格只記了輸出原文沒有判讀結(jié)論這就失去了巡檢的意義。我建議doc模板里加一列“結(jié)論”用“正常/關(guān)注/異常”三檔來標(biāo)記。判讀的基本原則CPU和內(nèi)存看是否超過基線接口看有沒有非預(yù)期down口光模塊看收發(fā)光是否在正常范圍日志看有沒有重復(fù)告警?；€數(shù)據(jù)從哪來來自設(shè)備穩(wěn)定運(yùn)行期間的多次巡檢平均值。沒有基線單看一次輸出很難判斷CPU 40%是高還是低。如果發(fā)現(xiàn)異常doc模板里應(yīng)該留“排查行動(dòng)”欄寫下一步要做什么。比如光衰低于-20dBm行動(dòng)是檢查尾纖是否彎折、法蘭是否松動(dòng)、對(duì)端模塊是否正常。沒有行動(dòng)項(xiàng)的巡檢報(bào)告客戶看了也不知道該怎么辦最后只能變成一張沒意義的表格。5. 巡檢避坑5個(gè)最常見的問題與排查思路5.1 現(xiàn)象CRT的SSH連不上H3C設(shè)備提示連接失敗或被拒絕原因H3C設(shè)備默認(rèn)沒有開啟SSH服務(wù)或者本地用戶沒有SSH服務(wù)類型只開了Telnet。很多新交付的設(shè)備配置里只有Console和Telnet訪問遠(yuǎn)程SSH 22端口并不存在。解決登錄Console口在系統(tǒng)視圖下執(zhí)行ssh server enable然后local-user admin class manage里加service-type ssh。檢查是否還有其他限制比如ACL限制了管理網(wǎng)段。排查時(shí)按順序看display ssh server status和display local-user確認(rèn)服務(wù)開啟和用戶綁定都正確。5.2 現(xiàn)象執(zhí)行display命令輸出卡在More腳本或粘貼的命令被吞掉原因H3C默認(rèn)開啟分屏輸出長度超過一屏就暫停等待輸入此時(shí)粘貼的后續(xù)命令會(huì)被當(dāng)作翻頁操作吞掉導(dǎo)致命令不完整或誤操作。解決用戶視圖下執(zhí)行screen-length disable臨時(shí)關(guān)閉當(dāng)前會(huì)話分屏。需要寫腳本批量巡檢時(shí)注意在每條命令前確保分頁已關(guān)閉如果是CRT手動(dòng)操作登錄后第一件事就執(zhí)行這條命令。不要試圖用CRT的“自動(dòng)發(fā)送空格”去翻頁那樣既慢又容易漏。5.3 現(xiàn)象光模塊收發(fā)光顯示--查詢不到任何數(shù)值原因光模塊不支持DDM數(shù)字診斷功能或者模塊與設(shè)備兼容性不佳導(dǎo)致設(shè)備讀取不到診斷數(shù)據(jù)。常見于第三方模塊。解決用display transceiver interface查看模塊基礎(chǔ)信息確認(rèn)模塊是否被識(shí)別。如果基礎(chǔ)信息正常但無DDM數(shù)據(jù)只能更換支持DDM的原廠模塊否則光衰判斷無依據(jù)。巡檢模板里要特別標(biāo)注哪些口是這類模塊避免每次巡檢都誤判為異常。5.4 現(xiàn)象日志里的時(shí)間與當(dāng)前時(shí)間相差數(shù)小時(shí)告警分析對(duì)不上原因設(shè)備沒有配置NTP也沒有設(shè)置時(shí)區(qū)或者時(shí)區(qū)設(shè)置錯(cuò)誤。Comware設(shè)備默認(rèn)使用UTC時(shí)間國內(nèi)環(huán)境需要手動(dòng)設(shè)置UTC8時(shí)區(qū)。解決配置clock timezone Beijing add 8再配置NTP同步ntp-service enable、ntp-service unicast-server指向NTP服務(wù)器。巡檢時(shí)執(zhí)行display ntp-status確認(rèn)同步狀態(tài)如果NTP服務(wù)器不可達(dá)至少手動(dòng)校準(zhǔn)clock datetime。不解決時(shí)間問題日志分析基本等于猜。5.5 現(xiàn)象巡檢時(shí)隨手save重啟后配置與預(yù)期不符原因save會(huì)把運(yùn)行配置寫入啟動(dòng)配置覆蓋原有配置文件。如果巡檢前設(shè)備上有臨時(shí)改動(dòng)比如測試接口shutdown或臨時(shí)加了一條ACLsave會(huì)把它們固化導(dǎo)致重啟后行為改變。解決巡檢前用display current-configuration查看完整配置確認(rèn)沒有臨時(shí)調(diào)試配置再執(zhí)行save。異常存儲(chǔ)時(shí)使用save cfg-backup-YYYYMMDD.cfg不要直接覆蓋默認(rèn)啟動(dòng)配置。設(shè)備多臺(tái)批量巡檢時(shí)尤其要注意別在腳本里自動(dòng)save——腳本操作沒有人在現(xiàn)場確認(rèn)配置狀態(tài)。6. 巡檢結(jié)果歸檔一張時(shí)間線表加一條救命習(xí)慣巡檢做完結(jié)果不能只留在終端里。我現(xiàn)在的習(xí)慣是每臺(tái)設(shè)備一個(gè)文件夾按日期命名里面放巡檢輸出txt、告警截圖、配置備份。文件夾里額外放一張歸檔說明表記錄巡檢日期、設(shè)備IP、關(guān)鍵判讀結(jié)論。日期設(shè)備CPU峰值內(nèi)存峰值接收光衰最差日志告警結(jié)論2025-06-11核心-S7006X35%42%-13.5dBm無正常2025-06-04核心-S7006X42%45%-15.2dBm接口抖動(dòng)1次觀察這張時(shí)間線表是判斷設(shè)備“是否在惡化”的核心依據(jù)。單次巡檢只能反映當(dāng)下狀態(tài)多次巡檢拉出趨勢才能發(fā)現(xiàn)光衰在逐周下降、內(nèi)存緩慢增長這類問題。沒有歸檔巡檢就只是重復(fù)勞動(dòng)。還有一個(gè)習(xí)慣值得分享每次巡檢前先執(zhí)行display clock和display version這兩條命令的輸出是后續(xù)所有判讀的時(shí)間錨點(diǎn)和版本錨點(diǎn)。版本變了要知會(huì)變更流程時(shí)間不對(duì)要先校準(zhǔn)再談日志分析。這個(gè)習(xí)慣幫我發(fā)現(xiàn)過兩次設(shè)備在夜間自動(dòng)重啟的隱患重啟日志在logbuffer里被覆蓋了但版本運(yùn)行時(shí)間出賣了它。日志集中化也是值得做的延伸網(wǎng)管平臺(tái)上用syslog-ng搭建一個(gè)日志服務(wù)把交換機(jī)日志實(shí)時(shí)收到服務(wù)器上巡檢時(shí)就多了一個(gè)歷史日志回溯的渠道。設(shè)備本地日志緩沖區(qū)再大也會(huì)被覆蓋集中化日志才是長期可追溯的方案。巡檢這件事本身不產(chǎn)生價(jià)值產(chǎn)生價(jià)值的是持續(xù)的對(duì)比和及時(shí)的行動(dòng)。希望對(duì)你有幫助。本文還有配套的精品資源點(diǎn)擊獲取