RabbitMQ Queue Backpressure & Flow-Control Triage Prompt

You are a senior platform engineer who has triaged many RabbitMQ backpressure incidents where queues grow without bound and publishers stall. Walk me through diagnosing mine.

I will provide:
- `rabbitmqctl list_queues name messages messages_ready messages_unacknowledged consumers consumer_utilisation` [PASTE OUTPUT]
- Connection state showing flow control: `rabbitmqctl list_connections name state` and channel `list_channels` [PASTE OUTPUT]
- Any resource alarms: `rabbitmqctl status` memory/disk alarm section, and `list_queues memory` [PASTE OUTPUT]
- Symptoms: publishers slow/blocked, growing queue depth, rising latency [DESCRIBE]

Your job:

1. **Locate the bottleneck** — separate "queue growing because consumers are slow/absent" (high `messages_ready`, low `consumer_utilisation`) from "broker is throttling producers" (connections in `flow` state) from "a memory or disk alarm has blocked all publishers."

2. **Read the signals correctly** — explain `messages_ready` vs `messages_unacknowledged` (unacked = consumers holding too much via prefetch), `consumer_utilisation` near 1.0 meaning consumers are the limit, and connection `flow` state meaning internal credit-based flow control is engaged.

3. **Trace causes** — slow downstream dependency, too few consumers, prefetch too low (consumers idle waiting) or too high (one consumer hoards), large unacked backlog from a stuck consumer, or memory/disk watermark crossed.

4. **Recommend fixes** — scale or speed consumers, tune prefetch/QoS, add a lazy queue or set a max-length with overflow policy, fix the resource alarm, or apply backpressure deliberately at the producer with publisher confirms.

5. **Prevent recurrence** — what to alert on (queue depth trend, `messages_unacknowledged`, connections in flow, alarm state) so this is caught before publishers block.

Output as: (a) the diagnosed bottleneck with the specific metric that proves it, (b) immediate mitigation, (c) root-cause fix, (d) the alerts to add.

Validate any queue-policy or prefetch change on a staging broker before prod. Do not purge a backed-up queue to "relieve pressure" without review — purging discards real messages and hides the actual cause.