Surveillance de l’expérience réseau

Généralités

Le serviceCitrix Network Experience Monitoring (NEM) (anciennement appelé Netscope ) permet aux fournisseurs de services, aux entreprises, aux fournisseurs de services Internet et aux fournisseurs de services tiers d’accéder à des journaux de mesure radar détaillés et à des rapports standard sous la forme de données exploitables résumées. NEM propose plusieurs journaux et rapports standard que les clients peuvent utiliser pour mesurer la qualité de leurs services.

Cette solution comprend la fourniture de mesures radar « brutes » et l’accès à l’API Citrix ITM Data. NEM fournit à la fois les données granulaires (sous forme de mesures brutes ou d’agrégats de données) et les alertes de seuil de données. Ces services sont utiles pour aider à découvrir et à isoler les problèmes de disponibilité et de performances des plates-formes avec le contexte des performances des homologues de plate-forme et des FAI sous-jacents qui fournissent finalement des services aux utilisateurs finaux.

Mesures radar « brutes » : Les mesures radar fournissent des informations granulaires par événement, par lot quotidiennement. Les mesures radar comprennent des données de mesure publiques et privées (disponibilité, temps de réponse, débit pour les mesures HTTP et HTTPS) telles que collectées par l’étiquette. Les mesures radar fournissent des champs de données tels que l’ID du fournisseur, l’IP du solveur, les adresses IP du client masquées (/28), l’en-tête du référent masqué, l’agent utilisateur, l’ASN de l’utilisateur final, les données géographiques de résolution et du client.

Les mesures radar disponibles dans les mesures « brutes » sont les suivantes :

  • Disponibilité
  • Temps de réponse
  • Débit (mesuré)
  • Temps de recherche DNS (facultatif)
  • Heure de connexion TCP (facultatif)
  • Durée de connexion sécurisée (en option)
  • Latence (facultatif)
  • Heure de téléchargement (facultatif)

Les mesures radar sont mises à disposition pour permettre aux clients d’effectuer leur propre analyse des données collectées. L’ensemble de données comprend des informations sur les performances et la disponibilité des fournisseurs (erreurs) pour une gamme de protocoles de communication.

Les données du fichier journal sont disponibles pendant 7 jours à partir d’un compartiment AWS S3 ou Google Cloud Storage. Les clients ont la possibilité de récupérer des fichiers journaux de données communautaires et privées par des méthodes d’accès au compartiment standard.

Mesures radar « brutes » en temps réel (en option) : les mesures radar brutes sont livrées en temps réel à un godet AWS S3. Ces bûches sont mises à disposition dès que possible, généralement dans les 5 minutes suivant la collecte. Ils fournissent autant de granularité que les mesures radar brutes mentionnées ci-dessus.

API de données : L’API de données Citrix ITM Radar fournit des agrégats de la communauté publique Radar et des données de mesure privées. Les données sont mises à jour en continu et groupées environ toutes les 60 secondes pour être récupérées par l’API. L’API de données est fournie pour permettre aux clients d’intégrer les données Radar dans leurs propres rapports et tableaux de bord.

Partage et remise des journaux

  • Les journaux radar peuvent être livrés en temps réel et quotidiennement.
  • Les rapports sont exécutés quotidiennement.
  • Les résultats sont enregistrés dans Amazon Web Services S3 (S3) ou Google Cloud Storage (GCS).
  • Les journaux et les rapports ont une période de conservation de 7 jours. Ils seront automatiquement supprimés une semaine après leur création.
  • Les rapports sont généralement au format TSV (valeur séparée par des tabulations) ou JSON selon le type de rapport.

Les clients reçoivent des informations de connexion pour accéder aux compartiments S3 et GCS. Ils peuvent utiliser un outil de ligne de commande comme s3cmd ou l’interface de ligne de commande AWS pour S3 ; ou gsutil pour GCS. Le fichier de configuration S3cmd reconnaît les clés d’accès (reçues via l’interface utilisateur du portail) et aide l’utilisateur à se connecter au compartiment S3. L’interface de ligne de commande AWS doit être installée sur l’ordinateur du client pour se connecter à S3 et accéder aux journaux. Pour GCS, le client reçoit le fichier de clé d’accès sous forme de téléchargement (via l’interface utilisateur du portail) qui peut être utilisé avec l’outil gsutil.

Pour plus d’informations sur l’utilisation du fichier de configuration s3cmd pour télécharger des fichiers à partir de S3 ou sur l’utilisation du fichier clé avec les outils de ligne de commande gsutil ou gcloud, reportez-vous à la section Questions fréquentes.

Les clients ont également la possibilité de recevoir des notifications par courriel lorsque les rapports sont disponibles.

Paramètres de la plate-forme

Vous devez configurer votre plate-forme pour prendre en charge et produire les données requises pour Netscope NEM. Avant de commencer, assurez-vous que les paramètres suivants sont activés pour votre plate-forme.

  • Pour les rapports Anonymous Best, activez les paramètres de la sonde radar.
    • Pour Anonymous Best RTT, activez Temps de réponse et Disponibilité.
    • Pour le meilleur débit anonyme, activez Débit et Disponibilité.
  • Pour les rapports d’ID de nœud de cache, activez les paramètres de la sonde radaret, dans Paramètres radar avancés, activez l’ ID de nœud.
  • Pour les détails de synchronisation des ressources, activez Inclure les horodatages dans les paramètres radar avancés .

Dans le menu principal, sélectionnez Netscope NEM. La page Configuration de la surveillance de l’expérience réseau s’ouvre.

Navigation

Plateformes et réseaux

Sélectionnez Plateformes ou Réseaux requis (ou les deux) pour démarrer le processus de configuration.

REMARQUE :

Les journaux et rapports ne peuvent être configurés et générés que si au moins une plate-forme ou un réseau est sélectionné.

Les données récapitulées reçues par le client incluent les mesures radar des plates-formes sélectionnées (pour tous les réseaux associés) ou des réseaux sélectionnés (pour toutes les mesures de plate-forme associées).

Sélection de plates-formes

Pour les fournisseurs de services de contenu ou les entreprises, sélectionnez Plateformes représentant les CDN, les clouds, les centres de données ou d’autres points de terminaison pour lesquels des mesures sont requises.

Plates-formes

Sélection de réseaux

Pour les FAI, sélectionnez Réseaux dans la liste associée à différentes plates-formes ou points de terminaison pour lesquels des mesures sont requises.

REMARQUE :

Si vous ne trouvez pas la plate-forme requise dans la liste, vous pouvez la configurer dans la section Plateforme du portail. Pour les réseaux indisponibles, contactez l’supportéquipe.

Réseaux

Rapports de plateforme

Il existe quatre types de rapports de plate-forme :

  1. Meilleur rapport anonyme pour la boucle RTT
  2. Meilleur rapport anonyme pour le débit
  3. ID du nœud de cache
  4. Horaire par pays/ASN

Pour les descriptions des journaux, accédez àDescriptions et rapports des journaux radar pour les fournisseurs de services et les entreprises.

Activer les rapports de plate-forme

Cliquez sur le bouton bascule pour activer ou désactiver les rapports que vous souhaitez (ou ne souhaitez pas) recevoir. Si un rapport existant est désactivé, les nouveaux journaux cessent de générer, mais les anciens rapports restent à l’emplacement actuel.

Rapports de plateforme

Meilleur rapport anonyme pour les plates-formes

  • Ces rapports aident les fournisseurs à comparer leurs performances à celles d’autres plateformes au sein de leur groupe de pairs, c’est-à-dire dans le même pays, région ou ASN.
  • Les données de performance des 15 principaux fournisseurs du groupe de pairs sont agrégées en fonction des mêmes catégories, et les meilleures performances sont répertoriées à côté de la meilleure valeur du fournisseur spécifique.
  • Anonymous Best Report for SSL Platforms est disponible afin que leurs performances puissent être comparées à d’autres plates-formes SSL.
  • Les adresses IP du client sont tronquées à /28.
  • Les résultats du « meilleur » fournisseur aident les Clouds/CDN à concentrer leurs efforts de performance sur des ASN à volume élevé ou critiques pour l’entreprise qui sont faibles sur le plan de la concurrence par rapport à leurs homologues.
  • Le rapport fournit des détails sur les performances ventilées par adresse IP du résolveur DNS, IP client /28 et nœud de mise en cache qui a servi les objets, et les compare avec la « meilleure » plate-forme pour les mêmes critères.

Disponible pour RTT et Débit.

Rapport d’ID de nœud de cache pour les plates-formes

  • Ce rapport permet d’identifier le serveur ou le centre de données spécifique qui a répondu à une demande et d’aider à diagnostiquer les problèmes de serveur.
  • Il fournit l’ID du centre de données ou de la machine qui a répondu à une demande spécifique.
  • Il aide à comprendre pourquoi les performances via un nœud spécifique (POP ou machine, ou ID de nœud), étaient bonnes ou mauvaises.
  • Les performances sont réduites en fonction du type de sonde (par exemple, le temps de réponse, le débit et la disponibilité), de l’adresse IP du résolveur DNS, de l’adresse IP du client /28 et du nœud de mise en cache qui a servi les objets.
  • Pour les descriptions des journaux, reportez-vous àDescriptions et rapports des journaux radar pour les fournisseurs de services et les entreprises

Horaire par pays/ASN

Rapports réseau

Il existe trois types de rapports réseau :

  1. Meilleur rapport anonyme pour la boucle RTT
  2. Meilleur rapport anonyme pour le débit
  3. Sous-réseau

Pour les descriptions des journaux, reportez-vous à la section Descriptions et rapports des journaux radar pour les FSI.

Activer les rapports réseau

Cliquez sur le bouton bascule pour activer/désactiver les rapports que vous souhaitez (ou ne souhaitez pas) recevoir. Si désactivé, les nouveaux journaux cessent de générer, mais les anciens rapports restent en place. Pour générer un rapport de sous-réseau, entrez les sous-réseaux spécifiques de vos réseaux. Si aucun sous-réseau n’a été saisi (mais que le rapport est activé), il est généré à l’aide du bloc CIDR ASN comme sous-réseau par défaut.

Rapports réseau

Meilleur rapport anonyme pour les FAI

  • Dans le rapport Anonymous Best for FSI, un groupe de pairs est utilisé pour la « meilleure » comparaison. Le groupe d’homologues est basé sur l’emplacement du fournisseur de services Internet. Il s’agit généralement des 10 FAI les plus mesurés dans un pays donné, avec un minimum de plus de 1 000 sessions.
  • Les résultats du « meilleur » FSI aident les FSI à concentrer leurs efforts de performance sur des plates-formes à volume élevé ou critiques pour l’entreprise et sur des domaines qui sont faibles sur le plan de la concurrence par rapport à leurs pairs.
  • Le rapport fournit des détails sur les performances ventilées par géographie et plateforme, et les compare avec le « meilleur » FAI pour les mêmes critères.
  • Disponible pour RTT et Débit.
  • Pour les descriptions des journaux, reportez-vous à la section Descriptions et rapports des journaux radar pour les FSI.

Rapport de sous-réseau pour les FAI

  • Ce rapport fournit aux FAI des informations sur la façon dont les sous-réseaux spécifiques de leurs réseaux fonctionnent pour les utilisateurs via les plates-formes que nous mesurons.
  • Il fournit des informations sur le fournisseur de services qui a répondu à une demande spécifique.
  • Il aide à comprendre les performances par sous-réseau réseau.
  • Les performances sont réduites en fonction du type de sonde (par exemple, temps de réponse, débit et disponibilité), de l’adresse IP du résolveur DNS, de l’adresse IP du client /28 et du sous-réseau de l’utilisateur qui a reçu les objets.
  • Pour les descriptions des journaux, reportez-vous à la section Descriptions et rapports des journaux radar pour les FSI.

Journaux radar

  • Les journaux radar sont disponibles pour les plates-formes et les réseaux.
  • Ils incluent un sous-ensemble des champs disponibles dans les journaux bruts, avec certaines données anonymisées : client IP /28, Referer MD5 haché.
  • Toutes les mesures prises pour les plates-formes publiques sont fournies, quelle que soit la page qui a généré la mesure.

REMARQUE :

NEM n’expose jamais les adresses IP client complètes. Au lieu de cela, il expose le /28. Par exemple, une adresse IP de 255.255.255.255 apparaîtra dans un rapport sous la forme 255.255.255.240/28.

Fréquence du journal

Les journaux radar peuvent être générés quotidiennement (toutes les 24 heures), c’est-à-dire en fin de journée, heure UTC. Les journaux peuvent également être générés en temps réel (minute par minute).

Format de fichier

Choisissez TSV ou JSON pour recevoir des journaux et des rapports dans l’un ou l’autre de ces formats.

Type de mesure

Vous pouvez configurer les journaux pour les types de mesure suivants : Disponibilité, Temps de réponse et Débit. Dans le rapport, 1 : Disponibilité, 0 : Temps de réponse HTTP et 14 : Débit HTTP.

Détails du calendrier des ressources

Vous pouvez choisir d’inclure également les détails du calendrier des ressources en cliquant sur les boutons Oui ou Non. Les détails du calendrier des ressources incluent :

  • Heure de recherche DNS
  • Heure de connexion TCP
  • Temps de connexion sécurisé
  • Heure de téléchargement

Pour les descriptions des journaux, reportez-vous à la section Descriptions et rapports des journaux radar pour les fournisseurs de services et les entreprises.

Configuration du journal

Journaux de synchronisation de navigation

Fréquence du journal

Les journaux de synchronisation de navigation peuvent être générés quotidiennement (toutes les 24 heures), c’est-à-dire en fin de journée, heure UTC. Les journaux peuvent également être générés en temps réel (minute par minute).

Format de fichier

Choisissez TSV ou JSON pour recevoir les journaux de synchronisation de navigation dans l’un de ces formats.

Pour les descriptions des journaux, reportez-vous à la section Descriptions du journal de synchronisation de navigation.

Journaux de synchronisation de navigation

Journaux Openmix

Fréquence du journal

Les journaux Openmix sont générés en temps réel (c’est-à-dire minute par minute). Ces journaux fournissent des mesures en temps réel pour les clients Openmix.

Format de fichier

Choisissez TSV ou JSON pour recevoir les journaux Openmix et HTTP Openmix dans l’un de ces formats. JSON est cependant le format recommandé.

Pour les descriptions des journaux, reportez-vous à la section Description du journal OpenMix.

Journaux Openmix

Prestation de services cloud

Cette option vous permet de sélectionner le mode de livraison. Vous pouvez choisir de recevoir des journaux et des rapports dans le compartiment AWS S3 ou dans le compartiment Google Cloud Storage (GCS). Vous disposez d’informations de connexion pour accéder aux compartiments S3 et GCS. Vous pouvez utiliser un outil de ligne de commande comme s3cmd ou l’interface de ligne de commande AWS pour S3. Et gsutil pour GCS.

AWS S3

Pour que les journaux et les rapports soient remis au compartiment AWS S3, sélectionnez AWS S3.

Emplacement

L’emplacement représente le compartiment dans AWS S3 où les journaux et les rapports sont enregistrés.

Clés IAM

Si vous sélectionnez le bouton Générer des clés sous AWS S3, les clés AWS IAM (clés Access et Secret) seront générées et affichées sous IAM Keys. Assurez-vous d’enregistrer les clés car elles ne sont pas stockées n’importe où pour être visualisés ultérieurement.

REMARQUE :

Cette paire de clés d’accès et de clés secrètes est la seule copie des clés privées. Le client est responsable de les stocker en toute sécurité. La régénération de nouvelles clés invalide les clés existantes. Le fichier de configuration S3cmd reconnaît les clés d’accès (reçues via l’interface utilisateur du portail) et aide le client à se connecter au compartiment S3. Pour se connecter à S3, l’interface de ligne de commande AWS doit être installée sur la machine du client.

Pour plus d’informations sur l’utilisation des clés d’accès et secrètes avec s3cmd pour télécharger des rapports à partir du compartiment S3, reportez-vous à la section Questions fréquentes.

AWS S3

Stockage Google Cloud

Pour que les journaux et les rapports soient remis à GCS, sélectionnez Google Cloud Storage.

Emplacement

L’emplacement représente le compartiment dans Google Cloud Storage où les journaux et les rapports sont enregistrés.

Clés IAM

Lorsque vous sélectionnez le bouton Générer un fichier de clé, le fichier de clé de compte de service Google est téléchargé sur votre ordinateur.

REMARQUE :

Ce fichier de clé sert de seule copie de la clé privée. Prenez note de l’adresse e-mail de votre compte de service et stockez en toute sécurité le fichier de clé privée du compte de service. La régénération d’un nouveau fichier de clé invalide le fichier existant.

Ce fichier de clé peut être utilisé avec l’outil gsutil pour télécharger des journaux et des rapports à partir du compartiment GCS. Pour plus d’informations sur l’utilisation du fichier clé pour télécharger des fichiers journaux, reportez-vous à la section Questions fréquentes.

GCS

Descriptions et rapports des journaux radar pour les fournisseurs de services et les entreprises

Journaux radar pour les fournisseurs

  • Ces journaux fournissent des mesures radar pour les partenaires de référence.
  • Ils fournissent toutes les mesures prises pour les plates-formes publiques, quelle que soit la page qui a généré la mesure.
  • Les journaux radar comprennent un sous-ensemble des champs disponibles dans les journaux bruts, avec certaines données anonymisées : client IP /28, Referer MD5 haché.
  • Voici un exemple Partage du journal du radar de plate-forme au format de fichier TSV.

REMARQUE :

NEM n’expose jamais les adresses IP client complètes. Au lieu de cela, il expose le /28. Par exemple, une adresse IP de 255.255.255.255 apparaîtra dans un rapport sous la forme 255.255.255.240/28.

Descriptions du journal

Ce sont les en-têtes de colonnes et les descriptions des journaux radar. Les champs apparaissent dans cet ordre dans les fichiers de sortie :

Journal Description
Horodatage Il s’agit de l’heure UTC de la requête au format AAAA-MM-JJTHH:MI:SSZ. Il s’agit de la valeur réelle (jusqu’à la seconde) dans les tables de journalisation et est arrondie à l’heure la plus proche (2018-03-30T 23:00:00 Z) ou au jour (2018-03-30T 00:00:00 Z) dans les tables d’heures/jour, respectivement. Ceci est toujours en UTC dans tous les jeux de données.
ID de nœud unique Également connu sous le nom d’ID de nœud de cache, une valeur arbitraire (généralement une adresse IP) qui peut être renvoyée par les serveurs périphériques CDN pour aider les CDN à identifier en interne quel serveur a traité une requête particulière. (chaîne vide) : provient de clients Radar qui ne prennent pas en charge la détection UNI .0 : L’agent utilisateur ne prend pas en charge les fonctionnalités nécessaires à la détection UNI .1 : Le client a rencontré une erreur lors de la détection UNI, telle une réponse HTTP 404 ou une autre réponse infructueuse.2 : La détection UNI a été tentée mais a entraîné une erreur.
ID du fournisseur ID interne de la plate-forme en cours de mesure.
Type de sonde Type de sonde mesuré (par exemple : 1 : Temps de connexion HTTP, 0 : Temps de réponse HTTP, 14 : Débit HTTP, etc.). Nous utilisons uniquement les informations qu’il a retournées avec succès (ou non) dans le délai imparti pour indiquer que le service est disponible.
Code de réponse Résultat de la mesure .e.g.0 : succès, 1 : délai d’attente, > 1 : erreur. Pour les calculs de disponibilité, le pourcentage de mesures est pris avec une réponse 0 (succès) par rapport au nombre total de mesures (total, indépendamment de la réponse). Ceci, est strictement le calcul de la disponibilité. Pour les autres types de sonde (RTT et débit), il doit s’agir d’un filtre (c’est-à-dire considérer uniquement les points de données RTT avec un code de succès 0 lors du calcul des statistiques sur le RTT) .Idem pour le débit.
Valeur de mesure Valeur de mesure enregistrée, dont la signification varie selon le type de sonde. Il représente les mesures de disponibilité (1)/Temps de réponse (0) en millisecondes, et Débit (14) en kbps.
Marché des résolveurs Marché du résolveur DNS qui a traité la demande. Généralement le continent où se trouve le résolveur DNS, où, 0 : inconnu (XX), 1:Amérique du Nord (NA) 5 : Afrique (AF), 3 : Europe (UE), 4 : Asie (AS), 2 : Océanie (OC), 6 : Amérique du Sud (SA).
Pays de résolution Le pays de la résolution DNS qui a géré la demande. Les ID peuvent être mappés aux noms sur https://community-radar.citrix.com/ref/countries.json.gz
Région de résolution La région du résolveur DNS qui a traité la requête.ID peut être mappée aux noms dans https://community-radar.citrix.com/ref/regions.json.gz Note : Tous les pays du monde n’ont pas de régions définies.
État de résolution L’état de la résolution DNS qui a géré la demande. Les ID peuvent être mappés avec des noms à l’adressehttps://community-radar.citrix.com/ref/states.json.gz Remarque : les pays du monde n’ont pas tous des états définis.
Ville de résolution La ville du résolveur DNS qui a géré la ville Request.Resolver est ajoutée en recherchant l’adresse IP du résolveur. Les ID peuvent être mappés aux noms sur https://community-radar.citrix.com/ref/cities.json.gz
ASN de résolution Numéro de système autonome (NSA) de la résolution DNS qui a traité la demande. Généralement, l’ASN qui contient la résolution DNS. Les ID peuvent être mappés aux noms sur https://community-radar.citrix.com/ref/asns.json.gz
IP de la résolution Adresse IP la résolution DNS à partir de laquelle notre infrastructure a reçu la demande DNS.
Marché client Le marché de l’utilisateur final qui a généré cette mesure. Généralement le continent où se trouve l’adresse IP du client ; où, 0 : inconnu (XX), 1:Amérique du Nord (NA) 5 : Afrique (AF), 3 : Europe (UE), 4 : Asie (AS), 2 : Océanie (OC), 6 : Amérique du Sud (SA).
Pays client Le pays de l’utilisateur final qui a généré cette mesure. Les ID peuvent être mappés aux noms sur https://community-radar.citrix.com/ref/countries.json.gz
Région client Région de l’utilisateur final qui a généré cette mesure. Généralement, la région géographique où se trouve l’adresse IP du client. Les ID peuvent être mappés avec des noms à l’adresse https://community-radar.citrix.com/ref/regions.json.gz Remarque : les pays du monde n’ont pas tous des régions définies.
État du client État de l’utilisateur final qui a généré cette mesure. Généralement, l’état où se trouve l’adresse IP du client. Les ID peuvent être mappés avec des noms surhttps://community-radar.citrix.com/ref/states.json.gz Remarque : les pays du monde n’ont pas tous des états définis.
Ville client Ville de l’utilisateur final qui a généré cette mesure. Généralement, la ville où se trouve l’adresse IP du client. Les ID peuvent être mappés aux noms surhttps://community-radar.citrix.com/ref/cities.json.gz
ASN client Numéro de système autonome (ASN) de l’utilisateur final qui a généré cette mesure. Généralement, l’ASN qui contient les ID IP client peut être mappé aux noms sur https://community-radar.citrix.com/ref/asns.json.gz
IP du client IP de l’utilisateur final qui a généré cette mesure.
Hôte référant MD5 Les informations du référent (protocole, hôte et chemin) proviennent de l’en-tête du référent de la requête HTTP vers Radar. L’hôte référent est haché MD5.
Agent utilisateur Chaîne de l’agent utilisateur du navigateur exécutant la page qui héberge la balise. Par exemple, si vous utilisez Chrome et que vous parcourez une page avec la balise Radar, les mesures radar prises en arrière-plan enregistrent l’agent utilisateur à partir de votre navigateur Chrome. Cela inclut le fait qu’il s’agissait de Chrome, quelle version de Chrome il était, des informations sur le système d’exploitation sur lequel vous exécutez, etc.
Heure de recherche DNS (facultatif) À l’aide de l’API Resource Timing, la différence entre la fin de la recherche de domaine et le début de la recherche de domaine lorsque les deux valeurs ne sont pas nulles et que l’heure de fin est supérieure à l’heure de début. Il est calculé comme domainLookupEnd - domainLookupStart.
Heure de connexion TCP (facultatif) À l’aide de l’API Resource Timing, la différence entre Connect End et Connect Start lorsque les deux valeurs ne sont pas nulles et que l’heure de fin est supérieure à l’heure de début. Il est calculé comme connectEnd - connectStart.
Durée de connexion sécurisée (facultatif) À l’aide de l’API Resource Timing, la différence entre Connect End et Secure Connection Start lorsque les deux valeurs ne sont pas nulles et que l’heure de fin est supérieure à l’heure de début. Il est calculé comme connectEnd - secureConnectionStart.
Latence (facultatif) À l’aide de l’API Resource Timing, la différence entre le début de la réponse et le début de la demande lorsque les deux valeurs ne sont pas nulles et que l’heure de début de la réponse est supérieure à l’heure de début de la demande. Il est calculé comme responseStart - requestStart
Heure de téléchargement (Facultatif) À l’aide de l’API Resource Timing, la différence entre la fin de la réponse et le début de la réponse lorsque les deux valeurs ne sont pas nulles et que l’heure de fin est supérieure à l’heure de début. Il est calculé comme responseEnd - responseStart.
Profil du client Cela permet d’identifier si les données proviennent d’applications mobiles ou de navigateurs. Il nous permet également de différencier les applications iOS, Android et les navigateurs. Chaque profil de client est identifié par un numéro. Les valeurs de ce champ sont : null, 0, 1, 2, 3, 4. Où, null : implique généralement un client Radar plus ancien qui ne supporte pas l’envoi de la valeur client_profile. 0 : Navigateur ; 1 : iOS - Radar runner pour l’application iOS écrite en Swift ; 2 : Android ; 3 : Navigateur sur la version mobile du site Web ; 4 : iOS - Radar Runner pour l’application iOS écrite en Objective-C.
Version du profil client La version du profil client nous indique quelle version du code Radar Runner (pour iOS) ou AndroidRadar SDK (pour Android) a été utilisée dans l’application mobile. Ce champ est destiné à un usage interne uniquement.
Catégorie de périphérique Tous les appareils sont classés dans l’un des éléments suivants : Smartphone, Tablette, PC, Smart TV et Autre. « Autre » est utilisé comme valeur par défaut si l’analyseur n’est pas en mesure de déterminer la valeur de l’un des champs.
Appareil Type de périphérique sur lequel se trouve l’utilisateur, par exemple Apple iPhone. Ceci est détecté par la chaîne de l’agent utilisateur du navigateur en cours d’exécution sur la page qui héberge la balise Radar.
Navigateur Type de navigateur utilisé par l’utilisateur, par exemple Mobile Safari UI/WKWebView 0.0.0. Ceci est détecté par la chaîne de l’agent utilisateur du navigateur en cours d’exécution sur la page qui héberge la balise Radar.
OS Système d’exploitation utilisé, par exemple iOS 11.0.3. Ceci est détecté par la chaîne de l’agent utilisateur du navigateur en cours d’exécution sur la page qui héberge la balise Radar.

Meilleur rapport anonyme

  • Les meilleurs rapports anonymes aident les fournisseurs à comparer leurs performances à celles d’autres plateformes au sein de leur groupe de pairs, c’est-à-dire dans le même pays, région ou ASN.
  • Les données de performance des 15 principaux fournisseurs du groupe de pairs sont agrégées en fonction des mêmes catégories, et les meilleures performances sont répertoriées à côté de la meilleure valeur du fournisseur spécifique.
  • Anonymous Best Report pour les plates-formes SSL est disponible afin que leurs performances puissent être comparées avec d’autres plates-formes SSL.
  • Les adresses IP du client sont tronquées à /28.
  • Les résultats du « meilleur » fournisseur aident les Clouds/CDN à concentrer leurs efforts de performance sur des ASN à volume élevé ou critiques pour l’entreprise qui sont faibles sur le plan de la concurrence par rapport à leurs homologues.
  • Le rapport fournit des détails sur les performances ventilées par adresse IP du résolveur DNS, IP client /28 et nœud de mise en cache qui a servi les objets, et les compare avec la « meilleure » plate-forme pour les mêmes critères.
  • Disponible pour RTT ou Débit.
  • Voici un exemple Meilleur rapport sur la plateforme anonyme pour RTT au format de fichier TSV.

Descriptions du journal

Ce sont les en-têtes de colonnes et les descriptions du rapport Anonymous Best. Les champs apparaissent dans cet ordre dans les fichiers de sortie.

Journal Description
Pays de résolution Pays du résolveur DNS qui a traité la demande.
Région de résolution Région du résolveur DNS qui a traité la demande.
État de résolution État du résolveur DNS qui a traité la demande.
ID ASN du résolveur Numéro de système autonome du résolveur DNS qui a traité la demande. Généralement l’ASN qui contient le résolveur DNS.
Nom de l’ASN du résolveur Nom de l’ASN.
IP de la résolution IP du résolveur DNS qui a traité la demande.
Pays client Pays de l’utilisateur final qui a généré cette mesure.
Région client Région de l’utilisateur final qui a généré cette mesure.
État du client État de l’utilisateur final qui a généré cette mesure.
ID ASN client Numéro ASN (Autonomous System Number) de l’utilisateur final qui a généré cette mesure. Généralement l’ASN qui contient l’adresse IP du client.
Nom de l’ASN client Nom de l’ASN de l’utilisateur final qui a généré la mesure.
IP du client IP de l’utilisateur final qui a généré la mesure.
Succès Nombre total de mesures réussies.Conseil : Succès/Total == Disponibilité.
Délais d’ expiration Nombre de mesures qui ont expiré.
Erreurs Nombre de mesures qui étaient des erreurs.
Total : Le nombre total de mesures.
Moyenne Moyenne de toutes les valeurs de mesure de cette ligne.
Meilleure moyenne Le meilleur moyen parmi les 15 principaux fournisseurs du groupe de pairs.
Meilleures mesures moyennes Nombre total de mesures qui ont produit le meilleur dénombrement moyen.
Médiane La valeur du 50e centile, également connue sous le nom de valeur moyenne des mesures pour un fournisseur particulier, si les mesures sont répertoriées dans l’ordre.
Meilleure médiane La meilleure valeur du 50e centile (en dessous de laquelle 50% des mesures peuvent être trouvées) des 15 principaux fournisseurs du groupe de pairs.
Meilleures mesures médianes Nombre total de mesures qui ont produit le best_median
5ème Valeur du 5e centile pour le fournisseur.
Meilleur 5ème La meilleure valeur du 5e centile parmi les 15 principaux fournisseurs du groupe homologue.
Meilleures mesures 5ème Nombre total de mesures qui ont produit le best_5th
10e Valeur du 10e centile pour le fournisseur.
Meilleur 10e La meilleure valeur du 10e centile parmi les 15 principaux fournisseurs du groupe homologue.
Meilleures mesures 10e Nombre total de mesures qui ont produit le best_10th
90th Valeur du 90e centile pour le fournisseur.
Meilleur 90e La meilleure valeur du 90e centile parmi les 15 principaux fournisseurs du groupe homologue.
Meilleures mesures 90e Nombre total de mesures qui ont produit le best_90e
95th Valeur du 95e centile pour le fournisseur.
Meilleur 95e La meilleure valeur du 95e centile parmi les 15 principaux fournisseurs du groupe homologue.
Meilleures mesures 95e Nombre total de mesures qui ont produit le meilleur 95e
Stdev L’écart type pour le fournisseur
Meilleur Stdev Le meilleur écart type parmi les 15 principaux fournisseurs du groupe homologue.
Meilleures mesures Stdev Nombre total de mesures qui ont produit le meilleur std.dev.
Disponibilité Disponibilité en pourcentage pour le fournisseur. La disponibilité est le taux de réussite de la sonde, c’est-à-dire Succès/(Succès + Fails + Délais d’attente)
Meilleure disponibilité La meilleure valeur de disponibilité parmi les 15 principaux fournisseurs du groupe homologue.
Meilleures mesures de disponibilité Le nombre de mesures qui ont produit la meilleure disponibilité
Importance Valeurs synthétiques générées pour aider à trouver des données exploitables.
ID de nœud unique Il s’agit d’une liste séparée par des virgules des ID de noeud uniques pour les mesures représentées par cette ligne.
Type de mesure Valeur de mesure enregistrée, dont la signification varie selon le type de sonde. Il représente HTTP_COLD (Disponibilité), HTTP_RTT (All-retour) ou HTTP_KBPS (Débit).
ID du fournisseur Numéro d’ID Citrix interne de ce fournisseur.

Rapport sur l’ID de nœud de cache (précédemment Rapport sur le fournisseur de services multiples)

Ce rapport permet d’identifier le serveur ou le centre de données spécifique qui a répondu à une demande et d’aider à diagnostiquer les problèmes de serveur.

  • Il fournit l’ID du centre de données ou de la machine qui a répondu à une demande spécifique.
  • Il aide à comprendre pourquoi les performances via un nœud spécifique (POP ou machine, ou ID de nœud), étaient bonnes ou mauvaises.
  • Les performances sont réduites en fonction du type de sonde (par exemple, temps de réponse, débit et disponibilité), de l’adresse IP du résolveur DNS, de l’adresse IP du client /28 et du nœud de mise en cache qui a servi les objets.
  • Voici un exemple Rapport d’ID de nœud de cache de plate-forme au format de fichier TSV.

Descriptions du journal

Ce sont les en-têtes de colonnes et les descriptions du rapport d’ID de nœud de cache. Les champs apparaissent dans cet ordre dans les fichiers de sortie :

Journal Description
Nom du fournisseur Il s’agit du nom du fournisseur qui est mesuré.
Valeur de mesure Valeur de mesure enregistrée, dont la signification varie selon le type de sonde. Il représente les mesures connect (1)/RTT (0) en millisecondes et les mesures de débit (14) en kbps.
ID de nœud unique Également connu sous le nom d’ID de nœud de cache, une valeur arbitraire (généralement une adresse IP) qui peut être renvoyée par les serveurs périphériques CDN pour aider les CDN à identifier en interne quel serveur a traité une requête particulière. (chaîne vide) : provient de clients Radar qui ne prennent pas en charge la détection UNI .0 : L’agent utilisateur ne prend pas en charge les fonctionnalités nécessaires à la détection UNI .1 : Le client a rencontré une erreur lors de la détection UNI, telle une réponse HTTP 404 ou une autre réponse infructueuse.2 : La détection UNI a été tentée mais a entraîné une erreur.
Pays de résolution Pays du résolveur DNS qui a traité la demande.
Région de résolution Région du résolveur DNS qui a traité la demande.
État de résolution État du résolveur DNS qui a traité la demande.
ASN de résolution Numéro de système autonome du résolveur DNS qui a traité la demande. Généralement l’ASN qui contient le résolveur DNS.
Nom de l’ASN du résolveur Nom de l’ASN.
IP de la résolution IP du résolveur DNS qui a traité la demande.
Pays client Pays de l’utilisateur final qui a généré cette mesure.
Région client Région de l’utilisateur final qui a généré cette mesure.
État du client État de l’utilisateur final qui a généré cette mesure.
ASN client Numéro ASN (Autonomous System Number) de l’utilisateur final qui a généré cette mesure. Généralement l’ASN qui contient l’adresse IP du client.
Nom de l’ASN client Nom de l’ASN de l’utilisateur final qui a généré la mesure.
IP du client IP de l’utilisateur final qui a généré la mesure.
Succès Nombre total de mesures réussies.Conseil : Succès/Total == Disponibilité.
Délai d’expiration Nombre de mesures qui ont expiré.
Error Nombre de mesures qui étaient des erreurs.
Total : Le nombre total de mesures.
Moyenne Moyenne des valeurs de mesure pour chaque ligne.
Médiane La valeur du 50e centile, également connue sous le nom de valeur moyenne des mesures pour un fournisseur particulier, si les mesures sont répertoriées dans l’ordre.
5ème Valeur du 5e centile pour le fournisseur.
10e Valeur du 10e centile pour le fournisseur.
90th Valeur du 90e centile pour le fournisseur.
95th Valeur du 95e centile pour le fournisseur.
Stdev Écart type pour le fournisseur.
Disponibilité Disponibilité en pourcentage pour le fournisseur.
Importance Valeurs synthétiques générées pour aider à trouver des données exploitables.

Heure par pays/Rapport ASN

  • Ce rapport permet de vérifier si les performances de vos fournisseurs varient considérablement au cours d’une journée.
  • Il montre l’heure à laquelle les mesures ont été prises (arrondies à l’heure), par exemple 2018-03-11T23:00:00.
  • Voici un exemple Plateforme Horaire par pays/Etat ASN au format de fichier TSV.

Descriptions du journal

Il s’agit des en-têtes de colonnes et des descriptions du rapport horaire par pays/ASN. Les champs apparaissent dans cet ordre dans les fichiers de sortie :

Journal Description
Horodatage 60 minutes L’heure UTC où les mesures ont été prises est tronquée à l’heure, par exemple2018-03-11T 23:00:00.
Nom du fournisseur Il s’agit du nom du fournisseur qui est mesuré.
Type de mesure Valeur de mesure enregistrée, dont la signification varie selon le type de sonde. Il représente HTTP_COLD (Disponibilité), HTTP_RTT (All-retour) ou HTTP_KBPS (Débit).
Pays client Pays de l’utilisateur final qui a généré cette mesure.
ASN client Numéro ASN (Autonomous System Number) de l’utilisateur final qui a généré cette mesure. Généralement l’ASN qui contient l’adresse IP du client.
Nom de l’ASN client Nom de l’ASN de l’utilisateur final qui a généré la mesure.
Succès Nombre total de mesures réussies.Conseil : Succès/Total == Disponibilité.
Délai d’expiration Nombre de mesures qui ont expiré.
Error Nombre de mesures qui étaient des erreurs.
Total : Le nombre total de mesures.
Moyenne Moyenne des valeurs de mesure pour chaque ligne.
Médiane La valeur du 50e centile, également connue sous le nom de valeur moyenne des mesures pour un fournisseur particulier, si les mesures sont répertoriées dans l’ordre.
5ème Valeur du 5e centile pour le fournisseur.
10e Valeur du 10e centile pour le fournisseur.
90th Valeur du 90e centile pour le fournisseur.
95th Valeur du 95e centile pour le fournisseur.
Stdev Écart type pour le fournisseur.
Disponibilité Disponibilité en pourcentage pour le fournisseur.
Importance Valeur synthétique générée pour aider à trouver des données exploitables.
ID du fournisseur Numéro d’ID Citrix interne de ce fournisseur.

Descriptions et rapports des journaux radar pour les FSI

Journaux radar pour les FAI

Les journaux radar permettent aux FSI de mesurer en détail leurs performances par rapport aux plates-formes mondiales. Les FSI peuvent utiliser ces données pour trouver les domaines où des améliorations doivent être apportées ou pour vérifier les performances attendues.

  • Permet d’accéder aux mesures radar.
  • Fournit les mesures prises par les FAI sur les plates-formes publiques, quelle que soit la page qui a généré la mesure.
  • Les journaux radar comprennent un sous-ensemble des champs disponibles dans les journaux bruts, avec certaines données anonymisées : client IP /28, référent MD5 haché.
  • Les fichiers journaux sont au format TSV.
  • Voici un exemple Partage du journal radar réseau au format de fichier TSV.

Descriptions du journal

Ce sont les en-têtes de colonnes et les descriptions des journaux radar pour les FAI. Les champs apparaissent dans cet ordre dans les fichiers de sortie.

Journal Description
Horodatage Il s’agit de l’heure UTC de la requête au format AAAA-MM-JJTHH:MI:SSZ. Il s’agit de la valeur réelle (jusqu’à la seconde) dans les tables de journalisation et est arrondie à l’heure la plus proche (2018-03-30T 23:00:00 Z) ou au jour (2018-03-30T 00:00:00 Z) dans les tables d’heures/jour, respectivement. Ceci est toujours en UTC dans tous les jeux de données.
ID du fournisseur ID interne de la plate-forme en cours de mesure.
Type de sonde Type de sonde mesuré (par exemple : 1 : Temps de connexion HTTP, 0 : Temps de réponse HTTP, 14 : Débit HTTP, etc.). Nous utilisons uniquement les informations qu’il a retournées avec succès (ou non) dans le délai imparti pour indiquer que le service est disponible.
Code de réponse Résultat de la mesure .e.g.0 : succès, 1 : délai d’attente, > 1 : erreur. Pour les calculs de disponibilité, le pourcentage de mesures est pris avec une réponse 0 (succès) vs. Le nombre total de mesures (total, quelle que soit la réponse). Ceci, est strictement le calcul de la disponibilité. Pour les autres types de sonde (RTT et débit), il doit s’agir d’un filtre (c’est-à-dire considérer uniquement les points de données RTT avec un code de réussite 0 lors du calcul des statistiques sur le RTT). Idem pour le débit.
Valeur de mesure Valeur de mesure enregistrée, dont la signification varie selon le type de sonde. Il représente les mesures de disponibilité (1)/Temps de réponse (0) en millisecondes, et Débit (14) en kbps.
Marché des résolveurs Marché du résolveur DNS qui a traité la demande. Généralement le continent où se trouve le résolveur DNS, où, 0 : inconnu (XX), 1:Amérique du Nord (NA) 5 : Afrique (AF), 3 : Europe (UE), 4 : Asie (AS), 2 : Océanie (OC), 6 : Amérique du Sud (SA).
Pays de résolution Le pays de la résolution DNS qui a géré la demande. Les ID peuvent être mappés aux noms sur https://community-radar.citrix.com/ref/countries.json.gz
Région de résolution La région du résolveur DNS qui a traité les identifiants Request.IDs peut être mappée avec des noms à l’adresse https://community-radar.citrix.com/ref/regions.json.gz Remarque : les pays du monde n’ont pas tous de régions définies.
État de résolution L’état de la résolution DNS qui a géré la demande. Les ID peuvent être mappés avec des noms à l’adressehttps://community-radar.citrix.com/ref/states.json.gz Remarque : les pays du monde n’ont pas tous des états définis.
ASN de résolution Numéro de système autonome (NSA) de la résolution DNS qui a traité la demande. Généralement, l’ASN qui contient la résolution DNS. Les ID peuvent être mappés aux noms sur https://community-radar.citrix.com/ref/asns.json.gz
IP de la résolution Adresse IP la résolution DNS à partir de laquelle notre infrastructure a reçu la demande DNS.
Marché client Le marché de l’utilisateur final qui a généré cette mesure. Généralement le continent où se trouve l’adresse IP du client ; où, 0 : inconnu (XX), 1:Amérique du Nord (NA) 5 : Afrique (AF), 3 : Europe (UE), 4 : Asie (AS), 2 : Océanie (OC), 6 : Amérique du Sud (SA).
Pays client Le pays de l’utilisateur final qui a généré cette mesure. Les ID peuvent être mappés aux noms sur https://community-radar.citrix.com/ref/countries.json.gz
Région client Région de l’utilisateur final qui a généré cette mesure. Généralement, la région géographique où se trouve l’adresse IP du client. Les ID peuvent être mappés avec des noms à l’adresse https://community-radar.citrix.com/ref/regions.json.gz Remarque : les pays du monde n’ont pas tous des régions définies.
État du client État de l’utilisateur final qui a généré cette mesure. Généralement, l’état où se trouve l’adresse IP du client. Les ID peuvent être mappés avec des noms surhttps://community-radar.citrix.com/ref/states.json.gz Remarque : les pays du monde n’ont pas tous des états définis.
ASN client Numéro de système autonome (ASN) de l’utilisateur final qui a généré cette mesure. Généralement, l’ASN qui contient les ID IP client peut être mappé aux noms sur https://community-radar.citrix.com/ref/asns.json.gz
IP du client IP de l’utilisateur final qui a généré cette mesure.
Hôte référant MD5 Les informations du référent (protocole, hôte et chemin) proviennent de l’en-tête du référent de la requête HTTP vers Radar. L’hôte référent est haché MD5.
Agent utilisateur Il s’agit de la chaîne de l’agent utilisateur du navigateur exécutant la page qui héberge la balise. Par exemple, si vous utilisez Chrome et que vous parcourez une page avec la balise Radar, les mesures radar prises en arrière-plan enregistrent l’agent utilisateur à partir de votre navigateur Chrome. Cela inclut le fait qu’il s’agissait de Chrome, quelle version de Chrome il était, des informations sur le système d’exploitation sur lequel vous exécutez, etc.
Heure de recherche DNS (facultatif) À l’aide de l’API Resource Timing, la différence entre la fin de la recherche de domaine et le début de la recherche de domaine lorsque les deux valeurs ne sont pas nulles et que l’heure de fin est supérieure à l’heure de début. Il est calculé comme domainLookupEnd - domainLookupStart.
Heure de connexion TCP (facultatif) À l’aide de l’API Resource Timing, la différence entre Connect End et Connect Start lorsque les deux valeurs ne sont pas nulles et que l’heure de fin est supérieure à l’heure de début. Il est calculé comme connectEnd - connectStart.
Durée de connexion sécurisée (facultatif) À l’aide de l’API Resource Timing, la différence entre Connect End et Secure Connection Start lorsque les deux valeurs ne sont pas nulles et que l’heure de fin est supérieure à l’heure de début. Il est calculé comme connectEnd - secureConnectionStart.
Latence (facultatif) À l’aide de l’API Resource Timing, la différence entre le début de la réponse et le début de la demande lorsque les deux valeurs ne sont pas nulles et que l’heure de début de la réponse est supérieure à l’heure de début de la demande. Il est calculé comme responseStart - requestStart
Heure de téléchargement (Facultatif) À l’aide de l’API Resource Timing, la différence entre la fin de la réponse et le début de la réponse lorsque les deux valeurs ne sont pas nulles et que l’heure de fin est supérieure à l’heure de début. Il est calculé comme responseEnd - responseStart.
Profil du client Cela permet d’identifier si les données proviennent d’applications mobiles ou de navigateurs. Il nous permet également de différencier les applications iOS, Android et les navigateurs. Chaque profil de client est identifié par un numéro. Les valeurs de ce champ sont : null, 0, 1, 2, 3, 4. Où, null : implique généralement un client Radar plus ancien qui ne supporte pas l’envoi de la valeur client_profile. 0 : Navigateur ; 1 : iOS - Radar runner pour l’application iOS écrite en Swift ; 2 : Android ; 3 : Navigateur sur la version mobile du site Web ; 4 : iOS - Radar Runner pour l’application iOS écrite en Objective-C.
Version du profil client La version du profil client nous indique quelle version du code Radar Runner (pour iOS) ou AndroidRadar SDK (pour Android) a été utilisée dans l’application mobile. Ce champ est destiné à un usage interne uniquement.
Catégorie de périphérique Tous les appareils sont classés dans l’un des éléments suivants : Smartphone, Tablette, PC, Smart TV et Autre. « Autre » est utilisé comme valeur par défaut si l’analyseur n’est pas en mesure de déterminer la valeur de l’un des champs.
Appareil Type de périphérique sur lequel se trouve l’utilisateur, par exemple Apple iPhone. Ceci est détecté par la chaîne de l’agent utilisateur du navigateur en cours d’exécution sur la page qui héberge la balise Radar.
Navigateur Type de navigateur utilisé par l’utilisateur, par exemple Mobile Safari UI/WKWebView 0.0.0. Ceci est détecté par la chaîne de l’agent utilisateur du navigateur en cours d’exécution sur la page qui héberge la balise Radar.
OS Système d’exploitation utilisé, par exemple iOS 11.0.3. Ceci est détecté par la chaîne de l’agent utilisateur du navigateur en cours d’exécution sur la page qui héberge la balise Radar.

Rapport de sous-réseau pour les FAI

  • Ce rapport fournit aux FAI des informations sur la façon dont les sous-réseaux spécifiques de leurs réseaux fonctionnent pour leurs utilisateurs via les plates-formes que nous mesurons.
  • Il fournit des informations sur le fournisseur de services qui a répondu à une demande spécifique.
  • Il aide à comprendre les performances par sous-réseau réseau.
  • Les performances sont réduites en fonction du type de sonde (par exemple, temps de réponse, débit et disponibilité), de l’adresse IP du résolveur DNS, de l’adresse IP du client /28 et du sous-réseau de l’utilisateur qui a reçu les objets.
  • Voici un exemple Rapport de sous-réseau réseau au format de fichier TSV.

Descriptions du journal

Ce sont les en-têtes de colonnes et les descriptions du rapport de sous-réseau pour les fournisseurs de services Internet. Les champs apparaissent dans cet ordre dans les fichiers de sortie :

Journal Description
Nom de l’ASN Nom du système autonome à partir duquel la mesure a été prise.
Valeur de mesure Valeur de mesure enregistrée, dont la signification varie selon le type de sonde. Il représente les mesures connect (1)/RTT (0) en millisecondes et les mesures de débit (14) en kbps.
Sous-réseau Sous-réseau de l’utilisateur d’où provient la demande.
ASN de résolution Numéro de système autonome du résolveur DNS qui a traité la demande. Généralement l’ASN qui contient le résolveur DNS.
IP de la résolution IP du résolveur DNS qui a traité la demande.
ASN client Numéro ASN (Autonomous System Number) de l’utilisateur final qui a généré cette mesure. Généralement l’ASN qui contient l’adresse IP du client.
IP du client IP de l’utilisateur final qui a généré la mesure.
ID de la plate-forme ID de la plate-forme Service Provider vers laquelle la requête a été tentée.
Nom de la plateforme Nom de la plate-forme Service Provider vers laquelle la requête a été tentée.
Succès Nombre total de mesures réussies.Conseil : Succès/Total == Disponibilité.
Délai d’expiration Nombre de mesures qui ont expiré.
Error Nombre de mesures qui étaient des erreurs.
Total : Le nombre total de mesures.
Moyenne Moyenne des valeurs de mesure pour chaque ligne.
Médiane La valeur du 50e centile, également connue sous le nom de valeur moyenne des mesures pour un fournisseur particulier, si les mesures sont répertoriées dans l’ordre.
5ème Valeur du 5e centile pour le fournisseur.
10e Valeur du 10e centile pour le fournisseur.
90th Valeur du 90e centile pour le fournisseur.
95th Valeur du 95e centile pour le fournisseur.
Stdev Écart type pour le fournisseur.
Disponibilité Disponibilité en pourcentage pour le fournisseur.
Importance Valeurs synthétiques générées pour aider à trouver des données exploitables.
Type de mesure Valeur de mesure enregistrée, dont la signification varie selon le type de sonde. Il représente HTTP_COLD (Disponibilité), HTTP_RTT (All-retour) ou HTTP_KBPS (Débit).

Meilleur rapport anonyme pour les FAI

  • Dans le rapport Anonymous Best, un groupe de pairs est utilisé pour la « meilleure » comparaison. Le groupe d’homologues est basé sur l’emplacement du fournisseur de services Internet. Il s’agit généralement des 10 FAI les plus mesurés dans un pays donné, avec un minimum de plus de 1 000 sessions.
  • Les résultats du « meilleur » FSI aident les FSI à concentrer leurs efforts en matière de performance sur des plates-formes à volume élevé ou critiques pour l’entreprise et sur des domaines qui sont faibles sur le plan de la concurrence par rapport à leurs homologues.
  • Le rapport fournit des détails sur les performances ventilées par géographie et plateforme, et les compare avec le « meilleur » FAI pour les mêmes critères.
  • Disponible pour RTT et Débit.
  • Voici un exemple Rapport sur les réseaux anonymes pour RTT au format de fichier TSV.

Descriptions du journal

Ce sont les en-têtes de colonnes et les descriptions du rapport Anonymous Best. Les champs apparaissent dans cet ordre dans les fichiers de sortie.

Journal Description
Type de mesure Valeur de mesure enregistrée, dont la signification varie selon le type de sonde. Il représente HTTP_COLD (Disponibilité), HTTP_RTT (All-retour) ou HTTP_KBPS (Débit).
Pays client Pays de l’utilisateur final qui a généré cette mesure.
Région client Région de l’utilisateur final qui a généré cette mesure.
État du client État de l’utilisateur final qui a généré cette mesure.
ID ASN client Numéro ASN (Autonomous System Number) de l’utilisateur final qui a généré cette mesure. Généralement l’ASN qui contient l’adresse IP du client.
Nom de l’ASN client Nom de l’ASN de l’utilisateur final qui a généré la mesure.
Pays de résolution Pays du résolveur DNS qui a traité la demande.
Région de résolution Région du résolveur DNS qui a traité la demande.
État de résolution État du résolveur DNS qui a traité la demande.
ID de la plate-forme ID de la plate-forme Service Provider vers laquelle la requête a été tentée.
Nom de la plateforme Nom de la plate-forme Service Provider vers laquelle la requête a été tentée.
Succès Nombre total de mesures réussies.Conseil : Succès/Total == Disponibilité.
Délais d’ expiration Nombre de mesures qui ont expiré.
Erreurs Nombre de mesures qui étaient des erreurs.
Total : Le nombre total de mesures.
Moyenne Moyenne de toutes les valeurs de mesure de cette ligne.
Meilleure moyenne Le meilleur moyen parmi les 15 principaux fournisseurs du groupe de pairs.
Meilleures mesures moyennes Nombre total de mesures qui ont produit le meilleur dénombrement moyen.
Médiane La valeur du 50e centile, également connue sous le nom de valeur moyenne des mesures pour un fournisseur particulier, si les mesures sont répertoriées dans l’ordre.
Meilleure médiane La meilleure valeur du 50e centile (en dessous de laquelle 50% des mesures peuvent être trouvées) des 15 principaux fournisseurs du groupe de pairs.
Meilleures mesures médianes Nombre total de mesures qui ont produit le best_median
5ème Valeur du 5e centile pour le fournisseur.
Meilleur 5ème La meilleure valeur du 5e centile parmi les 15 principaux fournisseurs du groupe homologue.
Meilleures mesures 5ème Nombre total de mesures qui ont produit le best_5th
10e Valeur du 10e centile pour le fournisseur.
Meilleur 10e La meilleure valeur du 10e centile parmi les 15 principaux fournisseurs du groupe homologue.
Meilleures mesures 10e Nombre total de mesures qui ont produit le best_10th
90th Valeur du 90e centile pour le fournisseur.
Meilleur 90e La meilleure valeur du 90e centile parmi les 15 principaux fournisseurs du groupe homologue.
Meilleures mesures 90e Nombre total de mesures qui ont produit le best_90e
95th Valeur du 95e centile pour le fournisseur.
Meilleur 95e La meilleure valeur du 95e centile parmi les 15 principaux fournisseurs du groupe homologue.
Meilleures mesures 95e Nombre total de mesures qui ont produit le meilleur 95e
Stdev Écart type pour le fournisseur.
Meilleur Stdev Le meilleur écart type parmi les 15 principaux fournisseurs du groupe homologue.
Meilleures mesures Stdev Nombre total de mesures qui ont produit le meilleur std.dev.
Disponibilité Disponibilité en pourcentage pour le fournisseur. La disponibilité est le taux de réussite de la sonde, c’est-à-dire Succès/(Succès + Échec + Délais d’attente)
Meilleure disponibilité La meilleure valeur de disponibilité parmi les 15 principaux fournisseurs du groupe homologue.
Meilleures mesures de disponibilité Nombre de mesures qui ont produit la meilleure disponibilité.
Importance Valeurs synthétiques générées pour aider à trouver des données exploitables.

Descriptions du journal de synchronisation de navigation

Données de synchronisation de navigation

Les données de synchronisation de la navigation fournissent des informations sur les différentes parties du processus de chargement de la page pour une page Web.

Ces données peuvent varier en raison de la localisation de l’utilisateur final, des problèmes de réseau, des modifications apportées par le fournisseur, etc. Les clients peuvent utiliser les données de synchronisation de navigation pour optimiser l’expérience de l’utilisateur final dans le chargement de la page Web surveillée.

Des mesures peuvent être prises pour chaque session Radar (si elle est activée). Chaque session est attachée à un numéro d’identification qui permet de suivre toutes les mesures d’une session. Ces mesures sont partagées avec les clients sous forme de journaux de synchronisation de navigation via NEM.

Voici un exemple du format de fichierDonnées de synchronisation de navigationdans TSV.

Ce sont les en-têtes de colonnes et les descriptions des journaux de synchronisation de navigation. Les champs apparaissent dans cet ordre dans les fichiers de sortie :

Journal Description
Horodatage Il s’agit de l’heure UTC de la requête au format AAAA-MM-JJTHH:MI:SSZ. Il s’agit de la valeur réelle (jusqu’à la seconde) dans les tables de journalisation et est arrondie à l’heure la plus proche (2018-03-30T 23:00:00 Z) ou au jour (2018-03-30T 00:00:00 Z) dans les tables d’heures/jour, respectivement. Ceci est toujours en UTC dans tous les jeux de données.
Code de réponse Résultat de la mesure .e.g.0 : succès, 1 : délai d’attente, > 1 : erreur. Pour les calculs de disponibilité, le pourcentage de mesures est pris avec une réponse 0 (succès) vs. Le nombre total de mesures (total, quelle que soit la réponse) .Ceci est strictement le calcul de la disponibilité. Pour les autres types de sonde (RTT et débit), il doit s’agir d’un filtre (c’est-à-dire considérer uniquement les points de données RTT avec un code de succès 0 lors du calcul des statistiques sur le RTT) .Idem pour le débit.
Marché des résolveurs Marché du résolveur DNS qui a traité la demande. Généralement le continent où se trouve le résolveur DNS, où, 0 : inconnu (XX), 1:Amérique du Nord (NA) 5 : Afrique (AF), 3 : Europe (UE), 4 : Asie (AS), 2 : Océanie (OC), 6 : Amérique du Sud (SA).
Pays de résolution Le pays de la résolution DNS qui a géré la demande. Les ID peuvent être mappés aux noms sur https://community-radar.citrix.com/ref/countries.json.gz
Région de résolution La région du résolveur DNS qui a traité les identifiants Request.IDs peut être mappée avec des noms à l’adresse https://community-radar.citrix.com/ref/regions.json.gz Remarque : les pays du monde n’ont pas tous de régions définies.
État de résolution L’état de la résolution DNS qui a géré la demande. Les ID peuvent être mappés avec des noms à l’adressehttps://community-radar.citrix.com/ref/states.json.gz Remarque : les pays du monde n’ont pas tous des états définis.
ASN de résolution Numéro de système autonome (NSA) de la résolution DNS qui a traité la demande. Généralement, l’ASN qui contient la résolution DNS. Les ID peuvent être mappés aux noms sur https://community-radar.citrix.com/ref/asns.json.gz
IP de la résolution Adresse IP la résolution DNS à partir de laquelle notre infrastructure a reçu la demande DNS.
Marché client Le marché de l’utilisateur final qui a généré cette mesure. Généralement le continent où se trouve l’adresse IP du client ; où, 0 : inconnu (XX), 1:Amérique du Nord (NA) 5 : Afrique (AF), 3 : Europe (UE), 4 : Asie (AS), 2 : Océanie (OC), 6 : Amérique du Sud (SA).
Pays client Le pays de l’utilisateur final qui a généré cette mesure. Les ID peuvent être mappés aux noms sur https://community-radar.citrix.com/ref/countries.json.gz
Région client Région de l’utilisateur final qui a généré cette mesure. Généralement, la région géographique où se trouve l’adresse IP du client. Les ID peuvent être mappés avec des noms à l’adresse https://community-radar.citrix.com/ref/regions.json.gz Remarque : les pays du monde n’ont pas tous des régions définies.
État du client État de l’utilisateur final qui a généré cette mesure. Généralement, l’état où se trouve l’adresse IP du client. Les ID peuvent être mappés avec des noms surhttps://community-radar.citrix.com/ref/states.json.gz Remarque : les pays du monde n’ont pas tous des états définis.
ASN client Numéro de système autonome (ASN) de l’utilisateur final qui a généré cette mesure. Généralement, l’ASN qui contient les ID IP client peut être mappé aux noms sur https://community-radar.citrix.com/ref/asns.json.gz
IP du client IP de l’utilisateur final qui a généré la mesure.
Hôte référent Les informations du référent (protocole, hôte et chemin) proviennent de l’en-tête du référent de la requête HTTP vers Radar.
Protocole de référencement Les informations du référent (protocole, hôte et chemin) proviennent de l’en-tête du référent de la requête HTTP vers Radar.
Chemin du référent Les informations du référent (protocole, hôte et chemin) proviennent de l’en-tête du référent de la requête HTTP vers Radar.
Catégorie de périphérique Tous les appareils sont classés dans l’un des éléments suivants : Smartphone, Tablette, PC, Smart TV et Autre. « Autre » est utilisé comme valeur par défaut si l’analyseur n’est pas en mesure de déterminer la valeur de l’un des champs.
Appareil Type de périphérique sur lequel se trouve l’utilisateur, par exemple Apple iPhone. Ceci est détecté par la chaîne de l’agent utilisateur du navigateur en cours d’exécution sur la page qui héberge la balise Radar.
Navigateur Type de navigateur utilisé par l’utilisateur, par exemple Mobile Safari UI/WKWebView 0.0.0. Ceci est détecté par la chaîne de l’agent utilisateur du navigateur en cours d’exécution sur la page qui héberge la balise Radar.
OS Système d’exploitation utilisé, par exemple iOS 11.0.3. Ceci est détecté par la chaîne de l’agent utilisateur du navigateur en cours d’exécution sur la page qui héberge la balise Radar.
Heure de recherche DNS À l’aide de l’API Resource Timing, la différence entre la fin de la recherche de domaine et le début de la recherche de domaine lorsque les deux valeurs ne sont pas nulles et que l’heure de fin est supérieure à l’heure de début. Il est calculé comme domainLookupEnd - domainLookupStart.
Temps de connexion TCP À l’aide de l’API Resource Timing, la différence entre Connect End et Connect Start lorsque les deux valeurs ne sont pas nulles et que l’heure de fin est supérieure à l’heure de début. Il est calculé comme connectEnd - connectStart.
Temps de connexion sécurisée À l’aide de l’API Resource Timing, la différence entre Connect End et Secure Connection Start lorsque les deux valeurs ne sont pas nulles et que l’heure de fin est supérieure à l’heure de début. Il est calculé comme connectEnd - secureConnectionStart.
Charger l’événement Il s’agit de la durée ou du temps nécessaire pour passer du début d’un événement de chargement à la fin d’un événement de chargement. Il est calculé comme LoadEventStart - LoadEventStart, lorsque les deux valeurs ne sont pas nulles et que l’heure de fin est supérieure à l’heure de début.
Rediriger Il s’agit de la durée ou du temps nécessaire pour passer du début de la navigation au début de la récupération. Il est calculé comme FetchStart - NavigationStart, lorsque les deux valeurs ne sont pas nulles et que l’heure de fin est supérieure à l’heure de début.
Chargement total de la page Il s’agit de la durée ou du temps nécessaire pour aller du début de la navigation à la fin de l’événement de chargement de la page. Il est calculé comme - Load Event End - Navigation Start lorsque les deux valeurs ne sont pas nulles et que l’heure de fin est supérieure à l’heure de début.
DOM La durée ou le temps nécessaire pour passer du chargement DOM au DOM est terminée. Il est calculé comme DOMComplete - DOMLoading lorsque les deux valeurs ne sont pas nulles et que l’heure de fin est supérieure à l’heure de début.
Latence À l’aide de l’API Resource Timing, la différence entre le début de la réponse et le début de la demande lorsque les deux valeurs ne sont pas nulles et que l’heure de début de la réponse est supérieure à l’heure de début de la demande. Il est calculé comme responseStart - requestStart
Heure de téléchargement À l’aide de l’API Resource Timing, la différence entre la fin de la réponse et le début de la réponse lorsque les deux valeurs ne sont pas nulles et que l’heure de fin est supérieure à l’heure de début. Il est calculé comme responseEnd - responseStart.
DOM interactif Durée ou temps nécessaire pour passer de Navigation Start à DOM Interactive. Il est calculé comme DOMInteractive - NavigationStart lorsque les deux valeurs ne sont pas nulles et que l’heure de fin est supérieure à l’heure de début.
Démarrer le rendu Durée ou temps nécessaire pour passer de Navigation Start à Start Render. Il est calculé comme StarTrender - NavigationStart lorsque les deux valeurs ne sont pas nulles et que l’heure de fin est supérieure à l’heure de début.

Journaux Openmix et HTTP Openmix

Les journaux Openmix et HTTP Openmix permettent aux clients d’utiliser des mesures en temps réel pour surveiller le comportement de leurs applications Openmix. Ils peuvent utiliser ces données pour trouver des domaines où des améliorations peuvent être apportées ou pour vérifier les performances attendues de leurs applications.

  • Ces journaux fournissent des mesures en temps réel pour les clients Openmix.
  • Le format de fichier recommandé pour ces journaux est JSON, mais ils sont également disponibles au format TSV.
  • Voici des exemplesOpenmixet des données de partage deHTTP Openmixjournaux au format de fichier TSV.

Description du journal OpenMix

Journal Description
Horodatage Il s’agit de l’heure UTC de la requête au format AAAA-MM-JJTHH:MI:SSZ. Il s’agit de la valeur réelle (jusqu’à la seconde) dans les tables de journalisation et est arrondie à l’heure la plus proche (2018-03-30T 23:00:00 Z) ou au jour (2018-03-30T 00:00:00 Z) dans les tables d’heures/jour, respectivement. Ceci est toujours en UTC dans tous les jeux de données.
ID de zone du propriétaire de l’application ID de zone du propriétaire de l’application qui gère la demande. Cette valeur est toujours égale à 1.
ID client du propriétaire de l’application ID client du propriétaire de l’application qui gère la requête.Pour les requêtes HTTP, ceci est codé dans le chemin d’accès de la requête et est utilisé pour rechercher l’application à exécuter.
ID de l’application ID d’application dans le compte du client qui gère la demande. Ceci est également codé dans le chemin d’accès de la requête HTTP. Les ID d’application commencent à 1 et ne sont uniques qu’au client. Par conséquent, vous devez qualifier entièrement les requêtes pour un ID d’application spécifique en interrogeant également sur AppownerCustomerID.
Version de l’application Version de l’application qui a servi le compte. Chaque fois qu’une application est mise à jour via le portail ou l’API, la version est incrémentée. La version en cours d’exécution au moment de la demande est enregistrée. Ces informations peuvent être utilisées pour séparer la logique versionnée au fil du temps lorsque les applications sont mises à jour. Les hôtes du réseau recevront généralement des mises à jour dans un délai similaire, mais presque jamais au même moment. Par conséquent, il est probable que les décisions qui se chevauchent dans le temps peuvent utiliser différentes versions d’une application pendant le processus de mise à jour.
Nom app Nom de l’application qui a servi le compte.
Marché Le marché de l’utilisateur final qui a généré cette mesure.
Pays Pays de l’utilisateur final qui a généré cette mesure.
Région Région de l’utilisateur final qui a généré cette mesure.
État État de l’utilisateur final qui a généré cette mesure.
ID ASN Numéro de système autonome (ASN) de l’utilisateur final qui a généré cette mesure. Généralement le numéro de système autonome qui contient l’adresse IP du client.
Nom de l’ASN Nom de l’ASN de l’utilisateur final qui a généré la mesure.
IP effective L’IP effective est l’IP utilisée pour traiter la demande. Il s’agit de l’adresse IP spécifiée par la chaîne de requête qui remplace l’adresse IP requérante (vs. ID de résolveur/ECS/EDNS pour le flux DNS). C’est l’adresse que le système considère la cible lors du traitement des informations. Il s’agit soit de l’adresse IP du résolveur demandeur, soit de l’adresse IP ECS du client si EDNS ECS est pris en charge. Donc, toutes les données de performance de la sonde, les informations géographiques, etc.passées à la logique de l’application est basée sur cette IP.
Marché des résolveurs Marché du résolveur DNS qui a traité la demande.
Pays de résolution Pays du résolveur DNS qui a traité la demande.
Région de résolution Région du résolveur DNS qui a traité la demande.
État de résolution État du résolveur DNS qui a traité la demande.
ID ASN du résolveur Numéro de système autonome (NSA) de la résolution DNS qui a traité la demande. Généralement le numéro de système autonome qui contient le résolveur DNS.
Nom de l’ASN du résolveur Nom de l’ASN du résolveur qui a traité la demande.
IP de la résolution IP du résolveur DNS qui a traité la demande.
Nom du fournisseur de décision Alias de la plate-forme sélectionnée par l’application.
Code motif Code de motif défini dans la demande décrivant le motif de la décision.
Journal des motifs Il s’agit d’une sortie définie par le client à partir de l’application Openmix. Il s’agit d’un champ de chaîne facultatif qui permet aux clients de consigner des informations sur leurs décisions d’application Openmix.
Mode de secours Cela indique si l’application était en mode de secours lorsqu’elle a traité la demande. Le repli se produit lorsque quelque chose a échoué pendant la préparation de la demande d’exécution.
EDNS d’occasion Cette propriété a la valeur True si l’application utilise l’extension de sous-réseau client EDNS.
TTL Le TTL (Time to Live) qui a été remis.
Réponse Le CNAME renvoyé à partir de la requête.
Résultats La valeur de ce champ est toujours 1.
Contexte Ceci est le résumé des données Radar disponibles pour Openmix lorsque la demande a été traitée. Openmix résout les données Radar par rapport aux valeurs effectives pour chaque requête, de sorte que deux clients effectuant des requêtes en même temps peuvent avoir des chaînes de contexte différentes.

Description du journal de l’API HTTP Openmix

Journal Description
Horodatage Il s’agit de l’heure UTC de la requête au format AAAA-MM-JJTHH:MI:SSZ. Il s’agit de la valeur réelle (jusqu’à la seconde) dans les tables de journalisation et est arrondie à l’heure la plus proche (2018-03-30T 23:00:00 Z) ou au jour (2018-03-30T 00:00:00 Z) dans les tables d’heures/jour, respectivement. Ceci est toujours en UTC dans tous les jeux de données.
ID de zone du propriétaire de l’application ID de zone du propriétaire de l’application qui gère la demande. Cette valeur est toujours égale à 1.
ID client du propriétaire de l’application ID client du propriétaire de l’application qui gère la requête.Pour les requêtes HTTP, ceci est codé dans le chemin d’accès de la requête et est utilisé pour rechercher l’application à exécuter.
ID de l’application ID d’application dans le compte du client qui gère la demande. Ceci est également codé dans le chemin d’accès de la requête HTTP. Les ID d’application commencent à 1 et ne sont uniques qu’au client. Par conséquent, vous devez qualifier entièrement les requêtes pour un ID d’application spécifique en interrogeant également sur AppownerCustomerID.
Version de l’application Version de l’application qui a servi le compte. Chaque fois qu’une application est mise à jour via le portail ou l’API, la version est incrémentée. La version en cours d’exécution au moment de la demande est enregistrée. Ces informations peuvent être utilisées pour séparer la logique versionnée au fil du temps lorsque les applications sont mises à jour. Les hôtes du réseau recevront généralement des mises à jour dans un délai similaire, mais presque jamais au même moment. Par conséquent, il est probable que les décisions qui se chevauchent dans le temps peuvent utiliser différentes versions d’une application pendant le processus de mise à jour.
Nom app Nom de l’application qui a servi le compte.
Marché Le marché de l’utilisateur final qui a généré cette mesure.
Pays Pays de l’utilisateur final qui a généré cette mesure.
Région Région de l’utilisateur final qui a généré cette mesure.
État État de l’utilisateur final qui a généré cette mesure.
ID ASN ID du numéro de système autonome (ASN) de l’utilisateur final qui a généré cette mesure, c’est-à-dire le numéro d’ID réseau associé au nom de l’ASN
Nom de l’ASN Nom de l’ASN de l’utilisateur final qui a généré la mesure.
IP effective L’IP effective est l’IP utilisée pour traiter la demande. Il s’agit de l’adresse IP spécifiée par la chaîne de requête qui remplace l’adresse IP requérante (vs. ID de résolveur/ECS/EDNS pour le flux DNS) .Il s’agit de l’adresse que le système considère la cible lors du traitement des informations. Il s’agit soit de l’adresse IP du résolveur demandeur, soit de l’adresse IP ECS du client si EDNS ECS est pris en charge. Ainsi, toutes les données de performance de la sonde, les informations géographiques, etc., transmises à la logique de l’application sont basées sur cette IP.
Nom du fournisseur de décision Alias de la plate-forme sélectionnée par l’application.
Code motif Code de motif défini dans la demande décrivant le motif de la décision.
Journal des motifs Il s’agit d’une sortie définie par le client à partir de l’application Openmix. Il s’agit d’un champ de chaîne facultatif qui permet aux clients de consigner des informations sur leurs décisions d’application Openmix.
Mode de secours Cela indique si l’application était en mode de secours lorsqu’elle a traité la demande. Le repli se produit lorsque quelque chose a échoué pendant la préparation de la demande d’exécution.
Code de réponse Résultat de la mesure .e.g.0 : succès, 1 : délai d’attente, > 1 : erreur. Pour les calculs de disponibilité, le pourcentage de mesures est pris avec une réponse 0 (succès) vs. Le nombre total de mesures (total, quelle que soit la réponse) .Ceci est strictement le calcul de la disponibilité. Pour les autres types de sonde (RTT et débit), il doit s’agir d’un filtre (c’est-à-dire considérer uniquement les points de données RTT avec un code de succès 0 lors du calcul des statistiques sur le RTT) .Idem pour le débit.
HTTP Method La méthode HTTP (GET/POST/OPTIONS/etc) se rapporte à la requête qui a été faite au serveur HTTP Openmix du service client. Ensemble, ces éléments constituent des parties de l’URL entrante et des réponses HTTP sortantes.
URI Il s’agit du chemin d’accès de la requête. Si les clients n’obtiennent pas le comportement qu’ils veulent, cela peut être dû à une demande mal structurée. En regardant les journaux, vous montrerez ce que nos serveurs reçoivent (protocole, hôte et chemin). Les informations du référent (protocole, hôte et chemin) proviennent de l’en-tête du référent de la requête HTTP vers Radar. Pour HTTP OPX, le référent entier (protocole, hôte et chemin) est inclus dans une chaîne appelée Referer.
Agent utilisateur Chaîne de l’agent utilisateur du navigateur exécutant la page qui héberge la balise. Par exemple, si vous utilisez Chrome et que vous parcourez une page avec la balise Radar, les mesures radar prises en arrière-plan enregistrent l’agent utilisateur à partir de votre navigateur Chrome. Cela inclut le fait qu’il s’agissait de Chrome, quelle version de Chrome il était, des informations sur le système d’exploitation sur lequel vous exécutez, etc.
Contexte Ceci est le résumé des données Radar disponibles pour Openmix lorsque la demande a été traitée. Openmix résout les données Radar par rapport aux valeurs effectives pour chaque requête, de sorte que deux clients effectuant des requêtes en même temps peuvent avoir des chaînes de contexte différentes.

Rapports personnalisés pour les organisations tierces

Les clients peuvent travailler avec Citrix pour obtenir des rapports personnalisés basés sur les données Radar collectées par Citrix. Citrix peut générer des rapports à exécuter selon une planification. Ces rapports sont disponibles sous forme de fichiers de données, généralement au format TSV.

Questions fréquentes

Radar

À quelle fréquence les fichiers sont-ils envoyés vers S3 et GCS ?

La fréquence des dépôts de fichiers est une fois par minute pour Radar et quotidienne pour les rapports.

Où sont stockés les rapports ?

Legacy S3 (emplacement 1) :

s3://public-radar/[customer name]/

S3 (Emplacement 2) :

s3://cedexis-netscope/[customer id]/

GCS (Emplacement 3) :

gs://cedexis-netscope-[customer id]/

Comment obtenir des informations d’identification d’accès S3 si vous ne les avez pas déjà ?

L’interface utilisateur du portail fournit une clé ‘Access’ et ‘Secret’ que les clients peuvent utiliser avec ‘s3cmd’ ou ‘awscli’ (le client en ligne de commande AWS) ou d’autres outils pour accéder à S3 et obtenir les fichiers.Pour Google Storage, le portail télécharge un fichier avec des informations d’identification d’accès à utiliser avec l’outil ‘gsutil’.

Comment utiliser les clés d’accès et secrètes avec s3cmd pour télécharger des journaux et des rapports à partir du compartiment S3 ?

Vous devez d’abord télécharger et installer s3cmd depuis https://s3tools.org/download, et vous référer à https://s3tools.org/usage pour l’utilisation, les options et les commandes. Ensuite, exécutez la commande suivante :

s3cmd --access_key=[access key] --secret_key=[secret key] ls s3://cedexis-netscope/<customer id>/radar/

Pour télécharger les fichiers, exécutez la commande suivante :

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]

Comment utiliser la configuration s3cmd pour lister les fichiers dans le compartiment S3

La première étape consiste à installers3cmd. Vous pouvez l’installer à partir dehttp://s3tools.org/download

Pour configurer s3cmd, exécutez la commande suivante

s3cmd ls s3://cedexis-netscope/[customer id]/

Si vous utilisezs3cmd déjà un autre jeu de clés d’accès et de clés secrètes, procédez comme suit :

Si vous utilisez déjàs3cmd, faites une copie de la configuration par défaut, à~/.s3cfg.Par exemple, vous pouvez faire une copie appelée~/.s3cfg_netscope.Remplacer les entrées d'accès et de clé secrète dans ~/.s3cfg_netscopeavec ceux que nous fournissons. Utilisez la nouvelle configuration au lieu de celle par défaut (celle de votre entreprise) pour accéder au compartiment S3 avec la commande suivante :

s3cmd -c ~/.s3cfg_netscope ls s3://cedexis-netscope/[customer id]/

La principale différence est que vous devez mettre dans un-c et où le fichier de configuration est avec l’accès fourni par Citrix et les clés secrètes.

Si vous devez pouvoir basculer entre les jeux de clés, votre meilleur pari est de les incorporer dans un fichier et de se référer au fichier avec l’-c option de spécifier la paire de clés que vous utilisez.

REMARQUE : Le-c paramètre indique simplement où le fichier de configuration contient les clés d’accès et secrètes.

Comment utiliser le fichier clé avec gsutil ou gcloud pour télécharger des fichiers journaux

Une fois le fichier clé JSON du compte de service Google téléchargé, il peut être utilisé pour authentifier vos informations d’identification de compte Google afin que vous puissiez afficher ou télécharger vos fichiers journaux. Par exemple, voici une façon de le faire en utilisant les utilitaires google gcloud et ligne de gsutil commande :

Étape 1 : Activer le fichier de clé

Les commandes d’authentificationgcloud auth activate- ougsutil config -e sont nécessaires pour authentifier le fichier clé pour exécuter les commandes gcloud ou gsutil.

Pour gcloud :

Exécutez la commande suivante à l’aide du fichier clé téléchargé :

gcloud auth activate-service-account --key-file [downloaded config file]

Ou

gcloud auth activate-service-account --key-file=[path and file name of key file]

Pour gsutil :

Exécutez la commande suivante à l’aide du fichier de configuration téléchargé :

gsutil config -e

Étape 2 : Liste des fichiers dans le compartiment GCS (Google Cloud Storage)

Une fois que vous avez activé le fichier de clé de compte de service (comme décrit à l’étape précédente), utilisez la commande suivante pour répertorier les fichiers dans le compartiment GCS :

gsutil ls gs://cedexis-netscope-<customer id>

Étape 3 (si nécessaire) : Restaurer les informations d’identification d’origine (ou basculer d’un compte à l’autre)

Vous pouvez basculer entre le compte Citrix et les autres informations d’identification Google Cloud que vous avez authentifiées en procédant comme suit.

Tout d’abord, exécutez la commande suivante pour répertorier tous vos comptes :

gcloud auth list

Utilisez ensuite la commande suivante pour basculer vers un autre compte :

gcloud config set account [email of the account to switch to as shown in gcloud auth list]

Vous pouvez basculer entre les comptes à l’aide de la même commande, en remplaçant l’e-mail par l’e-mail du compte vers lequel vous souhaitez basculer.

À quoi ressemble le nom de fichier ?

Héritage Quotidien :

Les noms de fichiers de partage de journaux quotidiens Radar ont la structure suivante :

<prefix><date: YYYY-MM-DD>.<customer_id>.part<uniq_id>.kr.txt.gz

Par exempleCedexis_Daily-2017-11-07.21222.part-cc901e1dd55eal4e.kr.txt.gz (exemple non standard)

Legacy en temps réel :

Les noms de fichiers de partage de journaux en temps réel Radar ont la structure suivante :

<prefix><customer_id>-YYYY-MM-DDTHH:MM<uniq_id>.txt.gz

Par exemple Cedexis_3-32291-2017-11-08T20:56-cc907e8fd71eaf4e.txt.gz

Format NEM de Netscope :

Le format NEM de Netscope pour les fichiers de partage de journaux quotidiens et en temps réel a la structure suivante :

<freq><log_type><prefix><id_type><id><iso_dt><uniq_id>.<line_format>.gz

Où,

  • 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"

Par exemple rt-radar-TestRadar1-provider-20363-20171209183034Z-cc907e8fd71eaf4e.tsv.gz

Quel est le format du fichier de sortie ?

Pour Radar, le format de fichier de sortie est TSV (valeur séparée par des tabulations), gzip.

API HTTP Openmix et Openmix

À quelle fréquence les fichiers sont-ils envoyés vers S3 ?

La fréquence des dépôts de fichiers est une fois par minute pour Openmix et HTTP Openmix.

Que faire si vous ne pouvez pas voir l’option de configurer Openmix & Openmix HTTP API en temps réel ?

Votre gestionnaire de compte peut activer le rôle requis pour configurer et activer le partage de journaux en temps réel de l’API HTTP Openmix et Openmix.

Comment activer Openmix & Openmix HTTP API en temps réel et accéder aux fichiers ?

Une fois le rôle activé sur votre compte, l’icône Gérer les journaux s’affiche. Cliquez dessus pour ouvrir la boîte de dialogue Journaux dans laquelle vous pouvez accéder aux paramètres de configuration du journal Openmix. Ces paramètres sont essentiellement tout ce dont vous avez besoin pour activer Openmix & HTTP Openmix en temps réel le partage des journaux et accéder aux fichiers.

Configuration du journal Openmix

Qu’est-ce que le processus back-end ?

L’activation du partage des journaux Openmix permet également le partage des journaux de l’API HTTP Openmix. Les services de partage de journaux de l’API HTTP Openmix et Openmix doivent commencer à sortir des journaux pour le client dans les 10 minutes.

Où sont stockés les rapports Openmix et HTTP Openmix ?

Legacy S3 (emplacement 1) :

s3://logshare/[zone ID]/[customer ID]/logs/openmix/json/[YYYY]/[MM]/[DD]/[HH]/.

S3 (Emplacement 2) :

s3://cedexis-netscope/[customer id]/

GCS (Emplacement 3) :

gs://cedexis-netscope-[customer id]/

À quoi ressemble le nom de fichier ?

La structure de nom de fichier pour Openmix et HTTP Openmix ressemble généralement à ceci :

Legacy en temps réel :

[zone ID, 1][customerID]-openmix-json[YYYY][MM][DD][HH][mm][ss]Z-m1-w9-c0.gz

Format NEM de Netscope :

Le format NEM de Netscope pour les fichiers de partage de journaux quotidiens et en temps réel a la structure suivante :

<freq><log_type><prefix><id_type><id><iso_dt><uniq_id>.<line_format>.gz

Où,

  • 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"

Par exemple hr-opx-TestOpenmix1-provider-20363-20171209183034Z-cc907e8fd71eaf4e.tsv.gz

Quel est le format de fichier de sortie ?

Le format de fichier pour Openmix et Openmix HTTP API est JSON (gzipped)