JP2000040063A

JP2000040063A - レポ―ト・フィ―ルド取り出し方法

Info

Publication number: JP2000040063A
Application number: JP11143669A
Authority: JP
Inventors: Brian Costa; ブライアン・コスタ; Chris P Das; クリス・ピー・ダス; William C Kepner; ウィリアム・シー・ケプナー
Original assignee: Hewlett Packard Co
Current assignee: HP Inc
Priority date: 1998-05-29
Filing date: 1999-05-24
Publication date: 2000-02-08
Also published as: DE69833723T2; EP0961439B1; US6138121A; DE69833723D1; EP0961439A2; EP0961439A3

Abstract

(57)【要約】【課題】レポート作成アプリケーションが適切な情報を
容易に取り出すことを可能にするような形態でネットワ
ークのイベント・データを保存する方法を提供する。【解決手段】本発明のエクスポート管理モジュールが複
数イベント・フィールドを含むシステム・イベントを受
け取り、複数のイベント・フィールドのうち特定レポー
トの生成にとって不可欠なイベント・フィールドを含む
レポート準備状態テーブルへ記憶する。レポート準備状
態テーブルは、標準通信インタフェースを経由してデー
タウェアハウスに送られ、そこに保存される。このよう
にして、レポート作成アプリケーションがレポート作成
に必要なすべてのフィールドをレポート準備状態テーブ
ルに対する単一の照会で取り出すことができる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、一般にネットワー
ク管理に関するもので、特に、ネットワーク管理システ
ムのイベント・データを保存して傾向の追跡および有用
なレポートを作成する際の使用のため情報の効果的取り
出しおよび集計を可能にするデータ・スキーマおよび方
法に関するものである。

【０００２】

【従来の技術】従来技術のネットワーク管理システム
は、ASCIIテキスト形式で、典型的には順次データスト
リーム形式でネットワーク・システムのイベント情報を
収集してきた。ネットワーク・システム管理者は、正常
なシステム使用の予防的保守のためシステム傾向を通知
するため、収集されたシステム・イベントに基づいた統
計およびレポートを必要とする場合が多い。一般的に
は、この情報は、集合的に本明細書においてレポート作
成アプリケーションと呼ばれる外部統計プロセス制御お
よび傾向追跡アプリケーションによって、順次ASCIIテ
キストのイベント・ファイルから導出される。そのよう
なアプリケーションは、イベント・ファイルから情報を
収集、処理および書式化して、ユーザが読み取ることが
できるレポートを生成する。

【０００３】しかしながら、過去においては、必要とさ
れる情報を導出してレポートを作成するため、レポート
作成アプリケーションの各々はイベント・ファイルの内
容のシステム特有形式を知っていなければならなかっ
た。すなわち、レポート作成アプリケーションは、シス
テム特有イベント・ファイル形式でそのアプリケーショ
ンを分離してコンパイルするか、または、設定時または
実行時にイベント形式情報をアプリケーションに供給す
るか、いずれかによって、イベント・ファイルに保存さ
れているイベント・データのシステム特有形式を認識し
ていなければならなかった。このように、そのようなア
プリケーションを利用するためには、アプリケーション
開発者は、イベント・ファイル形式をサポートするなん
らかの手段を提供しなければならなかった。公式の標準
化されたデータ・スキーマ、そのようなスキーマを実施
する方法、および種々のレーポート作成の元となる情報
を容易に導出する方法に対する必要性が当業界に存在す
る。

【０００４】加えて、システム・イベントのカテゴリは
種々異なるため、かならずしもすべてのシステム・イベ
ントが同じ量の情報を含むとは限らない。従来技術のい
くつかの実施形態においては、どのようなタイプのシス
テム・イベントに関しても標準サイズのシステム・イベ
ント・パケットを割り当て、各イベント・タイプに関し
てパケットの範囲内でフィールド定義を変更し、異なる
タイプのシステム・イベントに関して異なるレポート情
報を利用できるようにさせることによって、この問題が
取り扱われてきた。この技術は、異なるタイプのシステ
ム・イベントでレポートされる情報にいくらかの余裕を
与えるとはいえ、システム・イベント・パケットの標準
サイズが、最大長のシステム・イベント情報を持つタイ
プのシステム・イベントを保存することができるほど十
分な大きさであることを必要とする。この結果、標準サ
イズのシステム・イベント・パケットの最大サイズを必
要としないシステム・イベントに関して割り当てられは
するが使用されないイベント・パケッジ内のバイトが存
在するため、メモリ効率は大幅に悪くなる。従って、必
要とされる記憶空間量に従って動的にシステム・イベン
トを保存する方法およびデータ・スキーマに対する必要
性が存在する。

【０００５】この問題を克服する１つの方法は、すべて
のイベントに共通なフィールドだけを含む標準サイズの
システム・イベント・パケットを定義して、システム・
イベントのタイプに従ってサイズ的に変化することがで
きる可変結合パケットに、定義した標準サイズ・システ
ム・イベント・パケットをリンクするものである。この
技術は、イベント・フィールドの数および定義が異なる
システム・イベント・タイプの間の変動を許容し、最大
メモリ効率を保証する。しかしながら、システム・イベ
ントに関して役立つレポートを作成するために必要なデ
ータを取り出すのは難しい。

【０００６】

【発明が解決しようとする課題】レポート作成アプリケ
ーションは、一時点に２、３のカテゴリに従ってイベン
ト情報を構成し、システム管理者にとって有用な方法で
それらカテゴリに関連する情報を要約する。レポートを
作成する際に、アプリケーションは、各イベントに関し
て詳細なシステム・イベント・データ全体の中の小さな
サブセットだけを典型的には利用する。しかしながら、
上述の従来技術イベント保存技術では、イベント・フィ
ールドの完全な詳細セットからフィールドの該当サブセ
ットを取り出すためには、各イベントに関して必要とさ
れるイベント・フィールドに対するデータベース上の独
立した照会を必要とする。大量のイベント・データを処
理する時、または、アプリケーションが各イベントに関
して２、３以上のイベント・フィールドを必要とする
時、データベースに対する大量の照会がシステムの処理
性能を劣化させる。従って、レポート作成アプリケーシ
ョンが適切な情報を容易に取り出すことを可能にするよ
うな形態でイベント・データを保存する方法に対する必
要性が存在する。

【０００７】

【課題を解決するための手段】発明の課題を解決する手
段として、本発明は、ネットワーク管理システムのイベ
ント・データウェアハウスから一組のレポート・フィー
ルドを取り出す方法を提供する。該方法において、所与
のイベントに関して上記データウェアハウスに保存され
る上記一組のレポート・フィールドがネットワーク管理
システムのイベントを集合的に形成する複数のイベント
・フィールドを含み、更に上記一組のレポート・フィー
ルドが上記複数イベント・フィールドのうちのレポート
作成にとって不可欠なイベント・フィールドの各々を含
むレポート準備状態テーブルに保存される。該方法は、
複数のイベント・フィールドを含むネットワーク管理シ
ステム・イベントを受け取るステップ、上記ネットワー
ク管理システム・イベントから上記複数のイベント・フ
ィールドのうちのレポート作成にとって不可欠な少なく
とも第１のセットのイベント・フィールドを抽出するス
テップ、および、上記複数のイベント・フィールドの上
記第１のセットをレポート作成のためレポート作成アプ
リケーションによって使用される上記レポート準備状態
テーブルに保存するステップを含む。

【０００８】ネットワーク管理システムのイベント・デ
ータを保存して、システム傾向の追跡および有用なレポ
ートを作成する際の使用のため情報の効果的取り出しお
よび集計を可能にするデータ・スキーマおよび方法が提
供される。本発明は、標準インタフェースを経由してユ
ーザにとって一般的に利用できる標準化されたシステム
・イベント形式を、その実施方法と共に、提供する。デ
ータは、統計プロセス制御アプリケーション、傾向追跡
アプリケーションおよびレポート作成アプリケーション
が標準インタフェース経由で容易にアクセスできるもの
である。この標準インタフェースは、情報の価値を増加
させる、有用な形態でイベントに関する関心のある情報
を提示する。

【０００９】本発明に従って、エクスポート管理モジュ
ールが複数イベント・フィールドを含むシステム・イベ
ントを受け取る。エクスポート管理モジュールは、イベ
ント・フィールドの第１のセットを、特定レポートの生
成にとって不可欠なすべての利用できるイベント・フィ
ールドを含むレポート準備状態テーブルへフォーマット
する。レポート準備状態テーブルは、標準通信インタフ
ェースを経由してデータウェアハウスに送られ、そこに
保存され、レポート作成アプリケーションが標準通信イ
ンタフェース(例えば単一照会)を経由してアクセスする
ことができる状態に置かれる。リレーショナル・データ
ベースにおける複数テーブルの使用が、データ検索また
はレポート作成のための構造化照会言語(すなわちＳＱ
Ｌ)に役立つ。集計機能が、収集されたデータを要約し
て、各ノードに起こる各イベント・タイプのイベント・
カウントを維持する。切り取り機能が、データが集計さ
れた後データウェアハウスから不必要なデータを削除す
る。イベント・データがデータウェアハウスに保管され
ない条件を指定するため、フィルタ機能が利用できる。

【００１０】データウェアハウスは、各々が特定のイベ
ントまたはイベント・タイプに関連づけられる複数の関
連テーブルにイベント・データを保存する。テーブル
は、所与のイベントに関して利用できるイベント・フィ
ールドのうち特定のレポート・タイプに関連するサブセ
ットを含むレポート準備状態イベント・テーブルを含
む。次に、その特定タイプのレポートを実行するレポー
ト作成アプリケーションが、所与のイベントに関するす
べての必要なフィールドに単一照会でアクセスすること
ができるので、システムの処理性能が向上する。

【００１１】

【発明の実施の形態】図１は、本発明に従ったシステム
のブロック図である。イベント１０１がネットワーク管
理システム(図示されていない)によって収集される。イ
ベント１０１は、システム・ハードウェア、オペレーテ
ィング・システムおよびネットワーク上で動作するアプ
リケーションによって生成される。イベント１０１は、
典型的には、ネットワーク上の種々のイベント発生をシ
ステム管理者に通報するものであり、ネットワークの状
態がそこから導出される。典型的なシステム・イベント
は種々のカテゴリに分類できる。それらカテゴリには、
ネットワーク・エレメントの追加、削除、起動または故
障を標示するイベント、ネットワーク・エレメントが臨
界状態に到達したことを標示するイベント、特定のネッ
トワーク資源に関してあらかじめ定義されたしきい値を
越えたことを標示するイベント、および、潜在的認証問
題が発生したことを標示するイベントが含まれる。

【００１２】イベント１０１は、典型的には、ネットワ
ークの範囲内における異常な状況を標示する通報または
警告としてＳＮＭＰトラップによって生成される。典型
的には、ネットワークのオペレーティング・システム
は、イベントを種々の処理アプリケーションに仕向ける
イベント仕向けデーモンを通してトラップを処理する。
イベントのタイプおよびそれらが持つ重大性の度合いに
応じて、種々の反応型ネットワーク管理活動が、ソフト
ウェア・プロセスを起動し、あるいは、システム管理者
に警報を送って、問題の解決に導く。

【００１３】エクスポート管理モジュール１０２がイベ
ント１０１を受け取る。１つの実施形態において、エク
スポート管理モジュール１０２は、イベント１０１がネ
ットワーク管理システム(図示されていない)によってリ
アルタイムで記憶されるイベント・レポジトリ(図示さ
れていない)からイベント１０１を取り出すようにスケ
ジュールされる。代替実施形態においては、エクスポー
ト管理モジュール１０２は、イベントが発生する都度リ
アルタイムでネットワーク管理システムから直接イベン
ト１０１を受け取る。各イベント１０１は、イベント・
タイプに従って長さが変わる一連の生のデータ・バイト
である。後掲の表１は、エクスポート管理モジュール１
０２によって受け取られるいくつかのイベント１０１の
１つの例を示す。表１には、受け取られた生のデータの
各セットに対して、その対応するイベントの生データの
ＡＳＣＩＩ疑似解釈が含まれている。疑似解釈部分は、
システム管理者がネットワークの状態を判断しネットワ
ーク問題および傾向を正確に把握するため現在時点のシ
ステムにおいて判読するものである。有意な情報を取り
出すため疑似解釈ファイルを処理することは、熟練した
管理者によってのみ実践される技術である。

【００１４】表１は、１つのイベントの例に関して受け
取られた生のデータストリームを示している。このイベ
ントの疑似解釈は次の通りである。

【００１５】「"mercutio.cnd.hp.com"という機械上で
動作し、２５０ユーザをサポートする"Network Node Ma
nager"というソフトウェア・アプリケーションのライセ
ンスはTue Jul 28 1998の11:25:30に期限終了となる。
この事象はFri May 29 1998の11:27:49に生成された。
このイベントのオブジェクトＩＤは"1.3.6.1.4.11.2.1
7.1.0.59179231"である。」エクスポート管理モジュール１０２は、各イベント・タ
イプに関して異なる定義を可能にする公式データ・スキ
ーマに各イベント１０１をフォーマットする。公式デー
タ・スキーマは、種々のタイプの情報レポートに適切な
情報を効率的に取り出すことができるような形態でイベ
ント１０１のイベント・フィールドを記憶するテーブル
・セットを含む。このように、実行が見込まれるレポー
トのタイプに従って、その特定タイプのレポートにとっ
て不可欠なイベント・フィールドだけが対応するテーブ
ル・タイプに保存される。各イベントは、それに関連す
る複数の異なるテーブルを持つことができるが、それら
テーブルの各々は、少なくとも１つの異なるフィールド
を保存する点で相互に異なる。従って、アプリケーショ
ンが特定タイプのレポートに関連する情報を必要とする
時、そのイベントに欠かすことのできない情報のすべて
を取得するため、当該タイプのレポートに関連する適切
なテーブルに対して単一の照会が実行される。

【００１６】各テーブルは、そのタイプのレポートに必
要とされるすべての必須のイベント・フィールドを含む
ように定義される。図２は、イベント・フィールド２０
１、２０２、２０３、２０４および２０５を持つイベン
トに関する本発明の公式データ・スキーマに従ったオブ
ジェクト２００のインスタンスの例を示す。オブジェク
ト２００は、１つのタイプだけのイベントのオブジェク
トのインスタンスを示している。しかし、前述のよう
に、各イベント・タイプはどのような数の異なるレポー
ト準備状態テーブルをも含むことが可能である。この例
においては、オブジェクト２００は、第１のレポート・
タイプでフォーマットされた第１のテーブルevent_tabl
e_A２１０を含む。この第１のテーブルevent_table_A２
１０は、イベント・フィールドevent_field_1２０１、e
vent_field_2２０２およびevent_field_3２０３を含
む。オブジェクト２００は、また、第２のレポート・タ
イプでフォーマットされた第２のテーブルevent_table_
B２２０を含む。この第２のテーブルevent_table_B２２
０は、イベント・フィールドevent_field_1２０１、eve
nt_field_4２０４およびevent_field_5２０５を含む。
この例において、第１のタイプのレポート作成が実行さ
れるとすれば、event_table_A２１０に対する照会が実
行され、１回の対話でイベント・フィールド２０１、２
０２および２０３のすべてが取得される。同様に、第２
のタイプのレポート作成が実行されるとすれば、event_
table_B２２０に対する照会が実行され、１回の対話で
イベント・フィールド２０１、２０４および２０５のす
べてが取得される。このように、特定タイプのレポート
作成にとって不可欠なあらゆるイベント・フィールドに
関してイベント・オブジェクトに対する別々の照会を実
行する必要性または特定タイプのレポート作成にとって
不必要な情報を取り出す必要性が回避される。

【００１７】図１を再び参照すれば、イベント１０１を
その適切なテーブルにフォーマットした後、エクスポー
ト管理モジュール１０２はフォーマットされたイベント
１０３を標準通信インタフェースを使用してデータウェ
アハウス１１１に送る。本実施形態において、フォーマ
ットされたイベント・データ１０３は、既知のマイクロ
ソフトのOpen Data Base Connectivity(以下ＯＤＢＣと
略称する)アプリケーション・プログラミング・インタ
フェース(ＡＰＩ)を使用してデータウェアハウス１１１
に送られる。ＯＤＢＣは、異質の構造化照会言語(ＳＱ
Ｌ)データベースにアクセスするための共通インタフェ
ースであって、単一アプリケーションが共通コード・セ
ットを介して異なるＳＱＬデータベース管理システム
(ＳＤＭＳ)にアクセスすることを可能にする。これは、
アプリケーション開発者が特定のＤＢＭＳを目標としな
いアプリケーションを構築し分配することを可能にす
る。目標ＤＢＭＳ上で動くデータベース・ドライバがア
プリケーションをユーザのＤＢＭＳにリンクさせる。

【００１８】データウェアハウス１１１は、イベント１
０１のイベント・タイプに関して定義される公式データ
・スキーマに従ってフォーマットされたイベント・デー
タ１０３を保存する。データウェアハウス１１１に保存
されたイベント・データは、標準インターフェース１０
８(すなわち本実施形態においてはＯＤＢＣ)を通してア
クセス可能であり、それによって、異なるＤＢＭＳに基
づくシステム上で動作するレポート作成アプリケーショ
ン１１２によるデータへのアクセスが可能とされる。

【００１９】時間の経過と共に、データウェアハウス１
１１に次第に多くのデータが蓄積され、各イベントの詳
細な情報がさほど重要でなくなる状況となる場合があ
る。集計機能１０４が、イベントのすべての詳細を保持
せずにイベントに関する情報を要約するための方法を提
供する。この機能は、破棄されるイベントに関する要約
情報を保持しながらイベントの詳細をデータウェアハウ
ス１１１から破棄することを可能にすることによって、
利用できるデータベース容量を維持することに役立つ。
要約情報によって、アプリケーションは、(例えば特定
ノード上の特定タイプのイベントの出来事の頻度のよう
な)長期的照会に応答することができる。

【００２０】例えば、本実施形態において、集計機能１
０４は、各ネットワーク・ノード毎にイベント・タイプ
をカウントして、(例えば日、週および月毎のような)可
変的期間にわたるこれらイベントの発生回数を記録す
る。このようにして、システム管理者は、その通算記録
を見て、例えば、特定ノードがｎ回の特定イベント・タ
イプを持ったことを判断することができる。この情報の
重要性はイベント・タイプに依存する。例えば、イベン
ト・タイプがnode_up(ノード起動)であれば、通算記録
は、ある１ヶ月に特定ノードがｘ回のnode_upイベント
を経験し、年間にわたってその回数がｘからｘ＋ｙへ増
加することを明らかにする。この状況は、そのノード上
でのnode_upイベントが増加する傾向を明らかにし、そ
のノードに問題が存在することをシステム管理者へ通告
することができる。換言すれば、集計機能１０４は、イ
ベントを要約し、イベントの履歴を保持し、古いイベン
トの詳細をデータウェアハウス１１１から削除する点で
役立つ。このように、集計機能１０４は、時間の経過に
わたるネットワーク活動のプロファイルを反映すること
によって管理者へなんらかの価値を提供する。

【００２１】切り取り機能１０６は、データウェアハウ
ス１１１から詳細イベントを削除または部分的に削除す
る。切り取り機能は、詳細イベントが集計機能１０４に
よって要約された後に実行されることが望ましい。

【００２２】ネットワーク管理システムは、しばしば、
システム上の正常な出来事を通知するだけのイベントを
生成する。大量のこのようなタイプのイベントはシステ
ム管理者にとって迷惑と見られることが多い。フィルタ
機能１１０は、一定の正常な出来事イベントのようなユ
ーザが定義した迷惑イベントをフィルタリングする機能
を提供する。本実施形態において、フィルタ機能は、特
定ノード上のすべてのタイプのイベント、特定ノード上
の特定タイプのイベント、または、すべてのノード上の
特定タイプのイベントが保存されるべきではないことを
ユーザが指定することを可能にする。例えば、ノードｎ
上の１つの装置が起動また停止するようにスケジュール
されていることが知られているとすれば、それらが単に
ネットワークを通ってデータウェアハウス１１１に記録
されるトラフィックを生成するにすぎないので、ユーザ
はそのようなイベントが保存されることを望まない。

【００２３】図３は、イベントがデータウェアハウス１
１１に保存される様態の１例を示している。図３には
２、３のイベント・テーブルだけが図示されているが、
一般に使用されているデータウェアハウス１１１は、典
型的には、多数のイベント・テーブルを保存する。テー
ブルは、オブジェクト３１０ａ、３１０b、３２０ａ、
３２０b、３３０ａ、３３０bに保存される。オブジェク
ト３１０aおよび３２０ａにおけるそれぞれのテーブ
ル、それぞれの"共通の普遍的ユニークな識別子(common
universally unique identifier)"フィールドevent_uu
idによって連結されている。オブジェクト３２０ａおよ
び３２０ｂにおける集計テーブルは、"共通のユニーク
なオブジェクト識別子(common unique object identifi
er)"フィールドevent_oidによって連結されている。所
与のイベント・タイプに関して定義されるテーブルの組
合せは、イベント・タイプに関して実行されるレポート
作成タイプに依存する。従って、例えば、イベント・タ
イプＡは、可用性レポートには役立つが、しきい値違反
レポートには役立たないので、可用性テーブル３１６を
含むように定義されている。対照的に、イベント・タイ
プＢは、可用性レポートには役立たないが、しきい値突
破レポートには役立つので、しきい値テーブル３１８を
含むように定義されている。

【００２４】好ましい実施形態において、各イベント・
タイプの記憶域は、１つまたは複数のテーブル・クラス
によって定義される。それらテーブル・クラスには、ev
ent_detail_table３１２、event_varbinds_table３１
４、event_availability_table３１６、event_threshol
d_table３１８、event_daily_table３２２、event_week
ly_table３２４、event_monthly_table３２６およびeve
nt_filter_table３３０が含まれる。ここに定義された
テーブルへのアクセスをサポートする更に別のテーブル
も存在することもできる。これらテーブルの各々に関す
るクラス定義は、後掲の表２に含まれている。

【００２５】詳細テーブルevent_detail_table３１２
は、すべてのイベント・タイプに共通のイベント・フィ
ールドを含む。好ましい実施形態において、詳細テーブ
ルはすべての共通イベント・フィールドを含む。これ
は、テーブルのあらゆるフィールドがいっぱいであるこ
とを強制するので、詳細テーブルの最大メモリ効率を保
証する。本実施形態において、event_detail_table３１
２は、event_uuid、event_timestamp、category、noden
ame、application_id、message、severity、event_oi
d、ov_objectid、protocol、event_type、ip_address、
trapsource、trap_name、pid、forward_address、event
_source、event_timeおよびnumber_varbindsというフィ
ールドを含む。フィールドevent_uuidは、詳細テーブル
のデータを他の関連テーブルのデータと関係づけるため
に使用される。フィールドevent_timestampは、イベン
トの発生時点からの経過時間(秒)を記録する。種々のデ
ータウェアハウスにおけるデータ表現が必ずしも整合し
てはいないので、このフィールドが使用される。

【００２６】従って、"所与の日付からの期間"という標
準形式を使用することによって、すべてのＤＢＭＳにわ
たってタイムスタンプが整合していることが保証され
る。フィールドcategoryは関連イベントのイベント・タ
イプを保存し、フィールドnodenameはイベントが発生し
たノードの名前を識別する。フィールドapplication_id
は、イベントを生成したソフトウェア・アプリケーショ
ンを識別する。フィールドmessageは、イベントに関す
るASCIIテキスト情報を含む。フィールドseverityは、
(例えば、未指定、通常、警告、マイナ、メジャまたは
重大のような)イベントの重大性のレベルを標示する。
フィールドevent_oidは、当該イベントの特定イベント
・タイプにユニークな識別子を記憶する。フィールドnu
mber_varbindsは、イベント詳細テーブルに記憶されて
いるこのイベントと関連づけられているエントリがvarb
indsテーブルにいくつ存在するか標示する。Event_deta
il_table(イベント詳細テーブル)３１２は、ov_objecti
d、protocol、event_type、ip_address、trapsource、t
rap_name、pid、forward_address、event_source、even
t_timeというフィールドを含め、イベント情報を識別す
る更に多くのフィールドを含む。

【００２７】特定のイベントがそのイベントに関する更
に付加的サポート情報を持つこともできる。そのような
付加情報は、すべてのイベント・タイプに共通であると
いうわけではないが、可変結合テーブルevent_varbinds
_table３１４に記憶される。Event_varbinds_table３１
４は、可変数の付加データ・フィールドをイベントに付
加する。好ましい実施形態において、可変結合テーブル
event_varbinds_table３１４は、フィールドevent_uui
d、varbind_sequence、event_oid、val_len、type、str
ing、integer、flt、unsigned32、unsigned64などの種
々のタイプのその他任意の数のフィールドを含む。フィ
ールドevent_uuidもまたevent_detail_table３１２に保
存され、付加イベント・フィールドを詳細テーブルに対
応づけるため使用される。フィールドvarbind_sequence
は、event_varbinds_table３１４の特定エントリに関す
る可変結合エントリを識別する。この場合、このイベン
トに関するevent_varbindテーブルのvarbindエントリの
総数は、詳細テーブルevent_detail_table３１２のフィ
ールドnumber_varbindsに保存されている数に等しくな
ければならない。例えば、詳細テーブルevent_detail_t
able３１２のフィールドnumber_varbindsが整数"３"を
記憶していれば、同じevent_uuidを持つ３つのエントリ
が、可変結合テーブルevent_varbinds_table３１４に存
在する。

【００２８】詳細テーブルevent_detail_table３１２お
よび可変結合テーブルevent_varbinds_table３１４は、
普遍的にユニークな識別子(UUID)フィールドevent_uuid
を各々含み、それによって相互に結合される。詳細テー
ブルevent_detail_table３１２および可変結合テーブル
event_varbinds_table３１４は、所与のイベントに関し
て利用可能なすべての情報を記憶する。Event_uuidは、
詳細テーブルに記憶されていないが可変結合テーブルに
記憶されているイベントに関連する情報の部分を参照す
るために使用される。このようにして、所与の詳細テー
ブルevent_detail_table３１２、可変結合テーブルeven
t_varbind_table３１４およびUUIDフィールドevent_uui
dに従って、ユーザは、イベントに関する利用できるす
べての情報に外界からアクセスすることができる。

【００２９】一般的には、イベントに関して利用できる
情報のすべてが、統計プロセス制御、傾向追跡またはレ
ポート作成の目的に役立つとはかならずしもかぎらな
い。例えば、イベントに関して典型的に生成されるレポ
ートは、ユーザにとって意味のあるよう提示するため、
イベント・タイプ、重大性レベル等々に従って構成され
る。詳細テーブルおよび可変結合テーブルだけを使用し
てレポート作成を実行する試みは、レポート作成に必要
なすべての必須情報を取得するため、詳細テーブルおよ
び可変結合テーブルに対して一連の独立したフィールド
照会を必要とし、この結果、システムの処理性能は低下
する。従って、レポート作成アプリケーションがレポー
トを作成ために必要な情報のすべてを１つのイベントに
ついて単一の照会で取得することを可能とするため、本
実施形態において、レポート準備状態テーブル、可用性
テーブル３１６およびしきい値違反テーブル３１８が提
供される。

【００３０】可用性テーブルevent_availability_table
３１６は、詳細テーブルevent_detail_table３１２およ
び可変連結テーブルevent_varbind_table３１４のフィ
ールドのうち任意の可用性イベントに関連するすべての
フィールドを含む。好ましい実施形態において、可用性
イベントは、node_added、node_deleted、node_upおよ
びnode_downを含む。可用性イベントnode_addedは、所
与のノードがネットワーク管理システムによって検出さ
れたことおよびネットワーク管理システムがその管理を
開始しようとしていることを標示する。可用性イベント
node_deletedは、ネットワーク管理システムが所与のノ
ードをもはや管理しようとしていないことを標示する。
可用性イベントnode_upおよびnode_downは、そのノード
に関する起動および停止状態移行を標示する。可用性テ
ーブルevent_availability_table３１６は、一定期間に
おけるネットワークの所与のノードの可用性のプロファ
イルを表すレポートを作成するため、レポート作成アプ
リケーションによって使用される。

【００３１】可用性レポートおよびしきい値レポート
は、集計または処理されたデータを保存してレポートを
作成するため、付加的テーブル３１６および３１８を必
要とする。可用性テーブルevent_availability_table３
１６およびしきい値テーブルevent_threshold_table３
１８における情報は、詳細および可変結合テーブルに含
まれている情報の処理済みバージョンまたはサブセット
であり、event_availability_table３１６は、フィール
ドevent_uuidを介して、event_detail_table３１２およ
びevent_varbind_table３１４にリンクされる。このよ
うに、イベント可用性テーブルevent_availability_tab
le３１６およびしきい値テーブルevent_threshold_tabl
e３１８は、event_detail_table３１２およびevent_var
binds_table３１４に存在するデータを抽出して、レポ
ート作成アプリケーションが容易に情報を取り出すこと
ができるようにフォーマットされたデータを含む。言い
換えると、一旦データウェアハウス１１１が利用できる
ようになれば、所与のイベントが、event_detail_table
３１２およびevent_varbind_table３１４に保存され、
それらのテーブルから一定のフィールドが、異なるレイ
アウトで、event_availability_table３１６およびeven
t_threshold_table３１８に複製される。event_availab
ility_table３１６およびevent_threshold_table３１８
に含まれる情報の構成によって、データ取り出しアクセ
ス時間およびシステム資源活用度の観点からシステム性
能が向上する。

【００３２】監視された装置条件が事前指定された目標
値を上回る時一定のネットワーク・イベントが生成され
る。例えば、コンピュータがディスク容量を使い果たそ
うとする場合、しきい値が９０％容量を上回ると、しき
い値違反イベントが生成される。しきい値は典型的には
システム管理者によって定義され、管理者が通知される
ことを望む条件のしきい値に対応するレベルに設定され
る。しきい値違反テーブルevent_threshold_table３１
８は、関連event_detail_table３１２およびevent_varb
inds_table３１４に保存されているイベント・フィール
ドに含まれるフィールドからしきい値違反レポートを容
易に作成するために役立つものとして抽出されるフィー
ルドからなる。

【００３３】時間の経過とともに、典型的ネットワーク
管理システムにおいて生成されたイベントの数は非常に
大きくなり、それを維持するため大量の処理および記憶
資源を必要とするようになることがある。ノードあたり
の特定イベント・タイプの出来事の数を追跡することに
焦点がおかれる傾向追跡およびレポート作成目的のため
には、各イベントに関連する詳細情報は役に立つ目的を
提供しない。しかしながら、重要な点は、ノードあたり
のイベント・タイプの出来事の数の記録を維持すること
である。従って、好ましい実施形態において、event_da
ily_table、event_weekly_tableおよびevent_monthly_t
ableなどの多数の集計テーブル・クラスが定義される。
このようなクラスの好ましい実施形態定義が後掲の表２
に記載されている。かくして、フィールドevent_oidに
よって結合された各イベント・タイプおよび各ノードに
関して、event_daily_table、event_weekly_tableおよ
びevent_monthly_tableを使用して、カウント・フィー
ルドevent_cntが維持され、毎日、毎週および毎月の単
位でデータウェアハウス１１１に保存される。これによ
って、傾向追跡およびレポート作成アプリケーション
が、時間の経過にわたる特定ノードに関する特定イベン
ト毎の平均発生数や発生数の増加または減少傾向を描出
または識別することが可能とされる。

【００３４】同じイベント・タイプのイベント発生数の
追跡が必要となる時、集計テーブルevent_daily_table
３２２、event_weekly_table３２４およびevent_monthl
y_table３２６は、各イベント・タイプ毎に定義され、
フィールドevent_oid３２８によって識別およびリンク
される。集計テーブルevent_daily_table３２２、event
_weekly_table３２４およびevent_monthly_table３２６
の各々は、表２のそれぞれ対応するクラス定義に定義さ
れているように、イベント・タイプのカウントを保存す
るフィールドevent_cntを維持する。好ましい実施形態
において、エクスポート管理モジュール１０２が、標準
ＯＤＢＣインタフェース１０３を経由して、各イベント
・タイプに関するevent_daily_table３２２のフィール
ドevent_cntを更新し、一方、集計機能１０４が、標準
ＯＤＢＣインタフェース１０３を経由して、各イベント
・タイプに関するevent_weekly_table３２４およびeven
t_monthly_table３２６のフィールドevent_cntを更新す
る。

【００３５】エクスポート管理モジュール１０２がイベ
ント１０１を受け取ると、エクスポート管理モジュール
１０２は、それが処理するノードに関するイベント・タ
イプの発生数をカウントしてその記録を維持する。エク
スポート管理モジュール１０２は、各イベント・タイプ
・インスタンスおよびノードに関してevent_daily_tabl
e３２２のエントリを作成し、それが処理する各イベン
ト・インスタンス毎に毎日のカウントをフィールドeven
t_cntに通算する。event_daily_table３２２は各イベン
ト・タイプおよびノード毎に各日ごとに維持されるか、
あるいは、代替的には、好ましい実施形態におけるよう
に、フィールドevent_cntは、該当するevent_weekly_ta
ble３２４およびevent_monthly_tabl３２６に毎日加算
され、毎日ゼロにリセットされる。

【００３６】図４は、好ましい実施形態において集計機
能１０４によって実行されるステップの流れ図である。
集計機能１０４が、データウェアハウス１１１に保存さ
れているイベント・データを集計するようにスケジュー
ルされる。ステップ４０２において、集計機能１０４
は、event_daily_tableをデータウェアハウス１１１か
ら取り出す。上述のように、event_daily_tableは、所
与のノードに関する所与のイベント・タイプのイベント
のすべてを含む。

【００３７】ステップ４０４において、イベントの集計
を調整するため、フィールドevent_timestampが参照さ
れる。該当する期間に関してevent_weekly_tableまたは
event_monthly_tableがまだ存在しない場合、集計機能
１０４は、先ずそれらテーブルを作成して、次に該当す
る通算記録でそれぞれのevent_cntフィールドを更新す
る。ステップ４０８において、集計機能１０４は、更新
されたevent_weekly_tableおよびevent_monthly_table
をデータウェアハウス１１１に保存する。集計関数の実
行中に例えば、ノードｘに関するイベント・タイプαに
関して前日のイベント・カウントが２０イベントであっ
たとすれば、集計関数は、該当する期間に関連するeven
t_weekly_tableおよびevent_monthly_tableのevent_cnt
フィールドに２０イベントを加算する。

【００３８】集計機能１０４の有用性は、各週および各
月毎のデータ・ポイントを持つレポートを集計記録につ
いて生成することができ、時間経過にわたってそれを描
出して傾向を識別することができる点である。更に、こ
の傾向情報は、各イベントの詳細情報が保持されている
か否かに関係なく、維持される。

【００３９】時間の経過とともに過去のイベントの履歴
情報だけが一般的には関心をもたれるので、一旦集計機
能１０４がイベントをカウントしたならば、そのイベン
ト自身の詳細は典型的にはもはや必要ではない。従っ
て、データウェアハウス１１１から不必要なイベント情
報を削除するため、図１に示されているように、切り取
り機能１０６が提供される。切り取り機能１０６は、シ
ステム管理者による指定に従って、標準インターフェー
スＯＤＢＣ１０７を経由して、event_detail_tables３
１２、event_varbind_tables３１４、event_availabili
ty_tables３１６およびevent_threshold_tables３１８
を削除する。

【００４０】好ましい実施形態において、システム管理
者がタイムスタンプおよびテーブル・タイプを指定し、
切り取り機能１０６が指定されたタイムスタンプの前の
タイムスタンプを持つ指定されたテーブル・タイプのす
べてのテーブルを削除する。例えば、タイムスタンプｔ
に先行するタイムスタンプを持つすべてのイベント詳細
テーブル３１２およびイベント可変結合テーブル３１４
を切り取り機能１０６は削除する。好ましい実施形態に
おいて、切り取り機能１０６は、相対的秒、分、時など
で測定されるある時間の前にどのようなテーブルをも
(例えば２４時間より前に発生したイベントに関連する
どのようなテーブルをも)削除する能力を持つ。更に、
切り取り機能１０６は、所与の時点以降に発生したイベ
ントに関連するいかなるテーブルをも削除する能力を持
つので、これは、例えばネットワークが停止してデバッ
グをしている間に発生するデータを削除することに役立
つ。

【００４１】フィルタ機能１１０は、イベント・タイ
プ、Ｙ／Ｎインジケータという形式のフィルタ仕様入力
１１３を受け取る。Ｙ／Ｎインジケータは、Ｙに設定さ
れているとイベント・タイプのイベントを常にフィルタ
リングすることを意味し、Ｎに設定されているとイベン
ト・タイプのイベントを決してフィルタリングしないこ
とを意味する。フィルタ機能１１０は、特定イベントに
関するフィルタ・テーブルevent_filter_table３３０を
作成する。好ましくは、event_filter_table３３０はワ
イルドカードを許容する。例えば、指定されたノードに
関するすべてのイベント・タイプをフィルタリングする
ため、あるいは、指定イベント・タイプに関するすべて
のノードをフィルタリングするため、ワイルドカードが
使用される。加えて、整数限度Ｎを設定して、指定され
たノードに関してその日の最初のＮ個のイベントまでが
保存されるべきことを指定することができる。Event_fi
lter_table３３０は、標準インタフェースＯＤＢＣ１０
９を経由してデータウェアハウス１１１に保存される。
エクスポート管理モジュール１０２が標準インタフェー
ス１０３を経由してevent_filter_tableにアクセスし
て、定義されたフィルタ仕様に一致するすべてのイベン
ト情報を破棄する。

【００４２】当業者に認められることであろうが、上記
本発明は、ネットワーク管理システムのイベント・スト
リームからの生のデータストリームータを特別なコンテ
ナに構成して、レポート関連データをレポート作成アプ
リケーションによって容易にアクセスできるようにする
方法を提供する。加えて、本発明は、傾向を表す履歴形
式にデータを集計して、詳細イベント情報を保持するこ
となくレポート作成のためそのデータに容易にアクセス
することを可能にするメカニズムを提供する。以上本発
明を特定の実施形態を参照して記述したが、本発明の理
念を逸脱することなく上記実施形態に種々の変更および
修正を加えることができる点は当業者に認められること
であろう。

【００４３】

【表１】 0: O1: 10 OO 04 OO OO OO f5 OO OO 47 4a 0f 02 72 95 .......GJ..r. 16: OO OO OO OO 35 6e f0 15 57 ff 84 b2 f7 1a 71 d1 .....5n..W.....q. 32: 03 13 Of 02 72 95 OO OO Of 02 72 95 06 Oe 2b 06 .....r.....r...+ 48: O1 04 O1 Ob 02 11 O1 OO 9c 9c 81 5f 30 10 06 Ob ............._O.. 64: 2b 06 O1 04 O1 Ob 02 11 02 O1 OO 02 O1 03 30 22 +..............0" 80: 06 Ob 2b 06 O1 04 O1 Ob 02 11 02 02 OO 04 13 6d ...+............m 96: 65 72 63 75 74 69 6f 2e 63 6e 64 2e 68 70 2e 63 ercutio.cnd.hp.c 112: 6f 6d 30 Of 06 Ob 2b 06 O1 04 O1 Ob 02 11 02 03 om()...+......... 128: OO 04 OO 30 81 9b 06 Ob 2b 06 O1 04 O1 Ob 02 11 ...O....+....... 144: 02 04 OO 04 81 8b 20 20 20 20 20 4e 65 74 77 6f ......Netwo 160: 72 6b 20 4e 6f 64 65 20 4d 61 6e 61 67 65 72 20 rk Node Manager 176: 32 35 30 20 49 6e 73 74 61 6e 74 2d 4f 6e 20 20 250 Instant-On 192: 4e 65 74 77 6f 72 6b 20 4e 6f 64 65 20 4d 61 6e Network Node Man 208: 61 67 65 72 20 32 35 30 20 49 6e 73 74 61 6e 74 ager 250 Instant 224: 2d 4f 6e Oa 20 20 20 20 20 50 61 73 73 77 6f 72 -On. Passwor 240: 64 20 65 78 70 69 72 61 74 69 6f 6e 3a 20 54 75 d expiration: Tu 256: 65 20 4a 75 6c 20 32 38 20 31 31 3a 32 35 3a 33 e Jul 28 11:25:3 272: 30 20 31 39 39 38 2c 20 32 35 30 20 6e 6f 64 65 0 1998, 250 node 288: 73 -- -- -- -- -- -- -- -- -- -- -- s..........

【００４４】

【表２】 TABLE event_data_table (table_name varchar, last_timestamp integer, version integer); TABLE event_category_table (category integer, text varchar); TABLE event_severity_table (severity integer, text varchar); TABLE event_detail_table (event_uuid varchar; event_timestamp integer, category integer, nodename varchar, application_id varchar, message varchar, severity integer, event_oid varchar, ov_objectid varchar, protocol varchar, event_type varchar, ip_address varchar, trapsource integer, trap_name varchar, pid integer, forward_address varchar, event_source varchar, event_time timestamp, number_varbinds integer); TABLE event_varbinds_table (event_uuid varchar, varbind_sequence integer, event_oid varchar, val_len integer, type varchar, string varchar; type_integer integer, flt float, objid varchar, unsigned32 integer, unsigned64 integer); TABLE event_threshold_table (event_uuid varchar; event_oid varchar, event_timestamp integer, event_time timestamp, application_id integer, nodename varchar, object_id varchar, mib_oid varchar, collection_name varchar, instance varchar, severity integer, threshold float, sample float, high_sample float, high_time varchar, low_sample float, low_time varchar, threshold_operation varchar, threshold_count integer); TABLE event_avail_table (event_uuid varchar, event_oid varchar, event_timestamp integer, event_time timestamp, application_id integer, nodename varchar, object_id varchar, mib_oid varchar, collection_name varchar, instance varchar); TABLE event_daily_table (nodename varchar, event_oid varchar, event_cnt integer, event_timestamp integer, event_time timestamp, month integer, week integer, year integer); TABLE event_weekly_table (nodename varchar, event_oid varchar, instance varchar, event_cnt integer, event_timestamp integer, event_time timestamp, month integer, week integer, year integer); TABLE event_monthly_table (nodename varchar, event_oid varchar, instance varchar, event_cnt integer, event_timestamp integer, event_time timestamp, month integer, week integer, year integer); TABLE event_filter_table (nodename vachar, event_oid varchar, always_never varchar, limit integr);

【００４５】本発明には、例として次のような実施様態
が含まれる。

【００４６】（１）ネットワーク管理システムのイベン
ト・データウェアハウスから一組のレポート・フィール
ドを取り出す方法であって、所与のイベントに関して上
記データウェアハウスに保存される上記一組のレポート
・フィールドがネットワーク管理システムのイベントを
集合的に形成する複数のイベント・フィールドを含み、
更に上記一組のレポート・フィールドが上記複数イベン
ト・フィールドのうちのレポート作成にとって不可欠な
イベント・フィールドの各々を含むレポート準備状態テ
ーブルに保存され、該方法が、複数のイベント・フィー
ルドを含むネットワーク管理システム・イベントを受け
取るステップと、上記ネットワーク管理システム・イベ
ントから上記複数のイベント・フィールドのうちのレポ
ート作成にとって不可欠な少なくとも第１のセットのイ
ベント・フィールドを抽出するステップと、上記複数の
イベント・フィールドの上記第１のセットをレポート作
成のためレポート作成アプリケーションによって使用さ
れる上記レポート準備状態テーブルに保存するステップ
と、を含むレポート・フィールド取り出し方法。

【００４７】（２）上記レポート作成アプリケーション
からレポート照会を受け取るステップと、上記複数イベ
ント・フィールドの上記第１のセットを上記レポート作
成アプリケーションに送るステップと、を含む上記
（１）に記載のレポート・フィールド取り出し方法。

【００４８】（３）あらかじめ定められた期間における
上記イベント・タイプのイベントの発生回数のカウント
を維持するステップと、上記カウントを集計テーブルに
保存するステップと、を含む上記（１）または（２）に
記載のレポート・フィールド取り出し方法。

【００４９】（４）集計レポート作成アプリケーション
から集計レポート照会を受け取るステップと、上記集計
テーブルに保存されている上記カウントを上記集計レポ
ート作成アプリケーションに送るステップと、を含む上
記（３）に記載のレポート・フィールド取り出し方法。

【００５０】（５）上記カウントが上記集計テーブルに
保存された後上記イベント・フィールドの上記第１のセ
ットを上記データウェアハウスから削除するステップを
含む上記（３）または（４）に記載のレポート・フィー
ルド取り出し方法。

【００５１】（６）各々が複数の異なるイベント・タイ
プの１つを含み、各々が複数のイベント・フィールドか
ら構成される複数ネットワーク管理システム・イベント
を保存するデータウェアハウスであって、該データウェ
アハウスが上記イベントに各々が関連する複数の関連テ
ーブルを備え、上記複数の関連テーブルの各々が上記イ
ベントに関連づけられ、上記複数イベント・フィールド
のうちの第１のイベント・フィールド・セットを含むレ
ポート準備状態テーブルを含み、上記レポート準備状態
テーブルがレポート作成アプリケーションによって使用
され、上記第１のイベント・フィールド・セットが上記
レポートの作成にとって欠かすことのできない上記複数
のイベント・フィールドの各々を含む、データウェアハ
ウス。

【００５２】（７）上記データウェアハウスが上記イベ
ントを受け取るように構成されるエクスポート管理モジ
ュールを備え、上記エクスポート管理モジュールが上記
複数イベント・フィールドのうちの上記第１のイベント
・フィールド・セットをレポート準備状態テーブルにフ
ォーマットし、上記レポート準備状態テーブルが報告タ
イプ・テーブル・クラスに従って定義され、上記レポー
ト準備状態テーブルの上記報告タイプ・テーブル・クラ
スが上記レポートの作成にとって欠かすことのできない
上記複数のイベント・フィールドの各々を含み、上記デ
ータウェアハウスが更に上記レポート準備状態テーブル
を該データハウスに送る通信インタフェースを備える、
上記（６）に記載のデータウェアハウス。

【００５３】（８）指定された期間における上記イベン
トの上記イベント・タイプのイベント発生総数を含むイ
ベント・カウントを維持する集計機能を更に備える、上
記（６）または（７）に記載のデータウェアハウス。

【００５４】（９）該データウェアハウスが、条件を指
定するフィルタ・テーブルを作成するフィルタ機能を備
え、上記エキスポート管理モジュールが上記条件を読み
取り、該条件に応答して上記イベントが上記条件に一致
すればそのイベントを該データウェアハウスに保存する
ことなく破棄する、上記（６）乃至（８）のいずれかに
記載のデータウェアハウス。

【００５５】（１０）上記レポート準備状態テーブルか
ら上記複数のイベント・フィールドの上記第１のセット
を取り出すデータ取り出しインタフェースを更に備え
る、上記（６）乃至（９）のいずれかに記載のデータウ
ェアハウス。

【００５６】

【発明の効果】本発明のデータウェアハウスは、各々が
特定のイベントまたはイベント・タイプに関連づけられ
る複数の関連テーブルにイベント・データを保存する。
テーブルは、所与のイベントに関して利用できるイベン
ト・フィールドのうち特定のレポート・タイプに関連す
るサブセットを含むレポート準備状態イベント・テーブ
ルを含む。従って、その特定タイプのレポートを実行す
るレポート作成アプリケーションが、所与のイベントに
関するすべての必要なフィールドに単一の照会でアクセ
スすることが可能とされるので、本発明によって、シス
テムの処理性能が向上する。

【図面の簡単な説明】

【図１】本発明に従ったシステムのブロック図である。

【図２】１つのタイプのイベントに関する本発明の公式
データ・スキーマに従ったオブジェクトのブロック図で
ある。

【図３】本発明のデータウェアハウスのコンテンツの例
を示すブロック図である。

【図４】集計機能によって実行されるステップの好まし
い実施形態の流れ図である。

【符号の説明】

１０１ネットワーク管理システムのイベント１１１データウェアハウス１１２レポート作成アプリケーション２０１、２０２、２０３、２０４、２０５イベント
・フィールド２１０、２２０レポート準備状態テーブル

───────────────────────────────────────────────────── フロントページの続き (72)発明者クリス・ピー・ダスアメリカ合衆国80526コロラド州フォート・コリンズ、ブリックストン・ロード 2204 (72)発明者ウィリアム・シー・ケプナーアメリカ合衆国80526コロラド州フォート・コリンズ、カタリナ・ドライブ 5011

Claims

【特許請求の範囲】

【請求項１】ネットワーク管理システムのイベント・デ
ータウェアハウスから一組のレポート・フィールドを取
り出す方法であって、所与のイベントに関して上記データウェアハウスに保存
される上記一組のレポート・フィールドがネットワーク
管理システムのイベントを集合的に形成する複数のイベ
ント・フィールドを含み、更に上記一組のレポート・フ
ィールドが上記複数イベント・フィールドのうちのレポ
ート作成にとって不可欠なイベント・フィールドの各々
を含むレポート準備状態テーブルに保存され、該方法が、複数のイベント・フィールドを含むネットワーク管理シ
ステム・イベントを受け取るステップと、上記ネットワーク管理システム・イベントから上記複数
のイベント・フィールドのうちのレポート作成にとって
不可欠な少なくとも第１のセットのイベント・フィール
ドを抽出するステップと、上記複数のイベント・フィールドの上記第１のセットを
レポート作成のためレポート作成アプリケーションによ
って使用される上記レポート準備状態テーブルに保存す
るステップと、を含むレポート・フィールド取り出し方法。