複数のログ・エントリをマージする技術
【課題】不確定なコンディションのもとで生成されるログ・エントリから、高度のイベント情報を自動的に収集する。
【解決手段】エージェント１０４内のパーサ１０２が、複数デバイスおよびいくつかのソフトウェアからログ・エントリを受け取る。パーサ１０２は、ログ・エントリを構文解析してトークンをグルーピング・トラッカー・モジュール１１０に出力する。グルーピング・トラッカー・モジュールは、マージ・プロパティを使用して、被マージイベントを構築し、特定の被マージイベントに関連するログ・エントリをマッピング・モジュール１２０に出力する。マッピング・モジュールは、マッピング・プロパティ１２２に従って、ログ・エントリを被マージイベント内にマッピングし、複数ログ・エントリに起因する一つ以上の被マージイベントとして出力する。
【解決手段】エージェント１０４内のパーサ１０２が、複数デバイスおよびいくつかのソフトウェアからログ・エントリを受け取る。パーサ１０２は、ログ・エントリを構文解析してトークンをグルーピング・トラッカー・モジュール１１０に出力する。グルーピング・トラッカー・モジュールは、マージ・プロパティを使用して、被マージイベントを構築し、特定の被マージイベントに関連するログ・エントリをマッピング・モジュール１２０に出力する。マッピング・モジュールは、マッピング・プロパティ１２２に従って、ログ・エントリを被マージイベント内にマッピングし、複数ログ・エントリに起因する一つ以上の被マージイベントとして出力する。
【発明の詳細な説明】
【技術分野】
【０００１】
開示された実施形態はネットワーク動作の監視に広く関連する。より詳細には、開示された実施形態は、関連するネットワーク動作を表す複数のエントリ（entry: 参加）をマージ（merge: 合併）するためのシステムおよび方法に関する。
【背景技術】
【０００２】
ネットワーク上の各種デバイス（装置）およびいくつかのソフトウェアから受け取ったログ・エントリ（log entry）を監視することが望まれている。往々にして、これらのデバイスおよびいくつかのソフトウェアは、利便性、速度、または、信頼性の理由でいくつかのロギング・メッセージを作成することができる。これは、例えば、たとえ全ての情報がそうでなくとも、いくつかの情報はそのイベントのセントラルポイントに到達するようにする。例として、業務が完了する前にログ・メッセージを送出することは、たとえ後でシステムがその業務が完全に終了する前にクラッシュしたとしても何かが記録されることを確実にするために、望ましい。
【０００３】
加えて、何らかの種類のログ・イベントが時間とともにデバイスで発生する。全てのログ可能なイベントの発生がデバイスで起こるまで待つ代わりに、ログ可能なイベントが発生するその都度、当該ログ可能なイベントを送出することは望ましいと考えられる。
【０００４】
複数デバイスがネットワークにおける一つ以上のセントラルコレクションポイント(central collection point: 中央収集点)にログ・エントリを送出する場合、各種デバイスから各種イベントのためのログ・エントリは、互いに分散して到達する可能性が最も高い。各種のログ・エントリはそのログ内で隣接しないであろう。これらは大変似通ったイベント同士でインターリーブされてもよい。これらはいくつかのログ・ファイルにわたって拡散してもよい。エントリのシーケンスは完成していなくともよい（おそらくセンサはその動作が完了する前にクラッシュする）。
【０００５】
前述したような不確定なコンディションのもとで生成されるログ・エントリから、高度のイベント情報(high-level event information)を自動的に収集する手法が必要とされている。
【発明の概要】
【０００６】
本発明の好適な実施形態は、パーサ (parser: 構文解析プログラム)、グルーピング・トラッカー・モジュール (grouping tracker module: グループ化追跡取得プログラム・モジュール)、および、マッピング・モジュール (mapping module) を含むエージェント（agent: ソフトウェア上の概念としての「エージェント」）を定義する。パーサは到達するログ・エントリをトークン (token: ソースコード中の文字列の最小単位の字句) に選別する。グルーピング・トラッカーはこれらトークンを解析してトークンの属するマージされたイベント（もしあれば）を判定する。説明される実施形態では、グルーピング・トラッカーはコンフィギュラブル（configurable: 構成可能な）マージ・プロパティ（merge property: 併合属性）に従って動作するが、他の実施形態ではハードコード化されたプロパティを有してもよい。マージ・プロパティにより、ログ・エントリをハイレベルの被マージイベント（merged event）へとグループ化する動作に関連する各種プロパティを構成することができる。説明される実施形態では、これらプロパティは、以下のいくつかもしくは全てを含む： 各被マージイベントのために考慮されるべきログ・エントリがどんなタイプであるか； 各被マージイベントを識別するために使用されるＩＤ； エンドエントリが検出されない場合であっても、既存の被マージイベントのためのエントリの収集を自動的に終了するタイムアウト値。
【０００７】
記述された実施形態では、マッピング・モジュールは特定の被マージイベントに関連するログ・エントリを受け取り、これらをマッピング・プロパティ（これらマッピング・プロパティはまたハードコードされていてもよいが）に従って被マージイベントデータ構造のフィールドにマップする。
【０００８】
本発明の記述された実施形態は、マージ・プロパティの正規表現を使用して、受け取られたログ・エントリ内で検索される値を述べる。例えば、正規表現はマルチ・エントリ・イベントの一部であるエントリを定義してもよく、マルチ・エントリ・イベントの最初のエントリを検出してもよく、マルチ・エントリ・イベントの最後のエントリを検出してもよい。マージ・プロパティはまた、マージされるために同じ値を含んでいるのがエントリのどのフィールドかを宣言する（例えば、エントリは同じ数字ＩＤや同じＩＰアドレスの記述をともに有してもよい）。本発明の記述された実施形態は互いに散在するイベントのためのログ・エントリを処理することができる。
【図面の簡単な説明】
【０００９】
【図１】本発明の一実施形態に従ったシステムのブロック図。
【図２】マージプロパティに従ってログ・エントリを処理するために行われる方法の一実施形態のフローチャート。
【図３】マッピングプロパティに従ってログ・エントリを被マージイベントに加えるために行われる方法の一実施形態のフローチャート。
【図４】本発明の一実施形態におけるマッピングプロパティで用いられるoneOf関数を示すフローチャート。
【図５】各種被マージイベントのための散在したログ・エントリが受け取られた場合の、複数被マージイベントが構築されている例。
【図６】一つの被マージイベントのフォーマット例。
【発明を実施するための形態】
【００１０】
ここで本発明の一実施形態を、類似の参照符号が同一のまたは機能的に同等の要素を示している図面を参照しながら説明する。
【００１１】
図１は、本発明の一実施形態に従ってシステム１００のブロック図を示す。システム１００は好ましくは、ネットワーク上の一つ以上のセントラル・ポイントでエージェント１０４を含む。ネットワーク、例えば、インターネット、ＬＡＮ、ＷＡＮ、無線ネットワーク、移動式ネットワーク、または、リモートデバイスがエージェント１０４にログ・エントリを送信可能な他の何らかの適切な機構上で、エージェント１０４は複数デバイスおよびいくつかのソフトウェアからログ・エントリを受け取る。
【００１２】
ログ・エントリはパーサ (parser: 構文解析プログラム) １０２によって受け取られ、当業者に周知の手法でトークンに構文解析される。他の実施形態では、パーシング（構文解析）の実行は、Hector Aguilar-Macias他による２００５年３月１日付け出願の米国特許出願番号１１／０７０，０２４、「ネットワークセキュリティシステムにおけるメッセージパーシング」で説明されており、参照することによって本明細書に組み込まれている。
【００１３】
受け取られたログ・エントリは、パーサ１０２が構文解析することのできる何らかの適切なフォーマットであってよい。パーサ１０２は受け取られたログ・エントリに基づいたトークンを出力する。これらのトークンはグルーピング・トラッカー・モジュール１１０で受け取られる。
【００１４】
グルーピング・トラッカー・モジュール(grouping tracker module: グループ化追跡取得プログラム・モジュール)１１０は、メモリ、もしくは他の記憶モジュールまたはデバイス１１２からマージ・プロパティ（merge property: マージの特性若しくは属性）を受け取るように接続される。マージ・プロパティは、被マージイベント（merged event: 「複数のログ・エントリを合併したイベント」の意）を構築する際に使用され、受け取られたログ・エントリがどのように解釈されるべきかを指定する。グルーピング・トラッカー・モジュールは特定の被マージイベントに関連するログ・エントリをマッピング・モジュール内に出力する。マッピング・モジュールにおいて、ログ・エントリは、受け取られたログ・エントリから構築されつつある被マージイベント内にマッピングされる（配置される）。このマッピングはマッピング・プロパティ１２２に従って行われる。マッピング・モジュール１２０の出力は、複数ログ・エントリに起因する一つ以上の被マージイベントである。図１に概ね示されているこの工程につき、一例に関連して、以下、より詳細に説明する。
【００１５】
［例］
この例は、本発明の一実施形態において、どのようにイベントマージングが動作するのかの例である。
【００１６】
以下のようにログ・エントリを仮定する（また、これらは時として「メッセージ」と呼ばれる）。
[18/Jul/2005:12:30:20 -0400] conn=8 op=0 msgId=82 - BIND uid=admin
[18/Jul/2005:12:30:25 -0400] conn=7 op=-1 msgId=-1 - LDAP connection from 10.0.20.122 to 10.0.20.122
[18/Jul/2005:12:30:30 -0400] conn=8 op=0 msgId=82 - RESULT error=0
【００１７】
パーサ１０２はこれら受け取られたログ・エントリをキー・バリュー・ペア(key-value pair)に構文解析する。各ログ・エントリに対するこういった処理はトークンの１セットを生成する。例えば、ログ・エントリ
[18/Jul/2005:12:30:20 -0400]] conn=8 op=0 msgId=82 - BIND uid=admin
は以下のキー・バリュー・ペア(key/value pair)を有するトークンを生成する。
Date=18/Jul/2005 12:30:20
Connection=8
Operation=0
MessageId=82
OperationName=BIND
UserId=admin
【００１８】
同様に、他の２つのログ・エントリは自身のキー・バリュー・ペアを生成する。
[18/Jul/2005:12:30:25 -0400]] conn=7 op=-1 msgId=-1 - LDAP connection from 10.0.20.122 to 10.0.20.12
Date=18/Jul/2005 12:30:25
Connection=7
Operation=1
MessageId=-1
OperationName=LDAP
Source=10.0.20.122
Destination=10.0.20.12
【００１９】
[18/Jul/2005:12:30:30 -0400]] conn=8 op=0 msgId=82 - RESULT err=0
Date=18/Jul/2005 12:30:30
Connection=8
Operation=0
MessageId=82
OperationName=RESULT
ResultCode=0
【００２０】
図２はマージ・プロパティ１１２に従って受け取られたログ・エントリを処理するために行われる方法の一実施形態のフローチャート２００である。好適な実施形態では、この方法はグルーパ（grouper）／トラッカー１１０によって実行される。タイムアウトが、構築中の被マージイベントに到達した場合（２０２）、被マージイベントは終了して（２０４）、制御は要素（２０２）に戻る。よって、明らかな終了のログ・エントリが一つも検出されなかったとしても、被マージイベントのタイムアウトが発生すれば、その被マージイベントは閉じられるはずである。タイムアウト値は、ログするデバイスの種類毎に異なってもよく、単一デバイスからの被マージイベント毎に異なってもよい。以下に説明されるように、タイムアウト値はマージ・プロパティに含まれている。
【００２１】
要素２０６では、次のログ・エントリが処理のために受け取られる。そのログ・エントリがマージング（マージ・プロパティ１１２に定義されているように）のためのものであると考えられるはずである場合（２０８）には処理が継続され、そうでない場合にはシングルイベントが送出され（２０９）要素２０２に処理が戻る。
【００２２】
ログ・エントリが或る新しい被マージイベント２１０（マージ・プロパティ１１２に定義されているように）についての開始のログ・エントリである場合、当該新しい被マージイベントが開かれる（２１２、構築中の処理における複数の被マージイベントの例として図５参照）。いくつかの実施形態では、その被マージイベントのタイムアウトクロックがスタートされる（２１２）。
【００２３】
ログ・エントリが、開始のログ・エントリではなく、構築中の既存の被マージイベントのＩＤを含んでいる場合（２１４）、イクセプションがログ・記録され、シングルのイベントが送出される（２１５）。そうでない場合、処理は継続されてトークンおよびログ・エントリがマッピング・モジュールに送られ（２２０）、この結果、その情報を被マージイベントに付加することができる。一実施形態では、ＩＤはログ・エントリのシングルフィールドであってもよく、被マージイベントの全てのログ・エントリに共通の値を持つログ・エントリの複数フィールドであってもよい。
【００２４】
ログ・エントリが或る既存の被マージイベント（マージプロパティ１１２に定義されているように）についての終了のログ・エントリである場合（２１６）、既存の被マージイベントは終了され、グルーパ／トラッカーから取り除かれる（２１８、構築中の処理における複数の被マージイベントの例として図５参照）。ログ・エントリがイベント終了を示している場合、対応する被マージイベントは終了され、図５に示される構造から取り除かれなければならない。
【００２５】
例の説明を続けると、この例のマージ・プロパティ１１２は以下のように定義される。
merge.count=1
merge[0].pattern.count=1
merge[0].pattern[0].token=OperationName
merge[0].pattern[0].regex=(BIND|RESULT)
merge[0].starts.count=1
merge[0].starts[0].token=OperationName
merge[0].starts[0].regex=BIND
merge[0].ends.count=1
merge[0].ends[0].token=OperationName
merge[0].ends[0].regex=RESULT
merge[0].id.tokens=Connection,Operation,MessageId
merge[0].timeout=60000
【００２６】
先ず、我々はただ一つの被マージオペレーションを有することを示す。
merge.count=1
【００２７】
それから、マージングのために考えられるべき、BINDまたはRESULTに設定されているOperationNameを有する全てのメッセージを求めることを我々は定義する。
merge[0].pattern.count=1
merge[0].pattern[0].token=OperationName
merge[0].pattern[0].regex=(BIND|RESULT)
【００２８】
今や、BINDに設定されているOperationNameを有するメッセージがマージ処理を開始することを指定する。
merge[0].starts.count=1
merge[0].starts[0].token=OperationName
merge[0].starts[0].regex=BIND
【００２９】
そして、OperationNameがRESULTにセットされているメッセージを検出すると、マージ処理を終了することにすると指定する。
merge[0].ends.count=1
merge[0].ends[0].token=OperationName
merge[0].ends[0].regex=RESULT
【００３０】
我々はまた、イベントが同じグループに属することをどのように識別するかを定義する必要があり、Connection（接続）、Operation（オペレーション）およびMessageId（メッセージＩＤ）の値が同一でなければならないということを指定することでこれを行う（被マージイベントのためのＩＤを形成すること）。
merge[0].id.tokens=Connection, Operation,MessageId
【００３１】
最後に、タイムアウトを定義して、もし６０秒後にOperationNameがRESULTにセットされているメッセージを得られなかった場合、そのイベントはそのまま送出する。
merge[0].timeout=60000
【００３２】
図３は、マッピングプロパティに従ってログ・エントリを被マージイベントに加えるために行われる方法の一実施形態のフローチャートである。受け取られたログ・エントリおよびそれらのトークンは、構築された被マージイベントの少なくとも一つと関連しているとして既に識別されている。マッピング・モジュール１２０はログ・エントリの情報を構築された一つ以上の被マージイベントにマップする（構築された複数の被マージイベントの例として図５参照、被マージイベントのためのフォーマット例として図６参照）。
【００３３】
この例では、マッピング・プロパティ１２２は以下のように定義される。
event.deviceReceiptTime=Date
event.name=_oneOf(mergedevent.name,OperationName)
event.deviceAction=ResultCode
event.destinationUserId=UserId
【００３４】
これらプロパティは、イベントのためのタイムスタンプとしてDateを、デバイスアクションとしてResultCodeを、そして、出力先ユーザＩＤとしてUserIDを使用するつもりであることを示す。名前は以下のように定義される。
event.name=_oneOf(mergedevent.name,OperationName)
【００３５】
こういったフレーム構造なので、最終データを格納するために使用することができる「トラッキング」イベントを参照することができる。この場合、OperationNameまたは「トラッキング」イベントの名前（もしあれば）のいずれかを使用すべきであるということを、オペレーションは意味する。例えば、最初のイベントは以下のキー・バリューを含んでいるであろう。
[18/Jul/2005/:12:30:20 -0400]] conn=8 op=0 msgId=82 - BIND uid=admin
Date=18/Jul/2005 12:30:20
Connection=8
Operation=0
MessageId=82
OperationName=BIND
UserId=admin
【００３６】
そして新たな「トラッキング」イベントが生成されて、以下のマッピングで終了するであろう。
mergedevent.name=BIND
mergedevent.device ReceiptTime=18/Jul/2005 12:30:20
mergedevent.destinationUserId=admin
【００３７】
被マージイベントの名前は新しい被マージイベントであるためBINDとなり、mergedevent.nameは一つも存在せず、OperationNameの値は使用される（BIND）。ここで、マージンググループのための第２のイベントが処理されると以下になる。
[18/Jul/2005:12:30:30 -0400]] conn=8 op=0 msgId=82 - RESULT err=0
Date=18/Jul/2005 12:30:30
Connection=8
Operation=0
MessageId=82
OperationName=RESULT
ResultCode=0
【００３８】
被マージイベントは以下のようにマップされるであろう。
mergedevent.name=BIND
mergedevent.deviceReceiptTime=18/Jul/2005 12:30:30
mergedevent.destinationUserId=admin
mergedevent.deviceAction=0
【００３９】
このイベントが処理されるとき、BINDにセットされた名前で「トラック化された」イベント（mergedevent）が既にあるため、mergedevent.nameがBINDにセットされることに注目されたい。そこで、この場合、OperationNameは使用されず、mergedeventは値BINDを維持する。mergedeventの値はデフォルトによって置き換えられるであろうから、今はどのようにmergedevent.deviceReceiptTimeが18/Jul/2005 12:30:30にセットされたかに注目されたい。そこで、deviceReceiptTimeは最新の値と見なされるであろう。
【００４０】
図４は、本発明の一実施形態におけるマッピング・プロパティで用いられるoneOf関数４０２を示すフローチャート４００である。例えば、イベント名のためにoneOf関数を実行するためには、イベント名が現在ブランクである場合（４０４）、現在のトークン名が使用される（４０６）。名前がブランクであない場合、非ブランク(non-blank)名が維持される（４０８）。
【００４１】
oneOfはマッピングコンポーネントで使用することができるオペレーションの一例にすぎないということが理解されるはずである。マッピングコンポーネントは、被マージイベントのフィールドを参照することができる他の「オペレーション」を含んでもよい。oneOf関数は、実際のマッピングフレーム構造における一例にすぎない。オペレーションの他の例は連結(concatenate)、タイプ変換オペレーションおよびその他を含む。
【００４２】
図５は、各種の被マージイベントのためのログ・エントリが分散的に受け取られる場合に、複数の被マージイベントが構築されつつある例５００を示す。
【００４３】
図６は一つの被マージイベントのフォーマット例５５０を示す。例えば、図５の各種被マージイベントそれぞれでは、全ての値を各被マージイベントのそれぞれに満たすことができないが、このフォーマットを有する。本願発明の各種具体例は、連結、タイプ変換、カウンティング、およびその他を含んだ被マージオペレーションの他の例を含むことができる。他の実施形態は、被マージイベントの各種タイプの数を統計が維持することができるようにするために、被マージイベントの集合体を含む。これら統計されたデータを、単体でまたは他の送信データとの組み合わせでモニタに送信することができる。
【００４４】
以下の段落では本発明の一実施形態に含まれるマージ・プロパティ１１２例が簡単に記述される。
【００４５】
merge.count
定義されるはずのマージ・オペレーションの数を定義。
【００４６】
merge[{mergeindex}].pattern.count
定義されるであろうパターンがいくつあるかを定義する。マージ・オペレーションはマージ・オペレーションで考慮されるであろうイベントを定義するためのパターンを必要とする。もしパターンが一つも与えられていなければ全ての(ALL)イベントが考慮されるであろう。
【００４７】
merge[{mergeindex}].pattern[{patternindex}].token
このパターンのために使用されるであろうトークンを定義する。
【００４８】
merge[{mergeindex}].pattern[{patternindex}].regex
このパターンで使用するための正規表現を定義する。
【００４９】
merge[{mergeindex}].starts.count
定義されるであろうスタートパターンがいくつあるかを定義する。マージ・オペレーションはマージ・オペレーションを開始するはずのイベントを定義するためのスタートパターンを必要とする、もしパターンが一つも与えられていなければ全ての(ALL)イベントがマージオペレーションを開始する。オペレーションが一旦開始されると、タイムアウトまたはエンドパターンマッチを介した終了のみすることができる。
【００５０】
merge[{mergeindex}].starts[{patternindex}].token
このスタートパターンのために使用されるはずのトークンを定義。
【００５１】
merge[{mergeindex}].starts[{patternindex}].regex
このスタートパターンで使用するための正規表現を定義する。
【００５２】
merge[{mergeindex}].ends.count
定義されるであろうエンドパターンがいくつあるかを定義する。マージ・オペレーションはマージ・オペレーションを終了するはずのイベントを定義するためのエンドパターンを必要とする、もしパターンが一つも与えられていなければ一つのイベントもマージ・オペレーションを終了せず、そのオペレーションはタイムアウトを介した終了のみができる。
【００５３】
merge[{mergeindex}].ends[{patternindex}].token
このエンドパターンのために使用されるであろうトークンを定義する。
【００５４】
merge[{mergeindex}].ends[{patternindex}].regex
このエンドパターンで使用するための正規表現を定義する。
【００５５】
merge[{mergeindex}].timeout
マージング・オペレーションのためにタイムアウトをミリ秒単位で定義する。タイムアウトが到達した場合、マージ・オペレーションは終了するはずであり、イベントは送出されるはずである。これらイベントは異なるスレッドを介して送出されるはずであり、イベントの順番は保証されないということに留意する。
【００５６】
merge[{mergeindex}].id.delimiter
前述のリストに使用するためのオプションのデリミタを定義する。もし定義されていないのであれば、デリミタはコンマ(,)である。
【００５７】
merge[{mergeindex}].sendpartialevents
このプロパティはオプショナルであり、デフォルトでフォールスにセットされている。基本的にこのプロパティは、他のイベントとマージされているとしてマージ・オペレーションの各イベントが個別に送出されなければならないかどうかを指定する。
【００５８】
merge[{mergeindex}].capacity
このプロパティはオプショナルであり、デフォルトで１０００にセットされている。イベント・マージング・オペレーションは被マージ結果を維持するイベントのキャッシュを必要とする。これはどれだけキャッシュが大きくあるはずかを定義し、キャッシュがオーバーフローするとイベントはそのまま送出されるはずでありエラーがログ・記録されるはずである。
【００５９】
本明細書内の「一実施形態」または「実施形態」の参照は、その実施形態に関連して記述された特別な機能、構成または特徴が本発明の少なくとも１つの実施形態に含まれていることを意味する。本明細書の各所の「一実施形態では」といった句の出現は必ずしも同じ実施形態を参照することが全てであるということではない。
【００６０】
詳細な説明のいくつかの箇所は、コンピュータメモリ内のデータビット上で稼働するアルゴリズムおよび象徴の用語で記述されている。これらのアルゴリズム記述や表示は、データ処理分野の熟練者が他の当業者に自身の仕事の本質を最も効果的に伝達する手段である。アルゴリズムはここでは、しかも一般的に、所望の結果を導き出す工程（命令）の首尾一貫した順序であると考える。これら工程は物理的な量の物理的な操作を必要とするものである。通常、必ずというわけではないが、これらの量は、記憶、転送、組み合わせ、比較、および他の操作が可能な電気的または磁気的な信号といった形態をとる。大部分は共通使用の理由で、これらの信号はビット、値、要素、シンボル、キャラクタ、ターム、番号またはこれに類するもので呼ばれることは都合のいい時々に証明されている。
【００６１】
しかし、これらおよび類似のタームの全ては適切な物理量に関連し、これらの量に適用される便利な表示に過ぎないといったことを心にとどめておくべきである。詳細に述べられてない限り、そうでなければ解説から明らかではない限り、例えば「処理する（processing）」や「コンピュータで計算する（computing）」や「計算する（calculating）」や「判定する（determining）」や「表示する（displaying）」や同様のタームを使用する解説はコンピュータシステムや類似の電子計算装置の操作および作業を参照する、ということは説明全体を通して正しく理解され、コンピュータシステムは、そのレジスタおよびメモリ内の物理（電子）量として表されるデータを操作して、コンピュータシステムメモリやレジスタ、もしくはその他の情報記憶装置、伝送または表示装置内で物理量として同様に表される他のデータに変換する。
【００６２】
本発明のある局面は、アルゴリズムの形式でここで説明される、処理工程および命令を含む。注意すべきは、本発明の処理工程および命令を、ソフトウェア、ファームウェア、または、ハードウェアで具体化することができるということであり、ソフトウェアで具体化される場合、これらは常駐するようにダウンロードできたり、リアルタイムネットワークオペレーティングシステムを用いて異なるプラットフォームから操作できたりする。
【００６３】
本発明はまた、ここでの動作を実行するための装置に関連する。この装置は必要な目的のために特別に構築してもよく、コンピュータによりアクセスできるコンピュータ読み取り可能な媒体に格納されたコンピュータプログラムによって、選択的に稼働または再構築される汎用コンピュータを備えてもよい。こういったコンピュータプログラムは、例えば、ただし限定されるわけではなく、フロッピー（登録商標）ディスクを含んだあらゆるタイプのディスク、光ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、リードオンリーメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気または光カード、特定用途向けＩＣ（ＡＳＩＣ）、または、電子命令を格納するのに好適なあらゆるタイプの媒体であるコンピュータ読み取り可能な記憶媒体に格納してもよく、これら媒体のそれぞれはコンピュータのシステムバスに接続される。さらに、この明細書で参照されるコンピュータは、シングルプロセッサを含んでもよく、または、計算能力を向上するために設計されたマルチプロセッサを採用したアーキテクチャであってもよい。
【００６４】
ここで提示されるアルゴリズムおよび動作は、何らかの特別なコンピュータや他の装置に本質的に関連しているわけではない。各種汎用システムをここでの教示に従ってプログラムと共に使用することができ、または、必要な方法工程を実行するより専門的な装置を構築することが便利であることも証明できる。これらシステムの多様性のための必要な構成は、等価の変化と共に当業者とって明らかである。加えて、本発明は何らかの特別なプログラミング言語を参照して説明されてはいない。プログラミング言語の多様性は、ここで説明されるように、本発明の教示を実現するために使用することができ、特定言語の何らかの参照は本発明の使用可能性および本発明のベストモードのために提供される。
【００６５】
好適な実施形態およびいくつかの代替の実施形態を参照して、本発明は詳細に示し、説明されている一方、形や詳細の各種変更が本発明の気質や範囲から乖離することなくここで可能であることは関連分野の当業者に理解されるはずである。
【００６６】
最後に、注意すべきは、本明細書で使用される言語は、可読性および教示用目的のために主として選択され、発明的主題(inventive subject matter)を線引きまたは範囲を定めるために選択されたわけではない、ということである。従って、本発明の開示は、本発明の範囲の実例となるように意図されており、限定されず、特許請求の範囲に示される。
【符号の説明】
【００６７】
１００ システム
１０２ パーサ (構文解析プログラム)
１０４ エージェント
１１０ グルーピング・トラッカー・モジュール
１１２ マージ・プロパティ
１２０ マッピング・モジュール
１２２ マッピング・プロパティ
【技術分野】
【０００１】
開示された実施形態はネットワーク動作の監視に広く関連する。より詳細には、開示された実施形態は、関連するネットワーク動作を表す複数のエントリ（entry: 参加）をマージ（merge: 合併）するためのシステムおよび方法に関する。
【背景技術】
【０００２】
ネットワーク上の各種デバイス（装置）およびいくつかのソフトウェアから受け取ったログ・エントリ（log entry）を監視することが望まれている。往々にして、これらのデバイスおよびいくつかのソフトウェアは、利便性、速度、または、信頼性の理由でいくつかのロギング・メッセージを作成することができる。これは、例えば、たとえ全ての情報がそうでなくとも、いくつかの情報はそのイベントのセントラルポイントに到達するようにする。例として、業務が完了する前にログ・メッセージを送出することは、たとえ後でシステムがその業務が完全に終了する前にクラッシュしたとしても何かが記録されることを確実にするために、望ましい。
【０００３】
加えて、何らかの種類のログ・イベントが時間とともにデバイスで発生する。全てのログ可能なイベントの発生がデバイスで起こるまで待つ代わりに、ログ可能なイベントが発生するその都度、当該ログ可能なイベントを送出することは望ましいと考えられる。
【０００４】
複数デバイスがネットワークにおける一つ以上のセントラルコレクションポイント(central collection point: 中央収集点)にログ・エントリを送出する場合、各種デバイスから各種イベントのためのログ・エントリは、互いに分散して到達する可能性が最も高い。各種のログ・エントリはそのログ内で隣接しないであろう。これらは大変似通ったイベント同士でインターリーブされてもよい。これらはいくつかのログ・ファイルにわたって拡散してもよい。エントリのシーケンスは完成していなくともよい（おそらくセンサはその動作が完了する前にクラッシュする）。
【０００５】
前述したような不確定なコンディションのもとで生成されるログ・エントリから、高度のイベント情報(high-level event information)を自動的に収集する手法が必要とされている。
【発明の概要】
【０００６】
本発明の好適な実施形態は、パーサ (parser: 構文解析プログラム)、グルーピング・トラッカー・モジュール (grouping tracker module: グループ化追跡取得プログラム・モジュール)、および、マッピング・モジュール (mapping module) を含むエージェント（agent: ソフトウェア上の概念としての「エージェント」）を定義する。パーサは到達するログ・エントリをトークン (token: ソースコード中の文字列の最小単位の字句) に選別する。グルーピング・トラッカーはこれらトークンを解析してトークンの属するマージされたイベント（もしあれば）を判定する。説明される実施形態では、グルーピング・トラッカーはコンフィギュラブル（configurable: 構成可能な）マージ・プロパティ（merge property: 併合属性）に従って動作するが、他の実施形態ではハードコード化されたプロパティを有してもよい。マージ・プロパティにより、ログ・エントリをハイレベルの被マージイベント（merged event）へとグループ化する動作に関連する各種プロパティを構成することができる。説明される実施形態では、これらプロパティは、以下のいくつかもしくは全てを含む： 各被マージイベントのために考慮されるべきログ・エントリがどんなタイプであるか； 各被マージイベントを識別するために使用されるＩＤ； エンドエントリが検出されない場合であっても、既存の被マージイベントのためのエントリの収集を自動的に終了するタイムアウト値。
【０００７】
記述された実施形態では、マッピング・モジュールは特定の被マージイベントに関連するログ・エントリを受け取り、これらをマッピング・プロパティ（これらマッピング・プロパティはまたハードコードされていてもよいが）に従って被マージイベントデータ構造のフィールドにマップする。
【０００８】
本発明の記述された実施形態は、マージ・プロパティの正規表現を使用して、受け取られたログ・エントリ内で検索される値を述べる。例えば、正規表現はマルチ・エントリ・イベントの一部であるエントリを定義してもよく、マルチ・エントリ・イベントの最初のエントリを検出してもよく、マルチ・エントリ・イベントの最後のエントリを検出してもよい。マージ・プロパティはまた、マージされるために同じ値を含んでいるのがエントリのどのフィールドかを宣言する（例えば、エントリは同じ数字ＩＤや同じＩＰアドレスの記述をともに有してもよい）。本発明の記述された実施形態は互いに散在するイベントのためのログ・エントリを処理することができる。
【図面の簡単な説明】
【０００９】
【図１】本発明の一実施形態に従ったシステムのブロック図。
【図２】マージプロパティに従ってログ・エントリを処理するために行われる方法の一実施形態のフローチャート。
【図３】マッピングプロパティに従ってログ・エントリを被マージイベントに加えるために行われる方法の一実施形態のフローチャート。
【図４】本発明の一実施形態におけるマッピングプロパティで用いられるoneOf関数を示すフローチャート。
【図５】各種被マージイベントのための散在したログ・エントリが受け取られた場合の、複数被マージイベントが構築されている例。
【図６】一つの被マージイベントのフォーマット例。
【発明を実施するための形態】
【００１０】
ここで本発明の一実施形態を、類似の参照符号が同一のまたは機能的に同等の要素を示している図面を参照しながら説明する。
【００１１】
図１は、本発明の一実施形態に従ってシステム１００のブロック図を示す。システム１００は好ましくは、ネットワーク上の一つ以上のセントラル・ポイントでエージェント１０４を含む。ネットワーク、例えば、インターネット、ＬＡＮ、ＷＡＮ、無線ネットワーク、移動式ネットワーク、または、リモートデバイスがエージェント１０４にログ・エントリを送信可能な他の何らかの適切な機構上で、エージェント１０４は複数デバイスおよびいくつかのソフトウェアからログ・エントリを受け取る。
【００１２】
ログ・エントリはパーサ (parser: 構文解析プログラム) １０２によって受け取られ、当業者に周知の手法でトークンに構文解析される。他の実施形態では、パーシング（構文解析）の実行は、Hector Aguilar-Macias他による２００５年３月１日付け出願の米国特許出願番号１１／０７０，０２４、「ネットワークセキュリティシステムにおけるメッセージパーシング」で説明されており、参照することによって本明細書に組み込まれている。
【００１３】
受け取られたログ・エントリは、パーサ１０２が構文解析することのできる何らかの適切なフォーマットであってよい。パーサ１０２は受け取られたログ・エントリに基づいたトークンを出力する。これらのトークンはグルーピング・トラッカー・モジュール１１０で受け取られる。
【００１４】
グルーピング・トラッカー・モジュール(grouping tracker module: グループ化追跡取得プログラム・モジュール)１１０は、メモリ、もしくは他の記憶モジュールまたはデバイス１１２からマージ・プロパティ（merge property: マージの特性若しくは属性）を受け取るように接続される。マージ・プロパティは、被マージイベント（merged event: 「複数のログ・エントリを合併したイベント」の意）を構築する際に使用され、受け取られたログ・エントリがどのように解釈されるべきかを指定する。グルーピング・トラッカー・モジュールは特定の被マージイベントに関連するログ・エントリをマッピング・モジュール内に出力する。マッピング・モジュールにおいて、ログ・エントリは、受け取られたログ・エントリから構築されつつある被マージイベント内にマッピングされる（配置される）。このマッピングはマッピング・プロパティ１２２に従って行われる。マッピング・モジュール１２０の出力は、複数ログ・エントリに起因する一つ以上の被マージイベントである。図１に概ね示されているこの工程につき、一例に関連して、以下、より詳細に説明する。
【００１５】
［例］
この例は、本発明の一実施形態において、どのようにイベントマージングが動作するのかの例である。
【００１６】
以下のようにログ・エントリを仮定する（また、これらは時として「メッセージ」と呼ばれる）。
[18/Jul/2005:12:30:20 -0400] conn=8 op=0 msgId=82 - BIND uid=admin
[18/Jul/2005:12:30:25 -0400] conn=7 op=-1 msgId=-1 - LDAP connection from 10.0.20.122 to 10.0.20.122
[18/Jul/2005:12:30:30 -0400] conn=8 op=0 msgId=82 - RESULT error=0
【００１７】
パーサ１０２はこれら受け取られたログ・エントリをキー・バリュー・ペア(key-value pair)に構文解析する。各ログ・エントリに対するこういった処理はトークンの１セットを生成する。例えば、ログ・エントリ
[18/Jul/2005:12:30:20 -0400]] conn=8 op=0 msgId=82 - BIND uid=admin
は以下のキー・バリュー・ペア(key/value pair)を有するトークンを生成する。
Date=18/Jul/2005 12:30:20
Connection=8
Operation=0
MessageId=82
OperationName=BIND
UserId=admin
【００１８】
同様に、他の２つのログ・エントリは自身のキー・バリュー・ペアを生成する。
[18/Jul/2005:12:30:25 -0400]] conn=7 op=-1 msgId=-1 - LDAP connection from 10.0.20.122 to 10.0.20.12
Date=18/Jul/2005 12:30:25
Connection=7
Operation=1
MessageId=-1
OperationName=LDAP
Source=10.0.20.122
Destination=10.0.20.12
【００１９】
[18/Jul/2005:12:30:30 -0400]] conn=8 op=0 msgId=82 - RESULT err=0
Date=18/Jul/2005 12:30:30
Connection=8
Operation=0
MessageId=82
OperationName=RESULT
ResultCode=0
【００２０】
図２はマージ・プロパティ１１２に従って受け取られたログ・エントリを処理するために行われる方法の一実施形態のフローチャート２００である。好適な実施形態では、この方法はグルーパ（grouper）／トラッカー１１０によって実行される。タイムアウトが、構築中の被マージイベントに到達した場合（２０２）、被マージイベントは終了して（２０４）、制御は要素（２０２）に戻る。よって、明らかな終了のログ・エントリが一つも検出されなかったとしても、被マージイベントのタイムアウトが発生すれば、その被マージイベントは閉じられるはずである。タイムアウト値は、ログするデバイスの種類毎に異なってもよく、単一デバイスからの被マージイベント毎に異なってもよい。以下に説明されるように、タイムアウト値はマージ・プロパティに含まれている。
【００２１】
要素２０６では、次のログ・エントリが処理のために受け取られる。そのログ・エントリがマージング（マージ・プロパティ１１２に定義されているように）のためのものであると考えられるはずである場合（２０８）には処理が継続され、そうでない場合にはシングルイベントが送出され（２０９）要素２０２に処理が戻る。
【００２２】
ログ・エントリが或る新しい被マージイベント２１０（マージ・プロパティ１１２に定義されているように）についての開始のログ・エントリである場合、当該新しい被マージイベントが開かれる（２１２、構築中の処理における複数の被マージイベントの例として図５参照）。いくつかの実施形態では、その被マージイベントのタイムアウトクロックがスタートされる（２１２）。
【００２３】
ログ・エントリが、開始のログ・エントリではなく、構築中の既存の被マージイベントのＩＤを含んでいる場合（２１４）、イクセプションがログ・記録され、シングルのイベントが送出される（２１５）。そうでない場合、処理は継続されてトークンおよびログ・エントリがマッピング・モジュールに送られ（２２０）、この結果、その情報を被マージイベントに付加することができる。一実施形態では、ＩＤはログ・エントリのシングルフィールドであってもよく、被マージイベントの全てのログ・エントリに共通の値を持つログ・エントリの複数フィールドであってもよい。
【００２４】
ログ・エントリが或る既存の被マージイベント（マージプロパティ１１２に定義されているように）についての終了のログ・エントリである場合（２１６）、既存の被マージイベントは終了され、グルーパ／トラッカーから取り除かれる（２１８、構築中の処理における複数の被マージイベントの例として図５参照）。ログ・エントリがイベント終了を示している場合、対応する被マージイベントは終了され、図５に示される構造から取り除かれなければならない。
【００２５】
例の説明を続けると、この例のマージ・プロパティ１１２は以下のように定義される。
merge.count=1
merge[0].pattern.count=1
merge[0].pattern[0].token=OperationName
merge[0].pattern[0].regex=(BIND|RESULT)
merge[0].starts.count=1
merge[0].starts[0].token=OperationName
merge[0].starts[0].regex=BIND
merge[0].ends.count=1
merge[0].ends[0].token=OperationName
merge[0].ends[0].regex=RESULT
merge[0].id.tokens=Connection,Operation,MessageId
merge[0].timeout=60000
【００２６】
先ず、我々はただ一つの被マージオペレーションを有することを示す。
merge.count=1
【００２７】
それから、マージングのために考えられるべき、BINDまたはRESULTに設定されているOperationNameを有する全てのメッセージを求めることを我々は定義する。
merge[0].pattern.count=1
merge[0].pattern[0].token=OperationName
merge[0].pattern[0].regex=(BIND|RESULT)
【００２８】
今や、BINDに設定されているOperationNameを有するメッセージがマージ処理を開始することを指定する。
merge[0].starts.count=1
merge[0].starts[0].token=OperationName
merge[0].starts[0].regex=BIND
【００２９】
そして、OperationNameがRESULTにセットされているメッセージを検出すると、マージ処理を終了することにすると指定する。
merge[0].ends.count=1
merge[0].ends[0].token=OperationName
merge[0].ends[0].regex=RESULT
【００３０】
我々はまた、イベントが同じグループに属することをどのように識別するかを定義する必要があり、Connection（接続）、Operation（オペレーション）およびMessageId（メッセージＩＤ）の値が同一でなければならないということを指定することでこれを行う（被マージイベントのためのＩＤを形成すること）。
merge[0].id.tokens=Connection, Operation,MessageId
【００３１】
最後に、タイムアウトを定義して、もし６０秒後にOperationNameがRESULTにセットされているメッセージを得られなかった場合、そのイベントはそのまま送出する。
merge[0].timeout=60000
【００３２】
図３は、マッピングプロパティに従ってログ・エントリを被マージイベントに加えるために行われる方法の一実施形態のフローチャートである。受け取られたログ・エントリおよびそれらのトークンは、構築された被マージイベントの少なくとも一つと関連しているとして既に識別されている。マッピング・モジュール１２０はログ・エントリの情報を構築された一つ以上の被マージイベントにマップする（構築された複数の被マージイベントの例として図５参照、被マージイベントのためのフォーマット例として図６参照）。
【００３３】
この例では、マッピング・プロパティ１２２は以下のように定義される。
event.deviceReceiptTime=Date
event.name=_oneOf(mergedevent.name,OperationName)
event.deviceAction=ResultCode
event.destinationUserId=UserId
【００３４】
これらプロパティは、イベントのためのタイムスタンプとしてDateを、デバイスアクションとしてResultCodeを、そして、出力先ユーザＩＤとしてUserIDを使用するつもりであることを示す。名前は以下のように定義される。
event.name=_oneOf(mergedevent.name,OperationName)
【００３５】
こういったフレーム構造なので、最終データを格納するために使用することができる「トラッキング」イベントを参照することができる。この場合、OperationNameまたは「トラッキング」イベントの名前（もしあれば）のいずれかを使用すべきであるということを、オペレーションは意味する。例えば、最初のイベントは以下のキー・バリューを含んでいるであろう。
[18/Jul/2005/:12:30:20 -0400]] conn=8 op=0 msgId=82 - BIND uid=admin
Date=18/Jul/2005 12:30:20
Connection=8
Operation=0
MessageId=82
OperationName=BIND
UserId=admin
【００３６】
そして新たな「トラッキング」イベントが生成されて、以下のマッピングで終了するであろう。
mergedevent.name=BIND
mergedevent.device ReceiptTime=18/Jul/2005 12:30:20
mergedevent.destinationUserId=admin
【００３７】
被マージイベントの名前は新しい被マージイベントであるためBINDとなり、mergedevent.nameは一つも存在せず、OperationNameの値は使用される（BIND）。ここで、マージンググループのための第２のイベントが処理されると以下になる。
[18/Jul/2005:12:30:30 -0400]] conn=8 op=0 msgId=82 - RESULT err=0
Date=18/Jul/2005 12:30:30
Connection=8
Operation=0
MessageId=82
OperationName=RESULT
ResultCode=0
【００３８】
被マージイベントは以下のようにマップされるであろう。
mergedevent.name=BIND
mergedevent.deviceReceiptTime=18/Jul/2005 12:30:30
mergedevent.destinationUserId=admin
mergedevent.deviceAction=0
【００３９】
このイベントが処理されるとき、BINDにセットされた名前で「トラック化された」イベント（mergedevent）が既にあるため、mergedevent.nameがBINDにセットされることに注目されたい。そこで、この場合、OperationNameは使用されず、mergedeventは値BINDを維持する。mergedeventの値はデフォルトによって置き換えられるであろうから、今はどのようにmergedevent.deviceReceiptTimeが18/Jul/2005 12:30:30にセットされたかに注目されたい。そこで、deviceReceiptTimeは最新の値と見なされるであろう。
【００４０】
図４は、本発明の一実施形態におけるマッピング・プロパティで用いられるoneOf関数４０２を示すフローチャート４００である。例えば、イベント名のためにoneOf関数を実行するためには、イベント名が現在ブランクである場合（４０４）、現在のトークン名が使用される（４０６）。名前がブランクであない場合、非ブランク(non-blank)名が維持される（４０８）。
【００４１】
oneOfはマッピングコンポーネントで使用することができるオペレーションの一例にすぎないということが理解されるはずである。マッピングコンポーネントは、被マージイベントのフィールドを参照することができる他の「オペレーション」を含んでもよい。oneOf関数は、実際のマッピングフレーム構造における一例にすぎない。オペレーションの他の例は連結(concatenate)、タイプ変換オペレーションおよびその他を含む。
【００４２】
図５は、各種の被マージイベントのためのログ・エントリが分散的に受け取られる場合に、複数の被マージイベントが構築されつつある例５００を示す。
【００４３】
図６は一つの被マージイベントのフォーマット例５５０を示す。例えば、図５の各種被マージイベントそれぞれでは、全ての値を各被マージイベントのそれぞれに満たすことができないが、このフォーマットを有する。本願発明の各種具体例は、連結、タイプ変換、カウンティング、およびその他を含んだ被マージオペレーションの他の例を含むことができる。他の実施形態は、被マージイベントの各種タイプの数を統計が維持することができるようにするために、被マージイベントの集合体を含む。これら統計されたデータを、単体でまたは他の送信データとの組み合わせでモニタに送信することができる。
【００４４】
以下の段落では本発明の一実施形態に含まれるマージ・プロパティ１１２例が簡単に記述される。
【００４５】
merge.count
定義されるはずのマージ・オペレーションの数を定義。
【００４６】
merge[{mergeindex}].pattern.count
定義されるであろうパターンがいくつあるかを定義する。マージ・オペレーションはマージ・オペレーションで考慮されるであろうイベントを定義するためのパターンを必要とする。もしパターンが一つも与えられていなければ全ての(ALL)イベントが考慮されるであろう。
【００４７】
merge[{mergeindex}].pattern[{patternindex}].token
このパターンのために使用されるであろうトークンを定義する。
【００４８】
merge[{mergeindex}].pattern[{patternindex}].regex
このパターンで使用するための正規表現を定義する。
【００４９】
merge[{mergeindex}].starts.count
定義されるであろうスタートパターンがいくつあるかを定義する。マージ・オペレーションはマージ・オペレーションを開始するはずのイベントを定義するためのスタートパターンを必要とする、もしパターンが一つも与えられていなければ全ての(ALL)イベントがマージオペレーションを開始する。オペレーションが一旦開始されると、タイムアウトまたはエンドパターンマッチを介した終了のみすることができる。
【００５０】
merge[{mergeindex}].starts[{patternindex}].token
このスタートパターンのために使用されるはずのトークンを定義。
【００５１】
merge[{mergeindex}].starts[{patternindex}].regex
このスタートパターンで使用するための正規表現を定義する。
【００５２】
merge[{mergeindex}].ends.count
定義されるであろうエンドパターンがいくつあるかを定義する。マージ・オペレーションはマージ・オペレーションを終了するはずのイベントを定義するためのエンドパターンを必要とする、もしパターンが一つも与えられていなければ一つのイベントもマージ・オペレーションを終了せず、そのオペレーションはタイムアウトを介した終了のみができる。
【００５３】
merge[{mergeindex}].ends[{patternindex}].token
このエンドパターンのために使用されるであろうトークンを定義する。
【００５４】
merge[{mergeindex}].ends[{patternindex}].regex
このエンドパターンで使用するための正規表現を定義する。
【００５５】
merge[{mergeindex}].timeout
マージング・オペレーションのためにタイムアウトをミリ秒単位で定義する。タイムアウトが到達した場合、マージ・オペレーションは終了するはずであり、イベントは送出されるはずである。これらイベントは異なるスレッドを介して送出されるはずであり、イベントの順番は保証されないということに留意する。
【００５６】
merge[{mergeindex}].id.delimiter
前述のリストに使用するためのオプションのデリミタを定義する。もし定義されていないのであれば、デリミタはコンマ(,)である。
【００５７】
merge[{mergeindex}].sendpartialevents
このプロパティはオプショナルであり、デフォルトでフォールスにセットされている。基本的にこのプロパティは、他のイベントとマージされているとしてマージ・オペレーションの各イベントが個別に送出されなければならないかどうかを指定する。
【００５８】
merge[{mergeindex}].capacity
このプロパティはオプショナルであり、デフォルトで１０００にセットされている。イベント・マージング・オペレーションは被マージ結果を維持するイベントのキャッシュを必要とする。これはどれだけキャッシュが大きくあるはずかを定義し、キャッシュがオーバーフローするとイベントはそのまま送出されるはずでありエラーがログ・記録されるはずである。
【００５９】
本明細書内の「一実施形態」または「実施形態」の参照は、その実施形態に関連して記述された特別な機能、構成または特徴が本発明の少なくとも１つの実施形態に含まれていることを意味する。本明細書の各所の「一実施形態では」といった句の出現は必ずしも同じ実施形態を参照することが全てであるということではない。
【００６０】
詳細な説明のいくつかの箇所は、コンピュータメモリ内のデータビット上で稼働するアルゴリズムおよび象徴の用語で記述されている。これらのアルゴリズム記述や表示は、データ処理分野の熟練者が他の当業者に自身の仕事の本質を最も効果的に伝達する手段である。アルゴリズムはここでは、しかも一般的に、所望の結果を導き出す工程（命令）の首尾一貫した順序であると考える。これら工程は物理的な量の物理的な操作を必要とするものである。通常、必ずというわけではないが、これらの量は、記憶、転送、組み合わせ、比較、および他の操作が可能な電気的または磁気的な信号といった形態をとる。大部分は共通使用の理由で、これらの信号はビット、値、要素、シンボル、キャラクタ、ターム、番号またはこれに類するもので呼ばれることは都合のいい時々に証明されている。
【００６１】
しかし、これらおよび類似のタームの全ては適切な物理量に関連し、これらの量に適用される便利な表示に過ぎないといったことを心にとどめておくべきである。詳細に述べられてない限り、そうでなければ解説から明らかではない限り、例えば「処理する（processing）」や「コンピュータで計算する（computing）」や「計算する（calculating）」や「判定する（determining）」や「表示する（displaying）」や同様のタームを使用する解説はコンピュータシステムや類似の電子計算装置の操作および作業を参照する、ということは説明全体を通して正しく理解され、コンピュータシステムは、そのレジスタおよびメモリ内の物理（電子）量として表されるデータを操作して、コンピュータシステムメモリやレジスタ、もしくはその他の情報記憶装置、伝送または表示装置内で物理量として同様に表される他のデータに変換する。
【００６２】
本発明のある局面は、アルゴリズムの形式でここで説明される、処理工程および命令を含む。注意すべきは、本発明の処理工程および命令を、ソフトウェア、ファームウェア、または、ハードウェアで具体化することができるということであり、ソフトウェアで具体化される場合、これらは常駐するようにダウンロードできたり、リアルタイムネットワークオペレーティングシステムを用いて異なるプラットフォームから操作できたりする。
【００６３】
本発明はまた、ここでの動作を実行するための装置に関連する。この装置は必要な目的のために特別に構築してもよく、コンピュータによりアクセスできるコンピュータ読み取り可能な媒体に格納されたコンピュータプログラムによって、選択的に稼働または再構築される汎用コンピュータを備えてもよい。こういったコンピュータプログラムは、例えば、ただし限定されるわけではなく、フロッピー（登録商標）ディスクを含んだあらゆるタイプのディスク、光ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、リードオンリーメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気または光カード、特定用途向けＩＣ（ＡＳＩＣ）、または、電子命令を格納するのに好適なあらゆるタイプの媒体であるコンピュータ読み取り可能な記憶媒体に格納してもよく、これら媒体のそれぞれはコンピュータのシステムバスに接続される。さらに、この明細書で参照されるコンピュータは、シングルプロセッサを含んでもよく、または、計算能力を向上するために設計されたマルチプロセッサを採用したアーキテクチャであってもよい。
【００６４】
ここで提示されるアルゴリズムおよび動作は、何らかの特別なコンピュータや他の装置に本質的に関連しているわけではない。各種汎用システムをここでの教示に従ってプログラムと共に使用することができ、または、必要な方法工程を実行するより専門的な装置を構築することが便利であることも証明できる。これらシステムの多様性のための必要な構成は、等価の変化と共に当業者とって明らかである。加えて、本発明は何らかの特別なプログラミング言語を参照して説明されてはいない。プログラミング言語の多様性は、ここで説明されるように、本発明の教示を実現するために使用することができ、特定言語の何らかの参照は本発明の使用可能性および本発明のベストモードのために提供される。
【００６５】
好適な実施形態およびいくつかの代替の実施形態を参照して、本発明は詳細に示し、説明されている一方、形や詳細の各種変更が本発明の気質や範囲から乖離することなくここで可能であることは関連分野の当業者に理解されるはずである。
【００６６】
最後に、注意すべきは、本明細書で使用される言語は、可読性および教示用目的のために主として選択され、発明的主題(inventive subject matter)を線引きまたは範囲を定めるために選択されたわけではない、ということである。従って、本発明の開示は、本発明の範囲の実例となるように意図されており、限定されず、特許請求の範囲に示される。
【符号の説明】
【００６７】
１００ システム
１０２ パーサ (構文解析プログラム)
１０４ エージェント
１１０ グルーピング・トラッカー・モジュール
１１２ マージ・プロパティ
１２０ マッピング・モジュール
１２２ マッピング・プロパティ
【特許請求の範囲】
【請求項１】
データ処理システムにより受け取られた１又は複数のデバイスからの複数のログ・エントリをマージするための方法であって、
複数のログ・エントリを受け取るステップと、
前記受け取った複数のログ・エントリのそれぞれに対し、
マージ・プロパティに従って当該ログ・エントリがいずれかの潜在的な被マージイベントに共通するＩＤを含んでいるかを判定することと、
前記マージ・プロパティに従って或る被マージイベントの開始を示すログ・エントリであるかどうかを判定することと、
当該ログ・エントリが前記被マージイベントの開始のログ・エントリである場合、新たな被マージイベントの作成を開始することと、
前記マージ・プロパティに従って既存の被マージイベントの終了を示すログ・エントリであるかどうかを判定することと、
当該ログ・エントリが前記既存の被マージイベントの終了のログ・エントリである場合、該既存の被マージイベントの作成を終了すること、
を行うステップと、ここで、前記受け取った複数のログ・エントリには、複数の異なる被マージイベントに対応するログ・エントリが分散的に混在して含まれており、
或る既存の被マージイベントに共通なＩＤを含む各ログ・エントリを、前記被マージイベントのためのマッピング・プロパティに従って当該被マージイベントにマッピングするステップと
を備える方法。
【請求項２】
或る既存の被マージイベントのためのマージ・プロパティに規定されたタイムアウトが発生した場合、当該被マージイベントの作成を終了するステップを更に備える請求項１の方法。
【請求項３】
前記被マージイベントに対して或るログ・エントリをマッピングする際に、該被マージイベントの作成が開始したがまだその作成が終了していないときには該被マージイベントがそれまでと同様に存在しているとみなす機能を更に備える請求項２の方法。
【請求項４】
前記機能はマッピング動作で使用される、請求項３に記載の方法。
【請求項５】
受け取られたログ・エントリのそれぞれが、前記マージ・プロパティに従って、マージの対象として考慮されるべきであるかどうかを判定するステップを更に備える請求項１乃至４のいずれかの方法。
【請求項６】
前記ログ・エントリを被マージイベントにマッピングする前記ステップは、前記被マージイベントにおける前記開始のログ・イベントの時間を判定することを更に含む、請求項１乃至５のいずれかの方法。
【請求項７】
前記ログ・エントリを被マージイベントにマッピングする前記ステップは、前記被マージイベントにおける前記終了のログ・イベントの時間を判定することを更に含む、請求項１乃至６のいずれかの方法。
【請求項８】
前記ログ・エントリを被マージイベントにマッピングする前記ステップは、前記マッピング・プロパティに従ってイベントＩＤをマッピングすることを更に含む請求項１乃至７のいずれかの方法。
【請求項９】
前記ログ・エントリを被マージイベントにマッピングする前記ステップは、前記マッピング・プロパティに従ってイベント名をマッピングすることを更に含む請求項１乃至８のいずれかの方法。
【請求項１０】
前記ログ・エントリを被マージイベントにマッピングする前記ステップは、前記ログ・エントリから構文解析された名前をマッピングすることを更に含み、前記マッピングは前記マッピング・プロパティのoneOf関数に従って実行される、請求項１乃至９のいずれかの方法。
【請求項１１】
前記ログ・エントリを被マージイベントにマッピングする前記ステップは、前記マッピング・プロパティに従って前記被マージイベントのデバイスアクションフィールドに前記ログ・エントリのデバイスアクションの値をマッピングする、ことを更に含む請求項１乃至１０のいずれかの方法。
【請求項１２】
前記受け取られた複数のログ・エントリは、複数の被マージイベントに対応するログ・エントリを含んでおり、該複数の被マージイベントに対応する該ログ・エントリが該複数の各被マージイベント内にそれぞれ混合される、請求項１乃至１１のいずれかの方法。
【請求項１３】
１つの受け取られたログ・エントリは複数の被マージイベントを構築するのに使用される、請求項１乃至１１のいずれかの方法。
【請求項１４】
１つのＩＤが１つの前記ログ・エントリ内の複数フィールドを構成し、前記複数フィールドは、１つの被マージイベントに貢献する複数ログ・エントリを識別するように動作する、請求項１乃至１３のいずれかの方法。
【請求項１５】
前記受け取った複数のログ・エントリには、前記複数の異なる被マージイベントに対応するログ・エントリに加えて更に被マージイベントに対応していないログ・エントリが分散的に混在して含まれており、
前記受け取ったログ・エントリが被マージイベントに対応していないと判定した場合、該被マージイベントに対応していないログ・エントリをシングルイベントとして出力する、請求項１乃至１４のいずれかの方法。
【請求項１６】
データ処理システムで受け取られた１又は複数のデバイスからの複数ログ・エントリをマージするためのシステムにおいて、
複数のログ・エントリを受け取るためのモジュールと、
前記ログ・エントリをトークンに構文解析する構文解析手段と、
前記受け取った複数のログ・エントリのそれぞれに対して、
マージ・プロパティに従って当該ログ・エントリがいずれかの潜在的な被マージイベントに共通するＩＤを含んでいるかを判定し、
前記マージ・プロパティに従って或る被マージイベントの開始を示すログ・エントリであるかどうかを判定し、
前記ログ・エントリが前記被マージイベントの開始のログ・エントリである場合、新たな被マージイベントの作成を開始し、
前記マージ・プロパティに従って既存の被マージイベントの終了を示すログ・エントリであるかどうかを判定し、
前記ログ・エントリが前記既存の被マージイベントの終了のログ・エントリである場合、当該既存の被マージイベントの作成を終了する、グループ化手段と、ここで、前記受け取った複数のログ・エントリには、複数の異なる被マージイベントに対応するログ・エントリが分散的に混在して含まれており、
或る既存の被マージイベントに共通なＩＤを含む各ログ・エントリを、前記被マージイベントのためのマッピング・プロパティに従って当該被マージイベントにマッピングするマッピング手段と
を備えるシステム。
【請求項１７】
コンピュータに、
１又は複数のデバイスからの複数のログ・エントリを受け取る手順と、
前記受け取った複数のログ・エントリのそれぞれに対し、
マージ・プロパティに従って当該ログ・エントリがいずれかの潜在的な被マージイベントに共通するＩＤを含んでいるかを判定することと、
前記マージ・プロパティに従って或る被マージイベントの開始を示すログ・エントリであるかどうかを判定することと、
当該ログ・エントリが前記被マージイベントの開始のログ・エントリである場合、新たな被マージイベントの作成を開始することと、
前記マージ・プロパティに従って既存の被マージイベントの終了を示すログ・エントリであるかどうかを判定することと、
当該ログ・エントリが前記既存の被マージイベントの終了のログ・エントリである場合、該既存の被マージイベントの作成を終了すること、
を行う手順と、ここで、前記受け取った複数のログ・エントリには、複数の異なる被マージイベントに対応するログ・エントリが分散的に混在して含まれており、
或る既存の被マージイベントに共通なＩＤを含む各ログ・エントリを、前記被マージイベントのためのマッピング・プロパティに従って当該被マージイベントにマッピングする手順と
を実行させるためのコンピュータプログラム。
【請求項１】
データ処理システムにより受け取られた１又は複数のデバイスからの複数のログ・エントリをマージするための方法であって、
複数のログ・エントリを受け取るステップと、
前記受け取った複数のログ・エントリのそれぞれに対し、
マージ・プロパティに従って当該ログ・エントリがいずれかの潜在的な被マージイベントに共通するＩＤを含んでいるかを判定することと、
前記マージ・プロパティに従って或る被マージイベントの開始を示すログ・エントリであるかどうかを判定することと、
当該ログ・エントリが前記被マージイベントの開始のログ・エントリである場合、新たな被マージイベントの作成を開始することと、
前記マージ・プロパティに従って既存の被マージイベントの終了を示すログ・エントリであるかどうかを判定することと、
当該ログ・エントリが前記既存の被マージイベントの終了のログ・エントリである場合、該既存の被マージイベントの作成を終了すること、
を行うステップと、ここで、前記受け取った複数のログ・エントリには、複数の異なる被マージイベントに対応するログ・エントリが分散的に混在して含まれており、
或る既存の被マージイベントに共通なＩＤを含む各ログ・エントリを、前記被マージイベントのためのマッピング・プロパティに従って当該被マージイベントにマッピングするステップと
を備える方法。
【請求項２】
或る既存の被マージイベントのためのマージ・プロパティに規定されたタイムアウトが発生した場合、当該被マージイベントの作成を終了するステップを更に備える請求項１の方法。
【請求項３】
前記被マージイベントに対して或るログ・エントリをマッピングする際に、該被マージイベントの作成が開始したがまだその作成が終了していないときには該被マージイベントがそれまでと同様に存在しているとみなす機能を更に備える請求項２の方法。
【請求項４】
前記機能はマッピング動作で使用される、請求項３に記載の方法。
【請求項５】
受け取られたログ・エントリのそれぞれが、前記マージ・プロパティに従って、マージの対象として考慮されるべきであるかどうかを判定するステップを更に備える請求項１乃至４のいずれかの方法。
【請求項６】
前記ログ・エントリを被マージイベントにマッピングする前記ステップは、前記被マージイベントにおける前記開始のログ・イベントの時間を判定することを更に含む、請求項１乃至５のいずれかの方法。
【請求項７】
前記ログ・エントリを被マージイベントにマッピングする前記ステップは、前記被マージイベントにおける前記終了のログ・イベントの時間を判定することを更に含む、請求項１乃至６のいずれかの方法。
【請求項８】
前記ログ・エントリを被マージイベントにマッピングする前記ステップは、前記マッピング・プロパティに従ってイベントＩＤをマッピングすることを更に含む請求項１乃至７のいずれかの方法。
【請求項９】
前記ログ・エントリを被マージイベントにマッピングする前記ステップは、前記マッピング・プロパティに従ってイベント名をマッピングすることを更に含む請求項１乃至８のいずれかの方法。
【請求項１０】
前記ログ・エントリを被マージイベントにマッピングする前記ステップは、前記ログ・エントリから構文解析された名前をマッピングすることを更に含み、前記マッピングは前記マッピング・プロパティのoneOf関数に従って実行される、請求項１乃至９のいずれかの方法。
【請求項１１】
前記ログ・エントリを被マージイベントにマッピングする前記ステップは、前記マッピング・プロパティに従って前記被マージイベントのデバイスアクションフィールドに前記ログ・エントリのデバイスアクションの値をマッピングする、ことを更に含む請求項１乃至１０のいずれかの方法。
【請求項１２】
前記受け取られた複数のログ・エントリは、複数の被マージイベントに対応するログ・エントリを含んでおり、該複数の被マージイベントに対応する該ログ・エントリが該複数の各被マージイベント内にそれぞれ混合される、請求項１乃至１１のいずれかの方法。
【請求項１３】
１つの受け取られたログ・エントリは複数の被マージイベントを構築するのに使用される、請求項１乃至１１のいずれかの方法。
【請求項１４】
１つのＩＤが１つの前記ログ・エントリ内の複数フィールドを構成し、前記複数フィールドは、１つの被マージイベントに貢献する複数ログ・エントリを識別するように動作する、請求項１乃至１３のいずれかの方法。
【請求項１５】
前記受け取った複数のログ・エントリには、前記複数の異なる被マージイベントに対応するログ・エントリに加えて更に被マージイベントに対応していないログ・エントリが分散的に混在して含まれており、
前記受け取ったログ・エントリが被マージイベントに対応していないと判定した場合、該被マージイベントに対応していないログ・エントリをシングルイベントとして出力する、請求項１乃至１４のいずれかの方法。
【請求項１６】
データ処理システムで受け取られた１又は複数のデバイスからの複数ログ・エントリをマージするためのシステムにおいて、
複数のログ・エントリを受け取るためのモジュールと、
前記ログ・エントリをトークンに構文解析する構文解析手段と、
前記受け取った複数のログ・エントリのそれぞれに対して、
マージ・プロパティに従って当該ログ・エントリがいずれかの潜在的な被マージイベントに共通するＩＤを含んでいるかを判定し、
前記マージ・プロパティに従って或る被マージイベントの開始を示すログ・エントリであるかどうかを判定し、
前記ログ・エントリが前記被マージイベントの開始のログ・エントリである場合、新たな被マージイベントの作成を開始し、
前記マージ・プロパティに従って既存の被マージイベントの終了を示すログ・エントリであるかどうかを判定し、
前記ログ・エントリが前記既存の被マージイベントの終了のログ・エントリである場合、当該既存の被マージイベントの作成を終了する、グループ化手段と、ここで、前記受け取った複数のログ・エントリには、複数の異なる被マージイベントに対応するログ・エントリが分散的に混在して含まれており、
或る既存の被マージイベントに共通なＩＤを含む各ログ・エントリを、前記被マージイベントのためのマッピング・プロパティに従って当該被マージイベントにマッピングするマッピング手段と
を備えるシステム。
【請求項１７】
コンピュータに、
１又は複数のデバイスからの複数のログ・エントリを受け取る手順と、
前記受け取った複数のログ・エントリのそれぞれに対し、
マージ・プロパティに従って当該ログ・エントリがいずれかの潜在的な被マージイベントに共通するＩＤを含んでいるかを判定することと、
前記マージ・プロパティに従って或る被マージイベントの開始を示すログ・エントリであるかどうかを判定することと、
当該ログ・エントリが前記被マージイベントの開始のログ・エントリである場合、新たな被マージイベントの作成を開始することと、
前記マージ・プロパティに従って既存の被マージイベントの終了を示すログ・エントリであるかどうかを判定することと、
当該ログ・エントリが前記既存の被マージイベントの終了のログ・エントリである場合、該既存の被マージイベントの作成を終了すること、
を行う手順と、ここで、前記受け取った複数のログ・エントリには、複数の異なる被マージイベントに対応するログ・エントリが分散的に混在して含まれており、
或る既存の被マージイベントに共通なＩＤを含む各ログ・エントリを、前記被マージイベントのためのマッピング・プロパティに従って当該被マージイベントにマッピングする手順と
を実行させるためのコンピュータプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公開番号】特開２０１２−９４１６１（Ｐ２０１２−９４１６１Ａ）
【公開日】平成２４年５月１７日（２０１２．５．１７）
【国際特許分類】
【出願番号】特願２０１１−２５８３７１（Ｐ２０１１−２５８３７１）
【出願日】平成２３年１１月２６日（２０１１．１１．２６）
【分割の表示】特願２００９−５０４４２８（Ｐ２００９−５０４４２８）の分割
【原出願日】平成１９年４月３日（２００７．４．３）
【出願人】（５０６３６３９９７）アークサイト，インク． (6)
【Ｆターム（参考）】
【公開日】平成２４年５月１７日（２０１２．５．１７）
【国際特許分類】
【出願日】平成２３年１１月２６日（２０１１．１１．２６）
【分割の表示】特願２００９−５０４４２８（Ｐ２００９−５０４４２８）の分割
【原出願日】平成１９年４月３日（２００７．４．３）
【出願人】（５０６３６３９９７）アークサイト，インク． (6)
【Ｆターム（参考）】
[ Back to top ]