どんな場面で検討するか
AWS 上のアプリのエラー・処理時間・資源不足・ログをまとめ、担当者が異常を検知して原因を切り分けたい場合。監視対象の稼働確認と、情報が収集できていること自体の確認を分ける用途。
組織で使う条件
監視のしきい値・欠測時の扱い・通知経路を記録し、通知が届いた後の担当・判断・復旧手順まで確認する。アラームの OK と、収集元の最後の成功時刻を別表示にする。 ログ保持を明示する。既定では期限なしのログがあるため、保持期間と用途を設定する。認証情報・個人情報の出力と、不要なディメンション増加を点検する。
採用前に試すこと
- 正常と合成エラーを送信し、ログ・メトリクス・アラームを処理 ID で照合する。
- 生存メトリクスの送信を停止し、欠測時の状態・通知・最終成功時刻を確認する。
- 検証通知先で受信と対応手順を確認し、保持期間・検索範囲・メトリクス方式別の費用を試算する。
合格と判断する条件
- 固定入力数と成功・失敗数が一致し、エラーの原因ログへたどり着ける。時刻・単位・集計粒度のずれがない。
- 指定した欠測の扱いへ移行し、停止を正常や 0 件へ変換しない。送信再開後の状態復帰を識別できる。
- 検知から担当者の確認まで追跡でき、監視停止の検知も残る。ログ・メトリクス・アラーム・API の費用を分けて説明できる。
見落としたくない点
- AWS 外の障害・利用者の操作感まで、AWS のリソース監視だけで把握できるとは扱わない。必要なら合成監視や他基盤の収集を組み合わせる。 欠測を正常・0 件に置換しない。エラーメトリクスのように通常は送られないものと、定期送信が必要な生存確認を同じ欠測設定にしない。
- AWS 外の障害・利用者の操作感まで、AWS のリソース監視だけで把握できるとは扱わない。必要なら合成監視や他基盤の収集を組み合わせる。
- 欠測を正常・0 件に置換しない。エラーメトリクスのように通常は送られないものと、定期送信が必要な生存確認を同じ欠測設定にしない。
根拠となる資料
Amazon Monitoring and Observability – Amazon CloudWatch
Configuring how CloudWatch alarms treat missing data