Monitoring RabbitMQ with OpenTelemetry means collecting broker and queue metrics through the OpenTelemetry Collector's RabbitMQ receiver over OTLP, so message-queue health is observed with the rest of the stack..
Monitoring RabbitMQ with OpenTelemetry means collecting broker and queue metrics through the OpenTelemetry Collector's RabbitMQ receiver over OTLP, so message-queue health is observed with the rest of the stack.
For RabbitMQ the critical signals are queue depth and its rate of change, message publish and delivery rates, unacknowledged messages, consumer counts, and connection and channel health. A queue that is growing means consumers cannot keep pace, and whatever depends on those messages is being delayed.
The reading that catches incidents earliest is queue depth trend against consumer count: depth climbing while consumers drop toward zero is the clearest sign that processing has stalled, well before any downstream system reports a problem.
The Collector's rabbitmq receiver reads the RabbitMQ management API and emits node and queue metrics, message counts, publish and deliver rates, consumers and connections, over OTLP. The filelog receiver collects the broker logs, and instrumented producers and consumers add traces so you can follow a message end to end.
The prerequisite is the management plugin: enable it and give the receiver a monitoring user, since the receiver reads its metrics from that API rather than from the broker directly.
The signals that explain most RabbitMQ incidents:
| Signal | Source | What it tells you / watch for |
|---|---|---|
rabbitmq.message.current (ready) | rabbitmq receiver | Messages waiting in a queue; a rising ready count is a backlog forming. |
rabbitmq.message.current (unacknowledged) | rabbitmq receiver | Messages delivered but not acked; a pileup means consumers are receiving but not completing work. |
rabbitmq.message.published | rabbitmq receiver | Publish rate; compared to delivery rate, whether the queue is filling faster than it drains. |
rabbitmq.message.delivered | rabbitmq receiver | Delivery rate to consumers; a drop toward zero with a full queue means consumption stalled. |
rabbitmq.consumer.count | rabbitmq receiver | Consumers on a queue; dropping to zero leaves messages with nowhere to go. |
connections / channels | rabbitmq receiver | Connection and channel churn indicates unstable clients. |
A RabbitMQ dashboard should make a backlog and its cause obvious. Row one: queue depth (ready messages) over time per queue, and publish rate versus delivery rate on the same panel so you can see filling-faster-than-draining. Row two: unacknowledged messages and consumer count per queue. Row three: connection and channel counts for client stability.
# queue backlog: ready messages climbing = consumers behind
rabbitmq.message.current{state="ready"} by (queue)
# fill vs drain (published rate above delivered rate = growing queue)
rate(rabbitmq.message.published[5m]) - rate(rabbitmq.message.delivered[5m])
# queues with no consumers
rabbitmq.consumer.count == 0 by (queue)Ready-message count climbs without bound because publishers are outpacing consumers, delaying everything downstream. Publish rate above delivery rate confirms it. Scale consumers, speed up per-message processing, or apply back-pressure at the publisher.
A queue's consumer count drops to zero, so messages accumulate with nothing to process them, often after consumer instances crash or fail to reconnect. The consumer-count panel shows it immediately. Restart or fix the consumers and check why they disconnected.
Unacked messages climb because consumers receive messages but never acknowledge them, usually because processing hangs or throws before the ack. Redelivery on reconnect can then cause duplicate work. Fix the consumer so it acks (or rejects) every message, and set a sensible prefetch.
Starting thresholds to tune:
| Condition | Signal | Meaning |
|---|---|---|
| queue ready messages rising for 15m | backlog | Consumers cannot keep up. |
| consumer count = 0 for 2m | consumers | A queue has no one processing it. |
| unacknowledged climbing | consumers | Consumers receiving but not completing work. |
| publish rate > deliver rate for 10m | throughput | Queue filling faster than it drains. |
Ops Singularity's TelemetryOps ingests RabbitMQ telemetry over OpenTelemetry, and Sentinel AI resolves queue incidents through governed Action Tickets. Explore TelemetryOps.
Use the OpenTelemetry Collector's rabbitmq receiver for node and queue metrics and the filelog receiver for logs, exported over OTLP.
Queue depth and growth, publish and delivery rates, unacknowledged messages, consumer counts, and connection and channel health.
Bring a real incident. We will show you Sentinel investigate, act and verify end to end, with every action reversible and audited.