Slide 1

Slide 1 text

いまふたたびの CloudWatch Dashboards へ 2019.05.30 AKIBA.AWS #13 監視編 1

Slide 2

Slide 2 text

2 ⾃⼰紹介 園部 治 • クラスメソッド株式会社 オペレーション部 2019年1⽉ Join • 好きなAWSサービス ・CloudWatch ・Systems Manager • OpsJAWS 運営 Professional series Coming soon ..?

Slide 3

Slide 3 text

3 少しだけ宣伝を…

Slide 4

Slide 4 text

4 アジェンダ 1. なぜ、いまふたたび CloudWatch Dashboards︖ 2. Dev.IO 恒例 やってみた︕

Slide 5

Slide 5 text

5 アジェンダ 1. なぜ、いまふたたび CloudWatch Dashboards︖ 2. Dev.IO 恒例 やってみた︕

Slide 6

Slide 6 text

6 CloudWatch Dashboards - おさらい - “CloudWatchに収集されたデータ” から対象サービスの状態 を可視化するダッシュボードサービス (引⽤︓AWS Black Belt Online Seminar CloudWatch )

Slide 7

Slide 7 text

7 CloudWatch Dashboards - おさらい - 2015年10⽉ サービスリリース︕︕ 追加できるのは 線グラフとテキストのみ... 引⽤︓https://aws.amazon.com/jp/blogs/aws/cloudwatch-dashboards-create-use-customized-metrics-views/

Slide 8

Slide 8 text

8 内的な変化(更新)

Slide 9

Slide 9 text

9 外的な変化 l 監視を 取り巻く環境(対象システム) の変化 l 監視⾃体の 役割・考え⽅ の変化 (きっとこの辺は先輩たちがたくさん話してくれているはず...ボソボソ) 先輩に任せるワタシの図

Slide 10

Slide 10 text

10 Observability

Slide 11

Slide 11 text

Observability at Twitter Twitter サービス間通信を表した 有名な図『 デス・スター』 引⽤︓https://blog.twitter.com/engineering/en_us/a/2013/observability-at-twitter.html 11 Observability とは︖

Slide 12

Slide 12 text

12 Observability とは︖ 『可観測性(かかんそくせい)』 引⽤︓ http://ja.Wikipedia.org 引⽤︓ しくみがわかるKubernetes Azure で動かしながら学ぶコンセプトと実践知識 https://www.amazon.co.jp/dp/4798157848/ 第3部 実践編 CHAPTER 12 可観測性(observability)とは、システムの 外部出⼒を観測 することでシステム の 内部状態を推測可能 かどうかの尺度である。 クラウドコンピューティング や サーバーレスコンピューティング、マイクロサー ビスアーキテクチャ の監視、という⽂脈で最近⽬にする機会が増えた⾔葉 (中略) その定義は まだコンセンサスを得ておらず、使い⼿によって微妙にニュアンスが 異なる印象です。

Slide 13

Slide 13 text

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 とは︖

Slide 14

Slide 14 text

14 Observability とは︖ • Monitoring = Observability ではない • Monitoring < Observability でもない • Observability ⾃体は 新しい技法など ではない • 複雑化するシステム(サービス)状態を捉えるための 概念 • 予測するのではなく 追跡・把握(デバッグ)できる (今⽇のところはこの辺で...) 『 アーキテクチャの進化にともない 監視も変化している 』

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

16 章まとめ Q. なぜ、いまふたたび CloudWatch Dashboards︖ A. ワンモア チャレンジ なタイミング︖︕ • Observability というキーワードに⾒られるように取り巻 く状況が変化している • CloudWatch Dashboards (CloudWatch)も機能拡張が されてきている • ⽇の⽬を⾒ない CloudWatch Dashboards が不憫だから

Slide 17

Slide 17 text

17 アジェンダ 1. なぜ、いまふたたび CloudWatch Dashboards︖ 2. Dev.IO 恒例 やってみた︕

Slide 18

Slide 18 text

※ Systems Manager やマネジメントコンソールのリソースグループを作成するとグループ 内リソースだけ表⽰することが可能です。 18 その前に - 概要 - ・概要 ・サービス間ダッシュボード ・各利⽤サービス ・すべてのリソース ・リソースグループ(※) デフォルトダッシュボード名が表⽰ 直近のアラーム 各サービスの状況 サービス間ダッシュボード 各サービス⾃動作成ダッシュボード

Slide 19

Slide 19 text

参考情報︓ https://dev.classmethod.jp/cloud/aws/cloudwatch-automatic-dashboards/ 19 その前に - サービス間ダッシュボード - サービス間ダッシュボード AWS 側が推奨するベストプラクティスで⾃動作成され 各サービスを串刺しすることで状況を可視化することが可能

Slide 20

Slide 20 text

参考情報︓ https://dev.classmethod.jp/cloud/aws/cloudwatch-automatic-dashboards/ 20 その前に - 各サービス - 各サービス AWS 側が推奨するベストプラクティスで⾃動作成 リソース⼀覧

Slide 21

Slide 21 text

21 その前に - ダッシュボード - 前述した⾃動ダッシュボードでは 不⾜する部分 をカスタマイズする位置付けがオススメ︕ ⼀覧が表⽰ 折れ線グラフ 数値 クエリの結果 アラーム(⾊も変わる) ・テキスト(Markdown) スタックエリア

Slide 22

Slide 22 text

22 やってみた︕ 以下を仮想システム仕様として 【オンラインショップ】 • 構成はシンプル • スモールスタート(PoC 位置付け) • 継続して機能を拡張 • ⽉に1度セールを実施 • 運⽤担当は少数で複数サイトを管理 AWS Cloud Amazon RDS Elastic Load Balancing Auto Scaling group Instances

Slide 23

Slide 23 text

23 ダッシュボードを作成してみる 名称を「CloudWatch-Default 」とすることで「概要ページ」デフォルトのダッシュボー ト(右下図)として表⽰されます。 リソースが混在している場合はリソースグループを作成するとリソースグループ単位で表⽰ することも可能です。

Slide 24

Slide 24 text

24 KEY Metrics と KPI を 追加してみる 多くの Metrics からサービス状況を把握するのに 有⽤な Metrics を 数値 で追加 (Webサイトのため、フロントエンド要素を多めに) KPI を追加する場合は、既存のMetricsのみでは難しいため Metric Math や put-metrics-data で加⼯し 線グラフ で 追加 例︓ページビュー、SLO、コンバージョン率

Slide 25

Slide 25 text

25 TIPS CloudWatch のメトリクスに関する仕様 まだ発⽣していないエラー などは選択出来ない。その場合は ソースやCLIで追加を⾏う。 “ 過去14⽇間にわたりメトリクスがデータを発⾏していない場合、CloudWatch ダッシュボードにグラフを追加する際に検索に表⽰されません” 引⽤︓ https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/add_old_metrics_to_graph.html

Slide 26

Slide 26 text

26 RunBooks を追記してみる アラームなどから状況検知した場合の ネクストアクション(⼿順書)としての導線を テキスト(Markdown) でダッシュボードへ追加

Slide 27

Slide 27 text

27 アノテーションを付与してみる CloudWatch ではグラフへ注釈を追加可能 リリースやセールイベント開始&終了(未来時刻も登録可能 ) 各イベントによる効果を可視化することも可能。

Slide 28

Slide 28 text

28 ログを追加してみる CloudWatch Logs にあるログは全て対象になります。 • ELB ︓ 処理が必要 • OS ︓ CloudWatch Agent により出⼒可能 • RDS ︓ RDS サービス設定で出⼒可能

Slide 29

Slide 29 text

29 出来上がり • アラート⼀覧 (⾃動ダッシュボード) • Key Metrics や KPI を表⽰ • Run Books • イベントを終えるグラフ • エラーログ情報 (⾃前ダッシュボード) • サービス間ダッシュボード (⾃動ダッシュボード)

Slide 30

Slide 30 text

30 章まとめ 仮想システムを設けて、出来るだけ各要素を盛り込んで CloudWatch Dashboards を作成してみました。 監視SaaSなどで⽤意された内容よりも劣る部分もありますが ⾃動ダッシュボードとカスタマイズダッシュボードを併⽤す ることで有⽤なシーンもあるはず︕ 特に、スモールスタートやシステム規模によっては当初から ハイレベルな製品にはいきなりチャレンジせずに、監視につ いてもスモールスタートし、必要な要件を洗いだすのがベ ター。 AWSを利⽤しているのであれば、既に利⽤可能な CloudWatchは、最適な選択肢かもしれない。

Slide 31

Slide 31 text

31 まとめ ü Observability というワードに⾒られるように環境(ニー ズ)は変化している ü CloudWatch Dashboards(CloudWatch)も 進化中 ü スタートラインとしては充実してきている ü (とはいえ...)CloudWatch 推しではない ü 完全なサービスはなく、フェーズによって必要なサービス を選択するのが良い ü 監視は奥深い。だからこそ楽しい

Slide 32

Slide 32 text

32