On 15 November 2012 14:13, Paul Davis <[email protected]> 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
