「障害が起きてから気づく」のと「障害の予兆を検知して事前に対処する」のでは、ユーザー体験が天地ほど違う。監視の目的は「ユーザーより先に気づく」ことだ。
監視設計で一番大事なのは「何を監視するか」を決めること。全部監視するとノイズの海に溺れる。「本当に重要な4つのシグナル」に絞るのが鉄則。
監視すべき4大シグナル（Google SRE本より）：
- レイテンシ（遅延） — リクエストの応答時間。P50（中央値）だけでなくP95、P99も見る。P50が速くてもP99で5秒かかってたら、1%のユーザーが苦しんでる。
- トラフィック（流量） — リクエスト数、同時接続数。普段のパターンを把握しておけば、異常なスパイクにすぐ気づける。
- エラー（失敗率） — HTTP 5xxの割合。これが0%じゃなくても、普段0.01%なのに突然1%になったら要注意。
- サチュレーション（飽和度） — CPU、メモリ、ディスクの使用率。特にディスク使用率80%超えたら即アラート。ディスクフルは全サービスが死ぬ。
アラート設計の心得：
- アラートは少なく、意味あるものだけ — 1日10通のアラートが飛んでくると、全部無視するようになる。本当にヤバいときだけ通知。
- 対応手順をセットで — 「ディスク使用率80%超え」だけじゃなく「どのディレクトリが太ってるか確認するコマンド」までアラートに書く。深夜3時に思考停止でも対応できるように。
- 復旧したら自動で収束 — アラートが自己修復すること。「確認しました」ボタンを押さなくていい設計が理想。
ツールはPrometheus + Alertmanager + Grafanaで決まり。個人サーバーでもこの3点セットを入れておくと、障害対応のストレスが激減する。