Prometheus exporter: Stabilize config option scope_info_enabled

[ArthurSens]

Fixes #4989

Changes

Stabilizes the configuration option without_scope_info, documented in the Prometheus exporter spec. It is implemented by a few SDKs already #4989 (comment), an open PR for Python(open-telemetry/opentelemetry-python#5123), and an issue for DotNet(open-telemetry/opentelemetry-dotnet#7157). Both prometheus exporters in the collector have the option as well[1][2] (Although remote write exporter uses disable_scope_info instead of without_scope_info.

For non-trivial changes, follow the change proposal process.

• Related issues Stabilize Prometheus Metrics Exporter spec: Scope Info configuration #4989
• Related OTEP(s) #
• Links to the prototypes (when adding or changing features)
• CHANGELOG.md file updated for non-trivial changes
  • For trivial changes, include [chore] in the PR title to skip the changelog check
• Spec compliance matrix updated if necessary
• Declarative config data model is updated if SDK config surface is changed

[dashpole]

the _info suffix is a relic of the otel_scope_info metric we used to have. But it doesn't seem worth it to change it now.

[jack-berg]

Hey I want us to consider changing the names of a few of these prometheus exporter property names before stabilizing.

I think the whole with_ prefix pattern is weird. Not sure where that came about but we don't see that anywhere else in SDK component config properties.

I think the use of "without" without_scope_info / without_target_info with a default value of false was probably inspired by the "All Boolean environment variables SHOULD be named and defined such that false is the expected safe default behavior." language that we decided is not applicable to other configuration interfaces: #4723

So since there's no env vars for without_scope_info / without_target_info, we don't need to be constrained by that.

I propose these names, which I find more consistent with property naming elsewhere in the project and more intuitive:

• without_scope_info -> scope_info_enabled (default true)
• without_target_info -> target_info_enabled (default true)
• with_resource_constant_labels -> resource_constant_labels (default none are added)

[dashpole]

True. I think the pattern probably came from Go. The prefix should be removed.

Lets update the names

[jack-berg]

True. I think the pattern probably came from Go. The prefix should be removed.

I'll open a PR to adjust the parameter names today

[ArthurSens]

I don't have any problems with changing the configuration option. Most existing implementations are already using the "without" wording, though. Including the Collector, which has a HUGE user base.

I totally understand that the spec says MAY, so implementors don't need to follow the wording to the letter, but it feels inconsistent to me that the spec suggests one thing and most implementors use another.

[jack-berg]

#5071

A change in the spec property name doesn't stop an implementation from using the function options with pattern. See how opentelemetry-go OTLP exporters use with* for all the OTLP property options.

I see that the collector prometheus exporter does include a without_scope_info. The codeowners will need to navigate what to do about that. My 2p is that name is inconsistent. If without_scope_info, why send_timestamps vs with_timestamps, const_labels vs. with_const_labels, translation_strategy vs. with_translation_strategy? Naming is hard.

[ArthurSens]

Yeah, no strong opinions here. If the group prefers rewording the config, I'll be happy to do it; I just wanted to reinforce that current implementors are all using different names.

[cijothomas]

Checking if we have met usual requirement of 2-3 sdk implementations before stabilizing?
If needed, I can help get OTel Rust to implement this, if that helps. (Or if this was already covered, no issues!)

[ArthurSens]

Checking if we have met usual requirement of 2-3 sdk implementations before stabilizing? If needed, I can help get OTel Rust to implement this, if that helps. (Or if this was already covered, no issues!)

We have, so far, 1) Collector's Prometheus exporter, 2) Collector's Prometheus Remote Write exporter, 3) OTel Go SDK, 4) OTel Java SDK.

Then open PRs for Python and Rust.

[cijothomas]

Checking if we have met usual requirement of 2-3 sdk implementations before stabilizing? If needed, I can help get OTel Rust to implement this, if that helps. (Or if this was already covered, no issues!)

We have, so far, 1) Collector's Prometheus exporter, 2) Collector's Prometheus Remote Write exporter, 3) OTel Go SDK, 4) OTel Java SDK.

Then open PRs for Python and Rust.

Thanks for confirming. The new names are not yet reflected in those implementations, but we haven't released spec with that changes yet!

[cijothomas]

LGTM.
A minor non-blocker - the recent rename of the option is not yet implemented in the languages(in flight in some). It won't hurt to wait till that happens before merging this.