Amazon CloudWatchによる監視のシナリオ判断
イベント開始後に注文が遅くなりました。平均CPUは低く、アラームも鳴っていません。どの値を集め、どの条件で異常とし、ログや操作記録をどう照合するかを検討します。
この単元で学ぶこと
- 監視が異常を見逃した理由を指標設定から特定できる
- 欠測や追加収集の必要性を判断できる
- 通知からログ・操作・構成の調査へつなげられる
本文解説
平均だけでは見えない状態 Web3台のうち1台だけが過負荷でも、全体平均は低く見える場合があります。まず対象別の値へ分け、短い悪化を長い期間で平均していないか確認します。CPUだけでなく要求数やエラー数、応答時間も同じ時刻で並べます。
業務の失敗を測る CPUが低くてもDB待ちで注文が失敗することがあります。利用者の成功率や処理時間を示す指標を準備し、機器の生存だけでなく業務を観測します。アプリが何を成功と記録するかも確認し、単にHTTP応答が返るだけの検査にしないようにします。
アラームの条件を修正する 一瞬の変化で大量通知が出るなら、評価期間や必要な継続条件を見直します。一方、長い平均で障害を見逃すなら期間や統計が適切か調べます。しきい値を高くして通知を消すだけでは、異常の発見能力を失う場合があります。
ログで内容を追う エラー件数が増えた時間帯のアプリログを確認します。タイムアウトなのか、入力エラーなのか、権限拒否なのかで対処は異なります。ログがCloudWatchへ届いていなければ、対象ファイル、収集設定、権限、送信先を確認します。
メモリ不足の疑い EC2のCPUは低いのに処理が落ちるなら、メモリなどOS内部の情報が必要になることがあります。標準の監視に値がなければ、エージェント等で必要な指標を収集します。設定だけで満足せず、実際に測定値が届くことを確認します。
データが途切れた場合 深夜に指標がなくなっていたら、停止計画と一致するか、エージェントが落ちたかを調べます。欠測を正常扱いにすると障害を隠す場合があり、常に異常扱いにすると予定停止で不要通知になる場合があります。用途に応じた条件を決めます。
変更との照合 障害直前のAPI操作はCloudTrailで、構成の変化はConfigで調べます。指標が上がった時刻と操作時刻が近くても、別の資源であれば直接の原因とは限りません。対象ID、時刻、変更内容をそろえて検証します。
対応の最後まで試す 検証ではアラーム状態だけでなく、担当者が通知を受け、手順書や必要なログへ到達できることを確認します。通知が来ない原因が受信経路なら、CPUしきい値を下げても解決しません。検知・配送・判断を分けて改善します。
図解
重要ポイント
- 全体平均から個別資源の値へ掘り下げる。
- CPU以外に業務成功・応答時間も考える。
- 欠測と予定停止を区別する。
- アラームから担当者まで通知が届くことを試す。
間違えやすい点
- 通知数を減らすためだけにしきい値を上げない。
- 時間が近い別資源の操作を原因と断定しない。
- 収集設定を置いただけで値が届いたと見なさない。
用語解説
- メトリクス
- CPU使用率や要求数など、時刻とともに記録される数値。単位・集計期間・対象を合わせて読む。
- アラーム
- メトリクスなどの評価条件に応じて状態が変わり、設定した通知や対応へつなげる仕組み。
- 管理イベント
- AWSリソースの作成や設定変更など、管理面の操作を記録するイベント。
- データイベント
- S3オブジェクトへの取得・書込みなど、資源内のデータに対する操作を記録するイベント。対象の明示設定を確認する。
- 構成項目
- AWS Configが記録する、対象資源のある時点での属性や関係などの情報。
- 準拠評価
- 定めたルールに対象構成が合っているかを判定すること。未設定の要件まで保証するものではない。
関連教材
参考資料
教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。
確認問題の出題・採点や学習履歴の保存にはログインが必要です。