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.
A key challenge in implementing exponential histograms is that the
data_pointsclass used to represent them differs from theinstrument_kind. Since there is no dedicated API likecreate_exponential_histogram, exponential histograms are instead created using the genericcreate_histogramfunction, followed by applying a view withexponential_histogramaggregation. As a result, bothexplicit_histogramandexponential_histograminstruments share the sameinstrument_kindvalue:histogram.This creates ambiguity in the current
as_otlp_metricsimplementation, which must distinguish between explicit and exponential histograms to correctly map to the appropriate protobuf types:HistogramDataPointorExponentialHistogramDataPoint.This issue could become more prominent when users heavily rely on views to modify aggregations.
Additionally, the way
otel-pythonuses thedata_pointsclass to encode trace data (as seen in the _encode_metric function) might be better addressed as part of a broader refactoring effort.