couchdb-erlang mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: starting on metrics
Date Fri, 16 Nov 2012 00:49:51 GMT
> 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.

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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message