bernd / statsd-influxdb-backend

A naive InfluxDB backend for StatsD
ISC License
172 stars 74 forks source link

Tag support #21

Open esword opened 9 years ago

esword commented 9 years ago

I have seen a couple different ways that statsd-to-X bridges enabled support for tagging. This project does it by looking for tags embedded as part of the metric name. It is ugly, but probably safest since it makes no assumption about how the statsD process looks at data after the type constant.

A cleaner way is how DataDog does it (see format). I have used this fork of a popular statsd client library to push data in this way, but it may assume that the DD agent is the statsD service (rather than a generic statsD service that would barf on the data after the type data).

Just tossing ideas out. We are looking at using influxDB and need a statsD-with-tags solution. I can't offer to help (yet), but maybe someone else can get a jump on things using either of these approaches as a basis.

esword commented 9 years ago

Another possibility: Here's a thread from the dropwizard metrics forum about what that project may do for tag support - (https://groups.google.com/forum/#!topic/metrics-user/95Dv1xcOox0)

aderumier commented 9 years ago

Hi, I need this feature too, I'll try to implement something similar to https://github.com/danslimmon/statsd-opentsdb-backend.

also, influxdb 0.9 need to use the new line protocol to pass tags (no more json), https://influxdb.com/docs/v0.9/write_protocols/write_syntax.html

So, it's not too much different than opentsb

aderumier commented 9 years ago

Seem that somebody already done it in this fork :)

https://github.com/Asana/statsd-influxdb-backend/commit/cc75147626498808d1b37ab0eb8afd410b9d515a

aderumier commented 9 years ago

here another implementation : https://github.com/starsy/statsd-influxdb-backend/commit/a0c97e524a7f99ae0e989005aee8d246b4c46fc9

rjaquino commented 9 years ago

The second implementation has also been issued as a PR here: https://github.com/bernd/statsd-influxdb-backend/pull/22. I had meant to submit ours as a PR once we confirmed it was working for us, but the line protocol seems strictly cleaner.