三つの監視画面を並べて、自分のシステムにどれを入れるか落ち着いて見比べている一人運用の保守担当者
障害対応・運用監視約15分

死活監視・外形監視・リソース監視の違い｜最低限の監視設計

「サーバーは生きているのに、ユーザーからは『サイトが見られない』と言われた」。 「ディスクが満杯になる寸前まで、誰も気づかなかった」。

監視を入れているつもりでも、こういう抜けは起こります。 原因の多くは、監視を「種類」で整理できていないこと——つまり、何を見ていて、何を見ていないのかが自分でも分かっていないことです。

死活監視・外形監視・リソース監視。言葉は聞いたことがあっても、改めて「違いは?」と聞かれると、うまく説明できない。そんな状態のまま、なんとなく入れた監視で日々を回している人は少なくありません。これは知識不足ではなく、現場で体系立てて教わる機会がないだけです。

この記事では、3種類の監視を「何を見て・いつ気づきたいか」で整理し、一人運用でも最初に入れたい最低限の組み合わせを、比較表と優先順位つきで一緒に整理します。全部を一度に揃えなくて大丈夫です。

結論：3種類は「見る対象」が違うだけで、どれが偉いという話ではありません。死活監視=サーバーやプロセスが生きているか、外形監視=ユーザーから見て本当に使えるか、リソース監視=枯渇しそうな資源（ディスク・メモリ等）はないか。最初に入れるなら、まず外形監視で「ユーザー目線の生死」を1つ、次にリソース監視でディスクを1つ。この2つだけで、致命的な見落としの大半は防げます。死活監視はその土台として足していきます。

具体的なツールや閾値の数字は環境で変わります。この記事は「どれを・なぜ入れるか」の地図として使い、ツール選びや値の調整は自分の環境に合わせてください。

まず押さえる：3つの監視は「どこから見るか」が違う

3種類の違いは、難しく考えなくて大丈夫です。どの位置から、何を見ているかだけが違います。

ここで大事なのは、死活監視が「生きている」と言っても、ユーザーが使えるとは限らないことです。サーバーは ping に応答していても、Webアプリがエラーを返していたり、表示が極端に遅かったりすれば、ユーザーにとっては「落ちている」のと同じ。この差を埋めるのが外形監視です。

ユーザー側・サーバー内側・資源という三つの視点から、外形監視・死活監視・リソース監視がそれぞれ何を見ているかを示した位置関係の図
同じシステムを「どこから見るか」で3種類に分かれる。外形はユーザー側、死活とリソースは内側から

3種類を比べてみる（早見表）

それぞれの役割と限界を1枚にまとめると、こうなります。自分の監視に当てながら見てください。

監視の種類どこから見るか何を見る気づけること苦手なこと（見落とし）
死活監視システム内側サーバー・プロセスが動いているか（ping応答・プロセス・ポート）サーバー停止、プロセス落ち、ネットワーク断「生きているのに使えない」状態（アプリのエラー・極端な遅さ）
外形監視ユーザー側（外部）実際にアクセスして正しく・十分な速さで返るかサイトが見えない、ログインできない、表示が遅い、証明書切れ原因の特定（どこが悪いかまでは分からない）
リソース監視システム内側CPU・メモリ・ディスク・接続数などの残量と消費じわじわ進む枯渇、性能劣化の予兆突然の停止（リソースに余裕があっても落ちる時は落ちる）

表を見ると分かるとおり、1種類だけでは必ず死角ができます。死活監視はユーザー目線の不調を取りこぼし、外形監視は原因まで教えてくれず、リソース監視は突然死に弱い。だから「組み合わせ」で互いの穴を埋めるのが基本になります。次の章で、それぞれをもう少し具体的に見ます。

死活監視：いちばん基本だが、過信しないもの

死活監視は、最も古くからある監視で、考え方もシンプルです。「対象が応答するか」を一定間隔で確かめます。

代表的なやり方は次のとおりです。

死活監視の価値は、「土台が崩れていないか」を低コストで常時確認できることです。サーバーごと落ちた、プロセスが死んだ——こうした分かりやすい障害は、死活監視がいちばん早く教えてくれます。

ただし、冒頭でも触れたとおり、死活監視には大きな限界があります。「応答している＝正常に使える」ではないということです。

これらは死活監視では「正常」に見えてしまいます。だから死活監視は必要だが、それだけでは不十分。「サーバーは生きている」を確認する土台と位置づけ、ユーザー目線の確認は外形監視に任せます。

外形監視：ユーザーと同じ場所から「本当に使えるか」を見る

外形監視は、実際のユーザーと同じ外部の位置から、サービスへアクセスして確かめる監視です。「合成監視（Synthetic Monitoring）」と呼ばれることもあります。

具体的には、こんなことを定期的に行います。

外形監視の強みは、ユーザーが感じる不調をそのまま捉えられることです。サーバーが生きていようがいまいが、「ユーザーから見て使えるか」を直接見るので、死活監視やリソース監視がすり抜ける障害も拾えます。一人運用なら、まずここを1本入れるだけで安心感が大きく変わります。

注意点は2つです。ひとつは、外形監視は「使えない」ことは分かっても「なぜ使えないか」までは分からないこと。原因の切り分けは、死活監視・リソース監視やログと組み合わせて行います。もうひとつは、監視そのものをシステムの外から行うのが理想なこと。監視を対象と同じサーバー内に置くと、そのサーバーごと落ちたときに監視も一緒に止まり、肝心なときに気づけません。

「外部から」というと有料の外部監視サービスを思い浮かべがちですが、契約のハードルや、VPN内・閉域の社内システムで外部監視を当てられない現場も多いはずです。外部サービスは理想ですが、無理なら別サーバー・別VPS・自宅回線・無料枠のcron＋curlでも構いません。要は「対象と運命を共にしない場所」から1本叩けていれば、目的は果たせます。どうしても外に出せない場合は、せめて同居を避けて別ホストから監視するだけでも効果はあります。

リソース監視：じわじわ進む枯渇を、手遅れになる前に

リソース監視は、サーバー内部の資源の残量と消費を見張る監視です。突然の停止よりも、「じわじわ進んで、ある日あふれる」タイプの問題に強いのが特徴です。

主に見るのは次のような指標です。

リソース監視の価値は、対応できる時間の余裕を作れることです。ディスクが90%になった段階で気づければ、満杯になる前に古いログを整理できます。これが「100%になってサービスが止まってから気づく」だと、対応はずっと苦しくなります。

ただし、ログが急増する現場では90%から100%まで数分ということもあります。増加スピードが速い環境では閾値を下げるか、使用率（%）だけでなく空き容量（GB）でも見ておくと、「閾値だけ真似して間に合わなかった」を防げます。自分の環境で1日にどれくらい増えるかを一度見ておくと、適切な余裕がつかめます。

注意点は、リソースに余裕があっても障害は起きること。アプリのバグ、外部APIの不調、設定ミスなどは、CPUもメモリも余っているのに発生します。だからリソース監視も万能ではなく、外形監視で「結果としてユーザーが困っていないか」を併せて見る必要があります。

突然の停止はまず外形監視が捉え、じわじわ進む枯渇はリソース監視が予兆として捉える、という障害タイプと監視の対応を示した図
障害には「突然」と「じわじわ」がある。種類が違えば、早く気づける監視も違う

最低限の監視設計：一人運用なら、この順で入れる

「3種類が大事なのは分かったが、全部いきなりは無理」。そのとおりです。一度に完璧を目指さず、効きの大きい順に足していきましょう。優先順位はこうです。

① 外形監視を1本（最優先）

まず、いちばん大事なURL（トップページや、サービスの中心になる画面）に対して、外部からの外形監視を1つ入れます。「ユーザーから見て使えるか」を直接見るこの1本が、いちばん致命的な見落とし——“落ちているのに気づかない”——を防ぎます。最初は200番台が返るかだけでも十分。慣れてきたら固定の見出し文字を1つ確認に足し、真っ白ページを正常と誤判定しないようにします。外部サービスが使えない環境なら、別サーバーや無料枠のcron＋curlでも構いません。

② リソース監視でディスクを1つ

次に、ディスク使用率の監視を入れます。一人運用でいちばん静かに・確実に事故るのがディスク満杯だからです。余裕を持った水準（例：85〜90%）で一度気づける形にしておきます。ログが急に増える環境なら閾値を下げるか、空き容量（GB）でも見ておくと安心です。メモリ・CPUはその後で十分です。

③ 死活監視で土台を固める

ここで、サーバーの ping／主要プロセスの死活監視を足します。外形監視が「使えない」を捉えたとき、「そもそもサーバーが落ちているのか、アプリだけの問題か」を切り分ける材料になります。①②があれば致命傷は防げているので、死活は土台の補強として落ち着いて足します。

④ リソース・外形を少しずつ厚くする

最後に、メモリ・コネクション数などのリソース、重要導線のシナリオ監視、応答時間の監視などを、負担にならない範囲で広げます。ここからは「あると安心」の領域。焦らず、自分の現場で実際に困った順に足すのが正解です。

この順番のポイントは、「ユーザー影響の大きさ」と「事故りやすさ」で並べていることです。きれいに3種類を揃えることより、まず痛い見落としから塞ぐ——それが一人運用の現実的な設計です。

あわせて決めておくと楽になること

監視の「種類」を整えるのと同時に、次の2点も軽く決めておくと、後がぐっと楽になります。

監視は「入れて終わり」ではなく、種類と鳴らし方の両輪で育てるもの。最初から完璧でなくていいので、片方ずつ整えていきましょう。

影響：3種類を意識すると、何が変わるか

監視を種類で整理できると、対応の速さ以上に、日々の「見えている安心」が変わります。

逆に、種類を意識しないまま「なんとなく入れた監視」だけだと、入れているのに肝心なときに気づけない——監視はあるのに守れていない状態に陥りがちです。

明日やること：自分の監視を3種類で棚卸しする

いきなり監視を作り込まなくて大丈夫です。明日できる、いちばん小さな一歩はこれです。

  1. 今ある監視を紙やメモに書き出し、それぞれ死活・外形・リソースのどれかを横に書く。
  2. 3種類のうち、1つも無いものがないかを確かめる。たいていは「外形監視が無い」か「ディスク監視が無い」のどちらか。
  3. 抜けていたら、まず外形監視を1本（中心になるURL1つ）入れられないか検討する。
  4. それも難しければ、ディスク使用率の監視を1つだけ足す。
  5. 監視を置く場所が「対象と同じサーバーの中だけ」になっていないか、1つだけ見直す。

全部できなくて大丈夫です。「自分の監視がどの種類に偏っているか」が見えただけで、もう設計は前に進んでいます。

「最低限の監視設計」チェックリスト

死角ができていないかを確かめる項目です。コピーして、自分の環境に当ててみてください。

まず最低ラインから。「外形監視1本＋ディスク監視1本」の2項目だけ先に○にできれば、まず合格です。残りの6項目は“余裕があれば”の任意枠なので、全部埋めなければと身構えなくて大丈夫です。

最低ライン（まずここだけ）

余裕があれば（任意枠）

全部に○が付かなくても大丈夫です。1つでも抜けていた種類を足せたら、それだけで監視の死角は確実に減っています。

よければ、こちらも

監視は、障害に気づくための入口です。気づいた後の動きや、鳴らし方の調整もあわせて1枚にしておくと、いざという時に落ち着けます。

整理された監視ダッシュボードを見ながら、自分が何を見ているか把握できて安心している保守運用の担当者

監視の種類が分からないまま不安だったのは、知識が足りないからではなく、体系立てて整理する機会がなかっただけです。死活・外形・リソース——「どこから・何を見るか」の3つさえ押さえれば、自分の監視の死角は自分で見つけられます。 今日は、今ある監視を3種類に仕分けるだけで十分です。その小さな一歩が、「入れているのに気づけない」から「見えているから落ち着ける」へと、少しずつ近づけてくれます。

ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。

関連用語