現在、かなり大きなHTTPフラッドを受信しています。これにより、nginxリバースプロキシが502 Bad Gatewayを生成します。
バックエンドサーバーへのプロキシとしてnginxを実行しているフロントエンドサーバーがありますが、connect() failed (110: Connection timed out) while connecting to upstream
エラーが大量に発生しています。それらのトン。プロキシサーバーをバイパスしてバックエンドに接続すると、サイトを問題なく実行できるため、リバースプロキシのどこかにあることがわかります。ただし、どうしてそれがタイムアウトになるのかを判断する方法がわかりません。
何か助けは?
centOS 6.2でnginx 1.2.3を実行
Nginxエラーロギングレベルをデバッグするためにすでにジャックしていると思います。そうでない場合は、そこから始めます。
あなたの最善の策は、おそらくstrace
を使用して、Nginxによって行われているシステムコールを表示することです。特に、connect()
呼び出しに注意を払い、これらの戻りコード(man 2 connect
はここで友達になることができます)。
その情報を入手したら、問題がフロントエンドプロキシに限定されているのか、プロキシとバックエンドアプリケーションサーバー間の相互作用に関係があるのかについて、知識に基づいた推測を行うことができます。
Dtraceプローブを使用したくない場合を除いて、これ以上の知識は必要ありません。
デバッグログレベルを設定します:/etc/nginx/nginx.conf:
...
http {
...
error_log /var/log/nginx/error.log debug; # todo testing remove me not for production use
...
}
別のウィンドウでtcpdumpをセットアップします。
tcpdump not port 22 -vvv -s0 -q -XXX
さらに別のウィンドウでログファイルを監視する:
tail -f /var/log/nginx/*
Nginxをstraceを使用してインタラクティブに起動します。
# top of /etc/nginx/nginx.conf:
daemon off; # todo testing remove me not for production use
その後
$ strace nginx
--with-debug
でコンパイルされたnginxを使用すると、さらにデバッグを行うことができます。次のコマンドを実行して確認します。
nginx -V 2>&1 | grep -- '--with-debug' # no output if not debug
デフォルトでコンパイルされないもう1つの優れたモジュールは HttpStubStatusModule です。おそらく、まともなセットアップには、カスタムコンパイルされたnginx(ディストリビューションのパッケージツールを使用した非常に推奨されるパッケージ)が必要です。
これらのほとんどは本番環境での使用には適していません。さらに統計情報が必要な場合は、nginxをgperfでコンパイルすることを検討してください。
トラフィックの多いサイトをデバッグしているようです。
debug
をdebug_connection
ディレクティブと共に使用すると、nginxエラーログにIPからのデバッグログのみが表示されます。
Nginx設定全体のデバッグオプションをアクティブにするのではなく、いくつかの有用なエラーログが表示されたら、reverse_proxy接続を担当するerror_log /path/to/some/file/ debug;
ブロックに別のlocation {..}
ディレクティブを追加します。
これにより、デバッグエラーログをIPのみから分離できます。
(ブラウザから)作成するリクエストに関連付けてみてください。
たとえば、次を確認してください: https://easyengine.io/tutorials/nginx/debugging/
先のレベルでは、Nginxの HttpEchoModule を使用できます
私はNginxがボトルネックであるとは決して知りませんでした。ほとんどの場合、それはバックエンドよりも機能を超えています。しかし、Nginxなしでテストしてエラーが見つからなかった場合は、次のいずれか(または両方)になります。
Nginxの設定を見ないと、誰も前者にコメントできません。そして、OSからの適切な出力がなければ、だれも後者についてコメントできません。