diff --git a/config/_default/menus/api.en.yaml b/config/_default/menus/api.en.yaml index 27bb741f155..851b3e8ff29 100644 --- a/config/_default/menus/api.en.yaml +++ b/config/_default/menus/api.en.yaml @@ -9436,9 +9436,9 @@ menu: - GetTeamOnCallUsers unstable: [] order: 12 - - name: Get the schedule on-call user - url: '#get-the-schedule-on-call-user' - identifier: on-call-get-the-schedule-on-call-user + - name: Get scheduled on-call user + url: '#get-scheduled-on-call-user' + identifier: on-call-get-scheduled-on-call-user parent: on-call generated: true params: diff --git a/config/_default/menus/main.en.yaml b/config/_default/menus/main.en.yaml index b45da123fad..bbc3082c2a7 100644 --- a/config/_default/menus/main.en.yaml +++ b/config/_default/menus/main.en.yaml @@ -3631,41 +3631,46 @@ menu: parent: nm_parent identifier: cnm weight: 1 + - name: CNM Terms and Concepts + url: network_monitoring/cloud_network_monitoring/glossary + parent: cnm + identifier: cnm_glossary + weight: 101 - name: Setup url: network_monitoring/cloud_network_monitoring/setup/ parent: cnm identifier: cnm_setup - weight: 101 + weight: 102 - name: Network Health url: network_monitoring/cloud_network_monitoring/network_health/ parent: cnm identifier: cnm_network_health - weight: 102 + weight: 103 - name: Network Analytics url: network_monitoring/cloud_network_monitoring/network_analytics/ parent: cnm identifier: cnm_analytics - weight: 103 + weight: 104 - name: Tags Reference url: network_monitoring/cloud_network_monitoring/tags_reference/ parent: cnm_analytics identifier: cnm_analytics_tags_reference - weight: 10000 + weight: 10401 - name: Network Map url: network_monitoring/cloud_network_monitoring/network_map/ parent: cnm identifier: cnm_map - weight: 104 + weight: 105 - name: Guides url: network_monitoring/cloud_network_monitoring/guide/ identifier: cnm_guides parent: cnm - weight: 105 + weight: 106 - name: Supported Cloud Services url: network_monitoring/cloud_network_monitoring/supported_cloud_services/ identifier: cnm_supported_cloud_services parent: cnm - weight: 106 + weight: 10601 - name: DNS Monitoring url: network_monitoring/dns/ parent: nm_parent @@ -3675,7 +3680,7 @@ menu: url: network_monitoring/devices parent: nm_parent identifier: ndm - weight: 3 + weight: 3 - name: NDM Terms and Concepts url: network_monitoring/devices/glossary parent: ndm @@ -3690,67 +3695,67 @@ menu: url: network_monitoring/devices/supported_devices parent: ndm_setup identifier: ndm_supported_devices - weight: 30001 + weight: 30301 - name: SNMP Metrics url: network_monitoring/devices/snmp_metrics parent: ndm_setup identifier: ndm_snmp_metrics - weight: 30002 + weight: 30302 - name: SNMP Traps url: network_monitoring/devices/snmp_traps parent: ndm_setup identifier: ndm_snmptraps - weight: 30003 + weight: 30303 - name: Ping url: network_monitoring/devices/ping parent: ndm_setup identifier: ndm_snmp_ping - weight: 30004 + weight: 30304 - name: Syslog url: network_monitoring/devices/syslog parent: ndm_setup identifier: ndm_syslog - weight: 30005 + weight: 30305 - name: VPN Monitoring url: network_monitoring/devices/vpn_monitoring parent: ndm_setup identifier: ndm_vpn_monitoring - weight: 30006 + weight: 30306 - name: Integrations url: network_monitoring/devices/integrations parent: ndm identifier: ndm_integrations - weight: 303 + weight: 304 - name: Profiles url: network_monitoring/devices/profiles parent: ndm identifier: ndm_profiles - weight: 304 + weight: 305 - name: Configuration Management url: network_monitoring/devices/config_management parent: ndm identifier: ndm_config_management - weight: 305 + weight: 306 - name: Maps url: network_monitoring/devices/topology parent: ndm identifier: ndm_network_maps - weight: 306 + weight: 307 - name: SNMP Metrics Reference url: network_monitoring/devices/data parent: ndm identifier: ndm_data - weight: 307 + weight: 308 - name: Troubleshooting url: network_monitoring/devices/troubleshooting parent: ndm identifier: ndm_trouble - weight: 308 + weight: 309 - name: Guides url: network_monitoring/devices/guide/ parent: ndm identifier: ndm_guide - weight: 309 + weight: 310 - name: NetFlow Monitoring url: /network_monitoring/netflow/ parent: nm_parent @@ -3766,26 +3771,31 @@ menu: parent: nm_parent identifier: network_path weight: 5 + - name: Terms and Concepts + url: network_monitoring/network_path/glossary + parent: network_path + identifier: network_path_glossary + weight: 501 - name: Setup url: network_monitoring/network_path/setup/ parent: network_path identifier: network_path_setup - weight: 501 + weight: 502 - name: List View url: network_monitoring/network_path/list_view/ parent: network_path identifier: network_path_list_view - weight: 502 + weight: 503 - name: Path View url: network_monitoring/network_path/path_view/ parent: network_path identifier: network_path_path_view - weight: 503 + weight: 504 - name: Guides url: network_monitoring/network_path/guide parent: network_path identifier: network_path_guides - weight: 504 + weight: 505 - name: Storage Management url: /infrastructure/storage_management/ pre: file-wui diff --git a/content/en/feature_flags/server/java.md b/content/en/feature_flags/server/java.md index 0b416b40626..6f35c688496 100644 --- a/content/en/feature_flags/server/java.md +++ b/content/en/feature_flags/server/java.md @@ -5,20 +5,616 @@ further_reading: - link: "/feature_flags/server/" tag: "Documentation" text: "Server-Side Feature Flags" -- link: "/tracing/trace_collection/dd_libraries/java/" +- link: "/tracing/trace_collection/automatic_instrumentation/dd_libraries/java/" tag: "Documentation" - text: "Java Tracing" + text: "Java APM and Distributed Tracing" --- {{< callout url="http://datadoghq.com/product-preview/feature-flags/" >}} Feature Flags are in Preview. Complete the form to request access. {{< /callout >}} +
Java Feature Flags support is experimental and requires enabling an experimental flag in the tracer. See the Configuration section for details.
+ ## Overview -This page describes how to instrument your Java application with the Datadog Feature Flags SDK. +This page describes how to instrument a Java application with the Datadog Feature Flags SDK. Datadog feature flags provide a unified way to remotely control feature availability in your app, experiment safely, and deliver new experiences with confidence. + +The Java SDK integrates feature flags directly into the Datadog APM tracer and implements the [OpenFeature](https://openfeature.dev/) standard for maximum flexibility and compatibility. + +
If you're using Datadog APM and your application already has the Datadog Java tracer and Remote Configuration enabled, skip to Initialize the OpenFeature provider. You only need to add the OpenFeature dependencies and initialize the provider.
+ +## Compatibility requirements + +The Datadog Feature Flags SDK for Java requires: +- **Java 11 or higher** +- **Datadog Java APM Tracer**: Version **1.57.0** or later +- **OpenFeature SDK**: Version **1.18.2** or later +- **Datadog Agent**: Version **7.x or later** with Remote Configuration enabled +- **Datadog API Key**: Required for Remote Configuration + +For a full list of Datadog's Java version and framework support, read [Compatibility Requirements](/tracing/trace_collection/compatibility/java/). + +## Getting started + +Before you begin, make sure you've already [installed and configured the Agent](/tracing/trace_collection/automatic_instrumentation/dd_libraries/java/#install-and-configure-the-agent). + +## Installation + +Feature flagging is integrated into the Datadog Java APM tracer. You need the tracer JAR and the OpenFeature SDK dependencies. + +The `dd-java-agent-feature-flagging-bootstrap` JAR contains shared interfaces that enable the Datadog tracer (running in the bootstrap classloader) to communicate with the OpenFeature provider (running in the application classloader). This is a standard pattern for Java agents. Both JARs are required for feature flags to work. + +{{< tabs >}} +{{% tab "Gradle (Groovy)" %}} +Add the following dependencies to your `build.gradle`: + +{{< code-block lang="groovy" filename="build.gradle" >}} +dependencies { + // Datadog Java tracer (includes feature flagging) + implementation 'com.datadoghq:dd-trace-api:X.X.X' + + // OpenFeature SDK for flag evaluation + implementation 'dev.openfeature:sdk:1.18.2' + + // Datadog OpenFeature Provider + implementation 'com.datadoghq:dd-openfeature:X.X.X' + + // Datadog Feature Flagging Bootstrap (required) + implementation 'com.datadoghq:dd-java-agent-feature-flagging-bootstrap:X.X.X' +} +{{< /code-block >}} +{{% /tab %}} + +{{% tab "Gradle (Kotlin)" %}} +Add the following dependencies to your `build.gradle.kts`: + +{{< code-block lang="kotlin" filename="build.gradle.kts" >}} +dependencies { + // Datadog Java tracer (includes feature flagging) + implementation("com.datadoghq:dd-trace-api:X.X.X") + + // OpenFeature SDK for flag evaluation + implementation("dev.openfeature:sdk:1.18.2") + + // Datadog OpenFeature Provider + implementation("com.datadoghq:dd-openfeature:X.X.X") + + // Datadog Feature Flagging Bootstrap (required) + implementation("com.datadoghq:dd-java-agent-feature-flagging-bootstrap:X.X.X") +} +{{< /code-block >}} +{{% /tab %}} + +{{% tab "Maven" %}} +Add the following dependencies to your `pom.xml`: + +{{< code-block lang="xml" filename="pom.xml" >}} + + + + com.datadoghq + dd-trace-api + X.X.X + + + + + dev.openfeature + sdk + 1.18.2 + + + + + com.datadoghq + dd-openfeature + X.X.X + + + + + com.datadoghq + dd-java-agent-feature-flagging-bootstrap + X.X.X + + +{{< /code-block >}} +{{% /tab %}} +{{< /tabs >}} + +## Configuration + +If your Datadog Agent already has Remote Configuration enabled for other features (like Dynamic Instrumentation or Application Security), you can skip the Agent configuration and go directly to [Application configuration](#application-configuration). + +### Agent configuration + +Configure your Datadog Agent to enable Remote Configuration: + +{{< code-block lang="yaml" filename="datadog.yaml" >}} +# Enable Remote Configuration +remote_configuration: + enabled: true + +# Set your API key +api_key: +{{< /code-block >}} + +### Application configuration + +If your application already runs with `-javaagent:dd-java-agent.jar` and has Remote Configuration enabled (`DD_REMOTE_CONFIG_ENABLED=true`), you only need to add the experimental feature flag (`DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED=true`). Skip the tracer download and JVM configuration steps. + +Configure your Java application with the required environment variables or system properties: + +{{< tabs >}} +{{% tab "Environment Variables" %}} +{{< code-block lang="bash" >}} +# Required: Enable Remote Configuration in the tracer +export DD_REMOTE_CONFIG_ENABLED=true + +# Required: Enable experimental feature flagging support +export DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED=true + +# Required: Your Datadog API key +export DD_API_KEY= + +# Required: Service name +export DD_SERVICE= + +# Required: Environment (e.g., prod, staging, dev) +export DD_ENV= + +# Optional: Version +export DD_VERSION= + +# Start your application with the tracer +java -javaagent:path/to/dd-java-agent.jar -jar your-application.jar +{{< /code-block >}} +{{% /tab %}} + +{{% tab "System Properties" %}} +{{< code-block lang="bash" >}} +java -javaagent:path/to/dd-java-agent.jar \ + -Ddd.remote.config.enabled=true \ + -Ddd.experimental.flagging.provider.enabled=true \ + -Ddd.api.key= \ + -Ddd.service= \ + -Ddd.env= \ + -Ddd.version= \ + -jar your-application.jar +{{< /code-block >}} +{{% /tab %}} +{{< /tabs >}} + +The Datadog feature flagging system starts automatically when the tracer is initialized with both Remote Configuration and the experimental flagging provider enabled. No additional initialization code is required in your application. + +
Feature flagging requires both DD_REMOTE_CONFIG_ENABLED=true and DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED=true. Without the experimental flag, the feature flagging system does not start and the Provider returns the programmatic default.
+ +### Add the Java tracer to the JVM + +For instructions on how to add the `-javaagent` argument to your application server or framework, see [Add the Java Tracer to the JVM](/tracing/trace_collection/automatic_instrumentation/dd_libraries/java/#add-the-java-tracer-to-the-jvm). + +Make sure to include the feature flagging configuration flags: +- `-Ddd.remote.config.enabled=true` +- `-Ddd.experimental.flagging.provider.enabled=true` + +## Initialize the OpenFeature provider + +Initialize the Datadog OpenFeature provider in your application startup code. The provider connects to the feature flagging system running in the Datadog tracer. + +{{< code-block lang="java" >}} +import dev.openfeature.sdk.OpenFeatureAPI; +import dev.openfeature.sdk.Client; +import datadog.trace.api.openfeature.Provider; +import dev.openfeature.sdk.exceptions.ProviderNotReadyError; +import org.slf4j.Logger; +import org.slf4j.LoggerFactory; + +public class App { + private static final Logger logger = LoggerFactory.getLogger(App.class); + private static Client client; + + public static void main(String[] args) throws Exception { + // Initialize the Datadog provider + logger.info("Initializing Datadog OpenFeature Provider..."); + OpenFeatureAPI api = OpenFeatureAPI.getInstance(); + + try { + // Set provider and wait for initial configuration (recommended) + api.setProviderAndWait(new Provider()); + client = api.getClient("my-app"); + logger.info("OpenFeature provider initialized successfully"); + } catch (ProviderNotReadyError e) { + // Optional: Handle gracefully - app will use default flag values + logger.warn("Provider not ready (no tracer/configuration available), continuing with defaults", e); + client = api.getClient("my-app"); + logger.info("App will use default flag values until provider is ready"); + } + + // Your application code here + } +} +{{< /code-block >}} + +Use `setProviderAndWait()` to block until the initial flag configuration is received from Remote Configuration. This ensures flags are ready before the application starts serving traffic. The default timeout is 30 seconds. + +`ProviderNotReadyError` is an OpenFeature SDK exception thrown when the provider times out during initialization. Catching it allows the application to start with default flag values if Remote Configuration is unavailable. If not caught, the exception propagates and may prevent application startup. Handle this based on your availability requirements. + +### Asynchronous initialization + +For non-blocking initialization, use `setProvider()` and listen for provider events: + +{{< code-block lang="java" >}} +import dev.openfeature.sdk.ProviderEvent; + +OpenFeatureAPI api = OpenFeatureAPI.getInstance(); +Client client = api.getClient(); + +// Listen for provider state changes +client.on(ProviderEvent.PROVIDER_READY, (event) -> { + logger.info("Feature flags ready!"); +}); + +client.on(ProviderEvent.PROVIDER_ERROR, (event) -> { + logger.error("Provider error: {}", event.getMessage()); +}); + +client.on(ProviderEvent.PROVIDER_STALE, (event) -> { + logger.warn("Provider configuration is stale"); +}); + +// Set provider asynchronously +api.setProvider(new Provider()); +{{< /code-block >}} + +## Set the evaluation context + +The evaluation context defines the subject (user, device, session) for flag evaluation. It determines which flag variations are returned based on targeting rules. + +{{< code-block lang="java" >}} +import dev.openfeature.sdk.EvaluationContext; +import dev.openfeature.sdk.MutableContext; + +// Create an evaluation context with a targeting key and attributes +EvaluationContext context = new MutableContext("user-123") + .add("email", "user@example.com") + .add("tier", "premium"); + +// Use the context for flag evaluations (see next section) +{{< /code-block >}} + +The `targetingKey` (for example, `user-123`) is the primary identifier used for consistent flag evaluations and percentage-based rollouts. It's typically a user ID, session ID, or device ID. + +## Evaluate flags + +Evaluate feature flags using the OpenFeature client. All flag types are supported: Boolean, string, integer, double, and object. + +{{< tabs >}} +{{% tab "Boolean" %}} +{{< code-block lang="java" >}} +// Simple Boolean evaluation +boolean enabled = client.getBooleanValue("checkout.new", false, context); + +if (enabled) { + // New checkout flow +} else { + // Old checkout flow +} + +// Get detailed evaluation result +import dev.openfeature.sdk.FlagEvaluationDetails; + +FlagEvaluationDetails details = + client.getBooleanDetails("checkout.new", false, context); + +logger.info("Value: {}", details.getValue()); +logger.info("Variant: {}", details.getVariant()); +logger.info("Reason: {}", details.getReason()); +{{< /code-block >}} +{{% /tab %}} + +{{% tab "String" %}} +{{< code-block lang="java" >}} +// Evaluate string flags (e.g., UI themes, API endpoints) +String theme = client.getStringValue("ui.theme", "light", context); + +String apiEndpoint = client.getStringValue( + "payment.api.endpoint", + "https://api.example.com/v1", + context +); +{{< /code-block >}} +{{% /tab %}} + +{{% tab "Number" %}} +{{< code-block lang="java" >}} +// Integer flags (e.g., limits, quotas) +int maxRetries = client.getIntegerValue("retries.max", 3, context); + +// Double flags (e.g., thresholds, rates) +double discountRate = client.getDoubleValue("pricing.discount.rate", 0.0, context); +{{< /code-block >}} +{{% /tab %}} + +{{% tab "Object" %}} +{{< code-block lang="java" >}} +import dev.openfeature.sdk.Value; + +// Evaluate object/JSON flags for complex configuration +Value config = client.getObjectValue("ui.config", new Value(), context); + +// Access structured data +if (config.isStructure()) { + Value timeout = config.asStructure().getValue("timeout"); + Value endpoint = config.asStructure().getValue("endpoint"); +} +{{< /code-block >}} +{{% /tab %}} +{{< /tabs >}} + +## Error handling + +The OpenFeature SDK uses a default value pattern. If evaluation fails for any reason, the default value you provide is returned. + +{{< code-block lang="java" >}} +import dev.openfeature.sdk.ErrorCode; + +// Check evaluation details for errors +FlagEvaluationDetails details = + client.getBooleanDetails("checkout.new", false, context); + +if (details.getErrorCode() != null) { + switch (details.getErrorCode()) { + case FLAG_NOT_FOUND: + logger.warn("Flag does not exist: {}", "checkout.new"); + break; + case PROVIDER_NOT_READY: + logger.warn("Provider not initialized yet"); + break; + case TARGETING_KEY_MISSING: + logger.warn("Evaluation context missing targeting key"); + break; + case TYPE_MISMATCH: + logger.error("Flag value type doesn't match requested type"); + break; + default: + logger.error("Evaluation error for flag: {}", "checkout.new", details.getErrorCode()); + } +} +{{< /code-block >}} + +### Common error codes + +| Error Code | Description | Resolution | +|------------|-------------|------------| +| `PROVIDER_NOT_READY` | Initial configuration not received | Wait for provider initialization or use `setProviderAndWait()` | +| `FLAG_NOT_FOUND` | Flag doesn't exist in configuration | Check flag key or create flag in Datadog UI | +| `TARGETING_KEY_MISSING` | No targeting key in evaluation context | Provide a targeting key when creating context | +| `TYPE_MISMATCH` | Flag value can't be converted to requested type | Use correct evaluation method for flag type | +| `INVALID_CONTEXT` | Evaluation context is null | Provide a valid evaluation context | + +## Advanced configuration + +### Custom initialization timeout + +Configure how long the provider waits for initial configuration: + +{{< code-block lang="java" >}} +import datadog.trace.api.openfeature.Provider; +import java.util.concurrent.TimeUnit; + +Provider.Options options = new Provider.Options() + .initTimeout(10, TimeUnit.SECONDS); + +api.setProviderAndWait(new Provider(options)); +{{< /code-block >}} + +### Configuration change events + +Listen for configuration updates from Remote Configuration: + +{{< code-block lang="java" >}} +import dev.openfeature.sdk.ProviderEvent; + +client.on(ProviderEvent.PROVIDER_CONFIGURATION_CHANGED, (event) -> { + logger.info("Flag configuration updated: {}", event.getMessage()); + // Optionally re-evaluate flags or trigger cache refresh +}); +{{< /code-block >}} + +`PROVIDER_CONFIGURATION_CHANGED` is an optional OpenFeature event. Check the Datadog provider documentation to verify this event is supported in your version. + +### Multiple clients + +Use named clients to organize context and flags by domain or team: + +{{< code-block lang="java" >}} +// Named clients share the same provider instance but can have different contexts +Client checkoutClient = api.getClient("checkout"); +Client analyticsClient = api.getClient("analytics"); + +// Each client can have its own evaluation context +EvaluationContext checkoutContext = new MutableContext("session-abc"); +EvaluationContext analyticsContext = new MutableContext("user-123"); + +boolean newCheckout = checkoutClient.getBooleanValue( + "checkout.ui.new", false, checkoutContext +); + +boolean enhancedAnalytics = analyticsClient.getBooleanValue( + "analytics.enhanced", false, analyticsContext +); +{{< /code-block >}} + +The `Provider` instance is shared globally. Client names are for organizational purposes only and don't create separate provider instances. All clients use the same underlying Datadog provider and flag configurations. + +## Best practices + +### Initialize early +Initialize the OpenFeature provider as early as possible in your application lifecycle (for example, in `main()` or application startup). This ensures flags are ready before business logic executes. + +### Use meaningful default values +Always provide sensible default values that maintain safe behavior if flag evaluation fails: + +{{< code-block lang="java" >}} +// Good: Safe default that maintains current behavior +boolean useNewAlgorithm = client.getBooleanValue("algorithm.new", false, context); + +// Good: Conservative default for limits +int rateLimit = client.getIntegerValue("rate.limit", 100, context); +{{< /code-block >}} + +### Create context once +Create the evaluation context once per request/user/session and reuse it for all flag evaluations: + +{{< code-block lang="java" >}} +// In a web filter or request handler +EvaluationContext userContext = new MutableContext(userId) + .add("email", user.getEmail()) + .add("tier", user.getTier()); + +// Reuse context for all flags in this request +boolean featureA = client.getBooleanValue("feature.a", false, userContext); +boolean featureB = client.getBooleanValue("feature.b", false, userContext); +{{< /code-block >}} + +Rebuilding the evaluation context for every flag evaluation adds unnecessary overhead. Create the context once at the start of the request lifecycle, then pass it to all subsequent flag evaluations. + +### Handle initialization failures (optional) +Consider handling initialization failures if your application can function with default flag values: + +{{< code-block lang="java" >}} +try { + api.setProviderAndWait(new Provider()); +} catch (ProviderNotReadyError e) { + // Log error and continue with defaults + logger.warn("Feature flags not ready, using defaults", e); + // Application will use default values for all flags +} +{{< /code-block >}} + +If feature flags are critical for your application to function, let the exception propagate to prevent startup. + +### Use consistent targeting keys +Use consistent, stable identifiers as targeting keys: +- **Good**: User IDs, session IDs, device IDs +- **Avoid**: Timestamps, random values, frequently changing IDs + +### Monitor flag evaluation +Use the detailed evaluation results for logging and debugging: + +{{< code-block lang="java" >}} +FlagEvaluationDetails details = + client.getBooleanDetails("feature.critical", false, context); + +logger.info("Flag: {} | Value: {} | Variant: {} | Reason: {}", + "feature.critical", + details.getValue(), + details.getVariant(), + details.getReason() +); +{{< /code-block >}} + +## Troubleshooting + +### Provider not ready + +**Problem**: `PROVIDER_NOT_READY` errors when evaluating flags + +**Common Causes**: +1. **Experimental flag not enabled**: Feature flagging is disabled by default +2. **Agent not ready**: Application started before Agent was fully initialized +3. **No flags configured**: No flags published to your service/environment combination +4. **Agent Remote Configuration disabled**: Agent not configured for Remote Configuration + +**Solutions**: +1. **Enable experimental feature**: + ```bash + export DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED=true + ``` +2. **Verify feature flagging system started** in application logs: + ``` + [dd.trace] Feature Flagging system starting + [dd.trace] Feature Flagging system started + ``` +3. **Ensure Agent is ready** before app starts (use health checks in Docker/Kubernetes) +4. **Check EVP Proxy discovered** in logs: + ``` + discovered ... evpProxyEndpoint=evp_proxy/v4/ configEndpoint=v0.7/config + ``` +5. **Wait for Remote Configuration sync** (can take 30-60 seconds after publishing flags) +6. **Verify flags are published** in Datadog UI to the correct service and environment + +### ClassNotFoundException or NoClassDefFoundError + +**Problem**: Application fails to start with `ClassNotFoundException` for Datadog classes like `datadog.trace.api.featureflag.FeatureFlaggingGateway` + +**Cause**: Missing the bootstrap JAR dependency. The bootstrap module contains shared interfaces that allow the Datadog tracer (running in the bootstrap classloader) to communicate with the OpenFeature provider (running in the application classloader). Without it, the two components cannot interact. + +**Solutions**: +1. **Add the bootstrap JAR** to your dependencies: + ```xml + + com.datadoghq + dd-java-agent-feature-flagging-bootstrap + X.X.X + + ``` +2. **Verify both dependencies are included** in your build: + - `dd-openfeature` (the OpenFeature provider) + - `dd-java-agent-feature-flagging-bootstrap` (the bootstrap module) +3. **Check the classpath** includes both JARs in your runtime configuration + +### Feature flagging system not starting + +**Problem**: No "Feature Flagging system starting" messages in logs + +**Cause**: Experimental flag not enabled in tracer + +**Solution**: +Add `-Ddd.experimental.flagging.provider.enabled=true` to your Java command or set `DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED=true` + +### EVP proxy not available error + +**Problem**: Logs show "EVP Proxy not available" or "agent does not support EVP proxy" + +**Cause**: Application started before Agent was fully initialized + +**Solutions**: +1. **Add Agent health check** in orchestration (Docker Compose, Kubernetes) +2. **Add startup delay** to application +3. **Retry logic**: Implement retry on provider initialization failure +4. **Upgrade Agent**: Ensure using Agent 7.x or later with EVP Proxy support + +### Flags not updating + +**Problem**: Flag configuration changes aren't reflected in the application + +**Solutions**: +1. Check Remote Configuration is enabled on both Agent and application +2. Verify Agent can connect to Datadog backend +3. Check application logs for "No configuration changes" or "Configuration received" +4. Ensure flags are published (not saved as drafts) in the Datadog UI +5. Verify service and environment tags match between app and flag targeting + +### Type mismatch errors + +**Problem**: `TYPE_MISMATCH` errors when evaluating flags + +**Solutions**: +1. Verify the flag type in Datadog UI matches the evaluation method +2. Use correct method: `getBooleanValue()`, `getStringValue()`, `getIntegerValue()`, `getDoubleValue()` +3. Check flag configuration for correct value types + +### No exposures in Datadog + +**Problem**: Flag evaluations aren't appearing in Datadog UI -Documentation coming soon. +**Solutions**: +1. Verify the flag's allocation has `doLog=true` configured +2. Check Datadog Agent is receiving exposure events +3. Verify `DD_API_KEY` is correct +4. Check Agent logs for exposure upload errors ## Further reading diff --git a/content/en/network_monitoring/cloud_network_monitoring/glossary.md b/content/en/network_monitoring/cloud_network_monitoring/glossary.md new file mode 100644 index 00000000000..96467c75064 --- /dev/null +++ b/content/en/network_monitoring/cloud_network_monitoring/glossary.md @@ -0,0 +1,53 @@ +--- +title: CNM Terms and Concepts +description: Glossary for Cloud Network Monitoring (CNM) +further_reading: + - link: '/network_monitoring/cloud_network_monitoring/setup/' + tag: 'Documentation' + text: 'Setting Up Cloud Network Monitoring' + - link: '/network_monitoring/cloud_network_monitoring/tags_reference/' + tag: 'Documentation' + text: 'CNM Tags Reference' + - link: '/monitors/types/cloud_network_monitoring/' + tag: 'Documentation' + text: 'CNM Monitors and Alerts' + - link: '/network_monitoring/network_path/glossary' + tag: 'Documentation' + text: 'Network Path Glossary' +--- + +## Overview + +Cloud Network Monitoring (CNM) provides end-to-end visibility into network communication across services, containers, hosts, and cloud environments. It aggregates connection-level data into meaningful service-to-service dependencies, helping you analyze traffic patterns, troubleshoot latency and connectivity issues, and monitor the health of your applications. + +For additional definitions and descriptions of important CNM terms such as _policy based routing_, see the [main Glossary][6]. + +## Terminology + +| Concept | Description | +| ------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| **Cloud Network Monitoring (CNM)** | Cloud Network Monitoring (CNM) provides visibility into network traffic between services, containers, availability zones, and other tags in Datadog, aggregating raw connection-level data (IP, port, PID) into application-layer dependencies between client and server endpoints. | +| **Flow data** | The low-level data collected by CNM (connections at IP, port, PID levels) that CNM uses to build higher-level representations of network dependencies and traffic flow. | +| **Network Address Translation (NAT)** | A method for remapping one IP address to another. This allows multiple devices on a private network to share a single public IP address to connect to the internet. | +| **[Network Health][1]** | Displays the overall health of network connections, surfacing connectivity problems and degraded network performance across hosts and services. | +| **[Network Analytics][2]** | A CNM view that lets you graph and analyze network data between each client and server based on grouping tags, so you can investigate traffic patterns, dependencies, or anomalies. | +| **[Network Map][3]** | A visualization view in CNM that maps network data between tags such as `service`, `kube_service`, `short_image`, and `container_name`. | +| **[CNM Monitor][4]** | A Datadog monitor that alerts when a CNM (TCP network) metric crosses a user-defined threshold, for example network throughput between a specific client and server. | +| **[CNM tags][5]** | Tags that CNM uses to group and display traffic, for example, service-to-service or zone-to-zone communication. | +| **[Traffic volume][9] (Bytes Sent and Received)** | A primary network metric in CNM representing the amount of data transferred between endpoints. Often visualized in the network load section of dashboards or the network analytics page to spot spikes or traffic bottlenecks. | +| **[TCP metrics][8] (Connections, Retransmits, Latency)** | Metrics CNM tracks for TCP flows, including open and closed connections, packet retransmissions, and round-trip time to detect connectivity issues, packet loss, or network congestion. | +| **[Unresolved or NA traffic][10]** | Network flows that cannot be associated with defined tags (client or server). Often shown as "unresolved" or "NA," indicating that the origin or destination cannot be identified or grouped meaningfully. | + +## Further Reading + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /network_monitoring/cloud_network_monitoring/network_health/ +[2]: /network_monitoring/cloud_network_monitoring/network_analytics/ +[3]: /network_monitoring/cloud_network_monitoring/network_map/ +[4]: /monitors/types/cloud_network_monitoring/ +[5]: /network_monitoring/cloud_network_monitoring/tags_reference/ +[6]: /glossary/?product=cloud-network-monitoring +[8]: /network_monitoring/cloud_network_monitoring/network_analytics/#tcp +[9]: /network_monitoring/cloud_network_monitoring/network_analytics/#network-load +[10]: /network_monitoring/cloud_network_monitoring/network_analytics/#unresolved-traffic \ No newline at end of file diff --git a/content/en/network_monitoring/devices/glossary.md b/content/en/network_monitoring/devices/glossary.md index e4b9ba09210..7be0f313fda 100644 --- a/content/en/network_monitoring/devices/glossary.md +++ b/content/en/network_monitoring/devices/glossary.md @@ -9,7 +9,7 @@ further_reading: ## Overview -Network Device Monitoring helps you gain insights into the health and performance of your on-prem routers, switches, and firewalls. +Network Device Monitoring (NDM) helps you gain insights into the health and performance of your on-prem routers, switches, and firewalls. For additional definitions and descriptions of important NDM terms such as _layer 2_ and _layer 3_, see the main [Glossary][1]. ## Terminology @@ -17,6 +17,12 @@ For additional definitions and descriptions of important NDM terms such as _laye Simple network management protocol (SNMP) : A network protocol that is used to collect information about bare metal networking gear. +Link Layer Discovery Protocol (LLDP) +: A protocol used by devices to advertise identity and capabilities to neighboring devices. NDM uses LLDP to map topology. + +Managed information base (MIB) +: A database or list of all the possible OIDs and their definitions that are related to the MIB. For example, the `IF-MIB` (interface MIB) contains all the OIDs for descriptive information about a device's interface. + Object identifier (OID) : A unique ID or address on a device that when polled returns the response code of that value. For example, OIDs are CPU or device fan speed. @@ -35,7 +41,7 @@ Software-defined wide area network (SD-WAN) [Device namespaces][3] : Namespace of the device. Namespaces can be used as tags to differentiate between multiple network devices that may share the same private IP. -Ping +[Ping][4] : A network tool that measures how long it takes for a signal to travel from one device to another over a network and back again. @@ -43,6 +49,7 @@ Ping {{< partial name="whats-next/whats-next.html" >}} -[1]: /glossary/ +[1]: /glossary/?product=network-device-monitoring [2]: /network_monitoring/devices/profiles -[3]: /network_monitoring/devices/snmp_traps/?tab=yaml#device-namespaces \ No newline at end of file +[3]: /network_monitoring/devices/snmp_traps/?tab=yaml#device-namespaces +[4]: /network_monitoring/devices/ping \ No newline at end of file diff --git a/content/en/network_monitoring/network_path/glossary.md b/content/en/network_monitoring/network_path/glossary.md new file mode 100644 index 00000000000..babfd101bfd --- /dev/null +++ b/content/en/network_monitoring/network_path/glossary.md @@ -0,0 +1,57 @@ +--- +title: Network Path Terms and Concepts +description: Glossary for Network Path +further_reading: + - link: '/network_monitoring/cloud_network_monitoring/setup/' + tag: 'Documentation' + text: 'Setting Up Cloud Network Monitoring' + - link: '/network_monitoring/cloud_network_monitoring/tags_reference/' + tag: 'Documentation' + text: 'CNM Tags Reference' + - link: '/monitors/types/cloud_network_monitoring/' + tag: 'Documentation' + text: 'CNM Monitors and Alerts' +--- + +## Network Path + +Network Path provides hop-by-hop visibility into the route between a source and destination, helping you identify where latency, packet loss, or routing changes occur. + +## Terminology +| Concept | Description | +| --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| **[Network Path][6]** | Network Path provides hop-by-hop visibility into the route between a source and a destination, so you can identify where latency, packet loss, or routing changes occur. | +| **Autonomous System (AS / ASN)** | A collection of IP routing prefixes managed by a single network operator. Network Path groups hop by Autonomous System (AS) or Autonomous System Number (ASN) to show routing domains along the path. +| **[Path View][7]** | The Network Path visualization that displays each hop, grouped by Autonomous System Number (ASN), region, or network, along with probe status and hop metrics. | +| **Hop** | A network node along a route between source and destination, identified by IP address and associated metadata (ASN, cloud region, provider). | | +| **Source** | The starting point of a Network Path probe, typically an Agent-monitored host or container running the Datadog network monitoring tracer. | +| **Destination** | The endpoint that the Network Path probe is targeting, such as a service, public endpoint, or domain. | +| **Traceroute** | The mechanism that Network Path uses to determine intermediate hops and latency. CNM sends controlled probes, similar to traceroute, to discover each hop on the route. | +| **Latency per hop** | The round-trip time between the probe source and each hop. This helps identify slow or congested nodes. | +| **Packet loss per hop** | The percentage of probe packets dropped before reaching or returning from a hop, useful for diagnosing reliability issues. | + +### Path View +| Concept | Description | +| ----------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| **Aggregated hop** | A group of multiple identical hops (same IP, ASN, region), collapsed into a single representation to simplify visualization. | +| **ICMP timeout or no response** | A hop where no ICMP response was received. Often appears as a gray or unknown hop in the Path View. | +| **Missing hop** | A point in the path where the probe cannot identify a network node, often due to firewall filtering, ICMP rate limits, or private routing. Displayed as a dashed or empty hop. | +| **Path change indicator** | A visual marker that shows when the observed route changes over time, for example an AS shift or a new hop. | +| **AS grouping** | The cluster of hops belonging to the same Autonomous System, helping identify which network operator controls each segment of the path. | +| **Region grouping** | The cluster of hops located within the same cloud region or geographic region. Helpful for identifying inter-regional routing. +| **Start node** | The initial node (source) where the probe begins. Represented at the far left of the Path View. | +| **End node** | The destination node where the probe terminates. Represented at the far right of the Path View. | +| **Hop status indicator** | The icon or color indicating whether the hop is healthy, degraded, or unreachable, based on latency and loss. | +| **Probe status** | Shows whether the probe reached a hop successfully, partially, or not at all. This helps you identify where traffic stops or degrades. | | +| **Traversed count** | Represents the number of traceroute active probing packets received by reach hop. Higher counts suggest that the hop is consistently part of the route; lower counts may indicate path instability. | +| **Traversal completion** | Represents whether or not the traceroute was able to successfully reach the destination. | +| **Reachability** | The level of packet loss the destination is experiencing. | +| **Latency** | How long the traceroute took to get from a source to its destination. | + + +## Further Reading + +{{< partial name="whats-next/whats-next.html" >}} + +[6]: /network_monitoring/network_path/ +[7]: /network_monitoring/network_path/path_view \ No newline at end of file diff --git a/content/en/security/_index.md b/content/en/security/_index.md index 21ade1d7df1..1db45c2aed6 100644 --- a/content/en/security/_index.md +++ b/content/en/security/_index.md @@ -101,7 +101,7 @@ To learn more, check out the [30-second Product Guided Tour][14]. [Cloud SIEM][4] (Security Information and Event Management) detects real-time threats to your application and infrastructure, like a targeted attack, an IP communicating with your systems which matches a threat intel list, or an insecure configuration. Cloud SIEM is powered by [Datadog Log Management][5]. With these areas combined, you can [automate remediation of threats detected by Datadog Cloud SIEM][6] to speed up your threat-response workflow. Check out the dedicated [Guided Tour](https://www.datadoghq.com/guided-tour/security/cloud-siem/) to see more. -{{< img src="security/security_monitoring/cloud_siem_overview_2.png" alt="The Cloud SIEM home page showing the Security Overview section with widgets for important signals, suspicious actors, impacted resources, threat intel, and signal trends" width="100%">}} +{{< img src="security/security_monitoring/cloud_siem_overview_2025.png" alt="The Cloud SIEM home page showing the Security Overview section with widgets for important signals, suspicious actors, impacted resources, threat intel, and signal trends" width="100%">}} ## Code Security diff --git a/content/en/security/application_security/setup/aws/waf/_index.md b/content/en/security/application_security/setup/aws/waf/_index.md index a83d93b64de..129c3146f45 100644 --- a/content/en/security/application_security/setup/aws/waf/_index.md +++ b/content/en/security/application_security/setup/aws/waf/_index.md @@ -28,7 +28,7 @@ Both can be set up independently, but it is recommended to first set up the conv ## Prerequisites - The [Amazon Web Services integration][1] is setup. - - Metrics, and Logs collection are enabled on the [AWS WAF integration][2]. + - Metrics, and Logs collection are enabled on the [AWS WAF integration][2]. Note that only logs sent to an S3 bucket are collected by the AWS WAF integration. - A [Connection][3] is created with the AWS account hosting the AWS WAF used for blocking. ## Convert AWS WAF logs to traces diff --git a/content/en/security/code_security/iast/setup/_index.md b/content/en/security/code_security/iast/setup/_index.md index 846414227af..ba98f057365 100644 --- a/content/en/security/code_security/iast/setup/_index.md +++ b/content/en/security/code_security/iast/setup/_index.md @@ -769,26 +769,11 @@ The Python Application Security Client library follows a [versioning policy][3] Two release branches are supported: -| Release | Support level | Minimum Datadog Agent | -|------------|--------------------------------------------|-----------------------| -| `>=3.0,<4` | General Availability | 7.28 | -| `>=2.0,<3` | End of Life | 7.28 | -| `<2` | End of Life | | +{{< partial name="trace_collection/python/supported_versions.html" >}} And the library supports the following runtimes: -| OS | CPU | Runtime | Runtime version | Supported ddtrace versions | -|---------|-----------------------|---------|-----------------|----------------------------| -| Linux | x86-64, i686, AArch64 | CPython | 3.8+ | `>=3,<4` | -| MacOS | Intel, Apple Silicon | CPython | 3.8+ | `>=3,<4` | -| Windows | 64bit, 32bit | CPython | 3.8+ | `>=3,<4` | -| Linux | x86-64, i686, AArch64 | CPython | 3.7-3.13 | `>=2,<3` | -| MacOS | Intel, Apple Silicon | CPython | 3.7-3.13 | `>=2,<3` | -| Windows | 64bit, 32bit | CPython | 3.7-3.13 | `>=2,<3` | -| Linux | x86-64, i686, AArch64 | CPython | 2.7, 3.5-3.11 | `<2` | -| MacOS | Intel, Apple Silicon | CPython | 2.7, 3.5-3.11 | `<2` | -| Windows | 64bit, 32bit | CPython | 2.7, 3.5-3.11 | `<2` | - +{{< partial name="trace_collection/python/supported_runtimes.html" >}} #### Web framework compatibility ##### Code Security Capability Notes diff --git a/data/api/v2/full_spec.yaml b/data/api/v2/full_spec.yaml index 5cc466c2227..79fd5e5d19b 100644 --- a/data/api/v2/full_spec.yaml +++ b/data/api/v2/full_spec.yaml @@ -75649,10 +75649,14 @@ paths: - apiKeyAuth: [] appKeyAuth: [] - AuthZ: [] - summary: Get the schedule on-call user + summary: Get scheduled on-call user tags: - On-Call x-menu-order: 11 + x-permission: + operator: AND + permissions: + - on_call_read /api/v2/on-call/teams/{team_id}/on-call: get: description: Get a team's on-call users at a given time @@ -75696,6 +75700,10 @@ paths: tags: - On-Call x-menu-order: 12 + x-permission: + operator: AND + permissions: + - on_call_read /api/v2/on-call/teams/{team_id}/routing-rules: get: description: Get a team's On-Call routing rules diff --git a/data/api/v2/translate_actions.json b/data/api/v2/translate_actions.json index 8beba773ccc..9459cd97cbd 100644 --- a/data/api/v2/translate_actions.json +++ b/data/api/v2/translate_actions.json @@ -1988,7 +1988,7 @@ }, "GetScheduleOnCallUser": { "description": "Retrieves the user who is on-call for the specified schedule at a given time.", - "summary": "Get the schedule on-call user" + "summary": "Get scheduled on-call user" }, "GetTeamOnCallUsers": { "description": "Get a team's on-call users at a given time", diff --git a/layouts/partials/feature_flags/feature_flags_client.html b/layouts/partials/feature_flags/feature_flags_client.html index 0242ff75633..ec36a19a6a6 100644 --- a/layouts/partials/feature_flags/feature_flags_client.html +++ b/layouts/partials/feature_flags/feature_flags_client.html @@ -30,6 +30,13 @@ +
+ +
+ {{ partial "img.html" (dict "root" . "src" "integrations_logos/java.png" "class" "img-fluid" "alt" "Java" "width" "400") }} +
+ +
diff --git a/layouts/partials/trace_collection/python/supported_runtimes.html b/layouts/partials/trace_collection/python/supported_runtimes.html index ac6f3d681c4..50bd8e34d13 100644 --- a/layouts/partials/trace_collection/python/supported_runtimes.html +++ b/layouts/partials/trace_collection/python/supported_runtimes.html @@ -9,6 +9,33 @@ + + Linux + x86-64, AArch64 + CPython + 3.9+ + + >=4, <5 + + + + MacOS + Intel, Apple Silicon + CPython + 3.9+ + + >=4, <5 + + + + Windows + 64bit, 32bit + CPython + 3.9+ + + >=4, <5 + + Linux x86-64, i686, AArch64 @@ -36,7 +63,6 @@ >=3, <4 - Linux x86-64, i686, AArch64 @@ -64,7 +90,6 @@ >=2,<3 - Linux x86-64, i686, AArch64 diff --git a/layouts/partials/trace_collection/python/supported_versions.html b/layouts/partials/trace_collection/python/supported_versions.html index f876e5a5d13..f0c3024ad9c 100644 --- a/layouts/partials/trace_collection/python/supported_versions.html +++ b/layouts/partials/trace_collection/python/supported_versions.html @@ -9,11 +9,18 @@ - >=3.0,<4 + >=4.0,<5 General Availability 7.28 + + + >=3.0,<4 + + Maintenence (until May 31, 2026) + 7.28 + >=2.0,<3 diff --git a/static/images/security/security_monitoring/cloud_siem_overview_2025.png b/static/images/security/security_monitoring/cloud_siem_overview_2025.png new file mode 100644 index 00000000000..1c9a8e713a9 Binary files /dev/null and b/static/images/security/security_monitoring/cloud_siem_overview_2025.png differ