上周帮朋友处理一起Linux服务器凌晨卡顿的问题最头疼的不是故障本身而是等白天登录上去一切指标都恢复正常了——top里CPU空闲free里内存充足df也看不出半点异常。可业务确实在凌晨卡了将近半小时。没有当时的现场数据性能问题就成了悬案。后来我在那台机器上装了nmon让它每5秒记录一次系统状态第二天把生成的.nmon文件丢进分析工具十分钟不到就锁定了瓶颈。nmon就是这样一个Linux综合监控工具单个二进制文件、不需要安装依赖、既能交互式查看实时状态也能后台定时采集数据而且采集的数据可以离线生成图表。对运维和性能调优来说它最大的价值不是“现在能看到什么”而是“事后还能翻出证据”。这篇文章我从安装选型、交互操作、后台采数到数据分析和生产环境踩坑按实操顺序展开适合正在做服务器监控、性能排查或者准备Linux相关面试的工程师参考。1. 为什么我选了nmon而不是一堆单点命令1.1 一条命令看清整机状态省去来回切命令的麻烦先说最直接的痛点。排查Linux性能问题很多人习惯“三板斧”top看CPUfree看内存df看磁盘要看网络就临时iftop或者sar。三板斧本身没错问题是这些命令之间没有时间关联。你看到CPU高的时候内存到底处于什么状态网络流量是不是同时飙的靠肉眼来回切换命令看到的只是某一个瞬间的快照而且在高负载场景下top刷屏速度极快根本来不及细看。nmon把CPU、内存、磁盘、网络、文件系统、进程、内核信息全部整合在一个字符界面里通过按键切换维度所有指标都在同一个屏幕刷新周期内呈现。这个“时间对齐”非常关键。比如top显示load average从2跳到12但每个CPU核心都很闲这时候基本可以怀疑是磁盘IO等待或者锁竞争。用nmon按d看磁盘busy率、按n看网络流量状态栏里的数字会告诉你负载到底来自计算、IO还是网络。实际排查时我通常登录服务器后什么都不装先起一个nmon几秒钟就能扫完整机资源概况。不是说top没用而是nmon把分散的信息集中到了一起并且是以一种方便对比的方式展示的。遇到情况紧急的时候省下的就是最宝贵的响应时间。1.2 和top、sar、htop放在一起怎么选很多人会问我已经有top、htop、sar了还有必要上nmon吗我的看法是它们不是替代关系而是互补关系。下面这个对比我用了很长时间基本能代表我对这四类工具的理解。工具适合场景短板top快速看实时CPU和进程排行只有瞬态不留历史高负载时难观察htop交互体验好彩色界面直观同样不留历史且依赖ncurses库sar可以定时记录历史指标指标分散在不同文件中同屏对比不方便nmon实时同屏监控 后台采集一条龙更新节奏不如发行版仓库那么勤需要自己关注版本sar其实很强大sysstat包里的采集能力很完整但它的数据是分门别类的CPU在cpu文件里内存、网络各自独立。你想把同一时间点的CPU、内存、磁盘关联起来需要自己拼数据。而nmon采集出的文件是统一格式同一秒的CPU、内存、磁盘、网络记录在同一个文件的不同行里分析的时候天然就能对齐。所以我的习惯是日常巡检和故障复盘用nmon做后台采集实时应急排查用nmon交互界面历史趋势类的长期监控交给专门的监控系统sar作为补充。这样搭配下来既不会漏现场也不会重复造轮子。2. 安装选型单文件免安装的省心之处与最容易踩的架构坑2.1 下载解压就能跑生产服务器不需要装编译链nmon最讨喜的一点是它本质上就是一个静态编译的二进制文件不依赖一堆动态库也不需要make install。它的Linux版可以从SourceForge上找到解压之后里面是多个带不同平台后缀的二进制文件挑对架构直接chmod x就能运行。Debian/Ubuntu环境下也可以直接用apt install nmon装发行版仓库里的版本但版本通常不是最新的CentOS/RHEL如果没有配置EPEL源直接下载官方二进制反而更省事。我一般是这样部署的在SourceForge下载最新的nmon Linux压缩包顺手做一下sha256校验tar解压找到对应CPU架构的二进制文件复制到/usr/local/bin目录chmod 755赋予执行权限运行nmon验证是否正常。整个过程不需要编译工具链这一点在干净的生产服务器上尤其重要。你为装一个监控工具引入gcc、make这些依赖本身就扩大了风险面。单文件部署还有一个好处想批量部署时只需要把同一个二进制复制到几十台机器上目录结构统一脚本管理起来非常方便。2.2 x86_64和aarch64很多人搜成arrch64别搞混解压之后最需要留意的就是选对CPU架构。X86服务器用x86_64版本ARM服务器或者部分嵌入式平台要用aarch64版本。我看到不少朋友在搜“nmon监控工具arrch64”其实正确的拼法是aarch64压缩包里对应的文件通常带aarch64字样。这里提一句ARM版本在部分深度定制过的系统上使用时要注意发行版对二进制的兼容性最简单的判断方式是启动前先用file命令看一下架构。file /usr/local/bin/nmon如果跑起来报“cannot execute binary file: Exec format error”基本就是架构选错了不用急着换系统回去重新挑二进制就行。还有一种情况同样的文件在旧内核上跑不起来那是内核版本太老和新版nmon的glibc要求有关。我在老旧的CentOS 6上就遇到过后来换用发行版仓库里的旧版nmon才跑通。所以生产环境锁定一个验证过的版本比每次都用最新版更稳。3. 交互界面怎么用按对键几分钟看清问题方向3.1 记这几个按键实时排查够用了nmon启动后是一个字符终端界面底部有按键提示。使用它的门槛极低核心按键就那么几个记熟之后基本可以盲操作。按键功能说明cCPU状态连续按会在整体平均和每个逻辑核之间切换m内存状态可以查看物理内存、缓存和交换分区d磁盘状态看每块磁盘的busy率、读写速率n网络状态查看网络接口的实时吞吐t进程列表按资源占用排序类似top的进程视图j文件系统查看挂载点和文件系统使用率q退出退出nmon空格手动刷新立即刷新一次当前画面左右方向键调整刷新间隔调大间隔可以降低对系统的影响这里特别推荐熟练掌握连续按c的切换逻辑。24核以上的机器默认按核显示会刷出密密麻麻一大片想快速判断整体负载时再按一次c切到平均值视图清爽很多。同理m键也有多级视图可以在总览、详细内存分配之间切换。3.2 带你看一遍数据库慢响应的排查过程举个例子假设一台数据库服务器突然响应变慢我登录后启动nmon按c看到几个核的User%直接拉到90%以上初步判断是计算型瓶颈不是IO等待按m确认内存还有余量Swap使用为0排除内存换页按d看磁盘busy发现虽然有一些波动但整体不高按n看网络流量曲线平稳没有异常尖峰最后按t看进程列表定位到是哪个进程在持续消耗CPU。整个过程五分钟就能下结论。如果换成top来回切光是确认CPU、内存、磁盘、网络、进程这五个维度可能就要反复按好几轮快捷键而且每次看到的时间点还不一致。nmon的价值就在这里一个屏幕里能把多个维度串起来形成因果链而不是给你一堆孤立的数据点。4. 后台采数模式真正的自动化运维核心玩法4.1 参数组合与时长换算一眼就能看明白交互界面适合现场排查但nmon真正的威力是后台采集。这个模式下nmon不需要终端前台运行把采样数据持续写入文件事后统一分析。参数设计得很直观-f以标准格式输出到文件文件名默认是“主机名_日期_时间.nmon”-s采样间隔单位是秒-c采样次数-m指定输出目录-F指定输出文件名-t采集线程级数据抓进程内线程时用得上。比如nmon -f -s 5 -c 720 -m /var/log/nmon就是每5秒记录一次共720次持续时间正好60分钟。总时长很好算间隔秒数乘以次数。采样间隔采样次数实际覆盖时长适用场景10秒3601小时故障复盘、压测分析30秒288024小时日常巡检留证60秒144024小时长期低频采集采样间隔越短数据越细文件也越大。排查故障时我倾向用5到10秒的间隔最好控制在1小时以内保证细节完整又不至于文件膨胀。做长期巡检时可以放宽到30秒或60秒文件体积和细节密度之间比较平衡。4.2 接进crontab之前要想清楚的问题后台采集要自动化最自然是接进crontab。但直接甩一条crontab命令上去会埋不少雷我建议用一个包装脚本统一处理。脚本里至少要做三件事创建输出目录、避免重复进程、定期清理旧文件。下面这个脚本是我常用的模板#!/bin/bash # nmon_collect.sh NMON_DIR${NMON_DIR:-/var/log/nmon} SAMPLE_SEC${SAMPLE_SEC:-10} SAMPLE_COUNT${SAMPLE_COUNT:-720} mkdir -p $NMON_DIR # 避免同时跑多个nmon进程 if pgrep -x nmon /dev/null 21; then echo nmon already running, skip. exit 0 fi nmon -f -s $SAMPLE_SEC -c $SAMPLE_COUNT -m $NMON_DIR # 清理30天前的采集文件 find $NMON_DIR -name *.nmon -mtime 30 -deletecrontab里加一条0 22 * * * /usr/local/bin/nmon_collect.sh这个例子是每天晚上22点启动采集两小时正好覆盖常见的夜间任务高峰期。如果希望全天覆盖可以把SAMPLE_SEC30、SAMPLE_COUNT2880但要注意单次文件可能涨到几十MB磁盘空间和后续分析都会受影响。脚本里的pgrep检查是实际运维中必须的nmon本身没有防重复机制crontab里时间重叠或者手动多跑了一次就会出现多个nmon进程同时写文件轻则文件混乱重则磁盘被撑爆。5. 分析数据从.nmon文件到瓶颈定位5.1 nmon analyser出报告的基本流程采集完的.nmon文件不会自己说话它内部是一行行带标签的文本记录。最常用的分析方式是配合nmon analyser这个Excel分析工具。基本流程是下载对应的xlsm格式分析模板用Excel打开并启用宏点击分析按钮选择.nmon文件等待几十秒它就会生成一大堆带图表的sheet。整个流程不需要编写任何脚本甚至不需要懂数据结构。对我来说最重要的几个sheet是这样的CPU总览sheet看整机CPU使用率曲线重点观察Wait占比内存相关sheet看物理内存、缓存、Swap的变化趋势磁盘分析sheet看磁盘busy率和读写吞吐网络sheet看网卡流量是否异常。这套分析工具最适合复盘“说不清原因”的偶发问题。图表可以缩放到某一时间窗口和业务侧的报障时间做比对因果关系一下就清晰了。5.2 没有Excel时用命令行也能查生产环境分析不一定有Windows Excel的环境。没有分析器的时候直接看nmon文件里的文本行也能得到不少信息。nmon文件里每个指标域都有固定标签比如CPU_ALL、MEM、DISKBUSY、NET等。你可以用grep快速提取grep CPU_ALL 主机名_20250101_2200.nmon | tail -20这条命令会输出最近20条CPU整体采样记录每行包含一段时间的CPU使用率数据。虽然没有图表直观但用来快速确认“某个时间段CPU到底高不高”足够了。稍微复杂一点的需求可以配合awk或者python pandas做简单统计。这个命令行提取的思路在很多临时环境里比Excel方便得多。5.3 一次磁盘IO瓶颈的完整复盘讲一个我印象很深的案例。某应用每天凌晨跑批业务侧反馈凌晨两三点经常卡顿但白天完全正常。当时在应用服务器上做了后台采集覆盖凌晨零点到上午十点。数据分析时先看CPU总览sheet发现用户态CPU使用率整体不高但Wait占比在凌晨两点到三点期间持续走高。这时候CPU等待的指向已经很明确了接下来切到磁盘分析sheet看到一块数据盘在同一个时间段busy率接近100%同时DISK READ曲线同步拉起。真相是跑批任务大量读同一块盘磁盘本身的IO吞吐到了上限CPU只能排队等IO。后来把跑批程序的部分读操作挪到另一台机器的磁盘上同一时间段的Wait占比立刻降了下来。整个过程的关键是nmon把凌晨的IO尖峰完整记录下来了。如果没有后台采数这个发生在深夜的瓶颈根本没法事后复盘——你总不能一宿不睡盯着top刷新。6. 生产环境踩过的坑和我的处理习惯6.1 采样周期与文件大小的平衡用nmon时间长了最容易忽略的是文件体积问题。之前图省事用5秒间隔加线程采集开了一整天第二天一看单个.nmon文件接近上百MB。文件大带来的连锁反应是nmon analyser打开极其缓慢Excel甚至直接卡死想分析的数据反而提取不出来。我现在的原则是场景分离日常巡检用30秒或60秒间隔不开启线程采集故障复盘的专项采集才用5秒到10秒间隔并加上-t线程参数但时长控制在1小时以内。这样既能保住关键细节也不会把分析工具拖垮。6.2 时区显示不一致的问题跨时区分析nmon文件时有一个很容易踩的坑服务器生成的文件里记录的是服务器本地时间但把文件拷回本地用Excel分析时如果分析环境按UTC解析时间图表的横轴会和事故实际发生时间对不上。我见过同事对着图表找半天找不到故障点最后发现时间轴差了8小时。处理办法很简单分析前先确认服务器时区在文件名或归档目录上标注清楚时区信息如果分析工具支持时区设置先设置成服务器所在时区再打开。这个细节不解决再好的数据也白搭。6.3 内存指标要结合Swap判断别被free吓到看nmon内存界面时刚开始用的人很容易被“Used很高”吓到。其实Linux会尽量把空闲内存拿去当缓存这是正常行为不是内存泄露。判断内存是否真的紧张我的习惯是一看Swap使用率有没有持续上涨二看内存曲线是不是单边爬升不回落。如果Swap一直是0说明物理内存还够用如果缓存曲线和进程占用同时稳步上升应用本身吃内存的嫌疑就大了。我还习惯把nmon的数据和系统里的free输出做对照。free命令显示的used是包含了cache的看起来经常很高而nmon把物理内存、缓存、缓冲分开展示结合文件系统缓存的情况才能得出真实结论。这个差异在实际问题定位中经常会误导人。6.4 版本选择和跨环境差异nmon的Linux主流版本主要靠SourceForge更新发行版仓库里的版本往往滞后。滞后不一定是坏事至少经过了发行版的测试但如果遇到新内核或者新CPU特性老版本可能识别不完整。我现在的策略是每台服务器锁定一个已验证过的版本不追新也不随便降级批量部署时对二进制做一次sha256校验避免下载过程中出现损坏或被人替换。跨发行版使用时还会遇到一个现象同样的nmon版本在CentOS和Ubuntu上部分显示字段可能略有差异尤其是在终端分辨率不够或编码不对时画面会乱掉。遇到界面出现乱码先检查终端字符集再考虑版本问题不要一上来就换文件。最后分享一个小技巧nmon这种采集方式不要等到故障发生了才想起来开。完全可以纳入日常运维计划每月挑几天做定期采集把数据归档保留。以后做容量规划、扩缩容决策时这些历史数据比拍脑袋估算靠谱得多。我这边已经把nmon采集和值班巡检流程绑在一起自动归档、定期清理遇到“查无对证”的性能投诉先翻这个月的nmon目录多半能找到答案。