JP2018055481A - ログ監視装置、ログ監視方法及びログ監視プログラム - Google Patents

Abstract

【課題】複数の利用者がソフトウエアを利用するシステムにおいてスケーリング可能な形態でソフトウエアの実行ログの監視を実現する装置、方法及びプログラムを提供する。
【解決手段】複数のユーザのうちいずれかのユーザの識別情報と、ユーザに対応付けられたソフトウエアの実行ログデータとを受け付け、実行ログデータの検出条件をユーザの識別情報に対応付けて記憶する記憶部から、受け付けた識別情報に対応付けられた検出条件を取得し、受け付けた実行ログデータが、取得した検出条件を満たすか否かについて判定処理を行い、判定処理の結果を出力する。
【選択図】図４

Description

本発明は、ログの監視技術に関する。

クラウドサービスの普及が進み、複数の利用者（例えば企業など）によりリソースが共有されるシステムが構築されるようになっている。このようなシステムはマルチテナントシステムと呼ばれる。例えば、或る文献は、サービス提供装置のリソースが複数の利用者に共有されるマルチテナントシステムを開示する。

そして、マルチテナントシステムにおいては、各利用者のアプリケーション層やミドルウエア層に共通で必要な「ログ管理」や「異常検知」などの機能は、ＰａａＳ（Platform as a Service）として提供されるようになっている。これらの機能を提供するためのソフトウエアとして、例えば、ＯＳＳ（Open-Source Software）であるＺａｂｂｉｘが知られている。

但し、このソフトウエアは、例えば同一のＤＢ（Database）を共有出来ないなど、スケールアウトしない条件下で上記機能を提供することを前提として設計されており、利用者が増えた場合に負荷を分散できない。そのため、シングルテナント方式で利用者ごとにＶＭ（Virtual Machine）の割り当てを行うことになり、上記機能を提供するためのコストが高くなる場合がある。

特開２０１２−１１３３８０号公報

本発明の目的は、１つの側面では、複数の利用者がソフトウエアを利用するシステムにおいてスケーリング可能な形態でソフトウエアの実行ログの監視を実現するための技術を提供することである。

本発明に係るログ監視方法は、複数のユーザのうちいずれかのユーザの識別情報と、該ユーザに対応付けられたソフトウエアの実行ログデータとを受け付け、実行ログデータの検出条件をユーザの識別情報に対応付けて記憶する記憶部から、受け付けた識別情報に対応付けられた検出条件を取得し、受け付けた実行ログデータが、取得した検出条件を満たすか否かについて判定処理を行い、判定処理の結果を出力する処理を含む。

１つの側面では、複数の利用者がソフトウエアを利用するシステムにおいてスケーリング可能な形態でソフトウエアの実行ログの監視を実現できるようになる。

図１は、本実施の形態のマルチテナントシステムの概要を示す図である。 図２は、情報処理装置のハードウエア構成図である。 図３は、情報処理装置の機能ブロック図である。 図４は、監視装置の機能ブロック図である。 図５は、管理装置の機能ブロック図である。 図６は、情報処理装置が実行する処理の処理フローを示す図である。 図７は、実行ログの一例を示す図である。 図８は、テナントテーブルの一例を示す図である。 図９は、ＧＵＩＤが付加された実行ログの一例を示す図である。 図１０は、監視装置が実行する処理の処理フローを示す図である。 図１１は、監視ＶＭテーブルの一例を示す図である。 図１２は、情報処理装置のロードバランサが実行する処理の処理フローを示す図である。 図１３は、監視装置が実行する処理の処理フローを示す図である。 図１４は、トリガ定義テーブルの一例を示す図である。 図１５は、監視定義テーブルの一例を示す図である。 図１６は、情報処理装置が実行する処理の処理フローを示す図である。 図１７は、管理装置が実行する処理の処理フローを示す図である。 図１８は、監視装置が実行する処理の処理フローを示す図である。 図１９は、監視装置が実行する処理の処理フローを示す図である。 図２０は、管理装置が実行する処理の処理フローを示す図である。 図２１は、監視装置が実行する処理の処理フローを示す図である。 図２２は、コンピュータの機能ブロック図である。

図１は、本実施の形態のマルチテナントシステムの概要を示す図である。クラウドサービスを提供する情報処理装置１は、例えばインターネットであるネットワーク７に接続される。利用者端末９ａ乃至９ｃは、ネットワーク７を介してリクエストを情報処理装置１に送信し、情報処理装置１が提供するクラウドサービスを利用する。１又は複数の監視装置３は、情報処理装置１において発生する異常を検出し、検出した異常を利用者に通知する。管理装置５は、１又は複数の監視装置３を管理する。なお、図１においては利用者端末の数は３であるが、数に限定は無い。

図２は、情報処理装置１のハードウエア構成図である。情報処理装置１は、１又は複数のＣＰＵ（Central Processing Unit）１１と、例えばＤＲＡＭ（Dynamic Random Access Memory）である１又は複数のメモリ１２と、１又は複数のＨＤＤ（Hard Disk Drive）１３と、１又は複数のＮＩＣ（Network Interface Card）１４とを有する。これらのハードウエアコンポーネントは、バスによって互いに接続される。

本実施の形態の処理を実行するためのプログラムは、ＨＤＤ１３に格納されており、メモリ１２にロードされてＣＰＵ１１により実行されることで、図３に示すような各種機能を実現する。図３は、情報処理装置１の機能ブロック図である。情報処理装置１は、ロードバランサ１０１と、制御部１０２と、データ格納部１０３と、ログ処理部１０４と、アプリケーション実行基盤１０５とを含む。アプリケーション実行基盤１０５上では、アプリケーション１０５ａ乃至１０５ｄが実行される。利用者は、利用者端末を操作することで、ＰａａＳとして提供されるアプリケーション実行基盤１０５上のアプリケーションを利用することができる。図３においては、利用者Ａ用のアプリケーションとしてアプリケーション１０５ａ及び１０５ｂが実行されており、利用者Ｂ用のアプリケーションとしてアプリケーション１０５ｃが実行されており、利用者Ｃ用のアプリケーションとしてアプリケーション１０５ｄが実行されている。

アプリケーション１０５ａ乃至１０５ｄは、実行に関する情報を含む実行ログを出力する。ログ処理部１０４は、アプリケーション１０５ａ乃至１０５ｄが出力した実行ログを収集し、ロードバランサ１０１に転送する。ロードバランサ１０１は、１又は複数の監視装置３において実行されているＶＭ３０の負荷が平準化されるように、ログ処理部１０４から受け取った実行ログを割り振る。実行ログには、実行ログを出力したアプリケーションの利用者の識別情報（ＧＵＩＤ（Globally Unique Identifier））が付される。制御部１０２は、異常検出の条件のデータを含む定義データが登録、変更又は削除される際にアクセスされるエンドポイントであり、利用者端末から受信した定義データを管理装置５に転送する。定義データには、定義データの更新を要求する利用者のＧＵＩＤが付される。なお、制御部１０２は、トークンに基づき利用者端末の認証を行い、許可された利用者端末のみが定義データの登録等を行えるようにする。データ格納部１０３には、テナントテーブルと、監視ＶＭテーブルとが格納される。

なお、監視装置３のハードウエア構成は情報処理装置１のハードウエア構成と同じであるので、説明を省略する。

図４は、監視装置３の機能ブロック図である。監視装置３はＶＭ３０を実行しており、ＶＭ３０は、ログ転送部３０１と、監視部３０２と、ログ格納部３０３と、定義データ格納部３０４とを含む。なお、ここではＶＭ３０の数は１であるが、２以上のＶＭ３０が各監視装置３において実行されてもよい。

ログ転送部３０１は、情報処理装置１のロードバランサ１０１から受信した実行ログを監視部３０２に転送する。ログ転送部３０１は、実行ログを一時的にバッファに格納し、監視部３０２の状態が異常状態（例えば、監視部３０２の動作が停止している状態）ではない場合には実行ログを監視部３０２に転送する。監視部３０２の状態が異常状態である場合には実行ログをロードバランサ１０１に返送する。監視部３０２は、ログ転送部３０１から受け取った実行ログと定義データ格納部３０４に格納されている定義データとに基づき、アプリケーションの異常を検出する。ログ格納部３０３には、監視部３０２による処理が完了した後の実行ログが格納される。定義データ格納部３０４には、アプリケーションを利用する全利用者の定義データが格納される。

図５は、管理装置５の機能ブロック図である。管理装置５はＶＭ５０を実行しており、ＶＭ５０は、定義管理部５０１と、定義データ格納部５０２とを含む。なお、ＶＭ５０は冗長化されており、本実施の形態に関係する処理はプライマリのＶＭ５０に実行される。冗長化についてはよく知られているので、ここではこれ以上説明しない。

定義管理部５０１は、定義データ格納部５０２に格納されている定義データに基づき、各監視装置３における定義データ格納部３０４に格納されている定義データを更新する。定義データ格納部５０２には、制御部１０２から受信した定義データが格納される。

次に、図６乃至図２１を用いて、本実施の形態のシステムにおいて実行される処理について説明する。

まず、図６乃至図９を用いて、アプリケーション１０５ａ乃至１０５ｄから出力された実行ログに関して情報処理装置１が実行する処理について説明する。

情報処理装置１のログ処理部１０４は、アプリケーション１０５ａ乃至１０５ｄのうちいずれかのアプリケーションから出力された実行ログを取得する（図６：ステップＳ１）。

図７は、実行ログの一例を示す図である。図７（ａ）及び図７（ｂ）のいずれも、実行ログの一例を示しており、実行ログには、日時の情報と、アプリケーションの実行状態に関する情報とが含まれる。

ログ処理部１０４は、実行ログを出力したアプリケーションの利用者のＧＵＩＤを、データ格納部１０３に格納されているテナントテーブルから特定する。そして、ログ処理部１０４は、特定したＧＵＩＤを受信した実行ログの先頭に付加する（ステップＳ３）。

図８は、テナントテーブルの一例を示す図である。図８の例では、アプリケーションＩＤと、アプリケーション名と、アプリケーションの利用者のＧＵＩＤと、利用者名とが格納される。

図９は、ＧＵＩＤが付加された実行ログの一例を示す図である。図９（ａ）は図７（ａ）に示した実行ログにＧＵＩＤが付加された場合の実行ログを示しており、図９（ｂ）は図７（ｂ）に示した実行ログにＧＵＩＤが付加された場合の実行ログを示している。

ログ処理部１０４は、ＧＵＩＤが付加された実行ログをロードバランサ１０１に出力する。そして、ロードバランサ１０１は、ロードバランサ１０１の配下のＶＭ３０（すなわち、ロードバランサ１０１から実行ログを割り振られるＶＭ３０）から１のＶＭ３０を、ＶＭ３０の負荷に基づき特定する。上で述べたように、ＶＭ３０の負荷が平準化されるように割り振り先のＶＭ３０が特定される。そして、ロードバランサ１０１は、ステップＳ３においてＧＵＩＤが付加された実行ログを、特定されたＶＭ３０に転送する（ステップＳ５）。そして処理は終了する。

以上のような処理を実行すれば、実行ログを出力したアプリケーションを利用する利用者を特定できるようになる。

図１０乃至図１５を用いて、アプリケーション１０５ａ乃至１０５ｄから出力された実行ログに関して監視装置３が実行する処理について説明する。

監視装置３のログ転送部３０１は、ロードバランサ１０１から実行ログを受信する（ステップＳ１１）。

ログ転送部３０１は、監視部３０２の状態が正常状態であるか判定する（ステップＳ１３）。

監視部３０２の状態が正常状態である場合（ステップＳ１３：Ｙｅｓルート）、ログ転送部３０１は以下の処理を実行する。具体的には、ログ転送部３０１は、受信した実行ログを監視部３０２に出力する。また、ログ転送部３０１は、受信した実行ログのコピーをログ転送部３０１が管理するバッファに追加し、バッファに格納されている実行ログのうち最も古い実行ログをバッファから削除する（ステップＳ１５）。バッファには、所定数又は所定量の実行ログが格納される。そして処理は端子Ａを介して図１３のステップＳ２３に移行する。

一方、監視部３０２の状態が正常状態ではない場合（ステップＳ１３：Ｎｏルート）、ログ転送部３０１は以下の処理を実行する。具体的には、ログ転送部３０１は、ロードバランサ１０１からの実行ログの受信を停止する。例えば、ロードバランサ１０１に対して実行ログの割り振りの停止要求がログ転送部３０１から送信される。そして、ログ転送部３０１は、データ格納部１０３に格納されている監視ＶＭテーブルのレコードのうちステップＳ１１において実行ログを受信したＶＭ３０のレコードに対して、状態を「ｄｅｒｅｇｉｓｔｅｒｅｄ」に設定する（ステップＳ１７）。

図１１は、監視ＶＭテーブルの一例を示す図である。図１１の例では、ＶＭインスタンスＩＤと、ＶＭ名と、状態を示す情報と、定義データを更新中であるか否かを示す情報とが格納される。なお、状態が「ｂｕｉｌｄ」である場合、ＶＭ３０を配備中である。状態が「ａｃｔｉｖｅ」である場合、ＶＭ３０の配備が完了している。状態が「ｒｅｇｉｓｔｅｒｅｄ」である場合、ロードバランサ１０１に接続されており実行ログを受信できる状態にある。状態が「ｄｅｒｅｇｉｓｔｅｒｅｄ」である場合、ロードバランサ１０１に接続されておらず実行ログを受信できない状態にある。状態が「ｅｍｐｔｙ」である場合、滞留している実行ログが無い。なお、ステップＳ１７においては、監視装置３から情報処理装置１に対して、監視ＶＭテーブルの内容を変更するためのコマンドが送信され、コマンドに応じて情報処理装置１が監視ＶＭテーブルの内容を変更する。

ログ転送部３０１は、ステップＳ１１において受信した実行ログを、ロードバランサ１０１に転送する（ステップＳ１９）。ステップＳ１１において実行ログを受信したＶＭ３０においては実行ログを処理できないため、ロードバランサ１０１に実行ログが返送される。

ログ転送部３０１は、バッファに格納されている各実行ログに「転送済み」であることを示す情報を付加し、当該実行ログをロードバランサ１０１に転送する（ステップＳ２１）。バッファに格納されている実行ログは、既に監視部３０２に出力された実行ログであるが、監視部３０２の状態が異常状態であるため適切に処理がなされていない可能性が有るため、ロードバランサ１０１に返送される。そして処理は端子Ｂを介して図１３の説明に移行し終了する。

ここで、図１２を用いて、返送された実行ログを受信したロードバランサ１０１が実行する処理について説明する。

ロードバランサ１０１は、ステップＳ１９において転送された実行ログを、実行ログを割り振ったＶＭ３０から受信する（図１２：ステップＳ４１）。

ロードバランサ１０１は、配下のＶＭ３０から１のＶＭ３０を負荷に基づき特定し、特定したＶＭ３０にステップＳ４１において受信した実行ログを転送する（ステップＳ４３）。なお、ステップＳ１７の処理が実行されているため、実行ログを返送したＶＭ３０は特定されない。

ロードバランサ１０１は、「転送済み」を示す情報が付加された実行ログを、実行ログを割り振ったＶＭ３０から受信する（ステップＳ４５）。

ロードバランサ１０１は、配下のＶＭ３０から１又は複数のＶＭ３０を負荷に基づき特定し、特定した１又は複数のＶＭ３０にステップＳ４５において受信した実行ログを転送する（ステップＳ４７）。なお、ステップＳ１７の処理が実行されているため、実行ログを返送したＶＭ３０は特定されない。そして処理は終了する。

以上のようにすれば、一部の実行ログについて監視が行われなくなることを防げるようになる。

図１３の説明に移行し、ログ転送部３０１から実行ログを受け取った監視部３０２は、実行ログに付加されたＧＵＩＤに対応する監視方法を、定義データ格納部３０４に格納されているトリガ定義テーブルから特定する。また、監視部３０２は、実行ログに付加されたＧＵＩＤに対応する検出条件を、定義データ格納部３０４に格納されている監視定義テーブルから特定する（図１３：ステップＳ２３）。

図１４は、トリガ定義テーブルの一例を示す図である。図１４の例では、トリガＩＤと、監視方法を示す情報と、ＧＵＩＤと、定義ＩＤと、検出条件が満たされた場合に実行するアクションを示す情報とが格納される。なお、以下の説明ではアクションとしてメール通知が行われるが、図１４に示すように、アプリケーションの再起動等を実行してもよい。

図１５は、監視定義テーブルの一例を示す図である。図１５の例では、定義ＩＤと、定義名と、ＧＵＩＤと、検出条件と、メールによって通知されるメッセージとが格納される。本実施の形態においては、「＾［ＧＵＩＤ］＿．＊［利用者が定義した任意の文字列］．＊＄」の形式で検出条件が予め利用者により作成される。但し、その他の形式であってもよい。

監視部３０２は、ステップＳ２３において特定された監視方法に従い、ステップＳ２３において特定された検出条件が満たされるか判定する（ステップＳ２５）。ステップＳ２３において複数の検出条件が特定された場合には、監視部３０２は複数の検出条件の各々が満たされるか判定する。

検出条件が満たされない場合（ステップＳ２７：Ｎｏルート）、監視部３０２は、ログ格納部３０３に実行ログを格納する（ステップＳ２９）。そして処理は終了する。

検出条件が満たされる場合（ステップＳ２７：Ｙｅｓルート）、監視部３０２は、監視定義テーブルに格納されているデータに基づき、利用者に送信するメッセージを生成する（ステップＳ３１）。

監視部３０２は、「転送済み」であることを示す情報が、ログ転送部３０１から受け取った実行ログに付加されているか判定する（ステップＳ３３）。

「転送済み」であることを示す情報が実行ログに付加されていない場合（ステップＳ３３：Ｎｏルート）、ステップＳ３７の処理に移行する。一方、「転送済み」であることを示す情報が実行ログに付加されている場合（ステップＳ３３：Ｙｅｓルート）、監視部３０２は、以下の処理を実行する。具体的には、監視部３０２は、重複の通知であることを示唆するデータを、ステップＳ３１において生成したメッセージに追加する（ステップＳ３５）。「転送済み」であることを示す情報が付加されている場合、既に他の監視部３０２によって通知が行われている可能性があるため、ステップＳ３５の処理が実行される。

監視部３０２は、生成したメッセージを含むメールを、実行ログを出力したアプリケーションを利用する利用者の利用者端末に送信する（ステップＳ３７）。そして処理は終了する。なお、メールではなく、その他の出力手段（例えばプリンタ）を用いて利用者に通知をしてもよい。また、マルチテナントシステムの管理者に対して通知を行ってもよい。

以上のように、定義データ及び実行ログの双方にＧＵＩＤが付されるので、アプリケーションに異常が発生したか否かを利用者ごとに判定できるようになる。各ＶＭ３０は全利用者について監視を実行できるので、利用者ごとにＶＭを用意する場合と比較してコストを削減することができるようになる。

図１６を用いて、定義データの更新に関して情報処理装置１が実行する処理について説明する。

情報処理装置１の制御部１０２は、定義データの更新指示を利用者端末９ａ乃至９ｃのうちいずれかの利用者端末から受信する（図１６：ステップＳ５１）。更新指示は、例えば、更新後の検出条件についての情報を含む。

制御部１０２は、更新指示を送信した利用者端末の利用者名に対応するＧＵＩＤを、データ格納部１０３に格納されているテナントテーブルから特定する（ステップＳ５３）。

制御部１０２は、ステップＳ５３において特定したＧＵＩＤが先頭に付加された、正規表現の検出条件を、ステップＳ５１において受信した更新指示に基づき生成する（ステップＳ５５）。

制御部１０２は、ステップＳ５５において生成された検出条件を含む更新後の定義データを、管理装置５に送信する（ステップＳ５７）。

制御部１０２は、データ格納部１０３に格納されている監視ＶＭテーブルにおける全レコードについて、「定義更新中」カラムに「Ｔｒｕｅ」を設定する（ステップＳ５９）。そして処理は終了する。

以上のような処理を実行すれば、ＧＵＩＤが付加された検出条件を管理装置５が管理できるようになる。

図１７乃至図２１を用いて、定義データの更新に関して管理装置５が実行する処理及び監視装置３が実行する処理について説明する。

管理装置５における定義管理部５０１は、監視ＶＭテーブルにおける全レコードについて、「定義更新中」カラムに「Ｔｒｕｅ」が設定されたことを検出する（図１７：ステップＳ６１）。例えば、監視ＶＭテーブルの内容の送信要求を所定時間ごとに定義管理部５０１が情報処理装置１に対して送信することで、「定義更新中」カラムに「Ｔｒｕｅ」が設定されたことが確認される。

定義管理部５０１は、監視ＶＭテーブルに登録されている全ＶＭ３０に対して、監視部３０２に対する実行ログの転送の停止要求を送信する（ステップＳ６３）。停止要求を受信したＶＭ３０が実行する処理は、後で説明される。

定義管理部５０１は、監視ＶＭテーブルに登録されているＶＭ３０のうち状態が「ｒｅｇｉｓｔｅｒｅｄ」又は「ｄｅｒｅｇｉｓｔｅｒｅｄ」であるＶＭ３０に対して、更新後の定義データを含む更新要求を送信する（ステップＳ６５）。なお、更新後の定義データは情報処理装置１から受信され、定義データ格納部５０２に格納されている。そして処理は終了する。なお、状態が「ｄｅｒｅｇｉｓｔｅｒｅｄ」であるＶＭ３０の定義データも更新されるので、ロードバランサ１０１からの実行ログの転送が既に行われていないＶＭ３０のバッファに残存している実行ログに対しても、更新後の定義データを用いた処理が行われるようになる。

図１８を用いて、停止要求を受信した監視装置３が実行する処理を説明する。

監視装置３におけるＶＭ３０のログ転送部３０１は、ステップＳ６３において管理装置５が送信した停止要求を受信する（図１８：ステップＳ７１）。

ログ転送部３０１は、実行ログを監視部３０２に転送することを停止する（ステップＳ７３）。以降、ログ転送部３０１は、転送を再開するまではロードバランサ１０１から受信した実行ログをバッファに格納する。そして処理は終了する。

以上のような処理を実行すれば、転送が再開するまでは監視部３０２による監視は行われないので、更新前の定義データで実行ログに対して処理が行われることが無い。更新前の定義データを用いた監視によって誤った通知或いは検出もれが発生することを抑止することができる。

図１９を用いて、更新要求を受信した監視装置３が実行する処理を説明する。

監視装置３におけるＶＭ３０のログ転送部３０１は、ステップＳ６５において管理装置５が送信した更新要求を受信する（図１９：ステップＳ８１）。

ログ転送部３０１は、更新要求に含まれる更新後の定義データで、定義データ格納部３０４に格納されている定義データを更新する（ステップＳ８３）。

ログ転送部３０１は、バッファに格納されている実行ログを監視部３０２に転送する。そして、監視部３０２は、ログ転送部３０１から受け取った実行ログに対して、定義データ格納部３０４に格納されている定義データを用いて、検出条件が満たされるか否かの判定を実行する（ステップＳ８５）。これにより、バッファに格納されている実行ログに対しても更新後の定義データで処理が行われるようになる。

図２０を用いて、定義データの更新状況を管理装置５が確認する処理について説明する。

管理装置５における定義管理部５０１は、「定義更新中」カラムに「Ｔｒｕｅ」が設定されている全ＶＭ３０の定義データが更新されたか判定する（図２０：ステップＳ９１）。ステップＳ９１においては、定義データ格納部５０２に格納されている定義データと、各ＶＭ３０の定義データ格納部３０４に格納されている定義データとが一致するか否かに基づき判定が行われる。なお、各ＶＭ３０の定義データは、定義データ格納部３０４の内容の送信要求を所定時間ごとに定義管理部５０１が各監視装置３に対して送信することで取得される。

定義管理部５０１は、定義データが更新されたＶＭ３０が有るか判定する（ステップＳ９３）。定義データが更新されたＶＭが無い場合（ステップＳ９３：Ｎｏルート）、ステップＳ９１の処理に戻る。

一方、定義データが更新されたＶＭが有る場合（ステップＳ９３：Ｙｅｓルート）、定義管理部５０１は、以下の処理を実行する。具体的には、定義管理部５０１は、定義データが更新されたＶＭ３０に対して、監視部３０２に対する実行ログの転送の再開要求を送信する（ステップＳ９５）。

定義管理部５０１は、定義データが更新されたＶＭ３０について、監視ＶＭテーブルにおける「定義更新中」カラムに「Ｆａｌｓｅ」を設定する（ステップＳ９７）。ステップＳ９７においては、監視ＶＭテーブルの更新要求を定義管理部５０１が情報処理装置１に対して送信し、更新要求に応じて情報処理装置１が監視ＶＭテーブルを更新する。

定義管理部５０１は、「定義更新中」カラムに「Ｔｒｕｅ」が設定されているＶＭ３０のレコードが監視ＶＭテーブルに有るか判定する（ステップＳ９９）。

「定義更新中」カラムに「Ｔｒｕｅ」が設定されているＶＭ３０のレコードが監視ＶＭテーブルに有る場合（ステップＳ９９：Ｙｅｓルート）、処理はステップＳ９１に戻る。一方、「定義更新中」カラムに「Ｔｒｕｅ」が設定されているＶＭ３０のレコードが監視ＶＭテーブルに無い場合（ステップＳ９９：Ｎｏルート）、処理は終了する。

以上のような処理を実行すれば、定義データが更新された場合にかぎり監視部３０２に対する実行ログの転送が再開されるようになる。

図２１を用いて、再開要求を受信した監視装置３が実行する処理を説明する。

監視装置３におけるＶＭ３０のログ転送部３０１は、ステップＳ９５において管理装置５が送信した再開要求を受信する（図２１：ステップＳ１０１）。

ログ転送部３０１は、実行ログを監視部３０２に転送することを再開する（ステップＳ１０３）。そして処理は終了する。

以上のような処理を実行すれば、ロードバランサ１０１から受信した新たな実行ログに対して、更新後の定義データを用いて、検出条件が満たされるか否かについての判定が実行されるようになる。

以上本発明の一実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、上で説明した情報処理装置１、監視装置３及び管理装置５の機能ブロック構成は実際のプログラムモジュール構成に一致しない場合もある。

また、上で説明した各テーブルの構成は一例であって、上記のような構成でなければならないわけではない。さらに、処理フローにおいても、処理結果が変わらなければ処理の順番を入れ替えることも可能である。さらに、並列に実行させるようにしても良い。

また、ＧＵＩＤは、実行ログの末尾に付加されてもよい。

また、情報処理装置１の台数は２以上であってもよい。

なお、上で述べた管理装置５は、コンピュータ装置であって、図２２に示すように、メモリ２５０１とＣＰＵ２５０３とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。ＣＰＵ２５０３は、アプリケーション・プログラムの処理内容に応じて表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、所定の動作を行わせる。また、処理途中のデータについては、主としてメモリ２５０１に格納されるが、ＨＤＤ２５０５に格納されるようにしてもよい。本発明の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及びアプリケーション・プログラムなどのプログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

以上述べた本発明の実施の形態をまとめると、以下のようになる。

本実施の形態に係るログ監視方法は、（Ａ）複数のユーザのうちいずれかのユーザの識別情報と、該ユーザに対応付けられたソフトウエアの実行ログデータとを受け付け、（Ｂ）実行ログデータの検出条件をユーザの識別情報に対応付けて記憶する記憶部から、受け付けた識別情報に対応付けられた検出条件を取得し、（Ｃ）受け付けた実行ログデータが、取得した検出条件を満たすか否かについて判定処理を行い、（Ｄ）判定処理の結果を出力する処理を含む。

複数のユーザがソフトウエアを利用するシステムにおいて、スケーリング可能な形態でソフトウエアの実行ログの監視を実現することができるようになる。

また、本ログ監視方法は、（Ｅ）判定処理についてのプロセスの状態が異常状態である場合、受け付けた実行ログデータを、判定処理を実行する前に、受け付けた識別情報と実行ログデータの送信元であるロードバランサに返送する処理をさらに含んでもよい。

ロードバランサから別のプロセスに対して割り振りが行われるようになるので、正常状態のプロセスに判定処理を実行させることができるようになる。

また、本ログ監視方法は、（Ｆ）記憶部に記憶された検出条件の更新要求を受け付けた場合、該検出条件の更新が完了するまで、判定処理の実行を停止する処理をさらに含んでもよい。

更新前の検出条件を用いて判定処理が行われることを防げるようになる。

また、本ログ監視方法は、（Ｇ）ユーザの識別情報と該ユーザに対応付けられたソフトウエアの実行ログデータとの受け付けを停止した後、記憶部に記憶された検出条件の更新要求を受け付けた場合、該検出条件を更新し、（Ｈ）受け付けを停止する前に受け付けた実行ログデータであって且つ判定処理が実行されていない実行ログデータに対して、更新後の検出条件に基づき判定処理を実行する処理をさらに含んでもよい。

更新前の検出条件を用いて判定処理が行われることを防げるようになる。

また、本ログ監視方法は、（Ｉ）判定処理についてのプロセスの状態が異常状態である場合、直近の所定量の実行ログデータ及びユーザの識別情報と、直近の所定量の実行ログデータ及びユーザの識別情報を判定処理についてのプロセスに出力済みであることを示す情報とを、ロードバランサに返送する処理をさらに含んでもよい。

判定処理が実行されていない可能性がある実行ログに対して、別のプロセスによる判定処理を実行できるようになる。

また、ユーザの識別情報と該ユーザに対応付けられたソフトウエアの実行ログデータとを受け付ける処理において、（ａ１）直近の所定量の実行ログデータ及びユーザの識別情報を判定処理についてのプロセスに出力済みであることを示す情報をさらに受け付け、判定処理の結果を出力する処理において、（ｄ１）判定処理の結果を既に出力したことを示唆する情報をさらに出力してもよい。

判定処理の結果が重複して出力されたことを認識できるようになる。

なお、上記方法による処理をプロセッサに行わせるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。尚、中間的な処理結果はメインメモリ等の記憶装置に一時保管される。

以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。

（付記１）
コンピュータに、
複数のユーザのうちいずれかのユーザの識別情報と、該ユーザに対応付けられたソフトウエアの実行ログデータとを受け付け、
実行ログデータの検出条件をユーザの識別情報に対応付けて記憶する記憶部から、受け付けた前記識別情報に対応付けられた検出条件を取得し、
受け付けた前記実行ログデータが、取得した前記検出条件を満たすか否かについて判定処理を行い、
前記判定処理の結果を出力する、
処理を実行させるログ監視プログラム。

（付記２）
前記コンピュータに、
前記判定処理についてのプロセスの状態が異常状態である場合、受け付けた前記実行ログデータを、前記判定処理を実行する前に、受け付けた前記識別情報と前記実行ログデータの送信元であるロードバランサに返送する、
処理をさらに実行させる付記１記載のログ監視プログラム。

（付記３）
前記コンピュータに、
前記記憶部に記憶された検出条件の更新要求を受け付けた場合、該検出条件の更新が完了するまで、前記判定処理の実行を停止する、
処理をさらに実行させる付記１記載のログ監視プログラム。

（付記４）
前記コンピュータに、
ユーザの識別情報と該ユーザに対応付けられたソフトウエアの実行ログデータとの受け付けを停止した後、前記記憶部に記憶された検出条件の更新要求を受け付けた場合、該検出条件を更新し、
受け付けを停止する前に受け付けた前記実行ログデータであって且つ前記判定処理が実行されていない実行ログデータに対して、更新後の前記検出条件に基づき前記判定処理を実行する、
処理をさらに実行させる付記１記載のログ監視プログラム。

（付記５）
前記コンピュータに、
前記判定処理についてのプロセスの状態が前記異常状態である場合、直近の所定量の実行ログデータ及びユーザの識別情報と、前記直近の所定量の実行ログデータ及びユーザの識別情報を前記判定処理についてのプロセスに出力済みであることを示す情報とを、前記ロードバランサに返送する、
処理をさらに実行させる付記２記載のログ監視プログラム。

（付記６）
ユーザの識別情報と該ユーザに対応付けられたソフトウエアの実行ログデータとを受け付ける処理において、
直近の所定量の実行ログデータ及びユーザの識別情報を前記判定処理についてのプロセスに出力済みであることを示す情報をさらに受け付け、
前記判定処理の結果を出力する処理において、
前記判定処理の結果を既に出力したことを示唆する情報をさらに出力する、
付記１記載のログ監視プログラム。

（付記７）
コンピュータが、
複数のユーザのうちいずれかのユーザの識別情報と、該ユーザに対応付けられたソフトウエアの実行ログデータとを受け付け、
実行ログデータの検出条件をユーザの識別情報に対応付けて記憶する記憶部から、受け付けた前記識別情報に対応付けられた検出条件を取得し、
受け付けた前記実行ログデータが、取得した前記検出条件を満たすか否かについて判定処理を行い、
前記判定処理の結果を出力する、
処理を実行するログ監視方法。

（付記８）
複数のユーザのうちいずれかのユーザの識別情報と、該ユーザに対応付けられたソフトウエアの実行ログデータとを受け付ける受付部と、
実行ログデータの検出条件をユーザの識別情報に対応付けて記憶する記憶部から、受け付けた前記識別情報に対応付けられた検出条件を取得し、受け付けた前記実行ログデータが、取得した前記検出条件を満たすか否かについて判定処理を行い、前記判定処理の結果を出力する出力部と、
を有するログ監視装置。

１ 情報処理装置 ３ 監視装置
５ 管理装置 ７ ネットワーク
９ａ，９ｂ，９ｃ 利用者端末
１１ ＣＰＵ １２ メモリ
１３ ＨＤＤ １４ ＮＩＣ
１０１ ロードバランサ １０２ 制御部
１０３ データ格納部 １０４ ログ処理部
１０５ アプリケーション実行基盤
１０５ａ，１０５ｂ，１０５ｃ，１０５ｄ アプリケーション
３０ ＶＭ ３０１ ログ転送部
３０２ 監視部 ３０３ ログ格納部
３０４ 定義データ格納部
５０ ＶＭ ５０１ 定義管理部
５０２ 定義データ格納部

Claims (8)

1. コンピュータに、
   複数のユーザのうちいずれかのユーザの識別情報と、該ユーザに対応付けられたソフトウエアの実行ログデータとを受け付け、
   実行ログデータの検出条件をユーザの識別情報に対応付けて記憶する記憶部から、受け付けた前記識別情報に対応付けられた検出条件を取得し、
   受け付けた前記実行ログデータが、取得した前記検出条件を満たすか否かについて判定処理を行い、
   前記判定処理の結果を出力する、
   処理を実行させるログ監視プログラム。
2. 前記コンピュータに、
   前記判定処理についてのプロセスの状態が異常状態である場合、受け付けた前記実行ログデータを、前記判定処理を実行する前に、受け付けた前記識別情報と前記実行ログデータの送信元であるロードバランサに返送する、
   処理をさらに実行させる請求項１記載のログ監視プログラム。
3. 前記コンピュータに、
   前記記憶部に記憶された検出条件の更新要求を受け付けた場合、該検出条件の更新が完了するまで、前記判定処理の実行を停止する、
   処理をさらに実行させる請求項１記載のログ監視プログラム。
4. 前記コンピュータに、
   ユーザの識別情報と該ユーザに対応付けられたソフトウエアの実行ログデータとの受け付けを停止した後、前記記憶部に記憶された検出条件の更新要求を受け付けた場合、該検出条件を更新し、
   受け付けを停止する前に受け付けた前記実行ログデータであって且つ前記判定処理が実行されていない実行ログデータに対して、更新後の前記検出条件に基づき前記判定処理を実行する、
   処理をさらに実行させる請求項１記載のログ監視プログラム。
5. 前記コンピュータに、
   前記判定処理についてのプロセスの状態が前記異常状態である場合、直近の所定量の実行ログデータ及びユーザの識別情報と、前記直近の所定量の実行ログデータ及びユーザの識別情報を前記判定処理についてのプロセスに出力済みであることを示す情報とを、前記ロードバランサに返送する、
   処理をさらに実行させる請求項２記載のログ監視プログラム。
6. ユーザの識別情報と該ユーザに対応付けられたソフトウエアの実行ログデータとを受け付ける処理において、
   直近の所定量の実行ログデータ及びユーザの識別情報を前記判定処理についてのプロセスに出力済みであることを示す情報をさらに受け付け、
   前記判定処理の結果を出力する処理において、
   前記判定処理の結果を既に出力したことを示唆する情報をさらに出力する、
   請求項１記載のログ監視プログラム。
7. コンピュータが、
   複数のユーザのうちいずれかのユーザの識別情報と、該ユーザに対応付けられたソフトウエアの実行ログデータとを受け付け、
   実行ログデータの検出条件をユーザの識別情報に対応付けて記憶する記憶部から、受け付けた前記識別情報に対応付けられた検出条件を取得し、
   受け付けた前記実行ログデータが、取得した前記検出条件を満たすか否かについて判定処理を行い、
   前記判定処理の結果を出力する、
   処理を実行するログ監視方法。
8. 複数のユーザのうちいずれかのユーザの識別情報と、該ユーザに対応付けられたソフトウエアの実行ログデータとを受け付ける受付部と、
   実行ログデータの検出条件をユーザの識別情報に対応付けて記憶する記憶部から、受け付けた前記識別情報に対応付けられた検出条件を取得し、受け付けた前記実行ログデータが、取得した前記検出条件を満たすか否かについて判定処理を行い、前記判定処理の結果を出力する出力部と、
   を有するログ監視装置。

Images