心配な量の460
Application Load Balancerのログのステータスコード。時間、サーバー、リクエストURLに関して、これらのコードにパターンは見られません。 このフォーラムの投稿 によると、460は次のことを意味します:
クライアントは、フロントエンド接続またはバックエンド接続のいずれかでアイドルタイムアウトが発生する前に、ALBとの接続を閉じました。
バックエンドサーバーへのリクエストが表示され、バックエンドが問題なく非常に迅速にリクエストを処理します。これらのエラーが発生するのはなぜですか?このALBは、6〜8台のバックエンドサーバーで大量のトラフィックを処理します。
ALBログの例:
https 2017-01-30T22:46:27.451363Z app/LOAD-BALANCER/bbab458ad0b80d X.X.X.X:55999 10.5.X.X:80 0.000 -1 -1 460 - 132 0 "GET https://www.website.com:443/app/page HTTP/1.1" "-" ECDHE-RSA-AES128-SHA TLSv1 arn:aws:elasticloadbalancing:us-west-2:743462462234:targetgroup/TARGET-GROUP/e6120e5adr245b79107e "Root=1-588fc23e-77aea5adf4534af3de09659d13a08"
バックエンドからのNGINXログの例:
X.X.X.X 1485807955.048 www.website.com /app/page - GET 200 - 0.056 24 text/html; charset=UTF-8 -
ステータスコード460のドキュメントがApplication Load Balancer用に更新されました。
このエラーは、ロードバランサーがクライアントからリクエストを受信したが、アイドルタイムアウト期間が経過する前にクライアントがロードバランサーとの接続を閉じたときに発生します。
クライアントのタイムアウト期間がロードバランサーのアイドルタイムアウト期間より大きいかどうかを確認します。クライアントのタイムアウト期間が経過する前にターゲットがクライアントに応答するようにするか、クライアントがこれをサポートしている場合は、ロードバランサーのアイドルタイムアウトと一致するようにクライアントのタイムアウト期間を増やします。
ここで完全なドキュメントを読むことができます: http://docs.aws.Amazon.com/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html#http-460-issues
このシーケンスにはおそらく手掛かりがあります:
0.000 -1 -1 460-
フィールドは、request_processing_time、target_processing_time、response_processing_time、elb_status_code、target_status_codeです。
Target_processing_timeおよびresponse_processing_timeフィールドが-1の場合、ターゲットホストへのリクエストのディスパッチに問題があったことを示しています http://docs.aws.Amazon.com/elasticloadbalancing/latest/application/load-balancer- access-logs.html
ターゲットがリクエストを受け取っていることを確認してください。ALBとターゲットの間に構成またはネットワークの問題がある可能性があります。 ALBは、リクエストをターゲットに送信するときに、トレースヘッダーX-Amzn-Trace-Idをリクエストに挿入します。おそらく、NGINXバックエンドにこれらを記録し、失敗している特定のリクエストを取得しているかどうかを確認します。
私は同様の問題に対処してきましたが、TCPパケットがWindowsホストでオフロードするため、TCPオフロードが原因でパケットがドロップすることに関連しているようです。