Update Prometheus client to 1.5.0

[zeitlinger]

Summary

Simplified replacement for #7588 - updates the Prometheus client from 1.3.10 to 1.5.0 without adding a UTF-8 support flag.

In Prometheus client 1.4.x+, sanitizeMetricName and sanitizeLabelName no longer convert non-standard characters (dots, dashes, non-ASCII) to underscores, since the client now supports UTF-8 natively. To maintain backward-compatible behavior, prometheusName() is called first to convert names to legacy Prometheus format before sanitization.

Changes:

• Bump prometheusServerVersion from 1.3.10 to 1.5.0
• Add prometheusName() calls for metric names and label names to preserve legacy escaping
• Use stable Metrics class from io.prometheus.metrics.expositionformats.generated.Metrics instead of versioned protobuf package (new in 1.5.0, see Add stable Metrics class to decouple consumers from protobuf version prometheus/client_java#1873)
• Add @SuppressWarnings("NonCanonicalType") — the stable Metrics class extends the versioned protobuf-generated class, so Error Prone flags inner type references as non-canonical

Test plan

• All existing prometheus exporter tests pass (129 tests)
• MetricReaderFactoryTest in sdk-extensions/incubator passes

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.31%. Comparing base (297832a) to head (3815925).

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #8080      +/-   ##
============================================
- Coverage     90.31%   90.31%   -0.01%     
  Complexity     7606     7606              
============================================
  Files           839      839              
  Lines         22888    22889       +1     
  Branches       2283     2283              
============================================
  Hits          20672    20672              
  Misses         1506     1506              
- Partials        710      711       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

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

[jack-berg]

@zeitlinger when I look into the code I see prometheusName calls escapeName(String, EscapingScheme), where EscapingScheme is an enum with values: ALLOW_UTF8, UNDERSCORE_ESCAPING, DOTS_ESCAPING, VALUE_ENCODING_ESCAPING

And I've seen some hints in the code that the metric and attribute name escaping is influenced by headers requested by the client. Do we need to escape at all or will prometheus do we want by default?

Also, we've had offline conversations about the prometheus client library automatically appending suffixes like _total and units, and not providing an opt out mechanism, which makes it problematic for us in opentelemetry-java to implement the translation strategy option. Want to confirm this is still the case with this new version. Seems a bit strange that prometheus would have facilities to produce a full unescaped utf8 metric name but still always produces metric names with the suffixes.

[zeitlinger]

Escaping: You're right that the escaping scheme is normally determined at scrape time based on the Accept header (EscapingScheme.fromAcceptHeader()). By calling prometheusName() here, we're pre-escaping to underscores at snapshot creation time, so even if a scraper requests escaping=allow-utf-8, it would still get underscore-escaped names.

This is intentional for this PR — the goal is just to maintain backward-compatible behavior after the 1.5.0 upgrade (where sanitizeMetricName/sanitizeLabelName no longer do underscore escaping themselves). UTF-8 support will be unlocked by implementing the translation strategy option, which controls whether names are escaped to legacy format or kept as-is.

Suffixes: Yes, the Prometheus client still hardcodes _total in the text format writer for CounterSnapshot with no opt-out. Unit suffixes are already handled by the OTel exporter itself (in convertMetadata), so those aren't a problem. The _total suffix is the blocker for the translation strategy option (prometheus/client_java#1555). The plan is to add a disableSuffixAppending flag as part of experimental OpenMetrics 2.0 support (prometheus/client_java#1912), which will also unblock the OTel translation strategies.

[jack-berg]

Makes sense. I'll leave this unresolved so I can find it easier when we come back to the translation strategy work.