做性能分析这事儿最怕的不是机器真出故障而是故障来了你手上没有数据什么都说不清。系统卡顿、内存被打满、IO 持续高位如果提前装好了监控工具事后拿着图表复盘定位问题往往十分钟就能解决如果没装就只能靠玄学和运气。nmon 就是这样一款口碑极好的性能监控工具轻量、零依赖安装成本跑起来不占多少资源还能把采集结果直接拖进 Excel 生成图表。不过很多内网生产环境根本连不上外网yum 源也用不了这时候就需要离线安装这套组合方案。这篇文章就把我在 CentOS 7 上离线装 nmon、定时采集、再用 Excel 做图表分析的完整过程整理出来希望能给同样困在内网环境里的朋友省点时间。1. CentOS 7 离线环境的工具选型与准备工作1.1 为什么选 nmon 而不是其他监控工具内网服务器做性能监控可选的路子其实不少top、vmstat、sar、dstat 这些系统自带的命令也能看到实时数据但它们的短板很明显——历史数据不会自动落盘想回溯故障现场基本不可能。而像 Prometheus、Zabbix 这类完整监控平台功能确实强大但在离线内网环境里部署一套又重又繁琐光是依赖组件就能装到怀疑人生。nmon 恰好卡在中间它是个单二进制文件既能实时交互式查看系统状态又支持后台静默采集数据到文件采集结果还能借助配套的 Excel 分析模板自动生成几十张图表。对运维同学来说临时抓性能数据、做压测观察、定期巡检归档都是很舒服的选择。而且 nmon 本身消耗的资源极小CPU 占用基本可以忽略不会因为跑监控反而干扰被监控的业务。1.2 离线安装前需要确认的系统环境离线安装的第一步不是急着找安装包而是先确认目标主机的系统版本和架构。CentOS 7 最常见的架构是 x86_64但偶尔也会碰到 32 位或者其他平台的老机器架构不匹配包装上也会直接报错。检查系统信息用这几条命令就够cat /etc/redhat-release uname -m建议把uname -m的输出先记下来后面找 rpm 包的时候要严格按这个架构来找。接下来确认一下系统里有没有装ncurses这个依赖库。nmon 的交互界面依赖它如果缺了这个库装完包之后一运行就会提示找不到共享库。检查方式rpm -qa | grep ncurses ldd /usr/bin/nmon如果ldd输出里出现libncurses.so.5 not found就需要先离线安装ncurses-libs。不过正常情况下 CentOS 7 默认都会带这个库多数时候不需要额外处理。在动手之前我还习惯顺手看一眼磁盘空间毕竟 nmon 采集的数据文件虽然不大但如果采集频率高、时间跨度长日积月累也是要占地方的。1.3 把外网机上的准备工作做扎实离线环境安装核心思路就是在一台能联网的同版本机器上把安装包准备好然后拷贝进去。准备工作分三步走。第一步确认源里能拿到的 nmon 安装包。如果外网机器能访问官方源直接下载对应版本的 rpm。nmon 官方源里通常提供的格式是nmon-版本号-1.el7.x86_64.rpm。如果官方源访问不顺利也可以去第三方镜像源搜一下一定要核对版本号和架构。第二步检查依赖。用 rpm 工具查看安装包的依赖关系rpm -qpR nmon-*.rpm这样能看到这个包依赖哪些库和组件提前在目标机器上验证这些依赖是否存在。这一步看起来繁琐但能帮你避免拷过去之后才发现装不上来回折腾。第三步把 rpm 包和后续要用的 nmon analyser Excel 模板一起放到一个目录里打成压缩包再通过内网传输工具比如内部的软件分发系统、U 盘拷入等方式传到目标服务器。强烈建议这个压缩包里同时放一份README把版本号、来源、校验值写清楚方便后续追溯。2. nmon 离线安装与功能验证2.1 使用 rpm 安装并处理依赖问题离线安装 nmon 最直接的方式就是 rpm 安装命令很简单rpm -ivh nmon-16m-1.el7.x86_64.rpm正常情况下输出会显示安装进度最后出现两个########################################和一行表示写入成功的信息。装完之后用which nmon确认安装路径通常是/usr/bin/nmon或/usr/local/bin/nmon。如果在安装过程中报了依赖缺失的错误也不要慌错误信息会明确告诉你缺的是哪个库。比如常见的是error: Failed dependencies: libncurses.so.5()(64bit) is needed by nmon-16m-1.el7.x86_64这种情况就在外网机器上下载对应的ncurses-libsrpm 包拷贝进来用同样的方式先装上再回头装 nmon 就能顺利通过。内核版本一般不用担心nmon 对内核没有特别苛刻的要求CentOS 7 全系列都能跑。2.2 安装后的功能自检装完不等于完事一定要跑一遍功能验证我习惯按这套流程做检查which nmon nmon -h nmon -Vnmon -h会列出所有参数看到一大串帮助信息就说明程序能正常加载。注意有些版本不支持-V参数如果报错就忽略不影响使用。接下来做一个短时间的实际采集测试。用下面这条命令每 5 秒采一次一共采 6 次也就是 30 秒的数据输出到指定目录mkdir -p /tmp/nmon_test nmon -s 5 -c 6 -f -m /tmp/nmon_test命令执行后不会刷屏而是静默运行到了指定时间自动结束。然后去/tmp/nmon_test目录下看是否生成了一个类似主机名_日期_时间.nmon的文件。用cat或者head -n 20看一下文件内容如果能看到一行行用逗号分隔的数据说明采集功能完全正常。这个简单测试千万别跳过很多看起来装成功的 nmon实际采集时因为权限问题或目录不存在会直接报错退出提前发现问题能省不少事。3. 性能数据采集方案设计3.1 核心参数解析与场景化搭配nmon 的参数非常灵活但对多数运维场景来说真正重要的就几个。先看基础参数-s采样间隔单位是秒-c采样次数和-s一起决定采集总时长-f以固定格式写入文件-m指定数据文件保存目录-t采集占用资源最高的进程信息-d采集磁盘信息优先显示磁盘繁忙度举个例子想采集 10 分钟的数据每 5 秒采一次命令就是nmon -s 5 -c 120 -f -m /data/nmon这里120次乘以5秒正好等于 600 秒。采集总时长的计算方式就是s和c的乘积在做长时间采集规划时这个换算关系一定要算清楚。如果需要做进程级别的分析比如定位是哪个应用占用的 CPU 太高就要加上-t参数。不过加了这个参数后数据文件体积会明显变大对后续 Excel 分析的速度也有影响生产环境非必要不强开。磁盘性能观察则要结合-d不指定的话Excel 图表里磁盘相关的部分就只有基础数据不够精细。3.2 长时间采集与定时任务配置服务器性能问题并不总是当场就能复现更多时候需要提前布点让 nmon 在后台持续采集。这里我常用的做法是配合 crontab 做定时采集。比如要求每天从早高峰开始每 30 秒采一次连续采集 8 小时。30 秒采一次8 小时就是 960 次nmon -s 30 -c 960 -f -m /data/nmon -t配合 crontab 写进计划任务我一般会写成这样30 08 * * * /usr/bin/nmon -s 30 -c 960 -f -m /data/nmon -t这里有个小细节建议你使用 nmon 的绝对路径不要简单地写nmon。因为 crontab 运行时的 PATH 环境变量比较精简不一定包含/usr/bin或/usr/local/bin写成绝对路径可以避免明明手动执行正常、定时任务却不生效的尴尬。同时要给 nmon 单独建一个数据目录比如/data/nmon并确认这个目录的写权限。如果 nmon 进程是以 root 用户跑的那就无所谓但如果用普通用户跑就要提前授权。另外我还会在定时任务里加一条归档逻辑比如用 find 把超过 7 天的.nmon文件打包压缩避免数据文件越积越多最后把磁盘写满。3.3 数据文件命名与归档习惯nmon 默认生成的文件名格式是主机名_YYYYMMDD_HHMM.nmon时间用的是服务器本地时间。这个命名已经比较友好了能直接看出采集时间和主机。但在多台服务器的场景下还是建议把数据文件按角色或业务维度再分一层目录例如/data/nmon/nginx-01、/data/nmon/mysql-01。这样一来后面做 Excel 分析或者给领导汇报时整理材料会轻松很多。我一般在采集任务启动一段时间后会用下面这条命令看一眼数据文件的大小和增长情况ls -lh /data/nmon/如果采集频率是默认的 5 秒一次一小时的数据文件通常只有几 MB占用完全可以接受。但如果加了-t参数文件可能膨胀到几十 MB这时就要评估一下磁盘容量和 Excel 打开文件的性能了。4. nmon 数据转为 Excel 图表分析4.1 nmon analyser 模板的准备与安全设置nmon 最吸引人的点就在这里它配套的 nmon analyser 是一个 Excel 宏文件能把.nmon数据文件直接转成一份完整的图表工作簿。我们用到的模板文件名一般是nmon analyser vxx.xlsm这个模板需要在能联网的机器上下载好传到处理数据的电脑上通常是 Windows 环境这一步也算离线操作的一部分。拿到模板后先不要急着打开我吃过亏这里提醒几个关键设置。第一Excel 打开含宏的文件默认会禁用宏必须手动启用。如果用的是 Microsoft 365 或 Excel 2016 以上版本打开文件时留意顶部黄色提示条点击“启用内容”就行。第二如果遇到宏被禁止运行还得到“文件-选项-信任中心-信任中心设置-宏设置”里选择“启用所有宏”并勾选“信任对 VBA 工程对象模型的访问”。第三nmon analyser 对中文环境的兼容性不太友好如果 Excel 是中文语言环境分析过程中可能报错。一个稳妥的做法是在数据文件路径和文件名中完全避免中文并尽量使用英文版 Excel如果只有中文版可以先把 Windows 系统区域设置里的非 Unicode 程序语言调成英语这招实测下来能规避大部分异常。4.2 使用宏加载数据并生成图形化分析结果模板准备好之后操作流程大概分这几步打开nmon analyser vxx.xlsm启用宏。系统弹出对话框提示选择 nmon 数据文件直接浏览到你的.nmon文件并选中。点击“运行”或“OK”按钮不同模板版本按钮名称略有差异宏脚本会开始解析数据文件。解析过程可能需要几十秒到几分钟取决于数据文件大小和电脑性能进度条走完后会自动生成一个新工作簿里面是按不同性能维度分好的多个 sheet。生成的图表工作簿会包含 CPU 使用率、内存、磁盘 IO、网络流量、进程开销等多个维度每个维度下又有详尽的统计数据和图表。这里要特别注意这个新生成的工作簿在分析完成后要记得另存为新文件不要把模板文件覆盖掉。模板文件只有一个分析数据可是不断的保留原模板才能反复使用。我自己的习惯是每个分析周期结束先把生成的图表工作簿按业务和日期重新命名再统一归档比如nginx-01_20250601_perf.xlsx。这样后续找数据复盘时一目了然。4.3 Excel 图表工作簿的内容解读生成的图表工作簿里有十几个 sheet乍一看可能有点眼花。但真正高频用到的其实集中在几个关键页签。第一个是SYS_SUMM或者对应的系统汇总页这里能看到 CPU 总使用率、内存使用率等综合指标适合快速判断整体是否健康。第二个是CPU_SUMM按 CPU 逻辑核展示使用率同时会给出平均、最大、最小等统计值分析 CPU 瓶颈主要看这个页。第三个是MEM展示物理内存和交换分区的使用情况内存泄漏问题在这里体现得很明显。第四个是DISK_SUMM或DISKBUSY能看到各磁盘的忙闲状态是判断磁盘性能瓶颈的核心页。第五个是NET展示网络流量曲线包括每块网卡的接收和发送速率。看图表的时候不要只看平均值要重点看曲线的尖峰和持续时间。很多时候平均负载不高但某个瞬间 CPU 突然飙到 100%恰好对应业务抖动的时间点这才是需要排查的窗口。5. 性能指标的深度分析与瓶颈定位5.1 通过关键指标判断系统瓶颈拿到 Excel 图表之后下一步就是从“看图”升级到“定位问题”。这个过程需要结合业务特征来判断不能只看单一指标。CPU 维度的分析主要看用户态 CPU、系统态 CPU 和等待 IO 的占比。如果等待 IOwait%长期偏高CPU 其实在等磁盘干活这时候加 CPU 核心数并没多大作用重点要优化磁盘性能。如果用户态 CPU 高比如接近 100%通常是业务计算密集可以考虑优化应用逻辑或者横向扩容。内存维度的分析重点看物理内存剩余量、交换分区使用情况以及内存页换入换出。如果交换分区持续有换页动作内存大概率不够用或者存在泄漏。这里有个很容易忽略的点Linux 会把空闲内存用作缓存所以看到内存使用率很高不一定就是异常要结合缓存占比和实际业务进程占用综合判断。磁盘维度的分析重点看磁盘设备的繁忙度百分比。数值长期高于 80%基本可以断定磁盘是瓶颈了。再进一步结合读写速率曲线能判断是读多还是写多对应去调整缓存策略或者升级存储。网络维度的分析关注网卡的吞吐量和错误包数量。如果接收或发送速率经常接近网卡理论带宽上限那就需要考虑网络瓶颈如果错误包和丢弃包数量异常增长则可能涉及网卡驱动或者交换机问题。5.2 多指标联动分析定位真实原因单一指标往往会误导人我底下一个常见的例子。某次压测看到 CPU 使用率一直很高第一反应是应用计算复杂。但把 CPU、内存、磁盘三张图放在一起看发现 CPU 高的时候磁盘写速率也同步冲到峰值而且内存中的缓存占比在持续下降。真相其实是压测产生了大量日志写入磁盘写能力不足导致 log 进程阻塞间接把 CPU 拖住了。如果只盯着 CPU 曲线可能就会去加 CPU 配置结果钱花了问题还在。所以我看图表时有个固定习惯先看系统汇总页确认整体大方向再选一个核心业务时间窗口把 CPU、内存、磁盘、网络四个页签放在同一时间轴上对照最后再看进程页找到对应时刻消耗资源最高的那个进程。经过这一套“整体-分项-进程”三级跳大多数性能瓶颈都能定位清楚。5.3 从图表到调优建议的转化方法分析数据的最终目的是给出可执行的调优建议。这里我总结了几个比较常用的判断准则如果 CPU 平均使用率超过 70%且峰值持续时间长优先考虑优化应用层或追加计算资源如果磁盘繁忙度均值超过 60%峰值超过 85%需要关注 IO 队列长度必要时更换更快的存储设备如果内存使用率超过 90% 且交换分区活跃优先排查是否存在内存泄漏再考虑扩容如果网络吞吐接近带宽上限同时丢包率上升需要检查网卡中断绑定、网络拓扑及带宽规格这些准则不是硬性的实际判断时要结合业务平峰和高峰的差异。同一条准则放在数据库高写入业务和静态网页业务上结论可能完全相反。6. 离线安装与使用过程中的常见问题6.1 安装阶段与采集阶段排查速查表为了让你后面少走弯路我把实际操作中比较容易踩到的问题整理成一张速查表碰到异常可以直接按表排查。问题现象可能原因处理方式rpm 安装报依赖缺失系统缺少 ncurses-libs 等库在外网机器下载对应库 rpm按依赖顺序安装运行 nmon 提示找不到共享库库文件存在但版本不兼容用ldd /usr/bin/nmon确认具体缺失项目补装对应 32/64 位库采集命令执行后没有生成文件目标目录不存在或无写权限提前mkdir -p创建目录并检查属主和权限crontab 定时任务不执行PATH 环境变量问题在 crontab 中使用 nmon 绝对路径数据文件一直为空或大小为 0nmon 进程启动后异常退出先用极短的-s 1 -c 3手动测试观察标准错误输出长时间采集后系统负载变高数据文件过大或采集频率过高降低采样频率关闭-t对旧数据及时归档另外有一个很隐蔽的问题就是服务器时钟不准。如果系统时间和实际时间偏差较大nmon 生成的文件名时间可能是错的后续在做时间维度的数据对照时会产生很大的误导。建议在开始长期采集之前先校时保证服务器的时间是准的。6.2 数据分析阶段的问题与注意事项Excel 分析阶段的问题也不少这里挑几个典型的再说透一点。第一个问题是宏运行报错。最常见的原因是文件路径或文件名带中文nmon analyser 对非英文字符处理不好报错时不会明确告诉你原因。解决办法就是把 nmon 数据文件放到一个纯英文路径下文件名也改成拼音或英文。第二个问题是大文件分析半天不响应。一个几十 MB 的 nmon 文件在配置较低的电脑上打开可能要几分钟这时不要频繁点击鼠标容易把 Excel 卡死。可以先把数据文件用文本方式截断只保留需要分析时间段的数据再重新生成图表。第三个问题是生成的图表里某些维度为空。例如 DISK 相关页签没有曲线通常是因为采集时没有加-d参数或者系统确实没有识别到磁盘设备。解决方案就是重新采集采集时加上-d。第四个问题是版本兼容性。如果 nmon 版本和 Excel 模板版本相差太大解析格式可能不兼容出现大量零值或者乱码。稳妥的做法是下载模板时注意选择较新版本并和采集机器上的 nmon 版本保持配套关系。数据分析还有个非常容易忽视的点不要只看一两次的数据就下结论。性能问题往往有偶发性建议至少连续采集 3 到 5 天的数据形成多日趋势图之后再动手优化和分析这样判断才更可靠。6.3 一旦采集定型就建议固化的几个习惯最后分享几个我在实际运维中确定受益的习惯。第一每次新环境部署 nmon都固定写一份部署记录记录包版本、安装时间、采集参数、归档策略并提交到内部文档平台。这样可以避免半年后有人问起来大家都不知道这套监控是怎么跑起来的。第二对于重要的压测和故障复盘我会额外把 nmon 数据文件也一起归档不只是保留最终的 Excel 图表。因为图表可能随时被重新分析但原始数据一旦丢失就再也无法还原现场细节。第三nmon 只能做系统层面的指标采集像 JVM 堆内存、数据库慢查询、业务接口响应时间这类应用层指标它覆盖不到。所以真正成熟的监控体系应该是 nmon 负责系统侧基线数据业务侧再用各自对应的监控手段去补充两边对照着看才能形成一个完整的证据链。按照这套节奏从离线安装、参数规划、定时采集到 Excel 图表分析、瓶颈定位再到问题排查整个闭环就都跑通了。工具本身挺简单但真正让数据发挥价值的是使用它的人有没有形成一套稳定的方法论。希望这篇文章里的经验能帮你在内网环境里少踩几个坑顺顺利利地把性能监控这摊事跑起来。