nmon 实战指南：Linux 服务端监控、后台采集与数据分析

凌晨两点被电话叫醒，连上去敲了个 top，第一行红着一片，按了几下回车数字还在跳，等你切去看内存、再看磁盘，刚才那波尖峰已经过去了，什么都没留下。做过服务端监控的人都熟悉这种无力感：问题发生的那几十秒你没有数据，事后只能靠猜。nmon就是在这种时刻特别顶用的一类工具——一个单文件、几十 KB 的小程序，拷到服务器上就能跑，交互界面里按几个键，CPU、内存、磁盘、网络、进程一屏一屏翻过去；也能挂到后台按固定间隔把数据写成文件，第二天拉下来做趋势分析。这篇文章讲的是 nmon 使用方法里真正影响落地的那部分：怎么装、怎么看、怎么采、怎么分析，以及在什么情况下不该用它。刚接手服务器巡检的朋友能照着抄，已经有监控平台、但还需要一台台机器去看现场细节的老手，也能从里面挑到几条有用的经验。

1. Nmon 的定位：为什么它还在运维工具箱里

1.1 一次没有原始数据导致的排查长跑

某公司的订单服务隔三差五出现几秒钟的接口超时，监控平台上显示的 CPU 曲线平滑得像一条直线。原因很简单：平台五分钟采一次点，取的是平均值，几秒的尖峰被抹平了。团队花了三天时间在代码里加日志、在网关上加埋点，最后是一位老同事提了一句“先装个 nmon 按十五秒采一天”，第二天把文件拉下来一看，问题清清楚楚——每十分钟左右出现一次 CPU 的 Sys 时间短时冲高，与某个定时任务的执行周期完全对得上。

这件事说明的不是 nmon 比监控平台强，而是两者的定位根本不同。监控平台解决的是“面”的问题：几百上千台机器的指标汇总、告警、看板；nmon 解决的是“点”的问题：单台机器上，以秒级粒度把原始数据抓下来，留到事后慢慢剥。真实排障里这两件事缺一不可，可很多团队只做了前者。一旦遇到需要看瞬时波形、看进程级细节、看磁盘每一块盘的繁忙度这种问题，平台给不了，nmon 就能补上这个缺口。

它还有个很实在的优点：零依赖。不需要装 agent，不需要连外网，不需要额外的采集服务端，一个可执行文件加一条命令就能开始工作。在客户内网、隔离环境、临时借用的机器上，这个特性比什么花哨功能都值钱。

1.2 和 top、vmstat、sar 摆在一起比一比

单机性能工具就那么几个，用哪个往往取决于你想回答什么问题。我习惯按“是否需要留存”和“是否需要细粒度”这两个维度来选。

top 的问题是不可留存，你看到的就是当下这一帧，关掉窗口数据就没了；vmstat 能循环输出，但字段太精简，磁盘只能看到整体 bi/bo，分不清是哪块盘在忙；sar 的默认采样间隔是十分钟，改小之后又会产生大量文件，而且默认只保留一天，配置起来比 nmon 麻烦不少。

nmon 的位置刚好卡在中间：采集粒度可以调到秒级，输出是纯文本，文件不大，事后既能用表格工具分析，也能自己写脚本处理。它的短板也很明显——没有告警、没有多机聚合、没有长期存储方案，这些都是监控平台的活儿。所以我的做法一直是两者并用：平台负责发现问题和告警，nmon 负责在怀疑某台机器时下去抓一段原始数据。

1.3 它能做什么、不能做什么

先把边界画清楚，能省掉很多走弯路的时间。

nmon 能做的：按可配置的间隔采集单机的 CPU 各状态占比、内存与 swap 使用、分磁盘的吞吐与繁忙度、分网卡的收发速率与包量、Top 进程的 CPU 和内存占用、内核参数、文件系统使用率；能把结果写成结构化的文本文件；能在交互界面里实时切换视图。

它做不到的：抓包、分析具体的连接和端口（那得靠 ss、netstat 或者抓包工具）；看应用的业务指标；跨机器的关联分析；长时间（月级）的数据留存；告警推送。还有一个容易被忽略的点——在容器里跑 nmon，读到的往往是宿主机的 /proc 数据，容器本身的资源视图是失真的，想在容器里做精细化监控得另找方案。虚拟机上则要注意 Steal 时间，这个后面会专门讲。

2. 环境准备与安装：把工具稳稳装进服务器

2.1 版本选择与二进制获取

nmon 的版本号命名有点意思，用的是字母后缀，16g、16i、16j 一直到 16 系列的后继版本。功能上 16g 之后基本稳定，日常使用挑发行版仓库里带的版本就够了，不必追新。真正需要关心的是架构和 libc：主流的 x86_64 二进制在绝大多数发行版上都能直接跑，ARM 平台（现在不少云主机是 ARM 架构）就必须自己编译。

自己编译其实很简单，源码包解开之后看一眼 Makefile，里面通常有多个编译目标，对应不同平台。执行make之后产出的可执行文件就可以直接用。如果目标机器的 glibc 版本比较老，编译时加上静态链接选项，把依赖打进去，拷到别的机器上就不会出现“版本不够”的报错。这个细节在跨环境拷贝时特别重要，我见过不止一次因为 glibc 版本不一致导致工具在新机器上起不来的情况。

放的位置也有讲究。别随手丢在/tmp或者家目录里，系统重启、临时目录清理都可能把它弄丢。统一放/usr/local/bin/或者专门的运维工具目录，后续写定时任务时路径也稳定。

2.2 两类发行版的安装命令

Debian 系（Debian、Ubuntu 及其衍生版）最省事，仓库里直接有包：

sudo apt update sudo apt install nmon

RHEL 系（CentOS Stream、Rocky、Alma 等）需要先启用 EPEL 源：

sudo dnf install epel-release sudo dnf install nmon

如果机器完全隔离、连不了软件源，就走源码编译。整个过程不需要联网，只需要机器上有编译器：

tar -xzf nmon16g.tar.gz cd nmon16g make sudo cp nmon /usr/local/bin/

编译完之后执行nmon -V看一眼版本，能正常输出版本号就说明二进制没问题。顺手再执行一次ldd $(which nmon)，看看动态库依赖是不是都能找到，避免等到定时任务跑起来才发现缺库。

2.3 第一次运行的三个坑

第一个坑是终端宽度。nmon 的交互界面按固定列宽排版，终端太窄会显示成一团乱码或者截断。SSH 工具默认宽度一般是 80 列，勉强够用，但看磁盘列表那种多列视图就会很难受。把窗口拉宽到 120 列以上，体验立刻不一样。如果通过跳板机或者某些终端工具连接，还要确认 TERM 环境变量设置正确，export TERM=xterm-256color能解决大部分显示异常。

第二个坑是权限。普通用户能读/proc下的系统级数据，所以基本指标都能看；但 Top 进程那一屏，非 root 用户看不到其他用户的进程详情，命令行参数也读不全。巡检场景下建议用 sudo 执行，别用su -c那种方式，因为后者可能会丢失终端环境变量，导致界面出不来。

第三个坑是时区。nmon 写文件时用的是系统本地时间，如果服务器设置的是 UTC 而你在东八区看数据，所有时间戳都要手动加八小时，很容易算错。采集之前先date一下确认时区，跨地域的机器尤其要注意统一，不然一份文件里混着不同时区的时间戳，做趋势对比时会非常痛苦。

3. 交互界面：实时看盘的正确姿势

3.1 键盘操作与界面速查

直接敲nmon回车，进入交互界面。顶部会显示主机名、系统版本、当前时间，下面提示按 h 看帮助。常用按键我整理成一张表，贴在工位上比翻手册快：

用起来有两个小技巧。一是按.键做过滤，磁盘多的机器一屏能列几十块盘，其中大部分是空闲的，过滤之后只留有活动的，一眼就能定位。二是l长条图模式，它把最近若干次采样的值画成横向柱状，比单个数字更能看出趋势，判断“是在持续爬升还是偶发抖动”特别好用。

3.2 CPU 那一屏怎么读才不误判

CPU 界面里最关键的是四个数：User、Sys、Wait、Idle。它们加起来接近 100%，剩下的零头是 Steal 和中断之类的细项。

User 高，说明应用在算东西，可能是计算密集型的任务，也可能是代码里有死循环。Sys 高，说明系统调用多，常见于频繁的文件操作、网络收发、锁竞争。Wait 高是个强信号，表示 CPU 在等 IO，这时候你该去磁盘那一屏看看是哪块盘在拖后腿，而不是继续盯着 CPU 想优化算法。Idle 长期在 5% 以下，才是真正的“CPU 打满”，偶尔的短时冲高属于正常波动。

有一点必须提醒：nmon 显示的是整机聚合百分比，不是单核。八核机器上 Idle 显示 12%，意味着还有接近一个核的空闲，业务未必受影响。判断是否真的扛不住，要结合负载均值一起看，nmon 本身不显示 load average，得另外敲 uptime 补一眼。

虚拟机上还要多看一个指标——Steal。它表示 CPU 时间被宿主机拿走给了别的虚拟机。Steal 长期超过 5% 就很值得警惕了，说明你这台机器在争抢资源，此时无论怎么优化应用代码都是白费力气，得去找资源调度那一层。这个指标在物理机上一般是 0，容易被忽略，但在云环境里恰恰是最常见的问题来源之一。

3.3 内存与 swap：别被 free 数字吓到

第一次看 nmon 内存屏的人多半会被吓一跳：free 只剩几百兆，可用内存看起来岌岌可危。实际上这是 Linux 的正常行为，空闲内存会被拿去做页缓存，有需要时随时可以回收。真正该看的是三样东西：cached 的大小、swap 的换入换出速率、以及有没有出现持续的分页活动。

判断逻辑可以这样走：如果 free 低但 cached 高，且 swap in/out 都是 0，那系统很健康，不需要干预。如果 swap 使用率在持续上涨，同时分页速率长期非零，说明物理内存确实不够了，进程在被换出，性能会明显下降。如果 swap 使用率高但分页速率是 0，说明是历史遗留的换出页，暂时没在被访问，可以观察但不用急着处理。

nmon 的内存屏还会显示分页活动的明细，这个信息比单纯的 free 数字有用得多。我曾经遇到过一台机器 free 显示只有 200MB，但业务跑得好好的，一查分页速率全是 0，纯粹是缓存占得满。也见过 free 还有 2GB，但分页速率一直在跳，最后定位到是某个进程有内存泄漏，在不断触发回收。

3.4 磁盘与网络的读法

磁盘屏是 nmon 最有价值的部分之一，因为它按设备分开显示，能精确到具体是哪块盘、哪个分区在忙。每一行有四个关键列：繁忙度百分比、每秒 IO 次数、每秒吞吐量、平均等待时间。

繁忙度这一列最容易误读。机械硬盘上繁忙度超过 70% 基本就是瓶颈信号了，因为磁头寻道是串行的，忙就意味着排队。但固态盘不一样，它支持高并发，繁忙度显示 90% 时吞吐可能还有富余，这时候要看平均等待时间和队列深度，等待时间上去了才是真饱和。还有多路径设备的情况，同一块物理盘会在系统里出现多个设备名，nmon 把它们都列出来，看起来像是好几块盘同时在满负荷跑，实际是同一块，统计时要去重。

网络屏给的是分网卡的收发速率和包量，粒度是秒级的平均值。它能告诉你带宽有没有跑满、有没有突发流量，但看不到连接数、重传率、错误包这些更细的东西。真要排查网络问题，还是得配合ss -s和错误计数一起看。另外网卡名在新版系统上是可预测命名（比如 ens、eno 开头），和 eth0 这种老命名对不上，看数据时注意别搞混。

4. 后台采集：把数据留下来才算真监控

4.1 采集参数逐项拆解

交互模式只能解决“我现在想看”的问题，真正的价值在后台采集——把数据落成文件，事后可回溯。nmon 的采集参数不多，但每一个都值得说清楚。

一个典型的二十四小时采集命令长这样：

nmon -f -T -x -Z -s 30 -c 2880 -m /data/nmon/

算一下：一天是 86400 秒，间隔 30 秒，采样次数就是 86400 ÷ 30 = 2880，正好覆盖二十四小时。如果只需要覆盖业务高峰的八小时，间隔 15 秒，那么次数是 8 × 3600 ÷ 15 = 1920。这个乘法在写命令之前先算清楚，能避免采到一半就停了、或者采了两天还没停的尴尬。

4.2 采集间隔与开销的平衡

间隔怎么定，取决于你要回答什么问题。日常巡检、留一份底档，60 秒足够；怀疑有周期性尖峰，30 秒比较稳妥；已经在复现某个具体问题时，可以临时开 5 秒甚至 1 秒，但只跑十几分钟，不要长期挂着。

开销方面我做过几轮实测：在八核、几十个进程的普通业务机上，间隔 60 秒采集，CPU 占用基本测量不出来，可以认为是 0.1% 量级；间隔 30 秒，占用在 0.1% 到 0.3% 之间；间隔降到 1 秒，占用能到 1% 以上，同时文件增长速度非常快。文件体积还跟磁盘数量强相关，盘多的机器每一轮要多写几十行数据。

下面这张表是我按经验估的量级，实际会因机器配置浮动，但可以拿来判断磁盘空间够不够：

看到最后一行就该明白，秒级采集是排障手段，不是常态配置。曾经有人在生产库上开了一秒间隔采了一整天，结果文件几百兆不说，分析工具打开时直接卡死，反而没法用。正确的做法是先按常规间隔留底，出问题时再针对性地开短时高频采集。

4.3 定时任务与滚动清理

要让它每天自动跑，交给 cron 就行。这里有个细节：cron 的环境变量和交互式登录不一样，PATH 往往是精简过的，所以命令里的可执行文件路径必须写绝对路径，-m指定的目录也必须提前建好，否则文件根本不会生成，而且不会有任何报错提示。

# 每天零点启动一次采集，间隔 60 秒，采集 1440 次覆盖全天 0 0 * * * /usr/local/bin/nmon -f -T -x -Z -s 60 -c 1440 -m /data/nmon/ # 每天凌晨三点清理 14 天前的文件 0 3 * * * find /data/nmon -name "*.nmon" -mtime +14 -delete

输出目录一定要放在数据盘，别放根分区。我见过采集文件把根分区撑满导致系统异常的情况，事后看文件总量也不算大，就是根分区本身空间紧张。清理策略要按空间和保留周期双重考虑：硬盘小的机器保留七天，硬盘宽裕的保留十四天到三十天，同时用df做个兜底检查。

还有一个容易被忽略的点：如果机器会在夜间重启或者做维护，当天的采集文件可能不完整。文件名里带启动时间，可以用来看出这次采集覆盖了哪个时间段。翻旧文件时先看文件名和文件头，确认覆盖范围，别拿半天的数据去分析一整天的趋势。

5. 数据解析：从 .nmon 到可读报告

5.1 官方 Excel 分析模板

采集出来的.nmon文件是纯文本，直接打开看是一堆逗号分隔的行，人眼很难读。最省事的分析方式是官方维护的那套 Excel 分析模板，打开之后选择文件，它会自动把各类指标抽出来画成图表，CPU、内存、磁盘、网络各占一个 sheet，还会自动算出峰值、均值。

用它有几个前提条件。Excel 需要启用宏，打开文件时会有安全提示，得手动允许；文件路径不能有中文和空格，否则读取会失败；单个文件不能太大，Excel 本身有行数上限，秒级采集一天的文件基本打不开。另外它运行在 Windows 环境，如果平时用 Linux 办公，就得靠虚拟机或者另找替代工具。

模板生成的图表里，我最常看的是 CPU 分状态堆叠图和磁盘分设备繁忙度图。前者能看出一天里各个时段的负载构成，是用户态在跑还是 IO 在等；后者能定位到具体哪块盘在什么时间点出现了高负载。这两张图基本能覆盖百分之七八十的日常分析需求。

5.2 手工解析与脚本化

不想依赖 Excel 的话，自己写脚本解析其实不难。.nmon文件的格式是有规律的：以ZZZZ开头的行是时间戳标记，告诉后面这批数据属于哪个采样点；以CPU_ALL、MEM、DISKBUSY开头的行分别是各类指标，第二列那个T加数字的字段就是采样点编号，跟时间戳对应。

一段最小可用的解析代码长这样：

import sys timestamp = {} current = None rows = [] with open(sys.argv[1], encoding="utf-8", errors="ignore") as f: for line in f: line = line.rstrip("\n") if line.startswith("ZZZZ"): parts = line.split(",") current = parts[1] timestamp[current] = parts[2] + " " + parts[3] elif line.startswith("CPU_ALL") and current: parts = line.split(",") rows.append((timestamp.get(parts[1]), parts)) for ts, parts in rows[:5]: print(ts, parts[2:])

跑通之后可以按需扩展：把 CPU 的空闲率取出来画折线，把磁盘繁忙度按设备分组统计峰值，把 Top 进程里 CPU 占用最高的几个筛出来。字段的位置在不同版本之间可能有细微差异，动手之前先看文件头部的AAA行，里面会列出当前版本各字段的顺序，照着它取列最保险。

如果只是想把文件转成表格给不熟悉命令行的人看，社区里也有一些转换脚本能把.nmon直接导成 CSV，导入表格工具之后再透视、画图都方便。选脚本时注意看它支持的版本号，老脚本读新文件可能会错列。

5.3 一份从采集到结论的完整走法

把整个流程串一遍，实际排障时按这个顺序走，基本不会乱。

第一步，确认问题现象和时间窗口。“昨天下午三点到四点之间接口变慢”，窗口就很明确了。第二步，从采集目录里找到对应日期的文件，先看文件大小和行数，确认覆盖了目标时段。第三步，用脚本或分析模板把这段时间的 CPU、内存、磁盘、网络四类指标都拉出来，看哪个指标出现了异常形状。第四步，对异常指标下钻，比如发现磁盘繁忙度在三点十分冲到 95%，就去看那个时间点的 Top 进程和分设备数据，定位是哪个进程、哪块盘。第五步，把结论和原始数据一起归档，下次遇到类似现象可以直接对比。

这套流程里最容易被跳过的是第四步——很多人看到 CPU 高就下结论说“CPU 不够”，实际上 CPU 高可能只是结果，真正的原因在磁盘或者下游依赖。下钻这一步省不得，nmon 提供的分设备、分进程数据就是为了这个准备的。

6. 踩坑记录与问题速查

6.1 采集侧的高频问题

跑了这么多年，采集端的问题翻来覆去就那么几类，整理成表贴在值班文档里能省不少沟通成本。

还有一类不太常见但很坑的情况：机器上装了多个版本的 nmon，cron 调的是老的、手动执行的是新的，两边输出格式不一致，分析时会对不上。统一用绝对路径调用同一个二进制，能避免这个问题。

6.2 判读侧的典型误判

数据本身没问题，读的人理解错了，这种情况比采集故障更常见。

第一个误判是把磁盘繁忙度 100% 当成必然的性能问题。前面提过，多路径设备会重复统计，一块物理盘在系统里显示成好几个设备，每一行都是 100%，看着像全线告急，实际就是同一块盘。排查前先用设备映射关系确认哪些是同一块物理设备，去掉重复。

第二个误判是看到内存空闲率低就判断要加内存。Linux 的页缓存机制决定了空闲内存本来就该少，真正该看的是分页速率和 swap 变化趋势。光看一个数字下结论，很容易做出错误的扩容决策。

第三个误判是 CPU 空闲率高就认为没问题。业务慢但 CPU 闲，很可能是 IO 等待、锁竞争、下游接口超时，或者连接池被打满。这时候 CPU 数据是清白的，问题在别处，得去看磁盘等待时间、网络吞吐、以及应用自身的日志。

第四个是采样间隔造成的盲区。六十秒一次的采集，只能看到六十秒的平均值，如果尖峰只持续三秒，很可能被平均掉。所以看到“数据很平稳”时，先问一句：我的采样间隔够不够细？怀疑有短时尖峰，就换成十五秒采一段对比，往往能看出完全不同的画面。

6.3 开销控制与数据管理

最后说说使用纪律。nmon 本身很轻，但用得不讲究一样会影响业务。

高频采集是头号风险。秒级间隔在普通业务机上还能接受，但在高并发、进程数上千的机器上，采集进程遍历进程列表的开销会明显上升，而且会跟业务争抢 CPU。我给自己定的规矩是：一秒间隔只在复现问题时开，时间控制在十分钟以内，采集完立刻停掉并确认进程退出。

文件存放要规范。统一目录、按主机名和日期命名、定期清理，这三条做到位，后面找文件时就不会抓瞎。清理策略要留出余量，别卡着磁盘容量算，业务的日志也在长，两边一起涨很容易踩线。

还有一点是数据本身的敏感性。采集文件里包含主机名、进程命令行、挂载路径这些信息，跨团队流转时要注意脱敏，尤其是进程命令行里可能带连接串、路径参数。发给外部或者上传到公共空间之前，先把这类字段过滤掉，养成习惯比事后补救强。

把数据从服务器拉回本地可以用 scp，顺手记一下常用写法：

scp ops@10.0.0.12:/data/nmon/*.nmon ./cases/20240520/

批量拉取时按日期建目录，别全堆在一个文件夹里，时间一长自己都分不清哪份是哪天的。

我个人在实际操作中的体会是，nmon 最大的价值不在于它采集了多少指标，而在于它让你在问题过去之后还有话可说。监控平台告诉你“出事了”，nmon 告诉你“当时到底发生了什么”。所以采集这件事最好不要等到出事才想起来做，平时就让它按固定间隔在后台默默跑着，文件留个一两周，真需要的时候翻出来就能用。另外一个小习惯：每次排查完，把那段时间的 nmon 文件单独存一份，和问题记录放在一起，攒上几个月之后你会发现，这些历史数据本身就是一台机器的体检档案，比任何一次性的诊断都有说服力。