Are there any way to restrict data retention of Timeseries metrics?
I think Timeseries metrics is not so large but a little be afraid of a lack of storage space.
I referred this documentation and confirmed Timeseries metrics are unlimited.
https://www.dynatrace.com/support/help/shortlink/data-retention#data-retention-by-type
I also confirmed there is no option about Timeseries metrics on the following page.
Environments > (environment name) > Storage settings
Best Regards,
Natsumi Tanaka
Solved! Go to Solution.
No, it's currently not possible to configure. We are evaluating right now the effort and value of such a functionality. Feel free to post a product idea and pass the feedback of your current issues, ideas and suggestions.
Also related: https://answers.dynatrace.com/content/idea/205773/view.html
Thank you for your answer!
I understood it is not implemented now that changing retention period or storage space of Timeseries metrics. The Dynatrace product idea you showed me is replied that it's not feasible to manage retention on Cassandra and Elasticsearch database, so it seems to be difficult to restrict retention period of Timeseries metrics.
We cannot limit directly whole Elasticsearch and Cassandra storages, but we can think of keeping the limit of particular data types e.g. timeseries, user sessions etc. that might bring more control over these database sizes.
What does it mean "keeping the limit of particular data types"?
Should we reduce capturing data e.g. reduce target hosts, key request or something?
Or is it possible to change data types of timeseries and user sessions, e.g. integer, float, or something?
By data types I meant different data we store e.g. metrics/timeseries, user sessions, change history etc.
Definitely limiting monitored scope will help to stop the database to grow.
No, we cannot change data type of the data we store.
Thank you for your answer!
I understood the current best practice for saving disk space is limiting monitored scope.
exactly. Or you can also scale horizontally the cluster so less space is taken at each node.
Bump this ... not only to restrict but perhaps to further enable for longer metrics / and better granularity & precision over time