opentelemetry-collector-contrib
opentelemetry-collector-contrib copied to clipboard
[prometheusreceiver] Fix metrics being grouped into the same metrics family incorrectly
Description: <Describe what has changed.> Fix metrics being grouped into the same metrics family incorrectly
Link to tracking Issue: <Issue number if applicable> Fixes #13117
Testing: <Describe what testing was performed and which tests were added.> UT
Documentation: <Describe the documentation added.> n/a
This PR was marked stale due to lack of activity. It will be closed in 14 days.
@Aneurysm9 could you please comment?
@dashpole please do a final review and add the ready to merge label after.
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
Thanks @dashpole , do we have any prometheus issue being tracked for this currently?
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 (
foowithfoo,foo_totalwithfoo_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.
@codeboten @Aneurysm9 could you please review this PR?