You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Recently upgraded to Opentelemetry-cpp v1.12.0 and noticed some difference in how the OTLP Exporter exports Counters/UpDownCounters. In the previous version (v1.9.0) I was using, all observable Counters/UpDownCounters were exported with the is_monotonic flag set to true. As a result, the Prometheus exporter in the Opentelemetry Collector Contrib mapped the OTEL Counters/UpDownCounters to Prometheus Counters. Issue #2170 changed the behavior to only set the monotonic flag for kCounter. As a result, in v1.12.0, only the synchronous Counter is mapped to the Prometheus Counter type by the Collector; synchronous UpDownCounter and observable Counter/UpDownCounters are mapped to Prometheus Gauge type.
My question is, shouldn't observable Counters be mapped to Prometheus Counter type? For that to happen, we would need to set the is_monotonic flag for both kCounter and kObservableCounter. According to the official spec, if the aggregation temporality is cumulative and the sum is monotonic, it MUST be converted to a Prometheus Counter.
Also, for reference, seems like the Python SDK exports observable Counters with the is_monotonic flag set as the Prometheus endpoint shows the instrument type as a Counter instead of a Gauge.
The text was updated successfully, but these errors were encountered:
@samin36 your analysis is correct. Both Counter and ObservableCounter should have the is_monotonic flag as true. Do you want to raise a PR for the fix?
Recently upgraded to Opentelemetry-cpp v1.12.0 and noticed some difference in how the OTLP Exporter exports Counters/UpDownCounters. In the previous version (v1.9.0) I was using, all observable Counters/UpDownCounters were exported with the
is_monotonic
flag set totrue
. As a result, the Prometheus exporter in the Opentelemetry Collector Contrib mapped the OTEL Counters/UpDownCounters to Prometheus Counters. Issue #2170 changed the behavior to only set the monotonic flag forkCounter
. As a result, in v1.12.0, only the synchronous Counter is mapped to the Prometheus Counter type by the Collector; synchronous UpDownCounter and observable Counter/UpDownCounters are mapped to Prometheus Gauge type.My question is, shouldn't observable Counters be mapped to Prometheus Counter type? For that to happen, we would need to set the
is_monotonic
flag for bothkCounter
andkObservableCounter
. According to the official spec, if the aggregation temporality is cumulative and the sum is monotonic, it MUST be converted to a Prometheus Counter.Also, for reference, seems like the Python SDK exports observable Counters with the
is_monotonic
flag set as the Prometheus endpoint shows the instrument type as a Counter instead of a Gauge.The text was updated successfully, but these errors were encountered: