The Metrics Backend manages the storage of metrics and provides access to the stored blocks of metrics via LDAP. The Metrics Backend is configured to keep a maximum amount of metric history based on log retention policies.
The default retention policy uses the Default Size Limit Retention Policy, Free Disk Space Retention Policy, and the File Growth Limit Policy, limiting the total disk space used to 500 MB. This amount of disk typically contains more than 24 hours of metric history, which is ample. Directory Server keeps a metric history so that the PingDataMetrics Server can be down for a period and then catch up when it comes back online.
The following two commands create a Retention Policy that limits the number of files to 2000 and sets the Metrics Backend to flush data to a new file every 30 seconds.
$ bin/dsconfig create-log-retention-policy \ --policy-name StatsCollectorRetentionPolicy \ --type file-count --set number-of-files:2000 $ bin/dsconfig set-backend-prop \ --backend-name metrics --set sample-flush-interval:30s \ --set retention-policy:StatsCollectorRetentionPolicy
These commands configure the Metrics Backend to keep 16 hours of metric history, which
consumes about 250 MB of disk, ensuring that captured metrics are available to the
PingDataMetrics Server within 30 seconds of when the metric was captured. The value of the
sample-flush-interval attribute determines the maximum delay between
when a metric is captured and when it can be picked up by the PingDataMetrics Server.
You can set the flush interval between 15 seconds and 60 seconds, with longer values
resulting in less processing load on the PingDataMetrics Server. However, this flush
interval increases the latency between when the metric was captured and when it becomes
visible in the Dashboard Application. If you change the
sample-flush-interval attribute to 60 seconds in the example above,
then the Directory Server keeps 2000 minutes of history. Because the number of
metrics produced per unit of time can vary depending on the configuration, no exact formula
can be used to compute how much storage is required for each hour of history. However, 20
MB per hour is a reasonable estimate.