JP2010231292A

JP2010231292A - 監視装置

Info

Publication number: JP2010231292A
Application number: JP2009075379A
Authority: JP
Inventors: Shigeru Katsuzaki; 繁勝碕; Masayuki Shimada; 政行島田
Original assignee: Nomura Research Institute Ltd
Current assignee: Nomura Research Institute Ltd
Priority date: 2009-03-26
Filing date: 2009-03-26
Publication date: 2010-10-14
Anticipated expiration: 2029-03-26
Also published as: JP5378847B2

Abstract

【課題】監視対象装置間における異常発生の連鎖関係に応じて、監視装置の監視対象範囲を適宜調整する。
【解決手段】本発明の実施の一形態である監視装置３０は、監視対象装置１０の各装置と、監視対象装置１０間における異常発生の連鎖関係に応じて決定された監視優先度とを対応づけて記憶する手段と、監視対象装置１０の各装置における動作状態を取得する手段と、各装置における動作状態が異常か否かを判定する手段とを備える。ある監視対象装置１０における動作状態が異常と判定された際、動作状態を取得する手段は、その装置よりも監視優先度が低い別の監視対象装置１０からの動作状態の取得を停止する。
【選択図】図１

Description

この発明は、複数の情報処理装置の動作状態を監視する技術に関する。

現在の情報処理システムにおいては、多数のコンピュータが連係して動作し、一連の情報処理サービスを提供することが多く、また、情報処理システムには高い稼働率が要求されることが多い。このため、複数のコンピュータの動作状態を一元的に監視し、異常が検出された場合には運用担当者にその異常を通知する監視装置が情報処理システムに導入されることが一般的となっている。

本出願人は、情報処理システムで生じた一つの障害から多数のメッセージが生成されたときでも、その一つの障害の発生を知らせるためのメッセージのみを運用担当者に通知しやすくするために、特許文献１に係る監視装置を提案している。

特開２００５−１４１４６７号公報

監視すべきコンピュータ（以下、適宜「監視対象装置」とも呼ぶ。）の動作状態を監視装置において監視する場合には、通常、監視対象装置・監視装置・ネットワークのそれぞれにおけるハードウェアリソースを消費する。本発明者は、監視対象装置間で異常発生が連鎖する場合、その連鎖関係に応じて監視対象範囲を適宜調整することにより、効率的な動作状態の監視を実現できると考えた。

本発明は、発明者の上記認識に基づきなされたものであり、その主たる目的は、監視対象装置間における異常発生の連鎖関係に応じて、監視装置の監視対象範囲を適宜調整する技術を提供することである。

上記課題を解決するために、本発明のある態様の監視装置は、動作状態を監視すべき複数の情報処理装置のそれぞれと、情報処理装置間における異常発生の連鎖関係に応じて決定された監視優先度とを対応づけて記憶する優先度記憶部と、複数の情報処理装置のそれぞれにおける動作状態を取得する状態取得部と、複数の情報処理装置のそれぞれにおける動作状態が異常か否かを判定する状態判定部と、を備える。複数の情報処理装置のうち一つの情報処理装置における動作状態が異常と判定された際、状態取得部はその情報処理装置よりも監視優先度が低い別の情報処理装置からの動作状態の取得を停止し、もしくは、状態判定部は別の情報処理装置における動作状態に対する判定処理を停止する。

なお、以上の構成要素の任意の組合せ、本発明の表現を装置、方法、システム、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。

本発明によれば、情報処理システムにおける効率的な運用監視を実現できる。

本発明の実施の形態における情報処理システムの構成を示す図である。従来の監視装置から出力される異常通知メッセージを示す図である。監視対象装置の各装置と対応づけられる監視優先度を示す図である。実施の形態の監視装置の機能構成を示すブロック図である。監視属性情報のデータ構造を示す図である。実施の形態の監視装置の動作を示すフローチャートである。監視対象装置の各装置の動作状態を示すタイミングチャートである。実施の形態の監視装置から出力される異常通知メッセージを示す図である。監視対象装置の各装置の動作状態を示すタイミングチャートである。

図１は、本発明の実施の形態における情報処理システムの構成を示す。情報処理システム１００は、ユーザ端末２０と、監視装置３０と、監視対象装置１０で総称されるＤＢサーバ１２、第１のＡＰサーバ１４ａ、第２のＡＰサーバ１４ｂ、第１のウェブサーバ１６ａ、第２のウェブサーバ１６ｂ、第３のウェブサーバ１６ｃ、第４のウェブサーバ１６ｄ、ルータ１８とを備える。

ユーザ端末２０は、運用担当者によって操作される一般的なＰＣ端末であり、監視対象装置１０の異常を示すメッセージ（以下、適宜「異常通知メッセージ」とも呼ぶ。）を運用担当者に提示する。具体的には、監視装置３０から受信された異常通知メッセージが逐次表示されるメッセージコンソールをディスプレイに表示させる。

監視装置３０は、監視対象装置１０の各装置の動作状態を取得して、その動作状態が正常か異常かを判定する。監視対象装置１０の動作状態が異常と判定された際には、異常通知メッセージをユーザ端末２０に送信する。監視装置３０の詳細な構成は後述する。

ＤＢサーバ１２は、ＤＢＭＳ（database management system）ソフトウェアがインストールされたデータベースサーバである。ＤＢサーバ１２は、第１のＡＰサーバ１４ａおよび第２のＡＰサーバ１４ｂにおけるデータ処理に必要な各種データを保持する。

第１のウェブサーバ１６ａ、第２のウェブサーバ１６ｂ、第３のウェブサーバ１６ｃおよび第４のウェブサーバ１６ｄ（以下、総称する場合、単に「ウェブサーバ１６」と呼ぶ。）は、特定のＵＲＬ（Uniform Resource Locator）が指定されたＧＥＴ要求を図示しないウェブクライアント端末から受け付ける。そして、そのＵＲＬで特定されるウェブページをウェブクライアント端末に送信する。第１のウェブサーバ１６ａおよび第２のウェブサーバ１６ｂは、ウェブページに設定すべきデータを第１のＡＰサーバ１４ａから取得する。第３のウェブサーバ１６ｃおよび第４のウェブサーバ１６ｄは、ウェブページに設定すべきデータを第２のＡＰサーバ１４ｂから取得する。

第１のＡＰサーバ１４ａは、ウェブページに設定すべきデータの取得要求を第１のウェブサーバ１６ａおよび第２のウェブサーバ１６ｂから受け付ける。そして、ＤＢサーバ１２に保持された各種データを参照して、ウェブページに設定すべきデータを生成し、取得要求元の第１のウェブサーバ１６ａまたは第２のウェブサーバ１６ｂに送信する。第２のＡＰサーバ１４ｂは、データの提供先が第３のウェブサーバ１６ｃおよび第４のウェブサーバ１６ｄであることを除き、第１のＡＰサーバ１４ａと同様に動作する。以下、第１のＡＰサーバ１４ａおよび第２のＡＰサーバ１４ｂを総称する場合、単に「ＡＰサーバ１４」と呼ぶこととする。

ＤＢサーバ１２、ＡＰサーバ１４、ウェブサーバ１６には、運用監視ソフトウェアにおけるエージェントプログラムがインストールされている。このエージェントプログラムは、監視装置３０からの取得要求を受け付けて、その時点における自装置の動作状態を示すデータを監視装置３０に送信する。

例えば、ＤＢサーバ１２におけるエージェントプログラムは、データベースのテーブルスペースの状態を示すデータを監視装置３０に送信する。また、ＡＰサーバ１４におけるエージェントプログラムは、ＡＰサーバ１４でのデータ処理の状況を示すデータを監視装置３０に送信する。ウェブサーバ１６におけるエージェントプログラムは、特定のＵＲＬを指定したＧＥＴ要求をウェブサーバプログラムに送出して、そのレスポンス状況を示すデータを監視装置３０に送信する。なお、各装置におけるエージェントプログラムは、ハードウェアリソースの使用状況を示す各種統計データを監視装置３０に送信してもよい。この統計データには、ＣＰＵ使用率、メモリ使用量・使用率、ハードディスク使用量・使用率、その他のＩ／Ｏ統計量が含まれてもよい。

ルータ１８は、監視装置３０、ＤＢサーバ１２、ＡＰサーバ１４、ウェブサーバ１６をネットワーク上で相互接続させるためのルータである。監視装置３０は、ルータ１８を介して、ＤＢサーバ１２、ＡＰサーバ１４、ウェブサーバ１６のそれぞれから動作状態を取得する。また、監視装置３０は、ルータ１８の動作状態、言い換えればネットワークの疎通状態も確認する。例えば、ＩＣＭＰ（Internet Control Message Protocol）パケットをルータ１８に送信してその応答データを受信することで確認してもよい。

ここで情報処理システム１００が、監視装置３０に代えて、従来の監視装置を備える場合を考察する。情報処理システム１００において、ルータ１８の動作状態が異常となると、従来の監視装置は、ＤＢサーバ１２、ＡＰサーバ１４、ウェブサーバ１６から各装置の動作状態を取得できなくなる。その結果、従来の監視装置は、監視対象装置１０のいずれの装置の動作状態とも異常であると判断する。

図２は、従来の監視装置から出力される異常通知メッセージを示す。同図では、監視対象装置１０のいずれの装置についても動作状態が異常である旨が表示されている。運用担当者は、メッセージコンソールを見ても、障害の根本原因を迅速に把握することは困難である。また、ルータ１８の動作状態が異常と判定された場合、他の監視対象装置１０の動作状態も異常と判定されることは明らかであり、他の監視対象装置１０のそれぞれから動作状態を取得することはネットワークに不要な負荷を生じさせていることにもなる。

本実施の形態の情報処理システム１００においては、監視対象装置１０の各装置における動作状態を監視する際の優先度（以下、適宜「監視優先度」とも呼ぶ。）が予め決定され、監視対象装置１０の各装置と対応づけられる。具体的には、監視対象装置１０間における異常発生の連鎖関係において、第１の監視対象装置で発生した異常に起因して、第１の監視対象装置とは異なる第２の監視対象装置でも異常が発生する場合、第１の監視対象装置よりも低い監視優先度が第２の監視対象装置と対応づけられる。

図３は、監視対象装置１０の各装置と対応づけられる監視優先度を示す。同図においては、「優先度１」が最も監視優先度が高く、「優先度４」が最も監視優先度が低い。すなわち、ルータ１８の異常はルータ１８自身に起因し、ＤＢサーバ１２の異常はＤＢサーバ１２自身もしくはルータ１８に起因する。また、ＡＰサーバ１４の異常はＡＰサーバ１４自身、ＤＢサーバ１２もしくはルータ１８に起因し、ウェブサーバ１６の異常はウェブサーバ１６自身、ＡＰサーバ１４、ＤＢサーバ１２もしくはルータ１８に起因する。したがって、ウェブサーバ１６＜ＡＰサーバ１４＜ＤＢサーバ１２＜ルータ１８となるように、各装置と監視優先度とが対応づけられる。言い換えれば異常発生の連鎖関係の起原に位置するものほど、さらに言い換えれば障害の根本原因となるものほど、高い監視優先度と対応づけられることになる。

なお、第１のウェブサーバ１６ａおよび第２のウェブサーバ１６ｂは、第１のＡＰサーバ１４ａとの間で異常発生の連鎖関係が結ばれている。その一方で、第３のウェブサーバ１６ｃおよび第３のウェブサーバ１６ｃは、第２のＡＰサーバ１４ｂとの間で異常発生の連鎖関係が結ばれている。したがって、情報処理システム１００には２つの連鎖関係が存在することとなる。すなわち、第１の連鎖関係は、ルータ１８、ＤＢサーバ１２、第１のＡＰサーバ１４ａ、第１のウェブサーバ１６ａ、第２のウェブサーバ１６ｂで構成される。また、第２の連鎖関係は、ルータ１８、ＤＢサーバ１２、第２のＡＰサーバ１４ｂ、第３のウェブサーバ１６ｃ、第４のウェブサーバ１６ｄで構成される。図１に戻る。

本実施の形態における監視装置３０は、ある監視対象装置１０における異常発生を検出すると、その監視対象装置１０の監視優先度よりも低い監視優先度と対応づけられた別の監視対象装置１０の監視を停止する。これにより、本来不要な動作状態取得の処理を排除し、情報処理システム１００における効率的な運用監視を実現する。また、ユーザ端末２０のメッセージコンソールに出力される異常通知メッセージとして、障害の根本原因を示すメッセージが優先して出力されやすくなり、運用担当者の利便性を向上させる。

図４は、本実施の形態における監視装置３０の機能構成を示すブロック図である。本明細書のブロック図において示される各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。

監視装置３０は、監視属性記憶部３２と、メッセージ記憶部３４と、状態取得部３６と、状態判定部３８と、状態通知部４０とを有する。これらの機能ブロックは、運用監視ソフトウェアにおけるマネージャプログラムとして実装されてもよい。メッセージ記憶部３４は、複数の異常通知メッセージと、各異常通知メッセージの識別情報を示すメッセージＩＤとを対応づけて記憶する。

監視属性記憶部３２は、監視対象装置１０の動作状態の監視に関する属性情報（以下、適宜「監視属性情報」とも呼ぶ。）が記憶される記憶領域である。図５は、監視属性情報のデータ構造を示す。監視対象欄には、監視対象装置１０の装置名が記録される。監視項目欄には、監視対象装置１０の各装置から取得した動作状態について正常か異常かを判定すべき項目が記録される。監視間隔欄には、監視対象装置１０の各装置から動作状態を取得する時間間隔が記録される。連鎖関係欄には、異常発生の連鎖関係の識別情報が記録される。優先度欄には、各連鎖関係における監視優先度が記録される。メッセージＩＤ欄には、監視項目が異常と判定された際にユーザ端末２０に出力すべき異常通知メッセージのＩＤが記録される。異常フラグ欄には、監視項目が異常と判定されたことを示す所定値が設定される。停止フラグ欄には、監視対象からの動作状態の取得を停止すべきことを示す所定値が設定される。

図５には図示しないが、各監視項目について正常もしくは異常と判定するために、取得した動作状態と比較するための判定条件が各監視項目に対応づけて記憶されている。例えば、監視項目「ネットワーク疎通」については、ネットワークの疎通状態を異常と判定すべきパケットロス率が判定条件として記録されてもよい。また、監視項目「ＵＲＬレスポンス」については、レスポンスデータを取得できないことが判定条件として記録されてもよい。

また、図５の監視対象「ルータ」において、連鎖関係「１，２」と優先度「１」とを対応づけていることは、連鎖関係１における優先度が「１」であり、連鎖関係２における優先度も「１」であることを示している。また、同図では、一つの監視対象当たり一つの監視項目を割り当てているが、複数の監視項目を割り当ててもよい。また、異常発生の連鎖関係は監視項目ごとの関係であってもよく、例えば、ＤＢサーバ１２に対する別の監視項目と、ウェブサーバ１６に対する別の監視項目との間には、ＡＰサーバ１４を含まない別の連鎖関係が結ばれてもよい。図４に戻る。

状態取得部３６は、監視対象装置１０の各装置に対応づけられた監視間隔に応じて、監視対象装置１０の各装置から動作状態を取得すべき日時になったことを検出する。例えば、ある監視対象装置１０について、前回の動作状態取得を１０時１０分に実行し、その監視間隔が５分である場合、１０時１５分になったことを検出すると、次回の動作状態取得のタイミングであると判定する。

状態取得部３６は、動作状態を取得すべき監視対象装置１０について、その監視属性情報において停止フラグが設定されていないことを条件として、当該監視対象装置１０から動作状態を示すデータ（以下、適宜「状態データ」とも呼ぶ。）を取得する。なお、特定日時において動作状態を取得すべき監視対象装置１０が複数存在する場合、監視優先度が高い監視対象装置１０ほど優先して、言い換えれば、先にその状態データを取得する。

状態判定部３８は、監視対象装置１０の各装置から取得された状態データと、監視属性情報において各装置と対応づけられた判定条件とを比較して、監視対象装置１０の各装置の動作状態が異常か否かを判定する。

状態判定部３８は、ある監視対象装置１０の動作状態が正常から異常に変化したと判定したとき、すなわち異常フラグが未設定の監視対象装置１０の動作状態を異常と判定したとき（この監視対象装置１０を以下、適宜「異常発生装置」とも呼ぶ。）、監視属性情報を更新する。具体的には、異常発生装置の異常フラグに所定値を設定する。それとともに、異常発生装置と異常発生の連鎖関係を有する他の監視対象装置１０であって、異常発生装置よりも監視優先度が低い他の監視対象装置１０（以下、適宜「低優先装置」）の停止フラグに所定値を設定する。これにより、低優先装置からの状態データの取得が停止されることになる。また、状態判定部３８は、監視属性情報において異常発生装置と対応づけられたメッセージＩＤを状態通知部４０に通知する。

また、状態判定部３８は、低優先装置の停止フラグに所定値を設定した後の判定において、異常発生装置の動作状態が正常に回復したことを検出した際、すなわち異常フラグに所定値が設定された監視対象装置１０の動作状態を正常と判定したとき、監視属性情報を更新する。具体的には、異常発生装置の異常フラグにおける所定値の設定を解除するとともに、低優先装置の停止フラグにおける所定値の設定を解除する。例えば、各フラグの値を所定の初期値に戻すことでこの解除処理を実行してもよい。これにより、低優先装置からの状態データの取得が再開されることになる。

また、状態判定部３８は、低優先装置の停止フラグに所定値を設定した後の判定において、異常発生装置と異常発生の連鎖関係を有する他の監視対象装置１０であって、異常発生装置よりも監視優先度が高い他の監視対象装置１０（以下、適宜「高優先装置」）の動作状態を異常と判定したとき、監視属性情報を更新する。具体的には、高優先装置の異常フラグに所定値を設定するとともに、異常発生装置の異常フラグにおける所定値の設定を解除し、異常発生装置の停止フラグに所定値を設定する。この処理は、高優先装置が異常発生装置となり、異常発生装置が低優先装置となった場合の処理とも言える。これにより、異常発生装置からの状態データの取得がさらに停止されることになる。なお、この場合、高優先装置に関するメッセージＩＤが状態通知部４０に通知される。

状態通知部４０は、状態判定部３８から通知されたメッセージＩＤと対応づけられた異常通知メッセージのデータをメッセージ記憶部３４から取得する。状態通知部４０は、メッセージ記憶部３４から取得した異常通知メッセージのデータをユーザ端末２０に送信する。これにより、ユーザ端末２０のメッセージコンソールにおいて、異常通知メッセージを表示させる。

以上の構成による動作を以下説明する。
図６は、監視装置３０の動作を示すフローチャートである。状態取得部３６は、監視属性情報を参照して、特定の監視対象装置１０についてその動作状態を取得すべきタイミングとなったことを検出し（Ｓ１０のＹ）、その停止フラグが設定されていないとき（Ｓ１２のＹ）、当該装置から状態データを取得する（Ｓ１４）。いずれの監視対象装置１０についてもその動作状態を取得すべきタイミングでなく（Ｓ１０のＮ）、所定の終了条件が充足されていれば（Ｓ２６のＹ）、監視処理を終了する。所定の終了条件が充足されていなければ（Ｓ２６のＮ）、Ｓ１０に戻る。動作状態を取得すべきタイミングとなった監視対象装置１０の停止フラグが設定されているとき（Ｓ１２のＮ）、Ｓ１０に戻る。

状態判定部３８において監視対象装置１０の動作状態が正常から異常に変化したと判定されたとき（Ｓ１６のＹ）、状態通知部４０は異常通知メッセージをユーザ端末２０に送信する（Ｓ１８）。状態判定部３８は、その異常発生装置よりも監視優先度が低い低優先装置の停止フラグに所定値を設定することで、低優先装置からの状態データの取得を停止させる（Ｓ２０）。状態判定部３８において監視対象装置１０の動作状態が正常と判定されたとき、もしくは、継続して異常と判定されたとき（Ｓ１６のＮ）、Ｓ１８およびＳ２０はスキップされる。

状態判定部３８において監視対象装置１０の動作状態が異常から正常に回復したと判定されたとき（Ｓ２２のＹ）、状態判定部３８は低優先装置の停止フラグの設定を解除することで、低優先装置からの状態データの取得を再開させる（Ｓ２４）。状態判定部３８において監視対象装置１０の動作状態が異常と判定されたとき、もしくは、継続して正常と判定されたとき（Ｓ２２のＮ）、Ｓ２４はスキップされる。以降、Ｓ２６が実行される。

図７は、監視対象装置１０の各装置の動作状態を示すタイミングチャートである。横軸は開始時点からの経過時間を示しており、開始時点において各装置の動作状態が判定され、以降は図５の監視間隔にしたがってその判定が実行される。また、同図の「○」は動作状態が正常と判定されたこと、「×」は動作状態が異常と判定されたこと、「△」は動作状態の取得が行われなかったことを示している。同図においては、開始時刻から５分〜８分の間にＤＢサーバ１２の動作状態が異常となり、開始時刻から１５分〜２０分の間にその動作状態が正常に回復した場合が示されている。

開始時刻から８分経過時点でＡＰサーバ１４の動作状態が異常と判定され、ウェブサーバ１６からの状態データの取得が停止される。開始時刻から１０分経過時点でＤＢサーバ１２の動作状態が異常と判定され、ＡＰサーバ１４からの状態データの取得も停止される。この時点においてウェブサーバ１６から状態データは取得されない。開始時点から２０分経過時点でＤＢサーバ１２の動作状態が正常に回復したことが判定されると、ＡＰサーバ１４およびウェブサーバ１６からの動作状態の取得が再開され、その時点においてウェブサーバ１６の動作状態が取得され正常と判定されている。開始時刻から２４分経過時点でＡＰサーバ１４の動作状態が取得され正常と判定されている。

以上説明した監視装置３０によれば、複数の監視対象装置１０それぞれの動作状態に変化が生じたとき、監視対象装置１０間における異常発生の連鎖関係に応じて決定された監視優先度に応じて、監視装置３０による監視対象範囲が調整される。これにより、本来不要な監視対象装置１０からの状態データの取得が排除され、情報処理システム１００におけるネットワーク負荷、監視対象装置１０および監視装置３０におけるデータ処理負荷が低減される。言い換えれば、本来不要でありながら、言わば無駄に消費されていたハードウェアリソース量を低減できる。

また、監視装置３０によれば、運用担当者に提供される異常通知メッセージの量も低減される。さらに、異常発生の起原となった装置以外の監視対象装置１０に関する異常通知メッセージは提供されにくくなり、運用担当者は、異常発生の根本原因を特定しやすくなる。すなわち、監視対象装置１０で発生した異常の根本原因に対して、運用担当者が迅速かつ適切に対応できるよう支援できる。

図８は、監視装置３０から出力される異常通知メッセージを示す。図８の（ａ）における異常通知メッセージは、図２の異常通知メッセージに対応するものである。１時３２分の時点でルータ１８の異常が検出され、その他の監視対象装置１０に対する監視は停止されるため、ルータ１８に関する異常通知メッセージ以降、異常通知メッセージの出力は抑止される。なお、図８の（ａ）においては、ＤＢサーバ１２の異常通知メッセージは出力されたが、図５で示したように、監視優先度が高い監視対象装置１０ほど監視間隔を短く設定されることにより、他の装置よりも監視優先度が高い監視対象装置１０の異常が検出されやすくなる。これにより、図８の（ｂ）で示すように、異常発生の根本原因であるルータ１８に関する異常通知メッセージのみが出力されやすくなり、運用担当者は発生した障害の根本原因を容易に特定できる。

以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。以下変形例を示す。

第１の変形例を説明する。実施の形態においては、状態取得部３６が監視対象装置１０それぞれの停止フラグを確認して、監視対象装置１０それぞれからの状態データの取得を適宜停止することにより、監視対象範囲の調整が実行された。変形例においては、状態取得部３６は監視対象装置１０の動作状態によらず状態データの取得を継続してもよい。その代わりに、状態判定部３８は監視対象装置１０それぞれの停止フラグを確認して、監視対象装置１０それぞれからの状態データに対する異常判定を適宜停止してもよい。具体的には、停止フラグが設定された監視対象装置１０からの状態データに対しては異常判定を実行しないこととしてもよい。なお、複数の状態データが同時に取得された場合には、監視優先度が高い監視対象装置１０の状態データほど優先的に、すなわち先に異常判定を実行することが好ましい。本変形例によれば、本来不要な判定処理が排除されるため、監視装置３０の処理負荷が低減されるとともに、運用担当者に提供される異常通知メッセージの量も削減される。

第２の変形例を説明する。実施の形態においては、異常発生装置の動作状態が異常から正常に回復すると、低優先装置の停止フラグは一律に解除された。例えば、図７のタイミングチャートにおいては、最初に異常が検出されたのはＡＰサーバ１４であっても、ＤＢサーバ１２の異常が検出されるとＡＰサーバ１４の異常フラグは解除され、ＤＢサーバ１２の動作状態が正常に回復すると、ＡＰサーバ１４およびウェブサーバ１６の停止フラグは一律に解除された。

第２の変形例においては、監視優先度がより高い高優先装置において異常が検出されても、監視優先度がより低い低優先装置に設定された異常フラグは解除されない。そして、高優先装置の動作状態が異常から正常に回復すると、状態取得部３６は、低優先装置のうち異常フラグが設定され、かつ、監視優先度が最も高い装置を第２高優先装置として特定する。そして、異常発生の連鎖関係が第２高優先装置と同一であり、かつ、第２高優先装置よりも監視優先度が低い第２低優先装置については、その停止フラグの設定解除を保留する。第２高優先装置における動作状態が正常と判定されれば、第２低優先装置についても停止フラグの設定解除が実行される。第２高優先装置が存在しない、すなわち低優先装置の中に異常フラグが設定された装置が存在しない場合には、実施の形態と同様に低優先装置の停止フラグは一律に解除される。

図９は、第２の変形例における監視対象装置１０の各装置の動作状態を示すタイミングチャートである。同図における監視対象装置１０それぞれの動作状態の変化は、図７の場合と同様である。開始時点から１０分経過時点でＤＢサーバ１２の動作状態が異常と判定されても、ＡＰサーバ１４の異常フラグの設定は維持される。開始時点から２０分経過時点でＤＢサーバ１２の動作状態が正常に回復したことが判定されると、ＡＰサーバ１４からの動作状態の取得が再開されるが、ウェブサーバ１６の停止フラグの設定は維持される。開始時点から２４分経過時点でＡＰサーバ１４の動作状態が正常に回復したことが判定されると、ウェブサーバ１６からの動作状態の取得も再開される。

第２の変形例が特に有効な場面は、異常発生の連鎖関係があっても、実際にはそれぞれの異常が独立している可能性がある場合である。具体的には、ＡＰサーバ１４におけるデータ処理の異常は、ＤＢサーバ１２における異常に起因するものもあれば、データ処理内部での例外発生に起因するものもあり、ＡＰサーバ１４の異常とＤＢサーバ１２の異常とが独立して発生することがある。また、ＤＢサーバ１２の異常に起因して、ＡＰサーバ１４でもトランザクション矛盾など、単にＤＢサーバ１２が正常状態に回復しても解決しない異常が発生することがある。例えば、図９の開始時点から２０分経過時点において、ＤＢサーバ１２の正常状態に回復しても、ＤＢサーバ１２の異常とＡＰサーバ１４の異常とが独立しているときには、ウェブサーバ１６からの動作状態取得は無駄な場合がある。

第２の変形例によれば、一旦異常発生装置が特定されると、その異常発生装置が正常に回復したことが判定されるまでは、その異常発生装置に対する低優先装置の監視は停止される。その結果、異常発生の連鎖関係があるものの、それぞれの異常が独立している場合でも、本来不要な監視処理を排除して、ネットワーク負荷や各装置の処理負荷を低減できる。また、運用担当者に対して適切な異常通知メッセージを提供しやすくなる。

上述した実施の形態および変形例の任意の組み合わせもまた本発明の実施の形態として有用である。組み合わせによって生じる新たな実施の形態は、組み合わされる実施の形態および変形例それぞれの効果をあわせもつ。

請求項に記載の各構成要件が果たすべき機能は、実施の形態および変形例において示された各構成要素の単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。

１０監視対象装置、２０ユーザ端末、３０監視装置、３２監視属性記憶部、３４メッセージ記憶部、３６状態取得部、３８状態判定部、４０状態通知部、１００情報処理システム。

Claims

動作状態を監視すべき複数の情報処理装置のそれぞれと、情報処理装置間における異常発生の連鎖関係に応じて決定された監視優先度とを対応づけて記憶する優先度記憶部と、
前記複数の情報処理装置のそれぞれにおける動作状態を取得する状態取得部と、
前記複数の情報処理装置のそれぞれにおける動作状態が異常か否かを判定する状態判定部と、
を備え、
前記複数の情報処理装置のうち一つの情報処理装置における動作状態が異常と判定された際、前記状態取得部はその情報処理装置よりも監視優先度が低い別の情報処理装置からの動作状態の取得を停止し、もしくは、前記状態判定部は前記別の情報処理装置における動作状態に対する判定処理を停止することを特徴とする監視装置。
前記優先度記憶部は、情報処理装置間における異常発生の連鎖関係において、第１の情報処理装置で発生した異常に起因して、前記第１の情報処理装置とは異なる第２の情報処理装置でも異常が発生する場合、前記第１の情報処理装置の監視優先度よりも低い監視優先度を前記第２の情報処理装置と対応づけることを特徴とする請求項１に記載の監視装置。
前記一つの情報処理装置における動作状態が異常と判定された後、前記一つの情報処理装置における動作状態が正常と判定された際、前記状態取得部は前記別の情報処理装置からの動作状態の取得を再開し、もしくは、前記状態判定部は前記別の情報処理装置における動作状態に対する判定処理を再開することを特徴とする請求項１または２に記載の監視装置。
前記一つの情報処理装置における動作状態が異常と判定された後、前記一つの情報処理装置よりも監視優先度が高いさらに別の情報処理装置における動作状態が異常と判定された際、前記状態取得部は前記一つの情報処理装置からの動作状態の取得をさらに停止し、もしくは、前記状態判定部は前記一つの情報処理装置における動作状態に対する判定処理をさらに停止することを特徴とする請求項１から３のいずれかに記載の監視装置。
前記優先度記憶部は、情報処理装置間における異常発生の連鎖関係を示す第１の連鎖関係に応じて決定された監視優先度を当該第１の連鎖関係で結ばれた情報処理装置のそれぞれと対応づけて記憶するとともに、前記第１の連鎖関係とは異なる第２の連鎖関係に応じて決定された監視優先度を当該第２の連鎖関係で結ばれた情報処理装置のそれぞれと対応づけて記憶し、
前記複数の情報処理装置のうち一つの情報処理装置における動作状態が異常と判定された際、前記状態取得部は当該一つの情報処理装置と前記第１または第２の連鎖関係を有し、かつ、その第１または第２の連鎖関係において当該一つの情報処理装置よりも監視優先度が低い別の情報処理装置からの動作状態の取得を停止し、もしくは、前記状態判定部は前記別の情報処理装置における動作状態に対する判定処理を停止することを特徴とする請求項１に記載の監視装置。
動作状態を監視すべき複数の情報処理装置のそれぞれと、情報処理装置間における異常発生の連鎖関係に応じて決定された監視優先度とを対応づけて所定の記憶装置に記憶させる機能と、
前記複数の情報処理装置のそれぞれにおける動作状態を取得する機能と、
前記複数の情報処理装置のそれぞれにおける動作状態が異常か否かを判定する機能と、
をコンピュータに実現させ、
前記複数の情報処理装置のうち一つの情報処理装置における動作状態が異常と判定された際、前記取得する機能はその情報処理装置よりも監視優先度が低い別の情報処理装置からの動作状態の取得を停止し、もしくは、前記判定する機能は前記別の情報処理装置における動作状態に対する判定処理を停止することを特徴とするコンピュータプログラム。