Tout commence par un compteur d’onglets.
Vous êtes en plein incident. La latence des messages a spikté il y a 45 minutes sur trois brokers — un par environnement, comme tout le monde configure ça au début. Vous ouvrez le plugin de gestion sur le broker 1, vous vérifiez les profondeurs de queue, vous ouvrez un nouvel onglet pour le broker 2, vous vérifiez à nouveau, un troisième onglet pour le broker 3. Rien ne semble manifestement anormal là maintenant, mais vous avez besoin de savoir ce qui se passait il y a 45 minutes, quand le spike a vraiment commencé.
Le plugin de gestion ne peut pas vous le dire. Il vous montre l’état courant. Il vous montre un sparkline de 10 minutes dans la vue détail de la queue si vous descendez. Il ne vous montre pas ce qui s’est passé avant que vous ouvriez l’onglet.
Alors vous ouvrez Datadog. Ou Grafana. Ou Prometheus. Et vous reconstituez la timeline à partir de quatre écrans différents, dont aucun n’a été conçu pour dialoguer avec les autres.
C’est le pattern. Le plugin de gestion est là où tout le monde commence avec le monitoring RabbitMQ, et il est vraiment bon pour ce qu’il fait — parcourir les exchanges et les bindings, publier des messages de test, faire des vérifications rapides de santé. Mais il y a cinq plafonds que vous allez atteindre en production, et ils surgissent tous au pire moment.
Qarote met l’observabilité multi-broker, les métriques historiques et l’alerting en un seul endroit — sans setup Prometheus. Voir comment ça fonctionne →
1. Pas de vue multi-broker
Le plugin de gestion est par nœud. Chaque broker RabbitMQ a sa propre interface de gestion sur :15672, et il n’y a aucun moyen d’agréger plusieurs brokers depuis le plugin lui-même.
Pour les clusters, ça va — l’interface de gestion sur n’importe quel nœud affiche le cluster entier. Mais la plupart des setups en production finissent par ressembler à ça : un broker de staging, un broker de production, et peut-être un broker séparé pour un service spécifique. Vous avez maintenant trois interfaces de gestion. Ajoutez des outils internes, des intégrations partenaires ou un broker séparé pour des jobs asynchrones, et vous en êtes à cinq.
Ce que ça coûte : Chaque incident cross-broker devient un exercice de jonglage d’onglets. Vous ne pouvez pas écrire une seule requête qui demande « laquelle de mes queues, sur tous mes environnements, a une profondeur supérieure à X ? » Vous ne pouvez pas voir d’un coup d’œil que la queue de l’event bus sur le broker des intégrations grossit pendant que la queue principale en production est stable. Vous changez de contexte en permanence, ce qui ralentit le diagnostic exactement quand la vitesse compte.
Le vrai contournement : Taguez vos brokers dans Prometheus et écrivez des requêtes qui agrègent sur le label job. Quelque chose comme :
# Profondeur de queue sur tous les brokers, triée décroissant
topk(10,
rabbitmq_queue_messages{job=~"rabbitmq-.*"}
)Ça marche bien si vous avez déjà investi dans le stack Prometheus + Grafana. C’est aussi un engagement infra non négligeable — voir Comment configurer des alertes RabbitMQ qui se déclenchent vraiment quand il le faut pour le setup complet.
Qarote traite le multi-broker comme une fonctionnalité de base : ajoutez autant de connexions que vous avez de brokers et chaque vue est agrégée sur tous par défaut.
2. Pas de métriques historiques au-delà de la fenêtre de rétention en mémoire
Ouvrez l’interface de gestion et cliquez sur n’importe quelle queue. Vous verrez un graphique « Message rates » avec un sparkline affichant les 60 dernières secondes environ par défaut. Dans le menu déroulant « Charts », vous pouvez étendre cette fenêtre — mais seulement aussi loin que les données que RabbitMQ a retenues en mémoire.
Par défaut, cette fenêtre de rétention est de 60 secondes. Vous pouvez l’augmenter en configurant collect_statistics_interval et management.rates_mode dans la config du broker, mais il y a une limite dure : tout vit en mémoire. Un broker de production typique retient peut-être 5 à 10 minutes d’historique de métriques. Redémarrez le broker et c’est perdu.
Ce que ça coûte : L’analyse post-incident devient de l’archéologie. Quelque chose s’est mal passé à 2h14. Vous investiguez à 2h45. Le plugin de gestion a 10 minutes de sparklines de 2h35 à 2h45. La fenêtre où les choses ont vraiment cassé a disparu. Vous travaillez à partir des logs, des taux d’erreurs des consumers depuis un outil APM externe, et de ce que Prometheus a scrapé — si Prometheus était configuré et que le scraper n’a pas raté la fenêtre.
Cette limitation rend aussi la planification de capacité quasi impossible depuis le plugin. Vous ne pouvez pas répondre à « à quoi ressemble notre profondeur de queue à 9h le lundi par rapport au jeudi ? » sans un store de métriques externe.
Le vrai contournement : Prometheus avec le plugin Prometheus de RabbitMQ (rabbitmq-plugins enable rabbitmq_prometheus) vous donne une rétention de métriques long terme. Associez-le à Grafana pour des dashboards et vous pouvez requêter aussi loin que votre politique de rétention le permet.
# prometheus.yml — scraper les métriques RabbitMQ
scrape_configs:
- job_name: rabbitmq
static_configs:
- targets: ["rabbitmq:15692"]
scrape_interval: 15sL’intervalle de scrape à 15 secondes est important. À 60 secondes, vous raterez les incidents rapides — une queue qui se remplit et se vide en moins d’une minute n’apparaîtra pas de façon significative. Voir Comment déboguer un backlog de queue RabbitMQ pour comprendre pourquoi la fréquence de scrape est un facteur de premier ordre dans le diagnostic des backlogs.
3. Pas d’alerting
Le plugin de gestion n’a aucun mécanisme d’alerting. Aucun. Vous pouvez voir que votre alarme mémoire est déclenchée dans la vue d’ensemble — elle devient rouge — mais seulement si vous regardez déjà l’interface. Il n’y a aucun moyen de configurer le plugin pour vous envoyer une notification quand une profondeur de queue dépasse un seuil, quand un consumer disparaît, quand l’espace disque libre tombe sous une limite, ou quand les taux de messages spikent.
C’est le manque le plus conséquent. Toutes les autres limitations vous demandent d’utiliser un outil différent pour investiguer. Celle-là vous demande d’utiliser un outil différent pour savoir qu’il y a un problème.
Ce que ça coûte : Vous découvrez les problèmes de queue quand les utilisateurs remontent des erreurs. Ou quand un service downstream commence à timeouter. Ou quand la DLQ que personne n’avait mise sur un dashboard a accumulé 40 000 messages et que quelqu’un finit par le remarquer lors de la revue hebdomadaire.
Le coût d’astreinte s’accumule aussi. Sans alerting, le seul moyen de savoir que votre broker a un problème est de le regarder. Personne ne surveille des dashboards à 3h du matin.
Le vrai contournement : Branchez l’endpoint Prometheus de RabbitMQ et configurez des règles Alertmanager. Les alertes de base dont tout setup en production a besoin :
groups:
- name: rabbitmq
rules:
# Alarme mémoire déclenchée
- alert: RabbitMQMemoryAlarm
expr: rabbitmq_alarms_memory_used_watermark == 1
for: 0m
labels:
severity: critical
annotations:
summary: "Memory alarm fired on {{ $labels.instance }}"
# Profondeur de queue élevée
- alert: RabbitMQQueueDepthHigh
expr: rabbitmq_queue_messages > 10000
for: 5m
labels:
severity: warning
annotations:
summary: "Queue {{ $labels.queue }} has {{ $value }} messages"
# Nombre de consumers tombé à zéro
- alert: RabbitMQNoConsumers
expr: rabbitmq_queue_consumers == 0 and rabbitmq_queue_messages > 0
for: 2m
labels:
severity: critical
annotations:
summary: "Queue {{ $labels.queue }} has messages but no consumers"
# DLQ qui reçoit des messages
- alert: RabbitMQDLQGrowing
expr: |
rate(rabbitmq_queue_messages_published_total{
queue=~".*dlq.*|.*dead.*|.*failed.*"
}[5m]) > 0
for: 5m
labels:
severity: warning
annotations:
summary: "DLQ {{ $labels.queue }} receiving messages"Pour le setup d’alerting complet incluant le routage, la configuration des receivers, et quelles alertes se déclenchent en premier dans une cascade d’incident, voir Comment configurer des alertes RabbitMQ qui se déclenchent vraiment quand il le faut.
Qarote embarque ces types d’alertes nativement — seuils de profondeur de queue, chutes du nombre de consumers, alarmes mémoire et disque, croissance des DLQ — et les évalue sur vos données broker en direct sans nécessiter de setup Prometheus. Voir les fonctionnalités d’alerting →
4. Les permissions sont tout-ou-rien
Le plugin de gestion a quatre tags utilisateur : management, policymaker, monitoring, et administrator. C’est tout.
management donne accès à l’interface. monitoring donne l’interface plus les stats au niveau du nœud. policymaker permet de définir des policies. administrator donne tout.
Il n’y a pas de modèle de permissions qui dit « cet utilisateur peut voir toutes les queues dans le vhost payments mais rien dans internal ». Il n’y a pas de vue lecture seule qui expose les taux de messages sans exposer la capacité à purger une queue. Il n’y a pas de moyen de donner à un ingénieur d’astreinte l’accès au broker sans lui donner la permission de publier des messages vers des exchanges. Et il n’y a pas de journal d’audit — quand une queue est purgée à 2h du matin, aucune trace de qui l’a fait.
Ce que ça coûte : En pratique, la plupart des équipes finissent par partager un login de monitoring unique avec le tag monitoring sur toute la rotation d’astreinte. Cela signifie pas de responsabilité individuelle, pas de portée d’accès, et aucun moyen de donner à votre équipe ops une vue lecture seule sans leur donner aussi la capacité de modifier des bindings s’ils cliquent au mauvais endroit.
Les équipes les plus prudentes verrouillent complètement l’interface de gestion et n’exposent que des dashboards Grafana aux opérateurs — ce qui résout le problème de permissions mais supprime aussi les capacités de debug interactif qui rendent l’interface de gestion utile en premier lieu.
Le vrai contournement : Il n’y en a pas de propre dans le plugin de gestion lui-même. L’approche la moins mauvaise est des vhosts séparés par environnement ou périmètre de service, avec des credentials utilisateur séparés qui ont un tag management scopé à des vhosts spécifiques :
# Créer un utilisateur de monitoring scopé à un vhost
rabbitmqctl add_user payments-monitor <password>
rabbitmqctl set_user_tags payments-monitor monitoring
rabbitmqctl set_permissions -p /payments payments-monitor "^$" "^$" ".*"La commande set_permissions prend des patterns configure, write et read. Mettre configure et write à ^$ (ne correspond à rien) et read à .* (correspond à tout) donne à cet utilisateur un accès lecture seule sur le vhost /payments. Il peut voir les profondeurs de queue et les taux de messages mais ne peut pas publier, purger ou modifier quoi que ce soit.
Ça marche mais ça ne passe pas à l’échelle. Trente services, quatre environnements, trois niveaux d’accès : vous gérez une matrice d’utilisateurs scopés à des vhosts sans aucun outillage pour auditer qui a quoi. RabbitMQ n’a pas d’interface native pour ça — vous le faites dans rabbitmqctl ou via l’API HTTP.
5. Pas de séparation par workspace ou équipe pour les setups multi-environnement
Lié à la limitation des permissions, mais distinct : le plugin de gestion n’a aucune notion de workspaces, d’environnements ou d’équipes. Tout ce que vous pouvez voir est déterminé par vos credentials utilisateur. Il n’y a aucun moyen de regrouper « broker de staging, queues de staging, exchanges de staging » dans un environnement étiqueté que votre équipe peut basculer d’un clic.
En pratique, ça signifie que vos développeurs se connectent à l’interface de gestion de production quand ils ont besoin de vérifier quelque chose. Non pas parce qu’ils le veulent — parce qu’il n’y a pas de moyen ergonomique de séparer « je veux regarder le staging » de « je veux regarder la production » au-delà de garder des profils de navigateur séparés avec des mots de passe sauvegardés différents.
Ce que ça coûte : Des erreurs ops. La publication accidentelle vers un exchange de production qui était destinée au staging. Le rabbitmqadmin purge queue lancé contre le mauvais vhost. Non pas parce que les ingénieurs ne font pas attention — parce que l’outil ne fournit aucune friction entre production et non-production, et sous la charge cognitive d’un incident, c’est la friction qui prévient les erreurs.
Le vrai contournement : Des dossiers de dashboards Grafana séparés, tagués par environnement. Des conventions de nommage strictes sur les queues et exchanges (préfixer tout avec prod., staging., dev.). Des favoris de navigateur. Rien de tout ça n’est une vraie solution — ce sont des substituts à la friction qui tiennent jusqu’à ce qu’ils ne tiennent plus.
Certaines équipes font tourner une seconde instance Grafana pointant sur les métriques de staging uniquement, la gardant entièrement séparée du stack d’observabilité de production. Ça marche et c’est probablement l’approche la plus défendable pour les équipes qui ont déjà beaucoup investi dans le stack Prometheus + Grafana. Le coût opérationnel est de maintenir deux stacks.
Pour les équipes qui évaluent depuis zéro : les workspaces Qarote répondent directement à ce problème — vous modélisez vos brokers, environnements et accès équipe en un seul endroit, avec des permissions explicites au niveau du workspace. Votre ingénieur d’astreinte ne peut pas accidentellement agir sur le broker de production en pensant regarder le staging parce que l’interface rend la séparation visible à chaque niveau.
Quand le plugin de gestion suffit
Soyons honnêtes : la plupart du temps, et surtout au démarrage, le plugin de gestion suffit.
Il est livré avec RabbitMQ. Il se charge instantanément. Il a un excellent navigateur de queues et d’exchanges. La capacité de publier un message de test dans un exchange et de le tracer à travers les bindings est précieuse pour déboguer la configuration de routage. Le CLI rabbitmqadmin qui l’accompagne est une interface de scripting solide.
Si vous avez un seul broker, une petite équipe, et Prometheus déjà en place, vous pouvez combler la plupart de ces lacunes avec des règles Alertmanager et quelques dashboards Grafana. Les alertes de la section 3 ci-dessus constituent une base complète.
Le plugin de gestion devient un goulot d’étranglement quand vous avez plusieurs brokers, quand la rotation d’astreinte implique que plusieurs ingénieurs ont besoin d’un accès à l’observabilité, quand vous déboguez des incidents en travers des environnements, ou quand vous avez besoin de métriques historiques qui survivent à une fenêtre mémoire de 10 minutes.
tl;dr
Le plugin de gestion RabbitMQ vous donne un navigateur de queues et une vue temps réel étroite. En production, il a cinq lacunes dures : pas d’agrégation multi-broker (chaque broker est un onglet séparé), pas de métriques historiques au-delà de ce qui tient dans la mémoire du broker (par défaut : ~60 secondes), pas d’alerting (vous découvrez les problèmes quand les utilisateurs vous le disent), des permissions tout-ou-rien sans journal d’audit, et aucune séparation par workspace entre les environnements. Des contournements existent pour les cinq — Prometheus pour les métriques et l’alerting, des utilisateurs scopés à des vhosts pour la limitation des permissions, des instances Grafana séparées pour la séparation des environnements — mais ils s’accumulent. Un stack de monitoring complet en production construit à partir de ces briques a un coût infra et opérationnel réel. Pour les équipes qui ont déjà investi dans Prometheus, ce coût est absorbé dans le travail existant. Pour les équipes qui évaluent depuis zéro, c’est un engagement significatif avant d’avoir vu votre premier incident.
Le plugin de gestion est là où commence le monitoring RabbitMQ. Savoir où il s’arrête avant de heurter un incident, c’est l’objet de cet article.