RabbitMQ

RabbitMQ is an open-source message broker — the queueing backbone of countless integration landscapes. It fails in two distinct ways: queues back up when consumers fall behind, and the broker itself throttles when a resource alarm (memory, disk, file descriptors) trips and RabbitMQ starts blocking publishers. This system type watches both.

Key: rabbitmq · applied automatically to services emitting rabbitmq-prefixed metrics.

Getting the telemetry

Two sources together give full coverage — the OTel Collector’s rabbitmq receiver reads per-queue metrics from the management API, and RabbitMQ’s own rabbitmq_prometheus plugin exposes the node-level alarm metrics, scraped with the prometheus receiver:

otel-collector-config.yaml (receivers)

receivers:
  # Per-queue depth and consumer counts, via the management API (:15672)
  rabbitmq:
    endpoint: http://rabbitmq:15672
    username: monitoring
    password: ${env:RABBITMQ_MONITOR_PASSWORD}
    collection_interval: 30s

  # Node-level alarms and disk headroom, via the prometheus plugin (:15692)
  prometheus/rabbitmq:
    config:
      scrape_configs:
        - job_name: rabbitmq-node
          scrape_interval: 30s
          static_configs:
            - targets: ["rabbitmq:15692"]

Both receivers ship in the contrib Collector distribution. The full walkthrough — management-plugin setup, a read-only monitoring user, the export pipeline to Sluicio — is in Track RabbitMQ queue depth.

What Sluicio detects

Metrics whose names start with rabbitmq — which covers both sources: the OTel receiver’s rabbitmq.message.current, rabbitmq.consumer.count, … and the prometheus plugin’s rabbitmq_alarms_*, rabbitmq_disk_space_available_bytes, ….

Starter checks

Check	Condition	Severity	Why it matters
Memory alarm	Memory resource alarm active (rabbitmq_alarms_memory_used_watermark > 0)	Critical	RabbitMQ blocks all publishers while the alarm is active — upstream systems stall immediately.
Disk alarm	Free-disk resource alarm active (rabbitmq_alarms_free_disk_space_watermark > 0)	Critical	Same publisher-blocking behaviour, triggered by disk instead of memory.
File-descriptor alarm	File-descriptor limit alarm active (rabbitmq_alarms_file_descriptor_limit > 0)	Critical	The broker can no longer accept connections or open files.
Queue backlog	More than 5,000 ready messages on a queue	Warning	Consumers aren’t keeping up; latency grows with every message that lands.
No consumers	A queue has messages but zero consumers	Warning	Nothing is draining the queue — usually a crashed or disconnected consumer.
Low free disk	Free disk below 2 GiB	Warning	Headroom warning before the disk alarm trips and starts blocking publishers.

Tuning notes

• Backlog threshold. 5,000 ready messages is a generic default. Set it per queue from your real drain rate — the right number is “more than the consumers clear in the time you’d want to react”, which might be 500 on a low-volume queue and 500,000 on a firehose.
• Low free disk. 2 GiB assumes a modest node. Raise it to comfortably exceed your configured disk_free_limit plus reaction time, so the warning arrives well before the critical alarm.
• No consumers can be normal for queues drained by batch jobs on a schedule. Add a duration (or disable the check) on those queues rather than living with the noise.
• The three alarm checks rarely need tuning — an active resource alarm is always an incident — but they depend on the prometheus plugin being scraped. If you run only the OTel receiver, they’ll simply never fire.