com.unraveldata.metrics.backup.dir

Parent directory for database backup files.

com.unraveldata.metrics.data.points

The number of data points to be stored in a single database row.

com.unraveldata.metrics.doArchive

When true, archive retired partitions.

com.unraveldata.metrics.loadfile.dir

Parent directory for metric load files.

com.unraveldata.metrics.loadLatency.sec

Latency for loading metrics of a job.

com.unraveldata.metrics.merge.cache

Specify the count of messages for caching.

com.unraveldata.metrics.partition.cnt

Partitions available for future metrics.

com.unraveldata.metrics.partition.sec

Duration of a partition (1 week).

com.unraveldata.metrics.retention.sec

The threshold to retire partitions (1 month).

com.unraveldata.metrics.sample.count.max

Specify the maximum count of data points for sampling purposes.

This represents how many messages need to be aggregated to construct one data point in the graph.

Here the default is 16, which means one data point in the resource metrics graph represents 16 samples collected/received. This is the maximum value.

With Live aggregation, there is dynamic aggregating of messages as and when it received. Initially the sample count will be 1. If there are enough data points ( value of com.unraveldata.metrics.data.points) this is further aggregated and will replace the message with another set which will have sample count 2. The above process repeats and the sample count will become 4, 8, 16.

Since we have set the upper limit as 16, no further merging/folding will not occur. If you want to modify the sample count property, you must set it as n x 2 that is 2, 4, 8, 16, 32, 64. This property defines the granularity of the data for long-running applications. If you want high granularity you must set lower values.

com.unraveldata.metrics.statFrequency.sec

How often to write load statistics to log.