JP4575020B2 - 障害解析装置 - Google Patents

Description

この発明は、システム中で発生した障害状況から障害原因を推定して、その障害の素となった要素を特定する装置、方法に関するものである。

分散コンピュータシステムでは、障害の発生に備えてシステム内でさまざまな監視が行われている。例えば、ｐｉｎｇ監視に代表される機器外部からの問い合わせによるシステムあるいはシステムを構成する要素の生死監視がある。また障害以外にも、機器内のエージェントによるプロセス有無やディスク空き、ＣＰＵ使用状況等のリソース監視、業務処理の利用者視点に立った応答時間の監視等である。
ところでこれらの障害監視は、個々の監視設定に従って独立に実施されており相互の連携はない。あるものは短周期での監視、あるものは長周期での監視になっており、１つの根本原因に誘発された複数の波及障害の検知に時間差が生じる。更に個々に表面的な障害現象のみが収集されるので、障害の素を解析するには専門技術を必要とし、障害の根本原因箇所特定に時間を要してしまう。また、監視周期を短くすることで障害検知のリアルタイム性は向上し、検知の同時性も向上するが、システムに対するデータ収集と原因解析量の増大による監視処理の負荷が大きくなってしまう。

また、業務処理フローを集中管理し、その実行結果を収集することで障害データを迅速に収集する技術、例えば特許文献１の「管理マネージャ計算機、記録媒体、および、計算機運用管理方法」や、特許文献２の「業務フローの稼動情報取得方法および業務フローシステム」があるが、これらは、業務処理フローの観点で実行結果を追跡する技術である。従って、単に障害が発生したという事実の通知はあっても、業務処理を実行するために利用するコンピュータリソースや外部サービス、ネットワーク経路の障害には関知していない。つまり障害解析に関しては何の開示もないし、障害の根本原因の特定については述べられていない。
特開平１１−１３４３０６号公報 特開２００３−６７２２２号公報

従来のシステムの監視装置は上記のように構成されており、単に障害状況を個々に収集するのみである。あるいは過去の障害を記録した障害データベースを参照して障害原因を推定するのみであり、もとになる障害を見つけることが困難であるという課題がある。

本発明は上記の課題を解決するためになされたもので、関連する業務構成機器やリソースの障害状況から障害部分を特定し、かつ特定した障害部分に対して直ちに機能確認を行って容易に障害部分を特定することを目的とする。

この発明に係る障害解析装置は、監視対象システムの業務を構成する構成機器・リソースを業務毎に記憶する業務構成情報テーブルと、
上記各構成機器・リソースの個別監視方法を記憶する監視方法情報テーブルと、
上記監視対象システムを監視する監視部と、
上記監視部が上記監視対象システムの障害を検出すると、上記業務構成情報テーブルを参照して上記障害が発生した業務を推定し、該障害が発生した業務を構成する構成機器・リソースを抽出し、該業務を構成する構成機器・リソースの監視方法を適用する関連障害の確認方法特定部、とを備えた。

この発明によれば、業務構成情報テーブルと監視方法情報テーブルと障害が発生した業務を推定し、その業務を構成する構成機器・リソースを抽出し、その構成機器・リソースの監視方法を適用する関連障害の確認方法特定部とを備えたので、障害を分析する高度な知識を要せずに、障害部分に対して直ちに機能確認を行って容易に障害部分を特定できる効果がある。

実施の形態１．
システム障害があった場合に、その障害の根本原因部分は、業務を構成する機器やソフトウェアを含むリソース群の中のいずれかに存在するはずである。このことから、システム障害を検知すると、直ちに関連する業務構成機器かリソースの障害を推定して、その推定機器またはリソースに対して直ちに機能確認すれば、根本の障害部分を短時間に特定できる。こうすれば通常時のシステム監視負荷を増加することもない。
図１は、上記思想に基づくこの発明の実施の形態１における、障害解析装置を示す構成ブロック図である。
図１の構成において、監視対象システム１は、障害解析装置により、通常時に一定周期等でシステムの障害発生状況を監視部５１，５２で監視されている。同様に随時障害監視部５３，５４により、随時、監視対象システム内の構成要素の障害発生状況等を監視されている。
後にも詳述するが、クライアント別に監視業務を細分化し、監視プログラムをこれら細分化した業務が使用するリソースのレスポンスまで監視するようにすれば、少なくともどのような業務で障害が発生したかを把握することは困難ではない。

また障害解析装置には、これらの監視部で得られた監視データから、障害発生を検知すると、障害に関連する機器やリソースを抽出し、それらの障害状況を確認する方法を特定する関連障害の確認方法特定部３０がある。関連障害の確認方法特定部３０は、内部に、発生した障害から最も障害があり得る業務を推定する障害発生業務特定部３１と、その業務処理を行うための機器やリソースを抽出する関連リソース抽出部３２と、それらの機器やリソースの障害状況を確認する方法を特定する確認方法特定部３３を持つ。
更に障害解析装置には、関連障害の確認方法特定部３０が障害部分を推定する際に参照する、システムに関する情報群４０がある。このシステムに関する情報群４０中に、業務構成情報テーブル４１、対象毎の監視方法情報テーブル４２がある。更に、以上の一連の処理全体を制御する障害情報収集制御部２０がある。

また図２は、図１において監視対象システム１として示される、その具体的な構成の例と、特定の構成機器またはリソースを使用した業務の関係を示す図である。
図において、コンピュータノードとしてのサーバ１０１〜１０６は、内部に種々のプログラム１１１〜１１７を持ち、ネットワーク機器１２１〜１２４及びネットワークサービス１２５，１２６を経由して互いに接続されている。
図中の点線１３０は、ある業務処理「業務１」を構成する業務構成である。例として挙げた「業務１」はクライアント１からの処理要求が業務サーバ３ １０３中の業務プログラム３、業務プログラム４を経由して業務サーバ１ １０１中の業務プログラム１で処理される構成である。また業務プログラム３はその処理の中で、例えばネームサービスや認証サービスのような共有サービスプログラム１ １１５を利用している。「業務１」の点線１３０は、これらの業務構成を線で表したものである。
通常時障害監視部５１等が行う監視の方法として、例えば業務１として業務プログラム１はクライアント１からアクセスされ、同じ業務プログラム１を使用してもクライアント２からアクセスする場合には業務１１と名付けるようにすれば、かなり細かなレベルで障害発生時の業務の特定が可能である。更に監視プログラムが、業務プログラム１、クライアントプログラム１の振る舞いまでも監視すれば、障害発生を検知することは容易である。

また図３は、図１中の業務構成情報テーブル４１におけるデータ例を示す図であり、図２で示した「業務１」の業務構成をテーブル形式で表したものである。このテーブルには、業務１を構成する機器やリソースとそれぞれの機器やリソースが動作するための前提となる依存機器やリソースが表されている。もちろんその他に、業務２、業務３等の、他の業務の構成機器・リソースも記憶、表されている。
また図４は、図１中の対象毎の監視方法情報テーブル４２におけるデータ例を示す図であり、図２で示した対象システムの構成要素１つずつに対して、その監視方法をテーブル形式で表したものである。

次に動作について説明する。
図１の通常時障害監視部５１，５２は、監視対象システムの障害を検知すると、障害情報収集制御部２０に障害検知を通知する。ここでは、例として図２におけるクライアントプログラム１ １１６で業務応答が無くなった場合を想定する。即ち設定された時間内に応答が返らないので、障害検知とする。
この検知を受けて、障害情報収集制御部２０は、この情報を関連障害の確認方法特定部３０に渡す。関連障害の確認方法特定部３０では、まず障害発生業務特定部３１が障害の内容にあるクライアントプログラムの応答不良からその障害が業務１に関する障害であることを推定する。これは図１８における障害業務の推定ステップＳ１０１である。次に関連リソース抽出部３２が、図３に示す業務構成情報テーブル４１を参照して業務１に関連する機器やリソースを抽出する。これは図１８の構成機器・リソース推定ステップＳ１０２である。さらに、確認方法特定部３３が、図４に示す対象毎の監視方法情報テーブル４２から、各機器やリソースに対する障害監視方法を特定する。これは図１８の監視方法特定ステップＳ１０４である。図５は、関連障害の確認方法特定部３０が作成した業務１に関する監視方法情報テーブルの例を示す図である。

図５の業務１の監視方法情報テーブル４２ｂによる監視方法の情報を受け取った障害情報収集制御部２０は、随時障害監視部５３，５４を経由して、監視対象システムの中の業務１に関わる機器やリソースの障害状況の確認を、図５の「監視方法（現在状況確認方法）」に基づいて、構成される業務構成機器・リソース別に順に、直ちに実行する。これは図１８の個別障害確認実行ステップＳ１０５である。例えば、図５のＮＷ機器１について、ｐｉｎｇ ＮＷ１−１を実行し、所定の応答が返らなければ、ＮＷ機器１が障害原因であったことが確認、検知できる。この障害状況確認処理の中で図２のＮＷ機器１ １２１に障害が発生していることを確認、検知すれば、クライアントプログラム１ １１６の業務応答が無くなった根本原因部分がＮＷ機器１であることが判明する。
図１３は、このシステムの通常時の監視方法に関するテーブルの例を示す図であるが、この中で参考として示した各監視機能の監視間隔の例によると、ＮＷ機器１の監視間隔は２０分であり、本実施の形態における障害解析装置がなければ、根本原因部分の障害を検知するまでに、最悪２０分の時間差が生じてしまう。
このように従来の監視装置が、個々の機器やリソースの監視をそれぞれ個別に独立して設定された監視周期で実施されているだけの状況に比べて、本障害解析装置を用いることにより、業務の障害に対する根本原因部分の特定が迅速に行える効果がある。

実施の形態２．
実施の形態１では、確認方法特定部３３が図５に示す業務構成機器・リソースに対して順次、個別に障害確認を行う例を説明した。しかし順次、障害確認を行う方法では、効率が悪い。障害が発生した構成機器・リソースを推定するには、過去に発生した障害を参照して、同様の状況であれば、その構成機器・リソースであると推定するのが自然である。本実施の形態では、こうした過去の履歴によって障害が発生した業務の推定を行う。
図６は、本実施の形態における障害解析装置を示す構成ブロック図である。図において、先の実施の形態に追加された新しい構成要素として、障害履歴情報テーブル４３が追加されている。この障害履歴情報テーブル４３は、関連障害の確認方法特定部３０が処理を行う際に参照する。
また図７は、障害履歴情報テーブル４３に記憶されている具体的なデータの例を示す図であり、監視対象システム機器やリソース毎の障害履歴を記録している。

次に動作について説明する。
図８は、実施の形態１で作成した図５の監視方法情報テーブルに図７の障害履歴情報テーブル４３から得た「障害発生日」「障害重大度」の情報を付加したテーブルである。
特定の業務が障害していると推定されたとして、その推定された業務を構成する機器やリソースが多数抽出される場合がある。その場合、これら抽出された全ての機器の障害状況を優先度制御なしに全抽出機器とリソースに順次、図５に示す監視方法を適用して結果を得るには長い時間が要る。
そこで、過去に障害が発生した部分は、再度障害が発生する確率が高いと想定し、まずはそれらを優先的に障害確認し一次情報を報告する。その後全件の確認を行うことで、障害復旧対策の迅速化が図れる効果がある。
図８の例では、業務プログラム１、ＮＷ機器１、共用サービスプログラム１について優先的に障害確認を行う。

実施の形態３．
実施の形態３では実施の形態２と同様に障害監視の優先処理を実施するが、優先処理判断に利用する情報は図９に例を示した障害履歴情報テーブル４３ｃである。ここでは機能ブロック図は省略するが、この障害発生頻度情報テーブルは図６の障害履歴情報テーブル４３の中にこの頻度項目を設けて、関連障害の確認方法特定部３０が処理を行う際にこの頻度項目を参照する。

この場合の動作としては、実施の形態２と同様に、障害発生頻度が高い部分に障害が発生する確率が高いと想定し、まずはそれらの障害発生頻度が高い業務構成機器またはリソースを優先的に障害確認して一次情報を報告する。その後全件の確認を行うことで、障害復旧対策の迅速化が図れる効果がある。
図９の例で、たとえば３回以上のしきい値で優先監視するならば、先ずＮＷ機器１、業務プログラム１に対して優先的に障害確認を行う。ただしＮＷサービス２は業務１には該当しない。

実施の形態４．
本実施の形態では実施の形態２と同様に障害監視の優先処理を実施するが、優先処理判断に利用する情報は図１０に例を示したシステム変更履歴情報テーブル４４である。ここでは機能ブロック図を省略するが、このシステム変更履歴情報テーブル４４は図６の障害履歴情報テーブル４３と同等のテーブルとし、障害履歴情報テーブル４３と同様の部分に設ける。そして関連障害の確認方法特定部３０が処理を行う際に、このシステム変更履歴情報テーブル４４を参照する。

実施の形態２と同様に、システムに対して変更を行った部分に障害が発生する確率が高いと想定し、まずはそれらを優先的に障害確認し一次情報を報告する。その後全件の確認を行うことで、障害復旧の迅速化が図れる効果がある。
図１０の例では、変更記録があるもの全てを優先するならば、業務プログラム３、業務プログラム１、ＮＷ機器３、ＮＷ機器１、共用サービスプログラム１を優先的に障害確認を行う。ただしＮＷサービス２は業務１には該当しない。

実施の形態５．
本実施の形態では、実施の形態２、３、４と類似で障害監視の優先処理を実施するが、優先処理判断に利用する情報は図１１に例を示したシステム機器・リソース重要度情報テーブル４５の情報である。ここでは機能ブロック図を省略するが、このシステム機器・リソース重要度情報テーブル４５は図６の障害履歴情報テーブル４３と同等のテーブルとし、障害履歴情報テーブル４３と同様の部分に設ける。そして関連障害の確認方法特定部３０が処理を行う際に、このシステム機器・リソース重要度情報テーブル４５を参照する。

障害の根本原因箇所を特定する場合に、障害の影響が大きい機器やリソースの障害は、いち早く検知し対策をとるべきである。この目的のため、まずは重要度の高い機器やリソースを優先的に障害確認し順次報告することで、障害の業務影響を極小化できる。
図１１の例では、まず重大度レベルが最高値１０の業務プログラム１の障害確認を行い、順次、次いで重大度レベルの高い順へと確認を行う。

実施の形態６．
本実施の形態では、実施の形態２、３、４と類似で障害監視の優先処理を実施するが、優先処理判断に利用する情報は、図１２に示される、リソース毎の単位時間当たりの使用頻度情報テーブル４６である。これは例えば図１の構成において、障害情報収集制御部２０が随時障害監視部５３を用いて定期的に各業務構成機器とリソースの使用頻度を調べる。その調査結果を図１２のリソース使用頻度情報テーブル４６の、使用頻度の項に記録して管理しておく。使用頻度の調査は任意期間でよく、障害情報収集制御部２０が随時障害監視部５３に起動をかけて、対象となるリソースのオープン（開始）またはクローズ（終了）のどちらかを数えることで頻度が判る。これを更に積算していけば、相対的な使用頻度が判る。このリソース使用頻度テーブルを図６の障害履歴情報テーブル４３と同様の部分に設ける。
そして関連障害の確認方法特定部３０が処理を行う際に、このリソース使用頻度情報テーブル４６を参照する。
障害の根本原因箇所を特定する場合に、リソース使用頻度情報テーブル４６に記載の使用頻度が少ないリソースほど、残存バグなどの可能性があって、障害が発生しているのかもしれない。

実施の形態７．
本発明の装置は、システム障害の検知を効率よく行うことを目的としているが、その監視方法によっては、監視対象の障害自体ではなく、それ以外の障害によって誤検知している場合もあり得る。
図１３は、ｐｉｎｇによりネットワーク機器の外部から生死を確認している例であり、ｐｉｎｇ監視サーバ１０７からＮＷ機器３ １２４を監視している。この時、ＮＷ機器３に対するｐｉｎｇ応答エラー（無応答）はＮＷ機器３の障害以外に、監視経路上のＮＷ機器２やＮＷ機器４の障害でも検知してしまう。すなわち、ｐｉｎｇ監視サーバ１０７の位置からのＮＷ機器３へのｐｉｎｇ監視は、ＮＷ機器２とＮＷ機器４に依存していると言える。

本実施の形態では、実施の形態１ないし６の処理を行う前に、システム障害の検知に誤検知状態がなかったかをまず確認するものである。
図１４は、通常時の監視についての監視依存関係を示した監視依存関係テーブル５７の例を示した図である。たとえばＮＷ機器３の障害を検知した場合に、「誤検知原因になる監視機能の依存箇所」に登録されているＮＷ機器２、ＮＷ機器４の障害状況を先ず確認する。そして、これらに障害がなければ、実施の形態１ないし６の処理を実施する。
この事前処理を行うことにより、根本障害箇所検出処理の精度が向上する。

実施の形態８．
実施の形態１〜６の処理では、業務構成から抽出した機器やリソースの障害状況を、登録してある確認方法で確認するが、全ての機器やリソースに障害状態が認められないケースが考えられる。本実施の形態では、その場合でも、障害確認方法の観点を変更したり、より詳しい分析のために、障害解析情報を収集し人的な分析を行うことに備えたりする、二次ステップ、三次ステップの処理を実施できる手段を持つ。
図１５は、図４に示した対象毎の監視方法情報テーブル４２を拡張した監視方法情報テーブル４２ｄであり、二次アクションを登録した例である。この例では二次アクションとしては障害解析のための情報収集方法が登録されている。

図１６は、本実施の形態における動作を実行するフローである。一次アクションリストに従って関連機器、リソースの障害状況を確認しても、いずれも明らかな障害状態でない場合、二次アクションに切り替えて再度処置を、ステップＳ６１ないしＳ６５により実行する。
なお、この例を実施するためには、構成要素を追加した装置を示す図１６において、障害解析情報収集部５５，５６を新たに設ける等、実施したい処理に合わせた要素を追加する必要がある。
この処理により、障害箇所を検出できなかった場合でも、人的な分析に備えた障害解析情報を予め収集しておくなどの、代替処置を実行しておくことができ、システム障害対策の迅速化がはかれる。

実施の形態９．
上記の各実施の形態では、障害解析装置はハードウェアで構成されるとして説明した。しかし装置はそれに限定されることは無く、汎用のプロセッサとメモリを用いて、メモリにソフトウェアのプログラムでステップを記述して、このプログラム・ステップにより、同等の動作を実行させてもよい。
図１８は、こうしたプログラム・ステップで実施の形態１における動作を実現するフローチャートを示した図である。図において、プログラム・ステップとしてＳ１０１で障害発生業務特定部３１相当の機能を組む。通常時障害監視部１ ５１が障害検知を通知すると、この通知をスタートの監視するステップＳ１００として監視を始める。以下、関連リソース抽出部３２相当の機能をＳ１お２で組み、確認方法特定部３３相当の機能をＳ１０４とＳ１０５で組む。また実施の形態２ないし６における個別構成機器・リソース選択優先順位の機能を、Ｓ１０３で組む。
更にこの図１８で示されるフローチャートの機能をプログラムとして作成しておけば、汎用の計算機にそのプログラムをロードして、上記各実施の形態で説明した障害解析装置を構成することが出来る。

この発明の実施の形態１における障害解析装置を示す構成ブロック図である。 実施の形態１における監視対象システムである業務１と特定の構成機器・リソースの関係を示す図である。 実施の形態１における業務構成情報テーブル中のデータ例を示す図である。 実施の形態１における監視方法情報テーブル中のデータ例を示す図である。 実施の形態１で関連障害の確認方法特定部が作成した監視方法情報の例を示す図である。 この発明の実施の形態２における障害解析装置を示す構成ブロック図である。 実施の形態２における障害履歴情報テーブル中のデータ例を示す図である。 実施の形態２で関連障害の確認方法特定部が作成した監視方法情報の例を示す図である。 実施の形態３における障害履歴情報テーブル中のデータ例を示す図である。 実施の形態４におけるシステム変更履歴情報テーブル中のデータ例を示す図である。 実施の形態５におけるシステム機器・リソース重要度情報テーブル中のデータ例を示す図である。 実施の形態６における使用頻度情報テーブル中のデータ例を示す図である。 実施の形態７における外部からの構成機器・リソース障害確認方法例を説明する図である。 実施の形態７における監視依存関係テーブル中のデータ例を示す図である。 実施の形態８における監視方法情報テーブル中のデータ例を示す図である。 実施の形態８における障害分析動作を示すフロー図である。 実施の形態８における障害解析装置を示す構成ブロック図である。 この発明の実施の形態９における障害解析方法を示す動作フロー図である。

符号の説明

２０ 障害情報収集制御部、３０ 関連障害の確認方法特定部、３１ 障害発生業務特定部、３２ 関連リソース抽出部、３３ 確認方法特定部、４０ システムに関する情報群、４１ 業務構成情報テーブル、４２，４２ｂ，４２ｃ，４２ｄ （対象毎の）監視方法情報テーブル、４３，４３ｃ 障害履歴情報テーブル、４４ システム変更履歴情報テーブル、４５ システム機器・リソース重要度情報テーブル、４６ 使用頻度情報テーブル、５１，５２ 通常時障害監視部、５３，５４ 随時障害監視部、５５，５６ 障害解析情報収集部、５７ 監視依存関係テーブル、Ｓ６１ 前業務関連箇所の抽出と第一次ステップアクションの抽出、Ｓ６２ 全対象に対するアクション実施、Ｓ６３ 障害箇所検出ステップ、Ｓ６４ 次アクション登録ステップ、Ｓ６５ 次アクション抽出ステップ、Ｓ１０１ 障害業務推定ステップ、Ｓ１０２ 該当業務の構成機器・リソース抽出ステップ、Ｓ１０３ 構成機器・リソースの優先順位選定ステップ、Ｓ１０４ 構成機器・リソースの確認方法特定ステップ、Ｓ１０５ 優先順位に基づく個別障害確認実行ステップ、Ｓ１０６ 確認実行終了確認ステップ。

Claims (1)

1. 監視対象システムが実行する複数の業務の業務毎に業務を構成する構成機器とリソースとの情報を記憶する業務構成情報テーブルと、
   構成機器の障害状況を確認するコマンドを構成機器毎に記憶するとともに、リソースの障害状況を確認するコマンドをリソース毎に記憶する監視方法情報テーブルと、
   上記監視対象システムをあらかじめ定められた周期で監視し、上記監視対象システムの構成機器とリソースとのいずれかの障害を検知した場合、障害を検知した構成機器と障害を検知したリソースとのいずれかを示す障害検知情報を通知する通常時障害監視部と、
   上記通常時障害監視部から上記障害検知情報が通知された場合、上記業務構成情報テーブルに業務毎に記憶された業務を構成する構成機器とリソースとの情報を参照して、通知された障害検知情報が示す構成機器と通知された障害検知情報が示すリソースとのいずれかにより構成される業務を抽出し、
   抽出した業務を構成する構成機器とリソースとを上記業務構成情報テーブルを参照して抽出し、
   抽出した業務を構成する構成機器とリソースとの障害状況を確認するコマンドを上記監視方法情報テーブルを参照して特定する関連障害の確認方法特定部と
   上記関連障害の確認方法特定部が抽出した上記監視対象システムの業務を構成する構成機器とリソースとに対して、上記関連障害の確認方法特定部が特定したコマンドを実行して障害状況を確認する随時障害監視部と
   を備えたことを特徴とする障害解析装置。

Images