Як зрозуміти, що застосунок у певний момент працює справно?

Повне пояснення

Що це і навіщо

• Health‑check – простий HTTP‑endpoint, який повертає статус 200, коли всі залежності (БД, кеш, зовнішні сервіси) доступні. Використовується для моніторингу uptime і швидкої діагностики.

Ключові принципи/терміни

• Status code 200/204 – успішна відповідь.
• Health‑check endpoint (наприклад, /health).
• Unit / Integration tests – перевірка окремих компонентів і їх взаємодії.
• Logging – error, warn, info рівні.

Як це працює

1. Запит до /health викликає middleware, який перевіряє стан БД, кешу тощо.
2. Якщо всі перевірки успішні – повертається { status: 'ok' }.
3. Якщо будь‑яка перевірка не пройшла – повертається { status: 'fail', details: [...] } і статус 503.

Практика та реалізація (Node.js / NestJS)

// health.controller.ts
@Get('health')
async getHealth(): Promise<HealthCheckResult> {
  return this.health.check([
    async () => ({
      name: 'database',
      status: await this.dbService.isAlive() ? 'up' : 'down',
    }),
  ]);
}

Тестування – Jest + Supertest:

test('GET /health', async () => {
  const res = await request(app.getHttpServer()).get('/health');
  expect(res.status).toBe(200);
  expect(res.body.status).toBe('ok');
});

Безпека та приватність – health‑check не повинен розкривати внутрішні деталі. Використовувати аутентифікацію або IP‑фільтрацію.

Производительность і масштабирование – health‑check має бути легким, без тяжких запитів до БД. Для масштабованих систем можна розділити на liveness (чи живий процес) і readiness (може обробляти запити).

Часті помилки

1. Повернення 200 при відсутності БД – неправильна логіка.
2. Перевірка, що виконується синхронно – блокує event loop.
3. Відсутність таймауту на зовнішні сервіси – довгі затримки.
4. Логування всіх помилок як info – важко розпізнати критичні.
5. Необхідність ручного перезапуску після зміни конфігурації.
6. Перевірка лише одного сервісу – інші можуть бути недоступні.
7. Відсутність тестів для health‑check – не виявляються regressions.
8. Повернення детальної інформації (наприклад, SQL‑запит) – ризик розкриття.

Cheatsheet

• GET /health → 200 OK + {status:'ok'}.
• GET /health → 503 Service Unavailable + {status:'fail', details:[...]}.
• Тестувати з Jest/Supertest.
• Логувати лише error і warn у продакшн.

Follow‑up питання

1. Як розділити liveness і readiness? – Відповідь: liveness перевіряє, чи живий процес; readiness – чи готовий обробляти запити.
2. Які інструменти можна використовувати для моніторингу health‑check? – Prometheus + Grafana, Datadog, New Relic.