500エラーはよく見るエラーではありますが、本番環境※でその原因を突き止めるのは大変難しいです。
※開発モード等で動作している場合は、500エラーを出す代わりに細かいエラー情報を表示してくれる場合がよくあるため、エラー原因の追及にそれほど苦労することはありません。
まず、することは二つです。
- アクセスの流れの確認
- 再現方法の確立
まず、500エラーを出しているのはどこかと言うことを突き詰める必要があります。なぜなら、そのエラーを出しているところ以外を調べても何も分からないという事があるからです。では、出している場所を把握する前に必要なのは何かというと、正常なアクセスにおいて、どのような流れでページを表示しているかを把握することです。例えば、次のような流れかも知れません。
- ブラウザー -> ロードバランサー
- ロードバランサー -> Webサーバー
- Webサーバー -> APPサーバー
- APPサーバーがHTMLページを生成
- APPサーバー -> Webサーバー
- Webサーバー -> ロードバランサー
- ロードランサー -> ブラウザー
この場合、APPサーバーがHTMLページを生成しているから500エラーを出しているのはAPPサーバーだ、とはなりません。どこのタイミングでも500エラーはでる可能性があるのです。また、ブラウザーによっては、サーバーが返した500エラーを隠してしまって、ブラウザー独自の500エラーを表示している場合だってあります。まず、知るべきは、それぞれが500エラーなどのエラーを表示する場合、どのような画面になるのかを知っておくことです。といっても、一般的にどのソフトがどの画面かどうかではありません。**セキュリティ上の理由でエラー画面を簡素化したり、ソフトウェア名やバージョンを出さない場合があります。**あなたが扱っている環境独自で知っておくと言うことです。後は、500を出している所がわかれば、そのサーバーのアプリケーションのエラーログを見ます。そのログからさらに必要な情報を見たり、解決方法を探ったりします。もし、どこで出いるかわからなければ、全てのサーバーについてログを見る必要があります。
次に、再現方法の確立です。何故かというと、たいていの場合、現在取得したエラーログだけでは解決できることはほとんど無いからです。エラーログに解決方法が書いているなどほとんどありません。より詳しいデバッグログや別の連携したソフトウェアのログを取得しないと何も分からない場合があります。その時必要になるのは再現です。デバッグログを有効にして再現すれば、すぐにログを確認できるでしょう。しかし、再現方法がわからない場合、デバッグログを有効にして運用とかが必要になります。しかし、デバッグログは速度低下や容量圧迫に繋がりますので、本番環境でいつまでも実施というのは難しい場合が多いです。だからこそ、再現方法が必要なのです。
他にも、再現方法がわかれば、開発環境で再現できるかという試せます。デバッグログでもよくわからず、開発モードでないと難しいというのもよくある話です。
ここまで来ればログから何が原因かわかっているはずです。あとは、バグを潰して、再現テストをするだけです。自分で作った物なのですから、わからないはずがないですね。
最後に、エラーログの見方となると…ソフトウェアによります。まさしく千差万別です。詳しい環境がわからないかぎり、誰も教えることはできないでしょう。