Imaginez : nous sommes lundi matin. Votre site de commerce électronique organise une “vente flash de 48 heures”. Les commandes affluent, les paiements sont en cours et votre équipe d'assistance est inhabituellement calme - ce qui est une excellente chose.

Puis, soudainement, Slack explose.

• “La caisse est bloquée sur la rotation...”

• “Les confirmations de commande ne sont pas envoyées.”

• “L'inventaire a l'air mal fait”.”

• “Pourquoi les remboursements font-ils l'objet d'une file d'attente de plusieurs heures ?”

Au début, tout regards sain : Le processeur fonctionne bien, vos serveurs web sont opérationnels et les graphiques de la base de données n'indiquent rien de dramatique. Mais le système semble toujours... figé.

Après 45 minutes de lutte contre l'incendie, vous trouvez le vrai coupable : LapinMQ. Quelques files d'attente ont gonflé, les consommateurs ont ralenti, les accusés de réception se sont accumulés et la mémoire a atteint le point culminant. RabbitMQ a commencé à appliquer un contrôle de flux, les éditeurs ont commencé à perdre du temps et votre logique d'entreprise a tranquillement cessé d'acheminer les messages à travers les flux de travail critiques.

C'est exactement la raison pour laquelle Surveillance de RabbitMQ n'est pas optionnel. Si RabbitMQ est le “système circulatoire” de votre architecture, la surveillance est le moniteur cardiaque qui vous indique que quelque chose ne va pas avant le patient s'effondre.

(suite…)