有一次凌晨两点多线上订单服务的告警把我从床上拽了起来。监控大盘显示CPU使用率从30%一路冲上90%但top里看到的进程CPU占用并不高free显示内存还有几个G的余量vmstat也看不出明显异常。当时我手里能用的工具全是这种“你看得见指标、但拼不出真相”的类型。折腾了快一个小时还是同事甩了个nmon进来按了几个键屏幕上立刻把CPU、内存、磁盘、网络分区块铺开那个体量的信息密度和直观程度让我当场就意识到自己在这个方向上落后了。事后我把nmon装到了所有测试和线上服务器上越用越觉得它值一个“酷监控”的评价。网上关于nmon的教程不少但大多只给了一堆参数没有解释每块信息该怎么看、什么场景下用什么模式、为什么有些坑会踩。这篇就把我从安装、交互界面、数据采集到生成图表的完整使用链路捋一遍尤其会把那些“快捷键背后到底在说什么”讲清楚适合刚接触性能排查的运维和开发也适合已经用过nmon但只停留在按c、按m的同行。1. 为什么我在一众监控工具里留下了nmon先交代一个背景我日常接触的机器有物理机也有容器监控体系里既有Prometheus加Grafana那套集中式监控也有各种商业APM的Agent。按理说工具链已经够齐全了为什么还要在排查问题时专门依赖nmon答案其实就三个字轻、快、全。1.1 轻量到可以“随用随走”nmon是一个单文件程序安装完不过几百KB没有守护进程不监听端口不写数据库不依赖Python或Java运行时。它在机器上运行的时候只负责采样和显示退出之后基本不留痕迹。这一点对生产环境特别友好。很多商业监控Agent会传染式地吃掉几百MB内存还时不时上报数据把内网带宽占满而nmon在交互模式下自身的CPU占用通常可以忽略即使开着数据采集额外消耗也比业务波动小好几个数量级。在出故障的机器上你需要的不是一个加重负担的“监控全家桶”而是一个打开就能用的放大镜。1.2 实时信息密度比top高一个维度top和htop的优势是进程列表直观但如果你要在一台机器上同时对比CPU、内存、磁盘块设备、网络网卡、文件系统、NFS、内核表项的状态top要把多个命令来回切换着看htop虽然能显示负载和进程但磁盘和网络的维度依然很弱。nmon的做法是单屏分区块展示按下对应按键某类指标的明细区域就会铺开。比如按c能看到全局CPU、每核CPU、用户态/内核态/等待IO/空闲比例、CPU频率变化按n能看到每块网卡的实时IO速率、包速率、带宽占用百分比按d能看到每个块设备的繁忙程度和读写吞吐。这些数据如果不是nmon你得同时开着top、iostat、ifstat、free好几套命令才能拼齐而且它们各自的采样节拍还不一致看到的时间点对不上容易误判。1.3 两种模式分别对应两类典型场景nmon最实用的地方是它有明确的两种运行形态交互模式和采集模式。交互模式是在终端里实时刷新适合登录到机器上手撕问题采集模式是把采样数据写入文件适合压测观察、无人值守巡检或者事后复现那种“故障已经过去但你想搞清楚当时发生了什么”的场景。这两种模式对应了两条完全不同的使用路径。很多人只把nmon当成一个“彩色版top”用浪费了后半程的价值。后面我会分开讲。2. nmon安装与启动第一条命令该怎么敲安装本身没什么难度但不同发行版的细节略有差异我把常用命令一并列出来。2.1 不同系统下的安装方式Debian/Ubuntu系列apt update apt install -y nmonRHEL/CentOS 7及以下yum install -y nmonRHEL/CentOS 8及以上、Rocky/AlmaLinuxdnf install -y nmonopenSUSE/SLESzypper install -y nmon如果你用的是精简容器或者离线内网环境也可以从源码编译nmon本身依赖ncurses库编译前需要确保有ncurses-devel。装完直接在终端输入nmon就能进入交互界面一般不需要额外配置环境变量。2.2 交互模式的基本操作与退出在终端敲下nmon回车后屏幕会进入全屏刷新模式。底部会有一行快捷键提示区内容大致是每个字母按键对应的功能。此时机器上的所有监控数据已经在采样了你按哪个键对应的区块就会被点亮展示。退出方式很简单按q键即可。有些版本里CtrlC也能退出交互模式但在某些终端环境下CtrlC会被当成中断信号导致整个程序带着脏状态退出所以我习惯只用q。第一次进去可能会被满屏数字冲昏头别慌。nmon的核心交互逻辑是“按需点亮”默认状态下展示的区块很少你按c就出CPU按m就出内存按n就出网络按d就出磁盘。这样你既能控制信息密度又不会让无关指标干扰判断。2.3 一个容易被忽略的启动选项-? 帮助页很多人不知道nmon自带帮助页。在交互界面按h会列出当前版本支持的所有按键和说明在命令行里也可以带-?参数直接打印帮助。你不需要背快捷键表只要有这个帮助页在手边面对一个陌生版本的nmon也能快速摸清它能看什么。3. 交互界面逐键拆解把实时监控看明白这一节是实操重点。我会把最常用的几个按键拆开讲不光说按键还会解释屏幕上的字段分别意味着什么以及当你看到什么样的数值时应该警觉。3.1 按c看CPU别只看使用率按c之后屏幕上半部分会显示全局CPU统计数据包括CPU总使用率、用户态占比、系统态占比、等待IO占比、空闲占比下半部分会列出每个逻辑核心的占用情况。关键点在于“等待IO占比”%iowait。如果这个值长期偏高说明CPU在等待磁盘IO返回真正的瓶颈大概率在磁盘而不是CPU。曾经有一次我看到某个数据库节点的%iowait飙到40%CPU本身才用了一半顺着这个线索查下去才发现是慢磁盘导致的。当多核机器出现“某几个核跑到100%、其他核空闲”的情况时说明业务可能绑核或者存在单线程热点。nmon里每个核的颜色深浅也能看出这一趋势不用等到其他工具画图屏幕上就已经说明问题了。3.2 按m看内存RAM与Swap的实时博弈按m之后能看到内存相关的多组数据物理内存总量、已用、空闲、缓存、缓冲以及交换分区的使用量。在Linux的/proc/meminfo里buffers和cached容易混淆nmon把它们分开列方便区分文件缓存和真正的进程内存占用。实际排查时一个高发情况是free命令看到内存还剩很多但业务已经开始性能下降。这时候打开nmon按m重点看cached和Swap的变化趋势。如果cached在高位波动而Swap开始增长说明内存压力在积聚只是还没到系统OOM的程度。等Swap频繁换页性能就会断崖式下跌。3.3 按d看磁盘块设备级别的真实IO压力按d一次显示系统中所有块设备的IO状态再按一次可以展开每个设备下更细的统计。主要包括读速率、写速率、每秒IO次数、繁忙百分比。判断磁盘是否存在瓶颈不能只看读写速率因为SSD和机械盘的带宽上限不同。更可靠的观察指标是“繁忙百分比”它代表了设备有多少时间在处理IO请求。如果这个比例长期高于80%就算吞吐看着不高队列也会堆积应用的感知就会变差。这个区块配合前面说的%iowait一起看基本能还原出整个IO链路的压力分布。3.4 按n看网络网卡流量与带宽占用按n会展示每块网卡的实时速率、包速率、错误包和丢包统计。它把带宽占用率直接换算成了百分比不用你拿当前速率去除网卡带宽。网络问题排查里最容易忽略的是“小包高并发”网卡流量看着只有几十MB/s但包速率已经顶满。nmon里同时展示了包速率能直接区分是带宽瓶颈还是包转发瓶颈。比如某个Nginx节点流量低、但CPU软中断高打开nmon按n如果看到包速率很高方向就明确了。3.5 按j看文件系统与按t看进程文件系统这一层是很多人看漏的。按j会列出所有挂载点的空间使用率和inode使用率。磁盘空间满和inode满都会导致业务写文件失败但报错形式不一样前者常见“No space left on device”后者报同样的错误但df看空间还很充足。nmon里两个指标摆在一起省去了df和df -i来回切的麻烦。按t会显示当前占用CPU或内存最高的Top进程列表类似top但它和nmon其他区块的数据来自同一套采样节拍对比起来没有时间差。3.6 交互界面里的颜色和布局含义nmon终端里的颜色不是纯粹的装饰它代表数值的严重程度。一般绿色表示正常黄色开始需要注意红色说明该项指标已经进入异常区间。不同发行版打包的版本在颜色策略上略有差异但大方向一致。建议习惯“先看颜色再看数值”。屏幕上如果有大块红色即使你一时不知道怎么处理也已经知道问题出在哪个维度再顺着对应按键深入。这也是为什么我说它算“高颜值”工具——它把严重级别编码进了视觉里减少了大量数字比对成本。4. 把颜值再提一档nmonchart将采集数据变成图表实时模式再直观也有它的局限你不可能24小时盯着终端故障结束后还想复盘就需要把数据留档并转成可视化图表。nmon的采集模式配合nmonchart正好补上这一环。4.1 定时采集参数详解采集模式的核心参数就是三个-f代表文件模式-s代表采样间隔秒数-c代表采集次数。例如希望每5秒采一次、持续1分钟nmon -f -s 5 -c 12执行后nmon会在后台运行生成一个以主机名、日期、时间命名的.nmon文件。这个文件是纯文本格式里面记录了每类指标的快照详单体积不大但如果长时间高频采样文件也会增长得比较可观。常用扩展参数还包括-F 文件名手动指定输出文件名。-m 目录指定数据文件的保存目录默认是当前目录。-t记录Top进程数据后面分析进程级问题必须加。-T记录更详细的进程命令行信息但会产生更大的文件。-d记录磁盘数据。-^在AIX上表示记录每秒总CPULinux版不一定支持需要先看帮助。一个适合日常巡检的常用组合是nmon -f -s 30 -c 120 -m /var/log/nmon_data -t这条命令的含义是每30秒采样一次共采集120次总时长1小时数据写到/var/log/nmon_data同时记录进程数据。放在crontab里就可以实现定时巡检*/30 * * * * /usr/bin/nmon -f -s 30 -c 120 -m /var/log/nmon_data -t4.2 nmonchart安装与一行命令出HTML报表.nmon文件是文本直接看也能读但不直观。要把它变成真正的图表最省事的方式是用nmonchart工具。它本身是一个Perl脚本不会常驻内存只是把.nmon文件读进来生成一个自包含的HTML文件。下载到脚本后先赋予执行权限chmod x nmonchart然后执行./nmonchart server_202501011200.nmon server_202501011200.html生成出来的HTML文件用浏览器直接打开即可不需要联网加载任何外部插件。里面的图表包括系统汇总、CPU、内存、磁盘、网络等每个指标一条时间序列曲线拖动鼠标可以看到具体时间点的数值。需要注意nmonchart脚本对Perl版本和系统环境有默认依赖大多数Linux发行版自带Perl环境都能直接运行。如果遇到报错先确认Perl可执行再检查是否有IO模块缺失。4.3 生成的图表怎么看HTML报表里最建议第一眼看“SYS_SUMM”页签它把CPU、内存、磁盘IO、网络IO的汇总曲线放在了一起。排查时段问题时先看汇总曲线确定异常波峰发生在哪个时间点再跳转到对应指标页签看细节。CPU_ALL页签会按逻辑核心分别绘制曲线也有一张总的CPU使用率曲线。内存页签把内存总量、使用量、缓存、Swap分开画能直观看到内存是逐渐耗尽还是瞬时冲高。磁盘页签能看到每个设备的读写带宽和IO次数网络页签则能看出流量波动和包错误。我个人的复盘习惯是拿到一个故障时段的nmon数据后先看汇总页签锁定波峰起点然后分别看CPU、内存、磁盘、网络对应时间点的曲线形态任何一个方向出现持续攀升再结合当时的业务日志定位原因。这个过程从数据到结论一般不超过十分钟。4.4 想把数据接进Grafananmon2graphite的思路nmonchart适合离线复盘但如果想把nmon采集的数据接入现有的Grafana面板也有社区方案可以用。比如nmon2graphite这类脚本可以把.nmon文件里的数据点解析出来通过Graphite的协议上报到Graphite-carbon再由Grafana统一展示。这个方案的适用场景是你的监控体系是Graphite加Grafana而某些旧机器或容器环境不方便安装常规采集Agent。通过nmon定时采集再定时上报可以做到轻量接入。搭建成本不算低但如果你已经跑通了Graphite扩展nmon数据源反而是最平滑的方式。5. 实战复盘一次Java应用内存故障nmon如何帮我快速定位光讲参数不讲战例看完还是会忘。我把最近一次用nmon排查问题的全过程写下来大家感受一下它在真实故障里扮演的角色。5.1 症状与初始排查方向某天下午业务反馈一个Java服务频繁出现接口超时Grafana显示该节点内存使用率缓慢攀升但没有触发OOM。开发怀疑是代码内存泄漏运维把机器重启后继续观察。重启后内存依然以每小时约2%的速度增长。当时所有人的第一反应都是抓堆转储、分析GC日志但分析一次GC日志要花不少时间。我先在机器上开了一个nmon后台采集打算用一整天的数据画出内存曲线再说。5.2 nmon数据还原故障现场采集命令是每小时一个文件每个文件采12次、间隔5分钟这样即使某个文件损坏也不影响整体数据。到了第二天上午我下载了前一天的nmon文件用nmonchart转成HTML报表。内存页签的曲线显示JVM堆外的内存占用在持续上升而JVM堆内比较平稳同时Swap的使用量也呈阶梯式上涨。由于采集时加了-t参数Top进程数据里能看到具体进程的内存变化定位到了是那个Java进程的常驻内存一直在涨而不是系统缓存或临时文件占用。顺着这个线索再看GC日志发现Metaspace区域有缓慢增长。最终排查确认是某个动态生成类的组件在反复加载新的类定义导致Metaspace占用量逐渐膨胀。5.3 换成磁盘问题的复用方法这套排查思路换个方向依然成立。如果怀疑是磁盘问题就重点盯d和j两个区块看块设备繁忙百分比和文件系统剩余空间的变化趋势。如果怀疑网络问题就盯n区块看带宽占用率、包速率和错误包数量在故障时段的形态。前几个月有一次容器集群的Pod频繁被驱逐大家一开始怀疑是内存配额问题后来用nmon采集排查发现是宿主机磁盘IO的util持续接近100%导致写镜像层极其缓慢、容器健康检查超时被重启。那个问题如果在故障当时登录宿主机开nmon实时界面按d和j分别看磁盘IO和文件系统使用率十分钟内就能确定方向。5.4 事故复盘时nmon文件就是时间胶囊故障已经过去但nmon文件还在这就是它的价值。出问题时你没有机会登录机器或者当时没来得及开监控事后如果能拿到出事时段的历史nmon数据一样可以复现当时的系统状态。所以我建议有条件的话在核心节点上长期开着低频采集比如每5分钟采一次、保留一周。真遇到问题时至少有一份能还原现场的历史数据。6. 我踩过的nmon坑与对应的解决思路nmon用久了也会遇到一些坑这里挑几个典型的说说希望大家不要在同一处绊倒。6.1 采集文件把磁盘填满了有段时间我在一批机器上用-s 5 -c 8640做全天采集结果第二天发现数据目录占了好几个GB。问题出在加上-t参数之后Top进程的数据量远大于系统汇总数据高频采样时文件膨胀很快。解决办法有两个一是降低采样频率巡检场景每秒采一次没必要30秒一次就够用二是写好日志轮转和清理策略不要指望nmon自动清旧文件。现在我会在crontab里配合find命令定期清理七天前的.nmon文件。6.2 进程统计开关拖慢业务-t参数能记录进程数据但它会让nmon自身负载升高。在低配机器上长时间开启进程统计对业务进程的影响是不可忽视的。曾有台4核4G的云主机开着-t高频采集业务方反馈接口响应变慢停掉nmon后立刻恢复。建议策略是日常巡检不开-t只记录系统级汇总。出现疑似进程级问题时单独开一段时间高精度采集定位完就停。不要拿生产机长期做实验。6.3 交互界面字符乱码与跳色nmon的界面依赖终端对ANSI转义序列的支持。某些SSH客户端或Web终端下颜色显示会异常严重的会出现字符错位、刷新闪烁。遇到这种情况先检查终端类型设置是否为xterm-256color再确认本地SSH客户端是否禁用了转义序列。还有一个隐蔽问题在tmux或screen会话里运行nmon部分版本会因为终端尺寸变化导致界面刷新异常。解决办法是在固定的终端窗口尺寸下启动或者退出复用器直接登录物理终端查看。6.4 发行版自带版与IBM原版的功能差异Linux各发行版打包的nmon版本和IBM官网发布的版本在功能细节上并不完全一致。比如AIX上特有的一些按键在Linux版可能没有对应实现某些Linux版缺少-a参数的高级磁盘统计不同版本对-N参数的支持也不统一。判断当前版本支持什么最靠谱的方式不是看历史教程而是直接在nmon里按h查看当前版本的帮助页。很多所谓“按键失灵”的案例其实只是那个版本没有这个实现。6.5 数据文件版本不匹配导致生成图表失败用nmonchart处理.nmon文件时偶尔会遇到脚本版本和采集文件格式不兼容的问题。旧版本的nmonchart识别不了新版nmon生成的某些字段生成HTML时可能丢图或直接报错。这种场景下优先升级nmonchart到最新版本其次检查.nmon文件头部是否有明显损坏。还有个小技巧nmon文件里如果有个别字段残缺不影响整图生成不要因为报一两行warning就放弃整个HTML。我个人在实际使用中的体会是nmon不是那种需要天天盯着看、恨不得所有告警都从它这里出的工具但它一定是你登录机器排查问题时最不容易让你失望的那一个。它把系统中相互关联的指标放在同一个屏幕和同一条时间轴上让你能真正“看见”瓶颈在哪而不是靠猜。如果你只是把它当成一个彩色top用那就太可惜了。从实时交互到离线采集再到HTML图表复盘每多掌握一层这个工具能帮你解决的问题就多一大截。建议你拿到手里先在测试环境把每个键都按一遍尤其是c、m、d、n、j、t这几个混个脸熟再跑一次nmon -f -s 5 -c 12 -t -m /tmp把生成的.nmon文件用nmonchart转成HTML看看效果。用不了二十分钟你就能感受到这个“高颜值”的酷监控Toolkit到底好在哪了。