Queues and streams
RabbitMQ — planned
Queue depth, consumer count and dead-letter queues — the last of which is usually the finding. This integration is planned: documented here as reference, not connectable from the admin today.
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.
RabbitMQ today
Decim does not connect to brokers today. Consumer and producer code in a connected GitHub repository is read during discovery, which identifies queue consumers as pipeline triggers. Consumer logs are read from Google Cloud Logging or, on Windows hosts, through the optional agent.
The sources that ship today are GitHub, Google Cloud Logging, Jira Cloud and the optional Windows agent. Everything below this point describes the planned RabbitMQ integration: what it is designed to read, and why.
What Decim will read from RabbitMQ
The intended read-only surface for this integration. It is reference material for the roadmap — and useful on its own, because these are the views and APIs worth knowing during an incident whether or not any tool reads them for you.
| 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 it is designed around
Written out in full, because "read-only access" is not a specification. These are the grants the planned integration is designed around and may change before it ships. Nothing below grants the ability to write, and row access would be requested only on the specific tables you name. You do not need to create any of this today.
# 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 would be read:
curl -s -u decim-agent:... \
"https://rabbit.internal:15672/api/queues?columns=name,messages_ready,\
messages_unacknowledged,consumers,arguments"What it would build
What this source would contribute 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
Today, topology is built from code in GitHub, and each connection is marked direct or inferred. The design direction for sources like this one is a provenance model: a step found in a definition is declared, a step seen running is observed, one that is both is verified, and where two sources disagree the disagreement is kept as a drift note rather than resolved silently. That model is planned, not shipped.
Failure modes it would surface
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. Until the integration ships, the same signals can be checked by hand, or requested by Decim as a check your team runs.
| 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 source cannot tell you, even once it is read. Stated because an investigation that overstates its sources produces confident wrong answers, which is worse than an honest cause unclear.
- Management plugin statistics are sampled; short spikes may not appear in rate metrics
- Message content would never be read, so this source could not 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. Will read group offsets, topic ends and partition assignment.
- Custom services — No API and no metadata database — code, logs and the tables they write to. Code and logs work today.
- SQL Server — Will read 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.