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!!