RabbitMQ Local monitoring

Full description

RabbitMQ Local monitoring collects the state of a RabbitMQ cluster and turns it into Pandora FMS modules. On every execution it queries the broker management HTTP API and reports the cluster overview, the resources and status of each node, exchange activity, connection state and an availability check.

At cluster level the addon reports the cluster name, total queue messages, unacknowledged messages, total exchanges and the publish, deliver-get and deliver-noack rates. At node level it reports, for every node in the cluster, memory used and memory rate, Erlang processes used and their rate, and whether the node is running. At exchange level it reports the publish-in and publish-out rates of the last exchange that reports activity. At connection level it reports open, running and blocked connections, together with the received and sent octet rates. The availability module reports whether the management API overview request succeeds.

The addon runs as a Pandora FMS server plugin or as an agent plugin, and both modes generate the same module catalog. It is designed for RabbitMQ deployments where cluster health, node resource consumption and messaging activity must be reviewed next to the rest of the infrastructure. It is a monitoring integration: it reports state and metrics, and it does not change the configuration or the state of the broker, its nodes or its queues.

What it allows you to do

- Monitor the cluster overview, queue totals and message rates from a single addon.
- Track memory and Erlang process usage for every node in the cluster.
- Track whether each node is running.
- Track exchange publish-in and publish-out activity.
- Track open, running and blocked connections and the received and sent octet rates.
- Check whether the management API is available.

What it monitors

- Cluster overview: cluster name, queue totals, unacknowledged messages, exchange count and cluster rates.
- Node resources: memory used and Erlang process usage per node.
- Node status: whether each cluster node is running.
- Exchange activity: publish-in and publish-out rates.
- Connections: open, running and blocked connections plus received and sent octet rates.
- Availability: whether the management API overview request succeeds.

How it works

- The addon queries the RabbitMQ management HTTP API and converts the response into Pandora FMS modules.
- It generates cluster, node, exchange, connection and availability modules in the same run.
- It runs as a Pandora FMS server plugin or as an agent plugin; both modes generate the same module catalog.

Benefits

- Consolidated visibility: cluster, node, exchange and connection state are reviewed in the same Pandora FMS environment as the rest of the infrastructure.
- Per-node coverage: node modules are generated for every node in the cluster, so coverage follows cluster membership.
- Earlier recognition of documented conditions: dedicated availability and node status modules expose an unreachable management API or a stopped node.
- Lower scope-maintenance effort: one addon covers the whole cluster instead of a separate definition per node or exchange.

Use cases

- Messaging platform teams that need cluster health and resource usage in one place.
- Operations teams that need to know when a node stops or connections become blocked.
- Environments with multi-node RabbitMQ clusters where per-node visibility matters.
- Teams that review RabbitMQ health next to the rest of the infrastructure in Pandora FMS.

Requirements

- A RabbitMQ broker with the management plugin enabled.
- A RabbitMQ account allowed to query the management API.
- Network access from the environment executing the addon to the management API, over HTTP or HTTPS.
- A Pandora FMS installation to receive the modules.

Compatibility

- Validated on Rocky Linux 9 against RabbitMQ 3.13.7 with the management plugin enabled.
- Compatible with Pandora FMS NG 784 and later versions.

Limitations

- When the management API overview request fails, availability reports 0, node modules are omitted and exchange and connection modules report 0.
- Exchange activity is reported as a single publish-in and publish-out pair for the last exchange that reports activity, not as per-exchange modules.