Pourquoi est-il si important de mesurer le temps de réponse de l'utilisateur final ?| NETSCOUT

Pourquoi est-il si important de mesurer le temps de réponse de l'utilisateur final ?
 

Lorsque les systèmes de gestion des performances réseau ont vu le jour, ils dépendaient en grande partie de tests SNMP et ping actifs afin de faire le suivi de la disponibilité et des performances de l'infrastructure. Ces deux ensembles de données leur permettaient de suivre l'état des appareils défaillants ou fonctionnels, ainsi que le niveau d'utilisation et les erreurs des liaisons au fil du temps.
Ces données étaient extrêmement utiles, mais il n'a pas fallu longtemps pour que des problèmes réseau viennent dépasser ce niveau de visibilité.
 
Il n'a pas fallu longtemps avant que, quand une liaison subissait des pics d'utilisation, savoir qu'il y avait une grosse charge de trafic sur une liaison ne suffît plus - nous avions besoin de savoir de quoi le trafic était composé, et si cela constituait un niveau d'utilisation prévu ou non. Pour nous aider, NetFlow est entré en scène, il est venu ajouter une nuance : « de quoi est composé le trafic » au suivi du « niveau de la charge du trafic » dans l'analyse réseau.
 
Des tests ping actifs, scans SNMP, données NetFlow sont des ensembles de données qu'il est intéressant de posséder, en particulier pour résoudre les problèmes alors qu'ils sont en train de se produire. Mais aujourd'hui, de nombreux problèmes d'application ont trouvé un moyen de se cacher et d'éviter ces méthodes de visibilité, de se soustraire à la détection des outils les utilisant. Cela vient créer une situation où le système de gestion des performances réseau peut afficher des résultats intègres en matière de disponibilité du réseau et d'intégrité, mais l'application continue de souffrir de mauvaises performances.
 
Pour traquer les problèmes comme ceux-ci, des tests de connectivité TCP et des appels d'application synthétique étaient la prochaine étape dans l'évolution des NPM, afin de les sensibiliser davantage aux applications. Toutefois, étant donné que ces tests ne simulent pas correctement la nature dynamique et organique de véritables utilisateurs, ils ne sont pas en mesure de façon fiable de détecter des problèmes d'application qui affectent les utilisateurs finaux.
 

Les temps de réponse de l'utilisateur final entrent en scène.
Pour obtenir un suivi du réseau et des applications au niveau où il devait être pour détecter des problèmes de performance, à la fois en temps réel et de façon rétroactive, nous avons dû nous focaliser sur les paquets. La capture des paquets et une analyse en temps réel fournit aux systèmes de surveillance les renseignements nécessaires pour analyser et signaler les réels problèmes rencontrés par les utilisateurs de l'application réelle, aujourd'hui et hier. Ce niveau de visibilité donne au NPM les données nécessaires pour être centrées sur les applications, en fonction du trafic réel utilisé pour accéder aux applications. Maintenant, les ingénieurs réseau peuvent avoir accès à la disponibilité du réseau, son intégrité, ses flux et données de transaction d'application, en leur donnant les détails nécessaires pour aller à la racine des problèmes d'application évasifs.

 
Le suivi EURT est la meilleure façon de localiser rapidement le problème, de le résoudre, et de rétablir un niveau élevé de performances des applications - tout cela sans pointer du doigt une autre équipe et se rejeter la faute entre différents services.
 
Pour en savoir plus sur la façon de suivre les EURT dans votre environnement, veuillez consulter enterprise.netscout.com/truview
 
 
Powered By OneLink