JP2018014039A - 情報処理装置、情報処理システム、情報処理方法およびプログラム - Google Patents

Abstract

【課題】ログの収集量を抑えながらも、問題解決のために十分な情報を得ることが可能な情報処理装置、情報処理システム、情報処理方法およびプログラムを提供する。【解決手段】本発明の情報処理装置は、取得部と記憶部１３３と収集部１３４とを備える。取得部は、自装置または他の１以上の情報処理装置において障害が発生した場合に、自装置または他の１以上の情報処理装置を識別する装置識別情報と、発生した障害を識別する障害識別子と、該障害に関するログを識別するログ識別情報とが少なくとも紐付けられた障害管理情報を取得する。記憶部は、取得部により取得された障害管理情報を記憶する。収集部は、指定された障害を識別する障害識別子に紐付く全てのログ識別情報ごとに、該ログ識別情報で識別されるログを収集する。【選択図】図１１

Description

本発明は、情報処理装置、情報処理システム、情報処理方法およびプログラムに関する。

例えばプリンタ装置やファックス通信装置などの情報処理装置は、ＰＣ（Personal Computer）や通信回線といった外部からの動作要求に応じて動作を行うことが可能な動作状態と、一部の機能を休止させて動作要求を待つ待ち受け状態との間の遷移を行うなど、複雑なプログラムによって動作している。このため、万一情報処理装置に障害が発生した場合、その原因の所在を迅速に究明するため、情報処理装置内部に、情報処理装置の動作情報、ステータス情報やエラー情報をログとして保存・収集する技術が知られている。

ここで、複数台の情報処理装置（例えばＭＦＰ）を対象としたログ保存・収集技術では、ログのデータ量やＭＦＰの台数が増えたときにログの収集量が増大してしまい、その収集に長時間を要するという問題がある。このような問題を解決するために、例えば特許文献１には、端末ごとにログ記録頻度を動的に変更し、全体的にログ収集量を低減する構成が開示されている。

しかし、特許文献１に開示された技術では、ログの収集量を減らしたいあまりにログ記録量も削減してしまったことで、「ログを記録しない」設定の端末で問題が発生した場合に問題解決のためのログを記録できず、問題解決することができなくなってしまうという問題がある。

本発明は、上記に鑑みてなされたものであって、ログの収集量を抑えながらも、問題解決のために十分な情報を得ることが可能な情報処理装置、情報処理システム、情報処理方法およびプログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明は、自装置または他の１以上の情報処理装置において障害が発生した場合に、自装置または前記他の１以上の情報処理装置を識別する装置識別情報と、発生した障害を識別する障害識別子と、該障害に関するログを識別するログ識別情報とが少なくとも紐付けられた障害管理情報を取得する取得部と、前記取得部により取得された前記障害管理情報を記憶する記憶部と、指定された障害を識別する前記障害識別子に紐付く全ての前記ログ識別情報ごとに、該ログ識別情報で識別される前記ログを収集する収集部と、を備える情報処理装置である。

本発明によれば、ログの収集量を抑えながらも、問題解決のために十分な情報を得ることが可能な情報処理装置、情報処理システム、情報処理方法およびプログラムを提供することができる。

図１は、情報処理システムの構成の一例を示す図である。 図２は、ＭＦＰのハードウェア構成の一例を示す図である。 図３は、ＭＦＰのプログラム構成の一例を示す図である。 図４は、ＭａｓｔｅｒおよびＳｌａｖｅの各々の構成を説明するための図である。 図５は、ＭＦＰログ管理情報の一例を示す図である。 図６は、個体情報の一例を示す図である。 図７は、障害情報の一例を示す図である。 図８は、Ｓｌａｖｅが有する通知プログラムのイベントについて説明するための図である。 図９は、リクエストの一覧を示す図である。 図１０は、管理データ表示プログラムの機能を説明するための図である。 図１１は、ＭａｓｔｅｒおよびＳｌａｖｅの各々が有する機能の一例を示す図である。 図１２は、情報処理システムの動作例を示すフローチャートである。 図１３は、情報処理システムの動作例を示すフローチャートである。 図１４は、Ｍａｓｔｅｒの動作例を示すフローチャートである。

以下、添付図面を参照しながら、本発明に係る情報処理装置、情報処理システム、情報処理方法およびプログラムの実施形態を詳細に説明する。以下では、本発明に係る情報処理装置の一例として、画像形成装置の一態様である複合機（ＭＦＰ：Multifunction Peripheral）を例に挙げて説明するが、これに限られるものではない。なお、複合機とは、コピー機能、スキャナ機能、プリント機能、ファクス機能などの複数の異なる機能を有する装置である。

図１は、本実施形態の情報処理システム１００の構成の一例を示す図である。図１に示すように、情報処理システム１００は複数のＭＦＰ１を備え、これらは例えばインターネットなどのネットワーク２を介して相互に接続される。説明の便宜上、図１の例では、２台のＭＦＰ１のみが例示されているが、情報処理システム１００に含まれるＭＦＰ１の台数はこれに限らず任意である。図１に例示した２台のＭＦＰ１は、マスター／スレーブの関係であり、マスター（Ｍａｓｔｅｒ）として機能するＭＦＰ１は「第１の情報処理装置」として機能し、スレーブ（Ｓｌａｖｅ）として機能するＭＦＰ１は「第２の情報処理装置」として機能する。

図２は、ＭＦＰ１のハードウェア構成の一例を示す図である。図２に示すように、ＭＦＰ１は、ＣＰＵ１１と、ＲＯＭ１２と、ＲＡＭ１３と、ＨＤＤ（ハードディスクドライブ）１４と、ＳＤメモリカード１５と、通信Ｉ／Ｆ（インタフェース）１６と、操作パネル１７と、エンジン部１８と、を備え、これらがシステムバス１９を介して相互に接続されている。

ＣＰＵ１１は、ＭＦＰ１の動作を統括的に制御する。ＣＰＵ１１は、ＲＡＭ１３をワークエリア（作業領域）としてＲＯＭ１２等に格納されたプログラムを実行することで、ＭＦＰ１全体の動作を制御し、上述したコピー機能、スキャナ機能、ファクス機能、プリンタ機能などの各種機能を実現する。

通信Ｉ／Ｆ１６は、ネットワーク２と接続するためのインタフェースである。操作パネル１７は、ユーザからの各種の操作を受け付けるとともにＭＦＰ１に関する情報を表示する。例えば操作パネル１７は、液晶タッチパネルなどで構成される。エンジン部１８は、コピー機能、スキャナ機能、ファクス機能、および、プリンタ機能を実現させるための、汎用的な情報処理及び通信以外の処理を行うハードウェアである。例えば、原稿の画像をスキャンして読み取るスキャナ（画像読取部）、用紙等のシート材への印刷を行うプロッタ（画像形成部）、ファクス通信を行うファクス部などを備えている。更に、印刷済みシート材を仕分けるフィニッシャや、原稿を自動給送するＡＤＦ（自動原稿給送装置）のような特定のオプションを備えることもできる。

図３は、ＭＦＰ１単体上でのプログラム構成の一例を示す図である。図３に示すように、ＭＦＰ１は、ハードウェア、ＯＳ（オペレーティングシステム）、サービス、アプリケーションの４層で構成される。このうちＯＳ、サービス、アプリケーションがソフトウェアであり、個別にデバッグログ記録用のメモリ領域を持っている。各プログラム名と共に括弧で書いてある数値は、デバッグログ領域を示すＩＤ値である。たとえばアプリケーションの中の「コピー」は２０００番を有しており、ＯＳは１００〜１５０番までを有している。ＯＳは内部でデバイスドライバ等複数のプログラムが動作するため、複数のＩＤを持つ場合がある。

ハードウェアは、ＭＦＰ１を構成する物理的要素であり、エンジン部１８、ＨＤＤ１４、ＳＤメモリカード１５、デバッグログ領域を含むメモリ、その他ＣＰＵ１１などのリソースが存在する。

ＯＳはＵＮＩＸ（登録商標）などの汎用オペレーティングシステムであり、サービス並びにアプリケーションの各ソフトウェアをそれぞれプロセスとして並列実行する。サービス層では数十個程度のサービスプログラムが常時動作して装置の状態を監視・管理している。例えば図３では、サービス層は２つの層に分かれている。下層ではサービス群の統括管理を行うサービス統括管理や各ソフトウェアのデバッグログ領域をＨＤＤ１４上に記録するデバッグログ記録、ネットワーク２上の複数のＭＦＰ１間で問題が発生したデバッグログ情報をやりとりするデバッグログネットワーク管理（ＭａｓｔｅｒまたはＳｌａｖｅ）が動作する。ＭａｓｔｅｒとＳｌａｖｅの関係については後述する。また、上層ではサービスやアプリケーションの開始と終了を制御する起動・停止制御、装置の省電力モードを制御する省エネ制御、装置の設定を管理する設定管理、装置のネットワークの管理をするネットワーク管理、装置の障害状態を管理する障害管理、装置の用紙トレイや給紙排紙のためのドアを管理する装置ドア開閉管理、装置上で動作するアプリケーションの管理をするアプリケーション管理などが動作している。

アプリケーションは、装置を操作する人が実行したい機能を実現するためのソフトウェア群である。例えばコピー操作・プリンタ操作・スキャナ操作・ＦＡＸ操作等を行いたいときに動作するコピー、プリンタ、スキャナ、ＦＡＸ、装置のファームウェアを更新するときに動作するファームウェアアップデートなどがある。

図４は、Ｍａｓｔｅｒ−ＭＦＰ１（以下では単に「Ｍａｓｔｅｒ」と称する）およびＳｌａｖｅ−ＭＦＰ１（以下では単に「Ｓｌａｖｅ」と称する）の各々の構成を説明するための図である。本実施形態の情報処理システム１００は、それぞれがネットワーク２上で通信可能に配置されている複数のＭＦＰ１を備え、ログの管理に関して、複数のＭＦＰ１をＭａｓｔｅｒとＳｌａｖｅの２種類に分類する。説明の便宜上、ここでは、ＭａｓｔｅｒおよびＳｌａｖｅの各々は１台ずつであるが、これに限らず、例えばＭａｓｔｅｒおよびＳｌａｖｅが複数台ずつ存在してもよい。

図４に示すように、Ｍａｓｔｅｒは、Ｍａｓｔｅｒ管理情報１０１、通知受信プログラム１０２、リクエストプログラム１０３、管理データ表示プログラム１０４を備えている。Ｍａｓｔｅｒ管理情報１０１の詳細は後述するが、管理下にあるＳｌａｖｅ、および、自装置の各々の障害に関する障害情報を有し、障害に関するログ（障害ログ）と紐付けて管理する。

通知受信プログラム１０２は、Ｓｌａｖｅの通知プログラム１１２と連携して動作するプログラムである。詳細は後述するが、ＳｌａｖｅやＭａｓｔｅｒからのイベント通知を受けて、Ｍａｓｔｅｒ管理情報１０１に情報を追記する動作を行う。

リクエストプログラム１０３は、Ｓｌａｖｅのリクエスト受信プログラム１１３と連携して動作するプログラムである。詳細は後述するが、ユーザからのＵＩ操作による要求を受けて、ＭａｓｔｅｒからＳｌａｖｅに対してリクエストを送信する動作を行う。リクエスト内容によっては、ＨＤＤ１４、ＳＤメモリカード１５などの記憶装置に対して、取得したログの書き込みも行う。また、リクエストの内容によっては複数のＳｌａｖｅと通信を行うことになる。

管理データ表示プログラム１０４は、Ｍａｓｔｅｒ管理情報１０１を操作パネル１７上で閲覧・操作するためのプログラムである。詳細は後述する。

図４に示すように、Ｓｌａｖｅは、Ｓｌａｖｅ管理情報１１１、通知プログラム１１２、リクエスト受信プログラム１１３を備えている。ここでは説明の簡便化のために省くが、Ｓｌａｖｅは、Ｍａｓｔｅｒが有する管理データ表示プログラム１０４に相当するプログラムをさらに備えていてもよい。Ｓｌａｖｅ側で管理データを表示するためには、Ｍａｓｔｅｒに管理データを問い合わせ、返答を受信した後にＳｌａｖｅ側で表示することになる。

Ｓｌａｖｅ管理情報１１１の詳細は後述するが、親となるＭａｓｔｅｒの個体識別子や自装置で発生した障害に関するログなどを管理する。また、Ｍａｓｔｅｒとの通信が途絶している状況においては、未通知のデータを一時的に格納する領域としても機能する。以下の説明では、Ｍａｓｔｅｒ管理情報１０１とＳｌａｖｅ管理情報１１１を総称して、「ＭＦＰログ管理情報」と称する場合がある。

通知プログラム１１２は、Ｍａｓｔｅｒの通知受信プログラム１０２と連携して動作するプログラムであり、詳細は後述するが、Ｍａｓｔｅｒに対してイベントの通知を行うプログラムである。Ｍａｓｔｅｒが存在しないときにはローカルに情報を格納してＭａｓｔｅｒとの通信再開に備える。

リクエスト受信プログラム１１３は、Ｍａｓｔｅｒのリクエストプログラム１０３と連携して動作するプログラムであり、詳細は後述するが、Ｍａｓｔｅｒからのリクエストをうけて、結果をＭａｓｔｅｒに返信する処理を行う。リクエスト内容によっては、ログに対してピン止め（ログの消去を許可しない設定）を行い、以後、消去されないようにするための処理も行う。

また、ＭａｓｔｅｒやＳｌａｖｅは、相互に起動要求を相手に送信し、停止状態から起動状態へ遷移させることができてもよい。これにより、手近な１台のＭＦＰ１を起動することで、ネットワーク２上に存在する全てのＭＦＰ１の情報を取得することができる。

次に、ＭａｓｔｅｒおよびＳｌａｖｅの各々が有するＭＦＰログ管理情報について説明する。Ｍａｓｔｅｒが管理するＭａｓｔｅｒ管理情報１０１、および、Ｓｌａｖｅが管理するＳｌａｖｅ管理情報１１１はこの情報で表現される。

図５に示すように、ＭＦＰログ管理情報は、親情報（ｐａｒｅｎｔ）、ｃｈｉｌｄ個数、個体情報群を含む。

親情報は、自装置の親（Ｍａｓｔｅｒ）となるＭＦＰ１の情報であり、後述の個体情報で表現される。Ｍａｓｔｅｒの場合は親情報が存在しない。ｃｈｉｌｄ個数は、自装置の子（Ｓｌａｖｅ）となるＭＦＰ１の個数を表す。Ｓｌａｖｅの場合はゼロとなる。個体情報群は、後述の個体情報を複数含んだデータ列であり、自装置の子（Ｓｌａｖｅ）ごとの情報である。Ｓｌａｖｅの場合は個体情報群が存在しない。

図６に示すように、個体情報は、個体識別子と障害情報群とを含む。個体識別子は、「装置識別情報」の一例であり、ネットワーク２上に存在するＭＦＰ１を識別するための情報である。例えば個体識別子はＩＰアドレスなどであってもよい。障害情報群は後述する障害情報を複数含んだデータ列である。

図７に示すように、障害情報は、発生時刻と、発生元ログＩＤと、障害識別子と、ｐｉｎ止めｏｎ／ｏｆｆ情報とを含む。発生時刻は、障害が発生した時刻を示す。発生元ログＩＤは、「ログ識別情報」の一例であり、図３に示したプログラムごとのログＩＤ（ログを識別する情報）である。障害識別子は、発生した障害を識別するための情報である。この例では、例えばコピー時に印刷情報が正しく生成できなかった場合には「Ｓ１００」、プログラムが不正終了した場合には「Ｓ００１」というように番号が割り振られている。ｐｉｎ止めｏｎ／ｏｆｆ情報は、「消去可否情報」の一例であり、ログの消去を許可するか否かを示す情報である。この例では、ｐｉｎ止めｏｎ情報は、ログの消去を許可しない設定であることを意味し、ｐｉｎ止めｏｆｆ情報は、ログの消去を許可する設定であることを意味する。

図８は、Ｓｌａｖｅが有する通知プログラム１１２のイベントについて説明するための図である。この例では、図８（Ａ）に示すように、イベントには、「Ｅ１．起動通知」、「Ｅ２．停止通知」、「Ｅ３．障害発生通知」の３種類のイベントがある。「Ｅ１．起動通知」はＳｌａｖｅが起動したことを、Ｍａｓｔｅｒに知らせるための通知である。「Ｅ２．停止通知」はＳｌａｖｅが停止したことを、Ｍａｓｔｅｒに知らせるための通知である。「Ｅ３．障害発生通知」はＳｌａｖｅで障害が発生したことをＭａｓｔｅｒに知らせるための通知であり、図８（Ｂ）に示すように、発生時刻、発生元ログＩＤ、障害識別子、ｐｉｎ止めｏｎ／ｏｆｆ情報などを含んでいる。より具体的には、個体識別子なども含まれる。Ｍａｓｔｅｒはこれを受信すると、Ｍａｓｔｅｒ管理情報１０１から該当するＭＦＰ１の個体情報を探し出し、その障害情報群に追記する。また、ｐｉｎ止めｏｆｆとして通知を受信した場合、Ｍａｓｔｅｒは同じ障害識別子を持つ障害情報を探索し、その障害情報の中から、ｐｉｎ止めｏｎ情報を含む障害情報が存在するかどうかを確認し、ｐｉｎ止めｏｎを含む障害情報が存在すれば、発生元のＳｌａｖｅにｐｉｎ止めをｏｎに設定することを要求するリクエストを送信する。これによって、同一ネットワーク２上に接続されているＭＦＰ１群の中で同じ障害が発生しているものがあれば、同一の障害が発生したとして検知して管理できるようになる。

次に、ＭａｓｔｅｒからＳｌａｖｅに対して送信するコマンドの一つであるリクエストについて説明する。図９は、リクエストの一覧を示す図である。図９に示すように、リクエストとしては、「Ｒ１．管理情報収集」、「Ｒ２．ログ収集−一括」、「Ｒ３．ログ収集−単体」、「Ｒ４．ログ収集−ｐｉｎ単位」、「Ｒ５．ｐｉｎ止め設定」の５種類のリクエストがある。

「Ｒ１．管理情報収集」は、ＳｌａｖｅがＭａｓｔｅｒと通信できないときにローカルに保存していた情報を、Ｍａｓｔｅｒが吸い上げるためのリクエストである。Ｍａｓｔｅｒが再起動したときなどに用いられる。

Ｒ２〜Ｒ４のリクエストは、ログ管理情報ではなく、ログの実態を収集するためのリクエストである。普段の動作ではイベント通知によって、Ｍａｓｔｅｒが障害発生の情報を把握する。把握した情報をもとに、障害発生時のログを収集するときにこのリクエストを用いる。

「Ｒ２．ログ収集−一括」では、Ｍａｓｔｅｒ管理情報１０１に基づいて、ネットワーク２上のすべてのＭＦＰ１を対象として障害が発生した際のログを収集する。「Ｒ３．ログ収集−単体」では、ＭＦＰ１と発行元ログＩＤを特定してログの収集を行う。Ｍａｓｔｅｒを操作すれば、狙ったＭＦＰ１のログを収集することができる。「Ｒ４．ログ収集−ｐｉｎ単位」では、ｐｉｎ止めオンされた対象について、Ｍａｓｔｅｒ管理情報１０１に基づいてネットワーク２上のすべてのＭＦＰ１を対象としてログを収集する。これによって、同一内容と予想される障害についての情報（ログ）を一括で収集することができる。「Ｒ５．ｐｉｎ止め設定」は、対象となるＳｌａｖｅに対して、ｐｉｎ止めｏｎ／ｏｆｆ情報をｏｎに変更することを要求するリクエストである。

次に、図１０を用いて、管理データ表示プログラム１０４について説明する。管理データ表示プログラム１０４は、図１０（Ａ）に示す「ＭＦＰネットワーク上の障害情報」を表示する画面や図１０（Ｂ）に示す「同一障害情報」を表示する画面を操作パネル１７に表示する。

まず図１０（Ａ）の「ＭＦＰネットワーク上の障害情報」を表示する画面について、画面左の要素から説明していく。「マシン一覧」においては、Ｍａｓｔｅｒ管理情報１０１に基づいて、障害が一度でも発生したＭＦＰ１の名称が一覧で表示される。表下にある「一括収集」ボタンを押すと、一覧に表示された全てのＭＦＰ１から、障害に関する全てのログをネットワーク通信で収集し、Ｍａｓｔｅｒの記憶装置上に保存する。例えばユーザはこれをＵＳＢメモリなどに保存することで、障害ログを扱えるようになる。

また、「マシン一覧」に表示中の何れかのＭＦＰ１の名称をタッチすると、右隣の「障害一覧」に、タッチしたＭＦＰ１で発生した障害の一覧が表示される。表下にある「一括収集」ボタンを押すと、「障害一覧」に表示された全ての障害ごとの障害ログをネットワーク通信で収集し、Ｍａｓｔｅｒの記憶装置上に保存する。

また、「障害一覧」に表示された何れかの障害をタッチすると、右隣の「詳細」に、タッチした障害の詳細情報（障害情報）が表示される。詳細のうち「ｐｉｎ止め」については、右側にｏｎ／ｏｆｆを切り替えるためのボタンが表示される。ユーザは、このボタンを操作することでｐｉｎ止めをするかしないかを指示することができる。ｐｉｎ止めとは、該当する障害ログがＭＦＰ１から消去されてしまわないようにロックをかける動作のことである。通常、ＭＦＰ１中に記録されたログは常に出力され続けるものであるため、一定の期間を過ぎると上書きまたは消去されてしまう仕組みをとることが一般的である。そのため、障害発生時のログ（障害ログ）が消去されてしまうと解析が難しくなってしまうためにｐｉｎ止めという対策をとる。本システムでは、ｐｉｎ止めした対象の障害識別子については、同一障害の検知対象となり、Ｍａｓｔｅｒが通知プログラム１１２からｐｉｎ止め対象の障害識別子を受信した場合、Ｓｌａｖｅに対して即座にｐｉｎ止め要求を出す。表下にある「収集」ボタンを押すと、対応する障害に関するログをネットワーク通信で収集し、Ｍａｓｔｅｒの記憶装置上に保存する。また、詳細表示された障害がｐｉｎ止めｏｎを示す場合、表下の「同一障害表示」ボタンを押すことで、図１０（Ｂ）の「同一障害情報」を表示する画面へ遷移する。

図１０（Ｂ）の「同一障害情報」を表示する画面について、画面左の要素から説明していく。この画面では、左端に表示された障害情報に含まれる障害識別子と同一の障害識別子を含む障害情報について、ネットワーク２に接続されたすべてのＭＦＰ１から探し出すことができる。画面中央の「マシン一覧」において、同一障害が発生したことのある、ネットワーク２上の全てのＭＦＰ１が表示される。この中のＭＦＰ１を選択すると、右側の「障害一覧」に発生時刻の一覧が表示される。また、この例でも、各表の下のボタンを押下することで、ログの収集を実施できる。

図１１は、ＭａｓｔｅｒおよびＳｌａｖｅの各々が有する機能の一例を示す図である。説明の便宜上、図１１の例では、本発明に関する機能のみを主に例示しているが、ＭａｓｔｅｒおよびＳｌａｖｅの各々が有する機能はこれらに限られるものではない。これらの機能は、ＣＰＵ１１がＲＯＭ１２等の記憶装置に格納されたプログラムを実行することにより実現されるが、これに限らず、例えばこれらの機能のうちの少なくとも一部が専用のハードウェア回路（例えば半導体集積回路等）で実現されてもよい。

図１１に示すように、Ｓｌａｖｅは、第１の生成部１２１と、送信部１２２と、ｐｉｎ止め設定変更部１２３とを有する。第１の生成部１２１は、障害が発生した場合に、自装置を識別する装置識別情報と、発生した障害を識別する障害識別子と、該障害に関するログを識別するログ識別情報とが少なくとも紐付けられた障害管理情報を生成する。この例では、前述の個体識別子と前述の障害情報（図７参照）との組み合わせが障害管理情報に相当する。この例では、障害管理情報は、個体識別子と、障害識別子と、発行元ログＩＤと、ログの消去を許可するか否かを示すｐｉｎ止めｏｎ／ｏｆｆ情報（「消去可否情報」の一例）とが少なくとも紐付けられた情報であると考えることができる。第１の生成部１２１は、自装置で障害が発生するたびに、障害管理情報を生成する。

送信部１２２は、第１の生成部１２１により生成された障害管理情報をＭａｓｔｅｒへ送信する。この例では、送信部１２２は、第１の生成部１２１により障害管理情報が生成されるたびに、その生成された障害管理情報をＭａｓｔｅｒへ送信する。

ｐｉｎ止め設定変更部１２３は、後述するＭａｓｔｅｒ側の変更制御部１３５からの要求に応じて、Ｍａｓｔｅｒへ送信済みの障害管理情報に含まれるｐｉｎ止めｏｆｆ情報を、ｐｉｎ止めｏｎ情報に変更し、その変更を反映させた情報を変更制御部１３５へ返す。変更制御部１３５の具体的な内容については後述する。

図１１に示すように、Ｍａｓｔｅｒは、第２の生成部１３１と、受信部１３２と、記憶部１３３と、収集部１３４と、変更制御部１３５とを有する。

第２の生成部１３１は、障害が発生した場合に、障害管理情報（この例では、前述の個体識別子と前述の障害情報との組み合わせ）を生成する。第２の生成部１３１は、自装置で障害が発生するたびに、障害管理情報を生成する。

受信部１３２は、Ｓｌａｖｅから障害管理情報を受信する。記憶部１３３は、第２の生成部１３１により生成された障害管理情報、または、受信部１３２により受信された障害管理情報を記憶する。記憶部１３３は、上述のＭａｓｔｅｒ管理情報１０１を記憶していると考えてもよい。

なお、この例では、前述の第２の生成部１３１と前述の受信部１３２は、自装置または他の１以上のＳｌａｖｅにおいて障害が発生した場合に、自装置またはＳｌａｖｅを識別する個体識別子（「装置識別情報」の一例）と、発生した障害を識別する障害識別子と、該障害に関するログを識別する発行元ログＩＤ（「ログ識別情報」の一例）とが少なくとも紐付けられた障害管理情報を取得する「取得部」として機能すると考えることができる。

収集部１３４は、指定された障害を識別する障害識別子に紐付く全てのログ識別情報ごとに、該ログ識別情報で識別されるログを収集する。この例では、収集部１３４は、記憶部１３３を参照して、ユーザから指定された障害を識別する障害識別子に紐付く全ての発行元ログＩＤと個体識別子との組み合わせを特定する。そして、収集部１３４は、特定した組み合わせごとに、該組み合わせに含まれる個体識別子で識別されるＳｌａｖｅから、該組み合わせに含まれる発行元ログＩＤで識別されるログを取得（収集）する。本実施形態の収集部１３４による収集対象は、ログの消去を許可しないことを示すｐｉｎ止めｏｎ／ｏｆｆ情報（ｐｉｎ止めｏｎ情報）が紐付けられた発行元ログＩＤで識別されるログである。

変更制御部１３５は、ログの消去を許可することを示すｐｉｎ止めｏｎ／ｏｆｆ情報（ｐｉｎ止めｏｆｆ情報）を含む障害管理情報が第２の生成部１３１により生成された場合、または、該障害管理情報が受信部１３２により受信された場合に、記憶部１３３において、該障害管理情報に含まれる障害識別子と一致する障害識別子に対して、ログの消去を許可しないことを示すｐｉｎ止めｏｎ／ｏｆｆ情報（ｐｉｎ止めｏｎ情報）が紐付けられている場合、該障害管理情報に含まれるｐｉｎ止めｏｆｆ情報を、ｐｉｎ止めｏｎ情報に変更するための制御を行う。この例では、変更制御部１３５は、該障害管理情報に含まれる個体識別子で識別されるＳｌａｖｅに対して、ｐｉｎ止めｏｎ／ｏｆｆ情報をｏｎに変更することを要求するリクエスト（ｐｉｎ止め設定リクエスト）を送信する。そして、Ｓｌａｖｅからｐｉｎ止め設定リクエストに対する応答を受け取り、Ｍａｓｔｅｒ管理情報１０１に反映させる。

図１２は、Ｓｌａｖｅで障害が発生した場合の情報処理システム１００の動作例を示すフローチャートである。図１２では、Ｓｌａｖｅ側のフローと、Ｍａｓｔｅｒ側のフローとを分けて記載している。

まずＳｌａｖｅ側のフローを説明する。第１の生成部１２１は、障害の発生を検知すると（ステップＳ１）、上述の障害管理情報を生成する（ステップＳ２）。そして、ステップＳ２で生成した障害管理情報を、一時的に記憶するための障害管理情報バッファに格納する（ステップＳ３）。

通知プログラム１１２が起動済みの場合（ステップＳ４：Ｙｅｓ）、処理はそのまま続行され、後述のステップＳ６に移行する。通知プログラムが未起動の場合（ステップＳ４：Ｎｏ）、ＯＳは通知プログラム１１２を起動する（ステップＳ５）。そして、通知プログラム１１２は、Ｍａｓｔｅｒとの通信を確立する（ステップＳ６）。次に、通知プログラム１１２（送信部１２２）は、障害管理情報バッファに障害管理情報があるか否かを確認する（ステップＳ７）。

ステップＳ７の結果が肯定の場合（ステップＳ７：Ｙｅｓ）、通知プログラム１１２（送信部１２２）は、障害管理情報バッファに格納された障害管理情報をＭａｓｔｅｒへ送信する（ステップＳ８）。そして、Ｍａｓｔｅｒからの応答の受信を確認し（ステップＳ９）、ステップＳ７以降の処理を繰り返す。

ステップＳ７の結果が否定の場合（ステップＳ７：Ｎｏ）、通信プログラム１１２は、Ｍａｓｔｅｒとの通信路を閉路する（ステップＳ１０）。

次にＭａｓｔｅｒ側のフローを説明する。通知受信プログラム１０２（受信部１３２）は、Ｓｌａｖｅからの要求に応じてＳｌａｖｅと接続する（ステップＳ１１）。次に、通知受信プログラム１０２（受信部１３２）は、Ｓｌａｖｅから障害管理情報を受信する（ステップＳ１２）。次に、通知受信プログラム１０２は、ステップＳ１２で受信した障害管理情報を、障害管理情報バッファに格納する（ステップＳ１３）。そして、Ｓｌａｖｅに対して、ステップＳ１２で受信した障害管理情報に対する応答を返す（ステップＳ１４）。その後、通知受信プログラム１０２は、Ｓｌａｖｅから通信路を閉路する要求（切断要求）を受けない限り、ステップＳ１２〜ステップＳ１４の処理を繰り返す。Ｓｌａｖｅから切断要求を受けた場合、通知受信プログラム１０２は、Ｓｌａｖｅとの通信を切断する（ステップＳ１５）。

図１３は、ＭａｓｔｅｒがＳｌａｖｅから障害管理情報を受け取った後の情報処理システム１００の動作例を示すフローチャートである。図１３では、Ｍａｓｔｅｒ側のフローと、Ｓｌａｖｅ側のフローとを分けて記載している。

まずＭａｓｔｅｒ側のフローを説明する。図１３に示すように、Ｍａｓｔｅｒは、障害管理情報バッファに障害管理情報があるか否かを確認する（ステップＳ２１）。障害管理情報バッファに障害管理情報が存在する場合（ステップＳ２１：Ｙｅｓ）、Ｍａｓｔｅｒは、ＭＦＰログ管理情報（Ｍａｓｔｅｒ管理情報１０１）に該当するＳｌａｖｅのデータがあるか否かを確認する（ステップＳ２２）。具体的には、Ｍａｓｔｅｒは、Ｍａｓｔｅｒ管理情報１０１の中に、障害管理情報バッファに存在する障害管理情報に含まれる個体識別子と一致する個体識別子に紐付けられた障害情報群が存在するか否かを確認する。

ステップＳ２２の結果が否定の場合（ステップＳ２２：Ｎｏ）、ＭａｓｔｅｒはＳｌａｖｅデータを新たに作成する（ステップＳ２３）。ステップＳ２３の後、または、ステップＳ２２の結果が肯定の場合（ステップＳ２２：Ｙｅｓ）、Ｍａｓｔｅｒは、Ｓｌａｖｅデータの中の障害情報群にデータを追記する（ステップＳ２４）。より具体的には、Ｍａｓｔｅｒは、Ｍａｓｔｅｒ管理情報１０１のうち、障害管理情報バッファから読み出した障害管理情報に含まれる個体識別子と一致する個体識別子に紐付く障害情報群に、該障害管理情報に含まれる障害情報を追記する。

次に、Ｍａｓｔｅｒは、Ｍａｓｔｅｒ管理情報１０１において、障害管理情報バッファから読み出した障害管理情報に含まれる障害識別子と一致する障害識別子を含む１以上の障害情報のうち、ｐｉｎ止めｏｎ情報を含む障害情報が存在するか否かを確認する（ステップＳ２５）。ステップＳ２５の結果が肯定の場合（ステップＳ２５：Ｙｅｓ）、ｐｉｎ止め設定リクエストバッファにデータ（ｐｉｎ止め設定リクエスト）を格納し（ステップＳ２６）、処理はステップＳ２７に移行する。一方、ステップＳ２５の結果が否定の場合（ステップＳ２５：Ｎｏ）、そのまま処理はステップＳ２７に移行する。

ステップＳ２７において、ＯＳはリクエストプログラム１０３を起動し、Ｓｌａｖｅとの通信を確立する（ステップＳ２８）。そして、リクエストプログラム１０３は、ｐｉｎ止め設定リクエストバッファにデータが存在するか否かを確認する（ステップＳ２９）。ステップＳ２９の結果が肯定の場合（ステップＳ２９：Ｙｅｓ）、リクエストプログラム１０３（変更制御部１３５）は、ｐｉｎ止め設定リクエストバッファに格納されたｐｉｎ止め設定リクエストを、対象となるＳｌａｖｅへ送信する（ステップＳ３０）。そして、Ｓｌａｖｅからの応答の受信を確認し（ステップＳ３１）、ステップＳ２９以降の処理を繰り返す。

ステップＳ２９の結果が否定の場合（ステップＳ２９：Ｎｏ）、リクエストプログラム１０３は、Ｓｌａｖｅとの通信路を閉路する（ステップＳ３２）。

次にＳｌａｖｅ側のフローを説明する。リクエスト受信プログラム１１３は、Ｍａｓｔｅｒからの要求に応じてＭａｓｔｅｒと接続する（ステップＳ３３）。次に、リクエスト受信プログラム１１３は、Ｍａｓｔｅｒからｐｉｎ止め設定リクエストを受信する（ステップＳ３４）。次に、リクエスト受信プログラム１１３（ｐｉｎ止め設定変更部１２３）は、ステップＳ３４で受信したｐｉｎ止め設定リクエストに従って、対象となる障害管理情報（送信済みの障害管理情報）に含まれるｐｉｎ止めｏｆｆ情報を、ｐｉｎ止めｏｎ情報に変更し（ステップＳ３５）、Ｍａｓｔｅｒへ応答を返す（ステップＳ３６）。その後、リクエスト受信プログラム１１３は、Ｍａｓｔｅｒから通信路を閉路する要求（切断要求）を受けない限り、ステップＳ３４〜ステップＳ３６の処理を繰り返す。Ｍａｓｔｅｒから切断要求を受けた場合、リクエスト受信プログラム１１３は、Ｍａｓｔｅｒとの通信を切断する（ステップＳ３７）。

図１４は、ログを収集する場合のＭａｓｔｅｒの動作例を示すフローチャートである。図１４に示すように、まず、管理データ表示プログラム１０４は、ユーザからの障害の指定を受け付ける（ステップＳ４１）。例えば図１０（Ｂ）の画面の各表の下にある「一括収集」ボタンの押下の受け付けが、ステップＳ４１の受付に相当すると考えてもよい。次に、リクエストプログラム１０３（収集部１３４）は、Ｍａｓｔｅｒ管理情報１０１を参照して、ステップＳ４１で指定された障害を識別する障害識別子に紐付く全ての発行元ログＩＤを特定する（ステップＳ４２）。次に、リクエストプログラム１０３（収集部１３４）は、ステップＳ４２で特定した発行元ログＩＤごとにログを収集する（ステップＳ４３）。この例では、ログを要求するリクエストをＳｌａｖｅへ送信し、その応答としてログを受け取ることになる。

以上に説明したように、本実施形態のＭａｓｔｅｒとして機能するＭＦＰ１は、自装置または他の１以上のＭＦＰ１（Ｓｌａｖｅ）において障害が発生した場合に、個体識別子と、発生した障害を識別する障害識別子と、該障害に関するログを識別する発行元ログＩＤとが少なくとも紐付けられた障害管理情報を取得し、記憶部１３３に記憶する。そして、ユーザ操作によって指定された障害を識別する障害識別子に紐付く全ての発行元ログＩＤごとに、該発行元ログＩＤで識別されるログを収集する。これにより、ログの収集量を抑えながらも、問題解決のために十分な情報を得ることができる。

以上、本発明に係る実施形態について説明したが、本発明は、上述の実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上述の実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。

また、上述した実施形態のＭＦＰ１で実行されるプログラムは、インストール可能な形式または実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）等のコンピュータで読み取り可能な記録媒体に記録して提供するように構成してもよいし、インターネット等のネットワーク経由で提供または配布するように構成してもよい。また、各種プログラムを、ＲＯＭ等に予め組み込んで提供するように構成してもよい。

１ ＭＦＰ
２ ネットワーク
１１ ＣＰＵ
１２ ＲＯＭ
１３ ＲＡＭ
１４ ＨＤＤ
１５ ＳＤメモリカード
１６ 通信Ｉ／Ｆ
１７ 操作パネル
１８ エンジン部
１０１ Ｍａｓｔｅｒ管理情報
１０２ 通知受信プログラム
１０３ リクエストプログラム
１０４ 管理データ表示プログラム
１１１ Ｓｌａｖｅ管理情報
１１２ 通知プログラム
１１３ リクエスト受信プログラム
１２１ 第１の生成部
１２２ 送信部
１２３ ｐｉｎ止め設定変更部
１３１ 第２の生成部
１３２ 受信部
１３３ 記憶部
１３４ 収集部
１３５ 変更制御部

特許第５６７２４９１号公報

Claims (7)

1. 自装置または他の１以上の情報処理装置において障害が発生した場合に、自装置または前記他の１以上の情報処理装置を識別する装置識別情報と、発生した障害を識別する障害識別子と、該障害に関するログを識別するログ識別情報とが少なくとも紐付けられた障害管理情報を取得する取得部と、
   前記取得部により取得された前記障害管理情報を記憶する記憶部と、
   指定された障害を識別する前記障害識別子に紐付く全ての前記ログ識別情報ごとに、該ログ識別情報で識別される前記ログを収集する収集部と、を備える、
   情報処理装置。
2. 前記障害管理情報は、前記装置識別情報と、前記障害識別子と、前記ログ識別情報と、前記ログの消去を許可するか否かを示す消去可否情報とが少なくとも紐付けられた情報であり、
   前記収集部による収集対象は、前記ログの消去を許可しないことを示す前記消去可否情報が紐付けられた前記ログ識別情報で識別される前記ログである、
   請求項１に記載の情報処理装置。
3. 前記ログの消去を許可することを示す前記消去可否情報を含む前記障害管理情報が前記取得部により取得された場合に、前記記憶部において、該障害管理情報に含まれる前記障害識別子と一致する前記障害識別子に対して、前記ログの消去を許可しないことを示す前記消去可否情報が紐付けられている場合、前記取得部により取得された前記障害管理情報に含まれる前記消去可否情報を、前記ログの消去を許可しないことを示す前記消去可否情報に変更するための制御を行う変更制御部をさらに備える、
   請求項１または２に記載の情報処理装置。
4. 前記情報処理装置と前記他の１以上の情報処理装置との関係は、マスター／スレーブの関係であり、前記情報処理装置はマスターとして機能する、
   請求項１乃至３のうちの何れか１項に記載の情報処理装置。
5. 第１の情報処理装置と、第２の情報処理装置とを少なくとも含む情報処理システムであって、
   前記第２の情報処理装置は、障害が発生した場合に、自装置を識別する装置識別情報と、発生した障害を識別する障害識別子と、該障害に関するログを識別するログ識別情報とが少なくとも紐付けられた障害管理情報を生成する第１の生成部と、
   前記第１の生成部により生成された前記障害管理情報を前記第１の情報処理装置へ送信する送信部と、を備え、
   前記第１の情報処理装置は、
   障害が発生した場合に、前記障害管理情報を生成する第２の生成部と、
   前記第２の情報処理装置から前記障害管理情報を受信する受信部と、
   前記第２の生成部により生成された前記障害管理情報または前記受信部により受信された前記障害管理情報を記憶する記憶部と、
   指定された障害を識別する前記障害識別子に紐付く全ての前記ログ識別情報ごとに、該ログ識別情報で識別される前記ログを収集する収集部と、を備える、
   情報処理システム。
6. 自装置または他の１以上の情報処理装置において障害が発生した場合に、自装置または前記他の１以上の情報処理装置を識別する装置識別情報と、発生した障害を識別する障害識別子と、該障害に関するログを識別するログ識別情報とが少なくとも紐付けられた障害管理情報を取得する取得ステップと、
   前記取得ステップにより取得された前記障害管理情報を記憶する記憶部を参照して、指定された障害を識別する前記障害識別子に紐付く全ての前記ログ識別情報を特定し、特定した前記ログ識別情報ごとに、該ログ識別情報で識別される前記ログを収集する収集ステップと、を含む、
   情報処理方法。
7. コンピュータに、
   自装置または他の１以上の情報処理装置において障害が発生した場合に、自装置または前記他の１以上の情報処理装置を識別する装置識別情報と、発生した障害を識別する障害識別子と、該障害に関するログを識別するログ識別情報とが少なくとも紐付けられた障害管理情報を取得する取得ステップと、
   前記取得ステップにより取得された前記障害管理情報を記憶する記憶部を参照して、指定された障害を識別する前記障害識別子に紐付く全ての前記ログ識別情報を特定し、特定した前記ログ識別情報ごとに、該ログ識別情報で識別される前記ログを収集する収集ステップと、を実行させるためのプログラム。

Images