Clusters

Updated 10 October 2026 · applies to 1.2.0 · Commercial

RabbitMQ ▸ Overview in the sidebar shows what the management API can tell you about a cluster in one read, starting with whether anything blocks publishers. Around that sit its version, its nodes and what each is running on, what is listening and which plugins are enabled.

BROKA reaches RabbitMQ over its management API. How a connection reaches the cluster — the management URL and AMQP endpoint, a password or OAuth 2.0, TLS and client certificates — and what its test proves are on Connecting and authentication.

The alarm band

This is the part of the screen worth reading first, and the reason it sits above everything else.

RabbitMQ raises a resource alarm when a node goes over its memory watermark or under its free-disk limit. When that happens the broker stops accepting publishes across the entire cluster — not just on the alarmed node. Connections move to blocking and then blocked, and from an application's side publishing simply stops, with no error to read.

An operator looking at a console that does not show this sees a healthy cluster and a stuck producer.

So BROKA puts it first, in its own colour, and says which nodes are alarmed and which kind of alarm it is. The ? beside the page title says the part that matters most:

A resource alarm blocks publishing across the whole cluster until it clears. It cannot be cleared from here — free the memory or the disk, or change the watermark on the broker.

There is no button. Neither alarm can be cleared over the management API — they clear when the resource pressure does, or when the watermark is changed, which is a broker-side change. BROKA reports it rather than offering an action it cannot perform.

The same condition surfaces in two other places, so you can arrive at it from either end: the alarmed node's state, and — on the Connections screen — a blocked client connection, with a tooltip saying the cause is the cluster and not the client.

The nodes

Each node shows its memory against its limit, its free disk and its state — Down, Alarm when it holds a memory or free-disk alarm, or Running, which is the one left uncoloured. A node being drained or partitioned is marked as such beside its name. The card's Columns control adds its file descriptors (FDs), Erlang processes (Procs), Run queue and Uptime.

The RabbitMQ Overview of rabbitmq-prod-eu: rabbit@broka-rabbitmq, RabbitMQ 4.3.6, Erlang 27.3.4.18 and 1 node in the subtitle; one row of cards — Nodes 1/1, Queues 21 with 33 exchanges beneath, Connections 19 with 11 channels and 10 consumers beneath, Ready 3.2M, Unacknowledged 375, and Publish / deliver 0.0 / 5.2 msg/s with 5.2/s acknowledged and 0.0/s unroutable beneath; a Nodes table with the node's memory, free disk and Running state; a Listeners panel naming five listeners, each Plaintext, with the enabled plugins and the rates mode basic beneath; and below them Health checks reading 6 of 6 checks passed and the Churn card. — One node here. The table has a row per node, and the figures it shows are the ones an alarm is raised against.

One node here. The table has a row per node, and the figures it shows are the ones an alarm is raised against.

The Nodes card's Columns menu open on the RabbitMQ Overview of rabbitmq-prod-eu: Memory, Disk free and State in the table, in an order you can drag, and FDs, Procs, Run queue and Uptime offered under Add a column — beside the Listeners card and above the Health checks. — The four extra figures are hidden by default, not missing; the card's own Columns control adds them.

The four extra figures are hidden by default, not missing; the card's own Columns control adds them.

Memory is shown proportionally, because "159 MB" means nothing without the watermark it is measured against.

Opening a node's row shows where that memory goes: the broker's own breakdown of the node's memory into its categories — connections, queues, binaries, the internal tables and the rest — each with its size and its share, largest first, with each bar drawn against the largest category; the categories under half a percent are summed into one Other row. It is the read to make before touching the watermark: a node near its limit because of connection buffers needs a different fix from one holding a deep queue in memory. A node that is not running reports no breakdown, and the dialog says so.

The memory dialog of the node rabbit@broka-rabbitmq, where its memory goes as the broker reports it: strategy rss, total (rss) 457 MB, Erlang total 136 MB and allocated 482 MB, then each category with its memory and share, largest first — allocated_unused at 345 MB and 71.7%, then other_system, quorum_queue_procs, code, other_proc, Other (18) summing the smallest categories, queue_procs, quorum_ets and binary — each with a share bar. — The broker's own breakdown, largest first: the read to make before moving the watermark, because a node full of connection buffers needs a different fix from one holding a queue in memory.

The broker's own breakdown, largest first: the read to make before moving the watermark, because a node full of connection buffers needs a different fix from one holding a queue in memory.

Each node row also has a menu that grows quorum queues onto that node or removes its replicas, and the header's ⋯ menu has Rebalance queue leaders, disabled with the reason on a single-node cluster — see Quorum replicas.

Churn

Below the health checks, one Churn card counts what is opening and closing, per second: Connections opened, Connections closed, Channels opened, Channels closed, Queues declared, Queues created and Queues deleted.

It answers the question the message rates never do. An application that opens a connection for every publish looks idle on every other card, and here it is the busiest thing on the cluster. Like the message rates, the card appears only while the broker collects statistics.

Health checks

Below the nodes, the Health checks card runs the broker's own health checks. Its first line is the summary — 6 of 6 checks passed · No deprecated features in use — and a row appears only for a check that did not pass, with the broker's reason; Show every check lists the passed ones too. The checks are:

no resource alarm in the cluster, and none on this node;
no listener certificate expiring within a window you choose — 7, 30 or 90 days, or a year;
the node listening for AMQP;
every virtual host running on the node;
whether stopping this node would leave any quorum queue without its majority.

Each check reads Passed, Failed with what the broker found, or Not available on a broker version that predates it — never a failure it did not report. The checks run on the node that serves the management API, and the card names it. The broker's port-listener check is left out on purpose: the port a connection reaches may be a load balancer's, not the node's. Certificate expiry and quorum criticality in particular are answers the rest of the management API does not give any other way.

Deprecated features in use

The same card lists the deprecated features the cluster is still using, each with its deprecation phase and what provides it — the list to clear before an upgrade that removes them. It is read-only: BROKA shows them and changes nothing. When nothing deprecated is in use, the summary line says so and no list is drawn.

The Health checks card answered by rabbit@broka-rabbitmq-older with Certificates: 30 days chosen: the summary line reads 6 of 6 checks passed · No deprecated features in use, with Hide passed checks at its end, and every check listed with its result and a dash for detail — No resource alarm in the cluster (alarms), No resource alarm on this node (local-alarms), No listener certificate expiring within 30 days (certificate-expiration), Listening for amqp on this node (protocol-listener), Every virtual host running on this node (virtual-hosts) and Stopping this node leaves every quorum queue its majority (node-is-quorum-critical), each Passed. — Each verdict is the broker's own; with nothing deprecated in use, the summary line says so and no list is drawn.

Each verdict is the broker's own; with nothing deprecated in use, the summary line says so and no list is drawn.

What is listening, and what is installed

The listeners panel names each endpoint the broker is accepting on and whether it is TLS or plaintext — which is the fastest way to answer "is our AMQP port actually encrypted".

The plugin list is the union across nodes, and it is per-node underneath for a reason: a plugin enabled on some nodes and not others is a real and confusing cluster state, and a cluster-wide union alone would hide it.

Metrics

The overview ends with a Metrics section: the cluster's publish and deliver rates and its messages over time, from the metric history, and any cluster figure an alert rule watches. One range picker — 1 hour, 6 hours, 24 hours, 7 days or the retention — sets every chart. While statistics are switched off the rates are not reported, and their charts have a gap rather than a zero.

When statistics are switched off

RabbitMQ can be run with its metrics collector disabled. In that state the broker does not report message rates, queue totals, node memory, resource alarms or the plugin list at all.

BROKA says so in a banner, with the setting to change behind the ? beside the page title — and it distinguishes the two cases everywhere it can: unknown, because statistics are off is not the same statement as none. A plugin list that is not being reported is not an empty plugin list.

Shovels, federation and streams do not depend on it. BROKA asks the broker which management plugins it serves — a list RabbitMQ reports whether or not statistics are collected — and offers each feature whose plugin is there. One whose management plugin is not enabled is shown as unavailable with the plugin it needs named; if even that list cannot be read, the feature is offered and RabbitMQ answers for itself.

A number BROKA did not receive is shown as —, with that as the reason, rather than as zero.

On a broker older than 4.0

BROKA is built against RabbitMQ 4.0 and verified on 4.3. On an older broker a banner names its version, and the ? beside the page title says what differs — it accepts non-durable queues that 4.x refuses, runs Mnesia rather than Khepri so no queue can show a minority state, and may report no default queue type for a virtual host — so that behaviour is not read as a fault of the console. Everything else keeps working.