CloudWatch を開くと、CPU 使用率・ネットワークの入出力・ディスクの読み書きと、メトリクスは最初から並んでいます。それなのに「何を見ればいいか分からない」のは、指標が無いからではなく、「何が正常か」が決まっていないからです。監視設計は、道具の設定の話ではなく、「利用者にとって正常とは何か」を先に決める話です。この記事は、SLO から逆算して4つのシグナルで組む監視の設計と、アラームを鳴らす基準の決め方を、実務向けに整理します。
この記事の結論
- 監視設計は、利用者にとって正常とは何か（SLO）を先に決め、そこから「何を測るか（SLI）」「いつ人を起こすか（アラーム）」を逆算します。
- 見るべき指標は4つに集約できます。レイテンシ・トラフィック・エラー・飽和（Google の SRE 本の「4つのゴールデンシグナル」）。
- 道具は3種類。メトリクス（いま正常か）・ログ（なぜ異常か）・トレース（どこで遅いか）。役割が違うので、1つで代用しません。
- アラームは「人が起きる価値があるもの」だけに絞ります。利用者に見える指標（レイテンシ・エラー率）に付け、CPU のような原因側の指標は調べるときに見ます。
- 監視は作って終わりではなく、障害のたびに「気づけたか・早く気づけたか」を振り返って直します。
監視設計は SLO から逆算する
SLO（Service Level Objective）は、「このサービスは、利用者に対してこの水準を保つ」と自分たちで決めた目標です。「リクエストの 99.5% が 500 ミリ秒以内に成功する」のように書きます。契約として相手に約束するSLAとは違い、内部の目標です。
SLO を測るための指標がSLI（Service Level Indicator）です。「500 ミリ秒以内に成功したリクエストの割合」がそれです。
監視設計の順番は、この逆算です。
- SLO を決める。 利用者にとって「使えている」とはどういう状態か。
- SLI を決める。 それをどの数字で測るか。
- SLI を出すための指標とログを集める。 何を、どこから、どの粒度で。
- SLO を下回りそうなときにアラームを鳴らす。 いつ、誰を起こすか。
CPU 使用率から始めると、この逆算になりません。CPU が 90% でも利用者の応答が速ければ正常で、CPU が 20% でも応答が遅ければ異常だからです。
見るべき指標は4つに集約できる
FOUR GOLDEN SIGNALS見るべき4つ
利用者に見える3つにアラームを、飽和は予兆に
-
1.レイテンシ — 応答にかかる時間
成功と失敗を分けて、平均ではなく p95・p99 を見る
-
2.トラフィック — どれだけ使われているか
エラー率の分母。急減はそれ自体が異常のサイン
-
3.エラー — 失敗した割合
5xx だけでなく、200 で中身が間違い・遅すぎるも失敗
-
4.飽和 — リソースがどれだけいっぱいか
CPU・メモリ・接続数・キュー。壊れる前の予兆として見る
Google の SRE 本（Site Reliability Engineering）の「分散システムの監視」の章は、利用者に向いたシステムで見るべき指標を4つに集約しています。「4つのゴールデンシグナル」と呼ばれます。
| シグナル | 何を測るか | AWS での置き場所（例） | 注意 |
|---|---|---|---|
| レイテンシ | リクエストの応答にかかる時間 | ALB の TargetResponseTime、API Gateway の Latency | 成功と失敗を分けて見る。失敗が速く返ると平均が良く見える。平均ではなく p95・p99 を見る |
| トラフィック | どれだけ使われているか | ALB の RequestCount、SQS の受信数 | 「エラー率」の分母。急減はそれ自体が異常のサイン |
| エラー | 失敗したリクエストの割合 | ALB の HTTPCode_Target_5XX_Count、アプリのログから作るメトリクス | 「明示的な失敗（5xx）」と「暗黙の失敗（200 だが中身が間違い、遅すぎる）」がある |
| 飽和 | リソースがどれだけいっぱいか | CPU・メモリ・ディスク・接続数・キューの長さ | 利用者には直接見えない。「これ以上増えると壊れる」の予兆として見る |
利用者に見えるのは上の3つ（レイテンシ・トラフィック・エラー）で、飽和は「壊れる前の予兆」です。人を起こすアラームは上の3つに、飽和は調べるときと容量の計画に使うと、役割が整理できます。
CHECK 1ここまでの確認
監視設計の最初の一歩はどれ?
答えと解説
答え: 2. 利用者にとって正常とは何か（SLO）を決める
監視設計は SLO から逆算します。CPU が 90% でも応答が速ければ正常で、20% でも応答が遅ければ異常だからです。
道具は3種類: メトリクス・ログ・トレース
監視の道具は、役割で3つに分かれます。1つで全部を賄おうとすると、どれも中途半端になります。
- メトリクスは、数値の時系列です。「いま正常か」を一目で見る道具で、ダッシュボードとアラームの元になります。AWS では CloudWatch メトリクス。
- ログは、出来事の記録です。「なぜ異常か」を調べる道具で、リクエスト ID・時刻・エラーの内容を持ちます。AWS では CloudWatch Logs。構造化（JSON）にして、リクエスト ID を全部の行に付けておくと、あとで追えます。
- トレースは、1つのリクエストが複数のサービスをどう通ったかの記録です。「どこで遅いか」を調べる道具で、マイクロサービスやサーバーレスで効きます。AWS では X-Ray。
| 問い | 道具 | 例 |
|---|---|---|
| いま正常か | メトリクス | エラー率 0.1%、p99 レイテンシ 420 ms |
| なぜ異常か | ログ | リクエスト ID abc123 で DB 接続がタイムアウト |
| どこで遅いか | トレース | API → 認証サービス 30 ms → DB 380 ms |
ログからメトリクスを作ることもできます（CloudWatch Logs のメトリクスフィルター）。アプリのエラー率は、この方法で作ることが多いので、ログの形式は監視設計の一部として最初に決めます。
アラームは「人が起きる価値があるもの」だけ
アラームで一番多い失敗は、鳴りすぎることです。鳴りすぎると無視されるようになり、本当の障害のときに気づけません。基準は1つです。「このアラームが鳴ったら、人がいますぐ何かをする必要があるか」。無いなら、それはアラームではなくダッシュボードに置きます。
WHO GETS PAGED人を起こす門
利用者に見える指標だけを、傾向で通す
アラーム（鳴ったら人がいますぐ動くもの）
- エラー率SLO を下回りそう 起こす利用者に見える
- p99レイテンシが目標超え 起こす5分のうち3回
- CPU使用率が高い 起こさないダッシュボードへ
- 1回1分だけの 5xx 起こさない傾向で見る
アラームを絞る基準
- 利用者に見える指標に付ける。 エラー率が SLO を下回りそう、p99 レイテンシが目標を超えた。CPU が高い、はダッシュボードへ
- 「1回の値」ではなく「一定期間の傾向」で鳴らす。 1分だけの 5xx は無視してよいことが多い。5分のうち3回、のように評価期間を持たせる
- 鳴ったときの手順（Runbook）を書いてから鳴らす。 手順が無いアラームは、鳴っても何をすればいいか分からない
- 重さを分ける。 いますぐ起きる（ページ）、翌営業日に見る（チケット）、記録だけ（ログ）。全部を同じ経路に流さない
- 鳴らなかった障害・鳴ったが不要だったアラームを、障害のたびに振り返る。 監視は運用の中で直し続けるもの
CloudWatch アラームは、メトリクスに対して「しきい値・評価期間・データポイント数」を設定し、SNS を通じてメールやチャットや PagerDuty に通知します。複数のアラームを組み合わせる複合アラーム（「エラー率が高い AND トラフィックが通常」のときだけ）も作れます。設定の手順は公式ドキュメントに従い、ここでは「何に・どの基準で付けるか」だけを決めます。
MONITORING LOOP監視は直し続ける
作って終わりではなく、障害のたびに直す輪
監視の輪
回るほど気づける
- SLO を決める
- SLI を測る
- アラームを置く
- 障害が起きる
- 振り返るここが起点
RULE 1
鳴らなかった障害を残す
気づけなかった理由を SLI とアラームに戻す
RULE 2
鳴ったが不要だったアラームを消す
鳴りすぎると無視される
CHECK 2ここまでの確認
4つのゴールデンシグナルのうち、「壊れる前の予兆」として見るのはどれ?
答えと解説
答え: 3. 飽和
レイテンシ・トラフィック・エラーは利用者に見える指標で、人を起こすアラームに使います。飽和（CPU・メモリ・キューの長さ）は予兆と容量の計画に使います。
「動いている」と「運用できている」の差
段3の到達点は「運用まで回せる」ことです。監視設計は、その中核です。「動いている」を「運用できている」に変えるには、次の状態が要ります。
| 状態 | 問い | 監視で答える道具 |
|---|---|---|
| 動いている | サービスは応答しているか | ヘルスチェック、トラフィック |
| 正常に動いている | 利用者にとって使えているか | SLI（レイテンシ・エラー率）と SLO |
| 壊れたら分かる | 異常に気づけるか、何分で | アラームと通知の経路 |
| なぜ壊れたか分かる | 原因を追えるか | ログ（リクエスト ID）、トレース |
| 壊れる前に分かる | 予兆を掴めるか | 飽和のメトリクス、容量の推移 |
この5つを上から順に埋めるのが、実務での監視設計の進め方です。全部を最初から作るのではなく、まず「正常に動いている」を SLI で測れる状態を作り、次に「壊れたら分かる」アラームを1つ置く。そこから障害のたびに足していきます。
FROM RUNNING TO OPERABLE「動いている」から「運用できている」へ
上から順に埋める。全部を最初から作らない
-
動いている
ヘルスチェック、トラフィック
-
正常に動いている
SLI（レイテンシ・エラー率）と SLO
-
壊れたら分かる
アラームと通知の経路
-
なぜ壊れたか分かる
ログ（リクエスト ID）、トレース
-
壊れる前に分かる
飽和のメトリクス、容量の推移
CHECK 3ここまでの確認
「このアラームを置くべきか」の判断基準として、この記事が挙げたのはどれ?
答えと解説
答え: 1. 鳴ったら人がいますぐ何かをする必要があるか
鳴りすぎると無視されます。いますぐ動く必要が無いものはアラームではなくダッシュボードに置き、鳴らす前に手順（Runbook）を書きます。
まとめ
監視設計は、SLO（利用者にとって正常とは何か）から逆算します。見る指標はレイテンシ・トラフィック・エラー・飽和の4つに集約でき、道具はメトリクス（いま正常か）・ログ（なぜ）・トレース（どこで）の3種類を役割で使い分けます。アラームは「人が起きる価値があるもの」だけに絞り、利用者に見える指標に付け、鳴らす前に手順を書きます。監視は障害のたびに直し続けるものです。設計判断の「捨てたもの」を意識する考え方は、次のトレードオフの考え方で扱います。
参照ソース
- Monitoring Distributed Systems（Google SRE Book） — 4つのゴールデンシグナル（レイテンシ・トラフィック・エラー・飽和）と、アラームを「人が対応する必要があるもの」に絞る考え方の出典
- Amazon CloudWatch とは（AWS CloudWatch ユーザーガイド） — メトリクス・アラーム・ダッシュボードの位置づけの根拠。2026年9月時点の記載
- Amazon CloudWatch アラームの使用（AWS CloudWatch ユーザーガイド） — しきい値・評価期間・データポイント数と、複合アラームの根拠
- ログデータからメトリクスを作成する（AWS CloudWatch Logs ユーザーガイド） — メトリクスフィルターでログからエラー率を作る方法の根拠
- AWS Well-Architected フレームワーク 信頼性の柱 — ワークロードの監視と、障害からの回復の設計原則の根拠
