Experience monitoring provides you insight into how web applications are performing from a user or client application perspective. Monitoring points execute transactions that emulate user or client interactions with an application. Transactions are generated by workflows, which can be of two types: Browser workflows and HTTP workflows.
|Use …||To monitor …||By simulating …|
|Browser workflows||Web apps (HTML-based)||End user interactions with a web page|
|HTTP workflows||APIs or web services||Direct HTTP requests|
Figure 1: Monitoring points running workflows interacting with a web app.
Because the workflows are executed from monitoring points at various locations against the same applications or services your users or client apps are using, and generate network traffic in the same way users or clients do, the monitoring results accurately reflect the application performance experienced at those locations. Because the workflows are run at regular intervals, the results show how application performance changes over time. Performance-affecting changes made to the network, to the servers running the applications, or to the applications themselves, are easily identified within APM.
Browser workflows are primarily used to monitor HTML-based web apps. These are scripted synthetic transactions that emulate an end user’s interactions with a web page through a browser. These transactions allow you to determine the web app’s availability and responsiveness. You can also determine whether degradation in responsiveness is due to the browser, the network, or the server. If the issue is with the server or the web app running on it, you can determine where in the app the issue is originating.
Browser workflows use a browser located on the monitoring point to run scripts that emulate the workflow of a typical user. These scripts are run at regular intervals on a continuous basis from Enterprise Monitoring Points strategically located on your network and/or from Global Monitoring Points located around the world. Each time a script is run, the monitoring point measures the amount of time taken by the browser, the network, and the server running the application. It also breaks down the measurements by milestone within the script. All measurements are sent back to APM for analysis and presentation. In addition, you can set alerts that notify you whenever application performance is outside of acceptable limits.
There are two scripting languages available to use with Browser workflows: Selenium and AppNeta Synthethic. We recommend using Selenium as it makes use of a Chrome browser located on the monitoring point. Given that Chrome is the most widely used browser, the results from Selenium-based workflows will more accurately reflect those of your users.
HTTP workflows are primarily used to monitor web service APIs. These workflows generate direct HTTP requests that emulate a client app’s interactions with the web service using GET, PUT, or POST commands. The timing of responses to these requests allow you to determine the web app’s availability and responsiveness.
HTTP workflows generate HTTP requests from a monitoring point to an application’s API. They do this at regular intervals on a continuous basis from Enterprise Monitoring Points strategically located on your network. Each time a request is made, the monitoring point measures how long the response takes, confirms the response status code, and can check for specific content in the response. All measurements are sent back to APM for analysis and presentation. In addition, you can set alerts that notify you whenever application performance is outside of acceptable limits.
Setting up Experience monitoring involves specifying which monitoring points are going to monitor a given web application and creating a script or specifying the HTTP request to interact with the application. The unique combination of monitoring point, web application (referred to as the target), and workflow (which contains the script or HTTP request, its associated variables, alert settings, and Apdex settings) is known as a web path. The set of web paths associated with a given web application are grouped together in a web app group. Each time a script is run or an HTTP request is made against a web application it is known as a web path test.
- Set Up Experience Monitoring - describes how to set up a web app group containing web paths. These are required before you can monitor user experience.
- Introduction to Scripting - provides an introduction to scripting within APM.
- Managing Web Paths - describes how to find, filter, group, and sort web paths.
- Web Path Status - describes how to view web path status.
- Web Path Details - describes how to view web path performance details.