Skip to content

Conversation

zeitlinger
Copy link
Member

@zeitlinger zeitlinger commented Aug 18, 2025

To avoid a breaking change

@zeitlinger zeitlinger requested a review from a team as a code owner August 18, 2025 17:05
@zeitlinger zeitlinger self-assigned this Aug 18, 2025
@jkwatson jkwatson added the blocked:spec blocked on open or unresolved spec label Aug 19, 2025
Copy link

codecov bot commented Aug 27, 2025

Codecov Report

❌ Patch coverage is 94.73684% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 89.98%. Comparing base (63d4617) to head (4c214e3).
⚠️ Report is 2 commits behind head on main.

Files with missing lines Patch % Lines
...ry/exporter/prometheus/PrometheusMetricReader.java 66.66% 1 Missing ⚠️
Additional details and impacted files
@@             Coverage Diff              @@
##               main    #7588      +/-   ##
============================================
- Coverage     89.99%   89.98%   -0.01%     
- Complexity     7079     7081       +2     
============================================
  Files           803      803              
  Lines         21412    21428      +16     
  Branches       2086     2087       +1     
============================================
+ Hits          19269    19282      +13     
- Misses         1479     1482       +3     
  Partials        664      664              

☔ 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.

@zeitlinger
Copy link
Member Author

@jkwatson please have a look

}

prometheusBuilder.setUtf8SupportEnabled(
config.getBoolean("otel.exporter.prometheus.utf8", false));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this the official property? I thought no new properties were being added to the spec?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That doesn't answer my question... if we're adding new configuration properties, I'd like to make sure they're "official" in the spec, and we're not going off on our own, especially as there has been a moratorium set on the new configuration properties/env vars in the spec (at least, the last I heard).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it 😄

This is the part in the Go SDK: https://github.com/open-telemetry/opentelemetry-go/blob/d0cab8666b740c975f028236610cab2663f02031/exporters/prometheus/config.go#L44-L66

@ArthurSens it seems there is no env var to set the translation strategy - is that missing?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

// Resource attributes from the metric SDK resource translated to target_info
stringKeyValue(
"service_name",
"service.name",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why did these keys change, when we haven't explicitly changed the exporter?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I set UTF-8 to true in most tests - including here

@jkwatson
Copy link
Contributor

jkwatson commented Sep 1, 2025

no longer blocked by the spec?

@zeitlinger
Copy link
Member Author

no longer blocked by the spec?

We talked in the spec meeting that it's up to the SDKs to decide if __ should be converted to _ or not.

So from that point of view, we're free to keep __ as is.
However, I didn't want to introduce a breaking change (which is also SDK decision) - so I added a setting to enable UTF-8.

If

  • otel.exporter.prometheus.utf8 is false, we shorten __ to _ (and %% becomes __ and then _)
  • otel.exporter.prometheus.utf8 is true, the SDK passes all chars as is to the prom client - expecting that the user wants to keep that as is in the entire pipeline

We can decide that we're OK with the breaking change - and then we don't need this property.

@zeitlinger zeitlinger changed the title Update prom client Update prom client with support for UTF-8 Sep 5, 2025
@zeitlinger zeitlinger marked this pull request as draft September 5, 2025 08:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocked:spec blocked on open or unresolved spec
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants