Балансировщик может считать инстанс здоровым, пока процесс слушает порт, хотя приложение не подключается к базе или не обслуживает запросы. В результате часть пользователей получает 500 и таймауты от формально активного узла.

Разделите liveness и readiness. Балансировщику нужен быстрый readiness endpoint, который проверяет способность обслужить новый запрос, но не выполняет тяжелую диагностику при каждом обращении.

Что сделать в первую очередь

  • Проверьте текущий path, порт, протокол и ожидаемый статус healthcheck.
  • Сравните ответ проверки с реальным пользовательским запросом на каждом узле.
  • Зафиксируйте интервалы, таймауты и healthy/unhealthy thresholds.
  • Убедитесь, что firewall разрешает проверки только от балансировщика.

Почему возникает проблема

Симптом обычно появляется не из-за одной настройки. Сначала разделите путь данных на этапы и найдите место, где фактическое поведение расходится с ожидаемым.

  • Проверяется статический файл, не связанный с приложением.
  • Endpoint всегда возвращает 200 даже при недоступной критической зависимости.
  • Слишком большой порог долго оставляет неисправный узел в пуле.
  • При деплое трафик приходит до завершения миграции и прогрева.

Пошаговая диагностика

  • Отключите одну критическую зависимость на тестовом узле и наблюдайте статус.
  • Сравните журналы healthcheck и пользовательских ошибок по instance id.
  • Проверьте Host header и маршрут при обращении балансировщика.
  • Измерьте длительность endpoint и влияние на базу.
  • Проверьте deregistration delay и завершение активных соединений.

Как исправить

Исправляйте подтвержденную первопричину и сохраняйте возможность отката. После каждого изменения повторяйте один и тот же контрольный сценарий, чтобы не спутать результат нескольких правок.

  • Создайте отдельный readiness endpoint с минимальными критическими проверками.
  • Возвращайте неуспешный статус при невозможности обслуживать новый трафик.
  • Настройте разумные интервалы и пороги без секундных ложных переключений.
  • На деплое сначала дождитесь readiness, а при остановке включайте drain.
  • Не раскрывайте в публичном ответе версии, пароли и подробности инфраструктуры.

Как проверить результат

  • Неисправный узел исключается из пула в ожидаемое время.
  • После восстановления он возвращается только после стабильных успешных проверок.
  • Во время rolling deployment активные запросы завершаются без обрыва.

Как не допустить повторения

  • Регулярно проводите контролируемый тест отказа одного узла.
  • Мониторьте число healthy targets и ошибки по instance id.
  • Версионируйте healthcheck вместе с приложением и инфраструктурой.

Частые вопросы

Нужно ли healthcheck выполнять запрос к базе?

Если без базы приложение не может обслуживать запросы, readiness должен учитывать это, но проверка должна быть быстрой и ограниченной.

Почему нельзя проверять главную страницу?

Она может быть тяжелой, кешироваться или зависеть от лишних сервисов, что делает сигнал неточным.

Когда стоит обратиться за помощью

Для диагностики нужны настройки target group, ответы endpoint и ошибки по узлам. Доступ к данным пользователей не требуется.

Итог

Healthcheck должен отражать способность узла принимать трафик, а не только наличие процесса. Я могу настроить readiness, пороги, drain и безопасный rolling deployment.