Jitter hat zwei verwandte Bedeutungen. Im Netzwerk bezeichnet Jitter die Schwankung der Verzögerung zwischen Paketen oder Anfragen, auch Paketlaufzeitschwankung genannt, die besonders für Echtzeitverkehr wie Sprache und Video zählt. In verteilten Systemen ist Jitter bewusst eingefügter Zufall bei Retry-Backoff oder Zeitplänen, damit viele Clients nicht im selben Moment handeln.
Was Jitter ist
Jitter beschreibt unregelmäßiges Timing. Der Begriff wird in zwei Bedeutungen verwendet, die Ihnen im Betrieb regelmäßig begegnen und die Sie auseinanderhalten sollten:
- Netzwerk-Jitter ist unerwünschte Schwankung der Latenz. Kommen Pakete nach 20 ms, 22 ms, 61 ms und 19 ms an, wirkt der Durchschnitt unauffällig, die Streuung stört aber Echtzeitverkehr.
- Jitter bei Backoff und Zeitplänen ist erwünschter Zufall. Sie fügen ihn absichtlich hinzu, damit Retries, Cronjobs oder Cache-Aktualisierungen vieler Clients nicht exakt gleichzeitig stattfinden.
Beiden gemeinsam ist Timing, das um einen erwarteten Wert schwankt. Das eine ist ein Symptom, das Sie messen, das andere eine Technik, die Sie gezielt einsetzen.
Jitter im Netzwerk
Im Netzwerk heißt Jitter formal Paketlaufzeitschwankung (Packet Delay Variation). RFC 3393 der IETF definiert die IP Packet Delay Variation als Differenz der Einweg-Verzögerung ausgewählter Pakete, und RTP (RFC 3550) legt eine geglättete Interarrival-Jitter-Schätzung fest, die Empfänger an Sender melden. Typische Ursachen sind Warteschlangen in überlasteten Routern und Switches, Routenwechsel, Retransmissions im WLAN, konkurrierende Massentransfers und CPU-Konkurrenz auf virtualisierten Hosts.
Am stärksten betrifft Jitter Echtzeitanwendungen. Sprach- und Videoempfänger nutzen einen Jitter-Buffer, der Pakete kurz zurückhält, um sie gleichmäßig abzuspielen. Übersteigt der Jitter den Puffer, kommen Pakete zu spät und der Ton bricht ab. Für Sprache gilt ein Wert um 30 ms als verbreiteter Richtwert, Hersteller und Codecs unterscheiden sich aber. Bei Request/Response-APIs zeigt sich hoher Jitter als große Lücke zwischen Median und den hohen Perzentilen.
Jitter messen
| Methode | Aussage |
|---|---|
| Mittlere absolute Differenz aufeinanderfolgender Verzögerungen | Schwankung von Paket zu Paket, nah an der RTP-Definition |
| Standardabweichung der Latenz | Gesamtstreuung um den Mittelwert |
| Abstand zwischen p50 und p99 | Wie viel schlechter der Tail als der typische Fall ist |
Werkzeuge wie ping, mtr oder iperf3 im UDP-Modus | Ad-hoc-Messung entlang eines Pfads |
Messen Sie kontinuierlich von festen Messpunkten aus statt einmalig während eines Incidents. Nur so wissen Sie, wie normale Schwankung aussieht.
Jitter bei Retries: Exponential Backoff
Fällt eine Abhängigkeit aus, wiederholen Clients ihre Anfragen. Mit reinem exponentiellem Backoff warten alle Clients, die im selben Moment gescheitert sind, im Gleichschritt 1 s, 2 s, 4 s und so weiter, und jede Retry-Welle trifft den sich erholenden Service gleichzeitig. Jitter verteilt diese Wellen. Marc Brookers vielzitierter Artikel „Exponential Backoff And Jitter“ im AWS Architecture Blog vergleicht Varianten:
- Full Jitter:
sleep = random(0, min(cap, base * 2^attempt)) - Equal Jitter: die Hälfte des Backoffs fest, die andere Hälfte zufällig.
- Decorrelated Jitter:
sleep = min(cap, random(base, previous_sleep * 3))
In seinen Simulationen senkten Full und Decorrelated Jitter Gesamtarbeit und Abschlusszeit deutlich gegenüber Backoff ohne Jitter. Eine einfache Umsetzung:
import random, time
def retry(call, attempts=5, base=0.1, cap=5.0):
for attempt in range(attempts):
try:
return call()
except TransientError:
if attempt == attempts - 1:
raise
time.sleep(random.uniform(0, min(cap, base * 2 ** attempt)))Kombinieren Sie das mit einem Retry-Budget und einem Circuit Breaker, damit Retries ganz aufhören, wenn eine Abhängigkeit eindeutig ausgefallen ist. Beachten Sie außerdem Server-Hinweise wie den HTTP-Header Retry-After beim Rate Limiting.
Jitter in Zeitplänen
Dasselbe Thundering-Herd-Problem entsteht bei Zeitplänen. Starten Tausende Hosts einen Cronjob zur vollen Stunde oder laufen alle Cache-Einträge genau eine Stunde nach einem Deployment ab, entsteht in diesem Moment eine Lastspitze. Bewährte Gegenmittel sind eine zufällige Verzögerung vor dem Jobstart (systemd-Timer bieten dafür RandomizedDelaySec), zufällig gestreute Cache-TTLs wie 60 Minuten plus oder minus 10 % und die Verteilung pollender Clients über das Intervall. Prometheus nutzt dieselbe Idee beim Scraping, indem jedes Target innerhalb des Scrape-Intervalls versetzt abgefragt wird. Jitter ändert hier nicht die Menge der Arbeit, sondern nur ihren Zeitpunkt. Das genügt oft, um aus einer gefährlichen Spitze ein beherrschbares Plateau zu machen, ohne dass Sie zusätzliche Kapazität bereitstellen müssen.
Typische Fehler
Häufig wird nur die durchschnittliche Latenz überwacht und Jitter bleibt unsichtbar. Retries laufen ohne jede Zufallskomponente, oder alle Clients initialisieren ihren Zufallsgenerator identisch, sodass der „Jitter“ überall gleich ist. Ein weiterer Fehler: jede Schwankung für Netzwerk-Jitter zu halten, obwohl Garbage-Collection-Pausen oder CPU-Throttling auf dem Host die eigentliche Ursache sind. Prüfen Sie daher immer zuerst, ob die Schwankung im Netzwerk oder im Prozess selbst entsteht.
Wie Obseria unterstützt
Obseria bewahrt vollständige Latenzverteilungen aus Traces und Metriken auf, sodass der Abstand zwischen p50 und p99 im Zeitverlauf sichtbar wird, statt im Durchschnitt zu verschwinden. Das Netzwerk-Monitoring ergänzt den Blick auf den Netzwerkpfad, und synthetische Checks von über 50 Standorten liefern eine stabile Außensicht darauf, wie Antwortzeiten je Region schwanken.