prometheus / prometheus/client_java

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

オープン 初心者向け
#2,416 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

主要言語
Java
スター
2.3k
フォーク
833
平均マージ
2日 16時間
マージ済み PR(30日)
86

説明

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.

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

調査の方向性

prometheus-metrics-exporter-opentelemetry/src/main/java/io/prometheus/metrics/exporter/opentelemetry/otelmodel/PrometheusClassicHistogram.java から始め、toOtelDataPoint()、makeBoundaries()、makeCounts() を読みます。次に MetricDataFactory.java を追ってエントリポイントを理解します。結果として得られる HistogramPointData が有限の境界のみを持ち、counts.size() == boundaries.size() + 1 となっていることを確認します。最後のカウントは暗黙のオーバーフローバケットを表します。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
java
領域
observability
issue の種類
バグ
難易度
2/5
見積もり時間
1〜3時間
活発さ
活発
明瞭さ
明確に書かれている
初心者へのやさしさ
82/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。