Viele Diagnose-Tools verfügen über eine ganz spezielle Syntax. Das erschwert den Umgang und macht die Ausgabe unübersichtlich. Sysdig fasst die wichtigsten Vertreter unter einer einheitlichen Oberfläche zusammen.

Auf einem modernen Linux-System laufen zahlreiche Prozesse gleichzeitig. Es öffnet Dateien, schreibt darin Daten oder liest aus diesen, schließt sie wieder, öffnet neue und so weiter. Das belastet die CPU und andere Peripherie in unterschiedlicher Weise und führt womöglich zu Engpässen, die in manchen Fällen das gesamte System bremsen.

Um diese Flaschenhälse zu finden und zu beheben, kommen in der Regel Befehle wie top, ps, vmstat, strace oder lsof parallel oder in Kombination zum Einsatz. Die Ergebnisse der Werkzeuge dienen oft als Eingaben oder Parameter für weitere Tools, was nicht selten zu komplexen und unübersichtlichen Aktionen führt. Eine einheitliche und übersichtliche Syntax wäre hier eine willkommene Hilfe.

Hier kommt Sysdig [1] ins Spiel: Die Entwickler eines kleinen Unternehmens in San Francisco haben in ihm die in der Praxis am häufigsten eingesetzten Befehle zusammengefasst, und statteten das Tool mit einer programmierbaren Schnittstelle aus. Es versteht eine relativ große Anzahl von Optionen, die spezielle Eigenschaften steuern. Der Befehl sysdig --help listet die wichtigen davon auf.

Die zeilenweise Ausgabe besteht aus mehreren Teilen, den sogenannten Feldern. Die ersten beiden, evt.num und evt.time, kennzeichnen das beschriebene Ereignis (“event”) eindeutig mit einer Nummer und dem Zeitpunkt, zu dem es die Software registriert hat. Zusätzlich beschreibt evt.cpu die involvierte CPU bei Systemen mit mehreren CPUs.

Das Feld proc.name steht für den Prozess, thread.tid für den Thread. Mit evt.dir teilt die Software mit, in welche Richtung das Event arbeitet: “<” steht für eingehende Daten und “>” für ausgehende. Last, but not least klassifiziert evt.type das Ereignis als solches, wie read oder open. Die Argumente eines Events fasst evt.args zusammen.

apt-get -y install linux-headers-$(uname -r)

curl -s https://s3.amazonaws.com/download.draios.com/stable/install-sysdig | sudo bash

curl -s https://s3.amazonaws.com/download.draios.com/DRAIOS-GPG-KEY.public | sudo apt-key add -
curl -s -o /etc/apt/sources.list.d/draios.list http://download.draios.com/stable/deb/draios.list
sudo apt-get update

Praxis

Starten Sie Sysdig als Root ohne zusätzliche Optionen im Terminal, erhalten Sie augenblicklich eine Ausgabe in der Form, wie Listing 3 sie zeigt. Diesen Modus beenden Sie mit [Strg]+[C].

# sysdig
3 11:03:20.522466433 2 <NA> (0) > switch next=158(systemd-journal)
232 11:03:20.524714772 1 plugin-containe (5081) < futex res=-110(ETIMEDOUT)
286 11:03:20.533770002 0 firefox (4901) > mmap
338 11:03:20.536870106 0 firefox (4901) > poll fds=5:e1 4:u1 8:p3 10:u3 11:u1 23:p1 25:u1 timeout=0
387 11:03:20.537960783 2 Timer (5750) < futex res=-110(ETIMEDOUT)
2249 11:03:20.548869168 2 java (29547) < futex res=-110(ETIMEDOUT)
2266 11:03:20.551182910 0 emacs (16938) > writev fd=4(<u>) size=112
197129 11:03:21.241713273 3 Xorg (1757) < read res=72 data=.?.S.......

Das erste aufgezeichnete Ereignis trägt die Nummer 3 und stammt aus dem Prozess systemd-journal. Es folgt eines von vielen durch den als plugin-containe (die Ausgabe schneidet hier ein “r” ab) bezeichneten Prozess, den von Firefox eingebetteten Flash-Player und dann Firefox selbst, der eine Reihe Events generiert.

Interessant ist dabei unter anderem, dass Firefox eine andere CPU nutzt, als der Container. In der letzten Zeile des Listings mit der Zeichenkette data= sehen Sie zahlreiche Punkte. Sysdig schreibt diese stellvertretend für nicht darstellbare Zeichen in die Ausgabe. Das ändern Sie bei Bedarf durch Optionen wie -A, mit dem Sie das Programm anweisen, nur ASCII-Zeichen auszugeben.

Wenn Sysdig schon innerhalb einer Sekunde knapp 20?000 Events aufzeichnet, ist klar, dass der sinnvolle Einsatz der Software einen leistungsfähigen Filter erfordert, der die Ausgaben auf die gewünschten Ereignisse beschränkt. Sie hängen die Angaben zum Filtern nach den Optionen an das Kommando an. Listing 4 zeigt, wie Sie die Ausgabe auf das Ereignis read reduzieren.

# sysdig evt.type=read
152839 13:02:03.673561027 3 pulseaudio (4360) < read res=2 data=WW
152840 13:02:03.673561173 2 threaded-ml (3223) > read fd=23(<p>pipe:[1593199]) size=10

Chisels

Viele komplexe Angaben, etwa die Prozesse mit den meisten Ein- und/oder Ausgaben, gibt das System nicht direkt preis. Es gilt, diese durch Zusammenfassen von Informationen und mittels statistischen Methoden zu ermittelt. Das und vieles mehr geschieht über sogenannte Chisels. Dabei handelt es sich um etwa zwei KByte große Lua-Skripte, die Sysdig selbst aufruft. Die Option -c Chisel-Name aktiviert ein solches.

So analysiert das Beispiel aus Listing 5 die langsamsten Systemaufrufe. Dazu startet Sysdig zunächst eine Datensammlung und beendet diese, sobald Sie das Programm stoppen. Dann erfolgt das Auswerten der gesammelten Daten und deren Ausgabe. Wieder fällt der Flash-Player auf, der neben dem Java-Programm die meisten Ressourcen beansprucht und das System verlangsamt.

# sysdig -c bottlenecks
89898) 0.000000000 plugin-containe (5080) > futex addr=7FAB265B1DA4 op=137
170611) 1.000095651 plugin-containe (5080) < futex res=-110(ETIMEDOUT)
170597) 1.000069882 plugin-containe (16961) < futex res=-110(ETIMEDOUT)
89454) 0.000000000 java (29540) > futex addr=7F400C252F54 op=393
135393) 1.000024874 java (29720) < futex res=-110(ETIMEDOUT)

Viele Chisels benötigen zusätzliche Argumente, etwa eine zu überwachende IP-Adresse oder einen Port. Diese geben Sie direkt nach dem Chisel an, etwa sysdig -c spy_ip IP-Adresse. Bei der Installation kopiert Sysdig die Chisels ins Verzeichnis /usr/share/sysdig/chisels/. Dank der relativ einfachen Struktur eignen sie sich als Vorlagen für eigene Entwicklungen.

Der Aufruf sysdig -cl zeigt die in sechs Kategorien geordneten, vorhandenen Chisels an, mit denen Sie die Auslastung von CPU und Netzwerk untersuchen, den Durchsatz ermitteln, die Performance des Gesamtsystems analysieren, Sicherheitschecks machen und Fehleranalysen fahren. Die meisten Kategorien enthalten mehrere unterschiedliche Varianten von Chisels, die spezielle Aussagen erlauben.

Filtern

Wie erwähnt, erlaubt Sysdig es, die Ausgaben auf die wirklich relevanten Informationen einzugrenzen. Dazu geben Sie in der Befehlszeile die für Sie relevanten Events an: evt.type=open. Es gibt eine große Anzahl von Events, die Tabelle “Wichtige Felder” fasst einige der gängigsten zusammen. Über den Aufruf sysdig -l sehen Sie alle Events.

Mehrere Felder, die im Prinzip als Variablen für die Ausgaben arbeiten, kombinieren Sie durch logische Ausdrücke mittels and oder schränken sie über contains Muster ein. In diesem Fall muss das angegebene Muster in den Daten des Feldes vorkommen, damit Sysdig sie ausgibt.

Speziell bei numerischen Daten stehen oft nur bestimmte Werte-Bereiche im Vordergrund. Diese grenzen Sie bei Bedarf genauer ein (siehe Tabelle “Operatoren”).

Als weitere Möglichkeit bietet Sysdig an, die Operatoren durch runde Klammern zu gruppieren und mittels not zu negieren. Mit or erlaubt ein logisches ODER. Das setzt aber voraus, dass Sie die Ausdrücke in der Shell maskieren, indem Sie diese zwischen doppelte Hochkommata stellen. Ein Beispiel aus der Dokumentation zeigt dies:

sysdig "not (fd.name contains /proc or fd.name contains /dev)"

Nicht immer ist es notwendig oder sinnvoll, die von Sysdig erhobenen Daten direkt auszuwerten. Manchmal bietet es sich an, die gewonnenen Daten zunächst zwischenzuspeichern und anschließend auf unterschiedliche Weise zu analysieren.

Das Speichern von ungefilterten Ausgaben in eine Datei erledigen Sie über die Option -w Datei. Die Entwickler schlagen für diese Dateien das Suffix .scap vor. Der Aufruf von sysdig -r Datei liest die gesammelten Daten ein; die gewünschten Optionen zum Filtern hängen Sie ans Ende der Befehlszeile an.

Beispiele

Sysdig gibt sich als echtes Werkzeug für die Praxis: Viele seiner Funktionen lernen Sie beim Bedienen der Software, anderes erschließt sich nur durch die Dokumentation in Form der Manpage oder aus dem Wiki [3]. Oft ist es aber einfacher, sich einige Beispiele anzuschauen und diese den eigenen Anforderungen entsprechend anzupassen. Listing 6 zeigt den Einsatz von Sysdig bei der Analyse von Prozessen.

# sysdig -c topprocs_file
Bytes     Process
------------------------------
464.00KB  java
43.45KB   nemo
8.76KB    panel-29-system
8.03KB    guake
6.04KB    free
5.20KB    pool
2.25KB    xfce4-netload-p

Der Aufruf sysdig -c proc_exec_time zeigt die Prozesse, die momentan am meisten Zeit beim Ausführen beanspruchen. Als Ersatz für Strace zum Verfolgen von Ein- und Ausgaben verwenden Sie echo_fds (Listing 7).

# sysdig -c echo_fds
------ Read 128B from /dev/ptmx
....[31m--- Read 32B from ...$.s....L....[31m---...[31m--- Read 128B
------ Write 128B to /dev/pts/1
....[31m--- Read 32B from ...$.s....L....[31m---...[31m--- Read 128B
------ Read 128B from /dev/ptmx

Entspricht die Performance des Systems nicht den Erwartungen, zeigt sysdig -c bottlenecks die langsamsten Systemaufrufe. Mit sysdig -c topscalls finden Sie die momentan am häufigsten verwendeten System Calls. Gibt es Dateien, bei denen besonders oft Wartezeiten entstehen, findet sysdig -c fileslower 9 sie heraus.

Welche Dateien die meiste Zeit für das Lesen und Schreiben benötigen, zeigt sysdig -c topfiles_time, wohin das System die meisten schreibt, ermittelt sysdig -c topfiles_bytes. Die Ausgabe von sysdig -c topprocs_file zeigt an, welche Prozesse das machen. Welche davon das Netz verlangsamen, ermitteln Sie mit sysdig -c topprocs_net. Eine Reihe weiterer Beispiele finden Sie online [4].

Fazit

Sysdig empfiehlt sich uneingeschränkt als Ersatz für die vielen einzelnen Programme zum Analysieren des Systems. Das Konzept, ein einfaches Programm mit vielen Möglichkeiten durch Plugins zu erstellen, entspricht dem Trend der Zeit.

Die von Sysdig ermittelten Ergebnisse sind durchweg nützlich. Wahrscheinlich findet es sich demnächst in einigen Repositories großer Distributionen. Bisher löst das Projekt die Installation noch etwas unorthodox. Allerdings: Den maximalen Nutzen ziehen Sie aus dieser Software, wenn Sie deren Ergebnisse richtig deuten. Fehlt hier das Wissen, führt die Ausgabe mitunter zu Verwirrung.