企业官网建设流程全解析

CentOS 7 服务器跑了一段时间后，最怕的不是业务没流量，而是机器在满负荷运行时，你手里连一张性能曲线都拿不出来。遇到卡顿、内存飙高、磁盘排队，全靠猜，排查效率低得让人抓狂。我习惯的做法是提前给服务器装上系统性能监控工具，nmon 就是其中很实用的一款。它能覆盖 CPU、内存、磁盘、网络、进程等核心维度，而且离线安装非常简单，特别适合生产环境这种不能随便访问外网的场景。

很多内网服务器根本没有外部网络连接，配置 yum 源也费劲，甚至出于安全规范不允许动网络策略。在这种条件下，离线安装 nmon 解决的不仅是“装一个工具”的问题，而是整个性能观测链路能不能跑起来的问题。这篇文章就把我实操过的完整流程写出来：怎么准备安装包、怎么离线装、怎么配置采集任务、怎么把采集到的数据变成 Excel 图表来分析，全部按可以直接复制的标准来写。

1. 项目背景与整体设计思路

CentOS 7 在如今的服务器存量里占比仍然不低，尤其是跑内部系统、旧业务模块的机器，环境通常比较封闭。这类机器的性能问题往往不是持续存在的，而是间歇性出现：白天好好的，半夜磁盘 I/O 突然飙高，或者某个服务进程把内存吃干净后触发 OOM。等你想排查的时候，现场早就过去了，拿不到任何证据。

所以我的思路很简单：提前部署一套覆盖系统关键性能指标的监控工具，持续采集数据，等出问题时把历史数据翻出来，用图表还原当时的现场。整个过程需要三个核心环节：工具部署、数据采集、数据可视化。三个环节环环相扣，任何一个缺失都会导致排查链条断裂。

1.1 为什么选择 nmon 作为系统性能监控工具

先说说工具选型的逻辑。大家常用的排查命令里，top 适合看瞬时状态，vmstat 适合看内存和 CPU 概况，iostat 专注磁盘，sar 依赖 sysstat 包而且在内网环境经常没预装。这些工具各管一摊，数据格式又互不相同，想汇总成一份完整的性能报表，需要花不少时间做数据整理。

nmon 的优势在于它一站式采集。交互模式下可以实时观察各项指标，批处理模式下可以把 CPU、内存、磁盘、网络、进程等数据统一写进同一个文件。这个文件是文本格式，体积小，后续无论用分析模板快速生成全套图表，还是手动导入 Excel 做定制化分析，都非常顺手。

另一个实际优势是 nmon 几乎没有运行时依赖。这意味着在内网环境里，只要能想办法把安装包传进服务器，基本就能直接装好，不用跟一堆依赖包作斗争。这点在应急排查时尤其重要——服务器已经开始卡了，你不会希望安装工具的过程本身变成另一场灾难。

1.2 离线安装的核心难点与整体方案

离线安装真正的难点从来不在安装动作本身，而在准备阶段。你需要先在能联网的机器上，把匹配目标系统架构和版本的安装包准备好，再通过安全可控的方式传到目标服务器。如果平时没提前准备，等到服务器出问题才临时找安装包，往往要多花几个小时，这还是在能找到正确版本的前提下。

我把这套流程整理成了标准化的操作链路，一共四步：

1. 确认目标系统的版本和架构，下载对应安装包；
2. 把安装包通过离线方式上传到服务器，执行安装并验证；
3. 配置采集任务，让服务器按固定频率记录性能数据；
4. 把 nmon 数据文件转成 Excel 图表，完成性能分析与报告输出。

这条链路看起来简单，但每步都有细节。比如下载的安装包架构不能错，采集频率和次数的计算要匹配监控时长需求，Excel 分析时要知道每个指标对应什么含义。接下来我会按顺序把每一步的操作、参数和踩坑经验都讲清楚。

2. 离线安装 nmon 实操全流程

2.1 安装包获取与环境确认

准备工作不做好，后面全是麻烦。第一步就是确认目标服务器的架构和系统版本，两个命令就够了：

cat /etc/redhat-release uname -m

第一条命令会输出类似 CentOS Linux release 7.9.2009 的信息，第二条输出的是 x86_64 或者 aarch64 这样的架构标识。这两项信息决定你应该选择哪个安装包，搞错了 rpm 安装时会直接报架构冲突，白折腾。

nmon 安装包在社区里有多个版本在流传，文件名通常会体现架构和适用平台。下载时优先选择开源社区维护版或官方发布渠道，注意文件发布时间和更新记录，选较新的版本通常兼容性更好。同一套系统里，不同工具链版本可能对旧内核的兼容有差异，选发布日期与系统版本接近的包，成功率最高。

安装包下载好之后，建议在联网机器上先算一次校验值：

md5sum nmon-xxx.rpm

记下这个值，传到目标服务器后再算一次，两次一致再继续安装。内网环境经常要经过跳板机中转或者移动介质拷贝，传输过程中文件损坏的概率并不低，这一步能避开很多诡异的报错。

2.2 上传、安装与功能验证

传输方式根据现场条件来决定。网络可达的环境下，用 scp 最直接：

scp nmon-xxx.rpm 用户名@服务器IP:/tmp/

如果目标服务器完全隔离，只能通过运维终端操作，可以考虑 rz 命令上传或使用资产管理平台的文件分发功能。反正方式不限，只要保证文件完整出现在服务器上就行。

执行安装只需要一条 rpm 命令：

rpm -ivh nmon-xxx.rpm

正常情况下，命令执行完会输出安装成功提示，nmon 可执行文件会被放到系统可执行路径下，通常是 /usr/bin/nmon。这样在任何目录下直接敲 nmon 就能调用，不需要手动配置环境变量。

安装完之后，我习惯做两步验证。第一步看版本信息：

nmon -V

能输出版本号说明主程序可以运行。第二步做一次短时采集测试：

cd /tmp && nmon -s 1 -c 5 -f

命令结束后，/tmp 目录下会生成一个以主机名开头、以 .nmon 结尾的文件。用 ls 确认文件已生成，再用 head 看一眼内容，确认里面有实际数据而不是空文件。两步验证都通过，安装就算真正完成了。

提示：如果 rpm 安装提示依赖缺失，先别慌。绝大多数情况是 glibc 版本过低或者缺少某个基础运行库。CentOS 7 的官方资源库通常能提供这些依赖，但离线环境下需要提前准备好。实测下来，兼容较新 glibc 的 nmon 版本在 CentOS 7.6 以上的系统里基本都能正常工作。

3. 系统性能数据采集实战

3.1 交互式监控模式

nmon 装好之后最直接的用法是敲 nmon 进入交互模式。启动后界面是全屏的实时数据，但默认情况下各数据模块是收起来的，需要用按键切换显示。很多新手不知道这个机制，进去看到黑屏以为工具坏了，其实只要按键就能调出内容。

常用按键整理如下：

• c：开启 CPU 使用情况视图
• m：开启内存和交换分区视图
• d：开启磁盘 I/O 视图
• n：开启网络接口流量视图
• t：开启 Top 进程视图
• q：退出交互模式

实际排查时，我习惯同时开启 c、m、d、n 四个视图，CPU、内存、磁盘、网络的状态一眼看全。比如业务反馈变慢，我先看 CPU 各核是否打满，再看内存 used 和 cache 的走势，然后看磁盘 busy 百分比，最后确认网络流量有没有异常波动。基本沿着这个顺序看下来，大方向就锁定了。

交互模式适合正在出问题时的临时诊断，因为它是实时刷新，现场感很强。但很多性能问题是间歇性的，凌晨两三点的负载突变不可能靠人盯屏捕捉。这时候必须启动后台采集模式，让数据自己落盘。

3.2 批处理采集与定时任务配置

批处理模式是 nmon 最核心的用法。通过参数控制采集频率、次数和输出位置，让工具在后台持续记录，等性能问题出现之后再回看历史曲线。最常用的参数组合是：

nmon -s <间隔秒数> -c <采集次数> -f -m <输出目录>

参数含义说明如下：

• -s：每次采集之间的间隔，单位秒
• -c：总共采集的次数
• -f：以固定命名规则生成文件，格式是 主机名_日期_时间
• -m：指定输出文件的存放目录

举个例子，要监控 24 小时并且每 5 分钟记录一次，间隔就是 300 秒，次数就是 288 次。这个计算很简单：60 秒乘 60 分钟乘 24 小时，再除以 300 秒，得到 288。很多人会在这里算错，导致监控时长不够或者数据量冗余。

对应命令如下：

mkdir -p /var/log/nmon nmon -s 300 -c 288 -f -m /var/log/nmon

生产环境不能一直手动执行，所以要挂到 crontab 上。比如每天早晨 8 点启动一个 24 小时监控任务：

0 8 * * * /usr/bin/nmon -s 300 -c 288 -f -m /var/log/nmon

每天固定生成一个数据文件后，还要考虑磁盘占用问题。建议加一条清理计划，只保留最近 30 天的 nmon 文件：

0 2 * * * find /var/log/nmon -name "*.nmon" -mtime +30 -delete

这个定期清理习惯非常重要，不然监控数据会悄悄占满系统盘。

3.3 采集文件格式与数据含义

生成的 .nmon 文件表面看是纯文本，实际结构非常规整。每行以 AAA, 形式的前缀开头，用来区分数据类型。常见前缀有 CPU、MEM、DISK、NET，分别对应 CPU、内存、磁盘和网络数据，另外还有 SYS 开头的系统基础信息行。

文件头部是系统信息区块，记录主机名、内核版本、CPU 核数、内存大小等信息。正式数据区块中，CPU_ALL 行记录整个系统的 CPU 汇总数据，依次包括用户态占比、系统态占比、等待 I/O 占比、空闲占比等。MEM 行记录内存总量、使用量、空闲量、缓存量以及交换分区使用情况。DISK 行包含磁盘名、读写速率、繁忙度等。NET 行包含网络接口名、吞吐量和丢包数。

快速预览文件内容可以用 head：

head -80 /var/log/nmon/主机名_日期_时间.nmon

想统计某一段时间的平均 CPU 空闲率，可以用 awk 对对应列做均值计算。理解文件结构是后续一切分析的基础，不管是直接用分析模板还是手动做 Excel 图表，心里都要清楚每个字段背后的含义。

注意：采集文件里的基准时间取自 nmon 启动时的服务器时间，每一行的累计时间是相对启动时刻的偏移量，不是一串绝对的北京时间。做多台机器对比分析前，一定要先确认各服务器系统时间是否一致，否则曲线全部错位，结论没有意义。

4. Excel 图表制作与性能分析

4.1 分析模板一键生成全套图表

拿到 nmon 数据文件后，最省事的做法是用社区分析模板。这个模板是一个启用了宏的 Excel 工作簿，专门用来把 nmon 文本文件转换成成套的图表报告。使用流程我总结为四步：

1. 把 .nmon 文件传到装有 Excel 的电脑上；
2. 打开分析模板，启用宏；
3. 点击模板中的加载按钮，选择 nmon 文件；
4. 等待模板自动解析并生成多个工作表和图表。

解析完成后，通常会产生 SYS_SUMM、CPU_SUMM、CPU、MEM、DISK、NET 等工作表。CPU 页展示每个处理器核心的使用率曲线，MEM 页展示物理内存与交换分区变化曲线，DISK 页展示各磁盘繁忙度和吞吐曲线，NET 页展示各个网络接口的流量曲线。一眼扫过去，哪个时段有问题基本能看出来。

不过这个模板有几个限制。第一，对 Excel 版本有要求，太老的版本部分功能可能不可用。第二，数据文件特别大时，解析速度会明显下降。第三，生成的图表是固定格式，遇到定制化报告需求就不够灵活。因此手动制作图表仍然是一项必须掌握的技能。

4.2 手动制作核心性能图表

手动分析的场景主要有两种：一是模板生成的图表不满足汇报需要，二是想针对特定业务指标做聚焦分析。手动制作核心性能图表的流程并不复杂，核心是把 nmon 文件里的数据正确导入 Excel。

第一步是导入数据。在 Excel 里选择数据选项卡，点击从文本或 CSV 导入，文件类型选 CSV，在导入向导里设置分隔符为逗号。导入后，把含有 CPU_ALL、MEM、DISK 前缀的行筛选出来，分别复制到独立的工作表中，方便后续处理。

第二步是生成趋势折线图。以 CPU 使用率为例，选中时间字段和 User%、Sys%、Wait%、Idle% 这几列，插入折线图，图标题改成“CPU 使用率趋势分析”，再调整横坐标轴的显示格式，让时间刻度直观一些。内存分析做法相同，选中内存总量、使用量、缓存量以及交换分区使用量，生成一条组合曲线。

第三步是用双轴组合图提升信息密度。比如分析磁盘性能时，把磁盘繁忙度做成柱状图，把读写速率做成折线图，放到双坐标轴里。左边轴看速率，右边轴看繁忙度，两个维度的关联性一目了然。手动分析虽然比模板多花时间，但是你对数据的理解会深很多，做完一次就知道每个指标对应文件里的哪一列、数值变化代表什么，下次排查问题时心里有底。

4.3 关键性能指标解读与瓶颈判断

图表画出来不是终点，能看懂图表背后的瓶颈才是核心价值。我总结了几条最实用的判断思路。

CPU 方面重点看 User%、Sys% 和 Wait% 三个值。User% 高说明应用在做大量计算，Sys% 高说明系统调用频繁，可能是上下文切换太多或者内核态开销变大，Wait% 高则往往说明 CPU 正在等待磁盘 I/O 完成。看到 Wait% 持续走高，先不要怀疑计算资源不足，瓶颈很可能在存储层。

内存方面重点看物理内存 used 和 cache 的变化，以及交换分区的使用趋势。如果 swap 使用量持续增长而物理内存接近打满，说明内存压力已经很大，系统可能在频繁换页，业务响应速度会明显变差。

磁盘方面最有价值的指标是 busy% 和读写速率。busy% 长期高于 90% 说明磁盘已接近饱和，读写速率的剧烈波动往往意味着存在突发 I/O。磁盘瓶颈和 CPU Wait% 同时出现时，基本可以确认整个系统的短板在存储。

网络方面重点看接口流入流出速率、峰值以及丢包情况。流量出现明显峰值并且 CPU Sys% 同步升高，有可能是网络中断频繁触发软中断，造成 CPU 开销放大。

这些判断思路可以串联使用。比如某个时段业务响应变慢，先看 CPU 是否长时间打满，再看内存有没有被吃尽，接着看磁盘是不是瓶颈，最后检查网络有没有异常。所有证据都画在图表里，按这个顺序排查，比对着服务器瞎猜快得多。

5. 常见问题排查与实操经验

5.1 安装阶段典型问题

离线安装 nmon 时，最常见的问题是架构不匹配。下载了 x86_64 的安装包，却要往 ARM 架构的机器上装，rpm 会直接提示架构冲突。解决方式没有捷径，只有重新下载对应架构的包。所以前文反复强调，下载前一定先看 uname -m 的输出。

第二种问题是 glibc 版本过低。系统提示缺少某个版本的 glibc 时，要么系统版本太老，要么安装包选得太新。遇到这种情况，可以换一个兼容旧 glibc 的版本。实测经验是，选择与系统版本发布时间接近的安装包版本，成功率最高，不需要额外折腾依赖。

第三种问题是权限不足。rpm 安装和启动采集任务都需要相应权限。如果当前账号没有管理员权限，安装会直接失败，后续写日志目录也会遇到各种障碍。建议安装阶段用有管理权限的账号操作，日常采集任务可以通过 sudo 配置好之后再交给普通用户环境运行。

5.2 数据采集阶段典型问题

采集阶段的问题比安装阶段更隐蔽，我挑几个高频的讲。

第一个是采集文件为空或者只有头部信息。这种情况多半是命令参数拼错，或者输出目录有问题。目录不存在时 nmon 不会报错，而是直接不落数据。所以每次执行完，用 ls -l 确认文件大小不为零。

第二个是 crontab 定时任务不执行。常见原因有两个：脚本路径写错，以及环境变量 PATH 不包含 nmon 可执行文件所在目录。在 crontab 里尽量写绝对路径，比如 /usr/bin/nmon，不要只写命令名，这样能避开环境变量问题。

第三个是磁盘被采集文件填满。监控长期运行后文件会越堆越多，尤其是高频率采集时文件增长非常快。建议定期清理任务尽早配好，或者人为归档。我遇到过监控数据挤爆系统盘的案例，业务进程异常退出，教训非常深刻。

第四个是系统时间不同步导致分析错位。多台服务器联合排查时，如果彼此时间相差很大，曲线根本对不上。上线监控前先检查各机器的系统时间和时间同步配置，保证时钟一致再开始采集。

5.3 图表分析阶段注意事项

Excel 分析阶段的问题主要集中在三个点上。

第一，宏被禁用。Excel 默认安全策略会阻止宏运行，打开模板时需要手动选择启用内容，或者在受信任位置设置里把模板目录加进去。不然点击加载按钮没反应，还以为模板文件损坏了。

第二，数据文件过大导致 Excel 假死。模板解析大量数据时性能消耗明显，实测数据行数超过几十万行之后，Excel 可能出现长时间无响应。解决思路是先对原始文件做抽样，用命令行工具每隔 10 行取一行生成精简文件，再交给模板分析，曲线趋势保留，处理效率提升明显。

第三，手动导入时分隔符识别错误。部分环境里文件分隔符不是普通的英文逗号，或者字段里混有空格，导致所有内容挤到第一列。导入向导里手动指定逗号分隔，先预览列分割效果再确认，能避开大部分格式问题。

最后再说一个我自己坚持了很久的小习惯：每次项目上线或大版本发布前，我都会提前在服务器上开启至少三天的 nmon 采集任务，把上线前后的性能数据完整记录下来。一旦上线后出现性能劣化，可以直接把前后的曲线放在一起对比，哪项指标发生了突变一目了然。这个习惯帮你节省的排查时间，远比安装工具和整理数据花掉的时间多得多。