企业官网建设流程全解析

做性能分析这事儿，最怕的不是机器真出故障，而是故障来了你手上没有数据，什么都说不清。系统卡顿、内存被打满、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 -V

nmon -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 使用宏加载数据并生成图形化分析结果

模板准备好之后，操作流程大概分这几步：

1. 打开nmon analyser vxx.xlsm，启用宏。
2. 系统弹出对话框，提示选择 nmon 数据文件，直接浏览到你的.nmon文件并选中。
3. 点击“运行”或“OK”按钮（不同模板版本按钮名称略有差异），宏脚本会开始解析数据文件。
4. 解析过程可能需要几十秒到几分钟，取决于数据文件大小和电脑性能，进度条走完后会自动生成一个新工作簿，里面是按不同性能维度分好的多个 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 的占比。如果等待 IO（wait%）长期偏高，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 安装阶段与采集阶段排查速查表

为了让你后面少走弯路，我把实际操作中比较容易踩到的问题整理成一张速查表，碰到异常可以直接按表排查。

另外有一个很隐蔽的问题，就是服务器时钟不准。如果系统时间和实际时间偏差较大，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 图表分析、瓶颈定位，再到问题排查，整个闭环就都跑通了。工具本身挺简单，但真正让数据发挥价值的，是使用它的人有没有形成一套稳定的方法论。希望这篇文章里的经验能帮你在内网环境里少踩几个坑，顺顺利利地把性能监控这摊事跑起来。