[FFL-2653] Document Java flag evaluation metrics setup#37927
Conversation
Reflect the requirements for emitting the feature_flag.evaluations metric from the Java SDK: - Bump dd-openfeature examples to 1.63.0; note the 1.62.0 metrics floor - Document the OpenTelemetry SDK metrics + OTLP exporter dependencies (via the OpenTelemetry BOM) that the released provider needs - Clarify that the OTel SDK on the classpath, not DD_METRICS_OTEL_ENABLED, enables metrics on the Java tracer - Add a Spring Boot ScopeConfigurator startup troubleshooting note - Clarify the OpenTelemetry integration note for the metrics case Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
… clarify OTLP HTTP - Note that the Java tracer does not use DD_METRICS_OTEL_ENABLED for flag evaluation metrics, and drop it from the Java OpenTelemetry .env snippets - Document that the Java exporter uses OTLP/HTTP on port 4318 and ignores OTEL_EXPORTER_OTLP_PROTOCOL, so gRPC must not be configured for it Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The dd-openfeature 1.63.0 POM declares dev.openfeature:sdk 1.20.1 (1.57.0 declared 1.18.2). Bump the direct dev.openfeature:sdk examples and the compatibility line to 1.20.1 so a pinned direct dependency does not downgrade the provider's transitive version under Maven mediation. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
/review |
There was a problem hiding this comment.
Pull request overview
This PR updates the Feature Flags documentation to accurately describe what’s required for Java server-side flag evaluation metrics (feature_flag.evaluations), aligning the docs with current tracer/provider behavior.
Changes:
- Bump Java dependency examples (
dev.openfeature:sdkandcom.datadoghq:dd-openfeature) and document the Java metrics minimum version floor. - Document Java’s additional requirement for OpenTelemetry SDK metrics + OTLP exporter dependencies and clarify OTLP endpoint behavior.
- Remove/adjust guidance that incorrectly implied
DD_METRICS_OTEL_ENABLEDis the Java enablement mechanism, and add Spring Boot troubleshooting context.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| content/en/getting_started/feature_flags/_index.md | Updates Java dependency versions and points readers to the dedicated metrics setup guide instead of DD_METRICS_OTEL_ENABLED. |
| content/en/feature_flags/server/java.md | Updates Java compatibility/dependency versions and adds a metrics-specific note linking to the setup guide. |
| content/en/feature_flags/implementation_patterns/opentelemetry.md | Removes DD_METRICS_OTEL_ENABLED from Java examples and clarifies Java API-vs-SDK guidance for tracing vs metrics. |
| content/en/feature_flags/guide/server_flag_evaluation_metrics.md | Adds Java-specific OpenTelemetry SDK dependency requirements, endpoint nuances, and Spring Boot troubleshooting guidance. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| {{< /code-block >}} | ||
|
|
||
| If you use the **Java** tracer, `DD_METRICS_OTEL_ENABLED` is not required for flag evaluation metrics; the OpenTelemetry SDK dependencies described in the next section enable them instead. | ||
|
|
There was a problem hiding this comment.
🤖 Response from Claude: Good catch. Scoped the instruction to non-Java tracers and folded the Java exception into the lead-in (with a link to the Java SDK-dependencies section), and removed the redundant follow-up sentence. Fixed in ddc23e6.
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
🤖 Automated review by Claude. AI-generated; verify before acting.
Small review — no blockers. Two clarity nits on the new Java-specific content.
Reviewed bdc4107bf170f42808dbd5bda1cc10a0a775f83d — workflow run
|
|
||
| - The Agent is not reachable at `DD_AGENT_HOST` on the default OTLP port (for example, a remote Agent or a non-default port). | ||
| - You use the **Java** tracer. The Java tracer does not derive the endpoint from `DD_AGENT_HOST`; it defaults to `localhost:4318`. Set the endpoint whenever the Agent is not on `localhost`. | ||
| - You use the **Java** tracer. The Java flag evaluation metrics exporter sends OTLP over HTTP on port `4318` and ignores `OTEL_EXPORTER_OTLP_PROTOCOL`, so do not configure it for gRPC. It does not derive the endpoint from `DD_AGENT_HOST`; it defaults to `http://localhost:4318`. Set `OTEL_EXPORTER_OTLP_ENDPOINT` to the Agent's HTTP endpoint whenever the Agent is not on `localhost`. |
There was a problem hiding this comment.
Style: The pronoun "it" is ambiguous here — it could refer to the exporter or to OTEL_EXPORTER_OTLP_PROTOCOL. Naming the referent (or stating the constraint directly) reads more clearly.
| - You use the **Java** tracer. The Java flag evaluation metrics exporter sends OTLP over HTTP on port `4318` and ignores `OTEL_EXPORTER_OTLP_PROTOCOL`, so do not configure it for gRPC. It does not derive the endpoint from `DD_AGENT_HOST`; it defaults to `http://localhost:4318`. Set `OTEL_EXPORTER_OTLP_ENDPOINT` to the Agent's HTTP endpoint whenever the Agent is not on `localhost`. | |
| - You use the **Java** tracer. The Java flag evaluation metrics exporter sends OTLP over HTTP on port `4318` and ignores `OTEL_EXPORTER_OTLP_PROTOCOL`, so gRPC is not supported. It does not derive the endpoint from `DD_AGENT_HOST`; it defaults to `http://localhost:4318`. Set `OTEL_EXPORTER_OTLP_ENDPOINT` to the Agent's HTTP endpoint whenever the Agent is not on `localhost`. |
There was a problem hiding this comment.
🤖 Response from Claude: Applied — replaced "so do not configure it for gRPC" with "so gRPC is not supported" to drop the ambiguous pronoun. Fixed in ddc23e6.
| {{< /code-block >}} | ||
|
|
||
| **Note**: Depend only on the OpenTelemetry API, not the OpenTelemetry SDK. For more detail, see [OpenTelemetry API Support for Java](/opentelemetry/instrument/dd_sdks/api_support/?prog_lang=java&platform=traces). | ||
| **Note**: For tracing, depend only on the OpenTelemetry API, not the OpenTelemetry SDK. To emit flag evaluation metrics, you also need the OpenTelemetry SDK metrics and OTLP exporter dependencies; see [Set Up Server-Side Flag Evaluation Metrics](/feature_flags/guide/server_flag_evaluation_metrics/). For more detail, see [OpenTelemetry API Support for Java](/opentelemetry/instrument/dd_sdks/api_support/?prog_lang=java&platform=traces). |
There was a problem hiding this comment.
Suggestion: This Note now interleaves two pieces of advice — "depend only on the OpenTelemetry API" (tracing) and "you also need the OpenTelemetry SDK" (metrics) — with the "For more detail" link tucked in between. On first read it can look contradictory. Grouping the tracing guidance + its link, then the metrics guidance + its link, makes the flow easier to follow.
| **Note**: For tracing, depend only on the OpenTelemetry API, not the OpenTelemetry SDK. To emit flag evaluation metrics, you also need the OpenTelemetry SDK metrics and OTLP exporter dependencies; see [Set Up Server-Side Flag Evaluation Metrics](/feature_flags/guide/server_flag_evaluation_metrics/). For more detail, see [OpenTelemetry API Support for Java](/opentelemetry/instrument/dd_sdks/api_support/?prog_lang=java&platform=traces). | |
| **Note**: For tracing, depend only on the OpenTelemetry API, not the OpenTelemetry SDK. For more detail, see [OpenTelemetry API Support for Java](/opentelemetry/instrument/dd_sdks/api_support/?prog_lang=java&platform=traces). To emit flag evaluation metrics, you also need the OpenTelemetry SDK metrics and OTLP exporter dependencies; see [Set Up Server-Side Flag Evaluation Metrics](/feature_flags/guide/server_flag_evaluation_metrics/). |
There was a problem hiding this comment.
🤖 Response from Claude: Applied the suggested regrouping: tracing guidance and its link first, then the metrics guidance and its link. Fixed in ddc23e6.
- Scope the DD_METRICS_OTEL_ENABLED step to non-Java tracers so it no longer reads as contradictory with the Java guidance - List the Datadog OpenFeature provider in the compatibility requirements - Resolve an ambiguous pronoun in the Java OTLP endpoint note - Regroup the OpenTelemetry integration note: tracing guidance and link, then metrics guidance and link Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
/review |
| {{% /tab %}} | ||
| {{< /tabs >}} | ||
|
|
||
| To emit flag evaluation metrics (the `feature_flag.evaluations` metric), use `dd-openfeature` 1.62.0 or later and add the OpenTelemetry SDK dependencies to your application. For the required dependencies and endpoint configuration, see [Set Up Server-Side Flag Evaluation Metrics](/feature_flags/guide/server_flag_evaluation_metrics/). |
There was a problem hiding this comment.
🤖 Response from Claude: Good point — updated the note to require dd-openfeature and the Datadog Java tracer 1.62.0 or later (not just the provider). Fixed in 61e32ba.
There was a problem hiding this comment.
🤖 Automated review by Claude. AI-generated; verify before acting.
Overall this looks like a solid, focused set of changes: the Java exception path is now documented, version references are updated consistently, and stale DD_METRICS_OTEL_ENABLED mentions have been removed from Java/Go examples where they don't apply. A few small clarity/style nits inline; no blockers.
Reviewed ddc23e65fc62f787a6bb935881db970f0b002974 — workflow run
| ## Step 2: Configure your application | ||
|
|
||
| Set the following environment variable on your application, in addition to the standard [server-side feature flag configuration][1]: | ||
| Set the following environment variable on non-Java tracers, in addition to the standard [server-side feature flag configuration][1]. The Java tracer enables flag evaluation metrics through the OpenTelemetry SDK dependencies described in the [next section](#java-add-the-opentelemetry-sdk-dependencies), not through this variable. |
There was a problem hiding this comment.
Suggestion: The sentence packs both an inclusion ("non-Java tracers") and an exclusion ("not through this variable") into one line, which slows the reader down. Consider splitting.
| Set the following environment variable on non-Java tracers, in addition to the standard [server-side feature flag configuration][1]. The Java tracer enables flag evaluation metrics through the OpenTelemetry SDK dependencies described in the [next section](#java-add-the-opentelemetry-sdk-dependencies), not through this variable. | |
| For all tracers except Java, set the following environment variable in addition to the standard [server-side feature flag configuration][1]. The Java tracer enables flag evaluation metrics through the OpenTelemetry SDK dependencies described in the [next section](#java-add-the-opentelemetry-sdk-dependencies). |
There was a problem hiding this comment.
🤖 Response from Claude: Applied your suggestion — the step now leads with "For all tracers except Java" and drops the trailing exclusion clause. Fixed in 61e32ba.
|
|
||
| ### Java: add the OpenTelemetry SDK dependencies | ||
|
|
||
| The Java provider records `feature_flag.evaluations` through the OpenTelemetry SDK and exports it over OTLP, so the OpenTelemetry SDK metrics and OTLP exporter must be on your application's classpath. Add them alongside your [feature flag dependencies][6]. Import the OpenTelemetry BOM so the OpenTelemetry API and SDK stay on the same version: |
There was a problem hiding this comment.
Style: Slightly tighter phrasing and a more descriptive link label.
| The Java provider records `feature_flag.evaluations` through the OpenTelemetry SDK and exports it over OTLP, so the OpenTelemetry SDK metrics and OTLP exporter must be on your application's classpath. Add them alongside your [feature flag dependencies][6]. Import the OpenTelemetry BOM so the OpenTelemetry API and SDK stay on the same version: | |
| The Java provider records `feature_flag.evaluations` through the OpenTelemetry SDK and exports it over OTLP, so the OpenTelemetry SDK metrics and OTLP exporter dependencies must be on your application's classpath. Add them alongside your [Java feature flag dependencies][6]. Import the OpenTelemetry BOM so the OpenTelemetry API and SDK stay on the same version: |
There was a problem hiding this comment.
🤖 Response from Claude: Applied — "SDK metrics and OTLP exporter dependencies must be on your application's classpath" and the link label is now "Java feature flag dependencies". Fixed in 61e32ba.
| {{% /tab %}} | ||
| {{< /tabs >}} | ||
|
|
||
| On the Java tracer, the provider starts its OTLP metrics exporter automatically when the OpenTelemetry SDK is on the classpath, so adding these dependencies is what enables the metric; setting `DD_METRICS_OTEL_ENABLED` alone does not. This requires the Datadog Java tracer 1.62.0 or later. If the dependencies are missing, no metrics are emitted and the tracer logs `OpenTelemetry SDK is not on the classpath`. |
There was a problem hiding this comment.
Style: "is what enables the metric" reads a bit indirect — direct voice is clearer.
| On the Java tracer, the provider starts its OTLP metrics exporter automatically when the OpenTelemetry SDK is on the classpath, so adding these dependencies is what enables the metric; setting `DD_METRICS_OTEL_ENABLED` alone does not. This requires the Datadog Java tracer 1.62.0 or later. If the dependencies are missing, no metrics are emitted and the tracer logs `OpenTelemetry SDK is not on the classpath`. | |
| On the Java tracer, the provider starts its OTLP metrics exporter automatically when the OpenTelemetry SDK is on the classpath. Adding these dependencies enables the metric; setting `DD_METRICS_OTEL_ENABLED` alone does not. This requires the Datadog Java tracer 1.62.0 or later. If the dependencies are missing, no metrics are emitted and the tracer logs `OpenTelemetry SDK is not on the classpath`. |
There was a problem hiding this comment.
🤖 Response from Claude: Applied the direct-voice rewrite. Fixed in 61e32ba.
|
|
||
| - The Agent is not reachable at `DD_AGENT_HOST` on the default OTLP port (for example, a remote Agent or a non-default port). | ||
| - You use the **Java** tracer. The Java tracer does not derive the endpoint from `DD_AGENT_HOST`; it defaults to `localhost:4318`. Set the endpoint whenever the Agent is not on `localhost`. | ||
| - You use the **Java** tracer. The Java flag evaluation metrics exporter sends OTLP over HTTP on port `4318` and ignores `OTEL_EXPORTER_OTLP_PROTOCOL`, so gRPC is not supported. It does not derive the endpoint from `DD_AGENT_HOST`; it defaults to `http://localhost:4318`. Set `OTEL_EXPORTER_OTLP_ENDPOINT` to the Agent's HTTP endpoint whenever the Agent is not on `localhost`. |
There was a problem hiding this comment.
Suggestion: This bullet is now noticeably denser than the others in the list (four sentences of Java-specific behavior). Since the previous section already covers Java setup in depth, consider extracting the Java-only endpoint constraints into a short callout or sub-heading and keeping this bullet focused on "the endpoint is not derived from DD_AGENT_HOST; set OTEL_EXPORTER_OTLP_ENDPOINT." That keeps the bulleted list scannable while preserving the gRPC-not-supported detail.
There was a problem hiding this comment.
🤖 Response from Claude: Tightened the bullet to two clauses (OTLP/HTTP on 4318 only with gRPC not supported; endpoint not derived from DD_AGENT_HOST) rather than extracting a separate callout, so the endpoint details stay in the endpoint section. Fixed in 61e32ba.
- Note the Datadog Java tracer 1.62.0+ requirement (not just the provider) - Clarify that examples use the current release 1.63.0 - Lead the env-var step with "all tracers except Java"; tighten wording - Use direct voice and tighten the Java OTLP endpoint bullet Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
/review |
There was a problem hiding this comment.
🤖 Automated review by Claude. AI-generated; verify before acting.
Reviewed the split of Java's setup out of the shared DD_METRICS_OTEL_ENABLED flow. Content is technically clear and the diagnostic details (log message, Spring Boot BOM bean-collision note) are useful. One minor style nit inline.
Reviewed 61e32ba8a1d72aebe9c6a7ed516af51ada8db722 — workflow run
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
|
/review |
There was a problem hiding this comment.
🤖 Automated review by Claude. AI-generated; verify before acting.
Docs cleanly capture the new Java flow. A few style/consistency nits below; nothing blocking.
Reviewed 267dab3c90c1fe800cef2fb6b83e8e0c202ec0a9 — workflow run
| {{% /tab %}} | ||
| {{< /tabs >}} | ||
|
|
||
| The examples use the current release, `1.63.0`. See [Compatibility requirements](#compatibility-requirements) for the minimum supported versions. |
There was a problem hiding this comment.
Style: "current" is a temporal word that ages poorly (per the Vale rules) — the sentence will become inaccurate as new releases ship. Consider dropping the leading clause and letting the compatibility note stand on its own, or naming the specific version without the temporal framing.
| The examples use the current release, `1.63.0`. See [Compatibility requirements](#compatibility-requirements) for the minimum supported versions. | |
| The examples above pin `1.63.0`. See [Compatibility requirements](#compatibility-requirements) for the minimum supported versions. |
There was a problem hiding this comment.
🤖 Response from Claude: Fixed — dropped the temporal "current"; the note now reads "The examples above pin 1.63.0." Fixed in 7892c88.
| java -javaagent:path/to/dd-java-agent.jar -jar your-application.jar | ||
| {{< /code-block >}} | ||
|
|
||
| To emit flag evaluation metrics, add the OpenTelemetry SDK dependencies and configure the OTLP endpoint. See [Set Up Server-Side Flag Evaluation Metrics](/feature_flags/guide/server_flag_evaluation_metrics/). |
There was a problem hiding this comment.
Style: This file already defines reference [9]: /feature_flags/guide/server_flag_evaluation_metrics/ at the bottom — reuse it instead of an inline link to stay consistent with the rest of the page.
| To emit flag evaluation metrics, add the OpenTelemetry SDK dependencies and configure the OTLP endpoint. See [Set Up Server-Side Flag Evaluation Metrics](/feature_flags/guide/server_flag_evaluation_metrics/). | |
| To emit flag evaluation metrics, add the OpenTelemetry SDK dependencies and configure the OTLP endpoint. See [Set Up Server-Side Flag Evaluation Metrics][9]. |
There was a problem hiding this comment.
🤖 Response from Claude: Done — switched to the existing [9] reference. Fixed in 7892c88.
|
|
||
| The examples use the current release, `1.63.0`. See [Compatibility requirements](#compatibility-requirements) for the minimum supported versions. | ||
|
|
||
| To emit flag evaluation metrics (the `feature_flag.evaluations` metric), use `dd-openfeature` and the Datadog Java tracer 1.62.0 or later, and add the OpenTelemetry SDK dependencies to your application. For the required dependencies and endpoint configuration, see [Set Up Server-Side Flag Evaluation Metrics](/feature_flags/guide/server_flag_evaluation_metrics/). |
There was a problem hiding this comment.
Style: The rest of this page uses numbered reference-style links (see the [1]–[7] block at the bottom). Consider promoting this to a new reference (for example [8]) rather than an inline link.
Suggestion: Also, this sentence restates two Java-tracer/dd-openfeature version constraints that are already in the Compatibility requirements list above; you could tighten it to just point at the setup page for the OTel SDK dependencies without duplicating the version guidance.
There was a problem hiding this comment.
🤖 Response from Claude: Done — promoted to a new [8] reference and tightened the sentence to point at the setup page without restating the version constraints (those live in Compatibility requirements). Fixed in 7892c88.
| ## Step 2: Configure your application | ||
|
|
||
| Set the following environment variable on your application, in addition to the standard [server-side feature flag configuration][1]: | ||
| For all tracers except Java, set the following environment variable in addition to the standard [server-side feature flag configuration][1]. The Java tracer enables flag evaluation metrics through the OpenTelemetry SDK dependencies described in the [next section](#java-add-the-opentelemetry-sdk-dependencies). |
There was a problem hiding this comment.
Suggestion: "the [next section]" is brittle if this section ever moves. Consider naming the section ("see Java: Add the OpenTelemetry SDK dependencies") so the link keeps making sense even if reorganized.
There was a problem hiding this comment.
🤖 Response from Claude: Done — the link text now names the section: "[Java: Add the OpenTelemetry SDK dependencies]". Fixed in 7892c88.
|
|
||
| ### Java: Add the OpenTelemetry SDK dependencies | ||
|
|
||
| The Java provider records `feature_flag.evaluations` through the OpenTelemetry SDK and exports it over OTLP, so the OpenTelemetry SDK metrics and OTLP exporter dependencies must be on your application's classpath. Add them alongside your [Java feature flag dependencies][6]. Import the OpenTelemetry BOM so the OpenTelemetry API and SDK stay on the same version: |
There was a problem hiding this comment.
Suggestion: For clarity, consider naming the two artifacts inline so readers can match them to the code blocks below without scanning — e.g., "the opentelemetry-sdk-metrics and opentelemetry-exporter-otlp dependencies must be on your application's classpath."
There was a problem hiding this comment.
🤖 Response from Claude: Done — named the two artifacts inline (opentelemetry-sdk-metrics and opentelemetry-exporter-otlp). Fixed in 7892c88.
| {{% /tab %}} | ||
| {{< /tabs >}} | ||
|
|
||
| On the Java tracer, the provider starts its OTLP metrics exporter automatically when the OpenTelemetry SDK is on the classpath. Adding these dependencies enables the metric; setting `DD_METRICS_OTEL_ENABLED` alone does not. This requires the Datadog Java tracer 1.62.0 or later. If the dependencies are missing, no metrics are emitted and the tracer logs `OpenTelemetry SDK is not on the classpath`. |
There was a problem hiding this comment.
Suggestion: The 1.62.0 minimum is already in the tracer table under Prerequisites. You can drop "This requires the Datadog Java tracer 1.62.0 or later." here to avoid restating it, keeping the operational detail (log message on missing SDK) as the value-add of this paragraph.
There was a problem hiding this comment.
🤖 Response from Claude: Done — removed "This requires the Datadog Java tracer 1.62.0 or later" here; the minimum stays in the Prerequisites table, and the paragraph keeps the operational detail (log message on missing SDK). Fixed in 7892c88.
- Drop the temporal word "current" from the version note - Use reference-style links for the metrics guide ([8] in java.md, [9] in getting started) and name the target section in the metrics guide link - Name the opentelemetry-sdk-metrics and opentelemetry-exporter-otlp artifacts inline - Remove version restatements already covered by the prerequisites/ compatibility lists Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
/review |
There was a problem hiding this comment.
🤖 Automated review by Claude. AI-generated; verify before acting.
Overall, this reads clearly and the cross-links between the guide, the Java page, and the OpenTelemetry implementation-pattern page hold together. A couple of small clarity nits — nothing blocking.
Reviewed 7892c888b406bce1fc62fb6c7d5f95746cf648d6 — workflow run
|
|
||
| - The Agent is not reachable at `DD_AGENT_HOST` on the default OTLP port (for example, a remote Agent or a non-default port). | ||
| - You use the **Java** tracer. The Java tracer does not derive the endpoint from `DD_AGENT_HOST`; it defaults to `localhost:4318`. Set the endpoint whenever the Agent is not on `localhost`. | ||
| - You use the **Java** tracer. Its flag evaluation metrics exporter uses OTLP/HTTP on port `4318` only (gRPC is not supported) and does not derive the endpoint from `DD_AGENT_HOST` (it defaults to `http://localhost:4318`). Set `OTEL_EXPORTER_OTLP_ENDPOINT` to the Agent's HTTP endpoint when the Agent is not on `localhost`. |
There was a problem hiding this comment.
Suggestion: The clause "OTLP/HTTP on port 4318 only (gRPC is not supported)" is slightly ambiguous — a reader can parse "only" as modifying the port rather than the protocol. Reordering makes the two constraints independent and easier to skim.
| - You use the **Java** tracer. Its flag evaluation metrics exporter uses OTLP/HTTP on port `4318` only (gRPC is not supported) and does not derive the endpoint from `DD_AGENT_HOST` (it defaults to `http://localhost:4318`). Set `OTEL_EXPORTER_OTLP_ENDPOINT` to the Agent's HTTP endpoint when the Agent is not on `localhost`. | |
| - You use the **Java** tracer. Its flag evaluation metrics exporter supports OTLP/HTTP only (gRPC is not supported) and uses port `4318`. It does not derive the endpoint from `DD_AGENT_HOST` and defaults to `http://localhost:4318`. Set `OTEL_EXPORTER_OTLP_ENDPOINT` to the Agent's HTTP endpoint when the Agent is not on `localhost`. |
There was a problem hiding this comment.
🤖 Response from Claude: Applied your reordering — it now reads "supports OTLP/HTTP only (gRPC is not supported) and uses port 4318", so the protocol and port constraints are independent. Fixed in a503090.
| {{% /tab %}} | ||
| {{< /tabs >}} | ||
|
|
||
| On the Java tracer, the provider starts its OTLP metrics exporter automatically when the OpenTelemetry SDK is on the classpath. Adding these dependencies enables the metric; setting `DD_METRICS_OTEL_ENABLED` alone does not. If the dependencies are missing, no metrics are emitted and the tracer logs `OpenTelemetry SDK is not on the classpath`. |
There was a problem hiding this comment.
Suggestion: A Java user coming from Step 2 may wonder whether they still need DD_METRICS_OTEL_ENABLED at all. The intro to Step 2 already says only non-Java tracers set it, but this line is where readers land after adding dependencies — worth being explicit that they can skip the env var entirely.
| On the Java tracer, the provider starts its OTLP metrics exporter automatically when the OpenTelemetry SDK is on the classpath. Adding these dependencies enables the metric; setting `DD_METRICS_OTEL_ENABLED` alone does not. If the dependencies are missing, no metrics are emitted and the tracer logs `OpenTelemetry SDK is not on the classpath`. | |
| On the Java tracer, the provider starts its OTLP metrics exporter automatically when the OpenTelemetry SDK is on the classpath. Adding these dependencies is what enables the metric — `DD_METRICS_OTEL_ENABLED` is not required for Java and setting it alone has no effect. If the dependencies are missing, no metrics are emitted and the tracer logs `OpenTelemetry SDK is not on the classpath`. |
There was a problem hiding this comment.
🤖 Response from Claude: Done — made it explicit: "DD_METRICS_OTEL_ENABLED is not required for Java and setting it alone has no effect." Fixed in a503090.
| - **Datadog Java SDK**: Version **1.57.0** or later | ||
| - **OpenFeature SDK**: Version **1.18.2** or later | ||
| - **Datadog Java SDK**: Version **1.57.0** or later (**1.62.0** or later for flag evaluation metrics) | ||
| - **Datadog OpenFeature provider** (`com.datadoghq:dd-openfeature`): Version **1.57.0** or later (**1.62.0** or later for flag evaluation metrics) |
There was a problem hiding this comment.
Suggestion: The two lines above ("Datadog Java SDK" and "Datadog OpenFeature provider") both list "Version 1.57.0 or later (1.62.0 or later for flag evaluation metrics)", which reads as if these are two independently versioned artifacts users pick versions for. In practice, only com.datadoghq:dd-openfeature is added as a dependency; the "Datadog Java SDK" here is the dd-java-agent. Consider clarifying which artifact each line refers to so readers know what to check against the versions in their build files.
There was a problem hiding this comment.
🤖 Response from Claude: Good clarification — labeled each line with its artifact: "Datadog Java SDK (dd-java-agent, added with -javaagent)" and "Datadog OpenFeature provider (com.datadoghq:dd-openfeature, added as a build dependency)". Fixed in a503090.
|
|
||
| On the Java tracer, the provider starts its OTLP metrics exporter automatically when the OpenTelemetry SDK is on the classpath. Adding these dependencies enables the metric; setting `DD_METRICS_OTEL_ENABLED` alone does not. If the dependencies are missing, no metrics are emitted and the tracer logs `OpenTelemetry SDK is not on the classpath`. | ||
|
|
||
| <div class="alert alert-info">In Spring Boot applications, Spring Boot's OpenTelemetry autoconfiguration also creates an <code>OpenTelemetrySdk</code> bean. If the OpenTelemetry SDK version it resolves does not match the OpenTelemetry API version on the classpath, startup fails with a <code>BeanCreationException</code> for the <code>openTelemetry</code> bean and <code>NoClassDefFoundError: io/opentelemetry/sdk/internal/ScopeConfigurator</code>. Importing the <code>opentelemetry-bom</code> as shown above keeps the API and SDK on the same version and resolves the error.</div> |
There was a problem hiding this comment.
Suggestion: This alert reads more like a troubleshooting entry than setup guidance and interrupts the setup flow. Since the preceding paragraph already tells users to import the BOM, consider moving this Spring Boot detail to a troubleshooting section (or a <details> block) so the happy-path setup stays terse.
There was a problem hiding this comment.
🤖 Response from Claude: Keeping this inline for now. It's an alert-info callout (already set apart from the setup prose) and it documents the exact startup failure users hit right after adding these dependencies — the specific issue this change was written to address — so co-locating it with the dependency step maximizes discoverability. Happy to move it to a dedicated troubleshooting section in a follow-up if you'd prefer.
| {{% /tab %}} | ||
| {{< /tabs >}} | ||
|
|
||
| The examples above pin `1.63.0`. See [Compatibility requirements](#compatibility-requirements) for the minimum supported versions. |
There was a problem hiding this comment.
🤖 Response from Claude: Done — the note now calls out both pinned versions: "The examples above pin dd-openfeature 1.63.0 and the OpenFeature SDK 1.20.1." Fixed in a503090.
- Clarify which artifact each compatibility line refers to (dd-java-agent vs com.datadoghq:dd-openfeature) - Note both pinned example versions (dd-openfeature and the OpenFeature SDK) - State explicitly that DD_METRICS_OTEL_ENABLED is not required for Java - Reorder the Java endpoint bullet so protocol and port read independently Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
/review |
There was a problem hiding this comment.
🤖 Automated review by Claude. AI-generated; verify before acting.
Overall the PR is well-organized and technically thorough. The Java-specific setup section, the BOM import guidance, and the Spring Boot troubleshooting callout add real value. Cross-file link updates and version bumps are consistent (dd-openfeature 1.63.0, OpenFeature SDK 1.20.1, min for metrics 1.62.0). A few minor readability suggestions inline — nothing blocking.
Reviewed a50309016b0b8c6c45671720003280f33ea8773e — workflow run
|
|
||
| - The Agent is not reachable at `DD_AGENT_HOST` on the default OTLP port (for example, a remote Agent or a non-default port). | ||
| - You use the **Java** tracer. The Java tracer does not derive the endpoint from `DD_AGENT_HOST`; it defaults to `localhost:4318`. Set the endpoint whenever the Agent is not on `localhost`. | ||
| - You use the **Java** tracer. Its flag evaluation metrics exporter supports OTLP/HTTP only (gRPC is not supported) and uses port `4318`. It does not derive the endpoint from `DD_AGENT_HOST` and defaults to `http://localhost:4318`. Set `OTEL_EXPORTER_OTLP_ENDPOINT` to the Agent's HTTP endpoint when the Agent is not on `localhost`. |
There was a problem hiding this comment.
Suggestion: This bullet has grown to four sentences and mixes protocol support, port, default endpoint, and configuration guidance. Since the Java tracer already has its own subsection above, consider trimming this bullet to just the endpoint/DD_AGENT_HOST behavior and moving the OTLP/HTTP-only + port 4318 detail into the Java subsection where it fits with the rest of the Java-specific setup.
There was a problem hiding this comment.
🤖 Response from Claude: Keeping the protocol/port detail in this bullet. The sibling Python bullet documents its transport the same way (gRPC on 4317), so keeping Java's HTTP/4318 detail here is parallel and keeps the endpoint-transport facts together in this section. I already trimmed it in a503090 (four sentences to three). Happy to split it into a dedicated Java endpoint callout in a follow-up if you'd prefer.
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
After simplifying the Step 2 lead-in, add a note that the Java tracer does not use DD_METRICS_OTEL_ENABLED and points readers to the Java OpenTelemetry SDK dependencies section instead. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
/review |
There was a problem hiding this comment.
🤖 Automated review by Claude. AI-generated; verify before acting.
Clean, well-structured update. All version bumps are consistent across the three touched pages, the new Java subsection is complete with dependency snippets, BOM guidance, and a targeted Spring Boot troubleshooting callout, and cross-links ([6], [8], [9]) and anchors all resolve. No blockers or style nits worth flagging.
Reviewed 0823ed97a4fb4639eed2d309486d5832a6325fb3 — workflow run
What does this PR do? What is the motivation?
Fixes FFL-2653
Updates the Java feature flags docs to reflect what is actually required to emit the
feature_flag.evaluationsmetric:com.datadoghq:dd-openfeatureexamples to1.63.0and notes that flag evaluation metrics require1.62.0or later.DD_METRICS_OTEL_ENABLED— is what enables the metric.NoClassDefFoundError: io/opentelemetry/sdk/internal/ScopeConfiguratorstartup failure and the OpenTelemetry BOM fix.Pages changed:
content/en/feature_flags/server/java.mdcontent/en/feature_flags/guide/server_flag_evaluation_metrics.mdcontent/en/feature_flags/implementation_patterns/opentelemetry.mdcontent/en/getting_started/feature_flags/_index.mdTechnical claims (dependency artifacts, the
1.62.0metrics floor, the OTLP endpoint behavior, and theScopeConfiguratorroot cause) were verified against thedd-trace-javasource at release tagsv1.62.0–v1.63.2.Merge instructions
Merge readiness:
Additional notes