Continuous Profiling in der Produktion: Wie Always-on-Profiling mit Pyroscope und Parca Performance-Flaschenhälse sichtbar macht

Daten-Analyse auf einem Monitor – Foto von Pexels, lizenzfrei nutzbar

Klassisches Profiling kennen die meisten Entwickler: Man aktiviert es kurz, sammelt Daten über Hotspots, analysiert ein Flamegraph und schaltet es wieder ab. Das Problem dabei? Produktions-Performance-Probleme lassen sich oft nicht reproduzieren. Der Engpass, der nachts die Latenz verdreifacht, ist am nächsten Morgen verschwunden – und das Profiling lief nur am Dienstag von 14 bis 15 Uhr. Continuous Profiling löst dieses Problem, indem es Profiling dauerhaft aktiviert, mit minimalem Overhead und mit Zeitstempel – sodass Performance-Regressi onen retrospektiv untersucht werden können.

Was ist Continuous Profiling?

Continuous Profiling bezeichnet das kontinuierliche, Low-Overhead-Sampling von Prozessen in der Produktion. Statt eines einmaligen Snapshots entsteht ein lückenloses Archiv der Laufzeit-Performance – vergleichbar mit Metriken und Logs, aber auf Codeebene. Wann wurde welche Funktion wie oft aufgerufen? Welcher Code-Pfad hat die CPU dominiert? Wieviel Speicher hat welcher Stacktrace alloziert?

Das ermöglicht Fragen wie: "Seit welchem Commit ist die CPU-Auslastung in dieser Funktion um 30 % gestiegen?" – eine Frage, die ohne dauerhaftes Profiling kaum zu beantworten ist.

Wie funktioniert es technisch?

Die meisten Continuous-Profiling-Lösungen arbeiten mit Sampling-basiertem Profiling: In kurzen Intervallen (typischerweise alle 10–100 ms) wird der aktuelle Stacktrace aller Threads aufgezeichnet. Die gesammelten Samples werden aggregiert, komprimiert und an ein zentrales Backend gesendet. Der Overhead liegt typischerweise bei 1–3 % CPU und einem geringen Speicherverbrauch.

Moderne Implementierungen nutzen dafür eBPF auf Linux – ohne jede Code-Instrumentierung. Das Profiling-Tool läuft im Kernel-Space und kann Stacktraces aller Prozesse samplen, ohne dass die Applikation angepasst werden muss. Für Sprachen mit Garbage Collection (Java, Go, Python) gibt es darüber hinaus sprachspezifische Agents, die Heap-Allokationen und GC-Zyklen sichtbar machen.

Die wichtigsten Open-Source-Tools

Pyroscope

Pyroscope (heute Teil von Grafana) ist das bekannteste Open-Source-Projekt für Continuous Profiling. Es unterstützt Go, Python, Java, Ruby, Node.js und .NET und bietet eine flameGraph-basierte UI. Pyroscope lässt sich in Grafana integrieren, sodass Profiling-Daten direkt neben Metriken und Traces betrachtet werden können. Die Datenhaltung erfolgt wahlweise in Pyroscope selbst oder im Grafana-Backend.

Parca

Parca ist ein weiteres Open-Source-Projekt mit starkem Fokus auf eBPF-basiertes, instrumentierungsfreies Profiling. Es folgt den OpenTelemetry-Prinzipien und ist besonders für Kubernetes-Umgebungen optimiert. Das Parca-Agent läuft als DaemonSet und profilt alle Pods ohne weitere Konfiguration. Ein nativer Storage-Backend auf Basis von Apache Parquet ermöglicht effizientes Langzeit-Archivieren.

Grafana Pyroscope (Alloy)

Mit Grafana Alloy und dem integrierten Pyroscope-Backend lässt sich Continuous Profiling nahtlos in eine bestehende Grafana-Observability-Stack integrieren. Wer bereits Loki (Logs), Tempo (Traces) und Mimir/Prometheus (Metriken) nutzt, kann Profiling als vierte Säule ergänzen – ohne einen separaten Technologie-Stack einzuführen.

Praktische Anwendungsfälle

Regression-Bisecting

Nach einem Deployment steigt die CPU-Auslastung. Im klassischen Debugging würde man jetzt lokale Profiling-Sessions starten. Mit Continuous Profiling öffnet man das flamegraph-Diff zwischen vor und nach dem Deployment und sieht sofort, welche Funktion neu aufgetaucht ist oder sich ausgedehnt hat.

Speicherlecks in Produktion

Speicherlecks sind notorisch schwer zu reproduzieren. Continuous Heap-Profiling zeigt, welche Stacktraces für das Wachstum des Heaps verantwortlich sind – über Stunden oder Tage hinweg aggregiert. Was in einer kurzen lokalen Session unsichtbar bleibt, wird im Langzeit-Profil auffällig.

Kosten-Optimierung in der Cloud

Oft weiß man nicht, welche Services tatsächlich CPU-Zeit verbrauchen. Continuous Profiling macht CPU-Kosten auf Code-Ebene sichtbar. Nicht selten stellt sich heraus, dass ein Debug-Logging-Statement oder eine unnötige Serialisierung für 20 % der CPU-Last verantwortlich ist – und nach einer einzelnen Zeile Code-Änderung verschwindet.

Incident-Korrelation

In Kombination mit Traces und Logs entsteht bei einem Incident ein vollständiges Bild: Was war die Latenz (Traces), welche Fehler gab es (Logs), und welcher Code hat dabei die meiste CPU verbraucht (Profiling)? Observability-Plattformen wie Grafana erlauben es, direkt aus einem Trace-Span in die zugehörigen Profiling-Daten zu springen.

Integration in die Observability-Praxis

Continuous Profiling ist heute die vierte Säule der Observability, ergänzend zu Logs, Metriken und Traces. In einem modernen Stack bedeutet das konkret:

Profiling-Daten werden wie Metriken mit Labels (Service, Namespace, Version) angereichert
Flamegraphs lassen sich auf spezifische Zeitfenster zoomen – z. B. den Zeitpunkt eines Incidents
Alerting kann auf Profiling-Anomalien erweitert werden (z. B. wenn eine Funktion plötzlich deutlich mehr CPU beansprucht)

Für das Monitoring der Profiling-Infrastruktur selbst gilt: auch Pyroscope und Parca müssen überwacht werden. HTTPS-Checks, Heartbeats und API-Verfügbarkeit sollten in die eigene Monitoring-Plattform eingebunden sein – etwa über FreshCore, das einfache und zuverlässige Uptime-Checks für interne wie externe Dienste bietet.

Einstieg: Was braucht man zum Start?

Der Einstieg in Continuous Profiling ist heute einfacher als je zuvor:

Pyroscope oder Parca als Kubernetes-Deployment ausrollen (Helm-Charts vorhanden)
Parca-Agent oder Grafana Alloy als DaemonSet starten
Für feingranulares Heap-Profiling: sprachspezifischen SDK einbinden (5–10 Zeilen Code)
Pyroscope-Datasource in Grafana konfigurieren
Erstes Flamegraph ansehen – und sich fragen, warum man nicht früher angefangen hat

Fazit

Continuous Profiling füllt die letzte große Lücke in modernen Observability-Stacks. Wer bisher bei Performance-Problemen im Dunkeln tappt oder sich auf lokale Profiling-Sessions verlässt, die das Produktionsproblem nicht reproduzieren, gewinnt durch Always-on-Profiling einen erheblichen Vorteil. Die Tools sind ausgereift, der Overhead ist gering, und die Erkenntnisse können signifikante Performance- und Kosteneinsparungen bringen.

Bildquelle: Pexels (pexels.com), lizenzfrei nutzbar

Quellen: