Почему так важно измерять время ответа конечного пользователя?
When Network Performance Management Systems started out, they largely depended on SNMP and active ping testing to monitor infrastructure uptime and performance. These two data sets allowed them to monitor the up/down status of devices, as well as link usage and errors over time.
This data was great stuff, but it didn’t take long for network problems to outpace this level of visibility.
Before long, when a link would spike with utilization, it wasn’t enough to know that there was a bunch of traffic on a link – we needed to know what that traffic was, and whether it was expected usage or not. To help us, NetFlow entered the scene, which added the “What is that traffic” to the “How Much” in network monitoring.
Active ping tests, SNMP scans, and NetFlow is slick set of data to have, especially when troubleshooting live problems. But today, many application issues have found a way to duck and hide around these visibility methods, evading detection from the tools using them. This creates a situation where the Network Performance Management System may show green lights for network uptime and health, but the application continues to suffer poor performance.
To track down issues like these, TCP Connectivity tests and synthetic application calls were the next step in the evolution of NPMs, in an effort to make them more application aware. However, since these tests do not properly simulate the dynamic and organic nature of real users, they aren’t reliably able to flag application problems that impact end users.
End User Response Time enters the scene.
To get network and application monitoring to the level it needed to be to catch performance problems, both real time and back in time, we had to go to the packets. Packet capture and real-time analysis gives monitoring systems the detail needed to analyze and flag real problems experienced by real application users, both now and yesterday. This level of visibility gives the NPM the data needed to be application aware, based on the actual traffic used to access applications. Now, network engineers can have access to network uptime, health, flows, and application transaction data, giving them the detail needed to get to the root of evasive application problems.
Tracking EURT is the best way to quickly find the issue, resolve it, and restore a high level of application performance – all without the finger pointing and cross-silo blame game.