LoginSignup
3
3

More than 1 year has passed since last update.

【Rails】EC2サーバーのエラーログを確認する方法

Last updated at Posted at 2021-10-14

先日unicornの自動デプロイでエラーが起き、解決に時間がかかってしまったため、エラーログで素早く原因究明するための手順を備忘録としてアウトプットしていきます。

前提条件(本番環境)

・仮想OS:AWS(EC2)
・WEBサーバ:Nginx
・アプリケーションサーバ:unicorn
・データベース:MariaDB

エラーログを確認する際の注意点

※unicornでエラーが起きた場合の、エラーログの確認場所はすでに自身で設定しているはずです。
 そのため人によってディレクトリ名が異なる場合があります。以下を確認しましょう。

config/unicorn.rb
(省略)

#エラーのログを記録するファイルを指定
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です。

production.png

サーバーログを記録する場所で、いわば「EC2内での出来事を記録している場所」です。
Ruby on Railsを例にすると、開発環境でrails sを使ってアプリケーションを実行したとき、様々なログが表示されるのと同じ役割を持っています。

unicorn.stderr.log

ターミナルにmaster failed to start, check stderr log for detailsと表示された時に確認するlogです。

エラー2.png

今回はこちらの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サーバーのエラーログを確認する方法でした。
ご指摘などあれば、ご教授いただけると幸いです。

3
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
3