search

grafana / k6

A modern load testing tool, using Go and JavaScript - https://k6.io
GNU Affero General Public License v3.0
25.84k stars 1.27k forks source link

StatsD/CloudWatch tags #1765

Closed hynd closed 3 years ago

hynd commented 3 years ago

Support tags in StatsD metric output.

Feature Description

I might be missing something obvious, and i know there's a lot of changes upcoming with metric output (which i'm eagerly following!), but from a quick skim of the code it doesn't seem like the StatsD metric output supports tags?

Digging deeper, maybe this is because tags are not an official part of the format (see https://github.com/statsd/statsd/issues/619), but the extra dimensions (particularly for custom tags) would be useful when sending data to AWS CloudWatch, which seems to make some interesting aggregations when receiving stats from multiple instances.

The CloudWatch agent supports the same tag format as DogStatsD's extension:

MetricName:value|type|@sample_rate|#tag1:value,tag1...

This would need to be configurable (some endpoints might not support tags), tho it could be complex to support every possible tag variant (eg; Splunk/SignalFX's MetricName[tag1=value,...]:value|type). How would you suggest/prefer such a feature to be implemented?

mstoykov commented 3 years ago

The datadog output, which is based but different from the stated one, does support tags. So if you just say -o datadog instead of -o statsd it will just ... work ;). There is also a configuration about not sending some tags as k6, in general, sends a lot of tags, which is not oaky for some outputs such as datadog.

I can't comment currently on whether we will support multiple tag formats - I would argue that once we have output extensions, some currently included outputs will probably move out and only a small very standard subset will be left in k6. Whether that will actually happen like that and whether that will include stats/datadog is ... a question for the future :)

I am closing this as this is actually implemented, and I would argue that supporting multiple tag formats will likely not happen before we have extension outputs, and especially that it is unlikely to be developed by the k6 team.

If you want to make a PR for it - open another issue to discuss it, but first look at this https://github.com/loadimpact/k6/blob/1443e5ee738df5bac7d6b5e1c4a026df16735ffe/stats/datadog/collector.go#L36-L44, it is likely going to be just a matter of changing this function between output types, but if we are going to get any more I would argue that the code will need some DRYing up as otherwise this just introduces more work for when we refactor it to make the output extensions possible.