接手麒麟V10服务器运维已经有一段时间了日常做得最多的事情就是给业务排障、做容量评估、配合压测。每次遇到性能问题我习惯先抓一份资源监控数据再决定下一步往哪儿查。top、vmstat这类命令能实时看但数据不落盘事后复盘基本靠脑补sar需要提前装好sysstat还得保证采集服务一直跑在后台为一个节点去部署全套监控平台又显得有点重。nmon是我用了很多年的老牌工具单文件、低开销、零配置交互模式可以一屏同时看CPU、内存、磁盘、网络后台模式能按秒级间隔把指标写成文本文件之后丢进配套的分析表或者自己写脚本就能出报告。这篇文章就把我在麒麟V10服务器上安装nmon的完整过程写出来包括环境确认、安装选型、常用参数、定时采集配置以及实际遇到过的几个坑和完整的排查思路给同样在维护国产Linux服务器的朋友做个参考。1. 为什么监控麒麟V10服务器我首选nmonnmon最早来自一个大厂内部性能团队的开源作品后来在Linux社区里一直维护到今天。它的最大特点就是整个工具就是一个可执行文件不需要安装服务、不需要开守护进程、更不需要往内核里挂模块靠读取/proc下的系统文件拿数据。正因为这个设计它在兼容性上的麻烦比很多监控工具少得多换内核版本、换系统小版本基本不受影响。麒麟V10服务器版在关键业务环境里用得很多生产网段往往不能随便访问外网软件源也不能随便往机器上装一堆依赖包。这种环境下一个能通过内网拷贝传输、拷过去就能跑的二进制工具绝对是最稳妥的选择。它体积小不像那些动不动几十MB、还要带一堆动态库的监控工具拷贝和部署都很轻。而且nmon对机器本身的性能影响非常小采样时只读取/proc下的数据理论上对业务几乎无感这在生产节点上尤其重要。我跟其他常用工具做过一轮对比使用场景区别还是挺明显的工具实时查看数据落盘安装成本单屏信息量后续分析top支持不支持系统自带进程为主需手动截屏或另存vmstat支持不支持系统自带整机摘要需写脚本sar/sysstat支持支持需装服务并常驻分项指标文本可处理dstat支持部分需安装多栏滚动需脚本nmon支持支持极低CPU/内存/磁盘/网络/进程同屏有配套Excel分析器也可脚本解析从表里能看出来nmon的特长是“一屏看全部”和“既能看又能存”。一般来说我判断一台节点该不该用nmon就看这三点只是想做短时间取证不需要长期告警。希望不用装任何服务拿到就能跑。后续需要把监控数据导出成图表给别人看。反过来要说清楚如果你需要的是整个集群的持久化监控、阈值告警、多节点汇总那nmon帮不上忙。它没有告警机制也不是分布式设计。它的定位更偏“临时取证”和“短周期基线采集”恰好这个定位在单机排障场景里非常实用。2. 安装前的环境确认版本分支与CPU架构不能马虎麒麟V10这个系列其实不止一个分支安装包选型跟发行版分支强相关。桌面版继承Ubuntu那套生态包管理是apt服务器版普遍走rpm/dnf体系兼容CentOS生态。nmon的二进制又跟CPU架构强绑定同一个压缩包里往往放着x86_64、aarch64和PowerPC等多个版本。装之前如果没确认清楚最容易出现两种尴尬情况把apt和rpm混用导致装了个不适配的版本或者拿了ARM版二进制跑到x86机器上去执行。确认环境我一般按这几条命令来cat /etc/kylin-release cat /etc/os-release uname -m getconf LONG_BIT第一眼先看/etc/kylin-release它会直接显示是桌面版还是服务器版以及SP几的版本号。接着看/etc/os-release确认系统ID。uname -m判断CPU架构x86_64就是Intel/AMD的64位平台aarch64就是ARM平台这在后面选nmon包时是决定性的。服务器版还可以再确认一下/etc/redhat-release因为nmon预编译包经常按照兼容的RHEL/CentOS大版本命名比如rhel7、rhel8知道兼容目标能帮你更快挑对文件。不同分支和架构带来两个直接影响包管理器不同桌面版用apt服务器版用dnf/yum/rpm。nmon二进制需要选择对应的CPU架构变体。另外nmon的交互界面依赖ncurses字符界面库。安装之前顺手查一下系统里有没有ldconfig -p | grep ncurses如果输出里没有任何libncurses信息说明这台机器是最小化安装连基础字符界面库都没装。这种情况后面跑nmon交互模式会直接报错需要先用包管理器把库补上。服务器版执行sudo dnf install ncurses-libs -y桌面版执行sudo apt-get install libncurses-dev -y。还有一点容易被忽略如果打算走源码编译路线建议同时确认机器上有没有gcc、make和ncurses开发头文件没有的话提前装好免得编译到一半才发现缺工具链。提示purge过组件的精简系统很容易缺ncurses不要因为这台机器上能跑top就推断它一定有ncursestop的依赖面跟nmon并不完全相同最严谨的方式还是ldconfig去查实。3. 三种安装路径详解与我的推荐麒麟V10的默认软件源里很多时候没有nmon所以安装方法不能只指望一条路。我把实际可行的方式归纳成三条独立二进制、包管理器、源码编译。下面逐个说清楚最后给一个选型建议。3.1 独立二进制生产环境最稳妥的路线这条路线最适合生产网段。官方发布的nmon包是个压缩包里面放了多个操作系统版本对应的二进制文件挑一个跟当前机器匹配的拷出来就能用。一般步骤是这样# 1. 下载并解压替换为实际拿到的包名 wget nmon包下载地址 tar -xf nmon.tar.gz ls -l # 2. 选择与操作系统匹配的二进制并安装 # 服务器版如果兼容CentOS 7/RHEL 7优先选带rhel7/centos7标识的二进制 # 如果是aarch64ARM架构服务器选带aarch64标识的二进制 cp nmon_x86_64_centos7 /usr/local/bin/nmon chmod 755 /usr/local/bin/nmon # 3. 验证安装结果 nmon -V ldd /usr/local/bin/nmon下载后我习惯先校验一下文件的SHA256生产环境里尤其不要从不明渠道拿二进制这一点做得再怎么小心都不为过。nmon -V能打印版本号确认文件可以执行。ldd看动态库依赖正常情况下只依赖libc和libncurses两样如果出现not found按前面说的补库就行。这条路线的好处是真的快从拿到包到跑起来前后不到两分钟。坏处是升级和版本维护需要自己做下载什么版本、校验什么值、放到哪台机器都要你心里有数。3.2 包管理器适合网络环境宽松的机器桌面版基于Ubuntu生态软件源里大概率有nmon直接用apt安装就行sudo apt-get install nmon -y服务器版如果你们的内部软件源已经同步了nmon的rpm包也可以用dnf安装sudo dnf install nmon -y包管理器最大的优势是自动处理依赖升级时一条命令完成。但它的问题同样明显很多麒麟默认源里根本没有nmon这个包有的话版本也往往偏旧新版本里新增的指标解析能力就用不上。所以我的建议是先跑一条apt-cache search nmon或者dnf list nmon看看源里到底有没有有就优先用包管理器没有就直接切到二进制路线不要在这个环节上死磕。3.3 源码编译留给架构特殊的环境源码编译需要完整工具链包括gcc、make和ncurses开发头文件整套装下来所花的时间比收益大。除非机器架构太特殊、官方预编译包里确实没有对应版本否则我不太推荐走这条路。如果确实要编译大致流程是# 安装编译工具链根据包管理器选择 sudo dnf install gcc make ncurses-devel -y # 桌面版对应sudo apt-get install build-essential libncurses-dev -y # 解压源码包并编译 tar -xf nmon-src.tar.gz cd nmon-src make # 把编译产物放到系统路径 sudo cp nmon /usr/local/bin/不同版本的源码对64位内存支持可能有额外编译参数具体看包里的README。编译这条路灵活性最高但也最费时间并且编译产物同样要自己做安全校验我只在特殊架构机器上才考虑它。三种方式放一起看更直观安装方式适用环境优点缺点复杂度独立二进制生产/内网最快最稳、可控手动更新、需校验低包管理器可访问软件源依赖自动、升级方便源里常没有或版本旧低源码编译特殊架构/学习可定制编译依赖工具链中高我自己最常用的就是独立二进制配合一个固定的本地软件包目录管理。普通x86_64服务器版加ARM版用二进制最快能访问官方源的桌面版用apt装也很省心。绝大多数场景不需要走到编译那一步。4. 交互模式当天就能用起来的实时监控4.1 常用按键与界面解读安装完直接输入nmon回车就进入交互界面。界面默认2秒刷新一次按或-键可以调整刷新间隔。下面这些按键是我用得最频繁的cCPU状态m内存d磁盘繁忙度k磁盘读写速率n网络j文件系统tTop进程r资源汇总内核版本、运行时间、平均负载V虚拟内存h帮助q退出CPU那几行会把User、Sys、Wait、Idle都列出来而且每个物理核单独一行大机器一眼就能看出是不是某个核被吃满了。Wait%这个值特别关键它表示CPU等待磁盘IO的时间占比。如果Wait%一直居高不下大概率是磁盘先扛不住了而不是CPU算力不够。看内存的时候不要一看到free低就急着加内存Linux下的cache是可以回收的要结合cache大小和swap变化一起判断。网络面板显示的是每秒收发字节数、丢包和错误计数排查网络拥塞的时候很直观。4.2 一次典型的CPU排障过程说个具体场景。某个业务节点反馈响应慢我先在交互界面按c看到System%偏高、Wait%也不低而且多核利用率很不均匀再按t看进程发现某几个Java线程把CPU占满。这个判断流程从打开nmon到初步定位一两分钟足够了比逐个敲top再对着vmstat猜要直观得多。我还有一个习惯看到CPU和内存数据后会把d和k同时打开对照磁盘繁忙度和磁盘读写速率。有时候CPU高其实是因为进程在反复重试磁盘IO单纯看CPU列很容易误判成算力不足。交互模式下多按几个键多视角对照比单看某一个面板更不容易带偏排查方向。拿不准按键就按h看帮助页帮助信息写得很清楚每个字母对应什么功能一目了然。5. 落盘采集与定时任务把监控数据留档5.1 nmon抓取参数详解交互模式适合人在现场盯但更多时候面对的情况是问题已经发生过要求的是事后翻历史数据。这时候就要用记录模式。nmon最基本的落盘采集命令是这样nmon -f -s 5 -c 720 -m /data/nmon -t参数含义分开说-f后台采集并写入文件文件名自动生成。-s采样间隔单位秒上面的例子是每5秒采一条。-c采样次数上面的例子是720次。-m指定输出目录这里输出到/data/nmon。-t把Top进程一并记录排障时通常建议开启。采样间隔乘采样次数就是总时长。-s 5 -c 720正好1小时-s 30 -c 2880正好24小时。第一次用的人最容易犯的错是只记得-s和-c忘了-m结果文件默认写到当前目录。如果当前工作目录恰好是/tmp这种临时目录重启一次数据就清零了。文件名的规则是“主机名_年月日_时分.nmon”这个命名跟后面要用的nmon分析器直接相关不建议自己乱改后缀。还要注意它默认产出不是CSV是nmon特有的文本格式用普通Excel直接打开看到的是一行行的纯文本需要借助分析工具读。提示如果采集时长超过一天建议拆分成多个文件保存并且做完采集就压缩归档。nmon自己不会删旧文件长时间放任不管会把磁盘塞满。5.2 用crontab做周期性采集很多节点我会让它在业务高峰时段自动采样。比如周一至周五的9点到18点每30秒采一条采720次正好6小时输出到数据盘并记录Top进程crontab可以这样写0 9 * * 1-5 /usr/local/bin/nmon -f -s 30 -c 720 -m /data/nmon -t /dev/null 21数据目录建议独立放在数据盘上不要放根分区避免监控文件把系统盘占满而引发业务故障。再配一条清理策略只保留30天内的文件find /data/nmon -name *.nmon -mtime 30 -delete启动采集和清理旧文件这两件事我建议拆成两个独立脚本分别调度比把所有逻辑塞进一条复合命令好维护。脚本里也尽量写绝对路径crontab环境里PATH常常和交互终端不一样直接用相对路径或裸命令名很容易翻车。5.3 采集文件的分析方法nmon配套的Excel分析器是多年来的事实标准。把.nmon文件导进去宏会自动生成CPU、内存、磁盘、网络几十张图表对不会写脚本的同事特别友好。操作上唯一要注意的是必须先在Excel里启用宏否则工具根本没法运行。不想依赖Excel的话也可以用命令行直接抽数据。nmon文件每一行是一个指标域CPU那组行以“CPU”开头按逗号拆分后就能拿到User%、Sys%、Wait%、Idle%等字段。先看一下文件里CPU行的格式grep ^CPU, /data/nmon/主机名_时间.nmon | head -n 5确认格式后就可以用awk或cut提取某一列做趋势图。抽出来的数据如果想做更复杂的二次处理可以交给pandas读取归一化或者导进可视化工具做仪表盘展示。我的经验是短时间、单节点的定位问题用Excel分析器就够了长时间跨度的数据对比才需要走脚本。6. 安装使用中踩过的坑和完整排错链路下面三个问题是我在实际安装使用中真实遇到过的按当时排查的链路写出来比直接给结论更有参考价值。6.1 libncurses缺失导致无法启动现象第一次在麒麟V10服务器版上执行nmon屏幕直接弹出error while loading shared libraries: libncurses.so.5: cannot open shared object file。那台机器是最小化安装连vim都没装字符界面基础库自然也没有。排查链路先用ldd /usr/local/bin/nmon看动态库依赖输出里libncurses.so.5显示not found再用ldconfig -p | grep ncurses发现系统里连libncurses.so.6都没有。这说明问题不是版本对不上而是机器上压根没有装ncurses基础库。解决因为那台服务器走rpm体系直接执行sudo dnf install ncurses-libs -y装完再跑一次ldd依赖全部打勾nmon就能正常起来了。如果是桌面版对应命令是sudo apt-get install libncurses5 -y。还有个取巧办法是手头有同架构机器的libncurses.so.5就拷过来放到/lib64但这样做后续排查麻烦能用包管理器装就别手工拷贝。6.2 Exec format error与架构不匹配现象有一次从内部软件仓库拿到一个nmon包拷到机器上执行系统提示cannot execute binary file: Exec format error。这不是文件损坏而是二进制文件和当前CPU架构对不上。排查链路先uname -m确认当前机器是x86_64再用file命令查看那个nmon二进制输出显示ELF 64-bit LSB executable, ARM aarch64。思路一下子就清楚了拿错成了ARM版本。解决回到原始包列表里把x86_64对应的二进制选出来重新拷贝、赋权、ldd验证然后就能跑。这个坑在ARM架构服务器上尤其容易踩同一个发行版衍生出的x86和ARM包文件名里往往只差一个架构字段误下载的概率不低。我现在的习惯是下载之前先确认目标机器的CPU架构不等执行报错了才回头查。6.3 采集文件路径与磁盘空间的意外现象有次启动记录模式时图省事没加-m参数文件默认写到当期工作目录。后来服务器重启临时目录被清空一整天的采集数据全没了。另一次采集间隔设得太密采用-s 1 -c 86400一天下来生成的文件几百MB差点把根分区写满。排查链路文件丢失先看nmon运行时的当前工作目录和输出目录确认-m参数是否生效。文件过大就先统计目录里.nmon文件的大小分布再回去核对crontab里的采样参数。这两个问题表面不同根因却一样对输出路径和文件增长没有预估。解决我强制自己所有采集命令都带-m参数指定到数据盘上的专门目录超过24小时的采集拆成多个文件采集任务结束马上用gzip压缩。凡是用crontab跑的输出重定向到日志文件清理脚本也一并挂上就算采样参数写错了也不会拖垮磁盘。7. 用了一段时间后的几点体会nmon的定位说到底就是临时取证工具不是长期监控平台。真要做7x24集群监控、多维度告警还是得靠完整监控系统那套体系但nmon可以作为很好的补充手段在业务出问题的半天窗口内做细粒度数据抓取。监控数据千万别轻易删。每次扩容前采一份扩容后再采一份两份对比就能看出容量变化是否达到预期。养成这个习惯之后容量评估会变得很省力因为手里有历史基线不用每次都靠拍脑袋估算。我建议维护一个自己的nmon安装包目录按架构和系统分支分好类文件名上带清楚架构标识和来源版本号。这样不管换到哪台麒麟V10机器都能很快找到对应包的路径不用每次现去翻下载页面。最后再提一句nmon本身不写配置文件输出目录、自动清理这些行为都要自己在脚本层面包装好别指望工具本身来兜底。把安装、采集、清理这三层都想清楚nmon用起来会顺手得多。