sysstat: sar, iostat and pidstat for Linux performance data you can keep

The gap sysstat fills: numbers you can look at tomorrow

Most Linux performance tooling answers a question in the present tense. You run top or vmstat, you see what is happening right now, and the moment passes. sysstat is built around the opposite assumption: the interesting incident already happened, and nobody was watching. The package ships interactive reporters such as iostat, mpstat, pidstat, tapestat and cifsiostat, plus a collector path made of sar, sadc, sa1 and sa2 that can be scheduled by cron or systemd. The README describes the default sampling interval as 10 minutes, adjustable down to as small as 1 second, which is the dial that decides how much detail you keep and how fast the data grows. The audience is narrow and specific: system administrators, SREs and support engineers on physical or virtual Linux hosts who need to answer "what did the disk do at 03:20" without having installed an agent beforehand. It is not a fleet observability platform and does not pretend to be one.

How sar, sadc and the binary daily files fit together

The architecture separates collection from reporting, and the repository layout shows it plainly. sadc is the system activity data collector and acts as the backend. sa1 is a front end to sadc that writes binary data into the system activity daily data file, and sa2 is a front end to sar that writes a summarized daily report. Both sa1 and sa2 exist as .in templates in the repository, which is how the build system generates the scripts that cron or systemd actually invoke. sar itself both collects and reports, and sadf reads what was collected and re-emits it as CSV, XML, JSON or SVG; DTD and XML Schema documents ship with the package. That means the stored artefact is a binary file, not a text log, and any downstream tool has to go through sadf rather than reading the file directly. The README lists what lands in those files: I/O and transfer rates per device, per partition and per network filesystem, CPU statistics global and per CPU, memory, hugepages and swap, paging and faults, process creation, interrupts per CPU and per source, IP, TCP, ICMP and UDP traffic based on SNMPv2 standards, IPv6, Fibre Channel, softnet, NFS server and client activity, sockets, run queue and load, kernel tables, TTY activity, power management data including CPU clock frequency, fan speed, temperature and voltage, USB devices, filesystem inode and block utilization, and Pressure-Stall Information. Two design choices are worth noting. New devices such as disks and network interfaces are detected on the fly, so a hot-added device appears without a restart of the collector. And the history length has no built-in cap; the README states the only limit is available space on your storage device, which is a polite way of saying retention is entirely your problem.

Installing sysstat on Ubuntu, RHEL and from source

On Debian and Ubuntu the package installs from the distribution repository, and then data collection has to be turned on separately. The README gives this sequence, and the reconfigure step is the part people skip:

sudo apt-get install sysstat
sudo dpkg-reconfigure sysstat

The reconfigure dialog offers a yes or no choice. Selecting "Yes" enables data collecting. Until that is done, the interactive commands work but nothing is being written to the daily files.

On RHEL, Fedora and CentOS the package comes from yum, and the README notes that CentOS and Fedora call the collector from a cron job in /etc/cron.d that is enabled by default, while recent versions use systemd instead. In that case the service has to be enabled and started:

sudo yum install sysstat
sudo systemctl enable --now sysstat

If your systemd is too old for --now, the README gives the two-step form as `sudo systemctl enable sysstat` followed by `sudo systemctl start sysstat`.

Building from source starts with a clone and a configure run. The README shows the git protocol URL, and the automated reporting switch is passed to configure rather than set afterwards:

git clone git://github.com/sysstat/sysstat
cd sysstat
./configure --enable-automated-sar-reporting

Running `./configure --help` lists the other options, and the README mentions an interactive configuration path as an alternative to typing ./configure directly. For a first real use, the shortest path is to let the collector run for a while and then ask sar for a day of CPU history. The exact flags are documented in the man pages under man/, which the package installs.

Exporting sar data with sadf instead of parsing binaries

The binary daily file is the reason sadf exists. If you want sysstat numbers in a spreadsheet, a log pipeline or a graph, sadf is the documented route, because the README states it displays data collected by sar in multiple formats including CSV, XML and JSON and can be used for data exchange with other programs. It can also draw graphs of the collected activities as SVG, which the README illustrates with sample screenshots of CPU, TCP and load average graphs rendered in a browser. The practical consequence is that any integration you build should target sadf output, not the file layout. JSON output is also available directly from mpstat and iostat according to the README, which matters if you are sampling interactively and want structured output without a second process. One caveat the README does not resolve: the exact sadf flags for each format are not shown in the README text, so you have to read the man page in man/ before writing the pipeline. Treat that as the first thing to verify rather than something to discover in production.

Where sysstat is the wrong tool

The failure mode is retention, and it is structural rather than a bug. Because there is no built-in history limit, the daily files grow until the disk fills or your own rotation removes them. On a busy host with a one-second interval, that arrives quickly. The README does not document rollback, so if you enable collection with a short interval on a small root partition, undoing the damage means disabling the collector and deleting files by hand. Second, sysstat reports on the host. It is not a container-aware accounting system, and nothing in the README describes per-cgroup or per-container attribution; pidstat reports on Linux tasks, which is a different unit of analysis. Third, the collector has to be running before the incident, and on some distributions it is off until an administrator enables it, so a fresh machine that was never configured will have no history to inspect. Fourth, the output is text and files, not alerts. There is no thresholding or notification path in the package; you are expected to read reports or feed sadf output elsewhere. If your requirement is a queryable time-series store with retention policies and alerting, sysstat is the wrong layer, and using it that way means building the missing half yourself.

sysstat against Prometheus node_exporter

The closest alternative for most teams is node_exporter plus Prometheus, and the difference is not the metrics, which overlap heavily, but the direction of the data flow. node_exporter exposes counters over HTTP and Prometheus pulls them on a scrape interval, storing samples in its own time-series database with configurable retention and querying through PromQL. sysstat pushes nothing: sadc writes to a local binary file on a fixed interval set by cron or systemd, and analysis happens after the fact through sar or sadf on that host. That gives sysstat two properties a pull-based stack lacks. It works with no network path and no server, which is why it is common on isolated or customer-owned machines, and it survives the loss of your monitoring backend because the data never left the box. The trade-off runs the other way for fleet work: there is no central query across a hundred hosts unless you build the collection of sadf output yourself, and retention is a disk-space decision rather than a configuration value. A reasonable split is node_exporter for what you want to alert on and sysstat for the forensic detail, particularly per-device I/O and per-process CPU and memory, that a scrape interval of 15 or 30 seconds will smooth away.

Licence, maintenance and the cost of upgrading

sysstat is released under the GNU General Public License, version 2, and the README states it is freely available under that licence. For most users this is the ordinary situation of running GPL software on your own systems. The implication worth flagging is distribution: if you ship sysstat inside a product image or modify it, the GPL-2.0 obligations attach, and that is a question for your own legal review rather than something this article can settle. On maintenance, the repository is not archived and the last push was on 2026-09-12, which is recent. The README also notes that sysstat no longer uses odd and even version numbers to distinguish development from stable releases, and that the latest release should always be considered stable and suitable for distribution packaging. That policy removes the usual guesswork about whether a given tarball is safe to package. The upgrade cost is low in the common case because the interactive commands are stable and the storage format is handled by the package's own tools, but the CHANGES file in the repository is the place to check for behaviour changes before replacing a distribution build, and any pipeline that consumes sadf output should be re-run against the new version rather than assumed compatible.

Editorial conclusion

Adopt sysstat when you need per-device and per-process history that survives a reboot, and you are willing to run its collector. Skip it if you want a UI, per-container accounting or long-term storage with its own retention policy, since sysstat writes plain files on the host and keeps them only as long as your configuration allows. Before rolling it out, check whether the sysstat service is enabled on the target distribution, confirm the sampling interval in the cron or systemd unit, and verify that sadf can read a generated file in the format your pipeline expects.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. Project website
4. README
5. sysstat/sysstat on GitHub