(57)【要約】【課題】リソースの枯渇時におけるイベント通報の実行性を向上させるイベント通報装置およびイベント通報プログラムを提供することを目的とする。【解決手段】監視対象のイベントを検出し、イベント通報を行うイベント通報装置１であって、監視対象のイベントを検出する１つ以上の監視手段１１と、監視手段１１が検出したイベントに基づきイベント通報を行う１つ以上の通報手段１２と、リソースの消費状態に基づいて通常モード及び縮退モードを切り換え、通常モード中に監視手段１１および通報手段１２に対するリソース割当依頼があると、ユーザ空間２００上の共用領域２０２を割り当て、縮退モード中に監視手段１１および通報手段１２に対するリソース割当依頼があると、カーネル空間１００上のプール領域１０２を割り当てるリソース調停手段２０１とを有することにより上記課題を解決する。【選択図】図３
2007257292.tif 000002
【特許請求の範囲】
【請求項１】
監視対象のイベントを検出し、イベント通報を行うイベント通報装置であって、
前記監視対象のイベントを検出する１つ以上の監視手段と、
前記監視手段が検出したイベントに基づきイベント通報を行う１つ以上の通報手段と、
リソースの消費状態に基づいて通常モード及び縮退モードを切り換え、前記通常モード中に前記監視手段および前記通報手段に対するリソース割当依頼があると、ユーザ空間上の共用領域を割り当て、前記縮退モード中に前記監視手段および前記通報手段に対するリソース割当依頼があると、カーネル空間上のプール領域を割り当てるリソース調停手段と
を有することを特徴とするイベント通報装置。
【請求項２】
前記リソース調停手段は、リソースが不足している間、通常モードから縮退モードに切り換えるように、通常モード及び縮退モードを管理する縮退管理手段と、
前記通常モード中に前記リソース割当依頼があると、前記監視手段および前記通報手段が動的に消費するリソースとしてユーザ空間上の共用領域を割り当て、前記縮退モード中に前記リソース割当依頼があると、前記監視手段および前記通報手段が動的に消費するリソースとしてカーネル空間上のプール領域を割り当てるリソース制御手段と
を有することを特徴とする請求項１記載のイベント通報装置。
【請求項３】
前記縮退管理手段は、前記縮退モードに切り換えられた後、前記リソースとしてユーザ空間上の共用領域を割り当てられている前記監視手段が前記イベントを検出すると、前記監視手段および前記通報手段が動的に消費するリソースとしてカーネル空間上のプール領域を割り当てることを特徴とする請求項２記載のイベント通報装置。
【請求項４】
前記縮退管理手段は、前記通常モードに復旧した後、前記監視手段及び前記通報手段が動的に消費するリソースとしてユーザ空間上の共用領域を割り当てることを特徴とする請求項２又は３記載のイベント通報装置。
【請求項５】
記憶装置，演算処理装置を含むイベント通報装置において実行されるイベント通報プログラムであって、
前記記憶装置は、ユーザ空間上の共用領域およびカーネル空間上のプール領域が設けられており、
前記演算処理装置を、
監視対象のイベントを検出する１つ以上の監視手段と、
前記監視手段が検出したイベントに基づきイベント通報を行う１つ以上の通報手段と、
リソースの消費状態に基づいて通常モード及び縮退モードを切り換え、前記通常モード中に前記監視手段および前記通報手段に対するリソース割当依頼があると、ユーザ空間上の共用領域を割り当て、前記縮退モード中に前記監視手段および前記通報手段に対するリソース割当依頼があると、カーネル空間上のプール領域を割り当てるリソース調停手段と
して機能させるためのイベント通報プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、イベント通報装置およびイベント通報プログラムに係り、特に監視対象のイベントを検出し、イベント通報を行うイベント通報装置およびイベント通報プログラムに関する。
【背景技術】
【０００２】
近年、コンピュータはＯＳの機能を利用して、同時に複数のタスクを並行して行うマルチタスク環境をユーザに提供するようになった。マルチタスク環境下では、コンピュータが優先度や公平性をもとにタスクスケジューリングを行っている。
【０００３】
このようなマルチタスク環境下で実行されるタスクの一例としては、例えば監視対象が正常に動作しているか否かを監視する１つ以上の監視タスクと、監視対象が正常に動作しなくなると通報を行う１つ以上の通報タスクとがある。
【０００４】
特許文献１には、ソフトウェアの処理の正常性を監視するソフトウェア監視手段に関する技術が示されている。特許文献２には、監視プロセスから監視対象分、逐次起動される複数の監視スレッドで監視を行うことが示されている。
【特許文献１】特開平７−９８６６７号公報
【特許文献２】特開２００１−５６９４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかし、マルチタスク環境下ではタスクの実行環境（特にリソースの状態）についての配慮が乏しい。例えばタスクの実行中にメモリの枯渇（不足）が発生すると、マルチタスク環境下ではＯＯＭ（アウトオブメモリ）キラーのようにタスクを強制終了させる機能を利用してメモリの枯渇を回避していた。
【０００６】
したがって、上記したような監視タスク及び通報タスクの実行中にリソースの枯渇が発生した場合は、監視タスク及び通報タスクも強制終了される可能性があり、監視対象の異常時に行う通報の実行性が低下するという問題があった。上記のような監視タスク及び通報タスクの役割を考慮すると、リソースの枯渇が発生した場合であっても通報の実行性を低下させない何らかの工夫が望まれていた。
【０００７】
本発明は、上記の点に鑑みなされたもので、リソースの枯渇時におけるイベント通報の実行性を向上させるイベント通報装置およびイベント通報プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記課題を解決するため、本発明は、監視対象のイベントを検出し、イベント通報を行うイベント通報装置であって、前記監視対象のイベントを検出する１つ以上の監視手段と、前記監視手段が検出したイベントに基づきイベント通報を行う１つ以上の通報手段と、リソースの消費状態に基づいて通常モード及び縮退モードを切り換え、前記通常モード中に前記監視手段および前記通報手段に対するリソース割当依頼があると、ユーザ空間上の共用領域を割り当て、前記縮退モード中に前記監視手段および前記通報手段に対するリソース割当依頼があると、カーネル空間上のプール領域を割り当てるリソース調停手段とを有することを特徴とする。
【０００９】
前記リソース調停手段は、リソースが不足している間、通常モードから縮退モードに切り換えるように、通常モード及び縮退モードを管理する縮退管理手段と、前記通常モード中に前記リソース割当依頼があると、前記監視手段および前記通報手段が動的に消費するリソースとしてユーザ空間上の共用領域を割り当て、前記縮退モード中に前記リソース割当依頼があると、前記監視手段および前記通報手段が動的に消費するリソースとしてカーネル空間上のプール領域を割り当てるリソース制御手段とを有することを特徴としてもよい。
【００１０】
前記縮退管理手段は、前記縮退モードに切り換えられた後、前記リソースとしてユーザ空間上の共用領域を割り当てられている前記監視手段が前記イベントを検出すると、前記監視手段および前記通報手段が動的に消費するリソースとしてカーネル空間上のプール領域を割り当てることを特徴としてもよい。
【００１１】
前記縮退管理手段は、前記通常モードに復旧した後、前記監視手段及び前記通報手段が動的に消費するリソースとしてユーザ空間上の共用領域を割り当てることを特徴としてもよい。
【００１２】
また、上記課題を解決するため、本発明は、記憶装置，演算処理装置を含むイベント通報装置において実行されるイベント通報プログラムであって、前記記憶装置は、ユーザ空間上の共用領域およびカーネル空間上のプール領域が設けられており、前記演算処理装置を、監視対象のイベントを検出する１つ以上の監視手段と、前記監視手段が検出したイベントに基づきイベント通報を行う１つ以上の通報手段と、リソースの消費状態に基づいて通常モード及び縮退モードを切り換え、前記通常モード中に前記監視手段および前記通報手段に対するリソース割当依頼があると、ユーザ空間上の共用領域を割り当て、前記縮退モード中に前記監視手段および前記通報手段に対するリソース割当依頼があると、カーネル空間上のプール領域を割り当てるリソース調停手段として機能させるためのイベント通報プログラムであることを特徴とする。
【発明の効果】
【００１３】
上述の如く、本発明によれば、リソースの枯渇時におけるイベント通報の実行性を向上させるイベント通報装置およびイベント通報プログラムを提供可能である。
【発明を実施するための最良の形態】
【００１４】
次に、本発明を実施するための最良の形態を、以下の実施例に基づき図面を参照しつつ説明していく。なお、本実施例ではイベント通報装置の一例として監視エージェント搭載装置１を例に説明するが、イベントを検出し、イベント通知を行う如何なる装置，機器又はコンピュータに接続可能なボードや拡張カードであってもよい。
【００１５】
図１は監視エージェント搭載装置を含むシステムの一例の構成図である。監視エージェント搭載装置１は監視エージェント１０及びリソース調停部２０を含む構成である。監視エージェント１０は、監視タスク１１ａ〜１１ｃと、通報タスク１２ａ〜１２ｃとを含む構成である。なお、監視タスク１１ａ〜１１ｃの何れでも良い場合は、単に監視タスク１１と呼ぶ。また、通報タスク１２ａ〜１２ｃの何れでも良い場合は、単に通報タスク１２と呼ぶ。
【００１６】
監視タスク１１ａ〜１１ｃは監視対象２ａ〜２ｃと一対一に対応付けられており、対応付けられている監視対象２ａ〜２ｃのイベントを検出する。監視対象２ａ〜２ｃは、監視エージェント搭載装置１に直接又はネットワーク３を介して接続されている。図１では監視対象２ａ〜２ｃが自装置外にある例を示しているが、自装置内にあってもよい。通報タスク１２ａ〜１２ｃは監視タスク１１ａ〜１１ｃと一対一に対応付けられており、監視タスク１１ａ〜１１ｃが検出したイベントに基づいて、例えばネットワーク４にイベント通報を行う。
【００１７】
リソース調停部２０は、自装置のリソースの消費状態を通常モード又は縮退モードとして管理している。通常モードは、リソースが枯渇していない状態をいう。縮退モードはリソースが枯渇している状態をいう。リソース調停部２０は、自装置のリソースが枯渇している間、通常モードから縮退モードに切り換える。リソース調停部２０は、通常モード又は縮退モードに基づき、監視タスク１１及び通報タスク１２が動的に消費するリソースとしてユーザ空間上の共用領域またはカーネル空間上のプール領域を割り当てる。
【００１８】
なお、監視エージェント搭載装置１が行う処理の詳細は後述する。次に、監視エージェント搭載装置１のハードウェア構成について説明する。図２は、監視エージェント搭載装置の一例のハードウェア構成図である。監視エージェント搭載装置１は、それぞれバスＢで相互に接続されている入力装置３１，出力装置３２，ドライブ装置３３，補助記憶装置３４，メモリ装置３５，演算処理装置３６及びインターフェース装置３７で構成される。
【００１９】
入力装置３１はキーボードやマウスなどで構成され、各種信号を入力するために用いられる。出力装置３２はディスプレイ装置などで構成され、各種ウインドウやデータ等を表示するために用いられる。インターフェース装置３７は、モデム，ＬＡＮカードなどで構成されており、ネットワーク３，４に接続する為に用いられる。
【００２０】
本発明のイベント通報プログラムは、監視エージェント搭載装置１を制御する各種プログラムの少なくとも一部である。イベント通報プログラムは例えば記録媒体３８の配布やネットワーク４等からのダウンロードなどによって提供される。イベント通報プログラムを記録した記録媒体３８は、ＣＤ−ＲＯＭ、フレキシブルディスク、光磁気ディスク等の様に情報を光学的，電気的或いは磁気的に記録する記録媒体、ＲＯＭ、フラッシュメモリ等の様に情報を電気的に記録する半導体メモリ等、様々なタイプの記録媒体を用いることができる。
【００２１】
また、イベント通報プログラムを記録した記録媒体３８がドライブ装置３３にセットされると、イベント通報プログラムは記録媒体３８からドライブ装置３３を介して補助記憶装置３４にインストールされる。ネットワーク４等からダウンロードされたイベント通報プログラムは、インターフェース装置３７を介して補助記憶装置３４にインストールされる。
【００２２】
監視エージェント搭載装置１は、インストールされたイベント通報プログラムを格納すると共に、必要なファイル，データ等を格納する。メモリ装置３５は、コンピュータの起動時に補助記憶装置３４からイベント通報プログラムを読み出して格納する。そして、演算処理装置３６はメモリ装置３５に格納されたイベント通報プログラムに従って、後述するような各種処理を実現している。
【００２３】
図３は、監視エージェント搭載装置の一実施例の機能構成図である。監視エージェント搭載装置１は、メモリ空間としてカーネル空間１００及びユーザ空間２００が設けられている。カーネル空間１００は、カーネルが利用するメモリ空間である。カーネル空間１００には、オペレーティングシステム（ＯＳ）１０１と、プール領域１０２とが配置されている。
【００２４】
ユーザ空間２００はアプリケーション等が利用するメモリ空間である。ユーザ空間２００には、監視エージェント１０と、リソーススイッチャ２０１と、共用領域２０２と、リソース監視部２０３とが配置されている。なお、リソーススイッチャ２０１は前述したリソース調停部２０に相当する。また、リソース監視部２０３は監視エージェント搭載装置１の外部に設けて、外部連携させてもよい。
【００２５】
カーネル空間１００のプール領域１０２は、リソース枯渇時のリソース獲得競争を回避させるために、予め確保しておく領域である。また、プール領域１０２はカーネル空間１００上でメモリ装置３５の一例としてのＲＡＭにロックした領域である。プール領域１０２は監視タスク１１及び通報タスク１２の終了後もデータを保持でき、再利用可能な領域である。
【００２６】
ユーザ空間２００の共用領域２０２は、ＯＳ１０１が監視タスク１１及び通報タスク１２を含むタスクに割り当てる領域である。共用領域２０２はスワップ対象であり、タスク間の獲得競争があり、前述したＯＯＭキラーの対象である。したがって、共用領域２０２を割り当てられたタスクはＯＯＭキラーによって強制終了されることもある。
【００２７】
リソーススイッチャ２０１は、異常度プリエンプション機能部２１１，リソース制御部２１２，縮退管理機能部２１３を含む構成である。リソース制御部２１２は、リソース動的割当部２２１，タスクスイッチ２２２を含む構成である。
【００２８】
リソーススイッチャ２０１は、監視タスク１１及び通報タスク１２からのリソース割当依頼をフックして、リソースドリブンで通常モード，縮退モードの処理を行う。リソーススイッチャ２０１はリソース枯渇時の実行性を高めるため、通常モード及び縮退モードに関わらず、動的に消費するリソースとしてプール領域１０２を利用する。
【００２９】
リソーススイッチャ２０１の縮退管理機能部２１３は縮退モード管理およびタスク実行管理から成るタスク制御を行う。縮退モード管理は、例えば外部のリソース管理ソフトなどのリソース監視部２０３からの枯渇通知を捕捉して、通常モード及び縮退モードを切り換える。タスク実行管理は、縮退モード管理によって管理されている通常モード又は縮退モードに基づき、監視タスク１１および通報タスク１２の縮退化と、縮退からの復旧とを制御する。縮退化の判断は、監視タスク１１及び通報タスク１２の起動時に通知されるリソース割当依頼に基づき判定する。
【００３０】
ここでは、通常モードから縮退モードへの縮退について説明する。監視タスク１１は監視対象２ａ〜２ｃのイベントを検出する為に常時起動している。監視タスク１１は検出したイベントを即座に通知させる必要があるため、イベントを検出し、イベント通報に成功した順番に再起動されることで、緩やかに縮退モードに切り替わっていく。通報タスク１２は新たに実行するものから縮退モードに切り換えられる。イベント通報中又はイベント通報待ちの通報タスク１２は通報待ちキューで管理され、イベント通報後に縮退モードに切り換えられる。
【００３１】
次に、縮退モードから通常モードへの復旧について説明する。監視タスク１１は再起動を行い、通常モードに復旧する。監視タスク１１に対応する通報タスク１２があれば、監視タスク１１はイベント通報結果を取得する必要があるため、通報タスク１２の完了を待ってから順次再起動を行い、通常モードに復旧する。通報タスク１２は、新たに実行するものから通常モードに復旧する。なお、イベント通報中又はイベント通報待ちの通報タスク１２は、イベント通報に成功してから通常モードに復旧する。
【００３２】
リソーススイッチャ２０１のリソース制御部２１２は監視タスク１１及び通報タスク１２からリソース割当依頼があると、縮退モードであればカーネル空間１００上のプール領域１０２をリソースとして割り当て、通常モードであればユーザ空間２００の共用領域２０２をリソースとして割り当てる。
【００３３】
リソース制御部２１２のリソース動的割当部２２１は縮退モード時のリソースの割り当て及び通常モード時のリソースの割り当てを行う。縮退モード時のリソースの割り当てはカーネル空間１００のプール領域１０２を監視タスク１１及び通報タスク１２へ排他的に割り当てることで、リソース枯渇時に監視タスク１１及び通報タスク１２が動的に消費するリソースを確保しながら、監視タスク１１及び通報タスク１２を順次実行に切り替えている。
【００３４】
リソース動的割当部２２１は監視タスク１１間のイベントの検出の公平性を保つために一定時間で切り替えながらラウンドロビンな割り当てを行う。また、リソース動的割当部２２１は新たに実行する通報タスク１２から異常度プリエンプション機能部２１１で割り当てて行く。なお、イベント通報中又はイベント通報待ちの通報タスク１２は、イベント通報後に割り当てる。なお、通常モード時のリソースの割り当てはＯＳ１０１が割り当てるユーザ空間２００の共用領域２０２を監視タスク１１及び通報タスク１２に中継するものである。
【００３５】
また、リソース制御部２１２のタスクスイッチ２２２は縮退モード時のスイッチング及び通常モード時のスイッチングを行う。縮退モード時のスイッチングはリソース動的割当部２２１が行う縮退モード時のリソースの割り当てにより、タスクスイッチングを実現している。通常モード時のスイッチングはＯＳ１０１のスケジューラに依存する。
【００３６】
リソーススイッチャ２０１の異常度プリエンプション機能部２１１はイベント通報の優先度に従いイベント通報の順番を制御する。異常度プリエンプション機能部２１１は通報タスク１２のリソース獲得（リソース割当依頼）を契機として、通報待ちキューを異常度の高い順に並び替え、優先度の高い通報タスク１２から順番に実行させる。異常度プリエンプション機能部２１１は通報制御手段の一例である。
【００３７】
次に、リソーススイッチャ２０１が監視タスク１１及び通報タスク１２の縮退制御のために作成及び管理するスイッチテーブルについて説明する。図４はスイッチテーブルの一例の構成図である。図４のスイッチテーブルは監視タスク情報および通報タスク情報で構成されている。監視タスク情報はフィールド「監視タスク」，「状態」，「プール」から構成されている。通報タスク情報はフィールド「通報タスク」，「状態」，「異常度」，「プール」から構成されている。即ち、スイッチテーブルは７つのフィールドから構成されている。
【００３８】
監視タスク情報のフィールド「監視タスク」は監視タスク１１の識別子を表す。監視タスク情報のフィールド「状態」は監視タスク１１が通常モードか縮退モードかを判定する為の情報を表す。
【００３９】
監視タスク情報のフィールド「状態」が「通常」のとき、監視タスク１１は通常モードで監視中である。監視タスク情報のフィールド「状態」が「縮退」のとき、監視タスク１１は縮退モードで監視中である。監視タスク情報のフィールド「状態」が「異常」のとき、監視タスク１１は異常終了している。
【００４０】
また、監視タスク情報のフィールド「プール」は、監視タスク１１によるプール領域１０２の使用状況を表している。監視タスク情報のフィールド「プール」が「使用」であるとき、監視タスク１１は、プール領域１０２を獲得して使用中である。監視タスク情報のフィールド「プール」が「獲得待」であるとき、監視タスク１１はプール領域１０２の獲得待ちである。監視タスク情報のフィールド「プール」が「空き無」であるとき、プール領域１０２には監視タスク１１に割り当て可能な領域がない。監視タスク情報のフィールド「プール」が「−」であるとき、監視タスク１１は、プール領域１０２を使用していない。
【００４１】
通報タスク情報のフィールド「通報タスク」は通報タスク１２でイベント通報中のイベント識別子を表す。なお、通報タスク情報のフィールド「通報タスク」が「−」のときはイベント通報中の通報タスク１２が存在しない。通報タスク情報のフィールド「状態」は通報タスク１２が通常モードか縮退モードかを判定する為の情報を表す。
【００４２】
通報タスク情報のフィールド「状態」が「通常」のとき、通報タスク１２は通常モードで通信中である。通報タスク情報のフィールド「状態」が「縮退」のとき、通報タスク１２は縮退モードで通信中である。
【００４３】
通報タスク情報のフィールド「状態」が「完了」のとき、通報タスク１２は正常終了している。通報タスク情報のフィールド「状態」が「異常」のとき、通報タスク１２は異常終了している。通報タスク情報のフィールド「状態」が「−」のとき、通報タスク１２は存在しない。
【００４４】
通報タスク情報のフィールド「異常度」は通報タスク１２からイベント通報するイベントの異常度をイベント通報の優先度として表している。通報タスク情報のフィールド「異常度」は数値（例えば０〜１００）によってイベント通報の優先度を表す。通報タスク情報のフィールド「異常度」が「−」のとき、通報タスク１２は存在しない。
【００４５】
また、通報タスク情報のフィールド「プール」は、通報タスク１２によるプール領域１０２の使用状況を表している。通報タスク情報のフィールド「プール」が「使用」であるとき、通報タスク１２は、プール領域１０２を獲得して使用中である。通報タスク情報のフィールド「プール」が「獲得待」であるとき、通報タスク１２はプール領域１０２の獲得待ちである。通報タスク情報のフィールド「プール」が「空き無」であるとき、プール領域１０２には通報タスク１２に割り当て可能な領域がない。通報タスク情報のフィールド「プール」が「−」であるとき、通報タスク１２は、プール領域１０２を使用していない。
【００４６】
次に、監視エージェント搭載装置１が行う処理の手順について図５のフローチャートを参照しつつ説明する。図５は、監視エージェント搭載装置が行う処理の手順を表した一例のフローチャートである。
【００４７】
リソーススイッチャ２０１の縮退管理機能部２１３は外部連携しているリソース監視部２０３からの枯渇通知を捕捉して前述したように通常モード及び縮退モードを切り替えている。縮退管理機能部２１３は、監視タスク１１及び通報タスク１２からのリソース割当依頼を契機として、ステップＳ１に進み、通常モードであるか縮退モードであるかを判定する。
【００４８】
通常モードであれば、リソース動的割当部２２１はステップＳ２に進み、ＯＳ１０１が割り当てるユーザ空間２００の共用領域２０２を監視タスク１１及び通報タスク１２に中継する。縮退モードであれば、リソース動的割当部２２１はステップＳ３に進み、縮退管理機能部２１３は前述したスイッチテーブルに基づき、監視タスク１１および通報タスク１２の縮退化を制御する。
【００４９】
ステップＳ４に進み、リソース制御部２１２はカーネル空間１００上のプール領域１０２を監視タスク１１及び通報タスク１２のリソースとして割り当てる。また、縮退管理機能部２１３は、カーネル空間１００上のプール領域１０２を監視タスク１１及び通報タスク１２のリソースとして割り当てたとき、プール領域１０２のスイッチテーブルに反映させる。ステップＳ５に進み、異常度プリエンプション機能部２１１はイベント通報の優先度に従いイベント通報の順番を制御する。
【００５０】
そして、ステップＳ２又はＳ５に続いてステップＳ６に進み、監視タスク１１及び通報タスク１２はリソースとして割り当てられたプール領域１０２又は共用領域２０２を動的に消費して処理を行う。
【００５１】
以下、監視エージェント搭載装置１が行う処理の手順を、スイッチテーブルの遷移により説明する。図６及び図７は、縮退直後から縮退中におけるスイッチテーブルを表した遷移図である。また、図８は縮退中からの復旧におけるスイッチテーブルを表した遷移図である。図６〜図８では監視タスクが、ＳＮＭＰ監視タスク、シスログ監視タスク及びＩＯ監視Ａタスクである例を表している。
【００５２】
まず、図６及び図７を利用して縮退直後から縮退中におけるスイッチテーブルの遷移を一例に説明する。図６及び図７では、図６（ａ）〜図６（ｅ）、図７（ｆ）、図７（ｇ）の順番に時間が経過しているものとする。
【００５３】
図６（ａ）は縮退前に通常モードのＳＮＭＰ監視タスク，シスログ監視タスク及びＩＯ監視Ａタスクが通常モードで起動しており、且つ通常モードの通報タスクであるＸイベントが通報中であることを表している。
【００５４】
図６（ｂ）は通常モードのＳＮＭＰ監視タスクが、通報タスクであるＸイベントの完了を待って縮退化し、プール領域１０２を使用中であることを表している。図６（ｂ）は通常モードのシスログ監視タスクがイベントを検出し、縮退モードの通報タスクであるＹイベントが通報中であり、プール領域１０２を使用中であることを表している。
【００５５】
図６（ｃ）は通常モードのＩＯ監視Ａタスクがイベントを検出している。縮退モードの通報タスクであるＺイベントはＹイベントよりも異常度が大きく、Ｙイベントよりも優先度が高いので、Ｙイベントに替わってイベント通報を行う。なお、Ｙイベントは待ち状態となる。
【００５６】
図６（ｄ）は通常モードのＩＯ監視Ａタスクが、縮退モードの通報タスクであるＺイベントの完了を待って縮退化し、プール領域１０２を使用中であることを表している。縮退化されたＳＮＭＰ監視タスク及びＩＯ監視Ａタスクは、一定時間で切り替わる。なお、Ｙイベントは完了したＺイベントに替わってイベント通報を再開する。
【００５７】
図６（ｅ）は通常モードのシスログ監視タスクが、縮退モードの通報タスクであるＹイベントの完了を待って縮退化する。縮退化されたＳＮＭＰ監視タスク，シスログ監視タスク及びＩＯ監視Ａタスクは一定時間で切り替わる。
【００５８】
図７（ｆ）は縮退モードのＳＮＭＰ監視タスクがイベントを検出し、縮退モードの通報タスクであるＷイベントが通報中であり、プール領域１０２を使用中であることを表している。
【００５９】
図７（ｇ）は縮退モードのＩＯ監視Ａタスクがイベントを検出している。縮退モードの通報タスクであるＶイベントはＷイベントよりも異常度が大きく、Ｗイベントよりも優先度が高いので、Ｗイベントに替わってイベント通報を行う。なお、Ｗイベントは待ち状態となる。
【００６０】
次に、図８を利用して縮退中からの復旧におけるスイッチテーブルの遷移を一例に説明する。図８では、図８（ａ）〜図８（ｄ）の順番に時間が経過しているものとする。
【００６１】
図８（ａ）は前述した図７（ｇ）と同一である。図８（ａ）は、縮退からの復旧前に縮退モードのＳＮＭＰ監視タスクおよびＩＯ監視Ａタスクがイベントを検出している。縮退モードの通報タスクであるＶイベントはＷイベントよりも優先度が高いので、Ｗイベントに替わってイベント通報を行っている。なお、Ｗイベントは待ち状態となっている。
【００６２】
図８（ｂ）は、通報タスクの無い縮退モードのシスログ監視タスクを再起動して、通常モードに復旧する。なお、通報タスクの有る縮退モードのＳＮＭＰ監視タスク及びＩＯ監視Ａタスクは縮退モードの通報タスクＷイベント及びＶイベントの完了を待つ。
【００６３】
図８（ｃ）は、縮退モードのＩＯ監視Ａタスクが、通報タスクであるＶイベントの完了を待って再起動し、通常モードに復旧する。また、図８（ｄ）は、縮退モードのＳＮＭＰ監視タスクが、通報タスクであるＷイベントの完了を待って再起動し、通常モードに復旧する。
【００６４】
監視エージェント搭載装置１は、リソースの枯渇時、監視タスク１１及び通報タスク１２に割り当てるリソースを共用領域２０２からプール領域１０２に切り替える為、共用領域２０２のように強制終了される可能性がなくなり、通報の実行性を向上させることができる。
【００６５】
以上、本発明による監視エージェント搭載装置１は自律システムのスケールアウト運用のように自動的に必要なリソースを調整して枯渇を回避する仕組みでなく、リソースの枯渇を検出してから枯渇が解決されるまでの間に実行されるタスクの実行性を向上させることができる。
【００６６】
本発明は、以下に記載する付記のような構成が考えられる。
（付記１）
監視対象のイベントを検出し、イベント通報を行うイベント通報装置であって、
前記監視対象のイベントを検出する１つ以上の監視手段と、
前記監視手段が検出したイベントに基づきイベント通報を行う１つ以上の通報手段と、
リソースの消費状態に基づいて通常モード及び縮退モードを切り換え、前記通常モード中に前記監視手段および前記通報手段に対するリソース割当依頼があると、ユーザ空間上の共用領域を割り当て、前記縮退モード中に前記監視手段および前記通報手段に対するリソース割当依頼があると、カーネル空間上のプール領域を割り当てるリソース調停手段と
を有することを特徴とするイベント通報装置。
（付記２）
前記リソース調停手段は、リソースが不足している間、通常モードから縮退モードに切り換えるように、通常モード及び縮退モードを管理する縮退管理手段と、
前記通常モード中に前記リソース割当依頼があると、前記監視手段および前記通報手段が動的に消費するリソースとしてユーザ空間上の共用領域を割り当て、前記縮退モード中に前記リソース割当依頼があると、前記監視手段および前記通報手段が動的に消費するリソースとしてカーネル空間上のプール領域を割り当てるリソース制御手段と
を有することを特徴とする付記１記載のイベント通報装置。
（付記３）
前記縮退管理手段は、前記縮退モードに切り換えられた後、前記リソースとしてユーザ空間上の共用領域を割り当てられている前記監視手段が前記イベントを検出すると、前記監視手段および前記通報手段が動的に消費するリソースとしてカーネル空間上のプール領域を割り当てることを特徴とする付記２記載のイベント通報装置。
（付記４）
前記縮退管理手段は、前記通常モードに復旧した後、前記監視手段及び前記通報手段が動的に消費するリソースとしてユーザ空間上の共用領域を割り当てることを特徴とする付記２又は３記載のイベント通報装置。
（付記５）
前記リソース調停手段は、複数の前記通報手段がイベント通報中又はイベント通報待ちであるときに、前記イベント通報中又はイベント通報待ちの前記通報手段を優先度の高い順に実行させる通報制御手段を更に有することを特徴とする付記２乃至４何れか一項記載のイベント通報装置。
（付記６）
前記リソース制御手段は、前記監視手段および前記通報手段が動的に消費するリソースとしてユーザ空間上の共用領域又はカーネル空間上のプール領域を割り当てるリソース動的割当手段と、
前記リソースとしてユーザ空間上の共用領域又はカーネル空間上のプール領域を割り当てられた前記監視手段および前記通報手段の切り換えを行うスイッチ手段と
を有することを特徴とする付記２乃至５何れか一項記載のイベント通報装置。
（付記７）
前記リソース調停手段は、カーネル空間上のプール領域に、前記監視手段および前記通報手段が通常モード又は縮退モードの何れであるかを表したテーブルを保存していることを特徴とする付記１乃至６何れか一項記載のイベント通報装置。
（付記８）
記憶装置，演算処理装置を含むイベント通報装置において実行されるイベント通報プログラムであって、
前記記憶装置は、ユーザ空間上の共用領域およびカーネル空間上のプール領域が設けられており、
前記演算処理装置を、
監視対象のイベントを検出する１つ以上の監視手段と、
前記監視手段が検出したイベントに基づきイベント通報を行う１つ以上の通報手段と、
リソースの消費状態に基づいて通常モード及び縮退モードを切り換え、前記通常モード中に前記監視手段および前記通報手段に対するリソース割当依頼があると、ユーザ空間上の共用領域を割り当て、前記縮退モード中に前記監視手段および前記通報手段に対するリソース割当依頼があると、カーネル空間上のプール領域を割り当てるリソース調停手段と
して機能させるためのイベント通報プログラム。
【００６７】
本発明は、具体的に開示された実施例に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。
【図面の簡単な説明】
【００６８】
【図１】監視エージェント搭載装置を含むシステムの一例の構成図である。
【図２】監視エージェント搭載装置の一例のハードウェア構成図である。
【図３】監視エージェント搭載装置の一実施例の機能構成図である。
【図４】スイッチテーブルの一例の構成図である。
【図５】監視エージェント搭載装置が行う処理の手順を表した一例のフローチャートである。
【図６】縮退直後から縮退中におけるスイッチテーブルを表した遷移図（１／２）である。
【図７】縮退直後から縮退中におけるスイッチテーブルを表した遷移図（２／２）である。
【図８】縮退中からの復旧におけるスイッチテーブルを表した遷移図である。
【符号の説明】
【００６９】
１    監視エージェント搭載装置
２ａ〜２ｃ    監視対象
３，４    ネットワーク
１０    監視エージェント
１１，１１ａ〜１１ｃ    監視タスク
１２，１２ａ〜１２ｃ    通報タスク
２０    リソース調停部
３１    入力装置
３２    出力装置
３３    ドライブ装置
３４    補助記憶装置
３５    メモリ装置
３６    演算処理装置
３７    インターフェース装置
３８    記録媒体
１００    カーネル空間
１０１    ＯＳ
１０２    プール領域
２００    ユーザ空間
２０１    リソーススイッチャ
２０２    共用領域
２０３    リソース監視部
２１１    異常度プリエンプション機能部
２１２    リソース制御部
２１３    縮退管理部
２２１    リソース動的割当部
２２２    タスクスイッチ
【図１】
2007257292.tif 000003
【図２】
2007257292.tif 000004
【図３】
2007257292.tif 000005
【図４】
2007257292.tif 000006
【図５】
2007257292.tif 000007
【図６】
2007257292.tif 000008
【図７】
2007257292.tif 000009
【図８】
2007257292.tif 000010