share facebook facebook2 twitter menu hatena pocket slack

2013.01.02 WED

NginxのアクセスログにELBの”400 Bad Request”エラー(まとめ)

鈴木 宏康

WRITTEN BY鈴木 宏康

ELBの下のNginxで、下記のアクセスログが頻繁にみられました。
(“x.x.x.x”はELBのIPアドレスです)

x.x.x.x - [16/Nov/2012:00:00:17 +0900] 0.000 "-" 400 0 "-" "-" 0 0
x.x.x.x - [16/Nov/2012:00:00:18 +0900] 0.000 "-" 400 0 "-" "-" 0 0
x.x.x.x - [16/Nov/2012:00:00:18 +0900] 0.000 "-" 400 0 "-" "-" 0 0

上記の減少はElastic Load Balancer にぶら下がってる時の access logで非常に詳しく説明されていました。

つまり、ELBがsecond health checkと言われるコネクションを開いて閉じるだけの チェックを行い、それがNginxのアクセスログで”400 Bad Request”で拾われてるようです。

上記で紹介した日本語の情報は、Random requests from ELB generating 400 errors in Nginxをもとにしていると思います。

ここには、問題のログ(400 Bad Request)を出力しない方法なども紹介されています。

そして、上記で紹介した英語情報には、second health checkの情報もとも記載されていました。

ELB making many connections

There is a second health check that we implemented in Oct/Nov 2011, which behaves as you suggested — it opens a connection and closes it.

second health checkは2011/10-11に実装されており、そのヘルスチェックの 振る舞いは、コネクションを開いて閉じるのみのとなっています。

The reason for this second health check is that it provides protection against instances being terminated without being de-registered.

second health checkを行う理由は、ELBから取り外されず終了してしまう EC2インスタンスに対しても、ELBがより問題なく動作できるようにするためです。

ということで、単にELBのヘルスチェック拾っているだけなので、そこまで問題視する 必要はないと思いますが、ログの解析などでうざったい場合は、この手のログは 出力しないようにコントロールした方がいいかもしれません。

こちらの記事はなかの人(suz-lab)監修のもと掲載しています。
元記事は、こちら

鈴木 宏康

鈴木 宏康

愛知県生まれ。東京工業大学大学院修士課程修了。在学時より、ベンチャー企業でインターネットに関する業務に携わり、現在はクラウド(主にAmazon Web Services)上での開発・運用を軸とした事業の、業務の中心として活躍。