(57)【要約】【課題】コンピュータシステムで発生した事象を効率的かつ迅速に判定する。【解決手段】コンピュータシステムの複数の構成要素は、複数の属性カテゴリーのうちのいずれかに属する。ログデータベース２０は、構成要素からのログを蓄積する。ログ検索部２０は、コンピュータシステムで特定の事象が発生したか否かを判定するための事象条件が属性カテゴリーと論理演算子で定義され、事象条件の属性カテゴリーに対して、当該属性カテゴリーの構成要素と論理演算子とで定義された選択条件が記述され、選択条件の構成要素に対してログ検索条件が記述されたイベント要因ツリーを用いてログを検索し、ログ検索条件に合うログが検索された構成要素と選択条件の構成要素及び論理演算子とを照合し、選択条件が成立する属性カテゴリーを選択し、選択した属性カテゴリーと事象条件の属性カテゴリー及び論理演算子とを照合して特定の事象が発生したか否かを判定する。【選択図】図１
2015099533.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータシステムに含まれる複数の構成要素であって、それぞれの属性に応じて複数の属性カテゴリーのうちのいずれかの属性カテゴリーに属する複数の構成要素から出力されるログを蓄積するログ蓄積部と、
前記コンピュータシステムで特定の事象が発生したか否かを判定するための事象条件が属性カテゴリーと論理演算子とで定義され、前記事象条件の定義に用いられた属性カテゴリーに対して、当該属性カテゴリーに属する構成要素と論理演算子とで定義された選択条件が記述され、前記選択条件の定義に用いられた構成要素に対してログ検索条件が記述されている条件情報を記憶する条件情報記憶部と、
前記条件情報のログ検索条件を用いて前記ログ蓄積部を検索し、ログ検索条件に合致するログが検索された構成要素と前記選択条件で定義されている構成要素及び論理演算子とを照合し、前記選択条件が成立する属性カテゴリーを選択し、選択した属性カテゴリーと前記事象条件で定義されている属性カテゴリー及び論理演算子とを照合して前記コンピュータシステムで前記特定の事象が発生したか否かを判定する検索判定部とを有することを特徴とする情報処理装置。
【請求項２】
前記条件情報記憶部は、
要求されるログ検索件数が要求ログ検索件数として定義されている条件情報を記憶しており、
前記検索判定部は、
前記要求ログ検索件数以上のログが検索された構成要素と前記選択条件で定義されている構成要素及び論理演算子とを照合することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記条件情報記憶部は、
前記コンピュータシステムで発生する複数の事象について、事象ごとに、異なる事象条件と選択条件とログ検索条件とが定義されている条件情報を記憶しており、
前記検索判定部は、
複数の条件情報の中から選択された条件情報を用いて前記コンピュータシステムで発生した事象を判定することを特徴とする請求項１に記載の情報処理装置。
【請求項４】
前記情報処理装置は、更に、
前記条件情報に基づき、前記コンピュータシステムの前記特定の状態と、前記事象条件の定義に用いられている属性カテゴリーと、前記選択条件の定義に用いられている構成要素とを、ツリー構造で表示する表示部を有することを特徴とする請求項１に記載の情報処理装置。
【請求項５】
前記表示部は、
前記検索判定部により前記ログ検索条件に合致するログが検索された構成要素と、前記検索判定部により選択された属性カテゴリーとを、前記検索判定部により前記ログ検索条件に合致するログが検索されなかった構成要素と、前記検索判定部により選択されなかった属性カテゴリーとから区別して表示し、
前記検索判定部により前記コンピュータシステムで前記特定の事象が発生したと判定された場合に、前記コンピュータシステムで前記特定の事象が発生した旨を表示することを特徴とする請求項４に記載の情報処理装置。
【請求項６】
前記表示部は、
前記ログ検索条件に合致するログが検索された構成要素に対して、検索されたログを表すマークを、ログに記述されている時刻に従って、時系列に表示することを特徴とする請求項５に記載の情報処理装置。
【請求項７】
前記条件情報記憶部は、
前記事象条件の定義に用いられていない属性カテゴリーである定義外属性カテゴリーに対して、前記定義外属性カテゴリーに属する構成条件である定義外構成要素と論理演算子とが定義された定義外選択条件が記述され、前記定義外構成要素に対してログ検索条件が記述されている条件情報を記憶し、
前記検索判定部は、
前記定義外構成要素のログ検索条件を用いて前記ログ蓄積部を検索し、ログ検索条件に合致するログが検索された定義外構成要素と前記定義外選択条件で定義されている定義外構成要素及び論理演算子とを照合し、
前記表示部は、
前記定義外構成要素のログ検索条件に合致するログが検索され、前記定義外属性カテゴリーで前記定義外選択条件が成立した場合に、前記定義外構成要素のログ検索条件に合致するログが検索された旨、前記定義外属性カテゴリーで前記定義外選択条件が成立した旨を表示することを特徴とする請求項５に記載の情報処理装置。
【請求項８】
前記表示部は、
前記ログ検索条件に合致するログが検索された定義外構成要素に対して、検索されたログを表すマークを、ログに記述されている時刻に従って、時系列に表示することを特徴とする請求項７に記載の情報処理装置。
【請求項９】
コンピュータシステムに含まれる複数の構成要素であって、それぞれの属性に応じて複数の属性カテゴリーのうちのいずれかの属性カテゴリーに属する複数の構成要素から出力されるログを蓄積するログ蓄積部と、
前記コンピュータシステムで特定の事象が発生したか否かを判定するための事象条件が属性カテゴリーと論理演算子とで定義され、前記事象条件の定義に用いられた属性カテゴリーに対して、当該属性カテゴリーに属する構成要素と論理演算子とで定義された選択条件が記述され、前記選択条件の定義に用いられた構成要素に対してログ検索条件が記述されている条件情報を記憶する条件情報記憶部とを有するコンピュータに、
前記条件情報のログ検索条件を用いて前記ログ蓄積部を検索し、ログ検索条件に合致するログが検索された構成要素と前記選択条件で定義されている構成要素及び論理演算子とを照合し、前記選択条件が成立する属性カテゴリーを選択し、選択した属性カテゴリーと前記事象条件で定義されている属性カテゴリー及び論理演算子とを照合して前記コンピュータシステムで前記特定の事象が発生したか否かを判定する検索判定処理を実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
コンピュータシステムの構成要素から出力されたログから、コンピュータシステムで発生した事象を判定する技術に関する。
【背景技術】
【０００２】
多機器、多階層（ＨＷ（Ｈａｒｄｗａｒｅ）、ＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）、アプリケーション（以下、「アプリ」ともいう））からなるコンピュータシステムにおいては、障害の発生時に、障害の発生条件の確認や要因の調査が難しいという課題がある。
特許文献１においては、多階層システムにおいて、異常の伝播がある要素間を結ぶシステムトポロジをあらかじめ定義し、多階層システムの複数の要素で発生した異常が、そのシステムトポロジに当てはまるかどうかを確認し、当てはまる場合に、伝播の最上流にある異常要素を原因として特定することが開示されている。
【０００３】
また、特許文献２においては、アラームログ、異常ログ、操作ログ、通信ログなど種類や発生源の異なるログから、特定時間範囲内のレコードを抽出し、発生順に並べたファイルを生成・表示することが開示されている。
ユーザはこれを検索することで、個別のログを解析して結果を付き合わせる場合に比べて、障害の解析を容易に行うことができる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】国際公開ＷＯ２０１０／０１６２３９号公報
【特許文献２】特開２００８−２８９８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
特許文献１の技術では、異常を検知しない要素に関してはトポロジの合致判定が行われないので、異常の真の原因にたどり着けない場合があるという課題がある。
例えば、操作員が間違った操作をしたことに起因する異常は、その操作自体が正常に終了する場合、操作ログをつき合わせてみなければわからない。
また正常に動作している別のアプリケーションの影響（リソース競合など）により異常が発生するような場合にも、異常の真の原因を追跡することができない。
【０００６】
特許文献２の技術を適用する場合でも、多機器、多階層からなる複雑なコンピュータシステムでは、操作ログや通信ログなどの異常以外のログが大量に蓄積されるため、単純に時系列に並べただけでは、ログの量が膨大となって人手による確認が困難であるという課題がある。
【０００７】
本発明は、上記の事情に鑑みたものであり、コンピュータシステムの構成要素から出力されたログから、コンピュータシステムで発生した事象を効率的かつ迅速に判定する構成を得ることを主な目的とする。
【課題を解決するための手段】
【０００８】
本発明に係る情報処理装置は、
コンピュータシステムに含まれる複数の構成要素であって、それぞれの属性に応じて複数の属性カテゴリーのうちのいずれかの属性カテゴリーに属する複数の構成要素から出力されるログを蓄積するログ蓄積部と、
前記コンピュータシステムで特定の事象が発生したか否かを判定するための事象条件が属性カテゴリーと論理演算子とで定義され、前記事象条件の定義に用いられた属性カテゴリーに対して、当該属性カテゴリーに属する構成要素と論理演算子とで定義された選択条件が記述され、前記選択条件の定義に用いられた構成要素に対してログ検索条件が記述されている条件情報を記憶する条件情報記憶部と、
前記条件情報のログ検索条件を用いて前記ログ蓄積部を検索し、ログ検索条件に合致するログが検索された構成要素と前記選択条件で定義されている構成要素及び論理演算子とを照合し、前記選択条件が成立する属性カテゴリーを選択し、選択した属性カテゴリーと前記事象条件で定義されている属性カテゴリー及び論理演算子とを照合して前記コンピュータシステムで前記特定の事象が発生したか否かを判定する検索判定部とを有することを特徴とする。
【発明の効果】
【０００９】
本発明によれば、ログ検索条件に合致するログが検索された構成要素と選択条件で定義されている構成要素及び論理演算子との照合、成立条件が成立する属性カテゴリーと事象条件で定義されている属性カテゴリー及び論理演算子との照合により、コンピュータシステムで発生した事象を効率的かつ迅速に判定することができる。
【図面の簡単な説明】
【００１０】
【図１】実施の形態１に係るイベント監視・解析装置の構成例を示す図。
【図２】実施の形態１に係るログデータベースのテーブル構成例を示す図。
【図３】実施の形態１に係るイベント要因ツリーの概念を示す図。
【図４】実施の形態１に係るノードテーブルの例を示す図。
【図５】実施の形態１に係るエッジテーブルの例を示す図。
【図６】実施の形態１に係る索引条件入力画面の例を示す図。
【図７】実施の形態１に係る索引結果表示画面の例を示す図。
【図８】実施の形態１に係る検索問い合わせ文の例を示す図。
【図９】実施の形態１に係るイベント監視・解析装置の動作例を示すフローチャート図。
【図１０】実施の形態１に係るイベント監視・解析装置のハードウェア構成例を示す図。
【発明を実施するための形態】
【００１１】
実施の形態１．
以下では、イベント監視・解析装置の実施の形態について説明する。
以下に説明する実施の形態は、この発明の一例を示すものであって、具体的構成を限定するものではない。
【００１２】
本実施の形態では、イベント監視・解析装置が、コンピュータシステムで発生した事象として、コンピュータシステムで発生した障害を特定する例を説明する。
より具体的には、多機器、多階層（ＨＷ、ＯＳ、アプリケーション）からなるシステムにおいて、障害の発生時に収集したエラーログやシステムのトレース情報から関連するイベントの検索実行および検索結果確認を容易に行え、障害の発生条件の確認と要因の調査を迅速に行えるイベント監視・解析装置を説明する。
【００１３】
図１は、本実施の形態に係るイベント監視・解析装置１０の構成例を示す。
イベント監視・解析装置１０は、情報処理装置の例に相当する。
【００１４】
図１において、イベント監視・解析装置１０は、ログ記憶処理部１１、ログ検索部１２、検索結果表示部１３、イベント要因ツリー入力部１４、イベント要因ツリー管理部１５、検索条件入力部１６、問い合わせ生成部１７、ログデータベース２０、イベント要因ツリーデータベース３０から構成される。
イベント監視・解析装置１０は、単一のコンピュータハードウェア上に構成されてもよいし、ネットワークで接続された複数台のコンピュータハードウェア上に構成されてもよい。
【００１５】
各種ログ４０は、イベント監視・解析の対象とするコンピュータシステムの構成要素からネットワーク等を経由して収集された複数種類のログであり、例えば操作ログ４１、アプリログ４２、ＯＳログ４３、ＨＷログ４４などを含むが、それ以外のログを含んでもよい。
各種ログ４０はログ記憶処理部１１を通じて、ログデータベース２０に蓄積される。
ログ記憶処理部１１は、収集されたログを１イベント１レコードとしてログデータベース２０に蓄積してもよいし、収集されたログを整形あるいはログ中の一部分を抽出するなどの形式変換を行ってログデータベース２０に蓄積してもよい。
ログデータベース２０は、ログ蓄積部の例に相当する。
【００１６】
図２は、ログデータベース２０のテーブル構成の一例を示すものである。
この例は、収集されたログの形式変換を行って、あらかじめ定めたカラムにログから抽出された値を格納する場合の例である。
図２において、カラム「ＳｅｑＮｏ」はレコードを一意に特定するシリアル番号であり、整数値を取る。
カラム「ＬｏｇＴｉｍｅ」はログ中のイベントのタイムスタンプであり、日時および時刻を表す。
カラム「ＬｏｇＩＤ」はログの種類を示す識別子であり、操作ログ、ＨＷログ、ＯＳログ、アプリログなどの文字列値を取る例を示した。
数値にエンコードされたＩＤとすることもできることは以下のカラムも同様である。
カラム「ＭａｃｈｉｎｅＩＤ」はイベント発生源の機器の識別子であり、Ｔｅｒｍｉｎａｌ＿１やＳｅｒｖｅｒ＿１などの文字列値を取る例を示した。
カラム「ＤｅｖｉｃｅＩＤ」はイベント発生源の機器に含まれる、イベント発生源のデバイスの識別子であり、機器Ｓｅｒｖｅｒ＿１に内蔵されるネットワークデバイスＬＡＮ１などの値を取る例を示した。
カラム「ＰｒｏｃｅｓｓＮａｍｅ」はイベント発生源のソフトウェアのプロセス名を示し、アプリケーション１に対応する名前ＡＰＰ１などの値を取る例を示した。
カラム「ＥｒｒｏｒＩＤ」はイベントのエラー種別を示す識別子であり、ＨＷＥＲＲ、ＮＷ１ＥＲＲ、ＡＰＰ１ＮＷエラーなどの値を取る例を示した。
カラム「Ｍｅｓｓａｇｅ」はイベントの説明のためのメッセージである。
【００１７】
イベント要因ツリーデータベース３０は、イベント要因ツリーを記憶する。
イベント要因ツリーは、コンピュータシステムで発生した障害（事象）を判定するための情報である。
【００１８】
図３は、イベント要因ツリーデータベース３０に格納されるイベント要因ツリーの概念を示す図である。
要因ノード１１０はツリー構造の最上位のノードであり、「ＮＷ障害」という名前がついている。
ネットワーク障害の要因を表すイベント要因ツリーであることを示している。
要因ノード２１０、２２０、２３０、２４０はツリー構造の２階層目のノードであり、それぞれ「操作」、「アプリ」、「ＯＳ」、「ＨＷ」という名前が付いている。
ネットワーク障害の要因のうち、それぞれ操作ログ、アプリログ、ＯＳログ、ＨＷログに含まれるイベントを要因とすることを示している。
要因ノード３１０、３２０、３３０、３４０、３５０、３６０、３７０、３８０はツリー構造の３階層目のノードである。
要因ノード３１０、３２０は要因ノード２１０の下位ノードであり、それぞれ「端末１」、「端末２」という名前が付いている。
それぞれ端末１、端末２の操作ログに含まれるイベントを要因とすることを示している。
要因ノード３３０、３４０は要因ノード２２０の下位ノードであり、それぞれ「アプリ１」、「アプリ２」という名前が付いている。
それぞれアプリケーション１、アプリケーション２から出力されるアプリログに含まれるイベントを要因とすることを示している。
要因ノード３５０、３６０は要因ノード２３０の下位ノードであり、それぞれ「ＮＷ１」、「ＮＷ２」という名前が付いている。
それぞれＯＳログのうちネットワークデバイス１、ネットワークデバイス２に関連するイベントを要因とすることを示している。
要因ノード３７０、３８０は要因ノード２４０の下位ノードであり、それぞれ「ＬＡＮ  ＩＦ１」、「ＬＡＮ  ＩＦ２」という名前が付いている。
それぞれＨＷログのうち、ネットワークインタフェース１、ネットワークインタフェース２に関連するイベントを要因とすることを示している。
「端末１」、「端末２」、「アプリ１」、「アプリ２」、「ＮＷ１」、「ＮＷ２」、「ＬＡＮ  ＩＦ１」、「ＬＡＮ  ＩＦ２」の各々は、イベント監視・解析の対象のコンピュータシステムの構成要素である。
【００１９】
イベント要因ツリーは、各要因ノードにおいて、その要因ノードに関連するイベント検索条件を設定することができる。
イベント検索条件は、ログデータベース２０を検索して該当する要因ノードのイベントを抽出するための検索条件である。
以下の例では、ログデータベース２０をＤＢＭＳ（ＤａｔａＢａｓｅ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ）を用いて実装する場合の例を示す。
この場合、ＤＢＭＳの問い合わせ言語であるＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ  Ｑｕｅｒｙ  Ｌａｎｇｕａｇｅ）のＷＨＥＲＥ句に使用可能な構文を用いて表記することにより、柔軟な検索条件を設定することができ、さらに後に述べる問い合わせ生成を容易に実現することができる。
ログデータベース２０をその他の技術を用いて実現する場合には、相当する検索条件を設定するものとする。
例えば、ログデータベース２０をテキストファイルとし、ＵＮＩＸ（登録商標）  ＯＳのｇｒｅｐコマンドにより検索を行う場合であれば、イベント検索条件はｇｒｅｐコマンドが解釈可能な正規表現を用いればよい。
【００２０】
図３のイベント要因ツリーでは、要因ノード３１０〜３８０にそれぞれイベント検索条件３１１〜３８１が設定されている。
イベント検索条件３１１には図２のテーブルのＭａｃｈｉｎｅＩＤのフィールドがＴｅｒｍｉｎａｌ＿１であるときに抽出を行う検索条件として、「ＭａｃｈｉｎｅＩＤ＝Ｔｅｒｍｉｎａｌ＿１」が設定されている。
イベント検索条件３７１には、図２のテーブルのＥｒｒｏｒＩＤフィールドがＨＷＥＲＲであり、かつ、ＤｅｖｉｃｅＩＤフィールドがＬＡＮ１であるときに抽出を行う検索条件として、「ＥｒｒｏｒＩＤ＝ＨＷＥＲＲ  ＡＮＤ  ＤｅｖｉｃｅＩＤ＝ＬＡＮ１」が設定されている。
【００２１】
イベント要因ツリーはさらに、各要因ノードにおいて、下位ノードの検索結果に対する論理演算を設定することができる。
図３のイベント要因ツリーでは、要因ノード２１０に示す「＋」は要因ノード３１０と３２０の論理和（ＯＲ）であることを示す。
すなわち、要因ノード２１０の検索は、「ＭａｃｈｉｎｅＩＤ＝Ｔｅｒｍｉｎａｌ＿１」が成立するレコードがあるか、または、「ＭａｃｈｉｎｅＩＤ＝Ｔｅｒｍｉｎａｌ＿２」が成立するレコードがある場合に成立する。
成立しない要因ノードの検索結果は無しとなり、成立した要因ノードの検索結果は、成立したレコードがすべて返される。
要因ノード２２０〜２４０も同様に論理和（ＯＲ）演算が設定されている。
要因ノード１１０に示す「＊」は要因ノードの論理積（ＡＮＤ）であることを示す。
また、「・」は検索のみ行い、論理演算を行わない要因ノードであることを示す。
したがって、要因ノード１１０は要因ノード２２０が成立するレコードがあり、要因ノード２３０が成立するレコードがあり、かつ論理ノード２４０が成立するレコードがある場合に成立し、成立した場合に、要因ノード２２０、２３０、２４０が成立するレコードと、要因ノード２１０が成立するレコードが検索結果となる。
成立しない場合には、要因ノード２１０の成立に係らず、検索結果は無しとなる。
【００２２】
このように、コンピュータネットワークの構成要素である「端末１」、「端末２」、「アプリ１」、「アプリ２」、「ＮＷ１」、「ＮＷ２」、「ＬＡＮ  ＩＦ１」、「ＬＡＮ  ＩＦ２」は、それぞれの属性に応じて複数の上位の要因ノード２１０〜２４０（属性カテゴリーの例）のうちのいずれかの要因ノードに属している。
また、要因ノード１１０は、「ＮＷ障害」という障害（事象）がコンピュータシステムに発生したか否かを判定するための条件であり、事象条件の例に相当する。
また、要因ノード「アプリ」、要因ノード「ＯＳ」、要因ノード「ＨＷ」の各々の条件は、コンピュータシステムの構成要素（「アプリ１」と「アプリ２」、「ＮＷ１」と「ＮＷ２」、「ＬＡＮ  ＩＦ１」と「ＬＡＮ  ＩＦ２」）と論理演算子「＋」とで定義されており、選択条件の例に相当する。
なお、図３の例において、「操作」は「ＮＷ障害」の成立条件の対象外であり、定義外属性カテゴリーの例に相当する。
また、「操作」の下位の要因ノードである「端末１」及び「端末２」は定義外構成要素の例に相当する。
そして、「操作」の条件である「端末１」＋「端末２」は定義外選択条件の例に相当する。
また、イベント検索条件３１１〜３８１は、ログデータベース２０を検索するための条件であり、ログ検索条件の例に相当する。
イベント要因ツリーは条件情報の例に相当し、イベント要因ツリーデータベース３０は条件情報記憶部の例に相当する。
【００２３】
イベント要因ツリーデータベース３０は、例えば、要因ノードの情報を保持するノードテーブルと、要因ノード間の接続関係を保持するエッジテーブルにより構成することができる。
【００２４】
図４はイベント要因ツリーデータベース３０のノードテーブルの一例を示す。
「ＮｏｄｅＩＤ」フィールドは要因ノードの識別子を保持する。
「ＴｒｅｅＮａｍｅ」フィールドはイベント要因ツリーの名前を保持する。
「ＮｏｄｅＮａｍｅ」フィールドは要因ノードの名前を保持する。
「Ｃｏｎｄｉｔｉｏｎ」フィールドはイベント検索条件を保持する。
例えば、ＮｏｄｅＩＤ＝１１０は「ＮＷ障害」という名前のイベント要因ツリーに属し、要因ノードの名前は「ＮＷ障害」であり、イベント検索条件を持たない。
また、ＮｏｄｅＩＤ＝３１０の要因ノードの名前は「端末１」であり、イベント検索条件は「ＭａｃｈｉｎｅＩＤ＝Ｔｅｒｍｉｎａｌ＿１」である。
【００２５】
図５はイベント要因ツリーデータベース３０のエッジテーブルの一例を示す。
「ＥｄｇｅＩＤ」フィールドはエッジの識別子を保持する。
「ＴｒｅｅＮａｍｅ」フィールドはイベント要因ツリーの名前を保持する。
「ＰａｒｅｎｔＩＤ」は親要因ノード（上位の要因ノード）の「ＮｏｄｅＩＤ」を保持する。
「ＣｈｉｌｄＩＤ」は子要因ノード（下位の要因ノード）の「ＮｏｄｅＩＤ」を保持する。
「Ｏｐｅｒａｔｏｒ」は論理演算子の識別子を保持する。
例えば、ＥｄｇｅＩＤ＝１のエッジは、「ＮＷ障害」という名前のイベント要因ツリーに属し、要因ノードＮｏｄｅＩＤ＝１１０の下位に要因ノードＮｏｄｅＩＤ＝２１０を接続し、論理演算子は「・」である。
【００２６】
イベント要因ツリーは、イベント要因ツリー入力部１４により入力される。
イベント要因ツリーデータベースへの入力内容をＣＳＶ等のファイル形式で入力するようにしてもよいし、ＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）を通じて入力するようにしてもよい。
イベント要因ツリーは、様々な要因の解析のために、複数個を入力することができ、名前で識別されるようにすることができる。
【００２７】
検索条件入力部１６は、検索条件入力画面を表示してユーザによる検索条件入力を可能とする。
画面はイベント監視・解析装置１０に接続されたディスプレイに表示してもよいし、一般的に行われているようにＷＷＷ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ）技術を用いてネットワーク上の端末に表示可能なように構成してもよい。
【００２８】
図６は検索条件入力部１６による検索条件入力画面の例を示す。
検索条件入力画面４００は、イベント要因ツリー指定領域４１０、検索実行ボタン４２０、検索条件（期間）入力領域４３０、イベント要因ツリー表示領域４４０、イベント表示領域４５０から構成される。
イベント要因ツリー指定領域４１０は検索に使用するイベント要因ツリーの名前を入力可能とするもので、テキスト入力領域および入力完了ボタンとして構成することもできるが、プルダウンメニューによりイベント要因ツリーデータベース３０に登録済みのイベント要因ツリー名から選択可能な構成とすることでよりユーザの利便性が向上する。
指定されたイベント要因ツリーはイベント要因ツリーデータベース３０から抽出されてイベント要因ツリー表示領域４４０に表示される。
検索条件（期間）入力領域４３０はログの検索対象とする期間を指定可能とするもので、開始日時、終了日時の指定が可能である。
検索条件として、これ以外にログデータベース２０の特定のフィールドのキーワード指定などの条件を加えてもよい。
イベント要因ツリー表示領域４４０は、要因ノード名表示領域４４１、要因ノード検索指示領域４４２、要因ノード検索結果表示領域４４３を１要素として、ツリー構成での表示を行う。
要因ノード名表示領域４４１は要因ノードの名前を表示する。
要因ノード検索指示領域４４２は該当する要因ノードの検索の実行／不実行を指定可能とするもので、チェックボックス等により構成され、チェックした場合に該当する要因ノードの検索条件に基く検索を実行し、チェックしない場合に検索を実行しない。
要因ノード検索結果表示領域４４３およびイベント表示領域４５０は検索条件入力時には使用されず、後述する検索結果表示にて使用される。
検索条件入力部１６はイベント要因ツリーを含む検索条件入力画面を表示しており、表示部の例に相当する。
【００２９】
図７は、検索結果表示部１３による検索結果表示画面の例を示すものである。
この例では、図６の検索条件入力画面４００と同じ画面を用いて検索結果を表示する場合の例を示すが、別な画面により構成してもよい。検索結果表示部１３は、検索結果より、検索条件が成立し検索結果が得られた要因ノードに対して、要因ノード名表示領域４４１の色を変えて（図７では白から黒に）表示し、各要因ノードの成立状況を一覧可能とする。
要因ノード検索結果表示領域４４３には、検索条件が設定された要因ノードについて、結果件数が表示される。
図７の例は、図３のイベント要因ツリーを元にした検索結果例であり、「アプリ１」の検索結果が１件であることから「アプリ１」が成立し、その結果「アプリ」が成立する。
「ＮＷ１」の検索結果が１件であることから、「ＮＷ１」が成立し、その結果「ＯＳ」が成立する。
「ＬＡＮ  ＩＦ１」の検索結果が１件であることから、「ＬＡＮ  ＩＦ１」が成立し、その結果「ＨＷ」が成立する。
「アプリ」と「ＯＳ」と「ＨＷ」がそれぞれ成立したため、ＡＮＤ条件により「ＮＷ障害」が成立する。
したがって、指定の期間内のログに「ＮＷ障害」のパターンに合致したイベントが存在することをユーザが一目で確認できる。
なお、「操作」については、検索のみで論理演算を行わない要因ノードであるため、「ＮＷ障害」の成立には関係しないが、「端末１」の検索結果が３件であるため、「端末１」が成立し、その結果「操作」が成立しており、障害に関連して確認が必要なログがあることをユーザが認識できる。
また、成立の条件を上記では１件以上としているが、イベント要因ツリーにおいて要因ノードごとに検索件数の閾値である件数閾値（要求ログ検索件数）を設定可能とし、件数閾値を超えた場合に成立としてもよい。
【００３０】
イベント表示領域４５０には、検索結果のイベントがイベントマーク４５１により時系列で表示される。
各イベントマーク４５１の位置は、検索されたログに記述されている日付・時刻に対応している。
横軸は時間軸となっており、検索条件（期間）にて指定した期間が表示されるが、拡大・縮小などの表示切替が出来るようにしてもよい。
縦軸は各要因ノードに対応している。
イベント詳細４５２は、検索されたログを示すイベントマーク４５１をマウスでクリックする、あるいはマウスカーソルを載せることにより表示される該当イベントの詳細情報であり、ログデータベース２０に保存された該当レコードの任意の情報を表示させるようにできる。
図７では「Ｍｅｓｓａｇｅ」フィールドを表示した例を示す。
なお、イベント表示領域４５０は例示したようなグラフ表示のほかに、図２に示したようなテーブルを表形式で表示することでもよい。
検索結果表示部１３は検索結果表示画面を表示しており、前述の検索条件入力部１６とともに表示部の例に相当する。
【００３１】
問い合わせ生成部１７は、検索条件入力部１６にて入力されたイベント要因ツリーおよび検索条件（期間）から、ログデータベース２０の検索問い合わせ文を生成する。
つまり、問い合わせ生成部１７は、図３のイベント要因ツリーのイベント検索条件３１１〜３８１を用いて検索問い合わせ文を生成する。
ログデータベース２０をＤＢＭＳを用いて構成した場合の擬似ＳＱＬによる検索問い合わせ文の例を図８に示す。
行番号１〜１８はＳＥＬＥＣＴ句である。
行番号２は図２に例示したログデータベース２０の各フィールドから検索結果表示に必要なフィールドを選択して生成される。
行番号３〜１０は、イベント検索条件が設定された要因ノードに関して、各レコードがイベント検索条件にヒットしたかどうかを示す仮想的なカラムを定義するものであり、要因ノード名をカラム名として持つ。
１であればイベント検索条件にヒットしたことを示し、０であればヒットしなかったことを示す。
例えば、ＭａｃｈｉｎｅＩＤ＝Ｔｅｒｍｉｎａｌ＿１であるレコードの「端末１」カラムが値１を持つ。
これらのカラムの内容により、検索結果表示部１３がイベント表示領域４５０にイベントマークをプロットする際の検索結果レコードと要因ノードとの関連付けを行う。
行番号１１〜１８は、イベント検索条件が設定された要因ノードに関して、イベント検索条件にヒットしたレコード数をカウントした結果を示す仮想的なカラムを定義するものであり、要因ノード名に「＿ＣＯＵＮＴ」を付けたカラム名を持つ。
これらのカラムの内容を、検索結果表示部１３がイベント要因ツリー表示領域４４０の要因ノード検索結果表示領域４４３に表示する。
行番号１９はあらかじめ定められたログデータベース２０のテーブル名を指定するものである。
検索条件入力部１６にてテーブル名を指定したり、設定ファイル等で設定できるようにしてもよい。
行番号２１〜２４は、イベント検索条件にヒットするレコードを選択するためのもので、すべての検索対象となる要因ノードのイベント検索条件を論理和（ＯＲ）にて結合することにより生成される。
行番号２５は、検索条件（期間）の条件を指定するものであり、イベント要因ツリーの検索条件とＡＮＤにより結合される。
イベント要因ツリー以外のその他の検索条件を指定する場合にも、同様に条件を追加することができる。
行番号２６は検索結果のレコードをログ内のタイムスタンプ順にソートするためのものである。
検索結果表示部１３がイベント表示領域４５０に検索結果を表形式で表示する際に時刻順に並べるために使用することができる。
【００３２】
ログ検索部１２は、問い合わせ生成部１７により生成された検索問い合わせ文を用いて、ログデータベース２０を検索する。
そして、検索結果と図３のイベント要因ツリーとを照合して、コンピュータシステムに発生した障害（事象）を判定する。
例えば、図３の「端末１」のイベント検索条件３１１に合致するログが検索され、「アプリ１」のイベント検索条件３３１に合致するログが検索され、「ＮＷ１」のイベント検索条件３５１に合致するログが検索され、「ＬＡＮ  ＩＦ１」のイベント検索条件３７１に合致するログが検索された場合を想定する。
この場合に、ログ検索部１２は、ログの検索結果と「アプリ」の条件（「アプリ１」＋「アプリ２」）とを照合し、「アプリ１」のイベント検索条件３３１に合致するログが検索されているため、「アプリ」の条件が成立していると判断する。
同様にして、ログ検索部１２は、ログの検索結果と「ＯＳ」の条件（「ＮＷ１」＋「ＮＷ２」との照合、ログの検索結果と「ＨＷ」の条件（「ＬＡＮ  ＩＦ１」＋「ＬＡＮ  ＩＦ２」との照合を行い、「ＯＳ」の条件と「ＨＷ」の条件が成立していると判断する。
また、ログ検索部１２は、「アプリ」の条件の成立状況、「ＯＳ」の条件の成立状況、「ＨＷ」の条件の成立状況と、「ＮＷ障害」の条件（「アプリ」＊「ＯＳ」＊「ＨＷ」）とを照合し、「ＮＷ障害」の条件が成立していると判断し、コンピュータシステムに「ＮＷ障害」が発生していると判定する。
この結果、検索結果表示部１３には、図７に示すような各要因ノードの成立状況が表示される。
なお、ログ検索部１２及び問い合わせ生成部１７は、検索判定部の例に相当する。
【００３３】
次に、本実施の形態に係るイベント監視・解析装置１０の動作を説明する。
図９は、本実施の形態に係るイベント監視・解析装置１０によるログの検索動作を示すフローチャートである。
【００３４】
先ず、ユーザが検索条件入力部１６から検索に使用するイベント要因ツリーの名前を入力する（Ｓ１０１）。
検索条件入力部１６は、入力された名前のイベント要因ツリーをイベント要因ツリー管理部１５を通じてイベント要因ツリーデータベース３０から取得する（Ｓ１０２）。
そして、検索条件入力部１６は、取得したイベント要因ツリーを画面表示する（Ｓ１０３）。
次に、ユーザが検索条件入力部１６から検索条件（期間）を入力し、検索実行ボタンを押す（Ｓ１０４）。
検索条件入力部１６は、イベント要因ツリーと検索条件（期間）を問い合わせ生成部１７に送る（Ｓ１０５）。
【００３５】
問い合わせ生成部１７は、問い合わせ文を生成し、ログ検索部１２に問い合わせを発行する（Ｓ１０６）。
ログ検索部１２は、ログデータベース２０から検索結果を抽出し、検索結果表示部１３に送る（Ｓ１０７）。
検索結果表示部１３が検索結果を画面表示する（Ｓ１０８）。
【００３６】
以上により、障害要因の条件成立が直ちに確認できることに加えて、直接エラーとはならない操作のログなどを障害に関連して追跡することが容易となる。
図７の検索結果表示画面の例では、ＮＷ障害の要因として「ＬＡＮ  ＩＦ１」のＨＷＥＲＲが最初に発生しているが、その前にネットワークスイッチの設定を変更する操作が行われていることが分かり、その変更内容の間違いによりネットワーク障害が発生しているようなケースの追跡が可能となる。
【００３７】
なお、図３のイベント要因ツリーでは、論理演算子として「＊」と「＋」を用いているが、これら以外の論理演算子を用いて条件を定義してもよい。
【００３８】
以上、本実施の形態では、ハードウェア及びソフトウェアを含む複数の機能要素から構成されるコンピュータシステムのイベント監視・解析装置を説明した。
そして、本実施の形態に係るベント監視・解析装置が、ログ記憶処理部と、ログ検索部と、イベント要因ツリー入力部と、イベント要因ツリー管理部と、検索条件入力部と、問い合わせ生成部と、検索結果表示部とを備えることを説明した。
【００３９】
ログ記憶処理部は、複数の機能要素が出力する複数種類のログを蓄積して一元管理する。
ログ検索部は、ログに含まれるイベントを指定の問い合わせにより検索する。
イベント要因ツリー入力部は、イベントの検索条件を要因ノードに保存し、要因ノード間の関係性を木構造により管理するイベント要因ツリーを入力する。
イベント要因ツリー管理部は、イベント要因ツリーを管理する。
検索条件入力部は、検索に使用する１つ以上のイベント要因ツリーと、検索期間をユーザに指定させる。
問い合わせ生成部は、指定されたイベント要因ツリーおよび検索期間に基いてログ検索部による検索を行うための問い合わせ文を生成する。
検索結果表示部は、イベント要因ツリーに基いた検索結果を要因ノード毎に表示する。
【００４０】
また、本実施の形態では、イベント要因ツリーには、要因ノードにログから特定のＩＤや名前およびそれらの複数の組合せで識別されるイベントを検索するための０個以上のイベント検索条件が含まれ、要因ノードの下位に接続される要因ノードの検索結果のＡＮＤ、ＯＲの論理演算を行うための下位ノード論理演算条件が含まれることを説明した。
【００４１】
また、本実施の形態では、イベント検索条件には、ログに含まれる特定のイベントの件数のカウントに対し、閾値を超えた場合に条件成立と見なす件数閾値を含ませることができることを説明した。
【００４２】
また、本実施の形態では、検索結果表示部が、イベント要因ツリーを表示し、表示したイベント要因ツリーの各要因ノードに対応する検索結果を表示することを説明した。
【００４３】
また、本実施の形態では、検索結果表示部が、イベント要因ツリーのうち、検索結果のイベントが存在する要因ノードに対してそれぞれ、その要因ノードのイベント発生を時系列でプロットすることを説明した。
【００４４】
また、本実施の形態では、検索条件入力部が、指定のイベント要因ツリーのうち、一部の要因ノードとその下位要因ノードを検索対象外として指定させることができることを説明した。
【００４５】
最後に、本実施の形態に示したイベント監視・解析装置１０のハードウェア構成例を図１０を参照して説明する。
イベント監視・解析装置１０はコンピュータであり、イベント監視・解析装置１０の各要素をプログラムで実現することができる。
イベント監視・解析装置１０のハードウェア構成としては、バスに、演算装置９０１、外部記憶装置９０２、主記憶装置９０３、通信装置９０４、入出力装置９０５が接続されている。
【００４６】
演算装置９０１は、プログラムを実行するＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）である。
外部記憶装置９０２は、例えばＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）やフラッシュメモリ、ハードディスク装置である。
主記憶装置９０３は、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）である。
通信装置９０４は、例えば、ＮＩＣ（Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃａｒｄ）である。
入出力装置９０５は、例えばマウス、キーボード、ディスプレイ装置等である。
【００４７】
プログラムは、通常は外部記憶装置９０２に記憶されており、主記憶装置９０３にロードされた状態で、順次演算装置９０１に読み込まれ、実行される。
プログラムは、図１に示す「〜部」として説明している機能を実現するプログラムである。
更に、外部記憶装置９０２にはオペレーティングシステム（ＯＳ）も記憶されており、ＯＳの少なくとも一部が主記憶装置９０３にロードされ、演算装置９０１はＯＳを実行しながら、図１に示す「〜部」の機能を実現するプログラムを実行する。
また、本実施の形態の説明において、「〜の判断」、「〜の判定」、「〜の抽出」、「〜の検索」、「〜の照合」、「〜の設定」、「〜の登録」、「〜の選択」、「〜の生成」、「〜の入力」、「〜の出力」等として説明している処理の結果を示す情報やデータや信号値や変数値が主記憶装置９０３にファイルとして記憶されている。
【００４８】
なお、図１０の構成は、あくまでもイベント監視・解析装置１０のハードウェア構成の一例を示すものであり、イベント監視・解析装置１０のハードウェア構成は図１０に記載の構成に限らず、他の構成であってもよい。
【符号の説明】
【００４９】
１０  イベント監視・解析装置、１１  ログ記憶処理部、１２  ログ検索部、１３  検索結果表示部、１４  イベント要因ツリー入力部、１５  イベント要因ツリー管理部、１６  検索条件入力部、１７  問い合わせ生成部、２０  ログデータベース、３０  イベント要因ツリーデータベース、４０  各種ログ、４１  操作ログ、４２  アプリログ、４３  ＯＳログ、４４  ＨＷログ。
【図１】
2015099533.tif 000003
【図２】
2015099533.tif 000004
【図３】
2015099533.tif 000005
【図４】
2015099533.tif 000006
【図５】
2015099533.tif 000007
【図６】
2015099533.tif 000008
【図７】
2015099533.tif 000009
【図８】
2015099533.tif 000010
【図９】
2015099533.tif 000011
【図１０】
2015099533.tif 000012