nginx：（アプリケーションではなく）nginxからランダムな500を追跡する方法 潜在的に負荷と関係がありますか？

最近、なんとかログに記録されなかったnginx自体から約500がありました（スクリーンショットがありますが、ログには何もありません）。通常はエラーが表示されるため、それ自体は奇妙です。とにかく、接続プールのサイズのように、最大​​化すると500になるようなものがあるのでしょうか。最近のトラフィックの急増と潜在的に相関していますが、決定的なものではありません。

誰もがそのような問題に取り組み始める方法について何か考えがありますか？

nginxとlmonでログ形式の組み合わせを使用して、このようなことをキャッチします。次のようなNGINXログ形式：

log_format main '$ status：$ request_time：$ upstream_response_time：$ pipe：$ body_bytes_sent $ connection $ remote_addr $ host $ remote_user [$ time_local] "$ http_referer" "$ http_user_agent" "$ http_x_forwarded_for" $ upstream_addr $ upstream_cache_status in：$ http_cookie "'

リクエストを処理した上流サーバーなどの多くの役立つ診断情報をキャプチャし、ステータスを前面に表示するので、ログがかなり高速にスクロールしている場合でも読みやすくなります。

LMONを使用してこれらのログを監視し、ログに500 s、503 s、400 sなどのエラーが見つかった場合は、ページャー/電子メールで警告します。

http://www.bsdconsulting.no/tools/lmon-README

これは、問題が発生したときにそれをデバッグするのが最も簡単なときにアラートを受け取るのに役立ちます。

まだ検討していない場合に考慮すべきもう1つのことは、nginxはデフォルトで500を致命的な状態と見なし、別のアップストリームを試行しないことです。複数のアップストリームがある場合は、500を取得した場合に別のアップストリームを使用するように構成できます。うまくいけば、ユーザーからの失敗がわかりにくくなります。

http://wiki.nginx.org/NginxHttpProxyModule#proxy_next_upstream

error_log $filename debug; エラーログへのデバッグレベルのロギングをオンにします-これは、エラー発生時のnginxの内部ステータスの多くの詳細を提供し、-with-debug（デフォルトでいくつかのディストリビューションが行います）でコンパイルした場合もっとあげますよ。

「デバッグ」レベルでは実際に大量の出力が生成されるので、ディスク容量を監視したい場合があることに注意してください...

私の場合、confファイルの名前が正しくなく（example.com.confではなくexample.comでした）、含まれていませんでした。どういうわけか、これは「ようこそnginxへ」という結果にはならず、ログに記録されないHTTP 500エラーが発生しました。まあ、実際にはログに記録されていましたが、その特定のURLで動作しない別の仮想ホストからのエラーファイルにありました。