JP2003131905A

JP2003131905A - 管理サーバシステム

Info

Publication number: JP2003131905A
Application number: JP2001328802A
Authority: JP
Inventors: Shoei Fukushima; 昭英福島; Hiroshi Kume; 浩久米
Original assignee: SITECARE KK
Current assignee: SITECARE KK
Priority date: 2001-10-26
Filing date: 2001-10-26
Publication date: 2003-05-09
Anticipated expiration: 2021-10-26
Also published as: JP4081258B2

Abstract

(57)【要約】【課題】ネットワーク上に於けるエンドユーザサーバを
監視し、障害発生を未然に防止する為の管理サーバシス
テムに関する。【解決手段】処理機構の当初の問題を内部から診断する
内部初期診断手段と、内部初期診断終了後から予め定め
られた期間の使用傾向を収集する内部初期流動期間手段
と、処理機構の内部監視を行う内部監視手段とをエンド
ユーザサーバが有しており、エンドユーザサーバからデ
ータを受信するＥＵＳ受信手段と、ネットワーク状態の
当初の問題を外部から診断する外部初期診断手段と、外
部初期診断終了後から予め定められた期間のネットワー
ク状態の使用傾向を収集する外部初期流動期間手段と、
外部監視を行う外部監視手段と、受信したデータ、外部
初期診断手段、外部監視手段とに於いて処理機構、ネッ
トワーク状態に何らかの障害を検出した場合に通知を行
う外部通知手段とを有するＥＵＳ管理サーバである。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ネットワーク上に
於けるエンドユーザサーバを監視し、障害発生を未然に
防止する為の管理サーバシステムに関する。更に詳細に
は、エンドユーザサーバの外部／内部の予め定められた
初期期間の使用傾向に基づいてエンドユーザサーバを外
部、内部の双方から監視し障害発生を未然に防止するこ
とを特徴とする管理サーバシステムに関する。

【０００２】

【従来の技術】エンドユーザサーバ（ネットワークの利
用者（所謂個々のユーザ）が利用するサーバ。例えばプ
ロバイダがユーザとの接続に用いるサーバ等を示す）
は、その障害発生の防止、効率的運用の為に継続的な監
視を行うことが一般的である。

【０００３】従来、このエンドユーザサーバを監視する
方法としては、外部的な監視（以下、外部監視）、内部
的な監視（以下、内部監視）の何れかを用いることによ
って行われている。外部的な監視とは、エンドユーザサ
ーバに何らかの監視装置（ボード等）を設置し、エンド
ユーザサーバに何らかの障害が発生した場合に、前記監
視装置から外部の指定先に対して障害通知を行う方法で
ある。又、内部監視とはエンドユーザサーバのシステム
状態（例えばメモリの使用状態等）を継続的に監視し、
制限値まで到達した段階でエンドユーザサーバの管理者
等に警告を発する、障害が発生した場合に自動復旧を行
う等の方法である。

【０００４】

【発明が解決しようとする課題】上記の外部監視を用い
た場合、何らかの障害が発生した段階で速やかに外部、
例えば管理者や保守サービスマン等（以下、管理者等）
に通知することは可能であるが、管理者等のローテーシ
ョン、スケジュール等を勘案する必要性から多数の管理
者等を通知先として確保しておく必要性がある。又実際
に障害が発生してからの対応となるので、エンドユーザ
サーバのユーザは、障害発生時から障害復旧時迄の間、
エンドユーザサーバからサービスを享受することが出来
ない。更に管理者等の技術スキルにはバラツキがあり、
技術スキルの高い者が行う場合には速やかなる復旧が行
えるが、技術スキルの高くない者が行う場合には復旧ま
でに相当の時間を要す場合がある。

【０００５】一方、内部監視を用いた場合、システム状
態の継続監視から何らかの警告が発せられるのは、危険
状態になった場合、障害が発生した場合であってその対
応には専門的知識が必要となり、管理者等に対して相当
の技術スキルを要求する。更に障害発生時に於いて、知
識がない管理者等であっても復旧が行えるような自動復
旧システムも存しており、その一例が特開２００１−６
７２８８号公報に開示されている。

【０００６】この公報記載の発明は、予めデータベース
に障害から復旧する為の方法を格納し、障害発生時には
この方法に基づいて自動復旧を試みる。この方法で自動
復旧が行えない場合には、障害に対するガイド情報を提
供し管理者等による復旧を支援し、これでも復旧が行え
ない場合には障害内容と障害が発生したエンドユーザサ
ーバのシステム情報とを予め定められているサーバ装置
に送信し、保守サービスマンに通知する。保守サービス
マンはこれらを閲覧することで更なるガイド情報、シス
テム変更情報を作成し、ガイド情報の充実を図る方法で
ある。

【０００７】しかしこの発明を用いた場合に於いても、
この発明を利用することが出来るのはシステムの障害発
生後であって、外部監視と同様に障害発生時から障害復
旧時迄の間、エンドユーザサーバのユーザは、エンドユ
ーザサーバからサービスを享受することが出来ない。

【０００８】

【課題を解決するための手段】ところで、従来のように
障害発生時に速やかに対処することは重要であるが、エ
ンドユーザサーバの運営上最も重要なことは障害を未然
に防止することである。これを行う場合には、内部監視
で用いられているシステム状態を常に管理者等が把握し
ておくのが通常である。しかし、前記のようにシステム
状態を把握するには高度な専門的知識が必要であって、
管理者等の技術スキルにバラツキがある現在に於いて
は、これを行うのは非常に困難である。特にシステム管
理の為の専属の管理者等を任命することが困難な事業規
模の大きくない企業等に於いては、実質的に不可能に近
い。又内部監視でシステム状態（所謂システムログ）の
記録は行っているが、そのシステム状態からどのような
障害が将来的に発生するかを読みとれるか否かは、管理
者等の技術スキルに左右されてしまう為、障害を未然に
防止するには管理者等次第となってしまう。

【０００９】又、上記外部監視の手法も何らかの障害が
発生した段階でエンドユーザサーバから管理者等に通知
するものであるので、内部監視の通知のみを外部に行っ
ているにすぎず、実質上は内部監視とほぼ同一である。

【００１０】従って、エンドユーザサーバとユーザが利
用しているユーザ端末との間に存在するシステム（例え
ばＤＮＳサーバ）に障害が発生している場合には、その
障害そのものを発見することが出来ない。

【００１１】つまり、例えばＤＮＳサーバのみに障害が
ある場合には、上記手法を用いる外部監視、内部監視で
あってもエンドユーザサーバ自体は正常に機能している
ので何らの障害も発見は出来ない。しかしユーザ端末が
ＤＮＳサーバを介してエンドユーザサーバにアクセスす
る場合には、ＤＮＳサーバに障害が発生しているのでエ
ンドユーザサーバの利用が行うことは出来ないこととな
る。従ってユーザからの通知に因らない限り管理者等は
ＤＮＳサーバの障害を知ることが出来ない為、障害発生
時から障害復旧迄の期間が長期化することとなる。

【００１２】従って外部監視、内部監視の何れか一つの
監視手法を用いた場合では、上記のように何らかの問題
点が存在している。更に、外部監視、内部監視の２つの
監視システムを導入することも可能であるが、これら２
つの監視システムが作成するシステム状態等のレポート
は、各々の立場に因るものであるので連携が取れておら
ず、そこから総合的な評価を更に行う場合には、その２
つの監視システムが作成したレポートに基づいて管理者
等自らが行わなければならない。

【００１３】又内部監視と同様に外部監視に於いても障
害発生の未然防止を行うことが重要であるが、これを行
うにはネットワークトラフィックを常に監視する、ネッ
トワークエラーの発生を常に監視する等を恒常的に行わ
なくてはならない。又単に記録（ログ）を取ることは可
能であってもその記録（ログ）自体から障害発生を予測
することは、管理者等の経験と知識とに頼らなくてはい
けない為、エンドユーザサーバの管理を行う全ての管理
者等の経験と知識とを一定水準に保つのは困難であるこ
とから、個々のエンドユーザサーバに於いて障害発生度
にバラツキが発生することとなり、全体のシステムの安
定的な運用に欠ける。

【００１４】例えばある企業のシステム環境を経験、知
識が共に豊富である管理者Ａと経験、知識が共に浅い管
理者Ｂの２名で分担して管理している場合、必然的に管
理者Ｂの管理下にあるエンドユーザサーバでの障害発生
度が高くなる。従って、管理者Ｂの管理下にあるエンド
ユーザサーバで障害発生が起こる毎に管理者Ａの管理下
にあるエンドユーザサーバに対して処理が集中し、管理
者Ａの管理下のエンドユーザサーバでも障害発生が起こ
りやすくなってしまい、相対的にシステムの安定的運用
が損なわれてしまう。

【００１５】従来はこれを回避する為に管理者の知識、
経験の向上、管理人数等の増加等の人為的側面から対処
していたが、それには多大なる費用、時間を要すること
となる。従って、システム的に何らかの障害発生を未然
に防止する必要性がある。

【００１６】そこで本発明者は、エンドユーザサーバの
予め定めた初期稼働期間（以下、初期流動期間）のシス
テム状況に基づいて継続的な監視を行い障害発生の未然
防止を行うと共に、その監視をシステム状態の内部監視
とユーザとほぼ同様の立場からの監視を行う、即ちエン
ドユーザサーバのネットワーク状態の監視を行う実質上
の外部監視とを組み合わせ総合的に行うことによってエ
ンドユーザサーバの安定的管理を行う管理サーバシステ
ムを発明した。

【００１７】更にエンドユーザサーバの管理者は何らか
の外部監視、内部監視システムを導入した場合には、そ
の導入の効果があったかどうかを把握することを希望す
ることが多い。しかし、従来は各エンドユーザサーバに
対してのみの外部監視、内部監視であったので、全体的
な効果を測定することは困難であった。そこで本発明者
は、上記発明の他に更に全体的な監視効果の分析を行う
ことが可能となる管理サーバシステムを発明した。

【００１８】請求項１の発明は、エンドユーザサーバの
監視を行う管理サーバシステムに於いて、監視対象とな
るエンドユーザサーバと前記エンドユーザサーバの外部
監視を行うＥＵＳ管理サーバとがネットワークを介して
接続しており、前記ＥＵＳ管理サーバは、前記エンドユ
ーザサーバの処理を行う処理機構が問題なく初期設定が
為されているか否かを診断する内部初期診断手段と、前
記内部初期診断終了後から予め定められた期間の前記処
理機構の使用傾向を収集する内部初期流動期間手段と、
前記処理機構の内部監視を行う内部監視手段とを前記エ
ンドユーザサーバが有しており、前記内部初期診断手段
と前記内部初期流動期間手段と前記内部監視手段とに於
けるデータを前記エンドユーザサーバの内部監視送信手
段から受信するＥＵＳ受信手段と、前記エンドユーザサ
ーバのネットワーク状態が問題なく初期設定が為されて
いるか否かを前記ネットワークを介して外部から診断す
る外部初期診断手段と、前記外部初期診断終了後から予
め定められた期間の前記ネットワーク状態の使用傾向を
収集する外部初期流動期間手段と、前記ネットワーク状
態の外部監視を行う外部監視手段と、前記ＥＵＳ受信手
段に於いて受信したデータ及び／又は前記外部初期診断
手段及び／又は前記外部監視手段とに於いて前記処理機
構及び／又は前記ネットワーク状態に何らかの障害を検
出した場合に通知を行う外部通知手段とを有する管理サ
ーバシステムである。

【００１９】本発明によって、従来のように内部監視、
外部監視の何れか一つの監視ではなく、内部監視及び外
部監視を複合的に行う管理サーバシステムが可能とな
る。これによって２つの監視システムが従来別々に作成
しているレポートを、内部及び外部の双方から総合的な
評価を行うことが可能となる。

【００２０】更に、外部監視も従来のようにサーバに何
らかの装置（例えばボード等のハードウェア）を設置
し、障害が発生した段階に於いて外部の管理者等に通知
するのみの外部監視ではなく、実際にユーザと同等の立
場である、ネットワークを介してエンドユーザサーバの
ネットワーク状態の外部監視を行うことが可能となる。
これによって、従来の監視では検出出来なかった、ユー
ザとエンドユーザサーバとの間の障害（例えばＤＮＳサ
ーバのみの障害）を検出することも可能となる。

【００２１】請求項２の発明は、前記内部監視手段は、
前記内部初期流動期間手段に於いて収集した前記処理機
構の使用傾向に基づいて、前記処理機構の障害発生を予
測し、前記エンドユーザサーバは、前記内部監視手段に
於ける予測に基づいて警告及び／又は処置方法を通知す
る内部通知手段とを有する管理サーバシステムである。

【００２２】請求項３の発明は、前記外部監視手段は、
前記外部初期診断手段に於いて収集した前記エンドユー
ザサーバのネットワーク状態の使用傾向に基づいて、前
記ネットワーク状態の障害発生を予測し、前記ＥＵＳ管
理サーバは、前記外部監視手段に於ける予測に基づいて
警告及び／又は処置方法を通知する外部通知手段とを有
する管理サーバシステムである。

【００２３】請求項２及び請求項３の発明によって、従
来の監視システムのように、障害発生後に初めて何らか
の通知が為される監視システムではなく、当初の使用傾
向に基づいて以後の障害発生を予測し、障害の発生を未
然に防止することが可能となる。これによってエンドユ
ーザサーバを運営する際に最も重要である障害の回避が
行え、障害の発生そのものを逓減することが可能とな
る。

【００２４】請求項４の発明は、前記内部初期流動期間
手段は、前記処理機構のＣＰＵ負荷率、メモリ使用率、
ディスク使用状況、サービス接続、サービスアプリケー
ション、修正モジュールチェック、管理者権限パスワー
ドエラーの回数のうち少なくとも一以上の使用傾向を収
集する管理サーバシステムである。

【００２５】請求項５の発明は、前記内部監視手段は、
前記処理機構のＣＰＵ負荷率、メモリ使用率、ディスク
使用状況、サービス接続、サービスアプリケーション、
修正モジュールチェック、管理者権限パスワードエラー
の回数のうち少なくとも一以上の監視を行う管理サーバ
システムである。

【００２６】請求項６の発明は、前記外部初期流動期間
手段は、前記ネットワーク状態のネットワーク接続、サ
ービス接続、トラフィック状態、ポート状況、メールオ
ープンリレーチェックのうち少なくとも一以上の使用傾
向を収集する管理サーバシステムである。

【００２７】請求項７の発明は、前記外部監視手段は、
前記ネットワーク状態のネットワーク接続、サービス接
続、トラフィック状態、ポート状況、メールオープンリ
レーチェックのうち少なくとも一以上の監視を行う管理
サーバシステムである。

【００２８】請求項４から請求項７の発明は、障害の発
生を未然に防止する際にこれらの使用傾向を分析するこ
とが好適であり、これらの要素少なくとも一以上の内部
監視／外部監視を行うことによって、効率的に監視を行
うことが可能となる。

【００２９】請求項８の発明は、前記管理サーバシステ
ムは、前記エンドユーザサーバのパフォーマンスの分析
を行う総合管理サーバと前記ＥＵＳ管理サーバとが前記
ネットワークを介して接続しており、前記総合管理サー
バは、前記ＥＵＳ管理サーバから前記エンドユーザサー
バの内部監視の情報及び／又は外部監視の情報とを受信
するＥＵＳ管理サーバ受信手段と、前記ＥＵＳ管理サー
バ受信手段に於いて受信した情報を格納するＥＵＳ管理
データベースと、前記ＥＵＳ管理サーバ受信手段に於い
て受信した情報及び／又は前記ＥＵＳ管理データベース
に格納している情報とに基づいて、母集団とする全体又
は一部のエンドユーザサーバに於いて、前記エンドユー
ザサーバのパフォーマンスがどの位であるかの分析を行
う分析手段とを有する管理サーバシステムである。

【００３０】本発明によって、内部監視／外部監視のみ
ならず、エンドユーザサーバに本監視システムを用いた
客観的な効果を分析することが可能となる。これによっ
て、エンドユーザサーバの管理者等は、内部監視／外部
監視の効果を把握することが出来る。

【００３１】請求項９の発明は、前記ＥＵＳ管理サーバ
受信手段は、前記ＥＵＳ管理サーバから前記エンドユー
ザサーバの障害発生時刻と前記発生した障害に対する応
答時刻とを受信する管理サーバシステムである。

【００３２】請求項１０の発明は、前記分析手段は、前
記エンドユーザサーバのＭＴＢＦ、平均ＭＴＢＦ、母集
団とする全て又は一部のエンドユーザサーバの平均ＭＴ
ＢＦ、前記母集団に於ける前記エンドユーザサーバのＭ
ＴＢＦに対する偏差値、前記エンドユーザサーバのＭＴ
ＴＲ、平均ＭＴＴＲ、前記母集団の平均ＭＴＴＲ、前記
母集団に於ける前記エンドユーザサーバのＭＴＴＲに対
する偏差値のうち、少なくとも一以上を分析する管理サ
ーバシステムである。

【００３３】請求項９及び請求項１０の発明によって、
エンドユーザサーバに本管理サーバシステムを用いた場
合の客観的効果を分析する際に、ＭＴＢＦ、ＭＴＴＲ等
を分析対象とすることによって、その効果を測定するこ
とが可能となる。

【００３４】尚、ＭＴＢＦとはエンドユーザサーバの障
害発生間隔を計算する公知の手法であって、ＭＴＴＲと
はエンドユーザサーバの障害発生時に於ける障害からの
復旧間隔を計算する公知の手法である。これらの計算手
法は数１から数８に後述する。

【００３５】請求項１１の発明は、エンドユーザサーバ
の監視を行う管理サーバシステムに於いて、監視対象と
なるエンドユーザサーバと前記エンドユーザサーバの外
部監視を行うＥＵＳ管理サーバと前記エンドユーザサー
バのパフォーマンスの分析を行う総合管理サーバとがネ
ットワークを介して接続しており、前記総合管理サーバ
は、前記ＥＵＳ管理サーバが前記エンドユーザサーバか
ら受信した内部監視の情報と前記ＥＵＳ管理サーバによ
る前記エンドユーザサーバの外部監視の情報とを、前記
ＥＵＳ管理サーバから受信するＥＵＳ管理サーバ受信手
段と、前記ＥＵＳ管理サーバ受信手段に於いて受信した
情報を格納するＥＵＳ管理データベースと、前記ＥＵＳ
管理サーバ受信手段に於いて受信した情報及び／又は前
記ＥＵＳ管理データベースに格納している情報とに基づ
いて、母集団とする全体又は一部のエンドユーザサーバ
に於いて、前記エンドユーザサーバのパフォーマンスが
どの位であるかの分析を行う分析手段とを有する管理サ
ーバシステムである。

【００３６】本発明によって、エンドユーザサーバに本
監視システムを用いた場合の客観的な効果を分析するこ
とが可能となる。これによって、エンドユーザサーバの
管理者等は、内部監視／外部監視の効果を把握すること
が出来る。

【００３７】

【発明の実施の形態】本発明のシステム構成の実施態様
の一例を図１のシステム構成図に示す。管理サーバシス
テム１は、エンドユーザサーバ２とＥＵＳ管理サーバ３
とがネットワーク１３を介して接続している場合を説明
する。

【００３８】エンドユーザサーバ２は、ユーザ端末に対
して何らかのサービスを提供するサーバであって、例え
ばプロバイダのサーバ等を示し、本発明に於いて監視対
象となるサーバである。エンドユーザサーバ２は、処理
機構４、内部初期診断手段５、内部初期流動期間手段
６、内部監視手段７、内部監視送信手段８、内部通知手
段９とを有している。

【００３９】処理機構４は、エンドユーザサーバ２の処
理を行う機構であって、監視対象となる一般的なサーバ
自体である。

【００４０】内部初期診断手段５は、処理機構４を含む
エンドユーザサーバ２の内部から初期診断を行う手段で
ある。ここで内部初期診断とは、監視対象として監視を
行う際に最初に行う診断であって、エンドユーザサーバ
２の処理機構４が正常な状態、即ち問題なく初期設定が
為されているか否かを内部から診断する手段である。

【００４１】内部初期流動期間手段６は、初期診断終了
後から予め定められた期間（例えば４週間）に於いて、
エンドユーザサーバ２の処理機構４がどのようなシステ
ム状態に於いて使用されるか（即ちエンドユーザサーバ
２の使用傾向を把握する）データ収集を行う手段であ
る。例えばエンドユーザサーバ２の処理機構４に於ける
ディスク使用状況の傾向等を収集する。

【００４２】処理機構４の使用傾向は、個々のシステム
目的、システム環境に於いて異なるのが通常である。そ
こで平均的なエンドユーザサーバ２の処理機構４のシス
テム状態を参考として継続監視を行うのが従来である
が、この方法を用いた場合ではシステム目的、システム
環境等に適した継続監視を行うことが困難である。そこ
で本発明では初期流動期間（例えば３週間）を設定し、
どのような使用傾向があるか、即ちエンドユーザサーバ
２独自の使用傾向のデータ収集を行い、以後の継続監視
の基準とすることによって、エンドユーザサーバ２の処
理機構４の使用傾向を踏まえた形での継続監視を行い、
警告等を行うことによって、障害発生を予防することと
が可能となる。更にエンドユーザサーバ２の処理機構４
の初期の状態では複雑、余計な処理、ファイル等がほと
んど含まれていないので、最初に傾向把握を行うことが
好適である。

【００４３】内部監視手段７は、処理機構４のシステム
状態の内部監視を行う手段である。内部監視には例えば
ＣＰＵ負荷率の監視、メモリ使用率の監視（メモリの使
用状態の監視）、ディスク使用状況の監視、サービス接
続の監視（サービスに接続しサービスが行われている否
かの監視）、サービスアプリケーションの監視（サービ
スアプリケーションの稼働状況の監視）、修正モジュー
ルチェックの監視（ＯＳ、アプリケーションに最新の修
正モジュールが適用されているか否か）、管理者権限パ
スワードエラー回数（管理者権限でログイン使用とした
時のパスワードエラーの回数取得）等がある。

【００４４】内部監視送信手段８は、内部監視手段７に
於いて行う内部監視の情報をＥＵＳ管理サーバ３（後
述）に送信する手段である。

【００４５】内部通知手段９は、内部監視手段７に於い
て何らかの障害が発生しそうだという状況を事前に検出
し、その通知及び参考となる処置とをエンドユーザサー
バ２に通知する手段である。

【００４６】ＥＵＳ管理サーバ３は、少なくとも一以上
の監視対象となるエンドユーザサーバ２の外部監視を行
うサーバであって、外部初期診断手段１０、外部初期流
動期間手段１９、外部監視手段１１、ＥＵＳ受信手段１
２、外部通知手段２０とを有している。

【００４７】外部初期診断手段１０は、処理機構４を含
むエンドユーザサーバ２のネットワーク状態の外部初期
診断を行う手段である。ここで外部初期診断とは、管理
サーバシステム１が監視対象として監視を行う際に最初
に行う診断であって、エンドユーザサーバ２のネットワ
ーク状態が正常な状態、即ち問題なく初期設定が為され
ているか否かをネットワーク１３を介して外部から診断
する。ここで、ネットワーク状態の監視とは、ネットワ
ーク接続の監視（ＰＩＮＧによるネットワーク状態の監
視、障害箇所検索）、トラフィック状態の監視（ネット
ワークトラフィックの監視）、サービス接続の監視（サ
ービスに接続しサービスが行われているか否かを監
視）、ポート状況の監視（エンドユーザサーバ２のサー
ビスポート使用状態の監視）、メールオープンリレーチ
ェック（エンドユーザが使用しているメールサーバが不
正な中継を行うか否か）等がある。

【００４８】外部初期流動期間手段１９は、初期診断終
了後から予め定められた期間（例えば４週間）に於い
て、エンドユーザサーバ２のネットワーク状態がどのよ
うな使用傾向であるかのデータ収集を行う手段である。
例えばエンドユーザサーバ２のネットワークトラフィッ
ク状態の収集がある。

【００４９】外部監視手段１１は、ネットワーク１３を
介してエンドユーザサーバ２の外部監視を行う手段であ
り、主にエンドユーザサーバ２とのネットワーク１３の
状態を監視する手段である。

【００５０】従来の外部監視は、エンドユーザサーバ２
にボード等の監視装置を設置し、エンドユーザサーバ２
に障害が発生した時点に於いて予め定められた外部に対
して通知を行うという方法（即ち内部の障害を外部に通
知する方法）であった。しかしこのような外部監視の方
法では、エンドユーザサーバ２が接続しているネットワ
ーク１３の状態までを把握することが困難である。そこ
で本発明ではユーザ端末と同様の状態、即ちユーザ端末
がエンドユーザサーバ２にアクセスする状態と同様にネ
ットワーク１３を介してエンドユーザサーバ２にアクセ
スを行い、そのネットワーク１３の状態の監視を行うこ
とによって、従来の外部、内部監視では行うことの出来
なかった、ユーザの立場からの監視が可能となる。

【００５１】ＥＵＳ受信手段１２は、エンドユーザサー
バ２の内部監視送信手段８から、内部監視の情報を受信
する手段である。

【００５２】外部通知手段２０は、ＥＵＳ受信手段１２
が各エンドユーザサーバ２から受信した内部監視の情報
及びＥＵＳ管理サーバ３による各エンドユーザサーバ２
の外部監視の情報とに基づいて、何らかの障害が発生し
そうだという状況を予め検出し、その通知及び参考とな
る処置をＥＵＳ管理サーバ３の管理者等に通知する手段
である。

【００５３】

【実施例】次に本発明のプロセスの流れの一例を図３の
フローチャート図を用いて詳細に説明する。

【００５４】監視を希望するエンドユーザサーバ２の管
理者等は、エンドユーザサーバ２の初期設定後、エンド
ユーザサーバ２内の内部初期診断手段５及びＥＵＳ管理
サーバ３内の外部初期診断手段１０とを用い、エンドユ
ーザサーバ２の処理機構４及びエンドユーザサーバ２の
ネットワーク状態とが正常な状態、即ち監視をしても問
題ないか否かを内部及び外部から診断を行う（Ｓ１０
０）。初期診断の結果は、紙媒体、電子媒体等を用いて
その初期診断結果レポートを作成することが好適であ
る。図７から図９に初期診断結果レポートの一例を示
す。図７はＥＵＳ管理サーバ３に関する一般的な情報を
示すレポートであり、図８は内部初期診断の結果を示す
レポートであり、図９は外部初期診断の結果を示すレポ
ートである。

【００５５】Ｓ１００に於いて初期診断終了後、エンド
ユーザサーバ２の処理機構４及びネットワーク状態に於
いて何らかの問題が発生している（例えばディスク不良
等）場合には、その問題を内部初期診断手段５／外部初
期診断手段１０が内部通知手段９／外部通知手段２０を
介して通知を行う。又Ｓ１００の初期診断に於いて何ら
の問題が発生していなければ、エンドユーザサーバ２の
システム運用の開始を行う。内部初期流動期間手段６／
外部初期流動期間手段１９がこの時点から初期流動期間
を開始し、予め定めた期間（例えば３週間）のエンドユ
ーザサーバ２の処理機構４及びネットワーク状態のデー
タ収集を開始する（Ｓ１１０）。

【００５６】又Ｓ１１０に於ける初期流動期間のデータ
収集と並行して、エンドユーザサーバ２の処理機構４の
内部監視を内部監視手段７が行い、エンドユーザサーバ
２のサービス状態の外部監視をＥＵＳ管理サーバ３の外
部監視手段１１が行う（Ｓ１２０）。内部監視には、例
えばＣＰＵ負荷率の監視、メモリ使用率の監視、ディス
ク使用状況の監視、サービス接続の監視、サービスアプ
リケーションの監視、修正モジュールチェック、管理者
権限パスワードエラー回数の監視等があり、外部監視に
は、ネットワーク接続の監視、トラフィック状態の監
視、サービス接続の監視、ポート状況の監視、メールオ
ープンリレーチェック等がある。又内部監視の結果をネ
ットワーク１３を介して内部監視送信手段８がＥＵＳ管
理サーバ３に送信する。

【００５７】本実施態様に於いては内部監視として、サ
ービス接続監視の場合のプロセスの流れを図４のフロー
チャート図を用いて説明し、外部監視として、ネットワ
ーク接続監視を行うプロセスの流れを図５のフローチャ
ート図を用いて説明する。

【００５８】先ず図４を用いて内部監視の場合を説明す
る。この処理内容は、ＩＰアドレスとポート番号とによ
り該当のサービスに対して接続状態を取得し、結果表示
を行う監視である。内部監視がスタートすると、内部監
視手段７が、ＩＰアドレス、ポート番号で接続状況を確
認し（Ｓ２００）、何らかのパラメータに障害が発生し
ている場合には、そのパラメータ異常を内部通知手段９
を介して表示する（Ｓ２１０）。又Ｓ２００に於いて何
らパラメータ自体が正常であって、予め定められた時間
内に応答があった場合には、正常な状態であると判断
し、その状態と応答するのに要した応答時間とを表示す
る（Ｓ２２０）。一方、予め定められた時間内に応答が
ない場合、即ちタイムアウトした場合には、障害状態と
判断し障害状態の表示を行う（Ｓ２３０）。これらを該
当サービス分反復することによって、内部監視を行う。

【００５９】次に図５を用いて外部監視の場合を説明す
る。この処理内容は、入力ホスト名又は入力ＩＰアドレ
スでエンドユーザサーバ２の接続状態を取得し、正常で
あれば該当値を返し、障害が発生していれば障害箇所を
特定しその情報を取得する結果を結果表示を行う監視で
ある。外部監視がスタートすると、外部監視手段１１が
パラメータの状況を確認する（Ｓ３００）。パラメータ
に何らかの異常がある場合には、その異常表示を行う
（Ｓ３１０）。

【００６０】Ｓ３００に於いて異常がなければ、外部監
視手段１１が入力ホスト名で予め定められた回数の接続
をエンドユーザサーバ２に対して行い（Ｓ３２０）、１
回でもタイムアウトが発生した場合には（Ｓ３３０）、
その異常表示を行う（Ｓ３１０）。

【００６１】Ｓ３３０に於いてタイムアウトが発生しな
くとも、Ｓ３２０に於ける接続に於いて１回でも予め定
められた閾値の範囲内で処理が為されていなければ（Ｓ
３４０）、その処理は異常であると見なし、又Ｓ３３０
に於いてタイムアウトが発生したが異常がなかった場合
と併せて、入力ＩＰアドレスでの接続確認を行う（Ｓ３
５０）。

【００６２】Ｓ３５０に於いても同様に、予め定められ
た回数のＩＰアドレスによる接続を行い、１回でもタイ
ムアウトが発生した場合には、その接続ルートのチェッ
クを行う（Ｓ３６０）。又Ｓ３５０に於ける接続に於い
て１回でも予め定められた閾値の範囲内で処理が為され
ていなければ（Ｓ３７０）、その処理は異常であると見
なし、前記と同様に接続ルートのチェックを行う（Ｓ３
６０）。

【００６３】Ｓ３６０の接続ルートのチェックに於い
て、何れかの段階で応答がなくなった場合には、最終的
に到達することが出来たＩＰアドレスとＩＰアドレスに
基づいて管理者名との表示を行う（Ｓ３８０）。つま
り、最終的に到達することが出来たＩＰアドレスの次の
段階に於いて問題が発生していることが分かる。

【００６４】又Ｓ３６０のチェックに於いて応答があっ
ても、その応答の数が閾値の範囲を超えている場合には
（Ｓ３９０）、迂回的にネットワーク接続が行われてい
る可能性があるので接続ルートの表示を行う（Ｓ４０
０）。この際に行う表示項目としてはホスト名、ＩＰア
ドレス、応答時間等が好適である。又Ｓ３９０に於いて
閾値の範囲内である場合には、その状態、応答するのに
要した応答時間等を表示する（Ｓ４１０）。

【００６５】又Ｓ３５０に於ける接続に於いて予め定め
られた閾値の範囲内で処理が為されている場合には（Ｓ
３７０）、その状態、応答時間、取得ホスト名等の表示
を行う（Ｓ４２０）。又Ｓ３２０に於ける接続に於いて
も同様に、予め定められた閾値の範囲内で処理が為され
ている場合には（Ｓ３４０）、その状態、応答時間の表
示を行う（Ｓ４３０）。

【００６６】このような外部監視のプロセスを経ること
によって、実際にユーザ端末と同じ立場、即ちネットワ
ーク１３を介して監視を行うこととなるので、従来は検
出することが出来なかった、ユーザ端末とエンドユーザ
サーバ２との間のネットワーク障害、例えばＤＮＳサー
バのみの障害等であっても検出することが可能となる。

【００６７】又内部監視、外部監視の際に、従来型の障
害発生時のチェックのみならず、内部初期流動期間手段
６／外部初期流動期間手段１９に於いて取得したデータ
に基づいて、障害発生の予防措置を取る内部監視／外部
監視も併せて行う。図１０（ａ）に外部初期流動期間手
段１９が初期流動期間に収集したネットワークトラフィ
ック状態の概念図を示す。

【００６８】外部監視手段１１は、図１０（ａ）に示す
初期流動期間に於けるネットワークトラフィックを基準
として監視を行う。初期流動期間経過後のネットワーク
トラフィックの状況を図１０（ｂ）に示す。図１０
（ｂ）に於けるエンドユーザサーバ２の場合では土曜日
にネットワークトラフィックの最大の状態が周期的に現
れているが、エンドユーザサーバ２のネットワークトラ
フィックの使用傾向が、初期流動期間の使用傾向と比較
して上昇傾向にあり、又最大時の状態が予め定められた
値に近づいてきた場合（例えば８０％に継続的に達する
ようになった場合）には、エンドユーザサーバ２のネッ
トワークトラフィックがいずれ許容量をオーバーし障害
が発生する可能性が高まる。そこで、継続的に８０％に
達するようになった場合に外部監視手段１１が外部通知
手段２０を介して「ネットワークトラフィックが許容量
に近づいています。処理能力を向上させる等の処置を取
って下さい」等の警告を管理者等に通知する。これによ
って、エンドユーザサーバ２の障害発生を未然に防止す
ることが可能となる。

【００６９】従来は、ネットワークトラフィックのシス
テム状態のログを収集することは可能であったが、それ
に基づいて判断を行うには管理者等が自ら行わなければ
ならず、専門的知識が必要であった。又ログ自体はあっ
ても障害発生後に分析する、この場合はネットワーク処
理の遅延が発生する等の障害が発生し、その後ログを管
理者等が閲覧することによって、初めてネットワークト
ラフィックの許容量オーバーを知ることが出来、対策が
可能であった。即ち、一度障害が発生しないと対策を講
じるのは困難であった。しかし、本発明のような初期流
動期間に基づく外部監視を行うことによって、その障害
発生を未然に防止することが可能となる。

【００７０】同様に内部監視手段７が、内部初期流動期
間手段６に基づいて予防措置を取る監視の説明をする。
この一例としてディスク使用状況の監視の場合を説明し
図１１（ａ）に初期流動期間に於けるディスク使用状況
の概念図を示す。

【００７１】図１１（ｂ）に初期流動期間経過後のディ
スク使用状況を示す。図１１（ｂ）に於けるエンドユー
ザサーバ２の場合、初期流動期間でのディスク使用状況
の使用量の増加が３週間で１００ＭＢ（１００ＭＢの使
用量から２００ＭＢへの使用量の変化）となっている
が、初期流動期間経過後に於いては、同期間（３週間）
でのエンドユーザサーバ２のディスク使用状況が、初期
流動期間の使用量の増加と比較して増大傾向（４００Ｍ
Ｂの使用量から７００ＭＢへの使用量の変化）にあり、
又増加率も増えている。使用量が予め定められた値に近
づいてきた場合（例えば７００ＭＢに継続的に達するよ
うになった場合）には、エンドユーザサーバ２のディス
ク容量をオーバーし障害が発生する可能性が高まる。

【００７２】そこで継続的に７００ＭＢに達するように
なった場合に内部監視手段７が内部通知手段９を介して
「ディスク使用量が許容量に近づいています。処理能力
を向上させる等の処置を取って下さい」等の警告を管理
者等に通知する。これによってエンドユーザサーバ２の
障害発生を未然に防止することが可能となる。

【００７３】Ｓ１２０に於いて内部監視、外部監視の結
果をレポートとして出力をすることが好適である。又何
らかの障害が発生している場合には内部監視手段７、外
部監視手段１１が内部通知手段９／外部通知手段２０か
ら障害の通知を管理者等に行う。

【００７４】

【実施例２】エンドユーザサーバ２の管理者は何らかの
外部監視、内部監視システムを導入した場合には、その
導入の効果があったかどうかを把握することを希望する
ことが多い。しかし、従来は各エンドユーザサーバ２に
対してのみの外部監視、内部監視であったので、全体的
な効果を測定することは困難であった。そこで本発明者
は、実施例１のシステム構成に更に全体的な効果の測定
を行うことを可能とする総合管理サーバ１５を付加する
ことにより、これを実現せしめる管理サーバシステム１
とした。

【００７５】管理サーバシステム１は、エンドユーザサ
ーバ２とＥＵＳ管理サーバ３と総合管理サーバ１５とが
ネットワーク１３を介して接続している場合を説明す
る。図２にこの場合のシステム構成の一例であるシステ
ム構成図を示す。尚、本実施態様に於いて実施例１と同
様の部分については重複を避ける為、説明を省略する。

【００７６】ＥＵＳ管理サーバ３は、外部初期診断手段
１０、外部初期流動期間手段１９、外部監視手段１１、
ＥＵＳ受信手段１２、外部通知手段２０、報告手段１４
とを有している。

【００７７】報告手段１４は、ＥＵＳ管理サーバ３が各
エンドユーザサーバ２から受信した内部監視の情報及び
ＥＵＳ管理サーバ３による各エンドユーザサーバ２の外
部監視の情報とに基づいて、エンドユーザサーバ２のＮ
回目の障害発生時刻とエンドユーザサーバ２のＮ回目の
障害発生に対する応答時刻（即ちＮ回目の障害が復旧し
た時刻）とを総合管理サーバ１５にネットワーク１３を
介して送信する手段である。

【００７８】総合管理サーバ１５は、ＥＵＳ管理サーバ
受信手段１６、ＥＵＳ管理データベース１８、分析手段
１７とを有している。

【００７９】ＥＵＳ管理サーバ受信手段１６は、エンド
ユーザサーバ２のＮ回目の障害発生時刻とエンドユーザ
サーバ２のＮ回目の障害発生に対する応答時刻（即ちＮ
回目の障害が復旧した時刻）とをＥＵＳ管理サーバ３か
ら受信し、ＥＵＳ管理データベース１８に格納する手段
である。

【００８０】分析手段１７は、ＥＵＳ管理データベース
１８に格納している情報に基づいて、該当するエンドユ
ーザサーバ２のパフォーマンスが全体のどの付近に位置
しているかの分析を行う手段である。この際に分析を行
う項目としては、（１）該当するエンドユーザサーバ２のＮ回目のＭＴＢ
Ｆ（Mean Time BetweenFailure）（２）該当するエンドユーザサーバ２の平均ＭＴＢＦ（３）全てのエンドユーザサーバ２の平均ＭＴＢＦ（４）該当するエンドユーザサーバ２の全てのエンドユ
ーザサーバ２に対する偏差値（５）該当するエンドユーザサーバ２のＮ回目のＭＴＴ
Ｒ（Mean Time To Repair）（６）該当するエンドユーザサーバ２の平均ＭＴＴＲ（７）全てのエンドユーザサーバ２の平均ＭＴＴＲ（８）該当するエンドユーザサーバ２の全てのエンドユ
ーザサーバ２に対する偏差値を分析することが好適であるが、他の項目を行っても良
いしこれ以外であっても良い。

【００８１】ＭＴＢＦとは、エンドユーザサーバ２の障
害発生間隔を計算する項目であって、数１によって計算
することが出来る。

【数１】

【００８２】従って（２）は、数２によって計算するこ
とが出来る。

【数２】

【００８３】（３）は、全てのエンドユーザサーバ２
（例えばＸ台あったとする）の平均ＭＴＢＦであるの
で、数３によって計算することが出来る。

【数３】

【００８４】（４）は、全てのエンドユーザサーバ２に
対する該当するエンドユーザサーバ２の偏差値であるの
で、数４によって示される。

【数４】

【００８５】ＭＴＴＲとは、エンドユーザサーバ２に障
害が発生した際に、その障害から復旧した間隔を計算す
る項目であって、数５によって計算することが出来る。

【数５】

【００８６】従って（６）は数６のように計算すること
が出来る。

【数６】

【００８７】（７）は、全てのエンドユーザサーバ２の
平均ＭＴＴＲであるので、数７によって計算することが
出来る。

【数７】

【００８８】（８）は、全てのエンドユーザサーバ２に
対する該当するエンドユーザサーバ２の偏差値であるの
で、数８によって示される。

【数８】

【００８９】（１）から（８）の項目を分析手段１７が
分析を行うことによって、管理サーバシステム１が監視
対象とするエンドユーザサーバ２の全ての中で、そのエ
ンドユーザサーバ２が障害をどの位回避しているのか、
障害発生からどの位早く復旧しているのかを客観的に把
握させることが可能となり、これによって、管理者等は
管理サーバシステム１の導入の効果を知ることが可能と
なる。又、本実施態様に於いては、エンドユーザサーバ
２全てをその比較対象（母集団）としたが、任意のエン
ドユーザサーバ２のみを比較対象（母集団）としても良
いことは言うまでもない。

【００９０】ＥＵＳ管理データベース１８は、ＥＵＳ管
理サーバ受信手段１６が受信したエンドユーザサーバ２
のＮ回目の障害発生時刻とエンドユーザサーバ２のＮ回
目の障害発生に対する復旧時刻（即ちＮ回目の障害が復
旧した時刻）とを格納しているデータベースである。

【００９１】次に、本実施態様のプロセスの流れの一例
のフローチャート図を図６に示す。Ｓ５００からＳ５２
０は実施例１と同様なので省略する。

【００９２】Ｓ５２０に於ける内部監視の結果を内部監
視送信手段８がネットワーク１３を介してＥＵＳ管理サ
ーバ３に送信するとＥＵＳ管理サーバ３のＥＵＳ受信手
段１２に於いてその情報を受信する。

【００９３】受信した内部監視の結果と外部監視手段１
１による外部監視の結果に基づいて、エンドユーザサー
バ２のＮ回目の障害発生時刻とエンドユーザサーバ２の
Ｎ回目の障害発生に対する応答時刻（即ちＮ回目の障害
が復旧した時刻）とをＥＵＳ管理サーバ３の報告手段１
４が、総合管理サーバ１５にネットワーク１３を介して
送信する。ＥＵＳ管理サーバ３からの各エンドユーザサ
ーバ２の監視結果の情報を総合管理サーバ１５のＥＵＳ
管理サーバ受信手段１６が受信する（Ｓ５３０）。

【００９４】Ｓ５３０に於いて受信した情報をＥＵＳ管
理サーバ受信手段１６がＥＵＳ管理データベース１８に
格納する（Ｓ５４０）。

【００９５】分析手段１７は、定期的或いは不定期的に
ＥＵＳ管理データベース１８に格納している情報に基づ
いて、エンドユーザサーバ２毎、ＥＵＳ管理サーバ３
毎、全体等のＭＴＢＦ、ＭＴＴＲ等の分析を行う。ＥＵ
Ｓ管理サーバ３毎の分析結果の一例を図１２に示す（尚
図１２の分析結果に於いてはＥＵＳ管理サーバ３が複数
台のエンドユーザサーバ２を管理している場合を示して
いる）。これによって、管理サーバシステム１が監視対
象とするエンドユーザサーバ２の全ての中で、そのエン
ドユーザサーバ２が障害をどの位予防しているのか、障
害発生からどの位早く復旧しているのかを客観的に把握
させることが可能となり、これによって、管理者等は管
理サーバシステム１の導入の効果を知ることが可能とな
る。

【００９６】本発明に於ける各手段、データベースは、
その機能が論理的に区別されているのみであって、物理
上あるいは事実上は同一の領域を為していても良い。

【００９７】尚、本発明を実施するにあたり本実施態様
の機能を実現するソフトウェアのプログラムを記録した
記憶媒体をシステムに供給し、そのシステムのコンピュ
ータが記憶媒体に格納されたプログラムを読み出し実行
することによって実現されることは当然である。

【００９８】この場合、記憶媒体から読み出されたプロ
グラム自体が前記した実施態様の機能を実現することと
なり、そのプログラムを記憶した記憶媒体は本発明を当
然のことながら構成することになる。

【００９９】プログラムを供給する為の記憶媒体として
は、例えばフロッピー（登録商標）ディスク、ハードデ
ィスク、光ディスク、光磁気ディスク、磁気テープ、不
揮発性のメモリカード等を使用することができる。

【０１００】又、コンピュータが読み出したプログラム
を実行することにより、上述した実施態様の機能が実現
されるだけではなく、そのプログラムの指示に基づき、
コンピュータ上で稼働しているオペレーティングシステ
ムなどが実際の処理の一部又は全部を行い、その処理に
よって前記した実施態様の機能が実現される場合も含ま
れることは言うまでもない。

【０１０１】更に、記憶媒体から読み出されたプログラ
ムが、コンピュータに挿入された機能拡張ボードやコン
ピュータに接続された機能拡張ユニットに備わる不揮発
性あるいは揮発性の記憶手段に書き込まれた後、そのプ
ログラムの指示に基づき、機能拡張ボードあるいは機能
拡張ユニットに備わる演算処理装置などが実際の処理の
一部あるいは全部を行い、その処理により前記した実施
態様の機能が実現される場合も含まれることは当然であ
る。

【０１０２】

【発明の効果】本発明によって、エンドユーザサーバの
予め定めた初期稼働期間（以下、初期流動期間）のシス
テム状況に基づいて継続的な監視を行い障害発生の未然
防止を行うと共に、その監視をシステム状態の内部監視
とユーザとほぼ同様の立場からの監視を行う、即ちエン
ドユーザサーバのネットワーク状態の監視を行う実質上
の外部監視とを組み合わせ総合的に行うことによってエ
ンドユーザサーバの安定的管理を行う管理サーバシステ
ムが可能となる。

【０１０３】更にＭＴＢＦ、ＭＴＴＲ等の分析を行うこ
とによって、管理サーバシステムが監視対象とするエン
ドユーザサーバの全て（或いは一部）の中で、そのエン
ドユーザサーバが障害をどの位回避しているのか、障害
発生からどの位早く復旧しているのかを客観的に把握す
ることが可能となり、これによって、管理者等は管理サ
ーバシステムの導入の効果を知ることが可能となる。

【図面の簡単な説明】

【図１】本発明のシステム構成の一例を示すシステム
構成図である。

【図２】本発明のシステム構成の他の一例を示すシス
テム構成図である。

【図３】本発明のプロセスの流れの一例を示すフロー
チャート図である。

【図４】内部監視のプロセスの流れの一例を示すフロ
ーチャート図である。

【図５】外部監視のプロセスの流れの一例を示すフロ
ーチャート図である。

【図６】本発明のプロセスの流れの他の一例を示すフ
ローチャート図である。

【図７】初期診断結果レポートの一般的な情報を示す
レポートの概念図である。

【図８】初期診断結果レポートの内部初期診断の結果
を示すレポートの概念図である。

【図９】初期診断レポートの外部初期診断の結果を示
すレポートの概念図である。

【図１０】初期流動期間のネットワークトラフィックの
概念図である。

【図１１】初期流動期間のディスク使用状況の概念図で
ある。

【図１２】分析結果の一例である。

【符号の説明】

１：管理サーバシステム２：エンドユーザサーバ３：ＥＵＳ管理サーバ４：処理機構５：内部初期診断手段６：内部初期流動期間手段７：内部監視手段８：内部監視送信手段９：内部通知手段１０：外部初期診断手段１１：外部監視手段１２：ＥＵＳ受信手段１３：ネットワーク１４：報告手段１５：総合管理サーバ１６：ＥＵＳ管理サーバ受信手段１７：分析手段１８：ＥＵＳ管理データベース１９：外部初期流動期間手段２０：外部通知手段

───────────────────────────────────────────────────── フロントページの続きＦターム(参考） 5B042 GA10 JJ02 JJ03 JJ06 JJ15 JJ20 JJ36 JJ42 KK07 KK13 MC15 MC29 5B085 AC11 AC16 BG07 5B089 GA11 JA35 JB16 JB17 KA12 KB04 KC29 KC47 KC48 MC01 MC11

Claims

【特許請求の範囲】

【請求項１】エンドユーザサーバの監視を行う管理サー
バシステムに於いて、監視対象となるエンドユーザサー
バと前記エンドユーザサーバの外部監視を行うＥＵＳ管
理サーバとがネットワークを介して接続しており、前記
ＥＵＳ管理サーバは、前記エンドユーザサーバの処理を
行う処理機構が問題なく初期設定が為されているか否か
を内部から診断する内部初期診断手段と、前記内部初期
診断終了後から予め定められた期間の前記処理機構の使
用傾向を収集する内部初期流動期間手段と、前記処理機
構の内部監視を行う内部監視手段とを前記エンドユーザ
サーバが有しており、前記内部初期診断手段と前記内部
初期流動期間手段と前記内部監視手段とに於けるデータ
を前記エンドユーザサーバの内部監視送信手段から受信
するＥＵＳ受信手段と、前記エンドユーザサーバのネッ
トワーク状態が問題なく初期設定が為されているか否か
を前記ネットワークを介して外部から診断する外部初期
診断手段と、前記外部初期診断終了後から予め定められ
た期間の前記ネットワーク状態の使用傾向を収集する外
部初期流動期間手段と、前記ネットワーク状態の外部監
視を行う外部監視手段と、前記ＥＵＳ受信手段に於いて
受信したデータ及び／又は前記外部初期診断手段及び／
又は前記外部監視手段とに於いて前記処理機構及び／又
は前記ネットワーク状態に何らかの障害を検出した場合
に通知を行う外部通知手段とを有することを特徴とする
管理サーバシステム。
【請求項２】前記内部監視手段は、前記内部初期流動期
間手段に於いて収集した前記処理機構の使用傾向に基づ
いて、前記処理機構の障害発生を予測し、前記エンドユ
ーザサーバは、前記内部監視手段に於ける予測に基づい
て警告及び／又は処置方法を通知する内部通知手段とを
有することを特徴とする請求項１に記載の管理サーバシ
ステム。
【請求項３】前記外部監視手段は、前記外部初期診断手
段に於いて収集した前記エンドユーザサーバのネットワ
ーク状態の使用傾向に基づいて、前記ネットワーク状態
の障害発生を予測し、前記ＥＵＳ管理サーバは、前記外
部監視手段に於ける予測に基づいて警告及び／又は処置
方法を通知する外部通知手段とを有することを特徴とす
る請求項１に記載の管理サーバシステム。
【請求項４】前記内部初期流動期間手段は、前記処理機
構のＣＰＵ負荷率、メモリ使用率、ディスク使用状況、
サービス接続、サービスアプリケーション、修正モジュ
ールチェック、管理者権限パスワードエラーの回数のう
ち少なくとも一以上の使用傾向を収集することを特徴と
する請求項１又は請求項２に記載の管理サーバシステ
ム。
【請求項５】前記内部監視手段は、前記処理機構のＣＰ
Ｕ負荷率、メモリ使用率、ディスク使用状況、サービス
接続、サービスアプリケーション、修正モジュールチェ
ック、管理者権限パスワードエラーの回数のうち少なく
とも一以上の監視を行うことを特徴とする請求項１、請
求項２又は請求項４のいずれかに記載の管理サーバシス
テム。
【請求項６】前記外部初期流動期間手段は、前記ネット
ワーク状態のネットワーク接続、サービス接続、トラフ
ィック状態、ポート状況、メールオープンリレーチェッ
クのうち少なくとも一以上の使用傾向を収集することを
特徴とする請求項１又は請求項３に記載の管理サーバシ
ステム。
【請求項７】前記外部監視手段は、前記ネットワーク状
態のネットワーク接続、サービス接続、トラフィック状
態、ポート状況、メールオープンリレーチェックのうち
少なくとも一以上の監視を行うことを特徴とする請求項
１、請求項３又は請求項６のいずれかに記載の管理サー
バシステム。
【請求項８】前記管理サーバシステムは、前記エンドユ
ーザサーバのパフォーマンスの分析を行う総合管理サー
バと前記ＥＵＳ管理サーバとが前記ネットワークを介し
て接続しており、前記総合管理サーバは、前記ＥＵＳ管
理サーバから前記エンドユーザサーバの内部監視の情報
及び／又は外部監視の情報とを受信するＥＵＳ管理サー
バ受信手段と、前記ＥＵＳ管理サーバ受信手段に於いて
受信した情報を格納するＥＵＳ管理データベースと、前
記ＥＵＳ管理サーバ受信手段に於いて受信した情報及び
／又は前記ＥＵＳ管理データベースに格納している情報
とに基づいて、母集団とする全体又は一部のエンドユー
ザサーバに於いて、前記エンドユーザサーバのパフォー
マンスがどの位であるかの分析を行う分析手段とを有す
ることを特徴とする請求項１から請求項７のいずれかに
記載の管理サーバシステム。
【請求項９】前記ＥＵＳ管理サーバ受信手段は、前記Ｅ
ＵＳ管理サーバから前記エンドユーザサーバの障害発生
時刻と前記発生した障害に対する応答時刻とを受信する
ことを特徴とする請求項８に記載の管理サーバシステ
ム。
【請求項１０】前記分析手段は、前記エンドユーザサー
バのＭＴＢＦ、平均ＭＴＢＦ、母集団とする全て又は一
部のエンドユーザサーバの平均ＭＴＢＦ、前記母集団に
於ける前記エンドユーザサーバのＭＴＢＦに対する偏差
値、前記エンドユーザサーバのＭＴＴＲ、平均ＭＴＴ
Ｒ、前記母集団の平均ＭＴＴＲ、前記母集団に於ける前
記エンドユーザサーバのＭＴＴＲに対する偏差値のう
ち、少なくとも一以上を分析することを特徴とする請求
項８又は請求項９に記載の管理サーバシステム。
【請求項１１】エンドユーザサーバの監視を行う管理サ
ーバシステムに於いて、監視対象となるエンドユーザサ
ーバと前記エンドユーザサーバの外部監視を行うＥＵＳ
管理サーバと前記エンドユーザサーバのパフォーマンス
の分析を行う総合管理サーバとがネットワークを介して
接続しており、前記総合管理サーバは、前記ＥＵＳ管理
サーバが前記エンドユーザサーバから受信した内部監視
の情報と前記ＥＵＳ管理サーバによる前記エンドユーザ
サーバの外部監視の情報とを、前記ＥＵＳ管理サーバか
ら受信するＥＵＳ管理サーバ受信手段と、前記ＥＵＳ管
理サーバ受信手段に於いて受信した情報を格納するＥＵ
Ｓ管理データベースと、前記ＥＵＳ管理サーバ受信手段
に於いて受信した情報及び／又は前記ＥＵＳ管理データ
ベースに格納している情報とに基づいて、母集団とする
全体又は一部のエンドユーザサーバに於いて、前記エン
ドユーザサーバのパフォーマンスがどの位であるかの分
析を行う分析手段とを有することを特徴とする管理サー
バシステム。