Fixing the “UNSUPPORTED_METRIC_TYPE_CUMULATIVE_HISTOGRAM” Error

When integrating OpenTelemetry (OTel) metrics into Dynatrace via the OTLP endpoint, you might hit an error like this:

Errors:
Unsupported metric: 'xxx' - Reason: UNSUPPORTED_METRIC_TYPE_CUMULATIVE_HISTOGRAM

At first glance, this can look confusing—why would Dynatrace reject histograms? Let’s break it down and see how to fix it.

✅ The Fix: Use DELTA Temporality Instead of CUMULATIVE

Dynatrace currently does not support cumulative histograms via OTLP.
Instead, it expects delta histograms, meaning each export should only contain the changes since the last export, not the running total.

How to solve it

• Check your exporter configuration (depending on language/SDK).
• Force the histogram aggregation temporality to DELTA.
• Restart your collector/agent so that metrics are exported as deltas.

Once switched, Dynatrace will ingest histogram data correctly.

🔍 What Is Aggregation Temporality?

In OpenTelemetry, every metric that is exported has a temporality, telling the backend how to interpret the values:

• CUMULATIVE
  • Each metric data point is a running total since start/reset.
  • Example: If you record request latencies, the histogram buckets always increase. At t0 → 50 requests, at t1 → 80 requests (export = 80).
  • Backend must diff exports to calculate what happened between intervals.
• DELTA
  • Each data point is only the change during the collection period.
  • Example: From t0–t1 → 30 requests, from t1–t2 → 20 requests (exports = 30, then 20).
  • Backend can use these values directly—no diffs needed.

Different backends have different expectations.

• Prometheus-like systems prefer cumulative (they do their own diffs).
• Dynatrace expects delta histograms to avoid cumulative bucket growth.

📊 Why It Matters for Histograms and Exponential Histograms

Histograms in OTel are more complex than simple counters or gauges, because they store:

• Count → total number of recorded measurements
• Sum → sum of recorded values
• Buckets → counts per range

Exponential histograms add another layer:

• Scale → defines exponential growth of bucket boundaries
• Positive/Negative buckets → record values above/below zero
• Zero count → captures exact zeros efficiently

With CUMULATIVE temporality, all bucket counts, sums, and totals grow monotonically until reset. Backends must compute the delta themselves.
With DELTA temporality, each export already represents the per-interval view—which is easier for backends like Dynatrace to store, query, and visualize.

⚖️ Why Choosing the Right Temporality Is Important

• Compatibility: Some observability platforms reject unsupported temporality (like Dynatrace rejecting cumulative histograms).
• Performance: DELTA reduces backend processing overhead because no diffs are needed.
• Accuracy: Using the wrong temporality can cause inflated or incorrect metrics.
• Portability: OTel allows exporters to convert between cumulative and delta, but you must configure it correctly for your target backend.

🚀 Key Takeaways

• If you see UNSUPPORTED_METRIC_TYPE_CUMULATIVE_HISTOGRAM in Dynatrace → switch histograms to DELTA temporality.
• Aggregation temporality describes whether values are cumulative totals or per-interval changes.
• For histograms and exponential histograms, this choice affects bucket counts, sums, and time-series accuracy.
• Always align your OTel exporter configuration with what your observability backend supports.

👉 This small config change can mean the difference between broken dashboards and reliable real-time insights.