AWS再入門 – CloudWatch編

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

当エントリはDevelopers.IOで弊社AWSチームによる『AWS サービス別 再入門アドベントカレンダー 2015』の19日目のエントリです。昨日18日目のエントリはFujimura『AWS Lambda』でした。
このアドベントカレンダーの企画は、普段AWSサービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。
本日19日目のテーマは『Amazon CloudWatch』です。

Amazon CloudWatchとは

モニタリングサービス

CloudWatchは、AWSリソースとAWSで実行するアプリケーションのモニタリングサービスです。各種AWSサービスのメトリックスやログファイルを収集、モニタリングしアラームを設定出来ます。
対応するAWSサービスを開始すると、データポイントを定期的にCloudWatchに送信するため、特に意識せずともメトリックスをグラフィカルな画面で閲覧、分析出来ます。カスタムメトリックスを用意すれば、独自のアプリケーションから収集したメトリックスについても、グラフィカルなグラフを利用できます。
アラーム機能を使うと、SNSを使った通知はもちろんのこと、AutoScalingによるEC2インスタンスの追加や、EC2インスタンスの復旧も可能です。

用語

CloudWatchで使われる主な用語を整理しておきましょう。

データポイント、メトリックス

サポート対象のAWSサービスを開始すると、データポイント(監視データ)がCloudWatchに送信されます。CloudWatchはメトリックスにデータポイントを格納します。
メトリックスは監視対象の変数、データポイントは時間の経過に伴う変数の値と考えることが出来ます。データポイントはAWSサービスに関連する値とは限りません。ユーザが作成したスクリプトが送信したデータであることもあります。つまり、メトリックスはあるEC2インスタンスのCPU使用率である場合もありますし、アプリケーションの応答速度や室温であることもあります。
メトリックスは名前、名前空間、1 つ以上のディメンションで特定されます。メトリックスは2週間保管されます。

名前空間(ネームスペース)

名前空間はメトリックスを格納します。メトリックスの名前[CPUUtilization]は、EC2やRDSなどで使われます。
メトリックスを特定するための1要素として、名前空間[AWS/EC2]や[AWS/RDS]が使われます。

ディメンション

ディメンションはメトリックスのカテゴリーです。ディメンションを使うことで統計的なモニタリングが可能です。
あるインスタンスのメトリックスを確認する場合、ディメンション[InstanceId]を使用します。ディメンション[AutoScalingGroupName]を使えば、オートスケーリンググループごとのデータをモニタリング出来ます。

EC2メトリックスのディメンション

  • AutoScalingGroupName
  • ImageId
  • InstanceId
  • InstanceType

アラーム

CloudWatchアラームは、メトリックスの値と定義されたしきい値の比較によって3つの状態を持ちます。
アラームの状態変化が指定した期間継続した場合、1つ以上のアクション(最大5つ)を実行出来ます。

アラームの状態

  • OK – メトリックスの値が、しきい値を下回っている
  • ALARM – メトリックスの値が、しきい値を上回っている
  • INSUFFICIENT_DATA – アラームが開始直後であるか、メトリックスが利用できないか、データが不足していてアラームの状態を判定できない

Getting Started

AWSマネージメントコンソールから、CloudWatchを使ってみましょう。
EC2インスタンスのCPU使用率の閲覧からアクションの設定まで行います。

メトリックスの閲覧

CloudWatch画面の左メニューを見ると、メトリックスが名前空間でグルーピングされています。EC2を選択しましょう。

2

webサーバのメトリックス[CPUUtilization]を選択します。 3

グラフィカルにCPU使用率を確認することが出来ます。
CloudWatchは統計データを表示します。「平均」「5分間」という表示に注目してください。
CloudWatchはデータポイントそのものを表示しているわけではありません。
アラームの作成を選択しましょう。アラームの作成画面が表示されます。

8c

アラームの作成

CPU使用率が2回90%以上になった場合に、メールで通知します。メール通知はAmazon Simple Notification Service (SNS)を利用します。

8

指定したメールアドレス宛に、確認メールが送信されます。リンクをクリックすると、アドレスは有効化されます。 9

通知メール

閾値を2回超えた結果、以下メールが送られました。

You are receiving this email because your Amazon CloudWatch Alarm "alarm-cpu" in the APAC - Tokyo region has entered the ALARM state, because "Threshold Crossed: 2 datapoints were greater than or equal to the threshold (90.0). The most recent datapoints: [99.83200000000001, 99.9]." at "Wednesday 16 December, 2015 15:30:25 UTC".

View this alarm in the AWS Management Console: https://console.aws.amazon.com/cloudwatch/home?region=ap-northeast-1#s=Alarms&alarm=alarm-cpu

Alarm Details: - Name: alarm-cpu - Description: - State Change: OK -> ALARM - Reason for State Change: Threshold Crossed: 2 datapoints were greater than or equal to the threshold (90.0). The most recent datapoints: [99.83200000000001, 99.9]. - Timestamp: Wednesday 16 December, 2015 15:30:25 UTC - AWS Account: AWSアカウントID

Threshold: - The alarm is in the ALARM state when the metric is GreaterThanOrEqualToThreshold 90.0 for 300 seconds.

Monitored Metric: - MetricNamespace: AWS/EC2 - MetricName: CPUUtilization - Dimensions: [InstanceId = i-******] - Period: 300 seconds - Statistic: Average - Unit: not specified

State Change Actions: - OK: - ALARM: [arn:aws:sns:ap-northeast-1:AWSアカウントID:kanri] - INSUFFICIENT_DATA:

-- If you wish to stop receiving notifications from this topic, please click or visit the link below to unsubscribe: https://sns.ap-northeast-1.amazonaws.com/unsubscribe.html?SubscriptionArn=arn:aws:sns:ap-northeast-1:AWSアカウントID:kanri:*******-****-****-****-**********&Endpoint=********@classmethod.jp

Please do not reply directly to this email. If you have any questions or comments regarding this email, please contact us at https://aws.amazon.com/support

アクション

通知以外のアクションを確認しましょう。

AutoScaling

CloudWatchアラームの結果を元に、AutoScalingグループをスケールアウトまたはスケールインする事ができます。 AutoScalingのScaling Policyタブを選択します。 以下の例では、CloudWatchアラーム[alarm-cpu]の結果に基づいて、AutoScalingグループに1台のインスタンスを追加します。

13

手順はAWS公式の開発者ガイドを参照ください。

EC2アクション

CloudWatchアラームの結果を元に、EC2インスタンスを停止、終了、再起動、復旧することが出来ます。 インスタンスが必要なくなった場合に、停止や終了を行うことでコストを削減することができます。復旧アクションでは、システム障害があった場合に新しいハードウェアで復旧することが出来ます。 復旧アクションはインスタンスタイプの制限(C3、C4、M3、M4、R3、T2のみ)などがありますので、設定の際は開発者ガイドを参照ください。

カスタムメトリックス

標準メトリックスには、EC2のメモリ使用率やロードアベレージに関するメトリックスはありません。
put-metric-dataコマンド(またはそのクエリAPIと同等のPutMetricData)を使って、CloudWatchに送信することが出来ます。
AmazonLinuxの空きメモリーをCloudWatchに送信してみます。空きメモリーはfreeコマンドにて取得し赤枠を送信します。

11

freeコマンドの結果を、put-metric-dataコマンドで送信します。
スクリプトを用意したらcronなどで定期実行します。

#!/bin/bash
 
log() {
  echo $1 | logger
}
 
# CloudWatchに登録する値
usage=$(free | sed -e 1,2d | awk '{print $4}' | head -n 1)
 
# DimensionにインスタンスIDを指定する場合
# Dimensionには任意のKey-Valueを指定することが可能
instanceId=$(curl -s http://169.254.169.254/latest/meta-data/instance-id)
 
# インスタンス稼働リージョンの取得
region=$(curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone | sed -e 's/.$//')
 
cw_opts="--namespace Example/EC2"
cw_opts=${cw_opts}" --metric-name MemmoryFree"
cw_opts=${cw_opts}" --dimensions InstanceId=${instanceId}"
cw_opts=${cw_opts}" --unit Bytes"
cw_opts=${cw_opts}" --region ${region}"
cw_opts=${cw_opts}" --value ${usage}"
 
# cron等でAPIリクエストが集中するのを防ぐためある程度wait
sleep $(($RANDOM % 15))
 
counter=0
MAX_RETRY=3
 
while :; do
  aws cloudwatch put-metric-data ${cw_opts}
  if [ $? -ne 0 ]; then
    if [ "${counter}" -ge "${MAX_RETRY}" ]; then
      log "failed to put metrics."
      exit 1
    fi
  else
    break
  fi
 
  counter=$((counter + 1))
  sleep 10
done
 
exit 0

名前空間「Example/AWS」が増えました。メモリー空き容量がグラフィカルに確認出来ます。
カスタムメトリックスごとに0.5$/月課金されますので、ご注意ください。

10

スクリプトを用意する必要がありますが、以下記事を参照していただければ簡単にセットアップ出来ます。

CloudWatchカスタムメトリクス取得用Bashスクリプト雛形

ログファイルの収集

CloudWatch Logsを使うと、OS上のログをCloudWatchに集約することが出来ます。
ログは耐久性の高いストレージに保存され、指定した期間保持されます。
CloudWatch LogsはLinuxでもWindowsでも利用可能です。標準メトリックスと違い、EC2上の設定が必要になります。
Windowsの例を見てみましょう。左メニュー[ログ]を選択すると、ロググループの一覧が表示されます。
ロググループ名は任意に設定でき、{instance_id}という指定も可能です。

4

ロググループを選択すると、ログストリーム一覧が表示されます。
ログストリーム名も任意に設定できます。{instance_id}という指定も可能です。 5

ログストリームを選択するとログが表示されます。 6

文字列によるフィルタリングが出来ます。システムログのうち、「停止」が含まれるログを表示します。 7

他ツールとの併用

EC2以外のAWSリソースの監視を行う場合、CloudWatchが必要になります。
EC2においてはハイパーバイザレベルのモニタリングを得意とします。
OS内部(プロセスやリソース)の監視は、サードパーティツールとの併用やCloudWatchを使わないという判断もあり得ます。

あわせて読みたい

公式情報

AWS Blackbelt 2015シリーズ Amazon CloudWatch & Amazon CloudWatch Logs

Amazon CloudWatch 開発者ガイド

Amazon CloudWatch の名前空間、ディメンション、メトリックスのリファレンス

Developers.IO関連エントリ

監視プラクティス

ELB + CloudWatchアラームを使ったEC2サービス監視プラクティス

CloudWatch Logs(Linux)

Amazon CloudWatch Logsによるログの収集とフィルタとアラーム設定

CloudWatch LogsでAmazonLinux上のApacheエラーログを監視する

CloudWatch Logs(Windows)

AWS CloudWatch LogsでWindows OSのイベントログを収集する

パフォーマンスカウンタのデータをCloudWatchカスタムメトリクスにする

他ツールとの比較

AWS環境での監視について調べる CloudWatchとZabbixの比較

ZabbixによるAWS監視のコツ

引用

本記事の内容について、Amazon CloudWatch 開発者ガイドを引用または参考にしました。

さいごに

CloudWatchに限らず、AWSサービスには得意なこと、苦手なことがあります。運用にFitするかを見極め、サードパーティー製ツールの併用等も検討しましょう。

以上、AWS サービス別 再入門アドベントカレンダー 19日目のエントリ『Amazon CloudWatch』編でした。 明日(12/20)はmasuwo3のMachine Learning編です。お楽しみに!