PingDirectory

Preparing the servers monitored by the PingDataMetrics server

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.