先に要点
監視は大事 と言われることは多いですが、実際にどこまでやるべきかは意外と分かりにくいです。
特に小規模なシステムでは、最初から本格的な運用監視を全部入れるのは重い一方で、何もないと障害に気づけません。
このページでは、2026年4月4日時点で Google Cloud Architecture Framework のアラート設計、Google SRE Workbook の監視、Prometheus の公式ドキュメント、AWS CloudWatch Alarms の公開情報を確認しながら、最低限どこまで必要か を実務目線で整理します。
Linux サーバーを立てた直後にどこから整えるべきかを先に見たい場合は、Linuxサーバーの初期設定で最初にやることは？見直したい項目を実務目線で整理 もあわせて読むと流れがつかみやすいです。
ランサムウェアのように、入られたあとにどこで気づけるか まで含めて整理したい場合は、ランサムウェアとは？手口・対応策・実際に起きた事件をわかりやすく解説 もかなり相性がよいです。
監視はどこまで必要か
結論から言うと、監視は 全部入れるか、入れないか ではなく、段階で考えた方がうまくいきます。
たとえば、最初の段階なら次で十分なことも多いです。
- サービスが落ちたら分かる
- 何が起きたかをログで追える
- 連絡先と判断基準が決まっている
逆に、次のような状態だと監視を入れたつもりでも運用では弱いです。
- 監視画面はあるが誰も見ない
- 通知は飛ぶが、全部同じ重要度で鳴る
- ログは残っているが、異常時にどこを見ればよいか分からない
- 深夜通知を避けたいのに、緊急度の分け方がない
つまり、監視で本当に大事なのは 項目数 より 異常に気づけるか と 気づいたあとに動けるか です。
まず必要なのは死活監視
死活監視 は、システムが応答しているかを見る一番基本の監視です。
最初に入れるなら、ここからがかなり自然です。
見る対象はたとえばこのあたりです。
- Web サイトのトップやログイン画面が 200 を返すか
- API が応答するか
- サーバーに疎通があるか
- 証明書切れや名前解決異常で入口が落ちていないか
ここで大事なのは、サーバーが起動している と 利用者が使える は別だということです。
たとえば OS は動いていても、アプリだけ落ちていたり、DB 接続だけ死んでいたり、ログイン画面だけ 500 を返していたりします。
なので実務では、単なる疎通確認よりも、利用者が使うURL や 重要API を見た方が役に立ちやすいです。
ログ監視は「全部見る」ではなく「異常を拾う」
ログ監視 は、ログを全部眺め続けることではありません。
現実的には、異常の兆候を拾う 設計に寄せる方が回しやすいです。
まず見やすいのはこのあたりです。
- 失敗ログインの急増
- 500 エラーの増加
- 例外ログの急増
- ディスク容量不足に近いメッセージ
- バックアップ失敗
- ジョブ失敗やキュー滞留
逆に、何でも通知対象にするとかなりつらいです。
正常系の情報まで全部通知すると、すぐに 見ない通知 になります。
ログ監視で最低限決めたいこと
1. どのログを見るか
認証ログ、アプリ例外、Web サーバーエラー、バックアップ結果など、まずは本当に困るものだけに絞ります。
2. 何を異常とみなすか
1回出たら即通知なのか、5分で一定回数を超えたら通知なのかを決めておくと、無駄なアラートが減ります。
3. どこに集めるか
サーバー内だけで見るのか、外部サービスへ集約するのかを決めます。障害時に見に行ける場所かが大事です。
4. どこまで保存するか
短すぎると調査できず、長すぎると管理が重くなります。まずは調査に必要な期間を基準に決めます。
通知設計がない監視は回りにくい
アラート を入れたのにうまく回らないケースは多いです。
原因はかなりの割合で、何を誰にどう知らせるか が決まっていないことです。
実務では、少なくとも次を分けて考えた方がかなり楽です。
- 夜中でも起こすべき障害
- 朝見ればよい警告
- 担当者だけが拾えばよいメモ通知
たとえば、
このあたりは緊急度が高いです。
一方で、
- ディスク使用率が少し高め
- 失敗ログインが少し増えた
- 一時的な遅延が出た
のようなものは、即起床レベルとは限りません。
通知設計で先に決めたいこと
- 誰に通知するか
- 何分続いたら通知するか
- どの手段で通知するか
- 誰が一次対応するか
- 対応後にどう収束させるか
ここがないと、通知は飛ぶけど誰も責任を持たない 状態になりやすいです。
実務でよくある監視の段階
規模によって差はありますが、小規模から中規模でよくある段階はこのあたりです。
| 段階 | まず見るもの | 目的 |
|---|---|---|
| 最初 | 死活監視 | 落ちたことに気づけるようにする |
| 次 | ログ監視 | 異常の原因を追いやすくする |
| その次 | 通知設計 | 異常時に迷わず動けるようにする |
| 余裕が出たら | 傾向監視、容量監視、複合条件 | 予兆を見たり、誤通知を減らしたりする |
最初から複雑な条件や精密なダッシュボードを作るより、落ちたら分かる、異常を追える、通知が整理されている の順で整える方が失敗しにくいです。
死活監視だけでは足りない理由
死活監視 だけだと、使いにくいが落ちてはいない 状態を拾いにくいです。
たとえば、
- 500 エラーは出ているが一部だけ
- ログインだけ失敗する
- バックアップが止まっている
- 管理画面だけ異常に遅い
- 失敗ログインが急増している
こういうケースは、ログ監視 や個別の確認がないと気づきにくいです。
つまり、死活監視は入口としてかなり大事ですが、それだけで 安全に運用できている とまでは言えません。
実際のやり方をざっくり言うと
実際に入れるなら、まずは次の順がおすすめです。
- 重要URLを 1〜3 個だけ選ぶ
ログイン画面、トップ、重要APIなど、本当に止まると困る場所を決めます。 - 失敗時の通知先を決める
メールだけでよいのか、チャット通知もいるのかを決めます。 - アプリログとエラーログの置き場を整理する
障害時に迷わず見に行けるようにします。 - よく起きる異常を 2〜3 個だけ検知対象にする
500 エラー急増、失敗ログイン急増、バックアップ失敗あたりから入ると現実的です。 - 通知の重みを分ける
夜間起床レベル、営業時間内対応レベル、記録だけ残すレベルに分けます。
このくらいでも、何もない状態よりかなり運用しやすくなります。
よくある失敗
監視項目を増やすこと自体が目的になってしまい、誰が見るのか、何をしたら異常なのか、夜間に起こすべきかが決まっていないことです。これだと、通知が増えるほど逆に見なくなります。
ほかにも、次の失敗はかなり多いです。
- 死活監視だけで安心して、バックアップ失敗や認証異常を見ていない
- ログは保存しているが、異常時にどこを見るか決まっていない
- 全通知が同じチャンネルへ飛び、重要度が埋もれる
- 一時的な失敗まで全部即通知して、アラート疲れになる
- 深夜通知を嫌って通知を全部弱くし、重大障害まで朝まで気づかない
まとめ
監視 は、最初から大きく作り込む必要はありません。
ただし、落ちたら分かる、異常を追える、誰にどう知らせるかが決まっている までは、小規模でもかなり大事です。
迷ったら、まずは 死活監視、次に ログ監視、その次に 通知設計 の順で考えると整理しやすいです。
全部を完璧にするより、少ない監視をちゃんと回す方が、実務ではずっと役に立ちます。
参考情報
- Google Cloud: Create alerting policies
- Google SRE Workbook: Monitoring
- Prometheus: Alerting overview
- Prometheus: Alertmanager
- AWS CloudWatch: Using Amazon CloudWatch alarms
- AWS CloudWatch: Combining alarms