Option to use separate name and url tags (Possibly via raw_url)

[TomRiddle01]

Feature Description

From these threads (#2654, #2726, #2584) and release notes (https://github.com/grafana/k6/releases/tag/v0.40.0, https://github.com/grafana/k6/releases/tag/v0.41.0) I understand that the url and name tags are now essentially the same. My team and I apparently are the minority that uses those tags/values as described by @na-- in #2654 (comment).

I did not find an issue regarding the planned raw_url (Announced here: #2726 (comment)) so I want to voice interest and maybe start a discussion.

our use case:
The websites we test often have a lot of redirects and dynamic URLs. Because of this we tag all requests with shorter names to group them. In case of unexpected behaviours we used to look up the actual URLs from non-aggregated the InfluxDB/Grafana.
We also like to automatically print a mapping of which names map to which actual URLs to include in a report after the test.

In short: We'd like to continue to use something like the proposed raw_url in the mentioned threads.
For our use case this probably means support for non-indexed values in the influxdb output would be needed.

Suggested Solution (optional)

No response

Already existing or connected issues / PRs (optional)

#2654
#2726
https://github.com/grafana/k6/releases/tag/v0.40.0
https://github.com/grafana/k6/releases/tag/v0.41.0

[na--]

Thanks for opening this issue and sharing your use case! I'm sorry that the recent k6 versions broke your process 😞 We discussed that whole set of k6 changes quite heavily internally and decided to cut back quite a few things to narrow the scope, but we probably shouldn't have completely removed raw_url 😞

We have some plans to try to introduce another JS API to allow users to manually set high-cardinality metadata again (#2766). Unfortunately, this won't help you much when it comes to redirect, since the current k6/http API isn't very flexible and can't deal with that without a lot of boilerplate and wrapping 😞 We plan to address that in #2461, among a ton of other issues, but that is also a long way off from being ready...

A much easier fix for this problem would be to add a new system raw_url "tag" similar to vu and iter. Similarly to them, raw_url will be disabled by default, so there would be no performance implications, and it will not actually be an indexed metric tag, but high-cardinality non-indexed metric metadata.

This should be simple enough to count for good first issue issue tag, and there aren't any big downsides I can see 🤔 You'd have to manually enable it with the systemTags option, but it should cover your use case well. @mstoykov and @grafana/k6-core devs, WDYT, 👍 or 👎 (with a comment)?

We should probably also have a separate issue for the influxdb output to handle high-cardinality metadata as metric metadata as InfluxDB "fields", since currently only the json and csv outputs deal with the metadata in any way 🤔

[TomRiddle01]

Thanks. We actually do a lot of wrapping already so we probably are equipped to handle changes. Unfortunately we didn't see this ongoing discussion earlier and weren't able to chime in. We aim to share more of our workflow in the future too.

Afaik the "url" tag was an InfluxDB "field" already. From personal experience those should work well with high-cardinality data. We are excited to switch exceptions/errors to high cardinality fields too once user defined high-cardinality metadata is possible. For now we actually use tags for that (Knowing very well, that this can lead to performance issues)

[sid-maddy]

A much easier fix for this problem would be to add a new system raw_url "tag" similar to vu and iter. Similarly to them, raw_url will be disabled by default, so there would be no performance implications, and it will not actually be an indexed metric tag, but high-cardinality non-indexed metric metadata.

This should be simple enough to count for good first issue issue tag, and there aren't any big downsides I can see 🤔 You'd have to manually enable it with the systemTags option, but it should cover your use case well. @mstoykov and @grafana/k6-core devs, WDYT, 👍 or 👎 (with a comment)?

@na--, thanks for this suggestion! I'm already using this in my fork.
I can PR it, if this is something that's approved to be included back in k6 core.

[mstoykov]

@sid-maddy as long as you also provide tests and preferably at least some rudimentary benchmark results the code from your repo looks okay.