WO2014147699A1

WO2014147699A1 - 管理装置、方法及びプログラム

Info

Publication number: WO2014147699A1
Application number: PCT/JP2013/057613
Authority: WO
Inventors: 史中村; 佐藤　寛子
Original assignee: 富士通株式会社
Priority date: 2013-03-18
Filing date: 2013-03-18
Publication date: 2014-09-25
Also published as: US9811411B2; JP5999254B2; JPWO2014147699A1; US20150378810A1

Abstract

　本管理装置は、情報処理装置が備えるハードウェアの異常を監視する管理装置である。そして、本管理装置は、異常が発生したことを示す通知を情報処理装置から受信した場合に、異常が発生したハードウェアの識別情報が通知に含まれるか判断する第１処理部と、異常が発生したハードウェアの識別情報が通知に含まれないと第１処理部により判断された場合、ハードウェアの識別情報を取得するためのモジュールを実行することを要求する実行要求を情報処理装置に送信する第２処理部と、ハードウェアの識別情報を情報処理装置から受信した場合に、モジュールの実行を停止することを要求する停止要求を情報処理装置に送信する第３処理部とを有する。

Description

管理装置、方法及びプログラム

　ハードウェアを監視する技術に関する。

　コンピュータに異常が発生しないか監視する技術として、以下のような技術が知られている。

　例えば、監視対象の装置において動作するＯＳ（Operating System）上に情報収集のためのプログラムを導入することにより、管理サーバが監視対象の装置の情報を収集するシステムが知られている。このシステムにおいては、管理サーバのメモリにおけるプログラムが、定期的に、監視対象の装置に対して情報収集のためのポーリングを行う。監視対象の装置のメモリにおけるプログラムは、管理サーバからのポーリングがあると、監視対象の装置の状態に関する情報及び性能に関する情報を管理サーバに送信する。

　しかし、このシステムにおいては、監視対象の装置に導入するプログラムがＯＳに依存するため、ＯＳの改版等がある度にプログラムの更新を行うことになり手間がかかる。また、このシステムにおいては、監視対象の装置のメモリにプログラムが常駐することになるため、監視対象の装置に負荷がかかるという問題がある。さらに、特定の仮想化環境においては仮想化により物理情報の取得が困難であると共に、ＯＳベンダのポリシーによってはホストＯＳから取得できる情報が制限される場合がある。

　これに対し、情報収集のためのプログラムを監視対象の装置に導入することなく監視を行えるシステム（以下、エージェントレス型の監視システムと呼ぶ）がある。このシステムにおいては、ジョブ監視サーバにおけるジョブ監視プログラムが、所定時間になると、環境設定情報に基づいて監視対象サーバのジョブログファイルからログを読み込み、監視対象ジョブの状態を判定し、判定結果を中間ログファイルに出力する。さらに、ジョブ監視サーバにおけるログ送信プログラムは、中間ログファイルから所定時間ごとに中間ログを読み出し、通信回線を介して遠隔監視サーバに送信する。

　エージェントレス型の監視システムは、エージェントレス型ではない監視システムの問題を解決できる。しかしながら、上で述べたエージェントレス型の監視システムは、ジョブの開始又は停止の状態を監視するものであり、ハードウェアの監視を行うことはできない。また、ログ送信プログラムは所定時間毎に処理を行うため、リアルタイムで監視を行うことができない。

　以上のように、従来の技術によっては、エージェントレス型の監視システムにおいて、ハードウェアの監視をリアルタイムで行うことはできない。

国際公開第２００９／１４４９６９号パンフレット特開２０１１－１５９０１１号公報

　従って、１つの側面では、本発明の目的は、エージェントレス型の監視システムにおいて、ハードウェアの監視をリアルタイムで行えるようにするための技術を提供することである。

　本発明に係る管理装置は、情報処理装置が備えるハードウェアの異常を監視する管理装置である。そして、本管理装置は、異常が発生したことを示す通知を情報処理装置から受信した場合に、異常が発生したハードウェアの識別情報が通知に含まれるか判断する第１処理部と、異常が発生したハードウェアの識別情報が通知に含まれないと第１処理部により判断された場合、ハードウェアの識別情報を取得するためのモジュールを実行することを要求する実行要求を情報処理装置に送信する第２処理部と、ハードウェアの識別情報を情報処理装置から受信した場合に、モジュールの実行を停止することを要求する停止要求を情報処理装置に送信する第３処理部とを有する。

　エージェントレス型の監視システムにおいて、ハードウェアの監視をリアルタイムで行えるようになる。

図１は、本実施の形態に係るシステム概要を示す図である。図２は、ハードウェアデータ格納部に格納されるデータの一例を示す図である。図３は、フィルタファイル格納部に格納されるデータの一例を示す図である。図４は、判断フラグ格納部に格納されるデータの一例を示す図である。図５は、処理のシーケンス図である。図６は、メインの処理フローを示す図である。図７は、取得処理の処理フローを示す図である。図８は、データ取得ツールにより取得されるデータの一例を示す図である。図９は、データ取得ツールにより取得されるデータの一例を示す図である。図１０は、ユーザ端末への通知に含まれるデータの一例を示す図である。図１１は、コンピュータの機能ブロック図である。

　図１に、本実施の形態に係るシステム概要を示す。本実施の形態における主要な処理を実行する管理ユニット１には、１又は複数のサーバユニット３と、ユーザ端末５とが接続されている。管理ユニット１は、サーバユニット３の監視を行う物理サーバである。サーバユニット３は、業務処理等を実行する物理サーバである。ユーザ端末５は、本実施の形態に係るシステムの管理者が操作する端末である。

　管理ユニット１においては、図示しないＣＰＵ（Central Processing Unit）により、判断部１０２、配置部１０３、削除部１０４及び出力部１０５を含むデータ処理部１０１と、ログ解析部１０９と、ログ取得部１１０とが実行される。ログ格納部１０６と、取得データ格納部１０７と、ハードウェアデータ格納部１０８と、フィルタファイル格納部１１１と、判断フラグ格納部１１２とは、メモリ又はその他の記憶装置に確保される、データを格納するための領域である。

　ログ取得部１１０は、サーバユニット３の状態及び性能等を示すメッセージを、サーバユニット３におけるログ転送部３３から名前付きパイプにより受信し、ログ解析部１０９に出力する。ログ解析部１０９は、ログ取得部１１０から受け取ったメッセージとフィルタファイル格納部１１１に格納されているデータとを用いて、受け取ったメッセージが異常が発生したことを示すメッセージであるか判断する。ログ解析部１０９は、受け取ったメッセージが異常が発生したことを示すメッセージである場合に、そのメッセージをデータ処理部１０１に出力する。

　判断部１０２は、判断フラグ格納部１１２に格納されているデータを用いて、異常が発生したハードウェア（例えばネットワークインタフェースカード又はハードディスク等）の識別情報をサーバユニット３から取得するか判断する。異常が発生したハードウェアの識別情報をサーバユニット３から取得する場合、配置部１０３は、ハードウェアの識別情報を取得するためのモジュールであるデータ取得ツール３１をサーバユニット３に送信し、サーバユニット３に実行させる。ハードウェアの識別情報は、例えば、ハードウェアが接続されるバスの情報或いはベンダの情報等である。削除部１０４は、データ取得ツール３１からハードウェアの識別情報を受信した場合には、ハードウェアの識別情報を取得データ格納部１０７に格納すると共に、送信したモジュールの実行を停止することを要求する停止要求をサーバユニット３に送信する。出力部１０５は、受信したハードウェアの識別情報とハードウェアデータ格納部１０８に格納されているデータとを用いて通知を生成し、ユーザ端末５に送信する。

　サーバユニット３は、ネットワークインタフェースカード又はハードディスク等であるハードウェア３４を有する。サーバユニット３においては、図示しないＣＰＵにより、ログ転送部３３を含むＯＳ３２が実行される。また、サーバユニット３にデータ取得ツール３１が配置された場合には、図示しないＣＰＵにより、データ取得ツール３１が実行される。データ取得ツール３１は常時実行されるわけではないため、図１において点線のブロックで示されている。

　データ取得ツール３１は、ハードウェアの識別情報をハードウェア３４から取得し、管理ユニット１に送信する。ログ転送部３３は、サーバユニット３の状態及び性能等を示すメッセージを、管理ユニット１におけるログ取得部１１０に名前付きパイプにより送信する。ログ転送部３３は、ＯＳ３２が通常有するログ転送機能を実行する処理部であり、例えばＬｉｎｕｘ（登録商標）であればｓｙｓｌｏｇデーモンである。なお、ログ転送部３３は、ハードウェアのドライバからメッセージを受け取った場合に名前付きパイプを用いて直ちにそのメッセージを送信するため、管理ユニット１がサーバユニット３の状態をリアルタイムに把握することが可能である。

　図２に、ハードウェアデータ格納部１０８に格納されるデータの一例を示す。図２に示した例は、ハードウェアがＰＣＩ（Peripheral Component Interconnect）カードである場合の例であり、この場合にはバス番号とＰＣＩカードの搭載位置を示す情報とが対応付けて格納される。

　図３に、フィルタファイル格納部１１１に格納されるデータの一例を示す。図３に示すように、フィルタファイル格納部１１１には正規表現で表されたメッセージのパターンが格納される。ログ解析部１０９は、ログ取得部１１０から受け取ったメッセージがパターンのいずれかに一致した場合に、そのメッセージが異常が発生したことを示すメッセージ（すなわち通報対象のメッセージ）であると判定する。例えば、ログ解析部１０９が「ｅｔｈ０：Ｈａｒｄｗａｒｅ　Ｅｒｒｏｒ」というメッセージを受け取った場合には、「ｅｔｈ［０－９］：Ｈａｒｄｗａｒｅ　Ｅｒｒｏｒ」というパターンと一致するため、異常が発生したことを示すメッセージであると判定する。正規表現で表されたメッセージのパターンは、ハードウェアのドライバが出力するメッセージの各々に対して用意される。

　図４に、判断フラグ格納部１１２に格納されるデータの一例を示す。図４に示した例では、判断フラグ格納部１１２には、メッセージと、フラグとが格納される。判断部１０２は、フラグが「１」である場合にはハードウェアの識別情報を取得するべきメッセージであると判断し、フラグが「０」である場合にはハードウェアの識別情報を取得しなくてもよいメッセージであると判断する。

　次に、図５に示したシーケンス図を用いて、図１に示したシステムの動作の概要を説明する。

　前提として、サーバユニット３におけるハードウェア３４において異常が発生したとする。このような場合、ログ転送部３３は、ハードウェア３４において異常が発生したことを検出し、異常が発生したことを示すメッセージを管理ユニット１におけるログ取得部１１０に名前付きパイプにより転送する。

　ログ取得部１１０は、ログ転送部３３から受け取ったメッセージをログ解析部１０９に出力する。ログ解析部１０９は、ログ取得部１１０から受け取ったメッセージが異常が発生したことを示すメッセージであると判定した場合は、そのメッセージをデータ処理部１０１に出力する。

　データ処理部１０１は、受け取ったメッセージについてハードウェアの識別情報を取得すると判断した場合には、データ取得ツール３１をサーバユニット３のＯＳ上に配置し、サーバユニット３にデータ取得ツール３１を実行させる。データ取得ツール３１は、サーバユニット３においてハードウェアの識別情報の取得に成功した場合に、取得した識別情報を管理ユニット１に送信する。

　管理ユニット１のデータ処理部１０１は、ハードウェアの識別情報を受信した場合に、サーバユニット３におけるデータ取得ツール３１の実行を停止（又は削除）する。データ処理部１０１は、受信したハードウェアの識別情報を含む通知を生成し、ユーザ端末５に送信する。

　以上のようにすれば、ユーザ端末５を操作するユーザは、どのハードウェアにおいて異常が発生したか認識することができるので、ハードウェアの交換等の対応を迅速に行うことができるようになる。

　次に、図６乃至図１０を用いて、図１に示したシステムの動作について詳細に説明する。サーバユニット３におけるログ転送部３３から取得したメッセージが、ログ解析部１０９により、異常が発生したことを示すメッセージであると判定されたとする。すると、ログ解析部１０９は、そのメッセージをデータ処理部１０１に出力する。データ処理部１０１における判断部１０２は、異常が発生したことを示すメッセージを受信する（図６：ステップＳ１）。

　判断部１０２は、異常が発生したハードウェアを特定可能であるか判断する（ステップＳ３）。ステップＳ３の判断は、判断フラグ格納部１１２において、受信したメッセージに対応付けて格納されているフラグが「０」であるか否かにより行う。フラグが「０」であればハードウェアの識別情報がメッセージに含まれ、フラグが「１」であればハードウェアの識別情報がメッセージに含まれない。

　異常が発生したハードウェアを特定可能である場合（ステップＳ３：Ｙｅｓルート）、ステップＳ７の処理へ移行する。一方、異常が発生したハードウェアを特定可能ではない場合（ステップＳ３：Ｎｏルート）、判断部１０２は、取得処理の実行を配置部１０３及び削除部１０４に要求する。これに応じ、配置部１０３及び削除部１０４は、取得処理を実行する（ステップＳ５）。取得処理については、図７乃至図９を用いて説明する。

　まず、配置部１０３は、異常が発生したハードウェアを有するサーバユニット３に、コマンドを用いてデータ取得ツール３１を配置する（図７：ステップＳ２１）。すなわち、管理ユニット１が所持するデータ取得ツール３１のコピーをサーバユニット３に送信し、サーバユニット３における所定の位置に格納させる。なお、上で説明したように、データ取得ツール３１は、ハードウェアの識別情報を取得するためのモジュールである。データ取得ツール３１には、ハードウェアの識別情報を取得するためのコマンド及びＡＰＩ（Application Program Interface）等が登録されている。

　配置部１０３は、サーバユニット３におけるＯＳ３２にｓｓｈ（secure shell）等を用いてリモートログインすると共に（ステップＳ２３）、データ取得ツール３１を実行することを要求する実行要求をサーバユニット３に送信する（ステップＳ２５）。

　サーバユニット３におけるデータ取得ツール３１は、実行要求を受信すると、所定のコマンド及びＡＰＩ等を用いてハードウェア３４の識別情報を取得する。

　ここでは、データ取得ツール３１は、サーバユニット３が有するハードウェアを特定するためのコマンドを実行する。例えば、「♯ｉｆｃｏｎｆｉｇ　－ａ」というコマンドを実行すると、サーバユニット３が有するネットワークインタフェースを特定することができる。図８に、「♯ｉｆｃｏｎｆｉｇ　－ａ」というコマンドを実行した場合に取得されるデータの一例を示す。このようなデータにより、データ取得ツール３１は、サーバユニット３は少なくとも「ｅｔｈ０」というネットワークインタフェースと「ｅｔｈ１」というネットワークインタフェースとを有することがわかる。但し、「ｅｔｈ０」及び「ｅｔｈ１」という名前は、ＯＳ３２が独自に割り振った名前であるため、どのネットワークインタフェースカードのことであるのかユーザは分からない。

　そこで、データ取得ツール３１は、さらにコマンドを実行することにより、サーバユニット３が有するハードウェアの各々について識別情報を取得する。例えば、「♯ｅｔｈｔｏｏｌ　－ｉ　ｅｔｈ０」というコマンドを実行すれば、「ｅｔｈ０」というネットワークインタフェースについてバス情報を取得することができる。図９に示した例は、データ取得ツール３１が「♯ｅｔｈｔｏｏｌ　－ｉ　ｅｔｈ０」というコマンドを実行した場合に得られるデータの一例である。図９における「００００：０１：１０．０」という部分がバス情報であり、このようなバス情報を用いれば、どのネットワークインタフェースにおいて異常が発生したかを特定することができる。

　データ取得ツール３１は、ハードウェアの識別情報を取得すると、管理ユニット１に送信する。

　管理ユニット１のデータ処理部１０１における削除部１０４は、データ取得ツール３１からハードウェアの識別情報を受信したか判断する（ステップＳ２７）。

　ハードウェアの識別情報を取得した場合（ステップＳ２７：Ｙｅｓルート）、削除部１０４は、データ取得ツール３１の実行を停止することを要求する停止要求をサーバユニット３に送信する（ステップＳ３３）。そして元の処理に戻る。これに応じ、サーバユニット３は、データ取得ツール３１の実行を停止する。なお、停止要求に、データ取得ツール３１を削除することを要求する削除要求を含ませるようにしてもよい。その場合には、サーバユニット３は、データ取得ツール３１を削除する。

　一方、ハードウェアの識別情報を取得していない場合（ステップＳ２７：Ｎｏルート）、予め定められたリトライ回数内であるか判断する（ステップＳ２９）。リトライ回数内である場合（ステップＳ２９：Ｙｅｓルート）、リトライするため、ステップＳ２７の処理に戻る。リトライ回数内ではない場合（ステップＳ２９：Ｎｏルート）、データ取得ツール３１は取得に失敗したので、削除部１０４は、取得失敗に関するデータをログ格納部１０６に格納する（ステップＳ３１）。そしてステップＳ３３の処理に移行する。

　取得失敗に関するデータとは、例えば「２０１２／１／１０　１３：３０　Ｗａｒｎｉｎｇ　Ｆａｉｌｅｄ　ｔｏ　ｇｅｔ　ＰＣＩ　ｄｅｖｉｃｅ　ｉｎｆｏｒｍａｔｉｏｎ．」というようなデータである。このデータには、異常の発生日時と、エラーレベル（Ｗａｒｎｉｎｇ、Ｅｒｒｏｒ又はＩｎｆｏｒｍａｔｉｏｎ）と、内容を示すデータとが含まれる。

　以上のような処理を実行すれば、サーバユニット３のＯＳ３２上に常駐のソフトウェアを導入しなくても、ハードウェア３４の識別情報を取得できるようになる。

　図６の説明に戻り、出力部１０５は、取得されたハードウェアの識別情報をキーとして搭載位置を示すデータをハードウェアデータ格納部１０８から抽出し、抽出されたデータを含む通知を生成する（ステップＳ７）。

　図１０に、ユーザ端末５への通知に含まれるデータの一例を示す。図１０に示した例では、元のメッセージに含まれるデータに加えて、エラーレベル（Ｗａｒｎｉｎｇ、Ｅｒｒｏｒ又はＩｎｆｏｒｍａｔｉｏｎ）、エラー番号、ハードウェアの搭載位置を示すデータ、ドライバ名、バス情報、ベンダの識別情報、デバイスの識別情報及び改版番号が含まれる。

　出力部１０５は、生成された通知をユーザ端末５に送信する（ステップＳ９）。そして処理を終了する。

　以上のような処理を実行すれば、異常が発生したハードウェアの識別情報がメッセージに含まれていない場合に限り管理ユニット３においてデータ取得ツール３１が実行され、ハードウェアの識別情報が取得される。これにより、常駐のプログラムをサーバユニット３に導入せずとも、ハードウェアの監視をリアルタイムで行えるようになる。このように、リアルタイムで監視を行えるようになれば、異常の発生に対する対処を迅速に行うことができるようになる。

　また、データ取得ツール３１はサーバユニット３のＯＳ３２に依存しないため、ＯＳ３２の改版に影響を受けることはない。また、データ取得ツール３１はサーバユニット３に常駐するわけではないため、リソースの使用量を抑制できるようになる。

　以上本発明の一実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、上で説明した管理ユニット１及びサーバユニット３の機能ブロック構成は実際のプログラムモジュール構成に一致しない場合もある。

　また、上で説明した各テーブルの構成は一例であって、上記のような構成でなければならないわけではない。さらに、処理フローにおいても、処理結果が変わらなければ処理の順番を入れ替えることも可能である。さらに、並列に実行させるようにしても良い。

　また、データ取得ツール３１を予めサーバユニット３に配置しておき、管理ユニット１が実行要求を送信するだけでハードウェアの識別情報を取得できるようにしてもよい。

　また、データ取得ツール３１から取得したハードウェアの識別情報によってユーザが異常の発生箇所を特定できる場合には、ハードウェアの識別情報をそのままユーザへの通知に含ませるようにしてもよい。

　また、ネットワークインタフェースカードのファームウェア等に異常が発生した場合には、例えば「Ｉｐｆｃ：００００：１ａ：００．０　Ｆａｉｌｅｄ　ｔｏ　ａｌｌｏｃａｔｅ　ｍｅｍｏｒｙ」というようなメッセージがログ転送部３３から出力される。このようにハードウェア自体の異常ではない場合には部品交換を行わなくてもよいので、取得処理を実行せず、異常が発生した箇所をユーザに通知しない。ユーザへの通知には、例えば「Ｗａｒｎｉｎｇ　１２２４２　Ｓｏｆｔｗａｒｅ　Ｉｐｆｃ：００００：１ａ：００．０　Ｆａｉｌｅｄ　ｔｏ　ａｌｌｏｃａｔｅ　ｍｅｍｏｒｙ」のようなデータが含まれる。

　また、例えばＶＭｗａｒｅ等を用いてサーバユニット３上に仮想化環境が実現される場合にも、本実施の形態を適用可能である。このような場合には、管理ユニット１がｓｓｈ等を用いてホストＯＳに対してリモートアクセスすることを許可することにより、サーバユニット３上にデータ取得ツール３１を配置してハードウェアの識別情報を取得することが可能である。

　なお、上で述べた管理ユニット１及びサーバユニット３は、コンピュータ装置であって、図１１に示すように、メモリ２５０１とＣＰＵ（Central Processing Unit）２５０３とハードディスク・ドライブ（ＨＤＤ：Hard Disk Drive）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。ＣＰＵ２５０３は、アプリケーション・プログラムの処理内容に応じて表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、所定の動作を行わせる。また、処理途中のデータについては、主としてメモリ２５０１に格納されるが、ＨＤＤ２５０５に格納されるようにしてもよい。本発明の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及びアプリケーション・プログラムなどのプログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

　以上述べた本実施の形態をまとめると以下のようになる。

　本実施の形態の第１の態様に係る管理装置は、情報処理装置が備えるハードウェアの異常を監視する管理装置である。そして、本管理装置は、（Ａ）異常が発生したことを示す通知を情報処理装置から受信した場合に、異常が発生したハードウェアの識別情報が通知に含まれるか判断する第１処理部と、（Ｂ）異常が発生したハードウェアの識別情報が通知に含まれないと第１処理部により判断された場合、ハードウェアの識別情報を取得するためのモジュールを実行することを要求する実行要求を情報処理装置に送信する第２処理部と、（Ｃ）ハードウェアの識別情報を情報処理装置から受信した場合に、モジュールの実行を停止することを要求する停止要求を情報処理装置に送信する第３処理部とを有する。

　通常のＯＳが有するログの転送機能等によってリアルタイムに転送されるログには、異常が発生したハードウェアの識別情報が含まれないことがあり、その場合にはユーザに異常の発生箇所を通知できない。そこで、上で述べたようにすれば、異常が発生したハードウェアの識別情報が通知に含まれていない場合に限り情報処理装置においてモジュールが実行され、ハードウェアの情報が取得される。これにより、常駐のモジュールを情報処理装置に導入しない、エージェントレス型の監視システムにおいて、ハードウェアの監視をリアルタイムで行えるようになる。

　また、上で述べた第２処理部は、（ｂ１）異常が発生したハードウェアの識別情報が通知に含まれないと第１処理部により判断された場合、モジュールを情報処理装置に送信してもよい。そして、上で述べた停止要求には、モジュールを情報処理装置から削除することを要求する削除要求が含まれるようにしてもよい。このようにすれば、情報処理装置がモジュールを保持しなくてもよいので、記憶装置の使用容量を抑制できるようになる。

　また、本管理装置が、（Ｄ）異常が発生したハードウェアの識別情報が通知に含まれると第１処理部により判断された場合又はハードウェアの識別情報を情報処理装置から受信した場合に、異常が発生したハードウェアの情報を含む通知を生成し、出力する第４処理部をさらに有してもよい。このようにすれば、異常が発生したハードウェアの識別情報をユーザに通知できるようになる。

　本実施の形態の第２の態様に係る管理方法は、情報処理装置が備えるハードウェアの異常を監視する管理装置により実行される管理方法である。そして、本管理方法は、（Ｅ）異常が発生したことを示す通知を情報処理装置から受信した場合に、異常が発生したハードウェアの識別情報が通知に含まれるか判断し、（Ｆ）異常が発生したハードウェアの識別情報が通知に含まれないと判断された場合、ハードウェアの識別情報を取得するためのモジュールを実行することを要求する実行要求を情報処理装置に送信し、（Ｇ）ハードウェアの識別情報を情報処理装置から受信した場合に、モジュールの実行を停止することを要求する停止要求を情報処理装置に送信する処理を含む。

　なお、上記方法による処理をコンピュータに行わせるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブルディスク、ＣＤ－ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。尚、中間的な処理結果はメインメモリ等の記憶装置に一時保管される。

Claims

　情報処理装置が備えるハードウェアの異常を監視する管理装置であって、
　異常が発生したことを示す通知を前記情報処理装置から受信した場合に、前記異常が発生したハードウェアの識別情報が前記通知に含まれるか判断する第１処理部と、
　前記異常が発生したハードウェアの識別情報が前記通知に含まれないと前記第１処理部により判断された場合、前記ハードウェアの識別情報を取得するためのモジュールを実行することを要求する実行要求を前記情報処理装置に送信する第２処理部と、
　前記ハードウェアの識別情報を前記情報処理装置から受信した場合に、前記モジュールの実行を停止することを要求する停止要求を前記情報処理装置に送信する第３処理部と、
　を有する管理装置。
　前記第２処理部は、
　前記異常が発生したハードウェアの識別情報が前記通知に含まれないと前記第１処理部により判断された場合、前記モジュールを前記情報処理装置に送信し、
　前記停止要求には、前記モジュールを前記情報処理装置から削除することを要求する削除要求が含まれる
　ことを特徴とする請求項１記載の管理装置。
　前記異常が発生したハードウェアの識別情報が前記通知に含まれると前記第１処理部により判断された場合又は前記ハードウェアの識別情報を前記情報処理装置から受信した場合に、前記異常が発生したハードウェアの情報を含む通知を生成し、出力する第４処理部
　をさらに有する請求項１又は２記載の管理装置。
　情報処理装置が備えるハードウェアの異常を監視する管理装置により実行される管理方法であって、
　異常が発生したことを示す通知を前記情報処理装置から受信した場合に、前記異常が発生したハードウェアの識別情報が前記通知に含まれるか判断し、
　前記異常が発生したハードウェアの識別情報が前記通知に含まれないと判断された場合、前記ハードウェアの識別情報を取得するためのモジュールを実行することを要求する実行要求を前記情報処理装置に送信し、
　前記ハードウェアの識別情報を前記情報処理装置から受信した場合に、前記モジュールの実行を停止することを要求する停止要求を前記情報処理装置に送信する、
　処理を前記管理装置が実行する管理方法。
　情報処理装置が備えるハードウェアの異常を監視する管理装置に実行させるための管理プログラムであって、
　異常が発生したことを示す通知を前記情報処理装置から受信した場合に、前記異常が発生したハードウェアの識別情報が前記通知に含まれるか判断し、
　前記異常が発生したハードウェアの識別情報が前記通知に含まれないと判断された場合、前記ハードウェアの識別情報を取得するためのモジュールを実行することを要求する実行要求を前記情報処理装置に送信し、
　前記ハードウェアの識別情報を前記情報処理装置から受信した場合に、前記モジュールの実行を停止することを要求する停止要求を前記情報処理装置に送信する、
　処理を前記管理装置に実行させるための管理プログラム。