Zum Inhalt springen 
Mit kernel tracepoints verstehe ich Leistungsprobleme in Linux bis in den Kernel hinein und kann gezielt messen, wo Zeit verloren geht. Ich nutze diese Messpunkte, um Abläufe im Scheduler, im I/O-Stack und im Netzwerkpfad zu beobachten – mit geringem Zusatzaufwand und klaren Ereignisdaten.
Zentrale Punkte
Die folgenden Kernaspekte geben dir einen schnellen Überblick, worauf ich beim Arbeiten mit Tracepoints achte.
- Statisch verankerte Events liefern verlässliche Daten an markanten Code-Stellen.
- Geringer Overhead macht Tracing auch unter hoher Last praktikabel.
- Breites Ökosystem mit ftrace, perf, LTTng und eBPF-Tools.
- Gezieltes Aktivieren und Filtern verhindert Datenfluten.
- Kombination mit Performance-Countern zeigt Ursachenketten.
Ich halte die Liste schlank und fokussiere die Prioritäten der Analyse. So verliere ich keine Zeit in Nebenschauplätzen und behalte die wichtigsten Signale im Blick. Die genannten Punkte leiten meine praktische Arbeit vom ersten Verdacht bis zur verifizierten Optimierung. Damit schaffe ich Transparenz und Reproduzierbarkeit. Ich bleibe datengetrieben und kontrolliere jeden Schritt.
Was sind Kernel Tracepoints?
Ein Tracepoint ist ein statischer Instrumentierungspunkt im Kernel-Code, der ein Event mit strukturierten Feldern auslöst. Ich sehe dort unter anderem PID, Zeitstempel, CPU, Statuscodes oder Größenangaben, je nach Event. Über Makros wie TRACE_EVENT definiert der Kernel die Stelle, das Format und die gelieferten Daten. Diese Ereignisse liegen an sinnvollen Schnittstellen wie Scheduling, Block-I/O, Dateisystemen oder dem Netzwerkpfad. Ich kann sie jederzeit aktivieren, ohne den Kernel zu patchen oder Produktivsysteme zu riskieren, was mir Planungssicherheit gibt.
Warum Tracepoints für Performancemessung nutzen
Tracepoints bleiben im inaktiven Zustand fast kostenfrei und fügen erst beim Einschalten geringen Mehraufwand hinzu. Ich messe selbst bei aktivierten Events typischerweise nur eine zusätzliche Latenz im niedrigen zweistelligen Nanosekundenbereich – gut genug für Systeme mit strengen Latenzzielen. Da sie stabil im Kernel verankert sind, kann ich Analysen über Kernel-Versionen hinweg konsistent wiederholen. Ihre strukturierte Ausgabe lässt sich zuverlässig parsen und weiterverarbeiten. Damit gewinne ich verlässliche Messungen statt unklarer Log-Fragmente.
Zeitstempel, Uhren und Reihenfolge
Damit ich Latenzen korrekt deute, achte ich auf die verwendete Zeitquelle. Monotone Uhren (z. B. CLOCK_MONOTONIC) sind für Messungen robuster als die Wandzeit, weil NTP-Korrekturen nicht rückwirkend eingreifen. Auf Mehrkernsystemen liefern per-CPU-Puffer Events, deren Reihenfolge CPU-lokal stimmt, aber zwischen CPUs nur über Zeitstempel vergleichbar ist. Ich kalibriere deshalb die Sicht: Entweder ordne ich Ereignisse pro CPU, oder ich verwende Tools, die Puffer synchronisieren und Timeline-Konflikte korrekt auflösen. Bei sehr knappen Budgets prüfe ich, ob die TSC-Basis stabil ist, damit Abweichungen nicht fälschlich wie Jitter wirken. So verhindere ich Fehlinterpretationen, wenn zum Beispiel Wakeups auf CPU 3 und Kontextwechsel auf CPU 7 passieren.
Linux Tracing-Ökosystem im Überblick
Ich nutze mehrere Werkzeuge, die alle auf denselben Tracepoint-Events aufsetzen. ftrace erlaubt schnelles Aktivieren über das Tracing-Dateisystem und eignet sich für Ad-hoc-Checks mit Live-Blick. Mit perf verbinde ich Tracepoints, Hardware-Counter und Sampling, um Korrelationen sichtbar zu machen. LTTng trägt lange Aufzeichnungen mit hoher Ereignisrate und geringer Zusatzlast, was für tiefe Analysen zählt. eBPF-gestützte Tools lesen Tracepoints, führen Aggregationen im Kernel aus und reduzieren so Datenverkehr in den Userspace.
Ringpuffer und Verlustkontrolle
Hinter jedem aktiven Event arbeitet ein per-CPU-Ringpuffer. Ich dimensioniere diese Puffer so, dass Lastspitzen abgefedert werden, ohne dass Events verworfen werden. Wichtig sind Verlustzähler und Warnungen der Tools: Bei perf beachte ich Lost-Event-Zähler, bei ftrace prüfe ich Dropped-Statistiken im tracefs. LTTng zeigt ebenfalls an, wenn der Konsumentenpfad nicht nachkommt. Tritt Verlust auf, erhöhe ich die Puffer, filtere schärfer oder aggregiere früh. Für „Flight Recorder“-Szenarien nutze ich Snapshots, die einen Zeitraum um einen Trigger konservieren. So halte ich die Datenqualität hoch und erspare mir fehlerhafte Hypothesen auf Basis unvollständiger Spuren.
Werkzeugwahl: ftrace, perf, LTTng, eBPF
Ich starte oft mit perf, weil ich dort Sampling, Zählwerte und Tracepoints zusammen auswerte. Für schnelle Event-Inspektionen greife ich zu ftrace und schalte gezielt Events frei. Komplexe, langlaufende Sessions mit vielen CPUs fahre ich gern mit LTTng, da es hohe Raten zuverlässig ablegt. Möchte ich im Kernel voraggregieren, nutze ich eBPF-basierte Tracer, um nur verdichtete Kennzahlen zu exportieren. Wer tiefer in perf einsteigen will, findet praxisnahe Hinweise im Beitrag zum perf-Tool, was Einsteigern und Fortgeschrittenen gleichermaßen hilft.
Reproduzierbarkeit und Automatisierung von Sessions
Ich halte erfolgreiche Sessions als Rezept fest: aktivierte Events, Filter, Puffergrößen, Samplingraten und Laufzeit. Zusätzlich dokumentiere ich Kernel-Version, Tool-Versionen, CPU-Topologie und Power-Settings, damit spätere Messungen vergleichbar sind. So kann ich bei Bedarf eine Session unverändert wiederholen, auf andere Hosts übertragen oder in CI-Pipelines automatisieren. Bei längeren Analysen sichere ich Rohdaten und generiere direkt nach der Messung Zusammenfassungen (Histogramme, Perzentile, Heatmaps). Ich arbeite iterativ: kurze, gezielte Läufe, Auswertung, Hypothese präzisieren – und erneut messen. Auf diese Weise verliere ich mich nicht in Daten, sondern treffe belastbare Aussagen mit minimaler Schleifenzeit.
Einsatzszenarien in der Praxis
Beim Scheduler beobachte ich Kontextwechsel, Wakeups und Queue-Interaktionen, um exzessives Umschalten oder unpassende Prioritäten sichtbar zu machen. Im Block-Stack korreliere ich Einreichen und Abschluss von Requests mit Queue-Tiefe und Größen, so decke ich Storage-Engpässe auf. Im Netzwerkpfad verfolge ich Ein- und Ausgang von Paketen sowie Warteschlangen, um Latenzketten pro Flow zu verstehen. Bei Syscalls prüfe ich Häufigkeit und Latenz, um Auffälligkeiten in Hotpaths zu erkennen. Ich kombiniere das bei Bedarf mit Hardware-Countern, damit Cache-Misses, Branch-Mispredictions und I/O-Events eine Ursachenkette ergeben.
Konkrete Event-Namen und Feldinterpretation
Ich wähle Events so, dass ich mit wenigen Messpunkten den Pfad vollständig rekonstruieren kann. Ein Grundset, das sich bewährt hat:
- Scheduler: sched:sched_switch (prev/next_comm, prev_state), sched:sched_wakeup und sched:sched_wakeup_new (Wakeup-Quelle, Ziel-CPU)
- Block-I/O: block:block_rq_issue, block:block_rq_complete (Sektoren, Größe, Gerät, Latenz über Delta)
- Netzwerk: net:net_dev_queue, net:netif_receive_skb (Queueing und Empfang), tcp:tcp_retransmit_skb (Retransmits)
- Syscalls: syscalls:sys_enter_*, syscalls:sys_exit_* (Dauer pro Aufruf, Fehlercodes)
Ich prüfe die Feldbedeutungen vorab, damit ich korrekt korreliere: Aus prev_state lese ich schlafende Tasks, aus CPU-Feldern erkenne ich Wanderungen über Sockets hinweg. Bei Netzwerk-Events beziehe ich, wenn verfügbar, Flow-Metadaten (z. B. Ports) ein, um Latenzen pro Verbindung zu gruppieren. So bekomme ich Pfade, die sich tatsächlich mit beobachtetem Verhalten im Dienst decken.
Schritt-für-Schritt: Von der Frage zur Tracesession
Ich beginne immer mit einer klaren Frage, etwa: „Warum steigen Antwortzeiten in Spitzenlasten?“ Dieser Schritt zwingt mich, das richtige Subsystem zu wählen: Scheduler, Netzwerk, Block, Filesystem oder Speicherverwaltung. Anschließend liste ich passende Tracepoints mit „perf list“ oder im Tracing-Dateisystem auf und notiere relevante Felder. Ich konfiguriere die Session, setze Filter auf PID, CPU oder Event-Felder und lege Puffer sowie Dauer fest. Danach fahre ich das Lastszenario und analysiere anschließend Latenzverteilungen, Reihenfolgen und Korrelationen, bevor ich eine Hypothese prüfe und die Änderung wieder messe, um den Effekt zu bestätigen.
Filtern und Korrelation: PIDs, TIDs, cgroups und Flows
Präzise Filter sparen mir Zeit. Ich arbeite je nach Ziel mit PID-/TID-Filtern, CPU-Selektion oder cgroup-Filtern, um Container- oder Service-Grenzen einzuhalten. Sobald ich Netzwerklatenz verstehen will, korreliere ich Events über Flow-Attribute (z. B. Quell-/Zielport), damit ich Bulk-Traffic und Latenz-sensible Flows trenne. Bei Dateien ordne ich per Gerät/Block-Adresse zu oder gruppiere per Mount-Point, je nach Werkzeug. Im Scheduler-Bereich messe ich vom Wakeup bis zum ersten sched_switch auf die Ziel-CPU; so sehe ich Wartezeit in Runqueues getrennt von eigentlicher CPU-Zeit.
Overhead steuern: Best Practices
Ich aktiviere nur die Tracepoints, die ich wirklich brauche, um Datenmengen und Zusatzlast gering zu halten. Filter nach PID, CPU oder Feldern halten Rauschen niedrig und schonen Puffer. Die Puffergröße passe ich an die Eventrate an, damit ich keine Ereignisse verliere. Sessions begrenze ich zeitlich klar und wiederhole nur, wenn ich eine Hypothese testen will. Bei extrem häufigen Events greife ich zu Sampling oder in-Kernel-Aggregation per eBPF, damit die Auswertung im Userspace schlank bleibt.
Vergleich: Tracepoints vs. Performance-Events
Beide Ansätze ergänzen sich. Tracepoints erklären konkrete Ereignisse in Subsystemen und liefern aussagekräftige Felder. Performance-Events geben mir statistische Sicht auf Zyklen, Cache-Misses oder Branches. Im Zusammenspiel erkenne ich, wie viel Zeit verloren geht und an welchem Schritt es hakt. Die folgende Tabelle hilft bei der Werkzeugwahl und fokussiert auf das, was ich im nächsten Messlauf brauche. Sie dient mir als Merkliste für die Planung der Session.
| Aspekt | Tracepoints | Performance-Events (perf) |
|---|---|---|
| Stabilität | Statische Events an Kernel-Stellen, weitgehend versionstreu | Abhängig von Hardware-Countern und Kernel-Implementierung |
| Overhead | Niedrig, Event-getrieben | Sehr niedrig beim Sampling |
| Fokus | Konkrete Subsystem-Ereignisse | Systemweite Kennzahlen |
| Datenformat | Strukturiert, maschinenlesbar | Zählwerte, Samples, Profile |
| Typischer Einsatz | „Was“ und „Wann“ eines Pfades | „Wie viel“ und „Wie teuer“ |
Ich starte gerne mit Performance-Events, um einen groben Engpass zu lokalisieren, und gehe anschließend mit Tracepoints ins Detail. Umgekehrt schalte ich zuerst Tracepoints ein, wenn ich einen Pfad verstehen will, und ergänze später Counter für Quantisierung. Diese Reihenfolge spart Zeit und hält die Datenerhebung zielgerichtet. Wichtig ist, die Eventrate im Blick zu behalten, damit keine Daten verloren gehen. So bleibe ich mit Messdisziplin auf Kurs.
Grenzen, Validierung und Cross-Checks
Nicht jeder Treiberpfad ist durchgängig instrumentiert, und manche seltenen Fehlerwege tauchen in Spuren nicht auf. Deshalb gleiche ich Messungen gegen alternative Sichtweisen ab: Counter, Logs, synthetische Tests, aber auch einfache Zeitmessungen im Dienst selbst. Wenn Spuren und Counters nicht zusammenpassen, prüfe ich zuerst Filter und Datenverluste, danach die Uhrbasis. Ich achte außerdem auf Interferenzen: Debug-Builds, hohe Logging-Raten oder Security-Hooks können Latenzen verschieben. Nur mit Cross-Checks belege ich sicher, dass eine gefundene Ursache auch tatsächlich der Hebel für die Optimierung ist.
Beispiel: Storage-Latenzen messen
Ich aktiviere im Block-Stack Tracepoints für das Einreichen und Abschließen von I/O-Requests. Während ein Lasttest läuft, zeichne ich Zeitstempel, Request-Größe, Gerät und PID auf, um Latenzen je Prozess sichtbar zu machen. Danach sortiere ich nach Dauer und lasse mir Histogramme ausgeben, die Peaks und Ausreißer zeigen. In einem zweiten Durchlauf nehme ich zusätzlich CPU-Counter dazu, um zu prüfen, ob Rechenlast und I/O-Latenzen zusammenhängen. Am Ende justiere ich I/O-Scheduler, Queue-Tiefe oder Storage-Backend und wiederhole die Messung, bis die Ziele verlässlich erreicht sind.
Beispiel: Scheduler- und Wakeup-Latenzen nachvollziehen
Wenn Threads „spiky“ reagieren, messe ich die Zeit von sched:sched_wakeup bis zum ersten sched:sched_switch auf die Ziel-CPU. So trenne ich Wartezeit in Runqueues von tatsächlicher Ausführungszeit. Ich gruppiere nach CPU, Priorität und Policy (CFS/RT), um Missfits zu erkennen – etwa, wenn Threads mit hohem CPU-Bedarf auf überfüllten Cores landen, obwohl freie Kerne existieren. Sehe ich viele Cross-CPU-Wakeups, prüfe ich Affinitäten und NUMA-Zuteilung. In Kombination mit Perf-Countern für LLC-Misses belege ich, ob falsche Platzierung Cache-Latenzen hochtreibt. Eine kleine Anpassung an Thread-Affinität oder Scheduling-Parametern bringt hier oft sofort messbare Verbesserungen.
Tipps für produktive Umgebungen
Ich schalte Tracing außerhalb von Wartungsfenstern nur mit klaren Filtern und kurzen Zeitfenstern ein. Vorher prüfe ich Eventraten exemplarisch auf einem Testsystem, damit ich die Puffer passend einstelle. In produktiven Setups nutze ich in-Kernel-Aggregationen, um die Last im Userspace zu senken. Für schnelle Ad-hoc-Diagnosen lohnt ein Blick auf bpftrace im Hosting, weil ich damit in Minuten erste Antworten bekomme. Ich dokumentiere jeden Messlauf sofort, damit ich Wiederholbarkeit wahre.
Sicherheit, Rechte und Isolationsgrenzen
Tracing am Kernel erfordert passende Berechtigungen. Ich stelle sicher, dass tracefs korrekt gemountet ist und prüfe systemweite Schalter wie perf_event_paranoid oder kptr_restrict, die Details maskieren können. In sensiblen Umgebungen begrenze ich, wer Tracing aktivieren darf, und hinterlege Prozeduren zur Freigabe. Ich anonymisiere Prozessnamen oder IPs, wenn Daten geteilt werden müssen, und definiere klare Aufbewahrungsregeln für Traces. In Containern gilt: Root im Container ist nicht automatisch befähigt, Host-Kernel-Events zu lesen. Ich trace daher vorzugsweise vom Host oder arbeite mit expliziten cgroup-Filtern, um nur den Ziel-Workload zu erfassen.
Checkliste und typische Fehler
Ich definiere zuerst die Frage, dann die Subsysteme, dann die Events – in dieser Reihenfolge. Ich prüfe, ob ich wirklich alle benötigten Felder mitschreibe, bevor ich die Last starte. Vergiss nicht, Filter zu setzen; ungefilterte Sessions erzeugen schnell Datenfluten und überlasten Speicher. Ich gleiche Kernel-Version, Event-Namen und Werkzeugoptionen ab, damit keine Missverständnisse entstehen. Für tiefergehende eBPF-Workflows erweitere ich das Setup mit den BCC-Tools, um komplexe Metriken im Kernel vorzuverarbeiten und nur verdichtete Signale zu exportieren, was Klarheit schafft.
Tracing in Containern und VMs
In Container-Setups filtere ich idealerweise nach cgroup, um genau den Service zu sehen, der mich interessiert. So messe ich in Multi-Tenant-Umgebungen, ohne fremde Workloads zu erfassen. Auf VMs gilt: Ich sehe nur, was im Gastkernel passiert. Virtio-/vhost-Pfade und die Hypervisor-Seite bleiben ohne Host-Tracing unsichtbar. Für Ende-zu-Ende-Latenzen korreliere ich daher Gast- und Host-Messungen, wenn ich beide Einflussbereiche im Blick haben will. Zusätzlich beachte ich Zeitsynchronisation zwischen Host und Gast, damit ich Logs, Metriken und Traces sinnvoll übereinanderlegen kann. Mit dieser Disziplin bleiben Analysen auch in virtualisierten Landschaften belastbar.
Zum Mitnehmen: Wichtigste Learnings
Tracepoints geben mir stabile Ankerpunkte im Kernel und liefern strukturierte Events ohne großen Ballast. Ich nutze sie, um exakte Abläufe zu verstehen, Engpässe zu isolieren und Änderungen messbar zu überprüfen. Mit ftrace, perf, LTTng und eBPF wähle ich je nach Ziel das passende Werkzeug und kombiniere es bei Bedarf. Eine klare Fragestellung, strenge Filter und passende Puffergrößen halten die Last niedrig und die Daten brauchbar. So finde ich Ursachen schneller, belege die Wirkung meiner Maßnahmen und halte die Performance dauerhaft unter Kontrolle.
