Prometheus compatibility

[jack-berg]

Includes resource attribute in target_info metric. Previously attempted in #4569. This has been discussed in the spec and by the prometheus WG and the spec is unambiguous. We really need to get this behavior implemented.

• Resolves Prometheus Exporters do not interact with Resource attributes #4046
• Resolves Prometheus exporter resource attributes #4552

Example:

# TYPE target info
# HELP target Target metadata
target_info{service_name=\"my-application\"} 1

Serialize scope as otel_scope_info metric. Include scope name and version attributes on each metric to disambiguate from metrics with the same name in different scopes. Related to #5014, but doesn't solve the collision issue.

Example:

# TYPE otel_scope_info info"
# HELP otel_scope_info Scope metadat"
otel_scope_info{otel_scope_name=\"grpc\",otel_scope_version=\"1.0.0\"} 1
# TYPE grpc_name_total counter"
# HELP grpc_name_total long_description"
grpc_name_total{otel_scope_name=\"grpc\",otel_scope_version=\"version\",kp=\"vp\"} 5.0 0

Includes a new PrometheusHttpServerIntegrationTest to demonstrate the behavior end to end from: SDK -> collector prometheus receiver -> collector OTLP exporter -> mock OTLP server.

Our prometheus exporter is really starting to fall behind the spec. This PR is the first of a couple needed to get it back on course.

[mateuszrzeszutek]

It's pretty confusing that we have both service.name from scraping (and it contains a dot - shouldn't that be converted to an underscore?) and service_name from the resource. Well, nothing we can do about that in this PR.

[jack-berg]

service.name comes from job_name that produced the scrape in the promtheus receiver config. service_name comes from the attributes of the target_info metric from the app's prometheus exporter.

I agree it's confusing. Best case would be for the prometheus receiver to recognize that a target_info is present, try to reverse the attribute key transformation based on semantic conventions (i.e. transform service_name back to service.name), and prioritize the attributes from target_info over those generated from the job config.

[codecov]

Codecov Report

Base: 91.19% // Head: 91.23% // Increases project coverage by +0.04% 🎉

Coverage data is based on head (0dc1037) compared to base (9dfb002).
Patch coverage: 98.43% of modified lines in pull request are covered.

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #5039      +/-   ##
============================================
+ Coverage     91.19%   91.23%   +0.04%     
- Complexity     4877     4883       +6     
============================================
  Files           553      553              
  Lines         14402    14449      +47     
  Branches       1375     1379       +4     
============================================
+ Hits          13134    13183      +49     
+ Misses          879      878       -1     
+ Partials        389      388       -1     

Impacted Files	Coverage Δ
.../opentelemetry/exporter/prometheus/Serializer.java	88.33% <98.43%> (+2.32%)	⬆️
...metry/sdk/metrics/export/PeriodicMetricReader.java	90.00% <0.00%> (+2.85%)	⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.