fix(openfeature): use delta temporality for OTLP metrics export

[sameerank]

What Does This Do

Changes the OTLP metrics exporter from alwaysCumulative() to deltaPreferred() for feature flag evaluation metrics.

Motivation

OTLP receivers (like the Datadog Agent) expect delta temporality for counter metrics. With cumulative temporality, each export sends the total count since start (5, 10, 15...), and receivers that sum these values produce overcounted results (5, 15, 30...).

With delta temporality, each export sends only the increment since the last export (5, 5, 5...), which receivers correctly sum to the actual total.

Testing in https://github.com/DataDog/ffe-dogfooding I saw Java was overcounting with OTLP, compared to the other SDKs.

This aligns with Datadog's OTLP documentation which recommends delta temporality for metrics.

Datadog works best with delta aggregation temporality for monotonic sums, histograms, and exponential histograms.

Additional Notes

• deltaPreferred() uses DELTA for Counter/Histogram and CUMULATIVE for UpDownCounter (per OTel spec)
• Updated test to use delta temporality to match production configuration
• FlagEvalMetrics is the only direct OTLP exporter in dd-trace-java; other OTel metrics go through the DogStatsD shim

Contributor Checklist

• Format the title according to the contribution guidelines
• Assign the type: and (comp: or inst:) labels in addition to any other useful labels
• Avoid using close, fix, or any linking keywords when referencing an issue
• Update the CODEOWNERS file on source file addition, migration, or deletion
• Update public documentation with any new configuration flags or behaviors

[dd-octo-sts]

Hi! 👋 Thanks for your pull request! 🎉

To help us review it, please make sure to:

• Add at least one type, and one component or instrumentation label to the pull request

If you need help, please check our contributing guidelines.

[dd-octo-sts]

/merge

[gh-worker-devflow-routing-ef8351]

View all feedbacks in Devflow UI.

2026-05-22 17:11:37 UTC ℹ️ Start processing command /merge

---

2026-05-22 17:11:43 UTC ℹ️ MergeQueue: pull request added to the queue

The expected merge time in master is approximately 1h (p90).

---

2026-05-22 17:19:47 UTC ❌ MergeQueue: This merge request was updated

This PR is rejected because it was updated

[dd-octo-sts]

/merge

[gh-worker-devflow-routing-ef8351]

View all feedbacks in Devflow UI.

2026-05-22 19:31:57 UTC ℹ️ Start processing command /merge

---

2026-05-22 19:32:01 UTC ℹ️ MergeQueue: pull request added to the queue

The expected merge time in master is approximately 1h (p90).

---

2026-05-22 19:37:30 UTC ❌ MergeQueue: This merge request was updated

This PR is rejected because it was updated

[dd-octo-sts]

🟢 Java Benchmark SLOs — All performance SLOs passed

Suite	Status
Startup	🟢 pass

SLO thresholds are defined here based on automatically generated metrics. A warning is raised when results are within 5% of the threshold.

PR vs. master results

Startup Time

Scenario	This PR	master	Change
insecure-bank / iast	13,967 ms	13,864 ms	+0.7%
insecure-bank / tracing	12,973 ms	12,980 ms	-0.1%
petclinic / appsec	16,527 ms	16,344 ms	+1.1%
petclinic / iast	15,533 ms	16,514 ms	-5.9%
petclinic / profiling	16,374 ms	16,529 ms	-0.9%
petclinic / tracing	15,857 ms	15,795 ms	+0.4%

Commit: 98af643e · CI Pipeline · Benchmarking Platform UI

---

Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion.

[sameerank]

/merge

[gh-worker-devflow-routing-ef8351]

View all feedbacks in Devflow UI.

2026-05-22 20:15:55 UTC ℹ️ Start processing command /merge

---

2026-05-22 20:16:00 UTC ℹ️ MergeQueue: pull request added to the queue

The expected merge time in master is approximately 1h (p90).

---

2026-05-22 21:28:30 UTC ℹ️ MergeQueue: This merge request was merged