graphite-dev team mailing list archive

[Michael Leinartas <question148743@xxxxxxxxxxxxxxxxxxxxx>]

Question #148743 on Graphite changed:
https://answers.launchpad.net/graphite/+question/148743

Michael Leinartas posted a new comment:
Yeah, I agree there's a gap here. A lot of us really dont have the
luxury of deciding how our metrics come in as drawks points out. There's
also something to be said for storing the data in the least modified
form (e.g. raw counter values).  I think this is related to this
question: https://answers.launchpad.net/graphite/+question/184877 and
solving this perhaps solves it.

I think what Chris proposed a while back at the top of this thread with
the summarize() function makes sense (at least to me).

Say you sample counters every 10 seconds.  A nonNegativeDerivative gives
you a rate of events/10sec.  Using summarize() with a '1min' interval in
'sum' mode gives events/minute. What's proposed is that if you give
summarize a '1s' interval, a events/second rate would be imputed.

This only makes sense for 'sum' mode. The other modes 'avg', 'last',
'min', 'max' would have to either error out or behave as keepLastValue()

Aman Gupta and Chris Davis did some work on the summarize() function a
few weeks back. The new version (which is intended to replace the
original) is called smartSummarize(). I propose that we add this
functionality to it rather than creating a new function.

Can anyone spot problems with this approach? The patch from redbaron
isn't off the table, it just feels to me that summarize() could gain a
lot by having this - you then really dont have to know what your
interval is at all to get the resolution of rates you want in either
direction.

-- 
You received this question notification because you are a member of
graphite-dev, which is an answer contact for Graphite.