The different possible deployment scenarios for Dynatrace Managed are detailed below. Each illustration depicts the various involved components and the required communication ports between components. The direction of arrows in the diagrams indicates which component initiates communication.
If you want your 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.
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 (From the CMC menu, select Settings > Public endpoints) a cluster is only accessible internally and exposes ports
8443 for 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 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
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, applicationss, sessions, and synthetic monitoring, it's recommended that you set up two load-balanced Cluster ActiveGates with the same domain name and certificate. For smaller, low-load installations you can use only a single Cluster ActiveGate. Also, you might consider installing a separate Environment ActiveGate for each of your environments.
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.
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|