This topic describes a monitoring case on 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. Currently, while the server monitoring system is quite mature, the monitoring of page load and run time status is far from satisfactory. This is because less emphasis is placed on the browser monitoring, due to the misbelief that monitoring on the server can partially replace the 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 frontend problem that online users occasionally encounter.
Difficult to locate performance bottleneck
When a user gives feedback on slow page loading, it is difficult to quickly find out where the bottleneck is. Is slow page loading caused by a faulty network, resource loading problem, or page DOM parse problem? Is it about the province and country where the user is located, or the user’s browser and equipment? These problems cannot be reproduced quickly for locating detailed reasons.
Unable to get error details for user access
After a system goes live, too many JS errors will prevent the users from using the service normally. If the error details for user access cannot be obtained in time, are we at the risk of losing many users? If a user gives feedback on page usage details, can the use case be reproduced in the shortest period? Can we retrieve the error details and quickly fix the issue? This gives you a glimpse of what difficulties developers may have.
Unable to get API asynchronous calling details
Even if the HTTP status code returned from API calling is 200 everytime, it doesn’t necessoriliy mean that the interface is completely normal. If the business logic is abnormal, can it be perceived in time? If all the HTTP status code returned from API calling is normal, but the whole process consumes a long time, how can we get the whole picture and optimize it? With there unknown, we can’t identify the issues, and therefore can’t improve the user experience.
Based on the massive real-time log analysis and processing services provided by ARMS, the browser monitoring 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 using the browser monitoring function provided by ARMS, including application satisfaction rating, JS error rate, access speed, API request success rate, and PV details. Among them, the average value of the JS error rate is 11.56%, which has increased by 276.05% compared to the same period of the 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 loaded waterfall chart. Then you can locate the performance bottleneck according to detailed data.
JS error rate and error aggregation
On the JS Stability 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 are with the highest JS error rate, and which errors are the most common to see.
On the API Request page, you can view data on API success rates and time consumption, understanding every detail of the interfaces.
Click View Details and go to the View Details page. Then you can view the access details. For example, you can locate an error according to the error information, including file, stack, line, and col.