How to collectdata using nmon tool and producing the reports using nmon analyser

— ny_wk

The nmon tool captures CPU, memory, disk, and network metrics on a Linux or AIX server and writes them to a single timestamped file, which the companion nmon Analyser spreadsheet turns into clean charts and reports. This guide shows how to collect data safely in batch mode, watch the system in real time, terminate the collector cleanly, and produce a polished performance report on Windows.

What the nmon tool is and why it matters

nmon (short for Nigel's Monitor) is a lightweight, single-binary performance monitor originally written for AIX and ported to Linux. It has two modes. In interactive mode it draws a live, color-coded dashboard in your terminal. In capture (spool) mode it runs in the background and appends comma-separated samples to a .nmon file, which you later analyze offline.

The reason sysadmins still reach for the nmon tool is its tiny footprint and zero-dependency design. A single executable, no agent, no database, and no daemon to install means you can drop it on a troubled server, capture a day of metrics, and walk away. Performance monitoring data collected this way is ideal for capacity planning, troubleshooting intermittent slowdowns, and building before/after evidence for a change.

Important compatibility note: the binary referenced in many older runbooks, nmon_x86_64_rhel6, targets RHEL 6, which reached end of life in 2020. The commands below are identical across versions, but on a modern distribution you should install the maintained package instead of copying an ancient binary. On RHEL/Rocky/Alma and Fedora, nmon ships in EPEL; on Debian and Ubuntu it is in the default repositories.

Problem: you need lightweight, file-based performance monitoring

You suspect a server is hitting a CPU, I/O, or memory ceiling at unpredictable times, but heavyweight monitoring stacks are not installed and you cannot sit and watch a terminal for hours. You need a way to collect data using the nmon tool over an extended window, then hand a readable report to a colleague or manager. That is exactly the workflow nmon plus the nmon Analyser is built for.

Solution overview

The end-to-end path has four stages:

• Install nmon on the server (package manager preferred; standalone binary as a fallback).
• Capture metrics to a .nmon file with a defined interval and sample count.
• Transfer the file to a Windows workstation.
• Analyse it with the nmon Analyser Excel macro to generate charts.

Step-by-step: install the nmon tool

Use your distribution's package manager whenever possible so you get a maintained, correctly built binary:

1. On RHEL, Rocky, or Alma (enable EPEL first):
   sudo dnf install epel-release
sudo dnf install nmon
2. On Debian or Ubuntu:
   sudo apt update && sudo apt install nmon
3. On older or air-gapped systems where you must use a standalone binary, download the correct build, place it under a working directory, and make it executable:
   cp nmon_x86_64_rhel6 /tmp/
chmod 755 /tmp/nmon_x86_64_rhel6

Confirm it runs and check the version:

nmon -V

If you installed from a package, the command is simply nmon. If you are using a copied binary, call it by its full path (for example /tmp/nmon_x86_64_rhel6). The flags are the same either way.

Step-by-step: collect data using the nmon tool in capture mode

The defining flag for unattended collection is -f, which tells nmon to spool to a file instead of drawing the live screen. Two more flags shape the capture window:

• -s snapshot interval in seconds (how often a sample is taken).
• -c count (how many samples to take before nmon exits on its own).

Total capture duration = interval × count. So -s 600 -c 10000000 samples every 600 seconds (10 minutes) for ten million samples, which is effectively "run forever until I stop it." That is fine for an open-ended capture, but for a bounded study choose a count that matches your goal. For a 24-hour capture at one-minute resolution, use -s 60 -c 1440 (60 × 1440 = 86,400 seconds = 24 hours).

Start a background capture:

1. Run nmon with file mode, a 10-minute interval, and a large count:
   /tmp/nmon_x86_64_rhel6 -f -s 600 -c 10000000
   (or simply nmon -f -s 600 -c 10000000 if installed from a package)
2. nmon detaches and runs in the background. Verify it is alive:
   ps -ef | grep nmon
   Expected output (the grep line itself can be ignored):
   root 13380 1 0 May07 ? 00:00:00 /tmp/nmon_x86_64_rhel6 -f -s 600 -c 10000000
3. The output file is created in the current working directory (or the directory set with -m). It is named hostname_yymmdd_hhmm.nmon. List it:
   ls -l *.nmon
-rw-r--r-- 1 root root 455138 May 10 10:30 BCISBCCLUAAPP01_130507_1430.nmon

A useful refinement is to set the output directory explicitly so files do not litter /tmp. Create a dedicated folder and point nmon at it with -m:

mkdir -p /var/log/nmon
nmon -f -s 60 -c 1440 -m /var/log/nmon

The -t flag adds top-process data to the capture, which is invaluable when you need to know which process drove a CPU spike. Combine it for richer reports: nmon -ft -s 60 -c 1440 -m /var/log/nmon.

Step-by-step: real-time monitoring with the nmon tool

For an immediate, interactive look at the system, launch nmon without -f:

1. Start the live dashboard:
   nmon
   (or ./nmon_x86_64_rhel6 for a copied binary)
2. Toggle the panels you want with single keystrokes:
   • h — on-screen help
   • c — CPU utilization per core
   • m — memory
   • d — disk I/O
   • n — network
   • t — top processes
   • q — quit

Interactive mode is perfect for a quick triage, but it does not write a file, so you cannot generate a report from it. Use capture mode for anything you need to share.

Step-by-step: terminate a running nmon capture cleanly

A background capture stops automatically after its -c count is reached. If you set a huge count (like the ten-million example) you must stop it manually. Find the process ID and end it:

1. Locate the PID:
   ps -ef | grep nmon
root 13380 1 0 May07 ? 00:00:00 /tmp/nmon_x86_64_rhel6 -f -s 600 -c 10000000
2. Send a termination signal. Prefer a graceful stop first so the file is flushed and closed properly:
   kill 13380
   Only if it refuses to exit, force it:
   kill -9 13380
3. Confirm it is gone:
   ps -ef | grep nmon

Why prefer kill over kill -9? A plain kill sends SIGTERM, letting nmon finish writing its current sample and close the file. kill -9 (SIGKILL) cannot be caught and may leave the last record truncated, which the nmon Analyser will flag as a malformed line. Reserve the -9 hammer for a genuinely stuck process.

Step-by-step: transfer the file and build a report in nmon Analyser

The capture file is plain text, so move it to your Windows workstation with any file-transfer method. SFTP is the common choice:

1. From the workstation, pull the file (or push it from the server):
   sftp user@server
get /var/log/nmon/BCISBCCLUAAPP01_130507_1430.nmon
2. Open the nmon Analyser spreadsheet (for example nmon analyser v33f.xls, or the newer nmonchart/nmonanalyser releases) in Excel. Because it is a macro workbook, you must enable macros when prompted, otherwise the buttons do nothing.
3. Click Analyse nmon data.
4. Select your .nmon file and click Open. The macro parses the file and builds a new workbook of charts (CPU, memory, disk busy, network, and top processes).
5. Click Save to keep the generated report as its own .xlsx file.

If you prefer a no-Excel path, the open-source nmonchart utility converts a .nmon file directly into an interactive HTML report on the server itself: nmonchart BCISBCCLUAAPP01_130507_1430.nmon report.html. That avoids macro and licensing friction entirely and is the modern equivalent of the Analyser spreadsheet.

Common pitfalls when you collect data using the nmon tool

• Forgetting -f. Without it, nmon opens the interactive screen and writes nothing. No file means no report.
• Wrong working directory. The .nmon file lands wherever you launched nmon. If you cannot find it, you likely ran from a different directory. Use -m to pin the location.
• Interval too coarse to catch the problem. A 10-minute interval will completely miss a 30-second CPU storm. Match -s to the timescale of the issue you are chasing.
• Count too small. If the capture ends before the incident happens, you have nothing. Size -c to cover the full observation window.
• Disk filling up. Long captures at short intervals can grow large, and writing into /tmp on a system that purges it (or fills it) is risky. Capture into a stable, monitored path like /var/log/nmon.
• Using kill -9 by default. It can corrupt the final record. Try kill first.
• Macros disabled in Excel. The Analyser buttons are macros; with macros blocked the workbook appears inert. Enable them, or use nmonchart instead.
• Running an EOL binary. Copying nmon_x86_64_rhel6 onto a modern host may work, but install the maintained package so you get current fields and bug fixes.

Verification: confirm your capture is valid

Before you transfer anything, sanity-check the file on the server:

1. Confirm the file is growing while the capture runs:
   ls -l /var/log/nmon/*.nmon (run twice; the size should increase)
2. Inspect the header and a few records:
   head -20 /var/log/nmon/*.nmon
   You should see an AAA block (host, OS, CPU count, snapshot interval) followed by repeating CPU_ALL, MEM, and DISKBUSY lines.
3. Count the captured snapshots to confirm coverage:
   grep -c '^ZZZZ' /var/log/nmon/*.nmon
   Each ZZZZ line marks one timestamped snapshot; the count should be close to your -c value (or the elapsed-time equivalent if you stopped early).
4. After the Analyser runs, verify the report contains a continuous time axis with no large gaps — gaps usually mean nmon was paused, the host was overloaded, or the file was truncated by a hard kill.

Reference: key nmon flags

Key Takeaways

• The nmon tool has two modes: an interactive live dashboard and a file-based capture mode triggered by -f; only capture mode produces a file you can report on.
• Capture duration is -s interval multiplied by -c count — size both to the incident you are investigating (for example -s 60 -c 1440 for a clean 24-hour window).
• Stop a long capture with a graceful kill <pid> first; reserve kill -9 for a stuck process to avoid truncating the file.
• Build reports with the nmon Analyser Excel macro (enable macros) or, more simply, with the open-source nmonchart HTML generator.
• Install nmon from your distribution's package (EPEL on RHEL/Rocky, apt on Debian/Ubuntu) rather than copying the end-of-life nmon_x86_64_rhel6 binary onto modern servers.

Frequently Asked Questions

Where does nmon save the .nmon output file?

In the directory you launched it from, unless you override the location with -m <dir>. The filename is automatically hostname_yymmdd_hhmm.nmon. If you cannot find a capture, you almost certainly ran nmon from a different working directory.

How do I stop an nmon capture that I set to run "forever"?

Find its process ID with ps -ef | grep nmon, then run kill <pid> to stop it gracefully so the file is flushed. Use kill -9 <pid> only if the process will not exit, since a forced kill can leave the last record incomplete.

What interval and count should I use for the nmon tool?

Match the interval to the problem's timescale: 60 seconds is a good general default, 5–15 seconds for short bursts, and 300–600 seconds for long capacity trends. Then set the count so interval × count covers your whole observation window (1440 one-minute samples equal exactly 24 hours).

Do I have to use Excel to read nmon data?

No. The nmon Analyser spreadsheet is one option, but the open-source nmonchart tool converts a .nmon file straight into an interactive HTML report with charts, with no Excel or macros required.

For more Linux and sysadmin walkthroughs, subscribe on YouTube @explorenystream.