JP2013500542A

JP2013500542A - データのロギングと分析の方法およびシステム

Info

Publication number: JP2013500542A
Application number: JP2012522918A
Authority: JP
Inventors: クリストファー・エー・スミス; マイケル・エー・ベントコフスキー; マリーニ・コタパッリ
Original assignee: ベリサイン・インコーポレイテッド
Priority date: 2009-07-27
Filing date: 2010-07-23
Publication date: 2013-01-07
Also published as: CN102473085A; CA2764908A1; KR20120061777A; US20110022678A1; US8977705B2; EP2460066A1; WO2011014429A1; EP2460066A4

Abstract

インターネット要求のロギング方法には、関心のある複数のフィールドタイプを定義し、１つ以上のフィールドを含む要求をインターネットから受信することが含まれる。この方法には、１つ以上のフィールドの第１のフィールドの第１フィールドタイプが、関心のある複数のフィールドタイプの１つと一致するかどうかを判断し、第１のフィールドの少なくとも一部をキャッシュに格納することも含まれる。この方法には、１つ以上のフィールドの第２のフィールドの第２のフィールドタイプが、関心のある複数のフィールドタイプの１つに一致するかどうかを判断し、第２のフィールドの少なくとも一部をキャッシュに格納することも含まれる。さらに、この方法には、このキャッシュをサーバーに転送し、フィールド値の出現回数を判断し、このフィールド値の出現回数を含むレポートを提供することも含まれる。

Description

インターネットは、さまざまな形式とレベルの通信をサポートする国際的なコンピュータネットワークとしての機能がますます高まっている。たとえば、ワールドワイドウェブ（ＷＷＷ）上において、Ｗｅｂサイトと呼ばれる世界中で使用可能なページ上で情報を提供することができる。また、インターネットは、電子メール、インスタントメッセージ、およびボイスオーバーインターネットプロトコル（ＶｏＩＰ）通信を介して、エンドユーザー間の１対１の通信をサポートする。

ますます、インターネットは広範囲に分散したネットワークサービス（検索エンジン、冗長Ｗｅｂサイト、ＶｏＩＰ接続ポイントなど）によって構成されるようになってきている。こうしたネットワークサービスは、多くの物理的な地理上のサイトに展開されているが、論理的にネットワークサービスを提供している。広範囲に展開されたネットワークサービスの課題は、すべての物理的サイトと、物理的サイトのグリッド全体にわたるトラフィックの使用パターンを理解することである。

一部のインターネット要求を処理するため、ドメインネームシステム（ＤＮＳ）が利用される。ＤＮＳとは、クライアントサーバーモデルを基にした分散データベースシステムである。このデータベースのノードは、ネームサーバーと呼ばれる。各ドメインまたは各サブドメインは、そのドメインに関する情報と、そのドメインに従属するすべてのドメインのネームサーバーに関する情報を発行する１台以上の権限ＤＮＳサーバーを持つ。階層の最上位は、ルートネームサーバーと呼ばれるサーバーによって提供される。ルートネームサーバーとは、トップレベルドメイン（ＴＬＤ）の名前を検索または解決する際に照会されるサーバーのことである。その他のインターネット要求には、ＩＰ要求、ＯＣＳＰ要求、およびＷｈｏｉｓ要求が含まれる。

ネットワークサービスのオペレータにとっては、要求のトラッキングが望ましい。しかし、現在のシステムは、システムオペレータが必要とする深さのレベルでトラッキングデータを提供する機能は備えていない。そのため、インターネット要求をログに記録し、こうしたインターネット要求に関連する情報をレポートするための改善された方法とシステムの技術が必要になる。

本発明は、主にデータネットワークに関するものである。さらに具体的には、本発明は、ネットワークサービスの最も頻繁に出現する特徴を計算するための方法とシステムに関するものである。単なる例であるが、本発明は、関心のあるフィールドタイプに関するデータをフロントエンドプロセッサが受信した際に、そのデータをキャッシュして要約サーバーに転送するシステムに適用されている。この要約サーバーは、関心のある各フィールドタイプに対して最も頻繁に出現する値についてソート処理とレポート処理を実行する。本方法および技術は、ＤＮＳトラフィック、ＯＣＳＰトラフィック、Ｗｈｏｉｓトラフィックなどに適用することができる。

本発明の特定の実施形態に従い、要求のフィールドを分析し、関心のあるさまざまなフィールドタイプに対する特定の値の出現回数をカウントし、関心のある各フィールドタイプについて最も頻繁に出現する値を判断してレポートする。例として、処理エンジンが要求を受信すると、関心のあるフィールドタイプと一致するフィールドタイプを持つ要求内のフィールドがキャッシュされる。次に、このキャッシュがサーバーによって処理され、関心のあるフィールドタイプについて最も一般的に出現する値が判断される。一部の実施形態では、他のフィールドと結合されるフィールドに対して値が計算される。これは、構成を通じて設定することができる。次に、関心のある各フィールドタイプについて最も頻繁に出現する値（たとえば、関心のある特定のフィールドタイプの上位１０個の値など）が、レポートシステムを使用して、通常はシステムオペレータにレポートされる。

本発明の実施形態に従い、インターネット要求のロギング方法が提供される。この方法には、関心のある複数のフィールドタイプを定義し、インターネットからの要求を受信することが含まれる。この要求には、１つ以上のフィールドが含まれる。この方法には、１つ以上のフィールドの第１のフィールドの第１のフィールドタイプが、関心のある複数のフィールドタイプの１つに一致しているかどうかを判断し、第１のフィールドの少なくとも一部をキャッシュに格納することも含まれる。この方法には、１つ以上のフィールドの第２のフィールドの第２のフィールドタイプが、関心のある複数のフィールドタイプの１つに一致しているかどうかを判断し、第２のフィールドの少なくとも一部をキャッシュに格納することも含まれる。さらに、この方法には、このキャッシュをサーバーに転送し、第１のフィールドタイプと第２のフィールドタイプの少なくとも１つのフィールド値の出現回数をサーバー側で判断し、このフィールド値の出現回数を含むレポートを提供することも含まれる。

本発明の別の実施形態に従い、インターネット要求に対するレポート処理の方法が提供される。この方法には、関心のある複数のフィールドタイプを定義し、第１の処理エンジンにおいて、インターネットからの第１の複数の要求を受信することが含まれる。この第１の複数の要求のそれぞれには、１つ以上の第１のフィールド群が含まれる。この方法には、１つ以上の第１のフィールド群の第１のフィールドを第１のキャッシュに格納し、１つ以上の第１のフィールド群の第２のフィールドを第１のキャッシュに格納することも含まれる。さらに、この方法には、第２の処理エンジンにおいて、インターネットからの第２の複数の要求を受信することも含まれる。この第２の複数の要求のそれぞれには、１つ以上の第２のフィールド群が含まれる。この方法には、１つ以上の第２のフィールド群の第３のフィールドを第２のキャッシュに格納し、１つ以上の第２のフィールド群の第４のフィールドを第２のキャッシュに格納することも含まれる。さらに、この方法には、第１のキャッシュをサーバーに転送し、第２のキャッシュをサーバーに転送し、他のフィールド値よりも高い出現回数によって特徴付けられる最上位フィールド値をサーバー側で判断し、最上位フィールドの値とその出現回数を含むレポートを提供することも含まれる。

本発明の特定の実施形態に従い、システムが提供される。このシステムには、インターネットに接続され、インターネットからの要求を受信できる複数の処理エンジンが含まれる。各要求には、１つ以上のフィールドが含まれる。このシステムには、複数の処理エンジンに接続されたサーバーと、このサーバーに接続されたレポートシステムが含まれる。これらの複数の処理エンジンのそれぞれには、第１のデータプロセッサを制御してキャッシュを作成するための第１の複数の指示を格納する第１のコンピュータ可読媒体が含まれる。この第１の複数の指示には、インターネット経由の複数の要求を第１のデータプロセッサで受信する指示と、インターネット経由で受信した複数の要求のサブセットについて、関心のあるフィールドタイプのフィールド値を第１のデータプロセッサによってキャッシュに格納する指示が含まれる。第１の複数の指示には、このサブセットの総数に関連するカウンタを第１のデータプロセッサによってインクリメントさせる指示、キャッシュを作成する期間を第１のデータプロセッサによって決定する指示、および、作成されたキャッシュを第１のデータプロセッサによってサーバーに転送する指示も含まれる。

サーバーには、第２のデータプロセッサを制御してレポートを作成するための第２の複数の指示を格納する第２のコンピュータ可読媒体が含まれる。この第２の複数の指示には、関心のある複数のフィールドタイプのフィールド値に関連するカウンタを第２のデータプロセッサによってインクリメントさせる指示、このカウンタに基づいて上記フィールド値を第２のデータプロセッサによってソートする指示、および、第２のデータプロセッサによってレポートをレポートシステムに転送する指示が含まれる。

本発明により、従来の技術ではなし得なかった多くの利点が実現される。たとえば、本発明の各実施形態は、上位Ｎ件の関心のあるフィールドタイプについてのロギングとレポート処理の方法とシステムをサービスプロバイダに提供する。本発明によって収集されたデータを必要とするユーザーとしては、サービスがどのように使用されているかを知る必要がある業務意思決定者、攻撃パターンについてシステムをモニターするシステムオペレータ、サービスをモニターし、その使用パターンに基づいてサービスの改善を行うシステム実装者などが挙げられる。最も頻繁に出現するフィールド値のレポート処理は、ネットワークトラフィックを平均化するために、フロントエンドプロセッサ全体にわたってほぼリアルタイムに実行される。

本発明の各実施形態が提供する利点の１つは、本システムは汎用的な性質を持っているため、任意またはすべてのネットワークサービスで本システムを使用できるということである。暗号化されたデータを受信するネットワークサービスについても、本発明によってトラフィックパターンをモニターすることができる。このような場合、外部サービスによるモニター機能には、データを復号するための復号メカニズムが組み込まれていないという欠点がある。本発明のこれらの実施形態および他の実施形態については、その多くの利点と機能とともに、これ以降の記述と添付の図面に基づいてさらに詳しく説明する。

インターネット経由で受信した要求の概略図である。本発明の特定の実施形態による、関心のあるフィールドタイプをリストした表である。本発明の実施形態による、システム構成を示す概略図である。本発明の実施形態による、キャッシュの概略図である。本発明の実施形態による、クエリー要約機能の構成を示す概略図である。本発明の実施形態による、インターネット要求のロギング方法を示す概略的な流れ図である。本発明の実施形態による、インターネットクエリーのレポート処理方法を示す概略的な流れ図である。本発明の実施形態による、サービス用に地理的に分散した各サイトを示す概略図である。ログに記録されたインターネット要求を要約するキャッシュとレポートを示している。

フロントエンドプロセッサが受信したインターネット要求に関連する情報のトラッキングとレポートを行うために、トランザクションまたはクエリー（ＤＮＳクエリーなど）を、データベースまたはログファイル（ディスク上に格納されるテキストファイルなど）に記録することができる。次に、受信した要求に関するデータを収集するための他のプログラムやスクリプトを使用して、これらのログファイルの後処理を実行することができる。サービスプロバイダにとって関心のあるデータには、最も頻繁に照会されるＩＰアドレスや最も頻繁に実行されるクエリーなどが含まれる。

本発明者らは、上で述べた後処理システムは、システムのユーザーが必要とする処理速度も柔軟性も備えていないと判断した。ネットワークサービスを提供する典型的なシステムでは、数秒間に数十万件のクエリーを受信する可能性がある。従って、ディスク上のデータベースまたはログファイルに数十万件のクエリーを記録するには多くのリソース（特にディスクスペース）が必要になり、モニター中のシステムのパフォーマンス全体が直接的に影響を受ける。これは、データベースまたはディスクに対する履歴をコミットするのに必要な時間とリソースにより、次のトランザクションまたは要求を処理する前に、システムが一時的に停止することが多いためである。また、サービスプロバイダは、短い間隔で定期的に（たとえば、４秒間隔など）レポート処理を行うことを希望する。データベースまたはログファイルの後処理を行うプログラムまたはスクリプトは、トランザクションや要求の速度に追いつくことができず、必要とされる間隔でレポート処理を実行できない場合がある。トランザクションまたは要求の履歴をログファイルに記録するシステムについても、外部からの侵入者や不満を持つ従業員がアクセスできるディスク上のデータにこうした履歴を書き込む場合に、機密情報が漏洩するという可能性がある。本発明の各実施形態は、インターネット要求に関連する情報について、ほぼリアルタイムでのレポート処理を可能にすることにより、これらの問題と他の問題に対する解決策を提供する。これについては、本明細書を通して、さらに詳しく説明する。

図１は、インターネット経由で受信した要求の概略図である。図１に示す要求１００には、１つ以上のフィールドが含まれる。例として、図１に示すように、この要求にはＮ個のフィールドが含まれる場合がある。メッセージ内のフィールドの具体的な数は、実際の要求によって異なる。これについては、これ以降でさらに詳しく説明する。一部の用途では、メッセージに含まれるフィールドは、ＩＰ，ＤＮＳ，ＯＣＳＰ，Ｗｈｏｉｓという４つの代表的なカテゴリにグループ化することができる。これらのフィールドのそれぞれは、フィールドタイプ、フィールド長、およびフィールド値という３つの要素によって特徴付けされる。当業者にとっては明白であるため、一部の要求では、フィールド長はフィールド内には指定されない。用途に応じて、これら３つの要素は、特定用途に適するよう異なる。

本発明の各実施形態は、最も頻繁に出現するネットワークサービスの特徴を計算するためのシステムと技術を提供する。本発明の各実施形態に従い、各ネットワーク要求は「要求」と記述し、要求の各要素（ドメイン名やユーザーエージェントなど）は「フィールド」と記述する。これ以降で説明するように、要求は複数のフロントエンドプロセッサ（処理エンジンとも呼ばれる）に送信される。すべてのプロセッサが同じタイプの要求を処理するが、ユーザーが要求したサービスのタイプによっては、異なるフィールド値を持つ要求も存在する。処理エンジン（ＰＥ）は要求を順に処理し、「関心のあるフィールド」を選び出す。「関心のあるフィールド」とは、関心のあるフィールドタイプに一致するフィールドタイプを持つフィールドのことである。処理エンジン（ＰＥ）、プロトコルエンジン、フロントエンドプロセッサ、フロントサイドプロセッサおよびフロントフェイスプロセッサという各用語は、ＰＥを表すための別の用語であるため、ＰＥという用語と同じ意味で使用する必要がある。各ＰＥは同じフィールドを選び出すが、要求内の各フィールドは異なるフィールド値を持つため、本明細書で説明する方法とシステムは、最も頻繁に出現するフィールド値を判断する。各処理エンジンは各要求を処理し、関心のあるフィールドタイプに関連するデータをキャッシュしてから、クエリーログデーモン（ｑｌｏｇｄ）、クエリーサマライザ、またはクエリーログサーバーと呼ばれる要約サーバーに短期キャッシュを送信する。ＰＥは、実際には、各フィールド名（ocspシリアルなど）に対して数値表記（フィールド７など）を使用する。これに対して、クエリーログデーモンは、「フィールド７」が「ocspシリアル」を意味することを理解するように構成される。

クエリーログデーモンは、複数のＰＥから受信した各キャッシュ（要求セットとも呼ばれる）を処理し、フィールド値の出現回数を内部的にカウントする。次にクエリーログデーモンは、各ＰＥから報告された上位の値を定期的にレポートする。この説明は要約的なものにすぎず、これらの各プロセスに関係する追加の説明は、これ以降に記述する。

以下の各表に、関心のあるフィールドタイプのリストを作成する際に使用できるフィールドの例を示す。表１から表３にリストされたフィールドタイプは、本発明を制限するものではなく、各種プロトコルにおけるさまざまなフィールドタイプの例として示しているにすぎない。他のフィールドタイプも、各種実装におけるフィールドタイプとして使用することができる。当業者は、多くのバリエーション、改修、代替手段を考え付くであろう。表１から表３に示すように、一部のフィールドタイプ（「ソースＩＰアドレス」など）が、いくつかのプロトコルまたはサービスで使用されている。ソースＩＰアドレスの例では、一部のプロトコルに対して、ヘッダー内でソース情報が提供される。これにより、正しいソースに応答を返すことができる。一部のサービスに共通するフィールドタイプの別の例としては、要求を処理するために必要な時間に関する情報を提供する時間フィールドタイプがある。他のフィールドタイプについては、特定のプロトコルに固有のものとなる。

表１から表３に示した各フィールドは、説明のために単純化したものであり、本発明の範囲を制限するものではないことを理解されたい。例として、「ocspシリアル」フィールドの実際の値は「www.example.com」ではなく、表に示した値に容易に変換可能な固有の識別子になる。また、上の各表に示したフィールドはこれですべてではなく、他の関心のあるフィールドも本発明の範囲内に含まれることを理解されたい。従って、追加のフィールドも、処理エンジンによって受信され、関心のあるフィールドタイプとして使用される要求の一部として受信することができる。これについては、本明細書においてさらに詳しく説明する。インターネット経由で受信した要求は、標準化団体が合意したプロトコルにおおむね準拠している。そのため、これらのプロトコルで定義されたフィールドに基づいてフィールドが抽出される。これらのフィールドは、そのフィールドタイプが関心のあるフィールドタイプに一致した場合にキャッシュされる。従って、キャッシュされたフィールドは、フィールドタイプ、フィールド長、およびフィールド値（タイプ、長さ、および値とも呼ばれる）を持つ。

図２は、本発明の特定の実施形態による、関心のあるフィールドタイプを示す表である。関心のあるフィールドタイプは、表１から表３に示すフィールドのリストから取得され、通常、システム実装者または他の適切な担当者によって定義される。図３に関してさらに詳しく説明するように、クエリーデータまたは応答データ（あるいはその両方）内の関心のあるフィールドタイプは、処理エンジン（ＰＥ）によって記録される。処理エンジンは、このキャッシュされたデータをクエリーサマライザに送信する。従って、クエリーサマライザに送信したいデータのタイプを定義することができる。図２に示す関心のあるフィールドタイプには、ソースＩＰアドレスが含まれる。このソースＩＰアドレスは、上で説明したように、一部のプロトコルについて共通のフィールドタイプとなる。図２に示す関心のあるフィールドタイプには、ＤＮＳクエリーに関連するフィールドも含まれる。さらに、図２に示す関心のあるフィールドタイプには、ＯＣＳＰクエリーに関連するフィールドも含まれる。本発明は、これら特定のカテゴリの関心のあるフィールドタイプに制限されるものではなく、他のプロトコルにも適用することができる。当業者は、多くのバリエーション、改修、代替手段を考え付くであろう。

本発明の実装例として、各ＤＮＳクエリーには、ドメイン名とリソースレコード（ＲＲ）タイプ（つまり、有効なＤＮＳＲＲタイプ）が含まれる。現在の有効なＤＮＳＲＲタイプのリストは、http://www.iana.org/assignments/dns-parametersで参照することができる。各種タイプのうち、いくつかの例を表４に示す。

図８は、本発明の実施形態に従い、インターネットトラフィックを処理するネットワークサービスプロバイダを示している。図８に示すように、本発明の一部の実施形態では、インターネットからの複数サイト展開サービストラフィックを利用している。地理的に分散したネットワークサービスプロバイダは、サービス全体を構成する複数の接続ポイントを使用して、インターネットからのトラフィックを処理する。説明の目的で、ネットワークサービスプロバイダからのサービスを受けるいくつかの都市を示している。ネットワークサービスプロバイダは、サービストラフィックをインターネットから受信し、特定の用途に応じたサービスが提供される。以下で説明する図３は、ネットワーク要求を処理するこうしたサイトの１つを示している。

図３は、本発明の実施形態によるシステム構成の概略図である。図３に示すように、処理エンジンＰＥ１（３１０ａ）、ＰＥ２（３１０ｂ）．．．ＰＥｎ（３１０ｎ）によって要求が受信される。図３では３つの処理エンジンしか示していないが、典型的な実装においては、特定の用途に応じて１つ以上の処理エンジンが使用される。本発明の特定の実施形態では、各処理エンジンにより、インターネット経由でＤＮＳサービスを提供するドメイン名解決システムの一部が構成される。通常、これらの処理エンジンは１つのサイト上で共存する。

処理エンジンが要求を受信すると、それぞれの処理エンジンが要求を処理し、データをキャッシュに書き込む（図では、キャッシュ１（３２０ａ）、キャッシュ２（３２０ｂ）、およびキャッシュｎ（３２０ｎ）で示している）。各キャッシュの内容は、これ以降でさらに詳しく説明する。事前に設定された時間が経過すると、あるいは、事前に設定されたキャッシュサイズに達すると、処理エンジン（ＰＥ）がキャッシュをクエリーサマライザ３３０に転送する。クエリーサマライザ３３０は、各ＰＥから転送されたキャッシュを処理し、特定のフィールド値の出現回数によってランク付けされた上位ｎ件の関心のあるフィールドタイプを判断する。事前に設定された間隔で、レポートがレポートシステム３４０（このシステムには、システムオペレータがアクセスできる）に提供される。これについては、これ以降でさらに詳しく説明する。

図８は、本発明の実施形態による、サービス用に地理的に分散した各サイトを示す概略図である。各サイトは、ＤＮＳクエリーやＷｈｏｉｓクエリーなどのネットワーク要求を処理する。ネットワーク要求を処理する各サイトは、ロサンゼルス、シカゴ、ロンドンなどのいくつかの都市で稼働しているものとして示している。図３において、処理エンジンＰＥ１からＰＥｎは、ネットワーク要求を処理するこれらのサイトの１つに配置することができる。そのため、図８では、図３に示す各サイトの概要を示している。

図４において、処理エンジンは、フィールド内の用途固有のデータを、フィールドタイプ、フィールド長、およびフィールド値という３つの要素（Ｔ／Ｌ／Ｖ）の形式でバッファまたはキャッシュに格納する。ＰＥからの各メッセージは、これら３つの要素を含む複数のフィールドを持っている場合がある。ＰＥは、キャッシュをクエリーサマライザに送信する前に、複数のメッセージからの情報をバッファまたはキャッシュに格納する。図４では、ＰＥ１から送信されたキャッシュを示している。第１の要求（要求１）は、処理エンジンが受信して処理する。一実施形態において、この要求には１つ以上のメッセージ（通常は１つ）が含まれ、これら１つ以上のメッセージのそれぞれには１つ以上のフィールドが含まれる。ＰＥ１は、これら１つ以上のメッセージを反復し、要求内の各フィールドタイプを、図２に例示するような関心のあるフィールドタイプと比較する。フィールドタイプが１つの関心のあるフィールドタイプに一致した場合、そのフィールドタイプの３つの要素（タイプ／長さ／値（つまり、Ｔ／Ｌ／Ｖ））がキャッシュ３０２ａに格納される。図に示す例では、フィールド１とフィールド２のフィールドタイプが、関心のあるフィールドタイプの１つと一致し、フィールド１とフィールド２がキャッシュに格納される。要求１の他のフィールドも、省略記号によって示している。従って、フィールド１とフィールド２のフィールドタイプ、フィールド長、およびフィールド値がキャッシュ３０２ａに格納される。フィールドタイプ／長さ／値に関する追加の説明は、本明細書において、さらに具体的にはこれ以降において記述する。

第２の要求（要求２）も、ＰＥ１が受信して処理する。第２の要求では、第１のフィールド（フィールド１）と第４のフィールド（フィールド４）のフィールドタイプが、関心のあるフィールドタイプの１つと一致してキャッシュに格納される。この例では、フィールド２とフィールド３のフィールドタイプは、関心のあるフィールドタイプではない。つまり、フィールド２とフィールド３の特定のフィールドタイプは、処理エンジンによって格納されたリスト内の関心のあるフィールドタイプのいずれとも一致しないということである。一部の実施形態では、標準に準拠する目的で、フィールド２はすべての要求について同じタイプを持つ。他の実施形態では、一部の要求がフィールド２を持たない場合があるため、フィールド２は存在しないことになり、キャッシュには格納されない。従って、要求２に含まれる１つ以上のメッセージ内のフィールドをＰＥ１が反復する際に、フィールド２とフィールド３はスキップされ、キャッシュ３０２ａには格納されない。ＰＥ１は、図４に示すように、要求Ｎに達するまで、引き続き追加の要求の受信と処理を行う。ＰＥは、複数の要求にわたって同じフィールドタイプをキャッシュすることを理解する必要がある。従って、図４の実施例においては、フィールド１とフィールド２が要求１に対してキャッシュに格納され、フィールド１とフィールド４がフィールド２に対してキャッシュに格納され、フィールド１とフィールド２が要求Ｎに対してキャッシュに格納される。これは、これらのフィールドが、関心のあるフィールドタイプと一致するフィールドタイプを持っているためである。他の実施形態では、キャッシュに格納されるフィールドは、各フィールド内の特定のフィールドタイプによって異なる。

フィールドタイプ、フィールド長、およびフィールド値の例を示すため、ＰＥは、４つの要求の受信後に、表５に示す情報を自分の要求キャッシュに格納することができる。上で説明したように、これらの要求に関連するデータは、フィールドタイプ:長さ:値という形式でキャッシュに格納される。この例では、４つの各要求の７つのフィールドが、関心のあるフィールドタイプに一致するフィールドタイプを持ち、キャッシュに格納される。表５に示す各要求は７つを超えるフィールドを持つことができるが、関心のあるフィールドタイプと一致するフィールドタイプを持つフィールドは７つだけであるため、これらの一致する７つのフィールドだけがキャッシュに格納される。

図６は、本発明の実施形態による、インターネット要求のロギング方法を示す概略的な流れ図である。６１０では、関心のある複数のフィールドタイプが、通常、システムオペレータによって定義される。６１２では、複数のフィールドを含む要求をインターネット経由で受信する。典型的な要求については、図１に示している。６１４では、要求内の第１のフィールドのフィールドタイプが、複数の関心のあるフィールドタイプの１つに一致するかどうかを判断する。６１６では、この一致の判断に対する応答として、第１のフィールドの少なくとも一部をキャッシュに格納する。例として、関心のあるフィールドタイプの１つがソースＩＰアドレスで、ソースＩＰアドレスのフィールドタイプがフィールド内に含まれている場合、通常はフィールドタイプ、長さ、値という形式で、このフィールドに関連するデータがキャッシュに格納される。一部の実施形態では、フィールド長のキャッシュはオプションである。

６１８では、要求内の第２のフィールドのフィールドタイプが、関心のある複数のフィールドタイプの１つに一致するかどうかを判断する。６２０では、この一致の判断に対する応答として、第２のフィールドの少なくとも一部をキャッシュに格納する。６２２では、キャッシュをサーバーに転送する。６２４では、サーバー側でキャッシュの処理とソートを行い、関心のある複数のフィールドタイプの値の出現回数を判断する。たとえば、上に示したソースＩＰアドレスの例の場合、最も頻繁に出現するソースＩＰアドレスの値を、ランク順にソートしてリストすることができる。６２６では、通常はシステムオペレータに対して、出現回数のレポートを提供する。

図６に示す具体的な手順は、本発明の実施形態により、インターネット要求に対するロギングとレポート処理の特定の方法を提供するものであることを理解されたい。代替の実施形態に従い、他の順序で手順を実行することもできる。たとえば、本発明の代替の実施形態では、上で説明した手順を異なる順序で実行することができる。また、図６に示す個々の手順には、これらの手順に応じたさまざまな順序で実行可能なサブ手順を含めることができる。さらに、特定の用途に応じて、手順を追加したり削除したりすることもできる。当業者は、多くのバリエーション、改修、代替手段を考え付くであろう。

図７は、本発明の実施形態による、インターネットクエリーのレポート方法を示す概略的な流れ図である。７１０では、関心のある複数のフィールドタイプが、通常はシステムオペレータによって定義される。７１２では、第１の処理エンジンが複数の要求を受信する。この処理エンジン（ＰＥ）は、要求の処理を行い、さらに、要求内のフィールドに含まれるフィールドタイプが、定義されている関心のあるフィールドタイプと一致するかどうかを判断する。７１４では、フィールドタイプと関心のあるフィールドタイプとの間の一致に基づき、第１のフィールドと第２のフィールドを第１のキャッシュに格納する。キャッシュの例は、図４に示している。７１６では、第２のＰＥも、複数の要求を受信する。第１のＰＥでの操作と同様に、これら複数の要求が処理され、関心のあるフィールドタイプと一致するフィールドタイプを持つフィールドがキャッシュに格納される。従って、７１８では、第３のフィールドと第４のフィールドが第２のキャッシュに格納される。

７２０では、通常、事前に設定されたキャッシュサイズに達した場合、または制限時間が経過した場合に、第１のキャッシュと第２のキャッシュがサーバーに転送される。７２２では、最も大きな出現回数を持つフィールド値をサーバーが判断する。通常、最も頻繁に出現するフィールド値を判断するプロセスは、それよりも大きなプロセスである、最も頻繁に出現するフィールド値の上位Ｎ件のリスト（上位１０件のリストなど）を判断するプロセスの一部となる。７２４では、フィールド値と、そのフィールド値の出現回数を含むレポートを提供する。例として、ＤＮＳクエリー内のドメイン名が関心のあるフィールドタイプである場合、最も多く照会されたドメイン名のフィールド値（www.verisign.comなど）が、他のフィールド値とともに降順でレポート内にリストされる。

図７に示す具体的な手順は、本発明の実施形態に従い、インターネット要求について最も頻繁に出現するフィールド値をレポートする特定の方法を提供するものであることを理解されたい。代替の実施形態に従い、他の順序で手順を実行することもできる。たとえば、本発明の代替の実施形態では、上で説明した手順を異なる順序で実行することができる。また、図７に示す個々の手順には、これらの手順に応じたさまざまな順序で実行可能なサブ手順を含めることができる。さらに、特定の用途に応じて、手順を追加したり削除したりすることもできる。当業者は、多くのバリエーション、改修、代替手段を考え付くであろう。

一実施形態において、クライアントとサーバー間の通信プロトコルはステートレスで不安定である。この実施形態の場合、一部のクエリーログパケット（つまり、インターネット要求）が失われる可能性があることが考えられる。クエリーロギングは、単一スレッドモデルをサポートする。処理エンジンは、ルックアップエンジンからの応答を受信するたびに、クエリーロギングＡＰＩを使用してクエリーデータと応答データを自分のバッファまたはキャッシュに格納し、事前に設定された時間が経過した場合（たとえば１秒ごと）、またはキャッシュ（キャッシュ３０２ａなど）がいっぱいになった場合に、キャッシュされたデータをクエリーサマライザに送信する。通信に使用される特定のプロトコルは、本発明の実施形態を制限するものではなく、本発明の１つの実装を説明するために使用されているにすぎない。キャッシュまたはバッファに格納されたデータは、ＵＤＰ経由でクエリーサマライザ３３０に送信される。

特定の実施形態において、QueryLogPacketは、サーバーに送信されるパケットの有線形式を定義するクラスである。このクラスは、複数のフィールドを持つメッセージをバッファに追加するためのインターフェースと、有線パケットからのメッセージを読み込むためのインターフェースも定義する。QueryLogPacketクラスは、メッセージとフィールドの概念を持つ。メッセージは、新しいメッセージ境界の開始を定義し、それに対してフィールドは、フィールドタイプ、フィールド長（フィールドサイズとも呼ばれる）、およびフィールド値という３つの要素の形式でメッセージの属性を定義する。メッセージは、これらのフィールドを１つ以上持つことができる。QueryLogPacketには、ヘッダーとペイロードが含まれる。

クエリーログパケットがＵＤＰパケットである実装においては、パケットサイズは６５、４９３バイト（ＵＤＰヘッダーサイズを含めた場合は６５，５３５バイト）に制限される。クエリーログパケットのヘッダーは、事前に定義されたバイト数（１０バイトなど）になる。典型的なヘッダーを表６に示す。

パケットがＵＤＰパケットである場合、クエリーログパケットのペイロードが６５、４８３バイトを超えることはない。一実施形態において、パケットに追加される各メッセージは、表７に示す形式を持つ。

「メッセージタイプ」および「フィールドカウント」は、新しいメッセージの開始と前のメッセージの終わりを示す。ペイロードは、メッセージがキャッシュに追加される前に、後続の各フィールドで始まる。上で説明したように、これらのフィールドは、フィールドタイプ、フィールド長、フィールドデータ（値）という３つの要素の形式で定義される。

一部の実装において、処理エンジンはソースを定義することができる。この場合、ソースフィールドをパケットに追加することができる。また、struct timeval型のパケットタイムスタンプを追加して、パケットが初期化されたときのタイムスタンプを提供することもできる。

すべてのメッセージ内のフィールドは「MSGTIMESTAMP」（フィールドタイプ６）で始まる。このフィールドの値には、パケットタイムスタンプとメッセージタイムスタンプとの差異が設定される。このフィールドは、以下で説明するQueryLogWriterクラスのnewMessage()メソッドの呼び出し時に設定される。

QueryLogWriterオブジェクトが初期化されると、複数のフィールドを持つメッセージがこのオブジェクトに取り込まれる。メッセージの各フィールドは、解析後の１つのクエリーまたは応答などのように単純なものにすることも、実際の着信メッセージまたは送信応答を含めることもできる。特定の実施形態では、フロントエンドの要求または応答全体をパッケージ化するのではなく、要求と応答の重要な部分（つまり、関心のあるフィールド）だけを選び出す。各メッセージには、用途に応じて定義されたタイプのタグも付けられる。このタグ付けは、クエリーサマライザにおいて複数のタイプのメッセージを許可するためのものである。これらのタイプの例としては、以下のものがある。
■ 着信クエリー
■ 送信応答（要求と応答を分離するのではなく、要求と応答を１つのメッセージに格納することもできる。）
■ ログ内の注記（例：チェックポイントメッセージ）
■ 切り捨てられたメッセージの注記

本発明者らは、一部のメッセージタイプは大きく異なる共通フィールドを持つ可能性があり、メッセージタイプを区別するための用途的な理由が潜在的に多数存在するものと判断した。一実施形態において、メッセージとメッセージ内のフィールドを追加するためのプログラミングインターフェースは以下のようになる。

class QueryLogWriter {
public:

//いずれかのメッセージがfalseを返した場合、現在のメッセージはバッファから
//消去される。
//その場合、newMessage()の呼び出しが成功するまで、addField()の呼び出しはすべて
//失敗する。

//新しいメッセージの準備。直前のメッセージはコミットされている。
//送信メッセージバッファがいっぱいで新しいメッセージを追加できない場合、
//falseを返す。
bool newMessage(uint8_t type);

//現在のメッセージに新しいフィールドを追加する。新しいメッセージはすでに
//開始されている。
//送信メッセージバッファがいっぱいで処理を続行できない場合、falseを返す。
bool addField(unsigned short type, unsigned short length, const void * value);

//現在のメッセージの終わりを通知する。
void commitMessage();

//通常、ＰＥからこのメソッドを呼び出すことはない。
//ＰＥが停止した場合、ＰＥはこのメソッドを使用してバッファをフラッシュ
//することができる。
void send();
};

newMessageメソッドとaddFieldメソッドは、キャッシュ（つまり、バッファ）フルイベントからユーザーを保護しようとする。キャッシュ（つまり、バッファ）がいっぱいになると、これらのメソッドはバッファをクエリーサマライザに送信し、直前のメッセージをバッファの最初に再度キューに格納する。この処理が正常に完了すると、これらのメソッドは、キューの内容をバッファに追加しようとする。newMessageメソッドは、バッファの送信タイミングの確認、バッファの送信、およびタイマーのリセットも行う。

このインターフェースは、各イベント（フロントエンド要求など）でのnewMessage()の呼び出しで使用され、メッセージとともに記録される重要な各側面でのさまざまなaddField()呼び出しで使用されることを目的としている。フィールドはメッセージ内で反復することができ、呼び出し側にとって都合のいい方法で書式設定することができる。ただし、書式設定はクエリーサマライザに保存される。これにより、ログパケットを読み込むための適切な変換が実行される。たとえば、４バイトの整数としてフィールドが追加された場合、書き込み（htonl()など）と再読み込み（ntohI()など）の実行中に、適切なプラットフォーム変換が実行される。

再度図３を参照すると、クエリーサマライザ３３０（ｑｌｏｇｄとも呼ばれる）はネットワーク上で稼働するネットワーク要素であり、それぞれの解決サイトにおいてサーバー（つまりＰＥ）をモニターする。このクエリーサマライザは、構成可能なインターフェースとポート上で稼働するデーモンプロセスであり、クエリーなどのログ可能なイベントを含むＵＤＰパケットをＰＥからリッスンする。各ＵＤＰパケットは、１つ以上のログ可能イベントを含むことができる。上で説明したように、ＰＥは受信した各要求を反復し、図４に示した情報の３つの要素（フィールドタイプ、フィールド長、およびフィールド値）をキャッシュする。クエリーサマライザは、これら３つの要素の出現回数をトラッキングし、関心のあるフィールドタイプの構成済みリストに対する上位ｎ件リストを、構成可能な間隔でレポートする。トラッキング対象のフィールドタイプは構成経由のパラメータセットであるため、システムオペレータは、最も多く照会されたドメイン名など、上位のフィールドタイプのレポートを受信することができる。関心のあるフィールドタイプ（クエリー名）に対する上位の値（実際のドメイン名）の例として、最も多く照会された上位２０件のドメイン名のリストを挙げることができる。

ＵＤＰソケットからパケットを読み込むと、クエリーサマライザはQueryLogReaderクラスを使用してこのパケットを解析し、人間が読むことができる形式にデータを変換する。QueryLogReaderクラスは、受信したパケットの反復と検証を行うためのＡＰＩを提供する。メッセージが標準のクエリーログパケットの形式になっていない場合、読み込み機能によってパケット形式例外がスローされる。QueryLogReaderクラスは、このメッセージ内のそれぞれのメッセージとフィールドを読み込むためのＡＰＩを提供する。

class QueryLogReader {
public:
QueryLogReader(const void* buffer);

//読み込むメッセージがパケット内にさらに存在する場合、この呼び出しはtrueを返す。
bool getNextMessage() const;

//現在のメッセージのメッセージタイプを取得する。
//この呼び出しを行う前に、’getNextMessage()’の呼び出しでtrueを返す必要がある。
unsigned short getMessageType() const;

//現在のメッセージ内のフィールド数を取得する。
//この呼び出しを行う前に、’getNextMessage()’の呼び出しでtrueを返す必要がある。
unsigned short getFieldCount() const;

//現在のメッセージのソースを取得する。この場合のソースとは、メッセージを
//クエリーロガーに送信した処理エンジンの名前を指す。
const string getPacketSource() const;

//パケットが初期化された時刻を取得する。
const struct timeval & getPacketTime() const;

//パケット内のメッセージカウントを取得する。
unsigned short getMessageCount() const;

//パケット内のシーケンスを取得する。
unsigned int getPacketSequence() const;

//読み込むフィールドが現在のメッセージ内にさらに存在する場合、
//このメソッドはtrueを返す。
//この呼び出しを行う前に、’getNextMessage()’の呼び出しでtrueを返す必要がある。
bool getNextField(int & type, void *& data, unsigned & length);
};

たとえば、ＤＮＳ設定において、ＰＥは、受信した各クエリー（名前およびタイプ）と、このクエリーの応答コードを含むメッセージをキャッシュすることができる。クエリーサマライザは、３つの項目（名前、タイプ、および応答コード）すべてをトラッキングし、最も多く照会された上位２０の名前とタイプを１０秒ごとにレポートする。ｑｌｏｇｄは、起動時に自分自身の構成と初期化を実行する。サービスを提供する前に、ｑｌｏｇｄは１つのスレッドを生成し、そのスレッドに２つの稼働スレッドを付与する。第１のスレッドはサービススレッドで、ＰＥからパケットを読み込む。受信した各パケットについて、ｑｌｏｇｄはパケット内のメッセージを反復し、次に各メッセージ内のすべてのフィールドを反復する。通常はカウンタを使用して、３つの要素（フィールドタイプ、長さ、値）からの値の出現回数について、現時点での合計数が判断される。設定された秒数が経過すると、または設定されたサイズをキャッシュサイズが超えると、サービススレッドは、現在のキャッシュを新しい空のキャッシュに対してスワップアウトし、古いキャッシュに基づいてレポートを作成するという指示を、アイドル状態のレポートスレッドである第２のスレッドに対して条件変数経由で通知する。このレポートスレッドは、キャッシュを反復して、すべてのフィールドに対するベクトルを作成する。次に、これらのベクトルがソートされ、上位ｎ件の項目以外がすべて削除される（リスト内の項目が少ない場合は、リスト全体が削除される）。これらのリストからレポートメッセージが作成され、これにより、関心のある各フィールドタイプに対する上位ｎ件の値がレポートされる。停止指示が発行されるまで、この処理が繰り返される。本発明の各実施形態では、２つのスレッドを使用する必要はなく、他の構成も本発明の範囲内に含まれる。

図９は、各キャッシュと、ログに記録されたインターネット要求を要約したレポートを示している。図９に示すように、３つの異なる処理エンジン（ＰＥ１、ＰＥ２、およびＰＥｎ）のキャッシュには、さまざまなフィールドが含まれる。関心のあるフィールドタイプには、ソースロケーション、株式ティッカーシンボル、およびドル建ての入札価格に対する３つのフィールドが含まれる。ロケーション172.28.111.42のソースから、ＰＥ１が要求を受信する。ソースロケーションは関心のあるフィールドタイプであるため、このソースロケーションがキャッシュに格納される。同様に、ＰＥ１は、要求内の株式ティッカーシンボルVRSNをキャッシュし、102.00という特定の入札価格を持つ要求内のこの値をキャッシュに格納する。他の要求も、関心のあるフィールドタイプに一致するフィールドを持っているため、タイプ、長さ、値という形式で、これらのフィールドがキャッシュされる。同様のキャッシュが、ＰＥ２とＰＥｎによって作成される。

適切なレポート間隔で、キャッシュがクエリーサマライザに転送され、図に示すレポートがクエリーサマライザによって作成される。クエリーサマライザは、３つの関心のあるフィールドタイプ（タイプ１、タイプ２、タイプ２とタイプ３の組み合わせ）と一致するフィールドを持つフィールドについて、上位１０件のフィールド値をトラッキングする。クエリーサマライザは、各ＰＥからキャッシュを受信し、図に示すレポートを作成する。このレポートには、上位１０件のソースロケーション、上位１０件の株式ティッカーシンボル、および、上位１０件の株式ティッカーシンボルと入札価格の組み合わせが記載される。図５に示すように、最上位のソースロケーションは172.28.111.42、最上位の株式ティッカーシンボルはVRSN、最上位の株式ティッカーシンボルと入札価格の組み合わせはVRSN 102.00である。

クエリーサマライザは、さまざまな統計値をレポートする機能を備える。一実施形態では、表８に示す以下の統計値がレポートされる。

QueryLogCacheクラスは、クエリーサマライザのコンポーネントである。このクラスは、ＰＥから送信されたすべてのクエリー／イベントをトラッキングし、これらのクエリー／イベントがレポートされた頻度をトラッキングする。また、トラッキングしたそれぞれの関心のあるフィールドタイプに対する上位ｎ件のヒット数を返すためのコードも提供する。QueryLogCacheの例を以下に示す。

class QueryLogCache {
public:
struct QueryCacheKey {
unsigned short field_
unsigned char *value_;
unsigned short size_;
};

struct TopNList {
TopNList () {}
-TopNList () {}
unsigned short field_;
vector<QueryCacheKey> matches
};

QueryLogCache ();
-QueryLogCache ();
void add (unsigned short field, const unsigned char *value, unsigned short size);
void getTopN (unsigned maxNumMatches, DeleterForArrayOf<TopNList>&lists);
void dump (ostream &out) const;
void dump (unsigned short field, ostream &out) const;
private:
typedef map <uQueryCacheKey, unsigned> QueryCache_;
DoubleBuffer<QueryCache> cache_;
};

QueryLogCache::add()メソッドは、クエリーサマライザ内のサービススレッドによって呼び出されるメソッドである。ＰＥパケット内のメッセージから抽出されたフィールドタイプ、長さ、値はこのメソッドに渡され、クエリーキャッシュにコミットされる。このキャッシュの基本的な格納物はマップであり、フィールドタイプ（数字で表すことができる）、長さ、値を持つ構造体によってキーが解除される。この３つの要素によるキーがキャッシュマップ内で見つかると、このキーのカウントが更新される。見つからなかった場合は、新しいエントリーがキャッシュ内に追加される。レポートスレッドとサービススレッドがキャッシュ上で独立して稼働できるように、キャッシュ自体は二重バッファオブジェクト内に保存される。

QueryLogCache::dump()メソッドはデバッグ用としてのみ提供され、キャッシュ全体の内容または指定されたフィールドのキャッシュ内容のいずれかをダンプする。ダンプの結果は、用意されている出力ストリームに印刷される。

QueryLogCache::getTopN()メソッドは、システム管理者用のレポートを作成する時間になると、レポートスレッドによって呼び出される。呼び出し元は、Array<QueryLogCache::TopNList> オブジェクト内を通過する。このオブジェクトには、レポート対象の各フィールド用のQueryLogCache::TopNListオブジェクトが含まれている。呼び出し元は、トラッキング中のフィールドを使用して、各QueryLogCache::TopNListオブジェクトのfield_parameterを事前に設定する。ＰＥからｑｌｏｇｄに渡されたすべてのフィールドについてｑｌｏｇｄではレポートできない場合があるため、この処理が実行される。たとえば、ＤＮＳの名前、タイプ、および応答コードがトラッキングされていて、ＤＮＳ名のフィールド番号が１、タイプのフィールド番号が２、応答コードのフィールド番号が５である場合、呼び出し元は以下のメソッドを実行して、上位２０件の名前とタイプを取得する。

QueryLogCache::getTopN() call
Array<QueryLogCache::TopNList> lists;
lists.adopt(new QueryLogCache: :TopNList[fields_.size()]);
for (unsigned i = 0; i < fields .size(); i++) {
QueryLogCache: :TopNList &list = lists[i];
list.field_ = fields_[i] .number_i
}
cache_.getTopN(20, lists) i

当然ながら、リストの準備は初期化の際に行うことができる。このメソッドはキャッシュを反復し、キャッシュ内の各項目について、キャッシュのキーとカウントを追加する。ただし、イテレータの第２のメンバーと第１のメンバーについては、該当するフィールドのQueryLogCache::TopNListオブジェクト内での順序が逆になる。処理が終了すると、カウント値によってベクトルがソートされ、リスト内にｎ件を超える項目が存在する場合、最後のｎ件を除くすべての項目が削除される。その結果、実行されたArray<QueryLogCache::TopNList> オブジェクトには上位ｎ件リストが作成され、システムオペレータへのメッセージ内に組み込まれる準備ができる。

疑似コードでのQueryLogCache::getTopNの実装例を以下に示す。

void QueryLogCache: :getTopN (unsigned maxNumMatches, Array<QueryLogCache: :TopNList>
topLists) {
PRECONDITION(maxNumMatches > 0);
PRECONDITION(topLists.size() > 0);
//現在のキャッシュを取得し、新しい空のキャッシュを発行する。
QueryCache *current = cache_.getCurrentPtr();

for (map<QueryCacheKey, unsigned>::const_iterator it = current
>begin;
it ! = current->end (); it++) {
const QueryCacheKey &entry = it->first;
unsigned count = it->second;

//このキャッシュエントリに対する正しいTopNListを検索し、
//カウントとキーのペアとして追加する。

for (unsigned i = 0; i < topLists.size(); i++) {
TopNList &topList = lists[i];
if (topList.field_ == entry.field_) {
topList.matches_.push_back(make-pair(count, entry));
break;
}
}
}
for (unsigned i = 0; i < topLists.size(); i++) {
//カウントとキーのペアのカウント部分（最初の部分）により、
//リストをソートする。

TopNList &list = topLists[i];
sort (list.matches_.begin() , list.matches_.end());
//maxNumMatchesを超える数の項目がリスト内にある場合、
//最後のmaxNumMatches件を除いてすべて削除する。

if (list.matches .size() > maxNumMatches) {
list.matches_.erase(list.matches_.begin(),
list.matches .end() - maxNumMatches);
}
}
}

QueryLogServerクラスは、クエリーサマライザのもう１つのコンポーネントである。疑似コードでのQueryLogServerクラスの実装例を以下に示す。

class : public Server {
public:
QueryLogServer ();
-QueryLogServer ();

//レポータスレッド（上位ｎ件リストを作成して管理コンソールに
//送信するスレッド）を実行する。
void report ();
private:
string transformValue (QueryLogCache: : QueryCacheKey &entry);

QueryLogCache cache_;
ConditionLock condition_;
};

クエリーサマライザのプライマリサービススレッドは、各ＰＥから送信されたキャッシュを読み込む。疑似コードでのクエリーサマライザのプライマリサービススレッドの例を以下に示す。

start reporter thread

QueryLogCache newCache
while (!isShuttingDown()) {
read message from socket

for (each message in packet) {
if (time to report or cache size is too large) {
QueryLogCache *oldCache = 0;
cache_.writeUpdatePtr (newCache.orphan () &oldCache);
if (oldCache) {
delete oldCache;
}

newCache.adopt(new QueryLogCache);

ConditionLock clock (condition_);
clock.signal();
}

//各フィールドをキャッシュ内に追加する。

for (each field in message) {
newCache.add(field number, value, value length);
}

//動的フィールド（構成内に定義）を作成し、結果をキャッシュ内に追加する。

for (each constructed field)
string result;

for (each token in constructed field) {
result += token;
}
newCache.add(constructed field number, result.data(),
result.length()) i
}
}
}
shut down reporter thread

クエリーサマライザの値変換メソッドは、一致するフィールド値をシステムオペレータ用のレポートに組み込むために、このフィールド値をストリング形式に変換する。この変換がどのように行われるかは、フィールドの構成（具体的には、field_#型の構成パラメータ）によって異なる。型が指定されていない場合はバイナリ形式が使用され、フィールド値の１６進ダンプが実行される。表９に示す以下の変換がサポートされる。

クエリーサマライザのレポートメソッドは、すべての対象フィールドに対する上位ｎ件リストを取得し、リスト内の行データを適切な形式に変換し、このデータをシステム管理者または適切なコンソール／プログラムに送信する。疑似コードを以下に示す。

QueryLogServer Reporter Thread
while (!isShuttingDown()) {
ConditionLock clock (condition_);
clock. wait ();

if (!isShutting Down) {
for (each field to report) {
QueryLogCache: :TopList &list topLists[il;
list.field = ith field;
}

//フィールドごとに上位ｎ件のヒット数を取得する。これにより、
//新しいカウントの書き込みを開始するための新しい空のキャッシュが、
//プライマリサービススレッド用に発行される。

QueryLogCache *cache cache_.getCurrentPtr();
cache_.getTopN(numTopHits, topLists);

//レポートメッセージを作成する。
add preliminaries to report;

//実際の上位ｎ件リストを追加する。
for (each field to report) {
for (each match in field's top-n list) {
string textualValue = transformValue(entry);
add to report;
}
}
send to Report messaging server;
}
}

クエリーサマライザは、トラッキング対象として構成されたすべてのフィールドに対する上位ｎ件リストを管理コンソールにレポートする。レポートの送信間隔は、reporting_interval構成パラメータによって制御される。本発明の特定の実施形態に従い、各レポートが表１０のように構成される。

任意の名前や値などを使用したレポートの例を以下に示す。この例は実際のデータとは一切関係なく、例示目的で示しているにすぎない。また、見やすくするため、ＤＮＳタイプと応答コードは読み取り可能なニーモニックに変換している。

BEGIN 550 87176982
TO=host.dns.topqueries
FROM=host
TYPE=DATA
SEQ=1234
host=host
domain=(none)
start seconds=1190217552
start useconds=2
now seconds=1190217542
now useconds=12345
field17_0=www.example1.com. 1000
field17_1=www.example2.com. 999
field17_2=www.example3.com. 997
field17_3=www.example4.com. 74
field17_4=www.example5.com. 2
field18_0=A 2274
field18_1=NS 307
field18_2=MX 20
field18_3=SOA 6
field18_4=TXT 4
field19_0=NOERROR 2764
field19_1=NXDOMAIN 276
field19_2=REFUSED 30
field19_3=FORMERR 1
field19_4=NOTIMP 1

ＰＥとクエリーサマライザは、メモリーに接続されたプロセッサを含む。このメモリーには、本発明の実施形態に従い、本方法の少なくとも一部をプロセッサによって実行するための指示が格納される。このプロセッサは、指示とデータを実行するように構成された汎用マイクロプロセッサ（ＩｎｔｅｌＣｏｒｐｏｒａｔｉｏｎｏｆＳａｎｔａＣｌａｒａ, Ｃａｌｉｆが製造するＰｅｎｔｉｕｍ（登録商標）プロセッサなど）にすることができる。また、本発明による方法をソフトウェア、ファームウェア、及び/又はハードウェアで実行するための指示の少なくとも一部を実現する特定用途向け集積回路（ＡＳＩＣ）にすることもできる。例として、こうしたプロセッサには、専用の電気回路、ＡＳＩＣ、組み合わせロジック、他のプログラマブルプロセッサ、これらの組み合わせなどがある。メモリーは、デジタル情報を格納できる任意のデバイス（ＲＡＭ、フラッシュメモリー、ハードディスク、ＣＤなど）にすることができる。プロセッサは、関心のあるフィールドタイプ、キャッシュ、ソート済みフィールドのリスト、レポート、他の関連情報を格納できるデータベースに接続することができる。

本明細書で記述している例と実施形態は、単に説明目的として示しているに過ぎず、当業者にはさまざまな改修や変更が提示され、これらの改修や変更は本発明の精神と範囲内に含まれ、さらに添付の各請求項の範囲に含まれることが理解されよう。

Claims

関心のある複数のフィールドタイプを定義することと、
１つ以上のフィールドを持つ要求をインターネットから受信することと、
前記１つ以上のフィールドの第１のフィールドの第１のフィールドタイプが、前記関心のある複数のフィールドタイプの１つと一致するかどうかを判断することと、
前記第１のフィールドの少なくとも一部をキャッシュに格納することと、
前記１つ以上のフィールドの第２のフィールドの第２のフィールドタイプが、前記関心のある複数のフィールドタイプの１つと一致するかどうかを判断することと、
前記第２のフィールドの少なくとも一部を前記キャッシュに格納することと、
前記キャッシュをサーバーに転送することと、
前記第１のフィールドタイプと前記第２のフィールドタイプの少なくとも１つのフィールド値の出現回数をサーバー側で判断することと、
前記フィールド値の出現回数を含むレポートを提供することと、
を備える、インターネット要求のロギングを行う方法。
前記第１のフィールドタイプが、前記関心のある複数のフィールドタイプの１つと一致するかどうかを判断することは、解決サイトにおいて行われる、請求項１に記載の方法。
前記１つ以上のフィールドの第３のフィールドの第３のフィールドタイプが、前記関心のある複数のフィールドタイプの１つと一致しない場合、前記１つ以上のフィールドの前記第３のフィールドをキャッシュに格納しないことをさらに備える、請求項１に記載の方法。
複数の処理エンジンのそれぞれから送信されたキャッシュをサーバーで受信することをさらに備える、請求項１に記載の方法。
レポートをシステムオペレータに転送することをさらに備える、請求項１に記載の方法。
前記第１のフィールドの一部が、前記第１のフィールドのフィールドタイプ、フィールド長、およびフィールド値であり、前記第２のフィールドの一部が、前記第２のフィールドのフィールドタイプ、フィールド長、およびフィールド値である、請求項１に記載の方法。
前記１つ以上のフィールドのそれぞれが、少なくともフィールドタイプ、フィールド長、およびフィールド値によって特徴付けられる、請求項１に記載の方法。
前記関心のある複数のフィールドタイプを定義することが、インターネットからの要求の受信前に実行される、請求項１に記載の方法。
関心のある複数のフィールドタイプを定義することと、
それぞれが１つ以上の第１のフィールド群を持つ第１の複数の要求を、第１の処理エンジンがインターネットから受信することと、
前記１つ以上の第１のフィールド群の第１のフィールドを第１のキャッシュに格納することと、
前記１つ以上の第１のフィールド群の第２のフィールドを前記第１のキャッシュに格納することと、
それぞれが１つ以上の第２のフィールド群を持つ第２の複数の要求を、第２の処理エンジンがインターネットから受信することと、
前記１つ以上の第２のフィールド群の第３のフィールドを第２のキャッシュに格納することと、
前記１つ以上の第２のフィールド群の第４のフィールドを前記第２のキャッシュに格納することと、
前記第１のキャッシュをサーバーに転送することと、
前記第２のキャッシュをサーバーに転送することと、
他のフィールド値よりも高い出現回数によって特徴付けられる最上位フィールド値をサーバー側で判断することと、
前記最上位フィールド値とその出現回数を含むレポートを提供することと、
を備える、インターネット要求に対するレポート処理を行う方法。
前記レポートが、前記キャッシュに格納されたフィールド値の出現回数によってソートされたリストを備える、請求項９に記載の方法。
前記第１のフィールドをキャッシュに格納する前に、前記第１の処理エンジンにより、前記第１のフィールドのフィールドタイプが、関心のある複数のフィールドタイプの１つと一致するかどうかを判断することと、
前記第２のフィールドをキャッシュに格納する前に、前記第１の処理エンジンにより、前記第２のフィールドのフィールドタイプが、前記関心のある複数のフィールドタイプの１つと一致するかどうかを判断することと、
前記第３のフィールドをキャッシュに格納する前に、前記第２の処理エンジンにより、前記第３のフィールドのフィールドタイプが、前記関心のある複数のフィールドタイプの１つと一致するかどうかを判断することと、
前記第４のフィールドをキャッシュに格納する前に、前記第２の処理エンジンにより、前記第４のフィールドのフィールドタイプが、前記関心のある複数のフィールドタイプの１つと一致するかどうかを判断することと、
をさらに備える、請求項９に記載の方法。
前記第１の複数の要求および前記第２の複数の要求が、ＤＮＳ要求、ＩＰ要求、ＯＣＳＰ要求、またはＷｈｏｉｓ要求の少なくとも１つによって構成される、請求項９に記載の方法。
前記第１の複数の要求および前記第２の複数の要求が、ＶｏＩＰ要求またはＩＭ要求の少なくとも１つによって構成される、請求項９に記載の方法。
インターネットに接続され、それぞれが１つ以上のフィールドを持つ要求をインターネットから受信することができる複数の処理エンジンと、
前記複数の処理エンジンに接続されたサーバーと、
前記複数の処理エンジンのそれぞれが、キャッシュを作成する第１のデータプロセッサを制御するための第１の複数の指示を格納する第１のコンピュータ可読媒体を含むところの、前記サーバーに接続されたレポートシステムと、
を備え、
前記第１の複数の指示が、
前記第１のデータプロセッサにより、複数の要求をインターネット経由で受信する指示と、
前記第１のデータプロセッサにより、インターネット経由で受信した前記複数の要求のサブセットに対する関心のあるフィールドタイプのフィールド値をキャッシュに格納する指示と、
前記第１のデータプロセッサにより、前記サブセットの合計数に関連するカウンタをインクリメントさせる指示と、
前記第１のデータプロセッサにより、キャッシュを作成するための期間を決定する指示と、
前記第１のデータプロセッサにより、レポートを作成する第２のデータプロセッサを制御するための第２の複数の指示を格納する第２のコンピュータ可読媒体を含む前記サーバーに、前記キャッシュを送信する指示と、
を備え、
前記第２の複数の指示が、
前記第２のデータプロセッサにより、前記関心のある複数のフィールドタイプのフィールド値に関連するカウンタをインクリメントさせる指示と、
前記第２のデータプロセッサにより、前記カウンタに基づいて前記フィールド値をソートする指示と、
前記第２のデータプロセッサにより、前記レポートを前記レポートシステムに送信する指示と、
を備える、システム。
前記要求が、ＤＮＳ要求、ＩＰ要求、ＯＣＳＰ要求、またはＷｈｉｏｓ要求の少なくとも１つによって構成される、請求項１４に記載のシステム。
前記複数の処理エンジンが解決サイトに配置される、請求項１４に記載のシステム。
前記解決サイトがＤＮＳ解決システムのコンポーネントである、請求項１６に記載のシステム。
前記第１のフィールドのキャッシュ格納処理が、フィールドタイプ、フィールド長、およびフィールド値の格納によって構成される、請求項１４に記載のシステム。
時間間隔の経過に基づいて前記キャッシュが前記サーバーに転送される、請求項１４に記載のシステム。
キャッシュサイズが制限値に達したことに基づいて前記キャッシュが前記サーバーに転送される、請求項１４に記載のシステム。
前記サーバーがサービススレッドおよびレポートスレッドを備える、請求項１４に記載のシステム。