RabbitMQ doesn’t actually need Prometheus; Prometheus needs RabbitMQ to expose metrics in a way it can understand.
Here’s how you get Prometheus to scrape metrics from RabbitMQ, and why it’s not as simple as just pointing Prometheus at the RabbitMQ URL.
First, you need the RabbitMQ Prometheus Exporter. This is a separate service that runs alongside RabbitMQ, queries it for metrics, and then exposes those metrics on an HTTP endpoint that Prometheus can scrape. By default, this exporter runs on port 9419.
# Example of how to run the exporter (this is a conceptual example,
# actual deployment might involve Docker, systemd, etc.)
rabbitmq-prometheus-exporter --rabbitmq-host rabbitmq.example.com --rabbitmq-port 5672 --listen-port 9419
Once the exporter is running, you need to configure Prometheus to scrape it. This involves adding a new scrape job to your prometheus.yml configuration file.
scrape_configs:
- job_name: 'rabbitmq'
static_configs:
- targets: ['rabbitmq-exporter.example.com:9419']
This tells Prometheus to periodically make HTTP requests to http://rabbitmq-exporter.example.com:9419/metrics. The exporter then translates RabbitMQ’s internal metrics into Prometheus’s text-based exposition format.
But here’s the catch: RabbitMQ’s internal metrics are exposed via its Management Plugin, which uses an HTTP API. The Prometheus exporter itself needs to authenticate with and query this Management Plugin API. So, you need to ensure the Management Plugin is enabled on your RabbitMQ instance.
# Enable the Management Plugin
rabbitmq-plugins enable rabbitmq_management
The exporter will need credentials to access the Management Plugin API. You can provide these either via environment variables or command-line arguments to the exporter.
# Example using environment variables for exporter authentication
export RABBITMQ_USERNAME=guest
export RABBITMQ_PASSWORD=guest
rabbitmq-prometheus-exporter --rabbitmq-host rabbitmq.example.com --rabbitmq-port 5672 --listen-port 9419 --rabbitmq-user $RABBITMQ_USERNAME --rabbitmq-password $RABBITMQ_PASSWORD
The Prometheus exporter also has its own configuration for what metrics to collect. By default, it collects a comprehensive set. However, you might want to fine-tune this. The exporter’s configuration typically lives in a YAML file.
# exporter_config.yml
collectors:
enabled:
- exchange_queues
- queue_messages
- node_memory
- channel_details
- connection_details
- policy_details
- queue_details
- consumer_details
- message_rates
You’d then pass this config file to the exporter:
rabbitmq-prometheus-exporter --config-file exporter_config.yml --rabbitmq-host rabbitmq.example.com --rabbitmq-port 5672 --listen-port 9419
The real power comes from understanding which metrics are being exposed and how they map to RabbitMQ’s internal state. For example, rabbitmq_queue_messages_ready tells you how many messages are waiting in a queue, while rabbitmq_queue_messages_unacknowledged shows messages that have been delivered but not yet acknowledged by consumers.
When you look at the /metrics endpoint of the exporter, you’ll see metrics like:
# HELP rabbitmq_queue_messages_ready Number of messages ready to be delivered to consumers.
# TYPE rabbitmq_queue_messages_ready gauge
rabbitmq_queue_messages_ready{vhost="/",queue="my-queue"} 150
# HELP rabbitmq_queue_messages_unacknowledged Number of messages that have been delivered but not yet acknowledged.
# TYPE rabbitmq_queue_messages_unacknowledged gauge
rabbitmq_queue_messages_unacknowledged{vhost="/",queue="my-queue"} 25
# HELP rabbitmq_node_memory_used_bytes Memory used by the RabbitMQ node.
# TYPE rabbitmq_node_memory_used_bytes gauge
rabbitmq_node_memory_used_bytes{node="rabbit@my-rabbit-node"} 123456789
The common pitfall here is assuming the exporter magically knows how to talk to RabbitMQ. It’s an intermediary, and it relies on the RabbitMQ Management Plugin being active and accessible. Without it, the exporter will report errors, and Prometheus will see no metrics.
Another subtle point is network connectivity. The Prometheus exporter needs to be able to reach the RabbitMQ nodes on their AMQP port (default 5672) and the Management Plugin’s HTTP API port (default 15672). Prometheus, in turn, needs to reach the exporter on its listening port (default 9419). Firewall rules are often the silent killer here.
Finally, consider the permissions for the user the exporter uses to connect to RabbitMQ. This user needs at least read access to the vhosts and queues it’s monitoring. Insufficient permissions will lead to the exporter not seeing certain metrics, or even failing to connect.
Once you have Prometheus scraping the exporter, the next step is to set up alerting rules based on these metrics, for instance, to notify you when queue depths exceed a certain threshold.