Private synthetic locations

  • Latest Dynatrace
  • How-to guide
  • Published May 28, 2025

The goal of private locations is to execute synthetic monitors. You need to use private locations to monitor applications and endpoints within corporate networks, which are unavailable from the public internet. Also, private locations are obligatory for executing NAM monitors.

With monitors executed from a private location, you can bring the testing capabilities available in public locations right into your own environment. With private locations you can:

  • Measure internal webpage performance and availability.
  • Measure complex internal applications with browser clickpaths.
  • Measure external resources with synthetic monitors run from internal locations.
  • Monitor APIs, both internal and external.

You can create only classic locations using Synthetic Classic Synthetic, although the locations list displays classic and containerized (for example, Kubernetes and OpenShift) locations. If you still need to create a containerized location, you can do it in Settings Classic.

The Private locations tab in Synthetic Classic Synthetic shows the list of all private locations available within a given environment. For each private location, there's information about how many synthetic monitors are assigned to it, with links to those monitors.

If you created a private location in previous Dynatrace, it remains available in latest Dynatrace—there's no need to redeploy it.

System and hardware requirements for private locations

Make sure the target host you plan to use for running synthetic monitors complies with system and hardware requirements for private Synthetic locations. Note that Synthetic-enabled ActiveGates have more demanding hardware and system requirements than a regular Environment or Cluster ActiveGate.

Synthetic-enabled ActiveGate installed on Ubuntu 20.04 LTS and 22.04 LTS only You can use TEMP to customize the default temporary directory for private Synthetic files—/var/tmp/dynatrace/synthetic. However, the path must begin with /var/tmp, for example, TEMP=/var/tmp/syn. Dynatrace requires write access to /var/tmp for the installation of Chromium snap packages.

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.

To ensure the continuity and security of your synthetic monitors, we recommend migrating your Synthetic-enabled ActiveGate to one of the supported operating systems, for example Red Hat/Oracle Linux/Rocky Linux 9.

We plan to have ActiveGate version 1.325 as 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.

Additional support notes
  • 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.
  • Check the latest ActiveGate release notes for the oldest supported ActiveGate versions.

Before you begin

  • You cannot execute synthetic monitors using an Environment ActiveGate configured for multi-environment support.
  • You can create a private location using a clean-installed Synthetic-enabled Environment ActiveGate version 1.169+ or Cluster ActiveGate with Dynatrace Managed version 1.176+. If you want to use an existing ActiveGate host, uninstall ActiveGate first.
  • Synthetic-enabled ActiveGate is used exclusively to run synthetic monitors. A clean ActiveGate installation for the purpose of synthetic monitoring disables all other ActiveGate features, including communication with OneAgents.
  • Only IPv4 and DNS UDP are supported for network configuration.
  • Both manual and automatic Chromium updates require access to https://synthetic-packages.s3.amazonaws.com. For security reasons, public access to the S3 bucket is enabled only for specific files; trying anything else will result in a 403 error.

Create a private location

To add a classic private location

  1. Go to the Private locations tab in the upper-left corner of the Synthetic Classic Synthetic home page.

  2. Select New private locations > Classic.

  3. Name your location.

  4. Map it from an existing geographic location or add a custom location defined by Country, Region, City, Latitude, and Longitude.

  5. Select Existing ActiveGate to add an existing Synthetic-enabled Activegate to the location or Deploy new ActiveGate to deploy a new one (deploying a new ActiveGate will redirect you to Discovery & Coverage Discovery & Coverage from where you can install an ActiveGate).

    Add multiple ActiveGates if you plan to run a large number of synthetic monitors. Additional ActiveGates are used for failover and load balancing.

    • We recommend using at least two ActiveGates for a location.
    • You can't use one ActiveGate for multiple locations.

  1. optional Turn on Enable Chromium auto-update—it will be triggered during the Synthetic engine updates at this location.

    You can Enable Chromium auto-update at the location level, that is, for all ActiveGates assigned to a private location. Chromium autoupdate takes place during manual as well as automatic ActiveGate and Synthetic engine updates.

    As we recommend using the latest supported Chromium version for the smooth and secure execution of browser monitors from your private location, Chromium autoupdate is turned on by default for locations with Linux-based ActiveGates. If you don't want Chromium to be updated automatically, for example, to use a specific version of Chromium, or if you have offline environments, turn off the switch before triggering an ActiveGate update.

    This setting only applies to Linux-based ActiveGates; on Windows-based ActiveGates, Chromium is always updated during Synthetic engine updates. If your location has only Windows-based ActiveGates, the toggle is turned on but grayed out.

    Successful Chromium autoupdate requires access to OS (system) repositories for Chromium dependencies and access to https://synthetic-packages.s3.amazonaws.com for Chromium components. If you've enabled a custom local repository, Chromium components (but not dependencies) need to be available at the specified HTTP server address. See Chromium autoupdate from a custom repository.

    You will see a message if Chromium autoupdate fails for this or other reasons—we recommend either meeting the requirements for autoupdate (such as access to repositories) or disabling Chromium autoupdate for your private location.

    Also, check our information on installing Chromium and other dependencies manually (Linux only).

  2. optional If you have outage issues with your private location, use the Location outage handling options to receive related notifications. See the on-screen instructions for details.

    • You can configure the location to generate a problem when the entire private location is unavailable (all ActiveGates are offline), or if the location lacks the capability required for the monitor type to be executed.

    • You can configure the location to generate a problem when a single ActiveGate at this location is offline.

    For example, suppose your location has two ActiveGates, and you enable both problem switches. You will see three problems when your location is unavailable—one for the entire location and one for each ActiveGate that's offline.

    Containerized locations

    For containerized locations, you can only generate a problem when the entire private location is unavailable (all ActiveGates are offline), or if the location lacks the capability required for the monitor type to be executed.

  3. Select Save.

Additional deployment modes

Additional deployment modes available to you

  • Browserless
  • Kerberos
  • FIPS compliant

Browserless Synthetic-enabled ActiveGate

In general, we recommend the deployment of Synthetic-enabled ActiveGate to support the execution of all types synthetic monitors (HTTP, browser, NAM).

If you don't need to execute browser monitors, however, you might want to consider deploying your node in a special browserless mode. Such a node will be deployed without the browser. The resulting deployment requires less hardware resources, but browser monitors cannot be executed from such a node.

Consider browserless nodes as an alternative to nodes with browser monitor support when you're focused purely on:

  • Network and infrastructure use cases (using NAM monitors)
  • API monitoring (using HTTP monitors)

Kerberos client setup

If you want to run browser monitors using Kerberos authentication, the private location should be configured to be able to get ticket from the Kerberos Key Distribution Center.

  1. Each Windows machine using Kerberos has to be properly configured with Active Directory.
  2. If you are unable to authenticate with Kerberos on Windows, use the following command to register the machine.
ksetup /addkdc DOMAIN.TO.ADD address.of.kerberos.server

The DOMAIN.TO.ADD is your domain name and address.of.kerberos.server is the Kerberos Key Distribution Center (Active Directory Controller if you're using a Microsoft solution). Note that in the credentials used, the domain name must be in uppercase (for example, user@EXAMPLE.COM).

Synthetic FIPS compliance

ActiveGate version 1.315+

Installation

To install Synthetic-enabled ActiveGate in FIPS compliant mode, you need to add the --fips-mode flag. See also customize ActiveGate installation for FIPS compliance.

/bin/bash ./Dynatrace-ActiveGate-Linux.sh --enable-synthetic --fips-mode

Please note that FIPS-compliant mode cannot be changed after installation. To change the mode, you need to uninstall ActiveGate and reinstall it with the desired settings. Additionally, if you intend to execute browser monitors, additional setup will be required as described in Proxy configuration for FIPS mode and Proxy configuration for FIPS mode with corporate proxy.

Requirements and limitations

  • We require operating system with FIPS-compliant mode enabled, see also ActiveGate FIPS compliance.
  • Following operating systems are currently supported:
    • Ubuntu Pro 22.04
    • Red Hat Enterprise Linux 9
  • Private Synthetic locations on Kubernetes are not supported at the moment.

Ensuring compliance

To ensure the browser monitor traffic is FIPS compliant, it must be routed through a local intercepting proxy that encrypts traffic with a FIPS-certified crypto library. See Proxy configuration for FIPS mode for details.

For HTTP monitors, we use the Amazon Corretto Crypto Provider FIPS-certified cryptographic library that uses AWS-LC-FIPS 2.x as its cryptographic module. See Certificate #4816.

Synthetic-enabled ActiveGate in FIPS compliant mode supports the same set of cipher suites as regular ActiveGate.

Frequently asked questions

Each tgz package archive is stored in the S3 bucket together with the *.tgz.sig signature file. To verify that the packages on your drive are authentic Dynatrace-provided archives:

  1. Download the signature file. The filename is identical to the package archive but has the sig filename extension. For example, for Chromium 78, the command is:

    curl --output chromium.tgz.sig https://synthetic-packages.s3.amazonaws.com/Chromium/rpm/chromium-78.0.3904.97-1.el7.tgz.sig

  2. Verify the package:

    wget https://ca.dynatrace.com/dt-root.cert.pem ; openssl cms
    -verify
    -in chromium.tgz.sig
    -inform PEM
    -content chromium.tgz
    -binary
    -CAfile dt-root.cert.pem > /dev/null

  3. Verify the signature timestamp.

    You can also get the exact timestamp of a signature. Download the *.tgz.sig.tsr file from the same location as the installation packages and signature, and then run the following command:

    openssl ts -reply -in chromium.tgz.sig.tsr -text

With ActiveGate version 1.175+, an ActiveGate executing synthetic monitors can connect through the proxy to both the Dynatrace Cluster and the tested resource. For more information, see Setting up proxy for private synthetic monitoring.

No, you need to run a clean installation specifically for the purpose of synthetic monitoring to enable your ActiveGate to execute monitors from private locations.

Private Synthetic locations require a clean installation of ActiveGate specifically for the purpose of synthetic monitoring.

Manually editing the custom.properties file is not enough to enable the ActiveGate to execute synthetic monitors.

Troubleshoot

Can't see screenshots in browser monitor results

Visit the Troubleshooting forum in the Dynatrace Community for more troubleshooting information.

Related tags
Digital Experience