Comment surveiller RabbitMQ (sans perdre de messages, d'argent ou de sommeil)

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.

Dans ce guide, vous apprendrez :

• Ce qu'est RabbitMQ (en anglais)

• Pourquoi vous devez le surveiller (même si “tout va bien depuis des mois”)

• Quels sont les indicateurs les plus importants et à quoi ressemble un bon résultat ?

• Les modèles de défaillance les plus courants et la manière dont la surveillance permet de les détecter à temps

• Outils de haut niveau permettant de contrôler RabbitMQ

• Une liste de contrôle simple et pratique pour la surveillance de RabbitMQ

Qu'est-ce que RabbitMQ ?

LapinMQ est un programme populaire de courtier en messages. Il se situe entre les systèmes et les aide à échanger des messages de manière fiable.

Au lieu qu'un service en appelle un autre directement (et échoue si l'autre service est lent ou en panne), les services peuvent publier des messages dans RabbitMQ, et d'autres services consomment ces messages lorsqu'ils sont prêts.

RabbitMQ en une phrase

RabbitMQ est un système qui file d'attente des messages afin que vos applications puissent communiquer de manière asynchrone, fiable et à grande échelle.

Concepts clés de RabbitMQ (rapide et convivial)

Il n'est pas nécessaire de les mémoriser, mais ils vous aident à interpréter les signaux de surveillance :

• Producteur / éditeur: l'application qui envoie les messages

• Consommateur: l'application qui reçoit les messages

• File d'attente: où les messages attendent

• Échange: où les messages arrivent en premier et sont acheminés

• Reliurerègle qui relie un échange à une file d'attente

• Hôte virtuel (vhost)un espace de noms logique (comme un locataire/environnement)

• Chaîneune connexion légère à l'intérieur d'une connexion TCP

• Ack (accusé de réception)le consommateur confirme qu'il a traité le message

• DLQ (dead-letter queue)les messages qui n'ont pas pu être traités vont ici (si configuré)

RabbitMQ met généralement en œuvre AMQP (Advanced Message Queuing Protocol) mais prend également en charge d'autres protocoles par le biais de modules d'extension.

Pourquoi surveiller RabbitMQ ?

RabbitMQ est souvent une “dépendance silencieuse”. Lorsqu'il est en difficulté, les symptômes se manifestent ailleurs :

• Délai d'attente pour les requêtes web

• Les emplois d'arrière-plan s'accumulent

• Les courriels ne sont plus envoyés

• Retards dans le traitement des paiements

• Les systèmes pilotés par les événements deviennent incohérents

• Les microservices commencent à réessayer et à s'attaquer les uns aux autres.

Les problèmes liés à RabbitMQ peuvent être coûteux parce qu'ils créent arriérés cachés. Votre système est peut-être encore “en marche”, mais il ne produit pas de résultats.

La surveillance de RabbitMQ vous aide :

1. Détecter rapidement les ralentissements (avant l'avis des clients)

2. Prévenir la perte de messages (ou au moins attraper des conditions risquées)

3. Protéger le débit pendant les heures de pointe

4. Éviter les défaillances en cascade à travers les microservices

5. Capacité du plan (nombre de RAM/disque/réseau/consommateur)

6. Accélérer le dépannage quand quelque chose ne va pas

Le piège du “ça a marché hier”.

Les défaillances de RabbitMQ apparaissent souvent après :

• un pic de trafic

• un déploiement de consommateurs bloqué

• une panne de dépendance en aval (par exemple, une base de données ou un fournisseur de services de paiement)

• un gestionnaire de messages lent

• une série de messages importants

• diminution de l'espace disque

• filigrane de la mémoire touché

• croissance non limitée de la file d'attente en raison de TTLs/limites manquantes

En d'autres termes, RabbitMQ ne tombe pas en panne au hasard : RabbitMQ ne tombe pas en panne de manière aléatoire - il tombe en panne lorsque le système qui l'entoure change. La surveillance rend ces changements visibles.

Que faut-il surveiller dans RabbitMQ ?

Si vous ne surveillez qu'une seule chose, faites-le :

Profondeur de la file d'attente + santé du consommateur

Car c'est là que se révèle le “travail non fait”.

Mais une bonne configuration de surveillance de RabbitMQ couvre quatre couches :

1. Niveau de file d'attente (flux de messages)

2. Niveau du courtier (internes de RabbitMQ)

3. Niveau nœud/système (OS + disque + mémoire)

4. Niveau d'application (comportement et erreurs de publication/consommation)

Décortiquons les indicateurs les plus importants.

Les mesures de surveillance de RabbitMQ qui comptent vraiment

1) Mesures de la file d'attente (votre alerte précoce #1)

Ces mesures vous indiquent si les messages circulent ou s'accumulent.

Les indicateurs clés :

• Messages prêts: en attente dans la file d'attente

• Messages dépilésLes résultats de l'enquête sont les suivants : livrés aux consommateurs mais pas encore accusés de réception.

• Total des messages: prêt + déballé

• Taux de pénétrationmessages publiés par seconde

• Taux de sortie: messages accusés de réception/consommés par seconde

• Consommateurs en file d'attente: combien de consommateurs sont actifs par file d'attente

À surveiller :

• Le nombre total de messages a tendance à augmenter au fil du temps → les consommateurs ne peuvent pas suivre

• Croissance spontanée → le consommateur est lent, bloqué ou n'accède pas correctement à l'appareil.

• Consommateurs = 0 sur une file d'attente critique → les messages s'accumulent rapidement

• La sortie chute soudainement → problème de dépendance en aval ou consommateurs bloqués

Une règle simple :
Si la file d'attente continue d'augmenter pendant plus de quelques minutes en cas de “trafic normal”, quelque chose ne va pas.

2) Santé des consommateurs (point de départ de nombreux incidents)

RabbitMQ est souvent mis en cause, mais la cause première est souvent un problème de consommateur :

• code déployé avec un bogue

• consommateur bloqué dans les tentatives

• le pool de discussion est épuisé

• lenteur des appels à la base de données

• limites de débit de l'API externe

• fuite de mémoire du consommateur

Moniteur :

• nombre de consommateurs par file d'attente

• taux de consommation vs taux de publication

• messages non piratés

• les journaux d'erreurs des consommateurs (délais, exceptions)

• le temps de traitement (à partir de la télémétrie de l'application, si elle est disponible)

Conseil de pro :
Une file d'attente croissante n'est pas toujours néfaste en cas de pic. Une file d'attente qui croît et ne se rétablit jamais est mauvais.

3) Connexions et canaux (une source sournoise d'instabilité)

Un trop grand nombre de connexions ou de canaux peut dégrader les performances.

Moniteur :

• connexions ouvertes

• canaux par connexion

• la saturation des connexions (déconnexions/reconnexions fréquentes)

• raccordements bloqués (contrôle du débit)

À surveiller :

• des pics soudains de connexions (clients mal configurés)

• nombre élevé de canaux (fuites)

• boucles de reconnexion fréquentes (problèmes de réseau ou d'authentification)

4) Santé du nœud : mémoire, disque, CPU, descripteurs de fichiers

RabbitMQ est sensible à la mémoire et au disque.

Moniteur :

• Utilisation de la mémoire et s'il s'approche du filigrane

• Espace libre sur le disque (RabbitMQ bloquera les éditeurs si le disque est faible)

• UNITÉ CENTRALE (un taux d'UC élevé peut réduire le débit)

• Descripteurs de fichiers (l'épuisement des stocks peut rompre les connexions)

• Débit et erreurs du réseau (les courtiers s'appuient sur un réseau)

Pourquoi le disque est-il si important ?
RabbitMQ conserve les messages (en fonction des paramètres de durabilité) et utilise fortement le disque dans certaines conditions. Lorsque le disque est trop faible, RabbitMQ peut se protéger en bloquant les éditeurs. Cela donne l'impression que “l'application est en panne”, même si le serveur fonctionne.

5) Santé du courtier et statut du groupe

Si vous utilisez un cluster RabbitMQ, surveillez également :

• état du nœud en haut/bas

• partitions en grappes

• le miroir de la file d'attente/la santé de la file d'attente du quorum (en fonction de votre configuration)

• l'état de la synchronisation (le cas échéant)

• les changements de leader et les délais de réplication (pour les files d'attente du quorum)

6) Sécurité au niveau des messages : DLQ, tentatives, TTL

De nombreux systèmes utilisent des tentatives et des lettres mortes pour gérer les défaillances avec élégance. La surveillance permet de s'assurer que la “défaillance gracieuse” ne se transforme pas en “défaillance silencieuse”.”

Moniteur :

• profondeur de la file d'attente des lettres mortes

• taux de messages en lettres mortes

• profondeur de la file d'attente des tentatives (si elle est utilisée)

• l'expiration du TTL du message (le cas échéant)

Si les DLQ augmentent, cela signifie souvent que vos consommateurs échouent et que les messages sont réacheminés - les clients peuvent être affectés même si votre file d'attente principale “semble en bon état”.”

Problèmes courants de RabbitMQ (et le signal de surveillance qui les détecte)

Problème : les consommateurs sont en baisse

Signal :

• Consommateurs = 0

• Le nombre de messages prêts à être envoyés augmente rapidement

Problème : un bogue chez les consommateurs entraîne un ralentissement du traitement

Signal :

• Les hausses non compensées

• Taux de chute des sorties

• Le temps de traitement (mesure de l'application) augmente

Problème : Interruption de la dépendance en aval (DB/API)

Signal :

• Les ascensions sans sac

• Augmentation du nombre d'erreurs et de dépassements de délais chez les consommateurs

• La croissance des files d'attente s'accélère

Problème : Déclenchement d'un filigrane de mémoire élevée

Signal :

• L'utilisation de la mémoire s'approche du filigrane

• Les connexions sont bloquées

• Augmentation de la latence de publication

Problème : Alarme disque / espace disque réduit

Signal :

• Le nombre de disques libres passe en dessous du seuil

• RabbitMQ bloque la publication

• Les délais d'attente des producteurs augmentent

Problème : Fuite de connexion/canal dans une application

Signal :

• Les connexions/canaux sont en constante augmentation

• Les descripteurs de fichiers grimpent

• Éventuellement : échecs de connexion

Problème : une file d'attente “chaude” domine les ressources du courtier

Signal :

• Une file d'attente avec une grande profondeur et des taux élevés

• D'autres deviennent lents même si le volume est faible

• Pics d'activité de l'unité centrale et augmentation de la latence des courtiers

La surveillance ne se contente pas de vous dire que quelque chose ne va pas - il pointe vers où.

Comment surveiller RabbitMQ : une approche pratique

Une stratégie simple et efficace est la suivante :

1. Commencer par l'essentiel
   Profondeur de la file d'attente, consommateurs, entrée/sortie, déstockage, mémoire, disque.

2. Ajouter des alertes en fonction de l'impact sur l'entreprise
   Alerte sur les tendances (augmentation de l'arriéré), et pas seulement sur les seuils bruts.

3. Créer des tableaux de bord autour des flux de travail
   Afficher les files d'attente regroupées par domaine d'activité : caisse, notifications, facturation.

4. Établir une corrélation entre les mesures des courtiers et la télémétrie des applications
   Les métriques RabbitMQ + les journaux d'erreurs des consommateurs = cause première rapide.

5. Utiliser des signaux de type SLO
   “Les messages sont traités dans un délai de X minutes” est plus significatif que CPU%.

Solutions de haut niveau pour surveiller RabbitMQ

Vous trouverez ci-dessous des options éprouvées utilisées dans des environnements de production réels.

1) Xitoring (Surveillance tout-en-un pour RabbitMQ et l'ensemble de votre stack)

Xitoring.com est une solution de surveillance tout-en-un conçue pour vous aider à surveiller les infrastructures et les services critiques - y compris les courtiers en messages comme RabbitMQ - d'une manière claire et exploitable.

Pourquoi il s'adapte bien à la surveillance de RabbitMQ :

• Tableaux de bord centraux pour l'infrastructure et les services (un seul endroit à consulter)

• Alerte conçue pour les moments où “quelque chose ne va pas tout de suite”.

• Une visibilité de haut niveau qui aide les développeurs et les équipes d'exploitation.

• Utile lorsque les problèmes liés à RabbitMQ sont les symptômes de problèmes plus généraux (DB, réseau, latence de l'application).

Meilleur pour :
Les équipes qui souhaitent une centre de surveillance unique au lieu d'assembler plusieurs outils, et veulent que la surveillance de RabbitMQ fasse partie d'une image plus large de la “pile complète”.

2) Plugin de gestion RabbitMQ (interface utilisateur intégrée + métriques de base)

RabbitMQ comprend une interface de gestion (si elle est activée) qui affiche les files d'attente, les taux, les connexions, les consommateurs et les statistiques des nœuds.

Pour :

• Rapide à mettre en place

• Idéal pour l'inspection manuelle et le débogage

• Affiche clairement les détails au niveau de la file d'attente

Cons :

• Il ne s'agit pas d'un système de surveillance à part entière

• Alertes et tendances à long terme limitées, sauf si elles sont intégrées ailleurs

Meilleur pour :
Dépannage rapide et visibilité au jour le jour, en particulier dans les petites structures.

3) Prometheus + Grafana (pile de surveillance open-source populaire)

L'approche la plus courante est la suivante :

• Exporter les métriques RabbitMQ via un exportateur ou des points d'extrémité intégrés

• Collecter avec Prometheus

• Visualiser et alerter avec Grafana/Alertmanager

Pour :

• Tableaux de bord et alertes puissants

• Un écosystème solide et des modèles communautaires

• Idéal pour les tendances à long terme et les SLO

Cons :

• Plus d'installation et de maintenance

• Vous aurez probablement besoin de régler les alertes et les tableaux de bord

Meilleur pour :
Équipes utilisant déjà Prometheus ou souhaitant une solution flexible à code source ouvert.

4) Datadog (plateforme d'observabilité SaaS)

Datadog prend en charge la surveillance de RabbitMQ par le biais d'intégrations et peut corréler les mesures des courtiers avec les hôtes, les conteneurs et les traces APM.

Pour :

• Embarquement rapide

• Forte corrélation entre les mesures, les journaux et les traces

• Excellentes alertes et visualisation

Cons :

• Le coût augmente avec l'échelle

• Dépendance à l'égard du SaaS

Meilleur pour :
Les équipes qui souhaitent un délai de rentabilisation rapide et une grande observabilité.

5) New Relic (plateforme d'observabilité SaaS)

New Relic assure la surveillance de l'infrastructure, l'APM, les tableaux de bord et les alertes. RabbitMQ peut être surveillé par le biais d'intégrations et de pipelines de métriques personnalisés.

Pour :

• Visibilité complète (APM + infra)

• Bons tableaux de bord et alertes

Cons :

• Nécessite une configuration réfléchie pour obtenir les meilleurs signaux RabbitMQ

Meilleur pour :
Les équipes utilisent déjà New Relic pour la surveillance des applications.

6) Elastic Stack (ELK) pour les logs et les métriques (et les tableaux de bord Kibana)

Elastic est largement utilisé pour l'agrégation de logs et peut également gérer des métriques en fonction de votre configuration.

Pour :

• Excellente recherche et corrélation des journaux

• Des tableaux de bord puissants pour l'analyse opérationnelle

Cons :

• Peut devenir complexe à grande échelle

• Nécessité d'une bonne discipline en matière de schémas et de rétention

Meilleur pour :
Les équipes pour lesquelles les journaux sont un outil essentiel pour le diagnostic et le respect des règles.

7) Splunk

Splunk est couramment utilisé dans les grandes organisations pour l'agrégation des journaux, les alertes et l'intelligence opérationnelle.

Pour :

• De fortes capacités d'entreprise

• Requêtes et alertes puissantes

Cons :

• Peut être coûteux et lourd à utiliser

Meilleur pour :
Grandes entreprises disposant de flux de travail matures en matière d'observabilité.

8) Surveillance du fournisseur de services en nuage (lorsque RabbitMQ est géré)

Si vous utilisez RabbitMQ via un service géré (ou une offre gérée par un fournisseur), vous pouvez vous appuyer sur :

• Surveillance du nuage (comme les équivalents de CloudWatch)

• Tableaux de bord des fournisseurs + points de terminaison des mesures

Pour :

• Moins de travail opérationnel

• Intégré aux alertes de la plateforme

Cons :

• Peut ne pas exposer la profondeur que vous souhaitez pour les opérations au niveau de la file d'attente

• Il faut encore une visibilité au niveau de l'application

Meilleur pour :
Les équipes donnent la priorité à la réduction des frais généraux d'exploitation.

Construire un tableau de bord de monitoring RabbitMQ (ce qu'il faut inclure)

Si vous créez un tableau de bord dans Xitoring (ou tout autre outil), construisez-le autour des questions que vous posez lors des incidents.

Section A : “Le flux de messages est-il sain ?”

• nombre total de messages par file d'attente critique

• messages prêts ou non emballés

• taux de publication vs taux d'ack

• nombre de consommateurs par file d'attente

• Profondeur et taux de DLQ

Section B : “Le courtier est-il sous pression ?”

• l'utilisation de la mémoire (et la proximité du filigrane)

• espace libre du disque

• Utilisation de l'unité centrale

• débit du réseau

• descripteurs de fichiers

Section C : “Le groupe est-il stable ?”

• nœud haut/bas

• événements de la partition

• réplication de la file d'attente / santé du quorum (le cas échéant)

Section D : “Les applications se comportent-elles bien ?”

• erreurs de publication du producteur/temps morts

• taux d'erreur du consommateur

• temps de traitement des consommateurs

• taux de reconnexion

Conseil : Placez vos files d'attente les plus critiques en haut de la page. En cas d'incident, personne n'a envie de faire défiler les files d'attente.

Alertes pour RabbitMQ : rester simple et utile

Les alertes doivent être exploitables. Une bonne alerte RabbitMQ répond :

• Qu'est-ce qui est touché ?

• Où cela se produit-il (quelle file d'attente/nœud) ?

• Quelle est l'urgence ?

Des alertes pratiques qui fonctionnent bien

1) L'arriéré des files d'attente s'accroît

• Déclenchement lorsque la profondeur de la file d'attente augmente de façon continue pendant N minutes

2) Les consommateurs manquent à l'appel

• Déclenchement lorsque le nombre de consommateurs est égal à 0 pour une file d'attente critique pendant plus de 1 à 2 minutes

3) Les messages non annoncés sont trop élevés

• Déclenchement lorsque l'unacked dépasse un seuil (ou augmente régulièrement)

4) Espace disque réduit

• Déclenchement lorsque le disque libre passe en dessous d'un seuil de sécurité (défini en fonction de votre environnement).

5) Pression de la mémoire

• Déclenchement lorsque la mémoire est élevée et monte vers le filigrane

6) Croissance de DLQ

• Déclenchement lorsque la profondeur de DLQ augmente au-delà de la ligne de base normale

Éviter les alertes bruyantes

• Ne vous fiez pas uniquement aux pics d'activité de l'unité centrale.

• Ne vous fiez pas uniquement à la profondeur de la file d'attente sans tenir compte du contexte.

• Alerter sur les tendances + les consommateurs manquants + les limites des ressources des courtiers.

Meilleures pratiques pour un contrôle plus efficace

La surveillance est plus efficace lorsque l'installation de RabbitMQ est également conçue pour la stabilité.

1) Empêcher une croissance infinie

• Utiliser les TTL le cas échéant

• Utiliser les DLQ de manière intentionnelle

• Envisager des politiques de longueur maximale pour les files d'attente qui doivent être limitées

2) Limiter les messages

Les messages volumineux augmentent la charge de la mémoire et du réseau. Dans la mesure du possible, il est préférable d'envoyer les identifiants et d'aller chercher les détails ailleurs.

3) Utiliser correctement les remerciements

• Ack seulement après le succès du traitement

• Attention à l'auto-ack (il peut cacher des échecs)

4) Contrôler la préfixation

Les paramètres de prefetch du consommateur affectent le nombre d'unacked et le débit. La surveillance du nombre d'annulations vous permet d'ajuster la fonction de prélecture.

5) Séparer les charges de travail

Placez les charges de travail lentes ou rares dans des files d'attente séparées afin qu'elles ne bloquent pas les flux prioritaires.

6) Surveillez les “tempêtes de tentatives”.”

Si les consommateurs font des tentatives trop agressives, vous pouvez surcharger RabbitMQ et les systèmes en aval. Les DLQ et les tentatives retardées sont utiles.

Réflexions finales : Surveiller RabbitMQ comme s'il s'agissait d'un produit

RabbitMQ n'est pas seulement une “infrastructure”. C'est une partie vivante du comportement de votre système. Lorsqu'il ralentit, votre entreprise ralentit.

Une bonne configuration de surveillance vous permet de répondre rapidement et en toute confiance :

• Les messages circulent-ils ?

• Si ce n'est pas le cas, quelle file d'attente est bloquée ?

• Le courtier est-il en bonne santé ?

• Les consommateurs travaillent-ils - ou échouent-ils en silence ?

• S'agit-il d'un pic, d'un bogue ou d'un problème de capacité ?

Si vous souhaitez que la surveillance de RabbitMQ s'inscrive dans une approche plus large de “surveillance de tout en un seul endroit”, Xitoring est une excellente première option à considérer - en particulier lorsque les problèmes de RabbitMQ ne sont qu'une pièce d'un puzzle de performances plus large.