AWS再入門 – CloudWatch編

AWS再入門アドベントカレンダー

#Amazon CloudWatch

#AWS

阿部洸樹

2015.12.19

この記事は公開されてから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つの状態を持ちます。アラームの状態変化が指定した期間継続した場合、１つ以上のアクション（最大5つ）を実行出来ます。

アラームの状態

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

Getting Started

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

メトリックスの閲覧

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

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

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

アラームの作成

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

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

通知メール

閾値を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台のインスタンスを追加します。

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

EC2アクション

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

カスタムメトリックス

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

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$/月課金されますので、ご注意ください。

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

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

ログファイルの収集

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