You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
which convert metrics to rates then aggregate using the specified method.
The text was updated successfully, but these errors were encountered: