feat(inputs.http_listener_v2): Save the query parameters as tags

[tomasrojas26]

Summary

Add a new option to save the query parameters as tags. It's very useful to consume metrics from a client that only can send some informational parameters in the URI. Example:

curl -X POST http://local.domain:port/path?tag1=value1&tag2=value2 --data 'metrics in any format'

Checklist

• No AI generated code was used in this PR

[DStrand1]

Thanks for the PR! I have a couple comments, additionally could you run make docs?

[DStrand1]

Are there cases where we would need more than the first value?

[tomasrojas26]

Actually, I think it's not. It was a quick way to parse the value because it's an array, but now that I looked at it more carefully I consider that it could be possible to include another loop to parse it. Do you think this approach is more accurate?

if h.QueryTag {
	queryParams := req.URL.Query()
	for key, values := range queryParams {
		if len(values) > 0 {
			for _, value := range values {
				m.AddTag(key, value)
			}
		}
	}
}

[DStrand1]

I think it does make more sense to be fully accurate, though I worry about this being specifically a tag, and cardinality issues it causes. If the query values change with any regularity this could cause issues. Do you think it makes sense to have this as a field instead?

[tomasrojas26]

Yeah, you're right. It's a really good point. The case I'm dealing with has static data, that's why I solve it with tags. But thinking more globally, there could be dynamic values, and as a consequence, it could generate an impact on the cardinality.

Maybe we could give the option to choose what parameters are tags, like you currently do with the option http_header_tags. Then another option to choose some parameters as fields. What do you think about?

It's a little bit complex and it adds some processing time to the plugin, but you give to the user the option to enable or not with the fields that they need. In the other hand, choosing all/some paremeters as fields, the user has to include a converter processor to choose their tags, which it could be possible as well.

[DStrand1]

Maybe we could give the option to choose what parameters are tags, like you currently do with the option http_header_tags. Then another option to choose some parameters as fields. What do you think about?

I think this is a good solution, @srebhan what do you think?

[srebhan]

I think having http_query_parameter_tags might be good. This way the user has control over the cardinality. However, if multiple values are present, how about having one tag, sort the multiple values and string-join them?

[srebhan]

@tomasrojas26 any update?