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 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 PingDirectory 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.