Amazon CloudWatchによる監視を理解する
注文サイトが遅いときは、CPU、要求数、エラー数、ログを時間に沿って確認します。CloudWatchはこうした運用状態を観測するためのサービスです。数値を表示することと、異常を検知して知らせることを分けて学びます。
この単元で学ぶこと
- メトリクス・ログ・アラームの役割を区別できる
- 対象と統計・期間・欠測を考慮して指標を読める
- CloudTrailやConfigと使い分けられる
本文解説
数値を時系列にする CPU使用率を一度見るだけでは、いつから負荷が高いか分かりません。時刻と値を持つメトリクスなら、要求数やエラー数と並べて変化を確認できます。CloudWatchはAWSサービスや追加収集した指標を扱い、運用状態を可視化します。
対象を識別する CPUの値でも、EC2-Aの値とEC2-Bの値は別です。名前空間やディメンションなどを確認して、どの資源の値を見ているか特定します。全体平均が低くても一台だけ過負荷という場合があるため、集計の範囲を確認します。
統計と期間を読む 平均値は全体の傾向を見やすい一方、短時間の高負荷を小さく見せることがあります。最大値、件数、評価期間などを目的に合わせます。例えば瞬間的な一回の増加と、数期間続く高負荷では、通知すべき条件が異なります。
ログは詳細を説明する アプリケーションのエラーメッセージや処理記録をCloudWatch Logsなどへ集めると、数値が悪化した理由を調べやすくなります。ただしアプリログは送信設定が必要です。AWS APIを誰が実行したかを調べるCloudTrailの証跡とは役割が違います。
アラームへつなげる アラームでは対象指標、統計、期間、しきい値などを決め、必要な通知や対応を設定します。グラフを置いたダッシュボードだけでは担当者へ通知されません。異常を検知する条件と、その通知を誰が受けるかを合わせて設計します。
追加収集が必要な値 EC2の標準メトリクスだけでゲストOS内のすべての情報が分かるわけではありません。メモリ使用量など必要な項目に応じてCloudWatchエージェント等を設定します。収集権限や送信先、収集間隔、ログの保存期間も確認します。
欠測と正常を分ける データが届かないことはCPUが0%で正常なことと同じではありません。対象停止、収集エージェントの障害、送信権限などを調べます。アラームには欠測時の扱いも関わるので、何を正常とするかを明確にして検証します。
例題：三つの観点 CPUが高い時刻はCloudWatch、同時刻の設定変更者はCloudTrail、変更前後のリソース構成はConfigで調べる、という使い分けができます。時刻が一致するだけで原因と断定せず、対象と変更内容を照合して仮説を確かめます。
図解
重要ポイント
- 数値・ログ・通知を別の役割として組み合わせる。
- 対象、統計、期間が違えば同じ名称の値でも意味が違う。
- 標準でないOS指標は追加収集を検討する。
- 欠測をゼロや正常と同一視しない。
間違えやすい点
- ダッシュボード作成だけで通知設定まで完了としない。
- 平均値だけで短い悪化を見落とさない。
- 全OS指標がEC2標準で取れると思わない。
用語解説
- メトリクス
- CPU使用率や要求数など、時刻とともに記録される数値。単位・集計期間・対象を合わせて読む。
- アラーム
- メトリクスなどの評価条件に応じて状態が変わり、設定した通知や対応へつなげる仕組み。
- 管理イベント
- AWSリソースの作成や設定変更など、管理面の操作を記録するイベント。
- データイベント
- S3オブジェクトへの取得・書込みなど、資源内のデータに対する操作を記録するイベント。対象の明示設定を確認する。
- 構成項目
- AWS Configが記録する、対象資源のある時点での属性や関係などの情報。
- 準拠評価
- 定めたルールに対象構成が合っているかを判定すること。未設定の要件まで保証するものではない。
関連教材
参考資料
教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。
確認問題の出題・採点や学習履歴の保存にはログインが必要です。