Prometheus receiver uses Deprecated attributes from old semconv version

[robincw]

Component(s)

receiver/prometheus

Is your feature request related to a problem? Please describe.

The Prometheus receiver uses semconv/v1.6.1 since 2 years ago
to add resource attributes to convert from the Prometheus to the OpenMetrics convention when scraping
but these are confusing in meaning and deprecated according to latest documentation.

In addition, there are many dependencies (alerts, dashboards, recording rules) in the world which depend on the job and instance labels in metrics but the receiver is dropping these without any option to keep them.

Describe the solution you'd like

The attributes should be updated to match the spec described here.

Dropping job and instance attributes in the receiver should be configurable so Prometheus labels can be kept in addition to the semconv labels added. Or this should not be done by receivers at all as it can be done be attribute processor.

Describe alternatives you've considered

Currently using the attributes processor to re-add the job and instance attributes, and to remove the confusing net.* attributes.

Additional context

No response

[github-actions]

Pinging code owners:

• receiver/prometheus: @Aneurysm9 @dashpole

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[robincw]

Similar issue found for mongodb receiver #32810

[dashpole]

Dropping job and instance attributes in the receiver should be configurable so Prometheus labels can be kept in addition to the semconv labels added.

Are you referring to job + instance being translated to service.name and service.instance.id? That is required by the translation specification, as service resource attributes are required to uniquely identify timeseries in OTel.

I've opened #32829 to update other attributes used

[robincw]

job + instance being translated to service.name and service.instance.id is not a problem, and required by the spec, but dropping them could be a configurable opt-out , I think? This would aid migration of downstream dependencies on the data.