監視とは

監視とは

監視は稼働中のシステムから情報を継続して収集し、その結果に応じて適切な宛先に通知する仕組みです。サーバーが稼働しているか、画面が表示されるか、エラーが記録されていないかを一定の間隔で確認し、異常があれば担当者のメールや電話に通知します。

例えば受注サイトでは、外部の拠点から5分ごとに注文画面を表示し、2回連続で表示できなければ当番の担当者に電話で連絡します。同時にサーバーの稼働、ディスクの使用率、エラーの記録も確認しておくと、通知された担当者が原因の所在を推定できます。

目的は障害を利用者からの問合せより先に把握し、停止している時間を短縮することです。火災報知器と同じく、監視が担うのは異常の検知と通知までです。通知に対処する人と時間帯は、別に決定しておく必要があります。

攻撃の兆候を検知するセキュリティ監視は、非機能要求グレード2018でも稼働の監視とは別の要求項目で、攻撃の監視を専門に担うSOC（Security Operation Center）が担当することの多い領域です。

オブザーバビリティとも目的が異なります。監視が事前に設定した項目の異常を検知して通知するのに対し、オブザーバビリティは想定外の障害の原因を後から調査できるかを重視します。

障害を利用者からの問合せより先に検知する

監視がなければ、システムの停止は利用者からの問合せや担当者の確認で初めて把握することになり、発見が遅延しやすくなります。夜間に停止したシステムは、翌朝に担当者が画面を表示するか、利用者から連絡があるまで停止が継続します。受注サイトなら、その間の注文は処理されません。監視がない場合、停止の時間には停止を把握するまでの時間がそのまま加算されます。

SLAやSLOで稼働率の目標を定めても、停止した時間を計測する手段がなければ達成したかを判定できません。稼働率は全体の時間から停止の時間を減算し、全体の時間で除算して計算するため、監視の記録が算定の元になります。

確認する対象による4種類の監視

監視は確認する対象で次の4種類に分類できます。このうち稼働監視、リソース監視、ログのエラーを確認する監視には、IPAの非機能要求グレード2018で要求の水準が定められています。

種類	確認すること	検知できること	検知できないこと
稼働監視	サーバーやプロセスが稼働しているか	機器やソフトウェアの停止	稼働していても画面が表示されない状態
リソース監視	処理能力、メモリ、ディスク、通信量の使用率	容量不足などの停止の予兆	利用者への影響の有無
ログ監視	ログにエラーが記録されたか	障害が発生した機能と箇所	ログに記録されない不具合
外形監視	利用者と同じ操作が外部から成功するか	利用者の側で発生している停止と遅延	停止の予兆、原因の箇所

内部の状態を確認する稼働、リソース、ログの監視は、障害の予兆と原因の所在の把握に利用します。外部から利用者と同じ操作を試行する外形監視は、試行した操作の範囲で、利用者に影響が発生している問題を検知できる一方、まだ発生していない問題の予兆は検知できません。外形監視は操作の成否と同時に応答時間も記録できるため、停止していない段階の遅延も把握できます。

業務で利用するシステムでは、利用者への影響を通知する外形監視と、原因の所在を示す内部の監視の両方が必要です。

本番の環境で外形監視に注文や登録の操作をさせると、試験の記録が業務のデータに混入します。試験用のアカウントを使用し、売上や在庫の集計から除外できる識別子を設定します。

処理が実行されなかったことの検知

夜間のバッチ、取引先とのデータ連携、月末の締めの処理、バックアップは、失敗すればエラーを記録しますが、起動しなかった場合はエラーも記録されません。サーバーは稼働し、画面も表示されるため、4種類の監視ではいずれも正常と判定されます。

こうした処理は予定の時刻までに完了の記録がなければ異常とする仕組みで監視します。監視サービスには、一定の時間データの送信がないことを条件に通知する設定があります。非機能要求グレード2018では、バックアップやジョブの監視は、稼働やリソースの監視とは別のシステムレベルの監視に分類されます。

証明書とドメインの有効期限の超過も、期限を確認する設定がなければ、画面が表示されなくなるまで検知できません。外形監視の中には証明書の期限を計算するものがあり、期限の数週間前に通知する設定にしておくと、更新の手続きに必要な期間を確保できます。

監視の効果と運用の負担

効果

• 利用者からの問合せより先に停止を検知し、復旧の開始を前倒しできる
• ディスクの容量不足や処理の遅延を、停止する前に把握できる

費用と運用の負担

• 監視サービスの利用料が、監視する対象の数と確認の頻度に応じて増加する
• 構成を変更するたびに監視の設定の更新が必要になる
• 夜間と休日の当番には、待機の手当と交代の人員が必要になる
• 監視の仕組み自体が停止すると、障害が発生しても通知されない

2026年11月時点で、Amazon CloudWatchの外形監視は実行1回ごと、Google Cloudの外形監視は実行1,000回ごとに課金します。Mackerelはサーバー1台ごとの月額が基本です。回数で課金するサービスでは、確認の間隔を半分にすると利用料はほぼ倍になります。

利用料より負担が重くなりやすいのは人の工数です。サーバーや機能を追加するたびに監視の設定を更新する担当を決定しておかないと、追加した部分が監視の対象外のまま稼働します。

監視の仕組み自体の停止には、別の外部サービスから監視の稼働を確認するか、定時に送信する正常を知らせる通知の途絶を異常として処理するハートビート監視で備えます。

何をどこまで監視するか

外形監視と稼働監視から開始し、業務部門の責任者が決定した停止してよい時間が短い業務ほど、ログとリソースの監視を追加して計測の間隔を短縮します。

最初に監視する範囲

最初に監視するのは、利用者が利用する主要な操作の1〜3件程度と、その操作を処理するサーバーの稼働です。受注サイトなら、トップ画面の表示、ログイン、注文の確定の手前までの操作が対象です。夜間のバッチや取引先とのデータ連携がある場合は、その完了の記録と、証明書とドメインの期限も最初から対象に含めます。社内向けで翌営業日までに復旧すればよいシステムは、目安としてここまでで足ります。

停止してよい時間が数時間以内の業務では、ログのエラーとリソースの使用率も監視します。非機能要求グレード2018は、夜間でもすぐに対処が必要かを管理者が把握できるよう、詳細なエラー情報まで監視する水準を例示しています。通知の文面にエラーが発生した機能と内容が含まれていれば、担当者は自宅で対処の要否を決定できます。

計測の間隔

計測の間隔は、停止してよい時間より十分に短くします。数時間の停止が許容されない業務は1分から5分程度、翌営業日の復旧でよいシステムは数十分から数時間程度の間隔が目安です。間隔を短くするほど利用料と通知の数が増加します。GoogleのSREは、年間の稼働率99.9%を目標にするサービスでも、正常な応答の確認を1分に1〜2回より頻繁に行うのはおそらく不要としています。

監視を限定してよいシステム

試作や検証の環境、利用者が数名の社内ツールには、外形監視1件とメールの通知だけで十分です。夜間の通知も不要です。

監視の項目は削減もします。GoogleのSREは、ほとんど発報しない通知の設定を削除の候補にし、一部のチームは四半期に1回未満を目安にしています。

夜間・休日に誰が対応するか

業務部門の責任者が設定する、業務が停止してよい時間を基準に決定します。翌営業日まで停止してよい業務は、夜間の通知を記録だけにして朝に確認します。数時間以内に復旧が必要な業務は当番を決定して電話で連絡し、数十分以内なら24時間の有人の体制を用意します。

停止してよい時間	業務の例	夜間・休日の通知	体制
数十分以内	決済、受注、予約の受付	電話で即時に連絡し、応答がなければ次の担当者へ	24時間の当番、または運用事業者の有人の監視
数時間以内	取引先とのデータ連携、月末の締めの処理	業務が停止する異常だけ電話、他は朝に確認	2名以上による交代の当番
翌営業日まで	社内の情報共有、検証環境	通知せず、朝に一覧で確認	業務時間内の担当者

当番の応答の時間は、停止してよい時間から逆算します。四半期で稼働率99.99%を求めるシステムでは許容される停止は約13分しかなく、担当者は数分で対応を開始する必要があります。Googleでは、利用者が直接使うサービスで5分、時間の制約が緩いシステムで30分が典型的な応答の時間です。

夜間の当番は人数を前提にします。1名では休暇や体調不良のときに通知に対応する人がいなくなります。GoogleのSREは、主担当と副担当の2名で24時間の当番を1拠点で維持するには最低8名が必要としています。

待機の時間の扱いにも注意が必要です。厚生労働省のガイドラインは、指示があれば即時に業務に従事することを求められ、労働からの解放が保障されていない待機の時間を労働時間とするよう定めています。自宅での待機が該当するかは拘束の程度で異なるため、当番を開始する前に就業規則と手当を人事の担当と確認します。

通知に対応できる社員が2〜3名で、24時間の対応が必要な業務がある場合は、外部の有人の監視サービスに一次対応を委託し、社内の担当者は二次の担当にする構成が選択肢になります。有人の監視サービスは月額の固定費が発生し、対応の範囲で金額が異なります。通知を電話で転送するだけなら安価ですが、社内の担当者が毎回対処します。手順書に従った再起動まで委託すると金額は増加しますが、社内への連絡は手順で解消しない障害に限定されます。

同じ業務でも時間帯と日で求める水準は異なります。例えば月末の締めの日だけ夜間の当番を配置し、休日は翌営業日の確認にするなど、業務の予定表に従って区分すると、当番の負担を必要な日に集中できます。

通知を限定しないと誰も確認しなくなる

担当者に電話で連絡する通知は、即時の対処が必要で、人が状況を確認して対処を選択する異常に限定します。電話での連絡が頻繁になると、担当者は通知を流し読みしたり無視したりするようになり、本当の障害の通知を判別できなくなって停止が長期化します。

• 1回の失敗では通知せず、数分間の連続した失敗で通知する
• 同じ原因で複数の監視が同時に発報するときは、連絡を1件に集約する
• 担当者が何もせずに解消する通知は、閾値を再検討するか、朝の一覧に移動する
• 定型の手順で解消できる異常は、通知ではなく自動の再起動などで処理する

夜間の連絡が週に何度も発生する状態が継続するなら、通知の条件を緩和する前に、障害を反復するシステムの側の原因を是正します。当番の負担の上限として、Googleは12時間の当番で対応する障害を2件までとしています。

よくある誤解

クラウドを利用すれば自社のシステムも事業者が監視する

クラウドの事業者が監視するのは、事業者が提供する設備とサービスの稼働です。利用者が構築したアプリケーションや利用者が行った設定が正常に動作しているかまでは確認しません。アプリケーションが応答しているか、設定の誤りでエラーになっていないかは利用者が監視します。事業者の障害や計画停止の情報も自動で通知されるとは限らず、MicrosoftはAzureの障害と計画停止を通知する設定を利用者側で行うよう推奨しています。

監視ツールを導入すれば障害対応の体制ができる

監視ツールが担うのは、異常の検知と通知までです。通知を誰がどの時間帯に担当し、どの手順で復旧するかを決定していなければ、夜間の通知に誰も対応しません。ツールの導入と同時に、通知の宛先、当番の予定、復旧の手順書を用意します。