RabbitMQ Monitoring Metrics
Monitoring RabbitMQ means tracking the right metrics so you catch problems before they affect your application. A queue growing without bound, a consumer that stopped acknowledging, or a node running out of memory are all detectable early if you know which numbers to watch.
Where to Get Metrics
RabbitMQ exposes metrics through three channels:
- Management UI: Visual dashboard at
http://localhost:15672 - HTTP API: JSON endpoints at
http://localhost:15672/api/ - Prometheus plugin: Exposes metrics at
http://localhost:15692/metricsfor scraping by Prometheus and Grafana
Key Broker-Level Metrics
Memory Usage
RabbitMQ tracks how much RAM it uses. Three thresholds matter:
Green: below 40% of system RAM Yellow: 40%–60% (watermark warning – flow control starts) Red: above 60% (publishers are blocked)
When memory exceeds the high watermark, RabbitMQ blocks all publishing connections until memory drops. This protects the broker from crashing but stalls your producers. Monitor memory and add RAM or reduce queue depths before hitting the watermark.
Disk Free Space
RabbitMQ monitors available disk space. When free disk falls below 50 MB (default), it blocks publishers. Always keep at least 1–2 GB free on the disk holding RabbitMQ's data directory.
File Descriptors
Every TCP connection and every open file uses a file descriptor. Linux systems have a per-process limit (often 1024 by default). RabbitMQ needs this set to 65536 or higher in production. Monitor the ratio of used vs available file descriptors.
Erlang Processes
RabbitMQ uses Erlang lightweight processes internally. Each connection, channel, and queue runs in its own process. Monitor the process count — hitting the Erlang process limit causes the broker to refuse new connections.
Key Queue-Level Metrics
Messages Ready
The number of messages waiting in the queue for a consumer. A healthy queue has this number staying low or trending down. A steadily rising Ready count means consumers are not keeping up — add more consumer instances.
Messages Unacknowledged
Messages delivered to consumers but not yet acknowledged. A rising Unacked count indicates slow consumers, consumers stuck in processing, or crashed consumers that have not disconnected yet.
Healthy: Ready: 20 (normal backlog) Unacked: 3 (3 consumers actively working) Problem: Ready: 5000 (backlog growing fast) Unacked: 300 (consumers overwhelmed or stuck)
Message Rates
Three rates matter for each queue:
- Publish rate: Messages entering per second
- Deliver rate: Messages going out to consumers per second
- Ack rate: Messages acknowledged per second
A healthy queue has Deliver rate ≥ Publish rate. If Publish rate consistently exceeds Deliver rate, the queue grows without bound.
Queue Depth Trend
Track queue depth (total messages) over time. A flat line means consumers keep up. A rising slope means falling behind. A sharply rising queue is a sign of either a consumer failure or a traffic spike requiring more consumer instances.
Key Connection and Channel Metrics
Connection Count
Track the number of open AMQP connections. A sudden drop in connections usually means a deployment or network event. A connection count that never stops growing suggests a connection leak in your application (connections opened but never closed).
Channel Count per Connection
Each connection should have a small, stable number of channels. A channel count that keeps growing per connection is a channel leak — channels opened but never closed.
Node-Level Metrics
Metric What to watch ---------------------------------------------- Node uptime Check after restarts or deployments Running status Should be "running", never "stopped" Memory used Stay below 40% watermark Disk free Stay above 1 GB Fd used / available Used should be under 80% of limit Erlang proc used Should be well below the Erlang limit
Alerting Recommendations
Set alerts in your monitoring system for these conditions:
- Queue depth exceeds 10,000 messages for more than 5 minutes
- Unacked messages exceed 3× the number of consumers
- Memory usage exceeds 35% (warning before the 40% flow control kicks in)
- Disk free falls below 2 GB
- Any node shows status other than "running"
- Publish rate drops to zero unexpectedly
Using Prometheus and Grafana
Enable the Prometheus metrics plugin for production monitoring:
rabbitmq-plugins enable rabbitmq_prometheus
RabbitMQ now exposes metrics at http://localhost:15692/metrics in Prometheus format. Configure Prometheus to scrape this endpoint and build Grafana dashboards. The official RabbitMQ Grafana dashboard (ID 10991) is available on grafana.com and covers all key metrics out of the box.
HTTP API Monitoring Examples
# Get all queue stats curl -u guest:guest http://localhost:15672/api/queues # Get overview stats curl -u guest:guest http://localhost:15672/api/overview # Get node stats curl -u guest:guest http://localhost:15672/api/nodes
Summary
Monitor RabbitMQ at three levels: broker (memory, disk, file descriptors), queue (ready, unacked, message rates), and node (running status, uptime). A rising Ready count signals consumer lag. A rising Unacked count signals slow or stuck consumers. Memory above 40% triggers flow control. Use the Management UI for instant visibility, the HTTP API for custom scripts, and the Prometheus plugin with Grafana for production dashboards and alerting.