0

Я развертываю приложение Go с помощью AppEngine flexible. Ниже приведена моя app.yaml. Иногда после его развертывания он стабилизируется в 1 экземпляре (это приложение с очень низкой загрузкой), но большую часть времени он постоянно возрождается в 6 экземпляров. Мои журналы заполнены сообщениями, показывающими созданные новые экземпляры. В этом приложении почти нулевая нагрузка, почему AppEngine flexible постоянно уничтожает и обновляет экземпляры?AppEngine Гибкие экземпляры, постоянно обновляющиеся

Log показывает постоянные паки:

Log showing constant respawning.

app.yaml

runtime: go 
api_version: go1 
env: flex 

handlers: 
- url: /.* 
    script: _go_app 

health_check: 
    enable_health_check: True 
    check_interval_sec: 10 
    timeout_sec: 4 
    unhealthy_threshold: 2 
    healthy_threshold: 2 

automatic_scaling: 
    min_num_instances: 1 
    max_num_instances: 10 
    cool_down_period_sec: 120 # default value 
    cpu_utilization: 
    target_utilization: 0.5 
+0

Что произойдет, если вы отправите запрос на получение url '/ _ah/health' любого из ваших экземпляров? –

+0

Я получаю 200 «хорошо» от моей конечной точки проверки работоспособности. –

+0

Это может быть проблема с платформой. Мы должны сначала исключить, что экземпляр действительно вреден для здоровья. Респайны чаще всего вызывают неудачные или невосприимчивые проверки здоровья. В соответствии с вашими настройками экземпляр должен быть неактуальен в течение 20 секунд (2 проверки работоспособности), чтобы потенциально вызвать респаун (3 для безопасности). Имеются ли в журналах проверки работоспособности '/ _ah/health' какие-либо сбои или ответы более чем на 30 секунд? Какова временная шкала этой проблемы респауна? Каково использование процессора и памяти, например, для экземпляров вашего приложения? Это приложение Hello World ** go ** flex делает это? – Nicholas

ответ

1

Проблема был с моей проверкой здоровья функции. Первоначально он выглядел следующим образом:

func healthCheckHandler(w http.ResponseWriter, r *http.Request) { 
    return 
} 

Затем я обнаружил это предложение в документации о том, как экземпляры удалось:

Вы можете написать свой собственный пользовательский код медицинской проверки. Он должен отвечать на запросы/_ah/health с кодом статуса HTTP 200. Ответ должен содержать тело сообщения, однако значение тела игнорируется (оно может быть пустым).

Так что я изменил функцию проверки здоровья, чтобы написать простой «ОК» в ответ:

func healthCheckHandler(w http.ResponseWriter, r *http.Request) { 
    w.Write([]byte("ok")) 
    return 
} 

экземпляры теперь ведут себя в соответствии с моими настройками AutoScale! Просветление исчезло.

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

 Смежные вопросы

  • Нет связанных вопросов^_^