ホーム > 特許ランキング > ミュールソフト，エルエルシー
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-07-24
(45)【発行日】2023-08-01
(54)【発明の名称】アダプティブイベント集約
(51)【国際特許分類】
G06F 11/32 20060101AFI20230725BHJP
【ＦＩ】
G06F11/32 130
【請求項の数】
12
【外国語出願】
(21)【出願番号】P 2018202569
(22)【出願日】2018-10-29
(65)【公開番号】P2019083012
(43)【公開日】2019-05-30
【審査請求日】2021-10-05
(31)【優先権主張番号】62/579045
(32)【優先日】2017-10-30
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】15/874714
(32)【優先日】2018-01-18
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】518383046
【氏名又は名称】ミュールソフト，エルエルシー
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100091214
【弁理士】
【氏名又は名称】大貫 進介
(72)【発明者】
【氏名】ジャン ウー
(72)【発明者】
【氏名】アディティア ヴァイラヤ
(72)【発明者】
【氏名】レオ ウォン
(72)【発明者】
【氏名】パウロ グスタヴォ ヴェイガ
【審査官】小林 義晴
(56)【参考文献】
【文献】特開２０１２－２２１５０２（ＪＰ，Ａ）
【文献】特開平０８－２５５２５３（ＪＰ，Ａ）
【文献】米国特許第０７６４４４３８（ＵＳ，Ｂ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｆ １１／３２
(57)【特許請求の範囲】
【請求項1】
プロセッサと、前記プロセッサと結合されたメモリと、
を備えるシステムであって、
前記メモリは、前記プロセッサに命令を提供するように構成され、前記命令は実行されたときに、
複数のエージェントを用いてアプリケーションネットワークを監視するステップと、
データ集を学習バッファにサンプリングし、前記学習バッファが満杯であるイベントにおいて学習を用いて、集約次元について保持値を識別し、インライン集約を用いて、追加イベントをオーバーフローバッファに記憶し、前記学習バッファ及び前記オーバーフローバッファから集約結果を抽出することによってアダプティブイベント集約を実行して、前記集約次元の保持値を決定するステップと、
前記集約次元に基づいて、前記アプリケーションネットワークの報告を生成するステップと、
を前記プロセッサに実行させ、
前記報告は、前記アプリケーションネットワークの視覚化と、イベント監視報告と、ネットワークトポロジ報告とのうち少なくとも１つを含む、システム。
【請求項2】
前記複数のエージェントは、エージェントがメモリ、プロセッサ及び／又はネットワーク容量に関してリソース豊富であることを示す複数の軽量エージェントを含む、請求項１に記載のシステム。
【請求項3】
アダプティブイベント集約を実行することは、前記複数のエージェントを用いて前記アプリケーションネットワークを監視することに関連付けられるイベントを集約することに少なくとも部分的に基づいて、前記集約次元の保持値を決定することを含む、請求項１に記載のシステム。
【請求項4】
アダプティブイベント集約を実行することは、インライン学習とイベントデータの収集とを実行することを含む、請求項１に記載のシステム。
【請求項5】
前記プロセッサは集約プロセッサを含み、前記アダプティブイベント集約は前記集約プロセッサによって実行される、請求項１に記載のシステム。
【請求項6】
前記集約次元は、可逆次元、非可逆次元及び折り畳み次元のうち少なくとも１つとして構成可能である、請求項１に記載のシステム。
【請求項7】
前記保持値を識別することは、集約と未使用のうち少なくとも１つとしてメトリックを構成することを含む、請求項１に記載のシステム。
【請求項8】
前記集約プロセッサは、保持値の可逆メトリックを含む追加イベントの線形計算を実行するようにさらに構成されている、請求項５に記載のシステム。
【請求項9】
前記メモリは更に、前記プロセッサに、実行されたときに、前記アプリケーションネットワークのトポロジの図形視覚化を生成するステップ、
を前記プロセッサに実行させる命令を提供するように構成される、請求項１に記載のシステム。
【請求項10】
前記図形視覚化は、監視データの名称と値のペアと、ＡＰＩ呼出しのソース及び宛先と、イベントデータと、ＡＰＩ呼出し開始タイムスタンプと、ＩＰアドレスのネットワークタプルと、ポートのネットワークタプルと、プロトコルのネットワークタプルと、応答コードと、前記アプリケーションネットワークのエンティティ間の呼出しの数と、次元のサイズと、ＡＰＩ呼出しデータのサイズとのうち少なくとも１つの図形キューを含む、請求項９に記載のシステム。
【請求項11】
複数のエージェントを用いて、アプリケーションネットワークを監視するステップと、アダプティブイベント集約を実行して、集約次元の保持値を決定するステップと、
前記集約次元に基づいて、前記アプリケーションネットワークの報告を生成するステップと、
を含み、
前記報告は、前記アプリケーションネットワークの視覚化と、イベント監視報告と、ネットワークトポロジ報告とのうち少なくとも１つを含み、
アダプティブイベント集約を実行することは、
データ集を学習バッファにサンプリングすることと、
前記学習バッファが満杯であるイベントにおいて学習を用いて、前記集約次元について保持値を識別することと、
インライン集約を用いて、追加イベントをオーバーフローバッファに記憶することと、
前記学習バッファ及び前記オーバーフローバッファから集約結果を抽出することと、を含む、方法。
【請求項12】
非一時的コンピュータ可読記憶媒体において具体化されているプログラムであって、複数のエージェントを用いてアプリケーションネットワークを監視するためのコンピュータ命令と、
アダプティブイベント集約を実行して、集約次元の保持値を決定するためのコンピュータ命令と、
前記集約次元に基づいて、前記アプリケーションネットワークの報告を生成するためのコンピュータ命令と、
を含み、
前記報告は、前記アプリケーションネットワークの視覚化と、イベント監視報告と、ネットワークトポロジ報告とのうち少なくとも１つを含み、
アダプティブイベント集約を実行することは更に、
データ集を学習バッファにサンプリングするコンピュータ命令と、
前記学習バッファが満杯であるイベントにおいて学習を用いて、前記集約次元について保持値を識別するコンピュータ命令と、
インライン集約を用いて、追加イベントをオーバーフローバッファに記憶するコンピュータ命令と、
前記学習バッファ及び前記オーバーフローバッファから集約結果を抽出するコンピュータ命令と、を含む、プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
他の出願との相互参照
本願は、２０１７年１０月３０日に出願された米国仮特許出願第６２／５７９，０４５号「アダプティブイベント集約」に対する優先権を主張し、これは全ての目的で参照により本明細書に組み込まれる。
本願は、２０１７年１０月３０日に出願された米国仮特許出願第６２／５７９，０４５号「アダプティブイベント集約」に対する優先権を主張し、これは全ての目的で参照により本明細書に組み込まれる。
【背景技術】
【0002】
アプリケーションネットワークは、複数のクライアントコンピュータと結合された少なくとも１つのサーバコンピュータを含み、少なくとも１つのＡＰＩ（Application Programming Interface）を介して通信をおこなうことがある。アプリケーションネットワークの普及により、クライアントとサーバとの間の呼出しを表すＡＰＩ呼出しが何万も生じることがある。ＡＰＩ呼出しの数は、監視、トラブルシューティング及び／又は分析の目的で圧倒的なものになることがある。
【図面の簡単な説明】
【0003】
本発明の様々な実施形態が、以下の詳細な説明及び添付図面に開示される。
【0004】
【図1】一部の実施形態に係る、アダプティブイベント集約のためのプログラムされたコンピュータ／サーバシステムを示す機能図である。
【図2A】アプリケーションネットワーク視覚化の図である。
【図2B】アプリケーションネットワークのサンプル形状を示す図である。
【図3】エージェント及びトポロジサーバを示す図である。
【図4】アダプティブイベント集約のシーケンス図を示す図である。
【図5】アダプティブイベント集約のプロセスの実施形態を示すフローチャートである。
【図6】集約処理のプロセスの実施形態を示すフローチャートである。
【発明を実施するための形態】
【0005】
本発明は多くの方法で実施することができ、例えば、プロセス、装置、システム、組成物、コンピュータ可読記憶媒体上で具体化されるコンピュータプログラム製品、及び／又はプロセッサ（プロセッサに結合されたメモリに記憶され、且つ／又はメモリによって提供される命令を実行するように構成されるプロセッサ等）として実施することができる。本明細書では、これらの実施形態、或いは本発明がとり得る任意の他の形態は、技術と呼ばれることがある。一般に、開示されるプロセスのステップの順序は、本発明の範囲内で変更されてよい。別段の記載がない限り、タスクを実行するように構成されるとして記載されるプロセッサやメモリ等のコンポーネントは、所定の時間にタスクを実行するように一時的に構成される一般のコンポーネント、又は、タスクを実行するように製造された特定のコンポーネントとして実現されてよい。本明細書で用いられる場合、「プロセッサ」という用語は、コンピュータプログラム命令のようなデータを処理するように構成される１つ以上のデバイス、回路及び／又は処理コアを指す。
【0006】
本発明の原理を説明する添付図面と共に、本発明の１つ以上の実施形態の詳細な説明を以下に提供する。本発明はそのような実施形態に関連して記載されるが、本発明はいかなる実施形態にも限定されない。本発明の範囲は特許請求の範囲によってのみ限定され、本発明は、数多くの代替、変更及び均等物を包含する。本発明の完全な理解を提供するために、以下の説明には多くの具体的な詳細が記載される。このような詳細は例示を目的として提供されるものであり、本発明は、このような具体的な詳細の一部又は全部を伴わずに、特許請求の範囲に従って実施することができる。本発明が不必要に不明瞭にならないように、明確にするために、本発明に関連する技術分野において知られている技術的項目は、詳細には記載されない。
【0007】
アダプティブイベント集約が開示される。一実施形態において、軽量エージェントは、関連メトリックをキャプチャするためにホスト上で少ないメモリ／プロセッサリソースを用いるだけでよいネットワーク／ＡＰＩ通信を監視する。データが流れる前に先験的知識を有することを必要としない（例えば、キャプチャされるべきメトリックが、ＡＰＩ呼出しが比較的少ないサーバとサーバとの間であるのか、或いは、キャプチャされるメトリックが、莫大な数のＡＰＩ呼出しを伴うサーバとクライアントとの間であるのか）。いずれの場合も、関連メトリックは、統計的サンプリングを必要とせずに、完全な可逆イベント報告でキャプチャされる。異なるコンピューティング環境に対するインラインのリアルタイム学習により、どの次元がそのような可逆報告に関連するのか、そして交互に、莫大な数のＡＰＩ呼出しのイベントにおいて、どの次元が非可逆且つ／又は集約／折り畳みで有り得るのかが決定される。
【0008】
対照的に、従来は、膨大な数のＡＰＩ呼出しが存在するか否かの先験的知識を用いることなく、サンプリングは、イベントの監視、トラブルシューティング及び／又は分析に用いられる。別の従来のアプローチは、オフライン及び／又は後処理について全てのＡＰＩ呼出しをキャプチャすることであり、大規模では計算／メモリ／時間／ネットワーク／経済のリソースの点で高価になることがある。
【0009】
ランタイム・アプリケーション・ネットワーク・ビジュアライザが開示される。ビジュアライザは、ソフトウェアアプリケーション間のアプリケーション間ＡＰＩ通信を表示する。ランタイム・アプリケーション・ネットワーク視覚化では、各アプリケーションインスタンスは図形ノードとして表すことができる。あるアプリケーションインスタンスから別のアプリケーションインスタンスへのキャプチャされたＡＰＩ呼出しイベントから、ソースと宛先の固有の組合わせの情報を導出することにより、図形エッジを生成することができる。ＡＰＩ呼出しイベントの数は、１分ごとのアプリケーションインスタンスごとに、１桁から数万まで変動し得る。アプリケーションインスタンスごとに多くのＡＰＩ呼出しイベントを用いてエッジを導出することにより、多くの計算リソースを浪費してしまうおそれがある。
【0010】
エッジ生成に用いられるコンピューティングリソース量を削減するために、ＡＰＩ呼出しイベントを集約するシステムが開示される。システムは、重要な情報をアダプティブに学習し保存する。一実施形態において、軽量エージェントは、ネットワーク／ＡＰＩ通信を監視し、且つ／又はイベントを監視する。このような軽量エージェントは、メモリ、プロセッサ及び／又はネットワーク容量に関してリソース豊富である。このようなエージェントは、従来の統計的サンプリングとは対照的に、可逆イベント報告で関連メトリックをキャプチャする。このようなエージェントは、異なるコンピューティング環境に対してインラインのリアルタイム学習をおこなって、どの次元がそのような可逆報告に関連するのかと、どの次元が非可逆且つ／又は集約／折り畳みであり得るかとを決定する。
【0011】
図１は、一部の実施形態に係る、アダプティブイベント集約のためのプログラムされたコンピュータ／サーバシステムを示す機能図である。図示されているように、図１は、一部の実施形態に係る、アダプティブイベント集約を提供するようにプログラムされた汎用コンピュータシステムの機能図を提供する。当然ながら、アダプティブイベント集約には、他のコンピュータシステムのアーキテクチャ及び構成を用いることができる。
【0012】
コンピュータシステム１００（以下に説明する種々のサブシステムを含む）は、プロセッサ又は中央処理装置（ＣＰＵ）１０２とも呼ばれる、少なくとも１つのマイクロプロセッササブシステムを含む。例えば、プロセッサ１０２は、シングルチッププロセッサによって、又は複数のコア及び／又はプロセッサによって実現することができる。一部の実施形態では、プロセッサ１０２は、コンピュータシステム１００の動作を制御する汎用デジタルプロセッサである。プロセッサ１０２は、メモリ１１０から取得された命令を用いて、入力データの受信及び操作と、ディスプレイやグラフィックス・プロセッシング・ユニット（ＧＰＵ）１１８等の出力装置でのデータの出力及び表示とを制御する。
【0013】
プロセッサ１０２はメモリ１１０と双方向に結合され、メモリ１１０は、第１の１次記憶装置（典型的にはランダムアクセスメモリ（ＲＡＭ））及び第２の１次記憶領域（典型的には読出し専用メモリ（ＲＯＭ））を含むことができる。当分野で周知であるように、１次記憶装置は、一般の記憶領域として、且つスクラッチパッドとして用いることができ、また、入力データ及び処理済みデータを記憶するために用いることができる。また、１次記憶装置は、プロセッサ１０２上で動作するプロセスのための他のデータ及び命令に加えて、データオブジェクト及びテキストオブジェクトの形で、プログラミング命令及びデータを記憶することができる。また、当該技術分野で周知であるように、１次記憶装置は、典型的には、プロセッサ１０２がその機能を実行するために用いる基本操作命令、プログラムコード、データ及びオブジェクト、例えばプログラムされた命令を含む。例えば、１次記憶装置１１０は、例えばデータアクセスが双方向であるか単方向であるかに応じて、任意の適切なコンピュータ可読記憶媒体（以下に説明する）を含むことができる。例えば、プロセッサ１０２は、頻繁に必要とされるデータを直接的且つ非常に迅速に検索し、キャッシュメモリ（図示なし）に記憶することもできる。また、プロセッサ１０２は、プロセッサ及び／又はメモリ１１０を補助する補足的な処理コンポーネントとして、コプロセッサ（図示なし）を含むことができる。
【0014】
取り外し可能な大容量記憶装置１１２は、コンピュータシステム１００に追加の記憶容量を提供し、双方向（読取り／書込み）又は一方向（読取り専用）のいずれかでプロセッサ１０２に結合される。例えば、記憶装置１１２は、フラッシュメモリ、ポータブル大容量記憶装置、ホログラフィック記憶装置、磁気装置、磁気光学装置、光学装置、その他の記憶装置などの、コンピュータ可読媒体を含むこともできる。固定の大容量記憶装置１２０は、例えば、追加のデータ記憶容量を提供することもできる。大容量記憶装置１２０の一例は、ｅＭＭＣ又はmicroSDデバイスである。一実施形態において、大容量記憶装置１２０は、バス１１４によって接続されたソリッドステートドライブである。大容量記憶装置１１２，１２０は、一般に、典型的にはプロセッサ１０２によって使用されていない追加のプログラミング命令、データなどを記憶する。当然のことながら、大容量記憶装置１１２，１２０内に保持されている情報は、必要に応じて、仮想メモリとして１次記憶装置１１０の一部（例えばＲＡＭ）として標準的に組み込むことができる。
【0015】
バス１１４は、プロセッサ１０２に記憶サブシステムへのアクセスを提供することに加えて、他のサブシステム及びデバイスへのアクセスを提供することもできる。図示のように、これらは、ディスプレイモニタ１１８、通信インタフェース１１６、タッチ（又は物理）キーボード１０４及び１つ以上の補助入出力装置１０６を含むことができる。補助入出力装置１０６は、オーディオインタフェース、サウンドカード、マイクロフォン、オーディオポート、録音装置、オーディオカード、スピーカ、タッチ（又はポインティング）デバイス、及び／又は必要に応じて他のサブシステムを含む。補助装置１０６は、タッチスクリーン及び／又は容量性タッチインタフェースに加えて、マウス、スタイラス、トラックボール、或いはタブレットであってよく、グラフィカル・ユーザ・インタフェースとインタラクトするのに有用である。
【0016】
通信インタフェース１１６は、図示のように、ネットワーク接続を用いて、プロセッサ１０２を別のコンピュータ、コンピュータネットワーク、又はテレコミュニケーションネットワークに結合することを可能にする。例えば、通信インタフェース１１６を介して、プロセッサ１０２は、方法／プロセスステップを実行する過程で、データオブジェクトやプログラム命令等の情報を別のネットワークから受信したり、別のネットワークに情報を出力したりすることができる。情報（しばしばプロセッサ上で実行される一連の命令として表される）は、別のネットワークから受信することができ、別のネットワークに出力することができる。コンピュータシステム１００を外部ネットワークに接続し、標準プロトコルに従ってデータを伝えるために、インタフェースカード又は同様の装置と、プロセッサ１０２によって実装される（例えば遂行／実行される）適切なソフトウェアとを用いることができる。例えば、本明細書に開示される様々なプロセス実施形態は、プロセッサ１０２上で実行することができ、或いは、処理の一部を共有するリモートプロセッサと共に、インターネット、イントラネットネットワーク、ローカル・エリア・ネットワーク等のネットワークを介して実行することができる。本明細書を通して、「ネットワーク」はコンピュータコンポーネント間の任意の相互接続を指し、例として、インターネット、Bluetooth（登録商標）、ＷｉＦｉ、３Ｇ、４Ｇ、４ＧＬＴＥ、ＧＳＭ（登録商標）、イーサネット（登録商標）、イントラネット、ローカル・エリア・ネットワーク（“ＬＡＮ”）、ホーム・エリア・ネットワーク（“ＨＡＮ”）、直列接続、並列接続、ワイド・エリア・ネットワーク（“ＷＡＮ”）、Fibre Channel、PCI/PCI-X、ＡＧＰ、VLbus、PCI Express、ExpressCard、Infiniband、ACCESS.bus、無線ＬＡＮ、HomePNA、光ファイバ、G.hn、赤外線ネットワーク、衛星ネットワーク、マイクロ波ネットワーク、セルラネットワーク、仮想プライベートネットワーク（“ＶＰＮ”）、ユニバーサル・シリアル・バス（“ＵＳＢ”）、FireWire、シリアルＡＴＡ、1-Wire、UNI/O、或いはホモジニアスシステム、ヘテロジニアスシステム及び／又はシステム群を共に接続する任意の形態が挙げられる。追加の大容量記憶装置（図示なし）が、通信インタフェース１１６を介してプロセッサ１０２に接続することもできる。
【0017】
補助Ｉ／Ｏデバイスインタフェース（図示なし）をコンピュータシステム１００と共に使用することができる。補助Ｉ／Ｏデバイスインタフェースは、汎用インタフェース及びカスタマイズインタフェースを含むことができ、プロセッサ１０２がデータを送信し、より典型的には他のデバイス（マイクロフォン、タッチセンサ式ディスプレイ、トランスデューサカードリーダ、テープリーダ、音声又は手書き文字認識装置、生体認証リーダ、カメラ、ポータブル大容量記憶装置デバイス、その他のコンピュータ等）からデータを受信できるようにする。
【0018】
また、本明細書で開示される様々な実施形態は、更に、様々なコンピュータ実施の動作を実行するためのプログラムコードを含むコンピュータ可読媒体を備えた、コンピュータ記憶製品に関する。コンピュータ可読媒体は、後にコンピュータシステムによって読み取られることのできるデータを記憶することができる任意のデータ記憶装置である。コンピュータ可読媒体の例として、限定ではないが、上述した全ての媒体と、ＮＡＮＤフラッシュ、ｅＭＭＣ、ＳＤ、コンパクトフラッシュ（登録商標）等のフラッシュメディアと、ハードディスク、フロッピー（登録商標）ディスク、磁気テープ等の磁気媒体と、ＣＤ－ＲＯＭディスク等の光媒体と、光ディスク等の光磁気媒体と、特定用途向け集積回路（ＡＳＩＣ）、プログラマブルロジックデバイス（ＰＬＤ）、ＲＯＭ及びＲＡＭデバイス等の特別に構成されたハードウェアデバイスと、が挙げられる。プログラムコードの例としては、生産時のマシンコード（例えばコンパイラにより）、或いはより高いレベルのコードを含むファイル、例えば、インタプリタを使って実行できるスクリプトの両方が挙げられる。
【0019】
図１に示されるコンピュータ／サーバシステムは、本明細書に開示される様々な実施形態と共に用いるのに適したコンピュータシステムの一例に過ぎない。そのような使用に適した他のコンピュータシステムは、より多い又はより少ない数のサブシステムを含むことができる。また、バス１１４は、サブシステムをリンクするのに役立つ任意の相互接続方式の例示である。異なるシステム構成のサブシステムを有する他のコンピュータアーキテクチャも利用することができる。
【0020】
図２Ａは、アプリケーションネットワーク視覚化の図である。本明細書に記載されるランタイム・アプリケーション・ネットワークは、コンピュータネットワークを介してＡＰＩを通じて互いに通信する一連のソフトウェア・アプリケーション・インスタンスである。アプリケーションインスタンスは、ＩＯＴ（internet of things）センサ、ソフトウェアサービス、データベースサーバ、デスクトップ・クライアント・ブラウザ、又はモバイルアプリケーションの組込みソフトウェアインスタンスなど、任意の実行ソフトウェアプログラムであってよい。
【0021】
一実施形態において、図２Ａに示されるように、通信は、監視、トラブルシューティング及び分析の目的のために、アプリケーションインスタンスの間でそれらのＡＰＩを介して視覚化される。この視覚化は、有向図形の形をとってよい。ランタイム・アプリケーション・ネットワークを視覚化するために、各アプリケーションインスタンスは、図２Ａに示される“Mule”（202）、“Twitter”（204）、“Workday”（206）等と表示された１１個のノードのような、図形ノードとして表すことができる。図２Ａでは、同じアプリケーションのインスタンスを示すために、ノードの名称は同じであってよい。
【0022】
図形エッジは、アプリケーションインスタンス間のＡＰＩ呼出しイベントを分析することによって導出されてよい。エッジの方向は、呼び出す側のアプリケーションインスタンスから別のアプリケーションインスタンスへのＡＰＩ呼出しの方向を示すことができる（例えば、図２Ａにおいて“Mule”から“Twitter”へ向けられた図形エッジ（２０８））。ノードごとに観察されるＡＰＩイベントの数は、かなり変動する可能性がある。サーバからサーバになると、何万ものＡＰＩイベントがごくわずかのエッジを生成する可能性がある。一方、クライアントからサーバへの呼出しの場合、数万のＡＰＩ呼出しが何千ものエッジを生成することがある。
【0023】
図２Ｂは、アプリケーションネットワークのサンプル形状を示す。図２Ｂに示されるように、「サービスＧ」（２５２）は、何万ものクライアントがサーバ（２５４ａ…２５４ｚ）に対するＡＰＩ呼出しをおこなうのを見ることができる。同時に、且つ同じトポロジにおいて、「サービスＦ」（２５６）と「サービスＡ」（２５８）の間など、非常に頻繁に通信する少数のサーバが存在することがある。この場合、サーバのＡＰＩ呼出しのあらゆるペアが慎重にトラッキングされることがある。
【0024】
（２５２）と（２５４ａ…２５４ｚ）の間のような膨大な数のＡＰＩ呼出しイベントをトラッキングするには、計算コストが高くなることがある。図形エッジを生成するために用いられるデータの量を低減し制限するために、ＡＰＩ呼出しイベントをインラインで集約する技術が開示される。
【0025】
図３は、エージェント及びトポロジサーバを示す。ランタイム・アプリケーション・ネットワークは、アプリケーションインスタンスから形成されてよい。一実施形態において、各アプリケーションインスタンスの中には、図３において丸文字“ａ”として示される（３０２ａ…３０２ｅ）ように、軽量のネットワーク・ビジュアライザ・エージェントがインストールされ動作する（例えば「サービスＣ」のエージェント（３０２ｂ））。エージェントは、アプリケーションインスタンスに入ってくるＡＰＩ呼出しと、アプリケーションインスタンスから出ていくＡＰＩ呼出しとを収集することができる。一般に、全てのアプリケーションインスタンスによってエージェントがインストールされるわけではないので、エージェントは、アプリケーションインスタンスの一部でのみ動作することができる。
【0026】
エージェントは互いに独立して動作してよい。あるエージェントは、アプリケーションの他の場所で動作する他のエージェントが存在するか否かを事前に知らなくてよい。アプリケーションネットワーク全体の完全な画像を生成するために、各エージェントによって集められた通信情報はネットワークトポロジサーバ（３０４）に送信されてよい。トポロジサーバは、各インスタンスからの情報を組み合わせて、ランタイム・アプリケーション・ネットワークの全体図を形成する。
【0027】
一実施形態において、エージェントは、ネットワーク内の様々なサービスノード（エージェント（３０２ａ…３０２ｅ）など）について情報を集めてよいが、データベースノード（３０６ａ，３０６ｂ）又はクライアントブラウザノード（３０８ａ…３０８ｚ）について情報を集めなくてよい。集められた情報は、トポロジサーバ（３０４）に送信される。
【0028】
ランタイム環境では、観測されたＡＰＩ呼出し情報は時間と共に変化するので、エージェント（３０２ａ…３０２ｅ）は、データをトポロジサーバ（３０４）に連続的に送信することがある。例えば、エージェントが収集された通信情報を１分ごとにトポロジサーバ（３０４）に送信する場合、１分目に、それぞれ１つのＡＰＩ呼出しを「サーバＧ」におこなう５つの異なるクライアント（３０８ａ…３０８ｚ）が存在することがある。次の１分には、多くのＡＰＩ呼出しを「サーバＧ」におこなう唯一のクライアント（３０８ａ）が存在することがある。その結果、エージェントによりトポロジサーバ（３０４）に送信されるＡＰＩ呼出しイベントデータは、イベント内容の固有性だけでなく数も非常に変化しやすい。
【0029】
時系列イベントを用いてエッジを導出することが開示される。ランタイム・アプリケーション・ネットワーク図形のエッジは、あるアプリケーションインスタンスから別のアプリケーションインスタンスへのＡＰＩインタラクションを表す。エッジは、ＡＰＩ呼出しを開始したアプリケーションインスタンスについての情報と、ＡＰＩ呼出しを受信するアプリケーションインスタンスについての情報と、ＡＰＩ呼出しの応答情報（開始時間、呼出し継続時間、応答コード、応答サイズ等）とを含むことができる。エッジは、単一のＡＰＩ呼出しを表すこともできるし、同じソース、宛先、メソッド、応答コード等の同じ特性の複数のＡＰＩ呼出しを表すこともできる。
【0030】
以下の表に、ＡＰＩ呼出しデータのサンプルキャプチャを示す。
【表1】
【0031】
２０１８年３月２日、12:32:42.003において、呼出しがＩＰアドレス：port 10.0.23.123:8374からＩＰアドレス：port 10.2.34.212:80へ向かい、サイズが２３１４バイトであり継続時間が３４ｍｓであるコード200(OK)の応答（この場合ＨＴＴＰ応答）を伴う。ランタイムにおけるＡＰＩ呼出しは、「開始時間」と「継続時間」を用いて上記に表されているような、時間間隔の間だけ発生するので、各ＡＰＩ呼出しは時系列イベントとして表すことができる。時系列イベントとして、ＡＰＩ呼出しに含まれる様々な情報は、タイムスタンプ、コンテキスト次元及びイベントデータのうち少なくとも１つにグループ化することができる。
【0032】
ＡＰＩ呼出しは、この表に与えられるように、時系列イベントとして表すことができる。
【表2】
【0033】
この時系列イベントテーブルでは、
・タイムスタンプ：ＡＰＩ呼出し開始タイムスタンプである。
・コンテキストデータ：ＡＰＩ呼出しのソースと宛先の情報を記述する、一連のラベルと値のペアである。これらのデータ点は非加法的である。
・イベントデータ：一連のラベルと値のペアである。イベントデータには２つのタイプ、加法的メトリックデータと非加法的データが存在する。
・タイムスタンプ：ＡＰＩ呼出し開始タイムスタンプである。
・コンテキストデータ：ＡＰＩ呼出しのソースと宛先の情報を記述する、一連のラベルと値のペアである。これらのデータ点は非加法的である。
・イベントデータ：一連のラベルと値のペアである。イベントデータには２つのタイプ、加法的メトリックデータと非加法的データが存在する。
【0034】
加法的メトリックデータはラベル値であり、該値は、合計を形成するために多くのイベントからまとめられ得るという特徴をもつ数値的尺度である。そのような合計を用いて、平均などの統計的尺度を導出することができる。非加法的データはラベル値であり、該値は、値又はセンスをイベントの合計に追加しないカテゴリ、序数、自由形式のテキスト、又は数字であってよい。
【0035】
時系列イベントの内容は以下を含む。
・イベントタイムスタンプ：イベントタイムスタンプ。
・次元：非加法的コンテキストデータ及び非加法的イベントデータについての２つ以上の次元値。
・メトリック（オプション）：イベントデータに関する０以上の加法的メトリック値。
・イベントタイムスタンプ：イベントタイムスタンプ。
・次元：非加法的コンテキストデータ及び非加法的イベントデータについての２つ以上の次元値。
・メトリック（オプション）：イベントデータに関する０以上の加法的メトリック値。
【0036】
上記の構造を用いると、ＡＰＩ呼出しは構造化オブジェクトを用いて表すことができる。
【数1】
【0037】
時系列イベントの集約が開示される。必要な記憶と処理の量を削減するために、時系列イベントを集約する従来の手法よりも改善されている。時系列イベントを集約するには、どのイベントが「類似している」かを決定する必要がある。イベントの類似性は、本明細書では、イベントの次元の全部又は一部について同じ次元値を有するイベントとして定義される。上記の例を用いると、ユーザは、２つのイベントの“source.ip”が同じであるときに、それらのイベントが類似していると述べることができる。或いは、２つのイベントの“source.ip”、“destination.ip”及び“client-id”が同じであるときに、それらのイベントが類似しているとしてもよい。或いは、全ての次元が同じ値をもつとき、２つのイベントが類似しているとしてもよい。
【0038】
イベントの類似性がユーザによって定義された後、集約時間ウィンドウを指定して、時間ウィンドウ内の類似のイベントを単一の集約イベントに折り畳む（collapse）こともできる。例えば、集約の時間ウィンドウは１分、５分、１時間、１日等であってよい。
【0039】
複数のイベントが単一の集約イベントに折り畳まれたとき、様々なイベントからのメトリックが組み合わされて、集約メトリックが形成される。集約のために任意のメトリックを選択することができる。例えば、応答サイズ又は継続時間を複数のイベントにわたって組み合わせることができる。その結果、集約されたイベントは以下を含む。
・集約時間間隔：集約イベントの開始時間と継続時間。
・集約次元：非加法的コンテキストデータ及び非加法的イベントデータのイベント次元値の全部又は一部。
・集約メトリック：個別のイベントデータからの複合及び集約メトリック値。
・集約時間間隔：集約イベントの開始時間と継続時間。
・集約次元：非加法的コンテキストデータ及び非加法的イベントデータのイベント次元値の全部又は一部。
・集約メトリック：個別のイベントデータからの複合及び集約メトリック値。
【0040】
定義された集約次元はイベント次元の一部であってよいので、集約次元の一部ではないイベント次元は折り畳み次元と呼ばれる。折り畳まれる次元の例は応答コードである。集約されたイベントは、折り畳まれた次元についての情報を含まない。
【0041】
時系列イベント集約の結果は、時間間隔と集約次元値の固有の組合わせの各々について、１つの集約イベントを生成する。集約されたイベントの数は、元のイベントの数よりも少なくてよい。
【0042】
図形エッジに集約イベントを用いることが開示される。ランタイム・アプリケーション・ネットワークでは、時系列イベントは、２つのアプリケーション間の単一のＡＰＩ呼出しを表すことができる。これらのＡＰＩ呼出しは、ネットワークにおけるアプリケーション間のインタラクションを表す図形エッジを導出するために用いられてよい。各エッジは、ＡＰＩ呼出しのソースと宛先の固有の組合わせを表すことができる。同じソースから同じ宛先への繰返しのコールにより、同じエッジが図形に生成される。
【0043】
以下の表では、アプリケーションインスタンス間のＡＰＩ呼出しイベントの例示的セットが示される。
【表3】
【0044】
上記の５つのイベントを用いると、10.0.23.123，10.0.4.211及び10.2.34.212に位置する３つの別個のアプリケーションインスタンスを伴うアプリケーションネットワークを導出することができる。ノード10.0.23123は10.2.34.212と通信している。ノード10.0.4.211は10.2.34.212と通信しているが、ノード10.0.23.123は10.0.4.211と通信していない。
【0045】
生のイベントを用いてエッジを導出する代わりに、集約されたイベントを用いて図形エッジを生成することができる。最初に、１分の時間ウィンドウを用いて、Source IPとDestination IPの集約次元で、５つのイベントを集約することができる。次に、集約プロセスは以下を生じる。
【表4】
【0046】
上に示されたように、５つのイベントは３つの集約イベントに縮小される。３つの集約イベントから、同じアプリケーションネットワーク視覚化を導き出すことができる。この例は、システムが最初に生のイベントを集約して集約イベントにする場合、アプリケーションネットワークの導出に用いられるメモリと計算が低減され得ることを示す。これは特に、例えば図３の「サービスＡ」と「サービスＦ」との間のような、サーバ間通信に効果的であり得る。
【0047】
ここで、高い濃度（cardinality）の次元について説明する。時系列イベント集約では、集約された次元は多くの固有値を含み得る。次元ごとの固有値の数は、次元の濃度である。次元の濃度が高いとき、その次元の固有値の数が高くなり得る。結果として、集約次元の濃度によって、集約時のデータ削減の度合いが決まる。
【0048】
例えば、生のイベントが以下の表で表される場合、
ソースＩＰと宛先ＩＰに基づく集約では、集約された結果は以下の表で表される。
【表5】
【表6】
【0049】
上記の例は、ソースＩＰ次元内の高い濃度の例であり、これは、集約のために削減がおこなわれないほぼ最悪のシナリオを表す。これは、クライアントとサーバとの通信で発生することがあり、大規模なＡＰＩ呼出しが従来の監視、トラブルシューティング及び／又は分析を圧倒し得る例でもある。
【0050】
高い濃度の次元の取扱いが開示される。ランタイム・アプリケーション・ネットワークにおける高濃度の次元は、“source IP”、“API URI”、“client ID”等、ＡＰＩイベントのいくつかのイベント次元で発生する可能性がある。
【0051】
例えば、アプリケーションネットワークは、デスクトップ又はモバイルのクライアント（３０８ａ…３０８ｚ）からの要求を受け取るアプリケーションサーバ（３０２ｅに関連付けられた図３の「サービスＧ」）を含むことがある。アプリケーションサーバの観点からは、多数の個別のクライアントＩＰアドレスが存在する。これにより、クライアント‐サーバ間アプリケーションでは多くのエッジが暗示される（おそらく１０，０００個ほどのエッジ）。
【0052】
しかしながら、アプリケーションサーバ（３０２ｄに関連付けられた「サービスＦ」）が他のアプリケーションサーバ（３０２ａに関連付けられた「サービスＡ」、３０２ｂに関連付けられた「サービスＣ」、３０２ｅに関連付けられた「サービスＧ」）によって使用されるように設計されている場合、アプリケーションサーバは、いくつかの別個のサーバＩＰアドレスしか見ることができない。これにより、サーバ‐サーバ間アプリケーションではエッジはほとんど暗示されないことがある（おそらく１０個ほどのエッジ）。
【0053】
その結果、ソースＩＰ等の同じ次元セットでは、次元は、クライアント‐サーバ型アプリケーションでは高濃度になり、サーバ‐サーバ型アプリケーションでは低濃度になり得る。
【0054】
ランタイムＡＰＩ呼出しイベントを通じてランタイム・アプリケーション・ネットワークを構築する上での１つの課題は、アプリケーションサーバの使用のタイプ、すなわちクライアントにサービス提供するか又は他のサーバにサービス提供するかに関して、先験的且つ／又は先行情報が存在しない可能性があることである。或いは、アプリケーションサーバの使用は、時間と共に変化する可能性がある。結果として、潜在的な高濃度次元を扱うための以下の一般的な戦略のように、イベント集約時に高濃度次元を自動的に扱うために、従来技術を用いるのは難しいおそれがある。
【表7】
【0055】
このような従来のアプローチよりも優れた新規な技術が開示される。この技術は、ここでは「アダプティブイベント集約」と呼ばれる。
１．リソース使用率が低い：集約を生成するために全ての生のイベントを保持することがない。
２．先験的な知識なしで、高い濃度の次元から値を自動的に選択して保持する。
３．保持されている値について正確なメトリックを生成する。
１．リソース使用率が低い：集約を生成するために全ての生のイベントを保持することがない。
２．先験的な知識なしで、高い濃度の次元から値を自動的に選択して保持する。
３．保持されている値について正確なメトリックを生成する。
【0056】
図４は、アダプティブイベント集約のシーケンス図を示す。一実施形態において、アダプティブイベント集約は、生のＡＰＩ呼出しイベントを集約システムに送信する。指定された時間が経過すると、呼出し側は集約システムをトリガして、全ての集約されたイベントをその時点で返すことができる。集約システムは、一連の集約プロセッサを利用する。本明細書に記載されるように、「集約プロセッサ」は、データ処理専用のソフトウェア及び／又はソフトウェア‐ハードウェア要素であり、例えばオブジェクト／バイナリコードであってよい。一実施形態において、集約プロセッサは各軽量エージェント（３０２ａ…３０２ｅ）の一部である。各集約プロセッサは、以下の内部ステージを経ることによって動作する。
１．ステージ１：データ収集のサンプリング。
２．ステージ２：学習。
３．ステージ３：インライン集約。
４．ステージ４：集約された結果を抽出し、ステージ１にリセットする。
１．ステージ１：データ収集のサンプリング。
２．ステージ２：学習。
３．ステージ３：インライン集約。
４．ステージ４：集約された結果を抽出し、ステージ１にリセットする。
【0057】
構成は、各集約プロセッサ（３０２ａ…３０２ｅ）において、且つ／又はトポロジサーバ（３０４）内で発生することがある。アダプティブ集約システムに対して、以下の構成可能なパラメータが与えられる。
１．可逆、非可逆及び折り畳みの集約次元。
２．集約されたメトリック及び未使用のメトリック。
３．学習バッファサイズ、学習アルゴリズム、保持値カウント。
４．出力サイズ。
１．可逆、非可逆及び折り畳みの集約次元。
２．集約されたメトリック及び未使用のメトリック。
３．学習バッファサイズ、学習アルゴリズム、保持値カウント。
４．出力サイズ。
【0058】
一実施形態において、構成可能なパラメータは集約の挙動を制御する。各イベント次元は、以下のタイプのうち１つとして構成されてよい。
１．可逆集約次元：集約時に固有の次元値が保存される、イベント次元の全部又は一部。
２．非可逆集約次元：集約時に固有の次元値が部分的に保存される、イベント次元の全部又は一部。システムは、限定／制限された量のメモリリソースと計算リソースを用いて、これらの次元値についてできるだけ多くの情報を保持することができる。又は、
３．折り畳み次元：集約時に次元値が保存されない、イベント次元の全部又は一部。
１．可逆集約次元：集約時に固有の次元値が保存される、イベント次元の全部又は一部。
２．非可逆集約次元：集約時に固有の次元値が部分的に保存される、イベント次元の全部又は一部。システムは、限定／制限された量のメモリリソースと計算リソースを用いて、これらの次元値についてできるだけ多くの情報を保持することができる。又は、
３．折り畳み次元：集約時に次元値が保存されない、イベント次元の全部又は一部。
【0059】
イベントメトリックは、以下のタイプのうち１つとして指定されてよい。
１．集約メトリック：集約され出力されるイベントメトリック。又は、
２．未使用メトリック：集約時に無視され、且つ出力には現れないことのあるイベントメトリック。
１．集約メトリック：集約され出力されるイベントメトリック。又は、
２．未使用メトリック：集約時に無視され、且つ出力には現れないことのあるイベントメトリック。
【0060】
また、システムのユーザは以下を指定することができる。
１．学習バッファサイズ：学習バッファ内の固有キーの数（以下のステージ１で詳述される）。
２．学習アルゴリズム：（アダプティブ）学習を実行するために用いるプラグイン／プラガブル（pluggable）アルゴリズム。
３．出力サイズ：入力イベントの数に関わらず、集約のために生成される出力の最大数を指定するサイズガイド。及び／又は、
４．保持値カウント：非可逆集約次元の各々について保持される重要値の数。
１．学習バッファサイズ：学習バッファ内の固有キーの数（以下のステージ１で詳述される）。
２．学習アルゴリズム：（アダプティブ）学習を実行するために用いるプラグイン／プラガブル（pluggable）アルゴリズム。
３．出力サイズ：入力イベントの数に関わらず、集約のために生成される出力の最大数を指定するサイズガイド。及び／又は、
４．保持値カウント：非可逆集約次元の各々について保持される重要値の数。
【0061】
データ・集約・システムを構成する際のサンプルコードの例として、以下が挙げられる。
【数2】
【0062】
可逆次元。ユーザが１つ以上の可逆次元を構成するとき、複数の独立したアダプティブ集約プロセッサ（３０２ａ…３０２ｅ）が用いられてよい。ユーザが可逆次元を指定しないとき、単一のアダプティブ集約プロセッサが用いられてよい。イベントが与えられると、システムは最初に、可逆次元からの値を用いてルックアップキーを作成してよい。このルックアップキーは、プロセッサマップ内に既存の集約プロセッサを配置するために用いられてよい。そのようなプロセッサが見つからない場合、新しい集約プロセッサが作成／インスタンス化され、ルックアップキーについてプロセッサマップに追加されてよい。その後、集約プロセッサにイベントが送信される。集約プロセッサ内の全てのイベントは、それらの可逆次元と同じ値をもつ。各集約プロセッサは独立して、非可逆次元に対して４ステージのアダプティブ集約をおこなう。
【0063】
例えば、以下の表には一連のＡＰＩイベントが表される。
【表8】
【0064】
可逆次元が“Destination IP”及び“Response Code”である場合、３つの独立した集約プロセッサが作成/インスタンス化され、以下の３つの表の各々によって表されるように、それぞれが同じ可逆次元値を用いてイベントを処理する。
集約プロセッサ１
集約プロセッサ２
集約プロセッサ３
集約プロセッサ１
【表9】
【表10】
【表11】
【0065】
ステージ１：データ集のサンプリング。図４に示されるように、各集約プロセッサは、最大４つの内部ステージを経由する。ステージ１（４０２）において、受信された各イベントは、メモリ内のキー値構造に記憶される。このキー値構造は、本明細書では「学習バッファ」と呼ばれる。各キーは集約次元値の固有の組合わせであり、関連値は、同じキーを有するイベントに関する集約メトリックのセットを保持する集約イベントである。上記の集約プロセッサ１における例では、ルックアップキーは“Destination IP＝10.2.34212，Response Code＝200-OK”である。学習バッファのサイズは、ユーザによって構成された学習バッファのサイズを超えることはできない。
【0066】
一実施形態において、ステージ１の前に、各イベントを受信する前に前処理ステージが用いられる。例えば、ある前処理ステージは、ＩＰアドレスを取得し、それをサブドメインにまとめることであってよい。例えば、24.1.23.237は24.1.23.0にまとめられ、24.1.23.123も24.1.23.0にまとめられる。
【0067】
新しいイベントが到着すると、次元値の固有の組合わせからのキーが既にキー値構造に存在する場合、その値は新しいイベントのメトリック値を含むように更新される。キーが存在しない場合、システムは次に、キー値の現在のサイズが学習バッファのサイズよりも小さいか否かをチェックする。そうである場合、新しいイベントについてキー値に新しいエントリが追加され
【0068】
キー値構造の現在のサイズが、学習バッファが満杯であるような学習バッファサイズにある場合、新しいイベントはキー値構造に挿入されない。代わりに、ステージ２がトリガされ、以下で詳細に説明するように、新しいイベントはステージ３で処理されてよい。
【0069】
例えば、Response Codeを可逆次元とする集約プロセスのために、学習バッファは、“Source IP”及び“Destination IP”が非可逆次元であるイベントを収集する。このプロセッサによって処理される全てのイベントは同じ可逆次元値をもつ可能性があるので、ソースＩＰ値と宛先ＩＰ値は異なることがある。しかし、ステージ１、学習ステージでは、ソースＩＰと宛先ＩＰの全ての固有の組合わせは、学習バッファが満杯になる前に、非可逆であるにも関わらず維持される。学習バッファにおける各集約イベントのタイムスタンプは、ソースＩＰと宛先ＩＰのその固有の組合わせを伴う全ての最初のイベントの到着時刻を示す。この例の学習バッファは、以下の表によって表される。
学習バッファの例
学習バッファの例
【表12】
【0070】
ステージ２：学習。上述のように、学習バッファが学習バッファサイズ限度にあり、固有キーの既存セットに収まらない新しいイベントが到着したときに、ステージ２（４０４）がトリガされる。ステージ２は、指定された学習アルゴリズムを用いて、学習バッファの集約イベントの分析をおこなう。従来のサンプリングからアダプティブアルゴリズムに至るまで、多くのアルゴリズムを供給することができる。このセクションでは、アダプティブアルゴリズムをより詳細に説明する。
【0071】
アダプティブ学習では、システムは、各非可逆次元について、最も重要な次元値を識別することを試みる。それらの次元値が識別されると、それらの値の周囲のメトリックがトラッキングされる。最も重要な次元値を識別するために、非可逆次元の各固有値について頻度カウントを生成する学習バッファにおいて、全ての集約イベントを通して、学習ステップが繰り返される。定義された非可逆次元が複数存在する場合、全ての非可逆次元について次元値カウントが生成される。
【0072】
ステージ１の学習バッファの例の表を用いると、ソースＩＰと宛先ＩＰの非可逆次元により、以下の値カウントは以下のヒストグラムを生成する。
ソースＩＰヒストグラム：
宛先ＩＰヒストグラム：
ソースＩＰヒストグラム：
【表13】
【表14】
【0073】
上に示されたように、各非可逆集約次元の値カウントは、その次元の頻度ヒストグラムである。このヒストグラムを用いて、システムは保持する値を選択する。選択された値は、本明細書では「保持値」と呼ばれる。システムは、複数の因子を用いて、固有値の総数と、イベントカウント頻度と、頻度の偏差と、ヒストグラムの形状とから、保持値を決定する。
【0074】
例えば、固有値の総数が保持値カウントよりも小さい場合、全ての値が保持値として追加されてよい。ヒストグラムが高頻度値と他の値との間の高い偏差を示す場合、高頻度値のみが保持される。ヒストグラムが多くの低頻度値を示す場合、おそらくいずれの値も保持されない。分析の結果は、０以上の選択された保持値であってよい。ただし、保持値の数は、ユーザによって指定された保持値カウント構成プロパティを超えることはできない。
【0075】
学習分析の後、プロセッサはステージ３に移行する。
【0076】
ステージ３：インライン集約。学習ステージの後、ステージ３（４０６）の開始時、集約プロセッサは以下のデータ点を有している。
１．容量に達している学習バッファ。
２．非可逆集約次元ごとの、ゼロ以上の保持値のセット。
１．容量に達している学習バッファ。
２．非可逆集約次元ごとの、ゼロ以上の保持値のセット。
【0077】
プロセッサは、本明細書において「オーバーフローバッファ」と呼ばれる２次バッファを作成する。オーバーフローバッファは、学習バッファと構造が類似する。オーバーフローバッファは、追加の集約イベントをそれらの集約メトリックと共に記憶するのに用いられる。
【0078】
この時点で、プロセッサは、到着するイベントの処理を再開する。ステージ３で処理する最初のイベントは、ステージ２をトリガしたイベントである。ステージ３で処理されるイベントごとに、以下が適用される。
１．イベントの非可逆次元からの値の組合わせを用いて、キーを作成する。
２．学習バッファにキーが存在するか否かをチェックする。見つかった場合、メトリックは既存の学習バッファに集約される。
３．キーが学習バッファに見つからない場合、非可逆次元ごとに、その非可逆次元の値が保持値の１つであるか否かをチェックする。値が保持値の１つである場合、値はそのまま維持される。値が保持値の１つでない場合、イベントの値は特別なトークン“<OTHER>”に更新される。
４．非可逆次元から上記のステップ３の更新値を用いて、オーバーフローキーを作成する。
５．オーバーフローキーを用いて、オーバーフローバッファにおいて対応する集約イベントを検索する。集約バッファにエントリが見つかった場合、イベントのメトリックは見つかったエントリに集約される。エントリが見つからない場合、オーバーフローキーのために新しい集約イベントエントリが作成され、イベントメトリックは新しい集約イベントに追加される。
１．イベントの非可逆次元からの値の組合わせを用いて、キーを作成する。
２．学習バッファにキーが存在するか否かをチェックする。見つかった場合、メトリックは既存の学習バッファに集約される。
３．キーが学習バッファに見つからない場合、非可逆次元ごとに、その非可逆次元の値が保持値の１つであるか否かをチェックする。値が保持値の１つである場合、値はそのまま維持される。値が保持値の１つでない場合、イベントの値は特別なトークン“<OTHER>”に更新される。
４．非可逆次元から上記のステップ３の更新値を用いて、オーバーフローキーを作成する。
５．オーバーフローキーを用いて、オーバーフローバッファにおいて対応する集約イベントを検索する。集約バッファにエントリが見つかった場合、イベントのメトリックは見つかったエントリに集約される。エントリが見つからない場合、オーバーフローキーのために新しい集約イベントエントリが作成され、イベントメトリックは新しい集約イベントに追加される。
【0079】
ステージ３（４０６）において、オーバーフローバッファのサイズは既知の上限を有する。オーバーフローバッファ内のエントリの最大数は、積
である。miは、各保持値の次元である。例えば、ステージ１（４０２）及びステージ２（４０４）について上記に示された学習バッファの例を用いて、プロセッサが、ソースＩＰと宛先ＩＰの次元の以下の値
及び
を保持することを選択する場合、オーバーフローバッファのエントリの最大数は３×２＝６である。
【数3】
【表15】
【表16】
【0080】
この例を続けると、以下の追加イベントがステージ３（４０６）で受信されたとする。
次に、
１．１番目のイベントでは、学習バッファにおいて（source＝10.0.23.123，destination＝10.2.34.212）が発見されるので、学習バッファメトリックは更新される。
２．２番目のイベントでは、元のソースＩＰと宛先ＩＰの組合わせが学習バッファに存在せず、ソースＩＰ値が保持値であるが宛先ＩＰはそうではないので、（source＝10.0.23.123，destination＝10.2.34.211）が、オーバーフローキーとして（source＝10.0.23.123，destination＝<OTHER>）を用いて、オーバーフローバッファに追加される。
３．３番目のイベントでは、元のソースＩＰと宛先ＩＰの組合わせが学習バッファに存在せず、ソースＩＰ値は保持値ではないが宛先ＩＰは保持値であるので、（source＝10.0.6.51，destination＝10.2.34.212）が、オーバーフローキーとして（source＝<OTHER>，destination＝10.2.34.212）を用いて、オーバーフローバッファに追加される。
４．４番目のイベントでは、ソースＩＰと宛先ＩＰのいずれも保持値ではないので、（source＝10.0.6.51，destination＝10.2.3413）が、（source＝<OTHER>，destination＝<OTHER>）オーバーフローキーを用いて、オーバーフローバッファに追加される。
【表17】
１．１番目のイベントでは、学習バッファにおいて（source＝10.0.23.123，destination＝10.2.34.212）が発見されるので、学習バッファメトリックは更新される。
２．２番目のイベントでは、元のソースＩＰと宛先ＩＰの組合わせが学習バッファに存在せず、ソースＩＰ値が保持値であるが宛先ＩＰはそうではないので、（source＝10.0.23.123，destination＝10.2.34.211）が、オーバーフローキーとして（source＝10.0.23.123，destination＝<OTHER>）を用いて、オーバーフローバッファに追加される。
３．３番目のイベントでは、元のソースＩＰと宛先ＩＰの組合わせが学習バッファに存在せず、ソースＩＰ値は保持値ではないが宛先ＩＰは保持値であるので、（source＝10.0.6.51，destination＝10.2.34.212）が、オーバーフローキーとして（source＝<OTHER>，destination＝10.2.34.212）を用いて、オーバーフローバッファに追加される。
４．４番目のイベントでは、ソースＩＰと宛先ＩＰのいずれも保持値ではないので、（source＝10.0.6.51，destination＝10.2.3413）が、（source＝<OTHER>，destination＝<OTHER>）オーバーフローキーを用いて、オーバーフローバッファに追加される。
【0081】
結果の学習バッファは以下のように更新される。
【表18】
【0082】
そして、結果のオーバーフローバッファは以下のように更新される。
【表19】
【0083】
学習バッファとオーバーフローバッファは共に制限されており、且つ／又は最大サイズがあるので、ステージ３の処理では、いくつの追加イベントが処理されるかに関わらず、限られた量のメモリが節約される。一実施形態において、どのようにイベントを集約するかを決定するために、そのイベントは２つのバッファと照合されるのみであるので、ステージ３で処理される各イベントは、定数O(1)のオーダーである時間枠で処理される。
【0084】
保持値を考慮すると、学習バッファ及び潜在的にはオーバーフローバッファにはその値を含むエントリが存在する。全てのエントリからのメトリックを同じ保持値と組み合わせることにより、その保持値について正確なメトリックが与えられる。
【0085】
ステージ４：集約結果の抽出。呼出し側は、集約プロセッサから集約結果を抽出してよい（４０８）。抽出が呼び出されたとき、集約プロセッサはステージ１（４０２）かステージ３（４０６）のいずれかにある可能性がある。
【0086】
プロセッサが依然としてステージ１（４０２）にある場合、システムは、学習バッファが、構成された出力サイズよりも多くのエントリを含むか否かをチェックする。学習バッファが構成された出力サイズよりも多くのエントリを含まない場合、学習バッファのコンテンツ全体が返される。学習バッファが構成された出力サイズよりも多くのエントリを含む場合、ステージ２の学習は保持値を生成するように強制され、集約プロトコルがステージ３（４０６）にあるとき、以下で説明されるように、集約結果が抽出される。
【0087】
抽出が呼び出されたときに集約プロセッサがステージ３（４０６）にある場合、プロセッサはまず、イベントカウントを下ることにより、学習バッファをソートする。次にプロセッサは、最大で構成された出力サイズまで、上位Ｎ個のエントリを選択する。学習バッファに残っているエントリがある場合、残りのエントリの各々は、非可逆次元値を保持値に対して検討してオーバーフローキーを生成することにより、オーバーフローバッファへと処理される。オーバーフローキーを用いて、学習バッファの残りの全ての集約イベントがオーバーフローバッファに配置される。この処理の後、オーバーフローバッファのコンテンツが出力に付加される。
【0088】
上記の例を続けると、出力サイズが２である場合、以下が集約プロセッサからの出力である。
学習バッファ：
オーバーフローバッファ：
複合出力：
なお、出力は、選択された保持次元値の各々について正確なメトリックを含む。ソースＩＰ10.0.23.123では、出力は合計５つのイベントを示す。ソースＩＰ10.0.23.122では、出力は合計２つのイベントを示す。宛先ＩＰ10.2.34.212では、出力は合計７つのイベントを生成する。
学習バッファ：
【表20】
【表21】
【表22】
【0089】
プロセッサがステージ３（４０６）にあるとき、出力サイズとオーバーフローバッファサイズの合計は出力のサイズである。一実施形態において、結果抽出後、プロセッサはその学習バッファとオーバーフローバッファをクリアし、ステージ１に戻る（４０２）。
【0090】
集約プロセッサの構成において、従来技術に比べて、集約プロセッサのランタイム特性の利点がいくつか存在する。
１．有限メモリの使用：各集約プロセッサは、固定サイズの学習バッファと、既知の上限をもつオーバーフローバッファとを用いる。
２．ストリーミング集約：イベントがプロセッサによって処理されるので、到着するイベントを保持せずに、集約がオンザフライで生成される。
３．一定の計算時間：各イベントは、学習とオーバーフローバッファに対する２回の一定時間ルックアップを通じて、一定量の計算を用いて処理される。
４．保持値の正確なメトリック：出力は、非可逆次元の全て保持値について正確なメトリックを含む。
１．有限メモリの使用：各集約プロセッサは、固定サイズの学習バッファと、既知の上限をもつオーバーフローバッファとを用いる。
２．ストリーミング集約：イベントがプロセッサによって処理されるので、到着するイベントを保持せずに、集約がオンザフライで生成される。
３．一定の計算時間：各イベントは、学習とオーバーフローバッファに対する２回の一定時間ルックアップを通じて、一定量の計算を用いて処理される。
４．保持値の正確なメトリック：出力は、非可逆次元の全て保持値について正確なメトリックを含む。
【0091】
プラグイン／プラガブルのステージ２学習。図４で説明されたように、アダプティブ集約／処理はステージに分解される。その結果、どの非可逆次元値を保持するかを識別するためのプラグインを用いて、異なる学習アルゴリズムをステージ２（４０４）で切り替えることができる。これにより、学習について複数の可能性が開かれる。
１．学習バッファを組み合わせる。図４のステージ２（４０４）で説明されたように、学習アルゴリズムは、単一の学習バッファ内の頻度を用いて、保持値を決定することができる。可逆次元値の固有の組合わせごとに複数の学習バッファが存在することがあるので、アルゴリズムは、全ての学習バッファからの頻度を利用して、どの値を空間上に保持するかを決定することもできる。全ての学習バッファを併用することにより、保持するべき非可逆次元値を選択するためのグローバルな視点が得られる。
２．過去の保持値を活用する。ステージ２（４０４）の学習に関する別の変形は、現在の学習バッファからの値を用いる代わりに、以前の保持値を経時的に利用することである。以前の検出からの保持値を現在の値と組み合わせることにより、より安定した一連の保持値が提供される。過去の保持値は、保持値が更に観察されない場合、ゆっくりと、経時的に考慮の対象から除外されるという衰退に関連付けられてよい。且つ／又は、
３．異なるメトリックを用いる。頻度を用いる代わりに、この代替タイプの学習アルゴリズムは、保持値を決定するために、応答時間や応答サイズなどの異なるメトリックを用いることができる。これにより、出力に対して異なるセマンティクスが生成される。最も頻繁に発生するイベントの正確なメトリックを生成する代わりに、応答時間又は応答サイズを用いることにより、応答時間及び応答サイズが高いか又は低いイベントの正確なメトリックを生成することができる。特定の使用例では、このタイプのイベントの次元値を識別することが重要であることがある。
１．学習バッファを組み合わせる。図４のステージ２（４０４）で説明されたように、学習アルゴリズムは、単一の学習バッファ内の頻度を用いて、保持値を決定することができる。可逆次元値の固有の組合わせごとに複数の学習バッファが存在することがあるので、アルゴリズムは、全ての学習バッファからの頻度を利用して、どの値を空間上に保持するかを決定することもできる。全ての学習バッファを併用することにより、保持するべき非可逆次元値を選択するためのグローバルな視点が得られる。
２．過去の保持値を活用する。ステージ２（４０４）の学習に関する別の変形は、現在の学習バッファからの値を用いる代わりに、以前の保持値を経時的に利用することである。以前の検出からの保持値を現在の値と組み合わせることにより、より安定した一連の保持値が提供される。過去の保持値は、保持値が更に観察されない場合、ゆっくりと、経時的に考慮の対象から除外されるという衰退に関連付けられてよい。且つ／又は、
３．異なるメトリックを用いる。頻度を用いる代わりに、この代替タイプの学習アルゴリズムは、保持値を決定するために、応答時間や応答サイズなどの異なるメトリックを用いることができる。これにより、出力に対して異なるセマンティクスが生成される。最も頻繁に発生するイベントの正確なメトリックを生成する代わりに、応答時間又は応答サイズを用いることにより、応答時間及び応答サイズが高いか又は低いイベントの正確なメトリックを生成することができる。特定の使用例では、このタイプのイベントの次元値を識別することが重要であることがある。
【0092】
その他の使用例。本明細書に開示されているように、限定ではないが、アプリケーションネットワーク視覚化エッジ生成のためにアダプティブ集約を用いることは、ひとつの使用例に過ぎない。アダプティブ集約方法は、次元及びメトリックを伴うイベントの任意のストリームに役立つ一般化手法である。その結果、アダプティブ集約方法は、多くのホストアプリケーションとサービスに組み込むことのできる汎用ライブラリとして実現される。
【0093】
例えば、アダプティブ集約は、集約データを中央分析サービスに送信する前に収集されたメトリックイベントを集約及び制限する分析エージェントで用いられる。これにより、メトリックによって消費されるネットワークリソースが削減され、分析システムが無制限の量のデータによって圧倒されることが防がれる。
【0094】
エージェントをアダプティブ集約を含むように更新できない場合、同じ集約ライブラリをサービス側で用いることもできる。サービスがエージェントからデータを受け取ると、まず集約ライブラリを介してデータを渡して、集約イベントを残りのサービスに渡す前に、データ量を減らして制限することができる。
【0095】
【0096】
ステップ５０２において、複数のエージェントを用いてアプリケーションネットワークが監視される。一実施形態において、複数のエージェントは複数の軽量エージェントを含む。
【0097】
ステップ５０４において、集約次元の値を決定するために、アダプティブイベント集約が実行される。一実施形態において、アダプティブイベント集約を実行することは、複数のエージェントを用いてアプリケーションネットワークを監視することに関連付けられるイベントを集約することに少なくとも部分的に基づいて、集約次元の値を決定することを含む。一実施形態において、アダプティブイベント集約を実行することは、インライン学習及びイベントデータの収集を実行することを含む。一実施形態において、アダプティブイベント集約は集約プロセッサによって実行される。
【0098】
ステップ５０６において、集約次元に基づいて、アプリケーションネットワークの報告が生成される。一実施形態において、レポートは、アプリケーションネットワークの視覚化と、イベント監視レポートと、ネットワークトポロジレポートのうち少なくとも１つを含む。
【0099】
一実施形態において、エージェント集約メトリックは、低減されたネットワーク帯域幅の下で通信される。一実施形態において、アプリケーションネットワークの図形視覚化は、成功閾値に基づいて重大イベント及び失敗イベントを示す報告に基づいて生成される。
【0100】
一実施形態において、アプリケーションネットワークのトポロジの図形視覚化が生成される。図形視覚化は、監視データの名称と値のペアと、コンテキスト次元と、イベントデータと、タイムスタンプと、ＩＰアドレスのネットワークタプルと、ポートのネットワークタプルと、プロトコルのネットワークタプルと、応答コードと、次元のカウントと、アプリケーションネットワークのエンティティ間の呼出しの数と、次元のサイズと、応答サイズとのうち少なくとも１つの図形キューを含んでよい。
【0101】
図６は、集約処理のプロセスの実施形態を示すフローチャートである。一実施態様において、図６のプロセスは図３のエージェント（３０２ａ…３０２ｅ）によって実行され、また、図５のステップ（５０４）の一部である。
【0102】
ステップ６０２において、データ収集が学習バッファへサンプリングされる。一実施形態において、学習バッファサイズ、学習アルゴリズム、出力サイズ及び保持値カウントのうち少なくとも１つは構成可能である。
【0103】
ステップ６０４において、学習バッファが満杯であるイベントでは、集約次元の保持値が学習を用いて識別される。一実施形態において、アダプティブ学習は、保持値を識別するために用いられる。一実施形態において、集約次元は、可逆次元、非可逆次元及び折り畳み次元のうち少なくとも１つとして構成可能である。一実施形態において、保持値を識別することは、集約及び未使用のうち少なくとも１つとしてメトリックを構成することを含む。
【0104】
一実施形態において、学習を用いた識別は、トップＮ技法と、継時アダプテーション（adaptation over time）技法と、学習バッファを組み合わせる技法と、過去の保持値を用いる技法と、異なるメトリック技法とのうち少なくとも１つを用いることを含む。
【0105】
ステップ６０６では、インライン集約を用いて、追加イベントがオーバーフローバッファに記憶される。一実施形態において、追加イベントを記憶することは、保持値の可逆メトリックを含む追加イベントの線形計算を含む。
【0106】
ステップ６０８において、学習バッファ及びオーバーフローバッファから集約された結果が抽出される。
【0107】
前述の実施形態は、理解を明確にするために詳細に記載されているが、本発明は、提供された詳細に限定されない。本発明を実施する代替の方法は多く存在する。開示された実施形態は例示的なものであり、限定的なものではない。
【図1】
【図2A】
【図2B】
【図3】
【図4】
【図5】
【図6】
