diff --git a/.github/labeler.yml b/.github/labeler.yml index 03ecfcc7fd1..f25418a608d 100644 --- a/.github/labeler.yml +++ b/.github/labeler.yml @@ -2,29 +2,29 @@ Github: - .github/**/* Images: -- static/images/**/* +- hugo/static/images/**/* Architecture: -- local/**/* -- layouts/**/* -- config/**/* -- assets/**/* +- hugo/local/**/* +- hugo/layouts/**/* +- hugo/config/**/* +- hugo/assets/**/* $1: -- content/en/([^/]+)/.* +- hugo/content/en/([^/]+)/.* FAQ: -- content/en/*/faq/* +- hugo/content/en/*/faq/* Guide: -- content/en/*/guide/* +- hugo/content/en/*/guide/* eci: # Emerging Cloud Integrations team - integrations-internal-core/oracle_cloud_infrastructure/**/* cdocs: -- customization_config/ -- content/en/**/*.mdoc.md -- layouts/shortcodes/**/*.mdoc.md -- content/.gitignore +- hugo/customization_config/ +- hugo/content/en/**/*.mdoc.md +- hugo/layouts/shortcodes/**/*.mdoc.md +- hugo/content/.gitignore diff --git a/.gitignore b/.gitignore index f5c9cf2bb6d..4b3d52339c6 100644 --- a/.gitignore +++ b/.gitignore @@ -1,5 +1,26 @@ # Hugo +# Pre-Hugo-reorganization files left at the repository root. The canonical +# project files now live under /hugo; do not add root-level copies back to Git. +/.hugo_build.lock +/.yarn/ +/_vendor/ +/agent_config_types_list.txt +/content/ +/data/ +/examples/ +/hugpython/ +/integrations_data/ +/layouts/ +/local/ +/Makefile.config +/node_modules/ +/playwright-report/ +/public/ +/resources/ +/static/ +/test-results/ + # htmltest tmp files bin/htmltest htmltest_report.txt diff --git a/.husky/check-section-index.py b/.husky/check-section-index.py index dce7fc0a451..dd97e6dfba5 100644 --- a/.husky/check-section-index.py +++ b/.husky/check-section-index.py @@ -35,12 +35,12 @@ def get_staged_files(): def get_top_level_dir(file_path): """Extract the top-level directory under content/en/ from a file path. - For example, 'content/en/new_section/sub/page.md' returns 'new_section'. + For example, 'hugo/content/en/new_section/sub/page.md' returns 'new_section'. """ parts = Path(file_path).parts - # parts: ('content', 'en', 'new_section', ...) - if len(parts) > 2: - return parts[2] + # parts: ('hugo', 'content', 'en', 'new_section', ...) + if len(parts) > 3: + return parts[3] return None @@ -83,7 +83,7 @@ def has_index_file(repo_root, dir_name): return True # Also check if either variant is staged (new but not yet on disk) for name in ('_index.md', '_index.mdoc.md'): - relative = f'hugo/hugo/content/en/{dir_name}/{name}' + relative = f'hugo/content/en/{dir_name}/{name}' try: subprocess.run( ['git', 'show', f':{relative}'], diff --git a/REPO_REORG.md b/REPO_REORG.md index 55ed93f671f..1c2489c6f2e 100644 --- a/REPO_REORG.md +++ b/REPO_REORG.md @@ -30,6 +30,22 @@ When an automatic fix is not possible, we'll defer to the author's best judgment We'll institute a code freeze while the reorg is in progress, likely for a few hours on the morning of the reorg. We'll lift the freeze after the reorg changes have been merged, the build is confirmed to be operational, and the open PRs have been processed. +### Post migration cleanup + +After the migration has been completed: +- Your local repo will have some redundant files hanging out in the root directory. We've added them to `.gitignore` to prevent anyone from adding them back to the repo, but they take up space and clutter your local directory. +- You need to move your `Makefile.config` to the `hugo/` directory. + +You can run the following script to clean up your local repo and move the config file into the correct place: +```sh +./hugo/scripts/post-migration-cleanup.sh +``` + +The script deletes a lot of files, so it take a little while to complete. + ## Owners This project is owned by the WebOps Platform team (#webops-platform). + + + diff --git a/hugo/config/_default/menus/api.en.yaml b/hugo/config/_default/menus/api.en.yaml index 6cfc2089368..a0e4a16a330 100644 --- a/hugo/config/_default/menus/api.en.yaml +++ b/hugo/config/_default/menus/api.en.yaml @@ -18553,49 +18553,6 @@ menu: - ListRumMetrics unstable: [] order: 1 - - name: Rum Rate Limit - url: /api/latest/rum-rate-limit/ - identifier: rum-rate-limit - generated: true - - name: Create or update a RUM rate limit configuration - url: /api/latest/rum-rate-limit/create-or-update-a-rum-rate-limit-configuration/ - identifier: rum-rate-limit-create-or-update-a-rum-rate-limit-configuration - parent: rum-rate-limit - generated: true - params: - versions: - - v2 - operationids: - - UpdateRumRateLimitConfig - unstable: - - v2 - order: 2 - - name: Get a RUM rate limit configuration - url: /api/latest/rum-rate-limit/get-a-rum-rate-limit-configuration/ - identifier: rum-rate-limit-get-a-rum-rate-limit-configuration - parent: rum-rate-limit - generated: true - params: - versions: - - v2 - operationids: - - GetRumRateLimitConfig - unstable: - - v2 - order: 1 - - name: Delete a RUM rate limit configuration - url: /api/latest/rum-rate-limit/delete-a-rum-rate-limit-configuration/ - identifier: rum-rate-limit-delete-a-rum-rate-limit-configuration - parent: rum-rate-limit - generated: true - params: - versions: - - v2 - operationids: - - DeleteRumRateLimitConfig - unstable: - - v2 - order: 3 - name: Rum Replay Heatmaps url: /api/latest/rum-replay-heatmaps/ identifier: rum-replay-heatmaps diff --git a/hugo/config/_default/menus/main.en.yaml b/hugo/config/_default/menus/main.en.yaml index 6b4e4bc7782..6ba017882ec 100644 --- a/hugo/config/_default/menus/main.en.yaml +++ b/hugo/config/_default/menus/main.en.yaml @@ -5477,6 +5477,12 @@ menu: identifier: openlineage_datadog_agent_for_openlineage parent: openlineage_integrations weight: 1000000 + - name: Integration Overhead + url: data_observability/integration_overhead + pre: data-observability-wui + identifier: data_observability_integration_overhead + parent: data_observability_heading + weight: 90000 - name: Agent Observability url: llm_observability/ pre: llm-observability @@ -6244,31 +6250,36 @@ menu: parent: code_coverage identifier: code_coverage_configuration weight: 2 + - name: Coverage Calculation + url: code_coverage/coverage_calculation/ + parent: code_coverage + identifier: code_coverage_coverage_calculation + weight: 3 - name: Monorepo Support url: code_coverage/monorepo_support/ parent: code_coverage identifier: code_coverage_monorepo_support - weight: 3 + weight: 4 - name: Flags url: code_coverage/flags/ parent: code_coverage identifier: code_coverage_flags - weight: 4 + weight: 5 - name: Carryforward url: code_coverage/carryforward/ parent: code_coverage identifier: code_coverage_carryforward - weight: 5 + weight: 6 - name: Data Collected url: code_coverage/data_collected/ parent: code_coverage identifier: code_coverage_data_collected - weight: 5 + weight: 7 - name: Dashboards url: code_coverage/dashboards/ parent: code_coverage identifier: code_coverage_dashboards - weight: 6 + weight: 8 - name: PR Gates url: pr_gates/ pre: ci diff --git a/hugo/content/en/account_management/scim/entra.md b/hugo/content/en/account_management/scim/entra.md index 3b91bfa7433..1b30c45b863 100644 --- a/hugo/content/en/account_management/scim/entra.md +++ b/hugo/content/en/account_management/scim/entra.md @@ -84,7 +84,7 @@ When using SAML and SCIM together, Datadog strongly recommends disabling SAML ju 7. After you set your mappings, click {{< ui >}}Save{{< /ui >}}. -To provision a user's Datadog role (built-in or custom), map the `roles` attribute as shown above, using the `AppRoleAssignmentsComplex([appRoleAssignments])` expression for the Microsoft Entra ID attribute. Roles follow the SCIM multi-valued attribute convention defined in [RFC 7643][9]. If a SCIM request sends multiple roles, Datadog provisions only the roles that match a role in your organization. If none match, the user falls back to the org default role (Standard), and unmatched roles are logged to Audit Trail. For more details, see [SCIM][1]. +To provision a user's Datadog role (built-in or custom), map the `roles` attribute as shown above, using the `AppRoleAssignmentsComplex([appRoleAssignments])` expression for the Microsoft Entra ID attribute. If `roles` is not available in the target attribute dropdown, add it as a **multi-valued** string attribute. For configuration instructions, see [Microsoft's attribute-mapping documentation][10]. Roles follow the SCIM multi-valued attribute convention defined in [RFC 7643][9]. If a SCIM request sends multiple roles, Datadog provisions only the roles that match a role in your organization. If none match, the user falls back to the org default role (Standard), and unmatched roles are logged to Audit Trail. For more details, see [SCIM][1]. ### Group attributes @@ -99,3 +99,4 @@ Group mapping is not supported. [7]: https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference#cloud-application-administrator [8]: https://learn.microsoft.com/en-us/entra/identity/app-provisioning/application-provisioning-config-problem-scim-compatibility#flags-to-alter-the-scim-behavior [9]: https://www.rfc-editor.org/rfc/rfc7643.html#section-4.1.2 +[10]: https://learn.microsoft.com/en-us/entra/identity/app-provisioning/customize-application-attributes#provisioning-a-role-to-a-scim-app diff --git a/hugo/content/en/agent/logs/auto_multiline_detection.md b/hugo/content/en/agent/logs/auto_multiline_detection.md index 812d3aaae58..0c309ec9a64 100644 --- a/hugo/content/en/agent/logs/auto_multiline_detection.md +++ b/hugo/content/en/agent/logs/auto_multiline_detection.md @@ -12,31 +12,36 @@ algolia: tags: ['advanced log filter'] --- -
This feature is available for Agent version 7.65.0+ and above. For older Agent versions or to explicitly enable the legacy implementation, see Auto Multi-line Detection and Aggregation (Legacy). For Agent versions older than 7.82.0, Auto multi-line Detection is disabled by default.
+
This feature is available for Agent version 7.65.0+ and above. For older Agent versions or to explicitly enable the legacy implementation, see (Legacy) Automatic Multi-line Detection and Aggregation. For Agent versions older than 7.82.0, auto multi-line detection is disabled by default.
## Overview Automatic multi-line detection allows the Agent to detect and aggregate common multi-line logs automatically. -For example, the Agent receives the following lines separately: -``` -2024-08-13 17:15:17 INFO Starting request handler -Exception in thread "main" java.lang.NullPointerException - at com.example.MyClass.doSomething(MyClass.java:42) - at com.example.MyClass.main(MyClass.java:20) -2024-08-13 17:15:18 INFO Request handler stopped -``` -With Auto multi-line detection enabled, the stack trace is aggregated into a single log: + +For example, an application writes the following five lines. Without auto multi-line detection, the Agent sends each line as its own log, splitting the exception away from the message that introduced it: + +```text +2024-08-13 17:15:17 ERROR Request handler failed -> log 1 +Exception in thread "main" java.lang.NullPointerException -> log 2 + at com.example.MyClass.doSomething(MyClass.java:42) -> log 3 + at com.example.MyClass.main(MyClass.java:20) -> log 4 +2024-08-13 17:15:18 INFO Request handler stopped -> log 5 ``` -2024-08-13 17:15:17 INFO Starting request handler -Exception in thread "main" java.lang.NullPointerException - at com.example.MyClass.doSomething(MyClass.java:42) - at com.example.MyClass.main(MyClass.java:20) -2024-08-13 17:15:18 INFO Request handler stopped + +With auto multi-line detection enabled, by default, only lines that begin with a datetime start a new log. The exception and its stack trace are aggregated into the log that precedes them, so the same five lines are sent as two logs: + +```text +2024-08-13 17:15:17 ERROR Request handler failed --+ +Exception in thread "main" java.lang.NullPointerException | + at com.example.MyClass.doSomething(MyClass.java:42) |-> log 1 + at com.example.MyClass.main(MyClass.java:20) --+ + +2024-08-13 17:15:18 INFO Request handler stopped -> log 2 ``` ## Getting started -Auto multi-line detection is enabled by default starting with Agent version `7.82.0`. To disable the Auto multi-line feature in your Agent configuration, set `auto_multi_line_detection` to `false` in your configuration file, or set the `DD_LOGS_CONFIG_AUTO_MULTI_LINE_DETECTION=false` environment variable: +Auto multi-line detection is enabled by default starting with Agent version `7.82.0`. To disable the auto multi-line feature in your Agent configuration, set `auto_multi_line_detection` to `false` in your configuration file, or set the `DD_LOGS_CONFIG_AUTO_MULTI_LINE_DETECTION=false` environment variable: {{< tabs >}} {{% tab "Configuration file" %}} diff --git a/hugo/content/en/api/v2/fleet-automation/examples.json b/hugo/content/en/api/v2/fleet-automation/examples.json index 20a53d0d215..f8b913da597 100644 --- a/hugo/content/en/api/v2/fleet-automation/examples.json +++ b/hugo/content/en/api/v2/fleet-automation/examples.json @@ -717,11 +717,7 @@ "last_restart_at": "integer", "os": "linux", "os_version": "Ubuntu 20.04", - "otel_collector_deployment_types": [], - "otel_collector_distributions": [], - "otel_collector_versions": [], "otel_collectors": [], - "otel_resource_attributes": [], "pod_name": "string", "preferred_ha_active_agent": "string", "python_version": "3.9.5", @@ -842,7 +838,7 @@ "type": "agent" } }, - "html": "
\n
\n
\n
\n

data [required]

\n
\n

object

\n

Detailed information about a specific Datadog Agent.

\n
\n
\n
\n
\n
\n

attributes [required]

\n
\n

object

\n

Attributes for the v2 agent detail response.

\n
\n
\n
\n
\n
\n

agent_infos [required]

\n
\n

object

\n

Detailed information about a Datadog Agent.

\n
\n
\n
\n
\n
\n

active_ha_agent

\n
\n

string

\n

The currently active agent in the high-availability group.

\n
\n \n
\n
\n
\n
\n
\n

agent_version

\n
\n

string

\n

The Datadog Agent version.

\n
\n \n
\n
\n
\n
\n
\n

api_key_name

\n
\n

string

\n

The API key name (if available and not redacted).

\n
\n \n
\n
\n
\n
\n
\n

api_key_uuid

\n
\n

string

\n

The API key UUID.

\n
\n \n
\n
\n
\n
\n
\n

cloud_provider

\n
\n

string

\n

The cloud provider where the agent is running.

\n
\n \n
\n
\n
\n
\n
\n

cluster_name

\n
\n

string

\n

Kubernetes cluster name (if applicable).

\n
\n \n
\n
\n
\n
\n
\n

config_id

\n
\n

string

\n

The configuration identifier applied to the agent.

\n
\n \n
\n
\n
\n
\n
\n

datadog_agent_key

\n
\n

string

\n

The unique agent key identifier.

\n
\n \n
\n
\n
\n
\n
\n

datadog_data_center

\n
\n

string

\n

The Datadog data center the agent reports to.

\n
\n \n
\n
\n
\n
\n
\n

ecs_fargate_cluster_name

\n
\n

string

\n

The ECS Fargate cluster name, if the agent runs in an ECS Fargate environment.

\n
\n \n
\n
\n
\n
\n
\n

ecs_fargate_task_arn

\n
\n

string

\n

The ECS Fargate task ARN, if the agent runs in an ECS Fargate environment.

\n
\n \n
\n
\n
\n
\n
\n

enabled_products

\n
\n

[string]

\n

Datadog products enabled on the agent.

\n
\n \n
\n
\n
\n
\n
\n

env

\n
\n

[string]

\n

Environments the agent is reporting from.

\n
\n \n
\n
\n
\n
\n
\n

first_seen_at

\n
\n

int64

\n

Timestamp when the agent was first seen.

\n
\n \n
\n
\n
\n
\n
\n

ha_agent_hosts

\n
\n

[string]

\n

Hosts participating in the agent's high-availability group.

\n
\n \n
\n
\n
\n
\n
\n

ha_agent_state

\n
\n

string

\n

The high-availability state of the agent.

\n
\n \n
\n
\n
\n
\n
\n

hostname

\n
\n

string

\n

The hostname of the agent.

\n
\n \n
\n
\n
\n
\n
\n

hostname_aliases

\n
\n

[string]

\n

Alternative hostname list for the agent.

\n
\n \n
\n
\n
\n
\n
\n

install_method_installer_version

\n
\n

string

\n

The version of the installer used.

\n
\n \n
\n
\n
\n
\n
\n

install_method_tool

\n
\n

string

\n

The tool used to install the agent.

\n
\n \n
\n
\n
\n
\n
\n

ip_addresses

\n
\n

[string]

\n

IP addresses of the agent.

\n
\n \n
\n
\n
\n
\n
\n

is_single_step_instrumentation_enabled

\n
\n

boolean

\n

Whether single-step instrumentation is enabled.

\n
\n \n
\n
\n
\n
\n
\n

last_restart_at

\n
\n

int64

\n

Timestamp of the last agent restart.

\n
\n \n
\n
\n
\n
\n
\n

os

\n
\n

string

\n

The operating system.

\n
\n \n
\n
\n
\n
\n
\n

os_version

\n
\n

string

\n

The operating system version.

\n
\n \n
\n
\n
\n
\n
\n

otel_collector_deployment_types

\n
\n

[string]

\n

OpenTelemetry collector deployment types associated with the agent.

\n
\n \n
\n
\n
\n
\n
\n

otel_collector_distributions

\n
\n

[string]

\n

OpenTelemetry collector distributions associated with the agent.

\n
\n \n
\n
\n
\n
\n
\n

otel_collector_versions

\n
\n

[string]

\n

List of OpenTelemetry collector versions (if applicable).

\n
\n \n
\n
\n
\n
\n
\n

otel_collectors

\n
\n

[object]

\n

OpenTelemetry collectors associated with the agent (if applicable).

\n
\n \n
\n
\n
\n
\n
\n

otel_resource_attributes

\n
\n

[string]

\n

OpenTelemetry resource attributes reported by the agent.

\n
\n \n
\n
\n
\n
\n
\n

pod_name

\n
\n

string

\n

Kubernetes pod name (if applicable).

\n
\n \n
\n
\n
\n
\n
\n

preferred_ha_active_agent

\n
\n

string

\n

The preferred active agent in the high-availability group.

\n
\n \n
\n
\n
\n
\n
\n

python_version

\n
\n

string

\n

The Python version used by the agent.

\n
\n \n
\n
\n
\n
\n
\n

region

\n
\n

[string]

\n

Regions where the agent is running.

\n
\n \n
\n
\n
\n
\n
\n

remote_agent_management

\n
\n

string

\n

Remote agent management status.

\n
\n \n
\n
\n
\n
\n
\n

remote_config_status

\n
\n

string

\n

Remote configuration status.

\n
\n \n
\n
\n
\n
\n
\n

services

\n
\n

[string]

\n

Services running on the agent.

\n
\n \n
\n
\n
\n
\n
\n

support_agent_upgrade

\n
\n

boolean

\n

Whether the agent supports remote agent upgrade.

\n
\n \n
\n
\n
\n
\n
\n

tags

\n
\n

[string]

\n

Tags associated with the agent.

\n
\n \n
\n
\n
\n
\n
\n

team

\n
\n

string

\n

Team associated with the agent.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

configuration_files

\n
\n

object

\n

Configuration file details, present only when configuration_files is included in the include query parameter.

\n
\n
\n
\n
\n
\n

agent_configuration

\n
\n

object

\n

Configuration information organized by layers.

\n
\n
\n
\n
\n
\n

compiled_configuration

\n
\n

string

\n

The final compiled configuration.

\n
\n \n
\n
\n
\n
\n
\n

env_configuration

\n
\n

string

\n

Configuration from environment variables.

\n
\n \n
\n
\n
\n
\n
\n

file_configuration

\n
\n

string

\n

Configuration from files.

\n
\n \n
\n
\n
\n
\n
\n

remote_configuration

\n
\n

string

\n

Remote configuration settings.

\n
\n \n
\n
\n
\n
\n
\n

runtime_configuration

\n
\n

string

\n

Runtime configuration.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

application_monitoring_configuration

\n
\n

object

\n

Configuration information organized by layers.

\n
\n
\n
\n
\n
\n

compiled_configuration

\n
\n

string

\n

The final compiled configuration.

\n
\n \n
\n
\n
\n
\n
\n

env_configuration

\n
\n

string

\n

Configuration from environment variables.

\n
\n \n
\n
\n
\n
\n
\n

file_configuration

\n
\n

string

\n

Configuration from files.

\n
\n \n
\n
\n
\n
\n
\n

remote_configuration

\n
\n

string

\n

Remote configuration settings.

\n
\n \n
\n
\n
\n
\n
\n

runtime_configuration

\n
\n

string

\n

Runtime configuration.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

otel_collectors_configuration

\n
\n

[object]

\n

Configuration for OpenTelemetry collectors associated with the agent. Present only when the agent has associated OpenTelemetry collectors.

\n
\n
\n
\n
\n
\n

collector_id

\n
\n

string

\n

The unique identifier of the OpenTelemetry collector.

\n
\n \n
\n
\n
\n
\n
\n

compiled_configuration

\n
\n

string

\n

The final compiled configuration of the OpenTelemetry collector.

\n
\n \n
\n
\n
\n
\n
\n

distribution

\n
\n

string

\n

The distribution of the OpenTelemetry collector.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

security_agent_configuration

\n
\n

object

\n

Configuration information organized by layers.

\n
\n
\n
\n
\n
\n

compiled_configuration

\n
\n

string

\n

The final compiled configuration.

\n
\n \n
\n
\n
\n
\n
\n

env_configuration

\n
\n

string

\n

Configuration from environment variables.

\n
\n \n
\n
\n
\n
\n
\n

file_configuration

\n
\n

string

\n

Configuration from files.

\n
\n \n
\n
\n
\n
\n
\n

remote_configuration

\n
\n

string

\n

Remote configuration settings.

\n
\n \n
\n
\n
\n
\n
\n

runtime_configuration

\n
\n

string

\n

Runtime configuration.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

system_probe_configuration

\n
\n

object

\n

Configuration information organized by layers.

\n
\n
\n
\n
\n
\n

compiled_configuration

\n
\n

string

\n

The final compiled configuration.

\n
\n \n
\n
\n
\n
\n
\n

env_configuration

\n
\n

string

\n

Configuration from environment variables.

\n
\n \n
\n
\n
\n
\n
\n

file_configuration

\n
\n

string

\n

Configuration from files.

\n
\n \n
\n
\n
\n
\n
\n

remote_configuration

\n
\n

string

\n

Remote configuration settings.

\n
\n \n
\n
\n
\n
\n
\n

runtime_configuration

\n
\n

string

\n

Runtime configuration.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n
\n
\n

integrations

\n
\n

object

\n

Integration details, present only when integrations is included in the include query parameter.

\n
\n
\n
\n
\n
\n

configuration_files

\n
\n

[object]

\n

Configuration files for integrations.

\n
\n
\n
\n
\n
\n

agent_hash

\n
\n

string

\n

Hash of the configuration file as seen by the agent.

\n
\n \n
\n
\n
\n
\n
\n

file_content

\n
\n

string

\n

The raw content of the configuration file.

\n
\n \n
\n
\n
\n
\n
\n

file_path

\n
\n

string

\n

Path to the configuration file.

\n
\n \n
\n
\n
\n
\n
\n

filename

\n
\n

string

\n

Name of the configuration file.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

error_integrations

\n
\n

[object]

\n

Integrations with errors.

\n
\n
\n
\n
\n
\n

data_type

\n
\n

string

\n

Type of data collected, such as metrics or logs.

\n
\n \n
\n
\n
\n
\n
\n

error_messages

\n
\n

[string]

\n

Error messages if the integration has issues.

\n
\n \n
\n
\n
\n
\n
\n

init_config

\n
\n

string

\n

Initialization configuration (YAML format).

\n
\n \n
\n
\n
\n
\n
\n

instance_config

\n
\n

string

\n

Instance-specific configuration (YAML format).

\n
\n \n
\n
\n
\n
\n
\n

is_custom_check

\n
\n

boolean

\n

Whether this is a custom integration.

\n
\n \n
\n
\n
\n
\n
\n

is_default

\n
\n

boolean

\n

Whether this is a default integration instance.

\n
\n \n
\n
\n
\n
\n
\n

is_init

\n
\n

boolean

\n

Whether this integration configuration is an init config.

\n
\n \n
\n
\n
\n
\n
\n

log_config

\n
\n

string

\n

Log collection configuration (YAML format).

\n
\n \n
\n
\n
\n
\n
\n

name

\n
\n

string

\n

Name of the integration instance.

\n
\n \n
\n
\n
\n
\n
\n

pod_count

\n
\n

int64

\n

Number of pods running this integration. Absent from the response when the count is zero.

\n
\n \n
\n
\n
\n
\n
\n

source_index

\n
\n

int64

\n

Index in the configuration file.

\n
\n \n
\n
\n
\n
\n
\n

source_path

\n
\n

string

\n

Path to the configuration file.

\n
\n \n
\n
\n
\n
\n
\n

type

\n
\n

string

\n

Integration type.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

missing_integrations

\n
\n

[object]

\n

Detected but not configured integrations.

\n
\n
\n
\n
\n
\n

escaped_name

\n
\n

string

\n

Escaped integration name.

\n
\n \n
\n
\n
\n
\n
\n

prefix

\n
\n

string

\n

Integration prefix identifier.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

warning_integrations

\n
\n

[object]

\n

Integrations with warnings.

\n
\n
\n
\n
\n
\n

data_type

\n
\n

string

\n

Type of data collected, such as metrics or logs.

\n
\n \n
\n
\n
\n
\n
\n

error_messages

\n
\n

[string]

\n

Error messages if the integration has issues.

\n
\n \n
\n
\n
\n
\n
\n

init_config

\n
\n

string

\n

Initialization configuration (YAML format).

\n
\n \n
\n
\n
\n
\n
\n

instance_config

\n
\n

string

\n

Instance-specific configuration (YAML format).

\n
\n \n
\n
\n
\n
\n
\n

is_custom_check

\n
\n

boolean

\n

Whether this is a custom integration.

\n
\n \n
\n
\n
\n
\n
\n

is_default

\n
\n

boolean

\n

Whether this is a default integration instance.

\n
\n \n
\n
\n
\n
\n
\n

is_init

\n
\n

boolean

\n

Whether this integration configuration is an init config.

\n
\n \n
\n
\n
\n
\n
\n

log_config

\n
\n

string

\n

Log collection configuration (YAML format).

\n
\n \n
\n
\n
\n
\n
\n

name

\n
\n

string

\n

Name of the integration instance.

\n
\n \n
\n
\n
\n
\n
\n

pod_count

\n
\n

int64

\n

Number of pods running this integration. Absent from the response when the count is zero.

\n
\n \n
\n
\n
\n
\n
\n

source_index

\n
\n

int64

\n

Index in the configuration file.

\n
\n \n
\n
\n
\n
\n
\n

source_path

\n
\n

string

\n

Path to the configuration file.

\n
\n \n
\n
\n
\n
\n
\n

type

\n
\n

string

\n

Integration type.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

working_integrations

\n
\n

[object]

\n

Integrations that are working correctly.

\n
\n
\n
\n
\n
\n

data_type

\n
\n

string

\n

Type of data collected, such as metrics or logs.

\n
\n \n
\n
\n
\n
\n
\n

error_messages

\n
\n

[string]

\n

Error messages if the integration has issues.

\n
\n \n
\n
\n
\n
\n
\n

init_config

\n
\n

string

\n

Initialization configuration (YAML format).

\n
\n \n
\n
\n
\n
\n
\n

instance_config

\n
\n

string

\n

Instance-specific configuration (YAML format).

\n
\n \n
\n
\n
\n
\n
\n

is_custom_check

\n
\n

boolean

\n

Whether this is a custom integration.

\n
\n \n
\n
\n
\n
\n
\n

is_default

\n
\n

boolean

\n

Whether this is a default integration instance.

\n
\n \n
\n
\n
\n
\n
\n

is_init

\n
\n

boolean

\n

Whether this integration configuration is an init config.

\n
\n \n
\n
\n
\n
\n
\n

log_config

\n
\n

string

\n

Log collection configuration (YAML format).

\n
\n \n
\n
\n
\n
\n
\n

name

\n
\n

string

\n

Name of the integration instance.

\n
\n \n
\n
\n
\n
\n
\n

pod_count

\n
\n

int64

\n

Number of pods running this integration. Absent from the response when the count is zero.

\n
\n \n
\n
\n
\n
\n
\n

source_index

\n
\n

int64

\n

Index in the configuration file.

\n
\n \n
\n
\n
\n
\n
\n

source_path

\n
\n

string

\n

Path to the configuration file.

\n
\n \n
\n
\n
\n
\n
\n

type

\n
\n

string

\n

Integration type.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n

id [required]

\n
\n

string

\n

The unique agent key identifier.

\n
\n \n
\n
\n
\n
\n
\n

type [required]

\n
\n

enum

\n

The type of the agent resource. \nAllowed enum values: agent

default: agent

\n
\n \n
\n
\n
\n
" + "html": "
\n
\n
\n
\n

data [required]

\n
\n

object

\n

Detailed information about a specific Datadog Agent.

\n
\n
\n
\n
\n
\n

attributes [required]

\n
\n

object

\n

Attributes for the v2 agent detail response.

\n
\n
\n
\n
\n
\n

agent_infos [required]

\n
\n

object

\n

Detailed information about a Datadog Agent.

\n
\n
\n
\n
\n
\n

active_ha_agent

\n
\n

string

\n

The currently active agent in the high-availability group.

\n
\n \n
\n
\n
\n
\n
\n

agent_version

\n
\n

string

\n

The Datadog Agent version.

\n
\n \n
\n
\n
\n
\n
\n

api_key_name

\n
\n

string

\n

The API key name (if available and not redacted).

\n
\n \n
\n
\n
\n
\n
\n

api_key_uuid

\n
\n

string

\n

The API key UUID.

\n
\n \n
\n
\n
\n
\n
\n

cloud_provider

\n
\n

string

\n

The cloud provider where the agent is running.

\n
\n \n
\n
\n
\n
\n
\n

cluster_name

\n
\n

string

\n

Kubernetes cluster name (if applicable).

\n
\n \n
\n
\n
\n
\n
\n

config_id

\n
\n

string

\n

The configuration identifier applied to the agent.

\n
\n \n
\n
\n
\n
\n
\n

datadog_agent_key

\n
\n

string

\n

The unique agent key identifier.

\n
\n \n
\n
\n
\n
\n
\n

datadog_data_center

\n
\n

string

\n

The Datadog data center the agent reports to.

\n
\n \n
\n
\n
\n
\n
\n

ecs_fargate_cluster_name

\n
\n

string

\n

The ECS Fargate cluster name, if the agent runs in an ECS Fargate environment.

\n
\n \n
\n
\n
\n
\n
\n

ecs_fargate_task_arn

\n
\n

string

\n

The ECS Fargate task ARN, if the agent runs in an ECS Fargate environment.

\n
\n \n
\n
\n
\n
\n
\n

enabled_products

\n
\n

[string]

\n

Datadog products enabled on the agent.

\n
\n \n
\n
\n
\n
\n
\n

env

\n
\n

[string]

\n

Environments the agent is reporting from.

\n
\n \n
\n
\n
\n
\n
\n

first_seen_at

\n
\n

int64

\n

Timestamp when the agent was first seen.

\n
\n \n
\n
\n
\n
\n
\n

ha_agent_hosts

\n
\n

[string]

\n

Hosts participating in the agent's high-availability group.

\n
\n \n
\n
\n
\n
\n
\n

ha_agent_state

\n
\n

string

\n

The high-availability state of the agent.

\n
\n \n
\n
\n
\n
\n
\n

hostname

\n
\n

string

\n

The hostname of the agent.

\n
\n \n
\n
\n
\n
\n
\n

hostname_aliases

\n
\n

[string]

\n

Alternative hostname list for the agent.

\n
\n \n
\n
\n
\n
\n
\n

install_method_installer_version

\n
\n

string

\n

The version of the installer used.

\n
\n \n
\n
\n
\n
\n
\n

install_method_tool

\n
\n

string

\n

The tool used to install the agent.

\n
\n \n
\n
\n
\n
\n
\n

ip_addresses

\n
\n

[string]

\n

IP addresses of the agent.

\n
\n \n
\n
\n
\n
\n
\n

is_single_step_instrumentation_enabled

\n
\n

boolean

\n

Whether single-step instrumentation is enabled.

\n
\n \n
\n
\n
\n
\n
\n

last_restart_at

\n
\n

int64

\n

Timestamp of the last agent restart.

\n
\n \n
\n
\n
\n
\n
\n

os

\n
\n

string

\n

The operating system.

\n
\n \n
\n
\n
\n
\n
\n

os_version

\n
\n

string

\n

The operating system version.

\n
\n \n
\n
\n
\n
\n
\n

otel_collectors

\n
\n

[object]

\n

OpenTelemetry collectors associated with the agent (if applicable).

\n
\n \n
\n
\n
\n
\n
\n

pod_name

\n
\n

string

\n

Kubernetes pod name (if applicable).

\n
\n \n
\n
\n
\n
\n
\n

preferred_ha_active_agent

\n
\n

string

\n

The preferred active agent in the high-availability group.

\n
\n \n
\n
\n
\n
\n
\n

python_version

\n
\n

string

\n

The Python version used by the agent.

\n
\n \n
\n
\n
\n
\n
\n

region

\n
\n

[string]

\n

Regions where the agent is running.

\n
\n \n
\n
\n
\n
\n
\n

remote_agent_management

\n
\n

string

\n

Remote agent management status.

\n
\n \n
\n
\n
\n
\n
\n

remote_config_status

\n
\n

string

\n

Remote configuration status.

\n
\n \n
\n
\n
\n
\n
\n

services

\n
\n

[string]

\n

Services running on the agent.

\n
\n \n
\n
\n
\n
\n
\n

support_agent_upgrade

\n
\n

boolean

\n

Whether the agent supports remote agent upgrade.

\n
\n \n
\n
\n
\n
\n
\n

tags

\n
\n

[string]

\n

Tags associated with the agent.

\n
\n \n
\n
\n
\n
\n
\n

team

\n
\n

string

\n

Team associated with the agent.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

configuration_files

\n
\n

object

\n

Configuration file details, present only when configuration_files is included in the include query parameter.

\n
\n
\n
\n
\n
\n

agent_configuration

\n
\n

object

\n

Configuration information organized by layers.

\n
\n
\n
\n
\n
\n

compiled_configuration

\n
\n

string

\n

The final compiled configuration.

\n
\n \n
\n
\n
\n
\n
\n

env_configuration

\n
\n

string

\n

Configuration from environment variables.

\n
\n \n
\n
\n
\n
\n
\n

file_configuration

\n
\n

string

\n

Configuration from files.

\n
\n \n
\n
\n
\n
\n
\n

remote_configuration

\n
\n

string

\n

Remote configuration settings.

\n
\n \n
\n
\n
\n
\n
\n

runtime_configuration

\n
\n

string

\n

Runtime configuration.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

application_monitoring_configuration

\n
\n

object

\n

Configuration information organized by layers.

\n
\n
\n
\n
\n
\n

compiled_configuration

\n
\n

string

\n

The final compiled configuration.

\n
\n \n
\n
\n
\n
\n
\n

env_configuration

\n
\n

string

\n

Configuration from environment variables.

\n
\n \n
\n
\n
\n
\n
\n

file_configuration

\n
\n

string

\n

Configuration from files.

\n
\n \n
\n
\n
\n
\n
\n

remote_configuration

\n
\n

string

\n

Remote configuration settings.

\n
\n \n
\n
\n
\n
\n
\n

runtime_configuration

\n
\n

string

\n

Runtime configuration.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

otel_collectors_configuration

\n
\n

[object]

\n

Configuration for OpenTelemetry collectors associated with the agent. Present only when the agent has associated OpenTelemetry collectors.

\n
\n
\n
\n
\n
\n

collector_id

\n
\n

string

\n

The unique identifier of the OpenTelemetry collector.

\n
\n \n
\n
\n
\n
\n
\n

compiled_configuration

\n
\n

string

\n

The final compiled configuration of the OpenTelemetry collector.

\n
\n \n
\n
\n
\n
\n
\n

distribution

\n
\n

string

\n

The distribution of the OpenTelemetry collector.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

security_agent_configuration

\n
\n

object

\n

Configuration information organized by layers.

\n
\n
\n
\n
\n
\n

compiled_configuration

\n
\n

string

\n

The final compiled configuration.

\n
\n \n
\n
\n
\n
\n
\n

env_configuration

\n
\n

string

\n

Configuration from environment variables.

\n
\n \n
\n
\n
\n
\n
\n

file_configuration

\n
\n

string

\n

Configuration from files.

\n
\n \n
\n
\n
\n
\n
\n

remote_configuration

\n
\n

string

\n

Remote configuration settings.

\n
\n \n
\n
\n
\n
\n
\n

runtime_configuration

\n
\n

string

\n

Runtime configuration.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

system_probe_configuration

\n
\n

object

\n

Configuration information organized by layers.

\n
\n
\n
\n
\n
\n

compiled_configuration

\n
\n

string

\n

The final compiled configuration.

\n
\n \n
\n
\n
\n
\n
\n

env_configuration

\n
\n

string

\n

Configuration from environment variables.

\n
\n \n
\n
\n
\n
\n
\n

file_configuration

\n
\n

string

\n

Configuration from files.

\n
\n \n
\n
\n
\n
\n
\n

remote_configuration

\n
\n

string

\n

Remote configuration settings.

\n
\n \n
\n
\n
\n
\n
\n

runtime_configuration

\n
\n

string

\n

Runtime configuration.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n
\n
\n

integrations

\n
\n

object

\n

Integration details, present only when integrations is included in the include query parameter.

\n
\n
\n
\n
\n
\n

configuration_files

\n
\n

[object]

\n

Configuration files for integrations.

\n
\n
\n
\n
\n
\n

agent_hash

\n
\n

string

\n

Hash of the configuration file as seen by the agent.

\n
\n \n
\n
\n
\n
\n
\n

file_content

\n
\n

string

\n

The raw content of the configuration file.

\n
\n \n
\n
\n
\n
\n
\n

file_path

\n
\n

string

\n

Path to the configuration file.

\n
\n \n
\n
\n
\n
\n
\n

filename

\n
\n

string

\n

Name of the configuration file.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

error_integrations

\n
\n

[object]

\n

Integrations with errors.

\n
\n
\n
\n
\n
\n

data_type

\n
\n

string

\n

Type of data collected, such as metrics or logs.

\n
\n \n
\n
\n
\n
\n
\n

error_messages

\n
\n

[string]

\n

Error messages if the integration has issues.

\n
\n \n
\n
\n
\n
\n
\n

init_config

\n
\n

string

\n

Initialization configuration (YAML format).

\n
\n \n
\n
\n
\n
\n
\n

instance_config

\n
\n

string

\n

Instance-specific configuration (YAML format).

\n
\n \n
\n
\n
\n
\n
\n

is_custom_check

\n
\n

boolean

\n

Whether this is a custom integration.

\n
\n \n
\n
\n
\n
\n
\n

is_default

\n
\n

boolean

\n

Whether this is a default integration instance.

\n
\n \n
\n
\n
\n
\n
\n

is_init

\n
\n

boolean

\n

Whether this integration configuration is an init config.

\n
\n \n
\n
\n
\n
\n
\n

log_config

\n
\n

string

\n

Log collection configuration (YAML format).

\n
\n \n
\n
\n
\n
\n
\n

name

\n
\n

string

\n

Name of the integration instance.

\n
\n \n
\n
\n
\n
\n
\n

pod_count

\n
\n

int64

\n

Number of pods running this integration. Absent from the response when the count is zero.

\n
\n \n
\n
\n
\n
\n
\n

source_index

\n
\n

int64

\n

Index in the configuration file.

\n
\n \n
\n
\n
\n
\n
\n

source_path

\n
\n

string

\n

Path to the configuration file.

\n
\n \n
\n
\n
\n
\n
\n

type

\n
\n

string

\n

Integration type.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

missing_integrations

\n
\n

[object]

\n

Detected but not configured integrations.

\n
\n
\n
\n
\n
\n

escaped_name

\n
\n

string

\n

Escaped integration name.

\n
\n \n
\n
\n
\n
\n
\n

prefix

\n
\n

string

\n

Integration prefix identifier.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

warning_integrations

\n
\n

[object]

\n

Integrations with warnings.

\n
\n
\n
\n
\n
\n

data_type

\n
\n

string

\n

Type of data collected, such as metrics or logs.

\n
\n \n
\n
\n
\n
\n
\n

error_messages

\n
\n

[string]

\n

Error messages if the integration has issues.

\n
\n \n
\n
\n
\n
\n
\n

init_config

\n
\n

string

\n

Initialization configuration (YAML format).

\n
\n \n
\n
\n
\n
\n
\n

instance_config

\n
\n

string

\n

Instance-specific configuration (YAML format).

\n
\n \n
\n
\n
\n
\n
\n

is_custom_check

\n
\n

boolean

\n

Whether this is a custom integration.

\n
\n \n
\n
\n
\n
\n
\n

is_default

\n
\n

boolean

\n

Whether this is a default integration instance.

\n
\n \n
\n
\n
\n
\n
\n

is_init

\n
\n

boolean

\n

Whether this integration configuration is an init config.

\n
\n \n
\n
\n
\n
\n
\n

log_config

\n
\n

string

\n

Log collection configuration (YAML format).

\n
\n \n
\n
\n
\n
\n
\n

name

\n
\n

string

\n

Name of the integration instance.

\n
\n \n
\n
\n
\n
\n
\n

pod_count

\n
\n

int64

\n

Number of pods running this integration. Absent from the response when the count is zero.

\n
\n \n
\n
\n
\n
\n
\n

source_index

\n
\n

int64

\n

Index in the configuration file.

\n
\n \n
\n
\n
\n
\n
\n

source_path

\n
\n

string

\n

Path to the configuration file.

\n
\n \n
\n
\n
\n
\n
\n

type

\n
\n

string

\n

Integration type.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

working_integrations

\n
\n

[object]

\n

Integrations that are working correctly.

\n
\n
\n
\n
\n
\n

data_type

\n
\n

string

\n

Type of data collected, such as metrics or logs.

\n
\n \n
\n
\n
\n
\n
\n

error_messages

\n
\n

[string]

\n

Error messages if the integration has issues.

\n
\n \n
\n
\n
\n
\n
\n

init_config

\n
\n

string

\n

Initialization configuration (YAML format).

\n
\n \n
\n
\n
\n
\n
\n

instance_config

\n
\n

string

\n

Instance-specific configuration (YAML format).

\n
\n \n
\n
\n
\n
\n
\n

is_custom_check

\n
\n

boolean

\n

Whether this is a custom integration.

\n
\n \n
\n
\n
\n
\n
\n

is_default

\n
\n

boolean

\n

Whether this is a default integration instance.

\n
\n \n
\n
\n
\n
\n
\n

is_init

\n
\n

boolean

\n

Whether this integration configuration is an init config.

\n
\n \n
\n
\n
\n
\n
\n

log_config

\n
\n

string

\n

Log collection configuration (YAML format).

\n
\n \n
\n
\n
\n
\n
\n

name

\n
\n

string

\n

Name of the integration instance.

\n
\n \n
\n
\n
\n
\n
\n

pod_count

\n
\n

int64

\n

Number of pods running this integration. Absent from the response when the count is zero.

\n
\n \n
\n
\n
\n
\n
\n

source_index

\n
\n

int64

\n

Index in the configuration file.

\n
\n \n
\n
\n
\n
\n
\n

source_path

\n
\n

string

\n

Path to the configuration file.

\n
\n \n
\n
\n
\n
\n
\n

type

\n
\n

string

\n

Integration type.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n

id [required]

\n
\n

string

\n

The unique agent key identifier.

\n
\n \n
\n
\n
\n
\n
\n

type [required]

\n
\n

enum

\n

The type of the agent resource. \nAllowed enum values: agent

default: agent

\n
\n \n
\n
\n
\n
" }, "400": { "json": { diff --git a/hugo/content/en/api/v2/governance-console/examples.json b/hugo/content/en/api/v2/governance-console/examples.json index da2e44d7ea6..35c352517a3 100644 --- a/hugo/content/en/api/v2/governance-console/examples.json +++ b/hugo/content/en/api/v2/governance-console/examples.json @@ -97,7 +97,6 @@ "created_at": "2024-01-15T09:30:00Z", "created_by": "11111111-2222-3333-4444-555555555555", "description": "Identifies API keys that have not been used within your specified time threshold, helping reduce security risks from dormant credentials.", - "detection_frequency": "daily", "detection_parameters": {}, "insights": [ [] @@ -165,7 +164,7 @@ } ] }, - "html": "
\n
\n
\n
\n

data [required]

\n
\n

[object]

\n

An array of governance control resources.

\n
\n
\n
\n
\n
\n

attributes [required]

\n
\n

object

\n

The attributes of a governance control.

\n
\n
\n
\n
\n
\n

active_detections_count [required]

\n
\n

int64

\n

The number of active detections for the control.

\n
\n \n
\n
\n
\n
\n
\n

category [required]

\n
\n

string

\n

The value driver the control is grouped under, such as security or cost.

\n
\n \n
\n
\n
\n
\n
\n

created_at [required]

\n
\n

date-time

\n

The time the control configuration was created.

\n
\n \n
\n
\n
\n
\n
\n

created_by [required]

\n
\n

string

\n

The UUID of the user who created the control configuration.

\n
\n \n
\n
\n
\n
\n
\n

description [required]

\n
\n

string

\n

A human-readable description of what the control detects.

\n
\n \n
\n
\n
\n
\n
\n

detection_frequency [required]

\n
\n

string

\n

How often detections are evaluated for the control.

\n
\n \n
\n
\n
\n
\n
\n

detection_parameters [required]

\n
\n

object

\n

A free-form map of parameter names to their configured values.

\n
\n \n
\n
\n
\n
\n
\n

insights [required]

\n
\n

[string]

\n

The insight slugs associated with the control.

\n
\n \n
\n
\n
\n
\n
\n

last_detection_at [required]

\n
\n

date-time

\n

The time of the most recent detection for the control. null when there are no detections.

\n
\n \n
\n
\n
\n
\n
\n

mitigated_detections_count [required]

\n
\n

int64

\n

The number of mitigated detections for the control.

\n
\n \n
\n
\n
\n
\n
\n

mitigation_parameters [required]

\n
\n

object

\n

A free-form map of parameter names to their configured values.

\n
\n \n
\n
\n
\n
\n
\n

mitigation_type [required]

\n
\n

string

\n

The configured mitigation type for the control. Empty when not configured.

\n
\n \n
\n
\n
\n
\n
\n

mitigations [required]

\n
\n

[object]

\n

The mitigations available for a control.

\n
\n
\n
\n
\n
\n

description [required]

\n
\n

string

\n

A human-readable description of the mitigation.

\n
\n \n
\n
\n
\n
\n
\n

execution_modes [required]

\n
\n

[string]

\n

The execution modes the mitigation supports, such as manual or automatic.

\n
\n \n
\n
\n
\n
\n
\n

id [required]

\n
\n

string

\n

The unique identifier of the mitigation.

\n
\n \n
\n
\n
\n
\n
\n

permissions [required]

\n
\n

[string]

\n

The permissions required to apply the mitigation.

\n
\n \n
\n
\n
\n
\n
\n

supported_parameters [required]

\n
\n

[object]

\n

An array of parameter definitions.

\n
\n
\n
\n
\n
\n

default_value [required]

\n
\n

\n

The default value of the parameter. The JSON type depends on the parameter's type.

\n
\n \n
\n
\n
\n
\n
\n

description [required]

\n
\n

string

\n

A human-readable description of the parameter.

\n
\n \n
\n
\n
\n
\n
\n

display_name [required]

\n
\n

string

\n

The human-readable name of the parameter.

\n
\n \n
\n
\n
\n
\n
\n

name [required]

\n
\n

string

\n

The machine-readable name of the parameter.

\n
\n \n
\n
\n
\n
\n
\n

required [required]

\n
\n

boolean

\n

Whether the parameter must be provided.

\n
\n \n
\n
\n
\n
\n
\n

supported_values [required]

\n
\n

[object]

\n

The supported values for an enumerated parameter.

\n
\n
\n
\n
\n
\n

label [required]

\n
\n

string

\n

The human-readable label for the value.

\n
\n \n
\n
\n
\n
\n
\n

value [required]

\n
\n

string

\n

The machine-readable value.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

type [required]

\n
\n

string

\n

The type of the parameter, such as integer, string, boolean, enum, or pattern_list.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

title [required]

\n
\n

string

\n

A short, human-readable name for the mitigation.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

name [required]

\n
\n

string

\n

Human-readable name of the control.

\n
\n \n
\n
\n
\n
\n
\n

priority [required]

\n
\n

string

\n

The priority of the control, such as High.

\n
\n \n
\n
\n
\n
\n
\n

product [required]

\n
\n

string

\n

The product the control belongs to.

\n
\n \n
\n
\n
\n
\n
\n

resource_type [required]

\n
\n

string

\n

The type of resource the control evaluates.

\n
\n \n
\n
\n
\n
\n
\n

resource_type_display_name [required]

\n
\n

string

\n

The human-readable name of the resource type.

\n
\n \n
\n
\n
\n
\n
\n

supported_detection_parameters [required]

\n
\n

[object]

\n

An array of parameter definitions.

\n
\n
\n
\n
\n
\n

default_value [required]

\n
\n

\n

The default value of the parameter. The JSON type depends on the parameter's type.

\n
\n \n
\n
\n
\n
\n
\n

description [required]

\n
\n

string

\n

A human-readable description of the parameter.

\n
\n \n
\n
\n
\n
\n
\n

display_name [required]

\n
\n

string

\n

The human-readable name of the parameter.

\n
\n \n
\n
\n
\n
\n
\n

name [required]

\n
\n

string

\n

The machine-readable name of the parameter.

\n
\n \n
\n
\n
\n
\n
\n

required [required]

\n
\n

boolean

\n

Whether the parameter must be provided.

\n
\n \n
\n
\n
\n
\n
\n

supported_values [required]

\n
\n

[object]

\n

The supported values for an enumerated parameter.

\n
\n
\n
\n
\n
\n

label [required]

\n
\n

string

\n

The human-readable label for the value.

\n
\n \n
\n
\n
\n
\n
\n

value [required]

\n
\n

string

\n

The machine-readable value.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

type [required]

\n
\n

string

\n

The type of the parameter, such as integer, string, boolean, enum, or pattern_list.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

type [required]

\n
\n

string

\n

The control type, such as Proactive or Detection.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

id [required]

\n
\n

string

\n

The detection type that uniquely identifies the control.

\n
\n \n
\n
\n
\n
\n
\n

type [required]

\n
\n

enum

\n

JSON:API resource type for a governance control. \nAllowed enum values: governance_control

\n
\n \n
\n
\n
\n
" + "html": "
\n
\n
\n
\n

data [required]

\n
\n

[object]

\n

An array of governance control resources.

\n
\n
\n
\n
\n
\n

attributes [required]

\n
\n

object

\n

The attributes of a governance control.

\n
\n
\n
\n
\n
\n

active_detections_count [required]

\n
\n

int64

\n

The number of active detections for the control.

\n
\n \n
\n
\n
\n
\n
\n

category [required]

\n
\n

string

\n

The value driver the control is grouped under, such as security or cost.

\n
\n \n
\n
\n
\n
\n
\n

created_at [required]

\n
\n

date-time

\n

The time the control configuration was created.

\n
\n \n
\n
\n
\n
\n
\n

created_by [required]

\n
\n

string

\n

The UUID of the user who created the control configuration.

\n
\n \n
\n
\n
\n
\n
\n

description [required]

\n
\n

string

\n

A human-readable description of what the control detects.

\n
\n \n
\n
\n
\n
\n
\n

detection_parameters [required]

\n
\n

object

\n

A free-form map of parameter names to their configured values.

\n
\n \n
\n
\n
\n
\n
\n

insights [required]

\n
\n

[string]

\n

The insight slugs associated with the control.

\n
\n \n
\n
\n
\n
\n
\n

last_detection_at [required]

\n
\n

date-time

\n

The time of the most recent detection for the control. null when there are no detections.

\n
\n \n
\n
\n
\n
\n
\n

mitigated_detections_count [required]

\n
\n

int64

\n

The number of mitigated detections for the control.

\n
\n \n
\n
\n
\n
\n
\n

mitigation_parameters [required]

\n
\n

object

\n

A free-form map of parameter names to their configured values.

\n
\n \n
\n
\n
\n
\n
\n

mitigation_type [required]

\n
\n

string

\n

The configured mitigation type for the control. Empty when not configured.

\n
\n \n
\n
\n
\n
\n
\n

mitigations [required]

\n
\n

[object]

\n

The mitigations available for a control.

\n
\n
\n
\n
\n
\n

description [required]

\n
\n

string

\n

A human-readable description of the mitigation.

\n
\n \n
\n
\n
\n
\n
\n

execution_modes [required]

\n
\n

[string]

\n

The execution modes the mitigation supports, such as manual or automatic.

\n
\n \n
\n
\n
\n
\n
\n

id [required]

\n
\n

string

\n

The unique identifier of the mitigation.

\n
\n \n
\n
\n
\n
\n
\n

permissions [required]

\n
\n

[string]

\n

The permissions required to apply the mitigation.

\n
\n \n
\n
\n
\n
\n
\n

supported_parameters [required]

\n
\n

[object]

\n

An array of parameter definitions.

\n
\n
\n
\n
\n
\n

default_value [required]

\n
\n

\n

The default value of the parameter. The JSON type depends on the parameter's type.

\n
\n \n
\n
\n
\n
\n
\n

description [required]

\n
\n

string

\n

A human-readable description of the parameter.

\n
\n \n
\n
\n
\n
\n
\n

display_name [required]

\n
\n

string

\n

The human-readable name of the parameter.

\n
\n \n
\n
\n
\n
\n
\n

name [required]

\n
\n

string

\n

The machine-readable name of the parameter.

\n
\n \n
\n
\n
\n
\n
\n

required [required]

\n
\n

boolean

\n

Whether the parameter must be provided.

\n
\n \n
\n
\n
\n
\n
\n

supported_values [required]

\n
\n

[object]

\n

The supported values for an enumerated parameter. null when the parameter is not an enumerated type.

\n
\n
\n
\n
\n
\n

label [required]

\n
\n

string

\n

The human-readable label for the value.

\n
\n \n
\n
\n
\n
\n
\n

value [required]

\n
\n

string

\n

The machine-readable value.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

type [required]

\n
\n

string

\n

The type of the parameter, such as integer, string, boolean, enum, or pattern_list.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

title [required]

\n
\n

string

\n

A short, human-readable name for the mitigation.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

name [required]

\n
\n

string

\n

Human-readable name of the control.

\n
\n \n
\n
\n
\n
\n
\n

priority [required]

\n
\n

string

\n

The priority of the control, such as High.

\n
\n \n
\n
\n
\n
\n
\n

product [required]

\n
\n

string

\n

The product the control belongs to.

\n
\n \n
\n
\n
\n
\n
\n

resource_type [required]

\n
\n

string

\n

The type of resource the control evaluates.

\n
\n \n
\n
\n
\n
\n
\n

resource_type_display_name [required]

\n
\n

string

\n

The human-readable name of the resource type.

\n
\n \n
\n
\n
\n
\n
\n

supported_detection_parameters [required]

\n
\n

[object]

\n

An array of parameter definitions.

\n
\n
\n
\n
\n
\n

default_value [required]

\n
\n

\n

The default value of the parameter. The JSON type depends on the parameter's type.

\n
\n \n
\n
\n
\n
\n
\n

description [required]

\n
\n

string

\n

A human-readable description of the parameter.

\n
\n \n
\n
\n
\n
\n
\n

display_name [required]

\n
\n

string

\n

The human-readable name of the parameter.

\n
\n \n
\n
\n
\n
\n
\n

name [required]

\n
\n

string

\n

The machine-readable name of the parameter.

\n
\n \n
\n
\n
\n
\n
\n

required [required]

\n
\n

boolean

\n

Whether the parameter must be provided.

\n
\n \n
\n
\n
\n
\n
\n

supported_values [required]

\n
\n

[object]

\n

The supported values for an enumerated parameter. null when the parameter is not an enumerated type.

\n
\n
\n
\n
\n
\n

label [required]

\n
\n

string

\n

The human-readable label for the value.

\n
\n \n
\n
\n
\n
\n
\n

value [required]

\n
\n

string

\n

The machine-readable value.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

type [required]

\n
\n

string

\n

The type of the parameter, such as integer, string, boolean, enum, or pattern_list.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

type [required]

\n
\n

string

\n

The control type, such as Proactive or Detection.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

id [required]

\n
\n

string

\n

The detection type that uniquely identifies the control.

\n
\n \n
\n
\n
\n
\n
\n

type [required]

\n
\n

enum

\n

JSON:API resource type for a governance control. \nAllowed enum values: governance_control

\n
\n \n
\n
\n
\n
" }, "400": { "json": { @@ -247,7 +246,6 @@ "created_at": "2024-01-15T09:30:00Z", "created_by": "11111111-2222-3333-4444-555555555555", "description": "Identifies API keys that have not been used within your specified time threshold, helping reduce security risks from dormant credentials.", - "detection_frequency": "daily", "detection_parameters": {}, "insights": [ [] @@ -314,7 +312,7 @@ "type": "governance_control" } }, - "html": "
\n
\n
\n
\n

data [required]

\n
\n

object

\n

A governance control resource.

\n
\n
\n
\n
\n
\n

attributes [required]

\n
\n

object

\n

The attributes of a governance control.

\n
\n
\n
\n
\n
\n

active_detections_count [required]

\n
\n

int64

\n

The number of active detections for the control.

\n
\n \n
\n
\n
\n
\n
\n

category [required]

\n
\n

string

\n

The value driver the control is grouped under, such as security or cost.

\n
\n \n
\n
\n
\n
\n
\n

created_at [required]

\n
\n

date-time

\n

The time the control configuration was created.

\n
\n \n
\n
\n
\n
\n
\n

created_by [required]

\n
\n

string

\n

The UUID of the user who created the control configuration.

\n
\n \n
\n
\n
\n
\n
\n

description [required]

\n
\n

string

\n

A human-readable description of what the control detects.

\n
\n \n
\n
\n
\n
\n
\n

detection_frequency [required]

\n
\n

string

\n

How often detections are evaluated for the control.

\n
\n \n
\n
\n
\n
\n
\n

detection_parameters [required]

\n
\n

object

\n

A free-form map of parameter names to their configured values.

\n
\n \n
\n
\n
\n
\n
\n

insights [required]

\n
\n

[string]

\n

The insight slugs associated with the control.

\n
\n \n
\n
\n
\n
\n
\n

last_detection_at [required]

\n
\n

date-time

\n

The time of the most recent detection for the control. null when there are no detections.

\n
\n \n
\n
\n
\n
\n
\n

mitigated_detections_count [required]

\n
\n

int64

\n

The number of mitigated detections for the control.

\n
\n \n
\n
\n
\n
\n
\n

mitigation_parameters [required]

\n
\n

object

\n

A free-form map of parameter names to their configured values.

\n
\n \n
\n
\n
\n
\n
\n

mitigation_type [required]

\n
\n

string

\n

The configured mitigation type for the control. Empty when not configured.

\n
\n \n
\n
\n
\n
\n
\n

mitigations [required]

\n
\n

[object]

\n

The mitigations available for a control.

\n
\n
\n
\n
\n
\n

description [required]

\n
\n

string

\n

A human-readable description of the mitigation.

\n
\n \n
\n
\n
\n
\n
\n

execution_modes [required]

\n
\n

[string]

\n

The execution modes the mitigation supports, such as manual or automatic.

\n
\n \n
\n
\n
\n
\n
\n

id [required]

\n
\n

string

\n

The unique identifier of the mitigation.

\n
\n \n
\n
\n
\n
\n
\n

permissions [required]

\n
\n

[string]

\n

The permissions required to apply the mitigation.

\n
\n \n
\n
\n
\n
\n
\n

supported_parameters [required]

\n
\n

[object]

\n

An array of parameter definitions.

\n
\n
\n
\n
\n
\n

default_value [required]

\n
\n

\n

The default value of the parameter. The JSON type depends on the parameter's type.

\n
\n \n
\n
\n
\n
\n
\n

description [required]

\n
\n

string

\n

A human-readable description of the parameter.

\n
\n \n
\n
\n
\n
\n
\n

display_name [required]

\n
\n

string

\n

The human-readable name of the parameter.

\n
\n \n
\n
\n
\n
\n
\n

name [required]

\n
\n

string

\n

The machine-readable name of the parameter.

\n
\n \n
\n
\n
\n
\n
\n

required [required]

\n
\n

boolean

\n

Whether the parameter must be provided.

\n
\n \n
\n
\n
\n
\n
\n

supported_values [required]

\n
\n

[object]

\n

The supported values for an enumerated parameter.

\n
\n
\n
\n
\n
\n

label [required]

\n
\n

string

\n

The human-readable label for the value.

\n
\n \n
\n
\n
\n
\n
\n

value [required]

\n
\n

string

\n

The machine-readable value.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

type [required]

\n
\n

string

\n

The type of the parameter, such as integer, string, boolean, enum, or pattern_list.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

title [required]

\n
\n

string

\n

A short, human-readable name for the mitigation.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

name [required]

\n
\n

string

\n

Human-readable name of the control.

\n
\n \n
\n
\n
\n
\n
\n

priority [required]

\n
\n

string

\n

The priority of the control, such as High.

\n
\n \n
\n
\n
\n
\n
\n

product [required]

\n
\n

string

\n

The product the control belongs to.

\n
\n \n
\n
\n
\n
\n
\n

resource_type [required]

\n
\n

string

\n

The type of resource the control evaluates.

\n
\n \n
\n
\n
\n
\n
\n

resource_type_display_name [required]

\n
\n

string

\n

The human-readable name of the resource type.

\n
\n \n
\n
\n
\n
\n
\n

supported_detection_parameters [required]

\n
\n

[object]

\n

An array of parameter definitions.

\n
\n
\n
\n
\n
\n

default_value [required]

\n
\n

\n

The default value of the parameter. The JSON type depends on the parameter's type.

\n
\n \n
\n
\n
\n
\n
\n

description [required]

\n
\n

string

\n

A human-readable description of the parameter.

\n
\n \n
\n
\n
\n
\n
\n

display_name [required]

\n
\n

string

\n

The human-readable name of the parameter.

\n
\n \n
\n
\n
\n
\n
\n

name [required]

\n
\n

string

\n

The machine-readable name of the parameter.

\n
\n \n
\n
\n
\n
\n
\n

required [required]

\n
\n

boolean

\n

Whether the parameter must be provided.

\n
\n \n
\n
\n
\n
\n
\n

supported_values [required]

\n
\n

[object]

\n

The supported values for an enumerated parameter.

\n
\n
\n
\n
\n
\n

label [required]

\n
\n

string

\n

The human-readable label for the value.

\n
\n \n
\n
\n
\n
\n
\n

value [required]

\n
\n

string

\n

The machine-readable value.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

type [required]

\n
\n

string

\n

The type of the parameter, such as integer, string, boolean, enum, or pattern_list.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

type [required]

\n
\n

string

\n

The control type, such as Proactive or Detection.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

id [required]

\n
\n

string

\n

The detection type that uniquely identifies the control.

\n
\n \n
\n
\n
\n
\n
\n

type [required]

\n
\n

enum

\n

JSON:API resource type for a governance control. \nAllowed enum values: governance_control

\n
\n \n
\n
\n
\n
" + "html": "
\n
\n
\n
\n

data [required]

\n
\n

object

\n

A governance control resource.

\n
\n
\n
\n
\n
\n

attributes [required]

\n
\n

object

\n

The attributes of a governance control.

\n
\n
\n
\n
\n
\n

active_detections_count [required]

\n
\n

int64

\n

The number of active detections for the control.

\n
\n \n
\n
\n
\n
\n
\n

category [required]

\n
\n

string

\n

The value driver the control is grouped under, such as security or cost.

\n
\n \n
\n
\n
\n
\n
\n

created_at [required]

\n
\n

date-time

\n

The time the control configuration was created.

\n
\n \n
\n
\n
\n
\n
\n

created_by [required]

\n
\n

string

\n

The UUID of the user who created the control configuration.

\n
\n \n
\n
\n
\n
\n
\n

description [required]

\n
\n

string

\n

A human-readable description of what the control detects.

\n
\n \n
\n
\n
\n
\n
\n

detection_parameters [required]

\n
\n

object

\n

A free-form map of parameter names to their configured values.

\n
\n \n
\n
\n
\n
\n
\n

insights [required]

\n
\n

[string]

\n

The insight slugs associated with the control.

\n
\n \n
\n
\n
\n
\n
\n

last_detection_at [required]

\n
\n

date-time

\n

The time of the most recent detection for the control. null when there are no detections.

\n
\n \n
\n
\n
\n
\n
\n

mitigated_detections_count [required]

\n
\n

int64

\n

The number of mitigated detections for the control.

\n
\n \n
\n
\n
\n
\n
\n

mitigation_parameters [required]

\n
\n

object

\n

A free-form map of parameter names to their configured values.

\n
\n \n
\n
\n
\n
\n
\n

mitigation_type [required]

\n
\n

string

\n

The configured mitigation type for the control. Empty when not configured.

\n
\n \n
\n
\n
\n
\n
\n

mitigations [required]

\n
\n

[object]

\n

The mitigations available for a control.

\n
\n
\n
\n
\n
\n

description [required]

\n
\n

string

\n

A human-readable description of the mitigation.

\n
\n \n
\n
\n
\n
\n
\n

execution_modes [required]

\n
\n

[string]

\n

The execution modes the mitigation supports, such as manual or automatic.

\n
\n \n
\n
\n
\n
\n
\n

id [required]

\n
\n

string

\n

The unique identifier of the mitigation.

\n
\n \n
\n
\n
\n
\n
\n

permissions [required]

\n
\n

[string]

\n

The permissions required to apply the mitigation.

\n
\n \n
\n
\n
\n
\n
\n

supported_parameters [required]

\n
\n

[object]

\n

An array of parameter definitions.

\n
\n
\n
\n
\n
\n

default_value [required]

\n
\n

\n

The default value of the parameter. The JSON type depends on the parameter's type.

\n
\n \n
\n
\n
\n
\n
\n

description [required]

\n
\n

string

\n

A human-readable description of the parameter.

\n
\n \n
\n
\n
\n
\n
\n

display_name [required]

\n
\n

string

\n

The human-readable name of the parameter.

\n
\n \n
\n
\n
\n
\n
\n

name [required]

\n
\n

string

\n

The machine-readable name of the parameter.

\n
\n \n
\n
\n
\n
\n
\n

required [required]

\n
\n

boolean

\n

Whether the parameter must be provided.

\n
\n \n
\n
\n
\n
\n
\n

supported_values [required]

\n
\n

[object]

\n

The supported values for an enumerated parameter. null when the parameter is not an enumerated type.

\n
\n
\n
\n
\n
\n

label [required]

\n
\n

string

\n

The human-readable label for the value.

\n
\n \n
\n
\n
\n
\n
\n

value [required]

\n
\n

string

\n

The machine-readable value.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

type [required]

\n
\n

string

\n

The type of the parameter, such as integer, string, boolean, enum, or pattern_list.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

title [required]

\n
\n

string

\n

A short, human-readable name for the mitigation.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

name [required]

\n
\n

string

\n

Human-readable name of the control.

\n
\n \n
\n
\n
\n
\n
\n

priority [required]

\n
\n

string

\n

The priority of the control, such as High.

\n
\n \n
\n
\n
\n
\n
\n

product [required]

\n
\n

string

\n

The product the control belongs to.

\n
\n \n
\n
\n
\n
\n
\n

resource_type [required]

\n
\n

string

\n

The type of resource the control evaluates.

\n
\n \n
\n
\n
\n
\n
\n

resource_type_display_name [required]

\n
\n

string

\n

The human-readable name of the resource type.

\n
\n \n
\n
\n
\n
\n
\n

supported_detection_parameters [required]

\n
\n

[object]

\n

An array of parameter definitions.

\n
\n
\n
\n
\n
\n

default_value [required]

\n
\n

\n

The default value of the parameter. The JSON type depends on the parameter's type.

\n
\n \n
\n
\n
\n
\n
\n

description [required]

\n
\n

string

\n

A human-readable description of the parameter.

\n
\n \n
\n
\n
\n
\n
\n

display_name [required]

\n
\n

string

\n

The human-readable name of the parameter.

\n
\n \n
\n
\n
\n
\n
\n

name [required]

\n
\n

string

\n

The machine-readable name of the parameter.

\n
\n \n
\n
\n
\n
\n
\n

required [required]

\n
\n

boolean

\n

Whether the parameter must be provided.

\n
\n \n
\n
\n
\n
\n
\n

supported_values [required]

\n
\n

[object]

\n

The supported values for an enumerated parameter. null when the parameter is not an enumerated type.

\n
\n
\n
\n
\n
\n

label [required]

\n
\n

string

\n

The human-readable label for the value.

\n
\n \n
\n
\n
\n
\n
\n

value [required]

\n
\n

string

\n

The machine-readable value.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

type [required]

\n
\n

string

\n

The type of the parameter, such as integer, string, boolean, enum, or pattern_list.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

type [required]

\n
\n

string

\n

The control type, such as Proactive or Detection.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

id [required]

\n
\n

string

\n

The detection type that uniquely identifies the control.

\n
\n \n
\n
\n
\n
\n
\n

type [required]

\n
\n

enum

\n

JSON:API resource type for a governance control. \nAllowed enum values: governance_control

\n
\n \n
\n
\n
\n
" }, "400": { "json": { @@ -414,7 +412,6 @@ "created_at": "2024-01-15T09:30:00Z", "created_by": "11111111-2222-3333-4444-555555555555", "description": "Identifies API keys that have not been used within your specified time threshold, helping reduce security risks from dormant credentials.", - "detection_frequency": "daily", "detection_parameters": {}, "insights": [ [] @@ -481,7 +478,7 @@ "type": "governance_control" } }, - "html": "
\n
\n
\n
\n

data [required]

\n
\n

object

\n

A governance control resource.

\n
\n
\n
\n
\n
\n

attributes [required]

\n
\n

object

\n

The attributes of a governance control.

\n
\n
\n
\n
\n
\n

active_detections_count [required]

\n
\n

int64

\n

The number of active detections for the control.

\n
\n \n
\n
\n
\n
\n
\n

category [required]

\n
\n

string

\n

The value driver the control is grouped under, such as security or cost.

\n
\n \n
\n
\n
\n
\n
\n

created_at [required]

\n
\n

date-time

\n

The time the control configuration was created.

\n
\n \n
\n
\n
\n
\n
\n

created_by [required]

\n
\n

string

\n

The UUID of the user who created the control configuration.

\n
\n \n
\n
\n
\n
\n
\n

description [required]

\n
\n

string

\n

A human-readable description of what the control detects.

\n
\n \n
\n
\n
\n
\n
\n

detection_frequency [required]

\n
\n

string

\n

How often detections are evaluated for the control.

\n
\n \n
\n
\n
\n
\n
\n

detection_parameters [required]

\n
\n

object

\n

A free-form map of parameter names to their configured values.

\n
\n \n
\n
\n
\n
\n
\n

insights [required]

\n
\n

[string]

\n

The insight slugs associated with the control.

\n
\n \n
\n
\n
\n
\n
\n

last_detection_at [required]

\n
\n

date-time

\n

The time of the most recent detection for the control. null when there are no detections.

\n
\n \n
\n
\n
\n
\n
\n

mitigated_detections_count [required]

\n
\n

int64

\n

The number of mitigated detections for the control.

\n
\n \n
\n
\n
\n
\n
\n

mitigation_parameters [required]

\n
\n

object

\n

A free-form map of parameter names to their configured values.

\n
\n \n
\n
\n
\n
\n
\n

mitigation_type [required]

\n
\n

string

\n

The configured mitigation type for the control. Empty when not configured.

\n
\n \n
\n
\n
\n
\n
\n

mitigations [required]

\n
\n

[object]

\n

The mitigations available for a control.

\n
\n
\n
\n
\n
\n

description [required]

\n
\n

string

\n

A human-readable description of the mitigation.

\n
\n \n
\n
\n
\n
\n
\n

execution_modes [required]

\n
\n

[string]

\n

The execution modes the mitigation supports, such as manual or automatic.

\n
\n \n
\n
\n
\n
\n
\n

id [required]

\n
\n

string

\n

The unique identifier of the mitigation.

\n
\n \n
\n
\n
\n
\n
\n

permissions [required]

\n
\n

[string]

\n

The permissions required to apply the mitigation.

\n
\n \n
\n
\n
\n
\n
\n

supported_parameters [required]

\n
\n

[object]

\n

An array of parameter definitions.

\n
\n
\n
\n
\n
\n

default_value [required]

\n
\n

\n

The default value of the parameter. The JSON type depends on the parameter's type.

\n
\n \n
\n
\n
\n
\n
\n

description [required]

\n
\n

string

\n

A human-readable description of the parameter.

\n
\n \n
\n
\n
\n
\n
\n

display_name [required]

\n
\n

string

\n

The human-readable name of the parameter.

\n
\n \n
\n
\n
\n
\n
\n

name [required]

\n
\n

string

\n

The machine-readable name of the parameter.

\n
\n \n
\n
\n
\n
\n
\n

required [required]

\n
\n

boolean

\n

Whether the parameter must be provided.

\n
\n \n
\n
\n
\n
\n
\n

supported_values [required]

\n
\n

[object]

\n

The supported values for an enumerated parameter.

\n
\n
\n
\n
\n
\n

label [required]

\n
\n

string

\n

The human-readable label for the value.

\n
\n \n
\n
\n
\n
\n
\n

value [required]

\n
\n

string

\n

The machine-readable value.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

type [required]

\n
\n

string

\n

The type of the parameter, such as integer, string, boolean, enum, or pattern_list.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

title [required]

\n
\n

string

\n

A short, human-readable name for the mitigation.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

name [required]

\n
\n

string

\n

Human-readable name of the control.

\n
\n \n
\n
\n
\n
\n
\n

priority [required]

\n
\n

string

\n

The priority of the control, such as High.

\n
\n \n
\n
\n
\n
\n
\n

product [required]

\n
\n

string

\n

The product the control belongs to.

\n
\n \n
\n
\n
\n
\n
\n

resource_type [required]

\n
\n

string

\n

The type of resource the control evaluates.

\n
\n \n
\n
\n
\n
\n
\n

resource_type_display_name [required]

\n
\n

string

\n

The human-readable name of the resource type.

\n
\n \n
\n
\n
\n
\n
\n

supported_detection_parameters [required]

\n
\n

[object]

\n

An array of parameter definitions.

\n
\n
\n
\n
\n
\n

default_value [required]

\n
\n

\n

The default value of the parameter. The JSON type depends on the parameter's type.

\n
\n \n
\n
\n
\n
\n
\n

description [required]

\n
\n

string

\n

A human-readable description of the parameter.

\n
\n \n
\n
\n
\n
\n
\n

display_name [required]

\n
\n

string

\n

The human-readable name of the parameter.

\n
\n \n
\n
\n
\n
\n
\n

name [required]

\n
\n

string

\n

The machine-readable name of the parameter.

\n
\n \n
\n
\n
\n
\n
\n

required [required]

\n
\n

boolean

\n

Whether the parameter must be provided.

\n
\n \n
\n
\n
\n
\n
\n

supported_values [required]

\n
\n

[object]

\n

The supported values for an enumerated parameter.

\n
\n
\n
\n
\n
\n

label [required]

\n
\n

string

\n

The human-readable label for the value.

\n
\n \n
\n
\n
\n
\n
\n

value [required]

\n
\n

string

\n

The machine-readable value.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

type [required]

\n
\n

string

\n

The type of the parameter, such as integer, string, boolean, enum, or pattern_list.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

type [required]

\n
\n

string

\n

The control type, such as Proactive or Detection.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

id [required]

\n
\n

string

\n

The detection type that uniquely identifies the control.

\n
\n \n
\n
\n
\n
\n
\n

type [required]

\n
\n

enum

\n

JSON:API resource type for a governance control. \nAllowed enum values: governance_control

\n
\n \n
\n
\n
\n
" + "html": "
\n
\n
\n
\n

data [required]

\n
\n

object

\n

A governance control resource.

\n
\n
\n
\n
\n
\n

attributes [required]

\n
\n

object

\n

The attributes of a governance control.

\n
\n
\n
\n
\n
\n

active_detections_count [required]

\n
\n

int64

\n

The number of active detections for the control.

\n
\n \n
\n
\n
\n
\n
\n

category [required]

\n
\n

string

\n

The value driver the control is grouped under, such as security or cost.

\n
\n \n
\n
\n
\n
\n
\n

created_at [required]

\n
\n

date-time

\n

The time the control configuration was created.

\n
\n \n
\n
\n
\n
\n
\n

created_by [required]

\n
\n

string

\n

The UUID of the user who created the control configuration.

\n
\n \n
\n
\n
\n
\n
\n

description [required]

\n
\n

string

\n

A human-readable description of what the control detects.

\n
\n \n
\n
\n
\n
\n
\n

detection_parameters [required]

\n
\n

object

\n

A free-form map of parameter names to their configured values.

\n
\n \n
\n
\n
\n
\n
\n

insights [required]

\n
\n

[string]

\n

The insight slugs associated with the control.

\n
\n \n
\n
\n
\n
\n
\n

last_detection_at [required]

\n
\n

date-time

\n

The time of the most recent detection for the control. null when there are no detections.

\n
\n \n
\n
\n
\n
\n
\n

mitigated_detections_count [required]

\n
\n

int64

\n

The number of mitigated detections for the control.

\n
\n \n
\n
\n
\n
\n
\n

mitigation_parameters [required]

\n
\n

object

\n

A free-form map of parameter names to their configured values.

\n
\n \n
\n
\n
\n
\n
\n

mitigation_type [required]

\n
\n

string

\n

The configured mitigation type for the control. Empty when not configured.

\n
\n \n
\n
\n
\n
\n
\n

mitigations [required]

\n
\n

[object]

\n

The mitigations available for a control.

\n
\n
\n
\n
\n
\n

description [required]

\n
\n

string

\n

A human-readable description of the mitigation.

\n
\n \n
\n
\n
\n
\n
\n

execution_modes [required]

\n
\n

[string]

\n

The execution modes the mitigation supports, such as manual or automatic.

\n
\n \n
\n
\n
\n
\n
\n

id [required]

\n
\n

string

\n

The unique identifier of the mitigation.

\n
\n \n
\n
\n
\n
\n
\n

permissions [required]

\n
\n

[string]

\n

The permissions required to apply the mitigation.

\n
\n \n
\n
\n
\n
\n
\n

supported_parameters [required]

\n
\n

[object]

\n

An array of parameter definitions.

\n
\n
\n
\n
\n
\n

default_value [required]

\n
\n

\n

The default value of the parameter. The JSON type depends on the parameter's type.

\n
\n \n
\n
\n
\n
\n
\n

description [required]

\n
\n

string

\n

A human-readable description of the parameter.

\n
\n \n
\n
\n
\n
\n
\n

display_name [required]

\n
\n

string

\n

The human-readable name of the parameter.

\n
\n \n
\n
\n
\n
\n
\n

name [required]

\n
\n

string

\n

The machine-readable name of the parameter.

\n
\n \n
\n
\n
\n
\n
\n

required [required]

\n
\n

boolean

\n

Whether the parameter must be provided.

\n
\n \n
\n
\n
\n
\n
\n

supported_values [required]

\n
\n

[object]

\n

The supported values for an enumerated parameter. null when the parameter is not an enumerated type.

\n
\n
\n
\n
\n
\n

label [required]

\n
\n

string

\n

The human-readable label for the value.

\n
\n \n
\n
\n
\n
\n
\n

value [required]

\n
\n

string

\n

The machine-readable value.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

type [required]

\n
\n

string

\n

The type of the parameter, such as integer, string, boolean, enum, or pattern_list.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

title [required]

\n
\n

string

\n

A short, human-readable name for the mitigation.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

name [required]

\n
\n

string

\n

Human-readable name of the control.

\n
\n \n
\n
\n
\n
\n
\n

priority [required]

\n
\n

string

\n

The priority of the control, such as High.

\n
\n \n
\n
\n
\n
\n
\n

product [required]

\n
\n

string

\n

The product the control belongs to.

\n
\n \n
\n
\n
\n
\n
\n

resource_type [required]

\n
\n

string

\n

The type of resource the control evaluates.

\n
\n \n
\n
\n
\n
\n
\n

resource_type_display_name [required]

\n
\n

string

\n

The human-readable name of the resource type.

\n
\n \n
\n
\n
\n
\n
\n

supported_detection_parameters [required]

\n
\n

[object]

\n

An array of parameter definitions.

\n
\n
\n
\n
\n
\n

default_value [required]

\n
\n

\n

The default value of the parameter. The JSON type depends on the parameter's type.

\n
\n \n
\n
\n
\n
\n
\n

description [required]

\n
\n

string

\n

A human-readable description of the parameter.

\n
\n \n
\n
\n
\n
\n
\n

display_name [required]

\n
\n

string

\n

The human-readable name of the parameter.

\n
\n \n
\n
\n
\n
\n
\n

name [required]

\n
\n

string

\n

The machine-readable name of the parameter.

\n
\n \n
\n
\n
\n
\n
\n

required [required]

\n
\n

boolean

\n

Whether the parameter must be provided.

\n
\n \n
\n
\n
\n
\n
\n

supported_values [required]

\n
\n

[object]

\n

The supported values for an enumerated parameter. null when the parameter is not an enumerated type.

\n
\n
\n
\n
\n
\n

label [required]

\n
\n

string

\n

The human-readable label for the value.

\n
\n \n
\n
\n
\n
\n
\n

value [required]

\n
\n

string

\n

The machine-readable value.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

type [required]

\n
\n

string

\n

The type of the parameter, such as integer, string, boolean, enum, or pattern_list.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

type [required]

\n
\n

string

\n

The control type, such as Proactive or Detection.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

id [required]

\n
\n

string

\n

The detection type that uniquely identifies the control.

\n
\n \n
\n
\n
\n
\n
\n

type [required]

\n
\n

enum

\n

JSON:API resource type for a governance control. \nAllowed enum values: governance_control

\n
\n \n
\n
\n
\n
" }, "400": { "json": { @@ -573,7 +570,6 @@ "json": { "data": { "attributes": { - "detection_frequency": "daily", "detection_parameters": {}, "mitigation_parameters": {}, "mitigation_type": "revoke_api_key" @@ -581,7 +577,7 @@ "type": "governance_control" } }, - "html": "
\n
\n
\n
\n

data [required]

\n
\n

object

\n

The data of a governance control update request.

\n
\n
\n
\n
\n
\n

attributes

\n
\n

object

\n

The attributes of a governance control that can be updated. Only the attributes present in the request are modified.

\n
\n
\n
\n
\n
\n

detection_frequency

\n
\n

string

\n

How often detections should be evaluated for the control.

\n
\n \n
\n
\n
\n
\n
\n

detection_parameters

\n
\n

object

\n

A free-form map of parameter names to their configured values.

\n
\n \n
\n
\n
\n
\n
\n

mitigation_parameters

\n
\n

object

\n

A free-form map of parameter names to their configured values.

\n
\n \n
\n
\n
\n
\n
\n

mitigation_type

\n
\n

string

\n

The mitigation type to configure for the control.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

type [required]

\n
\n

enum

\n

JSON:API resource type for a governance control. \nAllowed enum values: governance_control

\n
\n \n
\n
\n
\n
" + "html": "
\n
\n
\n
\n

data [required]

\n
\n

object

\n

The data of a governance control update request.

\n
\n
\n
\n
\n
\n

attributes

\n
\n

object

\n

The attributes of a governance control that can be updated. Only the attributes present in the request are modified.

\n
\n
\n
\n
\n
\n

detection_parameters

\n
\n

object

\n

A free-form map of parameter names to their configured values.

\n
\n \n
\n
\n
\n
\n
\n

mitigation_parameters

\n
\n

object

\n

A free-form map of parameter names to their configured values.

\n
\n \n
\n
\n
\n
\n
\n

mitigation_type

\n
\n

string

\n

The mitigation type to configure for the control.

\n
\n \n
\n
\n
\n
\n
\n
\n
\n

type [required]

\n
\n

enum

\n

JSON:API resource type for a governance control. \nAllowed enum values: governance_control

\n
\n \n
\n
\n
\n
" } }, "ListGovernanceControlDetections": { diff --git a/hugo/content/en/code_coverage/_index.md b/hugo/content/en/code_coverage/_index.md index f06b427c55f..04fa09cbd89 100644 --- a/hugo/content/en/code_coverage/_index.md +++ b/hugo/content/en/code_coverage/_index.md @@ -8,6 +8,9 @@ further_reading: - link: "/code_coverage/configuration" tag: "Documentation" text: "Configure Code Coverage" + - link: "/code_coverage/coverage_calculation" + tag: "Documentation" + text: "Learn how Datadog calculates coverage" - link: "/code_coverage/flags" tag: "Documentation" text: "Organize coverage data with flags" diff --git a/hugo/content/en/code_coverage/coverage_calculation.md b/hugo/content/en/code_coverage/coverage_calculation.md new file mode 100644 index 00000000000..d2d4608de48 --- /dev/null +++ b/hugo/content/en/code_coverage/coverage_calculation.md @@ -0,0 +1,98 @@ +--- +title: Code Coverage Calculation +description: "Learn how Datadog merges coverage reports for a commit and how covered, uncovered, and partially covered lines affect total and patch coverage." +further_reading: + - link: "/code_coverage" + tag: "Documentation" + text: "Code Coverage" + - link: "/code_coverage/setup" + tag: "Documentation" + text: "Set up Code Coverage" + - link: "/code_coverage/flags" + tag: "Documentation" + text: "Organize coverage data with flags" + - link: "/code_coverage/carryforward" + tag: "Documentation" + text: "Keep total coverage accurate with carryforward" + - link: "/code_coverage/configuration" + tag: "Documentation" + text: "Configure Code Coverage" +--- + +## Overview + +A commit usually has more than one coverage report. A CI pipeline might run unit, integration, and end-to-end tests in separate jobs. It might also split a test suite across parallel workers, or run the same suite against several runtime versions. Each of those jobs uploads its own report. + +Datadog merges all of the reports it receives for the same repository and commit into a single dataset. The total coverage and patch coverage of a commit are computed from that merged dataset, not from any individual report. You don't need to merge reports yourself before uploading them. + +Because merging happens on the Datadog side, the coverage percentage shown in Datadog can differ from the percentage reported by a single coverage tool run. For related guidance, see [Discrepancy between Datadog UI and coverage report values][1]. + +## Report merging + +Merging is keyed on the repository and commit SHA pair. Every report uploaded for the same repository and commit contributes to the same merged dataset, regardless of which CI job, pipeline, or machine produced it. + +Merging is incremental. As each report arrives, its data is added to the merged dataset and the coverage values are recomputed. A commit's coverage reflects every report received for it so far. Wait until all of your CI jobs have finished uploading before comparing coverage percentages to PR Gate thresholds or to values from a single local report. + +The merged dataset is also the basis for the following: + +- The total and patch coverage displayed for a commit and for its pull request +- [PR Gate][2] evaluation +- Per-service and per-code-owner coverage in [Monorepo Support][3] + +[Flags][4] add a second layer on top of this. Reports sharing a flag are merged together into that flag's own dataset, while the unflagged view merges every report for the commit. For details, see [How flags work with report merging][5]. + +If [carryforward][7] is enabled, reports carried forward from ancestor commits are merged in the same way as reports uploaded directly for the commit. + +## Line coverage statuses + +Within the merged dataset, each executable line of each file has one of the following statuses: + +| Status | Meaning | +|---|---| +| Covered | The line was executed, and if it contains branches, every branch was executed. | +| Partially covered | The line was executed, but not all of its branches were. | +| Uncovered | The line was never executed. | + +Non-executable lines, such as comments, blank lines, and closing brackets, are excluded from coverage calculations. For coverage tools that report these lines as uncovered, see [Inaccurate coverage from non-executable lines][6]. + +### Files present in multiple reports + +When the same file appears in more than one report, Datadog merges the file's line data instead of picking one report over another. An executable line is counted as covered when **any** of the reports containing that file marks it as covered. + +For example, consider a commit with two reports that both contain `src/checkout.go`: + +| Line | Unit test report | Integration test report | Merged result | +|---|---|---|---| +| 10 | Covered | Uncovered | Covered | +| 11 | Uncovered | Covered | Covered | +| 12 | Uncovered | Uncovered | Uncovered | + +The merged coverage of a commit is therefore usually higher than the coverage of any single report. Splitting a test suite across parallel CI jobs does not lower the reported coverage. + +### Partial coverage + +A line is partially covered when it was executed but not all of its branches were. This applies to `if` statements as well as ternary operators, and to any other construct where a single line contains multiple execution paths. + +For example, in the following line, only one of the two paths runs if `user` is always non-null in your tests: + +{{< code-block lang="javascript" >}} +const name = user ? user.name : "anonymous"; +{{< /code-block >}} + +The line is executed, so it is not uncovered, but the `"anonymous"` branch is never taken, so the line is reported as partially covered. + +**Partially covered lines are not counted as covered.** They do not contribute to the total coverage percentage or to the patch coverage percentage. To count such a line as covered, add test cases that exercise all of its branches. + +Partial coverage is derived from the branch data in your coverage reports. If your coverage tool or report format doesn't include branch information, lines that were executed are reported as covered rather than partially covered. + +## Further reading + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /code_coverage/setup#discrepancy-between-datadog-ui-and-coverage-report-values +[2]: /code_coverage/configuration#pr-gates +[3]: /code_coverage/monorepo_support +[4]: /code_coverage/flags +[5]: /code_coverage/flags#how-flags-work-with-report-merging +[6]: /code_coverage/setup#inaccurate-coverage-from-non-executable-lines +[7]: /code_coverage/carryforward diff --git a/hugo/content/en/code_coverage/flags.md b/hugo/content/en/code_coverage/flags.md index 3a508f6ccbc..14b5aaa4d0a 100644 --- a/hugo/content/en/code_coverage/flags.md +++ b/hugo/content/en/code_coverage/flags.md @@ -66,6 +66,8 @@ The resulting coverage data for each flag is: This allows you to answer questions like "What is my unit test coverage?" (`unit-tests` flag) or "What is my coverage on JVM 11?" (`jvm-11` flag) from the same set of uploaded reports. +For details on how line data from overlapping reports is combined, see [Code Coverage Calculation][7]. + ## Add flags to coverage reports ### Add flags with the CLI @@ -206,3 +208,4 @@ datadog-ci coverage upload --flags python-3.12 coverage-py312.xml [4]: /code_coverage/setup/#upload-reports-automatically-with-test-optimization [5]: https://app.datadoghq.com/ci/code-coverage [6]: /code_coverage/configuration#pr-gates +[7]: /code_coverage/coverage_calculation diff --git a/hugo/content/en/code_coverage/setup.md b/hugo/content/en/code_coverage/setup.md index 5ea7c28ba63..9da330e9deb 100644 --- a/hugo/content/en/code_coverage/setup.md +++ b/hugo/content/en/code_coverage/setup.md @@ -529,6 +529,8 @@ If you use an external tool (such as [ReportGenerator][16]) to merge coverage re ensure your merged reports do not contain duplicate source code file entries. Datadog deduplicates overlapping files across reports, which can result in differences between your original coverage values and the merged values displayed in the Datadog UI. +For a description of how reports are merged and how each line status is counted, see [Code Coverage Calculation][20]. + ## Further reading {{< partial name="whats-next/whats-next.html" >}} @@ -552,3 +554,4 @@ Datadog deduplicates overlapping files across reports, which can result in diffe [17]: /tests/setup/ [18]: /code_coverage/setup/#integrate-with-source-code-provider [19]: https://app.datadoghq.com/organization-settings/data-access-controls +[20]: /code_coverage/coverage_calculation diff --git a/hugo/content/en/containers/cluster_agent/endpointschecks.md b/hugo/content/en/containers/cluster_agent/endpointschecks.md index d147ea5da0e..ba1ef98b46e 100644 --- a/hugo/content/en/containers/cluster_agent/endpointschecks.md +++ b/hugo/content/en/containers/cluster_agent/endpointschecks.md @@ -20,7 +20,7 @@ further_reading: The cluster check feature provides the ability to [Autodiscover][1] and perform checks on load-balanced cluster services, such as Kubernetes services. _Endpoints checks_ extend this mechanism to monitor each endpoint managed by a Kubernetes service. -The [Cluster Agent][2] discovers endpoint check configurations based on [Autodiscovery][1] annotations on the Kubernetes services. The Cluster Agent then dispatches these configurations to node-based Agents to individually run. Endpoint checks are dispatched to Agents that run on the same node as the Pod(s) that back the endpoint(s) of the monitored Kubernetes service. This dispatching logic allows the Agent to add the Pod and container tags it has already collected for each respective Pod. +The [Cluster Agent][2] discovers endpoint check configurations from [Autodiscovery][1] annotations on Kubernetes services or from a [`DatadogInstrumentation` custom resource][14]. The Cluster Agent then dispatches these configurations to node-based Agents to individually run. Endpoint checks are dispatched to Agents that run on the same node as the Pod(s) that back the endpoint(s) of the monitored Kubernetes service. This dispatching logic allows the Agent to add the Pod and container tags it has already collected for each respective Pod. The Agents connect to the Cluster Agent every ten seconds and retrieve the check configurations to run. Metrics coming from endpoints checks are submitted with service tags, [Kubernetes tags][3], host tags, and the `kube_endpoint_ip` tag based on the evaluated IP address. @@ -319,7 +319,6 @@ spec: [11]: /agent/kubernetes/integrations/?tab=kubernetes#supported-template-variables [12]: /integrations/nginx/ [13]: /getting_started/tagging/unified_service_tagging - {{% /tab %}} {{% tab "Kubernetes (AD v1)" %}} @@ -391,6 +390,28 @@ spec: {{% /tab %}} {{< /tabs >}} +### Configuration from DatadogInstrumentation CRD + +Use a `DatadogInstrumentation` resource targeting the Service. For more details, see [Configure Autodiscovery with DatadogInstrumentation CRD][14]. + +```yaml +apiVersion: datadoghq.com/v1alpha1 +kind: DatadogInstrumentation +metadata: + name: nginx-endpoints +spec: + targetRef: + apiVersion: v1 + kind: Service + name: nginx + config: + checks: + - integration: nginx + instances: + - name: "My NGINX Service Endpoints" + nginx_status_url: "http://%%host%%:%%port%%/status/" +``` + ## Further Reading {{< partial name="whats-next/whats-next.html" >}} @@ -408,3 +429,4 @@ spec: [11]: /agent/kubernetes/integrations/?tab=kubernetes#supported-template-variables [12]: /integrations/nginx/ [13]: /getting_started/tagging/unified_service_tagging +[14]: /containers/guide/configure-autodiscovery-with-the-datadoginstrumentation-crd/#service-targets diff --git a/hugo/content/en/containers/guide/_index.md b/hugo/content/en/containers/guide/_index.md index 34ad7878568..08ce9164cc7 100644 --- a/hugo/content/en/containers/guide/_index.md +++ b/hugo/content/en/containers/guide/_index.md @@ -29,6 +29,7 @@ disable_toc: true {{< nextlink href="/containers/guide/ad_identifiers" >}}Container identifiers: Apply an Autodiscovery configuration file template to a specific container{{< /nextlink >}} {{< nextlink href="/containers/guide/template_variables" >}}Autodiscovery template variables: Dynamically populate configuration settings{{< /nextlink >}} {{< nextlink href="/containers/guide/auto_conf" >}}Autodiscovery auto-configuration: Default base configuration for common integrations{{< /nextlink >}} + {{< nextlink href="/containers/guide/configure-autodiscovery-with-the-datadoginstrumentation-crd" >}}Configure Autodiscovery with DatadogInstrumentation CRD{{< /nextlink >}} {{< nextlink href="/containers/guide/autodiscovery-examples" >}}Detailed Autodiscovery template examples{{< /nextlink >}} {{< /whatsnext >}} diff --git a/hugo/content/en/containers/guide/auto_conf.md b/hugo/content/en/containers/guide/auto_conf.md index 2bc1c8f831c..19530e14c4f 100644 --- a/hugo/content/en/containers/guide/auto_conf.md +++ b/hugo/content/en/containers/guide/auto_conf.md @@ -50,9 +50,9 @@ When the Agent runs as a container, [Autodiscovery][49] tries to discover other The `auto_conf.yaml` configuration files cover all required parameters to set up a specific integration, with their corresponding [Autodiscovery Templates Variables][43] in place to take into account the containerized environment. ## Override auto-configuration -Each `auto_conf.yaml` file provides a default configuration. To override this, you can add a custom configuration in [Kubernetes annotations][50] or [Docker Labels][51]. +Each `auto_conf.yaml` file provides a default configuration. To override this on Kubernetes, you can add a custom configuration in [Kubernetes annotations][50] or use the [`DatadogInstrumentation` custom resource][52]. For Docker, use [Docker Labels][51]. -Kubernetes annotations and Docker Labels take precedence over `auto_conf.yaml` files, but `auto_conf.yaml` files take precedence over Autodiscovery configuration set in the Datadog Operator and Helm charts. To use Datadog Operator or Helm to configure Autodiscovery for an integration in the table on this page, you must [disable auto-configuration](#disable-auto-configuration). +Kubernetes annotations take precedence over `DatadogInstrumentation` resources and `auto_conf.yaml` files. `DatadogInstrumentation` resources take precedence over `auto_conf.yaml` files, and `auto_conf.yaml` files take precedence over Autodiscovery configuration set in the Datadog Operator and Helm charts. To use Datadog Operator or Helm to configure Autodiscovery for an integration in the table on this page, you must [disable auto-configuration](#disable-auto-configuration). ## Disable auto-configuration @@ -161,3 +161,4 @@ DD_IGNORE_AUTOCONF="redisdb istio" [49]: /getting_started/containers/autodiscovery [50]: /containers/kubernetes/integrations/?tab=annotations#configuration [51]: /containers/docker/integrations/ +[52]: /containers/guide/configure-autodiscovery-with-the-datadoginstrumentation-crd/ diff --git a/hugo/content/en/containers/guide/autodiscovery-examples.md b/hugo/content/en/containers/guide/autodiscovery-examples.md index 344c992e3f7..a3f08aa0706 100644 --- a/hugo/content/en/containers/guide/autodiscovery-examples.md +++ b/hugo/content/en/containers/guide/autodiscovery-examples.md @@ -17,6 +17,9 @@ further_reading: - link: "/agent/kubernetes/tag/" tag: "Documentation" text: "Assign tags to all data emitted by a container" +- link: "/containers/guide/configure-autodiscovery-with-the-datadoginstrumentation-crd/" + tag: "Documentation" + text: "Configure Autodiscovery with DatadogInstrumentation CRD" --- This page contains detailed example templates for configuring integrations in containerized environments in the following scenarios: @@ -28,6 +31,8 @@ For more information about containers and integrations, see [Docker and Integrat All examples make use of Datadog's Autodiscovery feature, which allows you to define configuration templates for Agent Checks on designated sets of containers. For more information about Autodiscovery, see [Getting Started with Containers: Autodiscovery][1]. +To configure these checks for a specific workload without using pod annotations, see [Configure Autodiscovery with DatadogInstrumentation CRD][13]. + ## Redis integration for all Redis containers In this example scenario, you have a containerized environment in which you want to set up and configure the [Datadog-Redis integration][5] for all containers that match the name `redis`. You have one container named `redis` and another named `my-custom-redis`, and you want to configure the Redis integration for **both** containers. @@ -130,6 +135,38 @@ spec: - containerPort: 6379 ``` +{{% /tab %}} +{{% tab "DatadogInstrumentation CRD" %}} + +In a `DatadogInstrumentation` resource: + +```yaml +apiVersion: datadoghq.com/v1alpha1 +kind: DatadogInstrumentation +metadata: + name: redis-instrumentation + namespace: default +spec: + targetRef: + apiVersion: apps/v1 + kind: Deployment + name: redis + config: + checks: + - integration: redisdb + containerName: redis + instances: + - host: "%%host%%" + port: "6379" + password: "%%env_REDIS_PASSWORD%%" + logs: + - containerName: redis + type: file + path: /var/log/redis_6379.log + source: redis + service: redis_service +``` + {{% /tab %}} {{% tab "Docker labels" %}} @@ -410,6 +447,40 @@ spec: # (...) ``` +{{% /tab %}} +{{% tab "DatadogInstrumentation CRD" %}} + +In a `DatadogInstrumentation` resource: + +```yaml +apiVersion: datadoghq.com/v1alpha1 +kind: DatadogInstrumentation +metadata: + name: apache-instrumentation + namespace: default +spec: + targetRef: + apiVersion: apps/v1 + kind: Deployment + name: apache + config: + checks: + - integration: apache + containerName: apache + instances: + - apache_status_url: "http://%%host%%/server-status?auto" + min_collection_interval: 30 + - integration: http_check + containerName: apache + instances: + - name: "my_website_1" + url: "http://%%host%%/website_1" + timeout: 1 + - name: "my_website_2" + url: "http://%%host%%/website_2" + timeout: 1 +``` + {{% /tab %}} {{% tab "Docker labels" %}} @@ -635,4 +706,5 @@ All of these examples use [Autodiscovery template variables][7]: [9]: /integrations/http_check/ [10]: https://github.com/DataDog/integrations-core/blob/master/apache/datadog_checks/apache/data/conf.yaml.example [11]: /extend/write_agent_check/#updating-the-collection-interval -[12]: https://github.com/DataDog/integrations-core/blob/master/http_check/datadog_checks/http_check/data/conf.yaml.example \ No newline at end of file +[12]: https://github.com/DataDog/integrations-core/blob/master/http_check/datadog_checks/http_check/data/conf.yaml.example +[13]: /containers/guide/configure-autodiscovery-with-the-datadoginstrumentation-crd/ diff --git a/hugo/content/en/containers/guide/autodiscovery-with-jmx.md b/hugo/content/en/containers/guide/autodiscovery-with-jmx.md index 0bbaefcdfdd..575c061f772 100644 --- a/hugo/content/en/containers/guide/autodiscovery-with-jmx.md +++ b/hugo/content/en/containers/guide/autodiscovery-with-jmx.md @@ -63,12 +63,15 @@ agents: Use one of the following methods: - [Autodiscovery annotations](#autodiscovery-annotations) (recommended) +- [`DatadogInstrumentation` custom resource][8]: for supported workloads where you want to configure integrations without modifying your workload. - [Autodiscovery configuration files](#autodiscovery-configuration-files): for heavy customization of configuration parameters ### Autodiscovery annotations In this method, a JMX check configuration is applied using annotations on your Java-based Pods. This allows the Agent to automatically configure the JMX check when a new container starts. Ensure these annotations are on the created Pod, and not on the object (Deployment, DaemonSet, etc.) creating the Pod. +Alternatively, use the [`DatadogInstrumentation` custom resource][8] to define the same check as a separate Kubernetes resource, instead of an Autodiscovery annotation. + Use the following template for Autodiscovery annotations: ```yaml @@ -514,6 +517,7 @@ Alternatively use `jmx` as your `` to set up a basic JMX integ [5]: https://kubernetes.io/docs/concepts/workloads/pods/downward-api/ [6]: /integrations/java/ [7]: https://kubernetes.io/docs/concepts/services-networking/network-policies/ +[8]: /containers/guide/configure-autodiscovery-with-the-datadoginstrumentation-crd/ [41]: /integrations/activemq/ [42]: https://github.com/DataDog/integrations-core/blob/master/activemq/datadog_checks/activemq/data/metrics.yaml [43]: https://github.com/DataDog/integrations-core/blob/master/activemq/datadog_checks/activemq/data/conf.yaml.example diff --git a/hugo/content/en/containers/guide/configure-autodiscovery-with-the-datadoginstrumentation-crd.md b/hugo/content/en/containers/guide/configure-autodiscovery-with-the-datadoginstrumentation-crd.md new file mode 100644 index 00000000000..b8f4371082f --- /dev/null +++ b/hugo/content/en/containers/guide/configure-autodiscovery-with-the-datadoginstrumentation-crd.md @@ -0,0 +1,276 @@ +--- +title: Configure Autodiscovery with DatadogInstrumentation CRD +description: Configure Autodiscovery checks and logs for Kubernetes workloads through the DatadogInstrumentation custom resource instead of pod annotations. +further_reading: +- link: "/containers/kubernetes/integrations/" + tag: "Documentation" + text: "Configure integrations with Autodiscovery" +- link: "/getting_started/containers/autodiscovery/" + tag: "Documentation" + text: "Getting Started with Autodiscovery" +- link: "/containers/guide/autodiscovery-examples/" + tag: "Documentation" + text: "Autodiscovery scenarios and examples" +- link: "/containers/cluster_agent/" + tag: "Documentation" + text: "Datadog Cluster Agent" +--- + +## Overview + +The `DatadogInstrumentation` custom resource (CR) lets you configure [Autodiscovery][1] checks and logs with a single Kubernetes resource instead of [pod annotations][2]. With this approach, you can enable, update, and remove integration configurations without editing your Agent or application and triggering a rollout. + +Use the `DatadogInstrumentation` CR when you want to: + +- Configure checks and logs without modifying workload manifests or adding annotations. +- Use a structured resource spec with validation instead of raw JSON in annotations. +- Centrally manage per-workload Autodiscovery configuration as a dedicated, version-controlled Kubernetes resource. +- Update or remove Autodiscovery configuration without restarting your application pods. + +When you create or update a `DatadogInstrumentation` resource, the [Datadog Cluster Agent][3] validates the target, reports resource status, and applies the Autodiscovery configuration to the targeted workload. + +## Requirements + +Upgrade to **v7.82+** of the Datadog Agent and Cluster Agent and install the `DatadogInstrumentation` CRD with one of the following: +- Datadog Operator **v1.29** or later. +- Datadog Helm chart **v3.236.0** or later. + +## Setup + +The `DatadogInstrumentation` controller runs in the Cluster Agent and is disabled by default. Enable it with the Datadog Operator or Helm. + +{{< tabs >}} +{{% tab "Datadog Operator" %}} + +1. Update your Helm repositories: + +```shell +helm repo update +``` + +2. Upgrade the Datadog Operator: + +```shell +helm upgrade datadog-operator datadog/datadog-operator +``` + +3. Add the `agent.datadoghq.com/instrumentation-crd-enabled` annotation to your `DatadogAgent` resource. The Cluster Agent must be v7.82.0 or later. + +```yaml +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog + annotations: + agent.datadoghq.com/instrumentation-crd-enabled: "true" +spec: + global: + [...] +``` + +4. Apply the change: + +```shell +kubectl apply -f datadog-agent.yaml +``` + +The Operator sets the required Cluster Agent and Node Agent environment variables, and configures the required RBAC for the Cluster Agent automatically. + +{{% /tab %}} +{{% tab "Helm" %}} + +1. Update your Helm repositories: + +```shell +helm repo update +``` + +2. In your `datadog-values.yaml` file, enable the controller: + +```yaml +datadog: + instrumentationCrd: + enabled: true +``` + +3. Upgrade your release: + +```shell +helm upgrade -f datadog-values.yaml datadog/datadog +``` + +{{% /tab %}} +{{< /tabs >}} + +Make sure the `DatadogInstrumentation` CRD is installed before creating resources: + +```shell +kubectl get crd datadoginstrumentations.datadoghq.com +``` + +If you manage Datadog CRDs separately, install or upgrade the Datadog CRDs Helm chart: + +```shell +helm upgrade --install datadog-crds datadog/datadog-crds +``` + +## Target workloads + +`DatadogInstrumentation` (DDI) for Autodiscovery has three parts: + +- `spec.targetRef`: identifies the workload to configure, by `apiVersion`, `kind`, and `name`. Your custom resource and target workload must be in the same namespace. +- `spec.config.checks`: defines integration checks to run against your workload. +- `spec.config.logs`: defines logs to collect from your workload. + +You can target the following Kubernetes resources: + +- Deployment +- DaemonSet +- StatefulSet +- CronJob +- Job +- Service (see the [Service targets](#service-targets) section) + +This example configures a [Redis integration][4] for a `StatefulSet` named `redis`, mirroring this [annotation-based example][2]. + +```yaml +apiVersion: datadoghq.com/v1alpha1 +kind: DatadogInstrumentation +metadata: + name: + namespace: +spec: + targetRef: + apiVersion: apps/v1 + kind: StatefulSet + name: redis + config: + checks: + - integration: redisdb + containerName: redis + initConfig: {} + instances: + - host: "%%host%%" + port: "6379" + password: "%%env_REDIS_PASSWORD%%" + logs: + - containerName: redis + tags: + - env:demo +``` + +Apply the resource: + +```shell +kubectl apply -f redis-instrumentation.yaml +``` + +Check the resource status: + +```shell +kubectl describe datadoginstrumentation -n +``` + +Each entry in `checks` accepts the following fields: + +`integration` +: Required. The name of the Datadog integration to run, for example `redisdb`. + +`containerName` +: Required for workload targets. The value must match a container name in the pod. Omit this field for Service targets. + +`initConfig` +: Optional. The `init_config` section for the integration. + +`instances` +: Optional. Check instance settings. Each instance can use [Autodiscovery template variables][5], including `%%host%%`. + +Each entry in `logs` accepts the same log collection options as Autodiscovery log annotations, such as `tags`, `type`, and `path`. Each entry requires a `containerName` matching a container in the pod. + +### Target Services + +Targeting a `Service` configures an [endpoint check][6] similar to an annotation on a Kubernetes service. + +- Datadog schedules one endpoint check for each endpoint of the Service. +- `%%host%%` resolves to the endpoint IP. +- If an endpoint is backed by a Kubernetes Pod, Datadog adds the Pod tags collected for that Pod. +- If an endpoint is not backed by a Pod, Datadog converts the check into a regular cluster check without Pod-specific tags. + +
+ +Service targets do not use `containerName`; omit that field. + +
+ +Below is an example configuring a nginx check against a Kubernetes `Service`: + +```yaml +apiVersion: datadoghq.com/v1alpha1 +kind: DatadogInstrumentation +metadata: + name: + namespace: +spec: + targetRef: + apiVersion: v1 + kind: Service + name: nginx + config: + checks: + - integration: nginx + initConfig: {} + instances: + - name: "My NGINX Service Endpoints" + nginx_status_url: "http://%%host%%:%%port%%/status/" +``` + +## Precedence + +When more than one configuration source applies to a workload, the Datadog Agent resolves them in the following order (highest precedence first): + +1. Pod annotations +2. `DatadogInstrumentation` custom resource +3. Static configuration, such as auto-configuration or mounted files + +If a workload already has annotation-based Autodiscovery configuration for a check or log collection, your `DatadogInstrumentation` configuration does not override it. + +## One resource per target + +A workload or Service can be the target of only one `DatadogInstrumentation` resource within a namespace. A validation webhook rejects a resource whose `targetRef` already belongs to another resource, or whose `targetRef` points to an unsupported kind. + +## Verify scheduled checks + +The resource status shows whether the Cluster Agent accepted the configuration. To verify that the checks are scheduled, run `agent configcheck` on the Node Agent where the target workload runs. + +Checks configured through a `DatadogInstrumentation` resource list `instrumentation-checks` as the configuration provider and `datadoginstrumentation:/` as the configuration source. The following example shows the output for a `redisdb` check scheduled from a resource that targets a Redis workload: + +```text +> agent configcheck +# other configs... + +=== redisdb check === +Configuration provider: instrumentation-checks +Configuration source: datadoginstrumentation:cache/redis-instrumentation +Config for instance ID: redisdb:d5dd267b580bc10e +host: 10.244.0.7 +password: "********" +port: 6379 +Init Config: +{} +Log Config: +- tags: + - env:demo +Auto-discovery IDs: +* redis +``` + +## Further reading + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /getting_started/containers/autodiscovery/ +[2]: /containers/kubernetes/integrations/ +[3]: /containers/cluster_agent/ +[4]: /integrations/redisdb/ +[5]: /containers/guide/template_variables/ +[6]: /containers/cluster_agent/endpointschecks/ diff --git a/hugo/content/en/containers/kubernetes/integrations.md b/hugo/content/en/containers/kubernetes/integrations.md index d0ba191b12f..bdd59e15001 100644 --- a/hugo/content/en/containers/kubernetes/integrations.md +++ b/hugo/content/en/containers/kubernetes/integrations.md @@ -52,7 +52,7 @@ Some commonly-used integrations come with default configuration for Autodiscover Otherwise: -1. Choose a configuration method (Kubernetes pod annotations, a local file, a ConfigMap, a key-value store, a Datadog Operator manifest, or a Helm chart) that suits your use case. +1. Choose a configuration method (Kubernetes pod annotations, a local file, a ConfigMap, a key-value store, a Datadog Operator manifest, a Helm chart, or the `DatadogInstrumentation` custom resource) that suits your use case. 2. Reference the template format for your chosen method. Each format contains placeholders, such as ``. 3. [Supply values](#placeholder-values) for these placeholders. @@ -107,6 +107,38 @@ spec: If you define pods indirectly (with deployments, ReplicaSets, or ReplicationControllers) add pod annotations under `spec.template.metadata`. +{{% /tab %}} +{{% tab "DatadogInstrumentation CRD" %}} + +You can configure Autodiscovery checks and log collection for a specific workload through the `DatadogInstrumentation` custom resource, instead of pod annotations. This lets you update or remove Autodiscovery configuration without editing pod specs or restarting your application pods. You can also target a Kubernetes `Service` to schedule endpoint checks for each endpoint of that Service. + +```yaml +apiVersion: datadoghq.com/v1alpha1 +kind: DatadogInstrumentation +metadata: + name: + namespace: default +spec: + targetRef: + apiVersion: apps/v1 + kind: Deployment + name: + config: + checks: + - integration: + containerName: + initConfig: + + instances: + - + logs: + - containerName: + +``` + +For setup steps, the full resource schema, and precedence rules, see [Configure Autodiscovery with DatadogInstrumentation CRD][29]. + +[29]: /containers/guide/configure-autodiscovery-with-the-datadoginstrumentation-crd/ {{% /tab %}} {{% tab "Local file" %}} @@ -412,7 +444,7 @@ For more information about tag cardinality, see [Per-check tag configuration][27 The Datadog Agent automatically recognizes and supplies basic configuration for some common technologies. For a complete list, see [Autodiscovery auto-configuration][20]. -Configurations set with Kubernetes annotations take precedence over auto-configuration, but auto-configuration takes precedence over configurations set with Datadog Operator or Helm. To use Datadog Operator or Helm to configure an integration in the [Autodiscovery auto-configuration][20] list, you must [disable auto-configuration][22]. +Configurations set with Kubernetes annotations take precedence over `DatadogInstrumentation` resources and auto-configuration. `DatadogInstrumentation` resources take precedence over static configuration, including auto-configuration and configurations set with Datadog Operator or Helm. To use Datadog Operator or Helm to configure an integration in the [Autodiscovery auto-configuration][20] list, you must [disable auto-configuration][22]. ## Integrations security diff --git a/hugo/content/en/containers/kubernetes/log.md b/hugo/content/en/containers/kubernetes/log.md index 2ed2d23faa3..ff365e0c310 100644 --- a/hugo/content/en/containers/kubernetes/log.md +++ b/hugo/content/en/containers/kubernetes/log.md @@ -163,9 +163,9 @@ The Datadog Agent in Kubernetes is deployed by a DaemonSet (managed by the Datad When "Container Collect All" is enabled you can configure which containers you want to collect logs from. This can be useful to prevent the collection of the Datadog Agent logs, if desired. You can do this by passing configurations to the Datadog Agent to control what it pulls, or by passing configurations to the Kubernetes Pod to exclude certain logs more explicitly. -When filtering out logs through methods like `DD_CONTAINER_EXCLUDE_LOGS` or `ad.datadoghq.com/logs_exclude`, the Agent ignores log collection regardless of explicitly defined log collection configurations in [Autodiscovery annotations][19] or [Autodiscovery configuration files][20]. +When filtering out logs through methods like `DD_CONTAINER_EXCLUDE_LOGS` or `ad.datadoghq.com/logs_exclude`, the Agent ignores log collection regardless of explicitly defined log collection configurations in [Autodiscovery annotations][19], the [`DatadogInstrumentation` CRD][23], or [Autodiscovery configuration files][20]. -When "Container Collect All" is disabled (default) you don't need to add any filtering because everything is excluded by default. To include collection for only selected pods, you can enable the log configuration by [Autodiscovery annotations][19] or [Autodiscovery configuration files][20] for the desired pods. +When "Container Collect All" is disabled (default) you don't need to add any filtering because everything is excluded by default. To include collection for only selected pods, you can enable the log configuration by [Autodiscovery annotations][19], the [`DatadogInstrumentation` CRD][23], or [Autodiscovery configuration files][20] for the desired pods. See [Container Discovery Management][8] to learn more about filtering. @@ -179,10 +179,11 @@ The `source` tag can be important for your logs, as the [out of box log pipeline ## Integration logs -[Autodiscovery][10] enables you to use templates to configure log collection (and other capabilities) on containers. This can be used to enable log collection, customize tagging, and add advanced collection rules. To configure log collection for an integration with Autodiscovery you can either: +[Autodiscovery][10] enables you to use templates to configure log collection and other capabilities on containers. Use one of the following methods to configure log collection: -- Specify a log configuration as Autodiscovery Annotations on a given Pod, to configure the rules for a given container *(Recommended)* -- Specify a log configuration as a configuration file, to configure the rules for each matching container by image +- [Autodiscovery annotations](#autodiscovery-annotations) (recommended) +- [`DatadogInstrumentation` CRD](#datadoginstrumentation-crd) (new) +- [Autodiscovery configuration files](#autodiscovery-configuration-files) Setting a `source` and `service` tag on these log configurations is strongly recommended. Match the `source` tag to one of Datadog's [out-of-the-box log pipelines][15] so your logs are automatically enriched; you can also find a [library of pipelines in Datadog][16]. The `service` tag powers [Unified Service Tagging][4], linking your logs with metrics and traces from the same service. If `source` and `service` are omitted, the Agent falls back to the `service` tag from Unified Service Tagging (when set), and otherwise to the container's short image name. @@ -190,7 +191,7 @@ Setting a `source` and `service` tag on these log configurations is strongly rec With Autodiscovery, the Agent automatically searches all Pod annotations for integration templates. -To apply a specific configuration to a given container, add the annotation `ad.datadoghq.com/.logs` to your Pod with the JSON formatted log configuration. +To apply a specific configuration to a given container, add the annotation `ad.datadoghq.com/.logs` to your Pod with the JSON formatted log configuration. **Note**: Autodiscovery annotations identify containers by name, **not** image. It tries to match `` to the `.spec.containers[i].name`, not `.spec.containers[i].image`. @@ -265,6 +266,30 @@ spec: # (...) ``` +### DatadogInstrumentation CRD + +Instead of annotating your pods or deployments, you can use a [`DatadogInstrumentation` custom resource][23] to configure log collection. The following examples is for the `app` container part of the `example` Deployment: + +```yaml +apiVersion: datadoghq.com/v1alpha1 +kind: DatadogInstrumentation +metadata: + name: example-logs + namespace: +spec: + targetRef: + apiVersion: apps/v1 + kind: Deployment + name: example + config: + logs: + - containerName: app + source: java + service: example-app + tags: + - foo:bar +``` + ### Autodiscovery configuration files You can provide the Datadog Agent with configuration files to have the Agent run a specified integration when it discovers a container using the matching image identifier. This allows you to create a generic log configuration that applies to a set of container images. @@ -286,7 +311,7 @@ spec: .yaml: |- ad_identifiers: - - + logs: - source: example-source service: example-service @@ -307,7 +332,6 @@ datadog: .yaml: |- ad_identifiers: - - logs: - source: example-source service: example-service @@ -495,3 +519,4 @@ For troubleshooting steps, see [Container Log Collection Troubleshooting][21]. [20]: /containers/kubernetes/log/?tab=helm#autodiscovery-configuration-files [21]: /containers/troubleshooting/log-collection/?tab=datadogoperator [22]: /containers/guide/ad_identifiers/ +[23]: /containers/guide/configure-autodiscovery-with-the-datadoginstrumentation-crd/ diff --git a/hugo/content/en/containers/kubernetes/prometheus.md b/hugo/content/en/containers/kubernetes/prometheus.md index ae859b422a2..547a1159735 100644 --- a/hugo/content/en/containers/kubernetes/prometheus.md +++ b/hugo/content/en/containers/kubernetes/prometheus.md @@ -52,10 +52,10 @@ This page explains the basic usage of these checks, which enable you to scrape c ### Configuration -Configure your OpenMetrics or Prometheus check using Autodiscovery, by applying the following `annotations` to your **pod** exposing the OpenMetrics/Prometheus metrics: +Configure your OpenMetrics or Prometheus check using Autodiscovery. Use pod annotations or `DatadogInstrumentation` custom resources. {{< tabs >}} -{{% tab "Kubernetes (AD v2)" %}} +{{% tab "Annotations (AD v2)" %}} **Note:** AD Annotations v2 was introduced in Datadog Agent version 7.36 to simplify integration configuration. For previous versions of the Datadog Agent, use AD Annotations v1. @@ -84,7 +84,7 @@ spec: ``` {{% /tab %}} -{{% tab "Kubernetes (AD v1)" %}} +{{% tab "Annotations (AD v1)" %}} ```yaml # (...) @@ -108,6 +108,35 @@ spec: - name: '' ``` +{{% /tab %}} +{{% tab "DatadogInstrumentation CRD" %}} + +Use a `DatadogInstrumentation` custom resource to configure an OpenMetrics check without adding pod annotations. For more information, see [Configure Autodiscovery with DatadogInstrumentation CRD][17]. + +```yaml +apiVersion: datadoghq.com/v1alpha1 +kind: DatadogInstrumentation +metadata: + name: example-cr + namespace: +spec: + targetRef: + apiVersion: apps/v1 + kind: Deployment + name: + config: + checks: + - integration: openmetrics + containerName: + instances: + - openmetrics_endpoint: "http://%%host%%:%%port%%/" + namespace: "" + metrics: + - "": "" +``` + +[17]: /containers/guide/configure-autodiscovery-with-the-datadoginstrumentation-crd/ + {{% /tab %}} {{< /tabs >}} @@ -115,7 +144,9 @@ With the following configuration placeholder values: | Placeholder | Description | |------------------------------------------|----------------------------------------------------------------------------------------------------| -| `` | Matches the name of the container that exposes the metrics. | +| `` | Namespace that contains the target workload and the `DatadogInstrumentation` resource. | +| `` | Name of the workload targeted by the `DatadogInstrumentation` resource. | +| `` | Matches the name of the container that exposes the metrics. | | `` | URL path for the metrics served by the container, in Prometheus format. | | `` | Set namespace to be prefixed to every metric when viewed in Datadog. | | `` | Prometheus metrics key to be fetched from the Prometheus endpoint. | @@ -200,6 +231,43 @@ For a full list of available parameters for instances, including `namespace` and # (...) ``` + {{% /tab %}} + {{% tab "DatadogInstrumentation CRD" %}} + +
+ + This configuration requires Datadog Agent and Cluster Agent v7.82 or later. Enable the controller with Datadog Operator v1.29+, or Datadog Helm chart v3.236.0+. For setup instructions, see [Configure Autodiscovery with DatadogInstrumentation CRD][17]. + +
+ + The example `prometheus.yaml` file defines the same check as a pod annotation. Remove that annotation because annotations take precedence over `DatadogInstrumentation` resources. Save the following resource as `prometheus-instrumentation.yaml`: + + ```yaml + apiVersion: datadoghq.com/v1alpha1 + kind: DatadogInstrumentation + metadata: + name: prometheus-example + namespace: + spec: + targetRef: + apiVersion: apps/v1 + kind: Deployment + name: prometheus-example + config: + checks: + - integration: openmetrics + containerName: prometheus-example + instances: + - openmetrics_endpoint: "http://%%host%%:%%port%%/metrics" + namespace: "documentation_example_kubernetes" + metrics: + - promhttp_metric_handler_requests: "handler.requests" + - promhttp_metric_handler_requests_in_flight: "handler.requests.in_flight" + - "go_memory.*" + ``` + + [17]: /containers/guide/configure-autodiscovery-with-the-datadoginstrumentation-crd/ + {{% /tab %}} {{< /tabs >}} @@ -209,6 +277,12 @@ For a full list of available parameters for instances, including `namespace` and kubectl create -f prometheus.yaml ``` + If you use a `DatadogInstrumentation` resource, apply it after creating the Deployment: + + ```shell + kubectl apply -f prometheus-instrumentation.yaml + ``` + 3. Go into your [Fleet Automation][16] page and filter for the `openmetrics` integration to view detailed information about the status of your checks. 4. Go into your [Metric summary][12] page to see the metrics collected from this example pod. This configuration will collect the metric `promhttp_metric_handler_requests`, `promhttp_metric_handler_requests_in_flight`, and all exposed metrics starting with `go_memory`. diff --git a/hugo/content/en/data_observability/integration_overhead.md b/hugo/content/en/data_observability/integration_overhead.md new file mode 100644 index 00000000000..b32315c6eea --- /dev/null +++ b/hugo/content/en/data_observability/integration_overhead.md @@ -0,0 +1,143 @@ +--- +title: Data Observability Integration Overhead +description: "Understand the compute overhead Data Observability adds when monitoring data quality and jobs, and how to control it." +further_reading: + - link: "/data_observability/" + tag: "Documentation" + text: "Data Observability Overview" + - link: "/data_observability/quality_monitoring/" + tag: "Documentation" + text: "Quality Monitoring" + - link: "/data_observability/jobs_monitoring/databricks/" + tag: "Documentation" + text: "Jobs Monitoring for Databricks" + - link: "/monitors/types/data_observability/" + tag: "Documentation" + text: "Data Observability Monitors" + - link: "/tracing/troubleshooting/agent_apm_resource_usage/" + tag: "Documentation" + text: "APM Agent resource usage" +--- + +## Overview + +Data Observability monitors your data through two products, each with a different overhead profile: + +- **Quality Monitoring** evaluates data-quality metrics (such as freshness, row count, and column statistics) on a schedule. Depending on the warehouse and metric, an evaluation either reads table metadata or runs a SQL query against your data, so its cost is measured in **warehouse compute** (for example, Snowflake credits, Databricks DBUs, or BigQuery bytes scanned). +- **Jobs Monitoring** observes the performance of your jobs by running the **Datadog Agent** on your compute (for example, Databricks or Spark clusters). The Agent shares a small amount of the CPU and memory you already provision for your workloads. + +This page describes both overhead sources and how to control them. Actual cost depends heavily on your environment: warehouse size, the amount of data scanned, how often monitors run, and warehouse auto-stop settings. This page focuses on what consumes resources, not a single benchmark number. + +## Quality Monitoring overhead + +A Data Observability monitor evaluates its metric on a fixed schedule that you choose: **hourly** or **daily**. Each time a monitor runs, Data Observability collects the metric value, either by reading table metadata or by running a query against your data. How each metric is collected depends on the warehouse. + +{{< tabs >}} +{{% tab "Snowflake" %}} + +On Snowflake, **row count** and **table freshness** are read from table metadata rather than by scanning the table. Datadog reads the `ROW_COUNT` and `LAST_ALTERED` columns from `INFORMATION_SCHEMA.TABLES`, and batches many tables in a database into a single query. This reads metadata only and does not scan table data. However, querying `INFORMATION_SCHEMA` requires a running warehouse, so it uses a small, roughly fixed amount of warehouse compute per batch, regardless of table size. + +**Column metrics** (Nullness, Uniqueness, Cardinality, Percent Zero, Percent Negative, Min, Max, Mean, Sum, Standard Deviation, and column-level freshness) and **Custom SQL** run as `SELECT` queries against your tables and are billed as normal warehouse usage. Column metrics on the same table that share the same filter and grouping are combined into a single query. + +{{% /tab %}} +{{% tab "Databricks" %}} + +On Databricks, every metric is collected by running a SQL statement on the SQL warehouse you connect for Quality Monitoring. There is no separate no-cost metadata layer for row count or freshness; these values are computed by querying the warehouse. As a result, each evaluation requires that SQL warehouse to be active and consumes DBUs while it runs. + +| Metric | Statement run on the SQL warehouse | Notes | +|---|---|---| +| **Row count** | `SELECT COUNT(1) FROM ` | An aggregate query against the table. The data actually scanned depends on table size and Delta optimizations such as data skipping and statistics. | +| **Table freshness** (base table) | `SELECT timestamp FROM (DESCRIBE HISTORY
LIMIT 1)` | A lightweight metadata command—scans little data, but still runs on the warehouse, so the warehouse must be active. | +| **Table freshness** (materialized view) | `DESCRIBE TABLE EXTENDED
` | Lightweight metadata command. | +| **Table freshness** (standard view) | *(no query)* | Views have no freshness query and add no overhead; use column-level freshness instead. | +| **Column metrics** (Nullness, Uniqueness, Cardinality, Percent Zero, Percent Negative, Min, Max, Mean, Sum, Standard Deviation, column freshness) | Aggregate `SELECT` over the column | An aggregate query against the table. Column metrics on the same table that share the same filter and grouping are combined into a single query. | +| **Custom SQL** | Your query, run as written | Cost is whatever your query costs to run. | + +{{% /tab %}} +{{% tab "BigQuery" %}} + +On BigQuery, **row count** and **table freshness** are read through BigQuery's table metadata API (equivalent to a `tables.get` call). No query runs and no bytes are scanned, so these checks incur no BigQuery query cost. + +**Column metrics** (Nullness, Uniqueness, Cardinality, Percent Zero, Percent Negative, Min, Max, Mean, Sum, Standard Deviation, and column-level freshness) and **Custom SQL** run as BigQuery SQL against your tables and are billed by the data they process—bytes scanned under on-demand pricing, or slot time under capacity pricing. Column metrics on the same table that share the same filter and grouping are combined into a single query. + +{{% /tab %}} +{{< /tabs >}} + +### What drives the cost + +Warehouse compute consumed by Quality Monitoring scales with: + +- **Cadence**: an hourly monitor reruns its query 24 times as often as a daily monitor. +- **Number of distinct queries**: cost scales with the number of distinct *(table, filter, grouping)* combinations being monitored, not the raw number of metrics. Multiple column metrics on the same table are batched into one query. +- **Data scanned per query**: column-statistic queries (and Custom SQL) are aggregates that scan table data, so larger tables and partitions cost more on every warehouse. Row count scans the table only on Databricks (`COUNT`); on Snowflake and BigQuery it is a metadata read that does not grow with table size. Freshness checks are lightweight everywhere: metadata reads on Snowflake and BigQuery, and metadata commands on Databricks. +- **Warehouse warm time**: on warehouse-based platforms (Snowflake, Databricks), the dominant factor on most bills is how long your warehouse stays running. Frequent checks against a warehouse with a long idle timeout keep it warm and accrue cost even between queries. BigQuery on-demand is serverless and bills only by bytes scanned, so it has no warm-time cost. + +Data Observability runs these queries with bounded concurrency and a per-query timeout. A backlog of monitors does not flood your warehouse with unbounded parallel queries. + +### Reducing Quality Monitoring overhead + +- **Choose daily over hourly** for metrics that do not need hourly resolution. +- **Monitor the tables and columns that matter.** Cost scales with the number of distinct queries; focus on critical tables rather than monitoring everything. +- **Add a `WHERE` clause** to scope a monitor to recent partitions or a relevant data segment, reducing the data scanned. +- **Group column metrics on the same table** so they batch into a single query. +- **On Snowflake and Databricks, use a dedicated, right-sized warehouse with an aggressive auto-stop** so it shuts down promptly between checks. This is usually the most impactful optimization. +- **Prefer table freshness on base tables** where it is a metadata read or lightweight command rather than a full aggregate scan. + +## Jobs Monitoring overhead + +Jobs Monitoring collects telemetry in one of two ways, each with a different overhead profile: + +- **Datadog Agent**: for Spark jobs on Databricks, Amazon EMR, Google Dataproc, and Kubernetes, you install the Datadog Agent on your compute. Its footprint is described in this section. +- **OpenLineage events**: for Apache Airflow, dbt, and custom pipelines, you run an open source OpenLineage integration in your own environment, which emits events to Datadog. See [OpenLineage-based integrations](#openlineage-based-integrations). + +On Databricks **classic** clusters (all-purpose or job clusters), the Agent is installed on the cluster nodes through an init script. On **serverless** compute, no Agent installation is required. + +### What runs on the cluster + +- The **Datadog Agent** and the Java APM tracer run as processes on the cluster nodes (the driver and the executors). +- The Spark integration runs **in-process** as a Spark listener: it reacts to Spark scheduler events (job, stage, and task callbacks) to build traces and spans. It does not poll your data or run any queries against your warehouse. +- The Agent collects Spark performance metrics and cluster system metrics, and optionally tails driver and worker logs. + +### Footprint + +The Agent is a lightweight process that shares the CPU and memory you already provision for your workloads. It does not add separate, Datadog-provisioned compute to classic clusters. + +Jobs Monitoring traces are coarse-grained. The Spark integration emits one span per application, job, stage, SQL execution, and streaming micro-batch, plus one span for each *failed* task. Successful tasks are aggregated into stage-level metrics instead of emitting individual spans. As a result, trace volume scales with a job's number of stages and jobs, not its task count or data volume. Trace throughput therefore stays low for typical jobs. The larger contributors to the Agent's footprint are Spark metric collection and, if enabled, log collection. For the Datadog SDK's resource profile, see [APM Agent resource usage][1]. + +The cluster Agent issues no queries against your warehouse, so it adds no warehouse cost on its own. + +### Reducing Jobs Monitoring overhead + +- **Disable log collection** when you do not need driver and worker logs (`DRIVER_LOGS_ENABLED` / `WORKER_LOGS_ENABLED`), or filter logs with `DD_LOGS_CONFIG_PROCESSING_RULES`. Log collection is the main tunable contributor to footprint and ingestion volume. + +### Databricks cost data + +Jobs Monitoring can surface the DBU cost of your Databricks jobs. This cost data is read from Datadog's own cost metrics; collecting it does not add queries to your monitored clusters. Populating Databricks cost requires the Datadog Databricks cost integration, which reads from Databricks system tables through a SQL warehouse you grant access to. For the required permissions, see the [Jobs Monitoring for Databricks setup][2]. + +### OpenLineage-based integrations + +Apache Airflow, dbt, and custom pipelines are monitored without the Datadog Agent. Instead, an open source [OpenLineage][3] integration emits lineage events to Datadog. These components are maintained by the OpenLineage and Apache Airflow projects, and their configuration and performance are documented in their respective project documentation. The overhead is the integration's, not the Datadog Agent's. + +These integrations capture run, job, and dataset metadata and emit events at run lifecycle points. The cost is proportional to the number of runs, tasks, and the metadata collected, not to your data volume. + +- **Airflow**: the [`apache-airflow-providers-openlineage`][4] provider runs in your Airflow schedulers and workers and emits an event at task and DAG lifecycle points. Its [configuration reference][5] documents options that affect overhead, such as selectively enabling OpenLineage and limiting collected metadata. +- **dbt**: for dbt Core, the [`openlineage-dbt`][6] wrapper (`dbt-ol`) follows dbt's structured logs and emits events as the run progresses. Because it reads logs rather than instrumenting execution, it does not affect dbt's performance. dbt Cloud sends job-run events to Datadog through a webhook, with no component running in your environment. +- **Custom pipelines**: you emit events yourself with the OpenLineage client or a raw HTTP call, so the overhead is whatever your emitting code does. + +For setup and the Datadog-optimized transport, see [Custom Jobs using OpenLineage][7]. See the OpenLineage documentation for the full set of tuning and overhead controls. + +## Estimating your actual costs + +The behaviors described on this page are environment-dependent. Actual cost depends on your warehouse size and pricing model, the data scanned, and how often monitors run. On warehouse-based platforms, it also depends on your auto-stop configuration. To estimate costs, validate against your own usage: your warehouse's query history or billing views, or Datadog Cloud Cost Management. + +[1]: /tracing/troubleshooting/agent_apm_resource_usage/ +[2]: /data_observability/jobs_monitoring/databricks/ +[3]: https://openlineage.io/docs/integrations/about +[4]: https://airflow.apache.org/docs/apache-airflow-providers-openlineage/stable/ +[5]: https://airflow.apache.org/docs/apache-airflow-providers-openlineage/stable/configurations-ref.html +[6]: https://openlineage.io/docs/integrations/dbt +[7]: /data_observability/jobs_monitoring/openlineage/ + +## Further reading + +{{< partial name="whats-next/whats-next.html" >}} diff --git a/hugo/content/en/data_security/data_retention_periods.md b/hugo/content/en/data_security/data_retention_periods.md index da09942f78d..abfd219377c 100644 --- a/hugo/content/en/data_security/data_retention_periods.md +++ b/hugo/content/en/data_security/data_retention_periods.md @@ -116,6 +116,7 @@ attributes: - product: Log Management data_type: | - **Logs**: Determined by customer plan + - **Sensitive Data Scanner example logs**: 3 days7 days - product: Metrics data_type: | - **Tags and values**: 15 months diff --git a/hugo/content/en/dd_e2e/cdocs/components/stepper_customizable.md b/hugo/content/en/dd_e2e/cdocs/components/stepper_customizable.md new file mode 100644 index 00000000000..fde847bd033 --- /dev/null +++ b/hugo/content/en/dd_e2e/cdocs/components/stepper_customizable.md @@ -0,0 +1,184 @@ +--- +title: Stepper test (customizable page) +draft: true +private: true +--- +

Programming Language

Database

Programming Language

+
JavaScriptPythonRubyGoJava

Database

+
PostgresMySQLMongoDB

Overview

This is a test page used to verify stepper scroll behavior on a customizable page. Because the page defines content_filters, it renders the sticky Cdocs filter bar below the header. When you navigate between steps, the new step title must scroll clear of both the header and the sticky filter bar.

The first step is intentionally long so that advancing to the next step forces a scroll, letting you confirm the title lands below the sticky region.

Stepper component

Install the database

Run the following command to install FakeDB:

curl -fsSL https://fakedb.example.com/install.sh | bash
+

After the installation completes, verify that FakeDB is running:

fakedb --version
+

System requirements

Before you install FakeDB, make sure your system meets the following requirements:

  • Operating system: Linux (kernel 4.15+), macOS 12+, or Windows 10+
  • CPU: x86_64 or ARM64
  • Memory: At least 2 GB of available RAM
  • Disk space: At least 500 MB of free disk space for the binary and initial data directory
  • Network: Outbound access to fakedb.example.com on port 443 during installation

What the installer does

The one-line installer performs the following steps:

  1. Downloads the latest stable FakeDB binary for your platform
  2. Verifies the download signature using GPG
  3. Copies the binary to /usr/local/bin/fakedb
  4. Creates the default data directory at ~/.fakedb/data
  5. Writes a default configuration file to ~/.fakedb/fakedb.conf
  6. Registers FakeDB as a systemd service (Linux) or launchd agent (macOS)

Manual installation

If you prefer to install FakeDB without running the one-line installer, download the binary directly:

curl -fsSL https://releases.fakedb.example.com/v2.4.1/fakedb-linux-amd64.tar.gz -o fakedb.tar.gz
+tar -xzf fakedb.tar.gz
+sudo mv fakedb /usr/local/bin/fakedb
+sudo chmod +x /usr/local/bin/fakedb
+

Verify the installation:

fakedb --version
+# Expected output: fakedb version 2.4.1 (build 20240315)
+

Troubleshooting installation issues

Permission denied when running the installer

If you see a Permission denied error, run the installer with sudo:

sudo bash -c "$(curl -fsSL https://fakedb.example.com/install.sh)"
+

GPG verification failed

If GPG verification fails, your keyring may be outdated. Update it:

gpg --keyserver hkps://keys.openpgp.org --recv-keys FAKEDB_KEY_ID
+

Port already in use

If port 5432 is already in use by another process, identify the process:

sudo lsof -i :5432
+

You can then either stop the conflicting process or configure FakeDB to use a different port in the next step.

Configure the database

Create a configuration file for FakeDB:

fakedb:
+  host: localhost
+  port: 5432
+  database: mydb
+

Connect to the database

Start the FakeDB service and open a connection:

fakedb start
+fakedb connect --host localhost --port 5432 --database mydb
+

You're all set. Happy databasing!

+
\ No newline at end of file diff --git a/hugo/content/en/getting_started/containers/autodiscovery.md b/hugo/content/en/getting_started/containers/autodiscovery.md index b8e43f0d95a..2d1d084d4bc 100644 --- a/hugo/content/en/getting_started/containers/autodiscovery.md +++ b/hugo/content/en/getting_started/containers/autodiscovery.md @@ -9,6 +9,9 @@ further_reading: - link: "/agent/kubernetes/integrations/" tag: "Documentation" text: "Create and load an Autodiscovery Integration Template" +- link: "/containers/guide/configure-autodiscovery-with-the-datadoginstrumentation-crd/" + tag: "Documentation" + text: "Configure Autodiscovery with DatadogInstrumentation CRD" - link: "/agent/guide/ad_identifiers/" tag: "Documentation" text: "Match a container with the corresponding Integration Template" @@ -140,6 +143,8 @@ Once Autodiscovery is enabled, the Datadog Agent automatically attempts Autodisc You can define an integration template in multiple forms: as Kubernetes pod annotations, Docker labels, a configuration file mounted within the Agent, a ConfigMap, and key-value stores. See the [Autodiscovery Integration Templates][4] documentation for further details. +On Kubernetes, you can also configure checks for a specific workload through the `DatadogInstrumentation` custom resource, instead of pod annotations. See [Configure Autodiscovery with DatadogInstrumentation CRD][5]. + ### Notes If you are using Autodiscovery and an application is deployed on a new node, you may experience some delay in seeing metrics appear in Datadog. When you switch to a new node, it takes time for the Datadog Agent to collect metadata from your application. @@ -152,3 +157,4 @@ If you are using Autodiscovery and an application is deployed on a new node, you [2]: /agent/faq/template_variables/ [3]: /agent/faq/auto_conf/ [4]: /agent/kubernetes/integrations/ +[5]: /containers/guide/configure-autodiscovery-with-the-datadoginstrumentation-crd/ diff --git a/hugo/content/en/getting_started/logs/_index.md b/hugo/content/en/getting_started/logs/_index.md index 376743405c1..d15f23c395b 100644 --- a/hugo/content/en/getting_started/logs/_index.md +++ b/hugo/content/en/getting_started/logs/_index.md @@ -55,8 +55,6 @@ To begin collecting logs from a server: 2. Collecting logs is **not enabled** by default in the Datadog Agent. To enable log collection, set `logs_enabled` to `true` in your `datadog.yaml` file. - {{< agent-config type="log collection configuration" filename="datadog.yaml" collapsible="true">}} - 3. Restart the [Datadog Agent][7]. 4. Follow the integration [activation steps][8] or the custom files log collection steps on the Datadog site. diff --git a/hugo/content/en/gpu_monitoring/setup.md b/hugo/content/en/gpu_monitoring/setup.md index 896fc506d9c..e3513549725 100644 --- a/hugo/content/en/gpu_monitoring/setup.md +++ b/hugo/content/en/gpu_monitoring/setup.md @@ -27,7 +27,7 @@ To begin using Datadog's GPU Monitoring, your environment must meet the followin #### Minimum version requirements - **Datadog Agent**: v7.80 - - (Preferred version: >v7.80). Datadog advises against using v7.79.x as there is a bug impacting metric values that is not present in other Agent versions. + - (Preferred version: 7.81.3). Datadog advises against using v7.82.0 to avoid a bug that causes unexpected kernel panics. - **Operating system**: Linux - **Linux kernel**: 5.8 and above - **NVIDIA driver**: version 450.51 diff --git a/hugo/content/en/incident_response/incident_management/guides/_index.md b/hugo/content/en/incident_response/incident_management/guides/_index.md index c71a6ec19c1..e148824d90e 100644 --- a/hugo/content/en/incident_response/incident_management/guides/_index.md +++ b/hugo/content/en/incident_response/incident_management/guides/_index.md @@ -20,6 +20,7 @@ cascade: {{< header-list header="General guides" >}} {{< nextlink href="incident_response/incident_management/guides/test_incidents" >}}Using test incidents for training and testing{{< /nextlink >}} + {{< nextlink href="incident_response/incident_management/guides/manage_with_terraform" >}}Manage Incident Management with Terraform{{< /nextlink >}} {{< /header-list >}} diff --git a/hugo/content/en/incident_response/incident_management/guides/manage_with_terraform.md b/hugo/content/en/incident_response/incident_management/guides/manage_with_terraform.md new file mode 100644 index 00000000000..9ac13a391c2 --- /dev/null +++ b/hugo/content/en/incident_response/incident_management/guides/manage_with_terraform.md @@ -0,0 +1,162 @@ +--- +title: Manage Incident Management with Terraform +description: Use Terraform to manage Incident Management configuration, including incident types, property fields, responder types, notification rules, postmortem templates, and notification templates. +disable_toc: false +further_reading: +- link: "/incident_response/incident_management/" + tag: "Documentation" + text: "Learn more about Incident Management" +- link: "/incident_response/incident_management/guides/test_incidents/" + tag: "Documentation" + text: "Using test incidents for training and testing" +- link: "https://registry.terraform.io/providers/DataDog/datadog/latest/docs" + tag: "Documentation" + text: "Terraform provider for Datadog" +--- + +## Overview + +You can use Terraform to manage your Incident Management configuration through the Datadog API. This guide covers the Incident Management resources available in the [Terraform registry][1] and links to the corresponding Datadog documentation for each. + +Configuring incident types, fields, roles, and notification rules by hand in the UI works well for a handful of teams. It becomes harder to scale as your organization grows, for example, when standardizing configuration across hundreds of teams or migrating from another incident management tool. Terraform lets you define this configuration as code, so you can create and update it programmatically and keep it consistent across your organization. + +You can also [import][2] your existing incident type, notification, and postmortem template configurations into Terraform, and reference existing configurations as Terraform [data sources][3]. + +### What you can manage with Terraform + +| Resource | Purpose | +| --- | --- | +| [Incident types](#incident-types) (`datadog_incident_type`) | The category of incident (for example, "Security Incident" or "Customer Impacting"). Also includes the settings on the [Information][19] page, such as private incidents and incident deletion. Anchors everything else in this table. | +| [Property fields](#property-fields) (`datadog_incident_user_defined_field`) | Structured data responders fill out on an incident, such as root cause or affected region. Also used to configure severity and status levels on the [Information][19] page. | +| [Responder types](#responder-types) (`datadog_incident_user_defined_role`) | Custom roles beyond the built-in Incident Commander and Responder. | +| [Notification rules](#notification-rules) (`datadog_incident_notification_rule`) | Rules that decide when and who gets notified as incidents change. | +| [Postmortem templates](#postmortem-templates) (`datadog_incident_postmortem_template`) | Where and how a postmortem document is generated for an incident type. | +| [Notification templates](#notification-templates) (`datadog_incident_notification_template`) | Reusable message content for incident notifications. | + +## Set up the Datadog Terraform provider + +If you haven't already, configure the [Datadog Terraform provider][4] to interact with Datadog APIs through a Terraform configuration. + +## Incident types + +Incident types let you apply different settings, fields, roles, and notification behavior to different classes of incidents, such as security incidents versus customer-impacting incidents. Every other resource on this page is scoped to an incident type, so define your incident types first. Use the `configuration` block on the [incident type resource][6] to create incident types and set the toggles found on the [Information][19] page, such as incident deletion, [test incidents][7], and [private incidents][8]. Severity and status levels, also found on the [Information][19] page, are configured with the [incident user-defined field resource][10]. + +To learn how this works in Datadog, see [Incident Types][5]. + +## Property fields + +Property fields let responders capture structured data on an incident, for example, root cause or affected region. Use the [incident user-defined field resource][10] to create property fields and scope them to an incident type. + +To learn how this works in Datadog, see [Property Fields][9]. + +## Responder types + +Responder types define the roles people can be assigned during an incident. Examples include Incident Commander or a custom role like Comms Lead. Use the [incident user-defined role resource][12] to create custom responder types. Scope each one to an incident type. + +To learn how this works in Datadog, see [Responder Types][11]. + +## Notification rules + +Notification rules determine when a notification fires, who it's sent to, and which template it uses. Use the [incident notification rule resource][16] to create rules based on triggers such as incident creation or a saved change. Conditions on a rule can include severity or affected services. + +To learn how this works in Datadog, see [Notification Rules][15]. + +## Postmortem templates + +Postmortem templates control where a postmortem document is generated for an incident type. Templates standardize the content a postmortem writer is expected to populate by defining specific sections and headers in the document. Use the [incident postmortem template resource][18] to configure this per incident type. + +To learn how this works in Datadog, see [Postmortem Templates][17]. + +## Notification templates + +Notification templates define reusable message content for incident notifications. Use the [incident notification template resource][14] to create templates scoped to an incident type. + +To learn how this works in Datadog, see [Notification Templates][13]. + +## Full configuration example + +The following example combines several of these resources into one configuration: + +- A `datadog_incident_type` with a `configuration` block that disables incident deletion and enables test incidents +- A `datadog_incident_user_defined_field` and `datadog_incident_user_defined_role`, both scoped to that type +- A `datadog_incident_notification_template` +- A `datadog_incident_notification_rule` that uses the template + +{{< code-block lang="terraform" >}} +resource "datadog_incident_type" "customer_impacting" { + name = "Customer Impacting" + description = "Incidents that impact customers" + configuration = { + private_incidents = false + private_incidents_by_default = false + allow_workflows = true + allow_incident_deletion = false + editable_timestamps = false + test_incidents = true + create_message = "" + slug_source = "default" + } +} + +resource "datadog_incident_user_defined_field" "root_cause" { + name = "root_cause" + type = "dropdown" + incident_type = datadog_incident_type.customer_impacting.id + + valid_value { + display_name = "Service Bug" + value = "service_bug" + } +} + +resource "datadog_incident_user_defined_role" "tech_lead" { + name = "Tech Lead" + incident_type = datadog_incident_type.customer_impacting.id +} + +resource "datadog_incident_notification_template" "sev1_alert" { + name = "SEV-1 Customer Impact Template" + subject = "SEV-1 Incident: {{incident.title}}" + category = "alert" + incident_type = datadog_incident_type.customer_impacting.id + content = "SEV-1 declared: {{incident.title}}. Status: {{incident.status}}." +} + +resource "datadog_incident_notification_rule" "sev1_sev2_created" { + enabled = true + trigger = "incident_created_trigger" + visibility = "organization" + handles = ["@pagerduty-on-call"] + incident_type = datadog_incident_type.customer_impacting.id + notification_template = datadog_incident_notification_template.sev1_alert.id + + conditions { + field = "severity" + values = ["SEV-1", "SEV-2"] + } +} +{{< /code-block >}} + +## Further reading + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://registry.terraform.io/providers/DataDog/datadog/latest/docs +[2]: https://developer.hashicorp.com/terraform/cli/import +[3]: https://developer.hashicorp.com/terraform/language/data-sources +[4]: /integrations/terraform/ +[5]: /incident_response/incident_management/setup_and_configuration/#incident-types +[6]: https://registry.terraform.io/providers/DataDog/datadog/latest/docs/resources/incident_type +[7]: /incident_response/incident_management/guides/test_incidents/ +[8]: /incident_response/incident_management/setup_and_configuration/information/#private-incidents-incident-visibility +[9]: /incident_response/incident_management/setup_and_configuration/property_fields/ +[10]: https://registry.terraform.io/providers/DataDog/datadog/latest/docs/resources/incident_user_defined_field +[11]: /incident_response/incident_management/setup_and_configuration/responder_types/ +[12]: https://registry.terraform.io/providers/DataDog/datadog/latest/docs/resources/incident_user_defined_role +[13]: /incident_response/incident_management/setup_and_configuration/templates/#messages +[14]: https://registry.terraform.io/providers/DataDog/datadog/latest/docs/resources/incident_notification_template +[15]: /incident_response/incident_management/setup_and_configuration/notification_rules/ +[16]: https://registry.terraform.io/providers/DataDog/datadog/latest/docs/resources/incident_notification_rule +[17]: /incident_response/incident_management/setup_and_configuration/templates/#postmortems +[18]: https://registry.terraform.io/providers/DataDog/datadog/latest/docs/resources/incident_postmortem_template +[19]: /incident_response/incident_management/setup_and_configuration/information/ diff --git a/hugo/content/en/llm_observability/instrumentation/sdk.md b/hugo/content/en/llm_observability/instrumentation/sdk.md index bcbf583379f..a508b2b379b 100644 --- a/hugo/content/en/llm_observability/instrumentation/sdk.md +++ b/hugo/content/en/llm_observability/instrumentation/sdk.md @@ -1525,11 +1525,11 @@ The `annotationOptions` object can contain the following: `inputData` : optional - _JSON serializable type or list of objects_ -
Either a JSON serializable type (for non-LLM spans) or a list of dictionaries with this format: `{role: "...", content: "...", audioParts: [...]}` (for LLM spans). `audioParts` is an optional list of audio objects for multimodal (voice) spans, each with a required `mimeType` and a base64-encoded `content` string. **Note**: Embedding spans are a special case and require a string or an object (or a list of objects) with this format: `{text: "..."}`. +
Either a JSON serializable type (for non-LLM spans) or a list of dictionaries with this format: `{role: "...", content: "...", audioParts: [...], imageParts: [...]}` (for LLM spans). `audioParts` and `imageParts` are optional lists of media objects for multimodal spans, each with a required `mimeType` and exactly one of `content` (base64-encoded media, carried inline) or `attachmentKey`. **Note**: Embedding spans are a special case and require a string or an object (or a list of objects) with this format: `{text: "..."}`. `outputData` : optional - _JSON serializable type or list of objects_ -
Either a JSON serializable type (for non-LLM spans) or a list of objects with this format: `{role: "...", content: "...", audioParts: [...]}` (for LLM spans). `audioParts` is an optional list of audio objects for multimodal (voice) spans, each with a required `mimeType` and a base64-encoded `content` string. **Note**: Retrieval spans are a special case and require a string or an object (or a list of objects) with this format: `{text: "...", name: "...", score: number, id: "..."}`. +
Either a JSON serializable type (for non-LLM spans) or a list of objects with this format: `{role: "...", content: "...", audioParts: [...], imageParts: [...]}` (for LLM spans). `audioParts` and `imageParts` are optional lists of media objects for multimodal spans, each with a required `mimeType` and exactly one of `content` (base64-encoded media, carried inline) or `attachmentKey`. **Note**: Retrieval spans are a special case and require a string or an object (or a list of objects) with this format: `{text: "...", name: "...", score: number, id: "..."}`. `metadata` : optional - _object_ @@ -1622,9 +1622,31 @@ function voiceTurn (userAudioBytes) { } voiceTurn = llmobs.wrap({ kind: 'llm', modelName: 'gpt-audio', modelProvider: 'openai' }, voiceTurn) +function describeImage (imageBytes) { + const resp = ... // multimodal (vision) llm call here + llmobs.annotate({ + inputData: [ + { + role: "user", + content: "What is in this image?", + imageParts: [{ mimeType: "image/png", content: imageBytes.toString("base64") }] + } + ], + outputData: [{ role: "assistant", content: "The image shows a golden retriever puppy." }] + }) + return resp +} +describeImage = llmobs.wrap({ kind: 'llm', modelName: 'gpt-4o', modelProvider: 'openai' }, describeImage) + {{< /code-block >}} -For OpenAI audio chat completions, `audioParts` are also captured automatically by [Datadog's LLM integrations](/llm_observability/instrumentation/auto_instrumentation/)—no manual annotation required. +Messages annotated with `audioParts` or `imageParts` render as inline audio players and images in the trace view: + +{{< img src="llm_observability/instrumentation/audio_example.png" alt="An LLM span in the Agent Observability trace view. The input message from the USER shows an inline audio player with the transcript 'Hey, how are you?', and the output ASSISTANT message shows a 'Click to play audio' control with the transcript 'Hey! I'm doing great, thanks for asking. How about you?'." style="width:100%;" >}} + +{{< img src="llm_observability/instrumentation/image_example.png" alt="An LLM span in the Agent Observability trace view. The input USER message shows the prompt 'What is in this image?' with an inline photo of a black puppy, and the output ASSISTANT message describes it as a black Labrador Retriever puppy on a wooden surface." style="width:100%;" >}} + +For OpenAI audio chat completions, `audioParts` are also captured automatically by [Datadog's LLM integrations](/llm_observability/instrumentation/auto_instrumentation/)—no manual annotation required. Unlike `audioParts`, `imageParts` are not currently captured automatically and must be annotated manually; automatic capture is planned for a future release. {{% /tab %}} {{% tab "Java" %}} diff --git a/hugo/content/en/logs/log_configuration/processors/grok_parser.md b/hugo/content/en/logs/log_configuration/processors/grok_parser.md index ab37a2903fd..4d9f4746db9 100644 --- a/hugo/content/en/logs/log_configuration/processors/grok_parser.md +++ b/hugo/content/en/logs/log_configuration/processors/grok_parser.md @@ -15,7 +15,7 @@ further_reading: Create custom grok rules to parse the full message or a specific attribute of your raw event. As a best practice, limit your grok parser to 10 parsing rules. For more information on Grok syntax and parsing rules, see [Parsing][1]. -{{< img src="/logs/processing/processors/define_parsing_rules_syntax_suggestions.png" alt="Grok parser syntax suggestions in the UI" style="width:90%;" >}} +{{< img src="/logs/processing/processors/ai-grok-rules.png" alt="Grok parser configuration" style="width:90%;" >}} ## Use cases @@ -28,16 +28,15 @@ After creating a grok rule, the parser can write the IP address, user, request t Define the Grok processor on the [{{< ui >}}Pipelines{{< /ui >}} page][2]. To configure Grok parsing rules: -1. Click {{< ui >}}Parse my logs{{< /ui >}} to automatically generate a set of three parsing rules based on the logs flowing through the pipeline. - **Note**: This feature requires that the corresponding logs are indexed and actively flowing in. You can temporarily deactivate or sample down exclusion filters to allow the feature to detect logs. +1. Click {{< ui >}}Add Grok Parser{{< /ui >}} to open a new parser configuration. +1. {{< ui >}}Log Samples{{< /ui >}}: Log samples are automatically pulled into the Log Samples section. You can also add more log samples (up to 10 total, 5000 characters each). + **Note**: The sample logs are pulled from the five highest-volume log patterns matching your pipeline filter. 1. {{< ui >}}Log Samples{{< /ui >}}: Add up to five sample logs (up to 5000 characters each) to test your parsing rules. -1. {{< ui >}}Define parsing rules{{< /ui >}}: Write your parsing rules in the rule editor. As you define rules, the Grok parser provides syntax assistance: - - **Matcher suggestions**: Type a rule name followed by `%{`. A dropdown appears with available matchers (such as `word`, `integer`, `ip`, `date`). Select a matcher from the list to insert it into your rule.
- ``` - MyParsingRule %{ - ``` - - **Filter suggestions**: When adding a filter with `:`, a dropdown shows compatible filters for the selected matcher. -1. {{< ui >}}Test your rules{{< /ui >}}: Select a sample by clicking on it to trigger its evaluation against the parsing rule and display the result at the bottom of the screen. All samples show a status (`match` or `no match`), which highlights if one of the parsing rules of the grok parser matches the sample. +1. {{< ui >}}Define parsing rules{{< /ui >}}: Click {{< ui >}}Auto parsing{{< /ui >}} to generate rules that match your samples. + {{< site-region region="gov,gov2" >}} +
Auto parsing is not available for your selected Datadog site ({{< region-param key="dd_site_name" >}}).
+ {{< /site-region >}} +1. {{< ui >}}Test your rules{{< /ui >}}: Click a sample to trigger its evaluation against the parsing rule and display the result on the right of the screen. All samples show a status (`match` or `no match`), which highlights if one of the parsing rules of the grok parser matches the sample. ## Before and after state of logs diff --git a/hugo/content/en/mcp_server/setup.md b/hugo/content/en/mcp_server/setup.md index 0a5970e5e65..5de80393b48 100644 --- a/hugo/content/en/mcp_server/setup.md +++ b/hugo/content/en/mcp_server/setup.md @@ -133,9 +133,9 @@ Selected endpoint ({{< region-param key="dd_site_name" >}}): {{< region-pa url = "{{< region-param key="mcp_server_endpoint" >}}" - To enable [product-specific tools](#toolsets), include the `toolsets` query parameter at the end of the endpoint URL. For example, this URL enables _only_ APM and Agent Observability tools (use `toolsets=all` to enable all generally available toolsets, best for clients that support tool filtering): + To enable [product-specific tools](#toolsets), define a header `X-Datadog-MCP-Toolsets` in the `config.toml` file on the line after the URL. For example, this header enables _only_ APM and Agent Observability tools (use `X-Datadog-MCP-Toolsets = "all"` to enable all generally available toolsets, best for clients that support tool filtering): - 
{{< region-param key="mcp_server_endpoint" >}}?toolsets=apm,llmobs
+ 
http_headers = { "X-Datadog-MCP-Toolsets" = "apm,llmobs" }
1. Log in to the Datadog MCP Server: @@ -626,6 +626,8 @@ Selected endpoint ({{< region-param key="dd_site_name" >}}): {{< region-pa The Datadog MCP Server supports _toolsets_, which allow you to use only the [MCP tools][49] you need, saving valuable context window space. To use a toolset, include the `toolsets` query parameter in the endpoint URL when connecting to the MCP Server ([remote authentication](#authentication) only). Use `toolsets=all` to enable all generally available toolsets at once. +
For the Codex CLI, use the X-Datadog-MCP-Toolsets header described in the Codex setup instructions, not the query parameter described here.
+ {{< site-region region="us,us3,us5,eu,ap1,ap2,uk1" >}} For example, based on your selected [Datadog site][17] ({{< region-param key="dd_site_name" >}}): diff --git a/hugo/content/en/observability_pipelines/destinations/datadog_metrics.md b/hugo/content/en/observability_pipelines/destinations/datadog_metrics.md index f0686e2c809..c59c02c8c15 100644 --- a/hugo/content/en/observability_pipelines/destinations/datadog_metrics.md +++ b/hugo/content/en/observability_pipelines/destinations/datadog_metrics.md @@ -44,6 +44,15 @@ There are no secret identifiers for this destination. {{% /tab %}} {{< /tabs >}} +## AWS PrivateLink + +To send metrics from Observability Pipelines to Datadog using AWS PrivateLink, see [Connect to Datadog over AWS PrivateLink][3] for setup instructions. The two endpoints you need to set up are: + +- Metrics: {{< region-param key=metrics_endpoint_private_link code="true" >}} +- Remote Configuration: {{< region-param key=remote_config_endpoint_private_link code="true" >}} + +**Note**: The `obpipeline-intake.datadoghq.com` endpoint is used for Live Capture and is not available as a PrivateLink endpoint. + ## How the destination works ### Metrics aggregation @@ -58,15 +67,6 @@ A batch of events is flushed when one of these parameters is met. See [Destinati |----------------|-------------------|---------------------| | 100,000 | None | 2 | -## AWS PrivateLink - -To send metrics from Observability Pipelines to Datadog using AWS PrivateLink, see [Connect to Datadog over AWS PrivateLink][3] for setup instructions. The two endpoints you need to set up are: - -- Metrics: {{< region-param key=metrics_endpoint_private_link code="true" >}} -- Remote Configuration: {{< region-param key=remote_config_endpoint_private_link code="true" >}} - -**Note**: The `obpipeline-intake.datadoghq.com` endpoint is used for Live Capture and is not available as a PrivateLink endpoint. - [1]: https://app.datadoghq.com/observability-pipelines [2]: https://docs.datadoghq.com/observability_pipelines/destinations/#event-batching [3]: https://docs.datadoghq.com/agent/guide/private-link/?tab=crossregionprivatelinkendpoints diff --git a/hugo/content/en/observability_pipelines/sources/splunk_tcp.md b/hugo/content/en/observability_pipelines/sources/splunk_tcp.md index f42b6180289..84e56e3d448 100644 --- a/hugo/content/en/observability_pipelines/sources/splunk_tcp.md +++ b/hugo/content/en/observability_pipelines/sources/splunk_tcp.md @@ -25,7 +25,9 @@ Set up this source when you [set up a pipeline][1]. You can set up a pipeline in After you select the Splunk TCP source in the pipeline UI, enter the identifier for your Splunk TCP address. If you leave it blank, the [default](#secret-defaults) is used. -{{% observability_pipelines/secrets_env_var_note %}} +**Notes**: +- By default, the Splunk TCP source doesn't limit the size of an event. To prevent unbounded memory consumption, such as from malformed connections or connections that remain open indefinitely, use the environment variable `DD_OP_SPLUNK_TCP_MAX_FRAME_LENGTH` to set a maximum frame length in bytes. +- If you enter secret identifiers and then choose to use environment variables, the environment variable is the identifier entered and prepended with `DD_OP_`. For example, if you entered PASSWORD_1 for a password identifier, the environment variable for that password is `DD_OP_PASSWORD_1`. ### Optional TLS settings diff --git a/hugo/content/en/real_user_monitoring/operations_monitoring.md b/hugo/content/en/real_user_monitoring/operations_monitoring.md index a42a63cb3fe..862a8a8f45a 100644 --- a/hugo/content/en/real_user_monitoring/operations_monitoring.md +++ b/hugo/content/en/real_user_monitoring/operations_monitoring.md @@ -1,6 +1,6 @@ --- title: Operations Monitoring -description: Monitor critical technical operations within user-facing features to identify exactly when and why users fail to complete key workflows. +description: Monitor critical technical operations within user-facing journeys to identify exactly when and why users fail to complete key workflows. further_reading: - link: '/monitors/create/types/real_user_monitoring/' tag: 'Documentation' @@ -11,26 +11,29 @@ further_reading: {{< img src="/real_user_monitoring/operations_monitoring/operations-monitoring-overview-1.png" alt="Operations tab under RUM > Performance Monitoring" style="width:100%;" >}} -In Datadog RUM, a feature represents a major user-facing area of your application like checkout, login, or search. Each feature includes operations, which are the critical technical steps that make the experience work. +In Datadog Real User Monitoring (RUM), a [journey][9] represents a major user-facing area of your application like checkout, login, or search. Each journey includes operations, which are the critical technical steps that make the experience work. -- Business teams use **features** to track and improve user conversion. +- Business teams use **journeys** to track and improve user conversion. - Engineering teams use **operations** to monitor and minimize technical failures that impact key user moments. -For example, the checkout experience of an e-commerce platform is a feature. Within it, operations might include entering payment details, saving a payment method, and completing a purchase. After the SDK has been instrumented, Datadog RUM measures each operation's performance, including execution volume, completion rate, and failure rate. Measuring operations' health enables you to identify exactly when and why users may not convert in your feature. +You can create operations with the RUM SDK APIs, directly in Datadog, or programmatically with the Datadog API. -The following table shows additional example features and their associated feature operations by industry. +For example, the checkout experience of an ecommerce platform is a journey. Within it, operations might include entering payment details, saving a payment method, and completing a purchase. After you create operations, Datadog RUM measures each operation's performance, including execution volume, completion rate, and failure rate. Measuring operations' health enables you to identify exactly when and why users may not convert in your journey. -| Industry | Feature | Feature Operations | + +The following table shows additional example journeys and their associated journey operations by industry. + +| Industry | Journey | Journey operations | |----------------|----------|----------------------------------------------------------------------------------------------------------------------------------| | Social network | Profile | Users can load their profile
Users can upload a picture
Users can update their status | -| E-Commerce | Checkout | Users can enter payment details
Users can save their payment method
Users can pay | +| Ecommerce | Checkout | Users can enter payment details
Users can save their payment method
Users can pay | | Streaming | Search | Users can find results for their search
Users can load the description of a title
Users can start watching the trailer | | CRM | Quote | Users can start a new quote
Users can add line items to the quote
Users can send a quote to recipients | ## Prerequisites -- [RUM without Limits][9] must be enabled in your organization. -- Make sure you've downloaded a supported Datadog RUM SDK version with client-side APIs to define operations: +- [RUM without Limits][11] must be enabled in your organization. +- To create operations with SDK APIs, download a supported Datadog RUM SDK version with client-side APIs to define operations: - [Browser (6.20.0)][1] - [Android (3.1.0)][2] - [iOS (3.1.0)][3] @@ -40,7 +43,7 @@ The following table shows additional example features and their associated featu - [React Native (3.0.0)][5] - [Roku (1.4.0)][6] -## Setup +## Create operations with the SDK APIs Use the SDK APIs to define your operations. @@ -136,11 +139,6 @@ Every started operation must have a stop. Use `succeedOperation` to stop an oper {{% tab "Browser" %}} ```javascript -DD_RUM.init({ -..., -enableExperimentalFeatures: ["feature_operation_vital"], // this flag needs to be enabled for the API to work -}) - succeedFeatureOperation: ( name: string, options?: { @@ -308,15 +306,64 @@ To use operations on Flutter Web, enable the `feature_operation_vital` experimen {{< /tabs >}} ### Parallelization -You may have cases where users are starting several feature operations in parallel. To individually track them, use the `operationKey` defined when calling `startOperation`. You must reuse the same `operationKey` later in other APIs, for example when calling `succeedOperation`. +You may have cases where users are starting several journey operations in parallel. To individually track them, use the `operationKey` defined when calling `startOperation`. You must reuse the same `operationKey` later in other APIs, for example when calling `succeedOperation`.
Operations that have been started but not explicitly stopped are automatically terminated when the RUM session expires. Those are marked as failed, with @operation.failure_reason:timeout.

If an operation stop API was called that was not started in the first place, the stop event emitted by the SDK is dropped upon ingestion.
+## Create operations from Datadog + +You can create an operation from either the operations catalog or a journey's details report: + +- **Operations catalog**: Navigate to {{< ui >}}RUM{{< /ui >}} > {{< ui >}}Operations{{< /ui >}}, then click {{< ui >}}New Operation{{< /ui >}} +- **Journey Monitoring**: Navigate to {{< ui >}}Digital Experience{{< /ui >}} > {{< ui >}}Journey Monitoring{{< /ui >}}, select a journey, navigate to its {{< ui >}}Details Report{{< /ui >}}, then click {{< ui >}}New Operation{{< /ui >}} + +{{< img src="/real_user_monitoring/operations_monitoring/operations-monitoring-web-ui.png" alt="Page for creating Operations from the Datadog UI" style="width:100%;" >}} + +
Each RUM application supports up to 1000 operations created from Datadog through the UI or API. There is no organization-wide limit on operations created directly in Datadog.
+ +### Step 1: Enter operation details and select the operation category + +Select the operation's RUM application and enter a display name. You may optionally add a description to the operation. + +Select the operation's **category** to determine the RUM event types compatible with the start, success, and failure conditions. + +| Operation category | Summary | Supported event types | +|----------------------------------|----------|----------------------------------------------------------------------------------------------------------------------| +| Component loading | Measure how long a user-initiated action takes to complete | Start: Action
Success: Resource or custom action
Failure: Resource, error, or custom action | +| Form submission | Measure how long a form submit or mutation takes to succeed | Start: Action
Success: Resource, view, or custom action
Failure: Resource, error, or custom action | +| Page or screen load | Measure how long a page or screen takes to load and display data | Start: View
Success: Resource, view, or custom action
Failure: Resource, error, or custom action | +| Page or screen navigation | Measure how long a navigation from one page or screen to another takes to succeed | Start: Action or view
Success: Resource, view, or custom action
Failure: Resource, error, or custom action | +| Custom | Define a custom operation with any event type combination | Start: Action or view
Success: Resource, view, or custom action
Failure: Resource, error, or custom action | + +### Step 2: Define the start event + +Each operation must have a starting RUM event. Operations can begin with either an action or view event depending on the selected operation category. + +### Step 3: Define the success conditions + +Each operation must have a condition for ending in a success. Operations can end in success with a resource, view, or custom action event, depending on the selected operation category. + +### Step 4: Define the failure conditions + +Each operation must have a condition for ending in a failure: +- **Error** failures can end as a resource, error, or custom action. +- **Abandon** failures can be toggled on in case the user navigates away from the starting view before the operation finishes. + +
Allow up to 15 minutes for metrics to appear in the operations catalog after you create an operation in Datadog through the UI or API.
+ +## Create operations with the Datadog API + +Operations can also be created through the [Datadog API][10]. + +## Edit operations + +In the operations catalog, click the pencil icon to edit an operation. You can edit the description of any operation, regardless of how it was created. Operations created through the UI or API can be fully edited (not just the description). + ## Monitor your availability on Datadog {{< img src="/real_user_monitoring/operations_monitoring/operations-monitoring-catalog-1.png" alt="Operations tab under RUM > Performance Monitoring" style="width:100%;" >}} -After you've configured the SDK APIs, you can monitor your operations by navigating to {{< ui >}}RUM{{< /ui >}} > {{< ui >}}Performance Monitoring{{< /ui >}} > {{< ui >}}Operations{{< /ui >}}. +After you create operations with the RUM SDK APIs, directly in Datadog, or with the Datadog API, monitor them by navigating to {{< ui >}}RUM{{< /ui >}} > {{< ui >}}Performance Monitoring{{< /ui >}} > {{< ui >}}Operations{{< /ui >}}. Datadog groups together all operations with the same name into a catalog. @@ -339,7 +386,7 @@ You can run an agentic investigation on a single operation directly from the Ope ## Configure retention filters -Operations are a new type of event in RUM. Operations are bound to a RUM Session, but can span across multiple RUM Views. Operations can be targeted in retention filters. This allows you to align your retention strategy on features that are cornerstones for your user experiences. For example, you can programmatically keep RUM Sessions that had specific operations fail or are taking longer than desired. +Operations are a new type of event in RUM. Operations are bound to a RUM Session, but can span across multiple RUM Views. Operations can be targeted in [retention filters][12]. This allows you to align your retention strategy on journeys that are cornerstones for your user experiences. For example, you can programmatically keep RUM Sessions that had specific operations fail or are taking longer than desired. {{< img src="/real_user_monitoring/operations_monitoring/operations-monitoring-3-temp.png" alt="Operations tab under RUM > Performance Monitoring" style="width:80%;" >}} @@ -361,8 +408,10 @@ Similarly to metrics, those events come with specific attributes you can use in [3]: https://github.com/DataDog/dd-sdk-ios/releases/tag/3.1.0 [4]: https://github.com/DataDog/dd-sdk-kotlin-multiplatform/releases/tag/1.4.0 [5]: https://github.com/DataDog/dd-sdk-reactnative/releases/tag/3.0.0 - [6]: https://github.com/DataDog/dd-sdk-roku/releases/tag/1.4.0 [7]: https://github.com/DataDog/dd-sdk-flutter/releases/tag/datadog_flutter_plugin%2Fv3.0.0 [8]: /real_user_monitoring/ai_investigations/operation_ai_investigation/ -[9]: /real_user_monitoring/rum_without_limits/ +[9]: /journey_monitoring/ +[10]: /api/latest/rum-operations/ +[11]: /real_user_monitoring/rum_without_limits/ +[12]: /real_user_monitoring/rum_without_limits/retention_filters/ diff --git a/hugo/content/en/real_user_monitoring/ownership_of_views.md b/hugo/content/en/real_user_monitoring/ownership_of_views.md index 9d77e76c6c1..d8b80cdc058 100644 --- a/hugo/content/en/real_user_monitoring/ownership_of_views.md +++ b/hugo/content/en/real_user_monitoring/ownership_of_views.md @@ -18,6 +18,20 @@ Ownership of views lets you see only the RUM metrics and events for the parts of By default, the toggle is enabled, which filters metrics and event data to show only the one coming from views your team owns. If you belong to multiple teams, you can enable or disable specific team filters. The teams that own a view are also listed in the top-right corner of all event side panels. +## Ownership rules + +There are two types of rules to configure ownership of views: + +1. Exact rules, which map one-to-one with a view name +2. Prefix rules, which capture all views that contain the prefix in their name + +{{< img src="/real_user_monitoring/ownership_of_views/ownership-rule-type.png" alt="Side panel displaying the two different types of rules to define ownership of views." >}} + +Every must also have at least one team and one scope defined. Two scope types are supported: +- For the current RUM application across all services +- For a specific service across all applications + + ## Setup
To use this feature, your organization must have teams enabled and configured.
@@ -25,8 +39,9 @@ By default, the toggle is enabled, which filters metrics and event data to show To configure team ownership for your application's views: 1. In Datadog, navigate to the [{{< ui >}}Digital Experience{{< /ui >}} > {{< ui >}}Manage Applications{{< /ui >}}][1] page and select your application. -2. In the left navigation menu, select {{< ui >}}Team Ownership{{< /ui >}}. -3. For each selected view, click {{< ui >}}Edit Teams{{< /ui >}} and select one or more teams. This attributes each view in your application to those teams. +2. In the left navigation menu, select {{< ui >}}Ownership{{< /ui >}}. +3. For each view, click {{< ui >}}Missing Ownership{{< /ui >}} and create a rule for the view. +4. Click on the {{< ui >}}All Rules{{< /ui >}} tab to review all created rules and their associated views. After you associate a view with a team, Datadog automatically attributes new event data to that team. diff --git a/hugo/content/en/security/cloud_security_management/misconfigurations/custom_rules.md b/hugo/content/en/security/cloud_security_management/misconfigurations/custom_rules.md index 43bd03130f3..ce21b859525 100644 --- a/hugo/content/en/security/cloud_security_management/misconfigurations/custom_rules.md +++ b/hugo/content/en/security/cloud_security_management/misconfigurations/custom_rules.md @@ -60,12 +60,10 @@ To create a rule from scratch: The text you enter in {{< ui >}}Say what's happening{{< /ui >}} is displayed in the finding side panel. When you write it as Markdown using the following section headers, each section is shown in a dedicated area of the finding: -| Header | Where it appears in the finding | -|---------------|------------------------------------------------| -| `Description` | **What Happened** | -| `Rationale` | **What Happened** (shown with the description) | -| `Remediation` | **Remediation** section | -| `References` | Shown separately | +| Header | Where it appears in the finding | +|---------------|---------------------------------| +| `Description` | **What Happened** | +| `Remediation` | **Remediation** section | For example: @@ -80,6 +78,7 @@ Describe how to remediate it. Keep the following in mind: - All sections are optional and can appear in any order. A typical message uses only `## Description` and `## Remediation`. +- You can also include a `## Rationale` section. Its content appears within **What Happened**, after the description. - Use level-2 (`##`) headers for each section. Deeper headers (for example, `###`) are treated as sub-points within a section, not as new sections. - Header matching is case-insensitive, but the section names must match exactly (for example, `Remediation`, not `Fix`). - Give each section content. A header immediately followed by another header may not render as expected. diff --git a/hugo/content/en/security/code_security/iast/setup/_index.md b/hugo/content/en/security/code_security/iast/setup/_index.md index f346fcdf1ea..f8279503715 100644 --- a/hugo/content/en/security/code_security/iast/setup/_index.md +++ b/hugo/content/en/security/code_security/iast/setup/_index.md @@ -13,7 +13,9 @@ Before setting up Runtime Code Analysis (IAST), ensure the following prerequisit 1. **Datadog Agent Installation:** The Datadog Agent is installed and configured for your application's operating system or container, cloud, or virtual environment. 2. **Supported SDK:** The Datadog SDK used by your application or service supports Runtime Code Analysis (IAST) capabilities for the language of your application or service. For more details, see the **Compatibility Requirements** section below. -
The Datadog Agent and SDK are the only requirements for IAST. APM tracing and Infrastructure Monitoring are not required; IAST reports findings independently of both. To disable APM or Infrastructure Monitoring, see Disable APM and Infrastructure Monitoring.
+
The Datadog Agent and SDK are the only requirements for IAST. APM tracing and Infrastructure Monitoring are not required; IAST reports findings independently of both. To disable APM or Infrastructure Monitoring, see Disable APM and Infrastructure Monitoring. +
+Even if APM is disabled, APM intake costs are still incurred for ingesting data, such as security traces and spans, to support IAST.
## Using Datadog SDKs diff --git a/hugo/content/en/security/sensitive_data_scanner/guide/investigate_sensitive_data_findings.md b/hugo/content/en/security/sensitive_data_scanner/guide/investigate_sensitive_data_findings.md index 03364afb8b2..d5242442f1e 100644 --- a/hugo/content/en/security/sensitive_data_scanner/guide/investigate_sensitive_data_findings.md +++ b/hugo/content/en/security/sensitive_data_scanner/guide/investigate_sensitive_data_findings.md @@ -50,7 +50,7 @@ To investigate a log finding: 3. At the top of the panel, check {{< ui >}}First Detected{{< /ui >}} and {{< ui >}}Last Detected{{< /ui >}} to understand how long the exposure has been active. 4. In the summary section, review {{< ui >}}Match State{{< /ui >}}, {{< ui >}}Service{{< /ui >}}, {{< ui >}}Environment{{< /ui >}}, and {{< ui >}}Total matches{{< /ui >}} to understand the scope of the exposure. 5. Review the {{< ui >}}Logs Pattern{{< /ui >}} to understand the format of the log line where sensitive data was detected. -6. In the {{< ui >}}Example Logs{{< /ui >}} section, review up to 5 representative examples of affected logs. When an example log expires it is replaced with the next matching event. Click {{< ui >}}Show log{{< /ui >}} to expand an example and inspect its log message, fields, and attributes inline. By default, example logs are stored for 3 days and are accessible to all users with the Data Scanner Read permission. To store these representative logs for a different period, contact [Support][1]. +6. In the {{< ui >}}Example Logs{{< /ui >}} section, review up to 5 representative examples of affected logs. When an example log expires it is replaced with the next matching event. Click {{< ui >}}Show log{{< /ui >}} to expand an example and inspect its log message, fields, and attributes inline. By default, example logs are stored for 3 days7 days and are accessible to all users with the Data Scanner Read permission. To store these representative logs for a different period, contact [Support][1]. 7. Review {{< ui >}}Matches Trend{{< /ui >}} to see how match volume has changed over the past week. Use {{< ui >}}Related Access and Configuration Events{{< /ui >}} to check whether recent access events or changes to the scanning group or scanning rule line up with changes in match volume. Additionally, you can: diff --git a/hugo/content/en/session_replay/_index.md b/hugo/content/en/session_replay/_index.md index 3d8b2b0524a..9880bec07bc 100644 --- a/hugo/content/en/session_replay/_index.md +++ b/hugo/content/en/session_replay/_index.md @@ -89,7 +89,7 @@ To find replays that need your attention, use the {{< ui >}}All mentions to me{{ ## Extend data retention -By default, Session Replay data is retained for 30 days. +By default, Session Replay data is retained for 30 days. To set the default retention period for all Session Replays to longer than 30 days, contact your account team. To extend Session Replay data retention to 15 months, you can enable {{< ui >}}Extended Retention{{< /ui >}} on individual session replays. These sessions must be non-active (the user has completed their experience). diff --git a/hugo/content/en/synthetics/browser_tests/_index.md b/hugo/content/en/synthetics/browser_tests/_index.md index d94f699e786..7a73aff9543 100644 --- a/hugo/content/en/synthetics/browser_tests/_index.md +++ b/hugo/content/en/synthetics/browser_tests/_index.md @@ -67,7 +67,7 @@ You may create a test using one of the following options: **Note**: You can also use the [Continuous Testing Tunnel][2] to trigger tests on your local development setup or in your CI/CD pipeline to test internal environments. - 7. Set the {{< ui >}}test frequency{{< /ui >}}: The intervals vary from every five minutes to once per week. To request one-minute frequency, [contact Support][3]. + 7. Set the {{< ui >}}test frequency{{< /ui >}}: The intervals vary from every one minute to once per week. 8. Click {{< ui >}}Save & Edit Recording{{< /ui >}} to submit your Browser Test. ### Locations diff --git a/hugo/data/api/v2/full_spec.yaml b/hugo/data/api/v2/full_spec.yaml index 441596194a8..e50069237f6 100644 --- a/hugo/data/api/v2/full_spec.yaml +++ b/hugo/data/api/v2/full_spec.yaml @@ -1759,23 +1759,6 @@ components: required: true schema: $ref: "#/components/schemas/RumPermanentRetentionFilterID" - RumRateLimitScopeIDParameter: - description: |- - The identifier of the scope the rate limit configuration applies to. - For the `application` scope, this is the RUM application ID. - in: path - name: scope_id - required: true - schema: - example: cd73a516-a481-4af5-8352-9b577465c77b - type: string - RumRateLimitScopeTypeParameter: - description: The type of scope the rate limit configuration applies to. - in: path - name: scope_type - required: true - schema: - $ref: "#/components/schemas/RumRateLimitScopeType" RumRetentionFilterIDParameter: description: Retention filter ID. in: path @@ -39541,35 +39524,11 @@ components: description: The operating system version. example: "Ubuntu 20.04" type: string - otel_collector_deployment_types: - description: OpenTelemetry collector deployment types associated with the agent. - items: - description: An OpenTelemetry collector deployment type. - type: string - type: array - otel_collector_distributions: - description: OpenTelemetry collector distributions associated with the agent. - items: - description: An OpenTelemetry collector distribution. - type: string - type: array - otel_collector_versions: - description: List of OpenTelemetry collector versions (if applicable). - items: - description: An OpenTelemetry collector version string. - type: string - type: array otel_collectors: description: OpenTelemetry collectors associated with the agent (if applicable). items: $ref: "#/components/schemas/FleetOtelCollector" type: array - otel_resource_attributes: - description: OpenTelemetry resource attributes reported by the agent. - items: - description: An OpenTelemetry resource attribute. - type: string - type: array pod_name: description: Kubernetes pod name (if applicable). type: string @@ -44910,10 +44869,6 @@ components: description: A human-readable description of what the control detects. example: "Identifies API keys that have not been used within your specified time threshold, helping reduce security risks from dormant credentials." type: string - detection_frequency: - description: How often detections are evaluated for the control. - example: "daily" - type: string detection_parameters: $ref: "#/components/schemas/GovernanceControlParametersMap" nullable: true @@ -44983,7 +44938,6 @@ components: - type - priority - detection_parameters - - detection_frequency - mitigation_type - mitigation_parameters - created_at @@ -45342,17 +45296,14 @@ components: - label type: object GovernanceControlSupportedValueArray: - description: The supported values for an enumerated parameter. + description: The supported values for an enumerated parameter. `null` when the parameter is not an enumerated type. items: $ref: "#/components/schemas/GovernanceControlSupportedValue" + nullable: true type: array GovernanceControlUpdateAttributes: description: The attributes of a governance control that can be updated. Only the attributes present in the request are modified. properties: - detection_frequency: - description: How often detections should be evaluated for the control. - example: "daily" - type: string detection_parameters: $ref: "#/components/schemas/GovernanceControlParametersMap" nullable: true @@ -90476,179 +90427,6 @@ components: $ref: "#/components/schemas/RumPermanentRetentionFilterData" type: array type: object - RumRateLimitAdaptiveConfig: - description: The configuration used when `mode` is `adaptive`. - properties: - max_retention_rate: - description: The maximum fraction of sessions to retain, in the range `(0, 1]`. - example: 0.5 - exclusiveMinimum: true - format: double - maximum: 1 - minimum: 0 - type: number - required: - - max_retention_rate - type: object - RumRateLimitConfigAttributes: - description: The RUM rate limit configuration properties. - properties: - adaptive: - $ref: "#/components/schemas/RumRateLimitAdaptiveConfig" - custom: - $ref: "#/components/schemas/RumRateLimitCustomConfig" - mode: - $ref: "#/components/schemas/RumRateLimitMode" - org_id: - description: The ID of the organization the rate limit configuration belongs to. - example: 2 - format: int64 - type: integer - updated_at: - description: The date the rate limit configuration was last updated. - example: "2026-03-04T15:37:54.951447Z" - type: string - updated_by: - description: The handle of the user who last updated the rate limit configuration. - example: test@example.com - type: string - required: - - mode - - org_id - type: object - RumRateLimitConfigData: - description: The RUM rate limit configuration object. - properties: - attributes: - $ref: "#/components/schemas/RumRateLimitConfigAttributes" - id: - description: The identifier of the scope the rate limit configuration applies to. - example: cd73a516-a481-4af5-8352-9b577465c77b - type: string - type: - $ref: "#/components/schemas/RumRateLimitConfigType" - required: - - id - - type - - attributes - type: object - RumRateLimitConfigResponse: - description: The RUM rate limit configuration response. - properties: - data: - $ref: "#/components/schemas/RumRateLimitConfigData" - required: - - data - type: object - RumRateLimitConfigType: - default: rum_rate_limit_config - description: The type of the resource, always `rum_rate_limit_config`. - enum: - - rum_rate_limit_config - example: rum_rate_limit_config - type: string - x-enum-varnames: ["RUM_RATE_LIMIT_CONFIG"] - RumRateLimitConfigUpdateAttributes: - description: The RUM rate limit configuration properties to create or update. - properties: - adaptive: - $ref: "#/components/schemas/RumRateLimitAdaptiveConfig" - custom: - $ref: "#/components/schemas/RumRateLimitCustomConfig" - mode: - $ref: "#/components/schemas/RumRateLimitMode" - required: - - mode - type: object - RumRateLimitConfigUpdateData: - description: The RUM rate limit configuration to create or update. - properties: - attributes: - $ref: "#/components/schemas/RumRateLimitConfigUpdateAttributes" - id: - description: |- - The identifier of the scope the rate limit configuration applies to. - Must match `scope_id` in the path. - example: cd73a516-a481-4af5-8352-9b577465c77b - type: string - type: - $ref: "#/components/schemas/RumRateLimitConfigType" - required: - - id - - type - - attributes - type: object - RumRateLimitConfigUpdateRequest: - description: The body of a request to create or update a RUM rate limit configuration. - properties: - data: - $ref: "#/components/schemas/RumRateLimitConfigUpdateData" - required: - - data - type: object - RumRateLimitCustomConfig: - description: The configuration used when `mode` is `custom`. - properties: - daily_reset_time: - description: The time of day when the daily quota resets, in `HH:MM` 24-hour format. - example: "08:00" - pattern: "^([01]\\d|2[0-3]):[0-5]\\d$" - type: string - daily_reset_timezone: - description: The timezone offset used for the daily reset time, in `±HH:MM` format. - example: "+09:00" - pattern: "^[+-](0\\d|1[0-4]):[0-5]\\d$" - type: string - quota_reached_action: - $ref: "#/components/schemas/RumRateLimitQuotaReachedAction" - session_limit: - description: The maximum number of sessions allowed within the window. - example: 1000000 - format: int64 - minimum: 1 - type: integer - window_type: - $ref: "#/components/schemas/RumRateLimitWindowType" - required: - - window_type - - session_limit - - daily_reset_time - - daily_reset_timezone - - quota_reached_action - type: object - RumRateLimitMode: - description: |- - The rate limit mode. `custom` enforces a fixed session limit, while - `adaptive` dynamically adjusts retention. - enum: - - custom - - adaptive - example: custom - type: string - x-enum-varnames: ["CUSTOM", "ADAPTIVE"] - RumRateLimitQuotaReachedAction: - description: The action to take when the session quota is reached. - enum: - - stop - - slowdown - example: stop - type: string - x-enum-varnames: ["STOP", "SLOWDOWN"] - RumRateLimitScopeType: - default: application - description: The type of scope the rate limit configuration applies to. - enum: - - application - example: application - type: string - x-enum-varnames: ["APPLICATION"] - RumRateLimitWindowType: - description: The window type over which the session limit is enforced. - enum: - - daily - example: daily - type: string - x-enum-varnames: ["DAILY"] RumRetentionFilterAttributes: description: The object describing attributes of a RUM retention filter. properties: @@ -146612,7 +146390,6 @@ paths: created_at: "2024-01-15T09:30:00Z" created_by: "11111111-2222-3333-4444-555555555555" description: "Identifies API keys that have not been used within your specified time threshold, helping reduce security risks from dormant credentials." - detection_frequency: "daily" detection_parameters: api_key_threshold: 30 insights: [] @@ -146642,7 +146419,7 @@ paths: display_name: "Unused API Key Threshold" name: "api_key_threshold" required: false - supported_values: [] + supported_values: type: "integer" type: "Proactive" id: "unused_api_keys" @@ -146713,7 +146490,6 @@ paths: created_at: "2024-01-15T09:30:00Z" created_by: "11111111-2222-3333-4444-555555555555" description: "Identifies API keys that have not been used within your specified time threshold, helping reduce security risks from dormant credentials." - detection_frequency: "daily" detection_parameters: api_key_threshold: 30 insights: [] @@ -146733,7 +146509,7 @@ paths: display_name: "Unused API Key Threshold" name: "api_key_threshold" required: false - supported_values: [] + supported_values: type: "integer" type: "Proactive" id: "unused_api_keys" @@ -146825,7 +146601,6 @@ paths: created_at: "2024-01-15T09:30:00Z" created_by: "11111111-2222-3333-4444-555555555555" description: "Identifies API keys that have not been used within your specified time threshold, helping reduce security risks from dormant credentials." - detection_frequency: "daily" detection_parameters: api_key_threshold: 60 insights: [] @@ -184928,145 +184703,6 @@ paths: - Rum Metrics x-codegen-request-body-name: body x-menu-order: 4 - /api/v2/rum/config/rate-limit/{scope_type}/{scope_id}: - delete: - description: Delete the RUM rate limit configuration for a given scope. - operationId: DeleteRumRateLimitConfig - parameters: - - $ref: "#/components/parameters/RumRateLimitScopeTypeParameter" - - $ref: "#/components/parameters/RumRateLimitScopeIDParameter" - responses: - "204": - description: No Content - "400": - $ref: "#/components/responses/BadRequestResponse" - "403": - $ref: "#/components/responses/NotAuthorizedResponse" - "404": - $ref: "#/components/responses/NotFoundResponse" - "429": - $ref: "#/components/responses/TooManyRequestsResponse" - summary: Delete a RUM rate limit configuration - tags: - - Rum Rate Limit - x-menu-order: 3 - x-unstable: |- - **Note**: This endpoint is in preview and is subject to change. - If you have any feedback, contact [Datadog support](https://docs.datadoghq.com/help/). - get: - description: Get the RUM rate limit configuration for a given scope. - operationId: GetRumRateLimitConfig - parameters: - - $ref: "#/components/parameters/RumRateLimitScopeTypeParameter" - - $ref: "#/components/parameters/RumRateLimitScopeIDParameter" - responses: - "200": - content: - application/json: - examples: - default: - value: - data: - attributes: - custom: - daily_reset_time: "08:00" - daily_reset_timezone: "+09:00" - quota_reached_action: stop - session_limit: 1000000 - window_type: daily - mode: custom - org_id: 2 - updated_at: "2026-03-04T15:37:54.951447Z" - updated_by: test@example.com - id: cd73a516-a481-4af5-8352-9b577465c77b - type: rum_rate_limit_config - schema: - $ref: "#/components/schemas/RumRateLimitConfigResponse" - description: OK - "400": - $ref: "#/components/responses/BadRequestResponse" - "403": - $ref: "#/components/responses/NotAuthorizedResponse" - "404": - $ref: "#/components/responses/NotFoundResponse" - "429": - $ref: "#/components/responses/TooManyRequestsResponse" - summary: Get a RUM rate limit configuration - tags: - - Rum Rate Limit - x-menu-order: 1 - x-unstable: |- - **Note**: This endpoint is in preview and is subject to change. - If you have any feedback, contact [Datadog support](https://docs.datadoghq.com/help/). - put: - description: |- - Create or update the RUM rate limit configuration for a given scope. - Returns the rate limit configuration object when the request is successful. - operationId: UpdateRumRateLimitConfig - parameters: - - $ref: "#/components/parameters/RumRateLimitScopeTypeParameter" - - $ref: "#/components/parameters/RumRateLimitScopeIDParameter" - requestBody: - content: - application/json: - examples: - default: - value: - data: - attributes: - custom: - daily_reset_time: "08:00" - daily_reset_timezone: "+09:00" - quota_reached_action: stop - session_limit: 1000000 - window_type: daily - mode: custom - id: cd73a516-a481-4af5-8352-9b577465c77b - type: rum_rate_limit_config - schema: - $ref: "#/components/schemas/RumRateLimitConfigUpdateRequest" - description: The definition of the RUM rate limit configuration to create or update. - required: true - responses: - "200": - content: - application/json: - examples: - default: - value: - data: - attributes: - custom: - daily_reset_time: "08:00" - daily_reset_timezone: "+09:00" - quota_reached_action: stop - session_limit: 1000000 - window_type: daily - mode: custom - org_id: 2 - updated_at: "2026-03-04T21:52:53.526022Z" - updated_by: test@example.com - id: cd73a516-a481-4af5-8352-9b577465c77b - type: rum_rate_limit_config - schema: - $ref: "#/components/schemas/RumRateLimitConfigResponse" - description: OK - "400": - $ref: "#/components/responses/BadRequestResponse" - "403": - $ref: "#/components/responses/NotAuthorizedResponse" - "404": - $ref: "#/components/responses/NotFoundResponse" - "429": - $ref: "#/components/responses/TooManyRequestsResponse" - summary: Create or update a RUM rate limit configuration - tags: - - Rum Rate Limit - x-codegen-request-body-name: body - x-menu-order: 2 - x-unstable: |- - **Note**: This endpoint is in preview and is subject to change. - If you have any feedback, contact [Datadog support](https://docs.datadoghq.com/help/). /api/v2/rum/events: get: description: |- @@ -216983,9 +216619,6 @@ tags: description: Find out more at url: https://docs.datadoghq.com/real_user_monitoring/platform/generate_metrics/ name: Rum Metrics - - description: |- - Manage RUM rate limit configurations for your organization's RUM applications. - name: Rum Rate Limit - description: Manage heatmap snapshots for RUM replay sessions. Create, update, delete, and retrieve snapshots to visualize user interactions on specific views. name: Rum Replay Heatmaps - description: Create and manage playlists of RUM replay sessions. Organize, categorize, and share collections of replay sessions for analysis and collaboration. diff --git a/hugo/data/api/v2/translate_actions.json b/hugo/data/api/v2/translate_actions.json index 33058aff922..69d10c86d51 100644 --- a/hugo/data/api/v2/translate_actions.json +++ b/hugo/data/api/v2/translate_actions.json @@ -5033,20 +5033,6 @@ "request_description": "New definition of the RUM-based metric.", "request_schema_description": "The new RUM-based metric body." }, - "DeleteRumRateLimitConfig": { - "description": "Delete the RUM rate limit configuration for a given scope.", - "summary": "Delete a RUM rate limit configuration" - }, - "GetRumRateLimitConfig": { - "description": "Get the RUM rate limit configuration for a given scope.", - "summary": "Get a RUM rate limit configuration" - }, - "UpdateRumRateLimitConfig": { - "description": "Create or update the RUM rate limit configuration for a given scope.\nReturns the rate limit configuration object when the request is successful.", - "summary": "Create or update a RUM rate limit configuration", - "request_description": "The definition of the RUM rate limit configuration to create or update.", - "request_schema_description": "The body of a request to create or update a RUM rate limit configuration." - }, "ListRUMEvents": { "description": "List endpoint returns events that match a RUM search query.\n[Results are paginated][1].\n\nUse this endpoint to see your latest RUM events.\n\n[1]: https://docs.datadoghq.com/logs/guide/collect-multiple-logs-with-pagination", "summary": "Get a list of RUM events" diff --git a/hugo/data/api/v2/translate_tags.json b/hugo/data/api/v2/translate_tags.json index a144bf419c2..c2e95e6f08d 100644 --- a/hugo/data/api/v2/translate_tags.json +++ b/hugo/data/api/v2/translate_tags.json @@ -411,10 +411,6 @@ "name": "Rum Metrics", "description": "Manage configuration of [RUM-based metrics](https://app.datadoghq.com/rum/generate-metrics) for your organization." }, - "rum-rate-limit": { - "name": "Rum Rate Limit", - "description": "Manage RUM rate limit configurations for your organization's RUM applications." - }, "rum-replay-heatmaps": { "name": "Rum Replay Heatmaps", "description": "Manage heatmap snapshots for RUM replay sessions. Create, update, delete, and retrieve snapshots to visualize user interactions on specific views." diff --git a/hugo/layouts/partials/page-edit.html b/hugo/layouts/partials/page-edit.html index 30b84d86f65..a9083c6a2c8 100644 --- a/hugo/layouts/partials/page-edit.html +++ b/hugo/layouts/partials/page-edit.html @@ -38,7 +38,7 @@ {{/* Not in integrations edit existing docs file */}} {{ with $ctx.File }} - {{ $editLink = ( printf "https://github.com/DataDog/documentation/edit/master/content/%s/%s/" $ctx.Page.Lang $ctx.File.Path ) }} + {{ $editLink = ( printf "https://github.com/DataDog/documentation/edit/master/hugo/content/%s/%s/" $ctx.Page.Lang $ctx.File.Path ) }} {{ partial "page-edit-body.html" (dict "ctx" $ctx "link" $editLink "type" $type) }} {{ end }} diff --git a/hugo/layouts/partials/trace_collection/python/supported_versions.html b/hugo/layouts/partials/trace_collection/python/supported_versions.html index f0c3024ad9c..50c32f83118 100644 --- a/hugo/layouts/partials/trace_collection/python/supported_versions.html +++ b/hugo/layouts/partials/trace_collection/python/supported_versions.html @@ -12,13 +12,13 @@ >=4.0,<5 - + - + diff --git a/hugo/layouts/shortcodes/agent-config.html b/hugo/layouts/shortcodes/agent-config.html index dcc04b69ebc..45ab2be49ab 100644 --- a/hugo/layouts/shortcodes/agent-config.html +++ b/hugo/layouts/shortcodes/agent-config.html @@ -1,39 +1 @@ -{{ if not (.Get "type") }} - {{ errorf "Agent Config shortcode error: Missing value for param 'type': %s" .Position }} -{{ end }} - -{{ $agent_config_data := $.Site.Data.agent_config | default (dict) }} -{{ $type := (.Get ("type")) | lower }} -{{ $filename := .Get "filename" | default "Code example" }} -{{ $collapsible := .Get "collapsible" }} -{{ $disable_copy := .Get "disable_copy" }} -{{ $config_data := index $agent_config_data $type }} -{{ $config_data_string := trim $config_data "\n" }} - -{{ if eq $config_data nil }} - {{ if eq $.Site.Params.environment "development" }} - {{ warnf "Agent Config shortcode error: given 'type' param was not found in Agent config template. Check agent_config_types_list.txt for list of available configuration types." }} - {{ else }} - {{ errorf "Agent Config shortcode error: given 'type' param was not found in Agent config template. Check agent_config_types_list.txt for list of available configuration types." }} - {{ end }} -{{ end }} - -
-
-

{{ $filename }}

- {{ if $collapsible }} -
-
-
-
- {{ end }} -
-
- {{ if ne $disable_copy "true" }} -
- -
- {{ end }} - {{ highlight $config_data_string "yaml" "" }} -
-
+{{/* Temporary no-op for localized pages. Remove this shortcode after localization removes all agent-config calls. */}} diff --git a/hugo/layouts/shortcodes/mdoc/en/sdk/setup/browser.mdoc.md b/hugo/layouts/shortcodes/mdoc/en/sdk/setup/browser.mdoc.md index 6670795bfbd..f39d60483e9 100644 --- a/hugo/layouts/shortcodes/mdoc/en/sdk/setup/browser.mdoc.md +++ b/hugo/layouts/shortcodes/mdoc/en/sdk/setup/browser.mdoc.md @@ -395,7 +395,7 @@ Your application appears as pending on the Applications page until Datadog start [5]: https://app.datadoghq.com/rum/list [6]: https://www.npmjs.com/package/@datadog/browser-rum [7]: https://datadoghq.dev/browser-sdk/interfaces/_datadog_browser-rum.RumInitConfiguration.html -[8]: /real_user_monitoring/application_monitoring/browser +[8]: /real_user_monitoring/application_monitoring/browser/advanced_configuration/#user-tracking-consent [9]: /integrations/content_security_policy_logs/ [10]: /agentic_onboarding/setup/ [11]: /real_user_monitoring/application_monitoring/browser/data_collected/ diff --git a/hugo/local/bin/py/build/configurations/pull_config.yaml b/hugo/local/bin/py/build/configurations/pull_config.yaml index d853aae4942..6798b377e4d 100644 --- a/hugo/local/bin/py/build/configurations/pull_config.yaml +++ b/hugo/local/bin/py/build/configurations/pull_config.yaml @@ -380,13 +380,6 @@ - repo_name: datadog-agent contents: - - action: pull-and-push-file - branch: main - globs: - - "pkg/config/config_template.yaml" - options: - file_name: 'agent_config.yaml' - output_content: false - action: pull-and-push-folder branch: 7.78.x globs: diff --git a/hugo/local/bin/py/build/configurations/pull_config_preview.yaml b/hugo/local/bin/py/build/configurations/pull_config_preview.yaml index 62a49fadcca..9bb09fd2156 100644 --- a/hugo/local/bin/py/build/configurations/pull_config_preview.yaml +++ b/hugo/local/bin/py/build/configurations/pull_config_preview.yaml @@ -381,13 +381,6 @@ - repo_name: datadog-agent contents: - - action: pull-and-push-file - branch: main - globs: - - "pkg/config/config_template.yaml" - options: - file_name: 'agent_config.yaml' - output_content: false - action: pull-and-push-folder branch: 7.78.x globs: diff --git a/hugo/local/bin/py/preview_links.py b/hugo/local/bin/py/preview_links.py index 03ca573f780..f52e9fb7e86 100644 --- a/hugo/local/bin/py/preview_links.py +++ b/hugo/local/bin/py/preview_links.py @@ -12,10 +12,10 @@ args=parser.parse_args() -comment_template = Template(filename='local/bin/py/preview-links-template.mako') +comment_template = Template(filename='hugo/local/bin/py/preview-links-template.mako') -pattern1 = re.compile('content/en/(.*?).md') -pattern2 = re.compile('content/en/glossary/terms/(.*?).md') +pattern1 = re.compile('hugo/content/en/(.*?).md') +pattern2 = re.compile('hugo/content/en/glossary/terms/(.*?).md') # Grab YAML frontmatter from markdown file def grab_glossary_title(filename): @@ -29,9 +29,9 @@ def compile_filename(filename): if pattern2.match(filename): return grab_glossary_title(filename) elif pattern1.match(filename): + filename = filename.split('content/en/', 1)[-1] filename = filename.replace( - 'content/en/', '' - ).replace('_index', '' + '_index', '' ).replace('.mdoc', '' ).replace('.md', '') return filename diff --git a/hugo/scripts/post-migration-cleanup.sh b/hugo/scripts/post-migration-cleanup.sh new file mode 100755 index 00000000000..00b0840ae24 --- /dev/null +++ b/hugo/scripts/post-migration-cleanup.sh @@ -0,0 +1,34 @@ +#!/usr/bin/env bash +# Remove known untracked root-level files left after the Hugo reorganization. + +set -euo pipefail + +repo_root=$(git rev-parse --show-toplevel) +cd "$repo_root" + +if [[ -e Makefile.config || -L Makefile.config ]]; then + if [[ -e hugo/Makefile.config || -L hugo/Makefile.config ]]; then + printf 'Cannot move Makefile.config: hugo/Makefile.config already exists.\n' >&2 + exit 1 + fi + mv Makefile.config hugo/Makefile.config +fi + +rm -rf \ + .hugo_build.lock \ + .yarn \ + _vendor \ + agent_config_types_list.txt \ + content \ + data \ + examples \ + hugpython \ + integrations_data \ + layouts \ + local \ + node_modules \ + playwright-report \ + public \ + resources \ + static \ + test-results diff --git a/hugo/static/images/logs/processing/processors/ai-grok-rules.png b/hugo/static/images/logs/processing/processors/ai-grok-rules.png new file mode 100644 index 00000000000..3b79edc2281 Binary files /dev/null and b/hugo/static/images/logs/processing/processors/ai-grok-rules.png differ diff --git a/hugo/static/images/real_user_monitoring/operations_monitoring/operations-monitoring-web-ui.png b/hugo/static/images/real_user_monitoring/operations_monitoring/operations-monitoring-web-ui.png new file mode 100644 index 00000000000..fccf50accc5 Binary files /dev/null and b/hugo/static/images/real_user_monitoring/operations_monitoring/operations-monitoring-web-ui.png differ diff --git a/hugo/static/images/real_user_monitoring/ownership_of_views/ownership-application-management-2.png b/hugo/static/images/real_user_monitoring/ownership_of_views/ownership-application-management-2.png index aad398c9d00..0e57db73fd4 100644 Binary files a/hugo/static/images/real_user_monitoring/ownership_of_views/ownership-application-management-2.png and b/hugo/static/images/real_user_monitoring/ownership_of_views/ownership-application-management-2.png differ diff --git a/hugo/static/images/real_user_monitoring/ownership_of_views/ownership-rule-type.png b/hugo/static/images/real_user_monitoring/ownership_of_views/ownership-rule-type.png new file mode 100644 index 00000000000..8eb61cb5958 Binary files /dev/null and b/hugo/static/images/real_user_monitoring/ownership_of_views/ownership-rule-type.png differ diff --git a/hugo/static/resources/yaml/data_streams/docker-compose-kafka-demo.yaml b/hugo/static/resources/yaml/data_streams/docker-compose-kafka-demo.yaml index 0883d529cae..2a5533b4a48 100644 --- a/hugo/static/resources/yaml/data_streams/docker-compose-kafka-demo.yaml +++ b/hugo/static/resources/yaml/data_streams/docker-compose-kafka-demo.yaml @@ -8,6 +8,7 @@ # # This starts: # - Kafka (KRaft mode, no ZooKeeper) + Schema Registry +# - Kafka Connect with an instrumented source and sink connector # - Datadog Agent with Kafka Consumer integration # - Producer app (sends orders every 2s, APM + Data Streams enabled) # - Consumer app (processes orders, APM + Data Streams enabled) @@ -67,8 +68,72 @@ services: timeout: 5s retries: 5 + kafka-connect: + image: confluentinc/cp-kafka-connect:7.5.0 + hostname: kafka-connect + depends_on: + kafka: + condition: service_healthy + datadog-agent: + condition: service_started + ports: + - "8083:8083" + environment: + CONNECT_BOOTSTRAP_SERVERS: 'kafka:19092' + CONNECT_REST_ADVERTISED_HOST_NAME: kafka-connect + CONNECT_GROUP_ID: kafka-connect-demo + CONNECT_CONFIG_STORAGE_TOPIC: _connect-configs + CONNECT_CONFIG_STORAGE_REPLICATION_FACTOR: 1 + CONNECT_OFFSET_STORAGE_TOPIC: _connect-offsets + CONNECT_OFFSET_STORAGE_REPLICATION_FACTOR: 1 + CONNECT_STATUS_STORAGE_TOPIC: _connect-status + CONNECT_STATUS_STORAGE_REPLICATION_FACTOR: 1 + CONNECT_KEY_CONVERTER: org.apache.kafka.connect.converters.ByteArrayConverter + CONNECT_VALUE_CONVERTER: org.apache.kafka.connect.converters.ByteArrayConverter + CONNECT_PLUGIN_PATH: /tmp/connect-plugins,/usr/share/java,/usr/share/confluent-hub-components + DD_AGENT_HOST: datadog-agent + DD_TRACE_AGENT_PORT: 8126 + DD_SERVICE: kafka-connect + DD_ENV: demo + DD_VERSION: "7.5.0" + DD_DATA_STREAMS_ENABLED: "true" + KAFKA_OPTS: -javaagent:/tmp/dd-java-agent.jar + command: + - bash + - -c + - | + set -e + curl -L --fail --silent --show-error -o /tmp/dd-java-agent.jar https://dtdg.co/latest-java-tracer + mkdir -p /tmp/connect-plugins + curl -L --fail --silent --show-error \ + -o /tmp/connect-plugins/connect-file.jar \ + https://repo1.maven.org/maven2/org/apache/kafka/connect-file/3.5.0/connect-file-3.5.0.jar + touch /tmp/source-records.txt + /etc/confluent/docker/run & + connect_pid=$$! + trap 'kill "$$connect_pid"; wait "$$connect_pid"' TERM INT + until curl --fail --silent http://localhost:8083/connectors > /dev/null; do sleep 2; done + curl --fail --silent --show-error -X PUT \ + -H 'Content-Type: application/json' \ + http://localhost:8083/connectors/demo-file-source/config \ + -d '{"connector.class":"org.apache.kafka.connect.file.FileStreamSourceConnector","tasks.max":"1","file":"/tmp/source-records.txt","topic":"connector-source-events","value.converter":"org.apache.kafka.connect.storage.StringConverter"}' + curl --fail --silent --show-error -X PUT \ + -H 'Content-Type: application/json' \ + http://localhost:8083/connectors/demo-file-sink/config \ + -d '{"connector.class":"org.apache.kafka.connect.file.FileStreamSinkConnector","tasks.max":"1","file":"/tmp/sink-records.txt","topics":"demo-orders"}' + while kill -0 "$$connect_pid" 2> /dev/null; do + echo "connector event $$(date +%s)" >> /tmp/source-records.txt + sleep 2 + done + wait "$$connect_pid" + healthcheck: + test: ["CMD", "curl", "--fail", "--silent", "http://localhost:8083/connectors"] + interval: 10s + timeout: 5s + retries: 12 + datadog-agent: - image: gcr.io/datadoghq/agent:7.80.0 + image: gcr.io/datadoghq/agent:7.82.0 depends_on: kafka: condition: service_healthy @@ -165,6 +230,7 @@ configs: instances: - kafka_connect_str: "kafka:19092" enable_cluster_monitoring: true + kafka_connect_url: http://kafka-connect:8083 schema_registry_url: http://schema-registry:8081 tags: - env:demo
General Availability7.287.63.0
>=3.0,<4 Maintenence (until May 31, 2026)Maintenance (until May 31, 2026) 7.28