JP2010231293A - 監視装置 - Google Patents

Abstract

【課題】情報処理システムの構成上ひとまとまりのグループとして把握される複数のコンピュータについては、そのグループ全体としての異常発生を運用担当者に通知する。
【解決手段】本発明の実施の一形態である監視装置３０は、グループの異常状態を構成する複数の監視対象装置１０それぞれにおける特定の動作状態の組み合わせを記憶する手段と、複数の監視対象装置１０それぞれにおける動作状態を検出する手段と、複数の監視対象装置１０それぞれから検出された動作状態の組み合わせが、特定の動作状態の組み合わせと合致する際、グループの異常を示すメッセージをユーザ端末２０に通知する手段とを備える。
【選択図】図１

Description

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

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

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

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

情報処理システムにおいて稼働する第１のコンピュータで障害が発生した場合でも、別の第２のコンピュータがその第１のコンピュータの非稼働分をカバーできれば、情報処理システム全体では情報処理サービスの提供を維持できる。この場合、第１のコンピュータに対する運用担当者による障害対応は急を要さないものとなる。

これまでの監視装置は、情報処理システムにおける個々の障害発生を示すメッセージを運用担当者に逐次通知していた。運用担当者は通知されたメッセージ間の関連に基づき、情報処理システムの状態を特定して、障害対応の要否や優先度を判断する必要があり、運用担当者の負担を増大させることがあった。

本発明は、上記課題を鑑みなされたものであり、その主たる目的は、情報処理システムの構成上ひとまとまりのグループとして把握される複数のコンピュータについては、そのグループ全体としての異常発生を運用担当者に通知する技術を提供することである。

上記課題を解決するために、本発明のある態様の監視装置は、複数の情報処理装置により構成されるグループについて、当該グループを単位とする異常状態が複数の情報処理装置のそれぞれにおける動作状態の組み合わせによって定義され、定義された異常状態を構成する各装置の動作状態をそれぞれ各装置の特定動作状態と呼ぶとき、異常状態を構成する複数の情報処理装置のそれぞれにおける特定動作状態の組み合わせを記憶する異常定義記憶部と、複数の情報処理装置のそれぞれにおける動作状態を検出する状態検出部と、複数の情報処理装置のそれぞれから検出された動作状態の組み合わせが、特定動作状態の組み合わせと合致する際、グループの異常を示すメッセージをユーザに通知する状態通知部と、を備える。

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

本発明によれば、運用担当者による障害対応を支援できる。

本発明の実施の形態における情報処理システムの構成を示す図である。 従来の監視装置から出力される異常通知メッセージを示す図である。 本実施の形態における監視装置の機能構成を示すブロック図である。 サーバグループの定義データの構造を示す図である。 監視項目グループの定義データの構造を示す図である。 実施の形態の監視装置の動作を示すフローチャートである。 実施の形態の監視装置から出力される異常通知メッセージを示す図である。

図１は、本発明の実施の形態における情報処理システムの構成を示す。情報処理システム１００は、ユーザ端末２０と、監視装置３０と、監視対象装置１０で総称される第１のＤＢサーバ１２ａ、第２のＤＢサーバ１２ｂ、第３のＤＢサーバ１２ｃ、第４のＤＢサーバ１２ｄ、第１のウェブサーバ１４ａ、第２のウェブサーバ１４ｂ、第３のウェブサーバ１４ｃ、第４のウェブサーバ１４ｄとを備える。これらの各装置は、ＬＡＮ・ＷＡＮ・インターネット等、公知の通信手段を含む通信網を介して、適宜相互に接続される。監視対象装置１０の各装置は、その動作状態が監視装置３０によって継続的に監視される。

第１のＤＢサーバ１２ａ、第２のＤＢサーバ１２ｂ、第３のＤＢサーバ１２ｃ、第４のＤＢサーバ１２ｄ（以下、総称する場合、単に「ＤＢサーバ１２」と呼ぶ。）は、ＤＢＭＳ（database management system）ソフトウェアがインストールされたデータベースサーバであり、各種データを記憶する。第１のＤＢサーバ１２ａおよび第２のＤＢサーバ１２ｂは、フェイルオーバー構成であり、一方が他の外部装置に対してデータアクセスサービスを提供するアクティブ状態であるとき、他方はスタンバイ状態となる。同様に、第３のＤＢサーバ１２ｃおよび第４のＤＢサーバ１２ｄもフェイルオーバー構成である。

第１のウェブサーバ１４ａ、第２のウェブサーバ１４ｂ、第３のウェブサーバ１４ｃ、第４のウェブサーバ１４ｄ（以下、総称する場合、単に「ウェブサーバ１４」と呼ぶ。）は、特定のＵＲＬ（Uniform Resource Locator）が指定されたウェブページの取得要求を図示しないウェブクライアント端末から受け付ける。そして、そのＵＲＬで特定されるウェブページをウェブクライアント端末に送信する。ウェブクライアント端末からのウェブページ取得要求は、図示しないロードバランサにおいて一元的に受け付けられ、ウェブサーバ１４のいずれかに転送される。このロードバランサは、例えばラウンドロビン方式で、一つのウェブページ取得要求をウェブサーバ１４のいずれかに振り分ける。すなわち、ウェブサーバ１４の各装置は、複数のウェブページ取得要求を水平負荷分散して処理する。

なお、監視対象装置１０の各装置には、運用監視ソフトウェアにおけるエージェントプログラムがインストールされてもよい。このエージェントプログラムは、運用監視ソフトウェアにおけるマネージャプログラムの実行装置から、動作状態の取得要求を受け付け、その時点における自装置の動作状態を示すデータ（以下、適宜「状態データ」とも呼ぶ。）をその実行装置に送信してもよい。

この状態データには、例えば、ＣＰＵ使用率、メモリ使用量・使用率、ハードディスク（ＨＤＤ）使用量・使用率、その他のＩ／Ｏ統計量が含まれてもよい。また、ウェブクライアント端末からのアクセス数、ウェブクライアントへの転送データ量、ウェブサーバプログラムからのＵＲＬ応答結果、ウェブページのデータの改ざん有無等が含まれてもよい。また、所定のプロセスまたはタスクの活動状態が含まれてもよい。エージェントプログラムは、自装置の動作状態を示すデータを、自装置の基本的な制御を実行する基本ソフトウェア、典型的にはオペレーティングシステムから取得してもよい。

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

監視装置３０は、監視対象装置１０の各装置から状態データを取得して、監視対象装置１０の各装置の動作状態が正常か異常かを判定する。そして、その判定結果に応じて、異常通知メッセージをユーザ端末２０に送信する。

ここで情報処理システム１００が、監視装置３０に代えて、従来の監視装置を備える場合を考察する。情報処理システム１００において、第１のウェブサーバ１４ａ、第２のウェブサーバ１４ｂ、第１のＤＢサーバ１２ａ、第３のＤＢサーバ１２ｃ、第４のＤＢサーバ１２ｄにおいて障害が発生すると、従来の監視装置は、各装置の異常を検出して、各装置の個々に関する異常通知メッセージをユーザ端末２０に通知した。

図２は、従来の監視装置から出力される異常通知メッセージを示す。同図の異常通知メッセージはユーザ端末２０のメッセージコンソールに表示される。運用担当者は、通知された異常通知メッセージ間の関係を確認して、障害対応の要否や優先度を判断していた。例えば、異常通知メッセージ２００および異常通知メッセージ２０２については、第１のウェブサーバ１４ａおよび第２のウェブサーバ１４ｂとともに、ウェブページ取得要求を処理している第３のウェブサーバ１４ｃおよび第４のウェブサーバ１４ｄの異常が通知されていないため、緊急の障害対応は不要であると判断した。また、異常通知メッセージ２０４については、第１のＤＢサーバ１２ａのフェイルオーバー先である第２のＤＢサーバ１２ｂの異常が通知されていないため、緊急の障害対応は不要であると判断した。また、異常通知メッセージ２０６および異常通知メッセージ２０８については、フェイルオーバー構成のＤＢサーバの両方で障害が発生したため、緊急の障害対応が必要であると判断した。

このように従来の監視装置は、情報処理システム１００の構成を意識せず、監視対象装置１０個々の異常通知メッセージをユーザ端末２０に通知した。そして、運用担当者が、異常通知メッセージの相関に応じて、障害対応の要否や優先度を決定する必要があった。したがって、障害対応の要否や優先度を適切に決定するためには、運用担当者が情報処理システム１００の構成を理解している必要があり、運用担当者の負担を増大させていた。また、高優先度で対応すべき異常を示す異常通知メッセージと、低優先度での対応で構わない異常を示す異常通知メッセージとが混在する場合、異常通知メッセージに対する運用担当者の注意を弱め、ミスを誘発しやすくもなっていた。

さらに、従来の監視装置においては、監視対象装置１０の各装置の動作状態を異常と判定するための条件を示す異常条件データが、監視対象装置１０の各装置に対してそれぞれ設定された。また、監視対象装置１０の各装置に対して設定された異常条件データには、監視項目と、その監視項目が異常あるか否かを判定するための判定基準とがそれぞれ含まれた。したがって、監視対象装置１０として新たな装置が追加される場合、その新たな装置に対して新たな異常条件データを設定する必要があった。また、新たな監視項目が追加される場合や判定基準が変更される場合、監視対象装置１０の各装置に対して設定された異常条件データをそれぞれ変更する必要があった。すなわち、従来の監視装置において監視処理の内容を変更する場合、多くの工数を要していた。

本実施の形態の監視装置３０においては、監視対象装置１０の各装置が適宜グループ化され、このグループ（以下、適宜「サーバグループ」とも呼ぶ。）を単位として動作状態が異常か否かが判定される。具体的には、サーバグループの各装置の動作状態の組み合わせに応じて、サーバグループの動作状態が異常か否かが判定される。そして、サーバグループ単位の異常通知メッセージが運用担当者に通知される。このサーバグループは、典型的には、同質の構成または同質の動作を実行すると想定される複数のサーバにより構成される。例えば、外部からの複数の要求を水平負荷分散して処理するサーバ群や、フェイルオーバー構成のサーバ群が、同一のサーバグループとして集約される。これにより、運用担当者に通知される異常通知メッセージは、サーバグループ全体としての異常、すなわち、運用担当者が対応すべき異常を示すものとなり、運用担当者が異常通知メッセージの相関を判断する負担を低減できる。

また、監視装置３０においては、１以上の監視項目により構成される監視項目グループが定義され、監視項目グループにおける監視項目それぞれの異常の判定基準が一元的に定義される。各サーバグループに対しては、監視項目グループが適宜選択して設定されることにより、同一のサーバグループの各装置には、同一の異常条件データが設定される。したがって、監視対象装置１０の特定のサーバグループに対して新たなサーバが追加される場合、その新たなサーバをサーバグループの定義データに追加すればよく、その新たなサーバのための新たな異常条件データは設定不要となる。また、新たな監視項目が追加される場合や判定基準データが変更される場合、その追加・変更内容を監視項目グループの定義データに反映させることで、各サーバグループにおける異常判定を一元的に変更できる。これにより、監視装置３０における監視処理の内容を容易に変更できる。

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

監視装置３０は、各種データが記憶される記憶領域を示す監視対象記憶部３２、異常定義記憶部３４、メッセージ記憶部３６を有する。さらに、ユーザインタフェース処理や通信処理を含む各種データ処理を実行する監視対象更新部３８、異常定義更新部４０、状態取得部４２、状態判定部４４、状態通知部４６を有する。これらの機能ブロックは、運用監視ソフトウェアにおけるマネージャプログラムの一部機能として実装されてもよい。

メッセージ記憶部３６は、複数の異常通知メッセージと、各異常通知メッセージの識別情報を示すメッセージＩＤとを対応づけて記憶する。
監視対象記憶部３２は、サーバグループの定義データを記憶する。図４は、サーバグループの定義データの構造を示す。サーバグループ欄には、サーバグループの識別情報が記録される。監視対象サーバ欄には、サーバグループに属する１以上の監視対象装置１０それぞれの識別情報が記録される。監視項目グループ欄には、サーバグループに適用される１以上の監視項目グループそれぞれの識別情報が記録される。図３に戻る。

異常定義記憶部３４は、監視項目グループの異常判定のための定義データを記憶する。この定義データには、監視項目グループの異常状態として、サーバグループの各装置における特定の動作状態の組み合わせが定義される。図５は、監視項目グループの定義データの構造を示す。監視項目グループ欄には、監視項目グループの識別情報が記録される。監視項目欄には、監視項目グループに含まれる１以上の監視項目が記録される。項目異常条件欄には、監視項目それぞれが異常か否かを判定するための条件が記録される。個別異常条件欄には、サーバグループに属する監視対象サーバそれぞれの動作状態が異常か否かを判定するための条件が記録される。例えば、リソース監視については、２つ以上の監視項目の異常が検出されたとき、監視対象サーバの動作状態が異常であると判定される。

続いて、グループ異常条件欄には、サーバグループ全体としての動作状態が異常か否かを判定するための条件が記録される。具体的には、サーバグループにおいて、何台以上または何割以上の監視対象サーバの動作状態が異常である場合に、サーバグループ全体の動作状態を異常とするかが規定される。通知時間帯欄には、サーバグループの異常を示す異常通知メッセージをユーザ端末２０に送信する時間帯が記録される。メッセージＩＤ欄には、異常通知メッセージの識別情報が記録される。図３に戻る。

監視対象更新部３８は、サーバグループの定義に対する変更情報をユーザ端末２０から受け付けて、監視対象記憶部３２に記憶された定義データを更新し、その変更内容をサーバグループに反映させる。この変更情報は、例えば、特定のサーバグループに対する監視対象サーバの追加・削除や、特定のサーバグループに対する監視項目グループの追加・削除等を指示するデータである。

異常定義更新部４０は、監視項目グループの定義に対する変更情報をユーザ端末２０から受け付けて、異常定義記憶部３４に記憶された定義データを更新し、その変更内容を監視項目グループに反映させる。この変更情報は、例えば、特定の監視項目グループに対する監視項目の追加・削除や、項目異常条件・個別異常条件・グループ異常条件の少なくとも１つの変更等を指示するデータである。

状態取得部４２は、監視対象装置１０の各装置から定期的に状態データを取得する。典型的には、サーバグループごとに、サーバグループに属する監視対象サーバそれぞれのエージェントプログラムにアクセスして状態データを取得する。状態判定部４４は、監視対象記憶部３２および異常定義記憶部３４を参照し、監視対象装置１０の各装置から取得された状態データにしたがって、サーバグループの動作状態が異常か否かを判定する。

状態判定部４４における具体的な判定処理を説明する。状態判定部４４は、まず、サーバグループに対応づけられた監視項目グループのそれぞれについて、状態データに応じて項目異常条件が充足されるか否かを判定することで、監視項目レベルの異常有無を検出する。次に、監視項目レベルの異常有無に応じて個別異常条件が充足されるか否かを判定することで、各監視対象サーバの異常有無を検出する。そして、各監視対象サーバの異常有無に応じてグループ異常条件が充足されるか否かを判定することで、サーバグループ全体としての異常有無を検出する。状態判定部４４は、サーバグループに対応づけられた監視項目グループについて、サーバグループ全体としての異常を検出した際、サーバグループのＩＤと、その監視項目グループに対応づけられたメッセージＩＤとを状態通知部４６に通知する。

ここでは、サーバグループ「ウェブグループ」における、監視項目グループ「リソース監視」についての異常判定処理を説明する。この場合、状態判定部４４は、ウェブサーバ１４のそれぞれから取得された状態データにしたがって、リソース監視の各監視項目の異常を判定する。例えば、ＣＰＵ使用率が９０％以上であるか否かを判定する。続いて状態判定部４４は、２つ以上の監視項目で異常と判定されたウェブサーバ１４を動作状態が異常な装置として特定する。そして、全てのウェブサーバ１４の動作状態が異常と判定したとき、ウェブグループ全体として動作状態が異常であると特定し、ウェブグループの識別情報と、メッセージＩＤ「０００１」とを状態通知部４６に送出する。

状態通知部４６は、異常定義記憶部３４を参照して、状態判定部４４から通知されたメッセージＩＤと対応づけられた通知時間帯を取得する。状態通知部４６は、現在時刻が通知時間帯に含まれることを条件として、そのメッセージＩＤと対応づけられた異常通知メッセージのデータをメッセージ記憶部３６から取得し、ユーザ端末２０に送信する。これにより、ユーザ端末２０のメッセージコンソールに異常通知メッセージを表示させる。なお、現在時刻が通知時間帯の外であるときには、そのメッセージＩＤと対応づけられた異常通知メッセージをユーザ端末２０に送信することなく、処理を終了する。

以上の構成による動作を以下説明する。図６は、監視装置３０の動作を示すフローチャートである。同図は、監視装置３０における特定のサーバグループに対する監視処理の流れを示している。同図の一連の処理は、サーバグループごとに実行されてもよく、所定時間が経過するたびに繰り返し実行されてもよい。

状態取得部４２は、サーバグループの監視対象サーバのそれぞれから状態データを取得する（Ｓ１０）。状態判定部４４は、サーバグループと対応づけられた監視項目グループについて、状態データにしたがって監視項目レベルの異常判定を実行し（Ｓ１２）、その判定結果にしたがって監視対象サーバ個別の異常判定を実行する（Ｓ１４）。監視対象サーバ個別の異常判定の結果、すなわちその組み合わせがグループ異常条件を充足するとき（Ｓ１６のＹ）、状態判定部４４は、監視項目グループのメッセージＩＤを状態通知部４６に通知する。現在時刻がそのメッセージＩＤと対応づけられた通知時刻帯であるとき（Ｓ１８のＹ）、状態通知部４６は、サーバグループの異常を示す異常通知メッセージをユーザ端末２０に送信する（Ｓ２０）。監視対象サーバ個別の異常判定の結果がグループ異常条件を充足しなければ（Ｓ１６のＮ）、Ｓ１８およびＳ２０はスキップされ、現在時刻が通知時刻帯の外であるときには（Ｓ１８のＮ）、Ｓ２０はスキップされる。

以上説明した監視装置３０によれば、情報処理システム１００において同質の構成もしくは同質の機能を有する複数の装置が適宜グループ化される。そして、個々の装置の異常ではなく、サーバグループの異常を単位として、サーバグループの異常を示すメッセージが運用担当者に通知される。これにより、運用担当者側においてメッセージ間の関係を判断し、障害対応の要否や優先度を決定することが不要となり、運用担当者の負担を低減できる。すなわち、異常な値を示す監視項目の数や、動作状態が異常なサーバ数に応じて、サーバグループ全体の正常性を監視装置３０側で判定することにより、運用担当者による優先的な対応が必要な障害を精度よく通知できる。

図７は、監視装置３０から出力される異常通知メッセージを示す。図２で示したように、従来の監視装置においては、異常通知メッセージ２００〜異常通知メッセージ２０８が出力された。これに対して、監視装置３０においては、図２の異常通知メッセージ２０６および異常通知メッセージ２０８に対応する異常通知メッセージ２１０のみが出力される。すなわち、図２の異常通知メッセージ２００および異常通知メッセージ２０２に対応する異常については、監視項目グループ「ウェブ監視その２」で定義されたグループ異常条件を充足しないため、グループ全体としての異常とは判定されず、異常通知メッセージは通知されていない。また、図２の異常通知メッセージ２０４に対応する異常については、監視項目グループ「ＤＢ監視」で定義されたグループ異常条件を充足しないため、異常通知メッセージは同様に通知されていない。運用担当者は、情報処理システム１００の構成を意識しなくても、この異常通知メッセージを確認することで、第２ＤＢグループへの障害対応を優先的に実行すべきことを判断できる。

また、監視装置３０によれば、サーバグループの定義において、監視対象装置１０の各装置がサーバグループおよび監視項目グループに対応づけられる。また、監視項目グループの異常判定のための条件は、特定のサーバグループに依存することなく、一元的に定義される。したがって、監視対象装置１０として新たな装置が追加される場合には、その新たな装置をサーバグループの定義に追加すればよく、その新たな装置に対する異常判定のための条件を新たに設定することは不要となる。また、個々の監視項目や異常判定のための条件を変更する場合には、監視項目グループの定義データを変更することで、その監視項目が対応づけられたサーバグループの異常判定に対してその変更内容を反映できる。言い換えれば、個々のサーバグループごとの設定を変更する必要はない。

さらに、監視装置３０によれば、監視項目グループと通知時間帯とが対応づけられ、この通知時間帯の外においては、サーバグループの異常が検出されても運用担当者への異常通知メッセージは非通知となる。通知時間帯は、監視項目グループの障害対応の優先度に応じて決定されてもよく、例えば障害対応の優先度が低い監視項目グループについては異常通知メッセージが夜間に通知されないように通知時間帯が設定されてもよい。現実のシステム運用においては、夜間に障害が発生してもシステム全体の運用に影響がないものについては翌朝以降の対応とされることが多い。監視装置３０によれば、このような実際のシステム運用に則して運用担当者を支援できる。

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

第１の変形例を説明する。実施の形態では、状態通知部４６において、通知時間帯の外における異常通知メッセージの抑止が実行された。変形例では、通知時間帯の外においては、状態判定部４４がメッセージＩＤを状態通知部４６に通知しないことにより、通知時間帯の外における異常通知メッセージの抑止を実行してもよい。

第２の変形例を説明する。状態通知部４６は、通知時間帯の外においては、メッセージＩＤまたは異常通知メッセージを所定の記憶装置に一時的に保持させてもよい。そして、通知時間帯となった際に、その記憶装置に保持させたメッセージＩＤまたは異常通知メッセージを取得して、通知を抑止した異常通知メッセージをユーザ端末２０に送信してもよい。なお、第１の変形例と組み合わせて、本変形例の処理は状態判定部４４において実行されてもよい。

第３の変形例を説明する。実施の形態では、サーバグループ全体としての異常が運用担当者に通知される一方で、サーバグループの各装置個別の異常は通知されなかった。変形例においては、サーバグループの各装置個別の異常も運用担当者に通知されてもよい。この場合、状態判定部４４はサーバグループの各装置個別の異常を検出すると、その旨を状態通知部４６に通知し、状態通知部４６は各装置個別の異常を示す異常通知メッセージをユーザ端末２０に送信する。好適には、サーバグループ全体としての異常を示す異常通知メッセージと、各装置個別の異常を示す異常通知メッセージとは、ユーザ端末２０において別のメッセージコンソールに表示される。この場合、状態通知部４６は、サーバグループ全体としての異常を示す異常通知メッセージは第１のメッセージコンソールに、各装置個別の異常を示す異常通知メッセージは別の第２のメッセージコンソールに表示されるよう、所定データを付加した異常通知メッセージを送信する。

第３の変形例の別の態様としては、サーバグループ全体としての異常を通知する異常通知メッセージと、各装置個別の異常を通知する異常通知メッセージとは、異なるレベルを示すデータがそれぞれ設定されてもよい。例えば、サーバグループ全体としての異常を通知する異常通知メッセージには、各装置個別の異常を通知する異常通知メッセージよりも高い対応優先度を示すために、より高いレベルが設定されてもよい。ユーザ端末２０のメッセージコンソールは、高いレベルが設定された異常通知メッセージほど優先して、言い換えれば運用担当者から視認されやすい態様で表示してもよい。例えば、文字サイズを大きくし、強調するための色を設定する等の方法により、高いレベルが設定された異常通知メッセージほど強調して表示してもよい。第３の変形例によれば、サーバグループ全体としての異常が運用担当者に通知されるとともに、各装置個別の異常も通知されるため、サーバグループ全体としての異常に至る前の各装置個別の異常にも対処しやすくなる。また、サーバグループ全体としての異常が運用担当者に対して優先的に示されることで、運用担当者は情報処理サービスの全面停止を招くおそれのある重大な障害に対して優先的に対応しやすくなる。

第４の変形例を説明する。実施の形態においては、サーバグループとしてグループ化される装置として、同質の構成または機能を提供する装置群、具体的にはロードバランス構成の装置群およびフェイルオーバー構成の装置群を示した。変形例においては、同じ監視項目グループを設定すべき装置群がグループ化されてもよい。例えば、Ｗｉｎｄｏｗｓ（登録商標）、ＵＮＩＸ（登録商標）等の同じオペレーティングシステムの装置群が、同一のグループとしてグループ化されてもよい。

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

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

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

Claims (7)

1. 複数の情報処理装置により構成されるグループについて、当該グループを単位とする異常状態が前記複数の情報処理装置のそれぞれにおける動作状態の組み合わせによって定義され、定義された異常状態を構成する各装置の動作状態をそれぞれ各装置の特定動作状態と呼ぶとき、
   前記異常状態を構成する前記複数の情報処理装置のそれぞれにおける特定動作状態の組み合わせを記憶する異常定義記憶部と、
   前記複数の情報処理装置のそれぞれにおける動作状態を検出する状態検出部と、
   前記複数の情報処理装置のそれぞれから検出された動作状態の組み合わせが、前記特定動作状態の組み合わせと合致する際、前記グループの異常を示すメッセージをユーザに通知する状態通知部と、
   を備えることを特徴とする監視装置。
2. 前記グループを構成する複数の情報処理装置を記憶するグループ記憶部と、
   前記グループに加入させるべき新たな情報処理装置が追加された際、前記複数の情報処理装置のそれぞれから検出される動作状態を、前記新たな情報処理装置からも検出させるために、前記グループ記憶部に前記新たな情報処理装置をさらに記憶させるグループ更新部と、
   をさらに備えることを特徴とする請求項１に記載の監視装置。
3. 前記グループにおける異常状態の定義を変更すべき際、その定義を構成する前記複数の情報処理装置のそれぞれにおける特定動作状態を一元的に変更する異常定義更新部をさらに備えることを特徴とする請求項１または２に記載の監視装置。
4. 前記異常定義更新部は、前記異常定義記憶部において複数の情報処理装置によりそれぞれ構成される複数のグループに対して同じ異常状態の定義が対応づけられている際、前記異常定義記憶部に記憶された異常状態の定義を一元的に変更することで、当該異常状態の定義の変更内容を前記複数のグループのそれぞれに反映することを特徴とする請求項３に記載の監視装置。
5. 前記異常定義記憶部は、外部からの要求を水平負荷分散して処理する複数の情報処理装置を、前記グループを構成する複数の情報処理装置として取り扱うことを特徴とする請求項１から４のいずれかに記載の監視装置。
6. 前記異常定義記憶部は、前記メッセージをユーザに通知すべき時間帯をさらに記憶し、
   前記状態通知部は、前記複数の情報処理装置のそれぞれから検出された動作状態の組み合わせが前記特定動作状態の組み合わせと合致しても、前記時間帯の外においては、前記メッセージをユーザに対して非通知とすることを特徴とする請求項１から５のいずれかに記載の監視装置。
7. 複数の情報処理装置により構成されるグループについて、当該グループを単位とする異常状態が前記複数の情報処理装置のそれぞれにおける動作状態の組み合わせによって定義され、定義された異常状態を構成する各装置の動作状態をそれぞれ各装置の特定動作状態と呼ぶとき、
   前記異常状態を構成する前記複数の情報処理装置のそれぞれにおける特定動作状態の組み合わせを所定の記憶装置に記憶させる機能と、
   前記複数の情報処理装置のそれぞれにおける動作状態を検出する機能と、
   前記複数の情報処理装置のそれぞれから検出された動作状態の組み合わせが、前記特定動作状態の組み合わせと合致する際、前記グループの異常を示すメッセージをユーザに通知する機能と、
   をコンピュータに実現させるためのコンピュータプログラム。

Images