JP2009003856A - 品質障害における発生傾向把握および原因切り分けシステム、ならびにその方法 - Google Patents

Abstract

【課題】品質障害に対して、負荷情報と設定・イベント情報を関連させた障害発生傾向を確認できる機能を持たせることにより、管理者の原因切り分け作業を容易にする。
【解決手段】複数クライアントＰＣ１０１がネットワーク１０２を介して接続された対象サーバ１０３内に、サーバ負荷情報を定期的に取得するサーバ負荷情報収集部Ｓ１０１と、サーバに対して行われた設定・イベント情報を登録する業務／イベント情報登録部Ｓ１０２と、負荷情報および設定・イベント情報からユーザ（管理者など）が指定した条件に従って発生傾向を導出するタイムテーブル生成部Ｓ１０３と、画面上に表示されたタイムテーブルに対応した各時刻のサーバ負荷情報を確認できるタイムテーブル詳細確認部Ｓ１０４と、負荷情報テーブル１０６と、イベントテーブル１０７と、タイムテーブルファイル１０８とを備える。
【選択図】図１

Description

本発明は、サーバ管理業務において、品質障害（例えば、ＣＰＵ使用率やメモリ使用率の増加などのパフォーマンス低下等）が発生した場合に、その原因を切り分けるため、品質障害の発生傾向を自動的に調べて、これをユーザ（管理者など）に把握させ、原因切り分けを容易にさせることが可能な品質障害における発生傾向把握および原因切り分けシステム、ならびにその方法に関する。

従来の技術においては、サーバの品質障害の原因切り分けシステムとして、主に下記のようなシステムが用いられていた。
すなわち、通常時には、必要最小限の稼動情報項目について収集しておき、異常と判断した場合には、その稼動情報項目に対応して予め関連付けられている項目について稼動情報を追加収集するシステムである。例えば、特開平８−６５３０２号公報（特許文献１参照）に記載のネットワーク稼動情報収集システムにおいては、限定項目に対応して各ネットワークの構成要素の稼動情報を収集する稼動情報収集部と、この稼動情報収集部で収集した稼動情報に基づいて、各構成要素の稼動状況の正常または異常を限定項目別に判定するとともに、異常状態と判定したときには、異常状態の限定項目に関連する関連項目を抽出する稼動情報解析部とを設けている。

特開平８−６５３０２号公報

一般的に、サーバにおいて品質障害が発生した場合、収集した負荷情報と直近で実施した設定・イベント情報を照合して、それらの関連性を考慮しながら、原因を切り分けていく。
しかし、上記の作業では大量のデータを取り扱うため、収集した情報の管理が煩雑であり、なおかつ、サーバ上で動作しているシステムに精通している者でないと、切り分けが極めて難かしい。収集方法については、上記のような幾つかのシステムも提案され、解決が図られているが、従来の技術では以下のような問題点があった。

例えば、上記特許文献１の方法では、障害が発生し異常を検知した場合に、詳細情報を収集するため、有用な情報のみ収集されるが、実施した設定・イベント情報との照合機能は実装されていないため、原因の切り分け作業は依然として管理者が一から十まで全て行う必要があった。

（目的）
本発明の目的は、品質障害に対して、負荷情報と設定・イベント情報を関連させた障害発生傾向を確認できる機能を持たせることにより、管理者の原因切り分け作業を容易にすることが可能な品質障害における発生傾向把握および原因切り分けシステム、ならびにその方法を提供することである。

本発明に係る発生傾向把握および原因切り分けシステムは、サーバ負荷情報を定期的に取得するサーバ負荷情報収集部と、サーバに対して行われた設定・イベント情報を登録する業務／イベント情報登録部と、負荷情報および設定・イベント情報からユーザ（管理者など）が指定した条件に従って発生傾向を導出するタイムテーブル生成部と、画面上に表示されたタイムテーブルに対応した各時刻のサーバ負荷情報を確認できるタイムテーブル詳細確認部とを設けることにより、上記目的を解決する。

本発明によれば、障害原因切り分けシステムが負荷情報からだけでなく、設定・イベント情報からも原因切り分けが可能になる。さらに、負荷情報と設定・イベント情報を組み合わせた条件設定により、多角度の原因追求が可能になり、潜在的な障害も発見できる可能性がある。なお、アウトプットとしても、発生傾向がＣＳＶ形式のファイルだけでなく、視覚的にも分かり易い画面で確認できるため、切り分け作業が格段に容易となる。

以下、本発明の実施例を、図面により詳細に説明する。
図１は、本発明の一実施例に係る原因切り分けシステムの全体構成図である。
本実施例に係る原因切り分けシステムは、複数のクライアントＰＣ１０１にインターネット１０２を介して接続された対象サーバ１０３があり、このサーバ１０３に原因切り分けシステム１０４が設置される。原因切り分けシステム１０４には、サーバ負荷情報収集部Ｓ１０１、業務／イベント情報登録部Ｓ１０２、タイムテーブル生成部Ｓ１０３、および、タイムテーブル詳細確認部Ｓ１０４の各ソフトウェア記憶部が設けられる。その他に、ハードウェアとして、負荷情報テーブル１０６、イベントテーブル１０７およびタイムテーブルファイル１０８が設けられる。なお、図において、破線は入力情報、太線（実線）は出力情報である。

図２は、図１における業務／イベント情報登録部のツールである画面例を示す図である。
業務／イベント情報登録部Ｓ１０２によりイベントテーブル１０７に登録するためには、管理者等により図２に示す画面から入力する必要がある。
業務イベント名２０１、実施期間２０２〜２０３を入力するとともに、実施周期（毎日２０４、毎週２０６、曜日２０７、毎月〜日２０８、１回のみ２０９のいずれかを入力し、実施時刻２１０〜２１１および反映対象としての反映２１２または無視２１３のいずれかを入力する。そして、入力後に登録２１４をクリックするか、または誤りなどの場合にはキャンセル２１５をクリックする。

図３は、図１におけるタイムテーブル生成部のツールである画面例を示す図である。
タイムテーブル生成部Ｓ１０３により生成したテーブルをタイムテーブルファイル１０８に記憶するためには、図３に示す画面から入力する必要がある。
生成期間３０１〜３０２を入力するとともに、生成期間の周期として、毎日３０３、毎週３０４の〜曜日３０５、毎月３０６の〜日３０７のうちのいずれかを入力する。次に、優先業務・イベント名３０８、優先プロセス名３１０、ＣＰＵ使用率３１２〜３１３（％）、メモリ使用率３１５〜３１６（％）、検査対象とするヒット率３１８（％）を入力した後、これらの比重（優先業務・イベント名、優先プロセス名、ＣＰＵ使用率、メモリ使用率の各％）を入力し、最後に生成３１９をクリックするか、または、誤り等があればキャンセル３２０をクリックする。

図７は、図２の画面から入力することにより、生成されたイベントテーブルのデータ例を示す図である。
業務／イベント情報登録部Ｓ１０２から登録されたイベント情報は、イベントテーブル１０７に書き込まれることにより、登録される。
このテーブル１０７には、業務イベント名ごとの番号、業務イベント名、開始日、終了日、周期、開始時刻、終了時刻、対象フラグ（反映、無視）が登録される。

図８は、図３の画面から入力することにより、生成されたタイムテーブルのデータ例を示す図である。
タイムテーブル生成部Ｓ１０３により生成されたタイムテーブルは、ＣＳＶ形式のタイムテーブルファイル１０８に集められる。
このテーブルには、何時何分（０：００．〜２３：５０．）で示す時刻と、１（有効）か０（無効）かのフラグが記録される。

次に、図１の各部の動作について、詳細に説明する。
（サーバ負荷情報収集部）
図９は、図１におけるサーバ負荷情報収集部Ｓ１０１の処理動作を示すフローチャートである。
サーバ負荷情報収集部Ｓ１０１は、スケジューラソフト（タスクジューラ、ＪＰ１／ＡＪＳ２など）を利用し、ある一定間隔で繰り返し実行されるものとする。実行間隔は任意の間隔で構わないが、実行間隔が短いほど精度が上がるため短くした方がよい。本例においては、実行間隔を１０分に設定する。
まず、現在時刻を出力するＯＳコマンドを実行して処理開始時刻を取得し、時刻を変数Ａ１に格納する（９０１）。次に、負荷情報を出力するＯＳコマンド（例えばｖｍｓｔａｔ，ｔｏｐなど）を実行し、ＣＰＵ使用率、メモリ使用率および占有率の高いプロセス上位５種を変数Ａ２に格納する。なお、占有率の高いプロセス上位については、本例においては５種としたが、任意の数で構わない（９０２）。
続いて、負荷情報テーブル１０６への接続を確立し（９０３）、ステップ（９０１）で取得した変数Ａ１およびステップ９０２で取得した変数Ａ２を負荷情報テーブルに登録する（９０４）。
最後に、負荷情報テーブルへの接続を切断し（９０５）、処理を終了する。

（業務／イベント情報登録部）
図１０は、業務／イベント情報登録部Ｓ１０２の処理動作を示すフローチャートである。
業務／イベント情報登録部Ｓ１０２は、ユーザ（管理者など）のＰＣ１０１から図２の業務／イベント情報入力ツールを使用して行われ、ツールの登録ボタン２１３がクリックされると処理が起動する。業務／イベント情報登録はユーザが必要と判断したタイミング（業務イベントが実施された際など）で随時行う処理のため、業務／イベント情報登録部Ｓ１０２は不定期の処理となる。

まず、イベントテーブル１０７への接続を確立する（１００１）。
次に、業務／イベント情報入力ツールにてユーザが入力した以下の情報をイベントテーブル１０７へ登録する（１００２）。ユーザが入力した情報とは、図７に示すように、業務イベント名、実施期間の開始日および終了日、実施周期、実施開始時刻および終了時刻、対象フラグである。例えば、『２００６年１１月１日から２００７年１月３日まで毎週水曜日１０：００〜１２：００の間で伝票登録が実施され、タイムテーブル生成の際に反映したい情報』となる場合には、イベントテーブルにはそれぞれ『伝票登録』、『２００６／１１／１』、『２００７／１／３』、『月』、『１０：００』、『１２：００』、『反映』が限納される。なお、図２の実施期間の終了２０３が空欄で、終了日が定まっていない場合には、終了日に『−』を格納する。
最後に、イベントテーブルへの接続を切断し（１００３）、処理を終了する。

（タイムテーブル生成部）
図１１は、図１におけるタイムテーブル生成部の処理動作を示すフローチャートである。
タイムテーブル生成部Ｓ１０３は、ユーザのＰＣ１０１から図３に示すタイムテーブル生成ツールを使用して行われ、ツールの生成ボタン３１２がクリックされると、処理が起動する。タイムテーブル生成は、ユーザがタイムテーブルを必要と判断したタイミングで随時行う処理のため、タイムテーブル生成部Ｓ１０３は不定期の処理となる。

まず、負荷情報テーブル１０６およびイベントテーブル１０７への接続を確立する（１１０１）。次に、ユーザが入力した生成期間３０１、３０２および生成期間の周期３０３〜３０７より、生成期間の全対象日数を計算し（１１０２）、変数Ｃ１に格納する。例えば、生成期間が２００６年１２月１日から２００６年１２月３１日で、生成期間の周期が毎週水曜日であった場合の全対象日数は４日、すなわちＣ１＝４となる。
続いて、処理前の準備として、ステップ１１０４以降の処理結果を格納するためのタイムテーブル用配列を定義する。一例で言うと、１日（２４時間）をサーバ情報負荷収集部Ｓ１０１の起動間隔で除した値分、すなわち１４４０（分）÷１０（分）＝１４４個格納できる配列を生成する。なお、１４４０は２４時間を分で表わした値である。
以降では、この配列をＴＩＭＥＣＯＬと呼び、配列のＮ番目をＴＩＭＥＣＯＬ〔Ｎ〕で表す。なお、この先、本配列は各時刻におけるヒット率を格納するために利用し、ＴＩＭＥＣＯＬ〔１〕は０：００におけるヒット率、ＴＩＭＥＣＯＬ〔２〕は０：１０におけるヒット率、・・・、ＴＩＭＥＣＯＬ〔１４４〕は２３：５０におけるヒット率というように各時刻に対応する。

次に、各条件におけるヒット率の計算処理に移る。まず、優先業務・イベント名のヒット率から計算する。ユーザが入力した優先業務・イベント名３０８が空欄でなく、かつ、優先業務・イベント名の比重３０９が０以上か否か判断する（１１０４）。判断結果がＦＡＬＳＥであった場合には、ステップ１１０５からステップ１１０９の処理を飛ばし、ステップ１１１０の処理に移る。一方、判断結果がＴＲＵＥであった場合には、ヒット件数をカウントする（１１０６）。このヒット件数のカウントについて詳述すると、まずユーザが入力した生成期間３０１，３０２と生成期間の周期３０３〜３０７より対象日を算出する。例えば、生成期間が２００６年１２月１日から２００６年１２月３１日で、生成期間の周期が毎週水曜日であった場合、対象日として、６日、１３日、２０日、２７日が算出される。

その後、イベントテーブルにおいて、優先業務・イベント名３０８をキーに検索し、抽出したレコードに対して、以下の条件を満たすレコードが何件あるか算出し、結果の件数をヒット条件として変数Ｃ２に格納する（１１０６）。ここでの条件とは、対象日が実行日（開始日〜終了日内にあり、周期も合致）であること、カウンタ時刻が開始時刻〜終了時刻内にあること、対象フラグが『反映』となっていることである。なお、カウンタ時刻とは、カウンタ変数ＣＴに対応する時刻のことであり、本例においてはＣＴ＝１の場合には０：００、ＣＴ＝２の場合には０：１０というような時刻を表している。本例では、サーバ情報負荷収集部の起動間隔が１０分であるため、０：００、０：１０、・・・２３：４０、２３：５０までの値が入る。ヒット件数算出の例として、対象日『１２月６日』で業務イベント名が『伝票登録』であった場合で説明すると、次のようになる。

まず業務イベント名をキーにイベントテーブル１０７を検索する。次に、該当取得レコードから開始日、終了日、周期を用いて、１２月６日が含まれるか否かを判断する。本データ例では、開始日が１１月１日であり、終了日が２００７年１月３日であり、周期が水曜であるので、１２月６日は基準を満たすため、次の判断に移る。次の判定では、カウンタ時刻が開始時刻と終了時刻の間、すなわち１０：００〜１２：００に入るかを判断する。ＣＴ＝１の場合、カウンタ時刻は、０：００であるため、基準を満たさないので、ヒット件数は０となり、変数Ｃ２には０が格納される。続いて、以下の式に基づいてヒット率を求める（１１０７）。ここでヒット率を求める計算式は、『ヒット率＝Ｃ２（ヒット件数）÷Ｃ１（全対象日数）×（比重（３０９）÷１００）』である。ステップ１１０７で求めたヒット率の値をステップ１１０３で生成したタイムテーブル用配列ＴＩＭＥＣＯＬ〔ＣＴ〕に格納する（１１０８）。以上のステップ１１０６から１１０８の処理をタイムテーブル用配列の数だけ処理を繰り返す。本例では、サーバ情報負荷収集部の起動間隔が１０分であるため、ＣＴが１から１１４になるまで計１４４回処理を繰り返す（ループＡ）。

引き続き、優先プロセス名のヒット率の計算処理に移る。ユーザが入力した優先プロセス名３１０が空欄でなく、かつ、優先プロセス名の比重３１１が０以上か否かを判断する（１１１０）。判断結果がＦＡＬＳＥであった場合には、ステップ１１１１からステップ１１１５の処理を飛ばし、ステップ１１１６の処理へ移る。判断結果がＴＲＵＥであった場合には、ヒット件数をカウントする（１１１２）。このヒット件数のカウントについて詳述すると、まず、ユーザが入力した生成期間３０１，３０２と生成期間の周期３０３〜３０７より対象日を算出する。例えば、生成期間が２００６年１２月１日から２００６年１２月３１日で、生成期間の周期が毎週水曜日であった場合、対象日として、６日、１３日、２０日、２７日が算出される。

その後、対象日のカウンタ時刻に取得した情報を確認し、負荷情報テーブルの動作プロセス＃１〜＃５に、優先プロセス名３１０が含まれているかを確認する。最終的に条件に合致したレコード数をヒット件数として変数Ｃ３に格納する。なお、カウンタ時刻については、ステップ１１０６で説明したものと同じものである。ヒット件数算出の例として、対象日『１２月６日、１３日、２０日、２７日』、優先プロセス名が『Ａ．ｅｘｅ』、カウンタ変数ＣＴ＝１であった場合で説明すると、まず各対象日において、カウンタ時刻０：００に取得した負荷情報を負荷情報テーブル１０６から検索する。次に、検索結果として得られた４つのレコードに対して、動作プロセス＃１〜＃５に、優先プロセス名３１０が含まれているかを確認する。

図６は、負荷情報テーブルのデータ例を示す図である。
サーバ負荷情報収集部Ｓ１０１により収集された負荷情報は、負荷情報テーブルに書き込まれる。
図６に示す例では、１２月６日０：００と１２月１３日０：００の２件が『Ａ．ｅｘｅ』を含んでいるので、ヒット数は２となり、変数ｃ３に２を格納する。続いて、以下の式に基づいてヒット率を求める（１１１３）。ここで、ヒット率を求める計算式は『ヒット率＝（Ｃ３（ヒット件数）÷Ｃ１（全対象日数）×（比重（３１１）÷１００）』である。ステップ１１１３で求めたヒット率の値を元々配列ＴＩＭＥＣＯＬ〔ＣＴ〕に格納されていた値に加えて格納する（１１１４）。以上のステップ１１１２から１１１４の処理をタイムテーブル用配列の数だけ処理を繰り返す。本例では、サーバ情報負荷収集部の起動間隔が１０分であるため、ＣＴが１から１４４になるまで計１４４回処理を繰り返す（ループＢ）。

引き続き、ＣＰＵ使用率のヒット率の計算処理に移る。ユーザが入力したＣＰＵ使用率３１２，３１３が空欄でなく、かつ、ＣＰＵ使用率の比重３１４が０以上か否かを判断する（１１１６）。判断結果がＦＡＬＳＥであった場合には、ステップ１１１７からステップ１１２１の処理を飛ばし、ステップ１１２２の処理へ移る。判断結果がＴＲＵＥであった場合には、ヒット件数をカウントする（１１１８）。このヒット件数のカウントについて詳述すると、まずユーザが入力した生成期間３０１，３０２と生成期間の周期３０３〜３０７より対象日を算出する。例えば、生成期間が２００６年１２月１日から２００６年１２月３１日で、生成期間の周期が毎週水曜日であった場合、対象日として、６日、１３日、２０日、２７日が算出される。

その後、対象日のカウンタ時刻に取得した情報を確認し、負荷情報テーブルのＣＰＵ使用率が、入力値３１２〜３１３の範囲内に含まれているかを確認する。最終的に条件に合致したレコード数をヒット件数として変数Ｃ４に格納する。なお、カウンタ時刻については、ステップ１１０６で説明したものと同じものである。ヒット件数算出の例として、対象日『１２月６日、１３日、２０日、２７日』、ユーザ入力値が『１０％〜３０％』、カウンタ変数ＣＴ＝１であった場合で説明すると、まず各対象日において、カウンタ時刻０：００に取得した負荷情報を負荷情報テーブル１０６から検索する。

次に、検索結果として得られた４つのレコードに対して、ＣＰＵ使用率が１０％〜３０％となっているかを確認する。図６に示す例では、１２月６日０：００、１２月１３日０：００、１２月２０日０：００の３件がＣＰＵ使用率１０％〜３０％を満たしているので、ヒット件数は３となり、変数Ｃ４に３を格納する。続いて、以下の式に基づいてヒット率を求める（１１１９）。ここで、ヒット率を求める計算式は『ヒット率＝（Ｃ４（ヒット件数）÷Ｃ１（全対象日数）×（比重（３１４）÷１００）』である。ステップ１１１９で求めたヒット率の値を元々配列ＴＩＭＥＣＯＬ〔ＣＴ〕に格納されていた値に加えて格納する（１１２０）。以上のステップ１１１８から１１２０の処理をタイムテーブル用配列の数だけ処理を繰り返す。本例では、サーバ情報負荷収集部の起動期間が１０分であるため、ＣＴが１から１４４になるまで計１４４回処理を繰り返す（ループＣ）。

引き続き、メモリ使用率のヒット率の計算処理に移る。ユーザが入力したメモリ使用率３１５、３１６が空欄でなく、かつ、メモリ使用率の比重３１７が０以上か否かを判断する（１１２２）。判断結果がＦＡＬＳＥであった場合には、ステップ１１２３からステップ１１２７の処理を飛ばし、ステップ１１２８の処理に移る。判断結果がＴＲＵＥであった場合には、ヒット件数をカウントする（１１２４）。このヒット件数のカウントについて詳述すると、まず、ユーザが入力した生成期間３０１、３０２と生成期間の周期３０３〜３０７より対象日を算出する。例えば、生成期間が２００６年１２月１日から２００６年１２月３１日で、生成期間の周期が毎週水曜日であった場合、対象日として、６日、１３日、２０日、２７日が算出される。

その後、対象日のカウンタ時刻に取得した情報を確認し、負荷情報テーブルのメモリ使用率が、入力値３１５〜３１６の範囲内に含まれているかを確認する。最終的に条件に合致したレコード数をヒット件数として変数Ｃ５に格納する。なお、カウンタ時刻についてはステップ１１０６で説明したものと同じものである。ヒット件数算出の例として、対象日『１２月６日、１３日、２０日、２７日』、ユーザ入力値が『５０％〜１００％』、カウンタ変数ＣＴ＝１であった場合で説明すると、まず各対象日において、カウンタ時刻０：００に取得した負荷情報を負荷情報テーブル１０６から検索する。次に、検索結果として得られた４つのレコードに対して、メモリ使用率が５０％〜１００％となっているか否かを確認する。図６に示す例では、１２月２７日０：００のみ５０％〜１００％を満たしているので、ヒット率は１となり、変数Ｃ５に１を格納する。続いて、以下の式に基づいてヒット率を求める（１１２５）。ここで、ヒット率を求める計算式は『Ｃ５（ヒット件数）÷Ｃ１（全対象日数））×（比重（３１７）÷１００）』である。ステップ１１２５で求めたヒット率の値を元々配列ＴＩＭＥＣＯＬ〔ＣＴ〕に格納されていた値に加えて格納する（１１２６）。以上のステップ１１２４から１１２６の処理をタイムテーブル用配列の数だけ処理を繰り返す。本例では、サーバ情報負荷収集部の起動間隔が１０分であるため、ＣＴが１から１４４になるまで計１４４回処理を繰り返す。

最後に、負荷情報テーブルおよびイベントテーブルへの接続を切断し（１１２８）、タイムテーブルの生成処理を行う。タイムテーブルは、以下のようにして生成される。まず、各時刻におけるヒット率が検査対象とするヒット率（図３で入力された３１８）以上となっているか、条件文『ＴＩＭＥＣＯＬ〔ＣＴ〕≧（図３の３１８の入力値÷１００）』によって確認する（１１３０）。判断結果がＴＲＵＥであった場合には、タイムテーブル用配列ＲＥＳＵＬＴＣＯＬに０を入力する（１１３２）。その後、タイムテーブルファイルに、時刻、カンマ、タイムテーブル用配列、改行コードの順で出力する（１１３３）。
例えば、ＣＴ＝１の場合で、条件判断がＴＲＵＥの場合には、『０：００，１（改行コード）』をタイムテーブルファイルに出力する。これらステップ１１３０からステップ１１３３までの処理は、ＣＴをカウントアップして各時刻において行う。本例では、サーバ情報負荷収集部の起動間隔が１０分であるため、ＣＴが１から１４４になるまで処理を繰り返す。

図４は、タイムテーブルの画面の画面例を示す図である。
図１１におけるステップ１１３３でタイムテーブルファイルに出力し、ループＥを終了した後（１１３４）、図４のタイムテーブル画面を呼び出す（１１３５）。
その後、以下のようにして、画面上にタイムテーブルの内容を表示させる。まず、条件６『ＲＥＳＵＬＴＣＯＬ〔ＣＴ〕＝１』によって、該当時間が検査対象となっているかを確認する（１１３６）。ＦＡＬＳＥであった場合には（ステップ１１３７）、図４の枠４０１において、該当時刻に対応する箇所の色を変更する。例えば、ＣＴ＝１の場合で、条件判断がＴＲＵＥの場合には、０：００に該当する左から１番目（ＣＴ番目）の枠の色を変更する（１１３８）。
これらのステップ１１３６からステップ１１３７までの処理はＣＴをカウントアップし、各時刻において行う。本例では、サーバ情報負荷収集部の起動間隔が１０分であるため、ＣＴが１から１４４になるまで、計１４４回処理を繰り返す。これで、ループＥは終了となる（１１３９）。

（タイムテーブル詳細確認部）
図１２は、タイムテーブル詳細確認部（Ｓ１０４）の処理動作を示すフローチャートである。また、図５は、詳細確認画面の画面例を示す図である。
タイムテーブル詳細確認部は、図４のタイムテーブル画面において、時刻枠４０１をクリックした際に表示される画面である図５において、確認ボタン５１１がクリックされると、処理が起動する。なお、図５の初期画面では、対象日欄５０１に昨日の日付、対象時刻欄５０２には図４の時刻枠４０１に対応する時刻が、画面起動とともに入力される。例えば、２００７年１月１６日に、図４において、時刻枠４０１の上段左から２つ目の枠をクリックして、図５を表示させた場合、対象日欄５０１には、『２００７／０１／１５』
対象時刻欄５０２には、『０：１０』が入力された状態で、図５が表示される。

まず、負荷情報テーブル１０６への接続を確立する（１２０１）。
次に、負荷情報テーブル１０６の取得日時列において、対象日欄５０１および対象時刻欄５０２と合致する情報があるかを検索し、取得した情報を変数Ｄ１に格納する（１２０２）。ここで、取得した情報とは、ＣＰＵ使用率、メモリ使用率、動作プロセス＃１、動作プロセス＃２、動作プロセス＃３、動作プロセス＃４、動作プロセス＃５である。
最後に、負荷情報テーブルへの接続を切断し（１２０３）、ステップ１２０２で取得した変数Ｄ１の情報を図５上の対応欄５０３〜５１０に出力させて（１２０４）、処理を終了する。

本発明の一実施例に係るサーバ負荷傾向把握システムの全体構成図である。 図１におけるサーバ管理者ＰＣで表示される業務／イベント情報入力ツールの画面例を示す図である。 図１におけるサーバ管理者ＰＣで表示されるタイムテーブル生成ツールの画面例を示す図である。 図１におけるサーバ管理者ＰＣで表示されるタイムテーブル画面の画面例を示す図である。 図１におけるサーバ管理者ＰＣで表示される詳細確認画面の画面例を示す図である。 図１における負荷情報テーブルの内容を示す図である。 図１におけるイベントテーブルの内容を示す図である。 図１におけるタイムテーブルファイルの内容を示す図である。 図１におけるサーバ負荷情報収集部（Ｓ１０１）の処理動作を示すフローチャートである。 図１における業務／イベント情報登録部（Ｓ１０２）の処理動作を示すフローチャートである。 図１におけるサーバ負荷情報収集部（Ｓ１０３）の処理動作を示すフローチャートである。 図１におけるタイムテーブル詳細確認部（Ｓ１０４）の処理動作を示すフローチャートである。

符号の説明

１０１ サーバ管理者が管理しているクライアントＰＣ
１０２ ネットワーク
１０３ 対象サーバ
１０４ 負荷傾向把握システム
１０５ データベース
１０６ 負荷情報テーブル
１０７ イベントテーブル
１０８ タイムテーブルファイル（ＣＳＶ形式ファイル）
Ｓ１０１ サーバ負荷情報収集部（プログラム）
Ｓ１０２ 業務／イベント情報登録部（プログラム）
Ｓ１０３ タイムテーブル生成部（プログラム）
Ｓ１０４ タイムテーブル詳細確認部（プログラム）

Claims (7)

1. サーバ管理業務におけるＣＰＵ使用率、メモリ使用率の増加を含む品質障害の原因切り分けを行う発生傾向把握および原因切り分けシステムにおいて、
   対象となるサーバの負荷情報をデータベースに登録するサーバ負荷情報収集部と、
   該サーバに負荷を与える可能性のある業務名およびメンテナンス作業名および作業開始・終了時刻をデータベースに登録する業務・イベント情報登録部と、
   前記負荷の情報および業務・イベント情報より品質障害の発生傾向を表すタイムテーブルを生成するタイムテーブル生成部とを備えることを特徴とする品質障害における発生傾向把握および原因切り分けシステム。
2. 請求項１に記載の品質障害における発生傾向把握および原因切り分けシステムにおいて、
   前記データベースは、負荷情報テーブルとイベントテーブルとタイムテーブルであることを特徴とする品質障害における発生傾向把握および原因切り分けシステム。
3. 請求項１に記載の品質障害における発生傾向把握および原因切り分けシステムにおいて、
   前記各処理部およびデータベースに加えて、負荷情報テーブルの取得日時列において、対象日欄および対象時刻欄と合致する情報があるか否かを検索し、取得するためのタイムテーブル詳細確認部を備えることを特徴とする品質障害における発生傾向把握および原因切り分けシステム。
4. 発生傾向把握および原因切り分けシステムによりタイムテーブルを生成するタイムテーブル生成方法において、
   タイムテーブル生成部は、負荷情報テーブルおよびイベントテーブルへの接続を確立し、
   ユーザにより入力された生成期間および生成期間の周期から、生成期間の全対象日数を計算し、
   優先業務・イベント名のヒット率、優先プロセス名のヒット率、ＣＰＵ使用率のヒット率、メモリ使用率のヒット率の順序で各々を計算し、
   前記負荷情報テーブルおよびイベントテーブルへの接続を切断した後に、タイムテーブルの生成処理を行うことを特徴とするタイムテーブル生成方法。
5. 発生傾向把握および原因切り分けシステムにより負荷情報を収集するサーバ負荷情報収集方法において、
   サーバ負荷情報収集部は、スケジューラソフトを利用して、ある一定間隔で繰り返し実行することにより、まず、現在時刻を出力するＯＳコマンドを実行して、処理開始時刻を取得して、該時刻をメモリに格納し、
   負荷情報を出力するＯＳコマンドを実行して、ＣＰＵ使用率、メモリ使用率および占有率の高いプロセス上位数種類を前記メモリに格納し、
   負荷情報テーブルへの接続を確立した後、前記メモリに格納された情報を該負荷情報テーブルに登録することを特徴とするサーバ負荷情報収集方法。
6. 発生傾向把握および原因切り分けシステムにより業務・イベント情報を登録する業務・イベント情報登録方法において、
   業務・イベント情報登録部は、イベントテーブルへの接続を確立した後、業務・イベント情報入力画面からユーザが入力した業務イベント名、実施期間の開始日および終了日、実施周期、実施開始時刻および終了時刻、対象フラグの各情報を前記イベントテーブルに書き込むことを特徴とする業務・イベント情報登録方法。
7. 発生傾向把握および原因切り分けシステムによりタイムテーブルを確認するタイムテーブル詳細確認方法において、
   タイムテーブル詳細確認部は、負荷情報テーブルへの接続を確立した後、前記負荷情報テーブルの取得日時列に対して、対象日欄および対象時刻欄と合致するＣＰＵ使用率、メモリ使用率、動作プロセスを含む情報があるか否かを検索し、その結果、取得した情報をメモリに格納することを特徴とするタイムテーブル詳細確認方法。

Images