Every RabbitMQ concept, kept distinct.
Clusters and virtual hosts
Nodes, their state and the vhosts on them, the broker’s own health checks — alarms, certificates close to expiry, quorum queues one failure from losing their majority — and the deprecated features the cluster still uses. A vhost can be protected from deletion, or started again on a node where it stopped. A vhost boundary is usually the cleanest mapping onto an environment.
Exchanges
Direct, topic, fanout and headers exchanges with their durability, arguments and every binding leaving them.
Queues and depth
Ready, unacknowledged and total counts, plus consumer count and the arguments that decide TTL, length limits and overflow behaviour.
Bindings and routing keys
Every binding leaving an exchange — exchange-to-exchange hops included — with the key each one matches. The relationship is the thing, so it is drawn rather than listed.
Connections and channels
Client connections, the channels multiplexed over them, prefetch settings and the consumers attached to each queue — and every connection of one user closed at once, with a reason the broker passes to its clients.
Dead-letter flows
Where a rejected or expired message goes next, followed one hop at a time rather than assumed from a naming convention — and kept apart from the unroutable case, which is the alternate exchange’s job.
Quorum queues and streams
Per-replica Raft state with commit and log indices, delivery limits, and streams read by offset, timestamp or interval — a read that takes nothing away.
Policies, applied honestly
User policies ordered by priority — only the highest match applies — with operator policies shown as the separate layer they are.
Message operations
Publish to an exchange with publisher confirms and see what the broker did with it — confirmed, returned because nothing routed it, or refused. Getting a message off a queue is an operation on the queue, and the console says so.
Follow the message, not the queue name.
Publishing goes to an exchange, never to a queue. Which queue receives it is decided by the bindings and the routing key — so the console draws the topology that makes that decision instead of leaving you to infer it from four screens and a naming convention.
Two numbers, two different problems.
Ready messages are waiting for a consumer; unacknowledged ones are already with a consumer that has not confirmed them. A queue that is deep in ready needs throughput; a queue that is deep in unacknowledged needs to know why a consumer stopped answering. Quorum queues add a third reading: redeliveries approaching the delivery limit, and a minority state the console flags red.
| Binding key | Queue | pay.us.settled |
|---|---|---|
| pay.eu.# | q.pay.eu | no match |
| pay.us.# | q.pay.us | matched |
| pay.*.failed | q.pay.dlq | no match |
| # | q.pay.audit | matched |
A topic exchange delivers to every matching binding, not the first one. The catch-all binding is why an audit queue is also filling — which is easy to forget and hard to see anywhere else.
Purging discards ready messages irrecoverably. It requires operate rights on the environment, names the queue and the count in the confirmation, and is refused outright where the environment is marked read-only.
A memory or disk alarm on a single node blocks publishers across the whole cluster — the reason nothing is publishing while no queue looks full. The console names the node and the alarm, and keeps flow, blocking and blocked apart, because they are three different states.
Permissions live on the vhost. So do the mistakes.
RabbitMQ grants configure, write and read per vhost with regular expressions, which is powerful and easy to get subtly wrong. BROKA's scoped role is checked first, and the connection's own vhost permissions still apply underneath — neither layer is bypassed.
- 01Map one vhost to one environment wherever the estate allows it
- 02Purge and delete require operate rights and name the queue and count
- 03Publishing from the console is refused in a read-only environment, not queued
- 04Policy edits are administrative: who changed which policy, and what it now sets
- 05Closing a client connection is deliberate: operate rights, a stated reason, and an audit entry
- 06In Commercial, the fields a data masking rule covers are masked in every message the console reads, and every unmasked read is recorded
- 07Connects with a password or OAuth 2.0 client credentials, over TLS verified against your own CA and with a client certificate where the broker asks for one — and an environment that forbids insecure TLS holds here too
actor mert@northwind-bank.example
session 9f2c4a ip: 10.20.8.41
env production policy: read-only
broker rabbitmq cluster: rmq-core-01
resource queue q.pay.us vhost: /payments
action purge
outcome rejected — blocked by environment policyA rejected action is recorded exactly like an accepted one. A trail that only holds successes cannot answer the question an access review is actually asking.
Audit and accountability →