AWS再入門 – CloudWatch編
はじめに
当エントリは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を選択しましょう。
webサーバのメトリックス[CPUUtilization]を選択します。
グラフィカルにCPU使用率を確認することが出来ます。 CloudWatchは統計データを表示します。「平均」「5分間」という表示に注目してください。 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}という指定も可能です。
ロググループを選択すると、ログストリーム一覧が表示されます。 ログストリーム名も任意に設定できます。{instance_id}という指定も可能です。
文字列によるフィルタリングが出来ます。システムログのうち、「停止」が含まれるログを表示します。
他ツールとの併用
EC2以外のAWSリソースの監視を行う場合、CloudWatchが必要になります。 EC2においてはハイパーバイザレベルのモニタリングを得意とします。 OS内部(プロセスやリソース)の監視は、サードパーティツールとの併用やCloudWatchを使わないという判断もあり得ます。
あわせて読みたい
公式情報
AWS Blackbelt 2015シリーズ Amazon CloudWatch & Amazon CloudWatch Logs
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の比較
引用
本記事の内容について、Amazon CloudWatch 開発者ガイドを引用または参考にしました。
さいごに
CloudWatchに限らず、AWSサービスには得意なこと、苦手なことがあります。運用にFitするかを見極め、サードパーティー製ツールの併用等も検討しましょう。
以上、AWS サービス別 再入門アドベントカレンダー 19日目のエントリ『Amazon CloudWatch』編でした。 明日(12/20)はmasuwo3のMachine Learning編です。お楽しみに!