セールス採用 / グシャッてからが本当の自分だった
セールス採用 / グシャッてからが本当の自分だった
2018.04.12
#35
バックエンドへの道

AWS EC2でWordPressを動かすときに設定したい「CloudWatch ログ」

エリカ

こんにちは。ディレクターのエリカです。

AWSで複数台のEC2インスタンスでWordPressを動作させる場合、エラーログはどうしてますか?

WordPressが稼働中のサイトで何か問題があったときなど、エラーログを確認したいですよね? でもそのサーバーにはセキュリティの設定で直接接続できない、複数稼働しているのでそれぞれのIPアドレスがわからないなどで、結局エンジニアさんにお願いすることになってしまいます。

そんな場合にオススメなのがCloudWatchログです。

AWSのEC2やECS上でWordPressを動かす場合、例えばエンジニアさんに「このログとあのログはCloudWatchログに送信しておいてください」と伝えておけば、いつでもどこでもログを確認できるようになります(CloudWatchコンソールに接続さえできれば)。

目次

  1. EC2の設定
  2. WordPressの設定
  3. CloudWatchの設定
    • メトリクスフィルタ
  4. まとめ

EC2の設定

まずは、以下のインラインポリシーをWordPressが動作しているEC2のロールに割り当てます。これは、EC2上で動作するCloudWatchログエージェントに、CloudWatchログに対して、グループやストリームの作成、ログの書き込みなどのアクションを許可しています。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents",
        "logs:DescribeLogStreams"
    ],
      "Resource": [
        "arn:aws:logs:*:*:*"
    ]
  }
 ]
}

 
次に、EC2インスタンスに接続し、CloudWatchログエージェントをインストールします。

$ sudo yum install -y awslogs

 
以下の設定ファイルのリージョンを確認します。初期値はus-east-1ですので、必要に応じて変更します。エージェントは、ここで指定したリージョンのCloudWatchログに対して送信します。

$ sudo vi /etc/aswlogs/awscli.conf

[default]
region = us-east-1

 
次に、どのログをCloudWatchログに送信するかの設定を行います。
/etc/awslogs/awslogs.confを編集します。

$ sudo vi /etc/awslogs/awslogs.conf

[/var/log/messages]
datetime_format = %b %d %H:%M:%S
file = /var/log/messages
buffer_duration = 5000
log_stream_name = {instance_id}
initial_position = start_of_file
log_group_name = /var/log/messages

上記が初期値です。

[/var/log/php-fpm/www-error.log] // セクション名。ユニークにすることにより複数のセクションを設定可能。
datetime_format = %d-%b-%Y %H:%M:%S // ログの中に記述されている文字列が、このフォーマットに合致した場合にCloudWatchログに日時として解釈させることができる。
file = /var/log/php-fpm/www-error.log // 送信するファイル
buffer_duration = 5000 // ログの送信間隔。
log_stream_name = {instance_id} // 定義済みの変数も利用できます。これはインスタンスIDです。
initial_position = start_of_file // 開始位置です。
log_group_name = /var/log/php-fpm/www-error.log // CloudWatchログに登録されるログググループ名になります。

上記のように設定し、awslogsを起動します。自動起動も設定しておきます。

$ sudo service awslogs start
$ sudo chkconfig awslogs on

次にPHPの設定で、/var/log/php-fpm/www-error.logをerror_logにセットします。
これは、error_log()関数の出力先になります。

これで、error_log()関数を利用すると、/var/www/php-fpm/www-error.logにエラーが出力され、そして、その内容をCloudWatchで見ることができるようになります。

WordPressの設定

次にWordPressの設定を、エラーが先ほど指定したファイルに出力されるように変更します。

wp-config.phpを編集します。

define('WP_DEBUG', true);
define('WP_DEBUG_DISPLAY', false);
define('WP_DEBUG_LOG', false);
ini_set('log_errors', 1);

WP_DEBUG_LOGをtrueにすると、コンテンツディレクトリ直下のdebug.logが、error_logとして設定されてしまうので、PHPの設定のまま(この記事の場合は、/var/www/php-fpm/www-error.log)を利用するようにします。そして、ini_set('log_errors', 1);とすることにより、errorの出力フラグのみをOnにします。

これで、WordPressを動かしたときのすべてのエラーが記録されていきます。

CloudWatchの設定

error_log()を実行するなどして、/var/www/php-fpm/www-error.logにエラーが出力されているのを確認します。

その後、CloudWatchコンソールのロググループ一覧ページにアクセスすると、/var/log/php-fpm/www-error.logというロググループが作成されています。

ロググループ > ログストリーム と進むと、先ほど確認したのと同じ内容のエラーが表示されます。

今回の設定では、ログストリームの名称がEC2インスタンスIDになっています。CloudWatchログを利用していれば、EC2を複数台利用して運用する場合に、すべてのインスタンスのエラーをコンソール上で確認することができますので、それぞれのインスタンスのエラーを確認するといった作業もせずにすみます。

また、ログの自動削除を無効にしていれば、EC2インスタンスが破棄されてしまった場合でも、ログの情報を保持しておくことができます。

メトリクスフィルタ

さらにCloudWatchログにメトリクスフィルタを適用すると、アラームに利用できます。例えば、任意の文字列が含まれているエラーログが記録された場合には、メールやSNSで通知を行う、といったCloudWatchのアラームを作成することができます。

まとめ

EC2上でWordPressを利用する場合には、CloudWatchログ、おすすめです。