1. The principles #
One duration per data type.
Overview #
Each data type has its own retention period. In Grail, data is stored in buckets whose retention you set (in days); classic data has fixed durations or durations defined by the subscription.
| Data type | Default order of magnitude |
|---|---|
| Distributed traces (PurePath, spans) | About ten days |
| Logs and events (Grail default buckets) | About 35 days, adjustable per bucket |
| RUM user sessions | About 35 days |
| Metrics | Several months to several years, with resolution decreasing with age |
| Problems | Several months |
Good to know: Exact durations depend on your subscription and evolve with the platform: check them in the documentation and in your environment's storage settings.
2. Managing retention with buckets #
Adapting duration to usage.
Buckets #
You create dedicated buckets (for example audit logs kept for a year, debug logs kept for 7 days) and route data to them at ingestion with processing rules (OpenPipeline).
| Bucket | Retention | Content |
|---|---|---|
| logs_audit | 365 days | Security and access logs |
| logs_applicatifs | 35 days | Standard application logs |
| logs_debug | 7 days | Verbose logs |
Good practice: Permissions can also be granted per bucket: audit logs can only be read by the security team.
3. Costs and compliance #
Finding the right balance.
Making trade-offs #
- Keeping data longer costs storage: keep for a long time only what will actually be queried.
- GDPR requires not keeping personal data longer than necessary: mask at ingestion and limit retention (see the article on handling GDPR in Dynatrace).
- For indicators over several years, prefer (aggregated) metrics to raw logs.
- Document the chosen durations and review them every year.
