Refactor: determine metrics data kind from data_points class instead of instrument_kind

[xuan-cao-swi]

A key challenge in implementing exponential histograms is that the data_points class used to represent them differs from the instrument_kind. Since there is no dedicated API like create_exponential_histogram, exponential histograms are instead created using the generic create_histogram function, followed by applying a view with exponential_histogram aggregation. As a result, both explicit_histogram and exponential_histogram instruments share the same instrument_kind value: histogram.

This creates ambiguity in the current as_otlp_metrics implementation, which must distinguish between explicit and exponential histograms to correctly map to the appropriate protobuf types: HistogramDataPoint or ExponentialHistogramDataPoint.

This issue could become more prominent when users heavily rely on views to modify aggregations.

Additionally, the way otel-python uses the data_points class to encode trace data (as seen in the _encode_metric function) might be better addressed as part of a broader refactoring effort.

[akahn]

Since there is no dedicated API like create_exponential_histogram, exponential histograms are instead created using the generic create_histogram function, followed by applying a view with exponential_histogram aggregation

Is the former not allowed by the spec? The current method, using a view, is rather oblique and must be ordered correctly, so it's error prone as well. I would love a clearer, more direct API for using exponential histograms.

[github-actions[bot]]

👋 This issue has been marked as stale because it has been open with no activity. You can: comment on the issue or remove the stale label to hold stale off for a while, add the keep label to hold stale off permanently, or do nothing. If you do nothing this issue will be closed eventually by the stale bot.

[kaylareopelle]

Hi @akahn, great point. I asked about this in the CNCF Slack on #otel-specification.

TL;DR I think it is currently not allowed in the spec, but I don't think it always has to be that way.

The response was:

Our intention at the time was to eventually get exponential histograms to be the default. I believe the "advice" API was intended to provide this capability in the API

We're missing (and should add) an advisory parameter for "Exponential Histograms" - https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/api.md#instrument-advisory-parameters

We have a PRs to add advisory parameters (https://github.com/open-telemetry/opentelemetry-ruby/pull/1801, https://github.com/open-telemetry/opentelemetry-ruby/pull/1703), but there isn't a specification PR open at the moment to add an exponential histogram parameter.

Next week, I can go to the developer experience SIG and raise this concern to see how users of other implementations are currently dealing with this limitation.