Track RabbitMQ queue depth and consumer lag with OpenTelemetry

Queue depth is the earliest signal that an integration is falling behind. When the number of ready messages on a RabbitMQ queue starts climbing, your consumers can’t keep up — and every message that lands after that waits a little longer. This guide points the OpenTelemetry Collector at RabbitMQ’s management API, streams per-queue metrics into Sluicio, and turns a growing backlog into an alert.

No application code changes are needed: the Collector polls RabbitMQ over HTTP and exports standard OTLP metrics.

Before you start

You’ll need a running RabbitMQ broker you can reach over HTTP, and the OpenTelemetry Collector (contrib) — the rabbitmq receiver ships in the contrib distribution, not the core one.

1 · Enable the management plugin

The receiver reads from RabbitMQ’s management HTTP API (port 15672). Enable the plugin and create a read-only user scoped to monitoring only:

# Expose the management HTTP API on :15672
rabbitmq-plugins enable rabbitmq_management

# A read-only user tagged 'monitoring' — no queue read/write/configure rights
rabbitmqctl add_user monitoring "$RABBITMQ_MONITOR_PASSWORD"
rabbitmqctl set_user_tags monitoring monitoring
rabbitmqctl set_permissions -p / monitoring "^$" "^$" ".*"

2 · Configure the Collector

Add the rabbitmq receiver and an OTLP exporter that points at Sluicio. Secrets come from the environment, so nothing sensitive lives in the file.

otel-collector-config.yaml

receivers:
  rabbitmq:
    endpoint: http://localhost:15672
    username: monitoring
    password: ${env:RABBITMQ_MONITOR_PASSWORD}
    collection_interval: 30s

exporters:
  otlphttp/sluicio:
    endpoint: https://your-instance-name.sluicio.com
    headers:
      authorization: Bearer ${env:SLUICIO_INGEST_KEY}

service:
  pipelines:
    metrics:
      receivers: [rabbitmq]
      exporters: [otlphttp/sluicio]

Mind the polling cost

Every collection hits the management API, which is not free on large clusters. Keep collection_interval at 10s or higher — 30s is plenty to catch a backlog forming, and it keeps load off the broker.

3 · Run the Collector

docker run --rm \
  -v "$(pwd)/otel-collector-config.yaml:/etc/otelcol-contrib/config.yaml" \
  -e RABBITMQ_MONITOR_PASSWORD \
  -e SLUICIO_INGEST_KEY \
  otel/opentelemetry-collector-contrib:latest

Within a collection interval or two, each queue shows up in Sluicio with live metrics.

4 · What the metrics mean

The receiver emits one set of metrics per queue, tagged with the queue, vhost, and node as resource attributes (rabbitmq.queue.name, rabbitmq.vhost.name, rabbitmq.node.name).

Metric	What it tells you
rabbitmq.message.current {state=ready}	Queue depth — messages waiting for a consumer. This is your backlog.
rabbitmq.message.current {state=unacknowledged}	Delivered but not yet acked — work currently in flight.
rabbitmq.consumer.count	How many consumers are attached to the queue.
rabbitmq.message.published	Source for the publish rate (messages in).
rabbitmq.message.delivered	Source for the delivery rate (messages out to consumers).
rabbitmq.message.acknowledged	Source for the throughput rate (work completed).
rabbitmq.message.dropped	Messages dropped — e.g. unroutable or no matching queue.

5 · Read consumer lag from the signals

There’s no single “lag” number — you read it from how the rates move together:

• Backlog growing: ready is trending up. Publishers are outrunning consumers.
• Falling behind: publish rate is consistently higher than the acknowledged rate.
• Stuck consumers: rabbitmq.consumer.count is 0 while ready > 0 — nothing is draining the queue at all.

In Sluicio, add a queue-depth panel grouped by rabbitmq.queue.name, and overlay publish vs. acknowledged rate to see the gap open up.

6 · Alert before the backlog hurts

Two alerts cover most cases:

• Sustained backlog — rabbitmq.message.current{state=ready} for a queue stays above your threshold for N minutes (e.g. > 1000 for 5 min). The duration matters: a brief spike during a burst is normal; a sustained climb is not.
• Stalled queue — rabbitmq.consumer.count == 0 while ready > 0. This catches a crashed or disconnected consumer immediately, before depth even has time to grow.

Name your queues for humans

The queue name becomes the facet you filter, group, and alert on in Sluicio. orders.inbound reads better on a 3am page than q.7f3a.

Where to go next

• Monitor ActiveMQ Artemis queue depth and dead-letter growth — the same idea for Artemis.
• Monitor a file-drop integration (hot folder) — backlog monitoring for file-based flows.
• Instrument a service — add traces to the consumer so a slow queue links to the slow code.