RabbitMQ 024 – Monitoring : prometheus & exporter

TL;DR

RabbitMQ est un broker de messages utilise pour decoupler des applications, absorber des traitements asynchrones et router des evenements vers des consommateurs. Dans cet episode, le sujet central est: Monitoring : prometheus & exporter. L’objectif est de relier la theorie AMQP, les commandes du depot Xavki et les choix d’architecture concrets.

La video de reference

Video: https://www.youtube.com/watch?v=y1_nu97BGuQ

Playlist complete: https://www.youtube.com/playlist?list=PLn6POgpklwWqiqKEriklbvbSd60-weOqh

Le depot support est disponible ici: https://gitlab.com/xavki/tutorials-rabbitmq. Le support de ce chapitre se trouve dans 24-prometheus-metrics/slides.md.

RabbitMQ et Monitoring : prometheus & exporter: c’est quoi exactement ?

Dans une architecture applicative, RabbitMQ joue le role d’intermediaire entre les producteurs et les consommateurs. Les producteurs publient des messages, le broker les route selon une topologie, puis les consommateurs les traitent. Le chapitre 24-prometheus-metrics sert a isoler une brique de ce modele pour eviter de tout melanger: protocole, cluster, administration, permissions, queues ou integration Kubernetes.

Sur Kubernetes, RabbitMQ devient un workload stateful. L’operator simplifie le cycle de vie du cluster, tandis que le topology operator declare vhosts, users, exchanges, queues et bindings comme des objets Kubernetes.

Le vrai probleme que ce chapitre resout

Le probleme n’est pas seulement de lancer RabbitMQ. Il faut surtout integrer RabbitMQ dans une plateforme moderne: Kubernetes, operators, monitoring, autoscaling et pipelines de messages. C’est ce qui fait la difference entre une demo qui fonctionne localement et un systeme que l’on sait diagnostiquer quand les messages s’accumulent, quand une queue ne recoit rien ou quand un consommateur tombe.

Points cles vus dans le support Xavki

• installation du plugin prometheus
• test de la route metrics
• installation de prometheus
• ajout du scrape pour rabbitmq
• dashboard grafana
• autre exporter
• règles – préparation
• règles – exemple

Ces elements viennent du support de cours du depot. Ils doivent etre lus comme une progression: comprendre les termes, manipuler le broker, puis verifier l’etat observe avec les outils RabbitMQ ou Kubernetes selon le contexte.

Modele mental minimal

Pour raisonner proprement, gardez cette chaine en tete: producer -> exchange -> binding -> queue -> consumer. Une erreur de routage peut venir du type d’exchange, de la routing key, du binding, de la queue cible, des permissions du user ou du vhost utilise. En pratique, on diagnostique donc toujours de gauche a droite.

Approfondissement spécifique

Dans Monitoring : prometheus & exporter, le sujet est l observabilite RabbitMQ: exporter les metriques du broker, les scraper avec Prometheus, puis lire des signaux utiles sur queues, connexions, consumers, memoire et disque.

Une metrique exposee ne suffit pas. Il faut verifier la target Prometheus, une requete concrete et le lien avec un comportement RabbitMQ visible comme une queue qui grossit.

Dans ce chapitre, le depot apporte aussi des artefacts concrets: 24-prometheus-metrics/config.json, 24-prometheus-metrics/slides.md. Ces fichiers ne sont pas de simples annexes: ils donnent les noms de ressources, les manifests, les scripts ou les configurations qui permettent de refaire le lab.

Ce que cet épisode cherche à modifier

• activer ou verifier l exposition des metriques
• scraper RabbitMQ avec Prometheus
• tester une requete sur queues ou consumers
• relier metriques et diagnostic broker

Chemin de diagnostic recommande

• verifier les pods, services, endpoints et PVC
• lire les events Kubernetes avant les logs applicatifs
• controler les probes RabbitMQ et les commandes rabbitmq-diagnostics
• verifier les secrets, le cookie Erlang et la resolution DNS entre pods
• confirmer: activer ou verifier l exposition des metriques
• confirmer: scraper RabbitMQ avec Prometheus
• confirmer: tester une requete sur queues ou consumers

Points de vigilance en production

• prevoir des ressources CPU/memoire explicites
• surveiller la taille des queues et le rythme des consumers
• documenter la strategie de backup et d upgrade
• ne jamais stocker les secrets en clair dans les manifests versionnes

Checklist de pratique

• declarer le stockage persistant
• verifier readiness et liveness avec rabbitmq-diagnostics
• exposer les metriques Prometheus
• separer cluster operator et topology operator
• tester les consommateurs avant d’activer l’autoscaling

Commandes du chapitre

• rabbitmq-plugins list | grep prometheus
• rabbitmq-plugins enable rabbitmq_prometheus
• curl -s localhost:15692/metrics | grep rabbitmq

Pieges courants

• traiter RabbitMQ comme un simple Deployment stateless
• oublier le PVC et la strategie de redemarrage
• mettre les secrets en clair dans les manifests
• confondre metriques broker et metriques applicatives

Mini-lab conseille

Deployeez un cluster RabbitMQ avec l’operator, creez une queue via le topology operator puis exposez les metriques pour Prometheus.

L’important est de casser volontairement un parametre: mauvaise routing key, queue absente, permission trop restrictive, noeud indisponible ou consommateur arrete. RabbitMQ devient beaucoup plus clair quand on observe ce qui se passe dans l’interface de management, les logs et les commandes de diagnostic.

Liens utiles

• Depot Xavki tutorials-rabbitmq
• Playlist YouTube RabbitMQ Xavki
• Documentation officielle RabbitMQ
• Guide AMQP 0-9-1 RabbitMQ
• RabbitMQ Management Plugin
• RabbitMQ Clustering
• RabbitMQ Kubernetes Operator
• 24-prometheus-metrics

Lien interne conseille

Pour revenir au sujet precedent, consultez RabbitMQ 023 – Kubernetes : manager un cluster externe (topology).

FAQ

RabbitMQ est-il equivalent a Kafka ?

Non. RabbitMQ est d’abord un broker de messages oriente queues et routage AMQP. Kafka est plutot un journal distribue d’evenements. Les deux peuvent transporter des messages, mais leur modele de consommation, de retention et de relecture n’est pas le meme.

Faut-il commencer par la GUI ou par la ligne de commande ?

Pour apprendre, la GUI aide a visualiser exchanges, queues, bindings et consommateurs. Pour exploiter et automatiser, il faut aussi connaitre les commandes comme rabbitmqctl, rabbitmq-diagnostics, les fichiers de configuration et, sur Kubernetes, les manifests.

Pourquoi les messages n’arrivent-ils pas dans ma queue ?

Les causes frequentes sont une routing key incorrecte, un binding manquant, un mauvais vhost, des permissions insuffisantes, un exchange mal choisi ou un consumer qui acquitte puis supprime les messages plus vite que vous ne les observez.

RabbitMQ sur Kubernetes est-il toujours une bonne idee ?

Ce n’est pas automatique. Kubernetes apporte l’orchestration, le stockage persistant et les operators, mais RabbitMQ reste un composant stateful. Il faut verifier stockage, DNS, probes, secrets, upgrades et supervision avant de le traiter comme un service banal.

Conclusion

Cet episode 24 pose une brique de plus dans la formation RabbitMQ. L’approche la plus efficace consiste a garder le vocabulaire precis, reproduire les exemples du depot, puis ajouter une verification systematique: topologie visible, logs, commandes de diagnostic et comportement reel des producteurs et consommateurs.