Synthetic Agent Locations
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.
WebDriver HTTP Requests| Script Execution Flow | Potential Issues |
|---|---|
|
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 Flow | Potential Issues |
|---|---|
|
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. |
実行コンテナとブラウザの場所のマッピング
次の表に、使用可能なブラウザの場所、および対応するプロバイダーとコンテナの場所を示します。
| * ブラウザの場所 | プロバイダー | コンテナの場所 |
|---|---|---|
|
バージニア州アッシュバーン | AWS |
米国東部(バージニア北部) |
|
ケベック州モントリオール | AWS | |
|
オンタリオ州トロント | Azure | |
| アムステルダム（オランダ） | Azure | EU（アイルランド） |
| ダブリン（アイルランド） | AWS | |
| フランクフルト（ドイツ） | AWS | |
| ロンドン（英国） | AWS | |
| イタリア、ミラノ | AWS | |
| パリ（フランス） | AWS | |
| 香港（中国） | AWS | アジア太平洋（東京） |
| ソウル（韓国） | AWS | |
| 東京（日本） | AWS | |
| チェンナイ（インド） | Azure | アジア太平洋（シンガポール） |
| ムンバイ（インド） | AWS | |
| シンガポール | AWS | |
| メルボルン（オーストラリア） | Azure | アジア太平洋（シドニー） |
| シドニー（オーストラリア） | AWS | |
| オレゴン州ボードマン | AWS | 米国西部（オレゴン） |
| カリフォルニア州サンフランシスコ | AWS | |
| サンパウロ（ブラジル） | AWS | |
| テキサス州サンアントニオ | Azure | |
| ケープタウン（南アフリカ） | AWS |
アフリカ（ケープタウン） |
| 情報 |
|---|
|
*一部のロケーションは、新しい地域クラウドの要求に基づいてのみ有効になります。地域クラウドに不足しているロケーションを追加するには、必要なロケーションのリストを含むサポートチケットを発行します。 |
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.
- The GRU EUM cloud has access to only AWS locations.