Pourquoi nous avons construit Qarote : une guerre des files d'attente

Le message est arrivé à 2 h 47 du matin. Pas une alerte PagerDuty — un message Slack d’un client.

« Hé, vous avez des problèmes en ce moment ? Nos jobs ne sont pas traités depuis une heure. »

Une heure.

J’ai ouvert le plugin de management RabbitMQ. Le graphique de profondeur de file d’attente était une ligne verticale. 847 000 messages. Notre file principale s’était remplie, sans surveillance, pendant soixante-trois minutes. Deux consommateurs étaient connectés. Aucun ne traitait quoi que ce soit.

J’avais quatre onglets ouverts en trente secondes : le plugin de management, Grafana, CloudWatch et un thread Slack où mes collègues essayaient de comprendre la même chose depuis des tableaux de bord différents.

Personne ne savait ce qui s’était passé.

Ce que les outils montraient

Le plugin de management m’a dit ce que je savais déjà en regardant le graphique : la file était profonde, le taux de messages était zéro, et deux consommateurs étaient listés comme connectés.

Ce qu’il ne pouvait pas me dire :

• Quels consommateurs étaient ces deux-là ? Étaient-ce les workers attendus, ou des connexions zombie d’un déploiement précédent ?
• Pourquoi étaient-ils connectés mais ne traitaient-ils rien ? Bloqués sur un message ? Crashant silencieusement ? En attente d’un service en aval ?
• Quand le backlog de file a-t-il commencé ? La résolution du graphique était trop grossière pour identifier le moment exact où les choses avaient déraillé.
• S’agissait-il d’une file isolée ou d’un effet en cascade ? J’avais quinze files. Le plugin m’en montrait une à la fois.
• À quoi ressemblaient les messages ? Impossible d’inspecter un seul message sans écrire un consommateur jetable — ce qui signifiait que je ne pouvais pas confirmer si les messages eux-mêmes étaient malformés ou si le problème venait des consommateurs.

J’ai basculé sur Grafana. Les métriques Prometheus RabbitMQ que nous avions configurées donnaient des données temporelles pour la profondeur de file et le nombre de consommateurs, mais l’intervalle de scrape était de 60 secondes — les données avaient déjà une minute de retard. Et les tableaux de bord étaient organisés par broker, pas par ce dont j’avais réellement besoin : une liste des files se comportant anormalement à cet instant.

Quarante minutes après le début de l’incident, j’ai finalement isolé la cause : un pool de connexions à la base de données épuisé sous charge. Les consommateurs récupéraient des messages, échouaient silencieusement sur le premier appel DB, nackaient sans journaliser l’erreur, puis replaçaient en file — créant une boucle serrée qui ressemblait, depuis le plugin de management, à « deux consommateurs connectés, débit zéro ».

La correction a pris cinq minutes. Le diagnostic en a pris quarante.

Le vrai problème

J’ai beaucoup réfléchi à cet incident depuis.

Le problème n’était pas que nous avions de mauvais outils. Le plugin de management est vraiment utile au quotidien. Prometheus + Grafana est une pile de monitoring légitime. Le problème était qu’aucun de ces outils n’était conçu pour répondre à la question que je posais réellement à 3h du matin : qu’est-ce qui ne va pas, maintenant, et que dois-je faire ?

Le plugin de management montre l’état. Grafana montre l’historique. Aucun ne montre la causalité.

Pour diagnostiquer correctement un incident RabbitMQ, il faut corréler des informations provenant d’endroits différents : la profondeur de file avec la santé des consommateurs, la santé des consommateurs avec les taux d’acquittement, les taux d’acquittement avec les files spécifiques où les consommateurs sont bloqués. Il faut voir quels consommateurs traitent réellement et lesquels sont connectés-mais-gelés. Il faut voir si le backlog d’une file a commencé à croître en même temps que le nombre de consommateurs a chuté, ou avant — parce que ce sont des incidents différents.

Rien de tout cela n’était surfacé automatiquement. Il fallait tout assembler manuellement, onglet par onglet, pendant un incident.

La pile de monitoring standard pour un déploiement RabbitMQ en production ressemblait à :

• Plugin de management — interface web, bien pour l’inspection manuelle
• Exporteur Prometheus — transforme les métriques RabbitMQ en endpoints scrapables
• Alertmanager — route les alertes basées sur les métriques vers Slack ou PagerDuty
• Grafana — tableaux de bord pour l’analyse des tendances
• Scripts personnalisés — généralement Python, généralement pour vérifier la profondeur des DLQ

Cinq outils. Pour un seul broker. Chacun nécessitant configuration, maintenance et quelqu’un sachant quel onglet regarder quand ça tourne mal.

Ce n’est pas une pile de monitoring. C’est de l’archéologie.

Ce que nous voulions à la place

Après l’incident, j’ai commencé à réfléchir à ce que serait un outil de monitoring RabbitMQ conçu spécifiquement pour répondre à « qu’est-ce qui ne va pas maintenant ? » plutôt que « voici toutes les métriques, bonne chance ».

Quelques éléments semblaient incontournables :

Le taux de changement, pas seulement la profondeur. Une file à 50 000 messages croissant à +500/s est un réveil à 3h du matin dans 90 minutes. La même file décroissant à -1 000/s est saine. La profondeur seule est un indicateur en retard. Il faut la vélocité pour savoir si on se dirige vers un incident ou si on s’en remet.

La santé des consommateurs comme signal de première classe. Pas seulement « combien de consommateurs sont connectés » mais « traitent-ils réellement ? » Un consommateur connecté mais n’acquittant pas est cassé. Cette distinction est invisible dans la plupart des outils de monitoring.

Un historique de file utilisable après incident. La rétention native de RabbitMQ est courte et peu précise. Ce dont j’avais besoin cette nuit-là, c’était un graphique de profondeur à résolution 5 minutes sur 7 jours — quelque chose qui montre exactement quand le backlog a commencé, pas seulement qu’il était actuellement large. Cette précision change la façon de scoper un incident : fuite lente ou chute soudaine ?

La capacité d’inspecter les messages sans les perturber. Cette nuit-là, je ne pouvais pas confirmer si les messages eux-mêmes étaient valides sans écrire un consommateur jetable. Il me fallait inspecter la file — lire les en-têtes, vérifier la structure du payload — sans consommer un seul message. Cette capacité seule aurait coupé 15 minutes de diagnostic.

Corrélation d’incident automatisée, pas de navigation manuelle entre onglets. Le diagnostic de quarante minutes n’était pas quarante minutes de réflexion intense. C’était quarante minutes à assembler un contexte qui existait déjà dans trois outils différents. Un outil qui corrèle les pics de profondeur de file, les chutes de consommateurs et les changements de taux de messages en une seule chronologie n’a rien de magique — il fait automatiquement la partie mécanique du diagnostic d’incident.

Des alertes sur les indicateurs avancés, pas seulement les indicateurs en retard. Une alerte qui se déclenche quand votre file atteint 500 000 messages confirme surtout que vous êtes déjà dans un incident. Une alerte qui se déclenche quand votre file croît plus vite que votre taux de vidange — quand vous avez cinq minutes de marge — est réellement utile.

Un résumé de santé quotidien livré dans votre boîte mail. Pas parce que je veux vérifier des tableaux de bord chaque matin, mais parce que les petites accumulations doivent être détectées avant de devenir des appels à 3h du matin. Un digest quotidien des profondeurs de file, des tendances de consommateurs et des anomalies des dernières 24 heures signifie qu’on n’entre jamais dans un incident sans contexte.

Zéro Prometheus requis. Pas parce que Prometheus est mauvais, mais monter une pile complète Prometheus + Grafana + Alertmanager juste pour surveiller un cluster RabbitMQ est un investissement significatif pour les équipes qui ne l’ont pas déjà.

Pourquoi nous l’avons construit plutôt que de patcher les outils existants

J’ai sérieusement examiné les options existantes. Il existe des templates de tableaux de bord Grafana pour RabbitMQ. Il existe des plateformes APM SaaS avec des intégrations RabbitMQ. Il existe des produits commerciaux de monitoring RabbitMQ.

Aucun n’était construit à partir du postulat que la chose la plus importante est : dites-moi ce qui ne va pas, pas seulement ce qui se passe.

Alors nous avons construit Qarote.

Qarote est un outil de monitoring RabbitMQ auto-hébergé qui se connecte directement à l’API HTTP de management — pas de plugin Prometheus, pas de YAML, pas d’agents à déployer. Noyau sous licence MIT, auto-hébergeable en deux minutes avec une seule commande Docker.

Voici à quoi cet incident aurait ressemblé avec Qarote en fonctionnement :

• Minute 1 : Drapeau consommateur-connecté-mais-n’acquittant-pas levé. Qarote interroge toutes les 15 secondes — pas de retard de 60 secondes.
• Minute 1 : Alerte sur le taux de croissance de la file déclenchée. Le backlog s’accélérait, pas seulement profond.
• Minute 2 : Le Moteur de Diagnostic d’Incident a corrélé le pic de backlog, la chute du taux d’acquittement des consommateurs et la pointe d’erreurs applicatives — même fenêtre de 4 minutes, automatiquement. Pas de navigation entre onglets.
• Minute 5 : Message Spy a confirmé que les messages dans la file bloquée étaient structurellement valides — payload intact, en-têtes corrects. Les messages n’étaient pas le problème. Les consommateurs l’étaient.
• Minute 5 : Réduit à DB ou réseau. Correctif déployé à la minute 10.

Dix minutes, pas quarante.

Et le lendemain matin, le Daily Digest aurait inclus l’incident dans le résumé d’anomalies des 24 heures — toute l’équipe aurait été informée avant d’ouvrir Slack, sans que personne n’ait à écrire un email de rétrospective.

Si cette même file avait accumulé lentement pendant des jours avant l’incident — une fuite lente plutôt qu’une chute soudaine — l’Historique de File l’aurait montré : des snapshots toutes les 5 minutes conservés 7 jours, traçables en regard du nombre de consommateurs et du taux de publication.

---

Si vous faites tourner RabbitMQ en production et que vous avez déjà regardé le plugin de management pendant un incident en vous demandant ce qui se passe vraiment, essayez-le. Le niveau gratuit couvre tout ce dont vous avez besoin pour commencer. La configuration prend environ deux minutes.

Si vous voulez l’héberger vous-même, le noyau est open source sur GitHub.