Tools für einfacheres und effizienteres Tracing unter Linux

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Axivion GmbH

Parasoft® Deutschland GmbH

Continental Automotive GmbH

Das Debug-FS-Interface von Linux bringt bereits einige solide Grundlagen zum Tracing und Debugging mit sich. Wer etwas weiter in die Tiefe gehen möchte, für den stehen unter Linux noch zahlreiche weitere hilfreiche und mächtige Werkzeuge bereit.

Im ersten Teil dieser Artikelserie haben wir uns mit den Grundlagen der Linux Tracing Infrastruktur beschäftigt. Eine herausragende Eigenschaft dieses Werkzeugkastens ist, dass er komplett ohne spezielle Programme bedient werden kann. Dies bedeutet jedoch nicht, dass keine Tools zur Verfügung stehen. Im Gegenteil: Ergänzend zu den Möglichkeiten, die Linux bereits über das sogenannte DebugFS Interface bereitstellt, existieren einige mächtige Werkzeuge, die die Bedienung der Tracing Infrastruktur deutlich vereinfachen und auch eine grafische Auswertung von Trace-Aufzeichnungen ermöglichen.

trace-cmd

Das wohl bekannteste und am häufigsten verwendete Hilfsmittel zur Aufzeichnung von Traces ist „trace-cmd“. Es handelt sich dabei um ein Kommandozeilenwerkzeug, das auf den meisten gängigen Linux Distributionen (auch im Embedded-Umfeld) als Standardpaket verfügbar ist. Weiterhin lässt sich trace-cmd sehr einfach für verschiedene Architekturen cross übersetzen. Wer also nicht über die verwendete Linux-Distribution auf dieses Werkzeug zurückgreifen kann, hat somit die Möglichkeit es sehr einfach nachzurüsten. Der Quellcode dazu findet sich hier:

https://git.kernel.org/pub/scm/linux/kernel/git/rostedt/trace-cmd.git/

Mit trace-cmd kann sowohl das Recording als auch die Auswertung eines Traces erfolgen. Greifen wir das Beispiel aus dem letzten Artikel dieser Serie auf und betrachten die Aufzeichnung aller Scheduling Events über einen bestimmten Zeitraum. Dies kann wie folgt aussehen:

trace-cmd record -e sched sleep 5

Das Subkommando „record“ stößt eine Trace-Aufzeichnung an und mit dem Argument „-e“ wird festgelegt, welche Events aufgezeichnet werden sollen. Hier aktivieren wir alle Ereignisse der Gruppe „sched“. Die zusätzlichen Argumente für die Option „-e“ entsprechen exakt den Namen der Events und Eventgruppen, wie man sie im DebugFS Interface vorfindet. Und selbstverständlich können auch beliebig viele Ereignisse für eine Aufzeichnung mit trace-cmd verwendet werden, hierzu wird das Argument „-e“ dann entsprechend mehrfach angegeben.

Das Recording ist auf einen bestimmten Zeitraum beschränkt, nämlich die Ausführung eines Kommandos. In diesem Beispiel führen wir also das Kommando „sleep 5“ aus und zeichnen während der Ausführung alle Events der Gruppe „sched“ auf. Die Ringbuffer werden während der Aufzeichnung kontinuierlich ausgelesen (per trace_pipe, also konsumierend) und weggeschrieben, hierfür wird eine Datei mit dem Namen „trace.dat“ erzeugt (dies ist nur der Default, mit der Option „-o“ kann angegeben werden, wohin die Daten geschrieben werden sollen).

Gespeichert wird nicht nur der Inhalt des Ringbuffers, sondern auch alle notwendigen Informationen über das Target, damit die Auswertung auf jedem beliebigen System erfolgen kann. Mit einem simplen Kommando lassen sich mit trace-cmd also mehrere Teilschritte automatisieren: die Konfiguration, das Starten und Stoppen der Aufzeichnung und das Auslesen und persistieren der Ereignisse in eine Datei.

Die Auswertung der aufgezeichneten Daten erfolgt ebenfalls mit trace-cmd, hierfür steht das Subkommando „report“ zur Verfügung:

trace-cmd report
oder:
trace-cmd report -i <Dateiname>

Ohne Angabe eines Dateinamens, wird trace-cmd standardmäßig versuchen, im aktuellen Verzeichnis eine Datei mit dem Namen trace.dat zu finden. Mit der Option „-i“ kann explizit eine Datei angegeben werden.

Bild 1 zeigt einen Ausschnitt der Ausgabe von „trace-cmd report“. Das Format ist stark an das des DebugFS Interfaces angelehnt. Selbstverständlich beherrscht das Subkommando „report“ viel mehr als nur die reine Darstellung, so können zum Beispiel Filter angewendet werden, um nach bestimmten Ereignissen zu suchen. Für weitere Möglichkeiten der Analyse, sei auf die Dokumentation verwiesen (man trace-cmd report).

Der Funktionsumfang von trace-cmd ist vielfältig und sehr umfangreich. Aufzeichnungen können mit den Subkommandos „start“ und „stop“ auch manuell gesteuert werden, mit „extract“ kann der bestehende Inhalt der Ringbuffer ausgelesen und in das trace.dat-Format konvertiert werden und darüber hinaus besteht die Möglichkeit, Tracedaten anstatt in eine Datei zu schreiben, über das Netzwerk zu streamen. Die Manpage von trace-cmd gibt einen Überblick, welche Funktionen das Programm noch bietet.

kernelshark

Mit trace-cmd haben wir nun bereits ein Werkzeug kennengelernt, das die Aufzeichnung und Analyse von Events deutlich erleichtert. Die Auswertung kann zwar auf jedem beliebigen System erfolgen, ist allerdings rein textbasiert. Und genau hier setzt das Tool „kernelshark“ an. Es handelt sich dabei um eine Ergänzung von trace-cmd, um eine grafische Analyse von Traceaufzeichnungen zu ermöglichen. Beide Tools werden gemeinsam entwickelt und sind somit perfekt aufeinander abgestimmt. So wie trace-cmd ist auch kernelshark in den meisten aktuellen Linux Distributionen verfügbar.

Als Eingabe erwartet kernelshark Daten im trace.dat-Format (also so, wie sie von trace-cmd erzeugt werden):

kernelshark
oder
kernelshark -i <Dateiname>

Das Verhalten ist hier analog zu dem von trace-cmd: Wird kein Dateiname angegeben, wird im aktuellen Verzeichnis nach einer Datei mit dem Namen trace.dat gesucht. Mit der Option „-i“ kann eine bestimmte Datei angegeben werden.

Bild 2 zeigt die grafische Darstellung von kernelshark. Die untere Hälfte des Fensters stellt die aufgezeichneten Events im bekannten Textformat dar. Die obere Hälfte zeigt eine grafische Repräsentation dieser Ereignisse. Für jede CPU wird eine eigene Zeile dargestellt. Die Farben innerhalb der Zeilen stehen für unterschiedliche Tasks. Jeder einzelnen Task wird eine eigene Farbe zugeordnet. Die senkrechten Striche innerhalb der Zeilen stehen jeweils für ein aufgezeichnetes Event, die farbig ausgefüllten Bereiche zeigen die Ausführung einer Task. D.h. hier hat uns kernelshark bereits Arbeit abgenommen: Basierend auf den aufgezeichneten Events wurde ausgewertet, wann welche Task auf welcher CPU ausgeführt wurde.

Die Bedienung der Oberfläche gestaltet sich denkbar einfach. Durch Klicken und Ziehen von links nach rechts in der Grafik, kann in einen beliebigen Bereich hineingezoomt werden (Ziehen von rechts nach links zoomt aus der Ansicht wieder heraus). Ein Doppelklick in der grafischen oder in der textuellen Darstellung führt dazu, dass der jeweils andere Bereich genau diesen Punkt highlighted. Wird die Option „graph follows“ aktiviert, so wird beim Durchgehen der Ereignisse in der textuellen Darstellung, die Position in der Grafik automatisch aktualisiert.

Bei vielen Problemen ist es hilfreich, bestimmte Situationen aus der Sicht einer einzelnen Task zu betrachten. Hierfür bietet kernelshark über den Menüpunkt „Plots->Task“ die Möglichkeit einzelne (oder alle) Tasks auszuwählen. Für jede gewählte Task wird in der grafischen Darstellung eine eigene Zeile hinzugefügt. Das Farbschema ist dort dann ein anderes: Aus Sicht einer Task wird jeder CPU eine eigene Farbe zugeordnet. Wechselt eine Task also die Farbe, dann wurde diese auf eine andere CPU migriert.

Gerade bei der Untersuchung von Latenzproblemen spielen das Aufwecken eines Programmes oder Situationen, in denen ein Programm unterbrochen wurde, eine große Rolle. Beide Situationen werden von kernelshark grafisch hervorgehoben. Grün umrahmte aber nicht ausgefüllte Bereiche zeigen, dass eine Task lauffähig ist, aber noch keine Rechenzeit bekommt. Mit rot umrahmten Bereichen wird das Unterbrechen einer Task markiert. Weiterhin stehen 2 Marker zur Verfügung. Werden beide Marker gesetzt, so wird auch die Zeitdifferenz zwischen beiden Markern berechnet (dies kann ebenfalls bei der Analyse von Latenzproblemen von Interesse sein).

Es gibt noch viele weitere nützliche Funktionen, wie zum Beispiel das Setzen von Filtern. Einen guten Überblick bietet die offizielle Dokumentation zu kernelshark: https://kernelshark.org/Documentation.html

Tracecompass

Über die letzten Jahre haben sich viele weitere Werkzeuge für den Umgang mit der Linux Tracing Infrastruktur etabliert. Das wohl mächtigste, frei verfügbare Programm zur grafischen Trace Analyse ist der sogenannte „Tracecompass“. Die Grundlagen für dieses Tool wurden bereits vor vielen Jahren im Rahmen der Entwicklung von LTTng (Linux Tracing Toolkit next generation) gelegt. Zu dieser Zeit besaß Linux von Hause aus noch keine eigene Tracing Infrastruktur. Mit der starken Weiterentwicklung der in Linux verfügbaren Werkzeuge hat sich auch LTTng und die damit verbundenen Programme entwickelt. Auch wenn Tracecompass ursprünglich in einem anderen Kontext entstand, so kann er heute dennoch dazu verwendet werden, Aufzeichnungen der Standard Linux Tracing Infrastruktur auszuwerten. Die dazu notwendigen Weiterentwicklungen sind maßgeblich der Diamon Working Group der Linux Foundation zu verdanken.

Tracecompass ist Eclipse basiert und sowohl als Plug-In, als auch als Standalone Applikation verfügbar. Unter https://www.eclipse.org/tracecompass/ kann die jeweils aktuelle Version bezogen werden. Das Programm kann auf Linux und auf Windows-basierten Systemen betrieben werden. Bedingt durch die Historie von Tracecompass ist das am besten unterstützte Dateiformat das Common Trace Format (CTF), welches auch aus dem Umfeld des LTTng Projekts stammt. Allerdings kann Tracecompass mittlerweile auch direkt Traces lesen, wie sie von Linux erzeugt werden. Hierfür ist ein Plug-In erforderlich, das per Default zwar nicht installiert ist, sich aber sehr einfach nachrüsten lässt. Nach dem Start von Tracecompass kann über Tools und den Menüpunkt „Add-Ons“ das notwendige Feature installiert werden. Dieses findet sich im Auswahl Menü unter „Trace Compass ftrace“. Dieser Menüpunkt muss aktiviert und die Installation mit dem Button „finish“ angestoßen werden.

Nach Abschluss der Installation kann die im letzten Kapitel erstellte Datei trace.dat importiert werden. Unter Linux kann dies direkt erfolgen, unter Windows ist ein kleiner Umweg erforderlich, da für das direkte Einlesen von trace.dat das trace-cmd Tool installiert sein muss. Dieses ist unter Windows nicht verfügbar. Zur Nutzung von Tracecompass auf einem Windows-basierten System müssen die Daten daher wie folgt vorbereitet werden:

trace-cmd report -R -i trace.dat > trace.raw

Die so erzeugte Datei kann nun in Tracecompass eingelesen werden. Dies erfolgt über „File“ und „Import“. Im entsprechenden Dialog wird nun die Datei „trace.raw“ (oder unter Linux direkt die Datei trace.dat) ausgewählt und mit dem Button „Finish“ importiert. Anschließend ist die Traceaufzeichnung im sogenannten „Project explorer“ verfügbar.

Im Übrigen können auch Traces verarbeitet werden, die nicht mit trace-cmd erzeugt wurden. Hierfür müssen lediglich die Daten per DebugFS aus der Datei „trace“ in eine Datei geschrieben werden. (näheres hierzu im ersten Artikel dieser Serie). Diese Datei wird dann wie oben beschrieben in Tracecompass importiert.

Abbildung 3 zeigt die Traceaufzeichung. Im Reiter „Control Flow“ ist eine grafische Darstellung der Tasks zu finden. Es lassen sich auch Pfeile einblenden, die den Ablauf im Scheduling veranschaulichen. Im Fenster darunter sind die aufgezeichneten Events zu sehen. Und wer sich für den Ablauf auf den einzelnen CPUs interessiert, der findet diesen im Reiter „Resources“.

Abbildung 4 zeigt diese Ansicht. Darüber hinaus lässt sich auch die CPU-Auslastung darstellen, eine Statistik der aufgezeichneten Events erstellen und ein Histogramm visualisiert die Anzahl der aufgezeichneten Ereignisse. Je nachdem welche Events aufgezeichnet wurden, kann Tracecompass aber noch viel mehr. Der Funktionsumfang ist enorm, die Bedienung ist aber weitestgehend selbsterklärend. Es empfiehlt sich daher, die verfügbaren Features selbst zu erkunden.

Fazit

Auch wenn die Linux Tracing Infrastruktur völlig ohne spezielle Werkzeuge auskommt, so gibt es mittlerweile ein sehr umfangreiches Portfolio an Tools, die den Anwender bei der Nutzung der Tracing Infrastruktur unterstützen. Eine sehr positive Entwicklung ist die Tatsache, dass auch Programme, die ursprünglich nicht direkt aus dem Umfeld der Linux Kernel Entwicklung stammen, nun auch direkt für jeden Linux-Anwender für jedes Linux-System nutzbar sind. Das beste Beispiel hierfür ist Tracecompass mit seinem enormen Funktionsumfang.

Nachdem die ersten beiden Teile dieser Artikelserie sich mit den Grundlagen der Tracing Infrastruktur und den wichtigsten Werkzeugen beschäftigt haben, werden wir im nächsten Artikel betrachten, wie die sogenannten Tracer verwendet werden und wie Events aus einer Applikation heraus generiert werden können.

Einführung in die Linux Tracing Infrastruktur

* Jan Altenberg beschäftigt sich seit mehr als 15 Jahren beruflich mit Linux. Er betreute u.a. verschiedene Arbeiten für das EU-Projekt OCEAN, welches sich zum Ziel setzte, eine offene Steuerungsplattform auf Basis von Realtime Linux zu schaffen. Weiterhin trug er bei einem namhaften Maschinenhersteller die volle konzeptionelle Verantwortung für die Einführung von Linux in der neuen Steuerungsgeneration. Von 2007-2019 arbeitete er für die Linutronix GmbH und leitete dort zuletzt den technischen Vertrieb. Jan Altenberg ist regelmäßiger Sprecher auf verschiedenen Fachkonferenzen und wurde 2014, 2018 und 2019 von den Besuchern des ESE Kongress mit dem Speaker Award Publikumspreis ausgezeichnet. Seit April 2019 arbeitet er als System-Architekt und Experte für Open-Source-Technologien für Continental Automotive.

(ID:46857168)