システム監視とは？監視項目の種類と死活監視・性能監視の違いを発注者視点で解説

システム監視とは、サーバーやネットワーク、アプリケーションが正常に動いているかを継続的に確認し、異常の兆候を検知した時点で担当者へ通知する仕組みです。監視が甘いと、障害の発覚は利用者からのクレーム経由になり、復旧は後手に回ります。この記事で扱うのは、監視の目的とインフラ監視・サービス監視の区分、死活監視や性能監視をはじめとする主要な監視項目、監視ツールの選び方、そして情シス・発注者が判断に迷う「内製と外注（MSP）の分岐点」です。オブザーバビリティとの違いや費用の目安も具体的に示します。

まとめ：システム監視の目的と監視項目・内製外注判断の要点整理

システム監視の目的は、障害を利用者より先に見つけて復旧時間を縮めることに尽きます。監視の対象はハードウェアやネットワークを見る「インフラ監視」と、アプリの応答やエラーを見る「サービス監視」の2系統に分かれ、実務ではこの両輪を組み合わせます。押さえるべき監視項目は死活監視・性能監視（リソース監視）・ログ監視・ポート監視・外形監視の5つが基本線です。

ツールを入れれば終わりではありません。通知が多すぎれば現場は警報を無視し、少なすぎれば障害を見逃します。しきい値と通知先の設計まで詰めて、監視ははじめて機能するものです。監視業務を自社で回すか、MSPへ委託するかは、24時間365日の当番を組めるか、監視対象の規模がどれくらいか、で分かれます。年中無休の一次対応を内製で維持できないなら外注が現実的です。監視はシステム運用の一部であり、より広い運用・保守の全体像はシステム運用とは何かを解説した記事で確認できます。

システム監視が担う目的とインフラ監視・サービス監視の対象範囲

監視は「見ること」自体が目的ではなく、異常を早く捉えて被害を小さくするための手段です。まずは何のために監視するのか、そして何を対象にするのかを分けて整理します。

障害の予兆検知と平均復旧時間の短縮につながるシステム監視の役割

監視の価値は2つの時間で測れます。1つは障害を検知するまでの時間、もう1つは復旧までの時間です。CPU使用率が数分間90%を超え続けている、ディスクの空きが残り5%を切った——こうした予兆を監視がつかめば、サーバーがダウンする前に手を打てます。検知から復旧までの平均時間はMTTR（平均修復時間）と呼ばれ、監視はこのMTTRを縮めるための最初の一手です。逆に監視が無いと、利用者からの「画面が開かない」という連絡が第一報になりかねません。原因の切り分けにも時間がかかります。稼働率をどこまで担保するかという目標設定は、SLA・SLO・SLIの違いと稼働率の決め方を解説した記事が実装の観点から参考になります。

ハードウェアを見るインフラ監視とアプリを見るサービス監視の違い

監視対象は大きく2層に分かれます。土台を見るのがインフラ監視です。サーバーのCPUやメモリ、ネットワーク機器の疎通、ディスク容量といったハードウェア寄りの状態を対象にします。その上で動くWebアプリやAPIが正しい応答を返すか、レスポンスが遅くなっていないかを見るのがサービス監視（アプリケーション監視）です。ここを混同すると穴が空きます。サーバー自体は生きていてもアプリだけが500エラーを返している、という障害はインフラ監視だけでは検知できません。逆にアプリの応答が速くても、裏でディスクが逼迫していれば数日後に止まります。実務では両者を組み合わせ、土台とサービスの双方から異常を拾う構成にします。

主要な監視項目5種類と死活監視・性能監視・ログ監視の確認内容

「監視項目をどこまで設定するか」は発注時に必ず論点になります。まずは基本となる5種類を、それぞれ何を確かめる項目なのかとあわせて押さえましょう。優先度は死活監視と性能監視が先で、そのうえでログ・ポート・外形を足していきます。

この5つを土台に、監視対象システムの性質へ合わせて項目を足し引きします。

死活監視とPing・ICMPで稼働の有無を確かめる最小構成の監視

死活監視は、対象が生きているか死んでいるかだけを判定する最小限の監視です。手段としてはpingコマンド（ICMP）で応答が返るかを一定間隔で確認する方式が代表的で、応答が途切れた時点でアラートを出します。実装が軽く負荷も小さいため、まず全機器に敷く土台になります。ただし死活監視は「電源が入っている」ことしか保証しません。サーバーは応答していてもアプリが固まっている状態は捕捉できないため、これ単体では不十分です。監視の第一歩として全台に入れつつ、次に挙げる性能監視やサービス監視を重ねる前提で使います。

CPU・メモリ・ディスクのしきい値で設計する性能監視の判断基準

性能監視はリソース監視とも呼ばれ、CPU使用率・メモリ使用量・ディスク空き容量・ネットワーク帯域といった数値を継続的に取得します。取得にはSNMPや監視エージェントを使い、値を時系列のグラフで残します。肝はしきい値の置き方です。CPU使用率を一瞬80%超えただけで通知していては警報が鳴りやみません。「5分平均で85%を超えたら警告、95%を超えたら緊急」のように、継続時間と段階を組み合わせて設計します。ディスクは特に見落としが多く、残量が一定を切ったら早めに通知する運用にしておくと、深夜にログで埋まってサービスが止まる事故を防げます。

ログ監視・ポート監視・外形監視という異常の種類別の検知の手法

残る3項目は、拾える異常の種類が違います。ログ監視は各サーバーが出力するログを収集し、あらかじめ決めた文字列（例：ERRORや特定の例外名）が現れたら通知する仕組みです。アプリ内部で起きた異常を捉えるのに向きます。ポート監視は、Webなら443番といった特定ポートへ接続を試み、応答の有無でサービスの生死を判定します。外形監視は、監視対象の外部拠点から実際の利用者と同じようにアクセスし、ページが開くか・何秒で開くかを測る方式です。社内からは正常でも、外部のDNSやロードバランサ経由では落ちている、という障害を捉えられるのが外形監視の強みです。

監視ツールの3類型とアラート設計で通知過多を防ぐ運用の選定基準

監視項目が決まったら、それを実装するツールと通知の設計に移ります。ツール選定そのものより、通知をどう絞るかで運用の質が決まります。

エージェント型・エージェントレス型・SaaS型ツールの使い分け

監視ツールは実装方式で3つに分かれます。1つ目のエージェント型（Zabbix系やDatadogのエージェント等）は、各サーバーに常駐プログラムを入れる方式です。詳細なメトリクスを細かく取れる反面、導入と保守の手間がかかります。2つ目のエージェントレス型はSNMPやSSH経由で外から状態を取りにいき、監視対象へソフトを入れられない機器に向いています。3つ目のSaaS型（Datadog・Mackerel・New Relic等のクラウド提供）は、監視基盤の構築と維持を提供側へ任せられる形です。立ち上げが速い一方、月額課金が監視対象数やデータ量で増えていきます。小規模なら無償のZabbix系やPrometheus系で始め、対人運用の負荷が上がってきたらSaaS型へ寄せる、という順序が現実的です。

通知過多と検知漏れを同時に避けるアラートしきい値と通知先の設計

監視が失敗する典型は、アラートを鳴らしすぎて現場が慣れてしまうパターンです。全項目を同じ強さで通知すると、1日に何十通も警報が届き、本当に緊急のものが埋もれます。ここは立場を取って言い切ります。通知は「緊急（即対応）」と「警告（翌営業日で可）」の2段階に分け、緊急だけを電話やチャットの即時通知へ、警告はメールやダッシュボードへ回すべきです。全部を緊急扱いにする設計は、検知漏れと同じくらい危険な失敗パターンだと考えてください。あわせて、誰に届くのか（通知先とエスカレーション順）を先に決めておかないと、深夜のアラートが宛先不明で放置されます。しきい値・段階・通知先の3点を最初に設計することが、鳴りっぱなしを防ぐ近道です。

システム監視の内製と外注を分ける損益分岐とオブザーバビリティの違い

最後は発注者がもっとも悩む論点です。監視を自社で回すのか、専門事業者へ委ねるのか。判断軸を条件付きで示したうえで、監視の一歩先にある「オブザーバビリティ」との線引きにも触れます。

内製が向く条件と外注（MSP）が向く条件を分ける判断の分岐点

分岐点は「24時間365日の一次対応を、無理なく維持できるか」です。監視ツールを入れること自体は難しくありません。問題は、深夜や休日にアラートが鳴ったとき、誰が起きて対応するかです。当番を組める人数（最低でも交代要員を含め数名）を確保できず、夜間対応が特定の担当者へ依存しているなら、その体制は長く続きません。監視対象が数台で日中のみ稼働ならば内製で十分ですが、24時間動く基幹システムや、監視対象が数十台規模に広がるなら、監視・一次対応を専門とするMSPへの委託が現実的です。委託先の役割やSIerとの違いはMSPとは何かを発注者視点で整理した記事にまとめています。監視設計から構築、24時間の運用までを外部へ任せたい場合は、保守運用・内製化支援のサービスで体制づくりから相談できます。

オブザーバビリティとの違いと監視で足りる範囲・足りない範囲の線引き

監視（モニタリング）とオブザーバビリティは近い言葉ですが、答えられる問いが違います。監視は「あらかじめ決めた項目が正常か」を見る仕組みで、CPUやポートのように何を見るかを先に決めておくものです。マイクロサービスのように構成が複雑で、障害の原因が事前に想定しきれないシステムでは、監視だけでは「なぜ遅いのか」に答えられません。オブザーバビリティは、メトリクス・ログ・トレースを突き合わせ、想定外の原因を後から探れる状態を指します。線引きはこうです。単一サーバーや構成が固定的なシステムなら、5項目の監視で足ります。サービスが多数連携し、障害箇所の特定が難しい構成になってきたら、オブザーバビリティの導入を検討する段階です。まずは監視から始め、複雑化に応じて拡張するのが妥当な順序で、保守全体の位置づけはシステム保守とは何かを解説した記事で俯瞰できます。

よくある質問

システム監視の導入や委託を検討する担当者から寄せられることの多い質問をまとめます。

システム監視とネットワーク監視・サーバー監視の違いは何ですか？

ネットワーク監視やサーバー監視は、システム監視の一部です。システム監視という総称の中で、ネットワーク機器の疎通を見るのがネットワーク監視、サーバーのCPUやディスクを見るのがサーバー監視にあたります。実務ではこれらにアプリの応答を見るサービス監視を加え、土台からサービスまでを一体で監視する構成が一般的です。個別の呼び名にとらわれず、何を見たいかで項目を選ぶと整理しやすくなります。

監視項目はどこまで設定すればよいですか？

全機器に死活監視を敷き、稼働の要となるサーバーへ性能監視（CPU・メモリ・ディスク）を加えるところが最初の基準です。そのうえで、アプリの異常を拾うログ監視、利用者視点の到達性を測る外形監視を、システムの重要度に応じて足します。すべてを最大限に設定するとアラートが増えすぎて運用が回らなくなるため、止まって困る順に優先度をつけ、必要な項目から段階的に広げる進め方が実務的です。

死活監視だけでシステム監視は十分ですか？

死活監視だけでは不十分です。死活監視はPingで応答があるかを見るだけで、「サーバーは生きているがアプリが固まっている」「ディスクが逼迫して数日後に止まる」といった状態は捉えられません。最低でも性能監視を加え、CPUやディスクの負荷を継続的に見る構成にします。死活監視は全台に敷く土台として使い、そこへ性能監視・ログ監視を重ねる前提で設計してください。

無料の監視ツールでも実務で問題ありませんか？

小〜中規模であれば、Zabbix系やPrometheus系といった無償のツールで実務に耐えます。無料ツールの費用はソフト代ではなく、構築と保守にかかる人件費に置き換わる点に注意が必要です。監視対象が増えて設計や保守の負荷が上がってきたら、監視基盤の維持を提供側へ任せられるSaaS型（Datadog・Mackerel等）へ切り替える判断が出てきます。ツールの無償・有償ではなく、自社で監視基盤を保守し続けられるかで選ぶのが妥当です。

システム監視は外注できますか？費用の目安はどのくらいですか？

監視の設計・構築から24時間の一次対応まで、MSP（マネージドサービスプロバイダー）へ外注できます。費用は監視対象の台数、監視項目の数、対応時間（平日日中のみか24時間365日か）で変わり、24時間の有人監視を含むほど高くなります。正確な金額は構成に依存するため、監視対象と求める対応時間を整理したうえで見積もりを取るのが確実です。体制設計から相談したい場合は、保守運用・内製化支援のサービスへ問い合わせるところから始められます。

関連記事

• システム運用とは？保守との違い・業務一覧から委託判断まで発注者視点で解説：監視を含む運用業務の全体像と委託の判断軸を整理しています。
• システム保守とは？運用との違い・費用相場・契約形態を発注者視点で解説：監視・運用を含む保守全体の位置づけと費用感を確認できます。
• MSPとは？マネージドサービスプロバイダーの役割・SIerとの違いと委託判断を発注者視点で解説：監視・一次対応を外注する際の委託先の選び方を解説しています。
• SLAとは？SLO・SLIとの違いと稼働率の決め方・監視実装をエンジニア視点で解説：監視で担保する稼働率の目標設定と実装の観点を扱っています。