(57)【要約】【課題】操作者の操作により障害が発生した後に再度障害が発生した場合であっても、履歴の記憶量をそのままの状態に保持する構成と比較して、障害の調査に必要な履歴を記憶するとともに不要な履歴を記憶しない可能性を高める。【解決手段】管理端末１００は、監視対象の装置における動作に関する履歴をログ記憶部１１３に記憶するログ生成部１１２と、操作者の操作により監視対象の装置で障害が発生した場合に、ログ生成部１１２が記憶する履歴の記憶量を第１の記憶量から第１の記憶量とは異なる第２の記憶量に変更するようにログ生成部１１２に対して指示し、指示後に操作により再度障害が発生した場合に、履歴の記憶量を第２の記憶量から第１の記憶量に戻すようにログ生成部１１２に対して指示するログ詳細度変更部１１８とを備える。【選択図】図３
2019079354.tif 000002
【特許請求の範囲】
【請求項１】
監視対象の装置における動作に関する履歴を記憶部に記憶する記憶手段と、
操作者の操作により前記監視対象の装置で障害が発生した場合に、前記記憶手段が記憶する前記履歴の記憶量を第１の記憶量から当該第１の記憶量とは異なる第２の記憶量に変更するように当該記憶手段に対して指示し、当該指示後に当該操作により再度障害が発生した場合に、当該履歴の記憶量を当該第２の記憶量から当該第１の記憶量に戻すように当該記憶手段に対して指示する指示手段と
を備える情報処理装置。
【請求項２】
前記指示手段は、前記第１の記憶量から前記第２の記憶量に変更された後、前記操作による障害が再度発生することなく予め定められた条件が満たされた場合には、当該第２の記憶量から当該第１の記憶量に戻すように前記記憶手段に対して指示すること
を特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記予め定められた条件は、前記操作が予め定められた回数実行されたにもかかわらず障害が発生しないという条件であること
を特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記予め定められた条件は、前記操作とは別の操作が予め定められた回数実行されたという条件であること
を特徴とする請求項２に記載の情報処理装置。
【請求項５】
前記予め定められた条件は、前記操作による障害が発生してから予め定められた時間が経過したという条件であること
を特徴とする請求項２に記載の情報処理装置。
【請求項６】
前記第２の記憶量は、前記第１の記憶量に比べて記憶される履歴の量が多いこと
を特徴とする請求項１に記載の情報処理装置。
【請求項７】
前記第２の記憶量の履歴には、前記第１の記憶量の履歴と、当該履歴とは異なる種類の履歴とが含まれること
を特徴とする請求項６に記載の情報処理装置。
【請求項８】
前記操作による障害が発生したときに前記記憶手段が記憶する前記第２の記憶量の履歴は、当該操作による障害が発生したときに当該記憶手段が記憶する前記第１の記憶量の履歴よりも、当該障害の情報を多く含むこと
を特徴とする請求項６に記載の情報処理装置。
【請求項９】
監視対象の装置における動作に関する履歴を記憶部に記憶する記憶手段と、
操作者の操作により前記監視対象の装置で障害が発生した後、当該操作により再度障害が発生した場合に、前記記憶手段が記憶する前記履歴の記憶量を、再度障害が発生する前に比べて減少させるように当該記憶手段に対して指示する指示手段と
を備える情報処理装置。
【請求項１０】
コンピュータに、
監視対象の装置における動作に関する履歴を記憶部に記憶する機能と、
操作者の操作により前記監視対象の装置で障害が発生した場合に、前記記憶する機能による前記履歴の記憶量を第１の記憶量から当該第１の記憶量とは異なる第２の記憶量に変更するように制御し、当該制御の後に当該操作により再度障害が発生した場合に、当該履歴の記憶量を当該第２の記憶量から当該第１の記憶量に戻すように制御する機能と
を実現させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置及びプログラムに関する。
【背景技術】
【０００２】
例えば、特許文献１には、障害が発生しやすいと思われる状態（たとえば設置直後、設定が変更されたとき）であると判断したところで、自動的にログの詳細度を密にし、定常安定状態になったならば、自動的にログの詳細度を粗にする機能を持つサーバ装置が開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００６−２３６２３１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
監視対象の装置における動作に関する履歴を収集して、装置で発生した障害の調査を行う場合がある。従来、例えば、装置の稼働中に、操作者の操作により発生した障害を再現することが必要な状況では詳細な履歴を取得し、詳細な履歴の取得が不要となった場合に元の状態に戻すというような処理ができなかった。
本発明は、操作者の操作により障害が発生した後に再度障害が発生した場合であっても、履歴の記憶量をそのままの状態に保持する構成と比較して、障害の調査に必要な履歴を記憶するとともに不要な履歴を記憶しない可能性を高めることを目的とする。
【課題を解決するための手段】
【０００５】
請求項１に記載の発明は、監視対象の装置における動作に関する履歴を記憶部に記憶する記憶手段と、操作者の操作により前記監視対象の装置で障害が発生した場合に、前記記憶手段が記憶する前記履歴の記憶量を第１の記憶量から当該第１の記憶量とは異なる第２の記憶量に変更するように当該記憶手段に対して指示し、当該指示後に当該操作により再度障害が発生した場合に、当該履歴の記憶量を当該第２の記憶量から当該第１の記憶量に戻すように当該記憶手段に対して指示する指示手段とを備える情報処理装置である。
請求項２に記載の発明は、前記指示手段は、前記第１の記憶量から前記第２の記憶量に変更された後、前記操作による障害が再度発生することなく予め定められた条件が満たされた場合には、当該第２の記憶量から当該第１の記憶量に戻すように前記記憶手段に対して指示することを特徴とする請求項１に記載の情報処理装置である。
請求項３に記載の発明は、前記予め定められた条件は、前記操作が予め定められた回数実行されたにもかかわらず障害が発生しないという条件であることを特徴とする請求項２に記載の情報処理装置である。
請求項４に記載の発明は、前記予め定められた条件は、前記操作とは別の操作が予め定められた回数実行されたという条件であることを特徴とする請求項２に記載の情報処理装置である。
請求項５に記載の発明は、前記予め定められた条件は、前記操作による障害が発生してから予め定められた時間が経過したという条件であることを特徴とする請求項２に記載の情報処理装置である。
請求項６に記載の発明は、前記第２の記憶量は、前記第１の記憶量に比べて記憶される履歴の量が多いことを特徴とする請求項１に記載の情報処理装置である。
請求項７に記載の発明は、前記第２の記憶量の履歴には、前記第１の記憶量の履歴と、当該履歴とは異なる種類の履歴とが含まれることを特徴とする請求項６に記載の情報処理装置である。
請求項８に記載の発明は、前記操作による障害が発生したときに前記記憶手段が記憶する前記第２の記憶量の履歴は、当該操作による障害が発生したときに当該記憶手段が記憶する前記第１の記憶量の履歴よりも、当該障害の情報を多く含むことを特徴とする請求項６に記載の情報処理装置である。
請求項９に記載の発明は、監視対象の装置における動作に関する履歴を記憶部に記憶する記憶手段と、操作者の操作により前記監視対象の装置で障害が発生した後、当該操作により再度障害が発生した場合に、前記記憶手段が記憶する前記履歴の記憶量を、再度障害が発生する前に比べて減少させるように当該記憶手段に対して指示する指示手段とを備える情報処理装置である。
請求項１０に記載の発明は、コンピュータに、監視対象の装置における動作に関する履歴を記憶部に記憶する機能と、操作者の操作により前記監視対象の装置で障害が発生した場合に、前記記憶する機能による前記履歴の記憶量を第１の記憶量から当該第１の記憶量とは異なる第２の記憶量に変更するように制御し、当該制御の後に当該操作により再度障害が発生した場合に、当該履歴の記憶量を当該第２の記憶量から当該第１の記憶量に戻すように制御する機能とを実現させるためのプログラムである。
【発明の効果】
【０００６】
請求項１記載の発明によれば、操作者の操作により障害が発生した後に再度障害が発生した場合であっても、履歴の記憶量をそのままの状態に保持する構成と比較して、障害の調査に必要な履歴を記憶するとともに不要な履歴を記憶しない可能性を高めることができる。
請求項２記載の発明によれば、操作者の操作による障害が再度発生することなく予め定められた条件が満たされた場合であっても、履歴の記憶量をそのままの状態に保持する構成と比較して、第１の記憶量の履歴を記憶し続けることが抑制される。
請求項３記載の発明によれば、操作者の操作が予め定められた回数実行されたにもかかわらず障害が発生しない場合に、履歴の記憶量を第２の記憶量から第１の記憶量に戻すことができる。
請求項４記載の発明によれば、障害が発生した操作者の操作とは別の操作が予め定められた回数実行された場合に、履歴の記憶量を第２の記憶量から第１の記憶量に戻すことができる。
請求項５記載の発明によれば、操作者の操作による障害が発生してから予め定められた時間が経過した場合に、履歴の記憶量を第２の記憶量から第１の記憶量に戻すことができる。
請求項６記載の発明によれば、操作者の操作により障害が発生した後に再度障害が発生した場合であっても、履歴の記憶量をそのままの状態に保持する構成と比較して、より確実に、障害の調査に必要な履歴を記憶するとともに不要な履歴を記憶しない可能性を高めることができる。
請求項７記載の発明によれば、操作者の操作により発生した障害の情報として、第１の記憶量の履歴とともに異なる種類の履歴を記憶することができる。
請求項８記載の発明によれば、操作者の操作により発生した障害について、第１の記憶量の履歴よりも多くの情報を記憶することができる。
請求項９記載の発明によれば、操作者の操作により障害が発生した後に再度障害が発生した場合であっても、履歴の記憶量をそのままの状態に保持する構成と比較して、障害の調査に必要な履歴を記憶するとともに不要な履歴を記憶しない可能性を高めることができる。
請求項１０記載の発明によれば、操作者の操作により障害が発生した後に再度障害が発生した場合であっても、履歴の記憶量をそのままの状態に保持する構成と比較して、障害の調査に必要な履歴を記憶するとともに不要な履歴を記憶しない可能性を高める機能をコンピュータにより実現できる。
【図面の簡単な説明】
【０００７】
【図１】本実施の形態に係る情報処理システムの全体構成例を示した図である。
【図２】本実施の形態に係る管理端末のハードウェア構成例を示す図である。
【図３】本実施の形態に係る管理端末の機能構成例を示したブロック図である。
【図４】ログレベルの一例を説明するための図である。
【図５】ログ詳細度変更部の構成例を示したブロック図である。
【図６】ログ詳細度変更部がログ詳細度を変更する処理手順の一例を示したフローチャートである。
【図７】（ａ）〜（ｄ）は、ログ読み込み部から取得したログの構成例を示す図である。
【図８】（ａ）、（ｂ）は、エラーテーブルの一例を示す図である。
【図９】無効操作をカウントする処理手順の一例を説明するためのフローチャートである。
【発明を実施するための形態】
【０００８】
以下、添付図面を参照して、本発明の実施の形態について詳細に説明する。
【０００９】
＜情報処理システムの全体構成＞
まず、本実施の形態に係る情報処理システム１の全体構成について説明する。図１は、本実施の形態に係る情報処理システム１の全体構成例を示した図である。図示するように、この情報処理システム１では、管理端末１００、デバイス２００ａ、２００ｂがネットワーク４００に接続される。また、情報管理サーバ３００がネットワーク５００に接続される。そして、管理端末１００、デバイス２００ａ、２００ｂは、ネットワーク４００及びネットワーク５００を介して、情報管理サーバ３００に接続される。
【００１０】
なお、図１では、デバイス２００ａ、２００ｂを示したが、これらを区別する必要がない場合にはデバイス２００と称する。また、図１には２つのデバイス２００しか示していないが、デバイス２００の数は図示の２つには限定されない。
【００１１】
情報処理装置の一例としての管理端末１００は、デバイス２００を管理する装置であり、例えば、ＰＣ（Personal Computer）等が例示される。この管理端末１００には、デバイス２００を管理するためのアプリケーション（以下、マネジメントアプリと称する）がインストールされており、このマネジメントアプリによってデバイス２００が管理される。
【００１２】
より具体的には、管理端末１００は、デバイス２００の機種やデバイス２００にインストールされているアプリケーション、そのアプリケーションのバージョン（版）など、デバイス２００に関する各種情報をデバイス２００から取得して保存する。また、管理端末１００は、情報管理サーバ３００が提供する各種アプリケーションや各種アプリケーションの情報を、情報管理サーバ３００から取得して保存する。そして、管理端末１００は、デバイス２００や情報管理サーバ３００から取得した情報を画面に表示して、操作者に提示する。また、管理端末１００は、情報管理サーバ３００が提供するアプリケーションをダウンロードしたり、ダウンロードしたアプリケーションをデバイス２００にインストールしたりする。さらに、管理端末１００は、デバイス２００にインストールされたアプリケーションをバージョンアップしたり、アンインストールしたりする。このように、マネジメントアプリによって、管理端末１００とデバイス２００及び情報管理サーバ３００との間の処理が行われ、デバイス２００が管理される。
【００１３】
デバイス２００は、データ処理を行う装置であり、例えば、電子写真方式やインクジェット方式により記録媒体に画像を形成する機能を有する画像形成装置である。ただし、デバイス２００は画像形成装置に限られず、例えば、ＰＣや携帯情報端末等も例示される。
【００１４】
情報管理サーバ３００は、デバイス２００に提供するアプリケーション（商品）やアプリケーションの情報を管理する装置である。情報管理サーバ３００としては、例えば、ＰＣ（Personal Computer）やワークステーション等が例示される。情報管理サーバ３００は、管理端末１００からの要求に応じて、管理端末１００に対してアプリケーションを送信したり、提供可能なアプリケーションの情報を送信したりする。情報管理サーバ３００が送信するアプリケーションの情報としては、例えば、提供可能なアプリケーションの名称、アプリケーションのバージョン、アプリケーションのリリース日、アプリケーションが対象とするデバイス２００の機種等である。また、アプリケーションのファイルを、情報管理サーバ３００以外の他の装置に格納してもよい。その場合には、情報管理サーバ３００は、アプリケーションのインストーラのＵＲＬ（Uniform Resource Locator）の情報を管理する。
【００１５】
ネットワーク４００は、管理端末１００とデバイス２００との間の情報通信に用いられる通信手段であり、例えば、ＬＡＮ（Local Area Network）である。
【００１６】
ネットワーク５００は、管理端末１００、デバイス２００と情報管理サーバ３００との間の情報通信に用いられる通信手段であり、例えば、インターネットや公衆回線である。
【００１７】
＜管理端末のハードウェア構成＞
次に、本実施の形態に係る管理端末１００のハードウェア構成について説明する。図２は、本実施の形態に係る管理端末１００のハードウェア構成例を示す図である。
【００１８】
図示するように、管理端末１００は、演算手段であるＣＰＵ（Central Processing Unit）１０１と、記憶手段であるメインメモリ１０２及び磁気ディスク装置１０３とを備える。ＣＰＵ１０１は、ＯＳ（Operating System）やアプリケーション等の各種プログラムを実行する。メインメモリ１０２は、各種プログラムやその実行に用いるデータ等を記憶する記憶領域である。また、磁気ディスク装置１０３は、各種プログラムや、各種プログラムに対する入力データ、各種プログラムからの出力データ等を記憶する記憶領域である。そして、ＣＰＵ１０１は、磁気ディスク装置１０３等に記憶された各種プログラムをメインメモリ１０２にロードして実行することにより、管理端末１００における各機能を実現する。なお、磁気ディスク装置１０３等には、後述するように、監視対象の装置における動作に関するログ（履歴）も記憶される。
【００１９】
さらに、管理端末１００は、外部との通信を行うための通信インタフェース（通信Ｉ／Ｆ）１０４と、ビデオメモリやディスプレイ等からなる表示機構１０５と、キーボードやマウス、タッチパネル等の入力デバイス１０６とを備える。
【００２０】
＜管理端末のログ生成処理＞
次に、本実施の形態に係る管理端末１００のログ生成処理について説明する。本実施の形態に係る管理端末１００は、上述したマネジメントアプリの処理に関してログ（履歴）を生成し、生成したログを記憶領域に記憶する機能を有する。即ち、管理端末１００内で実行される内部処理や、管理端末１００とデバイス２００及び情報管理サーバ３００との間で実行される処理などのマネジメントアプリの処理に関して、ログの生成・記憶が行われる。言い換えると、管理端末１００は、監視対象の装置（例えば、管理端末１００やデバイス２００、情報管理サーバ３００）における動作に関するログを生成して、生成したログを記憶領域に記憶する。
【００２１】
詳細は後述するが、本実施の形態では、このログの生成において、生成するログの量（情報量）を示すログ詳細度が設定される。そして、管理端末１００は、設定されているログ詳細度に従って、ログの生成を行う。
【００２２】
＜管理端末の機能構成＞
次に、本実施の形態に係る管理端末１００の機能構成について説明する。図３は、本実施の形態に係る管理端末１００の機能構成例を示したブロック図である。
【００２３】
本実施の形態に係る管理端末１００は、操作受付部１１１、ログ生成部１１２、ログ記憶部１１３、ログ設定ファイル記憶部１１４、表示制御部１１５、環境情報記憶部１１６、アプリケーションデータベース１１７、ログ詳細度変更部１１８、ログ収集部１１９を備える。なお、ログ生成部１１２は、マネジメントアプリによって実現される。また、ログ詳細度変更部１１８、ログ収集部１１９は、ログを収集するためのアプリケーション（以下、ログ収集ツールと称する）によって実現される。
【００２４】
操作受付部１１１は、操作者による操作を受け付ける。ここで、操作受付部１１１は、タッチパネルやマウス等による操作者の操作によって、例えば、情報管理サーバ３００や他の装置からアプリケーションをダウンロードする操作や、ダウンロードしたアプリケーションをデバイス２００にインストールする操作を受け付ける。また、操作受付部１１１は、例えば、ログ収集ツールを起動させる操作を受け付ける。
【００２５】
ログ生成部１１２は、マネジメントアプリの処理に関してログを生成し、生成したログをログ記憶部１１３に記憶する。ここで、ログ生成部１１２は、ログ設定ファイル記憶部１１４に記憶されているログ設定ファイルを参照し、その時点で設定されているログ詳細度を確認する。そして、ログ生成部１１２は、設定されているログ詳細度に従って、ログの生成を行う。
【００２６】
ログ記憶部１１３は、ログ生成部１１２が生成したログを記憶する記憶部である。ログ記憶部１１３には、ログ生成部１１２が生成したログが順次記憶される。
【００２７】
ログ設定ファイル記憶部１１４は、ログ設定ファイルを記憶する。このログ設定ファイルには、設定中のログ詳細度が記録される。また、ログ設定ファイルのログ詳細度は、ログ詳細度変更部１１８の処理により変更される。
【００２８】
表示制御部１１５は、表示機構１０５のディスプレイに画像を表示させるためのデータを出力し、ディスプレイの表示を制御する。より具体的には、表示制御部１１５は、例えば、情報管理サーバ３００や他の装置からアプリケーションをダウンロードする操作を受け付ける画面や、ダウンロードしたアプリケーションをデバイス２００にインストールする操作を受け付ける画面など、マネジメントアプリによって生成される画面を表示する。また、表示制御部１１５は、例えば、ログの収集を開始する操作を受け付ける画面や、ログ収集の進捗度合を示す画面など、ログ収集ツールによって生成される画面を表示する。
【００２９】
環境情報記憶部１１６は、管理端末１００の環境情報を記憶する。管理端末１００の環境情報とは、管理端末１００のハードウェア及びソフトウェアの情報であり、例えば、管理端末１００のＩＰアドレスやホスト名、管理端末１００に搭載されているＯＳやメモリの情報である。より具体的には、環境情報とは、例えば、Ｗｉｎｄｏｗｓ（登録商標）のコマンドである「ｉｐｃｏｎｆｉｇ」コマンドや「ｓｙｓｔｅｍｉｎｆｏ」コマンドにより取得される情報である。
【００３０】
アプリケーションデータベース１１７は、管理端末１００にて管理される各種情報を格納するデータベースである。アプリケーションデータベース１１７には、例えば、上述したように、デバイス２００の機種等のデバイス２００に関する情報や、情報管理サーバ３００から提供されたアプリケーションの情報等が格納される。なお、アプリケーションデータベース１１７へのデータの書き込みやデータの読み出しは、マネジメントアプリ等によって行われる。
【００３１】
ログ詳細度変更部１１８は、ログ設定ファイル記憶部１１４に記憶されているログ設定ファイルのログ詳細度を変更する。ここで、ログ詳細度変更部１１８は、ログ記憶部１１３に記憶されたログを取得し、取得したログを基に、操作者の操作により障害（エラー）が発生したか否かを判定する。そして、ログ詳細度変更部１１８は、操作者の操作により障害が発生したと判定した場合に、ログ詳細度を変更する。また、ログ詳細度変更部１１８は、ログ詳細度を変更した後、操作者の操作により障害が再度発生したか否かを判定する。そして、ログ詳細度変更部１１８は、操作者の操作により障害が再度発生したと判定した場合に、ログ詳細度を変更前の状態に戻す。
【００３２】
このようにログ詳細度を変更することにより、ログ生成部１１２によるログの生成量（即ち、ログ記憶部１１３に記憶されるログの量）が変更される。よって、ログ詳細度の変更は、ログ生成部１１２に対してログの生成量の変更を指示するものとして捉えることができる。
【００３３】
ログ収集部１１９は、ログ記憶部１１３に記憶されたログを収集する。ここで、ログ収集部１１９は、収集したログを書庫化して一つのログファイルを生成する。生成されたログファイルは、例えば障害の調査に用いるために、管理端末１００から外部の装置に出力される。
【００３４】
そして、管理端末１００の各機能部は、ソフトウェアとハードウェア資源とが協働することにより実現される。具体的には、管理端末１００を図２に示したハードウェア構成にて実現した場合、例えば、磁気ディスク装置１０３等に格納されているＯＳのプログラムやマネジメントアプリ、ログ収集ツール等が、メインメモリ１０２に読み込まれてＣＰＵ１０１に実行されることにより、操作受付部１１１、ログ生成部１１２、表示制御部１１５、ログ詳細度変更部１１８、ログ収集部１１９等の各機能部が実現される。また、ログ記憶部１１３、ログ設定ファイル記憶部１１４、環境情報記憶部１１６、アプリケーションデータベース１１７は、例えば磁気ディスク装置１０３等により実現される。
【００３５】
なお、本実施の形態では、ログ詳細度変更部１１８をログ収集ツールによって実現させるのではなく、マネジメントアプリ等の他のプログラムによって実現させてもよい。
また、本実施の形態では、記憶手段の一例として、ログ生成部１１２が用いられる。記憶部の一例として、ログ記憶部１１３が用いられる。指示手段の一例として、ログ詳細度変更部１１８が用いられる。
【００３６】
＜ログ詳細度の説明＞
次に、ログ設定ファイルで設定されるログ詳細度について説明する。ログ詳細度は、予め定められた複数のログレベルに基づいて設定される。このログレベルは、管理端末１００で発生する可能性のある各事象に対して予め対応付けられるものである。言い換えると、管理端末１００で発生する可能性のある各事象は、１又は複数のログレベルに予め対応付けられており、事象が発生した場合には、その事象に対応するログレベルのログが生成される。
【００３７】
図４は、ログレベルの一例を説明するための図である。図４に示す例では、「ＦＡＴＡＬ」、「ＥＲＲＯＲ」、「ＷＡＲＮ」、「ＩＮＦＯ」、「ＤＥＢＵＧ」、「ＴＲＡＣＥ」という６つのログレベルを示している。これらのログレベルは、予め定められた基準、例えば重要度に従って、６つに分けられている。例えば、「ＦＡＴＡＬ」で生成されるログが最も重要度が高いログとされており、さらに「ＥＲＲＯＲ」、「ＷＡＲＮ」、「ＩＮＦＯ」、「ＤＥＢＵＧ」、「ＴＲＡＣＥ」の順に、重要度が高いものとされる。
【００３８】
「ＦＡＴＡＬ」のログレベルは、致命的な障害の発生時に、障害の情報をログとして生成することを意味する。「ＥＲＲＯＲ」のログレベルは、致命的な障害ではないその他の障害の発生時に、障害の情報をログとして生成することを意味する。「ＷＡＲＮ」のログレベルは、注意・警告レベルの問題発生時に、問題の情報をログとして生成することを意味する。「ＩＮＦＯ」のログレベルは、操作者の操作が行われた時に、操作の情報をログとして生成することを意味する。
【００３９】
「ＤＥＢＵＧ」のログレベルは、デバッグ用の詳細情報をログとして生成することを意味する。「ＤＥＢＵＧ」のログレベルで生成される情報は、例えば、管理端末１００とデバイス２００との間でやり取りした際にデバイス２００から取得したアプリケーションの情報や、デバイス２００にアプリケーションをインストールした際に管理端末１００とデバイス２００との間で行われた処理の情報等である。また、例えば、管理端末１００と情報管理サーバ３００との間でやり取りした際に情報管理サーバ３００から取得したアプリケーションの情報や、アプリケーションデータベース１１７との間で行われた入出力処理の情報等である。さらに、操作者の操作などにより障害が発生した場合には、その障害についての情報が「ＤＥＢＵＧ」のログとして生成される。「ＴＲＡＣＥ」のログレベルは、トレース用の詳細情報をログとして生成することを意味し、デバッグ用の詳細情報よりもさらに詳細な情報が含まれる。
【００４０】
さらに説明すると、例えば、マネジメントアプリを操作している際に発生する障害について、その障害が致命的な障害であり「ＦＡＴＡＬ」に該当するか、又は、その障害が致命的な障害ではないその他の障害であり「ＥＲＲＯＲ」に該当するかが予め定められている。また、各障害についてどのような情報をログとして生成するかが予め定められている。「ＷＡＲＮ」、「ＩＮＦＯ」、「ＤＥＢＵＧ」、「ＴＲＡＣＥ」についても同様に、それぞれのログレベルに該当する具体的な事象が定められており、各事象についてどのような情報をログとして生成するかが予め定められている。
【００４１】
そして、本実施の形態では、このようなログレベルに対して、例えば、「疎」と「密」という２つのログ詳細度が存在する。例えば、ログ詳細度が「疎」の場合には、「疎」に対応するログレベルのログが生成される。また、例えば、ログ詳細度が「密」の場合には、「密」に対応するログレベルのログが生成される。さらに説明すると、例えば、ログ詳細度が「疎」の場合には、ログレベルとして「ＩＮＦＯ」が指定される。この場合、「ＦＡＴＡＬ」、「ＥＲＲＯＲ」、「ＷＡＲＮ」、「ＩＮＦＯ」のログが生成される。また、ログ詳細度が「密」の場合には、ログレベルとして「ＤＥＢＵＧ」が指定される。この場合、「ＦＡＴＡＬ」、「ＥＲＲＯＲ」、「ＷＡＲＮ」、「ＩＮＦＯ」、「ＤＥＢＵＧ」のログが生成される。即ち、ログ詳細度を「疎」から「密」に変更することによって、ログ詳細度が「疎」のときに生成されるログに加えて、新たに「ＤＥＢＵＧ」のログも生成されるようになり、ログの生成量が増加する。
【００４２】
付言すると、ログ生成部１１２は、障害や操作者の操作などの事象が発生した場合、発生した事象がどのログレベルに該当するかを判定する。また、ログ生成部１１２は、ログ設定ファイル記憶部１１４に記憶されているログ設定ファイルを参照し、その時点で設定されているログ詳細度を確認する。例えば、ログ詳細度が「疎」の場合に、ログレベル「ＩＮＦＯ」の事象が発生すれば、ログ生成部１１２は、その事象のログを生成する。一方、ログ詳細度が「疎」の場合に、ログレベル「ＤＥＢＵＧ」の事象が発生しても、ログ生成部１１２は、その事象のログを生成しない。また、例えば、ログ詳細度が「密」の場合に、ログレベル「ＩＮＦＯ」や「ＤＥＢＵＧ」の事象が発生すれば、ログ生成部１１２は、それらの事象のログを生成する。
【００４３】
なお、複数のログレベルに対応付けられた事象が発生した場合には、各ログレベルに対応するログがそれぞれ生成される。例えば、操作者の操作により発生する障害が「ＦＡＴＡＬ」で、且つ「ＤＥＢＵＧ」に対応付けられている場合について説明する。ログ詳細度が「疎」の場合にこの障害が発生すると、「ＦＡＴＡＬ」のログが生成される。この例では、例えば、障害の名称や障害の種類などの情報が「ＦＡＴＡＬ」のログとして生成される。一方、ログ詳細度が「密」の場合にこの障害が発生すると、「ＦＡＴＡＬ」のログが生成されるとともに、「ＤＥＢＵＧ」のログも生成される。この例では、例えば、障害が発生しているアプリケーションやモジュール、障害発生時に実行されていたプロセスなどの情報が「ＤＥＢＵＧ」のログとして生成される。なお、この例では、操作者の操作により障害が発生するため、操作者の操作についての情報を示す「ＩＮＦＯ」のログも生成される。
【００４４】
そして、本実施の形態では、例えば、通常時には、最小限の範囲でログを生成してログ記憶部１１３の使用量を抑制するように、ログ詳細度は「疎」に設定される。一方、操作者の操作により障害が発生した場合には、ログ詳細度変更部１１８がログ詳細度を「疎」から「密」に変更する。その後、障害が再現されると、ログ詳細度「密」の状態で、障害発生時のログが生成される。このログをログ収集ツールで収集することで、ログ詳細度「密」の状態で生成された障害発生時のログが収集されるため、ログ詳細度が「疎」の状態で生成されたログを収集する場合よりも、障害の調査のために有益な情報が多く取得されることになる。
【００４５】
さらに、障害が再現された場合には、ログ詳細度変更部１１８は、ログ詳細度を「密」から「疎」に変更する。ログ詳細度を「密」から「疎」に変更することにより、障害が再現されたにもかかわらずログ詳細度を「密」のままにする場合よりも、障害の調査に不要なログが生成されることが抑制される。
なお、本実施の形態では、第１の記憶量の一例として、「疎」の状態の記憶量が用いられる。また、第２の記憶量の一例として、「密」の状態の記憶量が用いられる。
【００４６】
＜ログ詳細度変更部の構成＞
次に、ログ詳細度変更部１１８の構成について、詳細に説明する。図５は、ログ詳細度変更部１１８の構成例を示したブロック図である。ログ詳細度変更部１１８は、ログ読み込み部１２１、エラーテーブル更新部１２２、ログ設定ファイル変更部１２３を有する。
【００４７】
ログ読み込み部１２１は、ログ記憶部１１３に記憶されたログを読み込む。読み込んだログは、エラーテーブル更新部１２２に出力される。
【００４８】
エラーテーブル更新部１２２は、ログ読み込み部１２１から取得したログにおいて、操作者の操作が記録されているか否かを判定する。ここで、操作者の操作が記録されている場合、さらに、エラーテーブル更新部１２２は、取得したログに基づいて、操作者の操作により障害（エラー）が発生しているか否かを判定する。
ここで、操作者の操作により障害が発生したと判定された場合に、ログ詳細度が「疎」であれば、エラーテーブル更新部１２２は、ログ設定ファイル変更部１２３に対して、ログ詳細度を「疎」から「密」に変更するように通知する。また、エラーテーブル更新部１２２は、障害が発生した操作者の操作をエラーテーブルに登録する。このエラーテーブルは、障害が発生した操作者の操作を管理するためのテーブルであり、エラーテーブルに登録された操作は、障害が再度発生するまでエラーテーブルで管理される。言い換えると、エラーテーブルに登録された操作は、障害を再現することが期待される操作として捉えることができる。
【００４９】
付言すると、エラーテーブルに操作者の操作が登録されている間、ログ詳細度は「密」に設定される。そのため、エラーテーブルに登録された操作による障害が再現した場合、ログ詳細度「密」の状態で、その操作における障害発生時のログが生成される。即ち、障害について、ログ詳細度「疎」の状態よりも多くの情報が生成される。この場合、エラーテーブル更新部１２２は、その操作をエラーテーブルから削除し、管理対象から除外する。また、エラーテーブルに登録された操作による障害が再現することなく予め定められた条件が満たされた場合、例えば、その操作が予め定められた回数行われたにもかかわらず障害が発生しない場合も、エラーテーブル更新部１２２は、その操作をエラーテーブルから削除する。
【００５０】
このようにして、エラーテーブル更新部１２２は、障害が発生した操作者の操作をエラーテーブルで管理する。そして、エラーテーブルに操作者の操作が登録されている場合には、ログ詳細度が「密」に設定される。また、エラーテーブルに登録されている操作者の操作がなくなれば（即ち、管理対象の操作がなくなれば）、エラーテーブル更新部１２２は、ログ設定ファイル変更部１２３に対して、ログ詳細度を「密」から「疎」に変更するように通知する。
【００５１】
ログ設定ファイル変更部１２３は、エラーテーブル更新部１２２からの通知を基に、ログ設定ファイルのログ詳細度を「疎」から「密」に変更したり、「密」から「疎」に変更したりする。
【００５２】
＜ログ詳細度を変更する処理手順の説明＞
次に、ログ詳細度変更部１１８がログ詳細度を変更する処理の一連の流れについて説明する。図６は、ログ詳細度変更部１１８がログ詳細度を変更する処理手順の一例を示したフローチャートである。図６に示す処理は、例えば、定期的に（例えば１分毎に）実行されたり、ログ記憶部１１３に新たにログが記憶されたタイミングで実行されたりする。
【００５３】
まず、ログ読み込み部１２１は、ログ記憶部１１３に記憶されたログを読み込む（ステップ１０１）。読み込んだログは、エラーテーブル更新部１２２に出力される。次に、エラーテーブル更新部１２２は、ログ読み込み部１２１から取得したログにおいて、操作者の操作が記録されている否かを判定する（ステップ１０２）。ステップ１０２で否定の判断（ＮＯ）がされた場合、本処理フローは終了する。一方、ステップ１０２で肯定の判断（ＹＥＳ）がされた場合、即ち、ログに操作者の操作が記録されている場合、ステップ１０３へ移行する。なお、以下の説明では、ログに記録されている操作者の操作を「ログ記録操作」と称する場合がある。
【００５４】
ステップ１０３において、エラーテーブル更新部１２２は、取得したログを基に、ログ記録操作において障害が発生しているか否かを判定する（ステップ１０３）。ステップ１０３で肯定の判断（ＹＥＳ）がされた場合、ステップ１０４に移行する。一方、ステップ１０３で否定の判断（ＮＯ）がされた場合、ステップ１１０に移行する。
【００５５】
ステップ１０３で肯定の判断（ＹＥＳ）がされた場合、ステップ１０４において、エラーテーブル更新部１２２は、ログ設定ファイルのログ詳細度が「疎」であるか否かを判定する（ステップ１０４）。
【００５６】
ステップ１０４で肯定の判断（ＹＥＳ）がされた場合、エラーテーブル更新部１２２は、ログ設定ファイル変更部１２３に対して、ログ設定ファイルのログ詳細度を「疎」から「密」に変更するように通知する。この通知により、ログ設定ファイル変更部は、ログ詳細度を「疎」から「密」に変更する（ステップ１０５）。また、エラーテーブル更新部１２２は、ログ記録操作（即ち、ステップ１０３で障害が発生していると判定された操作者の操作）について、エラーテーブルに登録するとともに、１以上の整数であるエラーカウントをセットする（ステップ１０６）。そして、本処理フローは終了する。
【００５７】
一方、ステップ１０４で否定の判断（ＮＯ）がされた場合、ログ詳細度は「密」の設定がされている。この場合、エラーテーブル更新部１２２は、ログ記録操作（即ち、ステップ１０３で障害が発生していると判定された操作者の操作）がエラーテーブルに登録されているか否かを判定する（ステップ１０７）。
【００５８】
ステップ１０７で肯定の判断（ＹＥＳ）がされた場合には、ログ記録操作により障害が再現し、ログ詳細度が「密」の状態で、障害発生時のログが生成されたことになる。そこで、エラーテーブル更新部１２２は、このログ記録操作をエラーテーブルから削除する（ステップ１０８）。次に、エラーテーブル更新部１２２は、ログ設定ファイル変更部１２３に対して、ログ設定ファイルのログ詳細度を「密」から「疎」に変更するように通知する。この通知により、ログ設定ファイル変更部は、ログ詳細度を「密」から「疎」に変更する（ステップ１０９）。そして、本処理フローは終了する。
【００５９】
一方、ステップ１０７で否定の判断（ＮＯ）がされた場合、本処理フローは終了する。付言すると、ステップ１０７で否定の判断（ＮＯ）がされた場合とは、ログ詳細度が「密」の状態で、エラーテーブルに登録されていない操作者の操作により障害が発生した場合である。この場合には、ログ詳細度が「密」の状態で、障害発生時のログが生成されるため、操作者が同じ操作を行って障害を再現させる必要がない。よって、この場合の操作者の操作は、エラーテーブルに登録されない。
【００６０】
また、ステップ１０３で否定の判断（ＮＯ）がされた場合、ステップ１１０において、エラーテーブル更新部１２２は、ログ設定ファイルのログ詳細度が「疎」であるか否かを判定する（ステップ１１０）。ステップ１１０で肯定の判断（ＹＥＳ）がされた場合、本処理フローは終了する。即ち、ログ詳細度は「疎」のままとされる。一方、ステップ１１０で否定の判断（ＮＯ）がされた場合、エラーテーブル更新部１２２は、エラーテーブルにログ記録操作（即ち、ステップ１０３で障害が発生していないと判定された操作者の操作）がエラーテーブルに登録されているか否かを判定する（ステップ１１１）。
【００６１】
ステップ１１１で否定の判断（ＮＯ）がされた場合、本処理フローは終了する。一方、ステップ１１１で肯定の判断（ＹＥＳ）がされた場合、エラーテーブル更新部１２２は、エラーテーブルにおいて、ログ記録操作のエラーカウントを減算する（ステップ１１２）。より具体的には、エラーテーブル更新部１２２は、ログ記録操作のエラーカウントを「１」減らす。
【００６２】
次に、エラーテーブル更新部１２２は、ログ記録操作のエラーカウントが「０」であるか否かを判定する（ステップ１１３）。ステップ１１３で肯定の判断（ＹＥＳ）がされた場合、ステップ１０８に移行する。この場合には、ログ記録操作が予め定められた回数行われたにもかかわらず、障害が発生しなかった（即ち、ログ記録操作がエラーカウントの回数行われたにもかかわらず、障害が再現しなかった）として、エラーテーブルから削除される。そして、ステップ１０９でログ詳細度が「密」から「疎」に変更される。一方、ステップ１１３で否定の判断（ＮＯ）がされた場合、本処理フローは終了する。この場合には、ログ記録操作はまだ予め定められた回数行われていないため、引き続き、管理対象の操作として扱われる。
【００６３】
なお、ステップ１０２において、ログ読み込み部１２１から取得したログに、操作者の操作が複数記録されている場合には、ログに記録されている操作毎に、図６に示す処理が行われる。
【００６４】
＜ログ詳細度を変更する処理の例＞
次に、ログ詳細度変更部１１８がログ詳細度を変更する処理について、具体例を挙げて説明する。以下の例では、初期状態として、ログ設定ファイルのログ詳細度は「疎」の設定がされており、またエラーテーブルには操作者の操作が登録されていないものとして説明する。なお、以下に示すステップは、図６の各ステップに対応する。
【００６５】
まず、ログ読み込み部１２１は、ログ記憶部１１３に記憶されたログを読み込み（ステップ１０１）、読み込んだログはエラーテーブル更新部１２２に出力される。次に、エラーテーブル更新部は、取得したログにおいて、操作者の操作が記録されているか否かを判定する（ステップ１０２）。
【００６６】
図７（ａ）〜（ｄ）は、ログ読み込み部１２１から取得したログの構成例を示す図である。「Ｄａｔｅ  Ｔｉｍｅ」は、ログの生成時刻である。「ログレベル」は、ログに対応付けられたログレベルである。「情報」は、ログに含まれる情報である。
【００６７】
ここで、図７（ａ）に示すログがログ読み込み部１２１から取得されたものとする。図７（ａ）に示す例では、ログレベル「ＩＮＦＯ」のログが生成されており、ログの情報として「操作ＩＤ」、「結果コード」が含まれる。「操作ＩＤ」は操作者の操作を識別するための識別子であり、「結果コード」は操作結果が正常に終了したか否かを示すものである。この例では、「操作ＩＤ」が「１」、「結果コード」が「ＥＲＲＯＲ」であり、「操作ＩＤ」が「１」を示す操作者の操作において障害が発生したことを示している。
【００６８】
この場合、エラーテーブル更新部１２２は、「操作ＩＤ」が「１」を示す操作者の操作が記録されていると判定する（ステップ１０２でＹＥＳ）。また、エラーテーブル更新部１２２は、操作者の操作において障害が発生していると判定する（ステップ１０３でＹＥＳ）。ここで、ログ詳細度は「疎」であるため（ステップ１０４でＹＥＳ）、ログ設定ファイル変更部１２３は、ログ詳細度を「疎」から「密」に変更する（ステップ１０５）。
【００６９】
また、エラーテーブル更新部１２２は、操作ＩＤ「１」の操作について、エラーテーブルに登録するとともに、エラーカウントをセットする（ステップ１０６）。図８（ａ）、（ｂ）は、エラーテーブルの一例を示す図である。ここでは、図８（ａ）に示すように、操作ＩＤ「１」の操作について、例えば、エラーカウント「１０」がセットされる。
【００７０】
このようにして、ログ設定ファイルのログ詳細度が「疎」から「密」に変更されることにより、以降の処理では、ログ詳細度「密」の状態でログが生成されることになる。より具体的には、ログ生成部１１２は、「ＦＡＴＡＬ」、「ＥＲＲＯＲ」、「ＷＡＲＮ」、「ＩＮＦＯ」、「ＤＥＢＵＧ」のログレベルのログを生成する。
【００７１】
引き続き、ログ読み込み部１２１は、ログを読み込んで（ステップ１０１）、エラーテーブル更新部１２２に出力する。ここで、図７（ｂ）に示すように、ログ読み込み部１２１が読み込んだログに、「操作ＩＤ」が「２」で、「結果コード」が「ＥＲＲＯＲ」のログが含まれる場合について説明する。
【００７２】
この場合、操作ＩＤ「１」の操作において障害が発生した場合と同様に、ステップ１０２で肯定の判断（ＹＥＳ）、ステップ１０３で肯定の判断（ＹＥＳ）がされる。また、ログ詳細度は「密」に変更されたため、ステップ１０４では否定の判断（ＮＯ）がされる。付言すると、ログ詳細度が「密」のため、図７（ｂ）に示すように、操作ＩＤ「２」の操作に関連して、ログレベル「ＤＥＢＵＧ」のログが生成される。この「ＤＥＢＵＧ」のログには、エラー詳細情報として、操作ＩＤ「２」の操作により発生した障害の情報が含まれる。即ち、ログ詳細度が「密」の状態で障害発生時のログが生成されるため、この障害を再現する必要はない。
【００７３】
引き続き、ログ読み込み部１２１は、ログを読み込んで（ステップ１０１）、エラーテーブル更新部１２２に出力する。ここで、図７（ｃ）に示すように、ログ読み込み部１２１が読み込んだログに、「操作ＩＤ」が「１」で、「結果コード」が「ＦＩＮＩＳＨ」のログが含まれる場合について説明する。「ＦＩＮＩＳＨ」は、操作者の操作が正常に終了したことを示すものである。
【００７４】
この場合、エラーテーブル更新部は、「操作ＩＤ」が「１」を示す操作者の操作が記録されていると判定する（ステップ１０２でＹＥＳ）。また、「結果コード」が「ＦＩＮＩＳＨ」であるため、エラーテーブル更新部は、操作者の操作において障害は発生していないと判定する（ステップ１０３でＮＯ）。
【００７５】
ここで、ログ詳細度は「密」であり（ステップ１１０でＮＯ）、図８（ａ）に示すように、操作ＩＤ「１」の操作はエラーテーブルに登録されている（ステップ１１１でＹＥＳ）。そのため、エラーテーブル更新部１２２は、エラーテーブルにおいて、操作ＩＤ「１」のエラーカウントを減算する（ステップ１１２）。ここでは、図８（ｂ）に示すように、操作ＩＤ「１」のエラーカウントは、「１０」から「１」減算されて「９」になる。エラーカウントは「０」ではないため（ステップ１１３でＮＯ）、操作ＩＤ「１」の操作はエラーテーブルに登録されたままとなる。
【００７６】
引き続き、ログ読み込み部１２１は、ログを読み込んで（ステップ１０１）、エラーテーブル更新部１２２に出力する。ここで、図７（ｄ）に示すように、ログ読み込み部１２１が読み込んだログに、「操作ＩＤ」が「１」で、「結果コード」が「ＥＲＲＯＲ」のログが含まれる場合について説明する。
【００７７】
この場合、エラーテーブル更新部は、「操作ＩＤ」が「１」を示す操作者の操作が記録されていると判定する（ステップ１０２でＹＥＳ）。また、「結果コード」が「ＥＲＲＯＲ」であるため、エラーテーブル更新部は、操作者の操作において障害が発生したと判定する（ステップ１０３でＹＥＳ）。また、ログ詳細度は「密」であり、ステップ１０４では否定の判断（ＮＯ）がされる。
【００７８】
次に、操作ＩＤ「１」の操作はエラーテーブルに登録されているため、ステップ１０７で肯定の判断（ＹＥＳ）がされる。即ち、操作ＩＤ「１」の操作により障害が再現し、ログ詳細度が「密」の状態で、障害発生時のログが生成されたことになる。付言すると、ログ詳細度が「密」のため、図７（ｄ）に示すように、操作ＩＤ「１」の操作に関連して、ログレベル「ＤＥＢＵＧ」のログが生成される。この「ＤＥＢＵＧ」のログには、エラー詳細情報として、操作ＩＤ「１」の操作により発生した障害の情報が含まれる。
【００７９】
次に、エラーテーブル更新部１２２は、操作ＩＤ「１」の操作をエラーテーブルから削除する（ステップ１０８）。そして、ログ設定ファイル変更部は、ログ詳細度を「密」から「疎」に変更する（ステップ１０９）。
このようにして、操作ＩＤ「１」の操作について再度障害が発生した場合には、ログ詳細度が「密」の状態で、障害発生時のログが生成される。そして、ログ詳細度は「密」から「疎」に変更される。
【００８０】
なお、上述した例では、操作ＩＤ「１」の操作について再度障害が発生する場合について説明したが、例えば、操作ＩＤ「１」の操作がエラーテーブルに登録された後に１０回行われたにもかかわらず、その全てが正常に終了し、障害が発生しなかった場合には、ステップ１１３で肯定の判断（ＹＥＳ）がされる。この場合、操作ＩＤ「１」の操作はエラーテーブルから削除され（ステップ１０８）、ログ詳細度が「密」から「疎」に変更される（ステップ１０９）。
【００８１】
また、上述した例では、操作ＩＤ「１」の操作について、エラーカウントを「１０」としたが、操作毎にエラーカウントの値を変えてもよい。例えば、通常時に該当の操作が行われる頻度や、操作の重要度、操作の種類等に基づいて、エラーカウントの値を設定してもよい。より具体的には、例えば、通常時に実行される頻度が高いほど、エラーカウントの値が大きくなるように設定される。
【００８２】
さらに、上述した例では、操作を識別したり障害の有無を判断したりするために、ログに「操作ＩＤ」及び「結果コード」が含まれることとしたが、「操作ＩＤ」や「結果コード」が含まれない場合には、操作を識別するための文字列や、障害の有無を示す文字列を予め定義しておけばよい。
【００８３】
＜障害が発生した操作がその後行われない場合の処理＞
次に、障害が発生した操作者の操作がその後行われない場合の処理について説明する。上述したように、操作者の操作において再度障害が発生した場合や、操作者の操作が予め定められた回数行われたにもかかわらず障害が発生しなかった場合には、ログ詳細度が「密」から「疎」に変更される。ただし、その操作自体が行われない場合には、ログ詳細度が「密」の状態のまま、デバッグ用の詳細情報がログとして生成され続けてしまう。
【００８４】
そこで、エラーテーブル更新部１２２は、エラーテーブルに登録されていない操作者の操作の数をカウントし、カウントした操作の数が予め定められた閾値を超えた場合に、ログ詳細度を「密」から「疎」に変更してもよい。以下では、エラーテーブルに登録されていない操作者の操作を「無効操作」と称する場合がある。付言すると、無効操作は、障害を再現することが期待されていない操作であり、言い換えると、障害を再現することが期待される操作とは関係のない操作と捉えることができる。本実施の形態では、別の操作の一例として、無効操作が用いられる。また、予め定められた条件の一例として、無効操作が予め定められた閾値の回数行われたという条件が用いられる。
【００８５】
図９は、無効操作をカウントする処理手順の一例を説明するためのフローチャートである。図９に示す処理手順は、図６に示す処理手順に対して、ステップ２１４〜２１８の処理を追加したものである。即ち、ステップ２０１〜２１３の処理はそれぞれ、ステップ１０１〜１１３の処理と同じであるため、ここでは説明を省略する。
【００８６】
ステップ２１４の処理は、ステップ２０５の処理の後に追加される。ステップ２０５において、ログ設定ファイル変更部１２３がログ詳細度を「疎」から「密」に変更した後、エラーテーブル更新部１２２は、無効操作数を「０」にリセットする（ステップ２１４）。
【００８７】
また、ステップ２１５〜２１８の処理は、ステップ２１１で否定の判断（Ｎｏ）がされた場合の処理として追加される。
ここで、ログ記録操作において障害が発生していないと判定され（ステップ２０３でＮｏ）、ログ詳細度が「密」の場合（ステップ２１０でＮｏ）、エラーテーブル更新部１２２は、ログ記録操作（即ち、ステップ２０３で障害が発生していないと判定された操作者の操作）がエラーテーブルに登録されているか否かを判定する（ステップ２１１）。ステップ２１１で肯定の判断（ＹＥＳ）がされた場合には、ステップ２１２の処理が行われる。一方、ステップ２１１で否定の判断（ＮＯ）がされた場合に、ステップ２１５の処理が行われる。
【００８８】
ステップ２１５において、エラーテーブル更新部１２２は、無効操作の数を加算する（ステップ２１５）。より具体的には、エラーテーブル更新部１２２は、無効操作数を「１」増やす。次に、エラーテーブル更新部１２２は、無効操作数が予め定められた閾値を超えたか否かを判定する（ステップ２１６）。ステップ２１６で否定の判断（ＮＯ）がされた場合、本処理フローは終了する。一方、ステップ２１６で肯定の判断（ＹＥＳ）がされた場合、エラーテーブル更新部１２２は、エラーテーブルに登録されている操作を削除する（ステップ２１７）。また、エラーテーブル更新部１２２は、ログ設定ファイル変更部１２３に対してログ詳細度を「密」から「疎」に変更するように通知する。この通知により、ログ設定ファイル変更部１２３は、ログ詳細度を「密」から「疎」に変更する（ステップ２１８）。そして、本処理フローは終了する。
【００８９】
このようにして、無効操作数が予め定められた閾値を超えた場合、ログ詳細度が「密」から「疎」に変更される。そのため、例えば、障害が発生した操作がその後行われなかった場合であっても、デバッグ用の詳細情報がログとして生成され続けることが抑制される。
【００９０】
また、図９に示す手順では、障害が発生していないと判定された操作であって、エラーテーブルに登録されていない操作を無効操作としたが、障害が発生したと判定された操作であって、エラーテーブルに登録されていない操作を、無効操作としてカウントしてもよい。
【００９１】
さらに、上述した例では、無効操作の数が予め定められた閾値を超えた場合に、ログ詳細度を「密」から「疎」に変更したが、ログ詳細度を「密」から「疎」に変更する条件はこのようなものに限られない。例えば、操作者の操作による障害が発生してから予め定められた時間が経過しても障害が再現しない場合に、ログ詳細度を「密」から「疎」に変更してもよい。この場合には、操作者の操作による障害が発生してから予め定められた時間が経過したという条件が、予め定められた条件の一例として用いられる。付言すると、操作者の操作による障害が発生してから予め定められた時間が経過したという条件は、ログ詳細度を「疎」から「密」に変更してから予め定められた時間が経過したという条件と捉えることもできる。また、例えば、操作者の操作による障害が再現することなく、管理端末１００の電源を停止する等の特定の操作が行われた場合に、ログ詳細度を「密」から「疎」に変更してもよい。
【００９２】
以上説明したように、本実施の形態において、ログ詳細度変更部１１８は、操作者の操作において障害が発生した場合、ログ詳細度を「疎」から「密」に変更する。また、操作者の操作において障害が再度発生した場合に、ログ詳細度を「密」から「疎」に変更する。よって、操作者の操作により障害が再現した場合に、ログ詳細度が「密」の状態で障害発生時のログが生成されることになり、障害の調査のために有益な情報が取得される。また、障害が再現した場合、ログ詳細度を「密」から「疎」に変更するため、例えば、操作者の操作により障害が発生した後に再度障害が発生した場合であっても、ログ詳細度を「密」の状態に保持する構成と比較して、障害の調査に不要なログを記憶することが抑制される。
【００９３】
また、ログ詳細度変更部１１８は、操作者の操作により障害が発生した場合に、障害の発生を条件として、ログ詳細度を「疎」から「密」に変更してもよいが、ログ詳細度を「疎」から「密」に変更する条件はこのような条件に限られない。
【００９４】
例えば、ログ詳細度変更部１１８は、操作者の操作において障害が発生した場合に、障害を再現することを促すメッセージに対して操作者が応答したことを条件として、ログ詳細度を「疎」から「密」に変更してもよい。また、例えば、ログ詳細度変更部１１８は、操作者の操作において障害が発生した場合に、ログ収集ツールの起動を促すメッセージに対して操作者が応答したことを条件として、ログ詳細度を「疎」から「密」に変更してもよい。付言すると、障害を再現することを促すメッセージに対して操作者が応答する操作や、ログ収集ツールの起動を促すメッセージに対して操作者が応答する操作は、障害の再現のための操作（障害の再現を開始するための操作）として捉えることができる。言い換えると、ログ詳細度変更部１１８は、操作者の操作において障害が発生した場合に、障害の再現のための操作（障害の再現を開始するための操作）が操作者によって行われたことを条件として、ログ詳細度を「疎」から「密」に変更してもよい。
【００９５】
また、例えば、ログ詳細度変更部１１８は、操作者の操作において障害が発生した場合に、ログ収集ツールが起動されたことを条件として、ログ詳細度を「疎」から「密」に変更してもよい。さらに、例えば、ログ詳細度変更部１１８は、操作者の操作において障害が発生した場合に、操作者によって手動でログ詳細度を変更する操作が行われたことを条件として、ログ詳細度を「疎」から「密」に変更してもよい。
【００９６】
また、上述した例では、ログ詳細度変更部１１８は、操作者の操作において障害が発生した場合に、ログ詳細度を「疎」から「密」に変更したが、ログ詳細度を「密」から「疎」に変更してもよい。例えば、ログ収集ツールで収集するログを少なくしたい場合には、操作者の操作において障害が発生した場合に、ログ詳細度を「密」から「疎」に変更することが考えられる。同様に、上述した例では、ログ詳細度変更部１１８は、操作者の操作において障害が再度発生した場合に、ログ詳細度を「密」から「疎」に変更したが、ログ詳細度を「疎」から「密」に変更してもよい。例えば、通常時に生成されるログを多くしたい場合には、操作者の操作において障害が再度発生した場合に、ログ詳細度を「疎」から「密」に変更することが考えられる。
【００９７】
また、上述した例では、ログ詳細度を「疎」と「密」の２段階で表したが、ログ詳細度を３段階以上で表してもよい。例えば、ログの生成量（記憶量）が多い順に、「多」、「中」、「少」という３段階のログ詳細度が設けられる場合について説明する。
ログ詳細度変更部１１８は、例えば、操作者の操作において障害が発生した場合に、ログ詳細度を変更する。ここで、ログ詳細度変更部１１８は、例えば、ログ記憶部１１３に記憶されるログの量を、障害が発生する前よりも増加させるように、ログ詳細度を「少」から「多」に変更する。また、ログ詳細度変更部１１８は、例えば、操作者の操作において障害が再現した場合に、ログ詳細度を変更する。ここで、ログ詳細度変更部１１８は、例えば、ログ記憶部１１３に記憶されるログの量を、障害が再現する前よりも減少させるように、ログ詳細度を「多」から「少」に戻したり、ログ詳細度を「多」から「中」に変更したりする。
【００９８】
さらに、上述した例では、ログ詳細度を「疎」から「密」に変更すると、「ＤＥＢＵＧ」のログが新たに生成されることによって、ログの生成量が増加したが、ログの生成量を増加させる態様としてはこのような構成に限られない。本実施の形態では、例えば、ログ詳細度を「疎」から「密」に変更した場合に、「ＤＥＢＵＧ」のログが新たに生成されることに代えて、又は「ＤＥＢＵＧ」のログが新たに生成されることに加えて、「ＦＡＴＡＬ」や「ＥＲＲＯＲ」などの「ＤＥＢＵＧ」以外のログレベルのログの情報を詳細にする（ログに含まれる情報量を増やす）ことで、ログの生成量を増加させてもよい。
【００９９】
また、上述した例では、ログの生成量をログ詳細度及びログレベルに基づいて決定することとしたが、ログの生成量を決定する手法としては、このような構成に限られない。本実施の形態では、操作者の操作において障害が発生した場合や障害が再現した場合にログの生成量を変更する手法であればよく、他の手法を用いてもよい。
【０１００】
さらに、上述した例では、デバイス２００を管理するマネジメントアプリでログを生成することとしたが、このような構成に限られるものではない。本実施の形態では、アプリケーション等のプログラムによってログを生成し、操作者の操作において障害が発生した場合や障害が再現した場合にログの生成量を変更する構成であればよく、他の構成を用いてもよい。また、上述した例では、操作者がマネジメントアプリを操作している際に障害が発生する場合について説明したが、監視対象の装置に対する操作の障害であって、アプリケーション等のプログラムによって障害発生時のログが生成されるものであれば、マネジメントアプリを操作している際の障害に限られない。
【０１０１】
なお、本実施の形態において、ログの生成量（記憶量）を変更する態様には、ログを生成しない状態からログを生成する状態に変更する態様や、ログを生成する状態からログを生成しない状態に変更する態様も含むものとする。
【０１０２】
また、本発明の実施の形態を実現するプログラムは、通信手段により提供することはもちろん、ＣＤ−ＲＯＭ等の記録媒体に格納して提供することも可能である。
【０１０３】
なお、上記では種々の実施形態および変形例を説明したが、これらの実施形態や変形例どうしを組み合わせて構成してももちろんよい。
また、本開示は上記の実施形態に何ら限定されるものではなく、本開示の要旨を逸脱しない範囲で種々の形態で実施することができる。
【符号の説明】
【０１０４】
１００…管理端末、１１１…操作受付部、１１２…ログ生成部、１１３…ログ記憶部、１１４…ログ設定ファイル記憶部、１１５…表示制御部、１１６…環境情報記憶部、１１７…アプリケーションデータベース、１１８…ログ詳細度変更部、１１９…ログ収集部、１２１…ログ読み込み部、１２２…エラーテーブル更新部、１２３…ログ設定ファイル変更部、２００…デバイス、３００…情報管理サーバ
【図１】
2019079354.tif 000003
【図２】
2019079354.tif 000004
【図３】
2019079354.tif 000005
【図４】
2019079354.tif 000006
【図５】
2019079354.tif 000007
【図６】
2019079354.tif 000008
【図７】
2019079354.tif 000009
【図８】
2019079354.tif 000010
【図９】
2019079354.tif 000011