服務(wù)器性能出問題的時候大多數(shù)人第一反應(yīng)是跑一把top看一眼CPU是不是爆了然后就沒有然后了。真正要定位一個問題光有這幾秒的瞬時數(shù)據(jù)完全不夠需要的是連續(xù)幾個小時的監(jiān)控曲線CPU到底在哪個時間點飆升內(nèi)存是逐步被吃光還是突然跳變磁盤I/O高峰和業(yè)務(wù)高峰是否重疊。nmon這套工具恰恰就是為這種場景設(shè)計的而且它天生適合離線環(huán)境——單個可執(zhí)行文件不依賴重型環(huán)境采集完的數(shù)據(jù)還能直接落成文件帶回本地用Excel分析。這篇文章就完整走一遍在CentOS 7內(nèi)網(wǎng)機器上離線安裝nmon配置后臺定時采集再把nmon數(shù)據(jù)轉(zhuǎn)換成Excel能用的格式最后做成圖表來定位性能瓶頸?；A(chǔ)判斷先說一下這套方案適合誰搞運維的、做系統(tǒng)交付的、還有在做壓測和性能調(diào)優(yōu)的開發(fā)特別是那些服務(wù)器在隔離內(nèi)網(wǎng)、既不能隨便外聯(lián)也沒法用軟件源的場景?？赐赀@篇文章你至少能解決兩件事一是知道怎么在沒有網(wǎng)的環(huán)境里把nmon跑起來二是知道采集到的那些看起來亂糟糟的文本數(shù)據(jù)怎么變成一張直觀的Excel圖表。1. 方案選型與總體思路1.1 為什么偏偏選 nmon 而不是其它監(jiān)控命令Linux下的性能監(jiān)控命令不少top、vmstat、iostat、sar各個都能輸出指標(biāo)但它們在離線、需要長期采集的場景里各有各的別扭。top適合臨時瞄一眼數(shù)據(jù)不落盤想回放歷史趨勢基本靠截圖vmstat和iostat能看實時信息也可以定時輸出但是指標(biāo)維度偏單一CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)要湊齊得同時開好幾個終端還得自己手工對齊時間軸sar相對完整但默認(rèn)依賴sysstat包離線環(huán)境下裝依賴本身就是個麻煩事而且默認(rèn)配置未必覆蓋你要監(jiān)控的維度。nmon不一樣它在設(shè)計上就很貼合“一個工具管到底”的思路。安裝包本身是一個二進(jìn)制文件拷過去就能執(zhí)行交互模式下按幾個快捷鍵就能看到CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)、進(jìn)程等十幾類信息采集模式下可以后臺連續(xù)記錄輸出一個自描述格式的.nmon文件里面把每類指標(biāo)按區(qū)塊組織好后續(xù)拿到辦公機上用表格軟件打開或者交給第三方分析器全鏈路都是通的。我實測下來nmon的采集對系統(tǒng)本身的影響也比較小默認(rèn)2秒一個采樣點只增加極小的CPU開銷在性能問題排查的場景下可以接受。我把常見的監(jiān)控工具做了一個簡單對比方便你判斷自己的場景到底選誰。工具實時查看長期采集指標(biāo)維度離線部署難度數(shù)據(jù)后續(xù)處理top強弱CPU、內(nèi)存、進(jìn)程為主低差vmstat中中CPU、內(nèi)存、IO低中iostat中中磁盤IO低中sar中強覆蓋面廣高依賴sysstat中nmon強強CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)、進(jìn)程等極低強適合Excel如果你的需求是“某一個時間窗口內(nèi)發(fā)生了什么、當(dāng)時各維度資源是啥狀態(tài)”nmon的綜合成本最低。它不僅在采集階段省心在數(shù)據(jù)分析階段也少折騰這一點到后面講Excel處理時體會會更明顯。1.2 離線場景下的完整落地鏈路離線環(huán)境做監(jiān)控最容易卡住的地方不是工具本身而是“怎么把工具弄進(jìn)去”和“怎么把數(shù)據(jù)弄出來”。內(nèi)網(wǎng)服務(wù)器出于安全考慮通常不開放外網(wǎng)訪問也沒有配可用的軟件源鏡像這時候直接執(zhí)行yum install是不現(xiàn)實的你需要先在能聯(lián)網(wǎng)的機器上把安裝包準(zhǔn)備好再通過運維通道傳進(jìn)去。整個方案的鏈路我分成五步第一步在聯(lián)網(wǎng)主機上獲取nmon的二進(jìn)制包同時確認(rèn)它依賴的動態(tài)庫有哪些第二步把二進(jìn)制包傳到離線服務(wù)器的指定目錄賦予可執(zhí)行權(quán)限并做一次干凈運行驗證第三步根據(jù)監(jiān)控需求計算采樣間隔和采樣次數(shù)用nmon的后臺采集模式輸出數(shù)據(jù)文件第四步把.nmon文件傳回本地辦公機做格式轉(zhuǎn)換得到Excel可以直接識別的表格第五步在Excel里繪制趨勢圖結(jié)合業(yè)務(wù)時間點分析瓶頸。這里面每一步都有能踩的坑比如64位系統(tǒng)和32位二進(jìn)制不兼容、缺少動態(tài)庫導(dǎo)致執(zhí)行時報錯、crontab里寫相對路徑導(dǎo)致定時任務(wù)跑不起來、采集文件積攢太多把磁盤寫滿等等。文章主體部分我會把每一個環(huán)節(jié)的做法和替代方案都講透盡量讓你照著操作一遍就能完整跑通。2. 離線安裝包準(zhǔn)備與安裝驗證2.1 在聯(lián)網(wǎng)主機上準(zhǔn)備安裝包nmon的發(fā)布形式有幾種最常見的是直接提供各個平臺編譯好的二進(jìn)制壓縮包里面已經(jīng)包含了多種CPU架構(gòu)和系統(tǒng)版本對應(yīng)的可執(zhí)行文件另一種是打包成rpm適合通過包管理工具安裝。離線環(huán)境下我更推薦直接拿二進(jìn)制因為它不依賴系統(tǒng)的包管理數(shù)據(jù)庫拷過去就能當(dāng)綠色工具用rpm方式反而多一步依賴檢查。在聯(lián)通的臨時主機上最簡單的獲取方式是用yumdownloader把rpm包拉下來。這個命令本身來自yum-utils如果機器上沒有可以先裝上然后執(zhí)行下面這段yum install -y yum-utils mkdir -p /tmp/nmon_pkg yumdownloader nmon --resolve --destdir/tmp/nmon_pkg執(zhí)行完以后/tmp/nmon_pkg目錄下會出現(xiàn)nmon的rpm包以及它依賴的其它包比如ncurses-libs。--resolve這個參數(shù)很關(guān)鍵它會把nmon運行所需的動態(tài)庫依賴一起拉下來省得你在離線服務(wù)器上裝到一半發(fā)現(xiàn)缺庫。如果機器能訪問軟件源里的所有擴(kuò)展倉庫也可以直接把整個依賴樹打包。實際生產(chǎn)環(huán)境中大量服務(wù)器是連軟件源都不通的。這種情況下我的做法是找一臺和離線服務(wù)器操作系統(tǒng)版本相同、且能聯(lián)機的跳板機在跳板機上執(zhí)行上面的命令然后用scp把rpm包推到內(nèi)網(wǎng)服務(wù)器上。操作系統(tǒng)版本盡量一致因為不同版本對glibc和ncurses的版本要求有差異跨大版本容易翻車。如果你拿到的不是rpm包而是一個zip格式的壓縮包解壓以后會看到一堆帶系統(tǒng)后綴的二進(jìn)制文件比如帶_x86_64_centos7后綴的那個就是CentOS 7 64位對應(yīng)的版本。選定的文件單獨抽出來剩下的一概不管。2.2 上傳、安裝與快速驗證先把準(zhǔn)備好的二進(jìn)制文件傳到目標(biāo)服務(wù)器。內(nèi)網(wǎng)環(huán)境常見的通道是堡壘機加跳板或者直接通過運維網(wǎng)絡(luò)傳文件。上傳完成后放到一個約定好的目錄比如/opt/nmon方便統(tǒng)一管理。如果是rpm形式安裝命令很簡單rpm -ivh /tmp/nmon_pkg/nmon*.rpmrpm裝完以后可執(zhí)行文件一般會放到/usr/bin/nmon下面直接用nmon命令就能啟動。如果是綠色二進(jìn)制方式需要手動賦予執(zhí)行權(quán)限chmod x /opt/nmon/nmon_x86_64_centos7 ln -s /opt/nmon/nmon_x86_64_centos7 /usr/bin/nmon做完軟鏈接以后nmon命令在任何目錄下都能直接調(diào)用后面寫crontab也就省心。下一步做驗證直接在終端敲nmon如果屏幕上出現(xiàn)了從上到下的實時數(shù)據(jù)面板說明二進(jìn)制能跑動態(tài)庫也都齊了。提示如果執(zhí)行時提示找不到共享庫文件最常見的原因是ncurses庫缺失或版本不對。CentOS 7離線環(huán)境里可以先嘗試rpm -qa | grep ncurses看看已安裝的版本正常情況下系統(tǒng)自帶的ncurses-libs就能滿足要求只有那種被極度裁剪過的基礎(chǔ)鏡像才需要手動補裝。驗證結(jié)束時按q退出交互界面就能回到命令行。到這里離線安裝環(huán)節(jié)就算收尾了后面要做的所有采集和分析都建立在這個能正常運行的二進(jìn)制之上。3. nmon 數(shù)據(jù)采集實操3.1 交互模式快速查看系統(tǒng)狀態(tài)啟動nmon之后它是一個全屏交互界面底層按鍵控制顯示哪些數(shù)據(jù)。剛進(jìn)去默認(rèn)只顯示基礎(chǔ)信息這時候可以按下面的常用鍵來切換視圖按c顯示CPU的每核心使用率以及整體匯總按m顯示物理內(nèi)存和交換分區(qū)的使用情況按d顯示磁盤組的讀寫速率和繁忙度按n顯示各網(wǎng)卡的收發(fā)包和速率按t顯示系統(tǒng)最耗CPU的進(jìn)程列表按V顯示虛擬內(nèi)存相關(guān)統(tǒng)計。交互模式適合在線排查比如接到報警說某臺機器CPU滿載登上去敲nmon按c和t一秒鐘之內(nèi)就能看到是哪個進(jìn)程在吃CPU非常直接。不過它有一個局限一旦退出nmon數(shù)據(jù)就全沒了沒法回溯之前十分鐘發(fā)生了什么。所以但凡要做周期性觀測或者事后分析就必須切換到后臺采集模式。真正到性能分析的時候我習(xí)慣的流程是先在交互模式下快速看一眼當(dāng)前狀態(tài)然后立刻啟動后臺采集讓它連續(xù)記錄一段時間這樣既有現(xiàn)場快照又有完整曲線兩邊信息互相印證。3.2 后臺采集模式的參數(shù)設(shè)計與原理解讀nmon的后臺采集模式核心就一句話定期把各項指標(biāo)追加寫入文件跑夠指定次數(shù)后自動退出。命令格式如下nmon -f -s 5 -c 720 -m /var/log/nmon這里-f表示后臺寫文件模式輸出文件會自動按主機名和時間戳命名比如xxx_220601_1530.nmon-s 5表示每5秒采集一次-c 720表示總共采集720次-m指定輸出目錄。5秒乘以720次正好是3600秒也就是一小時。如果你想要不同的采集時長記住這個公式采集間隔秒數(shù)乘以采集次數(shù)等于總時長秒數(shù)。參數(shù)選型沒有絕對標(biāo)準(zhǔn)主要看你的分析粒度。如果是排查偶發(fā)性問題間隔定為10秒或30秒就夠了太密的采樣點除了讓文件變大、分析時圖表擁擠并沒有額外價值如果是壓測現(xiàn)場需要看秒級抖動那就用2到5秒的間隔。內(nèi)存和磁盤這類指標(biāo)變化相對平滑不需要過密采樣而CPU占比突發(fā)性很強想抓住瞬態(tài)峰值就最好用5秒以內(nèi)的間隔。實際使用中nmon采集進(jìn)程會常駐在前臺即使-f也不能真正后臺化。如果你希望它完全脫離終端運行可以在命令前加nohup讓它轉(zhuǎn)向后臺執(zhí)行?，F(xiàn)在的系統(tǒng)服務(wù)里很多人會把它做成systemd服務(wù)來托管但離線二進(jìn)制配合nohup已經(jīng)足夠應(yīng)付大多數(shù)臨時采集需求不需要把復(fù)雜度提得太高。采集文件的大小也和采樣頻率成正比。按5秒間隔采集一天文件大概在幾十MB上下按1秒間隔會大得多。對長期監(jiān)控來說我的建議是先算一下磁盤余量再把輸出目錄掛到有獨立空間的分區(qū)避免把根目錄撐爆。3.3 定時采集與文件管理策略很多場景下監(jiān)控不是一次性任務(wù)而是一天24小時、連續(xù)一周甚至更久的例行工作。比如你想觀察業(yè)務(wù)高峰期的資源變化提前預(yù)判擴(kuò)容時機就需要每天固定時段采集。這時候crontab是比手工執(zhí)行更靠譜的選擇。在crontab里加一行比如每天早8點開始采集8小時每10秒一個采樣點0 8 * * * /usr/bin/nmon -f -s 10 -c 2880 -m /var/log/nmon /dev/null 2110秒乘以2880次就是28800秒正好8小時。注意crontab里的執(zhí)行命令最好寫絕對路徑包括nmon路徑和輸出目錄路徑否則容易出現(xiàn)任務(wù)執(zhí)行了但文件不知道寫到哪去的情況這類問題一會兒到常見問題部分細(xì)說。長期跑下來/var/log/nmon目錄會積累大量文件。我建議寫一個簡單的清理腳本配合crontab執(zhí)行比如只保留最近30天的.nmon文件。腳本不復(fù)雜核心就是把超過保留天數(shù)的文件刪掉find /var/log/nmon -name *.nmon -mtime 30 -delete運維實踐里還有一個很多人忽略的點監(jiān)控文件本身也要有統(tǒng)一的命名和歸檔習(xí)慣。nmon默認(rèn)按主機名和時間命名如果你的服務(wù)器命名混亂建議在采集腳本里對生成文件做一次重命名加上環(huán)境和業(yè)務(wù)標(biāo)簽比如帶上應(yīng)用名縮寫和內(nèi)網(wǎng)IP的最后一段這樣后續(xù)從幾十臺機器收集來的數(shù)據(jù)放到一起時一眼就能分辨出是哪臺機器哪天的采集結(jié)果。4. nmon 數(shù)據(jù)解析與 Excel 化處理4.1 nmon 文件格式到底長什么樣拿到.nmon文件以后直接用文本編輯器打開你會發(fā)現(xiàn)它不是二進(jìn)制亂碼而是結(jié)構(gòu)化的文本里面每一行以AAA開頭后面跟著指標(biāo)區(qū)塊名和數(shù)據(jù)。這種設(shè)計的精妙之處在于它把不同類型的數(shù)據(jù)用區(qū)塊隔離開解析的時候只要按區(qū)塊名取值就行后續(xù)無論是寫腳本轉(zhuǎn)換還是交給現(xiàn)成工具成本都很低。舉個最典型的結(jié)構(gòu)AAA,procx,Linux,221201,1530,09,3.10.0-957.el7.x86_64 AAA,CPU001,12,6,80,2 AAA,CPU_ALL,5,3,90,2 AAA,MEM,MemoryMB,2048000,2048000,0,0,0,0,1274374,... AAA,NET,eth0,0,0,0,0,0,0,0,0,... AAA,DISKBUSY,sda,12.5第一行是元數(shù)據(jù)包含主機名、系統(tǒng)版本、采集起始時間和內(nèi)核版本CPU_ALL后面的數(shù)字分別是用戶態(tài)占比、系統(tǒng)態(tài)占比、空閑占比等MEM后面是各種內(nèi)存總量、可用量NET后面跟著收發(fā)包字節(jié)數(shù)DISKBUSY那類行則是磁盤繁忙度。字段順序在不同版本的nmon里會有細(xì)微差異所以做轉(zhuǎn)換腳本的時候不能硬編碼列序號我后面給出的腳本會更穩(wěn)健地按區(qū)塊處理。用Excel直接打開這個文件不是不行但體驗很差因為文本里大量元信息行、不同指標(biāo)的列寬不齊而且時間戳格式對Excel不友好做圖表時軸上的時間點會對不齊。所以中間必須經(jīng)過一個轉(zhuǎn)換環(huán)節(jié)。4.2 用腳本把 nmon 轉(zhuǎn)成規(guī)整的 CSV轉(zhuǎn)換的思路并不復(fù)雜讀原始文件按行區(qū)分區(qū)塊把每個區(qū)塊內(nèi)相同指標(biāo)的行攢起來最后輸出成若干列。為了實用性重點提取CPU_ALL、MEM、DISKBUSY、NET這幾個最常見區(qū)塊就夠了其它細(xì)節(jié)指標(biāo)可以按需擴(kuò)展。下面這個腳本是我在實際項目中用過的簡化版用Python3編寫核心邏輯做了幾處穩(wěn)健性處理比如不管區(qū)塊行首是否有空格都先strip把各種字段保留為文本防止Excel把前導(dǎo)零吞掉。import csv import sys def parse_nmon(path): # 收集各區(qū)塊的全部行 blocks {} with open(path, r, encodingutf-8, errorsignore) as f: for line in f: line line.strip() if line.startswith(AAA): parts line.split(,) tag parts[1] blocks.setdefault(tag, []).append(parts) return blocks def convert(input_path, output_path): blocks parse_nmon(input_path) # 只處理關(guān)心的幾個核心區(qū)塊 wanted (CPU_ALL, MEM, DISKBUSY, NET) selected {tag: blocks[tag] for tag in wanted if tag in blocks} times [] col_data {} for tag, rows in selected.items(): for parts in rows: if len(parts) 5: continue ts parts[2] times.append(ts) col_data.setdefault(tag, []).append(parts[3:]) # 按時間點對齊輸出 with open(output_path, w, newline) as f: w csv.writer(f) header [time] for tag in selected: sample_len len(col_data[tag][0]) if col_data[tag] else 0 header.extend([{}_{}.format(tag, idx) for idx in range(sample_len)]) w.writerow(header) row_count len(times) for i in range(row_count): row [times[i]] for tag in selected: if i len(col_data[tag]): row.extend(col_data[tag][i]) w.writerow(row) if __name__ __main__: source sys.argv[1] target source.replace(.nmon, .csv) convert(source, target)運行方式也很簡單python3 nmon2csv.py server_221201_1530.nmon運行完以后Excel打開這個CSV就能看到規(guī)整的表第一列是時間后面每一列對應(yīng)一個采集指標(biāo)。如果覺得指標(biāo)列還是太雜可以在腳本里把需要的列單獨挑出來只留CPU用戶態(tài)、系統(tǒng)態(tài)、空閑率、內(nèi)存總量、可用量、磁盤總線忙綠比這些核心指標(biāo)。注意如果.nmon文件是從Windows環(huán)境傳輸過來的文本行尾可能帶了\r回車符打開前最好用dos2unix轉(zhuǎn)換成LF否則CSV的表格會被弄出多余空行。站點上還有一些現(xiàn)成的第三方Excel分析宏原理上就是替你做了解析和制圖導(dǎo)出的圖表更豐富。但我個人體驗是自己手握一個轉(zhuǎn)換腳本更靈活起碼可以按自己的口徑去定義指標(biāo)也不會被宏的安全設(shè)置卡住。5. Excel 圖表制作與性能瓶頸分析5.1 核心指標(biāo)怎么選才不會看花眼一個.nmon文件轉(zhuǎn)換出來指標(biāo)列可能有幾十列如果全部丟進(jìn)Excel做折線圖結(jié)果就是一坨毛線什么也解讀不出來。實際分析時我的習(xí)慣是先明確問題域再挑重點維度通常從四個方向入手。CPU維度只看兩個指標(biāo)CPU_ALL里的用戶態(tài)占比和系統(tǒng)態(tài)占比。用戶態(tài)高說明應(yīng)用或者計算任務(wù)吃CPU系統(tǒng)態(tài)高往往意味著系統(tǒng)調(diào)用頻繁、鎖競爭或者內(nèi)核態(tài)模塊在消耗資源兩類原因?qū)?yīng)的排查方向完全不同。內(nèi)存維度優(yōu)先看可用內(nèi)存的絕對值以及swap的讀寫量這兩個指標(biāo)能反映內(nèi)存是否真的吃緊。磁盤維度看DISKBUSY的百分比配合CPU的等待占比能夠區(qū)分磁盤I/O瓶頸和純CPU計算瓶頸。網(wǎng)絡(luò)維度看收發(fā)包速率和錯誤包數(shù)量判斷是否存在流量異常。選指標(biāo)時還有一個容易被忽略的地方字段單位。內(nèi)存的原始值在nmon里是MB網(wǎng)絡(luò)速率可能是KB/s如果混在一張圖里數(shù)量級差著上千倍小塊數(shù)據(jù)會被大塊數(shù)據(jù)直接壓成一條直線。遇到這種情況要么分開成兩張圖要么用Excel的次坐標(biāo)軸讓兩條曲線各用各的刻度。5.2 Excel 折線圖制作與坐標(biāo)軸對齊技巧轉(zhuǎn)換出來的CSV文件用Excel打開后做圖表的步驟并不復(fù)雜。先選中時間列和你想看的指標(biāo)列插入折線圖然后調(diào)整X軸格式。這里有一個實戰(zhàn)小技巧如果時間列是1530這種HHMMSS文本格式不要直接當(dāng)坐標(biāo)軸用先把它轉(zhuǎn)成常規(guī)時間格式否則圖表橫軸要么出現(xiàn)1800這種超大的數(shù)要么被錯誤當(dāng)作文本排序。最簡單的處理方式是在CSV轉(zhuǎn)換腳本里就把時間格式化成Excel認(rèn)識的HH:MM:SS字符串再在Excel里把該列設(shè)置為時間格式。插入圖表時橫軸選擇該列生成的折線就會按采集時間均勻鋪開。如果中間有斷點檢查原始.nmon文件里是不是某一次采集沒寫進(jìn)去這種斷點往往對應(yīng)操作系統(tǒng)負(fù)載過高導(dǎo)致nmon進(jìn)程短暫卡死。多指標(biāo)對比時建議先做一張“總覽圖”把CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)的關(guān)鍵指標(biāo)都放上去用次坐標(biāo)軸區(qū)分量級發(fā)現(xiàn)哪個維度有異常趨勢再單獨抽出來做局部放大。分析長期數(shù)據(jù)的時候可以用數(shù)據(jù)透視表把小時數(shù)據(jù)聚合觀察是否存在每天固定時間重復(fù)出現(xiàn)的高峰這比盯著原始秒級數(shù)據(jù)看更抓重點。5.3 從一個異常曲線反推瓶頸的分析方法有一次我處理過一個典型場景某個業(yè)務(wù)系統(tǒng)每天下午兩點左右響應(yīng)變慢應(yīng)用日志里沒有明顯報錯但用戶端感覺明顯延遲。運維同事在服務(wù)器上臨時起了nmon采集頻率30秒一次連續(xù)跑了三天。把Excel圖表拉出來以后每天下午兩點這條時間軸附近CPU的用戶態(tài)占比并不高但等待占比從5%一下跳到40%以上對應(yīng)的磁盤繁忙度也同步?jīng)_高到90%左右。這個匹配關(guān)系說明瓶頸不在CPU計算而在磁盤I/O。再往下深挖發(fā)現(xiàn)那個時間點正好是定時數(shù)據(jù)備份任務(wù)啟動的窗口備份任務(wù)對大目錄做全量掃描并寫盤把I/O帶寬基本吃滿。后來把備份任務(wù)挪到業(yè)務(wù)低峰期響應(yīng)時間的報警就消失了。這個過程里Excel圖表的作用就是把三個獨立的指標(biāo)按照同一時間軸擺在一起讓相關(guān)性一目了然。如果只看實時top或者分段日志很難把磁盤繁忙和系統(tǒng)卡頓這兩件事關(guān)聯(lián)起來。所以做分析的時候不要只畫一張孤立的指標(biāo)曲線而是盡量把CPU等待、磁盤IO、網(wǎng)絡(luò)速率放在同一個時間窗口里對照這樣才更容易找出真正的因果鏈。6. 常見問題與避坑指南6.1 現(xiàn)場高頻問題速查表離線環(huán)境安裝和后續(xù)采集踩坑的密集程度遠(yuǎn)比想象中高。下面這張表匯總了我見過的大多數(shù)問題每一行都對應(yīng)一個真實發(fā)生過的場景。現(xiàn)象常見原因解決辦法執(zhí)行nmon提示Permission denied二進(jìn)制文件沒有可執(zhí)行權(quán)限chmod x 對應(yīng)二進(jìn)制提示error while loading shared libraries: libncurses.so.5ncurses動態(tài)庫缺失或版本不匹配檢查ncurses-libs是否已安裝rpm -q ncurses-libs界面能打開但數(shù)字不刷新終端類型不對部分SSH客戶端對全屏刷新支持差換用標(biāo)準(zhǔn)終端或xterm重新連接后啟動nmon找不到輸出文件crontab看起來沒執(zhí)行cron環(huán)境變量PATH里沒有nmon路徑crontab中寫完整路徑 /usr/bin/nmon采集文件內(nèi)容正常但Excel打開亂序文本行尾回車符來自Windows批量傳輸用dos2unix處理后再轉(zhuǎn)換或改傳輸模式為binarynmon運行報date相關(guān)的錯誤服務(wù)器系統(tǒng)時間異?；驎r間同步服務(wù)未工作先校準(zhǔn)系統(tǒng)時間再重啟nmon采集采集文件越積越大磁盤空間告急沒有配置清理策略用find按mtime定期清理并評估采集頻率兩個不同平臺的二進(jìn)制傳錯下載包里面對應(yīng)的是另一個架構(gòu)的版本確認(rèn)uname -m結(jié)果選擇匹配的二進(jìn)制這張表里最容易被忽略的是crontab路徑問題。crontab啟動時加載的PATH很精簡并不包含/opt/nmon這類自定義目錄。之前有人把nmon放在/opt/nmon下crontab里只寫了nmon -f -s 30 -c 120任務(wù)確實在跑但系統(tǒng)找不到命令文件一個都沒有生成。改成寫全絕對路徑以后問題立刻解決。6.2 長期監(jiān)控的幾條實操心得在做長期nmon監(jiān)控的時候我總結(jié)了幾條經(jīng)驗未必在官方文檔里看得到但實際幫過我不少忙。第一條正式部署前先做短周期小批量驗證。不管你計劃用30秒還是5秒的采樣間隔先跑個兩分鐘的測試采集確認(rèn)文件能正常生成再用Excel打開確認(rèn)格式對最后才掛到crontab里長期跑。每次調(diào)整參數(shù)都這樣來一遍能省掉大量來回排查的時間。第二條命名規(guī)范要提前定好。nmon默認(rèn)的文件名帶主機名但如果你的服務(wù)器命名沒有業(yè)務(wù)含義數(shù)據(jù)混在一起根本分不清。我的做法是把采集腳本里加上環(huán)境名前綴比如在腳本里執(zhí)行一次重命名把文件統(tǒng)一整理為app_web01_20220601.nmon這種格式這樣后續(xù)歸檔和檢索都高效。第三條采集目錄要和系統(tǒng)根目錄分離。長期監(jiān)控必然產(chǎn)生文件如果/var/log所在分區(qū)本來就緊張監(jiān)控數(shù)據(jù)會在不知不覺中把磁盤吃出一塊隱患。把采集目錄掛到獨立分區(qū)或者至少給/var/log單獨留足空間這是成本極低但收益明顯的一條。第四條數(shù)據(jù)傳回本地時盡量壓縮傳輸。一個高頻率采集的nmon文件可能幾十MB如果每天都要從幾十臺服務(wù)器拉回來帶寬開銷不小。先gzip或使用壓縮工具壓一遍再傳能減少大半體積本地解壓后再分析流程完全不受影響。最后再說點實在的按上面這套流程走下來從離線安裝到Excel圖表分析工具鏈其實非常輕一個可執(zhí)行文件、一個轉(zhuǎn)換腳本、一個Excel模板就構(gòu)成了一條完整的性能排查流水線。我個人在使用中的一個體會是nmon的價值不止在于“能看到實時狀態(tài)”更在于“采集成本足夠低、數(shù)據(jù)形態(tài)足夠開放”讓后續(xù)分析有充分的自由度。你完全可以先把這套流程跑通再根據(jù)自己服務(wù)器的實際情況去定義指標(biāo)口徑和制圖模板時間長了甚至可以沉淀出一套適合自己團(tuán)隊的性能分析套路。真到了線上出故障、需要快速翻歷史曲線的時候你會發(fā)現(xiàn)提前布置nmon絕對是一件高性價比的事。