we currently have events triggered and pushed in a PUB/SUB zmq socket.
We should emit various statsd calls depending on those events as well.
The part I am not sure about is if we want to have this statd as a pub/sub client (so we need to handle one more process) or make it a statsd publisher at the same level than the zmq publisher
I think the easiest way to deal with this would be to create "event emitters", where we register any kind of emmiters and provide our zmq and statds ones...
I don't think including statsd before the zmq publisher can hurt any speed anywhere
After a second look at the code, it seems that having one subscriber per plugin can be a good solution because it makes the calls asynchronous.
A plugin receives events and have a link to the circusd commands machinery to act on the stack.
We'll have a feature to load plugins when circus starts:
And maybe a script to run one or several plugins, given an endpoint
added a plugin system and a statsd plugin - refers #138
make sure we use the passed options - refers #138