JPH10247911A

JPH10247911A - マルチサーバ構成におけるシステム監視情報管理装置及びマルチサーバ構成におけるシステム監視情報管理方法

Info

Publication number: JPH10247911A
Application number: JP9050450A
Authority: JP
Inventors: Akio Saito; 彰男斎藤; Hiroyuki Yamanishi; 宏幸山西
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 1997-03-05
Filing date: 1997-03-05
Publication date: 1998-09-14

Abstract

(57)【要約】【課題】複数のサーバを含むマルチサーバシステムに
おいて、各サーバで生じた事象を集中的に管理し、事象
が生じたことを自動的に利用者に知らせることができる
管理装置を提供する。【解決手段】各サーバ処理部２０に含まれる状変監視
部２０ａは、状変が生じたことを検知すると、共用処理
部２２の状変データ共用管理部２２ａに通知する。状変
データ共用管理部２２ａは状変のデータを状変データ共
用ファイル２６中に格納する。ＡＰ通知管理部２２ｃ
は、状変データＡＰ通知定義ファイル３０を利用して、
指定されたサーバへユーザ通知を行う。このような構成
により、事象が発生したことを利用者は自動的に知るこ
とが可能である。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ネットワークシス
テムの監視情報を管理する方法に関する。特に、ネット
ワーク上に複数のサーバが存在する場合に、システム監
視、制御に必要な情報をサーバ間で共有し、共通の手段
でその情報を取得することができる方法に関する。

【０００２】

【従来の技術】複数のサーバをネットワークで接続した
マルチサーバシステムが広く利用されている。このよう
なマルチサーバシステムにおいては、システム監視に必
要な情報は、ユーザが情報元から直接取得していた。特
に、システム監視に必要な情報は情報の提供元が独自の
方法で提供しており、ユーザはこの独自の方法に則して
情報を取得する必要があった。そして、必要に応じてネ
ットワーク上の各サーバ間で、その取り込んだ情報を交
換・通知しあい、各サーバはそれぞれシステム制御を行
っていた。

【０００３】

【発明が解決しようとする課題】さて、上記情報の取得
手段は各サーバ内で閉じた手段であった。そのため、そ
の情報元の種類によって異なる種々の方法に従って情報
をそれぞれ取得する必要がある。また、マルチサーバ構
成においては、これらの情報を一括で管理する必要があ
るが、その手段としては、一般に単なる通信手段のみが
提供され、実際の情報の通知動作は、そのシステムのユ
ーザが実施しなければならなかった。そのため、ユーザ
の管理負担は大であった。さらに、システムの高信頼化
を実現するための予防保全に関する機能も、シングルサ
ーバを前提とした機能のみが提供されており、マルチサ
ーバを考慮した機能は何等提供されていなかった。その
ため、マルチサーバ環境下におけるユーザの負担が大と
なっていた。

【０００４】本発明は、係る問題点に鑑みなされたもの
であり、その目的は、マルチサーバ構成において、シス
テム管理、制御に必要な情報をサーバ間で共有し、共通
の手段で取得することができる骨格機能を提供し、ユー
ザのシステム管理処理の負担の低減を図ることである。

【０００５】

【課題を解決するための手段】本発明に係るマルチサー
バ構成におけるシステム監視情報管理装置は、複数のサ
ーバを含む構成のシステムにおいて発生した事象を管理
するマルチサーバ構成におけるシステム監視情報管理装
置において、前記システムに含まれる複数のサーバに対
し共通に設けられている共通記憶手段と、前記システム
に含まれる各サーバ毎に設けられ、前記各サーバ毎に発
生した事象を検知し、この検知した事象に関する情報で
ある事象情報をネットワークを介して送信する事象検知
手段と、前記システムに含まれる何れかのサーバに設け
られ、前記送信された事象情報を受信し、この受信した
事象情報を前記共通記憶手段に記憶する管理手段と、を
含むものである。

【０００６】本発明に係るマルチサーバ構成におけるシ
ステム監視情報管理装置は、前記事象検知手段は、前記
マルチサーバ構成のシステムに予め定義されているシス
テム事象を検知するシステム事象検知手段と、前記シス
テムの利用者が定義するユーザ事象を検知するユーザ定
義事象検知手段と、を含むものである。

【０００７】本発明に係るマルチサーバ構成におけるシ
ステム監視情報管理装置は、前記システム事象検知手段
は、前記システム事象として、ハードウェアに縮退が生
じたこと、を検知するものである。

【０００８】本発明に係るマルチサーバ構成におけるシ
ステム監視情報管理装置は、前記システム事象検知手段
は、前記システム事象として、再試行が成功したこと、
を検知するものである。

【０００９】本発明に係るマルチサーバ構成におけるシ
ステム監視情報管理装置は、前記システム事象検知手段
は、前記システム事象として、機能的には障害がないが
冗長化ハードウェアの一部に障害が発生したこと、を検
知するものである。

【００１０】本発明に係るマルチサーバ構成におけるシ
ステム監視情報管理装置は、前記管理手段は、受信した
前記事象情報の示す事象が利用者に通知すべきユーザ通
知事象である場合に、前記受信した事象情報をネットワ
ークを介して所定のサーバに送信するユーザ通知送信手
段、を含み、前記システムに含まれる複数の各サーバ毎
に設けられ、前記ユーザ通知送信手段により送信されて
きた事象情報を受信し、受信した事象情報を利用者に通
知するユーザ通知連絡手段、を含むものである。

【００１１】本発明に係るマルチサーバ構成におけるシ
ステム監視情報管理装置は、前記ユーザ通知送信手段が
前記事象情報の送信を失敗した場合、又は、前記ユーザ
通知連絡手段が事象情報の利用者への通知を失敗した場
合には、通知失敗事象を前記管理手段に送信する通知失
敗検出手段、を含み、前記通知失敗事象は前記ユーザ通
知事象であるものである。

【００１２】本発明に係るマルチサーバ構成におけるシ
ステム監視情報管理装置は、前記ユーザ通知送信手段
は、前記発生した事象と、この事象に関する事象情報の
送信を行うべき１個以上のサーバと、前記１個以上のサ
ーバのそれぞれに割り当てられている優先順位と、を記
憶している優先順位記憶手段と、この優先順位記憶手段
中で最も高い優先順位が割り当てられているサーバ又は
サーバ群から、順に低い優先順位が割り当てられている
サーバ又はサーバ群にアクセスし、一番最初に見つかっ
た稼働しているサーバ又はサーバ群に対し前記事象情報
の送信を行う優先通知手段と、を含むものである。

【００１３】本発明に係るマルチサーバ構成におけるシ
ステム監視情報管理装置は、前記システムに含まれる複
数のサーバ間における定期通信を行うために、前記各サ
ーバに設けられている所定周期毎に定期通信を行う定期
通信手段、を備え、前記ユーザ通知送信手段は、前記定
期通信手段が行う前記定期通信における通信対象である
パケット中に、前記発生した事象情報を含めるパケット
形成手段、を含み、前記ユーザ通知は、前記定期通信で
使用するパケットと同一のパケットを使用して行われる
ものである。

【００１４】本発明に係るマルチサーバ構成におけるシ
ステム監視情報管理装置は、前記ユーザ通知連絡手段
は、前記ユーザ通知事象に対して予め指定されている指
定プロセスを、事象情報の送信先であるサーバ上で起動
させる起動手段、を含むものである。

【００１５】本発明に係るマルチサーバ構成におけるシ
ステム監視情報管理装置は、前記ユーザ通知連絡手段
は、前記ユーザ通知事象に対して予め指定されている指
定キーのメッセージの送付を、事象情報の送信先である
サーバ上で行うメッセージ送付手段、を含むものであ
る。

【００１６】本発明に係るマルチサーバ構成におけるシ
ステム監視情報管理装置は、前記ユーザ通知連絡手段
は、前記ユーザ通知事象に対して予め指定されている指
定ソケットへの通知を、事象情報の送信先であるサーバ
上で行うソケット通知手段、を含むものである。

【００１７】本発明に係るマルチサーバ構成におけるシ
ステム監視情報管理装置は、複数のサーバを含む構成の
システムにおいて発生したロギングを管理するマルチサ
ーバ構成におけるシステム監視情報管理装置において、
前記システムに含まれる複数のサーバに対し共通に設け
られている共通記憶手段と、前記システムに含まれる各
サーバ毎に設けられ、前記各サーバ毎に発生したロギン
グを検知し、この検知したロギング情報が前記共通記憶
手段に記憶すべきロギングの場合、ロギング情報をネッ
トワークを介して送信するロギング検知手段と、前記シ
ステムに含まれる何れかのサーバに設けられ、前記送信
されたロギング情報を受信し、この受信したロギング情
報を前記共通記憶手段に記憶する管理手段と、を含むも
のである。

【００１８】本発明に係るマルチサーバ構成におけるシ
ステム監視情報管理装置は、前記ロギング検知手段は、
ロギングを検知した時刻の情報を、前記ロギング情報に
付加して前記ネットワークを介して送信するものであ
る。

【００１９】本発明に係るマルチサーバ構成におけるシ
ステム監視情報管理装置は、前記管理手段は、受信した
前記ロギング情報の示すロギングが利用者に通知すべき
ユーザ通知ロギングである場合に、前記受信したロギン
グ情報をネットワークを介して所定のサーバに送信する
ユーザ通知送信手段、を含み、前記システムに含まれる
複数の各サーバ毎に設けられ、前記ユーザ通知送信手段
により送信されてきたロギング情報を受信し、受信した
ロギング情報を利用者に通知するユーザ通知連絡手段、
を含むのである。

【００２０】本発明に係るマルチサーバ構成におけるシ
ステム監視情報管理装置は、前記ユーザ通知送信手段
は、前記発生したロギングと、このロギングに関するロ
ギング情報の送信を行うべき１個以上のサーバと、前記
１個以上のサーバのそれぞれに割り当てられている優先
順位と、を記憶している優先記憶手段と、最も高い優先
順位が割り当てられているサーバ又はサーバ群から、順
に低い優先順位が割り当てられているサーバ又はサーバ
群にアクセスし、一番最初に見つかった稼働しているサ
ーバ又はサーバ群に対しロギング情報を送信する優先通
知手段と、を含むものである。

【００２１】本発明に係るマルチサーバ構成におけるシ
ステム監視情報管理装置は、前記システムに含まれる複
数のサーバ間における定期通信を行うために、前記各サ
ーバに設けられている所定周期毎に定期通信を行う定期
通信手段、を備え、前記ユーザ通知送信手段は、前記定
期通信手段が行う前記定期通信における通信対象である
パケット中に、前記発生したロギング情報を含めるパケ
ット形成手段、を含み、前記事象情報の対応するサーバ
への送信は、前記定期通信で使用するパケットと同一の
パケットを使用して行われるものである。

【００２２】本発明に係るマルチサーバ構成におけるシ
ステム監視情報管理装置は、前記ユーザ通知連絡手段
は、前記ユーザ通知ロギングに対して予め指定されてい
る指定プロセスを、ロギング情報の送信先であるサーバ
上で起動させる起動手段、を含むことを特徴とするもの
である。

【００２３】本発明に係るマルチサーバ構成におけるシ
ステム監視情報管理装置は、前記ユーザ通知連絡手段
は、前記ユーザ通知ロギングに対して予め指定されてい
る指定キーのメッセージの送付を、ロギング情報の送信
先であるサーバ上で行うメッセージ送付手段、を含むも
のである。

【００２４】本発明に係るマルチサーバ構成におけるシ
ステム監視情報管理装置は、前記ユーザ通知連絡手段
は、前記ユーザ通知ロギングに対して予め指定されてい
る指定ソケットへの通知を、ロギング情報の送信先であ
るサーバ上で行うソケット通知手段、を含むものであ
る。

【００２５】本発明に係るマルチサーバ構成におけるシ
ステム監視情報管理方法は、複数のサーバと、この複数
のサーバに対し共通に設けられている共通記憶手段と、
を含む構成のシステムにおいて発生した事象を管理する
マルチサーバ構成におけるシステム監視情報管理方法に
おいて、前記システムに含まれる各サーバ毎に発生した
事象を検知し、この検知した事象に関する情報である事
象情報をネットワークを介して送信する事象検知ステッ
プと、前記システムに含まれる何れかのサーバにおい
て、前記送信された事象情報を受信し、この受信した事
象情報を前記共通記憶手段に記憶する管理ステップと、
を含むものである。

【００２６】本発明に係るマルチサーバ構成におけるシ
ステム監視情報管理方法は、前記事象検知ステップは、
前記マルチサーバ構成のシステムに予め定義されている
システム事象を検知するシステム事象検知ステップと、
前記システムの利用者が定義するユーザ事象を検知する
ユーザ定義事象検知ステップと、を含むものである。

【００２７】本発明に係るマルチサーバ構成におけるシ
ステム監視情報管理方法は、前記システム事象検知ステ
ップは、前記システム事象として、ハードウェアに縮退
が生じたこと、を検知するものである。

【００２８】本発明に係るマルチサーバ構成におけるシ
ステム監視情報管理方法は、前記システム事象検知ステ
ップは、前記システム事象として、再試行が成功したこ
と、を検知するものである。

【００２９】本発明に係るマルチサーバ構成におけるシ
ステム監視情報管理方法は、前記システム事象検知ステ
ップは、前記システム事象として、機能的には障害がな
いが冗長化ハードウェアの一部に障害が発生したこと、
を検知するものである。

【００３０】本発明に係るマルチサーバ構成におけるシ
ステム監視情報管理方法は、前記管理ステップは、受信
した前記事象情報の示す事象が利用者に通知すべきユー
ザ通知事象である場合に、前記受信した事象情報をネッ
トワークを介して所定のサーバに送信するユーザ通知送
信ステップ、を含み、前記ユーザ通知送信ステップによ
り送信されてきた事象情報を前記システムに含まれる複
数の各サーバ毎に受信し、受信した事象情報を利用者に
通知するユーザ通知連絡ステップ、を含むものである。

【００３１】本発明に係るマルチサーバ構成におけるシ
ステム監視情報管理方法は、前記ユーザ通知送信ステッ
プにおいて前記事象情報の送信を失敗した場合、又は、
前記ユーザ通知連絡ステップにおいて事象情報の利用者
への通知を失敗した場合には、通知失敗事象を検知する
通知失敗検出ステップ、を含み、前記通知失敗事象は前
記ユーザ通知事象であるものである。

【００３２】本発明に係るマルチサーバ構成におけるシ
ステム監視情報管理方法は、前記ユーザ通知送信ステッ
プは、前記発生した事象と、この事象に関する事象情報
の送信を行うべき１個以上のサーバと、前記１個以上の
サーバのそれぞれに割り当てられている優先順位と、を
記憶している優先順位記憶手段を参照し、この優先順位
記憶手段中で最も高い優先順位が割り当てられているサ
ーバ又はサーバ群から、順に低い優先順位が割り当てら
れているサーバ又はサーバ群にアクセスし、一番最初に
見つかった稼働しているサーバ又はサーバ群に対し前記
事象情報の送信を行う優先通知ステップと、を含むもの
である。

【００３３】本発明に係るマルチサーバ構成におけるシ
ステム監視情報管理方法は、前記システムに含まれる複
数のサーバ間における定期通信を行うために、前記各サ
ーバに設けられており、所定周期毎に定期通信を行う定
期通信ステップ、を備え、前記ユーザ通知送信ステップ
は、前記定期通信ステップが行う前記定期通信における
通信対象であるパケット中に、前記発生した事象情報を
含めるパケット形成ステップ、を含み、前記ユーザ通知
は、前記定期通信で使用するパケットと同一のパケット
を使用して行われるものである。

【００３４】本発明に係るマルチサーバ構成におけるシ
ステム監視情報管理方法は、前記ユーザ通知連絡ステッ
プは、前記ユーザ通知事象に対して予め指定されている
指定プロセスを、事象情報の送信先であるサーバ上で起
動させる起動ステップ、を含むものである。

【００３５】本発明に係るマルチサーバ構成におけるシ
ステム監視情報管理方法は、前記ユーザ通知連絡ステッ
プは、前記ユーザ通知事象に対して予め指定されている
指定キーのメッセージの送付を、事象情報の送信先であ
るサーバ上で行うメッセージ送付ステップ、を含むもの
である。

【００３６】本発明に係るマルチサーバ構成におけるシ
ステム監視情報管理方法は、前記ユーザ通知連絡ステッ
プは、前記ユーザ通知事象に対して予め指定されている
指定ソケットへの通知を、事象情報の送信先であるサー
バ上で行うソケット通知ステップ、を含むものである。

【００３７】本発明に係るマルチサーバ構成におけるシ
ステム監視情報管理方法は、複数のサーバと、この複数
のサーバに対し共通に設けられている共通記憶手段と、
を含む構成のシステムにおいて発生したロギングを管理
するマルチサーバ構成におけるシステム監視情報管理方
法において、前記システムに含まれる各サーバ毎に設け
られ、前記各サーバ毎に発生したロギングを検知し、こ
の検知したロギング情報が前記共通記憶手段へ記憶すべ
き場合、ロギング情報をネットワークを介して送信する
ロギング検知ステップと、前記システムに含まれる何れ
かのサーバにおいて、前記送信されたロギング情報を受
信し、この受信したロギング情報を前記共通記憶手段に
記憶する管理ステップと、を含むものである。

【００３８】本発明に係るマルチサーバ構成におけるシ
ステム監視情報管理方法は、前記ロギング検知ステップ
は、ロギングを検知した時刻の情報を、前記ロギング情
報に付加して前記ネットワークを介して送信するもので
ある。

【００３９】本発明に係るマルチサーバ構成におけるシ
ステム監視情報管理方法は、前記管理ステップは、受信
した前記ロギング情報の示すロギングが利用者に通知す
べきユーザ通知ロギングである場合に、前記受信したロ
ギング情報をネットワークを介して所定のサーバに送信
するユーザ通知送信ステップ、を含み、前記ユーザ通知
送信ステップにより送信されてきたロギング情報を前記
システムに含まれる複数の各サーバ毎に受信し、受信し
たロギング情報を利用者に通知するユーザ通知連絡ステ
ップ、を含むものである。

【００４０】本発明に係るマルチサーバ構成におけるシ
ステム監視情報管理方法は、前記ユーザ通知送信ステッ
プは、前記発生したロギングと、このロギングに関する
ロギング情報の送信を行うべき１個以上のサーバと、前
記１個以上のサーバのそれぞれに割り当てられている優
先順位と、を記憶している優先順位記憶手段を参照し、
この優先順位記憶手段中で最も高い優先順位が割り当て
られているサーバ又はサーバ群から、順に低い優先順位
が割り当てられているサーバ又はサーバ群にアクセス
し、一番最初に見つかった稼働しているサーバ又はサー
バ群に対しロギング情報を送信する優先通知ステップ
と、を含むものである。

【００４１】本発明に係るマルチサーバ構成におけるシ
ステム監視情報管理方法は、前記システムに含まれる複
数のサーバ間における定期通信を行うために、前記各サ
ーバに設けられており、所定周期毎に定期通信を行う定
期通信ステップ、を備え、前記ユーザ通知送信ステップ
は、前記定期通信ステップが行う前記定期通信における
通信対象であるパケット中に、前記発生したロギング情
報を含めるパケット形成ステップ、を含み、前記ロギン
グ情報の送信の対応するサーバへの送信は、前記定期通
信で使用するパケットと同一のパケットを使用して行わ
れるものである。

【００４２】本発明に係るマルチサーバ構成におけるシ
ステム監視情報管理方法は、前記ユーザ通知連絡ステッ
プは、前記ユーザ通知ロギングに対して予め指定されて
いる指定プロセスを、ロギング情報の送信先であるサー
バ上で起動させる起動ステップ、を含むものである。

【００４３】本発明に係るマルチサーバ構成におけるシ
ステム監視情報管理方法は、前記ユーザ通知連絡ステッ
プは、前記ユーザ通知ロギングに対して予め指定されて
いる指定キーのメッセージの送付を、ロギング情報の送
信先であるサーバ上で行うメッセージ送付ステップ、を
含むものである。

【００４４】本発明に係るマルチサーバ構成におけるシ
ステム監視情報管理方法は、前記ユーザ通知連絡ステッ
プは、前記ユーザ通知ロギングに対して予め指定されて
いる指定ソケットへの通知を、ロギング情報の送信先で
あるサーバ上で行うソケット通知ステップ、を含むもの
である。

【００４５】

【発明の実施の形態】

実施の形態１．上記目的を達成するために、本発明にお
いては、まず、以下の骨格的機能を提供している。

【００４６】（１）サーバの状態やディスクの異常など
のシステム情報やユーザの定義する情報の変化を状変情
報としてマルチサーバ間でユーザに通知する機能。

【００４７】この機能は、サーバ間で共有するデータベ
ースを設けることにより実現される。サーバ状態などの
システム情報については、各情報元が提供する手段でそ
れぞれ取り込みが行われる。そして、この取り込んだ情
報は、サーバ間で共有する前記データベースにおいて一
元管理されるのである。この一元管理を行う一元管理部
は、システム情報の状態変化を検知し、各通信先サーバ
に通知要求を発行する。さらに、この通知動作が失敗し
た場合には、代替通知などのメカニズムを用いて通知の
欠損を防ぐことが好ましい。

【００４８】具体的に、状変データとは、各サーバ内で
発生するものを言い、本文では以下の種類に分類して扱
っている。

【００４９】（ａ）システム事象システム事象とは、各サーバの状態、各ディスク、各ネ
ットワーク路等のシステム共通要素の状態が変化したと
きに発生する事象を言う。例えば、サーバの立ち上がり
／停止、ディスク異常等が挙げられる。このシステム事
象の取得は、各サーバ間のパケットのやりとりや既存の
各パッケージ（アプリケーション）からのポーリングデ
ータにより行われる。

【００５０】（ｂ）ユーザ定義事象ユーザ定義事象とは、ユーザが独自に定義した事象をい
う。ユーザが事象を定義することは種々の方法で行うこ
とができるが、例えば、システムが提供する事象発生関
数をユーザのプログラム中においてコールすることによ
り、ユーザ事象を発生することが好ましい。また、特定
の割り込みを用いることも好ましい。

【００５１】尚、ユーザ定義事象の名称や、その内容
は、ユーザが自由に設定することは言うまでもない。

【００５２】各サーバで発生する状変データの内容は、
システム内で一箇所に集められる。すなわち、サーバ間
で共有されるデータベースに集められ、共通に管理され
るのである。この状変データはネットワークの何処から
でも参照でき、また、状変の発生（状態の変化が生じた
こと）は、予めユーザによって設定された方法でユーザ
に通知される。

【００５３】（２）システム共通のロギング機能を提供
し、各サーバで発生するログを複数のサーバに対して一
元的に管理する。さらに、ロギングの内容に応じて、上
記（１）と同様にユーザに所定の通知を行う機能も実現
する。各サーバにおいては、複数のログデータが存在す
るが、これらのログをシステム共通の場所に一括して格
納し、マルチサーバ間のロギング機能を実現したもので
ある。ロギングされるログの種類や内容は予めユーザが
定義することが好ましい。

【００５４】この機能は、各サーバで独自に発生したロ
グファイルを一元的に管理し、ログファイルの内容の変
更を監視することによって実現される。ログファイルの
管理は、各サーバが、発生したログ内容を、各サーバに
対して共通に設けられている管理部に通知することによ
って行われる。この通知は上記（１）で述べた代替通知
のメカニズムで行うのが好ましい。このような通知に基
づき、管理部におけいてサーバ間共通ログファイルにロ
グが蓄積されていくのである。

【００５５】また、所定のログが発生した場合に所定の
ユーザに通知がされるように設定することも好ましい。
そのような所定通知が設定されているログが蓄積された
場合には、前述したように、ユーザに所定の通知が行わ
れる。

【００５６】尚、ロギング機能自体は従来から知られて
いる技術である。しかし、システム共通のロギング機能
は、本発明において初めて提案するものである。従来
は、システム共通のロギング機能がないため、ログの集
中管理ができなかったのである。

【００５７】（３）サーバ間の低負荷通信機能を提供す
る。本発明においては、ユーザはシステムが使用する定
期的通信を利用して、通信量の増加を伴うことなく通信
を行うことができる。

【００５８】各サーバで発生するデータを一元管理する
と、状変データその他のデータをネットワークを介して
通信しなければならない。従って、一元管理を行うと、
一般的にはネットワーク上のトラフィックが増大し、ネ
ットワーク負荷の増大を招くことは必至である。

【００５９】しかし、（システム）異常などの状変（デ
ータ）は、即時に他のサーバに通知し、その異常に対す
る対応プログラムを他のサーバにおいても即時に起動す
る必要がある。そのため、ネットワーク負荷の増大をな
るべく抑制することが望ましい。

【００６０】ネットワーク負荷の増大を防ぐ工夫とし
て、緊急でない管理データについては、即時に通知する
ことを止めることが考えられる。すなわち、緊急を要さ
ない管理データなどは、内部的に定期的に行われる通信
データの一部として搭載させることにより、管理データ
のためだけの（管理データのみを載せた）パケットの通
信が行われることが無くなり、効率的な通信が実現で
き、ネットワーク負荷の増大を抑制することができる。
この定期的な通信は、一般にイベント（事象）の発生と
は非同期に行われるので、上記緊急を要さない管理デー
タは内部的に一旦バッファリングされてから、定期通信
の際にその通信データ中に載せられることになる。

【００６１】このように、本発明によれば、システムが
使用する定期的通信を利用することによって、システム
の一元管理を行う場合においても、通信量の増大を防止
することができる。

【００６２】まとめると、この機能は、サーバ間でサー
バ情報を監視するための定期的な通信に、ユーザのシス
テム情報を搭載することによって実現される。ユーザは
任意にデータの搭載／取り込みが行える。定期的な通信
を利用したため、新たに通信量の増大を伴うことがな
い。

【００６３】（４）システム監視情報として、各サーバ
の予防保全情報を管理できるようにする。さらに、予防
保全の信頼性を向上させるため、ＬＡＮの冗長化停止予
測等の情報精度の向上を図ることができる機能を設け
る。この機能は、後述するように、実際には、上記
（１）の一部として実現するのが好ましい。

【００６４】一般に、ハードウェアは、その構成を冗長
化したり、再試行を行うことによって、高信頼性を確保
している。しかし、再試行を行ったこと等はユーザには
報告されない場合もある。従って、再試行や冗長化ハー
ドウェアを用いることによってシステム異常が生じてい
てもシステム全体が停止せずに稼働しているという状態
をユーザが認識できない場合も生じていた。このよう
に、再試行などでシステム異常が生じているにもかかわ
らず、表面上システムが稼働している状況は、極めて危
険な状況といえる。このような状況は、回避することが
できない障害が発生する兆候を意味している場合も多い
と一般に言われている。

【００６５】従って、再試行や冗長化ハードウェアに関
する情報を管理（ユーザに報知）することは、事前にハ
ードウェアの劣化等による障害が発生することの予測の
精度を向上させる結果となる。そのため、事前にハード
ウェアの診断を実施するなどの、致命的な障害を回避す
るための作業を、ユーザは検討することができる。

【００６６】予防保全データとして、再試行で回避でき
たサーバ異常や、冗長化されたネットワーク情報の取得
を行うことができる。

【００６７】このように、この機能は、各サーバで、冗
長化ＬＡＮの各通信路の状態監視、その他の監視を行
い、サーバ間の予防保全性を向上させる。そして、監視
の結果をサーバ間の共有データベースに格納し、状態が
変化した時にその事象が変化した旨をユーザに通知する
のである。そのため、上述したように、本機能は、上記
（１）の機能の一部分として実現することが好ましいで
あろう。尚、本発明は、具体的には、上述した手段を有
している。

【００６８】以下、本発明の好適な実施の形態を図面に
基づいて詳細に説明する。

【００６９】実施の形態２．本実施の形態に係るマルチ
サーバ構成によるシステム監視情報管理方式が適用され
るシステムの構成図が図１に示されている。この図に示
されているように、本システムは複数のサーバ１０と、
各サーバ１０を結ぶ通信路であるネットワーク１２とを
備えている。各サーバ１０にはそれぞれローカルディス
ク１４が備えられている。また、各サーバ１０からアク
セスすることができる共用ディスク１６が備えられてい
る。

【００７０】尚、この共用ディスク１６は、本発明の共
通記憶手段に相当する。

【００７１】次に、マルチサーバ構成によるシステム監
視情報管理方式におけるソフトウェアの位置付けを説明
する。ソフトウェア構成としては、まず、各サーバ１０
に、各サーバ処理部２０、が設けられている。また、シ
ステムに含まれるいずれか１つのサーバ１０において情
報の一括管理を行うために、共用処理部２２、が備えら
れ動作している。共用処理部２２は、全てのサーバ１０
において動作できるソフトウェアであり、この共用処理
部２２が動作しているサーバ１０が何らかの障害により
停止すると、自動的に他のサーバ１０において引き続き
この共用処理部２２の動作が続行される（再起動され
る）。

【００７２】このように、本システムにおいては、各サ
ーバ１０に、各サーバ処理部２０と、共用処理部２２、
という２種類のソフトウェアが動作し得る環境となって
いる。

【００７３】尚、各サーバ処理部２０は、後述するよう
に、本発明における事象検知手段及びロギング検知手段
に相当する。又、共用処理部２２は、本発明における管
理手段に相当する。

【００７４】このようなソフトウェアの構成の説明図が
図２に示されている。また、図２には共用処理部２２が
動作していたサーバ１０が障害等により停止した場合
に、他のサーバ１０でこの共用処理部２２の処理が続行
される様子が示されている。

【００７５】なお、このようにいずれかのサーバ１０に
おいて異常が発生した場合に、そのサーバ１０で稼働し
ていたソフトウェアが他のサーバ１０で引き続き稼動す
る（再起動される）メカニズムは、既存のクラスタ管理
機構により実現することができる。このようなクラスタ
管理機構としては、例えばＨＰ社の「ＭＣ／Ｓｅｒｖｉ
ｃｅＧｕａｒｄパッケージ」などが知られている。

【００７６】以下、図３に基づき、本システムの動作の
概要を説明する。

【００７７】（１）各サーバ１０において状変やロギン
グが発生。

【００７８】各サーバ１０において、状変やロギングが
発生し、それらが一括管理の対象である場合には、共用
処理部２２へネットワーク１２を介して通知が行われ
る。

【００７９】図３に示されているように、各サーバ処理
部２０は、状変監視部２０ａと、ログ監視部２０ｂとの
２つのソフトウェアを備えている。

【００８０】尚、この状変監視部２０ａは、本発明にお
ける事象検知手段に相当する。又、ログ監視部２０ｂ
は、本発明におけるロギング検知手段に相当する。状変
監視部２０ａは、状変が生じたことを通知するメッセー
ジである状変通知をアプリケーションなどから受け取っ
たり、または自ら状変が生じたことを検知する機能を有
するソフトウェアである。また、ログ監視部２０ｂは、
ローカルログファイル２４に、エラーメッセージなどが
書き込まれたことを検知するソフトウェアである。そし
て、ログ監視部２０ｂはローカルログファイル２４への
書き込みを検知した場合には、共用処理部２２にその旨
をネットワーク１２を介して通知するのである。なお、
このローカルログファイル２４は、各サーバ１０に備え
られているローカルディスク１４内に構築されている。

【００８１】（２）共用処理部２２における一括管理。

【００８２】共用処理部２２は、共用ディスク１６の上
に、通知されてきた状変やロギングなどの一括管理情報
を蓄える。共用処理部２２は、図３に示されているよう
に状変データ共用管理部２２ａと、共有ログ管理部２２
ｂとの２つの管理ソフトウェアを備えている。状変デー
タ共用管理部２２ａは、各サーバ処理部２０の状変監視
部２０ａからの通知を受信し、その状変を状変データ共
用ファイル２６に格納する。この状変データ共用ファイ
ル２６は、共用ディスク１６内に構築される。一方、共
有ログ管理部２２ｂは、上記ログ監視部２０ｂからの通
知を受け取り、一括管理の対象であるログを共用ログフ
ァイル２８に格納する。この共用ログファイル２８も、
上記状変データ共用ファイル２６と同様に、共用ディス
ク１６の上に構築されている。

【００８３】図３に示されているように、共有処理部２
２は、ＡＰ通知管理部２２ｃというソフトウェアをも有
している。このＡＰ通知管理部２２ｃは、各サーバ処理
部２０から通知された状変やロギングが、アプリケーシ
ョン通知の対象であるか否かを判定し、通知の対象であ
れば対応するサーバ（各サーバ処理部２０）へ通知を行
う。通知された状変やロギングがアプリケーション通知
の対象であるか否かは、ＡＰ通知定義ファイルを参照し
て行う。このＡＰ通知定義ファイルとしては、図３に示
されているように状変データＡＰ通知定義ファイル３０
と、ログ情報ＡＰ通知定義ファイル３２との２種類のフ
ァイルが備えられている。この両ファイルとも共用ディ
スク１６の上に設けられている。ＡＰ通知管理部２２ｃ
は、状変データＡＰ通知定義ファイル３０を参照し、通
知された状変についてＡＰ通知が定義されている否かを
検査する。この検査の結果、ＡＰ通知が定義されている
場合にはサーバ１０の各サーバ処理部２０に対し通知を
行うのである。同様にして、ＡＰ通知管理部２２ｃは、
通知されてきたロギングについてＡＰ通知が定義されて
いるか否かをログ情報ＡＰ通知定義ファイル３２を参照
して判断する。この判断の結果ＡＰ通知の対象である場
合にはサーバ１０の各サーバ処理部２０に対し通知を行
う。勿論、この通知もネットワーク１２を介して行われ
る。

【００８４】尚、ＡＰ通知管理部２２ｃは、本発明のユ
ーザ通知送信手段に相当する。又、状変データＡＰ通知
定義ファイル３０や、ログ情報ＡＰ通知定義ファイル３
２は、本発明における優先順位記憶手段に相当する。

【００８５】（３）各サーバ１０におけるアプリケーシ
ョンへの通知。

【００８６】ＡＰ通知管理部２２ｃが各サーバ１０に対
して行った通知は、各サーバ処理部２０のＡＰ通知部２
０ｃが受け取る。このＡＰ通知部２０ｃは、各サーバ処
理部２０に含まれるソフトウェアである。このＡＰ通知
部２０ｃはアプリケーション通知を対応するアプリケー
ションに通知し、所定のアプリケーションはそれに対し
返答を返す。この返答は、ＡＰ通知管理部２２ｃに、Ａ
Ｐ通知部２０ｃがネットワーク１２を介して通知する。
ＡＰ通知管理部２２ｃはその通知の結果（正常／失敗）
に応じて代替通知などの対応措置を行う。

【００８７】尚、ＡＰ通知部２０ｃは、本発明のユーザ
通知連絡手段に相当する。

【００８８】本実施の形態において特徴的なことはいず
れか１つのサーバ１０において共用処理部２２が稼働し
ていることである。この共用処理部２２は、各サーバ１
０からの状変やロギングを集めて一括管理している。こ
のような共用処理部２２というソフトウェアをいずれか
のサーバ１０において稼働させることにより、システム
共通のロギング機能を実現し、ログの集中管理を行うこ
とができるものである。

【００８９】次に、各サーバ処理部２０の状変監視部２
０ａが取得する事象の説明を行う。図４には、状変監視
部２０ａが事象情報の検知を行う場合の動作の説明図が
示されている。本実施の形態における状変監視部２０ａ
が取得する事象には以下のものがある。

【００９０】（ａ）システム事象システム事象とは、基本システム構成要素に関する情報
である。例えば、各サーバ１０の状態、ディスク異常の
発生、異常状態からの復旧、またはネットワーク異常な
どがこのシステム事象に該当する。

【００９１】このシステム事象を検知する機能（及びこ
の機能を実現するソフトウェア）は、本発明のシステム
事象検知手段に相当する。

【００９２】具体的なシステム事象の検知方法は以下の
通りである。

【００９３】サーバ状態サーバ状態の検知は、各サーバ１０の間でパケットの定
期通信をネットワーク１２を介して行っている。そし
て、その定期通信の有無でそのサーバ１０の立ち上り、
停止を検知するのである。例えば、図４における説明図
においては、システム事象の例として表が示されてい
る。この表に示されて例においては、サーバ１の状態は
「ＵＰ」（立ち上り）であり、サーバ２の状態は「ＤＯ
ＷＮ」（停止）である。

【００９４】ディスク状態ディスク管理パッケージ４０を通じて行われるポーリン
グのデータや、このディスク管理パッケージ４０から通
知される異常発生通知などに基づいて、状変監視部２０
ａがディスク状態を検知する。なお、図４には示されて
はいないが、ユーザからの復旧指示などもディスク状態
に関する情報として検知が行われる。図４に示されてい
る例においては、システム事象の一例としてディスクの
状態が表の中に示されている。この表においてはディス
ク１の状態として「ＥＲＲＯＲ」が示されており、さら
に補足データとしてはそのエラー状態の要因や箇所が示
される。

【００９５】ネットワーク状態状変監視部２０ａは、ネットワーク管理パッケージ４２
を介してポーリングを行い、このポーリングのデータに
よりネットワークの状態を検知したり、また、このネッ
トワーク管理パッケージ４２から直接報告される異常に
基づいて、ネットワーク状態を検知する場合もある。こ
のネットワーク状態は、ネッワーク管理パッケージ４２
から報告される場合もあるが、システムのＯＳから報告
される場合もある。

【００９６】（ｂ）ユーザ定義事象ユーザ定義事象とは、ユーザが任意に定義する事象であ
る。例えば、このユーザ定義事象としては、各種機器の
状態や、アプリケーションが検知した障害情報などが該
当する。本システムにおいては、このユーザ定義事象の
発生は、アプリケーションが事象発生用関数をコールす
ることによって行われる。この事象発生用関数は、本シ
ステムにおいて予め備えられている関数である。ユーザ
はこの関数を利用することにより所望の事象を自由に定
義することができる。例えば、図４に示されている例に
おいてはユーザ定義事象の例として「重障害」や、「中
障害」、「軽障害」などが示されている。そして、この
図の例においては重障害の状態は「ＥＲＲＯＲ」であり
エラー状態であることが示されている。さらに、補足デ
ータとしては「ＤＢ異常」が示されており、データベー
スに異常が生じたことが示されている。さらに、図４の
例においてはユーザ定義事象の「軽障害」の状態が「Ｅ
ＲＲＯＲ」であり、補足データとしては「プロセス停
止」が示されている。このことにより、何らかのプロセ
スがエラーにより停止したことが示されている。

【００９７】このユーザ定義事象を検知する機能（及び
この機能を実現するソフトウェア）は、本発明のユーザ
定義事象検知手段に相当する。

【００９８】（ｃ）非同期通知事象非同期通知事象とは、ユーザ定義事象とほぼ同等の事象
であるが、特に早期の通知を必要としない事象である。
例えば、プリンタなどの周辺機器の状態や、アプリケー
ションの処理結果の統計情報などが、この非同期通知事
象に該当する。このような事象は、必ずしも迅速に通知
をする必要はない。そのため、各サーバの間で定期的に
行われる通信と合わせて通知を行うことができ、その定
期通信と合わせて通知を送ることによりネットワーク１
２上のトラフィックを減少させ、ネットワークの負荷を
減少させることができるものである。

【００９９】このように、非同期通知事象は各サーバの
間で行われる定期通知に乗せられる低負荷通信によっ
て、その事象の発生とは非同期に一括管理が行われるの
である。

【０１００】この非同期通知事象の発生は低負荷通信専
用の事象発生関数をユーザがコールすることにより行わ
れる。上記ユーザ定義事象と同様に、この低負荷通信専
用の事象発生関数も、本システムにおいて予め備えられ
ている関数である。ユーザはこの関数を利用することに
よりネットワーク負荷を増やすことなく、事象の一括管
理を行うことができる。

【０１０１】（ｄ）予防保全事象予防保全事象とは、サーバ１０自身のエラー（ＣＰＵの
１ビット誤りなどの再試行で解消したエラー）や、冗長
化ネットワークの縮退情報などのいわゆる予防保全デー
タを管理する事象である。

【０１０２】これらの予防保全データを管理するデータ
は、本発明のハードウェアに縮退が生じたこと、再試行
が成功したこと、機能的には障害がないが冗長化ハード
ウェアの一部に障害が発生したこと、に相当する。

【０１０３】この予防保全事象の取得は、例えば以下の
ように行われる。

【０１０４】サーバ情報サーバ情報とは、ＯＳからの通知により取得される情報
である。図４においては、ＯＳからの通知によりサーバ
１状態が「ＥＲＲＯＲ」であることが示されている。ま
た、これについての補足データとしては「１ビット誤
り」が示されており、ＣＰＵの１ビット誤りが再試行で
解消したエラーであることが示されている。

【０１０５】ネットワーク情報ネットワーク情報とは、ネットワーク管理パッケージ４
２からのポーリングデータにより取得される情報であ
る。図４に示されている例においては、予防保全事象の
１つとしてネットワーク縮退の情報が示されている。こ
こに示されている例においては、ネットワーク縮退の状
態が「ＥＲＲＯＲ」であり、その補足データは「カード
１エラー」であることが示されており、ネットワークカ
ードが１枚エラー状態になったことを表している。この
ネットワークのカードがエラー状態となったことによ
り、ネットワークの縮退が行われていることが示されて
いる。状変データ共用管理部２２ａ（図３参照）は、各
サーバ１０から通知される事象を、状変データ共用ファ
イル２６に格納する。この際、上記サーバ異常などは、
複数のサーバが定期通信により検出するため、複数のサ
ーバからそれぞれ事象として報告がなされる。従って、
複数の通知に対して、その都度アプリケーション通知を
行うことになるが、同じアプリケーション通知が複数回
行われるのは好ましくない場合が多い。そこで、本実施
の形態においては、各事象に対して重複通知可否を定義
情報として設定する。そして、状変データ共用管理部２
２ａは、重複通知否と定義されている事象に対し、その
事象が検出された場合には、その事象の「状態／補足デ
ータ」が同一の事象について既にアプリケーション通知
を行っているときは、共用ファイル更新／アプリケーシ
ョン通知の新たな動作をスキップして行わないようにす
る。このような状変データ共用管理部２２ａの動作を表
すフローチャートが図４の説明図に含まれている。この
フローチャートに示されているように、情報データ共用
管理部２２ａにおいては、状変監視部２０ａからの通知
がなされると、その通知で示されている事象データの読
み込みを行う（ステップＳ４−１）。次に、読み込んだ
事象データが重複通知ができる事象であるか否かが検査
される（ステップＳ４−２）。この検査の結果、重複通
知ができる事象である場合にはステップＳ４−４に処理
が移行する。

【０１０６】一方、重複通知ができる事象でない場合に
はステップＳ４−３に処理が移行し、事象データが同一
である通知が既に行われたか否かが検査される。この検
査の結果、事象データが同一のものであると判断される
場合には、重複通知を回避すべく、次のステップＳ４−
４やステップＳ４−５における更新処理通知処理などは
スキップされる。

【０１０７】ステップＳ４−３において事象データが同
一でないと判断される場合には、重複通知ではないと判
断し、ステップＳ４−４において事象の更新が行われ
る。この更新は、状変データ共用ファイル２６内の状変
データを更新することにより行われる。次に、ステップ
Ｓ４−５においてアプリケーション通知要求の処理が行
われる。この処理によって、ＡＰ通知管理部２２ｃから
各サーバ１０に対し所定の通知が行われる。

【０１０８】なお、図４に示されている例においてはシ
ステム事象の例としてサーバ状態やディスク状態が挙げ
られているが、その他にアプリケーション通知が失敗す
る事象など種々の事象を定義することができる。

【０１０９】次に、本システムにおけるログの管理方式
を説明する。各サーバ１０において発生するログは、以
下のような処理により、共用ログファイル２８に蓄えら
れる。このようなログ監視部２０ｂの動作の説明図が図
５に示されている。又、ログ監視部２０ｂの動作を表す
フローチャートが図６に示されている。以下、これら図
５及び図６に基づいて動作を説明する。

【０１１０】（ａ）各サーバ１０のログ監視部２０ｂ
は、定期的に監視対象となっているローカルログファイ
ル２４の更新日付を監視する（ステップＳ６−１）。一
方、このローカルログファイル２４に対するログの書き
込みは各パッケージ（ソフトウェア）がシステム関数な
どを利用してログを書き込む。

【０１１１】（ｂ）ログ監視部２０ｂは、ローカルログ
ファイル２４の日付が更新されていることを検知すると
（ステップＳ６−２）、書き込みが行われたと判断し、
その書き込まれたログを読み込み（ステップＳ６−
３）、一括管理の対象とすべきログ（ユーザにより指定
される）であるか否かを検査し（ステップＳ６−４）、
一括管理すべきログである場合にはそのログを取り出す
（ステップＳ６−５）。

【０１１２】（ｃ）上記取り出したログを、共有ログ管
理部２２ｂへ、ネットワーク１２を介して通知し（ステ
ップＳ６−５）、次回のチェックに備え更新日付、ロブ
読み込み箇所のセーブを行う（ステップＳ６−６）。

【０１１３】（ｄ）共有ログ管理部２２ｂは、通知され
たログを共用ログファイル２８へ発生順に蓄積する。

【０１１４】（ｅ）なお、共有ログ管理部２２ｂは、蓄
積したログが（ユーザが定義した）アプリケーション通
知すべきログであれば、ＡＰ通知管理部２２ｃに対しア
プリケーション通知の依頼を行う。

【０１１５】（ｆ）ＡＰ通知管理部２２ｃは、上記依頼
に基づき、指定された通知先にログが発生したことを通
知する。

【０１１６】このように、本実施の形態においては、シ
ステムに共通のロギング機能を提供したため、ログの集
中管理を実現している。さらに、ログが発生したことを
自動的に指定のサーバ１０に通知することができるた
め、システムの管理が容易となる。

【０１１７】本実施の形態においては、ログ監視部２０
ｂは、上記動作を行っているが、このような監視動作
は、図６に示されたフローチャートの動作以外にも種々
のものが知られており、本システムにおいても、図６以
外の種々の手法を採用することができる。

【０１１８】次に、検知した事象を所定のサーバ１０の
アプリケーションに通知する動作について図７及び図８
に基づいて説明する。

【０１１９】所定のサーバ１０におけるアプリケーショ
ンに事象を通知する動作は、以下のような流れにより行
われる。

【０１２０】（１）共用処理部２２のＡＰ通知管理部２
２ｃは、まずアプリケーション通知をすべき事象または
ログの通知を受け取る。アプリケーション通知すべき事
象であるか否かは、状変データＡＰ通知定義ファイル３
０を参照することにより、このファイル中に通知を受け
た事象が登録されているか否かを検査することにより判
断される。また、アプリケーション通知すべきログであ
るか否かは、ログ情報ＡＰ通知定義ファイル３２を参照
することにより、事象の場合と同様に判断される（ステ
ップＳ７−１）。状変データＡＰ通知定義ファイル３０
の内容の説明図が図８に示されている。この図に示され
ているように、ある１つの状変に対し、報告先となるサ
ーバを複数登録することができる。これら複数のサーバ
１０に対しては、プライオリティーが定められている。
例えば、図８中のサーバ１、２、３にはプライオリティ
ー「１」が設定されており、サーバ４にはプライオリテ
ィー「２」が設定されている。また、サーバ５と６には
プライオリティー「３」が設定されている。本文におい
ては、プライオリティー「１」が設定されているサーバ
群を第１報告先と呼ぶ。また、プライオリティー「２」
が設定されているサーバ群を第２報告先（以下同様）と
呼ぶ。また、図８に示されているように、各サーバ１０
毎に通知のための手順と通知先のアプリケーションがそ
れぞれ登録されている。図８においては、状変データＡ
Ｐ通知定義ファイル３０の説明図が示されているが、ロ
グ情報ＡＰ通知定義ファイル３２もほぼ同様の構成をな
している。

【０１２１】（２）ＡＰ通知管理部２２ｃはまず第１報
告先のサーバに対し処理を行う。このため、ＡＰ通知管
理部２２ｃは第１報告先であるサーバを取得する（ステ
ップＳ７−２）。ある状変に対し、その状変を報告する
サーバが設定されている場合には、その第１報告先であ
るサーバが停止中であるか否かの検査が行われる（ステ
ップＳ７−３）。この検査の結果、第１報告先のサーバ
１０がいずれも停止中であれば、ステップＳ７−８に処
理が移行し、第２報告先、すなわちプライオリティーが
「２」であるサーバ（群）があるか否かの検査が行われ
る。

【０１２２】また、報告をすべきサーバが全く定義され
ていない場合には、報告先のサーバは自サーバ（そのＡ
Ｐ通知管理部２２ｃを含む共用処理部２２が現在稼働し
ているサーバ）が報告先のサーバであると見なす。

【０１２３】（３）次に、ステップＳ７−４において報
告先のサーバに対し事象の通知を行う。この通知は、通
知要領、データを報告先サーバに通知をすることにより
行われる。この通知を行った後、ＡＰ通知管理部２２ｃ
は、その報告先サーバからの応答を待つ待ち状態に移行
する。

【０１２４】（４）報告先サーバにおいては、そのＡＰ
通知部２０ｃが通知された要求に基づき、所定の処理を
行う。ＡＰ通知部２０ｃは、通知の内容に応じて、以下
に述べるような方法でアプリケーションに通知を行う。
なお、その事象が状変の場合には、その事象名と状態と
補足データとがアプリケーションに通知され、その事象
がログである場合には、ログイメージがアプリケーショ
ンに通知される。

【０１２５】（ａ）プロセスの起動アプリケーション通知の第１の方法は、プロセスまたは
プロシジャを起動することである。指定されたプロセス
やプロシジャの起動を行い、この起動が正常に終了した
場合にはアプリケーションへの通知が正常に終了したこ
とになる。

【０１２６】尚、このプロセスの起動を行うＡＰ通知部
２０ｃの機能は、本発明における起動手段に相当する。

【０１２７】（ｂ）指定メッセージ送付アプリケーション通知を行う第２の方法は、指定キーに
対するメッセージをセンドすることである。このメッセ
ージセンドが正常に行うことができれば、アプリケーシ
ョン通知は正常終了となる。なお、この場合受信プロセ
スは、その指定キーでレシーブ待ちの状態にあり、セン
ドされてきたメッセージを受け取るのである。

【０１２８】尚、このメッセージをセンドするＡＰ通知
部２０ｃの機能は、本発明におけるメッセージ送付手段
に相当する。

【０１２９】（ｃ）ネットワークソケットに送付アプリケーション通知を行う第３の方法は、指定された
ソケットに所定のメッセージを送付することである。こ
の送付が正常に終了したことにより、アプリケーション
通知が正常終了したことになる。

【０１３０】尚、このソケットに所定のメッセージを送
付するＡＰ通知部２０ｃの機能は、本発明におけるソケ
ット通知手段に相当する。

【０１３１】図７に示されているように、ステップＳ７
−１４においてＡＰ通知部２０ｃはアプリケーション通
知が正常に終了したか否かを検査する。このように、図
７にはＡＰ通知部２０ｃの動作を表すフローチャートが
示されている。そして、正常に終了した場合にはステッ
プＳ７−１５を介して、ステップＳ７−１７に処理が移
行し、このステップＳ７−１７において正常に終了した
旨がＡＰ通知管理部２２ｃに通知される。

【０１３２】一方、アプリケーション通知が正常に終了
しなかった場合には、ステップＳ７−１６を介して、ス
テップＳ７−１７に処理が移行し、このステップＳ７−
１７において異常終了した旨がＡＰ通知管理部２２ｃに
通知される。

【０１３３】（５）ＡＰ通知管理部２２ｃは、ステップ
Ｓ７−１７においてＡＰ通知部２０ｃが通知した結果
を、受信する。ステップＳ７−５において結果の通知が
あるか否かが検査され、ない場合にはこのステップＳ７
−５において待ち状態を続行する。結果の通知があった
場合には次のステップＳ７−６に処理が移行する。一
方、所定の時間が経過しても結果の通知がこない場合に
は時間監視オーバーとしてステップＳ７−８に処理が移
行する。

【０１３４】結果の通知が所定の時間内になされ、ステ
ップＳ７−６においてアプリケーション通知が正常終了
したことが確認された場合にはステップＳ７−７におい
てアプリケーション通知が正常に完了する。

【０１３５】一方、ステップＳ７−６において正常終了
ではない場合や、ステップＳ７−５において所定時間を
経過しても通知がこなかった場合などにおいてはオルタ
ネート処理がステップＳ７−８において行われる。この
オルタネート処理は、次のプライオリティーを有するサ
ーバ１０（群）に対し報告を開始する処理である。例え
ば、現在は第１報告先であるサーバに対し通知を行った
ため、次のプライオリティーを有するサーバ１０（群）
は第２報告先サーバとなる。

【０１３６】ステップＳ７−８において次のオルタネー
ト通知先（次のプライオリティーを有するサーバ１０
（群）があるか否かが検査される。この検査の結果、次
のプライオリティーの値を有するサーバ１０（群）があ
る場合にはこの次のプライオリティーを有するサーバ１
０群（これを、本文ではネクスト報告先と呼ぶ）をステ
ップＳ７−９において取り出す。そして、この取り出さ
れたネクスト報告先に対し第１報告先と同様の処理が繰
り返されるのである。例えば、図８に示される例におい
ては、第１報告先であるサーバ１０（群）は、サーバ
１、２、３であり、第２報告先のサーバ１０（群）はサ
ーバ４のみである。

【０１３７】ステップＳ７−８において次のオルタネー
ト通知先がないと判断されればステップＳ７−１０にお
いて通知事象として通知失敗事象を処理していたか否か
の検査が行われる。報告しようとする対象が通知が失敗
したという事象でない場合にはステップＳ７−１１に処
理が移行し、新たに報告すべき事象として通知失敗を定
義し、上記ステップＳ７−２に処理が移行し、検知され
た事象の報告が行われる。すなわち、ディスク異常など
の異常状態を通知しようとした場合には、その通知が失
敗した場合にはステップＳ７−１１において、今度は報
告すべき事象として通知失敗が定義され、この通知失敗
事象の報告が新たになされるのである。

【０１３８】（６）一方、ステップＳ７−１０において
報告すべき事象が通知失敗事象である場合にはステップ
Ｓ７−１２において異常終了となる。これは、例えばデ
ィスク異常などの事象を通知する際に、その通知が失敗
しステップＳ７−１１を介してこの通知失敗事象の通知
が行われている際に、再びその通知失敗事象が検知され
た場合であるため、いわば通知失敗が２度検知されたこ
とになる。この場合にも、係る新たな通知失敗事象を報
告したのでは処理が終了しなくなる場合もあるため、通
知失敗の報告の最中に再び通知失敗が検知された場合に
はステップＳ７−１２において異常終了とすることにし
たのである。

【０１３９】さて、本実施の形態においては状変監視部
２０ａが状変を検知した場合や、外部から状変が通知さ
れてきた場合には、この状変があった旨を共用処理部２
２の状変データ共用管理部２２ａに通知する。また、ロ
グ監視部２０ｂと共有ログ管理部２２ｂも同様の関係に
立つ。

【０１４０】実施の形態３．さて、状変が通知された
り、またはログが書き込まれる度にその都度ネットワー
クを介して通知が行われと、ネットワーク上のトラフィ
ックが増え、いわゆる負荷が重くなってしまう場合も想
定される。

【０１４１】そこで、本実施の形態においては通知の緊
急性が低いものについては、定期通信を利用することに
よりネットワークの負荷を増大させない低負荷通信を採
用している。この低負荷通信を実現するため、本実施の
形態においては非同期通信を利用するものである。

【０１４２】非同期通信は、緊急性の低い状変に対しそ
の通知の要求を待たせておき、このマルチサーバシステ
ムの内部で行われている定期通信（サーバ１０の間の状
態監視などの定期情報交換）のタイミングを利用し、こ
の定期通信の通信データに状変を通知するためのデータ
を付加し、受信側が定期通信によるデータを受信した場
合に、中に付加されているデータを取り出し、定期通信
のデータと状変通知のデータに分離するものを言う。

【０１４３】この非同期通信の説明図が図９に示されて
いる。図９（定期通信利用なしの場合）に示されている
ように、定期通信を利用しない場合には状変がある場合
に各サーバ処理部２０の状変監視部２０ａは状変通知を
共用処理部２２に通知する。これは、状変通知がある毎
に、またログの書き込みが行われる毎にそれぞれ行われ
る。また各状変通知がアプリケーション通知を伴うもの
である場合には、各状変通知毎にＡＰ通知管理部２２ｃ
がそれぞれ各サーバ処理部２０に対し通知を行う。

【０１４４】これに対し、本実施の形態において採用し
ている通信方法によれば、図９（定期通信利用ありの場
合）に示されているように状変通知などがあった場合に
もこの通知要求は一旦状変監視部２０ａにおいて蓄積さ
れるのである。すなわち、図９（定期通信利用ありの場
合）に示されているように「要求データ１」や「要求デ
ータ２」などは緊急度の低いデータである。従って、一
旦状変監視部２０ａに蓄積されるのである。そして、定
期データ送信が発生した場合、例えば図４における「他
サーバとの定期通信」などを行う場合に、状変監視部２
０ａはこの定期データ送信のパケットの中に要求データ
１や要求データ２を埋め込んで１つのパケットを作成す
るのである。

【０１４５】尚、この状変監視部２０ａは、本発明のパ
ケット形成手段に相当する。

【０１４６】又、例えばこのパケットの大きさとしては
４ｋバイト程度の大きさである場合が多いが、これに対
して定期データ送信の内容の大きさは、図４において説
明したように、他のサーバの状態などであり数１０バイ
ト程度のデータ量である。従って、この定期通信に用い
られるパケットはその内部に空きが多いのが一般的であ
る。そこで、本実施の形態においては状変通知などにお
ける要求データを定期通信に用いられるパケットの中に
含めることができたものである。この要求データの大き
さは状変の名称とその補足データ（図４に示されている
表参照）その他のデータとを合わせた程度の大きさであ
るため、一般には２５６バイト程度のものとなると考え
られる。そのため、例えばそのシステムにおいて用いら
れているパケットの大きさが４ｋバイト程度である場合
には定期データと共に要求データを数個程度含めること
ができる。

【０１４７】このようにして、状変監視部２０ａにおい
ては緊急度の低い状変通知のデータを、一旦その状変監
視部２０ａの内部に記憶しておき、定期通信が発生した
時にその定期通信のパケットの中に蓄積しておいたデー
タを含めてパケットを作成した。そのため、ネットワー
ク上を流れるパケットの総数を減らすことができ、ネッ
トワーク負荷の減少を図ることができるものである。

【０１４８】このように、定期データだけでなく要求デ
ータをも含めたパケットが状変データ共用管理部２２ａ
に送信されると、この状変データ共用管理部２２ａはパ
ケットの中に含まれる管理ラベルに従って定期データ
と、その他の要求データとを分離する。すなわち、定期
通信に用いられるパケットの中の要求データの格納情報
は、このパケットに含まれる管理ラベルに書き込まれて
いるのである。この管理ラベルを参照することにより、
図９に示されているように定期データの他に要求データ
１や要求データ２が含まれていることを確認でき、各デ
ータに分離することができるのである。分離された後
は、通常の状変データ通知によって通知された要求デー
タと同様の取扱いをすることができる。

【０１４９】なお、定期データ送信の周期の間に、状変
通知が数多く発生した場合には、状変監視部に蓄積して
いる要求データの個数が増え、そのデータの総量が定期
通信パケットのパケットサイズを越える場合も考えられ
る。このような場合には、以下のような手法により対応
することが考えられる。

【０１５０】（１）一旦送付定期通信パケットのパケットサイズに達した時点におい
て、その状変監視部２０ａに蓄積されている要求データ
をまとめて１つの定期パケットを作成し、定期通信を行
ってしまう。すなわち、状変通知が短時間に多数発生し
てしまった場合には定期通信を繰り上げて行ってしまう
のである。

【０１５１】（２）要求待ちパケットサイズを越えて、状変通知が発生した場合に
は、状変監視部には定期パケットの容量以上の要求デー
タが蓄積されている。定期データの送信のタイミングに
おいて、状変監視部２０ａは定期パケットに格納できる
だけの要求データを用いて定期パケットを作成し、残り
の要求データについては次回の定期データ送信に回すの
である。これは、本文では「要求待ち」と呼ぶ。すなわ
ち、定期パケットに格納できなかったものについてはさ
らにそのまた次の定期データ送信の際の定期パケットに
含めようとするものである。

【０１５２】このように、本実施の形態における非同期
通信によれば緊急度の低い状変通知については定期デー
タ送信と共に送ったので、ネットワーク負荷の増大を防
止することができる。

【０１５３】

【発明の効果】以上述べたように、本発明によれば、共
通記憶手段上に各サーバで発生する事象情報を集約して
記憶したため、マルチサーバシステムを効率よく管理で
きる管理装置が得られる。

【０１５４】本発明によれば、利用者が検知する事象を
自由に定義できるため、利用者の利便性に富む管理装置
が得られる。

【０１５５】本発明によれば、ハードウェアに縮退が生
じたことを検知することができる管理装置が得られる。

【０１５６】本発明によれば、再試行を検知できる管理
装置が得られる。

【０１５７】本発明によれば、冗長化ハードウェアの一
部に異常が生じたことを検知できる管理装置が得られ
る。

【０１５８】本発明によれば、検知した事象に関する情
報を利用者に伝えることができる管理装置が得られる。

【０１５９】本発明によれば、利用者に対する通知が失
敗したことを所定の利用者に通知することができる管理
装置が得られる。

【０１６０】本発明によれば、優先順位を考慮した事象
の通知ができる管理装置が得られる。

【０１６１】本発明によれば定期通信を利用して事象の
通知を行うのでネットワークの負荷を増大させることが
ない管理装置が得られる。

【０１６２】本発明によれば、指定プロセスの起動によ
り、事象に関する情報をユーザに通知することができる
管理装置が得られる。

【０１６３】本発明によれば、指定キーのメッセージの
送付により、事象に関する情報をユーザに通知すること
ができる管理装置が得られる。

【０１６４】本発明によれば、指定ソケットへの通知に
より、事象に関する情報をユーザに通知することができ
る管理装置が得られる。

【０１６５】又、本発明によれば、共通記憶手段上に各
サーバで発生するロギング情報を集約して記憶したた
め、マルチサーバシステムを効率よく管理できる管理装
置が得られる。

【０１６６】本発明によれば、ロギングが発生した時刻
を知ることができる管理装置が得られる。

【０１６７】本発明によれば、検知したロギングに関す
る情報を利用者に伝えることができる管理装置が得られ
る。

【０１６８】本発明によれば、優先順位を考慮したロギ
ングに関する情報の通知ができる管理装置が得られる。

【０１６９】本発明によれば定期通信を利用してロギン
グに関する情報の通知を行うのでネットワークの負荷を
増大させることのない管理装置が得られる。

【０１７０】本発明によれば、指定プロセスの起動によ
り、ロギングが生じたことをユーザに通知することがで
きる管理装置が得られる。

【０１７１】本発明によれば、指定キーのメッセージの
送付により、ロギングが生じたことをユーザに通知する
ことができる管理装置が得られる。

【０１７２】本発明によれば、指定ソケットへの通知に
より、ロギングが生じたことをユーザに通知することが
できる管理装置が得られる。

【０１７３】本発明によれば、共通記憶手段上に各サー
バの事象情報を集約して記憶したため、マルチサーバシ
ステムを効率よく管理できる管理方法が得られる。

【０１７４】本発明によれば、利用者が検知する事象を
自由に定義できるため、利用者の利便性に富む管理方法
が得られる。

【０１７５】本発明によれば、ハードウェアに縮退が生
じたことを検知することができる管理方法が得られる。

【０１７６】本発明によれば、再試行を検知できる管理
方法が得られる。

【０１７７】本発明によれば、冗長化ハードウェアの一
部に異常が生じたことを検知できる管理方法が得られ
る。

【０１７８】本発明によれば、検知した事象に関する情
報を利用者に伝えることができる管理方法が得られる。

【０１７９】本発明によれば、利用者に対する通知が失
敗したことを所定の利用者に通知することができる管理
方法が得られる。

【０１８０】本発明によれば、優先順位を考慮した事象
の通知ができる管理方法が得られる。

【０１８１】本発明によれば定期通信を利用して事象の
通知を行うのでネットワークの負荷を増大させることが
ない管理方法が得られる。

【０１８２】本発明によれば、指定プロセスの起動によ
り、事象に関する情報をユーザに通知することができる
管理方法が得られる。

【０１８３】本発明によれば、指定キーのメッセージの
送付により、事象に関する情報をユーザに通知すること
ができる管理方法が得られる。

【０１８４】本発明によれば、指定ソケットへの通知に
より、事象に関する情報をユーザに通知することができ
る管理方法が得られる。

【０１８５】又、本発明によれば、共通記憶手段上に各
サーバのロギング情報を集約して記憶したため、マルチ
サーバシステムを効率よく管理できる管理方法が得られ
る。

【０１８６】本発明によれば、ロギングが発生した時刻
を知ることができる管理方法が得られる。

【０１８７】本発明によれば、検知したロギングに関す
る情報を利用者に伝えることができる管理方法が得られ
る。

【０１８８】本発明によれば、優先順位を考慮したロギ
ングに関する情報の通知ができる管理方法が得られる。

【０１８９】本発明によれば定期通信を利用してロギン
グに関する情報の通知を行うのでネットワークの負荷を
増大させることのない管理方法が得られる。

【０１９０】本発明によれば、指定プロセスの起動によ
り、ロギングが生じたことをユーザに通知することがで
きる管理方法が得られる。

【０１９１】本発明によれば、指定キーのメッセージの
送付により、ロギングが生じたことをユーザに通知する
ことができる管理方法が得られる。

【０１９２】本発明によれば、指定ソケットへの通知に
より、ロギングが生じたことをユーザに通知することが
できる管理方法が得られる。

【図面の簡単な説明】

【図１】本実施の形態に係るマルチサーバ構成による
システム監視情報管理方式が適用されるシステムの構成
図である。

【図２】本実施の形態において用いられるソフトウェ
アの構成の説明図である。

【図３】本実施の形態において用いられる各ソフトウ
ェアの動作の流れを表す説明図である。

【図４】状変監視部が事象情報の検知を行う場合の動
作の説明図である。

【図５】ログ監視部の動作の説明図である。

【図６】ログ監視部の動作を表すフローチャートであ
る。

【図７】ＡＰ通知部２０ｃの動作を表すフローチャー
トである。

【図８】状変データＡＰ通知定義ファイルの説明図で
ある。

【図９】非同期通信の説明図である。

【符号の説明】

１０サーバ、１２ネットワーク、１４ローカルデ
ィスク、１６共用ディスク、２０サーバ処理部、２
０ａ状変監視部、２０ｂログ監視部、２２ｃ共用
処理部、２２ａデータ共用管理部、２２ｂ共有ログ
管理部、２２ｃＡＰ通知管理部、２４ローカルログフ
ァイル、２６状変データ共用ファイル、２８共用ロ
グファイル、３０ＡＰ通知定義ファイル、３２ログ
ＡＰ通知定義ファイル、４０ディスク管理パッケー
ジ、４２ネットワーク管理パッケージ。

Claims

【特許請求の範囲】

【請求項１】複数のサーバを含む構成のシステムにお
いて発生した事象を管理するマルチサーバ構成における
システム監視情報管理装置において、前記システムに含まれる複数のサーバに対し共通に設け
られている共通記憶手段と、前記システムに含まれる各サーバ毎に設けられ、前記各
サーバ毎に発生した事象を検知し、この検知した事象に
関する情報である事象情報をネットワークを介して送信
する事象検知手段と、前記システムに含まれる何れかのサーバに設けられ、前
記送信された事象情報を受信し、この受信した事象情報
を前記共通記憶手段に記憶する管理手段と、を含むことを特徴とするマルチサーバ構成におけるシス
テム監視情報管理装置。
【請求項２】前記事象検知手段は、前記マルチサーバ構成のシステムに予め定義されている
システム事象を検知するシステム事象検知手段と、前記システムの利用者が定義するユーザ事象を検知する
ユーザ定義事象検知手段と、を含むことを特徴とする請求項１記載のマルチサーバ構
成におけるシステム監視情報管理装置。
【請求項３】前記システム事象検知手段は、前記シス
テム事象として、ハードウェアに縮退が生じたこと、を
検知することを特徴とする請求項２記載のマルチサーバ
構成におけるシステム監視情報管理装置。
【請求項４】前記システム事象検知手段は、前記シス
テム事象として、再試行が成功したこと、を検知するこ
とを特徴とする請求項２記載のマルチサーバ構成におけ
るシステム監視情報管理装置。
【請求項５】前記システム事象検知手段は、前記シス
テム事象として、機能的には障害がないが冗長化ハード
ウェアの一部に障害が発生したこと、を検知することを
特徴とする請求項２記載のマルチサーバ構成におけるシ
ステム監視情報管理装置。
【請求項６】前記管理手段は、受信した前記事象情報の示す事象が利用者に通知すべき
ユーザ通知事象である場合に、前記受信した事象情報を
ネットワークを介して所定のサーバに送信するユーザ通
知送信手段、を含み、前記システムに含まれる複数の各サーバ毎に設けられ、
前記ユーザ通知送信手段により送信されてきた事象情報
を受信し、受信した事象情報を利用者に通知するユーザ
通知連絡手段、を含むことを特徴とする請求項１又は２記載のマルチサ
ーバ構成におけるシステム監視情報管理装置。
【請求項７】前記ユーザ通知送信手段が前記事象情報
の送信を失敗した場合、又は、前記ユーザ通知連絡手段
が事象情報の利用者への通知を失敗した場合には、通知
失敗事象を前記管理手段に送信する通知失敗検出手段、を含み、前記通知失敗事象は前記ユーザ通知事象である
ことを特徴とする請求項６記載のマルチサーバ構成にお
けるシステム監視情報管理装置。
【請求項８】前記ユーザ通知送信手段は、前記発生した事象と、この事象に関する事象情報の送信
を行うべき１個以上のサーバと、前記１個以上のサーバ
のそれぞれに割り当てられている優先順位と、を記憶し
ている優先順位記憶手段と、前記、優先順位記憶手段の記憶内容を参照し、この優先
順位記憶手段中で最も高い優先順位が割り当てられてい
るサーバ又はサーバ群から、順に低い優先順位が割り当
てられているサーバ又はサーバ群にアクセスし、一番最
初に見つかった稼働しているサーバ又はサーバ群に対し
前記事象情報の送信を行う優先通知手段と、を含むことを特徴とする請求項６記載のマルチサーバ構
成におけるシステム監視情報管理装置。
【請求項９】前記システムに含まれる複数のサーバ間
における定期通信を行うために、前記各サーバに設けら
れている所定周期毎に定期通信を行う定期通信手段、を備え、前記ユーザ通知送信手段は、前記定期通信手段が行う前記定期通信における通信対象
であるパケット中に、前記発生した事象情報を含めるパ
ケット形成手段、を含み、前記ユーザ通知は、前記定期通信で使用するパ
ケットと同一のパケットを使用して行われることを特徴
とする請求項６記載のマルチサーバ構成におけるシステ
ム監視情報管理装置。
【請求項１０】前記ユーザ通知連絡手段は、前記ユーザ通知事象に対して予め指定されている指定プ
ロセスを、事象情報の送信先であるサーバ上で起動させ
る起動手段、を含むことを特徴とする請求項６、７、８又は９記載の
マルチサーバ構成におけるシステム監視情報管理装置。
【請求項１１】前記ユーザ通知連絡手段は、前記ユーザ通知事象に対して予め指定されている指定キ
ーのメッセージの送付を、事象情報の送信先であるサー
バ上で行うメッセージ送付手段、を含むことを特徴とする請求項６、７、８又は９記載の
マルチサーバ構成におけるシステム監視情報管理装置。
【請求項１２】前記ユーザ通知連絡手段は、前記ユーザ通知事象に対して予め指定されている指定ソ
ケットへの通知を、事象情報の送信先であるサーバ上で
行うソケット通知手段、を含むことを特徴とする請求項６、７、８又は９記載の
マルチサーバ構成におけるシステム監視情報管理装置。
【請求項１３】複数のサーバを含む構成のシステムに
おいて発生したロギングを管理するマルチサーバ構成に
おけるシステム監視情報管理装置において、前記システムに含まれる複数のサーバに対し共通に設け
られている共通記憶手段と、前記システムに含まれる各サーバ毎に設けられ、前記各
サーバ毎に発生したロギングを検知し、この検知したロ
ギング情報が共通記憶手段に記憶すべきロギングの場
合、ロギング情報をネットワークを介して送信するロギ
ング検知手段と、前記システムに含まれる何れかのサーバに設けられ、前
記送信されたロギング情報を受信し、この受信したロギ
ング情報を前記共通記憶手段に記憶する管理手段と、を含むことを特徴とするマルチサーバ構成におけるシス
テム監視情報管理装置。
【請求項１４】前記ロギング検知手段は、ロギングを
検知した時刻の情報を、前記ロギング情報に付加して前
記ネットワークを介して送信することを特徴とする請求
項１３記載のマルチサーバ構成におけるシステム監視情
報管理装置。
【請求項１５】前記管理手段は、受信した前記ロギング情報の示すロギングが利用者に通
知すべきユーザ通知ロギングである場合に、前記受信し
たロギング情報をネットワークを介して所定のサーバに
送信するユーザ通知送信手段、を含み、前記システムに含まれる複数の各サーバ毎に設けられ、
前記ユーザ通知送信手段により送信されてきたロギング
情報を受信し、受信したロギング情報を利用者に通知す
るユーザ通知連絡手段、を含むことを特徴とする請求項１３又は１４記載のマル
チサーバ構成におけるシステム監視情報管理装置。
【請求項１６】前記ユーザ通知送信手段は、前記発生したロギングと、このロギングに関するロギン
グ情報の送信を行うべき１個以上のサーバと、前記１個
以上のサーバのそれぞれに割り当てられている優先順位
と、を記憶している優先順位記憶手段と、前記優先順位記憶手段を参照することにより、この優先
順位記憶手段中で最も高い優先順位が割り当てられてい
るサーバ又はサーバ群から、順に低い優先順位が割り当
てられているサーバ又はサーバ群にアクセスし、一番最
初に見つかった稼働しているサーバ又はサーバ群に対し
ロギング情報を送信する優先通知手段と、を含むことを特徴とする請求項１５記載のマルチサーバ
構成におけるシステム監視情報管理装置。
【請求項１７】前記システムに含まれる複数のサーバ
間における定期通信を行うために、前記各サーバに設け
られている所定周期毎に定期通信を行う定期通信手段、を備え、前記ユーザ通知送信手段は、前記定期通信手段が行う前記定期通信における通信対象
であるパケット中に、前記発生したロギング情報を含め
るパケット形成手段、を含み、前記事象情報の対応するサーバへの送信は、前
記定期通信で使用するパケットと同一のパケットを使用
して行われることを特徴とする請求項１５記載のマルチ
サーバ構成におけるシステム監視情報管理装置。
【請求項１８】前記ユーザ通知連絡手段は、前記ユーザ通知ロギングに対して予め指定されている指
定プロセスを、ロギング情報の送信先であるサーバ上で
起動させる起動手段、を含むことを特徴とする請求項１５記載のマルチサーバ
構成におけるシステム監視情報管理装置。
【請求項１９】前記ユーザ通知連絡手段は、前記ユーザ通知ロギングに対して予め指定されている指
定キーのメッセージの送付を、ロギング情報の送信先で
あるサーバ上で行うメッセージ送付手段、を含むことを特徴とする請求項１５記載のマルチサーバ
構成におけるシステム監視情報管理装置。
【請求項２０】前記ユーザ通知連絡手段は、前記ユーザ通知ロギングに対して予め指定されている指
定ソケットへの通知を、ロギング情報の送信先であるサ
ーバ上で行うソケット通知手段、を含むことを特徴とする請求項１５記載のマルチサーバ
構成におけるシステム監視情報管理装置。
【請求項２１】複数のサーバと、この複数のサーバに
対し共通に設けられている共通記憶手段と、を含む構成
のシステムにおいて発生した事象を管理するマルチサー
バ構成におけるシステム監視情報管理方法において、前記システムに含まれる各サーバ毎に発生した事象を検
知し、この検知した事象に関する情報である事象情報を
ネットワークを介して送信する事象検知ステップと、前記システムに含まれる何れかのサーバにおいて、前記
送信された事象情報を受信し、この受信した事象情報を
前記共通記憶手段に記憶する管理ステップと、を含むことを特徴とするマルチサーバ構成におけるシス
テム監視情報管理方法。
【請求項２２】前記事象検知ステップは、前記マルチサーバ構成のシステムに予め定義されている
システム事象を検知するシステム事象検知ステップと、前記システムの利用者が定義するユーザ事象を検知する
ユーザ定義事象検知ステップと、を含むことを特徴とする請求項２１記載のマルチサーバ
構成におけるシステム監視情報管理方法。
【請求項２３】前記システム事象検知ステップは、前
記システム事象として、ハードウェアに縮退が生じたこ
と、を検知することを特徴とする請求項２２記載のマル
チサーバ構成におけるシステム監視情報管理方法。
【請求項２４】前記システム事象検知ステップは、前
記システム事象として、再試行が成功したこと、を検知
することを特徴とする請求項２２記載のマルチサーバ構
成におけるシステム監視情報管理方法。
【請求項２５】前記システム事象検知ステップは、前
記システム事象として、機能的には障害がないが冗長化
ハードウェアの一部に障害が発生したこと、を検知する
ことを特徴とする請求項２２記載のマルチサーバ構成に
おけるシステム監視情報管理方法。
【請求項２６】前記管理ステップは、受信した前記事象情報の示す事象が利用者に通知すべき
ユーザ通知事象である場合に、前記受信した事象情報を
ネットワークを介して所定のサーバに送信するユーザ通
知送信ステップ、を含み、前記ユーザ通知送信ステップにより送信されてきた事象
情報を前記システムに含まれる複数の各サーバ毎に受信
し、受信した事象情報を利用者に通知するユーザ通知連
絡ステップ、を含むことを特徴とする請求項２１又は２２記載のマル
チサーバ構成におけるシステム監視情報管理方法。
【請求項２７】前記ユーザ通知送信ステップにおいて
前記事象情報の送信を失敗した場合、又は、前記ユーザ
通知連絡ステップにおいて事象情報の利用者への通知を
失敗した場合には、通知失敗事象を検知する通知失敗検
出ステップ、を含み、前記通知失敗事象は前記ユーザ通知事象である
ことを特徴とする請求項２６記載のマルチサーバ構成に
おけるシステム監視情報管理方法。
【請求項２８】前記ユーザ通知送信ステップは、前記発生した事象と、この事象に関する事象情報の送信
を行うべき１個以上のサーバと、前記１個以上のサーバ
のそれぞれに割り当てられている優先順位と、を記憶し
ている優先順位記憶手段を参照し、この優先順位記憶手
段中で最も高い優先順位が割り当てられているサーバ又
はサーバ群から、順に低い優先順位が割り当てられてい
るサーバ又はサーバ群にアクセスし、一番最初に見つか
った稼働しているサーバ又はサーバ群に対し前記事象情
報の送信を行う優先通知ステップと、を含むことを特徴とする請求項２６記載のマルチサーバ
構成におけるシステム監視情報管理方法。
【請求項２９】前記システムに含まれる複数のサーバ
間における定期通信を行うために、前記各サーバに設け
られている所定周期毎に定期通信を行う定期通信ステッ
プ、を備え、前記ユーザ通知送信ステップは、前記定期通信ステップが行う前記定期通信における通信
対象であるパケット中に、前記発生した事象情報を含め
るパケット形成ステップ、を含み、前記ユーザ通知は、前記定期通信で使用するパ
ケットと同一のパケットを使用して行われることを特徴
とする請求項２６記載のマルチサーバ構成におけるシス
テム監視情報管理方法。
【請求項３０】前記ユーザ通知連絡ステップは、前記ユーザ通知事象に対して予め指定されている指定プ
ロセスを、事象情報の送信先であるサーバ上で起動させ
る起動ステップ、を含むことを特徴とする請求項２６、２７、２８又は２
９記載のマルチサーバ構成におけるシステム監視情報管
理方法。
【請求項３１】前記ユーザ通知連絡ステップは、前記ユーザ通知事象に対して予め指定されている指定キ
ーのメッセージの送付を、事象情報の送信先であるサー
バ上で行うメッセージ送付ステップ、を含むことを特徴とする請求項２６、２７、２８又は２
９記載のマルチサーバ構成におけるシステム監視情報管
理方法。
【請求項３２】前記ユーザ通知連絡ステップは、前記ユーザ通知事象に対して予め指定されている指定ソ
ケットへの通知を、事象情報の送信先であるサーバ上で
行うソケット通知ステップ、を含むことを特徴とする請求項２６、２７、２８又は２
９記載のマルチサーバ構成におけるシステム監視情報管
理方法。
【請求項３３】複数のサーバと、この複数のサーバに
対し共通に設けられている共通記憶手段と、を含む構成
のシステムにおいて発生したロギングを管理するマルチ
サーバ構成におけるシステム監視情報管理方法におい
て、前記システムに含まれる各サーバ毎に設けられ、前記各
サーバ毎に発生したロギングを検知し、この検知したロ
ギング情報が前記共通記憶手段に記憶すべきロギングの
場合、ロギング情報をネットワークを介して送信するロ
ギング検知ステップと、前記システムに含まれる何れかのサーバにおいて、前記
送信されたロギング情報を受信し、この受信したロギン
グ情報を前記共通記憶手段に記憶する管理ステップと、を含むことを特徴とするマルチサーバ構成におけるシス
テム監視情報管理方法。
【請求項３４】前記ロギング検知ステップは、ロギン
グを検知した時刻の情報を、前記ロギング情報に付加し
て前記ネットワークを介して送信することを特徴とする
請求項３３記載のマルチサーバ構成におけるシステム監
視情報管理方法。
【請求項３５】前記管理ステップは、受信した前記ロギング情報の示すロギングが利用者に通
知すべきユーザ通知ロギングである場合に、前記受信し
たロギング情報をネットワークを介して所定のサーバに
送信するユーザ通知送信ステップ、を含み、前記ユーザ通知送信ステップにより送信されてきたロギ
ング情報を前記システムに含まれる複数の各サーバ毎に
受信し、受信したロギング情報を利用者に通知するユー
ザ通知連絡ステップ、を含むことを特徴とする請求項３３又は３４記載のマル
チサーバ構成におけるシステム監視情報管理方法。
【請求項３６】前記ユーザ通知送信ステップは、前記発生したロギングと、このロギングに関するロギン
グ情報の送信を行うべき１個以上のサーバと、前記１個
以上のサーバのそれぞれに割り当てられている優先順位
と、を記憶している優先順位記憶手段を参照し、この優
先順位記憶手段中で最も高い優先順位が割り当てられて
いるサーバ又はサーバ群から、順に低い優先順位が割り
当てられているサーバ又はサーバ群にアクセスし、一番
最初に見つかった稼働しているサーバ又はサーバ群に対
しロギング情報を送信する優先通知ステップと、を含むことを特徴とする請求項３５記載のマルチサーバ
構成におけるシステム監視情報管理方法。
【請求項３７】前記システムに含まれる複数のサーバ
間における定期通信を行うために、前記各サーバに設け
られている所定周期毎に定期通信を行う定期通信ステッ
プ、を備え、前記ユーザ通知送信ステップは、前記定期通信ステップが行う前記定期通信における通信
対象であるパケット中に、前記発生したロギング情報を
含めるパケット形成ステップ、を含み、前記ロギング情報の送信の対応するサーバへの
送信は、前記定期通信で使用するパケットと同一のパケ
ットを使用して行われることを特徴とする請求項３５記
載のマルチサーバ構成におけるシステム監視情報管理方
法。
【請求項３８】前記ユーザ通知連絡ステップは、前記ユーザ通知ロギングに対して予め指定されている指
定プロセスを、ロギング情報の送信先であるサーバ上で
起動させる起動ステップ、を含むことを特徴とする請求項３５記載のマルチサーバ
構成におけるシステム監視情報管理方法。
【請求項３９】前記ユーザ通知連絡ステップは、前記ユーザ通知ロギングに対して予め指定されている指
定キーのメッセージの送付を、ロギング情報の送信先で
あるサーバ上で行うメッセージ送付ステップ、を含むことを特徴とする請求項３５記載のマルチサーバ
構成におけるシステム監視情報管理方法。
【請求項４０】前記ユーザ通知連絡ステップは、前記ユーザ通知ロギングに対して予め指定されている指
定ソケットへの通知を、ロギング情報の送信先であるサ
ーバ上で行うソケット通知ステップ、を含むことを特徴とする請求項３５記載のマルチサーバ
構成におけるシステム監視情報管理方法。