Ein Perzentil ist der Wert, unter dem ein bestimmter Prozentsatz der Messwerte liegt. In der Observability bedeutet eine p95- oder p99-Latenz, dass 95 bzw. 99 Prozent der Requests in dieser Zeit oder schneller abgeschlossen wurden. Perzentile machen das Verhalten im Long Tail sichtbar, das Mittelwerte verbergen, deshalb basieren SLOs und Latenz-Alerts meist darauf.
Was ist ein Perzentil?
Ein Perzentil sortiert Messwerte nach Größe und gibt den Wert an einer bestimmten Position aus. Das 50. Perzentil (p50, der Median) teilt die Requests in eine schnellere und eine langsamere Hälfte. Das 99. Perzentil (p99) ist die Dauer, die 99 Prozent der Requests erreichen oder unterschreiten; nur das langsamste Prozent liegt darüber. Im Monitoring werden Perzentile fast immer auf Latenz angewendet, sie funktionieren aber für jede Verteilung: Payload-Größen, Wartezeiten in Queues oder Ladezeiten im Real User Monitoring.
Üblich sind p50, p90, p95, p99 und p99.9. Je weiter Sie in den Long Tail gehen, desto mehr Daten brauchen Sie für einen stabilen Wert: Ein p99.9 aus 200 Requests ist schlicht der langsamste Request.
Wie Perzentile berechnet werden
Bei n sortierten Werten nimmt die Nearest-Rank-Methode den Wert an Rang ceil(p / 100 × n). Bei 1.000 Requests ist p99 der 990. schnellste Request, p50 der 500. Andere Verfahren interpolieren zwischen benachbarten Rängen, deshalb liefern Werkzeuge für dieselben Daten teils leicht unterschiedliche Werte.
Jeden Rohwert zu speichern skaliert nicht, daher schätzen Monitoring-Systeme Perzentile aus Histogrammen. Ein Histogramm zählt Messungen pro Bucket (zum Beispiel 0 bis 100 ms, 100 bis 250 ms, 250 bis 500 ms). Die Prometheus-Funktion histogram_quantile() sucht den Bucket mit dem Zielrang und interpoliert darin linear; die Genauigkeit hängt also von den Bucket-Grenzen ab. Exponentielle Histogramme in OpenTelemetry skalieren ihre Buckets automatisch und halten den relativen Fehler ohne manuelle Abstimmung klein.
Warum Mittelwerte täuschen
Latenzverteilungen sind schief: Die meisten Requests sind schnell, wenige sehr langsam. Der Mittelwert vermischt beide Gruppen zu einer Zahl, die kaum einen Request beschreibt. Ein Beispiel mit 1.000 Requests zur Veranschaulichung:
| Requests | Dauer |
|---|---|
| 900 | 80 ms |
| 90 | 400 ms |
| 10 | 3.000 ms |
Der Mittelwert beträgt (900 × 80 + 90 × 400 + 10 × 3.000) / 1.000 = 138 ms und wirkt unauffällig. Die Perzentile erzählen etwas anderes: p50 = 80 ms, p95 = 400 ms, p99 = 400 ms und p99.9 = 3.000 ms. Jeder zehnte Request ist fünfmal langsamer als der Median, jeder hundertste dauert drei Sekunden. Genau diese Nutzer brechen einen Checkout ab.
Fan-out verstärkt den Long Tail
Hängt eine Seite oder ein API-Aufruf von vielen Backend-Requests ab, wird der langsame Tail zum Normalfall. Macht eine Seite 100 unabhängige Backend-Aufrufe, von denen jeder mit 1 Prozent Wahrscheinlichkeit p99-Latenz erreicht, liegt die Wahrscheinlichkeit, dass mindestens ein Aufruf so langsam ist, bei 1 − 0,99 hoch 100, also rund 63 Prozent. Das p99 des Backends wird zur typischen Erfahrung der Nutzer.
Aggregationsregeln, die Sie kennen sollten
- Perzentile niemals mitteln. Der Mittelwert der p99-Werte von zehn Pods ist nicht das p99 des Services. Ein Pod mit wenig Traffic zählt so viel wie ein ausgelasteter, und selbst bei gleichem Traffic geht die Rechnung nicht auf.
- Erst Histogramme aggregieren, dann rechnen. Summieren Sie die Bucket-Zähler über alle Instanzen und leiten Sie erst danach das Perzentil ab. Genau deshalb sind Histogramme clientseitigen Summaries überlegen.
- Auf das Zeitfenster achten. Ein p99 über fünf Minuten und eines über 30 Tage beantworten unterschiedliche Fragen. SLOs zählen meist gute gegenüber allen Ereignissen über das gesamte Fenster, statt kurzfristige Perzentile zu mitteln.
Best Practices
- Erfassen Sie pro Endpunkt mindestens p50, p95 und p99 sowie die Request-Rate, damit klar ist, wie viele Nutzer ein Perzentil repräsentiert.
- Definieren Sie SLOs als Schwellenwert-Anteile, etwa „99 Prozent der Requests schneller als 300 ms“. Diese lassen sich leicht aggregieren und erklären.
- Legen Sie Bucket-Grenzen um Ihre SLO-Schwellen herum oder nutzen Sie exponentielle Histogramme.
- Teilen Sie Perzentile nach sinnvollen Dimensionen wie Route, Region oder Kundensegment auf, halten Sie die Kardinalität aber begrenzt.
- Nutzen Sie Exemplars, um von einem langsamen Bucket direkt zu einem repräsentativen Trace zu springen.
Typische Fehler
- Auf die durchschnittliche Latenz alarmieren und dadurch Regressionen übersehen, die nur den Tail betreffen.
- p99.9 für Endpunkte mit wenig Traffic berichten, bei denen ein einziger Request den Wert bestimmt.
- Perzentile aus Werkzeugen vergleichen, die unterschiedliche Berechnungs- oder Interpolationsverfahren verwenden.
- Fehler oder Timeouts aus den Latenzdaten herausfiltern, wodurch der Tail besser aussieht, als er ist.
Wie Obseria unterstützt
Obseria speichert Latenzen als Histogramme, einschließlich exponentieller OpenTelemetry-Histogramme. So lassen sich p50 bis p99.9 zur Abfragezeit über beliebige Dimensionen korrekt berechnen und aggregieren. Perzentil-Charts führen direkt zu den zugrunde liegenden Traces im Distributed Tracing, und Obseria Intelligence lernt pro Endpunkt eine Baseline, um Regressionen im Tail zu melden, bevor sie Ihr Error Budget aufzehren.
