We need to add the concept of metric tags/labels/fields to our metric data type. Statsd has the concept of "tags" that are represented like so:
user.logins,service=payroll,region=us-west:1|c
The above increments the user.logins counter with the "service" and "region" tags. These should be preserved in our internal metrics data model. In terms of naming, I'm torn between "tags" and "labels". It appears to former is used more, but we should go with whatever is the most natural to users.
Sadly dogstatsd has a slightly different format outlined here: https://docs.datadoghq.com/developers/dogstatsd/datagram_shell/
users.online:1|c|@0.5|#country:china
So- the tags are moved to the end of the packet
It would be helpful if this was implemented in such a way that allowed the user to configure what kind of metric format vector should look for. Telegraf handles this by including a "is dogstatsd" option under the statsd sink.
As far as I'm aware, Statsd doesn't provide support for tags yet.
And we have at least 3 different extensions that add this feature, all having different syntax.
Influx
user.logins,service=payroll,region=us-west:32|g
DataDog
user.logins:32|g|#service:payroll,region:us-west
SignalFx
user.[service=payroll,region=us-west]logins:32|g
Since Influx (Telegraf) supports both Influx and DataDog formats, I would suggest that we adopt DataDog format, to achieve more coverage with single implementation.
I would even suggest renaming this sink into something like statsd_datadog (Telegraf recently went this way and deprecated it's parse_data_dog_tags flag in favor of having separate plugins for different protocols).
FYI @lukesteensen, @binarylogic
That all sounds good to me!
Yep, agree, appreciate the thought you're putting into this. All of that sounds good to me.
Seems like renaming could wait until we will start working on next Statsd integration.
Most helpful comment
Seems like renaming could wait until we will start working on next Statsd integration.