On Thu, Nov 15, 2012 at 4:49 PM, Paul Davis <[email protected]> wrote: >> With regard to the rolling windows ("stats over past N seconds") idea >> - it's definitely more complex on both the implementation and API >> fronts, but I think it's worthwhile to keep around in some form. If >> you toss it for fixed-windows - i.e., collect data for N seconds, >> calculate your stats, then throw it away and start anew - you lose the >> ability to take meaningful measurements at any point in time. This can >> be misleading for pull-based requesters, such as humans. The API could >> certainly be simplified. Perhaps the window size could be specified at >> metric creation/specification time and returned along with the >> response? >> > > Sorry, I got distracted by my GF coming home in the middle of writing that > email. I meant that I'd like to see a discussion about moving to a time > slice based approach instead of the multiple-rolling-window approach. While > generally in theory I agree with the comment about pull based I think > that's only if we're naive. We could do something as simple as "every N > seconds, calculate values for each metric, use those values for requests > during the next time slice". Then we would get the constant values for N > seconds. I think that sort of thing would be fairly obvious to humans > clicking the refresh with little loss in precision as to what we have now.
Ah, that sounds like a good approach. > > Also, (assuming we go with a plugin type config) then really this > discussion would just be specific to the default plugin we provide with > couchdb that mimics what we do now with HTTP based publishing. Where if > someone wanted to write a riemann push thing, it could be totally different. Well, it would be nice to provide a clean internal API for storage, then use that for the default HTTP plugin, yeah?
