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.

Edit a private location

To edit an existing private location

  1. Go to the Private locations tab to open the Private Synthetic locations home page.
  2. Select the location name to display the panel on the right.
  3. In the displayed panel, edit the settings.
Containerized locations

The containerized locations are available only in view mode in the latest Dynatrace. Select Settings Classic to go to the previous Dynatrace and edit the location there.

See private location details

Select a location to see its details. The ActiveGates assigned to the location are listed and displayed in red when a Synthetic engine or an ActiveGate itself is offline; the Status column shows a corresponding message. You can add or delete ActiveGates from here.

PrivateLocation_view

Metrics for the health status of each monitor type are available for charting and alerting. For example, choose the following metrics in the Notebooks:

  • Synthetic - HTTP - Engine Utilization
  • Synthetic - HTTP High Resource - Engine Utilization
  • Synthetic - Browser - Engine Utilization

We strongly recommend splitting these metrics by location to get an accurate view of location health.

Metric_for_private_location

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.

Proxy configuration for FIPS mode

When a Synthetic location is installed in FIPS mode, browser monitor traffic must be routed through a local intercepting proxy, so that all traffic leaving the host is encrypted with a crypto library that is FIPS-certified:

FIPS proxy

In this setup, we use the Squid proxy linked to the system's OpenSSL library, but you can use different proxy software as long as its crypto library is FIPS-certified.

  1. Install the proxy on the same host as the Synthetic engine:

    sudo dnf install squid

  2. Provide a CA certificate for re-signing intercepted requests:

    sudo mkdir /etc/squid/ssl_cert
    sudo mv ~/prepared_ca_cert.pem /etc/squid/ssl_cert/squid.pem
    sudo chown --recursive squid:squid /etc/squid/ssl_cert
    sudo chmod 700 /etc/squid/ssl_cert
    sudo chmod 600 /etc/squid/ssl_cert/squid.pem

    If SELinux is enabled, you might need to adjust file labels to avoid permission errors.

  3. Create a temporary certificate cache:

    sudo /usr/lib64/squid/security_file_certgen -c -s /var/spool/squid/ssl_db -M 4MB
    sudo chown --recursive squid:squid /var/spool/squid/ssl_db

  4. Configure the proxy to perform SSL interception (by default /etc/squid/squid.conf):

    acl SSL_ports port 443
    acl Safe_ports port 80 443 1025-65535
    acl CONNECT method CONNECT
    

    http_access deny !Safe_ports
    http_access deny CONNECT !SSL_ports
    http_access allow localhost
    http_access deny all
    http_port 3128 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/squid/ssl_cert/squid.pem
    

    acl step1 at_step SslBump1
    ssl_bump peek step1
    ssl_bump bump all
    cache deny all

  5. Restart the proxy for configuration to take effect:

    sudo systemctl enable squid
    sudo systemctl restart squid

  6. Verify that the proxy is working correctly:

    curl --proxy localhost:3128 https://example.com

  7. optional If you chose a different proxy port, you need to adjust the Synthetic configuration (by default /var/lib/dynatrace/synthetic/config/user.properties):

    com.vuc.fips.proxy.port=3128

Proxy configuration for FIPS mode with corporate proxy

If your organization mandates use of a corporate proxy, due to limitations of Squid you need to set up a second local Squid instance (this may not be needed if you are using a different proxy software):

FIPS proxy chain

  1. Configure the proxy for FIPS, as described in the previous section. Squid must be version 5 or later, so Red Hat 8 and Ubuntu 20 are not supported.

  2. On the same host, create a second squid service definition:

    /usr/lib/systemd/system/squid2.service

    [Unit]
    Description=Squid with upstream proxy
    After=network.target network-online.target nss-lookup.target
    

    [Service]
    Type=notify
    LimitNOFILE=16384
    PIDFile=/run/squid2.pid
    ExecStart=/usr/sbin/squid --foreground -n squid2 -f "/etc/squid/squid2.conf"
    ExecReload=/usr/bin/kill -HUP $MAINPID
    KillMode=mixed
    NotifyAccess=all
    

    [Install]
    WantedBy=multi-user.target

  3. Create a second proxy configuration (/etc/squid/squid2.conf), providing your corporate proxy host, port, and authentication:

    acl SSL_ports port 443
    acl Safe_ports port 80 443 1025-65535
    acl CONNECT method CONNECT
    

    http_access deny !Safe_ports
    http_access deny CONNECT !SSL_ports
    http_access allow localhost
    http_access deny all
    http_port 3129
    

    access_log daemon:/var/log/squid/access2.log squid
    cache_log /var/log/squid/cache2.log
    pid_filename /run/squid2.pid
    

    cache_peer upstream-proxy.example.com parent 443 0 default no-digest proxy-only login=proxyuser:proxypass tls tls-min-version=1.2 tls-options=NO_SSLv3
    never_direct allow all
    visible_hostname squid2
    cache deny all

  4. Update first proxy configuration (/etc/squid/squid.conf) to use the second proxy as a parent proxy by appending the following lines:

    cache_peer localhost parent 3129 0 default no-digest proxy-only
    never_direct allow all
    visible_hostname squid1

  5. Restart both squid services:

    sudo systemctl daemon-reload
    sudo systemctl enable squid2
    sudo systemctl start squid2
    sudo systemctl restart squid

  6. Verify that the proxy chain is working correctly:

    curl --proxy localhost:3128 https://example.com

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