Radar

Überblick

Radar bildet das Rückgrat der Datenerfassungsmethodik. Radar verwendet ein JavaScript-Skript, das in eine Inhaltsseite oder die Seiten eines Anwendungsanbieters eingebettet ist, um Informationen über die Leistung und Verfügbarkeit eines Rechenzentrums oder einer Bereitstellungsplattform zu sammeln.

Der Radar-Client ist eine JavaScript-Anwendung, die auf Kundenwebseiten und in mobilen Anwendungen ausgeführt wird. Sein Hauptzweck ist es, Netzwerk-Leistungsdaten zu sammeln, die für intelligente Routing-Entscheidungen über Openmix verwendet werden, und optionale Plug-ins bereitzustellen, um andere NetScaler Intelligent Traffic Management-Dienste wie Seitenladezeit, Seitenressourcen-Timing und Videowiedergabe-Metriken zu ermöglichen.

Der Radar-Client ist voll ausgestattet, aber dennoch leichtgewichtig und unaufdringlich. Der Client wartet, bis die meisten Seitenressourcen heruntergeladen wurden, bevor er den Großteil seiner Arbeit verrichtet, und die gesamte Netzwerkkommunikation wird, wo immer möglich, asynchron durchgeführt. Diese Anweisungen legen fest, welche Plattform als Nächstes während der Sitzung gemessen werden soll, ausgewählt aus den Community-Plattformen und allen privaten Plattformen, die für dieses Community-Mitglied spezifisch sind. Sie geben auch die Arten der durchzuführenden Messungen an, die Verfügbarkeit, Roundtrip-Zeit, Durchsatz oder andere Metriksammlungen umfassen können.

Um es so klein wie möglich zu halten, wird das JavaScript mit erweiterten Optimierungen unter Verwendung des Google Closure Compilers kompiliert. Erweiterte optionale Funktionen werden als Plug-ins für Kunden bereitgestellt, die diese nutzen möchten.

Radar-Community

Mit einem einzigartigen, gemeinschaftsbasierten Ansatz bietet Radar eine unübertroffene Transparenz hinsichtlich der globalen Leistung und Verfügbarkeit der weltweit größten öffentlichen Infrastrukturen, von Cloud Computing und Storage bis hin zu Content- und Anwendungsbereitstellungsnetzwerken. Mit Radar können Kunden schnell die besten – und schlechtesten – performenden Plattformen für jeden ihrer Besucher finden.

Radar ist die erste Cloud-Monitoring-Kooperative des Internets. Die Mitgliedschaft in der Community bedeutet unbegrenzten Zugriff auf unsere historische Berichtsdatenbank, einschließlich detaillierter Segmentierung nach Anbieter, Land und Netzwerk.

Die Mitgliedschaft in der Radar-Community bietet auch eine Vielzahl von Tools zur Erfassung der Service-Levels, die sowohl von internen als auch externen Content-Delivery-Infrastrukturen bereitgestellt werden. Einzigartig bei Radar ist die Möglichkeit, Ihre Website-Besucher zu nutzen, um die Erfahrung zu messen, die sie von Plattformen erhalten würden, die derzeit nicht von einem Unternehmen verwendet werden. Dieselbe Methodik ermöglicht objektive Bewertungen von Cloud-Plattformen während ihres gesamten Lebenszyklus, einschließlich der laufenden Bewertung der Leistung im Verhältnis zu SLAs.

Durch das Hinzufügen eines einfachen JavaScript-Tags zu Ihrer Webseite oder eines SDK zu mobilen Anwendungen können Kunden jeden ihrer Besucher in einen virtuellen „Testagenten“ verwandeln. Radar löst gerätebasierte Messungen aus, indem es Referenzobjekte herunterlädt und interne und externe Infrastrukturen, Rechenzentren, Bereitstellungsnetzwerke und Cloud-Plattformen vergleicht, wie sie von den tatsächlichen Endbenutzern von Websites oder Webanwendungen wahrgenommen werden.

Hauptvorteile der Teilnahme

Radar begegnet mehreren Herausforderungen bei der Web-Bereitstellung durch seinen Ansatz zur Überwachung und Datenerfassung. Die Hauptvorteile der Teilnahme an der Radar-Community sind:

• Massive Testumgebung mit Endbenutzern in jedem Netzwerk an jedem Standort (bisher über 42.000 anerkannte Netzwerke).
• Gewinnung wichtiger Informationen über die Dienstanbieter vor dem Testen, um eine fundiertere Entscheidung zu treffen.
• Transparenz über die Leistung aktueller Anbieter und deren Verhalten in Regionen, in denen Sie Benutzer haben und nicht haben.
• Fokus auf die Metriken, die für Web- und Mobilbenutzer einen echten Unterschied machen (Leistung, Verfügbarkeit & QoS).
• Globaler (über 190 Länder) uneingeschränkter Einblick in Informationen bis auf Länder-, Netzwerk-, Regional- und Bundesstaatsebene.
• Echte, unvoreingenommene Daten durch die Nutzung von Endbenutzern. Radar-Daten sind “reale” Informationen und kein synthetischer Test oder eine Schätzung.
• Nicht alle Benutzer sind gleich: Verstehen Sie verschiedene Maschinen, Verbindungen und Geräte.
• Sichtbarkeit der Leistung tatsächlicher Seiten.

Benchmarks

ITM Radar bietet 3 Haupt-Benchmarks:

• Community-Benchmarking
• Privates Benchmarking
• Seitenlade-Benchmarking

Community-Benchmarking von CDN, Cloud und Rechenzentren

Community-Messungen werden über ein Crowdsourcing-Modell bezogen, das dem Kunden einen globalen Überblick über die Leistung und Verfügbarkeit eines Anbieters auf geografischer und logischer Ebene bietet. Die Community-Messungen ermöglichen Vergleiche der Qualität der Benutzererfahrung eines Anbieters aus Sicht des Endbenutzers und eine „Was-wäre-wenn“-Analyse bei der Bewertung von Anbietern und Lieferanten für die Verteilung von Inhalten und Anwendungen. Durch die Verwendung eines Crowdsourcing-Modells profitieren ITM-Kunden von einem höheren Grad an Granularität und Datenqualität bei der Bewertung und Überwachung der Anbieterleistung, selbst an Standorten, an denen ein Kunde möglicherweise keine hohe Benutzerdichte oder überhaupt keine Benutzer hat.

Die Messungen selbst verwenden einen Standardsatz von Objekten, die bei den verschiedenen Cloud- und CDN-Anbietern gespeichert sind und die Endbenutzer herunterladen, wenn sie den Radar JavaScript-Client oder die mobile SDK-Logik auf der Website oder Anwendung eines Inhaltseigentümers ausführen.

Die folgenden Metriken werden dann an ITM zurückgemeldet und innerhalb des Portals oder der API-Berichtsschnittstellen präsentiert:

• Verfügbarkeit – ob das Objekt geladen wird oder nicht.
• Antwortzeit – wie lange es dauert, bis der Server auf eine nachfolgende Anfrage antwortet, nachdem alle Störungen beim Aufbau einer Verbindung abgeschlossen sind. Dies ist eine relativ genaue Annäherung an die TCP-Roundtrip-Zeit (RTT) vom Browser zum Anbieter.
• Durchsatz – dies ist die Datenrate der Verbindung in Kilobit pro Sekunde, gemessen beim Abruf eines 100 KB großen Objekts.

Privates Benchmarking

Im Rahmen der Radar-Tag-Bereitstellung bietet ITM dem Kunden die Möglichkeit, eigene „Benchmark“-Tests zu erstellen, die von den Besuchern des Kunden gemessen werden. Dies kann für Rechenzentren oder eigene CDN- und Cloud-Verträge erfolgen. Wie bei den Community-Benchmark-Messungen werden dieselben Metriken bereitgestellt – Verfügbarkeit, Antwortzeit und Durchsatz –, die es dem Kunden ermöglichen, eine bestehende Content-Delivery-Strategie effektiv zu bewerten.

Diese privaten Informationen sind nur für den Kunden verfügbar und werden nicht geteilt. Beispiele für die Verwendung sind:

• Eigene Rechenzentrumsarchitektur(en)
• Verwendung eines eigenen Testobjekts oder einer eigenen Seite
• Verwendung eines eigenen Vertrags und Kontos bei einem bestimmten Anbieter oder einer Reihe von Anbietern

Radar-Seitenlade-Benchmarking

Innerhalb von Radar ITM hat der Kunde die Möglichkeit, detaillierte Informationen darüber einzusehen, wie die Seiten, auf denen der Tag implementiert ist, heruntergeladen werden. ITM stellt Informationen bereit, die es Ihnen ermöglichen, die Leistung zu sehen, die tatsächliche Endbenutzer beim Interagieren mit Ihren Webseiten erleben. Die Daten werden über die Navigation Timing API bereitgestellt, die von vielen neueren Browserversionen unterstützt wird.

Radar-Tag

Der Radar-Tag kann mithilfe eines JavaScript-Snippets integriert werden. Um zur Seite Radar-Tag zu navigieren, gehen Sie wie folgt vor:

1. Melden Sie sich beim NetScaler Intelligent Traffic Management Portal an.
2. Wählen Sie im linken Navigationsmenü Radar > Javascript-Tag.

Die Seite Radar-Tag wird geöffnet.

Wenn Sie den Radar-Tag noch nicht konfiguriert haben, sehen Sie oben auf dem Bildschirm eine orangefarbene horizontale Leiste, die Ihnen mitteilt, dass keine Radar-Messungen erkannt wurden.

Diese orangefarbene Leiste wird auch angezeigt, wenn der Tag nicht korrekt konfiguriert wurde.

Alternativ, wenn der Radar-Tag wie erwartet funktioniert, sehen Sie eine grüne horizontale Leiste, die Ihnen mitteilt, dass Radar-Messungen erfolgreich erfasst wurden.

Auf dieser Seite können Sie die für Ihre Nutzung zutreffende Tag-Version auswählen und in die Zwischenablage kopieren.

Hinweis: Es ist wichtig, dieses JavaScript-Snippet nicht zu ändern. Der Code enthält wichtige Informationen, die bei einer Änderung zu unerwartetem oder unzuverlässigem Verhalten führen können.

Integration des Radar-Tags

Die Integration des Radar-Tags ist relativ einfach. Sie müssen lediglich eines der unten stehenden JavaScript-Snippets zu Ihrem Seiten-Markup hinzufügen. Platzieren Sie es im HTML der Seiten, die Sie messen möchten. Wir empfehlen, es am Ende der Seite vor dem schließenden Body-Tag </body> zu platzieren.

Standard-Radar-Tag

Dies ist die empfohlene Version des Radar-Tags. Diese Version wartet, bis das Ladeereignis abgeschlossen ist, bevor der Radar-Client heruntergeladen und ausgeführt wird, wodurch sichergestellt wird, dass das Ladeereignis ununterbrochen bleibt.

<script>
if (typeof window.addEventListener === "function") {
    window.addEventListener("load", function() {
        if (window.cedexis === undefined) {
            var radar = document.createElement("script");
            radar.src = "//radar.cedexis.com/1/54621/radar.js"; // durch benutzerspezifischen Wert ersetzen
            document.body.appendChild(radar);
        }
    });
}
</script>
<!--NeedCopy-->

Diese Version des Tags verhindert, dass der Download des Radar-Clients das weitere Parsen der Seite blockiert, führt ihn aber aus, bevor das Ladeereignis ausgelöst wurde. Sie ist hauptsächlich für Kunden gedacht, die Content Security Policy-Einstellungen verwenden, die die Verwendung von Inline-JavaScript verhindern. Sie ist auch für Kunden gedacht, die das Video-QoS-Plug-in verwenden, bei dem der Radar-Client so früh wie möglich geladen werden muss.

<script src="//radar.cedexis.com/1/54621/radar.js" async></script>
<!--NeedCopy-->

Aktuelle Messungen

Die Tabelle Aktuelle Messungen ermöglicht es Ihnen, die neuesten Messungen anzuzeigen, die mit Radar durchgeführt wurden.

Klicken Sie auf die Schaltfläche Aktuelle Messungen. Sie erhalten folgende Informationen:

• Datum und Uhrzeit der Messung in UTC.
• Land, in dem die Messung durchgeführt wurde.
• Die Plattform, die für die Messung verwendet wurde.
• Die ID der Plattform.
• Die Art der Messung, d.h. Verbindungszeit (in Millisekunden), Antwortzeit (in Millisekunden) oder Durchsatz (in Kilobit pro Sekunde).
• Der tatsächliche Wert der Messung in Millisekunden (für Verbindungszeit und Antwortzeit) oder Kilobit pro Sekunde (für Durchsatz).

Die Radar-Messleiste wird auch auf der Radar-Dashboard-Seite angezeigt, wenn Sie sich zum ersten Mal im ITM-Portal anmelden.

Integration mit mobilen Apps

Die Integration mit mobilen Apps erfolgt über Wrapper um versteckte Webansichten, die den JavaScript-Client ausführen. Dies stellt sicher, dass die in Browsern und mobilen Apps gesammelten Daten konsistent sind.

Anweisungen zur Integration von Radar mit iOS-Apps Das folgende GitHub-Repository enthält den Wrapper-Code und Schritt-für-Schritt-Anweisungen zur Integration von Radar mit iOS-Apps:

Radar Runner für iOS

Anweisungen zur Integration von Radar mit Android Android Radar ist eine Client-Bibliothek, die die Integration von Radar in Android-Apps erleichtert. Sie finden sie hier:

AndroidRadar-Bibliothek

Integration mit NetScaler

Der Radar-Tag ist wichtig, da er Openmix mit Messungen versorgt, die es Openmix ermöglichen, bessere Routing-Entscheidungen zu treffen. Je mehr Webseiten den Tag verwenden, desto besser sind die Routing-Entscheidungen.

Die folgenden Methoden ermöglichen es Ihnen, den Radar JavaScript-Tag mithilfe von NetScaler in Ihre Webseite einzufügen. Sie können entweder die Befehlszeile oder das NetScaler Konfigurationsdienstprogramm verwenden.

Diese Methoden ermöglichen es Ihnen, den Radar-Tag in Ihre Antworten einzufügen. Um den Radar-Tag einzufügen, müssen Sie Umschreibungen verwenden. Umschreibungen gliedern sich in drei Schritte: Erstellen von Aktionen, Konfigurieren von Richtlinien und Binden von Richtlinien.

Befehlszeilenkonfiguration

Befehlszeilenkonfiguration der Rewrite-Aktion

Vorlage:

add rewrite action <name> <type> <target> [<stringBuilderExpr>] [-pattern <expression> | -search <expression>] [-refineSearch <string>] [-comment <string>]
<!--NeedCopy-->

Beispiel:

add rewrite action radar_tag action insert_after HTTP.RES.BODY(HTTP.RES.CONTENT_LENGTH).BEFORE_STR("</body>") '\"<script async src=\\"//radar.cedexis.com/1/<customer_id>/radar.js\\"></script>\"'
<!--NeedCopy-->

Hinweis: Fügen Sie Ihre eigene Kunden-ID an der Stelle ein, an der <customer_id> steht.

Befehlszeilenkonfiguration der Rewrite-Richtlinie

Vorlage:

add rewrite policy <name> <rule> <action> [<undefAction>] [-comment <string>] [-logAction <string>]
<!--NeedCopy-->

Beispiel:

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

Befehlszeilenbindung der Rewrite-Richtlinie

Vorlage 1:

bind vpn vserver <name> [-policy <string> [-priority <positive_integer>] [-secondary] [-groupExtraction] [-gotoPriorityExpression <expression>] [-type <type>]] [-intranetApplication <string>] [-nextHopServer <string>] [-urlName <string>] [-intranetIP <ip_addr> <netmask> ] [-staServer <URL> [-staAddressType ( IPV4 | IPV6 )]] [-appController <URL>] [-sharefile <string>]
<!--NeedCopy-->

Beispiel 1:

bind vpn vserver <name_of_vserver> -policy radar_tag_policy -type RESPONSE -priority 10
<!--NeedCopy-->

Vorlage 2:

bind cs vserver <name> (-lbvserver <string> | -vServer <string> | (-policyName <string> [-targetLBVserver <string>] [-priority <positive_integer>] [-gotoPriorityExpression <expression>] [-type ( REQUEST | RESPONSE )] [-invoke (<labelType> <labelName>) ] ) | (-domainName <string> [-TTL <secs>] [-backupIP <ip_addr|ipv6_addr|*>] [-cookieDomain <string>] [-cookieTimeout <mins>] [-sitedomainTTL <secs>]))
<!--NeedCopy-->

Beispiel 2:

bind cs vserver <name_of_vserver> -policyName radar_tag_policy -type RESPONSE -priority 10
<!--NeedCopy-->

Vorlage 3:

bind lb vserver <name>@ (<serviceName>@ [- weight <positive_integer>]) | <serviceGroupName>@ | (- policyName <string>@ [-priority <positive_integer>] [- gotoPriorityExpression <expression>] [-type ( REQUEST | RESPONSE )] [-invoke (<labelType> <labelName>) ] )
<!--NeedCopy-->

Beispiel 3:

bind lb vserver <name_of_vserver> -policyName radar_tag_policy -type RESPONSE -priority 10
<!--NeedCopy-->

Vorlage 4:

bind rewrite global <policyName> <priority> [<gotoPriorityExpression>] [-type <type>] [-invoke (<labelType> <labelName>) ]
<!--NeedCopy-->

Beispiel 4:

bind rewrite global radar_tag_policy 100 -type RES_DEFAULT
<!--NeedCopy-->

Konfiguration des GUI-Dienstprogramms

GUI-Rewrite-Aktion

1. Navigieren Sie im linken Navigationsmenü auf der Seite NetScaler-Konfiguration zu AppExpert -> Rewrite -> Rewrite Actions.
2. Wählen Sie die Schaltfläche Hinzufügen.
3. Geben Sie auf der Seite Rewrite-Aktion konfigurieren den Ausdruck wie im Beispiel gezeigt ein.
4. Geben Sie im Radar-Skript Ihre Kunden-ID in das Feld <customer_id> ein.
5. Wählen Sie OK. Sie haben die Erstellung Ihrer Rewrite-Aktion abgeschlossen.

GUI-Rewrite-Richtlinie

1. Navigieren Sie im linken Navigationsmenü auf der Seite NetScaler-Konfiguration zu AppExpert -> Rewrite -> Rewrite Policies.
2. Wählen Sie die Schaltfläche Hinzufügen.

3. Geben Sie auf der Seite Rewrite-Richtlinie konfigurieren den Ausdruck wie im Beispiel gezeigt ein.

   

4. Klicken Sie auf Erstellen.

Sie haben die Konfiguration der Rewrite-Richtlinie abgeschlossen.

GUI-Bindung der Rewrite-Richtlinie

Nachdem Sie Ihre Richtlinie konfiguriert haben, ist der letzte Schritt, die Richtlinie mithilfe des Policy Managers zu binden.

1. Gehen Sie zur Seite Rewrite-Richtlinien.
2. Wählen Sie die Rewrite-Richtlinie aus, die Sie für den Radar-Tag erstellt haben.

3. Gehen Sie zum Policy Manager.

   

4. Auf der Seite Policy Manager können Sie die Richtlinie wie folgt binden:

   • Für Bindungspunkt haben Sie die Möglichkeit, Global überschreiben, VPN Virtual Server, Content Switching Virtual Server oder Load Balancing Virtual Server auszuwählen.
   • Für Protokoll wählen Sie HTTP.
   • Für Verbindungstyp wählen Sie Antwort.
   • Für Virtual Server verwenden Sie Ihren eigenen Virtual Server-Namen.

   

   • Klicken Sie auf Weiter.
   • Wählen Sie auf der nächsten Seite die zuvor erstellte Rewrite-Richtlinie aus.
   • Fügen Sie Bindungsdetails hinzu.
   • Klicken Sie auf Binden.

   

Mit den oben genannten Methoden können Sie den Radar-Tag in Ihre Webseiten einfügen. Es ist jedoch zu beachten, dass dies eine grundlegende Implementierung ist. Eine weitere Filterung kann vorgenommen werden, um die Seiten, auf denen der Tag implementiert ist, besser zu steuern.

Radar-Tag-Konfiguration

Sie können Radar auf der Seite Radar-Tag-Konfiguration konfigurieren.

1. Melden Sie sich beim NetScaler Intelligent Traffic Management Portal an.
2. Wählen Sie im linken Navigationsmenü Radar > Tag-Konfiguration.

Die Seite Radar-Tag-Konfiguration wird geöffnet. Hier können Sie verschiedene Optionen zur Anpassung der Radar-Messungen festlegen. Das Radar-JavaScript verfügt über Parameter, die Sie anpassen können, um Timing- und Verzögerungselemente, die Anzahl der von Endbenutzern durchgeführten Tests für Community- und private Messungen sowie Timeout-Werte zur Messung der Verfügbarkeit usw. anzupassen.

Die folgende Tabelle enthält Informationen zu den Konfigurationsoptionen und den Standardeinstellungen für jede Option. Wenn Sie Änderungen vornehmen, klicken Sie unbedingt unten auf dem Bildschirm auf Radar-Einstellungen aktualisieren, um die Änderungen zu übernehmen.

*„Auto“ bedeutet, dass NetScaler Intelligent Traffic Management basierend auf dem Standort des Endbenutzers bestimmt, wie viele Plattformen für eine bestimmte Sitzung gemessen werden müssen. Wir versuchen, mehr Plattformen pro Sitzung für kleine Netzwerke zu messen, wo die Daten spärlich sind, anstatt für große Netzwerke, wo sie dicht sind.

**Dies ist die maximale Anzahl der pro Sitzung versuchten Messungen. Zum Beispiel kann Radar 4 private Plattformen pro Sitzung messen, wobei alle so konfiguriert sind, dass sie sowohl RTT als auch Durchsatz messen. Wenn jedoch „Maximale private Durchsatzmessungen“ auf 2 gesetzt ist, stoppt der Client die Einbeziehung der Durchsatzmessungen nach der Messung der ersten 2 privaten Plattformen. Für die letzten beiden Plattformen wird nur RTT gemessen.

Timing-Optionen ermöglichen es Ihnen, die Zeitspanne festzulegen, die Radar warten muss, bevor es mit der Durchführung von Messungen beginnt.

Hinweis: Startverzögerung ist in Sekunden, während Wiederholungsverzögerung in Minuten angegeben wird.

Protokolloptionen

Normalerweise misst der Radar-Client nur Plattformen mit URLs, deren Protokolle denen der Seite entsprechen, auf der er ausgeführt wird. Diese Optionen ermöglichen es Ihnen, dieses Verhalten für private Plattformen zu überschreiben. Zum Beispiel ermöglicht die Aktivierung von „Private HTTPS-Messungen immer zulassen“ dem Client, https://myprovider.com/r20.gif von http://example.com aus zu messen, während „Private HTTP-Messungen bei HTTPS-Verbindungen zulassen“ dem Client ermöglicht, http://myprovider.com/r20.gif von https://example.com aus zu messen.

Diese Optionen sollten im Allgemeinen vermieden werden, außer in extremen Anwendungsfällen. Der beste Weg, um eine ausreichende Dichte privater Messungen zu gewährleisten, besteht darin, Ihre Plattformen so zu konfigurieren, dass sie die Plattformen und Protokolle messen, die Sie tatsächlich in der Produktion verwenden (und nicht mehr), und den Radar-Tag auf so vielen Produktionsseiten wie möglich bereitzustellen. Wir bezeichnen dies manchmal als „Radar dort platzieren, wo es benötigt wird“.

Die Abtastrate ermöglicht es Ihnen, einen Prozentsatz der Webseiten (von Benutzern angesehen) festzulegen, von denen Messungen gesammelt werden sollen. Wenn Ihre Website beispielsweise 100.000 Seitenaufrufe pro Tag erhält und Sie eine Abtastrate von 5 % festlegen, sammelt Radar nur Messungen von 5 % der 100.000 Seitenaufrufe.

Private Messungen

Diese Einstellungen gelten für Messungen Ihrer privaten Plattformen. Private Plattformen sind solche, die Sie im Abschnitt Plattformen einrichten, um bestimmte CDNs, Cloud-Anbieter und andere Teile Ihrer Infrastruktur zu messen. Weitere Informationen finden Sie im Abschnitt Plattformen.

Diese Option ermöglicht es Ihnen, das Verhalten von Radar bei der Bereitstellung von Informationen an die Community zu konfigurieren.

Radar-Tests deaktivieren

Wenn es erforderlich ist, Radar-Messungen schnell zu deaktivieren, falls etwas Unerwartetes auftritt, können Sie dies im Portal tun, um Notfall-Codeänderungen an Ihrer Website zu vermeiden.

Deaktivieren Sie auf der Seite Radar-Tag-Konfiguration die privaten Messungen, Community-Messungen oder beides, indem Sie den Umschalter Aktiviert auf Deaktiviert klicken.

Klicken Sie auf Radar-Konfiguration speichern, um die Änderungen zu bestätigen. Die Änderungen können ein oder zwei Minuten dauern, bis sie sich verbreiten, danach stoppen die Radar-Messungen.

Radar-Client-Methodik

Eine grundlegende Dimension des Client-Verhaltens ist die Sitzung. Alle Daten, die der Client sendet, sind mit einer Sitzung verknüpft. Sitzungen werden durch einen Aufruf an NetScaler® ITM-Server erstellt, der als Initialisierungsanfrage bezeichnet wird. Sitzungen verfallen ziemlich schnell, was dazu beiträgt, dass nur gültige Radar-Daten akzeptiert werden. Aufgrund dieser Funktion erfolgen Radar-Messungen immer in Batches, die mit ihrer Sitzungstransaktions-ID verknüpft sind, und wir sprechen oft von einer „Radar-Sitzung“, um die damit verbundenen Messungen zu beschreiben.

Radar-Sitzung

Eine Radar-Sitzung ist die Haupteinheit der Arbeit, die der Client ausführt. Sie besteht aus einer Anfrage an NetScaler ITM-Server, um die Kundenkonfiguration und eine Reihe von zu messenden Plattformen zu erhalten, gefolgt von Anfragen zur Messung dieser Plattformen und zur Berichterstattung der Ergebnisse. Diese erfolgen asynchron und serialisiert, sodass immer nur eine Anfrage gleichzeitig stattfindet. Eine typische Sitzung ist in weniger als 10 Sekunden abgeschlossen.

Sondentypen

Jeder Bericht, den der Client sendet, hat einen zugehörigen Sondentyp, der dem System mitteilt, um welche Art von Messung es sich handelt und wie sie zu behandeln ist. Er gibt auch die Arten der durchzuführenden Messungen an, die Verfügbarkeit, Roundtrip-Zeit, Durchsatz oder andere Metriksammlungen umfassen können.

Es besteht ein wichtiger Zusammenhang zwischen Verfügbarkeit und Leistungsmessung (wie Roundtrip-Zeit und Durchsatz). Die Verfügbarkeit einer bestimmten Ressource wird in jeder Messsitzung immer zuerst gemessen. Nur wenn die Verfügbarkeitsmessung erfolgreich ist, können in derselben Sitzung zusätzliche Leistungsmessungen derselben Ressource durchgeführt werden.

Wenn ein besonders langsames Netzwerk einen Verfügbarkeitsausfall erleidet, kann dies dazu führen, dass sich die Gesamtleistung von Berichten, die dieses Netzwerk enthalten, tatsächlich verbessert. Dies ist nur ein Berichtsartefakt, da NetScaler Intelligent Traffic Management immer die granularsten, netzwerkspezifischen Leistungsdaten für Echtzeitentscheidungen verwendet.

Verfügbarkeit

Verfügbarkeit, auch bekannt als Kaltstart-Sonden, sollen Diensten ermöglichen, ihre Caches aufzuwärmen. Obwohl mit dieser Sonde ein Messwert verbunden ist, verwenden wir die Verfügbarkeitssonde, um festzustellen, ob der Anbieter verfügbar ist.

Wenn eine Plattform nicht für die Durchführung einer Kaltstart-Sonde konfiguriert ist, verwenden wir die Ergebnisse der RTT-Sonde anstelle eines Kaltstartberichts, um Verfügbarkeitsmetriken bereitzustellen.

Ähnlich verhält es sich bei dynamischen Objekten, die Site-Beschleunigungsdienste messen: Der Client lädt das kleine Testobjekt einmal herunter und meldet den Messwert sowohl für den Kaltstart als auch für die Antwortzeit.

RTT

Durchsatz

Testobjekte

Testobjekte sind Dateien, die auf Plattformen gehostet und vom Client heruntergeladen werden, um Messungen zu generieren. Dieser Abschnitt beschreibt die verschiedenen Arten von Testobjekten, die der Client unterstützt. Nicht alle Objekttypen gelten für jede Plattform.

Erforderlicher Header:

Der Timing-Allow-Origin-Antwortheader ist erforderlich, um JavaScript den Zugriff auf die von der Resource Timing API bereitgestellten Low-Level-Timing-Daten zu ermöglichen. Die empfohlene Einstellung ist Timing-Allow-Origin: *, was bedeutet, dass JavaScript, das auf jeder Domäne ausgeführt wird, die Berechtigung zum Zugriff auf die Timing-Daten der Ressource erteilt werden muss.

Standard

Die Standard-Testobjekte sind Medien, die der Client herunterlädt, indem er das src-Attribut eines Image-Objekts setzt. Nach dem Download verwendet der Client die Resource Timing API, um Leistungsdaten zu sammeln. Diese Testobjekte müssen mit dem Timing-Allow-Origin-Antwortheader bereitgestellt werden. Weitere Informationen finden Sie im Abschnitt Timing-Allow-Origin Header.

Standard Klein

Das standardmäßige kleine Testobjekt ist eine Ein-Pixel-Bilddatei, die verwendet wird, wenn der Client eine leichte Netzwerkanfrage stellen muss.

Das standardmäßige kleine Testobjekt wird in den folgenden Anwendungsfällen verwendet:

• Nicht-dynamische Kaltstart-Sonden
• Nicht-dynamische Roundtrip-Zeit-Sonden

Standard Groß

Das standardmäßige große Testobjekt ist eine 100 KB große Bilddatei, die zur Messung des Durchsatzes einer Plattform verwendet wird.

Benennung großer Objekte: Um den Durchsatz zu berechnen, muss der Client die Größe des Testobjekts kennen. Der Client bestimmt den Dateinamen, indem er nach „KB“ im Dateinamen sucht; zum Beispiel r20-100KB.png. Kunden können Bilddateien unterschiedlicher Größe messen, solange der Name die Dateigröße auf die gleiche Weise enthält, zum Beispiel myimage-2048kb.jpg.

Dynamisch

Dynamische Testobjekte werden verwendet, um die Leistung im Zusammenhang mit Site-Beschleunigungsdiensten zu messen. Jedes ist eine HTML-Datei, die JavaScript enthält, das Zeitstempel von der Navigation Timing API sammeln und an die übergeordnete Seite senden kann. Der Client lädt das Testobjekt mithilfe eines Iframes herunter und erhält diese Zeitstempel, die er zur Berechnung von Messungen verwendet.

Sicherheit und Validierung

Das Testobjekt ist ein 40 KB großes Objekt. Eine neue Funktion des Testobjekts ist ein HMAC (Hash-basierter Nachrichtenauthentifizierungscode), den es basierend auf Abfrageparametern und einem geheimen Schlüssel bereitstellt, auf den der Server Zugriff hat. Dieser HMAC wird mit unserer Messung zurückgesendet, was uns ermöglicht zu validieren, dass der Radar-Client auf das Testobjekt zugreifen konnte und nichts zwischengespeichert wurde.

Unterschied zwischen dynamischen und Standard-Testobjekten:

Bei Standard-Radar-Messungen versuchen wir, nur die primäre Anforderungsaktivität im Zusammenhang mit dem Herunterladen von Testobjekten zu isolieren, während es bei Site-Beschleunigungsdiensten unser Ziel ist, mehr von der Aktivität zu messen. Daher sind auch DNS-Lookup- und Verbindungszeit enthalten. Dynamische Messungen sollen auch die Anforderungsleistung beim Zugriff auf den Dienstursprung messen, nicht nur einen Edge-Cache.

Im Portal können Sie diese Methodik wie folgt auswählen:

• Gehen Sie im linken Navigationsmenü zu Plattformen.
• Klicken Sie auf das Symbol Plattform hinzufügen in der oberen rechten Ecke der Seite.
• Gehen Sie zu Private Plattform > Kategorie > Dynamischer Inhalt.
• Klicken Sie im Dialogfeld Radar-Testobjekte auf das Kontrollkästchen Sonden anpassen.
• Geben Sie die URL für die Antwortzeit ein und wählen Sie Webseite Dynamisch aus der Dropdown-Liste Objekttyp.

Das dynamische kleine Testobjekt wird verwendet, um die Verfügbarkeit und Roundtrip-Zeit mit derselben Sonde für Site-Beschleunigungsdienste zu messen.

iNav

Das iNav-Testobjekt ist eine statische HTML-Datei, die JavaScript enthält, das eine Reihe von Aufgaben ausführen kann. Der Client gibt an, welche Aufgabe ausgeführt werden soll, indem er Abfragezeichenfolgenparameter in die URL aufnimmt, die die HTML-Datei in einem Iframe lädt. Das iNav-Testobjekt unterstützt die folgenden Anwendungsfälle:

• iNav-Kaltstart
• iNav-Roundtrip-Zeit

iUNI

Das iUNI-Testobjekt wird verwendet, um den UNI-Wert zu erkennen, der mit einer Reihe von Radar-Messungen für eine Plattform verbunden ist (die andere Methode ist CORS AJAX, die kein separates Testobjekt erfordert).

AJAX GET

Die AJAX GET-Methodik kann im Allgemeinen mit jeder URL verwendet werden, die der Kunde messen möchte, vorausgesetzt, sie wird mit dem Timing-Allow-Origin-Header und einem geeigneten Access-Control-Allow-Origin-Header bereitgestellt. Im Portal können Sie diese Methodik wie folgt auswählen:

• Gehen Sie im linken Navigationsmenü zu Plattformen.
• Klicken Sie auf das Symbol Plattform hinzufügen in der oberen rechten Ecke der Seite.
• Gehen Sie zu Private Plattform > Kategorie > Dynamischer Inhalt.
• Klicken Sie im Dialogfeld Radar-Testobjekte auf das Kontrollkästchen Sonden anpassen.
• Geben Sie die Antwortzeit ein und wählen Sie AJAX (GET) aus der Dropdown-Liste Objekttyp.

Timing-Allow-Origin-Header

Der Timing-Allow-Origin-Antwortheader ist erforderlich, um JavaScript den Zugriff auf die von der Resource Timing API bereitgestellten Low-Level-Timing-Daten zu ermöglichen. Die empfohlene Einstellung ist Timing-Allow-Origin: *, was bedeutet, dass JavaScript, das auf jeder Domäne ausgeführt wird, die Berechtigung zum Zugriff auf die Timing-Daten der Ressource erteilt werden muss.

Radar-APIs

Radar bietet APIs sowohl für Betriebs- als auch für Datenabruffunktionen.

• Operations-API – Hinzufügen/Bearbeiten/Löschen von Radar-Konten und die Kontrollmechanismen zur Verwaltung Ihres Kontos über eine API
• Radar-Daten-API – Die ITM Radar-Daten-API bietet Aggregate der öffentlichen Community- und privaten Messdaten von Radar. Die Daten werden kontinuierlich aktualisiert und etwa alle 60 Sekunden für den Abruf über die API gebündelt. Die Daten-API wird bereitgestellt, um Kunden die Integration von Radar-Daten in ihre eigenen Berichte und Dashboards zu ermöglichen. Ein einziger API-Aufruf kann Radar-Quartil- oder Mittelwert-Messdurchschnitte für alle Länder und bis zu 30 interessierende ASNs für jede Plattform liefern.

Radar-Berichte

Radar-Berichte bieten eine leistungsstarke Einsicht in die dynamischen Daten, die über den Radar-Tag gesammelt werden.

Radar-Mitglieder erhalten Zugang zu einem umfangreichen Datensatz, der über intuitive interaktive Diagramme präsentiert wird. Der gesammelte Datensatz umfasst sowohl den vollständigen öffentlichen Datensatz von Milliarden von Messungen als Kontext für private Daten, die von einem Radar-Tag oder einer mobilen SDK-Bereitstellung eines Kunden gesammelt wurden. Informationen zur Seitenladezeit werden mit dem eigenen Tag des Kunden erfasst und bieten tiefe Einblicke in die tatsächliche Leistungserfahrung Ihrer Website- und mobilen Anwendungs-Endbenutzer.

Zusätzlich zu den Leistungsmetriken bieten Radar-Berichte Einblicke in viele Aspekte Ihrer Endbenutzer-Zielgruppe, einschließlich: Volumina, Geografien, Benutzeragenten, Betriebssystemtypen und den Zeitpunkt ihrer Nutzung Ihrer Website oder mobilen Anwendung.

Jeder Bericht ist unten definiert, aber hier sind wichtige Aspekte aller Berichte:

Primäre und sekundäre Dimensionen

Die primäre Dimension des Diagramms wird über eine Auswahlliste oberhalb des Diagramms ausgewählt. Nutzen Sie dies als leistungsstarken Pivot für den Bericht. Eine sekundäre Dimension kann ebenfalls ausgewählt werden, um die Berichterstattung weiter zu verfeinern.

Umschalter für Visualisierungshintergrund

Diagramme sind standardmäßig auf einen weißen Hintergrund eingestellt. Schalten Sie den Hintergrund für Monitore mit hohem Kontrast mit dem Hintergrund-Umschalter auf eine dunkle Farbe um.

Datenexport

Zusätzlich kann der Endbenutzer die Diagramm- und Tabellendaten über den Download-Link oben im Bericht herunterladen.

Filter: Berichtszeitraum

Die Radar-Berichte können mit einem Zeitraum von Letzte 60 Minuten, Letzte 24 Stunden, Letzte 48 Stunden, Letzte 7 Tage, Letzte 30 Tage oder einem benutzerdefinierten Bereich generiert werden. Die Standardansicht ist die Letzten 24 Stunden.

Filter: Plattform und Standort

Die Berichte variieren leicht in Bezug auf die geeigneten Filter, basierend auf den Daten. Die häufigsten sind:

• Plattform – Wählen Sie eine oder mehrere Plattformen (Anbieter) aus, die eingeschlossen werden sollen.
• Kontinent – Wählen Sie einen oder mehrere Kontinente aus, die eingeschlossen werden sollen.
• Land – Wählen Sie ein oder mehrere Länder aus, die eingeschlossen werden sollen.
• Region – Wählen Sie eine oder mehrere geografische Regionen (falls zutreffend) aus, die eingeschlossen werden sollen.
• Bundesstaat – Wählen Sie einen oder mehrere geografische Bundesstaaten (falls zutreffend) aus, die eingeschlossen werden sollen.
• Netzwerk – Wählen Sie ein oder mehrere Netzwerke (ASN) aus, die eingeschlossen werden sollen.

Filter: Ressourcen

• Datenquelle – Schließen Sie Daten aus der gesamten Radar-Community oder nur von Ihren Website-Besuchern ein.
• Standortquelle – Wählen Sie die Client-IP oder die Resolver-IP als Ihre Standortquelle aus.
• Radar-Client-Typ – Wählen Sie den Radar-Client-Typ als JavaScript-Tag, iOS SDK oder Android SDK aus.

Mein Seitenaufrufe Geo-Standortbericht

Dieser Bericht zeigt das Volumen der Seitenaufrufe für jedes Land. Diese Kartenansicht kann über die Zeit (basierend auf dem für den Bericht gewählten Zeitraum) durch Auswahl der Schaltfläche „Wiedergabe“ am unteren Rand des Diagramms angezeigt werden.

Leistungsbericht

Dieser Bericht zeigt den Leistungstrend für jede der definierten Plattformen.

Bericht zur statistischen Verteilung

Dieser Bericht zeigt die statistische Aufschlüsselung für jede der für das Konto definierten Plattformen.

Geo-Standortbericht für einzelne Plattform

Dieser Bericht zeigt die Verteilung des Radar-Traffics nach Ländern im Zeitverlauf für jeweils eine einzelne Plattform.

Bericht zur statistischen Verteilung für einzelne Plattform

Dieser Bericht zeigt die Verteilung des Radar-Traffics im Zeitverlauf nach Antwortzeit.