feat: optional id label for all metrics

[damiankaminski-form3]

Metrics are exported via prometheus push gateway. Unfortunately, push gateway is only a super simple cache. It does not add any common labels, such as server, or pod name, and when metric with the same label set is provided, it overrides the latest value with a new one. That's why it's crucial to make label values unique.

With the new id label it should be a little easier. It's optional and needed only when metric entries might be not unique.

[janakerman-form3]

Hey @damiankaminski-form3 - a couple of questions:

• Is the issue here that we have multiple concurrent executions of the same test overwriting each other's metrics?
• How do you envision this new variable to be used?

[damiankaminski-form3]

Is the issue here that we have multiple concurrent executions of the same test overwriting each other's metrics?

That is the exact issue.

How do you envision this new variable to be used?

It depends on the scenario. It should be a value that:

1. makes the metric unique, so that it is never overridden
2. is not random for every execution, as push gateway is a dumb cache, meaning that random value would stay there forever (not perfect cost and memory wise)

[janakerman-form3]

Hmmm OK. Seems reasonable to me. I suppose the intention is to give the user more control over metrics deduplication when pushing metrics to PushGateway, which is an issue that everyone using this tool could have.

I'm wondering if we couldn't make this more flexible by renaming the new env variable to PROMETHEUS_LABEL_ID. That way, we've be able to add more flexible behaviour in the future, such as adding all labels with PROMETHEUS_LABEL_ prefix as metrics labels, without having to affect the new environment variable in a breaking way.

Of course PROMETHEUS_NAMESPACE is a lost cause. :)

[damiankaminski-form3]

I'm wondering if we couldn't make this more flexible by renaming the new env variable to PROMETHEUS_LABEL_ID. That way, we've be able to add more flexible behaviour in the future, such as adding all labels with PROMETHEUS_LABEL_ prefix as metrics labels, without having to affect the new environment variable in a breaking way.

Good idea. Changed: ad760ba

Of course PROMETHEUS_NAMESPACE is a lost cause. :)

We can add a new PROMETHEUS_LABEL_NAMESPACE and then deprecate the old one some day, but not sure if it's worth it :)

[janakerman-form3]

It's easy enough to do if that functionality is ever added, so I think it's OK not to add it right now.