Collect Linux Activity Data Safely with sa1

sa1 is the wrapper behind every sysstat daily file, quietly called every ten minutes by a timer you may never have looked at. You will collect one or more system activity samples with it, check the resulting binary data file, and work out which scheduler is already running it. The examples use sysstat 12.6.1 on this machine. Allow about fifteen minutes for a first collection and verification. It writes binary data under /var/log/sysstat, so the collection step normally needs elevated privileges.

1. Check the installed command and package

sa1 is a shell wrapper around sadc, installed at /usr/lib/sysstat/sa1 rather than anywhere an interactive user's PATH normally searches. Check the path and version before putting it into a service or script:

$ test -x /usr/lib/sysstat/sa1 && echo 'sa1 is executable'
sa1 is executable
$ dpkg-query -W -f='${Package} ${Version}\n' sysstat
sysstat 12.6.1-2
$ /usr/lib/sysstat/sadc -V
sysstat version 12.6.1

The exact package revision will vary by host. The absolute path matters in cron and systemd units, where an interactive shell's PATH is not a safe assumption.

2. Check whether collection is already scheduled

Read the installed units and cron file before adding anything of your own. Running two collectors against the same daily file can cause contention or duplicate samples. Both checks below are read-only:

$ systemctl cat sysstat-collect.timer sysstat-collect.service
$ sed -n '1,120p' /etc/cron.d/sysstat

On this installation, systemd schedules /usr/lib/sysstat/sa1 1 1 every ten minutes. The cron file also contains a Debian helper, but that helper exits when systemd is running, and it honours ENABLED in /etc/default/sysstat too. Do not create a second root crontab entry until you know which mechanism is actually active.

3. Take one sample manually

For a controlled test, ask sa1 for one sample after a one-second interval. This appends a record to the current standard daily file, and because it changes system accounting data, review the target first and use sudo only for this operation:

$ sudo /usr/lib/sysstat/sa1 1 1
$ printf 'sa1 exit status: %s\n' "$?"
sa1 exit status: 0

• The two positional values mean interval and count: one record after one second.
• No arguments at all? The wrapper calls sadc 1 1 for a normal single sample.
• Avoid --boot here. It writes a dummy record marking a counter restart, not an ordinary measurement.

$ sudo find /var/log/sysstat -maxdepth 1 -type f -name 'sa*' -printf '%TY-%Tm-%Td %TH:%TM %s %p\n' | sort | tail -5

Daily files normally use names such as sa26, the day of the month. If sysstat is configured for long names, expect saYYYYMMDD instead. These files are binary, so a successful file result tells you more than cat ever will.

4. Include disk statistics when you need them

Most kernel data is collected by default, but the optional activities have to be requested. The DISK keyword collects block-device statistics, using the documented sa1 form below:

$ sudo /usr/lib/sysstat/sa1 1 1 -S DISK
$ printf 'sa1 exit status: %s\n' "$?"
sa1 exit status: 0

• XDISK extends this with partition and filesystem statistics on supported kernels.
• ALL requests every optional activity sadc lists.
• XALL also includes the extensions. More metrics mean bigger records, so select only what your reports actually need.

There is a subtle file-level default worth knowing: activities already present in an existing data file win over a later -S selection when records are appended. Choose your optional metrics when the file is first established, and keep a consistent collection policy; a later -S DISK does not retroactively add disk counters to older records.

5. Read back the result with sar

Use sar to interpret the binary file. Without a filename it picks the current standard file; for disk activity, ask for the disk report:

$ sar -d
Linux ...
...  DEV  tps  rkB/s  wkB/s  ...

The header and rows depend on the kernel, devices and samples available. If the current standard file is not present, specify an existing file explicitly after checking its name:

$ sudo ls -l /var/log/sysstat/sa*
$ sar -d -f /var/log/sysstat/saDD

Replace saDD with the actual path, such as sa26, and do not type the literal placeholder. An error saying the file cannot be opened usually means collection is disabled, the date-specific filename differs, or no sample has been written yet. Rerunning sar with random flags will not fix any of those.

6. Rotate the previous day after midnight

--rotate writes a record into the previous day's standard file, meant to run shortly after midnight so the final interval before midnight is covered:

$ sudo /usr/lib/sysstat/sa1 --rotate
$ printf 'rotation exit status: %s\n' "$?"
rotation exit status: 0

Use --rotate iso when your standard files are configured with ISO date names. This is a state-changing operation on the accounting file, not a report command, so let the package's existing timer or cron arrangement handle it when one is installed. If you add a custom schedule, remove it again before returning to the package-managed one, and check that only one rotation job survives.

7. Handle sleep and reboot markers correctly

System transitions need markers, not a normal timed sample. --boot records that counters restarted from zero; --sleep records entry to or exit from suspend or hibernation:

$ sudo /usr/lib/sysstat/sa1 --boot
$ sudo /usr/lib/sysstat/sa1 --sleep suspend
$ sudo /usr/lib/sysstat/sa1 --sleep resume

Do not use these as substitutes for routine collection: they add comments or dummy records that help sar make sense of gaps and counter resets. On a managed system, the installed service and sleep integration normally call these hooks for you.

Common traps and recovery