Add new option DisableAppendingUnitName in order to avoid appending the unit name in the metric name

[Gpower2]

Fixes #
This PR is adding a new option named "DisableAppendingUnitName" in the PrometheusAspNetCoreOptions and the PrometheusExporterOptions classes, in order to support the creation of metric names without appending the unit name.
This is very useful for migrating existing implementations that use prometheus-net to the opentelemetry-dotnet as a drop-in replacement.
I believe that Go exporter already has the same functionality but this is missing from the dotnet exporter.
I know that this adds a new option in the public API, but I believe that it will help a lot with migrating from prometheus-net for a lot of projects as already mentioned.

Changes

• Added DisableAppendingUnitName in PrometheusAspNetCoreOptions
• Added DisableAppendingUnitName in PrometheusExporterOptions
• Updated OpenTelemetry.Exporter.Prometheus.AspNetCore/.publicApi/PublicAPI.Unshipped.txt
• Updated OpenTelemetry.Exporter.Prometheus.HttpListener/.publicApi/PublicAPI.Unshipped.txt

Merge requirement checklist

• CONTRIBUTING guidelines followed (license requirements, nullable enabled, static analysis, etc.)
• Unit tests added/updated
• Appropriate CHANGELOG.md files updated for non-trivial changes
• Changes in public API reviewed (if applicable)

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: Gpower2 / name: Arslanoglou Georgios (623d32c)

[TimothyMothra]

Default value is false, so there should be no breaking change for existing users.

Still, we're very hesitant to make changes to the public api.
What does the OpenTelemetry specification say about appending unit names?

[Gpower2]

Default value is false, so there should be no breaking change for existing users.

Still, we're very hesitant to make changes to the public api. What does the OpenTelemetry specification say about appending unit names?

Thank you for your feedback!

I understand the hesitation, still, there is already a similar option in the public api to disable appending the Total for the counters (DisableTotalNameSuffixForCounters), so this change is in accordance to the existing public API and the benefits of having this option would be great for migrating existing apps from prometheus-net, which is a very popular and commonly used library.

Regarding the OpenTelemetry specification, correct me if I'm wrong, it doesn't specifically mention that the unit name MUST be present, but IF present, that it MUST be converted to the unit of the OTLP metric.

https://opentelemetry.io/docs/specs/otel/compatibility/prometheus_and_openmetrics/

So, based on the above reference, I believe that we don't break the specification here, since we are simply controlling if the unit name is present or not, which I don't see that is strictly required in the specification.

Again, this is my understanding of the specification, feel free to correct me or point me to another section of the specification 🙏

Last but not least, this change was driven out of need, since I am currently trying to migrate to OpenTelemetry metrics from prometheus-net, and with the current implementation of the api, all the Grafana dashboards would break.

Thank you very much checking this in any case!

[alanwest]

I do not see anything in the spec that permits us to add a configuration disabling the unit suffix.

I understand the hesitation, still, there is already a similar option in the public api to disable appending the Total for the counters (DisableTotalNameSuffixForCounters)

The spec explicitly permits a configuration option for disabling the addition of the _total suffix, specifically for counters.

Exporters SHOULD provide a configuration option to disable the addition of _total suffixes.

[Kielek]

Blocking, per #6241 (review)

[Gpower2]

I do not see anything in the spec that permits us to add a configuration disabling the unit suffix.

I understand the hesitation, still, there is already a similar option in the public api to disable appending the Total for the counters (DisableTotalNameSuffixForCounters)

The spec explicitly permits a configuration option for disabling the addition of the _total suffix, specifically for counters.

Exporters SHOULD provide a configuration option to disable the addition of _total suffixes.

Thank you for the reference link, I wasn't aware of this detail...

If there is a way to add this functionality in another way, without affecting the public API, would that be acceptable?

[TimothyMothra]

Thank you for the reference link, I wasn't aware of this detail...

If there is a way to add this functionality in another way, without affecting the public API, would that be acceptable?

HI @Gpower2, I think you should open a new Feature Request Issue to discuss your problem and possible solutions.
I can't promise any immediate change, but it's a good way to gauge how many users are impacted by your issue.

I don't work with Metrics very much, but have you explored if you can use Views to rename the metrics?
https://github.com/open-telemetry/opentelemetry-dotnet/tree/main/docs/metrics/customizing-the-sdk#rename-an-instrument

[Gpower2]

Thank you for the reference link, I wasn't aware of this detail...
If there is a way to add this functionality in another way, without affecting the public API, would that be acceptable?

HI @Gpower2, I think you should open a new Feature Request Issue to discuss your problem and possible solutions. I can't promise any immediate change, but it's a good way to gauge how many users are impacted by your issue.

I don't work with Metrics very much, but have you explored if you can use Views to rename the metrics? https://github.com/open-telemetry/opentelemetry-dotnet/tree/main/docs/metrics/customizing-the-sdk#rename-an-instrument

Thank you very much about the hint for the Views, this could be a workaround from what I gather, though I am not sure if this would affect the overall performance, definitely worth checking it out!

Regarding the Feature Request, could you give me a link or guide on where and how to open it? 🙏

[TimothyMothra]

Thank you very much about the hint for the Views, this could be a workaround from what I gather, though I am not sure if this would affect the overall performance, definitely worth checking it out!

Regarding the Feature Request, could you give me a link or guide on where and how to open it? 🙏

Here's how you can open a Feature Request (screenshot).
However, you should test the Views first and determine if that meets your needs.
I want to set your expectations that if an existing feature can meet your needs, there's a very high bar for taking any new change.

[github-actions]

This PR was marked stale due to lack of activity and will be closed in 7 days. Commenting or pushing will instruct the bot to automatically remove the label. This bot runs once per day.