Come monitorare RabbitMQ (senza perdere messaggi, soldi o sonno)

Immaginate: è lunedì mattina. Il vostro sito di e-commerce sta effettuando una “vendita flash di 48 ore”. Gli ordini stanno arrivando, i pagamenti sono in corso e il vostro team di assistenza è insolitamente tranquillo: una cosa bellissima.

Poi, improvvisamente, Slack esplode.

• “La cassa è bloccata sulla rotazione...”.”

• “Le conferme d'ordine non stanno uscendo”.”

• “L'inventario sembra sbagliato”.”

• “Perché i rimborsi sono in coda per ore?”.”

All'inizio, tutto sguardi sano: La CPU è a posto, i server Web sono attivi e i grafici del database non mostrano nulla di drammatico. Ma il sistema sembra ancora... bloccato.

Dopo 45 minuti di lotta al fuoco, si scopre il vero colpevole: RabbitMQ. Alcune code si sono gonfiate, i consumatori hanno rallentato, gli acknowledgement si sono accumulati e la memoria ha raggiunto la soglia massima. RabbitMQ ha iniziato ad applicare il controllo di flusso, i publisher hanno iniziato a perdere tempo e la logica aziendale ha smesso di spostare i messaggi attraverso i flussi di lavoro critici.

Questo è esattamente il motivo per cui Monitoraggio di RabbitMQ non è opzionale. Se RabbitMQ è il “sistema circolatorio” della vostra architettura, il monitoraggio è il cardiofrequenzimetro che vi dice che qualcosa non va. prima il paziente collassa.

In questa guida imparerete:

• Cos'è RabbitMQ (in parole povere)

• Perché è necessario monitorarlo (anche se “va bene da mesi”)

• Quali sono le metriche che contano di più e cosa si intende per “buono”

• Modelli di guasto comuni e modalità di monitoraggio per individuarli tempestivamente

• Strumenti di alto livello in grado di monitorare RabbitMQ

• Una semplice e pratica lista di controllo per il monitoraggio di RabbitMQ

Che cos'è RabbitMQ?

RabbitMQ è un popolare broker di messaggi. Si colloca tra i sistemi e li aiuta a scambiare messaggi in modo affidabile.

Invece di un servizio che chiama direttamente un altro (e che fallisce se l'altro servizio è lento o non funziona), i servizi possono pubblicare messaggi in RabbitMQ, e altri servizi consumano questi messaggi quando sono pronti.

RabbitMQ in una frase

RabbitMQ è un sistema che accodare i messaggi in modo che le applicazioni possano comunicare in modo asincrono, affidabile e su scala.

Concetti chiave di RabbitMQ (rapidi e semplici)

Non è necessario memorizzarli, ma aiutano a interpretare i segnali di monitoraggio:

• Produttore / Editore: l'applicazione che invia i messaggi

• Consumatore: l'applicazione che riceve i messaggi

• Coda: dove i messaggi aspettano

• Scambio: dove i messaggi arrivano per primi e vengono instradati

• Rilegatura: regola che collega uno scambio a una coda

• Host virtuale (vhost): uno spazio dei nomi logico (come un inquilino/ambiente)

• Canale: una connessione leggera all'interno di una connessione TCP

• Ack (riconoscimento): il consumatore conferma di aver elaborato il messaggio

• DLQ (coda di lettere morte): i messaggi che non hanno potuto essere elaborati vanno qui (se configurati)

RabbitMQ implementa tipicamente AMQP (Advanced Message Queuing Protocol), ma supporta anche altri protocolli tramite plugin.

Perché è necessario monitorare RabbitMQ?

RabbitMQ è spesso una “dipendenza silenziosa”. Quando è in difficoltà, i sintomi si manifestano altrove:

• Time out delle richieste web

• I lavori in background si accumulano

• Le e-mail smettono di essere inviate

• Ritardi nell'elaborazione dei pagamenti

• I sistemi event-driven diventano inconsistenti

• I microservizi iniziano a riprovare e a tempestarsi a vicenda

I problemi di RabbitMQ possono essere costosi perché creano arretrati nascosti. Il vostro sistema potrebbe essere ancora “attivo”, ma non sta producendo risultati.

Il monitoraggio di RabbitMQ vi aiuta:

1. Rilevare tempestivamente i rallentamenti (prima che i clienti se ne accorgano)

2. Prevenire la perdita di messaggi (o almeno catturare condizioni rischiose)

3. Proteggere il throughput durante i picchi di traffico

4. Evitare i guasti a cascata attraverso i microservizi

5. Capacità del piano (RAM/disco/rete/consumo)

6. Velocizzare la risoluzione dei problemi quando qualcosa va storto

La trappola del “ha funzionato ieri

I fallimenti di RabbitMQ appaiono spesso dopo:

• un picco di traffico

• una distribuzione dei consumatori bloccata

• un'interruzione di una dipendenza a valle (ad esempio, un database o un fornitore di pagamenti)

• un gestore di messaggi lento

• un'ondata di messaggi di grandi dimensioni

• spazio su disco in calo

• filigrana di memoria colpita

• crescita illimitata della coda a causa di TTL/limiti mancanti

In altre parole: RabbitMQ non fallisce in modo casuale, ma quando il sistema che lo circonda cambia. Il monitoraggio rende visibili tali cambiamenti.

Cosa monitorare in RabbitMQ?

Se monitorate solo una cosa, monitorate questa:

✅ Profondità della coda + salute del consumatore

Perché è lì che si rivela il “lavoro che non viene fatto”.

Ma una solida configurazione di monitoraggio di RabbitMQ copre quattro livelli:

1. Livello di coda (flusso di messaggi)

2. Livello del broker (interni di RabbitMQ)

3. Livello di nodo/sistema (OS + disco + memoria)

4. Livello di applicazione (comportamento e errori di pubblicazione/consumo)

Analizziamo le metriche più importanti.

Metriche di monitoraggio di RabbitMQ davvero importanti

1) Metriche di coda (l'avviso precoce di #1)

Queste metriche indicano se i messaggi scorrono o si accumulano.

Metriche chiave:

• Messaggi pronti: in attesa in coda

• Messaggi non registraticonsegnato ai consumatori ma non ancora riconosciuto

• Messaggi totali: pronto + disimballato

• Tasso di ingresso: messaggi pubblicati al secondo

• Velocità di uscita: messaggi riconosciuti/consumati al secondo

• Consumatori in coda: quanti consumatori sono attivi per coda

Cosa tenere d'occhio:

• Messaggi totali in crescita nel tempo → i consumatori non riescono a tenere il passo

• Crescita libera → l'utenza è lenta, bloccata o non funziona correttamente.

• Consumatori = 0 su una coda critica → i messaggi si accumuleranno velocemente

• L'uscita scende improvvisamente → problema di dipendenza da downstream o crash dei consumatori

Una semplice regola empirica:
Se la coda continua a crescere per più di qualche minuto durante il “traffico normale”, c'è qualcosa che non va.

2) Salute dei consumatori (da dove partono molti incidenti)

RabbitMQ viene spesso incolpato, ma la causa principale è spesso un problema del consumatore:

• codice distribuito con un bug

• consumatore bloccato nei tentativi di risposta

• pool di thread esaurito

• chiamate al database lente

• limiti di velocità API esterni

• perdita di memoria del consumatore

Monitor:

• numero di consumatori per coda

• tasso di consumo vs tasso di pubblicazione

• messaggi non registrati

• log degli errori dei consumatori (timeout, eccezioni)

• tempo di elaborazione (dalla telemetria dell'app, se disponibile)

Suggerimento:
Una coda in crescita non è sempre negativa durante un picco. Una coda che cresce e non si riprende mai è negativo.

3) Connessioni e canali (una fonte subdola di instabilità)

Un numero eccessivo di connessioni o di canali può ridurre le prestazioni.

Monitor:

• connessioni aperte

• canali per connessione

• churn di connessione (frequenti disconnessioni/riconnessioni)

• connessioni bloccate (controllo del flusso)

Cosa tenere d'occhio:

• picchi improvvisi di connessioni (client mal configurati)

• enormi quantità di canali (perdite)

• frequenti loop di riconnessione (problemi di rete o di autenticazione)

4) Salute del nodo: memoria, disco, CPU, descrittori di file

RabbitMQ è sensibile alla memoria e al disco.

Monitor:

• Utilizzo della memoria e se si avvicina all'high watermark

• Spazio libero su disco (RabbitMQ bloccherà gli editori se il disco è scarso)

• CPU (una CPU elevata e prolungata può ridurre il throughput)

• Descrittori di file (l'esaurimento può interrompere le connessioni)

• Velocità di rete ed errori (i broker sono molto legati alla rete)

Perché il disco è così importante
RabbitMQ persiste i messaggi (a seconda delle impostazioni di durabilità) e utilizza pesantemente il disco in determinate condizioni. Quando il disco è troppo basso, RabbitMQ può proteggersi bloccando gli editori. Questo sembra che “l'applicazione non funziona”, anche se il server è in funzione.

5) Stato di salute del broker e del cluster

Se si gestisce un cluster RabbitMQ, monitorare anche:

• stato del nodo su/giù

• partizioni del cluster

• stato di salute della coda di mirroring/quorum della coda (a seconda della configurazione)

• stato di sincronizzazione (se applicabile)

• cambiamenti di leader e ritardi di replica (per le code di quorum)

6) Sicurezza a livello di messaggio: DLQ, retry, TTL

Molti sistemi utilizzano retry e dead-lettering per gestire i guasti con grazia. Il monitoraggio aiuta a garantire che il “fallimento aggraziato” non diventi un “fallimento silenzioso”.”

Monitor:

• profondità della coda di lettere morte

• tasso di messaggi non scritti

• profondità della coda di riprova (se utilizzata)

• scadenza del TTL del messaggio (se applicabile)

Se le DLQ crescono, spesso significa che i vostri consumatori stanno fallendo e i messaggi vengono reindirizzati: i clienti potrebbero essere colpiti anche se la vostra coda principale “sembra a posto”.”

Problemi comuni di RabbitMQ (e il segnale di monitoraggio che li rileva)

Problema: i consumatori sono in calo

Segnale:

• Consumatori = 0

• I messaggi pronti salgono rapidamente

Problema: il bug del consumatore causa un'elaborazione lenta

Segnale:

• Aumenti non compensati

• Cadute di velocità in uscita

• Il tempo di elaborazione (metrica dell'applicazione) aumenta

Problema: interruzione della dipendenza a valle (DB/API)

Segnale:

• Salite non attrezzate

• Aumentano gli errori e i timeout dei consumatori

• La crescita delle code accelera

Problema: attivato l'high watermark della memoria

Segnale:

• L'utilizzo della memoria si avvicina alla filigrana

• Le connessioni si bloccano

• La latenza di pubblicazione aumenta

Problema: allarme disco / spazio ridotto su disco

Segnale:

• Il disco libero scende sotto la soglia

• RabbitMQ blocca la pubblicazione

• I timeout dei produttori aumentano

Problema: perdita di connessione/canale in un'applicazione

Segnale:

• Connessioni/canali in costante aumento

• Salita dei descrittori di file

• Eventualmente: errori di connessione

Problema: una coda “calda” domina le risorse del broker

Segnale:

• Una coda ha una profondità enorme e tassi elevati

• Altri diventano lenti anche se il volume è basso

• Picchi di CPU e aumento della latenza del broker

Il monitoraggio non si limita a dire che qualcosa non va - indica che dove.

Come monitorare RabbitMQ: un approccio pratico

Una strategia semplice ed efficace è:

1. Iniziare con l'essenziale
   Profondità della coda, consumatori, ingress/egress, unacked, memoria, disco.

2. Aggiungere avvisi che corrispondano all'impatto aziendale
   Avvisare sulle tendenze (aumento dell'arretrato), non solo sulle soglie grezze.

3. Creare dashboard intorno ai flussi di lavoro
   Mostra le code raggruppate in base al dominio aziendale: cassa, notifiche, fatturazione.

4. Correlare le metriche del broker con la telemetria dell'applicazione
   Metriche di RabbitMQ + log degli errori del consumatore = causa principale veloce.

5. Utilizzare segnali di tipo SLO
   “I messaggi vengono elaborati entro X minuti” è più significativo di CPU%.

Soluzioni di alto livello per il monitoraggio di RabbitMQ

Di seguito sono riportate le opzioni collaudate utilizzate in ambienti di produzione reali.

1) Xitoring (monitoraggio all-in-one per RabbitMQ e l'intero stack)

Xitoring.com è una soluzione di monitoraggio all-in-one progettata per aiutarvi a monitorare le infrastrutture e i servizi critici, compresi i broker di messaggi come RabbitMQ, in modo chiaro e funzionale.

Perché si adatta bene al monitoraggio di RabbitMQ:

• Cruscotti centrali per l'infrastruttura e i servizi (un unico punto di riferimento)

• Allarme progettato per i momenti in cui “c'è qualcosa che non va”.

• Visibilità di alto livello che aiuta sia gli sviluppatori che i team operativi

• Utile quando i problemi di RabbitMQ sono sintomi di problemi di sistema più ampi (DB, rete, latenza dell'app)

Ideale per:
Le squadre che vogliono un hub di monitoraggio unico invece di mettere insieme più strumenti, e vogliono che il monitoraggio di RabbitMQ faccia parte di un quadro più ampio “full-stack”.

2) Plugin di gestione RabbitMQ (interfaccia utente integrata + metriche di base)

RabbitMQ include un'interfaccia di gestione (se abilitata) che mostra code, tassi, connessioni, consumatori e statistiche dei nodi.

Pro:

• Abilitazione rapida

• Ottimo per l'ispezione manuale e il debug

• Mostra chiaramente i dettagli a livello di coda

Contro:

• Non è un sistema di monitoraggio completo da solo

• Allarmi e trend a lungo termine limitati, a meno che non siano integrati altrove.

Ideale per:
Rapida risoluzione dei problemi e visibilità quotidiana, soprattutto nelle configurazioni più piccole.

3) Prometheus + Grafana (popolare stack di monitoraggio open-source)

Un approccio comune è il seguente:

• Esportazione delle metriche di RabbitMQ tramite un esportatore o gli endpoint integrati

• Raccogliere con Prometeo

• Visualizzare e avvisare con Grafana/Alertmanager

Pro:

• Potenti dashboard e avvisi

• Forte ecosistema e modelli di comunità

• Ottimo per le tendenze a lungo termine e gli SLO

Contro:

• Più configurazione e manutenzione

• È probabile che dobbiate mettere a punto avvisi e dashboard.

Ideale per:
Team che già utilizzano Prometheus o che desiderano uno stack open-source flessibile.

4) Datadog (piattaforma di osservabilità SaaS)

Datadog supporta il monitoraggio di RabbitMQ tramite integrazioni e può correlare le metriche del broker con host, container e tracce APM.

Pro:

• Rapido onboarding

• Forte correlazione tra metriche, log, tracce

• Ottimi avvisi e visualizzazioni

Contro:

• Il costo cresce con la scala

• Dipendenza da SaaS

Ideale per:
Team che desiderano un time-to-value rapido e un'ampia osservabilità.

5) New Relic (piattaforma di osservabilità SaaS)

New Relic fornisce monitoraggio dell'infrastruttura, APM, dashboard e avvisi. RabbitMQ può essere monitorato attraverso integrazioni e pipeline di metriche personalizzate.

Pro:

• Visibilità full-stack (APM + infra)

• Buoni cruscotti e avvisi

Contro:

• Richiede una configurazione attenta per ottenere i migliori segnali di RabbitMQ

Ideale per:
I team che già utilizzano New Relic per il monitoraggio delle app.

6) Elastic Stack (ELK) per i log e le metriche (e cruscotti Kibana)

Elastic è ampiamente utilizzato per l'aggregazione dei log e può anche gestire le metriche, a seconda della configurazione.

Pro:

• Eccellente ricerca e correlazione dei log

• Potenti dashboard per l'analisi operativa

Contro:

• Può diventare complesso in scala

• Necessità di una buona disciplina in materia di schemi e conservazione

Ideale per:
Team in cui i registri sono uno strumento primario per la diagnosi e la conformità.

7) Splunk

Splunk è comune nelle grandi organizzazioni per l'aggregazione dei log, gli avvisi e l'intelligence operativa.

Pro:

• Forti capacità aziendali

• Potenti query e avvisi

Contro:

• Possono essere costosi e pesanti da gestire

Ideale per:
Grandi imprese con flussi di lavoro di osservabilità maturi.

8) Monitoraggio del provider cloud (quando RabbitMQ è gestito)

Se si esegue RabbitMQ tramite un servizio gestito (o un'offerta gestita dal fornitore), si può fare affidamento su:

• Monitoraggio del cloud (come gli equivalenti di CloudWatch)

• Cruscotti del fornitore + endpoint delle metriche

Pro:

• Meno lavoro operativo

• Integrato con gli avvisi della piattaforma

Contro:

• Potrebbe non esporre la profondità desiderata per le operazioni a livello di coda

• Serve ancora visibilità a livello di app

Ideale per:
I team danno priorità alla riduzione dei costi operativi.

Creazione di una dashboard di monitoraggio di RabbitMQ (cosa includere)

Se state creando un cruscotto in Xitoring (o in qualsiasi altro strumento), costruitelo intorno alle domande che fate durante gli incidenti.

Sezione A: “Il flusso di messaggi è sano?”.”

• messaggi totali per coda critica

• messaggi pronti vs. non confezionati

• tasso di pubblicazione vs tasso di ack

• numero di consumatori per coda

• Profondità DLQ e tasso DLQ

Sezione B: “Il broker è sotto pressione?”.”

• utilizzo della memoria (e vicinanza della filigrana)

• spazio libero su disco

• Utilizzo della CPU

• velocità di rete

• descrittori di file

Sezione C: “Il cluster è stabile?”.”

• nodo su/giù

• eventi di partizione

• stato di salute della coda di replica/quorum (se applicabile)

Sezione D: “Le applicazioni si comportano bene?”.”

• errori di pubblicazione del produttore/timeout

• tasso di errore del consumatore

• tempo di elaborazione del consumatore

• tasso di riconnessione

Suggerimento: Mettete le code più importanti per l'azienda in cima. In caso di incidente, nessuno vuole scorrere.

Avviso per RabbitMQ: semplice e utile

Gli avvisi devono essere attivabili. Un buon avviso RabbitMQ risponde:

• Che cosa viene colpito?

• Dove si verifica (quale coda/nodo)?

• Quanto è urgente?

Avvisi pratici che funzionano bene

1) Arretrati in coda in crescita

• Attivazione quando la profondità della coda aumenta continuamente per N minuti

2) Mancano i consumatori

• Attivazione quando il conteggio dei consumatori è 0 per una coda critica per più di 1-2 minuti

3) Messaggi non confezionati troppo alti

• Si attiva quando l'unacked supera una soglia (o cresce costantemente)

4) Spazio su disco ridotto

• Attivazione quando il disco libero scende al di sotto di un buffer sicuro (impostato in base all'ambiente)

5) Pressione della memoria

• Attivazione quando la memoria è alta e sale verso la filigrana

6) Crescita del DLQ

• Attivazione quando la profondità del DLQ aumenta oltre la normale linea di base

Evitare gli avvisi rumorosi

• Non allertate solo in base ai picchi della CPU.

• Non fare allerta solo sulla base della profondità della coda senza un contesto.

• Avvisare sulle tendenze + consumatori mancanti + limiti di risorse del broker.

Le migliori pratiche che rendono il monitoraggio più efficace

Il monitoraggio è più efficace quando la configurazione di RabbitMQ è progettata anche per la stabilità.

1) Impedire la crescita infinita

• Usare i TTL dove appropriato

• Utilizzare i DLQ intenzionalmente

• Considerare politiche di lunghezza massima per code che devono essere delimitate

2) Mantenere i messaggi snelli

I messaggi di grandi dimensioni aumentano il carico di memoria e di rete. Preferire l'invio degli ID e il recupero dei dettagli altrove, quando possibile.

3) Utilizzare correttamente i ringraziamenti

• Ack solo dopo che l'elaborazione è riuscita

• Fate attenzione all'auto-ack (può nascondere i fallimenti).

4) Controllo del prefetch

Le impostazioni di prefetch dei consumatori influenzano il conteggio degli unacked e il throughput. Il monitoraggio degli unacked aiuta a regolare il prefetch.

5) Carichi di lavoro separati

Mettete i carichi di lavoro lenti o rari in code separate, in modo che non blocchino i flussi ad alta priorità.

6) Attenzione alle “tempeste di tentativi”.”

Se i consumatori ritentano in modo troppo aggressivo, si può sovraccaricare RabbitMQ e i sistemi a valle. I DLQ e i ritentativi ritardati aiutano.

Pensieri finali: Monitorare RabbitMQ come se fosse un prodotto

RabbitMQ non è solo “infrastruttura”. È una parte viva del comportamento del vostro sistema. Quando rallenta, la vostra attività rallenta.

Una buona configurazione di monitoraggio vi permette di rispondere, in modo rapido e sicuro:

• I messaggi scorrono?

• In caso contrario, quale coda è bloccata?

• Il broker è in salute?

• I consumatori stanno lavorando - o stanno fallendo in silenzio?

• Si tratta di un picco, di un bug o di un problema di capacità?

Se volete un monitoraggio di RabbitMQ che si inserisca in un approccio più ampio di “monitoraggio di tutto in un unico posto”, Xitoring è una prima opzione da prendere in considerazione, soprattutto quando i problemi di RabbitMQ sono solo un pezzo di un puzzle di prestazioni più ampio.