diff --git a/config/_default/menus/main.en.yaml b/config/_default/menus/main.en.yaml index 90abae83032..944eea79cbd 100644 --- a/config/_default/menus/main.en.yaml +++ b/config/_default/menus/main.en.yaml @@ -1762,24 +1762,26 @@ menu: url: dashboards/sharing/shared_dashboards parent: dashboards_sharing weight: 1002 - - name: Widget Public URLs + - name: Widget Share URLs identifier: dashboards_sharing_widget_public_urls url: dashboards/sharing/widget_public_urls + parent: dashboards_sharing + weight: 1003 - name: Secure Embedded Dashboards identifier: dashboards_sharing_secure_embedded_dashboards url: dashboards/sharing/secure_embedded_dashboards parent: dashboards_sharing - weight: 1003 + weight: 1004 - name: Share Graphs identifier: dashboards_sharing_graphs url: dashboards/sharing/graphs parent: dashboards_sharing - weight: 1004 + weight: 1005 - name: Scheduled Reports identifier: dashboards_reporting url: dashboards/sharing/scheduled_reports parent: dashboards_sharing - weight: 1005 + weight: 1006 - name: Guides url: dashboards/guide/ parent: dashboards @@ -4697,9 +4699,9 @@ menu: identifier: live_debugger parent: tracing weight: 12 - - name: Debug with Bits - url: tracing/live_debugger/debug-with-bits/ - identifier: live_debugger_debug_with_bits + - name: Bits Live Debugger + url: tracing/live_debugger/bits-live-debugger/ + identifier: live_debugger_bits_live_debugger parent: live_debugger weight: 1 - name: Error Tracking @@ -6330,6 +6332,11 @@ menu: parent: feature_flags_concepts identifier: feature_flags_history weight: 307 + - name: Feature Flag Graphs + url: feature_flags/concepts/flag_graphs + parent: feature_flags_concepts + identifier: feature_flags_concepts_flag_graphs + weight: 308 - name: Implementation Patterns url: feature_flags/implementation_patterns parent: feature_flags diff --git a/content/en/account_management/workload_identity_federation.md b/content/en/account_management/workload_identity_federation.md index 6c873d1c48e..d1762d8a6cd 100644 --- a/content/en/account_management/workload_identity_federation.md +++ b/content/en/account_management/workload_identity_federation.md @@ -80,11 +80,18 @@ Navigate to [**Organization Settings** > **Workload Identity Federation**][6] an {{< img src="account_management/workload_identity_federation/identity-mappings-list.png" alt="Identity Mappings tab in the Workload Identity Federation page, showing the Org UUID field and a list of AWS ARN patterns mapped to Datadog users and service accounts" style="width:100%;" >}} +
Datadog requires the assumed-role ARN in the Source Pattern field, not the IAM role ARN. These two formats are different:
+ +To find the assumed-role ARN for your workload, run aws sts get-caller-identity from your workload environment and use the value in the Arn field of the response. + To create an identity mapping: 1. Click {{< ui >}}+ New Mapping{{< /ui >}}. 2. Select a **Cloud Provider**. -3. Enter a **Source Pattern (ARN)**. Use `*` for wildcard patterns (for example, `role/terraform-*`). +3. Enter a **Source Pattern (ARN)**. Use the assumed-role ARN format and `*` for wildcard patterns (for example, `arn:aws:sts::123456789012:assumed-role/terraform-runner/*`). 4. Search for and select a **Target Identity**. This is the Datadog user or service account this cloud identity authenticates as. 5. Click {{< ui >}}Create Mapping{{< /ui >}}. @@ -277,11 +284,18 @@ Navigate to [**Organization Settings** > **Workload Identity Federation**][6] an {{< img src="account_management/workload_identity_federation/intake-mappings-list.png" alt="Intake Mappings tab in the Workload Identity Federation page, showing the Org UUID field and a list of AWS ARN patterns authorized for Agent authentication" style="width:100%;" >}} +
Datadog requires the assumed-role ARN in the Source Pattern field, not the IAM role ARN. These two formats are different:
+ +To find the assumed-role ARN for your workload, run aws sts get-caller-identity from your workload environment and use the value in the Arn field of the response. + To create an intake mapping: 1. Click {{< ui >}}+ New Mapping{{< /ui >}}. 2. Select a **Cloud Provider**. -3. Enter a **Source Pattern (ARN)**. Use `*` for wildcard patterns (for example, `role/terraform-*`). +3. Enter a **Source Pattern (ARN)**. Use the assumed-role ARN format and `*` for wildcard patterns (for example, `arn:aws:sts::123456789012:assumed-role/DatadogAgentRole/*`). 4. Click {{< ui >}}Create Mapping{{< /ui >}}. {{< img src="account_management/workload_identity_federation/intake-mapping-create.png" alt="Create Intake Mapping dialog with fields for Cloud Provider and Source Pattern ARN, with helper text describing wildcard pattern support" style="width:70%;" >}} diff --git a/content/en/agent/fleet_automation/configure_integrations.md b/content/en/agent/fleet_automation/configure_integrations.md index f9515a8cdc3..b7748648509 100644 --- a/content/en/agent/fleet_automation/configure_integrations.md +++ b/content/en/agent/fleet_automation/configure_integrations.md @@ -14,10 +14,6 @@ further_reading: site-support-id: fleet-automation-standard-features --- -{{< callout btn_hidden="true" header="Join the Preview!" >}} -Remote integration configuration is in Preview. -{{< /callout >}} - Fleet Automation can deploy, update, and remove [integration][1] configuration files (`conf.d`) on your Agents remotely. Select target Agents by host or tag, choose an integration, and Fleet Automation pushes the configuration change across your fleet. ## Prerequisites diff --git a/content/en/bits_ai/bits_ai_dev_agent/_index.md b/content/en/bits_ai/bits_ai_dev_agent/_index.md index 55bc80a8984..0c838dd7317 100644 --- a/content/en/bits_ai/bits_ai_dev_agent/_index.md +++ b/content/en/bits_ai/bits_ai_dev_agent/_index.md @@ -14,16 +14,25 @@ further_reading: ## Overview -Bits Code is a generative AI coding assistant that uses Datadog observability data to automatically diagnose and fix issues in your code. It integrates with GitHub to create production-ready pull requests, then iterates on changes using CI logs and developer feedback. +Bits Code is a generative AI coding assistant that uses Datadog observability data to automatically diagnose and fix issues in your code. It integrates with [source code providers](#supported-source-code-providers) to create production-ready pull or merge requests, then iterates on changes using CI logs and developer feedback. {{< img src="bits_ai/dev_agent/sessions_overview.png" alt="A tab titled 'Sessions' shows a text field with suggestions underneath" style="width:100%;" >}} Each time Bits Code investigates an issue or generates a fix, it creates a [session](#sessions), which captures the agent's analysis, actions, and any resulting code changes across supported Datadog products. Set up [automations][28] to have Bits Code run sessions on a schedule or in response to signals from other Datadog products, such as a new APM Recommendation or flaky test. -To get started with Bits Code, [set up the GitHub integration][6] and complete any additional configuration. Then, [start your first session](#start-a-session). +To get started with Bits Code, [set up a source code integration][6] and complete any additional configuration. Then, [start your first session](#start-a-session). Learn how your Bits Code usage is billed on [AI Credits][27]. +## Supported source code providers +Bits Code supports the following source code providers: +- **GitHub**: GitHub.com and [GitHub Enterprise Cloud][30] +- **GitLab**: GitLab.com + +The following plans are not supported: +- **Self-hosted plans**, such as GitHub Enterprise Server and GitLab Self-Managed. +- **Cloud-hosted plans on dedicated domains**, such as [GitHub Enterprise Cloud with data residency][31] and [GitLab Dedicated][32]. Bits Code supports only providers on the standard GitHub.com and GitLab.com domains. + ## Sessions A session captures a segment of work with Bits Code, including its analysis and code changes. Start, view, and manage your sessions at **Bits AI** > **Bits Code** > [**Sessions**][7]. @@ -38,7 +47,7 @@ After [completing setup][6], do one of the following to start a Bits Code sessio A session can also be created when another Bits AI agent (like [Bits Chat][16] or [Bits Investigation][17]) hands off a coding task to Bits Code. ### View and manage sessions -On **[Sessions][7]**, view your past sessions in the **My Sessions** panel. A session appears here if you initiated it or interacted with it in some way, like participating in the conversation or creating an associated PR. +On **[Sessions][7]**, view your past sessions in the **My Sessions** panel. A session appears here if you initiated it or interacted with it in some way, like participating in the conversation or creating an associated PR or MR. Click a session to view its details and continue working with Bits Code. To remove a session from your **My Sessions** list, click (**Archive for everyone**) or (**Unwatch session**). @@ -74,18 +83,18 @@ Use the freeform prompt field at [**Sessions**][7] to work with Bits Code on gen ### Automations -[Automations][28] run Bits Code sessions automatically, on a schedule or in response to signals from Datadog products like Error Tracking, APM, or Code Security. After a session completes, Bits Code delivers the results as a pull request, a draft PR, or a Slack notification. +[Automations][28] run Bits Code sessions automatically, on a schedule or in response to signals from Datadog products like Error Tracking, APM, or Code Security. After a session completes, Bits Code delivers the results as a pull or merge request (optionally in draft mode) or a Slack notification. You can build automations from triggers (a product finding, a custom prompt, a schedule, or a combination) and configure one or more outputs. Datadog-provided templates are also available to help you get started. Create and manage automations at **Bits AI** > **Bits Code** > [**Automations**][29]. -### Pull request collaboration +### Pull or merge request collaboration -Bits Code integrates with GitHub to: -- Create pull requests, generating titles and descriptions based on your repository's pull request template -- Iterate on pull requests in response to comments; mention `@Datadog` in a comment to prompt Bits for updates +Bits Code integrates with [source code providers](#supported-source-code-providers) to: +- Create pull or merge requests, generating titles and descriptions based on your repository's pull or merge request template +- Iterate on pull or merge requests in response to comments; mention `@Datadog` in a comment to prompt Bits for updates - Monitor CI logs and fix failures -Bits Code never auto-merges PRs. See all the PRs that Bits Code is working on in **Bits AI** > **Bits Code** > **[Sessions][7]**. +Bits Code never auto-merges PRs or MRs. See all the PRs or MRs that Bits Code is working on in **Bits AI** > **Bits Code** > **[Sessions][7]**. ## Limitations @@ -107,7 +116,6 @@ Bits Code never auto-merges PRs. See all the PRs that Bits Code is working on in [10]: /profiler/automated_analysis/ [12]: /containers/ [13]: /containers/bits_ai_kubernetes_remediation -[14]: https://app.datadoghq.com/code/settings [15]: /security/code_security/static_analysis/ai_enhanced_sast/#remediation [16]: /bits_ai/bits_chat/ [17]: /bits_ai/bits_ai_sre/ @@ -121,3 +129,6 @@ Bits Code never auto-merges PRs. See all the PRs that Bits Code is working on in [27]: /account_management/billing/ai_credits/ [28]: /bits_ai/bits_ai_dev_agent/automations/ [29]: https://app.datadoghq.com/code/automations +[30]: https://docs.github.com/en/enterprise-cloud@latest/admin/overview/about-github-enterprise-cloud +[31]: https://docs.github.com/en/enterprise-cloud@latest/admin/overview/about-github-enterprise-cloud#about-data-residency +[32]: https://docs.gitlab.com/subscriptions/gitlab_dedicated/ diff --git a/content/en/bits_ai/bits_ai_dev_agent/automations.md b/content/en/bits_ai/bits_ai_dev_agent/automations.md index e148d68ffc6..52c286e5741 100644 --- a/content/en/bits_ai/bits_ai_dev_agent/automations.md +++ b/content/en/bits_ai/bits_ai_dev_agent/automations.md @@ -9,7 +9,7 @@ further_reading: --- ## Overview -Create an automation to have Bits Code start a [session][1] when a trigger fires, such as a new Code Security finding or a recurring schedule, then deliver the results as a pull request or Slack notification. +Create an automation to have Bits Code start a [session][1] when a trigger fires—such as a new Code Security finding or a recurring schedule. Bits Code delivers the results as a pull or merge request, or a Slack notification. {{< img src="bits_ai/dev_agent/automations/list.png" alt="Under an 'Automate with Bits' title, a table with columns like Name, Author, and Last Run has four rows." style="width:100%;" >}} @@ -17,7 +17,7 @@ With Bits Code automations, you can: - Generate code fixes on a schedule, without starting each session manually - Have Bits Code respond to signals from other Datadog products, such as a new APM Recommendation, a flaky test, or a Code Security finding -- Route the resulting code changes directly to a pull request or notify a team in Slack +- Route the resulting code changes directly to a pull or merge request, or notify a team in Slack ## Prerequisites To set up a Bits Code automation, each of the following must be true: @@ -44,8 +44,8 @@ To create a custom Bits Code automation: ### Create an automation from a template Find Datadog-provided automation templates in the **Automation Templates** section. These may include: -- **Create PRs based on APM Recommendations**: Generates pull requests based on APM Recommendations for a specific service. -- **Fix frequent errors for a repo**: Uses the [**Custom Prompt**](#custom-prompt-trigger) trigger to instruct Bits Code to scan the last 24 hours of logs, find the most frequent error, and open a pull request with a fix. +- **Create PRs based on APM Recommendations**: Generates pull or merge requests based on APM Recommendations for a specific service. +- **Fix frequent errors for a repo**: Uses the [**Custom Prompt**](#custom-prompt-trigger) trigger to instruct Bits Code to scan the last 24 hours of logs, find the most frequent error, and open a pull or merge request with a fix. Click a template tile to be taken to the new automation form. You must configure an [output](#outputs) before creating the automation. @@ -58,7 +58,7 @@ A trigger defines when an automation runs and what Bits Code acts on. A trigger Click **Add Trigger** to add a component. You can combine a product finding with a schedule, a custom prompt with a schedule, or use a product finding on its own. -To limit how many Bits Code sessions the automation can create in a given period (for example, `5 runs per Week`), click **Add Trigger** > **Set max runs**. One automation execution may produce more than one session. Use this setting to control the volume of pull requests or notifications an automation produces. +To limit how many Bits Code sessions the automation can create in a given period (for example, `5 runs per Week`), click **Add Trigger** > **Set max runs**. One automation execution may produce more than one session. Use this setting to control the volume of pull or merge requests, or Slack notifications, an automation produces. ### Product finding trigger A product finding trigger runs the automation in response to new issues in another Datadog product (for example, Error Tracking or Code Security). You can use a product finding trigger by itself, which runs the automation whenever there is a new finding, or with a [schedule](#schedule-trigger) and lookback window you define (in the **New findings within** field). @@ -69,7 +69,7 @@ When setting up a product finding trigger, you can configure additional filters, - **Flaky Tests** supports filtering by **Repository**, **Branch** (defaults to the repository's default branch), and **Status**. - **Code Security (SAST)** supports filtering by **Repository**, **Severity**, **Rule to remediate**, and a toggle to **Filter out findings identified as false positives by Bits AI**. -
Each finding that triggers an automation is tied to a single session. Multiple findings cannot be fixed in a single session or pull request.
+
Each finding that triggers an automation must have its own session, and related pull or merge request. Multiple findings cannot be fixed in a single session.
### Custom prompt trigger A custom prompt tells Bits Code what to do each time the automation runs, in freeform text, against a chosen repository. Use a custom prompt for recurring maintenance tasks that aren't tied to a specific Datadog signal, such as updating dependencies or refreshing documentation. @@ -80,17 +80,17 @@ A schedule trigger controls when an automation runs. It can be used in combinati - **Custom Schedule**: Choose specific days of the week and a time of day (for example, `Mo, We, Fr at 03:00 pm`). ## Outputs -An output defines what Bits Code does after a [session][1] completes. An automation can have one or more outputs, including [opening a pull request](#pull-request-output) and [generating a Slack notification](#slack-message-output). +An output defines what Bits Code does after a [session][1] completes. An automation can have one or more outputs, including [opening a pull or merge request](#pull-or-merge-request-output) and [generating a Slack notification](#slack-message-output). -### Pull request output +### Pull or merge request output You can configure your automation to: -- **Create a PR**: Open a pull request with the proposed changes -- **Draft a PR**: Open a draft pull request with the proposed changes +- **Create a PR or MR**: Open a pull or merge request with the proposed changes +- **Draft a PR or MR**: Open a draft pull or merge request with the proposed changes -As the author of a Bits Code automation, you are the author of all pull requests it generates. +As the author of a Bits Code automation, you are the author of all pull or merge requests it generates. ### Slack message output -You can configure your automation to send a Slack message summarizing the [session][1] and code changes. If you use a pull request output in addition to a Slack output, Bits Code includes a link to the pull request in the Slack message. +You can configure your automation to send a Slack message summarizing the [session][1] and code changes. If you use a pull or merge request output in addition to a Slack output, Bits Code includes a link to the pull or merge request in the Slack message. When you add a Slack message output, by default, Bits Code sends the message to the channel configured for the affected service in [Catalog][5]. You can set a fallback Slack channel, which is used when no channel is set in Catalog. diff --git a/content/en/bits_ai/bits_ai_dev_agent/setup.md b/content/en/bits_ai/bits_ai_dev_agent/setup.md index 100400e5ddb..9b473ae572b 100644 --- a/content/en/bits_ai/bits_ai_dev_agent/setup.md +++ b/content/en/bits_ai/bits_ai_dev_agent/setup.md @@ -1,131 +1,154 @@ ---- -title: Bits Code Setup -disable_toc: false ---- - -## Overview - -[Bits Code][8] integrates with GitHub to open, update, and iterate on pull requests based on issues detected in Datadog. After completing setup, you can [start using Bits Code][7]. - -## Prerequisites - -To set up Bits Code, you need the **Bits Code Write** (`bits_dev_write`) permission. This permission is included in managed Datadog roles such as the Datadog Standard Role. - -If your organization uses custom roles, an admin must add this permission manually. For details, see [Access Control][1]. - -## Setup - -1. Install the [GitHub integration][2]. For full installation and configuration steps, see the [GitHub integration guide][3]. -1. In your GitHub account, navigate to {{< ui >}}Settings{{< /ui >}} > {{< ui >}}Apps{{< /ui >}} > {{< ui >}}Datadog{{< /ui >}} to configure GitHub permissions. - 1. To enable basic Bits Code functionality, set the following permissions: - - {{< ui >}}Repository permissions{{< /ui >}} - - Repository contents: Read & write - - Pull requests: Read & write - - {{< ui >}}Subscribe to events{{< /ui >}} - - Push - 1. (Optional) To allow Bits Code to use CI logs when iterating on pull requests, you must send CI logs to Datadog and enable the [auto-push](#enable-auto-push) feature. This requires additional permissions: - - {{< ui >}}Repository permissions{{< /ui >}} - - Checks: Read - - Commit statuses: Read only - - {{< ui >}}Subscribe to events{{< /ui >}} - - Check run - - Check suite - - Issue comment - - Status - -## Additional configuration - -These optional configurations help you get the most out of Bits Code. - -### Configure telemetry tagging - -Bits Code uses the `service` and `version` telemetry tags to match detected issues (such as errors or vulnerabilities) to the version of code that was running at the time. - -To configure telemetry tagging, see [Tag your APM telemetry with Git information][4]. - -You can also configure service-to-repository mapping manually in Bits Code settings under [{{< ui >}}Repositories{{< /ui >}}][5] > {{< ui >}}Service Repository Mapping{{< /ui >}}. - -### Enable auto-push - -Auto-push allows Bits Code to create branches, push code, and open PRs when it detects something it can help you with. Auto-push only opens PRs and pushes changes; it never merges code. When auto-push is disabled, you must review code in Datadog before it gets pushed. - +--- +title: Bits Code Setup +disable_toc: false +--- + +## Overview + +[Bits Code][8] integrates with [source code providers][11] to open, update, and iterate on pull or merge requests based on issues detected in Datadog. After completing setup, you can [start using Bits Code][7]. + +## Prerequisites + +To set up Bits Code, you need the **Bits Code Write** (`bits_dev_write`) permission. This permission is included in managed Datadog roles such as the Datadog Standard Role. + +If your organization uses custom roles, an admin must add this permission manually. For details, see [Access Control][1]. + +## Setup + +Set up Bits Code for one of the [supported source code providers][11]. + +{{< tabs >}} + +{{% tab "GitHub" %}} +1. Install the [GitHub integration][1]. For full installation and configuration steps, see the [GitHub integration guide][2]. +1. In your GitHub account, navigate to {{< ui >}}Settings{{< /ui >}} > {{< ui >}}Apps{{< /ui >}} > {{< ui >}}Datadog{{< /ui >}} to configure GitHub permissions. + 1. To enable basic Bits Code functionality, set the following permissions: + - {{< ui >}}Repository permissions{{< /ui >}} + - Repository contents: Read & write + - Pull requests: Read & write + - {{< ui >}}Subscribe to events{{< /ui >}} + - Push + 1. (Optional) To allow Bits Code to use CI logs when iterating on pull requests, you must send CI logs to Datadog and enable the [auto-push](#enable-auto-push) feature. This requires additional permissions: + - {{< ui >}}Repository permissions{{< /ui >}} + - Checks: Read + - Commit statuses: Read only + - {{< ui >}}Subscribe to events{{< /ui >}} + - Check run + - Check suite + - Issue comment + - Status + +[1]: https://app.datadoghq.com/integrations/github +[2]: /integrations/github/ +{{% /tab %}} + +{{% tab "GitLab" %}} +1. Install the [GitLab Source Code integration][1]. For full installation and configuration steps, see the [GitLab Source Code integration guide][2]. +1. Verify that the GitLab [service account][3] meets the following requirements: + - The service account must have the [Developer role][4] on the project. This role can be inherited from a [group][5]. + - The service account's personal access token must have the following [scopes][6]: `api`, `write_repository`, and `read_user`. + +[1]: https://app.datadoghq.com/integrations/gitlab-source-code +[2]: /integrations/gitlab-source-code/ +[3]: https://docs.gitlab.com/user/profile/service_accounts/ +[4]: https://docs.gitlab.com/user/permissions/#default-roles +[5]: https://docs.gitlab.com/user/permissions/#groups +[6]: https://docs.gitlab.com/user/profile/personal_access_tokens/#personal-access-token-scopes +{{% /tab %}} + +{{< /tabs >}} + +## Additional configuration + +These optional configurations help you get the most out of Bits Code. + +### Configure telemetry tagging + +Bits Code uses the `service` and `version` telemetry tags to match detected issues (such as errors or vulnerabilities) to the version of code that was running at the time. + +To configure telemetry tagging, see [Tag your APM telemetry with Git information][4]. + +You can also configure service-to-repository mapping manually in Bits Code settings under [{{< ui >}}Repositories{{< /ui >}}][5] > {{< ui >}}Service Repository Mapping{{< /ui >}}. + +### Enable auto-push + +Auto-push allows Bits Code to create branches, push code, and open PRs or MRs when it detects something it can help you with. Auto-push only opens PRs or MRs and pushes changes; it never merges code. When auto-push is disabled, you must review code in Datadog before it gets pushed. + To enable auto-push, navigate to **Bits Code** > **Settings** > [**General**][6]. - - -#### Security considerations - -Allowing any AI-based tool to read untrusted data can let attackers influence its output. Auto-push behavior depends on the type of data Bits Code works with: code-only workflows operate on source code the Agent can inspect directly, while telemetry-based workflows (such as errors or traces) may include untrusted runtime inputs. - -To balance safety and automation, you can configure auto-push behavior in [Datadog][14] (for example, limiting auto-push to code-only workflows or requiring review when telemetry is involved). Datadog scans all Agent-generated code before pushing changes, but these safeguards are not foolproof. - -### Configure custom instructions - -Bits Code ingests custom instruction files from your repository, including: - -- `.cursorrules` -- `.windsurfrules` -- `copilot-instructions.md` -- `CLAUDE.md` -- `AGENTS.md` -- `agent.md` - - -You can also define global custom instructions, which apply to all Bits Code sessions, in **Bits Code** > **Settings** > [**General**][6], in the **Global Agent Instructions** section. - -## Environment setup - -Configure Bits Code's runtime environment, including network access policies and repository-specific tooling. - -### Configure internet access - -By default, Bits Code has **no internet access** during agent execution. To configure which external domains agents can reach, navigate to **Bits Code** > **Settings** > [**General**][6], and find the **Internet Access** section. Choose from the following access policies: **No Internet Access**, **Default Allowlist**, **Custom + Default Allowlist**, or **Custom Allowlist**. - -The default allowlist includes the following domains. This list will evolve over time based on user feedback and ecosystem changes. To avoid changes, configure a custom allowlist. - -| Language | Domains | -|---|---| -| Clojure/JVM | `repo.clojars.org` | -| Go | `pkg.go.dev`, `proxy.golang.org`, `sum.golang.org`, `vuln.go.dev` | -| Java/JVM | `repo1.maven.org` | -| JavaScript/TypeScript | `registry.npmjs.org`, `registry.yarnpkg.com` | -| .NET/C# | `api.nuget.org` | -| PHP | `packagist.org`, `repo.packagist.org` | -| Python | `files.pythonhosted.org`, `pypi.org`, `pypi.python.org`, `pythonhosted.org` | -| Rust | `index.crates.io`, `static.crates.io` | -| Ubuntu | `archive.ubuntu.com`, `ports.ubuntu.com`, `security.ubuntu.com` | - -### Configure repository environment - -Configure a custom environment for Bits Code to install dependencies, formatters, linters, and build tools that are needed for your codebase. Each repository runs in its own isolated sandbox, and the environment defines the settings for that sandbox. - -To configure a repository environment: - -1. Go to {{< ui >}}Bits Code{{< /ui >}} > {{< ui >}}Settings{{< /ui >}} > [{{< ui >}}Repositories{{< /ui >}}][5], and find the {{< ui >}}Environments{{< /ui >}} section. -1. Click {{< ui >}}Add Environment{{< /ui >}} to create a repository configuration: - 1. Select a repository from the dropdown. - 1. (Optional) Under {{< ui >}}Pre-installed Languages{{< /ui >}}, click {{< ui >}}Select Versions{{< /ui >}} to specify the language versions the sandbox should use. - 1. (Optional) Define environment variables and secrets. Environment variables are available during both environment setup and Bits Code execution. Secrets are available as environment variables only during environment setup. - 1. (Optional) Add a shell script with setup commands to execute (for example: `pip install -r requirements.txt`). -1. Run the setup command to ensure it runs successfully. -1. Save the configuration. - -Bits Code runs the setup command at startup and can use any tools installed in your environment. The setup command runs with network access enabled to download dependencies. After setup is complete, your [internet access](#configure-internet-access) policy controls outbound network access during agent execution. Because setup commands execute against code in your repository, enable them only if you trust the repository's code. - -**Note**: For best results, add a [custom instructions file](#configure-custom-instructions) (like `claude.md`) to your repository with instructions on how to build and test your code. - -## Troubleshooting - -### Creation of PRs fails unexpectedly - -In some cases, especially in repositories with many branches, GitHub does not run the permission check when creating a branch for the session. If you use a custom GitHub App, you can work around this issue by adding the `workflows:write` permission to your app in [Source Code Integration][2]. - -**Note**: This permission allows Bits AI to create workflows in your repository and has security implications. - -[1]: /account_management/rbac/permissions/#bits-ai -[2]: https://app.datadoghq.com/integrations/github -[3]: /integrations/github/ -[4]: /integrations/guide/source-code-integration/?tab=go#tag-your-apm-telemetry-with-git-information -[5]: https://app.datadoghq.com/code/settings?tab=repositories -[6]: https://app.datadoghq.com/code/settings -[7]: /bits_ai/bits_ai_dev_agent/#start-a-session -[8]: /bits_ai/bits_ai_dev_agent/ + + +#### Security considerations + +Allowing any AI-based tool to read untrusted data can let attackers influence its output. Auto-push behavior depends on the type of data Bits Code works with: code-only workflows operate on source code the Agent can inspect directly, while telemetry-based workflows (such as errors or traces) may include untrusted runtime inputs. + +To balance safety and automation, you can configure auto-push behavior in [Datadog][6] (for example, limiting auto-push to code-only workflows or requiring review when telemetry is involved). Datadog scans all Agent-generated code before pushing changes, but these safeguards are not foolproof. + +### Configure custom instructions + +Bits Code ingests custom instruction files from your repository, including: +- `.cursorrules` +- `.windsurfrules` +- `copilot-instructions.md` +- `CLAUDE.md` +- `AGENTS.md` +- `agent.md` + +You can also define global custom instructions, which apply to all Bits Code sessions, in **Bits Code** > **Settings** > [**General**][6], in the **Global Agent Instructions** section. + +## Environment setup + +Configure Bits Code's runtime environment, including network access policies and repository-specific tooling. + +### Configure internet access + +By default, Bits Code has **no internet access** during agent execution. To configure which external domains agents can reach, navigate to **Bits Code** > **Settings** > [**General**][6], and find the **Internet Access** section. Choose from the following access policies: **No Internet Access**, **Default Allowlist**, **Custom + Default Allowlist**, or **Custom Allowlist**. + +The default allowlist includes the following domains. This list will evolve over time based on user feedback and ecosystem changes. To avoid changes, configure a custom allowlist. + +| Language | Domains | +|---|---| +| Clojure/JVM | `repo.clojars.org` | +| Go | `pkg.go.dev`, `proxy.golang.org`, `sum.golang.org`, `vuln.go.dev` | +| Java/JVM | `repo1.maven.org` | +| JavaScript/TypeScript | `registry.npmjs.org`, `registry.yarnpkg.com` | +| .NET/C# | `api.nuget.org` | +| PHP | `packagist.org`, `repo.packagist.org` | +| Python | `files.pythonhosted.org`, `pypi.org`, `pypi.python.org`, `pythonhosted.org` | +| Rust | `index.crates.io`, `static.crates.io` | +| Ubuntu | `archive.ubuntu.com`, `ports.ubuntu.com`, `security.ubuntu.com` | + +### Configure repository environment + +Configure a custom environment for Bits Code to install dependencies, formatters, linters, and build tools that are needed for your codebase. Each repository runs in its own isolated sandbox, and the environment defines the settings for that sandbox. + +To configure a repository environment: + +1. Go to {{< ui >}}Bits Code{{< /ui >}} > {{< ui >}}Settings{{< /ui >}} > [{{< ui >}}Repositories{{< /ui >}}][5], and find the {{< ui >}}Environments{{< /ui >}} section. +1. Click {{< ui >}}Add Environment{{< /ui >}} to create a repository configuration: + 1. Select a repository from the dropdown. + 1. (Optional) Under {{< ui >}}Pre-installed Languages{{< /ui >}}, click {{< ui >}}Select Versions{{< /ui >}} to specify the language versions the sandbox should use. + 1. (Optional) Define environment variables and secrets. Environment variables are available during both environment setup and Bits Code execution. Secrets are available as environment variables only during environment setup. + 1. (Optional) Add a shell script with setup commands to execute (for example: `pip install -r requirements.txt`). +1. Run the setup command to ensure it runs successfully. +1. Save the configuration. + +Bits Code runs the setup command at startup and can use any tools installed in your environment. The setup command runs with network access enabled to download dependencies. After setup is complete, your [internet access](#configure-internet-access) policy controls outbound network access during agent execution. Because setup commands execute against code in your repository, enable them only if you trust the repository's code. + +**Note**: For best results, add a [custom instructions file](#configure-custom-instructions) (like `claude.md`) to your repository with instructions on how to build and test your code. + +## Troubleshooting + +### Creation of GitHub PRs fails unexpectedly + +In some cases, especially in repositories with many branches, GitHub does not run the permission check when creating a branch for the session. If you use a custom GitHub App, you can work around this issue by adding the `workflows:write` permission to your app in the [GitHub integration][2]. + +**Note**: This permission allows Bits AI to create workflows in your repository and has security implications. + +[1]: /account_management/rbac/permissions/#bits-ai +[2]: https://app.datadoghq.com/integrations/github +[4]: /integrations/guide/source-code-integration/?tab=go#tag-your-apm-telemetry-with-git-information +[5]: https://app.datadoghq.com/code/settings?tab=repositories +[6]: https://app.datadoghq.com/code/settings +[7]: /bits_ai/bits_ai_dev_agent/#start-a-session +[8]: /bits_ai/bits_ai_dev_agent/ +[11]: /bits_ai/bits_ai_dev_agent/#supported-source-code-providers diff --git a/content/en/cloud_cost_management/allocation/custom_allocation_rules.md b/content/en/cloud_cost_management/allocation/custom_allocation_rules.md index 469f73edba9..a960abf5612 100644 --- a/content/en/cloud_cost_management/allocation/custom_allocation_rules.md +++ b/content/en/cloud_cost_management/allocation/custom_allocation_rules.md @@ -91,6 +91,8 @@ You can also specify how cost proportions should be partitioned to ensure segmen {{% tab "Dynamic by metric" %}} +
The Dynamic by Metric allocation method requires a CCM Enterprise plan.
+ {{< img src="cloud_cost/custom_allocation_rules/dynamic_diagram.png" alt="Diagram illustrating the dynamic by metric strategy" style="width:70%;" >}} Metrics-based allocation provides the ability to split up costs based on Datadog's [metrics queries][1]. By using performance metrics to allocate expenses, you can more accurately allocate costs based on application usage patterns. diff --git a/content/en/dashboards/sharing/_index.md b/content/en/dashboards/sharing/_index.md index 6d7d4aef0bc..02f681a46a4 100644 --- a/content/en/dashboards/sharing/_index.md +++ b/content/en/dashboards/sharing/_index.md @@ -24,7 +24,7 @@ Shared visualizations allow you to display metric, trace, and log visualizations {{< whatsnext desc="How to share visualizations:" >}} {{< nextlink href="dashboards/sharing/shared_dashboards" >}}Shared dashboards: Generate a public link for users to access{{< /nextlink >}} {{< nextlink href="dashboards/sharing/graphs" >}}Share graphs: Generate an embed code{{< /nextlink >}} - {{< nextlink href="dashboards/sharing/widget_public_urls" >}}Widget Public URLs: Copy widgets as images to share outside of Datadog{{< /nextlink >}} + {{< nextlink href="dashboards/sharing/widget_public_urls" >}}Widget Share URLs: Copy widgets as images to share outside of Datadog{{< /nextlink >}} {{< nextlink href="dashboards/sharing/scheduled_reports" >}}Scheduled reports: Set a schedule to send email reports{{< /nextlink >}} {{< /whatsnext >}} diff --git a/content/en/dashboards/sharing/widget_public_urls.md b/content/en/dashboards/sharing/widget_public_urls.md index cb4e4e3535c..5b2b1fbc7d6 100644 --- a/content/en/dashboards/sharing/widget_public_urls.md +++ b/content/en/dashboards/sharing/widget_public_urls.md @@ -1,6 +1,6 @@ --- -title: Widget Public URLs -description: Copy widgets as snapshot images and share them outside of Datadog. +title: Widget Share URLs +description: Copy widgets as images to share outside of Datadog. further_reading: - link: "/dashboards/sharing/" tag: "Documentation" @@ -12,27 +12,35 @@ further_reading: ## Overview -Widget Public URLs let you copy a dashboard widget as a static image and share it outside of Datadog. When you copy a widget with Cmd/Ctrl + C, Datadog generates a publicly accessible link to a screenshot of the widget as it appears on your screen. This link is placed on your clipboard. When you paste outside of Datadog (for example, into Slack or Microsoft Teams) the link renders as a snapshot image of your widget. +Widget Share URLs let you copy a dashboard widget as an image for use outside of Datadog. When you copy a widget with Cmd/Ctrl + C, Datadog creates an image of the widget and generates a share URL. The URL behavior depends on your organization's Widget Share URLs setting. -**Note**: Widget Public URLs is separate from the [Datadog Clipboard][1], which copies widgets for use within Datadog (in dashboards, notebooks, and incidents). It is also unrelated to the [Snapshots API][2], which programmatically captures metric graph snapshots. +Admins can choose how widget share links and previews work in [**Organization Settings > Public Sharing > Settings**][3]: + +| Mode | Behavior | +| --- | --- | +| **Public** | Anyone with the share URL can view the widget image without a Datadog account. Third-party apps that support link previews, such as Slack or Microsoft Teams, can render a thumbnail of the widget. Viewing the source widget with live data still requires a Datadog account. | +| **Private** | Share URLs are available only to authenticated users in the same Datadog organization. Public image URLs stop serving widget images, so third-party apps cannot render public image previews. Private preview unfurling is supported only in Slack, and only for Slack workspaces connected to the same Datadog organization. | +| **Disabled** | Users cannot generate new Widget Share URLs. Existing share URLs and image endpoints are unavailable while the setting remains disabled, and Slack cannot generate new unfurls for those URLs. | + +**Note**: Widget Share URLs is separate from the [Datadog Clipboard][1], which copies widgets for use within Datadog (in dashboards, notebooks, and incidents). It is also unrelated to the [Snapshots API][2], which programmatically captures metric graph snapshots. ## Prerequisites -This feature requires the **Widget Public URLs** setting to be enabled in your organization. To enable it, navigate to [**Organization Settings > Public Sharing > Settings**][3]. +This feature requires the **Widget Share URLs** setting to be set to **Public** or **Private** in your organization. -When enabled, copying a widget generates a publicly accessible snapshot image link. Anyone with the link can view the snapshot, regardless of whether they have a Datadog account. +Admin changes to the Widget Share URLs mode apply immediately to existing share URLs. -## Copy a widget as an snapshot image +## Copy a widget as a preview image 1. On any dashboard, hover over the widget you want to share. 2. Press Cmd/Ctrl + C, or click the share icon and select **Copy**. 3. Paste outside of Datadog using Cmd/Ctrl + V. -In tools that support link previews (such as Slack or Microsoft Teams), the pasted link renders as a snapshot image of the widget. +In tools that support link previews, the pasted link renders according to your organization's Widget Share URLs mode. In **Public** mode, the widget image is publicly accessible. In **Private** mode, public image previews are unavailable; Slack can render a private preview only when the Slack workspace is connected to the same Datadog organization. -## Disable Widget Public URLs +## Disable Widget Share URLs -To stop generating publicly accessible widget image links, disable the **Widget Public URLs** setting in [**Organization Settings > Public Sharing > Settings**][3]. After disabling, copying a widget no longer generates a public snapshot image link. Previously generated links are no longer accessible. +To stop users from generating widget share links and previews, disable the **Widget Share URLs** setting in [**Organization Settings > Public Sharing > Settings**][3]. After disabling, copying a widget no longer generates share links or previews, and previously shared URLs are no longer accessible. If the setting is later changed back to **Public** or **Private**, previously shared URLs resume functioning according to the selected mode. ## Further reading diff --git a/content/en/dashboards/widgets/configuration/_index.md b/content/en/dashboards/widgets/configuration/_index.md index 2bb96dafeac..0c758ef41d2 100644 --- a/content/en/dashboards/widgets/configuration/_index.md +++ b/content/en/dashboards/widgets/configuration/_index.md @@ -112,7 +112,7 @@ Widgets not linked to global time show the data for their local time frame as ap Copy and paste functionality is a key sharing and collaboration feature that allows you to reuse widgets across different Datadog contexts and external tools. -
Enable Static Public Data Sharing in your Organization Settings to use this feature.
+
To share widgets outside of Datadog with link previews, an admin must set Widget Share URLs to Public or Private in your Organization Settings. Admins can disable this setting to stop users from generating widget share links and previews.
Widgets can be copied on [Dashboards][4], [Notebooks][5], [APM Service][6], and the [APM resource][7] page by using Ctrl/Cmd + C, or by selecting the share icon and choosing "Copy". @@ -121,9 +121,7 @@ The copied widgets can be pasted within Datadog by using Ctrl/Cm * **Dashboards**: Adds a new widget positioned under your mouse cursor. * **Notebooks**: Adds a new cell at the end of the notebook. -You can also paste the widget into your favorite chat program that displays link previews (like Slack or Microsoft Teams). This displays a snapshot image of your graph along with a direct link to your widget. For more information, see [Widget Public URLs][11]. - -For information on copying widgets for use within Datadog (in dashboards, notebooks, and incidents), see [Datadog Clipboard][9]. +You can also paste the widget into your favorite chat program that displays link previews (like Slack or Microsoft Teams). Depending on your organization's Widget Share URLs mode, this displays a public preview image of your graph, or a private preview image in Slack, along with a direct link to your widget. For more information, see [Widget Share URLs][11]. ## Groups of widgets @@ -200,6 +198,5 @@ Click on the context menu (three vertical dots) of any dashboard graph to open a [6]: /tracing/services/service_page/ [7]: /tracing/services/resource_page/ [8]: /dashboards/guide/custom_time_frames/ -[9]: /dashboards/guide/datadog_clipboard/ [10]: /dashboards/widgets/split_graph/ -[11]: /dashboards/sharing/widget_public_urls/ \ No newline at end of file +[11]: /dashboards/sharing/widget_public_urls/ diff --git a/content/en/data_observability/jobs_monitoring/databricks/_index.md b/content/en/data_observability/jobs_monitoring/databricks/_index.md index e5a0debc066..63c3e7745ae 100644 --- a/content/en/data_observability/jobs_monitoring/databricks/_index.md +++ b/content/en/data_observability/jobs_monitoring/databricks/_index.md @@ -180,7 +180,7 @@ Optionally, you can add tags to your Databricks cluster and Spark performance me | Variable | Description | |--------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------| | DD_TAGS | Add tags to Databricks cluster and Spark performance metrics. Comma or space separated key:value pairs. Follow [Datadog tag conventions][1]. For example: `env:staging,team:data_engineering` | -| DD_ENV | Set the `env` environment tag on metrics, traces, and logs from this cluster. | +| DD_ENV | Override the `env` environment tag on metrics, traces, and logs from this cluster. By default, the Databricks workspace name is used as env.| | DD_LOGS_CONFIG_PROCESSING_RULES | Filter the logs collected with processing rules. See [Advanced Log Collection][3] for more details. | @@ -246,7 +246,7 @@ This approach is recommended for clusters in **Standard** access mode. | DRIVER_LOGS_ENABLED | Collect spark driver logs in Datadog. | false | | WORKER_LOGS_ENABLED | Collect spark workers logs in Datadog. | false | | DD_TAGS | Add tags to Databricks cluster and Spark performance metrics. Comma or space separated key:value pairs. Follow [Datadog tag conventions][4]. For example: `env:staging,team:data_engineering` | | - | DD_ENV | Set the `env` environment tag on metrics, traces, and logs from this cluster. | | + | DD_ENV | Override the `env` environment tag on metrics, traces, and logs from this cluster. By default, the Databricks workspace name is used as env. | | | DD_LOGS_CONFIG_PROCESSING_RULES | Filter the logs collected with processing rules. See [Advanced Log Collection][5] for more details. | | 1. Click {{< ui >}}Create{{< /ui >}} if creating a new policy or {{< ui >}}Save{{< /ui >}} if updating an existing policy. If you update an existing policy, all clusters using that policy automatically apply the changes on their next restart. If you create a new policy, follow the steps below to apply it to your clusters. @@ -317,7 +317,7 @@ Optionally, you can also set other init script parameters and Datadog environmen | DRIVER_LOGS_ENABLED | Collect spark driver logs in Datadog. | false | | WORKER_LOGS_ENABLED | Collect spark workers logs in Datadog. | false | | DD_TAGS | Add tags to Databricks cluster and Spark performance metrics. Comma or space separated key:value pairs. Follow [Datadog tag conventions][4]. For example: `env:staging,team:data_engineering` | | -| DD_ENV | Set the `env` environment tag on metrics, traces, and logs from this cluster. | | +| DD_ENV | Override the `env` environment tag on metrics, traces, and logs from this cluster. By default, the Databricks workspace name is used as env. | | | DD_LOGS_CONFIG_PROCESSING_RULES | Filter the logs collected with processing rules. See [Advanced Log Collection][5] for more details. | | [1]: https://app.datadoghq.com/organization-settings/api-keys @@ -383,7 +383,7 @@ Optionally, you can also set other init script parameters and Datadog environmen | DRIVER_LOGS_ENABLED | Collect spark driver logs in Datadog. | false | | WORKER_LOGS_ENABLED | Collect spark workers logs in Datadog. | false | | DD_TAGS | Add tags to Databricks cluster and Spark performance metrics. Comma or space separated key:value pairs. Follow [Datadog tag conventions][4]. For example: `env:staging,team:data_engineering` | | -| DD_ENV | Set the `env` environment tag on metrics, traces, and logs from this cluster. | | +| DD_ENV | Override the `env` environment tag on metrics, traces, and logs from this cluster. By default, the Databricks workspace name is used as env. | | | DD_LOGS_CONFIG_PROCESSING_RULES | Filter the logs collected with processing rules. See [Advanced Log Collection][5] for more details. | | diff --git a/content/en/data_streams/metrics_and_tags.md b/content/en/data_streams/metrics_and_tags.md index 8c13ea8aea4..db2a4eb61a1 100644 --- a/content/en/data_streams/metrics_and_tags.md +++ b/content/en/data_streams/metrics_and_tags.md @@ -28,7 +28,7 @@ This metric measures latency between two points in the pipeline. The value can r - `partial_edge`: latency between a service and a queue, if the producer or consumer is not known (that is, not instrumented with Data Streams Monitoring) - `start` tag: the upstream producer service/queue - `end` tag: the downstream consumer service/queue - - `internal`: latency within the service. Measures time between _consume_ and the folllowing _produce_ operation. + - `internal`: latency within the service. Measures time between _consume_ and the following _produce_ operation. `start` : The name of the node where Data Streams Monitoring first detects the payload. This node can be a service (the original producer) or a queue (the original producer is not known to Data Streams Monitoring). diff --git a/content/en/feature_flags/concepts/_index.md b/content/en/feature_flags/concepts/_index.md index 7726e381b06..b21068f81cc 100644 --- a/content/en/feature_flags/concepts/_index.md +++ b/content/en/feature_flags/concepts/_index.md @@ -13,5 +13,6 @@ Learn how Datadog Feature Flags work and how to configure flags, environments, t {{< nextlink href="/feature_flags/concepts/traffic_splitting" >}}Traffic Splitting and Randomization{{< /nextlink >}} {{< nextlink href="/feature_flags/concepts/distribution_channels" >}}Distribution Channels{{< /nextlink >}} {{< nextlink href="/feature_flags/concepts/flag_history" >}}Flag History{{< /nextlink >}} + {{< nextlink href="/feature_flags/concepts/flag_graphs" >}}Feature Flag Graphs{{< /nextlink >}} {{< nextlink href="/feature_flags/concepts/stale_flags" >}}Stale Flags{{< /nextlink >}} {{< /whatsnext >}} diff --git a/content/en/feature_flags/concepts/flag_graphs.md b/content/en/feature_flags/concepts/flag_graphs.md new file mode 100644 index 00000000000..92de14289ec --- /dev/null +++ b/content/en/feature_flags/concepts/flag_graphs.md @@ -0,0 +1,71 @@ +--- +title: Feature Flag Graphs +description: Understand the graphs on the feature flags list and details pages and how to use them to monitor your rollout. +further_reading: +- link: "/feature_flags/server/" + tag: "Documentation" + text: "Server-Side Feature Flags" +- link: "/feature_flags/client/" + tag: "Documentation" + text: "Client-Side Feature Flags" +- link: "/dashboards/" + tag: "Documentation" + text: "Dashboards" +--- + +## Overview + +Datadog Feature Flags provides graphs at two levels: the flags list page gives a snapshot of all your flags at a glance, and the flag details page shows in-depth graphs for a single flag. + +## Flags list page + +Each summary row shows a total evaluation count and a mini graph, so you can assess activity across your flag inventory without opening each flag. + +{{< img src="feature_flags/flag_graphs/flag_list.png" alt="Feature flags list page showing evaluation counts and sparklines per flag" style="width:100%;" >}} + +Each row shows: + +- **Evaluation count**: Total number of client and server evaluations in the past hour +- **Mini graph**: Individual client and server evaluations in the past hour, grouped by variant +- **Variants**: The variant colors are the key for the mini graph + +## Flag details page + +The flag details page includes observability insights to help you identify how a single flag is performing. + +### Targeting rule evaluation counts + +This shows the total client and server evaluations that fell through to each targeting rule in the given **Real-time metric overview** time range. + +{{< img src="feature_flags/flag_graphs/targeting_rule_distribution.png" alt="Targeting rule evaluation count" style="width:100%;" >}} + +Use this count to confirm that targeting rules are working as expected and to see how traffic is distributed across targeting rules in a given environment, including the percentage of total traffic in the time range. + +### Client and server evaluations + +{{< img src="feature_flags/flag_graphs/evaluations.png" alt="Client and server evaluations graph split by variant" style="width:100%;" >}} + +Client SDK evaluations have two views, each grouped by variant: + +- **Unique**: Count of unique users or entities that evaluated each variant (deduplicated by targeting key) +- **Total**: Count of all evaluations by variant, including repeated evaluations of the same targeting key + +Server SDK evaluations show a count of all evaluations by variant. This requires flag evaluation metrics to be enabled. See [Set Up Server-Side Flag Evaluation Metrics][1]. + +### Errors and latency + +{{< img src="feature_flags/flag_graphs/errors_latency.png" alt="Error and latency graphs" style="width:100%;" >}} + +Error rate and latency graphs are available for client evaluations. They are not available for server evaluations. + +## Export to a dashboard + +{{< img src="feature_flags/flag_graphs/dashboard_export.png" alt="Export graph to a dashboard" style="width:100%;" >}} + +Choose **Save to dashboard** to add a graph to a Datadog dashboard. From there, you can filter and group the data for further insights. + +## Further reading + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /feature_flags/guide/server_flag_evaluation_metrics/ diff --git a/content/en/feature_flags/guide/_index.md b/content/en/feature_flags/guide/_index.md index 244b7ac519a..a15ad227d79 100644 --- a/content/en/feature_flags/guide/_index.md +++ b/content/en/feature_flags/guide/_index.md @@ -12,6 +12,7 @@ cascade: {{< whatsnext desc="Feature Flags Guides:" >}} {{< nextlink href="/getting_started/feature_flags" >}}Getting started with Feature Flags{{< /nextlink >}} + {{< nextlink href="/feature_flags/guide/server_flag_evaluation_metrics" >}}Set Up Server-Side Flag Evaluation Metrics{{< /nextlink >}} {{< nextlink href="/feature_flags/guide/migrate_flags_with_cli" >}}Migrate Flags with the Flag Migration CLI{{< /nextlink >}} {{< nextlink href="/feature_flags/guide/migrate_from_launchdarkly" >}}Migrate Your Feature Flags from LaunchDarkly{{< /nextlink >}} {{< nextlink href="/feature_flags/guide/migrate_from_statsig" >}}Migrate Your Feature Flags from Statsig{{< /nextlink >}} diff --git a/content/en/feature_flags/guide/server_flag_evaluation_metrics.md b/content/en/feature_flags/guide/server_flag_evaluation_metrics.md new file mode 100644 index 00000000000..9313e83912b --- /dev/null +++ b/content/en/feature_flags/guide/server_flag_evaluation_metrics.md @@ -0,0 +1,153 @@ +--- +title: Set Up Server-Side Flag Evaluation Metrics +description: Configure the Datadog Agent and your application to emit and visualize flag evaluation metrics for server-side feature flags. +further_reading: +- link: "/feature_flags/server/" + tag: "Documentation" + text: "Server-Side Feature Flags" +- link: "/feature_flags/concepts/flag_graphs/" + tag: "Documentation" + text: "Feature Flag Graphs" +- link: "/metrics/" + tag: "Documentation" + text: "Metrics" +- link: "/dashboards/" + tag: "Documentation" + text: "Dashboards" +--- + +## Overview + +Flag evaluation metrics let you measure how often each variant of a feature flag is returned by your server-side application. Use these metrics to track flag adoption over time, verify targeting rules are working as expected, and graph flag evaluation data on dashboards. + +
The feature_flag.evaluations metric is experimental and may change or be removed in a future release.
+ +## Prerequisites + +Before setting up flag evaluation metrics, confirm the following: + +- [Server-side feature flags][1] are already configured. +- Datadog Agent 7.32.0 or later is running. +- `DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED=true` is set on your application. +- Your server-side tracer meets the minimum version for flag evaluation metrics support: + +| Language | Minimum tracer version | +| -------- | ---------------------- | +| .NET | 3.44.0 | +| Go | 2.8.0 | +| Java | 1.62.0 | +| Node.js | 5.99.0 | +| PHP | 1.21.1 | +| Python | 4.7.0 | +| Ruby | 2.32.0 | + +## Step 1: Enable the Agent OTLP receiver + +Flag evaluation metrics are emitted over OpenTelemetry (OTLP). The Datadog Agent includes an OTLP receiver that is off by default. For setup instructions, see [OTLP Ingestion by the Datadog Agent][2]. + +You only need to enable the protocol your application uses (gRPC on port 4317, or HTTP on port 4318). + +
If you are running Agent v7.61.0 or later in Docker, set HOST_PROC=/proc on the Agent container to work around a known issue with the OTLP pipeline.
+ +## Step 2: Configure your application + +Set the following environment variable on your application, in addition to the standard [server-side feature flag configuration][1]: + +{{< code-block lang="bash" >}} +# Enable flag evaluation metrics +DD_METRICS_OTEL_ENABLED=true +{{< /code-block >}} + +By default, most tracers send OTLP metrics to the Agent at `DD_AGENT_HOST` on port `4318` (HTTP). If your application already sets `DD_AGENT_HOST` to reach the Agent, no endpoint configuration is required. + +Set an OTLP endpoint explicitly in any of these cases: + +- 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 **Python** tracer. The Python tracer defaults to gRPC on port `4317`, not HTTP. Enable the gRPC OTLP receiver on the Agent, or override the protocol to use HTTP instead: + +{{< code-block lang="bash" >}} +OTEL_EXPORTER_OTLP_ENDPOINT=http://:4318 +OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf +{{< /code-block >}} + +To set the endpoint, use the standard OpenTelemetry variable: + +{{< code-block lang="bash" >}} +# Point OTLP data at the Datadog Agent (HTTP, port 4318) +OTEL_EXPORTER_OTLP_ENDPOINT=http://:4318 + +# Or use gRPC (port 4317). For most tracers, the default protocol is http/protobuf, +# so set the protocol explicitly when switching to gRPC: +# OTEL_EXPORTER_OTLP_ENDPOINT=http://:4317 +# OTEL_EXPORTER_OTLP_PROTOCOL=grpc +{{< /code-block >}} + +Replace `` with the hostname or IP address of your Datadog Agent. + +Docker Compose example: + +{{< code-block lang="yaml" filename="docker-compose.yml" >}} +services: + datadog-agent: + environment: + - DD_OTLP_CONFIG_RECEIVER_PROTOCOLS_GRPC_ENDPOINT=0.0.0.0:4317 + - DD_OTLP_CONFIG_RECEIVER_PROTOCOLS_HTTP_ENDPOINT=0.0.0.0:4318 + - HOST_PROC=/proc # If running Agent v7.61.0+ in Docker + + app-go: + environment: + - DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED=true + - DD_METRICS_OTEL_ENABLED=true + - OTEL_EXPORTER_OTLP_ENDPOINT=http://datadog-agent:4318 + depends_on: + datadog-agent: + condition: service_healthy +{{< /code-block >}} + +## Step 3: Verify metrics are flowing + +After deploying, confirm metrics are reaching Datadog: + +1. Go to [Metrics Explorer][3] and search for `feature_flag.evaluations`. +2. If the metric does not appear within a few minutes of your application evaluating flags, check: + - The Agent OTLP receiver is enabled and the correct port is exposed. + - `OTEL_EXPORTER_OTLP_ENDPOINT` points to the Agent, not a separate collector. + - Your application is actively evaluating flags with a server SDK at runtime (the code path is being executed). + +## Step 4: Enable metric retention + +By default, `feature_flag.evaluations` retains only one hour of data. To retain a longer history: + +1. Go to [Metrics Summary][4] and search for `feature_flag.evaluations`. +2. Select the metric and enable **Historical Metrics**. + +This is an opt-in setting and is not enabled automatically for OTLP metrics. + +## Graph flag evaluations on a dashboard + +Use the following query to graph flag evaluations by flag key and variant on a [dashboard][5]: + +{{< code-block lang="text" >}} +sum:feature_flag.evaluations{*} by {feature_flag.key,feature_flag.result.variant} +{{< /code-block >}} + +The `feature_flag.evaluations` metric is a counter with the following tags: + +| Tag | Description | +| ------------------------------------ | -------------------------------------------------- | +| `feature_flag.key` | The flag key being evaluated | +| `feature_flag.result.variant` | The variant returned by the evaluation | +| `feature_flag.result.reason` | The reason for the evaluation result | +| `feature_flag.result.allocation_key` | The identifier for the evaluated targeting rules (emitted only when present) | +| `error.type` | The error type (emitted only on error evaluations) | + +## Further reading + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /feature_flags/server/ +[2]: /opentelemetry/setup/otlp_ingest_in_the_agent/ +[3]: https://app.datadoghq.com/metric/explorer +[4]: https://app.datadoghq.com/metric/summary +[5]: /dashboards/ diff --git a/content/en/feature_flags/server/_index.md b/content/en/feature_flags/server/_index.md index 2dbe99f0630..6a787d1dee8 100644 --- a/content/en/feature_flags/server/_index.md +++ b/content/en/feature_flags/server/_index.md @@ -8,6 +8,12 @@ further_reading: - link: "/remote_configuration/" tag: "Documentation" text: "Remote Configuration" +- link: "/feature_flags/guide/server_flag_evaluation_metrics/" + tag: "Guide" + text: "Set Up Server-Side Flag Evaluation Metrics" +- link: "/feature_flags/concepts/flag_graphs/" + tag: "Concept" + text: "Feature Flag Graphs" - link: "/feature_flags/implementation_patterns/serverless/" tag: "Documentation" text: "Serverless environments and Feature Flags" @@ -75,14 +81,14 @@ DD_TRACE_AGENT_PORT=8126 DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED=true # Optional: Enable flag evaluation metrics -DD_METRICS_OTEL_ENABLED=true +# See "Set Up Server-Side Flag Evaluation Metrics" documentation {{< /code-block >}}
The DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED=true environment variable is required to enable the feature flagging provider. Java also supports the system property -Ddd.experimental.flagging.provider.enabled=true, and Ruby and Node.js support code-based configuration as an alternative. See the SDK-specific documentation for details.
Remote Configuration must be available for server-side Feature Flags. It is enabled by default on Agent 7.47.0 and later. Only set SDK-level Remote Configuration variables (such as DD_REMOTE_CONFIG_ENABLED=true) if your tracer has Remote Configuration disabled and you need to override that setting.
-
Set DD_METRICS_OTEL_ENABLED=true to enable flag evaluation metrics. Without this, the SDK does not emit metrics for flag evaluations. When enabled, each evaluation records a feature_flag.evaluations counter metric tagged with the flag key, result variant, and evaluation reason.
+See Set Up Server-Side Flag Evaluation Metrics to enable the experimental feature_flag.evaluations metric. See Feature Flag Graphs for more information on available graphing. ## Testing with in-memory providers diff --git a/content/en/feature_flags/server/dotnet.md b/content/en/feature_flags/server/dotnet.md index e50e4c2b724..99c8a905e11 100644 --- a/content/en/feature_flags/server/dotnet.md +++ b/content/en/feature_flags/server/dotnet.md @@ -8,6 +8,12 @@ further_reading: - link: "/tracing/trace_collection/dd_libraries/dotnet-core/" tag: "Documentation" text: ".NET Tracing" +- link: "/feature_flags/guide/server_flag_evaluation_metrics/" + tag: "Guide" + text: "Set Up Server-Side Flag Evaluation Metrics" +- link: "/feature_flags/concepts/flag_graphs/" + tag: "Concept" + text: "Feature Flag Graphs" --- ## Overview @@ -33,7 +39,7 @@ Set the following environment variables: DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED=true # Optional: Enable flag evaluation metrics -DD_METRICS_OTEL_ENABLED=true +# See "Set Up Server-Side Flag Evaluation Metrics" documentation # Required: Service identification DD_SERVICE= @@ -42,6 +48,8 @@ DD_ENV=
The EXPERIMENTAL_ prefix is retained for backwards compatibility; the provider itself is stable.
+See Set Up Server-Side Flag Evaluation Metrics to enable the experimental feature_flag.evaluations metric. See Feature Flag Graphs for more information on available graphing. + ## Installation Install the Datadog [.NET SDK][3] and [OpenFeature SDK][4] using NuGet: diff --git a/content/en/feature_flags/server/go.md b/content/en/feature_flags/server/go.md index d82569af67d..b64a3db8e52 100644 --- a/content/en/feature_flags/server/go.md +++ b/content/en/feature_flags/server/go.md @@ -8,6 +8,12 @@ further_reading: - link: "/tracing/trace_collection/dd_libraries/go/" tag: "Documentation" text: "Go Tracing" +- link: "/feature_flags/guide/server_flag_evaluation_metrics/" + tag: "Guide" + text: "Set Up Server-Side Flag Evaluation Metrics" +- link: "/feature_flags/concepts/flag_graphs/" + tag: "Concept" + text: "Feature Flag Graphs" --- ## Overview @@ -31,7 +37,7 @@ Set the following environment variables: DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED=true # Optional: Enable flag evaluation metrics -DD_METRICS_OTEL_ENABLED=true +# See "Set Up Server-Side Flag Evaluation Metrics" documentation # Required: Service identification DD_SERVICE= @@ -40,6 +46,8 @@ DD_ENV=
The EXPERIMENTAL_ prefix is retained for backwards compatibility; the provider itself is stable.
+See Set Up Server-Side Flag Evaluation Metrics to enable the experimental feature_flag.evaluations metric. See Feature Flag Graphs for more information on available graphing. + ## Installation Install the Datadog OpenFeature provider package: diff --git a/content/en/feature_flags/server/java.md b/content/en/feature_flags/server/java.md index 7ffa4fcc54f..a68c3e8ef8e 100644 --- a/content/en/feature_flags/server/java.md +++ b/content/en/feature_flags/server/java.md @@ -8,10 +8,18 @@ further_reading: - link: "/tracing/trace_collection/automatic_instrumentation/dd_libraries/java/" tag: "Documentation" text: "Java APM and Distributed Tracing" +- link: "/feature_flags/guide/server_flag_evaluation_metrics/" + tag: "Guide" + text: "Set Up Server-Side Flag Evaluation Metrics" +- link: "/feature_flags/concepts/flag_graphs/" + tag: "Concept" + text: "Feature Flag Graphs" ---
Enable Java Feature Flags by setting DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED=true. The EXPERIMENTAL_ prefix is kept for backwards compatibility; the provider is stable. See the Configuration section for details.
+See Set Up Server-Side Flag Evaluation Metrics to enable the experimental feature_flag.evaluations metric. See Feature Flag Graphs for more information on available graphing. + ## Overview 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. @@ -122,7 +130,7 @@ Configure your Java application with the required environment variables or syste export DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED=true # Optional: Enable flag evaluation metrics -export DD_METRICS_OTEL_ENABLED=true +# See "Set Up Server-Side Flag Evaluation Metrics" documentation # Required: Service name export DD_SERVICE= @@ -142,7 +150,6 @@ java -javaagent:path/to/dd-java-agent.jar -jar your-application.jar {{< code-block lang="bash" >}} java -javaagent:path/to/dd-java-agent.jar \ -Ddd.experimental.flagging.provider.enabled=true \ - -Ddd.metrics.otel.enabled=true \ -Ddd.service= \ -Ddd.env= \ -Ddd.version= \ @@ -161,9 +168,8 @@ The Datadog feature flagging system starts automatically when the tracer is init For instructions on how to add the `-javaagent` argument to your application server or framework, see [Add the Java SDK to the JVM](/tracing/trace_collection/automatic_instrumentation/dd_libraries/java/#add-the-java-sdk-to-the-jvm). -Make sure to include the feature flagging configuration flags: +Make sure to include the feature flagging configuration flag: - `-Ddd.experimental.flagging.provider.enabled=true` -- `-Ddd.metrics.otel.enabled=true` if you want flag evaluation metrics ## Initialize the OpenFeature provider @@ -660,7 +666,7 @@ Review `reason` and `errorCode` to understand why the provider returned a given #### Flag evaluation metrics -Flag evaluation counts appear in Datadog when `DD_METRICS_OTEL_ENABLED=true` is set on the tracer. Each evaluation emits a `feature_flag.evaluations` counter metric tagged with the flag key, result variant, and evaluation reason. If this metric does not appear, verify the setting is enabled and the tracer version supports it. +Flag evaluation counts appear in Datadog as a `feature_flag.evaluations` counter metric tagged with the flag key, result variant, and evaluation reason. See Set Up Server-Side Flag Evaluation Metrics for the full setup guide and troubleshooting steps. #### Experiment exposures diff --git a/content/en/feature_flags/server/nodejs.md b/content/en/feature_flags/server/nodejs.md index 5c2d95e8fa7..8fd305e5f79 100644 --- a/content/en/feature_flags/server/nodejs.md +++ b/content/en/feature_flags/server/nodejs.md @@ -11,6 +11,12 @@ further_reading: - link: "/tracing/" tag: "Documentation" text: "Learn about Application Performance Monitoring (APM)" +- link: "/feature_flags/guide/server_flag_evaluation_metrics/" + tag: "Guide" + text: "Set Up Server-Side Flag Evaluation Metrics" +- link: "/feature_flags/concepts/flag_graphs/" + tag: "Concept" + text: "Feature Flag Graphs" --- ## Overview @@ -41,11 +47,13 @@ Enable the provider with environment variables: DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED=true # Optional: Enable flag evaluation metrics -DD_METRICS_OTEL_ENABLED=true +# See "Set Up Server-Side Flag Evaluation Metrics" documentation ```
The EXPERIMENTAL_ prefix is retained for backwards compatibility; the provider itself is stable.
+See Set Up Server-Side Flag Evaluation Metrics to enable the experimental feature_flag.evaluations metric. See Feature Flag Graphs for more information on available graphing. + Or enable the provider in code: ```javascript diff --git a/content/en/feature_flags/server/python.md b/content/en/feature_flags/server/python.md index 6c46d900916..3ea8aa9baec 100644 --- a/content/en/feature_flags/server/python.md +++ b/content/en/feature_flags/server/python.md @@ -8,6 +8,12 @@ further_reading: - link: "/tracing/trace_collection/dd_libraries/python/" tag: "Documentation" text: "Python Tracing" +- link: "/feature_flags/guide/server_flag_evaluation_metrics/" + tag: "Guide" + text: "Set Up Server-Side Flag Evaluation Metrics" +- link: "/feature_flags/concepts/flag_graphs/" + tag: "Concept" + text: "Feature Flag Graphs" --- ## Overview @@ -32,7 +38,7 @@ Set the following environment variables: export DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED=true # Optional: Enable flag evaluation metrics -export DD_METRICS_OTEL_ENABLED=true +# See "Set Up Server-Side Flag Evaluation Metrics" documentation # Required: Service identification export DD_SERVICE= @@ -41,6 +47,8 @@ export DD_ENV=
The EXPERIMENTAL_ prefix is retained for backwards compatibility; the provider itself is stable.
+See Set Up Server-Side Flag Evaluation Metrics to enable the experimental feature_flag.evaluations metric. See Feature Flag Graphs for more information on available graphing. + ## Installation Install the Datadog Python SDK and OpenFeature SDK: diff --git a/content/en/feature_flags/server/ruby.md b/content/en/feature_flags/server/ruby.md index a0fcb51bdee..0c18b29ed5a 100644 --- a/content/en/feature_flags/server/ruby.md +++ b/content/en/feature_flags/server/ruby.md @@ -11,6 +11,12 @@ further_reading: - link: "/tracing/" tag: "Documentation" text: "Learn about Application Performance Monitoring (APM)" +- link: "/feature_flags/guide/server_flag_evaluation_metrics/" + tag: "Guide" + text: "Set Up Server-Side Flag Evaluation Metrics" +- link: "/feature_flags/concepts/flag_graphs/" + tag: "Concept" + text: "Feature Flag Graphs" --- ## Overview @@ -44,11 +50,13 @@ You can enable Feature Flags with environment variables: DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED=true # Optional: Enable flag evaluation metrics -DD_METRICS_OTEL_ENABLED=true +# See "Set Up Server-Side Flag Evaluation Metrics" documentation ```
The EXPERIMENTAL_ prefix is retained for backwards compatibility; the provider itself is stable.
+See Set Up Server-Side Flag Evaluation Metrics to enable the experimental feature_flag.evaluations metric. See Feature Flag Graphs for more information on available graphing. + Or enable the provider in code: ```ruby diff --git a/content/en/getting_started/feature_flags/_index.md b/content/en/getting_started/feature_flags/_index.md index 784d23196b5..e8705a8622b 100644 --- a/content/en/getting_started/feature_flags/_index.md +++ b/content/en/getting_started/feature_flags/_index.md @@ -369,6 +369,8 @@ Monitor the feature rollout from the feature flag details page, which provides r {{< img src="getting_started/feature_flags/real-time-flag-metrics.png" alt="Real-time flag metrics panel" style="width:100%;" >}} +For server-side applications, you can also enable flag evaluation metrics to track how often each variant is returned and graph the data on dashboards. See [Set Up Server-Side Flag Evaluation Metrics][9]. + ## Further reading {{< partial name="whats-next/whats-next.html" >}} @@ -381,3 +383,4 @@ Monitor the feature rollout from the feature flag details page, which provides r [6]: /feature_flags/concepts/distribution_channels/ [7]: /feature_flags/concepts/targeting_rules/ [8]: /feature_flags/concepts/traffic_splitting/ +[9]: /feature_flags/guide/server_flag_evaluation_metrics/ diff --git a/content/en/llm_observability/instrumentation/auto_instrumentation.md b/content/en/llm_observability/instrumentation/auto_instrumentation.md index 9a04cecd771..bb17fe2f0de 100644 --- a/content/en/llm_observability/instrumentation/auto_instrumentation.md +++ b/content/en/llm_observability/instrumentation/auto_instrumentation.md @@ -56,6 +56,7 @@ Agent Observability can automatically trace and annotate calls to supported LLM | [Amazon Bedrock](#amazon-bedrock) | >= 3.422.0 | >= 5.35.0 (CJS), >=5.35.0 (ESM) | | [Anthropic](#anthropic) | >= 0.14.0 | >= 5.71.0 (CJS), >=5.71.0 (ESM) | | [LangChain](#langchain) | >= 0.1.0 | >= 5.32.0 (CJS), >=5.38.0 (ESM) | +| [MCP](#mcp) | >= 1.27.1 | >= 5.99.0 (CJS), >=5.99.0 (ESM) | | [OpenAI](#openai), [Azure OpenAI](#openai) | >= 3.0.0 | >= 4.49.0, >= 5.25.0 (CJS), >= 5.38.0 (ESM) | | [Vercel AI SDK](#vercel-ai-sdk) | >=4.0.0 | >= 5.63.0 (CJS), >=5.63.0 (ESM) | | [VertexAI](#vertex-ai) | >= 1.0.0 | >= 5.44.0 (CJS), >=5.44.0 (ESM) | @@ -129,7 +130,7 @@ Datadog's LLM integrations capture latency, errors, input parameters, input and {{% tab "Python" %}} The [Amazon Bedrock integration][1] provides automatic instrumentation for the Amazon Bedrock Runtime Python SDK's chat model calls (using [Boto3][2]/[Botocore][3]). -**Package name:** `boto3` +**Package name:** `boto3`\ **Integration name:** `botocore` ### Traced methods @@ -159,7 +160,7 @@ The Amazon Bedrock integration instruments the following methods: {{% tab "Node.js" %}} The [Amazon Bedrock integration][1] provides automatic tracing for the Amazon Bedrock Runtime Node.js SDK's chat model calls (using [BedrockRuntimeClient][2]). -**Package name:** `@aws-sdk/client-bedrock-runtime` +**Package name:** `@aws-sdk/client-bedrock-runtime`\ **Integration name:** `aws-sdk` ### Traced methods @@ -183,7 +184,7 @@ The Amazon Bedrock integration instruments the following methods: {{% tab "Python" %}} The Amazon Bedrock Agents integration provides automatic tracing for the Amazon Bedrock Agents Runtime Python SDK's agent invoke calls (using [Boto3][1]/[Botocore][2]). -**Package name:** `boto3` +**Package name:** `boto3`\ **Integration name:** `botocore` ### Traced methods @@ -208,7 +209,7 @@ tracing intra-agent steps, you must set enableTrace=True in the }} {{% /collapse-content %}} @@ -556,7 +575,7 @@ The MCP integration instruments the following methods: {{% tab "Python" %}} The [OpenAI integration][1] provides automatic tracing for the [OpenAI Python SDK's][2] completion and chat completion endpoints to OpenAI and Azure OpenAI. -**Package name:** `openai` +**Package name:** `openai`\ **Integration name:** `openai` ### Traced methods @@ -588,7 +607,7 @@ The OpenAI integration instruments the following methods, including streamed cal {{% tab "Node.js" %}} The [OpenAI integration][1] provides automatic tracing for the [OpenAI Node.js SDK's][2] completion, chat completion, and embeddings endpoints to OpenAI and [Azure OpenAI][3]. -**Package name:** `openai` +**Package name:** `openai`\ **Integration name:** `openai` ### Traced methods @@ -661,7 +680,7 @@ The provider (OpenAI vs Azure OpenAI) is automatically detected based on the `ba The OpenAI Agents integration converts the [built-in tracing][1] from the [OpenAI Agents SDK][2] into Agent Observability format and sends it to Agent Observability product by adding a Datadog trace processor. -**Package name:** `openai-agents` +**Package name:** `openai-agents`\ **Integration name:** `openai_agents` The following operations are supported: @@ -693,7 +712,7 @@ The following operations are supported: {{% tab "Python" %}} The Pydantic AI integration instruments agent invocations and tool calls made using the [Pydantic AI][1] agent framework. -**Package name:** `pydantic-ai` +**Package name:** `pydantic-ai`\ **Integration name:** `pydantic_ai` ### Traced methods @@ -730,7 +749,7 @@ For setup instructions and a complete example, see [OpenTelemetry Instrumentatio {{% tab "Node.js" %}} The [Vercel AI SDK][1] integration automatically traces text and object generation, embeddings, and tool calls by intercepting the OpenTelemetry spans created by the underlying core [Vercel AI SDK][2] and converting them into Agent Observability spans. -**Package name:** `ai` +**Package name:** `ai`\ **Integration name:** `ai` ### Traced methods @@ -795,7 +814,7 @@ async function main () { {{% tab "Python" %}} The [Vertex AI integration][1] automatically traces content generation and chat message calls made through [Google's Vertex AI Python SDK][2]. -**Package name:** `vertexai` +**Package name:** `vertexai`\ **Integration name:** `vertexai` ### Traced methods @@ -819,7 +838,7 @@ The Vertex AI integration instruments the following methods: {{% tab "Node.js" %}} The [Vertex AI integration][1] automatically traces content generation and chat message calls made through [Google's Vertex AI Node.js SDK][2]. -**Package name:** `@google-cloud/vertexai` +**Package name:** `@google-cloud/vertexai`\ **Integration name:** `google-cloud-vertexai` ### Traced methods @@ -846,7 +865,7 @@ The Vertex AI integration instruments the following methods: {{% tab "Python" %}} The vLLM integration automatically traces request processing and token generation in the [vLLM][1] inference engine. It captures model name, input and output tokens, and latency metrics (time to first token, queue time, prefill time, decode time, and inference time). -**Package name:** `vllm` +**Package name:** `vllm`\ **Integration name:** `vllm` ### Traced methods diff --git a/content/en/llm_observability/monitoring/mcp_client.md b/content/en/llm_observability/monitoring/mcp_client.md index 7988c273f08..e0e9396df85 100644 --- a/content/en/llm_observability/monitoring/mcp_client.md +++ b/content/en/llm_observability/monitoring/mcp_client.md @@ -11,18 +11,21 @@ further_reading: You can monitor your MCP clients with Agent Observability in two ways: -- [Automatic instrumentation](#automatically-instrument-your-mcp-client): If you are using the official [MCP Python SDK][1] -- [Manual instrumentation](#manually-instrument-your-mcp-client): If you are not using the official MCP Python SDK, or your MCP clients are written in Node.js or Java +- [Automatic instrumentation](#automatically-instrument-your-mcp-client): If you are using the official [MCP Python SDK][1] or [MCP JavaScript SDK][3] +- [Manual instrumentation](#manually-instrument-your-mcp-client): If you are not using an official MCP SDK, or your MCP clients are written in Java ## Automatically instrument your MCP client +{{< tabs >}} + +{{% tab "Python" %}} If you are using the official MCP Python SDK to connect to an MCP server with an MCP client session, use the following steps to automatically instrument your MCP client application: 1. Install `ddtrace`: - {{< code-block lang="shell">}} -pip install ddtrace -{{< /code-block >}} + ```shell + pip install ddtrace + ``` 2. Set the required environment variables: @@ -36,9 +39,46 @@ pip install ddtrace 3. Run your application with the `ddtrace-run` command: - {{< code-block lang="shell">}} -ddtrace-run -{{< /code-block >}} + ```shell + ddtrace-run + ``` + +For additional configuration options, see the [Agent Observability SDK setup guide][1]. + +[1]: /llm_observability/instrumentation/sdk?tab=python#setup +{{% /tab %}} + +{{% tab "Node.js" %}} +If you are using the official MCP JavaScript SDK to connect to an MCP server with an MCP client session, use the following steps to automatically instrument your MCP client application: + +1. Install `dd-trace`: + + ```shell + npm install dd-trace + ``` + +2. Set the required environment variables: + + ```shell + export DD_LLMOBS_ENABLED=true + export DD_LLMOBS_ML_APP= + export DD_LLMOBS_AGENTLESS_ENABLED=true + export DD_API_KEY= + export DD_SITE={{< region-param key="dd_site" >}} + ``` + +3. Run your application: + + ```shell + NODE_OPTIONS="--import dd-trace/initialize.mjs" node + ``` + +For additional configuration options, see the [Agent Observability SDK setup guide][1]. + +[1]: /llm_observability/instrumentation/sdk?tab=nodejs#setup +{{% /tab %}} + +{{< /tabs >}} ## Manually instrument your MCP client @@ -401,7 +441,7 @@ ddtrace-run {{% tab "Node.js" %}} {{< code-block lang="shell">}} -NODE_OPTIONS="--import dd-trace/initialize.mjs" +NODE_OPTIONS="--import dd-trace/initialize.mjs" node {{< /code-block >}} {{% /tab %}} @@ -418,4 +458,5 @@ java -javaagent:dd-java-agent.jar -Ddd.llmobs.enabled=true -Ddd.llmobs.ml-app=}} [1]: https://github.com/modelcontextprotocol/python-sdk -[2]: /llm_observability/instrumentation/sdk \ No newline at end of file +[2]: /llm_observability/instrumentation/sdk +[3]: https://github.com/modelcontextprotocol/typescript-sdk \ No newline at end of file diff --git a/content/en/metrics/volume.md b/content/en/metrics/volume.md index a757d75681d..0dc05413045 100644 --- a/content/en/metrics/volume.md +++ b/content/en/metrics/volume.md @@ -20,6 +20,8 @@ further_reading: Cloud-based applications generate massive amounts of data, which can be overwhelming for your organization as it scales. Observability costs become a significant budget item but core observability teams lack visibility into what is truly valuable to each individual engineering team. Individual teams are less incentivized to be proactive in helping manage this growth because they have limited insights into the costs of the metrics and tags they're submitting. +
For customers on the Metric Name Pricing model, see the guide to optimize your metric usage.
+ Datadog's [Metrics Volume Management page][1] provides comprehensive visibility and intelligent insights for which metrics you should focus your cost-optimization efforts. When used with [Metrics without Limits™][3], Metrics Volume allows for flexible configuration of metrics ingestion and indexing to reduce costs without sacrificing accuracy. With the Metrics Volume Management page you can access the following in real-time: @@ -123,4 +125,4 @@ To determine why a particular metric name is emitting a large number of custom m [3]: /metrics/metrics-without-limits [4]: https://app.datadoghq.com/metric/volume?bulk_manage_tags=true&facet.query_activity=-queried&sort=volume_total [5]: #reduce-metric-volume-and-cost -[6]: https://docs.datadoghq.com/account_management/billing/custom_metrics/?tab=countrategauge +[6]: https://docs.datadoghq.com/account_management/billing/custom_metrics/?tab=countrategauge \ No newline at end of file diff --git a/content/en/monitors/types/data_observability.md b/content/en/monitors/types/data_observability.md index 0f6ddc8b849..e9e7436f818 100644 --- a/content/en/monitors/types/data_observability.md +++ b/content/en/monitors/types/data_observability.md @@ -196,6 +196,7 @@ Set how often the monitor evaluates your data: - **Hourly**: The monitor runs every hour. - **Daily**: The monitor runs once per day. +- **Manual**: The monitor runs only when triggered programmatically. Trigger these monitors using the [Data Observability API][10] on a schedule so enough historical data can accumulate for modeling to be useful. Currently, the UI does not support default metrics like row counts and freshness, so this workflow only applies to custom or column-level metrics. ### Set alert conditions @@ -298,3 +299,4 @@ On a monitor's status page, click **Annotate Bounds**, select a time range on th [7]: https://app.datadoghq.com/data-obs/monitors [8]: /monitors/configuration/?tab=thresholdalert#thresholds [9]: /help/ +[10]: /api/latest/data-observability/ diff --git a/content/en/observability_pipelines/guide/strategies_for_reducing_log_volume.md b/content/en/observability_pipelines/guide/strategies_for_reducing_log_volume.md index 55a69e33591..bff4bf039c1 100644 --- a/content/en/observability_pipelines/guide/strategies_for_reducing_log_volume.md +++ b/content/en/observability_pipelines/guide/strategies_for_reducing_log_volume.md @@ -6,7 +6,7 @@ further_reading: tag: "documentation" text: "Set up a pipeline" - link: "/observability_pipelines/processors/" - tag: "documemtation" + tag: "documentation" text: "Observability Pipelines processors" --- diff --git a/content/en/observability_pipelines/processors/generate_metrics.md b/content/en/observability_pipelines/processors/generate_metrics.md index a7d9228943a..6b6bf15464d 100644 --- a/content/en/observability_pipelines/processors/generate_metrics.md +++ b/content/en/observability_pipelines/processors/generate_metrics.md @@ -24,7 +24,7 @@ Click **Manage Metrics** to create new metrics or edit existing metrics. This op - If you have not created any metrics yet, enter the metric parameters as described in the [Add a metric](#add-a-metric) section to create a metric. - If you have already created metrics, click on the metric's row in the overview table to edit or delete it. Use the search bar to find a specific metric by its name, and then select the metric to edit or delete it. Click **Add Metric** to add another metric. -##### Add a metric +### Add a metric 1. Enter a filter query. Only logs that match the specified filter query are processed. All logs, regardless of whether they match the filter query, are sent to the next step in the pipeline. See [Search Syntax][5] for more information. **Note**: Since a single processor can generate multiple metrics, you can define a different filter query for each metric. 1. Enter a name for the metric. @@ -34,7 +34,7 @@ Click **Manage Metrics** to create new metrics or edit existing metrics. This op - The **Group by** field determines how the metric values are grouped together. For example, if you have hundreds of hosts spread across four regions, grouping by region allows you to graph one line for every region. The fields listed in the **Group by** setting are set as tags on the configured metric. 1. Click **Add Metric**. -##### Metrics types +## Metrics types You can generate these types of metrics for your logs. See the [Metrics types][3] and [Distributions][4] documentation for more details. @@ -44,7 +44,7 @@ You can generate these types of metrics for your logs. See the [Metrics types][3 | GAUGE | A snapshot of a value at the time it is reported. | You want to track the latest CPU utilization per host. | | DISTRIBUTION | Raw values sent to Datadog so percentile aggregations (such as p95, p99) are computed server-side, globally across every host reporting the metric. | You want the global p95 of `response_time_seconds` across every host serving an API endpoint. | -##### Count metric example +### Count metric example For this `status:error` log example: @@ -61,7 +61,7 @@ To create a count metric that counts the number of logs that contain `"status":" | Metric type | Count | | Group by | `env`, `prod` | -##### Distribution metric example +### Distribution metric example For this example of an API response log: diff --git a/content/en/security/cloud_security_management/setup/agentless_scanning/enable.md b/content/en/security/cloud_security_management/setup/agentless_scanning/enable.md index 979e403f92b..93747bf8d5f 100644 --- a/content/en/security/cloud_security_management/setup/agentless_scanning/enable.md +++ b/content/en/security/cloud_security_management/setup/agentless_scanning/enable.md @@ -129,6 +129,7 @@ Use CloudFormation if you already have an AWS account integrated with Datadog an 1. On the [Cloud Security Setup][1] page, click **Cloud Integrations** > **AWS**. 1. At the bottom of the AWS section, click **Add AWS accounts by following these steps**. The **Add New AWS Account(s)** dialog is displayed. +1. Select the **Add a Single AWS Account** and **CloudFormation** options. 1. Select the AWS region where you want to create the CloudFormation stack. 1. Select an API key that has [Remote Configuration][3] enabled. 1. Choose whether to enable **Sensitive Data Scanner** for cloud storage. This automatically catalogs and classifies sensitive data in Amazon S3 resources. @@ -140,8 +141,13 @@ Use CloudFormation if you already have an AWS account integrated with Datadog an 1. Click the AWS account where you want to deploy the Agentless scanner, which opens the side panel. 1. On the **Features** tab, click **Configure Agentless Scanning** or **Manage** to open the Agentless Scanning Setup modal. 1. In the **How would you like to set up Agentless Scanning?** section, select **CloudFormation**. +1. Select the AWS region that corresponds to the CloudFormation stack. 1. Select an API key that has [Remote Configuration][3] enabled. -1. Toggle the features you want to enable, such as **Vulnerability Management** or **Sensitive Data Scanner**. +1. Copy the new application key Datadog generates. +1. Choose to either: + - Use an existing scanner, then select the scanner you want to use. + - Deploy a nwe scanner. +1. Toggle the features you want to enable, such as **Agentless Vulnerability Management** or **Sensitive Data Scanning for Cloud Storage**. 1. Click **Launch CloudFormation Template**. A new window opens, displaying the AWS CloudFormation screen. Use the provided CloudFormation template to create a stack. 1. Click **Done**. @@ -157,9 +163,9 @@ This setup deploys the delegate role required for [cross-account scanning](/secu #### Prerequisites -1. Access to the AWS management account. -1. [Trusted Access with AWS Organizations](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-orgs-enable-trusted-access.html) must be enabled for CloudFormation StackSets. -1. Agentless Scanning is already configured in your central scanning account (see above). +- Access to the AWS management account +- [Trusted Access with AWS Organizations](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-orgs-enable-trusted-access.html) must be enabled for CloudFormation StackSets +- Agentless Scanning already configured in your central scanning account ([see above](#aws-cloudformation-setup)) #### Deploy the StackSet @@ -194,7 +200,7 @@ The [Terraform Datadog Agentless Scanner module](https://github.com/DataDog/terr 1. On the [Cloud Security Setup][1] page, click **Cloud Integrations** > **AWS**. 1. At the bottom of the AWS section, click **Add AWS accounts by following these steps**. The **Add New AWS Account(s)** dialog is displayed. -1. Under **Choose a method for adding your AWS account**, select **Manually**. +1. Select the **Add a Single AWS Account** and **Manually** options. 1. Follow the instructions for installing the [Datadog Agentless Scanner module][2]. 1. Select the **I confirm that the Datadog IAM Role has been added to the AWS Account** checkbox. 1. Enter the **AWS Account ID** and **AWS Role Name**. @@ -207,7 +213,7 @@ The [Terraform Datadog Agentless Scanner module](https://github.com/DataDog/terr 1. On the **Features** tab, click **Configure Agentless Scanning** or **Manage** to open the Agentless Scanning Setup modal. 1. In the **How would you like to set up Agentless Scanning?** section, select **Terraform**. 1. Follow the instructions for installing the [Datadog Agentless Scanner module][2]. -1. Select the **I confirm the Terraform module is installed** checkbox. +1. Select the **I confirm the Datadog Agentless Scanner was installed using Terraform** checkbox. 1. Click **Done**. [1]: https://app.datadoghq.com/security/configuration/csm/setup diff --git a/content/en/security/code_security/static_analysis/ai_enhanced_sast.md b/content/en/security/code_security/static_analysis/ai_enhanced_sast.md index 7c56f91ed6e..744b8f7abb0 100644 --- a/content/en/security/code_security/static_analysis/ai_enhanced_sast.md +++ b/content/en/security/code_security/static_analysis/ai_enhanced_sast.md @@ -77,11 +77,13 @@ AI-native SAST uses a two-phase approach: ### Supported languages -| Language | Status | -| -------- | ----------- | -| Java | Available | -| Python | Available | -| Go | Available | +| Language | Status | +| ---------- | ----------- | +| Java | Available | +| Python | Available | +| Go | Available | +| C# | Available | +| JavaScript | Available | ### Detected vulnerability types @@ -102,7 +104,7 @@ AI-native SAST detects the following vulnerability types: - [CWE-94: Code Injection](https://cwe.mitre.org/data/definitions/94.html) - [CWE-501: Trust Boundary Violation](https://cwe.mitre.org/data/definitions/501.html) - [CWE-284: Broken Access Control (IDOR)](https://cwe.mitre.org/data/definitions/284.html) -- [CWE-1427: Server-Side Template Injection](https://cwe.mitre.org/data/definitions/1427.html) +- [CWE-1427: Prompt Injection](https://cwe.mitre.org/data/definitions/1427.html) {{% /collapse-content %}}