Use agent OTel metrics for OpenFeature evaluations

[sameerank]

What changed

This updates the OpenFeature feature flag evaluation metrics implementation to record through GlobalOpenTelemetry instead of constructing its own OpenTelemetry SDK meter provider and OTLP HTTP exporter.

It also removes the OpenTelemetry SDK/exporter dependencies from feature-flagging-api, refreshes the lockfile, and updates the README to document that evaluation metrics use the Datadog Java agent OpenTelemetry metrics pipeline with DD_METRICS_OTEL_ENABLED=true.

Why

The previous implementation required opentelemetry-sdk-metrics and opentelemetry-exporter-otlp on the application classpath and always created an OTLP HTTP exporter. That did not line up with customers already using the Datadog Java agent OTel metrics pipeline for custom metrics, especially when their Agent OTLP receiver is configured for gRPC only.

With this change, feature_flag.evaluations uses the same configured Java agent OTel metrics pipeline as other custom OTel metrics.

Validation

• ./gradlew :products:feature-flagging:feature-flagging-api:dependencies --write-locks
• ./gradlew :products:feature-flagging:feature-flagging-api:test
• git diff --check
• git diff --cached --check

Noted local blockers/noisy checks:

• ./gradlew :products:feature-flagging:feature-flagging-api:spotlessCheck is currently blocked by :spotlessInternalRegisterDependencies failing to provision P2 dependencies.
• ./gradlew :dd-java-agent:instrumentation:opentelemetry:opentelemetry-1.47:test fails before tests in unrelated :dd-java-agent:agent-jmxfetch:compileJava; the local otel-bootstrap shadow artifact is missing datadog.trace.bootstrap.otel.api.common.AttributeKey and Attributes.

Local testing

In ffe-dogfooding

Commented out the unnecessary dependencies and added opentelemetry-api

Set the protocol to gRPC

And verified that OTLP still working for flags DD_TRACE_JAVA_PATH=/path/to/dd-trace-java docker-compose -f docker-compose.yml -f local/docker-compose.java.yml up --build:

In system-tests

Set local binaries

binaries/dd-java-agent-1.63.0-SNAPSHOT.jar
binaries/dd-openfeature-1.63.0-SNAPSHOT.jar
binaries/dd-trace-api-1.63.0-SNAPSHOT.jar

And ran tests

system-tests % TEST_LIBRARY=java ./run.sh FEATURE_FLAGGING_AND_EXPERIMENTATION tests/ffe/test_flag_eval_metrics.py
================================================= test context =================================================
Scenario: FEATURE_FLAGGING_AND_EXPERIMENTATION
Logs folder: ./logs_feature_flagging_and_experimentation
Starting containers...
Agent: 7.80.3
Backend: datad0g.com
Library: java@1.63.0-SNAPSHOT+051539dcfa
Weblog variant: spring-boot
Weblog system: Linux weblog 6.19.7-200.fc43.aarch64 #1 SMP PREEMPT_DYNAMIC Thu Mar 12 15:54:05 UTC 2026 aarch64 GNU/Linux

============================================= test session starts ==============================================
collected 17 items                                                                                             
------------------------------------------------- tests setup --------------------------------------------------

tests/ffe/test_flag_eval_metrics.py .................

--------------------------------------- Wait for library interface (25s) ---------------------------------------
---------------------------------------- Wait for agent interface (5s) -----------------------------------------
--------------------------------------- Wait for backend interface (0s) ----------------------------------------

tests/ffe/test_flag_eval_metrics.py .................                                                    [100%]

- generated xml file: /Users/.../system-tests/logs_feature_flagging_and_experimentation/reportJunit.xml -
======================================== 17 passed in 153.53s (0:02:33) ========================================

[dd-octo-sts]

🟡 Java Benchmark SLOs — Performance SLO warning (near threshold)

Suite	Status
Startup	🟡 warning

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

Scenario	Candidate	master	Δ (95% CI of mean)
startup:insecure-bank:iast:Agent	13.98 s	14.00 s	[-0.9%; +0.6%] (no difference)
startup:insecure-bank:tracing:Agent	12.94 s	13.05 s	[-1.6%; -0.0%] (maybe better)
startup:petclinic:appsec:Agent	17.39 s	17.20 s	[+0.1%; +2.1%] (maybe worse)
startup:petclinic:iast:Agent	17.32 s	17.58 s	[-2.2%; -0.6%] (maybe better)
startup:petclinic:profiling:Agent	17.52 s	17.47 s	[-0.6%; +1.2%] (no difference)
startup:petclinic:sca:Agent	17.45 s	17.29 s	[+0.1%; +1.7%] (maybe worse)
startup:petclinic:tracing:Agent	16.46 s	16.19 s	[-3.0%; +6.2%] (no difference)

Commit: 051539dc · 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.

[leoromanovsky]

nice nice nice

[dd-octo-sts]

/merge

[gh-worker-devflow-routing-ef8351]

View all feedbacks in Devflow UI.

2026-06-30 08:36:37 UTC ℹ️ Start processing command /merge

---

2026-06-30 08:36:41 UTC ℹ️ MergeQueue: pull request added to the queue

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

---

2026-06-30 09:40:34 UTC ℹ️ MergeQueue: This merge request was merged

[tantran-earnin]

@sameerank How critical is having this env var?

In our testing we have dd-java-agent-1.64.0 and com.datadoghq:dd-openfeature = 1.64.0 without the DD_METRICS_OTEL_ENABLED and it still worked for emitting server-side evaluation metrics.

Granted our setup has Datadog java tracer for auto instrumentation with otel compatibility for custom spans/metrics. Only otel metrics exporter is enabled and is already manually wired.

-Dotel.traces.exporter=none \ -Dotel.metrics.exporter=otlp \ -Dotel.logs.exporter=none \ -Dotel.exporter.otlp.endpoint=http://${DD_AGENT_HOST}:4317 \ -Dotel.exporter.otlp.protocol=grpc \