Модуль 31

Моніторинг та метрики RabbitMQ

Ось урок, створений спеціально для тебе у стилі David Malan. Вмикай уяву, ми починаємо!

🎓 Урок: Моніторинг та метрики RabbitMQ

Або: Як не розбитись, керуючи літаком із зав’язаними очима

Привіт, друзі! Радий бачити вас знову.

1. 🔥 Вступ: Чому це питання життя і смерті вашого проєкту?

Уявіть собі ситуацію. Ви — головний інженер в аеропорту (або, якщо хочете, на жвавій кухні McDonald’s у розпал обіду).

Потоки літаків (або замовлень на бургери) летять з шаленою швидкістю. RabbitMQ — це ваш диспетчер. Він приймає повідомлення і розкидає їх по чергах. Все працює ідеально... або так вам здається.

Раптом — тиша. Користувачі скаржаться, що їхні замовлення не обробляються. Ви дивитесь на сервер — він наче працює. Процес запущений. Але що відбувається всередині?

  • Чи забиті черги до стелі?
  • Чи померли всі ваші консюмери (обробники)?
  • Чи, може, у RabbitMQ закінчилася оперативна пам'ять і він просто "завмер"?

Риторичне запитання: Чи погодилися б ви вести машину по трасі вночі, якби вам заклеїли лобове скло чорною плівкою і вимкнули приладову панель? Думаю, ні.

Без моніторингу RabbitMQ — це і є водіння всліпу. Сьогодні ми знімемо цю плівку. Ми навчимося бачити "пульс" нашої системи, щоб виправляти проблеми ще до того, як клієнт натисне кнопку "Написати скаргу".

2. 🧠 Теоретична база: Що ми шукаємо?

Давайте не ускладнювати. RabbitMQ — складний звір, написаний на Erlang, але нам не потрібно знати все про віртуальну машину Erlang, щоб зрозуміти, чи "здоровий" наш брокер.

Нам потрібна спостережуваність (Observability).

Ось "Свята Трійця" метрик RabbitMQ, яку ви маєте розуміти інтуїтивно (запам'ятайте це!):

1. Довжина черги (Queue Depth / Length)

Це кількість повідомлень, які лежать у черзі й чекають. * Аналогія: Черга людей на касу в супермаркеті. * Норма: Черга коротка або швидко рухається. * Проблема: Якщо черга постійно росте і не зменшується — ваші касири (консюмери) не справляються. Потрібно відкривати нову касу!

2. Кількість консюмерів (Consumer Count)

Скільки програм зараз підключено і готово працювати. * Аналогія: Кількість касирів на зміні. * Проблема: Якщо тут "0" — це катастрофа. Черга ростиме нескінченно, бо нікому працювати.

3. Швидкість публікації та обробки (Publish / Acknowledge Rates)

  • Publish Rate: Як швидко вода ллється в ванну.
  • Ack (Acknowledge) Rate: Як швидко вода витікає через злив.
  • Інтуїція: Якщо Publish Rate > Ack Rate протягом довгого часу... ну, ви зрозуміли. Ванна переповниться (пам'ять закінчиться).

Інструменти (Як на це дивитись?)

Не треба лізти в логи руками. У нас є: 1. Management Plugin: Вбудована веб-адмінка RabbitMQ (красиві графіки "з коробки"). 2. HTTP API: Щоб отримувати цифри програмно. 3. Prometheus + Grafana: Індустріальний стандарт. RabbitMQ віддає метрики, Prometheus їх збирає, Grafana малює красиві дашборди.

3. 🧪 Приклади: Від простого до реального

Приклад 1: "Вмикаємо світло" (Management Plugin)

За замовчуванням RabbitMQ — це чорна скринька. Давайте увімкнемо UI.

# Якщо ви використовуєте Docker, зазвичай це вже увімкнено в тегу: management
docker run -d --name rabbitmq -p 15672:15672 -p 5672:5672 rabbitmq:3-management

Тепер, якщо ви зайдете на http://localhost:15672 (логін/пароль: guest/guest), ви побачите Dashboard.

Що ви очікуєте там побачити, якщо система простоює? Правильно: Нулі. Рівні лінії. Тиша.

Приклад 2: Симуляція проблеми (The Spike)

Уявіть, що ми відправили 10 000 повідомлень, але не запустили жодного консюмера.

Код продюсера (Python/Pika - спрощено):

# Відправляємо 10 000 завдань
for i in range(10000):
    channel.basic_publish(exchange='', routing_key='task_queue', body=f'Task {i}')

Погляд на моніторинг: 1. Заходимо в вкладку Queues. 2. Бачимо стовпчик Ready: 10,000. 3. Стовпчик Unacked: 0 (бо ніхто не взяв їх в роботу). 4. Графік Queue depth різко пішов вгору.

Це сигнал тривоги! Повідомлення накопичуються, пам'ять витрачається.

Приклад 3: "Завислий" воркер (Unacked Messages)

Це підступна ситуація. У вас є воркер, він взяв повідомлення, але... "заснув" (завис, впав в infinite loop) і не надіслав підтвердження (ack).

Що покаже моніторинг? * Ready: 0 (черга ніби пуста). * Unacked: 50 (наприклад, prefetch_count був 50). * Total: 50.

Чому це важливо? Для RabbitMQ ці повідомлення "в обробці". Він не віддасть їх іншим воркерам. Якщо воркер так і не "прокинеться", ці 50 завдань заморожені навічно, поки з'єднання не розірветься.

4. 🛠 Практична частина

Час забруднити руки! Виконайте ці завдання, щоб відчути себе інженером.

Завдання 1: Hello Admin * Запустіть RabbitMQ з плагіном management (через Docker або локально). * Зайдіть у веб-інтерфейс. Знайдіть графік "Message rates". * Мета: Переконатися, що ви маєте доступ до "приладової панелі".

Завдання 2: Створити затор * Створіть чергу test_monitoring. * Напишіть скрипт, який відправляє 1000 повідомлень у цю чергу. * Не запускайте консюмера. * Подивіться на графік у розділі Queues. Запишіть значення поля Messages Ready.

Завдання 3: API розвідка * Замість веб-інтерфейсу, використайте curl або браузер, щоб отримати JSON з даними про черги. * URL: http://localhost:15672/api/queues * Питання: Знайдіть у цьому JSON поле messages (загальна кількість) та messages_ready.

Завдання 4: Міні-кейс "Детектив" * Ви бачите на графіку, що кількість повідомлень Unacked росте синхронно з кількістю Consumers. * Але кількість Ready (повідомлень, що чекають) не зменшується так швидко, як хотілося б. * Діагноз? Ваші консюмери беруть задачі, але обробляють їх дуже повільно. Система "захлинається". * Рішення? (Подумайте самі: додати більше консюмерів чи оптимізувати код обробки?)

Завдання 5: А що, якщо диск переповнений? (High Level) * Знайдіть у веб-інтерфейсі вкладку Overview -> Nodes. * Подивіться на Disk space low watermark. * Питання: Що зробить RabbitMQ, якщо вільне місце на диску впаде нижче цієї позначки? (Підказка: він перестане приймати нові повідомлення — заблокує продюсерів). Це називається Backpressure.

5. 💡 Мислення як у розробника

Як відрізнити новачка від профі в моніторингу?

Типові помилки новачків:

  1. "Я подивлюся, коли зламається".
    • Ні. Коли зламається, дивитися буде пізно, треба буде гасити пожежу.
  2. Дивитися тільки на Total Messages.
    • Total = Ready + Unacked. Якщо у вас 1000 Unacked, то черга ніби зайнята, але робота стоїть, якщо воркери зависли. Завжди розділяйте ці поняття.
  3. Ігнорування "заліза".
    • RabbitMQ дуже чутливий до RAM. Якщо пам'ять закінчується, він починає скидати повідомлення на диск (paging), і швидкість падає в 10-100 разів.

Як думає Senior Engineer:

  • Alerting (Сповіщення) > Monitoring (Спостереження).
    • Я не хочу сидіти і дивитися на графіки цілий день. Я хочу, щоб система надіслала мені повідомлення в Slack/Telegram, якщо:
      • Queue Length > 1000 протягом 5 хвилин.
      • Consumer Count < 1 (всі померли).
  • Тренди важливіші за миттєві значення.
    • Стрибок черги до 500 — це нормально, якщо через хвилину він падає до 0. Якщо він росте на 10 повідомлень щохвилини годинами — це проблема.

Порада з практики: Налаштуйте RabbitMQ Prometheus Plugin і виводьте графіки в Grafana. Це дасть вам історичні дані. Ви зможете сказати: "Ага, щоп'ятниці о 18:00 у нас пікове навантаження, треба автоскейлінг".

6. 🧩 Підсумок

Отже, друзі, що ми маємо?

Сьогодні ми перетворили RabbitMQ з "чорної скриньки" на прозорий механізм. Тепер ви знаєте: 1. Що Queue Depth показує, чи справляємося ми з навантаженням. 2. Що Unacked Messages можуть свідчити про завислі воркери. 3. Що без моніторингу ми просто гадаємо на кавовій гущі.

Тепер ви не просто "відправляєте повідомлення". Ви керуєте потоками даних.

Тизер наступного уроку: Але стривайте... Ми весь час говорили про один сервер RabbitMQ. А що, якщо цей сервер... згорить? Фізично? Невже всі наші черги зникнуть разом з ним? На наступному занятті ми поговоримо про Кластеризацію та Високу Доступність (High Availability). Ми зробимо так, щоб наша система вижила навіть після ядерного вибуху в дата-центрі (ну, майже).

Це був CS50... тобто, наш курс по RabbitMQ. До зустрічі!

← До списку уроків Наступний урок →