JP2009064098A

JP2009064098A - 運用管理システムおよび定義不足の分析方法

Info

Publication number: JP2009064098A
Application number: JP2007229316A
Authority: JP
Inventors: Junya Iwasaki; 順弥岩崎
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2007-09-04
Filing date: 2007-09-04
Publication date: 2009-03-26

Abstract

【課題】メッセージフィルタ定義に設定不足や不適切な設定があった場合でも、断続的に該当メッセージが発生するといった問題が発生した場合に監視者が検知すること。
【解決手段】コンピュータシステムのエラーメッセージの出力をルールに従ってフィルタリングする運用管理システムは、ルール上で未登録のメッセージをログ出力する度に、あらかじめ登録した不明メッセージの出力条件の閾値を越えたか判断し、越えた場合に管理者用監視端末に出力する。
【選択図】図１

Description

本発明は、運用管理システムにおいて、予め設定しておいたメッセージフィルタの不適切な定義や定義不足を分析（検知）する技術に関する。

まず、運用管理システムにおける監視画面へのメッセージ出力関連機能について簡単に述べる。通常、複数台のクライアントサーバからメッセージ収集を行う運用管理システムにおいて、全てのメッセージは、監視画面出力する・しないに関わらず各クライアントサーバが持つメッセージ用のログファイルに出力されている。監視画面への出力は各クライアントサーバのメッセージログファイルと、同じく各クライアントサーバのメッセージ定義フィルタとの突合せによって決定する。つまり、定義フィルタに該当メッセージが『出力』設定されていれば、監視画面へメッセージ出力され、定義フィルタに『抑止』設定されていれば監視画面には出力されない。フィルタ定義されていないメッセージは一般的に監視画面出力されないか、あるいは設定次第では全て運用レベルのメッセージ（以下、運用メッセージと呼称）として出力されるケースもある。

複数台のクライアントサーバから構成されるシステムの場合、マルチベンダ構成、各サーバで異なるアプリケーションが動作している、などが一般的である。従って、メッセージのフィルタ定義は１種類ではなく複数パターン設定する必要があるため、本当に必要なメッセージが取得（出力）出来ているかどうかの判断が困難であった。また、システムの規模が大きければ大きい程フィルタ定義のパターンが増えるため、定義誤りを起こす可能性が高くなると考えられるが、以下に述べる本発明の特徴によりこれらの問題の対処が可能になる。

ここで、統合運用管理サーバは、運用管理端末に出力すべきメッセージを抽出するためのフィルタ条件を定義したフィルタ群に含まれるフィルタを所定の使用順序で使用し、監視手段から受信したメッセージのうちいずれかのフィルタによって抽出されたメッセージを運用管理端末に出力し、抽出処理の過程で、統合運用管理サーバは、フィルタ条件に一致したメッセージの数をフィルタ毎にカウントしておき、統合運用管理サーバは、定期的に、カウンタ値を用いて、カウンタ値が多い順にフィルタの使用順序を並び替え、並び替え後、発生頻度の高いメッセージは、使用順序の早いフィルタによって特定可能となることで、メッセージの量・種類の多いコンピュータシステムにおける一元的かつ効率的な運用管理環境を提供する技術が提案されている（例えば、特許文献１参照）。
特開２００６−２６００５６号公報

しかしながら、上述の関連技術では、全てのイベント（条件）を定義して確認しなければメッセージフィルタ定義不足や適切かどうかは判断出来ず、運用の最適化という観点ではまだ検討すべき課題があった。例えば、従来のメッセージフィルタ機能については、出力か非出力（抑止）かの判定しかしておらず、それらはどちらも管理者が登録するものであり、「登録済」と「未登録」のメッセージを区別し、それぞれで異なった分析を行うことがなされていなかった。

本発明は、以上のような課題を解決するためになされたもので、メッセージフィルタ定義に設定不足や不適切な設定があった場合でも、断続的に該当メッセージが発生するといった問題が発生した場合に監視者が検知することができる不適切なメッセージフィルタ定義、および定義不足の分析方法を提供することを目的とする。

本発明の第１の運用管理システムは、コンピュータシステムのエラーメッセージの出力をルールに従ってフィルタリングする運用管理システムにおいて、該ルール上で未登録のメッセージをログ出力する度に、あらかじめ登録した不明メッセージの出力条件の閾値を越えたか判断し、越えた場合に管理者用監視端末に出力することを特徴とする。

また、本発明の第２の運用管理システムは、コンピュータシステムのエラーメッセージの出力をルールに従ってフィルタリングする運用管理システムにおいて、該ルール上で運用メッセージをログ出力する度に、あらかじめ登録した運用メッセージの出力条件の閾値を越えたか判断し、越えた場合に管理者用監視端末に出力することを特徴とする。

また、本発明の第１の定義不足の分析方法は、コンピュータシステムのエラーメッセージの出力をルールに従ってフィルタリングする定義不足の分析方法において、
該ルール上で未登録のメッセージをログ出力する度に、あらかじめ登録した不明メッセージの出力条件の閾値を越えたか判断し、越えた場合に管理者用監視端末に出力することを特徴とする。

また、本発明の第２の定義不足の分析方法は、コンピュータシステムのエラーメッセージの出力をルールに従ってフィルタリングする定義不足の分析方法において、該ルール上で運用メッセージをログ出力する度に、あらかじめ登録した運用メッセージの出力条件の閾値を越えたか判断し、越えた場合に管理者用監視端末に出力することを特徴とする。

本発明によれば、メッセージフィルタ定義に設定不足や不適切な設定があった場合でも、断続的に該当メッセージが発生するといった問題が発生した場合に監視者が検知することができる。

以下、本発明の実施の形態について図面を参照して詳細に説明する。図１、図３および図２のフローチャートを参照して本実施の形態の不明メッセージ出力（フィルタ定義不足検知）条件、マイナーメッセージ出力（不適切なフィルタ定義検知）条件の登録動作について詳細に説明する。

まず、監視端末装置１００のルール拡張要求手段１０３を用いて、図２の流れで不明メッセージを出力させる（または、運用メッセージが頻出している旨をマイナーメッセージで知らせる）条件を登録する（図２のステップＳ０１の拡張ルール作成）。設定する条件（拡張ルール）は、対象メッセージ（未登録メッセージor登録済メッセージ）とｘ秒間（例えば、最大８６４００秒＝２４時間まで指定可）にy件（例えば、最大９９９９件まで指定可）のメッセージが発生した場合といった２つのパラメータと対象ノード（省略可）を指定する（図３は登録画面イメージ）。ノード指定ありの場合、マネージャ装置２００の出力ルール蓄積部Ａ２０４のノード情報で指定ノードのみフラグを立て、ノード指定が省略されていた場合、全てのノードにフラグを立てる（図１のステップＳ０２〜S０４）。ノード情報フラグは未登録メッセージ用と運用メッセージ用で別々に持つことが出来る。出力ルール蓄積部Ａ２０４への登録が完了したら、エージェント装置３００の出力ルール蓄積部Ｂ３１２に図３の各条件を登録する。図１のステップＳ０２でノード指定があった場合は、特定のエージェント装置３００に対して登録を行い、ノード指定がなかった場合は、接続されている全てのエージェントに対して登録を行い（図１のステップＳ０５〜S０６）処理を終える。

次に、図１、図５、図６および図４のフローチャートを参照して不明メッセージや運用メッセージを知らせるマイナーメッセージを出力させる流れについて詳細に説明する。

まず、エージェント装置３００の異常検出手段３０１がサーバ（ノード）の異常を検出し、出力情報蓄積部３１１に対してメッセージログを出力する（図４のステップＳ１１〜S１２）。障害判定手段３０２は、フィルタ定義済かどうかを判断する機能である。出力されたメッセージがフィルタ定義済メッセージかどうか出力ルール蓄積部Ｂ３１２に登録されているメッセージＩＤと突合し、監視画面出力対象としている場合はそれが運用メッセージかどうか判断する（図４のステップＳ１３〜S１４）。該当のメッセージが出力対象でも抑止対象メッセージでもなかった場合は出力禁止設定済メッセージかどうか確認し、禁止済でない場合、メッセージ種別フラグに'１'（未登録メッセージを示す）を、運用メッセージだった場合はメッセージ種別フラグに'２'（運用メッセージを示す）を設定し、図５の形式（時系列順に追記）で該当メッセージ情報を出力情報蓄積部３１１に出力する（図４のステップＳ１３〜Ｓ１７）。図５のメッセージ情報を出力したタイミングで該当のメッセージＩＤの物のみ抜き出し（ｇｒｅｐのイメージ）、最新のメッセージからｘ秒以内にy件（図３の条件）以上該当のメッセージが出力されているか確認し、出力件数がy件未満の場合は処理を終了する（図４のステップＳ１８〜Ｓ１９）。ここで出力件数がy件以上だった場合は、閾値超過フラグをＯＮにして（図４のステップＳ２０）おく。（本実施の形態では、この様な分析手法を用いているが、これは情報を得るための一手段であるため、既存の分析エンジンなどを流用しても良い。）図４のステップＳ１５で設定したメッセージ種別フラグと閾値超過フラグをメッセージ出力要求送信手段３０３にてマネージャ装置２００のメッセージ出力要求送受信手段２０１に対して送信する。出力情報判定手段２０２はメッセージ種別フラグが'２'（運用メッセージ）の場合、運用メッセージを監視端末装置１００のメッセージ要求受信手段１０１に対して出力させる。また、閾値超過フラグがＯＮかどうか判断し、超過していない（ＯＦＦの）場合はそのまま処理を終了する（図４のステップＳ２１〜Ｓ２２）。閾値を超過していて（ＯＮで）かつメッセージ種別フラグが'１'（未登録メッセージ）の場合は、出力ルール蓄積部Ａ２０４に該当メッセージが拡張ルールとして登録されているか確認し、登録されていない場合は、監視端末装置１００のメッセージ要求受信手段１０１に対して不明メッセージ（図６―１のイメージ）を出力させる。閾値を超過していて（ＯＮで）かつ運用メッセージの場合は、その旨を通知するマイナーメッセージ（図６―２のイメージ）を出力させ（図４のステップＳ２２〜Ｓ２５）処理を終える。

最後に、図１、図６および図７のフローチャートを参照して不明メッセージ出力後に監視者（管理者）が行う作業の流れについて詳細に説明する。

図６―１の様な不明メッセージが出力された場合、監視者は該当メッセージが今後も正式なメッセージとして出力させる必要があるかどうか確認する。必要な場合は監視端末装置１００に対して登録要求を行う。ルール拡張要求手段１０３からマネージャ装置２００のルール拡張要求送受信手段２０３に対して該当のメッセージＩＤと出力禁止情報（'１'（正式な出力対象）または'２'（出力禁止対象））およびフィルタ定義を送る。フィルタ定義は不明メッセージの出力条件（閾値）がそのままメッセージ本文に含まれているのでそれを設定する。要求を受けたルール拡張要求送受信手段２０３はエージェント装置３００のルール拡張手段３０４に対して同じ要求を送信し、メッセージ情報記憶部３１０の出力ルール蓄積部３１２に該当メッセージＩＤと出力禁止情報を登録して（図７のステップＳ３１〜Ｓ３５）処理を終える。ここで、該当メッセージに対して何もオペレーションしなければ、正式メッセージ登録も出力禁止メッセージ登録もされないで次回以降も不明メッセージとして出力されるが、不明メッセージ出力条件（閾値）を変えても良い（図７のステップＳ３３、Ｓ３６）。

次に、本発明の実施の形態の構成について図１を用いて説明する。
図１を参照すると、本発明の運用管理システムは大きく分けて、監視端末装置１００とマネージャ装置２００とエージェント装置３００から構成されている。

監視端末装置１００はメッセージ要求受信手段１０１と、メッセージ出力手段１０２と、ルール拡張要求手段１０３とを含む。

マネージャ装置２００はメッセージ出力要求送受信手段２０１と、出力情報判定手段２０２と、ルール拡張要求送受信手段２０３と、出力ルール蓄積部Ａ２０４とを含む。

エージェント装置３００は、異常検出手段３０１と、障害判定手段３０２と、メッセージ出力要求送信手段３０３と、ルール拡張手段３０４と、メッセージ情報記憶部３１０とを含む。

メッセージ情報記憶部３１０は、出力情報蓄積部３１１と、出力ルール蓄積部Ｂ３１２とを含む。

図１ではマネージャ装置２００に対して１台のエージェント装置３００が接続されているが、複数台のエージェント装置３００が接続されていても動作可能とする。

これらはそれぞれ概略つぎのように動作する。
監視端末装置１００のメッセージ出力手段１０２により画面出力されたメッセージを監視者が確認する。また、ルール拡張要求手段１０３により、監視者は不明メッセージ出力条件や運用メッセージをマイナー出力するための条件を登録する。

マネージャ装置２００のメッセージ出力要求送受信手段２０１はエージェント装置３００から来たメッセージ出力要求を監視端末装置１００に渡すパイプ機能である。また、監視端末装置１００から来たルール拡張要求を受けて出力ルール蓄積部Ａ２０４に登録し、エージェント装置３００に同じ要求を渡すパイプ役である。出力ルール蓄積部Ａ２０４は各エージェントから送られてきたメッセージ要求を監視画面のどのカテゴリ（ノード）上に出力するか判断するために使われる。

エージェント装置３００の異常検出手段３０１は監視対象サーバ（ノード）が出力するメッセージを受信する機能である。障害判定手段３０２は受信したメッセージを出力情報蓄積部に出力し、該当メッセージが監視画面出力対象かどうか出力ルール蓄積部Ｂ３１２と突き合わせて判断する機能である。出力ルール蓄積部Ｂ３１２には該当サーバ（ノード）単位に不明メッセージ出力や運用メッセージをマイナー出力させるための条件（拡張ルール）が登録される。

本発明では、どのフィルタにも合致しない（フィルタ設定せずにメッセージ出力されない）ものをフィルタ設定の『不足』とみなす。事前に監視画面出力対象として登録していないメッセージであっても、頻繁に各クライアントサーバ内部のログファイルにメッセージログが出力され続ける場合、予期せぬトラブルである可能性が考えられるため、事前に登録しておいた閾値（出力頻度）に応じて、『不明メッセージ』として監視画面に出力させることが出来る。つまり『不足』を検知することが出来る点が１つ目の特徴である。

また、一方的に出力された不明メッセージは、監視者にとって本当に必要な物かどうか判断できないため、それが今後も出力させる必要があると判断された場合は、該当不明メッセージの抽出条件をそのままフィルタ条件としてメッセージレベルを付けて正式メッセージとして登録することが出来、不要と判断された場合は、該当の不明メッセージは二度と出力させなくすることが出来る点が２つ目の特徴である。

一方、本発明では、次の様なケースを不適切なフィルタ設定とみなす。運用メッセージの場合、監視者は重要視しないため気付かないケースが殆どである。運用レベルであるため、通常の出力頻度であれば問題にならないが、例えば３０秒に１件のペースなどで断続的に出力し続ける場合、システム的に何かしら異常（調査が必要）である可能性が考えられる。この場合も事前に登録しておいた閾値（出力頻度）に応じて、マイナーレベルのメッセージ（以下、マイナーメッセージと呼称）を出力させる事で運用メッセージが断続的に出力し続けていることを検知することが出来る点が３つ目の特徴である。

つまりどのフィルタ設定にも合致しないものを『不足』、何らかのフィルタ設定には合致するものの適切でない可能性があるものを『不適切』とみなし、これら２つを別々に抽出することで、フィルタ設定が『不適切』なのか『不足』なのかを明確にし、その抽出条件と共に監視者（管理者）に対して提示することで、管理者が条件の不備等を理解し、より最適な条件に修正する助けとすることができる。これに伴い、システム運用（管理）の最適化が実現できると考えられる。

本発明を用いることで予期せぬシステム障害などが発生した場合でもシステム異常をいち早く察知することが出来、メッセージに気付かずに放置していたがために発生する可能性のあるその後の大障害を未然に防ぐことが出来る。

上記の本実施の形態によれば、メッセージフィルタ定義に設定不足や不適切な設定があった場合でも、断続的に該当メッセージが発生するといった問題が発生した場合に監視者が検知することができる。その理由は、本発明では監視画面出力しないメッセージの出力頻度をエージェント内部でチェックする機構を持ち、予め設定しておいた閾値（条件）を超えた場合、該当のメッセージを監視画面上に不明メッセージとして出力するためである。つまり従来であれば、気付けなかった問題にいち早く検知することが出来ることで、それに伴う二次災害発生の可能性を事前に防ぐことが出来る。

また、一度不明メッセージとして出力したメッセージを監視者の必要性に応じて正式なメッセージとして登録することができる点、あるいは二度と出力させなくすることもできる。その理由は、不明メッセージを出すだけであれば従来からある分析エンジン機能などを用いれば実現可能であるが、それが監視者の望むものかどうかまでは判断できなかった。本発明では不明メッセージ画面を見た監視者が今後の出力対象とする/しないを選択することで二度と出力させなくすることが可能となり、無駄のない運用監視が可能となる。また、不明メッセージ本文には出力条件の閾値が明記されているのでそれをフィルタ条件とすれば用意に登録することができる。

また、通常運用メッセージの場合、監視者はあまり気を付けて確認しない事が多いと考えられるが、該当メッセージが断続的に発生するといった問題が発生した場合に監視者が検知することができ、メッセージフィルタ定義の見直しが出来る。その理由は、本発明では運用メッセージの出力頻度をエージェント内部でチェックする機構を持ち、予め設定しておいた閾値（条件）を超えた場合、その旨を通知するマイナーメッセージを監視画面出力するためである。つまり、運用メッセージであっても断続的に発生し続ける場合、何かしらの問題である可能性が考えられ、従来であれば気付けなかった問題をいち早く検知してそれに伴う二次災害発生の可能性を事前に防ぐことが出来る。これにより、メッセージフィルタの見直しなどその後の運用をより最適に行うことができる。

また、通常運用に従ってメッセージフィルタ定義不足や不適切な設定を解消することができる点、またはサービスの変化に追随して最適なフィルタ定義を維持できる。その理由は、システムを運用していく上で、サービスの拡充に伴い負荷量が増大するとして、それに伴いフィルタ定義を修正すべき状況になったとしても、フィルタ定義不足や不適切な定義は自動的に検知することが出来るためである。

なお、上述する各実施の形態は、本発明の好適な実施の形態であり、本発明の要旨を逸脱しない範囲内において種々変更実施が可能である。例えば、監視端末装置１００とマネージャ装置２００とエージェント装置３００の機能を実現するためのプログラムを各装置に読込ませて実行することにより各装置の機能を実現する処理を行ってもよい。さらに、そのプログラムは、コンピュータ読み取り可能な記録媒体であるＣＤ−ＲＯＭまたは光磁気ディスクなどを介して、または伝送媒体であるインターネット、電話回線などを介して伝送波により他のコンピュータシステムに伝送されてもよい。

本発明はミッションクリティカルなコンピュータシステムを運用管理する分野に適用可能である。

本発明の実施の形態に係るシステム構成を示す図である。本発明の実施の形態に係る不明メッセージ出力（フィルタ定義不足検知）条件、マイナーメッセージ出力（不適切なフィルタ定義検知）条件の登録動作について説明する図である。本発明の実施の形態に係る表示例を示す図である。本発明の実施の形態に係る不明メッセージや運用メッセージを知らせるマイナーメッセージを出力させる流れについて説明する図である。本発明の実施の形態に係るデータ構成を示す図である。本発明の実施の形態に係るメッセージの一例を示す図である。本発明の実施の形態に係る不明メッセージ出力後に監視者（管理者）が行う作業の流れについて説明する図である。

符号の説明

１００監視端末装置
１０１メッセージ要求受信手段
１０２メッセージ出力手段
１０３ルール拡張要求手段
２００マネージャ装置
２０１メッセージ出力要求送受信手段
２０２出力情報判定手段
２０３ルール拡張要求送受信手段
２０４出力ルール蓄積部Ａ
３００エージェント装置
３０１異常検出手段
３０２障害判定手段
３０３メッセージ出力要求送信手段
３０４ルール拡張手段
３１０メッセージ情報記憶部
３１１出力情報蓄積部
３１２出力ルール蓄積部Ｂ

Claims

コンピュータシステムのエラーメッセージの出力をルールに従ってフィルタリングする運用管理システムにおいて、
該ルール上で未登録のメッセージをログ出力する度に、あらかじめ登録した不明メッセージの出力条件の閾値を越えたか判断し、越えた場合に管理者用監視端末に出力することを特徴とする運用管理システム。
前記未登録のメッセージが発生頻度に応じて監視画面に発生条件としての閾値情報と共に出力されることを特徴とする請求項１記載の運用管理システム。
出力されたメッセージは、監視者の判断で出力ルール蓄積部に正式な登録メッセージとして出力対象として登録することを特徴とする請求項１または２記載の運用管理システム。
出力されたメッセージは、監視者の判断で出力ルール蓄積部に登録メッセージとして出力対象外として登録することを特徴とする請求項１から３のいずれか１項に記載の運用管理システム。
コンピュータシステムのエラーメッセージの出力をルールに従ってフィルタリングする運用管理システムにおいて、
該ルール上で運用メッセージをログ出力する度に、あらかじめ登録した運用メッセージの出力条件の閾値を越えたか判断し、越えた場合に管理者用監視端末に出力することを特徴とする運用管理システム。
前記運用メッセージが発生頻度に応じてその旨を通知するマイナーメッセージを発生条件としての閾値情報と共に出力されることを特徴とする請求項５記載の運用管理システム。
フィルタ定義として「登録済」と「未登録」のメッセージを明確に区分し、それぞれに分析されることを特徴とする請求項１から６のいずれか１項に記載の運用管理システム。
コンピュータシステムのエラーメッセージの出力をルールに従ってフィルタリングする定義不足の分析方法において、
該ルール上で未登録のメッセージをログ出力する度に、あらかじめ登録した不明メッセージの出力条件の閾値を越えたか判断し、越えた場合に管理者用監視端末に出力することを特徴とする定義不足の分析方法。
前記未登録のメッセージが発生頻度に応じて監視画面に発生条件としての閾値情報と共に出力されることを特徴とする請求項８記載の定義不足の分析方法。
出力されたメッセージは、監視者の判断で出力ルール蓄積部に正式な登録メッセージとして出力対象として登録することを特徴とする請求項８または９記載の定義不足の分析方法。
出力されたメッセージは、監視者の判断で出力ルール蓄積部に登録メッセージとして出力対象外として登録することを特徴とする請求項８から１０のいずれか１項に記載の定義不足の分析方法。
コンピュータシステムのエラーメッセージの出力をルールに従ってフィルタリングする定義不足の分析方法において、
該ルール上で運用メッセージをログ出力する度に、あらかじめ登録した運用メッセージの出力条件の閾値を越えたか判断し、越えた場合に管理者用監視端末に出力することを特徴とする定義不足の分析方法。
前記運用メッセージが発生頻度に応じてその旨を通知するマイナーメッセージを発生条件としての閾値情報と共に出力されることを特徴とする請求項１２記載の定義不足の分析方法。
フィルタ定義として「登録済」と「未登録」のメッセージを明確に区分し、それぞれに分析されることを特徴とする請求項８から１３のいずれか１項に記載の定義不足の分析方法。