Les tests de navigation web avec ThousandEyes
Précédemment dans A ThousandEyes Endpoint Story…
- Nous avons vu lors du premier article, comment nous pouvions résoudre très rapidement un incident en se basant sur la collecte de métriques réseaux & de performances système de l’ordinateur d’un employé
- Comment, dans une seconde partie, mieux superviser les expériences collaboratives (Webex, Microsoft Teams, Zoom) grâce à la fonctionnalité “Automated Session Tests”
On continue notre tour d’horizon de l’agent ThousandEyes Endpoint grâce à un service qui permet de s’assurer de la bonne expérience d’un utilisateur lorsqu’il consulte des services webs proposés par une entreprise, depuis un navigateur. Pour rappel, cet agent prend la forme d’une application légère à installer sur des postes Windows ou MacOS, et qui va collecter diverses métriques et réaliser des tests synthétiques depuis l’environnement d’un collaborateur.
Le cas d’usage le plus notable est simple à illustrer ! Nous tous en tant qu’employé d’une organisation, devons accéder à des services d’entreprise depuis un navigateur. Qu’on y accède depuis les locaux de l’entreprise (et donc un réseau de confiance), ou à distance (à notre domicile ou en déplacement professionnel), nous avons tous, à un moment de notre vie professionnelle, eu une expérience d’accès web que l’on peut qualifié de moyenne pour diverses raisons.
Les tests de navigations web (aka les “Browser Sessions Tests”)
Allons droit au but. Quel est l’objectif des “Browser Sessions Tests” ? La documentation est assez claire sur ce point. Grâce à un profil de monitoring, l’agent va pouvoir collecter des données lorsqu’un utilisateur ira naviguer sur des noms de domaines spécifiques choisis par l’administrateur de l’entreprise, en fonction du réseau où l’employé se trouve.
Prenons un cas concret d’utilisation. Vous êtes une entreprise qui fournit différents services SaaS à vos utilisateurs de type O365, Salesforces, etc. Vous pouvez décider de collecter des données d’accès à ces différents noms de domaines (par exemple microsoftonline.com, salesforce.com) lorsque l’utilisateur se trouve dans un réseau/subnet IP de votre choix. Par exemple, c’est peut-être l’adresse IP public qui est utilisée lorsque l’employé est présent dans les locaux de l’entreprise.
Toutefois, l’intérêt s’en retrouve accrue lorsque les utilisateurs sont en situation de mobilité. En conséquence, l’outil nous permet d’utiliser la fonction “Anywhere”, où on pourra suivra l’expérience web des utilisateurs peut importe l’endroit où ils se trouvent.
Réalisons quelques tests simples pour illustrer cela !
Tout se déroule depuis le dashboard SaaS de ThousandEyes, où l’administrateur de l’entreprise pourra réaliser les premiers réglages en naviguant dans les onglets : Endpoint Agents → Monitoring Settings → Browser Sessions → Add New Monitored Domain Sets. C’est à cet endroit que l’on va indiquer les noms de domaines que l’administrateur souhaite surveiller. À votre niveau, il faut donc imaginer les services webs qui sont à dispositions des utilisateurs et qui sont accessibles depuis un navigateur.
Pour notre exemple, j’ai créé un “Monitored Domain Set” qui s’appelle DemoCisco, et suivra mon expérience lorsque je tenterai d’accéder aux nom de domaines suivants : cisco.com, meraki.com, webex.com & thousandeyes.com.
On doit, par la suite, appliquer cet ensemble de domaines à des agents via plusieurs méthodes :
- Directement à tous les agents de notre organisation,
- À un nombre d’agents spécifiques que l’on pourra sélectionner via des cases à cocher,
- Via des labels qui sont appliqués à ces agents.
Pour illustrer notre démonstration, nous allons utiliser les labels pour démontrer à quel point cela peut être utile à grande échelle.
Pour une utilisation à grande échelle, les labels tu utiliseras !
À grande échelle, l’utilisation des labels peut être important pour gérer et regrouper un ensemble d’agents/utilisateurs ayant les mêmes caractéristiques. Quelques exemples :
- Label 1 : Tous les utilisateurs en situation de mobilité
- Label 2 : Tous les utilisateurs étant sur le SSID « Entreprise »
- Label 3 : Tous les utilisateurs utilisant MacOS et qui sont connectés via VPN
Comme vous le voyez, les combinaisons et associations peuvent être multiples. Et pour notre exemple, nous allons être carrément spécifique.
Je viens donc de créer le label « WorkFromHome », qui doit répondre à toutes les conditions techniques que j’énumère, c’est-à-dire être sur le bon SSID & BSSID, être connecté via le subnet 192.168.128.0/24 et que l’utilisateur soit sur MacOS.
Si tous les critères correspondent, la section Agents Settings → Endpoint Agents indiquera le label (ou les labels) assigné à l’agent.
Pour illustrer le dynamisme des labels, je me suis connecté via le partage de connexion de mon téléphone mobile. Le SSID (iPhone de Didier) & BSSID sont donc différents, avec un nouveau subnet attribué : 172.20.10.0/28. L’ensemble des conditions n’étant plus remplie, le label « WorkFromHome » n’est plus appliqué :
Et c’est tout ! Il ne reste plus qu’à visiter des pages appartenant aux différents nom de domaines établis dans notre “Monitored Domain Set”.
Plus d’une vingtaines de pages webs visités plus tard, voici le résultat :
L’agent a pu identifier de façon immédiate, les sites que j’ai visités et qui rentrent dans le “Monitored Domain Set” de l’administrateur, afin d’afficher une note sur mon expérience en tant qu’utilisateur. Sur l’ensemble des 29 pages visités entre 16h05 et 16h10, l’expérience globale fut de 97% avec l’ensemble des pages qui fut chargés rapidement. L’agent a détecté une seule erreur venant de mon système (arrêt du chargement de la page) !
Dans la section “Experience Score by Visited Site”, nous avons une note attribuée par noms de domaines visités. En cliquant sur “meraki.cisco.com”, nous avons une nouvelle vue qui résumera toutes les pages visités de ce sous-domaine :
- Un total de 9 pages visités sur ce domaine.
- Un ensemble d’informations sur l’état de l’ordinateur à l’instant même où l’utilisateur visite la page (Version d’OS, RAM, CPU, Version du Navigateur, etc)
- Quel est la qualité du signal Wi-Fi ?
- Les différents temps de réponses pour afficher la page, ainsi que le Waterfall
Il est intéressant de voir que le “Path Trace” vers cette page web nous redirige vers des contenus qui sont hébergés chez Akamai ! C’est donc un bon moyen pour vous de vérifier si votre CDN fonctionne !
Enfin, et selon moi l’une des fonctions les plus intéressantes, surtout lorsque les applications webs sont développés en interne, le Waterfall ! Cela nous permet de connaitre le temps de chargement des différents éléments qui composent une page web (et donc comprendre les causes d’un éventuel ralentissement).
Chaque élément de la page est scruté par l’agent, pour avoir un idée de la taille de l’objet, de sa durée de chargement, d’où vient l’élément en question ? (depuis un CDN?), etc !
Conclusion
Voilà qui conclut notre série sur l’agent ThousandEyes Endpoint sur les postes de travail. J’espère que cela vous permet d’imaginer tout ce qu’il est possible de faire en termes de monitoring grâce à la solution ThousandEyes.
Dîtes-vous que les fonctionnalités du produit ne cessent de s’étendre, via les multiples intégrations qui sont en cours (ThousandEyes for Cisco Secure Client, ThousandEyes on Cisco RoomOS Devices), ou bien via l’acquisition de nouvelles solutions comme Accedian, SamKnows ou CodeBGP.
C’est vraiment un outil formidable pour trouver l’origine d’un problème, de prouver que votre périmètre n’est pas toujours en cause, et de fournir des preuves tangibles aux entités concernés pour accélérer la résolution d’incidents !
Alors, le saviez-vous?
Mes contacts : #twitter / #linkedin
Tags:
