RabbitMQ

Connect RabbitMQ to CloudThinker via the Management HTTP API for queue depth, consumer lag, DLQ analysis, cluster and node health, and alarm monitoring

Connect your RabbitMQ brokers to enable Tony (Database Engineer) to monitor queue depths, analyze consumer lag, inspect dead-letter queues, and track cluster and node health.

RabbitMQ authenticates with a username and password over the Management HTTP API (default port 15672) — the same API the RabbitMQ management UI uses, so no AMQP client setup is required.

---

Supported platforms

Platform	Support
Self-hosted RabbitMQ	3.8+ with the management plugin enabled
Managed RabbitMQ	CloudAMQP and other providers exposing the Management HTTP API

---

Prerequisites

• A RabbitMQ broker reachable from CloudThinker on its management port (default 15672, or 15671 for HTTPS).
• The management plugin enabled. On self-hosted brokers:
  rabbitmq-plugins enable rabbitmq_management
  
• A broker user with the monitoring or administrator tag, so the Management HTTP API returns queue, node, and cluster data.

The monitoring tag is enough for all read and health-check capabilities. Only grant administrator if you want the agent to run the gated write operations (purge/delete queues, delete exchanges, update definitions) — these always require in-app approval. See Required permissions.

---

Setup

1. Enable the management plugin

   On a self-hosted broker, enable the management plugin and confirm it is listening:

   rabbitmq-plugins enable rabbitmq_management
   curl -u <user>:<password> http://localhost:15672/api/overview
   

   Managed providers such as CloudAMQP expose the Management HTTP API by default — skip to the next step.

2. Create a monitoring user

   Create a dedicated user for CloudThinker and tag it monitoring:

   rabbitmqctl add_user cloudthinker <strong-password>
   rabbitmqctl set_user_tags cloudthinker monitoring
   rabbitmqctl set_permissions -p / cloudthinker "" "" ".*"
   

   The monitoring tag grants read access to all queues, exchanges, nodes, and cluster health across virtual hosts.

3. Confirm network access

   Ensure CloudThinker can reach the broker at <host>:15672 (or <host>:15671 for TLS). Open the management port on your firewall or security group for CloudThinker’s egress.

4. Add connection in CloudThinker

   Navigate to Connections → RabbitMQ and enter:

   • Username: the broker user (e.g. cloudthinker)
   • Password: the user’s password
   • Host: the broker hostname or IP (host only — no scheme or port)
   • Management Port: the management API port (default 15672)
   • Use TLS: enable for an HTTPS management API and AMQPS
   • Log Level: connector log verbosity (info by default)

   Click Connect. CloudThinker verifies the credentials against the Management HTTP API and shows a Connected status.

Set Host to the hostname only — do not include http://, https://, or the port. Use the Use TLS toggle to select HTTP vs. HTTPS, and Management Port for the port.

---

Connection details

Field	Description	Default
RABBITMQ_USERNAME	Broker user with the monitoring or administrator tag	—
RABBITMQ_PASSWORD	Password for the broker user	—
RABBITMQ_HOST	Broker hostname or IP (no scheme, no port)	—
RABBITMQ_MANAGEMENT_PORT	Management HTTP API port	15672
RABBITMQ_USE_TLS	Disabled for HTTP + AMQP, Enabled for HTTPS + AMQPS	Disabled
LOG_LEVEL	Connector log verbosity: debug, info, warn, error	info

The management API listens on 15672 for HTTP and 15671 for HTTPS. When you enable Use TLS, set Management Port to your TLS management port.

---

Required permissions

The connecting user needs a management tag so the HTTP API returns broker data:

Tag	What it unlocks
monitoring	Read access to queues, exchanges, bindings, connections, channels, nodes, cluster, and health checks — covers all monitoring and diagnostic capabilities.
administrator	Everything monitoring provides, plus the gated write operations (purge/delete queue, delete exchange, update definition).

Follow least privilege: the monitoring tag is enough for queue, consumer-lag, DLQ, and cluster-health investigation. Only use administrator if you intend to run the gated write operations described below.

Write operations require approval

This connection has four mutative tools enabled. They are always gated behind in-app approval — the agent must request your confirmation before any of them run:

• delete_queue — delete a queue
• purge_queue — drop all messages in a queue
• delete_exchange — delete an exchange
• update_definition — modify broker definitions

All other capabilities are read-only. Destructive operations also require the broker user to hold the administrator tag with write permissions on the target virtual host.

---

Agent capabilities

Once connected, Tony can:

Capability	Description
Queue depth & message rates	Snapshot queue depth, ready vs. unacked, and publish/deliver rates
Consumer lag	Identify queues with high consumer lag or zero consumers
Dead-letter analysis	Inspect dead-letter queues for poison messages and error patterns
Cluster & node health	Check node status, local and global alarms, and quorum-critical queues
Alarm & certificate checks	Detect brokers in alarm and certificates nearing expiration
Gated write operations	Purge or delete queues, delete exchanges, and update definitions — each requires in-app approval

Verify the connection

@tony show RabbitMQ cluster status and list all queues with their current depths

Example prompts

@tony check all queues for abnormal depth or zero-consumer conditions and #alert on any queue growing faster than 500 msg/s
@tony identify queues with high consumer lag and inspect their dead-letter queues for poison messages, then #recommend remediation steps
@tony check cluster node status, alarms, quorum-critical queues, and certificate expiration; #alert on any node down or in alarm

---

Troubleshooting

Connection refused or timeout

• Verify the broker is reachable from CloudThinker at <host>:15672 (or your TLS management port).
• Confirm the management port — not the AMQP port 5672 — is open on your firewall or security group.
• For self-hosted brokers, ensure RabbitMQ is bound to an accessible interface, not just 127.0.0.1.

404 Not Found on the management API

The management plugin is not enabled. Run rabbitmq-plugins enable rabbitmq_management and retry. On managed providers, confirm the Management HTTP API is exposed for your instance.

401 Unauthorized

• Verify the username and password.
• Confirm the user has the monitoring or administrator tag: rabbitmqctl set_user_tags <user> monitoring.
• A user with no management tag can authenticate to AMQP but is rejected by the Management HTTP API.

TLS handshake or certificate errors

• Make sure Use TLS matches the broker: enable it only when the management API serves HTTPS (typically port 15671).
• If Use TLS is enabled but the port serves plain HTTP (or vice versa), the connection fails — align the toggle and Management Port.

Empty or partial results

• The monitoring user may lack permissions on some virtual hosts. Grant read permissions on the vhosts you want visible: rabbitmqctl set_permissions -p <vhost> <user> "" "" ".*".

---

Security

• Least privilege — grant only the permissions the agents need for your use case; start read-only and widen later.
• Read-only by default — use read-only credentials unless you want agents to make changes through this connection.
• Rotate credentials — rotate keys and tokens on your normal schedule; CloudThinker picks up the new value when you update the connection.
• Revoke on offboarding — remove the credential at the provider when you delete a connection or a teammate leaves.

• Dedicated user — create a separate cloudthinker broker user; never reuse the guest or admin account
• TLS in transit — enable Use TLS so management API traffic is encrypted between CloudThinker and the broker

---

Related

Tony Agent

Database-focused monitoring and optimization agent

Kafka Connection

Setup instructions for Apache Kafka streaming