Latenz ist die Zeit zwischen dem Start einer Operation und ihrem Abschluss, etwa vom Senden eines Requests bis zum Empfang der Antwort. In der Observability wird Latenz als Verteilung gemessen und mit Perzentilen wie p50, p95 und p99 angegeben, weil Durchschnittswerte die langsamen Ausreißer verbergen, die Nutzer am stärksten wahrnehmen. Sie ist eines der vier Golden Signals.
Was Latenz bedeutet
Latenz beschreibt, wie lange etwas dauert. Im Networking meint der Begriff oft die Verzögerung, bis Daten von einem Punkt zum anderen gelangen, etwa die Round-Trip-Time. In der Anwendungs-Observability ist Latenz meist die Dauer eines Requests oder einer Operation aus Sicht des Aufrufers: vom Senden eines HTTP-Requests bis zum Eintreffen der vollständigen Antwort, oder die Dauer einer Datenbankabfrage, eines Funktionsaufrufs oder der Verarbeitung einer Queue-Nachricht.
Streng genommen unterscheiden manche Engineers Latenz (Wartezeit, bevor die Arbeit beginnt) von Antwortzeit (Wartezeit plus Bearbeitungszeit). Im Monitoring-Alltag werden beide Begriffe meist für die End-to-End-Dauer verwendet. Latenz ist eines der vier Golden Signals, neben Traffic, Fehlern und Sättigung.
Warum Durchschnittswerte täuschen
Latenzverteilungen sind selten symmetrisch. Die meisten Requests sind schnell, ein langer Ausläufer ist langsam, etwa wegen Cache-Misses, Garbage Collection, Lock-Konflikten, Retries oder langsamer Abhängigkeiten. Ein Durchschnitt vermischt all das. Nehmen wir als Beispiel 1.000 Requests, von denen 980 jeweils 100 ms und 20 jeweils 3 Sekunden dauern: Der Mittelwert liegt bei 158 ms und wirkt unauffällig, doch jeder fünfzigste Nutzer wartet 3 Sekunden.
Deshalb wird Latenz in Perzentilen angegeben. Das p50 (Median) beschreibt das typische Erlebnis, p95 und p99 den langsamen Ausläufer. Perzentile lassen sich nicht über Instanzen mitteln, sie müssen aus der kombinierten Verteilung berechnet werden. Darum sind Histogramme der bevorzugte Metriktyp für Latenz.
Tail Latency und Fan-out
In verteilten Systemen ist Tail Latency noch wichtiger. Verzweigt sich ein Nutzer-Request auf viele Backend-Aufrufe, bestimmt der langsamste Aufruf die Gesamtantwortzeit. Das Google-Paper „The Tail at Scale“ veranschaulicht das: Berührt ein Request 100 Server und ist jeder Server in 1 % der Fälle langsam, trifft rund 63 % der Nutzer-Requests mindestens ein langsamer Server, denn 1 − 0,99 hoch 100 ≈ 0,63. Das p99 einzelner Services zu senken, ist daher einer der wirksamsten Hebel, um den Median des End-to-End-Erlebnisses zu verbessern.
Latenz messen
| Quelle | Was gemessen wird | Geeignet für |
|---|---|---|
| Histogramm-Metriken | Verteilung pro Service, Endpoint oder Route | Dashboards, SLOs, Alerting auf Perzentile |
| Distributed Traces | Aufschlüsselung je Request über Services und Spans | Herausfinden, wo die Zeit verbraucht wird |
| Real User Monitoring | Latenz, wie sie in Browsern und Apps erlebt wird | Wahrgenommene Performance, Regionen, Geräte |
| Synthetische Checks | Latenz skriptgesteuerter Requests von festen Standorten | Baseline-Vergleiche, Verfügbarkeit außerhalb von Lastspitzen |
Messen Sie so nah am Nutzer wie möglich. Serverseitige Latenz enthält weder Netzwerkzeit noch TLS-Handshakes oder Client-Rendering. Lasttests sollten zudem Coordinated Omission vermeiden: Wartet ein Lastgenerator auf langsame Antworten, bevor er den nächsten Request sendet, weist er die Tail Latency zu niedrig aus.
Beispiel: eine Latenz-Aufschlüsselung lesen
In einem beispielhaften Fall steigt das p99 einer Such-API nach einem Release von 600 ms auf 1,4 Sekunden, während das p50 bei 120 ms bleibt. Ein Trace aus dem langsamen Ausläufer zeigt den Server-Span bei 1,35 Sekunden, davon 1,1 Sekunden in einem Kind-Span, der einen Empfehlungsdienst aufruft. Dessen eigenes p99 liegt nur bei 200 ms, doch der Trace zeigt fünf aufeinanderfolgende Aufrufe statt eines gebündelten. Die Lösung ist eine Codeänderung in der Such-API, nicht mehr Kapazität für den Empfehlungsdienst. Ohne die Aufschlüsselung nach Spans hätte das Team womöglich die falsche Komponente skaliert.
Typische Ursachen hoher Latenz
- Sättigung und Warteschlangen. Nähert sich die Auslastung der Kapazitätsgrenze, wachsen Warteschlangen und die Latenz steigt steil an, lange bevor die CPU 100 % erreicht.
- Langsame Abhängigkeiten wie Datenbanken, Drittanbieter-APIs oder überlastete nachgelagerte Services.
- Ineffiziente Codepfade, etwa N+1-Queries, Serialisierungs-Overhead oder Lock-Konflikte, sichtbar in Continuous Profiles.
- Pausen der Laufzeitumgebung wie Garbage Collection oder Cold Starts bei Serverless-Funktionen.
- Netzwerkeffekte: regionsübergreifende Aufrufe, DNS-Auflösung, Retransmits und Verbindungsaufbau.
Best Practices
- Latenz-SLOs auf Perzentile definieren, etwa „99 % der Checkout-Requests sind nach 800 ms abgeschlossen“, statt auf Durchschnittswerte.
- Latenz als Histogramm erfassen, mit Buckets, die Ihre SLO-Schwellen abdecken, und Exemplars nutzen, um zu langsamen Traces zu springen.
- Erfolgreiche und fehlgeschlagene Requests trennen. Schnelle Fehler lassen die Latenz besser aussehen, als sie ist.
- Timeouts und Budgets entlang der Aufrufkette setzen, damit eine langsame Abhängigkeit nicht das gesamte Request-Budget aufbraucht.
- Mit einer Baseline vergleichen, um schleichende Regressionen nach Releases zu erkennen.
Wie Obseria unterstützt
Obseria erfasst Latenzverteilungen für jeden Service und Endpoint aus OpenTelemetry-Traces und -Metriken, und das Distributed Tracing zeigt, welcher Span die Zeit verbraucht hat. Real User Monitoring ergänzt die Perspektive aus Browser und Mobile-App, und SLOs auf Perzentil-Latenz bringen Burn-Rate-Alerting mit. Wie Sie Ziele definieren, erklärt Was ist ein SLO?.