素敵な Amazon CloudWatchJAWS-UG 北陸支部

松本 雄一郎

2013年4月15日月曜日

自己紹介

名前 →Yuuitiro Matsumoto

金沢出身の北海道経由富山育ち

システム開発から運用まで一通りやります。

特徴

IPv6 が好きだったので、KAME が好き。

年齢なりの落ち着きがないｗ

ベトナムが好き

2013年4月15日月曜日

今日のネタ

CloudWatch でカスタムメトリクスが有効になった頃 Blog 界隈で話題になってたこと。の焼き直しですｗ

CloudWatch とはどういうものか

CloudWatch は便利なので、EC2 のインスタンスを使うようになったら活用して欲しい。

2013年4月15日月曜日

Amazon CloudWatch とはなにか

AWSクラウドリソースの状態をモニタリング

http://aws.amazon.com/jp/cloudwatch/

メトリクスを収集

メトリクスをグラフで表示

ユーザに通知

2013年4月15日月曜日

CloudWatch でできること(1)

メトリクスを収集

監視対象 (無料)

Billing

EC2 (基本的モニタリング) -- 5分間隔 インスタンスを起動するときに On にする

EBS

RDS

DynamoDB

ELB / Elastic Cache / EMR / SNS

SQS / Storage Gateway

監視対象 (有料)

EC2 (詳細モニタリング) / 1分間隔

Auto Scaling グループ / 1分間隔

カスタムメトリクス

2013年4月15日月曜日

CloudWatch でできること(2)

カスタムメトリクス

ユーザが自由に値をCloudWatchに送信

自前のシステムに組み込み可能

2013年4月15日月曜日

CloudWatch でできること (3)

通知

SNS

auto-scaling

管理者へ連絡 メール or SMS (；´Д｀)

2013年4月15日月曜日

CloudWatch でできること (4)

メトリクスをグラフ表示 (Billing の例)

2013年4月15日月曜日

SNS = (Simple Notification Services)

( ´ﾟдﾟ｀)ｴｰ まだベータですか？

CloudWatch は通知する仕組みにSNSを使っている。

トピック = アクション

ポリシー = トピックの内容を定義

プロトコル = HTTP / HTTPS / Email / SQS / SMS (←日本は駄目)

エンドポイント= メールアドレス / URL / 電話番号

課金

リクエスト 100万件/月 まで無料

通知 HTTP(S) / Email / SMS / SQS ごとに無料枠あり

ぶっちゃけ障害の通知はあまりもらいたくないｗ = 無料枠で足りる。

2013年4月15日月曜日

CloudWatch を使ってみよう

ユースケース

AWS 請求書の予想請求額（トータル）で$100を超えたら、自分に通知する。

2013年4月15日月曜日

準備

Enable Monitoring for Your AWS Charges を有効にする。（Billing に関するメトリクスを取得する場合のみ）

2013年4月15日月曜日

SNSのトピックを定義

リージョンは N. Virginia を選択

TOPIC を作成

Protocolは Email

endpoint に通知先メールアドレス

通知先メールアドレスに確認のメールが届く

Confirm subscription をクリック

2013年4月15日月曜日

アラームを作るリージョンは N.Virginia を選択

CloudWatch を選択 アラームを作成

2013年4月15日月曜日

メトリクスの指定

2013年4月15日月曜日

通知条件の指定

2013年4月15日月曜日

SNSのトピックを呼ぶ

アラームのステートは、ALARM (発生)/OK (正常復帰) /

INSUFFICIENT_DATA (データが受信できないとき) を選択

2013年4月15日月曜日

設定内容の確認

2013年4月15日月曜日

CloudWatch のカスタムメトリクス

Amazon CloudWatch Command Line Tool を使います。

用意するもの

Java Runtime

アクセスキーID とシークレットアクセス

2013年4月15日月曜日

CloudWatch にデータを送信する

環境変数 EC2_REGION にリージョンを指定 (東京なら ap-northeast-1)

mon-put-data コマンドを使用

-m → メトリクス名 何でもいい

-n → NameSpace AWS 以外なら OK!

-v → 値

-u → 単位

% env EC2_REGION=ap-northeast-1 mon-put-data -m RequestLatency -n "JAWS-UG" -v 100 -u Milliseconds

2013年4月15日月曜日

CloudWatch からデータを取り出す

% env EC2_REGION=ap-northeast-1 mon-list-metrics -n "JAWS-UG"RequestLatency JAWS-UG

% env EC2_REGION=ap-northeast-1 mon-get-stats RequestLantency -n "JAWS-UG"\ -s Average --headers2013-04-07 09:39:00 100.0 Milliseconds

メトリクスは２週間で消えます。

2013年4月15日月曜日

マネジメントコンソールで確認

2013年4月15日月曜日

ZABBIX との連携

2013年4月15日月曜日

まとめ

落としたくないインスタンスがあるなら使いましょう。

EC2を使ってサービスをするなら、死活監視だけでも使うメリットはある。

カスタムメトリクスは楽しいです。何でも監視したくなる！（→懲りすぎる悪い癖ですｗ）

2013年4月15日月曜日