Possible deployment scenarios for Dynatrace Managed are detailed below. Each illustration depicts the various components involved and the required communication ports between components. The direction of arrows in the diagrams indicates which component initiates the connection.
If you want your Dynatrace Managed Cluster to be accessible only internally, use a basic setup (Scenario 1 below). Implement a pure Dynatrace Managed setup (Scenario 2) if you want to enable Digital Experience Monitoring (DEM) services and communication from external sources. If you want to integrate Dynatrace Managed into existing IT infrastructure, follow Scenario 3.
For a collective diagram showing all the possible connections and ports, see Supported connectivity schemes for ActiveGates.
Scenario 1: Basic setup
Once you install Dynatrace Managed and set up one or more cluster nodes, you get the deployment scenario illustrated below.
Without further configuration (in the Dynatrace menu, go to Settings > Public endpoints) a cluster is only accessible internally and exposes ports
443for the REST API, OneAgent traffic, and Web UI access (Cluster Management Console and environment UI). By default, remote access to Mission Control is enabled. This enables Dynatrace to perform monitoring and health checks of your Dynatrace Managed clusters. Each communication channel is secured with TLS.
Scenario 2: Pure Dynatrace Managed setup
The deployment scenario shown below allows the Dynatrace Cluster to receive monitoring data from external sources, such as external OneAgents, external Environment ActiveGates, or Digital Experience Monitoring (DEM) services. In addition, to better support multiple local OneAgents, an Environment ActiveGate is also used.
The DEM services may include:
- Synthetic monitoring
- Agentless Real User Monitoring
- Mobile Real User Monitoring
- Real User Monitoring via browser extension
- Communication with the Dynatrace mobile app
To receive external traffic, you need to expose the Dynatrace Cluster to external networks and configure a public IP address. Exposing the cluster directly to external networks isn't recommended for security reasons. Therefore, we suggest using one or more Cluster ActiveGates as mediating proxies for pre-processing of OneAgent and DEM traffic. Cluster ActiveGates will be recognized by the Cluster and can be configured through the Cluster Management Console, similarly to cluster nodes.
The Cluster ActiveGate requires:
- A publicly available IP address
- A domain name with a valid SSL certificate, since external communication is only supported in a secure manner using HTTPS (port 443). This domain must be different from the domain of the Dynatrace web UI. You can choose to provide a domain and a SSL certificate on your own or let Dynatrace do this for you. Dynatrace can generate a domain and a valid SSL certificate on your behalf.
For high-load installations with many external hosts, applications, sessions, and synthetic monitors, we recommend that you set up multiple load-balanced Cluster ActiveGates with the same domain name and certificate.
The Environment ActiveGate that receives traffic from your local OneAgents will, by default, connect directly to the Dynatrace Cluster (unless custom network zones are used). However, a connection through the Cluster ActiveGate must be configured if the Dynatrace Cluster is not directly reachable—for example, if the Environment ActiveGate and the OneAgents are in a different network or data center than the Dynatrace Cluster.
In scenarios, where the Environment ActiveGate uses a Cluster ActiveGate to connect to the Dynatrace Cluster, the Environment ActiveGate starts communication with the Cluster ActiveGate upon installation. Therefore, the Cluster ActiveGate must be operational and available at that time, exposing a suitable (local or public) IP address.
To set up a Dynatrace Managed environment, follow these deployment steps in this order:
Set up your Dynatrace Managed Cluster.
Set up your Cluster ActiveGate(s) and make sure that they can connect to the Dynatrace Managed Cluster. Make sure that the Cluster ActiveGate is accessible from your other networks or from outside, as appropriate, and has a public IP address, if required.
Install your Environment ActiveGate(s). If an Environment ActiveGate resides in another network/data center, make sure that the Cluster ActiveGate's address is reachable. If the Environment ActiveGate it is an external network, a public IP address of the Cluster ActiveGate will have to be available (Management Console > Settings > Public endpoints : Cluster ActiveGate URL).
Note: Web UI traffic or cluster administration (through Cluster Management Console) should remain on-premises, within your network. The Web UI is accessed using HTTPS. As such, a TLS certificate is required. It is acceptable to use a self-signed certificate, but you will likely want Web UI traffic and cluster administration to be carried out in a secure manner as well. In such cases, you can provide a domain name and a valid SSL certificate, or these can be generated automatically by Dynatrace. By default, each cluster gets a subdomain of
*.dynatrace-managed.com with a valid certificate from Let’s Encrypt. Note also that Cluster ActiveGates don't support proxying of Web UI traffic.
Scenario 3: Integration with existing IT landscape
In a more complex scenario, you may want to embed Dynatrace Managed into an existing IT infrastructure with a number of appliances already in place. The image below shows a customer-provided load balancer in front of the Cluster ActiveGate domain and a customer-provided proxy for outbound communication to Mission Control.
Scenario 4: Globally distributed high availability with automatic recovery
Dynatrace enables you to set up a high availability deployment across distributed networks in a self-contained out-of-the-box solution that provides near-zero downtime and allows monitoring to continue without data loss in failover scenarios. This solution provides cost savings in terms of compute and storage allocations by eliminating the need for separate stand-by recovery hosts and the associated infrastructure to store and transfer backup data. For capacity planning, consider the nodes in the additional data center as redundant rather than expanded capacity and plan to balance both data centers equally. For more information about the concept behind the multi-data center in Dynatrace Managed deployments, see High availability for multi-data centers.
To deploy this scenario, you must have a separate Premium High Availability license.
Required configuration for each traffic case
The following table sums up the required configuration for each discrete traffic case, indicating with an
x whether a public IP is required, a valid SSL certificate, or both. Note that Real User Monitoring (RUM), agentless RUM, and mobile RUM normally relate to your users' traffic and browser activity, which take place outside your network. Theoretically, this traffic can also be considered as originating from inside your network, so these cases are also included in the following table.
|Traffic type||Public IP||Valid SSL certificate|
|Agentless RUM (on-premises)||x|
|Agentless RUM (external)||x||x|
|Mobile RUM (on-premises)||x|
|Mobile RUM (external)||x||x|
|Browser extension RUM (on-premises)||x|
|Browser extension RUM (external)||x||x|
Agentless Real User Monitoring, mobile-app monitoring, and synthetic monitors all use the same endpoint to transmit monitoring data to Dynatrace.