Read Live and Saved System Metrics with sar

sar is the tool you reach for when a box was slow twenty minutes ago and you need proof, not a live top session. You will take short CPU, memory and network samples, save a capture for later inspection, and read the daily activity files sysstat already keeps. Allow about fifteen minutes. The commands below were checked with sysstat 12.6.1 on Linux 6.8.

Most examples here are ordinary, unprivileged reads. You may need elevated access to read a data file owned by another account, or to write somewhere restricted, but do not reach for sudo by default. sar only reports local activity.

1. Check the installed command

Confirm the binary and version before comparing output with another host. This avoids mixing details from a different sysstat release into an incident report.

$ command -v sar
/usr/bin/sar
$ sar -V
sysstat version 12.6.1
(C) Sebastien Godard (sysstat <at> orange.fr)

The command requires /proc, and reads kernel statistics from /proc and /sys. If it is missing, install sysstat through your normal package-management process; do not replace the system package with a copied binary while diagnosing a host.

Checkpoint: You have confirmed the version and can run sar -V.

2. Take a short CPU sample

Run a two-second sample three times:

$ sar -u 2 3
Linux 6.8.0-139-generic (server.example)  09/26/26  _x86_64_  (8 CPU)

21:15:16        CPU     %user     %nice   %system   %iowait    %steal     %idle
21:15:18        all      1.20      0.00      0.60      0.10      0.00     98.10
21:15:20        all      2.10      0.00      0.80      0.00      0.00     97.10
21:15:22        all      1.70      0.00      0.70      0.05      0.00     97.55
Average:        all      1.67      0.00      0.70      0.05      0.00     97.58

The exact numbers, hostname and timestamps will differ on your machine. all is the system-wide view, and the fields are percentages:

Do not treat one busy sample as a diagnosis. Compare several intervals and, where it helps, inspect individual processors:

$ sar -u -P ALL 2 3

This adds a row for each online processor plus a global row. A high global average can hide one saturated processor, while a high value on one processor can be entirely expected for a single-threaded workload.

3. Sample memory and network activity

The option selects the activity report; the final two arguments still mean interval and count.

$ sar -r 1 2
$ sar -n DEV 1 2

-r reports memory utilisation. Useful columns include kbavail, an estimate of memory available for starting applications, and %memused. -n DEV reports packet and byte rates for each network interface; use -p when device or interface names need a more readable layout.

Here is a fact worth flagging: the manual calls these units kilobytes and megabytes, but notes that sysstat actually uses kibibytes and mebibytes. Keep that distinction when converting a sar figure into a capacity calculation.

Checkpoint: You can collect CPU, memory and interface reports without changing system state.

4. Save a capture for later analysis

Use -o to write binary records while the samples are collected. This example writes only under /tmp:

$ sar -o /tmp/sar-capture 2 5 >/dev/null
$ test -s /tmp/sar-capture && echo "capture written"
capture written

The file is binary, so do not open it in an editor. The collector saves all data available from the kernel for this capture, even though the live display defaults to CPU activity; the redirection hides the live report because the saved file is the useful result here.

This example changes state by creating a temporary file. When you have finished with it, remove that exact file:

$ rm -- /tmp/sar-capture

Warning: that removal is irreversible. Keep the file if it is evidence for an incident, and copy it to your approved evidence store rather than leaving it in a world-readable location.

5. Read the saved records

Pass the capture to -f and choose the reports you want:

$ sar -u -r -n DEV -f /tmp/sar-capture
Linux 6.8.0-139-generic (server.example)  09/26/26  _x86_64_  (8 CPU)

... CPU, memory and network records from the capture ...

The placeholder line above represents host-specific output, not literal text to expect. The check that matters is that the command reads the file and prints the selected reports. -f and -o are exclusive: one reads an existing file, the other creates one.

For an existing sysstat daily file, name it explicitly. The default directory is /var/log/sysstat, and files use names such as sa26 or sa20260926 depending on how they were created:

$ ls -l /var/log/sysstat/sa*
$ sar -r -n DEV -f /var/log/sysstat/sa26

If no filename is given, sar chooses the most recent standard daily file when displaying saved data. That convenience can be a distraction during an investigation: state the path when you need a result someone else can reproduce.

6. Bound the time and avoid false conclusions

When reading a saved file, -s sets the starting time and -e sets the ending time. Their defaults are 08:00:00 and 18:00:00, so an unqualified report may not cover the full day:

$ sar -u -s 00:00:00 -e 23:59:59 -f /var/log/sysstat/sa26

Use 24-hour time. These options apply to file reads, not a live sample. -1 is a shortcut for yesterday's standard daily file, but an explicit path is clearer in notes and scripts.

Missing sections do not necessarily mean the kernel has no such activity. Some statistics depend on the data collector settings and kernel version; disk and filesystem reports, for example, depend on collector options. Check which collector sar invokes if a report is unexpectedly absent:

$ sar --sadc
/usr/lib/sysstat/sadc

Finally, remember that sar calculates rates between counter readings. A single interval is a snapshot, not proof of causation. Correlate it with service logs, workload changes and the relevant device or process tools before you act on it.

Done means