Comment surveiller l'état des nœuds RabbitMQ et les connexions avec `rabbitmqctl`
Cet article fournit un guide complet pour surveiller l'état des nœuds RabbitMQ et les connexions actives à l'aide de l'utilitaire en ligne de commande `rabbitmqctl`. Apprenez les commandes essentielles pour vérifier la santé du nœud, inspecter les connexions, les canaux et les consommateurs, et interpréter leurs résultats pour garantir le fonctionnement optimal et efficace de votre système de messagerie RabbitMQ.
Comment surveiller l'état des nœuds RabbitMQ et les connexions avec rabbitmqctl
RabbitMQ attire généralement l'attention seulement après qu'une file d'attente se soit accumulée, qu'un consommateur cesse d'accuser réception des messages, ou qu'un déploiement crée des centaines de connexions supplémentaires. rabbitmqctl reste l'un des moyens les plus rapides de vérifier ce que le broker voit depuis l'intérieur du nœud. Il ne remplacera pas Prometheus, l'interface de gestion ou la revue des logs, mais il vous offre une vue en ligne de commande fiable lorsque vous êtes sur un serveur et avez besoin de réponses rapidement.
Comprendre rabbitmqctl
Le script rabbitmqctl est l'interface en ligne de commande principale pour interagir avec un nœud RabbitMQ. Il permet aux administrateurs d'effectuer un large éventail de tâches, allant du démarrage et de l'arrêt du broker à la gestion des utilisateurs, des permissions, des échanges, des files d'attente et, crucialement pour cet article, de surveiller l'état opérationnel du nœud et son activité réseau.
Vérifier l'état du nœud RabbitMQ
Avant de plonger dans les connexions, il est essentiel de vérifier que votre nœud RabbitMQ est opérationnel. La commande status fournit un aperçu complet de l'état actuel du nœud.
La commande rabbitmqctl status
Cette commande affiche une multitude d'informations, notamment :
- Nom du nœud : Le nom du nœud RabbitMQ.
- Applications en cours d'exécution : Liste les applications Erlang en cours d'exécution, RabbitMQ lui-même étant un indicateur clé.
- Utilisation de la mémoire : Détails sur l'allocation et l'utilisation de la mémoire, essentiels pour le réglage des performances.
- Espace disque : Informations sur l'espace disque disponible, ce qui peut impacter la persistance des messages.
- Descripteurs de fichiers : Le nombre de descripteurs de fichiers ouverts, une ressource système importante.
- Informations réseau : Détails sur les interfaces réseau et les ports.
- Statut du cluster : Informations indiquant si le nœud fait partie d'un cluster et sa connectivité.
- Écouteurs : Ports sur lesquels RabbitMQ écoute pour divers protocoles (AMQP, interface de gestion, etc.).
Exemple d'utilisation :
rabbitmqctl status
Interprétation du résultat : Recherchez les signes d'épuisement des ressources (mémoire élevée, espace disque faible, utilisation élevée des descripteurs de fichiers) et confirmez que les applications essentielles comme rabbit sont en cours d'exécution. La section listeners est cruciale pour s'assurer que RabbitMQ est accessible sur les ports attendus.
Surveiller les connexions, les canaux et les consommateurs
Comprendre comment les clients interagissent avec votre nœud RabbitMQ est essentiel pour le dépannage et l'analyse des performances. rabbitmqctl fournit des commandes pour lister et inspecter ces entités.
Lister les connexions (rabbitmqctl list_connections)
Cette commande affiche toutes les connexions client actives au nœud RabbitMQ. Chaque connexion représente une application cliente (producteur ou consommateur) qui s'est connectée avec succès.
Commande :
rabbitmqctl list_connections
Colonnes du résultat (courantes) :
pid: L'identifiant du processus Erlang pour la connexion.node: Le nœud sur lequel la connexion est établie.name: Le nom de la connexion (reflète souvent les propriétés du client).port: Le port auquel le client s'est connecté.host: L'hôte à partir duquel le client s'est connecté.user: Le nom d'utilisateur utilisé pour l'authentification.vhost: L'hôte virtuel auquel la connexion est associée.ssl: Indique si la connexion utilise SSL/TLS.protocol: Le protocole utilisé (par exemple,amqp0-9-1).
Exemple :
rabbitmqctl list_connections name host port user vhost protocol
Cela vous permet de voir quels utilisateurs sont connectés, d'où, et quels hôtes virtuels ils utilisent.
Lister les canaux (rabbitmqctl list_channels)
Chaque connexion peut avoir plusieurs canaux. Les canaux sont des connexions légères et multiplexées sur une seule connexion TCP, utilisées pour les opérations AMQP.
Commande :
rabbitmqctl list_channels
Colonnes du résultat (courantes) :
connection: Lepidde la connexion parente.node: Le nœud sur lequel se trouve le canal.channel_pid: L'identifiant du processus Erlang pour le canal.vhost: L'hôte virtuel auquel le canal est associé.name: Le nom du canal (s'il est défini par le client).consumer_count: Le nombre de consommateurs actifs sur ce canal.messages_unacknowledged: Le nombre de messages non acquittés sur ce canal.messages_ready: Le nombre de messages prêts à être livrés sur ce canal.
Exemple :
rabbitmqctl list_channels connection vhost consumer_count messages_ready messages_unacknowledged
La surveillance de messages_unacknowledged et messages_ready est cruciale pour identifier les goulots d'étranglement potentiels où les consommateurs pourraient avoir du mal à suivre.
Lister les consommateurs (rabbitmqctl list_consumers)
Les consommateurs sont des processus qui s'abonnent aux files d'attente pour recevoir et traiter les messages.
Commande :
rabbitmqctl list_consumers
Colonnes du résultat (courantes) :
vhost: L'hôte virtuel dans lequel se trouve le consommateur.queue: Le nom de la file d'attente à laquelle le consommateur est attaché.consumer_tag: Un identifiant unique pour le consommateur (défini par le client).delivery_tag: Le tag de livraison du message en cours de traitement.redelivered: Indique si le message a été redistribué.message_count: Le nombre de messages en attente d'être livrés à ce consommateur.ack_required: Indique si les accusés de réception sont requis pour les messages livrés à ce consommateur.
Exemple :
rabbitmqctl list_consumers vhost queue consumer_tag message_count ack_required
Cette commande vous aide à comprendre quelles files d'attente ont des consommateurs actifs, combien de messages sont en attente de livraison pour eux, et si les accusés de réception sont correctement configurés.
Inspecter des composants spécifiques (arguments optionnels)
La plupart des commandes list_* acceptent des arguments pour spécifier les champs à afficher, rendant le résultat plus gérable. Vous pouvez également filtrer et trier le résultat à l'aide d'utilitaires shell standard comme grep et sort.
Exemple : Trouver les connexions d'un utilisateur spécifique :
rabbitmqctl list_connections | grep 'my_user'
Exemple : Afficher uniquement les canaux avec des messages non acquittés :
rabbitmqctl list_channels | awk '$4 > 0 { print }'
Meilleures pratiques pour la surveillance
- Vérifications régulières : Mettez en œuvre des vérifications régulières de
rabbitmqctl statuspour identifier les problèmes potentiels avant qu'ils n'impactent la production. - Automatisation : Envisagez d'automatiser ces vérifications à l'aide de scripts et de les intégrer à des systèmes de surveillance (par exemple, Prometheus, Nagios) pour une alerte proactive.
- Le contexte est essentiel : Comprenez les valeurs typiques de votre environnement. Un pic soudain de messages non acquittés ou une nouvelle connexion inattendue mérite une enquête.
- Combiner avec l'interface de gestion : Bien que
rabbitmqctlsoit puissant pour les scripts et l'accès direct, l'interface de gestion RabbitMQ offre un moyen visuel et interactif de surveiller les mêmes informations. - Surveillance des ressources : Corrélez toujours la sortie de
rabbitmqctlavec la surveillance des ressources au niveau du système (CPU, RAM, E/S disque) pour une image complète.
Un flux de triage utile lorsque les files d'attente s'accumulent
Lorsqu'une file d'attente commence à croître, ne commencez pas par redémarrer RabbitMQ. Un redémarrage peut ralentir la récupération et peut masquer les preuves dont vous avez besoin. Commencez par répondre à quatre questions.
Premièrement, le nœud est-il suffisamment sain pour servir les clients ?
rabbitmqctl status
Regardez les alarmes mémoire, les alarmes disque, l'utilisation des descripteurs de fichiers et les écouteurs. RabbitMQ dispose de mécanismes de sécurité pour la mémoire et l'espace disque libre. Si un nœud entre dans un état d'alarme, les éditeurs peuvent être bloqués. De l'extérieur, cela peut ressembler à un problème d'application, même si le broker se protège.
Deuxièmement, les consommateurs sont-ils connectés ?
rabbitmqctl list_consumers vhost queue consumer_tag ack_required active
Si une file d'attente n'a pas de consommateurs, la profondeur de la file d'attente n'est pas un problème de performance RabbitMQ. L'application qui devrait consommer de la file d'attente est en panne, mal configurée, connectée au mauvais hôte virtuel, ou consomme d'un nom de file d'attente différent de celui utilisé par l'éditeur.
Troisièmement, les consommateurs reçoivent-ils des messages mais ne les acquittent-ils pas ?
rabbitmqctl list_queues name messages_ready messages_unacknowledged consumers
messages_ready signifie que les messages attendent dans la file d'attente. messages_unacknowledged signifie que les messages ont été livrés aux consommateurs mais pas encore acquittés. Un nombre élevé de messages non acquittés indique souvent des gestionnaires lents, des appels de base de données longs dans les consommateurs, une valeur de prélecture trop élevée, ou des consommateurs qui ont planté après avoir reçu des messages.
Quatrièmement, y a-t-il trop de connexions ou de canaux ?
rabbitmqctl list_connections name user host state channels send_pend recv_cnt send_cnt
rabbitmqctl list_channels connection number consumer_count messages_unacknowledged prefetch_count
Les clients sains réutilisent généralement les connexions et ouvrent un nombre contrôlé de canaux. Si chaque requête ouvre une nouvelle connexion, le broker peut passer beaucoup de temps sur le renouvellement des connexions. Si une seule connexion a un très grand nombre de canaux, inspectez le comportement de la bibliothèque cliente et la taille du déploiement.
Interpréter les états de connexion
list_connections est plus utile lorsque vous demandez des colonnes spécifiques. Une commande compacte est plus facile à analyser lors d'un incident :
rabbitmqctl list_connections name user host state channels protocol ssl
La colonne state aide à séparer le trafic normal du comportement suspect. Une connexion à l'état running est active. Un grand nombre de connexions bloquées dans un état de contrôle de flux ou bloqué mérite une attention particulière. Si ssl est faux là où vous attendez TLS, vous avez peut-être des clients utilisant le mauvais écouteur ou une ancienne configuration.
Les noms des clients valent également la peine d'être définis dans le code de l'application. De nombreuses bibliothèques clientes RabbitMQ vous permettent de définir un nom de connexion. Sans cela, vous ne verrez peut-être que les détails de l'hôte et du port, ce qui rend plus difficile l'identification du service à l'origine de la charge. Un nom comme billing-worker-prod-3 est beaucoup plus utile qu'une connexion TCP anonyme.
Problèmes de canal et de prélecture
Les canaux sont peu coûteux par rapport aux connexions TCP, mais ils ne sont pas gratuits. Un problème courant en production est un processus de travail qui crée des canaux et ne les ferme jamais. Un autre est un consommateur avec une valeur de prélecture élevée qui reçoit de nombreux messages, les traite lentement et laisse les autres consommateurs inactifs.
Utilisez :
rabbitmqctl list_channels connection number consumer_count messages_unacknowledged prefetch_count
Si un canal a un nombre élevé de messages_unacknowledged, inspectez ce consommateur. Peut-être qu'il effectue des appels HTTP lents, attend un verrou de base de données, ou traite les messages un par un alors que la prélecture lui permet d'en réserver beaucoup plus. Baisser la prélecture peut améliorer l'équité, mais ce n'est pas un correctif de performance magique. Si les gestionnaires sont lents, vous devez toujours corriger le gestionnaire.
Vérifications des files d'attente qui doivent accompagner les vérifications de connexion
Bien que cet article se concentre sur l'état du nœud et les connexions, l'état de la file d'attente complète le tableau :
rabbitmqctl list_queues name durable auto_delete messages messages_ready messages_unacknowledged consumers memory state
Une file d'attente durable avec des messages persistants peut mettre la pression sur le disque. Une file d'attente avec consumers défini sur 0 nécessite une vérification de l'application. Une file d'attente avec de nombreux messages prêts et des consommateurs actifs indique un décalage de débit. Une file d'attente avec de nombreux messages non acquittés indique un problème de traitement ou de comportement d'acquittement côté consommateur.
Lorsque vous utilisez des filtres shell, faites attention aux positions des colonnes. Si vous modifiez les champs demandés, d'anciens extraits awk peuvent filtrer silencieusement la mauvaise colonne. Pour les vérifications reproductibles, préférez les scripts qui demandent des champs fixes et étiquettent leur sortie.
Notes sur le cluster
Dans un cluster, exécutez les commandes sur le nœud qui vous intéresse, ou spécifiez le nœud lorsque cela est pris en charge :
rabbitmqctl -n rabbit@node1 status
Vérifiez l'appartenance au cluster et les partitions :
rabbitmqctl cluster_status
Les partitions réseau et le désaccord entre les nœuds peuvent créer des symptômes déroutants : les clients se connectent avec succès à un nœud tandis que les files d'attente ou les métadonnées sont défectueuses ailleurs. Si un problème affecte une seule zone de disponibilité ou un seul hôte broker, comparez status, list_connections et list_queues sur les nœuds avant de modifier les paramètres à l'échelle du cluster.
Ce qu'il faut automatiser
Pour un petit environnement, quelques vérifications scriptées peuvent détecter les problèmes évidents : nœud down, alarme disque, alarme mémoire, aucun consommateur sur les files d'attente importantes, messages prêts au-dessus d'un seuil normal, messages non acquittés qui continuent d'augmenter, et nombre de connexions bien au-dessus de la ligne de base.
Pour les grands systèmes, utilisez le plugin Prometheus RabbitMQ ou un autre pipeline de métriques et gardez rabbitmqctl pour les investigations directes. Les alertes doivent être liées au comportement qui intéresse les utilisateurs. Une file d'attente qui augmente brièvement pendant un travail par lots peut être normale. Une file d'attente qui augmente pendant quinze minutes alors que les consommateurs sont connectés et que les messages non acquittés augmentent également est une meilleure page.
Habitudes opérationnelles qui font gagner du temps
Exécutez rabbitmqctl en tant qu'utilisateur OS correct ou via le compte de service attendu par votre installation. Les problèmes de permissions peuvent ressembler à des problèmes de broker lorsque vous êtes pressé. Si la commande ne peut pas contacter le nœud, vérifiez le nom du nœud, le cookie Erlang et si le service RabbitMQ est réellement en cours d'exécution sur cet hôte.
Gardez une petite liste des files d'attente importantes et de leurs consommateurs attendus. Lors d'un incident, "la file d'attente a zéro consommateur" n'est utile que si vous savez si cette file d'attente doit toujours avoir des consommateurs. Certaines files d'attente différées, de lettres mortes ou par lots sont censées rester inactives pendant de longues périodes.
Enfin, ne videz pas les files d'attente juste pour rendre les tableaux de bord verts. Vider une file d'attente est une perte de données à moins que les messages ne soient jetables par conception. Si les messages sont bloqués, déterminez d'abord s'ils sont en attente, non acquittés, rejetés, mis en lettres mortes ou bloqués par un consommateur manquant.
rabbitmqctl status, list_connections, list_channels, list_consumers et list_queues vous offrent un chemin pratique en ligne de commande de "les messages sont retardés" à une cause probable. L'astuce est de les lire ensemble : les ressources du nœud, les connexions client, le comportement des canaux, la présence des consommateurs et la profondeur des files d'attente racontent tous différentes parties de la même histoire.