David Ashpole

Related: https://github.com/prometheus/prometheus/issues/15259 To fix this, we need to sanitize exemplar keys here: https://github.com/open-telemetry/opentelemetry-go/blob/99c3c661e0ec3e484f9faf7bc7aa23f8c7b7f1d6/exporters/prometheus/exporter.go#L550 We should use the same approach used for label keys: https://github.com/open-telemetry/opentelemetry-go/blob/99c3c661e0ec3e484f9faf7bc7aa23f8c7b7f1d6/exporters/prometheus/exporter.go#L335

Fix out: #5995. @StarpTech are you able to verify that it fixes your issue?

Are you able to check v1.37.0? We have had significant changes to escaping between v1.36.0 and 1.37.0. Otherwise, do you know if they are setting `model.NameValidationScheme`? Or are they leaving...

I agree with deprecating the option, and replacing with a WithPublicEndpoint option similar to otelhttp if needed

We are probably going to switch to "translation modes" to match the Prometheus server's OTLP endpoint configuration: https://github.com/open-telemetry/opentelemetry-specification/pull/4533

You can see the original issue here: https://github.com/open-telemetry/opentelemetry-cpp/issues/2316. Unless you are re-exposing metrics from another source with significantly different timestamps, you should not add them. I'm not opposed to having...

It went to beta in 0.140.0, so we should be OK to graduate to stable in v0.142.0, which is the next release

Views can only filter attributes. We do have a labeler concept in otelhttp that is similar, but I don't think that applies to runtime metrics

That is basically correct. > each metric should have at least one equal attribute with metadata metric but there are no such attributes here. `target_info` joins should be done on...

`job` and `instance` labels are added by Prometheus after scraping based on the `scrape_config` defined in your prometheus configuration