© Andranik Hakobyan / 123RF.com

Top, Vmstat und Iotop gehören zu den unverzichtbaren Monitoring-Tools für Linux, haben jedoch einen entscheidenden Nachteil: Sie zeigen nur die momentane Situation, geben aber keine Auskunft über den Zustand in der Vergangenheit. Hier kommt Sysstat ins Spiel.

Das Paket Sysstat enthält zahlreiche Werkzeuge zum Überwachen von Performance und Lastzuständen auf Systemen. Dazu zählen unter anderem Iostat, Mpstat und Pidstat. Neben diesen zum Ad-hoc-Einsatz vorgesehenen Tools bringt Sysstat eine Reihe von Utilities mit, die Sie periodisch per Cronjob einplanen, beispielsweise Sar. Die zusammengetragenen Statistiken lassen nahezu keine Wünsche offen, angefangen bei I/O-Transferraten über CPU- und Speicherauslastung, Paging und Page Faults, Netzwerkstatistiken und Dateisystemauslastung bis hin zu den Aktivitäten von NFS-Servern und -Clients.

Man könnte die Daten freilich auch jederzeit mithilfe von Top, Vmstat, Ss und so weiter ermitteln. Ausnahmesituationen auf Systemen beschränken sich jedoch kaum auf Zeiten, zu denen Sie aktiv vor dem Bildschirm sitzen. Typischerweise erhalten Admins Anfragen wie “Können wir detailliertere Informationen bekommen, was genau zwischen 01:23 Uhr und 01:37 Uhr auf System XY los war?” Viele Sensoren in modernen Monitoring-Systemen erkennen solche Anomalien. Doch vermutlich haben die wenigsten IT-Abteilungen ein umfangreiches Monitoring für sämtliche Systeme konfiguriert. Zudem kommt es durchaus vor, dass ebenjene Messgrößen nicht im zentralen Monitoring implementiert sind. Für solche Fälle liefert Sysstat den passenden Werkzeugkasten.

Installieren

Um Sysstat unter Ubuntu und Debian zu beziehen, genügt der Befehl »sudo apt install sysstat«. Im Auslieferungszustand prüft Sysstat über einen Systemd-Timer alle zehn Minuten das System. Benötigen Sie engmaschigere Messungen, müssen Sie die Periode in der Datei »/usr/lib/systemd/system/sysstat-collect.timer« anpassen. Eine Stichprobe alle fünf Minuten stellen Sie ein, indem Sie dort statt der Voreinstellung »*:00/10« wie in Zeile 4 von Listing 1 »*:00/10« eintragen. Anschließend teilen Sie Systemd die neue Konfiguration per »systemctl daemon-reload« mit.

[Unit]
Description=Run system activity accounting tool every -10- 5 minutes
[Timer]
OnCalendar=*:00/05
[Install]
WantedBy=sysstat.service

Zur Aktivierung und zum Start des Monitorings mit Sar müssen zudem die Datei »/etc/default/sysstat« öffnen und die Einstellung »ENABLED=”false”« in »ENABLED=”true”« ändern. Aktivieren Sie den automatischen Start des Diensts beim Booten mit »systemctl enable sysstat« und starten Sie ihn direkt mit »systemctl start sysstat«. Ein Aufruf von »systemctl status sysstat« sollte nun »active« anzeigen.

Sysstat am Werk

Sysstat schreibt die Messwerte binär kodiert in Dateien im Ordner »/var/log/sysstat/«. Sie unterliegen dem Dateinamensschema »saDD« beziehungsweise »saYYYYMMDD«. DD steht für den aktuellen Tag, YYYY für das laufende Jahr und MM für den laufenden Monat. Je nach Aufruf schreibt Sar entweder in »saDD«, falls Sie die Option »-o« angegeben haben, oder in »saYYYYMMDD«, falls zusätzlich die Option »-D« vorliegt. Beim Lesen greift Sar stets auf die aktuelle Datei zu.

Wenn Sie es per »sar -q« starten, gibt das Tool eine kurze Übersicht über die Konfiguration aus. Darin findet sich eine Zeile mit den relevanten Systemdaten wie Kernel, Host-Name und Datum. Eine weitere Zeile gibt an, wann der Timer »sysstat-collect« zuletzt neu gestartet wurde. Schließlich gibt es pro Stichprobe eine Zeile mit den Messwerten wie der Größe der Run Queue und der Prozessliste sowie den drei Werten für Load Average.

Ex-post-Analyse

Wie eingangs erwähnt, konzentriere ich mich hinsichtlich Sysstat auf Ex-post-Daten, also den Zustand eines Systems in der Vergangenheit. Für den Zugriff auf die letzten beiden Tage kennt Sar die Schalter »-1« und »-2«, also gestern und vorgestern. Egal, welchen Sensor ich unter die Lupe nehme: »sar -1« liefert mir die Daten des Vortags.

Liegen die Messdaten weiter zurück, bleibt mir nichts anderes übrig, als die entsprechend benannten Dateien anzugeben. Das klappt mithilfe des Arguments »-f«. Will ich etwa explizit die Statistiken vom 8. Januar sehen, lege ich die Quelldatei so fest wie in der ersten Zeile von Listing 2.

$ sar -f /var/log/sysstat/sa08A [...]
$ sar -f /var/log/sysstat/sa08 -s 23:30:00 -e 23:55:00 [...]
$ sar -f /var/log/sysstat/sa07 -s 23:30:00 -e 23:55:00 -P ALL
$ sar -f /var/log/sysstat/sa07 -s 23:30:00 -e 23:55:00 -P 1,2

Mit dem Filtern nach bestimmten Tagen ist es jedoch oft nicht getan. Meist muss ich unbedingt über ein Zeitintervall filtern. Dazu gebe ich Sar die Schalter »-s [hh:mm:ss]« für den Startzeitpunkt und »-e [hh:mm:ss]« für den Endzeitpunkt mit. Die Messdaten vom 8. Januar zwischen 23:30:00 Uhr und 23:55:00 Uhr fördert das Kommando aus der zweiten Zeile von Listing 2 zutage.

Der Befehl liefert neben der obligatorischen Kopfzeile drei Datensätze. Mein Systemd-Timer ist auf eine 10-Minuten-Periode eingestellt, was die Zeiten der Stichproben erklärt. Zudem finden sich die Messgrößen »user«, »nice«, »system«, »iowait«, »steal« und »idle«. Wenig überraschend sehen Sie unter »user« den Anteil der CPU-Auslastung, der auf Prozesse im User-Space abfällt. Dasselbe gilt für »nice«, mit der Einschränkung, dass lediglich die Prozesse mit eigenem Nice-Level einfließen.

»system« zeigt die Auslastung durch den Kernel, also die Zeit, die für den Hardwarezugriff oder für Software-Interrupts anfällt. Beim Zugriff auf Hardware können sich Wartezeiten ergeben, die wiederum unter »iowait« auftauchen. Daneben protokolliert »steal«, wie hoch der Anteil unfreiwilliger Wartezeiten liegt. Sie fallen zum Beispiel an, wenn es sich um eine virtuelle Maschine handelt und der Hypervisor die CPU-Zeit anders verteilt. Zuletzt gibt »idle« Auskunft über die Zeit, in der sich die CPUs im Leerlauf befinden und keine I/O-Operationen anstehen.

Ohne weitere Angaben liefert Sar die CPU-Auslastung, allerdings nur auf die Gesamtheit aller CPUs bezogen. Möchten Sie einzelne CPUs oder Kerne betrachten, aktivieren Sie das mit dem Schalter »-P«. Mithilfe des Kommandos aus der dritten Zeile von Listing 2 lassen Sie sich den Zustand sämtlicher Kerne anzeigen, über das Kommando aus Zeile 4 nur den der Kerne 1 und 2.

Analog zu Top zeigt Sar die Average Load an. Prinzipiell eignet sie sich hervorragend als Kennzahl, um einzuschätzen, ob ein System richtig skaliert ist. Liegt die durchschnittliche Systemlast im Mittel deutlich über der Anzahl der CPU-Kerne, haben Sie es mit einer Überlast zu tun. Beläuft sie sich dagegen überwiegend auf etwa Null, ist das System möglicherweise überdimensioniert, und Sie könnten darüber nachdenken, ihm Ressourcen zu entziehen. Wie die Average Load genau zu interpretieren ist, lesen Sie in einer früheren Folge von Admin-as-a-Service [1] nach.

Wie Abbildung 1 veranschaulicht, kann Sar eine beachtliche Menge an Details zur Systemlast ausgeben. Die Run-Queue (»runq-sz«) zeigt an, dass es über den Nachmittag kaum zu erhöhter Last kam. Die Anzahl der Prozesse (»plist-sz«) liegt mit rund 350 recht hoch, was hier aber Absicht ist. Es handelt sich hauptsächlich um PHP-Server-Prozesse, die als Spare Servers bereitstehen, um Anfragen so schnell wie möglich abarbeiten zu können. Die Maschine verfügt über vier Kerne und ist mit einer durchschnittlichen Systemlast von 0,55 sehr moderat ausgelastet.

Abbildung 1: Die durchschnittliche Systemlast fällt am Nachmittag moderat aus.

Arbeitsspeicher

Das RAM gilt ebenfalls als unverzichtbare Messgröße. Über die Belegung gibt der Befehl »sar -r« Auskunft. Sar verwendet dafür die Einheit »kB«, die sich auf modernen Systemen schwer lesen lässt. Die Felder sind sprechend benannt: »kbmemfree« zeigt logischerweise den freien Speicher an, »%memuser« den belegten Speicher in Prozent. Die einzelnen Werte beschreibt allesamt die Manpage.

Eine schlechte Performance muss nicht zwingend an knappem RAM oder zu wenig CPU-Leistung liegen. Prüfen Sie mittels Sar oder Top die CPU-Auslastung sowie den Speicherverbrauch. Befinden Sie beides für in Ordnung und wundern Sie sich trotzdem über eine hohe Load Average, erweist sich oft eine niedrige I/O-Rate als das Problem. Muss der Kernel immer wieder auf langsamen Festspeicher warten, vor allem bei Datenbankanwendungen, dann nützen die schnellsten Prozessoren nichts.

Sar gibt die aktuellen I/O-Indikatoren mit »sar -b« aus. Die Kenngröße »tps« misst die Transfers pro Sekunde, »rtps« und »wtps« differenzieren Lese- und Schreibvorgänge. Die Anzahl der gelesenen Bytes pro Sekunde nennt »bread/s«, analog bezeichnet »bwrtn/s« die geschriebenen Bytes pro Sekunde.

Zeigen sich die I/O-Werte ebenfalls unauffällig – sprich: sind die Werte für »tps« nicht deutlich schlechter als gewohnt –, kann sich zudem das Netzwerk als Flaschenhals herausstellen. Ungünstige Werte für »rsize« und »wsize« bei eingehängten NFS-Shares können die Performance stark beeinflussen. Das führt wiederum dazu, dass Prozesse einfrieren, die auf Netzwerkübertragungen warten.

kSar

Mit Textstatistiken kommen Sie schon recht weit, noch aussagekräftiger sind jedoch Graphen. Obwohl das Projekt inaktiv scheint, ist kSar [2] nach wie vor das Werkzeug der Wahl, um die Messdaten von Sar grafisch aufzubereiten. Das in Java geschriebene Tool erfordert zwingend die passende Laufzeitumgebung. Unter Debian und Ubuntu installieren Sie kurzerhand mit »sudo apt install default-jdk« eine passende Entwicklungsumgebung. Es ergibt wenig Sinn, kSar auf Server-Systemen zu installieren, da es einerseits eine grafische Oberfläche benötigt und Sie es außerdem auf potenziell jedem System benötigen. Auf der persönlichen Workstation ist es dementsprechend gut aufgehoben.

Das Hauptfenster wirkt auf den ersten Blick spartanisch. Den Einstiegspunkt bildet das Menü Data: Hier lesen Sie aus lokalen Dateien, nutzen die Ausgabe lokaler Kommandos oder die Ausgabe von Remote-Befehlen über SSH. Die SSH-Verbindung bringt mich allerdings nicht weiter, da sie nur Passwortauthentifizierung implementiert und meine Systeme gänzlich per Public Key authentifizieren. Üblicherweise schreibe ich mir kurze Shell-Skripte, die die SSH-Verbindung per Key aufbauen und das jeweilige Kommando auf dem Ziel-Host ausführen (Listing 3).

#!/bin/bash
ssh thomas@raspi02 'LC_ALL=C sar -A -f'

Den Pfad zum Skript gebe ich als Local Command ein und bestätige mit OK. Daraufhin fragt mich kSar nach dem Date Format. Hier wähle ich DD/MM/YY 23:59:59, da die Automatic Detection offensichtlich Schwächen hat. Nach einem Mausklick auf OK füllt sich der Navigationsabschnitt links im Fenster von kSar (Abbildung 2). Über Klicks auf die Baumstruktur kann ich mir darüber hinaus die Graphen zur entsprechenden Sar-Abfrage anschauen, ohne umständlich Dateien von Servern kopieren zu müssen.

Abbildung 2: kSar zeigt übersichtliche Graphen mit sämtlichen relevanten Daten zu den unterschiedlichen CPUs.

Fazit

Für sich alleine genommen, bringen viele der durch Sar ermittelten Messwerte letztlich wenig. Vielmehr ist es die Statistik über den Lauf der Zeit, mit deren Hilfe sich die Werte vergleichen lassen. Dementsprechend ist es absolut sinnvoll, eine grafische Auswertung für den Sollzustand anzufertigen. Mit dieser Grundlage lassen sich später leicht Anomalien feststellen und mit Log-Dateien korrelieren. (csi)