雷达

概要

レーダーは、データ収集方法のバックボーンを形成します。Radar は、コンテンツページまたはアプリケーションプロバイダのページに埋め込まれた JavaScript スクリプトを使用して、データセンターまたは配信プラットフォームのパフォーマンスと可用性に関する情報を収集します。

雷达クライアントは、顧客の Web ページおよびモバイルアプリケーション内で実行される JavaScript アプリケーションです。その主な目的は、Openmix を介してインテリジェントなルーティング決定を行うために使用されるネットワークパフォーマンスデータを収集し、オプションのプラグインを提供し、ページ読み込み時間、ページリソースのタイミング、ビデオ再生メトリックなど、他のインテリジェントトラフィック管理サービスを有効にすることです。

雷达クライアントは、フル機能でありながら、軽量で、目立たないものです。クライアントは、ほとんどのページリソースがダウンロードされるまで待ってから、その作業の大部分を実行し、すべてのネットワーク通信は、可能な限り非同期的に実行されます。次の手順では、セッション中に次に測定するプラットフォームを指定します。このプラットフォームは、コミュニティプラットフォームとそのコミュニティメンバーに固有のプライベートプラットフォームから選択されます。また、実行すべき測定の種類も示します。これには、可用性、往復時間、スループット、またはその他のメトリックの収集が含まれます。

できるだけ小さくするために、JavaScriptは、Google閉鎖コンパイラを使用して高度な最適化でコンパイルされています。高度なオプション機能は、その使用を選択しているお客様向けのプラグインとして提供されます。

レーダーコミュニティ

独自のコミュニティベースのアプローチを使用して、Radar は、クラウドコンピューティングやストレージからコンテンツおよびアプリケーション配信ネットワークまで、世界最大の公共インフラストラクチャのグローバルなパフォーマンスと可用性を比類のない透明性をもたらします。Radar を使用すると、お客様は、訪問者のそれぞれにとって最適なパフォーマンスを発揮するプラットフォームをすばやく見つけることができます。

レーダーは、インターネット初のクラウド監視協同組合です。コミュニティメンバーになることは、プロバイダー、国、ネットワークによる詳細なセグメンテーションを含む、履歴レポートデータベースへの無制限アクセスを意味します。

雷达コミュニティのメンバーとして、社内外のコンテンツ・デリバリー・インフラストラクチャが提供するサービス・レベルを取得するための豊富なツール・セットも提供しています。レーダーに特有ののは、Webサイトの訪問者を活用して、企業によって現在使用されていないプラットフォームから得られるエクスペリエンスを測定できることです。同じ手法により、クラウドプラットフォームのライフサイクル全体にわたって客観的に評価できます。これには、SLA に対するパフォーマンスの継続的な評価も含まれます。

ウェブページに単純な JavaScript タグを追加するか、モバイルアプリケーションに SDK を追加することで、顧客は各訪問者を仮想「テストエージェント」に変えることができます。レーダーは、参照オブジェクトをダウンロードして、サイトやウェブアプリケーションの実際のエンドユーザーに見られるように、内部および外部のインフラストラクチャ、データセンター、配信ネットワーク、クラウドプラットフォームを比較することにより、デバイスベースの測定をトリガーします。

参加の主なメリット

レーダーは、監視とデータ収集のアプローチを通じて、Web配信に関する複数の課題に対処します。レーダーコミュニティに参加する主な利点は次のとおりです。

• あらゆる場所のすべてのネットワークにエンドユーザーがいる大規模なテスト環境（これまでに42,000 台以上のネットワークが認識されています）。
• より十分な情報に基づいた意思決定を行うために、トライアリング前にサービスプロバイダーに関する重要な情報を入手してください。
• 現在のプロバイダーのパフォーマンスと、ユーザーがいない地域におけるプロバイダーの動作の透明性。
• Webユーザーとモバイルユーザーに真の違いをもたらすメトリック（パフォーマンス、可用性、QoS）に焦点を当てます。
• グローバル（190カ国以上）国、ネットワーク、地域、州レベルまでの情報の無制限表示。
• エンドユーザーを使用した実際の偏りのないデータレーダーデータは、模擬テストや最良の推測ではなく、「実世界」の情報です。
• すべてのユーザーが同じではありません:異なるマシン、接続、デバイスを理解します。
• 実際のページのパフォーマンスの可視性。

ベンチマーク

ITM レーダーは、3 つの主要なベンチマークを提供します。

• コミュニティベンチマーキング
• プライベートベンチマーキング
• ページ読み込みベンチマーキング

CDN,クラウド,データセンターのコミュニティベンチマーキング

コミュニティ測定は、クラウドソーシングモデルを通じて調達され、グローバルな地理的レベルおよび論理レベルでのベンダーのパフォーマンスと可用性のビューを提供します。コミュニティ測定により、エンドユーザから見たベンダーのエクスペリエンスの品質を比較し、コンテンツやアプリケーションの配布についてベンダーやサプライヤを評価する際に「What-if」分析を行うことができます。クラウドソーシングモデルを使用することで、ITMのお客様は、ベンダーのパフォーマンスを評価および監視する際に、より高いレベルの細分性と品質を得ることができるようになります。ただし、顧客が高密度のユーザーや実際にはユーザーを持たない場所でも同様です。

測定自体は、エンドユーザーがコンテンツ所有者のサイトまたはアプリケーションで Radar JavaScript クライアント、またはモバイル SDK ロジックを実行するときにダウンロードする、さまざまなクラウドおよび CDN ベンダーに配置された標準のオブジェクトセットを使用します。

次に、次のメトリックが ITM に報告され、ポータルまたは API レポートインターフェイス内に表示されます。

• 可用性-オブジェクトがロードされるかどうか。
• 応答時間：接続確立のノイズのすべてが完了した後、サーバが後続の要求に応答するのにかかる時間。これは、ブラウザーからプロバイダーへの TCP ラウンドトリップ時間 (RTT) の比較的近い近似値です。
• throughputt：100 KB オブジェクトの取得から測定された、接続のデータレート（キロビット/秒）です。

プライベートベンチマーキング

レーダータグの導入の一環として、ITM は、お客様の訪問者が測定する独自の「ベンチマーク」テストを作成する機能を提供します。これは、データセンターまたは独自の CDN およびクラウド契約のために可能です。コミュニティのベンチマーク測定と同様に、可用性、応答時間、スループットといった同じ指標が提供されるため、お客様は既存のコンテンツ配信戦略を効果的に評価できます。

この個人情報はお客様のみが利用でき、共有されません。 使用例は次のとおりです。

• 独自のデータ・センター・アーキテクチャ/秒
• 独自のテストオブジェクトまたはページを使用する
• 特定のベンダーまたは一連のベンダーとの独自の契約およびアカウントを使用する

レーダーページ負荷ベンチマーキング

雷达ITM では、タグが実装されているページのダウンロード方法に関する詳細情報を顧客に表示できます。ITM は、Web ページとの対話時に実際にエンドユーザーが経験しているパフォーマンスを確認するための情報を提供します。データは、新しいバージョンのブラウザの多くでサポートされているナビゲーションタイミング API を通じて提供されます。

レーダータグ

レーダータグは、JavaScript スニペットを使用して統合できます。[レーダータグ] ページに移動するには、次の操作を行います。

1. Citrix Intelligent Traffic Management ポータルにサインインします。
2. 左側のナビゲーションメニューから [レーダー] > [Javascript タグ] を選択します。

[レーダータグ] ページが開きます。

雷达タグをまだ設定していない場合は、画面上部にオレンジ色の水平バーが表示され、レーダー測定が検出されなかったことが示されます。

このオレンジ色のバーは、タグが正しく構成されていない場合にも表示されます。

または、レーダータグが期待どおりに機能している場合は、レーダー測定が正常に取得されたことを示す緑色の水平バーが表示されます。

このページでは、使用状況に適用されるタグのバージョンを選択し、クリップボードにコピーできます。

注:このJavaScriptスニペットを変更しないことが重要です。コードには重要な情報が含まれています。変更すると、予期しない動作や信頼性の低い動作を引き起こす可能性があります。

レーダータグの統合

雷达タグの統合は比較的簡単です。あなたがする必要があるのは、以下のJavaScriptスニペットの1つをサイトのマークアップに追加することだけです。測定するページのHTMLにそれを置きます。ページの下部に閉じるボディタグの前に配置することをお勧めします。

既定のレーダータグ

これは、Radar タグの推奨バージョンです。このバージョンは、ロードイベントが完了するまで待機してから Radar Client をダウンロードして実行し、load イベントが中断されないようにします。

このバージョンのタグは、Radar Client のダウンロードがページのさらなる解析をブロックしないようにします。ただし、load イベントが発生する前に実行されます。これは、コンテンツセキュリティポリシーの設定を使用してインライン JavaScript の使用を禁止しているお客様向けです。また、Radar Client をできるだけ早くロードする必要があるビデオ QoS プラグインを使用しているお客様にも使用できます。

最近の測定

「最近の測定」(Recent Measurements) テーブルでは、レーダーを使用して取得した最新の測定値を表示できます。

[最近使用した測定] ボタンをクリックします。それはあなたに次の情報を提供します：

• UTCで測定された日付と時刻。
• 測定が行われた国。
• 測定に使用されたプラットフォーム。
• プラットフォームの ID。
• 測定値のタイプ。接続時間 (ミリ秒)、応答時間 (ミリ秒)、スループット (キロビット/秒)
• 測定値の実際の値（ミリ秒）（接続時間と応答時間の場合）またはキロビット/秒（スループットの場合）。

レーダー測定バーは、ITM ポータルへの初回ログイン時に [レーダーダッシュボード] ページにも表示されます。

モバイルアプリとの統合

モバイルアプリとの統合は、JavaScript クライアントを実行する非表示の Web ビューを囲むラッパーを介して行われます。これにより、ブラウザーやモバイルアプリで収集されたデータの一貫性が保証されます。

雷达と iOS アプリを統合する手順次のGitHub リポジトリには、Radar を iOS アプリと統合するためのラッパーコードとステップバイステップの手順が含まれています。

iOS用レーダーランナー

Androidのレーダーとレーダー統合するための手順は、 Androidアプリにレーダー統合することが容易になりますクライアントライブラリです。それはここで見つけることができます：

AndroidRadar Library

Citrix ADC との統合

雷达タグは、Openmix がより良いルーティング決定を下すための測定値を Openmix に供給するため、重要です。タグを使用する Web ページが多いほど、ルーティングの決定が向上します。

以下の方法を使用すると、Citrix ADCを使用してレーダーJavaScriptタグをWebページに配置できます。コマンドラインまたはCitrix ADC構成ユーティリティを使用できます。

これらのメソッドを使用すると、Radar タグを応答に挿入できます。Radar タグを挿入するには、書き換えを使用する必要があります。書き換えは、アクションの作成、ポリシーの設定、ポリシーのバインドの 3 つの手順に分かれています。

コマンドライン設定

コマンドライン書き換えアクションの設定

テンプレート:

add rewrite action    [] [-pattern  | -search ] [-refineSearch ] [-comment ] 

例:

add rewrite action radar_tag action insert_after HTTP.RES.BODY(HTTP.RES.CONTENT_LENGTH).BEFORE_STR("") '""' 

注: カスタマー ID を記載されている場所に挿入します。

コマンドライン設定リライトポリシー

テンプレート:

add rewrite policy    [] [-comment ] [-logAction ] 

例:

add rewrite policy radar_tag_policy HTTP.RES.HEADER("Content-Type").TO_LOWER.CONTAINS("text/html") radar_tag_action 

コマンドラインバインディングリライトポリシー

テンプレート 1:

bind vpn vserver  [-policy  [-priority ] [-secondary] [-groupExtraction] [-gotoPriorityExpression ] [-type ]] [-intranetApplication ] [-nextHopServer ] [-urlName ] [-intranetIP   ] [-staServer  [-staAddressType ( IPV4 | IPV6 )]] [-appController ] [-sharefile ] 

例 1:

bind vpn vserver  -policy radar_tag_policy -type RESPONSE -priority 10 

テンプレート 2:

结合cs vserver <名称> (-lbvserver <字符串> | vserver  | (-policyName  [-targetLBVserver ] [-priority ] [-gotoPriorityExpression ] [-type ( REQUEST | RESPONSE )] [-invoke ( ) ] ) | (-domainName  [-TTL ] [-backupIP ] [-cookieDomain ] [-cookieTimeout ] [-sitedomainTTL ])) 

例 2:

bind cs vserver  -policyName radar_tag_policy -type RESPONSE -priority 10 

テンプレート 3:

bind lb vserver @ (@ [- weight ]) | @ | (- policyName @ [-priority ] [- gotoPriorityExpression ] [-type ( REQUEST | RESPONSE )] [-invoke ( ) ] ) 

例 3:

bind lb vserver  -policyName radar_tag_policy -type RESPONSE -priority 10 

テンプレート 4:

bind rewrite global   [] [-type ] [-invoke ( ) ] 

例 4:

绑定改写100年全球radar_tag_policy类型RES_DEFAULT 

GUIユーティリティの設定

GUI 書き換えアクション

1. Citrix ADC構成ページの左側のナビゲーションメニューから、AppExpert->[ 書き直し]->[ リライトアクション]に移動します。

2. [追加] ボタンを選択します。

3. [書き換えアクションの設定] ページで、例に示す式を入力します。

4. レーダースクリプトで、マークされたスペースにカスタマー ID を入力します。

5. ［OK］を選択します。書き換えアクションの作成が完了しました。

GUI 書き換えポリシー

1. Citrix ADC構成ページの左側のナビゲーションメニューから、AppExpert-> [書き直し]->[ リライトポリシー] の順に選択します。

2. [追加] ボタンを選択します。

3. [書き換えポリシーの設定] ページで、例に示す式を入力します。

   

4. ［作成］をクリックします。

書き換えポリシーの設定が完了しました。

GUI バインディングリライトポリシー

ポリシーの設定が完了したら、最後の手順で PolicyManagerを使用してポリシーをバインドします。

1. [リライトポリシー] ページに移動します。

2. レーダータグ用に作成した書き換えポリシーを選択します。

3. [ポリシーマネージャ]に移動します。

   

4. [Policy Manager] ページで、次の操作を実行して、ポリシーをバインドできます。

   • [バインドポイント] では、[グローバル]、[VPN 仮想サーバー]、[コンテンツスイッチング仮想サーバー]、または[負荷分散仮想サーバー] を選択できます。
   • [プロトコル] で [HTTP] を選択します。
   • [接続タイプ] で [応答] を選択します
   • 仮想サーバーの場合は、独自の仮想サーバー名を使用します。

   

   • ［続行］をクリックします。
   • 次のページで、前に作成した書き換えポリシーを選択します。
   • バインドの詳細を追加します。
   • ［バインド］をクリックします。

   

上記の方法を使用すると、Webページにレーダータグを挿入することができます。ただし、これは基本的な実装であることに注意する必要があります。タグを実装したページをより適切に制御するために、さらにフィルタリングを行うことができます。

レーダータグの設定

レーダーは、[レーダータグの設定] ページで設定できます。

1. Citrix Intelligent Traffic Management ポータルにサインインします。
2. 左側のナビゲーションメニューから、[レーダー] > [タグ設定] を選択します。

[レーダータグの設定] ページが開きます。ここでは、レーダー測定をカスタマイズするためのさまざまなオプションを設定できます。Radar JavaScript には、タイミングと遅延要素、コミュニティおよびプライベート測定のためにエンドユーザーが完了したテストの数、可用性を測定するためのタイムアウト値などを調整するためにカスタマイズできるパラメータがあります。

次の表に、構成オプションとそれぞれのデフォルト設定について説明します。変更を行うときは、画面下部の [レーダー設定の更新] をクリックして変更を適用します。

*Auto は、インテリジェントトラフィック管理が、エンドユーザーの場所に基づいて、特定のセッションで測定する必要があるプラットフォームの数を決定することを意味します。私たちは、データが密集している大規模なネットワークではなく、疎である小規模ネットワークでは、セッションごとに多くのプラットフォームを測定しようとしています。

**これは、セッションごとに試行される測定値の最大数です。たとえば、Radar では、セッションごとに 4 つのプライベートプラットフォームを測定できます。これらのプラットフォームはすべて RTT とスループットの両方を測定するように構成されています。ただし、[プライベートスループットの最大測定] が 2 に設定されている場合、クライアントは最初の 2 つのプライベートプラットフォームを測定した後、スループット測定値を含めることを停止します。最後の 2 つのプラットフォームでは、RTT のみが測定されます。

タイミングオプションでは、Radar が測定を開始するまで待機する時間の長さを設定できます。

注:起動遅延は秒単位ですが、繰り返し遅延は分単位です。

プロトコルオプション

通常、Radar クライアントは、実行されているページのプロトコルと一致する URL を持つプラットフォームのみを測定します。これらのオプションを使用すると、プライベートプラットフォームでその動作を上書きできます。たとえば、「常にプライベートHTTPS測定を許可」を有効にすると、クライアントはhttp://example.comからhttps://myprovider.com/r20.gifを測定でき 、「常にプライベートHTTP測定を許可」を有効にすると、クライアントはhttps://example.comからhttp://myprovider.com/r20.gifを側的できます。

これらのオプションは、極端な使用例を除き、一般的に避ける必要があります。適切なプライベート測定密度を確保する最善の方法は、実際に使用している（それ以上ではない）プラットフォームとプロトコルを測定するようにプラットフォームを構成し、できるだけ多くの運用ページに Radar タグを展開することです。私たちは時々、これを「必要な場所にレーダを置く」と呼びます。

サンプルレートでは、測定値を収集する Web ページ (ユーザーが閲覧する) の割合を設定できます。たとえば、ウェブサイトが1日100,000ページビューを取得し、5% のサンプルレートを設定した場合、レーダーは 100,000 ページビューのうちの 5% の測定値のみを収集します。

プライベート測定

これらの設定は、プライベートプラットフォームの測定に適用されます。プライベートプラットフォームとは、特定の CDN、クラウドプロバイダー、およびインフラストラクチャの他の部分を測定するために [プラットフォーム] セクションで設定するプラットフォームです。詳細については、「プラットフォーム」の項を参照してください。

このオプションでは、コミュニティに情報を提供するときの Radar の動作を設定できます。

レーダーテストをオフにする

予期せぬ事態が発生した場合にレーダー測定を迅速に無効にする必要がある場合は、ポータル内でそれを行うことで、サイトへの緊急コードの変更を回避できます。

[レーダータグの設定] ページで、[使用可能] トグルボタンをクリックして [非公開測定]、[コミュニティ測定]、または [両方] をオフに切り替えます。

[レーダー設定の保存] をクリックして、変更を確定します。変更が反映されるまでに 1 分または 2 分かかることがあります。その後、レーダー測定が停止します。

レーダークライアントの方法論

クライアントの動作の基本的な次元は、セッションです。クライアントが送信するすべてのデータは、セッションに関連付けられます。セッションは、初期化要求と呼ばれるCitrixサーバーへの呼び出しによって作成されます。セッションの有効期限が短く、有効なレーダーデータのみが受け入れられるようにします。この機能により、レーダーの測定値は常にセッショントランザクション ID に関連付けられたバッチで取得され、「レーダーセッション」を参照して、それに関連付けられた測定値を記述することがよくあります。

レーダーセッション

レーダーセッションは、クライアントが実行する主な作業単位です。これは、Citrixサーバーへの顧客構成と測定する一連のプラットフォームを取得するための要求と、それらのプラットフォームを測定し、結果を報告する要求で構成されます。これらは、非同期かつシリアル化された方法で行われるため、一度に1つの要求しか発生しません。典型的なセッションは10秒未満で完了します。

プローブの種類

クライアントが送信するすべてのレポートには、プローブの種類が関連付けられています。プローブの種類は、それがどのような測定であり、どのように処理するかをシステムに伝えます。また、実行する測定の種類も示します。これには、可用性、往復時間、スループット、またはその他のメトリックの収集が含まれます

可用性とパフォーマンスのプローブ（ラウンドトリップ時間やスループットなど）には、重要な関係があります。特定のリソースの可用性は、常に特定の測定セッションで最初に測定されます。可用性の測定が成功した場合のみ、同じセッションで同じリソースの追加のパフォーマンス測定が行われる可能性があります。

特に低速なネットワークで可用性の停止が発生すると、このネットワークを含むレポートの総パフォーマンスが実際に改善される可能性があります。Citrix Intelligent Traffic Management では、常にネットワーク固有のパフォーマンスデータを使用してリアルタイムの意思決定を行うため、これはレポート作成アーティファクトに過ぎません。

可能性

コールドスタートプローブとも呼ばれる可用性は、サービスがキャッシュをウォームできるようにすることを目的としています。このプローブには測定値がありますが。可用性プローブを使用して、プロバイダーが利用可能かどうかを判断します。

コールドスタートプローブを実行するようにプラットフォームが設定されていない場合、コールドスタートレポートの代わりに RTT プローブの結果を使用して、可用性メトリックスを提供します。

同様に、サイトアクセラレーションサービスを測定する動的オブジェクトの場合、クライアントは小さなテストオブジェクトを 1 回ダウンロードし、コールドスタート時間と応答時間の両方の測定値をレポートします。

RTT

スループット

テストオブジェクト

テストオブジェクトは、プラットフォーム上でホストされ、測定値を生成するためにクライアントによってダウンロードされるファイルです。このセクションでは、クライアントがサポートするさまざまな種類のテストオブジェクトについて説明します。すべてのオブジェクトタイプがすべてのプラットフォームに適用されるわけではありません。

必要なヘッダー:

リソースタイミング API によって提供される低レベルのタイミングデータへの JavaScript アクセスを許可するには、Timing-Allow-Origin レスポンスヘッダーが必要です。推奨される設定はTiming-Allow-Origin: *です。これは、リソースのタイミングデータにアクセスする権限を任意のドメインで実行している JavaScript に付与する必要があることを示します。

Standard

標準テストオブジェクトはメディアであり、クライアントは Image オブジェクトにsrc属性を設定することによってダウンロードします。ダウンロードが完了すると、クライアントはリソースタイミング API を使用してパフォーマンスデータを収集します。 これらのテストオブジェクトは、Timing-Allow-Origin レスポンスヘッダーとともに提供する必要があります。詳細については、「タイミング-許可オリジンヘッダー」セクションを参照してください。

スタンダードスモール

標準的な小さなテストオブジェクトは、クライアントが軽量のネットワーク要求を行う必要がある場合に使用される、単一のピクセルイメージファイルです。

標準的な小さなテストオブジェクトは、次のユースケースで使用されます。

• 非動的コールドスタートプローブ
• 非動的往復時間プローブ

スタンダードラージ

標準ラージテストオブジェクトは、プラットフォームのスループットを測定するために使用される 100 KB のイメージファイルです。

ラージ・オブジェクト・ネーミング: スループットを計算するには、クライアントはテスト・オブジェクトのサイズを知る必要があります。クライアントは、ファイル名のどこかに KB を検索してファイル名を決定します。例：r20-100KB.png。名前に同じ方法でファイルサイズが含まれている限り、さまざまなサイズのイメージファイルを測定できます。例：myimage-2048kb.jpg。

動的

動的テストオブジェクトは,サイトアクセラレーションサービスに関連するパフォーマンスを測定するために使用されます。 各ファイルは、ナビゲーションタイミング API からタイムスタンプを収集し、親ページにポストできる JavaScript を含む HTML ファイルです。クライアントは iframe を使用してテストオブジェクトをダウンロードし、これらのタイムスタンプを取得し、それを使用して測定値を計算します。

セキュリティと検証

テストオブジェクトは 40KB のオブジェクトです。テストオブジェクトの新機能として、HMAC（ハッシュベースのメッセージ認証コード）があります。このコードは、クエリーパラメータとサーバがアクセスできる秘密キーに基づいて提供されます。このHMACは測定とともに送り返され、レーダークライアントがテストオブジェクトにアクセスできて、何もキャッシュされていないことを検証することができます。

動的テストオブジェクトと標準テストオブジェクトの違い：

標準的なレーダー測定では、テストオブジェクトのダウンロードに関連する主要な要求アクティビティのみを分離しますが、サイトアクセラレーションサービスの場合は、アクティビティをより多く測定することが目標です。したがって、DNS ルックアップと接続時間も含まれています。 また、動的測定は、エッジキャッシュだけでなく、サービスオリジンに当たったときのリクエストパフォーマンスを測定することを目的としています。

ポータルでは、次の操作を行って、この方法を選択できます。

• 左側のナビゲーションメニューから [プラットフォーム] に移動します。
• ページの右上隅にある [プラットフォームを追加] アイコンをクリックします。
• [プライベートプラットフォーム] > [カテゴリ] > [動的コンテンツ] に移動します。
• [レーダーテストオブジェクト] ダイアログボックスで、[プローブのカスタマイズ] チェックボックスをオンにします。
• [ 応答時間 ]の URL を入力し、[ オブジェクトタイプ ]ドロップダウンリストから[ Web ページ動的]を選択します。

動的小テストオブジェクトは、サイトアクセラレーションサービスの同じプローブを使用して、可用性とラウンドトリップ時間を測定するために使用されます。

iNav

inAV テストオブジェクトは、多くのタスクを実行できる JavaScript を含む静的な HTML ファイルです。クライアントは、iframe に HTML ファイルをロードする URL にクエリ文字列パラメータを含めることで、実行するタスクを示します。 iNav テストオブジェクトは、次のユースケースをサポートします。 iNav コールドスタート iNav 往復時間

iUNI

iUni テストオブジェクトは、プラットフォーム（別のテストオブジェクトを必要としない CORS AJAX）のレーダー測定セットに関連付けられた UNI 値を検出するために使用されます。

AJAX GET

AJAX GET 方法論は、通常、顧客が測定したい任意の URL で使用できます。ただし、Timing-Allow-Originヘッダーと適切なAccess-Control-Allow-Originヘッダーで提供されます 。 ポータルでは、次の操作を行って、この方法を選択できます。

• 左側のナビゲーションメニューから [プラットフォーム] に移動します。
• ページの右上隅にある [プラットフォームを追加] アイコンをクリックします。
• [プライベートプラットフォーム] > [カテゴリ] > [動的コンテンツ] に移動します。
• [レーダーテストオブジェクト] ダイアログボックスで、[プローブのカスタマイズ] チェックボックスをオンにします。
• [応答時間] を入力し、[オブジェクトタイプ] ドロップダウンリストから [AJAX (GET)] を選択します。

タイミング許可オリジンヘッダー

リソースタイミング API によって提供される低レベルのタイミングデータへの JavaScript アクセスを許可するには、Timing-Allow-Origin レスポンスヘッダーが必要です。 推奨設定はTiming-Allow-Origin: *です。これは、リソースのタイミングデータへのアクセス許可を、任意のドメインで実行されている JavaScript に付与する必要があることを示します。

レーダーAPI

雷达は、運用およびデータ取得機能の両方の API を提供します。

• 運用 API — レーダーアカウントを追加/編集/削除し、API を使用してアカウントを実行するための制御メカニズム

• レーダーデータ API — ITM レーダーデータ API は、レーダーのパブリックコミュニティとプライベート測定データの集約を提供します。データは継続的に更新され、約 60 秒ごとにバッチ処理され、API による取得が行われます。データ API は、Radar データを独自のレポートおよびダッシュボードに統合できるように提供されています。APIへの単一の呼び出しは、すべての国のレーダー四分位または平均測定平均を提供することができ、各プラットフォームのための興味のある最大30のASNを提供することができます。

レーダーレポート

レーダーレポートは、レーダータグを通じて収集された動的データを強力に可視化します。

レーダーメンバーには、直感的な対話型チャートによって提示された豊富なデータセットにアクセスできます。収集されたデータセットには、顧客のレーダータグまたはモバイル SDK 展開から収集されたプライベートデータのコンテキストとして、数十億の測定値の完全なパブリックデータセットの両方が組み込まれています。ページの読み込み時間情報は顧客独自のタグで取得され、ウェブサイトとモバイルアプリケーションのエンドユーザーの実際のパフォーマンス体験に関する深い洞察を提供します。

パフォーマンス指標に加えて、レーダーレポートでは、ボリューム、地域、ユーザーエージェント、OS タイプ、ウェブサイトやモバイルアプリケーションの使用タイミングなど、エンドユーザーオーディエンスのさまざまな側面に関する洞察が提供されます。

各レポートは以下のように定義されていますが、すべてのレポートの重要な側面は次のとおりです。

プライマリディメンションとセカンダリディメンション

チャートのプライマリディメンションは、チャートの上のリスト選択リストから選択されます。これをレポートの強力なピボットとして使用します。セカンダリディメンションを選択することも、レポートをさらに絞り込むこともできます。

可視化背景切り替え

デフォルトでは、グラフは白い背景に設定されています。背景切り替えを使用して、高コントラストモニタの背景を暗い色に切り替えます。

データエクスポート

さらに、エンドユーザーは、レポートの上部にあるダウンロードリンクを使用して、チャートとテーブルデータをダウンロードできます。

フィルタ:レポート時間範囲

レーダーレポートは、過去 60 分、過去 24 時間、過去 48 時間、過去 7 日間、過去 30 日間、またはカスタム範囲の時間範囲を使用して生成できます。既定のビューは [過去 24 時間] です。

フィルター:プラットフォームと場所

レポートは、データに基づいて適切なフィルタの点でわずかに異なります。最も一般的なものは次のとおりです。

• 「プラットフォーム」— 含めるプラットフォーム (プロバイダ) を 1 つ以上選択します。
• 「大陸」(Continent) — 含める大陸を 1 つ以上選択します。
• [国] — 含める国を 1 つ以上選択します。
• 「地域」(Region) — 含める地理的地域 (該当する場合) を 1 つ以上選択します。
• 「州」(State) — 含める地理的州 (該当する場合) を 1 つ以上選択します。
• [ネットワーク] — 含めるネットワーク (ASN) を 1 つ以上選択します。

フィルタ:リソース

• データソース-レーダーコミュニティ全体またはサイトの訪問者のみからのデータを含めます。
• ロケーションソース-クライアントIPまたはリゾルバIPをロケーションソースとして選択します。
• [レーダークライアントの種類]-[JavaScript タグ]、[iOS SDK]、または [Android SDK] として [レーダークライアントタイプ] を選択します。

マイページビュー位置情報レポート

このレポートには、各国のページビュー数が表示されます。このマップビューは、グラフの下部にある [再生]ボタンを選択することで、（レポートで選択した時間範囲に基づいて）時間の経過とともに表示できます。

パフォーマンスレポート

このレポートには、定義された各プラットフォームのパフォーマンスの傾向が表示されます。

統計分布レポート

このレポートには、勘定科目に定義された各プラットフォームの統計内訳が表示されます。

単一プラットフォームの位置情報レポート

このレポートは、一度に 1 つのプラットフォームについて、国別のレーダートラフィックの分布を時系列で表示します。

単一プラットフォーム統計分布レポート

このレポートには、レーダートラフィックの分布が応答時間別に表示されます。