Comprendre et résoudre efficacement les alarmes mémoire RabbitMQ

RabbitMQ, un courtier de messages puissant et polyvalent, joue un rôle critique dans les architectures d'applications modernes en facilitant la communication asynchrone. Cependant, comme tout logiciel gérant des ressources importantes, il peut rencontrer des problèmes. L'un des plus critiques et potentiellement perturbateurs est le déclenchement des alarmes mémoire. Ces alarmes sont conçues pour protéger le courtier RabbitMQ contre une saturation de la mémoire, ce qui pourrait entraîner une instabilité, une absence de réponse et une perte de données. Ce guide explorera les causes des alarmes mémoire RabbitMQ, comment les interpréter, et fournira des étapes pratiques et actionnables pour les résoudre et les prévenir, assurant ainsi le bon fonctionnement de votre infrastructure de messagerie.

Comprendre les alarmes mémoire est crucial pour maintenir un déploiement RabbitMQ sain. Lorsque l'utilisation de la mémoire de RabbitMQ dépasse des seuils prédéfinis, il entre dans un état 'critique', déclenchant des alarmes. Cet état peut entraîner diverses conséquences, notamment le blocage des éditeurs, l'empêchement de nouvelles connexions et, finalement, potentiellement un crash du courtier s'il n'est pas traité rapidement. Une surveillance proactive et un dépannage efficace sont essentiels pour atténuer ces risques.

Que sont les alarmes mémoire RabbitMQ ?

RabbitMQ utilise la mémoire pour mettre en mémoire tampon les messages, stocker l'état des canaux, gérer les connexions et contenir les structures de données internes. Pour empêcher le courtier de consommer toute la mémoire système disponible, ce qui pourrait entraîner un crash, RabbitMQ implémente des alarmes de seuil de mémoire. Ces alarmes sont configurées en fonction de la mémoire système totale disponible.

Le principal seuil avec lequel les opérateurs traitent est le seuil haut de mémoire. Lorsque l'utilisation de la mémoire de RabbitMQ atteint ce seuil, le nœud déclenche une alarme mémoire et commence à appliquer un contrôle de flux, le plus visiblement en bloquant les éditeurs. Les détails exacts peuvent varier selon la version de RabbitMQ et le type de file d'attente, donc traitez l'alarme comme un signal de contre-pression protectrice, et non comme une paire séparée "avertissement" et "critique" dans chaque installation.

Ces alarmes sont visibles dans l'interface de gestion RabbitMQ et peuvent être surveillées via son API HTTP ou des outils en ligne de commande.

Causes des alarmes mémoire RabbitMQ

Plusieurs facteurs peuvent contribuer à ce que RabbitMQ dépasse ses limites de mémoire et déclenche des alarmes. Comprendre ces causes profondes est la première étape vers une résolution efficace.

1. Accumulation de messages (messages non accusés)

C'est peut-être la cause la plus courante. Si les messages sont publiés dans des files d'attente plus rapidement qu'ils ne sont consommés, les messages s'accumuleront en mémoire. RabbitMQ conserve le contenu des messages en mémoire jusqu'à ce qu'il soit accusé par un consommateur. Des volumes élevés de messages non accusés, en particulier les plus gros, peuvent rapidement épuiser la mémoire disponible.

2. Charges utiles de messages volumineuses

La publication de messages très volumineux, même s'ils sont consommés rapidement, peut imposer une charge mémoire importante au courtier car il doit mettre ces messages en mémoire tampon. Bien que RabbitMQ soit conçu pour gérer différentes tailles de messages, des volumes constamment élevés de charges utiles exceptionnellement volumineuses peuvent submerger la mémoire disponible.

3. Fuites mémoire ou consommateurs inefficaces

Bien que moins courantes, les fuites mémoire dans les plugins personnalisés, la machine virtuelle Erlang elle-même, ou une logique de consommateur inefficace (par exemple, conserver les objets de message plus longtemps que nécessaire) peuvent contribuer à une croissance progressive de la mémoire.

4. Nombre élevé de canaux ou de connexions

Chaque connexion et chaque canal consomme une petite quantité de mémoire. Bien que généralement pas une cause principale d'alarmes en soi, un très grand nombre de connexions et de canaux, combiné à d'autres facteurs, peut s'ajouter à l'empreinte mémoire globale.

5. Configurations de files d'attente inefficaces

Certaines configurations de files d'attente, en particulier celles avec de nombreux messages paginés sur le disque ou celles utilisant des fonctionnalités nécessitant un état mémoire important, peuvent indirectement avoir un impact sur l'utilisation de la mémoire.

6. Mémoire système insuffisante

Parfois, l'explication la plus simple est que le serveur hébergeant RabbitMQ n'a tout simplement pas assez de RAM allouée pour sa charge de travail. Ceci est particulièrement pertinent dans les environnements virtualisés ou conteneurisés où les limites de ressources peuvent être plus strictes.

Surveillance des métriques clés pour l'utilisation de la mémoire

Une surveillance proactive est essentielle. RabbitMQ offre plusieurs façons d'inspecter son utilisation de la mémoire. Les plus courantes sont :

1. Interface de gestion RabbitMQ

L'interface de gestion offre un aperçu visuel de la santé du courtier. Accédez à l'onglet 'Aperçu', et vous verrez la section 'Santé du nœud'. Si des alarmes mémoire sont actives, elles seront affichées de manière proéminente avec un indicateur rouge.

2. Outils en ligne de commande (CLI)

RabbitMQ fournit la commande rabbitmqctl pour l'administration du système. Les commandes suivantes sont particulièrement utiles :

rabbitmqctl status : Cette commande fournit une mine d'informations sur le courtier, y compris l'utilisation de la mémoire. Recherchez les champs memory et mem_used.

rabbitmqctl status

Exemple d'extrait de sortie :

[...] 
node              : rabbit@localhost
core
  ...
memory
  total                     : 123456789 bytes
  heap_used                 : 98765432 bytes
  avg_heap_size             : 10000000 bytes
  processes_used            : 1234567 bytes
  ... 
...

rabbitmq-diagnostics memory_breakdown : Cette commande est souvent plus utile qu'un vidage d'environnement brut car elle regroupe l'utilisation de la mémoire par catégorie.
```
rabbitmq-diagnostics memory_breakdown
```

3. API HTTP

RabbitMQ expose une API HTTP complète qui vous permet d'interroger par programmation l'état du courtier, y compris l'utilisation de la mémoire.

Détails du nœud : GET /api/nodes/{node}
```
curl http://localhost:15672/api/nodes/rabbit@localhost
```
Recherchez des champs tels que mem_used, mem_limit et les informations d'alarme active dans la réponse. Les noms de champs peuvent varier selon les versions, alors vérifiez par rapport à la sortie de l'API RabbitMQ installée.
Alarmes mémoire : GET /api/overview Ce point de terminaison fournit un résumé de la santé du nœud, y compris l'état des alarmes.

Résolution des alarmes mémoire RabbitMQ

Une fois qu'une alarme mémoire est déclenchée, une action rapide est nécessaire pour restaurer le courtier à un état sain et éviter d'autres problèmes. Voici les étapes de résolution courantes :

1. Identifier la source de l'utilisation élevée de la mémoire

Examiner les profondeurs de file d'attente : Utilisez l'interface de gestion ou rabbitmqctl list_queues name messages_ready messages_unacknowledged pour identifier les files d'attente avec un grand nombre de messages, en particulier dans la colonne messages_unacknowledged.
```
rabbitmqctl list_queues name messages_ready messages_unacknowledged
```
Inspecter les tailles de messages : Si possible, étudiez la taille des messages dans les files d'attente problématiques. Cela peut nécessiter une surveillance personnalisée ou une journalisation au niveau du producteur/consommateur.
Vérifier l'activité des consommateurs : Assurez-vous que les consommateurs traitent activement les messages et les accusent rapidement. Recherchez les consommateurs qui pourraient être lents, bloqués ou arrêtés.

2. Réduire la charge mémoire

Augmenter le nombre de consommateurs : Le moyen le plus efficace de réduire l'accumulation de messages est d'augmenter le nombre de consommateurs traitant les messages des files d'attente concernées. Cela peut impliquer le déploiement de davantage d'instances de votre application consommateur.
Optimiser la logique des consommateurs : Examinez le code du consommateur pour détecter les inefficacités. Assurez-vous que les messages sont accusés dès qu'ils sont traités avec succès et évitez de conserver les objets de message plus longtemps que nécessaire.
Vider les files d'attente problématiques (avec prudence) : Si une file d'attente a accumulé un nombre ingérable de messages qui ne sont plus nécessaires, vous pouvez envisager de la vider. Cela peut être fait en purgeant la file d'attente à l'aide de l'interface de gestion ou de rabbitmqctl purge_queue <queue_name>. Avertissement : Cette action supprimera définitivement tous les messages de la file d'attente. Assurez-vous que cela est sûr pour l'intégrité des données de votre application.
```
rabbitmqctl purge_queue my_problematic_queue
```
Implémenter la mise en file d'attente des lettres mortes et TTL : Configurez des politiques pour la durée de vie (TTL) et les échanges de lettres mortes (DLX) afin d'expirer ou de déplacer automatiquement les messages qui sont dans une file d'attente depuis trop longtemps ou qui ne peuvent pas être traités. Cela empêche une accumulation indéfinie.

3. Ajuster la configuration RabbitMQ

Augmenter le seuil haut de mémoire avec précaution : Si le serveur ou le conteneur dispose réellement de RAM libre, vous pouvez augmenter le seuil haut de mémoire configuré. Dans la configuration moderne de RabbitMQ, cela est généralement défini dans rabbitmq.conf.
```
vm_memory_high_watermark.relative = 0.5
```
Certains déploiements plus anciens utilisent des fichiers d'environnement ou des formats de configuration hérités. Vérifiez votre version installée avant de modifier. L'augmentation du seuil peut faire gagner du temps, mais ne résout pas un consommateur bloqué, des charges utiles surdimensionnées ou une file d'attente illimitée.
Paramétrer les réglages de la machine virtuelle Erlang : Pour les utilisateurs avancés, le réglage du garbage collection et des paramètres mémoire de la machine virtuelle Erlang peut offrir des optimisations supplémentaires.

4. Augmenter les ressources système

Ajouter plus de RAM : La solution la plus simple, si possible, est d'augmenter la RAM physique disponible pour le serveur exécutant RabbitMQ.
Distribuer la charge : Envisagez de regrouper RabbitMQ sur plusieurs nœuds pour distribuer la charge et l'utilisation de la mémoire.

Prévention des futures alarmes mémoire

Prévenir les alarmes est toujours mieux que d'y réagir. Mettez en œuvre ces meilleures pratiques :

1. Surveillance robuste des consommateurs

Surveillez en continu le débit des consommateurs et les taux d'accusé de réception. Configurez des alertes pour les consommateurs lents ou ceux qui arrêtent le traitement.

2. Implémenter la limitation de débit

Si vous avez des pics imprévisibles dans la production de messages, envisagez d'implémenter une limitation de débit côté producteur ou d'utiliser les mécanismes de contrôle de flux de RabbitMQ pour éviter de submerger le courtier.

3. Audits réguliers des files d'attente

Examinez périodiquement les profondeurs des files d'attente et les taux de messages. Identifiez et traitez les files d'attente qui deviennent constamment volumineuses.

4. Gestion du cycle de vie des messages

Utilisez les politiques TTL et DLX pour garantir que les messages ne vivent pas éternellement dans les files d'attente inutilement.

5. Planification des ressources

Assurez-vous que vos nœuds RabbitMQ sont correctement provisionnés en RAM en fonction de votre charge de travail prévue. Tenez compte d'une marge pour les pics.

6. Procédures d'arrêt gracieux

Implémentez des procédures d'arrêt gracieux pour les applications publiant ou consommant des messages afin d'éviter de laisser trop de messages non accusés lors du redémarrage des services.

Ce que l'alarme signifie en pratique

Une alarme mémoire RabbitMQ n'est pas seulement un avertissement sur le tableau de bord. Elle modifie le comportement du courtier. Le courtier se protège en appliquant une contre-pression aux éditeurs afin que l'utilisation de la mémoire cesse d'augmenter. Du côté du producteur, cela peut ressembler à des publications lentes, des connexions bloquées, des confirmations retardées ou des threads d'application en attente à l'intérieur d'un appel de bibliothèque client.

Ce comportement est intentionnel. Si RabbitMQ acceptait les messages sans limite jusqu'à ce que le système d'exploitation tue le processus, le résultat serait pire. L'alarme est le courtier qui dit : "J'ai besoin que les consommateurs rattrapent leur retard, que les messages soient déplacés sur le disque, ou que les éditeurs ralentissent."

C'est pourquoi la première réaction ne devrait pas être "redémarrer RabbitMQ". Un redémarrage peut libérer temporairement de la mémoire, mais il peut également interrompre les consommateurs, déclencher une redistribution et laisser le même arriéré prêt à recréer le problème. Redémarrez uniquement lorsque vous comprenez le compromis ou lorsque le nœud est déjà suffisamment malsain pour qu'un redémarrage contrôlé soit la moins mauvaise option.

Trouvez la file d'attente avant de modifier le courtier

Les alarmes mémoire ont généralement une source visible. Commencez par la profondeur de la file d'attente et les messages non accusés :

rabbitmqctl list_queues name durable type messages_ready messages_unacknowledged consumers memory

La colonne memory peut ne pas être disponible dans toutes les versions ou peut se comporter différemment selon le type de file d'attente, mais lorsqu'elle est disponible, elle donne un indice utile. Vérifiez également les taux de messages :

rabbitmqctl list_queues name \
  message_stats.publish_details.rate \
  message_stats.deliver_get_details.rate \
  message_stats.ack_details.rate

Le modèle vous indique ce qui se passe :

messages_ready élevé et faible taux de livraison signifie que les consommateurs sont manquants, arrêtés ou trop lents ;
messages_unacknowledged élevé signifie que les consommateurs ont reçu des messages mais ne les accusent pas rapidement ;
taux de publication élevé et taux d'accusé de réception plus faible signifie que le système se remplit plus vite qu'il ne se vide ;
aucune croissance évidente de la file d'attente mais une mémoire élevée peut indiquer de nombreuses connexions, canaux, plugins ou messages en vol volumineux.

N'oubliez pas la propriété par vhost. Dans les clusters RabbitMQ partagés, la file d'attente d'une équipe peut déclencher des alarmes qui bloquent les éditeurs pour d'autres charges de travail sur le même nœud.

Les messages non accusés sont un problème différent

Une file d'attente avec de nombreux messages prêts signifie que le travail attend dans RabbitMQ. Une file d'attente avec de nombreux messages non accusés signifie que le travail est chez les consommateurs. Cette différence change la solution.

Si messages_unacknowledged est élevé, ajouter plus d'éditeurs ou modifier le TTL de la file d'attente n'aidera pas beaucoup. Regardez les consommateurs :

Sont-ils bloqués sur une base de données ou une API en aval ?
Un déploiement a-t-il introduit un bogue avant basic_ack ?
La pré-extraction est-elle trop élevée, permettant à quelques consommateurs de détenir trop de travail ?
Les consommateurs sont-ils vivants mais bloqués par une famine de threads ou un épuisement du pool de connexions ?

Réduire la pré-extraction peut réduire la quantité de mémoire immobilisée dans les livraisons en vol et rendre la distribution plus équitable. Cela ne rendra pas une logique métier lente rapide, mais cela peut empêcher un mauvais consommateur d'accaparer une grande partie de la file d'attente.

Pour un travailleur qui traite un message à la fois, une valeur de pré-extraction faible est souvent suffisante. Pour les travailleurs avec concurrence interne, choisissez une valeur qui correspond au parallélisme réel plutôt qu'à un nombre arbitrairement grand.

Charges utiles volumineuses et arriérés

Les messages volumineux rendent les alarmes mémoire plus probables car chaque message en vol ou mis en mémoire tampon a plus de poids. Si les messages incluent des images, des rapports, des documents ou des blobs JSON volumineux, RabbitMQ peut effectuer un travail mieux géré par un stockage d'objets.

Une refonte courante consiste à stocker la charge utile ailleurs et à envoyer une petite référence via RabbitMQ :

{
  "event": "report.ready",
  "report_id": "rpt_7782",
  "location": "s3://internal-reports/rpt_7782.json"
}

Cette conception nécessite toujours des règles de nettoyage et des contrôles d'accès, mais elle empêche un arriéré de file d'attente de devenir un problème de stockage de charge utile volumineuse.

Les arriérés nécessitent également une décision commerciale honnête. Si une file d'attente contient d'anciennes mises à jour de statut qui ne sont plus utiles, une politique TTL peut être appropriée. Si elle contient des commandes clients, la purger serait une perte de données. Le courtier ne peut pas décider cela à votre place.

Moyens sûrs de réduire la mémoire pendant un incident

Lorsque l'alarme est active, travaillez du moins destructeur au plus destructeur.

D'abord, restaurez les consommateurs. Si les consommateurs sont arrêtés, redémarrez-les. S'ils sont sous-provisionnés, ajoutez des répliques. S'ils sont bloqués sur un service en aval, corrigez ou contournez cette dépendance si le processus métier le permet.

Deuxièmement, ralentissez les producteurs. De nombreuses applications peuvent tolérer une limitation de débit temporaire mieux qu'une panne du courtier. Si les producteurs prennent en charge le backoff, activez-le ou réduisez le taux de publication.

Troisièmement, déplacez les mauvais messages hors du chemin principal. Si un message empoisonné provoque des échecs répétés des consommateurs, mettez-le en file d'attente de lettres mortes au lieu de le laisser bloquer la progression. Assurez-vous que la DLQ est surveillée.

Quatrièmement, purgez uniquement lorsque le propriétaire confirme que les données sont jetables. Exécutez :

rabbitmqctl purge_queue queue_name

seulement après avoir compris la conséquence. Pour les workflows d'audit, de paiement, de commande, d'inventaire et de sécurité, la purge n'est généralement pas une première réponse acceptable.

Cinquièmement, augmentez le seuil ou ajoutez de la mémoire si la charge de travail est légitime et que le nœud a de la marge. Dans les conteneurs, rappelez-vous que RabbitMQ peut voir la mémoire différemment selon la version et la prise en charge des cgroups. Définissez des limites de ressources explicites et testez comment le courtier les signale.

Files d'attente paresseuses, files d'attente de quorum et nuances de version

Certaines fonctionnalités RabbitMQ modifient le comportement de la mémoire. Les files d'attente classiques paresseuses ont été conçues pour conserver plus de messages sur le disque et réduire la pression mémoire pour les longs arriérés. Dans les versions plus récentes de RabbitMQ, le comportement et les valeurs par défaut des files d'attente ont évolué, et les files d'attente de quorum ont leur propre modèle de stockage et de réplication.

Le conseil sûr est de choisir le type de file d'attente en fonction de la charge de travail et de la version de RabbitMQ, puis de tester le comportement des arriérés sous une charge réaliste. Une file d'attente rapide avec 1 000 petits messages peut se comporter très différemment avec des millions de messages ou des charges utiles plus volumineuses. Ne migrez pas le type de file d'attente pendant un incident, sauf si vous connaissez déjà les étapes opérationnelles et les modes de défaillance.

Prévention qui fonctionne réellement

La meilleure prévention n'est pas un seuil unique plus grand. C'est un ensemble de limites qui correspondent à l'entreprise :

alertes par file d'attente sur les messages prêts et non accusés ;
alertes sur le blocage des éditeurs ;
tableaux de bord de latence des consommateurs ;
DLQ avec propriétaires et règles de conservation ;
politiques TTL pour les messages jetables ;
politiques de longueur maximale lorsque la suppression ou la mise en file d'attente de lettres mortes des anciens messages est acceptable ;
tests de charge qui incluent des pannes de consommateurs, pas seulement un débit de chemin heureux.

Pour chaque file d'attente importante, documentez ce qui devrait se produire lorsque les consommateurs sont hors service pendant 10 minutes, une heure ou un jour. Certaines files d'attente doivent absorber l'arriéré. Certaines doivent se débarrasser des anciens messages. Certaines doivent appeler un humain rapidement car les données sont trop importantes pour prendre du retard.

Vérification finale

Lorsqu'une alarme mémoire RabbitMQ se déclenche, ne la masquez pas en augmentant uniquement la limite. Trouvez la file d'attente, le client, la charge utile ou la défaillance du consommateur qui a poussé le nœud en contre-pression. La solution durable est généralement l'une des trois choses suivantes : drainer le travail plus rapidement, arrêter d'accepter plus de travail que le système ne peut en gérer, ou modifier le cycle de vie des messages qui ne devraient pas attendre éternellement.