fix(spec/metrics): Histogram sum is optional

[krajorama]

The implemented data model has the sum as intentionally optional, see histograms, exponential histograms.

Bring the spec in line with reality.

Exporters already deal with it sometimes, it's not totally consistent.

The Prometheus remote write exporter omits the ..._sum series when sum is not present in the OTel histograms.

Other exporters and native histograms outputs set the output sum to 0 - effectively making up a value.
E.g. exponential histogram leaves the field at 0 if unset, doesn't reject the data point.

Noted in
#5125 (comment)

Questions

• Do we fix the spec as proposed here or the coded model ?
• What is the strategy for exporters if sum is unset ?
  • Drop data point ? (current thinking in Update OpenTelemetry Exponential Histogram to Prometheus Native Histogram translation #5125, I support this)
  • Drop data point if export protocol requires it, otherwise omit ?
  • Export as 0 ?
  • Export as 0 if some config is set (enabled by default, to not be breaking) otherwise always drop ?

Historical context

There was a lot of debate over the years about what to do with the sum when there are negative observations in a histogram (or summary), see prometheus/prometheus#6669 , and OpenMetrics 1.0 said that if there are negative observations in a histogram, then the sum must not be present (prometheus/OpenMetrics#193), which gave rise to optional sum. However no library actually implemented it and it's excluding legit use cases where there are negative observations. OpenMetrics 2.0 reverses curse to be more in line with implementations: prometheus/docs#2627.

In general it's unlikely that anyone actually generates histograms with sum absent, so it seems dropping such histograms is fine. If we want to be extra careful we could allow opt-in defaulting the sum to zero.

Fixes #

Changes

Please provide a brief description of the changes here.

For non-trivial changes, follow the change proposal process.

• [N/A] Related issues #
• [N/A] Related OTEP(s) #
• [N/A] Links to the prototypes (when adding or changing features)
• CHANGELOG.md file updated for non-trivial changes
  • For trivial changes, include [chore] in the PR title to skip the changelog check
• Spec compliance matrix updated if necessary
• Declarative config data model is updated if SDK config surface is changed

[opentelemetry-pr-dashboard]

Pull request dashboard status

Closed · refreshed 2026-08-24 14:39 UTC

Status above doesn't look right?

• Anything look wrong? Report it with what you expected; it helps us improve the dashboard.

[dashpole]

@open-telemetry/specs-metrics-approvers

The concern I have with this is that this would imply that SDKs need to support an optional Sum, which (from my ai-assisted audit) is only Javascript today. The other 10 metrics SDKs don't allow the sum to be unset.

But I don't think you need this to unblock your other 3 PRs. The protobuf definition is generally a superset of the data model (e.g. includes metric metadata), as confusing as that can be.

[krajorama]

@open-telemetry/specs-metrics-approvers

The concern I have with this is that this would imply that SDKs need to support an optional Sum, which (from my ai-assisted audit) is only Javascript today. The other 10 metrics SDKs don't allow the sum to be unset.

But I don't think you need this to unblock your other 3 PRs. The protobuf definition is generally a superset of the data model (e.g. includes metric metadata), as confusing as that can be.

I don't want to make this change to the spec, I don't think there's enough of a use case to justify it. So if we can avoid making the change, I'm all for it.

I guess we can just close this PR? Or do we want to get some consensus to this first?

[cijothomas]

@open-telemetry/specs-metrics-approvers

The concern I have with this is that this would imply that SDKs need to support an optional Sum, which (from my ai-assisted audit) is only Javascript today. The other 10 metrics SDKs don't allow the sum to be unset.

But I don't think you need this to unblock your other 3 PRs. The protobuf definition is generally a superset of the data model (e.g. includes metric metadata), as confusing as that can be.

OTel Rust also fabricates a  "0" sum when the sum isn't applicable. And changing that would be breaking change...

[jmacd]

Thank you for the historical note. I was aware of the original motivation for sum to be optional in the protobuf, but not the reversal. So, I take it the recommendation is that sum should be recorded, that average value will be correct.

If there was a histogram instrument defined for strictly non-negative values, that would appear to help clarify our semantics.

[jack-berg]

The protobuf definition is generally a superset of the data model (e.g. includes metric metadata), as confusing as that can be.

👍

[krajorama]

If there was a histogram instrument defined for strictly non-negative values, that would appear to help clarify our semantics.

Currently it wouldn't help much with translation to Prometheus. It's unlikely we'd introduce a new metric type for this and for a Prometheus classic histogram to be able to tell if there are negative observations you'd have to define an upper bound that's the largest representable negative number. That's because bucket upper bounds are inclusive, using 0 upper bound wouldn't work - that can mean observing 0. For native histograms it's even worse, the zero bucket is a small range around 0, so observations there can be negative/zero/positive. Maybe we should have native histograms 2.0 (with new reserved schema numbers) where the zero count is counting 0s strictly, so bucket [0, 0] and the zero threshold means the boundary of the underflow buckets: smallest int32 as index and boundaries [-threshold, 0) and (0, threshold] for negatives and positives. This fits the current representation and solves the issue of not being able to tell if there's negative observations.

[krajorama]

Closing due to #5273 (comment) and SDK impact concerns.