© SV Luma, 123RF

Laufende Programme verraten nur selten, was sie tatsächlich im Hintergrund anstellen. Glücklicherweise verfolgen pfiffige Werkzeuge das Treiben und protokollieren die aufgerufenen Systemfunktionen. Die vorgestellten Debugger sind für Programmierer und Administratoren gleichermaßen interessant.

Gleich eine ganze Werkzeugklasse hat es sich zur Aufgabe gemacht, die Abläufe und Funktionsaufrufe fertiger Programme und mitunter sogar des kompletten Systems aufzuzeichnen. Die dabei entstehenden Protokolle heißen Traces. Programmierer können mit ihnen rasch nachvollziehen, welche Funktionsaufrufe und Aktionen geradewegs zu einem Fehler oder Abbruch führen. Wiederholte Einträge in den Protokollen weisen zudem auf Race Conditions und Deadlocks hin. Die Debugger helfen ebenfalls beim Reverse Engineering und geben angehenden Kernelentwicklern einen Einblick in typische Abläufe zwischen Userspace und Betriebssystemkern.

Auch Administratoren nutzen die Tools, um herauszufinden, was im System im Einzelnen vorgeht. Die Traces helfen ihnen dabei, verdächtiges Verhalten unter die Lupe zu nehmen. Um beispielsweise herauszufinden, welches Programm regelmäßig mehrere GByte große temporäre Dateien produziert, beobachten sie mit den Debuggern alle Aufrufe der Systemfunktion »open()« und zeichnen sie auf. Ein Blick in die Ausgabe der Debugger gibt anschließend Hinweise auf den Übeltäter.

In dieser Bitparade treten Strace [1], LTTng [2], Systemtap [3] und Dtrace [4] an. Den Auftakt macht der Klassiker, danach folgen die etwas mächtigeren Tools und Dtrace ist das neueste Werkzeug im Test. Alle Kandidaten klinken sich in den Linux-Kernel ein, beobachten dadurch weite Teile des Systems und behalten so etwa auch die Sockets im Auge.

Teilweise schneiden die Debugger den Netzwerkverkehr mit und protokollieren die Prozessorlast beziehungsweise die Rechenzeit einzelner Aktionen. So dienen sie als Profiler für Entwickler und liefern Admins einen Hinweis auf Performance-Engpässe und Flaschenhälse. Den Quellcode der zu inspizierenden Anwendung oder des Kernels benötigen sie nicht – die Analyse funktioniert auf jedem beliebigen Linux-System.

Strace

Zusammen mit den Entwicklerwerkzeugen landet bei fast allen großen Distributionen automatisch das kleine Werkzeug Strace [1] auf der Festplatte. Es protokolliert schlichtweg alle Systemaufrufe (System Calls) einer Anwendung. Dazu übergibt der Anwender auf der Kommandozeile das zu analysierende Programm, in folgendem Beispiel »test« :

strace -o aufrufe.txt ./test

Strace startet es und protokolliert im Standardfehlerkanal (Stderr) alle vom Programm aufgerufenen Systemfunktionen – einschließlich ihrer Parameter und Rückgabewerte – sowie alle vom zugehörigen Prozess empfangenen Signale. Um die Strace-Aufzeichnungen besser analysieren zu können, lenkt der Parameter »-o« sie in eine Textdatei um. Der Debugger setzt über die Aufrufoption »-p« an einem laufenden Prozess wie etwa einem Daemon an.

Abbildung 1 zeigt ein Strace-Ergebnis. In den letzten Zeilen ist gut zu erkennen, dass das kleine C-Programm aus Listing 1 eine Textdatei öffnet, »Hallo Welt!« hineinschreibt und die Datei wieder schließt. Strace protokolliert auch die zahlreichen Speichermanipulationen und die Aufrufe des dynamischen Linkers. In der Informationsflut kann es mitunter recht mühsam sein, die für einen Fehler verantwortlichen Funktionen herauszufischen. Der strikte und einfache Aufbau der Strace-Ausgabe ermöglicht es Anwendern allerdings, sie mit anderen Tools weiterzuverarbeiten und beispielsweise mit Grep nach bestimmten Funktionsaufrufen zu fahnden.

01 #include <stdio.h>
02 #include <stdlib.h>
03
04 int main()
05 {
06    FILE *datei;
07
08    /* Datei öffnen */
09    datei = fopen("hallo.txt", "a");
10
11    /* Text in Datei schreiben */
12    fprintf(datei, "Hallo Welt!");
13
14    /* Datei schließen */
15    fclose(datei);
16 }

Abbildung 1: Strace protokolliert alle Systemaufrufe, darunter auch die Speichermanipulationen und das Laden dynamischer Bibliotheken.

Strace selbst bietet nur ein paar einfache Filter. So landen beispielsweise mit dem folgenden Kommando ausschließlich die Aufrufe der Systemfunktionen »open()« und »close()« im Protokoll:

strace -e trace=open,close ./test

Ergänzend wirft der Parameter »-c« eine kleine Statistik aus (siehe Abbildung 2). Der Debugger liefert nicht nur Informationen zu den in den Funktionen genutzten Zeigern, sondern versucht auch sie zu dereferenzieren und die tatsächlichen Werte in das Protokoll zu schreiben. Teilt sich die zu analysierende Anwendung in mehrere Prozesse auf, schreibt er die zugehörige PID vor jeden Protokolleintrag. Auf Wunsch setzt Strace vor jeden Funktionsaufruf einen Zeitstempel und gibt so erste Hinweise auf kriechende Codepassagen.

Abbildung 2: Strace listet in dieser Statistik auf, welche Funktionen das Programm »test« wie oft aufgerufen hat und wie viele Fehler es dabei gab.

Da Strace lediglich die Systemaufrufe liefert, also die von einem Programm im Kernel aufgerufenen Funktionen erfasst, greifen Anwender am besten zu Ltrace (siehe Kasten “Ltrace”), um die dynamisch hinzugelinkten Bibliotheken zu beobachten – statische bleiben außen vor. So spüren sie Fehler auf, die durch fehlende oder falsche Shared Libraries entstehen.

Ltrace

Ltrace [5] arbeitet im Prinzip ähnlich wie Strace, sogar die Aufrufsyntax und die mitgelieferten Parameter sind oft gleich. Beim Aufruf übergeben die Anwender ebenfalls das Programm, das sie untersuchen möchten: »ltrace ./test« .

Das Ergebnis sieht ähnlich aus wie bei Strace, nur dass Ltrace ausschließlich Funktionsaufrufe aus dynamischen Bibliotheken listet (Abbildung 3). Auf Wunsch notiert das Werkzeug auch nur die Ausgabe bestimmter Bibliotheken. Dank des Parameters »-S« protokolliert der Debugger genau wie Strace die Systemfunktionen und kennzeichnet diese im Trace jeweils durch vorangestelltes »SYS_« .

Abbildung 3: Wie Ltrace beweist, nutzt das kleine Programm »test« ausschließlich Funktionen aus der Standardbibliothek.

Der Debugger konzentriert sich hauptsächlich auf die dynamisch hinzugelinkten Bibliotheken. Das Tool tritt daher in diesem Test nur außer Konkurrenz an und empfiehlt sich vor allem als Ergänzung zu Strace.

LTTng

Seit 2005 gibt es das “Linux Trace Toolkit next generation”, kurz LTTng [2]. Es liegt mittlerweile vielen größeren Distributionen bei; aktuell ist Version 2.0. Der Debugger klinkt sich mit einem Kernelmodul in den Linux-Kern ein, ein Daemon erfasst die vom Modul gesammelten Informationen. Anwender steuern den Daemon mit dem Clientprogramm »lttng« auf der Shell.

Um alle Aufrufe der Systemfunktion »sys_open()« mitzuschneiden, öffnen Anwender zunächst mit »create« eine neue Sitzung und teilen LTTng mit, die Funktion zu observieren. Ein dritter Befehl startet die eigentliche Aufzeichnung. Alle Kommandos benötigen Rootrechte:

lttng create sitzung
lttng enable-event --kernel sys_open --probe sys_open+0x0
lttng start

Sind alle Daten notiert, weisen Anwender den Debugger über zwei weitere Befehle dazu an, die Aufzeichnung zu stoppen und die Sitzung zu beenden:

lttng stop
lttng destroy

LTTng trägt Daten zu bestimmten Kernelereignissen zusammen oder meldet das Erreichen von im Kernel enthaltenen Tracepoints. Die dabei entstehende Datenmenge dürfen Nutzer direkt in LTTng nicht selbst (beispielsweise über Skripte) einstellen – sie erhalten also stets alle oder keine Informationen. Immerhin ist es über so genannte Kontexte möglich, Dinge detaillierter zu erfassen und beispielsweise die PID des auslösenden Prozesses oder die Anzahl der CPU-Takte für ein Ereignis zu notieren.

Der Debugger beobachtet optional auch Programme im Userspace – vorausgesetzt der Anwender hat diese darauf vorbereitet. Wie das funktioniert, haben die LTTng-Entwickler zwar notiert, die Information aber an zahlreichen Stellen in der Dokumentation und in den Beispielen im Quellcode verteilt, sodass es etwas mühsam ist, entsprechende Hinweise aufzustöbern.

Seinen eigenen Programmcode spickt der Benutzer mit Tracepoints, also Punkten, deren Erreichen LTTng später aufzeichnen soll. Alle dazu notwendigen Funktionen stellt die Bibliothek »lttng-ust« bereit, die der Anwender dem Programm folgerichtig hinzulinken muss. Das weitere Vorgehen verläuft analog zur Abfrage des Kernels. So registriert der folgende Befehl beispielsweise alle Tracepoints im Userspace:

lttng enable-event -a -u

Rootrechte sind für die Analyse im Userspace nicht erforderlich, wenn es sich um selbst aufgerufene Programme handelt. Anwendungen unter einer anderen Benutzerkennung verlangen wiederum den Admin-Status.

Externe Mitarbeiter

Alle gesammelten Informationen schreibt LTTng als CTF-Dateien [6] ins Verzeichnis »~/lttng-traces« . Dort sortiert es sie in Unterverzeichnisse ein, die den Namen der Sitzung und einen Zeitstempel tragen. Zum Auswerten der Protokolle ist noch ein weiteres Programm erforderlich, im einfachsten Fall das Kommandozeilenwerkzeug Babeltrace [7], das CTF in Text umwandelt:

babeltrace $HOME/lttng-traces/sitzung-20121030-164708 | less

Je nachdem, welche Ereignisse der Debugger notiert hat und wie lange die Beobachtung lief, ergießt sich nun eine wahre Informationsflut ins Terminal (siehe Abbildung 4). Anwender filtern und durchsuchen den Text mit den gängigen Shellwerkzeugen.

Abbildung 4: Die von LTTng produzierten Traces sind ohne Hilfsmittel und externe Programme nur schwer zu interpretieren.

Die LTTng-Homepage nennt als alternative Hilfsprogramme LTTV (Linux Trace Toolkit Viewer, [8]) und ein Eclipse-Plugin [9]. Beide Werkzeuge sind sozusagen Work in Progress – die Anpassung an die neue LTTng-Version 2.0 läuft noch. LTTV nutzt zwar die Babeltrace-Bibliotheken, ließ sich im Test aber nicht dazu überreden, CTF-Dateien anzuzeigen. Das Eclipse-Plugin implementiert eine eigene CTF-Bibliothek in Java und visualisierte die LTTng-Traces hingegen problemlos (siehe Abbildung 5).

Abbildung 5: LTTng arbeitet über ein Plugin mit Eclipse zusammen. Im Test hat der Debugger zunächst ein paar Sekunden den Kernel belauscht, Eclipse zeigt hier den entstandenen Trace an.

Systemtap

Einen Schritt weiter als LTTng geht Systemtap [3], das gleich das ganze Linux-System beobachtet. Es klinkt sich in den Kernel ein und protokolliert vom Nutzer ausgewählte Ereignisse oder Systemaufrufe. Mit Systemtap kommen Anwender daher auch komplexen Performanceproblemen oder Fehlfunktionen auf die Schliche. Derzeit beteiligen sich vor allem Red Hat, IBM, Hitatchi und Oracle an der Entwicklung des Debuggers, der allen großen Distributionen beiliegt.

Die Nutzer beschreiben in eigenen Skripten, welche Ereignisse Systemtap im Auge behalten soll. Dazu verwenden sie die Systemtap-eigene Skriptsprache, die an C und AWK erinnert. Die fertigen Skripte mit der Endung ».stp« führt dann das Werkzeug »stap« aus. Es wandelt sie zunächst in C-Code um, erzeugt daraus ein Kernelmodul und lädt es.

Damit das funktioniert, betreiben Anwender das Programm entweder mit Rootrechten oder tragen den entsprechenden Account in die Gruppe »stapdev« ein. Darüber hinaus benötigt Systemtap die Debuginformationen des Kernels. Je nach Distributionen installieren Anwender dazu ein einziges Paket nach oder aktivieren wie unter Ubuntu gleich ein komplettes Repository [10].

Ereignisreich

Jedes Systemtap-Skript bestimmt, auf welche Ereignisse der Debugger mit welchen Aktionen reagieren soll. Listing 2 zeigt ein einfaches Beispiel, das 4 Sekunden lang alle Aufrufe der Systemfunktion »open« aufzeichnet. Dazu registriert es drei Ereignisse, die jeweils hinter »probe« stehen. Beim Start tritt automatisch das Ereignis »begin« ein. Die Aktionen, die Systemtap abarbeiten soll, stehen in den geschweiften Klammern.

01 probe begin
02 {
03    print ("Start Aufzeichnung\n")
04 }
05
06 probe kernel.function("sys_open")
07 {
08    printf ("Prozess: %s [PID: %d] Datei: %s\n", execname(), pid(), $filename$)
09 }
10
11 probe timer.ms(4000) # nach 4 Sekunden
12 {
13    print ("Ende Aufzeichnung\n")
14    exit ()
15 }

Listing 2 schreibt »Start Aufzeichnung« auf die Standardausgabe. Das zweite Ereignis »kernel.function(“sys_open”)« tritt immer dann ein, wenn ein Programm die Systemfunktion »open()« aufruft. Im Listing gibt Systemtap nur den Namen des aufrufenden Programms (»execname()« ), dessen PID (»pid()« ) und den Namen der betroffenen Datei (»$filename$« ) aus. Selbstverständlich dürfen Anwender weitere Informationen hinzusetzen, etwa die übergebenen Argumente oder den Zugriffsmodus.

Die Funktion »printf()« nutzt übrigens die Syntax der gleichnamigen C-Funktion. Sind 4 Sekunden nach dem Skriptstart verstrichen, greift schließlich das dritte Ereignis. Die zugehörige Anweisung »exit()« beendet das Skript und somit die Aufzeichnung.

Einen Beispiellauf zeigt Abbildung 6. Systemtap gibt selbst einige Ereignisse vor. Weitere rüstet eine beiliegende Bibliothek nach. Sie enthält eine Sammlung von Systemtap-Skripten, den so genannten Tapsets. Sie erlauben es, sich in fast alle Bereiche des Kernels einzuhängen und damit sogar den Netzwerkverkehr aufzuzeichnen. Soll dafür beispielsweise ein Skript länger mitlaufen, verbannen Nutzer es über den “Flight Recorder Mode” als Daemon in den Hintergrund.

Abbildung 6: Ein Systemtap-Skript beobachtet in einer virtuellen Maschine unter Virtualbox 4 Sekunden lang die Systemfunktion »open()«.

Die Systemtap-Skriptsprache ist sehr mächtig. So dürfen Anwender beispielsweise Zwischenergebnisse in Variablen parken, »if« -Abfragen sowie »while« – und »for« -Schleifen einsetzen. Häufig benötigte Anweisungen fassen sie in Funktionen zusammen. So genannte Aggregates helfen statistische Daten zu einem einzelnen, aussagekräftigen Wert zu gruppieren. So zählt der Debugger zum Beispiel, wie viele GByte ein Programm von der Festplatte geladen hat.

Da Systemtap ein Kernelmodul erstellt, dürfen die Skripte sogar C-Code enthalten. Zahlreiche Beispielskripte finden Interessenten in der Dokumentation und im Wiki auf der Projekthomepage. Sie zeigen unter anderem, wie man Systemtap zum Profiling einsetzt oder Call-Graphen erstellt. Diese Graphen machen anschaulich, welche Funktionen andere Funktionen wann aufgerufen haben.

Auch im Userspace

War der Debugger ursprünglich dazu gedacht, ausschließlich den Kernel zu überwachen, stürzt er sich mittlerweile auch auf Userspace-Programme. Das geht so weit, dass das Werkzeug ein Ereignis auslösen kann, wenn beispielsweise ein Programm namens »hallo« in seinem Quellcode »test.c« die sechste Zeile erreicht hat. Das zugehörige Ereignis sieht dann so aus:

process("/home/tim/hallo").statement("*@test.c:6")

Dazu muss allerdings das Programm »hallo« mit Debuginformationen gespickt sein, wie sie beispielsweise »gcc« über den Parameter »-g« einwebt. Wer als Administrator ein bestehendes Programm wie etwa »ls« unter die Lupe nehmen möchte, der muss die Debuginformationen also erst nachinstallieren. Im Fall von »ls« beispielsweise liegen diese oft schon in einem Paket namens »coreutils-debuginfo« vor.

Darüber hinaus muss der Kernel die Utrace-Schnittstelle anbieten [11], was nur dann der Fall ist, wenn beim Übersetzen die Option »CONFIG_UTRACE« eingeschaltet war. Anwender überprüfen dies schnell auf der Kommandozeile:

grep CONFIG_UTRACE /boot/config-`uname -r`

Erscheint keine Meldung, dann kann Systemtap keine Userspace-Programme analysieren. In den Voreinstellungen unter Debian, Ubuntu und Open Suse ist das der Fall.

Einige Programme, darunter MySQL und PostgreSQL sowie einige Skriptsprachen wie Python, unterstützen Systemtap von Haus aus. Sie enthalten so genannte Marker, deren Erreichen ein Systemtap-Skript abfangen kann. Auf diese Weise lässt sich etwa jeder Start eines MySQL-Query protokollieren [12].

Außerdem existieren Frontends für die Zusammenarbeit mit anderen Werkzeugen. Besonders interessant sind die Eclipse-Plugins des Linux Tools Project: Die Systemtap-Erweiterung rüstet einen Editor mit Syntax Highlighting und Codevervollständigung für Systemtap-Skripte nach [13], während das Callgraph-Plugin den von Systemtap erzeugten Call-Graphen visualisiert [14].

Dtrace

Das ursprünglich von Sun für das Betriebssystem Solaris entwickelte Programm Dtrace [4] arbeitet ähnlich wie Systemtap. Nutzer schreiben für diesen Debugger ebenfalls Skripte in einer C-ähnlichen Sprache namens D. Diese ist allerdings eine Eigenkreation der Dtrace-Macher und nicht verwandt mit der offiziellen Programmiersprache D. Ein Dtrace-Skript gibt vor, auf welche Ereignisse der Debugger mit welchen Aktionen reagieren soll.

Listing 3 zeigt ein Beispiel, das genau wie Listing 2 alle Aufrufe der Systemfunktion »open()« protokolliert. Dabei nennt es den Programmnamen (»execname« ) und den betroffenen Dateinamen (»copyinstr(arg0)« ). Einen Beispiellauf demonstriert die Abbildung 7. Über 200 fertige Dtrace-Skripte aus verschiedenen Anwendungsbereichen fasst das Dtrace-Toolkit zusammen [15].

01 BEGIN
02 {
03    printf("Start Aufzeichnung");
04 }
05
06 syscall::open*:entry
07 {
08    printf("%s %s",execname ,copyinstr(arg0));
09 }
10
11 profile:::tick-4sec
12 {
13    trace("Ende Aufzeichnung");
14    exit(0);
15 }

Abbildung 7: Dtrace garniert die Skriptausgaben mit weiteren Informationen und packt sie in eine Art Tabelle. Der Output steht in der rechten Spalte.

Dtrace verwendet eine recht eigenwillige Terminologie: Was Systemtap als Ereignisse kennt, bezeichnet Dtrace als Probe (häufig mit Prüfpunkt oder Prüfsonde übersetzt). Die Probes stellen im Kernel wiederum so genannte Provider bereit. So liefert der Syscall-Provider beispielsweise Probes für das Aufrufen und Beenden von Systemfunktionen. Der Prüfpunkt »open*:entry« tritt immer dann ein, wenn ein Userspace-Programm die Funktion »open()« aufruft, wie in Listing 3 zu sehen ist.

Alle verfügbaren Probes eines Systems listet der Befehl »dtrace -l« auf. Auf einem der Testrechner waren das über 290 000 Einträge. Anders als Systemtap kennt dieser Testkandidat keine Schleifen und »if« -Abfragen. Dtrace kann lediglich Probes unter bestimmten Bedingungen eintreten lassen. Die Entwickler wollen mit dieser Design-Entscheidung unter anderem Endlosschleifen verhindern. Im Gegenzug bietet das Tool etwas flexiblere Aggregates.

Fertige Skripte starten Nutzer mit dem Kommandozeilen-Programm »dtrace« , das Skripte in eine Art Zwischencode übersetzt, den dann ein Interpreter innerhalb des Kernels ausführt. Dadurch kann Dtrace auch Laufzeitfehler im Skript abfangen, etwa eine Division durch 0. Über so genannte Privilegien vergeben Administratoren für andere Benutzer gezielt den Zugriff auf einzelne Funktionen des Debuggers, sodass nicht zwingend Rootrechte für den Betrieb nötig sind. Die Konfiguration der Rechte geschieht unter Linux in der Konfigurationsdatei »/etc/dtrace.conf« .

Auf Probe

Unter Linux ist Dtrace als optionales Kernelmodul verfügbar und nicht in den Kern integriert. Das liegt unter anderem an den verschiedenen Lizenzen. Während der Linux-Kernel unter der GPL steht, nutzt Dtrace die CDDL. Außerdem bietet die Linux-Portierung noch nicht den vollen Funktionsumfang des originalen Werkzeugs, auch wenn sie munter voranschreitet [16].

Die meisten Probes sind allerdings schon vorhanden und funktionieren. Durch Abwesenheit glänzen momentan noch solche, für deren Einführung die Entwickler den Kernelcode verändern müssten. Dazu gehören beispielsweise Prüfsonden, die unter Solaris jetzt schon den NFS-Verkehr analysieren, also insbesondere solche aus der Gruppe der “Statically Defined Tracing Probes”.

Die Linux-Version des Debuggers besitzt im Gegenzug schon jetzt einen Instruction Provider, der Instruction Level Tracing ermöglicht. Damit protokollieren Nutzer, welche Teile eines Programms ausgeführt wurden. Einen Überblick über die aktuellen Fähigkeiten von Dtrace unter Linux gibt die Datei »Status.txt« , die dem Dtrace-Quellcode-Archiv beiliegt oder unter [17] einsehbar ist.

Auch wenn Dtrace für Linux kontinuierlich Fortschritte macht, liegt es immer noch nicht in einer stabilen Fassung vor. Der für die Portierung verantwortliche Entwickler Paul D. Fox glaubt zwar, dass Anwender Dtrace bereits produktiv einsetzen können, übernimmt aber letztlich keine Garantie.

Zu allem Überfluss werkelt Oracle hinter halb verschlossenen Türen auch an einer eigenen Linux-Portierung, die laut Wim Coekaerts von Oracle recht weit gediehen ist [18], nach Aussage von Paul D. Fox aber einen geringeren Funktionsumfang als die von ihm betreute Variante bietet. All dies verhinderte bisher jedenfalls den Einzug von Dtrace in die Distributionen. Wer das Werkzeug einsetzen möchte, der muss es samt Kernelmodul also selbst erstellen.

Erfolgreich verfolgt

Strace und Ltrace sind unkompliziert in der Handhabung, dafür aber auch recht eingeschränkt im Funktionsumfang beziehungsweise spezialisiert auf ihre jeweilige Aufgabe: Strace zeichnet Systemfunktionen auf, Ltrace kümmert sich um dynamische Bibliotheken.

Systemtap klinkt sich bei Bedarf in beliebige Bereiche des Systems ein. Damit ist der Debugger zwar besonders flexibel und mächtig, erfordert allerdings auch die Einarbeitung in seine eigene Skriptsprache. Mit ihrer Hilfe lassen sich die gesuchten Informationen dann schon in Systemtap selbst bequem auswählen und aufbereiten, eine Nachbehandlung ist nicht notwendig. Zur Analyse von Userspace-Programmen muss der laufende Kernel allerdings Utrace unterstützen, was in der Voreinstellung nur selten der Fall ist.

Dtrace merkt man deutlich an, dass es sich noch am Anfang der Entwicklung befindet. Dazu passt die extrem karge und unvollständige Dokumentation der Linux-Portierung. Sofern nicht zwingende Gründe für den Einsatz dieses Debuggers sprechen, sollte man daher zumindest derzeit noch Systemtap den Vorzug geben. Dtrace macht aber auf anderen Betriebssystemen, darunter Free BSD, Mac OS X und Solaris, eine bessere Figur. Anwender, die in einem heterogenen Umfeld arbeiten, können folglich ihre Skripte mitnehmen beziehungsweise wiederverwenden.

LTTng hinkt der Konkurrenz etwas hinterher: Während die reine Kommandozeilennutzung die meisten nicht abschrecken dürfte, so ist doch die Auswertung der langen Traces nur mit externen Werkzeugen möglich. Die Dokumentation verdient derzeit ihren Namen nicht und ist eher eine Schnelleinführung. Wer LTTng kennenlernen möchte, der sollte in den Quellcode schauen. Programme im Userspace inspiziert der Debugger außerdem nur dann, wenn der Entwickler sie auf LTTng vorbereitet hat oder der Quellcode verfügbar ist.

Allen Werkzeugen gemeinsam ist, dass sie für ihren Einsatz zumindest Grundwissen über die Arbeitsweise des Kernels verlangen. Will der Anwender nicht in der selbst produzierten Datenflut versinken, dann sollte er zudem relativ genau wissen, wonach er sucht beziehungsweise wo sich im System ein Engpass oder Problem befindet. Andernfalls artet das Ganze zu einer sinnlosen Verfolgungsjagd aus.