RabbitMQ is the message broker that keeps distributed systems moving. It routes messages between producers and consumers, decouples services, and absorbs traffic spikes so your application does not collapse under load. When it works well, you do not notice it. When it fails, symptoms appear everywhere else first: API timeouts, orders that never complete, background jobs that pile up silently.
Monitoring RabbitMQ means collecting the right signals before those symptoms surface. That requires more than a single health check. You need to watch queue depth, consumer throughput, memory usage, disk alarms, and cluster state in combination. This guide explains exactly what RabbitMQ monitoring requires, which metrics matter and why, and how to act on what you see.
- Monitoring RabbitMQ is not optional: queue problems appear as application symptoms, not broker errors.
- The essential metrics are queue depth, message rates (publish/deliver/ack), unacknowledged messages, consumer count, memory, disk, and file descriptors.
-
Prometheus + Grafana is the recommended stack for production monitoring;
the
rabbitmq_prometheusplugin is built in from RabbitMQ 3.8 onward. - Set alerts on sustained queue growth, zero consumers, memory above 40% of the high watermark, and any disk free alarm.
- Dead-letter queues and cluster partition metrics are critical for data-integrity and high-availability scenarios.
- CubeAPM provides out-of-the-box RabbitMQ dashboards so you can skip the manual instrumentation.
Why Monitoring RabbitMQ Is Different From Monitoring a Database
A relational database either accepts a query or returns an error. The feedback loop is tight. RabbitMQ is asynchronous by design: a producer publishes a message and moves on. If the consumer never processes that message, the producer may never know. The failure is silent and cumulative.
This means problems in RabbitMQ rarely announce themselves. A consumer that is too slow to keep up will cause queue depth to grow steadily. Memory will creep toward the high watermark. Eventually the broker applies flow control and publishers start timing out. By that point you have lost significant time and possibly messages.
The official RabbitMQ documentation defines monitoring as capturing system behaviour through health checks and metrics over time, specifically to detect anomalies, support root cause analysis, and enable capacity planning. RabbitMQ monitoring therefore needs to be continuous, not reactive.
What Monitoring RabbitMQ Requires: The Core Components
Effective monitoring RabbitMQ covers four layers. Missing any one of them leaves blind spots.
1. Queue-Level Metrics
Queues are where messages wait. The state of your queues is the most immediate indicator of broker health.
- Queue depth (total messages): The total number of messages sitting in a queue. A queue that grows without bound is the earliest warning sign of a consumer problem. Datadog describes queue length as one of the most important RabbitMQ metrics to track (source: Datadog, Key metrics for RabbitMQ monitoring).
- Messages ready: Messages that have been routed to a queue and are available for delivery. A high and rising ready count means consumers are not picking up fast enough.
- Messages unacknowledged: Messages that have been delivered to a consumer but not yet confirmed as processed. A rising unacknowledged count usually means consumers are receiving messages but are too slow to finish processing them, or are crashing before they can send an ack.
- Dead-letter queue (DLQ) size: Messages that could not be processed and were routed to a DLQ. A non-zero DLQ is a signal to investigate — it means data was discarded from the normal flow.
2. Message Rate Metrics
Message rates tell you how fast data is flowing through the broker and whether supply and demand are balanced.
- Publish rate: Messages entering RabbitMQ from producers per second. A sudden drop can indicate a producer failure or upstream disruption.
- Deliver rate: Messages sent from RabbitMQ to consumers per second. If deliver rate is consistently lower than publish rate, queues will grow.
- Acknowledge rate: Messages confirmed as successfully processed per second. If this lags behind deliver rate, consumers are receiving but not finishing work.
- Redeliver rate: Messages that were returned to a queue because a consumer rejected or timed out on them. A rising redeliver rate points to consumer errors or misconfigurations.
3. Resource Metrics (Node Level)
RabbitMQ runs on the Erlang virtual machine and is sensitive to memory and file descriptor constraints. When resources are exhausted, the broker does not crash immediately. It throttles instead, which creates cascading latency across your system.
- Memory used: The amount of RAM consumed by the broker. RabbitMQ has a configurable vm_memory_high_watermark (default 40% of system RAM). Crossing it triggers a memory alarm and flow control begins.
- Disk free space: When free disk drops below disk_free_limit, RabbitMQ blocks all publishing connections to protect message durability.
- File descriptors used: RabbitMQ uses file descriptors for connections, channels, and persistent storage. Approaching the OS limit means new connections will be refused.
- Sockets used: A subset of file descriptors allocated specifically to network connections.
- CPU usage: High CPU on the node usually indicates either high message throughput, routing complexity, or issues with the Erlang scheduler.
- Erlang process count: RabbitMQ uses Erlang lightweight processes internally. Approaching the process limit (default 1,048,576) indicates the broker is under severe stress.
4. Cluster and Connectivity Metrics
If you run a multi-node RabbitMQ cluster, broker-level metrics are not enough. Cluster health requires its own set of checks.
- Cluster partitions: A network partition means nodes in the cluster cannot communicate. RabbitMQ can enter a split-brain state where each partition thinks it is the authority. Any detected partition should trigger an immediate alert.
- Quorum queue replication lag: For quorum queues (the recommended queue type for high availability), you need to monitor how far replica nodes have fallen behind the leader. A growing lag increases the risk of message loss if the leader fails.
- Node count and availability: A node going offline in a cluster is not always obvious from queue metrics alone. Track which nodes are up.
- Connection and channel counts: A sudden spike in connections or channels can indicate a connection storm, a bug in client code, or a deployment that failed to clean up old connections.
How to Enable Monitoring RabbitMQ in Practice
The Recommended Stack: Prometheus and Grafana
The official RabbitMQ team recommends Prometheus and Grafana as the primary monitoring stack for production clusters. From RabbitMQ 3.8 onward, the rabbitmq_prometheus plugin ships built in. Enabling it exposes a scrape endpoint at port 15692 in Prometheus text format.
To enable the plugin:
rabbitmq-plugins enable rabbitmq_prometheus
The team also provides pre-built Grafana dashboards for RabbitMQ that cover the overview, inter-node communication, and Raft metrics for quorum queues. These dashboards include colour-coded thresholds and graph conventions specifically designed to make anti-patterns visible at a glance.
Using the Management HTTP API
For development environments and quick inspections, the RabbitMQ management plugin exposes metrics via a REST API at http://localhost:15672/api/. You can query queue stats, node stats, and connection details without any additional tooling. This is not a substitute for long-term metric collection but is useful for ad-hoc troubleshooting.
Monitoring RabbitMQ on Kubernetes
If you run RabbitMQ on Kubernetes using the RabbitMQ Cluster Operator, the Prometheus plugin is automatically enabled. The operator also exposes ServiceMonitor resources that integrate directly with Prometheus Operator, reducing manual configuration.
Third-Party Monitoring Tools
Several commercial and open-source tools provide out-of-the-box RabbitMQ dashboards:
- Datadog: Integrates via the RabbitMQ check and surfaces queue, exchange, node, and connection metrics in its APM platform.
- Sematext: Provides a dedicated RabbitMQ monitoring integration with pre-built dashboards and anomaly detection.
- ManageEngine Applications Manager: Offers plugin-based RabbitMQ performance monitoring with alerting.
- Site24x7: Monitors file descriptors, memory, socket usage, and message rates through a lightweight agent plugin.
- CubeAPM: Provides full-stack observability including RabbitMQ metrics, traces, and logs in a single interface, without requiring multiple integrations.
Alerting Best Practices for Monitoring RabbitMQ
Collecting metrics without alerting on them is incomplete. The following alert conditions cover the most impactful failure scenarios:
Queue-Level Alerts
- Alert when queue depth grows continuously for more than 5 minutes relative to its rolling baseline. A static threshold misses context; sustained growth is more meaningful than an absolute number.
- Alert immediately when consumer count on a queue drops to zero. A queue with messages and no consumers will accumulate indefinitely.
- Alert when the dead-letter queue receives new messages. DLQ growth always indicates failed processing that needs investigation.
- Alert when unacknowledged messages exceed a threshold appropriate for your consumer processing time and prefetch count.
Resource Alerts
- Alert when memory usage exceeds 40% of the vm_memory_high_watermark to give time to act before flow control engages.
- Alert when disk free space drops below 150% of the disk_free_limit as an early warning before the disk alarm fires.
- Alert when file descriptors or sockets exceed 80% of the configured system limit.
Cluster Alerts
- Alert on any detected cluster partition immediately. This is a P1 condition.
- Alert if a node leaves the cluster unexpectedly.
- Alert when quorum queue replication lag grows beyond your recovery time objective for message loss.
Application-Level Monitoring: The Layer Most Teams Miss
RabbitMQ metrics tell you how the broker is behaving. They do not tell you whether your application is correctly publishing to and consuming from it. Application-level monitoring fills this gap.
- End-to-end message latency: The time from when a producer publishes a message to when a consumer processes it. A rise in this metric may indicate consumer slowness that queue depth alone does not fully explain.
- Consumer processing errors: Track the rate at which your consumers throw exceptions or fail to process messages. These errors become DLQ entries or redeliveries, which then appear in your broker metrics.
- Publisher confirms: RabbitMQ supports publisher confirms, which acknowledge that the broker received and persisted a message. If confirms stop arriving, your producer should surface this as an error.
The official RabbitMQ documentation notes that application-level metrics are the responsibility of the application, not the broker. Libraries like RabbitMQ Java client and amqplib for Node.js expose counters and events that you can instrument and forward to your monitoring stack.
Common RabbitMQ Monitoring Mistakes to Avoid
The management UI shows current state, not historical trends. You cannot spot gradual queue growth or memory drift from a point-in-time view
A queue depth of 10,000 is fine for a batch processing queue and alarming for a real-time payment queue. Thresholds need to reflect your specific workload.
Teams often watch queue depth and miss the unacknowledged count, which reveals stuck consumers that depth alone can obscure.
DLQs accumulate silently. Without a dedicated alert, messages fail and are never recovered.
RabbitMQ metrics can change significantly within seconds during traffic spikes. A 60-second scrape interval misses important transient events. The RabbitMQ team recommends scraping every 15 seconds for production systems.
A single-node metric dashboard does not reveal split-brain conditions or replica lag. Add cluster-level checks explicitly.
Monitoring RabbitMQ with Prometheus and Grafana: Quick Setup
If you are starting from scratch, here is the minimal path to a working monitoring setup:
- Enable the rabbitmq_prometheus plugin on all nodes.
- Add a Prometheus scrape job pointing to port 15692 on each node with a 15-second interval.
- Import the official RabbitMQ Grafana dashboards from the RabbitMQ GitHub repository or Grafana dashboard library.
- Configure Grafana alerts on the queue depth, consumer count, memory usage, and partition count panels.
- Route alerts to your on-call channel (PagerDuty, Slack, or equivalent).
FAQs
1. What is the most important metric when monitoring RabbitMQ?
Queue depth, specifically sustained queue growth, is the single most important signal. A queue that grows continuously means consumers cannot keep up with producers, and left unaddressed it leads to memory alarms, flow control, and eventual publisher failures.
2. How often should I scrape RabbitMQ metrics?
The RabbitMQ team recommends every 15 seconds for production systems. Scraping every 60 seconds is too coarse to catch short spikes in queue depth or memory usage.
3. What is the difference between messages ready and messages unacknowledged?
Messages ready are waiting to be delivered to a consumer. Messages unacknowledged have been delivered but the consumer has not confirmed processing. A high unacknowledged count with a low ready count means consumers are receiving work but are slow to complete it.
4. When should I use the management API versus Prometheus for monitoring RabbitMQ?
Use the management HTTP API for development, debugging, and ad-hoc checks. Use Prometheus with Grafana for production monitoring. The management API is not designed for long-term metric storage or alerting.
5. What does the memory alarm in RabbitMQ mean?
When memory usage crosses vm_memory_high_watermark (default 40% of system RAM), RabbitMQ triggers a memory alarm and applies flow control to all publishing connections. Publishers will block. The alarm clears when memory drops back below the threshold. You should alert before this point to give yourself time to act.
6. How do I monitor a RabbitMQ cluster versus a single node?
For clusters, add partition metrics, quorum queue replica lag, and per-node memory and disk metrics to your standard queue and message rate dashboards. The rabbitmq_prometheus plugin exposes both per-node and cluster-wide metrics in its scrape endpoint.