JP6375200B2

JP6375200B2 - 計算機システムの異常予兆検出装置および方法

Info

Publication number: JP6375200B2
Application number: JP2014215903A
Authority: JP
Inventors: 英児西島; 直之武田
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2014-10-23
Filing date: 2014-10-23
Publication date: 2018-08-15
Anticipated expiration: 2034-10-23
Also published as: WO2016063816A1; JP2016085496A

Description

本発明は、情報システムまたは制御システムにおける障害の予兆を検知する異常予兆検知装置および方法に関する。

従来の異常予兆検知方法は、予め想定できそうな状況を前提としており、その状況を監視するための測定項目を決めておき、定期的に監視した測定値に対して、正常範囲のしきい値の範囲内か否かによって、異常状況かどうかを検知する。予め想定できそうな状況とは、例えば、特開2010-009313では、通信トラフィック量とping応答時間である。

これ以外の例としては、計算機リソースの使用量として、例えば、CPU負荷、メモリ負荷、共有メモリ等のOS管理リソースの利用量等が考えられる。しかし、このような状況は、予め想定できることであり、当然、その状況を考慮したシステムの設計や製作およびテストが実施されているので、システム障害につながらない場合がある。

特開2010-009313

システム障害は、計算機リソースの使用量（CPU負荷、メモリ負荷、通信負荷、共有メモリ等のOS管理リソースの利用量）や異常状態（CPU負荷100%近辺、メモリ枯渇、通信量増大、共有メモリ等のOS管理リソースの枯渇など）に関係なく発生することもある。

また、システム障害は、設計不足やテスト時の項目抜け、つまりカバレージ不足によって発生する可能性が比較的に高い。具体的には、事前設定時や現地調整時のテストで異常状況を全て洗い出すことが難しく、かつ、異常状況をテスト環境で作り出すことも難しいため、テスト項目抜けが出てくる。すなわち、実際の運用時に起こる異常状態を想定できなかったときに、システム障害が発生する。

以上のことから、本発明は、システム障害が発生する状況が予め想定できない状況、すなわち未知の異常の予兆を検知することを目的とする。

計算機システムの処理単位毎の特徴点を抽出する特徴点抽出部と、特徴点抽出部が抽出した特徴点をトレースし、トレース結果を保持するトレース部と、計算機システムに障害が発生していないときのトレース結果である基準データと現在のトレース結果を比較し、比較結果が予め定められた第一の条件を満たすかどうかを判定する比較部と、判定が第一の基準を満たすとき計算機システムの異常予兆を示す情報を出力する出力部とを備えることにより実現される。その他の手段については実施例の中で明らかにされる。

本発明により、計算機を構成するプログラムに障害が発生する前に異常の予兆を検知することが可能となる。

実施例における計算機のソフトウェア構成の例を示すブロック図である。実施例における計算機のハードウェア構成の例を示すブロック図である。実行パスの特徴点抽出部の処理を示すフローチャートの例である。正常処理テスト時の関数トレースデータの例である。軽度な異常処理テスト時の関数トレースデータの例である。中度な異常処理テスト時の関数トレースデータの例である。関数コールグラフの例である。関数実行パスの頻度テーブルの例である。基準パターン算出部の処理を示すフローチャートの例である。運用時の特徴関数トレースデータの例である。特徴関数の頻度テーブルの例である。頻度グラフ基準パターンの例である。頻度テーブル基準パターンの例である。測定パターン算出と比較部の処理を示すフローチャートの例である。特徴関数の実行頻度グラフ測定パターンの例である。特徴関数の実行頻度テーブル測定パターンの例である。予兆判定条件テーブルの例である。トレース項目の指定テーブルの例である。予兆判定条件テーブル設定部の処理の流れの例である。除外パターンをグラフで表した図の例である。捕捉パターンをグラフで表した図の例である。

テスト時に、「実行パスの特徴点抽出部」がアプリケーション等のプログラム毎に関数単位の実行パスと頻度を正常処理テストと異常処理テスト別に算出する。正常処理テスト時に動作したパスを正常パスと見なし、異常処理テスト時に動作したパスを異常パスと見なす。各パスの特徴点となる関数を特定し、その特徴点とした関数を運用時の関数トレースのポイントとする。これによって、運用時の関数トレースの負荷を下げる。

実際の運用時は、「測定パターン算出と比較部」が実環境下で、プログラム毎に特徴点とした関数名を元に、実行パスと頻度を算出する。実環境下での統計的な基準パターンと最新の測定パターンが異なる場合に、異常状態（具体的には、テスト時のカバレージ抜けの状況）になる可能性があると判断する。

異常状態になる可能性があることを検知した時には、トレース項目を増やして詳細なトレースを収集する。逆に、統計的な基準パターンと最新の測定パターンが類似している場合には、正常状態と判断してトレース項目を減らしていく。これによって、障害が起こる可能性の高い時に、詳細なトレースを収集可能となり障害解析がしやすくなる。

本発明の実施の形態に関する詳細については図面を参照して説明する。

図１は、第１の実施形態が適用される計算機１００のソフトウェア構成を示すブロック図である。計算機のソフトウェア構成は、プログラム群１０１、トレース部１０２、各種トレースデータ１０３、関数トレースデータ１０４、実行パスの特徴点抽出部１１１、関数コールグラフ１１２、関数実行パスの頻度テーブル１１３、基準パターン算出部１２１、特徴関数の頻度テーブル１２２、基準パターン１２３、予兆判定条件テーブル設定部１３１、予兆判定条件テーブル１３２、測定パターン算出と比較部１３３、および、測定パターン１３４からなる。測定パターン１３４には後述する除外パターン、捕捉パターン等も格納される。

トレース部１０２は、プログラム群１０１に対する各種トレースデータ１０３および関数トレースデータ１０４を出力する。実行パスの特徴点抽出部１１１は、テスト時に実行され、関数トレースデータ１０４を入力して、関数コールグラフ１１２および関数実行パスの頻度テーブル１１３を出力する。基準パターン算出部１２１は、運用時に実行され、関数トレースデータ１０４に基づいて基準パターン１２３を出力する。測定パターン算出と比較部１３３は、運用時に実行され、測定パターン１３４を算出して基準パターン１２３と比較し、予兆判定条件テーブル１３の条件にマッチした時に、トレース部１０２に対してトレース項目の増減を指示する。すなわち、異常予兆を検知した時にトレース項目を増やすことで詳細な障害解析ができるようにする。

実行パスの特徴点抽出部１１１、関数コールグラフ１１２、関数実行パスの頻度テーブル１１３等の含まれる実線で囲まれた部分はシステム開発時等に事前設定を行うときに実行されるモジュールである。基準パターン算出部１２１、特徴関数の頻度テーブル１２２、基準パターン１２３等の含まれる点線で囲まれた部分は開発時に設定しても良いが、通常は現地調整など実際のシステムを用いて設定するときに実行されるモジュールである。実運用時には図１の全てのモジュールが実行される可能性がある。

図２は、本発明に係る計算機のハードウェア構成図の例である。図２に示すように、計算機１００は、ＣＰＵ２１１と、メモリ装置２３１と、補助記憶のための外部記憶装置２４１と、キーボードやマウス等の入力装置２６１と、液晶ディスプレイ等の出力装置２７１と、外部装置とデータ通信を行うためのネットワーク装置２５１を備えた一般的なコンピュータにより実現可能である。ＣＰＵ２１１は、１個または複数個のプロセッサコア２１２〜２１５を持つ演算装置である。

図２において、例えば、プログラム群１０１、トレース部１０２、実行パスの特徴点抽出部１１１、基準パターン算出部１２１、予兆判定条件テーブル設定部１３１、および、測定パターン算出と比較部１３３は、ＣＰＵ２１１が外部記憶装置２４１に予め記憶されている所定のプログラムをメモリ装置２３１にロードして実行することにより実現される。

図３は、図１の実行パスの特徴点抽出部１１１の処理の流れを示すフロー図である。実行パスの特徴点抽出部１１１は、事前の準備として、単体や組合せ等のテスト時に動作させる処理である。ステップ３１０は、トレース部に対して全ての関数単位のトレースを収集する設定にする。

ステップ３２０は、図１のプログラム群１０１に対してテストを実施し、各プログラムの関数単位のトレースを収集する。このテストは、正常処理テストと異常処理テストに分けて実施する。また、この異常処理テストは、軽度な異常処理と中度な異常処理を分けて実施する。軽度な異常処理テストの例としては、メモリ確保のリトライ処理、通信リトライ処理などである。中度な異常処理テストの例としては、何らかの異常によって停止したプログラムの再起動などである。ここで、図１のプログラム群１０１の例は、アプリA、アプリB等とする。以下では、説明を容易にするために、プログラム群１０１のうちでアプリAを中心に説明していく。ステップ３２０による関数トレースの出力結果は、図４〜図６に示す通りとなる。

図４は、関数トレースデータ１０４の例で、正常処理テスト時の関数トレースデータである。図４は、第１列の２０１４０７０１が日付、第２列の10:00:00.001が時刻、第３列のアプリAがプログラム名、第４列のmain()が関数名からなり、時系列に並んだ関数トレースデータである。図４の例では、アプリAの関数main()、funcA_a1()、funcA_a2()、exit()が繰り返し実行された例である。

図５は、軽度な異常処理テスト時の関数トレースデータである。図５の例では、アプリAの関数main()、funcA_b1()、funcA_b2()、exit()が繰り返し実行された例である。

図６は、中度な異常処理テスト時の関数トレースデータである。図６の例では、アプリAの関数main()、funcA_b1()、funcA_c1()、exit()が繰り返し実行された例である。

さて、図３に戻り、ステップ３３０は、収集した関数トレースを元に、各プログラムの関数のコールグラフを作成する。

図７は、図４〜６の関数トレースデータを元に作成された関数のコールグラフの例である。図７において、関数呼び出し関係がmain()７１０→funcA_a1()７２０→funcA_a2()７３０→exit()７４０となっている部分は、図４の正常処理テスト時の関数トレースデータの関数呼び出し順序から作成される。

また、関数呼び出し関係がmain()７１０→funcA_b1()７５０→funcA_b2()７６０→exit()７４０となっている部分は、図５の軽度な異常処理テスト時の関数トレースデータの関数呼び出し順序から作成される。

さらに、関数呼び出し関係がmain()７１０→funcA_b1()７５０→funcA_c1()７７０→exit()７４０となっている部分は、図６の中度な異常処理テスト時の関数トレースデータの関数呼び出し順序から作成される。なお、実際には複雑な関係となるが、ここでは分かりやすくするために、このような例としている。

さて、図３に戻り、ステップ３４０は、関数のコールグラフを元に、各プログラムの関数の実行パスの全パターンを抽出する。図７の例では、関数の実行パスの１つ目がmain()７１０→funcA_a1()７２０→funcA_a2()７３０→exit()７４０となり、２つ目がmain()７１０→funcA_b1()７５０→funcA_b2()７６０→exit()７４０となり、３つ目がmain()７１０→funcA_b1()７５０→funcA_c1()７７０→exit()７４０となる。

ステップ３５０は、収集した関数トレースを元に、各プログラムの関数の実行パス毎の実行頻度を算出する。

図８は関数実行パスの頻度テーブル１１３の例である。関数実行パスの頻度テーブル１１３は、プログラム名の列８０１、関数の実行パスの列８０２、正常処理頻度の列８０３、軽度な異常処理頻度の列８０４、および、中度な異常処理頻度の列８０５からなる。図８の例では、図４〜図６の関数トレースデータを元に、プログラム名の列８０１はアプリAが設定され、関数の実行パスの列８０２はmain()→funcA_a1()→funcA_a2()→exit()、main()→funcA_b1()→funcA_b2()→exit()、main()→funcA_b1()→funcA_c1()→exit()
の3つのパスが設定され、正常処理頻度の列８０３は各パスについて単位時間当たり１００回、０回、０回の実行頻度が設定され、軽度な異常処理の欄８０４は０回、５回、０回の実行頻度が設定され、中度な異常処理頻度の欄８０５は各パスについて単位時間当たり０回、０回、３回の実行頻度が設定される。

ステップ３６０は、各実行パスに対して一意に決定付ける特徴的な関数を抽出する。図８の例では、特徴的な関数は、main()→funcA_a1()→funcA_a2()→exit()の実行パスではfuncA_a1()またはfuncA_a2()であり、そのうちの１つを選定しfuncA_a2()とする。また、main()→funcA_b1()→funcA_b2()→exit()の実行パスではfuncA_b2()であり、main()→funcA_b1()→funcA_c1()→exit()の実行パスではfuncA_c1()となる。これらの特徴的な関数、以下では、特徴的な関数を特徴関数と呼ぶことにする。

図９は、図１の基準パターン算出部１２１の処理の流れを示すフロー図である。基準パターン算出部１２１は、現地調整以降の実際のシステム運用時に動作させる処理である。

ステップ９１０は、トレース部に対して特徴点となる関数のみをトレース収集する設定にする。ここでは、特徴点となる関数は、図３のステップ３６０で抽出した、funcA_a2()、funcA_b2()、および、funcA_c1()となる。実際の運用時は、全ての関数名ではなく、それらのうちで限定した特徴関数に絞ることで、関数トレース収集の負荷を軽減することができる。

ステップ９２０は、図１のプログラム群１０１を実行し、運用中の特徴関数のトレースを収集する。ステップ９２０による特徴関数トレースの出力結果は、図１０に示す通りとなる。図１０は図４と同様な形式である。

ステップ９３０は、収集した特徴関数トレースを元に、特徴関数に対応する実行パス毎の実行頻度を算出する。

図１１は、図１０の特徴関数トレースを元に、ステップ９３０によって算出される、特徴関数の実行回数テーブル１２２の例である。特徴関数の実行回数テーブル１２２は、プログラム名の行１１０１、特徴関数名の行１１０２、関数の実行パスの行１１０３、処理区分の行１１０４、および、実行回数の行１１０５からなる。

図１１の例では、プログラム名の行１１０１は図１０の第３列目のアプリAが設定され、特徴関数の列１１０２は図１０の第４列目の関数名としてfuncA_a2()、funcA_b2()、funcA_c1()が設定され、関数の実行パスの列１１０３は図８の関数の実行パスの列８０２の内容が特徴関数に対応付けて設定される。

また、処理区分の列１１０４は図８の各列８０２〜８０５の実行頻度の数値に関連性が強く表される処理（例えば、頻度数の最も多い部分）、すなわち「正常処理」、「軽度な異常処理」、「中度な異常処理」のいずれかがユーザにより設定される。実行頻度の列１１０５は図１０の第４列目の関数名の出現回数として、ここでは例えば、各々のパスについて１００回、１０回、３回が設定されたものとする。

ステップ９４０は、実行回数が所定の期間に所定の回数を超えた場合には、ステップ９５０へ進むが、超えていない場合にはステップ９２０へ戻る。例えば、所定の期間はプログラム群１０１の業務特性に応じて、週単位や月単位とすれば良い。また、所定の回数は正常処理の実行回数が例えば１００回以上とすれば良い。なお、所定の期間中は、基準パターンを算出するために、障害が発生していない期間とする。

ステップ９５０は、所定の期間での統計値を算出し、基準パターンを算出する。

図１２(a)は、ステップ９５０によって求められる累積実行回数グラフ１２３の例であり図１２（ｂ）が累積実行回数テーブルである。累積実行回数グラフ、図１０の特徴関数のトレースデータをグラフ表示したものであり、横軸が時間を表し、縦軸が関数の累積実行回数を表す。正常処理、軽度な異常処理、中度な異常処理に対応した特徴関数について累積実行回数を時間毎に示している。この例では正常処理の特徴関数fancA_a2の累積実行回回数の割合が他の特徴関数に比べ時間の経過とともに増えていることがわかる。

以上のステップ９１０〜９５０によって、基準パターンとしてＴ３の特徴関数の実行割合が求められる。どの程度の間特徴関数の累積実行回数を測定するかは、構成の近いシステムの測定期間を基にしても良いし、各々の特徴関数の実行割合が定常状態になったときとしても良い。

図１３は、図１の測定パターン算出と比較部１３３の処理の流れを示すフロー図である。測定パターン算出と比較部１３３は、図９の基準パターン算出部を動作を完了させた後に、実際の運用時に動作させる処理である。

ステップ１３１０は、所定の期間での統計値を算出し、測定パターンを算出する。この測定パターンの算出は、図９のステップ９１０〜９５０と同様な方法で実施することで可能となる。

図１４（ａ）は、ステップ１３１０によって算出される、累積実行回数グラフ１３４の例であり図１４（ｂ）が特徴関数の累積実行回数テーブルである。図１４（ａ）は、図１２（ａ）の累積実行回数グラフと類似しているが、図１４(a)が図１２(a)と異なり、Ｔ３において中度な異常処理を行うfuncA_c1実行頻度が増大したことを示しており、通常と異なる動きを意味する。funcA_c1実行頻度の増大は、基準パターン１１３０に対して中度な異常処理の実行頻度が増大したことを意味しており、実際の運用を今後も継続すると、障害が発生する可能性が高くなるという異常予兆を示すものである。

ステップ１３２０は、基準パターンと最新の測定パターンを比較する。この比較方法は、例えば、基準パターンと測定パターン間で、特徴関数毎の実行回数から実行頻度を算出し、正常処理の特徴関数funcA_a2を１００％となるように正規化した上で、それぞれの実行頻度を算出する。

ステップ１３３０は、比較した結果が予兆判定条件に一致する場合には、ステップ１３４０へ進み、一致しない場合にはステップ１３１０へ戻る。

図１５は、ユーザにより設定された予兆判定条件テーブル１３２の例である。予兆判定条件テーブル１３２は、プログラム名の行１４２１、予兆判定条件の行１４２２、および、トレース設定レベルの行１４２３からなる。

プログラム名の行１４２１はデフォルトで設定するプログラム共通の予兆判定条件を定義する部分１４１０である。個別のプログラム毎の設定はプログラム名称をプログラム名の欄１４２１に指定して定義する。この例ではアプリＡ１４２０の予兆判定条件が定義されている。予兆判定条件の行１４２２は、予兆判定とする条件を記述する部分である。

例えば、ここでは、判定条件として軽度な異常処理の実行頻度が基準値の１１０％を超え基準値の１２０％未満であることを示す「基準パターン×１２０％＞軽度な異常処理の実行頻度＞基準パターン×１１０％」という条件と、軽度な異常処理の実行頻度が基準値の１２０％を超えることを示す「軽度な異常処理の実行頻度＞基準パターン×１２０％」という条件と、中度な異常処理の実行頻度が基準値の１０５％を超え基準値の１１０％未満であることを示す「基準パターン×１１０％＞中度な異常処理の実行頻度＞基準パターン×１０５％」という条件と、中度な異常処理の実行頻度が基準値の１１０％を超えることを示す「中度な異常処理の実行頻度＞基準パターン×１１０％」という条件とその他の条件に分ける例がプログラム共通の処理に対する予兆判定条件として定義されている。

トレース設定レベルの行１４２３は、トレース部に対する項目数の優先度として、例えば、通常優先度、中優先度、高優先度が予兆判定条件に対応づけて設定される。

ステップ１３３０は、予兆判定条件の欄１４２２のいずれかに該当するかを選定する処理となる。ステップ１３４０は、予兆判定条件にマッチするトレース設定レベルを選定する。図１５において、予兆判定条件の欄１４２２の「基準パターン×１２０％＞軽度な異常処理の実行頻度＞基準パターン×１１０％」にマッチした場合には、トレース設定レベルとして中優先度が選定される。

ステップ１３５０は、図１のトレース部１０２に対して、トレース設定レベルに応じたトレース項目の設定を図１６のトレース項目の指定テーブルに基づいて指示する。

図１６は、トレース項目の指定テーブルの例である。トレース項目の指定テーブルは、トレース設定レベルに応じたトレース項目を指定するテーブルである。トレース項目の指定テーブルは、トレース項目１５０１の行、トレース設定レベルの高優先度の行１５０２、中優先度の行１５０３、および、通常優先度の行１５０４からなる。トレース項目１５０１の行は、オペレーティングシステムの内部動作をトレースする項目名を記述する。例えば、メモリ関連、タイマ関連、システムコール、ディスクドライバ、通信ドライバ、周辺ドライバなどである。トレース設定レベルの欄１５０２〜１５０４は、収集項目に対して○を記述し、未収集項目に対して×を記述する。

合計の負荷率の欄１５１０は、計算されたトレース収集自体の負荷率の合計値が計算されセットされる。また、合計のバッファの欄１５２０は、トレース収集による単位時間当たりの使用バッファ量の合計値が求められセットされる。合計の負荷率の欄１５１０およびバッファの欄１５２の値により、システムによって許容される範囲内であるかどうかを確認することができる。

つまり、ステップ１３５０は、トレース設定レベルの高優先度１５０２のときのトレース項目、中優先度１５０３のときのトレース項目、通常優先度１５０４のときのトレース項目のいずれかに応じて、トレース項目の収集対象を選定する。

ステップ１３６０は、トレース設定レベルが前回と今回で変更された場合に、ユーザに通知するために、変更されたトレース設定レベルの内容を出力する。例えば、現在時刻および該当のトレース設定レベルとして高優先度、中優先度、または、通常優先度のいずれかを出力する。

以上のステップ１３１０〜１３６０によって、デフォルト設定での予兆判定条件に応じて異常予兆を検知でき、さらに障害解析を容易とするために捕捉パターンを追加してトレース項目を増やすことや、除外パターンを追加してデフォルトの予兆判定条件が満たされている場合にトレース情報を減らしたり、トレース情報を出力しないという設定ができる。

図１７は、図１の予兆判定条件テーブル設定部１３１の処理の流れを示すフローチャートである。予兆判定条件テーブル設定部１３１は、ユーザが図１４の予兆判定条件テーブル１３２に示す予兆判定条件を変更する時に実行される。

ステップ１６１０は、アプリケーション共通の予兆判定条件であるデフォルト設定を修正する。予兆判定条件の欄１４２２のうちの１つを選択して、例えば、「基準パターン×１２０％＞軽度な異常処理の実行頻度＞基準パターン×１１０％」のパーセンテージの値を変更することができる。
例えば図１２（ａ）の基準パターンは、下記計算式を用いて計算した結果を基準として使用します。
基準パターン（「軽度な異常処理」ケースの実行頻度に相当する部分）
＝「軽度な異常処理」の実行頻度÷
（「正常処理」の実行頻度＋「軽度な異常処理」の実行頻度＋「中度な異常処理」の実行頻度）
ステップ１６２０は、除外パターンを追加または変更する場合には、ステップ１６３０へ進み、追加または変更しない場合には、ステップ１６５０へ進む。

ステップ１６３０は、予兆判定条件テーブル１３２のプログラム名の欄１４２１を元に、一覧表示したプログラム名からユーザが該当のプログラム名を選択する。例えば、アプリAを選択する。

ステップ１６４０は、予兆判定条件に対して除外パターンを入力または修正する。例えば、ユーザが除外パターンとして軽度な異常処理の実行頻度が基準値とほぼ同じで、中度な異常処理の実行頻度が基準値の１３０％未満であることを示す「軽度な異常処理の実行頻度＝基準パターン＆＆中度な異常処理の実行頻度＜基準パターン×１３０％」と入力し、そのトレース設定レベルとして「通常優先度」と入力する。その入力結果が予兆判定条件テーブル１３２の除外パターン１４３０へ反映される。この除外パターン１４３０は、図１３のステップ１３３０において、除外パターンとして識別される。

予兆判定条件と実測値を比較する場合は有る程度の誤差を許容するよう範囲を持たせても良い。例えば基準値と同じかどうかを判定する場合は基準値の１０１％を超えなければ基準値と同じであると判断しても良い。どこまでの誤差を許容するかはシステムに求められる信頼性に依存する。

図１８は、この除外パターンをグラフで表した図である。例えば、ユーザが各種トレースデータ１０３を解析して障害が無いことが判明した場合に、次回からはその変化パターンは異常予兆ケースから除外することができる。除外パターンの形式は図１１で示したテーブルと同じ形式で表現される。

ステップ１６５０は、捕捉パターンを追加または変更する場合には、ステップ１６６０へ進み、追加または変更しない場合には、終了する。捕捉パターンの形式は図１１で示したテーブルと同じ形式で表現される。

図１８は、図１２（ａ）や図１４（ａ）と類似の形式である。縦軸は、累積実行回数を示し、横軸は、時間を示す。
図１８の１７３０は、図１２（ａ）の１１３０とは異なる状況となったことを示し、Ｔ３でfuncA_b2の実行頻度は図１２と比べると、「軽度な異常処理」（funcA_b2）の実行頻度が急に増加していることを意味する。

図１９は、図１８と同様な形式である。縦軸は、累積実行回数を示し、横軸は、時間を示す。
図１９は図１２（ａ）と異なる状況となったことを示し、Ｔ３において図１２（ａ）と比べると、「軽度な異常処理」（funcA_b2）および「中度な異常処理」（funcA_c1）の両方の実行回数が急に増加していることを示している。

ステップ１６６０は、予兆判定条件テーブル１３２のプログラム名の欄１４２１を元に、一覧表示したプログラム名からユーザが該当のプログラム名を選択する。例えば、アプリAを選択する。

ステップ１６７０は、予兆判定条件に対して捕捉パターンを入力または修正する。例えば、ユーザが捕捉パターンとして「軽度な異常処理の実行頻度＞基準パターン×５０％＆＆中度な異常処理の実行頻度＞基準パターン×３００％」と入力し、そのトレース設定レベルとして「高優先度」と入力する。その入力結果が予兆判定条件テーブル１３２の捕捉パターン１４４０へ反映される。

この捕捉パターン１４３０は、図１３のステップ１３３０において、捕捉するパターンとして識別される。図１９は、この捕捉パターンをグラフで表した図である。例えば、ユーザが各種トレースデータ１０３を解析しても原因究明に至らなかった場合には、その状況時の優先度を高くして（トラップを仕掛けて）、さらに詳細なトレースを収集することができる。

以上のステップ１６１０〜１６７０によって、予兆判定条件テーブル１３２のデフォルト設定や除外パターンおよび捕捉パターンを変更でき、プログラムの特性に応じた対応が可能となる。

１０１プログラム群、１０２トレース部、１０３各種トレースデータ、１０４関数トレースデータ、１１１実行パスの特徴点抽出部、１１２関数コールグラフ、１１３関数実行パスの頻度テーブル、１２１基準パターン算出部、１２２特徴関数の頻度テーブル、１２３基準パターン、１３１予兆判定条件テーブル設定部、１３２予兆判定条件テーブル、１３３測定パターン算出と比較部、１３４測定パターン、除外パターン、捕捉パターン、１３５入出力部、２１１ＣＰＵ、２３１メモリ装置、２４１外部記憶装置、２５１ネットワーク装置、２６１入力装置、２７１出力装置。

Claims

計算機システムの処理単位毎の特徴点を抽出する特徴点抽出部と、
前記特徴点抽出部が抽出した特徴点をトレースし、トレース結果を保持するトレース部と、
前記計算機システムに障害が発生していないときのトレース結果である基準データと現在のトレース結果を比較し、比較結果が予め定められた第一の条件を満たすかどうかを判定する比較部と、
前記判定が第一の条件を満たすとき計算機システムの異常予兆を示す情報を出力する出力部とを備え、
前記特徴点は前記処理単位で実行される関数であり、前記計算機システムの異常処理の種別に対応づけた特徴点であり、
前記基準データは前記異常処理種別に対応づけられた特徴点の実行割合であり、前記第一の条件は前記基準データの実行割合との違いにより定義された条件であることを特徴とする計算機システムの異常予兆検出装置。
前記比較部は前記第一の条件が満たされた場合であっても異常予兆を示す情報を出力しない条件である第二の条件を受け付け、第一の条件が満たされた場合であっても第二の条件が満たされているときは計算機システムの異常予兆を示す情報の情報量を減らすか、計算機システムの異常予兆を示す情報を出力しないことを特徴とする請求項１に記載の計算機システムの異常予兆検出装置。
前記比較部は前記第一の条件が満たされたとき、出力部が出力する計算機システムの異常予兆を示す情報の情報量を増やす条件である第三の条件を受け付け、第一の条件と第三の条件の両方が満たされたとき第一の条件が満たされたときに出力される計算機システムの異常予兆を示す情報より出力する情報量を増やすことを特徴とする請求項１に記載の計算機システムの異常予兆検出装置。
特徴点抽出部が計算機システムの処理単位毎の特徴点を抽出し、
トレース部が前記特徴点抽出部が抽出した特徴点をトレースし、トレース結果を保持し、
比較部が前記計算機システムに障害が発生していないときのトレース結果である基準データと現在のトレース結果を比較し、比較結果が予め定められた第一の条件を満たすかどうかを判定し、
出力部が、前記判定が第一の条件を満たすとき計算機システムの異常予兆を示す情報を出力することを備え、
前記特徴点は前記処理単位で実行される関数であり、前記計算機システムの異常処理の種別に対応づけた特徴点であり、
前記基準データは前記異常処理種別に対応づけられた特徴点の実行割合であり、前記第一の条件は前記基準データの実行割合との違いにより定義された条件であることを特徴とする計算機システムの異常予兆検出方法。
前記比較部は前記第一の条件が満たされた場合であっても異常予兆を示す情報を出力しない条件である第二の条件を受け付け、第一の条件が満たされた場合であっても第二の条件が満たされているときは計算機システムの異常予兆を示す情報の情報量を減らすか、計算機システムの異常予兆を示す情報を出力しないことを特徴とする請求項４に記載の計算機システムの異常予兆検出方法。
前記比較部は前記第一の条件が満たされたとき、出力部が出力する計算機システムの異常予兆を示す情報の情報量を増やす条件である第三の条件を受け付け、第一の条件と第三の条件の両方が満たされたとき第一の条件が満たされたときに出力される計算機システムの異常予兆を示す情報より出力する情報量を増やすことを特徴とする請求項４に記載の計算機システムの異常予兆検出方法。