(57)【特許請求の範囲】
【請求項１】
管理対象環境におけるイベントをログする方法であって、
ａ）セントラル・ブローカによって１つまたは複数のイベントについて管理対象環境を監視するステップと、
ｂ）セントラル・ブローカによって前記イベントの１つを受け取るステップと、
ｃ）イベント記憶機構が、複数のセットに構成された複数の非テキストファイルを有し、該複数のセットのそれぞれが、対応するイベント・ログ・ファイルおよびイベント・インデックス・ファイルを含んでおり、前記セントラル・ブローカによってイベントが受け取られる都度、言語独立の非テキスト形式で該イベントの完全な表現をイベント・ログ・ファイルにアペンドし、イベント・ログ・ファイルにおける該イベントの位置を、イベント識別子をインデックスとしてイベント・インデックス・ファイルに書き込むことによって、イベント記憶機構にログするステップと、
ｄ）ストリームに関連したストリーム・イベントの通知を受け取るステップと、
e）当該ストリーム・イベントのイベント識別子を求めてイベント・インデックス・ファイルを探索することによって、イベント・ログ・ファイルにおけるストリーム・イベントの位置を決定するステップと、
f）要求に応じてストリーム履歴の迅速な再構築を可能にするように、１つまたは複数のストリーム・ログ・ファイルの１つに前記イベント・ログ・ファイルにおけるストリーム・イベントの位置をアペンドすることによって、イベント記憶機構にストリーム・イベントをログするステップと、を含むイベント・ログ方法。
【請求項２】
管理対象環境におけるイベントをログする方法であって、
ａ）セントラル・ブローカによって１つまたは複数のイベントについて管理対象環境を監視するステップと、
ｂ）セントラル・ブローカによって前記イベントの１つを受け取るステップと、
ｃ）イベント記憶機構が、複数のセットに構成された複数の非テキストファイルを有し、該複数のセットのそれぞれが、対応するイベント・ログ・ファイルおよびイベント・インデックス・ファイルを含んでおり、前記セントラル・ブローカによってイベントが受け取られる都度、言語独立の非テキスト形式で該イベントの完全な表現をイベント・ログ・ファイルにアペンドし、イベント・ログ・ファイルにおける該イベントの位置を、イベント識別子をインデックスとしてイベント・インデックス・ファイルに書き込むことによって、イベント記憶機構にログするステップと、
ｄ）主要イベントおよび関連イベントに関する相互関係要求を受け取るステップと、
e）当該関連イベントのイベント識別子を求めてイベント・インデックス・ファイルを探索することによって、イベント・ログ・ファイルにおける関連イベントの位置を決定するステップと、
f）主要イベントおよび関連イベントが関連付けられるように、イベント・ログ・ファイルにおける関連イベントの位置を、主要イベントの識別子とともに相互関係ログ・ファイルにアペンドすることによって関連イベントをイベント記憶機構にログするステップと、を含む、イベント・ログ方法。
【請求項３】
前記言語独立の非テキスト形式は、前記１つまたは複数のイベントのそれぞれをローカル言語にフォーマットすることを可能にする請求項１または２に記載のイベント・ログ方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、一般に、ネットワーク管理に関するもので、特に、管理対象ネットワーク環境におけるイベントのログと順序づけされた取り出しを可能にするネットワーク・システムに関するものである。
【０００２】
【従来の技術】
シンプル・ネットワーク・マネジメント・プロトコル(Simple Network Management Protocolの頭文字をとってＳＮＭＰと略称される)および共通管理情報プロトコル(Common Management Information Protocolの頭文字をとってＣＭＩＰ)は、ＵＮＩＸサーバのような管理システムを通して種々の製造業者の機器を監視および制御することを可能にする一般的メカニズムを提供するネットワーク管理プロトコルである。管理プロトコルを使用してネットワーク上のネットワーク・コンポーネントの間の管理情報を伝えることによって、管理対象ネットワーク上のネットワーク・コンポーネントは監視および制御されることができる。ネットワーク・コンポーネントは、ネットワーク化されたパーソナル・コンピュータ、ワークステーション、サーバ、ルータおよびブリッジを含む。障害管理、構成管理、セキュリティ管理、性能管理および経費負担管理を含むいくつかの主要なネットワーク管理分野が存在する。ネットワーク・コンポーネントにイベントを報告するように命令する能力およびネットワーク・コンポーネント上でプロセスを始動させる能力を用いて、システムの範囲内の条件の変化に対応するようにネットワークを操作することができる。
【０００３】
種々のネットワーク装置が管理システムと通信する主要なメカニズムは、ＳＮＭＰトラップまたはＣＭＩＰイベントを介するものである。以下の記述において、用語「イベント」は、ＳＮＭＰトラップまたはＣＭＩＰイベントのいずれかを意味するものとして使用される。イベントは、１つのネットワーク装置から他のネットワーク装置へ予期されていない通知を送信することを可能にする。この同じメカニズムを使用して、管理システムの範囲内で種々の協調ソフトウェア・コンポーネントの間の通信を実行することができる。イベントに含まれる情報が複数のユーザにとって価値のある可能性があるが、誰がその情報に関心を持っているかその情報の作成者には正確にはわからないような場合、このような形式の通信は特に価値がある。
【０００４】
種々の関係者の間でのこれらのイベントの通信を容易にするため、作成者からそのようなイベントのすべてを受け取り、あらかじめ登録した種々の関係者にイベントを送達するブローカ(すなわち仲介者)が用意される場合がある。
【０００５】
また、そのようなイベントは、問題のシナリオを再現して理解することを試みる時、すなわち、典型的には、そのようなシナリオが将来発生することを防止するメカニズムを工夫する努力において、歴史的価値を持つ。かくして、後の検索のためイベントをログ(すなわち記録)することができ、イベントの経緯を再構築することができることは重要である。
【０００６】
【発明が解決しようとする課題】
従来技術においては、イベントは、セントラル・ブローカ(中央の仲介者)によって受け取られる。以下、このような中央の仲介者をポストマスタ・デーモンと呼ぶ。ポストマスタ・デーモンは、trap.logと呼ばれるログ・ファイルにすべてのイベントを書き込む。イベント・データは、人間の読めるＡＳＣＩＩテキスト固定言語形式でtrap.logに書き込まれ、イベントに関する既知の情報のサブセットを含む。このtrap.logファイルは、イベント・データを見て分析することを望むいかなるイベント・ブラウザでもまたはその他いかなるアプリケーションでもアクセスすることができる。trap.logファイルは、最大サイズまで成長することができるように構成されるが、最大サイズに達した時点で、trap.logファイルの内容は、バックアップ・ファイルtrapd.log.oldへ移され、新しいイベントのため新しいtrapd.logファイルが生成される。
【０００７】
trapd.logに書かれたイベント・データは、ＡＳＣＩＩテキスト固定言語形式であるので、イベント情報は別の言語に簡単に再フォーマットすることができない。その上、trapd.logはイベントに関する既知の情報のサブセットだけを含むので、イベントが保存される時オリジナルのイベントに含まれるデータの重要な部分が消失する。従って、イベント情報全体が取り出されることができるようにオリジナルのイベント情報の完全な表現を記憶することができる未解決の必要性が当業界に存在する。また、異なる局所的言語での表現のため再フォーマットすることができるように非テキスト形式でオリジナルのイベント情報を記憶する必要性が当業界に存在する。
【０００８】
図１には、従来技術に従って、trapd.logファイル１４を利用するネットワーク・システム１０が示されている。ポストマスタ・デーモン１２は、管理対象環境または管理アプリケーションからイベントを受け取り、そのイベントをＡＳＣＩＩテキストのtrapd.logファイル１４、イベント・ブラウザ１６およびその他のアプリケーション１７に同時に複製する責任を持つ。その他のアプリケーション１８がそのＡＳＣＩＩテキストtrapd.logファイル１４を読み取る。
【０００９】
管理活動は、ポストマスタ・デーモンを通して流れるすべてのイベントのうち相互になんらかの関連を持つサブセットに関心を持つかもしれない。そのような相互関係の例には次のようなものが含まれる。すなわち、特定のアプリケーション、装置またはネットワーク・コンポーネントに関連するイベントのすべて、および、管理対象環境の特定のサブセットから生成されたイベントのすべて、である。
【００１０】
ポストマスタ・デーモン１２は、ポストマスタ・デーモン１２を通して流れるイベントを分割して、複数のイベント・ストリームと呼ばれるグループに分類する機能を有する。イベント・ストリームの各々は、何らかの形で関連付けられる複数のイベントを表す。更に、単一イベントは、これらのストリームのうちの１つまたは複数と関連している可能性があり、複数のストリームを通して流れるイベントの順序は、ストリーム毎に変わる可能性がある。従って、個々のストリームの流れを再構築できるように各ストリームからのイベントを正しくログ・ファイルに記録することが重要である。しかしながら、現行のtrad.logファイルは、イベントの単一の流れにのみ適している。従って、イベントが観察可能で、ストリームの順位毎に順序づけられるように、複数ストリームからのイベント情報を記憶することができるようにするという、未解決の課題が当業界に存在する。本明細書において、「（所定の）ストリームから流入する（流出する、流れる）イベント」という記載は、「（所定の）ストリームに関連するイベント」を意味する。
【００１１】
ポストマスタ・デーモンは、イベントが相互に関係づけられることを可能にする。例えば、いくつかのネットワーク・コンポーネントに関する通信障害を表示する複数イベントが、集合的に、通信リンクが切断したことを標示するかもしれない。従来技術においては、このような相互関係情報は記録されない。従って、イベント相互関係情報を記憶することができる未解決の課題が当業界に存在する。
【００１２】
【課題を解決するための手段】
本発明は、上記課題を解決するため、以下の諸目的を達成する。すなわち、ポストマスタ・デーモンによって受け取られたイベントの完全な表現を受け取られた順序で記憶すること、所望のローカル言語の表現に選択的に再フォーマットすることができるように非テキスト形式でオリジナルのイベント情報を記憶すること、イベント・ログの最大サイズに達した後、より新しいイベントがイベント・ログにおける最も古いイベントを置き換えるようにイベントの最大サイズが構成されることを可能にすること、データの重複を最小にし、要求に応じてストリーム履歴の迅速な再構築を可能にしながら、個々のストリームから流入するイベントの履歴に関する情報を記憶すること、
および、イベントの間の相互関係を記録することによって諸イベントの間にどのような種類の相互関係が存在するを識別する情報と共にイベントが記録されるようにすること、である。
【００１３】
従って、本発明に従って、ポストマスタ・デーモンによって受け取られる管理イベントの完全な表現が、従来技術のＡＳＣＩＩファイルtrapd.logを置き換えるイベント記憶機構に記憶される。後方互換性をサポートするため、ポストマスタ・デーモンは、付加的に、ＡＳＣＩＩtrapd.logファイルにも書き込むように構成するこもできるし、あるいは、独立型アプリケーションが、スナップショットが生成される瞬間のイベント記憶機構の内容のスナップショットを基にtrapd.logファイルを生成することもできる。
【００１４】
イベント記憶機構は、セットで構成される多数の異なる非テキスト・ファイルから構成される。各セットには、１つのイベント・ログ・ファイルおよび１つのイベント・インデックス・ファイルが含まれる。更に、各セットは、１つまたは複数のストリーム・ログ・ファイルおよび相互関係ログ・ファイルを含むこともできる。イベントはイベント・ログ・ファイルに書き込まれ、ポストマスタ・デーモンが１つのイベントを受け取ると直ちに１つのエントリがイベント・インデックス・ファイルに作成される。
【００１５】
イベント・ログ・ファイルは、可変長レコードを含み、イベントが受け取られた時のタイムスタンプおよび完全なイベント・メッセージを含む。イベント・インデックス・ファイルは、ユニークなイベント識別子によって検索可能なイベント・ログ・ファイルへのインデックスを含む。インデックス・エントリは、対応するイベント・ログ・ファイルにおけるイベントの位置を含む。
【００１６】
各ストリームに関してストリーム・ログ・ファイルが存在する。ストリーム・ログ・ファイルは、ストリームから流入したイベントに対する参照、および、イベントがストリームを離れた時のタイムスタンプを含む固定長レコードを含む。ストリーム・ログの中のイベントは、それらがストリームを離れた際の順序で記録される。
【００１７】
各ストリーム毎に、相互関係ログ・ファイルを生成することもできる。相互関係ログは、主要イベントと関連イベントの間の関係を含む固定長のレコードを含む。相互関係ログは、主要イベントのイベント識別子によって検索可能である。各レコードは、主要イベントの識別子および関連イベントへの参照を含む。
【００１８】
【発明の実施の形態】
本発明において、ポストマスタ・デーモンによって受け取られた管理イベントの完全な表現が、２進数のような非テキスト形式でイベント記憶機構に記憶される。イベント記憶機構は、従来技術のＡＳＣＩＩテキスト・ファイルtrapd.logを置き換える。イベント記憶機構は、完全なイベント・データを含むので、イベント・データ全体がアプリケーションによって読み取られることが可能とされる。従来技術ＡＳＣＩＩtrapd.logファイルとの後方互換性をサポートするため、ポストマスタ・デーモンは、付加的に、trad.logファイルに書き込みを行うように構成することもできる。イベント記憶機構は、イベントをローカル言語にフォーマットすることを可能にするため、言語に依存しない形式でイベントを記憶する。イベント・ブラウザは、イベントを見るユーザの各々にとって望ましいローカル言語にイベント情報をフォーマットすることができる。
【００１９】
本発明は、イベントの複数ストリームのログを用意する。この場合、すべてのイベントのサブセットが特定のストリームから任意の順序で流出することも、あるいは、同じイベントが複数のストリームから流出することも可能である。イベントは、それらが所与の処理ストリームから流出した順序で取り出されることができる。
【００２０】
本発明は、イベントの単一の書き込みルーチンを利用し、複数の並列読み取りルーチンを許容する。書き込みルーチンは、種々のソースからイベントを受け取り、可能な限り迅速にそれらをログするジョブを持つ。本発明は、複数の読み取りルーチンによるいくつかの基本的アクセス・メカニズムをサポートする。そのようなメカニズムには、1)すべてのログされたイベントをそれらが受け取られた順序で順次読み取ること、2)特定のストリームから流出したすべてのイベントを順次読み取ること、および、3)特定の既知のイベントと相互関係のあるすべてのイベントを検出すること、が含まれる。種々のファイルの内容および形式は、ネットワーク管理システムの時間臨界的コンポーネントである書き込みルーチンの性能にしばしば悪影響を与えるイベント記憶機構のロックを必要とすることなく、書き込みおよび読み取りルーチンがファイルと対話することができるように設計されている。
【００２１】
イベント記憶機構は、セットの形態で構成される多数の異なるファイルから成り立つ。各セットは、イベント・ログ・ファイルおよびイベント・インデックス・ファイルを含む。各セットは、また、１つまたは複数のストリーム・ログ・ファイルおよび相互関係ログ・ファイルを含むこともできる。ファイルの複数のセットが存在する。これらのファイルのセットは循環形態で使用される。イベントがイベント・ログ・ファイルに書き込まれ、そのファイルのサイズが最大構成可能サイズに達すると、現在セットの中のファイルのすべてが閉じられ、次のファイル・セットが開かれ、一部切り捨てされる。次に、イベント・ファイルへの書き込みは、新しいセットの中のファイルへと続く。最後のセットに到達すると、システムは最初のセットに戻る。例示の目的から、４つのセットが使用されているが、本発明においていかなる数のセットをも利用できることは当業者に理解されることであろう。
【００２２】
各ファイルは、プラットフォームから独立した形式で書き込まれ、ファイル・タイプを標示するファイル・ヘッダ、ファイルを書くために使用されたソフトウェア・バージョン、そのファイルが属するセット番号、および、反復数を含む。イベント・ログ・ファイルは、レコード開始記号、タイムスタンプ、反復数、イベント・メッセージの長さ、完全なイベント・メッセージおよびレコード終了記号を含む非固定長レコードを含む。
【００２３】
イベント・インデックス・ファイルは、イベント・ログ・ファイルへのインデックスを含む。イベント・インデックス・ファイルにおけるエントリはイベント識別子によってインデックスを付けられる。イベント・インデックス・ファイルの中のエントリは、イベント・レコードが記憶されているイベント・ログ・ファイルのバイト位置を含む。イベントは、イベント・ログ・ファイルにアペンドされ、ポストマスタ・デーモンがイベントを受け取ると直ちに１つのエントリがイベント・インデックス・ファイルに書き込まれる。
【００２４】
イベント・インデックス・ファイルは、以前にログされたイベントの位置を書き込みルーチンが見出すことを可能にするため、書き込みルーチンによる使用のためにのみ存在する。ストリーム・ログ・ファイルおよび相互関係ログ・ファイルにエントリをログする時、イベントの位置が使用される。ストリーム・ログ・ファイルおよび相互関係ログ・ファイルにイベントの位置を記録することによって、さもなければ競合を回避するためイベント・インデックス・ファイルのロックを必要とするイベント・インデックス・ファイルへのアクセスをこれらのファイルの読み取りルーチンが実施する必要性が回避される。
【００２５】
ポストマスタ・デーモンにおいて構成される各ストリームに関して、どのイベントがいつストリームを離れたかを標示するストリーム・ログ・ファイルが生成される。ストリーム・ログの中の各レコードは、固定長であり、タイムスタンプ、イベント・レコードを含んでいるイベント・ログ・ファイルのセット番号、イベント・ログ・ファイルの中のイベント・レコードの位置、および反復数という情報を含む。ストリーム・ログ・ファイルの使用は、データの重複を最小にして、要求に応じてストリーム履歴の迅速な再構築を可能にするように、個々のストリームから流入するイベントの履歴をログすることを可能にする。
【００２６】
各ストリーム毎に、２つのイベントの間の関係を含むレコードを含む相互関係ログ・ファイルを設けることができる。相互関係ログ・レコードは、固定長であって、２つのイベントの間の関係のタイプ、主要イベントのイベント識別子、関連イベントに関するイベント・レコードを含むイベント・ログ・ファイルのセット番号、イベント・ログ・ファイルにおける関連イベントの位置、および相互関係がログされた時のタイムスタンプを含む。
【００２７】
１つのセットにおける各ファイルは、そのファイルのタイプおよび対応するセット番号に従って名前付けされる。ストリーム・ログ・ファイルおよび相互関係ログ・ファイルは、ストリーム固有のものであり、ストリーム名を与えられる。
【００２８】
図２に示されるように、ネットワーク・システム２０は、本発明に従ったイベント記憶機構２４を含む。ポストマスタ・デーモン４０は、イベント相関機構４２を含み、管理対象環境または管理アプリケーションからイベントを受け取り、イベントをイベント記憶機構２４、イベント・ブラウザ２８およびその他のアプリケーション３０に同時に複製する責任を持つ。他のアプリケーション２６がイベント記憶機構２４を読み取る。オプションとして、ポストマスタ・デーモン４０は、既存の第３者アプリケーションとの後方互換性のため従来技術のＡＳＣＩＩテキストtrapd.logファイル２２にも出力するように構成されることもできる。
【００２９】
図３を参照すれば、本発明に従ったイベント記憶機構に対する書き込みルーチンと読み取りルーチンの間の関係のオブジェクト・モデル５０が示されている。イベントはイベント・ログ・ファイルEventLog５６に書き込まれ、ポストマスタ・デーモンがイベントを受け取ると直ちにイベント記憶書き込みルーチンEventStoreWriter５２によってイベント・インデックス・ファイルevent_index５７に書き込まれる。イベント記憶書き込みルーチンEventStoreWriter５２は、各ストリーム毎に、ストリームを離れた各イベントの、ストリームを離れた順番でのイベント・ログ・ファイルの位置を含むストリーム・ログ・ファイルStreamLog５８を生成する。イベント記憶書き込みルーチンEventStoreWriter５２は、また、２つのイベントの間の関係を標示する固定長レコードを含む相互関係ログ・ファイルCorrLog６０を生成する。イベント・ブラウザのようなイベント記憶読み取りルーチンEventStoreReader５４が、イベント・ログ・ファイルEventLog５６、ストリーム・ログ・ファイルStreamLog５８および相互関係ログ・ファイルCorrLog６０にアクセスする。
【００３０】
図４には、本発明に従ったイベント・ログ・ファイルの形式が示されている。イベント・ログ・ファイルの各レコード７０は、プラットフォームから独立した形式で書かれ、レコード開始記号ＢＯＲ７２、反復数７３、イベントが受け取られた時のタイムスタンプ７４、メッセージの長さ"msg_size"７６、可変長のイベント・メッセージ本体７８、および、レコード終了記号ＥＯＲ８０という６つの部分からなる。レコード開始記号ＢＯＲ７２およびレコード終了記号ＥＯＲ８０は、イベントに関して信頼性を保ってファイルが走査されることを可能にする。レコード開始記号ＢＯＲ７２およびレコード終了記号ＥＯＲ８０は、例えば"[(G)]"および"{(D)}"のようなそれぞれレコードの開始および終了を識別する文字のユニークなセットである。
【００３１】
反復数７３は、書き込みルーチンがイベント・ログ・ファイルを書き込むため現在使用している反復回数である。これは、書き込みルーチンによってファイルがラップされたか否かを読み取りルーチンが判断することを可能にする。このような状況は、ある読み取りルーチンがファイルを読み始めたが中断して、その中断の間に、書き込みルーチンがそのファイルを切り捨てて、読み取りルーチンが中断したそのポイントを越えてファイルの新しい内容を書き込み始めた場合に、発生する。読み取りルーチンは、次のレコードを読み、無効なレコード、または、読み取りルーチンがファイルを読み始めた時ファイル・ヘッダの中で判別した反復数と異なる反復数を含むレコードを検出することによって、上記状況の発生を認識する。次に、読み取りルーチンは次のファイルへ進む。
【００３２】
図５には、本発明に従ったストリーム・ログ・ファイルの形式が示されている。ストリーム・ログ・ファイルの各レコード９０は、イベントがストリームを離れた時のタイムスタンプ９２、セット番号９６、該当するイベント・ログ・ファイルにおけるイベントの位置９８および反復数１００を含む。該当するイベント・ログ・ファイルはセット番号９６によって識別される。そのイベント・ログ・ファイルにおけるイベントの位置は、イベント位置９８によって識別される。反復数１００は、書き込みルーチンがストリーム・ログ・ファイルを書くために現在使用している反復数である。それは、前述のイベント・ログ・ファイルの場合と同じ方法で使用される。
【００３３】
図６には、本発明に従った相互関係ログ・ファイルの形式が示されている。相互関係ログ・ファイルの各レコード１１０は、イベント・ログ・ファイルにおけるイベント・ペアへの参照およびそれらイベントの間の関係を含む。関係１１２は、イベント・ログ・ファイルにおけるイベントの間の関係のタイプを示す。イベント・ログ・ファイルにおける主要イベントは、主要イベント識別子１１４によって識別される。イベント・ログ・ファイルにおける相互関係イベントは、イベントを含むイベント・ログ・ファイルのセット番号およびそのファイルにおけるイベント位置１１８によって識別される。タイムスタンプ１２０は相互関係の時間を示す。
【００３４】
図７の(Ａ)には、本発明に従って、書き込みルーチンがイベントをログする要求を取り扱うプロセスが示されている。あるイベントがポストマスタ・デーモンに入ると、そのイベント全体が、イベント・ログ・ファイルのオフセット位置"ｌ"においてイベント・ログ・ファイルにアペンドされる(ブロック１３２およびブロック１３４)。イベント・ログ・ファイルにおけるイベントの位置"l"を標示するエントリがイベント・インデックス・ファイルに書かれる。
【００３５】
図７の(Ｂ)には、本発明に従って、ストリーム・ログ・エントリを書くプロセスが示されている。ポストマスタ・デーモンは、ストリーム"x"から流入するイベントの通知を受け取る(ブロック１４２)。イベント・ログ・ファイルにおける対応するイベントの位置"l"は、該当するイベントを求めてイベント・インデックス・ファイルを探索することによって決定される(ブロック１４４)。イベントがログされているイベント・ログ・ファイルのセット番号ｓおよびイベントの位置"l"を標示するエントリがストリーム"x"に関するストリーム・ログ・ファイルに書かれる(ブロック１４６)。
【００３６】
図７の(Ｃ)には、本発明に従って、相互関係ログ・ファイルにエントリを書き込むプロセスが示されている。ポストマスタ・デーモンは、主要イベントｐおよび関連イベントｑを含む相互関係要求を受け取る(ステップ１５２)。イベント・ログ・ファイルにおける対応する関連イベントの位置"l"が、該当するイベントを求めてイベント・インデックス・ファイルを探索することによって決定される(ブロック１５４)。主要イベントｐを含み、イベントがログされているイベント・ログ・ファイルのセット番号ｓおよびイベントの位置"l"を標示するエントリが、相互関係ログ・ファイルに書き込まれる(ブロック１５６)。
【００３７】
図８には、図７の(Ａ)のブロック１３４においてイベント・ログ・ファイルへエントリをアペンドするステップの詳細が示されている。ブロック１６２において、イベント・ログが開いているか否か判断される。イベント・ログが開いていない場合、プロセスはブロック１６４へ進む。イベント・ログが開いていれば、プロセスはブロック１６８へ進む。ブロック１６４において、書き込みルーチンは、最も最近のイベントを含むイベント・ログ・ファイルを決定し、そのファイルのセット番号ｓを保存する。当業者に認められることであろうが、これは種々の方法で達成することが可能であるが、それはファイルの各々を開いて、そのファイルにおける最新のイベント・レコードのタイムスタンプを読み取ることを必要とする。ブロック１６６において、セット番号ｓを持つイベント・ログ・ファイルおよびイベント・インデックス・ファイルが開かれ、プロセスはブロック１６８へ進む。
【００３８】
ブロック１６８において、イベント・ログ・ファイルの現在のサイズが実行時に構成される最大サイズに達したか否かが判断される。イベント・ログ・ファイルの現在のサイズが最大サイズに達していなければ、プロセスはブロック１６４へ進み、イベントはイベント・ログ・ファイルへアペンドされる。イベント・ログ・ファイルの現在のサイズが最大サイズに達したとすれば、プロセスはブロック１７０へ進み、詳細は図１３を参照して後述されるが、セット番号および反復数が調整される。次に、プロセスは、ブロック１７２へ進み、書き込みルーチンによって現在開かれているアイルの各々毎に、次のステップが実行される。ファイルが閉じられる。新しいセット番号で同じストリーム名を持つ同じタイプのファイルが開かれる。そのファイルが切り捨てられる。新しい反復数"ｉ"を含む新しいファイル・ヘッダが書き込まれる。次にプロセスはブロック１７４へ進む。本発明が、いかなる特定のファイルのセット番号にもあるいはいかなる特定の反復数にも限定されないことは認められることであろう。
【００３９】
図１３には、上述の図８のブロック１７０におけるセット番号および反復数を調節するステップの詳細が示されている。ブロック１８０においてセット番号ｓが増分され、ブロック１８２において、最大セット番号と比較される。最大セット番号を上回っていれば、プロセスはブロック１８４へ進み、反復数が増分され、ブロック１８６において最大数と比較される。最大反復数を上回っていれば、反復数"i"は0にリセットされ(ブロック１８８)、プロセスはブロック１８９に進む。ブロック１８６において、最大反復数に達していない場合も、プロセスはブロック１８９に進む。ブロック１８９において、セット番号"s"は０へリセットされる。
【００４０】
図８および図１３に記述されているプロセスが、例示の目的から、０から３までのセット番号および０から９までの反復数を使用しているが、本発明は、いかなる特定のセット番号にもあるいはいかなる特定の反復数にも限定されるものではない。
【００４１】
図９には、図７の(B)のブロック１４６および図７の(Ｃ)ブロック１５６においてエントリをそれぞれのファイルへアペンドするステップの詳細が示されている。ブロック１９２において、ストリーム・ログ・ファイルまたは相互関係ログ・ファイルが現在開いているか否か判断される。ストリーム・ログ・ファイルまたは相互関係ログ・ファイルが現在開いている場合、プロセスはブロック１９８へ進む。そうでなくストリーム・ログ・ファイルまたは相互関係ログ・ファイルが現在開いていない場合、プロセスはブロック１９４へ進む。ブロック１９４において、書き込みルーチンの現在時セット番号およびストリームの名前を使用して、該当するストリーム・ログ・ファイルまたは相互関係ログ・ファイルが開かれる。最後に、ブロック１９６において、ストリームまたは相互関係情報が、開いているストリーム・ログ・ファイルまたは相互関係ログ・ファイルにアペンドされる。
【００４２】
図１０乃至図１２は、本発明に従ってイベントの流れおよびイベントの相互関係を再構築するプロセスを記述している。図１０には、イベント・ログ・ファイルを読み取ることによってポストマスタ・デーモンを通過するイベントの流れを再構築する本発明の方法２００が示されている。最初に、ブロック２０２において、イベント・ログの開始をマークするため、時間インデックスが目標時間t=0に設定される。次にブロック２０４において、読み取りルーチンは、ブロック２０２において目標時間が確立された後、開始時点で最も古いイベントを含む適切なイベント・ログ・ファイルを決定する。初期のイベント・ログ・ファイルを決定する種々の方法が存在することは、当業者には明らかであろう。イベント・ログ・ファイルの各々が開かれ、目標時間より最小限に大きいタイムスタンプを含む最初のイベントを持つイベント・ログ・ファイルを検出するため、フィルの最初のイベントのタイムスタンプが読み取られる。このステップには、こわれているイベント・ログ・ファイルがあればそれを識別して除去することが含まれる。イベント・ログ・ファイルのすべてが目標時間より古いイベントを含むとすれば、プロセスは停止する。
【００４３】
初期イベント・ログ・ファイルが決定されたならば、反復数(図４の記号７３)がファイル・ヘッダから読み取られる(ブロック２０６)。次に、ブロック２０８において、初期イベント・ログ・ファイルの各イベントがファイルから順次読み取られる。読み取りルーチンが書き込みルーチンと同時にイベント・ログ・ファイルを処理する可能性があるので、読み取りルーチンが現在読んでいるファイルを書き込みルーチンが修正する状況の発生を認識するように読み取りルーチンは注意しなければならない。この状況は、読み取り動作の不完全な終了、無効なイベントを伴う読み取り動作、または、イベントは有効であるが、ファイルが開かれた時ヘッダに含まれていた反復数と異なる反復数を含むイベントを生み出す読み取り動作によって、明らかになる。  読み取りが有効なイベントという結果につながらない場合、読み取りルーチンは、ファイルがこわれているか、読み取りルーチンが書き込みルーチンによって重ねられたと推定しなければならない。この場合、ブロック２０４に戻って、こわれていない初期イベント・ログ・ファイルを検出しなければならない。また、イベント・レコードにおける反復数がブロック２０６においてイベント・ログ・ファイルのヘッダから読み取られた反復数と等しくない場合も、読み取りルーチンは、ファイルがこわれているか、読み取りルーチンが書き込みルーチンによって重ねられたと推定しなければならない。この場合、ブロック２０４に戻って、こわれていない初期イベント・ログ・ファイルを検出しなければならない。
【００４４】
適切な初期イベント・ログ・ファイルが識別されたと仮定すれば、ブロック２０８において、イベント・ログ・ファイルの各イベント・エントリが順次読み取られる。各イベント・エントリが現在のイベント・ログから読まれた後、イベント・ログ・ファイルの次のイベント・エントリの読み取りに先立ちそのタイムスタンプtが保存される(ブロック２１０)。ブロック２１２において、イベント・ログ・ファイルのすべてのイベント・エントリが読み取られたか否か判断され、すべて読み取られたなら、プロセスはブロック２０４へ戻って、ログ・ファイルのすべてのイベント・エントリが順次読み取られるまで次のイベント・ログ・ファイルを検出するステップを継続する。ブロック２１２において、イベント・ログ・ファイルのすべてのイベント・エントリが読み取られていない場合、プロセスはブロック２０４へ戻る。
【００４５】
図１１には、ストリーム・ログ・ファイルを読み取ることによってポストマスタ・デーモンにおける関連イベントの単一の流れを通過するイベントを再構築する本発明の方法２２０が示されている。最初に、ブロック２２２において、ストリームの開始をマークするため、時間インデックスが目標時間t=0に設定される。次にブロック２２４において、読み取りルーチンは、ブロック２２２において目標時間が確立された後、開始時点で最も古いイベントを含む適切なストリーム・ログ・ファイルを決定する。初期のストリーム・ログ・ファイルを決定する種々の方法が存在することは、当業者には明らかであろう。ストリーム・ログ・ファイルの各々が開かれ、目標時間より最小限に大きいタイムスタンプを含む最初のレコードを持つストリーム・ログ・ファイルを検出するため、フィルの最初のレコードのタイムスタンプが読み取られる。このステップには、こわれているストリーム・ログ・ファイルがあればそれを識別して除去することが含まれる。ストリーム・ログ・ファイルのすべてが目標時間より古いイベントを含むとすれば、プロセスは停止する。
【００４６】
初期ストリーム・ログ・ファイルが決定されたならば、反復数(図５の参照符号１００)がファイル・ヘッダから読み取られる(ブロック２２６)。次に、ブロック２２８において、初期ストリーム・ログ・ファイルの各レコードがファイルから順次読み取られる。読み取りルーチンが書き込みルーチンと同時にストリーム・ログ・ファイルを処理する可能性があるので、読み取りルーチンが現在読んでいるファイルを書き込みルーチンが修正する状況の発生を認識するように読み取りルーチンは注意しなければならない。この状況は、読み取り動作の不完全な終了、無効なレコードを伴う読み取り動作、または、レコードは有効であるが、ファイルが開かれた時ヘッダに含まれていた反復数と異なる反復数を含むレコードを生み出す読み取り動作によって、明らかになる。読み取りが有効なレコードという結果につながらない場合、読み取りルーチンは、ファイルがこわれているか、読み取りルーチンが書き込みルーチンによって重ねられたと推定しなければならない。この場合、ブロック２２４に戻って、こわれていない初期ストリーム・ログ・ファイルを検出しなければならない。また、レコードにおける反復数がブロック２２６においてストリーム・ログ・ファイルのヘッダから読み取られた反復数と等しくない場合も、読み取りルーチンは、ファイルがこわれているか、読み取りルーチンが書き込みルーチンによって重ねられたと推定しなければならない。この場合、ブロック２２４に戻って、こわれていない初期イベント・ログ・ファイルを検出しなければならない。
【００４７】
適切な初期イベント・ログ・ファイルが識別されたと仮定すれば、ブロック２２８において、ストリーム・ログ・ファイルの各レコードが順次読み取られる。次のレコードに進む前に、ブロック２３０において、読み取られた有効レコードの各々のタイムスタンプ"t"、セット番号"s"および位置"l"が保存される。有効レコードが読み取られると、ブロック２３２において、読み取りルーチンは、セット番号"s"によって識別されるイベント・ログ・ファイルにおける所与の位置"l"にある実際のイベント"e"を見出す。この場合も、書き込みルーチンと読み取りルーチンが同時に同じファイルを処理する可能性があるので、イベントが検出されないか検出されてもそれがストリーム・ログ・エントリの後にログされたもので、そのため、無効と見なされる場合がある。この場合、読み取りルーチンは、有効なイベントが検出されるまで、ストリーム・ログ・ファイルにおける次のレコードに進む。
【００４８】
次に、ブロック２３４において、ストリーム・ログ・ファイルのすべてのイベント・エントリが読み取られたか判断され、読み取られたなら、次のストリーム・ログ・ファイルの処理のため、ブロック２２４へ戻る。すべてが読み取られていない場合、プロセスは、ブロック２２８へ戻って。れこーを十次読み取る。
【００４９】
図１２には、相互関係ログ・ファイルを読み取ることによって所与のイベントに関連づけられたすべてのイベントを検出する本発明の方法２４０が示されている。所与の主要イベントに関連づけられたすべての関連イベントを検出するプロセスは、すべての相互関係ログ・ファイルのレコードを順次走査して、主要イベントの所与のイベントＩＤを探し出すことから始まる(ブロック２４２)。次に、ブロック２４４において、探し出された各レコード毎に、セット番号および位置番号によって標示される関連または２次イベントが適切なイベント・ログ・ファイルから読み取られる。ブロック２４６において、以前に保存された位置"l"およびセット番号のイベントが、合致するイベントを読み取るため使用される。
【００５０】
この場合も、合致イベントが有効でないことがあり得る。読み取りルーチンが書き込みルーチンと同時に動作して、そのため、イベントが検出されないか、検出されたイベントが相互関係ログのエントリが書き込まれた後にログされたものである可能性があるため、イベントが有効でないと見なされる場合がある。この場合、読み取りルーチンは単に相互関係ログの次のレコードの走査を続ける。この場合、プロセスは、ブロック２４４に戻って、次の合致レコードのセット番号および位置番号"l"を保存する。イベントを検出すると関連イベントが読み取られる。このプロセスは、主要イベントに関連させられたすべての有効な関連イベントが検出され読み取られるまで、続行する。
【００５１】
以上、本発明を特定の実施形態を参照して記述したが、本発明の理念を逸脱することなく上記実施形態の種々の変更を加えることが可能である点は当業者に理解されることであろう。
【００５２】
本発明には、例として次のような実施様態が含まれる。
【００５３】
（１）管理対象環境におけるイベントをログする方法であって、セントラル・ブローカによって１つまたは複数のイベントに関して管理対象環境を監視するステップ(a)と、セントラル・ブローカによって１つまたは複数のイベントを受け取るステップ(b)と、セントラル・ブローカによってイベントが受け取られる都度、言語独立形式でイベントの完全な表現をイベント・ログ・ファイルにアペンドし、イベント・ログ・ファイルにおけるイベントの位置をイベント・インデックス・ファイルに書き込むことによって、イベントをイベント記憶機構にログするステップ(c)と、１つまたは複数のイベントに関してイベントを受け取る上記ステップ(b)およびイベントをログする上記ステップ(c)を反復するステップ(d)と、を含む、イベント・ログ方法。
【００５４】
（２）イベントの完全な表現をイベント・ログ・ファイルへアペンドする上記ステップが、イベント・ログ・ファイルが開いているか否か判断するステップ(a)と、イベント・ログ・ファイルが開いていれば、最も新しいイベント・ログ・ファイルを決定して、その最も新しいイベント・ログ・ファイルのセット番号を保存して、当該最も新しいイベント・ログ・ファアイルおよび上記セット番号を持つイベント・インデックス・ファイルを開くステップ(ｂ)と、イベント・ログ・ファイルが最大サイズに達しているか否かを判断するステップ(c)と、イベント・ログ・ファイルが最大サイズに達していれば、セット番号カウンタおよび反復カウンタを調節して、開いているイベント・ログ・ファアイル毎に、イベント・ログ・ファイルを閉じ、新しいセット番号を持つイベント・ログ・ファイルを再度開き、そのファイルを切り捨て、イベント・ログ・ファイルの新しいファイル・ヘッダを書き込むステップ(d)と、イベントをイベント・ログ・ファイルにアペンドするステップ(e)と、を含む、上記（１）に記載のイベント・ログ方法。
【００５５】
（３）１つまたは複数のイベントを受け取りイベント記憶機構へログした後、ストリームから流れるストリーム・イベントの通知を受け取るステップと(a)、イベント・ログ・ファイルにおけるストリーム・イベントの位置を決定するステップ(b)と、１つまたは複数のストリーム・ログ・ファイルのストリーム・ログ・ファイルにイベント・ログ・ファイルにおけるストリーム・イベントの位置をアペンドすることによってイベント記憶機構にストリーム・イベントをログするステップ(c)と、を更に含む、上記（１）に記載のイベント・ログ方法。
【００５６】
（４）イベント・ログ・ファイルにおけるストリーム・イベントの位置をストリーム・ログ・ファイルにアペンドする上記ステップが、ストリーム・ログ・ファイルが開いているか否か判断するステップ(a)と、ストリーム・ログ・ファイルが開いていない場合、ストリーム・ログ・ファイルを開いてストリーム・ログ・ファイルにストリーム・ログ・ファイル・ヘッダを書き込むステップと(b)、ストリーム・ログ・ファイルにストリーム・イベントの位置を書き込むステップ(c)と、を含む、上記（３）に記載のイベント・ログ方法。
【００５７】
（５）１つまたは複数のイベントを受け取りイベント記憶機構へログした後、主要イベントおよび関連イベントに関する相互関係要求を受け取るステップ(a)と、イベント・ログ・ファイルにおける関連イベントの位置を決定するステップ(b)と、イベント・ログ・ファイルにおける関連イベントの位置を相互関係ログ・ファイルにアペンドすることによって関連イベントをイベント機構機構にログするステップ(c)と、を含む、上記（１）に記載のイベント・ログ方法。
【００５８】
（６）イベント・ログ・ファイルにおける関連イベントの位置を相互関係ログ・ファイルにアペンドする上記ステップが、相互関係ログ・ファイルが開いているか否か判断するステップ(a)と、相互関係ログ・ファイルが開いていなければ、相互関係ログ・ファイルを開き、相互関係ログ・ファイルに相互関係ログ・ファイル・ヘッダを書き込むステップ(b)と、相互関係ログ・ファイルに関連イベントの位置を書き込むステップ(c)と、を含む、上記（５）に記載のイベント・ログ方法。
【００５９】
（７）管理対象環境を通過するすべてのイベントの流れを再構築する方法であって、１つまたは複数のイベントのログの開始を表す目標時間を確立するステップ(a)と、目標時間に対して最も古いイベントを含む１つまたは複数のイベント・ログ・ファイルの初期イベント・ログ・ファイルを識別するステップ(b)と、初期イベント・ログ・ファイルを開き、初期イベント・ログ・ファイルのヘッダの反復数を読み取るステップ(c)と、初期イベント・ログ・ファイルの各イベント・エントリを順次読み取るステップ(d)と、初期イベント・ログ・ファイルの各イベント・エントリの反復数が初期イベント・ログ・ファイルのヘッダの反復数と合致することを検証し、読み取られている初期イベント・ログ・ファイルの各イベント・エントリのセット番号、位置およびタイムスタンプを保存するステップ(e)と、タイムスタンプに対して最も古いイベントを含む１つまたは複数のイベント・ログ・ファイルの後続のイベント・ログ・ファイルを識別するステップ(f)と、１つまたは複数のイベント・ログ・ファイルの後続のイベント・ログ・ファイルを開いて、後続のイベント・ログ・ファイルのヘッダの反復数を読み取るステップ(g)と、後続のイベント・ログ・ファイルの各イベント・エントリを順次読み取るステップ(h)と、後続イベント・ログ・ファイルの各イベント・エントリの反復数が後続イベント・ログ・ファイルのヘッダの反復数と合致することを検証し、読み取られている後続イベント・ログ・ファイルの各イベント・エントリのセット番号、位置およびタイムスタンプを保存するステップ(i)と、１つまたは複数のイベント・ログ・ファイルの各イベント・ログ・ファイル毎に上記(f)乃至(i)のステップを繰り返すステップ(j)と、を含むイベント流れ再構築方法。
【００６０】
（８）１つまたは複数のストリーム・ログ・ファイルを読み取ることによってセントラル・ブローカにおける単一ストリームからの１つまたは複数のイベントの流れを再構築する方法であって、ストリーム開始を表す目標時間を確立するステップ(a)と、目標時間に対して最も古いストリーム・イベントを含む１つまたは複数のストリーム・ログ・ファイルの初期ストリーム・ログ・ファイルを識別するステップ(b)と、初期ストリーム・ログ・ファイルを開き、初期ストリーム・ログ・ファイルのヘッダの反復数を読み取るステップ(c)と、初期ストリーム・ログ・ファイルの各ストリーム・イベント・レコードを順次読み取るステップ(d)と、初期ストリーム・ログ・ファイルの各ストリーム・イベント・レコードの反復数が初期ストリーム・ログ・ファイルのヘッダの反復数と合致することを検証し、読み取られている初期ストリーム・ログ・ファイルの各ストリーム・イベント・レコードのセット番号、位置およびタイムスタンプを保存するステップ(e)と、位置およびセット番号を使用してイベント・ログ・ファイルにおけるストリーム・イベントを検出するステップ(f)と、タイムスタンプに対して最も古いストリーム・イベントを含む１つまたは複数のストリーム・ログ・ファイルの後続ストリーム・ログ・ファイルを識別するステップ(g)と、後続ストリーム・ログ・ファイルを開き、後続ストリーム・ログ・ファイルのヘッダの反復数を読み取るステップ(h)と、後続ストリーム・ログ・ファイルの各ストリーム・イベント・レコードを順次読み取るステップ(i)と、後続ストリーム・ログ・ファイルの各ストリーム・イベント・レコードの反復数が後続ストリーム・ログ・ファイルのヘッダの反復数と合致することを検証し、読み取られている後続ストリーム・ログ・ファイルの各ストリーム・イベント・レコードのセット番号、位置およびタイムスタンプを保存するステップ(j)と、位置およびセット番号を使用してイベント・ログ・ファイルにおけるストリーム・イベントを検出するステップ(ｋ)と、１つまたは複数のストリーム・ログ・ファイルの各ストリーム・ログ・ファイル毎に上記ステップ(g)乃至ステップ(j)を繰り返すステップ(l)と、を含むイベント流れ再構築方法。
【００６１】
（９）１つまたは複数の相互関係ログ・ファイルを読み取ることによって１つまたは複数の主要イベントに関連づけられたすべての関連イベントを検出する方法であって、主要イベントに関連付けられた関連イベントを検出するため、相互関係ログ・ファイルを走査するステップ(a)と、関連イベントの位置およびセット番号を保存するステップ(b)と、位置およびセット番号を使用してイベント・ログ・ファイルにおける関連イベントを検出するステップ(c)と、主要イベントに関連付けられた１つまたは複数の関連イベントの各々毎に上記ステップ(a)乃至ステップ(c)を繰り返すステップ(ｄ)と、を含む、関連イベント検出方法。
【００６２】
（１０）管理対象環境におけるイベントをログし、順序だった取り出しを可能にするネットワーク・システムであって、１つまたは複数のイベントに関して管理対象環境を監視し、該１つまたは複数のイベントを受け取るセントラル・ブローカ(a)と、
複数のセットに構成された複数の非テキスト・ファイルを有し、セントラル・ブローカによって受け取られる都度受け取られた順序で１つまたは複数のイベントの各イベントがそれらファイルにログされる、イベント記憶機構(b)と、を備え、上記イベント記憶機構のイベント・ログ・ファイルが、１つまたは複数のイベントをローカル言語にフォーマットすることを可能にする形式の１つまたは複数のイベントの完全な表現を含み、イベント・ログ・ファイルにおける１つまたは複数のイベントの位置を保持するイベント・インデックス・ファイルを更に含む、ネットワーク・システム。
【００６３】
【発明の効果】
第１に、本発明は、従来技術の限られたイベント・プレゼンテーションに比較して利点を持つ。ポストマスタ・デーモンによって受け取られるオリジナルのイベント情報の完全な表現が、本発明によってイベント記憶機構に書き込まれる。本発明において、イベント機構ファイルが完全なイベント・データを保持するので、ブラウザによってイベント・データ全体が読み取られることが可能とされる。第２に、本発明は、従来技術のローカル言語サポートに比較して利点を持つ。本発明において、オリジナルのイベント情報が、プレゼンテーションのため異なるローカル言語に選択的に再フォーマットされることができる非テキスト形式でイベント記憶機構に書き込まれる。最後に、本発明は、従来技術ストリーム処理に対して利点を持つ。本発明は、イベントが複数のイベント・ストリームとして見えるように、複数のイベントを所与のストリームと関連付けることができる。
【図面の簡単な説明】
【図１】従来技術に従ったtrapd.logファイルを利用するネットワーク・システムを示すブロック図である。
【図２】本発明に従ったイベント記憶機構を含むネットワーク・システムを示すブロック図である。
【図３】本発明に従ったイベント記憶機構への書き込みと読み取りの関係を示すオブジェクト・モデルのブロック図である。
【図４】本発明に従ったイベント・ログ・ファイルの形式を示すブロック図である。
【図５】本発明に従ったストリーム・ログ・ファイルの形式を示すブロック図である。
【図６】本発明に従った相互関係ログ・ファイルの形式を示すブロック図である。
【図７】本発明に従った、イベント論理ログ要求を処理する書き込みルーチン、ストリーム・ログ・エントリの書き込み、および、相互関係ログ・エントリの書き込みのそれぞれのプロセスの流れ図である。
【図８】本発明に従ってエントリをイベント・ログにアペンドするプロセスの流れ図である。
【図９】本発明に従ってエントリをストリーム・ログ・ファイルおよび相互関係ログ・ファイルにアペンドするプロセスの流れ図である。
【図１０】本発明に従ってイベント・ログ・ファイルを読み取ることによってポストマスタ・デーモンを通るイベントの流れを再構築するプロセスの流れ図である。
【図１１】本発明に従ってストリーム・ログ・ファイルを読み取ることによって、ポストマスタ・デーモンにおける関連イベントの単一ストリームを通るイベントの流れを再構築するプロセスの流れ図である。
【図１２】本発明に従って相互関係ログ・ファイルを読み取ることによって、所与のイベントに関連づけられたすべてのイベントを検出するプロセスの流れ図である。
【図１３】図８のセット番号／反復数カウンタを調整するステップの詳細な流れ図である。
【符号の説明】
２０      管理対象環境
２４      イベント記憶機構
４０      セントラル・ブローカまたはポストマスタ
７０      イベント・ログ・ファイル
【図１】
0003655486.tif 000002
【図２】
0003655486.tif 000003
【図３】
0003655486.tif 000004
【図４】
0003655486.tif 000005
【図５】
0003655486.tif 000006
【図６】
0003655486.tif 000007
【図７】
0003655486.tif 000008
【図８】
0003655486.tif 000009
【図９】
0003655486.tif 000010
【図１０】
0003655486.tif 000011
【図１１】
0003655486.tif 000012
【図１２】
0003655486.tif 000013
【図１３】
0003655486.tif 000014