JP2017220139A - ログ解析装置、ログ解析方法及びログ解析プログラム - Google Patents

Abstract

【課題】システムが動作を継続不可能な障害状態が発生することを未然に防止し、システムを継続動作させることを目的とする。【解決手段】ログ解析装置１０は、システム１００を構成する複数の監視対象装置である複数のＤＢサーバ５０から取得された複数のログデータの組合せから、システム１００が動作を継続不可能な障害状態が発生する前兆である前兆状態を特定する。そして、ログ解析装置１０は、前兆状態が特定されると、前兆状態を障害状態と区別してユーザ端末６０に表示する。【選択図】図１

Description

この発明は、ログデータを解析してシステムの状態を表示する技術に関する。

システムを構成する装置から出力されたログデータを解析して、システムに発生している障害の内容及び障害の原因を特定することが行われている（特許文献１参照）。障害の内容及び障害の原因を特定することにより、システムを早期に障害から復旧させることが可能になる。

特開２００５−２８４３５７号公報

しかし、障害が発生してしまうと、システムの動作が継続できなくなってしまう。その結果、利用者がシステムを利用できない状態となってしまう。
この発明は、システムを継続動作させることを目的とする。

この発明に係るログ解析装置は、
複数のログデータの組合せから、システムが動作を継続不可能な障害状態が発生する前兆である前兆状態を特定する状態特定部と、
前記状態特定部によって特定された前記前兆状態を、前記障害状態と区別して表示する表示部と
を備える。

この発明は、複数のログデータの組合せから前兆状態を特定し、障害状態と区別して前兆状態表示する。これにより、システムの状態に応じた適切な対処をすることが可能になる。特に、障害状態ではなく前兆状態であることに気づかせることが可能であるため、障害が発生する前に対処することができ、システムを継続動作させることができる。

実施の形態１に係るシステム１００の構成図。 実施の形態１に係るログ解析装置１０の構成図。 実施の形態１に係る登録処理の処理フロー図。 実施の形態１に係る監視対象ログ登録ウインドウを示す図。 実施の形態１に係る処置管理ウインドウを示す図。 実施の形態１に係る処置管理ウインドウで登録される情報を示す図。 実施の形態１に係る監視処理の処理フロー図。 実施の形態１に係るログ解析結果ウインドウを示す図。 実施の形態１に係るログ解析結果ウインドウの説明図。 実施の形態１に係る実行確認用ポップアップウインドウを示す図。 変形例３に係るログ解析装置１０の構成図。 実施の形態２に係るＡＰＰサーバ４０の構成図。 実施の形態２に係るシステム１００の処理フロー図。

実施の形態１．
＊＊＊構成の説明＊＊＊
図１を参照して、実施の形態１に係るシステム１００の構成を説明する。
システム１００は、ログ解析装置１０と、監視装置２０と、ウェブサーバ３０と、ＡＰＰ（ＡＰＰｌｉｃａｔｉｏｎ）サーバ４０と、複数のＤＢ（ＤａｔａＢａｓｅ）サーバ５０と、ユーザ端末６０とを備える。
ウェブサーバ３０とＡＰＰサーバ４０とは、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）といったネットワークを介して接続されており、ＡＰＰサーバ４０と各ＤＢサーバ５０とは、ＬＡＮといったネットワークを介して接続されている。また、ユーザ端末６０とウェブサーバ３０とは、インターネットといったネットワークを介して接続されている。また、ログ解析装置１０及び監視装置２０と、各ＤＢサーバ５０とは、ＬＡＮといったネットワークを介して接続されている。また、ログ解析装置１０及び監視装置２０と、ユーザ端末６０とは、インターネットといったネットワークを介して接続されている。

ログ解析装置１０は、監視対象装置である各ＤＢサーバ５０からログデータを取得し、解析するコンピュータである。監視装置２０は、監視対象装置である各ＤＢサーバ５０のＣＰＵ使用率、メモリ使用率といったハードウェアの状態を監視するコンピュータである。

ウェブサーバ３０は、ユーザ端末６０からリクエストを受信して、受信したリクエストをＡＰＰサーバ４０に送信するコンピュータである。ＡＰＰサーバ４０は、リクエストに応じて各ＤＢサーバ５０に記憶されたデータを更新するコンピュータである。
各ＤＢサーバ５０は、ＤＢＭＳ（ＤａｔａＢａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）により、データを管理するコンピュータである。実施の形態１では、複数のＤＢサーバ５０は、冗長構成となっており、各ＤＢサーバ５０は、同じ機能である。なお、例えば、一部のＤＢサーバ５０が他のＤＢサーバ５０よりも高性能であるといった違いがあってもよい。

ユーザ端末６０は、ユーザによって使用されるＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）又はスマートフォンといったコンピュータである。

図２を参照して、実施の形態１に係るログ解析装置１０の構成を説明する。
ログ解析装置１０は、プロセッサ１１と、メモリ１２と、通信インタフェース１３とのハードウェアを備える。プロセッサ１１は、システムバスを介して他のハードウェアと接続され、これら他のハードウェアを制御する。

プロセッサ１１は、プロセッシングを行うＩＣ（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）である。プロセッサ１１は、具体例としては、ＣＰＵ、ＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）、ＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ
Ｕｎｉｔ）である。

メモリ１２は、ログ解析装置１０の電源がオフの間も実行プログラム及びデータを保持し続けることが可能な不揮発性メモリと、ログ解析装置１０の動作時にデータを高速に移動可能な揮発性メモリとで構成される。
不揮発性メモリは、具体例としては、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、フラッシュメモリである。不揮発性メモリは、ＳＤ（Ｓｅｃｕｒｅ Ｄｉｇｉｔａｌ）メモリカード、ＣＦ（ＣｏｍｐａｃｔＦｌａｓｈ）、ＮＡＮＤフラッシュ、フレキシブルディスク、光ディスク、コンパクトディスク、ブルーレイ（登録商標）ディスク、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）といった可搬記憶媒体であってもよい。
揮発性メモリは、具体例としては、ＤＤＲ２−ＳＤＲＡＭ（Ｄｏｕｂｌｅ−Ｄａｔａ−Ｒａｔｅ２ Ｓｙｎｃｈｒｏｎｏｕｓ Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＤＤＲ３−ＳＤＲＡＭ（Ｄｏｕｂｌｅ−Ｄａｔａ−Ｒａｔｅ３ Ｓｙｎｃｈｒｏｎｏｕｓ Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）である。

通信インタフェース１３は、各ＤＢサーバ５０といった他の装置と通信するための装置である。通信インタフェース１３は、具体例としては、Ｅｔｈｅｒｎｅｔ（登録商標）、ＲＳ２３２Ｃ、ＵＳＢ、ＩＥＥＥ１３９４の端子である。

ログ解析装置１０は、機能構成要素として、登録部１４と、状態特定部１５と、表示部１６と、実行部１７とを備える。登録部１４と、状態特定部１５と、表示部１６と、実行部１７との各部の機能は、ソフトウェアにより実現される。
メモリ１２には、ログ解析装置１０の各部の機能を実現するプログラムが記憶されている。このプログラムは、プロセッサ１１により読み込まれ実行される。

図２では、プロセッサ１１は、１つだけ示されている。しかし、ログ解析装置１０は、プロセッサ１１を代替する複数のプロセッサを備えていてもよい。これら複数のプロセッサは、ログ解析装置１０の各部の機能を実現するプログラムの実行を分担する。それぞれのプロセッサは、プロセッサ１１と同じように、プロセッシングを行うＩＣである。

＊＊＊動作の説明＊＊＊
図３から図１０を参照して、実施の形態１に係るシステム１００の動作を説明する。
実施の形態１に係るシステム１００の動作は、実施の形態１に係るログ解析方法に相当する。また、実施の形態１に係るシステム１００の動作は、実施の形態１に係るログ解析プログラムの処理に相当する。
ここでは、実施の形態１に係るシステム１００の動作として、登録処理と、監視処理とについて説明する。

＊＊登録処理＊＊
図３を参照して、実施の形態１に係る登録処理を説明する。
登録処理は、取得するログデータと、実行するバッチ処理とを登録する処理である。

（ステップＳ１１：対象ログ登録処理）
ログ解析装置１０の登録部１４は、監視対象装置である各ＤＢサーバ５０から取得するログデータの指定をユーザ端末６０から受け付ける。そして、登録部１４は、指定されたログデータを、取得対象のログデータとしてメモリ１２に書き込み登録する。

具体例としては、登録部１４は、図４に示す監視対象ログ登録ウインドウをユーザ端末６０に表示させる。そして、登録部１４は、ユーザにより監視対象ログ登録ウインドウが操作され指定されたログデータを受け付ける。
図４では、「監視対象装置」の欄で、ログデータの取得元となるＤＢサーバ５０が選択される。ＤＢサーバ５０が選択されると、「監視対象ログデータ一覧」の欄に、選択されたＤＢサーバ５０から取得されることになっているログデータの一覧が表示される。つまり、過去に取得対象のログデータとしてメモリ１２に書き込まれたログデータの一覧が表示される。新たに取得するログデータを追加する場合には、「新規監視対象ログデータ登録」の欄に、取得するログデータを特定するパスが入力される。「新規監視対象ログデータ登録」の欄にパスが入力された状態で登録ボタンが押下されると、パスによって特定されるログデータが取得対象のログデータとして指定される。

（ステップＳ１２：処理登録処理）
ログ解析装置１０の登録部１４は、前兆状態を特定する条件である前兆条件と、前兆状態と特定された場合に実行するバッチ処理である解消処理と、障害状態を特定する条件である障害条件と、障害状態と特定された場合に実行するバッチ処理である復旧処理との指定をユーザ端末６０から受け付ける。そして、登録部１４は、指定された前兆条件及び解消処理と、障害条件及び復旧処理とをメモリ１２に書き込み登録する。
ここで、前兆状態とは、障害状態が発生する前兆の状態であり、システム１００は動作を継続可能な状態である。障害状態とは、システム１００が動作を継続不可能な状態である。

前兆条件及び障害条件は、複数のログデータの組合せによって定められる。複数のログデータは、システム１００を構成する複数のＤＢサーバ５０から取得されたログデータである。つまり、前兆条件及び障害条件は、各ＤＢサーバ５０から取得されたログデータの組合せによって定められる。
実施の形態１では、前兆条件及び障害条件は、ログデータと、メッセージと、基準台数とによって定められる。前兆条件及び障害条件は、指定されたメッセージを含む指定されたログデータが、指定された基準台数以上のＤＢサーバ５０から出力された場合に満たすと判定される。前兆条件を満たすと判定された場合に、前兆状態と特定され、障害条件を満たすと判定された場合に、障害状態と特定される。
なお、ログデータの組合せには、同一の内容のログデータが、指定された基準台数以上のＤＢサーバ５０から出力された場合も、複数の種類のログデータが、複数のＤＢサーバ５０から出力された場合も含まれる。

具体例としては、登録部１４は、図５に示す処置管理ウインドウをユーザ端末６０に表示させる。そして、登録部１４は、ユーザにより処置管理ウインドウが操作され指定された前兆条件及び解消処理と、障害条件及び復旧処理とを受け付ける。
図５では、「監視対象装置」の欄で、バッチ処理の実行対象となるＤＢサーバ５０が選択される。「監視対象ログデータ」の欄で、条件として指定するログデータが選択される。ここでは、ＤＢサーバ５０が指定されると、指定されたＤＢサーバ５０から取得されるログデータの一覧が表示され、表示されたログデータから条件に指定するログデータを選択するようになっている。「解消処理」の欄で、メッセージと基準台数とが入力される。同様に、「復旧処理」の欄で、メッセージと基準台数とが入力される。なお、ログデータが選択されると、「内容表示」の欄に、選択されたログデータの詳細な内容が時系列に表示されるため、表示された詳細な内容を参照して、メッセージを入力することが可能である。また、ログデータの詳細な内容はキーワード検索できるようになっている。キーワードが指定されない場合、全ての内容が表示される。
また、図５では、「自動実行」の欄で、前兆状態になった場合に、自動で解消処理を実行するか、又は、管理者に解消処理を実行するかを判断させるかが指定される。同様に、障害状態になった場合に、自動で復旧処理を実行するか、又は、管理者に復旧処理を実行するかを判断させるかが指定される。

その結果、図６に示すように、前兆状態について、対象とするログデータとメッセージと基準台数とを示す前兆条件が１つ以上登録され、各前兆条件について、その前兆条件を満たす場合に実行される解消処理と、自動実行の有無とが登録される。また、同様に、障害状態について、対象とするログデータとメッセージと基準台数とを示す障害条件が１つ以上登録され、各障害条件について、その障害条件を満たす場合に実行される復旧処理と、自動実行するか否かとが登録される。

＊＊監視処理＊＊
図７を参照して、実施の形態１に係る監視処理を説明する。
監視処理は、登録処理で登録された情報に基づき、ログ解析装置１０が各ＤＢサーバ５０を監視する処理である。
なお、システム１００では、ユーザ端末６０からウェブサーバ３０を介してＡＰＰサーバ４０にリクエストが送信され、ＡＰＰサーバ４０により各ＤＢサーバ５０のデータが更新されるというデータ更新処理が繰り返し実行されている。監視処理は、データ更新処理中に実行される。

（ステップＳ２１：ログ解析処理）
ログ解析装置１０の状態特定部１５は、監視対象装置である各ＤＢサーバ５０から、登録処理で登録された取得対象のログデータを取得する。そして、状態特定部１５は、取得されたログデータを解析して、前兆状態又は障害状態を特定する。
具体的には、状態特定部１５は、各前兆条件を対象条件として以下の処理を実行する。まず、状態特定部１５は、取得されたログデータから、対象条件として登録されたメッセージを検索する。状態特定部１５は、メッセージが検索されたログデータの取得元のＤＢサーバ５０の台数をカウントし、カウントされた台数が、対象条件として登録された基準台数より多い場合には対象条件を満たすので、前兆状態と特定する。
同様に、状態特定部１５は、各障害条件を対象条件として以下の処理を実行する。まず、状態特定部１５は、取得されたログデータから、対象条件として登録されたメッセージを検索する。状態特定部１５は、メッセージが検索されたログデータの取得元のＤＢサーバ５０の台数をカウントする。状態特定部１５は、カウントされた台数が、対象条件として登録された基準台数より多い場合には対象条件を満たすので、障害状態と特定する。

（ステップＳ２２：結果表示処理）
ログ解析装置１０の表示部１６は、ステップＳ２１で特定された結果を示すログ解析結果ウインドウをユーザ端末６０に表示する。
具体例としては、表示部１６は、図８に示すように、ステップＳ２１で特定された最新の結果と、過去の結果の履歴とを示すログ解析結果ウインドウを表示する。図９に示すように、各結果について、状態を示すマークとともに、状態についての説明が表示される。図９では、状態Ａ〜状態Ｄに区別して表示されることが示されている。状態Ａは、前兆条件として登録されたメッセージと、障害条件として登録されたメッセージとのどちらも検出されていない未検出状態である。状態Ｂは、前兆条件として登録されたメッセージが検出されたものの、前兆条件として登録された基準台数未満のＤＢサーバ５０から取得されたログデータのみから検出された確認状態である。状態Ｃは、前兆状態である。状態Ｄは、障害状態である。
この際、監視装置２０で検出された情報もユーザ端末６０に表示してもよい。

前兆状態と障害状態とのどちらでもない場合、処理がステップＳ２１に戻される。前兆状態の場合には処理がステップＳ２３に進められ、障害状態の場合には処理がステップＳ２４に進められる。

（ステップＳ２３：前兆処理）
ステップＳ２３１では、ログ解析装置１０の実行部１７は、監視装置２０に対して監視強化を指示する。すると、監視装置２０は、各ＤＢサーバ５０からの情報の取得間隔を短くする、情報の取得項目を増やすといった監視強化を行う。そして、監視装置２０で検出された情報がユーザ端末６０に表示される。

続いて、ステップＳ２１で満たされた前兆条件について、解消処理を自動実行しないと登録されている場合には処理がステップＳ２３２に進められ、解消処理を自動実行すると登録されている場合には処理がステップＳ２３３に進められる。

ステップＳ２３２では、ログ解析装置１０の表示部１６は、解消処理についての情報をユーザ端末６０に表示し、解消処理を実行するか否かを管理者に判断させる。例えば、図１０に示すように、解消処理の名称を示すポップアップウインドウを表示し、解消処理を実行するか否かを管理者に入力させる。
解消処理を実行すると判断された場合には処理がステップＳ２３３に進められ、解消処理を実行しないと判断された場合には処理がステップＳ２１に戻される。処理がステップＳ２１に戻されると、監視強化が終了される。

ステップＳ２３３では、ログ解析装置１０の実行部１７は、ステップＳ２１で満たされた前兆条件に対応する解消処理を実行する。そして、表示部１６は、解消処理の実行結果をユーザ端末６０に表示する。

（ステップＳ２４：障害処理）
ステップＳ２１で満たされた障害条件について、復旧処理を自動実行しないと登録されている場合には処理がステップＳ２４１に進められ、復旧処理を自動実行すると登録されている場合には処理がステップＳ２４２に進められる。

ステップＳ２４１では、ログ解析装置１０の表示部１６は、ステップＳ２３２の処理と同様に、復旧処理についての情報をユーザ端末６０に表示し、復旧処理を実行するか否かを管理者に判断させる。
復旧処理を実行すると判断された場合には処理がステップＳ２４２に進められ、復旧処理を実行しないと判断された場合には処理がステップＳ２１に戻される。

ステップＳ２４２では、ログ解析装置１０の実行部１７は、ステップＳ２１で満たされた障害条件に対応する復旧処理を実行する。そして、表示部１６は、復旧処理の実行結果をユーザ端末６０に表示する。

＊＊＊実施の形態１の効果＊＊＊
以上のように、実施の形態１に係るシステム１００では、複数のログデータの組合せから前兆状態を特定し、障害状態と区別して前兆状態表示する。これにより、システム１００の状態に応じた適切な対処をすることが可能になる。
特に、障害状態ではなく前兆状態であることに気づかせることが可能であるため、障害が発生する前に対処することができ、システム１００を継続動作させることができる。

また、実施の形態１に係るシステム１００では、１台のＤＢサーバ５０から取得されたログデータに基づき前兆状態を特定するのではなく、複数のＤＢサーバ５０から取得されたログデータに基づき前兆状態を特定する。これにより、前兆状態を適切に特定することができる。
特に、実施の形態１では、複数のＤＢサーバ５０は、冗長構成となっている。そのため、１台のＤＢサーバ５０のログデータだけでは、システム１００として障害状態に近い状態であると判定することは困難である。そのため、複数のＤＢサーバ５０から取得されたログデータに基づき前兆状態を特定することが有効である。

＊＊＊他の構成＊＊＊
＜変形例１＞
実施の形態１では、ＤＢサーバ５０のみを監視対象装置とした。しかし、変形例１として、ウェブサーバ３０、ＡＰＰサーバ４０、ウェブサーバ３０とＡＰＰサーバ４０とＤＢサーバ５０とを接続するためのネットワーク装置といった他の装置も監視対象装置としてもよい。

＜変形例２＞
実施の形態１では、障害条件についても、前兆条件と同様に、ログデータに基づき指定されるものとした。しかし、変形例２として、障害条件は、ログデータに限らず、監視装置２０によって取得される情報等を用いて指定されてもよい。また、障害条件は、ログデータと、監視装置２０によって取得される情報等との両方を用いて指定されてもよい。

＜変形例３＞
実施の形態１では、ログ解析装置１０の各部の機能がソフトウェアで実現された。変形例３として、ログ解析装置１０の各部の機能はハードウェアで実現されてもよい。この変形例３について、実施の形態１と異なる点を説明する。

図１１を参照して、変形例３に係るログ解析装置１０の構成を説明する。
各部の機能がハードウェアで実現される場合、ログ解析装置１０は、プロセッサ１１とメモリ１２とに代えて、処理回路１８を備える。処理回路１８は、ログ解析装置１０の各部の機能と、メモリ１２の機能とを実現する専用の電子回路である。

処理回路１８は、単一回路、複合回路、プログラム化したプロセッサ、並列プログラム化したプロセッサ、ロジックＩＣ、ＧＡ（Ｇａｔｅ Ａｒｒａｙ）、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）、ＦＰＧＡ（Ｆｉｅｌｄ−Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）が想定される。
各部の機能を１つの処理回路１８で実現してもよいし、各部の機能を複数の処理回路１８に分散させて実現してもよい。

＜変形例４＞
変形例４として、一部の機能がハードウェアで実現され、他の機能がソフトウェアで実現されてもよい。つまり、ログ解析装置１０の各部のうち、一部の機能がハードウェアで実現され、他の機能がソフトウェアで実現されてもよい。

プロセッサ１１とメモリ１２と処理回路１８とを、総称して「プロセッシングサーキットリー」という。つまり、各部の機能は、プロセッシングサーキットリーにより実現される。

実施の形態２．
実施の形態１では、前兆状態を特定することにより、システム１００が継続動作可能な状態を維持できるようにした。しかし、システム１００が動作できない障害状態になる場合も起こり得る。
実施の形態２では、ＤＢサーバ５０が障害状態になり、ＤＢサーバ５０のデータ更新ができない場合でもシステム１００のユーザへのサービス提供を継続する方法を説明する。実施の形態２では、実施の形態１と異なる部分を説明する。

実施の形態２では、システム１００として、ユーザ端末６０からリクエストが送信されてから、ある程度の時間が経ってからリスエストに基づきＤＢサーバ５０のデータが更新されてもよいシステムを想定する。
具体例としては、システム１００は、ユーザ端末６０から家電製品等の設定変更のリクエストを受け付け、家電製品等の設定変更を行うシステムである。例えば、システム１００は、ユーザ端末６０から冷房の起動時刻のリクエストを受け付け、起動時刻になったらエアコンを起動させるシステムである。

＊＊＊構成の説明＊＊＊
図１２を参照して、実施の形態２に係るＡＰＰサーバ４０の構成を説明する。
ＡＰＰサーバ４０は、プロセッサ４１と、メモリ４２と、通信インタフェース４３とのハードウェアを備える。プロセッサ４１は、システムバスを介して他のハードウェアと接続され、これら他のハードウェアを制御する。
プロセッサ４１とメモリ４２と通信インタフェース４３とは、ログ解析装置１０のプロセッサ１１とメモリ１２と通信インタフェース１３と同様である。

ＡＰＰサーバ４０は、機能構成要素として、リクエスト受付部４４と、ＤＢ更新部４５とを備える。リクエスト受付部４４と、ＤＢ更新部４５との各部の機能は、ソフトウェアにより実現される。
メモリ４２には、ＡＰＰサーバ４０の各部の機能を実現するプログラムが記憶されている。このプログラムは、プロセッサ４１により読み込まれ実行される。また、メモリ４２は、一時保管部４６の機能を実現する。

＊＊＊動作の説明＊＊＊
図１３を参照して、実施の形態２に係るシステム１００の動作を説明する。
実施の形態２に係るシステム１００の動作は、実施の形態２に係るサービス提供方法に相当する。また、実施の形態２に係るシステム１００の動作は、実施の形態２に係るサービス提供プログラムの処理に相当する。

（ステップＳ３１：リクエスト受付処理）
ＡＰＰサーバ４０のリクエスト受付部４４は、通信インタフェース４３を介して、ユーザ端末６０からリクエストを受け付ける。そして、リクエスト受付部４４は、受け付けたリクエストを一時保管部４６に書き込む。

（ステップＳ３２：更新判定処理）
ＤＢ更新部４５は、ＤＢサーバ５０が障害状態であるか否かを判定する。具体的には、ＤＢ更新部４５は、ログ解析装置１０にＤＢサーバ５０が障害状態であるか問い合わせることにより、ＤＢサーバ５０が障害状態であるか否かを判定する。具体的には、ＤＢ更新部４５は、ログ解析装置１０にＤＢサーバ５０の障害状態を問合せるメッセージを送信する。ログ解析装置１０は、ＡＰＰサーバ４０のログ解析装置１０からのメッセージを受信すると、指定されたＤＢサーバ５０が障害状態であるか否かを示すメッセージをＡＰＰサーバ４０に送信する。ＡＰＰサーバ４０のＤＢ更新部４５は、ログ解析装置１０からのメッセージを受信することで、ＤＢサーバ５０の障害状態を把握することができる。
ＤＢサーバ５０が障害状態である場合には処理がステップＳ３３に進められ、ＤＢサーバ５０が障害状態でない場合には処理がステップＳ３４に進められる。

（ステップＳ３３：復旧待機処理）
ＤＢ更新部４５は、ＤＢサーバ５０が復旧するまで待機する。具体的には、ＤＢ更新部４５は、ログ解析装置１０に定期的にＤＢサーバ５０の状態を問い合わせて、ＤＢサーバ５０が復旧したか否かを判定する。あるいは、ＤＢサーバ５０が復旧した場合に、ログ解析装置１０又はＤＢサーバ５０からＡＰＰサーバ４０に通知が送信され、通知があるまでＤＢ更新部４５は待機するとしてもよい。
ＤＢサーバ５０が復旧すると、処理がステップＳ３４に進められる。

（ステップＳ３４：ＤＢ更新処理）
ＤＢ更新部４５は、一時保管部４６に記憶されたリクエストを読み出す。そして、ＤＢ更新部４５は、読み出されたリクエストに応じて各ＤＢサーバ５０に記憶されたデータを更新する。

＊＊＊実施の形態２の効果＊＊＊
以上のように、実施の形態２に係るシステム１００では、ＤＢサーバ５０が障害状態の間、ＡＰＰサーバ４０がユーザ端末６０から送信されたリクエストを保管しておく。これにより、ユーザは、ＤＢサーバ５０が障害状態にあるか否かに関わらず、リクエストを送信しておくことができる。
上述したように、実施の形態２では、システム１００として、ユーザ端末６０からリクエストが送信されてから、ある程度の時間が経ってからリスエストに基づきＤＢサーバ５０のデータが更新されてもよいシステムを想定している。そのため、リクエストが送信されてから、ＤＢサーバ５０が復旧するまでにある程度時間がかかっても問題ない。

＊＊＊他の構成＊＊＊
＜変形例５＞
実施の形態２では、ＤＢサーバ５０が動作できない障害状態になった場合には、ＡＰＰサーバ４０がユーザ端末６０から送信されたリクエストを保管していた。しかし、変形例５として、ＤＢサーバ５０が障害状態になった場合に限らず、前兆状態を解消するための処理を実行している最中にＤＢサーバ５０が動作できない場合にも、ＡＰＰサーバ４０がユーザ端末６０から送信されたリクエストを保管しても良い。
この場合、ログ解析装置１０は、ＡＰＰサーバ４０のＤＢ更新部４５からの問い合わせメッセージを受信した場合に、前兆状態を解消するための処理中である旨を示すメッセージをＡＰＰサーバ４０に送信する。これにより、ＡＰＰサーバ４０は、ＤＢサーバ５０が前兆状態を解消する処理を行っていることを把握することができる。

＜変形例６＞
変形例３に係るログ解析装置１０のように、ＡＰＰサーバ４０の各部の機能はハードウェアで実現されてもよい。また、変形例４に係るログ解析装置１０のように、ＡＰＰサーバ４０の各部のうち、一部の機能がハードウェアで実現され、他の機能がソフトウェアで実現されてもよい。

１００ システム、１０ ログ解析装置、１１ プロセッサ、１２ メモリ、１３ 通信インタフェース、１４ 登録部、１５ 状態特定部、１６ 表示部、１７ 実行部、２０ 監視装置、３０ ウェブサーバ、４０ ＡＰＰサーバ、４１ プロセッサ、４２ メモリ、４３ 通信インタフェース、４４ リクエスト受付部、４５ ＤＢ更新部、４６ 一時保管部、５０ ＤＢサーバ、６０ ユーザ端末。

Claims (10)

1. 複数のログデータの組合せから、システムが動作を継続不可能な障害状態が発生する前兆である前兆状態を特定する状態特定部と、
   前記状態特定部によって特定された前記前兆状態を、前記障害状態と区別して表示する表示部と
   を備えるログ解析装置。
2. 前記複数のログデータは、前記システムを構成する複数の監視対象装置から取得された請求項１に記載のログ解析装置。
3. 前記複数の監視対象装置は、冗長構成とするために設けられた同一機能を有する装置である
   請求項２に記載のログ解析装置。
4. 前記状態特定部は、基準台数以上の監視対象装置から取得されたログデータが指定内容を示す場合に、前記前兆状態であると特定する
   請求項３に記載のログ解析装置。
5. 前記表示部は、さらに、前記基準台数未満の監視対象装置から取得されたログデータが前記指定内容を示す確認状態を、前記前兆状態及び前記障害状態と区別して表示する
   請求項４に記載のログ解析装置。
6. 前記ログ解析装置は、さらに、
   前記前兆状態と特定された場合に、前記前兆状態を解消するための解消処理を実行する実行部
   を備える請求項１から５のいずれか１項に記載のログ解析装置。
7. 前記前兆状態には、複数の状態があり、
   前記実行部は、前記前兆状態がどの状態かに応じて、管理者により実行判断がされた上で前記解消処理を実行するか、実行判断がされることなく前記解消処理を実行するかを切り替える
   請求項６に記載のログ解析装置。
8. 前記状態特定部は、監視対象装置に記憶されたデータを更新する装置に対して、前記監視対象装置が前記障害状態である旨を通知する
   請求項１から７のいずれか１項に記載のログ解析装置。
9. コンピュータが、複数のログデータの組合せから、システムが動作を継続不可能な障害状態が発生する前兆である前兆状態を特定し、
   コンピュータが、特定された前記前兆状態を、前記障害状態と区別して表示するログ解析方法。
10. 複数のログデータの組合せから、システムが動作を継続不可能な障害状態が発生する前兆である前兆状態を特定する状態特定処理と、
    前記状態特定処理によって特定された前記前兆状態を、前記障害状態と区別して表示する表示処理と
    をコンピュータに実行させるログ解析プログラム。

Images