Initial Prometheus <-> OTLP datamodel specification.

[dashpole]

This supersedes #2017, and is meant to capture the current state of prometheus support in prometheus SDK exporters and prometheus collector receivers/exporters, rather than the desired end state. This is done to avoid (potentially) contentious debates in the initial draft, and allow tackling these topics individually.

There are a number of changes we will likely want to make after this:

• Handling currently unsupported types (StateSet, Info, GaugeHistogram, ExponentialHistogram)
• Converting OTel resources to something in prometheus

[alolita]

Nit: Prometheus should be consistently capitalized.

[dashpole]

Nit: Prometheus should be consistently capitalized.

Done

[bogdandrutu]

@dashpole not sure if prometheus let users set their "job" in the metrics source, but if that is the case probably the library sdk prom exporter should convert "service.name" to "job". Also a separate PR is fine.

[dashpole]

not sure if prometheus let users set their "job" in the metrics source, but if that is the case probably the library sdk prom exporter should convert "service.name" to "job".

It is possible to set "job" in the metrics source, but by default it will be overwritten by service discovery. honor_labels in the prom scrape config allows you to override this, but it is generally intended for use with a federated prom endpoint, rather than an application endpoint. I'll plan to address this when addressing #1782 in a follow-up.

[MrAlias]

The conversions statements here are not made using the normative language conventions this specification is defined to use. Can we update these statements to make clear requirements and recommendations about these conversions?

[dashpole]

Can we update these statements to make clear requirements and recommendations about these conversions?

Done.

[carlosalberto]

This looks like it's ready to go. Please confirm there's no blocker at this moment @brian-brazil @legendecas @anuraaga @jmacd

[legendecas]

👍nice works!