Migrate prometheus exporter to otlptranslator

[dashpole]

Fixes #7039
Fixes #6704

This uses the common prometheus/otlptranslator library to handle name conversion. It was a little tricky to work around the fact that the library only lets us configure whether all suffixes are added or not. But we want to keep supporting WithoutUnit and WithoutCounterSuffixes for a while longer. Those will eventually be deprecated and replaced after open-telemetry/opentelemetry-specification#4533 is released.

We decided to go ahead with the changes despite it being a small behavioral change when UTF8 is enabled. See: prometheus/otlptranslator#44 for the rationale.

This adds a unit test to verify that it properly handles bracketed units. The test fails on main with:

--- FAIL: TestPrometheusExporter (0.01s)
    --- FAIL: TestPrometheusExporter/counter_with_bracketed_unit (0.00s)
        exporter_test.go:646:
            	Error Trace:	/usr/local/google/home/dashpole/go/src/go.opentelemetry.io/opentelemetry-go/exporters/prometheus/exporter_test.go:646
            	Error:      	Received unexpected error:
            	            	-# HELP "foo_{spans}_total" a simple counter
            	            	-# TYPE "foo_{spans}_total" counter
            	            	-{"foo_{spans}_total",A="B",C="D",E="true",F="42",otel_scope_fizz="buzz",otel_scope_name="testmeter",otel_scope_schema_url="",otel_scope_version="v0.1.0"} 24.3
            	            	-{"foo_{spans}_total",A="D",C="B",E="true",F="42",otel_scope_fizz="buzz",otel_scope_name="testmeter",otel_scope_schema_url="",otel_scope_version="v0.1.0"} 5
            	            	+# HELP foo_total a simple counter
            	            	+# TYPE foo_total counter
            	            	+foo_total{A="B",C="D",E="true",F="42",otel_scope_fizz="buzz",otel_scope_name="testmeter",otel_scope_schema_url="",otel_scope_version="v0.1.0"} 24.3
            	            	+foo_total{A="D",C="B",E="true",F="42",otel_scope_fizz="buzz",otel_scope_name="testmeter",otel_scope_schema_url="",otel_scope_version="v0.1.0"} 5
            	            	 # HELP target_info Target metadata
            	            	 # TYPE target_info gauge
            	            	 target_info{"service.name"="prometheus_test","telemetry.sdk.language"="go","telemetry.sdk.name"="opentelemetry","telemetry.sdk.version"="latest"} 1

            	Test:       	TestPrometheusExporter/counter_with_bracketed_unit
2025/07/18 15:07:47 internal_logging.go:50: "msg"="Using existing type definition." "error"="instrument type conflict" "instrument"="foo_total" "existing"="COUNTER" "dropped"="GAUGE"
2025/07/18 15:07:47 internal_logging.go:50: "msg"="Using existing type definition." "error"="instrument type conflict" "instrument"="foo_bytes" "existing"="GAUGE" "dropped"="HISTOGRAM"
FAIL
FAIL	go.opentelemetry.io/otel/exporters/prometheus	0.054s
FAIL

cc @TylerHelmuth @ywwg @ArthurSens

[ArthurSens]

TODO:

• Fix the otlptranslator's handling of suffixes that already exist when utf8 is allowed. This is the cause of unit test failures. Tracked in Duplicate type or unit suffixes when uff8 is allowed prometheus/otlptranslator#44

When creating new metrics with OTel-Go-SDK, I don't expect people to add unit/type suffixes manually. So, to increase performance, we decided not to deduplicate suffixes in this code path.

Did I have the wrong expectations? If people prefer Prometheus' ways of doing things, I expected they would use Prometheus SDK instead of OTel's.

[dashpole]

We can tell people who are relying on the suffix deduplication to disable suffixes and add them themselves if they want. I'll remove those test cases

[codecov]

Codecov Report

Attention: Patch coverage is 95.12195% with 4 lines in your changes missing coverage. Please review.

Project coverage is 82.8%. Comparing base (f6b5fb9) to head (500fe37).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
exporters/prometheus/exporter.go	95.1%	4 Missing ⚠️

Additional details and impacted files

@@          Coverage Diff          @@
##            main   #7044   +/-   ##
=====================================
  Coverage   82.8%   82.8%           
=====================================
  Files        261     261           
  Lines      24361   24371   +10     
=====================================
+ Hits       20173   20201   +28     
+ Misses      3813    3795   -18     
  Partials     375     375           

Files with missing lines	Coverage Δ
exporters/prometheus/config.go	100.0% <ø> (+7.2%)	⬆️
exporters/prometheus/exporter.go	85.7% <95.1%> (+3.3%)	⬆️

... and 2 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[dashpole]

Thanks everyone! This is ready for review.

[ArthurSens]

It would be nice to test this in the collector. I expect that the instrumented metrics don't have unit/type suffixes in their names (which would cause that duplicated suffix problem), but I haven't checked yet

[pellared]

@dashpole, should this PR be blocked by:

1. Retract most recent prometheus exporter release #7046,
2. AND a "patch release" of the Prometheus exporter module?

[dashpole]

@pellared do you think it is OK to include this PR in a patch release? Otherwise, I can open a revert PR for the offending change, rather than fix it this way

[dashpole]

I would prefer including this PR in the patch release

[MrAlias]

+1 for merging this and including in the patch release. If it is not included that patch release itself needs to be retracted and that is not the original plan.

[dfawley]

@dashpole - Is this the same process that is followed for other languages when exporting to prometheus? Since this was a behavior change, and it broke grpc-go, I'm wondering if it will impact grpc-java/c++/etc, or if they are already doing something to avoid the translation.

[dashpole]

This won't impact other languages @dfawley

[dfawley]

Sorry if it wasn't clear, but my question is whether this is the same behavior that other languages have. But also it seems like we were using the library incorrectly by not including braces around our non-standard units, and if we had done so we would not have been broken. So perhaps the question is moot.

[dashpole]

It should be the same behavior across languages. If you find that it isn't, let me know and i'll make sure it gets fixed. Sorry for any breakage this caused!