Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie AWS運用監視ノウハウ CloudWatch 〜作ってからが本番です！〜
Ähnlich wie AWS運用監視ノウハウ CloudWatch 〜作ってからが本番です！〜 (20)
Mehr von Terui Masashi
Mehr von Terui Masashi (20)
AWS運用監視ノウハウ CloudWatch 〜作ってからが本番です！〜
- 1. AWS運用監視ノウハウ CloudWatch 〜作ってからが本番です！〜 JAWS Festa Tohoku 2014
- 2. はじめまして！（じゃない方はこんにちは！） 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ドキュメント（サービスじゃないけど）
- 3. Agenda CloudWatchって何？ なんでCloudWatch？ 基本操作とカスタムメトリクス（デモ） CloudWatchの基本概念 CloudWatchの良い所 CloudWatchの足りない所 もっと便利に 新機能CloudWatch Logs まとめ この辺りは独自の解釈が含まれており、 AWSの公式情報ではない部分も多いです。
- 4. CloudWatchって何？ AWSのリソースをモニタリングするためのWebサービス CloudWatchの特徴 EC2インスタンスや各サービスのモニタリング 利用料金の取得も可能 その他、カスタムメトリクスとして、 任意のデータも保存可能 メトリクスをベースにアラームを設定できる アラームからAuto Scaling Policy実行、SNSで通知
- 5. なんでCloudWatch？ その疑問は正しいです 数あるサービスの中でも地味 ぶっちゃけイケてない所もある（良い所もいっぱいありますよ！） Zabbix,NagiosとかNew Relic,Mackerelとかの方が良い所あるよ？ だがしかし！AWSを便利に使いたいなら必須！ RDSとかELBとかそもそも独自の内部監視(Agent等)を入れられない 特にELBは埋もらせておくには惜しい情報が多い AutoScalingやる時に使う どうせ使わないといけないなら上手く使いたい 運用監視大事！ 派手な構築の話だけでは実際のシステムは成り立たない わがまま言ってごめんなさい（to 関係者）
- 6. CloudWatchの基本概念 CloudWatchは必ずしも監視サービスではないかも？ フルマネージドな時系列データストア＋アプリケーション メトリクスのグラフGUIが付いてる 閾値を指定してトリガーを登録できる 組み合わせることで監視サービスになる トリガーにSNSを登録してプッシュ通知 E-mail HTTP Request → 自動リアルタイム処理（すぐにアクション） SQS → 自動バッチ処理（時間がかかる、確実に処理したい） 他サービス同様、APIで情報取得・コントロールができる 独自の監視の仕組みが作れる 監視以外にも使える 少なくともAutoScalingは監視じゃない AutoScalingや各種自動化等の運用支援サービスと言えるかも
- 10. 基本操作とカスタムメトリクス（デモ） 実際の手順 SNSトピックを登録 メール通知 Subscribe（通知受信許可） IAM Role作成 cloudwatch:putMetricData（メトリクス送信） ec2:describeInstances（自身のデータを取得） EC2起動 UserData(cloud-init)で諸々設定 Apache HTTP Serverインストール 定期的にhttpdプロセス数のカスタムメトリクスを送信する設定 アラーム設定 httpdプロセス数のカスタムメトリクス Apache Benchでプロセス数を上げてみる メール通知が飛んだら成功！ 時間の都合上この方法ですが、先に作成してからSSHで流す、 Chefレシピやスクリプト実行等、方法は色々あります。
- 11. 基本操作とカスタムメトリクス（デモ） IAM Roleの内容 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:DescribeInstances", "cloudwatch:PutMetricData" ], "Resource": [ "*" ] } ] }
- 12. 基本操作とカスタムメトリクス（デモ） 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
- 13. CloudWatchの良い所 安い（2014.09.06現在、月当たり） 無料枠 標準提供のメトリクス 10カスタムメトリクス、10アラーム、100万APIリクエスト 料金設定 $0.50 / カスタムメトリクス $0.10 / アラーム $0.01 / 1,000 API リクエスト 監視用にサーバ立てるよりも遥かに安いと思われる サーバ/システム保守コストも考えよう もちろん使い方による
- 14. CloudWatchの良い所 スケーラブル 何百台でも何千台でも 何項目（カスタムメトリクス）でも カスタムメトリクスでなんでも突っ込める メトリクスの取得APIもシステム負荷を気にせずにいつでもどこでも 保存容量無制限（ただし、保存期間は２週間） フルマネージドで運用要らず（↓自前運用時の例） メトリクスデータストア（DBサーバ） APIエンドポイント（Web/APサーバ） Web GUI（Web/APサーバ） 通知システム（メールサーバ等）
- 15. CloudWatchの良い所 他サービスとの連携 AutoScaling SNSによる多彩な通知方法 人に通知（メール） システムに通知（HTTP、SQS） IAMによる認証機構 IAM Role Credentialキー 二段階認証 目的別に権限指定できる（↓例） 監視対象にはメトリクス登録権限だけ与える メトリクス取得だけできる外部監視システム連携用 グラフを見るだけの監視員ユーザ
- 16. CloudWatchの足りない所 ２週間しか保存できない メトリクスの間隔は最短1分 秒単位のリアルタイム監視ができない ただし、1分間（以上も可）の集計値を入れることもできる Max,Min,Total,SampleCountの項目がある 単純に一つの瞬間値だけ入れることも可能 通知内容のフォーマットが変えられない SNS側の制限でもある メッセージタイトルがどうなるか考えて名前とか付ける必要が… メッセージ文面が分かりづらい（もちろん英語…） システム通知のフォーマット変わると困るけど
- 17. CloudWatchの足りない所 最近はだいぶ良くなったけど、まだGUIが微妙… ※個人的見解 メトリクスのデータ構造が独自でちょっとわかりにくい ※個人的見解 Namespace ≒ 監視グループ（標準ではサービス毎） MetricName ≒ 監視項目 Dimensions ≒ 監視対象の情報（e.g. AZ, Instance[Name,Id]) ここから先は個人的願望ですｗ メトリクスにタグつけたい アラームにタグつけたい Dimensionsだとメトリクスデータの持ち方が変わってしまうので
- 18. もっと便利に 別のデータストアに連携する ２週間より長く保持したい 見ることをとりあえず考えないなら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に入れておく
- 19. もっと便利に 参考までに弊社の監視ダッシュボード（by Grafana）です。 ほとんどの情報をCloudWatchから取得している。 一部例外有（Response TimeやSlow Query等） ! 請求情報やインスタンス数とかも見れたり… ※部外者に見せたら怒られるので載せてませんがｗ
- 20. もっと便利に メール以外の通知方法を作る IRC チャットサービス（HipChatやSlack等） Twitter SNSのHTTP通知やSQS通知 HTTP通知をどこかのサーバで受ける SQSをどこかのサーバがポーリング 受け取ったメッセージを解析し、対象のAPI等へ送信 中継だけじゃなく、システム内で閉じた自動対応の仕組みも作れる そこまではやってないですが…いずれやりたい
- 21. もっと便利に 参考までに弊社のHipChat通知 通知された内容だけだと、 その時何が起きているのか把握しにくいので、 全体の状態を取得した上で出したりしている 状態が変化したら再度通知 平常時の監視運用業務から煩雑なメールを撤廃 モバイルクライアントもあるので外出先からも見られる ※見たく無いですけどね！ｗ
- 22. もっと便利に 別の監視システムと統合する 一つであらゆる問題に対応できるものは無い（当然CloudWatchも） 既に確立された監視の仕組みを持っている場合 EC2はそれをそのまま使っても良い その他サービスはAPIでデータを抜いて集約する方法もある ZabbixとかSensuとかだとWeb上に色々情報がある おググりください 誰かが作ったPluginが既に公開されている場合も https://github.com/sensu/sensu-community-plugins 逆に、別のシステムで取ったデータをCloudWatchに集約しても良い カスタムメトリクスは何でもあり（形式さえ合わせられれば） 別の監視ツールなら簡単に取れて有用な指標もある 全く別々に扱うと運用に困るかも… 集約する or 役割分担をハッキリしておく
- 23. もっと便利に 参考までにCloudWatch→Graphite(Grafana)のデータ連携を行うスクリプト(PHP) 都合上、実際に使用している ものではありませんが、 全体でたったの60行未満。 ※ウンコードなのはご勘弁ｗ ! これを定期的(cron)に実行。 ! 大体こんなレベルで大抵は 実現できたりします。
- 24. 新機能CloudWatch Logs 新機能！（2014.07 AWS Summit NYCで発表された） ログの監視と集約のための機能 無料枠が大きい！ モニタリング用5GB（期間指定） アーカイブ用5GB（指定期間後自動でアーカイブ） 現状はUS Eastのみのサポート とりあえず貯めるだけなら別にUSでも良いかも バックエンドはKinesisらしい Kinesisは東京来てるから時間の問題？
- 25. 新機能CloudWatch Logs 転送エージェントを利用してアップロード AWS純正エージェント fluent-plugin-cloudwatch-logs もちろんAPIからのアップロードも可能 ただし、欠損等のケアは自分でやらないといけない ログの保管形式 Log Event ≒ ログレコード Log Stream ≒ 発生元毎のログシーケンス Log Group ≒ ログ種別 フィルターを設定する 該当した数がCloudWatchメトリクスとして登録される モニタリング アラーム設定して通知 It’s me!! ※他Pluginの機能を移植しただけｗ
- 26. 新機能CloudWatch Logs 新機能で使い倒してないので所感レベルですいません 安い 大きな無料枠 モニタリング対象は月当たり$0.5/GB 長期保存アーカイブは≒S3の保存料金っぽい アーカイブ時にさらに圧縮されて保存されるらしい とりあえずでS3に入れて塩漬けになっているようであれば乗り換え対象 他のログ管理サービスと比べると物足りない感がある？ リアルタイムモニタリングできない 検索できない 目指している方向が違う気もしている 現状はフィルター（からのメトリクス）監視に特化 CloudWatchと同じで、物足りない部分は他と連携して解決するものっぽい 一時集約用＋長期保存アーカイブ 何か（例えばFluentd Plugin）で吸い上げて分析用データストアへ…とか？ 今後、機能は増えるはずなのであくまで現状
- 27. まとめ 作ってからが本番です！ AWSを使う上で、CloudWatchは避けて通ることはできない シンプルにも使えるし、色々組み合わせて便利にも使える 便利な機能がたくさんあるが、物足りない部分もある 利点は活用し、欠点は何かで補って使おう 他ツール連携やAPIインテグレーションは実は簡単 あなたの運用監視スタイルを確立しよう！ 上手に使って良い運用監視ライフを！
- 28. Thank you!!