Expose OpenTelemetry metrics shutdown through MeterProvider

[bm1549]

What Does This Do

Adds a Datadog lifecycle extension to the OpenTelemetry MeterProvider returned by GlobalOpenTelemetry:

MeterProvider meterProvider = GlobalOpenTelemetry.get().getMeterProvider();
DatadogMeterProvider datadogMeterProvider = (DatadogMeterProvider) meterProvider;
CompletableResultCode result = datadogMeterProvider.shutdown().join(10, TimeUnit.SECONDS);

shutdown() performs a final export and stops the Datadog OpenTelemetry metrics pipeline. Java does not expose a public forceFlush() extension. DatadogMeterProvider is independent of the OpenTelemetry SDK SdkMeterProvider.

Repeated calls observe the first shutdown result through isolated result views. A disabled or unavailable pipeline succeeds as a no-op. Existing internal metric flushing remains unchanged.

Motivation

Short-lived Java processes need a supported way to wait for pending custom metrics before exit. Exposing shutdown through the underlying meter provider keeps usage close to the OpenTelemetry API.

Tests

• Datadog metrics API unit tests, Javadoc, and SpotBugs
• OpenTelemetry 1.47 forked lifecycle test
• Spotless formatting checks

Contributor Checklist

• Follow the repository title and labeling conventions
• Add focused deterministic tests
• Keep the public API shutdown-only
• Use merge queue after approval

Jira ticket: N/A

[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

Scenario	Candidate	master	Δ (95% CI of mean)
startup:insecure-bank:iast:Agent	13.97 s	13.96 s	[-0.8%; +0.9%] (no difference)
startup:insecure-bank:tracing:Agent	12.93 s	13.03 s	[-1.5%; +0.0%] (no difference)
startup:petclinic:appsec:Agent	16.93 s	16.31 s	[-0.5%; +8.1%] (no difference)
startup:petclinic:iast:Agent	16.29 s	16.89 s	[-7.6%; +0.5%] (no difference)
startup:petclinic:profiling:Agent	16.25 s	16.55 s	[-6.1%; +2.5%] (no difference)
startup:petclinic:sca:Agent	16.84 s	16.69 s	[-0.1%; +2.0%] (no difference)
startup:petclinic:tracing:Agent	15.88 s	16.06 s	[-2.3%; +0.0%] (no difference)

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

[dougqh]

Note from Claude (reviewing on behalf of @dougqh): not a blocker, but worth thinking through before this lands.

Neither OtlpMetricsService.forceFlush() nor shutdown() puts a deadline on the returned CompletableFuture<Boolean>. The only bound in the chain is the transport's own retry policy:

• OtlpHttpSender retries via HttpRetryPolicy.Factory(5, 100, 2.0, true) — up to 5 retries, and the trailing true means InterruptedIOException (covers SocketTimeoutException) is retried, not just hard connection failures.
• Each attempt is bounded by otlp.metrics.timeout, which defaults to 10s.
• Worst case under a degraded (not dead) network — connects but reads stall — that's roughly 6 attempts × ~10s + backoff ≈ 60+ seconds before export()/finishShutdown() returns and the future completes.

For the automatic path (CoreTracer#close()) this is harmless today, since it calls shutdown() fire-and-forget without awaiting the future.

But it cuts against the PR's own motivation: a short-lived job calling OpenTelemetryMetrics.shutdown().join()/.get() to make sure metrics leave before the process exits could block up to ~a minute under a merely-slow network, which is a rough trade for something meant to bound a short-lived job's exit.

Worth considering wrapping the flush/shutdown future with orTimeout(...)/completeOnTimeout(...) (or using a tighter/no-retry policy specifically for the shutdown-triggered final export) so callers of the new public API get a predictable upper bound independent of the transport's retry behavior.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-08T21:04:45.940673Z	dc3deb9	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[datadog-official]

The tracer shutdown path starts the final export on a daemon thread but does not wait for it. The DDTracer wrapper also returns unavailable for both new lifecycle calls instead of forwarding them.

_{Open Bits AI session}

_{🤖 Datadog Autotest · Commit 1b4200c · What is Autotest? · @DataDog review to ask questions · Any feedback? Reach out in #autotest}

[chatgpt-codex-connector]

💡 Codex Review

dd-trace-java/dd-trace-core/src/main/java/datadog/trace/core/CoreTracer.java

Line 1532 in 1b4200c

OtlpMetricsService.INSTANCE.shutdown();

Await metrics shutdown from CoreTracer.close

When CoreTracer.close() runs, especially from dd-tracer-shutdown-hook, this call now only enqueues finishShutdown and discards its future. The exporter uses a daemon AgentThreadFactory, so the JVM may terminate after the hook returns while the final send is still running; manual close likewise returns before sender.shutdown() completes. The previous implementation closed the sender synchronously, so wait for this future with a bounded timeout before returning.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[mabdinur]

@dougqh On the deadline question: the future intentionally has no built-in timeout. Callers can bound their wait with get(timeout, unit), which preserves Java 8 support and does not imply that the in-flight transport was cancelled. CoreTracer.close() now applies a 2.5-second bound.

[mabdinur]

Reviewed the Datadog lifecycle implementation, addressed feedback, and focused tests. CI is green.

[mcculls]

We should avoid using CompletableFuture in a public trace/metrics API

I've suggested some alternatives in other comments

[datadog-official]

A callback on one shutdown result can block completion of later shutdown results. This behavior breaks the repeated-call result contract.

_{Open Bits AI session}

_{🤖 Datadog Autotest · Commit cd8ab82 · What is Autotest? · @DataDog review to ask questions · Any feedback? Reach out in #autotest}

[datadog-official]

More details

The shutdown path returns separate views of one shared result. It exports the last metrics before it stops the sender and executor.

Was this helpful? React 👍 or 👎

_{Open Bits AI session}

_{🤖 Datadog Autotest · Commit dc3deb9 · What is Autotest? · @DataDog review to ask questions · Any feedback? Reach out in #autotest}