Модуль 2. Мониторинг RabbitMQ: очереди, alarms, flow — и что алертить

Цель модуля: видеть RabbitMQ по приборам: глубина и «занятость» очередей, потребители, alarms (память/диск) и flow control; как включить Prometheus- плагин, какой дашборд собрать и какие пять алертов ставить.

Перед началом: Модуль 1 (AMQP-модель, ack/prefetch, quorum), «Фундамент» (2.6), Docker. Стенд: make up (кластер ×3), make up-obs (+ Prometheus; метрики — встроенный плагин). Трудоёмкость: ~8–10 ч (теория 4 ч · практика 4 ч · квиз 1 ч).

📖 2.1. Четыре группы метрик

1. Очереди (глубина и занятость). Три числа на очередь, которые отвечают на все вопросы «где мои сообщения»:

• messages_ready — лежат и ждут потребителя;
• messages_unacknowledged — отданы потребителю и «держатся» до ack (prefetch в руках). Устойчивый рост = потребители берут, но не подтверждают;
• consumers — сколько подписчиков. Ноль у очереди с трафиком — воркеры умерли, самая частая причина «очередь стоит».

Сумма ready+unacked = messages. Нормальный паттерн: обе величины колеблются около нуля; плохо — когда растёт одна из них (готовые: потребителей мало/медленные; unacked: обработка длиннее prefetch-окна или потребитель умер, не закрыв соединение).

2. Поток: publish/deliver/ack rate по очередям и exchange'ам — «вход против выхода». Разрыв = рост глубины;deliver упал при живом publish = потребители отвалились.

3. Узлы и ресурсы: память (node_mem_used), файловые дескрипторы, сокеты, соединения/каналы. RabbitMQ сам охраняет ресурсы через alarms — и это меняет поведение кластера (§2.2), поэтому алармы метрики первичные.

4. Кластер: живые узлы, quorum-очереди с живым кворумом (rabbitmq_queue_mirror_state/quorum-статусы), patitions (rabbitmq_node_partition_detected).

📖 2.2. Alarms: как RabbitMQ спасает себя (и что при этом ломается)

Два встроенных предохранителя:

• memory alarm — vm_memory_high_watermark (по умолчанию 40 % RAM узла): узел перестаёт публиковать (blocking publishers), пока память не опустеет;
• disk alarm — disk_free_limit (по умолчанию 50 МБ): то же самое при нехватке диска.

Ключевая деталь, которую все пропускают: alarm на одном узле блокирует публикацию на весь кластер — издатели подключены к любому узлу, а кластер синхронизирует состояние alarm'а. Поэтому «продюсеры встали, а у нас всё зелёное» почти всегда = чей-то alarm на соседнем узле.

bash
rabbitmqctl status | grep -A3 alarms
rabbitmq-diagnostics alarms          # список активных

Метрики Prometheus: rabbitmq_node_mem_alarm, rabbitmq_node_disk_alarm (1 = активен) — алерт ставится на любое значение 1 дольше минуты.

📖 2.3. Prometheus-плагин и как снять метрики

RabbitMQ поставляется с плагином rabbitmq_prometheus — отдельный порт 15692 (/metrics), management UI при этом на 15672:

bash
docker compose exec rabbit1 rabbitmq-plugins enable rabbitmq_prometheus
curl -s localhost:15692/metrics | grep rabbitmq_queue_messages

В стенде курса плагин включён заранее, Prometheus скрейпит все три узла (make up-obs). Основные метрики (имена — как в плагине):

Management API (15672, /api/queues) удобен для разовых разборов (eye-balling), но мониторинг строится на 15692 — метрики уже Prometheus-формата и без авторизации в стендовой сети.

📖 2.4. Дашборд: восемь панелей

Порядок — как в курсах Kafka/Redis: сначала «наша очередь», потом сервер:

1. Ready по очередям (топ-5): где скопилось;
2. Unacked по очередям: кто держит и не подтверждает;
3. Consumers по очередям: нули всплывают мгновенно;
4. Publish vs deliver rate: вход против выхода;
5. Alarms (mem/disk) по узлам: любые единицы;
6. Соединения/каналы: общее число + churn;
7. Ресурсы узлов: память, fd, сокеты;
8. Кластер: узлы живы, patitions.

При «очередь стоит» порядок взгляда: 3 (consumers) → 2 (unacked) → 5 (alarms) → остальное.

📖 2.5. Пять алертов и два антипримера

Антипримеры: «messages > 0» (норма при живом трафике), «fd_used > 1000» без привязки к лимиту (смотрите долю fd_used/fd_total).

💻 Практика

1. Кластер + наблюдаемость: make up-obs — три узла, quorum-очередь make queue tasks; проверьте http://localhost:9090/targets.
2. Штатный контур: продюсер 200 msg/s, два воркера с prefetch 16 — все панели «здоровы»: ready ≈ 0, unacked ≈ 0–32, consumers = 2.
3. Остановите воркеров: consumers → 0, ready растёт линейно — алерт №1 срабатывает на глазах.
4. «Мёртвый хват»: воркер получает сообщения (unacked растёт) и зависает (не ack, соединение живо) — unacked упирается в prefetch; сравните с убитым воркером (соединение закрыто → ready отдаётся живым, redelivery). Это два разных инцидента — и два разных алерта.
5. Memory alarm (демо): make mem-alarm (порог воды занижен на rabbit1) → alarm=1 на узле, publish встал на всём кластере — самый контринтуитивный эксперимент модуля. Вернуть: make mem-alarm-off.
6. Алерты: соберите пятёрку §2.5 в config/alerts.yml, каждый проверьте шагами 3–5.

Артефакт: config/alerts.yml + скриншоты трёх экспериментов (no consumers, мёртвый хват, alarm).

🧩 Quiz "Проверь себя"

✅ Итоги модуля

🔗 Мостик к Модулю 3

Приборы стоят. Дальше — инциденты в момент боли: memory alarm под нагрузкой, шторм соединений и каналов, «мёртвый хват» unacked, flow control и blocked publishers, poison-циклы через DLX — каждый разбор воспроизводится на кластере, а закроет курс модуль про Streams и multi-DC (shovel/federation).