Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

CloudWatchツールの監視目的別使い分けの例

417 views

Published on

2020/10/05に開催された「JAWS-UG 初心者支部 #32 監視編 サーバーのモニタリングの基本を学ぼう。りたーんず」勉強会での私のLT資料になります。


https://jawsug-bgnr.connpass.com/event/189723/

Published in: Software
  • Be the first to comment

CloudWatchツールの監視目的別使い分けの例

  1. 1. #JAWS-UG 初心者支部 CloudWatchツールの監視目的別 使い分けの例 Author: Masaki Suzuki @makky12
  2. 2. #jawsug_bgnr 自己紹介 • 名前:鈴木 正樹 (Masaki Suzuki) • 在住:愛知県半田市 • 職業:フリーランスエンジニア • 業務:サーバーレスアプリのシステムアーキテクト/設計/開発 など • 技術: • クラウド(特にAWS&Serverless Frameworkが大好き) • 各種イベント・SNS・ブログでのクラウド普及活動(個人的に) • 好きなAWSサービス:Lambda, CloudFormation, Step Functions • SNS http://makky12.hatenablog.com/ https://github.com/smt7174 @makky12 (Masaki Suzuki@フリーランスクラウドエンジニア)
  3. 3. #jawsug_bgnr 内容 • CloudWatchツールの監視目的別での使い分け • Search All(全文検索) • インサイト • ダッシュボード • アラーム • どのツールを、どのような監視目的で使用しているか ※あくまで「私の場合は」になります ※サーバー監視を行う(導入する)際の「一例」として参照ください ※他にも、やり方は色々あると思います(むしろ教えてほしい…)
  4. 4. #jawsug_bgnr サーバー監視のケース • (とりあえずの)事象発生有無の確認&詳細調査 • Search All(全文検索) • インサイト • 各リソースのヘルスステータス確認 • ダッシュボード • 緊急度の高い事象(=早急に対策が必要) • アラーム
  5. 5. #jawsug_bgnr Search All(ロググループの全文検索) • 特定のキーワードで、ロググループ全体を検索可能 • 検索期間の指定も可能(むしろ、極力指定したほうが良い) • 適宜ログはアーカイブ化して、肥大化しないようにする • ある事象(エラーなど)の発生有無をとりあえず調べたい場合に使用 • キーワードがある程度分かる場合に用いる • (例) Error, Exception, Fatalなど • キーワードを入力するだけなので、手っ取り早い調査に用いる • インサイト/ダッシュボード/アラームなどと違い、事前準備が不要 • ログさえ出力していればOK
  6. 6. #jawsug_bgnr Search All(ロググループの全文検索)
  7. 7. #jawsug_bgnr インサイト • ログのクエリ検索 • CloudWatch Logsについて、SQLのようなクエリ検索が可能 • 各種関数、比較・算術などをはじめ、様々な機能が使用可能 • (例) 「ある文字の出現回数の合計(count)を1時間ごとに表示する」etc. • 複数ロググループを対象にできる • ある事象の発生について、もう少し細かく調査したい場合に • (例) 一定時間間隔での発生頻度の調査 etc. • (Search Allと併用して) 発生現象の詳細な監視 • ここまでいくと「監視」よりは「調査」なのかもしれないけど…
  8. 8. #jawsug_bgnr インサイト
  9. 9. #jawsug_bgnr ダッシュボード • 各種メトリクス・アラームの状態をまとめて監視できる • グラフで視覚的にわかりやすく表示できる • 表示内容(項目・位置・大きさなど)をJSONでカスタマイズ可能 • 主に各リソースのヘルスステータス(≒性能)の確認に用いている • API Gateway/Lambdaのレイテンシー • DynamoDBの読み込み/書き込みキャパシティユニット確認 etc. • チームで共有しておく必要がある事項の把握 • 視覚的に分かりやすいので、ステータスを把握しやすい • 複数リソースを一度に表示可能なので、全体を把握するのに向いている
  10. 10. #jawsug_bgnr ダッシュボード
  11. 11. #jawsug_bgnr アラーム • メトリクスの状態に応じて、ステータスを変化させる • ステータスは「OK」「アラーム」「不足」の3つ • 各ステータスに応じて、下記イベントの発生ができる • SNS(Eメール, Slack等)/オートスケーリング/EC2(EC2メトリクスのみ) • 各ステータスの条件は、カスタマイズ可能 • 緊急度の高い(=早急に対応しなければならない)事項への適用 • エラー発生、その他重要度・致命度が高い事象 • 専用にカスタムメトリクスを作成しておく • 特定のキーワードで検索(=発火)できるように
  12. 12. #jawsug_bgnr Search All /インサイトの課題 • どうしてもコンソールでの手作業が発生する(フィルタ条件/クエリなど) • アラームのような「監視の自動化」には不向き • 検索後、ログ内容の確認が必要になる(エラーメッセージなど) • 最終的には、1つ1つログを確認する必要がある • 「視覚的な把握のしやすさ」ではダッシュボードに劣る • あくまでも「監視の第一歩」として • 逆に「詳細な監視(というよりは調査)」にも向いている
  13. 13. #jawsug_bgnr ダッシュボードの課題 • メトリクスにある事項しか確認できない • 詳細事項の確認には不向き • 標準のメトリクスにない項目は、カスタムメトリクスを作成する必要がある • Search All/インサイトとの使い分けが重要 • グラフが見づらくなる場合がある • (例)折れ線グラフの場合、線が表示される場合とされない場合がある • 視覚的にパッと見でわかりにくい場合がある • 「一定間隔のサンプリング」という意味では、線が表示されないのが正しいのだけど…
  14. 14. #jawsug_bgnr アラームの課題 • 「一定時間内に条件を満たす(満たさない)」が厳密ではない? • 確実にステータスがOKになったのに、アラームアクションが継続される事がある • 「どの時間にサンプリングを実施しているか」がいまいち不明 • デプロイ時間基準? • アクション(=通知など)に気づかなければ、アラームも意味がない • アラームはあくまで「アクション」を行うだけ • アラームに気づく(≒アラームが埋もれない)運用・対策が必要 • メールクライアントのフィルタ機能を使用し、フォルダを分けておく • やたらとアラームを多くしすぎない etc. • あまり恒常的にアラームが来ると、アラームがアラームでなくなってしまう • 「ああ、またか」「多分、他の誰かが見てるからヨシ!」ということが発生しないように
  15. 15. #jawsug_bgnr まとめ • サーバー監視ツールには、いろいろな種類・特徴がある • 目的・作業内容によって、向き/不向きはある • 目的に応じた使い分けが重要 • 重要なのは、担当者自らが「アクション」を起こせること • モニタリングツールは、あくまで状態を監視&通知するだけ • 状態に応じて、適宜それに応じた対応ができる体制づくりを • アラームが「アラーム」としての価値を持つようにする • アラームが恒常的になりすぎないように • アラームの数、条件の見直しなどが必要
  16. 16. #jawsug_bgnr 以上です ご清聴ありがとうございました

×