RabbitMQ sits between applications as a message broker, and problems there tend to show up as symptoms elsewhere (a background job that never runs, a queue that quietly backs up) long before the broker itself looks unhealthy. Monitoring it directly closes that gap.
Enabling the management API
RabbitMQ's management plugin exposes a REST API with detailed broker metrics.
- Enable the RabbitMQ management plugin if it isn't already active.
- Create a monitoring-specific user with read-only permissions for iPM to authenticate as, rather than reusing an administrative account.
- Restrict access to the management port to trusted hosts, including the iPM server.
- Configure the RabbitMQ service check in iPM to use the management API with those credentials.
What you can monitor
- Process / port — is the RabbitMQ broker running and accepting connections
- Queue depth — how many messages are waiting in each queue; a queue that grows continuously usually means consumers have stopped processing, not that producers are simply busy
- Consumer count — whether a queue has active consumers attached at all; a queue with zero consumers is often the actual root cause behind a "messages aren't being processed" report
- Memory and disk alarms — RabbitMQ throttles or blocks publishers when it hits configured memory or disk thresholds, which is worth alerting on before it happens, not after
- Node health — for clustered deployments, whether all expected nodes are up and part of the cluster
Reading a growing queue correctly
A queue depth that's rising isn't automatically a problem — it may just mean a burst of messages arrived. What matters is the combination: rising depth with zero or falling consumers is a real problem, while rising depth with active, keeping-pace consumers is often just normal load. Alert on the combination where possible, rather than on queue depth alone.