#0. はじめに
- Amazon CloudWatch Logs サービスを理解、活用するために、Amazon CloudWatch Logs ユーザーガイド を一読して、個人用に概要と最低限設定しておくべきことをまとめる。
- 補足は、Amazon CloudWatch の よくある質問 の よくある質問を参考にしている。
##0.1 概要、注意点など
(1) CloudWatch Logs
(2) 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) ログエントリ、ログイベント、またはバッチがスキップまたは切り捨てられる原因
- 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ロールを作成
- 管理者権限ポリシーが付加されたIAMユーザ でAWSマネジメントコンソールへサインインして、IAMサービスへ遷移する。(参考: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 エージェントをインストール
・インストール
$ 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 エージェントの起動と、動作確認
$ 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 へログが送信されているか確認
-
参考
-
logger コマンドで、/var/log/messages にメッセージを出力して、CloudWatch Logs へログが送信されているか確認する。5秒以内(buffer_duration = 5000)には、送信される。
$ logger test
- CloudWatch サービスへ遷移する
https://console.aws.amazon.com/cloudwatch
- ナビゲーションペイン「ログ」
- 対象のロググループの "次の期間経過後にイベントを失効" の "失効しない" をクリック
- お好みの保持期間へ変更する
###0.2.2 メトリクスフィルタ設定例
- 例: ログイベントのカウント
- 例: 単語「Error」の出現回数をカウントする
- 例: HTTP 404 レスポンスのカウント
- 例: 400 レベルを見つけて 4xx メトリクスにカウントする
- 例: Apache ログから転送されたバイト数の抽出
###0.2.3 CloudWatch Logs データを Amazon Elasticsearch Service にストリーミング
#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 エージェントでは、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 エージェントをインストールして設定する
- 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
##3.2 [クイックスタート: 新規 Amazon EC2 インスタンスに CloudWatch Logs エージェントをインストールして設定する](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/EC2NewInstanceCWL.html)
- エージェントのステータス確認、動作確認
・ /var/log/awslogs.log ファイルでサービス開始時に記録されたエラーがあるかどうか確認
・ エージェントが実行されてしばらくしたら、CloudWatch コンソールに新しく作成されたロググループとログストリームを確認
この章で行っていること
- /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 エージェントのステータスをレポートします
- エージェントのステータスを確認する方法その1 - コマンドで
$ sudo service awslogs status
awslogs (pid 8281) is running...
- エージェントのステータスを確認する方法その2 - ログから
- /var/log/awslogs.log ファイルで CloudWatch Logs エージェントのエラー、警告、問題を確認してください。
##3.6 CloudWatch Logs エージェントの開始
$ sudo service awslogs start
##3.7 CloudWatch Logs エージェントの停止
$ sudo service awslogs stop
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 メトリクスフィルタの作成
- /var/log/messages のログイベントのカウント設定例
- CloudWatch コンソール
https://console.aws.amazon.com/cloudwatch/
- リージョン確認(今回は東京)
- ナビゲーションペイン「ログ」
- コンテンツペインでロググループ「/var/log/mesages」を選択して、「メトリクスフィルタの作成」
- ログメトリクスフィルタの定義
・フィルタパターン
空のまま
・テストするログデータの選択
そのままメトリクスの割り当て
- メトリクスフィルタの作成とメトリクスの割り当て
・フィルタの名前
VarLogMessagesCount
・メトリクス名前空間
Test1NameSpace
・メトリクス名
VarLogMessagesEventCountフィルタの作成
ロググループ「/var/log/mesages」のメトリクスフィルタが「1フィルタ」となる
-
メトリクスの状態をグラフで確認する
- 今回のメトリクスフィルタでは、フィルタパターンを空にしたため、/var/log/messages の行にマッチする。
- メトリクス値が1なので、1行出力したら1インクリメントされる。
- CloudWatch コンソール
https://console.aws.amazon.com/cloudwatch/
- リージョン確認(今回は東京)
- ナビゲーションペイン「メトリクス」
- さきほど作成したメトリクス名前空間(Test1NameSpace)を選択
- さきほど作成したメトリクス名(VarLogMessagesEventCount)を選択
- 「グラフ化したメトリクス(1)」タブを選択
「統計」を 平均 から 合計 へ変更する
/var/log/messages に出力された行の合計グラフ(期間:5分)
logger コマンドで、/var/log/messages にメッセージを出力してグラフを確認
- /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」がある行にマッチする。
- メトリクス値が1なので、マッチする行があったら1インクリメントされる。
- 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」がある行の合計グラフ(期間:5分)
(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ロールの作成
許可
- ログ形式とフィルタの設定
・ログの形式
AWS ÇloudTrail
- 確認
↓
ストリーミングの開始
※Lambdaファンクション(LogsToElasticsearch_cloudtrail)が自動作成される
※CloundWatch Logs (/aws/lambda/LogsToElasticsearch_cloudtrail) が自動生成される
[3] Kibana4 で CloudTrail ログを可視化
- Amazon Elasticsearch Service コンソール
https://console.aws.amazon.com/es/
- Indices 確認
[1] で作成したAmazon ES ドメイン「cloudtrail」をクリック
Indices タブをクリック
- Kibana サイトへ
Amazon Elasticsearch Service コンソール
https://console.aws.amazon.com/es/
[1] で作成したAmazon ES ドメイン「cloudtrail」をクリック
Kibana のURLをクリック
- Kibana 初期設定
・Configure an index pattern
Index contains time-based events:チェック
Index name or pattern: cwl-*
Time-field name: @timestamp
Create
↓
↓
Discover
#8. 認証とアクセスコントロール