Fehlerbehebung bei RabbitMQ: Diagnose von Warteschlangen- und Nachrichtenproblemen mit Befehlen

Wenn eine RabbitMQ-Warteschlange festzustecken scheint, ist der schlechteste erste Schritt normalerweise, sie zu leeren. Der zweitschlechteste Schritt ist, den Broker neu zu starten und zu hoffen, dass sich das Problem von selbst löst. Die meisten Warteschlangenprobleme hinterlassen eine Spur: bereite Nachrichten, nicht bestätigte Nachrichten, fehlende Consumer, blockierte Publisher, nicht routingfähige Nachrichten, eine sich leise füllende Dead-Letter-Warteschlange oder ein Consumer, der verbunden ist, aber nichts bestätigt.

Dieser Leitfaden verwendet RabbitMQ-Befehle, um dies vom Terminal aus einzugrenzen. Ich verlasse mich auf rabbitmqctl für den Broker-seitigen Zustand und rabbitmqadmin, wenn Sie Management-API-Operationen benötigen, wie z. B. das sichere Abtasten einer Nachricht. Die Beispiele gehen vom Standard-Virtual-Host aus, sofern keine -p <vhost>-Option angegeben ist. In realen Systemen geben Sie immer den Vhost an; viele Fehldiagnosen entstehen, weil jemand / überprüft, während die Anwendung payments oder prod verwendet.

Grundlegendes zu rabbitmqctl

Der Befehl rabbitmqctl fungiert als Kommandozeilenschnittstelle (CLI) für die Interaktion mit der RabbitMQ-Managementebene. Er ermöglicht Ihnen die Verwaltung von Benutzern, Berechtigungen, Exchanges, Warteschlangen, Bindungen und, am wichtigsten für die Fehlerbehebung, die Untersuchung der Laufzeitstatistiken des Brokers.

Hinweis zur Ausführung: Die meisten Befehle erfordern Root-Rechte oder der Benutzer, der den Befehl ausführt, muss Mitglied der rabbitmq-Gruppe sein, oder Sie müssen möglicherweise sudo verwenden.

Diagnose von Warteschlangenrückständen und feststeckenden Nachrichten

Eines der häufigsten Probleme ist eine wachsende Warteschlange, was darauf hindeutet, dass Nachrichten schneller produziert als verbraucht werden oder dass Consumer die Verarbeitung eingestellt haben.

Beginnen Sie mit der Warteschlange, aber fragen Sie nach den richtigen Spalten

Die Standardausgabe von list_queues ist für die Fehlerbehebung zu dünn. Fragen Sie nach den Spalten, die "wartet auf Zustellung" von "zugestellt, aber nicht bestätigt" trennen.

rabbitmqctl -p / list_queues name messages_ready messages_unacknowledged messages consumers state

Lesen Sie es so:

Symptom	Wahrscheinliche Bedeutung
messages_ready wächst, consumers ist 0	Kein aktiver Consumer ist für die Warteschlange abonniert. Überprüfen Sie Bereitstellungen, Anmeldeinformationen, Vhost und Warteschlangennamen.
messages_ready wächst, Consumer vorhanden	Consumer sind zu langsam, blockiert oder der Prefetch ist für die Arbeitslast zu niedrig.
messages_unacknowledged hoch und stabil	Consumer haben Nachrichten erhalten, bestätigen sie aber nicht. Suchen Sie nach feststeckenden Handlern oder einem zu hohen Prefetch-Wert.
state ist nicht running	Die Warteschlange ist möglicherweise nicht verfügbar, synchronisiert oder von einem Knotenproblem betroffen. Überprüfen Sie den Cluster- und Warteschlangen-Leader-Status.

Fügen Sie für Quorum-Warteschlangen Leader- und Mitgliedschaftsspalten hinzu:

rabbitmqctl -p / list_queues name type leader members online messages_ready messages_unacknowledged consumers state

Das ist wichtig, weil eine Warteschlange gesunde Consumer auf einem Knoten haben kann, während der Leader woanders ist, oder eine Quorum-Warteschlange darauf wartet, dass genügend Mitglieder online kommen.

Wenn die Liste lang ist, filtern Sie mit Standard-Shell-Tools:

rabbitmqctl -p / list_queues name messages_ready messages_unacknowledged consumers state \
  | awk '$2 > 0 || $3 > 0 || $4 == 0'

Überprüfen Sie, ob der Broker Publisher blockiert

rabbitmqctl status
rabbitmq-diagnostics alarms

Speicher- und Datenträgeralarme bedeuten nicht, dass die Warteschlange falsch konfiguriert ist, aber sie erklären viele Vorfälle, bei denen "nichts sich bewegt". Wenn RabbitMQ einen Speicher- oder Datenträgerfreiplatzalarm auslöst, kann es Publishing-Verbindungen blockieren. Consumer können möglicherweise weiterhin Nachrichten abrufen, sodass das sichtbare Symptom ungleichmäßig sein kann: Einige Warteschlangen schrumpfen, andere hören auf, neue Arbeit zu erhalten, und Publisher erhalten Zeitüberschreitungen.

Überprüfen Sie auch Listener und Knotenzustand:

rabbitmq-diagnostics ping
rabbitmq-diagnostics listeners
rabbitmq-diagnostics check_running
rabbitmq-diagnostics check_local_alarms

Untersuchen Sie Consumer ohne zu raten

list_connections sagt Ihnen, wer verbunden ist. list_channels sagt Ihnen, ob diese Verbindungen Kanäle geöffnet haben und wie viel Arbeit sie halten.

rabbitmqctl list_connections name user peer_host peer_port state channels recv_oct send_oct
rabbitmqctl list_channels connection name number consumer_count messages_unacknowledged prefetch_count state

Die nützlichen Muster sind einfach:

• Keine Verbindung vom erwarteten Host: Die Anwendung ist ausgefallen, kann den Broker nicht auflösen, kann sich nicht authentifizieren oder stellt eine Verbindung zu einer anderen Umgebung her.
• Verbindung vorhanden, aber keine Kanäle: Der Client hat eine Verbindung hergestellt und ist dann fehlgeschlagen, bevor er deklariert oder konsumiert hat.
• Kanäle vorhanden, aber consumer_count ist 0: Die App veröffentlicht möglicherweise nur, oder das Consumer-Abonnement ist fehlgeschlagen.
• messages_unacknowledged ist auf einem Kanal hoch: Dieser Consumer hat Arbeit im Speicher und gibt keine schnellen Bestätigungen zurück.

Wenn Sie benannte Verbindungen verwenden, fügen Sie connection_name in Ihre Client-Konfiguration ein. Eine Zeile wie 10.42.8.17:52344 -> 10.42.1.20:5672 ist weniger hilfreich als billing-worker-7.

Überprüfen Sie Bindungen, bevor Sie Consumer beschuldigen

Wenn eine Warteschlange leer ist, die Anwendung aber sagt, dass sie Nachrichten veröffentlicht hat, ist das Routing der nächste Ort, an dem Sie suchen sollten.

rabbitmqctl -p / list_exchanges name type durable auto_delete internal arguments
rabbitmqctl -p / list_bindings source_name source_kind destination_name destination_kind routing_key arguments

Ein Direct-Exchange erfordert eine exakte Übereinstimmung des Routing-Keys. Ein Topic-Exchange verwendet * für ein Wort und # für null oder mehr Wörter. Ein Fanout-Exchange ignoriert Routing-Keys. Wenn der Exchange keine passende Bindung und keinen Alternate-Exchange hat, ist die Nachricht nicht routingfähig. Sie wartet nicht heimlich irgendwo.

Für die Publisher-seitige Bestätigung verwenden Sie obligatorisches Publishing und behandeln Sie zurückgegebene Nachrichten im Client. Auf der Broker-Seite sind die Management-UI und Metriken normalerweise besser als rabbitmqctl für Raten, aber list_bindings reicht aus, um die häufigsten Fehler zu erkennen: falscher Vhost, falscher Exchange, falsch geschriebener Routing-Key oder eine Warteschlange, die nach einer Bereitstellung an den alten Exchange gebunden ist.

Tasten Sie eine Nachricht sicher ab

Es gibt keinen allgemeinen rabbitmqctl queue_get-Befehl in modernem RabbitMQ. Verwenden Sie das Management-Plugin über rabbitmqadmin oder die HTTP-API. Tun Sie dies vorsichtig: Abhängig vom Bestätigungsmodus kann das Abrufen von Nachrichten diese entfernen oder erneut in die Warteschlange einreihen.

rabbitmqadmin -V / get queue=orders.pending count=3 ackmode=ack_requeue_true

Verwenden Sie dies, um enge Fragen zu beantworten: Ist die Nutzdaten gültiges JSON, ist der Nachrichtentyp das, was der Consumer erwartet, fehlt ein erforderlicher Header, ist der Routing-Key der, den das Produzententeam angegeben hat? Verwenden Sie es nicht als Masseninspektionswerkzeug in einer geschäftigen Produktionswarteschlange.

Achten Sie auf Dead-Letter-Bewegungen

Verzögerte Verarbeitung zeigt sich oft als eine leise wachsende Dead-Letter-Warteschlange.

rabbitmqctl -p / list_queues name messages_ready messages_unacknowledged arguments policy
rabbitmqctl -p / list_bindings source_name destination_name routing_key arguments \
  | grep -E 'dead|dlx|retry|parking'

Warteschlangenargumente wie x-dead-letter-exchange, x-dead-letter-routing-key, x-message-ttl, x-max-length und x-overflow ändern, wohin Nachrichten gehen, wenn sie ablaufen, abgelehnt werden oder Längenlimits erreichen. Wenn die Anwendung durch Dead-Lettering über Verzögerungswarteschlangen wiederholt, kann eine schlechte Bindung eine Schleife erzeugen. Das Symptom sieht aus wie "verzögerte Nachrichten", aber das eigentliche Problem ist, dass Nachrichten zwischen Warteschlangen zirkulieren, anstatt eine endgültige Verarbeitungswarteschlange oder eine Parkplatzwarteschlange zu erreichen.

Eine praktische Befehlskette

Wenn jemand meldet, dass "Bestellungen feststecken", führe ich normalerweise diese Sequenz aus:

rabbitmq-diagnostics ping
rabbitmq-diagnostics check_local_alarms
rabbitmqctl -p orders list_queues name type messages_ready messages_unacknowledged consumers state
rabbitmqctl list_connections name user peer_host state channels
rabbitmqctl list_channels connection consumer_count messages_unacknowledged prefetch_count state
rabbitmqctl -p orders list_bindings source_name destination_name routing_key arguments

Wenn messages_ready hoch und consumers null ist, gehen Sie zur Consumer-Bereitstellung. Wenn messages_unacknowledged hoch ist, gehen Sie zu den Consumer-Protokollen und Prefetch-Einstellungen. Wenn die Warteschlange leer ist, aber Publisher Erfolg melden, überprüfen Sie Bindungen und Publisher-Bestätigungen. Wenn Alarme aktiv sind, beheben Sie den Broker-Ressourcendruck, bevor Sie der Anwendungslogik nachjagen. Dies hält die Untersuchung auf dem Boden dessen, was der Broker tatsächlich tut.