CloudWatch LogsでLinuxのログファイル監視を試してみた

AWS Summit 2014 New Yorkで発表された、CloudWatch Logsについて試してレポートします。

CloudWatch Logs


CloudWatch Logsエージェントのセットアップ

早速セットアップしましょう。
…と思いきや、早速クラスメソッドさんのブログに先を越されました。

Amazon CloudWatch Logsでログファイルを監視する – Developers.IO

上の記事では既存のインスタンスにCloudWatch Logsエージェントをインストールする方法を試しているので、こちらでは新規インスタンスでCloudWatch Logsエージェントをインストール・セットアップする方法を試します。

Quick Start: Install and Configure the CloudWatch Logs Agent on a New EC2 Instance

Step1. コンフィグファイルの作成

今回はAmazon Linuxで試すので、下記のAmazon Linux用のサンプルコンフィグを作成します。
ちなみに、例ではawslogs.cfgとしますが、名前は何でもよいようです。

[general]
state_file = /var/awslogs/state/agent-state  
 
[/var/log/messages]
file = /var/log/messages
log_group_name = /var/log/messages
log_stream_name = {instance_id}
datetime_format = %b %d %H:%M:%S

このコンフィグファイルをS3バケット上に保存します。
保管場所も、インスタンスのファイルシステムでも、HTTP/HTTPSでアクセスできるパブリックな場所でも、S3バケットでもよいとのこと。
今回はS3に保存しました。

s3://sekiyama-cloudwatch-logs/awslogs.cfg

Step2. IAMロールの作成

CloudWatch Logs用にIAMロールを作成します。
サンプルポリシーはこんな感じ。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:*",
        "s3:GetObject"
      ],
      "Resource": [
        "arn:aws:logs:us-east-1:*:*",
        "arn:aws:s3:::*"
      ]
    }
  ]
}

Step3. インスタンスの起動

インスタンスを起動します。
UserDataには以下のようなスクリプトを書きます。

#!/bin/bash
wget https://s3.amazonaws.com/aws-cloudwatch/downloads/awslogs-agent-setup-v1.0.py
chmod +x ./awslogs-agent-setup-v1.0.py
./awslogs-agent-setup-v1.0.py -n -r us-east-1 -c s3://sekiyama-cloudwatch-logs/awslogs.cfg

awslogs-agent-setup-v1.0.pyを実行する際に -c オプションでS3バケット上のコンフィグファイルを参照しています。
このスクリプト自体は対話的インストールが可能となっていますが、今回はUserDataでインストールするため、こんなふうに指定しています。便利。

ちなみに、Step2で作成したロールを忘れず割り当てておきます。

Launch Instance
以上でCloudWatch Logsエージェントのセットアップは終わりです。

試しに、CloudWatch Logsエージェントサービスの状態を確認してみます。

$ sudo service awslogs status
 (pid  1810) is running...

ちゃんと動いているようです。


ログメッセージの確認

では、早速マネジメントコンソールから操作して、ログメッセージを確認してみましょう。

ログメッセージの確認

今回、コンフィグファイルでは/var/log/messagesを監視するように設定しています。

CloudWatch Logs

これをドリルダウンするとこんな感じ。

CloudWatch Logs

ばっちり/var/log/messagesの中身が確認できました。


保存期間

ちょっと前の画面に戻ります。

CloudWatch Logs

ちょっとわかりにくいですが、この”Expire Events After”列の値のリンクをクリックすると、Log Groupごとの保存期間を変更できます。
デフォルトは無制限(Never Expire)の模様。
無制限の他に、1dayから10years(!)まで選択できます。

10years


フィルタ

保存期間と同じように、”Metrics Filter”列の値のリンクをクリックすると、対象のLog Groupに適用されるフィルタを設定できます。
試しに、ERRORという文字列をフィルタとして設定します。

ERROR

この画面上で、実際のログメッセージや任意入力のメッセージを使って、フィルタ設定を試せるようになっています。
いまはERRORは一度も出力されていないので、”Found 0 matches”と出ています。
“Assign Metrics”をクリックすると、フィルタ名等の設定になります。

https://moomindani.files.wordpress.com/2014/07/e382b9e382afe383aae383bce383b3e382b7e383a7e38383e38388-2014-07-11-0-32-51.png

適切な値を入力して、”Create Filter”をクリックします。

completed

フィルタ完成です。

/var/log/messagesに任意の文字列を出力するには、やっぱりloggerでしょう。

logger ERROR_CloudWatch_Logs_TEST

ばっちり記録されています。
test message

フィルタにマッチしたので、ERRORメトリクスの値が登録されています。
メトリクス

こんなふうに、CloudWatchメトリクスに値を登録するのにフィルタが使われます。
従来のCloudWatchと同じように、ログのマッチ回数によってSNSによって通知したり、夢広がりますね。


おわりに

以上、簡単にレポートしました。
CloudWatch Logsは個人的に注目しているサービスなので、今後もいろいろ検証してみたいと思います。

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

%d人のブロガーが「いいね」をつけました。