Warum Sampling in Observability-Pipelines unverzichtbar ist
In modernen, verteilten Systemen entstehen bei jedem Request Traces, die durch Dutzende oder Hunderte von Services fließen. Was als nützliche Debugging-Information gedacht ist, wird bei ausreichend Traffik schnell zum Problem: Unkontrolliert gesammelte Traces können mehrere Terabytes pro Tag produzieren, die Kosten für Speicherung und Transport in die Höhe treiben und Analyse-Tools unter Last setzen. Die Lösung heißt Sampling – aber einfaches Sampling ist oft eine stumpfe Waffe.
OpenTelemetry bietet 2026 ausgereifte Mechanismen, um Sampling intelligent und adaptiv zu gestalten. Wer diese versteht und richtig einsetzt, kann das Trace-Volumen um 90 bis 99 Prozent reduzieren, ohne relevante Debug-Informationen zu verlieren. Dieser Beitrag erklärt die wichtigsten Sampling-Strategien, ihre Vor- und Nachteile und wann welcher Ansatz sinnvoll ist.
Die drei grundlegenden Sampling-Ansätze
1. Head-Based Sampling
Beim Head-Based Sampling wird die Entscheidung, ob ein Trace aufgezeichnet wird, am Eintrittspunkt des Systems getroffen – also beim ersten Service, der einen Request empfängt. Diese Entscheidung basiert ausschließlich auf Informationen, die zu diesem Zeitpunkt verfügbar sind: typischerweise eine Sampling-Rate, also „zeichne 10 % aller Requests auf".
Vorteil: Einfach zu implementieren, kein nennenswerter Overhead, funktioniert ohne zentrale Koordination.
Nachteil: Die Sampling-Entscheidung ist blind. Ein Fehler oder ein langsamer Request hat dieselbe Wahrscheinlichkeit aufgezeichnet zu werden wie ein perfekter Request. Bei einer Rate von 10 % gehen 90 % der Fehler verloren.
Head-Based Sampling ist sinnvoll für allgemeine Performance-Trends und Baseline-Metriken, aber ungeeignet für Debugging und Fehleranalyse.
2. Tail-Based Sampling
Tail-Based Sampling trifft die Sampling-Entscheidung erst, nachdem ein Trace vollständig vorliegt – also nachdem alle Spans eines Requests gesammelt wurden. Damit ist es möglich, den gesamten Trace zu betrachten und gezielt zu entscheiden: Dieser Trace ist interessant (Fehler, hohe Latenz), dieser nicht.
Der OpenTelemetry Collector bietet seit Version 0.80 einen stabilen Tail-Sampling-Processor. Typische Policies sind:
- Status Code Policy: Alle Traces mit HTTP 5xx oder gRPC-Fehlern immer behalten.
- Latency Policy: Alle Traces behalten, bei denen die Gesamtdauer einen Schwellenwert überschreitet (z. B. > 2000 ms).
- Probabilistic Policy: Aus den restlichen Traces einen definierten Prozentsatz zufällig behalten.
- Composite Policy: Mehrere Policies kombinieren und priorisieren.
Vorteil: Deutlich höhere Signaldichte – Fehler-Traces werden nahezu vollständig erfasst, während unauffällige Requests stark reduziert werden.
Nachteil: Höherer Ressourcenverbrauch im Collector, da alle Spans eines Traces zwischengespeichert werden müssen, bis die Entscheidung getroffen wird. Horizontale Skalierung des Collectors erfordert eine konsistente Zuweisung: Alle Spans desselben Trace-ID müssen zum selben Collector-Shard gelangen.
3. Probabilistisches Sampling mit Konsistenzgarantien
OpenTelemetry hat mit dem Konzept des Consistent Probability Sampling einen Ansatz standardisiert, der sicherstellt, dass Sampling-Entscheidungen in verteilten Systemen konsistent sind. Das Problem: Wenn Service A entscheidet, einen Trace zu samplen, Service B aber eine andere Rate hat, entstehen unvollständige Traces. Consistent Probability Sampling propagiert die Sampling-Entscheidung über W3C Trace Context-Header, sodass alle Services denselben Trace auf dieselbe Weise behandeln.
Adaptive Sampling: Wenn Schwellenwerte nicht mehr ausreichen
Statische Sampling-Regeln haben einen fundamentalen Schwachpunkt: Sie sind zur Konfigurationszeit festgelegt, aber das Verhalten von Systemen ändert sich. Was bei normalem Traffic 5 % Sampling bedeutet, kann bei einem Lastspike plötzlich das 20-fache Volumen bedeuten.
Adaptive Sampling-Mechanismen lösen dieses Problem, indem sie Sampling-Raten dynamisch anpassen. Der OpenTelemetry Collector bietet mit dem Adaptive Sampling-Processor (ab Collector v0.90 experimentell verfügbar) einen ersten nativen Ansatz. Darüber hinaus nutzen Anbieter wie Honeycomb (mit Refinery) oder Grafana Tempo eigene adaptive Algorithmen.
Typisches Muster für adaptive Pipelines
Eine pragmatische Architektur sieht so aus:
- Collector Tier 1 (Edge): Am Rand der Services, Head-Based Sampling mit 100 % für Fehler-Traces, 5–10 % für alle anderen.
- Collector Tier 2 (Aggregation): Zentrale Collector-Instanzen, die Tail-Based Sampling anwenden und konsistent nach Trace-ID sharden.
- Backend: Nur noch die relevanten Traces landen im Speicher.
Diese zweistufige Architektur kombiniert die Ressourceneffizienz von Head-Based Sampling mit der Signalqualität von Tail-Based Sampling.
KI-gestütztes Sampling: Der nächste Schritt
2026 sehen wir erste produktive Einsätze von KI-gestützten Sampling-Strategien. Statt regelbasierter Policies trainieren diese Ansätze Modelle auf historischen Trace-Daten, um automatisch zu erkennen, welche Traces informativ sind – auch dann, wenn sie keinen expliziten Fehlercode enthalten. Ein Trace, dessen Span-Muster auf ein beginnendes Ressourcenproblem hindeutet, kann so identifiziert und erhalten werden, bevor der eigentliche Fehler auftritt.
Honeycomb und andere Anbieter haben solche Funktionen in frühen Preview-Phasen verfügbar. Für IT-Teams, die eigenständige Lösungen betreiben, sind erste Open-Source-Projekte entstanden, die KI-basierte Sampling-Entscheidungen als Collector-Plugin implementieren.
Konfigurationsbeispiel: Tail-Based Sampling im OTel Collector
Ein einfaches, aber effektives Konfigurationsbeispiel für den OpenTelemetry Collector:
processors:
tail_sampling:
decision_wait: 10s
policies:
- name: errors-policy
type: status_code
status_code: {status_codes: [ERROR]}
- name: slow-traces-policy
type: latency
latency: {threshold_ms: 2000}
- name: probabilistic-policy
type: probabilistic
probabilistic: {sampling_percentage: 5}
Diese Konfiguration behält alle Fehler-Traces und alle Traces über 2 Sekunden vollständig, und samplet von den restlichen Traces 5 Prozent zufällig. In typischen Produktionsumgebungen reduziert das das Trace-Volumen erheblich, ohne relevante Debug-Informationen zu verlieren.
Fazit: Sampling ist Architektur, nicht Konfiguration
Wer Sampling als Nachgedanke behandelt – einfach eine Rate einstellen und vergessen – verschenkt einen großen Teil des Werts von OpenTelemetry. Intelligent konfiguriertes Sampling ist eine Architekturfrage: Welche Signals brauche ich wirklich? Welche Fehler dürfen niemals verloren gehen? Wie viel Budget habe ich für Speicherung und Transport?
Die gute Nachricht ist, dass das OpenTelemetry-Ökosystem 2026 die notwendigen Werkzeuge bereitstellt, um diese Fragen sauber zu beantworten. Tail-Based Sampling im Collector, Consistent Probability Sampling über W3C-Headers und erste adaptive Mechanismen erlauben Lösungen, die sowohl kostengünstig als auch informativ sind.
Bildquelle: Unsplash / Lars Kienle (Serverraum-Fotoarchiv)
Quellen
- OpenTelemetry Dokumentation: Sampling (opentelemetry.io/docs/concepts/sampling)
- OpenTelemetry Collector: Tail Sampling Processor (github.com/open-telemetry/opentelemetry-collector-contrib)
- Honeycomb: Refinery (refinery.honeycomb.io)
