Modify Metric Data Retention Periods
You can modify the default metric data retention periods, which control how long data is retained at 1-minute, 10-minute, and 1-hour resolution. See Metric Data Resolution over Time.
There are a few important points to note before changing metric data retention periods:
Setting longer retention periods for metric data can quickly and significantly affect database size and Controller performance.
- If you need to review details for an issue that occurred during a period for which you have only 10-minute or 1-hour data, Splunk AppDynamics provides access to diagnostic data at a more detailed level than might be visible on a graph, so increasing the default retention periods is not often necessary.
- While metric retention periods apply to the data kept in the Controller database, some of the data that appears in the Controller UI — in particular, data at the 1 and 10-minute granularity level that appears in the tier and application dashboards — is fetched from the Controller cache rather than from the database. If you set the 1 and 10-minute metric retention periods to an overall retention period that exceeds the cache retention period, the performance of the Controller UI will be adversely affected. This is because the Controller has to retrieve the data from the database rather than from the cache. The cache retention period is determined by the
caches.retention.period
setting, which you can modify in the Administration Console. - Changing the data retention periods in the Controller settings does not affect the values shown as time ranges in the Controller UI.
To change the data retention period for metrics:
-
Log in to the Administration Console.
-
Click Controller Settings.
-
Change the data retention period by modifying the values for the following settings:
Property Name About the Property Deafult appdynamics.controller.sim.purge.machine.using.metric
Enable purging using only metadata information. Purging in this method does not use metrics data. false metrics.min.retention.period
The number of hours 1-minute data is retained. This value should always be less than the value for metrics.ten.min.retention.period
4 hours
metrics.ten.min.retention.period
The number of hours 10-minute data is retained. This value should always be greater than the value for metrics.min.retention.period and less than metrics.retention.period
48 hours
metrics.retention.period
The number of days 1-hour data is retained. This value should always be greater than the value for metrics.ten.min.retention.period
365 days
purger.bts.shortlived.expected.baseline
The expected number of short-lived business transactions to be purged in one purging attempt. 100 purger.metrics.shortlived.expected.baseline
The number of entities the short-lived metric purger expects to be purged on every purging attempt. 1000 shortlived.metric.purger.time.interval.in.min
The interval frequency in minutes for the short-lived stale metric purger timer task to run. 30 shortlived.metric.purging.enabled
Enable the short-lived metric purger. When set to true, the short-lived metric purger timer task purges all stale metrics which are short-lived. For example, container metrics. true shortlived.stale.metric.duration.in.hours
The duration of data in an hour, in which a metric that has not reported any data, is considered stale. 2
-
Click Save.
For example, if you change the metrics.min.retention.period
property to 3, metric data displayed for all time ranges less than or equal to 3 hours are shown at one-minute resolution. Metric data for time ranges greater than 3 hours and less than metrics.ten.min.retention
are shown at 10-minute resolution, and metric data for older time ranges are shown at 1-hour resolution.
As another example, if you change metrics.ten.min.retention
to 72, all the time ranges less than or equal to 72 hours (3 days), and greater or equal to min.retention.period
are displayed at 10-minute resolution.