Feature request: add rate

[msaf1980]

Add
rate as sum / (carbon.interval / 1000)
sample_rate as agg.len() / (carbon.interval / 1000)

[Albibek]

We think about adding lua for processing metrics before they are sent to carbon. It should solve most of the post-aggregation problems better than single cases

[msaf1980]

msaf1980@046382e
Quick and ugly realization. Unsafe was used, because I need global mutable variable (filled with value from config file).

[Albibek]

You can use a lazy_static to stay safe.
And I'm still unsure if we should add functionality that can easily be done on storage side, i.e. using some graphite function. This would make bio too bloated and monolithic, and we'd like to avoid this.

[loyd]

@Albibek
I'm surprised that it's not implemented here, at least as optional settings.

Firstly, modern statsd sends .rate and .count metrics, and it has the behavior like bioyino only with legacyNamespace enabled.

Secondly, such metrics highly rely on an interval of aggregation (that defaults to 10s), and it can be tricky to implement rate calculation based on total count only. Could you explain how you use graphite functions to do it? We use mhr3/brubeck (supports .rate) and graphite, and there is a visible (but not dramatically) difference between .rate and perSecond(.count) even in ideal conditions with uniform distribution. Using data from DB we've detected that the precalculated metric is more precise than produced by graphite. The situation worsens in different cases: missing data points, after retention (obviously with right aggregation settings in graphite), irregular grid etc. Thus, the precalculated metrics are more reliable.

we'd like to avoid this.

We write in rust and want to replace brubeck with bioyino, but the absence of .rate is frustrating. Is your position final?

[Albibek]

Considering your request is another one here, I think this can and should be implemented. Also, some time ago I was worrying about increasing the number of unique names for ms, but since 0.7 (not yet released) it's possible to define aggregations in config, so this is not a problem.

[Albibek]

@loyd @msaf1980 The rate aggregation has been added into 0.8.0-alpha2 tag

Note, that it is available for all metrics, because of the update counter value being used. So for i.e. set or counter the rate is also available, but for set it will not always be equal to len(set)/aggregation_period.

Could be great if you tested this somewhere so I am sure it works as intended.