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

先日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](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1884909/7e4773cb-6324-aa49-8cae-ecba34a8ab6c.png)

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

### unicorn.stderr.log

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

![エラー２.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1884909/ffd655ac-7266-7748-fc27-b7e84049932f.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の再起動コマンドが変更されたため、手動デプロイコマンドが使えなくなっているためです。

<br>
以上、EC2サーバーのエラーログを確認する方法でした。
ご指摘などあれば、ご教授いただけると幸いです。