AWS運用監視ノウハウ
CloudWatch
〜作ってからが本番です！〜
JAWS Festa Tohoku 2014

はじめまして！（じゃない方はこんにちは！）
Masashi Terui
照井 将士
!
https://www.facebook.com/marcy.terui
https://twitter.com/FumblePerson
!
(株)アグレックス 札幌事業所 システム部
AWS Consulting Partner New!!
AWSチーム技術リーダー（的な立ち位置）
!
JAWS-UG札幌下っ端メンバー
Chef Meetup Sapporo主催 New!!
!
東京生まれ札幌育ち
1987年 東京都大田区に生まれる
1992年 札幌へ移住
!
好きなAWSサービス：AWSドキュメント（サービスじゃないけど）

Agenda
CloudWatchって何？
なんでCloudWatch？
基本操作とカスタムメトリクス（デモ）
CloudWatchの基本概念
CloudWatchの良い所
CloudWatchの足りない所
もっと便利に
新機能CloudWatch Logs
まとめ
この辺りは独自の解釈が含まれており、
AWSの公式情報ではない部分も多いです。

CloudWatchって何？
AWSのリソースをモニタリングするためのWebサービス
CloudWatchの特徴
EC2インスタンスや各サービスのモニタリング
利用料金の取得も可能
その他、カスタムメトリクスとして、
任意のデータも保存可能
メトリクスをベースにアラームを設定できる
アラームからAuto Scaling Policy実行、SNSで通知

なんでCloudWatch？
その疑問は正しいです
数あるサービスの中でも地味
ぶっちゃけイケてない所もある（良い所もいっぱいありますよ！）
Zabbix,NagiosとかNew Relic,Mackerelとかの方が良い所あるよ？
だがしかし！AWSを便利に使いたいなら必須！
RDSとかELBとかそもそも独自の内部監視(Agent等)を入れられない
特にELBは埋もらせておくには惜しい情報が多い
AutoScalingやる時に使う
どうせ使わないといけないなら上手く使いたい
運用監視大事！
派手な構築の話だけでは実際のシステムは成り立たない
わがまま言ってごめんなさい（to 関係者）

CloudWatchの基本概念
CloudWatchは必ずしも監視サービスではないかも？
フルマネージドな時系列データストア＋アプリケーション
メトリクスのグラフGUIが付いてる
閾値を指定してトリガーを登録できる
組み合わせることで監視サービスになる
トリガーにSNSを登録してプッシュ通知
E-mail
HTTP Request → 自動リアルタイム処理（すぐにアクション）
SQS → 自動バッチ処理（時間がかかる、確実に処理したい）
他サービス同様、APIで情報取得・コントロールができる
独自の監視の仕組みが作れる
監視以外にも使える
少なくともAutoScalingは監視じゃない
AutoScalingや各種自動化等の運用支援サービスと言えるかも

CloudWatchの基本概念（図にすると）

CloudWatchの基本概念（図にすると）
全ての中心にある大事なサービス
…っぽく見える（見せ方の問題？ｗ）

基本操作とカスタムメトリクス（デモ）
この後色々話しますが、基本は簡単です。
というのをデモで感じてもらえれば…

基本操作とカスタムメトリクス（デモ）
実際の手順
SNSトピックを登録
メール通知
Subscribe（通知受信許可）
IAM Role作成
cloudwatch:putMetricData（メトリクス送信）
ec2:describeInstances（自身のデータを取得）
EC2起動
UserData(cloud-init)で諸々設定
Apache HTTP Serverインストール
定期的にhttpdプロセス数のカスタムメトリクスを送信する設定
アラーム設定
httpdプロセス数のカスタムメトリクス
Apache Benchでプロセス数を上げてみる
メール通知が飛んだら成功！
時間の都合上この方法ですが、先に作成してからSSHで流す、
Chefレシピやスクリプト実行等、方法は色々あります。

基本操作とカスタムメトリクス（デモ）
IAM Roleの内容
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"cloudwatch:PutMetricData"
],
"Resource": [
"*"
]
}
]
}

基本操作とカスタムメトリクス（デモ）
UserDataのシェル内容
#!/bin/sh
REGION=`curl http://169.254.169.254/latest/meta-data/placement/availability-zone | sed -e 's/.$//g'`
ENDPOINT=http://monitoring.$REGION.amazonaws.com
INSTANCE_ID=`curl http://169.254.169.254/latest/meta-data/instance-id`
INSTANCE_NAME=$(aws ec2 describe-instances --region ${REGION} --instance-ids ${INSTANCE_ID} --query
'Reservations[].Instances[].Tags[?Key==`Name`].Value' --output text)
(
cat <<-EOP
#!/bin/sh
PROC=`ps -ef | grep "httpd" | grep -v "grep" | wc -l`
NOW=`date --iso-8601=seconds`
aws cloudwatch --region=$REGION --endpoint-url=$ENDPOINT put-metric-data --namespace "System/Linux" --metric-data "[{"Dimensions":
[{"Name":"Instance","Value":"$INSTANCE_NAME($INSTANCE_ID)"}],"Timestamp":"$NOW","Value":$PROC.0,"Unit":"Count",
"MetricName":"Process-httpd"}]"
EOP
) > /usr/local/cloudwatch.sh
chmod 755 /usr/local/cloudwatch.sh
(
cat <<-EOP
* * * * * /usr/local/cloudwatch.sh > /dev/null 2>&1
EOP
) > /usr/local/.crontab
crontab /usr/local/.crontab
yum -y install httpd php
(
cat <<-EOP
<?php sleep(1); ?>
JAWS Festa 2014!!<br/>
$INSTANCE_NAME($INSTANCE_ID)
EOP
) > /var/www/html/index.html
/etc/init.d/httpd start

CloudWatchの良い所
安い（2014.09.06現在、月当たり）
無料枠
標準提供のメトリクス
10カスタムメトリクス、10アラーム、100万APIリクエスト
料金設定
$0.50 / カスタムメトリクス
$0.10 / アラーム
$0.01 / 1,000 API リクエスト
監視用にサーバ立てるよりも遥かに安いと思われる
サーバ/システム保守コストも考えよう
もちろん使い方による

CloudWatchの良い所
スケーラブル
何百台でも何千台でも
何項目（カスタムメトリクス）でも
カスタムメトリクスでなんでも突っ込める
メトリクスの取得APIもシステム負荷を気にせずにいつでもどこでも
保存容量無制限（ただし、保存期間は２週間）
フルマネージドで運用要らず（↓自前運用時の例）
メトリクスデータストア（DBサーバ）
APIエンドポイント（Web/APサーバ）
Web GUI（Web/APサーバ）
通知システム（メールサーバ等）

CloudWatchの良い所
他サービスとの連携
AutoScaling
SNSによる多彩な通知方法
人に通知（メール）
システムに通知（HTTP、SQS）
IAMによる認証機構
IAM Role
Credentialキー
二段階認証
目的別に権限指定できる（↓例）
監視対象にはメトリクス登録権限だけ与える
メトリクス取得だけできる外部監視システム連携用
グラフを見るだけの監視員ユーザ

CloudWatchの足りない所
２週間しか保存できない
メトリクスの間隔は最短1分
秒単位のリアルタイム監視ができない
ただし、1分間（以上も可）の集計値を入れることもできる
Max,Min,Total,SampleCountの項目がある
単純に一つの瞬間値だけ入れることも可能
通知内容のフォーマットが変えられない
SNS側の制限でもある
メッセージタイトルがどうなるか考えて名前とか付ける必要が…
メッセージ文面が分かりづらい（もちろん英語…）
システム通知のフォーマット変わると困るけど

CloudWatchの足りない所
最近はだいぶ良くなったけど、まだGUIが微妙… ※個人的見解
メトリクスのデータ構造が独自でちょっとわかりにくい ※個人的見解
Namespace ≒ 監視グループ（標準ではサービス毎）
MetricName ≒ 監視項目
Dimensions ≒ 監視対象の情報（e.g. AZ, Instance[Name,Id])
ここから先は個人的願望ですｗ
メトリクスにタグつけたい
アラームにタグつけたい
Dimensionsだとメトリクスデータの持ち方が変わってしまうので

もっと便利に
別のデータストアに連携する
２週間より長く保持したい
見ることをとりあえず考えないならS3
すぐに or 定期的に見たいなら（＋もっと見やすく！）
GrowthForecast（主にMySQL）→ シンプル！
http://kazeburo.github.io/GrowthForecast/index.ja.html
Zabbix（主にMySQL）→ 多機能なので見るだけだと勿体無い
http://www.zabbix.com/jp/
Grafana (Graphite or InfluxDB) → オススメ！
http://grafana.org/
その他にも色々あります
視覚化目的の場合、CloudWatchを一時保管用・予備GUIと捉えると良い
２週間以前が失われても仕方ないと割り切る
データストアの可用性担保や障害復旧にゆとりができる
長期保存要件があるならついでにS3に入れておく

もっと便利に
参考までに弊社の監視ダッシュボード（by Grafana）です。
ほとんどの情報をCloudWatchから取得している。
一部例外有（Response TimeやSlow Query等）
!
請求情報やインスタンス数とかも見れたり…
※部外者に見せたら怒られるので載せてませんがｗ

もっと便利に
メール以外の通知方法を作る
IRC
チャットサービス（HipChatやSlack等）
Twitter
SNSのHTTP通知やSQS通知
HTTP通知をどこかのサーバで受ける
SQSをどこかのサーバがポーリング
受け取ったメッセージを解析し、対象のAPI等へ送信
中継だけじゃなく、システム内で閉じた自動対応の仕組みも作れる
そこまではやってないですが…いずれやりたい

もっと便利に
参考までに弊社のHipChat通知
通知された内容だけだと、
その時何が起きているのか把握しにくいので、
全体の状態を取得した上で出したりしている
状態が変化したら再度通知
平常時の監視運用業務から煩雑なメールを撤廃
モバイルクライアントもあるので外出先からも見られる
※見たく無いですけどね！ｗ

もっと便利に
別の監視システムと統合する
一つであらゆる問題に対応できるものは無い（当然CloudWatchも）
既に確立された監視の仕組みを持っている場合
EC2はそれをそのまま使っても良い
その他サービスはAPIでデータを抜いて集約する方法もある
ZabbixとかSensuとかだとWeb上に色々情報がある
おググりください
誰かが作ったPluginが既に公開されている場合も
https://github.com/sensu/sensu-community-plugins
逆に、別のシステムで取ったデータをCloudWatchに集約しても良い
カスタムメトリクスは何でもあり（形式さえ合わせられれば）
別の監視ツールなら簡単に取れて有用な指標もある
全く別々に扱うと運用に困るかも…
集約する or 役割分担をハッキリしておく

もっと便利に
参考までにCloudWatch→Graphite(Grafana)のデータ連携を行うスクリプト(PHP)
都合上、実際に使用している
ものではありませんが、
全体でたったの60行未満。
※ウンコードなのはご勘弁ｗ
!
これを定期的(cron)に実行。
!
大体こんなレベルで大抵は
実現できたりします。

新機能CloudWatch Logs
新機能！（2014.07 AWS Summit NYCで発表された）
ログの監視と集約のための機能
無料枠が大きい！
モニタリング用5GB（期間指定）
アーカイブ用5GB（指定期間後自動でアーカイブ）
現状はUS Eastのみのサポート
とりあえず貯めるだけなら別にUSでも良いかも
バックエンドはKinesisらしい
Kinesisは東京来てるから時間の問題？

新機能CloudWatch Logs
転送エージェントを利用してアップロード
AWS純正エージェント
fluent-plugin-cloudwatch-logs
もちろんAPIからのアップロードも可能
ただし、欠損等のケアは自分でやらないといけない
ログの保管形式
Log Event ≒ ログレコード
Log Stream ≒ 発生元毎のログシーケンス
Log Group ≒ ログ種別
フィルターを設定する
該当した数がCloudWatchメトリクスとして登録される
モニタリング
アラーム設定して通知
It’s me!! ※他Pluginの機能を移植しただけｗ

新機能CloudWatch Logs
新機能で使い倒してないので所感レベルですいません
安い
大きな無料枠
モニタリング対象は月当たり$0.5/GB
長期保存アーカイブは≒S3の保存料金っぽい
アーカイブ時にさらに圧縮されて保存されるらしい
とりあえずでS3に入れて塩漬けになっているようであれば乗り換え対象
他のログ管理サービスと比べると物足りない感がある？
リアルタイムモニタリングできない
検索できない
目指している方向が違う気もしている
現状はフィルター（からのメトリクス）監視に特化
CloudWatchと同じで、物足りない部分は他と連携して解決するものっぽい
一時集約用＋長期保存アーカイブ
何か（例えばFluentd Plugin）で吸い上げて分析用データストアへ…とか？
今後、機能は増えるはずなのであくまで現状

まとめ
作ってからが本番です！
AWSを使う上で、CloudWatchは避けて通ることはできない
シンプルにも使えるし、色々組み合わせて便利にも使える
便利な機能がたくさんあるが、物足りない部分もある
利点は活用し、欠点は何かで補って使おう
他ツール連携やAPIインテグレーションは実は簡単
あなたの運用監視スタイルを確立しよう！
上手に使って良い運用監視ライフを！

Thank you!!