Ensure that the host you want to use for your private location complies with the following requirements.
End-of-support information
There are no new versions of Chromium for Red Hat/Oracle Linux/Rocky Linux 8 beyond version 133.
For important security and stability reasons, we've decided to discontinue our support for installing Synthetic-enabled ActiveGate on Red Hat/Oracle Linux/Rocky Linux 8 after ActiveGate version 1.325.
ActiveGate version 1.325 is the last Synthetic-enabled ActiveGate supported on Red Hat/Oracle Linux/Rocky Linux 8.
Additionally, with Dynatrace version 1.326, we plan to introduce mechanisms preventing Synthetic-enabled ActiveGates on Red Hat/Oracle Linux/Rocky Linux 8 from being updated beyond version 1.325.
Chromium development for Amazon Linux 2 stopped at version 126.
For important security and stability reasons, we've decided to discontinue our support for installing Synthetic-enabled ActiveGate on Amazon Linux 2 after ActiveGate version 1.307.
ActiveGate version 1.307 is the last Synthetic-enabled ActiveGate to support Amazon Linux 2.
Additionally, with Dynatrace version 1.308, we have introduced mechanisms preventing Synthetic-enabled ActiveGates on Amazon Linux 2 from being updated beyond version 1.307.
Chromium development for Red Hat/CentOS 7 stopped at version 126.
For important security and stability reasons, we've decided to discontinue our support for installing Synthetic-enabled ActiveGate on Red Hat/CentOS 7 after ActiveGate version 1.305.
ActiveGate version 1.305 is the last Synthetic-enabled ActiveGate to support Red Hat/CentOS 7.
Additionally, with Dynatrace version 1.306, we have introduced mechanisms preventing Synthetic-enabled ActiveGates on Red Hat/CentOS 7 from being updated beyond version 1.305.
Since Red Hat Enterprise Linux 7 reached End of Maintenance support on June 30, 2024, all of its packages have been archived. This means that it may not be possible to find the required dependencies for update. For more details, see the Red Hat Enterprise Linux 7 status
Antivirus and anti-malware software can adversely affect Dynatrace Synthetic monitoring capabilities. The antivirus or anti-malware software might block the Chromium browser or Dynatrace processes responsible for executing synthetic monitors, cause Synthetic-enabled ActiveGate installation failures, interfere with network communication, and impact the reliability of measurements.
Please also note
To ensure proper stability and performance, consider adding the following directories and processes to the allowed list or excluding them from the policy:
Directories:
All directories with synthetic in their path. For an overview of directories in use, see ActiveGate directories.
Processes:
chrome
vucwrapper
java
This is the minimal list of processes and directories required for Dynatrace Synthetic to operate. It's not guaranteed that the service will function correctly with only these exclusions. Collaborate with your vendor to appropriately allow expected behaviors from Dynatrace.
Prior to contacting Dynatrace support to troubleshoot issues with your private synthetic locations make sure that antivirus or anti-malware software was excluded as a source of problems.
A freshly installed ActiveGate can run your private synthetic monitors (both HTTP and browser monitors) on the following operating systems.
Windows
Supported operating systems
Windows OS
Versions
Windows Server
2016, 2019, 2022
Chromium version on Windows
On Windows, the ActiveGate installer package includes the Chromium browser used to run browser monitors. The table below shows the Chromium versions that are bundled with the respective ActiveGate versions.
ActiveGate version
Included Chromium version
1.327
141
1.325
140
1.323
139
1.321
138
1.319
138
1.317
137
1.315
136
1.313
135
1.311
134
1.309
133
1.307
132
1.305
130
1.303
129
1.301
128
Unsupported Windows versions for testing purposes only
If you only want to test private Synthetic locations on a non-production host, for example, your own desktop, you can install a Synthetic-enabled ActiveGate on unsupported Windows versions such as Windows 10 or Windows 11.
The Synthetic installer can be installed on all minor releases of Oracle Linux 9. However, we recommend using the latest currently supported versions according to documentation for Oracle Linux 9.
2
The Synthetic installer can be installed on all minor releases of Rocky Linux 9. However, we recommend using the latest currently supported versions according to Rocky Linux Release and Version Guide.
ActiveGate version 1.305 is the last Synthetic-enabled ActiveGate to support Red Hat/CentOS 7.
2
ActiveGate version 1.307 is the last Synthetic-enabled ActiveGate to support Amazon Linux 2.
3
ActiveGate version 1.325 is the last Synthetic-enabled ActiveGate to support Red Hat/Oracle Linux/Rocky Linux 8.
Chromium versions on Linux
We strongly recommend that you keep your Linux-based Synthetic-enabled ActiveGates and Chromium versions updated—Dynatrace supports Chromium versions that are no more than two versions behind the latest Dynatrace-supported version for a specific ActiveGate release. For example, if the latest supported Chromium version is 103, Dynatrace supports up to Chromium version 101. If the provided Chromium version is significantly older for a specific OS, we support only the provided version. See information on updating Chromium automatically and manually.
On Linux, the ActiveGate installer downloads the Chromium dependencies that are required by the Synthetic engine. On Red Hat and Rocky, you need to enable particular repositories from which the installer downloads the dependencies. The Dynatrace web UI provides you with all the required commands. For detailed instructions, see Create a private synthetic location.
When installing ActiveGate and Chromium from a custom, local repository, you need to resolve all dependencies and enable repositories as required; the custom repository can be used only for Chromium packages, not their dependencies. Place the Chromium package archive and the signature file in the custom repository for installation. If your package archive file is https://synthetic-packages.s3.amazonaws.com/Chromium/snap/chromium-107.0.5304.87-2168.tgz (Chromium 107 for Ubuntu 20 and 22 on ActiveGate version 1.255), you can find the signature file by appending .sig to the URL: https://synthetic-packages.s3.amazonaws.com/Chromium/snap/chromium-107.0.5304.87-2168.tgz.sig.
Chromium development for Red Hat/CentOS 7 and Amazon Linux 2 stopped at version 126.
Since Red Hat Enterprise Linux 7 reached End of Maintenance support on June 30, 2024, all of its packages have been archived. This means that it may not be possible to find the required dependencies for update. For more details, see the Red Hat Enterprise Linux 7 status
Due to changes in libdav1d.so.6 packet availability Chromium versions older than 130 cannot be installed on Red Hat/Rocky Linux 9.
Please refer to troubleshooting guide for details.
ActiveGate version
Latest supported Chromium version Red Hat, CentOS, Oracle Linux 8
Latest supported Chromium version Ubuntu
Latest supported Chrome for Testing version Amazon Linux 2023, Ubuntu 24, Oracle Linux 9
If not configured correctly, the File Access Policy Daemon (fapolicyd) can potentially affect Dynatrace Synthetic monitoring capabilities. Similarly to antivirus or anti-malware software, fapolicyd might block the Chromium browser or Dynatrace processes responsible for executing synthetic monitors.
To ensure proper stability and performance, consider adding directories and processes to the allowed list or excluding them from the policy. For more detailed information, refer to the Red Hat documentation on fapolicyd. Prior to contacting Dynatrace support to troubleshoot issues with your private synthetic locations, make sure that fapolicyd was excluded as a source of problems.
File Access Policy Daemon framework can be run in debug mode where all denials are logged, making tracking down missing rules and troubleshooting issues easier. For more detailed information about its debug mode, refer to the documentation on troubleshooting problems related to fapolicyd
Hardware requirements
General considerations
Note that a Synthetic-enabled ActiveGate has more demanding hardware and system requirements than a regular Environment or Cluster ActiveGate. We strongly recommend using a Synthetic-enabled ActiveGate exclusively for synthetic monitoring purposes.
Any additional component running on the host should be taken into account when planning resources provisioning. For instance, if the location is monitored by OneAgent or another deep monitoring solution, memory (RAM) requirements will increase.
You need to uninstall and reinstall your Synthetic-enabled ActiveGate to change its size, for example, after increasing the resources of your S-sized ActiveGate to meet the requirements for a size M. Reinstallation is required before you can make use of the updated resources for synthetic monitoring; otherwise, your ActiveGate will continue to show up as size S (Synthetic Node size) in Deployment Status and will be subject to the execution limits of size S.
Sizing guide
Based on the number of tests executed per hour, Synthetic-enabled ActiveGates need to meet the following hardware requirements.
Limit values
The estimated limits listed in the table below were determined in our internal tests. The actual values might vary depending on the complexity of your monitors.
XS node
While XS nodes can be used on Windows Server-based ActiveGates, they may not be the best fit due to the higher hardware demands of Chromium. For optimal performance and to prepare for future enhancements, we recommend having at least 8 GB of RAM and 25 GB of free disk space.
On Linux systems with only 4 GB of RAM, the increasing resource requirements of Chrome (or Chromium), combined with the installation of third-party tools on the host, may lead to occasional memory shortages. Upgrading to 8 GB of RAM is strongly recommended to help ensure a smoother and more reliable experience.
Node with browser monitor support
Browserless node
Minimum CPUs
2 vCPU
1 vCPU
Minimum free disk space
20 GB
17 GB
Minimum RAM
4 GB
4 GB
Minimum free RAM
3 GB
2,7 GB
Minimum disk IOPS (Windows)
100
100
Estimated maximum number of HTTP monitor executions/h1
300k
300k
Estimated maximum number of high-resource HTTP monitor2 executions/h
10k
10k
Estimated maximum number of browser monitor executions/h
300
-
Estimated maximum number of NAM ICMP monitor packets/h35
500k
500k
Estimated maximum number of NAM TCP monitor requests/h46
1M
1M
Estimated maximum number of NAM DNS monitor request/h47
100k
100k
Footnotes
1
Calculated as 5000 monitor executions (maximum for a single environment) run once every minute (maximum frequency).
2
These are HTTP monitors on private locations with any of: pre- or post-execution scripts, OAuth2 authorization, Kerberos authentication.
3
For NAM monitors using ICMP request type, capacity is related to number of ICMP echo requests (packets) that are being sent during monitors execution. As this number of packets-to-be-sent may significantly vary among defined monitors, using the number of monitor executions as a capacity limit would be inaccurate.
4
For NAM monitors using TCP and DNS request types, capacity is related to the number of network connections (requests) that are being sent during monitors execution. As this number of requests may significantly vary among defined monitors, using the number of monitor executions as a capacity limit would be inaccurate.
5
During load tests that helped to establish capacity limits, NAM ICMP monitors were exclusively scheduled on location; monitors had the following characteristic. Actual capacity may be different for other environments (for example, those where monitored targets respond slower or are failing to provide a response within timeout limit or other type of monitors are executed at the same time).
Monitors were using default settings (including default timeouts settings and single packet per-request) and were scheduled every 1 minute.
There were multiple target hosts used during tests; all of them were responding properly with average RTT around 200ms.
6
During load tests that helped to establish capacity limits, NAM TCP monitors were exclusively scheduled on location; monitors had the following characteristic. Actual capacity may be different for other environments (for example, those where monitored targets respond slower or are failing to provide a response within timeout limit or other type of monitors are executed at the same time).
Monitors were using default settings (including default timeouts settings) and were scheduled every 1 minute.
There were multiple target hosts and ports used during tests; all of them were responding properly with average TCP connection time around 200ms.
7
During load tests that helped to establish capacity limits, NAM DNS monitors were exclusively scheduled on location; monitors had the following characteristic. Actual capacity may be different for other environments (for example, those where monitored targets respond slower or are failing to provide a response within timeout limit or other type of monitors are executed at the same time). Please note that DNS server used during resolution should be able to handle incoming requests and may not consider the incoming traffic as a subject to throttling or rejection (for example, due to detection as bot-originated).
Monitors were using default settings (including default timeouts settings and UDP as a transport) and were scheduled every 1 minute.
There were multiple resolution targets used during tests; all of them were resolved properly with average DNS resolution time around 10ms.
Publicly available DNS servers were used: Google (8.8.8.8 and 8.8.4.4) and Cloudflare (1.1.1.1 and 1.1.1.2)
Node with browser monitor support
Browserless node
Minimum CPUs
4 vCPU
2 vCPU
Minimum free disk space
25 GB
22 GB
Minimum RAM
8 GB
8 GB
Minimum free RAM
5 GB
4 GB
Minimum disk IOPS (Windows)
200
200
Estimated maximum number of HTTP monitor executions/h1
300k
300k
Estimated maximum number of high-resource HTTP monitor2 executions/h
20k
20k
Estimated maximum number of browser monitor executions/h
650
-
Estimated maximum number of NAM ICMP monitor packets/h35
1M
1M
Estimated maximum number of NAM TCP monitor requests/h46
2M
2M
Estimated maximum number of NAM DNS monitor request/h47
200k
200k
Footnotes
1
Calculated as 5000 monitor executions (maximum for a single environment) run once every minute (maximum frequency).
2
These are HTTP monitors on private locations with any of: pre- or post-execution scripts, OAuth2 authorization, Kerberos authentication.
3
For NAM monitors using ICMP request type, capacity is related to number of ICMP echo requests (packets) that are being sent during monitors execution. As this number of packets-to-be-sent may significantly vary among defined monitors, using the number of monitor executions as a capacity limit would be inaccurate.
4
For NAM monitors using TCP and DNS request types, capacity is related to the number of network connections (requests) that are being sent during monitors execution. As this number of requests may significantly vary among defined monitors, using the number of monitor executions as a capacity limit would be inaccurate.
5
During load tests that helped to establish capacity limits, NAM ICMP monitors were exclusively scheduled on location; monitors had the following characteristic. Actual capacity may be different for other environments (for example, those where monitored targets respond slower or are failing to provide a response within timeout limit or other type of monitors are executed at the same time).
Monitors were using default settings (including default timeouts settings and single packet per-request) and were scheduled every 1 minute.
There were multiple target hosts used during tests; all of them were responding properly with average RTT around 200ms.
6
During load tests that helped to establish capacity limits, NAM TCP monitors were exclusively scheduled on location; monitors had the following characteristic. Actual capacity may be different for other environments (for example, those where monitored targets respond slower or are failing to provide a response within timeout limit or other type of monitors are executed at the same time).
Monitors were using default settings (including default timeouts settings) and were scheduled every 1 minute.
There were multiple target hosts and ports used during tests; all of them were responding properly with average TCP connection time around 200ms.
7
During load tests that helped to establish capacity limits, NAM DNS monitors were exclusively scheduled on location; monitors had the following characteristic. Actual capacity may be different for other environments (for example, those where monitored targets respond slower or are failing to provide a response within timeout limit or other type of monitors are executed at the same time). Please note that DNS server used during resolution should be able to handle incoming requests and may not consider the incoming traffic as a subject to throttling or rejection (for example, due to detection as bot-originated).
Monitors were using default settings (including default timeouts settings and UDP as a transport) and were scheduled every 1 minute.
There were multiple resolution targets used during tests; all of them were resolved properly with average DNS resolution time around 10ms.
Publicly available DNS servers were used: Google (8.8.8.8 and 8.8.4.4) and Cloudflare (1.1.1.1 and 1.1.1.2)
Node with browser monitor support
Browserless node
Minimum CPUs
8 vCPU
4 vCPU
Minimum free disk space
30 GB
23 GB
Minimum RAM
16 GB
16 GB
Minimum free RAM
8 GB
6,5 GB
Minimum disk IOPS (Windows)
400
400
Estimated maximum number of HTTP monitor executions/h1
300k
300k
Estimated maximum number of high-resource HTTP monitor2 executions/h
60k
60k
Estimated maximum number of browser monitor executions/h
1200
-
Estimated maximum number of NAM ICMP monitor packets/h35
1.5M
1.5M
Estimated maximum number of NAM TCP monitor requests/h46
3M
3M
Estimated maximum number of NAM DNS monitor request/h47
300k
300k
Footnotes
1
Calculated as 5000 monitor executions (maximum for a single environment) run once every minute (maximum frequency).
2
These are HTTP monitors on private locations with any of: pre- or post-execution scripts, OAuth2 authorization, Kerberos authentication.
3
For NAM monitors using ICMP request type, capacity is related to number of ICMP echo requests (packets) that are being sent during monitors execution. As this number of packets-to-be-sent may significantly vary among defined monitors, using the number of monitor executions as a capacity limit would be inaccurate.
4
For NAM monitors using TCP and DNS request types, capacity is related to the number of network connections (requests) that are being sent during monitors execution. As this number of requests may significantly vary among defined monitors, using the number of monitor executions as a capacity limit would be inaccurate.
5
During load tests that helped to establish capacity limits, NAM ICMP monitors were exclusively scheduled on location; monitors had the following characteristic. Actual capacity may be different for other environments (for example, those where monitored targets respond slower or are failing to provide a response within timeout limit or other type of monitors are executed at the same time).
Monitors were using default settings (including default timeouts settings and single packet per-request) and were scheduled every 1 minute.
There were multiple target hosts used during tests; all of them were responding properly with average RTT around 200ms.
6
During load tests that helped to establish capacity limits, NAM TCP monitors were exclusively scheduled on location; monitors had the following characteristic. Actual capacity may be different for other environments (for example, those where monitored targets respond slower or are failing to provide a response within timeout limit or other type of monitors are executed at the same time).
Monitors were using default settings (including default timeouts settings) and were scheduled every 1 minute.
There were multiple target hosts and ports used during tests; all of them were responding properly with average TCP connection time around 200ms.
7
During load tests that helped to establish capacity limits, NAM DNS monitors were exclusively scheduled on location; monitors had the following characteristic. Actual capacity may be different for other environments (for example, those where monitored targets respond slower or are failing to provide a response within timeout limit or other type of monitors are executed at the same time). Please note that DNS server used during resolution should be able to handle incoming requests and may not consider the incoming traffic as a subject to throttling or rejection (for example, due to detection as bot-originated).
Monitors were using default settings (including default timeouts settings and UDP as a transport) and were scheduled every 1 minute.
There were multiple resolution targets used during tests; all of them were resolved properly with average DNS resolution time around 10ms.
Publicly available DNS servers were used: Google (8.8.8.8 and 8.8.4.4) and Cloudflare (1.1.1.1 and 1.1.1.2)
Node with browser monitor support
Browserless node
Minimum CPUs
16 vCPU
8 vCPU
Minimum free disk space
40 GB
25 GB
Minimum RAM
32 GB
32 GB
Minimum free RAM
12 GB
10 GB
Minimum disk IOPS (Windows)
750
750
Estimated maximum number of HTTP monitor executions/h1
300k
300k
Estimated maximum number of high-resource HTTP monitor2 executions/h
100k
100k
Estimated maximum number of browser monitor executions/h
2200
-
Estimated maximum number of NAM ICMP monitor packets/h35
2M
2M
Estimated maximum number of NAM TCP monitor requests/h46
4M
4M
Estimated maximum number of NAM DNS monitor request/h47
400k
400k
Footnotes
1
Calculated as 5000 monitor executions (maximum for a single environment) run once every minute (maximum frequency).
2
These are HTTP monitors on private locations with any of: pre- or post-execution scripts, OAuth2 authorization, Kerberos authentication.
3
For NAM monitors using ICMP request type, capacity is related to number of ICMP echo requests (packets) that are being sent during monitors execution. As this number of packets-to-be-sent may significantly vary among defined monitors, using the number of monitor executions as a capacity limit would be inaccurate.
4
For NAM monitors using TCP and DNS request types, capacity is related to the number of network connections (requests) that are being sent during monitors execution. As this number of requests may significantly vary among defined monitors, using the number of monitor executions as a capacity limit would be inaccurate.
5
During load tests that helped to establish capacity limits, NAM ICMP monitors were exclusively scheduled on location; monitors had the following characteristic. Actual capacity may be different for other environments (for example, those where monitored targets respond slower or are failing to provide a response within timeout limit or other type of monitors are executed at the same time).
Monitors were using default settings (including default timeouts settings and single packet per-request) and were scheduled every 1 minute.
There were multiple target hosts used during tests; all of them were responding properly with average RTT around 200ms.
6
During load tests that helped to establish capacity limits, NAM TCP monitors were exclusively scheduled on location; monitors had the following characteristic. Actual capacity may be different for other environments (for example, those where monitored targets respond slower or are failing to provide a response within timeout limit or other type of monitors are executed at the same time).
Monitors were using default settings (including default timeouts settings) and were scheduled every 1 minute.
There were multiple target hosts and ports used during tests; all of them were responding properly with average TCP connection time around 200ms.
7
During load tests that helped to establish capacity limits, NAM DNS monitors were exclusively scheduled on location; monitors had the following characteristic. Actual capacity may be different for other environments (for example, those where monitored targets respond slower or are failing to provide a response within timeout limit or other type of monitors are executed at the same time). Please note that DNS server used during resolution should be able to handle incoming requests and may not consider the incoming traffic as a subject to throttling or rejection (for example, due to detection as bot-originated).
Monitors were using default settings (including default timeouts settings and UDP as a transport) and were scheduled every 1 minute.
There were multiple resolution targets used during tests; all of them were resolved properly with average DNS resolution time around 10ms.
Publicly available DNS servers were used: Google (8.8.8.8 and 8.8.4.4) and Cloudflare (1.1.1.1 and 1.1.1.2)
Storage and file system permissions
The table below shows the default installation locations (Linux and Windows) of various ActiveGate directories and the minimum size requirements. This information is compiled from details in ActiveGate directories.
Installation parameter
Default path
Min. size
Notes
<INSTALL>
/opt/dynatrace/
%PROGRAMFILES%\dynatrace
600 MB
For executable files, libraries, and related files
1 GB for ActiveGate temporary files (without cached OneAgent installers and container images)
20 GB for Private Synthetic temporary files (including execution logs, cache, and screenshots)
1
For an XS ActiveGate—more space is required for execution logs on larger ActiveGates.
Permissions for /tmp
Synthetic-enabled ActiveGate requires write access to the /tmp directory during runtime. Its dependencies, including xvfb, utilize /tmp for storing temporary files and runtime data.
Lack of write permissions to this directory may result in unexpected failures or degraded functionality.
Ensure that the host environment provides sufficient access rights and available space in /tmp to support these operations reliably.