Моніторинг Kafka: де черги втрачають повідомлення
Відставання споживачів від потоку рідко виглядає як аварія: брокер приймає записи, метрика доступності зелена. Зміщення читача повільно від'їжджає від кінця журналу, і через кілька годин це вже години затримки.
Окремі розділи черги стоять без руху, частина повідомлень іде в необроблені й спливає за терміном зберігання — а дізнаєтеся ви про це зі скарг, а не із системи спостереження.
Причина в тому, що набір метрик зазвичай дивиться на брокер, а не на обробку. Середнє відставання по групі згладжує картину: один застряглий розділ із двадцяти дає скромну цифру у звіті, хоча саме в ньому накопичується непрочитане.
Моніторинг Kafka працює на рівні «споживач — розділ — зміщення», інакше зростання відставання залишається непоміченим до моменту, коли наздогнати потік уже не можна.
Тиха відмова обробки — найнеприємніший сценарій. Споживач продовжує читати й підтверджувати зміщення, але логіка падає на певному типі запису: частина повідомлень іде в гілку повторів, частина відкидається без сліду.
Зовні сервіс працює, а дані втрачаються там, де їх ніхто не рахує. Втрата повідомлень перестає бути помітною, якщо немає звірки кількості записаних і оброблених подій за кожним розділом.
Тому спостереження будуємо навколо того, що можна порахувати: відставання в одиницях часу, а не лише в кількості записів, власні пороги для розділів із різним навантаженням, сигнали на простій розділу й на розбіжність лічильників, трасування шляху від джерела до результату.
Тоді зростання відставання видно за хвилини, застряглі розділи не маскуються середнім, а необроблені повідомлення розбираються до спливу терміну зберігання.
Що дає наскрізний контроль черг повідомлень
Наскрізний контроль черг збирає в одну картину сервіси-видавці, брокер і групи споживачів: відставання кожної групи, швидкість публікації та підтверджень, обсяг непрочитаних розділів, частка повторних доставок.
Поки цих метрик немає, збій в обробці видно тільки за зовнішнім симптомом — користувач не отримав листа, замовлення зависло в проміжному статусі.
Час реакції на інцидент
Порогові оповіщення за відставанням споживачів і швидкістю підтверджень переводять виявлення з режиму «повідомив клієнт» в автоматичне: черговий бачить стійке зростання черги на ранній стадії, коли споживач ще наздоганяє потік, а не після зупинки обробки.
Час виявлення інциденту падає з годин до одиниць хвилин — встигнути втрутитися можна до того, як черга впреться в ліміти зберігання повідомлень.
Клас відмов, який перестає доходити до користувача
Окремо відстежуємо повідомлення без підтвердження, зростання кількості повторних доставок і «отруєні» повідомлення, які споживач не може розібрати й нескінченно повертає в чергу.
Такі збої небезпечні тим, що не обвалюють сервіс, а тихо втрачають дані: частина операцій просто не доїжджає до кінця, і виявляється це за скаргами, а не за метриками.
Прозорість обробки потоку
Трасування прив'язує ідентифікатор повідомлення до конкретної бізнес-операції, тому розбір іде за фактами: видно, на якому кроці повідомлення затрималося і скільки разів його переобробляли.
Kafka та інші брокери віддають ці метрики штатно — завдання в тому, щоб звести їх зі станом споживача і не потонути в шумі спрацювань.
Три підходи до збору метрик: агент, збирач, плагін
Метрики черг у Kafka та інших брокерах знімають трьома способами, і вони не замінюють один одного. Від вибору залежить, чи побачите ви відставання споживачів до того, як черга почне зростати, і скільки ресурсів піде на саме спостереження.
Що кожен варіант дає і чого позбавляє — у таблиці.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Агент на вузлі | Потрібні системні показники поруч із брокером і єдиний формат для всіх сервісів контуру | Займає ресурси вузла, втрачає частину вимірювань під час перезапуску брокера, потребує доступу до машини |
| Зовнішній збирач метрик | Багато різнорідних контурів, ставити на хости нічого не можна | Опитує мережею і з меншою частотою, не бачить внутрішнього стану брокера |
| Плагін брокера | Потрібні метрики зсередини: глибина черги, відставання споживачів, непідтверджені повідомлення | Прив'язаний до версії брокера, оновлюється разом із ним, у разі збою спостереження зникає |
Що вибрати за високого навантаження
За високого навантаження накладні витрати на спостереження перестають бути непомітними. Зовнішнє опитування не встигає за зростанням кількості черг і дає рвану картину, тому опорним роблять плагін: він віддає метрики зсередини і не ходить мережею. Агент на вузлі залишається для системних показників, яких плагін не бачить.
Змішаний збір на одному контурі
Тримати два способи на одному контурі нормально, якщо заздалегідь розвести зони відповідальності: плагін — про черги та споживачів, агент — про вузол, збирач — про доступність і зведені пороги.
Важливо не рахувати одну й ту саму величину двічі, інакше графіки розходяться і черговий перестає їм вірити. Оновлення брокера і плагіна планують разом, щоб не залишитися без спостереження в найнезручніший момент.
Як ми впроваджуємо моніторинг черг: етапи робіт
Починаємо з розбору контуру черг: які брокери та черги реально використовуються, хто публікує і хто читає, де проходить критичний шлях обробки. Далі фіксуємо відхилення, які вже призводили до інцидентів — зростання лагу, залипання споживача, переповнення диска на вузлі. Це й визначає, що потрапляє до схеми метрик, а що залишається шумом.
- Розбір контуру черг. Карта брокерів, обмінників, черг, груп споживачів і зв'язків між сервісами. Окремо відзначаємо потоки, простій яких зупиняє процес.
- Схема метрик. Набір показників: лаг споживача, глибина черги, швидкість публікації та обробки, кількість непідтверджених повідомлень, стан вузлів і диска.
- Налаштування збору. Збір з брокерів і споживачів, прив'язка до сховища метрик і панелей. Підписуємо показники за сервісами та чергами — черговий одразу бачить джерело.
- Порогові правила. Попередження та аварія за кожним показником, прив'язка до розкладу чергувань. Поріг беремо зі спостережуваної поведінки, а не з довідника, інакше отримуємо потік хибних спрацювань.
- Перевірка на навчальному збої. Зупиняємо споживача, роздуваємо чергу, прискорюємо публікацію: чи спрацювали правила і чи дійшло повідомлення до потрібної людини. Правки вносимо до передачі.
- Передача в експлуатацію. Панелі, правила, інструкції черговому та порядок доопрацювання при появі нових черг.
Що потрібно з вашого боку на кожному кроці
Доступи до брокерів, сховища метрик і панелей, перелік критичних черг і сервісів, контакт чергового та вікно для безпечної імітації збою. На розборі потрібен інженер, який знає зв'язки сервісів, на прийманні — той, хто буде чергувати. Інакше строки йдуть на погодження, а правила залишаються неперевіреними.
Що залишається у вас після впровадження: схеми та регламенти
Впровадження моніторингу закінчується не набором графіків, а комплектом артефактів, за якими ваша команда працює без нас. Усе живе у вашому репозиторії та у вашій системі оповіщень — з коментарями, чому зроблено саме так.
- Карта черг і споживачів. Які топіки та черги є, які сервіси їх читають, які групи споживачів існують і яке відставання для кожної вважається нормою. За нею новий інженер за вечір розуміє схему обміну повідомленнями.
- Конфігурації збору метрик. Описані як код: які лічильники знімаємо з брокерів і споживачів, з яким інтервалом, де зберігаються дані та скільки живуть.
- Правила оповіщень. Пороги за відставанням споживачів, швидкістю зростання черги, недоступністю вузла та відмовами публікації — так, щоб спрацьовувало на проблему, а не на шум.
- Регламент чергування. Хто і в які години відповідає, що вважається нічним інцидентом, як влаштована ескалація і коли підключається друга лінія.
- Інструкція з реагування. Покрокові дії на типові відмови: зростання відставання, втрата вузла, переповнення диска, завислий споживач — з командами діагностики та критеріями «лагодити зараз чи спостерігати».
- Опис панелей моніторингу. Що дивитися першим при сигналі та які метрики підтверджують, що проблема зникла.
- План розвитку. Що додати наступним кроком: контроль наскрізного проходження повідомлення, терміни зберігання, оповіщення за бізнес-показниками.
Як ми передаємо знання вашій команді
Передаємо не файлами на диску, а робочими розборами: проходимо по кожному оповіщенню і пояснюємо, чому поріг такий і що зміниться, якщо його зсунути.
Окремо проводимо навчання — імітуємо зростання відставання та втрату вузла, щоб черговий пройшов сценарій у спокійній обстановці, а не в момент аварії.
Перші чергування ваша команда несе разом із нашим інженером, далі — сама, а документація залишається точкою входу для нових людей.
Кейс: як зняли втрати повідомлень на пікових навантаженнях
Ретейл-сервіс із нічною вигрузкою замовлень: потік у чергу на розпродажах перевищував швидкість обробки, буфери переповнювалися, і частина повідомлень зникала раніше, ніж її помічали.
Kafka сам дані не втрачає — втрати виникали на стиках: підтвердження йшло до фактичної обробки, а відставання споживачів ніхто не відстежував.
Про збій дізнавалися від підтримки — клієнти писали, що замовлення не збирається. Від виявлення до початку розбору проходили години, а сам розбір був ручним: події відновлювали за логами, звіряючи номери замовлень.
Що саме змінили в контурі обробки
Підтвердження стали надсилати строго після запису результату, обробку зробили повторюваною з перевіркою ідентифікатора — повтори більше не перетворюються на подвійні операції.
Повідомлення, які не пройшли обробку після кількох спроб, ідуть в окрему чергу з тілом і причиною відмови. Алерти прив'язали до двох сигналів: відставання групи споживачів і швидкості його зростання — замість одного порогу, який спрацьовував на планових сплесках.
Моніторинг побудували на наскрізних маркерах: раз на хвилину тестове повідомлення проходить увесь шлях і підтверджує, що контур живий.
| Метрика | До | Після |
|---|---|---|
| Втрачені повідомлення на піку | до 2% у години розпродажів | одиниці, усі потрапляють до черги розбору |
| Виявлення збою | години, зі слів клієнтів | хвилини, за алертом про відставання |
| Хибні спрацювання | кілька на тиждень | поодинокі за квартал |
| Ручний розбір | після кожної пікової ночі | планова звірка раз на тиждень |
Чим контроль Kafka відрізняється від контролю RabbitMQ?
Kafka — це розподілений лог, а не черга: повідомлення зберігаються в розділах заданий час незалежно від того, прочитав їх хтось чи ні. Тому контроль Kafka будується навколо відставання споживачів — різниці між останнім записаним і останнім підтвердженим зміщенням у групі.
Дивляться не лише на середнє відставання, а й на рівномірність: якщо один споживач у групі забрав більше розділів, локальна затримка зростає при зовні здоровій загальній картині. Вирівнювання навантаження за розділами тут значить більше, ніж абсолютний поріг.
RabbitMQ працює інакше: повідомлення зникає після підтвердження, тому метрики RabbitMQ описують чергу тут і зараз. Ключові — глибина черги, співвідношення швидкостей публікації та підтвердження, кількість непідтверджених повідомлень і наявність черг без активних споживачів.
Плутати ці набори не можна. У потокової шини відставання коливається протягом дня, і поріг ставлять на швидкість зростання, а не на абсолютне значення: лог не порожніє сам по собі.
У брокера черг глибина — пряма ознака збою: вона або тримається біля нуля, або зростає до упору в ліміти, після чого публікація починає відмовляти.
У змішаному контурі черг, де поруч живуть обидва типи брокерів, панель спостереження збирають за загальними правилами, а пороги та прогнози рахують окремо.
Для потокової шини прогноз — час до витіснення даних за терміном зберігання, для брокера черг — час до переповнення і ризик зростання диска. Оповіщення спрацьовує на стійкий тренд, а не на одиничний сплеск.
Технічні питання, які задають перед стартом
Перед стартом технічна команда замовника зазвичай задає одні й ті самі питання — і правильно: відповіді визначають, як буде влаштований збір і що потрапить в оповіщення. Нижче п'ять, які закриваємо до початку робіт, щоб не з'ясовувати це вже в процесі.
Як ви отримаєте доступ до метрик?
Заводимо окремий обліковий запис лише для читання з правами виключно на метрики брокера — без доступу до вмісту топіків і черг. Збір іде зсередини вашого контуру, назовні нічого не публікується.
Наскільки збір навантажує кластер?
Агент знімає лічильники через штатний інтерфейс брокера й агрегує їх локально, тому на брокери припадає частка відсотка від їхньої звичайної роботи. Відставання споживачів, глибина черг і швидкість обробки при цьому видно повністю.
Що з безпекою даних у чергах?
Ми читаємо метадані та лічильники, а не тіла повідомлень — вміст листування між сервісами залишається недоступним для системи спостереження. У логи та оповіщення потрапляють лише імена черг і числові значення, ключі шифрування не залишають ваш контур.
У нас уже є спостереження — чи не буде конфлікту?
Спочатку дивимося, що вже збирається, і підключаємося до наявного збору, а не розгортаємо другий паралельно. Зазвичай бракує не збору, а порогів і правил: додаємо відсутні сигнали та налаштовуємо оповіщення поверх поточної картини.
Де закінчується ваша відповідальність?
Ми відповідаємо за збір метрик, правила оповіщень, розбір інцидентів і документацію щодо них. Конфігурація брокерів, доступи та стан самого кластера залишаються за вашою командою — межу фіксуємо письмово до старту.
Обговоримо вашу задачу та повернемося з планом робіт
Щоб розбір був предметним, а не оглядовим, надішліть три речі: схему контуру з брокерами та споживачами, склад черг і топіків із призначенням і поточні скарги — що саме гальмує, втрачається або дублюється.
Корисні й вигрузки метрик за тиждень, і те, як зараз налаштовані оповіщення. За цим набором уже видно, де вузьке місце, і не доводиться задавати загальні питання про Kafka і RabbitMQ.
Чек-лист готовності контуру, за яким ми звіряємося перед стартом робіт:
- названо власників сервісів — з ким погоджувати перезапуск і зміну груп споживачів;
- є доступ до метрик брокера та відставання кожної групи споживачів;
- зафіксовано очікуваний режим: пікове навантаження, допустиме відставання, політика повторів;
- описано поточні сигнали: кому і за яких порогів іде оповіщення;
- є тестовий контур, де можна безпечно відтворити збій і перевірити відкат;
- зрозуміла частота релізів і вікна, коли перебудова черг нікого не зачепить.
Так ми обговоримо задачу на ваших даних і повернемося з оцінкою та планом робіт: етапи, строки, зони відповідальності, точки контролю. Питання до підрядника збираємо разом із матеріалами — відповідаємо по суті, без загальних обіцянок.
Старт робіт не чекає повної ясності за всіма пунктами: чек-лист закриваємо по ходу, а перші спостереження віддаємо вже на етапі розбору.
