(57)【要約】【課題】監視基盤において、ログデータベースの設定変更案を自動生成し、この設定変更案を運用管理者に提示することにより、運用管理者の設定変更作業を支援する。【解決手段】運用管理者が、設定管理インタフェースを介して、ログデータベースの設定変更をすると、設定管理インタフェースは、その設定情報を管理データベースに記録する。さらに、監視対象装置のログデータがログ収集ユニットを介して、ログデータベースに収集されると、ログデータ量分析ユニットが、ログデータベースのデータ量の利用情報を読み取って、管理データベース上に記録する。設定変更案生成ユニットは、管理データベース上に記録された情報をもとに、ログデータベースの設定変更案を自動生成する。また、設定変更にかかる時間を評価する指標値と、設定変更に伴う性能を評価する指標値と、設定変更に伴うデータ量を評価する指標値を計算し、変更案の効果と影響を運用管理者に提示する。【選択図】図２
2014106655.tif 000002
【特許請求の範囲】
【請求項１】
時系列データベースと、
該時系列データベースを利用する監視サーバとを備え、
前記監視サーバは、
複数の監視対象に関して、各々、前記時系列データベースを利用した時系列データを格納および検索する機能と、
前記監視対象毎の前記時系列データの種類と保存形式に関する設定情報を管理する設定管理機能と、
前記各監視対象に関し、時間情報を含む前記設定情報の変更案を生成する機能とを有し、
前記監視対象は、サービス提供対象のテナント、データ種別、及び前記テナントの機器を一意に識別するインスタンス名の組合せからなり、
前記監視対象毎に、前記時系列データベースの現在の設定情報と、前記時系列データの操作履歴及び前記時系列データの量の情報に基づいて、前記時間情報を含む設定情報の変更案を生成する
ことを特徴とする時系列データベースの設定自動生成システム。
【請求項２】
請求項１において、
前記監視サーバは、
前記監視対象毎に、
前記設定の変更に伴う影響や効果を定量化した指標を生成する機能と、
前記テナントの運用管理者の端末に、前記設定変更案と共に前記指標を提示する機能とを有する
ことを特徴とする時系列データベースの設定自動生成システム。
【請求項３】
請求項２において、
前記監視サーバは、
前記監視対象毎に、前記設定情報の変更に対する要求として、予め前記指標が満たすべき条件を水準値として記述したポリシー情報を保持しており、
前記ポリシー情報に記載された前記水準値と前記設定情報の変更案の指標値とを比較し、前記設定変更案が前記要求を満たしているかどうかを判断し、該判断結果をもとに前記設定変更案を生成する機能と、
前記端末に表示した前記設定変更案に対する前記テナントの運用管理者の判定を求める機能と、
前記判定で許可が得られた前記設定変更案を新たな設定情報として登録する機能とを有する
ことを特徴とする時系列データベースの設定自動生成システム。
【請求項４】
請求項３において、
前記設定変更案に対して前記運用管理者が許可・却下を選択した結果を、選択情報として記録する機能と、
該設定変更の選択情報を用いて、前記運用管理者の設定変更に対する要求を分析し、該分析結果をもとに前記ポリシー情報を更新する機能と、
該更新されたポリシー情報を用いて前記設定変更案を生成する機能とを有する
ことを特徴とする時系列データベースの設定自動生成システム。
【請求項５】
請求項３において、
前記監視対象の重要度を事前に計算する機能と、
該計算された重要度に従って、前記時系列データベースの前記設定情報の設定値あるいは前記ポリシー情報を重み付ける
ことを特徴とする時系列データベースの設定自動生成システム。
【請求項６】
請求項５において、
前記監視サーバは、
前記監視対象毎に、前記各テナントの各サービスの監視に関する情報と、前記サービスの役割や重要度を表すデータを予め記述したサービス情報を保持しており、
前記サービス情報を用いて前記重要度を算出する機能を有する
ことを特徴とする時系列データベースの設定自動生成システム。
【請求項７】
請求項５において、
前記監視サーバは、
前記監視対象毎に、前記各サービスに対する障害発生を記録する障害情報を保持しており、
前記障害情報を用いて前記重要度を算出する機能を有する
ことを特徴とする時系列データベースの設定自動生成システム。
【請求項８】
請求項２において、
前記指標は、
前記設定変更にかかる時間を評価する第１の指標値と、
前記設定変更に伴う性能の変化を評価する第２の指標値と、
前記設定変更に伴うデータ量の変化を評価する第３の指標値とを含み、
前記監視サーバは、
前記設定変更に伴う前記第１〜第３の指標値を含む差分情報、及び、該各差分情報に対応する前記テナントへの課金額の増減に関する情報を生成し、その結果を前記設定変更案と共に前記テナントの運用管理者の端末に表示する機能を有する
ことを特徴とする時系列データベースの設定自動生成システム。
【請求項９】
請求項１において、
前記テナントに実際にアクセスしたデータに合わせた設定変更案を生成する設定変更案生成ユニットを備えており、該設定変更案生成ユニットは、
前記テナントの設定見直し要求を受けると、指定された前記テナントの見直し対象期間中の操作履歴を取得し、データ設定情報を生成するデータ設定情報生成ユニットと、
前記生成された設定情報が、予め設定された設定変更のポリシーを満たしているかの判定及び調整を行い、前記設定変更案を生成するデータ設定情報調整ユニットと、
前記時系列データに対して、データの検索を高速化するためのインデックスを付与するインデックス設定情報生成ユニットと、
前記設定情報が予め設定された設定変更のポリシーを満たしているかの判定を行い、前記設定情報を調整するインデックス設定情報調整ユニット、及び
前記設定変更の案を前記テナントの管理者端末の画面に表示する変更案表示ユニットを含む
ことを特徴とする時系列データベースの設定自動生成システム。
【請求項１０】
時系列データベースとそれを利用する監視サーバとを備えたデータ検索システムにおける、時系列データベースの設定の自動生成方法であって、
前記監視サーバは、複数の監視対象に関して、各々、前記時系列データの保存に関する設定情報を管理する設定管理機能を備えており、
前記監視対象は、サービス提供対象のテナント、データ種別、及び前記テナントの機器を一意に識別するインスタンス名の組合せからなり、
前記監視対象毎に、前記時系列データベースを利用した時系列データを格納および検索し、
前記各監視対象に関し、時間情報を含む前記設定情報の変更案を生成し、
前記監視対象毎に、前記時系列データベースの現在の設定情報と、前記時系列データの操作履歴及び前記時系列データの量の情報に基づいて、前記時間情報を含む設定情報の変更案を生成する
ことを特徴とする時系列データベースの設定の自動生成方法。
【請求項１１】
請求項１０において、
前記監視対象毎に、
前記設定の変更に伴う影響や効果を定量化した指標を生成し、
前記テナントの運用管理者の端末に、前記設定変更案と共に前記指標を提示する
ことを特徴とする時系列データベースの設定の自動生成方法。
【請求項１２】
請求項１１において、
前記監視対象毎に、前記設定情報の変更案を用いて、前記設定の変更に伴う影響を定量化した指標を生成し、
前記テナントの運用管理者の端末に前記設定変更案と共に前記指標を表示し、該変更案に対する許可若しくは却下の判定を求め、
前記許可の判定があった前記設定変更案を新たな設定情報として登録する
ことを特徴とする時系列データベースの設定の自動生成方法。
【請求項１３】
請求項１２において、
前記テナントの運用管理者の端末に、前記設定変更に伴う前記指標の差分情報、及び、該差分情報に対応する前記テナントの管理者への課金額の増減金額を表示する
ことを特徴とする時系列データベースの設定の自動生成方法。
【請求項１４】
時系列データベースを利用する監視サーバであって、
前記時系列データベースは、サービス提供対象であるテナントの時系列データを保持する機能を有しており、
複数の監視対象に関して、各々、前記時系列データベースを利用した時系列データを格納および検索する機能と、
前記監視対象毎の前記時系列データの種類と保存形式に関する設定情報を管理する設定管理機能と、
前記各監視対象に関し、時間情報を含む前記設定情報の変更案を生成する機能とを有し、
前記監視対象は、前記テナント、データ種別、及び前記テナントの機器を一意に識別するインスタンス名の組合せからなり、
前記監視対象毎に、前記時系列データベースの現在の設定情報と、前記時系列データの操作履歴及び前記時系列データの量の情報に基づいて、前記時間情報を含む設定情報の変更案を生成する
ことを特徴とする時系列データベースの監視サーバ。
【請求項１５】
請求項１４において、
前記設定の変更に伴う影響や効果を定量化した指標を生成する機能と、
前記設定変更に伴う前記指標値の差分情報、及び、該各差分情報に対応する前記テナントへの課金額の増減に関する情報を生成する機能を有する
ことを特徴とする時系列データベースの監視サーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、時系列データベースの設定自動生成方法及び生成システム並びに監視サーバに係り、特に、時系列データベースの運用管理者に対する運用管理業務の支援技術に関する。
【背景技術】
【０００２】
コンピュータシステムの運用管理者は、そのシステム上で動作するサービスに影響する障害や、その予兆を示す異常を監視する。そして障害や異常が検出された場合は、それらの原因を分析し、必要に応じて対策を行う。
【０００３】
このようなサービス管理業務を支援するソフトウェアには、監視ソフトウェアがある。監視ソフトウェアは、障害検出および原因分析を支援するソフトウェアである。監視ソフトウェアは、第１に、監視対象のハードウェアやソフトウェアと通信し、システムの稼働状況を示すログデータを収集する機能を持つ。ログデータには、CPU使用率のような数値データや、アプリケーションの状態を表すテキストメッセージのような文字列データがある。近年では、これらの多種多様なログデータを収集し、検索可能にする監視ソフトウェアも存在する。監視ソフトウェアは、第２に、ログデータを線グラフなどの形に加工して、管理者端末の画面上に表示する機能を持つ。
【０００４】
従来では、監視の仕組みはログデータごとあるいはサービスごとに構築されていた。しかし、近年の仮想化技術によるシステム集約の影響にともなって、複数サービスを一元的に管理する統合監視の仕組みが求められるようになった。
【０００５】
このような統合監視を実現する監視ソフトウェアの一形態として、監視基盤がある。監視基盤では、異なるサービスの異なる種類のログデータを一か所に集約して管理する機能を提供する。監視基盤では、運用管理者からの要求に応じて、ログデータベース上に格納されたログデータを検索し、その結果を運用管理者に提示する。
【０００６】
ログデータベースでは、サービスやログデータの種類によって形式の異なるデータを格納できる必要がある。そのようなデータを柔軟に格納するための技術が存在する。特許文献１は、リレーショナルデータベース（以下、RDB）のように予めスキーマ(格納データ構造)の定義を必要とするデータベースを対象とし、定義済みの固定のスキーマに対して、可変なスキーマ・データを格納するための方法を開示する。この技術では、まず、固定スキーマの定義時に、可変データ用のデータフィールド列を予め複数個用意しておく。その後、データ種別ごとの異なるデータ形式の定義情報をスキーマの外で管理することで、同一のフィールド列に異なるデータ形式の値を格納可能とする。特許文献１と別の方法として、形式の異なるデータのキーと値をハッシュテーブルに格納して、そのテーブルデータのバイナリをリレーショナルデータベースの単一の列に格納する方法も存在する。さらに、近年では、ドキュメント指向データベースと呼ばれるスキーマ柔軟性を備えた新たなデータベースが登場した。ドキュメント指向データベースは、格納、検索、インデックス付与など、RDBとほぼ同様の基本機能を提供する。ただし、ドキュメント指向データベースでは、RDBのようにデータを表形式で格納するのではなく、キーと値の組み合わせで格納する。そのため、事前のスキーマ定義は不要となる。これら、キーと値を格納する方法は、どの列に何を入れるかを事前定義する特許文献１と異なり、データ列の定義や順序が後から変わった場合にも対応できるという利点がある。
【０００７】
一方、設定における人手のリソースを減らすための技術として、一般的なデータベースの設定を自動化する方法が存在する。特許文献２と特許文献３は、属性への検索頻度から、データベースの検索インデックスを評価し、自動調整する技術を開示する。特許文献４は、検索頻度から、予め登録済みのインデックス候補の利用頻度を評価して、上位から順に選択する技術を開示する。特許文献５は、検索の応答時間と挿入の応答時間との累計値が最小となるインデックスを自動生成する技術を開示する。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２０１１−１３４３４２号公報
【特許文献１】特開２００３−２２８５７０号公報
【特許文献２】特開平６−２１５０３７号公報
【特許文献３】特開平７−８５０９３号公報
【特許文献４】特開平１０−１１１８１９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
監視基盤のログデータベースを利用するためには、ログデータベースの設定を行う必要がある。この設定には、「どのログデータをどれくらいの期間保存するか」といった期間の設定がある。また、ログデータの検索を高速に行いたい場合には、インデックスをはじめとした高速化のためのデータ構造について設定をする必要がある。これらのログデータベースの設定は、運用管理者自身が決める必要がある。
【００１０】
しかし、従来の方式では、ログデータベースの設定を決めたり、調整したりすることが複雑で大変であった。なぜなら、サービスやログデータの種類によって、保存しておくべき期間が異なるためである。また、ログデータの種類ごとに、監視時に利用する検索条件や求められる応答性能も異なるためである。さらに、設定変更による効果と影響を定量的に把握できなかったため、運用管理者の要求どおりの設定がなっているか確認することが難しかった。
【００１１】
そのため、従来、ログデータベースでは、十分な期間のデータを残しつつ、性能を確保するために、ストレージなどのリソースを余分に消費していた。あるいはデータの消し過ぎや性能不足が発生していた。これを極力防ぐために、監視のノウハウがある有識者が判別して設定を検討していたため、人手のリソースがかかっていた。その結果、ログデータベースの管理にコストが掛かっていた。
【００１２】
上記特許文献１〜５に記載の方法を監視基盤のログデータベースに適用しても、適切な設定を生成することは難しい。その理由の前提として、ログデータベースは、従来のデータベースの特徴に加えて、時系列情報が付与されたデータを順次蓄積していき、そのようなデータに対して検索を行うという特徴を有している。この特徴のために、従来技術では不都合が生じることがある。例えば、特許文献１〜５では、ログデータベースの一つの特徴的な情報であるデータ利用期間を考慮していない。もし、データ利用期間を用いずに、ログデータの保存設定や、インデックスの設定を自動生成した場合、保存されている全期間に対してインデックスが付与される。しかし、実際には、ログデータやインデックスは特定の期間分しか利用されない。よって、期間外の無駄なインデックスデータによって、リソースが余分に消費されることになる。このように、公知技術を用いて設定を自動生成にしても、人手で利用期間を考慮した設定を再検討する必要があった。また、これらの公知例では、運用管理者が設定の効果と影響を確認し、取捨選択を支援する機能が十分でない。そのため、設定の選択作業にかかる人手のリソースまでは減らすことができなかった。
【００１３】
本発明の解決課題の１つは、監視基盤において、時系列データベースの一つの特徴的な情報であるデータ利用期間を考慮した設定変更案を自動生成し、この設定変更案を運用管理者に提示することにより、運用管理者の設定変更作業を支援し、運用管理者のログ監視にかかるコストを削減することのできる、ログデータベースの設定自動生成方法及び設定自動生成システム並びに監視サーバを提供することにある。
【課題を解決するための手段】
【００１４】
本発明の代表的なものの一例を示すと、次のとおりである。時系列データベースの設定自動生成システムは、時系列データベースと、該時系列データベースを利用する監視サーバとを備え、前記監視サーバは、複数の監視対象に関して、各々、前記時系列データベースを利用した時系列データを格納および検索する機能と、前記監視対象毎の前記時系列データの種類と保存形式に関する設定情報を管理する設定管理機能と、前記各監視対象に関し、時間情報を含む前記設定情報の変更案を生成する機能とを有し、前記監視対象は、サービス提供対象のテナント、データ種別、及び前記テナントの機器を一意に識別するインスタンス名の組合せからなり、前記監視対象毎に、前記時系列データベースの現在の設定情報と、前記時系列データの操作履歴及び前記時系列データの量の情報に基づいて、前記時間情報を含む設定情報の変更案を生成することを特徴とする。
【発明の効果】
【００１５】
本発明を用いた設定変更作業の支援により、監視対象毎にデータ利用期間を考慮した設定変更案を自動生成し、設定情報の変更案を自動生成するので、監視基盤の時系列データベースのリソースの浪費を削減し、かつ、運用管理者の監視にかかるコストを削減できる。
【図面の簡単な説明】
【００１６】
【図１】本発明のログデータベースを適用した監視基盤の例を示す図である。
【図２】本発明の第１の実施形態に係る、ログデータベースの設定自動生成システムを模式的に示す図である。
【図３】第１の実施形態における、ログの生データの例を示す図である。
【図４】ログの圧縮データの例を示す図である。
【図５】ログのインデックスデータの例を示す図である。
【図６】テナント情報の例を示す図である。
【図７】操作履歴の例を示す図である。
【図８】現在の設定情報の例を示す図である。
【図９】データ量情報の例を示す図である。
【図１０】個別ポリシー情報の例を示す図である。
【図１１】全体ポリシー情報の例を示す図である。
【図１２】第１の実施形態における、設定変更案生成のシーケンスである。
【図１３】第１の実施形態における、データ設定情報生成ユニットのデータ設定情報生成処理のフローチャートである。
【図１４】第１の実施形態における、変更後の設定情報の例を示す図である。
【図１５】第１の実施形態における、データ設定情報調整ユニットのデータ設定情報調整処理のフローチャートである。
【図１６】設定変更の差分情報の例を示す図である。
【図１７】第１の実施形態における、インデックス設定情報生成ユニットのインデックス設定情報生成処理のフローチャートである。
【図１８】第１の実施形態における、インデックス設定情報調整ユニットのインデックス設定情報調整処理のフローチャートである。
【図１９】設定変更の全体指標値の例を示す図である。
【図２０】第１の実施形態における、設定変更案の推薦画面表示の例を示す図である。
【図２１】本発明の第２の実施形態に係る、ログデータベースの設定自動生成システムを模式的に示す図である。
【図２２】選択情報の例を示す図である。
【図２３】第２の実施形態における、設定変更の再調整のシーケンスである。
【図２４】第２の実施形態における、選択情報分析ユニットのポリシー情報の自動調整処理のフローチャートである。
【図２５】本発明の第３の実施形態に係る、ログデータベースの設定自動生システムを模式的に示す図である。
【図２６】サービス情報の例を示す図である。
【図２７】障害情報の例を示す図である。
【図２８】第３の実施形態における、設定変更案生成のシーケンスである。
【発明を実施するための形態】
【００１７】
まず、本発明の時系列データベースの設定自動生成システムの概要について、説明する。  
本発明の設定自動生成システムは、以下の実施形態で述べるように、コンピュータシステムによって実現される。このコンピュータシステム上の物理的または仮想的な機器は、複数の企業や組織に対して貸し出されるものとする。本発明では、各企業に対して貸し出される機器の集合を「テナント」と呼ぶ。本発明では、テナントごとにサービスの監視が行われる。本発明におけるコンピュータシステム上の機器はテナント間で共有される。ただし、あるテナントの運用管理者は、機器上に格納される他のテナントの情報を閲覧することはできない。サービスを監視するためのログデータは、各テナントの企業秘密を含む可能性があるためである。
【００１８】
図１は、本発明に係る時系列データベースの設定自動生成システムを適用した監視基盤の例を示す図である。監視基盤では、異なるサービスの異なる種類のログデータを一か所に集約して管理する機能を提供する。また、図１で示した監視基盤は、マルチテナント型の監視基盤となっている。マルチテナント型の監視基盤とは、監視基盤の提供者が、単一あるいは複数の事業者（以下、テナント）に、監視基盤をサービス（Software as a Service）として提供する形態である。
【００１９】
ここで、図１を用いて、監視基盤の機能概要を説明する。監視基盤提供者のシステム200が保有する監視基盤201は、この監視基盤を利用する複数テナント（A）、（B）、（N）の各システム100、110、120と、ネットワーク300を介して接続されている。ここでは、テナントAのシステム100に着目する。テナントAは、このシステム100上にあるサーバ101（A−1〜A−n）によって、テナントA内の各エンドユーザに対するサービスを提供している。監視基盤提供者のシステム200の監視基盤201は、時系列データベース202や監視サーバ203を備えている。テナントAの運用管理者は端末102を介して、監視対象のサーバ101や監視基盤提供者のシステム200にアクセス可能である。監視基盤提供者のシステム200は、テナントAにおける、エンドユーザに提供される各サービスの稼働状況を監視するために、各サーバ101（A−1〜A−n）上で出力あるいは計測された様々なログデータ等の時系列データを、監視基盤201上に順次収集し、時系列データベース202に格納する。本発明では、このような時系列データを格納するデータベースのことを時系列データベースと呼ぶ。監視基盤提供者のシステム200の監視サーバ203は、時系列データの時間情報等の設定管理機能204及び時系列データの利用・分析機能205及び、監視対象毎の上記時間情報等の変更案の生成・登録機能206を有し、かつ、管理・設定用の各種情報を保持した管理・設定用データベース（図２参照）を備えている。
【００２０】
時系列データの利用・分析機能205は、運用管理者の監視要求に応じて時系列データを検索し、その結果を運用管理者の端末102に出力する。変更案の生成・登録機能206は、管理・設定用データベースの情報に基づき、時系列データベース202に格納された時系列データを検索・利用・分析し、テナントAの運用管理者からの時系列データに関する変更の要求に応じて、あるいは監視基盤側自らから、例えば毎月1回、時間情報（例えば保存期間）を含む時系列データの変更案を生成し、その結果を運用管理者の端末102に提示し、承認が得られたら時系列データの時間情報の変更を行う。
【００２１】
なお、本発明では、設定の変更案を生成する単位となる（テナント、データ種別、インスタンス名）の組合せを、「監視対象」と定義する。
【００２２】
このようにして、監視基盤の提供者（運用管理者）は、テナントの運用管理者の要求を満たした、監視対象毎の時系列データの保存に関する設定情報の適切な更新ができる。これにより、監視基盤の運用管理者のログ監視（特に時系列データベースの管理）にかかるコストを削減できる。すなわち、本発明では、監視対象毎にデータ利用期間を考慮した設定変更案を自動生成する。また、設定変更案による効果と影響の判断材料となる指標情報を提示する。これにより、ログデータベース設定検討作業の工数を削減できる。第２に、本発明では、操作履歴から実際に活用されているログデータの種類とその期間を分析して設定変更案を生成する。この案に従って、時系列データの保存方式を設定変更することで、ログデータベース上の無駄なデータを削減できる。また、監視基盤の運用管理者のログ監視強化をすることができる。本発明では、監視対象毎に利用実態に合わせた設定変更案を生成するため、従来発生していたログデータの消し過ぎによる損失（障害対応時工数増大、機会損失）を抑制できる。
【００２３】
なお、以下で述べる本発明の実施形態では、監視基盤の時系列データベースとしてログデータベースを例に説明する。しかし、本発明の実施形態はこのログデータベースに限定されるものではない。時系列順でデータが蓄積される時系列データベースであれば、本発明を適用可能である。例えば、通信分野における通信（通話）履歴（時系列データ）を蓄積する時系列データベースに適用してもよい。通信履歴は利用者ごとに膨大な量のデータが蓄積され、例えば、サービス品質向上のために検索される。そのため、本発明の実施形態に示したログデータベースと利用形態が似ているため、本発明の実施形態の方法で管理可能である。また、本発明は、Webブログの更新情報や非同期型の短文投稿サービスにおける投稿情報、ICカードの購買履歴などの時系列データを格納するマーケティング向けの時系列データベースにも適用可能である。  
以下、本発明の詳細な実施形態を、図面を参照しながら説明する。
【実施形態１】
【００２４】
本発明の第１の実施形態は、運用管理者からの要求を契機に、ログデータベースの設定変更案を自動生成し、その設定変更案を運用管理者に提示する例である。  
図２に、第１の実施形態に係るログデータベースの設定自動生成システムを模式的に示す。図２は、第１の実施形態を実現するコンピュータシステムを模式的に示している  
このコンピュータシステムは、ログデータベース3、管理データベース4、設定変更案データベース5、ログ監視サーバ6、ログ設定管理サーバ8、テナントの運用管理者端末7によって構成される。これらの機器は、物理的な通信回線2を通して管理ネットワーク1に接続される。
【００２５】
ログデータベース3は、運用管理者がサービス提供のための機器のログデータを管理するために用いられる。本実施形態のログデータベース3では、テナント、ログデータの種類、機器ごとに所定の保存方式でログデータを管理する。また、このログデータベース3は、各テナントの複数の運用管理者によって、管理者端末7を介して操作されるものとする。この管理者端末7は運用管理者の数だけ存在してもよい。
【００２６】
管理データベース4は、ログデータベース3を管理するための情報を格納し、後述する各サーバおよび各ユニット（プログラム）によって利用される。管理データベース4は、テナント情報T400、ログデータベース3の現在の設定情報T600、ログデータベース3のデータ量情報T700といったログデータベース3に関する管理情報と、ログデータベース3に対する操作履歴T500などのログデータベース3に関する履歴を保持する。
【００２７】
ログ監視サーバ6は、そのメモリに、サーバ（コンピュータ）を「ログデータの収集・格納ユニット」として機能させるためのログ収集プログラム61と、サーバ（コンピュータ）を「格納済みログの検索・閲覧ユニット」として機能させるためのログ検索・閲覧プログラム63と、サーバ（コンピュータ）を「データ量分析ユニット」として機能させるためのデータ量分析プログラム62を保有している。
【００２８】
「ログデータの収集・格納ユニット」（ログ収集プログラム）61は、サービス提供のための機器からログデータを収集する機能を有する。一般的な収集方法としては、各機器上でSimple Network Management Protocol (SNMP)などのエージェントを動作させ、そのエージェントと「ログデータの収集・格納ユニット」61の間で通信することでログデータを収集する。「ログデータの収集・格納ユニット」61は、受信したログデータを順次ログデータベース3に登録する。
【００２９】
「格納済みログの検索・閲覧ユニット」（ログ検索・閲覧プログラム）63は、運用管理者の監視要求に応じて、ログデータを検索し、その結果を表示する機能を提供する。例えば、「格納済みログの検索・閲覧ユニット」63は、管理者端末7の画面上に表示されたWebブラウザ71からの監視要求を受けると、監視要求に含まれるログデータ検索条件に従って、ログデータベース3から、ログデータを取り出す。そして、取り出したログデータを監視要求に合わせて分析・加工し、その結果をWebブラウザ71上に表示する。また、「格納済みログの検索・閲覧ユニット」63は、このユニットを介してログデータ検索・閲覧操作を行った履歴を管理データベース4に記録する機能を有する。以降では、この履歴を単に「操作履歴」と呼ぶ。
【００３０】
「データ量分析ユニット」（データ量分析プログラム）62は、ログデータベース3に登録されたログデータを分析し、格納されているデータ量（以下、保存データ量と呼ぶ）を分析する機能を有する。この分析方法については後述する。
【００３１】
ログ設定管理サーバ8は、運用管理者がログデータベース3の設定を管理するための機能を提供する。ログ設定管理サーバ8は、そのメモリに、設定管理インタフェース81、設定変更案生成プログラム82を保持している。設定変更案生成プログラム82は、サーバ（コンピュータ）を「設定変更案生成ユニット」として機能させるためのプログラムであり、サーバを「データ設定情報生成ユニット」として機能させるデータ設定情報生成プログラム83、サーバを「データ設定情報調整ユニット」として機能させるデータ設定情報調整プログラム84、サーバを「インデックス設定情報生成ユニット」として機能させるインデックス設定情報生成プログラム85、サーバを「インデックス設定情報調整ユニット」として機能させるインデックス設定情報調整プログラム86、及び、サーバを「変更案表示ユニット」として機能させる変更案表示プログラム87の5つのサブプログラムによって構成される。なお、上記各ユニット（各サブプログラム）の区分はあくまでも一例であり、上記ユニット（サブプログラム）の幾つかを１つに統合しても良く、あるいは、上記ユニット（サブプログラム）の何れかをさらに、機能毎に細分化して構成しても良いことは言うまでもない。
【００３２】
設定管理インタフェース81は、管理者端末7からの監視要求を受けて、その運用管理者が管理するテナントのログデータベース3の設定情報の閲覧、設定の変更を行うためのユニット（プログラム）である。設定情報の閲覧時には、設定管理インタフェース81は、管理データベース4にアクセスし、要求した運用管理者が管理するテナントのログデータベース3の設定情報を取得して、画面に表示する。運用管理者は画面に表示された設定情報に対して、追加・削除・上書きなどの入力をすることで設定変更の要求を行う。運用管理者から設定変更の要求を受けると、設定管理インタフェース81は、管理データベース4にアクセスし、記録された設定情報を更新する。さらに、設定管理インタフェース81は、ログデータベース3にアクセスし、新しい設定を反映する。
【００３３】
「設定変更案生成ユニット」82は、管理データベース4に格納された情報を用いて、テナントのログデータベース3の利用状況を分析し、その状況に合わせた設定変更案を自動生成する。「設定変更案生成ユニット」82は、設定管理インタフェース81を介した運用管理者からの要求を契機に呼び出され、設定変更案を生成し、その変更案を画面に表示する。
【００３４】
本実施形態では、ログ検索・閲覧ユニット62の操作履歴、ログデータベース3のデータ量情報および現在の設定情報等から、ログデータベースの設定変更案を自動生成する手段を提供する。従来のログデータベースに加え、ログ検索・閲覧ユニットに対する操作の履歴情報やログデータベースのデータ量情報および現在の設定情報を格納する管理データベースを用意する。テナントの運用管理者が、ログ検索・閲覧ユニットを介して、ログデータベースの検索・閲覧の操作をすると、ログ検索・閲覧ユニットは、その操作の履歴を管理データベース4に記録する。また、運用管理者が、設定管理インタフェース81を介して、ログデータベースの設定変更をすると、設定管理インタフェースは、その設定情報を管理データベースに記録する。さらに、監視対象装置のログデータがログ収集ユニット61を介して、ログデータベースに収集されると、ログデータ量分析ユニット62が、ログデータベースのデータ量の利用情報を読み取って、管理データベース上に記録する。
【００３５】
設定変更案生成ユニット82は、上記の管理データベース上に記録された情報をもとに、ログデータベースの設定変更案を自動生成する。この自動生成のために、操作履歴や現在の設定情報に含まれるログ利用期間の情報やデータ保存形式といった情報を活用する。また、自動生成した変更案の効果と影響を運用管理者に提示するために、設定変更にかかる時間を評価する指標値と、設定変更に伴う性能を評価する指標値と、設定変更に伴うデータ量を評価する指標値を計算し、その情報を運用管理者に提示する。  
これらの各ユニット83〜87（プログラム）の機能による設定変更案の生成処理については、後ほど詳細に説明する。 
以降では、本実施形態のログデータベース3に格納されるログデータについて、詳細に説明する。  
本実施形態のログデータベース3は、テナントごとのログデータを格納する。図２では、複数のテナントのログデータが一つのログデータベース3上で管理されている例を示す。
【００３６】
また、本実施形態のログデータベース3は、ログデータを表形式で格納する。しかし、本発明の実施形態は、表形式のデータに限定されるものではない。例えば、木構造のデータであっても、テキストのデータであっても、後述する各情報に相当するデータがあれば、本発明を適用できる。
【００３７】
本実施形態のログデータベース3に格納するログデータの例では、生データT100、圧縮データT200、インデックスT300の3種類のデータの保存形式がある。生データT100は、サービス提供のための機器から収集されたログデータそのものである。また、圧縮データT200、インデックスT300は、この生データT100を分析・加工して生成した情報である。
【００３８】
本実施形態では、ログデータには、テナント、ログデータの種類、サービス提供のための機器の情報が付与される。
【００３９】
以下では、ログデータの種類を一意に識別するための名称を「データ種別名」と呼ぶ。データ種別は、OSに関するデータ、そのOS上の複数アプリケーションから共通して利用されるミドルウェア（データベース、Webコンテナなど）に関するデータ、およびアプリケーション固有のデータがある。データ種別名は、「サービス1のWebイベントログ」、「OSのCPU利用率」など、これらの種別が特定できる文字列データである。
【００４０】
また、サービス提供のための機器を一意に識別するための名称を「インスタンス名」とよぶ。インスタンス名としては、ホスト名やIPアドレスなどがあり得る。
【００４１】
本実施形態のログデータベース3では、上記のテナント、データ種別名、インスタンス名を単位に、各保存形式の設定が決まる。以降では、これらテナント、データ種別名、インスタンス名の組を監視対象と呼ぶ。生データT100、圧縮データT200、インデックスT300に格納されるデータは、監視対象によって、互いに関連付けられている。本実施形態では、監視対象として、テナント、データ種別名、インスタンス名を用いているが、あくまでも一例であり、監視対象として別の情報を用いても構わない。
【００４２】
図３は、生データT100の一例である。列T102は、ログを管理するテナント名である。列T103は、ログが出力された時刻を表す。列T104は、データ種別名、列T105は、インスタンス名である。これらの列T102、T104、T105にて示す情報は、監視対象T120である。また、本実施形態の例では、列T102〜T105の情報は、全てのログに必ず付与される必須データである。一方、列T106は、データ種別名、あるいは、インスタンス名ごとに格納される内容が異なるデータを示す。以降では、データ種別名あるいはインスタンス名ごとに格納される内容が異なるデータのことを任意データと呼ぶ。この任意データは、名前（キー）と値のペアとして格納される。以降では、このキーと値をそれぞれ、任意データ名と任意データ値と呼ぶ。このように名前と値のペアで管理することによって、多種多様な形式のログを表に格納することができる。例えば、行T150の列T106の最初のペアでは、ログに、名称「イベント名」、値「Action1」のデータが記録されていたことを示す。列T112は、ログ1件あたりのバイト数を示す。このバイト数は、例えば、このログの各種必須データと任意データのバイト数の合計値である。
【００４３】
ここで、図３では、図中の表現を簡単にするために、表形式に生データを格納する例を示している。しかし、実際には、全てキーと値の組で格納するドキュメント指向データベースに格納しても構わない。その場合にも、この図に示すように表形式の単一の列にキーと値の組を全て格納する場合に比べて大きな違いは無い。
【００４４】
図４は、圧縮データT200の一例である。圧縮データT200は、生データT100を一定の変換手順に従って圧縮したデータである。データを圧縮することで、保存容量を節約することができる。ただし、圧縮データT200がログデータ検索の対象になった場合には、データを一旦解凍してから検索をする必要があるため、生データに比べて検索に時間がかかる。そのため、利用頻度の少ない生データT100や検索性能が遅くてもよい生データT100を圧縮対象とするのが一般的である。この例では、一定期間内に含まれる生データT100をまとめて圧縮し、その圧縮したデータの塊を１つの行（レコード）として格納している。列T201〜T203は、テナント、データ種別名、インスタンス名を示す。これらは、生データT100の列T102〜T104に対応している。列T204とT205は圧縮開始対象時刻と終了対象時刻をそれぞれ示す。列T102〜T104が対応する生データT100のうち、ログ計測時刻が圧縮開始対象時刻と終了対象時刻の間に含まれるデータが、このレコードの圧縮対象データとなる。列T206は、その圧縮対象となった生データの件数を示す。列T207は、圧縮された実際のデータを示す。一般に、圧縮データT200はバイナリ形式であるため、可読困難である。そのため、列T207の記載は省略している。列T208と列T209は、それぞれ圧縮前と圧縮後のバイト数を示す。
【００４５】
図５は、インデックスT300の一例である。インデックスとは、表上の生データ検索を高速化するためのデータである。本実施形態では、インデックスの一例として、表中の一つ以上のデータ列を対象に検索を高速化するためのカラムインデックスを用いることとする。また、インデックスの対象データには、生データT100の必須データ名および任意データ名を指定可能とする。例えば、生データT100の必須データ名である「ログ計測時刻」にインデックスを付与した場合、ログ検索条件に特定の時刻や時刻範囲指定を行ったときに、通常よりも高速に検索が可能である。また、任意データ名である「イベント名」にインデックスを付与した場合、ログ検索条件にイベント名を指定したときに、高速な検索が可能である。インデックスは複数のデータ列についても付与することができる。例えば、「データ種別名, ログ計測時刻, インスタンス名」の順にインデックスを付与した場合には、検索条件で、この順序どおりに、絞込みを行った場合に、高速な検索が可能である。このインデックスでは、データ種別名、ログ計測時刻、インスタンス名の順、データ種別名、ログ計測時刻の順、データ種別名のみで絞込みを行った場合に、高速な検索が可能である。一方、この順序を逸脱した場合、インスタンス名、データ種別名の順に絞込みを行った場合には、このインデックスを利用した高速な検索は行えない。また、インデックスに含まれないデータ列を検索条件に加えた場合には、インデックスに含まれる列で高速な絞り込みを行った後で、含まれない列で通常の絞込みが行われる。列T301〜T303は、テナント、データ種別名、インスタンス名を示す。これらは、生データT100の列T102〜T104に対応している。列T304は、インデックスの対象データを表す情報である。行T350〜T354は、全て、ログデータの監視対象が（テナントA, サービス1のWebイベントログ, ap1server1）である生データ（行T151〜T151）に対して、カラムインデックスを付与した例である。ただし、行T350〜T354では、それぞれ対象データ列が異なっている。このようにインデックスは一つの監視対象に対して、複数設定してもよい。列T305は、インデックスの内部データ構造を示す列である。列T305には、インデックスのデータ構造そのものが格納されていてもよいし、データ構造への参照情報が格納されていてもよい。本実施形態のインデックスのデータ構造には、多くのデータベースで採用されるB+木という木構造を用いることを想定し、その詳細な内部構造については省略する。列T306およびT307は、それぞれこのインデックスデータのバイト数およびデータ件数を表す。
【００４６】
図５では、１つの表の中で、全てのインデックスデータを管理している。しかし、発明の実施形態は、この方式に限定されるものではない。例えば、監視対象ごとに別々のインデックステーブルを用意してもよい。
【００４７】
本実施形態では、以上の３つのデータ保存形式を扱う。しかし、本発明の実施形態は、これらのデータ形式に限定されるものではない。例えば、一定時刻内の複数のログデータを分析した結果をキャッシュとして格納してもよい。
【００４８】
以降では、本実施形態の管理データベース4に格納される情報を詳細に説明する。  
図６は、テナント情報T400の一例である。テナント情報T400は、ログデータベース3を利用するテナントと、そのテナントに属する運用管理者の対応関係を表したデータである。列T402は、運用管理者の属するテナントの名前である。列T403は、運用管理者の名前である。
【００４９】
図７は、ログ検索・閲覧ユニット63に対する操作履歴T500の例を示す図である。列T501は、運用管理者がログ検索・閲覧ユニット63にアクセスした日時である。列T502は、運用管理者が属するテナントの名前である。列T503は、ログ検索・閲覧ユニット63にアクセスした運用管理者の名前である。列T504〜T506は、閲覧時に指定された検索条件を表す情報である。列T504とT505は、検索条件で指定したログ計測時間の範囲である。列T504は計測時刻の最小値、列T505は最大値である。本実施形態では、検索条件で計測時間範囲の指定は必須であるとする。また、指定した計測時刻の最小値以上最大値未満のログデータを検索するものとする。列T506は、ログ計測時刻以外の検索条件である。例えば、行T553は、指定した計測時刻内で、データ種別名が「サービス1のWebイベントログ」に一致し、インスタンス名が「ap1server1」に一致し、リクエスト処理時間が「2000」以上のログデータを検索したときの条件である。列T507は、この条件の検索にかかったサーバ内応答時間である。列T508は、この条件の検索にヒットした件数である。列T509は、この条件の検索に利用したインデックスである。この列には、利用したインデックスの対象データ列の情報が登録される。もし検索にインデックスが利用されなかった場合には、「未使用」が登録される。列510は、この検索の際に圧縮データへのアクセスがあったか否かを示す。圧縮データにアクセスした場合には「有」、アクセスしなかった場合には「無」が登録される。
【００５０】
本実施形態では上記のような検索条件を一例をとして挙げたが、本発明はこの条件のみに限定されるものではない。例えば、検索条件は、ソート条件指定を含んでもよい。
【００５１】
図８は、ログデータベース3の現在の設定情報T600の例を示す図である。ログデータベース3には、この情報に従った設定が反映されている。列T601は、ログデータベースの設定を一意に識別するためのIDである。この設定IDは、設定情報が追加される際に新たに自動付与されるものとする。以降で説明する処理フローでは、設定情報が追加されることがあるが、この設定IDの自動付与処理については説明を省略する。列T602〜T604は監視対象を示す情報である。列T602は、この設定の対象となるログデータを管理しているテナントの名称である。列T603は、この設定の対象となるログデータのデータ種別の名称である。列T604は、この設定の対象となるログデータを出力するインスタンスの名称である。列T605は、この監視対象について指定するデータの保存形式を表す。保存形式には、「生データ」、「圧縮データ」、「インデックス」のいずれかが指定される。列T606は、インデックスを付与する対象データ列を表す。この列は、データ保存形式T605が「インデックス」のときのみ使用される。列T607は、この設定の対象となるデータの保存期間である。本実施形態では、保存期間には、[180日前から, 現在まで]というように、現在時刻を起点とした時刻範囲が指定される。ログデータベース3には、この保存期間の範囲内のログデータのみが格納され、範囲外のログデータは順次削除される。
【００５２】
ここで、生データ設定、圧縮データ設定、インデックス設定について、それぞれ例を用いて説明する。行T650は、監視対象を示す情報が（テナントA, サービス1のWebイベントログ, ap1server1）である生データを、180日前から現在まで保存する設定である。180日より古くなったログデータは、圧縮データ設定がされている場合には順次圧縮され、そうでない場合にはログデータベース3上から順次削除される。行T651は、行T650と同じ監視対象の圧縮データを360日前から180日前まで保存する設定である。このように、圧縮データの保存期間の終了時点は、生データの保存期間の開始時点と連続するように設定される。行T652〜T654は、行T650と同じ監視対象を示す情報を持つ生データに対するインデックス設定である。
【００５３】
図９は、ログデータベース3のデータ量情報T700の例を示す図である。このデータ量情報T700には、ログデータ分析ユニット62がログデータベース3のデータを分析して、保存データ量と件数を集計した結果が格納される。列T701は、ログデータベースの設定を一意に識別IDである。列T701〜T705は監視対象およびデータ保存形式を示す情報である。これらの列T701〜T705は、設定情報T600の列T601〜T605に対応している。列T706は、この設定のログデータのデータ保存容量である。この列には、ログデータベース3上に格納されているデータ保存容量を集計した結果が格納される。ここで、本実施形態におけるデータ保存形式ごとにデータ保存容量の計算方法について述べる。データ保存形式T705が「生データ」の場合には、ログデータ分析ユニット62がログデータベース3上の生データT100を参照し、監視対象を示す情報T102, T104, T105が、T701, T702, T703と一致する行を取り出し、そのバイト数T112をカウントする。「圧縮データ」の場合には、ログデータ分析ユニット62がログデータベース3上の圧縮データT200を参照し、監視対象を示す情報T201〜T203が、T701, T702, T703と一致する行を取り出し、その圧縮後バイト数T209をカウントする。「インデックス」の場合には、ログデータ分析ユニット62がログデータベース3上のインデックスT300を参照し、監視対象と対象データ列T301〜T304が一致するインデックスのバイト数T306を取得する。列T707は、この設定のログデータのデータ保存件数である。件数についても保存容量と同様の方法で集計する。ただし、バイト数ではなく行数をカウントする。「生データ」の場合には単純に行数を、「圧縮データ」の場合には圧縮対象データ件数T206を、「インデックス」の場合には、インデックスのデータ件数T307をそれぞれカウントする。
【００５４】
図１０は、設定変更の個別ポリシー情報T900の例を示す図である。個別ポリシー情報T900は、各テナントが、ログデータベース3の設定変更の際に、変更される個々の設定に対して求める水準を記述したデータである。本実施形態では、設定変更案生成ユニット82が設定変更案を作成する際には、変更される個々の設定がこの水準を満たすかどうか判定し、水準を満たす設定だけを設定変更案として提示する。本実施形態では、個別ポリシー情報T900はテナントごとに一つ以上設定されるものとする。もし、一つのテナントで複数の個別ポリシー情報T900が設定されていた場合には、変更される設定が、複数の個別ポリシー情報T900のうち、いずれかの基準を満たせばよいこととする。列T901は、個別ポリシー情報T900を一意に特定するためのIDを示す。列T902は、このポリシーを設定したテナントの名称である。列T903〜T905は、テナントが変更される個々の設定に対して求める指標の水準である。本発明では、設定変更案を生成する際に、その変更される個々の設定を評価する三種類の指標値を計算する。その計算した指標値が、列T903〜T905に示す水準を満たした場合にその設定を採用する。以降では、変更される個々の設定を評価する指標のことを、個別指標と呼ぶこととする。
【００５５】
列T903は、設定変更にかかる時間すなわち設定変更に必要な時間を評価する個別指標M1の水準である。設定変更にかかる時間は、ログデータベース3の設定を決める上で重要な指標である。なぜなら、設定変更時は、通常時よりもコストがかかり、機会損失のリスクが高まるので、その期間を極力短くしたいためである。設定変更が発生すると、ログデータの一括追加・削除処理などのデータ処理が行われる。このデータ処理中は、ログデータ不整合や、データのロックによる性能劣化が発生する可能性がある。その影響を避けるため、設定変更は、システム稼働停止日や休日など、特定の時間帯に行うことが一般的である。その時間帯の内に設定変更のための処理が完了するかは、運用管理者にとって大きな指標となる。本実施形態では、指標M1の一例として、設定変更にかかる想定処理時間を用いる。列T903には、指標M1を評価した指標値が満たすべき条件が設定される。例えば、行T950は、ある個別ポリシーにおいて、指標M1の水準が「設定変更にかかる時間が60分未満」に設定されていることを示す。この場合には、60分以上かかるログデータベースの設定は、このポリシーを満たさない設定と判断される。なお、もし、指標に対して水準を設ける必要がない場合には「無制限」を設定する。これは、以降で説明する指標も同様である。
【００５６】
本実施形態では、指標M1に処理時間を用いるが、この評価方法に限定されるものではない。例えば、設定変更に、人手の作業工数を要し、その測定と予測をする手段があるのであれば、作業工数を指標M1に含めてもよい。
【００５７】
列T904は、設定変更に伴う性能の変化を評価する個別指標M2の水準である。性能は、ログデータベース3の設定を決める上で重要な指標である。なぜなら、性能は監視作業にかかる時間に影響するため、監視業務を遂行する上で、一定以上の性能が必要となるためである。例えば、サービス監視においては、一般に障害発生時の復旧時間目標が決められている。障害発生時には、ログデータベース3は原因分析のために利用される。そのため、障害復旧にかかる時間は、ログデータ検索にかかる応答時間に依存する。したがって、監視業務に支障を出さないために、ログデータベース3には、一定の応答性能が求められる。本実施形態の例では、指標M2の一例として、設定変更前後での応答時間の増減量を用いる。この応答時間には、検索ヒット件数N件あたりのサーバ内応答時間の平均値を用いる。以降では、検索ヒット件数N件あたりの応答時間を便宜上、基準応答時間と呼ぶことにする。列T904には、指標M2を評価した指標値が満たすべき条件が設定される。例えば、行T950は、ある個別ポリシーにおいて、指標M2の水準が「設定変更に伴う基準応答時間の減少が１秒以上」に設定されていることを示す。この場合には、応答時間が１秒以上改善されない設定は、このポリシーを満たさない設定と判断される。
【００５８】
上記は一例であり、指標M2はこの評価方法に限定されるものではない。例えば、指標に用いる応答時間として、サーバ内応答時間以外にも、クライアント内処理やネットワークを含めた応答時間を用いてもよい。また、性能の増減量として、応答時間ではなく、CPUの利用率などを用いてもよい。あるいは、もし測定と予測をする手段があれば、運用管理者の監視作業の実施時間を指標にしてもよい。
【００５９】
列T905は、設定変更に伴うデータ量の変化を評価する個別指標M3の水準である。データ量は、ログデータベース3の設定を決める上で重要な指標である。なぜなら、ログデータ量が多くなるほど、ログデータベース3の維持管理にコストがかかるためである。本実施形態の例では、指標M3の一例として、設定変更前後での保存データ量の増減量を用いる。この保存データ量には、設定した保存期間分のログデータがたまった場合に予想される保存データ量を用いる。以降では、この保存データ量を便宜上、基準保存データ量と呼ぶことにする。列T904には、指標M3を評価した指標値が満たすべき条件が設定される。例えば、行T951は、ある個別ポリシーにおいて、指標M3の水準が「設定変更に伴う基準保存データ量の削減が1GB以上」に設定されていることを示す。この場合には、保存データ量が1GB以上改善されない設定は、このポリシーを満たさない設定と判断される。
【００６０】
上記は一例であり、指標M3はこの評価方法に限定されるものではない。例えば、単位時間あたりの保存データ量を用いても構わない。
【００６１】
なお、本実施形態においては、各個別ポリシーの指標M1, M2, M3の三つの水準をすべて満たしたログデータベース3設定のみ、その個別ポリシーを満たした設定であるとみなす。例えば行T951のポリシーを満たすログデータベース3設定は、「設定変更にかかる時間が60分未満」かつ「設定変更に伴う基準応答時間の増加が１秒未満」かつ「設定変更に伴う基準保存データ量の削減が1GB以上」の設定である。
【００６２】
図１１は、設定変更の全体ポリシー情報T800の例を示す図である。全体ポリシー情報T800は、各テナントが、ログデータベース3の設定変更の際に、設定変更案の全体に対して求める水準を記述したデータである。本実施形態では、設定変更案生成ユニット82が設定変更案を作成する際には、設定変更案の全体がこの水準を満たすかどうか判定し、水準を満たす場合に、その案を提示する。本実施形態では、全体ポリシー情報T800は、テナントごとに一つのみ設定されることとする。列T801は、全体ポリシー情報T800を一意に特定するためのIDを示す。列T802は、このポリシーを設定したテナントの名称である。列T802〜T805は、テナントが設定変更案の全体に対して求める指標の水準である。本発明では、設定変更案を生成する際に、その変更案の全体を評価する三種類の指標値を計算する。その計算した指標値が、列T803〜T805に示す水準を満たした場合に、その設定を採用する。以降では、変更案の全体を評価する指標のことを、全体指標と呼ぶこととする。
【００６３】
列T803は、設定変更にかかる時間を評価する全体指標M4の水準である。この指標は、個別ポリシー情報の指標M1と対応しており、内容は概ね同様であるが、全ての設定変更にかかる総時間で評価する点が異なる。
【００６４】
列T804は、設定変更に伴う性能の変化を評価する全体指標M5の水準である。この指標は、個別ポリシー情報の指標M2と対応しており、内容は概ね同様であるが、設定変更の全体性能で評価する点が異なる。すなわち、本実施形態の例では、指標M5として、変更後の全設定についての基準応答時間の平均値を用いる。
【００６５】
列T805は、設定変更に伴うデータ量の変化を評価する全体指標M6の水準である。この指標は、個別ポリシー情報の指標M3と対応しており、内容は概ね同様であるが、変更後の全ログデータの保存データ量の合計値で評価する点が異なる。
【００６６】
なお、本実施形態においては、個別ポリシーと同様に、設定変更案は、全体ポリシーの指標M4, M5, M6の三つの水準をすべて満たす必要がある。例えば行T850に示すテナントAの設定変更案は、「全設定変更にかかる時間の合計が300分未満」かつ「変更後の全設定についての基準応答時間の平均値が10秒未満」かつ「変更後の全ログデータ保存データ量が100GB未満」である必要がある。また、T851に示すテナントBの設定変更案は、「全設定変更にかかる時間の合計が300分未満」かつ「変更後の全設定についての基準応答時間の平均値が5秒未満」かつ「変更後の全ログデータ保存データ量が50GB未満」である必要がある。
【００６７】
上記で用いる全体指標は一例であり、本発明の適用は、これらの評価方法に限定されるものではない。
【００６８】
本実施形態では、全体ポリシー情報T800は一つのテナントに一つずつとしているが、個別ポリシー情報T900と同様に、一つのテナントに対して全体ポリシー情報T800が複数存在しても構わない。
【００６９】
本実施形態では、個別ポリシー情報T900と全体ポリシー情報T800は、テナントを単位に設定しているが、本発明の実施形態はこの方法に限定されない。例えば、ポリシー情報は、テナントだけでなく、データ種別名やインスタンス名ごとに細分化して設定しても構わない。あるいはデータ保存形式ごとに設定しても構わない。例えば、個別ポリシー情報T900において、データ種別ごとのポリシーを決めておき、その水準値に、複数インスタンスの指標値の合計値を用いてもよい（例：あるデータ種別の全てのインスタンスの基準保存データ量の合計値が10GB未満）。
【００７０】
また、これらのポリシー情報は、運用管理者からの明示的な入力で設定しても良いし、機械的に自動設定しても良い。
【００７１】
本発明は、指標値さえ計算すれば、ポリシー情報を一切利用せずに設定変更案を生成することも可能である。例えば、予めどの指標を優先するか決めておき、優先度が高い指標の値がより良い設定から順に選択することで、設定変更案を生成しても良い。
【００７２】
図１２は、本発明の第１の実施形態における設定変更案生成処理のシーケンスを示す。  
ログ設定管理サーバ8の設定管理インタフェース81は、テナントの管理者端末7からの設定見直し要求を受けて、その運用管理者が管理するテナントのログデータベース3の設定情報の閲覧、設定の変更を行う。ログ設定管理サーバ8の設定変更案生成ユニット82（データ設定情報生成ユニット83、データ設定情報調整ユニット84、インデックス設定情報生成ユニット85、インデックス設定情報調整ユニット86、及び変更案表示ユニット87）は、設定管理インタフェース81を介した運用管理者からの要求を契機に呼び出され、管理データベース4に格納された情報を用いて、テナントのログデータベース3の利用状況を分析し、その状況に合わせた設定変更案を自動生成し、その変更案をテナントの管理者端末7の画面に表示する。テナント管理者により承認された変更案は、設定変更案データベース5に格納される。
【００７３】
以下では、図１２中の個々のユニットについて、詳細なフローチャートを説明する。併せて、設定変更案生成処理に伴い生成され設定変更案データベース5に格納される情報についても詳細に説明する。
【００７４】
図１３は、データ設定生成ユニット83によるデータ設定生成処理のフローチャートである。この処理では、生データの設定情報と圧縮データの設定情報を生成する。  
データ設定生成ユニット83は、設定管理インタフェース81を介して、運用管理者から設定見直し要求を受けると、指定されたテナントの見直し対象期間中のログ検索・閲覧ユニット63の操作履歴T500を取得する（S101）。ここで、本実施形態では、見直し対象期間は、前回設定変更が実施された日時から、現在までの期間であると想定した例を述べる。この期間は1ヶ月程度であると想定する。ただし、本発明の実施形態は、この見直し対象期間に限定されるものではない。例えば、設定変更ごとに各履歴が保存されているのであれば、第１の実施形態と同様の方法で、複数の設定変更を跨いだ長期間の見直しも実施できる。
【００７５】
次に、データ設定生成ユニット83は、S101で取得した操作履歴T500から、監視対象（テナント, データ種別名, インスタンス名）の一意な組合せを列挙する（S102）。操作履歴T500上で、テナントは、列T502から、データ種別名とインスタンス名は、列T506から取得可能である。
【００７６】
以下、データ設定生成ユニット83は、S102で列挙した監視対象について、S103〜S114の処理を繰り返す。
【００７７】
データ設定生成ユニット83は、S102で列挙した監視対象から未検証の監視対象S_KEYを選択し、操作履歴T500からその監視対象を示す情報を持つ履歴のグループGRPを取得する（S103）。 続いて、データ設定生成ユニット83は、このGRPを圧縮可能なグループGRP_COMと、そうでないグループGRP_RAWの二つのグループに分ける（S104）。その判断方法としては、例えば、操作履歴T500において、圧縮データへのアクセスT510が「有」でかつ、検索にかかった応答時間T507が閾値T1未満であれば、その操作履歴T500（の検索対象）を圧縮可能なデータと判断する。閾値T1は予め個別に決められていても良い（例：20秒）し、そうでなくても良い。例えば、別の手段で計算してもよいし、全体ポリシー情報T800の指標M5の水準をT1として用いても良い。ここで閾値を設ける理由は、圧縮データを検索することで応答時間が悪すぎる状況を避けるためである。そのため、閾値で限定せずに、圧縮データへのアクセス有無だけによって判別してもよい。また、この判定自体を行わず、すべての操作履歴を生データの設定情報の生成に利用する方法でもよい。
【００７８】
S105〜S109では、GRP_RAWの操作履歴T500をもとに生データの設定情報を生成する。この処理を行うことで、実際にアクセスしたデータに合わせた設定を生成することができる。まず、データ設定生成ユニット83は、監視対象S_KEYの生データの設定情報CONF＿RAWを生成する（S105）。ここでCONF_RAWの初期値としては、（監視対象＝ S_KEY, データ保存形式＝生データ, 保存期間＝[制限なし,現在まで]）を指定する。これは、保存期間に特に制限がされていない設定状態を表す。次に、データ設定生成ユニット83は、GRP_RAWに含まれる各履歴について、ログ利用日数TR＿RAWを計算する（S106）。ここでTR_RAWは、操作履歴T500の（検索条件で指定したログ計測時間の最小値−アクセス日時）によって求める。この計算により、アクセス日時を起点として、どれくらい古い期間のログデータにアクセスしたかが求まる。続いて、データ設定生成ユニット83は、S106で計算した各履歴のTR_RAWのうち、最大日数TRM_RAWを計算する（S107）。そして、データ設定生成ユニット83は、CONF_RAWの保存期間に[TRM_RAW日前から, 現在まで] を設定する（S108）。最後に、データ設定生成ユニット83は、CONF_RAWを生成した設定情報として登録する（S109）。なお、この処理においては、GRP_RAWに履歴が1件も存在しない場合が考えられる。その場合には、S105〜S109の処理を省略する。
【００７９】
S110〜S114では、GRP_COMの操作履歴T500をもとに、圧縮データの設定情報を生成する。大まかな処理の流れは、生データ設定の生成S105〜S109と同様である。この処理を行うことで、実際にアクセスした圧縮可能なデータに合わせた設定を生成できる。まず、データ設定生成ユニット83は、監視対象S_KEYの圧縮データの設定情報CONF_COMを生成する（S110）。ここでCONF_COMの初期値としては、（監視対象＝ S_KEY, データ保存形式＝圧縮データ, 保存期間＝[制限なし,現在まで]）を指定する。これは、保存期間に特に制限がされていない設定状態を表す。次に、データ設定生成ユニット83は、GRP_ COMに含まれる各履歴について、ログ利用日数TR_COMを計算し、その最大日数TRM_COMを計算する（S111〜S112）。この計算方法は、TR_RAWおよびTRM_COMと同様である。そして、データ設定生成ユニット83は、CONF_COMの保存期間に[TRM_COM日前から, TRM_RAW日前まで]を設定する（S113）。ここで、保存期間の終了時点を、生データ設定の保存期間の開始時点に設定しているのは、データの保存期間を連続させるためである。最後に、データ設定生成ユニット83は、CONF_COMを生成した設定情報として登録する（S114）。なお、この処理においては、GRP_ COMに履歴が1件も存在しない場合が考えられる。その場合には、S110〜S114の処理を省略する。
【００８０】
図１４は、運用管理者からの設定見直し要求を受けて、変更された後の設定情報T1200の例を示す図である。列T1201は、ログデータベースの設定を一意に識別するためのIDである。列T1202〜T1204は監視対象を示す情報である。列T1205はこの監視対象について指定するデータの保存形式を表す。列T1206はインデックスを付与する対象データ列を表す。列T1207はこの設定の対象となるデータの保存期間である。
【００８１】
変更後の設定情報T1200は、設定変更案生成ユニット82によって生成されたもので、前述のポリシーの全体指標、ならびに個別指標を満たしている設定である。行T1250は、監視対象を示す情報が生データ、行T1251は監視対象の圧縮データの保存期間の設定である。行T1252〜T1254は、行T1250と同じ監視対象を示す情報を持つ生データに対するインデックス設定である。この情報を構成する列の内容は、図８に示した現在の設定情報と同様のため、説明は省略する。
【００８２】
本実施形態における圧縮データの設定情報の生成処理では、アクセス状況に基づいて保存期間の開始時点を計算しているが、この計算は行わず保存期間の開始時点「制限なし」に設定しても良い。制限を設定しないことで、データ消し過ぎのリスクを抑制できる。この場合には、圧縮データは自動削除されず、運用管理者の操作によってのみ削除される。
【００８３】
また、本実施形態におけるデータの設定情報の生成処理では、設定情報の保存期間は、操作履歴T500の（検索条件で指定したログ計測時間の最小値−アクセス日時）の最大値を指定しているが、この最大値に安全係数（例：1.2倍）を掛けた値を用いても構わない。これはもし、ログを使い始めたばかりで利用日数が増える可能性がある場合などに有効である。
【００８４】
図１５は、データ設定調整ユニット84によるデータ設定調整処理のフローチャートである。データ設定調整ユニット84は、図１３に示したデータ設定生成処理が終わった後で、生成した設定情報T1200が設定変更のポリシーを満たしているかの判定を行い、生成した設定情報T1200を調整することで、最終的な設定変更案を生成する。その流れを以下に説明する。
【００８５】
まず、データ設定調整ユニット84は、管理データベース4から現在の設定情報T600（図８）を、データ設定生成ユニット83から生成した設定情報T1200（図１４）を、それぞれ取得する（S201）。次に、データ設定調整ユニット84は、S201で取得した現在の設定情報T600と生成した設定情報T1200とから、監視対象（テナント, データ種別名, インスタンス名）の一意な組合せを列挙する（S202）。
【００８６】
以下、データ設定調整ユニット84は、S202で列挙した監視対象について、S203〜S215の処理を繰り返す。
【００８７】
データ設定調整ユニット84は、S202で列挙した監視対象から未検証の監視対象S_KEYを選択する（S203）。そして、データ設定調整ユニット84は、現在の設定情報T600からS_KEYと一致する生データの設定情報Aと圧縮データの設定情報Aを取得する（S204）。 また、同様に生成した設定情報T1200からS_KEYと一致する生データの設定情報Bと圧縮データの設定情報Bを取得する（S205）。
【００８８】
次に、データ設定調整ユニット84は、生成した生データの設定情報Bの保存期間が現在の生データの設定情報Aよりも短い場合に、その差の期間について圧縮データを保存するような、圧縮データの設定情報の別候補Cを生成する（S206〜S207）。これは、生データの保存期間を減らすことによるデータの消し過ぎの発生を緩和するために行う。圧縮データの設定情報Cの設定値には、（監視対象＝ S_KEY, データ保存形式＝圧縮データ, 保存期間＝[現在の生データの設定情報Bで保存が開始する日時から,生成した生データの設定情報Aで保存が開始する日時まで]）を与える。
【００８９】
さらに、データ設定調整ユニット84は、上記で示した生データの設定情報と圧縮データの設定情報の中から、最も良い設定の組合せを見つけ、それを監視対象S_KEYの変更後の設定情報として登録する（S208〜S215）。まず、S204〜S207で示した生データの設定情報 と圧縮データの設定情報の六つの組合せ（以下、設定候補ペア）を次のように生成する（S208）。
【００９０】
（設定候補ペア＝（A, a）（A, b）（A, c）（B, a）（B, b）（B, c）） 
続いて、データ設定調整ユニット84は、S208の設定候補ペアについて、S209〜S212の処理を繰り返す。
【００９１】
データ設定調整ユニット84は、S208の設定候補ペアから、未検証のペア（生データの設定情報X, 圧縮データの設定情報x）を選択する（S209）。そして、データ設定調整ユニット84は、圧縮データの設定情報xの保存期間の終了時点に、生データの設定情報Xの保存期間の開始時点を設定する（S210）。これは圧縮データと生データの設定における保存期間を連続させるための処理である。次に、データ設定調整ユニット84は、生データの設定情報Xと圧縮データの設定情報xの変更区分を判定する（S211）。現在の設定情報が空の場合には変更区分「追加」、設定候補ペアから選択した設定情報（Xまたはx）が空の場合に変更区分「削除」、両方が空でない場合には変更区分「変更」と判定する。さらに、変更区分「変更」の場合に、設定情報が完全に一致するときには、変更無しなので、以降の処理を省略する。
【００９２】
次に、データ設定調整ユニット84は、生データの設定情報Xと圧縮データの設定情報xの指標値M1, M2, M3をそれぞれ計算する（S212）。以降では各指標値の計算方法の一例をあげる。
【００９３】
本実施形態の指標M1には、前述のとおり、設定変更にかかる想定処理時間を用いる。この処理時間の計算方法の例を示す。本実施形態では、仮に、設定変更の区分や対象ごとの性能単価および傾向が既知である。その性能単価と、現在の設定情報T600、変更後の設定情報（ここでは設定候補ペアから選択した設定情報）、データ量情報T700を用いて、以下の式1−1、1−2に従って計算することにする。
【００９４】
設定変更にかかる想定処理時間＝
データ1件あたりの設定変更にかかる性能単価×処理対象となるデータ件数
（式1−1）
処理対象となるデータ件数＝
データ量情報T700で設定情報と同じ設定ID T701の保存データ件数T707
×ABS（変更後の設定情報の保存期間の日数
−現在の設定情報の保存期間の日数）÷現在の設定情報の保存期間の日数
（ここで関数ABS()はカッコ内の絶対値を計算する関数である）
（式1−2）
これらの計算式に実際の値を当てはめた例を示す。まず、生データの削除処理において、1件あたりの削除処理の性能単価は1ミリ秒/件であるとする。また、現在の設定情報の保存期間の日数が100日間、変更後の設定情報の保存期間が80日間であるとする。さらに、保存データ件数が1000万件であるとする。その場合には、設定変更にかかる想定処理時間は、「1ミリ秒/件×1000万件×ABS（80日間―100日間）÷100日間＝2000秒＝33分」となる。
【００９５】
本実施形態では、性能単価が既知である場合を例に挙げたが、本発明はそれに制限されるものではない。例えば、性能単価が未知の場合には、性能単価を機械的に把握するために、少量のログデータを用いて実機上で追加や削除処理の行い、その時間の計測結果から性能単価を求めても良い。また、傾向が未知である場合には、多変量解析手法を用いて、過去の設定変更実績の傾向を分析してもよい。例えば、処理時間が保存中のデータ量に依存する場合には、過去の設定変更実績を統計解析することで予測計算式を求めて、その式を指標M1の計算に利用してもよい。
【００９６】
本実施形態の指標M2には、前述のとおり、設定変更に伴う基準応答時間の変化量を用いる。本実施形態では、変更後の応答時間は、過去の操作履歴の傾向から分析できるものとし、操作履歴T500、現在の設定情報T600、変更後の設定情報（ここでは設定候補ペアから選択した設定情報）、データ量情報T700、を用いて、以下の式に従って計算する。
【００９７】
基準応答時間の変化量＝
変更後の設定情報の基準応答時間―現在の設定情報の基準応答時間
（式2−1）
現在の設定情報の基準応答時間＝
この設定情報と同じ監視対象の全ての操作履歴の基準応答時間の平均値
（式2−2）
操作履歴の基準応答時間＝
検索にかかった応答時間×（基準となる件数N件÷検索でヒットした件数）
（式2−3）
変更後の設定情報の基準応答時間＝
現在の設定情報の基準応答時間×変更による性能改善係数
（式2−4）
変更による性能改善係数＝
func（変更後に利用されるインデックスのデータ列の数, 
変更後における圧縮データへのアクセス）
（式2−5）
ここで、変更による性能改善係数は、0〜1の数値で表現されるものとし、数値が小さいほど性能が良くなることを表す。この係数を求めるための関数func ()は、過去の操作履歴の検索に利用したインデックスのデータ列数、および圧縮データへのアクセス有無の情報を入力パラメータとした性能傾向の統計分析（例えば、重回帰分析）によって求めた予測式である。
【００９８】
本実施形態の指標M2の計算方法は一例であるため、他の計算方法を用いても構わない。例えば、ニューラルネットワークなどの別の機械学習の手法を用いても構わない。
【００９９】
本実施形態の指標M3には、前述のとおり、設定変更前後での保存データ量の変化量を用いる。本実施形態では、変更後の保存データ量は、データ量情報T600の傾向から分析できるものとし、現在の設定情報T600、変更後の設定情報（ここでは設定候補ペアから選択した設定情報）、データ量情報T700を用いて、以下の式に従って計算する。
【０１００】
基準保存データ量の変化量＝
データ情報T700中で設定情報と同じ設定ID T701を持つ保存データ量T706
×ABS（変更後の設定情報の保存期間の日数−現在の設定情報の保存期間の日数）
÷現在の設定情報の保存期間の日数
（式3−1）
上記の計算において、設定変更の区分が追加の場合には、データ情報T700中で設定情報と同じ設定ID T701を持つ保存データ量が存在しない。その場合には、以下の代替手段から推測することとする。ここで推測を可能とするために、本実施形態では、生データを圧縮データに変換する圧縮率や、インデックスを生成する場合の生データと比べたデータ量の比率が既知であるとする。同じ監視対象の保存データ量がある場合には、その数値を用いてデータ量を取得して、先の圧縮率やデータ量の比率を乗じた値を用いる。また、同じ監視対象の保存データ量が一つもない場合には、他の全ての監視対象の保存データ量の平均値を用いることとする。
【０１０１】
本実施形態の指標M3の計算方法は一例であるため、他の計算方法を用いても構わない。例えば、データ量情報T700を計算する際に保存期間も計算しておき、指標M3の計算時に考慮すれば、評価の精度をより上げることができる。
【０１０２】
以上の方法で個別指標の計算が終わった後で、データ設定調整ユニット84は、監視対象S_KEYに対応する個別ポリシー情報T900を取得する（S214）。そして、全ての設定候補ペアのうち、個別ポリシーの条件を満たし、かつ指標値が最も良い設定情報を、変更後の設定情報T1200として登録する。また、現在の設定情報T600、変更後の設定情報T1200、および指標値M1, M2, M3を設定変更の差分情報として登録する（S215）。ここで、指標値が最も良い設定情報の選び方としては、例えば、予め決めたデータ保存形式と個別指標の優先順位（例：データ保存形式としては生データの設定情報を優先し、さらに、指標はM2、M3、M1の順に優先する）に従って設定候補ペアをソートして、その最上位の設定情報を選択する方法がある。
【０１０３】
以上のS203〜S216を繰り返した結果として、変更後の設定情報T1200と設定変更の差分情報T1100が登録される。その後で、データ設定調整ユニット84は、この設定変更が全体ポリシーを満たしているかどうか判別する。まず、監視対象S_KEYに対応する全体ポリシー情報T800を取得する（S217）。そして、設定変更の差分情報T1100から、全体指標値M4, M5, M6を計算する（S218）。以降では各指標値の計算方法の一例をあげる。
【０１０４】
本実施形態の指標M4は、全ての設定変更にかかる総時間で評価する。計算方法はS212の指標M1に示した方法とほぼ同様である。ただし、指標M4では、全ての設定変更にかかる総時間を計算する。そのため、全ての設定変更にかかる想定処理時間（式1−1で求める）の合計値を計算し、その結果を指標M4の値とする。
【０１０５】
本実施形態の指標M5の計算方法はS212の指標M2に示した方法とほぼ同様である。ただし、指標M5では、変更後の全設定についての基準応答時間の平均値を計算する。そのため、まず、全ての変更後の設定情報T1200について、式2−4を用いて、変更後の設定情報の基準応答時間を計算する。そして、求めた全基準応答時間の平均値を計算し、その結果を指標M5の値とする。ここで、式2−5の入力値となる「変更後に利用されるインデックスのデータ列」や「変更後における圧縮データへのアクセス有無」は、操作履歴T500中の検索条件T504〜T506と変更後の設定情報T1200の比較から推定することとする。例えば、操作履歴T500中の検索条件T504〜T506に使われているデータ列と、変更後の設定情報T1200中のインデックス対象データT600のデータ列が最も一致する設定情報が、その操作履歴T500の検索において、利用されるインデックスのデータ列であるとみなす。
【０１０６】
本実施形態の指標M6の計算方法はS212の指標M3に示した方法とほぼ同様である。ただし、指標M6では、変更後の全ログデータの保存データ量の合計値を計算する。そのため、式3−1を修正した以下の式3−2を用いて、変更後の設定情報T1200の個別の保存データ量を計算し、その合計値を求める。
【０１０７】
基準保存データ量＝
データ情報T700中で設定情報と同じ設定ID T701を持つ保存データ量T706
×変更後の設定情報の保存期間の日数÷現在の設定情報の保存期間の日数
（式3−2）
次に、データ設定調整ユニット84は、計算した全体指標値M4, M5, M6と、全体ポリシー情報T800を比較し、変更後の設定情報T1200が水準を満たすかどうか判別する（S219）。もし水準を満たす場合には、設定変更の全体指標値T1300としてM4, M5, M6を登録する（S220）。もし水準を満たさない場合、この変更案は不十分とみなし、設定変更の差分情報T1200を削除する。変更後の設定情報T1200としては変更前の設定情報T600をそのまま利用する（S221）。 
本実施形態のS221では、全体の指標値が全体ポリシー情報T800を満たさない場合、変更案として不十分とみなして処理を打ち切り、変更前の設定情報T600をそのまま利用している。処理を打ち切っている理由は、計算量を少なくするためである。そのため、計算量を考慮しなくてよい場合には、S215までの計算結果を残しておき、S215で選択しなかった別設定を登録し直して、再計算してもよい。あるいは、個別ポリシー情報T900を満たす全ての設定の組合せについて、全体の指標値を計算して、その中から、最も全体の指標値が良い設定を採用してもよい。
【０１０８】
また、全体のポリシーを満たすか否かの判定処理は、個々では実施せずに、後述のインデックス設定情報の調整処理まで終わった後に実施してもよい。
【０１０９】
さらに、指標M1〜M6を全て判定に利用する必要はない。例えば、指標M2, M5は、後に決まるインデックス設定にも依存するため、このデータ設定調整処理の中では省略し、インデックス設定調整処理の際に、まとめて、指標M2, M5の計算と判定を実施してもよい。
【０１１０】
図１６は、設定変更の差分情報T1100の例を示す図である。設定変更の差分情報T1100は、設定変更案生成ユニット82によって生成される。本実施形態では、設定変更の差分情報T1100には、今回の設定変更案にて変更される設定のみが登録される。列T1101〜T1111では、変更前（すなわち現在）の設定情報T600と変更後の設定情報T1200を示す。列T1101は、ログデータベース3の設定を一意に識別するためのIDである。列T1102〜T1104は監視対象を示す情報である。列T1102は、この設定の対象となるログデータを管理しているテナントの名称である。列T1103は、この設定の対象となるログデータのデータ種別の名称である。列T1104は、この設定の対象となるログデータを出力するインスタンスの名称である。列T1105は、この監視対象について指定するデータの保存形式を表す。列T1101〜T1105は、現在の設定情報T600の列T601〜T605、変更後の設定情報T1200の列T1201〜T1205に対応する。列T1107とT1108は、それぞれ変更前の設定情報におけるインデックス対象データと保存期間であり、現在の設定情報T600の列T606〜T607に対応する。もし、設定が追加である場合には、対応する現在の設定情報T600は存在しないため、これらの列には「−」が登録される。列T1110とT1111は、それぞれ変更後の設定情報T1200におけるインデックス対象データと保存期間であり、現在の設定情報T1100の列T1106〜T1107に対応する。もし、設定が削除である場合には、対応する変更後の設定情報T1200は存在しないため、これらの列には「−」が登録される。列T1112は、この設定変更の変更区分である。変更区分には、「変更」「削除」「追加」のいずれかの値が登録される。列T1113〜T1115は、この設定の個別指標M1〜M3を評価した指標値である。行T1150を用いて具体例を説明する。行T1150は、監視対象（テナントA, サービス1のWebイベントログ, ap1server1）の生データ設定について、保存期間の開始時点を「180日前」から「200日前」に変更することを示す。その設定変更を評価した結果、設定変更には10分かかり（列T1113）、基準応答時間は１秒減少し（列T1114）、基準保存データ量が1GB増加する（列T1115）ことを表している。行T1151〜T1154に関しても同様に、設定変更の差分情報が登録されている。
【０１１１】
図１７は、第１の実施形態におけるインデックス設定情報生成ユニット85によるインデックスの設定情報生成処理のフローチャートである。この処理の大まかな流れや一部フローで実施する処理内容は、データ設定情報生成ユニット83のフローチャートと同様である。そのため、内容が同様の部分に関しては説明を省略する。
【０１１２】
インデックス設定情報生成ユニット85は、設定管理インタフェース81を介して、運用管理者から設定見直し要求を受けると、指定されたテナントの見直し対象期間中のログ検索・閲覧ユニット63の操作履歴T500を取得する（S301）。この処理は、データ設定生成ユニット83のS101と同様である。
【０１１３】
次に、インデックス設定情報生成ユニット85は、S301で取得した操作履歴T500から、監視対象＋インデックス対象データ（テナント、ログデータ種別名、インスタンス名、インデックス対象データ）の一意な組合せを列挙する（S302）。インデックス対象データは、操作履歴T500上の検索に利用したインデックスT509を用いる。また、検索にインデックスを利用していない操作履歴T500の場合には、例外として、インデックス対象データに「対象データ無し」を指定する。
【０１１４】
以下、インデックス設定情報生成ユニット85は、S302で列挙した監視対象＋インデックス対象データについて、S303〜S319の処理を繰り返す。
【０１１５】
インデックス設定情報生成ユニット85は、S302で列挙した監視対象＋インデックス対象データから未検証のものI_KEYを選択し、操作履歴T500からその監視対象＋インデックス対象データを持つ履歴のグループI_GRPを取得する（S303）。
【０１１６】
続いて、インデックス設定情報生成ユニット85は、I_KEYに対応する新しいインデックスの設定情報の候補を生成する（S304〜S316）。まず、インデックス設定情報生成ユニット85は、生成したインデックスの設定情報の候補を一時保存するためのリストLを生成する（S304）。次に、インデックス設定情報生成ユニット85は、I_KEYに対応する個別ポリシー情報T900を取得する（S305）。さらに、I_GRPに含まれる操作履歴T500から、検索条件（列T504〜T506）で指定したデータ列のべき集合を生成する（S306）。S305の方法を図７の操作履歴T500の行T553を例に説明する。この行では列T504〜T505で「ログ計測時刻」、列T506で「データ種別名」、「インスタンス名」、計３つのデータ列が検索に指定されている。そのため、このデータ列のべき集合としては{{対象データ無し}, {ログ計測時刻}, {データ種別名}, {インスタンス名}, {ログ計測時刻, データ種別名}, {ログ計測時刻, インスタンス名}, {データ種別名, インスタンス名}, {ログ計測時刻, データ種別名, インスタンス名}}が生成される。
【０１１７】
その後、インデックス設定情報生成ユニット85は、S305で生成したデータ列のべき集合の要素についてS308〜S316を繰り返す。
【０１１８】
インデックス設定情報生成ユニット85は、未検証のデータ列のべき集合の要素 PARAM_SETを選択する（S308）。そして、インデックス設定情報生成ユニット85は、このPARAM_SETを用いて、I_KEYのインデックスの設定情報の候補CONF_IDXを生成する（S309）。この初期設定値には（監視対象＝I_KEYの監視対象, 保存形式＝インデックス, インデックス対象データ＝PARAM＿SET, 保存期間＝ [制限なし,現在まで]）を指定する。さらに、インデックス設定情報生成ユニット85は、I_GRPに含まれる各操作履歴T500のログ利用日数（検索条件で指定したログ計測時間の最小値−アクセス日時）を計算し、昇順にソートする（S310）。続いて、インデックス設定情報生成ユニット85は、S310で計算したログ利用日数に未検証のものがあるか判定し（S311）、もしなければ、このPARAM_SETを用いたインデックス設定情報は不十分とみなし、次のPARAM_SETを選択する処理に戻る（S308）。もしあれば、S311のログ利用日数から、未検証かつ最も狭いログ利用日数TR_IDXを選択する（S312）。そして、このログ利用日数TR_IDXをインデックスの設定情報の候補CONF_IDXの保存期間に設定する（S313）。さらに、インデックスの設定情報の候補CONF_IDXの指標値M1, M2, M3を計算する（S314）。この計算方法は前述の方法と同様の方法を用いる。計算した指標M1, M2, M3が個別ポリシーを満たしたかどうかを判定し、もし満たしていれば、このインデックスの設定情報の候補CONF_IDXをリストLに登録する（S316）。もし満たしていなければ、新しいTR_IDXを選びなおす（S312）。
【０１１９】
以上の処理S304〜S316によって、I_KEYのインデックスの設定情報の候補をリストアップした後で、その中から一つを選び出し生成した設定情報として登録する。そのために、まず、インデックス設定情報生成ユニット85は、リストLの中から、データ量が最も少ないと期待される設定情報を取り出す（S317）。この方法としては、例えば、インデックス対象データ列数×保存期間が最小となる設定情報を選ぶ方法が挙げられる。S317の処理は、リストの中から最も良い候補を選びだすための一例であり、他の方法や基準で選出しても構わない。続いて、インデックス設定情報生成ユニット85は、S317で取り出した設定情報を生成した設定情報として登録する（S318）。
【０１２０】
以上のS303〜S319の処理を繰り返し、インデックスの設定情報を生成した後で、インデックス設定情報生成ユニット85は、不要なインデックスの設定情報を排除する。そのために、生成した設定情報同士（レコード同士）のインデックス対象データ列および保存期間を比較することで、包含関係を確認する（S320）。包含されるインデックスは包含するインデックスで代替できるため、不要である。そこで、他の設定情報に包含される設定情報を、生成した設定情報から全て削除する（S322）。これにより、データ量をより節約することができる。
【０１２１】
本実施形態の設定生成処理では、指標M1〜M6を全て判定に利用している。しかしこの全てを利用する必要はない。例えば、指標M2, M5が重要な場合には、この計算と判定だけを行っても構わない。
【０１２２】
図１８は、第１の実施形態におけるインデックス設定情報調整ユニット86によるインデックスの設定情報調整処理のフローチャートである。 この処理の大まかな流れや一部フローで実施する処理内容は、データ設定情報調整ユニット87のフローチャートと同様である。そのため、内容が同様の部分に関しては説明を省略する。
【０１２３】
インデックス設定情報調整ユニット86は、インデックス設定情報生成ユニット85による、図１７に示したインデックス設定情報生成処理が終わった後で、生成した設定情報が設定変更のポリシーを満たしているかの判定を行い、生成した設定情報を調整することで、最終的な設定変更案を生成する。その流れを以下に説明する。
【０１２４】
まず、インデックス設定情報調整ユニット86は、管理データベース4から現在の設定情報T600と、インデックス設定情報生成ユニット85の処理によって生成した設定情報をそれぞれ取得する（S401）。次に、インデックス設定情報調整ユニット86は、S401で取得した現在の設定情報T600と生成した設定情報を紐づけて、設定変更の前後のペアを作成する（S402）。この方法の一例をあげる。まず、監視対象とデータ保存形式、インデックス対象データが一致するものを設定変更のペアとする。さらに、監視対象とデータ保存形式が一致し、インデックス対象データが一致しない場合には、その一致したデータ列数が最も多い設定情報同士を設定変更のペアとする。そうでない設定については、追加あるいは削除とみなし、変更前あるいは変更後の設定情報が空の設定変更のペアとする。次に、インデックス設定情報調整ユニット86は、S402の設定変更の前後のペアから、監視対象＋インデックス対象データ（テナント、データ種別名、インスタンス名、インデックス対象データ）の一意な組合せを列挙する（S403）。 
以下、インデックス設定情報調整ユニット86は、S403で列挙した監視対象＋インデックス対象データについて、S404〜S413の処理を繰り返す。
【０１２５】
インデックス設定情報調整ユニット86は、S403の監視対象＋インデックス対象データの組合せから未検証のものI_KEYを選択する（S404）。次に、インデックス設定情報調整ユニット86は、現在の設定情報T600からI_KEYに対応するインデックスの設定情報CURRENTを、生成した設定情報から、I_KEYに対応するインデックスの設定情報CREATEDをそれぞれ取得する（S405）。続いて、インデックス設定情報調整ユニット86は、CURRENT、CREATEDの変更区分を判定する（S406）。CURRENTが空の場合には変更区分「追加」、CREATEDが空の場合に変更区分「削除」、両方が空でない場合には変更区分「変更」と判定する。
【０１２６】
その後、インデックス設定情報調整ユニット86は、インデックスの設定情報の指標値M1, M2, M3をそれぞれ計算する（S407）。この計算方法は前述のとおりである。そして、インデックス設定情報調整ユニット86は、I_KEYに対応する個別ポリシー情報T900を取得し（S408）、計算した指標値M1, M2, M3が 個別ポリシーを満たすかどうか判定する（S409）。判定の結果、個別ポリシーを満さない場合には、CREATEDは変更として不十分とみなし、CURRENTを変更後の設定情報T1200として登録する（S412）。判定の結果、個別ポリシーを満たす場合には、CREATEDを変更後の設定情報T1200として登録する（S410）。さらに、設定変更の差分情報T1100として、（I_KEY, CURRENT,CREATED, 変更区分, M1, M2, M3）を登録する（S411）。
【０１２７】
以上の処理を行い、変更後の設定情報T1100および設定変更の差分情報T1100を登録した後で、インデックス設定情報調整ユニット86は、全体ポリシー情報T800に基づく判定を行う。インデックス設定情報調整ユニット86は、設定変更の差分情報T1100から、全体の指標値M4, M5, M6を計算する（S414）。この計算方法は前述のとおりである。次に、I_KEYに対応する全体ポリシー情報T800を取得する（S415）。さらに、インデックス設定情報調整ユニット86は、計算した全体指標値M4, M5, M6と、全体ポリシー情報T800を比較し、変更後の設定情報T1200が水準を満たすかどうか判別する（S416）。もし水準を満たす場合には、設定変更の全体指標値T1300としてM4, M5, M6を登録する（S417）。もし水準を満たさない場合、この変更案は不十分とみなし、設定変更の差分情報T1200を削除する。変更後の設定情報T1200としては変更前の設定情報T600をそのまま利用する（S418）。 
S418では、全体の指標値T1300が全体ポリシー情報T800を満たさない場合、変更案として不十分とみなして処理を打ち切り、変更前の設定情報T600をそのまま利用している。処理を打ち切っている理由は、計算量を少なくするためである。そのため、計算量を考慮しなくてよい場合には、インデックス生成処理の計算結果を残しておき、S317で選択しなかった別設定を登録し直して、再計算してもよい。あるいは、個別ポリシー情報T900を満たす全ての設定の組合せについて、全体の指標値T1300を計算して、その中から、最も全体の指標値が良い設定を採用してもよい。
【０１２８】
図１９は、設定変更の全体指標値T1300の例を示す図である。これは、設定変更案生成ユニット82が、設定変更の差分情報T1100の全体指標を評価した結果である。列T1301は、設定変更案の対象となるログデータを管理しているテナントの名称である。列T1302〜T1304は、この設定の全体指標M4〜M6の指標値である。例えば行T1350に示すテナントAの設定変更の全体指標値は、「全設定変更にかかる時間の合計が210分」、「変更後の全設定についての基準応答時間の平均値が8秒」、「変更後の全ログデータ保存データ量は90GB」であり、いずれも、設定変更の全体ポリシー情報T800のポリシーを満たしている。
【０１２９】
本実施形態における設定情報の調整処理では、指標M1〜M6を全て判定に利用している。しかし、この全てを計算に利用しなくても構わない。
【０１３０】
また、上記で述べた各フローチャートの処理は、個別ポリシー情報T900と全体ポリシー情報T8000を用いずに実施することも可能である。例えば、各指標の優劣を判断する別の手段（指標の優先順位など）があれば、その方法で代替して、本発明に記載の方法を実施することも可能である。
【０１３１】
図２０は、変更案表示ユニット87が、運用管理者に提示する設定変更案の推薦画面表示の例を示す図である。この画面は、運用管理者が要求した設定変更案を確認し、それに対して操作をするための画面である。この推薦画面表示870は、設定変更案の全体の指標値の表示871、設定変更案の差分情報の表示872、設定変更の許可・却下選択ボタン873、設定変更反映ボタン874、再提案ボタン875によって構成される。設定変更の全体の指標値の表示871には、先に評価した全体の指標値T1300を描画される。また、設定変更の差分情報の表示872には、先に生成および指標を評価した設定変更の差分情報T1100を描画される。また、各差分情報に対応する監視基盤提供者からテナント管理者への課金額の増減金額も併せて表示される。これらの表示を閲覧することで、運用管理者は設定変更内容とその効果、及びコストの増減を確認することができる。設定変更の許可・却下選択ボタン873は、各設定について、変更を「許可」するか「却下」するかを選択するためのインタフェースである。このボタンは差分情報T1100の各行分用意される (873−1〜873−3)。
【０１３２】
874および875は、差分情報T1100と許可・却下選択ボタン873の選択情報に基づいて、操作を実行するためのボタンである。設定変更反映ボタン874を押下すると、差分情報T1100と選択情報に基づいて、ログデータベース3上の設定ならびに現在の設定情報T600を更新する。再提案ボタン875を押下すると、差分情報T1100と選択情報T1400に基づいて、設定変更案を再生成する。この再提案の方法については、第２の実施形態において、詳細に述べる。
【０１３３】
以上のようにして、本発明の設定変更案生成ユニット82は、操作履歴T500、現在の設定情報T600、データ量情報T700を用いて設定変更案を自動生成する。また、その設定変更による効果と影響の判断材料となる指標情報を提示する。運用管理者は、この自動生成された設定変更案を用いて、指標情報をもとに設定変更の取捨選択ができる。そのため、本発明は、ログデータベース設定検討作業の工数を削減できる効果がある。したがって、運用者が監視にかけるコストを削減できる効果がある。
【０１３４】
また、本発明では、操作履歴T500から実際に活用されているログデータの種類とその期間を分析して設定変更案を生成する。これにより、実際にアクセスしたデータやその期間に合わせた設定を生成することができる。この案に従って、設定変更することで、従来よりもログデータベース上の無駄なデータを削減できる効果がある。また、従来発生していたログデータの消し過ぎによる損失（障害対応時工数増大、機会損失）を抑制できる効果がある。したがって、監視基盤の運用管理者のログ監視強化をする効果も期待できる。
【０１３５】
さらに、本発明では、運用管理者が設定変更に求める要求水準を表す個別ポリシー情報および全体ポリシー情報を用いて、設定変更案を生成することで、使用しなかった場合に比べて、より運用管理者の要求に合った設定変更案を推薦できる。そのため、使わなかった場合に比べてより高い精度で設定変更案を生成できる。また、個別ポリシー情報T900と全体ポリシー情報T800という二つの観点から要求の判定を行うことで、片方しか使わなかった場合に比べてより高い精度で設定変更案を生成できる。このように精度の高い推薦を行うことで、運用管理者のログデータベース設定検討作業の工数をより削減できる効果が期待できる。
【０１３６】
本発明では、設定変更案の生成において、テナント情報T400を用いる。これにより、テナントごとの細かい操作履歴T500やポリシー情報を用いた設定変更案の生成ができるため、使わなかった場合に比べて、設定変更案の提案の精度をより上げることができる。そのため、運用管理者のログデータベース設定検討作業の工数をより削減できる効果がある。
【０１３７】
このように、本実施形態の設定変更作業の支援により、監視基盤の運用管理者のログ監視（特にログデータベースの管理）にかかるコストを削減できる。第１に、本実施形では、設定変更案を自動生成する。また、設定変更による効果と影響の判断材料となる指標情報を提示する。これにより、ログデータベース設定検討作業の工数を削減できる。第２に、本実施形では、操作履歴から実際に活用されているログデータの種類とその期間を分析して設定変更案を生成する。この案に従って、設定変更することで、ログデータベース上の無駄なデータを削減できる。  
また、監視基盤の運用管理者のログ監視強化をすることができる。本実施形では、利用実態に合わせた設定変更案を生成するため、従来発生していたログデータの消し過ぎによる損失（障害対応時工数増大、機会損失）を抑制できる。
また、利用実態に合わせた設定変更案を生成するため、従来発生していたログデータの消し過ぎによる損失（障害対応時工数増大、機会損失）を抑制できる。
【０１３８】
なお、第１の実施形態では、運用管理者からの要求を契機に、ログデータベース3の設定変更案を自動生成し、その設定変更案を運用管理者に提示する例を示したが、運用管理者による人手を介さない方法でも、本発明は実施可能である。例えば、ログ設定管理サーバ8がログデータベース3上の管理状態が一定の閾値を超えたこと（例：設定変更後に一定期間が経過、あるいは、保存データ量が一定以上に達したこと）を契機に、設定変更案生成を自動実行し、その設定の自動反映まで実施してもよい。
【０１３９】
このように、本実施例を用いた設定変更作業の支援により、監視対象毎に時系列データの保存に関して時間情報を含む設定情報の変更案を自動生成するので、監視基盤の時系列データベースのリソースの浪費を削減し、かつ、運用管理者の監視にかかるコストを削減できる。
【実施形態２】
【０１４０】
次に、本発明の第２の実施形態について述べる。  
第２の実施形態は、第１の実施形態に記載の方法で一度運用管理者に設定変更案を提示した後で、運用管理者による設定変更の許可・不許可の選択情報を入力に、設定変更案を再調整する例である。
【０１４１】
図２１に、第２の実施形態で想定するコンピュータシステムを模式的に示す。コンピュータシステムの構成は、第１の実施形態と概ね同様である。ただし、管理データベース4上に選択情報T1400がログ設定管理サーバ8上に選択情報分析ユニット88が追加されている点が異なる。以降では異なる部分についてのみ説明し、第１の実施形態と同様の部分についての説明は省略する。
【０１４２】
図２２は、選択情報T1400の一例である。選択情報T1400は、変更案表示ユニット87が表示した変更案の推薦画面表示に対して、運用管理者が許可・却下を選択した結果を記録したデータである。列T1401は、ログデータベース3の設定を一意に識別するためのIDである。この列は、設定変更の差分情報T1100の列T1101と関連付いている。列T1402は、この設定が満たした個別ポリシー情報T900を一意に特定するためのIDを示す。この列は、個別ポリシー情報T900の列T901と関連付いている。ここで、この設定が満たした個別ポリシー情報には、データ設定情報調整処理中のS215の処理結果、およびインデックス設定情報調整処理中のS409の処理結果を登録することとする。列T1403は、運用管理者がこの設定に対して、変更の許可・却下を選択した結果である。許可された場合には「許可」、却下された場合には「却下」がそれぞれ登録される。
【０１４３】
図２３は、第２の実施形態における設定変更案の再調整のシーケンスである。まず、前提として、第１の実施形態と同様の設定変更案生成処理が行われている。そして、運用管理者に対して、生成した変更案の推薦画面表示870が提示されている状態にある。その状態において、運用管理者が推薦画面表示870上で、各設定変更の許可・却下を選択し、再提案ボタン875を押下することで、設定変更見直し要求がされる。設定見直し要求がされると、選択情報分析ユニット88は、選択情報T1400に基づくポリシーの自動調整処理S5を実施する。その後、設定変更案生成ユニット82は、調整したポリシー情報を利用して、第１の実施形態と同様の方法で、設定変更案生成処理を再実行する。
【０１４４】
図２４は、第２の実施形態における選択情報分析ユニット88のポリシー情報の自動調整処理のフローチャートである。本実施形態では処理の一例として、個別ポリシー情報T900を調整する例を示す。調整した個別ポリシー情報T900は、再調整要求の間だけ一時的に使用しても構わないし、その後も継続して使い続けても構わない。この例では、再調整要求の間だけ一時的に使用することとする。まず、選択情報分析ユニット88は、設定見直し要求を受けると、まず、そのテナントの個別ポリシー情報T900を取得する（S501）。この例では調整した個別ポリシー情報T900は、再調整要求の間だけ一時的に使用することを想定して、調整前の個別ポリシー情報T900を複製して退避しておくこととする。次に、選択情報分析ユニット88は、要求したテナントの、設定変更の差分情報T1100とその選択情報T1400を取得する（S502）。さらに、選択情報T1400のうち、「却下」された設定について、設定変更の差分情報T1100と選択情報T1400のペアを列挙する（S503）。
【０１４５】
以下、選択情報分析ユニット88は、S503で列挙したペアについて、S504〜S506の処理を繰り返す。
【０１４６】
選択情報分析ユニット88は、S503で列挙したペアから、未検証のペアPAIRを選択する（S504）。次に、選択情報分析ユニット88は、PAIRの差分情報T1100の個別指標値を用いて新しい個別ポリシーを生成し（S505）、テナントの個別ポリシー情報T900を新しいポリシーで上書きする（S506）。S505〜S506の処理方法としては、例えば、却下された差分情報T1100に含まれる指標値と、その設定が満たした個別ポリシー情報T900の値とを比較して、より厳しい値を新しい値として与える方法を用いる。今、図１６に例示する差分情報T1100の設定T1152が「却下」されたとする。また、この設定T1152は、図１０に例示する個別ポリシー情報T900のポリシーT951を満たしたとする。その場合には、却下された設定T1152をもとに、ポリシーを「設定変更にかかる時間」を「60分未満」から「50分未満」に、「設定変更に伴う基準応答時間の変化」を「減少が１秒以上」から「減少が12秒以上」に、「設定変更に伴うデータ量の変化」を「無制限」から「増加が18GB未満」に更新する。もし、同一の個別ポリシー情報を満たした設定が、複数の却下された場合には、繰り返し処理によって、より厳しい条件で更新されていく。ただし、これは一例であるため、別の処理方法を用いても構わない。例えば、同一の個別ポリシー情報を満たし、かつ却下された複数の設定の値のうち、最も緩い条件を用いる方法でも構わないし、それらの値の平均値を用いる方法でも構わない。
【０１４７】
また、この例の選択情報T1400は今回の設定変更におけるデータしか記録していないが、過去の複数回の設定変更の選択情報T1400を記録しておき、そのうちから却下された設定情報だけを取り出して、その設定値の平均値を使う方法でも構わない。
【０１４８】
以上のようにして、設定変更案生成ユニット82は、実施形態1と設定変更案を生成、提示するとともに、その案に対する選択情報T1400を用いて、設定変更案を再推薦する。これにより、運用管理者は、設定変更案生成ユニット82によって行われる推薦が役立たなかった場合は、他の推薦方法を試すことができる。その際、選択情報T1400を入力として与えることで、現在の運用管理者の要求に合わせた設定変更案を推薦することができる。これは、運用管理者のログデータベース設定検討作業の工数をより削減できる効果がある。
【実施形態３】
【０１４９】
次に、本発明の第２の実施形態について述べる。  
第３の実施形態は、第１の実施形態におけるログデータベース3の設定変更案生成時に、監視対象となるサービスの重要度に従った重み付けを行う例である。
【０１５０】
図２５に、第３の実施形態で想定するコンピュータシステムを模式的に示す。コンピュータシステムの構成は、第１の実施形態と概ね同様である。ただし、管理データベース4上にサービス情報T1500および障害情報T1600が追加されている点、ログ設定管理サーバ8上に重要度分析ユニット89が追加されている点が異なる。以降では異なる部分についてのみ説明し、第１の実施形態と同様の部分についての説明は省略する。
【０１５１】
図２６は、サービス情報T1500の一例である。サービス情報T1500は、各テナントの各サービスの監視に関する情報と、サービスの役割や重要度を表すデータである。サービス情報T1500は、予め入力されていることを想定する。列T1501は、サービスを管理するテナント名である。列T1502は、サービスを一意に特定するための名称である。例えば、「サービス1」や「サービス1デモ」などの名称が登録されている。列T1503とT1504は、各テナントの各サービスの監視に関する情報である。列T1503は、このサービスを監視のためのデータ種別名のリストである。この列には、例えば、「サービス1のWebイベントログ，OSのCPU利用率，…」のように、このサービスを関するためのデータ種別名が全て列挙されている。この列の各データ種別名は、生データT100の列T104など、他の表上のデータ種別名に対応付いている。列T1504は、このサービスを提供のためのインスタンス名のリストである。この列には、例えば、「ap1server1, ap1server2, ap1db1, …」のように、このサービスを提供のためのインスタンス名が全て列挙されている。この列の各インスタンス名は、生データT100の列T105など、他の表上のインスタンス名に対応付いている。列T1505とT1506はサービスの役割や重要度を表すデータである。列1505はサービスの役割を表す。例えば、「Webサービス本番環境」や「トライアル環境」など、このサービスの役割を表すデータが登録される。列T1505は、このサービスの重要度である。重要度にはこのサービスの役割に応じた重要度が登録される。この例では、重要度は「0〜1」の間の数値として表現される。また、この値が大きければ大きいほど重要度が高いものとする。この例では、サービスの重要度は予め与えられているが、他の情報から計算して求めても構わない。例えば、サービスを利用するエンドユーザ数を入力とする計算式から求めても構わない。また、この例では、役割と重要度は、サービスごとに決められているが、これはインスタンスごとに決めていても構わない。例えばインスタンスの役割として「APサーバ」「DBサーバ」を登録し、その値に応じて、重要度を決めても構わない。
【０１５２】
図２７は、障害情報T1600の一例である。障害情報T1600は、各サービスの障害発生の記録を示すデータである。列T1601とT1602は、それぞれテナントの名称と、サービスの名称である。この列は、サービス情報T1500の列T1501とT1502に、それぞれ関連付いている。列T1603は、障害発生日時である。この列には、サービスの障害が発生した時刻が記録される。列T1604は、その障害の原因特定に用いたデータ種別の名称である。また、列T1605は、その障害の原因となったインスタンスの名称である。列T1604とT1605のデータは、生データT100の列T103とT104などの、データ種別名とインスタンス名にそれぞれ関連付いている。
【０１５３】
図２８は、第３の実施形態における設定変更案生成のシーケンスである。運用管理者からの設定変更案見直し要求を受けると、重要度分析ユニット89は、サービス情報T1500または障害情報T1600あるいはその両方を用いてサービスの重要度を計算する（S6）。次に、実施形態1と同様の設定変更案生成処理を実施する。ただし、設定情報の保存期間の設定値には、重要度に応じて重み付けした値を用いる。また、個別ポリシー情報T900についても同様に重み付けした値を用いる。
【０１５４】
以降では、重要度分析ユニット89による重要度の分析方法の例を挙げる。ここでは、サービスの重要度として、監視対象ごとの重要度を計算する例を示す。例えば、サービス情報T1500から重要度を計算する方法としては、サービス情報T1500から監視対象を含む行をすべて取り出し、その重要度T1506の平均値を計算し、その値をこの監視対象の重要度とする方法が考えられる。また、障害情報T1600から重要度を計算する方法としては、例えば、監視対象ごとに、見直し対象期間中の障害の発生頻度を集計して、その頻度の高さを重要度として扱う方法が考えられる。
【０１５５】
重要度分析ユニット89が、監視対象ごとの重要度を計算した後で、設定変更案生成ユニット82は、この重要度を考慮した設定情報生成処理を行う。基本的な処理内容は、実施形態1と同様である。ただし、生成する設定情報の設定値とポリシー情報の各基準値に対して、重要度による重み付けを行う点が異なる。例えば、保存期間を設定する処理S108とS313においては、保存期間のログ利用日数に、監視対象の重要度が高ければ高いほど期間が長くなる重み係数をかけて計算する（例：保存期間＝ログ利用日数×（重要度＋1））。同様に個別ポリシー情報T900についても、監視対象の重要度に応じた重み係数をかけて計算する（例：データ量の条件は重要度が高ければ高くなるほど緩くする）。
【０１５６】
以上のように、設定変更案生成ユニット82は、重要度による重みづけをして設定変更案を生成することで、実施形態1に比べて、重要なログデータほど長い期間保存されるようになる。そのため、重要なサービスやログデータほど、従来発生していたログデータの消し過ぎによる損失（障害対応時工数増大、機会損失）をより抑制できる。したがって、監視基盤の運用管理者のログ監視をより強化できる効果がある。
【０１５７】
以上の第１〜３の実施形態では、生データの設定情報、圧縮データの設定情報、およびインデックスの設定情報に関する設定変更案生成処理を説明した。しかし、本発明の実施形態はこの設定情報の生成に限定されるものではない。従って、これ以外の設定情報の生成に本発明を適用しても良い。例えば、複数のログデータを分析した結果をキャッシュする設定がある場合には、その設定情報の変更案生成に本発明を適用しても良い。
【０１５８】
以上、本発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計なども含まれる。
【符号の説明】
【０１５９】
1  管理ネットワーク
2  物理的な通信回線
3  ログデータベース
4  管理データベース
5  設定変更案データベース
6  ログ監視サーバ
61  ログ収集ユニット（プログラム） 
62  データ量分析ユニット（プログラム） 
63  ログ検索・閲覧ユニット（プログラム）
7  管理者端末
71  WeBブラウザ
8  ログ設定管理サーバ
81  設定管理インタフェース
82  設定変更案生成ユニット（プログラム）
83  データ設定情報生成ユニット（プログラム）
84  データ設定情報調整ユニット（プログラム）
85  インデックス設定情報生成ユニット（プログラム）
86  インデックス設定情報調整ユニット（プログラム）
87  変更案表示ユニット（プログラム）
88  選択情報分析ユニット（プログラム）
89  重要度分析ユニット（プログラム）
100  テナント（A）のシステム
101  監視対象のサーバ
102  運用管理者端末
110  テナント（B）のシステム
120  テナント（N）のシステム
200  監視基盤提供者のシステム
201  監視基盤
202  時系列データベース
203  監視サーバ
204  設定管理機能
205  時系列データの利用・分析機能
206  監視対象毎の時間情報の変更案の生成・登録機能
300  ネットワーク
T100  生データ
T200  圧縮データ
T300  インデックス
T400  テナント情報
T500  操作履歴
T600  現在の設定情報
T700  データ量情報 
T800  全体ポリシー情報
T900  個別ポリシー情報
T1100  設定変更の差分情報
T1200  変更後の設定情報
T1300  設定変更の全体指標値
T1400  選択情報
T1500  サービス情報
T1600  障害情報。
【図１】
2014106655.tif 000003
【図２】
2014106655.tif 000004
【図３】
2014106655.tif 000005
【図４】
2014106655.tif 000006
【図５】
2014106655.tif 000007
【図６】
2014106655.tif 000008
【図７】
2014106655.tif 000009
【図８】
2014106655.tif 000010
【図９】
2014106655.tif 000011
【図１０】
2014106655.tif 000012
【図１１】
2014106655.tif 000013
【図１２】
2014106655.tif 000014
【図１３】
2014106655.tif 000015
【図１４】
2014106655.tif 000016
【図１５】
2014106655.tif 000017
【図１６】
2014106655.tif 000018
【図１７】
2014106655.tif 000019
【図１８】
2014106655.tif 000020
【図１９】
2014106655.tif 000021
【図２０】
2014106655.tif 000022
【図２１】
2014106655.tif 000023
【図２２】
2014106655.tif 000024
【図２３】
2014106655.tif 000025
【図２４】
2014106655.tif 000026
【図２５】
2014106655.tif 000027
【図２６】
2014106655.tif 000028
【図２７】
2014106655.tif 000029
【図２８】
2014106655.tif 000030