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 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
If you want your cluster to receive monitoring data from external OneAgents, or if you want to use our Digital Experience Monitoring (DEM) services, you need to expose the cluster to external networks and configure a public IP address. The DEM services include:
- Synthetic monitoring
- Agentless Real User Monitoring
- Mobile Real User Monitoring
- Real User Monitoring via browser extension
- Communication with the Dynatrace mobile app
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 similar to cluster nodes. The image below shows the relevant communication ports for each case.
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 Web UI domain. 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, production-ready installations with external hosts, applications, sessions, and synthetic monitoring, we recommend that you set up two load-balanced Cluster ActiveGates with the same domain name and certificate. For smaller, low-load installations you can use a single Cluster ActiveGate. Also, you might consider installing a separate Environment ActiveGate for each of your environments.
Because the Environment ActiveGate starts communication with the Cluster ActiveGate upon installation, the Cluster ActiveGate must be operational and available via the public IP address beforehand. As a result, if you plan to use the Environment ActiveGate, the deployment order is important:
Set up your Dynatrace Managed Cluster.
Set up your Cluster ActiveGate and make sure that it can connect to the Dynatrace Managed Cluster. Also, make sure that the Cluster ActiveGate has a public IP address and is accessible from outside your network.
Install your Environment ActiveGate and make sure that the Cluster ActiveGate public address is reachable (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|