couchdb-erlang mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Anderson <...@cloudant.com>
Subject Re: starting on metrics
Date Fri, 16 Nov 2012 01:15:43 GMT
On Thu, Nov 15, 2012 at 4:49 PM, Paul Davis <paul.joseph.davis@gmail.com> 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?

Mime
View raw message