The primary purpose of Browser Synthetic Monitoring is to perform browser-based testing. To help you test browsers in the locations of your users, Browser Synthetic provides agents in locations around the world. Your scripts, however, are run in a separate location for the security reasons discussed in the next section.

Security Considerations for Scripting

The browsers configured in synthetic jobs are run on shared Windows machines. Because synthetic scripts are written in native Python, they are not run on the shared Windows machines. Instead, each synthetic script is executed in isolation within a Docker container in a location mapped to the configured browser location. This isolation of the agents and scripts guarantees the safety of the data handled by the scripts and has no effect on the performance of the agent.

How This Affects Your Synthetic Jobs

You should understand how the locations of the agent/browser and where the script is executed may affect your synthetic job. For example, if the location of the execution container and the configured browser are not in the same region, you may expect to see some network latency. Also, if you are using the Python Requests library to make HTTP requests, you should know where the request is being made from. 

The following sections provide some insight as to how your job may be affected.

URL Measurements

URL Measurements are used to test site availability and will not be affected because no script is being executed.

Synthetic Scripts

Your script can use different libraries to make HTTP requests. The WebDriver API is used to mimic the browser making HTTP requests. To make cURL-like requests to test REST APIs or to retrieve data, you can use an HTTP library such as the Requests library. The tables below describe how the script is executed and the types of problems you may encounter.

Script Execution FlowPotential Issues
  1. You add your script to a synthetic job and configure the browser location in the Controller UI.
  2. The synthetic job is transmitted to the Synthetic servers.
  3. When the synthetic job is ready to run:
    1. A Docker container is created.
    2. The Docker container communicates with agents in selected regions.
    3. The script is executed within the container.
  4. The script commands are run in a browser using the Remote WebDriver.
  5. After the script finishes running, the agent collects browser metrics and sends them to the Controller UI.
  6. The Controller UI receives and displays the metrics from your synthetic job.

The WebDriver API is used to test the functionality of web pages. You may experience network latency between the execution of the script and the results if the locations of the Docker container and the browser are different.

Because the script is running in a different location, network latency may increase the time to complete the execution of the script. The browser test results collected through this process, however, are not affected by this latency, and thus, the results will be reliable.

Script Execution FlowPotential Issues
  1. You add your script to a synthetic job and configure the browser location in the Controller UI.
  2. The synthetic job is transmitted to the Synthetic servers.
  3. When the synthetic job is ready to run:
    1. A Docker container is created.
    2. The Docker container communicates with agents in selected regions.
    3. The script is executed within the container.
  4. After the script finishes running, the agent sends the script output to the Controller UI.
  5. The Controller UI receives and displays the output from your synthetic job in the script console.

If you are using something other than WebDriver to make HTTP requests, such as the Requests library, you should know where the HTTP request is being made from.

You should also understand that the Controller UI only captures browser metrics, so you may want to capture output from your requests in the script console.

Mapping of Execution Containers and Browser Locations

The table below lists the available browser locations as well as the corresponding provider and container location.

* Browser LocationProviderContainer Location

Ashburn, Virginia

AWS

US East (N. Virginia)

Montreal, Québec

AWS

Toronto, Ontario

Azure
Amsterdam, NetherlandsAzureEU (Ireland) 
Dublin, IrelandAWS
Frankfurt, GermanyAWS
London, United KingdomAWS
Milan, ItalyAWS
Paris, FranceAWS
Hong Kong, ChinaAWSAsia Pacific (Tokyo) 
Seoul, South KoreaAWS
Tokyo, JapanAWS
Chennai, IndiaAzureAsia Pacific (Singapore) 
Mumbai, IndiaAWS
SingaporeAWS
Melbourne, AustraliaAzureAsia Pacific (Sydney) 
Sydney, AustraliaAWS
Boardman, OregonAWSUS West (Oregon)
San Francisco, CaliforniaAWS
Sao Paulo, BrazilAWS
San Antonio, TexasAzure

Info

*Some of the locations are enabled only based on requests in the new regional clouds. To add missing locations in any regional cloud, raise a support ticket with the list of required locations.

Hosted Agent Coverage Variations

Synthetic hosted agents have the following coverage variations:

  • The US EUM cloud has access to both AWS and Azure locations. 
  • The Frankfurt EUM cloud has access to only AWS locations. 
  • The Sydney EUM cloud has access to only AWS locations.

  • The Bombay EUM cloud has access to only AWS locations.