Monitor a Minimum Number of Consumers on a RabbitMQ Queue
This JSON sensor checks that a RabbitMQ queue has at least one active consumer by querying the Management API and evaluating the length of the consumer_details array.
Purpose
Ensure that a specific RabbitMQ queue always has at least one active consumer. This allows early detection of service disruption or worker failure in queue-based architectures.
Use Case Example
In a distributed system using RabbitMQ, certain queues must always be consumed by at least one worker. If no consumer is present, messages will pile up, possibly leading to delays, data loss, or system instability. This check ensures that a queue has one or more consumers at all times.
Configuration Overview
Prerequisites
The RabbitMQ management plugin must be enabled for this to work.
| Field | Value |
|---|---|
| Verb | GET |
| Url | http://<rabbitmq_host>:15672/api/queues/<virtual_host>/<queue_name> |
| JsonPath | $.consumer_details |
| Condition | Array length more than |
| Check value type | Int |
| Value to check | 0 |
| Recursion | 1 min |
| Timeout | 15000 ms |
| Http codes accepted | 2xx |
| Auth type | Basic |
| Username / Password | <user> / <password> (secured password) |
This configuration queries the RabbitMQ Management API every minute and checks that the consumer_details array in the response contains more than 0 entries.
Explanation of Key Fields
- JsonPath (
$.consumer_details): This targets the field that lists all consumers attached to the queue. - Condition (
Array length more than 0): Ensures the array is not empty, indicating that at least one consumer is active. - HTTP Basic Auth: Used to authenticate with the RabbitMQ Management API. The credentials should be kept secure and only granted minimal required permissions.
- Timeout (15000 ms): Allows for up to 15 seconds to receive a response, which is reasonable for internal networks.
- Recursion (1 min): Ensures frequent monitoring, allowing quick reaction to consumer disconnection.
- Accepted HTTP codes (
2xx): Covers successful responses and redirections.
Good Practices
- Use read-only users for API monitoring to minimize security risks.
- Keep the polling interval tight (1 minute is a good default) to quickly detect issues.
- Test your sensor with the queue stopped or paused to verify alerting.
- Avoid exposing management APIs to public networks; use VPNs or private subnets.
To Go Further
- Monitor message count in addition to consumer count to detect accumulating backlogs.
- Track consumer details such as IPs or node names for advanced diagnosis.