diff --git a/config/_default/menus/main.en.yaml b/config/_default/menus/main.en.yaml
index 13c2205f029..90abae83032 100644
--- a/config/_default/menus/main.en.yaml
+++ b/config/_default/menus/main.en.yaml
@@ -6442,11 +6442,6 @@ menu:
parent: ide_plugins_idea
identifier: ide_plugins_idea_logs
weight: 103
- - name: Live Debugger
- url: ide_plugins/idea/live_debugger/
- parent: ide_plugins_idea
- identifier: ide_plugins_idea_debugger
- weight: 104
- name: VS Code & Cursor
url: ide_plugins/vscode/
parent: ide_plugins
@@ -6472,11 +6467,6 @@ menu:
parent: ide_plugins_vscode
identifier: ide_plugins_vscode_exception_replay
weight: 104
- - name: Live Debugger
- url: ide_plugins/vscode/live_debugger/
- parent: ide_plugins_vscode
- identifier: ide_plugins_vscode_live_debugger
- weight: 105
- name: Observability Pipelines
url: observability_pipelines/
pre: pipelines
diff --git a/content/en/ide_plugins/idea/_index.md b/content/en/ide_plugins/idea/_index.md
index 1feefd096dc..1add08f366c 100644
--- a/content/en/ide_plugins/idea/_index.md
+++ b/content/en/ide_plugins/idea/_index.md
@@ -13,9 +13,6 @@ further_reading:
- link: "/logs/explorer/"
tag: "Documentation"
text: "Learn more about Logs"
-- link: "/tracing/live_debugger/"
- tag: "Documentation"
- text: "Learn more about Live Debugger"
- link: "/security/code_security/"
tag: "Documentation"
text: "Learn more about Code Security"
@@ -28,7 +25,7 @@ cascade:
## Overview
-The Datadog plugin for JetBrains IDEs helps improve software performance by providing code insights in the IDE based on real-time observability data. The plugin is for developers that use Datadog products including [Code Security][24], [Error Tracking][25], [Logs][23], and [Live Debugger][20] to monitor their services. It is available for IntelliJ IDEA, GoLand, PyCharm, RubyMine, WebStorm, and PhpStorm.
+The Datadog plugin for JetBrains IDEs helps improve software performance by providing code insights in the IDE based on real-time observability data. The plugin is for developers that use Datadog products including [Code Security][24], [Error Tracking][25], and [Logs][23] to monitor their services. It is available for IntelliJ IDEA, GoLand, PyCharm, RubyMine, WebStorm, and PhpStorm.
{{< img src="/ide_plugins/idea/overview1.png" alt="The Datadog tool window open in IDEA" style="width:100%;" >}}
@@ -109,16 +106,6 @@ The [**Logs**][23] integration detects log lines in your source code, displays l
Find out more in the [Logs][23] sub-section.
-### Live Debugger
-
-This feature is in limited support.
-
-The [**Live Debugger**][20] enables you to add logpoints—auto-expiring, non-breaking breakpoints—to your runtime code to collect information for debugging.
-
-{{< img src="/ide_plugins/idea/live_debugger/tool-window-tab-v2.png" alt="The Live Debugger tab" style="width:100%;" >}}
-
-Find out more in the [Live Debugger][20] sub-section.
-
### Code Origin for Spans
This feature is in limited support.
@@ -186,8 +173,6 @@ You can give feedback in the [discussion forum][1], or send an e-mail to [team-i
[17]: https://www.datadoghq.com/legal/eula/
[18]: /tests/
[19]: /continuous_integration/
-[20]: /ide_plugins/idea/live_debugger/
-[21]: /tracing/live_debugger/
[22]: /tracing/code_origin?tab=java
[23]: /ide_plugins/idea/logs/
[24]: /ide_plugins/idea/code_security/
diff --git a/content/en/ide_plugins/idea/live_debugger.md b/content/en/ide_plugins/idea/live_debugger.md
deleted file mode 100644
index 64f9a03267a..00000000000
--- a/content/en/ide_plugins/idea/live_debugger.md
+++ /dev/null
@@ -1,121 +0,0 @@
----
-title: Live Debugger
-type: documentation
-aliases:
-- '/developers/ide_plugins/idea/live_debugger/'
-further_reading:
-- link: "/tracing/live_debugger/"
- tag: "Documentation"
- text: "Learn more about Live Debugger"
-- link: "/integrations/guide/source-code-integration/"
- tag: "Documentation"
- text: "Learn about Source Code Integration."
----
-
-## Overview
-
-This feature is in limited support.
-
-The Live Debugger enables you to add logpoints—auto-expiring, non-breaking breakpoints—to your runtime code to collect information for debugging. The logpoints are set dynamically in running systems, so there is no need to redeploy your code to investigate and resolve issues. Logpoints are grouped into sessions and you can activate, edit, deactivate, or delete sessions (or individual logpoints) at any time. All sessions and logpoints automatically deactivate after 60 minutes.
-
-## Live Debugger tab
-The **Live Debugger** tab in the Datadog tool window shows the current session, its logpoints, and the data captured by the selected logpoint:
-
-{{< img src="/ide_plugins/idea/live_debugger/tool-window-tab-v2.png" alt="The Live Debugger tab" style="width:100%;" >}}
-
-The panel has three sections:
-
-* The [current session](#current-session) and its logpoints (left side)
-* The [status and events](#logpoint-status-and-events) for the selected logpoint (center)
-* The [runtime data](#runtime-data-for-debugging) for the selected logpoint event (right side)
-
-### Current session
-The session view shows the current session and its logpoints. Use the selector to choose another session or start a new one.
-
-{{< img src="/ide_plugins/idea/live_debugger/session-selector.png" alt="The session selector" style="width:80%;" >}}
-
-Activate, deactivate, or delete the session, using the controls in the toolbar at the right of the selector. You can also open the session in the Datadog UI from here.
-
-Select any logpoint to display its status and recently generated events, or to [enable, disable](#enable-and-disable-a-logpoint), [edit](#edit-a-logpoint) or [delete](#delete-a-logpoint) it. To navigate to the source code location for a logpoint, double-click it or right-click and select **Jump to Source**.
-
-### Logpoint status and events
-The central section displays the status and recent event information for the selected logpoint. The list shows up to 50 events from within the past 24 hours. Select an event to view the generated log message, the captured variables, and the runtime stacktrace for the event.
-
-At the top-right of the panel, **View logs in Datadog** opens the [Log Explorer][2] in Datadog to explore all log events for the selected logpoint.
-
-### Runtime data for debugging
-The right section displays data for the selected logpoint event, including captured variables and the stacktrace for the event. This runtime context is invaluable for understanding issues and reasoning about your source code.
-
-The **Captures** tab shows a tree view of variable values captured at runtime for the logpoint. Nested values are captured up to the depth limit defined in the logpoint. The data is fully searchable and you can copy selected items to the clipboard.
-
-The **Stacktrace** tab shows the runtime path execution leading up to the logpoint. Double-click any frame in the stack trace to open the corresponding source file location.
-
-## Source editor
-In the source editor, an icon is shown in the gutter for any line that has a logpoint defined in the current session:
-
-{{< img src="/ide_plugins/idea/live_debugger/gutter-icon.png" alt="Gutter icon in the source editor" style="width:80%;" >}}
-
-Click the icon to open the Datadog tool window and show the selected logpoint. Right-click the icon for options to [enable, disable](#enable-and-disable-a-logpoint), [edit](#edit-a-logpoint), and [delete](#delete-a-logpoint) the logpoint.
-
-## Managing logpoints
-
-### Add a logpoint
-To add a logpoint, right-click a line of code in the source editor and select **Datadog Live Debugger** > **Add Line Logpoint** or **Add Method Logpoint**. New logpoints are added to the current session or, if required, a new session is created.
-
-A dialog appears where you can enter the service name, the environment, a template for the log message to be emitted at runtime, a logpoint condition expression (optional), and the variable capture depth:
-
-{{< img src="/ide_plugins/idea/live_debugger/new-logpoint.png" alt="Add a new log probe" style="width:75%;" >}}
-
-The log message field accepts a log template that contains descriptive text and variable references—see the [Dynamic Instrumentation expression language][3] documentation for details. The log message is generated using the runtime state immediately *prior* to the line of code being executed. Generated log messages automatically pass through the Dynamic Instrumentation [Sensitive Data Scanner][5].
-
-When a condition is defined, log events are generated only when the condition evaluates to true. Use conditions to capture events based on runtime state (for example, a particular transaction or product identifier).
-
-The *Capture variables depth* controls how deeply hierarchical data structures are traversed when capturing runtime values. Higher values provide more useful information but require more capacity.
-
-Logpoints expire automatically after 60 minutes. Logpoint events are rate-limited to 1 execution per second.
-
-#### Local and remote versions
-Notice that the remote code may be a different version compared to the source code in the IDE. The **New Logpoint** dialog displays the version of the code that is deployed remotely, if it can be detected, so that you can see exactly where the logpoint is being placed. This requires that your application or service is [tagged with Git information][4].
-
-Tip: Checking out this revision locally shows you the same code in your IDE that is running remotely, which simplifies the live debugging experience. However, this is not required as the Datadog plugin maps local line numbers for logpoints to remote line numbers based on Git commit information.
-
-### Edit a logpoint
-To modify the log message for a logpoint, right-click the logpoint and select **Edit**:
-
-{{< img src="/ide_plugins/idea/live_debugger/edit-logpoint.png" alt="Edit a log probe" style="width:75%;" >}}
-
-You can update the log message, the logpoint condition, and the capture depth. Changing the service or environment requires deleting the logpoint and creating a new one.
-
-Applying changes to the logpoint also extends the expiration time to 60 minutes.
-
-### Delete a logpoint
-You can delete logpoints by right-clicking the icon in the gutter of the source editor, or the entry in the tool window, and selecting **Delete** from the context menu.
-
-Deleting a logpoint does not delete the events already generated by the logpoint.
-
-When a session is deleted, all the logpoints in the session are deleted. This cannot be undone.
-
-### Enable and disable a logpoint
-You can enable or disable logpoints by right-clicking and selecting the appropriate context menu item. The icon changes to indicate the current state of the logpoint:
-
-| Icon | Description |
-|--------------|-------------------|
-| {{< img src="/ide_plugins/idea/live_debugger/probeActive.svg.png" alt="Active icon" width="24px" >}} | **Active**: Log events will be generated when the line of code is about to be executed.|
-| {{< img src="/ide_plugins/idea/live_debugger/probeDisabled.svg.png" alt="Inactive icon" width="24px" >}} | **Disabled**: The logpoint is inactive, either because it automatically expired or the user disabled it manually. |
-| {{< img src="/ide_plugins/idea/live_debugger/probeError.svg.png" alt="Error icon" width="24px" >}} | **Error**: The logpoint is not generating log events due to an error. |
-| {{< img src="/ide_plugins/idea/live_debugger/probeWarning.svg.png" alt="Warning icon" width="24px" >}} | **Warning**: The logpoint may not be generating log events. |
-
-Disabling then re-enabling a logpoint extends its expiry time to 60 minutes.
-
-## Prerequisites
-The Live Debugger feature in the IDE supports Java and Python and is subject to the same setup requirements as [Live Debugger][1].
-
-## Further reading
-
-{{< partial name="whats-next/whats-next.html" >}}
-
-[1]: /tracing/live_debugger/#getting-started
-[2]: /logs/explorer/
-[3]: /dynamic_instrumentation/expression-language/
-[4]: /integrations/guide/source-code-integration/?tab=java#tag-your-telemetry-with-git-information
-[5]: /tracing/dynamic_instrumentation/sensitive-data-scrubbing/
diff --git a/content/en/ide_plugins/vscode/_index.md b/content/en/ide_plugins/vscode/_index.md
index 2bf9db70e28..41cd53496a1 100644
--- a/content/en/ide_plugins/vscode/_index.md
+++ b/content/en/ide_plugins/vscode/_index.md
@@ -50,8 +50,6 @@ The extension includes these features:
- [**Exception Replay**](#exception-replay): Debug your production code.
-- [**Live Debugger**](#live-debugger): Add non-breaking logpoints to running services to capture runtime data without redeploying.
-
Unless stated otherwise, all extension features are available for both VS Code and any other IDEs based on VS Code forks, such as Cursor.
## Requirements
@@ -161,16 +159,6 @@ Find out more in the [Logs][20] sub-section.
Find out more in the [Exception Replay][22] sub-section.
-### Live Debugger
-
-This feature is in limited support.
-
-The **Live Debugger** lets you add logpoints—auto-expiring, non-breaking breakpoints—to your running services to capture runtime data for debugging without redeploying your code.
-
-{{< img src="/ide_plugins/vscode/live_debugger_overview.mp4" alt="Overview of the Datadog Live Debugger activity" style="width:100%" video=true >}}
-
-Find out more in the [Live Debugger][23] sub-section.
-
## Data and telemetry
Datadog collects certain information about your usage of this IDE, including how you interact with it, whether errors occurred while using it, what caused those errors, and user identifiers in accordance with the [Datadog Privacy Policy][13] and Datadog's [VS Code extension EULA][12]. This data is used to help improve the extension's performance and features, including transitions to and from the extension and the applicable Datadog login page for accessing the Services.
@@ -210,4 +198,3 @@ Read the [End-User License Agreement][12] carefully before downloading or using
[20]: /ide_plugins/vscode/logs/
[21]: /ide_plugins/vscode/code_insights/
[22]: /ide_plugins/vscode/exception_replay/
-[23]: /ide_plugins/vscode/live_debugger/
diff --git a/content/en/ide_plugins/vscode/live_debugger.md b/content/en/ide_plugins/vscode/live_debugger.md
deleted file mode 100644
index ade333ffedc..00000000000
--- a/content/en/ide_plugins/vscode/live_debugger.md
+++ /dev/null
@@ -1,89 +0,0 @@
----
-title: Live Debugger
-type: documentation
-description: Add logpoints to running services to capture runtime data for debugging without redeploying, using the Live Debugger in the Datadog VS Code extension.
-further_reading:
- - link: '/dynamic_instrumentation/'
- tag: 'Documentation'
- text: 'Learn more about Dynamic Instrumentation'
- - link: '/integrations/guide/source-code-integration/'
- tag: 'Documentation'
- text: 'Learn more about Source Code Integration'
----
-
-## Overview
-
-This feature is in limited support.
-
-The **Live Debugger** lets you add logpoints—auto-expiring, non-breaking breakpoints—to your running services to collect information for debugging. Logpoints are set dynamically, so you don't need to redeploy your code to investigate an issue. Logpoints are grouped into sessions, and you can activate, edit, deactivate, or delete sessions (or individual logpoints) at any time. All sessions and logpoints automatically deactivate after 60 minutes, and log events are rate-limited to one execution per second.
-
-To use this feature, your service must be set up for [Datadog Dynamic Instrumentation][1], and remote code is matched to your local files using [Source Code Integration][2].
-
-{{< img src="/ide_plugins/vscode/live_debugger_overview.mp4" alt="Overview of the Datadog Live Debugger activity" style="width:100%" video=true >}}
-
-## Datadog Live Debugger activity
-
-The extension contributes a dedicated **Datadog Live Debugger** activity to the IDE sidebar with the following views:
-
-- **Sessions**: Lists existing sessions and lets you activate, deactivate, delete, or refresh them, and open them in the Datadog UI. The view can be filtered to show only your sessions, only active sessions, or only sessions whose service repositories are open in the workspace.
-- **Logpoints**: Lists the logpoints belonging to the selected session. From here you can enable, disable, edit, or delete a logpoint, jump to its source location, copy its ID or link, or open it in Datadog.
-- **Log Events**: Shows recent log events generated by the selected logpoint. You can open events in the Datadog UI or use **Generate Unit Test** to turn captured runtime values into a unit test.
-- **Variables**: Shows the variables captured for the selected log event as a searchable tree. You can copy values or jump to the variable's source location.
-- **Logpoint Editor**: A form used to create or edit a logpoint (service, environment, message template, condition, capture variables depth).
-
-## Source editor integration
-
-For lines that have a logpoint defined in the current session, the extension shows a status icon in the editor gutter and a code lens above the line.
-
-- Right-click the line number of any line of code and select **Datadog Live Debugger > Create Logpoint** to create a logpoint on that line.
-- For a line that already has a logpoint, the same submenu offers **Edit**, **Delete**, and either **Enable** or **Disable** depending on the logpoint's current state.
-- Click the code lens above the line to reveal the logpoint in the Live Debugger views.
-
-{{< img src="/ide_plugins/vscode/live_debugger_create.mp4" alt="Creating a logpoint from the line-number context menu" style="width:100%" video=true >}}
-
-## Create a logpoint
-
-To add a logpoint, right-click the line number for a line of code in the source editor and select **Datadog Live Debugger > Create Logpoint**. The logpoint is added to the current session, or a new session is created if needed.
-
-The **Logpoint Editor** shows the following fields:
-
-- **Service** and **Environment**: Target the service and environment where the logpoint runs. The list of services is filtered by the current file's language to show only compatible services.
-- **Message template**: Descriptive text with variable references using the Dynamic Instrumentation expression language. The message is built from the runtime state immediately before the line of code is executed. Generated messages automatically pass through the Dynamic Instrumentation Sensitive Data Scanner.
-- **Condition** (optional): When defined, a log event is emitted only if the expression evaluates to `true`. Use it to capture events based on runtime state (for example, a particular user or transaction ID).
-- **Capture variables depth**: Controls how deeply hierarchical data structures are traversed when capturing runtime values. Higher values provide more detail but require more capacity.
-
-The editor warns you when no service or environment matches the file's language, or when the remote service is associated with a different repository than the local workspace. You can still create the logpoint in those cases.
-
-### Local and remote versions
-
-The remote running code may be a different revision from the source you are editing. The extension uses Git commit information to map line numbers from your local file to the remote revision, so logpoints land on the correct line even if the remote is on a different commit. This requires your service to be tagged with Git information.
-
-Checking out locally the same revision that is running remotely shows you the same code in the IDE that is running in production, which simplifies the live debugging experience, but it is not required.
-
-## Edit, enable, disable, and delete logpoints
-
-- **Edit**: Right-click a logpoint in the editor or in the **Logpoints** view and select **Edit** to update its message template, condition, or capture depth. Changing the service or environment requires deleting the logpoint and creating a new one. Saving an edit also extends the expiration to 60 minutes.
-- **Enable / Disable**: Toggle a logpoint or a whole session from the views or the line-number context menu. Re-enabling a logpoint extends its expiration to 60 minutes.
-- **Delete**: Deleting a logpoint does not delete the events it has already generated. Deleting a session deletes all of its logpoints and cannot be undone. The extension asks for confirmation before deleting (you can suppress these prompts in the extension settings).
-
-The gutter icon reflects the current status of each logpoint:
-
-| Icon | Status | Meaning |
-| ----------------------------------------------------------------------------------------------------------------------------- | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| {{< img src="/ide_plugins/vscode/probe_active_dark.png" alt="Active status icon." style="width:16px; display:inline;" >}} | **Active** | The logpoint is installed and emits log events when the line of code is about to run. |
-| {{< img src="/ide_plugins/vscode/probe_warning_dark.png" alt="Warning status icon." style="width:16px; display:inline;" >}} | **Warning** | The logpoint may not be generating events yet. This is shown when the backend has not processed a recent change (`WAITING`) or no tracer agents are reporting for the targeted service (`NO_AGENTS`). |
-| {{< img src="/ide_plugins/vscode/probe_error_dark.png" alt="Error status icon." style="width:16px; display:inline;" >}} | **Error** | The logpoint is not generating events because of an error, or its status is unknown. |
-| {{< img src="/ide_plugins/vscode/probe_disabled_dark.png" alt="Disabled status icon." style="width:16px; display:inline;" >}} | **Disabled** | The logpoint is inactive—either you disabled it manually or it has expired. |
-
-## Generate a unit test from a log event
-
-From the **Log Events** view, the **Generate Unit Test** action sends the runtime values captured by a logpoint (variables and arguments) to the chat agent with a prompt to produce a unit test that reproduces the captured state. This is useful to turn a real production event into a regression test.
-
-{{< img src="/ide_plugins/vscode/live_debugger_test_with_ai.mp4" alt="Creating a unit test from Live Debugger-captured runtime values" style="width:100%" video=true >}}
-
-## Further reading
-
-{{< partial name="whats-next/whats-next.html" >}}
-
-[1]: /dynamic_instrumentation/
-[2]: /integrations/guide/source-code-integration/
diff --git a/content/en/observability_pipelines/guide/upgrade_worker.md b/content/en/observability_pipelines/guide/upgrade_worker.md
index 2402eb40928..a0c2b524c32 100644
--- a/content/en/observability_pipelines/guide/upgrade_worker.md
+++ b/content/en/observability_pipelines/guide/upgrade_worker.md
@@ -127,7 +127,7 @@ Worker version 2.15.1 gives you access to the following:
#### New features
-- The following VRL functions are now available for the Custom Processor: `to_entries`, `from_entries`, and `with_entries` for converting between objects and arrays of key-value pairs (jq-style).
+- The Custom Processor now supports the `to_entries` and `from_entries` functions for converting between objects and arrays of key-value pairs (jq-style).
#### Enhancements
diff --git a/content/en/security/application_security/setup/nginx/ingress-controller.md b/content/en/security/application_security/setup/nginx/ingress-controller.md
index 7d1a741ec47..ddfa46f2cf7 100644
--- a/content/en/security/application_security/setup/nginx/ingress-controller.md
+++ b/content/en/security/application_security/setup/nginx/ingress-controller.md
@@ -19,16 +19,102 @@ further_reading:
# Ingress-nginx support for Datadog
[Ingress-nginx][1] is a [Kubernetes ingress controller][2]
-that uses nginx as a reverse proxy and load balancer. In a Kubernetes cluster, external access is restricted by default for security reasons.
+that uses NGINX as a reverse proxy and load balancer. In a Kubernetes cluster, external access is restricted by default for security reasons.
An ingress controller uses rules to control how external traffic may reach your services.
+You can enable [App and API Protection][10] for your ingress-nginx controller to inspect and protect traffic at the edge of your cluster. Datadog supports two setup methods:
+
+- **Automated configuration** (recommended): the Datadog Cluster Agent injects the `nginx-datadog` module into your ingress-nginx controller pods.
+- **Manual configuration**: you add a Datadog init container and NGINX configuration snippets yourself.
+
+## Automated configuration with App and API Protection for Kubernetes
+
+
+ Automated configuration lets the Datadog Cluster Agent inject the nginx-datadog module into your ingress-nginx controller pods, without manual init container or NGINX snippet changes. This is the recommended approach for most users.
+
+
+### Setup
+
+This setup requires:
+
+- The Datadog Cluster Agent `v7.79.0` or later.
+- For the Helm method, the Datadog Helm chart `v3.217.0` or later.
+
+Enable automatic configuration using the Datadog Operator or Helm.
+
+{{< tabs >}}
+{{% tab "Datadog Operator" %}}
+
+Add annotations to your `DatadogAgent` resource:
+
+```yaml
+apiVersion: datadoghq.com/v2alpha1
+kind: DatadogAgent
+metadata:
+ name: datadog
+ annotations:
+ agent.datadoghq.com/appsec.injector.enabled: "true"
+ # Optional: override the path where the nginx-datadog module is mounted
+ # in the controller pod (default: /modules_mount)
+ # agent.datadoghq.com/appsec.nginx.module_mount_path: "/modules_mount"
+```
+
+Apply the configuration:
+
+```bash
+kubectl apply -f datadog-agent.yaml
+```
+
+{{% /tab %}}
+{{% tab "Helm" %}}
+
+Add the following to your `values.yaml`:
+
+```yaml
+datadog:
+ appsec:
+ injector:
+ enabled: true
+ # Optional: override the path where the nginx-datadog module is mounted
+ # in the controller pod (default: /modules_mount)
+ # nginx:
+ # moduleMountPath: "/modules_mount"
+```
+
+Install or upgrade the Datadog Helm chart (`v3.217.0` or later):
+
+```bash
+helm upgrade -i datadog-agent datadog/datadog -f values.yaml
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+After you enable automatic configuration, the Datadog Cluster Agent:
+
+- Detects your ingress-nginx controller pods
+- Injects the `nginx-datadog` module into the controller
+- Configures the controller to load the module and apply App and API Protection
+
+You can turn App and API Protection on or off through [Remote Configuration][8] without changing this setup.
+
+For configuration options, see [App and API Protection for Kubernetes][9].
+
+### Validate
+
+{{% appsec-getstarted-2-plusrisk %}}
+
+{{< img src="/security/application_security/appsec-getstarted-threat-and-vuln_2.mp4" alt="Video showing Signals explorer and details, and Vulnerabilities explorer and details." video="true" >}}
+
+## Manual configuration (alternative)
+
The ingress-nginx controller is managed through [Kubernetes resources][3],
-but customization of the underlying nginx configuration is typically limited beyond its intended use case. However, ingress-nginx allows
-the addition of extra nginx modules for extended functionality. To take advantage of this feature with `nginx-datadog`, we provide **init containers**.
+but customization of the underlying NGINX configuration is typically limited beyond its intended use case. However, ingress-nginx allows
+the addition of extra NGINX modules for extended functionality. To take advantage of this feature with `nginx-datadog`, Datadog provides **init containers**.
-## How to enable `nginx-datadog` in ingress-nginx?
+### How to enable `nginx-datadog` in ingress-nginx?
To integrate `nginx-datadog` with ingress-nginx, add a Datadog [init container][4] to your pod
-specification and configure nginx to load the `nginx-datadog` module.
+specification and configure NGINX to load the `nginx-datadog` module.
The following Helm values demonstrate how to inject the `nginx-datadog` module into an ingress-nginx controller:
@@ -51,29 +137,29 @@ controller:
distroless: false
```
-Check [our details examples][5] to help you set up ingress-nginx with `nginx-datadog`.
+See the [detailed examples][5] to help you set up ingress-nginx with `nginx-datadog`.
-## How does it work?
+### How does it work?
Init containers are special containers that run before the main container in a Kubernetes pod. In this case,
-the Datadog init container is responsible for copying the `nginx-datadog` module into a shared volume that will be
-accessible by the main ingress-nginx container.
+the Datadog init container is responsible for copying the `nginx-datadog` module into a shared volume that the
+main ingress-nginx container can access.
-When the main ingrees-nginx controller starts, the nginx configuration must be updated with the `load_module` directive,
-allowing it to load the Datadog module seamlessly.
+When the main ingress-nginx controller starts, the NGINX configuration must be updated with the `load_module` directive,
+allowing it to load the Datadog module.
-We provide a specific init container **for each ingress-nginx controller version**, starting with v1.10.0. This is crucial because **each** init container must match the underlying nginx version. To ensure compatibility, ensure the version of the Datadog init container matches your ingress-nginx version.
+Datadog provides a specific init container for each ingress-nginx controller version, starting with v1.10.0. This is crucial because each init container must match the underlying NGINX version. To confirm compatibility, verify that the version of the Datadog init container matches your ingress-nginx version.
-## Interaction with OpenTelemetry
+### Interaction with OpenTelemetry
By default, ingress-nginx includes an OpenTelemetry (oTel) module that can be enabled using the `enable-opentelemetry: true` setting
in the [ingress-nginx ConfigMap][6].
-However, if you are using `nginx-datadog` for tracing, we recommend **disabling** OpenTelemetry to prevent duplicate tracing data from both
+However, if you are using `nginx-datadog` for tracing, Datadog recommends **disabling** OpenTelemetry to prevent duplicate tracing data from both
the oTel and Datadog modules.
To disable OpenTelemetry, set `enable-opentelemetry: false`.
-## Enabling AppSec
+### Enabling AppSec
You can enable the WAF provided by AppSec to protect your applications from security threats. To do so, update your Helm values to include the AppSec configuration:
@@ -104,12 +190,16 @@ controller:
- `datadog_appsec_enabled on`: Enables the Application Security module for threat detection and protection. This can be omitted so that AppSec can be enabled or disabled through Remote Configuration.
- `datadog_waf_thread_pool_name waf_thread_pool`: Associates the matching requests with the configured thread pool.
-Refer to the [configuration reference][7] for more configurable options.
+See the [configuration reference][7] for more configurable options.
For production environments, monitor the thread pool performance and adjust the threads and max_queue parameters based on your traffic volume and latency requirements.
+## Further reading
+
+{{< partial name="whats-next/whats-next.html" >}}
+
[1]: https://github.com/kubernetes/ingress-nginx
[2]: https://kubernetes.io/docs/concepts/services-networking/ingress/
[3]: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/
@@ -117,3 +207,6 @@ For production environments, monitor the thread pool performance and adjust the
[5]: https://github.com/DataDog/nginx-datadog/tree/master/example/ingress-nginx
[6]: https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#enable-opentelemetry
[7]: https://github.com/DataDog/nginx-datadog/blob/master/doc/API.md
+[8]: /agent/remote_config/?tab=helm#enabling-remote-configuration
+[9]: /containers/kubernetes/appsec
+[10]: /security/application_security/
diff --git a/content/en/security/automation_pipelines/set_due_date.md b/content/en/security/automation_pipelines/set_due_date.md
index db1a8c849fe..1e505ba0586 100644
--- a/content/en/security/automation_pipelines/set_due_date.md
+++ b/content/en/security/automation_pipelines/set_due_date.md
@@ -38,7 +38,12 @@ Configure due date rules to ensure findings are addressed within your specified
- Identity Risk
- API Security
- **Any of these tags or attributes**: The resource tags or attributes that must match for the rule to apply.
-1. Set a due date for each severity level that needs one. The due date starts from when the matching finding was discovered, not when the rule was created.
+1. Set a due date for each severity level that needs one.
+1. If the rule includes a CVE-based finding type (Library, Container Image, or Host vulnerability), under **Calculate due dates from**, select the base date for the SLA clock:
+ - **First Seen Date**: Starts the SLA clock when Datadog first detects the finding.
+ - **Fix-Available Date**: Starts the SLA clock when a patch is published for the vulnerability. Useful when you don't want teams to breach SLA on advisories they can't yet remediate.
+
+ For all other finding types, First Seen Date is always used.
1. Click **Save**. The rule applies to new findings immediately and starts checking existing findings within the next hour.
## Where due dates appear
diff --git a/content/en/tracing/live_debugger/_index.md b/content/en/tracing/live_debugger/_index.md
index 9c5cf019a0b..a0c38dbf411 100644
--- a/content/en/tracing/live_debugger/_index.md
+++ b/content/en/tracing/live_debugger/_index.md
@@ -1,6 +1,10 @@
---
title: Live Debugger
description: Debug running applications in real time using non-breaking logpoints that collect information without stopping execution or redeploying code.
+aliases:
+- '/ide_plugins/idea/live_debugger/'
+- '/developers/ide_plugins/idea/live_debugger/'
+- '/ide_plugins/vscode/live_debugger/'
further_reading:
- link: "https://www.datadoghq.com/blog/gitlab-source-code-integration"
tag: "Blog"
@@ -11,9 +15,6 @@ further_reading:
- link: "/dynamic_instrumentation/expression-language/"
tag: "Documentation"
text: "Dynamic Instrumentation Expression Language"
-- link: "/ide_plugins/idea/live_debugger/"
- tag: "Documentation"
- text: "Live Debugger for JetBrains IDEs"
- link: "/dynamic_instrumentation/sensitive-data-scrubbing/"
tag: "Documentation"
text: "Sensitive Data Scrubbing"
@@ -115,10 +116,6 @@ Live Debugger.
## Using Live Debugger
-
-
Rather debug in your IDE?
-Try using Live Debugger directly from JetBrains!
Click here to learn more.