What RabbitMQ Monitoring Tools Work with Prometheus and Grafana? 

The RabbitMQ team’s official recommendation for production monitoring is Prometheus combined with Grafana. The right tool to get RabbitMQ metrics into that stack depends on your RabbitMQ version, your deployment environment, and whether you want to manage your own Prometheus infrastructure or use a managed service. This guide covers every option that works with Prometheus and Grafana today, what each one gives you, and when to use each.

The Options at a Glance

Option 1: The Built-in rabbitmq_prometheus Plugin

The rabbitmq_prometheus plugin ships with every RabbitMQ installation from 3.8 onward and is the approach the RabbitMQ team explicitly recommends for production. It runs inside the broker process, exposes metrics on port 15692 at /metrics, and has low overhead because it reads directly from internal broker state rather than polling the Management HTTP API.

Enable it:

rabbitmq-plugins enable rabbitmq_prometheus

rabbitmq-plugins enable rabbitmq_prometheus

Verify:

curl http://localhost:15692/metrics | head -20

curl http://localhost:15692/metrics | head -20

Two endpoints available:

/metrics returns aggregated cluster-level metrics and is the standard scrape target. /metrics/detailed returns per-queue and per-consumer metrics with rabbitmq_detailed_ prefixed names and requires specifying metric families as query parameters:

GET /metrics/detailed?family=queue_coarse_metrics&family=queue_consumer_count

The detailed endpoint is the correct approach for per-queue alerting. The /metrics endpoint alone does not carry queue-name labels.

Prometheus scrape config:

scrape_configs:

  - job_name: rabbitmq

    scrape_interval: 15s

    static_configs:

      - targets:

          - rabbitmq-node1:15692

          - rabbitmq-node2:15692

          - rabbitmq-node3:15692

  - job_name: rabbitmq-detailed

    scrape_interval: 30s

    metrics_path: /metrics/detailed

    params:

      family:

        - queue_coarse_metrics

        - queue_consumer_count

    static_configs:

      - targets:

          - rabbitmq-node1:15692

          - rabbitmq-node2:15692

          - rabbitmq-node3:15692

scrape_configs:

  - job_name: rabbitmq

    scrape_interval: 15s

    static_configs:

      - targets:

          - rabbitmq-node1:15692

          - rabbitmq-node2:15692

          - rabbitmq-node3:15692

  - job_name: rabbitmq-detailed

    scrape_interval: 30s

    metrics_path: /metrics/detailed

    params:

      family:

        - queue_coarse_metrics

        - queue_consumer_count

    static_configs:

      - targets:

          - rabbitmq-node1:15692

          - rabbitmq-node2:15692

          - rabbitmq-node3:15692

Official Grafana dashboards:

Import these from Grafana Labs using the IDs below. They are maintained by the RabbitMQ team.

Option 2: kbudde/rabbitmq_exporter (RabbitMQ 3.x Only)

The kbudde/rabbitmq_exporter is a community-maintained Go binary that polls the RabbitMQ Management HTTP API and exposes results on port 9419 in Prometheus format. It predates the built-in plugin and was widely used before RabbitMQ 3.8.

Important limitation: The exporter only works with RabbitMQ 3.x. The maintainer stated this explicitly in issue #383 on the project’s GitHub repository: “This exporter only works with RabbitMQ 3. Please use the official exporter for RabbitMQ 4 or newer.” For any deployment running RabbitMQ 4.x, use the built-in plugin instead.

Note also that RabbitMQ 3.13 reached the end of community support on January 31, 2026. If you are still on RabbitMQ 3.x, upgrading to a supported 4.x release is strongly advisable before choosing a long-term monitoring approach.

Docker setup (RabbitMQ 3.x deployments only):

docker run -d \

  --name rabbitmq-exporter \

  --net=container:my-rabbitmq \

  -e RABBIT_URL=http://localhost:15672 \

  -e RABBIT_USER=guest \

  -e RABBIT_PASSWORD=guest \

  -e PUBLISH_PORT=9419 \

  kbudde/rabbitmq-exporter

docker run -d \

  --name rabbitmq-exporter \

  --net=container:my-rabbitmq \

  -e RABBIT_URL=http://localhost:15672 \

  -e RABBIT_USER=guest \

  -e RABBIT_PASSWORD=guest \

  -e PUBLISH_PORT=9419 \

  kbudde/rabbitmq-exporter

Prometheus scrape config:

scrape_configs:

  - job_name: rabbitmq-exporter

    scrape_interval: 30s

    static_configs:

      - targets:

          - rabbitmq-host:9419

scrape_configs:

  - job_name: rabbitmq-exporter

    scrape_interval: 30s

    static_configs:

      - targets:

          - rabbitmq-host:9419

The exporter has a corresponding Grafana dashboard (ID 10120) on Grafana Labs built specifically for its metric naming conventions.

Option 3: Grafana Cloud RabbitMQ Integration

Grafana Cloud provides a managed RabbitMQ integration that bundles the scrape configuration, pre-built dashboards, and alert rules into a single install. The integration was updated in February 2026 to add support for RabbitMQ 4.x.

What it includes:

• Grafana Alloy configuration that scrapes the rabbitmq_prometheus plugin endpoint
• 5 pre-built dashboards covering overview, queue health, node health, Erlang VM, and alerts
• 4 pre-configured Prometheus alert rules for queue depth, consumer count, memory, and disk

Setup path:

1. In Grafana Cloud, go to Connections and search for Apache RabbitMQ
2. Follow the Configuration Details tab to install Grafana Alloy on each RabbitMQ host
3. Click Install to add the pre-built dashboards and alert rules

Alloy scrape config (added automatically or manually):

prometheus.scrape "rabbitmq" {

  targets = [

    {"__address__" = "rabbitmq-host:15692"},

  ]

  forward_to = [prometheus.remote_write.grafana_cloud.receiver]

  job_name   = "integrations/rabbitmq"

}

prometheus.scrape "rabbitmq" {

  targets = [

    {"__address__" = "rabbitmq-host:15692"},

  ]

  forward_to = [prometheus.remote_write.grafana_cloud.receiver]

  job_name   = "integrations/rabbitmq"

}

This is the fastest path to a complete RabbitMQ monitoring setup if your team already uses Grafana Cloud. The trade-off is that data leaves your infrastructure and flows to Grafana’s managed platform, and usage above the free tier incurs costs.

Option 4: Kubernetes with the RabbitMQ Cluster Operator

On Kubernetes, the RabbitMQ Cluster Operator enables the rabbitmq_prometheus plugin automatically on every broker node in every managed cluster. No manual plugin configuration is needed.

The operator exposes port 15692 on each pod. To scrape with Prometheus Operator, create a ServiceMonitor targeting each pod individually. Do not point the scrape job at a load-balanced Service for the detailed metrics endpoint, because detailed metrics for a queue are only served by the node hosting that queue’s leader replica.

apiVersion: monitoring.coreos.com/v1

kind: ServiceMonitor

metadata:

  name: rabbitmq

  namespace: monitoring

spec:

  selector:

    matchLabels:

      app.kubernetes.io/component: rabbitmq

  namespaceSelector:

    matchNames:

      - rabbitmq

  endpoints:

    # Standard aggregated metrics

    - port: prometheus

      interval: 15s

    # Per-queue detailed metrics

    - port: prometheus

      interval: 30s

      path: /metrics/detailed

      params:

        family:

          - queue_coarse_metrics

          - queue_consumer_count

apiVersion: monitoring.coreos.com/v1

kind: ServiceMonitor

metadata:

  name: rabbitmq

  namespace: monitoring

spec:

  selector:

    matchLabels:

      app.kubernetes.io/component: rabbitmq

  namespaceSelector:

    matchNames:

      - rabbitmq

  endpoints:

    # Standard aggregated metrics

    - port: prometheus

      interval: 15s

    # Per-queue detailed metrics

    - port: prometheus

      interval: 30s

      path: /metrics/detailed

      params:

        family:

          - queue_coarse_metrics

          - queue_consumer_count

Option 5: Amazon MQ for RabbitMQ

Amazon MQ for RabbitMQ enabled the Prometheus plugin by default on all 4.2 brokers in April 2026. The metrics endpoint is active without any configuration on all Amazon MQ for RabbitMQ 4.2 brokers across all AWS regions.

You can integrate the endpoint with Amazon Managed Service for Prometheus, self-hosted Prometheus, or Grafana Cloud by pointing a scrape job at the broker endpoint. This makes Prometheus-based monitoring accessible on managed RabbitMQ deployments without running your own broker infrastructure.

Option 6: Commercial Platforms

Commercial observability platforms support RabbitMQ monitoring via the Management HTTP API or the Prometheus plugin endpoint. They provide pre-built dashboards and alert policies, but they add cost and vendor dependency on top of what the open-source stack provides for free.

For most teams already running Prometheus and Grafana, the open-source stack with the built-in plugin and official dashboards is the full solution. Commercial platforms make sense when RabbitMQ monitoring is one of many integrations you are consolidating into a single vendor platform that your team already pays for.

How to Choose

What Prometheus and Grafana Cannot Tell You Alone?

Prometheus and Grafana give you complete visibility into the broker: queue depth, message rates, consumer counts, node memory, and disk pressure. What they do not give you is visibility into why a queue is building up. A growing queue depth can mean consumers have crashed, each message is taking too long to process, or a downstream dependency the consumer calls has slowed down. Those three root causes look identical on any queue depth chart.

CubeAPM integrates directly with the RabbitMQ Prometheus plugin through the OpenTelemetry Collector and correlates broker metrics with distributed traces and logs from your producer and consumer services. When a queue depth alert fires, CubeAPM shows which consumer instance is falling behind, how long each message takes end-to-end through the system, and which downstream call is responsible. The Prometheus alert tells you something is wrong. CubeAPM tells you what and where. It runs self-hosted inside your own infrastructure at $0.15/GB ingestion pricing, so no data leaves your environment.

Summary

The right RabbitMQ monitoring tool for Prometheus and Grafana is almost always the built-in rabbitmq_prometheus plugin, combined with the official Grafana dashboards maintained by the RabbitMQ team. It ships with every installation from 3.8 onward, has the lowest overhead, and is the only option explicitly supported for RabbitMQ 4.x. 

The kbudde exporter is legacy tooling for 3.x deployments only, and RabbitMQ 3.x itself reached the end of community support in January 2026. Managed options from Grafana Cloud and Amazon MQ reduce setup work if you are already on those platforms.

Disclaimer: Plugin availability, dashboard IDs, version support, and platform feature details are verified against RabbitMQ 4.3 documentation (rabbitmq.com/docs/monitoring), the kbudde/rabbitmq_exporter GitHub repository (issue #383), Grafana Cloud integration documentation (updated February 2026), and the Amazon MQ Prometheus release announcement (April 2026) as of May 2026.

Also read:

How to Monitor ActiveMQ with Prometheus 

What Are the Key ActiveMQ Metrics to Monitor for Performance? 

RabbitMQ Alerts: How to Alert on RabbitMQ Queue Depth and Consumer Count