RabbitMQ Management API Automation Prompt
Build safe automation against the RabbitMQ HTTP management API — health checks, queue audits, and bulk operations — without hammering the broker or hard-coding fragile assumptions.
- Target user
- Platform and SRE engineers automating RabbitMQ operations
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior platform engineer who automates RabbitMQ operations through the HTTP management API. Help me build a script that's safe to run against production. I will provide: - The task: health check, queue/connection audit, bulk policy apply, or definitions sync [DESCRIBE] - My environment: cluster size, broker version, the management endpoint, and how I authenticate (basic auth user, token) [DESCRIBE] - Scale: how many queues/connections/vhosts the API will enumerate [DESCRIBE] - Where this runs: cron, CI, an alerting probe, or ad hoc [DESCRIBE] Your job: 1. **Pick the right endpoint** — choose between `/api/healthchecks/...`, `/api/queues`, `/api/aliveness-test/<vhost>`, and the lighter `/api/health/checks/...` endpoints. Flag that `/api/queues` is expensive on large clusters because it computes per-queue stats; prefer column filtering and pagination where supported. 2. **Rate and load awareness** — explain that the management API runs on a node and can load the broker if polled aggressively or fanned across many queues. Recommend a polling interval, column reduction (`?columns=name,messages,state`), and avoiding full enumerations in tight loops. 3. **Auth and least privilege** — use a dedicated monitoring user with the `monitoring` tag (read-only stats) rather than an admin, and keep credentials out of the script. 4. **Idempotent writes** — for bulk operations (apply policy, create user, import definitions), make the script safe to re-run: check current state before writing, and use PUT semantics that are idempotent. 5. **Validate** — dry-run mode that prints intended changes, plus a verification read after each write to confirm it took. Output as: (a) the chosen endpoints with why, (b) the script skeleton with column filtering and a polling interval, (c) the least-privilege user setup, (d) a dry-run/verify pattern for any writes. Test the script against a staging broker first, and run writes in dry-run mode before applying. The management API can add meaningful load — confirm your polling interval and column filters don't degrade the broker under production queue counts.
Why this prompt works
The HTTP management API is the obvious automation surface for RabbitMQ, and it’s also the easiest way to accidentally load the broker you’re trying to monitor. The endpoints look uniform but cost wildly different amounts: /api/aliveness-test is cheap, while /api/queues recomputes per-queue stats and gets expensive fast on a cluster with thousands of queues. This prompt’s first move is endpoint selection by cost, which is the difference between a monitoring probe that’s invisible and one that shows up in the broker’s own CPU graphs.
The rate-awareness and column-filtering guidance targets the most common self-inflicted incident: a health check or audit script that fans across every queue every few seconds and quietly degrades the node it runs on. By pushing ?columns= reduction, conservative intervals, and a ban on tight-loop full enumerations, the prompt keeps automation from becoming the load it’s meant to detect.
For write operations, the prompt insists on least privilege and idempotency. A dedicated monitoring-tagged read-only user keeps stats collection from carrying admin rights, and the dry-run-then-verify pattern means bulk policy applies and definitions syncs are safe to re-run and auditable. The staging guardrail ensures the polling cost is measured against real queue counts before it ever touches production.