Statsd Admin interface #18

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
2 participants

werkshy commented Jan 18, 2013

This statsd bug led me to finding the statsd admin interface on port 8126: etsy/statsd#113

Here's a class that implements the admin commands to list stats: stats, counters, timers, gauges
And the management commands: delcounters, deltimers, delgauges

I'm using it to clear out defunct ec2 servers from my statsd gauges.

Sorry, no unit tests or readme modifications :\

Owner

jsocol commented Mar 1, 2013

@werkshy I like this! I'll likely merge it in after the pipeline branch, so it'll be in v2.

Owner

jsocol commented Jul 28, 2014

I'm sorry to do this, after... over a year, dang. But every time I look at this PR I just can't see how it would fit in. It's not a standalone repl—and that would be crazy if it were—it's not a CLI tool—which adds a whole can of worms here—and it doesn't offer huge advantages over telnetting to the same port.

I could see a more comprehensive CLI at some point, something that might look like this:

$ statsd incr[ement] stat [value] [rate]
$ statsd timing stat value [rate]
$ statsd gauge stat value

And then, either in a separate executable, or separate namespace, the admin tools would have a more natural home:

$ statsd-admin gauges
host01.process.memory.rss
host02.process.memory.rss
host03.process.memory.rss
$ statsd-admin delgauges "host03.*"
deleted: host03.process.memory.rss
$

(Or maybe statsd admin gauges or statsd[-| ]admin gauges --delete, either way.)

Then I can see having this code in a good, programmatically accessible place, but you wouldn't need to write a bunch of code or use a Python REPL to use it.

Maybe this is a good route for 4.0. If it would be useful for people.

werkshy commented Jul 28, 2014

I've left the job that I wrote this for, but we were using it to clean up old stats when we rotated servers, otherwise statsd keeps reporting the last value of any gauges (the metric names contained the server like prod.server1.cpu). We were calling the admin stuff from a python script, hence the desire for a python module to wrap it. It solved a real problem for us at least. YMMV.

Owner

jsocol commented Jul 28, 2014

@werkshy I get how it would solve that problem for you (I usually reboot statsd then wipe out junk .wsp files, myself), it's just a question of API design and "where does it belong?" (I.e. should it be pip install statsd-admin.)

Nothing else in this library—right now—involves two-way communication, very much by design of both the statsd server and the client. And everything else operates through a single class interface (that Timers and Pipelines are classes is really an implementation detail, you shouldn't need to think of them that way). Dropping in this admin client class and saying "it's here, but you're on your own to use it" doesn't mesh with the general "know-/require-/do-as-little-as-possible" principle of the rest of the library.

I'm just saying I could never see a way to merge this as-is and still love the overall cleanliness and simplicity here.

But, I do think that exposing a CLI statsd client would, in general, be a useful addition. Increment from shell scripts or whatever else. And in that context, I think there's a motivating API within this package where the admin tool fits (as opposed to some statsd-admin).

Once there's a place it fits, there's every good reason to keep the code well-structured so that the admin client could be imported and used programmatically by other Python programs.

So I may take this as a jumping off point and do a CLI interface, and call that v4. I mean it would be so great if a deprovisioning bash script could just run statsd gauges --delete "stats.gauges.hostFOO.*".

werkshy commented Jul 29, 2014

I respect your aim in keeping the module as simple as possible. I guess
I'll just throw this class up as a gist for those who might seek it out,
since I don't have the urge to package it at the moment. Feel free to use
it later if your CLI tool takes shape.

On Mon, Jul 28, 2014 at 6:37 PM, James Socol notifications@github.com
wrote:

@werkshy https://github.com/werkshy I get how it would solve that
problem for you (I usually reboot statsd then wipe out junk .wsp files,
myself), it's just a question of API design and "where does it belong?"
(I.e. should it be pip install statsd-admin.)

Nothing else in this library—right now—involves two-way communication,
very much by design of both the statsd server and the client. And
everything else operates through a single class interface (that Timers
and Pipelines are classes is really an implementation detail, you
shouldn't need to think of them that way). Dropping in this admin client
class and saying "it's here, but you're on your own to use it" doesn't mesh
with the general "know-/require-/do-as-little-as-possible" principle of the
rest of the library.

I'm just saying I could never see a way to merge this as-is and still love
the overall cleanliness and simplicity here.

But, I do think that exposing a CLI statsd client would, in general, be a
useful addition. Increment from shell scripts or whatever else. And in that
context, I think there's a motivating API within this package where the
admin tool fits (as opposed to some statsd-admin).

Once there's a place it fits, there's every good reason to keep the code
well-structured so that the admin client could be imported and used
programmatically by other Python programs.

So I may take this as a jumping off point and do a CLI interface, and call
that v4. I mean it would be so great if a deprovisioning bash script could
just run statsd gauges --delete "stats.gauges.hostFOO.*".


Reply to this email directly or view it on GitHub
#18 (comment).

@werkshy werkshy closed this Jul 29, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment