AWS 道場 07

CloudWatch 監視 — ログから検知し、行動できる通知へつなぐ

監視の目的は、グラフを増やすことではなく、問題に早く気づき、次の調査を始められる状態にすることです。ログ・メトリクス・Alarm・通知を一本の流れで捉えます。

TL;DR

  1. ログは出来事、メトリクスは変化、Alarmは判断、通知は行動開始の合図。
  2. ログのパターンをMetric Filterで数値化すると、エラーをしきい値で検知できる。
  3. 通知は誰が何を確認すべきかを決めて初めて役に立つ。

01異常の有無だけでなく、原因調査へ進める材料をそろえる。

監視データを増やす前に、どの問いへ答える信号かを決める。

異常の有無だけでなく、原因調査へ進める材料をそろえる。
三角形の各頂点が、傾向・出来事・処理経路という別の調査材料を表す。

レイテンシ上昇をメトリクスで知り、遅いリクエストをトレースで絞り、対応するエラーログで入力や失敗理由を確認する。

一種類の信号だけで原因まで断定しない。メトリクスの急増は症状であり、ログやトレースによる裏付けが要る。

02文字列のイベントを、継続監視できる指標に変換する。

人がログを見続ける代わりに、異常パターンを数値へ変換する。

文字列のイベントを、継続監視できる指標に変換する。
左から右へ、500 errorのログが件数になり、Alarmの状態判定を経てSlackへ届く流れを読む。

5分間の500エラー件数をカスタムメトリクスへ変換し、しきい値超過でAlarmがSNS通知を開始する。

高カーディナリティな値をdimensionへ無制限に入れると、メトリクス数とコストが膨らむ。集約単位を先に決める。

03ノイズだけのアラートは、いずれ無視される。

通知を、受信者が次の確認へ移れる作業票として設計する。

ノイズだけのアラートは、いずれ無視される。
中央の通知カードを囲む6項目が、初動に必要な文脈を表している。

「stg cost-apiの5xxが5分で10件。該当ログはこちら。担当はAPIチーム」のように、症状と確認先を一緒に送る。

原因不明のまま「ERROR」とだけ通知すると、調査開始に時間がかかり、繰り返すほど無視されやすい。

結論

  1. ログ→メトリクス→Alarm→通知は、検知から初動までの一本の設計。
  2. アラート対象はユーザー影響と運用上の判断に結びつける。
  3. 通知後に何を見るかまで決めると、監視が運用として機能する。