JP2017049715A - ログ管理プログラム、ログ管理方法およびログ管理装置 - Google Patents

Abstract

【課題】管理対象の機器の動作状況が変化した場合に、ログの情報を削除する適切なパターンを生成する、ログ管理プログラム、ログ管理方法およびログ管理装置を提供する。
【解決手段】ログ管理装置３（管理サーバ）は、管理対象の機器２（業務サーバ）の動作に関する情報の変化に応じて、機器のログデータのログ項目の規則性に基づいて生成されたログパターン特定情報によるログデータのログ項目の削除を一時停止する削除停止部１５と、動作に関する情報の変化状況に基づいて、ログパターン特定情報によるログ項目の削除の適否を判定する削除適否判定部１６と、削除が不適切であると判定された場合、削除が一時停止された後に記憶されたログ項目に基づき、ログパターン特定情報を更新する操作型処理部１１と、を含む。
【選択図】図１

Description

本発明は、ログ管理プログラム、ログ管理方法およびログ管理装置に関する。

近年、サービス利用者の業務サーバ等の機器をデータセンタに配置し、データセンタの管理サーバが機器の管理を行うサービスが利用されている。そのようなサービスにおいて、管理サーバは、管理対象の機器のログデータを記憶する。

特開２０１０−１２８９０１号公報 特開２０１４−１０６６５５号公報 特表２０１４−５０２７６７号公報 米国特許出願公開第２０１２／０１７９６４６号明細書 米国特許出願公開第２０１４／０１４９４６６号明細書

管理サーバが記憶するログの総サイズには制限があるため、ログを定期的に、内容に応じて削除する必要がある一方、事後の解析に利用されるログは削除せずに保持する必要がある。

管理サーバが、サービス利用者の機器の運用手順等を認識している場合、該運用手順に基づいて、管理サーバに記憶されたログのうち、一部の情報を問題なく削除することができる。

しかし、近年の、Platform as a Service(PaaS)等のサービスにおける運用管理においては、サービス利用者の運用手順を得ることは難しい。この場合、サービス利用者により行われた操作に関するログに出現する規則性等に基づいて、ログの情報（ログに含まれる情報）を定期的に削除することが考えられる。

運用手順が変更されると、機器の動作状況が変化する。この場合、ログの情報を削除する規則性も変化する。運用手順が変更される前の規則性に基づいて、運用手順が変更された後のログから情報を削除すると、例えば、解析等に使用されるログの情報が削除されることがある。

１つの側面として、本発明は、管理対象の機器の動作状況が変化した場合に、ログの情報の削除を適切に行うことを目的とする。

１つの態様では、ログ管理プログラムは、管理対象の機器の動作に関する情報の変化に応じて、前記機器のログデータのログ項目の規則性に基づいて生成されたログパターン特定情報による前記ログデータのログ項目の削除を一時停止し、前記動作に関する情報の変化状況に基づいて、前記ログパターン特定情報による前記ログ項目の削除の適否を判定し、前記削除が不適切であると判定された場合、前記削除が一時停止された後に記憶されたログ項目に基づき、前記ログパターン特定情報を更新する、処理をコンピュータに実行させる。

１つの側面によれば、管理対象の機器の動作状況が変化した場合に、ログの情報の削除を適切に行うことができる。

管理サーバおよび業務サーバの一例を示す図である。 ログデータおよび操作型の一例を示す図である。 操作型の生成の一例を示す図である。 操作型とログ項目の削除との関係の一例を示す図である。 リソース波形の一例を示す図（その１）である。 波形と操作型と管理サーバの動作との対応関係の一例を示す図（その１）である。 リソース波形の一例を示す図（その２）である。 波形と操作型と管理サーバの動作との対応関係の一例を示す図（その２）である。 ログ項目の削除の一例を示す図である。 運用変更管理情報およびログ削除管理情報の一例を示す図である。 実施形態の処理の一例を示すフローチャートである。 運用変更検知処理の一例を示すフローチャートである。 ログ削除処理の一例を示すフローチャートである。 管理サーバのハードウェア構成の一例を示す図である。

＜実施形態の業務システムの一例＞
以下、実施形態について、図面を参照して、説明する。図１は、実施形態の管理システム１の一例を示している。図１の例の管理システム１では、業務サーバ２が管理サーバ３により管理される。

業務サーバ２は、例えば、データセンタ等に設置され、管理サーバ３により管理される。業務サーバ２は、管理対象の機器の一例である。実施形態では、業務サーバ２は、複数の利用者が利用する実行環境（例えば、仮想環境）を含む。図１の例では、利用者Ａ〜利用者Ｚのそれぞれの実行環境が業務サーバ２に含まれる。

利用者Ａ〜利用者Ｚのそれぞれの実行環境は、業務サーバ２で動作するプログラムにより実現されてもよい。なお、利用者Ａ〜利用者Ｚのそれぞれに対して、物理的な機器が割り当てられてもよい。また、業務サーバ２の実行環境の数は１つであってもよい。

利用者Ａ〜利用者Ｚは、それぞれに割り当てられた実行環境にログインした後に、実行環境上で、所定の操作を行う。業務サーバ２は、該操作を受け付けて、実行環境ごとに、操作の履歴を操作ログとして保持する。操作ログは、システムログと称されることもある。

実施形態では、１つの操作に関する情報をログ項目と称する。複数の操作が実行された場合、操作ログは、複数のログ項目を含む。業務サーバ２が受け付ける操作としては、例えば、ログインおよびログアウトの操作がある。

また、業務サーバ２が受け付ける操作としては、業務サーバ２に所定の機能を実行させるコマンドがある。１つの操作に関する情報をログ項目とする。従って、業務サーバ２が、ログインの操作を受け付け、一連のコマンド操作が実行され、その後ログアウトの操作を受け付けた場合、操作ログには複数のログ項目が含まれる。

業務サーバ２は、それぞれの実行環境により使用される業務サーバ２のリソースの使用状況を示すリソース情報を保持する。リソースとしては、例えば、業務サーバ２のハードウェアリソース等がある。また、リソース情報には、業務サーバ２によるネットワーク負荷に関する情報が含まれてもよい。リソース情報は、機器の動作に関する情報の一例である。

管理サーバ３は、操作型処理部１１と運用変更検知部１２と情報収集部１３とログ削除部１４と削除停止部１５と削除適否判定部１６と監視重要度設定部１７とログデータベース１８とリソース情報データベース１９とを含む。なお、図２の例の表記において、「ＤＢ」はデータベースを示している。管理サーバ３は、ログ管理装置の一例である。

操作型処理部１１は、ログデータベース１８に記憶されたログデータのログ項目の削除を行う操作型の生成処理や更新処理等を行う。操作型は、ログパターン特定情報の一例である。また、操作型処理部１１は、更新部の一例である。

運用変更検知部１２は、業務サーバ２の各実行環境のそれぞれについて、業務サーバ２によるシステムの運用が変更されたかを検知する。運用変更検知部１２は、業務サーバ２の各実行環境のリソース情報の変化状況に基づいて、運用が変化されたかを検知する。

情報収集部１３は、業務サーバ２の各実行環境が保持する操作ログおよびリソース情報を定期的に収集する。情報収集部１３は、収集した操作ログをログデータベース１８に記憶する。ログ削除部１４は、操作型を使用して、ログデータベース１８に記憶されたログデータのログ項目を削除する。

削除停止部１５は、ログ削除部１４によるログ項目の削除を一時的に停止させる。削除適否判定部１６は、操作型処理部１１により生成された操作型を使用したログ項目の削除の適否を、上記のリソース情報の変化に基づいて、判定する。削除適否判定部１６は、判定部の一例である。

監視重要度設定部１７は、各実行環境のそれぞれについて、監視の重要度を設定する。例えば、トラブル発生頻度が高い実行環境に対しては、監視重要度設定部１７は、監視の重要度を高く設定する。また、トラブル発生頻度が低い実行環境に対しては、監視重要度設定部１７は、監視の重要度を低く設定する。

例えば、管理サーバ３は、監視の重要度が高い実行環境に対しては、監視ポーリング回数や監視項目数を多くする。また、管理サーバ３は、監視の重要度が低い実行環境に対しては、監視ポーリング回数や監視項目数を少なくする。

ログデータベース１８は、業務サーバ２の各実行環境の操作ログを、実行環境ごとに記憶する。リソース情報データベース１９は、業務サーバ２の各実行環境のリソース情報を、実行環境ごとに記憶する。

次に、図２を参照して、ログデータおよび操作型の一例について説明する。図２の例のログデータのうち「ファイル名」は、ログデータがログデータベース１８にファイル形式で記憶される場合のファイル名を表す。

例えば、「20150101-userA.log」は「２０１５年１月１日」に利用者Ａの実行環境で操作された操作ログに関するログデータのファイルである。実施形態では、ログデータベース１８は、実行環境ごとにログデータをファイル形式で記憶する。ログデータは、ファイル形式で記憶されなくてもよい。

ログデータは、複数の操作ログのログ項目を含む。図２の例に示される１つの項目がログ項目である。

例えば、図２の例のうち、ログ項目Ｌ１で示される「2015-01-01_00:01:00 exec cmd A」が１つのログ項目である。同様に、ログ項目Ｌ２で示される「2015-01-01_00:02:00 exec cmd B」も１つのログ項目である。他の項目もログ項目である。図２の例のログデータは複数のログ項目を含む。

図２の例では、各ログ項目は、日付と時刻と操作情報とを含む。「login」は業務サーバ２の実行環境にログインされたことを示す。「logout」は業務サーバ２の実行環境からログアウトされたことを示す。「exec cmd A」は、業務サーバ２の実行環境がコマンドＡの実行操作を受け付けたことを示す。

操作型のうち「ファイル名」は、操作型がログデータベース１８にファイル形式で記憶される場合のファイル名を表す。例えば、「pattern-userA.log」は、利用者Ａの実行環境で操作された内容に基づく操作型のファイルのファイル名である。

実施形態では、ログデータベース１８は、実行環境ごとに操作型をファイル形式で記憶するが、操作型はファイル形式でなくてもよい。各コマンドに併記される時刻は、操作型の最初のコマンドが実行された時点から起算した時刻を示す。

情報収集部１３が業務サーバ２から操作ログを収集するごとに、ログデータベース１８にログ項目が蓄積される。操作型処理部１１が操作型を新たに生成するごとに、ログデータベース１８の操作型は更新される。

＜操作型生成の一例＞
情報収集部１３は、業務サーバ２に対して行われた操作に関する操作ログを定期的に収集し、収集した操作ログをログデータとしてログデータベース１８に記憶する。ログデータベース１８に記憶されるログデータの情報量が多くなると、管理サーバ３のリソースの使用率が高くなる。

また、管理サーバ３が操作ログに基づく解析等の処理を行うときに、ログデータの情報量が多くなると、例えばCentral Processing Unit(CPU)の負荷が高くなる。このため、管理サーバ３のハードウェアリソースの使用率が高くなる。

業務サーバ２によるシステムの運用手順として、定期的なメンテナンスがある。定期的なメンテナンスは、業務サーバ２の実行環境ごとに行われる。定期的なメンテナンスにおける操作は、規則性がある。

例えば、定期メンテナンスは、所定の時間帯に予め決まったコマンドのパターンが実行されることにより行われる。従って、ログデータベース１８においても、定期メンテナンスに関するログ項目のパターン（以下、ログパターンと称することもある）は、所定の規則性で出現する。

このため、ログ削除部１４は、定期メンテナンスのログパターンに基づく操作型を用いて、ログデータベース１８に記憶されたログ項目のうち、操作型のログパターンと一致するログ項目を削除する。これにより、管理サーバ３のハードウェアリソースの使用率が低減される。

業務サーバ２の実行環境に何らかのトラブルが生じた場合、該トラブルの原因調査が行われる。業務サーバ２に生じるトラブルは偶発的に生じるものであり、定期メンテナンスのように所定の規則性で出現しない。

従って、ログ削除部１４が操作型を使用してログデータベース１８からログ項目を削除したとしても、トラブル原因調査に関するログ項目はログデータベース１８から削除されない。操作型によりログデータベース１８のログ項目が削除されたとしても、ログデータベース１８のログデータに基づいて、後にトラブルの原因調査を行うことができる。

ここで、管理サーバ３が業務サーバ２によるシステムの運用手順を認識している場合、該運用手順に基づいて、定期メンテナンスが行われる時間帯や実行されるコマンド等が認識される。このため、操作型処理部１１は、適切な操作型を生成し、ログ削除部１４は、該適切な操作型を使用して、ログデータベース１８からログ項目の削除を行うことができる。

ただし、近年のＰａａｓ等においては、サービス利用者により利用される業務サーバ２の運用手順がサービス提供者に提示されない場合がある。この場合、管理サーバ３は、業務サーバ２の運用手順を認識しない。このため、操作型処理部１１は、適切な操作型を生成することが難しい。

ログデータベース１８には、情報収集部１３が業務サーバ２から収集した操作ログが記憶される。そこで、操作型処理部１１は、ログデータベース１８に記憶されたログ項目の規則性に基づいて、操作型を生成することが考えられる。

この場合、操作型処理部１１は、ログデータベース１８を参照して、所定の時間帯において一定のパターンのコマンドが実行されたことを認識した場合、認識したコマンドのパターンを操作型として生成する。

図３は、操作型Ｔ１の生成の一例を示している。図３において、ログデータベース１８に記憶されたログデータの各ログ項目は週ごとに分けられている。操作型処理部１１は、所定の時間帯（時刻ｔ１〜時刻ｔ２）における一定のパターンのコマンド（コマンドＡ、コマンドＢ、コマンドＣ）を操作型Ｔ１として生成する。

図３の例では省略しているが、操作型Ｔ１は、ログインおよびログアウトの情報も含む。図３の例では、操作型Ｔ１は、ログイン、コマンドＡ、コマンドＢ、コマンドＣ、ログアウトの順番で操作が行われたことを示す。

ログ削除部１４は、ログデータベース１８のうち操作型Ｔ１と一致するログ項目をログデータベース１８から削除する。これにより、ログデータベース１８に記憶される情報の情報量が低減される。

ここで、業務サーバ２によるシステムの運用は変更される場合がある。操作型Ｔ１は、システムの運用変更前のログデータに基づく操作型である。システムの運用が変更された後に、ログ削除部１４が該操作型Ｔ１を用いてログデータベース１８のログ項目を削除すると、後の解析等に使用される情報が削除されることがある。

このため、従前（システムの運用変更前）に使用されていた操作型Ｔ１が、システムの運用変更後に使用されることは、不適切である。

図４は、操作型とログ項目の削除との関係の一例を示す。図４の例において、運用変更前の操作型Ｔ１は、図４の実線の枠内のコマンドＡ、コマンドＢ、コマンドＣのパターンである。

一方、運用変更後の操作型Ｔ２は、図４の点線の枠内のコマンドＣ、コマンドＤ、コマンドＡのパターンである。なお、図４の例において、一点鎖線は、システムの運用が変更されたタイミングを示している。

従って、システムの運用変更後に、ログ削除部１４が従前の操作型Ｔ１でログ項目の削除を行うと、システムの運用変更後には削除の対象とならないログ項目が削除される。例えば、図４の例において、システムの運用変更後、コマンドＡ、コマンドＢ、コマンドＣのパターンのログ項目は削除の対象にはならない。

ただし、システムの運用変更後においても、ログ削除部１４が従前の操作型Ｔ１でログ項目の削除を行うと、コマンドＡ、コマンドＢ、コマンドＣのパターンのログ項目も削除される。このため、トラブルの原因調査を行うときに使用されるログ項目が削除される。

そこで、業務サーバ２の運用の変更を運用変更検知部１２が検知した場合、操作型処理部１１は、操作型を更新する。ログ削除部１４は、更新された新たな操作型を用いて、ログデータベース１８に記憶されたログデータのログ項目を削除する。

＜新たな操作型生成の一例＞
図５は、４月第３週から５月第３週までにおける、業務サーバ２のうち１つの実行環境によるリソース波形の一例を示す。リソース波形は、リソース情報の経時的変化を表現した波形である。図５の例では、リソース波形は１週間をサイクルとする。

例えば、定期的なメンテナンスは、１週間のうち所定の期間の間に集中的に行われる。この場合、リソース使用率は、１週間のうち所定の期間、高くなる。システムの運用が変更されていなければ、リソース波形は一定になることが想定される。

一方、システムの運用が変更されると、定期的なメンテナンスが行われる期間が変更される可能性がある。この場合、リソース使用率が高くなる期間は、システム運用変更前とシステム運用変更後とでは異なり、リソース波形が変化することが想定される。

図５に例示する波形において、４月第３週の時点では、１週間のうち日曜日の所定時間帯のリソース使用率が高い。４月第３週の時点での波形を波形Ｗ１とする。一方、図５に例示する波形において、４月第４週からは、１週間のうち月曜日の所定時間帯のリソース使用率が高い。４月第４週以降の波形を波形Ｗ２とする。

従って、運用変更検知部１２は、リソース波形（機器の動作に関する情報の変化を示す波形）に応じて、４月第４週に業務サーバ２によるシステムの運用が変更された可能性を検知する。

リソース波形の変化は、例えば、突発的な障害等を要因として、一時的に生じる場合がある。この場合、業務サーバ２によるシステムの運用は変更されていない可能性がある。

そこで、運用変更検知部１２は、リソース波形が変化した後、変化後の波形が所定期間継続した場合に、業務サーバ２によるシステムの運用が変更されたことを検知する。例えば、図５の例では、リソース波形が変化した後、変化後の波形が４週間継続した場合に、運用変更検知部１２は運用の変化を検知する。

図６は、週ごとの波形と操作型と管理サーバ３の動作との対応関係の一例である。１月第１週に、業務サーバ２によるシステムの運用が開始されたとする。システムの運用が開始された直後に、ログデータベース１８に記憶されたログ項目の数は少ない。

操作型処理部１１は、ログデータベース１８に記憶されたログ項目の規則性に基づいて、操作型を生成する。このため、ログデータベース１８に記憶されたログ項目の数が少ない段階では、操作型を生成するためのサンプル数が少ない。

操作型処理部１１は、ログデータベース１８にある程度の数（所定数）のログ項目が記憶されるまで、操作型を生成しない。図６の例では、１月第１週から２月第１週までの間、操作型は生成されない。また、図６の例では、１月第１週から４月第３週までのリソース波形はＷ１である。

図６の例では、２月第１週に、操作型処理部１１は、ログデータベース１８に記憶されたログデータのログ項目の規則性に基づいて、最初の操作型Ｔ１を生成する。２月第１週以降、ログ削除部１４は、ログデータベース１８に記憶されたログ項目のうち、操作型Ｔ１のログパターンと一致するログ項目を削除する。

図６の例では、４月第４週の時点で、リソース波形はＷ１からＷ２に変化する。運用変更検知部１２は、リソース波形の変化に応じて、システムの運用変更の可能性を検知する。

運用変更検知部１２がシステムの運用変更の可能性を検知すると、削除停止部１５は、ログ削除部１４によるログ項目の削除を一時停止させる。このため、ログ項目の削除が一時停止された後、情報収集部１３が業務サーバ２の実行環境から収集した操作ログは、削除されることなく、ログデータベース１８に蓄積される。

変化後のリソース波形Ｗ２が所定期間（例えば、４週間）継続した場合、運用変更検知部１２は、システムの運用が変更されたことを検知する。この場合、削除適否判定部１６は、システムの運用が変更されたことが検知されたため、従前の操作型Ｔ１を使用したログ削除部１４によるログ項目の削除は不適切と判定する。

この場合、操作型処理部１１は、システムの運用変更後に応じた新たな操作型Ｔ２を生成し、従前の操作型Ｔ１を新たな操作型Ｔ２に変更する。従前の操作型Ｔ１と新たな操作型Ｔ２とはログ項目のパターンが異なる。また、削除停止部１５は、ログ削除部１４によるログ項目の削除の一時停止を解除する。

これにより、５月第３週以降、ログ削除部１４は、新たな操作型Ｔ２と一致するログ項目のパターンを削除する。また、ログ削除部１４は、新たな操作型Ｔ２に基づいて、ログ項目の削除が一時停止されてからログ項目の削除が再開するまでの間にログデータベース１８に記憶されたログ項目を削除する。

図７は、４月第３週から５月第３週までにおける、業務サーバ２のうち１つの実行環境によるリソース波形の他の例を示す。図７において、４月第３週におけるリソース波形はＷ１であり、４月第４週におけるリソース波形はＷ２に変化する。

４月第４週において、運用変更検知部１２は、業務サーバ２によるシステムの運用の変更の可能性を検知する。このため、削除停止部１５は、ログ削除部１４によるログ項目の削除を停止させる。

図７の例において、５月第１週にリソース波形はＷ２からＷ１に戻る。この場合、変化後のリソース波形Ｗ２は所定期間（例えば、４週間）継続していない。この場合、運用変更検知部１２は、システムの運用が変更されていないことを検知する。

システムの運用が変更されていないことが検知された場合、削除適否判定部１６は、従前の操作型Ｔ１を使用したログ削除部１４によるログ項目の削除は適切であると判定する。また、削除停止部１５は、ログ削除部１４によるログ項目の削除の一時停止を解除する。

ログ削除部１４は、従前の操作型Ｔ１を使用して、ログデータベース１８のログ項目の削除を行う。また、ログ削除部１４は、ログ項目の削除が一時停止されていた間に記憶されたログ項目を、操作型Ｔ１に基づいて削除する。

従って、リソース波形の変化状況に基づいて、システムの運用変更が検知された場合、削除適否判定部１６は、従前の操作型Ｔ１の使用は不適切であると判定する。この場合、従前の操作型Ｔ１は使用されず、更新後の新たな操作型Ｔ２が使用される。

一方、リソース波形の変化状況に基づいて、システムの運用変更が検知されない場合、削除適否判定部１６は、従前の操作型Ｔ１の使用は適切であると判定する。この場合、操作型の更新は行われず、従前の操作型Ｔ１が使用される。

図８は、週ごとの波形と操作型と管理サーバ３の動作との対応関係の一例である。１月第１週に、業務サーバ２によるシステムの運用が開始される。２月第１週に、操作型処理部１１は、ログデータベース１８に記憶されたログ項目の規則性に基づいて、操作型Ｔ１を生成する。そして、ログ削除部１４は、操作型Ｔ１に基づいて、ログデータベース１８のログ項目を削除する。

４月第４週に、運用変更検知部１２がシステムの運用変更の可能性を検知すると、削除停止部１５は、ログ削除部１４によるログ項目の削除を一時停止させる。５月第１週に、リソース波形はＷ２からＷ１に戻るため、運用変更検知部１２は、システムの運用変更を検知しない。

この場合、削除適否判定部１６は、従前の操作型Ｔ１の使用が適切であると判定するため、操作型処理部１１は、従前の操作型Ｔ１を使用する。５月第１週以降、ログ削除部１４は、従前の操作型Ｔ１を使用して、ログデータベース１８のログ項目を削除する。

次に、ログ項目の削除の一例について、図９の例を参照して説明する。図９は、一例として、業務サーバ２の利用者Ａの実行環境についての波形、操作型およびログデータベース１７の状態を示す。

また、図９の例において、４月第３週から５月第３週までのログデータベース１８の状態を示しているが、ログデータベース１８には、４月第２週以前のログデータも記憶されている。

情報収集部１３は、業務サーバ２の利用者Ａの実行環境から４月第３週の操作ログを収集し、収集した操作ログをログデータベース１８に記憶する。例えば、情報収集部１３は、利用者Ａの実行環境のエージェントプログラムを介して、操作ログを収集する。

図９の例の場合、４月第３週において、７つのコマンドが実行されたことを示す。情報収集部１３は、操作ログを収集し、収集した操作ログをログデータベース１８に記憶する。また、４月第３週における操作型はＴ１である。

ログ削除部１４は、ログデータベース１８に記憶された各ログ項目のうち、操作型Ｔ１と一致するパターンのログ項目を削除する。操作型Ｔ１のログパターンは、コマンドＡ、コマンドＢ、コマンドＣである。

ログ削除部１４は、図９の例の実線で示される３つのコマンドのログ項目を削除する。これにより、４月第３週にログデータベース１８に記憶された６つのコマンドのうち、実線で囲まれた３つのコマンド以外の３つのコマンドがログデータベース１８に残る。

また、情報収集部１３は、業務サーバ２の利用者Ａの実行環境から４月第３週のリソース情報を収集し、収集したリソース情報をリソース情報データベース１９に記憶する。図９の例において、４月第３週のリソース情報に基づく、リソース波形はＷ１である。

４月第４週において、情報収集部１３は、業務サーバ２の利用者Ａの実行環境からリソース情報を収集し、収集したリソース情報をリソース情報データベース１９に記憶する。運用変更検知部１２は、リソース情報データベース１９に記憶された４月第４週のリソース情報に基づいて、リソース波形がＷ１からＷ２に変化したことを認識する。

この場合、運用変更検知部１２は、システムの運用変更の可能性を検知する。運用変更検知部１２がシステムの運用変更の可能性を検知すると、削除停止部１５は、ログ削除部１４によるログ項目の削除を一時停止させる。

４月第４週において、情報収集部１３は、業務サーバ２の利用者Ａの実行環境から操作ログを収集し、収集した操作ログをログデータベース１８に記憶する。図９の例では、情報収集部１３は、５つのコマンドのログ項目をログデータベース１８に記憶する。

４月第４週において、ログ削除部１４によるログ項目の削除は一時停止されているため、ログデータベース１８に記憶された５つのコマンドのログ項目は削除されない。５月第１週、５月第２週および５月第３週も同様である。

従って、ログデータベース１８には、４月第４週の最初のコマンドＡのログ項目を開始位置として、情報収集部１３が５月第１週、５月第２週および５月第３週に業務サーバ２の利用者Ａの実行環境から収集した操作ログが、削除されずに記憶される。

運用変更検知部１２は、リソース情報データベース１９に記憶されたリソース情報に基づいて、４月第４週から５月第３週までの４週間（所定期間）の間、リソース波形Ｗ２が継続していることを認識する。これにより、運用変更検知部１２は、システムの運用が変更されたことを検知する。

システムの運用が変更されたことが検知されたため、削除適否判定部１６は、従前の操作型Ｔ１を使用したログ項目の削除は不適切であると判定する。このため、操作型処理部１１は、操作型を新たな操作型Ｔ２に更新する。

ログ項目の削除が一時停止された４月第４週から５月第３週までの間、ログ項目は削除されない。操作型処理部１１は、この間にログデータベース１８に記憶された操作ログに基づいて、新たな操作型Ｔ２を生成する。

つまり、操作型処理部１１は、削除停止部１５によりログ項目の削除が一時停止された後にログデータベース１８に記憶されたログ項目のパターンに基づいて、新たな操作型Ｔ２を生成する。

週ごとの、所定の時間帯における一定のログパターンは、コマンドＣ、コマンドＤ、コマンドＡであるとする。操作型処理部１１は、図９において破線で囲まれたログパターンを操作型Ｔ２として生成し、従前の操作型Ｔ１を新たな操作型Ｔ２に更新する。

ログ削除部１４は、ログデータベース１８に記憶された４月第４週から５月第３週までの各ログ項目のうち、新たな操作型Ｔ２のログパターンと一致するログ項目を削除する。また、ログ削除部１４は、５月第３週以降、更新後の操作型Ｔ２のログパターンを使用して、ログデータベース１８に記憶されたログ項目を削除する。

次に、図１０の例を参照して、運用変更管理情報およびログ削除管理情報について説明する。情報収集部１３は、業務サーバ２の各実行環境からリソース情報を収集し、収集したリソース情報をリソース情報データベース１９に記憶する。

ログデータベース１８には、実行環境ごとに、リソース情報が記憶される。運用変更検知部１２は、実行環境ごとのリソース情報に基づいて、実行環境ごとにシステムの運用状況を検知する。

運用変更管理情報は、運用変更検知部１２により管理される情報であり、例えば、リソース情報データベース１９に記憶される。第１カラムは、利用者ＩＤである。利用者ＩＤは、業務サーバ２の実行環境を利用する利用者を特定する識別子であり、実行環境を特定する識別子でもある。ＩＤはIdentificationの略称である。

例えば、利用者ＩＤ「００００１」は利用者Ａであることを示し、利用者Ａの実行環境であることを示す。また、利用者ＩＤ「００００２」は利用者Ｂであることを示し、利用者Ｂの実行環境であることを示す。

第２カラムは、運用変更検知部１２の動作状況を示す。図１０の例では、第２カラムの値が「０」の場合、運用変更検知部１２の動作が停止中であることを示す。上述したように、ログデータベース１８にある程度のログ項目が記憶されるまで、最初の操作型は生成されない。最初の操作型が生成されるまでの間、運用変更検知部１２は動作しない。

運用変更検知部１２が動作を開始した後、該運用変更検知部１２は、リソース波形が変化したことに応じて、システムの運用変更の可能性を検知する。運用変更検知部１２は、システムの運用変更の可能性を検知しない場合、第２カラムの値を「１」に設定する。

運用変更検知部１２は、運用変更の可能性を検知した場合、運用変更可能性通知をログ削除部１４に出力する。運用変更検知部１２は、システムの運用変更の可能性を検知した後、変化後の波形が所定期間継続している場合、システムの運用変更を検知する。この場合、運用変更検知部１２は、ログ削除部１４に運用変更発生通知を出力する。

運用変更検知部１２は、運用変更の可能性を検知した後、変化後の波形が所定期間継続しない場合、運用変更の可能性を取り消す運用変更取消通知をログ削除部１４に出力する。

運用変更検知部１２は、運用変更可能性通知をログ削除部１４に出力した後、運用変更発生通知も運用変更取消通知もログ削除部１４に出力していない場合、第２カラムの値を「２」に設定する。

運用変更検知部１２は、運用変更発生通知をログ削除部１４に出力した場合、第２カラムの値を「３」に設定する。運用変更検知部１２は、運用変更取消通知をログ削除部１４に出力した場合、第２カラムの値を「４」に設定する。

次に、ログ削除管理情報について説明する。ログ削除管理情報は、ログ削除部１４により管理される情報であり、例えばログデータベース１８に記憶される。第１カラムは、利用者ＩＤを示す。

第２カラムは、ログ削除部１４の動作状況を示す。第２カラムの値が「０」の場合、ログ削除部１４の動作は停止中であることを示す。運用変更管理情報の第２カラムが「０」の場合、対応するログ削除管理情報の第２カラムも「０」である。

最初の操作型が生成された後、ログ削除部１４が運用変更検知部１２から運用変更可能性通知を入力していない場合、ログ削除部１４は第２カラムの値を「１」に設定する。ログ削除部１４が運用変更検知部１２から運用変更可能性通知を入力した場合、ログ削除部１４は第２カラムの値を「２」に設定する。

ログ削除部１４が運用変更検知部１２から運用変更発生通知を入力した場合、ログ削除部１４は第２カラムの値を「３」に設定する。ログ削除部１４が運用変更検知部１２から運用変更取消通知を入力した場合、ログ削除部１４は第２カラムの値を「４」に設定する。

運用変更管理情報は、運用変更検知部１２により管理される。運用変更検知部１２は、状況に応じて運用変更管理情報を変更する。また、運用変更検知部１２は、運用変更管理情報に基づいて、各種の判定を行ってもよい。

ログ削除管理情報は、ログ削除部１４により管理される。ログ削除部１４は、状況に応じてログ削除管理情報を変更する。また、ログ削除部１４は、ログ削除管理情報に基づいて、各所の判定を行ってもよい。

＜実施形態の処理の流れの一例を示すフローチャート＞
次に、図１１のフローチャートを参照して、実施形態の処理の流れの一例を説明する。業務サーバ２によるシステムの運用が開始された後、情報収集部１３は、業務サーバ２の実行環境から操作ログを収集し、収集した操作ログをログデータベース１８に記憶する。

ログデータベース１８にある程度の数のログ項目が記憶されるまで、操作型処理部１１は操作型を生成しない。また、運用変更検知部１２およびログ削除部１４は動作を停止中である。

この場合、運用変更管理情報およびログ削除管理情報の第２カラムの値は「０」に設定される。ログデータベース１８にある程度の数のログ項目が記憶されると、操作型処理部１１は、ログデータベース１８に記憶されたログデータのログ項目の規則性に基づいて、最初の操作型を生成する（ステップＳ１）。ステップＳ１の後、運用変更管理情報およびログ削除管理情報の第２カラムの値は「１」に変更される。

操作型処理部１１は、例えば、ログデータベース１８に記憶されたログ項目のうち、所定の時間帯におけるログパターンを最初の操作型として生成する。

ログ削除部１４は、操作型を使用して、操作型と一致するパターンのログ項目をログデータベース１８から削除する（ステップＳ２）。使用される操作型は、最初の操作型の場合もあり、操作型処理部１１が新たに生成した操作型である場合もある。

情報収集部１３は、業務サーバ２の実行環境からリソース情報を収集し、収集したリソース情報をリソース情報データベース１９に記憶する。運用変更検知部１２は、定期的にリソース情報データベース１９を参照する（ステップＳ３）。

運用変更検知部１２は、運用変更可能性を検知したかを判定する（ステップＳ４）。運用変更検知部１２は、リソース情報データベース１９に記憶されたリソース情報に基づくリソース波形を認識する。

リソース波形の変化が認識された場合、運用変更検知部１２は、システムの運用が変更された可能性があることを検知する。リソース波形の変化が認識されなければ、運用変更検知部１２は、システムの運用が変更された可能性があることを検知しない。

運用変更検知部１２がシステムの運用変更の可能性を検知しない場合（ステップＳ４でＮＯ）、処理はステップＳ２に戻る。

運用変更検知部１２がシステムの運用変更の可能性を検知した場合（ステップＳ４でＹＥＳ）、削除停止部１５は、ログ削除部１４によるログ項目の削除を一時停止させる（ステップＳ５）。

運用変更検知部１２は、リソース波形が変化した後、変化後の波形が所定期間継続したかを監視する。変化後のリソース波形が所定期間継続した場合、運用変更検知部１２は、システムの運用が変更されたことを検知する。

運用変更検知部１２がシステムの運用変更発生を検知した場合（ステップＳ６でＹＥＳ）、削除適否判定部１６は、従前に使用されていた操作型によるログ項目の削除が不適切であると判定する（ステップＳ７）。

操作型処理部１１は、ステップＳ５でログ項目の削除が一時停止された後に、ログデータベース１８に記憶されたログデータのログ項目の規則性に基づいて、新たな操作型を生成する（ステップＳ８）。そして、操作型処理部１１は、従前の操作型を新たな操作型に変更する（ステップＳ９）。

削除停止部１５は、ログ削除部１４によるログ項目の削除を再開させる。ログ削除部１４は、更新後の新たな操作型を使用する（ステップＳ１０）。この後、処理はステップＳ２に戻り、ログ削除部１４は、新たな操作型を使用して、ログデータベース１８に記憶されたログ項目を削除する。

運用変更検知部１２がシステムの運用変更発生を検知しない場合（ステップＳ６でＮＯ）、削除適否判定部１６は、従前に使用されていた操作型によるログ項目の削除は適切であると判定する（ステップＳ１１）。

この場合、ログ削除部１４によるログ項目の削除の再開後、操作型処理部１１は、従前に使用していた操作型を使用する（ステップＳ１２）。この後、処理はステップＳ２に戻り、ログ削除部１４は、従前の操作型を使用して、ログデータベース１８に記憶されたログ項目を削除する。

次に、運用変更検知部１２が行う処理（以下、運用検知処理と称する）の一例について、図１２のフローチャートを参照して説明する。操作型処理部１１は、最初の操作型の生成が完了した場合、その旨の通知を運用変更検知部１２に出力する。

運用変更検知部１２は、最初の操作型の生成が完了した旨の通知を入力しない場合（ステップＳ２１でＮＯ）、処理は次のステップに進まない。この場合、運用変更検知部１２は、リソース情報データベース１９を参照しない。

運用変更検知部１２が、最初の操作型の生成が完了した旨の通知を入力した場合（ステップＳ２１でＹＥＳ）、リソース情報データベース１９を参照する（ステップＳ２２）。運用変更検知部１２は、リソース情報データベース１９に記憶されたリソース情報に基づいて、リソース波形が変化したかを判定する（ステップＳ２３）。

リソース波形が変化していないことを示している場合（ステップＳ２３でＮＯ）、運用変更検知部１２は一定時間（例えば、１週間）スリープする（ステップＳ２４）。

リソース波形が変化したことを示している場合（ステップＳ２３でＹＥＳ）、運用変更検知部１２は、運用変更可能性通知をログ削除部１４に出力する（ステップＳ２５）。この場合、運用変更管理情報の第２カラムの値は「２」に変更される。

運用変更検知部１２は、リソース情報データベース１９に記憶されたリソース情報に基づいて、波形が変化した後のリソース波形が所定期間継続したかを判定する（ステップＳ２６）。

変化後のリソース波形が所定期間継続していないことを示している場合（ステップＳ２６でＮＯ）、運用変更検知部１２は、運用変更取消通知をログ削除部１４に出力する（ステップＳ２７）。この場合、運用変更管理情報の第２カラムの値は「４」に変更される。

変化後のリソース波形が所定期間継続したことを示している場合（ステップＳ２６でＹＥＳ）、運用変更検知部１２は、運用変更発生通知をログ削除部１４に出力する（ステップＳ２８）。この場合、運用変更管理情報の第２カラムの値は「３」に変更される。

次に、ログ削除部１４が行う処理（以下、ログ削除処理と称する）の一例について、図１３のフローチャートを参照して説明する。ログ削除部１４は、操作型処理部１１から最初の操作型の生成が完了した旨の通知を入力しない場合（ステップＳ３１でＮＯ）、処理は次のステップには進まない。

ログ削除部１４が、操作型処理部１１から最初の操作型の生成が完了した旨の通知を入力した場合（ステップＳ３１でＹＥＳ）、運用変更可能性通知を入力したかを判定する（ステップＳ３２）。

ログ削除部１４が、運用変更可能性通知を入力しない場合（ステップＳ３２でＮＯ）、ログ削除部１４は、従前の操作型を使用してログデータベース１８のログ項目を削除し、一定時間スリープする（ステップＳ３３）。

運用変更可能性通知をログ削除部１４が入力した場合（ステップＳ３２でＹＥＳ）、ログ削除部１４は、運用変更検知部１２から情報を入力したかを判定する（ステップＳ３４）。ログ削除部１４が運用変更可能性通知を入力した場合、ログ削除管理情報の第２カラムの値は「２」に変更される。

ログ削除部１４が運用変更検知部１２から情報を入力しない場合（ステップＳ３４でＮＯ）、処理は次のステップに進まない。

ログ削除部１４が運用変更検知部１２から情報を入力した場合（ステップＳ３４でＹＥＳ）、運用変更検知部１２は、入力した情報が運用変更発生通知であるかを判定する（ステップＳ３５）。

入力した情報が運用変更発生通知でない場合、入力した情報は運用変更取消通知である。この場合（ステップＳ３５でＮＯ）、操作型は更新されないため、処理はステップＳ３３に進む。

入力した情報が運用変更発生通知である場合（ステップＳ３５でＹＥＳ）、ログ削除部１４は、操作型処理部１１により更新された新たな操作型を認識する（ステップＳ３６）。

ログ削除部１４は、新たな操作型を使用して、ログ項目の削除が一時停止された後にログデータベース１８に記憶された各ログ項目のうち、新たな操作型のログパターンと一致するログ項目を削除する（ステップＳ３７）。

ログ削除部１４が、運用変更検知部１２から運用変更発生通知を入力した場合、ログ削除管理情報の第２カラムの値は「３」に変更される。ログ削除部１４が、運用変更検知部１２から運用変更取消通知を入力した場合、ログ削除管理情報の第２カラムの値は「４」に変更される。

次に、監視重要度設定部１７が行う処理（以下、監視重要度決定処理と称する）について、説明する。監視重要度設定部１７は、業務サーバ２の実行環境ごとに、監視重要度を設定する。監視重要度を設定するため、監視重要度設定部１７は、ログデータベース１８を参照する。

ログデータベース１８に記憶されたログ項目のうち、操作型のログパターンと一致するログ項目は削除される。上述したように、操作型は、定期メンテナンスが行われるときに実行されるコマンドの規則性に基づくログ項目のパターンである。

ログデータベース１８は、業務サーバ２の実行環境ごとに、ログデータを記憶する。監視重要度設定部１７は、ログデータベース１７に記憶されているログイン数に応じて、実行環境ごとの監視重要度を決定する。

例えば、トラブルの原因調査のためにコマンドが実行される頻度が高いと、ログデータベース１８には、多くのログインの情報が残る。一方、トラブルの原因調査のためにコマンドが実行される頻度が低いと、ログデータベース１８に残るログインの情報は少ない。

監視重要度設定部１７は、ログデータベース１７に記憶されたログイン数が多い実行環境については、トラブルの原因調査のためにコマンドが実行された頻度が高いため、監視重要度を高く設定する。

一方、監視重要度設定部１７は、ログデータベース１７に記憶されたログイン数が少ない実行環境については、トラブルの原因調査のためにコマンドが実行された頻度が低いため、監視重要度を低く設定する。

＜管理サーバのハードウェア構成の一例＞
次に、図１４の例を参照して、管理サーバ３のハードウェア構成の一例を説明する。上述したように、管理サーバ３は、ログ管理装置の一例である。

図１４の例に示すように、バス１００に対して、プロセッサ１１１とRandom Access Memory(RAM)１１２とRead Only Memory(ROM)１１３と補助記憶装置１１４と媒体接続部１１５と通信インタフェース１１６とが接続されている。

プロセッサ１１１は任意の処理回路である。プロセッサ１１１には、例えば、上述したＣＰＵが適用されてもよい。

プロセッサ１１１はＲＡＭ１１２に展開されたプログラムを実行する。実行されるプログラムとしては、実施形態の処理を行うログ管理プログラムを適用してもよい。ＲＯＭ１１３はＲＡＭ１１２に展開されるプログラムを記憶する不揮発性の記憶装置である。

補助記憶装置１１４は、種々の情報を記憶する記憶装置であり、例えばハードディスクドライブや半導体メモリ等を補助記憶装置１１４に適用してもよい。媒体接続部１１５は、可搬型記録媒体１１９と接続可能に設けられている。

可搬型記録媒体１１９としては、可搬型のメモリや光学式ディスク（例えば、Compact Disk(CD)やDigital Versatile Disk(DVD)等）を適用してもよい。この可搬型記録媒体１１９に実施形態の処理を行うログ管理プログラムが記録されてもよい。

管理サーバ３のうち、操作型処理部１１と運用変更検知部１２と情報収集部１３とログ削除部１４と削除停止部１５と削除適否判定部１６と監視重要度設定部１７とは、ログ管理プログラムをプロセッサ１１１が実行することにより実現されてもよい。また、ログデータベース１８とリソース情報データベース１９とは、ＲＡＭ１１２や補助記憶装置１１４により実現されてもよい。

ＲＡＭ１１２、ＲＯＭ１１３、補助記憶装置１１４および可搬型記録媒体１１９は、何れもコンピュータ読み取り可能な有形の記憶媒体の一例である。これらの有形な記憶媒体は、信号搬送波のような一時的な媒体ではない。
＜その他＞
本実施形態は、以上に述べた実施の形態に限定されるものではなく、本実施形態の要旨を逸脱しない範囲内で種々の構成または実施形態を取ることができる。

１ 管理システム
２ 業務サーバ
１１ 操作型生成部
１２ 運用変更検知部
１３ 情報収集部
１４ ログ削除部
１５ 削除停止部
１６ 削除適否判定部
１７ 監視重要度設定部
１８ ログデータベース
１９ リソース情報データベース
１１１ プロセッサ
１１２ ＲＡＭ
１１３ ＲＯＭ

Claims (7)

1. コンピュータに、
   管理対象の機器の動作に関する情報の変化に応じて、前記機器のログデータのログ項目の規則性に基づいて生成されたログパターン特定情報による前記ログデータのログ項目の削除を一時停止し、
   前記動作に関する情報の変化状況に基づいて、前記ログパターン特定情報による前記ログ項目の削除の適否を判定し、
   前記削除が不適切であると判定された場合、前記削除が一時停止された後に記憶されたログ項目に基づき、前記ログパターン特定情報を更新する、
   処理を実行させるためのログ管理プログラム。
2. 前記コンピュータに、
   前記削除を一時停止している間の前記機器の動作に関する情報の変化状況に基づいて、前記ログパターン特定情報によるログ項目の削除が不適切であると判定された場合、前記ログパターン特定情報とは異なる新たなログパターン特定情報を生成する、
   処理を実行させるための請求項１記載のログ管理プログラム。
3. 前記コンピュータに、
   前記削除を一時停止している間の前記機器の動作に関する情報の変化状況に基づいて、前記ログパターン特定情報による前記ログ項目の削除が適切と判定された場合、前記ログパターン特定情報を使用する、
   処理を実行させるための請求項１記載のログ管理プログラム。
4. 前記コンピュータに、
   前記削除が一時停止された後、前記機器の動作に関する情報が変化した後の状態が所定期間継続した場合、前記ログパターン特定情報を更新し、前記変化した後の状態が前記所定期間継続しない場合、前記ログパターン特定情報を使用する、
   処理を実行させるための請求項１乃至３のうち何れか１項に記載のログ管理プログラム。
5. 前記コンピュータに、
   所定時間ごとの前記機器のリソースの使用状況を示す情報に基づく波形が変化したことを検知した場合、前記機器の動作に関する情報が変化したことを検知する、
   処理を実行させるための請求項１乃至４のうち何れか１項に記載のログ管理プログラム。
6. コンピュータが、
   管理対象の機器の動作に関する情報の変化に応じて、前記機器のログデータのログ項目の規則性に基づいて生成されたログパターン特定情報による前記ログデータのログ項目の削除を一時停止し、
   前記動作に関する情報の変化状況に基づいて、前記ログパターン特定情報による前記ログ項目の削除の適否を判定し、
   前記削除が不適切であると判定された場合、前記削除が一時停止された後に記憶されたログ項目に基づき、前記ログパターン特定情報を更新する、
   処理を実行するログ管理方法。
7. 管理対象の機器の動作に関する情報の変化に応じて、前記機器のログデータのログ項目の規則性に基づいて生成されたログパターン特定情報による前記ログデータのログ項目の削除を一時停止する削除停止部と、
   前記動作に関する情報の変化状況に基づいて、前記ログパターン特定情報による前記ログ項目の削除の適否を判定する判定部と、
   前記削除が不適切であると判定された場合、前記削除が一時停止された後に記憶されたログ項目に基づき、前記ログパターン特定情報を更新する更新部と、
   を備えるログ管理装置。

Images