(57)【要約】      （修正有）【課題】重要なイベントの情報のログファイルを優先して記録領域に記録し、記録領域の消費、計算機資源の消費を低減する。【解決手段】イベントの情報の種別を判別しＳ９０１、記録先ディレクトリを決定するＳ９０２。記録先ディレクトリ内の最新のイベントの情報のログファイルを判別しＳ９０３、イベントの情報を書き込むかを、ファイルサイズに基づき判断するＳ９１０。ｙｅｓの場合、ログファイルの末尾にイベントの情報を追記するＳ９１１。ｎｏの場合、新規のログファイルを作成した場合に記録先ディレクトリ下に記録されるログファイルの数が所定のファイル数を超過するかを判断しＳ９２０、ｎｏならば新規ログファイルを作成しＳ９２１、イベントの情報を追記するＳ９１１。ｙｅｓならば、記録先ディレクトリ下のログファイル中で最も作成日時が古いファイルを削除しＳ９３０、新規ログファイルを作成しＳ９２１、イベントの情報を追記するＳ９１１。【選択図】図９
2020071572.tif 000002
【特許請求の範囲】
【請求項１】
記憶装置を備え、複数種類のイベントを検出して、検出された各イベントの情報をログファイルとして前記記憶装置に記録し、ログファイルをネットワークを介して外部のシステムに送信するネットワーククライアントであって、
第１のイベント種別に該当する複数種類のイベントのそれぞれについて、前記記憶装置に、各イベントの情報を記録するログファイルの最大ファイルサイズと、該ログファイルの最大ファイル数と、を設定することで、各イベントのための記録領域をそれぞれ確保する第１確保手段と、
第２のイベント種別に該当する複数種類のイベントについて、前記記憶装置に、前記第２のイベント種別に該当する全てのイベントの情報をまとめて記録するログファイルの最大ファイルサイズと、該ログファイルの最大ファイル数と、を設定することで、該全てのイベントのための記録領域を確保する第２確保手段と、
イベントが検出された場合に、該イベントの種別が前記第１のイベント種別か前記第２のイベント種別かに応じて、前記第１確保手段で、確保された記録領域と前記第２確保手段で確保された記録領域との何れかに、該イベントの情報を記録する記録手段と、
を有することを特徴とするネットワーククライアント。
【請求項２】
前記第１確保手段は、各イベントの種別毎にログファイルの最大ファイルサイズと、該ログファイルの最大ファイル数について、異なる設定を行うことで記録領域を確保することを特徴とする請求項１に記載のネットワーククライアント。
【請求項３】
前記第１確保手段は、各イベント種別が属す優先度毎にログファイルの最大ファイルサイズと、該ログファイルの最大ファイル数について、異なる設定を行うことで記録領域を確保することを特徴とする請求項１に記載のネットワーククライアント。
【請求項４】
前記第１のイベント種別に該当する複数種類のイベントには、部品の交換イベント、及びサービスコールが発生した際に行われる自己診断イベント、の少なくとも1つが含まれることを特徴とする請求項1〜３の何れか１項に記載のネットワーククライアント。
【請求項５】
前記第２のイベント種別に該当する複数種類のイベントには、電源状態の遷移イベント、ジョブ状態の遷移イベント、アプリケーションのインストールに係るイベント、及び部品の寿命に係るイベント、の少なくとも１つが含まれることを特徴とする請求項１〜４の何れか１項に記載のネットワーククライアント。
【請求項６】
検出されたイベントの情報のデータサイズと該イベントの情報のログファイルのファイルサイズの合計が前記ログファイルの最大ファイルサイズ以上の場合は、前記記録先ディレクトリ下に新規のイベントの情報のログファイルを作成し、前記検出されたイベントの情報を追記すること、を特徴とする請求項１〜５の何れか１項に記載のネットワーククライアント。
【請求項７】
新規のイベントの情報のログファイルを作成した場合に、前記記録先ディレクトリ下に記録されるイベントの情報のログファイルの数が最大ファイル数を超える場合には、前記記録先ディレクトリ下のログファイルを削除した上で、新規のログファイルを作成し、前記検出されたイベントの情報を追記すること、を特徴とする請求項６に記載のネットワーククライアント。
【請求項８】
前記各イベントの記録領域に対応するイベントの発生の頻度が、該イベントの最大頻度を超えていた場合に、イベントの情報をログファイルに追記を行わないこと、
を特徴とする請求項１〜７の何れか１項に記載のネットワーククライアント。
【請求項９】
記憶装置を備え、複数種類のイベントを検出して、検出された各イベントの情報をログファイルとして前記記憶装置に記録し、ログファイルをネットワークを介して外部のシステムに送信するネットワーククライアントの制御方法であって、
第１のイベント種別に該当する複数種類のイベントのそれぞれについて、前記記憶装置に、各イベントの情報を記録するログファイルの最大ファイルサイズと、該ログファイルの最大ファイル数と、を設定することで、各イベントのための記録領域をそれぞれ確保する第１確保ステップと、
第２のイベント種別に該当する複数種類のイベントについて、前記記憶装置に、前記第２のイベント種別に該当する全てのイベントの情報をまとめて記録するログファイルの最大ファイルサイズと、該ログファイルの最大ファイル数と、を設定することで、該全てのイベントのための記録領域を確保する第２確保ステップと、
イベントが検出された場合に、該イベントの種別が前記第１のイベント種別か前記第２のイベント種別かに応じて、前記第１確保手段で、確保された記録領域と前記第２確保手段で確保された記録領域との何れかに、該イベントの情報を記録する記録ステップと、
を有することを特徴とするネットワーククライアントの制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーククライアント及びその制御方法に関する。
【背景技術】
【０００２】
サーバとネットワークを介して接続されているネットワーククライアントの保守、該装置の動作の予兆予測の分析、該装置に搭載された機能の改善を迅速に行う必要に迫られることがある。この状況に対処するため、稼働しているネットワーククライアントから各種イベントログをインターネットを通じてイベントログ管理サーバに送信するシステムが知られている。
このようなシステムにおいては、サーバとの通信が何らかの原因で断絶してしまう可能性を踏まえ、送信すべきイベントログをネットワーククライアント装置内の記憶装置に記録領域を確保してバッファリングすることとしている。その際、ネットワーククライアント装置の記録領域の大漁消費を防ぐために、バッファリングしているデータが所定の量を超過した場合に、古いイベントログを順次削除しながら動作させる方法が知られている(例えば、特許文献1を参照)。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開2016-48433号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
この方法を用いると、イベントログ管理サーバとの通信状況に関わらずイベントログを収集し続けることが可能である。しかし、多種多様なイベントを扱う場合には、記録領域上に各種イベントが混在し、ネットワーククライアント装置の稼働状況を把握するうえで重要なイベントの情報のログが、比較的重要ではないイベントを記録するために削除されてしまう可能性がある。
上記の課題を解決するために、イベントの種別に応じて各々バッファリング可能なデータ量を予約しておくことも考えられるが、イベントが発生しない場合には予約領域が無駄になってしまう。
特許文献1に記載の技術ではこれらの課題の解決策の一例として、履歴を蓄積している領域がフルになったときに、登録されたキーワードから履歴の重要度を判定し、重要度が低いものから削除することが示されている。しかし、新規イベントログ発生時に削除するイベントログを特定する必要があり、既にバッファリングしているログをその都度走査する必要がある。このため、記録領域からのデータ読み出しをはじめとした処理が必要となり、ネットワーククライアント装置の計算機資源を消費し、装置の動作に影響を与える可能性がある。
本発明は、重要なイベントの情報のログファイルを優先して記録領域に記録することを可能とし、記録領域の消費、計算機資源の消費を低減することを目的とする。
【課題を解決するための手段】
【０００５】
上記の課題を解決するために本発明は以下の構成を備える。
記憶装置を備え、複数種類のイベントを検出して、検出された各イベントの情報をログファイルとして前記記憶装置に記録し、ログファイルをネットワークを介して外部のシステムに送信するネットワーククライアントであって、第１のイベント種別に該当する複数種類のイベントのそれぞれについて、前記記憶装置に、各イベントの情報を記録するログファイルの最大ファイルサイズと、該ログファイルの最大ファイル数と、を設定することで、各イベントのための記録領域をそれぞれ確保する第１確保手段と、第２のイベント種別に該当する複数種類のイベントについて、前記記憶装置に、前記第２のイベント種別に該当する全てのイベントの情報をまとめて記録するログファイルの最大ファイルサイズと、該ログファイルの最大ファイル数と、を設定することで、該全てのイベントのための記録領域を確保する第２確保手段と、イベントが検出された場合に、該イベントの種別が前記第１のイベント種別か前記第２のイベント種別かに応じて、前記第１確保手段で、確保された記録領域と前記第２確保手段で確保された記録領域との何れかに、該イベントの情報を記録する記録手段と、を有することを特徴とする。
【発明の効果】
【０００６】
本発明によれば、重要なイベントの情報のログファイルを優先して記録領域に記録することを可能とし、記録領域の消費、計算機資源の消費を低減することができる。
【図面の簡単な説明】
【０００７】
【図１】ネットワークシステム全体を示すシステム構成図
【図２】管理サーバの構成を示すブロック図
【図３】ネットワーククライアントの全体構成を示すブロック図
【図４】情報処理コントローラユニットの構成を示すブロック図
【図５】ネットワーククライアントのソフトブロック図
【図６】イベントの検知から管理サーバへ送付するまでの処理のフローチャート
【図７】正規化されたイベントの情報の構成を示す図
【図８】ネットワーククライアントのＨＤＤ内に記録されるデータの構成図
【図９】イベントの情報をメッセージバッファに記録する際のフローチャート
【図１０】他の実施例におけるイベントの情報を記録する際のフローチャート
【発明を実施するための形態】
【０００８】
以下、本発明を実施するための形態について図面を用いて説明する。
【実施例１】
【０００９】
図１は、本発明におけるシステム全体を示すシステム構成図である。ネットワーク100には、情報処理装置である管理サーバ110、およびネットワーククライアント120が接続されている。
ネットワーククライアント120には機器内でのイベントをイベントの情報のログファイルの形で管理サーバ110に対して通知する通信機能を具備している。管理サーバ110は複数のネットワーククライアント120から通知されたイベントの情報のログを管理サーバ内のストレージに記録する機能を具備している。ストレージに蓄積された情報は稼働監視情報の分析などに利用される。
本実施例では管理サーバ110についてはデータストレージと情報処理計算とネットワーク通信機能を具備するコンピュータなどの一般的な情報処理装置や、同等機能を持つクラウドサービスで実現できる。
ネットワーククライアント120としては複数種類の機能、例えばコピーやFAX等を実現する複合機を例に説明する。それらの機能の実行をしたイベントの情報のログに加え、省電力状態への遷移や復帰の履歴、またエラー発生など異常状態への遷移・復帰などの履歴などを管理サーバ110に通知する機能を具備している。なお、ネットワーククライアント120は、上記の複合機に限らず、ネットワークカメラや、ネットワーク家電、ナビゲーションシステム等のネットワークに接続される各種IoT機器でもよい。
【００１０】
図２は、本発明における管理サーバ110が一般的なコンピュータなどの情報処理装置で実現された場合の構成を表すブロック図である。管理サーバ110は、コントローラユニット200、操作部209、表示部210を含んでいる。
コントローラユニット200は、ＣＰＵ(Central Processing Unit)201を有する。ＣＰＵ201は、ＲＯＭ(Read Only Memory)202に保存されているブートプログラムによりＯＳ(Operating System)を起動する。
ＣＰＵ201は、このＯＳ上で、ＨDＤ(Hard Disk Drive)204に保存されているアプリケーションプログラムを実行し、これによって各種処理を実行する。このＣＰＵ201の作業領域としてはＲＡＭ(Random Access Memory)203が用いられる。
ＨＤＤ204は、上記アプリケーションプログラムと設定や履歴等のデータを記録する。
ＣＰＵ201には、システムバス208を介して、ＲＯＭ202、ＲＡＭ203及びＨＤＤ204とともに、操作部Ｉ/Ｆ205、表示部Ｉ/Ｆ206、Network207が接続される。
操作部Ｉ/Ｆ205は、マウス、キーボード等から成る操作部209とのインタフェースであり、操作部209によってユーザにより入力された情報をＣＰＵ201に送出する。表示部Ｉ/Ｆ206は、ディスプレイ等から成る表示部210に表示すべき画像データを表示部210に対して出力する。
また、Network207は、ネットワーク100に接続され、ネットワーク100を介してネットワーク100上の各装置との間で情報の入出力を行う。
【００１１】
図３は本発明におけるネットワーククライアント120の構成を表すブロック図である。ネットワーククライアント120は、情報処理コントローラユニット301、プリンタコントローラユニット302、スキャナコントローラユニット303を含んでいる複合機(MFP)である。さらに、プリンタ304、スキャナ305、操作部306も含んでいる。
情報処理コントローラユニット301は、ネットワーククライアント120の動作に係る情報処理制御を統括するコントローラであり、操作部306が接続される。さらに画像出力デバイスであるプリンタ304を制御するプリンタコントローラユニット302や画像入力デバイスであるスキャナ305を制御するスキャナコントローラユニット303が接続される。
【００１２】
図４は本発明におけるネットワーククライアント120の情報処理コントローラユニット301の構成を表すブロック図である。
情報処理コントローラユニット301は、ＣＰＵ401を有し、ＣＰＵ401は、ＲＯＭ402に保存されているブートプログラムによりＯＳを起動する。ＣＰＵ401は、このＯＳ上で、ＨＤＤ404に保存されているアプリケーションプログラムを実行し、これによって各種処理を実行する。このＣＰＵ401の作業領域としてはＲＡＭ403が用いられる。また、ＲＡＭ403は、作業領域を提供するとともに、画像データを一時記憶するための画像メモリ領域を提供する。ＨＤＤ404は、上記アプリケーションプログラムや画像データ、各種設定値や履歴を記録する。
ＣＰＵ401には、システムバス410を介して、ＲＯＭ402、ＲＡＭ403及びＨＤＤ404とともに、操作部Ｉ/Ｆ406、デバイスコントローラＩ/Ｆ408、Network405、画像処理部407及び電源制御部409が接続される。
【００１３】
操作部Ｉ/Ｆ406は、タッチパネルを有する操作部306とのインタフェースであり、操作部306に表示すべき画像データを操作部306に対して出力する。また、操作部Ｉ/Ｆ406は、操作部306によってユーザにより入力された情報をＣＰＵ401に送出する。
デバイスコントローラＩ/Ｆ408にはプリンタコントローラユニット302及びスキャナコントローラユニット303が接続され、デバイスコントローラＩ/Ｆ408は、画像データの同期系/非同期系の変換を行う。
Network405は、ネットワーク100に接続され、ネットワーク100を介してネットワーク100上の各装置との間で情報の入出力を行う。
画像処理部407では、プリンタ304への出力画像処理やスキャナ305からの入力画像処理、画像回転、画像圧縮、解像度変換、色空間変換、階調変換などの処理を行う。
電源制御部409は機器全体の電源制御を行う。電源オンオフの制御の他通常通電状態以外の省電力状態への移行や、通常状態への復帰などを制御する。
【００１４】
図５は本発明におけるネットワーククライアント120のソフトウェアブロック図である。本実施例では、動作を行うためのソフトウェアはＲＡＭ403、ＨＤＤ404、ＲＯＭ402のいずれかの記憶手段に記憶され、ＣＰＵ401により実行されるものとする。ネットワーククライアント120は複合機(MFP)であり、スキャン、プリント、およびネットワークやメモリストレージを利用した各種機能を実現するソフトウェアが動作する。
ユーザインターフェース501は操作部306に対してユーザが操作する画面を表示したり、ユーザが操作した際にその動きをソフトウェアに伝えたりする機能を持つ。
機能アプリケーション502はコピー、プリント、メール送信などのアプリケーションで機器内に複数あり、操作部306を経由したユーザの指示やNetwork405経由のデータ受信などをトリガにして複合機のアプリケーション機能を動作させる。
ジョブ制御部503は機能アプリケーション502からの指示を受けてプリンタコントローラユニット302やスキャナコントローラユニット303を制御してスキャンやプリントを実行する。
電源制御部504は、装置内のソフトウェアの状態と連動して、電源制御部409を制御し通常通電状態と省電力状態の遷移をつかさどる。
エラー制御部505は、主にジョブ制御部503やプリンタコントローラユニット302やスキャナコントローラユニット303などで発生した異常状態の通知を受け、システム全体を停止したり、機能を限定した縮退動作を指示したりの制御を実施する。
【００１５】
履歴・設定保持部506は機器内における不揮発データを管理する。複合機やジョブの制御に必要な設定を保持したり、ユーザの操作履歴やジョブ実行結果およびエラーの発生などをサマライズして記録したりする。またシステムの不具合発生時に解析デバッグ用途で残すログ情報もここに記録される。不揮発データの実体はＨＤＤ404に保持される。
イベント回収部510は機器内の各モジュール(501〜506)で発生した状態遷移を監視し、イベントとして検出し、それを管理サーバ110に送付するため、検出されたイベントを正規化しメッセージバッファ520に記録する。
メッセージバッファ520はＨＤＤ404上にあり正規化されたイベントは不揮発領域に記録される。本実施例においては、イベントの正規化方式としてＪＳＯＮ(JavaScript（登録商標） Object Notation)フォーマットを使うものとする。イベント名称、発生時刻などの基本情報に加えてイベントの種別によって、追加でさまざまな情報が付加される。これら付加情報はイベント回収部510が、履歴・設定保持部506などの不揮発データや、機器内各モジュール(501〜506)の状態を参照することにより、動的に取得する。具体的なイベントの情報の例については後述する。
イベント送付部530はメッセージバッファ520への書き込みを検出するなどしてイベントが発行されたことを受け、メッセージバッファ520から情報を読み出してネットワーク通信部531を介して外部の管理サーバ110に対してイベントを送付する。
ネットワーク通信部531はNetwork405を利用し通信する。
【００１６】
図６は本発明におけるネットワーククライアント120の機器内で各種イベントが起きた際の管理サーバ110へのイベントの情報のログファイル送付の流れを示したフローチャートである。
［イベントの情報のログファイル送付処理：メイン］
エラー発生イベントを契機としたイベントの情報のログファイル送付処理についてフローチャート600に示す。
ステップS601において、イベント回収部510は、エラーの発生を検知する。
続くステップS602において、イベント回収部510は、現在時刻を取得する。そしてイベント回収部510は、後述のイベントの情報のログファイル発行のサブルーチンに対してイベント種別としてエラー発生イベントである旨と、イベント発生時刻として取得した現在時刻を引数として引渡す。該サブルーチンが処理を実行することで外部の管理サーバ110にイベントの情報のログファイルが送付され、その後全体処理を終了する。
［イベント発行処理：サブ］
次に、前記サブルーチンについてフローチャート610を用いて詳細に説明する。
ステップS611において、イベント回収部510は受信したイベント種別の内容に応じてあらかじめ紐づけられた情報を機器内の各モジュールから情報を収集する。例えばエラー発生のイベントであれば、エラーコードやエラーが起きた部品の名称、その時までの通紙したカウント値などが収集対象の情報になる。また、例えばコピージョブの完了イベントであれば、実行ユーザ名、カラーモノクロの区別、スキャン枚数、プリント枚数などが収集対象の情報になる。これら収集した情報に加えて、引渡された時刻情報を使ってＪＳＯＮのような汎用フォーマットにして正規化する。
続いてステップS612で、イベント回収部510は正規化されたイベントの情報をログファイルとしてメッセージバッファ520の該イベント種別の記録領域に記録する。この時点でサーバへの送付内容が確定される。ステップS612の処理の詳細は後述する。
【００１７】
続いてステップS613にて、イベント送付部530は、ステップS612でのイベント回収部510による書き込みを非同期に検知する。そしてイベント送付部530は、メッセージバッファ520から正規化されたイベントの情報のログファイルを読み出す。
続くステップS614で、イベント送付部530は読み出されたイベントの情報のログファイルを外部の管理サーバ110へ送信する。ここではサーバへの認証動作や通信エラー時のリトライ処理などを含めて送信完了までを実行する。送付された管理サーバ110は受信したイベントの情報をストレージに記録する。
このようにしてネットワーククライアント120内で発生した各種イベントは管理サーバ110に送信され収集される。
【００１８】
［イベントの情報の例］
図７は本実施例のS612においてメッセージバッファに記録される、イベントの情報のログファイルの一例である。前述したように、本実施例においてはイベントの情報をＪＳＯＮ形式で表現する。
イベントの情報には、イベント種別(“event_type”属性)、イベント発生日時(“occur_datetime”属性)、発生したイベントの具体的な内容(“attributes”属性)が含まれる。また、イベントに関連する付加情報(“additional_info”属性)を付与することも可能である。図７の例は、イベント種別が機器内でエラーが発生(“error_occurred”)し、サービスコールを要請する際、現状を判断する自己診断イベントであることを示している。具体的には“3344"というエラーコード(“error_code”)が発生していることを示している。これに加えて、エラー発生時の機器の周辺環境(“environment”属性)として、周辺温度(“tempareture”属性)や周辺湿度(“humidity”属性)も付加情報として記録されている。イベント種別は、ここで示したエラー発生以外にも、任意のイベント種別を作成することが可能である。また、イベントの具体的な内容や、付加情報に関しても、イベント種別に応じて任意の内容を記録することが可能であり、更に必要に応じて他の情報を記録しても構わない。
【００１９】
図８は本実施例においてＨＤＤ404に記録されるデータの構成を示す図である。ＨＤＤ404には、ルートディレクトリ以下に、機器で実行されるプログラム(/programs/main.exe)、履歴・設定保持部506が管理するファイル(/settings/setting.conf)が記録される。またその外に、ジョブ制御部503や機能アプリケーション502が使用する画像ファイル(/images/img0・・・.jpg)が記録される。同様に、メッセージバッファ520の記録領域として “messagebuffer”ディレクトリ以下が用意されており、イベントの情報はこのディレクトリ以下のファイルに記録される。具体的には、イベント種別毎に更に子ディレクトリが作成され、これらのディレクトリ以下に正規化されたイベントの情報を記録するためのイベントの情報のログファイルが作成される。一般情報に関する“generalevents”ディレクトリに示すように、イベントの情報の発生状況に依存し、一つの子ディレクトリには複数のイベントの情報のログファイルが存在することもある。本実施例においては、イベントの情報のログファイルの名称としてファイルの作成日時を利用しているが、ファイル名が子ディレクトリ上で一意になる規則であれば、他の情報をファイル名として利用しても構わない。
【００２０】
［イベントの情報のログファイルをメッセージバッファに記録するサブルーチン］
図９は、図６のフローチャート内のステップS612のサブルーチンの詳細を示すフローチャートである。このフローチャートは、イベント回収部510に対応するソフトウェアをＣＰＵ401が実行することで達成される。
はじめにステップS901にてイベント種別を判別する。具体的には、図７に示したイベントの情報の中の“event_type”属性を確認する。
次に、ステップS902にて、ステップS901で判別したイベント種別、及び表１に示すメッセージバッファの管理テーブルの情報を元に、記録先ディレクトリを決定する。
【表１】
2020071572.tif 000003
【００２１】
上記管理テーブル内には、メッセージバッファ502内の各ディレクトリの名称に対応して、記録対象のイベント種別、ディレクトリ内に作成するイベントの情報のログファイルの最大ファイルサイズ、ディレクトリ内に作成する最大ファイル数が記録されている。なお、本実施例においては、表1に示す管理テーブルはイベント回収部510のプログラム内に埋め込まれるものとする。
記録対象イベント種別の基本情報に関する“basic_informcation”，エラー発生に関する“error_occurred”，警告の発生に関する“worning_occurred” は、重要なイベントであるので第１のイベント種別に該当する。そして、これら第１のイベント種別のイベントの情報のログファイルは、最大ファイルサイズと、該ログファイルの最大ファイル数とを設定することにより、該イベント種別のイベントの情報のログが記録されるディレクトリの領域を確保されている。
一方、上記以外のイベント種別のイベントは、第１のイベント種別のイベントより重要度が低い第２のイベント種別として設定されており、これらのイベントの情報をまとめたログファイルとして記録される。
基本情報“basicinformation”のディレクトリには、ネットワーククラインアントのシリアル番号、機種名などの基本情報に係るイベントのログファイルが記録される。
サービスコール“servicecall”のディレクトリには、エラー発生によりサービスコールや縮退動作が発生した際に、その原因となったユニットを特定するために行われる自己診断イベントのログファイルが記録される。
警告“warning”のディレクトリには、警告が発生した際に、ネットワーククライアントの状況などに係るイベントのログファイルが記録される。
また、一般情報“generalevents”のディレクトリには、その他のイベント種別全てが該当する。例えば、電源状態の遷移イベント、ジョブ状態の遷移イベント、アプリケーションのインストールに係るイベント、部品の寿命に係るイベントなどがこれに含まれる。
【００２２】
ステップS902では、具体的にはS901で判別したイベント種別が、表1の“記録対象イベント種別"列のどの行に該当するかを判断し、該当行の“ディレクトリ名称"列に記載されたディレクトリを記録先ディレクトリとする。例えば、記録を依頼されたイベントの情報のイベント種別が“error_occurred”であった場合、このイベントの情報を記録するディレクトリ名称は“servicecall”となる。
続いて、ステップS903にて記録先ディレクトリ内の最新のイベントの情報のログファイルを判別する。本実施例においては、イベントの情報のログファイル名にはファイルの作成日時を付与しているため、ファイル名の比較により最新のイベントの情報のログファイルを判別するものとする。
その後、ステップS910にて判別した最新のイベントの情報のログファイルにイベントの情報を書き込むかどうかを判断する。具体的にはイベントの情報のログファイルのファイルサイズを取得する。このファイルサイズにイベントの情報のデータサイズを加算し、この合計サイズが記録先ディレクトリに対応する表1の管理テーブル内での最大ファイルサイズ以上であるかどうかを判断する。例えば“error_occurred”イベントの場合、記録先ディレクトリは“servicecall”であるため、最大ファイルサイズは32KBとなる。前記合計サイズが最大ファイルサイズ以内であった場合には、メッセージバッファ502は最新のイベントの情報のログファイルにイベントを書き込むと判断する。
ステップS910において最新のイベントの情報のログファイルにイベントの情報を書き込むと判断した場合(S910でyes)には、ステップS911にてこのイベントの情報のログファイルの末尾にイベントの情報を追記する。
【００２３】
一方、ステップS910で、最新のイベントの情報のログファイルのファイルサイズとイベントの情報のデータサイズの合計が記録先ディレクトリの最大ファイルサイズ以上である場合は、該ログファイルにイベントの情報を書き込まないと判断する。
そして、ステップS910において最新のイベントの情報のログファイルにイベントの情報を書き込まないと判断した場合(S910でno)、新たにイベントの情報のログファイルを作成しこれにイベントの情報を書き込むこととし、S920に進む。
そのためステップS920にて、新規のイベントの情報のログファイルを作成した場合に、記録先ディレクトリ下に記録されるイベントの情報のログファイルの数が所定のファイル数を超過するかどうかを判断する。具体的には、記録先ディレクトリ下に存在するイベントの情報のログファイルの数が、表1の管理テーブル内で記録先ディレクトリの最大ファイル数未満であるかどうかを判断する。例えば、“error_occurred"イベントの場合、記録先ディレクトリは“servicecall”であるため、最大ファイルサイズ数は１０となる。
ステップS920においてファイル数が超過しないと判断した場合(S920でno)には、ステップS921にて新規ログファイルを作成した上で、この新規ログファイルにステップS911にてイベントの情報を追記する。
一方、ステップS920において記録先ディレクトリの最大ファイル数を超過する場合には、ステップS930にて記録先ディレクトリ下のイベントの情報のログファイル中で最も作成日時が古いファイルを削除する。そして、ステップS921,S911にて新規イベントの情報のログファイルを作成し、その新規イベントの情報のログファイルにイベントの情報を追記する。
【００２４】
本実施例に示す方法によれば、各記録先ディレクトリ以下に記録されるイベントの情報の合計データサイズ、すなわち最大ファイルサイズと最大ファイル数の積が所定サイズ以上にならないように制御することが可能である。更に記録先ディレクトリ毎にファイルの最大ファイルサイズや最大ファイル数を規定することにより、イベントの特性に応じた記録制御が可能となる。例えば、頻繁に発生するイベントの場合には、イベントの情報のログファイルの作成・削除処理が性能上問題となる可能性があるため、イベントの情報のログファイルの最大ファイルサイズを比較的大きくすることが望ましいと考えられる。一方、最大ファイルサイズを大きくしたことにより最大ファイル数があまりに少なくなった場合には、ステップS930でイベントの情報のログファイルを削除する際に消失する情報の内容が増加する。本実施例ではこれらに代表される諸条件を踏まえた上で管理テーブルの設定が可能となり、特性の異なる多種多様なイベントに応じて柔軟に対応することができる。
また、上述したように、イベント種別毎にイベントの情報のログファイルの記録先ディレクトリを変更可能とすることで、機器にとって重要なイベントを他のイベントと隔離して記録することが可能となる。このため、管理サーバに接続不可能な状態で機器が運用され続けても、重要なイベントが他のイベントの発生により消失することを抑止できる。
加えて、新規なイベントの情報をメッセージバッファ520に記録する際に、既に記録されているイベントの情報を読み出して走査する必要はなく、特定のログファイルにデータを書き込む処理となるため、比較的高速に処理が行える利点がある。
【実施例２】
【００２５】
実施例１では、重要なイベントの情報を保全しつつ、ネットワーククライアントの記録領域の消費を低減することができることを説明した。
実施例１においては、イベントの情報をメッセージバッファ520に記録する際に、表１に示す管理テーブルをネットワーククライアントが使用し、重要なイベントの情報についてはイベント種別毎に専用のディレクトリを用いることとした。
実施例２は、イベント種別毎に優先度を設定し、該優先度毎に専用のディレクトリを用い、該ディレクトリに記録対象のイベント種別を割り当てるよう管理テーブルで管理するものである。上記構成により、記録領域の消費を低減するとともに、監視すべきディレクトリの数が削減でき性能の向上を図ることを可能とするものである。
本実施例におけるメッセージバッファ502の管理テーブルを表２に示す。
【表２】
2020071572.tif 000004
【００２６】
表２に示すように、本実施例においては、単一のディレクトリに記録するイベント種別が複数設定可能となっている。例えば、第２優先順位の“secondpriority“というディレクトリには、警告の発生に関する“warning_occurred”とトナー交換に関する“toner_changed“という２種類のイベントが記録される。また、図８に対応するＨＤＤ404内の“messagebuffer”ディレクトリ下の子ディレクトリも、表２に含まれるディレクトリ名称に対応して作成される。
処理フローは、実施例１と同様である。図９のフローチャートで行われる処理のステップS902で用いられる管理テーブルが表２のものを使用する点のみが異なる。
以上説明したように実施例２では、単一のディレクトリに複数のイベント種別のイベントの情報を設定可能とした。これにより、イベント送付部530がログファイルの書き込みをする際、監視すべきディレクトリの数が削減できるため、ソフトウェアの簡素化や、性能の向上を図ることができる。
【実施例３】
【００２７】
実施例１，２では、重要なイベントを保全しつつ、ネットワーククライアントの記録領域の消費を低減することができた。
ところで、ソフトウェアアップデート機能を有するネットワーククライアントでは、出荷された後も必要に応じて機能アプリケーション502に対する機能追加又は削除を行うことが可能である。このようなネットワーククライアントにおいては、出荷・設置後にイベント種別が増減する可能性がある。本実施例では、このような設置後にイベント種別が増減する場合の処理の例に関して説明する。
表３は、実施例１で説明したネットワーククライアントのソフトウェアバージョンアップ後におけるメッセージバッファ520の管理テーブルである。
【表３】
2020071572.tif 000005
【００２８】
ソフトウェアのバージョンアップにより、表３の下線で示した2点が表１と変更されている。
１点目は、イベント種別が、部品交換に関する“parts_chaged”のイベントの情報が記録される “maintenance”ディレクトリが追加されている点である。このディレクトリ追加に伴い、ディレクトリに記録可能なデータサイズが、最大ファイルサイズと最大ファイル数により確保されている。イベント回収部510は、ソフトウェアバージョンアップ後の最初の機器起動時にこの管理テーブル変更が行われたことを検知し、ＨＤＤ404の所定の領域に、“maintenance”ディレクトリを新規作成する。
２点目は、“maintenance”ディレクトリの追加に関連して、“generalevents”ディレクトリに記録可能なデータサイズが削減されている点である。これは、メッセージバッファ520が使用する総計のデータを増加させないために必要である。このような場合、ソフトウェアバージョンアップ後の最初の起動時にイベント回収部510は、最初に変更後の管理テーブルにおけるディレクトリ以下の記録可能なデータサイズの総計(最大ファイルサイズ×最大ファイル数)を計算する。例えば、表3の“generalevents”ディレクトリの場合、約16MBとなる。次に、イベント回収部510は、ＨＤＤ404に既に記録されているイベントの情報のログファイルの総計ファイルサイズを計算する。もし前記総計ファイルサイズが前記記録可能なデータサイズを超過していれば、前記記録可能なデータサイズ以内となるように作成日時が古いほうからイベントの情報のログファイルを削除する。具体的には、変更前と変更後とで、“generalevents”の最大ファイル数のみが減少していた場合には、変更後の最大ファイル数−１になるまで、作成日時が古いログファイルから削除を行う。また、最大ファイル数及び最大ファイルサイズの両方が変更されていた場合には、記録可能なデータサイズの総計が(最大ファイルサイズ×（最大ファイル数−１)）の値になるまで、古いログファイルを削除する。この場合、追加される新規のログファイルは、最大ファイルサイズ以下のものとなる。
以上説明したように、メッセージバッファの管理テーブルに対して、ディレクトリの追加や、それに伴う変更が行われた場合でも対応可能となるため、機器の機能向上に対して柔軟に対応できる。
【実施例４】
【００２９】
実施例１〜２によれば、重要なイベントを保全しつつ、装置の記録領域の消費を低減することができ、さらに実施例３によれば、ソフトウェアアップデートにより機器の機能が追加された場合でも、イベントの情報を適切に管理できた。
ところで、機器の故障やソフトウェアの不具合により、結果としてログが不要なイベントが大量に発生する場合がある。例えば、機器に備え付けられている温度センサが故障することにより、機器温度が異常である旨のイベントを連続して検知する可能性がある。また、ソフトウェアの不具合により、一度しか発生していないエラーが複数回発生したかのように誤認する可能性もある。これらのような状態の場合、同一もしくは類似のイベントが大量に発生してしまうため、本来把握すべき重要なイベントがメッセージバッファ520から削除されてしまう可能性がある。
実施例４では、このような場合に備え、想定以上の頻度で特定のイベントが発生した場合に該イベントの記録を停止する方法について説明する。
表４は実施例４で使用するメッセージバッファの管理テーブルである。
【表４】
2020071572.tif 000006
【００３０】
本実施例で使用される表４の管理テーブルでは、ディレクトリ名称毎に“最大頻度”を管理するための列が追加されている。この列の数値は、ディレクトリに記録されるイベントの発生が想定される最大の頻度を示している。例えば、表4の記載によれば“maintenance”ディレクトリには50msという数値が指定されている。これは部品の交換イベントである“parts_changed”イベントが、最も頻繁に発生したとしても50ms以上の間隔を空けて発生することを示している。
【００３１】
上記の管理テーブルの情報に対応したイベントの情報をメッセージバッファに記録する処理について図１０に沿って説明する。本処理は、実施例１で示した図９のフローチャートに以下の2つのステップを追加したのもので、以下ではその差異の部分について説明し、同じ部分については説明を省略する。なお、図１０中、実施例１（図９）と同じステップには、同じ符号を用いている。
ステップS901のイベントの情報の種別を判別する処理に続いて、ステップS1001に進む。S1001では、S901で判別されたイベント種別に対応したイベント最終追記時刻をＲＡＭ403から読み出し、現在時刻と比較し、その時間間隔が管理テーブルの“最大頻度”以内か否かを判断する。
“最大頻度”以内である場合(S1001でyes)には、後続の処理を行わず、フローチャートの処理を終了する。
一方、“最大頻度”以内でない場合(S1001でno)には、S902に進み以降の処理を行う。
ステップS911のイベントの情報のログファイルにイベントの情報を追記する処理に続いて、ステップS1002では、現在時刻を、イベント種別毎にイベント最終追記時刻としてＲＡＭ403に記憶し、本処理を終了する。
以上で説明したように、実施例４によれば、イベント発生の頻度を加味することにより、不要であると思われるイベントを記録することにより本来必要なイベントが削除されることを抑止することができる。
【００３２】
(その他の実施例) 
本発明は、上述の実施形態の1以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける1つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、1以上の機能を実現する回路(例えば、ＡＳＩＣ)によっても実現可能である。
【図１】
2020071572.tif 000007
【図２】
2020071572.tif 000008
【図３】
2020071572.tif 000009
【図４】
2020071572.tif 000010
【図５】
2020071572.tif 000011
【図６】
2020071572.tif 000012
【図７】
2020071572.tif 000013
【図８】
2020071572.tif 000014
【図９】
2020071572.tif 000015
【図１０】
2020071572.tif 000016