With the latest release of our APM tool inspectIT, a new long-awaited feature has been integrated: inspectIT now supports Browser End User Experience Monitoring. This means that for every Java Servlet API based application (or any technology which itself uses the Servlet API), you can now monitor the actually experienced performance of your web front-end via the APIs the internet browsers expose. Examples for such APIs are the Navigation Timing API  and the Resource Timing API. All you need to do to use these new capabilities is to adapt your configuration of inspectIT, no changes are needed on your application itself.

Configuring and Enabling EUM

To use the end user monitoring, it is required that that the inspectIT Java Agent has been integrated into the application. Now let’s have a look at the new configuration options:

In this section, you can now enable the end user monitoring and configure it for your needs (the configuration options are described in detail in our documentation).

When end user monitoring is active, inspectIT injects JavaScript code into your pages, the inspectIT JavaScript Agent. In the shown configuration, we chose this script to be delivered under the “scripts” path, which is the path used by all scripts of my application. The JavaScript Agent consists of many different modules, where each can be individually enabled or disabled based on your needs. For this demo, we enabled all of them.

And that’s it! If you start up the application (in my case Spring Pet Clinic) with this configuration now, the end user monitoring will already perform its duty.

Let the (Monitoring) Games Begin!

Let’s start the Demo Application and open up the welcome page in a browser. The page still looks the same as previously (would be a shame if not), however let us take a look at the source HTML of the page:

As highlighted in the image, two new script tags have appeared right in the beginning of the head section in the source of the page:

  • First, a inline script containing our configuration
  • Second, the actual inspectIT JavaScript Agent with the configured modules

This separation is done to allow the agent to be cached in order to make sure that the performance of your page is not affected negatively. While the JavaScript Agent does not exist under the given URL in your application, the inspectIT Java Agent will make sure that requests to it are still answered correctly: the Java Agent will intercept such requests and send the correct script to the browser. We can test this by opening the agents URL, resulting in the following page:

We can see the minified version of the inspectIT JavaScript Agent. If you are interested in how it works or want to debug some issues, you can just untick the “Deliver minifed agent” option in the configuration in order to have the unminified Agent be sent to the clients.

Now let’s take a look at the actual data. When opening the tracing overview in the inspectIT UI, we can see traces with the origin “Browser”. These are traces which start at the users browser. In the shown screenshot, we opened the trace details view for the first trace with origin “Browser”, which is the request of loading the welcome page.

Let’s go through it step by step. As the root we find our HTTP request performed by the browser to http://localhost:8080/. As we can see, this request has been automatically correctly correlated with the corresponding backend trace at the api-gateway, which is the first child element in the screenshot. Afterwards we can see all the resources loaded by the welcome page, which have been captured because the “Resource Timings Module” is active. At the bottom, we can see that also a JavaScript listener for the event “DOMContentLoaded” is called. This event listener triggers asynchronous loading of the different bits of the page like header and footer using AJAX. These pieces are then dynamically composed to form the welcome page in the browser.
Of course there is a lot more JavaScript execution going on when loading the page, however the inspectIT JavaScript Agent filters this down to only collect the performance relevant information as presented in the screenshot above. You can influence what the Agent considers to be “relevant” by adapting the “Relevancy Threshold” value in the configuration: the JS Agent will use this threshold in order to decide whether a monitored execution (for example, an event listener) will be captured or not. If you are interested in what the JS Agent is capable of monitoring, try setting this threshold to zero. This will result in everything the agent has access to being monitored and being shown in the UI. This setting is however not recommended for productive use.

Next we can try something else: As we enabled the “Listener Instrumentation” Module, we are able to see event listeners of  our application (e.g. clicks), which execute performance relevant actions. If we click on a link of our demo application, we will find the following trace in the inspectIT UI:

For the next section it is important to know that our demo application is built as a single page application. This means that, for example, page links do not cause the entire page to be reloaded, but instead the application dynamically changes the page contents based on the data it queries via AJAX requests. This behavior can be nicely observed when inspecting the trace shown in the screenshot: The click-listener executed first loads an empty HTML template. Subsequently, data is loaded from the back end using another AJAX request. Hereby, we can see that it traverses through multiple back end services, in our case api-gateway and customer-service, before it is returned. This means you can now fully observe traces from the initial click to the resulting back-end actions, like SQL queries!

Long-Term Monitoring with influxDB

In addition to enriching traces with front-end information, enabling the end user monitoring will also store records about the front-end request performance in an influxDB instance, if it is connected to the CMR. With EUM enabled, three influx time series are generated: One for all page-load requests, including the Navigation Timings, one for all resource loads, and one for all AJAX requests. These are generated and populated if the corresponding EUM modules are active. In addition, if you have the “Browser Meta-Info Capturing” Module active, information like the browser or the device of the users are also attached to each measurement point.

Based on this data, it is possible to derive long term usage statics and information on which browsers you need to focus when optimizing your application. The data is best viewed with Grafana Dashboards, for which we already provide sample dashboard configurations. A screenshot of the provided “EUM Summary” dashboard is shown below, which is useful to get a general overview over the health of your application from the end-user perspective:

Conclusion

Here we come to the end of our journey showcasing the capabilities of the new browser end user monitoring feature of inspectIT. Of course this is not the end of the journey for the EUM feature itself, there’s a lot more functionality to come. We are already working on additional modules, for example, to track JavaScript errors and log outputs or for a CSS-selector based instrumentation of the users interaction with the page.

Therefore, if you enjoyed this post (which I hope so) I recommend you to stay tuned on the EUM feature and to continue the journey yourself by trying it out on your application!

Leave a Comment

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close