#0. はじめに

Amazon CloudWatch Logs サービスを理解、活用するために、Amazon CloudWatch Logs ユーザーガイドを一読して、個人用に概要と最低限設定しておくべきことをまとめる。
補足は、Amazon CloudWatch のよくある質問のよくある質問を参考にしている。

##0.1 概要、注意点など
(1) CloudWatch Logs

特徴

(2) IAMポリシー、IAMロール

IAMロールの注意点

(3) CloudWatch Logs エージェント
CloudWatch Logs エージェントは、Amazon Linux または Ubuntu を実行する Amazon EC2 インスタンスでログデータを CloudWatch Logs に自動送信する方法を提供する。

前提条件
リファレンス
サポートしているログローテート
エージェントを停止させた場合の挙動

(4) ログの保持期間の変更

ロググループに対して保持期間を設定することができる。
期限切れのログイベントは自動的に削除される。

(5) ログデータ送信タイミング

初回時

CloudWatch Logs エージェントを起動するとawslogs.conf の設定を読み込んで自動的に CloudWatch Logs へログが送信される。
CloudWatch Logs にプッシュするログファイルは「file」に設定する。ファイルのどの位置からデータの読み出しを開始するかを「initial_position」に設定する（デフォルトはファイルの先頭(start_of_file))。
なので、デフォルト設定では指定したファイルのすべての内容が送信される。

以降

次の条件のいずれかが満たされる場合にバッチがフルになり、データがPUSHされる(リアルタイム送信ではない）。

最初のログイベントが追加されてから、[buffer_duration] の時間が経過した(デフォルト 5000ms=5秒)。
累積されたログイベントの [batch_size] 未満ですが、新しいログイベントを追加すると [batch_size] を超過します(デフォルト　32768 バイト)。
ログイベント数は [batch_count] に達しました(デフォルト 1000)。
バッチのログイベントは 24 時間以上になりませんが、新しいログイベントを追加すると 24 時間の制約を超過します。

(6) ログエントリ、ログイベント、またはバッチがスキップまたは切り捨てられる原因

(7) メトリクス
※よくある質問から

Amazon CloudWatch のメトリクスでは何を測定できるのですか?
Amazon CloudWatch では、AWS のクラウドリソースや、お客様が AWS で実行するアプリケーションのモニタリングを行うことができます。
AWS の多数の製品とサービスについて、メトリクスが自動的に生成されます。
すべてのメトリクスの保存期間はどうなっていますか?
2016 年 11 月 1 日、CloudWatch はメトリックスの保存期間の延長を発表しました。これにより、お客様のすべてのメトリックスの保存期間が、従来の 14 日間から 15 か月間になりました。
CloudWatch Metrics で選択できる保存期間スケジュールは、次の 3 種類になりました。


1 分ごとのデータポイントを 15 日間保存
5 分ごとのデータポイントを 63 日間保存
1 時間ごとのデータポイントを 455 日間保存

* メトリクスは削除できますか? * *CloudWatch ではメトリクスの削除はサポートされません。メトリクスは上記の保存期間スケジュールに基づいて有効期間が切れます。* 　

* Amazon EC2 インスタンスのモニタリングを無効にした場合、メトリクスデータを失いますか? * *いいえ。すべてのアマゾン EC2 インスタンスのメトリックスデータは、上記の保存期間スケジュールに基づいて常に取得できます。* * *ただし、名前空間で最新のインスタンスが表示されるように、CloudWatch コンソールでのメトリクスの検索は、メトリクスが最後に取り込まれてから 2 週間に制限されます。*

* 終了した Amazon EC2 インスタンスや削除された Elastic Load Balancer のメトリクスデータにアクセスできますか? * *はい。Amazon CloudWatch は、終了した Amazon EC2 インスタンスまたは削除された Elastic Load Balancing のメトリクスを 15 か月間格納します。*

##0.2 設定例

###0.2.1 CloudWatch Logs を新規利用するための基本設定の手順例

[1] CloudWatch Logs の利用を許可するIAMポリシーを付加したIAMロールを作成

参考

3.1 クイックスタートステップ 1
3.2 クイックスタート

管理者権限ポリシーが付加されたIAMユーザでAWSマネジメントコンソールへサインインして、IAMサービスへ遷移する。(参考:IAM 管理者のユーザーおよびグループの作成)

　https://console.aws.amazon.com/iam

ナビゲーションペイン「ポリシー」

ポリシーの作成 ⇒ 独自のポリシーを作成 ⇒ 選択

・ポリシー名
CloudWatchLogs

・ポリシードキュメント

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

ポリシーの作成

ナビゲーションペイン「ロール」

新しいロールの作成

・ロール名
ec2role

ロールタイプの選択

・AWS サービスロール
「Amazon EC2」を選択

ポリシーのアタッチ

・作成した　CloudWatchLogs　ポリシーをアタッチする

ロールの作成

[2] 上記のIAMロールを割り当てた EC2 を作成

EC2インスタンス作成時の、「インスタンスの詳細の設定」画面の「IAM ロール」に作成した ec2role を選択する

[3] 上記のEC2インスタンスに CloudWatch Logs エージェントをインストール

参考
3.1 クイックスタートステップ 2

・インストール


$ sudo yum update
$ sudo yum install awslogs

・バージョン確認


$ yum info aws-cli-plugin-cloudwatch-logs

[4] CloudWatch Logs エージェントの設定ファイル編集

参考
3.1 クイックスタートステップ 2

/etc/awslogs/awscli.conf


[plugins]
cwlogs = cwlogs
[default]
region = ap-northeast-1

[5] CloudWatch Logs エージェントが送信するログファイルを設定

参考
3.1 クイックスタートステップ 2

3.8 CloudWatch Logs エージェントのリファレンス

/etc/awslogs/awscli.conf
デフォルト設定


[general]
state_file = /var/lib/awslogs/agent-state
　　　
[/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

[6] CloudWatch Logs エージェントの起動と、動作確認

参考
3.1 クイックスタートステップ 2
3.6 CloudWatch Logs エージェントの開始
3.5 CloudWatch Logs エージェントのステータスをレポートします

・起動


$ sudo service awslogs start
$ sudo chkconfig awslogs on

・プロセス動作確認


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

・/var/log/awslogs.log ファイルを開き、CloudWatch Logs エージェントのエラー、警告、問題等のメッセージが出ていないことを確認

[7] CloudWatch Logs へログが送信されているか確認

参考
3.9 ログデータの表示
logger コマンドで、/var/log/messages にメッセージを出力して、CloudWatch Logs へログが送信されているか確認する。5秒以内(buffer_duration = 5000)には、送信される。


$ logger test

[8] ログの保持期間の変更

参考
3.10 ログの保持期間の変更

CloudWatch サービスへ遷移する
　https://console.aws.amazon.com/cloudwatch

ナビゲーションペイン「ログ」

対象のロググループの "次の期間経過後にイベントを失効" の "失効しない" をクリック

お好みの保持期間へ変更する

###0.2.2 メトリクスフィルタ設定例

例: ログイベントのカウント
例: 単語「Error」の出現回数をカウントする
例: HTTP 404 レスポンスのカウント
例: 400 レベルを見つけて 4xx メトリクスにカウントする
例: Apache ログから転送されたバイト数の抽出

###0.2.3 CloudWatch Logs データを Amazon Elasticsearch Service にストリーミング

CloudTrail ログを Amazon ES へ送る

#Amazon CloudWatch Logs ユーザーガイド

#1. Amazon CloudWatch Logs とは?

Amazon CloudWatch Logs を使用して、Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、AWS CloudTrail、およびその他のソースのログファイルの監視、保存、アクセスができます。その後、CloudWatch Logs から、関連するログデータを取得できます。

特徴

Amazon EC2 インスタンスのログをリアルタイムでモニタリングする
CloudWatch Logs で、ログデータを使用してアプリケーションとシステムをモニタリングできます。たとえば、 アプリケーションログに存在するエラーの数をトラッキングし、エラー率が指定のしきい値を超えたときに管理者に通知を送ることができます。
お客様のログが CloudWatch Logs によるモニタリングに使用されるので、コードの変更は不要です。たとえば、 アプリケーションログの特定のリテラルターム（例:「NullReferenceException」）をモニタリングしたり、ログデータの特定の場所でリテラルターム（例: Apache アクセスログの「404」ステータスコード）の発生数をカウントしたりできます。
検索した語句が見つかると、CloudWatch Logs は指定された CloudWatch メトリクスにデータをレポートします。
ログデータは、転送時や保管時に暗号化されます。
AWS CloudTrail のログに記録されたイベントのモニタリング
CloudWatch にアラームを作成して、CloudTrail がキャプチャした特定の API アクティビティの通知を受け取り、通知をトラブルシューティングの実行に使用できます。
ログデータをアーカイブする
CloudWatch Logs を使用して耐久性が高いストレージにログデータを保存できます。ログの保持設定は、その設定よりも古いログイベントを自動的に削除するように変更できます。
CloudWatch Logs エージェントにより、ローテーションするログデータもローテーションしないログデータも、ホストからログサービスに簡単にすばやく送信できます。その後は、必要なときに生のログデータにアクセスできます。

##1.1 CloudWatch Logs 用語、概念

ログイベント
ログストリーム
ロググループ
メトリクスフィルタ
保持設定

##1.2 CloudWatch Logs の制限

#2. 準備作業
##2.1 アマゾンウェブサービス（AWS）にサインアップ
##2.2 Amazon CloudWatch コンソールにサインインする
##2.3 コマンドラインインターフェイスをセットアップする

#3. はじめに

このセクションでは Amazon Linux、Ubuntu Server、CentOS、Red Hat Enterprise Linux を実行する Amazon EC2 インスタンスに CloudWatch Logs エージェントをインストールするために必要なステップを説明します。

CloudWatch Logs エージェントの前提条件

CloudWatch Logs エージェントでは、Python バージョン 2.6、2.7、3.0、または 3.3、および次のいずれかのバージョンの Linux が必要です。

Amazon Linux バージョン 2014.03.02 以降
Ubuntu Server バージョン 12.04 または 14.04
CentOS バージョン 6、6.3、6.4、6.5、または 7.0
Red Hat Enterprise Linux (RHEL) バージョン 6.5 または 7.0
Debian 8.0

##3.1 クイックスタート: 既存の Amazon EC2 インスタンスに CloudWatch Logs エージェントをインストールして設定する

IAMロールの注意点

EC2 内で稼働している CloudWatch Logs エージェントから CloudWatch Logs へログを送信するには、それを許可する内容を記述した IAMポリシーが、EC2 の IAMロールに登録してある必要がある。
EC2 に IAMロールを割り当てることは、EC2 インスタンス作成時にしか出来ない。そのため、既存の EC2 で CloudWatch Logs を利用したいが、その EC2 に IAMロールが何も割り当てられていない場合は、新規に EC2 インスタンスを作成する必要がある。

ステップ 1: IAM ロールまたは CloudWatch Logs ユーザーを設定する

このステップ 1 では、既存の起動中 EC2 にすでに IAMロールが割り当てられていて、その IAMロールに次の IAMポリシーを作成して追加している。

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

ステップ 2: 既存の Amazon EC2 インスタンスに CloudWatch Logs エージェントをインストールして設定する

Amazon Linux AMI 2014.09 から、awslogs パッケージを使用した RPM のインストールに CloudWatch Logs エージェントが使用可能です。
手順

パッケージリポジトリの最新の変更を取得


$ sudo yum update

awslogs パッケージをインストール


$ sudo yum install awslogs

/etc/awslogs/awscli.conf ファイルを編集し、[default] セクションで、ログデータを表示し認証情報を追加するリージョンを指定

・ region は、東京リージョン(ap-northeast-1)を設定する。
・認証情報(aws_access_key_id, aws_secret_access_key)は不要。


[plugins]
cwlogs = cwlogs
[default]
region = ap-northeast-1

/etc/awslogs/awslogs.conf ファイルを編集して追跡するログを設定

・デフォルト設定では、/var/log/messages ファイルに出力されたログを CloudWatch Logs の「/var/log/messages」というロググループへ送信する。


[/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

awslogs サービスを開始


$ sudo service awslogs start

エージェントのステータス確認、動作確認
・ /var/log/awslogs.log ファイルでサービス開始時に記録されたエラーがあるかどうか確認
・エージェントが実行されてしばらくしたら、CloudWatch コンソールに新しく作成されたロググループとログストリームを確認

##3.2 [クイックスタート: 新規 Amazon EC2 インスタンスに CloudWatch Logs エージェントをインストールして設定する](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/EC2NewInstanceCWL.html)

この章で行っていること

/etc/awslogs/awslogs.conf ファイルを作成して、S3 へ置いている

IAMポリシー、IAMロールを作成している
IAMポリシーには、EC2からS3のバケットへのGetObjectを許可する設定を入れている
EC2 から S3のバケットにある　/awslogs.conf を取りに行くため
EC2インスタンを作成、起動する
このときに、先に作成した　IAMロールを割り当てる
ユーザーデータで、CloudWatch Logs エージェントをインストールするコードを入れている


#!/bin/bash
curl https://s3.amazonaws.com/aws-cloudwatch/downloads/latest/awslogs-agent-setup.py -O
chmod +x ./awslogs-agent-setup.py
./awslogs-agent-setup.py -n -r us-east-1 -c s3://myawsbucket/my-config-file

##3.3 クイックスタート: AWS OpsWorks および Chef を使用して CloudWatch Logs エージェントをインストールする

##3.4 クイックスタート: AWS CloudFormation を使用してログデータを CloudWatch Logs に送信する

##3.5 CloudWatch Logs エージェントのステータスをレポートします

エージェントのステータスを確認する方法その１ - コマンドで


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

エージェントのステータスを確認する方法その２ - ログから
/var/log/awslogs.log ファイルで CloudWatch Logs エージェントのエラー、警告、問題を確認してください。

##3.6 CloudWatch Logs エージェントの開始


$ sudo service awslogs start

##3.7 CloudWatch Logs エージェントの停止


$ sudo service awslogs stop

##3.8 [CloudWatch Logs エージェントのリファレンス](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/AgentReference.html)

CloudWatch Logs エージェントは、Amazon Linux または Ubuntu を実行する Amazon EC2 インスタンスでログデータを CloudWatch Logs に自動送信する方法を提供します。

エージェントは次のコンポーネントで構成されています。

ログデータを CloudWatch Logs にプッシュする AWS CLI プラグイン。
CloudWatch Logs にデータを送信する CloudWatch Logs aws logs push コマンドを実行するスクリプト (デーモン)。
デーモンが常に実行中であることを確認する cron ジョブ。

エージェント設定ファイル

CloudWatch Logs エージェント設定ファイルは、 aws logs push コマンドが必要とする情報を記述します。
エージェント設定ファイルのデフォルト設定
/etc/awslogs/awslogs.conf


[general]
state_file = /var/lib/awslogs/agent-state
　　　
[/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

datetime_format
ログからタイムスタンプを入手する方法を指定します。タイムスタンプはログイベントを取得し、メトリクスを生成するために使用されます。
file
CloudWatch Logs にプッシュするログファイルを指定します。ファイルは、特定のファイルまたは複数のファイルを指すことができます（/var/log/system.log* のようにワイルドカードを使用）。
access_log.2014-06-01-01 と access_log.2014-06-01-02 など同じ形式の一連のファイルを指定するにはワイルドカードの使用をお勧めします。ただし、access_log_80 と access_log_443 のように種類が異なる複数のファイルには使用しないでください。種類が異なる複数のファイルを指定するには、設定ファイルに別のストリームログのエントリを追加して、各種類のログファイルが異なるロググループに行くようにします。
圧縮ファイルはサポートされていません。
ファイルの変更時間に基づいて、最新のファイルのみが CloudWatch Logs にプッシュされます。
buffer_duration
ログイベントのバッチ期間を指定します。最小値は 5000ms で、デフォルト値は 5000ms です。
5000ms = 5秒
log_stream_name
送信先ログストリームを指定します。
initial_position
データの読み出しをどこから開始するかを指定します（start_of_file または end_of_file）。
デフォルトは start_of_file です。
そのログストリームに保持されている状態がない場合にのみ使用されます。
log_group_name
送信先ロググループを指定します。ロググループが存在しない場合には、自動的に作成されます。
batch_count
バッチのログイベントの最大値を 10000 までの値で指定します。デフォルト値は 1000 です。
batch_size
バッチのログイベントの最大値を 1048576 バイトまでのバイト値で指定します。デフォルト値は 32768 バイトです。このサイズは、UTF-8 のすべてのイベントメッセージの合計に各ログイベントにつき 26 バイトを加算して計算されます。

CloudWatch Logs エージェントのよくある質問

どのようなファイルローテーションがサポートされていますか。

次のファイルローテーション機能がサポートされています。

既存のファイルを数字サフィックスをつけた名前に変更し、その後、元の名前の空のログファイルを作成し直します。たとえば、/var/log/syslog.log が /var/log/syslog.log.1 という名前に変更されます。/var/log/syslog.log.1 が前回のローテーションにより既に存在する場合は、/var/log/syslog.log.2 という名前に変更されます。
元のログファイルを、コピーを作成した後切り捨てます。たとえば、/var/log/syslog.log を /var/log/syslog.log.1 にコピーし、/var/log/syslog.log を切り捨てます。この場合、データを損失する恐れがあるため、このファイルローテーション機能の使用にはご注意ください。
古いファイルと共通のパターンを持つ新しいファイルを作成します。たとえば /var/log/syslog.log.2014-01-01 をそのまま残し、/var/log/syslog.log.2014-01-02 を作成します。

使用しているエージェントのバージョンを確認する方法

yum から CloudWatch Logs エージェントをインストールした場合


$ yum info aws-cli-plugin-cloudwatch-logs
読み込んだプラグイン:priorities, update-motd, upgrade-helper
インストール済みパッケージ
名前                : aws-cli-plugin-cloudwatch-logs
アーキテクチャー    : noarch
バージョン          : 1.3.3
...

ログイベントはどのようにバッチされていますか

次の条件のいずれかが満たされる場合、バッチがフルになり発行されます。

最初のログイベントが追加されてから、[buffer_duration] の時間が経過した。
累積されたログイベントの [batch_size] 未満ですが、新しいログイベントを追加すると [batch_size] を超過します。
ログイベント数は [batch_count] に達しました。
バッチのログイベントは 24 時間以上になりませんが、新しいログイベントを追加すると 24 時間の制約を超過します。

ログエントリ、ログイベント、またはバッチがスキップまたは切り捨てられるのはどのような原因がありますか。

PutLogEvents オペレーションの制約に従って、次の問題によりログイベントまたはバッチがスキップされる場合があります。
ログイベントのサイズが 256 KB を超過した場合、ログイベントは完全にスキップされます。
ログイベントのタイムスタンプが 2 時間以上未来の場合、ログイベントはスキップされます。
ログイベントのタイムスタンプが 14 日以上過去の場合、ログイベントはスキップされます。
ログイベントがロググループの保持期間よりも古い場合、バッチはすべてスキップされます。
単一の PutLogEvents リクエストでログイベントのバッチが 24 時間実行されている場合、PutLogEvents オペレーションは失敗します。

エージェントを停止させた場合、データ損失や重複が発生しますか。

状態ファイルが使用可能であり、最後に実行された時からファイルのローテーションが発生していなければ、発生しません。 CloudWatch Logs エージェントは停止した場所から再開してログデータのプッシュを続行できます。

##3.9 ログデータの表示

##3.10 ログの保持期間の変更

デフォルトでは、ログデータは永続的に保存されます。 ただし、ロググループにログデータを保存する期間を設定できます。現在の保持設定より古いデータはすべて自動的に削除されます。各ロググループのログの保持期間は、いつでも変更できます。

次の期間経過後にイベントを失効
デフォルトは「失効しない」・・・永続的に保存

#4. ログデータの検索およびフィルタリング

CloudWatch Logs エージェントが Amazon CloudWatch へのログデータの発行を開始した後、1 つ以上のメトリクスフィルタを作成して、ログデータの検索およびフィルタリングを開始できます。
メトリクスフィルタは CloudWatch Logs に送信されたログデータを検索するための語句とパターンを定義します。CloudWatch Logs はこれらのメトリクスフィルタを使用して、ログデータをグラフの作成やアラームの設定に利用できる CloudWatch メトリクスに変換します。

各メトリクスフィルタは以下のキー要素で構成されています。

フィルタパターン

各ログイベントのデータを CloudWatch Logs がどのように解釈するかについての記号による説明です。たとえば、ログエントリにはタイムスタンプ、IP アドレス、文字列などが含まれる可能性があります。パターンを使用して、ログファイルの検索対象を指定します。

メトリクス名

モニタリングされたログ情報が発行される CloudWatch メトリクスの名前です。たとえば、ErrorCount というメトリクスに発行できます。

メトリクス名前空間

新しい CloudWatch メトリクスの送信先名前空間です。

メトリクス値

メトリクスに発行するものです。たとえば、「Error」など特定の語句の発生回数をカウントする場合、その値は発生するごとに「1」になります。転送されたバイト数をカウントする場合は、発行される値はログイベントの値になります。

##4.1 フィルタとパターンの構文

メトリクスフィルタで指定されたものに一致する語句や値が、ログイベントの中で検索されます。
メトリクスフィルタは、ログイベントで語句、フレーズ、値を 1 つ見つけるたびに CloudWatch メトリクスでカウントします。
たとえば、ログイベントの中で ERROR という単語を検索して出現回数を数えるメトリクスフィルタを作成します。メトリクスフィルタには、スペースで区切られたログイベントから値を抽出する機能もあります。
たとえば、ウェブリクエストのレイテンシーです。条件演算子やワイルドカードを使用して完全一致を見つけることもできます。メトリクスフィルタを作成する前に、CloudWatch コンソールで検索パターンをテストできます。

##4.2 メトリクスフィルタの作成

(1) 例: ログイベントのカウント

/var/log/messages のログイベントのカウント設定例

CloudWatch コンソール
　https://console.aws.amazon.com/cloudwatch/

リージョン確認(今回は東京)

ナビゲーションペイン「ログ」

コンテンツペインでロググループ「/var/log/mesages」を選択して、「メトリクスフィルタの作成」

ログメトリクスフィルタの定義

・フィルタパターン
　空のまま
・テストするログデータの選択
　そのまま

メトリクスの割り当て

メトリクスフィルタの作成とメトリクスの割り当て

・フィルタの名前
　VarLogMessagesCount
・メトリクス名前空間
　Test1NameSpace
・メトリクス名
　VarLogMessagesEventCount

フィルタの作成

ロググループ「/var/log/mesages」のメトリクスフィルタが「1フィルタ」となる

メトリクスの状態をグラフで確認する
- 今回のメトリクスフィルタでは、フィルタパターンを空にしたため、/var/log/messages の行にマッチする。
- メトリクス値が１なので、１行出力したら１インクリメントされる。

CloudWatch コンソール
　https://console.aws.amazon.com/cloudwatch/

リージョン確認(今回は東京)

ナビゲーションペイン「メトリクス」

さきほど作成したメトリクス名前空間(Test1NameSpace)を選択

さきほど作成したメトリクス名(VarLogMessagesEventCount)を選択

「グラフ化したメトリクス(1)」タブを選択

「統計」を平均から合計へ変更する

/var/log/messages に出力された行の合計グラフ（期間:５分）

logger コマンドで、/var/log/messages にメッセージを出力してグラフを確認

(2) 例: 単語「Error」の出現回数をカウントする

/var/log/messages ファイルに出力された、単語「Error」の出現回数をカウントする

CloudWatch コンソール
　https://console.aws.amazon.com/cloudwatch/

リージョン確認(今回は東京)

ナビゲーションペイン「ログ」

コンテンツペインでロググループ「/var/log/mesages」を選択して、「メトリクスフィルタの作成」

ログメトリクスフィルタの定義

・フィルタパターン（パターンは大文字と小文字を区別する)
　Error

フィルターテストを行う場合
・テストするログデータの選択
　- カスタムログデータ -
・パターンテスト
　テキストエリアにテストしたいログメッセージを入力する
　※loggerコマンドを使ったりなんかしてそれらしいメッセージを作成したもの


Dec 23 04:58:01 ip-10-0-0-144 dhclient[2136]: XMT: Solicit on eth0, interval 117980ms.
Dec 23 04:59:22 ip-10-0-0-144 ec2-user: This is a test error messages.
Dec 23 04:59:53 ip-10-0-0-144 ec2-user: This is a test Error messages.
Dec 23 04:59:59 ip-10-0-0-144 dhclient[2136]: XMT: Solicit on eth0, interval 110540ms.
Dec 23 05:01:50 ip-10-0-0-144 dhclient[2136]: XMT: Solicit on eth0, interval 115710ms.
Dec 23 05:02:01 ip-10-0-0-144 ec2-user: error
Dec 23 05:02:04 ip-10-0-0-144 ec2-user: Error

パターンのテストを実施する ⇒ 結果を確認する

メトリクスの割り当て

メトリクスフィルタの作成とメトリクスの割り当て

・フィルタの名前
　VarLogMessagesErrorCount
・メトリクス名前空間
　Test1NameSpace
・メトリクス名
　VarLogMessagesEventErrorCount

フィルタの作成

ロググループ「/var/log/mesages」のメトリクスフィルタが「2フィルタ」となる

メトリクスの状態をグラフで確認する
- 今回のメトリクスフィルタでは、/var/log/messages ファイル内に単語「Error」がある行にマッチする。
- メトリクス値が１なので、マッチする行があったら１インクリメントされる。

CloudWatch コンソール
　https://console.aws.amazon.com/cloudwatch/

リージョン確認(今回は東京)

ナビゲーションペイン「メトリクス」

さきほど作成したメトリクス名前空間(Test1NameSpace)を選択

このとき、/var/log/messages にまだ単語「Error」のある行がない場合、先ほど作成したメトリクス名「VarLogMessagesEventErrorCount」はない。
テストとして、loggerコマンドで /var/log/messages に単語「Error」を出力させる。


$ logger "This is a test error messages."
$ logger "This is a test Error messages."
$ logger error
$ logger Error

しばらくすると、「VarLogMessagesEventErrorCount」が表示される

さきほど作成したメトリクス名(VarLogMessagesEventErrorCount)を選択

「グラフ化したメトリクス(1)」タブを選択

「統計」を平均から合計へ変更する

/var/log/messages ファイル内に単語「Error」がある行の合計グラフ（期間:５分）

(3) 例: HTTP 404 レスポンスのカウント

(4) 例: 400 レベルを見つけて 4xx メトリクスにカウントする

(5) 例: Apache ログから転送されたバイト数の抽出

##4.3 メトリクスフィルタの一覧表示
ロググループ内のメトリクスフィルタを一覧表示

##4.4 メトリクスフィルタの削除

※メトリクスの削除について

##4.5 フィルタパターンを使用したログデータ検索

Amazon CloudWatch コンソールのフィルタとパターンの構文を使用してログデータを検索できます。ロググループ内のすべてのログストリームを検索するか、このデータのサブセットを検索できます。

#5. サブスクリプションを使用したログデータのリアルタイム処理
サブスクリプションを使用して CloudWatch Logs からのログイベントのリアルタイムフィードにアクセスし、カスタム処理、分析、他のシステムへのロードを行うために、Amazon Kinesis ストリームや AWS Lambda などの他のサービスに配信することができます。

CloudWatch ログは、Lambda を使用してログデータを Amazon Elasticsearch Service に配信する。
⇒7. Amazon ES へのストリーミングログデータ

#6. ログデータを一括で Amazon S3 にエクスポートする

#7. Amazon ES へのストリーミングログデータ
CloudWatch Logs サブスクリプションを通して、ほぼリアルタイムでAmazon Elasticsearch Service (Amazon ES) クラスターで受け取るCloudWatch Logs ロググループをストリームデータに設定することができます。 CloudWatchコンソールによりこの設定を補助するための簡単なウィザードが提供されています (Lambdaファンクションも自動生成してくれる)。

大量の CloudWatch Logs データを Amazon ES にストリーミングすると、AWS 請求書の利用料金が高額になる可能性があります。予想より高い金額にならないように、AWS 請求書を監視することをお勧めします。

CloudTrail ログを Amazon ES へ送る設定手順

注意
CloudTrail ログを CloudTrailログをCloudWatch Logsへ送信する設定が済んでいること
Amazon ES 料金が発生する
ログデータのフロー「CloudTrail → CloudWatch Logs → Amazon Lambda → Amazon ES」

[1] Amazon ES ドメインを作成する

Amazon Elasticsearch Service コンソール
　https://console.aws.amazon.com/es/

リージョン確認(今回は東京)

Get started

Define domain

・Elasticsearch domain name
　cloudtrail

・Elasticsearch version
　2.3

Configure cluster (今回はテスト用なのでなるべく最小構成)

Node configuration

・Instance count
　1
・Instance type
　t2/micro

Storage configuration

・Storage type
　EBS

Set up access policy
　今回は、接続元IPアドレス制限

・Set the domain access policy to
　Allow access to the domain from specific IP(s)
　↓
　今回は、自宅のインターネット回線のIPアドレスを入力

Review

Domain status が Loading → Active になるまで暫く待つ

↓

[2] CloudWatch Logs データを Amazon ES へAmazon ES へストリーミングする

Amazon CloudWatch コンソール
　https://console.aws.amazon.com/cloudwatch/

ナビゲーションペイン「ログ」

cloudtrail のロググループを選択 ⇒ アクション ⇒ Amazon Elasticsearch Service へのストリーミングの開始

Amazon Elasticsearch Service への CloudTrail/test-logs のストリーミングを開始する

・アカウントの選択
　このアカウント
・Amazon ES クラスター
　cloudtrail （[1]で作成したもの)
・Lambda IAM 実行ロール
　新しいIAMロールの作成