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. The Directory Proxy 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.
The flush interval can be set 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 Proxy 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 good estimate.