Überwachung der Netzwerkerfahrung

Übersicht

Der Network Experience Monitoring (NEM)-Dienst (früher Netscope genannt) ermöglicht Dienstanbietern, Unternehmen, ISPs und Drittanbietern den Zugriff auf detaillierte Radarmessprotokolle und Standardberichte in Form von zusammengefassten, umsetzbaren 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 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 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 Details zum Ressourcen-Timing die Option Zeitstempel in den erweiterten Radar.

Wählen Sie im Hauptmenü Netscope NEMaus. Die Seite Konfiguration der Network Experience Monitoring wird geöffnet.

Navigation

Plattformen

Wählen Sie die erforderlichen Plattformen aus, um den Konfigurationsvorgang 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, beinhalten Radarmessungen ausgewählter Plattformen (für alle zugehörigen Netzwerke).

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.

Plattformen

Radarprotokolle

  • Radarprotokolle sind für Plattformen 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.

Protokollkonfiguration

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.

Navigationszeitprotokolle

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.

Openmix Protokolle

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.

AWS S3

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.

GCS

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:

Protokollierung 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).

Beschreibung des Navigations-Timing-

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:

Protokollierung 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

Protokollierung 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

Protokollierung 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 besteht darin, dass Sie ein -c angeben müssen sowie die Angabe, wo sich die Konfigurationsdatei mit den von NetScaler bereitgestellten Zugriffs- und Geheimschlü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.

Openmix-Protokollkonfiguration

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).