The Sar command in Linux: system historical performance
The Sar (System Activity Reporter) command is part of the sysstat package and allows you to collect, report and save information about system activity over time. Unlike tools that show an instant, sar saves historical data that can be consulted later to identify trends, bottlenecks or sporadic problems.
Sar was originally developed by Sebastien Godard and is distributed under the GPL license. It is included in most Linux distributions using the sysstat package, which also provides the sa1 and sa2 demons responsible for regular sampling and storage in binary files under / var / log / sa /.
In Debian-based distributions / Ubuntu is installed withsudo apt-get install sysstat. In RHEL, CentOS or Fedora is usedsudo dnf install sysstatoryum. After installation, the / etc / default / sysstat file allows to activate the collection by setting ENABLED =»true» and defining the sampling interval (by default 10 minutes).
The general format issar [opciones] [intervalo [recuentos]]. Without arguments, sar shows the data of the current day. The most common parameters include -u for CPU, -r for memory, -B for pagation, -n for networks, -d for disks and -A for obtaining all available reports.
-u: shows percentage of CPU time in user mode, nice, system, iowait, stolen and idle.-r: reports free and used memory, as well as buffers and cache.-B: details pagination and swap activities, including pgpgin / pgpgout and fault / s.-n: with suboptions such as DEV for interface traffic, EERROR for errors and FCOLL for collisions.-d: block device statistics such as tps, kB _ read / s and kB _ wrtn / s.-A: equivalent to specify all the above options, useful for a complete vision.
To observe the use of the CPU every two seconds for ten iterations is runsar -u 2 10. The output shows columns such as% user,% nice,% system,% iowait,% steal and% idle, allowing to detect consumption peaks or wait in I / O.
Each line corresponds to a sampling interval; the values are average over that period. A high sustained iowait% indicates that the CPU is waiting for disk operations, while a high% system may indicate excessive system call activity or interruptions.
The sa1 demon runs via cron every 10 minutes (configurable) and saves binary data in / var / log / sa / sADD, where DD is the day of the month. Subsequently, sa2 generates a daily summary in legible format and stores it in the same directory, facilitating the generation of monthly reports.
In / etc / cron.d / sysstat is the task that calls / usr / lib / sysstat / sa1 1 1 1 to take samples and a / usr / lib / sysstat / sa2 6 0 to create the summary. Modifying these files allows you to change the frequency or retain more days of history according to audit requirements.
The binary files can be read again with sar -f / var / log / sa / saDD to get a specific day report. Tools such as ksar (KDE System Activity Reporter) or scripts with gnuplot transform these data into trend graphics, facilitating the presentation to operations or management teams.
It is recommended to adjust the sampling interval according to the load: on critical production servers a 30-second interval provides more detail, while on less demanding systems 5-10 minutes reduces disk use. In addition, sar does not capture sporadic events of less than one interval, so it is complemented by tools such as perf or eBPF for more thin analysis.
To analyze bottle necks in Disk E / S, you can combine sar -d with sar -u and see if the iowait% increases while the% user and% system remain low. A typical example is to runsar -d 1 5to see the transfers per second (tps) and the kilobytes read and written. Also, sar -n DEV shows the traffic of each network interface; if collisions (FCOLL) or high errors (EERROR) are detected, it may indicate wiring problems or duplex configuration. These metric crosses allow to identify whether the limitation comes from the storage, the network or the CPU itself.
Many production environments integrate sar with continuous monitoring systems to create historical dashboards. The binary sa1 data can be exported to CSV usingsar -A -f /var/log/sa/saDD > metrics.csvand then be ingested by tools such as Prometheus by an exporter custom or by scripts that run every minute and send the values to a Pushgateway. In Grafana, panels can be created to show the evolution of CPU use, memory and network width over weeks, facilitating the detection of growth trends and evidence-based capacity planning.
The sar command is an essential tool for any Linux administrator who needs to understand the system's historical behavior. Its capacity to store and consult CPU, memory, E / S and network metrics over days or months allows for capacity analysis, upgrade planning and proactive anomalies detection.
