couchdb-erlang mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Cottlehuber <...@jsonified.com>
Subject Re: starting on metrics
Date Thu, 15 Nov 2012 21:35:11 GMT
On 15 November 2012 14:13, Paul Davis <paul.joseph.davis@gmail.com> wrote:
> The idea here is good but I'm not at all a fan of the implementation. First
> off, no way should we be choosing a specific stats collection protocol.
> They're just too specific to a particular operations/infra configuration
> that anything we pick is going to be inadequate for a non trivial number of
> users.

Absolutely - but as a first go I am learning a lot :-)). First make it
work, then make it pretty?

Yesterday I hacked in starting up estatsd and enabling/disabling this
via config file:

https://github.com/dch/couchdb/commit/e885e55ee91b77be41363c0fd76414036650dcaa

It's hacky but it works, I think.

> OTOH, I think it would be a very good idea to sit down and design the stats
> API to be pluggable. We already have two rough sides to the API (collection
> vs reporting). If we sat down and designed a collection API that would then
> talk to a configurable reporting API it'd allow for users to do a number of
> cool things with stats.

Nice split.

Re measuring "properly" we could get by with 3 "things":

- counters (http reqs, # of active couchjs procs maybe)
- duration
- events (replication started, etc)

And then plug into graphite, riemann, whatever take your fancy. Would
the best way to provide that API interface these counters be to write
a custom behaviour? Any existing code you can point to that does this
sort of thing?

Last question, any tip on how to implement this in a way that you can
turn off metrics and avoid the performance hit completely, without
needing a recompile (e.g. to remove macros)?

A+
Dave

Mime
View raw message