JP3376760B2

JP3376760B2 - 被管理機器のログ取得方式

Info

Publication number: JP3376760B2
Application number: JP13172095A
Authority: JP
Inventors: 芳裕竹下
Original assignee: Fuji Xerox Co Ltd; Fujifilm Business Innovation Corp
Current assignee: Fujifilm Business Innovation Corp
Priority date: 1995-05-30
Filing date: 1995-05-30
Publication date: 2003-02-10
Anticipated expiration: 2018-02-10
Also published as: JPH08328970A

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は被管理機器のログ取得方
式に関し、特にネットワークを介して管理マネージャに
接続されている被管理機器の内部で発生のログを取得す
る被管理機器のログ取得方式に関する。

【０００２】

【従来の技術】従来、ネットワークを介して管理マネー
ジャおよび被管理機器が接続されて構成されるシステム
において、被管理機器にてエラーが発生すると、その都
度、エラー情報がロギングされる。被管理機器内のメモ
リの制約上、機器が保持できるログの数には制限があ
り、一定件数（最大ログ数）を越えては保持できない。
このため、メモリが一杯になる前にログを管理マネージ
ャに転送して、被管理機器で発生したエラー情報を管理
マネージャの記憶媒体に記憶・保存するようにしてい
る。

【０００３】被管理機器から管理マネージャへエラー情
報を通知する方式としては、たとえば、特開平３−１９
５１４２号公報にその一例が載っている。この公報によ
れば、伝送装置において発生した障害情報を保持してお
いて、一定件数の障害が発生した場合、あるいはそれ以
前の通知から一定時間が経過した場合に、保持しておい
た障害情報を、伝送路で接続された別の伝送装置にひと
まとめにして通知する方式が記載されている。

【０００４】

【発明が解決しようとする課題】しかし、上述の特開平
３−１９５１４２号公報に開示されているように、一定
件数の障害が発生した場合、あるいは以前の通知から一
定時間経過した場合に、保持しておいた障害情報をまと
めて別の伝送装置へ転送する方式では、たまたま障害情
報転送時に転送先装置および伝送路に何らかの障害が発
生していた場合には、転送元の装置が再度転送を行わな
い限り、障害情報が消失してしまう可能性があるという
問題点があった。

【０００５】本発明はこのような点に鑑みてなされたも
のであり、被管理機器内のログが所定数に達してログを
管理マネージャへ転送する必要が発生した時点で、管理
マネージャの停止または障害、またはネットワークにお
ける障害のために、ログが所定数に達していることの通
知も、ログの転送もすることができない場合に、被管理
機器内のログを失うことなく管理マネージャの記憶媒体
へ記録することができるようにする被管理機器のログ取
得方式を提供することを目的とする。

【０００６】

【課題を解決するための手段】本発明では上記課題を解
決するために、ネットワークを介して管理マネージャに
接続されている被管理機器の内部で発生のログを取得す
る被管理機器のログ取得方式において、管理マネージャ
にて被管理機器に蓄積されているログを取得するための
タイミングを認識してログ取得トリガを出力するログ取
得時期認識手段（１１）と、前記ログ取得時期認識手段
によるログ取得トリガの出力に応答して、前記被管理機
器に蓄積されているログを収集し保存するログ取得実行
手段（１２）と、を備えていることを特徴とする被管理
機器のログ取得方式が提供される。

【０００７】

【作用】上述の手段によれば、ログ取得時期認識手段
（１１）が被管理機器に蓄積されているログを取得する
ためのタイミングを、たとえば被管理機器からログフル
通知を受けることにより、またはネットワークあるいは
管理マネージャの障害復帰時に認識すると、ログ取得の
ための処理が開始される。被管理機器に蓄積されている
ログはログ取得実行手段（１２）によって取得される。
これにより、被管理機器からネットワークあるいは管理
マネージャの状態に関係なくログを一方的に送り付ける
のではなく、管理マネージャの側からログを取りに行く
ようにしたので、被管理機器から管理マネージャにログ
フル通知をしたときに、ネットワークあるいは管理マネ
ージャに障害が発生していたとしても、障害が回復して
からログを取得することができ、管理マネージャは確実
にログを取得してその記録媒体に保存していくことが可
能になる。

【０００８】

【実施例】以下、本発明の一実施例を図面に基づいて説
明する。図１は本発明の被管理機器のログ取得方式の構
成を示す図である。

【０００９】本発明を実施するネットワークシステム
は、管理マネージャ１０と、ネットワーク２０と、被管
理機器３０とによって構成されている。本発明の被管理
機器のログ取得方式は、管理マネージャ１０の側にて、
ログ取得時期認識手段１１と、ログ取得実行手段１２
と、トラップインターバル設定手段１３と、管理マネー
ジャアドレス設定手段１４とから構成される。この管理
マネージャ１０の側の構成に対して、被管理機器３０で
は、ログがあらかじめ定められた一定値を越えて登録さ
れたときにログフル通知を行うログフル通知手段３１
と、蓄積されていたログを管理マネージャ側へ送信する
ログ送信手段３２と、管理マネージャ１０のトラップイ
ンターバル設定手段１３からの設定変更要求に応じてト
ラップインターバルの値を変更するトラップインターバ
ル変更手段３３と、管理マネージャ１０の管理マネージ
ャアドレス設定手段１４からの設定変更要求に応じてロ
グフル通知の通知先管理マネージャを登録する管理マネ
ージャアドレス登録手段３４とから構成されている。

【００１０】上記の構成において、被管理機器３０内で
発生したログはそのメモリに順次ロギングされ、ログの
数がトラップインターバル変更手段３３によって設定さ
れている値を越えたときに、ログフル通知手段３１によ
り管理マネージャ１０に対してログフル通知が行われ
る。管理マネージャ１０のログ取得時期認識手段１１は
被管理機器３０からのログフル通知を受けると、ログ取
得実行手段１２を起動し、ログ取得実行手段１２は被管
理機器３０に対してログ取得要求を出す。これに応え
て、被管理機器３０のログ送信手段３２は未送信分のロ
グを管理マネージャ１０へ送信する。ログ取得実行手段
１２は送信されたログをハードディスクなどの記録媒体
に格納し、保存する。

【００１１】管理マネージャ１０のログ取得時期認識手
段１１はまた、ネットワーク２０または管理マネージャ
１０に障害が発生していてこれらが回復したとき、ある
いは管理マネージャ１０がその停止状態から立ち上がっ
たときにも、その旨を認識する。ログ取得時期認識手段
１１は障害回復を認識すると、障害発生中に、被管理機
器３０からログフル通知があったかもしれないので、ロ
グ取得実行手段１２を起動して、被管理機器３０に蓄え
られているログを取得するようにする。これにより、ロ
グフル通知を正常に受信したときはもちろん、ログフル
通知を正常に受信できなかったときにも、被管理機器３
０のログをもれなく管理マネージャ１０の記録媒体に記
録しておくことが可能になる。

【００１２】好適な実施例では、管理マネージャ１０は
ネットワーク管理システム、被管理機器３０はプリンタ
とすることができ、図示はしないが、これらを結ぶネッ
トワーク２０にはプリンタを利用するための複数のコン
ピュータ、文書処理装置などが接続される。

【００１３】図２はトラップインターバル値変更処理を
示すフローチャートである。被管理機器３０では、ログ
が一定数ロギングされたときにログフルになったことを
ログフル通知手段３１により管理マネージャ１０に対し
て通知する。発生したログを保存しておくメモリは、そ
の容量の制約から、ロギングできる最大数が決められ
る。ログフル通知は、その最大数より少ないある一定数
のログが保存されたときに、管理マネージャ１０に対し
て行われる。前回のログフル通知というトラップが上が
ってから次にログフル通知のトラップが上がるまでのロ
グ数をトラップインターバルという。このトラップイン
ターバルの値は被管理機器３０がそれぞれある値を規定
値として持っているが、ログ取得要求に対する被管理機
器３０のレスポンス、メモリの容量、すなわち、保持で
きる最大ログ数やログ発生頻度などを考慮して、管理マ
ネージャ１０側からトラップインターバルの値を変更で
きるようにしている。トラップインターバルの値の変更
は、管理マネージャ１０のトラップインターバル設定手
段１３および被管理機器３０のトラップインターバル変
更手段３３によって、実行される。

【００１４】図示のフローチャートにおいて、まず、管
理マネージャ１０側から設定変更の要求があると（ステ
ップＳ１１）、被管理機器３０のトラップインターバル
変更手段３３では、トラップインターバル値として正し
いかどうかが判断される（ステップＳ１２）。つまり、
通知された値がその被管理機器３０がログ保存用として
持っているメモリの容量から決められる最大ログ数以下
かどうかが判断され、ここで、通知された値がトラップ
インターバル値として取り得る値でないと判断される
と、値の変更を行うことなくそのまま終了し、取り得る
値であると判断されると、その値に変更する処理が行わ
れる（ステップＳ１３）。

【００１５】図３は管理アドレスの設定処理の流れを示
すフローチャートである。被管理機器３０はログがある
一定数以上保存されると、ログフルになったことを管理
マネージャ１０に通知するが、管理マネージャ１０が複
数存在するような場合にはどの管理マネージャに通知す
るかを被管理機器３０にて設定することができる。この
通知先の管理マネージャの設定も管理マネージャ側から
設定することができ、管理マネージャ１０の管理マネー
ジャアドレス設定手段１４および被管理機器３０の管理
マネージャアドレス登録手段３４によって実行される。

【００１６】図示のフローチャートによれば、管理マネ
ージャ１０からの要求があると（ステップＳ２１）、被
管理機器３０の管理マネージャアドレス登録手段３４
は、その要求が、通知先として新たに登録したいのか、
登録を削除したいのか、または登録を変更したいのかを
判断する（ステップＳ２２）。管理マネージャ１０から
の要求が登録と判断されると、管理マネージャアドレス
の登録処理が行われ（ステップＳ２３）、削除と判断さ
れると、管理マネージャアドレスの削除処理が行われ
（ステップＳ２４）、変更と判断されると、管理マネー
ジャアドレスの変更処理が行われる（ステップＳ２
５）。

【００１７】図４はログ取得を開始するかどうかの判断
処理のフローチャートである。管理マネージャ１０から
被管理機器３０に保存されているログを取得する場合
は、その契機として、管理マネージャ１０はそのログ取
得時期認識手段１１により事象の変化を監視する（ステ
ップＳ３１）。ここで、被管理機器３０からのログフル
のトラップを受信したか（ステップＳ３２）、管理マネ
ージャ１０の立ち上がりか（ステップＳ３３）、ネット
ワーク障害からの回復か（ステップＳ３４）のいずれか
が検出されると、ログ取得トリガを発生し（ステップＳ
３５）、いずれの事象変化も検出されないと、ログ取得
トリガは発生しない。次に、ログ取得トリガが発生した
かどうか判断され（ステップＳ３６）、ログ取得トリガ
が発生しなければ、ステップＳ３１に戻り、ログ取得ト
リガが発生すれば、この処理フローチャートは終了し、
これがログ取得の契機となる。

【００１８】図５はログフル通知処理のフローチャート
である。被管理機器３０内にてログが発生し、ログデー
タがメモリに保存されると（ステップＳ４１）、前回ロ
グフル通知を行ってから最新ログが発生した時点までに
蓄積されたログ数を算出する（ステップＳ４２）。次
に、登録されているトラップインターバル値と算出され
たログ数とを比較して算出値がトラップインターバル値
より大きいかどうかを判断する（ステップＳ４３）。こ
こで、算出値がトラップインターバル値より大きくない
と判断されれば、この処理はそのまま終了し、大きいと
判断されれば、「ログフル時のログＩＤ」をその時の最
新ログＩＤに更新する（ステップＳ４４）。ログＩＤは
その被管理機器３０の使用開始時から発生したログに対
して一意に与えられるもので、ログフルのトラップが上
がる毎に、「ログフル時のログＩＤ」はそのログＩＤに
変更される。この「ログフル時のログＩＤ」はステップ
Ｓ４２のログ数の算出に使用される値である。そして、
「ログフル時のログＩＤ」が書き換えられると、管理マ
ネージャ１０に対してログフルのトラップを送信して、
この処理を終了する（ステップＳ４５）。

【００１９】図６はネットワーク障害からの回復処理を
示すフローチャートである。管理マネージャ１０では、
ログ取得時期認識手段１１が被管理機器３０に対して定
期的にアクセスし（ステップＳ５１）、ここでアクセス
エラーが起きるかどうかを判断する（ステップＳ５
２）。アクセスエラーが起きなければ、ステップＳ５１
に戻って次のアクセスに備え、アクセスエラーが起きれ
ば、ネットワークに障害が発生したとする（ステップＳ
５３）。次に、再び、被管理機器３０に対して定期的な
アクセスをし（ステップＳ５４）、アクセスエラーがあ
るかどうかを判断する（ステップＳ５５）。ここで、ア
クセスエラーがあれば、ステップＳ５４に戻って次のア
クセスに備え、アクセスエラーがなくなると、ネットワ
ーク障害が回復したものとする（ステップＳ５６）。こ
のネットワーク障害回復を検出して、管理マネージャ１
０は被管理機器３０に対してログ取得を要求する契機と
する。

【００２０】図７は管理マネージャの具体的な構成例を
示す図である。この構成例によれば、管理マネージャ
は、被管理機器からログフル通知を受けてログ取得トリ
ガを発生するログ取得トリガ発生部１０１を備えてい
る。このログ取得トリガ発生部１０１には、この管理マ
ネージャが起動したときに、管理マネージャが正常に立
ち上がったことを通知する管理マネージャ立ち上げ通知
部１０２と、ネットワークに障害が発生したかどうかを
監視して障害が回復したときにその通知を行うネットワ
ーク障害回復通知部１０３とが接続されており、これら
管理マネージャ立ち上げ通知部１０２またはネットワー
ク障害回復通知部１０３からの通知があった場合にも、
ログ取得トリガ発生部１０１はログ取得トリガを発生す
る。ログ取得トリガ発生部１０１の出力には、発生され
たログ取得トリガを受けるようにログ取得実行部１０４
が接続されている。ログ取得実行部１０４は、被管理機
器に対してログ取得を要求し、これに応答して被管理機
器からログが転送されてくると、その転送されたログを
記録保存するためのハードディスク１０５が接続されて
いる。管理マネージャは、さらに、被管理機器に対して
トラップインターバル値の設定・変更を要求するトラッ
プインターバル変更要求部１０６と、被管理機器に対し
てログフルの通知先を設定要求する管理マネージャアド
レス設定要求部１０７とを備えている。

【００２１】図８は被管理機器の具体的な構成例を示す
図である。ここに例示した被管理機器は、管理マネージ
ャに対してログフル通知を行うログフル通知部２１０
と、この被管理機器で発生したログや管理マネージャ側
からの要求によって設定・登録された値などのデータを
記憶するデータ記憶部２２０と、管理マネージャからの
要求によってデータ記憶部２２０に保持されているログ
データを転送するログ送信部２３０と、管理マネージャ
からの要求によりトラップインターバルの値を変更する
トラップインターバル値変更部２４０と、管理マネージ
ャからの要求により通知先管理マネージャの登録・削除
・変更を行う管理マネージャアドレス登録部２５０とか
ら構成されている。

【００２２】データ記憶部２２０は、ログが発生する毎
にログＩＤが付けられて格納されるログデータ記憶部２
２１と、ログフル通知を行ったときのログＩＤを格納す
るログフル時のログＩＤ記憶部２２２と、トラップイン
ターバル値変更部２４０により変更された値が格納され
るトラップインターバル値記憶部２２３と、管理マネー
ジャアドレス登録部２５０より登録された値が格納され
る管理マネージャアドレス記憶部２２４とを有してい
る。ログデータ記憶部２２１は、保存できる最大ログ数
を越えてさらにログが発生すると、そのログは最も古い
ログＩＤの領域に上書き（ラップアップ）される構成に
なっている。

【００２３】ログフル通知部２１０は、ログデータ記憶
部２２１の最新ログＩＤ、ログフル時のログＩＤ記憶部
２２２に格納されている前回通知のログフル時のログＩ
Ｄ、トラップインターバル値記憶部２２３のトラップイ
ンターバル値、および管理マネージャアドレス記憶部２
２４の管理マネージャアドレスを参照してログフルかど
うかを判断するログフル判断部２１１を有している。

【００２４】上述した図７の管理マネージャおよび図８
の被管理機器の構成をもとに、これらの動作について、
以下のフローチャートに従って説明する。図９は管理マ
ネージャ側および被管理機器側におけるログ取得処理を
示すフローチャートである。

【００２５】まず、管理マネージャ側において、ログ取
得トリガ発生部１０１は被管理機器からのログフル通
知、管理マネージャ立ち上げ通知部１０２からの通知、
またはネットワーク障害回復通知部１０３からの通知を
受けると、ログ取得トリガを発生する（ステップＳ６
１）。すると、ログ取得実行部１０４は、前回最後に転
送されたログのログＩＤ（Ｎ）をもとに被管理機器に対
してログＩＤ（Ｎ）以降のログの取得を要求し（ステッ
プＳ６２）、ログデータ受信待ちに入る（ステップＳ６
３）。

【００２６】一方、被管理機器側では、管理マネージャ
からのログ取得要求を受けると（ステップＳ６４）、ロ
グＩＤ（Ｓ）の「Ｓ」に「Ｎ」を代入する（ステップＳ
６５）。前回のログ転送で最後に転送されたのはログＩ
Ｄ（Ｎ）のログであるので、これから送信しようとする
ログはその次のログＩＤのログからとなる。したがっ
て、ここで、「Ｓ」の値を１つ増やし（ステップＳ６
６）、そのログＩＤのログデータをログデータ記憶部２
２１を参照してログ送信部２３０により管理マネージャ
へ送信する（ステップＳ６７）。このとき、管理マネー
ジャ側では、データ受信待ちの状態になっているので、
被管理機器側からログデータが送信されてくると、ログ
取得実行部１０４にてそのログデータを取得し、ハード
ディスク１０５に記録保持する（ステップＳ６８）。

【００２７】被管理機器側では、あるログＩＤのログデ
ータの送信が終了すると、今、送信したログデータは最
新ログＩＤを有するデータかどうかを判断し（ステップ
Ｓ６９）、最新ログデータでなければ、ステップＳ６６
に戻って、次のログＩＤを有するログデータが送信処理
されることになる。送信したログデータが最新のもので
あれば、管理マネージャに対してログデータ終了を送信
し、被管理機器側でのログ取得処理を終了する（ステッ
プＳ７０）。管理マネージャ側では、ログデータ終了の
通知を受けると、今回のログの取得処理は終了すること
になる（ステップＳ７１）。このステップＳ７１にて、
ログデータ終了が通知されなければ、ステップＳ６３に
戻って、次のログデータの受信待ちとなる。

【００２８】ここで、具体的な例を挙げて説明すると、
データ記憶部２２０のログデータ記憶部２２１はたとえ
ば５０個のログを保存することができ、トラップインタ
ーバル値記憶部２２３に設定されているトラップインタ
ーバル値は４０であるとする。ログＩＤは、最初は
「０」から始まってログが発生する毎に１つずつ増えて
いくものとし、ログフル時のログＩＤ記憶部２２２には
最初「０」が入っているものとする。また、管理マネー
ジャのハードディスク１０５には、この被管理機器のロ
グはまだ記録されていないので、ログＩＤはない。

【００２９】ログが蓄積されていって、ログＩＤが４０
のログが発生されると、ログデータ記憶部２２１には４
１個のログデータが蓄積されたことになり、蓄積された
ログ数がトラップインターバル値より大きくなる。この
時点で、ログフル時のログＩＤ記憶部２２２の値は「４
０」に変更され、ログフルのトラップが管理マネージャ
に上がり、管理マネージャはログデータの取得を開始す
る。このとき、管理マネージャ側にはログデータの記録
はないので、管理マネージャからのログ取得要求はすべ
てのログデータとなる。被管理機器のログ送信部２３０
はログＩＤが「０」のログから管理マネージャへ順次送
信し、ログＩＤが４０のログまで送信する。送信された
ログは管理マネージャのハードディスクに格納される。

【００３０】引き続き、ログが発生すると、今度はログ
ＩＤ＝４１のログからログデータ記憶部２２１に保持さ
れていく。ログＩＤ＝４９のログが保持されてログデー
タ記憶部２２１が一杯になると、この次に発生したログ
ＩＤ＝５０のログはログＩＤ＝０の最古のログ記憶位置
に上書き保持される。このようにして、ログＩＤ＝８０
のログが保持されると、前回のログフル通知から新たに
蓄積されたログの数はトラップインターバル値の４０に
等しくなり、次のログＩＤ＝８１のログが発生すると、
ログフル時のログＩＤ記憶部２２２の値は「８１」に変
更され、ログフルのトラップが管理マネージャに上が
る。すると、管理マネージャはハードディスクに記録さ
れているログの中で最新のログのログＩＤ＝４０ととも
に被管理機器側へログ取得要求を出す。被管理機器側で
は、通知されたログＩＤの次のログＩＤ＝４１のログか
ら管理マネージャ側へ順次送信する。ログＩＤ＝８１の
ログを送信するとログ転送の終了となる。

【００３１】同様にして、次に発生したログは、ログＩ
Ｄ＝８２からログデータ記憶部２２１へ順次保持されて
いき、ログフルになると、管理マネージャから前回ログ
フル時のログＩＤ以降の被管理機器内のログをすべて取
得するという処理が繰り返される。また、ログフル通知
時に加えて、管理マネージャが立ち上がったとき、ある
いはネットワーク障害が回復したときにも、管理マネー
ジャはログフル通知時と同じログ取得処理が行われる。

【００３２】次に、管理マネージャの性能を考えると、
管理マネージャのログ取得要求に対する被管理機器のレ
スポンスが早い場合と遅い場合とが考えられる。管理マ
ネージャのログ取得要求に対するレスポンスが早い場合
には、ログフルの通知が上がってから管理マネージャが
ログをハードディスクに記録するまで少ない時間で記録
できるので、トラップインターバル値は機器が保持でき
る最大ログ数に近い値でよい。ところが、管理マネージ
ャのログ取得要求に対するレスポンスが遅い場合には、
ログフルの通知が上がってから管理マネージャがログを
ハードディスクに記録するまで時間がかかってしまう。
したがって、ログフル通知から管理マネージャにてログ
が記録されるまでの間に、被管理機器において、新たに
発生したログにより未転送ログが上書きされてしまうの
で、まだハードディスクに記録していないログが被管理
機器のログデータ記憶部２２１から消失してしまわない
ようにすることが必要である。このような状況を避ける
ため、管理マネージャはログ取得レスポンスを考慮し
て、被管理機器のトラップインターバル値を最適な値に
変更することができ、トラップインターバル値は図２に
示したフローチャートに従って変更される。

【００３３】図１０は被管理機器のログ取得方式の別の
構成例を示す図である。図示の構成例によれば、第１管
理マネージャ３００および第２管理マネージャ４００は
ネットワーク５００を介して第１ないし第４被管理機器
６００，７００，８００，９００に接続されている。第
１管理マネージャ３００および第２管理マネージャ４０
０はそれぞれログを記録するハードディスク３１０およ
び４１０を備え、第１ないし第４被管理機器６００〜９
００はそれぞれ管理マネージャアドレス記憶部６１０，
７１０，８１０，９１０を備えている。また、第１管理
マネージャ３００には、ハードディスク３１０の空き容
量を監視して、空き容量がなくなった場合に、第１ない
し第４被管理機器６００〜９００で発生したログの管理
を別の管理マネージャに移管する処理を行うログ取得切
り替え部３２０を有している。

【００３４】ここで、第１ないし第４被管理機器６００
〜９００は第１管理マネージャ３００によって管理され
ているとする。したがって、第１ないし第４被管理機器
６００〜９００の管理マネージャアドレス記憶部６１
０，７１０，８１０，９１０には、ログフル通知先の管
理マネージャとして、第１管理マネージャ３００のアド
レスがそれぞれ登録されているとする。このため、第１
ないし第４被管理機器６００〜９００にてログが発生す
ると、ログはそれぞれのログデータ記憶部に保持されて
いき、ログフルになると、第１管理マネージャ３００の
ハードディスク３１０へ転送されて記録される。

【００３５】第１管理マネージャ３００のログ格納用の
ハードディスク３１０が一杯になると、ログ取得切り替
え部３２０はこれを検出してログの管理を第２管理マネ
ージャ４００に移すようにする。このとき、ハードディ
スク３１０には、第１被管理機器６００のログがログＩ
Ｄ＝Ｎのログまで記録され、第２被管理機器７００のロ
グがログＩＤ＝Ｍのログまで記録され、第３被管理機器
８００のログがログＩＤ＝Ｌのログまで記録され、第４
被管理機器９００のログがログＩＤ＝Ｋのログまで記録
されているとする。

【００３６】ログ取得切り替え部３２０は、まず、管理
マネージャアドレス設定要求部により、第１ないし第４
被管理機器６００〜９００に対して、それらの管理マネ
ージャアドレス記憶部６１０，７１０，８１０，９１０
に設定されているログフル通知先を第１管理マネージャ
３００から第２管理マネージャ４００へ変更し、第２管
理マネージャ４００に対して、ログ取得時に必要な開始
ログＩＤを通知する。すなわち、ハードディスク３１０
に記録された最終記録ログのログＩＤが通知され、第１
被管理機器６００のログＩＤ＝Ｎ、第２被管理機器７０
０のログＩＤ＝Ｍ、第３被管理機器８００のログＩＤ＝
Ｌ、および第４被管理機器９００のログＩＤ＝Ｋが通知
される。

【００３７】ここで、被管理機器側にてログフルのトラ
ップが上がると、今度は第２管理マネージャ４００がそ
のトラップを認識してログ取得処理を開始する。第２管
理マネージャ４００のハードディスク４１０には、第１
被管理機器６００についてはログＩＤ＝Ｎ＋１、第２被
管理機器７００についてはログＩＤ＝Ｍ＋１、第３被管
理機器８００についてはログＩＤ＝Ｌ＋１、および第４
被管理機器９００についてはログＩＤ＝Ｋ＋１のログか
ら記録開始される。

【００３８】これにより、１つの管理マネージャにおけ
るログ記録領域が一杯になっても、ログ記録を一時的に
他の管理マネージャに移管することで、ログ記録を継続
することができる。

【００３９】

【発明の効果】以上説明したように本発明では、被管理
機器からログフル通知があった場合、管理マネージャが
立ち上がった場合、あるいはネットワーク障害が回復し
た場合には、ログ取得を管理マネージャから取得しにい
くように構成した。このため、被管理機器のログフル通
知があった場合に、管理マネージャがこの通知を認識す
ることができない状態にあっても、ログ取得可能状態に
なったときに、管理マネージャの方からログを取得しに
いくので、被管理機器に蓄積されていたログが取得され
ずに上書きによって失われることがなくなる。

【図面の簡単な説明】

【図１】本発明の被管理機器のログ取得方式の構成を示
す図である。

【図２】トラップインターバル値変更処理を示すフロー
チャートである。

【図３】管理アドレスの設定処理の流れを示すフローチ
ャートである。

【図４】ログ取得を開始するかどうかの判断処理のフロ
ーチャートである。

【図５】ログフル通知処理のフローチャートである。

【図６】ネットワーク障害からの回復処理を示すフロー
チャートである。

【図７】管理マネージャの具体的な構成例を示す図であ
る。

【図８】被管理機器の具体的な構成例を示す図である。

【図９】管理マネージャ側および被管理機器側における
ログ取得処理を示すフローチャートである。

【図１０】被管理機器のログ取得方式の別の構成例を示
す図である。

【符号の説明】

１０管理マネージャ１１ログ取得時期認識手段１２ログ取得実行手段１３トラップインターバル設定手段１４管理マネージャアドレス設定手段２０ネットワーク３０被管理機器３１ログフル通知手段３２ログ送信手段３３トラップインターバル変更手段３４管理マネージャアドレス登録手段

Claims

(57)【特許請求の範囲】

【請求項１】ネットワークを介して管理マネージャに
接続されている被管理機器の内部で発生のログを取得す
る被管理機器のログ取得方式において、管理マネージャにて被管理機器に蓄積されているログを
取得するためのタイミングを認識してログ取得トリガを
出力するログ取得時期認識手段と、前記ログ取得時期認識手段によるログ取得トリガの出力
に応答して、前記被管理機器に蓄積されているログを収
集し保存するログ取得実行手段と、を備え、前記ログ取得時期認識手段は、被管理機器にて発生した
ログの数があらかじめ定められたある一定値を越えた旨
のログフル通知を前記被管理機器より受けたとき、また
は管理マネージャまたはネットワークが、被管理機器に
て発生したログの数があらかじめ定められたある一定値
を越えた旨の通知を受けることができない状態から復旧
したときに、前記ログ取得トリガを出力するように構成
されていることを特徴とする被管理機器のログ取得方
式。
【請求項２】前記ログ取得時期認識手段に対して前記
ログフル通知を行ってから次にログフル通知を行うまで
に蓄積されるログの数、すなわち、前記一定値を変更す
るための要求を、管理マネージャから被管理機器に対し
て行うトラップインターバル設定手段をさらに備えてい
ることを特徴とする請求項１記載の被管理機器のログ取
得方式。
【請求項３】前記ログの数が前記トラップインターバ
ルの値を越えて新たに蓄積されたときに前記ログフルを
通知する相手の管理マネージャを設定するための要求
を、管理マネージャから被管理機器に対して行う管理マ
ネージャアドレス設定手段をさらに備えていることを特
徴とする請求項１記載の被管理機器のログ取得方式。
【請求項４】ある管理マネージャにてログを記録保存
する媒体が一杯になったことに応答して、被管理機器に
設定されたログフル通知先の管理マネージャを前記管理
マネージャアドレス設定手段によりあらかじめ定められ
た管理マネージャに変更するとともに前記あらかじめ定
められた管理マネージャに対して記録しはじめる各被管
理機器のログＩＤを通知するログ取得切り替え手段をさ
らに備えていることを特徴とする請求項３記載の被管理
機器のログ取得方式。