[prometheusexporter] SDK uses the wrong signal to determine whether to escape

[ywwg]

Description

PR 5755 added switching logic to determine when to escape prometheus names and when not to. We have since decided that relying on model.UTF8Validation is the wrong signal and we should only use an internal flag to gate that behavior. That value has also been deprecated. And, since there are bugs with how the escaping is currently performed, I suggest the SDK should always escape until we have update the spec to allow for the proper no-translation mode (open-telemetry/opentelemetry-collector-contrib#39706 (comment)).

Removing this behavior will restore the SDK to its expected behavior, which is to always escape prometheus metric and label names.

[pellared]

FYI @dmathieu, @dashpole

[pellared]

I suggest the SDK should always escape until we have update the spec to allow for the proper no-translation mode

Can you please give more context as personally I am getting lost in the communication.

Is there a spec issue for it? Can you reference it?

When I am reading https://pkg.go.dev/github.com/prometheus/common/model#NameValidationScheme:

If you wish to stick to the legacy name validation use
IsValidLegacyMetricName()andLabelName.IsValidLegacy()methods instead. This variable is here as an escape hatch for emergency cases, given the recent change fromLegacyValidationtoUTF8Validation, e.g., to delay UTF-8 migrations in time or aid in debugging unforeseen results of the change. In such a case, a temporary assignment to LegacyValidationvalue in theinit()` function in your main.go or so, could be considered.

then it looks like the "no-translation mode" is the officially supported one it maybe we should not escape at all.

since there are bugs with how the escaping is currently performed, I suggest the SDK should always escape until we have update the spec to allow for the proper no-translation mode

What bugs? Is there an issue? If the escaping is buggy then it does not seem to make sense to always escape.

Can you please improve the issue description as guess that you are suggesting to do right thing, but I have a feeling that the justification is unclear. Even if I would somehow follow it, I think that it should be well described for the sake of the users that would like to understand why we are going back and forth.

[pellared]

Possibly related: open-telemetry/opentelemetry-specification#4494 (comment)