JP2021149849A - 障害原因特定システム、障害原因特定方法および障害原因特定プログラム - Google Patents

Abstract

【課題】障害原因の特定に要する時間を短縮することで、ＩＣＴインフラストラクチャの運用を効率化する。【解決手段】障害原因特定システム１５０は、第１の考え方（「複数の異常が同時に発生する場合、共通の要因が存在する」）に基づいて、ネットワークシステム１００の構成情報からアプリケーションに異常が生じたノードと関連のある関連ノードを抽出する。抽出した関連ノードの各メトリックを「目的変数」とし、その他を「説明変数」の候補とし、その候補中から、各目的変数について予測モデルに使える説明変数を選択する。目的変数の異常をＪＩＴ判定により検出し、異常を検出した目的変数と、その説明変数を検出する。つぎに、第２の考え方（「複数の異常に共通する要因があれば、それが異常原因である可能性が高い」）に基づいて、異常を検出した目的変数の各説明変数に共通する目的変数の数を抽出し、その数が最多のものが、異常原因候補第１位となる。【選択図】図１

Description

本発明は、障害原因特定システム、障害原因特定方法および障害原因特定プログラムに関する。

近年、コンピュータネットワークシステムにおいて、ＩＴサービスのコンテナ化、マイクロサービス化により、サービスを構成する要素が増加している。それにともない、ＩＣＴ（Ｉｎｆｏｒｍａｔｉｏｎ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ）インフラストラクチャの運用管理が複雑化しており、その運用の効率化が求められている。そのため、システム内で障害が発生した場合に、その異常箇所を特定する技術がある。

また、関連する先行技術としては、コンピュータネットワークシステムにおいて、障害が発生した第１機器を示す障害発生情報を取得し、その第１機器を起点として、障害の影響がおよぶ可能性のある第１影響範囲内に存在する複数の第２機器を探索する。そして、複数の第２機器それぞれについて、異常が起きているか否かを判定し、異常が起きている第３機器を起点として、第３機器の異常の影響がおよぶ可能性のある第２影響範囲内に存在するか否かの判定結果に基づいて、複数の第２機器それぞれについてランクを決定する技術がある（下記特許文献１を参照）。これにより、障害の影響を受ける可能性の高さの違いが判別可能となる影響範囲を特定でき、影響がすでに出ている機器だけでなく、まだ検知されていないが影響を受ける機器も探索し、障害影響のランク付けをおこない、障害影響範囲を絞り込むことができる。

特開２０１８−２０５８１１号公報

しかしながら、従来技術にあっては、異常（障害）の有無を判定することができても、障害の原因箇所を明らかにすることができない。したがって、異常箇所をそれぞれ確認する必要があるため、複数の異常箇所がある場合には時間がかかるという問題点がある。また、関連する先行技術にあっては、障害影響範囲を絞り込んで、影響を受ける箇所をそれぞれ確認しても、障害の原因特定には時間がかかるという問題点がある。

一つの側面では、本発明は、障害原因の特定に要する時間を短縮することで、ＩＣＴインフラストラクチャの運用を効率化することを目的とする。

一つの実施態様では、複数のノードから構成されるネットワークシステムにおいて異常が発生したノードと関連のある関連ノードを抽出し、抽出された関連ノードと当該関連ノードの稼働データとの各組み合わせをそれぞれ目的変数とし、当該目的変数以外の組み合わせのうち、当該目的変数についての予測モデルとして使用できる組み合わせを、当該目的変数の説明変数としてそれぞれ選択し、選択された説明変数を用いておこなわれた異常検出において、異常が検出された異常検出目的変数と、当該異常検出目的変数の説明変数を抽出し、抽出された異常検出目的変数の説明変数に共通する目的変数の数を算出し、算出された目的変数の数に基づいて、障害原因箇所の優先順位を設定する、制御部を有する障害原因特定システムが提供される。

本発明の一側面によれば、障害原因の特定に要する時間を短縮することで、ＩＣＴインフラストラクチャの運用を効率化することができる。

図１は、実施の形態にかかる障害原因特定システム、障害原因特定方法および障害原因特定プログラムの概要の一例を示す説明図である。 図２は、ネットワークシステムのシステム構成の一例を示す説明図である。 図３Ａは、ネットワークシステムを構成する管理サーバ、ネットワーク（ＮＷ）機器、データベース、サーバのハードウェア構成の一例を示すブロック図である。 図３Ｂは、ネットワークシステムを構成するユーザ端末装置のハードウェア構成の一例を示すブロック図である。 図４は、実施の形態にかかる障害原因特定システムの機能的構成の一例を示すブロック図である。 図５は、ノード検出部に対する入力データ（「構成情報」）、出力データ（「関連ノード情報」）の関係の一例を示す説明図である。 図６は、ノード検出処理の手順の一例を示すフローチャートである。 図７は、説明変数選択部に対する入力データ（「関連ノード情報」）、出力データ（「説明変数選択結果」）の関係の一例を示す説明図である。 図８は、説明変数選択処理の手順の一例を示すフローチャートである。 図９は、ＪＩＴ判定部に対する入力データ（「説明変数選択結果」）、出力データ（「異常判定結果」）の関係の一例を示す説明図である。 図１０は、ＪＩＴ判定処理の手順の一例を示すフローチャートである。 図１１は、異常検出変数抽出部に対する入力データ（「異常判定結果」）、出力データ（「異常検出した目的変数」）の関係の一例を示す説明図である。 図１２は、異常検出変数抽出処理の手順の一例を示すフローチャートである。 図１３は、共通目的変数算出部に対する入力データ（「異常検出した目的変数」）、出力データ（「共通する目的変数の数」）の関係の一例を示す説明図である。 図１４は、共通目的変数算出処理の手順の一例を示すフローチャートである。 図１５は、優先順位設定部に対する入力データ（「共通する目的変数の数」）、出力データ（「調査優先度」）の関係の一例を示す説明図である。 図１６は、優先順位設定処理の手順の一例を示すフローチャートである。 図１７は、表示画面の一例を示す説明図である。

以下に図面を参照して、本発明にかかる、障害原因特定システム、障害原因特定方法および障害原因特定プログラムの実施の形態を詳細に説明する。

（実施の形態）
（障害原因特定処理の概要）
図１は、実施の形態にかかる障害原因特定システム、障害原因特定方法および障害原因特定プログラムの概要の一例を示す説明図である。図１においては、ネットワークシステム１００は、アプリケーション（Ａｐｐ１（１０１）〜Ａｐｐ４（１０４））、コンテナ（コンテナ１（１１１）〜コンテナ４（１１４））、バーチャルマシン（ＶＭ１（１２１）、ＶＭ２（１２２））、サーバ（Ｓｅｒｖｅｒ１（１３１）、Ｓｅｒｖｅｒ２（１３２））、スイッチ（ＳＷ）１４１などのノードにより構成されている。

また、各ノードには、それぞれ稼働データである「メトリック」が存在する。図１に示すように、アプリケーション（Ａｐｐ１（１０１）〜Ａｐｐ４（１０４））のメトリックは、具体的には、たとえば、（ＨＴＴＰリクエストなどの）応答時間、リクエスト数などである。また、コンテナ（コンテナ１（１１１）〜コンテナ４（１１４））、バーチャルマシン（ＶＭ１（１２１）、ＶＭ２（１２２））、サーバ（Ｓｅｒｖｅｒ１（１３１）、Ｓｅｒｖｅｒ２（１３２））のメトリックは、たとえば、コア使用時間、メモリ使用量、ディスクＩＯ（書き込み／読み込み）量、ＮＷ（ネットワーク）ＩＯ（受信／送信）量などである。また、スイッチ（ＳＷ）１４１のメトリックは、たとえば、ＮＷＩＯ量などである。ネットワークシステム１００において障害（異常）箇所は、この「ノード＋メトリック」の単位であるとする。

このネットワークシステム１００において障害（異常）が発生した場合に、障害原因特定システム１５０は、その障害原因、すなわち、「ノード＋メトリック」の単位で障害箇所を特定する。その際に、障害原因特定システム１５０は、２つの考え方に基づいて、障害原因の特定をおこなう。第１は、『複数の異常が同時に発生する場合、共通の要因が存在する』という考え方である。第２は、『複数の異常に共通する要因があれば、それが異常原因である可能性が高い』という考え方である。

第１の考え方（『複数の異常が同時に発生する場合、共通の要因が存在する』）に基づいて、障害原因特定システム１５０は、ネットワークシステム１００の構成情報からアプリケーションに異常が生じたノード（図１において、障害マークを付したノード（たとえば、Ａｐｐ１（１０１）、コンテナ３（１１３）などの６個のノード））と関連のある関連ノード（図１において、楕円で囲ったノード（たとえば、コンテナ１（１１１）、Ａｐｐ３（１０３）などの９個のノード））を抽出する。

つぎに、障害原因特定システム１５０は、抽出した関連ノードと、当該関連ノードの各メトリック（各ノードの応答時間、リクエスト数、ＮＷＩＯ量など）のそれぞれの組み合わせを「目的変数」とし、その他のノードとメトリックの組み合わせを「説明変数」の候補とする。そして、「説明変数」の候補の中から、各目的変数について近似モデルに使える説明変数を選択する。ここで、「目的変数」とは、予測したい変数、すなわち、物事の結果を示す。また、「説明変数」とは、目的変数を説明する変数、すなわち、物事の原因を示す。したがって、「目的変数」が、障害が発生したノードに関連するノードとそのメトリックとの組み合わせであり、「説明変数」が、その障害の原因となったノードとそのノードのメトリックとの組み合わせである。

つぎに、目的変数の異常を検出する。具体的には、たとえば、選択した説明変数を用いて、ＪＩＴ（Ｊｕｓｔ−Ｉｎ−Ｔｉｍｅ）判定をおこない、実際に異常が発生しているかを検証する。ＪＩＴ判定の詳細な内容については、後述する。そして、異常を検出した目的変数（ノード＋メトリックの組み合わせ）と、その説明変数（ノード＋メトリックの組み合わせ）を検出する。

その後、第２の考え方（『複数の異常に共通する要因があれば、それが異常原因である可能性が高い』）に基づいて、障害原因特定システム１５０は、異常を検出した目的変数の各説明変数（ノード＋メトリックの組み合わせ）に共通する目的変数（ノード＋メトリックの組み合わせ）の数を抽出する。そして、その説明変数を目的変数としたとき異常検出しており、かつ、共通する目的変数の数が大きい順に調査の優先順位を付ける。共通する目的変数の数が最多のものが、異常原因候補第１位となる。

図１において、説明変数のうち、ノード＋メトリックの組み合わせ：「ＶＭ１（１２１）・ＮＷＩＯ量」が、共通する３つの目的変数（「Ａｐｐ１（１０１）・応答時間」、「Ａｐｐ３（１０３）・応答時間」、「ＶＭ２（１２２）・ＮＷＩＯ量」）を有しており、障害原因特定システム１５０は、この説明変数（「ＶＭ１（１２１）・ＮＷＩＯ量」）が、共通する目的変数の数が最多であり、異常原因候補第１位であることを特定することができる。

このように、障害原因特定システム１５０は、上述した２つの考え方に基づいて、障害原因特定処理をおこなうことで、より適切な異常原因候補の順位付けをすることができる。

（ネットワークシステムのシステム構成）
図２は、ネットワークシステムのシステム構成の一例を示す説明図である。図２において、ＩＣＴインフラストラクチャを実現するネットワークシステム１００は、ネットワーク２００によってそれぞれ接続された、管理サーバ２０１、ネットワーク機器２０２、データベース２０３、サーバ２０４、ユーザ端末装置２０５などの各ハードウェア装置あるいはハードウェア機器（以下、「ハードウェア装置」という）から構成される。また、サーバ２０４には、各種のアプリケーション２０６がインストールされている。

ネットワーク２００は、具体的には、たとえば、Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＬＡＮ）や、広域通信網であるＷｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＷＡＮ）などである。ネットワーク２００の通信形式は、有線通信であってもよく、また、無線通信であってもよく、有線通信と無線通信とが混在していてもよい。

管理サーバ２０１は、たとえば、ネットワーク２００における通信処理を管理するハードウェア装置である。また、ネットワーク機器２０２は、たとえば、データ通信の流れを司るハードウェア機器である。ネットワーク機器２０２は、具体的には、たとえば、スイッチ（ＳＷ）やルーターなどによって構成される。データベース２０３は、たとえば、検索や蓄積が容易にできるよう整理された情報を収集し、蓄積したハードウェア装置である。サーバ２０４は、たとえば、サービスや機能を提供するコンピュータ（ハードウェア装置）である。ユーザ端末装置２０５は、たとえば、ユーザが操作するコンピュータ（ハードウェア装置）である。

これらのハードウェア装置２０１〜２０５における稼働データ（メトリック）には、たとえば、「ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）使用率」、「プロセッサーのエラーイベント数」、「実行キューの長さ」、「メモリ使用量」、「メモリ不足エラーイベント数」、「ＯＯＭ（Ｏｕｔ Ｏｆ Ｍｅｍｏｒｙ）キラーイベント数」、「スワップ使用量」、「読み取り・書き込み平均待機時間」、「読み取り量・書き込み量」、「ファイルシステムエラー・ディスクエラー数」、「Ｉ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）キューの深さ」、「ネットワークドライバキュー長」、「１秒当たりの受信バイト数・送信バイト数・パケット数」、「ネットワークデバイスエラー」、「ドロップされたパケット」などが含まれていてもよい。

アプリケーション２０６は、たとえば、ユーザの業務に応じて作成されたプログラム（ソフトウェア）である。アプリケーション２０６には、たとえばＷＥＢアプリケーションなどがある。アプリケーション２０６は、図１に示したアプリケーション１０１〜１０４のほか、コンテナ１１１〜１１４や、バーチャルマシン１２１、１２２などが含まれていてもよい。

アプリケーション２０６の一例としてのＷＥＢアプリケーションにおける稼働データ（メトリック）には、「ページの平均接続時間」、「平均レスポンス時間」、「トランザクション中断数」、「ｈｔｔｐリクエスト数」などが含まれていてもよい。

（ネットワークシステムのハードウェア構成）
図３Ａは、ネットワークシステムを構成する管理サーバ、ネットワーク（ＮＷ）機器、データベース、サーバのハードウェア構成の一例を示すブロック図である。図３Ａにおいて、各ハードウェア装置、すなわち、管理サーバ２０１、ネットワーク機器２０２、データベース２０３、サーバ２０４は、ＣＰＵ３０１と、メモリ３０２と、ネットワークＩ／Ｆ（Ｉｎｔ１ｅｒｆａｃｅ）３０３と、記録媒体Ｉ／Ｆ３０４と、記録媒体３０５と、を有する。また、各構成部３０１〜３０４は、バス３００によってそれぞれ接続されている。

ここで、ＣＰＵ３０１は、各ハードウェア装置の全体の制御を司る。メモリ３０２は、たとえば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）およびフラッシュＲＯＭなどを有する。具体的には、たとえば、フラッシュＲＯＭやＲＯＭが各種プログラムを記憶し、ＲＡＭがＣＰＵ３０１のワークエリアとして使用される。メモリ３０２に記憶されるプログラムは、ＣＰＵ３０１にロードされることで、コーディングされている処理をＣＰＵ３０１に実行させる。これにより、たとえば、サーバ２０４は、サーバ２０４にインストールされているアプリケーション２０６を実行することができる。

ネットワークＩ／Ｆ３０３は、通信回線を通じてネットワーク２００に接続され、ネットワーク２００を介して他の装置（たとえば、他のハードウェア装置２０１〜２０５など）に接続される。そして、ネットワークＩ／Ｆ３０３は、ネットワーク２００と自装置内部とのインタフェースを司り、他の装置からのデータの入出力を制御する。ネットワークＩ／Ｆ３０３には、たとえば、モデムやＬＡＮアダプタなどを採用することができる。

記録媒体Ｉ／Ｆ３０４は、ＣＰＵ３０１の制御にしたがって記録媒体３０５に対するデータのリード／ライトを制御する。記録媒体３０５は、記録媒体Ｉ／Ｆ３０４の制御で書き込まれたデータを記憶する。記録媒体３０５としては、たとえば、磁気ディスク、光ディスクなどが挙げられる。

なお、ハードウェア装置２０１〜２０５は、上述した構成部３０１〜３０５のほかに、たとえば、図示を省略する、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、キーボード、ポインティングデバイス、ディスプレイなどを有することにしてもよい。

図３Ｂは、ネットワークシステムを構成するユーザ端末装置のハードウェア構成の一例を示すブロック図である。図３Ｂにおいて、ユーザ端末装置２０５は、ＣＰＵ３５１と、メモリ３５２と、ネットワークＩ／Ｆ３５３と、ディスプレイ３５４と、入出力装置３５５と、を有する。また、各構成部３５１〜３５５は、バス３５０によってそれぞれ接続される。

ＣＰＵ３５１は、図３Ａに示したＣＰＵ３０１と同様に、ユーザ端末装置２０５の全体の制御を司る。メモリ３５２は、図３Ａに示したメモリ３０２と同様に、たとえば、ＲＯＭ、ＲＡＭおよびフラッシュＲＯＭなどを有する。具体的には、たとえば、フラッシュＲＯＭやＲＯＭが各種プログラムを記憶し、ＲＡＭがＣＰＵ３５１のワークエリアとして使用される。メモリ３５２に記憶されるプログラムは、ＣＰＵ３５１にロードされることで、コーディングされている処理をＣＰＵ３５１に実行させる。

ネットワークＩ／Ｆ３５３は、図３Ａに示したネットワークＩ／Ｆ３０３と同様に、通信回線を通じてネットワーク２００に接続され、ネットワーク２００を介して他の装置（たとえば、他のハードウェア装置２０１〜２０５など）に接続される。そして、ネットワークＩ／Ｆ３５３は、ネットワーク２００と自装置内部とのインタフェースを司り、他の装置からのデータの入出力を制御する。ネットワークＩ／Ｆ３５３には、たとえば、モデムやＬＡＮアダプタなどを採用することができる。

ディスプレイ３５４は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。ディスプレイ３５４としては、たとえば、液晶ディスプレイ、有機ＥＬ（Ｅｌｅｃｔｒｏｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイなどを採用することができる。このディスプレイ３５４によって、後述する図１７に示す表示画面を表示することができる。

入出力装置３５５は、文字、数字、各種指示などの入力のためのキーを有し、データの入力をおこなう。入出力装置３５５は、キーボードや、マウスなどのポインティングデバイスであってもよく、また、タッチパネル式の入力パッドやテンキーなどであってもよい。また、入出力装置４０５は、プリンタなどの印刷装置であってもよい。なお、ユーザ端末装置２０５は、上述した構成部のほかに、たとえば、ＳＳＤ、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）などを有することにしてもよい。

（障害原因特定システムの機能的構成）
図４は、実施の形態にかかる障害原因特定システムの機能的構成の一例を示すブロック図である。図４において、障害原因特定システム１５０は、制御部４００を有する。そして、この制御部４００は、ノード検出部４０１、説明変数選択部４０２、ＪＩＴ（Ｊｕｓｔ−Ｉｎ−Ｔｉｍｅ）判定部４０３、異常検出変数抽出部４０４、共通目的変数算出部４０５、優先順位設定部４０６の各構成部を含んでいる。

制御部４００は、図２に示したネットワークシステム１００のハードウェア装置によってその機能を実現することができる。すなわち、制御部４００は、図３Ａに示したハードウェア装置２０１〜２０４のＣＰＵ３０１が、メモリ３０２や記録媒体３０５に記録されたプログラムを実行することによって、その機能を実現することができる。あるいは、図３Ｂに示したユーザ端末装置２０５のＣＰＵ３５１が、メモリ３５２に記録されたプログラムを実行することによって、その機能を実現することができる。制御部４００は、各構成部４０１〜４０６の機能を、いずれかのハードウェア装置２０１〜２０５のいずれか、具体的には、たとえば、ネットワークシステム１００の管理サーバ２０１によって実現するようにしてもよい。また、制御部４００は、各構成部４０１〜４０６の各機能を、管理サーバ２０１および管理サーバ２０１以外のハードウェア装置２０２〜２０５によって、分散して実現するようにしてもよい。

ノード検出部４０１は、複数のノードから構成されるネットワークシステム１００において異常が発生したノードと関連のある関連ノードを抽出する。ノードの異常は、たとえば、各ノードの監視プログラム（アプリケーション監視プログラム、コンテナ監視プログラムなど）によって、その発生を検出することができる。異常が発生したノードと関連のある関連ノードの抽出は、たとえば、当該異常が発生したノードと、ネットワークシステム１００において通信経路が繋がっているかということに基づいて判断し、その判断結果に基づいておこなうことができる。

説明変数選択部４０２は、ノード検出部４０１によって抽出された関連ノードと当該関連ノードの稼働データ（メトリック）との各組み合わせを、それぞれ「目的変数」とする。具体的には、たとえば、関連ノードが２つ（ノードＡ、ノードＢ）抽出され、それぞれメトリックを２つずつ（メトリックａ、メトリックｂ）有する場合、「目的変数」は、組み合わせ１（ノードＡ＋メトリックａ）、組み合わせ２（ノードＡ＋メトリックｂ）、組み合わせ３（ノードＢ＋メトリックａ）、組み合わせ４（ノードＢ＋メトリックｂ）の４つとなる。

つぎに、説明変数選択部４０２は、当該目的変数以外の組み合わせのうち、当該目的変数についての予測モデルとして使用できる組み合わせを、当該目的変数の説明変数としてそれぞれ選択する。目的変数以外の組み合わせは、具体的には、たとえば、組み合わせ１を「目的変数」とした場合、組み合わせ２、組み合わせ３、組み合わせ４が、その「説明変数」となる。また、組み合わせ２を「目的変数」とした場合、組み合わせ１、組み合わせ３、組み合わせ４が、その「説明変数」となる。同様に、「目的変数」＝「組み合わせ３」の場合、「説明変数」＝「組み合わせ１、２、４」、「目的変数」＝「組み合わせ４」の場合、「説明変数」＝「組み合わせ１、２、３」となる。

そして、各目的変数に対する説明変数の中から予測モデルとして使用できる組み合わせのみを選択する。予測モデルに基づいて選択するとは、具体的には、たとえば、各ノードがポートごとに分かれている場合に、関連ノードと異なるポートにおける関連ノードにおける説明変数を除外するなどである。このように、説明変数の中から予測モデルとして使用できる組み合わせのみを選択することで、説明変数の数を減少させ、処理を迅速化することができる。

さらに、説明変数の選択を機械的におこなう方法もある。たとえば、目的変数に対する寄与率が大きい変数を逐次的に追加していき、一定の規則に従って停止する変数増加法であったり、それとは逆に、目的変数に対する単寄与率が小さい変数を逐次的に除去していく変数減少法であったり、それらを組み合わせた変数増減法などがあってもよい。

ＪＩＴ判定部４０３は、説明変数選択部４０２によって選択された説明変数を用いて異常検出をおこなう。この異常検出は、たとえば、ジャストインタイム（Ｊｕｓｔ−Ｉｎ−Ｔｉｍｅ（ＪＩＴ））判定によりおこなうことができる。

ＪＩＴ判定部４０３は、たとえば、目的変数（たとえばＨＴＴＰ応答遅延など）の予測値と観測値のずれが大きいときに、異常が発生したと判定する。具体的には、たとえば、はじめに、目的変数と説明変数（たとえばＨＴＴＰリクエスト数など）の観測値を計測し保存しておく。つぎに、判定時刻の説明変数の観測値に近い過去の説明変数の値から目的変数の予測モデルを作成し、予測値と予測値の分散を計算する。そして、目的変数の予測値の分散範囲（正常範囲）から観測値が逸脱すると異常と判定する。このようにして、各ノード＋メトリックの組み合わせごとに、実際に異常が発生しているかどうかを判定することができる。

異常検出変数抽出部４０４は、選択された説明変数を用いておこなわれた異常検出において、異常が検出された異常検出目的変数と、当該異常検出目的変数の説明変数を抽出する。異常検出変数抽出部４０４は、具体的には、たとえば、ＪＩＴ判定部４０３によるＪＩＴ判定の結果に基づいて、実際に異常が発生していると判定されたノード＋メトリックの組み合わせにかかる目的変数を異常検出目的変数（異常検出した目的変数）として抽出する。

また、異常検出変数抽出部４０４は、選択された説明変数を用いておこなわれた異常検出において、異常が検出されなかった異常非検出目的変数と、当該異常非検出目的変数の説明変数を抽出するようにしてもよい。異常検出変数抽出部４０４は、具体的には、たとえば、ＪＩＴ判定部４０３によるＪＩＴ判定の結果に基づいて、実際に異常が発生しないないと判定されたノード＋メトリックの組み合わせにかかる目的変数を異常非検出目的変数（異常検出しなかった目的変数）として抽出するようにしてもよい。

共通目的変数算出部４０５は、異常検出変数抽出部４０４によって抽出された異常検出目的変数の説明変数に共通する目的変数の数を算出する。共通目的変数算出部４０５は、具体的には、たとえば、異常検出目的変数以外の目的変数において、異常検出目的変数の説明変数のノード＋メトリックの組み合わせと同じ組み合わせを説明変数としている目的変数がいくつあるかを算出する。

また、共通目的変数算出部４０５は、異常検出変数抽出部４０４によって抽出された異常非検出目的変数の説明変数に共通する目的変数の数を算出するようにしてもよい。共通目的変数算出部４０５は、具体的には、たとえば、異常非検出目的変数以外の目的変数において、異常非検出目的変数の説明変数のノード＋メトリックの組み合わせと同じ組み合わせを説明変数としている目的変数がいくつあるかを算出するようにしてもよい。

優先順位設定部４０６は、共通目的変数算出部４０５によって算出された目的変数の数に基づいて、障害原因箇所の優先順位を設定する。具体的には、たとえば、異常検出目的変数の説明変数のうち、算出された目的変数の数が多い順に優先順位を高くする。したがって、算出された目的変数の数が最多の説明変数であるノード＋メトリックの組み合わせを、障害原因箇所候補の第１位とすることができる。

優先順位設定部４０６は、たとえば、異常非検出目的変数の説明変数のうち、算出された目的変数の数が多い順に優先順位を高くするようにしてもよい。そして、算出された目的変数の数が最多の説明変数であるノード＋メトリックの組み合わせを、異常検出目的変数の説明変数の優先順位の最下位のつぎの順位とするようにしてもよい。このように、異常検出目的変数だけの順位ではなく、異常非検出目的変数の順位も加味して、障害原因箇所候補の順位を設定することで、より適切な優先順位とすることができる。

また、上述した説明変数選択部４０２は、所定のタイミングで、所定のノードと当該所定のノードの稼働データとの各組み合わせをそれぞれ目的変数とし、当該目的変数以外の組み合わせのうち、当該目的変数についての予測モデルとして使用できる組み合わせを説明変数として選択し、当該選択の結果を記憶しておくようにしてもよい。そして、ＪＩＴ判定部４０３は、ネットワークシステム１００を構成するノードに異常が発生した場合に、記憶された選択の結果にかかる説明変数を用いて、異常検出をおこなうようにしてもよい。

この所定のタイミングは、たとえば、ネットワークシステム１００を構成するノードの起動時または当該起動時から所定時間が経過した時であってもよい。また、この所定のタイミングは、ネットワークシステム１００の構成に変化があったときであってもよい。また、この所定のタイミングは、ユーザによるトリガーがあったときであってもよい。このように、説明変数選択処理を、異常が発生する前に、事前におこなっておくことによって、異常が発生した際のレスポンスをより早くすることができる。

また、上述したＪＩＴ判定部４０３は、上述した異常検出を所定のタイミングでおこなうようにしてもよい。この所定のタイミングは、たとえば、周期的であってもよく、また、ユーザまたはプログラムによるトリガーがあったときであってもよい。

また、上述した共通目的変数算出部４０５は、算出された目的変数の数に、各当該目的変数が有する係数を乗算したスコアを算出するようにしてもよい。この係数は、たとえば、ノードの種類、メトリックの種類、過去の障害の履歴などに基づいて設定することができる。また、この係数は、適宜、変更することができる。そして、優先順位設定部４０６は、共通目的変数算出部４０５によって算出されたスコアに基づいて、障害原因箇所候補の優先順位を設定するようにしてもよい。このように、共通目的変数算出部４０５における算出処理について、その算出結果を、適宜、チューニングすることによって、より精度のよい優先順位を設定することができる。

（ノード検出部によるノード検出処理）
図５は、ノード検出部に対する入力データ（「構成情報」）、出力データ（「関連ノード情報」）の関係の一例を示す説明図である。図５において、構成情報５０１には、たとえば、ネットワークシステム１００の構成に関する情報を記憶している。構成情報５０１は、図５に示すように、具体的には、たとえば、ネットワークシステム１００を構成する各ノードの種類、各ノードのメトリックに関する情報、各ノードどうしの接続状況などに関する情報を含む。

ネットワークシステム１００を構成するノードには、たとえば、アプリケーション（Ａｐｐ１（１０１）〜Ａｐｐ４（１０４））、コンテナ（コンテナ１（１１１）〜コンテナ４（１１４）、仮想マシン（ＶＭ１（１２１）、ＶＭ２（１２２））、サーバ（Ｓｅｒｖｅｒ１（１３１）、Ｓｅｒｖｅｒ２（１３２））、スイッチ（ＳＷ１４１）などが含まれる。したがって、ネットワークシステム１００を構成するノードには、ハードウェア装置によって実現するノードと、ソフトウェアによって実現するノードの両方が含まれる。

ここで、アプリケーション（Ａｐｐ１（１０１）〜Ａｐｐ４（１０４））は、たとえば、各種業務システムなどにおけるプログラムであり、より具体的には、たとえば、購買システムの入力画面などを表示するプログラムなどである。また、コンテナ（コンテナ１（１１１）〜コンテナ４（１１４））は、アプリケーションの起動に必要なアプリケーション本体・必要なライブラリ・設定ファイルなどをひとまとめにしたものである。また、バーチャルマシン（ＶＭ１（１２１）、ＶＭ２（１２２））は、仮想的に作られたハードウェアを実現するプログラムである。

これらのノードは、いずれも、ハードウェア装置にインストールされたプログラムあるいはデータである。したがって、ネットワークシステム１００においては、必ずしも図５の構成情報５０１どおりの構成でなくてもよい。すなわち、ネットワークシステム１００において、ＶＭがなかったり、あるいは、コンテナがなかったり、また、ＶＭにコンテナが載って、その上にＶＭが載ったりという構成であってもよい。

また、サーバ（Ｓｅｒｖｅｒ１（１３１）、Ｓｅｒｖｅｒ２（１３２））は、図２に示した、ネットワークシステム１００を構成する管理サーバ２０１、データベース２０３、サーバ２０４、ユーザ端末装置２０５などのハードウェア装置である。また、スイッチ（ＳＷ１４１）は、図２に示したネットワークシステム１００を構成するネットワーク機器２０２などのハードウェア装置である。

ノード検出部４０１は、異常が発生したノードを特定する。そして、構成情報５０１を参照して、特定したノードに関連するノードを抽出する。具体的には、たとえば、図１に示したように、Ａｐｐ１（１０１）を、異常が発生したノードと特定した場合に、構成情報５０１を参照して、Ａｐｐ１（１０１）に関連するノードとして、コンテナ１（１１１）、ＶＭ１（１２１）、Ｓｅｒｖｅｒ１（１３１）、ＳＷ（１４１）を、関連するノードとして抽出する。

また、同様に、ＶＭ１（１２１）を、異常が発生したノードと特定した場合に、構成情報５０１を参照して、ＶＭ１（１２１）に関連するノードとして、Ａｐｐ１（１０１）、コンテナ１（１１１）、Ｓｅｒｖｅｒ１（１３１）、ＳＷ（１４１）を、関連するノードとして抽出する。同様に、コンテナ３（１１３）を、異常が発生したノードと特定した場合に、構成情報５０１を参照して、コンテナ３（１１３）に関連するノードとして、Ａｐｐ３（１０３）、ＶＭ２（１２２）、Ｓｅｒｖｅｒ２（１３２）、ＳＷ（１４１）を、関連するノードとして抽出する。

異常が発生したその他のノード（コンテナ１（１１１）、Ｓｅｒｖｅｒ１（１３１）、ＶＭ２（１２２））についても、同様に関連するノードを抽出する。このように、ノード検出部４０１は、異常が発生した各ノードに関連するノードを抽出し、関連ノード情報５０２を作成し、出力あるいは記憶する。

関連ノード情報５０２には、異常が発生したノードに関する情報と、異常が発生したノードに関連のあるノードに関する情報を記憶している。関連ノード情報５０２は、具体的には、たとえば、異常が発生したノードに関する情報、異常が発生したノードに関連のあるノードに関する情報を含む。また、関連ノード情報５０２には、図示は省略するが、各ノードのメトリック情報を含んでいてもよい。

図６は、ノード検出処理の手順の一例を示すフローチャートである。図６のフローチャートにおいて、ノード検出部４０１は、まず、システムにおいて異常が発生したか否かを判断する（ステップＳ６０１）。ここで、異常が発生するのを待って（ステップＳ６０１：Ｎｏ）、異常が発生した場合（ステップＳ６０１：Ｙｅｓ）は、異常が発生したノードを特定する（ステップＳ６０２）。

つぎに、構成情報５０１を読み込み（ステップＳ６０３）、読み込んだ構成情報５０１から、ステップＳ６０２において特定したノードと関連のあるノードを抽出する（ステップＳ６０４）。そして、抽出されたノードに基づいて、関連ノード情報５０２を作成する（ステップＳ６０５）。その後、作成した関連ノード情報５０２を出力（あるいは記憶）し（ステップＳ６０６）、一連の処理を終了する。

（説明変数選択部による説明変数選択処理）
図７は、説明変数選択部に対する入力データ（「関連ノード情報」）、出力データ（「説明変数選択結果」）の関係の一例を示す説明図である。図７において、関連ノード情報５０２は、図５において、ノード検出部４０１によって作成・出力（記憶）された関連ノード情報５０２である。

説明変数選択部４０２は、第１に、関連ノード情報５０２を参照して、ノード検出部４０１において抽出されたノードと当該ノードの各メトリックとの組み合わせを目的変数とする。メトリックは、各ノードによってそれぞれ異なる。図１に示したように、アプリケーションのメトリックは、たとえば、応答時間、リクエスト数などである。また、コンテナ、ＶＭ、サーバのメトリックは、たとえば、コア使用時間、メモリ使用時間、ディスクＩＯ量、ＮＷ（ネットワーク）ＩＯ量などである。なお、メトリックの詳細情報については、後述する。

説明変数選択部４０２は、第２に、目的変数としたノードとメトリックの組み合わせ以外の組み合わせを説明変数とする。具体的には、ノードである「Ａｐｐ１（１０１）」とそのメトリックである「応答時間」の組み合わせを目的変数とした場合に、目的変数とした「Ａｐｐ１（１０１）・応答時間」の組み合わせ以外のメトリックである、「Ａｐｐ１（１０１）・リクエスト数」、「Ａｐｐ３（１０３）・リクエスト数」、「コンテナ１（１１１）・ＮＷＩＯ量」、「コンテナ３（１１３）・ＮＷＩＯ量」、「ＶＭ１（１２１）・ＮＷＩＯ量」、「ＶＭ２（１２２）・ＮＷＩＯ量」、「Ｓｅｒｖｅｒ１（１３１）・ＮＷＩＯ量」などを説明変数とする。

説明変数選択部４０２は、第３に、各目的変数について、予測モデルに使える説明変数を選択し、説明変数選択結果７００を作成し、出力する。説明変数選択結果７００には、説明変数選択部４０２によって選択された説明変数の選択結果が記憶される。図７に示した説明変数選択結果７００においては、説明変数選択部４０２が第１に特定した目的変数を列方向に示し（重複する目的変数は削除している）、説明変数選択部４０２が第２に特定した説明変数を行方向に示している。

また、説明変数選択部４０２が第３に選択した説明変数を『○』で示している。具体的には、たとえば、目的変数：「Ａｐｐ１（１０１）・応答時間」について予測モデルに使える説明変数は、「コンテナ１（１１１）・ＮＷＩＯ量」と、「ＶＭ１（１２１）・ＮＷＩＯ量」の２つであり、また、目的変数：「Ａｐｐ１（１０１）・リクエスト数」について予測モデルに使える説明変数は、「Ａｐｐ１（１０１）・応答時間」と、「Ａｐｐ３（１０３）・リクエスト数」の２つである。

図８は、説明変数選択処理の手順の一例を示すフローチャートである。図８において、説明変数選択部４０２は、まず、関連ノード情報５０２を読み込む（ステップＳ８０１）。つぎに、読み込んだ関連ノード情報５０２からノード情報を一つ抽出する（ステップＳ８０２）。抽出したノード情報からメトリックを一つ抽出し、そのメトリックとの組み合わせを目的変数とする（ステップＳ８０３）。つぎに、抽出したノード情報と当該メトリック以外の他の組み合わせを説明変数の候補とする（ステップＳ８０４）。そして、候補の中から、予測モデルに使える説明変数を選択し（ステップＳ８０５）、選択した説明変数を記憶する（ステップＳ８０６）。

つぎに、抽出したノード情報において未処理のメトリックがあるか否かを判断する（ステップＳ８０７）。ここで、未処理のメトリックがある場合（ステップＳ８０７：Ｙｅｓ）は、当該未処理のメトリックを一つ抽出し、当該ノード情報と組み合わせて目的変数とする（ステップＳ８０８）。その後、ステップＳ８０４へ戻って、ステップＳ８０４〜Ｓ８０８の各処理を繰り返しおこなう。

ステップＳ８０７において、未処理のメトリックがない場合（ステップＳ８０７：Ｎｏ）は、つぎに、関連ノード情報に未処理のノード情報はあるか否かを判断する（ステップＳ８０９）。ここで、未処理のノード情報がある場合（ステップＳ８０９：Ｙｅｓ）は、関連ノード情報から、当該未処理のノード情報を一つ抽出する（ステップＳ８１０）。その後、ステップＳ８０３へ戻って、ステップＳ８０３〜Ｓ８１０の各処理を繰り返しおこなう。

一方、ステップＳ８０９において、未処理のノード情報がない場合（ステップＳ８０９：Ｎｏ）は、記憶した説明変数に基づいて説明変数選択結果７００を作成する（ステップＳ８１１）。そして、作成した説明変数選択結果７００を出力（あるいは記憶）し（ステップＳ８１２）、一連の処理を終了する。

（ＪＩＴ判定部によるＪＩＴ判定処理）
図９は、ＪＩＴ判定部に対する入力データ（「説明変数選択結果」）、出力データ（「異常判定結果」）の関係の一例を示す説明図である。図９において、説明変数選択結果７００は、図７において、説明変数選択部４０２によって作成・出力（記憶）された説明変数選択結果７００である。

ＪＩＴ判定部４０３は、上述したジャストインタイムによる異常検出方法を用いて、各メトリックの異常を判定する。そして、判定結果に基づいて、異常判定結果９００を作成し、出力（あるいは記憶）する。異常判定結果９００には、ＪＩＴ判定部４０３による各ノード＋メトリック組み合わせの異常判定結果が記憶される。図９に示した異常判定結果９００において、異常判定の結果、異常と判定されたノード＋メトリックの組み合わせについては、『あり』を示し、異常と判定されなかったノード＋メトリックの組み合わせについては、『なし』を示している。具体的には、異常判定結果９００において、「Ａｐｐ１（１０１）・応答時間」、「Ａｐｐ３（１０３）・リクエスト数」、「コンテナ１（１１１）・ＮＷＩＯ量」、「ＶＭ１（１２１）・ＮＷＩＯ量」、「ＶＭ２（１２２）・ＮＷＩＯ量」の各ノード＋メトリックの組み合わせが、『あり』と示されており、これらのノード＋メトリックの組み合わせが異常と判定されたことを示している。

一方、異常判定結果９００において、「Ａｐｐ１（１０１）・リクエスト数」、「コンテナ３（１１３）・ＮＷＩＯ量」、「Ｓｅｒｖｅｒ１（１３１）・ＮＷＩＯ量」の各ノード＋メトリックの組み合わせが、『なし』と示されており、これらのノード＋メトリックの組み合わせが異常なしと判定されたことを示している。

図１０は、ＪＩＴ判定処理の手順の一例を示すフローチャートである。図１０のフローチャートにおいて、において、ＪＩＴ判定部４０３は、まず、説明変数選択結果７００を読み込む（ステップＳ１００１）。読み込んだ説明変数選択結果７００から一つの目的変数を抽出する（ステップＳ１００２）。そして、選択した説明変数を用いてＪＩＴ判定をおこない（ステップＳ１００３）、その判定結果を記憶する（ステップＳ１００４）。

つぎに、説明変数選択結果７００に未処理の目的変数はあるか否かを判断する（ステップＳ１００５）。ここで、未処理の目的変数がある場合（ステップＳ１００５：Ｙｅｓ）は、説明変数選択結果７００から、未処理の目的変数を一つ抽出する（ステップＳ１００６）。そして、ステップＳ１００３へ戻る。その後、ステップＳ１００３〜Ｓ１００６の各処理を繰り返しおこなう。

一方、ステップＳ１００５において、未処理の目的変数がない場合（ステップＳ１００５：Ｎｏ）は、記憶した判定結果に基づいて異常判定結果９００を作成する（ステップＳ１００７）。そして、作成した異常判定結果９００を出力（あるいは記憶）し（ステップＳ１００８）、一連の処理を終了する。

（異常検出変数抽出部による異常検出変数抽出処理）
図１１は、異常検出変数抽出部に対する入力データ（「異常判定結果」）、出力データ（「異常検出した目的変数」）の関係の一例を示す説明図である。図１１において、異常判定結果９００は、図９において、ＪＩＴ判定部４０３によって作成・出力（記憶）された異常判定結果９００である。

異常検出変数抽出部４０４は、異常判定結果９００に基づいて、異常検出した目的変数１１００とその説明変数を抽出する。異常検出変数抽出部４０４は、具体的には、たとえば、異常判定結果９００において、異常と判定され、『あり』と示された、「Ａｐｐ１（１０１）・応答時間」、「Ａｐｐ３（１０３）・リクエスト数」、「コンテナ１（１１１）・ＮＷＩＯ量」、「ＶＭ１（１２１）・ＮＷＩＯ量」、「ＶＭ２（１２２）・ＮＷＩＯ量」の各ノード＋メトリックを抽出し、異常検出された目的変数の説明変数として特定する。

さらに、異常検出変数抽出部４０４は、異常判定結果９００において、異常なしと判定され、『なし』と示された、「Ａｐｐ１（１０１）・リクエスト数」、「コンテナ３（１１３）・ＮＷＩＯ量」、「Ｓｅｒｖｅｒ１（１３１）・ＮＷＩＯ量」の各ノード＋メトリックを抽出し、異常検出しなかった目的変数の説明変数として特定してもよい。そして、異常検出変数抽出部４０４は、特定した“異常検出された目的変数（異常検出目的変数）”および“異常検出しなかった目的変数（異常非検出目的変数）”に基づいて異常検出した目的変数１１００を作成し出力する。

図１１に示した異常検出した目的変数１１００において、各ノード＋メトリックの組み合わせに対して、異常検出した目的変数として特定したノード＋メトリックの組み合わせには、「異常検出した目的変数」欄に『○』を示している。具体的には、たとえば、「Ａｐｐ１（１０１）・応答時間」、「Ａｐｐ３（１０３）・リクエスト数」、「コンテナ１（１１１）・ＮＷＩＯ量」、「ＶＭ１（１２１）・ＮＷＩＯ量」、「ＶＭ２（１２２）・ＮＷＩＯ量」の各ノード＋メトリックの組み合わせに、『○』が示されている。また、各ノード＋メトリックの組み合わせに対して、異常検出しなかった目的変数として特定したノード＋メトリックの組み合わせには、「異常検出しなかった目的変数」欄に『○』を示している。具体的には、たとえば、「Ａｐｐ１（１０１）・リクエスト数」、「コンテナ３（１１３）・ＮＷＩＯ量」、「Ｓｅｒｖｅｒ１（１３１）・ＮＷＩＯ量」の各ノード＋メトリックの組み合わせに、『○』が示されている。

図１２は、異常検出変数抽出処理の手順の一例を示すフローチャートである。図１２において、異常検出変数抽出部４０４は、まず、異常判定結果９００を読み込む（ステップＳ１２０１）。読み込んだ異常判定結果９００から、異常を検出した目的変数（ノード＋メトリックの組み合わせ）を抽出する（ステップＳ１２０２）。そして、抽出した目的変数の説明変数（ノード＋メトリックの組み合わせ）を抽出する（ステップＳ１２０３）。つぎに、抽出した変数を、異常検出した変数として作成し、出力（あるいは記憶）する（ステップＳ１２０４）。異常検出変数抽出処理としては、これで、一連の処理を終了してもよい。

また、さらに続けて、読み込んだ異常判定結果９００から、異常を検出しなかった目的変数（ノード＋メトリックの組み合わせ）を抽出する（ステップＳ１２０５）。そして、抽出した目的変数の説明変数（ノード＋メトリックの組み合わせ）を抽出する（ステップＳ１２０６）。つぎに、抽出した変数を、異常検出しなかった変数として作成し、出力（あるいは記憶）する（ステップＳ１２０７）。これにより、異常検出変数抽出処理の一連の処理を終了するようにしてもよい。

（共通目的変数算出処理）
図１３は、共通目的変数算出部に対する入力データ（「異常検出した目的変数」）、出力データ（「共通する目的変数の数」）の関係の一例を示す説明図である。図１３において、異常検出した目的変数１１００は、図１１において、異常検出変数抽出部４０４によって作成・出力（記憶）された異常検出した目的変数１１００である。また、図示を省略するが、異常検出した目的変数１１００には、図７に示した説明変数選択結果７００に関する情報が含まれていてもよい。

共通目的変数算出部４０５は、異常を検出した目的変数の各説明変数に共通する目的変数の数を抽出する。具体的には、たとえば、異常を検出した目的変数の説明変数（ノード＋メトリックの組み合わせ）である「Ａｐｐ１（１０１）・応答時間」に共通する目的変数は、図７に示した説明変数選択結果７００からもわかるように、１つ（Ａｐｐ１（１０１）・リクエスト数）である。また、同様に、異常を検出した目的変数の説明変数（ノード＋メトリックの組み合わせ）である「Ａｐｐ３（１０３）・リクエスト数」に共通する目的変数は、図７に示した説明変数選択結果７００からもわかるように、１つ（「Ａｐｐ１（１０１）・リクエスト数」）である。したがって、図１３に示した共通する目的変数の数１３００の該当欄を、それぞれ、『１』とする。

また、同様に、異常を検出した目的変数の説明変数（ノード＋メトリックの組み合わせ）である「コンテナ１（１１１）・ＮＷＩＯ量」に共通する目的変数は、図７に示した説明変数選択結果７００からもわかるように、２つ（「Ａｐｐ１（１０１）・応答時間」、「コンテナ１（１１１）・メモリ使用量」）である。したがって、図１３に示した共通する目的変数の数１３００の該当欄を『２』とする。

また、同様に、異常を検出した目的変数の説明変数（ノード＋メトリックの組み合わせ）である「ＶＭ１（１２１）・ＮＷＩＯ量」に共通する目的変数は、図７に示した説明変数選択結果７００からもわかるように、３つ（「Ａｐｐ１（１０１）・応答時間」、「Ａｐｐ３（１０３）・リクエスト数」、「ＶＭ２（１２２）・ＮＷＩＯ量」）である。したがって、図１３に示した共通する目的変数の数１３００の該当欄を『３』とする。

また、同様に、異常を検出した目的変数の説明変数（ノード＋メトリックの組み合わせ）である「ＶＭ２（３０２）・ＮＷＩＯ量」に共通する目的変数は、図７に示した説明変数選択結果７００からもわかるように、存在しない。したがって、図１３に示した共通する目的変数の数１３００の該当欄を『０』とする。

共通目的変数算出部４０５は、異常を検出しなかった目的変数の各説明変数に共通する目的変数の数を抽出するようにしてもよい。具体的には、たとえば、異常を検出しなかった目的変数の説明変数（ノード＋メトリックの組み合わせ）である「Ａｐｐ１（１０１）・リクエスト数」に共通する目的変数は、図７に示した説明変数選択結果７００からもわかるように、１つであり、同様に、「コンテナ３（１１３）・ＮＷＩＯ量」に共通する目的変数は２つであり、「Ｓｅｒｖｅｒ１（１３１）・ＮＷＩＯ量」に共通する目的変数は２つである。したがって、図１３に示した共通する目的変数の数１３００の該当欄を、それぞれ、『１』、『２』、『２』とする。このようにして、共通目的変数算出部４０５は、共通する目的変数の数１３００を作成し、出力する。

図１４は、共通目的変数算出処理の手順の一例を示すフローチャートである。図１４において、共通目的変数算出部４０５は、まず、異常検出した変数を読み込む（ステップＳ１４０１）。つぎに、異常検出しなかった変数がある場合は、当該異常検出しなかった変数を読み込む（ステップＳ１４０２）。そして、各説明変数の共通する目的変数の数を算出する（ステップＳ１４０３）。つぎに、算出した数を、共通する目的変数の数として作成する（ステップＳ１４０４）、そして、作成した共通する目的変数の数を出力（あるいは記憶）し（ステップＳ１４０５）、一連の処理を終了する。

（優先順位設定処理）
図１５は、優先順位設定部に対する入力データ（「共通する目的変数の数」）、出力データ（「調査優先度」）の関係の一例を示す説明図である。図１５において、共通する目的変数の数１３００は、図１３に示した共通目的変数算出部４０５によって作成・出力（記憶）された共通する目的変数の数１３００である。

優先順位設定部４０６は、説明変数を目的変数としたとき、異常検出しており、かつ、共通する目的変数の数が大きい順に調査の優先順位を付ける。優先順位設定部４０６は、具体的には、たとえば、共通する目的変数の数１３００に基づいて、まず、異常検出した目的変数にかかるノード＋メトリックの組み合わせを抽出する。

具体的には、たとえば、共通する目的変数の数１３００において、異常検出した目的変数にかかるノード＋メトリックの組み合わせである、「Ａｐｐ１（１０１）・応答時間」、「Ａｐｐ３（１０３）・リクエスト数」、「コンテナ１（１１１）・ＮＷＩＯ量」、「ＶＭ１（１２１）・ＮＷＩＯ量」、「ＶＭ２（１２２）・ＮＷＩＯ量」の５つを抽出する。そして、各ノード＋メトリックの共通する目的変数の数を比較する。この中で、一番大きな数である『３』となっている「ＶＭ１（１２１）・ＮＷＩＯ量」が優先順位第１位である。そこで、調査優先度１５００の「ＶＭ１（１２１）・ＮＷＩＯ量」の該当欄を『１』とする。この『１』が優先順位第１位であることを示す。

つぎに、二番目に大きな数である『２』となっている「コンテナ１（１１１）・ＮＷＩＯ量」が優先順位第２位である。そこで、調査優先度１５００の該当欄を『２』とする。同様に、三番目に大きな数である『１』となっている「Ａｐｐ１（１０１）・応答時間」と、「Ａｐｐ３（１０３）・リクエスト数」が、優先順位第３位である。そこで、調査優先度１５００の該当欄をそれぞれ『３』とする。また同様に、共通する目的変数の数が『０』である「ＶＭ２（１２２）・ＮＷＩＯ量」を優先順位第４位として、調査優先度１５００の該当欄を『４』とする。

つぎに、優先順位設定部４０６は、説明変数を目的変数としたとき、異常検出しなかったノード＋メトリックの組み合わせを、共通する目的変数の数１３００に基づいて抽出する。具体的には、たとえば、共通する目的変数の数１３００において、「Ａｐｐ１（１０１）・リクエスト数」、「コンテナ３（１１３）・ＮＷＩＯ量」、「Ｓｅｒｖｅｒ１（１３１）・ＮＷＩＯ量」の３つを抽出する。

そして、各ノード＋メトリックの組み合わせの共通する目的変数の数を比較する。この中で、一番大きな数である『２』となっている「コンテナ３（１１３）・ＮＷＩＯ量」と、「Ｓｅｒｖｅｒ１（１３１）・ＮＷＩＯ量」が、異常検出しており、かつ、共通する目的変数の数が大きい順の最下位であった「ＶＭ２（１２２）・ＮＷＩＯ量」の優先順位第４位に引き続き、優先順位第５位となる。そこで、調査優先度１５００の「コンテナ３（１１３）・ＮＷＩＯ量」と、「Ｓｅｒｖｅｒ１（１３１）・ＮＷＩＯ量」の該当欄をそれぞれ『５』とする。この『５』が優先順位第５位であることを示す。

また同様に、共通する目的変数の数が『１』となっている「Ａｐｐ１（１０１）・リクエスト数」が優先順位第６位となる。そこで、調査優先度１５００の「Ａｐｐ１（１０１）・リクエスト数」の該当欄を『６』とする。

このようにして、優先順位設定部４０６は、調査の優先順位を付けた調査優先度１５００を作成し、出力する。なお、優先順位は、異常を検出しており、かつ、共通する目的変数の数が大きい順に調査の優先順位を付けてもよく（優先順位第１位〜第４位まででもよく）、また、異常を検出しなかったノード＋メトリックの組み合わせまで範囲を広げて、優先順位第５位、第６位まで順位付けをしてもよい。

図１６は、優先順位設定処理の手順の一例を示すフローチャートである。図１６のフローチャートにおいて、優先順位設定部４０６は、まず、共通する目的変数の数を読み込む（ステップＳ１６０１）。つぎに、共通する目的変数の数から、異常を検出した説明変数（異常検出説明変数）を抽出する（ステップＳ１６０２）。そして、抽出した異常検出説明変数を、共通する目的変数の数の多い順に優先順位を設定する（ステップＳ１６０３）。

つぎに、共通する目的変数の数から、異常を検出しなかった説明変数（異常非検出説明変数）を抽出する（ステップＳ１６０４）。そして、抽出した異常非検出説明変数を、共通する目的変数の数の多い順に優先順位を設定する（ステップＳ１６０５）。すなわち、ステップＳ１６０３において設定した優先順位に続けて、優先順位を設定する。

その後、設定した優先順位に基づいて、調査優先度を作成する（ステップＳ１６０６）。そして、作成した調査優先度を出力（あるいは記憶）し（ステップＳ１６０７）、一連の処理を終了する。

（表示画面の一例）
図１７は、表示画面の一例を示す説明図である。図１７において、表示画面１７００は、たとえば、図３Ｂに示したユーザ端末装置２０５のディスプレイ３５４に表示される表示の内容を示している。表示画面１７００の表示内容は、優先順位設定部４０６によって作成・出力された調査優先度１５００の内容に基づいて作成される。これにより、障害原因箇所順位をユーザに容易に知らしめることができる。

図１７において、調査優先度１５００の優先順位にしたがって、障害原因箇所順位の第１位から順番に上から並べて表示される。表示画面１７００に表示される内容は、障害原因箇所順位のほか、障害原因箇所のノードのノード名と、そのノードのメトリックである稼働データ名と、さらに当該ノードに関連するノードおよびその稼働データ名である。

表示画面１７００においては、調査優先度１５００において、調査優先度が第１位であったノード＋メトリックの組み合わせ：「ＶＭ１（１２１）・ＮＷＩＯ量」が障害原因箇所順位の第１位である。そして、「ＶＭ１（１２１）・ＮＷＩＯ量」に関連するノード・稼働データ名としては、図７に示した説明変数選択結果７００からもわかるように、説明変数：「ＶＭ１（１２１）・ＮＷＩＯ量」の目的変数である「Ａｐｐ１（１０１）・応答時間」、「Ａｐｐ３（１０３）・リクエスト数」、「ＶＭ２（１２２）・ＮＷＩＯ量」の３つが表示される。障害原因箇所順位の第２位以下も同様である。

ユーザは、この表示画面１７００を確認することで、発生した障害原因を容易に認識することができる。すなわち、ユーザは、優先順位の上から探すことによって、より効率的に障害原因箇所を発見することができる。ＯＫボタン１７０１が押下されることによって、表示画面１７００は消去する。

以上説明したように、本実施の形態によれば、制御部４００のうち、ノード検出部４０１が、複数のノードから構成されるネットワークシステム１００において異常が発生したノードと関連のある関連ノードを抽出し、説明変数選択部４０２が、抽出された関連ノードと当該関連ノードの稼働データとの各組み合わせをそれぞれ目的変数とし、当該目的変数以外の組み合わせのうち、当該目的変数についての予測モデルとして使用できる組み合わせを、当該目的変数の説明変数としてそれぞれ選択し、異常検出変数抽出部４０４が、選択された説明変数を用いてＪＩＴ判定部４０３によっておこなわれた異常検出において、異常が検出された異常検出目的変数と、当該異常検出目的変数の説明変数を抽出し、共通目的変数算出部４０５が、抽出された異常検出目的変数の説明変数に共通する目的変数の数）を算出し、優先順位設定部４０６が、算出された目的変数の数に基づいて、障害原因箇所の優先順位を設定する。これにより、障害原因の特定に要する時間を短縮することができ、ＩＣＴインフラストラクチャの運用を効率化することができる。

また、本実施の形態によれば、異常検出変数抽出部４０４が、異常検出において、異常が検出されなかった異常非検出目的変数と、当該異常非検出目的変数の説明変数を抽出し、共通目的変数算出部４０５が、抽出された異常非検出目的変数の説明変数に共通する目的変数の数を算出し、優先順位設定部４０６が、算出された目的変数の数に基づいて、障害原因箇所候補の優先順位を設定するので、詳細箇所を特定する、さらに詳細な優先順位を設定することができる。

また、本実施の形態によれば、ＪＩＴ判定部４０３が、異常検出をジャストインタイム（ＪＩＴ）判定によりおこなうので、実際に異常が発生しているかどうかをより正確に判定することができる。

また、本実施の形態によれば、ＪＩＴ判定部４０３が、異常検出を所定のタイミングでおこなうので、異常発生時以外にも異常を把握でき、定常的にネットワークシステムの各ノードの健全な運用を担保することができる。

また、本実施の形態によれば、共通目的変数算出部４０５が、算出された目的変数の数に、各当該目的変数が有する係数を乗算したスコアを算出し、優先順位設定部４０６が、算出されたスコアに基づいて、障害原因箇所の優先順位を設定するので、より精度のよい優先順位とすることができる。

また、本実施の形態によれば、説明変数選択部４０２は、所定のタイミング（たとえば、ネットワークシステム１００を構成するノードの起動時または当該起動時から所定時間が経過した時、あるいは、ネットワークシステム１００の構成に変化があったとき）で、所定のノードと当該所定のノードの稼働データとの各組み合わせをそれぞれ目的変数とし、当該目的変数以外の組み合わせのうち、当該目的変数についての予測モデルとして使用できる組み合わせを説明変数として選択し、当該選択の結果を記憶し、ＪＩＴ判定部４０３は、ネットワークシステム１００を構成するノードに異常が発生した場合に、記憶された選択の結果にかかる説明変数を用いて、異常検出をおこなうので、より迅速なレスポンスをおこなうことができる。

なお、本実施の形態で説明した障害原因特定方法は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することにより実現することができる。障害原因特定プログラムは、ハードディスク、フレキシブルディスク、ＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｃ）−ＲＯＭ、ＭＯ（Ｍａｇｎｅｔｏ−Ｏｐｔｉｃａｌ Ｄｉｓｋ）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）、フラッシュメモリ、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）メモリなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また、障害原因特定プログラムは、インターネットなどのネットワークを介して配布してもよい。

上述した実施の形態に関し、さらに以下の付記を開示する。

（付記１）
複数のノードから構成されるネットワークシステムにおいて異常が発生したノードと関連のある関連ノードを抽出し、
抽出された関連ノードと当該関連ノードの稼働データとの各組み合わせをそれぞれ目的変数とし、当該目的変数以外の組み合わせのうち、当該目的変数についての予測モデルとして使用できる組み合わせを、当該目的変数の説明変数としてそれぞれ選択し、
選択された説明変数を用いておこなわれた異常検出において、異常が検出された異常検出目的変数と、当該異常検出目的変数の説明変数を抽出し、
抽出された異常検出目的変数の説明変数に共通する目的変数の数を算出し、
算出された目的変数の数に基づいて、障害原因箇所の優先順位を設定する、
制御部を有することを特徴とする障害原因特定システム。

（付記２）
前記制御部は、前記異常検出において、異常が検出されなかった異常非検出目的変数と、当該異常非検出目的変数の説明変数を抽出し、抽出された異常非検出目的変数の説明変数に共通する目的変数の数を算出し、
算出された目的変数の数に基づいて、障害原因箇所候補の優先順位を設定することを特徴とする付記１に記載の障害原因特定システム。

（付記３）
前記制御部は、
前記異常検出を、ジャストインタイム（Ｊｕｓｔ−Ｉｎ−Ｔｉｍｅ（ＪＩＴ））判定によりおこなうことを特徴とする付記１または２に記載の障害原因特定システム。

（付記４）
前記制御部は、
前記異常検出を所定のタイミングでおこなうことを特徴とする付記１〜３のいずれか一つに記載の障害原因特定システム。

（付記５）
前記制御部は、
前記算出された目的変数の数に、各当該目的変数が有する係数を乗算したスコアを算出し、
算出されたスコアに基づいて、障害原因箇所の優先順位を設定することを特徴とする付記１〜４のいずれか一つに記載の障害原因特定システム。

（付記６）
前記制御部は、
所定のタイミングで、所定のノードと当該所定のノードの稼働データとの各組み合わせをそれぞれ目的変数とし、当該目的変数以外の組み合わせのうち、当該目的変数についての予測モデルとして使用できる組み合わせを説明変数として選択し、当該選択の結果を記憶し、
前記ネットワークシステムを構成するノードに異常が発生した場合に、記憶された選択の結果にかかる説明変数を用いて、前記異常検出をおこなうことを特徴とする付記１〜５のいずれか一つに記載の障害原因特定システム。

（付記７）
前記所定のタイミングは、前記ネットワークシステムを構成するノードの起動時または当該起動時から所定時間が経過した時であることを特徴とする付記６に記載の障害原因特定システム。

（付記８）
前記所定のタイミングは、前記ネットワークシステムの構成に変化があったときであることを特徴とする付記６に記載の障害原因特定システム。

（付記９）
複数のノードから構成されるネットワークシステムにおいて異常が発生したノードと関連のある関連ノードを抽出し、
抽出された関連ノードと当該関連ノードの稼働データとの各組み合わせをそれぞれ目的変数とし、当該目的変数以外の組み合わせのうち、当該目的変数についての予測モデルとして使用できる組み合わせを、当該目的変数の説明変数としてそれぞれ選択し、
選択された説明変数を用いておこなわれた異常検出において、異常が検出された異常検出目的変数と、当該異常検出目的変数の説明変数を抽出し、
抽出された異常検出目的変数の説明変数に共通する目的変数の数を算出し、
算出された目的変数の数に基づいて、障害原因箇所の優先順位を設定する処理を、コンピュータが実行することを特徴とする障害原因特定方法。

（付記１０）
複数のノードから構成されるネットワークシステムにおいて異常が発生したノードと関連のある関連ノードを抽出し、
抽出された関連ノードと当該関連ノードの稼働データとの各組み合わせをそれぞれ目的変数とし、当該目的変数以外の組み合わせのうち、当該目的変数についての予測モデルとして使用できる組み合わせを、当該目的変数の説明変数としてそれぞれ選択し、
選択された説明変数を用いておこなわれた異常検出において、異常が検出された異常検出目的変数と、当該異常検出目的変数の説明変数を抽出し、
抽出された異常検出目的変数の説明変数に共通する目的変数の数を算出し、
算出された目的変数の数に基づいて、障害原因箇所の優先順位を設定する処理を、コンピュータに実行させることを特徴とする障害原因特定プログラム。

１００ ネットワークシステム
１０１〜１０４ アプリケーション（Ａｐｐ１〜Ａｐｐ４）
１１１〜１１４ コンテナ（コンテナ１〜コンテナ４）
１２１、１２２ バーチャルマシン（ＶＭ１、ＶＭ２）
１３１、１３２ サーバ（Ｓｅｒｖｅｒ１、Ｓｅｒｖｅｒ２）
１４１ スイッチ（ＳＷ）
１５０ 障害原因特定システム
２００ ネットワーク
２０１ 管理サーバ
２０２ ネットワーク機器
２０３ データベース
２０４ サーバ
２０５ ユーザ端末装置
２０６ アプリケーション
４００ 制御部
４０１ ノード検出部
４０２ 説明変数選択部
４０３ ＪＩＴ判定部
４０４ 異常検出変数抽出部
４０５ 共通目的変数算出部
４０６ 優先順位設定部
５０１ 構成情報
５０２ 関連ノード情報
７００ 説明変数選択結果
９００ 異常判定結果
１１００ 異常検出した目的変数
１３００ 共通する目的変数の数
１５００ 調査優先度
１７００ 表示画面

Claims (8)

1. 複数のノードから構成されるネットワークシステムにおいて異常が発生したノードと関連のある関連ノードを抽出し、
   抽出された関連ノードと当該関連ノードの稼働データとの各組み合わせをそれぞれ目的変数とし、当該目的変数以外の組み合わせのうち、当該目的変数についての予測モデルとして使用できる組み合わせを、当該目的変数の説明変数としてそれぞれ選択し、
   選択された説明変数を用いておこなわれた異常検出において、異常が検出された異常検出目的変数と、当該異常検出目的変数の説明変数を抽出し、
   抽出された異常検出目的変数の説明変数に共通する目的変数の数を算出し、
   算出された目的変数の数に基づいて、障害原因箇所の優先順位を設定する、
   制御部を有することを特徴とする障害原因特定システム。
2. 前記制御部は、前記異常検出において、異常が検出されなかった異常非検出目的変数と、当該異常非検出目的変数の説明変数を抽出し、抽出された異常非検出目的変数の説明変数に共通する目的変数の数を算出し、
   算出された目的変数の数に基づいて、障害原因箇所候補の優先順位を設定することを特徴とする請求項１に記載の障害原因特定システム。
3. 前記制御部は、
   前記異常検出を、ジャストインタイム（Ｊｕｓｔ−Ｉｎ−Ｔｉｍｅ（ＪＩＴ））判定によりおこなうことを特徴とする請求項１または２に記載の障害原因特定システム。
4. 前記制御部は、
   前記異常検出を所定のタイミングでおこなうことを特徴とする請求項１〜３のいずれか一つに記載の障害原因特定システム。
5. 前記制御部は、
   前記算出された目的変数の数に、各当該目的変数が有する係数を乗算したスコアを算出し、
   算出されたスコアに基づいて、障害原因箇所の優先順位を設定することを特徴とする請求項１〜４のいずれか一つに記載の障害原因特定システム。
6. 前記制御部は、
   所定のタイミングで、所定のノードと当該所定のノードの稼働データとの各組み合わせをそれぞれ目的変数とし、当該目的変数以外の組み合わせのうち、当該目的変数についての予測モデルとして使用できる組み合わせを説明変数として選択し、当該選択の結果を記憶し、
   前記ネットワークシステムを構成するノードに異常が発生した場合に、記憶された選択の結果にかかる説明変数を用いて、前記異常検出をおこなうことを特徴とする請求項１〜５のいずれか一つに記載の障害原因特定システム。
7. 複数のノードから構成されるネットワークシステムにおいて異常が発生したノードと関連のある関連ノードを抽出し、
   抽出された関連ノードと当該関連ノードの稼働データとの各組み合わせをそれぞれ目的変数とし、当該目的変数以外の組み合わせのうち、当該目的変数についての予測モデルとして使用できる組み合わせを、当該目的変数の説明変数としてそれぞれ選択し、
   選択された説明変数を用いておこなわれた異常検出において、異常が検出された異常検出目的変数と、当該異常検出目的変数の説明変数を抽出し、
   抽出された異常検出目的変数の説明変数に共通する目的変数の数を算出し、
   算出された目的変数の数に基づいて、障害原因箇所の優先順位を設定する処理を、コンピュータが実行することを特徴とする障害原因特定方法。
8. 複数のノードから構成されるネットワークシステムにおいて異常が発生したノードと関連のある関連ノードを抽出し、
   抽出された関連ノードと当該関連ノードの稼働データとの各組み合わせをそれぞれ目的変数とし、当該目的変数以外の組み合わせのうち、当該目的変数についての予測モデルとして使用できる組み合わせを、当該目的変数の説明変数としてそれぞれ選択し、
   選択された説明変数を用いておこなわれた異常検出において、異常が検出された異常検出目的変数と、当該異常検出目的変数の説明変数を抽出し、
   抽出された異常検出目的変数の説明変数に共通する目的変数の数を算出し、
   算出された目的変数の数に基づいて、障害原因箇所の優先順位を設定する処理を、コンピュータに実行させることを特徴とする障害原因特定プログラム。

Images