Chase,
Ori mentioned that you might have plans to replace txstatsd as our StatsD
collector for graphite/carbon. Do you have such plans and can you elaborate?
The reason I'm asking is because we currently operate txstatsd with a non
statsd complaint message processor which has some unexpected, to me, side
effects with respect to counters. On the other hand, we cannot use the
compliant processor because it uses a whole bunch of unwanted prefixes.
The side effect to this is that I cant just use a vanilla StatsD client in
my code, and having looked at the internals of the non compliant processor
I'm worried we're abusing it and thus potentially misinterpreting its
results in other places (it uses mark() to store statistics which doesn't
do aggregation and keeps it across time points). On the other hand, it's
implementation of timer is very friendly in that it gives us percentile
breakdowns and such...
So, my current thought is either to write another processor with better
counter semantics; or we should replace it entirely with a vanilla statsd
implementation (like etsy's -- which we might have to end up patching to
get the nice timer behavior.) I suspect that writing another processor and
hosting a custom deb locally is probably the "easiest" option.
It's probably worth pointing out that txstatsd is currently unmaintained --
Sidnei left Canonical for Google sometime near the end of last year and
hasn't touched the code since.
~Matt Walker
Wikimedia Foundation
Fundraising Technology Team