akibaaws13-cloudwatchdashborads

Transcript

1. いまふたたびの CloudWatch Dashboards へ 2019.05.30 AKIBA.AWS #13 監視編 1
2. 2 ⾃⼰紹介 園部 治 • クラスメソッド株式会社 オペレーション部 2019年1⽉ Join • 好きなAWSサービス ・CloudWatch ・Systems Manager • OpsJAWS 運営 Professional series Coming soon ..?
3. 3 少しだけ宣伝を…
4. 4 アジェンダ 1. なぜ、いまふたたび CloudWatch Dashboards︖ 2. Dev.IO 恒例 やってみた︕
5. 5 アジェンダ 1. なぜ、いまふたたび CloudWatch Dashboards︖ 2. Dev.IO 恒例 やってみた︕
6. 6 CloudWatch Dashboards - おさらい - “CloudWatchに収集されたデータ” から対象サービスの状態 を可視化するダッシュボードサービス （引⽤︓AWS Black Belt Online Seminar CloudWatch ）
7. 7 CloudWatch Dashboards - おさらい - 2015年10⽉ サービスリリース︕︕ 追加できるのは 線グラフとテキストのみ... 引⽤︓https://aws.amazon.com/jp/blogs/aws/cloudwatch-dashboards-create-use-customized-metrics-views/
8. 8 内的な変化（更新）
9. 9 外的な変化 l 監視を 取り巻く環境（対象システム） の変化 l 監視⾃体の 役割・考え⽅ の変化 （きっとこの辺は先輩たちがたくさん話してくれているはず...ﾎﾞｿﾎﾞｿ） 先輩に任せるワタシの図
10. 10 Observability
11. Observability at Twitter Twitter サービス間通信を表した 有名な図『 デス・スター』 引⽤︓https://blog.twitter.com/engineering/en_us/a/2013/observability-at-twitter.html 11 Observability とは︖
12. 12 Observability とは︖ 『可観測性（かかんそくせい）』 引⽤︓ http://ja.Wikipedia.org 引⽤︓ しくみがわかるKubernetes Azure で動かしながら学ぶコンセプトと実践知識 https://www.amazon.co.jp/dp/4798157848/ 第3部 実践編 CHAPTER 12 可観測性（observability）とは、システムの 外部出⼒を観測 することでシステム の 内部状態を推測可能 かどうかの尺度である。 クラウドコンピューティング や サーバーレスコンピューティング、マイクロサー ビスアーキテクチャ の監視、という⽂脈で最近⽬にする機会が増えた⾔葉 （中略） その定義は まだコンセンサスを得ておらず、使い⼿によって微妙にニュアンスが 異なる印象です。
13. Four pillars of the Observability • Monitoring（モニタリング） • Alerting/visualization（アラート / 可視化） • Distributed systems tracing infrastructure（トレーシング） • Log aggregation/analytics（ログ収集・分析） 引⽤︓https://blog.twitter.com/engineering/en_us/a/2016/observability-at-twitter-technical-overview-part-i.html または別のところでは...個⼈的には上の⽅が好み。 • Metrics • Tracing • Logging 13 Observability とは︖
14. 14 Observability とは︖ • Monitoring ＝ Observability ではない • Monitoring < Observability でもない • Observability ⾃体は 新しい技法など ではない • 複雑化するシステム（サービス）状態を捉えるための 概念 • 予測するのではなく 追跡・把握（デバッグ）できる （今⽇のところはこの辺で...） 『 アーキテクチャの進化にともない 監視も変化している 』
15. 15 Observability とは︖ (オマケ) AWS サービスにマッピングすると ※私⾒です 4つの柱 AWS サービス Monitoring CloudWatch Metrics Alerting / visualization CloudWatch Alarms +α / CloudWatch Dashboards Distributed systems tracing infrastructure AWS X-RAY AWS App Mesh Log aggregation / analytics CloudWatch Logs / CloudWatch Logs insights Amazon Elasticsearch Service Amazon Athena
16. 16 章まとめ Q. なぜ、いまふたたび CloudWatch Dashboards︖ A. ワンモア チャレンジ なタイミング︖︕ • Observability というキーワードに⾒られるように取り巻 く状況が変化している • CloudWatch Dashboards （CloudWatch）も機能拡張が されてきている • ⽇の⽬を⾒ない CloudWatch Dashboards が不憫だから
17. 17 アジェンダ 1. なぜ、いまふたたび CloudWatch Dashboards︖ 2. Dev.IO 恒例 やってみた︕
18. ※ Systems Manager やマネジメントコンソールのリソースグループを作成するとグループ 内リソースだけ表⽰することが可能です。 18 その前に - 概要 - ・概要 ・サービス間ダッシュボード ・各利⽤サービス ・すべてのリソース ・リソースグループ(※) デフォルトダッシュボード名が表⽰ 直近のアラーム 各サービスの状況 サービス間ダッシュボード 各サービス⾃動作成ダッシュボード
19. 参考情報︓ https://dev.classmethod.jp/cloud/aws/cloudwatch-automatic-dashboards/ 19 その前に - サービス間ダッシュボード - サービス間ダッシュボード AWS 側が推奨するベストプラクティスで⾃動作成され 各サービスを串刺しすることで状況を可視化することが可能
20. 参考情報︓ https://dev.classmethod.jp/cloud/aws/cloudwatch-automatic-dashboards/ 20 その前に - 各サービス - 各サービス AWS 側が推奨するベストプラクティスで⾃動作成 リソース⼀覧
21. 21 その前に - ダッシュボード - 前述した⾃動ダッシュボードでは 不⾜する部分 をカスタマイズする位置付けがオススメ︕ ⼀覧が表⽰ 折れ線グラフ 数値 クエリの結果 アラーム（⾊も変わる） ・テキスト（Markdown） スタックエリア
22. 22 やってみた︕ 以下を仮想システム仕様として 【オンラインショップ】 • 構成はシンプル • スモールスタート（PoC 位置付け） • 継続して機能を拡張 • ⽉に1度セールを実施 • 運⽤担当は少数で複数サイトを管理 AWS Cloud Amazon RDS Elastic Load Balancing Auto Scaling group Instances
23. 23 ダッシュボードを作成してみる 名称を「CloudWatch-Default 」とすることで「概要ページ」デフォルトのダッシュボー ト（右下図）として表⽰されます。 リソースが混在している場合はリソースグループを作成するとリソースグループ単位で表⽰ することも可能です。
24. 24 KEY Metrics と KPI を 追加してみる 多くの Metrics からサービス状況を把握するのに 有⽤な Metrics を 数値 で追加 （Webサイトのため、フロントエンド要素を多めに） KPI を追加する場合は、既存のMetricsのみでは難しいため Metric Math や put-metrics-data で加⼯し 線グラフ で 追加 例︓ページビュー、SLO、コンバージョン率
25. 25 TIPS CloudWatch のメトリクスに関する仕様 まだ発⽣していないエラー などは選択出来ない。その場合は ソースやCLIで追加を⾏う。 “ 過去14⽇間にわたりメトリクスがデータを発⾏していない場合、CloudWatch ダッシュボードにグラフを追加する際に検索に表⽰されません” 引⽤︓ https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/add_old_metrics_to_graph.html
26. 26 RunBooks を追記してみる アラームなどから状況検知した場合の ネクストアクション（⼿順書）としての導線を テキスト(Markdown) でダッシュボードへ追加
27. 27 アノテーションを付与してみる CloudWatch ではグラフへ注釈を追加可能 リリースやセールイベント開始＆終了（未来時刻も登録可能 ） 各イベントによる効果を可視化することも可能。
28. 28 ログを追加してみる CloudWatch Logs にあるログは全て対象になります。 • ELB ︓ 処理が必要 • OS ︓ CloudWatch Agent により出⼒可能 • RDS ︓ RDS サービス設定で出⼒可能
29. 29 出来上がり • アラート⼀覧 （⾃動ダッシュボード） • Key Metrics や KPI を表⽰ • Run Books • イベントを終えるグラフ • エラーログ情報 （⾃前ダッシュボード） • サービス間ダッシュボード （⾃動ダッシュボード）
30. 30 章まとめ 仮想システムを設けて、出来るだけ各要素を盛り込んで CloudWatch Dashboards を作成してみました。 監視SaaSなどで⽤意された内容よりも劣る部分もありますが ⾃動ダッシュボードとカスタマイズダッシュボードを併⽤す ることで有⽤なシーンもあるはず︕ 特に、スモールスタートやシステム規模によっては当初から ハイレベルな製品にはいきなりチャレンジせずに、監視につ いてもスモールスタートし、必要な要件を洗いだすのがベ ター。 AWSを利⽤しているのであれば、既に利⽤可能な CloudWatchは、最適な選択肢かもしれない。
31. 31 まとめ ü Observability というワードに⾒られるように環境（ニー ズ）は変化している ü CloudWatch Dashboards（CloudWatch）も 進化中 ü スタートラインとしては充実してきている ü （とはいえ...）CloudWatch 推しではない ü 完全なサービスはなく、フェーズによって必要なサービス を選択するのが良い ü 監視は奥深い。だからこそ楽しい