When you inherit a Dynatrace Managed cluster, the first challenge is not reading the dashboards. It is understanding what actually runs on the servers: in other words, the Dynatrace Managed architecture. A disk incident, a Cassandra alert or a node that will not restart forces you to know which components live where, what data they store and which path OneAgent measurements take to get there.
This question is specific to Managed. In the hosted model, the vendor absorbs all of this complexity. With Managed, your team owns the operating system, the disks, the network, the backups and the update schedule. A good mental map of the architecture is therefore a prerequisite for running it with confidence.
This article describes the building blocks of a Managed cluster and how data flows between agents, ActiveGates and nodes, then walks through a short hands-on routine to inventory your own installation.
Dynatrace Managed architecture overview: a cluster, nodes and environments
A Managed cluster is a set of Linux servers, called nodes, that all run the same software stack. There is no fixed « master » role: every node receives traffic, processes data, stores part of it and serves the web UI. This symmetry makes adding capacity simple, but it requires all nodes to be sized identically.
On top of this foundation, the cluster hosts one or more environments (tenants). Each one is reachable at https://{your-domain}/e/{environment-id} and has its own entities, alerting rules, users and quotas. Cluster-wide administration (nodes, licences, backups, updates, environments) is done in the Cluster Management Console (CMC).
What runs on each node
A typical node runs several cooperating processes:
- The Dynatrace server: the core application (JVM) that receives agent data, correlates entities, runs causation analysis and exposes the UI and APIs.
- A front-end web proxy: it terminates HTTPS connections from browsers and agents, then distributes requests to the cluster’s servers.
- Cassandra: the distributed database for time series (metrics) and part of the configuration.
- Elasticsearch: the index for user-oriented data, notably RUM sessions and actions.
- Transaction storage: local files holding distributed traces (PurePaths) and their details.
By default, the binaries live in /opt/dynatrace-managed and the data in /var/opt/dynatrace-managed. It is common, and recommended, to put the different stores on dedicated volumes so that unexpected growth in one does not fill up the others.
Storage types and how they behave
| Store | Content | Replication | Watch out for |
|---|---|---|---|
| Cassandra | Metrics, timeseries data | Replicated across nodes (factor 3 is typical from 3 nodes) | Sensitive to disk and network latency |
| Elasticsearch | User sessions, actions, RUM data | Replicated across nodes | Growth tied to session volume |
| Transactions | Distributed traces, request details | Distributed, usually not replicated | Losing a node loses part of the recent traces |
| Backups | Copies of Cassandra, Elasticsearch, configuration | On shared storage (NFS) | Must be mounted at the same path on every node |
The practical consequence matters: high availability for metrics and configuration relies on replication, and therefore on having enough nodes. A single-node cluster works, but it offers no fault tolerance. In a multi-node cluster the metrics store is kept in three copies, while transaction storage is simply distributed, without redundancy: the documentation requires at least three nodes in production.
End-to-end data flow
- Collection: the OneAgent installed on a host instruments processes, services and infrastructure.
- Transport: the agent sends its data over HTTPS either directly to the cluster nodes or to an ActiveGate, which concentrates, compresses and forwards it.
- Reception: a node’s front-end proxy accepts the connection and passes it to the Dynatrace server.
- Processing: the server correlates the data with the entity model (topology), computes baselines and detects anomalies.
- Persistence: metrics go to Cassandra, sessions to Elasticsearch, traces to transaction storage.
- Consumption: the web UI, the environment API (
…/e/{id}/api/v2/…) and integrations use this data.
Agents receive the list of available endpoints and fail over automatically if a node or an ActiveGate becomes unavailable. That is why you should avoid hard-coding a single node in network configurations.
Network flows you need to know
- Agents and ActiveGates to the cluster: HTTPS on port 443 (redirected locally to 8022 by an iptables rule). Port 8443 also receives OneAgent data and carries node-to-node traffic; it no longer needs to be exposed outside the cluster, except on clusters older than version 1.166 or upgraded from them.
- Between nodes: a set of ports for Hazelcast (5701–5711), Cassandra (7000, 7001, 9042), Elasticsearch (9200, 9300) and server-to-server communication. These ports must be open between all nodes, and only between them.
- Cluster to Mission Control: outbound HTTPS for licensing, updates and support, except in offline mode where these operations are manual.
- Nodes to NFS: for backups.
Step-by-step tutorial: inventory your cluster
Here is a simple routine to check, on an existing cluster, that reality matches the picture above.
Step 1 — List the nodes in the CMC
Log in to the CMC and open the nodes overview page. For each node, note its IP address, status, version and the disk usage shown. Check that all versions are identical.
Step 2 — Identify the services on a node
On each server, as root:
systemctl list-units --type=service | grep -i dynatrace
ps -eo pid,user,rss,cmd --sort=-rss | grep -i -E "dynatrace|cassandra|elasticsearch" | head -20
You should see the server, Cassandra, Elasticsearch and front-end proxy processes.
Step 3 — Map the storage volumes
df -h /opt/dynatrace-managed /var/opt/dynatrace-managed
du -sh /var/opt/dynatrace-managed/* 2>/dev/null | sort -h
findmnt -t nfs,nfs4
These commands show where the data actually lives, which directory grows fastest and whether the backup share is properly mounted.
Step 4 — Check the listening ports
ss -tlnp | grep -E ":443|:8443|:9042|:9200|:9300"
Compare the output with the port matrix in the documentation for your version, and review the firewall rules between nodes.
Step 5 — Query the Cluster API
Create a Cluster API token with the Service Provider API permission in the CMC, then list the environments:
curl -s -H "Authorization: Api-Token {token}" \
"https://{your-domain}/api/cluster/v2/environments" | python3 -m json.tool
This output becomes your reference for documenting which tenants live on the cluster.
Step 6 — Check the logs
journalctl -u "dynatrace*" --since "1 hour ago" --no-pager | tail -50
ls -lh /var/opt/dynatrace-managed/log/ 2>/dev/null
The exact location of application logs can vary with the version and installation choices.
Best practices
- Aim for at least three nodes in production to benefit from data replication.
- Keep nodes strictly identical (CPU, RAM, disks): the weakest one sets the cluster’s performance.
- Split the stores across separate volumes and monitor how full each one is independently.
- Place nodes on the same low-latency network; for multiple sites, look at Premium High Availability.
- Use ActiveGates to concentrate traffic from remote network zones rather than opening the cluster everywhere (see Environment ActiveGate or Cluster ActiveGate).
- Document the flow matrix and version it alongside your firewall configuration.
Frequently asked questions
Is a single-node Managed cluster enough?
It works, but it offers no fault tolerance: Cassandra and Elasticsearch replication requires several nodes. In production, aim for at least three identical nodes.
Where is the data stored on a node?
By default under /var/opt/dynatrace-managed: metrics in Cassandra, RUM sessions and actions in Elasticsearch, distributed traces in local transaction storage. Backups go to an NFS share mounted at the same path on every node (see backing up and restoring a cluster).
Should OneAgents be pointed at a specific node?
No. Agents receive the list of available endpoints and fail over automatically if a node or an ActiveGate becomes unavailable. Hard-coding a single node in the network configuration throws that benefit away.
Conclusion
A Managed cluster is a complete distributed system: an application server, a proxy, two distributed databases, local trace storage and a shared backup mechanism. Knowing what stores what and where the data travels helps you anticipate incidents, size correctly and talk to support effectively. The next articles in this series build on this map to cover sizing, installation and cluster expansion. To practise on a test cluster, follow module 2 of the course on the Dynatrace Managed cluster, then keep it under watch with cluster health monitoring.
span.observer is an independent community blog, not affiliated with Dynatrace LLC. Dynatrace is a trademark of Dynatrace LLC. Always check values (ports, versions, sizes) in the official documentation for your version of Managed.
Originally published on span.observer. French version: https://span.observer/fr/architecture-dynatrace-managed/.
Top comments (0)