【AWS発表】Amazon CloudWatchによるOSやログファイルの蓄積とモニタリング機能の提供

静的に運用されている環境からクラウドの力を活かし、動的にスケールする環境に移行する時、運用しているシステムやアプリケーションが出力するログファイルの取得、格納、分析するための構造を見直す必要があるでしょう。なぜなら、インスタンスは動的に変化するためログをそのインスタンスに長期に格納するのはむいていないからです。 スケールする環境でシステムを動作させるとき簡単にログファイルを格納する場所を探すことができ、古くなったログファイルの有効期限を管理する仕組みを導入するのは骨の折れる仕事です。さらに、しばしば対応しなければならない情報が埋もれてしまうこともあります。たとえ、100万または、10億のログデータうちの1つの失敗したログが埋もれただけだったとしても、そのログは、システムの信頼性を向上させる、または、ユーザエクスペリエンスを改善させる機会をあらわしているのです。

今日は、 Amazon CloudWatchの強力なログ格納とモニタリングの機能を紹介します。CloudWatchに対してOS、アプリケーションやカスタムのログファイルを投入することができ、そのログは、信頼性高いストレージに望む期間、格納できます。また、投入されるログの特徴、メッセージのモニタリングをCloudWatchに設定でき、結果をCloudWatchのメトリックスとして確認できます。例えば、Webログの間違ったリンクを検知するための404エラーや高負荷状態かもしれないことを503エラーを利用して監視することができます。Linuxサーバのログファイルを用いてスワップスペースやファイルディスクリプタの不足などリソース不足を監視することもできます。さらに、メトリックスを用いてアラームを出すことやAuto Scaling機能をアクティブにすることも可能です。

用語の整理
深い内容に入る前に、基本的な用語について整理しましょう。以下は、CloudWatchにログを格納し、監視するために理解する必要のある用語です。:

• Log Event - Log Eventは、 モニターされるアプリケーションやリソースが記録したアクティビティです。タイムスタンプとUTF-8でフォーマットされたメッセージで構成されます。
• Log Stream - Log Streamは、同じデータ発生元（特定のアプリケーションが動作するインスタンスやリソース）からのLog Eventのシーケンスです。
• Log Group - Log Groupは、同じプロパティ、ポリシやアクセスコントロールを共有するLog Streamのグループです。
• Metric Filters - Metric Filters は、監視するメトリックスをCloudWatchに投入しメトリックスにするときに抽出する方法です。
• Retention Policies - Retention Policiesは、イベントの保持期間に関する定義をします。Log Groupに関連づけられ、グループ内の全てのLog Streamに適用されます。
• Log Agent - Log Agentは、EC2インスタンスにインストールし、直接CloudWatchにLog Eventを送信するエージェントです。このエージェントはAmazon Linux AMIとUbuntu AMIでテストされています。

CloudWatch Logを試してみましょう
CloudWatch Logについて学ぶために、CloudWatch Log AgentをまさにこのBlogを書くのに使っているEC2インスタンスインストールしてみましょう。インストールスクリプトをダウンロードします。:

$ wget https://s3.amazonaws.com/aws-cloudwatch/downloads/awslogs-agent-setup-v1.0.py

そしてドキュメントに従って、IAMユーザを作成し、クレデンシャルを保存します。:

インストールスクリプトを実行します。スクリプトは、ダウンロードし、インストールを行い、(IAMユーザーのAWSクレデンシャルのプロンプトなどの)AWS CLIの設定を行います。インスタンス上の/var/log/messagesと /var/log/secureファイルからLog Eventをキャプチャするよう、Log Agentを設定します。:

Path of log file to upload [/var/log/messages]: 
Destination Log Group name [/var/log/messages]: 

Choose Log Stream name:
  1. Use EC2 instance id.
  2. Use hostname.
  3. Custom.
Enter choice [1]: 

Choose Log Event timestamp format:
  1. %b %d %H:%M:%S    (Dec 31 23:59:59)
  2. %d/%b/%Y:%H:%M:%S (10/Oct/2000:13:55:36)
  3. %Y-%m-%d %H:%M:%S (2008-09-08 11:52:54)
  4. Custom
Enter choice [1]: 1

Choose initial position of upload:
  1. From start of file.
  2. From end of file.
Enter choice [1]: 1

Log Groupは、数分後にAWS Management Consoleで確認することができます。:

今回は、一つのEC2インスタンスにLog Agentを入れたので、それぞれのLog Groupは、一つのLog Streamになります。Log Agentをインストールした時に、インスタンスIDをストリームの名前とするように設定しました。:

/var/log/secureのLog Streamをクリックしてみましょう。:

私のインスタンスに怪しいログインがどの程度起きているのかを確認するために、"invalid user"メッセージを追跡することにしました。Log Groupsのリスト画面に戻り、ストリームを選択、Create Metric Filterをクリックします。"invalid user"文字列を見つけるためのフィルタ設定を作成します。(パターンは大文字小文字を区別します。):

ご覧のとおり、コンソールで実際のログを用いてフィルタのテストを行うことできます。 結果を検証した時にログの中に幾つかのログインを試みているログを見つけることができました。ステップを進めてフィルタの名前やCloudWatchのネームスペースやメトリックスのマッピングを行います。:

無効なログインを試みている数が多く実行されてたことを気付くことができるように、メールでアラームを受け取る設定も行いました。:

ログとアラームが正しく設定されているかを確認するために、他のEC２インスタンスから怪しいログイン連発し、期待通りアラームが来ることを待ちます。:

それぞれのLog Groupの保持期間を設定します。ご覧のとおり、ログは永久に保持することもできます。（この場合のコストについての詳細は、下のノートを御覧ください。）:

Elastic Beanstalk と CloudWatch Logs
Elastic BeanstalkアプリケーションからCloudWatch Logsを生成することも可能です。 試していただくために、アプリケーションのルートディレクトリに.ebextensionsディレクトリをコピーして使うことができるサンプルのコンフィグレーションファイルを作成しました。 CWLogsApache-us-east-1.zipをフォルダに配置し、通常通りアプリケーションをビルド及びデプロイを行ってください。 Elastic BeanstalkのコンソールのMonitoringタブをクリックし、新しいリソースの場所とモニタリングとグラフを選択するためにEditボタンをクリックしてください。:

希望の統計を追加すると、Elastic Beanstalkはそれをグラフで表示します。:

その他のロギングオプション
AWS OpsWorksまたは、CloudWatch APIからCloudWatchにログデータをプッシュすることができます。 AWS CloudFormationを使ってログを設定したり、使用したりすることもできます。

AWS Application Management Blogの新しいブログ記事、「Using Amazon CloudWatch Logs with AWS OpsWorks」で、同僚のChris Barclayがスケーラブルで集中管理されたロギングソリューションを2,3のシンプルなレシピだけで作成するためにChefのレシピを使う方法を紹介しています。

CloudFormationを介して、CloudWatch LogsおよびMetrics Filtersを設定する方法についての詳しい情報は、Amazon CloudWatch Logs Sampleをご参照ください。テンプレートの一部を抜粋したものを紹介します。:

"404MetricFilter":{"Type":"AWS::Logs::MetricFilter","Properties":{"LogGroupName":{"Ref":"WebServerLogGroup"},"FilterPattern":"[ip, identity, user_id, timestamp, request, status_code = 404, size, ...]","MetricTransformations":[{"MetricValue":"1","MetricNamespace":"test/404s","MetricName":"test404Count"}]}}

コード内で、putLogEvents機能を使用して長いストリームに単一のLog Eventをプッシュすることができます。 PHPのスニペットは次のようになります。:

$result = $client->putLogEvents(array('logGroupName'  => 'AppLog,'logStreamName' => 'ThisInstance','logEvents'     => array(        array('timestamp' => time(),'message'   => 'Click!',        )    ),'sequenceToken' => 'string',));

料金と利用
この新機能は全てのAWSリージョンでご利用可能となっており、今すぐお試しいただけます。

価格は、登録されたログの量と維持する期間に基づきます。 詳細は、CloudWatchの料金ページをご覧ください。 Log Eventは、ストレージ料金を減らすために圧縮されて保存されます。Log Eventあたり、26バイトのストレージオーバーヘッドがあります。

-- Jeff;

この記事はAWSシニアエバンジェリスト Jeff BarrのAmazon Web Services Blogの記事、 Store and Monitor OS & Application Log Files with Amazon CloudWatchを 榎並 利晃が翻訳したものです。