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