Zum Inhalt springen 
sar sysstat liefert mir historische Metriken von Linux-Servern, mit denen ich Lastmuster, Engpässe und abweichendes Verhalten sauber über Zeit nachverfolge. So analysiere ich CPU, RAM, I/O und Netzwerk rückblickend und erkenne wiederkehrende Spitzen, die ein reines Live-Tool leicht übersieht.
Zentrale Punkte
Die folgenden Kernaussagen fasse ich kurz und klar zusammen.
- Historie statt Momentaufnahme: Regelmäßige Aufzeichnung macht Lastmuster sichtbar.
- Kombination aus Sammlung und Auswertung: sysstat sammelt, sar bereitet auf.
- Breite an Metriken: CPU, RAM, Swap, Disk I/O, Netzwerk und mehr.
- Diagnose von Ursachen: Zeitfenster gezielt nachstellen und vergleichen.
- Planung mit Trends: Kapazitäten realistisch dimensionieren.
Was leisten sar und sysstat im Alltag?
Ich nutze sar als System Activity Reporter, der die von sysstat gespeicherten Daten lesbar macht. sysstat sammelt regelmäßig CPU-, Speicher-, I/O- und Netzwerkwerte, während ich mit sar gezielt Berichte für bestimmte Zeiten abrufe. Dadurch erkenne ich wiederkehrende Lastfenster durch Backups, Cronjobs oder Traffic-Peaks ohne Rätselraten. Im Gegensatz zu Live-Tools wie top oder htop bewerte ich nicht den flüchtigen Zustand, sondern beziehe die zeitliche Entwicklung ein. Diese Perspektive vermeidet Fehldiagnosen, weil sie Ursache und Wirkung voneinander trennt und mir belastbare Hinweise liefert.
Installation und Aktivierung auf gängigen Distributionen
Ich installiere sysstat per Paketmanager, aktiviere die Erfassung und prüfe die systemd-Timer. Unter Debian/Ubuntu reichen meist apt install sysstat und ein Blick in /etc/default/sysstat, gefolgt von systemctl enable --now sysstat. Auf RHEL-/CentOS-/Oracle-Linux nutze ich dnf install sysstat und steuere die Timer über systemctl. Danach landen Tagesdateien üblicherweise unter /var/log/sa/ mit Namen wie sa10 für den 10. des Monats. Ich verifiziere die Erfassung mit sar ohne Parameter oder mit sar -u 1 3 für einen kurzen Ad-hoc-Check.
Die wichtigsten sar-Aufrufe erklärt
Für CPU nutze ich sar -u und bei Bedarf pro Kern sar -u -P ALL, um Spitzen nicht zu übersehen. Speicher und Caching betrachte ich mit sar -r und Swapping mit sar -S. Die Plattenaktivität lese ich mit sar -d, das Netzwerk mit sar -n DEV,ETCP,TCP,UDP. Historische Dateien öffne ich mit sar -f /var/log/sa/sa10 und grenze Zeitfenster mit -s HH:MM -e HH:MM ein. Für Detailanalysen zu Wartezeiten ergänze ich sar durch I/O-Waits analysieren, weil ich so Warteschlangen und Durchsatz besser bewerte und Engpässe sauber identifiziere.
Messwerte richtig lesen: CPU, Speicher, I/O, Netzwerk
Ich schaue auf wenige Kennzahlen, die mir rasch ein verlässliches Bild liefern und die ich im zeitlichen Verlauf vergleiche. CPU-Idle nahe 0 und hohe %iowait deuten auf Warteschlangen an der Platte hin. Ein hoher %steal verrät CPU-Knappheit in Virtualisierung. Beim RAM beachte ich freie Speicherseiten, Pagecache-Verhalten und Swap-Ins/Outs. Für das Netzwerk helfen Paketfehler, Drops und Retransmits, um Kapazitätsgrenzen oder Störungen zu erkennen.
| Metrik | sar-Schalter | Auffällige Werte | Sofortmaßnahme |
|---|---|---|---|
| CPU | sar -u [-P ALL] | %idle sehr niedrig, %iowait hoch | I/O prüfen, Threads verteilen, CPU-Bedarf validieren |
| Speicher | sar -r | wenig frei, starker Pagecache-Schwund | Dienste optimieren, RAM erweitern, Caching bewerten |
| Swap | sar -S | häufige Swap-Ins/Outs | Arbeitsspeicher entlasten, Limits anpassen |
| Disk I/O | sar -d | hohe await-/svctm-Werte, Queue wächst | I/O-Profil prüfen, Storage-Tiering oder Batch-Fenster anpassen |
| Netzwerk | sar -n DEV,ETCP | Drops, Errors, Retransmits | MTU/Offloading testen, Bandbreite und Latenz analysieren |
Historische Daten und Zeitfenster auswerten
Ich arbeite fast immer mit Zeitfenstern, etwa sar -u -f /var/log/sa/sa10 -s 01:00:00 -e 05:00:00 für nächtliche Jobs. So vergleiche ich identische Uhrzeiten an verschiedenen Tagen und erkenne Trends statt Einzelfälle. Für maschinelle Auswertung speichere ich Daten mit sadf -d im CSV-Format und lade sie in ein eigenes Dashboard. Bei ungewöhnlichen Peaks betrachte ich benachbarte Intervalle, um Seiteneffekte auszuschließen. Ich halte diese Methode schlank, weil sie mir schnell verwertbare Hinweise ohne lange Vorarbeit gibt.
Trendanalyse und Kapazitätsplanung
Ich nutze die archivierten Werte für Forecasts und dimensioniere Ressourcen an realen Mustern statt an Bauchgefühl. Steigt die CPU-Auslastung wochenweise, plane ich Kerne oder Taktreserven ein. Wächst der Arbeitsspeicherbedarf durch Caches, vergleiche ich Nutzen und RAM-Erweiterung. Zeigt der I/O-Pfad vermehrte Wartezeiten, entscheide ich über schnelleren Storage oder entkoppelte Batch-Fenster. Für Visualisierung binde ich Daten alternativ an Grafana und Prometheus an und kombiniere sar-Trends mit Metriken aus Exportern.
Praxisfall: Webserver mit Lastspitzen
Ich skizziere einen Fall, in dem WordPress-Seiten jeden Abend verzögert antworten und Nutzer Abbrüche melden. Mit sar -u -s 18:00:00 -e 20:00:00 und sar -d finde ich zeitgleiche I/O-Spitzen während Backups. Parallel zeigt sar -n DEV steigenden Netzwerkdurchsatz, was die Lastsituation abrundet. Die Gegenprobe am Folgetag ohne Backup bestätigt das Muster. Ich verlege den Job, optimiere Datenbank-Queries und entzerre Caches, wodurch die Abendspitzen verschwinden und die Antwortzeiten wieder konstant bleiben.
Tipps für Datenhaltung, Rotation und Aufbewahrung
Ich prüfe die Aufbewahrung in /etc/sysconfig/sysstat oder /etc/default/sysstat und stelle die Retention je nach Bedarf ein. Für kritische Hosts hebe ich 30–90 Tage auf, um saisonale Effekte zu erkennen. Die Dateigröße bleibt überschaubar, solange Intervalle sinnvoll sind und keine übertriebene Sekundentaktung aktiv ist. Ich rotiere ältere Archives in ein zentrales Verzeichnis oder hänge sie an eine einfache Langzeitablage. So halte ich Daten verfügbar, ohne das System zu belasten oder die Auswertung zu verlangsamen.
Integration mit Monitoring-Stacks und Logs
Ich setze sar als Rohdaten-Lieferant ein und kombiniere es mit zentralem Monitoring, Log-Analyse und Alarmierung. Ein APM- oder Log-Stack liefert mir Ereignisse, während sar die Infrastrukturwerte zeitlich einordnet. Für besonders laute Hosts nutze ich zusätzlich pidstat und iostat, um Prozesse und I/O-Pfade zuzuordnen. Ergänzend hilft mir Process Accounting, ressourcenhungrige Prozesse sauber zu belegen. Diese Verbindung aus Ereignis- und Metriksicht vermeidet Blindflug und verkürzt meine Fehlersuche deutlich.
Konfiguration feinjustieren: Intervalle, sa1/sa2 und Timer
Ich stelle die Erfassungsintervalle so ein, dass sie zur Dynamik des Systems passen. Ein Minutentakt bietet sich als Standard an, während bei hochvolatilen Hosts auch 10–30 Sekunden sinnvoll sein können. Die Sammlung übernimmt sa1 (häufige Stichproben), die Tageszusammenfassung sa2 (Berichte über den Tag). Unter systemd prüfe ich die entsprechenden Timer bzw. Services und passe die Frequenz an. Auf Debian/Ubuntu aktiviere ich die Sammlung oft explizit mit ENABLED="true" in /etc/default/sysstat. Ich dokumentiere die Intervalle pro Umgebung, damit spätere Vergleiche korrekt sind und niemand aus 5‑Sekunden-Stichproben falsche Schlüsse gegenüber 1‑Minuten-Daten zieht.
Fortgeschrittene sar-Optionen im Überblick
Neben den Klassikern helfen mir zusätzliche Schalter für eine Vollsicht: sar -b zeigt Block-I/O-Throughput aggregiert, sar -B das Paging-Verhalten des Kernels und sar -W die Swap-Aktivität im Detail. Mit sar -q sehe ich die Runqueue (Prozesse, die auf CPU warten) und die Load-Entwicklung. sar -H liefert Hugepage-Daten, wenn relevant. Für Platten nehme ich bei Bedarf sar -d -p, um Partitionen getrennt zu betrachten. Ich bin vorsichtig mit svctm: Dieser Wert ist in modernen Kerneln teils unzuverlässig oder 0; ich werte lieber await (End-to-End-Latenz) und avgqu-sz/aqu-sz (Warteschlangengröße) aus. Und wenn ich einen schnellen Gesamteindruck brauche, liefert sar -A einen breiten Überblick, den ich danach fokussiere.
Virtuelle Maschinen und Container richtig bewerten
In Virtualisierungen beachte ich %steal besonders: Hohe Steal-Werte bedeuten, dass der Hypervisor der VM CPU-Zeit entzieht. Das führt leicht zu Fehleinschätzungen, wenn ich nur %idle bewerte. Ich korreliere daher CPU-Auslastung, Steal und Runqueue (sar -q) gemeinsam. In Container-Umgebungen trenne ich Host- und Workload-Sicht: sar beobachtet den Host, nicht einzelne Container. Brauche ich Details pro Dienst, ergänze ich mit pidstat (per-Prozess) und berücksichtige cgroups-Limits. Ich prüfe außerdem CPU-Frequenz-Skalierung und Power-States (Taktwechsel), weil sie kurzfristig Latenzen verursachen können, die ohne Kontext wie CPU-Knappheit wirken.
Zeitbezug: Zeitzonen, Sommerzeit und zuverlässige Korrelation
Ich achte auf konstante Zeitbasis, damit Vergleiche stimmen. sar speichert standardmäßig in Lokaltime; bei Clustern lohnt sich eine einheitliche TZ (oft UTC). Rund um die Sommerzeitumstellung prüfe ich doppelte oder fehlende Zeitfenster und nutze bei Bedarf die Ausgabe von sadf mit Zeitstempeln im ISO-Format. Für Korrelationen mit Logs oder APM-Events gleiche ich die Zeitzonen ab, um Peaks in Metriken exakt mit Ereignissen (Deployments, Backups, Cronjobs) zusammenzuführen. Saubere Zeitreferenzen reduzieren Missverständnisse in Incident-Postmortems deutlich.
Automatisieren und exportieren mit sadf
Für Berichte und Dashboards exportiere ich Daten mit sadf. Im Alltag nutze ich sadf -d (CSV) für einfache Auswertungen, alternativ sadf -j (JSON) für flexible Pipelines. Ein typischer Export sieht so aus: sadf -d /var/log/sa/sa10 -- -u -r -b -n DEV,ETCP -s 18:00 -e 20:00 > sar_abend.csv. So erzeuge ich eine Datei mit CPU, RAM, Block-I/O und Netzkennzahlen für ein Abendfenster. In Skripten vergleiche ich damit automatisch Wochentage, berechne Median/95. Perzentil und markiere Ausreißer. Ich halte die Metrikmenge bewusst schlank, um die Lesbarkeit zu bewahren und Fehlalarme zu vermeiden.
Praxisfall: Datenbankserver mit Pagecache-Druck
Ein MySQL-Host klagt über sporadische Query-Latenzen. sar -r zeigt abends sinkenden Pagecache, sar -S gelegentliche Swap-Outs. Parallel wächst bei sar -d die await-Zeit, und sar -b weist auf erhöhte Schreibflüsse hin. Die Korrelation mit Log-Rotationen und einem ETL-Job erklärt das Muster: Große sequentielle Schreibwellen verdrängen den Cache und drücken Reads der Datenbank in I/O. Ich entzerre die Jobs, erhöhe den RAM moderat und setze DB-Buffer gezielt größer. Nachher bleiben await- und Swap-Werte stabil, die Latenzen sinken, und der Pagecache hält die Hotsets zuverlässig im Speicher.
Betriebliche Aspekte: Overhead, Gerätelisten und Filter
Ich halte den Overhead klein, indem ich Stichproben verhältnismäßig wähle. Sysstat liest primär aus /proc und schreibt binär; bei Minutenintervallen spüre ich die Last kaum. Auf Hosts mit sehr vielen Devices oder kurzlebigen Blockgeräten (z. B. bei Snapshots) filtere ich die Ausgabe gezielt und bewerte nur relevante Pfade. Für dm-crypt, MD-RAID oder Multipath-Geräte prüfe ich sowohl das logische als auch – wo möglich – das zugrunde liegende Device, um Engpässe korrekt zuzuordnen. Ich dokumentiere dabei die Gerätenamen, damit spätere Vergleiche nicht an umbenannten Pfaden scheitern.
Methodik: Baselines und Vergleichstage
Ich definiere pro Host eine Baseline pro Tageszeitfenster (z. B. 01–05 Uhr Batch, 09–18 Uhr Office, 18–22 Uhr Peak). Für jedes Fenster merke ich mir typische Medianwerte und akzeptable Perzentile (z. B. CPU-%idle, await, avgqu-sz, Retransmits). Bei Abweichungen suche ich erst nach neuen Jobs, Deployments oder Trafficmustern – erst danach denke ich an Kapazitätserweiterungen. Diese disziplinierte Reihenfolge verhindert Schnellschüsse: Häufig löst eine kleine Planänderung oder eine Limit-Anpassung mehr als teurer Hardwarezuwachs. sar liefert mir dafür die belastbare Faktenbasis über Wochen und Monate.
Grenzen und sinnvolle Ergänzungen
Ich sehe sar nicht als Ersatz für Alarmierung, weil es standardmäßig keine Schwellen überwacht oder Benachrichtigungen versendet. Echtzeit-Alerts gehören in dedizierte Systeme, die Regeln, Eskalationen und Team-Workflows abbilden. Auch tiefe Metriken zu Applikationen, Datenbanken oder JVMs decke ich über Exporter und Tracing ab. sar glänzt, wenn ich Systemressourcen historisch vergleichen und Engstellen im Betrieb nachvollziehen will. In Summe setze ich es gezielt ein, wo schnelle, wiederholbare Antworten auf infrastrukturelle Fragen gefragt sind.
Kurz zusammengefasst
Ich nutze sar und sysstat, um aus Messwerten eine nachvollziehbare Geschichte der Serverlast zu machen. Die Kombination aus regelmäßiger Sammlung und gezielter Rückschau klärt Ursachen, statt Symptome zu raten. Mit wenigen Befehlen decke ich CPU-, Speicher-, I/O- und Netzwerkprobleme auf und belege sie zeitlich. Daraus leite ich realistische Kapazitätsentscheidungen ab und erkenne ineffiziente Routinen wie schlecht getimte Backups. Wer Linux-Server verantwortet, gewinnt mit dieser Methode verlässliche Orientierung und spart Zeit bei Analyse, Planung und Betrieb.
