Cheat SheetsRabbitMQOperations

Operations — Cheat Sheet

RabbitMQ · 7 topics. Download the PDF or the Instagram carousel and share it.

Cheat Sheet · AiCanCode.org
Operations
RabbitMQ7 topicsQuick revision reference
1

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.
Shell — enable management plugin and user setup
# 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
2

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.
Shell — manual cluster formation + K8s operator
# 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"
3

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.
Shell + Java — cluster join and quorum queue
# 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 queues
4

TLS & 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 — TLS configuration
# 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
5

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
Shell — least-privilege producer / consumer accounts
# 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
6

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.
YAML — Prometheus plugin + scrape config
# 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 space
7

RabbitMQ 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
Java — prefetch count and concurrent consumer configuration
// 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
    }
}
Learn this free with Aria, your AI tutor → AiCanCode.org/learn/rabbitmq