Queue Depth (Warteschlangentiefe) ist die Anzahl der Elemente, etwa Nachrichten, Jobs, Requests oder I/O-Operationen, die zu einem Zeitpunkt in einer Warteschlange warten. Zusammen mit der Ankunfts- oder Abarbeitungsrate zeigt sie, wie lange neue Arbeit wartet. Eine stetig wachsende Queue Depth bedeutet, dass die Consumer mit den Producern nicht mithalten.
Was ist Queue Depth?
Queue Depth, auf Deutsch Warteschlangentiefe oder Warteschlangenlänge, ist die Zahl der Elemente, die in einer Queue auf ihre Verarbeitung warten. Das können Nachrichten in Kafka, RabbitMQ oder Amazon SQS sein, Jobs in einer Worker-Queue, Requests, die auf einen freien Thread warten, oder I/O-Operationen vor einem Datenträger. Überall dort, wo ein Puffer Producer und Consumer entkoppelt, ist die Queue Depth das direkteste Maß dafür, wie weit die Verarbeitung hinterherhinkt.
Im Sinne der Golden Signals ist Queue Depth ein Signal für Sättigung: Eine Queue, die meist fast leer ist, bedeutet freie Kapazität. Eine wachsende Queue bedeutet, dass mehr Arbeit ankommt, als verarbeitet werden kann.
Queue Depth und Wartezeit: Little's Law
Den Zusammenhang zwischen Warteschlangentiefe und Wartezeit beschreibt Little's Law aus der Warteschlangentheorie:
L = λ × W
L = mittlere Anzahl Elemente im System (Queue Depth)
λ = mittlere Ankunftsrate (Elemente pro Sekunde)
W = mittlere Verweildauer eines Elements im SystemDas Gesetz gilt für jedes stabile System über einen ausreichend langen Zeitraum, unabhängig von der Verteilung der Ankünfte. Umgestellt zu W = L / λ übersetzt es eine Queue Depth in eine erwartete Wartezeit. Im eingeschwungenen Zustand entspricht die Ankunftsrate der Abgangsrate, Sie können also auch den Durchsatz der Consumer verwenden.
Ein illustratives Beispiel: In einer Queue liegen 12.000 Nachrichten, die Consumer verarbeiten 400 Nachrichten pro Sekunde. Neue Nachrichten warten also etwa 12.000 / 400 = 30 Sekunden, bis sie abgeholt werden. Liegt Ihr End-to-End-Ziel bei 10 Sekunden, brauchen Sie den dreifachen Durchsatz oder einen kleineren Rückstau.
Warum Queues nahe der Kapazitätsgrenze so schnell wachsen
Die Warteschlangentheorie erklärt auch, warum Rückstaus plötzlich entstehen. Nähert sich die Auslastung der Consumer 100 Prozent, steigt die mittlere Wartezeit nicht linear, sondern steil an: Im einfachen M/M/1-Modell beträgt die erwartete Verweildauer 1 / (μ − λ), wobei μ die Bedienrate ist. Der Schritt von 80 auf 95 Prozent Auslastung vervierfacht die Wartezeit ungefähr. Liegt die Ankunftsrate längere Zeit über der Bedienrate, wächst die Queue unbegrenzt. Deshalb kann ein System, das bei 80 Prozent unauffällig wirkt, nach einem moderaten Traffic-Anstieg weit zurückfallen.
Was Sie messen sollten
| Metrik | Aussage | Beispiele |
|---|---|---|
| Queue Depth / Backlog | Wie viel Arbeit wartet | SQS ApproximateNumberOfMessagesVisible, RabbitMQ Ready Messages |
| Consumer Lag | Wie weit Consumer hinter dem neuesten Offset liegen | Kafka-Lag pro Partition und Consumer Group |
| Alter des ältesten Elements | Wie lange das ungünstigste Element bereits wartet | SQS ApproximateAgeOfOldestMessage |
| Ankunfts- und Abarbeitungsrate | Ob der Rückstau wächst oder schrumpft | Eingehende vs. bestätigte Nachrichten pro Sekunde |
| Tiefe der Dead-Letter-Queue | Wie viele Elemente endgültig fehlgeschlagen sind | Anzahl Nachrichten in der DLQ |
Die Tiefe allein ist mehrdeutig: 50.000 Nachrichten sind harmlos für eine Consumer Group, die 20.000 pro Sekunde abarbeitet, und kritisch für eine, die 50 schafft. Lesen Sie die Tiefe deshalb immer zusammen mit der Abarbeitungsrate oder dem Alter der ältesten Nachricht.
Alerting und Autoscaling auf Basis der Queue Depth
- Auf Zeit alarmieren, nicht auf Anzahl. Das Alter der ältesten Nachricht oder die geschätzte Wartezeit (
Tiefe / Abarbeitungsrate) entspricht direkt der Nutzerauswirkung und Ihrem SLO. - Auf den Trend alarmieren. Ein Rückstau, der seit 15 Minuten kontinuierlich wächst, ist aussagekräftiger als eine kurze Spitze nach einem Burst.
- Consumer nach Backlog skalieren. Werkzeuge wie KEDA in Kubernetes skalieren Worker nach Queue-Länge oder Consumer Lag. Teilen Sie den Backlog durch den Durchsatz pro Worker, um die Ziel-Replica-Zahl zu erhalten.
- Downstream-Grenzen beachten. Mehr Consumer erhöhen die Last auf Datenbank oder API, in die sie schreiben. Skalieren Sie nur im Rahmen der langsamsten Abhängigkeit.
- Die Queue begrenzen. Unbegrenzte Queues verbergen Überlast, bis der Speicher voll ist. Eine begrenzte Queue mit Backpressure oder Rate Limiting scheitert sichtbar und früh.
Typische Fehler
- Eine tiefe Queue als Consumer-Problem behandeln, obwohl eine langsame Downstream-Abhängigkeit der eigentliche Engpass ist. Traces über Producer, Queue und Consumer zeigen, wo die Zeit verloren geht.
- Nur den Gesamt-Lag eines Topics überwachen, nicht den pro Partition. So bleibt eine einzelne heiße Partition unsichtbar.
- Die Dead-Letter-Queue ignorieren, bis sie Tage an fehlgeschlagenen Bestellungen enthält.
- Feste Schwellwerte für die Tiefe verwenden, obwohl der normale Rückstau stark von der Tageszeit abhängt. Eine Baseline oder Anomalieerkennung berücksichtigt Saisonalität besser.
Wie Obseria hilft
Obseria erfasst Broker- und Consumer-Metriken wie Tiefe, Lag und Nachrichtenalter und verknüpft sie mit den Traces von Producern und Consumern. So sehen Sie, ob ein Rückstau aus einem Traffic-Burst, langsamen Consumern oder einer fehlerhaften Abhängigkeit stammt. Das Queue Monitoring von Obseria deckt Broker wie Kafka ab, und die Anomalieerkennung lernt normale Backlog-Muster. Mehr dazu unter Kafka Monitoring.
