Queues and streams
RabbitMQ
Queue depth, consumer count and dead-letter queues — the last of which is usually the finding.
RabbitMQ's management API exposes everything an investigation needs about message flow, and the single most useful thing in it is the dead-letter queue. Messages that could not be processed are routed there, retained silently, and monitored by almost nobody — which makes it the queue equivalent of the reject table.
The second most useful is the split between messages_ready and
messages_unacknowledged. A queue with a large unacked count is not backed up
because it lacks consumers; it is backed up because a consumer took the messages and never
acknowledged them, which is a completely different diagnosis.
What Decim reads from RabbitMQ
Every item below is read-only, and each is a specific view, endpoint or file rather than a category of access. If something here is unacceptable in your environment, it can be removed from the query catalogue — see the agent for how that works.
| What | From | Why it matters |
|---|---|---|
| Queue depth | GET /api/queues | messages_ready and messages_unacknowledged, separately |
| Consumer count | GET /api/queues | Zero consumers on a live queue is an immediate finding |
| Message rates | message_stats | Publish, deliver and ack rates over time |
| Dead-letter config | arguments.x-dead-letter-exchange | Where rejected messages go, if anywhere |
| Bindings | GET /api/bindings | Exchange-to-queue routing — the topology |
| Connections and channels | GET /api/connections | Which services are attached |
| Shovel and federation | GET /api/shovels | Cross-broker movement, frequently undocumented |
Permissions required
Written out in full, because "read-only access" is not a specification. Nothing below grants the ability to write, and row access is requested only on the specific tables you name.
# The built-in monitoring tag grants read access to the management API
# without any ability to publish, consume, or purge.
rabbitmqctl add_user decim-agent '...'
rabbitmqctl set_user_tags decim-agent monitoring
# Explicitly no permissions on any vhost resource: the monitoring tag
# covers the API surface, and this leaves message operations impossible.
rabbitmqctl set_permissions -p / decim-agent '^$' '^$' '^$'
# What the agent reads:
curl -s -u decim-agent:... \
"https://rabbit.internal:15672/api/queues?columns=name,messages_ready,\
messages_unacknowledged,consumers,arguments"What it builds
What this source contributes to the pipeline topology and to the evidence available during an investigation:
- Exchange and queue topology from bindings
- Which services consume which queues, from connection and channel data
- Dead-letter routing — and, more often, its absence
- Cross-broker movement via shovels that no diagram includes
Nodes learned from a definition are marked declared; nodes observed running are marked observed; nodes both declared and observed are verified. Where two sources disagree, the disagreement is recorded as a drift note rather than resolved silently.
Failure modes it surfaces
What this source is uniquely good at proving — and, just as usefully, at disproving. An investigation that can refute a hypothesis cheaply is worth as much as one that confirms it.
| Failure mode | The signal |
|---|---|
| Messages quietly dead-lettered | Growing depth on a DLQ nobody monitors |
| Consumer took messages and hung | High messages_unacknowledged, low ready |
| No consumers attached | consumers = 0 on a queue still being published to |
| Messages dropped entirely | No dead-letter exchange configured on a queue that rejects |
Limits
What this integration cannot tell you. Stated because an investigation that overstates its sources produces confident wrong answers, which is worse than an honest blocked.
- Management plugin statistics are sampled; short spikes may not appear in rate metrics
- Message content is never read, so the agent cannot tell you which records were affected — only how many
- Queue depth reflects the moment of sampling and a fast-draining backlog may be invisible between polls
Related integrations
- Apache Kafka — Consumer lag is the leading indicator. Reads group offsets, topic ends and partition assignment.
- Custom services — No API and no metadata database — structured logs, config files and the tables they write to.
- SQL Server — Reads catalog metadata, procedure bodies and write activity — the definitions git never sees.
See all integrations, or how the sources are combined into one graph.
Get started
Investigating a RabbitMQ pipeline?
Bring an incident you already know the answer to. If Decim gets it wrong, that is a more useful demo than one where it doesn't.