0

私はAppEngineを使用してGoアプリケーションをデプロイしています。以下は私のapp.yamlです。時には、私はそれが1インスタンス(それは非常に負荷の低いアプリケーションです)で安定しますが、たいていの場合、それは常に6つのインスタンスを上向きに再ポスペンドします。私のログには、新しいインスタンスが作成されたことを示すメッセージが埋め込まれています。このアプリケーションにはほぼゼロの負荷がありますが、AppEngineの柔軟性は常にインスタンスを破棄し再インスタンス化するのはなぜですか?一定の再生成を示すAppEngine柔軟なインスタンスが常に再作成

ログイン:

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'へのgetリクエストを送信するとどうなりますか? –

+0

私は健康診断のエンドポイントから200 'ok'を返します。 –

+0

プラットフォームに問題がある可能性があります。インスタンスが実際には不健康であることをまず除外する必要があります。 Respawnsは、ほとんどの場合、失敗または応答しないヘルスチェックによって発生します。あなたの設定に応じて、インスタンスはレスポンスを引き起こす可能性があるため、20秒間レスポンスが2回(ヘルスチェック2回)しか必要としません(3回は安全です)。ヘルスチェックログ '/ _ah/health'は30秒以上離れた失敗や反応を表示しますか?この復活の問題のタイムラインは何ですか?あなたのアプリケーションのインスタンスのようなCPUとメモリの使用法は何ですか? Hello World ** go ** flexアプリケーションはこれを行いますか? – Nicholas

答えて

1

問題は、私の健康チェック機能していました。私は、その後のインスタンスを管理する方法についてのドキュメントでこの文を発見し

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

:もともとはこのように見えた

あなたは、独自のカスタムの健康チェックコードを書くことができます。 HTTPステータスコード200の/ _ah/healthリクエストに応答する必要があります。応答にはメッセージ本文が含まれている必要がありますが、本文の値は無視されます(空でもかまいません)。

だから私は応答して、単純な「OK」を書くためにヘルスチェック機能を変更:

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

インスタンスは今私のオートスケールの設定に従って動作します!復活は消えてしまった。

私は当然のことながらドキュメントを近く読むべきですが、ヘルスチェックログに問題がないことを示しています。すべての健康診断は、通過したように見えました。うまくいけば、この情報は他人に役立つはずです。

関連する問題