Cómo monitorear el estado del nodo y las conexiones de RabbitMQ usando rabbitmqctl

RabbitMQ suele recibir atención solo después de que una cola se acumula, un consumidor deja de confirmar mensajes o un despliegue crea cientos de conexiones adicionales. rabbitmqctl sigue siendo una de las formas más rápidas de verificar lo que el broker observa desde dentro del nodo. No reemplazará a Prometheus, la interfaz de administración o la revisión de registros, pero le brinda una vista confiable desde la línea de comandos cuando está en un servidor y necesita respuestas rápidamente.

Entendiendo rabbitmqctl

El script rabbitmqctl es la interfaz principal de línea de comandos para interactuar con un nodo de RabbitMQ. Permite a los administradores realizar una amplia gama de tareas, desde iniciar y detener el broker hasta gestionar usuarios, permisos, intercambios, colas y, crucialmente para este artículo, monitorear el estado operativo del nodo y su actividad de red.

Verificando el estado del nodo de RabbitMQ

Antes de profundizar en las conexiones, es esencial verificar que su nodo de RabbitMQ esté funcionando. El comando status proporciona una visión general completa del estado actual del nodo.

El comando rabbitmqctl status

Este comando genera una gran cantidad de información, que incluye:

• Nombre del nodo: El nombre del nodo de RabbitMQ.
• Aplicaciones en ejecución: Enumera las aplicaciones Erlang que se están ejecutando, siendo RabbitMQ en sí mismo un indicador clave.
• Uso de memoria: Detalles sobre la asignación y el uso de memoria, vitales para el ajuste de rendimiento.
• Espacio en disco: Información sobre el espacio disponible en disco, que puede afectar la persistencia de mensajes.
• Descriptores de archivo: El número de descriptores de archivo abiertos, un recurso importante del sistema.
• Información de red: Detalles sobre interfaces de red y puertos.
• Estado del clúster: Información sobre si el nodo forma parte de un clúster y su conectividad.
• Escuchas: Puertos en los que RabbitMQ está escuchando para varios protocolos (AMQP, interfaz de administración, etc.).

Ejemplo de uso:

rabbitmqctl status

Interpretando la salida: Busque signos de agotamiento de recursos (alta memoria, poco espacio en disco, alto uso de descriptores de archivo) y confirme que las aplicaciones esenciales como rabbit se estén ejecutando. La sección listeners es crucial para asegurarse de que RabbitMQ sea accesible en los puertos esperados.

Monitoreando conexiones, canales y consumidores

Comprender cómo los clientes interactúan con su nodo de RabbitMQ es clave para la resolución de problemas y el análisis de rendimiento. rabbitmqctl proporciona comandos para listar e inspeccionar estas entidades.

Listando conexiones (rabbitmqctl list_connections)

Este comando muestra todas las conexiones de clientes activas al nodo de RabbitMQ. Cada conexión representa una aplicación cliente (productor o consumidor) que se ha conectado exitosamente.

Comando:

rabbitmqctl list_connections

Columnas de salida (comunes):

• pid: El identificador del proceso Erlang para la conexión.
• node: El nodo en el que se establece la conexión.
• name: El nombre de la conexión (a menudo refleja las propiedades del cliente).
• port: El puerto al que se conectó el cliente.
• host: El host desde el que se conectó el cliente.
• user: El nombre de usuario utilizado para la autenticación.
• vhost: El host virtual asociado a la conexión.
• ssl: Indica si la conexión utiliza SSL/TLS.
• protocol: El protocolo utilizado (por ejemplo, amqp0-9-1).

Ejemplo:

rabbitmqctl list_connections name host port user vhost protocol

Esto le permite ver qué usuarios están conectados, desde dónde y qué hosts virtuales están utilizando.

Listando canales (rabbitmqctl list_channels)

Cada conexión puede tener múltiples canales. Los canales son conexiones ligeras y multiplexadas sobre una única conexión TCP, utilizadas para operaciones AMQP.

Comando:

rabbitmqctl list_channels

Columnas de salida (comunes):

• connection: El pid de la conexión padre.
• node: El nodo en el que se encuentra el canal.
• channel_pid: El identificador del proceso Erlang para el canal.
• vhost: El host virtual asociado al canal.
• name: El nombre del canal (si lo establece el cliente).
• consumer_count: El número de consumidores activos en este canal.
• messages_unacknowledged: El número de mensajes no confirmados en este canal.
• messages_ready: El número de mensajes listos para ser entregados en este canal.

Ejemplo:

rabbitmqctl list_channels connection vhost consumer_count messages_ready messages_unacknowledged

Monitorear messages_unacknowledged y messages_ready es crucial para identificar posibles cuellos de botella donde los consumidores podrían tener dificultades para mantenerse al día.

Listando consumidores (rabbitmqctl list_consumers)

Los consumidores son procesos que se suscriben a colas para recibir y procesar mensajes.

Comando:

rabbitmqctl list_consumers

Columnas de salida (comunes):

• vhost: El host virtual en el que se encuentra el consumidor.
• queue: El nombre de la cola a la que está adjunto el consumidor.
• consumer_tag: Un identificador único para el consumidor (establecido por el cliente).
• delivery_tag: La etiqueta de entrega del mensaje actual que se está procesando.
• redelivered: Si el mensaje ha sido reentregado.
• message_count: El número de mensajes esperando ser entregados a este consumidor.
• ack_required: Indica si se requieren confirmaciones para los mensajes entregados a este consumidor.

Ejemplo:

rabbitmqctl list_consumers vhost queue consumer_tag message_count ack_required

Este comando le ayuda a entender qué colas tienen consumidores activos, cuántos mensajes están pendientes de entrega y si las confirmaciones están configuradas correctamente.

Inspeccionando componentes específicos (argumentos opcionales)

La mayoría de los comandos list_* aceptan argumentos para especificar qué campos mostrar, haciendo la salida más manejable. También puede filtrar y ordenar la salida utilizando utilidades estándar del shell como grep y sort.

Ejemplo: Encontrar conexiones de un usuario específico:

rabbitmqctl list_connections | grep 'my_user'

Ejemplo: Mostrar solo las colas con mensajes no confirmados:

rabbitmqctl list_channels | awk '$4 > 0 { print }'

Mejores prácticas para el monitoreo

• Verificaciones regulares: Implemente verificaciones regulares de rabbitmqctl status para identificar posibles problemas antes de que afecten la producción.
• Automatización: Considere automatizar estas verificaciones usando scripts e integrándolas con sistemas de monitoreo (por ejemplo, Prometheus, Nagios) para alertas proactivas.
• El contexto es clave: Comprenda los valores típicos para su entorno. Un aumento repentino en mensajes no confirmados o una nueva conexión inesperada merecen investigación.
• Combine con la interfaz de administración: Si bien rabbitmqctl es potente para scripting y acceso directo, la interfaz de administración de RabbitMQ proporciona una forma visual e interactiva de monitorear la misma información.
• Monitoreo de recursos: Siempre correlacione la salida de rabbitmqctl con el monitoreo de recursos a nivel de sistema (CPU, RAM, E/S de disco) para obtener una imagen completa.

Un flujo de triaje útil cuando las colas se acumulan

Cuando una cola comienza a crecer, no comience reiniciando RabbitMQ. Un reinicio puede hacer que la recuperación sea más lenta y puede ocultar la evidencia que necesita. Comience respondiendo cuatro preguntas.

Primero, ¿el nodo está lo suficientemente saludable para atender a los clientes?

rabbitmqctl status

Observe las alarmas de memoria, alarmas de disco, uso de descriptores de archivo y escuchas. RabbitMQ tiene mecanismos de seguridad de memoria y espacio libre en disco. Si un nodo entra en estado de alarma, los publicadores pueden ser bloqueados. Desde fuera, eso puede parecer un problema de la aplicación, aunque el broker se esté protegiendo a sí mismo.

Segundo, ¿hay consumidores conectados?

rabbitmqctl list_consumers vhost queue consumer_tag ack_required active

Si una cola no tiene consumidores, la profundidad de la cola no es un problema de rendimiento de RabbitMQ. La aplicación que debería consumir de la cola está caída, mal configurada, conectada al host virtual incorrecto o consumiendo de un nombre de cola diferente al que usa el publicador.

Tercero, ¿los consumidores están recibiendo mensajes pero no los están confirmando?

rabbitmqctl list_queues name messages_ready messages_unacknowledged consumers

messages_ready significa que los mensajes están esperando en la cola. messages_unacknowledged significa que los mensajes han sido entregados a los consumidores pero aún no se han confirmado. Un recuento alto de no confirmados a menudo apunta a manejadores lentos, llamadas largas a bases de datos dentro de los consumidores, un valor de prefetch demasiado alto o consumidores que se bloquearon después de recibir mensajes.

Cuarto, ¿hay demasiadas conexiones o canales?

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

Los clientes saludables generalmente reutilizan conexiones y abren un número controlado de canales. Si cada solicitud abre una nueva conexión, el broker puede pasar mucho tiempo en la rotación de conexiones. Si una sola conexión tiene un número muy grande de canales, inspeccione el comportamiento de la biblioteca del cliente y el tamaño del despliegue.

Interpretando los estados de conexión

list_connections es más útil cuando solicita columnas específicas. Un comando compacto es más fácil de escanear durante un incidente:

rabbitmqctl list_connections name user host state channels protocol ssl

La columna state ayuda a separar el tráfico normal del comportamiento sospechoso. Una conexión en estado running está activa. Una gran cantidad de conexiones atascadas en control de flujo o estados bloqueados merece atención. Si ssl es falso donde espera TLS, es posible que los clientes estén usando el listener incorrecto o una configuración antigua.

Los nombres de los clientes también vale la pena configurarlos en el código de la aplicación. Muchas bibliotecas de cliente de RabbitMQ le permiten establecer un nombre de conexión. Sin eso, es posible que solo vea detalles del host y el puerto, lo que dificulta identificar el servicio que causa la carga. Un nombre como billing-worker-prod-3 es mucho más útil que una conexión TCP anónima.

Problemas de canal y prefetch

Los canales son baratos en comparación con las conexiones TCP, pero no son gratuitos. Un problema común en producción es un proceso trabajador que crea canales y nunca los cierra. Otro es un consumidor con un valor de prefetch alto que recibe muchos mensajes, los procesa lentamente y deja a otros consumidores inactivos.

Use:

rabbitmqctl list_channels connection number consumer_count messages_unacknowledged prefetch_count

Si un canal tiene un gran recuento de messages_unacknowledged, inspeccione ese consumidor. Quizás está haciendo llamadas HTTP lentas, esperando un bloqueo de base de datos o procesando mensajes uno a la vez mientras el prefetch le permite reservar muchos más. Reducir el prefetch puede mejorar la equidad, pero no es una solución mágica de rendimiento. Si los manejadores son lentos, aún necesita arreglar el manejador.

Verificaciones de cola que deben estar junto a las verificaciones de conexión

Aunque este artículo se centra en el estado del nodo y las conexiones, el estado de la cola completa la imagen:

rabbitmqctl list_queues name durable auto_delete messages messages_ready messages_unacknowledged consumers memory state

Una cola duradera con mensajes persistentes puede ejercer presión sobre el disco. Una cola con consumers establecido en 0 necesita una verificación de la aplicación. Una cola con muchos mensajes listos y consumidores activos apunta a una discrepancia de rendimiento. Una cola con muchos mensajes no confirmados apunta a un comportamiento de procesamiento o confirmación del lado del consumidor.

Cuando use filtros de shell, tenga cuidado con las posiciones de las columnas. Si cambia los campos solicitados, los fragmentos antiguos de awk pueden filtrar silenciosamente la columna incorrecta. Para verificaciones repetibles, prefiera scripts que soliciten campos fijos y etiqueten su salida.

Notas sobre clústeres

En un clúster, ejecute comandos contra el nodo que le interesa, o especifique el nodo donde sea compatible:

rabbitmqctl -n rabbit@node1 status

Verifique la membresía del clúster y las particiones:

rabbitmqctl cluster_status

Las particiones de red y el desacuerdo entre nodos pueden crear síntomas confusos: los clientes se conectan exitosamente a un nodo mientras que las colas o los metadatos no son saludables en otro lugar. Si un problema afecta solo a una zona de disponibilidad o a un host del broker, compare status, list_connections y list_queues entre nodos antes de cambiar la configuración de todo el clúster.

Qué automatizar

Para un entorno pequeño, algunas verificaciones con scripts pueden detectar los problemas obvios: nodo caído, alarma de disco, alarma de memoria, sin consumidores en colas importantes, mensajes listos por encima de un umbral normal, mensajes no confirmados que siguen aumentando y un recuento de conexiones muy por encima de la línea base.

Para sistemas más grandes, use el plugin de Prometheus de RabbitMQ u otro pipeline de métricas y reserve rabbitmqctl para investigación directa. Las alertas deben estar vinculadas al comportamiento que les importa a los usuarios. Una cola que aumenta brevemente durante un trabajo por lotes puede ser normal. Una cola que aumenta durante quince minutos mientras los consumidores están conectados y los mensajes no confirmados también aumentan es una mejor página.

Hábitos operativos que ahorran tiempo

Ejecute rabbitmqctl como el usuario de OS correcto o a través de la cuenta de servicio que espera su instalación. Los problemas de permisos pueden parecer problemas del broker cuando tiene prisa. Si el comando no puede contactar al nodo, verifique el nombre del nodo, la cookie de Erlang y si el servicio de RabbitMQ se está ejecutando realmente en ese host.

Mantenga una pequeña lista de colas importantes y sus consumidores esperados. Durante un incidente, "la cola tiene cero consumidores" solo es útil si sabe si esa cola siempre debe tener consumidores. Se espera que algunas colas retrasadas, de mensajes muertos o por lotes estén inactivas durante largos períodos.

Finalmente, no limpie las colas solo para que los paneles se vean verdes. Purgar una cola es pérdida de datos a menos que los mensajes sean desechables por diseño. Si los mensajes están atascados, primero averigüe si están esperando, no confirmados, rechazados, enviados a mensajes muertos o bloqueados por un consumidor faltante.

rabbitmqctl status, list_connections, list_channels, list_consumers y list_queues le brindan un camino práctico desde la línea de comandos desde "los mensajes están retrasados" hasta una causa probable. El truco es leerlos juntos: los recursos del nodo, las conexiones de los clientes, el comportamiento de los canales, la presencia de consumidores y la profundidad de la cola cuentan diferentes partes de la misma historia.