[EXPORTER] Export resource for prometheus

[owent]

Fixes #1842

Changes

• Prometheus exporter emits resource attributes
• Fix incorrect address point in unit test of prometheus utils.

Follow https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/compatibility/prometheus_and_openmetrics.md#resource-attributes-1

For significant contributions please make sure you have completed the following items:

• CHANGELOG.md updated for non-trivial changes
• Unit tests have been added
• Changes in public API reviewed

[codecov]

Codecov Report

Merging #2301 (0149d5c) into main (0803e6a) will increase coverage by 0.02%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main    #2301      +/-   ##
==========================================
+ Coverage   87.39%   87.41%   +0.02%     
==========================================
  Files         199      199              
  Lines        6009     6018       +9     
==========================================
+ Hits         5251     5260       +9     
  Misses        758      758              

Files	Coverage Δ
...opentelemetry/sdk/metrics/export/metric_producer.h	100.00% <100.00%> (ø)

[lalitb]

Going through this link: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/compatibility/prometheus_and_openmetrics.md#resource-attributes-1, it states:

In SDK Prometheus (pull) exporters, resource attributes SHOULD be converted to a single [target_info metric](https://github.com/OpenObservability/OpenMetrics/blob/main/specification/OpenMetrics.md#supporting-target-metadata-in-both-push-based-and-pull-based-systems); otherwise, they MUST be dropped, and MUST NOT be attached as labels to other metric families. The target_info metric MUST be an info-typed metric whose labels MUST include the resource attributes, and MUST NOT include any other labels. There MUST be at most one target_info metric exposed on an SDK Prometheus endpoint.

It states that resource attributes should be converted into a separate target_info metrics, or else dropped. I don't see we are doing it here.

[owent]

Going through this link: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/compatibility/prometheus_and_openmetrics.md#resource-attributes-1, it states:

In SDK Prometheus (pull) exporters, resource attributes SHOULD be converted to a single [target_info metric](https://github.com/OpenObservability/OpenMetrics/blob/main/specification/OpenMetrics.md#supporting-target-metadata-in-both-push-based-and-pull-based-systems); otherwise, they MUST be dropped, and MUST NOT be attached as labels to other metric families. The target_info metric MUST be an info-typed metric whose labels MUST include the resource attributes, and MUST NOT include any other labels. There MUST be at most one target_info metric exposed on an SDK Prometheus endpoint.

It states that resource attributes should be converted into a separate target_info metrics, or else dropped. I don't see we are doing it here.

Sorry, I had some misunderstanding before. Could you please reviews the codes again and please let me know if there is any problem.

[dashpole]

We can open a follow-up issue to cache target_info so it doesn't need to be recomputed each scrape.

[lalitb]

Nicely done. Thanks for the PR.

[lalitb]

Not related to this PR, but there is possibility of precision loss while casting from int64_t to double for larger values ( > 2^52) of sum. Good to have a issue to track this (I will create one) - to check for any such loss and log a warning. No changes required in this PR.

[owent]

Thanks, I add this static cast because it will trigger a warning with clang 16 and -Werror will make it a error.
BTW:Do you think think it may have epsilon problem in the code metric->histogram.sample_count = static_cast<std::uint64_t>(values[1]); in PrometheusExporterUtils::SetValue ?

[lalitb]

@owent Can you please resolve the conflict, probably one last change to merge this :)

[owent]

I'm on holiday these days. sorry for the delay.

[owent]

@owent Can you please resolve the conflict, probably one last change to merge this :)

Done

[marcalff]

Small question on label reserve(size) or size +2.

[marcalff]

LGTM, thanks for the fix.