(57)【特許請求の範囲】
【請求項１】
サーバ管理業務におけるＣＰＵ使用率、メモリ使用率の増加を含む品質障害の原因切り分けを行う発生傾向把握および原因切り分けシステムにおいて、
対象となるサーバの負荷情報を所定の実行間隔で取得してデータベースに登録するサーバ負荷情報収集部と、
該サーバに負荷を与える可能性のある業務名およびメンテナンス作業名および作業実施期間と実施周期をデータベースに登録する業務・イベント情報登録部と、
前記業務・イベント情報登録部がデータベースに登録した作業実施期間と実施周期と、ユーザが入力したタイムテーブルの生成期間と生成期間の周期とを対比した結果として、
作業実施期間および生成期間に含まれ、かつ、実施周期と生成期間の周期とが合致する日に実施された作業が、
前記所定の実行間隔の特定の一時刻に実施されていた回数を、前記所定の実行間隔の各時刻毎にカウントし、
該カウントした回数の、前記合致する日の日数（全対象日数）に対する率（第１のヒット率）を算出すると共に、
前記サーバ負荷情報収集部が所定の実行間隔の各時点で取得した負荷情報の値が所定の範囲であった回数を、前記所定の実行間隔の各時刻毎にカウントし、該カウントした回数の、前記合致する日の日数（全対象日数）に対する率（第２のヒット率）を算出し、
算出した第１，第２のヒット率を重み付き加算して、前記所定の実行間隔の各時刻に対応付けて登録するタイムテーブルを生成するタイムテーブル生成部とを備えることを特徴とする品質障害における発生傾向把握および原因切り分けシステム。
【請求項２】
コンピュータ装置により、サーバ管理業務におけるＣＰＵ使用率、メモリ使用率の増加を含む品質障害の原因切り分けを行う発生傾向把握および原因切り分け方法であって、
前記コンピュータ装置は、プログラムされたコンピュータ処理を実行する手段として、サーバ負荷情報収集手段と、業務・イベント情報登録手段と、タイムテーブル生成手段とを具備し、
前記サーバ負荷情報収集手段は、
対象となるサーバの負荷情報を所定の実行間隔で取得してデータベースに登録し、
前記業務・イベント情報登録手段は、
前記サーバに負荷を与える可能性のある業務名およびメンテナンス作業名および作業実施期間と実施周期をデータベースに登録し、
前記タイムテーブル生成手段は、
前記業務・イベント情報登録手段がデータベースに登録した作業実施期間と実施周期と、ユーザが入力したタイムテーブルの生成期間と生成期間の周期とを対比した結果として、
作業実施期間および生成期間に含まれ、かつ、実施周期と生成期間の周期とが合致する日に実施された作業が、
前記所定の実行間隔の特定の一時刻に実施されていた回数を、前記所定の実行間隔の各時刻毎にカウントし、
該カウントした回数の、前記合致する日の日数（全対象日数）に対する率（第１のヒット率）を算出すると共に、
前記サーバ負荷情報収集手段が所定の実行間隔の各時点で取得した負荷情報の値が所定の範囲であった回数を、前記所定の実行間隔の各時刻毎にカウントし、該カウントした回数の、前記合致する日の日数（全対象日数）に対する率（第２のヒット率）を算出し、
算出した第１，第２のヒット率を重み付き加算して、前記所定の実行間隔の各時刻に対応付けて登録するタイムテーブルを生成することを特徴とする品質障害における発生傾向把握および原因切り分け方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバ管理業務において、品質障害（例えば、ＣＰＵ使用率やメモリ使用率の増加などのパフォーマンス低下等）が発生した場合に、その原因を切り分けるため、品質障害の発生傾向を自動的に調べて、これをユーザ（管理者など）に把握させ、原因切り分けを容易にさせることが可能な品質障害における発生傾向把握および原因切り分けシステム、ならびにその方法に関する。
【背景技術】
【０００２】
従来の技術においては、サーバの品質障害の原因切り分けシステムとして、主に下記のようなシステムが用いられていた。
すなわち、通常時には、必要最小限の稼動情報項目について収集しておき、異常と判断した場合には、その稼動情報項目に対応して予め関連付けられている項目について稼動情報を追加収集するシステムである。例えば、特開平８−６５３０２号公報（特許文献１参照）に記載のネットワーク稼動情報収集システムにおいては、限定項目に対応して各ネットワークの構成要素の稼動情報を収集する稼動情報収集部と、この稼動情報収集部で収集した稼動情報に基づいて、各構成要素の稼動状況の正常または異常を限定項目別に判定するとともに、異常状態と判定したときには、異常状態の限定項目に関連する関連項目を抽出する稼動情報解析部とを設けている。
【０００３】
【特許文献１】特開平８−６５３０２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
一般的に、サーバにおいて品質障害が発生した場合、収集した負荷情報と直近で実施した設定・イベント情報を照合して、それらの関連性を考慮しながら、原因を切り分けていく。
しかし、上記の作業では大量のデータを取り扱うため、収集した情報の管理が煩雑であり、なおかつ、サーバ上で動作しているシステムに精通している者でないと、切り分けが極めて難かしい。収集方法については、上記のような幾つかのシステムも提案され、解決が図られているが、従来の技術では以下のような問題点があった。
【０００５】
例えば、上記特許文献１の方法では、障害が発生し異常を検知した場合に、詳細情報を収集するため、有用な情報のみ収集されるが、実施した設定・イベント情報との照合機能は実装されていないため、原因の切り分け作業は依然として管理者が一から十まで全て行う必要があった。
【０００６】
（目的）
本発明の目的は、品質障害に対して、負荷情報と設定・イベント情報を関連させた障害発生傾向を確認できる機能を持たせることにより、管理者の原因切り分け作業を容易にすることが可能な品質障害における発生傾向把握および原因切り分けシステム、ならびにその方法を提供することである。
【課題を解決するための手段】
【０００７】
本発明に係る発生傾向把握および原因切り分けシステムは、サーバ負荷情報を定期的に取得するサーバ負荷情報収集部と、サーバに対して行われた設定・イベント情報を登録する業務／イベント情報登録部と、負荷情報および設定・イベント情報からユーザ（管理者など）が指定した条件に従って発生傾向を導出するタイムテーブル生成部と、画面上に表示されたタイムテーブルに対応した各時刻のサーバ負荷情報を確認できるタイムテーブル詳細確認部とを設けることにより、上記目的を解決する。
【発明の効果】
【０００８】
本発明によれば、障害原因切り分けシステムが負荷情報からだけでなく、設定・イベント情報からも原因切り分けが可能になる。さらに、負荷情報と設定・イベント情報を組み合わせた条件設定により、多角度の原因追求が可能になり、潜在的な障害も発見できる可能性がある。なお、アウトプットとしても、発生傾向がＣＳＶ形式のファイルだけでなく、視覚的にも分かり易い画面で確認できるため、切り分け作業が格段に容易となる。
【発明を実施するための最良の形態】
【０００９】
以下、本発明の実施例を、図面により詳細に説明する。
図１は、本発明の一実施例に係る原因切り分けシステムの全体構成図である。
本実施例に係る原因切り分けシステムは、複数のクライアントＰＣ１０１にインターネット１０２を介して接続された対象サーバ１０３があり、このサーバ１０３に原因切り分けシステム１０４が設置される。原因切り分けシステム１０４には、サーバ負荷情報収集部Ｓ１０１、業務／イベント情報登録部Ｓ１０２、タイムテーブル生成部Ｓ１０３、および、タイムテーブル詳細確認部Ｓ１０４の各ソフトウェア記憶部が設けられる。その他に、ハードウェアとして、負荷情報テーブル１０６、イベントテーブル１０７およびタイムテーブルファイル１０８が設けられる。なお、図において、破線は入力情報、太線（実線）は出力情報である。
【００１０】
図２は、図１における業務／イベント情報登録部のツールである画面例を示す図である。
業務／イベント情報登録部Ｓ１０２によりイベントテーブル１０７に登録するためには、管理者等により図２に示す画面から入力する必要がある。
業務イベント名２０１、実施期間２０２〜２０３を入力するとともに、実施周期（毎日２０４、毎週２０６、曜日２０７、毎月〜日２０８、１回のみ２０９のいずれかを入力し、実施時刻２１０〜２１１および反映対象としての反映２１２または無視２１３のいずれかを入力する。そして、入力後に登録２１４をクリックするか、または誤りなどの場合にはキャンセル２１５をクリックする。
【００１１】
図３は、図１におけるタイムテーブル生成部のツールである画面例を示す図である。
タイムテーブル生成部Ｓ１０３により生成したテーブルをタイムテーブルファイル１０８に記憶するためには、図３に示す画面から入力する必要がある。
生成期間３０１〜３０２を入力するとともに、生成期間の周期として、毎日３０３、毎週３０４の〜曜日３０５、毎月３０６の〜日３０７のうちのいずれかを入力する。次に、優先業務・イベント名３０８、優先プロセス名３１０、ＣＰＵ使用率３１２〜３１３（％）、メモリ使用率３１５〜３１６（％）、検査対象とするヒット率３１８（％）を入力した後、これらの比重（優先業務・イベント名、優先プロセス名、ＣＰＵ使用率、メモリ使用率の各％）を入力し、最後に生成３１９をクリックするか、または、誤り等があればキャンセル３２０をクリックする。
【００１２】
図７は、図２の画面から入力することにより、生成されたイベントテーブルのデータ例を示す図である。
業務／イベント情報登録部Ｓ１０２から登録されたイベント情報は、イベントテーブル１０７に書き込まれることにより、登録される。
このテーブル１０７には、業務イベント名ごとの番号、業務イベント名、開始日、終了日、周期、開始時刻、終了時刻、対象フラグ（反映、無視）が登録される。
【００１３】
図８は、図３の画面から入力することにより、生成されたタイムテーブルのデータ例を示す図である。
タイムテーブル生成部Ｓ１０３により生成されたタイムテーブルは、ＣＳＶ形式のタイムテーブルファイル１０８に集められる。
このテーブルには、何時何分（０：００．〜２３：５０．）で示す時刻と、１（有効）か０（無効）かのフラグが記録される。
【００１４】
次に、図１の各部の動作について、詳細に説明する。
（サーバ負荷情報収集部）
図９は、図１におけるサーバ負荷情報収集部Ｓ１０１の処理動作を示すフローチャートである。
サーバ負荷情報収集部Ｓ１０１は、スケジューラソフト（タスクジューラ、ＪＰ１／ＡＪＳ２など）を利用し、ある一定間隔で繰り返し実行されるものとする。実行間隔は任意の間隔で構わないが、実行間隔が短いほど精度が上がるため短くした方がよい。本例においては、実行間隔を１０分に設定する。
まず、現在時刻を出力するＯＳコマンドを実行して処理開始時刻を取得し、時刻を変数Ａ１に格納する（９０１）。次に、負荷情報を出力するＯＳコマンド（例えばｖｍｓｔａｔ，ｔｏｐなど）を実行し、ＣＰＵ使用率、メモリ使用率および占有率の高いプロセス上位５種を変数Ａ２に格納する。なお、占有率の高いプロセス上位については、本例においては５種としたが、任意の数で構わない（９０２）。
続いて、負荷情報テーブル１０６への接続を確立し（９０３）、ステップ（９０１）で取得した変数Ａ１およびステップ９０２で取得した変数Ａ２を負荷情報テーブルに登録する（９０４）。
最後に、負荷情報テーブルへの接続を切断し（９０５）、処理を終了する。
【００１５】
（業務／イベント情報登録部）
図１０は、業務／イベント情報登録部Ｓ１０２の処理動作を示すフローチャートである。
業務／イベント情報登録部Ｓ１０２は、ユーザ（管理者など）のＰＣ１０１から図２の業務／イベント情報入力ツールを使用して行われ、ツールの登録ボタン２１３がクリックされると処理が起動する。業務／イベント情報登録はユーザが必要と判断したタイミング（業務イベントが実施された際など）で随時行う処理のため、業務／イベント情報登録部Ｓ１０２は不定期の処理となる。
【００１６】
まず、イベントテーブル１０７への接続を確立する（１００１）。
次に、業務／イベント情報入力ツールにてユーザが入力した以下の情報をイベントテーブル１０７へ登録する（１００２）。ユーザが入力した情報とは、図７に示すように、業務イベント名、実施期間の開始日および終了日、実施周期、実施開始時刻および終了時刻、対象フラグである。例えば、『２００６年１１月１日から２００７年１月３日まで毎週水曜日１０：００〜１２：００の間で伝票登録が実施され、タイムテーブル生成の際に反映したい情報』となる場合には、イベントテーブルにはそれぞれ『伝票登録』、『２００６／１１／１』、『２００７／１／３』、『月』、『１０：００』、『１２：００』、『反映』が限納される。なお、図２の実施期間の終了２０３が空欄で、終了日が定まっていない場合には、終了日に『−』を格納する。
最後に、イベントテーブルへの接続を切断し（１００３）、処理を終了する。
【００１７】
（タイムテーブル生成部）
図１１は、図１におけるタイムテーブル生成部の処理動作を示すフローチャートである。
タイムテーブル生成部Ｓ１０３は、ユーザのＰＣ１０１から図３に示すタイムテーブル生成ツールを使用して行われ、ツールの生成ボタン３１２がクリックされると、処理が起動する。タイムテーブル生成は、ユーザがタイムテーブルを必要と判断したタイミングで随時行う処理のため、タイムテーブル生成部Ｓ１０３は不定期の処理となる。
【００１８】
まず、負荷情報テーブル１０６およびイベントテーブル１０７への接続を確立する（１１０１）。次に、ユーザが入力した生成期間３０１、３０２および生成期間の周期３０３〜３０７より、生成期間の全対象日数を計算し（１１０２）、変数Ｃ１に格納する。例えば、生成期間が２００６年１２月１日から２００６年１２月３１日で、生成期間の周期が毎週水曜日であった場合の全対象日数は４日、すなわちＣ１＝４となる。
続いて、処理前の準備として、ステップ１１０４以降の処理結果を格納するためのタイムテーブル用配列を定義する。一例で言うと、１日（２４時間）をサーバ情報負荷収集部Ｓ１０１の起動間隔で除した値分、すなわち１４４０（分）÷１０（分）＝１４４個格納できる配列を生成する。なお、１４４０は２４時間を分で表わした値である。
以降では、この配列をＴＩＭＥＣＯＬと呼び、配列のＮ番目をＴＩＭＥＣＯＬ〔Ｎ〕で表す。なお、この先、本配列は各時刻におけるヒット率を格納するために利用し、ＴＩＭＥＣＯＬ〔１〕は０：００におけるヒット率、ＴＩＭＥＣＯＬ〔２〕は０：１０におけるヒット率、・・・、ＴＩＭＥＣＯＬ〔１４４〕は２３：５０におけるヒット率というように各時刻に対応する。
【００１９】
次に、各条件におけるヒット率の計算処理に移る。まず、優先業務・イベント名のヒット率から計算する。ユーザが入力した優先業務・イベント名３０８が空欄でなく、かつ、優先業務・イベント名の比重３０９が０以上か否か判断する（１１０４）。判断結果がＦＡＬＳＥであった場合には、ステップ１１０５からステップ１１０９の処理を飛ばし、ステップ１１１０の処理に移る。一方、判断結果がＴＲＵＥであった場合には、ヒット件数をカウントする（１１０６）。このヒット件数のカウントについて詳述すると、まずユーザが入力した生成期間３０１，３０２と生成期間の周期３０３〜３０７より対象日を算出する。例えば、生成期間が２００６年１２月１日から２００６年１２月３１日で、生成期間の周期が毎週水曜日であった場合、対象日として、６日、１３日、２０日、２７日が算出される。
【００２０】
その後、イベントテーブルにおいて、優先業務・イベント名３０８をキーに検索し、抽出したレコードに対して、以下の条件を満たすレコードが何件あるか算出し、結果の件数をヒット条件として変数Ｃ２に格納する（１１０６）。ここでの条件とは、対象日が実行日（開始日〜終了日内にあり、周期も合致）であること、カウンタ時刻が開始時刻〜終了時刻内にあること、対象フラグが『反映』となっていることである。なお、カウンタ時刻とは、カウンタ変数ＣＴに対応する時刻のことであり、本例においてはＣＴ＝１の場合には０：００、ＣＴ＝２の場合には０：１０というような時刻を表している。本例では、サーバ情報負荷収集部の起動間隔が１０分であるため、０：００、０：１０、・・・２３：４０、２３：５０までの値が入る。ヒット件数算出の例として、対象日『１２月６日』で業務イベント名が『伝票登録』であった場合で説明すると、次のようになる。
【００２１】
まず業務イベント名をキーにイベントテーブル１０７を検索する。次に、該当取得レコードから開始日、終了日、周期を用いて、１２月６日が含まれるか否かを判断する。本データ例では、開始日が１１月１日であり、終了日が２００７年１月３日であり、周期が水曜であるので、１２月６日は基準を満たすため、次の判断に移る。次の判定では、カウンタ時刻が開始時刻と終了時刻の間、すなわち１０：００〜１２：００に入るかを判断する。ＣＴ＝１の場合、カウンタ時刻は、０：００であるため、基準を満たさないので、ヒット件数は０となり、変数Ｃ２には０が格納される。続いて、以下の式に基づいてヒット率を求める（１１０７）。ここでヒット率を求める計算式は、『ヒット率＝Ｃ２（ヒット件数）÷Ｃ１（全対象日数）×（比重（３０９）÷１００）』である。ステップ１１０７で求めたヒット率の値をステップ１１０３で生成したタイムテーブル用配列ＴＩＭＥＣＯＬ〔ＣＴ〕に格納する（１１０８）。以上のステップ１１０６から１１０８の処理をタイムテーブル用配列の数だけ処理を繰り返す。本例では、サーバ情報負荷収集部の起動間隔が１０分であるため、ＣＴが１から１１４になるまで計１４４回処理を繰り返す（ループＡ）。
【００２２】
引き続き、優先プロセス名のヒット率の計算処理に移る。ユーザが入力した優先プロセス名３１０が空欄でなく、かつ、優先プロセス名の比重３１１が０以上か否かを判断する（１１１０）。判断結果がＦＡＬＳＥであった場合には、ステップ１１１１からステップ１１１５の処理を飛ばし、ステップ１１１６の処理へ移る。判断結果がＴＲＵＥであった場合には、ヒット件数をカウントする（１１１２）。このヒット件数のカウントについて詳述すると、まず、ユーザが入力した生成期間３０１，３０２と生成期間の周期３０３〜３０７より対象日を算出する。例えば、生成期間が２００６年１２月１日から２００６年１２月３１日で、生成期間の周期が毎週水曜日であった場合、対象日として、６日、１３日、２０日、２７日が算出される。
【００２３】
その後、対象日のカウンタ時刻に取得した情報を確認し、負荷情報テーブルの動作プロセス＃１〜＃５に、優先プロセス名３１０が含まれているかを確認する。最終的に条件に合致したレコード数をヒット件数として変数Ｃ３に格納する。なお、カウンタ時刻については、ステップ１１０６で説明したものと同じものである。ヒット件数算出の例として、対象日『１２月６日、１３日、２０日、２７日』、優先プロセス名が『Ａ．ｅｘｅ』、カウンタ変数ＣＴ＝１であった場合で説明すると、まず各対象日において、カウンタ時刻０：００に取得した負荷情報を負荷情報テーブル１０６から検索する。次に、検索結果として得られた４つのレコードに対して、動作プロセス＃１〜＃５に、優先プロセス名３１０が含まれているかを確認する。
【００２４】
図６は、負荷情報テーブルのデータ例を示す図である。
サーバ負荷情報収集部Ｓ１０１により収集された負荷情報は、負荷情報テーブルに書き込まれる。
図６に示す例では、１２月６日０：００と１２月１３日０：００の２件が『Ａ．ｅｘｅ』を含んでいるので、ヒット数は２となり、変数ｃ３に２を格納する。続いて、以下の式に基づいてヒット率を求める（１１１３）。ここで、ヒット率を求める計算式は『ヒット率＝（Ｃ３（ヒット件数）÷Ｃ１（全対象日数）×（比重（３１１）÷１００）』である。ステップ１１１３で求めたヒット率の値を元々配列ＴＩＭＥＣＯＬ〔ＣＴ〕に格納されていた値に加えて格納する（１１１４）。以上のステップ１１１２から１１１４の処理をタイムテーブル用配列の数だけ処理を繰り返す。本例では、サーバ情報負荷収集部の起動間隔が１０分であるため、ＣＴが１から１４４になるまで計１４４回処理を繰り返す（ループＢ）。
【００２５】
引き続き、ＣＰＵ使用率のヒット率の計算処理に移る。ユーザが入力したＣＰＵ使用率３１２，３１３が空欄でなく、かつ、ＣＰＵ使用率の比重３１４が０以上か否かを判断する（１１１６）。判断結果がＦＡＬＳＥであった場合には、ステップ１１１７からステップ１１２１の処理を飛ばし、ステップ１１２２の処理へ移る。判断結果がＴＲＵＥであった場合には、ヒット件数をカウントする（１１１８）。このヒット件数のカウントについて詳述すると、まずユーザが入力した生成期間３０１，３０２と生成期間の周期３０３〜３０７より対象日を算出する。例えば、生成期間が２００６年１２月１日から２００６年１２月３１日で、生成期間の周期が毎週水曜日であった場合、対象日として、６日、１３日、２０日、２７日が算出される。
【００２６】
その後、対象日のカウンタ時刻に取得した情報を確認し、負荷情報テーブルのＣＰＵ使用率が、入力値３１２〜３１３の範囲内に含まれているかを確認する。最終的に条件に合致したレコード数をヒット件数として変数Ｃ４に格納する。なお、カウンタ時刻については、ステップ１１０６で説明したものと同じものである。ヒット件数算出の例として、対象日『１２月６日、１３日、２０日、２７日』、ユーザ入力値が『１０％〜３０％』、カウンタ変数ＣＴ＝１であった場合で説明すると、まず各対象日において、カウンタ時刻０：００に取得した負荷情報を負荷情報テーブル１０６から検索する。
【００２７】
次に、検索結果として得られた４つのレコードに対して、ＣＰＵ使用率が１０％〜３０％となっているかを確認する。図６に示す例では、１２月６日０：００、１２月１３日０：００、１２月２０日０：００の３件がＣＰＵ使用率１０％〜３０％を満たしているので、ヒット件数は３となり、変数Ｃ４に３を格納する。続いて、以下の式に基づいてヒット率を求める（１１１９）。ここで、ヒット率を求める計算式は『ヒット率＝（Ｃ４（ヒット件数）÷Ｃ１（全対象日数）×（比重（３１４）÷１００）』である。ステップ１１１９で求めたヒット率の値を元々配列ＴＩＭＥＣＯＬ〔ＣＴ〕に格納されていた値に加えて格納する（１１２０）。以上のステップ１１１８から１１２０の処理をタイムテーブル用配列の数だけ処理を繰り返す。本例では、サーバ情報負荷収集部の起動期間が１０分であるため、ＣＴが１から１４４になるまで計１４４回処理を繰り返す（ループＣ）。
【００２８】
引き続き、メモリ使用率のヒット率の計算処理に移る。ユーザが入力したメモリ使用率３１５、３１６が空欄でなく、かつ、メモリ使用率の比重３１７が０以上か否かを判断する（１１２２）。判断結果がＦＡＬＳＥであった場合には、ステップ１１２３からステップ１１２７の処理を飛ばし、ステップ１１２８の処理に移る。判断結果がＴＲＵＥであった場合には、ヒット件数をカウントする（１１２４）。このヒット件数のカウントについて詳述すると、まず、ユーザが入力した生成期間３０１、３０２と生成期間の周期３０３〜３０７より対象日を算出する。例えば、生成期間が２００６年１２月１日から２００６年１２月３１日で、生成期間の周期が毎週水曜日であった場合、対象日として、６日、１３日、２０日、２７日が算出される。
【００２９】
その後、対象日のカウンタ時刻に取得した情報を確認し、負荷情報テーブルのメモリ使用率が、入力値３１５〜３１６の範囲内に含まれているかを確認する。最終的に条件に合致したレコード数をヒット件数として変数Ｃ５に格納する。なお、カウンタ時刻についてはステップ１１０６で説明したものと同じものである。ヒット件数算出の例として、対象日『１２月６日、１３日、２０日、２７日』、ユーザ入力値が『５０％〜１００％』、カウンタ変数ＣＴ＝１であった場合で説明すると、まず各対象日において、カウンタ時刻０：００に取得した負荷情報を負荷情報テーブル１０６から検索する。次に、検索結果として得られた４つのレコードに対して、メモリ使用率が５０％〜１００％となっているか否かを確認する。図６に示す例では、１２月２７日０：００のみ５０％〜１００％を満たしているので、ヒット率は１となり、変数Ｃ５に１を格納する。続いて、以下の式に基づいてヒット率を求める（１１２５）。ここで、ヒット率を求める計算式は『Ｃ５（ヒット件数）÷Ｃ１（全対象日数））×（比重（３１７）÷１００）』である。ステップ１１２５で求めたヒット率の値を元々配列ＴＩＭＥＣＯＬ〔ＣＴ〕に格納されていた値に加えて格納する（１１２６）。以上のステップ１１２４から１１２６の処理をタイムテーブル用配列の数だけ処理を繰り返す。本例では、サーバ情報負荷収集部の起動間隔が１０分であるため、ＣＴが１から１４４になるまで計１４４回処理を繰り返す。
【００３０】
最後に、負荷情報テーブルおよびイベントテーブルへの接続を切断し（１１２８）、タイムテーブルの生成処理を行う。タイムテーブルは、以下のようにして生成される。まず、各時刻におけるヒット率が検査対象とするヒット率（図３で入力された３１８）以上となっているか、条件文『ＴＩＭＥＣＯＬ〔ＣＴ〕≧（図３の３１８の入力値÷１００）』によって確認する（１１３０）。判断結果がＴＲＵＥであった場合には、タイムテーブル用配列ＲＥＳＵＬＴＣＯＬに０を入力する（１１３２）。その後、タイムテーブルファイルに、時刻、カンマ、タイムテーブル用配列、改行コードの順で出力する（１１３３）。
例えば、ＣＴ＝１の場合で、条件判断がＴＲＵＥの場合には、『０：００，１（改行コード）』をタイムテーブルファイルに出力する。これらステップ１１３０からステップ１１３３までの処理は、ＣＴをカウントアップして各時刻において行う。本例では、サーバ情報負荷収集部の起動間隔が１０分であるため、ＣＴが１から１４４になるまで処理を繰り返す。
【００３１】
図４は、タイムテーブルの画面の画面例を示す図である。
図１１におけるステップ１１３３でタイムテーブルファイルに出力し、ループＥを終了した後（１１３４）、図４のタイムテーブル画面を呼び出す（１１３５）。
その後、以下のようにして、画面上にタイムテーブルの内容を表示させる。まず、条件６『ＲＥＳＵＬＴＣＯＬ〔ＣＴ〕＝１』によって、該当時間が検査対象となっているかを確認する（１１３６）。ＦＡＬＳＥであった場合には（ステップ１１３７）、図４の枠４０１において、該当時刻に対応する箇所の色を変更する。例えば、ＣＴ＝１の場合で、条件判断がＴＲＵＥの場合には、０：００に該当する左から１番目（ＣＴ番目）の枠の色を変更する（１１３８）。
これらのステップ１１３６からステップ１１３７までの処理はＣＴをカウントアップし、各時刻において行う。本例では、サーバ情報負荷収集部の起動間隔が１０分であるため、ＣＴが１から１４４になるまで、計１４４回処理を繰り返す。これで、ループＥは終了となる（１１３９）。
【００３２】
（タイムテーブル詳細確認部）
図１２は、タイムテーブル詳細確認部（Ｓ１０４）の処理動作を示すフローチャートである。また、図５は、詳細確認画面の画面例を示す図である。
タイムテーブル詳細確認部は、図４のタイムテーブル画面において、時刻枠４０１をクリックした際に表示される画面である図５において、確認ボタン５１１がクリックされると、処理が起動する。なお、図５の初期画面では、対象日欄５０１に昨日の日付、対象時刻欄５０２には図４の時刻枠４０１に対応する時刻が、画面起動とともに入力される。例えば、２００７年１月１６日に、図４において、時刻枠４０１の上段左から２つ目の枠をクリックして、図５を表示させた場合、対象日欄５０１には、『２００７／０１／１５』
対象時刻欄５０２には、『０：１０』が入力された状態で、図５が表示される。
【００３３】
まず、負荷情報テーブル１０６への接続を確立する（１２０１）。
次に、負荷情報テーブル１０６の取得日時列において、対象日欄５０１および対象時刻欄５０２と合致する情報があるかを検索し、取得した情報を変数Ｄ１に格納する（１２０２）。ここで、取得した情報とは、ＣＰＵ使用率、メモリ使用率、動作プロセス＃１、動作プロセス＃２、動作プロセス＃３、動作プロセス＃４、動作プロセス＃５である。
最後に、負荷情報テーブルへの接続を切断し（１２０３）、ステップ１２０２で取得した変数Ｄ１の情報を図５上の対応欄５０３〜５１０に出力させて（１２０４）、処理を終了する。
【図面の簡単な説明】
【００３４】
【図１】本発明の一実施例に係るサーバ負荷傾向把握システムの全体構成図である。
【図２】図１におけるサーバ管理者ＰＣで表示される業務／イベント情報入力ツールの画面例を示す図である。
【図３】図１におけるサーバ管理者ＰＣで表示されるタイムテーブル生成ツールの画面例を示す図である。
【図４】図１におけるサーバ管理者ＰＣで表示されるタイムテーブル画面の画面例を示す図である。
【図５】図１におけるサーバ管理者ＰＣで表示される詳細確認画面の画面例を示す図である。
【図６】図１における負荷情報テーブルの内容を示す図である。
【図７】図１におけるイベントテーブルの内容を示す図である。
【図８】図１におけるタイムテーブルファイルの内容を示す図である。
【図９】図１におけるサーバ負荷情報収集部（Ｓ１０１）の処理動作を示すフローチャートである。
【図１０】図１における業務／イベント情報登録部（Ｓ１０２）の処理動作を示すフローチャートである。
【図１１】図１におけるサーバ負荷情報収集部（Ｓ１０３）の処理動作を示すフローチャートである。
【図１２】図１におけるタイムテーブル詳細確認部（Ｓ１０４）の処理動作を示すフローチャートである。
【符号の説明】
【００３５】
１０１  サーバ管理者が管理しているクライアントＰＣ
１０２  ネットワーク
１０３  対象サーバ
１０４  負荷傾向把握システム
１０５  データベース
１０６  負荷情報テーブル
１０７  イベントテーブル
１０８  タイムテーブルファイル（ＣＳＶ形式ファイル）
Ｓ１０１  サーバ負荷情報収集部（プログラム）
Ｓ１０２  業務／イベント情報登録部（プログラム）
Ｓ１０３  タイムテーブル生成部（プログラム）
Ｓ１０４  タイムテーブル詳細確認部（プログラム）
【図１】
0004507260.tif 000002
【図２】
0004507260.tif 000003
【図３】
0004507260.tif 000004
【図４】
0004507260.tif 000005
【図５】
0004507260.tif 000006
【図６】
0004507260.tif 000007
【図７】
0004507260.tif 000008
【図８】
0004507260.tif 000009
【図９】
0004507260.tif 000010
【図１０】
0004507260.tif 000011
【図１１】
0004507260.tif 000012
【図１２】
0004507260.tif 000013