Add statsd instrumentation #11
Conversation
|
In an internal branch of the cache server I've implemented pull commands to retrieve statistics from our cache server instances. This was done to feed a munin instance with the statistics data which polls the cache server every so often. So from my point of view I'd rather opt for a low-tech stats retrieval mechanism instead of implementing specifics into the cache server, just to give users freedom to attach whatever tracking mechanism they use. |
|
As I read your argument, you're asking for protocol-independence. (Right?) At very least I'd appreciate if we could get some common metrics-events flying somewhere, and then pick it up from there. I'm not particularly keen on maintaining an fork of the project with hooks deep into the internals. As an alternative, I'd like to propose implementing the prometheus scraper interface, though that'll require quite a bit more care when running in clustered mode. |
|
A ground-up re-write is coming soon - see the feature/streams-refactor branch. It's stable and ready for perf testing if you want to check it out. As such I'm not going to take any PRs against the current version, other than critical bug fixes. |
4 participants
I've added some metrics as to track the throughput, hit-rates and command usage.
I'm not terribly familiar with the underlying protocol and general behaviour of the system, but I am looking to improve performance of our cache server. We have talked about several possible bottlenecks (disk, network, Node.js) but to find out we need some measurements...
It's using the DogStatsD protocol, which is basically statsd with tags in it. Primarily supported by Datadog and the Prometheus statsd exporter.
There are two new options,
--statsd-host [hostname]which set the host to send traffic to and--statsd-tags [key:val, ...]which adds extra tags for the whole server (if ex. having one server per game/office/...)I'll be happy to incorporate any feedback you may have.