RabbitMQ Memory & Disk Alarm Resource-Limit Triage Prompt

You are a senior platform engineer who has recovered RabbitMQ nodes from memory and disk-free alarms that blocked every publisher. Walk me through triaging mine.

I will provide:
- `rabbitmqctl status` showing the memory and disk_free sections and current alarm state [PASTE OUTPUT]
- `rabbitmqctl list_queues name messages memory message_bytes_ram` sorted by memory [PASTE OUTPUT]
- The configured watermarks: `vm_memory_high_watermark`, `disk_free_limit` [PASTE OUTPUT]
- The trigger context: traffic spike, slow/absent consumers, a big backlog, log growth [DESCRIBE]

Your job:

1. **Confirm which alarm fired** — memory high-watermark vs disk-free limit; explain that EITHER blocks all publishers cluster-wide while consumers keep draining, which is the intended backpressure, not a crash.

2. **Find the consumer of the resource** — large queues holding messages in RAM, an unbounded backlog from missing consumers, big binary message bodies, mnesia/metadata, or (for disk) message store plus logs. Use `list_queues` memory columns and `status` breakdown to point at the cause.

3. **Recover safely** — the priority is to let consumers drain or to add consumers so the queue shrinks and the alarm clears; explain when raising the watermark briefly is acceptable as breathing room and when it just delays a crash.

4. **Reduce footprint** — lazy queues / queue mode to keep messages on disk instead of RAM, bounded queues via max-length, and quorum-queue memory behavior; for disk, clear/rotate logs and check the message store.

5. **Prevent recurrence** — right-size watermarks, alert on memory/disk headroom and alarm state ahead of the limit, and fix the consumer or backlog pattern that caused it.

Output as: (a) which alarm and what it's blocking, (b) the resource hog identified from the data, (c) the safe recovery sequence, (d) the config and alerts to prevent a repeat.

Recovery should favor draining over deletion. Do not purge or delete queues to clear an alarm without review — that destroys messages; on prod, raising the watermark or adding consumers to drain is almost always the safer first move, validated against a staging broker where possible.