> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cloudthinker.io/llms.txt
> Use this file to discover all available pages before exploring further.

# 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](/guide/agents/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:
  ```bash theme={null}
  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.

<Info>
  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](#required-permissions).
</Info>

***

## Setup

<Steps>
  <Step title="Enable the management plugin">
    On a self-hosted broker, enable the management plugin and confirm it is listening:

    ```bash theme={null}
    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.
  </Step>

  <Step title="Create a monitoring user">
    Create a dedicated user for CloudThinker and tag it `monitoring`:

    ```bash theme={null}
    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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

<Warning>
  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.
</Warning>

***

## 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`     |

<Note>
  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.
</Note>

***

## 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).                               |

<Tip>
  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.
</Tip>

### 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](/guide/agents/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

```text theme={null}
@tony show RabbitMQ cluster status and list all queues with their current depths
```

### Example prompts

```text theme={null}
@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

<Accordion title="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`.
</Accordion>

<Accordion title="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.
</Accordion>

<Accordion title="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.
</Accordion>

<Accordion title="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**.
</Accordion>

<Accordion title="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> "" "" ".*"`.
</Accordion>

***

## 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

<CardGroup cols={2}>
  <Card title="Tony Agent" icon="database" href="/guide/agents/tony">
    Database-focused monitoring and optimization agent
  </Card>

  <Card title="Kafka Connection" icon="https://mintcdn.com/cloudthinker/aLd-ttc-SCW-aFky/images/icons/kafka.svg?fit=max&auto=format&n=aLd-ttc-SCW-aFky&q=85&s=f977ba21911cea4b67d99e55c7565058" href="/guide/connections/kafka" width="24" height="24" data-path="images/icons/kafka.svg">
    Setup instructions for Apache Kafka streaming
  </Card>
</CardGroup>