OpenTelemetry bridge: classic histograms exported with +Inf boundary included, violating counts == boundaries + 1 contract

[krishna3554]

Summary

PrometheusClassicHistogram.toOtelDataPoint() converts a Prometheus classic histogram into an OpenTelemetry HistogramPointData, but it passes the Prometheus bucket boundaries including the final +Inf boundary and emits exactly one count per boundary. The OpenTelemetry data model requires counts.size() == boundaries.size() + 1, with boundaries containing only finite values (the last, +Inf bucket is implicit). The converted point therefore violates the OTel contract that downstream consumers rely on.

Static-analysis finding against current master; not executed here.

Location

• File: prometheus-metrics-exporter-opentelemetry/src/main/java/io/prometheus/metrics/exporter/opentelemetry/otelmodel/PrometheusClassicHistogram.java
• Methods: makeBoundaries(ClassicHistogramBuckets) (~lines 66-72) and makeCounts(ClassicHistogramBuckets) (~lines 74-80), called from toOtelDataPoint() (~lines 45-58).

Problem

makeBoundaries() iterates all classic buckets and appends every upper bound - for a Prometheus classic histogram the last bucket's upper bound is Double.POSITIVE_INFINITY, so +Inf ends up inside HistogramPointData.getBoundaries(). makeCounts() returns buckets.size() counts, i.e. counts.size() == boundaries.size().

Per the OTel SDK data model (io.opentelemetry.sdk.metrics.data.HistogramPointData), boundaries are the finite bucket edges and there is always one extra count for the implicit last bucket:

• getCounts().size() == getBoundaries().size() + 1
• boundaries must be finite (Double.POSITIVE_INFINITY is not a legal explicit bound; the OTLP explicit_bounds field likewise expects finite values)

Concretely, a Prometheus histogram with bounds [1, 5, +Inf] and counts [c0, c1, c2] is converted to:

• boundaries [1.0, 5.0, Infinity]
• counts [c0, c1, c2]

An OTel consumer reading this point interprets it as four buckets: [..,1], [1,5], [5,+Inf] (count c2) plus an implicit trailing (+Inf) bucket with count 0 - misrepresenting both bucket structure and totals. Anything that validates the model (or the OTLP exporter's serialization of infinite explicit bounds) will reject or distort the histogram instead of exporting it faithfully.

Trigger / Reproduction

Based on static analysis; no runtime run was performed:

• Expose any classic histogram through PrometheusMetricsExporter with the OpenTelemetry bridge enabled (MetricDataFactory line ~73 constructs PrometheusClassicHistogram whenever the snapshot has classic histogram data).
• Observe the resulting HistogramPointData: getBoundaries().contains(Double.POSITIVE_INFINITY) and getCounts().size() == getBoundaries().size().

Expected Behavior

The conversion should drop the final +Inf upper bound from boundaries and append the total observation count as the extra last element of counts (the implicit overflow bucket), e.g. boundaries [1.0, 5.0], counts [c0, c1, c0+c1+c2]. (calculateCount() already computes this sum when the snapshot lacks an explicit count.)

Actual Behavior

+Inf remains in the boundary list and no implicit-bucket count is appended, producing an out-of-contract HistogramPointData.

Impact

Every classic histogram exported through the OpenTelemetry bridge carries malformed bucket metadata: OTLP exports can fail validation or silently shift all bucket assignments, and aggregation logic built on the OTel model (e.g., heatmap rendering, downstream collectors) computes wrong distributions.

Suggested Direction

In toOtelDataPoint() (or in the two helpers), strip the trailing +Inf boundary when present and build counts as the per-boundary counts followed by the total count. Keeping the helpers symmetric (boundaries.size() == counts.size() - 1) would make the invariant locally verifiable.

Evidence

• PrometheusClassicHistogram.makeBoundaries(): unconditional buckets.getUpperBound(i) loop; ClassicHistogramBuckets snapshots from the core module always end with +Inf for classic histograms.
• MetricDataFactory.java line ~73: result is fed directly into the OTel MetricData tree consumed by the exporter pipeline.

[jaydeluca]

Based on the code paths you identified, I agree there appears to be a mismatch with the OpenTelemetry histogram representation: for (N) explicit boundaries, HistogramPointData defines (N+1) bucket counts, with the final +Inf bucket implicit.

However, I don’t think the proposed conversion of the counts is correct. ClassicHistogramBuckets stores non-cumulative counts, and its final entry is already the count for the +Inf bucket. Given:

• boundaries: [1, 5, +Inf]
• counts: [c0, c1, c2]

the corresponding OTel representation should therefore be:

• boundaries: [1, 5]
• counts: [c0, c1, c2]
• total count: c0 + c1 + c2

Replacing c2 with the total count would overcount the first two buckets when the OTel consumer sums the bucket counts.

More importantly, the report says explicitly that this is a static-analysis finding and that no runtime test was performed. Static analysis can be useful for identifying code that deserves investigation, but it is not sufficient on its own to establish that a user-visible bug exists—particularly when the report makes broad claims about exports failing, bucket assignments shifting, or downstream consumers producing incorrect results.

Were you able to reproduce an actual problem? Before we proceed with a change, we would like to see a minimal, executable reproducer demonstrating the observable failure. For example, that could be a test which creates a classic histogram and shows:

• the resulting HistogramPointData and its boundaries and counts;
• the serialized OTLP payload; and
• the specific rejection or incorrect result produced by an OTel exporter or downstream consumer.

A focused regression test would also help clarify whether the problem occurs at point construction, serialization, or consumption. We want to prioritize concrete, reproducible problems rather than conclusions derived solely from an unexecuted reading of the source.