Netzwerk-Erfahrungsüberwachung
Übersicht
Der Dienst zur Netzwerk-Erfahrungsüberwachung (NEM) (früher Netscope genannt) ermöglicht Dienstanbietern, Unternehmen, ISPs und Drittanbietern den Zugriff auf detaillierte Radar-Messprotokolle und Standardberichte in Form von zusammengefassten, umsetzbaren Daten. NEM bietet verschiedene Standardprotokolle und Berichte, die Kunden zur Messung der Qualität ihrer Dienste verwenden können.
Diese Lösung umfasst die Bereitstellung von “Roh”-Radar-Messdaten und den Zugriff auf die ITM Data API. NEM liefert sowohl die granularen Daten (entweder als Rohmessungen oder Datenaggregate) als auch Daten-Schwellenwertwarnungen. Diese Dienste unterstützen die Erkennung, Isolierung von Plattformverfügbarkeit und Leistungsproblemen bei Plattform-Peers und den zugrunde liegenden ISPs.
Radar-“Roh”-Messungen: Radar-Messungen liefern ereignisbezogene, granulare Informationen, die täglich gebündelt werden. Radar-Messungen umfassen öffentliche Community- und private Messdaten, die vom Tag erfasst werden. Daten wie Verfügbarkeit, Antwortzeit und 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, User-Agent, Endbenutzer-ASN
- Geodaten für Resolver- und Client-Felder
Die in den “Roh”-Messungen verfügbaren Radar-Metriken sind:
- Verfügbarkeit, Antwortzeit und Durchsatz (sofern gemessen)
- DNS-Lookup-Zeit (optional), TCP-Verbindungszeit (optional) und sichere Verbindungszeit (optional)
- Latenz (optional)
- Download-Zeit (optional)
Radar-Messungen stehen Kunden zur Verfügung, um ihre eigenen Analysen der gesammelten Daten durchzuführen. Der Datensatz enthält Informationen zur Anbieterleistung und -verfügbarkeit (Fehler) für eine Reihe von Kommunikationsprotokollen.
Protokolldateidaten sind für 7 Tage aus einem AWS S3- oder Google Cloud Storage-Bucket verfügbar. Kunden können Protokolldateien mit Community- und privaten Daten über Standard-Bucket-Zugriffsmethoden abrufen.
Echtzeit-Radar-“Roh”-Messungen (optional): Roh-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 die gleiche Granularität wie die zuvor erwähnten Radar-Roh-Messungen.
Daten-API: Die ITM Radar-Daten-API bietet Aggregate der öffentlichen Community- und privaten Messdaten von Radar. Die Daten werden kontinuierlich aktualisiert und etwa alle 60 Sekunden für den Abruf über die API gebündelt. Die Daten-API wird bereitgestellt, damit Kunden Radar-Daten in ihre eigenen Berichte und Dashboards integrieren können.
Protokollfreigabe und -bereitstellung
- Radar-Protokolle können in Echtzeit und täglich bereitgestellt 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 eine Woche nach ihrer Erstellung automatisch gelöscht.
- Berichte liegen je nach Berichtstyp in der Regel im TSV- (Tabulator-getrennte Werte) oder JSON-Format vor.
Kunden erhalten Anmeldeinformationen für den Zugriff auf die S3- und GCS-Buckets. Ein Befehlszeilentool wie s3cmd oder die AWS CLI für S3 oder gsutil für GCS kann zum Anmelden verwendet werden. Die s3cmd-Konfigurationsdatei erkennt die über die Portal-Benutzeroberfläche empfangenen Zugriffsschlüssel und hilft dem Benutzer, sich mit dem S3-Bucket zu verbinden.
Die AWS CLI muss auf dem Computer des Kunden installiert sein, um sich mit S3 zu verbinden 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 FAQ.
Kunden erhalten E-Mail-Benachrichtigungen, sobald Berichte verfügbar sind.
Plattform-Einstellungen
Sie müssen Ihre Plattform so konfigurieren, dass sie die für Netscope NEM erforderlichen Daten unterstützt und erzeugt. Stellen Sie vor dem Start sicher, dass die folgenden Einstellungen für Ihre Plattform aktiviert sind:
- Aktivieren Sie für Ressourcentiming-Details die Option Zeitstempel einschließen in den Erweiterten Radar-Einstellungen.
Navigation
Wählen Sie im Hauptmenü Netscope NEM. Die Konfigurationsseite Netzwerk-Erfahrungsüberwachung wird geöffnet.
Plattformen
Wählen Sie die erforderlichen Plattformen 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 Radar-Messungen ausgewählter Plattformen (für alle zugehörigen Netzwerke).
Plattformen auswählen
Für Content-Dienstanbieter oder Unternehmen wählen Sie Plattformen wie CDNs, Clouds, Rechenzentren oder andere Endpunkte aus. Wählen Sie die Plattformen aus, für die Messungen erforderlich sind.
Radar-Protokolle
- Radar-Protokolle sind für Plattformen verfügbar.
- Sie enthalten eine Untermenge der in den Rohprotokollen verfügbaren Felder, wobei einige Daten anonymisiert sind: Client-IP /28, Referer MD5-gehasht.
- Jede für öffentliche Plattformen durchgeführte Messung wird bereitgestellt, unabhängig von der Seite, die die Messung generiert hat.
HINWEIS:
NEM legt niemals vollständige Client-IPs offen. Stattdessen wird die /28 offengelegt. Zum Beispiel wird eine IP von 255.255.255.255 in einem Bericht als 255.255.255.240/28 angezeigt.
Protokollfrequenz
Radar-Protokolle können täglich (alle 24 Stunden), d.h. am Ende des Tages, UTC-Zeit, generiert werden. Protokolle können auch in Echtzeit (minütlich) generiert werden.
Dateiformat
Wählen Sie TSV oder JSON, um Protokolle und Berichte in einem dieser Formate zu erhalten.
Messtyp
Sie können Protokolle für die folgenden Messtypen konfigurieren: Verfügbarkeit, Antwortzeit und Durchsatz. Im Bericht: 1: Verfügbarkeit, 0: HTTP-Antwortzeit und 14: HTTP-Durchsatz.
Ressourcentiming-Details
Sie können auch Ressourcentiming-Details einschließen, indem Sie auf die Schaltflächen Ja oder Nein klicken. Ressourcentiming-Details umfassen:
- DNS-Lookup-Zeit
- TCP-Verbindungszeit
- Sichere Verbindungszeit
- Download-Zeit
Für Protokollbeschreibungen siehe Radar-Protokollbeschreibungen und Berichte für Dienstanbieter und Unternehmen.
Navigation Timing-Protokolle
Protokollfrequenz
Navigation Timing-Protokolle können täglich (alle 24 Stunden), d.h. am Ende des Tages, UTC-Zeit, generiert werden. Protokolle können auch in Echtzeit (minütlich) generiert werden.
Dateiformat
Wählen Sie TSV oder JSON, um Navigation Timing-Protokolle in einem dieser Formate zu erhalten. Für Protokollbeschreibungen siehe Navigation Timing-Protokollbeschreibungen.
Openmix-Protokolle
Protokollfrequenz
Openmix-Protokolle werden in Echtzeit (d.h. minütlich) generiert. Diese Protokolle liefern Echtzeit-Messungen, die für Openmix-Kunden durchgeführt wurden.
Dateiformat
Wählen Sie TSV oder JSON, um Openmix- und HTTP-Openmix-Protokolle in einem dieser Formate zu erhalten. JSON ist jedoch das empfohlene Format.
Für Protokollbeschreibungen siehe Openmix-Protokollbeschreibungen.
Cloud-Dienstbereitstellung
Diese Option ermöglicht Ihnen die Auswahl des Bereitstellungsmodus. Sie können wählen, ob Sie Protokolle und Berichte entweder im AWS S3-Bucket oder im Google Cloud Storage (GCS)-Bucket erhalten möchten.
Sie können auf die S3- und GCS-Buckets mit den bereitgestellten Anmeldeinformationen zugreifen und s3cmd oder die AWS CLI für S3 sowie die gsutil-Befehlszeile für GCS verwenden.
AWS S3
Um Protokolle und Berichte an den AWS S3-Bucket liefern zu lassen, wählen Sie AWS S3.
Speicherort
Der Speicherort repräsentiert den Bucket in AWS S3, in dem die Protokolle und Berichte gespeichert werden.
IAM-Schlüssel
Wenn Sie die Schaltfläche Schlüssel generieren unter AWS S3 auswählen, werden die AWS IAM-Schlüssel (Zugriffs- und Geheimschlüssel) generiert und unter IAM-Schlüssel angezeigt. Stellen Sie sicher, dass Sie die Schlüssel aufzeichnen, da sie später nicht mehr zur Ansicht gespeichert werden.
HINWEIS:
Das Paar aus Zugriffs- und Geheimschlüssel ist die einzige Kopie der privaten Schlüssel. Der Kunde muss sie sicher aufbewahren. Das Neugenerieren der Schlüssel macht die bestehenden ungültig. Die
s3cmd-Konfigurationsdatei erkennt die Zugriffsschlüssel (die über die Portal-Benutzeroberfläche empfangen wurden) und hilft dem Kunden, sich mit dem S3-Bucket zu verbinden. Die AWS CLI muss auf dem Computer des Kunden installiert sein, um sich mit S3 zu verbinden.
Informationen zur Verwendung der Zugriffs- und Geheimschlüssel mit s3cmd zum Herunterladen von Berichten aus dem S3-Bucket finden Sie in den FAQ.
Google Cloud Storage
Um Protokolle und Berichte an GCS liefern zu lassen, wählen Sie Google Cloud Storage.
Speicherort
Der Speicherort repräsentiert den Bucket in Google Cloud Storage, in dem Protokolle und Berichte gespeichert werden.
IAM-Schlüssel
Wenn Sie die Schaltfläche Schlüsseldatei generieren auswählen, wird die Google Service Account Key File 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. Das Neugenerieren einer neuen Schlüsseldatei macht die bestehende Datei ungültig.
Diese Schlüsseldatei kann mit dem gsutil-Tool verwendet werden, um Protokolle und Berichte aus dem GCS-Bucket herunterzuladen. Details zur Verwendung der Schlüsseldatei zum Herunterladen von Protokolldateien finden Sie in den FAQ.
Radar-Protokollbeschreibungen und Berichte für Dienstanbieter und Unternehmen
Radar-Protokolle für Anbieter
- Diese Protokolle liefern Radar-Messungen für Benchmark-Partner.
- Sie stellen jede Messung bereit, die für öffentliche Plattformen durchgeführt wurde, unabhängig von der Seite, die die Messung generiert hat.
- Radar-Protokolle enthalten eine Untermenge der in den Rohprotokollen verfügbaren Felder, wobei einige Daten anonymisiert sind: Client-IP /28, Referer MD5-gehasht.
- Hier ist ein Beispiel für eine Plattform-Radar-Protokollfreigabe im TSV-Dateiformat.
HINWEIS:
- NEM legt niemals vollständige Client-IPs offen. Stattdessen wird die /28 offengelegt. Zum Beispiel wird eine IP von 255.255.255.255 in einem Bericht als 255.255.255.240/28 angezeigt.
- Die GEO-Informationen des Clients werden basierend auf der detaillierteren IPv4 des Clients extrahiert.
Protokollbeschreibungen
Im Folgenden sind die Spaltenüberschriften und Beschreibungen für die Radar-Protokolle aufgeführt. Die Felder erscheinen in den Ausgabedateien in der folgenden Reihenfolge:
| Protokoll | Beschreibung |
|---|---|
| Zeitstempel | Dies ist die UTC-Zeit der Anfrage im Format YYYY-MM-DDTHH:MI:SSZ. Der tatsächliche Wert (bis auf die Sekunde genau) 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-/Tagestabellen gerundet. Der Zeitstempel ist in allen Datensätzen immer in UTC. |
| Eindeutige Knoten-ID | Auch bekannt als Cache-Knoten-ID. Es ist ein beliebiger Wert. Typischerweise eine IP, die die CDN-Edge-Server zurückgeben, um CDNs intern zu helfen, zu identifizieren, welcher Server eine bestimmte Anfrage bearbeitet hat. ‘’ (leerer String): Kommt von Radar-Clients, die keine UNI-Erkennung unterstützen. 0: Der User-Agent unterstützt die für die UNI-Erkennung erforderlichen Funktionen nicht. 1: Der Client stieß während der UNI-Erkennung auf einen Fehler, wie z.B. einen HTTP 404 oder eine andere erfolglose Antwort. 2: Die UNI-Erkennung wurde versucht, führte aber zu einem Fehler. |
| Anbieter-ID | Interne ID der Plattform, die gemessen wird. |
| Sondentyp | Der gemessene Sondentyp (z.B. 1: HTTP-Verbindungszeit, 0: HTTP-Antwortzeit, 14: HTTP-Durchsatz usw.). Um anzuzeigen, dass der Dienst verfügbar ist, verwenden Sie die erfolgreich innerhalb der zulässigen Zeit zurückgegebenen Informationen. |
| Antwortcode | Ergebnis der Messung. Z.B. 0: Erfolg, 1: Timeout, 4: Fehler. Für Verfügbarkeitsberechnungen wird der Prozentsatz der Messungen mit einer 0 (Erfolg) als Antwort im Vergleich zur Gesamtzahl der Messungen (gesamt, unabhängig von der Antwort) herangezogen. Für andere Sondentypen (RTT und Durchsatz) muss der Filter bei der Berechnung von Statistiken über die RTT nur RTT-Datenpunkte mit einem Erfolgscode von 0 berücksichtigen. Gleiches gilt für den Durchsatz. |
| Messwert | Der aufgezeichnete Messwert, dessen Bedeutung je nach Sondentyp variiert. Er repräsentiert Verfügbarkeits- (1)/Antwortzeit- (0) Messungen in Millisekunden und Durchsatz- (14) Messungen in kbps. |
| Resolver-Markt | Der Markt des DNS-Resolvers, der die Anfrage bearbeitet hat. Im Allgemeinen der Kontinent, auf dem sich der DNS-Resolver befindet, wobei 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 Anfrage bearbeitet hat. IDs können unter https://community-radar.citrix.com/ref/countries.json.gz Namen zugeordnet werden. |
| Resolver-Region | Die Region des DNS-Resolvers, der die Anfrage bearbeitet hat. 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. |
| Resolver-Bundesland | Das Bundesland 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 Bundesländer. |
| Resolver-Stadt | Die Stadt des DNS-Resolvers, der die Anfrage bearbeitet hat. Die Resolver-Stadt wird durch Nachschlagen einer Resolver-IP-Adresse hinzugefügt. IDs können unter https://community-radar.citrix.com/ref/cities.json.gz Namen zugeordnet werden. |
| Resolver-ASN | Die Autonomous System Number (ASN) des DNS-Resolvers, der die Anfrage bearbeitet hat. Im Allgemeinen die ASN, die den DNS-Resolver hat. 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. |
| Client-Markt | Der Markt des Endbenutzers, 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). |
| Client-Land | Das Land des Endbenutzers, der diese Messung generiert hat. IDs können unter https://community-radar.citrix.com/ref/countries.json.gz Namen zugeordnet werden. |
| Client-Region | 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. Hinweis: Nicht alle Länder der Welt haben definierte Regionen. |
| Client-Bundesland | Das Bundesland des Endbenutzers, der diese Messung generiert hat. Im Allgemeinen das Bundesland, in dem sich die Client-IP befindet. IDs können unter https://community-radar.citrix.com/ref/states.json.gz Namen zugeordnet werden. Beachten Sie, dass nicht alle Länder der Welt definierte Bundesländer haben. |
| Client-Stadt | Die Stadt des Endbenutzers, der diese Messung generiert hat. Im Allgemeinen die Stadt, in der sich die Client-IP befindet. IDs können unter https://community-radar.citrix.com/ref/cities.json.gz Namen zugeordnet werden. |
| Client-ASN | Die Autonomous System Number (ASN) des Endbenutzers, der diese Messung generiert hat. Im Allgemeinen die ASN, die die Client-IP enthält. 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. |
| Referer Host MD5 | Die Referer-Informationen (Protokoll, Host und Pfad) stammen aus dem Referer-Header der HTTP-Anfrage an Radar. Der Referer-Host ist MD5-gehasht. |
| User-Agent | Dies ist der User-Agent-String der Browserseite, die den Tag hostet. Wenn Sie beispielsweise Chrome verwenden und eine Seite mit dem Radar-Tag durchsuchen, zeichnen die Radar-Messungen im Hintergrund den User-Agent Ihres Chrome-Browsers auf. Die Messungen umfassen den Chrome-Browser, die Chrome-Version, Informationen über das Betriebssystem, auf dem Chrome läuft, und so weiter. |
| DNS-Lookup-Zeit (Optional) | Mit der Resource Timing API wird die Differenz zwischen Domain Lookup End und Domain Lookup Start berechnet. Sie wird 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 die Differenz zwischen Connect End und Connect Start berechnet. Sie wird berechnet, wenn beide Werte nicht null sind und die Endzeit größer als die Startzeit ist. Sie wird als connectEnd - connectStart berechnet. |
| Sichere Verbindungszeit (Optional) | Mit der Resource Timing API wird die Differenz zwischen Connect End und Secure Connection Start berechnet. Sie wird 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 Response Start und Request Start berechnet. Sie wird berechnet, wenn beide Werte nicht null sind und die Antwortstartzeit größer als die Anfragestartzeit ist. Sie wird als responseStart - requestStart berechnet. |
| Download-Zeit (Optional) | Mit der Resource Timing API wird die Differenz zwischen Response End und Response Start berechnet. Sie wird berechnet, wenn beide Werte nicht null sind und die Endzeit größer als die Startzeit ist. Sie wird als responseEnd - responseStart berechnet. |
| Client-Profil | Dieses Feld hilft zu identifizieren, ob die Daten von mobilen Apps oder Browsern stammen. Es ermöglicht auch die Unterscheidung zwischen iOS-, Android-Apps und Browsern. Eine Zahl wird verwendet, um jedes Client-Profil zu identifizieren. Die Werte für dieses Feld sind: null, 0, 1, 2, 3, 4. Wobei null: Im Allgemeinen einen älteren Radar-Client impliziert, der das Senden des client_profile-Werts nicht unterstützt. 0: Browser; 1: iOS - Radar-Runner 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. |
| Client-Profilversion | Die Client-Profilversion gibt an, welche Version des Radar-Runner-Codes (für iOS) oder des AndroidRadar SDK (für Android) in der mobilen App verwendet wurde. Dieses Feld ist nur für den internen Gebrauch bestimmt. |
| Gerätekategorie | Alle Geräte werden in eine der folgenden Kategorien eingeteilt: Smartphone, Tablet, PC, Smart TV und Sonstige. ‘Sonstige’ wird als Standardwert verwendet, wenn der Parser den Wert für eines der Felder nicht bestimmen kann. |
| Gerät | Der Gerätetyp, den der Benutzer verwendet, z.B. ein Apple iPhone. Der User-Agent-String erkennt dies vom Browser, der auf der Seite läuft, die den Radar-Tag hostet. |
| Browser | Der Browsertyp, den der Benutzer verwendet, z.B. Mobile Safari UI/WKWebView 0.0.0. Der User-Agent-String erkennt dies vom Browser, der auf der Seite läuft, die den Radar-Tag hostet. |
| Betriebssystem | Das verwendete Betriebssystem. Zum Beispiel iOS 11.0.3. Der User-Agent-String erkennt dies vom Browser, der auf der Seite läuft, die den Radar-Tag hostet. |
| Berichtende Client-IP | Diese IP ist die maskierte /48 öffentliche IP des Benutzers, der die Messung vornimmt. Es kann entweder IPv4 oder IPv6 sein (sofern unterstützt). |
Navigation Timing-Protokollbeschreibungen
Navigation Timing-Daten
Navigation Timing-Daten bieten Einblicke in die verschiedenen Teile des Seitenladevorgangs einer Webseite.
Diese Daten variieren aufgrund des Standorts des Endbenutzers, Netzwerkproblemen, Änderungen durch den Anbieter usw. Kunden können Navigation Timing-Daten verwenden, um die Erfahrung des Endbenutzers beim Laden der überwachten Webseite zu optimieren.
Messungen können für jede Radar-Sitzung durchgeführt werden (sofern aktiviert). Jede Sitzung ist mit einer ID-Nummer verknüpft, die hilft, alle Messungen einer Sitzung zu verfolgen. Diese Messungen werden den Kunden als Navigation Timing-Protokolle über NEM zur Verfügung gestellt.
Im Folgenden finden Sie ein Beispiel für die Navigation Timing-Daten im TSV-Dateiformat.
Im Folgenden sind die Spaltenüberschriften und Beschreibungen für Navigation Timing-Protokolle aufgeführt. Die Felder erscheinen in den Ausgabedateien in der folgenden Reihenfolge:
| Protokoll | Beschreibung |
|---|---|
| Zeitstempel | Dies ist die UTC-Zeit der Anfrage im Format YYYY-MM-DDTHH:MI:SSZ. Der tatsächliche Wert (bis auf die Sekunde genau) 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-/Tagestabellen gerundet. Er 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 0 (Erfolg) als Antwort im Vergleich zur Gesamtzahl der Messungen (gesamt) herangezogen. Für andere Sondentypen (RTT und Durchsatz) muss der Filter bei der Berechnung von Statistiken über die RTT nur RTT-Datenpunkte mit einem Erfolgscode von 0 berücksichtigen. Gleiches gilt 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, wobei 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 Anfrage bearbeitet hat. IDs können unter https://community-radar.citrix.com/ref/countries.json.gz Namen zugeordnet werden. |
| Resolver-Region | Die Region des DNS-Resolvers, der die Anfrage bearbeitet 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. |
| Resolver-Bundesland | Das Bundesland des DNS-Resolvers, der die Anfrage bearbeitet 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 Bundesländer. |
| Resolver-ASN | Die Autonomous System Number (ASN) des DNS-Resolvers, der die Anfrage bearbeitet hat. Im Allgemeinen die ASN, die den DNS-Resolver hat. 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. |
| Client-Markt | Der Markt des Endbenutzers, 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). |
| Client-Land | Das Land des Endbenutzers, der diese Messung generiert hat. IDs können unter https://community-radar.citrix.com/ref/countries.json.gz Namen zugeordnet werden. |
| Client-Region | 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-Bundesland | Das Bundesland des Endbenutzers, der diese Messung generiert hat. Im Allgemeinen das Bundesland, 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 Bundesländer. |
| Client-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. |
| Referer-Host | Die Referer-Informationen (Protokoll, Host und Pfad) stammen aus dem Referer-Header der HTTP-Anfrage an Radar. |
| Referer-Protokoll | Die Referer-Informationen (Protokoll, Host und Pfad) stammen aus dem Referer-Header der HTTP-Anfrage an Radar. |
| Referer-Pfad | Die Referer-Informationen (Protokoll, Host und Pfad) stammen aus dem Referer-Header der HTTP-Anfrage an Radar. |
| Gerätekategorie | Alle Geräte werden in eine der folgenden Kategorien eingeteilt: Smartphone, Tablet, PC, Smart TV und Sonstige. ‘Sonstige’ wird als Standardwert verwendet, wenn der Parser den Wert für eines der Felder nicht bestimmen kann. |
| Gerät | Der Gerätetyp, den der Benutzer verwendet, z.B. ein Apple iPhone. Der User-Agent-String erkennt dies vom Browser, der auf der Seite läuft, die den Radar-Tag hostet. |
| Browser | Der Browsertyp, den der Benutzer verwendet, z.B. Mobile Safari UI/WKWebView 0.0.0. Der User-Agent-String erkennt dies vom Browser, der auf der Seite läuft, die den Radar-Tag hostet. |
| Betriebssystem | Das verwendete Betriebssystem, z.B. iOS 11.0.3. Der User-Agent-String erkennt dies vom Browser, der auf der Seite läuft, die den Radar-Tag hostet. |
| DNS-Lookup-Zeit | Mit der Resource Timing API wird die Differenz zwischen Domain Lookup End und Domain Lookup Start berechnet. Sie wird 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 die Differenz zwischen Connect End und Connect Start berechnet. Sie wird berechnet, wenn beide Werte nicht null sind und die Endzeit größer als die Startzeit ist. Sie wird als connectEnd - connectStart berechnet. |
| Sichere Verbindungszeit | Mit der Resource Timing API wird die Differenz zwischen Connect End und Secure Connection Start berechnet. Sie wird berechnet, wenn beide Werte nicht null sind und die Endzeit größer als die Startzeit ist. Sie wird als connectEnd - secureConnectionStart berechnet. |
| Ladeereignis | Dies ist die Dauer oder Zeit, die benötigt wird, um vom Start 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. |
| Umleitung | Dies ist die Dauer oder Zeit, die benötigt wird, um von Navigation Start zu Fetch 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 Start der Navigation bis zum Ende des Seitenladeereignisses zu gelangen. Sie wird als Load Event End - Navigation Start berechnet, wenn beide Werte nicht null sind und die Endzeit größer als die Startzeit ist. |
| DOM | Die Dauer oder Zeit, die benötigt wird, um vom DOM-Laden bis zum DOM-Abschluss zu gelangen. 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 Response Start und Request Start berechnet. Sie wird berechnet, wenn beide Werte nicht null sind und die Antwortstartzeit größer als die Anfragestartzeit ist. Sie wird als responseStart - requestStart berechnet. |
| Download-Zeit | Mit der Resource Timing API wird die Differenz zwischen Response End und Response Start berechnet. Sie wird 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 benötigt wird, um von Navigation Start zu DOM Interactive zu gelangen. Sie wird als DomInteractive - NavigationStart berechnet, wenn beide Werte nicht null sind und die Endzeit größer als die Startzeit ist. |
| Start-Rendering | Die Dauer oder Zeit, die benötigt wird, um von Navigation Start zu Start Render zu gelangen. 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-Protokolle ermöglichen es Kunden, Echtzeit-Messungen zu verwenden, um das Verhalten ihrer Openmix-Anwendungen zu überwachen. Sie können diese Daten nutzen, um Verbesserungsbereiche zu finden oder die erwartete Leistung ihrer Anwendungen zu überprüfen.
- Diese Protokolle liefern Echtzeit-Messungen, die für Openmix-Kunden durchgeführt wurden.
- Das empfohlene Dateiformat für diese Protokolle ist JSON, sie sind aber auch im TSV-Format verfügbar.
- Hier sind Beispiele für Openmix und HTTP Openmix Protokollfreigabedaten im TSV-Dateiformat.
Openmix-Protokollbeschreibungen
| Protokoll | Beschreibung |
|---|---|
| Zeitstempel | Dies ist die UTC-Zeit der Anfrage im Format YYYY-MM-DDTHH:MI:SSZ. Der tatsächliche Wert (bis auf die Sekunde genau) 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-/Tagestabellen gerundet. Der Zeitstempel ist in allen Datensätzen immer in UTC. |
| App-Besitzer-Zonen-ID | Die Zonen-ID für den Anwendungsbesitzer, der die Anfrage bearbeitet. Dieser Wert ist immer gleich 1. |
| App-Besitzer-Kunden-ID | Die Kunden-ID für den Anwendungsbesitzer, der die Anfrage bearbeitet. Für HTTP-Anfragen wird diese ID im Anforderungspfad codiert und verwendet, um nachzuschlagen, welche Anwendung ausgeführt werden soll. |
| App-ID | Die Anwendungs-ID innerhalb des Kundenkontos, die die Anfrage bearbeitet. Diese ID ist ebenfalls 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 nach der 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 lief, 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 im Allgemeinen in einem ähnlichen Zeitrahmen, aber fast nie genau zur gleichen Zeit. Es ist wahrscheinlich, dass sich überlappende Entscheidungen im Laufe der Zeit während des Update-Prozesses unterschiedliche Versionen einer App verwenden. |
| App-Name | Der Name der Anwendung, die das Konto bedient hat. |
| Markt | Der Markt des Endbenutzers, 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. |
| Bundesland | Das Bundesland des Endbenutzers, der diese Messung generiert hat. |
| ASN-ID | Die Autonomous System Number (ASN) des Endbenutzers, der diese Messung generiert hat. Im Allgemeinen die Autonomous System Number, 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 im Abfrage-String angegebene IP, die die anfragende IP überschreibt (im Gegensatz zur Resolver-/ECS-/EDNS-ID für den DNS-Fluss). Es ist die Adresse, die das System als Ziel bei der Verarbeitung der Informationen betrachtet. Diese IP ist entweder die IP des anfragenden Resolvers oder die ECS-IP-Adresse des Clients, wenn EDNS ECS unterstützt wird. Daher basieren alle Sondierungsleistungsdaten, geografischen Informationen usw., die an die Anwendungslogik übergeben werden, auf dieser IP. |
| Entscheidungsanbieter-Name | Alias der Plattform, die eine Anwendung auswählt. |
| Grundcode | Grundcode, der innerhalb der Anwendung festgelegt wird und den Grund für die Entscheidung beschreibt. |
| Grundprotokoll | Dieses Protokoll ist eine kundendefinierte Ausgabe der Openmix-App. Es ist ein optionales String-Feld, das Kunden ermöglicht, Informationen über ihre Openmix-App-Entscheidungen zu protokollieren. |
| Fallback-Modus | Dieser Modus zeigt an, ob die App im Fallback-Modus war, als sie die Anfrage bearbeitet hat. Fallback tritt auf, wenn bei der Vorbereitung der Anfrage zur Ausführung etwas fehlgeschlagen ist. |
| Verwendetes EDNS | True, wenn die Anwendung eine EDNS Client Subnet-Erweiterung verwendet. |
| TTL | Die zurückgegebene TTL (Time To Live). |
| Antwort | Der von der Anfrage zurückgegebene CNAME. |
| Ergebnis | Der Wert in diesem Feld ist immer 1. |
| Kontext | Dies ist die Zusammenfassung der Radar-Daten, die Openmix zur Verfügung standen, als die Anfrage bearbeitet wurde. Openmix löst Radar-Daten 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 | Dies ist die UTC-Zeit der Anfrage im Format YYYY-MM-DDTHH:MI:SSZ. Der tatsächliche Wert (bis auf die Sekunde genau) 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-/Tagestabellen gerundet. Der Zeitstempel ist in allen Datensätzen immer in UTC. |
| App-Besitzer-Zonen-ID | Die Zonen-ID für den Anwendungsbesitzer, der die Anfrage bearbeitet. Dieser Wert ist immer gleich 1. |
| App-Besitzer-Kunden-ID | Die Kunden-ID für den Anwendungsbesitzer, der die Anfrage bearbeitet. Für HTTP-Anfragen wird diese ID im Anforderungspfad codiert und verwendet, um nachzuschlagen, welche Anwendung ausgeführt werden soll. |
| App-ID | Die Anwendungs-ID innerhalb des Kundenkontos, die die Anfrage bearbeitet. Diese ID ist ebenfalls 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 nach der 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 lief, 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 im Allgemeinen in einem ähnlichen Zeitrahmen, aber fast nie genau zur gleichen Zeit. Es ist wahrscheinlich, dass sich überlappende Entscheidungen im Laufe der Zeit während des Update-Prozesses unterschiedliche Versionen einer App verwenden. |
| App-Name | Der Name der Anwendung, die das Konto bedient hat. |
| Markt | Der Markt des Endbenutzers, 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. |
| Bundesland | Das Bundesland 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 im Abfrage-String angegebene IP, die die anfragende IP überschreibt (im Gegensatz zur Resolver-/ECS-/EDNS-ID für den DNS-Fluss). Es ist die Adresse, die das System als Ziel bei der Verarbeitung der Informationen betrachtet. Diese IP ist entweder die IP des anfragenden Resolvers oder die ECS-IP-Adresse des Clients, wenn EDNS ECS unterstützt wird. Alle Sondierungsleistungsdaten, geografischen Informationen usw., die an die Anwendungslogik übergeben werden, basieren auf dieser IP. |
| Entscheidungsanbieter-Name | Alias der Plattform, die eine Anwendung auswählt. |
| Grundcode | Grundcode, der innerhalb der Anwendung festgelegt wird und den Grund für die Entscheidung beschreibt. |
| Grundprotokoll | Dieses Protokoll ist eine kundendefinierte Ausgabe der Openmix-App. Es ist ein optionales String-Feld, das Kunden ermöglicht, Informationen über ihre Openmix-App-Entscheidungen zu protokollieren. |
| Fallback-Modus | Dieser Modus zeigt an, ob die App im Fallback-Modus war, als sie die Anfrage bearbeitet hat. Fallback tritt auf, wenn bei der Vorbereitung der Anfrage 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 0 (Erfolg) als Antwort im Vergleich zur Gesamtzahl der Messungen (gesamt, unabhängig von der Antwort) herangezogen. Für andere Sondentypen (RTT und Durchsatz) muss der Filter bei der Berechnung von Statistiken über die RTT nur RTT-Datenpunkte mit einem Erfolgscode von 0 berücksichtigen. Gleiches gilt 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 | Dies 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-Anfrage an Radar. Für HTTP OPX ist der gesamte Referer (Protokoll, Host und Pfad) in einem String mit der Bezeichnung Referer enthalten. |
| User-Agent | Dies ist der User-Agent-String der Browserseite, die den Tag hostet. Wenn Sie beispielsweise Chrome verwenden und eine Seite mit dem Radar-Tag durchsuchen, zeichnen die Radar-Messungen im Hintergrund den User-Agent Ihres Chrome-Browsers auf. Die Messungen umfassen den Chrome-Browser, die Chrome-Version, Informationen über das Betriebssystem, auf dem Chrome läuft, und so weiter. |
| Kontext | Dies ist die Zusammenfassung der Radar-Daten, die Openmix zur Verfügung standen, als die Anfrage bearbeitet wurde. Openmix löst Radar-Daten 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 Drittanbieterorganisationen
Kunden können mit NetScaler® zusammenarbeiten, um benutzerdefinierte Berichte basierend auf den von NetScaler gesammelten Radar-Daten zu erhalten. NetScaler kann Berichte generieren, die nach einem Zeitplan ausgeführt werden. Die Berichte sind als Datendateien verfügbar, normalerweise im TSV-Format.
FAQ
Radar
Wie häufig werden Dateien an S3 und GCS übertragen?
Die Häufigkeit der Dateieinlagerungen beträgt einmal pro Minute für Radar und täglich für Berichte.
Wo werden die Berichte gespeichert?
S3 Legacy (Speicherort 1):
s3://public-radar/[customer name]/
S3 (Speicherort 2):
s3://cedexis-netscope/[customer id]/
GCS (Speicherort 3):
gs://cedexis-netscope-[customer id]/
Wie erhalten Sie S3-Zugangsdaten, falls Sie diese noch nicht haben?
Das Portal stellt einen “Access”- und einen “Secret”-Schlüssel bereit. Verwenden Sie die Schlüssel mit s3cmd, awscli oder anderen Tools, um auf S3 zuzugreifen. Für Google Storage lädt das Portal eine Datei mit Zugangsdaten herunter, die mit dem gsutil-Tool verwendet werden können.
Wie verwenden Sie die Zugriffs- und Geheimschlü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 und https://s3tools.org/usage für die Verwendung, Optionen und Befehle konsultieren. 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-->
Um die Dateien herunterzuladen, führen Sie den folgenden Befehl aus:
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-->
Wie verwenden Sie die s3cmd-Konfiguration, um Dateien im S3-Bucket aufzulisten?
Der erste Schritt ist die Installation von s3cmd. Sie können es von http://s3tools.org/download installieren.
Um s3cmd zu konfigurieren, führen Sie den folgenden Befehl aus:
s3cmd ls s3://cedexis-netscope/[customer id]/
<!--NeedCopy-->
Wenn Sie s3cmd bereits mit einem anderen Satz von Zugriffs- und Geheimschlüsseln verwenden, gehen Sie wie folgt vor:
Wenn Sie s3cmd bereits verwenden, erstellen Sie eine Kopie der Standardkonfiguration unter ~/.s3cfg. Erstellen Sie beispielsweise eine Kopie und nennen Sie sie ~/.s3cfg_netscope. Ersetzen Sie die Zugriffs- und Geheimschlüsseleinträge in ~/.s3cfg_netscope durch die von uns bereitgestellten.
Verwenden Sie die neue Konfiguration anstelle der Standardkonfiguration (Ihres Unternehmens), um mit dem folgenden 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 und den Speicherort der Konfigurationsdatei mit den von NetScaler bereitgestellten Zugriffs- und Geheimschlüsseln angeben müssen.
Wenn Sie zwischen verschiedenen Schlüsselpaaren wechseln möchten, betten Sie diese in eine Datei ein. Verweisen Sie mit der Option -c auf die Datei, um anzugeben, welches Schlüsselpaar Sie verwenden.
HINWEIS: Der Parameter
-cgibt an, wo sich die Konfigurationsdatei mit den Zugriffs- und Geheimschlüsseln befindet.
Wie verwenden Sie die Schlüsseldatei mit gsutil oder gcloud, um Protokolldateien herunterzuladen?
Sobald Sie die JSON-Schlüsseldatei des Google-Dienstkontos heruntergeladen haben, können Sie diese verwenden, um Ihre Google-Kontozugangsdaten zu authentifizieren, Ihre Protokolldateien anzuzeigen oder herunterzuladen. Hier ist beispielsweise eine Möglichkeit, dies mit den Google-Befehlszeilendienstprogrammen 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: Dateien im GCS (Google Cloud Storage) Bucket auflisten
Nachdem Sie die Dienstkontoschlüsseldatei wie im vorherigen Schritt beschrieben aktiviert haben, verwenden Sie den folgenden Befehl, um die Dateien im GCS-Bucket aufzulisten:
gsutil ls gs://cedexis-netscope-<customer id>
<!--NeedCopy-->
Schritt 3 (falls erforderlich): Originale Anmeldeinformationen wiederherstellen (oder zwischen Konten wechseln)
Sie können zwischen dem NetScaler ITM-Konto und anderen von Ihnen authentifizierten Google Cloud-Anmeldeinformationen wechseln, indem Sie Folgendes tun:
Führen Sie zuerst 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-Adresse durch die E-Mail-Adresse des Kontos ersetzen, zu dem Sie wechseln möchten.
Wie sieht der Dateiname aus?
Legacy Täglich:
Die Dateinamen der täglichen Radar-Protokollfreigabe haben diese Struktur:
<prefix><date: YYYY-MM-DD>.<customer_id>.part<uniq_id>.kr.txt.gz
Zum Beispiel Cedexis_Daily-2017-11-07.21222.part-cc901e1dd55eal4e.kr.txt.gz (nicht-standardmäßiges Beispiel)
Legacy Echtzeit:
Die Dateinamen der Echtzeit-Radar-Protokollfreigabe 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 diese Struktur:
<freq><log_type><prefix><id_type><id><iso_dt><uniq_id>.<line_format>.gz
Wobei,
-
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
Welches Format hat die Ausgabedatei?
Für Radar ist das Ausgabedateiformat TSV (Tabulator-getrennte Werte), gzipped.
Openmix und Openmix HTTP API
Wie häufig werden Dateien an S3 übertragen?
Die Häufigkeit der Dateieinlagerungen beträgt einmal pro Minute für Openmix und HTTP Openmix.
Was ist, wenn Sie die Option zur Konfiguration der Openmix- und Openmix HTTP API-Echtzeit-Protokollfreigabe nicht sehen können?
Ihr Account Manager kann die erforderliche Rolle für Sie aktivieren, um die Openmix- und Openmix HTTP API-Echtzeit-Protokollfreigabe zu konfigurieren und zu aktivieren.
Wie aktivieren Sie die Openmix- und Openmix HTTP API-Echtzeit-Protokollfreigabe und greifen auf Dateien zu?
Sobald die Rolle in Ihrem Konto aktiviert ist, sehen Sie das Symbol Protokolle verwalten. Klicken Sie darauf, um das Dialogfeld Protokolle zu öffnen, in dem Sie auf die Openmix-Protokollkonfigurationseinstellungen zugreifen können. Diese Einstellungen sind im Grunde alles, was Sie benötigen, um die Openmix- und HTTP Openmix-Echtzeit-Protokollfreigabe zu aktivieren und auf Dateien zuzugreifen.
Was ist der Backend-Prozess?
Das Aktivieren der Openmix-Protokollfreigabe aktiviert auch die Openmix HTTP API-Protokollfreigabe. Die Openmix- und Openmix HTTP API-Protokollfreigabedienste 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 (Speicherort 1):
s3://logshare/[zone ID]/[customer ID]/logs/openmix/json/[YYYY]/[MM]/[DD]/[HH]/.
S3 (Speicherort 2):
s3://cedexis-netscope/[customer id]/
GCS (Speicherort 3):
gs://cedexis-netscope-[customer id]/
Wie sieht der Dateiname aus?
Die Dateinamensstruktur für Openmix und HTTP Openmix sieht typischerweise so aus:
Legacy Echtzeit:
[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 diese Struktur:
<freq><log_type><prefix><id_type><id><iso_dt><uniq_id>.<line_format>.gz
Wobei,
-
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
Welches Format hat die Ausgabedatei?
Das Dateiformat für Openmix und eine Openmix HTTP API ist JSON (gzipped).
In diesem Artikel
- Übersicht
- Protokollfreigabe und -bereitstellung
- Navigation
- Plattformen
- Radar-Protokolle
- Navigation Timing-Protokolle
- Openmix-Protokolle
- Cloud-Dienstbereitstellung
- Radar-Protokollbeschreibungen und Berichte für Dienstanbieter und Unternehmen
- Navigation Timing-Protokollbeschreibungen
- Openmix- und HTTP-Openmix-Protokolle
- Openmix-Protokollbeschreibungen
- Openmix HTTP API-Protokollbeschreibungen
- Benutzerdefinierte Berichte für Drittanbieterorganisationen
- FAQ