JP2006011888A

JP2006011888A - 遠隔管理システム

Info

Publication number: JP2006011888A
Application number: JP2004189105A
Authority: JP
Inventors: Yukio Ogawa; 祐紀雄小川; Tomokazu Ebata; 智一江端; Eiji Ohira; 栄二大平
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2004-06-28
Filing date: 2004-06-28
Publication date: 2006-01-12
Also published as: CN1716874A; US20050286435A1; CN100349414C

Abstract

【課題】
管理対象装置と管理装置がネットワークを介して接続された環境で、管理装置が管理対象装置において発生したイベントの対策を行うにあたり、管理対象装置側のファイアウォールの設定変更や管理対象装置のアドレスの把握を必要とせず、管理対象装置が増加した場合でも管理装置に設定を追加する必要のないスケーラブルな管理を可能にすること。
【解決手段】
管理対象装置と管理装置がネットワークを介して接続された環境で、管理対象装置に発生する事象を、複数の管理対象装置に適応可能なイベント体系で管理し、管理対象装置に設置した管理モジュール121は、管理装置100にイベント識別子500と付属情報800を送信し、受付番号700とイベント識別子500に対応した対策情報601を受信し、対策実施後、管理装置100に受付番号700と対策完了情報801通知を送信すること。
【選択図】図８

Description

本発明は、インターネット等のネットワークを経由して遠隔から機器の監視、情報収集、情報分析、情報提供を行う技術に関する。

管理を受ける装置（以下管理対象装置という）と管理を行う装置（以下管理装置という）がインターネット等のネットワークに接続された環境において、管理対象装置に発生した障害等のイベントに対して、管理装置が遠隔から対策を実施するときに、管理対象装置は管理装置にイベント通知を送信し、その後、管理装置は、管理対象装置に問い合わせを行って情報を収集し、イベント対策情報を提供するといった手法がとられていた。

上記手法では、管理装置は、管理対象装置にネットワーク経由で通信を行うため、管理対象装置のアドレスを把握していなければならなかった。また、管理装置が管理対象装置側にファイアウォールが設置されている場合は、通過させるための設定変更を必要とした。

これに対し、たとえば特許文献１に記載の遠隔管理システムは、管理対象装置側のファイアウォールの設定変更をすること無く、管理対象装置のアドレスが不明であっても、インターネット等のネットワーク経由で管理装置から管理対象装置に情報を提供する方法を実現しようとしている。

具体的には、管理対象装置に配置した上記管理モジュールが、HTTP（HyperText Transfer Protocol）等のリクエストとレスポンスが対になった通信プロトコルを利用し、XML（Extensible Markup Language）等のデータ形式にて、種類、名称、製造業者、型名、シリアル番号やUUID（Universally Unique IDentifier）等の、上記管理対象装置を他の同一の管理対象装置から区別できる識別情報を上記管理装置に通知する。通知を受けた上記管理装置では上記識別情報に特定の情報を検索し、通知へのレスポンスを利用して上記管理モジュールに送信する。

また、非特許文献１に記載の通信プロトコルでは、ファイアウォールの設定を変更すること無くインターネット経由で管理装置と管理対象装置との間でデータアクセスを行う仕組みを規定している。

具体的には、管理対象装置は、HTTP等を下位プロトコルとしてXML形式のメッセージを管理装置に送信し、管理装置のデータへアクセスし、その結果得られた情報を取得している。

特表2004-510231号公報 Don Box、外７名、"Simple Object Access Protocol (SOAP) 1.1"、［online］、2000年5月8日、World Wide Web Consortium、［2004 年4 月20日検索］、インターネット＜URL：http://www.w3.org/TR/2000/NOTE-SOAP-20000508/＞

従来の遠隔管理システムでは、管理装置は、上記管理対象装置を他の同一の管理対象装置と区別するために、種類、名称、製造業者、型名、シリアル番号、UUID等の上記識別情報を受信し、上記識別情報をキーとして上記管理対象装置に特定の情報を検索している。従って、上記管理装置においては、上記管理対象装置が増加する度に、上記管理対象装置に関する特定の情報を追加する等の設定追加を行う必要があり、管理対象装置数の規模に比例した工数が必要である。

また、従来の管理装置は、管理対象装置から通知を受けた場合に、オペレータが介在して対話式で情報を提供する仕組みを持たないので、管理対象装置に予期せぬ事態が発生したときの対応に課題があった。

本発明は、管理対象装置側のファイアウォールの設定変更や管理対象装置のアドレスの把握を必要とせず、さらに、管理対象装置が増加した場合でも管理装置に設定を追加する必要のないスケーラブルな遠隔管理システムを提供する。

また、管理装置が、管理対象装置から通知を受けた場合に、オペレータの介在により対話形式で情報を提供できる遠隔管理システムを提供する。

具体的には、本発明は、その一態様において、ネットワークを介して接続された管理対象装置と管理装置を備えた遠隔管理システムであって、管理対象装置に発生する事象を、複数の管理対象装置に適応可能なイベント体系で管理する。

上記管理対象装置は管理モジュールを備え、上記管理モジュールは、上記管理対象装置に発生したイベントを検知する手段と、イベント問い合わせ先テーブルから上記イベントに対応した一つ以上の問い合わせ先を検索する手段と、上記イベント問い合わせ先テーブルにおいて上記イベントの識別子に対応した一つ以上の問い合わせ先が定義されていない場合の問合せ先を割り当てる手段と、上記管理装置に上記イベントの識別子を送信して問い合わせを行う手段と、上記一つ以上の問い合わせ先に対して同時に、あるいは、連続的に問い合わせを行う手段を備える。

上記管理装置は、上記管理モジュールの問い合わせを受信する手段と、上記イベントを受け付ける手段と、イベント状態管理テーブルを用いて上記イベントの処理状態を管理する手段と、イベント対策情報テーブルから上記イベント識別子に対応した対策情報を検索する手段と、上記イベント対策情報テーブルから上記管理モジュールの問い合わせ条件に応じた対策情報を検索する手段と、上記イベント対策情報テーブルにおいて上記イベント識別子に対応した対策情報が登録されていない場合の対策情報を割り当てる手段と、上記イベント対策情報テーブルにおいて上記イベント識別子に対応した対策情報が登録されていない場合にオペレータ呼び出しという対策情報を割り当てる手段と、イベント受付番号および上記対策情報を上記管理モジュールに送信する手段を備える。

さらに、上記管理モジュールは、上記対策情報を提供されるまで上記管理装置に問い合わせを繰り返す手段と、問い合わせの繰り返し時に上記管理装置に情報を追加して提供する手段と、上記管理装置から受信した上記対策情報を実施する手段と、上記管理装置に上記イベントの対策が完了したことを通知する手段を備える。

さらに、上記管理装置は、上記管理モジュールからイベント対策完了通知を受け付ける手段を備える。

さらに、上記管理モジュールは、上記管理装置から問い合わせに対する応答を得られなかった場合や、上記管理装置から上記対策情報を提供されなかった場合や、上記管理装置からイベント対策完了通知に対する応答を得られなかった場合に、上記管理対象装置の管理者に通知する手段と、上記管理装置から受信した対策情報を上記管理対象装置の管理者に通知する手段を備えることにより、上記管理装置が上記管理対象装置のハードウェア、ソフトウェアの管理を行う構成とする。

上記態様の遠隔管理システムによれば、管理対象装置側のファイアウォールの設定変更や管理対象装置のアドレスの把握を必要とせず、管理対象装置が増加した場合でも管理装置に設定を追加する必要のない、簡易でスケーラブルな遠隔管理が可能になる。

また、上記管理対象装置は、一つ以上の管理装置からイベント対策情報を取得でき、管理装置側は、一つ以上の管理装置により管理対象装置の管理を分担、あるいは、協調して実施することが可能になる。

また、上記管理装置は、上記管理対象装置からの問い合わせ条件に応じて提供する対策情報を変更することができ、上記管理対象装置の状況に応じた対策情報の提供が可能になる。

さらに、上記管理装置は、オペレータが介在して対話的に上記管理対象装置と情報交換を行うことにより、上記管理対象装置に予期せぬイベントが発生したとき等でも、イベント対策を確実に実施することができる。

本発明によれば、簡易でスケーラブルな遠隔管理が可能な遠隔管理システムを実現することができる。

以下、本発明の実施の形態を、図面を用いて詳しく説明する。以下の説明は、本発明の技術的範囲を限定するものではない。以下の説明において、同一の機能を有する構成要素には同一の番号を付している。また、同一の機能を有する構成要素が、同一の装置によって繰り返し実施されたり、異なる装置によって実施されたりして、区別が不明瞭な場合は、番号の後ろに括弧で識別番号を追加している。

図1は、本発明の実施形態に係る遠隔管理システムにおける全体構成を示す図である。ネットワーク110を介して、管理装置100と、管理対象装置120および同様の管理対象装置132が接続されている。

ネットワーク110は、インターネットやイントラネットワークである。ネットワーク110がインターネットである場合などに、管理対象装置120とネットワーク110との境界にファイアウォール122が、管理対象装置132とネットワーク110の境界にファイアウォール133が、管理装置100とネットワーク110の境界にファイアウォール107が設置されていてもよい。

管理装置100側において、管理対象装置120や管理対象装置132からの通信の優先制御を行う場合は、ネットワーク100との境界に優先制御装置108を設置する。また、管理装置100側において、管理対象装置120や管理対象装置132からの通信の認証を行う場合は、ネットワーク100との境界に認証装置109を設置する。

管理装置100は、パーソナルコンピュータやサーバ装置といった一般的な情報処理装置であり、CPU（Central Processing Unit）101、メモリ102、ハードディスク103、通信インタフェース104、キーボード105、ディスプレイ106等から構成される。管理装置100では、オペレーティングシステムの制御によりCPU101がハードディスク103からメモリ102上にプログラムを呼び出して実行することにより以下に説明する各機能を実現する。

管理対象装置120、管理対象装置132、管理対象装置132と同じ場所に設置され管理対象装置132の監視を行う監視装置130も、管理装置100と同様の情報処理装置である。

管理対象装置120、132について補足する。本実施形態では、管理対象装置120、132が、管理装置100にメッセージを送信することを契機として、これらが相互にメッセージを交換する。

従って、本実施形態では、管理対象装置120、132側にファイアウォール122、133等が設置されているため、管理装置100が、直接、管理対象装置120、132にアクセスできない場合や、管理対象装置120、132のアドレスが不明、または、刻々と変化するため、管理装置100が、管理対象装置120、132にアクセスできない場合にも対応可能である。

前者における管理対象装置120、132の例としては、上記で述べた通常のパーソナルコンピュータやサーバ装置の他、プリンター、コピー機、情報家電等がある。後者における管理対象装置120、132の例としては、ネットワークに接続可能な車両や携帯電話等の移動体がある。

管理対象装置120上に実現される管理モジュール121は、管理装置100と通信を行い、管理対象装置120の管理を行う。管理モジュール121は、通常のプログラムとしてハードディスクに格納され、CPU101によりメモリ上で実行されてもよい。あるいは、組み込みデバイスに格納されていてもよい。

監視装置130に備えられた管理モジュール131は、管理装置100と通信を行い、ネットワーク経由で管理対象装置132の管理を行う機能である。管理モジュール121と管理モジュール131は、配置位置は異なるが同等の機能を有する。以下の説明では、管理モジュール121による処理を例として説明しているが、管理モジュール131による処理も同様である。

以下、図2に示す管理モジュール121の処理フローや、図3および図4に示す管理装置100の処理フローと、図8から図13に示す管理モジュール121と管理装置100のメッセージ交換シーケンスを対応付けながら、管理対象装置120に発生したイベントの処理について説明する。

まず、図8を参照し、管理モジュール121が、管理装置100と基本的なメッセージ交換を行いイベント対策を実施する場合を、時間軸に沿って説明する。

（イベント検知201）において、管理モジュール121は、管理対象装置120においてイベントが発生したこと検知する。

イベントとは、管理対象装置120のCPU、メモリ、ハードディスク、あるいは、アプリケーションといったハードウェアやソフトウェアに関して、それらの構成や性能に関する数値が、ある設定値を超えたり、特定の動作を行ったりしたことを示すエラーや警告等のことである。イベントは、管理対象装置120だけでなく、管理モジュール121自身のハードウェアやソフトウェアの構成、性能に関連して発生させてもよい。また、イベントは、不定期ではなく、定時通報のように周期的に発生するものであってもよい。

イベントは、それを一意に識別できる番号等のイベント識別子で管理する。イベント識別子は、管理対象装置120に発生するイベント毎に定めることとし、MIB（Management Information Base）やCIM（Common Information Model）等の標準的な情報管理体系や、複数の管理対象装置に共通なハードウェアやソフトウェアの情報管理体系に基づいて定める。これにより、管理対象装置が異なる場合でも、同一のイベントに対して、同一の識別子が割り当てられるので、イベント対策を均一にできる。

また、標準的な情報管理体系や共通の情報管理体系に当てはまらないようなイベントや、一つの管理対象装置120にだけ固有であるイベントについては、それぞれに固有のイベント識別子を割り当ててもよいが、以下では「その他（default）」というイベント識別子によって一律に管理する方法を説明する。

（問い合わせ先検索202）において、管理モジュール121は、図5に示すイベント問い合わせ先テーブルを検索しイベント識別子500に対応した問い合わせ先501を検索する。問い合わせ先501は、通常は、"http://center.com/server"521や"http://center.com/storage"522といったアドレスで示す外部の管理装置100であるが、"http://localhost/event"520のように管理対象装置120や管理モジュール121自身であってもよい。この場合は、管理対象装置120や管理モジュール121自身に、後述する管理装置100と同様のイベント対策情報が格納しておく。

問い合わせ先501には、複数の宛先が登録されていてもよい。複数の宛先の実体は、通常は異なる管理装置100であるが、同一の管理装置100であってもよい。"http://center1.com/server OR http://center2.com/server"523は、予備の宛先を示す例であるが、詳細は、（応答受信205）の説明時に述べる。"http://center.com/storage AND http://center.com/network"524は、同時に複数の宛先を示す例であるが、詳細は、図11の説明時に述べる。"http://center.com/server, http://center.com/staff"525は、連続した複数の宛先を示す例であるが、詳細は図12の説明時に述べる。

発生したイベントに対して該当するイベント識別子500が検索されない場合は、「その他」のイベントの識別子である"default"530を利用する。イベント識別子500の"default"530には、検知したイベントに対してイベント識別子が定義されていない場合の問い合わせ先を定める。これによって、標準的な情報管理体系や共通の情報管理体系に当てはまらないようなイベントに対しても問い合わせ先501を定め、対応することができるようになる。

さらに、それぞれのイベント識別子500に対して、処理優先度502を定め、複数イベントが同時に起こったときの処理の優先度を定義してもよい。

なお、図5では、通信プロトコルにHTTPを利用することを例としているため、問い合わせ先501に"http://"を記しているが、HTTPSを利用する場合であれば"https://"のように、利用する通信プロトコルに適した形式で問い合わせ先を登録すればよい。

（問い合わせ送信203）において、管理モジュール121は、検索された問い合わせ先501である管理装置100に対して、イベントに関する問い合わせを行う。

管理モジュール121と管理装置100との間の通信プロトコルは、送信と受信が対になった通信プロトコルであれば、どのようなプロトコルでもよい。管理モジュール121側にファイアウォール122が設置されている場合でも、外部への通過を許可されているHTTPやSOAPを通信プロトコルに利用した場合は、ファイアウォール122に特別な設定を行う必要はない。

送信内容は、管理対象装置120に発生したイベントの識別子500、および、それに付随する付属情報800である。送信内容は、管理モジュール121と管理装置100の両者が解釈可能なXML等の任意の形式で記述すればよい。以下、管理モジュール121と管理装置100の間で送受信するメッセージの書式は、この形式とする。

付属情報800は、イベントの優先度502や、イベント発生時刻、イベント発生に関連するハードウェアやソフトウェアの名称、型名、製造番号、あるいは、イベントログ、管理対象装置120の設置場所、管理者等、イベントの処理に必要な任意の情報である。

（問い合わせ受信301）において、管理装置100は、管理モジュール121から、管理対象装置120に発生したイベントに関する問い合わせを受信する。

管理装置100が問い合わせを受信する前に、優先制御装置108が、問い合わせメッセージの送信先アドレスや送信元アドレス、あるいは、問い合わせ先501、付属情報800に含まれるイベントの優先度502等の情報を識別して、優先制御処理を行ってもよい。具体的には、優先制御装置108が、複数の問い合わせメッセージを同時に受信した場合に、高優先度のメッセージから管理装置100に転送を行う。

また、認証装置109が、問い合わせメッセージに追加されたユーザ名称やパスワード、証明書等の認証情報、あるいは、付属情報800に含まれるユーザ名称やパスワード、証明書等の認証情報を用いて、イベントメッセージの認証を行ってもよい。

（イベント受け付け303）において、管理装置100は、イベントを受け付け、問い合わせメッセージを解析して、受付番号を持っているかどうかを調べる。受付番号を持っている場合は、既に受付済みのイベントであると判断する。

受付番号がない場合は、新規受け付けであると判断して、問い合わせを受けたイベントを一意に識別できる番号や識別子を新たに受付番号に割り当てる。

図3の（イベント状態開始304）において、管理装置100は、図7に示すイベント状態管理管理テーブルの受付番号700に割り当てた受付番号を、イベント識別子500に問い合わせを受けたイベントの識別子を、時刻701に問い合わせを受けた時刻を、状態702に"イベント受け付け"750といった処理状態を、それぞれ登録し、イベントの状態管理を開始する。

（対策情報検索305）において、管理装置100は、イベント識別子500をキーとしてイベントの対策情報を検索する。管理装置100は、問い合わせメッセージを解析してイベント識別子500が含まれているかを調べる。イベント識別子500がある場合は、図6に示すようなイベント対策情報テーブルを検索してイベント識別子500に対応する対策情報601を検索する。

対策情報601に対して条件600を設けてもよい。イベント識別子500が"207"610である場合に示すように、一つのイベント識別子500に対して複数の条件600を設定し、条件600毎に対策情報601を設定してもよい。条件600とは、"time 9:00-17:00"630のような時間帯設定や、"processed by server1"632のような別の管理装置に既に処理されていること、などである。

図3の（処理中止330）において、イベント優先度503や、イベント発生時刻、イベント発生に関連するハードウェアやソフトウェアの名称、型名、あるいは、管理対象装置120の設置場所、管理者等の問い合わせメッセージに含まれる付属情報800をもとに条件600を設定してもよい。条件600が設定されている場合は、管理装置100は、イベント識別子500に対応する対策情報601のうち、条件600に合致する対策情報601を取得する。合致する対策情報601がない場合は、イベントの処理を中止する。

受信したイベント識別子500に対して、図6のイベント対策テーブルから該当するイベント識別子500が検索されない場合は、テーブルの"default"620に登録された対策情報601を検索する。イベント識別子500の"default"620には、受信したイベント識別子500の値が"default"である場合やイベント対策情報テーブルに登録されていない場合の対策情報601を定める。これによって、標準的な情報管理体系や共通の情報管理体系に当てはまらないようなイベントに対しても対策情報601を定め、対応することができるようになる。

（対策情報取得308）において、管理装置100は、検索結果をもとに対策情報601を取得する。対策情報601とは、管理対象装置120や管理モジュール121に対する設定ファイルの変更命令"change AAA configuration"640、管理対象装置120や管理モジュール121のコマンド実行命令"execute BBB"641、他の装置への通知命令"call http://staff.com/network"642、対策情報601に添付したパッチファイルやモジュール等の実効命令等を表すコマンドや、その実行を記述したスクリプト等である。

スクリプトは、予めテンプレートを作成しておき、そのテンプレートに、イベントに関連するハードウェアやソフトウェアの名称、型名、製造番号等の問い合わせメッセージに含まれる付属情報800を埋め込むような手順で、動的に作成してもよい。ただし、イベントに対する対策情報601は、イベント識別子500に対応して定められており、付属情報800はイベント対策情報601に補助的な情報を与えるものである。

対策情報601には、"send staff"643といった管理装置100が設置してある管理センタから管理対象装置120の設置場所への専門スタッフ派遣、"log"646といった管理装置100や管理モジュール121のログにイベント問い合わせを記録、"call operator"644といったオペレータの呼び出し、"transfer http://maintenance.com/storage"645といった他の管理装置に問い合わせ転送等の内容も含まれる。

イベント対策情報テーブルにおいて、イベント識別子500が"default"620となっている場合の対策情報601として、"call operator"644といったオペレータの呼び出しを登録しておいてもよい。これにより、標準的な情報管理体系や共通の情報管理体系に当てはまらないようなイベントに対しても全て対策を実施することができる。

なお、検索結果が、"call operator"644の呼び出しの場合については、後ほど図9および図10の説明時に述べる。"transfer http://maintenance.com/storage"645の場合については、後ほど図13の説明時に述べる。

図3の（イベント状態更新309）において、管理装置100は、対策情報601の取得後、図7に示すようなイベント状態管理管理テーブルの受付番号700に当該受付番号を、イベント識別子500に当該イベント識別子を、時刻701に処理時刻を、状態702に"対策情報取得"751といった処理状態を、それぞれ登録したエントリを追加して、イベントの処理状態を更新する。

イベント問い合わせが条件600に合致せず、対策情報601を取得できなかった場合も、同様に、状態702に"対策情報取得不可"といった内容を登録したエントリをイベント状態管理テーブルに登録し、イベントの処理状態を更新する。

（応答送信310）において、管理装置100は、管理モジュール121から受信したメッセージに対する応答メッセージに、受付番号700および取得したイベント対策情報601を含めて返信する。例えば、管理モジュール121からHTTPリクエストを受信した場合はその応答のHTTPレスポンスに、（イベント受け付け303）で割り当てられた受付番号700、および、（対策情報取得308）で得たコマンドやスクリプト等の対策情報601を含める。返信データは、管理モジュール121と管理装置100の両者が解釈可能なXML等の任意の形式で記述する。イベント問い合わせが条件600に合致せず、対策情報601を取得できなかった場合は、返信する対策情報601には処理中止を示す識別子を含める。

図3の（イベント状態更新311）において、管理装置100は、応答の送信後、図7に示すようなイベント状態管理管理テーブルの受付番号700に当該受付番号を、イベント識別子500に当該イベント識別子を、時刻701に処理時刻を、状態702に"応答送信"752といった処理状態を、それぞれ登録したエントリを追加し、イベントの処理状態を更新する。

（応答受信205）において、管理モジュール121は、（問い合わせ送信203）で管理装置100に送信した問い合わせの応答メッセージを受信する。管理モジュール121は、応答メッセージを解析し、内部に受付番号700が含まれていれば、管理装置100にイベント問い合わせが受け付けられたと判断する。

なお、管理モジュール121は、設定時間以内に管理装置100から応答を受信できなかった場合は、事前の設定時間だけスリープした後、再度（問い合わせ送信203）を実施する。

図2の（管理者に連絡221）において、管理モジュール121は、上記再送信を、事前の設定回数だけ繰り返しても、通信障害等のために管理装置100から応答を得られなかった場合は、通信障害等をログに記録し、管理対象装置120の管理者に対して、管理対象装置120のディスプレイに表示したり、メールで連絡したりする等の方法によりその内容を通知する。

問い合わせの再送信において、予め予備の問い合わせ先が設定されている場合、例えば、図5の"http://center1.com/server OR http://center2.com/server"523のような場合は、第一の問い合わせ先から応答がない場合に、第二の問い合わせ先に送信する。第一の問い合わせ先である管理装置100のデータと第二の問い合わせ先である他の管理装置100のデータは同期していることが望ましい。

（対策実施208）において、管理モジュール121は、応答メッセージを解析し、内部に対策情報601としてコマンドやスクリプト等が含まれていれば、そのコマンドやスクリプト等を取り出して実行する。実行結果をログや管理装置120のディスプレイに出力してもよい。また、対策情報601がオペレータ呼び出しの場合でも同様である。対策情報601が、専門スタッフを管理対象装置120の設置場所に派遣するといった内容であれば、管理対象装置120の管理者に対して、管理装置120のディスプレイに表示したり、メールで連絡したりするなどの方法によりその内容を通知する。

（対策完了通知送信209）において、管理モジュール121は、対策情報601の実行結果を通知するため、イベントの受付番号700と対策完了情報801を、管理装置100に送信する。対策完了情報801とは、対策完了を示す"operation end"といった識別子である。さらに、対策完了情報801に、（対策実施208）におけるコマンドやスクリプトの実行ログや、管理対象装置120の管理者に対する通知ログ等の、対策情報601の実行結果を示す情報を含んでもよい。

同様に、（対策実施208）において、コマンドやスクリプトの実行に失敗したときは、対策失敗を示す"operation error"といった識別子やエラーログ等を対策完了情報801に含ませる。

（対策完了通知受信401）において、管理装置100は、管理モジュール121の送信した対策完了通知を受信する。

（対策完了受け付け402）において、管理装置100は、イベントの対策完了通知を解析し、対策完了を確認する。管理装置100は、対策完了通知を解析して、受付番号700および対策完了情報801を取り出す。

図4の（イベント状態更新403）において、管理装置100は、図7に示すイベント状態管理管理テーブルの受付番号700に当該受付番号を、イベント識別子500に当該イベント識別子を、時刻701に処理時刻を、状態702に"対策完了受け付け"753といった処理状態を、それぞれ登録したエントリを追加し、イベントの処理状態を更新する。

（再問い合わせ指示420）において、管理装置100は、一定時間経過後の管理対象装置120の情報収集、状態確認や、管理対象装置120への再度の対策情報の提供等を行うために、管理モジュール121に、現在、受付中のイベントについて、再度問い合わせを行うよう指示することも可能である。

図4の（イベント状態更新421）において、管理装置100は、図7に示すイベント状態管理管理テーブルの受付番号700に当該受付番号を、イベント識別子500に当該イベント識別子を、時刻701に処理時刻を、状態702に"再問い合わせ指示"といった処理状態を、それぞれ登録したエントリを追加し、イベントの処理状態を更新する。

（応答送信406）において、管理装置100は、対策完了通知を受け付けたことを管理モジュール121に返信する。管理装置100は、対策を完了する場合、管理モジュール121から受信した対策完了通知メッセージに対する応答メッセージに、受付番号700、および、対策完了受付情報802を送信する。対策完了受付情報802とは、イベント問い合わせ処理の終了を示す"process end"といった識別子である。対策完了受付情報802は空でもよい。

図4の（イベント状態管理終了407）において、管理装置100は、応答の送信後、図7に示すイベント状態管理管理テーブルの受付番号700に当該受付番号を、イベント識別子500に当該イベント識別子を、時刻701に処理時刻を、状態702に"応答送信"754といった処理状態を、それぞれ登録したエントリを追加し、イベントの状態管理を終了する。

図4の（応答送信422）において、管理装置100は、再問い合わせを指示する場合は、管理モジュール121から受信したメッセージに対する応答メッセージに、受付番号700および再問い合わせ指示を送信する。再問い合わせ指示とは、"call me again"といった識別子や再問い合わせの時の宛先等である。

図4の（イベント状態更新423）において、管理装置100は、応答の送信後、図7に示すイベント状態管理管理テーブルの受付番号700に当該受付番号を、イベント識別子500に当該イベント識別子を、時刻701に処理時刻を、状態702に"再問い合わせ指示送信"といった処理状態を、それぞれ登録したエントリを追加し、イベントの状態管理を更新する。

（応答受信211）において、管理モジュール121は、（対策完了通知209）で管理装置100に送信した対策完了通知の応答メッセージを受信する。管理モジュール121は、応答メッセージを解析し、内部に対策完了受付情報802が含まれていれば、管理装置100に対策完了通知が受け付けられたと判断する。

応答メッセージに再問い合わせ指示が含まれていた場合は、（問い合わせ送信203）に戻り、受付番号700を利用して当該イベントに関する再問い合わせを実施する。

図2の（管理者に連絡241）において、管理モジュール121は、事前設定時間内に管理装置100から応答を受信できなかった場合は、設定時間だけスリープした後、再度（対策完了通知送信209）を実施する。

再送信を事前設定回数だけ繰り返しても、通信障害のために管理装置100から応答を得られなかった場合は、これら通信障害の内容をログに記録し、管理対象装置120の管理者に対して、管理対象装置120のディスプレイに表示したり、メールで連絡したりする等の方法によりその内容を通知する。

上記通信障害としては、ファイアウォール122、ファイアウォール107、優先制御装置108、認証装置109や、管理装置100における障害や、通信データの集中による処理性能限界オーバー、ネットワーク110における障害や通信データの集中による通信帯域オーバー等がありえる。

（終了215）において、管理モジュール212は、管理装置100から対策完了受付情報802を受け取ったら、その内容をログに記録し、イベント対策処理を終了する。

次に、管理モジュール121が、管理装置100とメッセージ交換を行い、図8に示したイベント対策を実施する上で、オペレータが介在する場合を、図9を参照し、時間軸に沿って説明する。

図9の（イベント検知201）から（対策方法検索305）では、図8と同様の処理を実施する。

（オペレータ呼び出し340）において、管理装置100は、イベント識別子500をキーに図6のイベント対策情報テーブルを検索した結果がオペレータの呼び出し指示"call operator"644であった場合、ディスプレイ106にイベント識別子500や付属情報800を表示するなどして、オペレータにイベントの処理を要請する。

図3の（イベント状態更新309）において、管理装置100は、図7に示すイベント状態管理管理データの受付番号700に当該受付番号を、イベント識別子500に当該イベント識別子を、時刻701に処理時刻を、状態702に"オペレータ呼び出し"760といった処理状態を、それぞれ登録したエントリを追加して、イベントの処理状態を更新する。

（応答送信310）において、管理装置100は、前述した図8における管理装置100の処理（応答送信310）と同様の通信手法にて、（イベント受け付け303）で割り当てられた受付番号700を管理モジュール121に返信する。返信メッセージに、受付番号700以外にオペレータ呼び出しを示す識別子を含め、オペレータが処理中であることを明示的に管理モジュール121に通知してもよい。さらに、応答メッセージに、管理モジュール121に対する次回の問い合わせ送信203(2)の送信時刻や、送信周期、送信回数といった指示を含めてもよい。

（応答受信205）において、管理モジュール121は、前述した図8における管理モジュール121の処理（応答受信205）と同様に、（問い合わせ送信203）で管理装置100に送信した問い合わせの応答メッセージを受信する。

（問い合わせ送信203(2)）において、管理モジュール121は、応答メッセージを解析した結果、対策情報601が含まれていない場合は、管理装置100に、再度、問い合わせを送信する。問い合わせ通知には、受付番号700を含ませ、（問い合わせ送信203）において問い合わせたイベントについての再問い合わせであることを通知する。再問い合わせの時刻、周期、送信回数等の設定は、管理装置100からの応答メッセージに含まれる指示、あるいは、管理モジュール121の設定に従う。

（問い合わせ受信301(2)）において、管理装置100は、上記（問い合わせ受信301）と同様、問い合わせを受信する。

（イベント再受け付け320）において、管理装置100は、問い合わせメッセージを解析して、受付番号700を含んでいるかどうかを調べる。受付番号700を含んでいる場合は、既に受付済みのイベントであると判断して、図7に示すイベント状態管理管理テーブルを、受付番号700をキーに検索した状態702を調べ、問い合わせを受けたイベントの処理状態を把握する。

図3の（イベント状態更新321）において、管理装置100は、イベント状態管理管理テーブルの受付番号700に当該受付番号を、イベント識別子500に当該イベント識別子を、時刻701に処理時刻を、状態702に"イベント再受け付け"761といった処理状態を、それぞれ登録したエントリを追加して、イベントの処理状態を更新する。

（応答送信310(2)）において、管理装置100は、上記（応答送信310）と同様、対策情報601を得られない場合は、受付番号700を管理モジュール121に返信する。

（応答受信205(2)）において、管理モジュール121は、上記（応答受信205）と同様、（問い合わせ送信203(2)）で管理装置100に送信した問い合わせの応答メッセージを受信する。

管理モジュール121は、設定回数分だけ、或いは、管理装置100による指定回数分だけ、何らかの対策情報601を得られるまで、上記の（問い合わせ送信203(2)）処理を繰り返す。

図2の（管理者に連絡233））において、管理モジュール121は、この再問い合わせを、事前設定回数だけ繰り返しても、管理装置100から対策情報601を得られなかった場合は、その内容をログに記録し、さらに、管理対象装置120の管理者に対して、管理対象装置120のディスプレイに表示したり、メールで連絡したりする等の方法によりその内容を通知する。

（問い合わせ送信203(3)）において、管理モジュール121は、上記（問い合わせ送信203(2)）同様、管理装置100に、再度、問い合わせを送信する。

（問い合わせ受信301(3)）において、管理装置100は、上記（問い合わせ受信301(2)）と同様、問い合わせを受信する。

（イベント再受け付け320(3)）において、管理装置100は、上記（イベント再受け付け320）と同様、問い合わせメッセージ内の受付番号700をキーに図7に示すイベント状態管理管理テーブルを検索して状態702を調べ、問い合わせを受けたイベントの処理状態を把握する。また、イベントの処理状態を更新する。（オペレータによる対策情報入力900）が行われている場合は、図7の当該受け付け番号700における状態702に、"オペレータによる対策情報入力"762のように登録されている。これにより、管理装置100は、対策情報601が取得可能であると判断する。

（対策情報取得308）において、管理装置100は、前述した図8における管理装置100の処理（対策方法取得308）と同様、オペレータにより入力された対策情報601を取得する。オペレータにより入力された対策情報601は、図8における管理装置100の処理（対策方法取得308）で説明した対策情報601と同様の内容である。

（応答送信310(3)）から（終了215）において、管理モジュール121および管理装置100は、前述した図8における管理モジュール121および管理装置100の（応答送信310）から（終了215）までの処理と同様の処理を実施する。

上記処理において、一度目のイベントの問い合わせに対して、オペレータが入力した対策情報601を図6のイベント対策情報テーブルに保持することにより、二度目の問い合わせ以降は、図8に示すオペレータが介在せずに対策情報を送信する形態に移行できる。

次に、管理モジュール121が、管理装置100とメッセージ交換を行い、図9に示すイベント対策を実施する上で、オペレータが介在し、管理モジュール121に情報追加指示を出す場合について、図10を参照し、時間軸に沿って説明する。

（イベント検知201）から（問い合わせ受信301(2)））は、前述した図9における管理モジュール121および管理装置100の処理と同様である。

（イベント再受け付け320）において、管理装置100は、前述した図9における処理（イベント再受け付け320）同様、イベントの処理状態を把握する。（オペレータによる情報追加指示1000）が行われている場合は、図7のようなイベント状態管理テーブルの当該受け付け番号700における状態702に、"オペレータによる情報追加指示"のように登録されている。これにより、管理装置100は、オペレータが情報追加を要求していることを判断する。

（情報追加指示341）において、管理装置100は情報追加指示1010を取得する。情報追加指示1010とは、管理対象装置120や管理モジュール121に対する"get XXX configuration"、"get YYY log"、"execute ZZZ and get AAA"といったコマンドや、その実行を記述したスクリプト等である。コマンドの実行を記述するスクリプトは、予め用意されていてもよいし、テンプレートのみ用意しておいて、オペレータが情報追加を指示する際に付属情報800を利用するなどにより動的に作成してもよい。

（応答送信310(2)）において、管理装置100は、（応答送信310）と同様に受付番号700および情報追加指示1010を管理モジュール121に返信する。

（応答受信205(2)）において、管理モジュール121は、（応答受信205）と同様、（問い合わせ送信203(2)）への応答メッセージを受信する。

（追加情報収集231）において、管理モジュール121は、応答メッセージを解析し、内部に情報追加指示1010としてコマンドやスクリプト等が含まれていれば、そのコマンドやスクリプトを実行し、管理装置100が要求する追加情報1011を取得する。追加情報1011とは、管理対象装置120や管理モジュール121の設定ファイル（Configuration）や障害ログ等の、情報追加指示1010として受信したコマンドやスクリプトを実行して得られた情報である。なお、コマンドやスクリプトの実行に失敗した場合は、実行失敗を示す"operation error"といった識別子やエラーログ等を追加情報1011に含ませる。

（問い合わせ送信203(3)）において、管理モジュール121は、（問い合わせ送信203）と同様に、受付番号700、および、（追加情報収集231）にて収集した追加情報1011を、管理装置100に送信する。

（問い合わせ受信301(3)）において、管理装置100は、（問い合わせ受信301）と同様に、受付番号700および追加情報1011を含む再問い合わせメッセージを、管理モジュール121から受信する。

（イベント再受け付け320(3)）において、管理装置100は、上記（イベント再受け付け320）と同様、問い合わせメッセージ内の受付番号700をキーに、図7に示すイベント状態管理管理テーブルを検索して状態702を調べ、問い合わせを受けたイベントの処理状態を把握する。さらに、イベントの処理状態を更新する。

図3の（イベント状態更新321）において、管理装置100は、追加情報1011を受信している場合は、イベント状態管理管理テーブルの受付番号700に当該受付番号を、イベント識別子500に当該イベント識別子を、時刻701に処理時刻を、状態702に"追加情報取得"といった処理状態を、それぞれ登録したエントリを追加して、イベントの処理状態を更新する。

（追加情報提示342）において、管理装置100は、追加情報1011を受信している場合は図7の当該受け付け番号700における状態702に"追加情報取得"と登録されているので、追加情報1011をオペレータに提示することができると判断し、追加情報1011をディスプレイ106に表示する等して、オペレータに提示する。

図3（イベント状態更新309）において、管理装置100は、図7のようなイベント状態管理管理テーブルの受付番号700に当該受付番号を、イベント識別子500に当該イベント識別子を、時刻701に処理時刻を、状態702に"追加情報提示"といった処理状態を、それぞれ登録したエントリを追加して、イベントの処理状態を更新する。

（応答送信310(3)）において、管理装置100は、前述した図9における処理（応答送信310(2)）と同様の処理を実施する。なお、（オペレータによる情報追加指示1000）が、再度、実施された場合は、管理装置100と管理モジュール121において、上記（情報追加指示341）から（イベント再受け付け320(3)）までの処理を、再度、実行する。

（応答受信205(3)）から（終了215）において、管理モジュール121および管理装置100は、前述した図9における管理モジュール121および管理装置100の（応答受信205(2)）から（終了215）までの処理と同様の処理を実施する。

次に、管理モジュール121が、複数の管理装置100に対して同時に問い合わせを行い、図8に示すイベント対策を実施する場合を、図11を参照し、時間軸に沿って説明する。

（イベント検索201）は、図8における処理と同様である。

（問い合わせ先検索202）は、図8における処理と同様である。管理対象装置120に発生するイベントが、ストレージとネットワーク、特定のソフトウェアとハードウェアといった複数の部位や事象に関係する場合や、複数の部位や事象のいずれに関係するか判断ができない場合がある。このような場合に対応する問い合わせ先として、図5の"http://center.com/storage AND http://center.com/network"524のように、複数の問い合わせ先を同時に指定する。

（問い合わせ送信203）から（応答受信205）において、管理モジュール121、および、（問い合わせ先検索202）で検索された第1の問い合わせ先である管理装置100は、図8と同様の処理を実施する。

さらに、第2、第3の問い合わせ先がある場合でも同様の処理を行う。

管理装置(2)100(2)は、図6のイベント対策情報テーブルに示す条件600を利用して、問い合わせメッセージに管理装置100の受付番号700が含まれているときに対策情報(2)601(2)を送信するようにすることもできる。この場合は、図5のイベント問い合わせテーブルにおける当該イベント識別子500に対応する備考503に、管理装置(2)100(2)への送信には管理モジュール100の受付番号700が必要であることを予め設定しておき、管理モジュール121は、管理装置(2)100(2)に送信する付属情報(2)800(2)に、管理装置100からの受付番号700を含ませる。

管理装置(2)100(2)におけるイベント対策情報テーブルの条件600に、管理装置100に受け付けられていることといった条件が設定されていない場合は、管理モジュール121は、管理装置100に対する問い合わせの応答受信205を待たず、管理装置(2)100(2)対する問い合わせを同時に行ってもよい。

（対策実施208）において、管理モジュール121は、管理装置100および管理装置(2)100(2)の応答メッセージを解析し、対策情報601および対策情報(2)601(2)を実施する。対策情報601、対策情報(2)601(2)の両方、あるいは、いずれを実施するのか、どの順序で実施するのか等は、イベント識別子500に対応する備考503に、事前に定めておく。

（対策完了通知送信209）から（応答受信211）は、図8と同様の処理を実施する。

さらに、第2、第3の問い合わせ先があった場合でも同様の処理を行う。

管理装置(2)100(2)への送信に管理装置100の受付番号700が必要であることが予め設定してある場合は、管理装置(2)100(2)に送信する対策完了情報(2)801(2)に、管理装置100からの受付番号700を含ませる。

管理装置(2)100(2)におけるイベント対策情報テーブルの条件600に、管理装置100に受け付けられていることといった条件が設定されていない場合においては、管理モジュール121は、管理装置100に対する対策完了通知の応答受信211を待たずに、管理装置(2)100(2)対する対策完了通知を同時に行ってもよい。

次に、管理モジュール121が、複数の管理装置100に対して連続的に問い合わせを行い、図8に示すイベント対策を実施する場合を、図12を参照し、時間軸に沿って説明する。

（イベント検索201）は、図8における処理と同様である。

（問い合わせ先検索202）は、図8における処理と同様である。管理対象装置120に発生するイベントに対して、第一の管理装置によって一次対策を実施した上で、第二の管理装置により二次対策を行う場合がある。このような場合に対応する問い合わせ先として、図5の"http://center.com/server, http://center.com/staff"525のように、複数の連続した問い合わせ先を指定する。

（問い合わせ送信203）から（応答受信211）は、図8における処理と同様に実施し、第一の管理装置100によるイベント対策実施を完了する。

（問い合わせ送信203(2)）から（イベント受け付け303(2)）は、図8における処理と同様である。

（対策情報検索305(2)）において、管理装置100(2)は、イベント識別子500をキーとして、イベントの対策情報601を検索する。このとき、図6に示すイベント対策情報テーブルのイベント識別子500に対する条件600に、"processed by server1"632のように管理装置100に既に処理されていることという条件を設定することも可能である。この場合は、図5に示すイベント問い合わせ先テーブルの当該イベント識別子500に対応する備考503に、管理装置(2)100(2)への送信には管理モジュール100の受付番号700および対策完了受付情報802が必要であることを予め設定しておく。管理モジュール121は、付属情報(2)800(2)に、管理装置100からの受付番号700および対策完了受付情報802を含め、管理装置(2)100(2)に送信する。

（対策情報取得308(2)）から（終了215）において、管理モジュール121、および、管理装置(2)100(2)は、前述した図8における管理モジュール121および管理装置100の（対策情報取得308）から（終了215）までの処理と同様の処理を実施する。

さらに、第3の問い合わせ先があった場合でも上記（問い合わせ送信203(2)）から（応答受信211(2)）までの処理と同様の処理を行う。

最後に、管理モジュール121が、管理装置100に対して問い合わせを行ったときに、管理装置100が、図9に示すオペレータへの問い合わせの代わりに、さらに他の管理装置(2)100(2)に問い合わせを転送しイベント対策を実施する場合を、図13を参照し、時間軸に沿って説明する。

この問い合わせの転送処理では、実際の処理においては、異なる専用の各管理装置が対策情報を提供する場合であっても、管理モジュール121にとっては、問い合わせ宛先を一元化することができる。

（イベント検知201）から（対策方法検索305）において、管理モジュール121および管理装置100は、前述した図9における管理モジュール121および管理装置100の（イベント検知201）から（対策方法検索305）までの処理と同様の処理を実施する。

（問い合わせ転送343）において、イベント識別子500をキーに検索した結果が、図6の"transfer http://maintenance.com/storage"645のように他の管理装置への問い合わせの転送を指示している場合は、管理装置100は、転送先に指定された管理装置(2)100(2)に、受信したイベント識別子500、および、付属情報800(2)を転送する。

図3の（イベント状態更新309）において、管理装置100は、図7に示すイベント状態管理管理テーブルの受付番号700に当該受付番号を、イベント識別子500に当該イベント識別子を、時刻701に処理時刻を、状態702に"問い合わせ転送"といった処理状態を、それぞれ登録したエントリを追加して、イベントの処理状態を更新する。

管理装置100は、管理装置(2)100(2)に付属情報800を転送する際に、そのまま転送してもよいが、管理装置(2)100(2)の指定するフォーマットにデータ変換を行ったり、受付番号700を追加したりすることで明示的に管理装置100で受け付けていることを示すようにしてもよい。

（応答送信310）から（応答受信205）は、図9における処理と同様である。

（問い合わせ受信301(3)）から（応答送信310(3)）において、管理装置(2)100(2)は、図8における管理装置100の（問い合わせ受信301）から（応答受信310）までの処理と同様の処理を実施する。なお、管理装置(2)100(2)においては、図6のイベント対策方法データの条件600を利用して、問い合わせメッセージに管理装置100の受付番号700が含まれているときに対策情報601を送信しても良い。

（転送応答受信1300）において、管理装置100は、管理装置(2)100(2)から転送した問い合わせの応答として受付番号(2)700(2)と対策情報601を受信する。さらに、図7に示すイベント状態管理データの当該受け付け番号700における状態702に"転送応答受信"のように登録したエントリを追加し、イベントの処理状態を更新する。

（問い合わせ送信203(2)）から（問い合わせ受信301(2)）は、図9における処理と同様である。

（イベント再受け付け320）において、管理装置100は、図9における管理モジュール121の処理（イベント再受け付け(3)）と同様の処理を行い、イベント状態管理データを参照して、イベントの処理状態を把握する。また、イベントの処理状態を更新する。

管理装置(2)100(2)から、転送した問い合わせに対する応答を受信している場合は、図7の当該受け付け番号700における状態702に、"転送応答受信"が登録されている。これにより、管理装置100は、対策情報601を取得可能である、と判断する。

（対策情報取得308）において、管理装置100は、前述した図9における管理装置100の処理（対策方法取得308）と同様に、管理装置(2)100(2)から送信された対策情報601を取得する。この対策情報601は、図8における管理装置100の処理（対策方法取得308）で説明した対策情報601と同様の内容である。

（応答送信310(2)）において、管理装置100は、前述した図9における管理装置100の処理（応答送信310(3)）と同様に、受付番号700と対策情報601(2)を、管理モジュール121に返信する。対策情報601(2)は、管理装置(2)100(2)から受信した対策情報601そのままでもよいし、管理モジュール121に適したデータ形式にフォーマット変換を行ってもよい。管理装置(2)100(2)から取得した対策情報601に管理装置100の情報を追加して、新しく対策情報601(2)を作成してもよい。

（応答受信205(2)）から（対策完了受け付け402）において、管理モジュール121および管理装置100は、前述した図9における管理モジュール121および管理装置100の（応答受信205(3)）から（対策完了受け付け402）までの処理と同様の処理を実施する。

（通知転送410）において、上記（問い合わせ転送343）で述べたように、管理装置100は、管理装置(2)100(2)に、管理モジュール121から受信した対策完了通知を転送する。

図4の（イベント状態更新411）において、管理装置100は、図7に示すイベント状態管理管理データの受付番号700に当該受付番号を、イベント識別子500に当該イベント識別子を、時刻701に処理時刻を、状態702に"対策完了通知転送"といった処理状態を、それぞれ登録したエントリを追加して、イベントの処理状態を更新する。

対策完了通知には、管理装置(2)100(2)から受信した受け付け番号(2)700(2)および対策完了情報(2)801(2)を含める。対策完了情報(2)801(2)には、管理モジュール121から受信した対策完了情報801をそのまま用いてもよいし、管理装置100(2)の指定するフォーマットにデータ変換を行ってもよい。また、受付番号700や対策完了受付情報802を追加することで、明示的に管理装置100で受け付けられている、あるいは、処理が終了していることを示してもよい。

（対策完了通知受信401(3)）から（応答送信406(3)）において、管理装置(2)100(2)は、前述した図8における管理装置100の（対策完了通知受信401）から（応答送信406）までの処理と同様の処理を実施する。

（応答送信406）から（終了215）において、管理モジュール121および管理装置100は、前述した図9における管理モジュール121および管理装置100の（応答送信406）から（終了215）までの処理と同様の処理を実施する。

（転送応答受信1301）において、管理装置100は、管理装置(2)100(2)から、転送した対策完了通知への応答として受付番号(2)700(2)と対策完了受付情報(2)802(2)を受信する。さらに、図7に示すイベント状態管理データの当該受け付け番号700における状態702に、"対策完了通知転送の応答受信"のように登録したエントリを追加し、イベントの処理状態を更新する。

以上で説明したように、本実施形態に係る遠隔管理管理システムは、次のような特徴と機能を奏するものである。即ち、本実施形態では、管理対象装置120に発生する事象を、複数の管理対象装置120に適応可能なイベント体系で管理し、管理対象装置120の内部に管理エージェント211を配置する。管理エージェント211は、管理対象装置120のイベントを検知し、管理装置100にイベント識別子500を送信して問い合わせを行う。

管理装置100は、管理モジュール121の問合せを受信し、管理対象装置120のイベントを受け付け、イベント状態管理テーブルを用いてイベントの状態を管理し、イベント対策情報テーブルからイベント識別子500に対応した対策情報601を検索し、イベント受付番号700および対策情報601を管理モジュール121に送信する。

管理モジュール121は、さらに、管理装置100から受信した対策情報601を実施し、管理装置100に受付番号700および対策完了情報801を送信してイベント対策が完了したことを通知する。管理装置100は、さらに、管理モジュール121から通知されたイベント対策完了通知を受け付ける。

これらが動作することにより、管理対象装置120側のファイアウォール122の設定変更や管理対象装置120のアドレスの把握を必要とせず、管理対象装置120が増加した場合でも管理装置100に設定を追加する必要のない、簡易でスケーラブルな遠隔管理が可能になる。

さらに、管理モジュール121が、イベント問い合わせ先テーブルからイベントに対応した一つ以上の問合せ先501を検索し、一つの管理装置100から応答がない場合に他の管理装置100に問い合わせを行ったり、複数の管理装置100に同時に問い合わせを行ったり、複数の管理装置100に連続的に問い合わせを行ったりすることにより、管理対象装置120は、確実にイベント対策情報601を取得でき、管理装置100側は、複数の装置で、管理対象装置120の管理を分担、あるいは、協調して実施することが可能になる。

さらに、イベント対策情報テーブルを検索し、管理モジュール121のイベントの問い合わせ条件600に応じた対策情報601を取得することにより、管理装置100は、時間帯等の問い合わせ条件600に応じて提供する対策情報601を変更することができ、状況に応じた対策情報601の提供が可能になる。

さらに、管理モジュール121が、管理装置100から対策情報601を提供されるまで管理装置100に問い合わせを繰り返すことにより、管理装置100において、オペレータが介在して対話的に管理対象装置120と情報交換を行うことができ、管理対象装置120に予期せぬイベントが発生したとき等でも、イベント対策を確実に実施することができる。

さらに、管理モジュール121が、イベント問い合わせ先テーブルにおいて、イベント識別子500に対応した一つ以上の問い合わせ先が定義されていない場合の問合せ先を割り当てることにより、標準的な情報管理体系や共通の情報管理体系に当てはまらないイベントに対しても問い合わせ先501を定め、イベント対策を確実に実施することができる。

さらに、管理装置100が、イベント対策情報テーブルにおいて、イベント識別子500に対応した対策情報が登録されていない場合に用いる対策情報601を登録することにより、標準的な情報管理体系や共通の情報管理体系に当てはまらないイベントに対しても対策情報601を定め、イベント対策を確実に実施することができる。

さらに、管理装置100が、イベント対策情報テーブルにおいて、イベント識別子に対応した対策情報が登録されていない場合に、オペレータ呼び出しという対策情報601を割り当てることにより、標準的な情報管理体系や共通の情報管理体系に当てはまらないイベントに対しても、オペレータが対応することにより、イベント対策を確実に実施することができる。

さらに、管理モジュール121が、問い合わせの繰り返し時に、管理装置100に情報を追加して提供することにより、管理装置100にイベントの対策立案に必要な情報を提供できるので、イベント対策を確実に実施することができる。

さらに、管理モジュール121が、管理装置100から問い合わせに対する応答を得られなかった場合や、管理装置100から対策情報601を提供されなかった場合や、管理装置100からイベント対策完了通知に対する応答を得られなかった場合に、管理対象装置120の管理者に、イベント対策時におけるエラーの発生を連絡できるので、イベント対策を確実に実施することができる。

さらに、管理モジュールが121、管理装置100から受信した対策情報601を管理対象装置120の管理者に、イベント対策経過や結果を連絡できるので、イベント対策を確実に実施することができる。

本実施形態におけるシステムの構成である。本実施形態における管理モジュールの処理フローである。本実施形態における問い合わせ受信時の管理装置の処理フローである。本実施形態における対策完了通知受信時の管理装置の処理フローである。本実施形態におけるイベント問い合わせ先テーブルである。本実施形態におけるイベント対策情報テーブルである。本実施形態におけるイベント状態管理テーブルである。本実施形態における基本的なメッセージシーケンスである。本実施形態におけるオペレータ介在時のメッセージシーケンスである。本実施形態におけるオペレータへの情報追加提供時のメッセージシーケンスである。本実施形態における複数同時問い合わせ時のメッセージシーケンスである。本実施形態における複数連続問い合わせ時のメッセージシーケンスである。本実施形態における階層的問い合わせ時のメッセージシーケンスである。

符号の説明

201：イベント検知、202：問い合わせ先検索、203：問い合わせ先送信、500：イベント識別子、800：付属情報、301：問い合わせ受信、303：イベント受け付け、305：対策方法検索、308：対策情報取得、310：応答送信、700：受付番号、601：対策情報、205：応答受信、208：対策実施、209：対策完了通知送信、801：対策完了情報、401：対策完了通知受信、402：対策完了受け付け、406：応答送信、802：対策完了受付情報、211：応答受信、215：終了。

Claims

ネットワークを介して接続された管理対象装置と管理装置とを備えた遠隔管理システムであって、
前記管理対象装置は、
当該管理対象装置に発生したイベントを検知する手段と、
前記管理装置に、前記イベントの識別子を含む問い合わせを送信する手段を備え、
前記管理装置は、
前記管理対象装置から、前記イベントの識別子を含む問い合わせを受信する手段と、
前記イベントの処理状態を管理するために備えるイベント対策情報テーブルから、前記イベント識別子に対応した対策情報を検索する手段と、
前記対策情報を前記管理モジュールに送信する手段とを備え、さらに、
前記管理対象装置は、
前記管理装置から前記対策情報を受信する手段と、
受信した前記対策情報に基づき前記イベントの対策を実施する手段と、
前記管理装置に前記イベントの対策が完了したことを通知する手段を備え、さらに、
前記管理装置は、
前記管理対象装置から前記イベントの対策完了通知を受信する手段と、を備える
ことを特徴とする遠隔管理システム。
請求項1に記載の遠隔管理システムにおいて、
前記管理対象装置が、
当該管理対象装置が備えるイベント問い合わせ先テーブルから、前記イベントの識別子に対応した一つ以上の問い合わせ先を検索する手段と、
前記一つ以上の問い合わせ先に対して問い合わせを行う手段と、を備える
ことを特徴とする遠隔管理システム。
請求項1に記載の遠隔管理システムにおいて、
前記管理装置が、前記イベント対策情報テーブルから、前記管理対象装置が指定する問い合わせ条件に応じた対策情報を検索する手段を備える
ことを特徴とする遠隔管理システム。
請求項1に記載の遠隔管理システムにおいて、
前記管理対象装置が、前記対策情報を提供されるまで前記管理装置に前記問い合わせを繰り返し送信する手段を備える
ことを特徴とする遠隔管理システム。
請求項２に記載の遠隔管理システムにおいて、
前記管理対象装置の前記イベント問い合わせ先テーブルは、前記イベントの識別子に対応した問い合わせ先が定義されていない場合の問合せ先を備える
ことを特徴とする遠隔管理システム。
請求項１に記載の遠隔管理システムにおいて、
前記管理装置の前記イベント対策情報テーブルは、前記イベント識別子に対応した対策情報が登録されていない場合に用いる対策情報を備える
ことを特徴とする遠隔管理システム。
請求項６に記載の遠隔管理システムにおいて、
前記管理装置の前記イベント対策情報テーブルは、前記イベント識別子に対応した対策情報が登録されていない場合の対策情報として、オペレータ呼び出しを定義する
ことを特徴とする遠隔管理システム。
請求項４に記載の遠隔管理システムにおいて、
前記管理対象装置が、前記問い合わせの繰り返し時に、情報を追加する手段を備える
ことを特徴とする遠隔管理システム。
請求項１に記載の遠隔管理システムにおいて、
前記管理対象装置が、前記問い合わせに対する応答を前記管理装置から得られなかった場合、または、前記管理装置から前記対策情報を提供されなかった場合、または、前記イベント対策完了通知に対する応答を前記管理装置から得られなかった場合に、前記管理対象装置の管理者に通知する手段を備える
ことを特徴とする遠隔管理システム。
請求項１に記載の遠隔管理システムにおいて、
前記管理対象装置が、受信した前記対策情報を、当該管理対象装置の管理者に通知する手段を備える
ことを特徴とする遠隔管理システム。