Meter name validation

[pellared]

The current way the meter can be named may be unfriendly for Prometheus. For example refer to TestIncompatibleMeterName in open-telemetry/opentelemetry-go#4274. Prometheus exporter in OTel Go is logging the issue like this:

2023/06/30 14:09:31 cannot create scope info metric: label value "\xff\xfe\xfd" is not valid UTF-8

and the metric is not exported.

I just want to double-check if the existing behavior of OTel Go Prometheus exporter and OTel Specification is OK or if we should make the name validation more strict. E.g should the meter name validation be the same as for (or similar to) instrument name validation?

[pellared]

@reyang, can you please take a look at this issue as I see that the instrument name validation was added as part of #1557?

[MrAlias]

I don't know if we can be more restrictive with the meter name and remain backwards compatible.

[pellared]

I don't know if we can be more restrictive with the meter name and remain backwards compatible.

It would be ABI backwards compatible as the API surface remains the same, but NOT behavioral backwards compatible as these are behavioral changes.

[MrAlias]

I don't know if we can be more restrictive with the meter name and remain backwards compatible.

It would be ABI backwards compatible as the API surface remains the same, but NOT behavioral backwards compatible as these are behavioral changes.

Right. I worry that a user that is currently using OTel will upgrade and instead of continuing to work their system starts erroring and not functioning. If we do decide to change the validation, I think the most we could do as a response would be to add log messages describing the error.

[jack-berg]

Meter name manifests as scope name in the data model, and is akin to tracer name and logger name. For consistency, I think its important that the rules for scope name are the same across the signals.

I can't find anything in the data model that that suggests any limits around the characters or length of a scope name. Adding limits retroactively would definitely be a breaking change.

I get the argument that we could add rules and log when they're violated rather than erroring, but I see this is a prometheus exporter specific problem and not something that should influence tracer, meter, and logger more broadly. The crux is that OTLP to prometheus spec describes insufficient rules for mapping instrumentation scope to prometheus info-typed metrics. It appears that OpenTelemetry scopes have less constraints in terms of their allowable characters (and probably their length) than info typed metrics. Let's fix that problem rather than the much more disruptive and arguably breaking change of adjusting the rules of instrumentation scope.