在 Linux 系统管理员的日常工作中，面对服务器性能突然下降、资源瓶颈不明或者需要生成一份专业的性能报告时，你是否感到过手足无措？虽然我们都有 INLINECODEceace733、INLINECODE8f675b2e 或 iostat 这些老牌工具，但它们往往只能监控单一维度，或者输出的数据难以直接用于可视化分析。尤其是在 2026 年，随着云原生架构和 AI 辅助运维的普及，我们需要更精准的数据来驱动自动化决策。
在这篇文章中，我们将深入探讨 nmon（Nigel‘s Monitor）这一功能强大的 Linux 性能监控工具，并结合现代开发理念，看看如何将它融入当今的可观测性体系。作为一个全功能、交互式的命令行工具，它不仅能帮助我们实时监控 CPU、内存、网络、磁盘等核心资源，还能录制性能数据用于后续的深度分析。我们将一起学习如何安装、使用它进行实时诊断，并生成数据报告，助你从“单点”监控走向“全局”掌控。
什么是 Nmon？
Nmon（Nigel‘s Monitor 的缩写）是 Linux 平台上一个非常轻量级且高效的命令行系统性能监控工具。它最初由 IBM 工程师 Nigel Griffiths 开发，旨在为 AIX 和 Linux 提供一个简洁的性能分析手段。
它最大的优势在于：在一个屏幕内展示所有关键指标。这使得我们可以在一个终端窗口中，通过按不同的按键快速切换和组合查看 CPU、内存、磁盘 I/O、网络带宽、文件系统以及进程信息，而无需在多个终端窗口之间来回切换。
对于系统管理员和开发人员来说，在 2026 年的复杂基础设施中，nmon 依然是以下场景的绝佳选择：
- 实时故障排查：快速定位是 CPU 飙高、磁盘 I/O 打满还是内存泄漏。
- 性能基准测试：在进行压力测试时，录制系统的整体负载情况。
- 长期监控报告：生成
.nmon数据文件，转化为图表，用于向管理层汇报或进行历史趋势分析。
Nmon 的安装
Nmon 几乎包含在所有主流 Linux 发行版的软件仓库中。根据你使用的系统不同，我们可以使用以下命令轻松安装它。
在 Ubuntu/Debian 上
对于基于 Debian 的系统，我们使用 apt 包管理器：
# 更新软件源列表
sudo apt-get update
# 安装 nmon
sudo apt-get install nmon
在 Fedora/CentOS/RHEL 上
对于基于 RedHat 的系统，我们使用 INLINECODEf2c159f7 或 INLINECODE4ba4f5b7。需要注意的是，在某些 RHEL 或 CentOS 版本中，nmon 可能位于 EPEL (Extra Packages for Enterprise Linux) 仓库中，因此我们需要先安装 EPEL 源。
# 对于 CentOS/RHEL 7 及更早版本
# 1. 安装 EPEL 源
sudo yum install epel-release
# 2. 安装 nmon
sudo yum install nmon
# 对于 Fedora 或较新的 CentOS/RHEL 8
dnf install nmon
安装完成后，我们可以通过在终端输入 nmon 并回车来启动它。如果安装成功，你将看到一个充满字符数据的全屏界面。
$ nmon
Nmon 交互式监控实战
启动 nmon 后，你会发现这是一个纯键盘操作的界面（类似于 vim）。屏幕上方会有提示信息，告诉你哪些按键可以触发什么功能。所有的操作都是“按键即显示”，再次按键通常关闭该显示。
下面我们将详细演示如何使用这些交互功能。
1. 全局概览与 CPU 监控
在启动界面，我们首先关注的是 CPU。按下 c 键，屏幕下方将弹出 CPU 统计区域。
- USER：用户空间程序占用的 CPU 百分比。
- SYSTEM：内核空间占用的 CPU 百分比。
- WAIT：CPU 等待 I/O 操作完成的时间（如果这个值很高，说明磁盘瓶颈严重）。
- IDLE：CPU 空闲时间。
实战技巧：如果你看到 INLINECODE5950e3b9 值持续很高，而 INLINECODE043a7e37 很低，这意味着 CPU 并不忙，但在等待磁盘读写数据。这是典型的 I/O 密集型负载特征。如果你的服务器是多核的，你可以多次按 c 键来切换显示模式（例如：查看所有核心的独立负载 vs 总体负载）。
2. 内存与交换分区监控
按下 m 键，我们可以查看内存使用情况。这里我们需要特别关注几个指标：
- Real Total/Used：物理内存的总量和已用量。
- Swap Total/Used：虚拟内存的使用量。
深度解析：在 Linux 中，看到“内存用光了”并不一定意味着需要惊慌。Linux 内核会利用空闲内存作为文件系统缓存。因此，我们更应关注 Swap 的使用情况。如果 Swap Used 开始增长，说明物理内存确实不足，系统正在进行痛苦的磁盘交换，此时系统性能会急剧下降。
3. Top 进程详情
想要知道哪些进程在“作祟？按下 INLINECODEc75509e9 键。nmon 会列出消耗资源最多的进程列表，类似于 INLINECODE970c1c01 命令，但更整洁。列表通常包含：
- PID：进程 ID。
- Command：进程名称或命令。
- CPU%：该进程占用的 CPU。
- Res：物理内存占用。
结合 INLINECODE0f94c0bf 和 INLINECODEb4ff3310 键，我们可以快速定位到导致 CPU 飙高的罪魁祸首。例如，当你发现某个 Java 进程 CPU 占用 800% 时，你就可以针对性地进行排查。
4. 磁盘 I/O 图形与统计
这是 nmon 最强大的功能之一。按下 d 键，我们将看到磁盘 I/O 的统计信息，并且是以图形化的 ASCII 字符展示的。
- Disk Busy %：磁盘繁忙的时间百分比。如果接近 100%，说明磁盘已经满载。
- Read/Write：每秒的读写速率（KB/s）。
场景分析：如果 INLINECODE8ed8ff31 很高，但 INLINECODE4c723ce9 速率却很低，这可能意味着磁盘面对的是大量随机的小文件读写（IOPS 瓶颈），而不是带宽瓶颈。这对于数据库服务器调优非常关键。
5. 网络统计信息
按下 n 键，我们将看到网络接口的吞吐量。
- Read/Write：这里指的是接收和发送的数据量。
如果你在排查网络延迟问题，这里的吞吐量数据可以帮你判断网卡是否打满。如果你的网络带宽上限是 1Gbps，而这里显示的速率已经接近 125MB/s，那么网络瓶颈就已经形成了。
进阶功能：录制与离线分析
仅仅在屏幕上查看数据是不够的，我们需要数据留存。nmon 允许我们将系统性能数据录制到一个文件中，然后使用分析工具生成图表。这对于性能测试（例如：在压力测试期间监控服务器）非常有用。
如何录制数据
我们可以使用 INLINECODE2a0e24b8 参数指定输出到文件，使用 INLINECODEcdc7a5ae 参数包含高精度的进程数据，以及 INLINECODEef120747 和 INLINECODE143645a2 来控制采集频率和次数。
示例 1：录制 1 小时的性能数据
假设我们需要录制 1 小时的数据，每 10 秒采集一次。
# -f: 指定输出到文件（文件名通常自动包含时间戳）
# -t: 收集高精度进程信息
# -s 10: 每 10 秒采样一次
# -c 360: 采集 360 次 (10秒 * 360 = 3600秒 = 1小时)
# -m /root/perf_logs: 指定输出文件的目录
nmon -f -t -s 10 -c 360 -m /root/perf_logs
示例 2：结合 nohup 进行后台长期监控
在实际生产环境中，我们通常希望监控命令在 SSH 断开后依然运行。我们可以结合 nohup 使用：
# 使用 nohup 确保进程后台运行，重定向输出
nohup nmon -f -t -s 30 -c 120 -m /root/perf_logs > /dev/null 2>&1 &
如何分析 .nmon 文件
录制得到的 .nmon 文件本质上是一个文本文件，包含了一系列按时间戳记录的快照数据。虽然可以直接用文本编辑器打开查看，但由于数据量巨大，人类很难直接阅读。
- 使用 nmon Analyzer (Excel)
这是一个非常流行的 Excel 宏工具。你可以下载 nmon_analyser.xlsx。
* 打开 Excel 文件（需启用宏）。
* 点击 "Analyze nmon data" 按钮。
* 选择你生成的 .nmon 文件。
Excel 将会自动解析数据，并生成包含 CPU 趋势图、内存曲线图、磁盘 I/O 热力图等多个 Sheet 的报表。
- 使用 nmonchart (命令行生成 HTML)
如果你需要在 Linux 服务器上直接生成网页报告，nmonchart 是最好的选择。
# 假设你已经下载了 nmonchart 并赋予执行权限
./nmonchart localhost_240510_1200.nmon output_report.html
2026 视角：企业级封装与自动化脚本实践
在现代化的运维环境中，我们通常不会手动去一个个服务器上运行 nmon。作为技术专家，我们倾向于编写健壮的封装脚本，使其具备自我管理、错误处理和自动化的能力。让我们来看一个实际项目中的例子，我们如何将 nmon 封装成一个生产级的监控服务。
实战案例：智能监控守护进程
我们需要一个脚本，它能够：自动检测磁盘空间、防止重复启动、优雅地处理信号，并在后台稳定运行。这不仅仅是一个命令，而是一套完整的监控解决方案。
#!/bin/bash
# ============================================================================
# 脚本名称: enterprise_nmon_wrapper.sh
# 功能描述: 生产级 Nmon 监控封装脚本
# 作者: AI Infrastructure Team
# 最后更新: 2026
# ============================================================================
# --- 配置区域 ---
LOG_DIR="/var/log/nmon_logs"
MAX_SNAPSHOTS=288 # 24小时 (每5分钟一次)
COLLECT_INTERVAL=300 # 300秒 = 5分钟
LOCK_FILE="/tmp/nmon_wrapper.lock"
HOSTNAME=$(hostname)
DATE_STAMP=$(date +%Y%m%d)
NMON_BIN=$(which nmon)
# --- 预检查 ---
# 检查 nmon 是否安装
if [ -z "$NMON_BIN" ]; then
echo "[ERROR] nmon 未安装。正在尝试安装..."
# 这里可以添加自动安装逻辑，或者简单地退出
exit 1
fi
# 检查是否已经运行 (防止重复启动)
if [ -f "$LOCK_FILE" ]; then
echo "[WARNING] 检测到锁文件 $LOCK_FILE。脚本可能已在运行。"
# 在实际生产中，这里可以添加检查 PID 是否存活的逻辑
exit 1
else
touch "$LOCK_FILE"
fi
# --- 核心逻辑 ---
# 创建日志目录
mkdir -p "$LOG_DIR"
echo "[INFO] 启动监控: 日志将保存至 $LOG_DIR"
# 定义清理函数 (trap 信号)
cleanup() {
echo "[INFO] 收到退出信号，正在清理..."
rm -f "$LOCK_FILE"
# 这里可以添加结束 nmon 进程的逻辑，或者让 nmon 自己完成采集
exit 0
}
# 捕获 INT 和 TERM 信号
trap cleanup SIGINT SIGTERM
# 启动 Nmon
# 参数说明:
# -F : 指定输出文件名（使用 -F 而不是 -f 可以自定义文件名格式）
# -t : 包含高精度进程信息
# -s : 采集间隔
# -c : 采集次数
# -m : 输出目录
#
# 注意：我们使用 $! 获取 nmon 的 PID，以便后续管理
NMON_OUTPUT="${LOG_DIR}/${HOSTNAME}_${DATE_STAMP}.nmon"
$NMON_BIN -F "$NMON_OUTPUT" -t -s $COLLECT_INTERVAL -c $MAX_SNAPSHOTS -m "$LOG_DIR" &
NMON_PID=$!
echo "[SUCCESS] Nmon 已启动 (PID: $NMON_PID)"
echo "[INFO] 执行以下命令查看实时日志: tail -f $NMON_OUTPUT"
# 保持脚本运行（守护进程模式）
# 或者，如果你只是想启动它并退出，可以去掉 wait，但这取决于具体需求
wait $NMON_PID
# 监控结束后自动清理
rm -f "$LOCK_FILE"
#### 代码深度解析
在这段脚本中，我们融入了 2026 年开发范式中强调的“鲁棒性”和“自动化”理念：
- 锁机制：这是我们在生产环境中防止定时任务（如 cron）重叠执行的关键。没有锁，一次系统维护重启可能导致无数个监控进程在后台争夺资源。
n2. 信号捕获：trap cleanup SIGINT SIGTERM 确保了即使管理员手动终止脚本，锁文件也会被清理，不会导致下次启动失败。
- 环境感知：我们使用了
$(which nmon)而不是硬编码路径，这增加了脚本在不同 Linux 发行版上的移植性。 - 数据管理：我们将日志集中存放在
/var/log下的专门目录，符合 Linux 文件系统层次结构标准 (FHS)，便于后续的日志轮转 集成。
融入 AIOps 与现代可观测性
你可能会问，既然 Prometheus 和 Grafana 这类云原生监控栈已经如此成熟，为什么我们还需要 nmon？
在我们的实战经验中，nmon 填补了一个关键的空白：“上下文快照”。云原生监控擅长展示“此刻”的状态或长期聚合趋势，但在故障发生后的“回溯分析”中，nmon 提供的、带有时间戳的细粒度进程和 I/O 数据是无与伦比的。
2026 年的最佳实践是：将 nmon 作为 AIOps 的数据源之一。
我们可以编写一个简单的解析器，将 nmon 的数据实时推送到 Elasticsearch 或 OpenSearch 中，结合 Kibana 进行可视化。甚至，我们可以利用 LLM（大语言模型） 来分析 nmon 的输出日志。
- 场景：当系统变慢时，AI Agent 可以自动拉取过去 1 小时的
.nmon文件。 - 分析：AI 会分析 INLINECODE27e2b94b 指标和 INLINECODEa3cd60d8 的相关性。
- 结论：AI 生成报告：“从 14:00 到 14:30，CPU Wait 时间与磁盘 sdb 的 Busy 度呈现强正相关（>0.9），判定为磁盘 I/O 瓶颈，建议检查数据库索引。”
这就是我们将 Nmon 这一经典工具赋予新生命的做法。
常见错误与最佳实践
在使用 nmon 的过程中，我们总结了一些经验，希望能帮助你避开坑点：
- 文件过大问题
如果你设置了 -s 1（1秒采集一次）并运行了一整天，生成的文件可能达到几百 MB 甚至更大。这会导致 Excel 打开时直接卡死。
* 解决方案：根据监控时长合理设置采集间隔。对于长期监控（如数天），建议 -s 300（5分钟）或更长。
- 磁盘空间写满
nmon 自身非常轻量，但如果你的日志分区空间很小，长时间的监控可能会把空间写满。
* 解决方案：始终使用 INLINECODEe25e17d6 参数将日志输出到空间充足的挂载点（如 INLINECODE4e22de47 或专门的数据盘），并在脚本中增加清理旧日志的逻辑。
- 权限问题
普通用户运行 nmon 可能无法看到某些内核或进程详细信息。
* 解决方案：在进行深度故障排查时，建议使用 sudo nmon 运行，以确保数据采集的完整性。
总结
Nmon 不仅仅是一个监控工具，它是 Linux 系统管理员手中的“听诊器”。通过它，我们可以实时诊断系统病痛，也可以录制数据作为“病历”进行长期分析。在 2026 年，掌握这种基础层面的工具，能让我们更好地理解系统的底层行为，从而构建出更稳固的监控体系。
在这篇文章中，我们不仅探讨了 Nmon 的基础操作，还深入研究了如何通过企业级脚本封装来解决自动化部署的问题。我们鼓励你尝试编写自己的封装脚本，并将其与你现有的监控工具链结合。
现在，建议你登录到你的测试服务器，试着运行 INLINECODEb516fcb7 并按下 INLINECODE823be7f8 键，看看你的磁盘 I/O 状况如何？或者尝试使用我们提供的脚本模板，部署你的第一个自动化监控任务。掌握这个工具，将让你的系统运维工作如虎添翼。