JP7387469B2 - 通信装置、監視サーバ及びログ収集方法 - Google Patents

Description

本発明は、発生した障害の原因を特定する通信装置及び監視サーバに関する。

複数の通信装置によって構成されるネットワークでは、通信装置のハードウェア異常、ソフトウェア異常、通信回線の輻輳、ネットワーク設定ミスなどによって、通信を阻害する障害が発生する。そこで、通信装置や、通信装置に接続される端末から定期的にログを収集して、稼働状況を把握して障害の発生を早期に検知し、同時に障害原因を特定する方法が提案されている。

近年は、ＩｏＴ機器の普及などによって通信装置やネットワークが多様化し、従来有線接続ネットワークが主流であった分野においても有線及び無線が混在するネットワークが採用されている。この場合、従来の有線区間で発生する障害だけでなく、無線区間で発生する障害も検知する必要がある。このようにネットワークと障害原因が多様化する中で、障害の検知や障害原因の特定を実現する技術が提案されている。

例えば、特許文献１（特開２０１２－１９８７９６号公報）には、端末機器とサーバ装置とを備え、端末機器は、ログ情報を収集し蓄積するログ収集蓄積手段と、蓄積したログ情報を解析し、異常状態を検出する異常検出手段と、異常状態を検出すると、サーバ装置に異常状態を通知する異常通知手段とを含み、サーバ装置は、端末機器に蓄積されたログ情報を収集するログ収集手段と、通知された異常状態を解析する異常解析手段と、異常状態の内容に応じて、異常検出手段に対して異常状態の検出方法の設定を指示する異常検出指示手段と、ログ収集蓄積手段に対して収集し蓄積するログ情報の粒度及び内容と収集し蓄積する頻度との設定を指示する端末ログ収集蓄積指示手段と、ログ収集手段に対して端末機器から収集するログ情報の内容と収集頻度との設定を指示するログ収集指示手段とを含むログ収集システムが開示されている（要約参照）。

また、特許文献２（特開２０１９－２８８７８号公報）には、所定の装置の構成部品に関する複数のログレコードを含む動作情報のうち、抽出対象とするログレコードの時間範囲と前記ログレコードのタイプ毎の優先レベルとを、メッセージ毎に記憶する記憶部と、メッセージを検出すると、前記記憶部を参照して、前記メッセージに応じた現時刻からの前記時間範囲および前記優先レベルに基づき、前記動作情報の中から前記ログレコードを抽出する処理部と、を有する情報処理装置が開示されている（請求項１参照）。

特開２０１２－１９８７９６号公報 特開２０１９－２８８７８号公報

発生した障害が大きな損害を生む場合には、障害原因を効率よく、早急に追及する必要がある。前述した先行技術では、ログの収集を効率化しているが、ログの収集内容を決定する際に障害原因の特定順序が考慮されていない。例えば、パケットが転送されない障害が発生した場合に、ソフトウェアのバグの有無を検証した後に、ネットワークの設定ミスが発見された場合、設定ミスを修正した上で、ソフトウェアのバグの有無を再度検証する必要がある。この場合、設定ミスの有無を確認した上でソフトウェアのバグの有無を検証する順序の方が高効率である。本発明では、障害原因の特定順序を定めることによって、ダウンタイムを最小化する高効率な障害原因特定を実現するログ収集を可能とする。

本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、信号を転送する通信装置であって、所定の処理を実行する演算装置と、前記演算装置がアクセス可能な記憶装置とを備え、前記通信装置及び前記通信装置に接続される機器の少なくとも一方から第１の種類のログを収集するログ収集部と、前記収集されたログが所定の条件を満たす場合にアラートを生成するアラート生成部と、前記生成されたアラートに対応して障害原因候補を決定し、前記決定された障害原因候補に対応して定められる追加ログ収集順序に従って、第２の種類のログを収集するための追加ログ収集要求を前記ログ収集部に出力する障害原因候補決定部とを備えることを特徴とする。

本発明によれば、障害発生時にダウンタイムを最小化する高効率な障害原因特定を実現するログ収集を可能とする。前述した以外の課題、構成及び効果は、以下の実施例の説明によって明らかにされる。

実施例１の通信装置の構成の一例を示す図である。 実施例１の通信装置の構成要素間の入出力の一例を示す図である。 実施例１のログ収集条件管理テーブルの一例を示す図である。 実施例１のアラート条件管理テーブルの一例を示す図である。 実施例１の障害原因管理テーブルの一例を示す図である。 実施例１の優先度管理テーブルの一例を示す図である。 実施例１の障害原因候補決定部が実行する障害原因候補決定処理のフローチャートである。 実施例１の通信装置の設定情報管理画面の一例である。 実施例２の通信装置の構成の一例を示す図である。 実施例２の通信装置の構成要素間の入出力の一例を示す図である。 実施例２の追加収集管理テーブルの一例を示す図である。 実施例２の収集モード管理テーブルの一例を示す図である。 実施例２の収集モード決定部が実行する収集モード更新処理のフローチャートである。 実施例２の障害原因候補決定部及び追加収集管理部が実行する障害原因候補決定処理のフローチャートである。 実施例２の通信装置の追加収集管理画面及び条件変更画面の一例を示す図である。 実施例３の障害原因特定システムの構成の一例を示す図である。 実施例３の障害原因特定システムの構成要素の入出力の一例を示す図である。 実施例３のログ・アラート解析部が実行する障害原因候補決定処理のフローチャートである。 実施例４の障害原因特定システムの構成の一例を示す図である。 実施例４の障害原因特定システムの構成要素の入出力の一例を示す図である。 実施例５の障害原因特定システムの構成の一例を示す図である。 実施例５の障害原因特定システムの構成要素の入出力の一例を示す図である。

以下、本実施の形態について図面を参照して説明する。ただし、本発明は以下に示す実施例の記載内容に限定して解釈されるものではない。本発明の思想ないし趣旨から逸脱しない範囲で、その具体的構成を変更し得ることは当業者であれば容易に理解される。

以下に説明する発明の構成において、同一又は類似する構成又は機能には同一の符号を
付し、重複する説明は省略する。

＜実施例１＞
図１は、実施例１の通信装置の構成の一例を示す図である。

本実施例の通信装置１００は、ＣＰＵ１１０、メモリ１２０、通信インターフェース１３０及び入出力部１４０を有し、各構成要素は通信装置内ネットワーク１５０を介して接続される。通信装置内ネットワーク１５０は、その種別及び接続方式に限定されず、構成要素間を接続するネットワークの種別や接続方式は異なってもよい。

ＣＰＵ１１０は、プログラムを実行する演算装置であり、プログラムを実行することによって、特定の機能を実現する機能部（ログ収集部１１１、アラート生成部１１２、障害原因候補決定部１１３）として動作する。ＣＰＵ１１０がプログラムを実行して行う処理の一部を、他の演算装置（例えば、ＦＰＧＡ（Field Programmable Gate Array）、ＡＳＩＣ（Application Specific Integrated Circuit）などのハードウェア）で実行してもよい。以下の説明では、機能部を主語にした処理の説明は、ＣＰＵ１１０が当該機能部を実現するプログラムを実行していることを意味する。

メモリ１２０は、通信装置１００が機能を遂行するために必要なデータを格納する記憶装置である。メモリ１２０には、ログデータ１２１や、ログ収集部１１１、アラート生成部１１２、障害原因候補決定部１１３が参照する管理テーブル群１２２が格納される。

通信インターフェース１３０は、通信装置１００が他の装置と通信するためのインターフェースである。通信インターフェース１３０は、例えばＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）や、ＳＩＭカードが格納された無線通信モジュール等で構成される。

入出力部１４０は、通信インターフェース１３０を介して通信装置１００の外部から入力された情報の処理、入力情報をメモリ１２０へ格納する処理、及び入力情報を他の構成要素に中継する処理を行う。また、入出力部１４０は、通信装置１００の構成要素から情報を取得し、通信インターフェース１３０を介して外部に出力する処理を行う。

図２は、実施例１の通信装置１００の構成要素間の入出力の一例を示す図である。

管理テーブル群１２２は、ログ収集条件管理テーブル２０１、アラート条件管理テーブル２０２、障害原因管理テーブル２０３及び優先度管理テーブル２０４を含む。

ログ収集部１１１は、ログ収集条件管理テーブル２０１を参照して、通信装置１００及び通信インターフェース１３０を介して通信装置１００に接続される機器からログを収集して、ログデータ１２１として保存する。

アラート生成部１１２は、アラート条件管理テーブル２０２及びログデータ１２１を参照して、ログデータ１２１がアラート条件管理テーブル２０２のアラート生成条件を満たす場合に、アラートを生成し、障害原因候補決定部１１３に通知する。

障害原因候補決定部１１３は、アラート生成部１１２よりアラートが通知されると、障害原因管理テーブル２０３及び優先度管理テーブル２０４を参照し、障害原因候補を決定し、障害種別に基づく優先度を決定する。さらに、障害原因候補決定部１１３は、決定した障害原因候補に応じてログ収集条件管理テーブル２０１、アラート条件管理テーブル２０２及び障害原因管理テーブル２０３を更新する。

以下に、各機能部が参照する管理テーブル群１２２の詳細を説明する。なお、管理テーブル群１２２に含まれる要素は一例であって、以下に説明する要素の一部を含ませなくてもよく、他の要素を含んでもよい。

図３は、ログ収集条件管理テーブル２０１の一例を示す図である。

ログ収集条件管理テーブル２０１には、ログ番号３０１、ログ名３０２、収集周期３０３及び収集フラグ３０４が記載される。ログ番号３０１には、ログを識別する番号が記載される。ログ名３０２には、ログを識別する名称が記載される。収集周期３０３には、ログを収集する周期が記載される。収集フラグ３０４には、その行のログを収集するかを制御するためのフラグが記載される。例えば、収集フラグ３０４の列に１が記載されている場合、ログ収集部１１１は、収集周期３０３に従ってその行のログを収集する。一方、収集フラグ３０４の列に０が記載されている場合、ログ収集部１１１はその行のログを収集しない。

図４は、アラート条件管理テーブル２０２の一例を示す図である。

アラート条件管理テーブル２０２には、アラート番号４０１、アラート名４０２、参照ログ４０３、条件４０４、チェック周期４０５及びアラートフラグ４０６が記載される。アラート番号４０１には、アラートを識別する番号が記載される。アラート名４０２には、アラートを識別する名称が記載される。チェック周期４０５には、アラート条件を検証する周期が記載される。アラートフラグ４０６には、その行のアラート条件を検証するかを制御するためのフラグが記載される。例えば、アラートフラグ４０６の列に１が記載されている場合、アラート生成部１１２は、チェック周期４０５に従ってその行のアラート条件を検証し、当該アラート条件を満たす場合にアラートを生成する。一方、アラートフラグ４０６の列に０が記載されている場合、アラート生成部１１２はその行のアラート条件を検証しない。

図５は、障害原因管理テーブル２０３の一例を示す図である。

障害原因管理テーブル２０３には、アラート名５０１、障害原因５０２、障害種別５０３、発生回数５０４、収集ログ５０５及び合致条件５０６が記載される。アラート名５０１にはアラート条件管理テーブル２０２のアラート名４０２の名称が引用され、障害原因５０２には障害原因を区別する名称が記載される。障害種別５０３には障害原因を分類した種別、例えばハードウェア、ソフトウェア、無線、設定ミス等が記載される。発生回数５０４には、その障害原因が候補として決定された累計回数が記載される。収集ログ５０５には、その行の障害原因５０２を特定するために必要なログ名３０２が記載される。合致条件５０６には、その行の収集ログ５０５がどのような条件の時に障害原因５０２が発生したと推定して障害原因候補として決定するかを、例えば、大なり、小なり、等号、不等号等と閾値等を用いて記載される。

図６は、優先度管理テーブル２０４の一例を示す図である。

優先度管理テーブル２０４には、優先度６０１及び障害種別６０２が記載される。優先度６０１には、その行に記載される障害種別６０２の優先度が記載される。障害種別６０２には、障害原因を分類した種別が記載される。障害種別６０２は障害原因管理テーブル２０３の障害種別５０３が引用される。

以下、図７（Ａ）、図７（Ｂ）を参照して、実施例１において障害原因候補決定部１１３が実行する処理について説明する。

図７（Ａ）は、実施例１の障害原因候補決定部１１３が実行する障害原因候補決定処理のフローチャートである。障害原因候補決定部１１３は動作を開始すると以下の手順を実行する。

Ｓ１１：終了指示が入出力部１４０に入力されているかを判定し、終了指示が入力されている場合、動作を終了する。終了指示が入力されていない場合、ステップＳ１２に処理を進める。

Ｓ１２：アラート生成部１１２がアラートを生成しているかを判定し、アラートが生成されている場合、ステップＳ１３に処理を進める。アラートが生成されていない場合、ステップＳ１１に処理を戻す。

Ｓ１３：アラート生成部１１２より生成されたアラートと障害原因管理テーブル２０３と優先度管理テーブル２０４とを参照して、障害原因候補を決定し、障害種別に基づく優先度を決定する。障害原因候補を決定する詳細な処理についてはステップＳ２１からステップＳ２８にて後述する。

Ｓ１４：ステップＳ１３にて決定された障害原因候補に関連する障害原因管理テーブル２０３の行における発生回数５０４の値に１を加える。

Ｓ１５：ログ収集条件管理テーブル２０１を参照し、ステップＳ１３にて決定された障害原因候補に関連するログの情報を更新する。例えば、候補として決定した障害原因５０２に関連する障害原因管理テーブル２０３の行の収集ログ５０５とログ収集条件管理テーブル２０１のログ名３０２とが一致するログ収集条件管理テーブル２０１の行において、収集周期３０３を最短の時間に変更し、収集フラグ３０４が０の場合、０から１に変更するテーブル更新処理を実行してもよい。

Ｓ１６：アラート条件管理テーブル２０２を参照し、ステップＳ１３にて決定された障害原因候補に関連するアラートの情報を更新する。例えば、候補として決定された障害原因５０２に関連する障害原因管理テーブル２０３の行のアラート名５０１とアラート条件管理テーブル２０２のアラート名４０２とが一致する行において、チェック周期４０５を最短の時間に変更してもよい。

次に、図７（Ｂ）を参照して、障害原因候補決定（Ｓ１３）の詳細な処理について説明する。障害原因候補決定部１１３は障害原因候補決定（Ｓ１３）において下記の手順を行う。

Ｓ２１：障害原因管理テーブル２０３を参照し、アラート名５０１とステップＳ１２において生成を検知したアラート名４０２とが一致する行を抽出する。優先度管理テーブル２０４と、抽出した行の障害種別５０３とを参照し、優先度が高い障害種別５０３の行の収集ログ５０５を追加収集リストに追加する。例えば、優先度管理テーブル２０４において障害種別６０２に記載されたハードウェアの優先度６０１が１であり、障害種別６０２に記載されたソフトウェアの優先度６０１が２である場合、抽出された行を上から順に参照し、はじめに、障害種別５０３がハードウェアと記載されている場合、収集ログ５０５を追加収集リストに追加してもよい。このように、優先度６０１に従って追加で収集するログの順序が定められる。本動作を抽出された行の終わりまで繰り返し、先頭に戻る。次に、障害種別５０３がソフトウェアと記載されている場合、障害原因５０２及び収集ログ５０５を追加収集リストの末尾に追加する。追加収集リストは行の要素に障害原因５０２及び収集ログ５０５が記載されたリストである。項目追加の際に追加収集リストがない場合、追加収集リストを作成する。

Ｓ２２：ステップＳ２１で作成された追加収集リストの情報を一行読み込み、記載された収集ログ５０５を収集する。例えば、発生回数５０４が多い行から優先して読み込むとよい。このようにすると、過去に頻繁に発生した障害を優先するように、追加で収集するログの順序が定められる。また、優先度６０１が下位の行を無視してもよい。

Ｓ２３：ステップＳ２２で収集された収集ログ５０５が、合致条件５０６を満たすかを判定する。合致条件５０６を満たす場合、ステップＳ２４に処理を進める。合致条件５０６を満たさない場合、ステップＳ２５に処理を進める。

Ｓ２４：ステップＳ２２で読み込んだ追加収集リストの行の障害原因５０２を障害原因リストの末尾に追加する。障害原因リストは障害原因５０２が列挙されたリストであり、項目追加の際に障害原因リストがない場合、障害原因リストを作成する。

Ｓ２５：ステップＳ２２で読み込んだ追加収集リストの行を参照し、読み込んだ行が追加収集リストの末尾である場合、ステップＳ２６に処理を進める。読み込んだ行が追加収集リストの末尾でなかった場合、ステップＳ２２に処理を戻す。

Ｓ２６：ステップＳ２２からステップＳ２６の間に作成された障害原因リストを入出力部１４０へ送信する。入出力部１４０は通信インターフェース１３０を介して障害原因リストを出力する。例えば、入出力部１４０が障害原因リストを記載した電子メールを作成し、管理者のメールアドレスへ送信してもよい。また、通信装置１００にネットワークを介して接続された端末のブラウザからアクセスした際に表示される画面を入出力部１４０が作成し、障害原因リストを表示してもよい。なお、本発明は上記の障害原因リストの出力方法に限定して解釈されるものではない。

Ｓ２７：ステップＳ２２からステップＳ２６の間に作成された障害原因リストの項目数が０である場合、障害原因候補が決定できないので、ステップＳ２８に処理を進める。障害原因リストの項目数が１以上である場合、障害原因候補決定処理（Ｓ１３）を終了する。

Ｓ２８：管理者への通知を入出力部１４０に指示し、入出力部１４０を介して管理者へ原因不明な障害が発生した旨を伝達する。例えば、入出力部１４０が原因不明な障害が発生した旨を伝える定型文を記載した電子メールを作成し、管理者のメールアドレスへ、通信インターフェース１３０を介して送信してもよい。また、ネットワークを介して接続された端末のブラウザからアクセスした際に表示される画面を入出力部１４０が作成し、原因不明な障害が発生した旨を伝えるエラーメッセージを表示してもよい。なお、本発明は上記の伝達手法に限定して解釈されるものではない。

以下に、通信装置１００にネットワークを介して接続された端末が、ブラウザを介して通信装置１００にアクセスした際に、入出力部１４０が表示する設定情報管理画面８００について説明する。なお、本発明は以下に説明する設定情報管理画面８００上の表示内容や操作内容に限定して解釈されるものではない。

図８は、通信装置１００の設定情報管理画面８００の一例を示す図である。

入出力部１４０は、管理テーブル群１２２を参照し、設定情報管理画面８００を作成する。設定情報管理画面８００には、ログ収集条件管理テーブル２０１、アラート条件管理テーブル２０２、障害原因管理テーブル２０３及び優先度管理テーブル２０４に記録された内容が表示される。

ログ収集条件管理テーブル２０１の内容は、ログ番号３０１、ログ名３０２、収集周期３０３及び収集フラグ３０４の各項目が対応付けられ、１行に一つのログ収集条件として表示される。

アラート条件管理テーブル２０２の内容は、アラート番号４０１、アラート名４０２、参照ログ４０３、チェック周期４０５及びアラートフラグ４０６の各項目が対応付けられ、１行に一つのアラート条件として表示される。また、条件４０４は、条件と閾値に分けて表示される。

障害原因管理テーブル２０３の内容は、アラート名５０１、障害原因５０２、障害種別５０３及び収集ログ５０５の各項目が対応付けられ、１行に一つの障害原因候補決定条件として表示される。また、合致条件５０６は、条件と閾値に分けて表示される。

優先度管理テーブル２０４の内容は、優先度６０１及び障害種別６０２の各項目が対応付けられ、１行に一つの優先度として表示される。

以下、設定情報管理画面８００上での操作について説明する。

収集フラグのチェックボックス８１０は、ログ収集条件の各行に記載されたログの収集フラグ３０４の状態を表示し変更するために操作されるチェックボックスである。設定情報管理画面８００の生成時にログ収集条件管理テーブル２０１の収集フラグ３０４が１の場合にチェック有のチェックボックスを表示し、収集フラグ３０４が０の場合にチェック無のチェックボックスを表示する。画面上でチェックボックス８１０をチェックすると収集フラグ３０４を１に更新でき、チェックを外すと収集フラグ３０４を０に更新できる。

設定情報管理画面８００上にて、登録されたログ名３０２をログ名入力ボックス８１１で選択し、収集周期を収集周期入力ボックス８１２に入力した後、決定ボタン８１３を操作すると、ログ収集条件を新規に定義できる。

条件追加ボタン８１４の操作によって、ログ名入力ボックス８１１と、収集周期入力ボックス８１２と、決定ボタン８１３を新たに一項目ずつ表示できる。

条件削除ボックス８１５は、ログ収集条件を削除するために操作されるボタンであり、選択された行のログ収集条件を削除できる。

設定ファイル選択ボタン８２０の操作によってファイルを選択する画面を表示できる。このファイルを選択する画面において、ログ名３０２、収集周期３０３及び収集フラグ３０４をリスト化したファイルが選択でき、複数のログ収集条件が定義できる。

ログ定義追加ボタン８２１は、新しくログを定義するために操作されるボタンであり、ログを新たに定義し、ログ名入力ボックス８１１で選択可能なログを増加できる。例えば、ログ定義追加ボタン８２１の操作によって、ログ名３０２と、ログを取得するためのプログラムと、スクリプトのファイルパスとを入力可能な画面を表示して、入力に応じてログを新たに定義する。

チェックボックス８３０は各行に記載されたアラートのアラートフラグ４０６の状態を表示し変更するために操作されるチェックボックスである。設定情報管理画面８００の生成時にアラート条件管理テーブル２０２のアラートフラグ４０６が１の場合にチェック有のチェックボックスを表示し、アラートフラグ４０６が０の場合にチェック無のチェックボックスを表示する。画面上でチェックボックス８３０をチェックするとアラートフラグ４０６を１に更新でき、チェックを外すとアラートフラグ４０６を０に更新できる。

設定情報管理画面８００上にて、アラート名入力ボックス８３１にアラート名を入力し、参照ログ入力ボックス８３２にてログ名３０２を選択し、条件入力ボックス８３３にて大なり、小なり、等号、不等号等を選択し、閾値入力ボックス８３４に閾値を入力し、チェック周期入力ボックス８３５に周期を入力した後、決定ボタン８３６を操作すると、アラート条件を新規に定義できる。

ログ追加ボタン８３７は、一つのアラート名入力ボックス８３１に対して複数の参照ログ入力ボックス８３２と、条件入力ボックス８３３と、閾値入力ボックス８３４とを対応付けるために用いられる。すなわち、ログ追加ボタン８３７の操作によって、参照ログ入力ボックス８３２と、条件入力ボックス８３３と、閾値入力ボックス８３４を新たに一項目ずつ表示する。

条件追加ボタン８３８の操作によって、アラート名入力ボックス８３１と、参照ログ入力ボックス８３２と、条件入力ボックス８３３と、閾値入力ボックス８３４と、チェック周期入力ボックス８３５と、決定ボタン８３６を新たに一項目ずつ表示する。

条件削除ボックス８３９は、アラート条件を削除するために操作されるボタンであり、選択された行のアラート条件を削除できる。

設定ファイル選択ボタン８４０の操作によってファイルを選択する画面を表示できる。このファイルを選択する画面において、アラート番号４０１、アラート名４０２、参照ログ４０３、条件４０４、チェック周期４０５及びアラートフラグ４０６をリスト化したファイルが選択でき、複数のアラート条件が定義できる。

設定情報管理画面８００上にて、障害原因入力ボックス８５１に障害原因を入力し、障害種別入力ボックス８５２にて障害種別５０３を選択し、アラート名入力ボックス８５３にてアラート名４０２を選択し、参照ログ入力ボックス８５４にてログ名３０２を選択し、条件入力ボックス８５５にて大なり、小なり、等号、不等号を選択し、閾値入力ボックス８５６に閾値を入力した後、決定ボタン８５７を操作すると、障害原因候補決定条件を新規に定義できる。

アラート追加ボタン８５８は、一つの障害種別入力ボックス８５２に対して複数のアラート名入力ボックス８５３を対応付ける場合に用いられる。すなわち、アラート追加ボタン８５８の操作によって、アラート名入力ボックス８５３を新たに一項目表示する。

ログ追加ボタン８５９は、一つの障害種別入力ボックス８５２に対して複数の参照ログ入力ボックス８５４と、条件入力ボックス８５５と、閾値入力ボックス８５６とを対応付けるために用いられる。すなわち、ログ追加ボタン８５９の操作によって、参照ログ入力ボックス８５４と、条件入力ボックス８５５と、閾値入力ボックス８５６を新たに一項目ずつ表示する。

条件追加ボタン８６０の操作によって、障害原因入力ボックス８５１と、障害種別入力ボックス８５２と、アラート名入力ボックス８５３と、参照ログ入力ボックス８５４と、条件入力ボックス８５５と、閾値入力ボックス８５６を新たに一項目ずつ表示する。

条件削除ボックス８６１は、障害原因候補決定条件を削除するために操作されるボタンであり、選択された行の障害原因候補決定条件を削除できる。

設定ファイル選択ボタン８７０の操作によってファイルを選択する画面を表示できる。このファイルを選択する画面において、アラート名５０１、障害原因５０２、障害種別５０３、収集ログ５０５及び合致条件５０６をリスト化したファイルが選択でき、複数の障害原因候補決定条件が定義できる。

設定情報管理画面８００上にて、障害種別入力ボックス８８１に障害種別５０３を入力した後、決定ボタン８８２を操作すると、障害種別を新規に定義できる。

分類追加ボタン８８３の操作によって、障害種別入力ボックス８８１と決定ボタン８８２を新たに一項目ずつ表示できる。

種別削除ボックス８８４は、障害種別５０３を削除するために操作されるボタンであり、選択された行の障害種別５０３を削除できる。

優先度上昇ボタン８８５を操作すると、その行に表示された障害種別５０３の優先度６０１を一つ上げることができる。

設定更新ボタン８９０が操作されると、入出力部１４０は設定情報管理画面８００上に表示された設定情報に従って管理テーブル群１２２を更新する。

以上に説明したように、実施例１によれば、アラートから障害原因候補を決定し、決定された障害原因候補の検証順序を決定することによって、ダウンタイムを最小化する高効率な障害原因特定を実現するログ収集を可能とする。また、障害発生時に継続的にログを収集する必要がある場合や、アラートを継続的に監視する必要がある場合のために、決定された障害原因候補に応じて、ログの収集条件やアラート生成条件を更新できる。

障害原因候補の検証順序は、事前に決定してもよいし、障害種別や障害の発生頻度等の障害履歴等を基に動的に決定してもよい。これらの設定は設定情報管理画面８００等によってユーザが設定し、設定内容を確認できる。

本実施例では説明のため、ログの収集条件、アラート生成条件、障害原因候補の決定条件、及び優先度をテーブルで管理したが、ソフトウェア内部に保持する等、その管理手段によらず本実施例の効果が得られる。

＜実施例２＞
実施例２では、障害原因特定時の処理手順が異なる。実施例２では障害原因特定のためにログを収集する際に、通信装置の動作を阻害しないよう収集禁止条件を設ける機能と、ユーザが求める要件に応じて収集可否を決定する機能を追加する。以下、実施例２について実施例１との差異を中心に説明する。なお、実施例２において実施例１と同じ構成及び機能には同じ符号を付し、それらの説明は省略する。

図９は、実施例２の通信装置１００の構成の一例を示す図である。

本実施例の通信装置１００は、ＣＰＵ１１０、メモリ１２０、通信インターフェース１３０及び入出力部１４０を有し、各構成要素は通信装置内ネットワーク１５０を介して接続される。

ＣＰＵ１１０は、プログラムを実行する演算装置であり、プログラムを実行することによって、特定の機能を実現する機能部（ログ収集部１１１、アラート生成部１１２、障害原因候補決定部１１３、収集モード決定部９０１、追加収集管理部９０２）として動作する。ＣＰＵ１１０がプログラムを実行して行う処理の一部を、他の演算装置（例えば、ＦＰＧＡ（Field Programmable Gate Array）、ＡＳＩＣ（Application Specific Integrated Circuit）などのハードウェア）で実行してもよい。以下の説明では、機能部を主語にした処理の説明は、ＣＰＵ１１０が当該機能部を実現するプログラムを実行していることを意味する。

図１０は、実施例２の通信装置１００の構成要素間の入出力の一例を示す図である。

管理テーブル群１２２は、ログ収集条件管理テーブル２０１、アラート条件管理テーブル２０２、障害原因管理テーブル２０３、優先度管理テーブル２０４、追加収集管理テーブル１００１及び収集モード管理テーブル１００２を含む。

収集モード決定部９０１は、障害原因を特定する際に収集の傾向を決定付ける収集モードを決定する。収集モードとは、例えば、通信装置の稼働を優先するために収集に時間のかかるログの収集を停止するモードや、通信帯域を節約するためにデータ量の大きいログの収集を抑制するモードなどである。入出力部１４０を介して通信インターフェース１３０から受信する入力や、収集モード管理テーブル１００２に記載の収集モードごとの合致条件１２０２によって、収集モードを決定できる。

追加収集管理部９０２は、障害原因候補決定部１１３が障害原因を特定する際に行う問い合わせに対して、追加収集管理テーブル１００１のログ情報１１０２、追加収集可否１１０３及び収集禁止条件１１０４を参照し、修正した追加収集リストを返信する。問い合わせに対応する際には、収集モード決定部９０１に収集モードを問い合わせる。

図１１は、追加収集管理テーブル１００１の一例を示す図である。

追加収集管理テーブル１００１には、ログ名１１０１、ログ情報１１０２、追加収集可否１１０３及び収集禁止条件１１０４が記載される。ログ名１１０１は、ログ名３０２と同一であり、ログ収集条件管理テーブル２０１に記載のログ名３０２が引用される。ログ情報１１０２には、ログ毎の情報、例えば、収集に必要な収集時間や収集されるログのデータ量などが記載される。追加収集可否１１０３には、ログ毎に、収集モード決定部９０１にて決定される収集モードにおける収集可否が記載される。収集禁止条件１１０４には、ログ毎に決定される収集を禁止する条件が記載される。例えば、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）に接続されていない状態ではＷＡＮに関する情報の収集を禁止する、重要なプロセスが稼働している際には収集時間が長いログの収集を禁止するなどである。

図１２は、収集モード管理テーブル１００２の一例を示す図である。

収集モード管理テーブル１００２には、収集モード１２０１及び合致条件１２０２が記載される。収集モード管理テーブル１００２に記載された収集モード以外に、通常時に適用されるデフォルトモードがあるとよい。収集モード１２０１には、収集モードの名称が記載される。合致条件１２０２には、収集モード毎に、条件を満たす場合に収集モードを切り替える条件が記載される。収集モードの切り替えは、例えば、ＣＰＵの使用率が８０％を超えた場合に、通信装置の稼働を優先するモードに移行する等である。稼働優先モードでは、通信装置本来の動作を阻害しないように、収集時間が長いログの収集を抑制する。収集モードは、収集モード決定部９０１が切り替える。

以下に、収集モード決定部９０１が実行する処理について説明する。

図１３は、収集モード決定部９０１が実行する収集モード更新処理のフローチャートである。収集モード決定部９０１は、収集モードの更新が許可されていない場合には現在の収集モードを変更せず、収集モードの更新が許可されている場合に一定の周期で収集モード更新処理を実行する。

Ｓ３１：収集モード管理テーブル１００２を管理テーブル群１２２から取得する。

Ｓ３２：収集モード管理テーブル１００２から一行を参照し、合致条件１２０２を満たすかを判定する。なお、収集モード管理テーブル１００２の取得直後には先頭行から参照するとよい。合致条件１２０２を満たす場合、ステップＳ３４に処理を進め、合致条件１２０２を満たさない場合、ステップＳ３３に処理を進める。

Ｓ３３：収集モード管理テーブル１００２の次の行を参照し、ステップＳ３２に処理を戻す。

Ｓ３４：ステップＳ３２で合致条件１２０２を満たす収集モード１２０１に、収集モードを変更する。

以下に、図１４（Ａ）、図１４（Ｂ）を参照して、実施例２において障害原因候補決定部１１３及び追加収集管理部９０２が実行する処理について説明する。

図１４（Ａ）は、実施例２の障害原因候補決定部１１３と追加収集管理部９０２が実行する障害原因候補決定処理のフローチャートである。障害原因候補決定部１１３は、アラートを検知すると以下の手順を実行する。ただし、ステップＳ２１からステップＳ２８までは実施例１と同一の処理であるため、説明を省略する。

Ｓ４１：ステップＳ２１の後、追加収集リストを追加収集管理部９０２に送信し、ログ収集可否及び収集順序を考慮した追加収集リストを得る。その後、ステップＳ２２以後の処理を実行する。

次に、図１４（Ｂ）を参照して、追加収集リストの更新（Ｓ４１）の詳細な処理について説明する。追加収集管理部９０２は、ステップＳ４１で障害原因候補決定部１１３が発する問い合わせに対し、以下の問い合わせ対応手順を実行する。

Ｓ５１：追加収集管理テーブル１００１を参照し、受信した追加収集リストに記載されたログについて収集禁止条件１１０４を判定する。収集禁止条件１１０４を満たすログを追加収集リストから消去する。

Ｓ５２：収集モード決定部９０１に収集モード１２０１を問い合わせ、現在の収集モード１２０１を得る。

Ｓ５３：追加収集管理テーブル１００１の追加収集可否１１０３を参照し、受信した追加収集リストに記載されたログについて、収集モード１２０１毎の収集可否に従って追加収集リストのログを削除する。その後、収集モード１２０１に応じてログ情報１１０２を参照し、収集順序を決定し、決定した収集順序に従って追加収集リストの順序を入れ替える。例えば、稼働優先モードでは、収集時間を参照し、時間が早い順に収集順序を決定するなどの動作である。最後に、作成した追加収集リストを障害原因候補決定部１１３に送信する。

以下に、通信装置１００にネットワークを介して接続された端末が、ブラウザを介して通信装置１００にアクセスした際に、入出力部１４０が表示する追加収集管理画面１５００と、その画面上のインターフェースを介して表示する条件変更画面１５１０について説明する。なお、本発明は以下に説明する追加収集管理画面１５００や条件変更画面１５１０上の表示内容や操作内容に限定して解釈されるものではない。

図１５（Ａ）は、通信装置の追加収集管理画面１５００の一例を示す図であり、図１５（Ｂ）は、条件変更画面１５１０の一例を示す図である。

入出力部１４０は、管理テーブル群１２２を参照し、追加収集管理画面１５００を作成する。追加収集管理画面１５００には、追加収集管理テーブル１００１及び収集モード管理テーブル１００２に記録された内容が表示される。

追加収集管理テーブル１００１の内容は、ログ名１１０１、ログ情報１１０２、追加収集可否１１０３及び収集禁止条件１１０４の各項目が対応付けられ、ログ追加収集可否として表示される。

収集モード管理テーブル１００２の内容は、収集モード１２０１及び合致条件１２０２が対応付けられ、モード自動変更条件として表示される。

以下、追加収集管理画面１５００上での操作について説明する。

収集モード入力ボックス１５０１によって、収集モード１２０１を選択できる。収集モード入力ボックス１５０１にて選択可能な項目は、収集モードの他に、自動変更モードの項目が存在する。自動変更モードでは、収集モード決定部９０１の収集モードの更新を許可し、条件に合わせて動的に収集モード１２０１を切り替える。

参照情報入力ボックス１５０２によって、収集モード１２０１ごとに、追加収集管理部９０２がステップＳ５３でログの収集順序の決定根拠とするログ情報１１０２を決定できる。収集順序は参照情報の昇順で決定される。なお、降順チェックボックス１５０３のチェックによって、収集順序は参照情報の降順で決定される。

条件変更ボタン１５０４の操作によって、条件変更画面１５１０（図１５（Ｂ））が表示される。

追加収集管理画面１５００上にて、収集モード入力ボックス１５０５に収集モード名を入力した後、決定ボタン１５０６を操作すると、新しい収集モード１２０１を定義できる。

収集モード追加ボタン１５０７の操作によって、収集モード入力ボックス１５０５と決定ボタン１５０６を新たに一項目ずつ表示できる。

収集可否決定チェックボックス１５０８は、各行に記載されたログの収集可否を表示し変更するためのチェックボックスであり、追加収集管理画面１５００の生成時に追加収集管理テーブル１００１の追加収集可否１１０３が可の場合にチェック有、否の場合にチェックなしのチェックボックスを表示する。画面上でチェックボックスをチェックすると追加収集可否１１０３を可に更新でき、チェックを外すと追加収集可否１１０３を否に更新できる。

条件変更画面１５１０では、参照ログ入力ボックス１５１１にてログ名１１０１を選択し、条件入力ボックス１５１２にて大なり、小なり、等号、不等号等の条件を選択し、値入力ボックス１５１３にて閾値を入力した後、条件変更完了ボタン１５１４を操作すると、合致条件１２０２や収集禁止条件１１０４を変更できる。

設定更新ボタン１５０９が操作されると、入出力部１４０は追加収集管理画面１５００上に表示された設定情報に従って管理テーブル群１２２を更新する。

以上に説明したように、実施例２によれば、収集禁止条件１１０４によって、発生するはずのない障害原因の特定手順を除外できる。また、収集禁止条件１１０４と、モード毎の追加収集可否１１０３によって、通信装置へのユーザ要件に応じた障害原因特定手段を提供できる。例えば、産業機器の制御情報を送受信する通信装置１００では、制御情報の通信を阻害することなく、障害原因を特定する必要がある。このような場合に、通信装置１００のリソースを大きく消費するログの収集を停止する、軽い処理で済むログ収集を中心に原因特定を進める等の機能を切り替えて提供できる。さらに、収集モード１２０１を動的に切り替えることによって、時間ごとに変化するユーザ要件に適合する障害原因特定手段を提供できる。例えば、通信装置や通信装置に接続される機器が主体的に稼働し、リソースの使用率が高い就業時間内にて稼働優先モードとしてリソースの消費を抑制し、リソースの使用率が低い就業時間外にて障害原因を詳細に特定するなどの機能を提供できる。

今回は説明のため、追加収集条件及びモード変更条件をテーブルで管理したが、ソフトウェア内部に保持する等、その管理手段によらず本実施例の効果が得られる。

＜実施例３＞
実施例３では、複数の通信装置１００に加え、監視サーバ１６００を備える障害原因特定システムを提供する。監視サーバ１６００は、複数の通信装置１００から収集したログやアラートを参照し、障害原因候補を決定する。そして、決定された障害原因候補に応じて、複数の通信装置のログ収集条件やアラート条件を更新する。以下、実施例３について実施例１との差異を中心に説明する。なお、実施例３において実施例１と同じ構成及び機能には同じ符号を付し、それらの説明は省略する。

図１６は、実施例３の障害原因特定システムの構成の一例を示す図である。

障害原因特定システムは、監視サーバ１６００及び複数の通信装置１００～１０Ｎで構成される。

監視サーバ１６００は、ＣＰＵ１６１０、メモリ１６２０、通信インターフェース１６３０及び入出力部１６４０を有し、各構成要素は監視サーバ内ネットワーク１６５０を介して接続される。監視サーバ内ネットワーク１６５０は、その種別及び接続方式に限定されず、構成要素間を接続するネットワーク種別や接続方式は異なってもよい。

ＣＰＵ１６１０は、プログラムを実行する演算装置であり、プログラムを実行することによって、特定の機能を実現する機能部（ログ・アラート受信部１６１１、ログ・アラート解析部１６１２）として動作する。ＣＰＵ１６１０がプログラムを実行して行う処理の一部を、他の演算装置（例えば、ＦＰＧＡ（Field Programmable Gate Array）、ＡＳＩＣ（Application Specific Integrated Circuit）などのハードウェア）で実行してもよい。以下の説明では、機能部を主語にした処理の説明は、ＣＰＵ１６１０が当該機能部を実現するプログラムを実行していることを意味する。

メモリ１６２０は、各通信装置１００～１０Ｎから収集したログデータ１６２１や、各通信装置１００～１０Ｎが持つ管理テーブル群１２２を通信装置ごとに格納した管理テーブルデータベース１６２２を格納する。

ＣＰＵ１６１０が実行するプログラムは、リムーバブルメディア（ＣＤ－ＲＯＭ、フラッシュメモリなど）又はネットワークを介して監視サーバ１６００に導入され、非一時的記憶媒体である不揮発性の補助記憶装置（図示省略）に格納される。このため、監視サーバ１６００は、リムーバブルメディアからデータを読み込むインターフェースを有するとよい。

監視サーバ１６００は、一つの計算機上で、又は、論理的又は物理的に構成された複数の計算機上で構成される計算機システムであり、同一の計算機上で別個のスレッドで動作してもよく、複数の物理的計算機資源上に構築された仮想計算機上で動作してもよい。

実施例３の通信装置１００～１０Ｎは、ＣＰＵ１１０、メモリ１２０、通信インターフェース１３０及び入出力部１４０を有する。

ＣＰＵ１１０は、プログラムを実行する演算装置であり、プログラムを実行することによって、特定の機能を実現する機能部（ログ・アラート送信部１６７１、命令実行部１６７２）として動作する。ＣＰＵ１１０がプログラムを実行して行う処理の一部を、他の演算装置（例えば、ＦＰＧＡ（Field Programmable Gate Array）、ＡＳＩＣ（Application Specific Integrated Circuit）などのハードウェア）で実行してもよい。以下の説明では、機能部を主語にした処理の説明は、ＣＰＵ１１０が当該機能部を実現するプログラムを実行していることを意味する。

監視サーバ１６００と複数の通信装置１００～１０Ｎとは、ネットワーク１６６０を介して接続される。ネットワーク１６６０は、その種別及び接続方式に限定されず、装置間を接続するネットワークの種別や接続方式は異なってもよい。

図１７は、実施例３の障害原因特定システムの構成要素の入出力の一例を示す図である。

以下、監視サーバ１６００の入出力や構成について説明する。

管理テーブルデータベース１６２２は、ログ収集条件データベース１７０１、アラート条件データベース１７０２、障害原因データベース１７０３及び優先度データベース１７０４を含む。

ログ収集条件データベース１７０１は、ログ収集条件管理テーブル２０１と同じ内容を通信装置１００～１０Ｎと関連付けて格納する。アラート条件データベース１７０２は、アラート条件管理テーブル２０２と同じ内容を通信装置１００～１０Ｎと関連付けて格納する。障害原因データベース１７０３は、障害原因管理テーブル２０３と同じ内容を通信装置１００～１０Ｎと関連付けて格納する。優先度データベース１７０４は、優先度管理テーブル２０４と同じ内容を通信装置１００～１０Ｎと関連付けて格納する。

ログ・アラート受信部１６１１は、通信インターフェース１６３０を介して、通信装置１００～１０Ｎからログ及びアラートを受信し、受信したログをログデータ１６２１に格納し、受信したアラートをログ・アラート解析部１６１２に通知する。

ログ・アラート解析部１６１２は、通信装置１００～１０Ｎから受信したログ及びアラートを解析し、解析の結果、テーブル更新指示を抽出して、抽出されたテーブル更新指示を管理テーブルデータベース１６２２に送信し、抽出されたテーブル更新指示を通信インターフェース１６３０を介して通信装置１００～１０Ｎに送信する。ここでログ及びアラートの解析は、例えば、複数の通信装置１００～１０Ｎのアラート及びログを参照した障害原因解析などである。

入出力部１６４０は、テーブル更新通知及び外部からの入力を通信インターフェース１６３０を介して受信し、管理テーブルデータベース１６２２を更新する。また、通信装置１００～１０Ｎの管理テーブル群１２２の更新指示を検知すると、通信装置１００～１０Ｎにテーブル更新通知を通信インターフェース１６３０を介して送信する。

障害原因データベース１７０３と優先度データベース１７０４には、監視サーバ１６００のみが持つ、複数通信装置参照用の障害原因管理テーブル２０３及び優先度管理テーブル２０４が格納されている。ログ・アラート解析部１６１２は、複数の通信装置１００～１０Ｎからアラートが通知された場合に、障害原因候補を決定するために、これらの管理テーブル２０３、２０４を参照する。

以下、通信装置１００～１０Ｎの入出力や構成における実施例１との差異について説明する。

ログ・アラート送信部１６７１は、ログ収集部１１１が収集したログや、アラート生成部１１２が生成したアラートを、通信インターフェース１３０を介して、監視サーバ１６００に送信する。

命令実行部１６７２は、監視サーバ１６００より通信インターフェース１３０を介して受信した命令を実行する。

入出力部１４０は、管理テーブル群１２２の更新を検知すると、通信インターフェース１３０を介して監視サーバ１６００にテーブル更新通知を送信する。また、入出力部１４０は、通信インターフェース１３０を介してテーブル更新通知を受信し、管理テーブル群１２２を更新する。

以下に、実施例３においてログ・アラート解析部１６１２が実行する処理について説明する。

図１８は、実施例３のログ・アラート解析部１６１２が実行する障害原因候補決定処理のフローチャートである。ログ・アラート解析部１６１２は、動作を開始すると下記の手順を実行する。

Ｓ６１：入出力部１６４０より終了指示が入力されているかを判定し、終了指示が入力されている場合、動作を終了する。終了指示が入力されていない場合、ステップＳ６２に処理を進める。

Ｓ６２：ログ・アラート受信部１６１１がアラートを受信しているかを判定し、複数の通信装置１００～１０Ｎから同一のアラートを受信している場合、ステップＳ６３に処理を進める。複数の通信装置１００～１０Ｎから同一のアラートを受信していない場合、ステップＳ６１に処理を戻す。

Ｓ６３：監視サーバ１６００のみが持つ、複数通信装置参照用の障害原因管理テーブル２０３と優先度管理テーブル２０４を参照し、アラートを送信した全通信装置を、通信装置ごとにログを参照し、障害原因候補決定処理を実行する。障害原因候補の決定には、実施例１の通信装置１００と同様に、ステップＳ２１からステップＳ２８までの処理を実行する。

Ｓ６４：複数通信装置参照用の障害原因管理テーブル２０３のうち、ステップＳ６３にて決定された障害原因候補の行における発生回数５０４の値に１を加算する。

Ｓ６５：ログ収集条件データベース１７０１を参照し、ステップＳ６３にて障害原因候補を決定した通信装置のログ収集条件管理テーブル２０１における決定された障害原因候補に関連するログの情報を更新する。例えば、障害原因管理テーブル２０３において、候補として決定された障害原因５０２の行における収集ログ５０５と一致するログ収集条件管理テーブル２０１のログ名３０２を持つ行において、収集周期３０３を最短の時間に変更し、収集フラグ３０４が０の場合、０から１に変更するテーブル更新処理を実行する。

Ｓ６６：アラート条件データベース１７０２を参照し、ステップＳ６３にて障害原因候補を決定された通信装置のアラート条件管理テーブル２０２において、決定された障害原因候補に関連するアラートの情報を更新する。例えば、候補として決定された障害原因５０２の行におけるアラート名５０１と一致するアラート名４０２を持つアラート条件管理テーブル２０２の行において、チェック周期４０５を最短の時間に変更する。

以下に、監視サーバ１６００にネットワークを介して接続された端末が、ブラウザを介して監視サーバ１６００にアクセスした際に、入出力部１６４０が表示する画面での操作について説明する。

入出力部１６４０は、実施例１と同様の設定情報管理画面８００を表示する。この時、ブラウザが参照するＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を変更することによって、設定表示・更新の対象とする通信装置１００～１０Ｎを変更できるとよい。

画面上の操作に関しては、実施例１と同一であるため、説明を省略する。

画面操作によって設定が更新された後、入出力部１６４０は、管理テーブルデータベース１６２２を更新すると共に、通信インターフェース１６３０を介して、参照された通信装置１００～１０Ｎにテーブル更新通知を送信する。

以上に説明したように、実施例３によれば、監視サーバ１６００に集約されたログ・アラートを参照することによって、通信装置単体では検知が不可能な障害原因を検知できる。例えば、複数の通信装置１００～１０Ｎで無線通信区間のエラー率が上昇した際には、付近で干渉波が発生している可能性がある。通信装置単体ではエラー率上昇の原因が、アンテナの故障などの通信装置固有の問題か、複数の通信装置に影響する干渉波かの判断が困難である。しかし、本実施例の障害原因特定システムによると、複数の通信装置のエラー率上昇アラートを参照し、干渉波が原因であることを特定できる。

また、本実施例によれば、複数通信装置を参照する障害原因候補特定の優先度を決定できる。通信装置単体ではハードウェアやソフトウェアを疑う問題でも、通信装置１００～１０Ｎで複数の同一アラートが生成される場合には、無線通信やネットワークに関する不具合が原因であることが多い。このため複数通信装置を参照して障害原因候補を決定すると、ネットワークに関する障害原因候補を優先的に決定でき、高効率で障害原因候補を決定できる。

本実施例では説明のため、ステップＳ６２にて複数の同一アラートを検知することを障害原因候補決定の起点としたが、起点となる条件を問わず、本実施例は同様の効果が得られる。例えば、監視サーバ１６００上で通信装置１００～１０Ｎのログ情報１１０２を参照する条件検証動作を定義し、条件を満たす通信装置１００～１０Ｎを対象に障害原因候補を決定してもよい。

＜実施例４＞
実施例４では、実施例１において通信装置１００で実行した処理を、監視サーバ１６００にて実行する。以下、実施例１から実施例３との差異を中心に実施例４について説明する。なお、実施例４において、前述した実施例と同じ構成及び機能には同じ符号を付し、それらの説明は省略する。

図１９は、実施例４の障害原因特定システムの構成の一例を示す図である。

障害原因特定システムは、監視サーバ１６００と複数の通信装置１００～１０Ｎで構成される。

監視サーバ１６００及び通信装置１００～１０Ｎの構成要素は実施例３と同一である。

ＣＰＵ１６１０は、プログラムを実行する演算装置である。ＣＰＵ１６１０は、プログラムを実行することによって、特定の機能を実現する機能部（ログ・アラート受信部１６１１、障害原因候補決定部１９０１）として動作する。ログ・アラート受信部１６１１の用途及び動作は実施例３と同一であるため、説明を省略する。

ＣＰＵ１１０は、プログラムを実行する演算装置である。ＣＰＵ１１０は、プログラムを実行することによって、特定の機能を実現する機能部（ログ収集部１１１、アラート生成部１１２、ログ・アラート送信部１６７１、命令実行部１６７２）として動作する。以下の説明では、機能部を主語にした処理の説明は、ＣＰＵ１１０が当該機能部を実現するプログラムを実行していることを意味する。

ログ収集部１１１及びアラート生成部１１２の用途及び動作は実施例１と同一であり、ログ・アラート送信部１６７１及び命令実行部１６７２の用途及び動作は実施例３と同一であるため、説明を省略する。

図２０は、実施例４の障害原因特定システムの構成要素の入出力の一例を示す図である。以下、実施例１及び実施例３との差異を中心に説明する。

障害原因候補決定部１９０１は、ログ・アラート受信部１６１１からアラート通知を受信すると、障害原因データベース１７０３と優先度データベース１７０４を参照し、障害原因候補を決定する。障害原因候補決定部１９０１は、障害原因候補を決定するために、ログの追加収集を通信インターフェース１６３０を介して通信装置１００～１０Ｎに指示する。さらに、候補として決定された障害原因に応じて、ログ収集条件データベース１７０１、アラート条件データベース１７０２及び障害原因データベース１７０３を更新する。

入出力部１６４０は、ログ収集条件データベース１７０１及びアラート条件データベース１７０２を参照し、ログ収集条件やアラート条件を通信インターフェース１６３０を介して通信装置１００～１０Ｎに送信する。

ログ収集部１１１及びアラート生成部１１２は、通信インターフェース１３０を介して受信したログ収集条件及びアラート条件に従って、ログを収集し、アラートを生成する。

以下に、実施例４において障害原因候補決定部１９０１が実行する処理について説明する。

障害原因候補決定部１９０１は、実施例１における障害原因候補決定部１１３と同一の処理を実行する。この処理において、管理テーブルデータベース１６２２から、アラートを生成した通信装置１００～１０Ｎの管理テーブル群１２２を参照する。

以上に説明したように、実施例４によれば、監視サーバ１６００に通信装置１００～１０Ｎの機能を集約することによって、障害原因候補の決定に必要な通信装置１００～１０Ｎの使用リソース量を抑制した障害原因特定手段を提供できる。例えば、産業機器の制御情報を送受信する通信装置１００～１０Ｎでは、制御情報の通信を阻害することなく、障害原因を特定する必要がある。この際、障害原因候補決定処理が並列して実行されると、通信装置１００～１０Ｎのリソース使用率が高まり、制御情報の通信を阻害する可能性がある。実施例４のように監視サーバ１６００上で障害原因候補を決定する処理を実行し、通信装置１００～１０Ｎが追加のログ収集を実行するので、リソース使用量を抑制し、制御情報の通信に失敗する可能性を低減できる。

＜実施例５＞
実施例５では、実施例４の処理に加えて、実施例２において通信装置１００で実行した処理を、監視サーバ１６００にて実行する。以下、実施例１から実施例３との差異を中心に実施例５について説明する。なお、実施例５において、前述した実施例と同じ構成及び機能には同じ符号を付し、それらの説明は省略する。

図２１は、実施例５の障害原因特定システムの構成の一例を示す図である。

障害原因特定システムは、監視サーバ１６００と複数の通信装置１００～１０Ｎで構成される。

監視サーバ１６００及び通信装置１００～１０Ｎの構成要素は実施例４と同一である。

ＣＰＵ１６１０は、プログラムを実行する演算装置である。ＣＰＵ１６１０は、プログラムを実行することによって、特定の機能を実現する機能部（収集モード決定部２１０１、追加収集管理部２１０２）として動作する。ログ・アラート受信部１６１１の用途及び動作は実施例３と同一であるため、説明を省略する。

収集モード決定部２１０１及び追加収集管理部２１０２以外の機能部の動作や入出力は実施例４と同一であるため、説明を省略する。

図２２は、実施例５の障害原因特定システムの構成要素の入出力の一例を示す図である。

管理テーブルデータベース１６２２は、追加収集管理データベース２２０１及び収集モードデータベース２２０２を含む。

追加収集管理データベース２２０１は、追加収集管理テーブル１００１を格納する。収集モードデータベース２２０２は、収集モード管理テーブル１００２と同じ内容を通信装置１００～１０Ｎと関連付けて格納する。

収集モード決定部２１０１は、障害原因候補を決定する際に収集の傾向を決定付ける収集モード１２０１を決定する。入出力部１６４０を介して通信インターフェース１６３０から受信する入力や、収集モードデータベース２２０２に格納された収集モード管理テーブル１００２に記載された収集モード毎の合致条件１２０２を用いて、収集モード１２０１が決定される。

追加収集管理部２１０２は、障害原因候補決定部１９０１が障害原因候補を決定する際に行う問い合わせに対して、追加収集管理データベース２２０１に格納された追加収集管理テーブル１００１のログ収集可否・収集順序や、収集禁止条件１１０４を参照し、修正された追加収集リストを返信する。問い合わせに対応する際には、収集モード決定部２１０１に収集モード１２０１を問い合わせる。

収集モード決定部２１０１は、実施例２における収集モード決定部９０１と同一の処理を実行する。

以下に、実施例５において障害原因候補決定部１９０１と追加収集管理部２１０２が実行する処理について説明する。処理の際に、管理テーブルデータベース１６２２から、収集モード１２０１を決定する通信装置１００～１０Ｎの収集モード管理テーブル１００２を参照する。

障害原因候補決定部１９０１は、実施例２における障害原因候補決定部１１３と同一の処理を実行する。処理の際に、アラートを生成した通信装置の管理テーブル群１２２を、管理テーブルデータベース１６２２から参照する。

追加収集管理部２１０２は、実施例２における追加収集管理部９０２と同一の処理を実行する。処理の際に、アラートを生成した通信装置１００～１０Ｎの追加収集管理テーブル１００１を、管理テーブルデータベース１６２２から参照する。

実施例５によれば、実施例４の効果に加え、発生するはずのない障害原因の特定手順を、収集禁止条件１１０４によって除去できる。また、収集禁止条件１１０４と、モード毎の追加収集可否１１０３によって、通信装置１００～１０Ｎのユーザ要件に応じた障害原因特定手段を提供できる。さらに、収集モード１２０１を動的に切り替えることによって、時間ごとに変化するユーザ要件に適合して障害原因を特定できる。

以上に説明したように、本発明の実施例の通信装置１００は、通信装置１００及び通信装置１００に接続される機器の少なくとも一方から第１の種類のログを収集するログ収集部１１１と、収集されたログが所定の条件を満たす場合にアラートを生成するアラート生成部１１２と、生成されたアラートに対応して障害原因候補を決定し、候補として決定された障害原因に対応して定められる追加ログ収集順序に従って、第２の種類のログを収集するための追加ログ収集要求をログ収集部１１１に出力する障害原因候補決定部１１３とを備えるので、障害発生時にダウンタイムを最小化する高効率な障害原因特定を実現するログ収集が可能となる。

また、障害原因候補決定部１１３は、追加ログ収集要求に従って収集された第２の種類のログが所定の条件を満たすかによって、障害原因候補を特定するので、障害の原因が正確かつ迅速に特定できる。

また、障害原因候補決定部１１３は、候補として決定された障害原因に基づいて追加ログ収集順序を決定するので、システム要件に適する順序でログを収集できる。

また、障害原因候補決定部１１３は、過去の障害の情報に基づいて追加ログ収集順序を決定するので、発生頻度が高い障害を早期に検出できる。

また、通信装置１００は、入力情報を受け付ける入出力部１４０を備え、入力情報に従って動作を変更し、構成要素の設定情報を更新するので、ログ収集条件及びアラート条件が外部からの入力によって設定可能となる。

また、障害原因候補決定部１１３は、候補として決定された障害原因と関連するログの収集条件の更新をログ収集部１１１へ指示し、ログ収集部１１１は、障害原因候補決定部１１３からの指示に従ってログの収集条件を更新するので、障害の発生状況に応じてログを収集できる。例えば、ログ収集間隔を短くすることによって障害状況を的確に把握できる。

また、障害原因候補決定部１１３は、候補として決定された障害原因と関連するアラートの生成条件の更新をアラート生成部１１２へ指示し、アラート生成部１１２は、障害原因候補決定部１１３からの指示に従ってアラートの生成条件を更新するので、障害の発生状況に応じて的確にアラートを生成できる。例えば、アラート周期を短くすることによって障害検出タイミングが早くなり、迅速に障害を検出できる。

また、入力情報に従って収集モードを決定する収集モード決定部９０１と、決定された収集モード毎に追加ログ収集に関する情報を管理する追加収集管理部９０２とを備え、障害原因候補決定部１１３は、追加収集管理部９０２からの情報に従って追加ログ収集順序及び追加ログ収集可否を決定するので、システム要件に適する障害の検出ができる。

また、収集モード決定部９０１は、収集モード切替条件を満たす場合に収集モードを変更するので、システムの実運用を阻害することなくログを収集できる。

また、障害原因候補決定部１１３は、追加ログ収集要求を出力する際に、追加収集管理部９０２に従って所定の条件を満たすログを収集しないように要求するので、本来の動作を邪魔することなくログを収集できる。

また、収集されたログ及び生成されたアラートを監視サーバ１６００に送信するログ・アラート送信部１６７１と、監視サーバ１６００から受信した命令を実行する命令実行部１６７２とを備え、監視サーバ１６００は、通信装置１００からログ及びアラートを受信し、１又は複数の通信装置１００のログ及びアラートを参照することによって障害原因を絞り込み、設定情報の変更を通信装置１００に指示するので、障害が発生している通信装置の数の情報を用いて障害原因候補を容易かつ正確に決定できる。また、複数の通信装置で発生している障害は重要度が高いことから迅速に障害に対応する契機となる。

また、本発明の実施例の監視サーバ１６００は、通信装置１００が取得した第１の種類のログに基づいて発生したアラートを受信するログ・アラート受信部１６１１と、生成されたアラートに対応して障害原因候補を決定し、候補として決定された障害原因に対応して定められる追加ログ収集順序に従って、第２の種類のログを収集するための追加ログ収集要求を通信装置１００に出力する障害原因候補決定部１９０１とを備えるので、障害発生時にダウンタイムを最小化する高効率な障害原因特定を実現するログ収集が可能となる。また、通信装置１００のリソースを圧迫せずに障害原因を特定できる。

なお、本発明は前述した実施例に限定されるものではなく、添付した特許請求の範囲の趣旨内における様々な変形例及び同等の構成が含まれる。例えば、前述した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに本発明は限定されない。また、ある実施例の構成の一部を他の実施例の構成に置き換えてもよい。また、ある実施例の構成に他の実施例の構成を加えてもよい。また、各実施例の構成の一部について、他の構成の追加・削除・置換をしてもよい。

また、前述した各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等により、ハードウェアで実現してもよく、プロセッサがそれぞれの機能を実現するプログラムを解釈し実行することにより、ソフトウェアで実現してもよい。

各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリ、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記憶装置、又は、ＩＣカード、ＳＤカード、ＤＶＤ、ＢＤ等の記録媒体に格納することができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、実装上必要な全ての制御線や情報線を示しているとは限らない。実際には、ほとんど全ての構成が相互に接続されていると考えてよい。

１００～１０Ｎ 通信装置
１１０、１６１０ ＣＰＵ
１２０、１６２０ メモリ
１３０、１６３０ 通信インターフェース
１４０、１６４０ 入出力部
１５０ 通信装置内ネットワーク
１１１ ログ収集部
１１２ アラート生成部
１１３、１９０１ 障害原因候補決定部
１２１、１６２１ ログデータ
１２２ 管理テーブル群
２０１ ログ収集条件管理テーブル
２０２ アラート条件管理テーブル
２０３ 障害原因管理テーブル
２０４ 優先度管理テーブル
８００ 設定情報管理画面
９０１、２１０１ 収集モード決定部
９０２、２１０２ 追加収集管理部
１００１ 追加収集管理テーブル
１００２ 収集モード管理テーブル
１５００ 追加収集管理画面
１６００ 監視サーバ
１６５０ 監視サーバ内ネットワーク
１６６０ ネットワーク
１６１１ ログ・アラート受信部
１６１２ 条件更新部
１６２２ 管理テーブルデータベース
１６７１ ログ・アラート送信部
１６７２ 命令実行部
１７０１ ログ収集条件データベース
１７０２ アラート条件データベース
１７０３ 障害原因データベース
１７０４ 優先度データベース
１９０２ 命令生成部
２２０１ 追加収集管理データベース
２２０２ 収集モードデータベース

Claims (13)

1. 信号を転送する通信装置であって、
   所定の処理を実行する演算装置と、前記演算装置がアクセス可能な記憶装置とを備え、
   前記通信装置及び前記通信装置に接続される機器の少なくとも一方から第１の種類のログを収集するログ収集部と、
   前記収集されたログが所定の条件を満たす場合にアラートを生成するアラート生成部と、
   前記生成されたアラートに対応して障害原因候補を決定し、前記決定された障害原因候補に対応して定められる追加ログ収集順序に従って、第２の種類のログを収集するための追加ログ収集要求を前記ログ収集部に出力する障害原因候補決定部とを備えることを特徴とする通信装置。
2. 請求項１に記載の通信装置であって、
   前記障害原因候補決定部は、前記追加ログ収集要求に従って収集された第２の種類のログが所定の条件を満たすかによって、障害原因を特定することを特徴とする通信装置。
3. 請求項１に記載の通信装置であって、
   前記障害原因候補決定部は、前記決定された障害原因候補の種別または分類に基づいて前記追加ログ収集順序を決定することを特徴とする通信装置。
4. 請求項１に記載の通信装置であって、
   前記障害原因候補決定部は、過去の障害の情報に基づいて前記追加ログ収集順序を決定することを特徴とする通信装置。
5. 請求項１に記載の通信装置であって、
   入力情報を受け付ける入出力部を備え、
   前記入力情報に従って動作を変更し、構成要素の設定情報を更新することを特徴とする通信装置。
6. 請求項１に記載の通信装置であって、
   前記障害原因候補決定部は、前記決定された障害原因候補と関連するログの収集条件の更新を前記ログ収集部へ指示し、
   前記ログ収集部は、前記障害原因候補決定部からの指示に従って前記ログの収集条件を更新することを特徴とする通信装置。
7. 請求項１に記載の通信装置であって、
   前記障害原因候補決定部は、前記決定された障害原因候補と関連するアラートの生成条件の更新を前記アラート生成部へ指示し、
   前記アラート生成部は、前記障害原因候補決定部からの指示に従ってアラートの生成条件を更新することを特徴とする通信装置。
8. 請求項５に記載の通信装置であって、
   前記入力情報に従って収集モードを決定する収集モード決定部と、
   前記決定された収集モード毎に追加ログ収集に関する情報を管理する追加収集管理部とを備え、
   前記障害原因候補決定部は、前記追加収集管理部からの情報に従って前記追加ログ収集の順序及び前記追加ログ収集の可否を決定することを特徴とする通信装置。
9. 請求項８に記載の通信装置であって、
   前記収集モード決定部は、収集モード切替条件を満たす場合に前記収集モードを変更することを特徴とする通信装置。
10. 請求項１に記載の通信装置であって、
    ログの収集禁止条件を管理する追加収集管理部を備え、
    前記障害原因候補決定部は、前記追加ログ収集要求を出力する際に、前記追加収集管理部に従って所定の条件を満たすログを収集しないように要求することを特徴とする通信装置。
11. 請求項１に記載の通信装置であって、
    設定情報の変更を前記通信装置に命令する監視サーバと接続されており、
    前記収集されたログ及び前記生成されたアラートを前記監視サーバに送信するログ・アラート送信部と、
    前記監視サーバから受信した命令を実行する命令実行部とを備えることを特徴とする通信装置。
12. 通信装置の障害を監視する監視サーバであって、
    前記通信装置が取得した第１の種類のログに基づいて発生したアラートを受信するログ・アラート受信部と、
    前記発生したアラートに対応して障害原因候補を決定し、前記決定された障害原因候補に対応して定められる追加ログ収集順序に従って、第２の種類のログを収集するための追加ログ収集要求を前記通信装置に出力する障害原因候補決定部とを備えることを特徴とする監視サーバ。
13. 信号を転送する通信装置を含む通信システムにおけるログ収集方法であって、
    所定の処理を実行する演算装置と、前記演算装置がアクセス可能な記憶装置とを備え、
    前記演算装置が、前記通信装置及び前記通信装置に接続される機器の少なくとも一方から第１の種類のログを収集するログ収集ステップと、
    前記演算装置が、前記収集されたログが所定の条件を満たす場合にアラートを生成するアラート生成ステップと、
    前記演算装置が、前記生成されたアラートに対応して障害原因候補を決定し、前記決定された障害原因候補に対応して定められる追加ログ収集順序に従って、第２の種類のログを収集するための追加ログ収集要求を出力する障害原因候補決定ステップとを含むことを特徴とするログ収集方法。

Images