Self-Hosted RabbitMQ Monitoring & Management Dashboards: RabbitMQ Management vs RabbitScout vs rabbitmq_exporter

RabbitMQ is the most widely deployed open-source message broker, powering asynchronous communication in thousands of production systems. But as your RabbitMQ clusters scale, relying on command-line tools alone becomes impractical. You need visibility into queue depths, consumer health, message rates, and cluster status in real time.

This guide compares three leading approaches to monitoring and managing RabbitMQ: the built-in RabbitMQ Management Plugin, the modern RabbitScout dashboard, and the rabbitmq_exporter for Prometheus-based observability. Each serves a different monitoring philosophy, and the right choice depends on whether you want a standalone web UI, a modern real-time dashboard, or deep integration with your existing Prometheus and Grafana stack.

RabbitMQ Management Plugin

The RabbitMQ Management Plugin ships with every RabbitMQ installation and provides a comprehensive web-based interface for monitoring and administering your broker. It is the default starting point for most RabbitMQ users and requires no additional software beyond enabling the plugin.

Key Features

• Real-time queue depth, message rates, and consumer count visualization
• Exchange and binding topology management via web UI
• User, virtual host, and permission management
• Message publishing, getting, and purging from the web interface
• HTTP-based Management API for programmatic access
• Per-queue and per-connection detailed statistics
• Policy and parameter configuration

Architecture

The management plugin runs as a built-in Erlang application within the RabbitMQ node. It exposes both a web UI and a REST API on port 15672 by default. The plugin gathers statistics from the internal RabbitMQ ETS tables and AMQP flow counters, aggregating them into configurable sample intervals (default: 5 seconds for coarse data, 1 second for fine data).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

# docker-compose.yml - RabbitMQ with Management Plugin
version: "3.8"
services:
  rabbitmq:
    image: rabbitmq:4-management
    container_name: rabbitmq
    hostname: rabbitmq-node1
    ports:
      - "5672:5672"   # AMQP
      - "15672:15672" # Management UI
    environment:
      RABBITMQ_DEFAULT_USER: admin
      RABBITMQ_DEFAULT_PASS: changeme
      RABBITMQ_DEFAULT_VHOST: /
    volumes:
      - rabbitmq_data:/var/lib/rabbitmq
      - ./rabbitmq.conf:/etc/rabbitmq/rabbitmq.conf:ro
    restart: unless-stopped

volumes:
  rabbitmq_data:

rabbitmq.conf for Management Plugin

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

## Enable management plugin (enabled by default with -management image)
management.tcp.port = 15672
management.tcp.ssl = false

## Statistics collection interval (seconds)
collect_statistics = fine
collect_statistics_interval = 5000

## HTTP API rate limiting
management.rates_mode = basic

The management plugin is suitable for small to medium deployments where a single broker or small cluster needs basic monitoring. However, it does not integrate with external alerting systems and lacks long-term historical data.

RabbitScout

RabbitScout is a modern, open-source RabbitMQ management dashboard built with Next.js, TypeScript, and uPlot for real-time charting. It provides a cleaner, faster UI experience compared to the traditional management plugin, with features like pass-through authentication and a focus on developer productivity.

Key Features

• Modern React-based dashboard with responsive design
• Real-time queue and message rate visualization with uPlot charts
• Message inspection and pass-through authentication
• Built with Next.js for fast client-side navigation
• Queue management with deep message inspection
• REST API integration with RabbitMQ Management HTTP API

Architecture

RabbitScout acts as a frontend proxy to the RabbitMQ Management HTTP API. It does not run inside RabbitMQ itself but connects to the management API endpoints to fetch and display data. This architecture allows it to be deployed independently and connected to multiple RabbitMQ clusters.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

# docker-compose.yml - RabbitScout Dashboard
version: "3.8"
services:
  rabbitmq:
    image: rabbitmq:4-management
    container_name: rabbitmq
    ports:
      - "5672:5672"
      - "15672:15672"
    environment:
      RABBITMQ_DEFAULT_USER: admin
      RABBITMQ_DEFAULT_PASS: changeme
    restart: unless-stopped

  rabbitscout:
    image: ghcr.io/ralve-org/rabbitscout:latest
    container_name: rabbitscout
    ports:
      - "3000:3000"
    environment:
      RABBITMQ_URL: http://rabbitmq:15672
      RABBITMQ_USER: admin
      RABBITMQ_PASS: changeme
    depends_on:
      - rabbitmq
    restart: unless-stopped

RabbitScout is ideal for teams that want a modern, responsive monitoring experience without sacrificing the depth of the underlying Management API. It pairs well with the management plugin enabled on the RabbitMQ side.

rabbitmq_exporter for Prometheus

The rabbitmq_exporter is a Prometheus exporter that scrapes RabbitMQ’s Management API and exposes metrics in Prometheus format. This enables integration with the broader observability ecosystem: Grafana for dashboards, Alertmanager for alerting, and Thanos or Cortex for long-term storage.

Key Features

• Full Prometheus metrics export from RabbitMQ
• Pre-built Grafana dashboards for queue depth, message rates, and consumer health
• Configurable metric filtering and labeling
• Alert rules for queue overload, consumer disconnection, and node health
• Lightweight standalone binary or Docker container
• Supports RabbitMQ cluster-wide metrics aggregation

Architecture

The exporter runs as a separate process that periodically queries the RabbitMQ Management HTTP API (default: every 10 seconds), parses the JSON response, and converts the data into Prometheus metric format. It is scraped by the Prometheus server, which then feeds Grafana for visualization and Alertmanager for notifications.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

# docker-compose.yml - RabbitMQ + Prometheus + Grafana Stack
version: "3.8"
services:
  rabbitmq:
    image: rabbitmq:4-management
    container_name: rabbitmq
    ports:
      - "5672:5672"
      - "15672:15672"
    environment:
      RABBITMQ_DEFAULT_USER: admin
      RABBITMQ_DEFAULT_PASS: changeme
    restart: unless-stopped

  rabbitmq_exporter:
    image: kbudde/rabbitmq-exporter:latest
    container_name: rabbitmq-exporter
    ports:
      - "9419:9419"
    environment:
      RABBIT_URL: http://rabbitmq:15672
      RABBIT_USER: admin
      RABBIT_PASSWORD: changeme
      PUBLISH_ADDR: "0.0.0.0"
      PUBLISH_PORT: "9419"
      OUTPUT_FORMAT: "json"
    depends_on:
      - rabbitmq
    restart: unless-stopped

  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro
    depends_on:
      - rabbitmq_exporter
    restart: unless-stopped

  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    ports:
      - "3001:3000"
    environment:
      GF_SECURITY_ADMIN_PASSWORD: admin
    volumes:
      - grafana_data:/var/lib/grafana
    depends_on:
      - prometheus
    restart: unless-stopped

volumes:
  grafana_data:

Prometheus Configuration

1
2
3
4
5
6
7
8
9

# prometheus.yml
global:
  scrape_interval: 15s

scrape_configs:
  - job_name: "rabbitmq"
    static_configs:
      - targets: ["rabbitmq-exporter:9419"]
    metrics_path: /metrics

Example Prometheus Alert Rules

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

# alert-rules.yml
groups:
  - name: rabbitmq-alerts
    rules:
      - alert: RabbitMQQueueDepthHigh
        expr: rabbitmq_queue_messages_ready > 10000
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Queue {{ $labels.queue }} has high message depth"

      - alert: RabbitMQConsumerDown
        expr: rabbitmq_queue_consumers == 0
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Queue {{ $labels.queue }} has no active consumers"

      - alert: RabbitMQNodeMemoryHigh
        expr: rabbitmq_node_mem_used / rabbitmq_node_mem_limit > 0.8
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "RabbitMQ node memory usage above 80%"

Comparison Table

Deployment Architecture Recommendations

Small Deployment: Management Plugin Only

For a single RabbitMQ broker or small development cluster, the built-in management plugin is sufficient. Enable it with rabbitmq-plugins enable rabbitmq_management and access the UI at port 15672.

Medium Deployment: RabbitScout + Management Plugin

For teams that want a better UI experience while retaining full management capabilities, deploy RabbitScout as a frontend to the Management API. The management plugin remains enabled for administrative tasks, while RabbitScout provides the day-to-day monitoring dashboard.

Production Deployment: rabbitmq_exporter + Prometheus + Grafana

For production environments requiring historical data, alerting, and integration with existing observability infrastructure, the rabbitmq_exporter + Prometheus + Grafana stack is the recommended approach. This provides:

• Long-term metric storage and trend analysis
• Automated alerting via Alertmanager (PagerDuty, Slack, email)
• Custom Grafana dashboards with saved views
• Correlation with application and infrastructure metrics

Choosing the Right Monitoring Stack

The three tools are not mutually exclusive. A mature RabbitMQ deployment typically uses all three:

1. Management Plugin — always enabled as the source of truth for the Management API
2. RabbitScout — for developers who prefer a modern, responsive UI for daily queue inspection
3. rabbitmq_exporter — for SRE and operations teams who need alerting and historical metrics

Why Self-Host RabbitMQ Monitoring?

Running your own RabbitMQ monitoring infrastructure gives you complete control over data retention, alert routing, and dashboard customization. Cloud-hosted RabbitMQ services often limit monitoring access or charge premium prices for advanced metrics. With self-hosted monitoring, you can:

• Retain metrics history indefinitely without per-metric pricing
• Configure custom alert thresholds tailored to your workload patterns
• Correlate RabbitMQ metrics with application-level tracing and logging
• Avoid vendor lock-in and data egress charges
• Meet compliance requirements for on-premises data storage

For organizations already running Prometheus and Grafana for infrastructure monitoring, adding the rabbitmq_exporter integrates RabbitMQ seamlessly into your existing observability pipeline. For teams evaluating message broker health as part of a broader infrastructure review, our STOMP server comparison covers how RabbitMQ fits into the wider messaging landscape. If you’re managing message processing workflows, our task queue web UI guide provides complementary monitoring strategies for consumer-side visibility.

FAQ

Which RabbitMQ monitoring tool should I use first?

Start with the built-in RabbitMQ Management Plugin — it ships with RabbitMQ and requires no additional setup. Enable it with rabbitmq-plugins enable rabbitmq_management. Once you need historical data or alerting, add rabbitmq_exporter with Prometheus and Grafana.

Can I use RabbitScout without the Management Plugin?

No. RabbitScout connects to the RabbitMQ Management HTTP API, which is provided by the Management Plugin. The plugin must be enabled on your RabbitMQ broker for RabbitScout to function.

Does rabbitmq_exporter replace the Management Plugin?

No. The exporter scrapes the Management API but does not provide a management interface. You still need the Management Plugin (or at least the HTTP API) running on RabbitMQ. The exporter only provides metrics in Prometheus format.

How often should RabbitMQ metrics be scraped?

For most workloads, a 15-second Prometheus scrape interval is sufficient. For high-throughput systems with rapidly changing queue depths, reduce to 5-10 seconds. Avoid scraping faster than 5 seconds to prevent excessive load on the Management API.

Can I monitor multiple RabbitMQ clusters with one exporter?

Yes. Run one rabbitmq_exporter instance per RabbitMQ cluster, each configured with its own RABBIT_URL. Prometheus can scrape from multiple exporter targets and you can use Grafana templating to switch between clusters.

What RabbitMQ metrics are most important to monitor?

Key metrics include: rabbitmq_queue_messages_ready (queue depth), rabbitmq_queue_messages_published_total (ingest rate), rabbitmq_queue_messages_delivered_total (consumption rate), rabbitmq_queue_consumers (active consumers), and rabbitmq_node_mem_used (node memory). Set alerts on queue depth growth and consumer drops.