[prometheusreceiver] Fix metrics being grouped into the same metrics family incorrectly

[newly12]

Description:
Fix metrics being grouped into the same metrics family incorrectly

Link to tracking Issue:
Fixes #13117

Testing:
UT

Documentation:
n/a

[dashpole]

Overall, I think this is a less bad thing to do.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 14 days.

[newly12]

@Aneurysm9 could you please comment?

[bogdandrutu]

@dashpole please do a final review and add the ready to merge label after.

[dashpole]

I think we should wait on this. I was able to discuss this at the prom wg yesterday (notes), and we concluded that we should see if it is possible for the appender to know if the metrics came from OpenMetrics or from Prometheus

[codeboten]

I think we should wait on this. I was able to discuss this at the prom wg yesterday (#13117 (comment)), and we concluded that we should see if it is possible for the appender to know if the metrics came from OpenMetrics or from Prometheus

@dashpole do you want to add a request for change until this is unblocked?

[dashpole]

lets see if we can get a feature in upstream promethetheus that lets us know if the scrape was openmetrics or prometheus

[newly12]

Thanks @dashpole , do we have any prometheus issue being tracked for this currently?

[dashpole]

While writing up the issue, i've realized that knowing openmetrics vs prometheus won't help us. I was going to write:

The OpenTelemetry collector's prometheus receiver is implemented as an Appender. One issue we currently have is that we don't know how to correctly associate metric points with type (or other) comments. For example, with the Prometheus metrics:

# TYPE foo gauge
foo{} 1
# TYPE foo_total counter
foo_total{} 1

Each metric point should be associated with the metric family of the same name (foo with foo, foo_total with foo_total)

However, with the OpenMetrics metrics:

# TYPE foo counter
foo_total{} 1
# TYPE foo_total gauge
foo_total{} 1

We want to associate the metrics with the counter, rather than the gauge.

But then I read in the OpenMetrics spec:

The name of a MetricFamily MUST NOT result in a potential clash for sample metric names as per the ABNF with another MetricFamily in the Text Format within a MetricSet. An example would be a gauge called "foo_created" as a counter called "foo" could create a "foo_created" in the text format.

So the OpenMetrics example above is invalid. In that case, I think it is correct for us to accept this PR.

[newly12]

@codeboten @Aneurysm9 could you please review this PR?