Come Monitorare lo Stato del Nodo e le Connessioni di RabbitMQ Usando rabbitmqctl

RabbitMQ di solito riceve attenzione solo dopo che una coda si accumula, un consumatore smette di riconoscere i messaggi, o un deploy crea centinaia di connessioni extra. rabbitmqctl è ancora uno dei modi più veloci per verificare cosa vede il broker dall'interno del nodo. Non sostituirà Prometheus, l'interfaccia di gestione o la revisione dei log, ma ti fornisce una visione affidabile da riga di comando quando sei su un server e hai bisogno di risposte rapidamente.

Comprendere rabbitmqctl

Lo script rabbitmqctl è l'interfaccia principale da riga di comando per interagire con un nodo RabbitMQ. Consente agli amministratori di eseguire un'ampia gamma di attività, dall'avvio e arresto del broker alla gestione di utenti, permessi, exchange, code e, crucialmente per questo articolo, al monitoraggio dello stato operativo del nodo e della sua attività di rete.

Verificare lo Stato del Nodo RabbitMQ

Prima di addentrarci nelle connessioni, è essenziale verificare che il tuo nodo RabbitMQ sia attivo e funzionante. Il comando status fornisce una panoramica completa dello stato attuale del nodo.

Il Comando rabbitmqctl status

Questo comando restituisce una grande quantità di informazioni, tra cui:

• Nome del Nodo: Il nome del nodo RabbitMQ.
• Applicazioni in Esecuzione: Elenca le applicazioni Erlang in esecuzione, con RabbitMQ stesso come indicatore chiave.
• Utilizzo della Memoria: Dettagli sull'allocazione e l'utilizzo della memoria, vitali per l'ottimizzazione delle prestazioni.
• Spazio su Disco: Informazioni sullo spazio su disco disponibile, che può influenzare la persistenza dei messaggi.
• Descrittori di File: Il numero di descrittori di file aperti, una risorsa di sistema importante.
• Informazioni di Rete: Dettagli sulle interfacce di rete e le porte.
• Stato del Cluster: Informazioni su se il nodo fa parte di un cluster e sulla sua connettività.
• Listener: Porte su cui RabbitMQ è in ascolto per vari protocolli (AMQP, interfaccia di gestione, ecc.).

Esempio di Utilizzo:

rabbitmqctl status

Interpretare l'Output: Cerca segni di esaurimento delle risorse (memoria alta, poco spazio su disco, uso elevato di descrittori di file) e conferma che le applicazioni essenziali come rabbit siano in esecuzione. La sezione listeners è cruciale per assicurarsi che RabbitMQ sia accessibile sulle porte previste.

Monitorare Connessioni, Canali e Consumatori

Capire come i client interagiscono con il tuo nodo RabbitMQ è fondamentale per la risoluzione dei problemi e l'analisi delle prestazioni. rabbitmqctl fornisce comandi per elencare e ispezionare queste entità.

Elencare le Connessioni (rabbitmqctl list_connections)

Questo comando mostra tutte le connessioni client attive al nodo RabbitMQ. Ogni connessione rappresenta un'applicazione client (produttore o consumatore) che si è connessa con successo.

Comando:

rabbitmqctl list_connections

Colonne dell'Output (Comuni):

• pid: L'identificatore del processo Erlang per la connessione.
• node: Il nodo su cui è stabilita la connessione.
• name: Il nome della connessione (spesso riflette le proprietà del client).
• port: La porta a cui il client si è connesso.
• host: L'host da cui il client si è connesso.
• user: Il nome utente utilizzato per l'autenticazione.
• vhost: L'host virtuale a cui è associata la connessione.
• ssl: Indica se la connessione utilizza SSL/TLS.
• protocol: Il protocollo utilizzato (es., amqp0-9-1).

Esempio:

rabbitmqctl list_connections name host port user vhost protocol

Questo ti permette di vedere quali utenti sono connessi, da dove e quali host virtuali stanno utilizzando.

Elencare i Canali (rabbitmqctl list_channels)

Ogni connessione può avere più canali. I canali sono connessioni leggere e multiplexate su una singola connessione TCP, utilizzate per le operazioni AMQP.

Comando:

rabbitmqctl list_channels

Colonne dell'Output (Comuni):

• connection: Il pid della connessione padre.
• node: Il nodo su cui si trova il canale.
• channel_pid: L'identificatore del processo Erlang per il canale.
• vhost: L'host virtuale a cui è associato il canale.
• name: Il nome del canale (se impostato dal client).
• consumer_count: Il numero di consumatori attivi su questo canale.
• messages_unacknowledged: Il numero di messaggi non riconosciuti su questo canale.
• messages_ready: Il numero di messaggi pronti per essere consegnati su questo canale.

Esempio:

rabbitmqctl list_channels connection vhost consumer_count messages_ready messages_unacknowledged

Monitorare messages_unacknowledged e messages_ready è cruciale per identificare potenziali colli di bottiglia in cui i consumatori potrebbero avere difficoltà a tenere il passo.

Elencare i Consumatori (rabbitmqctl list_consumers)

I consumatori sono processi che si iscrivono alle code per ricevere ed elaborare i messaggi.

Comando:

rabbitmqctl list_consumers

Colonne dell'Output (Comuni):

• vhost: L'host virtuale in cui si trova il consumatore.
• queue: Il nome della coda a cui è collegato il consumatore.
• consumer_tag: Un identificatore univoco per il consumatore (impostato dal client).
• delivery_tag: Il tag di consegna del messaggio corrente in elaborazione.
• redelivered: Indica se il messaggio è stato riconsegnato.
• message_count: Il numero di messaggi in attesa di essere consegnati a questo consumatore.
• ack_required: Indica se sono richiesti riconoscimenti per i messaggi consegnati a questo consumatore.

Esempio:

rabbitmqctl list_consumers vhost queue consumer_tag message_count ack_required

Questo comando ti aiuta a capire quali code hanno consumatori attivi, quanti messaggi sono in attesa di essere consegnati e se i riconoscimenti sono configurati correttamente.

Ispezionare Componenti Specifici (Argomenti Opzionali)

La maggior parte dei comandi list_* accetta argomenti per specificare quali campi visualizzare, rendendo l'output più gestibile. Puoi anche filtrare e ordinare l'output utilizzando utilità shell standard come grep e sort.

Esempio: Trovare connessioni da un utente specifico:

rabbitmqctl list_connections | grep 'my_user'

Esempio: Mostrare solo le code con messaggi non riconosciuti:

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

Migliori Pratiche per il Monitoraggio

• Controlli Regolari: Implementa controlli regolari di rabbitmqctl status per identificare potenziali problemi prima che influiscano sulla produzione.
• Automazione: Considera l'automazione di questi controlli utilizzando script e l'integrazione con sistemi di monitoraggio (es., Prometheus, Nagios) per avvisi proattivi.
• Il Contesto è Fondamentale: Comprendi i valori tipici per il tuo ambiente. Un improvviso picco di messaggi non riconosciuti o una nuova connessione inaspettata meritano un'indagine.
• Combina con l'Interfaccia di Gestione: Mentre rabbitmqctl è potente per lo scripting e l'accesso diretto, l'Interfaccia di Gestione di RabbitMQ fornisce un modo visivo e interattivo per monitorare le stesse informazioni.
• Monitoraggio delle Risorse: Correla sempre l'output di rabbitmqctl con il monitoraggio delle risorse a livello di sistema (CPU, RAM, I/O del disco) per un quadro completo.

Un Flusso di Triage Utile Quando le Code si Accumulano

Quando una coda inizia a crescere, non iniziare riavviando RabbitMQ. Un riavvio può rallentare il recupero e potrebbe nascondere le prove di cui hai bisogno. Inizia rispondendo a quattro domande.

Primo, il nodo è abbastanza sano per servire i client?

rabbitmqctl status

Controlla gli allarmi di memoria, gli allarmi del disco, l'uso dei descrittori di file e i listener. RabbitMQ ha meccanismi di sicurezza per la memoria e lo spazio libero su disco. Se un nodo entra in uno stato di allarme, i publisher potrebbero essere bloccati. Dall'esterno, questo può sembrare un problema dell'applicazione, anche se il broker si sta proteggendo.

Secondo, i consumatori sono connessi?

rabbitmqctl list_consumers vhost queue consumer_tag ack_required active

Se una coda non ha consumatori, la profondità della coda non è un problema di prestazioni di RabbitMQ. L'applicazione che dovrebbe consumare dalla coda è giù, mal configurata, connessa all'host virtuale sbagliato o consuma da un nome di coda diverso da quello utilizzato dal publisher.

Terzo, i consumatori ricevono messaggi ma non li riconoscono?

rabbitmqctl list_queues name messages_ready messages_unacknowledged consumers

messages_ready significa che i messaggi sono in attesa nella coda. messages_unacknowledged significa che i messaggi sono stati consegnati ai consumatori ma non ancora riconosciuti. Un numero elevato di messaggi non riconosciuti spesso indica handler lenti, chiamate lunghe al database all'interno dei consumatori, un valore di prefetch troppo alto o consumatori che si sono arrestati dopo aver ricevuto messaggi.

Quarto, ci sono troppe connessioni o canali?

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

I client sani di solito riutilizzano le connessioni e aprono un numero controllato di canali. Se ogni richiesta apre una nuova connessione, il broker può dedicare molto tempo al churn delle connessioni. Se una singola connessione ha un numero molto elevato di canali, ispeziona il comportamento della libreria client e la dimensione del deployment.

Interpretare gli Stati delle Connessioni

list_connections è più utile quando richiedi colonne specifiche. Un comando compatto è più facile da scansionare durante un incidente:

rabbitmqctl list_connections name user host state channels protocol ssl

La colonna state aiuta a separare il traffico normale dal comportamento sospetto. Una connessione in stato running è attiva. Un gran numero di connessioni bloccate in controllo di flusso o in stato bloccato merita attenzione. Se ssl è falso dove ti aspetti TLS, potresti avere client che utilizzano il listener sbagliato o una vecchia configurazione.

Vale anche la pena impostare i nomi dei client nel codice dell'applicazione. Molte librerie client RabbitMQ ti permettono di impostare un nome di connessione. Senza di esso, potresti vedere solo i dettagli di host e porta, rendendo più difficile identificare il servizio che causa il carico. Un nome come billing-worker-prod-3 è molto più utile di una connessione TCP anonima.

Problemi di Canale e Prefetch

I canali sono economici rispetto alle connessioni TCP, ma non sono gratuiti. Un problema comune in produzione è un processo worker che crea canali e non li chiude mai. Un altro è un consumatore con un valore di prefetch alto che riceve molti messaggi, li elabora lentamente e lascia inattivi altri consumatori.

Usa:

rabbitmqctl list_channels connection number consumer_count messages_unacknowledged prefetch_count

Se un canale ha un numero elevato di messages_unacknowledged, ispeziona quel consumatore. Forse sta facendo chiamate HTTP lente, aspettando un lock del database o elaborando i messaggi uno alla volta mentre il prefetch gli permette di riservarne molti di più. Abbassare il prefetch può migliorare l'equità, ma non è una soluzione magica per le prestazioni. Se gli handler sono lenti, devi comunque sistemare l'handler.

Controlli delle Code Che Dovrebbero Stare Accanto ai Controlli delle Connessioni

Anche se questo articolo si concentra sullo stato del nodo e le connessioni, lo stato delle code completa il quadro:

rabbitmqctl list_queues name durable auto_delete messages messages_ready messages_unacknowledged consumers memory state

Una coda durevole con messaggi persistenti può mettere pressione sul disco. Una coda con consumers impostato a 0 necessita di un controllo dell'applicazione. Una coda con molti messaggi pronti e consumatori attivi indica una mancata corrispondenza di throughput. Una coda con molti messaggi non riconosciuti indica un problema di elaborazione o di comportamento di riconoscimento lato consumatore.

Quando usi filtri shell, fai attenzione alle posizioni delle colonne. Se modifichi i campi richiesti, vecchi snippet awk potrebbero filtrare silenziosamente la colonna sbagliata. Per controlli ripetibili, preferisci script che richiedono campi fissi ed etichettano il loro output.

Note sul Cluster

In un cluster, esegui i comandi sul nodo che ti interessa o specifica il nodo dove supportato:

rabbitmqctl -n rabbit@node1 status

Controlla l'appartenenza al cluster e le partizioni:

rabbitmqctl cluster_status

Le partizioni di rete e il disaccordo tra i nodi possono creare sintomi confusi: i client si connettono con successo a un nodo mentre le code o i metadati sono in uno stato non sano altrove. Se un problema colpisce solo una zona di disponibilità o un host broker, confronta status, list_connections e list_queues tra i nodi prima di modificare le impostazioni a livello di cluster.

Cosa Automatizzare

Per un ambiente piccolo, alcuni controlli scriptati possono cogliere i problemi evidenti: nodo giù, allarme disco, allarme memoria, nessun consumatore su code importanti, messaggi pronti sopra una soglia normale, messaggi non riconosciuti che continuano a salire e numero di connessioni molto al di sopra della baseline.

Per sistemi più grandi, usa il plugin Prometheus di RabbitMQ o un'altra pipeline di metriche e tieni rabbitmqctl per indagini dirette. Gli avvisi dovrebbero essere legati al comportamento che interessa agli utenti. Una coda che aumenta brevemente durante un job batch può essere normale. Una coda che aumenta per quindici minuti mentre i consumatori sono connessi e anche i messaggi non riconosciuti aumentano è un motivo migliore per essere chiamati.

Abitudini Operative Che Fanno Risparmiare Tempo

Esegui rabbitmqctl come utente OS corretto o tramite l'account di servizio che la tua installazione si aspetta. I problemi di autorizzazione possono sembrare problemi del broker quando hai fretta. Se il comando non riesce a contattare il nodo, controlla il nome del nodo, il cookie Erlang e se il servizio RabbitMQ è effettivamente in esecuzione su quell'host.

Tieni un piccolo elenco di code importanti e dei loro consumatori previsti. Durante un incidente, "la coda ha zero consumatori" è utile solo se sai se quella coda dovrebbe sempre avere consumatori. Alcune code di ritardo, dead-letter o batch possono rimanere inattive per lunghi periodi.

Infine, non cancellare le code solo per rendere verdi le dashboard. Svuotare una coda è una perdita di dati a meno che i messaggi non siano progettati per essere eliminabili. Se i messaggi sono bloccati, scopri prima se sono in attesa, non riconosciuti, rifiutati, dead-letter o bloccati da un consumatore mancante.

rabbitmqctl status, list_connections, list_channels, list_consumers e list_queues ti danno un percorso pratico da riga di comando da "i messaggi sono in ritardo" a una causa probabile. Il trucco è leggerli insieme: le risorse del nodo, le connessioni dei client, il comportamento dei canali, la presenza dei consumatori e la profondità delle code raccontano tutte parti diverse della stessa storia.