電子の密林を開拓する

タグ:CloudWatch

今回は CloudWatch の Alarm を CLI 経由で設定します。


・負荷をかける対象のEC2インスタンスを作成する
GUIでCloudWatchのAlarmを設定した記事でやったように、sysbench というコマンドで負荷をかけてみます。
AmazonLinux では sysbench が yum でインストールできるパッケージに含まれていないので、負荷対象として 新規に Ubuntu を OS とする EC2を起動します。
$ ec2-run-instances  \
     ami-20ad1221 \
     --group web  \
     --key innerkey  \
     --instance-count 1  \
     --instance-type t1.micro  \
     --instance-initiated-shutdown-behavior stop

RESERVATION     r-15841f16      488224276535    web
INSTANCE        i-55b38d56      ami-20ad1221                    pending innerkey        0             t1.micro        2013-02-25T07:43:21+0000        ap-northeast-1a aki-ec5df7ed                  monitoring-disabled                                     ebs                                   paravirtual     xen             sg-33bace32     default false
セキュリティグループや鍵ペアについては適切なものを指定ください。

次に、作成した 負荷対象となるEC2インスタンスにsshログインして、負荷試験ツール(sysbench)をインストールします。まずは ssh ログイン。
$ ec2-describe-instances i-55b38d56 \
     | grep '^INSTANCE'  \
     | cut --fields=5

ip-10-132-166-244.ap-northeast-1.compute.internal

$ ssh \
     -i ~/.ssh/innerkey.pem \
     -l ubuntu \
     ip-10-132-166-244.ap-northeast-1.compute.internal

続いて、EC2インスタンス上での設定。
まずは前準備の呪文として、以下の二つを実行しておきます(後者は、まぁ、無くてもOKかも)。
$ sudo apt-get update
$ sudo apt-get upgrade
次は、sysbench をインストールします。
$ sudo apt-cache search sysbench
sysbench - Cross-platform and multi-threaded benchmark tool

$ sudo apt-get install sysbench

Ubuntu 側の設定はコレで終わりなので、一旦ログアウトしておきます。
$ exit



・S
NSの設定

Alarmを利用するには通知先となるSNSが必要になります。
そのため、先に server-alarm という名前のSNSトピックを作成し、メールアドレスを登録しておきます。
手順は以前の記事を参考にしてください。
$ sns-create-topic server-alarm
arn:aws:sns:ap-northeast-1:488224276535:server-alarm

$ sns-subscribe \
     arn:aws:sns:ap-northeast-1:488224276535:server-alarm \
     --protocol email  \
     --endpoint  exploreaws@example.com

Subscription request received.

※ここでメール受信

$ sns-confirm-subscription \
     arn:aws:sns:ap-northeast-1:488224276535:server-alarm \
     --token ~メールで送られてきたTOEKN識別子~

arn:aws:sns:ap-northeast-1:488224276535:server-alarm:59bb374a-186b-40e9-8d6c-09d43d716058
念のため、sns-publish コマンドで通知が届くことを確認しておいてください。
⇒ Alarm設定後に通知が届かない場合、SNS側の設定ミスなのか、Alarm側の設定ミスなのか判断できなくなるので。
$ sns-publish \
     arn:aws:sns:ap-northeast-1:488224276535:server-alarm \
     --message 'This is sample publishing.'

13dc2c0b-069c-5820-8e6e-65965c13ae80



・Alarmの設定
(AmazonLinuxの場合) /opt/aws/bin/ にインストールされている alarm に関連しそうな mon-* 系コマンドは以下の通り。
$ ls -1 /opt/aws/bin/mon* \
     | grep -i alarm

/opt/aws/bin/mon-delete-alarms
/opt/aws/bin/mon-describe-alarm-history
/opt/aws/bin/mon-describe-alarms
/opt/aws/bin/mon-describe-alarms-for-metric
/opt/aws/bin/mon-disable-alarm-actions
/opt/aws/bin/mon-enable-alarm-actions
/opt/aws/bin/mon-put-metric-alarm
/opt/aws/bin/mon-set-alarm-state
Alarmの作成と削除は、それぞれ mon-put-metric-alarm と mon-delete-alarms が対応するようです。

まずはAlarmの作成から。

mon-put-metric-alarm で、良く使いそうなパラメータを並べてみます。
mon-put-metric-alarm

  ALARM_NAME
  --alarm-description 'COMMENT'
  --alarm-actions SNS_TOPIC_NAME,...

  --namespace  CLOUDWATCH_NAMESPACE
  --metric-name  CLOUDWATCH_METRIC
  --statistic  CLOUDWATCH_STATISTIC
  --dimensions CLOUDWATCH_DIMENSION
  --period  CLOUDWATCH_PERIOD_IN_SECOND
  --unit CLOUDWATCH_UNIT

  --threshold  VALUE_TO_COMPARE
  --evaluation-periods  NUMBER_OF_PERIODS
  --comparison-operator  (
         GreaterThanOrEqualToThreshold
       | GreaterThanThreshold,
       | LessThanThreshold
       | LessThanOrEqualToThreshold
       )
ものすごく大量にあってゲンナリしますが…。2つにグループ分けすると、以下のような感じになります。
  • 上段 - Alarmに関する名前、通知先SNSトピックの指定
  • 中段 - 監視対象となる CloudWatch の指定
  • 下段 - 条件と閾値(この値になったらAlarm作動するぜ…というモノ)

Alarm に関する名前は、EC2インスタンス自身の CPU負荷に対するAlarmを作成するので、それらしいモノにしておきます。


  cpu-overload
  --alarm-description 'CPU utlization overload'
  --alarm-actions server-alarm


CloudWatch の設定は、前回の記事で試したので特に困ることは無いですね…。以下のような感じになります。


  --namespace  AWS/EC2
  --metric-name  CPUUtilization
  --statistic  Average
  --period  300

  --unit Percent


EC2インスタンス、300秒(5分)間、CPU使用率…の平均値を監視対象とします。

どのEC2インスタンスで負荷が発生してもAlarmを出したいので、dimensions は指定しません。

period を指定させる意味が良く分かりませんが、とりあえず(CloudWatchデフォルトの)300としておきます。


最後の条件と閾値は…


  --threshold  50
  --evaluation-periods  2
  --comparison-operator  GreaterThanOrEqualToThreshold


…という設定で、「監視対象の値が 50%以上の2回以上続いたら」という条件設定にします。

ではコマンドを実行してみましょう。
$ mon-put-metric-alarm  \
     cpu-overload  \
     --alarm-description 'CPU utlization overload'  \
     --alarm-actions arn:aws:sns:ap-northeast-1:488224276535:server-alarm  \
     --namespace  AWS/EC2  \
     --metric-name  CPUUtilization  \
     --statistic  Average  \
     --period  300  \
     --unit Percent  \
     --threshold  50  \
     --evaluation-periods  2  \
     --comparison-operator  GreaterThanOrEqualToThreshold
OK-Created Alarm
先ほどのコマンド一覧にあった mon-describe-alarms で結果を確認してみます。
$ mon-describe-alarms
cpu-overload  INSUFFICIENT_DATA  arn:aws:sns:ap-nor...276535:server-alarm  AWS/EC2  CPUUtilization  300  Average  2  GreaterThanOrEqualToThreshold  50.0
それらしいものが設定されているように見えますね…。
しかし、状態(?)が INSUFFICIENT_DATA になっています。これって異常???
https://forums.aws.amazon.com/message.jspa?messageID=253009

Ensure any dimensions you specify are applicable to the metric (e.g. CPUUtilization for EC2 instances is measured against the InstanceId and AutoscalingGroup dimensions for the AWS/EC2 namespace, whereas CPUUtilization for RDS is measured against the dimensions DatabaseClass, DBInstanceIdentifier and EngineName for the AWS/RDS namespace).
上記の公式フォーラムの回答によると、CPUUtilization は Instance-ID か AutoScalingGroup を dimension として必要とするみたいですね…。どのインスタンスのCPU 負荷でも良いからアラーム対象とする…という設定にはできないみたいです…(x_x;

Alarm を再設定します。再設定(update)も 同じ mon-put-metric-alarm コマンドを使用するようです。
$ mon-put-metric-alarm  \
     cpu-overload  \
     --alarm-description 'CPU utlization overload'  \
     --alarm-actions arn:aws:sns:ap-northeast-1:488224276535:server-alarm  \
     --namespace  AWS/EC2  \
     --metric-name  CPUUtilization  \
     --dimensions 'InstanceId=i-55b38d56' \
     --statistic  Average  \
     --period  300  \
     --unit Percent  \
     --threshold  50  \
     --evaluation-periods  2  \
     --comparison-operator  GreaterThanOrEqualToThreshold

OK-Created Alarm

$ mon-describe-alarms
cpu-overload  OK  arn:aws:sns:ap-nor...276535:server-alarm  AWS/EC2  CPUUtilization  300  Average  2  GreaterThanOrEqualToThreshold  50.0
今度はバッチリ設定されているようですね。




・負荷試験の実行

負荷試験は、Ubuntu側で直接実行します。sshでログインして、そこから作業しましょう。
先に設定した mon-put-metric-alarm では「5分単位の計測で2回の高負荷」時に警告が飛ぶようにしたので、比較的な長い時間負荷試験を実行する必要があります。
ここでは、900秒(15分)実行しておくことにします。

$ ssh \
     -i ~/.ssh/innerkey.pem \
     -l ubuntu \
     ip-10-132-166-244.ap-northeast-1.compute.internal



$ sysbench \
     --max-requests=9999999 \
     --max-time=900 \
     --test=cpu run


sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1

Doing CPU performance benchmark

Threads started!

Time limit exceeded, exiting...
Done.

Maximum prime number checked in CPU test: 10000


Test execution summary:
    total time:                          900.0490s
    total number of events:              203125
    total time taken by event execution: 899.3371
    per-request statistics:
         min:                                  1.78ms
         avg:                                  4.43ms
         max:                                229.57ms
         approx.  95 percentile:               2.11ms

Threads fairness:
    events (avg/stddev):           203125.0000/0.00
    execution time (avg/stddev):   899.3371/0.00



負荷試験対象である Ubuntu にはEC2コマンドをインストールしていないので、AmazonLinuxなインスタンスから CPUUtlization (CPU負荷)を確認してみます。
$ mon-get-stats  \
     CPUUtilization \
     --namespace AWS/EC2 \
     --statistics Maximum \
     --dimensions 'InstanceId=i-55b38d56'
2013-02-25 09:40:00  1.67   Percent
2013-02-25 09:45:00  1.67   Percent
2013-02-25 09:50:00  1.69   Percent
2013-02-25 09:55:00  1.64   Percent
2013-02-25 10:00:00  1.67   Percent
2013-02-25 10:05:00  1.75   Percent
2013-02-25 10:10:00  100.0  Percent
2013-02-25 10:15:00  100.0  Percent
2013-02-25 10:20:00  100.0  Percent
2013-02-25 10:25:00  100.0  Percent
2013-02-25 10:30:00  100.0  Percent

$ mon-describe-alarms
cpu-overload  OK  arn:aws:sns:ap-nor...276535:server-alarm  AWS/EC2  CPUUtilization  300  Average  2  GreaterThanOrEqualToThreshold  50.0

$ mon-describe-alarm-history cpuoverload
cpu-overload  2013-02-25T10:35:36.223Z  StateUpdate          Alarm updated from ALARM to OK
cpu-overload  2013-02-25T10:25:36.253Z  Action               Successfully executed action arn:aws:sns:ap-northeast-1:488224276535:server-alarm
cpu-overload  2013-02-25T10:25:36.230Z  StateUpdate          Alarm updated from OK to ALARM
cpu-overload  2013-02-25T09:46:47.720Z  StateUpdate          Alarm updated from INSUFFICIENT_DATA to OK
cpu-overload  2013-02-25T09:46:47.136Z  ConfigurationUpdate  Alarm "cpu-overload" updated
cpu-overload  2013-02-25T09:33:04.279Z  ConfigurationUpdate  Alarm "cpu-overload" created

Alarmに設定されたアクションが実行されたことになっています。

exploreaws@example.com にも、「ALARM: "cpu-overload" in APAC - Tokyo」という件名のメールが届いていました。

You are receiving this email because your Amazon CloudWatch Alarm "cpu-overload" in the APAC - Tokyo region has entered the ALARM state, because "Threshold Crossed: 2 datapoints were greater than or equal to the threshold (50.0). The most recent datapoints: [100.0, 100.0]." at "Monday 25 February, 2013 10:25:36 UTC".

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

Alarm Details:
- Name:                       cpu-overload
- Description:                CPU utlization overload
- State Change:               OK -> ALARM
- Reason for State Change:    Threshold Crossed: 2 datapoints were greater than or equal to the threshold (50.0). The most recent datapoints: [100.0, 100.0].
- Timestamp:                  Monday 25 February, 2013 10:25:36 UTC
- AWS Account:                488224276535

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

Monitored Metric:
- MetricNamespace:            AWS/EC2
- MetricName:                 CPUUtilization
- Dimensions:                 [InstanceId = i-55b38d56]
- Period:                     300 seconds
- Statistic:                  Average
- Unit:                       Percent

State Change Actions:
- OK: 
- ALARM: [arn:aws:sns:ap-northeast-1:488224276535:server-alarm]
- INSUFFICIENT_DATA: 

これでAlarmの設定が正しく機能していることが確認できました。

ちなみに、今回は「ALARMになった時」のActionだけ設定しましたが、実運用では「OKになった時」も設定しておくのが良いでしょう。負荷状態から自動的に復帰した場合、それも知りたいでしょうから…。

しかしAlarmの文面が変更できないのは、微妙に使いにくいですね…。



・後始末
mon-delete-alarm でAlarm設定を削除します。
$ mon-delete-alarms cpu-overload
    Are you sure you want to delete these Alarms? [Ny]y
OK-Deleted alarms
プロンプトがメンドくさければ、--force オプションで抑制できます。

Alarm の通知先であった、SNS も削除します。
$ sns-list-topics
arn:aws:sns:ap-northeast-1:488224276535:server-alarm

$ sns-delete-topic \
     arn:aws:sns:ap-northeast-1:488224276535:server-alarm
    Are you sure you want to delete this topic? [Ny]y
Topic deleted.
要らなくなった EC2 インスタンス (Ubuntu)も削除しておいてください。
$ ec2-stop-instances i-55b38d56
INSTANCE        i-55b38d56      running stopping

$ ec2-terminate-instances i-55b38d56
INSTANCE        i-55b38d56      stopped terminated

これで後始末も終了。




今回はここまで。


今回は CloudWatch というか、mon-*系の監視コマンドを使ってみます。



・タグからEC2インスタンスを探す
MasterController という名前の AmazonLinux な EC2 で CloudWatch を試してみます。
MasterController というNameタグを持つインスタンスを探して、そのInstance-ID を入手します。
$ ec2-describe-instances \
     | grep -e '^TAG' \
     | grep 'MasterController' \
     | cut --fields=3
i-0f1b440c
あるいは --filter オプションを使用して以下のようにもできます。
$ ec2-describe-instances \
     --filter 'tag:Name=MasterController' \
   | grep '^INSTANCE' \
   | cut --fields=2
i-0f1b440c
書く手間は、あまり変わりませんね…。
いずれにせよ、コマンドじゃなくてAPIで探した方が良いような気がするけど…。とりあえず、今はコレでガマンしておきます。



・EC2インスタンス用のメトリックス
次に、mon-list-metrics を使って、先に入手した Instance-ID に紐づく Metrics のリストを
入手します。
⇒ mon-list-metrics コマンドだけを使っても一覧を入手できますが、既に削除済みのインスタンスに対するmetricsも表示されたりしてメンドクサイので、Instence-ID で検索したいのです。
$ mon-list-metrics \
     | egrep 'i-0f1b440c' \
     | grep -v '^"'
CPUUtilization                 AWS/EC2  {InstanceId=i-0f1b440c}
DiskReadBytes                  AWS/EC2  {InstanceId=i-0f1b440c}
DiskReadOps                    AWS/EC2  {InstanceId=i-0f1b440c}
DiskWriteBytes                 AWS/EC2  {InstanceId=i-0f1b440c}
DiskWriteOps                   AWS/EC2  {InstanceId=i-0f1b440c}
NetworkIn                      AWS/EC2  {InstanceId=i-0f1b440c}
NetworkOut                     AWS/EC2  {InstanceId=i-0f1b440c}
StatusCheckFailed              AWS/EC2  {InstanceId=i-0f1b440c}
StatusCheckFailed_Instance AWS/EC2  {InstanceId=i-0f1b440c}
StatusCheckFailed_System       AWS/EC2  {InstanceId=i-0f1b440c}

MasterController というタグが付けられたEC2インスタンスには、これだけのMetricsがあるらしいです。

しかし、もっとカンタンな方法を発見。

$ mon-list-metrics \
--dimensions "InstanceId=i-0f1b440c" \
     | egrep -v '^"'

CPUUtilization                 AWS/EC2  {InstanceId=i-0f1b440c}
DiskReadBytes                  AWS/EC2  {InstanceId=i-0f1b440c}
DiskReadOps                    AWS/EC2  {InstanceId=i-0f1b440c}
DiskWriteBytes                 AWS/EC2  {InstanceId=i-0f1b440c}
DiskWriteOps                   AWS/EC2  {InstanceId=i-0f1b440c}
NetworkIn                      AWS/EC2  {InstanceId=i-0f1b440c}
NetworkOut                     AWS/EC2  {InstanceId=i-0f1b440c}
StatusCheckFailed              AWS/EC2  {InstanceId=i-0f1b440c}
StatusCheckFailed_Instance AWS/EC2  {InstanceId=i-0f1b440c}
StatusCheckFailed_System AWS/EC2  {InstanceId=i-0f1b440c}
--dimensions オプションを使えば、簡単に Instance-ID で絞り込みできました!

で、肝心の Metrics そのものですが……。
MasterController は AmazonLinux なマイクロインスタンスなので、ローカルディスクは使用していないです(マイクロインスタンスではEBSが使用される)。つまり、Disk* 系の Metrics には あまり意味が無いというコトですね。


・EC2インスタンスの監視結果を得る
Metrics の一覧が手に入ったので、次は mon-get-stats コマンドで CloudWatch から監視結果の値を入手します。指定するパラメータは以下のようにします。
Metric     = CPUUtilization 
Statistics = Average
NameSpace = AWS/EC2
mon-get-stats --help で確認すると、Statistics には「Average, Sum, SampleCount, Maximum, Minimum」のいずれかが指定できるようです。
$ mon-get-stats \
     CPUUtilization \
     --statistics Average \
     --namespace AWS/EC2
あれ??? パラメータは足りているはずなのに、何も表示されませんね???
(このコマンド指定で何かが表示される場合もありますが、今回は表示されませんでした…。結果が表示されたり、されなかったりする理由は不明。)

気を取り直して、先ほど mon-list-metrics で指定した dimensions を設定してみます。
$ mon-get-stats \
     CPUUtilization \
     --statistics Average \
     --namespace AWS/EC2 \
     --dimensions "InstanceId=i-0f1b440c"

2013-02-17 17:13:00  23.830000000000002   Percent
2013-02-17 17:18:00  0.33399999999999996  Percent
2013-02-17 17:23:00  26.666000000000004   Percent
2013-02-17 17:28:00  0.0                  Percent
2013-02-17 17:33:00  0.0                  Percent
2013-02-17 17:38:00  1.6440000000000001   Percent
2013-02-17 17:43:00  47.18                Percent
2013-02-17 17:48:00  9.622                Percent
2013-02-17 17:53:00  18.887999999999998   Percent
2013-02-17 17:58:00  35.922000000000004   Percent
2013-02-17 18:03:00  12.334               Percent
--dimensions オプションに Instance-ID を指定したら 結果が表示されるようになりましたね。Dimensions は必須オプションではないのに……指定が必要な理由が分からないです。

他の値、ヘルスチェックの結果も見てみましょう。
$ mon-get-stats \
     StatusCheckFailed \
     --statistics Sum \
     --namespace AWS/EC2 \
     --dimensions "InstanceId=i-0f1b440c"

2013-02-17 18:25:00  0.0  Count
2013-02-17 18:30:00  0.0  Count
2013-02-17 18:35:00  0.0  Count
2013-02-17 18:40:00  0.0  Count
2013-02-17 18:45:00  0.0  Count
2013-02-17 18:50:00  0.0  Count
2013-02-17 18:55:00  0.0  Count
2013-02-17 19:00:00  0.0  Count
2013-02-17 19:05:00  0.0  Count
2013-02-17 19:10:00  0.0  Count
2013-02-17 19:15:00  0.0  Count
2013-02-17 19:20:00  0.0  Count
特にヘルスチェックに失敗するような処理もさせていないので、カウントはゼロになっていますね。



・EBSの Volume-ID を得る
MasterController(i-0f1b440c)にアタッチされた EBS の状態を確認してみましょう。
ec2-describe-volumes に --filter オプションを使って、EBS のボリュームIDを探してみます。
$ ec2-describe-volumes \
     --filter 'attachment.instance-id=i-0f1b440c' \
   | grep '^VOLUME' \
   | cut --fields=2


vol-6057ec42



・EBSに対するメトリックスを得る
では、EBS Volume(vol-6057ec42) に対する Metrics のリストを確認します。
$ mon-list-metrics \
     --namespace AWS/EBS \
     --dimensions='VolumeId=vol-6057ec42' \
   | grep -v '^"'
VolumeIdleTime           AWS/EBS  {VolumeId=vol-6057ec42}
VolumeQueueLength        AWS/EBS  {VolumeId=vol-6057ec42}
VolumeReadBytes          AWS/EBS  {VolumeId=vol-6057ec42}
VolumeReadOps            AWS/EBS  {VolumeId=vol-6057ec42}
VolumeTotalReadTime      AWS/EBS  {VolumeId=vol-6057ec42}
VolumeTotalWriteTime AWS/EBS  {VolumeId=vol-6057ec42}
VolumeWriteBytes         AWS/EBS  {VolumeId=vol-6057ec42}
VolumeWriteOps AWS/EBS  {VolumeId=vol-6057ec42}
AWS Management Console でも見たことがあるような監視項目が表示されています。




・EBSの監視結果を得る
まずは、VolumeQueueLength を見てみます。
$ mon-get-stats \
     VolumeQueueLength \
     --statistics Maximum \
     --namespace AWS/EBS \
     --dimensions "VolumeId=vol-6057ec42"
2013-02-17 19:01:00  3.06666666666667E-4  Count
2013-02-17 19:06:00  9.73333333333333E-4  Count
2013-02-17 19:11:00  2.4E-4               Count
2013-02-17 19:16:00  4.13333333333333E-4  Count
2013-02-17 19:21:00  2.13333333333333E-4  Count
2013-02-17 19:26:00  5.2E-4               Count
2013-02-17 19:31:00  2.66666666666667E-4  Count
2013-02-17 19:36:00  1.46666666666667E-4  Count
2013-02-17 19:41:00  1.46666666666667E-4  Count
2013-02-17 19:46:00  0.0                  Count
2013-02-17 19:51:00  0.0                  Count
2013-02-17 19:56:00  0.00133333333333333  Count
浮動小数点が E 表記になっているので、ものすごく見づらいです…。これをふつうの表記に変更する方法が分からない…。

VolumeQueueLength の意味は「The average number of read and write operations waiting to be completed during the period」(単位時間内に、READ/WRITE処理が待たされた回数の平均)ということらしいです。平均ってオカシイような気がするのですが…(単に「回数」じゃなくて??? ↑のコマンド実行結果にも Count [回数]って書いてあるし…)
あと、単位時間(the period)って どれぐらいなのでしょう? …と思いましたが、記録されている時間が 5分毎なので、恐らく 単位時間も5分なのでしょう。EC2の標準状態(無料)の監視間隔と同じですね。

他の値も見ておきます。
$ mon-get-stats \
     VolumeTotalWriteTime \
     --statistics Sum \
     --namespace AWS/EBS \
     --dimensions "VolumeId=vol-6057ec42"

2013-02-17 19:36:00  0.044  Seconds
2013-02-17 19:41:00  0.044  Seconds
2013-02-17 19:56:00  0.26   Seconds
2013-02-17 20:01:00  0.124  Seconds
2013-02-17 20:06:00  0.196  Seconds
2013-02-17 20:11:00  0.088  Seconds
2013-02-17 20:16:00  0.028  Seconds
2013-02-17 20:21:00  0.032  Seconds
2013-02-17 20:26:00  0.072  Seconds
VolumeTotalWriteTimeは「書き込みに処理かかった時間(=待たされた時間)」ということらしいです。これと VolumeTotalReadTime の値が高い値になったら、EBSの処理が遅延しているということになりますね…たぶん。
⇒ 実際に負荷試験するなり、実運用しているEBSから値を取得するなりしないと、ホントのところは分かりませんが…。




・まとめ???
mon-* 系コマンド(というか CloudWatch)には、Namespace / Metrics / Statistics / Dimensions / Unit / Period という値が登場しますが…。ここまでコマンドを使ってみた結果、以下のような感じになっているものと思われます。


Namespaceデータ取得元の大雑把な分類 (AWS/EC2、AWS/EBS など)
Metricsデータの種類 (CPU使用率、失敗回数、遅延時間など)
Dimensionsデータ取得元の詳細な分類(Volume-ID、Instance-ID など)
Statisticsデータの統計方法(平均、合計、最大、最小、記録回数など)
Unit データの単位 (~秒、~バイト、~ビット、~パーセント、~回、~バイト/秒 など)
Periodデータを取得/統計する単位時間 (標準の無料利用状態だと5分単位)

標準で用意されたデータを参照して利用するだけでは、単なる簡単で便利な自動監視機構にしか見えませんが…。
カスタムメトリックス(mon-put-data とか?)とアラームを使いこなせれば、もっと高度に使えそうな気がします…。
⇒ そもそも AutoScaling の基礎になっているので、そのとおりなのですが…(^^;



今回はここまで……。

今回は CloudWatch というか、ヘルスチェック機能(AWSではAlarmと呼ぶらしい)を設定してみます。


・WEBサーバの作成
web01、web02 という名前で、二台のWEBサーバを作成しておく。
中身は以前作ったものと同様。
※もっとも、今回はWEBサーバとしては利用しないので、単なるLinuxインスタンスでOKですが…。


・SNS Topic の作成と、通知先設定

alarm01
AWS Management Console から SNS を選択
⇒ SNS は Simple Notification Service の略




alarm02
SNS Dashboard が表示されるので、中央の Create New Topic をクリック




alarm03
TopicName と DisplayName をテキトーに設定します。
ここでは、server-alarm としておきます。




alarm04
作成した Topic に対して通知先を設定する必要があるので、
MyTopic の server-alarm を選択して、Create New Subscription をクリック。




alarm05
通知先の設定。
ここでは、Protocol を Email とし、Endpoint に自分のメールアドレスを設定します。




alarm07
Topic 設定完了後の画面。
server-alarm の topic に登録(subscription)された email アドレスは、PendingConfirmation (確認/認証待ち)状態になっています。


登録したメールアドレス宛てに no-reply@sns.amazonaes.com から、Subscription の確認メールが届いているはずなので、確認します。

(メール文面は省略)


alarm09
no-reply@sns.amazonaes.com
からのメールに含まれているURLをクリックすると、Confirmation が完了し、上記のようなブラウザ画面が表示されます。



・Alarmの作成
alarm10
EC2 Dashboard から web01 の監視状況を確認します。
自分では特に何も設定していなくても、基本的な監視(だけ)は実施されているようです。
その中から Avg CPU Utilization をクリックしてみます。
※Avg は Average (平均) の略でしょう。



alarm11
Alarm 作成画面が表示されるので、適当な値を入力します。
ここでは、CPU 利用率が 25% 以上になったら Alarm を飛ばすように設定します。
対象topic(= Send a notification to) には、先ほど作成した topic である server-alarm を指定しておきます。




alarm12
Alarm 作成完了画面。特に気になる文面はないですね…。




alarm13
似たような手順で、今度は web01 の Disk Writes 用の Alarm も設定します。




・サーバ負荷をかけてみる
サーバー負荷をかけるためには、負荷をかけるためのプログラムが必要なのですが…。
特にこだわりは無いので、sysbench というソフトを使ってみることにします。

まずはインストール。

  sudo apt-get install sysbench

特に難しいこともなくインストールは完了します。

まずは sysbench で CPU 負荷をかけてみましょう。コマンドは「sysbench --max-requests=9999999 --max-time=300 --test=cpu run」とします。詳細は man sysbench とかして調べてみてください。

上記コマンドを使って、web01 上で CPU 負荷をかけるように実行してみます。
ssh で web01 にログインして実行すると、以下のようになります。

ubuntu@ip-10-120-3-7:~$ sysbench --max-requests=9999999 --max-time=300 --test=cpu run

sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1

Doing CPU performance benchmark

Threads started!
Time limit exceeded, exiting...
Done.

Maximum prime number checked in CPU test: 10000


Test execution summary:
    total time:                          300.0011s
    total number of events:              68805
    total time taken by event execution: 299.5721
    per-request statistics:
         min:                                  1.47ms
         avg:                                  4.35ms
         max:                                157.60ms
         approx.  95 percentile:               1.50ms

Threads fairness:
    events (avg/stddev):           68805.0000/0.00
    execution time (avg/stddev):   299.5721/0.00




alarm15
EC2 Dashboard から、負荷のかかり具合を確認してみます。

グラフだと80% までCPUパワーを消費していますね。

負荷が設定した閾値を超えたので、AWS から Alarm メヘールが届いているハズです。
監視は 5分ごとのデータに依存しているので、すぐにメールが来るかどうかは分かりませんが…。




次は、HDD に負荷をかけてみます。
HDD 負荷をかける場合は、sysbench に対して、「prepare → run → cleanup」という順序で操作するようです。
テンポラリファイルがたくさん作成されるので、サブディレクトリを作成して、その中で実行するのが良いでしょう。
以下の3行のコマンドを実行してください。

  sysbench --max-requests=9999999 --max-time=300 --test=fileio --file-test-mode=rndrw  prepare
  sysbench --max-requests=9999999 --max-time=300 --test=fileio --file-test-mode=rndrw  run
  sysbench --max-requests=9999999 --max-time=300 --test=fileio --file-test-mode=rndrw  cleanup
結果は以下のような感じ。

ubuntu@ip-10-120-3-7:~$ sysbench --max-requests=9999999 --max-time=300 --test=fileio --file-test-mode=rndrw  prepare

sysbench 0.4.12:  multi-threaded system evaluation benchmark

128 files, 16384Kb each, 2048Mb total
Creating files for the test...
ubuntu@ip-10-120-3-7:~$

ubuntu@ip-10-120-3-7:~$ sysbench --max-requests=9999999 --max-time=300 --test=fileio --file-test-mode=rndrw  run

sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1

Extra file open flags: 0
128 files, 16Mb each
2Gb total file size
Block size 16Kb
Number of random requests for random IO: 9999999
Read/Write ratio for combined random IO test: 1.50
Periodic FSYNC enabled, calling fsync() each 100 requests.
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing random r/w test
Threads started!
Time limit exceeded, exiting...
Done.

Operations performed:  98880 Read, 65920 Write, 210931 Other = 375731 Total
Read 1.5088Gb  Written 1.0059Gb  Total transferred 2.5146Gb  (8.5832Mb/sec)
  549.33 Requests/sec executed

Test execution summary:
    total time:                          300.0037s
    total number of events:              164800
    total time taken by event execution: 50.8981
    per-request statistics:
         min:                                  0.01ms
         avg:                                  0.31ms
         max:                                207.43ms
         approx.  95 percentile:               0.99ms

Threads fairness:
    events (avg/stddev):           164800.0000/0.00
    execution time (avg/stddev):   50.8981/0.00

ubuntu@ip-10-120-3-7:~$


ubuntu@ip-10-120-3-7:~$ sysbench --max-requests=9999999 --max-time=300 --test=fileio --file-test-mode=rndrw  cleanup

sysbench 0.4.12:  multi-threaded system evaluation benchmark

Removing test files...

ubuntu@ip-10-120-3-7:~$


特に問題なく実行できているようです。




alarm16
AWS Management Conosole の EC" Dashboard から結果(HDDの DiskWriteのグラフ)を確認してみます。

あれ……?
負荷ゼロですね...?


.
.
.

嗚呼!!

作成したインスタンスは HDD として EBS を利用しているので、ローカルのHDD(Ephemeral Disk と呼ばれるらしい)は利用していないのですね。
なので、負荷を計測するべき対象は web01 サーバ(EC2)ではなく、そこにアタッチされている EBS になります。


alarm17
EC2にアタッチされている EBS を調べてみましょう。
EC2 インスタンスにアタッチされている EBS の ID を調べるには、上記のようにします。
EC2 インスタンスから見た場合、/dev/sda1 としてマウントされているので、そのデバイスの状態を確認すると、EBS の ID が入手できます。




・EBS に Alarm を設定する
alarm18
AWS Management Console の Cloud Watch から、Metrics をクリックし、先ほどの EBS ID を使って検索します。
ここでは、DiskWriteBytes で Alarm を設定します。




alarm19
名前と閾値をテキトーに設定します。




alarm20
通知先となる SNS Topic を選択します。
ここでは server-alarm を指定します。

この後、「確認画面」と「完了画面」が出ますが、特に困ることもないので省略します。




似たような感じで、EBS の 「TotalWriteTime」「TotalWriteOps」 に対する Alarm も設定しておきます。


↓ CloudWatch から 指定した EBS ID の TotalWriteBytes を検索
alarm29

↓ EBS の TotalWriteBytes に対する Alarm を設定
alarm30

↓ CloudWatch から 指定した EBS ID の TotalWriteOps を検索
alarm37

↓ EBS TotalWriteOps に対する Alarm を設定
alarm38



・再度サーバに負荷をかける

先ほどと同じ手順で HDD に負荷をかけてみます。

sysbench --max-requests=9999999 --max-time=300 --test=fileio --file-test-mode=rndrw  prepare
sysbench --max-requests=9999999 --max-time=300 --test=fileio --file-test-mode=rndrw  run
sysbench --max-requests=9999999 --max-time=300 --test=fileio --file-test-mode=rndrw  cleanup

状況/負荷のかかり具合にもよりますが、負荷をかけた後、設定した Alarm がメールで通知されているはずです。





alarm42
Alarm の閾値によっては、通知が来ないこともあるようですが...。

CPU 負荷の場合は期待通りに負荷がかかるのですが、EBS の場合 イマヒトツ負荷のかかり具合が不明です。何度か負荷をかけると、Alarm が発生したりしなかったりするので、キャッシュが設定されているように思えます。もっとも、詳細は不明(調べればどこかに記載されている???)。

実際に運用するか、一般的な想定値から閾値を設定してみる必要があると思います…。
(つまり、ここでは閾値の妥当性については分からない…ということです)




・INSUFFICIENT_DATA とは?

alarm44
負荷をかけずにしばらく放置しておくと、EBS の TotalWriteTime に対する Alarm が「INSUFFICIENT_DATA」という状態になります。

これは、いったい何?!
.
.
.

そうか、「書き込むべきデータが無い」状態では「書き込み回数(WriteOps)」はゼロで、
「書き込みに要した時間(write time)」もゼロだから、「0÷0=計算不可」となるのかな…たぶん…。




・後始末
alarm45
Alarm も(数が多いと)課金対象らしいので実験が終わったらサッサと削除しておきます。
Alarm の一覧で、全Alarm をチックして Delete ボタンを押下するだけです。




alarm47
EC2インスタンスとEBSも削除して、課金されないようにしておきます。
EC2 dashboard で、利用中のサービス状態を確認しておいてください。




・TIPS

  1. Alarm のメールには display name が記載される。そのため、display name には「障害の内容」あるいは「受信者に対処して欲しい作業」を記載しておくと良いかも。
  2. Alarm に設定する閾値は、実際に運用して決定する必要がある。EBS は仕組みと計測単位の詳細が良く分からないので、それも調べてみる必要がある。



今回はここまで。


次は AutoScaling を試してみたい。

このページのトップヘ