feat(profiling): Integrate OTLP profiles export into the agent

[jbachorik]

What Does This Do

Connects the OTLP profiles pipeline to the profiler agent. After this PR, the agent converts JFR recordings to OTLP/P and exports them.

• OtlpProfileUploader consumes reference-counted RecordingData, converts through the profiling-otel converter, and sends through the otlp-exporter sender via OtlpProfilesSenderFactory.
• LightweightOtlpEncoder assembles payloads with low allocation.
• OtlpTelemetry reports export attempts, export completions, and conversion time gauges.
• New configuration: DD_PROFILING_OTLP_* and OTEL_EXPORTER_OTLP_PROFILES_* variables for endpoint, headers, protocol, compression, and timeout. OtelEnvironmentConfigSource resolves them. supported-configurations.json and ConfigDefaults register them. ProfilingConfig.OtlpMode is registry-version-B gated.
• ProfilingAgent and CompositeController attach the uploader as a recording consumer.
• The module is included in the agent shadow jar.

The feature is not production-ready. Every flag defaults to off.

Motivation

The converter, the sender transport, and the reference-counted recordings exist as standalone pieces. None of them runs until the profiler agent uses them. This PR connects them. The agent feeds recordings to the uploader. The uploader converts and sends. The agent reports what happened.

The shape of this PR follows three constraints.

• The export is off by default. The feature is not production-ready, so no user gets the new behavior without asking for it.
• The configuration surface matches the other OTLP signals. Traces, metrics, and logs already use OTEL_EXPORTER_OTLP_* variables with a generic fallback. Profiles follow the same pattern, so operators use a surface they already know. DD_OTLP_PROFILES_HEADERS is marked sensitive, like DD_OTLP_TRACES_HEADER, so header values do not leak into telemetry.
• The export path reports telemetry. An export that fails silently is invisible to operators. The reported attempts, completions, and conversion times make the pipeline observable.

Additional Notes

Part of a 5-PR stack. Each PR bases on the previous one.

1. The payload and request body move (refactor: Move OtlpPayload and OTLP request bodies to communication/otlp-exporter #12880)
2. The sender extraction and the canonical resource attributes (refactor: Extract OTLP sender infrastructure to communication/otlp-exporter #12868)
3. RecordingData reference counting (feat(profiling): Reference-count RecordingData lifecycle #12869)
4. The JFR to OTLP/P converter, profiling-otel, plus jafar 0.26.2 (feat(profiling): Add JFR to OTLP/P converter with CLI, benchmarks and validation #12870)
5. this PR: the OTLP profiles export wiring

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
• Update the CODEOWNERS file on source file addition, migration, or deletion
• Update public documentation with any new configuration flags or behaviors
• Once approved, use merge queue to merge the PR

Jira ticket: [PROJ-IDENT]

[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.91 s	13.83 s	[-0.1%; +1.2%] (no difference)
startup:insecure-bank:tracing:Agent	12.80 s	12.89 s	[-1.5%; +0.2%] (no difference)
startup:petclinic:appsec:Agent	17.73 s	17.58 s	[-0.2%; +1.8%] (no difference)
startup:petclinic:iast:Agent	16.79 s	17.58 s	[-8.6%; -0.4%] (maybe better)
startup:petclinic:profiling:Agent	17.49 s	17.27 s	[-0.0%; +2.6%] (no difference)
startup:petclinic:sca:Agent	17.79 s	17.69 s	[-0.4%; +1.6%] (no difference)
startup:petclinic:tracing:Agent	16.63 s	16.77 s	[-1.8%; +0.2%] (no difference)

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