Überwachung der Netzwerkerfahrung
Übersicht
Der Citrix Network Experience Monitoring Service (NEM) (früher Netscope) ermöglicht Dienstanbietern, Unternehmen, ISPs und Drittanbietern den Zugriff auf detaillierte Radarmessprotokolle und Standardberichte in Form von zusammengefassten verwertbaren Daten. NEM bietet mehrere Standardprotokolle und Berichte an, mit denen Kunden die Qualität ihrer Dienste messen können.
Diese Lösung umfasst die Bereitstellung von “rohen” Radarmessungen und den Zugriff auf die Citrix ITM Data API. NEM stellt sowohl die granularen Daten (als Rohmessungen oder Datenaggregate) als auch Datenschwellenwarnungen bereit. Diese Services helfen bei der Erkennung, Isolierung der Plattformverfügbarkeit und Performanceprobleme bei Plattformkollegen und den zugrunde liegenden ISPs.
“Raw” -Radarmessungen: Radarmessungen liefern pro Ereignis granulare Informationen, die täglich gechargt werden. Radarmessungen umfassen öffentliche, gemeinschaftliche und private Messdaten, die vom Tag erfasst werden. Daten wie Verfügbarkeit, Reaktionszeit, Durchsatz für HTTP- und HTTPS-Messungen sind enthalten. Die folgenden Datenfelder werden bereitgestellt:
- Anbieter-ID, Resolver-IP, verschleierte (/28) Client-IPs
- Verschleierter Referrer-Header, Benutzeragent, Endbenutzer-ASN
- Geodaten für Resolver- und Kundenfelder
Radar-Metriken, die in den “Raw” -Messungen verfügbar sind, sind:
- Verfügbarkeit, Reaktionszeit und Durchsatz (wenn gemessen)
- DNS-Suchzeit (optional), TCP-Verbindungszeit (optional) und sichere Verbindungszeit (optional)
- Latenz (optional)
- Downloadzeit (optional)
Radarmessungen sind verfügbar, damit Kunden die gesammelten Daten selbst analysieren können. Der Datensatz enthält Informationen zur Providerleistung und -verfügbarkeit (Fehler) für eine Reihe von Kommunikationsprotokollen.
Protokolldateidaten sind 7 Tage lang über einen AWS S3 oder Google Cloud Storage-Bucket verfügbar. Kunden können Protokolldateien von Community- und privaten Daten mithilfe von Standard-Bucket-Zugriffsmethoden abrufen.
“Raw” -Messungen in Echtzeit (optional): Raw-Radar-Messungen werden in Echtzeit an einen AWS S3-Bucket geliefert. Diese Protokolle sind in der Regel innerhalb von 5 Minuten nach der Erfassung verfügbar. Sie bieten so viel Granularität wie die zuvor erwähnten Radar-Rohmessungen.
Daten-API: Die Citrix ITM Radar-Daten-API stellt Aggregate der öffentlichen Gemeinschaft und private Messdaten zur Verfügung. Die Daten werden kontinuierlich aktualisiert und etwa alle 60 Sekunden gestapelt, um sie von der API abzurufen. Die Daten-API wird bereitgestellt, damit Kunden Radar-Daten in ihre eigenen Berichte und Dashboards integrieren können.
Teilen von Protokollen und
- Radarprotokolle können in Echtzeit und täglich geliefert werden.
- Berichte werden täglich ausgeführt.
- Die Ergebnisse werden in AWS S3 (S3) oder Google Cloud Storage (GCS) gespeichert.
- Protokolle und Berichte haben beide eine Aufbewahrungsfrist von 7 Tagen und werden automatisch eine Woche nach der Erstellung gelöscht.
- Berichte liegen normalerweise je nach Berichtstyp im TSV- (tabulatorseparierter Wert) oder JSON-Format vor.
Kunden erhalten Anmeldeinformationen für den Zugriff auf die S3- und GCS-Buckets. Für die Anmeldung kann ein Befehlszeilentool wie s3cmd oder die AWS-CLI für S3 oder gsutil für GCS verwendet werden. Die S3cmd-Konfigurationsdatei erkennt die über die Portal-Benutzeroberfläche erhaltenen Zugriffsschlüssel und hilft dem Benutzer, sich mit dem S3-Bucket zu verbinden.
Die AWS CLI muss auf dem Computer des Kunden installiert werden, um eine Verbindung mit S3 herzustellen und auf die Protokolle zuzugreifen. Für GCS erhält der Kunde die Zugriffsschlüsseldatei als Download über die Portal-Benutzeroberfläche, die mit dem gsutil-Tool verwendet werden kann. Weitere Informationen finden Sie in den häufig gestellten Fragen.
Kunden erhalten E-Mail-Benachrichtigungen, sobald Berichte verfügbar sind.
Plattformeinstellungen
Sie müssen Ihre Plattform so konfigurieren, dass die für Netscope NEM erforderlichen Daten unterstützt und erstellt werden. Bevor Sie beginnen, stellen Sie sicher, dass die folgenden Einstellungen für Ihre Plattform aktiviert sind:
- Aktivieren Sie für Anonyme beste Berichte die Einstellungen für die Radarsonde.
- Aktivieren Sie für Anonymous Best RTT Reaktionszeit und Verfügbarkeit.
- Aktivieren Sie für den besten anonymen Durchsatz die Option Durchsatz und Verfügbarkeit.
- Aktivieren Sie für Cache-Knoten-ID-Berichte die Radarsondeneinstellungenund aktivieren Sie unter Erweiterte Radareinstellungendie Knoten-ID.
- Aktivieren Sie für Details zum Ressourcen-Timing die Option Zeitstempel in den erweiterten Radar
Navigation
Wählen Sie im Hauptmenü Netscope NEMaus. Die Seite Konfiguration der Network Experience Monitoring wird geöffnet.
Plattformen und Netzwerke
Wählen Sie die erforderlichen Plattformen oder Netzwerke (oder beide) aus, um den Konfigurationsprozess zu starten.
HINWEIS:
Protokolle und Berichte können nur konfiguriert und generiert werden, wenn mindestens eine Plattform oder ein Netzwerk ausgewählt ist.
Die zusammengefassten Daten, die der Kunde erhält, umfassen Radarmessungen von ausgewählten Plattformen (für alle zugehörigen Netzwerke) oder ausgewählte Netzwerke (für alle zugehörigen Plattformmessungen).
Auswählen von Plattformen
Wählen Sie für Content Service Provider oder Unternehmen Plattformen wie CDNs, Clouds, Rechenzentren oder andere Endpunkte aus. Wählen Sie Plattformen aus, für die Messungen erforderlich sind.
Netzwerke auswählen
Wählen Sie für ISPs die Netzwerke aus der Liste aus, die verschiedenen Plattformen oder Endpunkten zugeordnet ist, für die Messungen erforderlich sind.
HINWEIS:
Wenn Sie die erforderliche Plattform nicht in der Liste finden, können Sie sie im Abschnitt Platform des Portals konfigurieren. Wenden Sie sich für nicht verfügbare Netzwerke an das Support-Team .
Plattformberichte
Es gibt vier Arten von Plattformberichten:
- Anonym Best for Round Trip Time (RTT)
- Anonym Best for Through
- Cache-Knoten-ID
- Stündlich nach Land/ASN
Eine Beschreibung der Protokolle finden Sie unter Radarprotokollbeschreibungen und Berichte für Dienstanbieter und Unternehmen.
Plattformberichte aktivieren
Klicken Sie auf den Umschalter, um die Berichte, die Sie erhalten möchten, zu aktivieren oder zu deaktivieren. Wenn Sie einen vorhandenen Bericht deaktivieren, werden keine neuen Protokolle generiert, aber alte Berichte bleiben am aktuellen Speicherort.
Anonymer Bester Bericht für Plattformen
- Diese Berichte helfen Anbietern dabei, ihre Leistung mit der von anderen Plattformen innerhalb ihrer Peer-Gruppe, d. h. innerhalb desselben Landes, derselben Region oder ASN zu vergleichen.
- Die Leistungsdaten der 15 wichtigsten Anbieter in der Peer-Group werden auf der Grundlage derselben Kategorien aggregiert. Der beste Wert wird neben dem besten Wert des jeweiligen Anbieters aufgeführt.
- Anonymer Best Report für SSL-Plattformen ist verfügbar, damit ihre Leistung mit anderen SSL-Plattformen verglichen werden kann.
- Die Client-IPs werden auf /28 gekürzt.
- Die Ergebnisse des “besten” Anbieters helfen Clouds/CDNs dabei, ihre Leistung auf hochvolumige oder geschäftskritische ASNs zu konzentrieren, die für ihre Mitbewerber wettbewerbsschwach sind.
- Der Bericht enthält Details zur Leistung, aufgeschlüsselt nach DNS-Resolver-IP, Client-IP /28 und dem Caching-Knoten, der die Objekte bedient hat. Dasselbe wird mit der “besten” Plattform für dieselben Kriterien verglichen.
Verfügbar für RTT und Durchsatz.
- Beschreibungen der Protokolle finden Sie unter Radarprotokollbeschreibungen und Berichte für Service Provider and Enterprises.
Cache-Knoten-ID-Bericht für Plattformen
- Dieser Bericht wird verwendet, um den spezifischen Server oder das Datencenter zu identifizieren, das auf eine Anfrage reagiert hat, und hilft bei der Diagnose von Serverproblemen.
- Es liefert die ID des Rechenzentrums oder der Maschine, die auf eine bestimmte Anfrage geantwortet hat.
- Es hilft zu verstehen, warum die Leistung über einen bestimmten Knoten (POP oder Maschine oder Knoten-ID) gut oder schlecht war.
- Die Leistung besteht aus Reaktionszeit, Durchsatz, Verfügbarkeit (Probentyp), der DNS-Resolver-IP, Client IP /28 und dem Caching-Knoten, der die Objekte bedient hat.
- Protokollbeschreibungen finden Sie unter [Radarprotokollbeschreibungen und -berichte für Service Provider and Enterprises] (#radar -log-descriptions-and-reports-for-service-providers-and-enterprises)
Stündlich nach Land/ASN
- Mit diesem Bericht können Sie überprüfen, ob die Leistung Ihrer Anbieter im Laufe eines Tages erheblich variiert.
- Es zeigt die Zeit, zu der die Messungen auf die Stunde abgeschnitten wurden, zum Beispiel
2018-03-11T23:00:00
. - Beschreibungen der Protokolle finden Sie unter Radarprotokollbeschreibungen und Berichte für Service Provider and Enterprises.
Netzwerkberichte
Es gibt drei Arten von Netzwerkberichten:
- Anonym Best for Round Trip Time (RTT)
- Anonym Best for Through
- Subnetz
Eine Beschreibung der Protokolle finden Sie unter Radarprotokollbeschreibungen und Berichte für ISPs.
Netzwerkberichte aktivieren
Klicken Sie auf den Umschalter, um die Berichte, die Sie erhalten möchten, zu aktivieren oder zu deaktivieren. Wenn diese Option deaktiviert ist, werden keine neuen Protokolle mehr generiert, aber alte Berichte sind vorhanden. Um einen Subnetzbericht zu generieren, geben Sie die spezifischen Subnetze Ihrer Netzwerke ein. Wenn keine Subnetze eingegeben wurden, werden Berichte mit dem ASN-CIDR-Block als Standardsubnetz generiert.
Anonymer Bester Bericht für ISPs
- Im Bericht Anonymous Best für ISPs wird eine Peer-Group für den “besten” Vergleich verwendet. Die Peer-Gruppe basiert auf dem Standort des ISP. Normalerweise sind es die 10 am häufigsten gemessenen ISPs in einem bestimmten Land mit einem Minimum von über 1.000 Sitzungen.
- Die Ergebnisse des “besten” ISP helfen ISPs dabei, ihre Leistungsbemühungen auf hochvolumige oder geschäftskritische Plattformen und Bereiche zu konzentrieren, die gegenüber ihren Mitbewerbern wettbewerbsschwach sind.
- Der Bericht enthält Details zur Leistung, aufgeschlüsselt nach Geographie und Plattform, und vergleicht sie mit dem “besten” ISP für dieselben Kriterien.
- Verfügbar für RTT und Durchsatz.
- Eine Beschreibung der Protokolle finden Sie unter Radarprotokollbeschreibungen und Berichte für ISPs.
Subnetzbericht für ISPs
- Dieser Bericht liefert ISPs Informationen darüber, wie sich die spezifischen Subnetze ihrer Netzwerke für Benutzer über die von uns gemessenen Plattformen verhalten.
- Es enthält Informationen über den Dienstanbieter, der auf eine bestimmte Anforderung geantwortet hat.
- Es hilft, die Leistung eines Netzwerksubnetzes zu verstehen.
- Die Leistung besteht aus Reaktionszeit, Durchsatz, Verfügbarkeit (Probentypen), der DNS-Resolver-IP, Client IP /28 und dem Subnetz des Benutzers.
- Eine Beschreibung der Protokolle finden Sie unter Radarprotokollbeschreibungen und Berichte für ISPs.
Radarprotokolle
- Radarprotokolle sind für Plattformen und Netzwerke verfügbar.
- Sie enthalten eine Teilmenge der Felder, die in den Rohprotokollen verfügbar sind, mit einigen Daten anonymisiert: Client IP /28, Referer MD5-Hash.
- Jede Messung für öffentliche Plattformen wird bereitgestellt, unabhängig von der Seite, auf der die Messung generiert wurde.
HINWEIS:
NEM stellt niemals vollständige Client-IPs bereit. Stattdessen wird /28 offen gelegt. Beispielsweise wird eine IP von 255.255.255.255 in einem Bericht als 255.255.255.240/28 angezeigt.
Protokollfrequenz
Radarprotokolle können täglich (alle 24 Stunden) erstellt werden, d.h. am Ende des Tages, UTC-Zeit. Protokolle können auch in Echtzeit (Minute für Minute) generiert werden.
Datei-Format
Wählen Sie TSV oder JSON, um Protokolle und Berichte in einem dieser Formate zu empfangen.
Messungstyp
Sie können Protokolle für die folgenden Messarten konfigurieren: Verfügbarkeit, Reaktionszeit und Durchsatz. Im Bericht: 1: Verfügbarkeit, 0: HTTP-Antwortzeit und 14: HTTP-Durchsatz.
Details zur Ressourcenzeitplanung
Sie können festlegen, dass auch Details zum Ressourcen-Timing einbezogen werden sollen, indem Sie auf die Schaltflächen Ja oder Nein klicken. Zu den Details des Ressourcen
- DNS-Nachschlagezeit
- TCP-Verbindungszeit
- Sichere Verbindungszeit
- Download-Zeit
Beschreibungen der Protokolle finden Sie unter Radarprotokollbeschreibungen und Berichte für Service Provider and Enterprises.
Navigationszeitprotokolle
Protokollfrequenz
Navigations-Timing-Protokolle können täglich (alle 24 Stunden) generiert werden, dh am Ende des Tages, UTC-Zeit. Protokolle können auch in Echtzeit (Minute für Minute) generiert werden.
Datei-Format
Wählen Sie TSV oder JSON, um Navigationszeitprotokolle in einem dieser Formate zu empfangen. Beschreibungen der Protokolle finden Sie unter Beschreibungen des Navigationszeitprotokolls.
Openmix Protokolle
Protokollfrequenz
Openmix-Protokolle werden in Echtzeit (d. h. Minute für Minute) generiert. Diese Protokolle bieten Echtzeitmessungen für Openmix-Kunden.
Datei-Format
Wählen Sie TSV oder JSON, um Openmix- und HTTP Openmix-Protokolle in einem dieser Formate zu empfangen. JSON ist jedoch das empfohlene Format.
Logbeschreibungen finden Sie unter Openmix Log Descriptions.
Bereitstellung von Cloud-Diensten
Mit dieser Option können Sie die Art der Lieferung auswählen. Sie können Protokolle und Berichte entweder im AWS S3-Bucket oder im Google Cloud Storage (GCS) -Bucket empfangen. Sie können mit den bereitgestellten Anmeldeinformationen auf die S3- und GCS-Buckets zugreifen und s3cmd oder die AWS-CLI für S3. und die gsutil-Befehlszeile für GCS verwenden.
AWS S3
Wählen Sie AWS S3 aus, um Protokolle und Berichte an den AWS S3-Bucket zu übermitteln.
Standort
Der Standort stellt den Bucket in AWS S3 dar, in dem die Protokolle und Berichte gespeichert werden.
IAM-Schlüssel
Wenn Sie unter AWS S3 auf die Schaltfläche Schlüssel generieren klicken, werden die AWS IAM-Schlüssel (Access und Secret Keys) generiert und unter IAM-Schlüssel angezeigt. Achten Sie darauf, die Schlüssel aufzuzeichnen, da sie nirgends gespeichert sind, um sie später anzusehen.
HINWEIS:
Das Paar von Access- und Secret-Schlüsseln ist die einzige Kopie der privaten Schlüssel. Der Kunde muss sie sicher aufbewahren. Durch das Regenerieren der neuen Schlüssel werden die vorhandenen ungültig. Die Konfigurationsdatei S3cmd erkennt die Zugriffsschlüssel (die über die Portal-Benutzeroberfläche empfangen werden) und hilft dem Kunden, sich mit dem S3-Bucket zu verbinden. Die AWS-CLI muss auf dem Computer des Kunden installiert sein, um eine Verbindung zum S3 herzustellen.
Informationen zur Verwendung der Access- und Secret-Keys mit s3cmd zum Herunterladen von Berichten aus dem S3-Bucket finden Sie in den FAQ.
Google Cloud-Speicher
Wählen Sie Google Cloud Storage aus, um Protokolle und Berichte an GCS zu übermitteln.
Standort
Der Standort stellt den Bucket in Google Cloud Storage dar, in dem Protokolle und Berichte gespeichert werden.
IAM-Schlüssel
Wenn Sie die Schaltfläche Schlüsseldatei generieren auswählen, wird die Google Service-Kontoschlüsseldatei auf Ihren Computer heruntergeladen.
HINWEIS:
Diese Schlüsseldatei dient als einzige Kopie des privaten Schlüssels. Notieren Sie sich die E-Mail-Adresse Ihres Dienstkontos und speichern Sie die private Schlüsseldatei des Dienstkontos sicher. Durch das erneute Generieren einer neuen Schlüsseldatei wird die vorhandene Datei ungültig.
Diese Schlüsseldatei kann mit dem gsutil-Tool verwendet werden, um Protokolle und Berichte aus dem GCS-Bucket herunterzuladen. Einzelheiten zur Verwendung der Schlüsseldatei zum Herunterladen von Protokolldateien finden Sie in den häufig gestellten Fragen.
Radarprotokollbeschreibungen und Berichte für Service Provider und Unternehmen
Radarprotokolle für Anbieter
- Diese Protokolle bieten Radarmessungen für Benchmark-Partner.
- Sie liefern alle Messungen, die für öffentliche Plattformen durchgeführt wurden, unabhängig von der Seite, auf der die Messung generiert wurde.
- Radarprotokolle enthalten eine Teilmenge der Felder, die in den Rohprotokollen verfügbar sind, mit einigen Daten anonymisiert: Client IP /28, Referer MD5-Hash.
- Hier ist ein Beispiel für eine Platform Radar Log Share im TSV-Dateiformat.
HINWEIS:
- NEM stellt niemals vollständige Client-IPs bereit. Stattdessen wird /28 offen gelegt. Beispielsweise wird eine IP von 255.255.255.255 in einem Bericht als 255.255.255.240/28 angezeigt.
- Die GEO-Informationen des Kunden werden basierend auf dem IPv4 des Kunden extrahiert, das detaillierter ist.
Protokollbeschreibungen
Im Folgenden finden Sie die Spaltenüberschriften und Beschreibungen für die Radarprotokolle. Die Felder werden in der folgenden Reihenfolge in den Ausgabedateien angezeigt:
Protokoll | Beschreibung |
---|---|
Zeitstempel | Es ist die UTC-Zeit der Anforderung im Format YYYY-MM-DDTHH:MI:SSZ. Der tatsächliche Wert (auf die Sekunde herunter) in den Protokolltabellen wird auf die nächste Stunde (2018-03-30T23:00:00Z) bzw. den nächsten Tag (2018-03-30T00:00:00Z) in den Stunden-/Tag-Tabellen gerundet. Der Zeitstempel ist in allen Datensätzen immer in UTC angegeben. |
Eindeutige Knoten-ID | Wird auch als Cache-Knoten-ID bezeichnet. Es ist ein willkürlicher Wert. In der Regel eine IP, die die CDN Edge-Server zurückgeben, um CDNs dabei zu helfen, intern zu identifizieren, welcher Server eine bestimmte Anfrage bearbeitet hat. (leere Zeichenfolge): Stammt von Radar-Clients, die die UNI-Erkennung nicht unterstützen.0: Der Benutzeragent unterstützt die für die UNI-Erkennung erforderlichen Funktionen nicht.1: Der Client ist während der UNI-Erkennung auf einen Fehler gestoßen, z. B. eine HTTP 404 oder eine andere erfolglose Antwort.2: Es wurde versucht, eine UNI-Erkennung durchzuführen, führte jedoch zu einem Fehler. |
Anbieter-ID | Interne ID der Plattform, die gemessen wird. |
Sonden-Typ | Der Prüfpunkttyp, der gemessen wird (z. B. 1: HTTP-Verbindungszeit, 0: HTTP-Antwortzeit, 14: HTTP-Durchsatz usw.). Verwenden Sie die Informationen, die innerhalb der zulässigen Zeit erfolgreich zurückgegeben wurden, um anzuzeigen, dass der Dienst verfügbar ist. |
Antwortcode | Ergebnis der Messung, z. B. 0: Erfolg, 1: Timeout, 4: Fehler. Für Verfügbarkeitsberechnungen wird der Prozentsatz der Messungen mit einer Antwort von 0 (Erfolg) im Vergleich zur Gesamtzahl der Messungen (insgesamt, unabhängig von der Reaktion) ermittelt. Bei anderen Sondentypen (RTT und Durchsatz) darf der Filter bei der Berechnung von Statistiken im RTT nur RTT-Datenpunkte mit einem Erfolgscode von 0 berücksichtigen. Gleiches für den Durchsatz. |
Messwert | Der aufgezeichnete Messwert, dessen Bedeutung je nach Sondentyp variiert. Sie stellt Verfügbarkeits- (1) /Reaktionszeit (0) -Messungen in Millisekunden und Durchsatz (14) in kBit/s dar. |
Resolver-Markt | Der Markt des DNS-Resolvers, der die Anfrage bearbeitet hat. Im Allgemeinen der Kontinent, auf dem sich der DNS-Resolver befindet, wo, 0: Unbekannt (XX), 1: Nordamerika (NA) 5: Afrika (AF), 3: Europa (EU), 4: Asien (AS), 2: Ozeanien (OC), 6: Südamerika (SA). |
Resolver Land | Das Land des DNS-Resolvers, der die Anforderung bearbeitet hat. IDs können unter https://community-radar.citrix.com/ref/countries.json.gz Namen zugeordnet werden. |
Region “Resolver” | Die Region der DNS-Auflösungsinstanz, die die Anfrage bearbeitet hat. IDs können Namen zugeordnet werden. https://community-radar.citrix.com/ref/regions.json.gz Hinweis: Nicht alle Länder der Welt haben definierte Regionen. |
Auflösungsstatus | Der Status des DNS-Resolvers, der die Anfrage bearbeitet hat. IDs können unter https://community-radar.citrix.com/ref/states.json.gz Namen zugeordnet werden. Hinweis: Nicht alle Länder der Welt haben definierte Staaten zugeordnet. |
Resolver Stadt | Die Stadt des DNS-Resolvers, der die Anfrage bearbeitet hat. Die Stadt des Resolvers wird hinzugefügt, indem eine Resolver-IP-Adresse gesucht wird.IDs können Namen unter https://community-radar.citrix.com/ref/cities.json.gz |
Auflösungsvorabschuss-ASN | Die Autonomous System Number (ASN) des DNS-Resolvers, der die Anforderung bearbeitet hat. Im Allgemeinen kann die ASN mit den DNS-Resolver-IDs Namen zugeordnet werden https://community-radar.citrix.com/ref/asns.json.gz |
Resolver-IP | Die IP-Adresse des DNS-Resolvers, von dem unsere Infrastruktur die DNS-Anfrage erhalten hat. |
Kunden-Markt | Der Markt des Endverbrauchers, der diese Messung generiert hat. Im Allgemeinen der Kontinent, auf dem sich die Client-IP befindet; wobei 0: Unbekannt (XX), 1: Nordamerika (NA) 5: Afrika (AF), 3: Europa (EU), 4: Asien (AS), 2: Ozeanien (OC), 6: Südamerika (SA). |
Land des Kunden | Das Land des Endbenutzers, der diese Messung generiert hat.IDs können Namen unter https://community-radar.citrix.com/ref/countries.json.gz |
Region des Kunden | Die Region des Endbenutzers, der diese Messung generiert hat. Im Allgemeinen die geografische Region, in der die Client-IP ist. IDs können unter https://community-radar.citrix.com/ref/regions.json.gz Namen zugeordnet werden. Hinweis: Nicht alle Länder der Welt haben definierte Regionen zugeordnet. |
Client-Status | Der Status des Endbenutzers, der diese Messung generiert hat. Im Allgemeinen der Bundesstaat, in dem die Client-IP ist. IDs können unter https://community-radar.citrix.com/ref/states.json.gz Namen zugeordnet werden. Hinweis, nicht alle Länder der Welt definierte Staaten haben. |
Kunden-Stadt | Die Stadt des Endbenutzers, der diese Messung generiert hat. Im Allgemeinen die Stadt, in der sich die Client-IP befindet.IDs können Namen unter https://community-radar.citrix.com/ref/cities.json.gz |
Kunden-ASN | Die Autonomous System Number (ASN) des Endbenutzers, der diese Messung generiert hat. Im Allgemeinen kann die ASN, die die Client-IP.IDs enthält, Namen unter https://community-radar.citrix.com/ref/asns.json.gz |
Client-IP | Die IP des Endbenutzers, der diese Messung generiert hat. |
Referrer-Host MD5 | Die Referer-Informationen (Protokoll, Host und Pfad) stammen aus dem Referer-Header der HTTP-Anforderung an Radar. Der Referer-Host ist MD5-Hash. |
Benutzeragent | Es ist die Benutzer-Agent-Zeichenfolge von der Browserseite, die das Tag hostet. Wenn Sie beispielsweise Chrome verwenden und eine Seite mit dem Radar-Tag durchsuchen, zeichnet die Radarmessung im Hintergrund den Benutzeragenten in Ihrem Chrome-Browser auf. Die Messungen umfassen den Chrome-Browser, die Version von Chrome, Informationen über das Betriebssystem, auf dem Chrome ausgeführt wird, und so weiter. |
DNS-Nachschlagefunkt (optional) | Mit der Resource Timing API wird die Differenz zwischen dem Ende der Domänensuche und dem Start der Domänensuche berechnet. Es berechnet, wenn beide Werte nicht Null sind und die Endzeit größer als die Startzeit ist. Sie wird als domainLookupEnd - domainLookupStart berechnet. |
TCP-Verbindungszeit (optional) | Mit der Resource Timing API wird der Unterschied zwischen dem Connect End und Connect Start berechnet. Es berechnet, wenn beide Werte nicht Null sind und die Endzeit größer als die Startzeit ist. Es wird als connectEnd - connectStart berechnet. |
Sichere Verbindungszeit (optional) | Mit der Resource Timing API wird der Unterschied zwischen dem Connect End und Secure Connection Start berechnet. Es berechnet, wenn beide Werte nicht Null sind und die Endzeit größer als die Startzeit ist. Sie wird als connectEnd - secureConnectionStart berechnet. |
Latenz (optional) | Mit der Resource Timing API wird die Differenz zwischen dem Start der Antwort und dem Start der Anfrage berechnet. Es wird berechnet, wenn beide Werte nicht Null sind und die Startzeit der Antwort größer als die Startzeit der Anforderung ist. Es wird als responseStart - requestStart berechnet |
Downloadzeit (optional) | Mit der Resource Timing API wird die Differenz zwischen dem Ende der Antwort und dem Start der Antwort berechnet. Es berechnet, wenn beide Werte nicht Null sind und die Endzeit größer als die Startzeit ist. Sie wird als responseEnd - responseStart berechnet. |
Kundenprofil | Dieses Feld hilft bei der Identifizierung, ob die Daten von mobilen Apps oder Browsern stammen. Es ermöglicht uns auch, zwischen iOS, Android Apps und Browsern zu unterscheiden. Eine Zahl wird verwendet, um jedes Kundenprofil zu identifizieren. Die Werte für dieses Feld sind: null, 0, 1, 2, 3, 4. Wo, null: Impliziert im Allgemeinen einen älteren Radar-Client, der das Senden des client_profile-Werts nicht unterstützt. 0: Browser; 1: iOS - Radarläufer für iOS-App in Swift geschrieben; 2: Android; 3: Browser auf mobiler Version der Website; 4: iOS - Radar Runner für iOS-App in Objective-C geschrieben. |
Version des Kundenprofils | Die Version des Client-Profils gibt an, welche Version des Radar Runner-Codes (für iOS) oder AndroidRadar SDK (für Android) in der mobilen App verwendet wurde. Dieses Feld ist nur für den internen Gebrauch bestimmt. |
Geräte-Kategorie | Alle Geräte sind in eines der folgenden Kategorien unterteilt: Smartphone, Tablet, PC, Smart TV und Andere. ‘Andere’ wird als Standardwert verwendet, wenn der Parser den Wert für keines der Felder ermitteln kann. |
Gerät | Der Typ des Geräts, auf dem sich der Benutzer befindet, z. B. ein Apple iPhone. Die Benutzer-Agent-Zeichenfolge erkennt sie im Browser, der auf der Seite ausgeführt wird, auf der das Radar-Tag gehostet wird. |
Browser | Der Typ des Browsers, den der Benutzer verwendet, z. B. Mobile Safari UI/WKWebView 0.0.0. Die Benutzer-Agent-Zeichenfolge erkennt sie im Browser, der auf der Seite ausgeführt wird, auf der das Radar-Tag gehostet wird. |
Betriebssystem | Das verwendete Betriebssystem. Zum Beispiel iOS 11.0.3. Die Zeichenfolge des Benutzeragenten erkennt sie vom Browser, der auf der Seite ausgeführt wird, auf der das Radar-Tag gehostet wird. |
Berichts-Kunden-IP | Diese IP ist die maskierte /48 öffentliche IP des Benutzers, der die Messung durchführt. Es kann entweder IPv4 oder IPv6 sein (sofern unterstützt). |
Anonymer Bester Bericht
- Anonyme Best Reports helfen Anbietern dabei, ihre Leistung mit der Peer-Group der anderen Plattform zu vergleichen, die sich innerhalb desselben Landes, derselben Region oder ASN befindet.
- Die Leistungsdaten der 15 wichtigsten Anbieter in der Peer-Group werden auf der Grundlage derselben Kategorien aggregiert. Der beste Wert wird neben dem besten Wert des jeweiligen Anbieters aufgeführt.
- Anonymer Best Report für SSL-Plattformen ist verfügbar, so dass ihre Leistung mit anderen SSL-Plattformen verglichen werden kann.
- Die Client-IPs werden auf /28 gekürzt.
- Die Ergebnisse des “besten” Anbieters helfen Clouds/CDNs dabei, ihre Leistung auf hochvolumige oder geschäftskritische ASNs zu konzentrieren, die für ihre Mitbewerber wettbewerbsschwach sind.
- Der Bericht enthält Details zur Leistung, die aus DNS-Resolver-IP, Client IP /28 und dem Caching-Knoten besteht, der die Objekte bedient hat. Es wird mit der “besten” Plattform für dieselben Kriterien verglichen.
- Verfügbar für RTT oder Durchsatz.
- Das Folgende ist ein Beispiel für einen Platform Anonymous Best Report für RTT im TSV-Dateiformat.
Protokollbeschreibungen
Im Folgenden sind die Spaltenüberschriften und Beschreibungen für den anonymen besten Bericht aufgeführt. Die Felder werden in der folgenden Reihenfolge in den Ausgabedateien angezeigt.
Protokoll | Beschreibung |
---|---|
Resolver Land | Das Land des DNS-Resolvers, der die Anfrage bearbeitet hat. |
Region “Resolver” | Die Region des DNS-Resolvers, die die Anforderung bearbeitet hat. |
Auflösungsstatus | Der Status des DNS-Resolvers, der die Anforderung bearbeitet hat. |
ASN-ID des Resolvers | Die Autonome Systemnummer des DNS-Resolvers, der die Anforderung verarbeitet hat. Im Allgemeinen die ASN, die über den DNS-Resolver verfügt. |
Name der Resolver-ASN | Der Name der ASN. |
Resolver-IP | Die IP-Adresse des DNS-Resolvers, von dem unsere Infrastruktur die DNS-Anfrage erhalten hat. |
Land des Kunden | Das Land des Endbenutzers, der diese Messung generiert hat. |
Region des Kunden | Die Region des Endbenutzers, der diese Messung generiert hat. |
Client-Status | Der Status des Endbenutzers, der diese Messung generiert hat. |
ASN-ID des Kunden | Die ASN-Nummer (Autonomous System Number) des Endbenutzers, der diese Messung generiert hat. Im Allgemeinen die ASN, die die Client-IP hat. |
Name der Client-ASN | Der Name der ASN des Endbenutzers, der die Messung generiert hat. |
Client-IP | Die IP des Endbenutzers, der die Messung generiert hat. |
Erfolge | Gesamtzahl der Messungen, die erfolgreich waren.Tipp: Erfolg/Total == Verfügbarkeit. |
Timeouts | Die Anzahl der Messungen, bei denen das Zeitlimit überschritten wurde. |
Errors | Die Anzahl der Messungen, die Fehler waren. |
Gesamt | Die Gesamtzahl der Messungen. |
Mean | Der Durchschnitt aller Messwerte für diese Zeile. |
Bester Mittelwert | Der beste Mittelwert unter den 15 besten Anbietern in der Peer-Group. |
Beste Mittelwertmessungen | Gesamtzahl der Messungen, die den besten Mittelwert ergaben. |
Median | Der 50. Perzentilwert ist der mittlere Wert der Messungen für einen bestimmten Anbieter, wenn die Messungen in der Reihenfolge aufgeführt sind. |
Bester Median | Der beste 50. Perzentilwert (unter dem 50 Prozent der Messungen zu finden sind) der 15 besten Anbieter in der Peer-Group. |
Beste Medianmessungen | Gesamtzahl der Messungen, die den best_median ergaben |
5th | Der 5. Perzentilwert für den Anbieter. |
Beste 5. | Der beste Wert des 5. Perzentils unter den 15 besten Anbietern in der Vergleichsgruppe. |
Beste 5. Messungen | Gesamtzahl der Messungen für best_5th |
10th | Der 10. Perzentilwert für den Anbieter. |
Beste 10. | Der beste Wert des 10. Perzentils unter den 15 besten Anbietern in der Vergleichsgruppe. |
Beste 10. Messungen | Gesamtzahl der Messungen für best_10th |
90th | Der 90. Perzentilwert für den Anbieter. |
Beste 90. | Der beste Wert des 90. Perzentils unter den 15 besten Anbietern in der Vergleichsgruppe. |
Beste 90. Messungen | Gesamtzahl der Messungen für best_90th |
95th | Der 95. Perzentilwert für den Anbieter. |
Beste 95. | Der beste Wert des 95. Perzentils unter den 15 besten Anbietern in der Vergleichsgruppe. |
Beste 95. Messungen | Gesamtzahl der Messungen für best_95. |
Stev | Die Standardabweichung für den Anbieter |
Best Stdev | Die beste Standardabweichung unter den 15 besten Anbietern in der Vergleichsgruppe. |
Best Stdev Measurements | Gesamtzahl der Messungen für best std.dev. |
Verfügbarkeit | Die prozentuale Verfügbarkeit für den Anbieter. Verfügbarkeit ist die Erfolgsrate der Probe, d.h. Erfolge/(Erfolge + Fehlschläge + Timeouts) |
Beste Verfügbarkeit | Der beste Verfügbarkeitswert unter den 15 besten Anbietern in der Peer-Group. |
Messungen der besten Verfügbarkeit | Die Anzahl der Messungen, die die beste Verfügbarkeit ergaben |
Wichtigkeit | Synthetische Werte werden generiert, um verwertbare Daten zu finden. |
Eindeutige Knoten-IDs | Diese IDs sind eine durch Kommas getrennte Liste der eindeutigen Knoten-IDs für die Messungen dieser Zeile. |
Messungstyp | Der aufgezeichnete Messwert, dessen Bedeutung je nach Sondentyp variiert. Es ist HTTP_COLD (Verfügbarkeit), HTTP_RTT (Roundtrip-Zeit) oder HTTP_KBPS (Durchsatz). |
Anbieter-ID | Die interne NetScaler ITM-ID-Nummer für diesen Anbieter. |
Cache-Knoten-ID-Bericht (zuvor Multi-Service Provider-Bericht)
Dieser Bericht wird verwendet, um den spezifischen Server oder das Datencenter zu identifizieren, das auf eine Anfrage reagiert hat, und hilft bei der Diagnose von Serverproblemen.
- Es liefert die ID des Rechenzentrums oder der Maschine, die auf eine bestimmte Anfrage geantwortet hat.
- Es hilft zu verstehen, warum die Leistung über einen bestimmten Knoten (POP oder Maschine oder Knoten-ID) gut oder schlecht war.
- Die Leistung besteht aus Reaktionszeit, Durchsatz, Verfügbarkeit (Probentyp), der DNS-Resolver-IP, Client IP /28 und dem Caching-Knoten, der die Objekte bedient hat.
- Das Folgende ist ein Beispiel für einen Plattform-Cache-Knoten-ID-Bericht im TSV-Dateiformat.
Protokollbeschreibungen
Im Folgenden sind die Spaltenüberschriften und Beschreibungen für den Cache-Knoten-ID-Bericht aufgeführt. Die Felder werden in der folgenden Reihenfolge in den Ausgabedateien angezeigt:
Protokoll | Beschreibung |
---|---|
Name des Anbieters | Es ist der Name des Anbieters, der gemessen wird. |
Messwert | Der aufgezeichnete Messwert, dessen Bedeutung je nach Sondentyp variiert. Es sind connect (1) /RTT (0) -Messungen in Millisekunden und Durchsatzmessungen (14) in Kbit/s. |
Eindeutige Knoten-ID | Es ist als Cache-Knoten-ID bekannt. Ein beliebiger Wert, typischerweise eine IP, die CDN Edge-Server zurückgeben, um CDNs dabei zu helfen, intern zu identifizieren, welcher Server eine bestimmte Anfrage bearbeitet hat. (leere Zeichenfolge): Stammt von Radar-Clients, die die UNI-Erkennung nicht unterstützen.0: Der Benutzeragent unterstützt die für die UNI-Erkennung erforderlichen Funktionen nicht.1: Der Client findet während der UNI-Erkennung einen Fehler, z. B. eine HTTP 404 oder eine andere erfolglose Antwort.2: Es wurde versucht, eine UNI-Erkennung durchzuführen, führte jedoch zu einem Fehler. |
Resolver Land | Das Land des DNS-Resolvers, der die Anfrage bearbeitet hat. |
Region “Resolver” | Die Region des DNS-Resolvers, die die Anforderung bearbeitet hat. |
Auflösungsstatus | Der Status des DNS-Resolvers, der die Anforderung bearbeitet hat. |
Auflösungsvorabschuss-ASN | Die Autonome Systemnummer des DNS-Resolvers, der die Anforderung verarbeitet hat. Im Allgemeinen die ASN, die über den DNS-Resolver verfügt. |
Name der Resolver-ASN | Der Name der ASN. |
Resolver-IP | Die IP-Adresse des DNS-Resolvers, von dem unsere Infrastruktur die DNS-Anfrage erhalten hat. |
Land des Kunden | Das Land des Endbenutzers, der diese Messung generiert hat. |
Region des Kunden | Die Region des Endbenutzers, der diese Messung generiert hat. |
Client-Status | Der Status des Endbenutzers, der diese Messung generiert hat. |
Kunden-ASN | Die ASN-Nummer (Autonomous System Number) des Endbenutzers, der diese Messung generiert hat. Im Allgemeinen die ASN, die die Client-IP hat. |
Name der Client-ASN | Der Name der ASN des Endbenutzers, der die Messung generiert hat. |
Client-IP | Die IP des Endbenutzers, der die Messung generiert hat. |
Erfolg | Gesamtzahl der Messungen, die erfolgreich waren.Tipp: Erfolg/Total == Verfügbarkeit. |
Timeout | Die Anzahl der Messungen, bei denen das Zeitlimit überschritten wurde. |
Fehler | Die Anzahl der Messungen, die Fehler waren. |
Gesamt | Die Gesamtzahl der Messungen. |
Mean | Der Durchschnitt der Messwerte für jede Zeile. |
Median | Der 50. Perzentilwert ist der mittlere Wert der Messungen für einen bestimmten Anbieter, wenn die Messungen in der Reihenfolge aufgeführt sind. |
5th | Der 5. Perzentilwert für den Anbieter. |
10th | Der 10. Perzentilwert für den Anbieter. |
90th | Der 90. Perzentilwert für den Anbieter. |
95th | Der 95. Perzentilwert für den Anbieter. |
Stev | Die Standardabweichung für den Anbieter. |
Verfügbarkeit | Die prozentuale Verfügbarkeit für den Anbieter. |
Wichtigkeit | Synthetische Werte werden generiert, um verwertbare Daten zu finden. |
Stündlich nach Land/ASN-Bericht
- Mit diesem Bericht können Sie überprüfen, ob die Leistung Ihrer Anbieter im Laufe eines Tages erheblich variiert.
- Es zeigt die Zeit, zu der die Messungen auf die Stunde abgeschnitten wurden, zum Beispiel
2018-03-11T23:00:00
. - Das Folgende ist ein Beispiel für einen Plattform-Hourly by Country/ASN-Bericht im TSV-Dateiformat.
Protokollbeschreibungen
Im Folgenden finden Sie die Spaltenüberschriften und Beschreibungen für den Bericht “Stündlich nach Land/ASN”. Die Felder werden in der folgenden Reihenfolge in den Ausgabedateien angezeigt:
Protokoll | Beschreibung |
---|---|
Zeitstempel 60 Minuten | Die UTC-Zeit, zu der die Messungen durchgeführt wurden, wurde auf die Stunde verkürzt, zum Beispiel 2018-03-11T 23:00:00. |
Name des Anbieters | Es ist der Name des Anbieters, der gemessen wird. |
Messungstyp | Der aufgezeichnete Messwert, dessen Bedeutung je nach Sondentyp variiert. Es ist HTTP_COLD (Verfügbarkeit), HTTP_RTT (Roundtrip-Zeit) oder HTTP_KBPS (Durchsatz). |
Land des Kunden | Das Land des Endbenutzers, der diese Messung generiert hat. |
Kunden-ASN | Die ASN-Nummer (Autonomous System Number) des Endbenutzers, der diese Messung generiert hat. Im Allgemeinen die ASN, die die Client-IP hat. |
Name der Client-ASN | Der Name der ASN des Endbenutzers, der die Messung generiert hat. |
Erfolg | Gesamtzahl der Messungen, die erfolgreich waren.Tipp: Erfolg/Total == Verfügbarkeit. |
Timeout | Die Anzahl der Messungen, bei denen das Zeitlimit überschritten wurde. |
Fehler | Die Anzahl der Messungen, die Fehler waren. |
Gesamt | Die Gesamtzahl der Messungen. |
Mean | Der Durchschnitt der Messwerte für jede Zeile. |
Median | Der 50. Perzentilwert ist der mittlere Wert der Messungen für einen bestimmten Anbieter, wenn die Messungen in der Reihenfolge aufgeführt sind. |
5th | Der 5. Perzentilwert für den Anbieter. |
10th | Der 10. Perzentilwert für den Anbieter. |
90th | Der 90. Perzentilwert für den Anbieter. |
95th | Der 95. Perzentilwert für den Anbieter. |
Stev | Die Standardabweichung für den Anbieter. |
Verfügbarkeit | Die prozentuale Verfügbarkeit für den Anbieter. |
Wichtigkeit | Synthetischer Wert wird generiert, um verwertbare Daten zu finden. |
Anbieter-ID | Die interne NetScaler ITM-ID-Nummer für diesen Anbieter. |
Radarprotokollbeschreibungen und Berichte für ISPs
Radarprotokolle für ISPs
Radarprotokolle ermöglichen es ISPs, ihre Leistung anhand globaler Plattformen im Detail zu messen. ISPs können diese Daten verwenden, um Bereiche zu finden, in denen Verbesserungen vorgenommen werden müssen, oder um die erwartete Leistung zu überprüfen.
- Bietet Zugriff auf Radarmessungen.
- Stellt Messungen von ISPs auf öffentlichen Plattformen bereit, unabhängig von der Seite, auf der die Messung generiert wurde.
- Radarprotokolle enthalten eine Teilmenge der in den Rohprotokollen verfügbaren Felder, wobei einige Daten anonymisiert sind: Client IP /28, Referer MD5 gehasht.
- Die Protokolldateien sind im TSV-Format.
- Das Folgende ist ein Beispiel für eine Network Radar Log Share im TSV-Dateiformat.
Protokollbeschreibungen
Im Folgenden finden Sie die Spaltenüberschriften und Beschreibungen für die Radarprotokolle für ISPs. Die Felder werden in der folgenden Reihenfolge in den Ausgabedateien angezeigt.
Protokoll | Beschreibung |
---|---|
Zeitstempel | Es ist die UTC-Zeit der Anfrage im Format YYYY-MM-DDTHH: MI: SSZ. Der tatsächliche Wert (auf die Sekunde herunter) in den Protokolltabellen wird auf die nächste Stunde (2018-03-30T23:00:00Z) bzw. den nächsten Tag (2018-03-30T00:00:00Z) in den Stunden-/Tag-Tabellen gerundet. Der Zeitstempel ist in allen Datensätzen immer in UTC angegeben. |
Anbieter-ID | Interne ID der Plattform, die gemessen wird. |
Sonden-Typ | Der Prüfpunkttyp, der gemessen wird (z. B. 1: HTTP-Verbindungszeit, 0: HTTP-Antwortzeit, 14: HTTP-Durchsatz usw.). Die Informationen, die innerhalb der zulässigen Zeit erfolgreich zurückgegeben wurden, werden verwendet, um anzuzeigen, dass der Dienst verfügbar ist. |
Antwortcode | Ergebnis der Messung, z. B. 0: Erfolg, 1: Timeout, 4: Fehler. Für Verfügbarkeitsberechnungen wird der Prozentsatz der Messungen mit einer Antwort von 0 (Erfolg) im Vergleich zur Gesamtzahl der Messungen (gesamt) ermittelt. Bei anderen Sondentypen (RTT und Durchsatz) darf der Filter bei der Berechnung von Statistiken im RTT nur RTT-Datenpunkte mit einem Erfolgscode von 0 berücksichtigen. Gleiches für den Durchsatz. |
Messwert | Der aufgezeichnete Messwert, dessen Bedeutung je nach Sondentyp variiert. Es sind Verfügbarkeits- (1) /Reaktionszeit (0) -Messungen in Millisekunden und Durchsatz (14) in KBit/s. |
Resolver-Markt | Der Markt des DNS-Resolvers, der die Anfrage bearbeitet hat. Im Allgemeinen der Kontinent, auf dem sich der DNS-Resolver befindet, wo, 0: Unbekannt (XX), 1: Nordamerika (NA) 5: Afrika (AF), 3: Europa (EU), 4: Asien (AS), 2: Ozeanien (OC), 6: Südamerika (SA). |
Resolver Land | Das Land des DNS-Resolvers, der die Anforderungs-IDs bearbeitet hat, kann Namen zugeordnet werden unter https://community-radar.citrix.com/ref/countries.json.gz |
Region “Resolver” | Die Region des DNS-Resolvers, die die Anforderungs-IDs bearbeitet hat, kann Namen unter zugeordnet werden https://community-radar.citrix.com/ref/regions.json.gz. Nicht alle Länder der Welt haben definierte Regionen. |
Auflösungsstatus | Der Status des DNS-Resolvers, der die Anforderungs-IDs verarbeitet hat, kann Namen unter zugeordnet werden https://community-radar.citrix.com/ref/states.json.gz. Nicht alle Länder der Welt haben definierte Staaten. |
Auflösungsvorabschuss-ASN | Die Autonomous System Number (ASN) des DNS-Resolvers, der die Anforderung bearbeitet hat. Im Allgemeinen kann die ASN mit den DNS-Resolver-IDs Namen unter zugeordnet werden https://community-radar.citrix.com/ref/asns.json.gz. |
Resolver-IP | Die IP-Adresse des DNS-Resolvers, von dem unsere Infrastruktur die DNS-Anfrage erhalten hat. |
Kunden-Markt | Der Markt des Endverbrauchers, der diese Messung generiert hat. Im Allgemeinen der Kontinent, auf dem sich die Client-IP befindet; wobei 0: Unbekannt (XX), 1: Nordamerika (NA) 5: Afrika (AF), 3: Europa (EU), 4: Asien (AS), 2: Ozeanien (OC), 6: Südamerika (SA). |
Land des Kunden | Das Land des Endbenutzers, der diese Messung generiert hat.IDs können Namen unter https://community-radar.citrix.com/ref/countries.json.gz |
Region des Kunden | Die Region des Endbenutzers, der diese Messung generiert hat. Im Allgemeinen die geografische Region, in der sich die Client-IP befindet. IDs können unter https://community-radar.citrix.com/ref/regions.json.gz Namen zugeordnet werden. Nicht alle Länder der Welt haben definierte Regionen. |
Client-Status | Der Status des Endbenutzers, der diese Messung generiert hat. Im Allgemeinen der Staat, in dem sich die Client-IP befindet. IDs können unter https://community-radar.citrix.com/ref/states.json.gz Namen zugeordnet werden. Nicht alle Länder der Welt haben definierte Staaten. |
Kunden-ASN | Die Autonomous System Number (ASN) des Endbenutzers, der diese Messung generiert hat. Im Allgemeinen die ASN, die die Client-IP hat. IDs können unter https://community-radar.citrix.com/ref/asns.json.gz Namen zugeordnet werden. |
Client-IP | Die IP des Endbenutzers, der diese Messung generiert hat. |
Referrer-Host MD5 | Die Referer-Informationen (Protokoll, Host und Pfad) stammen aus dem Referer-Header der HTTP-Anforderung an Radar. Der Referer-Host ist MD5-Hash. |
Benutzeragent | Es ist die Benutzer-Agent-Zeichenfolge von der Browserseite, die das Tag hostet. Wenn Sie beispielsweise Chrome verwenden und eine Seite mit dem Radar-Tag durchsuchen, zeichnet die Radarmessung im Hintergrund den Benutzeragenten in Ihrem Chrome-Browser auf. Die Messungen umfassen den Chrome-Browser, die Version von Chrome, Informationen über das Betriebssystem, auf dem Chrome ausgeführt wird, und so weiter. |
DNS-Nachschlagefunkt (optional) | Mit der Resource Timing API wird die Differenz zwischen dem Ende der Domänensuche und dem Start der Domänensuche berechnet. Es berechnet, wenn beide Werte nicht Null sind und die Endzeit größer als die Startzeit ist. Sie wird als domainLookupEnd - domainLookupStart berechnet. |
TCP-Verbindungszeit (optional) | Mit der Resource Timing API wird der Unterschied zwischen dem Connect End und Connect Start berechnet. Es berechnet, wenn beide Werte nicht Null sind und die Endzeit größer als die Startzeit ist. Es wird als connectEnd - connectStart berechnet. |
Sichere Verbindungszeit (optional) | Mit der Resource Timing API wird der Unterschied zwischen dem Connect End und dem Secure Connection Start berechnet. Es berechnet, wenn beide Werte nicht Null sind und die Endzeit größer als die Startzeit ist. Sie wird als connectEnd - secureConnectionStart berechnet. |
Latenz (optional) | Mit der Resource Timing API wird die Differenz zwischen dem Start der Antwort und dem Start der Anfrage berechnet. Es wird berechnet, wenn beide Werte nicht Null sind und die Startzeit der Antwort größer als die Startzeit der Anforderung ist. Es wird als responseStart - requestStart berechnet |
Downloadzeit (optional) | Mit der Resource Timing API wird die Differenz zwischen dem Ende der Antwort und dem Start der Antwort berechnet. Es berechnet, wenn beide Werte nicht Null sind und die Endzeit größer als die Startzeit ist. Sie wird als responseEnd - responseStart berechnet. |
Kundenprofil | Dieses Feld hilft bei der Identifizierung, ob die Daten von mobilen Apps oder Browsern stammen. Es ermöglicht uns auch, zwischen iOS, Android Apps und Browsern zu unterscheiden. Eine Zahl wird verwendet, um jedes Kundenprofil zu identifizieren. Die Werte für dieses Feld sind: null, 0, 1, 2, 3, 4. Wo, null: Impliziert im Allgemeinen einen älteren Radar-Client, der das Senden des client_profile-Werts nicht unterstützt. 0: Browser; 1: iOS - Radarläufer für iOS-App in Swift geschrieben; 2: Android; 3: Browser auf mobiler Version der Website; 4: iOS - Radar Runner für iOS-App in Objective-C geschrieben. |
Version des Kundenprofils | Die Version des Client-Profils gibt an, welche Version des Radar Runner-Codes (für iOS) oder AndroidRadar SDK (für Android) in der mobilen App verwendet wurde. Dieses Feld ist nur für den internen Gebrauch bestimmt. |
Geräte-Kategorie | Alle Geräte sind in eines der folgenden Kategorien unterteilt: Smartphone, Tablet, PC, Smart TV und Andere. ‘Andere’ wird als Standardwert verwendet, wenn der Parser den Wert für keines der Felder ermitteln kann. |
Gerät | Der Typ des Geräts, auf dem sich der Benutzer befindet, z. B. ein Apple iPhone. Die Benutzer-Agent-Zeichenfolge erkennt sie im Browser, der auf der Seite ausgeführt wird, auf der das Radar-Tag gehostet wird. |
Browser | Der Typ des Browsers, den der Benutzer verwendet, z. B. Mobile Safari UI/WKWebView 0.0.0. Die Benutzer-Agent-Zeichenfolge erkennt sie im Browser, der auf der Seite ausgeführt wird, auf der das Radar-Tag gehostet wird. |
Betriebssystem | Das verwendete Betriebssystem, z. B. iOS 11.0.3. Die Benutzer-Agent-Zeichenfolge erkennt sie im Browser, der auf der Seite ausgeführt wird, auf der das Radar-Tag gehostet wird. |
Subnetzbericht für ISPs
- Der Bericht liefert ISPs Informationen darüber, wie sich die spezifischen Subnetze ihrer Netzwerke für ihre Benutzer über die gemessenen Plattformen verhalten.
- Es enthält Informationen über den Dienstanbieter, der auf eine bestimmte Anforderung geantwortet hat.
- Es hilft, die Leistung des Netzwerksubnetzes zu verstehen.
- Die Leistung besteht aus Reaktionszeit, Durchsatz, Verfügbarkeit (Probentyp), der DNS-Resolver-IP, Client IP /28 und dem Caching-Knoten, der die Objekte bedient hat.
- Das Folgende ist ein Beispiel für einen Netzwerk-Subnetzbericht im TSV-Dateiformat.
Protokollbeschreibungen
Im Folgenden finden Sie die Spaltenüberschriften und Beschreibungen für den Subnetzbericht für ISPs. Die Felder werden in der folgenden Reihenfolge in den Ausgabedateien angezeigt:
Protokoll | Beschreibung |
---|---|
ASN Name | Der Name des autonomen Systems, von dem aus die Messung durchgeführt wurde. |
Messwert | Der aufgezeichnete Messwert, dessen Bedeutung je nach Sondentyp variiert. Es sind connect (1) /RTT (0) -Messungen in Millisekunden und Durchsatzmessungen (14) in Kbit/s. |
Subnetz | Das Subnetz des Benutzers, von dem die Anfrage stammt. |
Auflösungsvorabschuss-ASN | Die Autonome Systemnummer des DNS-Resolvers, der die Anforderung verarbeitet hat. Im Allgemeinen die ASN, die über den DNS-Resolver verfügt. |
Resolver-IP | Die IP-Adresse des DNS-Resolvers, von dem unsere Infrastruktur die DNS-Anfrage erhalten hat. |
Kunden-ASN | Die ASN-Nummer (Autonomous System Number) des Endbenutzers, der diese Messung generiert hat. Im Allgemeinen die ASN, die die Client-IP hat. |
Client-IP | Die IP des Endbenutzers, der die Messung generiert hat. |
Plattform-ID | Die ID der Service Provider-Plattform, an der die Abfrage durchgeführt wurde. |
Plattformname | Der Name der Service Provider-Plattform, an der die Abfrage durchgeführt wurde |
Erfolg | Gesamtzahl der Messungen, die erfolgreich waren.Tipp: Erfolg/Total == Verfügbarkeit. |
Timeout | Die Anzahl der Messungen, bei denen das Zeitlimit überschritten wurde. |
Fehler | Die Anzahl der Messungen, die Fehler waren. |
Gesamt | Die Gesamtzahl der Messungen. |
Mean | Der Durchschnitt der Messwerte für jede Zeile. |
Median | Der 50. Perzentilwert ist der mittlere Wert der Messungen für einen bestimmten Anbieter, wenn die Messungen in der Reihenfolge aufgeführt sind. |
5th | Der 5. Perzentilwert für den Anbieter. |
10th | Der 10. Perzentilwert für den Anbieter. |
90th | Der 90. Perzentilwert für den Anbieter. |
95th | Der 95. Perzentilwert für den Anbieter. |
Stev | Die Standardabweichung für den Anbieter. |
Verfügbarkeit | Die prozentuale Verfügbarkeit für den Anbieter. |
Wichtigkeit | Synthetische Werte werden generiert, um verwertbare Daten zu finden. |
Messungstyp | Der aufgezeichnete Messwert, dessen Bedeutung je nach Sondentyp variiert. Es ist HTTP_COLD (Verfügbarkeit), HTTP_RTT (Roundtrip-Zeit) oder HTTP_KBPS (Durchsatz). |
Anonymer Bester Bericht für ISPs
- Im Bericht Anonymous Best wird eine Peer-Group für den “besten” Vergleich verwendet. Die Peer-Gruppe basiert auf dem Standort des ISP. Normalerweise sind es die 10 am häufigsten gemessenen ISPs in einem bestimmten Land mit einem Minimum von über 1.000 Sitzungen.
- Die Ergebnisse des “besten” ISP helfen ISPs dabei, ihre Leistungsbemühungen auf großvolumige oder geschäftskritische Plattformen und Bereiche zu konzentrieren, die im Vergleich zu ihren Mitbewerbern wettbewerbsschwach sind.
- Der Bericht enthält Details zur Leistung, aufgeschlüsselt nach Geographie und Plattform, und vergleicht sie mit dem “besten” ISP für dieselben Kriterien.
- Verfügbar für RTT und Durchsatz.
- Das Folgende ist ein Beispiel für Network Anonymous Best Report für RTT im TSV-Dateiformat.
Protokollbeschreibungen
Im Folgenden sind die Spaltenüberschriften und Beschreibungen für den anonymen besten Bericht aufgeführt. Die Felder werden in der folgenden Reihenfolge in den Ausgabedateien angezeigt.
Protokoll | Beschreibung |
---|---|
Messungstyp | Der aufgezeichnete Messwert, dessen Bedeutung je nach Sondentyp variiert. Es ist HTTP_COLD (Verfügbarkeit), HTTP_RTT (Roundtrip-Zeit) oder HTTP_KBPS (Durchsatz). |
Land des Kunden | Das Land des Endbenutzers, der diese Messung generiert hat. |
Region des Kunden | Die Region des Endbenutzers, der diese Messung generiert hat. |
Client-Status | Der Status des Endbenutzers, der diese Messung generiert hat. |
ASN-ID des Kunden | Die ASN-Nummer (Autonomous System Number) des Endbenutzers, der diese Messung generiert hat. Im Allgemeinen die ASN, die die Client-IP hat. |
Name der Client-ASN | Der Name der ASN des Endbenutzers, der die Messung generiert hat. |
Resolver Land | Das Land des DNS-Resolvers, der die Anfrage bearbeitet hat. |
Region “Resolver” | Die Region des DNS-Resolvers, die die Anforderung bearbeitet hat. |
Auflösungsstatus | Der Status des DNS-Resolvers, der die Anforderung bearbeitet hat. |
Plattform-ID | Die ID der Service Provider-Plattform, an die die Abfrage versucht wurde. |
Plattformname | Der Name der Service Provider-Plattform, an die die Abfrage versucht wurde. |
Erfolge | Gesamtzahl der Messungen, die erfolgreich waren.Tipp: Erfolg/Total == Verfügbarkeit. |
Timeouts | Die Anzahl der Messungen, bei denen das Zeitlimit überschritten wurde. |
Errors | Die Anzahl der Messungen, die Fehler waren. |
Gesamt | Die Gesamtzahl der Messungen. |
Mean | Der Durchschnitt aller Messwerte für diese Zeile. |
Bester Mittelwert | Der beste Mittelwert unter den 15 besten Anbietern in der Peer-Group. |
Beste Mittelwertmessungen | Gesamtzahl der Messungen, die den besten Mittelwert ergaben. |
Median | Der 50. Perzentilwert ist der mittlere Wert der Messungen für einen bestimmten Anbieter, wenn die Messungen in der Reihenfolge aufgeführt sind. |
Bester Median | Der beste 50. Perzentilwert (unter dem 50 Prozent der Messungen zu finden sind) der 15 besten Anbieter in der Peer-Group. |
Beste Medianmessungen | Gesamtzahl der Messungen, die den best_median ergaben |
5th | Der 5. Perzentilwert für den Anbieter. |
Beste 5. | Der beste Wert des 5. Perzentils unter den 15 besten Anbietern in der Vergleichsgruppe. |
Beste 5. Messungen | Gesamtzahl der Messungen für best_5th |
10th | Der 10. Perzentilwert für den Anbieter. |
Beste 10. | Der beste Wert des 10. Perzentils unter den 15 besten Anbietern in der Vergleichsgruppe. |
Beste 10. Messungen | Gesamtzahl der Messungen für best_10th |
90th | Der 90. Perzentilwert für den Anbieter. |
Beste 90. | Der beste Wert des 90. Perzentils unter den 15 besten Anbietern in der Vergleichsgruppe. |
Beste 90. Messungen | Gesamtzahl der Messungen für best_90th |
95th | Der 95. Perzentilwert für den Anbieter. |
Beste 95. | Der beste Wert des 95. Perzentils unter den 15 besten Anbietern in der Vergleichsgruppe. |
Beste 95. Messungen | Gesamtzahl der Messungen für best_95. |
Stev | Die Standardabweichung für den Anbieter. |
Best Stdev | Die beste Standardabweichung unter den 15 besten Anbietern in der Vergleichsgruppe. |
Best Stdev Measurements | Gesamtzahl der Messungen für best std.dev. |
Verfügbarkeit | Die prozentuale Verfügbarkeit für den Anbieter. Verfügbarkeit ist die Erfolgsrate des Tests, d. h. Erfolge/(Erfolge + Fehlschläge + Timeouts) |
Beste Verfügbarkeit | Der beste Verfügbarkeitswert unter den 15 besten Anbietern in der Peer-Group. |
Messungen der besten Verfügbarkeit | Die Anzahl der Messungen, die die beste Verfügbarkeit ergaben. |
Wichtigkeit | Synthetische Werte werden generiert, um verwertbare Daten zu finden. |
Beschreibung des Navigations-Timing-
Navigations-Timing-Daten
Navigation Timing Daten geben Einblicke in die verschiedenen Teile des Seitenladeprozesses für eine Webseite.
Diese Daten variieren aufgrund des Standorts des Endbenutzers, Netzwerkproblemen, Änderungen des Anbieters usw. Kunden können Navigations-Timing-Daten verwenden, um die Erfahrung des Endbenutzers beim Laden der überwachten Webseite zu optimieren.
Messungen können für jede Radarsitzung durchgeführt werden (falls aktiviert). Jede Sitzung ist an eine ID-Nummer angehängt, mit der alle Messungen aus einer Sitzung verfolgt werden können. Diese Messungen werden mit Kunden als Navigation Timing Logs über NEM geteilt.
Das Folgende ist ein Beispiel für die Navigations-Timing-Daten im TSV-Dateiformat.
Im Folgenden sind die Spaltenüberschriften und Beschreibungen für Navigations-Timing-Protokolle aufgeführt. Die Felder werden in der folgenden Reihenfolge in den Ausgabedateien angezeigt:
Protokoll | Beschreibung |
---|---|
Zeitstempel | Es ist die UTC-Zeit der Anfrage im Format YYYY-MM-DDTHH: MI: SSZ. Der tatsächliche Wert (auf die Sekunde herunter) in den Protokolltabellen wird auf die nächste Stunde (2018-03-30T23:00:00Z) bzw. den nächsten Tag (2018-03-30T00:00:00Z) in den Stunden-/Tag-Tabellen gerundet. Es ist in allen Datensätzen immer in UTC. |
Antwortcode | Ergebnis der Messung, z. B. 0: Erfolg, 1: Timeout, 4: Fehler. Für Verfügbarkeitsberechnungen wird der Prozentsatz der Messungen mit einer Antwort von 0 (Erfolg) im Vergleich zur Gesamtzahl der Messungen (insgesamt) ermittelt. Bei anderen Sondentypen (RTT und Durchsatz) berücksichtigt der Filter bei der Berechnung von Statistiken im RTT nur RTT-Datenpunkte mit einem Erfolgscode von 0. Gleiches für den Durchsatz. |
Resolver-Markt | Der Markt des DNS-Resolvers, der die Anfrage bearbeitet hat. Im Allgemeinen der Kontinent, auf dem sich der DNS-Resolver befindet, wo, 0: Unbekannt (XX), 1: Nordamerika (NA) 5: Afrika (AF), 3: Europa (EU), 4: Asien (AS), 2: Ozeanien (OC), 6: Südamerika (SA). |
Resolver Land | Das Land des DNS-Resolvers, der die Anforderung bearbeitet hat. IDs können unter https://community-radar.citrix.com/ref/countries.json.gz Namen zugeordnet werden. |
Region “Resolver” | Die Region des DNS-Resolvers, der die Anforderung verarbeitet hat. IDs können unter https://community-radar.citrix.com/ref/regions.json.gz Namen zugeordnet werden. Nicht alle Länder der Welt haben definierte Regionen. |
Auflösungsstatus | Der Status des DNS-Resolvers, der die Anfrage verarbeitet hat. IDs können unter https://community-radar.citrix.com/ref/states.json.gz Namen zugeordnet werden. Nicht alle Länder der Welt haben definierte Staaten. |
Auflösungsvorabschuss-ASN | Die Autonomous System Number (ASN) des DNS-Resolvers, der die Anforderung bearbeitet hat. Im Allgemeinen die ASN, die über den DNS-Resolver verfügt. IDs können unter https://community-radar.citrix.com/ref/asns.json.gz Namen zugeordnet werden. |
Resolver-IP | Die IP-Adresse des DNS-Resolvers, von dem unsere Infrastruktur die DNS-Anfrage erhalten hat. |
Kunden-Markt | Der Markt des Endverbrauchers, der diese Messung generiert hat. Im Allgemeinen der Kontinent, auf dem sich die Client-IP befindet; wobei 0: Unbekannt (XX), 1: Nordamerika (NA) 5: Afrika (AF), 3: Europa (EU), 4: Asien (AS), 2: Ozeanien (OC), 6: Südamerika (SA). |
Land des Kunden | Das Land des Endbenutzers, der diese Messung generiert hat.IDs können Namen unter https://community-radar.citrix.com/ref/countries.json.gz |
Region des Kunden | Die Region des Endbenutzers, der diese Messung generiert hat. Im Allgemeinen die geografische Region, in der sich die Client-IP befindet. IDs können unter https://community-radar.citrix.com/ref/regions.json.gz Namen zugeordnet werden. Nicht alle Länder der Welt haben definierte Regionen. |
Client-Status | Der Status des Endbenutzers, der diese Messung generiert hat. Im Allgemeinen der Staat, in dem sich die Client-IP befindet. IDs können unter https://community-radar.citrix.com/ref/states.json.gz Namen zugeordnet werden. Nicht alle Länder der Welt haben definierte Staaten. |
Kunden-ASN | Die Autonomous System Number (ASN) des Endbenutzers, der diese Messung generiert hat. Im Allgemeinen die ASN, die die Client-IP hat. IDs können unter https://community-radar.citrix.com/ref/asns.json.gz Namen zugeordnet werden. |
Client-IP | Die IP des Endbenutzers, der die Messung generiert hat. |
Referrer-Host | Die Referer-Informationen (Protokoll, Host und Pfad) stammen aus dem Referer-Header der HTTP-Anforderung an Radar. |
Referrer-Protokoll | Die Referer-Informationen (Protokoll, Host und Pfad) stammen aus dem Referer-Header der HTTP-Anforderung an Radar. |
Referrer-Pfad | Die Referer-Informationen (Protokoll, Host und Pfad) stammen aus dem Referer-Header der HTTP-Anforderung an Radar. |
Geräte-Kategorie | Alle Geräte sind in eines der folgenden Kategorien unterteilt: Smartphone, Tablet, PC, Smart TV und Andere. ‘Andere’ wird als Standardwert verwendet, wenn der Parser den Wert für keines der Felder ermitteln kann. |
Gerät | Der Typ des Geräts, auf dem sich der Benutzer befindet, z. B. ein Apple iPhone. Die Benutzer-Agent-Zeichenfolge erkennt sie im Browser, der auf der Seite ausgeführt wird, auf der das Radar-Tag gehostet wird. |
Browser | Der Typ des Browsers, den der Benutzer verwendet, z. B. Mobile Safari UI/WKWebView 0.0.0. Die Benutzer-Agent-Zeichenfolge erkennt sie im Browser, der auf der Seite ausgeführt wird, auf der das Radar-Tag gehostet wird. |
Betriebssystem | Das verwendete Betriebssystem, z. B. iOS 11.0.3. Die Benutzer-Agent-Zeichenfolge erkennt sie im Browser, der auf der Seite ausgeführt wird, auf der das Radar-Tag gehostet wird. |
DNS-Nachschlagezeit | Mit der Resource Timing API wird die Differenz zwischen dem Ende der Domänensuche und dem Start der Domänensuche berechnet. Es berechnet, wenn beide Werte nicht Null sind und die Endzeit größer als die Startzeit ist. Sie wird als domainLookupEnd - domainLookupStart berechnet. |
TCP-Verbindungszeit | Mit der Resource Timing API wird der Unterschied zwischen dem Connect End und Connect Start berechnet. Es berechnet, wenn beide Werte nicht Null sind und die Endzeit größer als die Startzeit ist. Es wird als connectEnd - connectStart berechnet. |
Sichere Verbindungszeit | Mit der Resource Timing API wird der Unterschied zwischen dem Connect End und dem Secure Connection Start berechnet. Es berechnet, wenn beide Werte nicht Null sind und die Endzeit größer als die Startzeit ist. Sie wird als connectEnd - secureConnectionStart berechnet. |
Load-Ereignis | Dies ist die Dauer oder Zeit, die benötigt wird, um vom Anfang bis zum Ende des Ladeereignisses zu gelangen. Sie wird als LoadEventEnd - LoadEventStart berechnet, wenn beide Werte nicht null sind und die Endzeit größer als die Startzeit ist. |
Umleiten | Dies ist die Dauer oder Zeit, die benötigt wird, um vom Navigationsstart zum Abrufen von Start zu gelangen. Sie wird als FetchStart - NavigationStart berechnet, wenn beide Werte nicht null sind und die Endzeit größer als die Startzeit ist. |
Gesamte Seitenladezeit | Dies ist die Dauer oder Zeit, die benötigt wird, um vom Beginn der Navigation bis zum Ende des Seitenladevorgangs zu gelangen. Sie wird berechnet als - Ereignisende laden - Navigationsstart, wenn beide Werte nicht Null sind und die Endzeit größer als die Startzeit ist. |
DOM | Die Dauer oder Zeit, die vom DOM-Laden zum DOM-Abschluss genommen wird. Sie wird als DomComplete - DomLoading berechnet, wenn beide Werte nicht Null sind und die Endzeit größer als die Startzeit ist. |
Latenz | Mit der Resource Timing API wird die Differenz zwischen dem Start der Antwort und dem Start der Anfrage berechnet. Es wird berechnet, wenn beide Werte nicht Null sind und die Startzeit der Antwort größer als die Startzeit der Anforderung ist. Es wird als responseStart - requestStart berechnet |
Download-Zeit | Mit der Resource Timing API wird die Differenz zwischen dem Ende der Antwort und dem Start der Antwort berechnet. Es berechnet, wenn beide Werte nicht Null sind und die Endzeit größer als die Startzeit ist. Sie wird als responseEnd - responseStart berechnet. |
DOM interaktiv | Die Dauer oder Zeit, die für den Wechseln von Navigation Start zu DOM Interactive gebraucht wird. Sie wird als DomInteractive - NavigationStart berechnet, wenn beide Werte nicht null sind und die Endzeit größer als die Startzeit ist. |
Rendern starten | Die Dauer oder Zeit, die für das Wechseln von Navigationsstart zum Rendern starten gebraucht wird. Sie wird als startRender - NavigationStart berechnet, wenn beide Werte nicht Null sind und die Endzeit größer als die Startzeit ist. |
Openmix und HTTP Openmix Protokolle
Openmix- und HTTP Openmix-Logs ermöglichen es Kunden, Echtzeitmessungen zu verwenden, um das Verhalten ihrer Openmix-Apps zu überwachen. Sie können diese Daten verwenden, um Verbesserungsmöglichkeiten zu finden oder die erwartete Leistung ihrer Apps zu überprüfen.
- Diese Protokolle bieten Echtzeitmessungen für Openmix-Kunden.
- Das empfohlene Dateiformat für diese Protokolle ist JSON, aber sie sind auch im TSV-Format verfügbar.
- Hier sind Beispiele für Openmix - und HTTP Openmix-Log-Sharing-Daten im TSV-Dateiformat.
Openmix Log-Beschreibungen
Protokoll | Beschreibung |
---|---|
Zeitstempel | Es ist die UTC-Zeit der Anfrage im Format YYYY-MM-DDTHH: MI: SSZ. Der tatsächliche Wert (auf die Sekunde herunter) in den Protokolltabellen wird auf die nächste Stunde (2018-03-30T23:00:00Z) bzw. den nächsten Tag (2018-03-30T00:00:00Z) in den Stunden-/Tag-Tabellen gerundet. Der Zeitstempel ist in allen Datensätzen immer in UTC angegeben. |
App-Besitzer-Zonen-ID | Die Zonen-ID des Anwendungseigentümers, der die Anforderung bearbeitet. Dieser Wert ist immer gleich 1. |
App-Besitzer-Kundennummer | Die Kunden-ID des Anwendungseigentümers, der die Anfrage bearbeitet. Bei HTTP-Anfragen kodieren Sie diese ID im Anforderungspfad und verwenden Sie sie, um nachzuschlagen, welche Anwendung ausgeführt werden soll. |
App-ID | Die Anwendungs-ID innerhalb des Kundenkontos, die die Anfrage bearbeitet. Diese ID ist auch im HTTP-Anforderungspfad codiert. Anwendungs-IDs beginnen bei 1 und sind nur für den Kunden eindeutig. Sie müssen Abfragen für eine bestimmte App-ID vollständig qualifizieren, indem Sie die appOwnerCustomerId abfragen. |
App-Version | Die Version der Anwendung, die das Konto bedient hat. Jedes Mal, wenn eine Anwendung über das Portal oder die API aktualisiert wird, wird die Version inkrementiert. Die Version, die zum Zeitpunkt der Anfrage ausgeführt wurde, wird aufgezeichnet. Diese Informationen können verwendet werden, um versionierte Logik im Laufe der Zeit zu trennen, wenn Anwendungen aktualisiert werden. Hosts im gesamten Netzwerk erhalten Updates in der Regel in einem ähnlichen Zeitraum, jedoch fast nie genau zum gleichen Zeitpunkt. Es ist wahrscheinlich, dass sich überlappende Entscheidungen im Laufe der Zeit während des Aktualisierungsprozesses unterschiedliche Versionen einer App verwenden. |
App-Name | Der Name der Anwendung, die das Konto bedient hat. |
Market | Der Markt des Endverbrauchers, der diese Messung generiert hat. |
Land | Das Land des Endbenutzers, der diese Messung generiert hat. |
Region | Die Region des Endbenutzers, der diese Messung generiert hat. |
Status | Der Status des Endbenutzers, der diese Messung generiert hat. |
ASN-ID | Die Autonomous System Number (ASN) des Endbenutzers, der diese Messung generiert hat. Im Allgemeinen die Autonome Systemnummer, die die Client-IP hat. |
ASN Name | Der Name der ASN des Endbenutzers, der die Messung generiert hat. |
Effektive IP | Die effektive IP ist die IP, die zur Verarbeitung der Anfrage verwendet wird. Es ist die von der Abfragezeichenfolge angegebene IP, die die anfordernde IP außer Kraft setzt (im Gegensatz zur Resolver/ECS/EDNS-ID für den DNS-Fluss). Es ist die Adresse, die das System bei der Verarbeitung der Informationen als Ziel berücksichtigt. Diese IP ist entweder die IP des anfordernden Resolvers oder die ECS-IP-Adresse des Clients, falls EDNS ECS unterstützt wird. Alle Probe-Performance-Daten, geographische Informationen usw., die an die Anwendungslogik übergeben werden, basieren auf dieser IP. |
Resolver-Markt | Der Markt des DNS-Resolvers, der die Anfrage bearbeitet hat. |
Resolver Land | Das Land des DNS-Resolvers, der die Anfrage bearbeitet hat. |
Region “Resolver” | Die Region des DNS-Resolvers, die die Anforderung bearbeitet hat. |
Auflösungsstatus | Der Status des DNS-Resolvers, der die Anforderung bearbeitet hat. |
ASN-ID des Resolvers | Die Autonomous System Number (ASN) des DNS-Resolvers, der die Anforderung bearbeitet hat. Im Allgemeinen die Autonome Systemnummer, die über den DNS-Resolver verfügt. |
Name der Resolver-ASN | Der Name der ASN des Resolvers, der die Anforderung bearbeitet hat. |
Resolver-IP | Die IP-Adresse des DNS-Resolvers, von dem unsere Infrastruktur die DNS-Anfrage erhalten hat. |
Name des Entscheidungsanbieters | Alias der Plattform, die eine Anwendung auswählt. |
Ursachencode | In der Anwendung festgelegter Ursachencode, der den Grund für die Entscheidung beschreibt. |
Ursache-Protokoll | Dieses Protokoll ist eine vom Kunden definierte Ausgabe der Openmix-App. Es ist ein optionales Zeichenfolgenfeld, mit dem Kunden Informationen über ihre Openmix-App-Entscheidungen protokollieren können. |
Fallback-Modus | Dieser Modus zeigt an, ob sich die App bei der Bearbeitung der Anfrage im Fallback-Modus befand. Fallback tritt auf, wenn während der Vorbereitung der Anforderung zur Ausführung etwas fehlgeschlagen ist. |
Gebrauchte EDNS | True, wenn die Anwendung eine EDNS Client Subnet-Erweiterung verwendet. |
TTL | Die TTL (Time To Live), die zurückgegeben wurde. |
Antwort | Der von der Anfrage zurückgegebene CNAME. |
Ergebnis | Der Wert in diesem Feld ist immer 1. |
Kontext | Es ist die Zusammenfassung der Radardaten, die Openmix zur Verfügung standen, als die Anfrage bearbeitet wurde. Openmix löst Radardaten relativ zu den effektiven Werten für jede Anfrage auf, sodass zwei Clients, die gleichzeitig Anfragen stellen, unterschiedliche Kontext-Strings haben können. |
Openmix HTTP-API-Protokollbeschreibungen
Protokoll | Beschreibung |
---|---|
Zeitstempel | Es ist die UTC-Zeit der Anfrage im Format YYYY-MM-DDTHH: MI: SSZ. Der tatsächliche Wert (auf die Sekunde herunter) in den Protokolltabellen wird auf die nächste Stunde (2018-03-30T23:00:00Z) bzw. den nächsten Tag (2018-03-30T00:00:00Z) in den Stunden-/Tag-Tabellen gerundet. Der Zeitstempel ist in allen Datensätzen immer in UTC angegeben. |
App-Besitzer-Zonen-ID | Die Zonen-ID des Anwendungseigentümers, der die Anforderung bearbeitet. Dieser Wert ist immer gleich 1. |
App-Besitzer-Kundennummer | Die Kunden-ID des Anwendungseigentümers, der die Anfrage bearbeitet. Bei HTTP-Anfragen kodieren Sie diese ID im Anforderungspfad und werden verwendet, um nachzuschlagen, welche Anwendung ausgeführt werden soll. |
App-ID | Die Anwendungs-ID innerhalb des Kundenkontos, die die Anfrage bearbeitet. Diese ID ist auch im HTTP-Anforderungspfad codiert. Anwendungs-IDs beginnen bei 1 und sind nur für den Kunden eindeutig. Sie müssen Abfragen für eine bestimmte App-ID vollständig qualifizieren, indem Sie die appOwnerCustomerId abfragen. |
App-Version | Die Version der Anwendung, die das Konto bedient hat. Jedes Mal, wenn eine Anwendung über das Portal oder die API aktualisiert wird, wird die Version inkrementiert. Die Version, die zum Zeitpunkt der Anfrage ausgeführt wurde, wird aufgezeichnet. Diese Informationen können verwendet werden, um versionierte Logik im Laufe der Zeit zu trennen, wenn Anwendungen aktualisiert werden. Hosts im gesamten Netzwerk erhalten Updates in der Regel in einem ähnlichen Zeitraum, jedoch fast nie genau zum gleichen Zeitpunkt. Es ist wahrscheinlich, dass sich überlappende Entscheidungen im Laufe der Zeit während des Aktualisierungsprozesses unterschiedliche Versionen einer App verwenden. |
App-Name | Der Name der Anwendung, die das Konto bedient hat. |
Market | Der Markt des Endverbrauchers, der diese Messung generiert hat. |
Land | Das Land des Endbenutzers, der diese Messung generiert hat. |
Region | Die Region des Endbenutzers, der diese Messung generiert hat. |
Status | Der Status des Endbenutzers, der diese Messung generiert hat. |
ASN-ID | Die ID der Autonomous System Number (ASN) des Endbenutzers, der diese Messung generiert hat, d. h. die Netzwerk-ID-Nummer, die mit dem ASN-Namen verknüpft ist |
ASN Name | Der Name der ASN des Endbenutzers, der die Messung generiert hat. |
Effektive IP | Die effektive IP ist die IP, die zur Verarbeitung der Anfrage verwendet wird. Es ist die von der Abfragezeichenfolge angegebene IP, die die anfordernde IP außer Kraft setzt (im Gegensatz zur Resolver/ECS/EDNS-ID für den DNS-Fluss). Es ist die Adresse, die das System bei der Verarbeitung der Informationen als Ziel berücksichtigt. Diese IP ist entweder die IP des anfordernden Resolvers oder die ECS-IP-Adresse des Clients, falls EDNS ECS unterstützt wird. Alle Daten zur Sondenleistung, geografischen Informationen usw., die an die Anwendungslogik weitergegeben werden, basieren auf dieser IP. |
Name des Entscheidungsanbieters | Alias der Plattform, die eine Anwendung auswählt. |
Ursachencode | In der Anwendung festgelegter Ursachencode, der den Grund für die Entscheidung beschreibt. |
Ursache-Protokoll | Dieses Protokoll ist eine vom Kunden definierte Ausgabe der Openmix-App. Es ist ein optionales Zeichenfolgenfeld, mit dem Kunden Informationen über ihre Openmix-App-Entscheidungen protokollieren können. |
Fallback-Modus | Dieser Modus zeigt an, ob sich die App bei der Bearbeitung der Anfrage im Fallback-Modus befand. Fallback tritt auf, wenn während der Vorbereitung der Anforderung zur Ausführung etwas fehlgeschlagen ist. |
Antwortcode | Ergebnis der Messung, z. B. 0: Erfolg, 1: Timeout, 4: Fehler. Für Verfügbarkeitsberechnungen wird der Prozentsatz der Messungen mit einer Antwort von 0 (Erfolg) im Vergleich zur Gesamtzahl der Messungen (gesamt, unabhängig von der Reaktion) ermittelt. Bei anderen Sondentypen (RTT und Durchsatz) darf der Filter bei der Berechnung von Statistiken im RTT nur RTT-Datenpunkte mit einem Erfolgscode von 0 berücksichtigen. Gleiches für den Durchsatz. |
HTTP-Methode | Die HTTP-Methode (GET/POST/OPTIONS/etc) bezieht sich auf die Anfrage, die von einem Kundendienst an den HTTP Openmix-Server gestellt wurde. Zusammen bilden diese Methoden Teile der eingehenden URL und der ausgehenden HTTP-Antworten. |
URI | Es ist der Anforderungspfad. Wenn Kunden nicht das gewünschte Verhalten erhalten, kann dies an einer falsch strukturierten Anfrage liegen. Die Protokolle zeigen, was unsere Server empfangen (Protokoll, Host und Pfad). Die Referer-Informationen (Protokoll, Host und Pfad) stammen aus dem Referer-Header der HTTP-Anforderung an Radar. Für HTTP OPX ist der gesamte Referer (Protokoll, Host und Pfad) in einer Zeichenfolge mit der Bezeichnung Referer enthalten. |
Benutzeragent | Es ist die Benutzer-Agent-Zeichenfolge von der Browserseite, die das Tag hostet. Wenn Sie beispielsweise Chrome verwenden und eine Seite mit dem Radar-Tag durchsuchen, zeichnet die Radarmessung im Hintergrund den Benutzeragenten in Ihrem Chrome-Browser auf. Die Messungen umfassen den Chrome-Browser, die Version von Chrome, Informationen über das Betriebssystem, auf dem Chrome ausgeführt wird, und so weiter. |
Kontext | Es ist die Zusammenfassung der Radardaten, die Openmix zur Verfügung standen, als die Anfrage bearbeitet wurde. Openmix löst Radardaten relativ zu den effektiven Werten für jede Anfrage auf, sodass zwei Clients, die gleichzeitig Anfragen stellen, unterschiedliche Kontext-Strings haben können. |
Benutzerdefinierte Berichte für Drittanbieter
Kunden können mit NetScaler zusammenarbeiten, um benutzerdefinierte Berichte zu erhalten, die auf Radardaten basieren, die NetScaler sammelt. NetScaler kann Berichte generieren, die nach einem Zeitplan ausgeführt werden. Die Berichte sind als Datendateien verfügbar, normalerweise im TSV-Format.
Häufig gestellte Fragen
Radar
Wie häufig werden Dateien auf S3 und GCS übertragen?
Die Häufigkeit der Dateieinzahlungen beträgt einmal pro Minute für Radar und täglich für Berichte.
Wo werden die Berichte gespeichert?
S3 Legacy (Standort 1):
s3://public-radar/[customer name]/
S3 (Standort 2):
s3://cedexis-netscope/[customer id]/
GCS (Standort 3):
gs://cedexis-netscope-[customer id]/
Wie erhalte ich S3-Zugangsdaten, wenn Sie diese noch nicht haben?
Das Portal bietet einen “Access” - und “Secret” -Schlüssel. Verwenden Sie die Tasten mit ‘s3cmd’, ‘awscli’ oder anderen Tools, um auf S3 zuzugreifen. Für Google Storage lädt das Portal eine Datei mit Zugangsdaten zur Verwendung mit dem Tool ‘gsutil’ herunter.
Wie verwende ich die Zugriffs- und geheimen Schlüssel mit s3cmd, um Protokolle und Berichte aus dem S3-Bucket herunterzuladen?
Zuerst müssen Sie s3cmd
von https://s3tools.org/download herunterladen und installieren. Informationen zur Verwendung, Optionen und Befehle finden Sie unter https://s3tools.org/usage. Führen Sie dann den folgenden Befehl aus:
s3cmd --access_key=[access key] --secret_key=[secret key] ls s3://cedexis-netscope/<customer id>/radar/
<!--NeedCopy-->
Führen Sie den folgenden Befehl aus, um die Dateien herunterzuladen:
s3cmd --access_key=[access_key] --secret_key=[secret_key] get s3://cedexis-netscope/<customer id>/radar/[the_filename_to_download] [the_name_of_the_local_file]
<!--NeedCopy-->
So verwenden Sie die s3cmd-Konfiguration, um Dateien im S3-Bucket aufzulisten
Der erste Schritt ist die Installation s3cmd
. Sie können es installieren von http://s3tools.org/download
Führen Sie den folgenden Befehl aus, um s3cmd zu konfigurieren
s3cmd ls s3://cedexis-netscope/[customer id]/
<!--NeedCopy-->
Wenn Sie bereitss3cmd
mit einem anderen Satz von Zugriffs- und geheimen Schlüsseln verwenden, gehen Sie folgendermaßen vor:
Wenn Sie bereits verwenden s3cmd
, erstellen Sie eine Kopie der Standardkonfiguration unter ~/.s3cfg
. Erstellen Sie beispielsweise eine Kopie und nennen Sie sie als ~/.s3cfg_netscope
. Ersetzen Sie die Access- und Secret-Key-Einträge in ~/.s3cfg_netscope
durch die von uns bereitgestellten.
Verwenden Sie die neue Konfiguration anstelle der Standardkonfiguration (die Ihres Unternehmens), um mit folgendem Befehl auf den S3-Bucket zuzugreifen:
s3cmd -c ~/.s3cfg_netscope ls s3://cedexis-netscope/[customer id]/
<!--NeedCopy-->
Der Hauptunterschied ist, dass Sie eine-c
und wo sich die Konfigurationsdatei mit den von Citrix bereitgestellten Zugriffs- und geheimen Schlüsseln befindet.
Wenn Sie zwischen den Schlüsseln wechseln möchten, betten Sie sie in eine Datei ein. Beziehen Sie sich auf die Datei mit der Option -c
, um anzugeben, welches Schlüsselpaar Sie verwenden.
HINWEIS:
-c
Parameter gibt an, wo die Konfigurationsdatei ist, die den Zugriff und die geheimen Schlüssel enthält.
So verwenden Sie die Schlüsseldatei mit gsutil oder gcloud zum Herunterladen von Protokolldateien
Sobald Sie die JSON-Schlüsseldatei des Google-Dienstkontos heruntergeladen haben, können Sie sie verwenden, um die Anmeldeinformationen Ihres Google-Kontos zu authentifizieren, Ihre Protokolldateien anzuzeigen oder herunterzuladen. Hier ist zum Beispiel eine Möglichkeit, dies mit den Befehlszeilenprogrammen von Google gcloud
und gsutil
zu tun:
Schritt 1: Schlüsseldatei aktivieren
Die Authentifizierungsbefehle gcloud auth activate-
oder gsutil config -e
sind erforderlich, um die Schlüsseldatei für die Ausführung von gcloud- oder gsutil-Befehlen zu authentifizieren.
Für gcloud:
Führen Sie den folgenden Befehl mit der heruntergeladenen Schlüsseldatei aus:
gcloud auth activate-service-account --key-file [downloaded config file]
<!--NeedCopy-->
Oder
gcloud auth activate-service-account --key-file=[path and file name of key file]
<!--NeedCopy-->
Für Gsutil:
Führen Sie den folgenden Befehl mit der heruntergeladenen Konfigurationsdatei aus:
gsutil config -e
<!--NeedCopy-->
Schritt 2: Listen Sie die Dateien im GCS (Google Cloud Storage) Bucket auf
Nachdem Sie die Dienstkontoschlüsseldatei wie im vorherigen Schritt beschrieben aktiviert haben, führen Sie den folgenden Befehl aus, um die Dateien im GCS-Bucket aufzulisten:
gsutil ls gs://cedexis-netscope-<customer id>
<!--NeedCopy-->
Schritt 3 (falls erforderlich): Wiederherstellen der ursprünglichen Anmeldeinformationen (oder Wechseln zwischen Konten)
Gehen Sie wie folgt vor, um zwischen dem NetScaler ITM-Konto und anderen von Ihnen authentifizierten Google Cloud-Anmeldeinformationen zu wechseln.
Führen Sie zunächst den folgenden Befehl aus, um alle Ihre Konten aufzulisten:
gcloud auth list
<!--NeedCopy-->
Verwenden Sie dann den folgenden Befehl, um zu einem anderen Konto zu wechseln:
gcloud config set account [email of the account to switch to as shown in gcloud auth list]
<!--NeedCopy-->
Sie können mit demselben Befehl zwischen Konten hin- und herwechseln, indem Sie die E-Mail durch die Konto-E-Mail ersetzen, zu der Sie wechseln möchten.
Wie sieht der Dateiname aus?
Legacy Täglich:
Die ShareFile-Namen des täglichen Radarprotokolls haben diese Struktur:
<prefix><date: YYYY-MM-DD>.<customer_id>.part<uniq_id>.kr.txt.gz
Zum BeispielCedexis_Daily-2017-11-07.21222.part-cc901e1dd55eal4e.kr.txt.gz
(nicht standardmäßiges Beispiel)
Legacy-Echtzeit-Version:
Die ShareFile-Namen des Radar-Echtzeitprotokolls haben diese Struktur:
<prefix><customer_id>-YYYY-MM-DDTHH:MM<uniq_id>.txt.gz
Zum Beispiel Cedexis_3-32291-2017-11-08T20:56-cc907e8fd71eaf4e.txt.gz
Netscope NEM-Format:
Das Netscope NEM-Format für tägliche und Echtzeit-Protokollfreigabedateien hat folgende Struktur:
<freq><log_type><prefix><id_type><id><iso_dt><uniq_id>.<line_format>.gz
Hierbei gilt:
-
freq
:"daily" | "rt" | "hr"
-
log_type
:"radar" | "opx" | "hopx"
-
prefix
:log_share.prefix
-
id_type
:"customer" | "provider" | "asn"
-
id
:log_share.match_id
-
iso_dt
:iso 8601 Date_time "YYYYMMDDTHHMMSSZ"
-
uniq_id
:hash(UUID)
-
line_format
:"tsv" | "json"
Zum Beispiel rt-radar-TestRadar1-provider-20363-20171209183034Z-cc907e8fd71eaf4e.tsv.gz
Was ist das Format der Ausgabedatei?
Für Radar ist das Ausgabedateiformat TSV (tabulatorgetrennter Wert), gzipped.
Openmix und Openmix HTTP API
Wie oft werden Dateien auf S3 übertragen?
Die Häufigkeit der Dateieinlagen beträgt einmal pro Minute für Openmix und HTTP Openmix.
Was ist, wenn Sie die Option zur Konfiguration der Echtzeit-Logfreigabe von Openmix und Openmix HTTP API nicht sehen können?
Ihr Account Manager kann die erforderliche Rolle für die Konfiguration und Aktivierung von Openmix und Openmix HTTP API in Echtzeit Log Sharing aktivieren.
Wie aktiviert man Openmix und eine Openmix HTTP API Echtzeit-Log-Sharing und greift auf Dateien zu?
Sobald die Rolle in Ihrem Konto aktiviert ist, wird das Symbol “Protokolle verwalten “ angezeigt. Klicken Sie hier, um den Dialog Logs zu öffnen, in dem Sie auf die Einstellungen der Openmix Log Diese Einstellungen sind im Grunde alles, was Sie benötigen, um Openmix und HTTP Openmix in Echtzeit Log-Sharing einzuschalten und auf Dateien zuzugreifen.
Was ist der Back-End-Prozess?
Das Aktivieren der Openmix-Logfreigabe ermöglicht auch die Openmix HTTP-API-Protokollfreigabe. Die Openmix- und Openmix-HTTP-API-Log-Sharing-Dienste müssen innerhalb von 10 Minuten mit der Ausgabe von Protokollen für den Kunden beginnen.
Wo werden die Openmix- und HTTP-Openmix-Berichte gespeichert?
S3 Legacy (Standort 1):
s3://logshare/[zone ID]/[customer ID]/logs/openmix/json/[YYYY]/[MM]/[DD]/[HH]/.
S3 (Standort 2):
s3://cedexis-netscope/[customer id]/
GCS (Standort 3):
gs://cedexis-netscope-[customer id]/
Wie sieht der Dateiname aus?
Die Dateinamenstruktur für Openmix und HTTP Openmix sieht normalerweise wie folgt aus:
Legacy-Echtzeit-Version:
[zone ID, 1][customerID]-openmix-json[YYYY][MM][DD][HH][mm][ss]Z-m1-w9-c0.gz
Netscope NEM-Format:
Das Netscope NEM-Format für tägliche und Echtzeit-Protokollfreigabedateien hat folgende Struktur:
<freq><log_type><prefix><id_type><id><iso_dt><uniq_id>.<line_format>.gz
Hierbei gilt:
-
freq
:"daily" | "rt" | "hr"
-
log_type
:"radar" | "opx" | "hopx"
-
prefix
:log_share.prefix
-
id_type
:"customer" | "provider" | "asn"
-
idv
:log_share.match_id
-
iso_dt
:iso 8601 Date_time "YYYYMMDDTHHMMSSZ"
-
uniq_id
:hash(UUID)
-
line_format
:"tsv" | "json"
Zum Beispiel hr-opx-TestOpenmix1-provider-20363-20171209183034Z-cc907e8fd71eaf4e.tsv.gz
Was ist das Ausgabedateiformat?
Das Dateiformat für Openmix und eine Openmix HTTP API ist JSON (gzipped).
In diesem Artikel
- Übersicht
- Teilen von Protokollen und
- Navigation
- Plattformen und Netzwerke
- Plattformberichte
- Netzwerkberichte
- Radarprotokolle
- Navigationszeitprotokolle
- Openmix Protokolle
- Bereitstellung von Cloud-Diensten
- Radarprotokollbeschreibungen und Berichte für Service Provider und Unternehmen
- Radarprotokollbeschreibungen und Berichte für ISPs
- Beschreibung des Navigations-Timing-
- Openmix und HTTP Openmix Protokolle
- Openmix Log-Beschreibungen
- Openmix HTTP-API-Protokollbeschreibungen
- Benutzerdefinierte Berichte für Drittanbieter
- Häufig gestellte Fragen