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.

(altro…)