Skip to main content

Monitoring RabbitMQ

RabbitMQ is recognised by its AMQP port, and that is deliberate: a broker running in a container hides its process from the host, but the port it publishes is right there. The connection check starts on its own. The queue metrics come from the management API and need one read-only credential stored on the host, nothing else.

How RabbitMQ is recognised​

The signed RabbitMQ definition matches a host with something listening on 5672/tcp. A broker installed from a package and a broker in a Docker container with the port published both qualify, because the port is what the host sees. Once matched, two probes run every minute:

  • a TCP connection to 127.0.0.1:5672, which has to be accepted,
  • GET /api/overview on the management API at 127.0.0.1:15672, authenticated with HTTP basic auth from the credential named rabbitmq-monitor.

Nothing is installed in the broker and no plugin is enabled by the agent; the management plugin has to be on already.

What is collected​

Queue depth. Total messages across the broker, how many are ready for delivery and how many are unacknowledged (delivered but not yet confirmed by a consumer). A growing ready count while consumers hold steady is the classic sign that producers outrun consumers.

Capacity. The number of queues, client connections and consumers, plus the cumulative count of published messages, from which a chart shows the publish rate.

Facts shown on the host page: the RabbitMQ version and the Erlang version underneath it.

SignalMetric
Messages total / ready / unacknowledgedsvc.rabbitmq.messages, svc.rabbitmq.messages_ready, svc.rabbitmq.messages_unacked
Queuessvc.rabbitmq.queues
Connectionssvc.rabbitmq.connections
Consumerssvc.rabbitmq.consumers
Published messages (cumulative)svc.rabbitmq.publish_total
Published messages per secondsvc.rabbitmq.publish_rate

Names, tags and units are in the metrics reference.

There is no RabbitMQ-specific log definition. A broker running in Docker has its stdout and stderr shipped through the Docker log definition under the image name.

Alerts out of the box​

RuleFires whenSeverityShips
RabbitMQ messages are piling up10,000 or more ready messages for 15 minuteswarningon
RabbitMQ queue has no consumerszero consumers on the broker for 10 minuteswarningoff

Ten thousand ready messages held for a quarter of an hour separates a backlog from a burst: a spike that a consumer drains in a few minutes never reaches the hold time, while a consumer that died stays over the line. The incident closes once the ready count falls back under 5,000, so a queue oscillating around the threshold does not flap. The no-consumers rule ships off because an idle queue with no consumer attached is normal on many setups (a queue that is filled by a nightly job and drained in the morning, a dead-letter queue someone inspects by hand); enable it per workspace where every queue is supposed to have a live consumer. Thresholds and hysteresis are in the rules catalog.

Credentials​

The management API refuses anonymous requests, so the overview probe needs a RabbitMQ user. A read-only user is enough (RabbitMQ's own monitoring tag is made for exactly this); it never needs to publish or consume. Store it on the host:

sudo wakora secret set rabbitmq-monitor --user wakora

The command prompts for the password. The value is stored encrypted on the host, bound to that machine, and never sent anywhere; the definition refers to the credential by its name only. Until the credential exists, the overview check fails and names the command that fixes it, while the port check keeps running. See Secrets stay local.

Limitations​

  • Everything comes from the overview endpoint, so the numbers are broker-wide totals. Depth per queue, per virtual host or per node is not collected.
  • The management API must answer on 127.0.0.1:15672. A broker in a container must publish that port too, not only 5672, or the queue metrics stay empty while the port check passes.
  • Node health signals that RabbitMQ raises itself (memory and disk alarms, partitioned cluster members) are not read.
  • The published-message count is a cumulative counter; use the chart for the rate rather than the raw value.
  • Matching is by port. Another AMQP broker listening on 5672 matches the definition and fails the management probe, which the check reports plainly.