With Dynatrace Managed, every metric, every distributed trace, every user session and every log line ends up on disks that you buy, mount and monitor yourself. Where a hosted service hides the storage question completely, Dynatrace Managed data retention forces the administrator to keep balancing history depth, query performance and infrastructure cost.
The symptoms of poorly controlled retention are well known: a /var/opt/dynatrace-managed volume approaching 90%, storage alerts in the Cluster Management Console, traces vanishing earlier than expected because the cluster had to purge to survive, or, conversely, terabytes paid for to keep data nobody looks at.
This article explains how Managed spreads data across its various stores, how to configure retention per environment, and how to size and monitor storage to avoid unpleasant surprises.
Where your data lives in a Managed cluster
A Managed node is not a single database: several engines sit side by side, each with its own growth profile.
| Store | Main content | Growth profile |
|---|---|---|
| Cassandra | Metric time series (hosts, services, custom metrics) | Proportional to the number of entities and dimensions |
| Elasticsearch | User sessions, RUM actions, events, log events (Log Monitoring) | Proportional to web and mobile application traffic |
| Transaction storage | Distributed traces (PurePath), detailed requests | Very sensitive to request volume and capture depth |
| Session Replay (dedicated store, server/replayData) | Session Replay recordings, if the feature is enabled | Variable, often underestimated |
| Backups (NFS) | Configuration, metrics and user sessions (transaction storage is not backed up) | Proportional to the stores being backed up |
By default, everything lives under /var/opt/dynatrace-managed, but the installer lets you place each store on a separate mount point. Ideally, make this decision at installation time: moving a store afterwards is possible but requires a careful procedure.
Understanding Dynatrace Managed data retention
Retention by data type
In the CMC, each environment has its own storage settings: the volume reserved for transaction storage, then separate retention periods for service request level, code level (code-level visibility), Real User Monitoring, Synthetic, Session Replay and logs. As a reference point, the official sizing tables assume 10 days of code-level visibility and 35 days of Elasticsearch retention. Metrics are progressively aggregated and kept much longer at low resolution. Defaults and maximums depend on your version: check the documentation.
Metric aggregation
Metrics are not stored at one-minute resolution forever: they are aggregated into coarser resolutions over time. Keeping two years of metrics therefore costs far less than keeping two years of traces.
The disk space safeguard
When disk space runs short, the cluster raises an « Insufficient disk space » event; if transaction storage is affected, adaptive data retention truncates data and shortens the effective period on its own. In other words, configured retention is a maximum, not a guarantee: if you notice « gaps » in trace history, look at disk usage first.
Step-by-step tutorial
Step 1 — Measure current usage
On each node, measure the space used per store:
df -h /var/opt/dynatrace-managed
sudo du -sh /var/opt/dynatrace-managed/* 2>/dev/null | sort -h
If you have split the stores across several mount points, repeat the command for each one. Record the values in a table: they will serve as your baseline.
Step 2 — Check the CMC storage view
In the Cluster Management Console, each node’s details page shows disk usage and any warnings. Spot the fastest-growing store: it is usually transaction storage or Elasticsearch.
Step 3 — Identify the hungry environments
On a multi-environment cluster, a single environment can consume most of the space. In the CMC, compare data volume and host count per environment. You can also query an environment’s API to track the number of monitored entities:
curl -s -H "Authorization: Api-Token {token}" \
"https://{your-domain}/e/{environment-id}/api/v2/entities?entitySelector=type(%22HOST%22)&pageSize=1" \
| python3 -m json.tool | grep totalCount
Step 4 — Adjust retention per environment
In the CMC, open the settings of the environment concerned, in the data retention section. Adjust the periods per category to your real needs:
- Critical production: traces kept for the maximum allowed, to make post-incident analysis easier.
- Staging / development: short retention; a few days is often enough.
- User sessions: align the period with your GDPR obligations and privacy policy.
New values apply gradually: space is not freed instantly.
Step 5 — Reduce volume at the source
Before adding disks, cut down what is collected without value:
- Put development hosts in infrastructure only mode (
--set-monitoring-mode=infra-onlyat installation or viaoneagentctl). - Exclude health-check requests and technical URLs from capture.
- Review high-cardinality custom metrics (dimensions such as a request ID).
- Limit Session Replay to applications where it is genuinely useful.
sudo /opt/dynatrace/oneagent/agent/tools/oneagentctl --set-monitoring-mode=infra-only --restart-service
Step 6 — Extend storage cleanly
If the need is real, there are two options: grow the existing volumes (LVM, virtual disk) or add a node to the cluster, which also spreads the compute load. For a standard LVM extension:
sudo lvextend -L +{size}G /dev/{vg}/{lv-dynatrace}
sudo xfs_growfs /var/opt/dynatrace-managed # or resize2fs for ext4
df -h /var/opt/dynatrace-managed
Do this node by node and keep the same partition size on every node. For the metrics store (Cassandra, three copies in multi-node clusters), the documentation recommends staying below 2 TB per node: beyond that, adding a node is better than growing disks.
Step 7 — Monitor over time
Monitor the cluster nodes themselves (for example with a OneAgent attached to an environment dedicated to operations) and create an alert on disk usage of the Dynatrace volumes, with a warning threshold around 75% and a critical one around 85% — adapt as needed.
Best practices
- Separate the stores onto distinct volumes from installation onwards, to isolate growth and make diagnosis easier.
- Fast disks (SSD/NVMe) for Cassandra and transaction storage: disk latency is felt directly in the interface.
- Differentiated retention per environment: production deserves history, staging rarely does.
- Plan for backup: the backup NFS share must keep pace with the growth of the stores being backed up (metrics, Elasticsearch, configuration); transaction storage is not backed up.
- Quarterly review: growth curve, heaviest-consuming environments, six-month projection.
Frequently asked questions
Why do traces disappear before the configured retention ends?
When a store nears capacity, the cluster can reduce effective retention on its own to protect the service. The configured period is a maximum: check disk usage first.
Why is keeping metrics for a long time cheaper than keeping traces?
Metrics are aggregated into coarser resolutions over time, whereas distributed traces keep their detail. Two years of metrics therefore weigh far less than two years of traces.
Should I add disks or a node?
Start by cutting collection that brings no value. If the need is still real, grow the volumes node by node to keep capacity uniform, or add a node, which also spreads the compute load.
Conclusion
In Managed, retention is not just a setting: it is a contract between what you want to analyse and what your disks can hold. By knowing the stores, measuring their growth regularly, adjusting retention per environment and cutting unnecessary collection, you guarantee reliable history without oversizing the infrastructure — and you stop the cluster from making those trade-offs for you.
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) against the official documentation for your Managed version.
Originally published on span.observer. French version: https://span.observer/fr/retention-stockage-donnees/.
Top comments (0)