Operations — Cheat Sheet
RabbitMQ · 7 topics. Download the PDF or the Instagram carousel and share it.
RabbitMQ Management Plugin
The management plugin exposes an HTTP API and a browser UI at :15672 for inspecting exchanges, queues, bindings, connections, and consumer stats.
- ✓Management plugin UI is at :15672; HTTP API is at /api/* — both require authentication.
- ✓Never use guest/guest in production — delete the guest user and create dedicated accounts.
- ✓The HTTP API supports full CRUD on exchanges, queues, bindings and is scriptable via curl/HTTP clients.
- ✓rabbitmq_prometheus exposes /metrics at :15692 for Prometheus scraping.
- ✓Key metrics: queue depth (messages_ready), in-flight (messages_unacked), consumer utilisation.
- ✓Use the management API in CI/CD to declare test topology, publish test messages, and purge queues.
# Enable management plugin rabbitmq-plugins enable rabbitmq_management # Access UI # http://localhost:15672 # Default credentials: guest / guest (localhost only) # Create admin user for remote access rabbitmqctl add_user admin StrongPass! rabbitmqctl set_user_tags admin administrator rabbitmqctl set_permissions -p / admin ".*" ".*" ".*" # Delete default guest user in production rabbitmqctl delete_user guest # Enable HTTPS for management (recommended for production) # rabbitmq.conf: management.ssl.port = 15671 management.ssl.certfile = /etc/rabbitmq/certs/server_certificate.pem management.ssl.keyfile = /etc/rabbitmq/certs/server_key.pem management.ssl.cacertfile = /etc/rabbitmq/certs/ca_certificate.pem
RabbitMQ Clustering
Cluster nodes share metadata (exchanges, bindings, users) but not queue contents by default; quorum queues replicate content to a majority of nodes for durability.
- ✓Classic queue contents are NOT replicated in a cluster — only quorum queues replicate via Raft.
- ✓Classic mirrored queues are deprecated since 3.9; migrate to quorum queues for HA.
- ✓A 3-node cluster is the minimum for fault tolerance; a 2-node cluster provides no HA (both nodes required).
- ✓Erlang cookie must be identical on all nodes — it is the shared secret for inter-node authentication.
- ✓Quorum queues require (N/2 + 1) nodes online; a network partition that loses quorum makes the queue unavailable.
- ✓Use HAProxy or the official RabbitMQ Cluster Kubernetes Operator for production cluster management.
# Step 1: ensure the same Erlang cookie on all nodes # /var/lib/rabbitmq/.erlang.cookie (must be identical on all nodes) # On node1 (seed node): rabbitmq-server -detached # On node2: join node1 rabbitmq-server -detached rabbitmqctl stop_app rabbitmqctl reset # wipe any existing data rabbitmqctl join_cluster rabbit@node1 # join with full replication rabbitmqctl start_app # On node3: join node1 rabbitmq-server -detached rabbitmqctl stop_app rabbitmqctl reset rabbitmqctl join_cluster rabbit@node1 rabbitmqctl start_app # Verify cluster membership rabbitmqctl cluster_status # Disk nodes: rabbit@node1, rabbit@node2, rabbit@node3 # RAM nodes: metadata in memory only — never use for quorum queues # rabbitmqctl join_cluster rabbit@node1 --ram ← not recommended for HA # Kubernetes: use the RabbitMQ Cluster Operator (official) # kubectl apply -f "https://github.com/rabbitmq/cluster-operator/releases/latest/download/cluster-operator.yml"
High Availability
Use quorum queues for replicated durability in clusters; deploy behind a load balancer; use multiple nodes to tolerate single-node failures without message loss.
- ✓Quorum Queues (Raft-based) replace Classic Mirrored Queues for HA — more reliable and consistent.
- ✓A 3-node cluster tolerates 1 node failure; a 5-node cluster tolerates 2.
- ✓Deploy HAProxy or AWS NLB in front of brokers; configure Spring AMQP with all broker addresses.
- ✓Automatic connection recovery in amqp-client reconnects transparently after broker failover.
- ✓Publisher confirms detect messages lost during failover — use CORRELATED confirm mode.
- ✓Quorum queues require durable=true; they do not support non-durable or exclusive queues.
# Join nodes to a cluster (on node 2 and 3)
rabbitmqctl stop_app
rabbitmqctl join_cluster rabbit@node1
rabbitmqctl start_app
# Verify cluster status
rabbitmqctl cluster_status
# Declare a quorum queue (AMQP 0-9-1 args)
@Bean
public Queue orderQueue() {
return QueueBuilder.durable("orders.processing")
.quorum() // x-queue-type=quorum
.withArgument("x-quorum-initial-group-size", 3) // 3 replicas
.build();
}
// Quorum queue policy via rabbitmqctl
rabbitmqctl set_policy quorum-all ".*" \
'{"x-queue-type":"quorum","x-quorum-initial-group-size":3}' \
--apply-to queuesTLS & Authentication
Enable TLS for encrypted transport and client-certificate authentication; LDAP or OAuth2 backend plugins handle centralised user management beyond local user accounts.
- ✓AMQPS listens on port 5671 (TLS); AMQP on 5672 (plaintext) — disable plaintext in production.
- ✓ssl_options.verify=verify_peer + fail_if_no_peer_cert=true enables mutual TLS (mTLS).
- ✓Spring AMQP mTLS requires a KeyManagerFactory (client cert) and TrustManagerFactory (CA cert).
- ✓rabbitmq-auth-backend-oauth2 validates JWT tokens from any OIDC-compliant provider.
- ✓JWT scopes map to RabbitMQ read/write/configure permissions per vhost and resource pattern.
- ✓Use OAuth2 token auth for Kubernetes service accounts — no static passwords in secrets.
# rabbitmq.conf — enable TLS listeners.ssl.default = 5671 ssl_options.cacertfile = /etc/rabbitmq/certs/ca_certificate.pem ssl_options.certfile = /etc/rabbitmq/certs/server_certificate.pem ssl_options.keyfile = /etc/rabbitmq/certs/server_key.pem ssl_options.verify = verify_peer # verify client cert (mTLS) ssl_options.fail_if_no_peer_cert = true # require client cert # TLS version and cipher restrictions ssl_options.versions.1 = tlsv1.2 ssl_options.versions.2 = tlsv1.3 # Disable plaintext AMQP (optional — forces all traffic through TLS) listeners.tcp = none # Management plugin TLS management.ssl.port = 15671 management.ssl.cacertfile = /etc/rabbitmq/certs/ca_certificate.pem management.ssl.certfile = /etc/rabbitmq/certs/server_certificate.pem management.ssl.keyfile = /etc/rabbitmq/certs/server_key.pem
Permissions & Access Control
RabbitMQ permissions are per-vhost with configure, write, and read regexes per user; grant least-privilege access — separate produce-only and consume-only users.
- ✓Three permission regexes per user per vhost: configure (declare), write (publish), read (consume)
- ✓".*" = full access; "^$" = no access; use specific patterns for least privilege
- ✓Management tags (administrator, monitoring, management) control HTTP API / UI access
- ✓Guest user is localhost-only by default — delete or restrict it before exposing the broker
- ✓Create one service account per service with only the permissions that service needs
- ✓Combine user permissions with TLS mutual auth for defence-in-depth in production
# Create producer user — can only publish to order-related exchanges rabbitmqctl add_user order-producer StrongPass1! rabbitmqctl set_permissions -p /orders order-producer "^$" # configure: cannot declare anything "^orders\..*" # write: publish to exchanges matching orders.* "^$" # read: cannot consume # Create consumer user — can only consume from order queues rabbitmqctl add_user order-consumer StrongPass2! rabbitmqctl set_permissions -p /orders order-consumer "^$" # configure: no "^$" # write: no publishing "^orders\..*" # read: consume from queues matching orders.* # List current permissions rabbitmqctl list_permissions -p /orders
Monitoring & Alerting
Key metrics: queue depth, consumer count, unacknowledged messages, publish/deliver rates, and memory/disk alarms; export via prometheus exporter or HTTP API scraping.
- ✓Enable rabbitmq_prometheus plugin — it is built-in since 3.8 and far more efficient than polling the HTTP API.
- ✓The three most important metrics: queue depth (messages_ready), consumer count, and unacked message count.
- ✓A memory alarm blocks all publishers — alert immediately; a disk alarm blocks publishes too when free space drops below threshold.
- ✓High redeliver rate indicates poison messages cycling through; check your DLQ and consumer logs immediately.
- ✓Import the official RabbitMQ Grafana dashboard (ID 10991) for a complete operational overview out of the box.
- ✓Use Spring Boot Actuator /health to surface queue health in Kubernetes liveness/readiness probes.
# Enable plugins (rabbitmq-plugins or environment variable)
rabbitmq-plugins enable rabbitmq_prometheus rabbitmq_management
# rabbitmq.conf
## Prometheus scrape port
prometheus.tcp.port = 15692
# prometheus.yml scrape config
scrape_configs:
- job_name: rabbitmq
static_configs:
- targets: ['rabbitmq-host:15692']
metrics_path: /metrics
relabel_configs:
- source_labels: [__address__]
target_label: instance
# Key metrics exposed
# rabbitmq_queue_messages_ready — messages waiting to be delivered
# rabbitmq_queue_messages_unacked_total — delivered but not yet acked
# rabbitmq_queue_consumers — active consumer count
# rabbitmq_channel_publish_total — publish rate (use rate())
# rabbitmq_node_mem_used_bytes — broker memory usage
# rabbitmq_node_disk_free_bytes — free disk spaceRabbitMQ Performance Tuning
Tune prefetch count, connection/channel pooling, persistent vs transient messages, queue type selection, and OS TCP settings to maximise throughput and minimise latency.
- ✓Prefetch count = 1 ensures fair dispatch but limits throughput; start at 10–50 and tune based on consumer processing time
- ✓Persistent messages (delivery-mode=2) + durable queues survive restart but require disk writes — use for business-critical events
- ✓Transient messages on non-durable queues are 10–50x faster but lost on restart — acceptable for telemetry, not payments
- ✓Quorum queues are the recommended default for reliability (replicated, survives node failure); Stream queues for high-throughput replay
- ✓vm_memory_high_watermark=0.4 blocks producers when broker reaches 40% RAM — prevents OOM broker crashes
- ✓Channels are multiplexed over TCP connections — use CachingConnectionFactory channel cache instead of creating new connections
// Spring AMQP — configure prefetch count
@Bean
public SimpleRabbitListenerContainerFactory rabbitListenerContainerFactory(
ConnectionFactory connectionFactory) {
SimpleRabbitListenerContainerFactory factory =
new SimpleRabbitListenerContainerFactory();
factory.setConnectionFactory(connectionFactory);
// Prefetch: messages pre-fetched per consumer
factory.setPrefetchCount(10); // default 250 in Spring AMQP
// Concurrent consumers: multiple threads per container
factory.setConcurrentConsumers(3);
factory.setMaxConcurrentConsumers(10); // scale up under load
// Acknowledgement mode
factory.setAcknowledgeMode(AcknowledgeMode.MANUAL);
return factory;
}
// @RabbitListener automatically uses the factory
@RabbitListener(queues = "order.processing")
public void processOrder(OrderMessage msg, Channel channel,
@Header(AmqpHeaders.DELIVERY_TAG) long tag)
throws IOException {
try {
processOrder(msg);
channel.basicAck(tag, false);
} catch (Exception e) {
channel.basicNack(tag, false, true); // requeue
}
}