Health check ендпоінти: де відмова ламає весь сервіс
Відмова одного вузла рідко залишається локальною. Балансувальник продовжує слати трафік на інстанс, який уже не може обслуговувати запити — з'єднання накопичуються, пул потоків вичерпується, і за кілька хвилин лягає весь сервіс.
Це класична каскадна відмова: health check ендпоінти або відсутні, або відповідають «ок» незалежно від реального стану застосунку.
Зворотна крайність не краща. Якщо liveness проба перевіряє зовнішню залежність — базу, чергу, сторонній API — то при короткочасній недоступності бази платформа почне перезапускати здорові інстанси.
Отримуємо хибні перезапуски: сервіс втрачає з'єднання, прогріває кеш заново, а причина збою нікуди не зникла. Розділення проб знімає цю плутанину: liveness відповідає лише за «процес живий і не завис», readiness — за «готовий приймати трафік прямо зараз».
Readiness проба — це точка, де трафік відсікається до того, як користувач побачить помилку. Поки інстанс прогріває кеш, чекає міграції або втрачає зв'язок з базою, він чесно повідомляє «не готовий» — балансувальник виводить його з ротації, і запити йдуть на робочі вузли. Без цього механізму деградація одного пода перетворюється на простій сервісу для всіх.
Ціна помилки вимірна: при коректних пробах час відновлення після збою вузла — секунди, при їх відсутності — хвилини, поки черговий вручну не виведе інстанс. Далі розбираємо, як це закривається на рівні конфігурації.
Що дає правильно налаштований health check
Час відновлення падає з десятків хвилин до секунд
Liveness-проба перестає бути формальністю: вона перевіряє не «процес живий», а здатність сервісу відповідати на реальний запит — доступність пулу з'єднань з базою, стан внутрішніх черг, готовність кешу.
Коли контейнер зависає в деградованому стані, оркестратор отримує чесний сигнал і перезапускає його одразу, а не через півгодини за алертом від чергового. На практиці це різниця між відновленням за 20-40 секунд і ручним розбором на 15-30 хвилин.
Хибні перезапуски зникають із графіка чергувань
Readiness-проба з коректними порогами (затримка старту, кількість допустимих провалів, період опитування) відокремлює «сервіс ще піднімається» від «сервіс зламаний».
Без неї типова картина: застосунок стартує довше за таймаут, оркестратор убиває його на середині ініціалізації, цикл повторюється — сервіс не виходить у стрій взагалі.
Правильна конфігурація прибирає цей клас інцидентів повністю, а разом із ним — нічні перезапуски та хибні спрацювання моніторингу.
Маршрутизація трафіку перестає слати запити в мертві поди
Поки readiness не підтверджена, балансувальник не направляє трафік на екземпляр — і навпаки, при провалі проби прибирає його з ротації до перезапуску.
Це закриває відмови, які інакше виглядають як випадкові помилки в частини користувачів: запити йдуть у контейнер, який уже не обслуговує з'єднання. Доступність сервісу перестає залежати від того, чи встиг хтось вручну прибрати вузол.
Розділення проб дає керований відкат
Коли liveness, readiness і стартова проба налаштовані роздільно, перезапуск перестає бути єдиною реакцією на будь-який збій. Тимчасова втрата бази валить readiness, але не вбиває контейнер — сервіс перечікує збій і повертається в ротацію сам. Це знижує навантаження на інфраструктуру і зберігає стан, який губиться при жорсткому рестарті.
Підходи до перевірки стану: порівняння режимів
Перевірки поділяються на два рівні: внутрішні проби оркестратора, які вирішують, чи перезапускати контейнер і чи пускати на нього трафік, та зовнішній моніторинг, який дивиться на сервіс очима користувача.
Змішувати їх не можна: проба, що смикає базу або зовнішній API, при збої залежності завалить здоровий под, а моніторинг, що стукає лише в корінь сайту, не побачить, що застосунок віддає помилки на половині сценаріїв.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Liveness-проба | Процес може зависнути: дедлок, зациклення, вичерпання пулу потоків | Відповідає лише «чи живий процес». Залежності не перевіряє — інакше каскадний перезапуск усього сервісу при збої бази |
| Readiness-проба | Потрібно прибрати под з балансування на час прогріву, міграцій або перевантаження | Не перезапускає контейнер. При помилці в логіці легко отримати под, що вічно висить поза трафіком |
| Startup-проба | Довгий старт: прогрів кешу, завантаження моделей, застосування міграцій | Працює один раз за життя контейнера. Якщо старт нестабільний за часом — поріг доведеться піднімати із запасом |
| Зовнішній моніторинг | Перевірка наскрізного сценарію: вхід, оплата, віддача даних зі сховища | Не керує оркестратором. Хибні спрацювання при мережевих сплесках, потрібен запас за частотою опитування |
На практиці режими комбінують: startup закриває довгий запуск, readiness регулює трафік, liveness ловить зависання, а зовнішній моніторинг підтверджує, що сервіс працює для клієнта.
Розділення ендпоінтів — обов'язкова умова: /healthz для процесу та /ready для готовності приймати запити не повинні ходити в одні й ті самі залежності.
Головне обмеження будь-якого режиму — ціна хибного спрацювання. Занадто строга liveness-проба перетворює короткочасну просадку на шторм перезапусків, занадто м'яка — залишає неробочий под у ротації.
Тому пороги, затримки та число повторів підбирають під реальний профіль навантаження, а не за замовчуванням.
Етапи впровадження health check ендпоінтів
Впровадження health check ендпоінтів починається з аудиту того, що вже є: які перевірки відповідають на запити, що саме вони перевіряють і як на них реагує балансувальник.
Часто з'ясовується, що ендпоінт повертає «ок» завжди — при недоступній базі або переповненій черзі він усе одно віддає успішну відповідь, і трафік продовжує йти на зламаний екземпляр.
На цьому етапі фіксуємо залежності сервісу і домовляємося, відмова якої з них має виводити екземпляр з ротації, а яка — лише сигналізувати.
- Аудит поточних перевірок. Збираємо список ендпоінтів, дивимося, що вони перевіряють, як налаштовані інтервали та пороги на боці оркестратора, які збої вже призводили до простоїв.
- Проєктування схеми перевірок. Розділяємо liveness і readiness: перша відповідає на питання «чи живий процес», друга — «чи готовий він приймати трафік». Окремо проєктуємо перевірку старту для сервісів із довгою ініціалізацією, щоб проба не вбивала екземпляр раніше часу.
- Налаштування проб. Прописуємо інтервали, таймаути, кількість повторів до переведення в стан відмови та пороги, за яких екземпляр виводиться з ротації. Перевірки робимо дешевими — без важких запитів до бази, щоб проба сама не створювала навантаження.
- Тестування сценаріїв відмови. Навмисно валимо залежність, забиваємо чергу, відкликаємо доступ до сховища — і дивимося, як поводиться система: чи йде трафік з проблемного екземпляра, чи відновлюється він після повернення залежності, чи немає хибних спрацювань при короткочасних збоях.
- Документація. Передаємо схему перевірок, значення параметрів і логіку реакції на відмову — щоб черговий інженер розумів, чому екземпляр вийшов з ротації, і міг відрізнити реальну аварію від хибного спрацювання.
Після впровадження відмова одного екземпляра перестає бути помітною для користувача: трафік іде на здорові вузли, а відновлення відбувається без ручного втручання. Опишіть вашу задачу — повернемося з оцінкою та планом робіт.
Артефакти та конфігурації, які ви отримуєте
За підсумком робіт ви отримуєте не «налаштований моніторинг», а відтворюваний набір артефактів: конфігурації, схеми, політики та регламенти, за якими система живе й передається вашій команді без усних пояснень. Нижче — що саме залишається в репозиторії та в документації.
- Конфігурація проб — маніфести з liveness, readiness і startup-перевірками: шлях ендпоінта, інтервали, пороги відмов, затримка першого запуску. Окремо для кожного сервісу, з коментарями, чому обрано такі значення.
- Схема залежностей — карта, який сервіс від кого залежить і як це відображено в readiness: перевірка БД, черги, зовнішніх API. Видно, що саме блокує прийом трафіку при збої.
- Політики доступу — правила, хто і звідки може смикати ендпоінти: внутрішня мережа, оркестратор, системи моніторингу. Публічний доступ закрито, перевірки не світять стан сервісу назовні.
- Регламенти реагування — що означає кожен статус проби, за якого сценарію перезапуск, за якого — зняття з балансування, кому йде оповіщення і в який термін.
- Інструкції з експлуатації — як додати нову пробу, змінити поріг, відкотити конфігурацію. З прикладами правок і очікуваним результатом.
- Набір тестових сценаріїв — як відтворити відмову: погасити залежність, сповільнити відповідь, уронити процес. Перевірка, що проби реагують так, як задумано.
- Звіт щодо впровадження — які сервіси покрито, які пороги виставлено, що залишилося за рамками і чому.
Конфігурації лежать у системі контролю версій поруч із кодом сервісів — зміни проходять рев'ю і потрапляють в історію. Схеми та регламенти — у документації проєкту, у форматі, який читається без доступу до інфраструктури. Опишіть вашу задачу — повернемося з оцінкою та планом, які артефакти потрібні саме вам.
Кейс: як health check ендпоінти скоротили простої
Проєкт — високонавантажений сервіс із чергою фонових задач: кілька інстансів за балансувальником, деплой по кілька разів на тиждень.
До впровадження перевірок контейнери перезапускалися за зовнішньою ознакою «процес живий», хоча застосунок уже не відповідав: пул з'єднань до бази вичерпано, фонові обробники зупинилися, але процес не падав.
Балансувальник продовжував слати трафік на нездоровий інстанс, клієнти отримували помилки, а черговий дізнавався про збій із звернень. Кожен такий інцидент розтягувався на десятки хвилин ручної діагностики.
Що змінили
Розвели два типи перевірок за змістом. Liveness відповідає лише на питання «процес завис намертво» — якщо так, платформа перезапускає контейнер. Readiness описує готовність приймати трафік: доступність бази, наповненість пулу з'єднань, стан фонових обробників.
Поки readiness не проходить, інстанс виводиться з балансування, але не вбивається — це принципово, інакше перезапуск під час прогріву дає лавину.
Окремо налаштували стартову перевірку зі збільшеним вікном: застосунок прогріває кеші та піднімає з'єднання довше, ніж триває звичайний інтервал, і без цього платформа вбивала контейнер до готовності.
Пороги підібрали так, щоб одиничний збій залежності не виводив інстанс з ладу, а стійка деградація — виводила.
Що стало
Kubernetes перестав перезапускати здорові контейнери і почав прибирати з балансування лише реально неготові. Частка запитів, що потрапили на нездоровий інстанс, упала з 4–5% до часток відсотка.
Середній час відновлення після збою залежності скоротився з десятків хвилин до 1–2: інстанс сам повертається в стрій, щойно readiness знову проходить.
Кількість перезапусків контейнерів за тиждень знизилася приблизно в п'ять разів — пішли хибні спрацювання на прогріві та піковому навантаженні.
Стабільність перестала залежати від того, чи помітив черговий проблему. Перевірки фіксують деградацію раніше, ніж її відчують клієнти, а метрики за ендпоінтами дають готову картину для розбору.
Чим відрізняється liveness від readiness?
Liveness відповідає на питання «чи живий процес», readiness — «чи готовий він приймати трафік».
Це різні питання, і плутати їх дорого: проба, яка перевіряє не те, що потрібно, або кидає здоровий контейнер під підозрою в цикл перезапусків, або тримає в балансуванні екземпляр, який ще не підняв з'єднання з базою.
Liveness-проба дивиться тільки на самопочуття самого процесу: чи не заблокувався він, чи не пішов у дедлок, чи відповідає керуючий потік. Якщо перевірка падає, платформа вбиває контейнер і піднімає новий — це аварійний важіль, а не інструмент тонкого налаштування.
Класична помилка — повісити в liveness перевірку зовнішньої залежності: база моргнула на десять секунд, і весь парк контейнерів іде в одночасний перезапуск, хоча застосунок був повністю працездатний.
Readiness-проба, навпаки, керує маршрутизацією. Поки вона не проходить, екземпляр виключений з балансування, але продовжує жити: довантажує кеш, чекає прогріву пулу з'єднань, застосовує міграції.
Readiness, що впала, не перезапускає контейнер — вона лише прибирає його з видачі, і коли залежність повертається, екземпляр так само плавно повертається в стрій.
Звідси практичне правило: у liveness — мінімум логіки, тільки «процес відповідає»; у readiness — усе, без чого запит не буде обслуговано коректно.
Таймаути теж розходяться: readiness можна перевіряти часто і з коротким порогом, liveness — рідше і із запасом, щоб не вбивати контейнер на піковому навантаженні, коли відповіді закономірно сповільнилися.
Часті технічні сумніви
Проби вбудовуються у вже працюючий сервіс без переписування бізнес-логіки: додається окремий ендпоінт, який перевіряє залежності та віддає статус.
Якщо застосунок уже розгорнуто в кластері, спочатку знімаємо поточну поведінку — як він відповідає при недоступній базі, при переповненому пулі з'єднань, при повільному зовнішньому сервісі. За цією картиною налаштовуємо пороги, а не за замовчуванням.
Обмеження у проб є, і їх важливо проговорити до впровадження. Liveness не повинен ходити в базу або зовнішній сервіс: якщо залежність моргнула, перезапуск контейнера її не вилікує, а сервіс втратить обробку запитів.
Readiness, навпаки, зобов'язаний враховувати готовність залежностей — інакше трафік піде на інстанс, який ще не може відповідати. Розділення цих ролей і є основна робота.
Як уникнути хибних спрацювань при короткочасних збоях?
Поріг спрацювання задається не одним запитом, а серією: наприклад, три невдалі перевірки підряд з інтервалом і періодом очікування. Плюс окремий таймаут на сам ендпоінт — він повинен відповідати швидше, ніж спливає проба. Так короткочасна затримка бази не призводить до перезапуску, а стійка деградація — призводить.
Що буде з уже налаштованим рішенням, якщо ми прийдемо?
Розбираємо поточні проби і дивимося, що вони реально перевіряють. Часто liveness і readiness вказують на один і той самий ендпоінт — це перше, що розділяємо. Конфігурацію переносимо в маніфести, щоб пороги та таймаути були версіоновані, а не задані руками в панелі. Відкат — повернення попереднього маніфесту, без перезбирання образу.
Чи потрібно змінювати код застосунку під проби?
У більшості випадків — ні. Ендпоінт додається окремим обробником, бізнес-логіка не зачіпається. Якщо сервіс не вміє віддавати статус залежностей, додаємо легку перевірку: доступність з'єднання та час відповіді. Цього достатньо, щоб проба відображала реальну готовність, а не факт запуску процесу.
Обговоримо ваше завдання з налаштування health check
Щоб повернутися з оцінкою та планом, а не із загальними словами, нам потрібен мінімум вхідних даних щодо вашого контуру. Опишіть завдання: які сервіси обслуговуються, як зараз влаштований деплой, чи є оркестратор і як проби налаштовані сьогодні. Цього достатньо, щоб зрозуміти обсяг і запропонувати конкретну схему.
Що корисно додати до опису:
- перелік сервісів та їхні ролі — які приймають трафік, які працюють у фоні;
- поточні маніфести або конфігурації деплою, якщо вони є;
- як зараз перевіряється доступність: зовнішній моніторинг, ручні перевірки чи нічого;
- вимоги до часу відновлення — скільки простою допустимо при відмові пода;
- обмеження щодо доступів і середовищ: скільки контурів, хто власник кластера;
- відомі проблеми: хибні перезапуски, завислі поди, довгий прогрів після старту;
- контактна особа з боку інфраструктури для уточнень у ході робіт.
За цим набором ми оцінюємо трудовитрати, називаємо етапи та порядок викочування. Далі узгоджуємо план робіт: розмітку проб за сервісами, налаштування порогів і таймаутів, перевірку на staging і поетапне виведення в продуктив. Старт проєкту — після того як зафіксуємо межі та точки відкату.
Опишіть завдання у зручному вигляді — повернемося з оцінкою та планом робіт.
