(57)【要約】      （修正有）【課題】監視対象の異常を適切に検出可能にする装置及びプログラムを提供する。【解決手段】異常検出装置において、定期分析部２２１は、定期的に、監視対象３０におけるリソース使用量を定期量として取得して、定期量の特徴を表す定期特徴量を計算する。イベント分析部２２２は、イベントの発生時に、監視対象３０におけるリソース使用量をイベント量として取得して、イベント量の特徴を表すイベント特徴量を計算する。判定部２３１は、定期判定データ記憶部１３１に記憶された定期判定データと定期特徴量とを比較して、監視対象３０に異常が発生しているか否かを判定するとともに、イベント判定データ記憶部１３２に記憶されたイベント判定データとイベント特徴量とを比較して、監視対象３０に異常が発生しているか否かを判定する。【選択図】図１
2019003303.tif 000002
【特許請求の範囲】
【請求項１】
定期的に、監視対象におけるリソース使用量を定期量として取得して、前記定期量の特徴を表す定期特徴量を計算する定期分析部と、
イベントの発生時に、前記監視対象におけるリソース使用量をイベント量として取得して、前記イベント量の特徴を表すイベント特徴量を計算するイベント分析部と、
定期判定データ記憶部に記憶された定期判定データと、前記定期分析部によって計算された前記定期特徴量とを比較して、前記監視対象に異常が発生しているか否かを判定するとともに、イベント判定データ記憶部に記憶されたイベント判定データと、前記イベント分析部によって計算された前記イベント特徴量とを比較して、前記監視対象に異常が発生しているか否かを判定する判定部と
を備える異常検出装置。
【請求項２】
前記異常検出装置は、さらに、
前記定期判定データと前記定期特徴量とを比較して前記監視対象に異常が発生していないと前記判定部によって判定された場合に、前記定期特徴量に基づき、前記定期判定データ記憶部に記憶された前記定期判定データを更新し、前記イベント判定データと前記イベント特徴量とを比較して前記監視対象に異常が発生していないと前記判定部によって判定された場合に、前記イベント特徴量に基づき、前記イベント判定データ記憶部に記憶された前記イベント判定データを更新する判定データ更新部
を備える請求項１に記載の異常検出装置。
【請求項３】
前記イベント分析部は、前記イベント量の取得時に、前記定期分析部によって定期量が取得されている場合には、取得された前記イベント量から前記定期量分減らした上で、前記イベント特徴量を計算する
請求項１又は２に記載の異常検出装置。
【請求項４】
前記定期分析部は、定期的に第１時間分の前記リソース使用量を前記定期量として取得し、
前記イベント分析部は、イベントの発生時に第２時間分の前記リソース使用量を前記イベント量として取得し、前記第１時間と前記第２時間との重複する時間について、取得された前記イベント量から前記定期量分減らす
請求項３に記載の異常検出装置。
【請求項５】
前記イベント分析部は、前記定期判定データから前記重複する時間の前記定期量を推定して、取得された前記イベント量から推定された前記定期量分減らす
請求項４に記載の異常検出装置。
【請求項６】
前記イベントは、データ通信を行い、
前記イベント判定データ記憶部は、前記イベントで通信されたデータの種別毎に、前記イベント判定データを記憶し、
前記判定部は、発生したイベントで通信されたデータの種別に応じた前記イベント判定データに基づき、前記監視対象に異常が発生しているか否かを判定する
請求項１から５までのいずれか１項に記載の異常検出装置。
【請求項７】
定期的に、監視対象におけるリソース使用量を定期量として取得して、前記定期量の特徴を表す定期特徴量を計算する定期分析処理と、
イベントの発生時に、前記監視対象におけるリソース使用量をイベント量として取得して、前記イベント量の特徴を表すイベント特徴量を計算するイベント分析処理と、
定期判定データ記憶部に記憶された定期判定データと、前記定期分析処理によって計算された前記定期特徴量とを比較して、前記監視対象に異常が発生しているか否かを判定するとともに、イベント判定データ記憶部に記憶されたイベント判定データと、前記イベント分析処理によって計算された前記イベント特徴量とを比較して、前記監視対象に異常が発生しているか否かを判定する判定処理と
をコンピュータに実行させる異常検出プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、監視対象の異常を検出するための技術に関する。
【背景技術】
【０００２】
監視対象の異常を検出する方法として、監視対象である計算機のリソース使用量を収集し、経験則に基づく固定的な判定値による判定を行う方法がある。また、別の方法として、収集した計算機のリソース使用量を蓄積して、蓄積されたリソース使用量から学習を行い、正常な状態を表す正常パターンを確立した後、収集されたリソース使用量と正常パターンとを比較する方法がある（特許文献１参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００８−１９１８３９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
固定的な判定値による判定を行う場合、判定値を低く設定すると、誤警報が多発する可能性があり、判定値を高く設定すると、障害が発生しているにもかかわらず、障害検知がされない可能性がある。
学習を行い正常パターンの確立を行う場合、計算機のリソース使用量の変動パターンが時間的な周期性のみならず、プロセス間もしくは計算機間の通信データにより変化する装置については、適切な判断基準を作成することは困難である。
この発明は、監視対象の異常を適切に検出可能にすることを目的とする。
【課題を解決するための手段】
【０００５】
この発明に係る異常検出装置は、
定期的に、監視対象におけるリソース使用量を定期量として取得して、前記定期量の特徴を表す定期特徴量を計算する定期分析部と、
イベントの発生時に、前記監視対象におけるリソース使用量をイベント量として取得して、前記イベント量の特徴を表すイベント特徴量を計算するイベント分析部と、
定期判定データ記憶部に記憶された定期判定データと、前記定期分析部によって計算された前記定期特徴量とを比較して、前記監視対象に異常が発生しているか否かを判定するとともに、イベント判定データ記憶部に記憶されたイベント判定データと、前記イベント分析部によって計算された前記イベント特徴量とを比較して、前記監視対象に異常が発生しているか否かを判定する判定部と
を備える。
【発明の効果】
【０００６】
この発明では、定期的な異常の検出と、イベントの発生時における異常の検出とで用いる学習データを分ける。これにより、監視対象の異常を適切に検出することができる。
【図面の簡単な説明】
【０００７】
【図１】実施の形態１に係る異常検出装置１０の構成図。
【図２】実施の形態１に係る定期判定データ記憶部１３１に記憶される情報を示す図。
【図３】実施の形態１に係るイベント判定データ記憶部１３２に記憶される情報を示す図。
【図４】実施の形態１に係る異常検出装置１０の全体的な処理の説明図。
【図５】実施の形態１に係るデータ分析部２１１の処理のフローチャート。
【図６】実施の形態１に係る定期分析部２２１の処理のフローチャート。
【図７】実施の形態１に係る定期特徴量の計算方法の説明図。
【図８】実施の形態１に係るイベント分析部２２２の処理のフローチャート。
【図９】実施の形態１に係るイベント量の補正方法の説明図。
【図１０】実施の形態１に係る判定部２３１及び判定データ更新部２３２の処理のフローチャート。
【図１１】実施の形態１に係るモデル式の係数の更新方法の説明図。
【図１２】変形例１に係る異常検出装置１０の構成図。
【発明を実施するための形態】
【０００８】
実施の形態１．
＊＊＊構成の説明＊＊＊
図１を参照して、実施の形態１に係る異常検出装置１０の構成を説明する。
異常検出装置１０は、監視対象３０の異常を検出するコンピュータである。
監視対象３０は、オペレータ、又は、センサ３２といった外部装置からの入力に基づき、複数のプログラム又は複数の計算機３１が通信データにより連携動作するシステムである。監視対象３０は、１台以上の計算機３１を備える。また、計算機３１には、１台以上のセンサ３２が接続されている場合がある。計算機３１では、複数のプロセスが動作している。計算機３１間と、センサ３２間と、計算機３１とセンサ３２との間と、プロセス間との少なくともいずれかでは通信が行われる。
【０００９】
異常検出装置１０は、プロセッサ１１と、メモリ１２と、ストレージ１３と、通信インタフェース１４とのハードウェアを備える。プロセッサ１１は、信号線を介して他のハードウェアと接続され、これら他のハードウェアを制御する。
【００１０】
プロセッサ１１は、プロセッシングを行うＩＣ（Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）である。プロセッサ１１は、具体例としては、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）、ＤＳＰ（Ｄｉｇｉｔａｌ  Ｓｉｇｎａｌ  Ｐｒｏｃｅｓｓｏｒ）、ＧＰＵ（Ｇｒａｐｈｉｃｓ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）である。
【００１１】
メモリ１２は、データを一時的に記憶する記憶装置である。メモリ１２は、具体例としては、ＳＲＡＭ（Ｓｔａｔｉｃ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、ＤＲＡＭ（Ｄｙｎａｍｉｃ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）である。
【００１２】
ストレージ１３は、データを保管する記憶装置である。ストレージ１３は、具体例としては、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）、又は、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）である。また、ストレージ１３は、ＳＤ（登録商標，Ｓｅｃｕｒｅ  Ｄｉｇｉｔａｌ）メモリカード、ＣＦ（ＣｏｍｐａｃｔＦｌａｓｈ）、ＮＡＮＤフラッシュ、フレキシブルディスク、光ディスク、コンパクトディスク、ブルーレイ（登録商標）ディスク、ＤＶＤ（Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｋ）といった可搬記憶媒体であってもよい。
【００１３】
通信インタフェース１４は、入力装置と表示装置といった外部の装置と通信するためのインタフェースである。通信インタフェース１４は、具体例としては、Ｅｔｈｅｒｎｅｔ（登録商標）、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ）、ＨＤＭＩ（登録商標，Ｈｉｇｈ−Ｄｅｆｉｎｉｔｉｏｎ  Ｍｕｌｔｉｍｅｄｉａ  Ｉｎｔｅｒｆａｃｅ）のポートである。
【００１４】
異常検出装置１０は、機能構成要素として、イベント分析部２１と、リソース分析部２２と、リソース監視部２３とを備える。イベント分析部２１は、データ分析部２１１を備える。リソース分析部２２は、定期分析部２２１と、イベント分析部２２２とを備える。リソース監視部２３は、判定部２３１と、判定データ更新部２３２とを備える。異常検出装置１０の各機能構成要素の機能はソフトウェアにより実現される。
ストレージ１３には、異常検出装置１０の各機能構成要素の機能を実現するプログラムが記憶されている。このプログラムは、プロセッサ１１によりメモリ１２に読み込まれ、プロセッサ１１によって実行される。これにより、異常検出装置１０の各機能構成要素の機能が実現される。
【００１５】
また、ストレージ１３は、定期判定データ記憶部１３１と、イベント判定データ記憶部１３２とを実現する。
【００１６】
図２を参照して、実施の形態１に係る定期判定データ記憶部１３１に記憶される情報を説明する。
定期判定データ記憶部１３１には、周期４１と、定期判定データ４２であるリソーストータル使用量４３及び変化時間４４とが記憶される。
周期４１は、定期的にデータを取得する取得間隔を示す。
リソーストータル使用量４３は、監視対象３０における使用されたリソースのトータル量を示す。リソースとは、監視対象３０が有するＣＰＵとメモリとディスクＩＯ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）といった資源のことである。リソーストータル使用量４３としては、特徴量を表す平均値４３１及び標準偏差４３２が記憶される。
変化時間４４は、リソーストータル使用量４３に変化が発生している時間を示す。具体例としては、変化時間４４は、ＣＰＵの使用量が概ね一定値である場合に、計測時間のうち、ＣＰＵの使用量が前記一定値に対して基準割合以上増えた又は減った時間である。変化時間４４としては、特徴量を表す平均値４４１及び標準偏差４４２が記憶される。
【００１７】
図３を参照して、実施の形態１に係るイベント判定データ記憶部１３２に記憶される情報を説明する。
イベント判定データ記憶部１３２には、データ種別５１と、イベント判定データ５２とが記憶される。イベント判定データ５２には、取得数５３と、リソーストータル使用量／データ５４と、変化時間／データ量５５とが記憶される。
データ種別５１は、通信された通信データの種別を示す。
取得数５３は、取得されたデータ数を示す。
リソーストータル使用量／データ５４は、１データ当たりに使用されたリソースのトータル量を示す。リソーストータル使用量／データ５４としては、特徴量を表すモデル式の情報が記憶される。図３では、モデル式の情報として、モデル式で用いられる係数Ａと係数Ｂと係数Ｃと標準偏差とが記憶されている。
変化時間／データ量５５は、単位データ量当たりの変化時間である。変化時間／データ量５５としては、特徴量を表すモデル式の情報が記憶される。図３では、モデル式の情報として、モデル式で用いられる係数Ｄと係数Ｅと係数Ｆと標準偏差とが記憶されている。
【００１８】
図１では、プロセッサ１１は、１つだけ示されている。しかし、異常検出装置１０は、プロセッサ１１を代替する複数のプロセッサを備えていてもよい。これら複数のプロセッサは、異常検出装置１０の各機能構成要素の実行を分担する。それぞれのプロセッサは、プロセッサ１１と同じように、プロセッシングを行うＩＣである。
【００１９】
図１では、異常検出装置１０を１台の装置として表した。しかし、異常検出装置１０は、複数の装置から構成される異常検出システムであってもよい。具体例としては、異常検出装置１０は、イベント分析部２１を実現する装置と、リソース分析部２２を実現する装置と、リソース監視部２３を実現する装置とから構成される異常検出システムであってもよい。
【００２０】
＊＊＊動作の説明＊＊＊
図４から図１１を参照して、実施の形態１に係る異常検出装置１０の動作を説明する。
実施の形態１に係る異常検出装置１０の動作は、実施の形態１に係る異常検出方法に相当する。また、実施の形態１に係る異常検出装置１０の動作は、実施の形態１に係る異常検出プログラムの処理に相当する。
【００２１】
図４を参照して、実施の形態１に係る異常検出装置１０の全体的な処理を説明する。
（処理Ａ）
イベント分析部２１のデータ分析部２１１は、監視対象３０における通信データを監視する。データ分析部２１１は、通信データが検出された場合には、イベントが発生したとして、リソース分析部２２のイベント分析部２２２に通知する。
【００２２】
（処理Ｂ）
リソース分析部２２の定期分析部２２１は、定期判定データ記憶部１３１から周期４１を読み出して、リソース使用量の取得周期を決定する。定期分析部２２１は、取得周期になると、監視対象３０におけるリソース使用量を定期量として取得して、定期量の特徴を表す定期特徴量を計算する。つまり、定期分析部２２１は、定期的に、定期量を取得して定期特徴量を計算する。定期分析部２２１は、リソース監視部２３に対して定期特徴量を送信する。
【００２３】
（処理Ｃ）
リソース分析部２２のイベント分析部２２２は、処理Ａで通信データが検出されたことが通知されると、監視対象３０におけるリソース使用量をイベント量として取得して、イベント量の特徴を表すイベント特徴量を計算する。イベント分析部２２２は、リソース監視部２３に対してイベント特徴量を送信する。
【００２４】
（処理Ｄ）
リソース監視部２３の判定部２３１は、処理Ｂで定期特徴量が通知されると、定期判定データ記憶部１３１に記憶された定期判定データ４２と、定期分析部２２１によって計算された定期特徴量とを比較する。これにより、判定部２３１は、監視対象３０に異常が発生しているか否かを判定する。判定部２３１は、判定結果を監視対象３０の運用者に通知する。
判定データ更新部２３２は、監視対象３０に異常が発生していないと判定部２３１によって判定された場合に、定期特徴量に基づき、定期判定データ記憶部１３１に記憶された定期判定データを更新する。
【００２５】
（処理Ｅ）
リソース監視部２３の判定部２３１は、処理Ｃでイベント特徴量が通知されると、イベント判定データ記憶部１３２に記憶されたイベント判定データ５２と、イベント分析部２２２によって計算されたイベント特徴量とを比較する。これにより、判定部２３１は、監視対象３０に異常が発生しているか否かを判定する。判定部２３１は、判定結果を監視対象３０の運用者に通知する。
判定データ更新部２３２は、監視対象３０に異常が発生していないと判定部２３１によって判定された場合に、イベント特徴量に基づき、イベント判定データ記憶部１３２に記憶されたイベント判定データを更新する。
【００２６】
図５を参照して、実施の形態１に係るデータ分析部２１１の処理を説明する。
ステップＳ１１では、データ分析部２１１は、監視対象３０における通信データを監視する。
データ分析部２１１は、通信データがあった場合には、処理をステップＳ１２に進める。一方、データ分析部２１１は、通信データがない場合には、処理をステップＳ１１に戻して、再び通信データを監視する。
【００２７】
ステップＳ１２では、データ分析部２１１は、ステップＳ１１で取得された通信データのデータ種別を特定する。データ分析部２１１は、特定されたデータ種別が監視対象であるか否かを判定する。
データ分析部２１１は、データ種別が監視対象である場合には、処理をステップＳ１３に進める。一方、データ分析部２１１は、データ種別が監視対象でない場合には、処理をステップＳ１１に戻して、再び通信データを監視する。
【００２８】
ステップＳ１３では、データ分析部２１１は、ステップＳ１１で取得された通信データが可変長のデータであるか固定長のデータであるかを判定する。
データ分析部２１１は、通信データが可変長のデータである場合には、処理をステップＳ１４に進める。一方、データ分析部２１１は、通信データが固定長のデータである場合には、処理をステップＳ１５に進める。
【００２９】
ステップＳ１４では、データ分析部２１１は、データ長に基づき通信データに含まれるデータの個数を算出する。
【００３０】
ステップＳ１５では、データ分析部２１１は、通信データが発生したことを示す通知データに、データ種別とデータの個数とを含めて、リソース分析部２２のイベント分析部２２２に送信する。
【００３１】
図６を参照して、実施の形態１に係る定期分析部２２１の処理を説明する。
ステップＳ２１では、定期分析部２２１は、定期判定データ記憶部１３１から周期４１を読み出す。定期分析部２２１は、読み出された周期４１に基づき、リソース使用量の取得タイミングを決定する。
【００３２】
ステップＳ２２では、定期分析部２２１は、ステップＳ２１で決定された取得タイミングになると、監視対象３０のリソース使用量を定期量として取得する。ここでは、定期分析部２２１は、予め定められた第１時間分のリソース使用量を定期量として取得する。例えば、定期分析部２２１は、取得タイミングから後の第１時間分のリソース使用量を定期量として取得する。
【００３３】
ステップＳ２３では、定期分析部２２１は、ステップＳ２１で取得された定期量が示すリソーストータル使用量及び変化時間を、定期量の特徴を表す定期特徴量として計算する。
【００３４】
図７を参照して具体的に説明する。
定期分析部２２１は、定期量を計測単位時間毎に正規化して、計測単位時間あたりのリソース使用量を計算する。そして、定期分析部２２１は、計算された計測単位時間あたりのリソース使用量を積分してリソーストータル使用量を計算する。つまり、リソーストータル使用量＝Σ（リソース使用量×計測単位時間）である。また、定期分析部２２１は、計算された計測単位時間あたりのリソース使用量が一定割合以上に変化した変化時間を求める。図７では、リソース使用量が０以外の範囲が変化時間となっている。
【００３５】
ステップＳ２４では、定期分析部２２１は、ステップＳ２３で計算された定期特徴量をリソース監視部２３に対して送信する。
【００３６】
図８を参照して、実施の形態１に係るイベント分析部２２２の処理を説明する。
ステップＳ３１では、イベント分析部２２２は、図５のステップＳ１５で通知データが送信されるまで待機する。
イベント分析部２２２は、通知データが送信された場合には、処理をステップＳ３２に進める。一方、イベント分析部２２２は、通知データが送信されていない場合には、処理をステップＳ３１に戻して、再び待機状態とする。
【００３７】
ステップＳ３２では、イベント分析部２２２は、監視対象３０のリソース使用量をイベント量として取得する。ここでは、イベント分析部２２２は、予め定められた第２時間分のリソース使用量をイベント量として取得する。第１時間と第２時間とは、同じ時間であってもよいし、異なる時間であってもよい。例えば、イベント分析部２２２は、通知データを受信してから後の第２時間分のリソース使用量をイベント量として取得する。
【００３８】
ステップＳ３３では、イベント分析部２２２は、ステップＳ３２の実行中に定期分析部２２１が定期量を取得していたか否かを判定する。
具体的には、イベント分析部２２２は、定期分析部２２１から直近に定期量を取得した第１時間を示す時間情報を取得する。イベント分析部２２２は、取得された時間情報が示す第１時間と、ステップＳ３２でイベント量を取得した第２時間とが重複するか否かを判定する。
イベント分析部２２２は、定期量を取得していた場合には、処理をステップＳ３４に進める。一方、イベント分析部２２２は、定期量を取得していなかった場合には、処理をステップＳ３５に進める。
【００３９】
ステップＳ３４では、イベント分析部２２２は、ステップＳ３３で取得された第１時間とステップＳ３２でイベント量を取得した第２時間との重複する時間について、ステップＳ３２で取得されたイベント量を定期量分減らす。これにより、イベント分析部２２２は、イベント量を補正する。
【００４０】
図９を参照して具体的に説明する。
イベント分析部２２２は、第１時間と第２時間との重複する時間を第３時間として特定する。図９では、時刻ｔ１から時刻ｔ２までの時間が第３時間として特定される。
イベント分析部２２２は、定期判定データ記憶部１３１に記憶された定期判定データ４２に基づき、第３時間における定期量を推定する。つまり、イベント分析部２２２は、第１時間における第３時間の位置と、定期判定データ４２が示すリソーストータル使用量４３の平均値４３１及び標準偏差４３２から、第３時間における定期量を推定する。第１時間における第３時間の位置とは、第１時間の終わりの２０％の時間が第１時間であるといった意味である。図９では、黒塗りの部分が第３時間における定期量として推定される。
イベント分析部２２２は、第３時間におけるイベント量から、第３時間における定期量を減らす。
【００４１】
ステップＳ３５では、イベント分析部２２２は、ステップＳ３４が実行された場合には、ステップＳ３４で補正されたイベント量が示すリソーストータル使用量及び変化時間を、イベント量の特徴を表すイベント特徴量として計算する。一方、イベント分析部２２２は、ステップＳ３４が実行されていない場合には、ステップＳ３３で取得されたイベント量が示すリソーストータル使用量及び変化時間を、イベント量の特徴を表すイベント特徴量として計算する。
イベント特徴量の具体的な計算方法は、図７のステップＳ２３で定期特徴量を計算する方法と同じである。
【００４２】
ステップＳ３６では、イベント分析部２２２は、ステップＳ３５で計算されたイベント特徴量を、ステップＳ１５で通知データに含めて送信されたデータ種別とデータの個数とともにリソース監視部２３に対して送信する。
【００４３】
図１０を参照して、実施の形態１に係る判定部２３１及び判定データ更新部２３２の処理を説明する。
ステップＳ４１では、判定部２３１は、定期特徴量、又は、イベント特徴量が送信されるまで待機する。
判定部２３１は、定期特徴量、又は、イベント特徴量が送信された場合には、定期特徴量、又は、イベント特徴量を受信して処理をステップＳ４２に進める。一方、判定部２３１は、定期特徴量、及び、イベント特徴量が送信されていない場合には、処理をステップＳ４１に戻して、再び待機状態とする。
【００４４】
ステップＳ４２では、判定部２３１は、ステップＳ４１で受信された定期特徴量、又は、イベント特徴量に基づき、トータルリソース使用量が異常であるか否かを判定する。
判定部２３１は、トータルリソース使用量が異常である場合には、処理をステップＳ４４に進める。一方、判定部２３１は、トータルリソース使用量が異常でない場合には、処理をステップＳ４３に進める。
【００４５】
具体的には、判定部２３１は、ステップＳ４１で定期特徴量が受信された場合には、定期判定データ記憶部１３１に記憶されたリソーストータル使用量４３に基づき、定期特徴量が示すリソーストータル使用量が異常であるか否かを判定する。例えば、判定部２３１は、リソーストータル使用量４３の平均値４３１及び標準偏差４３２から基準使用量を計算する。判定部２３１は、定期特徴量が示すリソーストータル使用量が、計算された基準使用量を基準とする閾範囲（例えば、±１０％）の範囲外である場合に、異常であると判定する。
【００４６】
また、判定部２３１は、ステップＳ４１でイベント特徴量が受信された場合には、イベント判定データ記憶部１３２に記憶されたリソーストータル使用量／データ５４に基づき、リソース特徴量が示すリソーストータル使用量が異常であるか否かを判定する。この際、判定部２３１は、通知データに含められたデータ種別５１に対応したリソーストータル使用量／データ５４を用いる。例えば、判定部２３１は、イベント特徴量が示すリソーストータル使用量を、ステップＳ３６で送信されたデータの個数で除して、１つのデータ当たりのリソーストータル使用量を計算する。また、判定部２３１は、ステップＳ３６で送信されたデータ種別に対応するリソーストータル使用量／データ５４のモデル式から基準使用量を計算する。判定部２３１は、計算された１つのデータ当たりのリソーストータル使用量が、計算された基準使用量を基準とする閾範囲（例えば、±１０％）の範囲外である場合に、異常であると判定する。
【００４７】
ステップＳ４３では、判定部２３１は、ステップＳ４１で受信された定期特徴量、又は、イベント特徴量に基づき、変化時間が異常であるか否かを判定する。
判定部２３１は、変化時間が異常である場合には、処理をステップＳ４４に進める。一方、判定部２３１は、変化時間が異常でない場合には、処理をステップＳ４６に進める。
【００４８】
具体的には、判定部２３１は、ステップＳ４１で定期特徴量が受信された場合には、定期判定データ記憶部１３１に記憶された変化時間４４に基づき、定期特徴量が示す変化時間が異常であるか否かを判定する。例えば、判定部２３１は、変化時間４４の平均値４４１及び標準偏差４４２から基準変化時間を計算する。判定部２３１は、定期特徴量が示す変化時間が、計算された基準変化時間を基準とする閾範囲（例えば、±１０％）の範囲外である場合に、異常であると判定する。
【００４９】
また、判定部２３１は、ステップＳ４１でイベント特徴量が受信された場合には、イベント判定データ記憶部１３２に記憶された変化時間／データ量５５に基づき、リソース特徴量が示す変化時間が異常であるか否かを判定する。この際、判定部２３１は、通知データに含められたデータ種別５１に対応した変化時間／データ量５５を用いる。例えば、判定部２３１は、ステップＳ３６で送信されたデータ種別に対応するリソーストータル使用量／データ５４のモデル式と、ステップＳ３６で送信されたデータの個数とから基準変化時間を計算する。判定部２３１は、イベント特徴量が示す変化時間が、計算された基準変化時間を基準とする閾範囲（例えば、±１０％）の範囲外である場合に、異常であると判定する。
【００５０】
ステップＳ４４では、判定部２３１は、ステップＳ４１で受信された定期特徴量、又は、イベント特徴量と、異常と判定された際に用いられた基準使用量、又は、基準変化時間とをメモリ１２に書き込む。そして、判定部２３１は、異常が検出されたことを運用者に通知する。
【００５１】
ステップＳ４５では、判定部２３１は、運用者から異常が発生していたか否かの評価結果の入力を受け付ける。この際、運用者は、メモリ１２に記憶された定期特徴量、又は、イベント特徴量と、異常と判定された際に用いられた基準使用量、又は、基準変化時間とを参照する等して、異常が発生しているか否かを判断する。
判定部２３１は、異常が発生しているとの評価結果が入力された場合には、処理をステップＳ４１に戻す。一方、判定部２３１は、異常が発生していないとの評価結果が入力された場合には、処理をステップＳ４６に進める。
【００５２】
ステップＳ４６では、判定データ更新部２３２は、ステップＳ４１で定期特徴量が受信された場合には、定期特徴量に基づき定期判定データ記憶部１３１に記憶された定期判定データ４２を更新する。具体的には、判定データ更新部２３２は、定期特徴量を用いて、リソーストータル使用量４３の平均値４３１及び標準偏差４３２と、変化時間４４の平均値４４１及び標準偏差４４２とを計算し直す。
判定データ更新部２３２は、ステップＳ４１でイベント特徴量が受信された場合には、イベント特徴量に基づき、イベント判定データ記憶部１３２に記憶されたイベント判定データ５２を更新する。具体的には、判定データ更新部２３２は、イベント特徴量を用いて、リソーストータル使用量／データ５４のモデル式の係数及び標準偏差と、変化時間／データ量５５のモデル式の係数及び標準偏差を計算し直す。また、判定データ更新部２３２は、ステップＳ３６で送信されたデータの個数を取得数５３に加算する。
【００５３】
図１１を参照して、実施の形態１に係るモデル式の係数の更新方法を説明する。
判定データ更新部２３２は、リソーストータル使用量について、同一のデータ種別毎に、データの個数が異なるリソーストータル使用量に基づき、２次方程式といったモデル式の係数を計算する。変化時間についても同様に、判定データ更新部２３２は、同一のデータ種別毎に、データの個数が異なる変化時間に基づき、２次方程式といったモデル式の係数を計算する。
【００５４】
＊＊＊実施の形態１の効果＊＊＊
以上のように、実施の形態１に係る異常検出装置１０は、定期的な異常の検出と、イベントの発生時における異常の検出とで用いる学習データを分ける。これにより、リソース使用量の定期的な変動だけでなく、イベントの発生時の変動についても適切に学習することができる。その結果、監視対象の異常を適切に検出することができる。
【００５５】
また、実施の形態１に係る異常検出装置１０は、定期的なリソース使用量の収集タイミングと、イベント発生時のリソース使用量の収集タイミングとが重なった場合に、リソース使用量を補正した上で、異常の検出を行う。これにより、監視対象の異常を適切に検出することができる。
【００５６】
＊＊＊他の構成＊＊＊
＜変形例１＞
実施の形態１では、異常検出装置１０の各機能構成要素の機能がソフトウェアで実現された。しかし、変形例１として、異常検出装置１０の各機能構成要素の機能はハードウェアで実現されてもよい。この変形例１について、実施の形態１と異なる点を説明する。
【００５７】
図１２を参照して、変形例１に係る異常検出装置１０の構成を説明する。
異常検出装置１０の各機能構成要素の機能がハードウェアで実現される場合、異常検出装置１０は、プロセッサ１１とメモリ１２とストレージ１３とに代えて、電子回路１５を備える。電子回路１５は、異常検出装置１０の各機能構成要素の機能と、メモリ１２とストレージ１３との機能とを実現する専用の回路である。
【００５８】
電子回路１５は、単一回路、複合回路、プログラム化したプロセッサ、並列プログラム化したプロセッサ、ロジックＩＣ、ＧＡ（Ｇａｔｅ  Ａｒｒａｙ）、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）、ＦＰＧＡ（Ｆｉｅｌｄ−Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ）が想定される。
異常検出装置１０の各機能構成要素の機能を１つの電子回路１５で実現してもよいし、異常検出装置１０の各機能構成要素の機能を複数の電子回路１５に分散させて実現してもよい。
【００５９】
＜変形例２＞
変形例２として、一部の機能がハードウェアで実現され、他の機能がソフトウェアで実現されてもよい。つまり、異常検出装置１０の各機能構成要素の機能のうち、一部の機能がハードウェアで実現され、他の機能がソフトウェアで実現されてもよい。
【００６０】
プロセッサ２１と電子回路１５とを、処理回路という。つまり、各機能構成要素の機能は、処理回路により実現される。
【符号の説明】
【００６１】
１０  異常検出装置、１１  プロセッサ、１２  メモリ、１３  ストレージ、１３１  定期判定データ記憶部、１３２  イベント判定データ記憶部、１４  通信インタフェース、１５  電子回路、２１  イベント分析部、２１１  データ分析部、２２  リソース分析部、２２１  定期分析部、２２２  イベント分析部、２３  リソース監視部、２３１  判定部、２３２  判定データ更新部、３０  監視対象、３１  計算機、３２  センサ、４１  周期、４２  定期判定データ、４３  リソーストータル使用量、４３１  平均値、４３２  標準偏差、４４  変化時間、４４１  平均値、４４２  標準偏差、５１  データ種別、５２  イベント判定データ、５３  取得数、５４  リソーストータル使用量／データ、５５  変化時間／データ量。
【図１】
2019003303.tif 000003
【図２】
2019003303.tif 000004
【図３】
2019003303.tif 000005
【図４】
2019003303.tif 000006
【図５】
2019003303.tif 000007
【図６】
2019003303.tif 000008
【図７】
2019003303.tif 000009
【図８】
2019003303.tif 000010
【図９】
2019003303.tif 000011
【図１０】
2019003303.tif 000012
【図１１】
2019003303.tif 000013
【図１２】
2019003303.tif 000014