Queue Monitoring für Kafka, RabbitMQ, SQS und Pub/Sub

Was ist Queue Monitoring?

Queue Monitoring bezeichnet die Überwachung von Message Brokern und Event-Streaming-Plattformen wie Apache Kafka, RabbitMQ, Amazon SQS und Google Cloud Pub/Sub, zusammen mit den Producern und Consumern, die sie nutzen. Es beantwortet die Fragen, ob Nachrichten fließen, wie schnell sie verarbeitet werden und ob irgendein Teil der Pipeline in Rückstand gerät. Die zentralen Kennzahlen sind Consumer Lag, Durchsatz, Nachrichtenalter und Fehlerraten.

Queues und Streams entkoppeln Services voneinander. Ein Producer kann ein Bestell-Event veröffentlichen, ohne darauf zu warten, dass Abrechnung, Versand und Analytics ihre Arbeit erledigt haben. Diese Entkopplung macht Systeme robuster, verbirgt aber auch Probleme: Wird ein Consumer langsamer, schlägt zunächst nichts fehl. Nachrichten stauen sich einfach an, bis die Verzögerung für Nutzer oder nachgelagerte Systeme sichtbar wird.

Warum Queue Monitoring wichtig ist

In ereignisgesteuerten Architekturen laufen viele Geschäftsprozesse asynchron: Zahlungen, Benachrichtigungen, Bestandsaktualisierungen, Datenpipelines. Ein wachsender Rückstau in einer einzigen Consumer Group kann bedeuten, dass E-Mails Stunden zu spät verschickt werden, Lagerbestände nicht stimmen oder Dashboards veraltete Daten zeigen. Weil der Producer weiterhin erfolgreich arbeitet, bemerkt klassisches, Request-basiertes Monitoring davon nichts.

Auch die Diagnose ist schwieriger als bei synchronen Aufrufen. Ursache eines Rückstaus kann eine langsame Datenbank hinter dem Consumer sein, eine Welle von Rebalances in Kafka, eine fehlerhafte Nachricht, die endlos wiederholt wird, oder schlicht mehr Traffic, als die Consumer bewältigen können. Queue Monitoring verbindet Broker-Metriken mit Traces auf Consumer-Seite, damit Sie diese Fälle schnell unterscheiden können und gezielt reagieren, statt pauschal weitere Consumer hinzuzufügen.

Wichtige Metriken für Queues und Streaming

Metrik	Warum sie wichtig ist
Consumer Lag	Anzahl der Nachrichten, die eine Consumer Group hinter dem neuesten Offset liegt; das wichtigste Signal für Rückstaus in Kafka.
Alter der ältesten Nachricht	Wie lange die älteste unverarbeitete Nachricht bereits wartet; direkt mit der für Nutzer sichtbaren Verzögerung verbunden.
Durchsatz ein- und ausgehend	Publish- und Consume-Raten; eine wachsende Differenz bedeutet einen wachsenden Rückstau.
Verarbeitungsdauer	Zeit, die Consumer pro Nachricht oder Batch benötigen, gemessen über Traces.
Fehler und Redeliveries	Fehlgeschlagene Verarbeitung, negative Acknowledgements und Retries, die auf fehlerhafte Nachrichten oder gestörte Abhängigkeiten hinweisen.
Tiefe der Dead-Letter-Queue	Nachrichten, die nicht verarbeitet werden konnten und Aufmerksamkeit brauchen.
Broker-Zustand	Unterreplizierte oder Offline-Partitionen, Disk- und Speicher-Alarme, Anzahl der Verbindungen.

So funktioniert Queue Monitoring mit Obseria

Obseria erfasst Broker-Metriken aus selbst betriebenen Kafka- und RabbitMQ-Clustern über den Obseria Agent oder die Receiver des OpenTelemetry Collectors, auch wenn diese Cluster in Kubernetes laufen. Amazon SQS, Google Cloud Pub/Sub und weitere gemanagte Messaging-Dienste werden agentenlos überwacht, als Teil der Abdeckung von über 300 Cloud-Services. Alle Broker landen in einem gemeinsamen Datenmodell, sodass Dashboards und Alerts unabhängig von der Technologie gleich aufgebaut sind.

Auf Anwendungsseite schreibt die OpenTelemetry-Messaging-Instrumentierung den Trace-Kontext in die Message-Header. Obseria verknüpft Publish- und Process-Spans, sodass ein Trace den HTTP-Request zeigt, der ein Event erzeugt hat, die Wartezeit der Nachricht in der Queue und die anschließende Arbeit des Consumers. Obseria TopoGraph stellt Producer, Topics, Queues und Consumer als Abhängigkeitskarte dar. Wächst der Lag, prüft Obseria Intelligence Consumer-Fehler, Verarbeitungszeiten, nachgelagerte Abhängigkeiten und aktuelle Deployments und liefert eine Ursache samt Beweiskette.

Lag und Durchsatz fragen Sie mit OQL oder PromQL ab:

fetch metrics
| filter messaging.system == "kafka"
| summarize max(kafka.consumer_group.lag), by:{consumer_group, topic}

Best Practices für Queue Monitoring

1. Auf Lag-Trend und Nachrichtenalter alarmieren. Ein stabiler Lag ist oft unkritisch, ein stetig wachsender nicht. Das Nachrichtenalter spiegelt die Auswirkung auf Nutzer besser wider als reine Zählwerte.
2. SLOs für asynchrone Verarbeitung festlegen. Zum Beispiel: 99 % der Bestellungen werden innerhalb von 60 Sekunden nach Veröffentlichung verarbeitet.
3. Trace-Kontext in Headern weitergeben. Ohne ihn wird jede Queue zum blinden Fleck in Ihren Traces.
4. Dead-Letter-Queues beobachten. Werten Sie Wachstum als Signal und nicht als Ort, an dem Fehler in Vergessenheit geraten.
5. Mit Consumer-Skalierung korrelieren. Autoscaling, Rebalances und Deployments erklären plötzliche Lag-Änderungen häufig.