Surveillance de l’expérience réseau

Vue d’ensemble

Le service Citrix Network Experience Monitoring (NEM)(anciennement Netscope) permet aux fournisseurs de services, aux entreprises, aux FAI 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 inclut la fourniture « brute » de mesures radar 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 aident à la découverte, isolent la disponibilité de la plate-forme et les problèmes de performances des homologues de la plateforme et des FAI sous-jacents.

Mesures « brutes » radar: Les mesures radar fournissent des informations granulaires par événement qui sont groupées quotidiennement. Les mesures radar incluent les données de mesure publiques, communautaires et privées collectées par le tag. Les données telles que la disponibilité, le temps de réponse, le débit pour les mesures HTTP et HTTPS sont incluses. Les champs de données suivants sont fournis :

  • ID du fournisseur, adresse IP du résolveur, adresses IP client masquées (/28)
  • En-tête de référence obscurci, agent utilisateur, ASN de l’utilisateur final
  • Données géographiques pour les champs du résolveur et du client

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

  • Disponibilité, temps de réponse et débit (lorsqu’ils sont mesurés)
  • Heure de recherche DNS (en option), heure de connexion TCP (en option) et heure de connexion sécurisée (en option)
  • Latence (facultatif)
  • Heure de téléchargement (facultatif)

Les mesures radar sont disponibles 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 peuvent récupérer les fichiers journaux des données communautaires et privées à l’aide des méthodes d’accès aux compartiments standard.

Mesures « brutes » radar en temps réel (en option) : Les mesures radar brutes sont fournies en temps réel à un compartiment AWS S3. Ces journaux sont généralement disponibles dans les 5 minutes suivant leur collecte. Ils fournissent autant de granularité que les mesures brutes radar mentionnées précédemment.

API de données : L’API de données Citrix ITM Radar fournit des agrégats de la communauté Radar publique et des données de mesure privées. Les données sont mises à jour en continu et mises en lots 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 livraison de journaux

  • Les journaux radar peuvent être fournis en temps réel et quotidiennement.
  • Les rapports sont exécutés quotidiennement.
  • Les résultats sont enregistrés dans AWS S3 (S3) ou Google Cloud Storage (GCS).
  • Les journaux et les rapports ont tous deux une période de conservation de 7 jours et sont 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. Un outil de ligne de commande tel que s3cmd ou l’interface de ligne de commande AWS pour S3 ou le gsutil pour GCS peut être utilisé pour vous connecter. 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, consultez la FAQ.

Les clients reçoivent des notifications par e-mail dès que des 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 plateforme :

  • 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 un meilleur débit anonyme, activez Throughput et Availability.
  • 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 les rapports peuvent être configurés et générés uniquement si au moins une plate-forme ou un réseau est sélectionné.

Les données résumées que le client reçoit comprennent les mesures radar de plateformes sélectionnées (pour tous les réseaux associés) ou de 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 des plateformes telles que des CDN, des clouds, des centres de données ou d’autres points de terminaison. Sélectionnez les plateformes pour lesquelles des mesures sont requises.

Platforms

Sélection des 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 non disponibles, contactez l’équipe d’ assistance .

Networks

Rapports de plateforme

Il existe quatre types de rapports de plate-forme :

  1. Meilleur Anonyme pour le temps aller-retour (RTT)
  2. Anonyme idéal pour le débit
  3. ID du nœud de cache
  4. Horaire par pays/ASN

Pour les descriptions des journaux, consultez 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 recevoir. Si vous désactivez un rapport existant, les nouveaux journaux ne sont pas générés mais les anciens rapports restent à l’emplacement actuel.

Rapports de plateforme

Meilleur rapport anonyme pour les plateformes

  • 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 meilleurs fournisseurs du groupe homologue sont agrégées sur la base des mêmes catégories. Le meilleur est répertorié à côté du meilleur rapport qualité-prix 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 Cloud/CDN à concentrer les efforts de performance sur les ASN à volume élevé ou critiques pour l’entreprise qui sont peu compétitifs par rapport à leurs pairs.
  • Le rapport fournit des détails sur les performances ventilées par IP du résolveur DNS, IP du client /28 et le nœud de mise en cache qui a servi les objets. La même chose est comparée à la « meilleure » plateforme 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 est utilisé pour identifier le serveur ou le centre de données spécifique qui a répondu à une demande et 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 comprennent le temps de réponse, le débit, la disponibilité (type de sonde), l’adresse IP du résolveur DNS, l’adresse IP du client /28 et le nœud de mise en cache qui a servi les objets.
  • Pour les descriptions des journaux, voir [Descriptions et rapports des journaux radar pour les fournisseurs de services et les entreprises] (#radar -log-descriptions-and-reports-for-service-providers-and-enterprises)

Horaire par pays/ASN

Rapports réseau

Il existe trois types de rapports réseau :

  1. Meilleur Anonyme pour le temps aller-retour (RTT)
  2. Anonyme idéal pour le débit
  3. Sous-réseau

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

Activer les rapports réseau

Cliquez sur le bouton bascule pour activer ou désactiver les rapports que vous souhaitez recevoir. Lorsque cette option est désactivée, les nouveaux journaux cessent de générer mais les anciens rapports sont 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’est entré, les rapports sont générés à 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 pour les FAI, 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 » FAI aident les FAI à concentrer leurs efforts de performance sur les plateformes à volume élevé ou critiques et sur les domaines où la concurrence est faible 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 la description des journaux, reportez-vous à la section Descriptions et rapports des journaux radar pour les FAI.

Rapport de sous-réseau pour les FAI

  • Ce rapport fournit aux FAI des informations sur les performances des sous-réseaux spécifiques de leurs réseaux pour les utilisateurs via les plateformes que nous mesurons.
  • Il fournit des informations sur le fournisseur de services qui a répondu à une demande spécifique.
  • Cela permet de comprendre les performances d’un sous-réseau réseau.
  • Les performances comprennent le temps de réponse, le débit, la disponibilité (types de sondes), l’adresse IP du résolveur DNS, l’adresse IP du client /28 et le sous-réseau de l’utilisateur.
  • Pour la description des journaux, reportez-vous à la section Descriptions et rapports des journaux radar pour les FAI.

Journaux radar

  • Les journaux radar sont disponibles pour les plateformes et les réseaux.
  • Ils incluent un sous-ensemble des champs disponibles dans les journaux bruts, avec certaines données anonymisées : IP du client /28, hachage Referer MD5.
  • 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 complètes des clients. Au lieu de cela, il expose le /28. Par exemple, une adresse IP de 255.255.255.255 est affichée 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 les journaux et les rapports dans l’un 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 de synchronisation des ressources en cliquant sur les boutons Oui ou Non. Les détails de la synchronisation des ressources incluent,

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

Pour la description des journaux, voir 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 tous les jours (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 la description des journaux, voir Descriptions des journaux 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 la description des journaux, consultez la section Descriptions des journaux 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 pouvez accéder aux compartiments S3 et GCS avec les informations de connexion fournies et utiliser s3cmd ou l’interface de ligne de commande AWS pour S3. Et la ligne de commande gsutil pour GCS.

AWS S3

Pour les journaux et les rapports à livrer 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 Generate Keys sous AWS S3, les clés AWS IAM (clés d’accès et clés secrètes) sont générées et affichées sous IAM Keys. Assurez-vous d’enregistrer les clés, car elles ne sont stockées nulle part pour être consultées ultérieurement.

REMARQUE :

La paire de clés d’accès et de clé secrète est la seule copie des clés privées. Le client doit les stocker en toute sécurité. La régénération des 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. L’interface de ligne de commande AWS doit être installée sur la machine du client pour se connecter à S3.

Pour plus d’informations sur l’utilisation des clés d’accès et secrètes avec s3cmd pour télécharger des rapports depuis le compartiment S3, consultez la FAQ.

AWS S3

Stockage Google Cloud

Pour que les journaux et les rapports soient envoyés à 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 clé constitue la 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 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 de détails sur l’utilisation du fichier clé pour télécharger des fichiers journaux, consultez la FAQ.

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 plateformes 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 de Platform Radar Log Share au format de fichier TSV.

REMARQUE :

  • NEM n’expose jamais les adresses IP complètes des clients. Au lieu de cela, il expose le /28. Par exemple, une adresse IP de 255.255.255.255 est affichée dans un rapport sous la forme 255.255.255.240/28.
  • Les informations GEO du client sont extraites en fonction de l’IPv4 du client, qui est plus détaillé.

Descriptions du journal

Voici les en-têtes de colonnes et les descriptions des journaux radar. Les champs apparaissent dans l’ordre suivant dans les fichiers de sortie :

Journal Description
Timestamp Il s’agit de l’heure UTC de la requête au format AAAA-MM-JJTHH:MI:SSZ. La valeur réelle (à la seconde près) dans les tables de journaux est arrondie à l’heure (2018-03-30T 23:00:00 Z) ou au jour (2018-03-30T 00:00:00 Z) le plus proche dans les tables heure/jour, respectivement. L’horodatage est toujours en UTC dans tous les jeux de données.
ID de nœud unique Également appelé ID de nœud de cache. C’est une valeur arbitraire. En général, il s’agit d’une adresse IP renvoyée par les serveurs CDN Edge pour aider les CDN à identifier en interne quel serveur a traité une demande 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 qu’une erreur 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 plateforme 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.). Pour indiquer que le service est disponible, utilisez les informations renvoyées avec succès dans le délai imparti.
Code de réponse Résultat de la mesure.e.g.0 : réussite, 1 : délai d’attente, 4 : 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, quelle que soit la réponse). Pour les autres types de sonde (RTT et débit), le filtre doit uniquement prendre en compte 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 le débit (14) en kbits/s.
Marché des résolveurs Le 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 du résolveur DNS qui a traité la Request. 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.Les ID peuvent être mappés avec des noms dans https://community-radar.citrix.com/ref/regions.json.gz Remarque : Tous les pays du monde n’ont pas de régions définies.
État de résolution L’état du résolveur DNS qui a traité la requête.Les ID peuvent être mappés aux noms dans https://community-radar.citrix.com/ref/states.json.gz Remarque : Tous les pays du monde n’ont pas d’états définis.
Ville de résolution Ville du résolveur DNS qui a traité la requête.La ville du résolveur est ajoutée en recherchant une adresse IP de résolveur. Les ID peuvent être mappés à des 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. En règle générale, l’ASN qui possède les ID de résolveur DNS peut être mappé avec des noms sur https://community-radar.citrix.com/ref/asns.json.gz
IP de la résolution Adresse IP du résolveur DNS à partir duquel 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 identifiants peuvent être mappés avec des noms sur https://community-radar.citrix.com/ref/countries.json.gz
Région cliente Région de l’utilisateur final qui a généré cette mesure. Généralement, la région géographique dans laquelle se trouve l’adresse IP du client. Les ID peuvent être mappés avec des noms à https://community-radar.citrix.com/ref/regions.json.gz Remarque : Tous les pays du monde n’ont pas de 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 à des noms à https://community-radar.citrix.com/ref/states.json.gz Remarque, que tous les pays du monde n’ont pas d’états définis.
Ville client La 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 à des noms sur https://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. En règle générale, l’ASN qui contient l’adresse IP du client. Les ID peuvent être mappés à des noms sur https://community-radar.citrix.com/ref/asns.json.gz
IP du client L’adresse IP de l’utilisateur final qui a généré cette mesure.
Hôte référent 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.
User Agent Il s’agit de la chaîne de l’agent utilisateur de la page du navigateur qui héberge la balise. Par exemple, si vous utilisez Chrome et que vous parcourez une page contenant la balise Radar, les mesures radar en arrière-plan enregistrent l’agent utilisateur à partir de votre navigateur Chrome. Les mesures incluent le navigateur Chrome, la version de Chrome, des informations sur le système d’exploitation sur lequel Chrome est exécuté, etc.
Heure de recherche DNS (facultatif) Avec l’API Resource Timing, la différence entre la fin de la recherche de domaine et le début de la recherche de domaine est calculée. Il calcule quand 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 suit : DomainLookupEnd - DomainLookupStart.
Heure de connexion TCP (facultatif) Avec l’API Resource Timing, la différence entre la fin de la connexion et le début de la connexion est calculée. Il calcule quand 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 suit : ConnectEnd - ConnectStart.
Durée de connexion sécurisée (facultatif) Avec l’API Resource Timing, la différence entre Connect End et Secure Connection Start est calculée. Il calcule quand 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 suit : ConnectEnd - SecureConnectionStart.
Latence (facultatif) Avec l’API Resource Timing, la différence entre Response Start et Request Start est calculée. Il calcule quand 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) Avec l’API Resource Timing, la différence entre la fin de la réponse et le début de la réponse est calculée. Il calcule quand 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 Ce champ permet de déterminer 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. Un numéro est utilisé pour identifier chaque profil client. Les valeurs de ce champ sont : null, 0, 1, 2, 3, 4. Où, null : implique généralement un ancien client Radar qui ne prend pas en charge l’envoi de la valeur client_profile. 0 : Navigateur ; 1 : iOS - Application Radar Runner pour iOS écrite en Swift ; 2 : Android ; 3 : Navigateur sur la version mobile du site Web ; 4 : iOS - Application Radar Runner pour 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 du SDK AndroidRadar (pour Android) a été utilisée dans l’application mobile. Ce champ est réservé à un usage interne.
Catégorie d’appareils Tous les appareils sont classés dans l’une des catégories suivantes : smartphone, tablette, PC, Smart TV et autres. « 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 d’appareil sur lequel se trouve l’utilisateur, par exemple un iPhone Apple. La chaîne de l’agent utilisateur le détecte dans le navigateur qui s’exécute sur la page hébergeant la balise Radar.
Navigateur Type de navigateur utilisé par l’utilisateur, par exemple Mobile Safari UI/WKWebView 0.0.0. La chaîne de l’agent utilisateur le détecte dans le navigateur qui s’exécute sur la page hébergeant la balise Radar.
OS Le système d’exploitation utilisé. Par exemple, iOS 11.0.3. La chaîne de l’agent utilisateur le détecte à partir du navigateur exécuté sur la page hébergeant la balise Radar.
IP du client Reporting Cette adresse IP est l’adresse IP publique masquée /48 de l’utilisateur effectuant la mesure. Il peut s’agir d’IPv4 ou d’IPv6 (lorsqu’il est pris en charge).

Meilleur rapport anonyme

  • Les meilleurs rapports anonymes aident les fournisseurs à comparer leurs performances à celles du groupe de pairs de l’autre plateforme, c’est-à-dire au sein du même pays, de la même région ou de la même ASN.
  • Les données de performance des 15 meilleurs fournisseurs du groupe homologue sont agrégées sur la base des mêmes catégories. Le meilleur est répertorié à côté du meilleur rapport qualité-prix 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 Cloud/CDN à concentrer les efforts de performance sur les ASN à volume élevé ou critiques pour l’entreprise qui sont peu compétitifs par rapport à leurs pairs.
  • Le rapport fournit des détails sur les performances en fonction 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. Elle est comparée à la « meilleure » plateforme pour les mêmes critères.
  • Disponible pour RTT ou Débit.
  • Ce qui suit est un exemple de meilleur rapport anonyme de plate-forme pour RTT au format de fichier TSV.

Descriptions du journal

Vous trouverez ci-dessous les en-têtes de colonnes et les descriptions du meilleur rapport anonyme. Les champs apparaissent dans l’ordre suivant 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 possède le résolveur DNS.
Nom de l’ASN du résolveur Le nom de l’ASN.
IP de la résolution Adresse IP du résolveur DNS à partir duquel notre infrastructure a reçu la demande DNS.
Pays client Le pays de l’utilisateur final qui a généré cette mesure.
Région cliente 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 du client Numéro ASN (Autonomous System Number) de l’utilisateur final qui a généré cette mesure. Généralement, l’ASN qui possède 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 L’adresse 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 Le nombre de mesures dont le délai a expiré.
Erreurs Le nombre de mesures qui comportaient des erreurs.
Total : Le nombre total de mesures.
Moyenne La moyenne de toutes les valeurs de mesure pour cette ligne.
Meilleure moyenne La meilleure moyenne parmi les 15 meilleurs fournisseurs du groupe de pairs.
Meilleures mesures moyennes Nombre total de mesures ayant produit le meilleur décompte moyen.
Médiane La valeur du 50e centile est la valeur médiane des mesures pour un fournisseur particulier, lorsque les mesures sont répertoriées dans l’ordre.
Meilleure médiane La meilleure valeur du 50e centile (en dessous de laquelle se trouvent 50 % des mesures) des 15 meilleurs fournisseurs du groupe homologue.
Meilleures mesures médianes Nombre total de mesures ayant produit la meilleure médiane
5th Valeur du 5e centile pour le fournisseur.
Meilleur 5e La meilleure valeur du 5e centile parmi les 15 meilleurs fournisseurs du groupe de pairs.
Meilleures 5èmes mesures Nombre total de mesures ayant produit le meilleur_5e
10th Valeur du 10e centile pour le fournisseur.
Meilleur 10e La meilleure valeur du 10e centile parmi les 15 meilleurs fournisseurs du groupe de pairs.
Meilleures mesures 10e Nombre total de mesures ayant produit le meilleur_10e
90th Valeur du 90e centile pour le fournisseur.
Meilleur 90e La meilleure valeur du 90e centile parmi les 15 meilleurs fournisseurs du groupe de pairs.
Meilleures mesures du 90e Nombre total de mesures ayant produit le meilleur 90e
95th Valeur du 95e centile pour le fournisseur.
Meilleur 95e La meilleure valeur au 95e centile parmi les 15 meilleurs fournisseurs du groupe de pairs.
Meilleures mesures de la 95e Nombre total de mesures ayant produit le meilleur 95e
Stdev L’écart type pour le fournisseur
Best Stdev Le meilleur écart type parmi les 15 meilleurs fournisseurs du groupe de pairs.
Meilleures mesures Stdev Nombre total de mesures ayant produit le meilleur std.dev.
Disponibilité La disponibilité en pourcentage pour le fournisseur. La disponibilité est le taux de réussite de la sonde, c.-à-d. Succès/(Succès + Échecs + Délais)
Meilleure disponibilité La meilleure valeur de disponibilité parmi les 15 meilleurs fournisseurs du groupe de pairs.
Meilleures mesures de disponibilité Le nombre de mesures ayant produit la meilleure disponibilité
Importance Valeurs synthétiques générées pour aider à trouver des données exploitables.
ID de nœud unique Ces ID sont une liste séparée par des virgules des ID de nœud uniques pour les mesures de cette ligne.
Type de mesure Valeur de mesure enregistrée, dont la signification varie selon le type de sonde. Il s’agit de HTTP_COLD (disponibilité), HTTP_RTT (temps aller-retour) ou HTTP_KBPS (débit).
ID du fournisseur Numéro d’identification NetScaler ITM interne de ce fournisseur.

Rapport d’ID de nœud de cache (précédemment rapport du fournisseur de services multiples)

Ce rapport est utilisé pour identifier le serveur ou le centre de données spécifique qui a répondu à une demande et 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 comprennent le temps de réponse, le débit, la disponibilité (type de sonde), l’adresse IP du résolveur DNS, l’adresse IP du client /28 et le nœud de mise en cache qui a servi les objets.
  • Voici un exemple de rapport Platform Cache Node ID au format de fichier TSV.

Descriptions du journal

Vous trouverez ci-dessous les en-têtes de colonnes et les descriptions du rapport d’ID de nœud de cache. Les champs apparaissent dans l’ordre suivant dans les fichiers de sortie :

Journal Description
Nom du fournisseur C’est le nom du fournisseur qui est mesuré.
Valeur de mesure Valeur de mesure enregistrée, dont la signification varie selon le type de sonde. Il s’agit des mesures connect (1) /RTT (0) en millisecondes et des mesures de débit (14) en kbps.
ID de nœud unique Il est connu sous le nom d’ID de nœud de cache. Une valeur arbitraire, généralement une adresse IP renvoyée par les serveurs CDN Edge 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 trouve une erreur lors de la détection UNI, telle qu’une erreur 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 possède le résolveur DNS.
Nom de l’ASN du résolveur Le nom de l’ASN.
IP de la résolution Adresse IP du résolveur DNS à partir duquel notre infrastructure a reçu la demande DNS.
Pays client Le pays de l’utilisateur final qui a généré cette mesure.
Région cliente 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 possède 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 L’adresse 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 Le nombre de mesures dont le délai a expiré.
Erreur Le nombre de mesures qui comportaient des erreurs.
Total : Le nombre total de mesures.
Moyenne La moyenne des valeurs de mesure pour chaque ligne.
Médiane La valeur du 50e centile est la valeur médiane des mesures pour un fournisseur particulier, lorsque les mesures sont répertoriées dans l’ordre.
5th Valeur du 5e centile pour le fournisseur.
10th Valeur du 10e centile pour le fournisseur.
90th Valeur du 90e centile pour le fournisseur.
95th Valeur du 95e centile pour le fournisseur.
Stdev L’écart type pour le fournisseur.
Disponibilité La disponibilité en pourcentage pour le fournisseur.
Importance Valeurs synthétiques générées pour aider à trouver des données exploitables.

Rapport horaire par pays/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 de rapport Platform Hourly by Country/ASN au format de fichier TSV.

Descriptions du journal

Vous trouverez ci-dessous les en-têtes de colonnes et les descriptions du rapport horaire par pays/ASN. Les champs apparaissent dans l’ordre suivant dans les fichiers de sortie :

Journal Description
Horodatage 60 minutes L’heure UTC à laquelle les mesures ont été prises est tronquée à l’heure, par exemple2018-03-11T 23:00:00.
Nom du fournisseur C’est le nom du fournisseur qui est mesuré.
Type de mesure Valeur de mesure enregistrée, dont la signification varie selon le type de sonde. Il s’agit de HTTP_COLD (disponibilité), HTTP_RTT (temps aller-retour) ou HTTP_KBPS (débit).
Pays client Le 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 possède 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 Le nombre de mesures dont le délai a expiré.
Erreur Le nombre de mesures qui comportaient des erreurs.
Total : Le nombre total de mesures.
Moyenne La moyenne des valeurs de mesure pour chaque ligne.
Médiane La valeur du 50e centile est la valeur médiane des mesures pour un fournisseur particulier, lorsque les mesures sont répertoriées dans l’ordre.
5th Valeur du 5e centile pour le fournisseur.
10th Valeur du 10e centile pour le fournisseur.
90th Valeur du 90e centile pour le fournisseur.
95th Valeur du 95e centile pour le fournisseur.
Stdev L’écart type pour le fournisseur.
Disponibilité La 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’identification NetScaler ITM interne de ce fournisseur.

Descriptions et rapports des journaux radar pour les FAI

Journaux radar pour les FAI

Les journaux radar permettent aux FAI de mesurer en détail leurs performances par rapport aux plateformes mondiales. Les FAI peuvent utiliser ces données pour trouver les domaines dans lesquels des améliorations doivent être apportées ou pour vérifier les performances attendues.

  • Permet d’accéder aux mesures radar.
  • Fournit des mesures prises auprès des FAI sur des plateformes publiques, quelle que soit la page qui a généré la mesure.
  • Les journaux radar incluent un sous-ensemble des champs disponibles dans les journaux bruts, avec certaines données anonymisées : IP du client /28, hachage MD5 du référent.
  • Les fichiers journaux sont au format TSV.
  • Voici un exemple de partage de journaux Network Radar au format de fichier TSV.

Descriptions du journal

Voici les en-têtes de colonnes et les descriptions des journaux Radar pour les FAI. Les champs apparaissent dans l’ordre suivant dans les fichiers de sortie.

Journal Description
Timestamp Il s’agit de l’heure UTC de la requête au format YYYY-MM-DDTHH:MI:SSZ. La valeur réelle (à la seconde près) dans les tables de journaux est arrondie à l’heure (2018-03-30T 23:00:00 Z) ou au jour (2018-03-30T 00:00:00 Z) le plus proche dans les tables heure/jour, respectivement. L’horodatage est toujours en UTC dans tous les jeux de données.
ID du fournisseur ID interne de la plateforme 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.). Les informations renvoyées avec succès dans le délai imparti sont utilisées pour indiquer que le service est disponible.
Code de réponse Résultat de la mesure.e.g.0 : réussite, 1 : délai d’attente, 4 : 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). Pour les autres types de sonde (RTT et débit), le filtre doit uniquement prendre en compte 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 s’agit des mesures de disponibilité (1)/Temps de réponse (0) en millisecondes et de Débit (14) en Kbits/s.
Marché des résolveurs Le 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 du résolveur DNS qui a traité les ID de demande peut être mappé 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 ID de demande peut être mappée aux noms sur https://community-radar.citrix.com/ref/regions.json.gz. Tous les pays du monde n’ont pas de régions définies.
État de résolution L’état du résolveur DNS qui a traité les ID de demande peut être mappé aux noms sur https://community-radar.citrix.com/ref/states.json.gz. Tous les pays du monde n’ont pas d’États définis.
ASN de résolution Numéro de système autonome (NSA) de la résolution DNS qui a traité la demande. En général, l’ASN qui possède les ID de résolveur DNS peut être mappé aux noms sur https://community-radar.citrix.com/ref/asns.json.gz.
IP de la résolution Adresse IP du résolveur DNS à partir duquel 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 identifiants peuvent être mappés avec des noms sur https://community-radar.citrix.com/ref/countries.json.gz
Région cliente Région de l’utilisateur final qui a généré cette mesure. Généralement la région géographique dans laquelle se trouve l’adresse IP du client. Les ID peuvent être mappés aux noms sur https://community-radar.citrix.com/ref/regions.json.gz. Tous les pays du monde n’ont pas de régions définies.
État du client État de l’utilisateur final qui a généré cette mesure. En général, l’état dans lequel se trouve l’adresse IP du client. Les ID peuvent être mappés aux noms sur https://community-radar.citrix.com/ref/states.json.gz. Tous les pays du monde n’ont pas d’É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 possède l’adresse IP du client. Les ID peuvent être mappés à des noms sur https://community-radar.citrix.com/ref/asns.json.gz
IP du client L’adresse IP de l’utilisateur final qui a généré cette mesure.
Hôte référent 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.
User Agent Il s’agit de la chaîne de l’agent utilisateur de la page du navigateur qui héberge la balise. Par exemple, si vous utilisez Chrome et que vous parcourez une page contenant la balise Radar, les mesures radar en arrière-plan enregistrent l’agent utilisateur à partir de votre navigateur Chrome. Les mesures incluent le navigateur Chrome, la version de Chrome, des informations sur le système d’exploitation sur lequel Chrome est exécuté, etc.
Heure de recherche DNS (facultatif) Avec l’API Resource Timing, la différence entre la fin de la recherche de domaine et le début de la recherche de domaine est calculée. Il calcule quand 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 suit : DomainLookupEnd - DomainLookupStart.
Heure de connexion TCP (facultatif) Avec l’API Resource Timing, la différence entre la fin de la connexion et le début de la connexion est calculée. Il calcule quand 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 suit : ConnectEnd - ConnectStart.
Durée de connexion sécurisée (facultatif) Avec l’API Resource Timing, la différence entre la fin de connexion et le démarrage de la connexion sécurisée est calculée. Il calcule quand 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 suit : ConnectEnd - SecureConnectionStart.
Latence (facultatif) Avec l’API Resource Timing, la différence entre Response Start et Request Start est calculée. Il calcule quand 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) Avec l’API Resource Timing, la différence entre la fin de la réponse et le début de la réponse est calculée. Il calcule quand 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 Ce champ permet de déterminer 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. Un numéro est utilisé pour identifier chaque profil client. Les valeurs de ce champ sont : null, 0, 1, 2, 3, 4. Où, null : implique généralement un ancien client Radar qui ne prend pas en charge l’envoi de la valeur client_profile. 0 : Navigateur ; 1 : iOS - Application Radar Runner pour iOS écrite en Swift ; 2 : Android ; 3 : Navigateur sur la version mobile du site Web ; 4 : iOS - Application Radar Runner pour 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 du SDK AndroidRadar (pour Android) a été utilisée dans l’application mobile. Ce champ est réservé à un usage interne.
Catégorie d’appareils Tous les appareils sont classés dans l’une des catégories suivantes : smartphone, tablette, PC, Smart TV et autres. « 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 d’appareil sur lequel se trouve l’utilisateur, par exemple un iPhone Apple. La chaîne de l’agent utilisateur le détecte dans le navigateur qui s’exécute sur la page hébergeant la balise Radar.
Navigateur Type de navigateur utilisé par l’utilisateur, par exemple Mobile Safari UI/WKWebView 0.0.0. La chaîne de l’agent utilisateur le détecte dans le navigateur qui s’exécute sur la page hébergeant la balise Radar.
OS Système d’exploitation utilisé, par exemple iOS 11.0.3. La chaîne de l’agent utilisateur le détecte dans le navigateur qui s’exécute sur la page hébergeant la balise Radar.

Rapport de sous-réseau pour les FAI

  • Le rapport fournit aux FAI des informations sur les performances des sous-réseaux spécifiques de leurs réseaux pour leurs utilisateurs via les plateformes mesurées.
  • Il fournit des informations sur le fournisseur de services qui a répondu à une demande spécifique.
  • Cela aide à comprendre les performances du sous-réseau réseau.
  • Les performances comprennent le temps de réponse, le débit, la disponibilité (type de sonde), l’adresse IP du résolveur DNS, l’adresse IP du client /28 et le nœud de mise en cache qui a servi les objets.
  • Voici un exemple de rapport de sous-réseau réseau au format de fichier TSV.

Descriptions du journal

Vous trouverez ci-dessous les en-têtes de colonnes et les descriptions du rapport de sous-réseau pour les FAI. Les champs apparaissent dans l’ordre suivant dans les fichiers de sortie :

Journal Description
Nom de l’ASN Le 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 s’agit des mesures connect (1) /RTT (0) en millisecondes et des 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 possède le résolveur DNS.
IP de la résolution Adresse IP du résolveur DNS à partir duquel notre infrastructure a reçu la demande DNS.
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 possède l’adresse IP du client.
IP du client L’adresse IP de l’utilisateur final qui a généré la mesure.
ID de la plate-forme ID de la plateforme du fournisseur de services sur laquelle la requête a été effectuée.
Nom de la plateforme Le nom de la plateforme du fournisseur de services sur laquelle la requête a été effectuée
Succès Nombre total de mesures réussies.Conseil : Succès/Total == Disponibilité.
Délai d’expiration Le nombre de mesures dont le délai a expiré.
Erreur Le nombre de mesures qui comportaient des erreurs.
Total : Le nombre total de mesures.
Moyenne La moyenne des valeurs de mesure pour chaque ligne.
Médiane La valeur du 50e centile est la valeur médiane des mesures pour un fournisseur particulier, lorsque les mesures sont répertoriées dans l’ordre.
5th Valeur du 5e centile pour le fournisseur.
10th Valeur du 10e centile pour le fournisseur.
90th Valeur du 90e centile pour le fournisseur.
95th Valeur du 95e centile pour le fournisseur.
Stdev L’écart type pour le fournisseur.
Disponibilité La 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 s’agit de HTTP_COLD (disponibilité), HTTP_RTT (temps aller-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 » FAI aident les FAI à concentrer leurs efforts de performance sur les plateformes à volume élevé ou critiques et sur les domaines où la concurrence est faible 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.
  • Voici un exemple de meilleur rapport Network Anonymous pour RTT au format de fichier TSV.

Descriptions du journal

Vous trouverez ci-dessous les en-têtes de colonnes et les descriptions du meilleur rapport anonyme. Les champs apparaissent dans l’ordre suivant 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 s’agit de HTTP_COLD (disponibilité), HTTP_RTT (temps aller-retour) ou HTTP_KBPS (débit).
Pays client Le pays de l’utilisateur final qui a généré cette mesure.
Région cliente 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 du client Numéro ASN (Autonomous System Number) de l’utilisateur final qui a généré cette mesure. Généralement, l’ASN qui possède 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 du fournisseur de services sur laquelle la requête a été tentée.
Nom de la plateforme Nom de la plate-forme du fournisseur de services sur 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 Le nombre de mesures dont le délai a expiré.
Erreurs Le nombre de mesures qui comportaient des erreurs.
Total : Le nombre total de mesures.
Moyenne La moyenne de toutes les valeurs de mesure pour cette ligne.
Meilleure moyenne La meilleure moyenne parmi les 15 meilleurs fournisseurs du groupe de pairs.
Meilleures mesures moyennes Nombre total de mesures ayant produit le meilleur décompte moyen.
Médiane La valeur du 50e centile est la valeur médiane des mesures pour un fournisseur particulier, lorsque les mesures sont répertoriées dans l’ordre.
Meilleure médiane La meilleure valeur du 50e centile (en dessous de laquelle se trouvent 50 % des mesures) des 15 meilleurs fournisseurs du groupe homologue.
Meilleures mesures médianes Nombre total de mesures ayant produit la meilleure médiane
5th Valeur du 5e centile pour le fournisseur.
Meilleur 5e La meilleure valeur du 5e centile parmi les 15 meilleurs fournisseurs du groupe de pairs.
Meilleures 5èmes mesures Nombre total de mesures ayant produit le meilleur_5e
10th Valeur du 10e centile pour le fournisseur.
Meilleur 10e La meilleure valeur du 10e centile parmi les 15 meilleurs fournisseurs du groupe de pairs.
Meilleures mesures 10e Nombre total de mesures ayant produit le meilleur_10e
90th Valeur du 90e centile pour le fournisseur.
Meilleur 90e La meilleure valeur du 90e centile parmi les 15 meilleurs fournisseurs du groupe de pairs.
Meilleures mesures du 90e Nombre total de mesures ayant produit le meilleur 90e
95th Valeur du 95e centile pour le fournisseur.
Meilleur 95e La meilleure valeur au 95e centile parmi les 15 meilleurs fournisseurs du groupe de pairs.
Meilleures mesures de la 95e Nombre total de mesures ayant produit le meilleur 95e
Stdev L’écart type pour le fournisseur.
Best Stdev Le meilleur écart type parmi les 15 meilleurs fournisseurs du groupe de pairs.
Meilleures mesures Stdev Nombre total de mesures ayant produit le meilleur std.dev.
Disponibilité La disponibilité en pourcentage pour le fournisseur. La disponibilité est le taux de réussite de la sonde, c’est-à-dire Succès/(Succès + Échecs + Délais d’expiration)
Meilleure disponibilité La meilleure valeur de disponibilité parmi les 15 meilleurs fournisseurs du groupe de pairs.
Meilleures mesures de disponibilité Le nombre de mesures ayant produit la meilleure disponibilité.
Importance Valeurs synthétiques générées pour aider à trouver des données exploitables.

Description des journaux 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 varient en fonction 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 lors du chargement de la page Web surveillée.

Des mesures peuvent être prises pour chaque session Radar (si elle est activée). Chaque session est associé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 de données de synchronisation de navigation au format de fichier TSV.

Vous trouverez ci-dessous les en-têtes de colonnes et les descriptions des journaux de synchronisation de navigation. Les champs apparaissent dans l’ordre suivant dans les fichiers de sortie :

Journal Description
Timestamp Il s’agit de l’heure UTC de la requête au format YYYY-MM-DDTHH:MI:SSZ. La valeur réelle (à la seconde près) dans les tables de journaux est arrondie à l’heure (2018-03-30T 23:00:00 Z) ou au jour (2018-03-30T 00:00:00 Z) le plus proche dans les tables heure/jour, respectivement. Il est toujours en UTC dans tous les ensembles de données.
Code de réponse Résultat de la mesure.e.g.0 : réussite, 1 : délai d’attente, 4 : 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). Pour les autres types de sonde (RTT et débit), le filtre doit uniquement prendre en compte 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.
Marché des résolveurs Le 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 du résolveur DNS qui a traité la Request. 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.IDs peut être mappée aux noms sur https://community-radar.citrix.com/ref/regions.json.gz. Tous les pays du monde n’ont pas de régions définies.
État de résolution L’état du résolveur DNS qui a traité la requête.ID peut être mappé aux noms sur https://community-radar.citrix.com/ref/states.json.gz. Tous les pays du monde n’ont pas d’É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 possède le résolveur DNS. Les ID peuvent être mappés à des noms sur https://community-radar.citrix.com/ref/asns.json.gz
IP de la résolution Adresse IP du résolveur DNS à partir duquel 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 identifiants peuvent être mappés avec des noms sur https://community-radar.citrix.com/ref/countries.json.gz
Région cliente Région de l’utilisateur final qui a généré cette mesure. Généralement la région géographique dans laquelle se trouve l’adresse IP du client. Les ID peuvent être mappés aux noms sur https://community-radar.citrix.com/ref/regions.json.gz. Tous les pays du monde n’ont pas de régions définies.
État du client État de l’utilisateur final qui a généré cette mesure. En général, l’état dans lequel se trouve l’adresse IP du client. Les ID peuvent être mappés aux noms sur https://community-radar.citrix.com/ref/states.json.gz. Tous les pays du monde n’ont pas d’É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 possède l’adresse IP du client. Les ID peuvent être mappés à des noms sur https://community-radar.citrix.com/ref/asns.json.gz
IP du client L’adresse 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 Referer 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 d’appareils Tous les appareils sont classés dans l’une des catégories suivantes : smartphone, tablette, PC, Smart TV et autres. « 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 d’appareil sur lequel se trouve l’utilisateur, par exemple un iPhone Apple. La chaîne de l’agent utilisateur le détecte dans le navigateur qui s’exécute sur la page hébergeant la balise Radar.
Navigateur Type de navigateur utilisé par l’utilisateur, par exemple Mobile Safari UI/WKWebView 0.0.0. La chaîne de l’agent utilisateur le détecte dans le navigateur qui s’exécute sur la page hébergeant la balise Radar.
OS Système d’exploitation utilisé, par exemple iOS 11.0.3. La chaîne de l’agent utilisateur le détecte dans le navigateur qui s’exécute sur la page hébergeant la balise Radar.
Heure de recherche DNS Avec l’API Resource Timing, la différence entre la fin de la recherche de domaine et le début de la recherche de domaine est calculée. Il calcule quand 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 suit : DomainLookupEnd - DomainLookupStart.
Temps de connexion TCP Avec l’API Resource Timing, la différence entre la fin de la connexion et le début de la connexion est calculée. Il calcule quand 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 suit : ConnectEnd - ConnectStart.
Temps de connexion sécurisée Avec l’API Resource Timing, la différence entre la fin de connexion et le démarrage de la connexion sécurisée est calculée. Il calcule quand 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 suit : ConnectEnd - SecureConnectionStart.
Charger l’événement Il s’agit de la durée ou du temps écoulé entre le début et la fin de l’événement de chargement. Il est calculé comme LoadEventEnd - 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. Elle est calculée comme suit : 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 écoulé entre le début de la navigation et la fin de l’événement de chargement de page. Il est calculé comme suit : - Fin de l’événement de chargement - Début de la navigation 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 Avec l’API Resource Timing, la différence entre Response Start et Request Start est calculée. Il calcule quand 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 Avec l’API Resource Timing, la différence entre la fin de la réponse et le début de la réponse est calculée. Il calcule quand 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 d’amélioration 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 exemples de données de partage de journaux Openmixet HTTP Openmix au format de fichier TSV.

Description du journal OpenMix

Journal Description
Timestamp Il s’agit de l’heure UTC de la requête au format YYYY-MM-DDTHH:MI:SSZ. La valeur réelle (à la seconde près) dans les tables de journaux est arrondie à l’heure (2018-03-30T 23:00:00 Z) ou au jour (2018-03-30T 00:00:00 Z) le plus proche dans les tables heure/jour, respectivement. L’horodatage 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 traite la demande. Cette valeur est toujours égale à 1.
ID client du propriétaire de l’application L’ID client du propriétaire de l’application qui répond à la demande. Pour les requêtes HTTP, codez cet ID dans le chemin de la requête et utilisez-le pour rechercher l’application à exécuter.
ID de l’application L’ID de l’application dans le compte du client qui répond à la demande. Cet ID est également codé dans le chemin de la requête HTTP. Les ID d’application commencent à 1 et sont uniques au client. Vous devez pleinement qualifier les requêtes pour un ID d’application spécifique en interrogeant l’AppOwnerCustomerID.
Version de l’application Version de l’application qui a géré 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 reçoivent généralement des mises à jour dans des délais similaires, mais presque jamais exactement au même moment. Il est probable que des décisions qui se chevauchent dans le temps utilisent différentes versions d’une application au cours du processus de mise à jour.
Nom de l’application Le nom de l’application qui a géré le compte.
Marchés Le marché de l’utilisateur final qui a généré cette mesure.
Pays Le 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 possède 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 efficace 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 de la demande (par rapport à l’ID Resolver/ECS/EDNS pour le flux DNS). C’est l’adresse que le système considère comme la cible lors du traitement des informations. Cette adresse IP est soit l’adresse IP du résolveur demandeur, soit 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 Le 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 possède le résolveur DNS.
Nom de l’ASN du résolveur Le nom de l’ASN du résolveur qui a traité la demande.
IP de la résolution Adresse IP du résolveur DNS à partir duquel notre infrastructure a reçu la demande DNS.
Nom du fournisseur de décision Alias de la plateforme sélectionnée par une application.
Code motif Code de motif défini dans l’application décrivant la raison de la décision.
Journal des motifs Ce journal est une sortie définie par le client depuis 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 relatives à l’application Openmix.
Mode de secours Ce mode 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 une extension de sous-réseau client EDNS.
TTL Le TTL (Time To Live) qui a été rendu.
Réponse Le CNAME renvoyé par la demande.
Résultat La valeur de ce champ est toujours 1.
Contexte Il s’agit du résumé des données Radar qui étaient disponibles pour Openmix lorsque la requête 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 qui font des demandes en même temps peuvent avoir des chaînes de contexte différentes.

Description du journal de l’API HTTP Openmix

Journal Description
Timestamp Il s’agit de l’heure UTC de la requête au format YYYY-MM-DDTHH:MI:SSZ. La valeur réelle (à la seconde près) dans les tables de journaux est arrondie à l’heure (2018-03-30T 23:00:00 Z) ou au jour (2018-03-30T 00:00:00 Z) le plus proche dans les tables heure/jour, respectivement. L’horodatage 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 traite la demande. Cette valeur est toujours égale à 1.
ID client du propriétaire de l’application L’ID client du propriétaire de l’application qui répond à la demande. Pour les requêtes HTTP, codez cet ID dans le chemin de la requête et il est utilisé pour rechercher l’application à exécuter.
ID de l’application L’identifiant de l’application dans le compte du client qui répond à la demande. Cet ID est également codé dans le chemin de la requête HTTP. Les ID d’application commencent à 1 et sont uniques au client. Vous devez pleinement qualifier les requêtes pour un ID d’application spécifique en interrogeant l’AppOwnerCustomerID.
Version de l’application Version de l’application qui a géré 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 reçoivent généralement des mises à jour dans des délais similaires, mais presque jamais exactement au même moment. Il est probable que des décisions qui se chevauchent dans le temps utilisent différentes versions d’une application au cours du processus de mise à jour.
Nom de l’application Le nom de l’application qui a géré le compte.
Marchés Le marché de l’utilisateur final qui a généré cette mesure.
Pays Le 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 L’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’identification réseau associé au nom ASN
Nom de l’ASN Nom de l’ASN de l’utilisateur final qui a généré la mesure.
IP efficace 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 de la demande (par rapport à l’ID Resolver/ECS/EDNS pour le flux DNS). C’est l’adresse que le système considère comme la cible lors du traitement des informations. Cette adresse IP est soit l’adresse IP du résolveur demandeur, soit l’adresse IP ECS du client si EDNS ECS est pris en charge. Toutes les données de performance de sonde, les informations géographiques, etc., transmises à la logique de l’application sont basées sur cette adresse IP.
Nom du fournisseur de décision Alias de la plateforme sélectionnée par une application.
Code motif Code de motif défini dans l’application décrivant la raison de la décision.
Journal des motifs Ce journal est une sortie définie par le client depuis 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 relatives à l’application Openmix.
Mode de secours Ce mode 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 : réussite, 1 : délai d’attente, 4 : 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, quelle que soit la réponse). Pour les autres types de sonde (RTT et débit), le filtre doit uniquement prendre en compte 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.
Méthode HTTP La méthode HTTP (Get/Post/Options/etc) concerne la demande qui a été faite au serveur HTTP Openmix par un service client. Ensemble, ces méthodes constituent des parties de l’URL entrante et des réponses HTTP sortantes.
URI C’est le chemin de la requête. Si les clients n’obtiennent pas le comportement qu’ils souhaitent, cela peut être dû à une demande mal structurée. Les journaux indiquent 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, l’intégralité du Referer (protocole, hôte et chemin) est incluse dans une chaîne intitulée Referer.
User Agent Il s’agit de la chaîne de l’agent utilisateur de la page du navigateur qui héberge la balise. Par exemple, si vous utilisez Chrome et que vous parcourez une page contenant la balise Radar, les mesures radar en arrière-plan enregistrent l’agent utilisateur à partir de votre navigateur Chrome. Les mesures incluent le navigateur Chrome, la version de Chrome, des informations sur le système d’exploitation sur lequel Chrome est exécuté, etc.
Contexte Il s’agit du résumé des données Radar qui étaient disponibles pour Openmix lorsque la requête 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 qui font des demandes 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 NetScaler pour obtenir des rapports personnalisés basés sur les données Radar collectées par NetScaler. NetScaler peut générer des rapports à exécuter selon un calendrier. Les 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 transférés vers S3 et GCS ?

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

Où sont stockés les rapports ?

S3 Legacy (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à ?

Le portail fournit une clé « Accès » et une clé « Secret ». Utilisez les touches avec « s3cmd », « awscli » ou d’autres outils pour accéder à S3. Pour Google Storage, le portail télécharge un fichier contenant des informations d’identification à 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 reporter à https://s3tools.org/usage pour l’utilisation, les options et les commandes. Exécutez ensuite la commande suivante :

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

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]
<!--NeedCopy-->

Comment utiliser la configuration s3cmd pour répertorier les fichiers dans le compartiment S3

La première étape consiste à installer s3cmd. Vous pouvez l’installer depuis http://s3tools.org/download

Pour configurer s3cmd, exécutez la commande suivante

s3cmd ls s3://cedexis-netscope/[customer id]/
<!--NeedCopy-->

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 l’utilisez déjà s3cmd, faites une copie de la configuration par défaut, à l’adresse ~/.s3cfg. Par exemple, faites une copie et nommez-la comme ~/.s3cfg_netscope. Remplacez les entrées de clé d’accès et de clé secrète ~/.s3cfg_netscope par celles 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]/
<!--NeedCopy-->

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 souhaitez basculer entre les jeux de clés, intégrez-les dans un fichier. Reportez-vous au fichier avec l’option -c pour spécifier la paire de clés que vous utilisez.

REMARQUE : -c le paramètre indique où se trouve le fichier de configuration, qui 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 que vous avez téléchargé le fichier de clé JSON du compte de service Google, vous pouvez l’utiliser pour authentifier les informations d’identification de votre compte Google, afficher ou télécharger vos fichiers journaux. Par exemple, voici un moyen de le faire à l’aide de Google gcloud et des utilitaires de ligne de gsutil commande :

Étape 1 : Activer le fichier de clé

Les commandes d’authentification gcloud auth activate- ou gsutil config -e sont nécessaires pour authentifier le fichier clé pour l’exécution des 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]
<!--NeedCopy-->

Ou

gcloud auth activate-service-account --key-file=[path and file name of key file]
<!--NeedCopy-->

Pour gsutil :

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

gsutil config -e
<!--NeedCopy-->

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

Une fois que vous avez activé le fichier clé du 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>
<!--NeedCopy-->

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

Vous pouvez passer du compte NetScaler ITM aux autres informations d’identification Google Cloud que vous avez authentifiées en procédant comme suit.

Exécutez d’abord la commande suivante pour répertorier tous vos comptes :

gcloud auth list
<!--NeedCopy-->

Utilisez ensuite la commande suivante pour passer à un autre compte :

gcloud config set account [email of the account to switch to as shown in gcloud auth list]
<!--NeedCopy-->

Vous pouvez passer d’un compte à l’autre à l’aide de la même commande, en remplaçant l’e-mail par l’adresse e-mail du compte vers laquelle vous souhaitez basculer.

À quoi ressemble le nom du fichier ?

Héritage Quotidien :

Les noms ShareFile du journal journalier 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 ShareFile du journal 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 Netscope :

Le format Netscope NEM 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), gzippé.

API HTTP Openmix et Openmix

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

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

Que se passe-t-il si vous ne voyez pas l’option permettant de configurer le partage de journaux en temps réel Openmix et Openmix HTTP API ?

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

Comment activer Openmix et une API HTTP Openmix pour partager des journaux en temps réel et accéder aux fichiers ?

Une fois que le rôle est activé sur votre compte, l’icône Gérer les journaux s’affiche. Cliquez pour ouvrir la boîte de dialogue Logs dans laquelle vous pouvez accéder aux paramètres de configuration des journaux Openmix. Ces paramètres sont essentiellement tout ce dont vous avez besoin pour activer le partage de journaux en temps réel Openmix et HTTP Openmix 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 à générer des journaux pour le client dans les 10 minutes.

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

S3 Legacy (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 du fichier ?

La structure des noms de fichiers 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 Netscope :

Le format Netscope NEM 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 une API HTTP Openmix est JSON (gzippé).