Конечные точки готовности и жизнеспособности AppEngine Flex не запускаются

Question

Я настроил пользовательские конечные точки проверки готовности и живучести, как описано на этой странице для моего приложения AppEngine Flex: https://cloud.google.com/appengine/docs/flexible/python/reference/app-yaml

Однако, глядя на журналы, становится ясно, что он игнорирует мои настройки, которые выглядят следующим образом:

liveness_check:
  path: "/liveness_check_custom"
  check_interval_sec: 30
  timeout_sec: 4
  failure_threshold: 4
  success_threshold: 2

readiness_check:
  path: "/readiness_check_custom"
  check_interval_sec: 5
  timeout_sec: 4
  failure_threshold: 2
  success_threshold: 2
  app_start_timeout_sec: 300

У меня есть пользовательское сообщение журнала за этими конечными точками, которое не появляется в журналах, а также просматривает журналы nginx .health_check, которые я вижу что он по-прежнему попадает в конечные точки "liveness_check" и "readiness_check", а не в мои пользовательские конечные точки.

Если я сам попадаю на мои конечные точки, я вижу сообщения журнала. Эта документация Google неверна или я что-то упустил? Есть настройки, которые мне не хватает?

Answer 1

Секции

liveness_check и readiness_check , определенные в app.yaml , - это новый метод проверки работоспособности в flex модуля приложения. liveness_check сигнализирует о том, что ВМ и контейнер Docker работают, а readiness_check сигнализирует о том, что экземпляр может принимать входящие запросы.

вы можете настроить указанный c путь для доступа к вашему приложению. Однако nginx переписывает пути '/ readiness_check' и '/ liveness_check' в пути, указанные пользователем, при отправке запросов к приложению в виртуальной машине. Поэтому вы увидите «/ readiness_check» и «/ liveness_check» в журналах nginx.

Кроме того, если вы хотите применить прогрев к вашему App Engine, вы должны использовать настройку initial_delay_se c в разделе liveness_check. По умолчанию установлено значение 300, но вы можете изменить его на то, что, по вашему мнению, достаточно для того, чтобы приложение приняло запрос (вы можете указать его в диапазоне от 0 до 3600 секунд)

Answer 2

Это ожидаемое поведение. Nginx переписывает liveness_check и readiness_check в настраиваемый путь, предоставленный в файле app.yaml при регистрации проверок работоспособности, и поэтому в журналах вы увидите стандартные «/ readiness_check» и «/ liveness_check» в nginx logs.

App Engine создает избыточные копии каждой проверки работоспособности , а в случае сбоя проверки работоспособности избыточная копия вступает во владение без задержки.

Tthe nginx .health_check Журналы для вашего приложения показывают журналы для избыточных проверок работоспособности. Они автоматически создаются App Engine и не могут быть настроены.

Журналы пользовательских проверок работоспособности можно найти в разделе health_logs в разделе «Ведение журнала для приложения Google App Engine».

Там уже был Publi c Issue Tracker , созданный для этой проблемы, где он объясняет предыдущую информацию о проверках работоспособности в App Engine.