先日unicornの自動デプロイでエラーが起き、解決に時間がかかってしまったため、エラーログで素早く原因究明するための手順を備忘録としてアウトプットしていきます。
前提条件(本番環境)
・仮想OS：AWS(EC2)
・WEBサーバ：Nginx
・アプリケーションサーバ：unicorn
・データベース：MariaDB
エラーログを確認する際の注意点
※unicornでエラーが起きた場合の、エラーログの確認場所はすでに自身で設定しているはずです。
そのため人によってディレクトリ名が異なる場合があります。以下を確認しましょう。
（省略）
# エラーのログを記録するファイルを指定
stderr_path "#{app_path}/log/unicorn.stderr.log"
（省略）
エラーログを確認する手順
※個人情報保護の観点から、一部コードを改変しています。
※ここでは分かりやすいようにlsコマンドを使って、適宜ディレクトリの中身を確認しています。
ユーザー名@PC名 ~ % cd .ssh/
ユーザー名@PC名 .ssh % ssh -i ダウンロードした鍵の名前.pem ec2-user@作成したEC2インスタンスに紐付けたElastic IP
例）％ ssh -i test.pem ec2-user@1.234.5.678
Last login: Wed Oct 13 02:31:20 2021 from 12.345.678.901.cyberhome.jp
__| __|_ )
_| ( / Amazon Linux 2 AMI
___|\___|___|
https://aws.amazon.com/amazon-linux-2/
8 package(s) needed for security, out of 24 available
Run "sudo yum update" to apply all updates.
[ec2-user@ip-123-45-67-890 ~]$ cd /var/www/アプリ名
[ec2-user@ip-123-45-67-890 アプリ名]$ cd current
[ec2-user@ip-123-45-67-890 current]$ ls
Capfile Gemfile.lock REVISION app babel.config.js config db log package.json public test.dio storage tmp yarn.lock
Gemfile README.md Rakefile assets_manifest_backup bin config.ru lib node_modules postcss.config.js spec test_move.dio test vendor
[ec2-user@ip-123-45-67-890 current]$ cd log
[ec2-user@ip-123-45-67-890 log]$ ls
production.log unicorn.stderr.log unicorn.stdout.log
[ec2-user@ip-123-45-67-890 log]$ less unicorn.stderr.log
まずEC2サーバーへログインしたのち、EC2サーバのlogディレクトリまで移動します。
lsコマンドでlogディレクトリの中身を見てみると、3種類のlogがあることが分かります。
このうち次の2つに注目します。
production.log
ブラウザにWe’re sorry, but 〜と表示された時に確認するlogです。
サーバーログを記録する場所で、いわば「EC2内での出来事を記録している場所」です。
Ruby on Railsを例にすると、開発環境でrails sを使ってアプリケーションを実行したとき、様々なログが表示されるのと同じ役割を持っています。
unicorn.stderr.log
ターミナルにmaster failed to start, check stderr log for detailsと表示された時に確認するlogです。
今回はこちらのlogの中身を確認してきます。
ファイルの中身を確認する方法
lessコマンドを使います
less unicorn.stderr.log
エラーログを効率よく確認する方法
lessコマンドでlogファイルを開くと、大量のlogが並んでいると思いますが、これを全て確認する必要はありません。
エラーログを確認する上で大切なのはエラーが起きた直後のlog、つまり最新のlog周りを見ていきます。
最新のログを確認する2つの方法
①lessコマンドでログファイルを開いた後、Shift + gでログファイルの一番下へ移動する。
②lessコマンドを実行する代わりに、tail -f ファイル名コマンドで最新のログを10行分だけ表示する。
①は全体を残しつつ最新ログから遡ることができ、②は最新ログだけを見ることができます。
どちらもメリットがあるため、状況に応じて使い分けていきましょう。
※ログファイルからは:wqで抜けられます。
エラーログの見つけ方
ここまできたら、あとはエラー原因が書かれているログを探して対処するだけです。
あくまで個人的な見解ですが、エラーログの特徴として次のことが挙げられます。
・他のログに比べてやや長文(少し飛び出している)
・「○○Error」や「○○ didn't」のようにErrorや否定文が含まれている
エラーが起きたら確認すること
自動デプロイ未設定の場合
・ローカル→GiuHubへのpushのし忘れはないか（mergeまで確認）
・GitHubからEC2への反映（git pull origin master）のし忘れはないか
・EC2サーバー側でエラーログの内容を確認し、原因を見つける
・データベースは正しく起動しているか
・EC2サーバー側の環境変数は正しく設定できているか
・EC2インスタンスの再起動を行ってみる
自動デプロイ設定済の場合
上記に加えて、
・unicornのプロセスをkillし忘れていないか(masterとworker両方をkill)
※これを行わなければ、自動デプロイでunicornを再起動できません。
・ローカルのターミナルかつアプリケーションのディレクトリで自動デプロイコマンドを実行しているか(自動デプロイコマンド→bundle exec cap production deploy)
※手動デプロイで使用していたunicornの再起動コマンドRAILS_SERVE_STATIC_FILES=1 unicorn_rails -c config/unicorn.rb -E production -Dは使うと「ArgumentError」になります。これは自動デプロイを設定したことで、unicornの再起動コマンドが変更されたため、手動デプロイコマンドが使えなくなっているためです。
以上、EC2サーバーのエラーログを確認する方法でした。 ご指摘などあれば、ご教授いただけると幸いです。