CloudWatch のアラームを作ったことはあっても、通知メールが届いた瞬間に何から開けばよいか迷う人は多いはずです。メトリクスのグラフを見て、すぐ再起動や設定変更に手が伸びると、原因が分からないまま直ってしまい、同じ通知がまた来ます。この記事は、直す前に「状態、範囲、変更、ログ」の順で切り分ける型を説明します。コンソールの操作手順ではなく、何をどの順で見るかの考え方を扱います。
この記事の結論
- まず見るのはアラームの状態と履歴です。ALARM は「しきい値を超えた」、INSUFFICIENT_DATA は「判定できない」で、後者は異常とは限りません。
- 次にメトリクスのグラフで「いつから」「どの範囲か（1台か全体か）」を確かめます。
- 「その少し前に何かを変えたか」は CloudTrail のイベント履歴で、誰が・いつ・どの操作をしたかを見ます。
- 原因の手がかりは CloudWatch Logs で絞ります。直すのはその後で、直したら記録を残します。
- 通知が多すぎる、少なすぎるのは運用の課題として振り返り、しきい値や複合アラームで直します。
アラームが鳴ったとき、最初に何を見ればよいのか
結論から言うと、最初に見るのは「いま何が起きているか」ではなく「アラーム自身が何を言っているか」です。どのアラームが、どの状態に変わり、いつ変わったのか。通知メールの文面にも書いてありますが、アラームの履歴で確かめるのが確実です。
初動を 4 つの問いに分けると、次のようになります。
- 状態：このアラームは何の状態か（ALARM か INSUFFICIENT_DATA か）。
- 範囲：いつから、どこで（1台か全体か）数字が変わったか。
- 変更：その少し前に、誰が何を変えたか。
- ログ：アプリや OS の中では何が起きているか。
この順番には理由があります。後ろの問いほど調べるのに手間がかかるので、手間の小さいものから確かめ、見るべき範囲を狭めていきます。また「変更」を「ログ」より先にするのは、設定変更が原因の障害は、ログを読むより変更記録を見るほうが早く答えにたどり着くことが多いからです。
FIRST RESPONSE初動の4ステップ
直す前に、状態・範囲・変更・ログの順で切り分ける
-
状態を見る
ALARM か INSUFFICIENT_DATA か
-
いつから・どこで
メトリクスで時刻と範囲
-
変更を見る
CloudTrail で誰が何を
-
ログを見る
Logs Insights で絞る
「直す」はこの 4 つの後ろに置きます。原因が分からないまま直すと、直った理由が説明できず、再発を防ぐ手も打てません。
ALARM・OK・INSUFFICIENT_DATA は何を意味するか
メトリクスアラームの状態は 3 つです。それぞれの意味を取り違えると、初動の向きが変わってしまいます。
| 状態 | 意味 | まず疑うこと |
|---|---|---|
| OK | メトリクスがしきい値の内側にある | 通知が来ていれば、直前に ALARM から戻った可能性 |
| ALARM | メトリクスがしきい値を超えた状態が、設定した期間続いた | 実際に負荷や異常が起きているか、しきい値が実態に合っているか |
| INSUFFICIENT_DATA | 判定に足るデータが届いていない | 対象が止まっていないか、メトリクスが送られているか |
ここで大事なのは、ALARM が「しきい値を超えた」という事実だけを表していることです。ユーザーに影響が出ているかどうかは、アラームの状態からは分かりません。逆に INSUFFICIENT_DATA は、アラームを作った直後や、対象のリソースが停止中のときにも出ます。INSUFFICIENT_DATA は「異常」ではなく「判定できない」と読むのが出発点です。
ALARM VS NO DATA2つの状態の読み方
ALARM は超えた事実、INSUFFICIENT_DATA は判定できない
ALARM
しきい値を超えた状態が続いた
- 意味基準を超えたという事実
- まず疑うこと実害の有無としきい値の妥当性
INSUFFICIENT_DATA
判定に足るデータが無い
- 意味異常とは限らない
- まず疑うこと対象の停止、データが届いているか
アラームには履歴があり、状態がいつ何から何に変わったかを後から確認できます。公式ドキュメントによると、アラームの履歴は 30 日間保持されます。「昨日の夜に一度鳴って、自然に戻っていた」といった出来事も、この履歴で追えます。
CHECK 1ここまでの確認
アラームが INSUFFICIENT_DATA になっていたとき、最初に疑うのはどれですか?
答えと解説
答え: 2. 判定に使うデータが届いていない（対象が止まっている、送られていないなど）
INSUFFICIENT_DATA は「判定できない」状態で、異常とは限りません。まず対象が動いているか、メトリクスが届いているかを確かめます。「ALARM・OK・INSUFFICIENT_DATA は何を意味するか」の章を読み直してください。
「いつから・どこで」をメトリクスで確かめる
状態を確認したら、アラームの元になっているメトリクスのグラフを開きます。ここで確かめたいのは、次の 2 点だけです。
- いつから：数字が変わり始めた時刻。アラームが鳴った時刻ではなく、グラフ上で最初に動いた時刻を見ます。鳴った時刻は、評価の期間が過ぎた後なので遅れます。
- どこで：1台だけか、全体か。ディメンション（インスタンス単位、サービス単位など）で分けて見て、特定の1台だけが外れているのか、全部が同じ動きをしているのかを確かめます。
1台だけが外れているなら、そのリソース固有の問題を疑います。全体が同時に動いているなら、共通の依存先、デプロイ、設定変更を疑います。この区別だけで、次に調べる場所がかなり変わります。
グラフを見るときの注意が 2 つあります。1 つ目は、表示期間を広げて「平常時の姿」と比べることです。数字が高いこと自体が普通の時間帯もあります。2 つ目は、統計（平均、最大など）と期間の粒度で見え方が変わることです。平均では目立たない一瞬の跳ね上がりも、最大で見ると出ることがあります。アラームが使っている統計に合わせて見ると、鳴った理由が納得しやすくなります。
この段階で「いつから」が分かると、次の問いが立ちます。その時刻の少し前に、何か変わっていないか。
「何が変わったか」を CloudTrail のイベント履歴で見る
設定変更が原因の障害は、運用の現場でとても多い型です。セキュリティグループのルール、ルートテーブル、IAM ポリシー、スケーリングの設定などが、誰かの操作や自動化で書き換わると、翌朝から一部の通信だけ失敗する、といったことが起きます。
こうした「誰が・いつ・どの API を呼んだか」を記録しているのが AWS CloudTrail です。何も設定しなくても、コンソールの「イベント履歴」から過去の管理イベントを検索できます。
| 項目 | イベント履歴で言えること |
|---|---|
| 期間 | 過去 90 日の管理イベント |
| 範囲 | リージョンごと（見たいリージョンを切り替える） |
| 絞り込み | 1 つの属性でしか絞れない（ユーザー名、イベント名、リソース名など） |
読み方の基本は、メトリクスで見つけた「いつから」の少し前の時間帯に絞り、イベント名（変更系の API 名）やリソース名で探すことです。見つかったイベントには、呼び出した主体、時刻、API 名、対象が残っています。「その変更は、数字が動き始める少し前だった」と並べられれば、有力な手がかりになります。
注意点は 3 つあります。
- 時間が前後しても因果とは限らない。 変更と異常が近かったというだけでは、原因とは言い切れません。ログや設定の中身で裏を取ります。
- 自動化もイベントに残る。 人の操作だけでなく、IaC のデプロイや Auto Scaling などサービスが代わりに呼んだ API も並びます。主体の欄を見て、人か仕組みかを分けます。
- 90 日より前や、複数条件の検索には別の備えが要る。 長く残したい場合は証跡を作って S3 などに保存します（保存期間の設計は別の記事の範囲です）。
見るものの役割分担
メトリクスはいつ、CloudTrail は誰が何を、ログはなぜ
-
メトリクス — いつから・どこで
数字が動き始めた時刻と範囲
-
CloudTrail — 誰が何を変えたか
過去 90 日の管理イベント（イベント履歴）
-
CloudWatch Logs — なぜそうなったか
Logs Insights で絞り込み・集計
CHECK 2ここまでの確認
昨夜のうちに、誰がセキュリティグループの設定を変えたかを調べたいとき、最初に開く先はどれですか?
答えと解説
答え: 2. CloudTrail のイベント履歴
誰が・いつ・どの API を呼んだかを記録しているのは CloudTrail です。メトリクスは「いつから変わったか」、ログは「アプリの中で何が起きたか」を見る道具です。「何が変わったかを CloudTrail のイベント履歴で見る」の章を読み直してください。
ログで原因を絞る（Logs Insights の使いどころ）
メトリクスで時刻と範囲が決まり、CloudTrail で変更の有無が分かったら、最後にアプリや OS の中で何が起きていたかを CloudWatch Logs で確かめます。ここで効くのが CloudWatch Logs Insights です。保存済みのロググループに対して、クエリで絞り込みと集計をその場で行えます。
たとえば「5xx が出ている時間帯に、どのパスのエラーが多いか」を知りたいときは、エラーを含む行に絞り込み、パスごとに件数を数えて並べ替える、という順に組み立てます。
fields @timestamp, @message
| filter @message like /ERROR/
| stats count() by bin(5m)
こうすると、エラーが 5 分ごとにどう増えたかが分かります。メトリクスのグラフで見つけた「いつから」と、ログの中でエラーが増え始めた時刻が重なっていれば、原因の絞り込みが進みます。
ここで使い分けを整理しておきます。
- ログを数に変えて常時見張りたい → メトリクスフィルターで数値化し、そのメトリクスにアラームを付けて通知する。
- 起きてしまったことを、その場で調べたい → Logs Insights で絞り込んで集計する。
前者は「次から早く気づく」ための仕組み、後者は「いま起きていることを調べる」道具です。初動で使うのは後者です。
CHECK 3ここまでの確認
すでに CloudWatch Logs に入っているログを、障害対応の最中にその場で絞り込んで件数を集計したいとき、使うのはどれですか?
答えと解説
答え: 1. CloudWatch Logs Insights
Logs Insights はロググループに対してクエリを書き、絞り込みと集計をその場で行えます。アラームの履歴は状態の変化の記録、CloudTrail は API 操作の記録で、アプリのログの中身は集計できません。「ログで原因を絞る」の章を読み直してください。
直したあとに残すこと｜アラームの振り返りと、うるさいアラームの直し方
原因が分かって対処できたら、終わる前に 3 つを残します。
- 経緯の記録：いつ鳴ったか、いつからの異常か、何が原因か、何をしたか。アラームの履歴や CloudTrail のイベントは、保持期間が過ぎると見られなくなるので、必要な部分は文章で残します。
- 再発防止：原因が変更なら変更手順を、しきい値が実態に合っていなかったなら設定を直します。
- アラーム自体の見直し：今回、もっと早く気づけなかったか。逆に、実害のない通知は多くなかったか。
通知が多すぎる状態を放っておくと、本当に重要な通知が埋もれます。複数の条件を組み合わせて、ほんとうに対応が要るときだけ鳴らせる複合アラームは、ノイズを減らす手段として公式ドキュメントでも紹介されています。通知が少なすぎる側の対策は、見逃したメトリクスにアラームを足すことです。
何を監視対象にするか、しきい値をどう決めるか、誰に知らせるかといった設計は、初動とは別の話です。次の記事で扱います。
READ ALSO — 実務向け・段3 基盤
監視設計｜何を見るかは SLO から逆算する。4つのシグナルと、アラームを鳴らす基準の決め方
まとめ
アラームが鳴ったときの初動は、直すことではなく、切り分けることです。状態と履歴で何が起きたかを確かめ、メトリクスで「いつから・どこで」を決め、CloudTrail で「何が変わったか」を見て、ログで「なぜ」を絞ります。そのうえで直して、記録を残します。
道具の役割は決まっています。メトリクスは時刻と範囲、CloudTrail は変更の主体と内容、ログはアプリの中の様子です。迷ったら、いま知りたいのが「いつ」「誰が」「なぜ」のどれかを自分に聞いてみてください。
参照ソース
- Amazon CloudWatch ユーザーガイド｜メールを送信するアラームを作成する — アラームの種類（メトリクス・複合）、状態の扱い、アラーム履歴の保持、INSUFFICIENT_DATA が問題とは限らないこと、複合アラームでノイズを減らせることの根拠に使用
- AWS CloudTrail ユーザーガイド｜イベント履歴でイベントを表示する — イベント履歴が過去 90 日の管理イベントであること、リージョンごとであること、絞り込みが 1 つの属性に限られることの根拠に使用
