So überwachen Sie den RabbitMQ-Knotenstatus und Verbindungen mit rabbitmqctl

RabbitMQ erhält normalerweise erst dann Aufmerksamkeit, wenn eine Warteschlange blockiert, ein Verbraucher aufhört, Nachrichten zu bestätigen, oder eine Bereitstellung Hunderte zusätzlicher Verbindungen erzeugt. rabbitmqctl ist immer noch eine der schnellsten Möglichkeiten, um zu überprüfen, was der Broker von innerhalb des Knotens sieht. Es wird Prometheus, die Management-Oberfläche oder die Protokollüberprüfung nicht ersetzen, aber es bietet Ihnen eine zuverlässige Befehlszeilenansicht, wenn Sie auf einem Server sind und schnell Antworten benötigen.

Grundlegendes zu rabbitmqctl

Das Skript rabbitmqctl ist die primäre Befehlszeilenschnittstelle für die Interaktion mit einem RabbitMQ-Knoten. Es ermöglicht Administratoren, eine Vielzahl von Aufgaben auszuführen, vom Starten und Stoppen des Brokers bis zur Verwaltung von Benutzern, Berechtigungen, Exchanges, Warteschlangen und, entscheidend für diesen Artikel, der Überwachung des Betriebsstatus des Knotens und seiner Netzwerkaktivität.

Überprüfen des RabbitMQ-Knotenstatus

Bevor Sie sich mit Verbindungen befassen, ist es wichtig zu überprüfen, ob Ihr RabbitMQ-Knoten läuft. Der Befehl status bietet einen umfassenden Überblick über den aktuellen Zustand des Knotens.

Der Befehl rabbitmqctl status

Dieser Befehl gibt eine Fülle von Informationen aus, darunter:

• Knotenname: Der Name des RabbitMQ-Knotens.
• Laufende Anwendungen: Listet die laufenden Erlang-Anwendungen auf, wobei RabbitMQ selbst ein wichtiger Indikator ist.
• Speichernutzung: Details zur Speicherzuweisung und -nutzung, entscheidend für die Leistungsoptimierung.
• Festplattenspeicher: Informationen über den verfügbaren Festplattenspeicher, der die Nachrichtenpersistenz beeinflussen kann.
• Dateideskriptoren: Die Anzahl der geöffneten Dateideskriptoren, eine wichtige Systemressource.
• Netzwerkinformationen: Details zu Netzwerkschnittstellen und Ports.
• Clusterstatus: Informationen darüber, ob der Knoten Teil eines Clusters ist und dessen Konnektivität.
• Listener: Ports, auf denen RabbitMQ für verschiedene Protokolle (AMQP, Management-UI usw.) lauscht.

Beispielverwendung:

rabbitmqctl status

Interpretieren der Ausgabe: Achten Sie auf Anzeichen von Ressourcenerschöpfung (hoher Speicher, wenig Festplattenspeicher, hohe Dateideskriptornutzung) und bestätigen Sie, dass wichtige Anwendungen wie rabbit ausgeführt werden. Der Abschnitt listeners ist entscheidend, um sicherzustellen, dass RabbitMQ auf den erwarteten Ports erreichbar ist.

Überwachen von Verbindungen, Kanälen und Verbrauchern

Zu verstehen, wie Clients mit Ihrem RabbitMQ-Knoten interagieren, ist der Schlüssel zur Fehlerbehebung und Leistungsanalyse. rabbitmqctl bietet Befehle zum Auflisten und Inspizieren dieser Entitäten.

Auflisten von Verbindungen (rabbitmqctl list_connections)

Dieser Befehl zeigt alle aktiven Client-Verbindungen zum RabbitMQ-Knoten an. Jede Verbindung repräsentiert eine Client-Anwendung (Produzent oder Verbraucher), die erfolgreich verbunden wurde.

Befehl:

rabbitmqctl list_connections

Ausgabespalten (üblich):

• pid: Die Erlang-Prozesskennung für die Verbindung.
• node: Der Knoten, auf dem die Verbindung hergestellt wurde.
• name: Der Name der Verbindung (spiegelt oft Client-Eigenschaften wider).
• port: Der Port, mit dem der Client verbunden ist.
• host: Der Host, von dem der Client verbunden ist.
• user: Der für die Authentifizierung verwendete Benutzername.
• vhost: Der virtuelle Host, dem die Verbindung zugeordnet ist.
• ssl: Gibt an, ob die Verbindung SSL/TLS verwendet.
• protocol: Das verwendete Protokoll (z. B. amqp0-9-1).

Beispiel:

rabbitmqctl list_connections name host port user vhost protocol

Damit können Sie sehen, welche Benutzer verbunden sind, von wo aus und welche virtuellen Hosts sie verwenden.

Auflisten von Kanälen (rabbitmqctl list_channels)

Jede Verbindung kann mehrere Kanäle haben. Kanäle sind leichtgewichtige, multiplexierte Verbindungen über eine einzige TCP-Verbindung, die für AMQP-Operationen verwendet werden.

Befehl:

rabbitmqctl list_channels

Ausgabespalten (üblich):

• connection: Die pid der übergeordneten Verbindung.
• node: Der Knoten, auf dem sich der Kanal befindet.
• channel_pid: Die Erlang-Prozesskennung für den Kanal.
• vhost: Der virtuelle Host, dem der Kanal zugeordnet ist.
• name: Der Name des Kanals (falls vom Client festgelegt).
• consumer_count: Die Anzahl der auf diesem Kanal aktiven Verbraucher.
• messages_unacknowledged: Die Anzahl der nicht bestätigten Nachrichten auf diesem Kanal.
• messages_ready: Die Anzahl der Nachrichten, die zur Zustellung auf diesem Kanal bereit sind.

Beispiel:

rabbitmqctl list_channels connection vhost consumer_count messages_ready messages_unacknowledged

Die Überwachung von messages_unacknowledged und messages_ready ist entscheidend, um potenzielle Engpässe zu identifizieren, bei denen Verbraucher möglicherweise Schwierigkeiten haben, Schritt zu halten.

Auflisten von Verbrauchern (rabbitmqctl list_consumers)

Verbraucher sind Prozesse, die Warteschlangen abonnieren, um Nachrichten zu empfangen und zu verarbeiten.

Befehl:

rabbitmqctl list_consumers

Ausgabespalten (üblich):

• vhost: Der virtuelle Host, in dem sich der Verbraucher befindet.
• queue: Der Name der Warteschlange, an die der Verbraucher angeschlossen ist.
• consumer_tag: Eine eindeutige Kennung für den Verbraucher (vom Client festgelegt).
• delivery_tag: Das Zustellungstag der aktuell verarbeiteten Nachricht.
• redelivered: Gibt an, ob die Nachricht erneut zugestellt wurde.
• message_count: Die Anzahl der Nachrichten, die auf die Zustellung an diesen Verbraucher warten.
• ack_required: Gibt an, ob für an diesen Verbraucher zugestellte Nachrichten Bestätigungen erforderlich sind.

Beispiel:

rabbitmqctl list_consumers vhost queue consumer_tag message_count ack_required

Dieser Befehl hilft Ihnen zu verstehen, welche Warteschlangen aktive Verbraucher haben, wie viele Nachrichten auf deren Zustellung warten und ob Bestätigungen korrekt konfiguriert sind.

Inspizieren spezifischer Komponenten (optionale Argumente)

Die meisten list_*-Befehle akzeptieren Argumente, um anzugeben, welche Felder angezeigt werden sollen, was die Ausgabe überschaubarer macht. Sie können die Ausgabe auch mit standardmäßigen Shell-Dienstprogrammen wie grep und sort filtern und sortieren.

Beispiel: Finden von Verbindungen eines bestimmten Benutzers:

rabbitmqctl list_connections | grep 'my_user'

Beispiel: Nur die Warteschlangen mit nicht bestätigten Nachrichten anzeigen:

rabbitmqctl list_channels | awk '$4 > 0 { print }'

Best Practices für die Überwachung

• Regelmäßige Überprüfungen: Führen Sie regelmäßige Überprüfungen von rabbitmqctl status durch, um potenzielle Probleme zu identifizieren, bevor sie sich auf die Produktion auswirken.
• Automatisierung: Erwägen Sie die Automatisierung dieser Überprüfungen mithilfe von Skripten und die Integration in Überwachungssysteme (z. B. Prometheus, Nagios) für proaktive Warnmeldungen.
• Kontext ist entscheidend: Verstehen Sie die typischen Werte für Ihre Umgebung. Ein plötzlicher Anstieg nicht bestätigter Nachrichten oder eine neue, unerwartete Verbindung erfordert eine Untersuchung.
• Kombinieren mit der Management-Oberfläche: Während rabbitmqctl für Skripterstellung und direkten Zugriff leistungsstark ist, bietet die RabbitMQ-Management-Oberfläche eine visuelle und interaktive Möglichkeit, dieselben Informationen zu überwachen.
• Ressourcenüberwachung: Korrelieren Sie die Ausgabe von rabbitmqctl immer mit der Ressourcenüberwachung auf Systemebene (CPU, RAM, Festplatten-E/A), um ein vollständiges Bild zu erhalten.

Ein nützlicher Triage-Ablauf, wenn Warteschlangen blockieren

Wenn eine Warteschlange zu wachsen beginnt, starten Sie RabbitMQ nicht neu. Ein Neustart kann die Wiederherstellung verlangsamen und die benötigten Beweise verbergen. Beginnen Sie damit, vier Fragen zu beantworten.

Erstens: Ist der Knoten gesund genug, um Clients zu bedienen?

rabbitmqctl status

Überprüfen Sie Speicheralarme, Festplattenalarme, Dateideskriptornutzung und Listener. RabbitMQ verfügt über Sicherheitsmechanismen für Speicher und freien Festplattenspeicher. Wenn ein Knoten in einen Alarmzustand gerät, können Herausgeber blockiert werden. Das kann von außen wie ein Anwendungsproblem aussehen, obwohl der Broker sich selbst schützt.

Zweitens: Sind Verbraucher verbunden?

rabbitmqctl list_consumers vhost queue consumer_tag ack_required active

Wenn eine Warteschlange keine Verbraucher hat, ist die Warteschlangentiefe kein RabbitMQ-Leistungsproblem. Die Anwendung, die aus der Warteschlange verbrauchen sollte, ist ausgefallen, falsch konfiguriert, mit dem falschen virtuellen Host verbunden oder verbraucht aus einem anderen Warteschlangennamen als der Herausgeber verwendet.

Drittens: Empfangen Verbraucher Nachrichten, bestätigen sie aber nicht?

rabbitmqctl list_queues name messages_ready messages_unacknowledged consumers

messages_ready bedeutet, dass Nachrichten in der Warteschlange warten. messages_unacknowledged bedeutet, dass Nachrichten an Verbraucher zugestellt, aber noch nicht bestätigt wurden. Eine hohe Anzahl nicht bestätigter Nachrichten deutet oft auf langsame Handler, lange Datenbankaufrufe innerhalb von Verbrauchern, einen zu hohen Prefetch-Wert oder Verbraucher hin, die nach dem Empfangen von Nachrichten abgestürzt sind.

Viertens: Gibt es zu viele Verbindungen oder Kanäle?

rabbitmqctl list_connections name user host state channels send_pend recv_cnt send_cnt
rabbitmqctl list_channels connection number consumer_count messages_unacknowledged prefetch_count

Gesunde Clients verwenden normalerweise Verbindungen wieder und öffnen eine kontrollierte Anzahl von Kanälen. Wenn jede Anfrage eine neue Verbindung öffnet, kann der Broker viel Zeit mit Verbindungswechseln verbringen. Wenn eine einzelne Verbindung eine sehr große Anzahl von Kanälen hat, überprüfen Sie das Client-Bibliotheksverhalten und die Bereitstellungsgröße.

Interpretieren von Verbindungszuständen

list_connections ist nützlicher, wenn Sie nach bestimmten Spalten fragen. Ein kompakter Befehl ist während eines Vorfalls leichter zu scannen:

rabbitmqctl list_connections name user host state channels protocol ssl

Die Spalte state hilft, normalen Datenverkehr von verdächtigem Verhalten zu trennen. Eine Verbindung im Zustand running ist aktiv. Eine große Anzahl von Verbindungen, die in der Flusskontrolle oder im blockierten Zustand stecken, verdient Aufmerksamkeit. Wenn ssl dort falsch ist, wo Sie TLS erwarten, verwenden Clients möglicherweise den falschen Listener oder eine alte Konfiguration.

Client-Namen sollten auch im Anwendungscode festgelegt werden. Viele RabbitMQ-Clientbibliotheken ermöglichen das Festlegen eines Verbindungsnamens. Ohne diesen sehen Sie möglicherweise nur Host- und Portdetails, was es schwieriger macht, den Dienst zu identifizieren, der die Last verursacht. Ein Name wie billing-worker-prod-3 ist viel nützlicher als eine anonyme TCP-Verbindung.

Kanal- und Prefetch-Probleme

Kanäle sind im Vergleich zu TCP-Verbindungen günstig, aber nicht kostenlos. Ein häufiges Produktionsproblem ist ein Worker-Prozess, der Kanäle erstellt und nie schließt. Ein weiteres ist ein Verbraucher mit einem hohen Prefetch-Wert, der viele Nachrichten empfängt, sie langsam verarbeitet und andere Verbraucher untätig lässt.

Verwenden Sie:

rabbitmqctl list_channels connection number consumer_count messages_unacknowledged prefetch_count

Wenn ein Kanal eine große Anzahl von messages_unacknowledged hat, überprüfen Sie diesen Verbraucher. Vielleicht führt er langsame HTTP-Aufrufe durch, wartet auf eine Datenbanksperre oder verarbeitet Nachrichten einzeln, während Prefetch ihm erlaubt, weit mehr zu reservieren. Eine Verringerung des Prefetch kann die Fairness verbessern, ist aber keine magische Leistungsverbesserung. Wenn Handler langsam sind, müssen Sie trotzdem den Handler reparieren.

Warteschlangenprüfungen, die neben Verbindungsprüfungen gehören

Obwohl sich dieser Artikel auf Knotenstatus und Verbindungen konzentriert, vervollständigt der Warteschlangenzustand das Bild:

rabbitmqctl list_queues name durable auto_delete messages messages_ready messages_unacknowledged consumers memory state

Eine dauerhafte Warteschlange mit persistenten Nachrichten kann die Festplatte belasten. Eine Warteschlange mit consumers auf 0 benötigt eine Anwendungsprüfung. Eine Warteschlange mit vielen bereiten Nachrichten und aktiven Verbrauchern deutet auf einen Durchsatzunterschied hin. Eine Warteschlange mit vielen nicht bestätigten Nachrichten deutet auf ein Verarbeitungs- oder Bestätigungsverhalten auf Verbraucherseite hin.

Wenn Sie Shell-Filter verwenden, achten Sie auf Spaltenpositionen. Wenn Sie die angeforderten Felder ändern, können alte awk-Schnipsel stillschweigend die falsche Spalte filtern. Für wiederholbare Überprüfungen bevorzugen Sie Skripte, die feste Felder anfordern und ihre Ausgabe beschriften.

Cluster-Hinweise

Führen Sie in einem Cluster Befehle gegen den Knoten aus, der Sie interessiert, oder geben Sie den Knoten an, wo dies unterstützt wird:

rabbitmqctl -n rabbit@node1 status

Überprüfen Sie die Cluster-Mitgliedschaft und Partitionen:

rabbitmqctl cluster_status

Netzwerkpartitionen und Knotenmeinungsverschiedenheiten können verwirrende Symptome erzeugen: Clients verbinden sich erfolgreich mit einem Knoten, während Warteschlangen oder Metadaten anderswo fehlerhaft sind. Wenn ein Problem nur eine Verfügbarkeitszone oder einen Broker-Host betrifft, vergleichen Sie status, list_connections und list_queues über Knoten hinweg, bevor Sie clusterweite Einstellungen ändern.

Was automatisieren

Für eine kleine Umgebung können ein paar skriptgesteuerte Überprüfungen die offensichtlichen Probleme erkennen: Knoten ausgefallen, Festplattenalarm, Speicheralarm, keine Verbraucher bei wichtigen Warteschlangen, bereite Nachrichten über einem normalen Schwellenwert, nicht bestätigte Nachrichten, die stetig steigen, und Verbindungsanzahl weit über der Basislinie.

Für größere Systeme verwenden Sie das RabbitMQ-Prometheus-Plugin oder eine andere Metrik-Pipeline und behalten Sie rabbitmqctl für direkte Untersuchungen. Warnungen sollten an das Verhalten gekoppelt sein, das Benutzer betrifft. Eine Warteschlange, die während eines Batch-Jobs kurz ansteigt, kann normal sein. Eine Warteschlange, die fünfzehn Minuten lang ansteigt, während Verbraucher verbunden sind und auch nicht bestätigte Nachrichten ansteigen, ist eine bessere Seite.

Betriebsgewohnheiten, die Zeit sparen

Führen Sie rabbitmqctl als den richtigen OS-Benutzer oder über das Dienstkonto aus, das Ihre Installation erwartet. Berechtigungsprobleme können wie Broker-Probleme aussehen, wenn Sie in Eile sind. Wenn der Befehl den Knoten nicht erreichen kann, überprüfen Sie den Knotennamen, das Erlang-Cookie und ob der RabbitMQ-Dienst tatsächlich auf diesem Host läuft.

Führen Sie eine kleine Liste wichtiger Warteschlangen und ihrer erwarteten Verbraucher. Während eines Vorfalls ist "Warteschlange hat null Verbraucher" nur nützlich, wenn Sie wissen, ob diese Warteschlange immer Verbraucher haben sollte. Einige verzögerte, Dead-Letter- oder Batch-Warteschlangen werden voraussichtlich für lange Zeiträume untätig sein.

Löschen Sie schließlich keine Warteschlangen, nur um Dashboards grün zu machen. Das Leeren einer Warteschlange ist ein Datenverlust, es sei denn, die Nachrichten sind von Natur aus wegwerfbar. Wenn Nachrichten stecken, finden Sie zuerst heraus, ob sie warten, nicht bestätigt, abgelehnt, als Dead-Letter markiert oder durch einen fehlenden Verbraucher blockiert sind.

rabbitmqctl status, list_connections, list_channels, list_consumers und list_queues bieten Ihnen einen praktischen Befehlszeilenpfad von "Nachrichten werden verzögert" zu einer wahrscheinlichen Ursache. Der Trick besteht darin, sie zusammen zu lesen: Knotenressourcen, Client-Verbindungen, Kanalverhalten, Verbraucherpräsenz und Warteschlangentiefe erzählen alle verschiedene Teile derselben Geschichte.