JP4081258B2 - 管理サーバシステム - Google Patents

管理サーバシステム Download PDF

Info

Publication number
JP4081258B2
JP4081258B2 JP2001328802A JP2001328802A JP4081258B2 JP 4081258 B2 JP4081258 B2 JP 4081258B2 JP 2001328802 A JP2001328802 A JP 2001328802A JP 2001328802 A JP2001328802 A JP 2001328802A JP 4081258 B2 JP4081258 B2 JP 4081258B2
Authority
JP
Japan
Prior art keywords
end user
monitoring
internal
external
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2001328802A
Other languages
English (en)
Other versions
JP2003131905A (ja
Inventor
昭英 福島
浩 久米
Original Assignee
株式会社キューディファクトリ
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社キューディファクトリ filed Critical 株式会社キューディファクトリ
Priority to JP2001328802A priority Critical patent/JP4081258B2/ja
Publication of JP2003131905A publication Critical patent/JP2003131905A/ja
Application granted granted Critical
Publication of JP4081258B2 publication Critical patent/JP4081258B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Landscapes

  • Debugging And Monitoring (AREA)
  • Computer And Data Communications (AREA)

Description

【0001】
【発明の属する技術分野】
本発明は、ネットワーク上に於けるエンドユーザサーバを監視し、障害発生を未然に防止する為の管理サーバシステムに関する。更に詳細には、エンドユーザサーバの外部/内部の予め定められた初期期間の使用傾向に基づいてエンドユーザサーバを外部、内部の双方から監視し障害発生を未然に防止することを特徴とする管理サーバシステムに関する。
【0002】
【従来の技術】
エンドユーザサーバ(ネットワークの利用者(所謂個々のユーザ)が利用するサーバ。例えばプロバイダがユーザとの接続に用いるサーバ等を示す)は、その障害発生の防止、効率的運用の為に継続的な監視を行うことが一般的である。
【0003】
従来、このエンドユーザサーバを監視する方法としては、外部的な監視(以下、外部監視)、内部的な監視(以下、内部監視)の何れかを用いることによって行われている。外部的な監視とは、エンドユーザサーバに何らかの監視装置(ボード等)を設置し、エンドユーザサーバに何らかの障害が発生した場合に、前記監視装置から外部の指定先に対して障害通知を行う方法である。又、内部監視とはエンドユーザサーバのシステム状態(例えばメモリの使用状態等)を継続的に監視し、制限値まで到達した段階でエンドユーザサーバの管理者等に警告を発する、障害が発生した場合に自動復旧を行う等の方法である。
【0004】
【発明が解決しようとする課題】
上記の外部監視を用いた場合、何らかの障害が発生した段階で速やかに外部、例えば管理者や保守サービスマン等(以下、管理者等)に通知することは可能であるが、管理者等のローテーション、スケジュール等を勘案する必要性から多数の管理者等を通知先として確保しておく必要性がある。又実際に障害が発生してからの対応となるので、エンドユーザサーバのユーザは、障害発生時から障害復旧時迄の間、エンドユーザサーバからサービスを享受することが出来ない。更に管理者等の技術スキルにはバラツキがあり、技術スキルの高い者が行う場合には速やかなる復旧が行えるが、技術スキルの高くない者が行う場合には復旧までに相当の時間を要す場合がある。
【0005】
一方、内部監視を用いた場合、システム状態の継続監視から何らかの警告が発せられるのは、危険状態になった場合、障害が発生した場合であってその対応には専門的知識が必要となり、管理者等に対して相当の技術スキルを要求する。更に障害発生時に於いて、知識がない管理者等であっても復旧が行えるような自動復旧システムも存しており、その一例が特開2001−67288号公報に開示されている。
【0006】
この公報記載の発明は、予めデータベースに障害から復旧する為の方法を格納し、障害発生時にはこの方法に基づいて自動復旧を試みる。この方法で自動復旧が行えない場合には、障害に対するガイド情報を提供し管理者等による復旧を支援し、これでも復旧が行えない場合には障害内容と障害が発生したエンドユーザサーバのシステム情報とを予め定められているサーバ装置に送信し、保守サービスマンに通知する。保守サービスマンはこれらを閲覧することで更なるガイド情報、システム変更情報を作成し、ガイド情報の充実を図る方法である。
【0007】
しかしこの発明を用いた場合に於いても、この発明を利用することが出来るのはシステムの障害発生後であって、外部監視と同様に障害発生時から障害復旧時迄の間、エンドユーザサーバのユーザは、エンドユーザサーバからサービスを享受することが出来ない。
【0008】
【課題を解決するための手段】
ところで、従来のように障害発生時に速やかに対処することは重要であるが、エンドユーザサーバの運営上最も重要なことは障害を未然に防止することである。これを行う場合には、内部監視で用いられているシステム状態を常に管理者等が把握しておくのが通常である。しかし、前記のようにシステム状態を把握するには高度な専門的知識が必要であって、管理者等の技術スキルにバラツキがある現在に於いては、これを行うのは非常に困難である。特にシステム管理の為の専属の管理者等を任命することが困難な事業規模の大きくない企業等に於いては、実質的に不可能に近い。又内部監視でシステム状態(所謂システムログ)の記録は行っているが、そのシステム状態からどのような障害が将来的に発生するかを読みとれるか否かは、管理者等の技術スキルに左右されてしまう為、障害を未然に防止するには管理者等次第となってしまう。
【0009】
又、上記外部監視の手法も何らかの障害が発生した段階でエンドユーザサーバから管理者等に通知するものであるので、内部監視の通知のみを外部に行っているにすぎず、実質上は内部監視とほぼ同一である。
【0010】
従って、エンドユーザサーバとユーザが利用しているユーザ端末との間に存在するシステム(例えばDNSサーバ)に障害が発生している場合には、その障害そのものを発見することが出来ない。
【0011】
つまり、例えばDNSサーバのみに障害がある場合には、上記手法を用いる外部監視、内部監視であってもエンドユーザサーバ自体は正常に機能しているので何らの障害も発見は出来ない。しかしユーザ端末がDNSサーバを介してエンドユーザサーバにアクセスする場合には、DNSサーバに障害が発生しているのでエンドユーザサーバの利用が行うことは出来ないこととなる。従ってユーザからの通知に因らない限り管理者等はDNSサーバの障害を知ることが出来ない為、障害発生時から障害復旧迄の期間が長期化することとなる。
【0012】
従って外部監視、内部監視の何れか一つの監視手法を用いた場合では、上記のように何らかの問題点が存在している。更に、外部監視、内部監視の2つの監視システムを導入することも可能であるが、これら2つの監視システムが作成するシステム状態等のレポートは、各々の立場に因るものであるので連携が取れておらず、そこから総合的な評価を更に行う場合には、その2つの監視システムが作成したレポートに基づいて管理者等自らが行わなければならない。
【0013】
又内部監視と同様に外部監視に於いても障害発生の未然防止を行うことが重要であるが、これを行うにはネットワークトラフィックを常に監視する、ネットワークエラーの発生を常に監視する等を恒常的に行わなくてはならない。又単に記録(ログ)を取ることは可能であってもその記録(ログ)自体から障害発生を予測することは、管理者等の経験と知識とに頼らなくてはいけない為、エンドユーザサーバの管理を行う全ての管理者等の経験と知識とを一定水準に保つのは困難であることから、個々のエンドユーザサーバに於いて障害発生度にバラツキが発生することとなり、全体のシステムの安定的な運用に欠ける。
【0014】
例えばある企業のシステム環境を経験、知識が共に豊富である管理者Aと経験、知識が共に浅い管理者Bの2名で分担して管理している場合、必然的に管理者Bの管理下にあるエンドユーザサーバでの障害発生度が高くなる。従って、管理者Bの管理下にあるエンドユーザサーバで障害発生が起こる毎に管理者Aの管理下にあるエンドユーザサーバに対して処理が集中し、管理者Aの管理下のエンドユーザサーバでも障害発生が起こりやすくなってしまい、相対的にシステムの安定的運用が損なわれてしまう。
【0015】
従来はこれを回避する為に管理者の知識、経験の向上、管理人数等の増加等の人為的側面から対処していたが、それには多大なる費用、時間を要することとなる。従って、システム的に何らかの障害発生を未然に防止する必要性がある。
【0016】
そこで本発明者は、エンドユーザサーバの予め定めた初期稼働期間(以下、初期流動期間)のシステム状況に基づいて継続的な監視を行い障害発生の未然防止を行うと共に、その監視をシステム状態の内部監視とユーザとほぼ同様の立場からの監視を行う、即ちエンドユーザサーバのネットワーク状態の監視を行う実質上の外部監視とを組み合わせ総合的に行うことによってエンドユーザサーバの安定的管理を行う管理サーバシステムを発明した。
【0017】
更にエンドユーザサーバの管理者は何らかの外部監視、内部監視システムを導入した場合には、その導入の効果があったかどうかを把握することを希望することが多い。しかし、従来は各エンドユーザサーバに対してのみの外部監視、内部監視であったので、全体的な効果を測定することは困難であった。そこで本発明者は、上記発明の他に更に全体的な監視効果の分析を行うことが可能となる管理サーバシステムを発明した。
【0018】
請求項1の発明は、エンドユーザサーバの監視を行う管理サーバシステムであって、監視対象となるエンドユーザサーバと前記エンドユーザサーバの外部監視を行うEUS管理サーバとがネットワークを介して接続しており、前記エンドユーザサーバは、前記エンドユーザサーバの処理を行う処理機構が正常な状態であるかを、前記処理機構を含むエンドユーザサーバの内部から診断する内部初期診断手段と、前記内部初期診断終了後から予め定められた内部初期流動期間における、前記エンドユーザサーバの、CPU負荷率、メモリ使用率、ディスク使用状況、サービスアプリケーションの稼働状況、最新の修正モジュールがOSまたはアプリケーションに適用されているか否か、パスワードエラーの回数のうちいずれか一以上を含む情報を、内部初期流動期間の内部監視の情報として収集する内部初期流動期間手段と、前記エンドユーザサーバにおける前記内部監視の情報を取得することで、前記エンドユーザサーバの内部監視を実行する内部監視手段と、前記内部監視の結果を前記EUS管理サーバに送信する内部監視送信手段と、を有しており、前記EUS管理サーバは、前記エンドユーザサーバから少なくとも前記内部監視の結果を受信するEUS受信手段と、前記エンドユーザサーバとの接続が正常な状態であるかを、前記ネットワークを介して前記エンドユーザサーバの外部から診断する外部初期診断手段と、前記外部初期診断終了後から予め定められた外部初期流動期間におけるネットワーク接続、トラフィック状態、サービス接続、ポート状況、メールオープンリレーチェックのうちいずれか一以上を含む情報を、外部初期流動期間の外部監視の情報として収集する外部初期流動期間手段と、前記エンドユーザサーバのネットワークにおける前記外部監視の情報を取得することで、前記エンドユーザサーバのネットワークの外部監視を実行する外部監視手段と、前記EUS受信手段において受信した前記エンドユーザサーバの内部監視の結果と、前記外部監視手段により監視を行った外部監視の結果とを通知する外部通知手段と、を有する管理サーバシステムである。
【0019】
本発明によって、従来のように内部監視、外部監視の何れか一つの監視ではなく、内部監視及び外部監視を複合的に行う管理サーバシステムが可能となる。これによって2つの監視システムが従来別々に作成しているレポートを、内部及び外部の双方から総合的な評価を行うことが可能となる。
【0020】
更に、外部監視も従来のようにサーバに何らかの装置(例えばボード等のハードウェア)を設置し、障害が発生した段階に於いて外部の管理者等に通知するのみの外部監視ではなく、実際にユーザと同等の立場である、ネットワークを介してエンドユーザサーバのネットワーク状態の外部監視を行うことが可能となる。これによって、従来の監視では検出出来なかった、ユーザとエンドユーザサーバとの間の障害(例えばDNSサーバのみの障害)を検出することも可能となる。
また、障害の発生を未然に防止する際に上述の各要素の使用傾向を分析することが好適であり、これらの要素少なくとも一以上の内部監視/外部監視を行うことによって、効率的に監視を行うことが可能となる。
【0021】
請求項2の発明において、前記内部監視手段は、更に、前記エンドユーザサーバにおける前記内部監視の情報を取得し、前記取得した内部監視の情報を、前記内部初期流動期間手段で収集した内部初期流動期間の内部監視の情報と比較することで、前記エンドユーザサーバの内部監視を実行し、前記エンドユーザサーバは、更に、前記内部監視手段の内部監視の結果に基づいて警告及び/又は処置方法を通知する内部通知手段、を有する管理サーバシステムである。
【0022】
請求項3の発明において、前記外部監視手段は、更に、 前記エンドユーザサーバのネットワークの前記外部監視の情報を取得し、前記取得した外部監視の情報を、前記外部初期流動期間手段で収集した外部初期流動期間の外部監視の情報と比較することで、前記エンドユーザサーバのネットワークの外部監視を実行し、前記外部通知手段は、更に、前記外部監視手段の外部監視の結果に基づいて警告及び/又は処置方法を通知する管理サーバシステムである。
【0023】
請求項2及び請求項3の発明によって、従来の監視システムのように、障害発生後に初めて何らかの通知が為される監視システムではなく、当初の使用傾向に基づいて以後の障害発生を予測し、障害の発生を未然に防止することが可能となる。これによってエンドユーザサーバを運営する際に最も重要である障害の回避が行え、障害の発生そのものを逓減することが可能となる。
【0029】
請求項4の発明において、前記管理サーバシステムは、更に、前記エンドユーザサーバのパフォーマンスの分析を行う総合管理サーバと前記EUS管理サーバとが前記ネットワークを介して接続しており、前記総合管理サーバは、前記EUS管理サーバから前記エンドユーザサーバの内部監視の情報及び/又は外部監視の情報とを受信するEUS管理サーバ受信手段と、前記EUS管理サーバ受信手段にいて受信した情報を格納するEUS管理データベースと、前記EUS管理サーバ受信手段にいて受信した情報及び/又は前記EUS管理データベースに格納している情報に基づいて、前記管理サーバシステムが監視対象とするエンドユーザサーバの一部または全部の母集団のうち、前記エンドユーザサーバのパフォーマンスが前記管理サーバシステムにおいてどの位であるかの分析を行う分析手段と、を有する管理サーバシステムである。
【0030】
本発明によって、内部監視/外部監視のみならず、エンドユーザサーバに本監視システムを用いた客観的な効果を分析することが可能となる。これによって、エンドユーザサーバの管理者等は、内部監視/外部監視の効果を把握することが出来る。
【0031】
請求項5の発明において、前記EUS管理サーバ受信手段は、前記EUS管理サーバから前記エンドユーザサーバの障害発生時刻と前記発生した障害から復旧した時刻とを受信する、管理サーバシステムである。
【0032】
請求項6の発明において、前記分析手段は、前記エンドユーザサーバのMTBF、平均MTBF、前記母集団とする全てまたは一部のエンドユーザサーバの平均MTBF、前記母集団にける前記エンドユーザサーバのMTBFに対する偏差値、前記エンドユーザサーバのMTTR、平均MTTR、前記母集団の平均MTTR、前記母集団にける前記エンドユーザサーバのMTTRに対する偏差値のうち、少なくとも一以上を分析する、管理サーバシステムである。
【0033】
請求項及び請求項の発明によって、エンドユーザサーバに本管理サーバシステムを用いた場合の客観的効果を分析する際に、MTBF、MTTR等を分析対象とすることによって、その効果を測定することが可能となる。
【0034】
尚、MTBFとはエンドユーザサーバの障害発生間隔を計算する公知の手法であって、MTTRとはエンドユーザサーバの障害発生時に於ける障害からの復旧間隔を計算する公知の手法である。これらの計算手法は数1から数8に後述する。
【0035】
請求項の発明は、監視対象となるエンドユーザサーバの外部監視をネットワークを介して行うEUS管理サーバであって、前記EUS管理サーバは、前記エンドユーザサーバの処理を行う処理機構が正常な状態であるかを、前記処理機構を含むエンドユーザサーバの内部から診断する内部初期診断手段と、前記内部初期診断終了後から予め定められた内部初期流動期間における、前記エンドユーザサーバの、CPU負荷率、メモリ使用率、ディスク使用状況、サービスアプリケーションの稼働状況、最新の修正モジュールがOSまたはアプリケーションに適用されているか否か、パスワードエラーの回数のうちいずれか一以上を含む情報を、内部初期流動期間の内部監視の情報として収集する内部初期流動期間手段と、前記エンドユーザサーバにおける前記内部監視の情報を取得することで、前記エンドユーザサーバの内部監視を実行する内部監視手段と、前記内部監視の結果を前記EUS管理サーバに送信する内部監視送信手段と、を有する前記エンドユーザサーバから、前記エンドユーザサーバの内部監視の結果を受信するEUS受信手段と、前記エンドユーザサーバとの接続が正常な状態であるかを、前記ネットワークを介して前記エンドユーザサーバの外部から診断する外部初期診断手段と、前記外部初期診断終了後から予め定められた外部初期流動期間におけるネットワーク接続、トラフィック状態、サービス接続、ポート状況、メールオープンリレーチェックのうちいずれか一以上を含む情報を、外部初期流動期間の外部監視の情報として収集する外部初期流動期間手段と、前記エンドユーザサーバのネットワークにおける前記外部監視の情報を取得することで、前記エンドユーザサーバのネットワークの外部監視を実行する外部監視手段と、前記EUS受信手段において受信した前記エンドユーザサーバの内部監視の結果と、前記外部監視手段により監視を行った外部監視の結果とを通知する外部通知手段と、を有するEUS管理サーバである。
【0037】
【発明の実施の形態】
本発明のシステム構成の実施態様の一例を図1のシステム構成図に示す。管理サーバシステム1は、エンドユーザサーバ2とEUS管理サーバ3とがネットワーク13を介して接続している場合を説明する。
【0038】
エンドユーザサーバ2は、ユーザ端末に対して何らかのサービスを提供するサーバであって、例えばプロバイダのサーバ等を示し、本発明に於いて監視対象となるサーバである。エンドユーザサーバ2は、処理機構4、内部初期診断手段5、内部初期流動期間手段6、内部監視手段7、内部監視送信手段8、内部通知手段9とを有している。
【0039】
処理機構4は、エンドユーザサーバ2の処理を行う機構であって、監視対象となる一般的なサーバ自体である。
【0040】
内部初期診断手段5は、処理機構4を含むエンドユーザサーバ2の内部から初期診断を行う手段である。ここで内部初期診断とは、監視対象として監視を行う際に最初に行う診断であって、エンドユーザサーバ2の処理機構4が正常な状態、即ち問題なく初期設定が為されているか否かを内部から診断する手段である。
【0041】
内部初期流動期間手段6は、初期診断終了後から予め定められた期間(例えば4週間)に於いて、エンドユーザサーバ2の処理機構4がどのようなシステム状態に於いて使用されるか(即ちエンドユーザサーバ2の使用傾向を把握する)データ収集を行う手段である。例えばエンドユーザサーバ2の処理機構4に於けるディスク使用状況の傾向等を収集する。
【0042】
処理機構4の使用傾向は、個々のシステム目的、システム環境に於いて異なるのが通常である。そこで平均的なエンドユーザサーバ2の処理機構4のシステム状態を参考として継続監視を行うのが従来であるが、この方法を用いた場合ではシステム目的、システム環境等に適した継続監視を行うことが困難である。そこで本発明では初期流動期間(例えば3週間)を設定し、どのような使用傾向があるか、即ちエンドユーザサーバ2独自の使用傾向のデータ収集を行い、以後の継続監視の基準とすることによって、エンドユーザサーバ2の処理機構4の使用傾向を踏まえた形での継続監視を行い、警告等を行うことによって、障害発生を予防することとが可能となる。更にエンドユーザサーバ2の処理機構4の初期の状態では複雑、余計な処理、ファイル等がほとんど含まれていないので、最初に傾向把握を行うことが好適である。
【0043】
内部監視手段7は、処理機構4のシステム状態の内部監視を行う手段である。内部監視には例えばCPU負荷率の監視、メモリ使用率の監視(メモリの使用状態の監視)、ディスク使用状況の監視、サービス接続の監視(サービスに接続しサービスが行われている否かの監視)、サービスアプリケーションの監視(サービスアプリケーションの稼働状況の監視)、修正モジュールチェックの監視(OS、アプリケーションに最新の修正モジュールが適用されているか否か)、管理者権限パスワードエラー回数(管理者権限でログイン使用とした時のパスワードエラーの回数取得)等がある。
【0044】
内部監視送信手段8は、内部監視手段7に於いて行う内部監視の情報をEUS管理サーバ3(後述)に送信する手段である。
【0045】
内部通知手段9は、内部監視手段7に於いて何らかの障害が発生しそうだという状況を事前に検出し、その通知及び参考となる処置とをエンドユーザサーバ2に通知する手段である。
【0046】
EUS管理サーバ3は、少なくとも一以上の監視対象となるエンドユーザサーバ2の外部監視を行うサーバであって、外部初期診断手段10、外部初期流動期間手段19、外部監視手段11、EUS受信手段12、外部通知手段20とを有している。
【0047】
外部初期診断手段10は、処理機構4を含むエンドユーザサーバ2のネットワーク状態の外部初期診断を行う手段である。ここで外部初期診断とは、管理サーバシステム1が監視対象として監視を行う際に最初に行う診断であって、エンドユーザサーバ2のネットワーク状態が正常な状態、即ち問題なく初期設定が為されているか否かをネットワーク13を介して外部から診断する。ここで、ネットワーク状態の監視とは、ネットワーク接続の監視(PINGによるネットワーク状態の監視、障害箇所検索)、トラフィック状態の監視(ネットワークトラフィックの監視)、サービス接続の監視(サービスに接続しサービスが行われているか否かを監視)、ポート状況の監視(エンドユーザサーバ2のサービスポート使用状態の監視)、メールオープンリレーチェック(エンドユーザが使用しているメールサーバが不正な中継を行うか否か)等がある。
【0048】
外部初期流動期間手段19は、初期診断終了後から予め定められた期間(例えば4週間)に於いて、エンドユーザサーバ2のネットワーク状態がどのような使用傾向であるかのデータ収集を行う手段である。例えばエンドユーザサーバ2のネットワークトラフィック状態の収集がある。
【0049】
外部監視手段11は、ネットワーク13を介してエンドユーザサーバ2の外部監視を行う手段であり、主にエンドユーザサーバ2とのネットワーク13の状態を監視する手段である。
【0050】
従来の外部監視は、エンドユーザサーバ2にボード等の監視装置を設置し、エンドユーザサーバ2に障害が発生した時点に於いて予め定められた外部に対して通知を行うという方法(即ち内部の障害を外部に通知する方法)であった。しかしこのような外部監視の方法では、エンドユーザサーバ2が接続しているネットワーク13の状態までを把握することが困難である。そこで本発明ではユーザ端末と同様の状態、即ちユーザ端末がエンドユーザサーバ2にアクセスする状態と同様にネットワーク13を介してエンドユーザサーバ2にアクセスを行い、そのネットワーク13の状態の監視を行うことによって、従来の外部、内部監視では行うことの出来なかった、ユーザの立場からの監視が可能となる。
【0051】
EUS受信手段12は、エンドユーザサーバ2の内部監視送信手段8から、内部監視の情報を受信する手段である。
【0052】
外部通知手段20は、EUS受信手段12が各エンドユーザサーバ2から受信した内部監視の情報及びEUS管理サーバ3による各エンドユーザサーバ2の外部監視の情報とに基づいて、何らかの障害が発生しそうだという状況を予め検出し、その通知及び参考となる処置をEUS管理サーバ3の管理者等に通知する手段である。
【0053】
【実施例】
次に本発明のプロセスの流れの一例を図3のフローチャート図を用いて詳細に説明する。
【0054】
監視を希望するエンドユーザサーバ2の管理者等は、エンドユーザサーバ2の初期設定後、エンドユーザサーバ2内の内部初期診断手段5及びEUS管理サーバ3内の外部初期診断手段10とを用い、エンドユーザサーバ2の処理機構4及びエンドユーザサーバ2のネットワーク状態とが正常な状態、即ち監視をしても問題ないか否かを内部及び外部から診断を行う(S100)。初期診断の結果は、紙媒体、電子媒体等を用いてその初期診断結果レポートを作成することが好適である。図7から図9に初期診断結果レポートの一例を示す。図7はEUS管理サーバ3に関する一般的な情報を示すレポートであり、図8は内部初期診断の結果を示すレポートであり、図9は外部初期診断の結果を示すレポートである。
【0055】
S100に於いて初期診断終了後、エンドユーザサーバ2の処理機構4及びネットワーク状態に於いて何らかの問題が発生している(例えばディスク不良等)場合には、その問題を内部初期診断手段5/外部初期診断手段10が内部通知手段9/外部通知手段20を介して通知を行う。又S100の初期診断に於いて何らの問題が発生していなければ、エンドユーザサーバ2のシステム運用の開始を行う。内部初期流動期間手段6/外部初期流動期間手段19がこの時点から初期流動期間を開始し、予め定めた期間(例えば3週間)のエンドユーザサーバ2の処理機構4及びネットワーク状態のデータ収集を開始する(S110)。
【0056】
又S110に於ける初期流動期間のデータ収集と並行して、エンドユーザサーバ2の処理機構4の内部監視を内部監視手段7が行い、エンドユーザサーバ2のサービス状態の外部監視をEUS管理サーバ3の外部監視手段11が行う(S120)。内部監視には、例えばCPU負荷率の監視、メモリ使用率の監視、ディスク使用状況の監視、サービス接続の監視、サービスアプリケーションの監視、修正モジュールチェック、管理者権限パスワードエラー回数の監視等があり、外部監視には、ネットワーク接続の監視、トラフィック状態の監視、サービス接続の監視、ポート状況の監視、メールオープンリレーチェック等がある。又内部監視の結果をネットワーク13を介して内部監視送信手段8がEUS管理サーバ3に送信する。
【0057】
本実施態様に於いては内部監視として、サービス接続監視の場合のプロセスの流れを図4のフローチャート図を用いて説明し、外部監視として、ネットワーク接続監視を行うプロセスの流れを図5のフローチャート図を用いて説明する。
【0058】
先ず図4を用いて内部監視の場合を説明する。この処理内容は、IPアドレスとポート番号とにより該当のサービスに対して接続状態を取得し、結果表示を行う監視である。内部監視がスタートすると、内部監視手段7が、IPアドレス、ポート番号で接続状況を確認し(S200)、何らかのパラメータに障害が発生している場合には、そのパラメータ異常を内部通知手段9を介して表示する(S210)。又S200に於いて何らパラメータ自体が正常であって、予め定められた時間内に応答があった場合には、正常な状態であると判断し、その状態と応答するのに要した応答時間とを表示する(S220)。一方、予め定められた時間内に応答がない場合、即ちタイムアウトした場合には、障害状態と判断し障害状態の表示を行う(S230)。これらを該当サービス分反復することによって、内部監視を行う。
【0059】
次に図5を用いて外部監視の場合を説明する。この処理内容は、入力ホスト名又は入力IPアドレスでエンドユーザサーバ2の接続状態を取得し、正常であれば該当値を返し、障害が発生していれば障害箇所を特定しその情報を取得する結果を結果表示を行う監視である。外部監視がスタートすると、外部監視手段11がパラメータの状況を確認する(S300)。パラメータに何らかの異常がある場合には、その異常表示を行う(S310)。
【0060】
S300に於いて異常がなければ、外部監視手段11が入力ホスト名で予め定められた回数の接続をエンドユーザサーバ2に対して行い(S320)、1回でもタイムアウトが発生した場合には(S330)、その異常表示を行う(S310)。
【0061】
S330に於いてタイムアウトが発生しなくとも、S320に於ける接続に於いて1回でも予め定められた閾値の範囲内で処理が為されていなければ(S340)、その処理は異常であると見なし、又S330に於いてタイムアウトが発生したが異常がなかった場合と併せて、入力IPアドレスでの接続確認を行う(S350)。
【0062】
S350に於いても同様に、予め定められた回数のIPアドレスによる接続を行い、1回でもタイムアウトが発生した場合には、その接続ルートのチェックを行う(S360)。又S350に於ける接続に於いて1回でも予め定められた閾値の範囲内で処理が為されていなければ(S370)、その処理は異常であると見なし、前記と同様に接続ルートのチェックを行う(S360)。
【0063】
S360の接続ルートのチェックに於いて、何れかの段階で応答がなくなった場合には、最終的に到達することが出来たIPアドレスとIPアドレスに基づいて管理者名との表示を行う(S380)。つまり、最終的に到達することが出来たIPアドレスの次の段階に於いて問題が発生していることが分かる。
【0064】
又S360のチェックに於いて応答があっても、その応答の数が閾値の範囲を超えている場合には(S390)、迂回的にネットワーク接続が行われている可能性があるので接続ルートの表示を行う(S400)。この際に行う表示項目としてはホスト名、IPアドレス、応答時間等が好適である。又S390に於いて閾値の範囲内である場合には、その状態、応答するのに要した応答時間等を表示する(S410)。
【0065】
又S350に於ける接続に於いて予め定められた閾値の範囲内で処理が為されている場合には(S370)、その状態、応答時間、取得ホスト名等の表示を行う(S420)。又S320に於ける接続に於いても同様に、予め定められた閾値の範囲内で処理が為されている場合には(S340)、その状態、応答時間の表示を行う(S430)。
【0066】
このような外部監視のプロセスを経ることによって、実際にユーザ端末と同じ立場、即ちネットワーク13を介して監視を行うこととなるので、従来は検出することが出来なかった、ユーザ端末とエンドユーザサーバ2との間のネットワーク障害、例えばDNSサーバのみの障害等であっても検出することが可能となる。
【0067】
又内部監視、外部監視の際に、従来型の障害発生時のチェックのみならず、内部初期流動期間手段6/外部初期流動期間手段19に於いて取得したデータに基づいて、障害発生の予防措置を取る内部監視/外部監視も併せて行う。図10(a)に外部初期流動期間手段19が初期流動期間に収集したネットワークトラフィック状態の概念図を示す。
【0068】
外部監視手段11は、図10(a)に示す初期流動期間に於けるネットワークトラフィックを基準として監視を行う。初期流動期間経過後のネットワークトラフィックの状況を図10(b)に示す。図10(b)に於けるエンドユーザサーバ2の場合では土曜日にネットワークトラフィックの最大の状態が周期的に現れているが、エンドユーザサーバ2のネットワークトラフィックの使用傾向が、初期流動期間の使用傾向と比較して上昇傾向にあり、又最大時の状態が予め定められた値に近づいてきた場合(例えば80%に継続的に達するようになった場合)には、エンドユーザサーバ2のネットワークトラフィックがいずれ許容量をオーバーし障害が発生する可能性が高まる。そこで、継続的に80%に達するようになった場合に外部監視手段11が外部通知手段20を介して「ネットワークトラフィックが許容量に近づいています。処理能力を向上させる等の処置を取って下さい」等の警告を管理者等に通知する。これによって、エンドユーザサーバ2の障害発生を未然に防止することが可能となる。
【0069】
従来は、ネットワークトラフィックのシステム状態のログを収集することは可能であったが、それに基づいて判断を行うには管理者等が自ら行わなければならず、専門的知識が必要であった。又ログ自体はあっても障害発生後に分析する、この場合はネットワーク処理の遅延が発生する等の障害が発生し、その後ログを管理者等が閲覧することによって、初めてネットワークトラフィックの許容量オーバーを知ることが出来、対策が可能であった。即ち、一度障害が発生しないと対策を講じるのは困難であった。しかし、本発明のような初期流動期間に基づく外部監視を行うことによって、その障害発生を未然に防止することが可能となる。
【0070】
同様に内部監視手段7が、内部初期流動期間手段6に基づいて予防措置を取る監視の説明をする。この一例としてディスク使用状況の監視の場合を説明し図11(a)に初期流動期間に於けるディスク使用状況の概念図を示す。
【0071】
図11(b)に初期流動期間経過後のディスク使用状況を示す。図11(b)に於けるエンドユーザサーバ2の場合、初期流動期間でのディスク使用状況の使用量の増加が3週間で100MB(100MBの使用量から200MBへの使用量の変化)となっているが、初期流動期間経過後に於いては、同期間(3週間)でのエンドユーザサーバ2のディスク使用状況が、初期流動期間の使用量の増加と比較して増大傾向(400MBの使用量から700MBへの使用量の変化)にあり、又増加率も増えている。使用量が予め定められた値に近づいてきた場合(例えば700MBに継続的に達するようになった場合)には、エンドユーザサーバ2のディスク容量をオーバーし障害が発生する可能性が高まる。
【0072】
そこで継続的に700MBに達するようになった場合に内部監視手段7が内部通知手段9を介して「ディスク使用量が許容量に近づいています。処理能力を向上させる等の処置を取って下さい」等の警告を管理者等に通知する。これによってエンドユーザサーバ2の障害発生を未然に防止することが可能となる。
【0073】
S120に於いて内部監視、外部監視の結果をレポートとして出力をすることが好適である。又何らかの障害が発生している場合には内部監視手段7、外部監視手段11が内部通知手段9/外部通知手段20から障害の通知を管理者等に行う。
【0074】
【実施例2】
エンドユーザサーバ2の管理者は何らかの外部監視、内部監視システムを導入した場合には、その導入の効果があったかどうかを把握することを希望することが多い。しかし、従来は各エンドユーザサーバ2に対してのみの外部監視、内部監視であったので、全体的な効果を測定することは困難であった。そこで本発明者は、実施例1のシステム構成に更に全体的な効果の測定を行うことを可能とする総合管理サーバ15を付加することにより、これを実現せしめる管理サーバシステム1とした。
【0075】
管理サーバシステム1は、エンドユーザサーバ2とEUS管理サーバ3と総合管理サーバ15とがネットワーク13を介して接続している場合を説明する。図2にこの場合のシステム構成の一例であるシステム構成図を示す。尚、本実施態様に於いて実施例1と同様の部分については重複を避ける為、説明を省略する。
【0076】
EUS管理サーバ3は、外部初期診断手段10、外部初期流動期間手段19、外部監視手段11、EUS受信手段12、外部通知手段20、報告手段14とを有している。
【0077】
報告手段14は、EUS管理サーバ3が各エンドユーザサーバ2から受信した内部監視の情報及びEUS管理サーバ3による各エンドユーザサーバ2の外部監視の情報とに基づいて、エンドユーザサーバ2のN回目の障害発生時刻とエンドユーザサーバ2のN回目の障害発生に対する応答時刻(即ちN回目の障害が復旧した時刻)とを総合管理サーバ15にネットワーク13を介して送信する手段である。
【0078】
総合管理サーバ15は、EUS管理サーバ受信手段16、EUS管理データベース18、分析手段17とを有している。
【0079】
EUS管理サーバ受信手段16は、エンドユーザサーバ2のN回目の障害発生時刻とエンドユーザサーバ2のN回目の障害発生に対する応答時刻(即ちN回目の障害が復旧した時刻)とをEUS管理サーバ3から受信し、EUS管理データベース18に格納する手段である。
【0080】
分析手段17は、EUS管理データベース18に格納している情報に基づいて、該当するエンドユーザサーバ2のパフォーマンスが全体のどの付近に位置しているかの分析を行う手段である。この際に分析を行う項目としては、
(1)該当するエンドユーザサーバ2のN回目のMTBF(Mean Time Between Failure)
(2)該当するエンドユーザサーバ2の平均MTBF
(3)全てのエンドユーザサーバ2の平均MTBF
(4)該当するエンドユーザサーバ2の全てのエンドユーザサーバ2に対する偏差値
(5)該当するエンドユーザサーバ2のN回目のMTTR(Mean Time To Repair)
(6)該当するエンドユーザサーバ2の平均MTTR
(7)全てのエンドユーザサーバ2の平均MTTR
(8)該当するエンドユーザサーバ2の全てのエンドユーザサーバ2に対する偏差値
を分析することが好適であるが、他の項目を行っても良いしこれ以外であっても良い。
【0081】
MTBFとは、エンドユーザサーバ2の障害発生間隔を計算する項目であって、数1によって計算することが出来る。
【数1】
Figure 0004081258
【0082】
従って(2)は、数2によって計算することが出来る。
【数2】
Figure 0004081258
【0083】
(3)は、全てのエンドユーザサーバ2(例えばX台あったとする)の平均MTBFであるので、数3によって計算することが出来る。
【数3】
Figure 0004081258
【0084】
(4)は、全てのエンドユーザサーバ2に対する該当するエンドユーザサーバ2の偏差値であるので、数4によって示される。
【数4】
Figure 0004081258
【0085】
MTTRとは、エンドユーザサーバ2に障害が発生した際に、その障害から復旧した間隔を計算する項目であって、数5によって計算することが出来る。
【数5】
Figure 0004081258
【0086】
従って(6)は数6のように計算することが出来る。
【数6】
Figure 0004081258
【0087】
(7)は、全てのエンドユーザサーバ2の平均MTTRであるので、数7によって計算することが出来る。
【数7】
Figure 0004081258
【0088】
(8)は、全てのエンドユーザサーバ2に対する該当するエンドユーザサーバ2の偏差値であるので、数8によって示される。
【数8】
Figure 0004081258
【0089】
(1)から(8)の項目を分析手段17が分析を行うことによって、管理サーバシステム1が監視対象とするエンドユーザサーバ2の全ての中で、そのエンドユーザサーバ2が障害をどの位回避しているのか、障害発生からどの位早く復旧しているのかを客観的に把握させることが可能となり、これによって、管理者等は管理サーバシステム1の導入の効果を知ることが可能となる。又、本実施態様に於いては、エンドユーザサーバ2全てをその比較対象(母集団)としたが、任意のエンドユーザサーバ2のみを比較対象(母集団)としても良いことは言うまでもない。
【0090】
EUS管理データベース18は、EUS管理サーバ受信手段16が受信したエンドユーザサーバ2のN回目の障害発生時刻とエンドユーザサーバ2のN回目の障害発生に対する復旧時刻(即ちN回目の障害が復旧した時刻)とを格納しているデータベースである。
【0091】
次に、本実施態様のプロセスの流れの一例のフローチャート図を図6に示す。S500からS520は実施例1と同様なので省略する。
【0092】
S520に於ける内部監視の結果を内部監視送信手段8がネットワーク13を介してEUS管理サーバ3に送信するとEUS管理サーバ3のEUS受信手段12に於いてその情報を受信する。
【0093】
受信した内部監視の結果と外部監視手段11による外部監視の結果に基づいて、エンドユーザサーバ2のN回目の障害発生時刻とエンドユーザサーバ2のN回目の障害発生に対する応答時刻(即ちN回目の障害が復旧した時刻)とをEUS管理サーバ3の報告手段14が、総合管理サーバ15にネットワーク13を介して送信する。EUS管理サーバ3からの各エンドユーザサーバ2の監視結果の情報を総合管理サーバ15のEUS管理サーバ受信手段16が受信する(S530)。
【0094】
S530に於いて受信した情報をEUS管理サーバ受信手段16がEUS管理データベース18に格納する(S540)。
【0095】
分析手段17は、定期的或いは不定期的にEUS管理データベース18に格納している情報に基づいて、エンドユーザサーバ2毎、EUS管理サーバ3毎、全体等のMTBF、MTTR等の分析を行う。EUS管理サーバ3毎の分析結果の一例を図12に示す(尚図12の分析結果に於いてはEUS管理サーバ3が複数台のエンドユーザサーバ2を管理している場合を示している)。これによって、管理サーバシステム1が監視対象とするエンドユーザサーバ2の全ての中で、そのエンドユーザサーバ2が障害をどの位予防しているのか、障害発生からどの位早く復旧しているのかを客観的に把握させることが可能となり、これによって、管理者等は管理サーバシステム1の導入の効果を知ることが可能となる。
【0096】
本発明に於ける各手段、データベースは、その機能が論理的に区別されているのみであって、物理上あるいは事実上は同一の領域を為していても良い。
【0097】
尚、本発明を実施するにあたり本実施態様の機能を実現するソフトウェアのプログラムを記録した記憶媒体をシステムに供給し、そのシステムのコンピュータが記憶媒体に格納されたプログラムを読み出し実行することによって実現されることは当然である。
【0098】
この場合、記憶媒体から読み出されたプログラム自体が前記した実施態様の機能を実現することとなり、そのプログラムを記憶した記憶媒体は本発明を当然のことながら構成することになる。
【0099】
プログラムを供給する為の記憶媒体としては、例えばフロッピーディスク、ハードディスク、光ディスク、光磁気ディスク、磁気テープ、不揮発性のメモリカード等を使用することができる。
【0100】
又、コンピュータが読み出したプログラムを実行することにより、上述した実施態様の機能が実現されるだけではなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているオペレーティングシステムなどが実際の処理の一部又は全部を行い、その処理によって前記した実施態様の機能が実現される場合も含まれることは言うまでもない。
【0101】
更に、記憶媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わる不揮発性あるいは揮発性の記憶手段に書き込まれた後、そのプログラムの指示に基づき、機能拡張ボードあるいは機能拡張ユニットに備わる演算処理装置などが実際の処理の一部あるいは全部を行い、その処理により前記した実施態様の機能が実現される場合も含まれることは当然である。
【0102】
【発明の効果】
本発明によって、エンドユーザサーバの予め定めた初期稼働期間(以下、初期流動期間)のシステム状況に基づいて継続的な監視を行い障害発生の未然防止を行うと共に、その監視をシステム状態の内部監視とユーザとほぼ同様の立場からの監視を行う、即ちエンドユーザサーバのネットワーク状態の監視を行う実質上の外部監視とを組み合わせ総合的に行うことによってエンドユーザサーバの安定的管理を行う管理サーバシステムが可能となる。
【0103】
更にMTBF、MTTR等の分析を行うことによって、管理サーバシステムが監視対象とするエンドユーザサーバの全て(或いは一部)の中で、そのエンドユーザサーバが障害をどの位回避しているのか、障害発生からどの位早く復旧しているのかを客観的に把握することが可能となり、これによって、管理者等は管理サーバシステムの導入の効果を知ることが可能となる。
【図面の簡単な説明】
【図1】 本発明のシステム構成の一例を示すシステム構成図である。
【図2】 本発明のシステム構成の他の一例を示すシステム構成図である。
【図3】 本発明のプロセスの流れの一例を示すフローチャート図である。
【図4】 内部監視のプロセスの流れの一例を示すフローチャート図である。
【図5】 外部監視のプロセスの流れの一例を示すフローチャート図である。
【図6】 本発明のプロセスの流れの他の一例を示すフローチャート図である。
【図7】 初期診断結果レポートの一般的な情報を示すレポートの概念図である。
【図8】 初期診断結果レポートの内部初期診断の結果を示すレポートの概念図である。
【図9】 初期診断レポートの外部初期診断の結果を示すレポートの概念図である。
【図10】初期流動期間のネットワークトラフィックの概念図である。
【図11】初期流動期間のディスク使用状況の概念図である。
【図12】分析結果の一例である。
【符号の説明】
1:管理サーバシステム
2:エンドユーザサーバ
3:EUS管理サーバ
4:処理機構
5:内部初期診断手段
6:内部初期流動期間手段
7:内部監視手段
8:内部監視送信手段
9:内部通知手段
10:外部初期診断手段
11:外部監視手段
12:EUS受信手段
13:ネットワーク
14:報告手段
15:総合管理サーバ
16:EUS管理サーバ受信手段
17:分析手段
18:EUS管理データベース
19:外部初期流動期間手段
20:外部通知手段

Claims (7)

  1. エンドユーザサーバの監視を行う管理サーバシステムであって、監視対象となるエンドユーザサーバと前記エンドユーザサーバの外部監視を行うEUS管理サーバとがネットワークを介して接続しており、
    前記エンドユーザサーバは、
    前記エンドユーザサーバの処理を行う処理機構が正常な状態であるかを、前記処理機構を含むエンドユーザサーバの内部から診断する内部初期診断手段と、
    前記内部初期診断終了後から予め定められた内部初期流動期間における、前記エンドユーザサーバの、CPU負荷率、メモリ使用率、ディスク使用状況、サービスアプリケーションの稼働状況、最新の修正モジュールがOSまたはアプリケーションに適用されているか否か、パスワードエラーの回数のうちいずれか一以上を含む情報を、内部初期流動期間の内部監視の情報として収集する内部初期流動期間手段と、
    前記エンドユーザサーバにおける前記内部監視の情報を取得することで、前記エンドユーザサーバの内部監視を実行する内部監視手段と、
    前記内部監視の結果を前記EUS管理サーバに送信する内部監視送信手段と、
    を有しており、
    前記EUS管理サーバは、
    前記エンドユーザサーバから少なくとも前記内部監視の結果を受信するEUS受信手段と、
    前記エンドユーザサーバとの接続が正常な状態であるかを、前記ネットワークを介して前記エンドユーザサーバの外部から診断する外部初期診断手段と、
    前記外部初期診断終了後から予め定められた外部初期流動期間におけるネットワーク接続、トラフィック状態、サービス接続、ポート状況、メールオープンリレーチェックのうちいずれか一以上を含む情報を、外部初期流動期間の外部監視の情報として収集する外部初期流動期間手段と、
    前記エンドユーザサーバのネットワークにおける前記外部監視の情報を取得することで、前記エンドユーザサーバのネットワークの外部監視を実行する外部監視手段と、
    前記EUS受信手段において受信した前記エンドユーザサーバの内部監視の結果と、前記外部監視手段により監視を行った外部監視の結果とを通知する外部通知手段と、
    を有することを特徴とする管理サーバシステム。
  2. 前記内部監視手段は、更に、
    前記エンドユーザサーバにおける前記内部監視の情報を取得し、前記取得した内部監視の情報を、前記内部初期流動期間手段で収集した内部初期流動期間の内部監視の情報と比較することで、前記エンドユーザサーバの内部監視を実行し、
    前記エンドユーザサーバは、更に、
    前記内部監視手段の内部監視の結果に基づいて警告及び/又は処置方法を通知する内部通知手段、を有する
    ことを特徴とする請求項1に記載の管理サーバシステム。
  3. 前記外部監視手段は、更に、
    前記エンドユーザサーバのネットワークの前記外部監視の情報を取得し、前記取得した外部監視の情報を、前記外部初期流動期間手段で収集した外部初期流動期間の外部監視の情報と比較することで、前記エンドユーザサーバのネットワークの外部監視を実行し、
    前記外部通知手段は、更に、
    前記外部監視手段の外部監視の結果に基づいて警告及び/又は処置方法を通知する
    ことを特徴とする請求項1または請求項2に記載の管理サーバシステム。
  4. 前記管理サーバシステムは、更に、
    前記エンドユーザサーバのパフォーマンスの分析を行う総合管理サーバと前記EUS管理サーバとが前記ネットワークを介して接続しており、
    前記総合管理サーバは、
    前記EUS管理サーバから前記エンドユーザサーバの内部監視の情報及び/又は外部監視の情報とを受信するEUS管理サーバ受信手段と、
    前記EUS管理サーバ受信手段にいて受信した情報を格納するEUS管理データベースと、
    前記EUS管理サーバ受信手段にいて受信した情報及び/又は前記EUS管理データベースに格納している情報に基づいて、前記管理サーバシステムが監視対象とするエンドユーザサーバの一部または全部の母集団のうち、前記エンドユーザサーバのパフォーマンスが前記管理サーバシステムにおいてどの位であるかの分析を行う分析手段と、
    を有することを特徴とする請求項1から請求項3のいずれかに記載の管理サーバシステム。
  5. 前記EUS管理サーバ受信手段は、
    前記EUS管理サーバから前記エンドユーザサーバの障害発生時刻と前記発生した障害から復旧した時刻とを受信する、
    ことを特徴とする請求項4に記載の管理サーバシステム。
  6. 前記分析手段は、
    前記エンドユーザサーバのMTBF、平均MTBF、前記母集団とする全てまたは一部のエンドユーザサーバの平均MTBF、前記母集団にける前記エンドユーザサーバのMTBFに対する偏差値、前記エンドユーザサーバのMTTR、平均MTTR、前記母集団の平均MTTR、前記母集団にける前記エンドユーザサーバのMTTRに対する偏差値のうち、少なくとも一以上を分析する、
    ことを特徴とする請求項4または請求項5に記載の管理サーバシステム。
  7. 監視対象となるエンドユーザサーバの外部監視をネットワークを介して行うEUS管理サーバであって、
    前記EUS管理サーバは、
    前記エンドユーザサーバの処理を行う処理機構が正常な状態であるかを、前記処理機構を含むエンドユーザサーバの内部から診断する内部初期診断手段と、前記内部初期診断終了後から予め定められた内部初期流動期間における、前記エンドユーザサーバの、CPU負荷率、メモリ使用率、ディスク使用状況、サービスアプリケーションの稼働状況、最新の修正モジュールがOSまたはアプリケーションに適用されているか否か、パスワードエラーの回数のうちいずれか一以上を含む情報を、内部初期流動期間の内部監視の情報として収集する内部初期流動期間手段と、前記エンドユーザサーバにおける前記内部監視の情報を取得することで、前記エンドユーザサーバの内部監視を実行する内部監視手段と、前記内部監視の結果を前記EUS管理サーバに送信する内部監視送信手段と、を有する前記エンドユーザサーバから、前記エンドユーザサーバの内部監視の結果を受信するEUS受信手段と、
    前記エンドユーザサーバとの接続が正常な状態であるかを、前記ネットワークを介して前記エンドユーザサーバの外部から診断する外部初期診断手段と、
    前記外部初期診断終了後から予め定められた外部初期流動期間におけるネットワーク接続、トラフィック状態、サービス接続、ポート状況、メールオープンリレーチェックのうちいずれか一以上を含む情報を、外部初期流動期間の外部監視の情報として収集する外部初期流動期間手段と、
    前記エンドユーザサーバのネットワークにおける前記外部監視の情報を取得することで、前記エンドユーザサーバのネットワークの外部監視を実行する外部監視手段と、
    前記EUS受信手段において受信した前記エンドユーザサーバの内部監視の結果と、前記 外部監視手段により監視を行った外部監視の結果とを通知する外部通知手段と、
    を有することを特徴とするEUS管理サーバ。
JP2001328802A 2001-10-26 2001-10-26 管理サーバシステム Expired - Fee Related JP4081258B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2001328802A JP4081258B2 (ja) 2001-10-26 2001-10-26 管理サーバシステム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2001328802A JP4081258B2 (ja) 2001-10-26 2001-10-26 管理サーバシステム

Publications (2)

Publication Number Publication Date
JP2003131905A JP2003131905A (ja) 2003-05-09
JP4081258B2 true JP4081258B2 (ja) 2008-04-23

Family

ID=19144806

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2001328802A Expired - Fee Related JP4081258B2 (ja) 2001-10-26 2001-10-26 管理サーバシステム

Country Status (1)

Country Link
JP (1) JP4081258B2 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10237143B2 (en) 2011-11-07 2019-03-19 Square Enix Holdings Co., Ltd. Management apparatus and control method of management apparatus

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8090599B2 (en) 2003-12-30 2012-01-03 Hartford Fire Insurance Company Method and system for computerized insurance underwriting
US7783505B2 (en) 2003-12-30 2010-08-24 Hartford Fire Insurance Company System and method for computerized insurance rating
WO2010018755A1 (ja) * 2008-08-11 2010-02-18 株式会社日立製作所 トランスポート制御サーバ、ネットワークシステム及びトランスポート制御方法
JP5470884B2 (ja) * 2009-02-12 2014-04-16 日本電気株式会社 マルチノードシステム、異常処理方法、スイッチ、ノード及びプログラム
JP7363049B2 (ja) 2019-02-18 2023-10-18 日本電気株式会社 業務サービス提供システム、業務サービス復旧方法及び業務サービス復旧プログラム

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0721059A (ja) * 1993-07-02 1995-01-24 Hitachi Ltd エラ−ログ情報管理方法
JPH0749712A (ja) * 1993-08-05 1995-02-21 Toshiba Corp 設備保全管理装置
JPH07261610A (ja) * 1994-03-18 1995-10-13 Fujitsu Ltd 使用頻度平均化方法及び装置
JP3457455B2 (ja) * 1996-02-23 2003-10-20 京セラミタ株式会社 複写機管理システム
JPH09265415A (ja) * 1996-03-28 1997-10-07 Nippon Telegr & Teleph Corp <Ntt> 異常診断方法及び異常診断装置
JPH10293747A (ja) * 1997-04-18 1998-11-04 Nec Corp クライアント・サーバシステムの性能評価装置及び方式
JPH1185707A (ja) * 1997-09-04 1999-03-30 Hitachi Ltd 並列計算機におけるジョブ投入計算機の選択方法及び装置
JP3190902B2 (ja) * 1999-02-02 2001-07-23 中部日本電気ソフトウェア株式会社 性能監視装置、性能監視方法および性能監視プログラムを記録した記録媒体
JP2001268081A (ja) * 2000-03-17 2001-09-28 Mitsubishi Electric Corp ネットワーク遅延監視装置

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10237143B2 (en) 2011-11-07 2019-03-19 Square Enix Holdings Co., Ltd. Management apparatus and control method of management apparatus

Also Published As

Publication number Publication date
JP2003131905A (ja) 2003-05-09

Similar Documents

Publication Publication Date Title
US11379292B2 (en) Baseline modeling for application dependency discovery, reporting, and management tool
JP4980581B2 (ja) 性能監視装置、性能監視方法及びプログラム
EP2523115B1 (en) Operation management device, operation management method, and program storage medium
US11354222B2 (en) Discovery crawler for application dependency discovery, reporting, and management tool
US8635498B2 (en) Performance analysis of applications
US10915428B2 (en) Intelligent services and training agent for application dependency discovery, reporting, and management tool
US20050262237A1 (en) Dynamic incident tracking and investigation in service monitors
US10931533B2 (en) System for network incident management
US11093378B2 (en) Testing agent for application dependency discovery, reporting, and management tool
JP2004258940A (ja) 情報システムのネットワーク監視方法及びオペレーショナルリスク計量方法
CN113836044B (zh) 一种软件故障采集和分析的方法及系统
JP2011154483A (ja) 異常検出装置、プログラム、及び異常検出方法
CN100549975C (zh) 计算机维护帮助系统及分析服务器
JP2007323193A (ja) 性能負荷異常検出システム、性能負荷異常検出方法、及びプログラム
US9021078B2 (en) Management method and management system
JP4081258B2 (ja) 管理サーバシステム
WO2016159039A1 (ja) 中継装置及びプログラム
WO2012008058A1 (ja) 計算機システムの管理方法、及び管理システム
Iyer et al. Measurement-based analysis of networked system availability
EP4242850A2 (en) Determining problem dependencies in application dependency discovery, reporting, and management tool
CN115543665A (zh) 一种内存可靠性评估方法、装置及存储介质
Munawar et al. Monitoring multi-tier clustered systems with invariant metric relationships
JP4905363B2 (ja) ネットワーク障害検出プログラム、ネットワーク障害検出装置、およびネットワーク障害検出方法
JP2003132019A (ja) 計算機システムの障害監視方法
JP2008005118A (ja) ネットワーク監視システム

Legal Events

Date Code Title Description
A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20041004

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20041004

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20070813

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20070828

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A711

Effective date: 20071003

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20071004

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20071003

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20071126

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20080129

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20080208

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110215

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120215

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130215

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140215

Year of fee payment: 6

LAPS Cancellation because of no payment of annual fees