Class DiagTask_gauge

java.lang.Object
io.nosqlbench.adapter.diag.optasks.BaseDiagTask
io.nosqlbench.adapter.diag.optasks.DiagTask_gauge
All Implemented Interfaces:
com.codahale.metrics.Gauge<Double>, com.codahale.metrics.Metric, DiagTask, NBParentComponentInjection, NBCanConfigure, NBConfigModelProvider, NBConfigurable, NBLabeledElement, BiFunction<Long,Map<String,Object>,Map<String,Object>>
public class DiagTask_gauge extends BaseDiagTask implements com.codahale.metrics.Gauge<Double>, NBParentComponentInjection

A diag gauge task allows you to create a source of metrics data for testing or demonstration. You can customize the function used to produce the raw values, the number of buckets to use for leavening the values over time, and the basic stat function used to summarize the buckets into an aggregate double value.

Usage Notes

The data image for the gauge summary is updated consistently with respect to monotonic (whole step) cycle values. There are a few parameters which can be adjusted in order to make the gauge data appear more realistic.
  • label - This determines the metric label, normally used as the metric family name. Default is the task name.
  • buckets - The number of values to seed incrementally to produce a data image
  • binding - The binding recipe to use to create the value stored in a bin for a given cycle
  • modulo - The interval of cycle values at which a new bin value is computed and stored in a bin
  • stat - The aggregate statistic to use when computing the gauge value: min, avg, or max

The buckets are updated incrementally and consistently based on the cycle value, modulated by the modulo value. When the gauge is observed, the present value of the buckets is converted to a values image and the result is summarized according to the selected stat.

Practical values should be selected with awareness of the op rate and the rate of change desired in the metrics over time. The buckets allow for the effective rate of change over cycles to be slowed, but it is recommended to keep bin counts relative low by increasing modulo instead.

Examples

Suppose you wanted to see a moving average, where a new value is presented every second. A new value every second is obviously not needed in practical scenarios, but it makes a useful basis for thinking about relative rates, since the rate limiters are specified in ops/s.

  • activity rate=10 modulo=10 - a new update will be visible every second.
  • activity rate=1000 modulo=1000 - a new gauge value will be visible every second.
  • activity rate=1000 modulo=60000 - a new gauge value will be visible every minute.
  • activity rate=100 modulo=100 buckets=50 stat=avg - a new value will be visible every second, however the rate of change will be reduced due to the large sample size.

Usage Notes

Changing the number of buckets has a different effect based on the stat. For avg, the higher the number of buckets, the smaller the standard deviation of the results. For min and max, the higher the number of buckets, the more extreme the value will become. This is true for uniform bindings and non-uniform binding functions as well, although you can tailor the shape of the sample data as you like.