Curso de Administración de RabbitMQ para Equipos de Infraestructura

Instalar RabbitMQ en laboratorio mediante paquetes del sistema, contenedores o imágenes oficiales, entendiendo diferencias de mantenimiento y actualización.

Preparar una configuración base con hostname estable, puertos necesarios, directorios de datos, logs, plugins mínimos y usuario administrador controlado.

Diferenciar despliegues locales, servidores dedicados, contenedores, máquinas virtuales, cloud y Kubernetes según objetivo operativo.

Configurar variables de entorno, ficheros de configuración, parámetros runtime y convenciones de nombres para entornos corporativos.

Validar arranque del nodo, estado del broker, listeners activos, memoria disponible, uso de disco y conectividad inicial.

Evitar instalaciones “rápidas” con usuario invitado, credenciales por defecto, management expuesto y sin política de backup.

Diseñar separación entre desarrollo, integración, preproducción y producción mediante vhosts, clústeres o entornos independientes.

Crear procedimientos de parada, arranque, reinicio, actualización y rollback con ventanas de mantenimiento y comunicación previa.

Documentar versión, plugins, configuración, usuarios administrativos, puertos, certificados, límites y rutas de datos.

Construir una instalación reproducible de RabbitMQ con Docker Compose, configuración externa y comprobaciones de salud.

Comprender AMQP desde la administración: cómo productores publican en exchanges y cómo los mensajes llegan a colas mediante bindings.

Diferenciar exchange direct, topic, fanout y headers, identificando cuándo aporta valor cada tipo en procesos reales.

Diseñar routing keys con convenciones legibles, evitando nombres improvisados que dificultan soporte, trazabilidad y evolución.

Crear colas con propiedades coherentes: durable, exclusive, auto-delete, tipo de cola, argumentos, TTL y dead lettering.

Entender que una queue es una colección ordenada de mensajes y que el comportamiento real depende de consumidores, acks, prioridad y políticas.

Evitar publicar directamente en colas cuando una topología basada en exchanges simplifica crecimiento, auditoría y cambios futuros.

Analizar bindings como contratos operativos que deben documentarse, versionarse y revisarse cuando cambian aplicaciones.

Diseñar topologías para punto a punto, publish/subscribe, routing selectivo, procesamiento por tipo de evento y fan-out controlado.

Probar rutas de mensajes con productores y consumidores de laboratorio, confirmando que los mensajes llegan al destino esperado.

Construir un diagrama de exchanges, queues, bindings y routing keys para un proceso empresarial con varios consumidores.

Diseñar virtual hosts como fronteras administrativas para separar aplicaciones, entornos, equipos, dominios funcionales o clientes internos.

Crear usuarios técnicos por aplicación, evitando cuentas compartidas que impiden trazabilidad y aumentan riesgo operativo.

Asignar permisos configure, write y read de forma mínima, ajustados al exchange, cola o patrón de recursos necesario.

Separar usuarios administradores, operadores, aplicaciones productoras, aplicaciones consumidoras, monitorización y herramientas de soporte.

Evitar conceder permisos amplios sobre `.*` por comodidad si la aplicación solo debe acceder a una parte de la topología.

Definir convención de nombres para usuarios, vhosts, exchanges, queues, bindings y recursos administrados por plataforma.

Usar tags de usuario con criterio, diferenciando administración completa, monitorización, gestión limitada y acceso de solo lectura.

Auditar periódicamente usuarios sin uso, permisos excesivos, contraseñas antiguas, cuentas temporales y vhosts abandonados.

Documentar matriz de accesos por aplicación, entorno, owner, permisos, fecha de revisión y justificación.

Construir un modelo multiaplicación con varios vhosts, usuarios mínimos, permisos restringidos y pruebas de acceso negativas.

Usar políticas para aplicar configuración transversal a colas y exchanges sin modificar individualmente cada recurso.

Configurar TTL de mensajes o colas para evitar acumulaciones indefinidas cuando los mensajes pierden valor con el tiempo.

Diseñar dead-letter exchanges para capturar mensajes expirados, rechazados o no procesables sin perder trazabilidad.

Construir estrategias de retry con colas intermedias, TTL, reencaminamiento y límites para evitar bucles infinitos.

Evitar que una cola de errores se convierta en un vertedero sin owner, sin alertas, sin limpieza y sin análisis de causa raíz.

Aplicar políticas de longitud máxima, overflow, lazy behaviour cuando proceda y límites de recursos según criticidad del flujo.

Diferenciar argumento declarado por aplicación y política aplicada por administración, evitando conflictos silenciosos de configuración.

Documentar cada política con patrón, recursos afectados, prioridad, finalidad, owner, fecha de revisión e impacto esperado.

Probar el comportamiento de TTL, DLX, retry y rechazo de mensajes con consumidores de laboratorio.

Construir un circuito completo de mensaje fallido: publicación, consumo, rechazo, reintento, DLQ, análisis y remediación.

Diferenciar classic queues, quorum queues y streams según necesidad de latencia, durabilidad, replicación, throughput, relectura y disponibilidad.

Entender quorum queues como tipo moderno de cola replicada y orientada a seguridad de datos, basado en el algoritmo Raft.

Evitar diseños nuevos basados en classic mirrored queues, ya que RabbitMQ documenta su deprecación y retirada en 4.x.

Usar classic queues cuando el caso requiere comportamiento sencillo, baja complejidad, colas no replicadas o cargas no críticas.

Elegir quorum queues para cargas duraderas donde importan consistencia, replicación, tolerancia a fallo de nodo y recuperación ordenada.

Evaluar streams cuando se necesita almacenamiento append-only, retención temporal, consumidores que leen desde offset y alto throughput.

Analizar implicaciones de cada tipo de cola en disco, memoria, replicación, mantenimiento, monitorización y comportamiento ante caída.

Diseñar políticas de tipo de cola por patrón de nombre para evitar que cada equipo declare recursos de forma incoherente.

Medir rendimiento y latencia de classic, quorum y stream en un laboratorio con distintos tamaños de mensaje y consumidores.

Construir una matriz de decisión para elegir tipo de cola por caso de uso, criticidad, volumen, durabilidad y patrón de consumo.

Comprender el ciclo completo de entrega fiable: publicación, confirmación del broker, encolado, entrega, ack del consumidor y eliminación segura.

Diferenciar publisher confirms, consumer acknowledgements, redeliveries, nacks, rejects y requeue desde una perspectiva operativa.

Configurar prefetch para evitar que un consumidor lento reciba demasiados mensajes y bloquee trabajo en memoria sin procesarlo.

Diseñar consumidores idempotentes porque RabbitMQ puede redeliverar mensajes y las aplicaciones deben tolerar duplicados.

Evitar `auto-ack` en flujos críticos donde un fallo del consumidor después de recibir el mensaje puede provocar pérdida lógica.

Analizar back pressure cuando productores publican más rápido de lo que consumidores procesan y el broker empieza a acumular carga.

Diseñar límites de publicación, control de velocidad, colas intermedias, alertas y circuit breakers para evitar saturación.

Revisar mensajes unacked, ready, redelivered y publish/ack rates para diagnosticar cuellos de botella reales.

Coordinar decisiones de fiabilidad entre desarrollo y operaciones, porque muchas garantías dependen del cliente y no solo del broker.

Construir un laboratorio con consumidor lento, prefetch variable, ack manual, redelivery y medición de acumulación de mensajes.

Activar únicamente plugins necesarios, revisando impacto en superficie de ataque, consumo de recursos, puertos y mantenimiento.

Usar RabbitMQ Management Plugin para administración, monitorización, HTTP API, interfaz web y `rabbitmqadmin`.

Proteger el management plugin con TLS, usuarios mínimos, restricción de red, control de permisos y exposición limitada.

Usar HTTP API para consultar estados, exportar definiciones, automatizar revisiones y preparar operaciones reproducibles.

Gestionar definiciones de usuarios, vhosts, permisos, exchanges, queues, bindings, policies y parameters como configuración versionable.

Evitar cambios manuales en producción sin registrar qué se cambió, quién lo aprobó y cómo revertirlo.

Crear procedimientos para exportar e importar definitions en entornos de laboratorio, recuperación o despliegues controlados.

Revisar plugins habituales: management, prometheus, shovel, federation, MQTT, STOMP, stream y autenticación externa cuando aplica.

Documentar cada plugin activo con finalidad, owner, puertos, configuración, riesgos y plan de actualización.

Construir una administración declarativa con definitions versionadas, API de management y pruebas de importación.

Comprender un clúster RabbitMQ como agrupación lógica de nodos que comparten usuarios, vhosts, queues, streams, exchanges, bindings y estado distribuido.

Diseñar clústeres con número impar de nodos cuando se usan quorum queues, considerando tolerancia a fallos y disponibilidad de mayoría.

Preparar nodos con hostnames estables, resolución DNS correcta, cookie Erlang compartida, puertos abiertos y sincronización horaria.

Diferenciar escalado de conexiones, escalado de disponibilidad, escalado de almacenamiento y escalado de throughput, porque no se resuelven igual.

Evitar asumir que añadir nodos siempre mejora rendimiento si las colas, conexiones y consumidores no están distribuidos adecuadamente.

Analizar particiones de red, comportamiento del clúster, recuperación, riesgo de split-brain y políticas de manejo de particiones.

Planificar altas y bajas de nodos, reinicios rolling, mantenimiento, reemplazo de hosts y recuperación de nodos perdidos.

Documentar topología de clúster, puertos, roles de nodos, tipos de colas, owners, dependencias y procedimientos de emergencia.

Validar estado del clúster con CLI, management UI, métricas y pruebas de failover controladas.

Construir un clúster de tres nodos en laboratorio con quorum queues, caída de nodo, recuperación y verificación de disponibilidad.

Diseñar alta disponibilidad con quorum queues, clientes resilientes, balanceadores, DNS, health checks y reconexión controlada.

Diferenciar clustering, federation y shovel: no resuelven el mismo problema ni deben usarse como sinónimos de alta disponibilidad.

Usar Federation para conectar brokers de forma flexible entre ubicaciones o dominios cuando no se quiere un clúster único.

Usar Shovel para mover mensajes entre brokers o vhosts de forma controlada, temporal o permanente, según caso operativo.

Evitar clústeres extendidos entre centros de datos con latencia alta si comprometen estabilidad, replicación y mantenimiento.

Diseñar balanceo de conexiones AMQP sin ocultar errores de conexión, reconexión agresiva o saturación de un nodo concreto.

Crear estrategias de backup y recuperación de definitions, datos críticos, certificados, configuración y procedimientos de reinstalación.

Diferenciar recuperación de configuración y recuperación de mensajes, ya que no siempre se protegen con el mismo mecanismo.

Probar recuperación ante desastre con pérdida de nodo, pérdida de definitions, cola no crítica, quorum degradado y reconstrucción.

Construir un escenario de continuidad con clúster local, definitions exportadas, Shovel o Federation de laboratorio y plan de recuperación.

Configurar TLS para cifrar tráfico cliente-broker, management UI, federation, shovel y conexiones entre componentes cuando proceda.

Gestionar certificados, CA interna, claves privadas, expiración, rotación, trust stores y validación de hostname.

Definir políticas de autenticación con usuarios internos, LDAP, OAuth 2.0 u otros backends según arquitectura corporativa.

Considerar OAuth 2.0 cuando la empresa necesita autenticación y autorización basada en tokens JWT para usuarios o aplicaciones.

Evitar exponer AMQP, MQTT, STOMP o management UI directamente a internet sin controles de red, TLS, WAF, VPN o segmentación.

Aplicar separación por vhost, usuarios por aplicación, permisos mínimos y rotación de credenciales.

Revisar logs de autenticación, intentos fallidos, conexiones sospechosas, permisos denegados y accesos administrativos.

Controlar plugins habilitados, puertos abiertos, cuentas temporales, usuarios huérfanos y certificados caducados.

Documentar política de seguridad RabbitMQ con roles, permisos, TLS, rotación, exposición, revisión y respuesta ante incidentes.

Construir un broker securizado con TLS, usuario por aplicación, vhost separado, permisos mínimos y management restringido.

Definir qué significa salud de RabbitMQ: nodos vivos, colas controladas, consumidores conectados, disco disponible, memoria estable y throughput coherente.

Usar Management Plugin para revisión operativa rápida, sin convertir la interfaz web en la única fuente de observabilidad.

Activar y configurar el plugin de Prometheus cuando se requiera integración con métricas corporativas y dashboards Grafana.

Monitorizar métricas clave: mensajes ready, unacked, publish rate, deliver rate, ack rate, consumers, connections, channels, memory y disk alarms.

Crear alertas accionables para colas creciendo, consumidores ausentes, DLQ con mensajes, memoria en alarma, disco bajo y nodo fuera de clúster.

Evitar alertas genéricas que solo dicen “RabbitMQ va mal” sin indicar cola, vhost, nodo, métrica, umbral y acción esperada.

Diseñar dashboards por audiencia: SRE, desarrollo, soporte, arquitectura, seguridad y responsables de servicio.

Correlacionar métricas del broker con logs de aplicaciones, latencia de consumidores, errores de red y despliegues recientes.

Documentar runbooks por alerta con causa probable, comprobaciones, comandos, propietario y escalado.

Construir un dashboard operativo con Prometheus y Grafana para clúster, nodos, colas, consumidores, DLQ y alarmas.

Analizar capacidad de RabbitMQ según tamaño de mensaje, tasa de publicación, tasa de consumo, tipo de cola, disco, memoria y red.

Diferenciar problema de broker, problema de consumidor, problema de productor, problema de disco, problema de red y mala topología.

Ajustar prefetch, número de consumidores, tamaño de mensaje, persistencia, batching y confirms sin romper garantías de entrega.

Revisar alarmas de memoria y disco como mecanismos de protección que pueden bloquear productores cuando el broker está bajo presión.

Evitar mensajes enormes si el patrón correcto sería almacenar payload grande fuera del broker y enviar una referencia controlada.

Diseñar límites por vhost, conexiones, canales, colas, longitud de cola y recursos para evitar que una aplicación afecte a todas.

Medir latencia y throughput con pruebas controladas antes de extrapolar comportamiento a producción.

Identificar colas calientes, consumidores lentos, publishers excesivos, bindings complejos y rutas que generan fan-out inesperado.

Documentar criterios de capacidad: mensajes por segundo, retención, crecimiento aceptable, número de consumidores y margen operativo.

Construir una prueba de carga controlada con métricas, cuellos de botella, ajuste de prefetch y análisis de resultados.

Desplegar RabbitMQ en contenedor entendiendo persistencia de datos, volúmenes, puertos, hostname, cookies, plugins y configuración externa.

Crear Docker Compose de laboratorio con broker, management, configuración, usuario no productivo, health check y volúmenes persistentes.

Evitar contenedores efímeros sin volumen en prácticas donde se espera conservar definitions, mensajes o configuración.

Desplegar RabbitMQ en Kubernetes considerando StatefulSets, storage, headless services, readiness, liveness, secrets y certificates.

Evaluar RabbitMQ Cluster Kubernetes Operator para gestionar clústeres en Kubernetes y operaciones de día dos.

Tener en cuenta que el operador requiere Kubernetes 1.19 o posterior y recomienda versiones más recientes para ciertos escenarios.

Integrar monitoring en Kubernetes con Prometheus, sabiendo que el operador puede desplegar clústeres con plugin Prometheus activado.

Gestionar upgrades rolling, cambios de configuración, escalado y estado de quorum con especial cuidado en entornos orquestados.

Documentar manifests, Helm values, secrets, storage classes, policies, resources, probes y estrategia de backup.

Construir un despliegue Kubernetes de laboratorio con RabbitMQ Operator, quorum queues, métricas Prometheus y prueba de failover.

Diagnosticar problemas de arranque revisando configuración, Erlang cookie, permisos, puertos, certificados, memoria, disco y logs del nodo.

Resolver incidencias de entrega comprobando exchange, routing key, binding, cola, consumidor, ack, permisos, DLX y política aplicada.

Investigar colas que crecen diferenciando ausencia de consumidor, consumidor lento, mensajes no confirmados, errores de aplicación o back pressure.

Revisar conexiones excesivas, canales filtrados, reconexiones agresivas, heartbeat fallido, timeouts y balanceadores mal configurados.

Preparar backups de definitions, configuración, certificados, políticas, usuarios, vhosts y documentación operativa.

Entender límites de la recuperación de mensajes según tipo de cola, durabilidad, persistencia, replicación y estado del almacenamiento.

Diseñar mantenimiento preventivo: actualización, revisión de permisos, limpieza de recursos huérfanos, rotación de certificados y pruebas de restauración.

Crear runbooks para disco lleno, memoria en alarma, nodo fuera de clúster, DLQ creciendo, certificado caducado y consumidores caídos.

Construir el proyecto final: clúster RabbitMQ seguro con vhosts, usuarios, políticas, quorum queues, DLX, monitoring, backups y despliegue Docker/Kubernetes.

Presentar la solución final con arquitectura, configuración, evidencias, dashboards, alertas, pruebas de fallo, plan de recuperación y recomendaciones operativas.