Empieza con el contador de pestañas.
Estás en mitad de un incidente. La latencia de mensajes subió hace 45 minutos en tres brokers — uno por entorno, como todo el mundo los configura al principio. Abres el plugin de gestión en el broker 1, compruebas la profundidad de los queues, abres una nueva pestaña para el broker 2, compruebas otra vez, abres una tercera para el broker 3. Nada parece claramente roto ahora mismo, pero necesitas saber qué estaba pasando hace 45 minutos, cuando el pico realmente empezó.
El plugin de gestión no puede decírtelo. Te muestra el estado actual. Te muestra un sparkline de 10 minutos en la vista de detalle del queue si haces scroll. No te muestra qué pasó antes de que abrieras la pestaña.
Así que abres Datadog. O Grafana. O Prometheus. Y reconstruyes la línea de tiempo desde cuatro pantallas distintas, ninguna de las cuales fue diseñada para hablar con las otras.
Este es el patrón. El plugin de gestión es por donde todos empiezan con el monitoreo de RabbitMQ, y es genuinamente bueno en lo que hace — navegar exchanges y bindings, publicar mensajes de prueba, hacer health checks rápidos. Pero hay cinco límites que vas a tocar en producción, y todos aparecen en el peor momento posible.
Qarote pone la observabilidad multi-broker, las métricas históricas y las alertas en un solo lugar — sin necesidad de configurar Prometheus. Ver cómo funciona →
1. Sin vista multi-broker
El plugin de gestión es por nodo. Cada broker de RabbitMQ tiene su propia UI de gestión en :15672, y no hay forma de agregar datos entre brokers desde el propio plugin.
Para clusters, eso está bien — la UI de gestión en cualquier nodo muestra el cluster completo. Pero la mayoría de setups de producción acaban pareciéndose a esto: un broker de staging, uno de producción, y quizás un broker separado para un servicio específico. Ahora tienes tres UIs de gestión. Añade herramientas internas, integraciones con partners, o un broker separado para jobs async, y llegas a cinco.
Lo que cuesta: Cada incidente multi-broker se convierte en un ejercicio de malabarismo con pestañas. No puedes escribir una sola consulta que pregunte “¿cuáles de mis queues en todos los entornos tienen profundidad por encima de X?”. No puedes ver de un vistazo que el queue del event bus en el broker de integraciones lleva rato creciendo mientras el queue principal de producción está bien. Cambias de contexto constantemente, lo que ralentiza el diagnóstico exactamente cuando la velocidad importa.
El workaround honesto: Etiqueta tus brokers en Prometheus y escribe consultas que agreguen por la etiqueta job. Algo así:
# Profundidad de queue en todos los brokers, ordenada descendente
topk(10,
rabbitmq_queue_messages{job=~"rabbitmq-.*"}
)Funciona bien si ya has invertido en el stack de Prometheus + Grafana. También es un compromiso de infraestructura considerable — consulta Cómo configurar alertas de RabbitMQ que realmente se disparen para el setup completo.
Qarote trata el multi-broker como ciudadano de primera clase: añade tantas conexiones como brokers tengas y cada vista se agrega en todos ellos por defecto.
2. Sin métricas históricas más allá de la ventana de retención en memoria
Abre la UI de gestión y haz clic en cualquier queue. Verás un gráfico de “Message rates” con un sparkline que muestra los últimos 60 segundos aproximadamente por defecto. En el desplegable “Charts” puedes ampliar esa ventana — pero solo hasta donde los datos que RabbitMQ ha retenido en memoria lleguen.
Por defecto, esa ventana de retención es de 60 segundos. Puedes aumentarla configurando collect_statistics_interval y management.rates_mode en la configuración del broker, pero hay un límite duro: todo vive en memoria. Un broker de producción típico retiene unos 5–10 minutos de historial de métricas. Reinicia el broker y desaparece.
Lo que cuesta: El análisis post-incidente se convierte en arqueología. Algo fue mal a las 2:14 de la madrugada. Estás investigando a las 2:45. El plugin de gestión tiene 10 minutos de sparklines desde las 2:35 hasta las 2:45. La ventana donde las cosas realmente se rompieron ha desaparecido. Trabajas con logs, tasas de error de consumers de una herramienta APM externa, y lo que Prometheus scrapeó — si Prometheus estaba configurado y el scraper no se perdió esa ventana.
Esta limitación también hace que la planificación de capacidad sea prácticamente imposible desde dentro del plugin. No puedes responder “¿cómo es la profundidad de nuestros queues a las 9 de la mañana los lunes frente a los jueves?” sin un almacén de métricas externo.
El workaround honesto: Prometheus con el plugin de Prometheus de RabbitMQ (rabbitmq-plugins enable rabbitmq_prometheus) te da retención de métricas a largo plazo. Combínalo con Grafana para dashboards y podrás consultar tan atrás en el tiempo como quieras según tu política de retención.
# prometheus.yml — scrape de métricas de RabbitMQ
scrape_configs:
- job_name: rabbitmq
static_configs:
- targets: ["rabbitmq:15692"]
scrape_interval: 15sEl intervalo de scrape de 15 segundos importa. A 60 segundos te perderás los incidentes que se mueven rápido — un queue que se llena y se vacía en menos de un minuto no aparecerá de forma significativa. Consulta Cómo depurar un backlog en un queue de RabbitMQ para entender por qué la frecuencia de scrape es una variable de primer orden en el diagnóstico de backlogs.
3. Sin alertas
El plugin de gestión no tiene ningún mecanismo de alertas. Ninguno. Puedes ver que tu alarma de memoria se ha disparado en el overview — se pone en rojo — pero solo si ya estás mirando la UI. No hay forma de configurar el plugin de gestión para que te envíe una notificación cuando la profundidad de un queue cruza un umbral, cuando un consumer se cae, cuando el espacio libre en disco cae por debajo de un límite, o cuando las tasas de mensajes se disparan.
Esta es la brecha más importante. Todas las demás limitaciones te piden que uses una herramienta diferente para investigar. Esta te pide que uses una herramienta diferente para enterarte de que hay un problema.
Lo que cuesta: Te enteras de los problemas de los queues cuando los usuarios reportan errores. O cuando un servicio downstream empieza a tener timeouts. O cuando la DLQ que nadie puso en un dashboard ha acumulado 40.000 mensajes y alguien finalmente se da cuenta en la revisión semanal.
El coste de guardia también se multiplica. Sin alertas, la única manera de saber que tu broker tiene un problema es estar mirándolo. Nadie mira dashboards a las 3 de la madrugada.
El workaround honesto: Conecta el endpoint de Prometheus de RabbitMQ y configura reglas de Alertmanager. Las alertas core que todo setup de producción necesita:
groups:
- name: rabbitmq
rules:
# Alarma de memoria disparada
- alert: RabbitMQMemoryAlarm
expr: rabbitmq_alarms_memory_used_watermark == 1
for: 0m
labels:
severity: critical
annotations:
summary: "Memory alarm fired on {{ $labels.instance }}"
# Profundidad de queue alta
- alert: RabbitMQQueueDepthHigh
expr: rabbitmq_queue_messages > 10000
for: 5m
labels:
severity: warning
annotations:
summary: "Queue {{ $labels.queue }} has {{ $value }} messages"
# Contador de consumers cayó a cero
- alert: RabbitMQNoConsumers
expr: rabbitmq_queue_consumers == 0 and rabbitmq_queue_messages > 0
for: 2m
labels:
severity: critical
annotations:
summary: "Queue {{ $labels.queue }} has messages but no consumers"
# DLQ recibiendo mensajes
- alert: RabbitMQDLQGrowing
expr: |
rate(rabbitmq_queue_messages_published_total{
queue=~".*dlq.*|.*dead.*|.*failed.*"
}[5m]) > 0
for: 5m
labels:
severity: warning
annotations:
summary: "DLQ {{ $labels.queue }} receiving messages"Para el setup completo de alertas incluyendo routing, configuración de receptores y qué alertas se disparan primero en una cascada de incidente, consulta Cómo configurar alertas de RabbitMQ que realmente se disparen.
Qarote incluye estos tipos de alerta de serie — umbrales de profundidad de queue, caída del contador de consumers, alarmas de memoria y disco, crecimiento de DLQ — y los evalúa contra los datos en vivo de tu broker sin necesitar configurar Prometheus. Ver las funcionalidades de alertas →
4. Los permisos son todo-o-nada
El plugin de gestión tiene cuatro etiquetas de usuario: management, policymaker, monitoring y administrator. Eso es todo.
management da acceso a la UI. monitoring da la UI de gestión más estadísticas a nivel de nodo. policymaker da la capacidad de establecer políticas. administrator da todo.
No hay modelo de permisos que diga “este usuario puede ver todos los queues en el vhost payments pero nada en internal”. No hay una vista de solo lectura que exponga las tasas de mensajes sin exponer la capacidad de purgar un queue. No hay forma de dar a un ingeniero de guardia acceso al broker sin darle permiso para publicar mensajes a exchanges. Y no hay log de auditoría — cuando un queue se purga a las 2 de la madrugada, no hay registro de quién lo hizo.
Lo que cuesta: En la práctica, la mayoría de equipos acaban compartiendo un único login de monitoreo con acceso de etiqueta monitoring en toda la rotación de guardia. Esto significa sin responsabilidad individual, sin scoping de acceso, y sin forma de dar a tu equipo de ops una vista de solo lectura sin darles también la capacidad de modificar bindings si hacen clic donde no deben.
Los equipos más cautelosos bloquean la UI de gestión por completo y solo exponen dashboards de Grafana a los operadores — lo que resuelve el problema de permisos pero también elimina las capacidades de depuración interactiva que hacen útil la UI de gestión en primer lugar.
El workaround honesto: No hay una solución limpia dentro del propio plugin de gestión. El enfoque menos malo es usar vhosts separados por entorno o límite de servicio, con credenciales de usuario separadas que tengan acceso de etiqueta management limitado a vhosts específicos:
# Crear un usuario de monitoreo con scope de vhost
rabbitmqctl add_user payments-monitor <password>
rabbitmqctl set_user_tags payments-monitor monitoring
rabbitmqctl set_permissions -p /payments payments-monitor "^$" "^$" ".*"El comando set_permissions toma patrones de configure, write y read. Establecer configure y write a ^$ (no coincidir con nada) y read a .* (coincidir con todo) da a este usuario acceso de solo lectura al vhost /payments. Puede ver profundidades de queue y tasas de mensajes pero no puede publicar, purgar ni modificar nada.
Esto funciona pero no escala. Treinta servicios, cuatro entornos, tres niveles de acceso: estás gestionando una matriz de usuarios con scope de vhost sin herramientas para auditar quién tiene qué. RabbitMQ no tiene una UI nativa para esto — lo haces en rabbitmqctl o via la HTTP API.
5. Sin separación de workspace o equipo para setups multi-entorno
Relacionado con la limitación de permisos, pero distinto: el plugin de gestión no tiene concepto de workspaces, entornos ni equipos. Todo lo que puedes ver está determinado por tus credenciales de usuario. No hay forma de agrupar “broker de staging, queues de staging, exchanges de staging” en un entorno etiquetado entre el que tu equipo pueda cambiar con un clic.
En la práctica esto significa que tus desarrolladores se conectan a la UI de gestión de producción cuando necesitan comprobar algo. No porque quieran — porque no hay una forma ergonómica de separar “quiero ver staging” de “quiero ver producción” más allá de mantener perfiles de navegador separados con contraseñas guardadas distintas.
Lo que cuesta: Errores operativos. La publicación accidental a un exchange de producción que iba destinada a staging. El rabbitmqadmin purge queue que se ejecutó contra el vhost equivocado. No porque los ingenieros no sean cuidadosos — porque la herramienta no pone fricción entre producción y no-producción, y bajo la carga cognitiva de un incidente, la fricción es lo que previene los errores.
El workaround honesto: Carpetas de dashboards de Grafana separadas, etiquetadas por entorno. Convenciones de nomenclatura estrictas en queues y exchanges (prefijar todo con prod., staging., dev.). Marcadores del navegador. Ninguno de estos es una solución real — son sustitutos de fricción que funcionan hasta que no funcionan.
Algunos equipos ejecutan una segunda instancia de Grafana apuntando solo a las métricas de staging, manteniéndola completamente separada del stack de observabilidad de producción. Funciona y probablemente es el enfoque más defendible para equipos que ya han invertido mucho en el stack de Prometheus + Grafana. El coste operativo es mantener dos stacks.
Para equipos que evalúan desde cero: los workspaces de Qarote se mapean directamente a este problema — modelas tus brokers, entornos y acceso de equipo en un solo lugar, con permisos explícitos a nivel de workspace. Tu ingeniero de guardia no puede actuar accidentalmente sobre el broker de producción cuando cree que está mirando staging porque la UI hace la separación visible en todo momento.
Cuándo el plugin de gestión es suficiente
Para ser justos: la mayor parte del tiempo, y especialmente al principio, el plugin de gestión es suficiente.
Viene incluido con RabbitMQ. Carga al instante. Tiene un navegador de queues y exchanges excelente. La capacidad de publicar un mensaje de prueba en un exchange y rastrearlo a través de los bindings es invaluable para depurar configuraciones de routing. El CLI rabbitmqadmin que viene con él es una interfaz sólida para scripting.
Si tienes un solo broker, un equipo pequeño, y Prometheus ya corriendo, puedes cerrar la mayoría de estas brechas con reglas de Alertmanager y unos cuantos dashboards de Grafana. Las alertas de la sección 3 anterior son una base completa.
El plugin de gestión se convierte en un cuello de botella cuando tienes múltiples brokers, cuando la rotación de guardia implica que varios ingenieros necesitan acceso de observabilidad, cuando estás depurando incidentes entre entornos, o cuando necesitas métricas históricas que duren más de una ventana de memoria de 10 minutos.
tl;dr
El plugin de gestión de RabbitMQ te da un navegador de queues y una vista en tiempo real estrecha. En producción tiene cinco brechas duras: sin agregación multi-broker (cada broker es una pestaña separada), sin métricas históricas más allá de lo que cabe en la memoria del broker (por defecto: ~60 segundos), sin alertas (te enteras de los problemas cuando los usuarios te lo dicen), permisos todo-o-nada sin log de auditoría, y sin separación de workspace entre entornos. Existen workarounds para los cinco — Prometheus para métricas y alertas, usuarios con scope de vhost para acotar permisos, instancias de Grafana separadas para separar entornos — pero se acumulan. Un stack completo de monitoreo de producción construido con estas piezas tiene un overhead real de infraestructura y operacional. Para equipos que ya han invertido en Prometheus, ese overhead se absorbe en el trabajo existente. Para equipos que evalúan desde cero, es un compromiso significativo antes de haber visto tu primer incidente.
El plugin de gestión es donde empieza el monitoreo de RabbitMQ. Saber dónde termina antes de llegar a un incidente es el objetivo de este artículo.