Interactive tools show what is happening while you watch them. Historical monitoring is needed when a slowdown has already ended. The sysstat suite collects periodic system counters, and sar reads either current counters or saved activity files.
Process Utilization · Lesson 7
Continuous Monitoring
Learn how sysstat collection and sar reports support historical Linux performance analysis.
Enabling Data Collection
Install the distribution's sysstat package, then confirm that its collector and retention mechanism are enabled. The exact service, timer, and configuration paths differ by distribution; installing the package does not guarantee collection has started.
On a systemd host, inspect the package-provided units rather than guessing their names:
$ systemctl list-unit-files | grep sysstat
$ systemctl list-timers --all | grep sysstat
Verify that new activity files are being created in the distribution's sysstat data directory and review their permissions and retention policy.
What should you verify after installing sysstat?
Reading Current Samples
Ask sar to collect three CPU reports at one-second intervals:
$ sar -u 1 3
Other common reports include run queue and load (-q), memory (-r), paging (-B), block devices (-d), and per-CPU activity (-P ALL). Options and fields vary with sysstat version, so consult sar --help or the local manual.
What does sar -u 1 3 request?
Reading Historical Files
Saved file locations and names vary, often under /var/log/sysstat or /var/log/sa. Pass a selected activity file with -f:
$ sar -q -f /var/log/sysstat/sa02
Confirm the file's full date from report headers; a two-digit suffix commonly refers to a day of the month and can be ambiguous across retention periods. Saved binary formats can also require a compatible sysstat version.
Which option tells sar to read a specified activity file?
Correlating an Incident
Establish the incident time and timezone, then compare several signals across the same interval. Look for changes in load, CPU, run queue, paging, device activity, network traffic, and application latency. Counter changes show correlation, not necessarily causation; deployment records and application logs may explain the trigger.
Gaps can mean the host was down, the collector failed, or retention removed data. Monitor the monitoring pipeline itself so missing evidence is visible before an incident.
How should historical sar data be used during an incident review?
Lesson complete
You finished Continuous Monitoring
You can now use sar to investigate performance outside an interactive session.
Verify that collection and retention are actually active.
Request bounded current samples with an interval and count.
Select historical activity files explicitly.
Align several metrics with incident time and workload evidence.
Keep your learning progress
Create a free account to save this lesson and continue learning on any device.
Create a free account