ITシステムの死活監視を導入・整備しようとするとき、「死活監視には、結局どんな機能が必要で、どこまでが標準的に備わっているべきなのか」という疑問にぶつかる情報システム担当者は少なくありません。死活監視と一口に言っても、単純なpingの応答確認だけのものから、サービスのHTTP応答やプロセスの生死、通知やエスカレーション、自動復旧まで担うものまで、機能の幅は大きく異なります。必要な機能を取りこぼすと、せっかく監視を入れても「止まっているのに気づけない」「気づいても誰も動かない」という事態に陥ります。
本記事は、ITシステム死活監視の必要機能・標準機能を、発注企業（情シス）の視点から「機能特化」で整理する解説です。死活そのものを判定する監視機能、検知を行動につなげる通知・エスカレーション機能、停止を分析・記録するレポート機能、そして自動復旧やAIOpsといった一歩進んだ機能まで、それぞれが何をしてくれるのかを具体的に掘り下げます。死活監視を委託・構築する際の機能チェックリストとしても使える内容です。死活監視の費用相場やSLAも含めた全体像をまだ把握していない方は、まずITシステム死活監視の完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・ITシステム死活監視の完全ガイド
死活を判定する監視機能の基本
死活監視の中核は、対象が「生きているか・死んでいるか」を判定する機能です。ただし、ひとくちに死活といっても、何をもって「生きている」とみなすかには複数のレベルがあります。サーバーが電源として応答するか、ネットワーク的に到達できるか、サービスとして正しく応答を返すか。このレベルの違いを理解することが、必要な監視機能を選ぶ出発点になります。
ping・ポート・プロセスを確認する基本機能
もっとも基本的な死活判定が、pingによる疎通確認です。対象サーバーへ一定間隔でICMPの問い合わせを送り、応答が返るかで生死を判断します。ただし、サーバー自体は応答しても、その上で動くサービスが止まっていることはよくあります。そこで、特定のポート（たとえばWebなら80番・443番、データベースなら指定のポート）が開いて応答するかを確認するポート監視や、特定のプロセスが起動し続けているかを見るプロセス監視が必要になります。
これらの基本機能で重要なのは「監視間隔」と「判定の閾値」です。1分間隔で監視し、何回連続で応答がなければ「停止」と判定するか、といった設定が死活監視の精度を左右します。間隔が長すぎると検知が遅れ、短すぎたり閾値が甘すぎたりすると一時的なネットワークの揺らぎで誤検知が増えます。標準的な死活監視では、これらping・ポート・プロセスの確認を、対象ごとに間隔・閾値を調整できることが最低限の要件になります。
HTTP応答・コンテンツを確認するサービス監視機能
サーバーやプロセスが生きていても、利用者から見て「サービスが使える」とは限りません。そこで重要になるのが、サービスレベルの死活監視です。Webサービスであれば、特定のURLにアクセスしてHTTPのステータスコードが200（正常）を返すか、ページ内に想定した文字列が含まれているか（コンテンツ監視）まで確認します。これにより、「サーバーは動いているがアプリケーションがエラー画面を返している」という状態も停止として検知できます。
さらに高度な機能として、ログインから検索、決済直前までの一連の操作を模擬的に実行し、ユーザー体験として正常かを確認する外形監視（合成監視）もあります。利用者と同じ目線で「本当に使えるか」を継続的に確かめる機能で、ECサイトのように停止が売上に直結するシステムでは特に有効です。死活監視の機能を選ぶときは、自社にとっての「生きている」が、サーバーの応答なのか、サービスの正常応答なのか、ユーザー体験の成立なのかを定義し、それに合う監視レベルを備えているかを確認することが大切です。
検知を行動に変える通知・エスカレーション機能
死活を検知しても、それが担当者に届かなければ意味がありません。死活監視のもう一つの柱が、検知を確実に人の行動へ変える通知・エスカレーション機能です。誰に・どの経路で・どんな順番で知らせるか。この設計の質が、停止に気づいてから対応を始めるまでの時間を決めます。
メール・チャット・電話など多経路の通知機能
標準的な死活監視では、検知時にメールやチャット（Slack・Teams等）へ自動で通知を飛ばす機能が備わっています。重要なのは、通知の経路を停止の重大度に応じて選べることです。軽微なものはチャットへ、業務に直結する重大停止は電話やSMSへ、というように経路を分けられると、本当に緊急なものだけが確実に担当者の目と耳に届きます。深夜帯にチャットだけでは気づけないため、電話通知の有無は委託・構築時に必ず確認したいポイントです。
また、通知に含める情報の質も機能差として現れます。「サーバーAが停止しました」だけでなく、いつから・どの監視項目で・直前の状態はどうだったか、といった一次切り分けに役立つ情報が通知に含まれていると、初動が速くなります。死活監視は「鳴らすこと」が目的ではなく「最短で正しく動いてもらうこと」が目的なので、通知の経路と中身の両方を機能として評価する視点が欠かせません。
多段階のエスカレーションと一次対応機能
通知が一人に届いても、その人が反応できなければ停止は放置されます。これを防ぐのがエスカレーション機能です。一次受けに通知して一定時間応答がなければ二次受けへ、それでも反応がなければ責任者へ、というように自動で連絡先を切り替えていきます。当番表（オンコール）と連動し、時間帯ごとに通知先を自動で切り替える機能を持つものもあります。これにより、特定個人への依存を避け、必ず誰かに届く状態をつくれます。
委託型のサービスでは、通知に加えて「一次対応」まで機能として提供されることがあります。リサーチでは、サーバー監視は1台あたり月3,000円程度、障害対応の一次対応を含めると1台あたり月10,000円程度、フルマネージドで月20,000円程度という料金例があります。また、SOC運用支援は月9万円程度から、重大インシデントに15分以内で一次対応を保証するサービスもあります。死活監視を委託する場合は、「検知だけなのか」「一次対応まで含むのか」を機能として明確に切り分けて契約することが、後の費用と責任のトラブルを防ぎます。
停止を記録・分析するレポート機能
死活監視は、その場の検知だけでなく「過去にどれだけ止まったか」を記録・分析する機能を持つことで、改善のサイクルを回せるようになります。停止の履歴がデータとして残れば、稼働率の実績やMTTR（平均復旧時間）を可視化でき、SLAの達成状況も客観的に評価できます。検知して終わりにせず、記録を経営や改善に活かす機能が標準で備わっているかを見ていきましょう。
稼働率・ダウンタイムを集計するレポート機能
標準的な死活監視には、月次や週次で稼働率・停止回数・停止時間を集計するレポート機能があります。これにより、「先月の稼働率は99.92%で、SLA目標の99.9%を満たした」というように、約束した水準を守れているかを定量的に示せます。稼働率99.9%は年間許容ダウンタイム8.76時間・月43.8分、99.99%は年52.6分・月4.38分という具体的な許容量があり、レポートはこの基準に対する実績を可視化してくれます。
このレポート機能は、SLAを契約している場合の達成証跡としても、社内への説明資料としても重要です。停止が起きたときに「なんとなく止まった」ではなく「今月は2回・合計18分停止し、稼働率は99.95%だった」と数字で語れることが、監視を投資として正当化する材料になります。死活監視を導入する際は、検知機能だけでなく、こうした稼働率・ダウンタイムの集計とレポート出力が標準で備わっているかを確認しておくと、後の運用がぐっと楽になります。
ダッシュボードで全体状態を俯瞰する機能
監視対象が増えてくると、個々のアラートだけでなく「いま全体としてどこが正常で、どこに問題があるか」を一目で把握できるダッシュボード機能が役立ちます。サーバーやサービスの一覧が緑・黄・赤といった状態色で表示され、異常箇所がすぐ分かる画面です。複数のシステムをまとめて見られることで、運用担当者の負荷が下がり、状況把握のスピードが上がります。
主要な監視ツールでは、こうしたダッシュボードが標準機能として提供されています。OSSのZabbixはライセンス無料で柔軟なダッシュボードを構築できますが、自社で構築・維持する工数がかかります。一方、Datadog・New Relic・Mackerelといったクラウド型はホスト数やメトリクス量に応じた従量課金で、中規模だと月数万〜数十万円が目安ですが、ダッシュボードや運用機能が最初から整っています。死活監視のレポート機能は、こうしたツールの選定とも密接に関わるため、自社が何をどこまで俯瞰したいかを基準に選ぶとよいでしょう。
自動復旧・AIOpsなど一歩進んだ機能
死活監視の機能は、検知・通知・記録の先に、停止を自動で復旧したり、異常の予兆を捉えたりする一歩進んだ領域へと広がっています。すべての企業に必要なわけではありませんが、運用負荷をさらに下げる機能として理解しておくと、将来の拡張を見据えた選択ができます。中小企業でも部分的に取り入れられるスモールスタートの観点も含めて見ていきます。
検知をトリガーに自動でアクションを実行する機能
一歩進んだ死活監視では、停止を検知したらあらかじめ定めた処理を自動で実行する機能があります。たとえば、特定のプロセスが落ちたら自動で再起動を試みる、サービスが応答しなくなったらフェイルオーバー（待機系への切り替え）を実行する、といった対応です。これにより、人が動く前に軽微な障害が自動で復旧し、夜間でも一次対応の手数を減らせます。
ただし、自動復旧は万能ではありません。根本原因が解消されていないまま再起動を繰り返すと、問題を覆い隠してしまう危険もあります。したがって、自動復旧を導入する場合も「自動で復旧を試みた事実は必ず通知し、記録する」という設計が前提になります。検知・通知・記録という基本機能の上に自動復旧を載せる、という順序を守ることが、機能を安全に使ううえで重要です。自社のシステムのどこに自動復旧が向くかを見極め、まずは影響の小さい範囲から試すのが堅実です。
AIOpsによる予兆検知と中小のスモールスタート
近年注目されるのが、AIを活用して異常の予兆を捉えたり、大量のアラートを束ねて本当に重要なものを抽出したりするAIOpsです。死活監視のログやメトリクスをAIが学習し、「いつもと違う挙動」を検知して停止に至る前に知らせる、といった機能が期待されています。ただし、JUASの調査ではAI活用について約78%が「検討中・未検討」とされており、多くの企業にとってはまだこれからの領域です。
中小企業にとって現実的なのは、いきなり全面的なAIOpsを目指すのではなく、まず死活監視の基本機能を固め、そこに溜まったデータを土台に部分的なAI活用へ広げていくスモールスタートです。レガシーなシステムを維持しつつ、影響の大きい一部のサービスから予兆検知を試し、ROIを確認しながら範囲を広げる。riplaはフルスクラッチ受託と国内運用保守の立場から、こうした「いまある監視を活かしながら段階的に高度化する」進め方を重視しています。死活監視の機能は、必要十分から始めて育てていくものだと捉えるのがよいでしょう。
まとめ
ITシステム死活監視の機能は、(1)ping・ポート・プロセス・HTTP応答で死活を判定する監視機能、(2)多経路の通知とエスカレーションで検知を行動に変える機能、(3)稼働率・ダウンタイムを集計しダッシュボードで俯瞰するレポート機能、(4)自動復旧やAIOpsといった一歩進んだ機能、という4つの層で整理できます。標準として最低限備えるべきは(1)〜(3)であり、(4)は自社の規模と必要性に応じて段階的に取り入れる領域です。
機能を選ぶときに大切なのは、流行のキーワードに飛びつくことではなく、自社にとっての「生きている」の定義と、停止時に「誰がどう動くか」を起点に必要機能を逆算することです。稼働率99.9%か99.99%かといったSLAの目標に対し、検知・通知・記録の機能がその水準を支えられるかを確認してください。riplaはフルスクラッチ受託と国内運用保守を組み合わせ、自社のシステムに必要十分な死活監視機能の設計から運用までを一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。