couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: Statistics Module
Date Sat, 31 Jan 2009 17:01:43 GMT
Hi Dirk,

thanks for your comments.

On 31 Jan 2009, at 12:40, Dirk-Willem van Gulik wrote:

> Paul Davis wrote:
>> >> The way that stats are calculated currently with the dependent
>> >> variable being time could cause some issues in implementing more
>> >> statistics. With my extremely limited knowledge of stats I think
>> >> moving that to be dependent on the number of requests might be  
>> better.
>> Code looks awesome. For reference, they're storing the last N samples
>> with each time point over a given time period. Ie, they store the
>> current counter values once a second.
> Eh - do you really want to build RRDtool/cacti/nagios/zenoss/mrtg  
> like capabilities in your database ?


> I'd say - focus on getting the data out (ideally as _counters_) and  
> let the monitoring tools figure out the rest. They know their  
> polling intervals and what not (some dynimically adjust) and can  
> figure out how to sample, calculate rates, do stats and what not.  
> And can have fairly refined windowing techniques to aggregate (e.g.  
> rrdtool).
> So do not try to make a stats module - try to make a module that  
> output the data on which you can base your starts :).
> I.e. when you can have:
> 	database_opened		counter
> 	database_closed		counter
> you can work out 1) rate of open/close, 2) the number currently open  
> and do all sorts of post processing. Whereas a float giving you some  
> rate over some unknown window is not nearly as useful.

We have pure counters and raw data for all the tools. After all,
this was done after your spec which asked for some aggregate
values, so we put it in. The aggregates are well defined: 900
second window, 1 second resolution. We don't plan to make
this any fancier, just add more counters.


View raw message