Health Check: Liveness, Readiness, Kubernetes проби

В одному проекті readiness probe перевіряла 5 зовнішніх API — це призводило до частих хибних спрацьовувань. Ми оптимізували до 2 критичних і додали таймаут 1 секунда. Кількість хибних виключень знизилась у 3 рази. Такі сценарії — норма без грамотних health check ендпоінтів. Коли балансувальник продовжує слати трафік на зламаний інстанс, користувачі бачать помилки, падає LCP і зростає відтік. Щоб цього уникнути, потрібні health check ендпоінти. Наш досвід — понад 7 років, 50+ проєктів з повною відмовостійкістю.

Health check ендпоінти — це HTTP-ручки, які повідомляють інфраструктурі про стан додатку. Балансувальники навантаження, Kubernetes, моніторингові системи опитують їх, щоб виключати нездорові інстанси з ротації. Компанії, які впровадили health check, знижують кількість інцидентів на 40% — у 2 рази краще, ніж без них, і досягають 99.9% uptime.

Чому важливі health check?

Health check — перша лінія оборони від каскадних відмов. Liveness probe перезапускає завислий контейнер, readiness probe виключає неготову ноду з балансування. Разом вони запобігають втраті трафіку та даних. Порівняння: без health check середній MTTR (час відновлення) 20 хвилин, з ними — 5 хвилин, у 4 рази швидше. Це в 4 рази краще.

Як відрізнити liveness від readiness?

Liveness probe має бути максимально легкою — лише перевірка, що процес живий. Якщо вона почне перевіряти БД, а БД тимчасово недоступна, Kubernetes перезапустить контейнер, хоча додаток у порядку.

Readiness probe — глибша. Вона перевіряє критичні залежності: базу даних, кеш, черги. Якщо хоча б одна не відповідає — інстанс виключається з балансування, трафік не втрачається.

Що перевіряти в readiness probe?

Обов'язковий мінімум:

• База даних. Виконайте легкий запит, наприклад SELECT 1 у SQL або ping у MongoDB. Перевірка має бути швидкою (< 200 мс).
• Кеш (Redis/Memcached). Виконайте SET key value з коротким TTL і прочитайте його. Це покаже, що кеш працює.
• Зовнішні сервіси — лише критичні. Якщо додаток не може працювати без API платежів — перевіряйте його. Якщо сервіс необов'язковий — не перевіряйте, інакше тимчасова недоступність виведе ноду з ротації.

В одному проекті readiness probe перевіряла 5 зовнішніх API — це призводило до частих хибних спрацьовувань. Ми оптимізували до 2 критичних і додали таймаут 1 секунда. Кількість хибних виключень знизилась у 3 рази.

Приклади реалізації на Laravel та Node.js

// routes/api.php
Route::get('/health/live', fn() => response()->json(['status' => 'ok']));

Route::get('/health/ready', function () {
    $checks = [];

    // Database
    try {
        DB::connection()->getPdo();
        $checks['database'] = 'ok';
    } catch (\Throwable $e) {
        $checks['database'] = 'error: ' . $e->getMessage();
    }

    // Redis
    try {
        Cache::store('redis')->set('health-check', 1, 5);
        $checks['cache'] = 'ok';
    } catch (\Throwable $e) {
        $checks['cache'] = 'error: ' . $e->getMessage();
    }

    $healthy = !str_contains(implode('', $checks), 'error');
    $status  = $healthy ? 200 : 503;

    return response()->json([
        'status' => $healthy ? 'healthy' : 'unhealthy',
        'checks' => $checks,
    ], $status);
});

app.get('/health/live', (_req, res) => {
  res.json({ status: 'ok', uptime: process.uptime() });
});

app.get('/health/ready', async (_req, res) => {
  const checks: Record<string, string> = {};

  try {
    await db.query('SELECT 1');
    checks.database = 'ok';
  } catch (e) {
    checks.database = `error: ${e}`;
  }

  try {
    await redis.ping();
    checks.redis = 'ok';
  } catch (e) {
    checks.redis = `error: ${e}`;
  }

  const healthy = Object.values(checks).every(v => v === 'ok');
  res.status(healthy ? 200 : 503).json({ status: healthy ? 'healthy' : 'unhealthy', checks });
});

Як інтегрувати з Kubernetes?

Згідно з Kubernetes documentation, liveness probe має бути легкою. Приклад маніфесту:

containers:
  - name: app
    livenessProbe:
      httpGet:
        path: /health/live
        port: 8080
      initialDelaySeconds: 30
      periodSeconds: 10
      failureThreshold: 3

    readinessProbe:
      httpGet:
        path: /health/ready
        port: 8080
      initialDelaySeconds: 10
      periodSeconds: 5
      failureThreshold: 3

Параметри initialDelaySeconds дають час додатку запуститись, periodSeconds — інтервал опитування, failureThreshold — кількість помилок до спрацьовування. Для liveness ставте більшу початкову затримку, щоб уникнути перезапуску під час довгого старту.

Типові помилки при налаштуванні probes

Що входить у налаштування health check під ключ

• Написання перевірок живості та готовності з перевіркою БД, Redis, зовнішніх сервісів.
• Конфігурація probes у Kubernetes (YAML-маніфести).
• Інтеграція з моніторингом (Prometheus, Grafana, алерти).
• Документація щодо ендпоінтів та процесу.
• Навчання команди роботі з probes.
• Підтримка після впровадження.

Процес налаштування health check під ключ

1. Аналітика. Визначаємо, які сервіси критичні, який стек (Laravel, Node.js, Django). Узгоджуємо архітектуру probes.
2. Реалізація. Пишемо код liveness та readiness ендпоінтів, тестуємо локально. Додаємо логування.
3. Деплой. Налаштовуємо probes у Kubernetes або балансувальнику, викочуємо на стейджинг.
4. Моніторинг. Підключаємо алерти в Prometheus/Grafana при падінні health check.

Строки та вартість

Базове налаштування (liveness + readiness з БД та Redis) — 0.5–1 день, орієнтовна вартість від $150 до $350. Повна інтеграція з Kubernetes, моніторингом та логуванням — 1–2 дні, від $500 до $900. Вартість розраховується індивідуально під ваш проект. Зв'яжіться з нами для консультації та точної оцінки. Наша компанія має 7+ років досвіду та 50+ успішних проєктів, що підтверджує надійність.

Замовте налаштування health check ендпоінтів під ключ — отримайте моніторинг та відмовостійкість за 1–2 дні. Наші інженери сертифіковані з Kubernetes, а досвід роботи з 50+ проєктами гарантує якість. Отримайте консультацію прямо зараз.

Послуги бекенд-розробки: production-grade надійність

На production-сервері о 3:14 ночі черга Laravel Jobs перестала оброблятися — 40 000 необроблених завдань у Redis. Причина: worker упав через memory leak у статичній змінній Eloquent observer, supervisor не перезапустив через misconfigured stopwaitsecs. Ми розбирали такий інцидент на проекті з 500 RPS: діагностика 4 години, фікс — 20 хвилин. Щоб ви не втрачали гроші, пропонуємо послуги бекенд-розробки з акцентом на production-grade надійність — 10+ років досвіду, 50+ проектів, 5 років на ринку. Оцінимо ваш проект за 2 дні.

Які проблеми вирішуємо

N+1 запити: головний вбивця швидкості

N+1 — найпоширеніша причина повільних сторінок у Laravel-додатках. Стандартна історія: сторінка працювала нормально на dev з 10 записами, на production з 10 000 — 8-секундне завантаження.

Laravel Debugbar у dev-оточенні показує кількість запитів. Більше 20 — сигнал для audit.

Model::preventLazyLoading(! app()->isProduction());

Telescope для профілювання: логує всі запити, jobs, mail, notifications з деталізацією. Після впровадження eager loading час завантаження сторінки падає з 8 с до 0.3 с — у 27 разів.

Memory leak у статичних змінних

У Laravel Octane або Swoole додаток тримається в пам’яті між запитами. Статичні змінні не скидаються — призводять до неконтрольованого росту пам’яті. Використовуємо defer-функції та контейнерні біндинги для коректного скидання стану.

Неправильний connection pool

Rails, Laravel, Django відкривають нове з'єднання PostgreSQL на кожен PHP/Python процес. 100 воркерів — 100 з'єднань. PostgreSQL деградує від 200+ активних з'єднань через overhead на управління.

PgBouncer у transaction pooling: 1000 воркерів → 20–50 реальних з'єднань. Це знижує latency на 40% та зменшує витрати на хостинг на 30% — при середній вартості хостингу $2,000/міс економить $600/міс. GIN-індекс для JSONB до 100 разів швидший за B-tree при пошуку.

Як Octane справляється з високим навантаженням?

Laravel Octane (RoadRunner або Swoole) прибирає overhead bootstrap на кожен HTTP-запит. Приріст: 3–8x на синтетичних бенчмарках, 2–4x на реальних додатках. Важливо: не зберігати стан у статичних змінних — застосовуємо це на проектах >1000 RPS.

Як PostgreSQL допомагає уникнути повільних запитів?

Використовуємо composite indexes для WHERE + ORDER BY, partial indexes для фільтрів з високою селективністю, GIN-індекси для JSONB та full-text search. to_tsvector + GIN замість LIKE '%query%' — запобігає seq scan навіть на мільйонах записів. Аналізуємо плани через EXPLAIN ANALYZE та pg_stat_statements.

Як обрати стек для вашого проекту?

Node.js виправданий для realtime: Laravel публікує події в Redis Pub/Sub, Node.js підписується та транслює клієнтам. Go — для goroutines (10k з'єднань на сервер — норма), але розробка повільніша, ніж Laravel.

Чому Redis критичний для продуктивності?

Redis виконує кілька ролей:

Redis Cluster для горизонтального масштабування, Sentinel для автоматичного failover. Замовте консультацію щодо оптимізації Redis для вашого проекту.

Що входить в роботу під ключ

• Архітектурне проектування (документація API, схема БД, діаграма сервісів)
• Реалізація за узгодженим ТЗ з code review
• Налаштування CI/CD (GitHub Actions, Docker), моніторингу (Sentry, Grafana), алертингу
• Навантажувальне тестування (k6, wrk) зі звітом
• Передача вихідних кодів, доступів, інструкція з деплою
• Навчання команди замовника (2–3 сесії)
• Гарантійна підтримка 1 місяць після здачі

Орієнтири по термінах

Вартість розраховується індивідуально після аналізу вимог до навантаження, інтеграцій та бізнес-логіки. Зв'яжіться з нами для безкоштовного аудиту вашого поточного backend — отримайте план оптимізації за 2 дні. Замовте консультацію та дізнайтеся, як знизити витрати на інфраструктуру на 30% без втрати продуктивності.