Metrics - Telegraf - Influx Statsd Protocol Support

[jameschensmith]

I need to send metrics to a telegraf client that supports the Influx Statsd protocol.

I know that the metrics libraries that go-kit supports are just the standard protocols, so my question is if go-kit is opposed to adding support for the protocol, what would be the best way to create my own package using go-kit's statsd package and just adding tag support? I can't take the statsd package directly and make my modifications because the package uses internal libraries. Thanks!

[peterbourgon]

Can you use the Dogstatsd package?

[jameschensmith]

Hey @peterbourgon. Unfortunately the protocol is different. This can be seen in the metric format for dogstatsd, where the tags are placed at the end, instead of after the metric name in CSV format.

[jameschensmith]

@peterbourgon, I've been doing a little more digging, and I've found two potential options that I can currently use:

1. As this article shows under Introducing Influx StatsD, I could essentially just append the tags to the metric's name of each metric that I want to publish. This option would allow me to continue to benefit from go-kit, but this unnecessary avoiding of a base implementation support can be solved in Option #2.

2. Use this statsd library, which supports both DogStatsD and Influx StatsD format. The only downside of this option, is that it's not bundled with go-kit, and therefore doesn't benefit from the data structs, logging, and tracing that the kit provides.

I think I will go with Option #2 for now, but I would recommend (I can open a separate issue and possibly work on this if you think it's a good idea) taking what this library provides, and merging the base StatsD protocol with the DogStatsD (already implemented) and Influx (to be implemented) flavors of the protocol into a single StatsD package. Let me know what you think. 😊

Edit : Update : Option #2 seems to be broken and unmanaged by the creator. Will go with Option #1 and again recommend to combine StatsD protocols into a single package or offer support for Influx StatsD protocol. Thanks!

[peterbourgon]

How would you suggest we manage the different wire protocols, if they're all in the same package? Different types and constructors?

[jameschensmith]

There are two options that I can think of off the top of my head :

1. Single statsd package with a type option for : base, dog, and influx. This type will be in the Statsd struct along with the other fields needed. Append / ignore the tags and construct the object based off the flavor of StatsD used. This option would require some values in the struct not being used by some of the protocols. For example, the base StatsD would not use the histogram field.

2. Have a statsd package along with a statsdX package that supports the other flavors of StatsD. Seeing as the Influx StatsD is more related to DogStatsD, this might be an easier option to implement, and I see possibly all the fields being used by both of the additional protocols.

Both seem quite messy, especially since DogStatsD is more independent from StatsD compared with Influx StatsD. Just some suggestions. Let me know what you think.

[peterbourgon]

I'd like to try out a package structure that better optimizes for minimizing dependencies. If all of those implementations can be made using only stdlib dependencies, then I think it'd be great if they can just be types in the same package statsd. But if they need their own third-party dependencies, I'd like to try segregating by package, i.e. package {statsd,influxstatsd,dogstatsd,...}.

Does that make sense? (I fully acknowledge this isn't currently the case throughout Go kit!)

[jameschensmith]

That makes sense, @peterbourgon. I believe (inferring that internal dependencies are not third-party dependencies) the current case is that both of the currently implemented protocols (i.e. package {statsd,dogstatsd}) implement stdlib and internal dependencies. Influx StatsD protocol should follow the same design. So, are you suggesting to go with the same package statsd?

[peterbourgon]

Hmm, I guess the tradition now is separate packages altogether. Three choices:

• Brand new package influxstatsd — I admit a slight preference for this one
• Add new types to package statsd
• Add new types to package influx

[jameschensmith]

@peterbourgon, if creating an additional package is not a problem, I would agree with your preference.

One thing, as I noted earlier, is that the Influx StatsD is not as independent as DogStatsD, and seems to be a protocol created by Telegraf (i.e. Influx Data) to support tags / additional features using StatsD protocol. So, seeing as it's a potentially temporary protocol, I could see it either as a separate package that separates concerns in case the protocol is deprecated in the future, or implementing tag support in package statsd (keeping package dogstatsd independent still) with the idea that StatsD protocol may support tags in the future.

I still see your preference as the best option. 😅