This topic describes a monitoring case regarding user experience.
When a user accesses a service, the whole process can be divided into three phases: page production time (server status), page load time, and page run time. To ensure stable online services, the running status of services is monitored on the server. The existing server monitoring system is quite mature, but the monitoring of the page load time and run time status is far from satisfactory. This is because less emphasis is placed on browser monitoring, due to the mistaken belief that monitoring on the server can partially replace browser monitoring. In this case, the system access details cannot be perceived when the system is running online and a user accesses the system. Therefore, it is extremely difficult to identify a front-end problem that online users occasionally encounter.
Business pain points
Difficulty in locating performance bottlenecks
When a user gives feedback that a page loads slowly, it is difficult to quickly find out where the bottleneck is. Is the slow loading of the page caused by a faulty network, resource loading problem, or page Document Object Model (DOM) parsing problem? Is it about the province and country where the user is located, or the user’s browser and terminal? These problems cannot recur quickly to allow locating detailed reasons.
Inability to get error details for user access
Inability to get asynchronous API call details
Even if the HTTP status code returned from API calling is 200 every time, it does not necessarily mean that the API is completely normal. If the business logic is abnormal, can it be perceived in time? If all the HTTP status codes returned from API calling are normal, but the whole process consumes a long time, how can we get the whole picture and optimize it? With this kind of information unknown, we cannot identify the issues, and therefore cannot improve user experience.
ARMS-based browser monitoring solution
Based on the massive real-time log analysis and processing services provided by Application Real-Time Monitoring Service (ARMS), the browser monitoring function monitors the access conditions of all real online users and solves the preceding problems.
Application overview for identifying exceptions
You can view the information on the application overview page by using the ARMS browser monitoring function, including application satisfaction rating, JS error rate, page speed, API request success rate, and page view (PV) details. In the following example, the average JS error rate is 6.68%, up 15.56% from last week.
Performance data trend and waterfall chart
On the Page Speed page, you can view detailed metrics related to the page performance and the page loading waterfall chart. Then, you can locate the performance bottleneck according to detailed data.
JS error rate and error aggregation
On the JS Error Rate page, you can view a ranking on error rates in descending order and a ranking on error aggregation. Therefore, you can get a straightforward impression about which pages have the highest JS error rate, and which errors are the most common.
On the API Request page, you can view data on API call success rates and time consumption, understanding every detail of the APIs.
On the View Details page, you can view the access details. For example, you can locate an error according to the error information, including stack, file, line, and column.