Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

better support for aggregation of counters #344

Open
woodsaj opened this issue Feb 9, 2019 · 0 comments
Open

better support for aggregation of counters #344

woodsaj opened this issue Feb 9, 2019 · 0 comments

Comments

@woodsaj
Copy link
Member

woodsaj commented Feb 9, 2019

trying to aggregate counters is problematic. Users regularly have applications that emit counters, eg for number of requests handled, and want to aggregate these across many instances. When viewing the data users usually convert the aggregated metric to a rate via graphites perSecond() function.

The problem with aggregating the counters, is that if a single datapoint is missed from one instance the resulting counter value is much lower then expected. If the next interval has points from all instances then the aggregated counter value suddenly jumps. This leads to large drops and spikes when converting the aggregated counter to a rate.

In general, it is not recommended to aggregated counters. Instead the counters should be converted to rates first then aggregated.

Crng supports converting to rates but does not support chained aggregations (eg, convert to rate then sum).

Supporting chained aggregations will like require significant code changes, so instead i propose that we just add new functions for

  • sumRate
  • avgRate
  • minRate
  • maxRate

which convert metrics to rates then aggregate using the specified method.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant