From 9a3298125fd41b1ab2418f824564ac7e020614b9 Mon Sep 17 00:00:00 2001 From: Heston Hoffman Date: Thu, 13 Aug 2026 20:33:25 -0700 Subject: [PATCH 1/2] Add BlockIgnore for prodname shortcode in Vale config Related to DOCS-15413. --- .vale.ini | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/.vale.ini b/.vale.ini index cdaf205ae26..adb4122994f 100644 --- a/.vale.ini +++ b/.vale.ini @@ -12,7 +12,8 @@ BlockIgnores = (?s) *({{< ?code-block [^>]* >}}.*?{{< ?/ ?code-block >}}), \ (?s) *({{< ?(w|/w)hatsnext [^>]*>}}), \ (?s) *({{< ?(n|/n)extlink [^>]*>}}), \ (?s) *({%\s*if\s+[^%]*%}), \ -(?s) *({%\s*partial\s+[^%]*\/%}) +(?s) *({%\s*partial\s+[^%]*\/%}), \ +(?s) *({{< ?prodname ?>}}.*?{{< ?/ ?prodname ?>}}) TokenIgnores = ({{< ?site-region [^>]* >}}) [*.html] From 265235e26baada7f53d412ac3874b272c5052d56 Mon Sep 17 00:00:00 2001 From: Heston Hoffman Date: Fri, 14 Aug 2026 09:44:58 -0700 Subject: [PATCH 2/2] prodname changes --- .../en/account_management/api-app-keys.md | 2 +- .../account_management/audit_trail/_index.md | 2 +- .../account_management/audit_trail/events.md | 2 +- ...rack_agentic_usage_in_your_organization.md | 4 +- .../en/account_management/billing/_index.md | 2 +- .../billing/ai_credit_limits.md | 4 +- .../billing/incident_response.md | 30 ++--- .../en/account_management/billing/pricing.md | 8 +- .../account_management/billing/serverless.md | 2 +- .../billing/workflow_automation.md | 16 +-- .../account_management/multi_organization.md | 2 +- .../org_settings/cross_org_visibility.md | 2 +- .../org_settings/ip_allowlist.md | 2 +- .../plan_and_usage/bill_overview.md | 2 +- .../plan_and_usage/cost_details.md | 2 +- .../plan_and_usage/usage_details.md | 2 +- .../en/account_management/rbac/data_access.md | 20 +-- .../en/account_management/teams/_index.md | 2 +- .../en/account_management/teams/manage.md | 2 +- hugo/content/en/actions/_index.md | 4 +- .../en/actions/actions_catalog/_index.md | 2 +- hugo/content/en/actions/agents/_index.md | 10 +- hugo/content/en/actions/app_builder/_index.md | 4 +- .../content/en/actions/app_builder/queries.md | 4 +- hugo/content/en/actions/connections/_index.md | 4 +- .../en/actions/connections/aws_integration.md | 2 +- hugo/content/en/actions/datadog_apps.md | 10 +- hugo/content/en/actions/datastores/_index.md | 2 +- hugo/content/en/actions/datastores/use.md | 2 +- hugo/content/en/actions/forms/_index.md | 12 +- .../private_actions/use_private_actions.md | 8 +- hugo/content/en/actions/workflows/build.md | 6 +- hugo/content/en/actions/workflows/limits.md | 2 +- .../en/actions/workflows/saved_actions.md | 2 +- hugo/content/en/actions/workflows/trigger.md | 2 +- hugo/content/en/administrators_guide/plan.md | 12 +- .../en/agent/configuration/dual-shipping.md | 4 +- .../configuration/infrastructure-modes.md | 2 +- .../content/en/agent/configuration/network.md | 4 +- hugo/content/en/agent/faq/fips_proxy.md | 2 +- .../en/agent/fleet_automation/upgrade_sdks.md | 4 +- hugo/content/en/agent/logs/_index.md | 2 +- .../en/agent/supported_platforms/aix.md | 2 +- hugo/content/en/agentic_onboarding/_index.md | 2 +- hugo/content/en/agentic_onboarding/setup.md | 10 +- hugo/content/en/ai_agents_console/_index.md | 10 +- hugo/content/en/ai_agents_console/setup.md | 24 ++-- hugo/content/en/all_guides.md | 24 ++-- hugo/content/en/api/latest/scopes/_index.md | 2 +- hugo/content/en/bits_ai/_index.md | 6 +- hugo/content/en/bits_ai/bits_chat.md | 22 ++-- hugo/content/en/bits_ai/bits_code/_index.md | 50 ++++---- .../en/bits_ai/bits_code/automations.md | 36 +++--- hugo/content/en/bits_ai/bits_code/setup.md | 38 +++--- .../en/bits_ai/bits_data_analysis/_index.md | 2 +- .../bits_ai/bits_investigation/configure.md | 10 +- .../bits_investigation/investigate_issues.md | 4 +- hugo/content/en/bits_ai/bits_remediation.md | 2 +- .../en/bits_ai/bits_security_analyst.md | 40 +++--- hugo/content/en/byoc-logs/_index.md | 6 +- hugo/content/en/byoc-logs/configure/_index.md | 4 +- .../content/en/byoc-logs/configure/indexes.md | 8 +- .../content/en/byoc-logs/configure/ingress.md | 14 +-- hugo/content/en/byoc-logs/configure/lambda.md | 12 +- .../configure/metastore_read_replicas.md | 2 +- .../en/byoc-logs/configure/pipelines.md | 10 +- hugo/content/en/byoc-logs/guides/_index.md | 4 +- .../byoc-logs/guides/query_logs_with_mcp.md | 16 +-- .../send_otel_logs_observability_pipelines.md | 12 +- hugo/content/en/byoc-logs/ingest/_index.md | 14 +-- hugo/content/en/byoc-logs/ingest/agent.md | 16 +-- hugo/content/en/byoc-logs/ingest/api.md | 2 +- .../ingest/observability_pipelines.md | 12 +- hugo/content/en/byoc-logs/install/_index.md | 6 +- hugo/content/en/byoc-logs/install/aws_eks.md | 16 +-- .../content/en/byoc-logs/install/azure_aks.md | 34 +++--- .../en/byoc-logs/install/custom_k8s.md | 10 +- hugo/content/en/byoc-logs/install/docker.md | 24 ++-- hugo/content/en/byoc-logs/install/gcp_gke.md | 22 ++-- .../en/byoc-logs/introduction/_index.md | 16 +-- .../en/byoc-logs/introduction/architecture.md | 16 +-- .../en/byoc-logs/introduction/features.md | 14 +-- .../en/byoc-logs/introduction/network.md | 8 +- .../en/byoc-logs/operate/best_practices.md | 12 +- .../operate/disk_buffer_durability.md | 16 +-- .../en/byoc-logs/operate/monitoring.md | 4 +- .../en/byoc-logs/operate/search_logs.md | 2 +- hugo/content/en/byoc-logs/operate/sizing.md | 4 +- .../en/byoc-logs/operate/troubleshooting.md | 8 +- hugo/content/en/byoc-logs/operate/updates.md | 4 +- hugo/content/en/byoc-logs/quickstart.md | 10 +- hugo/content/en/byoc-logs/release_notes.md | 2 +- hugo/content/en/change_tracking/_index.md | 22 ++-- .../en/change_tracking/feature_flags.md | 14 +-- hugo/content/en/cli/_index.md | 2 +- hugo/content/en/client_sdks/_index.md | 4 +- .../en/cloud_cost_management/_index.md | 6 +- .../en/cloud_cost_management/ai_costs.md | 4 +- .../allocation/_index.md | 2 +- .../allocation/custom_allocation_rules.md | 2 +- .../allocation/tag_pipelines.md | 2 +- .../cloud_cost_management/cloud_cost_skill.md | 22 ++-- .../cost_changes/_index.md | 2 +- .../cost_changes/real_time_costs.md | 4 +- .../en/cloud_cost_management/datadog_costs.md | 8 +- .../cloud_cost_management/planning/_index.md | 2 +- .../planning/commitment_programs.md | 2 +- .../planning/forecasting.md | 4 +- .../recommendations/_index.md | 10 +- .../cost_optimization_automation.md | 4 +- .../en/cloud_cost_management/setup/aws.md | 10 +- .../en/cloud_cost_management/setup/azure.md | 2 +- .../en/cloud_cost_management/setup/custom.md | 2 +- .../setup/google_cloud.md | 2 +- .../en/cloud_cost_management/setup/oracle.md | 6 +- .../setup/permissions.md | 2 +- .../cloud_cost_management/setup/saas_costs.md | 30 ++--- .../en/cloud_cost_management/tags/_index.md | 10 +- .../tags/multisource_querying.md | 16 +-- .../tags/tag_explorer.md | 8 +- .../content/en/code_coverage/configuration.md | 2 +- hugo/content/en/code_coverage/flags.md | 6 +- .../en/code_coverage/monorepo_support.md | 4 +- hugo/content/en/code_coverage/setup.md | 10 +- hugo/content/en/containers/_index.md | 2 +- .../en/containers/autoscaling/_index.md | 6 +- .../content/en/containers/bits_remediation.md | 6 +- .../datadog_operator/crd_monitor.md | 4 +- .../en/containers/kubernetes/_index.md | 4 +- .../en/containers/kubernetes/appsec.md | 18 +-- .../en/containers/kubernetes/installation.md | 2 +- .../en/containers/monitoring/_index.md | 4 +- .../containers/monitoring/container_images.md | 2 +- .../en/continuous_integration/_index.md | 2 +- .../cicd_optimization.md | 6 +- .../pipelines/awscodepipeline.md | 2 +- .../continuous_integration/pipelines/azure.md | 2 +- .../pipelines/buildkite.md | 2 +- .../pipelines/circleci.md | 2 +- .../pipelines/github.md | 2 +- .../pipelines/gitlab.md | 4 +- .../pipelines/jenkins.md | 14 +-- .../cicd_integrations/jenkins.md | 2 +- .../en/continuous_testing/guide/_index.md | 2 +- ...-testing-test-runs-in-test-optimization.md | 12 +- .../en/continuous_testing/troubleshooting.md | 2 +- hugo/content/en/coterm/install.md | 2 +- hugo/content/en/coterm/usage.md | 4 +- .../en/dashboards/change_overlays/_index.md | 2 +- hugo/content/en/dashboards/widgets/_index.md | 2 +- .../widgets/configuration/_index.md | 2 +- hugo/content/en/dashboards/widgets/list.md | 6 +- .../en/dashboards/widgets/log_stream.md | 2 +- .../en/dashboards/widgets/point_plot.md | 4 +- .../en/dashboards/widgets/retention.md | 2 +- hugo/content/en/dashboards/widgets/sankey.md | 2 +- .../en/dashboards/widgets/scatter_plot.md | 2 +- hugo/content/en/data_observability/_index.md | 2 +- .../integration_overhead.md | 6 +- .../jobs_monitoring/_index.md | 10 +- .../jobs_monitoring/airflow.md | 12 +- .../jobs_monitoring/airflow_mwaa_upgrade.md | 2 +- .../airflow_troubleshooting_dag.md | 2 +- .../jobs_monitoring/azure_data_factory.md | 2 +- .../jobs_monitoring/databricks/_index.md | 24 ++-- .../jobs_monitoring/dataproc.md | 4 +- .../data_observability/jobs_monitoring/dbt.md | 2 +- .../data_observability/jobs_monitoring/emr.md | 6 +- .../jobs_monitoring/glue.md | 4 +- .../jobs_monitoring/kubernetes.md | 8 +- .../jobs_monitoring/openlineage/_index.md | 2 +- hugo/content/en/data_observability/lineage.md | 2 +- .../business_intelligence/looker.md | 2 +- .../quality_monitoring/data_lakes/aws_glue.md | 2 +- .../data_warehouses/bigquery.md | 4 +- .../data_warehouses/databricks.md | 2 +- .../data_warehouses/redshift.md | 2 +- .../data_warehouses/snowflake.md | 2 +- .../transactional_databases/postgres.md | 22 ++-- hugo/content/en/data_security/_index.md | 2 +- hugo/content/en/data_security/logs.md | 4 +- .../en/data_security/pci_compliance.md | 2 +- hugo/content/en/data_security/synthetics.md | 2 +- hugo/content/en/data_streams/_index.md | 2 +- hugo/content/en/data_streams/kafka/_index.md | 2 +- .../kafka/monitors_and_automation.md | 6 +- hugo/content/en/database_monitoring/_index.md | 4 +- .../agent_integration_overhead.md | 2 +- .../en/database_monitoring/architecture.md | 6 +- .../bits_database_optimization.md | 4 +- .../connect_dbm_and_apm.md | 8 +- .../custom_metrics/_index.md | 2 +- .../exploring_custom_metrics.md | 2 +- .../en/database_monitoring/data_collected.md | 8 +- .../database_investigator/_index.md | 24 ++-- .../guide/aurora_autodiscovery.md | 4 +- .../guide/build_apps_with_dbm_api.md | 2 +- .../guide/database_identifier.md | 4 +- .../guide/managed_authentication.md | 2 +- .../guide/parameterized_queries.md | 6 +- .../guide/rds_autodiscovery.md | 4 +- .../guide/rds_autodiscovery_terraform.md | 2 +- .../database_monitoring/guide/sql_alwayson.md | 2 +- .../database_monitoring/guide/sql_deadlock.md | 4 +- .../guide/sql_extended_events.md | 2 +- .../guide/tag_database_statements.md | 2 +- .../en/database_monitoring/query_metrics.md | 2 +- .../en/database_monitoring/recommendations.md | 2 +- .../en/database_monitoring/schema_explorer.md | 2 +- .../setup_agent_terraform/_index.md | 2 +- .../setup_agent_terraform/mysql.md | 8 +- .../setup_agent_terraform/postgres.md | 8 +- .../setup_clickhouse/_index.md | 2 +- .../setup_clickhouse/cloud.md | 2 +- .../setup_clickhouse/selfhosted.md | 2 +- .../setup_documentdb/amazon_documentdb.md | 4 +- .../setup_documentdb/troubleshooting.md | 2 +- .../setup_mongodb/mongodbatlas.md | 4 +- .../setup_mongodb/selfhosted.md | 4 +- .../setup_mongodb/troubleshooting.md | 2 +- .../database_monitoring/setup_mysql/aurora.md | 10 +- .../database_monitoring/setup_mysql/azure.md | 10 +- .../database_monitoring/setup_mysql/gcsql.md | 10 +- .../en/database_monitoring/setup_mysql/rds.md | 12 +- .../setup_mysql/selfhosted.md | 12 +- .../setup_mysql/troubleshooting.md | 6 +- .../setup_oracle/autonomous_database.md | 8 +- .../setup_oracle/exadata.md | 8 +- .../database_monitoring/setup_oracle/rac.md | 8 +- .../database_monitoring/setup_oracle/rds.md | 8 +- .../setup_oracle/selfhosted.md | 8 +- .../setup_oracle/troubleshooting.md | 2 +- .../setup_postgres/_index.md | 2 +- .../setup_postgres/alloydb.md | 12 +- .../setup_postgres/aurora.md | 12 +- .../setup_postgres/azure.md | 12 +- .../setup_postgres/gcsql.md | 12 +- .../setup_postgres/heroku.md | 10 +- .../setup_postgres/rds/_index.md | 12 +- .../setup_postgres/selfhosted.md | 10 +- .../setup_postgres/supabase/_index.md | 6 +- .../setup_postgres/supabase/agent.md | 10 +- .../setup_postgres/supabase/cloud.md | 10 +- .../setup_postgres/troubleshooting.md | 10 +- .../setup_sql_server/azure.md | 6 +- .../setup_sql_server/gcsql.md | 6 +- .../setup_sql_server/rds.md | 6 +- .../setup_sql_server/selfhosted.md | 4 +- .../setup_sql_server/troubleshooting.md | 2 +- .../en/database_monitoring/troubleshooting.md | 2 +- hugo/content/en/datadog_cloudcraft/_index.md | 12 +- .../overlays/observability.md | 2 +- .../datadog_cloudcraft/overlays/security.md | 2 +- hugo/content/en/ddsql_editor/_index.md | 4 +- hugo/content/en/ddsql_reference/_index.md | 6 +- .../content/en/delivery_performance/_index.md | 2 +- .../change_failure_detection/_index.md | 2 +- .../dora_metrics/data_collected/_index.md | 2 +- hugo/content/en/deployment_gates/_index.md | 8 +- hugo/content/en/deployment_gates/explore.md | 4 +- .../en/deployment_gates/setup/_index.md | 6 +- hugo/content/en/deployment_gates/setup/jit.md | 6 +- .../deployment_gates/setup/preconfigured.md | 6 +- hugo/content/en/error_tracking/_index.md | 10 +- hugo/content/en/error_tracking/apm.md | 2 +- hugo/content/en/error_tracking/auto_assign.md | 2 +- .../en/error_tracking/backend/_index.md | 2 +- .../capturing_handled_errors/_index.md | 4 +- .../capturing_handled_errors/python.md | 4 +- .../backend/exception_replay.md | 10 +- .../backend/getting_started/_index.md | 2 +- .../content/en/error_tracking/backend/logs.md | 6 +- .../en/error_tracking/dynamic_sampling.md | 8 +- hugo/content/en/error_tracking/explorer.md | 10 +- .../en/error_tracking/frontend/_index.md | 2 +- .../en/error_tracking/frontend/browser.md | 10 +- .../en/error_tracking/frontend/logs.md | 6 +- .../error_tracking/frontend/mobile/android.md | 12 +- .../en/error_tracking/frontend/mobile/expo.md | 12 +- .../en/error_tracking/frontend/mobile/ios.md | 16 +-- .../frontend/mobile/kotlin-multiplatform.md | 10 +- .../en/error_tracking/guides/_index.md | 6 +- .../en/error_tracking/guides/sentry_sdk.md | 14 +-- .../content/en/error_tracking/issue_states.md | 16 +-- .../en/error_tracking/issue_team_ownership.md | 2 +- .../en/error_tracking/link_pull_requests.md | 12 +- .../error_tracking/manage_data_collection.md | 24 ++-- .../en/error_tracking/regression_detection.md | 4 +- .../en/error_tracking/suspect_commits.md | 4 +- .../ticketing_systems/_index.md | 10 +- .../ticketing_systems/case_management.md | 36 +++--- .../error_tracking/ticketing_systems/jira.md | 36 +++--- .../ticketing_systems/linear.md | 44 +++---- .../en/error_tracking/troubleshooting.md | 14 +-- hugo/content/en/events/_index.md | 4 +- .../events/correlation/maintenance_windows.md | 2 +- .../events/correlation/triage_and_notify.md | 8 +- .../migrating_to_new_events_features.md | 2 +- hugo/content/en/events/triage_inbox.md | 2 +- hugo/content/en/experiments/_index.md | 6 +- .../en/experiments/concepts/subject_types.md | 4 +- .../en/experiments/defining_metrics/_index.md | 8 +- .../defining_metrics/metric_sync.md | 2 +- hugo/content/en/experiments/diagnostics.md | 4 +- hugo/content/en/experiments/mcp_tools.md | 4 +- .../experiments/metric_property_breakouts.md | 2 +- .../plan_and_launch_experiments.md | 2 +- .../content/en/experiments/reading_results.md | 2 +- .../content/en/experiments/troubleshooting.md | 2 +- hugo/content/en/extend/guide/dogshell.md | 2 +- .../create-a-cloud-siem-detection-rule.md | 4 +- hugo/content/en/feature_flags/_index.md | 2 +- .../en/feature_flags/client/flutter.md | 6 +- .../en/feature_flags/client/reactnative.md | 10 +- .../en/feature_flags/concepts/approvals.md | 4 +- .../en/feature_flags/concepts/environments.md | 6 +- .../en/feature_flags/concepts/flag_history.md | 2 +- .../feature_flags/concepts/saved_filters.md | 4 +- .../concepts/scheduled_rollouts.md | 2 +- .../concepts/targeting_attributes.md | 2 +- .../feature_flags/concepts/targeting_rules.md | 2 +- .../feature_flags/feature_flag_mcp_server.md | 2 +- hugo/content/en/feature_flags/guide/_index.md | 2 +- .../en/feature_flags/guide/headless_cms.md | 10 +- .../guide/migrate_from_launchdarkly.md | 4 +- .../guide/migrate_from_statsig.md | 4 +- .../implementation_patterns/_index.md | 2 +- .../implementation_patterns/serverless.md | 8 +- .../content/en/feature_flags/server/_index.md | 2 +- hugo/content/en/feature_flags/server/java.md | 4 +- hugo/content/en/feature_flags/server/ruby.md | 4 +- hugo/content/en/getting_started/_index.md | 24 ++-- .../en/getting_started/application/_index.md | 2 +- .../getting_started/ci_visibility/_index.md | 2 +- .../getting_started/code_security/_index.md | 8 +- .../continuous_testing/_index.md | 2 +- .../database_monitoring/_index.md | 10 +- .../en/getting_started/devsecops/_index.md | 18 +-- .../getting_started/feature_flags/_index.md | 2 +- .../incident_management/_index.md | 4 +- .../en/getting_started/integrations/azure.md | 2 +- .../integrations/google_cloud.md | 10 +- .../en/getting_started/integrations/oci.md | 8 +- .../internal_developer_portal/_index.md | 4 +- .../content/en/getting_started/logs/_index.md | 4 +- .../en/getting_started/monitors/_index.md | 2 +- .../en/getting_started/search/_index.md | 2 +- .../search/product_specific_reference.md | 6 +- .../en/getting_started/security/_index.md | 10 +- .../security/application_security.md | 8 +- .../security/cloud_security_management.md | 6 +- .../en/getting_started/security/cloud_siem.md | 10 +- .../getting_started/session_replay/_index.md | 4 +- .../en/getting_started/software_delivery.md | 4 +- .../software_delivery_mcp_tools/_index.md | 10 +- .../test_impact_analysis/_index.md | 4 +- .../test_optimization/_index.md | 14 +-- .../en/getting_started/tracing/_index.md | 10 +- .../workflow_automation/_index.md | 4 +- hugo/content/en/glossary/terms/ndm.md | 2 +- hugo/content/en/glossary/terms/rasp.md | 2 +- .../en/glossary/terms/test_regression.md | 2 +- hugo/content/en/glossary/terms/test_run.md | 2 +- .../content/en/glossary/terms/test_service.md | 2 +- hugo/content/en/glossary/terms/test_suite.md | 2 +- hugo/content/en/gpu_monitoring/_index.md | 8 +- hugo/content/en/gpu_monitoring/fleet.md | 8 +- hugo/content/en/gpu_monitoring/setup.md | 24 ++-- hugo/content/en/gpu_monitoring/summary.md | 2 +- hugo/content/en/ide_plugins/idea/_index.md | 16 +-- .../en/ide_plugins/idea/code_security.md | 2 +- .../en/ide_plugins/idea/error_tracking.md | 6 +- hugo/content/en/ide_plugins/vscode/_index.md | 18 +-- .../en/ide_plugins/vscode/code_insights.md | 8 +- .../en/ide_plugins/vscode/code_security.md | 2 +- .../en/ide_plugins/vscode/exception_replay.md | 6 +- hugo/content/en/incident_response/_index.md | 4 +- .../case_management/_index.md | 2 +- .../case_management/ai/_index.md | 8 +- .../case_management/ai/custom_agents.md | 8 +- .../case_management/automation_rules.md | 2 +- .../case_management/customization.md | 6 +- .../notifications_integrations.md | 12 +- .../case_management/settings.md | 4 +- .../case_management/troubleshooting.md | 8 +- .../incident_management/_index.md | 10 +- .../analytics_and_reporting/_index.md | 2 +- .../guides/manage_with_terraform.md | 2 +- .../investigate/declare.md | 12 +- .../investigate/response_team.md | 2 +- .../investigate/timeline.md | 2 +- .../post_incident/_index.md | 2 +- .../post_incident/follow-ups.md | 14 +-- .../setup_and_configuration/_index.md | 2 +- .../setup_and_configuration/automations.md | 4 +- .../setup_and_configuration/integrations.md | 6 +- .../integrations/_index.md | 6 +- .../integrations/google_chat.md | 2 +- .../integrations/microsoft_teams/_index.md | 16 +-- .../integrations/servicenow.md | 4 +- .../integrations/slack/_index.md | 24 ++-- .../integrations/status_pages.md | 6 +- .../integrations/statuspage.md | 4 +- .../property_fields.md | 4 +- .../en/incident_response/on-call/_index.md | 16 +-- .../incident_response/on-call/automations.md | 2 +- .../configure-mobile-device-for-on-call.md | 20 +-- ...rate-your-opsgenie-resources-to-on-call.md | 2 +- .../migrating-from-your-current-providers.md | 2 +- .../guides/offboarding-teams-and-users.md | 22 ++-- .../notification_preferences/_index.md | 6 +- .../supported_countries.md | 2 +- .../incident_response/on-call/pages/_index.md | 8 +- .../on-call/pages/cross_org_paging.md | 2 +- .../on-call/pages/live_call_routing.md | 6 +- .../en/incident_response/on-call/schedules.md | 12 +- .../en/incident_response/on-call/teams.md | 2 +- .../incident_response/status_pages/_index.md | 2 +- hugo/content/en/infrastructure/list.md | 2 +- .../infrastructure/resource_catalog/_index.md | 8 +- .../resource_changes/_index.md | 4 +- .../storage_management/amazon_s3.md | 14 +-- .../en/integrations/amazon_guardduty.md | 2 +- hugo/content/en/integrations/guide/_index.md | 2 +- .../guide/amazon-eks-audit-logs.md | 6 +- .../application-monitoring-vmware-tanzu.md | 2 +- .../guide/aws-organizations-setup.md | 4 +- .../integrations/guide/aws-terraform-setup.md | 14 +-- .../guide/azure-native-integration.md | 2 +- .../guide/azure-resource-manager.md | 2 +- .../guide/servicenow-cmdb-enrichment-setup.md | 2 +- .../guide/servicenow-itom-itsm-setup.md | 12 +- .../en/integrations/guide/slack-actions.md | 2 +- .../en/internal_developer_portal/_index.md | 2 +- .../campaigns/_index.md | 2 +- .../catalog/_index.md | 4 +- .../catalog/endpoints/_index.md | 2 +- .../catalog/set_up/_index.md | 4 +- .../catalog/set_up/create_entities.md | 2 +- .../catalog/set_up/discover_entities.md | 2 +- .../eng_reports/catalog_health.md | 2 +- .../eng_reports/teams_performance.md | 4 +- .../en/internal_developer_portal/homepage.md | 4 +- .../internal_developer_portal/integrations.md | 4 +- .../onboarding_guide.md | 6 +- .../overview_pages.md | 4 +- .../en/internal_developer_portal/plugins.md | 2 +- .../scorecards/custom_rules.md | 4 +- .../scorecards/scorecard_configuration.md | 2 +- .../self_service_actions/_index.md | 8 +- .../software_templates.md | 4 +- .../use_cases/cloud_cost_management.md | 2 +- .../use_cases/pipeline_visibility.md | 2 +- .../use_cases/production_readiness.md | 6 +- hugo/content/en/journey_monitoring/_index.md | 4 +- .../details_report/_index.md | 6 +- .../en/journey_monitoring/map/_index.md | 2 +- hugo/content/en/llm_observability/_index.md | 4 +- .../data_security_and_rbac.md | 8 +- .../llm_observability/evaluations/_index.md | 10 +- .../evaluations/annotation_queues.md | 4 +- .../_index.md | 6 +- .../connect_to_account.md | 18 +-- .../session_level_evaluations.md | 4 +- .../trace_level_evaluations.md | 4 +- .../evaluations/deepeval_evaluations.md | 2 +- .../evaluations/end_user_feedback.md | 4 +- .../evaluations/evaluation_developer_guide.md | 2 +- .../evaluations/export_api.md | 6 +- .../evaluations/external_evaluations.md | 6 +- .../evaluations/managed_evaluations/_index.md | 2 +- .../evaluations/pydantic_evaluations.md | 2 +- .../evaluations/submit_nemo_evaluations.md | 8 +- .../llm_observability/experiments/_index.md | 2 +- .../experiments/analyzing_results.md | 2 +- .../experiments/prompt_optimization.md | 4 +- .../en/llm_observability/experiments/setup.md | 6 +- .../en/llm_observability/guide/_index.md | 4 +- .../guide/claude_code_skills.md | 4 +- .../llm_observability/guide/crewai_guide.md | 4 +- .../llm_observability/guide/nextjs_guide.md | 4 +- .../instrumentation/_index.md | 4 +- .../instrumentation/agentic/_index.md | 8 +- .../instrumentation/agentic/nodejs.md | 2 +- .../agentic/prompt_management.md | 8 +- .../instrumentation/agentic/python.md | 2 +- .../llm_observability/instrumentation/api.md | 2 +- .../instrumentation/auto_instrumentation.md | 18 +-- .../instrumentation/otel_instrumentation.md | 36 +++--- .../llm_observability/instrumentation/sdk.md | 50 ++++---- hugo/content/en/llm_observability/lapdog.md | 6 +- .../en/llm_observability/mcp_server.md | 18 +-- .../en/llm_observability/monitoring/_index.md | 6 +- .../monitoring/agent_monitoring.md | 4 +- .../monitoring/automation_rules.md | 2 +- .../en/llm_observability/monitoring/cost.md | 6 +- .../monitoring/llm_observability_and_apm.md | 16 +-- .../monitoring/mcp_client.md | 2 +- .../llm_observability/monitoring/metrics.md | 12 +- .../llm_observability/monitoring/patterns.md | 6 +- .../monitoring/prompt_management.md | 8 +- .../monitoring/prompt_tracking.md | 6 +- .../en/llm_observability/quickstart.md | 8 +- .../en/llm_observability/terms/_index.md | 14 +-- .../llm_observability/trace_proxy_services.md | 4 +- hugo/content/en/logs/_index.md | 2 +- hugo/content/en/logs/error_tracking/_index.md | 4 +- hugo/content/en/logs/explorer/facets.md | 2 +- .../content/en/logs/explorer/search_syntax.md | 2 +- .../en/logs/explorer/watchdog_insights.md | 2 +- hugo/content/en/logs/guide/_index.md | 2 +- .../best-practices-for-log-management.md | 2 +- .../logs/guide/google-cloud-log-forwarding.md | 2 +- .../en/logs/guide/how-to-set-up-only-logs.md | 2 +- .../logs/guide/reduce_data_transfer_fees.md | 2 +- hugo/content/en/logs/log_collection/_index.md | 2 +- .../attributes_naming_convention.md | 2 +- .../en/logs/log_configuration/indexes.md | 2 +- .../logs/log_configuration/logs_to_metrics.md | 4 +- .../en/logs/log_configuration/pipelines.md | 4 +- .../log_configuration/processors/_index.md | 2 +- hugo/content/en/mcp_server/_index.md | 8 +- hugo/content/en/mcp_server/setup.md | 114 +++++++++--------- hugo/content/en/mcp_server/tools.md | 102 ++++++++-------- hugo/content/en/metrics/advanced-filtering.md | 2 +- .../en/metrics/guide/dynamic_quotas.md | 4 +- hugo/content/en/metrics/summary.md | 10 +- hugo/content/en/mobile/_index.md | 12 +- hugo/content/en/mobile/guide/_index.md | 2 +- .../configure-mobile-device-for-on-call.md | 26 ++-- .../en/mobile/guide/setup_mobile_device.md | 2 +- hugo/content/en/mobile/push_notification.md | 10 +- hugo/content/en/mobile/widgets.md | 18 +-- .../en/monitors/configuration/_index.md | 4 +- .../en/monitors/guide/monitor_api_options.md | 2 +- .../en/monitors/guide/on_missing_data.md | 2 +- hugo/content/en/monitors/notify/variables.md | 4 +- hugo/content/en/monitors/status/graphs.md | 6 +- .../en/monitors/status/status_legacy.md | 2 +- hugo/content/en/monitors/types/_index.md | 6 +- hugo/content/en/monitors/types/analysis.md | 2 +- hugo/content/en/monitors/types/cloud_cost.md | 2 +- .../en/monitors/types/data_observability.md | 12 +- .../en/monitors/types/error_tracking.md | 16 +-- hugo/content/en/monitors/types/event.md | 2 +- hugo/content/en/monitors/types/log.md | 2 +- hugo/content/en/monitors/types/netflow.md | 2 +- hugo/content/en/network_monitoring/_index.md | 2 +- .../network_analytics.md | 2 +- .../en/network_monitoring/devices/_index.md | 4 +- .../devices/config_management.md | 6 +- .../en/network_monitoring/devices/data.md | 4 +- .../en/network_monitoring/devices/geomap.md | 4 +- .../en/network_monitoring/devices/glossary.md | 2 +- .../devices/guide/cluster-agent.md | 2 +- .../devices/integrations.md | 2 +- .../en/network_monitoring/devices/ping.md | 2 +- .../devices/profiles/_index.md | 4 +- .../devices/profiles/device_profiles.md | 2 +- .../en/network_monitoring/devices/setup.md | 6 +- .../devices/snmp_metrics.md | 4 +- .../network_monitoring/devices/snmp_traps.md | 2 +- .../en/network_monitoring/devices/summary.md | 2 +- .../en/network_monitoring/devices/syslog.md | 2 +- .../en/network_monitoring/devices/topology.md | 2 +- .../devices/vpn_monitoring.md | 2 +- .../en/network_monitoring/netflow/_index.md | 4 +- .../en/observability_pipelines/_index.md | 4 +- .../configuration/_index.md | 4 +- .../configuration/access_control.md | 2 +- .../configuration/explore_templates.md | 2 +- ...port_and_import_pipeline_configurations.md | 10 +- .../install_the_worker/_index.mdoc.md | 22 ++-- .../advanced_worker_configurations.md | 2 +- .../configuration/live_capture.md | 2 +- .../configuration/pipeline_simulation.md | 8 +- .../configuration/set_up_pipelines.md | 8 +- .../update_existing_pipelines.md | 4 +- .../destinations/_index.md | 2 +- .../destinations/amazon_s3.md | 2 +- .../destinations/azure_storage.md | 2 +- .../destinations/databricks.md | 2 +- .../destinations/datadog_archives.md | 2 +- .../destinations/datadog_byoc_logs.md | 12 +- .../destinations/datadog_logs.md | 12 +- .../destinations/datadog_metrics.md | 4 +- .../destinations/google_cloud_storage.md | 4 +- .../destinations/kafka.md | 2 +- .../destinations/sentinelone.md | 2 +- .../destinations/splunk_hec/logs.md | 4 +- .../destinations/splunk_hec/metrics.md | 4 +- .../observability_pipelines/guide/_index.md | 2 +- .../get_started_with_the_custom_processor.md | 4 +- .../guide/remap_reserved_attributes.md | 8 +- .../strategies_for_reducing_log_volume.md | 4 +- .../guide/upgrade_worker.md | 20 +-- .../observability_pipelines/legacy/_index.md | 6 +- .../availability_disaster_recovery.md | 2 +- .../legacy/configurations.md | 2 +- .../guide/control_log_volume_and_size.md | 2 +- ...with_the_observability_pipelines_worker.md | 2 +- ...atadog_rehydratable_format_to_Amazon_S3.md | 2 +- .../guide/sensitive_data_scanner_transform.md | 6 +- ...t_quotas_for_data_sent_to_a_destination.md | 6 +- .../legacy/monitoring.md | 4 +- .../legacy/production_deployment_overview.md | 2 +- .../legacy/reference/sources.md | 2 +- .../legacy/setup/_index.md | 6 +- .../legacy/setup/datadog.md | 14 +-- .../legacy/setup/datadog_with_archiving.md | 10 +- .../legacy/setup/splunk.md | 12 +- .../legacy/troubleshooting.md | 2 +- .../legacy/working_with_data.md | 4 +- .../monitoring_and_troubleshooting/_index.md | 2 +- .../monitoring_pipelines.md | 8 +- .../pipeline_usage_metrics.md | 6 +- .../troubleshooting.md | 12 +- .../observability_pipelines/packs/_index.md | 2 +- .../processors/_index.md | 2 +- .../processors/enrichment_table.md | 6 +- .../processors/sensitive_data_scanner.md | 6 +- .../en/observability_pipelines/rehydration.md | 6 +- .../scaling_and_performance/_index.md | 4 +- ...ces_for_scaling_observability_pipelines.md | 2 +- .../buffering_and_backpressure.md | 6 +- .../observability_pipelines/sources/_index.md | 4 +- .../sources/akamai_datastream.md | 8 +- .../sources/azure_event_hubs.md | 16 +-- .../sources/cloudflare_logpush.md | 6 +- .../sources/datadog_agent.md | 4 +- .../sources/filebeat.md | 2 +- .../sources/http_server.md | 2 +- .../sources/lambda_extension.md | 2 +- .../sources/lambda_forwarder.md | 2 +- .../observability_pipelines/sources/mysql.md | 10 +- .../observability_pipelines/sources/okta.md | 6 +- .../sources/opentelemetry.md | 16 +-- .../sources/splunk_hec.md | 4 +- .../observability_pipelines/sources/syslog.md | 2 +- .../sources/websocket.md | 2 +- .../content/en/opentelemetry/compatibility.md | 2 +- .../getting_started/otel_demo_to_datadog.md | 2 +- hugo/content/en/opentelemetry/guide/_index.md | 2 +- .../integrations/datadog_extension.md | 2 +- .../install/kubernetes_daemonset.md | 2 +- .../install/kubernetes_gateway.md | 2 +- .../setup/ddot_collector/install/linux.md | 2 +- .../setup/ddot_collector/install/windows.md | 2 +- .../setup/otlp_ingest_in_the_agent.md | 2 +- .../partners/cloud_cost_management/_index.md | 2 +- hugo/content/en/pr_gates/_index.md | 14 +-- hugo/content/en/pr_gates/setup/_index.md | 14 +-- hugo/content/en/product_analytics/_index.md | 20 +-- .../en/product_analytics/action_management.md | 6 +- .../charts/analytics_explorer/events.md | 4 +- .../charts/analytics_explorer/export.md | 4 +- .../charts/analytics_explorer/group.md | 2 +- .../charts/analytics_explorer/visualize.md | 4 +- .../product_analytics/charts/chart_basics.md | 4 +- .../data_collected/_index.md | 6 +- .../data_collected/server_side_events.md | 2 +- .../en/product_analytics/export_pipelines.md | 6 +- .../en/product_analytics/guide/_index.md | 2 +- ...itor-utm-campaigns-in-product-analytics.md | 4 +- .../guide/rum_and_product_analytics.md | 20 +-- .../en/product_analytics/profiles/_index.md | 2 +- .../profiles/identity_resolution.md | 8 +- .../product_analytics/segmentation/_index.md | 10 +- .../content/en/product_analytics/usability.md | 4 +- .../content/en/profiler/automated_analysis.md | 4 +- .../content/en/real_user_monitoring/_index.md | 4 +- .../android/error_tracking.md | 4 +- .../browser/build_plugins/_index.md | 2 +- .../build_plugins/source_code_context.md | 2 +- .../browser/build_plugins/source_maps.md | 4 +- .../browser/collecting_browser_errors.md | 6 +- .../cpp/error_tracking.md | 6 +- .../flutter/error_tracking.md | 2 +- .../react_native/error_tracking.md | 4 +- .../react_native/setup/_index.mdoc.md | 2 +- .../react_native/setup/codepush.md | 2 +- .../roku/error_tracking.md | 6 +- .../unity/error_tracking.md | 4 +- .../llm_observability/_index.md | 8 +- .../error_tracking/_index.md | 2 +- .../error_tracking/mobile/expo.md | 4 +- .../error_tracking/mobile/flutter.md | 4 +- .../error_tracking/mobile/ios.md | 8 +- .../mobile/kotlin-multiplatform.md | 6 +- .../error_tracking/mobile/maui.md | 6 +- .../error_tracking/mobile/reactnative.md | 4 +- .../error_tracking/mobile/roku.md | 6 +- .../real_user_monitoring/explorer/events.md | 2 +- .../explorer/visualize.md | 2 +- .../using_feature_flags.md | 2 +- .../guide/debug-symbols.md | 2 +- ...-components-in-your-browser-application.md | 2 +- .../guide/mobile-sdk-upgrade.md | 4 +- .../guide/session-replay-for-solutions.md | 2 +- .../guide/setup-rum-deployment-tracking.md | 4 +- .../understanding-the-rum-event-hierarchy.md | 2 +- .../guide/upload-javascript-source-maps.md | 4 +- .../platform/dashboards/_index.md | 4 +- .../platform/dashboards/errors.md | 4 +- .../en/real_user_monitoring/rum_export.md | 6 +- .../rum_without_limits/retention_filters.md | 2 +- .../content/en/remote_configuration/_index.md | 14 +-- hugo/content/en/security/_index.md | 30 ++--- hugo/content/en/security/ai_guard/_index.md | 14 +-- .../en/security/ai_guard/onboarding.md | 20 +-- .../en/security/ai_guard/setup/_index.md | 54 ++++----- .../ai_guard/setup/automatic_integrations.md | 30 ++--- .../en/security/ai_guard/setup/http_api.md | 10 +- .../ai_guard/setup/manual_integrations.md | 10 +- .../content/en/security/ai_guard/setup/sdk.md | 14 +-- hugo/content/en/security/ai_guard/signals.md | 32 ++--- .../security/application_security/_index.md | 6 +- .../api_posture/_index.md | 4 +- .../api_posture/api_findings.md | 10 +- .../api_posture/api_inventory/_index.md | 2 +- .../api_inventory/api_endpoints.md | 10 +- .../api_posture/api_inventory/services.md | 6 +- .../api_posture/compliance.md | 2 +- .../api_posture/endpoint_scanning.md | 2 +- .../api_posture/overview.md | 2 +- .../api_posture/sensitive_data.md | 8 +- .../application_security/attack_summary.md | 2 +- .../application_security/guide/_index.md | 4 +- .../guide/manage_account_theft_appsec.md | 8 +- .../guide/standalone_application_security.md | 14 +-- .../how-it-works/_index.md | 14 +-- .../how-it-works/add-user-info.md | 2 +- .../how-it-works/threat-intelligence.md | 4 +- .../how-it-works/trace_qualification.md | 4 +- .../application_security/setup/_index.md | 4 +- .../setup/aws/fargate/_index.md | 4 +- .../setup/aws/lambda/_index.md | 4 +- .../setup/aws/lambda/dotnet.md | 8 +- .../setup/aws/lambda/go.md | 10 +- .../setup/aws/lambda/java.md | 8 +- .../setup/aws/lambda/nodejs.md | 6 +- .../setup/aws/lambda/python.md | 8 +- .../setup/aws/lambda/ruby.md | 10 +- .../setup/aws/waf/_index.md | 4 +- .../setup/azure/app-service/_index.md | 6 +- .../setup/compatibility/envoy-gateway.md | 8 +- .../setup/compatibility/envoy.md | 8 +- .../compatibility/gcp-service-extensions.md | 4 +- .../setup/compatibility/haproxy.md | 8 +- .../setup/compatibility/istio.md | 8 +- .../setup/compatibility/nginx.md | 4 +- .../setup/compatibility/serverless.md | 6 +- .../setup/docker/_index.md | 4 +- .../setup/dotnet/_index.md | 2 +- .../setup/dotnet/aws-fargate.md | 10 +- .../setup/dotnet/docker.md | 6 +- .../setup/dotnet/dotnet.md | 6 +- .../setup/dotnet/kubernetes.md | 6 +- .../setup/dotnet/linux.md | 6 +- .../setup/dotnet/troubleshooting.md | 2 +- .../setup/dotnet/windows.md | 6 +- .../application_security/setup/envoy.md | 6 +- .../setup/gcp/cloud-run/_index.md | 4 +- .../setup/gcp/cloud-run/dotnet.md | 4 +- .../setup/gcp/cloud-run/go.md | 4 +- .../setup/gcp/cloud-run/java.md | 4 +- .../setup/gcp/cloud-run/nodejs.md | 4 +- .../setup/gcp/cloud-run/php.md | 4 +- .../setup/gcp/cloud-run/python.md | 4 +- .../setup/gcp/cloud-run/ruby.md | 4 +- .../setup/gcp/service-extensions.md | 6 +- .../application_security/setup/go/_index.md | 4 +- .../setup/go/aws-fargate.md | 14 +-- .../setup/go/dockerfile.md | 16 +-- .../application_security/setup/go/sdk.md | 2 +- .../application_security/setup/go/setup.md | 22 ++-- .../setup/go/troubleshooting.md | 8 +- .../application_security/setup/haproxy.md | 10 +- .../application_security/setup/java/_index.md | 2 +- .../setup/java/aws-fargate.md | 14 +-- .../application_security/setup/java/docker.md | 10 +- .../setup/java/kubernetes.md | 14 +-- .../application_security/setup/java/linux.md | 10 +- .../application_security/setup/java/macos.md | 10 +- .../setup/java/troubleshooting.md | 2 +- .../setup/java/windows.md | 10 +- .../setup/kubernetes/_index.md | 4 +- .../setup/kubernetes/envoy-gateway.md | 14 +-- .../setup/kubernetes/gateway-api.md | 6 +- .../setup/kubernetes/gke.md | 12 +- .../setup/kubernetes/istio.md | 16 +-- .../setup/linux/_index.md | 4 +- .../setup/macos/_index.md | 4 +- .../application_security/setup/nginx.md | 2 +- .../setup/nginx/_index.md | 4 +- .../setup/nginx/ingress-controller.md | 8 +- .../application_security/setup/nginx/linux.md | 6 +- .../setup/nodejs/_index.md | 2 +- .../setup/nodejs/aws-fargate.md | 10 +- .../setup/nodejs/docker.md | 6 +- .../setup/nodejs/kubernetes.md | 6 +- .../setup/nodejs/linux.md | 10 +- .../setup/nodejs/macos.md | 10 +- .../setup/nodejs/troubleshooting.md | 2 +- .../setup/nodejs/windows.md | 10 +- .../application_security/setup/php/_index.md | 2 +- .../setup/php/aws-fargate.md | 10 +- .../application_security/setup/php/docker.md | 6 +- .../setup/php/kubernetes.md | 10 +- .../application_security/setup/php/linux.md | 6 +- .../setup/php/troubleshooting.md | 4 +- .../setup/python/_index.md | 2 +- .../setup/python/aws-fargate.md | 10 +- .../setup/python/docker.md | 6 +- .../setup/python/kubernetes.md | 10 +- .../setup/python/linux.md | 6 +- .../setup/python/macos.md | 6 +- .../setup/python/troubleshooting.md | 2 +- .../setup/python/windows.md | 6 +- .../application_security/setup/ruby/_index.md | 2 +- .../setup/ruby/aws-fargate.md | 12 +- .../application_security/setup/ruby/docker.md | 8 +- .../setup/ruby/kubernetes.md | 8 +- .../application_security/setup/ruby/linux.md | 8 +- .../application_security/setup/ruby/macos.md | 8 +- .../setup/ruby/troubleshooting.md | 2 +- .../setup/single_step/_index.md | 2 +- .../setup/windows/_index.md | 4 +- .../en/security/application_security/terms.md | 2 +- .../threat_protection/_index.md | 4 +- .../account_takeover_protection.md | 4 +- .../threat_protection/exploit-prevention.md | 16 +-- .../threat_protection/overview.md | 4 +- .../threat_protection/policies/_index.md | 14 +-- .../policies/custom_rules.md | 4 +- .../policies/inapp_waf_rules.md | 6 +- .../policies/library_configuration.md | 2 +- .../security_signals/_index.md | 16 +-- .../security_signals/attacker-explorer.md | 2 +- .../security_signals/attacker_clustering.md | 2 +- .../security_signals/attacker_fingerprint.md | 4 +- .../security_signals/users_explorer.md | 6 +- .../threat_protection/waf-integration.md | 4 +- .../application_security/troubleshooting.md | 4 +- .../en/security/assignee_management.md | 8 +- .../security/automation_pipelines/_index.md | 2 +- .../automation_pipelines/create_ticket.md | 6 +- .../cloud_security_management/_index.md | 20 +-- .../code_locations/_index.md | 6 +- .../cloud_security_management/crown_jewels.md | 6 +- .../cloud_security_management/guide/_index.md | 2 +- .../guide/active-protection.md | 4 +- .../guide/agent_variables.md | 2 +- .../guide/custom-rules-guidelines.md | 2 +- .../guide/eBPF-free-agent.md | 6 +- .../identify-unauthorized-anomalous-procs.md | 2 +- .../guide/resource_evaluation_filters.md | 4 +- .../guide/tuning-rules.md | 8 +- .../identity_risks/_index.md | 6 +- .../misconfigurations/_index.md | 6 +- .../misconfigurations/findings/_index.md | 2 +- .../custom_frameworks.md | 2 +- .../supported_frameworks.md | 2 +- .../misconfigurations/kspm.md | 6 +- .../review_remediate/_index.md | 4 +- .../review_remediate/ownership_agent.md | 4 +- .../review_remediate/ownership_preferences.md | 2 +- .../review_remediate/remediate_with_ai.md | 14 +-- .../review_remediate/workflows.md | 4 +- .../cloud_security_management/setup/_index.md | 6 +- .../setup/agent/_index.md | 2 +- .../setup/agent/docker.md | 4 +- .../setup/agent/kubernetes.md | 4 +- .../setup/agent/linux.md | 4 +- .../setup/agentless_scanning/enable.md | 2 +- .../setup/ci_cd/_index.md | 2 +- .../setup/cloud_integrations.md | 12 +- .../setup/iac_remediation.md | 4 +- .../setup/supported_deployment_types.md | 4 +- .../without_infrastructure_monitoring.md | 18 +-- .../triage_and_prioritize/_index.md | 2 +- .../runtime_prioritization_engine.md | 2 +- .../triage_and_prioritize/severity_scoring.md | 8 +- .../troubleshooting/threats.md | 12 +- .../vulnerabilities/_index.md | 2 +- hugo/content/en/security/cloud_siem/_index.md | 16 +-- .../cloud_siem/detect_and_monitor/_index.md | 4 +- .../custom_detection_rules/content_anomaly.md | 2 +- .../create_rule/historical_job.md | 2 +- .../create_rule/scheduled_rule.md | 2 +- .../detect_and_monitor/mitre_attack_map.md | 4 +- .../en/security/cloud_siem/guide/_index.md | 18 +-- ...ate-the-remediation-of-detected-threats.md | 2 +- .../guide/aws-config-guide-for-cloud-siem.md | 4 +- .../azure-config-guide-for-cloud-siem.md | 4 +- ...ustomize-which-logs-cloud-siem-analyzes.md | 42 +++---- .../guide/determine-cloud-siem-product.md | 12 +- ...oogle-cloud-config-guide-for-cloud-siem.md | 2 +- .../guide/oci-config-guide-for-cloud-siem.md | 4 +- .../setting-up-security-monitoring-for-aws.md | 2 +- .../troubleshoot-cribl-stream-cloud-siem.md | 2 +- .../cloud_siem/ingest_and_enrich/_index.md | 10 +- .../ingest_and_enrich/content_packs.md | 2 +- .../_index.md | 10 +- .../ocsf_processor.md | 2 +- .../ingest_and_enrich/threat_intelligence.md | 16 +-- .../cloud_siem/respond_and_report/_index.md | 6 +- .../security_operational_metrics.md | 2 +- .../triage_and_investigate/_index.md | 4 +- .../entities_and_risk_scoring.md | 8 +- .../investigate_security_signals.md | 24 ++-- .../triage_and_investigate/investigator.md | 8 +- .../triage_and_investigate/ioc_explorer.md | 4 +- .../en/security/code_security/_index.md | 12 +- .../code_security/dev_tool_int/_index.md | 2 +- .../dev_tool_int/ide_plugins/_index.md | 2 +- .../dev_tool_int/mcp_server/_index.md | 4 +- .../mcp_server/tools_reference.md | 2 +- .../mcp_server/troubleshooting.md | 2 +- .../pull_request_comments/_index.md | 16 +-- .../guides/automate_risk_reduction_sca.md | 4 +- .../code_security/iac_security/_index.md | 2 +- .../iac_security/configuration.md | 4 +- .../code_security/iac_security/setup.md | 8 +- .../code_security/iast/setup/_index.md | 8 +- .../iast/setup/compatibility/dotnet.md | 2 +- .../iast/setup/compatibility/java.md | 6 +- .../iast/setup/compatibility/nodejs.md | 2 +- .../code_security/iast/setup/dotnet.md | 6 +- .../security/code_security/iast/setup/java.md | 6 +- .../code_security/iast/setup/nodejs.md | 6 +- .../code_security/iast/setup/python.md | 10 +- .../code_security/secret_scanning/_index.md | 2 +- .../software_composition_analysis/_index.md | 28 ++--- .../configuration.md | 2 +- .../setup_runtime/_index.md | 2 +- .../setup_runtime/compatibility/_index.md | 2 +- .../setup_runtime/compatibility/dotnet.md | 2 +- .../setup_runtime/compatibility/go.md | 2 +- .../setup_runtime/compatibility/java.md | 4 +- .../setup_runtime/compatibility/php.md | 4 +- .../setup_static/_index.md | 2 +- .../code_security/static_analysis/_index.md | 8 +- .../static_analysis/ai_enhanced_sast.md | 10 +- .../static_analysis/configuration.md | 2 +- .../static_analysis/custom_rules/_index.md | 4 +- .../static_analysis/setup/_index.md | 4 +- .../setup/generic_ci_providers.md | 2 +- .../static_analysis_rules/_index.md | 2 +- .../code_security/troubleshooting/_index.md | 10 +- .../en/security/default_rules/_index.md | 8 +- .../en/security/detection_rules/_index.md | 28 ++--- hugo/content/en/security/guide/_index.md | 16 +-- .../guide/aws_fargate_config_guide.md | 40 +++--- hugo/content/en/security/guide/byoti_guide.md | 2 +- .../generated/schema-reference.md | 12 +- .../guide/security-findings-migration.md | 14 +-- hugo/content/en/security/mcp_server.md | 22 ++-- .../en/security/notifications/rules.md | 2 +- hugo/content/en/security/security_inbox.md | 2 +- .../security/sensitive_data_scanner/_index.md | 20 +-- .../investigate_sensitive_data_findings.md | 8 +- .../scanning_rules/_index.md | 2 +- .../scanning_rules/library_rules.md | 2 +- .../sensitive_data_scanner/setup/_index.md | 6 +- .../setup/telemetry_data.md | 4 +- .../sensitive_data_scanner/troubleshooting.md | 2 +- .../en/security/ticketing_integrations.md | 54 ++++----- .../en/security/workload_protection/_index.md | 16 +-- .../guide/active-protection.md | 2 +- .../guide/eBPF-free-agent.md | 4 +- .../workload_protection/guide/tuning-rules.md | 8 +- .../workload_protection/inventory/_index.md | 2 +- .../inventory/coverage_map.md | 12 +- .../inventory/hosts_and_containers.md | 6 +- .../inventory/serverless.md | 10 +- .../workload_protection/secl_auth_guide.md | 4 +- .../workload_protection/security_signals.md | 12 +- .../workload_protection/setup/_index.md | 16 +-- .../workload_protection/setup/agent/_index.md | 2 +- .../workload_protection/setup/agent/docker.md | 2 +- .../setup/agent/ecs_ec2.md | 2 +- .../setup/agent/kubernetes.md | 2 +- .../workload_protection/setup/agent/linux.md | 2 +- .../setup/agent_variables.md | 2 +- .../workload_protection/setup/ootb_rules.md | 4 +- .../supported_linux_distributions.md | 2 +- .../troubleshooting/threats.md | 14 +-- .../workload_security_rules/_index.md | 16 +-- .../workload_security_rules/custom_rules.md | 4 +- .../en/serverless/aws_lambda/configuration.md | 6 +- .../aws_lambda/distributed_tracing.md | 8 +- .../aws_lambda/instrumentation/ruby.md | 4 +- hugo/content/en/serverless/aws_lambda/logs.md | 2 +- .../azure_app_service/windows_code.md | 2 +- .../azure_container_apps/_index.mdoc.md | 4 +- .../_index.md | 2 +- .../azure_cosmosdb.md | 2 +- .../azure_event_hubs.md | 2 +- .../azure_service_bus.md | 2 +- .../azure_functions/dotnet_extension.md | 2 +- .../guide/datadog_forwarder_node.md | 2 +- .../guide/datadog_forwarder_python.md | 2 +- .../guide/datadog_forwarder_ruby.md | 4 +- .../en/serverless/logic_apps/installation.md | 2 +- .../guide/slo-checklist.md | 2 +- hugo/content/en/session_replay/_index.md | 2 +- hugo/content/en/session_replay/dev_tools.md | 2 +- ...se-funnel-drop-offs-with-session-replay.md | 6 +- hugo/content/en/session_replay/heatmaps.md | 4 +- hugo/content/en/source_code/_index.md | 2 +- hugo/content/en/source_code/features.md | 14 +-- .../guide/api_test_timing_variations.md | 6 +- .../guide/canvas-content-javascript.md | 2 +- .../guide/explore-rum-through-synthetics.md | 4 +- .../manage-browser-tests-through-the-api.md | 2 +- .../platform/private_locations/_index.md | 2 +- .../en/synthetics/platform/settings/_index.md | 2 +- .../en/synthetics/troubleshooting/_index.md | 8 +- hugo/content/en/tests/_index.md | 18 +-- hugo/content/en/tests/browser_tests.md | 6 +- hugo/content/en/tests/code_coverage.md | 2 +- .../tests/correlate_logs_and_tests/_index.md | 4 +- hugo/content/en/tests/developer_workflows.md | 18 +-- hugo/content/en/tests/explorer/export.md | 2 +- .../en/tests/flaky_management/_index.md | 14 +-- .../en/tests/flaky_tests/auto_test_retries.md | 20 +-- .../flaky_tests/early_flake_detection.md | 4 +- hugo/content/en/tests/guides/_index.md | 2 +- .../en/tests/guides/add_custom_measures.md | 2 +- .../tests/guides/setup_new_flaky_pr_gate.md | 2 +- .../guides/validate_optimizations/_index.md | 4 +- hugo/content/en/tests/setup/_index.md | 8 +- hugo/content/en/tests/setup/bazel/_index.md | 4 +- hugo/content/en/tests/setup/bazel/go.md | 12 +- hugo/content/en/tests/setup/bazel/java.md | 8 +- hugo/content/en/tests/setup/bazel/python.md | 6 +- hugo/content/en/tests/setup/dotnet.md | 2 +- hugo/content/en/tests/setup/go.md | 2 +- hugo/content/en/tests/setup/java.md | 14 +-- hugo/content/en/tests/setup/javascript.md | 14 +-- hugo/content/en/tests/setup/junit_xml.md | 2 +- hugo/content/en/tests/setup/python.md | 4 +- hugo/content/en/tests/setup/ruby.md | 6 +- hugo/content/en/tests/setup/swift.md | 2 +- hugo/content/en/tests/swift_tests.md | 4 +- hugo/content/en/tests/test_health.md | 4 +- .../en/tests/test_impact_analysis/_index.md | 2 +- .../test_impact_analysis/how_it_works.md | 2 +- .../en/tests/test_parallelization/_index.md | 4 +- .../en/tests/test_parallelization/setup.md | 4 +- .../en/tests/troubleshooting/_index.md | 2 +- hugo/content/en/tracing/_index.md | 18 +-- hugo/content/en/tracing/code_origin/_index.md | 16 +-- .../en/tracing/error_tracking/_index.md | 8 +- .../error_tracking_assistant.md | 6 +- hugo/content/en/tracing/faq/_index.md | 2 +- .../tracing/faq/trace_sampling_and_storage.md | 2 +- hugo/content/en/tracing/guide/_index.md | 2 +- .../content/en/tracing/guide/apm_dashboard.md | 2 +- .../guide/ingestion_sampling_use_cases.md | 2 +- .../tracing/guide/instrument_custom_method.md | 16 +-- .../guide/send_traces_to_agent_by_api.md | 2 +- .../guide/serverless_enable_aws_xray.md | 4 +- .../serverless_enable_azure_app_insights.md | 6 +- .../guide/setting_primary_tags_to_scope.md | 2 +- .../en/tracing/guide/slowest_request_daily.md | 2 +- .../guide/trace_ingestion_volume_control.md | 2 +- .../guide/tutorial-enable-go-aws-ecs-ec2.md | 2 +- .../tutorial-enable-go-aws-ecs-fargate.md | 2 +- .../guide/tutorial-enable-java-aws-ecs-ec2.md | 2 +- .../tutorial-enable-java-aws-ecs-fargate.md | 2 +- .../en/tracing/live_debugger/_index.md | 10 +- .../live_debugger/bits-live-debugger.md | 6 +- .../connect_logs_and_traces/_index.md | 2 +- .../en/tracing/recommendations/_index.md | 12 +- .../en/tracing/services/inferred_services.md | 2 +- .../en/tracing/services/service_page.md | 16 +-- .../en/tracing/services/services_map.md | 2 +- .../en/tracing/services/tag_enrichment.md | 2 +- .../en/tracing/trace_collection/_index.md | 12 +- .../trace_collection/compatibility/_index.md | 2 +- .../compatibility/dotnet-framework.md | 2 +- .../trace_collection/compatibility/php.md | 4 +- .../trace_collection/compatibility/php_v0.md | 4 +- .../custom_instrumentation/_index.md | 2 +- .../trace_collection/dd_libraries/_index.md | 2 +- .../dd_libraries/dotnet-core.md | 4 +- .../dd_libraries/dotnet-framework.md | 4 +- .../trace_collection/dd_libraries/go.md | 2 +- .../trace_collection/dd_libraries/nodejs.md | 2 +- .../dynamic_instrumentation/_index.md | 28 ++--- .../enabling/dotnet.md | 8 +- .../dynamic_instrumentation/enabling/java.md | 8 +- .../dynamic_instrumentation/enabling/php.md | 8 +- .../enabling/python.md | 10 +- .../expression-language.md | 2 +- .../sensitive-data-scrubbing.md | 8 +- .../dynamic_instrumentation/symdb/_index.md | 8 +- .../dynamic_instrumentation/symdb/dotnet.md | 6 +- .../dynamic_instrumentation/symdb/java.md | 4 +- .../dynamic_instrumentation/symdb/python.md | 8 +- .../proxy_setup/apigateway.md | 2 +- .../proxy_setup/azure_apim.md | 2 +- .../trace_collection/proxy_setup/envoy.md | 6 +- .../trace_collection/proxy_setup/istio.md | 4 +- .../trace_collection/proxy_setup/kong.md | 2 +- .../trace_collection/proxy_setup/nginx.md | 2 +- .../trace_collection/span_links/_index.md | 2 +- .../en/tracing/trace_explorer/_index.md | 2 +- .../en/tracing/trace_explorer/visualize.md | 2 +- .../trace_pipeline/generate_metrics.md | 2 +- .../en/tracing/trace_pipeline/metrics.md | 2 +- .../tracing/trace_pipeline/trace_retention.md | 4 +- .../en/tracing/troubleshooting/_index.md | 4 +- 1115 files changed, 3647 insertions(+), 3647 deletions(-) diff --git a/hugo/content/en/account_management/api-app-keys.md b/hugo/content/en/account_management/api-app-keys.md index a78700b0255..5741bba76b4 100644 --- a/hugo/content/en/account_management/api-app-keys.md +++ b/hugo/content/en/account_management/api-app-keys.md @@ -54,7 +54,7 @@ The recommended best practice for scoping application keys is to grant your keys Action APIs include: - [App Builder][5] - [Actions Connections][6] -- [Workflow Automation][7] +- [{{< prodname >}}Workflow Automation{{< /prodname >}}][7] In order to use application keys with these APIs, you must enable Actions API access on the application key. This can be done [through the UI][2] or [API][21]. By default, application keys cannot be used with these APIs. diff --git a/hugo/content/en/account_management/audit_trail/_index.md b/hugo/content/en/account_management/audit_trail/_index.md index ba55306aab9..a2ae9ca0d74 100644 --- a/hugo/content/en/account_management/audit_trail/_index.md +++ b/hugo/content/en/account_management/audit_trail/_index.md @@ -43,7 +43,7 @@ For security admins or InfoSec teams, audit trail events help with compliance ch - For user logins, account, or role changes in your organization. -You can also analyze Audit Trail events with [Cloud SIEM][15] to detect threats and generate security signals. See [Getting Started with Cloud SIEM][16] for more information. +You can also analyze Audit Trail events with [{{< prodname >}}Cloud SIEM{{< /prodname >}}][15] to detect threats and generate security signals. See [Getting Started with Cloud SIEM][16] for more information. **Note**: Datadog's tools and policies comply with PCI v4.0. For more information, see [PCI DSS Compliance][2]. diff --git a/hugo/content/en/account_management/audit_trail/events.md b/hugo/content/en/account_management/audit_trail/events.md index 3c1782fc027..e068dd4742d 100644 --- a/hugo/content/en/account_management/audit_trail/events.md +++ b/hugo/content/en/account_management/audit_trail/events.md @@ -18,7 +18,7 @@ further_reading: ## Agent actor and delegation fields -In addition to product-specific events, Audit Trail events can carry actor and delegation metadata that identifies actions taken by a Datadog AI agent, such as Bits SRE, Bits Chat, Bits Security Analyst, and Bits Agent Builder. +In addition to product-specific events, Audit Trail events can carry actor and delegation metadata that identifies actions taken by a Datadog AI agent, such as Bits SRE, {{< prodname >}}Bits Chat{{< /prodname >}}, {{< prodname >}}Bits Security Analyst{{< /prodname >}}, and Bits Agent Builder. | Field | Description | | -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| diff --git a/hugo/content/en/account_management/audit_trail/guides/track_agentic_usage_in_your_organization.md b/hugo/content/en/account_management/audit_trail/guides/track_agentic_usage_in_your_organization.md index 51790bb47bf..b7e8efcf02c 100644 --- a/hugo/content/en/account_management/audit_trail/guides/track_agentic_usage_in_your_organization.md +++ b/hugo/content/en/account_management/audit_trail/guides/track_agentic_usage_in_your_organization.md @@ -13,7 +13,7 @@ further_reading: ## Overview -Datadog AI agents, including the Bits fleet (Bits SRE, Bits Chat, Bits Security Analyst) and Bits Agent Builder, can take actions inside your organization on their own or on behalf of a user. Audit Trail attributes these actions to the agent that performed them and, when applicable, to the user who authorized them. Onboarding to this attribution model varies by agent and by action type. This guide walks you through finding agent-driven events, filtering them by agent type, tracing an agent's actions back to the user who delegated them, and checking agent coverage. +Datadog AI agents, including the Bits fleet (Bits SRE, {{< prodname >}}Bits Chat{{< /prodname >}}, {{< prodname >}}Bits Security Analyst{{< /prodname >}}) and Bits Agent Builder, can take actions inside your organization on their own or on behalf of a user. Audit Trail attributes these actions to the agent that performed them and, when applicable, to the user who authorized them. Onboarding to this attribution model varies by agent and by action type. This guide walks you through finding agent-driven events, filtering them by agent type, tracing an agent's actions back to the user who delegated them, and checking agent coverage. ## Agent coverage @@ -69,7 +69,7 @@ To retrieve a user's complete activity, including delegated agent actions: ## Distinguish agent events from human events -Agent-driven events are marked with the agent's name and avatar (for example, Bits Chat) paired with the delegating user, labeled Co-authored by user + agent. This lets you distinguish agent activity from human activity without opening each event. +Agent-driven events are marked with the agent's name and avatar (for example, {{< prodname >}}Bits Chat{{< /prodname >}}) paired with the delegating user, labeled Co-authored by user + agent. This lets you distinguish agent activity from human activity without opening each event. ## Further reading diff --git a/hugo/content/en/account_management/billing/_index.md b/hugo/content/en/account_management/billing/_index.md index bcfb8eed104..62cb815ca5e 100644 --- a/hugo/content/en/account_management/billing/_index.md +++ b/hugo/content/en/account_management/billing/_index.md @@ -23,7 +23,7 @@ It is recommended that containers are monitored with a single containerized Agen Datadog bills based on the average number of functions per hour across the month for your accounts. Every hour, Datadog records the number of functions that were executed one or more times and monitored by your Datadog account. At the end of the month, Datadog charges by calculating the average of the hourly number of functions recorded. Pro and Enterprise plans include five custom metrics per billable function. -Billing for serverless APM is based on the sum of AWS Lambda invocations connected to APM ingested spans in a given month. You will also be billed for the total number of [indexed spans][4] submitted to the Datadog APM service exceeding the bundled quantity at the end of the month. There are no billable [APM Hosts][4] when using serverless. +Billing for serverless APM is based on the sum of AWS Lambda invocations connected to APM ingested spans in a given month. You will also be billed for the total number of [indexed spans][4] submitted to the {{< prodname >}}Datadog APM{{< /prodname >}} service exceeding the bundled quantity at the end of the month. There are no billable [APM Hosts][4] when using serverless. For more information, see the [Serverless billing page][5] and the [Datadog Pricing page][6]. diff --git a/hugo/content/en/account_management/billing/ai_credit_limits.md b/hugo/content/en/account_management/billing/ai_credit_limits.md index b399af35be7..784e72f114b 100644 --- a/hugo/content/en/account_management/billing/ai_credit_limits.md +++ b/hugo/content/en/account_management/billing/ai_credit_limits.md @@ -9,7 +9,7 @@ further_reading: ## Overview -Organization admins can set monthly caps on AI Credit usage at the organization level, the per-user level, or both. Admins can also override the default per-user limit for individual users. AI Credits are shared across [Bits Chat][1], [Bits Investigation][2], [Bits Code][3], and [Bits Agent Builder][4]. +Organization admins can set monthly caps on AI Credit usage at the organization level, the per-user level, or both. Admins can also override the default per-user limit for individual users. AI Credits are shared across [{{< prodname >}}Bits Chat{{< /prodname >}}][1], [Bits Investigation][2], [{{< prodname >}}Bits Code{{< /prodname >}}][3], and [Bits Agent Builder][4]. ## Permissions @@ -38,7 +38,7 @@ You can configure three types of monthly limits: - When both an organization limit and a user limit (or override) are configured, the most restrictive applicable limit applies to a user. - If a user has both a default per-user limit and an override configured, the higher of the two applies, and the user's usage is still subject to the organization-wide limit. - Raising a limit unblocks users who reached the previous limit. Lowering a limit blocks users whose usage already exceeds the new value. -- When a user or the organization reaches a limit, affected users can't use Bits Chat, Bits Investigation, Bits Code, or Bits Agent Builder, and a banner shows the reset date. +- When a user or the organization reaches a limit, affected users can't use {{< prodname >}}Bits Chat{{< /prodname >}}, Bits Investigation, {{< prodname >}}Bits Code{{< /prodname >}}, or Bits Agent Builder, and a banner shows the reset date. ### Examples diff --git a/hugo/content/en/account_management/billing/incident_response.md b/hugo/content/en/account_management/billing/incident_response.md index 4fd59142bb2..9e53e7aa5b7 100644 --- a/hugo/content/en/account_management/billing/incident_response.md +++ b/hugo/content/en/account_management/billing/incident_response.md @@ -14,11 +14,11 @@ further_reading: ## Overview -Datadog's [Incident Management][1], [On-Call][2], and Incident Response SKUs use a seat-based billing model. +Datadog's [{{< prodname >}}Incident Management{{< /prodname >}}][1], [{{< prodname >}}On-Call{{< /prodname >}}][2], and Incident Response SKUs use a seat-based billing model. Organizations have two options for incident response billing: -- Incident Management or On-Call as separate SKUs, each billed individually -- The Incident Response bundle, which unifies billing for both Incident Management and On-Call under a single SKU +- {{< prodname >}}Incident Management{{< /prodname >}} or {{< prodname >}}On-Call{{< /prodname >}} as separate SKUs, each billed individually +- The Incident Response bundle, which unifies billing for both {{< prodname >}}Incident Management{{< /prodname >}} and {{< prodname >}}On-Call{{< /prodname >}} under a single SKU Each product bills by seat, so each user who performs qualifying actions requires a seat license. For detailed pricing information, see the [Incident Response pricing page][3]. @@ -28,16 +28,16 @@ View and manage seat usage for each product in the [Seat Management][4] section A **seat** is a license for a user to actively participate in the on-call or incident management process in Datadog. -Any user can claim a seat for On-Call, Incident Management, or Incident Response as they perform actions that require a seat. Billing admins can also assign seats ahead of time to simplify the process for their teams. +Any user can claim a seat for {{< prodname >}}On-Call{{< /prodname >}}, {{< prodname >}}Incident Management{{< /prodname >}}, or Incident Response as they perform actions that require a seat. Billing admins can also assign seats ahead of time to simplify the process for their teams. -A user needs an **On-Call seat** if they perform any of the following: +A user needs an **{{< prodname >}}On-Call{{< /prodname >}} seat** if they perform any of the following: - Participate in an [on-call schedule][5] - Are included in an [escalation policy][6] - Have set up [notification preferences][7] to receive pages -In the On-Call product, a user does not need a seat to view existing pages, escalation policies, teams, or schedules. +In the {{< prodname >}}On-Call{{< /prodname >}} product, a user does not need a seat to view existing pages, escalation policies, teams, or schedules. -A user needs an **Incident Management seat** if they perform any of the following actions. These actions require a seat whether they are performed in the Datadog UI or through integrations such as Microsoft Teams or Slack. +A user needs an **{{< prodname >}}Incident Management{{< /prodname >}} seat** if they perform any of the following actions. These actions require a seat whether they are performed in the Datadog UI or through integrations such as Microsoft Teams or Slack. - Modify an incident (for example, update severity) - Delete an incident - Add a comment, graph, or link to an incident timeline @@ -46,11 +46,11 @@ A user needs an **Incident Management seat** if they perform any of the followin In Incident Management, a user does not need a seat to create incidents, view incidents, or join incident channels. Commenting in Slack, including posting messages that sync to the incident timeline, also does not require a seat. Only actions taken through the Datadog app in Slack, such as using action buttons or interacting with @Datadog, trigger a seat requirement. -If your organization has committed to the Incident Response SKU, any user who meets the On-Call or Incident Management criteria can claim or be assigned an **Incident Response seat**. +If your organization has committed to the Incident Response SKU, any user who meets the {{< prodname >}}On-Call{{< /prodname >}} or {{< prodname >}}Incident Management{{< /prodname >}} criteria can claim or be assigned an **Incident Response seat**. ### Status Pages usage -All paid Datadog customers can use Status Pages. Access depends on whether your organization has a committed Incident Management or Incident Response seat: +All paid Datadog customers can use Status Pages. Access depends on whether your organization has a committed {{< prodname >}}Incident Management{{< /prodname >}} or Incident Response seat: - **With at least one committed seat**: Full access, including unlimited pages and custom domains. - **Without a committed seat**: Limited to one Status Page and no custom domain support. @@ -60,10 +60,10 @@ If you are a trialing customer who would like full access during trial period, c ## Manage seats -The [Seat Management page][1] gives billing admins visibility and control over users who occupy seats for Incident Management, On-Call, or the Incident Response bundle. +The [Seat Management page][1] gives billing admins visibility and control over users who occupy seats for {{< prodname >}}Incident Management{{< /prodname >}}, {{< prodname >}}On-Call{{< /prodname >}}, or the Incident Response bundle. The Seat Management page contains tabs for each product enabled in your organization. Depending on your contract, you may see one of the following: -- Separate tabs for Incident Management and On-Call +- Separate tabs for {{< prodname >}}Incident Management{{< /prodname >}} and {{< prodname >}}On-Call{{< /prodname >}} - A single tab for Incident Response (if you use the bundle SKU) Each tab includes: @@ -75,7 +75,7 @@ Each tab includes: You can also find users by searching by name, email, or team. -On-Call admins can also use the [Notification Preferences settings page][9] to view which schedules or escalation policies a user belongs to and remove that user's notification preferences if needed. +{{< prodname >}}On-Call{{< /prodname >}} admins can also use the [Notification Preferences settings page][9] to view which schedules or escalation policies a user belongs to and remove that user's notification preferences if needed. Removing a user's notification preferences does not unassign their seat. If a user should no longer occupy a seat, you must explicitly unassign the user from the Seat Management Page. @@ -89,7 +89,7 @@ Billing admins, or users with the `billing_edit` permission, can manually assign To assign a seat: 1. Go to {{< ui >}}Plan & Usage{{< /ui >}} → {{< ui >}}Seat Management{{< /ui >}}. -2. Select the relevant product tab: {{< ui >}}Incident Management{{< /ui >}}, {{< ui >}}On-Call{{< /ui >}}, or {{< ui >}}Incident Response{{< /ui >}}. +2. Select the relevant product tab: {{< ui >}}{{< prodname >}}Incident Management{{< /prodname >}}{{< /ui >}}, {{< ui >}}{{< prodname >}}On-Call{{< /prodname >}}{{< /ui >}}, or {{< ui >}}Incident Response{{< /ui >}}. 3. Click {{< ui >}}Assign Seats{{< /ui >}}. 4. Search for users by name or email, and select them. 5. Click {{< ui >}}Assign Seats{{< /ui >}}. @@ -110,7 +110,7 @@ After they are unassigned, the user loses access to features that require a seat ### Claim a seat -When you try to perform an action that requires a seat (such as joining an On-Call schedule, updating an incident, or adding information to an incident timeline) Datadog prompts you to claim a seat. Claiming a seat requires at least one of the following permissions: `billing_read`, `on_call_read`, or `incident_read`. +When you try to perform an action that requires a seat (such as joining an {{< prodname >}}On-Call{{< /prodname >}} schedule, updating an incident, or adding information to an incident timeline) Datadog prompts you to claim a seat. Claiming a seat requires at least one of the following permissions: `billing_read`, `on_call_read`, or `incident_read`. After you claim a seat, the following items change in Datadog: - You immediately gain access to the product features you need (for example, receiving pages or managing incidents). @@ -122,7 +122,7 @@ You only need to claim a seat once. After a seat is assigned, you continue to ha ## Billing and overages -Datadog bills for On-Call, Incident Management, and Incident Response based on the total number of seats in use during each billing period. +Datadog bills for {{< prodname >}}On-Call{{< /prodname >}}, {{< prodname >}}Incident Management{{< /prodname >}}, and Incident Response based on the total number of seats in use during each billing period. Each billing period reflects the maximum number of concurrently assigned seats across your organization for that product. Your contract includes a committed number of seats, and any usage beyond that amount is billed at your on-demand rate. diff --git a/hugo/content/en/account_management/billing/pricing.md b/hugo/content/en/account_management/billing/pricing.md index a158134723d..61dd88b20eb 100644 --- a/hugo/content/en/account_management/billing/pricing.md +++ b/hugo/content/en/account_management/billing/pricing.md @@ -11,7 +11,7 @@ Datadog has many pricing plans to fit your needs. For more information, see the ## Billing plans -Datadog offers two billing plans for host-based products, such as Infrastructure Monitoring, APM, and Database Monitoring: +Datadog offers two billing plans for host-based products, such as {{< prodname >}}Infrastructure Monitoring{{< /prodname >}}, APM, and {{< prodname >}}Database Monitoring{{< /prodname >}}: - **High watermark plan (HWMP)**: Datadog meters your host count each hour. At the end of the month, Datadog bills you on the maximum count (high-water mark) of the lower 99% of those hourly readings, excluding the top 1% to reduce the impact of short usage spikes on your bill. This plan is well-suited to environments with stable usage throughout the month. - **Hybrid monthly/hourly plan (MHP)**: You commit to a monthly minimum, and any host hours above that commitment are billed at an hourly rate. Because usage above the commitment is billed hourly, this plan is well-suited to ephemeral environments, such as autoscaling fleets or short-lived workloads. @@ -33,8 +33,8 @@ The following sections describe the most common pricing units for each product. * If an application running on a host (defined in [Infrastructure monitoring](#infrastructure-monitoring)) generates traces and submits them to the Datadog SaaS application, Datadog counts that host as one **APM host**. * On a high watermark plan (HWMP), Datadog meters the count of hosts hourly. The billable count of hosts is calculated at the end of the month using the maximum count (high-water mark) of the lower 99 percent of usage for those hours. Datadog excludes the top 1 percent to reduce the impact of spikes in usage on your bill. * On a hybrid monthly/hourly plan (MHP), Datadog charges your minimum monthly commitment, and for any host hours above that commitment, Datadog charges an hourly rate. -* An **Indexed Span** is an individual request against an individual service in your stack. Datadog charges based on the total number of spans indexed by [retention filters][3] within Datadog APM. -* An **Ingested Span** is an individual request against an individual service in your stack. Datadog charges based on the total number of gigabytes of spans ingested into Datadog APM. +* An **Indexed Span** is an individual request against an individual service in your stack. Datadog charges based on the total number of spans indexed by [retention filters][3] within {{< prodname >}}Datadog APM{{< /prodname >}}. +* An **Ingested Span** is an individual request against an individual service in your stack. Datadog charges based on the total number of gigabytes of spans ingested into {{< prodname >}}Datadog APM{{< /prodname >}}. You can put controls in place for both Indexed and Ingested span volumes. For more information, read the [Trace Ingestion][4] and [Retention][5] documentation. @@ -86,7 +86,7 @@ You can put controls in place for both Indexed and Ingested span volumes. For mo ## Incident Management * For organizations on a seat-based plan, Datadog charges based on your organization's seat commitment. -* For organizations on the legacy usage-based plan, Datadog tracks the number of monthly active Incident Management users. +* For organizations on the legacy usage-based plan, Datadog tracks the number of monthly active {{< prodname >}}Incident Management{{< /prodname >}} users. * Datadog counts a user as an **active user** if they have used Datadog capabilities to contribute substantively to the incident response. For example, you become an active user for the month when you: * Update an incident's state, severity, or other fields * Comment on the incident's timeline diff --git a/hugo/content/en/account_management/billing/serverless.md b/hugo/content/en/account_management/billing/serverless.md index 6b983bb2a99..e40b6d5caa0 100644 --- a/hugo/content/en/account_management/billing/serverless.md +++ b/hugo/content/en/account_management/billing/serverless.md @@ -51,7 +51,7 @@ Datadog provides multiple tools to manage the installation and configuration of Datadog bills based on the average number of functions per hour across the month for your accounts. Every hour, Datadog records the number of functions that were executed one or more times and monitored by your Datadog account. At the end of the month, Datadog charges by calculating the average of the hourly number of functions recorded. Pro and Enterprise plans include five custom metrics per billable function. A single billable function is defined by a unique function ARN. In the case of Lambda@Edge functions, each function in a different region is counted as a separate billable function. -Billing for serverless APM is based on the sum of AWS Lambda invocations connected to APM ingested spans in a given month. You are also billed for the total number of [indexed spans][4] submitted to the Datadog APM service exceeding the bundled quantity at the end of the month. There are no billable [APM Hosts][4] when using serverless. +Billing for serverless APM is based on the sum of AWS Lambda invocations connected to APM ingested spans in a given month. You are also billed for the total number of [indexed spans][4] submitted to the {{< prodname >}}Datadog APM{{< /prodname >}} service exceeding the bundled quantity at the end of the month. There are no billable [APM Hosts][4] when using serverless. ## Troubleshooting diff --git a/hugo/content/en/account_management/billing/workflow_automation.md b/hugo/content/en/account_management/billing/workflow_automation.md index fed60eaf034..281979dbe7b 100644 --- a/hugo/content/en/account_management/billing/workflow_automation.md +++ b/hugo/content/en/account_management/billing/workflow_automation.md @@ -4,7 +4,7 @@ title: Workflow Automation ## Overview -Datadog [Workflow Automation][8] billing is based on the number of **workflow executions**. Workflow executions are recorded whenever a published workflow runs, regardless of its run method (manually, programmatically, or automatically), except for the cases listed under [Included automations](#included-automations). +Datadog [{{< prodname >}}Workflow Automation{{< /prodname >}}][8] billing is based on the number of **workflow executions**. Workflow executions are recorded whenever a published workflow runs, regardless of its run method (manually, programmatically, or automatically), except for the cases listed under [Included automations](#included-automations). ## Summary - **Billing metric**: You incur a cost per committed execution or on-demand execution, depending on your billing plan. Specific pricing can be found on the [Workflow Automation pricing page][13]. @@ -12,7 +12,7 @@ Datadog [Workflow Automation][8] billing is based on the number of **workflow ex - **Visibility**: Usage and cost breakdowns are available in [Plan & Usage][1]. - **Exceptions for certain SKUs**: - CSM/DevSecOps SKUs include 5-20 executions per host. - - [Incident Management][9], [On-Call][10], and [App Builder][11] SKUs include free unlimited executions when triggered by events from these products. + - [{{< prodname >}}Incident Management{{< /prodname >}}][9], [{{< prodname >}}On-Call{{< /prodname >}}][10], and [App Builder][11] SKUs include free unlimited executions when triggered by events from these products. ## Pricing model @@ -22,7 +22,7 @@ A workflow execution refers to one full run of a published workflow, regardless - API or programmatic triggers - Event-based triggers (monitors, incidents, etc.) - Workflows triggered from other workflows - - **Note**: When a workflow triggers another workflow, billing is determined by the original (root) trigger of the chain. If the root trigger is a billed source (such as a monitor or API call), every workflow in the chain is billed. If the root trigger is a free source (for example, Incident Management, On-Call, or App Builder), the entire chain is free, regardless of depth. + - **Note**: When a workflow triggers another workflow, billing is determined by the original (root) trigger of the chain. If the root trigger is a billed source (such as a monitor or API call), every workflow in the chain is billed. If the root trigger is a free source (for example, {{< prodname >}}Incident Management{{< /prodname >}}, {{< prodname >}}On-Call{{< /prodname >}}, or App Builder), the entire chain is free, regardless of depth. Unpublished (test or draft) runs are **not billed**. @@ -36,7 +36,7 @@ Failed executions are not exempt from billing. All published executions are bill ### Billing metrics -Workflow Automation is billed **per execution**. This means that each workflow run counts toward your bill. +{{< prodname >}}Workflow Automation{{< /prodname >}} is billed **per execution**. This means that each workflow run counts toward your bill. The two billing options are committed executions and on-demand executions. Committed executions are purchased in advance, while on-demand executions are billed as they occur. Prepaid executions cost less than on-demand executions. @@ -46,7 +46,7 @@ The best source of truth for billing is on your [Datadog Plan & Usage page][1], Other sources of usage tracking that do not include billing metrics are the [Workflow Automation API][7] and the [Workflows Overview dashboard][2]. Through the API, you can view granular information such as [all instances of a given workflow][12]. The Workflows Overview dashboard is based on execution metrics, before any billing considerations take place. Additionally, the dashboard does not reflect billing complexities such as free allotments of workflows. ## Included workflow allotments by SKU -Certain Datadog SKUs include Workflow Automation allotments as part of their pricing: +Certain Datadog SKUs include {{< prodname >}}Workflow Automation{{< /prodname >}} allotments as part of their pricing: | SKU | Included Workflow Executions | Allotment Basis | |---------------------------|------------------------------|-----------------| @@ -59,11 +59,11 @@ These included executions are automatically applied to your account each month a ### Included automations Workflows triggered automatically or manually by events from the following products are **free** and included in their respective SKU pricing: -- [**Incident Management**][9] -- [**On-Call**][10] +- [**{{< prodname >}}Incident Management{{< /prodname >}}**][9] +- [**{{< prodname >}}On-Call{{< /prodname >}}**][10] - [**App Builder**][11] -This means that if your automation originates from one of these services, those executions **do not count** toward your Workflow Automation bill. For example, a workflow triggered by an incident creation or an on-call handover does not incur a cost. +This means that if your automation originates from one of these services, those executions **do not count** toward your {{< prodname >}}Workflow Automation{{< /prodname >}} bill. For example, a workflow triggered by an incident creation or an on-call handover does not incur a cost. [1]: https://app.datadoghq.com/billing/usage?selected_cost_products=workflow_execution [2]: https://app.datadoghq.com/dash/integration/30994/workflows-overview?fromUser=false&refresh_mode=sliding&from_ts=1760203373269&to_ts=1762885373269&live=true diff --git a/hugo/content/en/account_management/multi_organization.md b/hugo/content/en/account_management/multi_organization.md index 9522e126cef..abeadfe58ef 100644 --- a/hugo/content/en/account_management/multi_organization.md +++ b/hugo/content/en/account_management/multi_organization.md @@ -118,7 +118,7 @@ The Overall Usage section shows the monthly aggregate usage across all organizat {{< img src="account_management/multi-org-v2-trends.png" alt="Overall Usage Long-term trends" >}} -Both the Month-to-Date Total Usage section and the Overall Usage section can be filtered by clicking on product specific sub-tabs. In the "Log Management" sub-tab, you can view the Logs Usage by Index table, which displays your month-to-date and last month's indexed log usage by: +Both the Month-to-Date Total Usage section and the Overall Usage section can be filtered by clicking on product specific sub-tabs. In the "{{< prodname >}}Log Management{{< /prodname >}}" sub-tab, you can view the Logs Usage by Index table, which displays your month-to-date and last month's indexed log usage by: * Index name * Organization diff --git a/hugo/content/en/account_management/org_settings/cross_org_visibility.md b/hugo/content/en/account_management/org_settings/cross_org_visibility.md index 4b9a3bf9dec..d498dfd5b64 100644 --- a/hugo/content/en/account_management/org_settings/cross_org_visibility.md +++ b/hugo/content/en/account_management/org_settings/cross_org_visibility.md @@ -37,7 +37,7 @@ Cross-organization visibility supports the following telemetry in [Dashboard and * Metrics (all types supported, including [custom metrics][3], [trace metrics][4], and [metrics generated from logs][5]) * Logs * CI Visibility pipelines -* Test Optimization tests +* {{< prodname >}}Test Optimization{{< /prodname >}} tests * Audit Trail ## Configure connections diff --git a/hugo/content/en/account_management/org_settings/ip_allowlist.md b/hugo/content/en/account_management/org_settings/ip_allowlist.md index 5d5e00a0ac8..fb8309c00fb 100644 --- a/hugo/content/en/account_management/org_settings/ip_allowlist.md +++ b/hugo/content/en/account_management/org_settings/ip_allowlist.md @@ -23,7 +23,7 @@ If a user's IP is not contained in the IP allowlist, they are effectively blocke - Datadog's public [API][1], including both documented and unpublished endpoints - Datadog's mobile apps (iOS, Android) - Third-party integrations and applications that access Datadog through OAuth -- The [Datadog MCP Server][9], including remote connections from AI agents and MCP clients +- The [{{< prodname >}}Datadog MCP Server{{< /prodname >}}][9], including remote connections from AI agents and MCP clients The IP allowlist feature does not block access to the following: - Data ingest endpoints to which the Agent sends data, such as metrics, traces, and logs diff --git a/hugo/content/en/account_management/plan_and_usage/bill_overview.md b/hugo/content/en/account_management/plan_and_usage/bill_overview.md index 1035a1c76a7..cf88c3c22bc 100644 --- a/hugo/content/en/account_management/plan_and_usage/bill_overview.md +++ b/hugo/content/en/account_management/plan_and_usage/bill_overview.md @@ -97,7 +97,7 @@ Click {{< ui >}}View Details{{< /ui >}} on a Trends card or click any row in the - {{< ui >}}Projected Cost Change{{< /ui >}}: The projected dollar and percentage change vs. the prior period - {{< ui >}}Projected EOM{{< /ui >}}: Estimated total cost at end of month - {{< ui >}}Daily Cost{{< /ui >}} bar chart: Day-by-day cost for the previous and current month, with the current month highlighted. Hover over any bar to see the cost for that day. Toggle {{< ui >}}Show Usage Charges Only{{< /ui >}} to isolate on-demand charges. -- {{< ui >}}Drilldown in Cloud Cost{{< /ui >}}: Click to open Cloud Cost Management, pre-filtered to the selected billing dimension. +- {{< ui >}}Drilldown in Cloud Cost{{< /ui >}}: Click to open {{< prodname >}}Cloud Cost Management{{< /prodname >}}, pre-filtered to the selected billing dimension. ### Usage Overview diff --git a/hugo/content/en/account_management/plan_and_usage/cost_details.md b/hugo/content/en/account_management/plan_and_usage/cost_details.md index 8b3e7bda0af..81e6df77aed 100644 --- a/hugo/content/en/account_management/plan_and_usage/cost_details.md +++ b/hugo/content/en/account_management/plan_and_usage/cost_details.md @@ -25,7 +25,7 @@ You can break down your costs by sub-organization and by product to: - Allocate costs according to their source - Gain insight into how costs are tracking -For visibility into daily Datadog spending in Cloud Cost Explorer, dashboards, and [cost monitors][7], see [Datadog Costs][8] under Cloud Cost Management. +For visibility into daily Datadog spending in Cloud Cost Explorer, dashboards, and [cost monitors][7], see [Datadog Costs][8] under {{< prodname >}}Cloud Cost Management{{< /prodname >}}. ### Permissions diff --git a/hugo/content/en/account_management/plan_and_usage/usage_details.md b/hugo/content/en/account_management/plan_and_usage/usage_details.md index 9639762a1b8..986fd393981 100644 --- a/hugo/content/en/account_management/plan_and_usage/usage_details.md +++ b/hugo/content/en/account_management/plan_and_usage/usage_details.md @@ -130,7 +130,7 @@ For more details on your metrics, navigate to the [Metrics Summary][7] by hoveri ## Logs usage by index -In the Log Management tab, this table displays your hourly, daily, monthly, and annual indexed log usage by index name and retention period. It also shows the breakdown between live logs and [rehydrated logs][8]. The following information is provided: +In the {{< prodname >}}Log Management{{< /prodname >}} tab, this table displays your hourly, daily, monthly, and annual indexed log usage by index name and retention period. It also shows the breakdown between live logs and [rehydrated logs][8]. The following information is provided: * Index name * Retention period in days diff --git a/hugo/content/en/account_management/rbac/data_access.md b/hugo/content/en/account_management/rbac/data_access.md index bee9fc060e8..4fae41cb4ec 100644 --- a/hugo/content/en/account_management/rbac/data_access.md +++ b/hugo/content/en/account_management/rbac/data_access.md @@ -46,7 +46,7 @@ Name Dataset : A descriptive name to help users understand what data is contained in the dataset. Select data to be included in this Dataset -: The boundary definition that describes which data to restrict to a specific set of users. Boundaries are query statements with limitations that allow an access manager to define the scope of sensitive data to be protected. The [supported telemetry types][10] are custom metrics, RUM sessions, APM traces, logs, cloud costs, error tracking issues, Software Delivery repository info (CI Visibility pipelines), Workload Protection Agent Events, and security signals (Cloud SIEM signals only). +: The boundary definition that describes which data to restrict to a specific set of users. Boundaries are query statements with limitations that allow an access manager to define the scope of sensitive data to be protected. The [supported telemetry types][10] are custom metrics, RUM sessions, APM traces, logs, cloud costs, error tracking issues, {{< prodname >}}Software Delivery{{< /prodname >}} repository info (CI Visibility pipelines), Workload Protection Agent Events, and security signals ({{< prodname >}}Cloud SIEM{{< /prodname >}} signals only). Grant access : Select one or more teams or roles that may access the content bound in the Restricted Dataset. Any users who are not members of these groups are blocked from accessing this data. @@ -61,20 +61,20 @@ You may create a maximum of 100 Restricted Datasets under the Enterprise plan, a ### Supported telemetry types {#supported-telemetry} -- Agent Observability traces +- {{< prodname >}}Agent Observability{{< /prodname >}} traces - APM traces - Cloud costs -- Error Tracking issues +- {{< prodname >}}Error Tracking{{< /prodname >}} issues - Logs - RUM sessions -- Security signals (Cloud SIEM signals only) -- Software Delivery repository info (in CI Visibility pipelines) +- Security signals ({{< prodname >}}Cloud SIEM{{< /prodname >}} signals only) +- {{< prodname >}}Software Delivery{{< /prodname >}} repository info (in CI Visibility pipelines) - Workload Protection Agent Events The following are available as a Preview upon request: - Custom metrics - **Note:** Standard and OpenTelemetry (OTel) metrics are not supported -- Database Monitoring +- {{< prodname >}}Database Monitoring{{< /prodname >}} - Hosts - Processes @@ -130,8 +130,8 @@ If you are concerned about unauthorized data access through monitors, Datadog re ### Software Delivery repository info (CI Visibility pipelines) -* **Supported telemetry**: Only CI Visibility pipelines are supported. Test Optimizations tests are not supported. -* **CI Logs**: CI Logs are stored in the Log Management product. To restrict access to CI Logs, create a Logs dataset. +* **Supported telemetry**: Only CI Visibility pipelines are supported. {{< prodname >}}Test Optimization{{< /prodname >}}s tests are not supported. +* **CI Logs**: CI Logs are stored in the {{< prodname >}}Log Management{{< /prodname >}} product. To restrict access to CI Logs, create a Logs dataset. * **Supported dataset tags**: Only the following tags are supported: * `@git.repository_url` * `@git.repository.id` @@ -140,8 +140,8 @@ If you are concerned about unauthorized data access through monitors, Datadog re ### Agent Observability -* **Supported telemetry**: Agent Observability traces are supported. Experiment event data (spans and evaluation metrics) for experiments in a project is also restricted by `ml_app`-keyed Restricted Datasets. Only the event data is restricted—experiment list views and metadata are not. Datasets, annotation queues, and managed prompts are not supported. -* **OpenTelemetry**: When using [OpenTelemetry instrumentation][13], some data sent to Agent Observability may also be written to APM traces, as well as metrics and monitors. If you are protecting sensitive data with a Restricted Dataset on Agent Observability, consider also configuring Restricted Datasets on APM, metrics, or monitors with matching data boundaries. +* **Supported telemetry**: {{< prodname >}}Agent Observability{{< /prodname >}} traces are supported. Experiment event data (spans and evaluation metrics) for experiments in a project is also restricted by `ml_app`-keyed Restricted Datasets. Only the event data is restricted—experiment list views and metadata are not. Datasets, annotation queues, and managed prompts are not supported. +* **OpenTelemetry**: When using [OpenTelemetry instrumentation][13], some data sent to {{< prodname >}}Agent Observability{{< /prodname >}} may also be written to APM traces, as well as metrics and monitors. If you are protecting sensitive data with a Restricted Dataset on {{< prodname >}}Agent Observability{{< /prodname >}}, consider also configuring Restricted Datasets on APM, metrics, or monitors with matching data boundaries. ## Select tags for access diff --git a/hugo/content/en/account_management/teams/_index.md b/hugo/content/en/account_management/teams/_index.md index a3008d8fd72..c366a6dcc44 100644 --- a/hugo/content/en/account_management/teams/_index.md +++ b/hugo/content/en/account_management/teams/_index.md @@ -84,7 +84,7 @@ Datadog supports associating the following resources with team handles: - [Dashboards][5] - [Incidents][6] - [Monitors][7] -- [Resource Catalog][8] +- [{{< prodname >}}Resource Catalog{{< /prodname >}}][8] - [Catalog][9] - [Service Level Objectives][10] - Synthetic Tests, Global Variables, Private Locations diff --git a/hugo/content/en/account_management/teams/manage.md b/hugo/content/en/account_management/teams/manage.md index eb9cb426f9b..fa19dae5246 100644 --- a/hugo/content/en/account_management/teams/manage.md +++ b/hugo/content/en/account_management/teams/manage.md @@ -11,7 +11,7 @@ The team detail page is organized into three tabs: - **Info**: Core team details and membership. - **Resources**: The Datadog resources associated with the team. -- **On-Call**: The team's [Datadog On-Call][6] configuration. +- **{{< prodname >}}On-Call{{< /prodname >}}**: The team's [Datadog On-Call][6] configuration. The team header displays the team's avatar, banner, name, and description. Customize the look of your team by choosing an emoji avatar and banner. The emoji avatar displays next to the team name in lists across Datadog. diff --git a/hugo/content/en/actions/_index.md b/hugo/content/en/actions/_index.md index 49d0d605dfb..0acbfd99ea1 100644 --- a/hugo/content/en/actions/_index.md +++ b/hugo/content/en/actions/_index.md @@ -6,12 +6,12 @@ private: true ## Components {{< whatsnext desc="Explore Actions Components" >}} - {{< nextlink href="/actions/workflows/" >}}Workflow Automation - Orchestrate and automate end-to-end processes with workflows that connect actions across your infrastructure and tools.{{< /nextlink >}} + {{< nextlink href="/actions/workflows/" >}}{{< prodname >}}Workflow Automation{{< /prodname >}} - Orchestrate and automate end-to-end processes with workflows that connect actions across your infrastructure and tools.{{< /nextlink >}} {{< nextlink href="/actions/app_builder/" >}}App Builder - Build internal tools with a low-code, drag-and-drop interface.{{< /nextlink >}} {{< nextlink href="/actions/connections/" >}}Connections - Manage connections for actions.{{< /nextlink >}} {{< nextlink href="/actions/agents/" >}}Agents - Build custom AI agents that can access the Action Catalog.{{< /nextlink >}} {{< nextlink href="/actions/actions_catalog/" >}}Action Catalog - Browse and discover actions across cloud providers, SaaS tools, and Datadog services.{{< /nextlink >}} - {{< nextlink href="/actions/datastores/" >}}Datastores - Scalable, structured data storage for App Builder and Workflow Automation.{{< /nextlink >}} + {{< nextlink href="/actions/datastores/" >}}Datastores - Scalable, structured data storage for App Builder and {{< prodname >}}Workflow Automation{{< /prodname >}}.{{< /nextlink >}} {{< nextlink href="/actions/forms/" >}}Forms - Build forms to collect input, analyze responses, and trigger automations.{{< /nextlink >}} {{< nextlink href="/actions/private_actions/" >}}Private Actions - Interact with private network services using Docker-based private action runners.{{< /nextlink >}} {{< /whatsnext >}} diff --git a/hugo/content/en/actions/actions_catalog/_index.md b/hugo/content/en/actions/actions_catalog/_index.md index 68b819a47c5..066cae3ac59 100644 --- a/hugo/content/en/actions/actions_catalog/_index.md +++ b/hugo/content/en/actions/actions_catalog/_index.md @@ -16,6 +16,6 @@ cascade: rank: 40 --- -The Datadog Action Catalog provides actions that can be performed against your infrastructure and integrations using either the Workflow Automation or App Builder products. You can orchestrate and automate your end-to-end processes by linking together actions that perform tasks in your cloud providers, SaaS tools, and Datadog accounts. +The Datadog Action Catalog provides actions that can be performed against your infrastructure and integrations using either the {{< prodname >}}Workflow Automation{{< /prodname >}} or App Builder products. You can orchestrate and automate your end-to-end processes by linking together actions that perform tasks in your cloud providers, SaaS tools, and Datadog accounts. See below for a list of all available actions. Click an action to see its description, inputs, outputs, and parameters. diff --git a/hugo/content/en/actions/agents/_index.md b/hugo/content/en/actions/agents/_index.md index e64c6283f38..6aceabd2685 100644 --- a/hugo/content/en/actions/agents/_index.md +++ b/hugo/content/en/actions/agents/_index.md @@ -19,7 +19,7 @@ further_reading: text: "Case Management Integration with Bits Agent Builder" --- -{{< callout url="https://www.datadoghq.com/product-preview/custom-agents-in-case-management/" btn_hidden="false" header="Case Management integration is in Preview" >}} +{{< callout url="https://www.datadoghq.com/product-preview/custom-agents-in-case-management/" btn_hidden="false" header="{{< prodname >}}Case Management{{< /prodname >}} integration is in Preview" >}} Automatically assign custom agents to work on your Cases. {{< /callout >}} @@ -84,11 +84,11 @@ Tools define what actions the agent can take. Add tools from the [Action Catalog Click on any added tool to hardcode its parameters. For example, lock a Slack tool to a specific channel or a logs query to a specific service. -The [Datadog MCP Server][8] is enabled by default. You can connect to any API using [custom HTTP actions][12]. +The [{{< prodname >}}Datadog MCP Server{{< /prodname >}}][8] is enabled by default. You can connect to any API using [custom HTTP actions][12]. ### Automations -Set up your agent to run automatically with a [schedule][13], or trigger it from a Datadog [monitor][14], [incident][15], or [security signal][16]. These automations use [Workflow Automation][9]. +Set up your agent to run automatically with a [schedule][13], or trigger it from a Datadog [monitor][14], [incident][15], or [security signal][16]. These automations use [{{< prodname >}}Workflow Automation{{< /prodname >}}][9]. ## Test your agent @@ -96,11 +96,11 @@ Use the built-in chat interface to test your agent. Send messages, review the ag ## Agent orchestration -Use agents in [Workflow Automation][9] and [App Builder][10] through the **Run Agent** action. This lets you embed AI reasoning into any workflow: +Use agents in [{{< prodname >}}Workflow Automation{{< /prodname >}}][9] and [App Builder][10] through the **Run Agent** action. This lets you embed AI reasoning into any workflow: {{< img src="/actions/agents/run-agent-step.png" alt="The Run Agent step configuration in a workflow, showing agent selection, run instructions, conversation ID, and output schema fields" style="width:100%;" >}} -1. Open or create a workflow in [Workflow Automation][9], or open or create an app in [App Builder][10]. +1. Open or create a workflow in [{{< prodname >}}Workflow Automation{{< /prodname >}}][9], or open or create an app in [App Builder][10]. 1. Add the **Run Agent** step from the action catalog. 1. Select which agent to run. 1. Write the **Run Instructions**—the prompt the agent receives each time it runs. Use variables such as `{{Source.form}}` to pass in trigger data. diff --git a/hugo/content/en/actions/app_builder/_index.md b/hugo/content/en/actions/app_builder/_index.md index 39df1e1b224..11e534284f4 100644 --- a/hugo/content/en/actions/app_builder/_index.md +++ b/hugo/content/en/actions/app_builder/_index.md @@ -54,7 +54,7 @@ App Builder is in Preview on Datadog Government site US1-FED. Datadog App Builder is a low-code application building platform. It streamlines the development of your internal tools with a user-friendly drag-and-drop interface and built-in support for JavaScript. App Builder integrates with popular services such as AWS and GitHub, allowing you to leverage data and seamlessly connect with external APIs and data stores. By integrating with Datadog's existing capabilities, App Builder provides a centralized context that enables you to take preventive actions or respond to ongoing incidents, all from within the same view that you use for troubleshooting. -For more complex applications that require a local development workflow, source control, or collaboration across multiple engineers, see [Datadog Apps][10] to build apps as code. +For more complex applications that require a local development workflow, source control, or collaboration across multiple engineers, see [{{< prodname >}}Datadog Apps{{< /prodname >}}][10] to build apps as code. {{< img src="/actions/app_builder/app-builder-app.png" alt="An app in App Builder" caption="An app in App Builder" style="width:100%;" >}} @@ -73,7 +73,7 @@ Datadog App Builder provides an [Action Catalog][1] of hundreds of actions acros ## Take action directly from dashboards -You can use your apps from the Apps page or [access them directly from within your dashboards][6]. Datadog Apps function as native dashboard integrations, allowing you to customize and take action on your data straight from your dashboard. +You can use your apps from the Apps page or [access them directly from within your dashboards][6]. {{< prodname >}}Datadog Apps{{< /prodname >}} function as native dashboard integrations, allowing you to customize and take action on your data straight from your dashboard. {{< img src="/actions/app_builder/app-builder-embedded-dashboard-2.png" alt="An ECS Task Balancer app embedded in a dashboard, with a cursor clicking the Scale Service button" caption="An ECS Task Balancer app embedded in a dashboard, with a cursor clicking a button on it" style="width:100%;" >}} diff --git a/hugo/content/en/actions/app_builder/queries.md b/hugo/content/en/actions/app_builder/queries.md index 5224997641c..72b55ae5da1 100644 --- a/hugo/content/en/actions/app_builder/queries.md +++ b/hugo/content/en/actions/app_builder/queries.md @@ -25,7 +25,7 @@ To add a query, click the Data ({{< ui >}}{ }{{< /ui >}}) icon to open the You can also use Bits AI to add, configure, and trigger queries. Click the {{< ui >}}Build with AI{{< /ui >}} icon (****) to get started. -Queries rely on [Connections][5] for authentication. App Builder shares connections with [Workflow Automation][6]. +Queries rely on [Connections][5] for authentication. App Builder shares connections with [{{< prodname >}}Workflow Automation{{< /prodname >}}][6]. ## Run settings @@ -139,7 +139,7 @@ When executing a query, App Builder performs the following steps in the order li ## Example apps ### Return workflow results to an app -App Builder queries can trigger Workflow Automation workflows. Apps can then use the results of those workflows. +App Builder queries can trigger {{< prodname >}}Workflow Automation{{< /prodname >}} workflows. Apps can then use the results of those workflows. This app provides a button to trigger a workflow. The workflow sends a poll to a Slack channel asking the user to pick from one of two options. Based on the option the user chooses, the workflow issues one of two different HTTP GET requests, which then returns data that is displayed in the app. diff --git a/hugo/content/en/actions/connections/_index.md b/hugo/content/en/actions/connections/_index.md index 158f531141a..97378b48afd 100644 --- a/hugo/content/en/actions/connections/_index.md +++ b/hugo/content/en/actions/connections/_index.md @@ -50,7 +50,7 @@ If the integration you need to set up is not listed above, set up connection cre ## Connection credentials -Connections extend your installed integrations to give you control over workflow step authentication. Use connection credentials to authenticate a [generic action][8] or any action for which the integration tile does not offer authentication. For a list of integrations that use the integration tile for authentication, see the [Integration tile credentials](#integration-tile-credentials) section. Connection credentials are only available for use within the Workflow Automation and App Builder products. +Connections extend your installed integrations to give you control over workflow step authentication. Use connection credentials to authenticate a [generic action][8] or any action for which the integration tile does not offer authentication. For a list of integrations that use the integration tile for authentication, see the [Integration tile credentials](#integration-tile-credentials) section. Connection credentials are only available for use within the {{< prodname >}}Workflow Automation{{< /prodname >}} and App Builder products. Connections support the following example use cases: - The integration you need is not available as a built-in connection. @@ -133,7 +133,7 @@ The example below shows the {{< ui >}}New Connection{{< /ui >}} dialog box for t ### Restrict connection use -To learn how to restrict connection use, see Access and Authentication for [Workflow Automation][12] or [App Builder][15]. +To learn how to restrict connection use, see Access and Authentication for [{{< prodname >}}Workflow Automation{{< /prodname >}}][12] or [App Builder][15]. ## HTTP connection diff --git a/hugo/content/en/actions/connections/aws_integration.md b/hugo/content/en/actions/connections/aws_integration.md index 56d01030abf..533b8c4c6ee 100644 --- a/hugo/content/en/actions/connections/aws_integration.md +++ b/hugo/content/en/actions/connections/aws_integration.md @@ -70,7 +70,7 @@ To configure the {{< ui >}}Executor{{< /ui >}} permission for the Datadog AWS In ### 2. Add the integration to an action -1. In [Workflow Automation][5], click the workflow you want to edit. +1. In [{{< prodname >}}Workflow Automation{{< /prodname >}}][5], click the workflow you want to edit. 1. Add an AWS action, such as {{< ui >}}List ECS Clusters{{< /ui >}}. 1. In the configuration pane, click the {{< ui >}}Connection{{< /ui >}} dropdown and scroll to {{< ui >}}Existing AWS Integrations{{< /ui >}}. 1. Select the AWS Account you configured in step one. diff --git a/hugo/content/en/actions/datadog_apps.md b/hugo/content/en/actions/datadog_apps.md index 71d7ac0132f..5ddbab9670d 100644 --- a/hugo/content/en/actions/datadog_apps.md +++ b/hugo/content/en/actions/datadog_apps.md @@ -20,7 +20,7 @@ further_reading: --- {{< callout url="https://www.datadoghq.com/product-preview/apps/" btn_hidden="false" header="Join the Preview!">}} -Datadog Apps is in Preview. Use this form to request access. +{{< prodname >}}Datadog Apps{{< /prodname >}} is in Preview. Use this form to request access. {{< /callout >}} ## Overview @@ -43,7 +43,7 @@ Choose Apps when you need: ```shell node --version ``` -- Optional: A Datadog **API key** and an **application key** with [Actions API Access][5] enabled. Required for API-key-backed build telemetry (build metrics and Error Tracking sourcemap uploads) and for CI/CD uploads. For instructions, see [API and Application Keys][6]. +- Optional: A Datadog **API key** and an **application key** with [Actions API Access][5] enabled. Required for API-key-backed build telemetry (build metrics and {{< prodname >}}Error Tracking{{< /prodname >}} sourcemap uploads) and for CI/CD uploads. For instructions, see [API and Application Keys][6]. To enable Actions API Access on an application key: @@ -72,7 +72,7 @@ The scaffolded project includes: ## Use the `datadog-app` skill -The [`datadog-app` agent skill][20] gives AI coding agents guidance on Datadog Apps workflows, including scaffolding, local development, uploads, publishing, CI/CD, troubleshooting, DDSQL, and Action Catalog usage. The skill is available in the [agent-skills GitHub repository][21]. +The [`datadog-app` agent skill][20] gives AI coding agents guidance on {{< prodname >}}Datadog Apps{{< /prodname >}} workflows, including scaffolding, local development, uploads, publishing, CI/CD, troubleshooting, DDSQL, and Action Catalog usage. The skill is available in the [agent-skills GitHub repository][21]. ### Install @@ -188,7 +188,7 @@ import { Button } from '@datadog/druids'; Druids requires React 18 or 19 as a peer dependency. For the set of available components, see the [package on npm][23].
-Druids components are for use in Datadog Apps and App Builder only. See the package's license for details. +Druids components are for use in {{< prodname >}}Datadog Apps{{< /prodname >}} and App Builder only. See the package's license for details.
## Build and upload your app @@ -224,7 +224,7 @@ After you upload an app, it appears in your [App Builder][12] app list. From App - [Publish your app][13] - [Edit the app name and description][13] - Manage [permissions][14] -- [Embed the app][3] in dashboards, notebooks, and the Internal Developer Portal +- [Embed the app][3] in dashboards, notebooks, and the {{< prodname >}}Internal Developer Portal{{< /prodname >}}
The following App Builder features are not available for locally-built apps: diff --git a/hugo/content/en/actions/datastores/_index.md b/hugo/content/en/actions/datastores/_index.md index 3f142de9884..ed34c1c3545 100644 --- a/hugo/content/en/actions/datastores/_index.md +++ b/hugo/content/en/actions/datastores/_index.md @@ -18,7 +18,7 @@ further_reading: text: "How we created a single app to automate repetitive tasks with Datadog Workflow Automation, Datastore, and App Builder" --- -The Actions Datastore offers a scalable, structured data storage solution within Datadog's App Builder and Workflow Automation products. Datastores support CRUD (Create, Read, Update, and Delete) operations and integrate seamlessly with Datadog's ecosystem to optimize persistent data storage without the need for external databases. +The Actions Datastore offers a scalable, structured data storage solution within Datadog's App Builder and {{< prodname >}}Workflow Automation{{< /prodname >}} products. Datastores support CRUD (Create, Read, Update, and Delete) operations and integrate seamlessly with Datadog's ecosystem to optimize persistent data storage without the need for external databases. You can interact with a datastore using an app or a workflow, or you can use the UI in the Datadog App. diff --git a/hugo/content/en/actions/datastores/use.md b/hugo/content/en/actions/datastores/use.md index 40cc9f3b686..96b48e81ba8 100644 --- a/hugo/content/en/actions/datastores/use.md +++ b/hugo/content/en/actions/datastores/use.md @@ -30,7 +30,7 @@ To create a workflow from a datastore: 1. On the [Datastores page][1], locate your datastore in the list and click to open it. 1. Click {{< ui >}}Create{{< /ui >}} > {{< ui >}}Workflow from Datastore{{< /ui >}}. -Datadog creates a workflow with a {{< ui >}}List items{{< /ui >}} workflow step prepopulated with your datastore ID. From here, follow the [Workflow Automation][2] documentation to build your workflow. For a list of available datastore actions, see the [Action Catalog][4]. +Datadog creates a workflow with a {{< ui >}}List items{{< /ui >}} workflow step prepopulated with your datastore ID. From here, follow the [{{< prodname >}}Workflow Automation{{< /prodname >}}][2] documentation to build your workflow. For a list of available datastore actions, see the [Action Catalog][4]. ### App Builder diff --git a/hugo/content/en/actions/forms/_index.md b/hugo/content/en/actions/forms/_index.md index 5989c1ffe2f..fc50fb5b2ee 100644 --- a/hugo/content/en/actions/forms/_index.md +++ b/hugo/content/en/actions/forms/_index.md @@ -14,7 +14,7 @@ further_reading: ## Overview -Datadog Forms allow you to collect input, analyze responses, and trigger automations in Datadog. Forms and their responses can be shared across your organization, allowing you to collect and analyze data with your team. +{{< prodname >}}Datadog Forms{{< /prodname >}} allow you to collect input, analyze responses, and trigger automations in Datadog. Forms and their responses can be shared across your organization, allowing you to collect and analyze data with your team. Some ways you can use forms: - Scaffold services from predefined templates. @@ -27,11 +27,11 @@ On the [Forms][2] page, click {{< ui >}}New Form{{< /ui >}}, then select a creat {{< tabs >}} {{% tab "Create with AI" %}} -1. Select {{< ui >}}Create with AI{{< /ui >}} and click {{< ui >}}Continue{{< /ui >}}. The form editor opens with [Bits Chat][100]. -1. Describe the form you want to build in the Bits Chat panel. +1. Select {{< ui >}}Create with AI{{< /ui >}} and click {{< ui >}}Continue{{< /ui >}}. The form editor opens with [{{< prodname >}}Bits Chat{{< /prodname >}}][100]. +1. Describe the form you want to build in the {{< prodname >}}Bits Chat{{< /prodname >}} panel. 1. Click {{< ui >}}Publish{{< /ui >}} or {{< ui >}}Publish Changes{{< /ui >}} to make the form available to respondents. -You can also ask Bits Chat to create a form from anywhere in Datadog, not only from the Forms editor. See [Create and manage forms with MCP](#create-and-manage-forms-with-mcp). +You can also ask {{< prodname >}}Bits Chat{{< /prodname >}} to create a form from anywhere in Datadog, not only from the Forms editor. See [Create and manage forms with MCP](#create-and-manage-forms-with-mcp). [100]: /bits_ai/bits_chat/ @@ -146,11 +146,11 @@ After creating a form, you can add an [action][7] or [workflow blueprint][8] tha 1. The action or blueprint opens in a workflow canvas, where you can [edit it][9]. 1. Click {{< ui >}}Create{{< /ui >}}. -**Note**: Automations triggered by forms appear under [Workflow Automation][10]. +**Note**: Automations triggered by forms appear under [{{< prodname >}}Workflow Automation{{< /prodname >}}][10]. ## Create and manage forms with MCP -Connect an external AI agent to the [Datadog MCP Server][11] to create, update, publish, and read forms and their responses. Enable the `forms` toolset (or `all`) when you [connect to the MCP Server][12]. You can also ask [Bits Chat][13] to build a form from anywhere in Datadog. See [Forms][14] in the Datadog MCP Server tools reference for the full list of available tools. +Connect an external AI agent to the [{{< prodname >}}Datadog MCP Server{{< /prodname >}}][11] to create, update, publish, and read forms and their responses. Enable the `forms` toolset (or `all`) when you [connect to the MCP Server][12]. You can also ask [{{< prodname >}}Bits Chat{{< /prodname >}}][13] to build a form from anywhere in Datadog. See [Forms][14] in the {{< prodname >}}Datadog MCP Server{{< /prodname >}} tools reference for the full list of available tools. ## Manage access diff --git a/hugo/content/en/actions/private_actions/use_private_actions.md b/hugo/content/en/actions/private_actions/use_private_actions.md index c05d740da80..c70ef937642 100644 --- a/hugo/content/en/actions/private_actions/use_private_actions.md +++ b/hugo/content/en/actions/private_actions/use_private_actions.md @@ -861,17 +861,17 @@ By default, only the runner's creator has {{< ui >}}Editor{{< /ui >}} access. Th Before you can use an action runner, you must pair it with one or more connections. To pair a runner to a connection: -1. From the [Workflow Automation][7] or [App Builder][8] Connections page, click {{< ui >}}New Connection{{< /ui >}}. +1. From the [{{< prodname >}}Workflow Automation{{< /prodname >}}][7] or [App Builder][8] Connections page, click {{< ui >}}New Connection{{< /ui >}}. 1. Select the integration you want to connect with your private action runner. For a list of integrations that support private actions, see [Supported private actions](#supported-private-actions). 1. Add a {{< ui >}}Connection Name{{< /ui >}} and select your runner from the {{< ui >}}Private Action Runner{{< /ui >}} dropdown. 1. Add the paths to any required credential files. For more information on credentials, see [Handling Private Action Credentials][9]. ## Use a private action -To use a private action in your [Workflow Automation][10] workflow or [App Builder][11] app: +To use a private action in your [{{< prodname >}}Workflow Automation{{< /prodname >}}][10] workflow or [App Builder][11] app: -{{% collapse-content title="Workflow Automation" level="p" %}} -1. From the [Workflow Automation][10] page, create a workflow, or open an existing workflow. For information on creating or editing a workflow, see [Build Workflows][12]. +{{% collapse-content title="{{< prodname >}}Workflow Automation{{< /prodname >}}" level="p" %}} +1. From the [{{< prodname >}}Workflow Automation{{< /prodname >}}][10] page, create a workflow, or open an existing workflow. For information on creating or editing a workflow, see [Build Workflows][12]. 1. Click {{< ui >}}Add Step{{< /ui >}} and search for the private action you want to add to your workflow. For a list of integrations that support private actions, see [Supported private actions](#supported-private-actions). 1. Enter a name for the step. 1. Select a {{< ui >}}Connection{{< /ui >}} from the dropdown or click the plus ({{< ui >}}+{{< /ui >}}) icon to add a new connection. Using a private action requires a private action runner that is paired with a connection. See [Connect a runner](#connect-a-runner) for more information. diff --git a/hugo/content/en/actions/workflows/build.md b/hugo/content/en/actions/workflows/build.md index 8ffdaf94925..9d19c0d4e27 100644 --- a/hugo/content/en/actions/workflows/build.md +++ b/hugo/content/en/actions/workflows/build.md @@ -22,7 +22,7 @@ further_reading: text: "Variables and Parameters" --- -You can create workflows or edit existing workflows from the [Workflow Automation][1] page. The page lists information about existing workflows, such as the workflow's owner, the trigger type, the dates that each workflow was last modified and executed, and whether the workflow is published or not. +You can create workflows or edit existing workflows from the [{{< prodname >}}Workflow Automation{{< /prodname >}}][1] page. The page lists information about existing workflows, such as the workflow's owner, the trigger type, the dates that each workflow was last modified and executed, and whether the workflow is published or not. - Hover over a workflow for the options to delete, clone, or edit the permissions for the workflow. - Toggle {{< ui >}}My workflows{{< /ui >}} if you want to see only workflows that you created. @@ -46,7 +46,7 @@ You can create workflows or edit existing workflows from the [Workflow Automatio If you're not sure where to start, you can automatically generate a workflow, or iterate on an existing workflow with AI. To generate a workflow: -1. From the [Workflow Automation][1] page, click {{< ui >}}New Workflow{{< /ui >}}. +1. From the [{{< prodname >}}Workflow Automation{{< /prodname >}}][1] page, click {{< ui >}}New Workflow{{< /ui >}}. 1. Click {{< ui >}}Create a workflow with AI{{< /ui >}}. 1. Enter a detailed prompt for your workflow. Specify the integrations and actions you'd like to use. 1. Click the up arrow ({{< ui >}}↑{{< /ui >}}) to create your workflow. @@ -60,7 +60,7 @@ To iterate on an existing workflow: ## Create a custom workflow -To create a workflow, click {{< ui >}}New workflow{{< /ui >}} on the [Workflow Automation][1] page. +To create a workflow, click {{< ui >}}New workflow{{< /ui >}} on the [{{< prodname >}}Workflow Automation{{< /prodname >}}][1] page. To configure your workflow: 1. In the workflow configuration panel, enter a {{< ui >}}Name{{< /ui >}} for your workflow. diff --git a/hugo/content/en/actions/workflows/limits.md b/hugo/content/en/actions/workflows/limits.md index 5a29aaa3bf9..8d0bf04b8cd 100644 --- a/hugo/content/en/actions/workflows/limits.md +++ b/hugo/content/en/actions/workflows/limits.md @@ -12,7 +12,7 @@ further_reading: text: "Build Workflows" --- -This page describes rate limits and throttles that apply to Workflow Automation. +This page describes rate limits and throttles that apply to {{< prodname >}}Workflow Automation{{< /prodname >}}. ## Account-level limits diff --git a/hugo/content/en/actions/workflows/saved_actions.md b/hugo/content/en/actions/workflows/saved_actions.md index 58e3de3e5ac..b2a1bb55e6d 100644 --- a/hugo/content/en/actions/workflows/saved_actions.md +++ b/hugo/content/en/actions/workflows/saved_actions.md @@ -50,7 +50,7 @@ To configure an existing step using a saved action: You can preview, edit, or delete your Saved Actions from the [Action Catalog][1] tab. To find a saved action: -1. From the [Workflow Automation][2] page, click [**Action Catalog**][1]. +1. From the [{{< prodname >}}Workflow Automation{{< /prodname >}}][2] page, click [**Action Catalog**][1]. 1. Click {{< ui >}}Saved Actions{{< /ui >}} and browse through the list for the Saved Action you'd like to preview, edit, or delete. 1. Hover over the action and click {{< ui >}}Preview/Edit saved configurations{{< /ui >}} to be presented with a preview of the action. 1. From the preview screen, select the action to edit or delete it. diff --git a/hugo/content/en/actions/workflows/trigger.md b/hugo/content/en/actions/workflows/trigger.md index 22a2dd59553..54f319cdc7d 100644 --- a/hugo/content/en/actions/workflows/trigger.md +++ b/hugo/content/en/actions/workflows/trigger.md @@ -96,7 +96,7 @@ See the test and debug page for information on [how to test a monitor trigger][1 Incident triggers can run a workflow automatically based on incident events, or manually from within an incident. -
To set up incident automations within Incident Management, with incident context built in and no additional billing, see Incident Automations. Use a workflow with an incident trigger when incident events are one trigger among others, or when the workflow is managed outside of Incident Management.
+
To set up incident automations within {{< prodname >}}Incident Management{{< /prodname >}}, with incident context built in and no additional billing, see Incident Automations. Use a workflow with an incident trigger when incident events are one trigger among others, or when the workflow is managed outside of {{< prodname >}}Incident Management{{< /prodname >}}.
To add an incident trigger to your workflow: 1. From the [Workflow creation page][6], scroll down to the Trigger options and click {{< ui >}}Incident{{< /ui >}}. diff --git a/hugo/content/en/administrators_guide/plan.md b/hugo/content/en/administrators_guide/plan.md index d38f93391a9..a7715cc50ca 100644 --- a/hugo/content/en/administrators_guide/plan.md +++ b/hugo/content/en/administrators_guide/plan.md @@ -107,7 +107,7 @@ Usually, the default APM setup is sufficient for most use cases, but if, for exa ### Log Management -Log Management capabilities allow you and your teams to diagnose and fix your infrastructure issues. [Logging without Limits™][14] enables you to create tunable log collection patterns and extract information from your log data into custom metrics. You can also receive alerts about critical errors in your logs, without needing to index your logs. +{{< prodname >}}Log Management{{< /prodname >}} capabilities allow you and your teams to diagnose and fix your infrastructure issues. [Logging without Limits™][14] enables you to create tunable log collection patterns and extract information from your log data into custom metrics. You can also receive alerts about critical errors in your logs, without needing to index your logs. {{< img src="/administrators_guide/logging_without_limits.png" alt="Logging without Limits diagram" style="width:90%;">}} @@ -199,7 +199,7 @@ There are different types of integrations in Datadog, and the order in which the ## Additional resources -You've achieved some important wins and adopted best practices with APM, RUM, Synthetic Monitoring and Log Management. Some additional resources that are important when planning your installation phase are outlined below. +You've achieved some important wins and adopted best practices with APM, RUM, Synthetic Monitoring and {{< prodname >}}Log Management{{< /prodname >}}. Some additional resources that are important when planning your installation phase are outlined below. ### Live processes @@ -231,9 +231,9 @@ Refer to the [Endpoints list][33] to categorize, monitor performance and reliabi ### Resource Catalog -Use [Resource Catalog][46] to view key resource information such as metadata, ownership, configurations, relationships between assets, and active security risks. It is the central hub of all of your infrastructure resources. Resource Catalog offers visibility into infrastructure compliance, promotes good tagging practices, reduces application risks by identifying security vulnerabilities, provides engineering leadership with a high-level view of security practices, and allows resource export for record-keeping or auditing. +Use [{{< prodname >}}Resource Catalog{{< /prodname >}}][46] to view key resource information such as metadata, ownership, configurations, relationships between assets, and active security risks. It is the central hub of all of your infrastructure resources. {{< prodname >}}Resource Catalog{{< /prodname >}} offers visibility into infrastructure compliance, promotes good tagging practices, reduces application risks by identifying security vulnerabilities, provides engineering leadership with a high-level view of security practices, and allows resource export for record-keeping or auditing. -You can use Resource Catalog in a variety of contexts, including: +You can use {{< prodname >}}Resource Catalog{{< /prodname >}} in a variety of contexts, including: - Understanding the team ownership of resources and finding orphaned ones to clean up. - Planning upgrades of resources that are running deprecated versions. @@ -242,11 +242,11 @@ You can use Resource Catalog in a variety of contexts, including: ### Event Management -Without any additional setup, [Event management][31] can show third-party event statuses, events generated from the Agent and installed integrations. Datadog Event Management centralizes third-party events, such as alerts and change events. Datadog also automatically creates events from various products including monitors and Error Tracking. You can also use Event Management to send monitor alerts and notifications based on event queries. +Without any additional setup, [Event management][31] can show third-party event statuses, events generated from the Agent and installed integrations. Datadog Event Management centralizes third-party events, such as alerts and change events. Datadog also automatically creates events from various products including monitors and {{< prodname >}}Error Tracking{{< /prodname >}}. You can also use {{< prodname >}}Event Management{{< /prodname >}} to send monitor alerts and notifications based on event queries. ### Error Tracking -See errors where they happen with Datadog's [Error Tracking][32]. Error Tracking can ingest errors from APM, Log Management, and Real User Monitoring to debug issues faster. +See errors where they happen with Datadog's [{{< prodname >}}Error Tracking{{< /prodname >}}][32]. {{< prodname >}}Error Tracking{{< /prodname >}} can ingest errors from APM, {{< prodname >}}Log Management{{< /prodname >}}, and Real User Monitoring to debug issues faster. ### Fleet Automation diff --git a/hugo/content/en/agent/configuration/dual-shipping.md b/hugo/content/en/agent/configuration/dual-shipping.md index 5ecbe08148a..158f993c4bf 100644 --- a/hugo/content/en/agent/configuration/dual-shipping.md +++ b/hugo/content/en/agent/configuration/dual-shipping.md @@ -23,7 +23,7 @@ Dual shipping can impact billing if you are sending data to multiple Datadog org This guide provides examples of Agent configurations for dual shipping different types of data (for example, APM, logs, Cluster Agent metrics) to multiple Datadog organizations and sites. For more information about Datadog sites, see [Getting Started with Datadog sites][3]. -**Note**: Use [Observability Pipelines][1] if you want to dual ship logs or split log traffic across different logging vendors, cloud storages, or SIEM providers. +**Note**: Use [{{< prodname >}}Observability Pipelines{{< /prodname >}}][1] if you want to dual ship logs or split log traffic across different logging vendors, cloud storages, or SIEM providers. For a full list of network traffic destinations, see [Network Traffic][2]. @@ -221,7 +221,7 @@ DD_EVP_PROXY_CONFIG_ADDITIONAL_ENDPOINTS='{\"https://-app.agent.{{< reg ## Logs -Use the Agent if you want to dual ship logs to multiple Datadog organizations. Use [Observability Pipelines][2] if you want to send logs to Datadog and external destinations. +Use the Agent if you want to dual ship logs to multiple Datadog organizations. Use [{{< prodname >}}Observability Pipelines{{< /prodname >}}][2] if you want to send logs to Datadog and external destinations. TCP requires Agent version >= 6.6.
HTTPS requires Agent version >= 6.13. diff --git a/hugo/content/en/agent/configuration/infrastructure-modes.md b/hugo/content/en/agent/configuration/infrastructure-modes.md index cc6141a8845..37db0850e35 100644 --- a/hugo/content/en/agent/configuration/infrastructure-modes.md +++ b/hugo/content/en/agent/configuration/infrastructure-modes.md @@ -82,7 +82,7 @@ The Agent supports four infrastructure modes. A checkmark ({{< X >}}) indicates `none` : **Minimum Agent version**: 7.77.0
-**Recommended for**: Hosts configured only for [Log Management][19], [APM][20], or [Error Tracking][21]
+**Recommended for**: Hosts configured only for [{{< prodname >}}Log Management{{< /prodname >}}][19], [APM][20], or [{{< prodname >}}Error Tracking{{< /prodname >}}][21]
: The Agent does not collect any infrastructure metrics or run infrastructure integrations. You can still use custom metrics, [custom checks][15] prefixed with `custom_`, and logs-only integrations such as [journald][16] or [Windows Event Log][17]. : Hosts in `none` mode appear in [Fleet Automation][22] under the {{< ui >}}View Agents{{< /ui >}} tab because the Agent continues to send metadata to Datadog. However, these hosts do not appear in infrastructure dashboards or queries that rely on infrastructure metrics. diff --git a/hugo/content/en/agent/configuration/network.md b/hugo/content/en/agent/configuration/network.md index 209d7352152..d94501b1028 100644 --- a/hugo/content/en/agent/configuration/network.md +++ b/hugo/content/en/agent/configuration/network.md @@ -61,7 +61,7 @@ This behavior can be disabled in version 7.72.0 and later by setting conve [Live Containers][3], [Live Process][4], [Cloud Network Monitoring][24], [Universal Service Monitoring][25] : `process.`{{< region-param key="dd_site" code="true" >}} -[Network Device Monitoring][10] +[{{< prodname >}}Network Device Monitoring{{< /prodname >}}][10] : `ndm-intake.`{{< region-param key="dd_site" code="true" >}}
`snmp-traps-intake.`{{< region-param key="dd_site" code="true" >}}
`ndmflow-intake.`{{< region-param key="dd_site" code="true" >}} @@ -94,7 +94,7 @@ API test results for the Synthetics Worker < v0.1.5: `api.`{{< region-param key= [Remote Configuration][101] : `config.`{{< region-param key="dd_site" code="true" >}} -[Database Monitoring][102] +[{{< prodname >}}Database Monitoring{{< /prodname >}}][102] : `dbm-metrics-intake.`{{< region-param key="dd_site" code="true" >}}
`dbquery-intake.`{{< region-param key="dd_site" code="true" >}} diff --git a/hugo/content/en/agent/faq/fips_proxy.md b/hugo/content/en/agent/faq/fips_proxy.md index 1d8b90abeed..89f86affc19 100644 --- a/hugo/content/en/agent/faq/fips_proxy.md +++ b/hugo/content/en/agent/faq/fips_proxy.md @@ -144,7 +144,7 @@ sudo journalctl -u datadog-fips-proxy #### journald logs configuration -If you use [Log Management][3] and want to send the Datadog Agent FIPS Proxy logs to Datadog, set up the Datadog Agent to read logs from journald. +If you use [{{< prodname >}}Log Management{{< /prodname >}}][3] and want to send the Datadog Agent FIPS Proxy logs to Datadog, set up the Datadog Agent to read logs from journald. 1. In the Agent's [configuration file][2], set `logs_enabled` to `true` to activate the Logs Agent. In the [configuration directory][4], create a file at `fips_proxy.d/conf.yaml` with the following content: diff --git a/hugo/content/en/agent/fleet_automation/upgrade_sdks.md b/hugo/content/en/agent/fleet_automation/upgrade_sdks.md index e2cdf47cffb..950a3f6236a 100644 --- a/hugo/content/en/agent/fleet_automation/upgrade_sdks.md +++ b/hugo/content/en/agent/fleet_automation/upgrade_sdks.md @@ -9,10 +9,10 @@ site_support_id: fleet-automation-standard-features --- {{< callout url="https://www.datadoghq.com/product-preview/remote-upgrade-of-sdk-versions/" btn_hidden="false" header="Join the Preview!" >}} -Remotely upgrade the SDKs that power APM, Profiler, Dynamic Instrumentation, and more. Request access to join the preview. +Remotely upgrade the SDKs that power APM, Profiler, {{< prodname >}}Dynamic Instrumentation{{< /prodname >}}, and more. Request access to join the preview. {{< /callout >}} -Fleet Automation can centrally manage remote upgrades to the SDKs that power APM, Continuous Profiler, Dynamic Instrumentation, and more. Keeping your services' SDK versions up to date lets you benefit from the latest features, performance improvements, bug fixes, and security updates. +Fleet Automation can centrally manage remote upgrades to the SDKs that power APM, Continuous Profiler, {{< prodname >}}Dynamic Instrumentation{{< /prodname >}}, and more. Keeping your services' SDK versions up to date lets you benefit from the latest features, performance improvements, bug fixes, and security updates.
Scheduling SDK upgrades is not supported. diff --git a/hugo/content/en/agent/logs/_index.md b/hugo/content/en/agent/logs/_index.md index 2c1a373bef6..83dd4cbe132 100644 --- a/hugo/content/en/agent/logs/_index.md +++ b/hugo/content/en/agent/logs/_index.md @@ -24,7 +24,7 @@ further_reading: Log collection requires the Datadog Agent v6.0+. Older versions of the Agent do not include the `log collection` interface. If you are not using the Agent already, follow the [Agent installation instructions][1]. -See [Observability Pipelines][2] if you want to send logs using another vendor's collector or forwarder, or you want to preprocess your log data within your environment before shipping. +See [{{< prodname >}}Observability Pipelines{{< /prodname >}}][2] if you want to send logs using another vendor's collector or forwarder, or you want to preprocess your log data within your environment before shipping. ## Activate log collection diff --git a/hugo/content/en/agent/supported_platforms/aix.md b/hugo/content/en/agent/supported_platforms/aix.md index fb421f17656..3378ba327c9 100644 --- a/hugo/content/en/agent/supported_platforms/aix.md +++ b/hugo/content/en/agent/supported_platforms/aix.md @@ -20,7 +20,7 @@ algolia: ## Overview The [Datadog UNIX Agent][4] brings host-level monitoring to IBM AIX (PowerPC 8+) so you can visualize system metrics, enable additional Datadog products, and troubleshoot services that still run on-prem. -The UNIX Agent supports Infrastructure Monitoring and Custom Metrics using [DogStatsD][11]. Other products like APM, Live Process Monitoring, Cloud Network Monitoring, and Log Management are not supported on the UNIX Agent. See [Supported Platforms][5] for the complete list of supported AIX versions. +The UNIX Agent supports {{< prodname >}}Infrastructure Monitoring{{< /prodname >}} and Custom Metrics using [DogStatsD][11]. Other products like APM, Live Process Monitoring, Cloud Network Monitoring, and {{< prodname >}}Log Management{{< /prodname >}} are not supported on the UNIX Agent. See [Supported Platforms][5] for the complete list of supported AIX versions. This page walks you through installing, operating, and removing the Datadog UNIX Agent on AIX. diff --git a/hugo/content/en/agentic_onboarding/_index.md b/hugo/content/en/agentic_onboarding/_index.md index aa4cfe49fc0..43e7391d14f 100644 --- a/hugo/content/en/agentic_onboarding/_index.md +++ b/hugo/content/en/agentic_onboarding/_index.md @@ -4,5 +4,5 @@ private: true --- {{< whatsnext desc="Explore Agentic Onboarding" >}} - {{< nextlink href="/agentic_onboarding/setup/" >}}Setup - Use the Datadog AI Setup CLI or the Datadog MCP Server to instrument your applications with Datadog.{{< /nextlink >}} + {{< nextlink href="/agentic_onboarding/setup/" >}}Setup - Use the Datadog AI Setup CLI or the {{< prodname >}}Datadog MCP Server{{< /prodname >}} to instrument your applications with Datadog.{{< /nextlink >}} {{< /whatsnext >}} diff --git a/hugo/content/en/agentic_onboarding/setup.md b/hugo/content/en/agentic_onboarding/setup.md index 900b8aab6bd..5b15900f60f 100644 --- a/hugo/content/en/agentic_onboarding/setup.md +++ b/hugo/content/en/agentic_onboarding/setup.md @@ -11,7 +11,7 @@ Agentic Onboarding is a set of AI-driven tools that automate Datadog instrumenta - [AI Setup CLI](#ai-setup-cli): Set up Datadog from a terminal, without a coding assistant. - [MCP server](#mcp-server): Set up Datadog through a coding assistant (such as Claude Code or Cursor), which handles framework detection and configuration from your IDE. -The two paths are complementary and use the same Datadog account. You can install the Datadog MCP Server in your IDE and run the CLI in a terminal. +The two paths are complementary and use the same Datadog account. You can install the {{< prodname >}}Datadog MCP Server{{< /prodname >}} in your IDE and run the CLI in a terminal. ## AI Setup CLI @@ -146,7 +146,7 @@ Add the server to `~/.cursor/mcp.json`: {{% tab "Other MCP clients" %}} -Any MCP client that supports HTTP transport can connect to the Datadog MCP Server. Point it at the endpoint for your [Datadog site][1]: +Any MCP client that supports HTTP transport can connect to the {{< prodname >}}Datadog MCP Server{{< /prodname >}}. Point it at the endpoint for your [Datadog site][1]: 
{{< region-param key="mcp_server_endpoint" >}}?toolsets=onboarding
@@ -189,7 +189,7 @@ Send the prompt that matches the product you want to set up: {{% /tab %}} {{% tab "App and API Protection (Preview)" %}} -
Agentic onboarding for App and API Protection is in Public Preview.
+
Agentic onboarding for {{< prodname >}}App and API Protection{{< /prodname >}} is in Public Preview.
{{< code-block lang="text" >}}Add Datadog App and API Protection to my project{{< /code-block >}} {{% /tab %}} @@ -228,8 +228,8 @@ After the agent completes, commit the changes to your repository and set any new Confirm data is flowing in the Datadog UI for the product you set up: -- [Error Tracking][6] -- [App and API Protection][11] +- [{{< prodname >}}Error Tracking{{< /prodname >}}][6] +- [{{< prodname >}}App and API Protection{{< /prodname >}}][11] - [RUM > Applications][7] - [Infrastructure > Hosts][8] - [Serverless > Functions][9] diff --git a/hugo/content/en/ai_agents_console/_index.md b/hugo/content/en/ai_agents_console/_index.md index ab439243f28..29281a74928 100644 --- a/hugo/content/en/ai_agents_console/_index.md +++ b/hugo/content/en/ai_agents_console/_index.md @@ -17,12 +17,12 @@ further_reading: --- {{< callout url="#" btn_hidden="true" header="Preview">}} -Agent Console is in Preview and available to all Datadog customers. +{{< prodname >}}Agent Console{{< /prodname >}} is in Preview and available to all Datadog customers. {{< /callout >}} -The [Agent Console][1] provides centralized monitoring for AI agents across your organization. It collects logs and metrics from coding agents and Datadog's own [Bits AI agents](#bits-ai-agents), surfacing them in real time to give you visibility into usage, cost, latency, productivity impact, and emerging problem patterns. +The [{{< prodname >}}Agent Console{{< /prodname >}}][1] provides centralized monitoring for AI agents across your organization. It collects logs and metrics from coding agents and Datadog's own [Bits AI agents](#bits-ai-agents), surfacing them in real time to give you visibility into usage, cost, latency, productivity impact, and emerging problem patterns. -Agent Console supports the following coding agents: +{{< prodname >}}Agent Console{{< /prodname >}} supports the following coding agents: | Tool | Description | |------|-------------| @@ -91,11 +91,11 @@ The {{< ui >}}User Analytics{{< /ui >}} panel gives you visibility into how indi The {{< ui >}}Bits AI Agents{{< /ui >}} tab shows usage of Datadog's built-in AI agents alongside your coding agents. The combined view of investigations, sessions, and executions across all Datadog agents lets you correlate Bits AI activity with the rest of your organization. -Individual cards summarize activity for each Bits AI agent, including [Bits Investigation][5], [Bits Code][6], and [Bits Agent Builder][7]. Click {{< ui >}}View Details{{< /ui >}} on a card to examine that agent. +Individual cards summarize activity for each Bits AI agent, including [Bits Investigation][5], [{{< prodname >}}Bits Code{{< /prodname >}}][6], and [Bits Agent Builder][7]. Click {{< ui >}}View Details{{< /ui >}} on a card to examine that agent. ## Set up -To start sending data to Agent Console, see [Set Up Agent Console][8]. +To start sending data to {{< prodname >}}Agent Console{{< /prodname >}}, see [Set Up Agent Console][8]. ## Further reading diff --git a/hugo/content/en/ai_agents_console/setup.md b/hugo/content/en/ai_agents_console/setup.md index a6da94a1e30..27da6f7ace7 100644 --- a/hugo/content/en/ai_agents_console/setup.md +++ b/hugo/content/en/ai_agents_console/setup.md @@ -14,18 +14,18 @@ further_reading: --- {{< callout url="#" btn_hidden="true" header="Preview">}} -Agent Console is available to all Datadog customers in Preview. +{{< prodname >}}Agent Console{{< /prodname >}} is available to all Datadog customers in Preview. {{< /callout >}} -Set up an integration for each coding agent you want to monitor in [Agent Console][1]. +Set up an integration for each coding agent you want to monitor in [{{< prodname >}}Agent Console{{< /prodname >}}][1]. ## Claude Code ### Option 1: Anthropic Usage and Costs integration (recommended) -To monitor Claude Code with Agent Console, set up the [Anthropic Usage and Costs][4] integration. +To monitor Claude Code with {{< prodname >}}Agent Console{{< /prodname >}}, set up the [Anthropic Usage and Costs][4] integration. -After setup, navigate to the [Agent Console][1] and click the {{< ui >}}Claude Code{{< /ui >}} tile to view metrics. +After setup, navigate to the [{{< prodname >}}Agent Console{{< /prodname >}}][1] and click the {{< ui >}}Claude Code{{< /ui >}} tile to view metrics. ### Option 2: OpenTelemetry (OTLP) @@ -52,10 +52,10 @@ The following procedure configures Claude Code to send telemetry directly to Dat Replace `` with your Datadog API key. -
To set up Agent Console for Claude Code across your organization, your IT team can use a Mobile Device Management (MDM) system or server-managed settings to distribute the Claude Code settings file across all managed devices.
+
To set up {{< prodname >}}Agent Console{{< /prodname >}} for Claude Code across your organization, your IT team can use a Mobile Device Management (MDM) system or server-managed settings to distribute the Claude Code settings file across all managed devices.
4. Restart Claude Code. -After you restart Claude Code, navigate to the [Agent Console][1] and click the {{< ui >}}Claude Code{{< /ui >}} tile. Metrics (usage, cost, latency, errors) should appear within a few minutes. +After you restart Claude Code, navigate to the [{{< prodname >}}Agent Console{{< /prodname >}}][1] and click the {{< ui >}}Claude Code{{< /ui >}} tile. Metrics (usage, cost, latency, errors) should appear within a few minutes. ### Option 3: Forward data through the Datadog Agent @@ -87,22 +87,22 @@ After you restart Claude Code, navigate to the [Agent Console][1] and click the } ``` -
To set up Agent Console for Claude Code across your organization, your IT team can use a Mobile Device Management (MDM) system or server-managed settings to distribute the Claude Code settings file across all managed devices.
+
To set up {{< prodname >}}Agent Console{{< /prodname >}} for Claude Code across your organization, your IT team can use a Mobile Device Management (MDM) system or server-managed settings to distribute the Claude Code settings file across all managed devices.
5. Restart Claude Code. -After you restart Claude Code, navigate to the [Agent Console][1] and click the {{< ui >}}Claude Code{{< /ui >}} tile. Metrics (usage, cost, latency, errors) should appear within a few minutes. +After you restart Claude Code, navigate to the [{{< prodname >}}Agent Console{{< /prodname >}}][1] and click the {{< ui >}}Claude Code{{< /ui >}} tile. Metrics (usage, cost, latency, errors) should appear within a few minutes. ## Cursor -To monitor Cursor with Agent Console, set up the [Cursor][5] integration using the Datadog Extension for Cursor. +To monitor Cursor with {{< prodname >}}Agent Console{{< /prodname >}}, set up the [Cursor][5] integration using the Datadog Extension for Cursor. -After setup, navigate to the [Agent Console][1] and click the {{< ui >}}Cursor{{< /ui >}} tile to view metrics. +After setup, navigate to the [{{< prodname >}}Agent Console{{< /prodname >}}][1] and click the {{< ui >}}Cursor{{< /ui >}} tile to view metrics. ## GitHub Copilot -To monitor GitHub Copilot with Agent Console, set up the [GitHub Copilot][10] integration. +To monitor GitHub Copilot with {{< prodname >}}Agent Console{{< /prodname >}}, set up the [GitHub Copilot][10] integration. -After setup, navigate to the [Agent Console][1] and click the {{< ui >}}GitHub Copilot{{< /ui >}} tile to view metrics. +After setup, navigate to the [{{< prodname >}}Agent Console{{< /prodname >}}][1] and click the {{< ui >}}GitHub Copilot{{< /ui >}} tile to view metrics. ## Further reading diff --git a/hugo/content/en/all_guides.md b/hugo/content/en/all_guides.md index fdfb08ead0b..78ff0264c8d 100644 --- a/hugo/content/en/all_guides.md +++ b/hugo/content/en/all_guides.md @@ -23,33 +23,33 @@ Guides in the Datadog documentation are pages that provide background knowledge, {{< /whatsnext >}} {{< whatsnext desc="Incident Response:">}} -{{< nextlink href="/incident_response/incident_management/guides/" >}}    Incident Management{{< /nextlink >}} -{{< nextlink href="/incident_response/on-call/guides/" >}}    On-Call{{< /nextlink >}} +{{< nextlink href="/incident_response/incident_management/guides/" >}}    {{< prodname >}}Incident Management{{< /prodname >}}{{< /nextlink >}} +{{< nextlink href="/incident_response/on-call/guides/" >}}    {{< prodname >}}On-Call{{< /prodname >}}{{< /nextlink >}} {{< /whatsnext >}} {{< whatsnext desc="Infrastructure:">}} {{< nextlink href="/containers/guide" >}}    Containers{{< /nextlink >}} {{< nextlink href="/serverless/guide" >}}    Serverless{{< /nextlink >}} {{< nextlink href="/network_monitoring/cloud_network_monitoring/guide" >}}    Cloud Network Monitoring{{< /nextlink >}} -{{< nextlink href="/network_monitoring/devices/guide" >}}    Network Device Monitoring{{< /nextlink >}} +{{< nextlink href="/network_monitoring/devices/guide" >}}    {{< prodname >}}Network Device Monitoring{{< /prodname >}}{{< /nextlink >}} {{< /whatsnext >}} {{< whatsnext desc="Application Performance:">}} {{< nextlink href="/tracing/guide" >}}    APM{{< /nextlink >}} -{{< nextlink href="/database_monitoring/guide" >}}    Database Monitoring{{< /nextlink >}} +{{< nextlink href="/database_monitoring/guide" >}}    {{< prodname >}}Database Monitoring{{< /prodname >}}{{< /nextlink >}} {{< nextlink href="/universal_service_monitoring/guide" >}}    Universal Service Monitoring{{< /nextlink >}} {{< /whatsnext >}} {{< whatsnext desc="Software Delivery:">}} {{< nextlink href="/continuous_integration/guides/" >}}    CI Visibility{{< /nextlink >}} -{{< nextlink href="/tests/guides/" >}}    Test Optimization{{< /nextlink >}} -{{< nextlink href="/feature_flags/guide" >}}    Feature Flags{{< /nextlink >}} +{{< nextlink href="/tests/guides/" >}}    {{< prodname >}}Test Optimization{{< /prodname >}}{{< /nextlink >}} +{{< nextlink href="/feature_flags/guide" >}}    {{< prodname >}}Feature Flags{{< /prodname >}}{{< /nextlink >}} {{< /whatsnext >}} {{< whatsnext desc="Security:">}} -{{< nextlink href="/security/cloud_siem/guide" >}}    Cloud SIEM{{< /nextlink >}} -{{< nextlink href="/security/cloud_security_management/guide" >}}    Cloud Security{{< /nextlink >}} -{{< nextlink href="/security/application_security/guide" >}}    App and API Protection{{< /nextlink >}} +{{< nextlink href="/security/cloud_siem/guide" >}}    {{< prodname >}}Cloud SIEM{{< /prodname >}}{{< /nextlink >}} +{{< nextlink href="/security/cloud_security_management/guide" >}}    {{< prodname >}}Cloud Security{{< /prodname >}}{{< /nextlink >}} +{{< nextlink href="/security/application_security/guide" >}}    {{< prodname >}}App and API Protection{{< /prodname >}}{{< /nextlink >}} {{< /whatsnext >}} {{< whatsnext desc="Digital Experience:">}} @@ -59,9 +59,9 @@ Guides in the Datadog documentation are pages that provide background knowledge, {{< /whatsnext >}} {{< whatsnext desc="Log Management:">}} -{{< nextlink href="/logs/guide" >}}    Log Management{{< /nextlink >}} -{{< nextlink href="/observability_pipelines/guide" >}}    Observability Pipelines{{< /nextlink >}} -{{< nextlink href="/byoc-logs/guides/" >}}    BYOC Logs{{< /nextlink >}} +{{< nextlink href="/logs/guide" >}}    {{< prodname >}}Log Management{{< /prodname >}}{{< /nextlink >}} +{{< nextlink href="/observability_pipelines/guide" >}}    {{< prodname >}}Observability Pipelines{{< /prodname >}}{{< /nextlink >}} +{{< nextlink href="/byoc-logs/guides/" >}}    {{< prodname >}}BYOC Logs{{< /prodname >}}{{< /nextlink >}} {{< /whatsnext >}} {{< whatsnext desc="Administration:">}} diff --git a/hugo/content/en/api/latest/scopes/_index.md b/hugo/content/en/api/latest/scopes/_index.md index c3448390de5..69c05b7c9ac 100644 --- a/hugo/content/en/api/latest/scopes/_index.md +++ b/hugo/content/en/api/latest/scopes/_index.md @@ -17,7 +17,7 @@ Scopes are an authorization mechanism that allow you to limit and define the spe The best practice for scoping applications is to follow the principle of least privilege. Assign only the minimum scopes necessary for an application to function as intended. This enhances security and provides visibility into how applications interact with your organization's data. For example, a third-party application that only reads dashboards does not need permissions to delete or manage users. -You can use authorization scopes with OAuth2 clients for your [Datadog Apps][1]. +You can use authorization scopes with OAuth2 clients for your [{{< prodname >}}Datadog Apps{{< /prodname >}}][1]. {{< api-scopes >}} diff --git a/hugo/content/en/bits_ai/_index.md b/hugo/content/en/bits_ai/_index.md index e3eff509005..bb9dc5ffb3c 100644 --- a/hugo/content/en/bits_ai/_index.md +++ b/hugo/content/en/bits_ai/_index.md @@ -40,9 +40,9 @@ Learn about Bits AI pricing on [AI Credits][1]. {{< whatsnext desc="Learn about how you can use Bits AI:" >}} {{< nextlink href="bits_ai/bits_investigation" >}}Investigate alerts with Bits Investigation{{< /nextlink >}} - {{< nextlink href="bits_ai/bits_code" >}}Automate code fixes with Bits Code{{< /nextlink >}} - {{< nextlink href="bits_ai/bits_security_analyst" >}}Triage security threat signals with Bits Security Analyst{{< /nextlink >}} - {{< nextlink href="bits_ai/bits_chat" >}}Explore your observability data with Bits Chat{{< /nextlink >}} + {{< nextlink href="bits_ai/bits_code" >}}Automate code fixes with {{< prodname >}}Bits Code{{< /prodname >}}{{< /nextlink >}} + {{< nextlink href="bits_ai/bits_security_analyst" >}}Triage security threat signals with {{< prodname >}}Bits Security Analyst{{< /prodname >}}{{< /nextlink >}} + {{< nextlink href="bits_ai/bits_chat" >}}Explore your observability data with {{< prodname >}}Bits Chat{{< /prodname >}}{{< /nextlink >}} {{< nextlink href="bits_ai/bits_data_analysis" >}}Explore your business data in natural language with Bits Data Analysis{{< /nextlink >}} {{< nextlink href="bits_ai/bits_detection" >}}Autonomously monitor for impactful service degradations with Bits Detection{{< /nextlink >}} {{< nextlink href="bits_ai/bits_remediation" >}}Take action on root causes with Bits Remediation{{< /nextlink >}} diff --git a/hugo/content/en/bits_ai/bits_chat.md b/hugo/content/en/bits_ai/bits_chat.md index 1f6eaaa4375..f0aec69acbb 100644 --- a/hugo/content/en/bits_ai/bits_chat.md +++ b/hugo/content/en/bits_ai/bits_chat.md @@ -22,7 +22,7 @@ aliases: --- ## Overview -Bits Chat helps you search and act across Datadog using natural language. Bits Chat is available across the web application, mobile app, and Slack. +{{< prodname >}}Bits Chat{{< /prodname >}} helps you search and act across Datadog using natural language. {{< prodname >}}Bits Chat{{< /prodname >}} is available across the web application, mobile app, and Slack. Ask Bits Chat questions across these categories: @@ -58,16 +58,16 @@ Ask Bits Chat questions across these categories: #### Access to Bits Chat -To use Bits Chat, your role must have the **Bits Chat Access** permission. This permission is enabled by default for all three standard Datadog roles: Datadog Admin, Datadog Standard, and Datadog Read Only. +To use {{< prodname >}}Bits Chat{{< /prodname >}}, your role must have the **Bits Chat Access** permission. This permission is enabled by default for all three standard Datadog roles: Datadog Admin, Datadog Standard, and Datadog Read Only. To manage this permission for custom roles, go to **Organization Settings** > **Roles**, select a role, and toggle **Bits Chat Access** under **General Permissions**. #### Data access through Bits Chat -Bits Chat uses your Datadog role to fetch data, so it can only access the resources you have permission to view or modify. For example, if your role restricts access to a specific set of logs indexes, Bits Chat can only query logs from those indexes. Similarly, if you do not have permission to edit a dashboard, Bits Chat cannot edit that dashboard on your behalf. +{{< prodname >}}Bits Chat{{< /prodname >}} uses your Datadog role to fetch data, so it can only access the resources you have permission to view or modify. For example, if your role restricts access to a specific set of logs indexes, {{< prodname >}}Bits Chat{{< /prodname >}} can only query logs from those indexes. Similarly, if you do not have permission to edit a dashboard, {{< prodname >}}Bits Chat{{< /prodname >}} cannot edit that dashboard on your behalf. ### Skills -Bits Chat has a range of specialized skills for tasks across Datadog. The most commonly used skills are described below. +{{< prodname >}}Bits Chat{{< /prodname >}} has a range of specialized skills for tasks across Datadog. The most commonly used skills are described below. #### Dashboards Build [dashboards][5] and widgets from natural language descriptions. @@ -116,19 +116,19 @@ Example prompts: ### Reports -The Bits Chat Reports page provides visibility into how your organization uses Bits Chat. Go to [**Bits AI** > **Chat** > **Reports**][10] to view: +The Bits Chat Reports page provides visibility into how your organization uses {{< prodname >}}Bits Chat{{< /prodname >}}. Go to [**Bits AI** > **Chat** > **Reports**][10] to view: -- **Top users**: See which team members use Bits Chat the most, ranked by conversation count. +- **Top users**: See which team members use {{< prodname >}}Bits Chat{{< /prodname >}} the most, ranked by conversation count. - **Usage trends**: Track conversation volume over time to understand adoption and identify usage patterns. - **Conversation intent distribution**: See how conversations break down by intent category, such as investigating issues, exploring telemetry, learning Datadog concepts, and configuring observability. Use these insights to understand adoption patterns, identify power users for best-practice sharing, and assess which use cases deliver the most value for your organization. ### Web application -There are multiple ways to open Bits Chat in the Datadog web application: -- Go to [Bits Chat][11]. +There are multiple ways to open {{< prodname >}}Bits Chat{{< /prodname >}} in the Datadog web application: +- Go to [{{< prodname >}}Bits Chat{{< /prodname >}}][11]. - In the top-right of the navigation bar, click {{< ui >}}Ask Bits{{< /ui >}}. -- In a Datadog product integrated with Bits Chat, click {{< ui >}}Ask Bits{{< /ui >}} or {{< img src="bits_ai/dev_agent/twinkling_stars_icon.png" inline="true" style="width:24px">}} (the twinkling stars icon). +- In a Datadog product integrated with {{< prodname >}}Bits Chat{{< /prodname >}}, click {{< ui >}}Ask Bits{{< /ui >}} or {{< img src="bits_ai/dev_agent/twinkling_stars_icon.png" inline="true" style="width:24px">}} (the twinkling stars icon). - Press Cmd/Ctrl + I. - In the left-side navigation panel, click {{< ui >}}Bits AI{{< /ui >}}. @@ -139,8 +139,8 @@ There are multiple ways to open Bits Chat in the Datadog web application: Ask Bits questions about your system or active incident. Bits has context on Datadog public documentation, telemetry, and ownership. 1. [Download the mobile app and log in][2]. -2. On the home screen, tap {{< ui >}}Bits Chat{{< /ui >}}. -3. Start chatting with Bits Chat by voice or text. +2. On the home screen, tap {{< ui >}}{{< prodname >}}Bits Chat{{< /prodname >}}{{< /ui >}}. +3. Start chatting with {{< prodname >}}Bits Chat{{< /prodname >}} by voice or text. {{< img src="bits_ai/getting_started/bits_ai_mobile_app_2026.png" alt="View of the Mobile App Home dashboard with Bits AI" style="width:40%;" >}} ### Slack diff --git a/hugo/content/en/bits_ai/bits_code/_index.md b/hugo/content/en/bits_ai/bits_code/_index.md index ce08feca80d..477303a340f 100644 --- a/hugo/content/en/bits_ai/bits_code/_index.md +++ b/hugo/content/en/bits_ai/bits_code/_index.md @@ -16,52 +16,52 @@ further_reading: ## Overview -Bits Code is a generative AI coding assistant that uses Datadog observability data to automatically diagnose and fix issues in your code. It integrates with [source code providers](#supported-source-code-providers) to create production-ready pull or merge requests, then iterates on changes using CI logs and developer feedback. +{{< prodname >}}Bits Code{{< /prodname >}} is a generative AI coding assistant that uses Datadog observability data to automatically diagnose and fix issues in your code. It integrates with [source code providers](#supported-source-code-providers) to create production-ready pull or merge requests, then iterates on changes using CI logs and developer feedback. {{< img src="bits_ai/dev_agent/sessions_overview.png" alt="A tab titled 'Sessions' shows a text field with suggestions underneath" style="width:100%;" >}} -Each time Bits Code investigates an issue or generates a fix, it creates a [session](#sessions), which captures the agent's analysis, actions, and any resulting code changes across supported Datadog products. Set up [automations][28] to have Bits Code run sessions on a schedule or in response to signals from other Datadog products, such as a new APM Recommendation or flaky test. +Each time {{< prodname >}}Bits Code{{< /prodname >}} investigates an issue or generates a fix, it creates a [session](#sessions), which captures the agent's analysis, actions, and any resulting code changes across supported Datadog products. Set up [automations][28] to have {{< prodname >}}Bits Code{{< /prodname >}} run sessions on a schedule or in response to signals from other Datadog products, such as a new APM Recommendation or flaky test. -To get started with Bits Code, [set up a source code integration][6] and complete any additional configuration. Then, [start your first session](#start-a-session). +To get started with {{< prodname >}}Bits Code{{< /prodname >}}, [set up a source code integration][6] and complete any additional configuration. Then, [start your first session](#start-a-session). -Learn how your Bits Code usage is billed on [AI Credits][27]. +Learn how your {{< prodname >}}Bits Code{{< /prodname >}} usage is billed on [AI Credits][27]. ## Sessions -A session captures a segment of work with Bits Code, including its analysis and code changes. Start, view, and manage your sessions at {{< ui >}}Bits AI{{< /ui >}} > {{< ui >}}Bits Code{{< /ui >}} > [{{< ui >}}Sessions{{< /ui >}}][7]. +A session captures a segment of work with {{< prodname >}}Bits Code{{< /prodname >}}, including its analysis and code changes. Start, view, and manage your sessions at {{< ui >}}Bits AI{{< /ui >}} > {{< ui >}}{{< prodname >}}Bits Code{{< /prodname >}}{{< /ui >}} > [{{< ui >}}Sessions{{< /ui >}}][7]. {{< img src="bits_ai/dev_agent/code_fix.png" alt="A session showing a Bits AI summary and task list on the left and a code diff on the right" style="width:100%;" >}} ### Start a session -After [completing setup][6], do one of the following to start a Bits Code session: +After [completing setup][6], do one of the following to start a {{< prodname >}}Bits Code{{< /prodname >}} session: - Enter a freeform prompt at [{{< ui >}}Sessions{{< /ui >}}][7]: enter a custom prompt or generate one by clicking a suggested prompt card - Invoke Bits Code in a [supported Datadog product](#supported-datadog-products) -- Set up a Bits Code [automation][28] +- Set up a {{< prodname >}}Bits Code{{< /prodname >}} [automation][28] -A session can also be created when another Bits AI agent (like [Bits Chat][16] or [Bits Investigation][17]) hands off a coding task to Bits Code. +A session can also be created when another Bits AI agent (like [{{< prodname >}}Bits Chat{{< /prodname >}}][16] or [Bits Investigation][17]) hands off a coding task to {{< prodname >}}Bits Code{{< /prodname >}}. ### Session visibility -Bits Code sessions are shared across your Datadog organization by default. Anyone in your organization can open a session to review its analysis, actions, and code changes—or continue working with Bits Code in it. This makes it easy to share context and pick up a teammate's in-progress work. +{{< prodname >}}Bits Code{{< /prodname >}} sessions are shared across your Datadog organization by default. Anyone in your organization can open a session to review its analysis, actions, and code changes—or continue working with {{< prodname >}}Bits Code{{< /prodname >}} in it. This makes it easy to share context and pick up a teammate's in-progress work. ### View and manage sessions On [{{< ui >}}Sessions{{< /ui >}}][7], the {{< ui >}}My Sessions{{< /ui >}} panel shows the sessions you're involved in. A session appears here if you initiated it or interacted with it in some way, like participating in the conversation or creating an associated PR or MR. {{< ui >}}My Sessions{{< /ui >}} is a personalized view, not a privacy boundary—that is, other members of your organization can still access these sessions. -Click a session to view its details and continue working with Bits Code. To remove a session from your {{< ui >}}My Sessions{{< /ui >}} list, click one of the following: +Click a session to view its details and continue working with {{< prodname >}}Bits Code{{< /prodname >}}. To remove a session from your {{< ui >}}My Sessions{{< /ui >}} list, click one of the following: - ({{< ui >}}Unwatch session{{< /ui >}}): removes the session from your own {{< ui >}}My Sessions{{< /ui >}} list only. Other users are not affected. - ({{< ui >}}Archive for everyone{{< /ui >}}): archives the session for all users in your organization. ## Supported source code providers -Bits Code supports the following source code providers: +{{< prodname >}}Bits Code{{< /prodname >}} supports the following source code providers: - **GitHub**: GitHub.com and [GitHub Enterprise Cloud][30] - **GitLab**: GitLab.com The following plans are not supported: - **Self-hosted plans**, such as GitHub Enterprise Server and GitLab Self-Managed. -- **Cloud-hosted plans on dedicated domains**, such as [GitHub Enterprise Cloud with data residency][31] and [GitLab Dedicated][32]. Bits Code supports only providers on the standard GitHub.com and GitLab.com domains. +- **Cloud-hosted plans on dedicated domains**, such as [GitHub Enterprise Cloud with data residency][31] and [GitLab Dedicated][32]. {{< prodname >}}Bits Code{{< /prodname >}} supports only providers on the standard GitHub.com and GitLab.com domains. ## Supported Datadog products -Bits Code can suggest code improvements within several Datadog products, including the following: +{{< prodname >}}Bits Code{{< /prodname >}} can suggest code improvements within several Datadog products, including the following: | Product | Capabilities | |---------------------------|--------------------------------------------------------------------| @@ -81,43 +81,43 @@ Bits Code can suggest code improvements within several Datadog products, includi ### Code fixes and optimizations surfaced by Datadog products -Across [supported Datadog products](#supported-datadog-products), use Bits Code to implement optimizations and fixes—for example, [Cloud Cost Recommendations][23], [Error Tracking][1] issues, and [SAST vulnerabilities][15]. In certain products, [Bits Chat][16] explores and investigates issues, then hands off its findings to Bits Code to implement a code change. +Across [supported Datadog products](#supported-datadog-products), use {{< prodname >}}Bits Code{{< /prodname >}} to implement optimizations and fixes—for example, [Cloud Cost Recommendations][23], [{{< prodname >}}Error Tracking{{< /prodname >}}][1] issues, and [SAST vulnerabilities][15]. In certain products, [{{< prodname >}}Bits Chat{{< /prodname >}}][16] explores and investigates issues, then hands off its findings to {{< prodname >}}Bits Code{{< /prodname >}} to implement a code change. {{< img src="bits_ai/dev_agent/fix_with_bits.png" alt="A button labeled with the text 'Fix with Bits.'" style="width:25%" >}} -You can manually prompt Bits Code to implement changes for a certain finding, or configure an [automation][28] so that it does so autonomously. +You can manually prompt {{< prodname >}}Bits Code{{< /prodname >}} to implement changes for a certain finding, or configure an [automation][28] so that it does so autonomously. ### General coding tasks -Use the freeform prompt field at [{{< ui >}}Sessions{{< /ui >}}][7] to work with Bits Code on general coding tasks. +Use the freeform prompt field at [{{< ui >}}Sessions{{< /ui >}}][7] to work with {{< prodname >}}Bits Code{{< /prodname >}} on general coding tasks. ### Automations -[Automations][28] run Bits Code sessions automatically, on a schedule or in response to signals from Datadog products like Error Tracking, APM, or Code Security. After a session completes, Bits Code delivers the results as a pull or merge request (optionally in draft mode) or a Slack notification. +[Automations][28] run {{< prodname >}}Bits Code{{< /prodname >}} sessions automatically, on a schedule or in response to signals from Datadog products like {{< prodname >}}Error Tracking{{< /prodname >}}, APM, or {{< prodname >}}Code Security{{< /prodname >}}. After a session completes, {{< prodname >}}Bits Code{{< /prodname >}} delivers the results as a pull or merge request (optionally in draft mode) or a Slack notification. -You can build automations from triggers (a product finding, a custom prompt, a schedule, or a combination) and configure one or more outputs. Datadog-provided templates are also available to help you get started. Create and manage automations at {{< ui >}}Bits AI{{< /ui >}} > {{< ui >}}Bits Code{{< /ui >}} > [{{< ui >}}Automations{{< /ui >}}][29]. +You can build automations from triggers (a product finding, a custom prompt, a schedule, or a combination) and configure one or more outputs. Datadog-provided templates are also available to help you get started. Create and manage automations at {{< ui >}}Bits AI{{< /ui >}} > {{< ui >}}{{< prodname >}}Bits Code{{< /prodname >}}{{< /ui >}} > [{{< ui >}}Automations{{< /ui >}}][29]. ### Custom agent skills and instructions -Bits Code can use custom skills defined in your repository. It discovers skills formatted like `/SKILL.md` in `.claude/skills/`, `.codex/skills/`, and `.gemini/skills/` directories. Skills should contain YAML `name` and `description` frontmatter keys. +{{< prodname >}}Bits Code{{< /prodname >}} can use custom skills defined in your repository. It discovers skills formatted like `/SKILL.md` in `.claude/skills/`, `.codex/skills/`, and `.gemini/skills/` directories. Skills should contain YAML `name` and `description` frontmatter keys. -Bits Code automatically invokes appropriate skills based on their `name` and `description` values, and you can encourage use by mentioning skills in your [custom instructions file][33]. You can also prompt Bits Code to use a certain skill directly. +{{< prodname >}}Bits Code{{< /prodname >}} automatically invokes appropriate skills based on their `name` and `description` values, and you can encourage use by mentioning skills in your [custom instructions file][33]. You can also prompt {{< prodname >}}Bits Code{{< /prodname >}} to use a certain skill directly. -Bits Code also [ingests custom instructions][33] defined in your repository and Bits Code settings. +{{< prodname >}}Bits Code{{< /prodname >}} also [ingests custom instructions][33] defined in your repository and {{< prodname >}}Bits Code{{< /prodname >}} settings. ### Pull or merge request collaboration -Bits Code integrates with [source code providers](#supported-source-code-providers) to: +{{< prodname >}}Bits Code{{< /prodname >}} integrates with [source code providers](#supported-source-code-providers) to: - Create pull or merge requests, generating titles and descriptions based on your repository's pull or merge request template - Iterate on pull requests in response to comments (GitHub only); mention `@Datadog` in a comment to prompt Bits for updates - Monitor CI logs and pull or merge request state to fix failures and merge blockers -Bits Code never auto-merges PRs or MRs. See all the PRs or MRs that Bits Code is working on in {{< ui >}}Bits AI{{< /ui >}} > {{< ui >}}Bits Code{{< /ui >}} > [{{< ui >}}Sessions{{< /ui >}}][7]. +{{< prodname >}}Bits Code{{< /prodname >}} never auto-merges PRs or MRs. See all the PRs or MRs that {{< prodname >}}Bits Code{{< /prodname >}} is working on in {{< ui >}}Bits AI{{< /ui >}} > {{< ui >}}{{< prodname >}}Bits Code{{< /prodname >}}{{< /ui >}} > [{{< ui >}}Sessions{{< /ui >}}][7]. ## Limitations -- Bits Code is an AI product, which means it can make mistakes. Use best practices when reviewing and testing agent-generated code. -- Bits Code does not support multi-repository investigations. +- {{< prodname >}}Bits Code{{< /prodname >}} is an AI product, which means it can make mistakes. Use best practices when reviewing and testing agent-generated code. +- {{< prodname >}}Bits Code{{< /prodname >}} does not support multi-repository investigations. - When using GitLab, mentioning `@Datadog` in a comment to prompt Bits for updates is not supported. ## Further reading diff --git a/hugo/content/en/bits_ai/bits_code/automations.md b/hugo/content/en/bits_ai/bits_code/automations.md index be744dafa7d..8d9c618d77b 100644 --- a/hugo/content/en/bits_ai/bits_code/automations.md +++ b/hugo/content/en/bits_ai/bits_code/automations.md @@ -11,20 +11,20 @@ further_reading: --- ## Overview -Create an automation that has Bits Code start a [session][1] when a trigger fires - such as a new Code Security finding or a recurring schedule. Bits Code delivers the results as a pull or merge request or a Slack notification. These sessions consume [AI Credits][8], whether you create the automation from a custom prompt or a Datadog-provided template. Follow-up interactions in those sessions also consume AI Credits. +Create an automation that has {{< prodname >}}Bits Code{{< /prodname >}} start a [session][1] when a trigger fires - such as a new {{< prodname >}}Code Security{{< /prodname >}} finding or a recurring schedule. {{< prodname >}}Bits Code{{< /prodname >}} delivers the results as a pull or merge request or a Slack notification. These sessions consume [AI Credits][8], whether you create the automation from a custom prompt or a Datadog-provided template. Follow-up interactions in those sessions also consume AI Credits. {{< img src="bits_ai/dev_agent/automations/list.png" alt="Under an 'Automate with Bits' title, a table with columns like Name, Author, and Last Run has four rows." style="width:100%;" >}} With Bits Code automations, you can: - Generate code fixes on a schedule, without starting each session manually -- Have Bits Code respond to signals from other Datadog products, such as a new APM Recommendation, a flaky test, or a Code Security finding +- Have Bits Code respond to signals from other Datadog products, such as a new APM Recommendation, a flaky test, or a {{< prodname >}}Code Security{{< /prodname >}} finding - Route the resulting code changes directly to a pull or merge request, or notify a team in Slack ## Prerequisites -To set up a Bits Code automation, each of the following must be true: +To set up a {{< prodname >}}Bits Code{{< /prodname >}} automation, each of the following must be true: - You have the [`Bits Code Write` (`bits_dev_write`) permission][6] in Datadog. -- You have completed the Bits Code [setup][2]. +- You have completed the {{< prodname >}}Bits Code{{< /prodname >}} [setup][2]. - If you plan to have your automations [output Slack notifications](#slack-message-output), you have set up the [Slack integration][4]. ## Create an automation @@ -35,8 +35,8 @@ You can [create a custom automation](#create-a-custom-automation), or [use a Dat By default, newly created automations have an {{< ui >}}Active{{< /ui >}} status, and appear in the {{< ui >}}My Automations{{< /ui >}} list. ### Create a custom automation -To create a custom Bits Code automation: -1. In Datadog, navigate to {{< ui >}}Bits AI{{< /ui >}} > {{< ui >}}Bits Code{{< /ui >}} > [{{< ui >}}Automations{{< /ui >}}][3]. +To create a custom {{< prodname >}}Bits Code{{< /prodname >}} automation: +1. In Datadog, navigate to {{< ui >}}Bits AI{{< /ui >}} > {{< ui >}}{{< prodname >}}Bits Code{{< /prodname >}}{{< /ui >}} > [{{< ui >}}Automations{{< /ui >}}][3]. 1. Click {{< ui >}}New Automation{{< /ui >}}. 1. In the {{< ui >}}Automation name{{< /ui >}} field, enter a descriptive name for the automation. 1. In the {{< ui >}}Trigger{{< /ui >}} section, configure a [trigger](#triggers). @@ -47,34 +47,34 @@ To create a custom Bits Code automation: Find Datadog-provided automation templates in the {{< ui >}}Automation Templates{{< /ui >}} section. These may include: - {{< ui >}}Create PRs based on APM Recommendations{{< /ui >}}: Generates pull or merge requests based on APM Recommendations for a specific service. -- {{< ui >}}Fix frequent errors for a repo{{< /ui >}}: Uses the [{{< ui >}}Custom Prompt{{< /ui >}}](#custom-prompt-trigger) trigger to instruct Bits Code to scan the last 24 hours of logs, find the most frequent error, and open a pull or merge request with a fix. +- {{< ui >}}Fix frequent errors for a repo{{< /ui >}}: Uses the [{{< ui >}}Custom Prompt{{< /ui >}}](#custom-prompt-trigger) trigger to instruct {{< prodname >}}Bits Code{{< /prodname >}} to scan the last 24 hours of logs, find the most frequent error, and open a pull or merge request with a fix. Click a template tile to be taken to the new automation form. You must configure an [output](#outputs) before creating the automation. ## Triggers -A trigger defines when an automation runs and what Bits Code acts on. A trigger is built from up to three components: +A trigger defines when an automation runs and what {{< prodname >}}Bits Code{{< /prodname >}} acts on. A trigger is built from up to three components: -- [Product finding](#product-finding-trigger): a signal from within Datadog, such as an Error Tracking issue -- [Custom prompt](#custom-prompt-trigger): a freeform instruction telling Bits Code what to do against a chosen repository +- [Product finding](#product-finding-trigger): a signal from within Datadog, such as an {{< prodname >}}Error Tracking{{< /prodname >}} issue +- [Custom prompt](#custom-prompt-trigger): a freeform instruction telling {{< prodname >}}Bits Code{{< /prodname >}} what to do against a chosen repository - [Schedule](#schedule-trigger): a recurring time interval, such as daily or on specific days of the week Click {{< ui >}}Add Trigger{{< /ui >}} to add a component. You can combine a product finding with a schedule, a custom prompt with a schedule, or use a product finding on its own. -To limit how many Bits Code sessions the automation can create in a given period (for example, `5 runs per Week`), click {{< ui >}}Add Trigger{{< /ui >}} > {{< ui >}}Set max runs{{< /ui >}}. One automation execution may produce more than one session. Use this setting to control the volume of pull or merge requests, or Slack notifications, an automation produces. +To limit how many {{< prodname >}}Bits Code{{< /prodname >}} sessions the automation can create in a given period (for example, `5 runs per Week`), click {{< ui >}}Add Trigger{{< /ui >}} > {{< ui >}}Set max runs{{< /ui >}}. One automation execution may produce more than one session. Use this setting to control the volume of pull or merge requests, or Slack notifications, an automation produces. ### Product finding trigger -A product finding trigger runs the automation in response to new issues in another Datadog product (for example, Error Tracking or Code Security). You can use a product finding trigger by itself, which runs the automation whenever there is a new finding, or with a [schedule](#schedule-trigger) and lookback window you define (in the {{< ui >}}New findings within{{< /ui >}} field). +A product finding trigger runs the automation in response to new issues in another Datadog product (for example, {{< prodname >}}Error Tracking{{< /prodname >}} or {{< prodname >}}Code Security{{< /prodname >}}). You can use a product finding trigger by itself, which runs the automation whenever there is a new finding, or with a [schedule](#schedule-trigger) and lookback window you define (in the {{< ui >}}New findings within{{< /ui >}} field).
While it's common to use a product finding trigger alone (to immediately remediate new findings), coupling it with a schedule and lookback window lets you monitor for new findings only during certain times. For example, if you deploy weekly on Wednesdays, you may want to configure an APM Recommendations trigger to run every Thursday, looking back 24 hours.
When setting up a product finding trigger, you can configure additional filters, which vary by product. For example: - {{< ui >}}Flaky Tests{{< /ui >}} supports filtering by {{< ui >}}Repository{{< /ui >}}, {{< ui >}}Branch{{< /ui >}} (defaults to the repository's default branch), and {{< ui >}}Status{{< /ui >}}. - - {{< ui >}}Code Security (SAST){{< /ui >}} supports filtering by {{< ui >}}Repository{{< /ui >}}, {{< ui >}}Severity{{< /ui >}}, {{< ui >}}Rule to remediate{{< /ui >}}, and a toggle to {{< ui >}}Filter out findings identified as false positives by Bits AI{{< /ui >}}. + - {{< ui >}}{{< prodname >}}Code Security{{< /prodname >}} (SAST){{< /ui >}} supports filtering by {{< ui >}}Repository{{< /ui >}}, {{< ui >}}Severity{{< /ui >}}, {{< ui >}}Rule to remediate{{< /ui >}}, and a toggle to {{< ui >}}Filter out findings identified as false positives by Bits AI{{< /ui >}}.
Each finding that triggers an automation must have its own session, and related pull or merge request. Multiple findings cannot be fixed in a single session.
### Custom prompt trigger -A custom prompt tells Bits Code what to do each time the automation runs, in freeform text, against a chosen repository. Use a custom prompt for recurring maintenance tasks that aren't tied to a specific Datadog signal, such as updating dependencies or refreshing documentation. +A custom prompt tells {{< prodname >}}Bits Code{{< /prodname >}} what to do each time the automation runs, in freeform text, against a chosen repository. Use a custom prompt for recurring maintenance tasks that aren't tied to a specific Datadog signal, such as updating dependencies or refreshing documentation. ### Schedule trigger A schedule trigger controls when an automation runs. It can be used in combination with a [product finding](#product-finding-trigger) or a [custom prompt](#custom-prompt-trigger). When setting a schedule, you can choose from: @@ -82,19 +82,19 @@ A schedule trigger controls when an automation runs. It can be used in combinati - {{< ui >}}Custom Schedule{{< /ui >}}: Choose specific days of the week and a time of day (for example, `Mo, We, Fr at 03:00 pm`). ## Outputs -An output defines what Bits Code does after a [session][1] completes. An automation can have one or more outputs, including [opening a pull or merge request](#pull-or-merge-request-output) and [generating a Slack notification](#slack-message-output). +An output defines what {{< prodname >}}Bits Code{{< /prodname >}} does after a [session][1] completes. An automation can have one or more outputs, including [opening a pull or merge request](#pull-or-merge-request-output) and [generating a Slack notification](#slack-message-output). ### Pull or merge request output You can configure your automation to: - {{< ui >}}Create a PR or MR{{< /ui >}}: Open a pull or merge request with the proposed changes - {{< ui >}}Draft a PR or MR{{< /ui >}}: Open a draft pull or merge request with the proposed changes -Datadog administrators can configure pull or merge request authorship through the {{< ui >}}Create pull and merge requests as Bits Code{{< /ui >}} setting in [Bits Code settings][7]. When this setting is enabled, the Bits Code integration identity for the source control provider (for example, the `datadog[bot]` GitHub App account) is the author. When it's disabled, the session creator's connected source control account is the author. +Datadog administrators can configure pull or merge request authorship through the {{< ui >}}Create pull and merge requests as {{< prodname >}}Bits Code{{< /prodname >}}{{< /ui >}} setting in [Bits Code settings][7]. When this setting is enabled, the {{< prodname >}}Bits Code{{< /prodname >}} integration identity for the source control provider (for example, the `datadog[bot]` GitHub App account) is the author. When it's disabled, the session creator's connected source control account is the author. ### Slack message output -You can configure your automation to send a Slack message summarizing the [session][1] and code changes. If you use a pull or merge request output in addition to a Slack output, Bits Code includes a link to the pull or merge request in the Slack message. +You can configure your automation to send a Slack message summarizing the [session][1] and code changes. If you use a pull or merge request output in addition to a Slack output, {{< prodname >}}Bits Code{{< /prodname >}} includes a link to the pull or merge request in the Slack message. -When you add a Slack message output, by default, Bits Code sends the message to the channel configured for the affected service in [Catalog][5]. You can set a fallback Slack channel, which is used when no channel is set in Catalog. +When you add a Slack message output, by default, {{< prodname >}}Bits Code{{< /prodname >}} sends the message to the channel configured for the affected service in [Catalog][5]. You can set a fallback Slack channel, which is used when no channel is set in Catalog. ## Manage automations On [{{< ui >}}Automations{{< /ui >}}][3], view the automations you created on the {{< ui >}}My Automations{{< /ui >}} tab. Switch to {{< ui >}}All{{< /ui >}} to see automations created by anyone in your organization. diff --git a/hugo/content/en/bits_ai/bits_code/setup.md b/hugo/content/en/bits_ai/bits_code/setup.md index 4f636bbd5e6..609d9b4a9e7 100644 --- a/hugo/content/en/bits_ai/bits_code/setup.md +++ b/hugo/content/en/bits_ai/bits_code/setup.md @@ -7,30 +7,30 @@ disable_toc: false ## Overview -[Bits Code][8] integrates with [source code providers][11] to open, update, and iterate on pull or merge requests based on issues detected in Datadog. After completing setup, you can [start using Bits Code][7]. +[{{< prodname >}}Bits Code{{< /prodname >}}][8] integrates with [source code providers][11] to open, update, and iterate on pull or merge requests based on issues detected in Datadog. After completing setup, you can [start using Bits Code][7]. ## Prerequisites -To set up Bits Code, you need the [`Bits Code Write` (`bits_dev_write`) permission][1]. This permission is included in managed Datadog roles such as the Datadog Standard Role. +To set up {{< prodname >}}Bits Code{{< /prodname >}}, you need the [`Bits Code Write` (`bits_dev_write`) permission][1]. This permission is included in managed Datadog roles such as the Datadog Standard Role. If your organization uses custom roles, an admin must add this permission manually. For details, see [Access Control][1]. ## Setup -Set up Bits Code for one of the [supported source code providers][11]. +Set up {{< prodname >}}Bits Code{{< /prodname >}} for one of the [supported source code providers][11]. {{< tabs >}} {{% tab "GitHub" %}} 1. Install the [GitHub integration][1]. For full installation and configuration steps, see the [GitHub integration guide][2]. 1. In your GitHub account, navigate to {{< ui >}}Settings{{< /ui >}} > {{< ui >}}Apps{{< /ui >}} > {{< ui >}}Datadog{{< /ui >}} to configure GitHub permissions. - 1. To enable basic Bits Code functionality, set the following permissions: + 1. To enable basic {{< prodname >}}Bits Code{{< /prodname >}} functionality, set the following permissions: - {{< ui >}}Repository permissions{{< /ui >}} - Repository contents: Read & write - Pull requests: Read & write - {{< ui >}}Subscribe to events{{< /ui >}} - Push - 1. (Optional) To allow Bits Code to use CI logs when iterating on pull requests, you must send CI logs to Datadog and enable the [auto-push](#enable-auto-push) feature. This requires additional permissions: + 1. (Optional) To allow {{< prodname >}}Bits Code{{< /prodname >}} to use CI logs when iterating on pull requests, you must send CI logs to Datadog and enable the [auto-push](#enable-auto-push) feature. This requires additional permissions: - {{< ui >}}Repository permissions{{< /ui >}} - Checks: Read - Commit statuses: Read only @@ -65,32 +65,32 @@ Set up Bits Code for one of the [supported source code providers][11]. ## Additional configuration -These optional configurations help you get the most out of Bits Code. +These optional configurations help you get the most out of {{< prodname >}}Bits Code{{< /prodname >}}. ### Configure telemetry tagging -Bits Code uses the `service` and `version` telemetry tags to match detected issues (such as errors or vulnerabilities) to the version of code that was running at the time. +{{< prodname >}}Bits Code{{< /prodname >}} uses the `service` and `version` telemetry tags to match detected issues (such as errors or vulnerabilities) to the version of code that was running at the time. To configure telemetry tagging, see [Tag your APM telemetry with Git information][4]. -You can also configure service-to-repository mapping manually in Bits Code settings under [{{< ui >}}Repositories{{< /ui >}}][5] > {{< ui >}}Service Repository Mapping{{< /ui >}}. +You can also configure service-to-repository mapping manually in {{< prodname >}}Bits Code{{< /prodname >}} settings under [{{< ui >}}Repositories{{< /ui >}}][5] > {{< ui >}}Service Repository Mapping{{< /ui >}}. ### Enable auto-push -Auto-push allows Bits Code to create branches, push code, and open PRs or MRs when it detects something it can help you with. Auto-push only opens PRs or MRs and pushes changes; it never merges code. When auto-push is disabled, you must review code in Datadog before it gets pushed. +Auto-push allows {{< prodname >}}Bits Code{{< /prodname >}} to create branches, push code, and open PRs or MRs when it detects something it can help you with. Auto-push only opens PRs or MRs and pushes changes; it never merges code. When auto-push is disabled, you must review code in Datadog before it gets pushed. -To enable auto-push, navigate to {{< ui >}}Bits Code{{< /ui >}} > {{< ui >}}Settings{{< /ui >}} > [{{< ui >}}General{{< /ui >}}][6]. +To enable auto-push, navigate to {{< ui >}}{{< prodname >}}Bits Code{{< /prodname >}}{{< /ui >}} > {{< ui >}}Settings{{< /ui >}} > [{{< ui >}}General{{< /ui >}}][6]. #### Security considerations -Allowing any AI-based tool to read untrusted data can let attackers influence its output. Auto-push behavior depends on the type of data Bits Code works with: code-only workflows operate on source code the Agent can inspect directly, while telemetry-based workflows (such as errors or traces) may include untrusted runtime inputs. +Allowing any AI-based tool to read untrusted data can let attackers influence its output. Auto-push behavior depends on the type of data {{< prodname >}}Bits Code{{< /prodname >}} works with: code-only workflows operate on source code the Agent can inspect directly, while telemetry-based workflows (such as errors or traces) may include untrusted runtime inputs. To balance safety and automation, you can configure auto-push behavior in [Datadog][6] (for example, limiting auto-push to code-only workflows or requiring review when telemetry is involved). Datadog scans all Agent-generated code before pushing changes, but these safeguards are not foolproof. ### Configure custom instructions -Bits Code ingests custom instruction files from your repository, including: +{{< prodname >}}Bits Code{{< /prodname >}} ingests custom instruction files from your repository, including: - `AGENTS.md` - `CLAUDE.md` @@ -99,9 +99,9 @@ Bits Code ingests custom instruction files from your repository, including: - `.windsurfrules` - `copilot-instructions.md` -You can also define global custom instructions that apply to all Bits Code sessions in {{< ui >}}Bits Code{{< /ui >}} > {{< ui >}}Settings{{< /ui >}} > [{{< ui >}}General{{< /ui >}}][6], in the {{< ui >}}Global Agent Instructions{{< /ui >}} section. +You can also define global custom instructions that apply to all {{< prodname >}}Bits Code{{< /prodname >}} sessions in {{< ui >}}{{< prodname >}}Bits Code{{< /prodname >}}{{< /ui >}} > {{< ui >}}Settings{{< /ui >}} > [{{< ui >}}General{{< /ui >}}][6], in the {{< ui >}}Global Agent Instructions{{< /ui >}} section. -A custom instruction file is a good place to mention [custom skills][12] you'd like Bits Code to use. +A custom instruction file is a good place to mention [custom skills][12] you'd like {{< prodname >}}Bits Code{{< /prodname >}} to use. ## Environment setup @@ -109,7 +109,7 @@ Configure Bits Code's runtime environment, including network access policies and ### Configure internet access -By default, Bits Code has **no internet access** during agent execution. To configure which external domains agents can reach, navigate to {{< ui >}}Bits Code{{< /ui >}} > {{< ui >}}Settings{{< /ui >}} > [{{< ui >}}General{{< /ui >}}][6], and find the {{< ui >}}Internet Access{{< /ui >}} section. Choose from the following access policies: {{< ui >}}No Internet Access{{< /ui >}}, {{< ui >}}Default Allowlist{{< /ui >}}, {{< ui >}}Custom + Default Allowlist{{< /ui >}}, or {{< ui >}}Custom Allowlist{{< /ui >}}. +By default, {{< prodname >}}Bits Code{{< /prodname >}} has **no internet access** during agent execution. To configure which external domains agents can reach, navigate to {{< ui >}}{{< prodname >}}Bits Code{{< /prodname >}}{{< /ui >}} > {{< ui >}}Settings{{< /ui >}} > [{{< ui >}}General{{< /ui >}}][6], and find the {{< ui >}}Internet Access{{< /ui >}} section. Choose from the following access policies: {{< ui >}}No Internet Access{{< /ui >}}, {{< ui >}}Default Allowlist{{< /ui >}}, {{< ui >}}Custom + Default Allowlist{{< /ui >}}, or {{< ui >}}Custom Allowlist{{< /ui >}}. The default allowlist includes the following domains. This list will evolve over time based on user feedback and ecosystem changes. To avoid changes, configure a custom allowlist. @@ -128,20 +128,20 @@ The default allowlist includes the following domains. This list will evolve over ### Configure repository environment -Configure a custom environment for Bits Code to install dependencies, formatters, linters, and build tools that are needed for your codebase. Each repository runs in its own isolated sandbox, and the environment defines the settings for that sandbox. +Configure a custom environment for {{< prodname >}}Bits Code{{< /prodname >}} to install dependencies, formatters, linters, and build tools that are needed for your codebase. Each repository runs in its own isolated sandbox, and the environment defines the settings for that sandbox. To configure a repository environment: -1. Go to {{< ui >}}Bits Code{{< /ui >}} > {{< ui >}}Settings{{< /ui >}} > [{{< ui >}}Repositories{{< /ui >}}][5], and find the {{< ui >}}Environments{{< /ui >}} section. +1. Go to {{< ui >}}{{< prodname >}}Bits Code{{< /prodname >}}{{< /ui >}} > {{< ui >}}Settings{{< /ui >}} > [{{< ui >}}Repositories{{< /ui >}}][5], and find the {{< ui >}}Environments{{< /ui >}} section. 1. Click {{< ui >}}Add Environment{{< /ui >}} to create a repository configuration: 1. Select a repository from the dropdown. 1. (Optional) Under {{< ui >}}Pre-installed Languages{{< /ui >}}, click {{< ui >}}Select Versions{{< /ui >}} to specify the language versions the sandbox should use. - 1. (Optional) Define environment variables and secrets. Environment variables are available during both environment setup and Bits Code execution. Secrets are available as environment variables only during environment setup. + 1. (Optional) Define environment variables and secrets. Environment variables are available during both environment setup and {{< prodname >}}Bits Code{{< /prodname >}} execution. Secrets are available as environment variables only during environment setup. 1. (Optional) Add a shell script with setup commands to execute (for example: `pip install -r requirements.txt`). 1. Run the setup command to ensure it runs successfully. 1. Save the configuration. -Bits Code runs the setup command at startup and can use any tools installed in your environment. The setup command runs with network access enabled to download dependencies. After setup is complete, your [internet access](#configure-internet-access) policy controls outbound network access during agent execution. Because setup commands execute against code in your repository, enable them only if you trust the repository's code. +{{< prodname >}}Bits Code{{< /prodname >}} runs the setup command at startup and can use any tools installed in your environment. The setup command runs with network access enabled to download dependencies. After setup is complete, your [internet access](#configure-internet-access) policy controls outbound network access during agent execution. Because setup commands execute against code in your repository, enable them only if you trust the repository's code. **Note**: For best results, add a [custom instructions file](#configure-custom-instructions) (like `claude.md`) to your repository with instructions on how to build and test your code. diff --git a/hugo/content/en/bits_ai/bits_data_analysis/_index.md b/hugo/content/en/bits_ai/bits_data_analysis/_index.md index 1de084e3b82..d790138d464 100644 --- a/hugo/content/en/bits_ai/bits_data_analysis/_index.md +++ b/hugo/content/en/bits_ai/bits_data_analysis/_index.md @@ -55,7 +55,7 @@ Ask Bits Data Analysis questions like: Query contexts are curated instructions per data domain, such as Product or Sales. Each context tells Bits Data Analysis which tables to use, which filters to apply, and which edge cases to avoid. Query contexts are what make Bits Data Analysis accurate and consistent. -Bits Data Analysis can auto-generate query contexts from usage and metadata in your connected BI tools and data warehouses through [Data Observability][4]. Data teams then review and refine the generated instructions so anyone on the team can get reliable answers, without analyst expertise or analyst involvement. +Bits Data Analysis can auto-generate query contexts from usage and metadata in your connected BI tools and data warehouses through [{{< prodname >}}Data Observability{{< /prodname >}}][4]. Data teams then review and refine the generated instructions so anyone on the team can get reliable answers, without analyst expertise or analyst involvement. ### Example: revenue query context diff --git a/hugo/content/en/bits_ai/bits_investigation/configure.md b/hugo/content/en/bits_ai/bits_investigation/configure.md index 96aab566c3d..1eb9b5d5c30 100644 --- a/hugo/content/en/bits_ai/bits_investigation/configure.md +++ b/hugo/content/en/bits_ai/bits_investigation/configure.md @@ -11,7 +11,7 @@ Set up integrations to extend Bits Investigation's capabilities: ## Integrate with third-party observability and SCM platforms -Bits Investigation integrates with GitHub, Grafana, Dynatrace, Splunk, Sentry, and ServiceNow to incorporate observability data and source code into investigations. Source code access is also required for Bits Code to generate a code fix when Bits Investigation identifies an issue that can be resolved in code. +Bits Investigation integrates with GitHub, Grafana, Dynatrace, Splunk, Sentry, and ServiceNow to incorporate observability data and source code into investigations. Source code access is also required for {{< prodname >}}Bits Code{{< /prodname >}} to generate a code fix when Bits Investigation identifies an issue that can be resolved in code. ### GitHub To configure GitHub: @@ -43,12 +43,12 @@ The Microsoft Teams integration with Bits Investigation is in Preview for all cu ### Datadog Case Management -Datadog Case Management provides a centralized workspace for triaging, tracking, and remediating issues detected by Datadog and third-party integrations. Bits Investigation automatically delivers its investigation findings to Jira and ServiceNow through Case Management. +Datadog Case Management provides a centralized workspace for triaging, tracking, and remediating issues detected by Datadog and third-party integrations. Bits Investigation automatically delivers its investigation findings to Jira and ServiceNow through {{< prodname >}}Case Management{{< /prodname >}}. -To set up Case Management, and the Jira and ServiceNow integrations: +To set up {{< prodname >}}Case Management{{< /prodname >}}, and the Jira and ServiceNow integrations: 1. Create a [Case Management project][5] for your team. 1. In Datadog, go to [{{< ui >}}Case Management{{< /ui >}} > {{< ui >}}Settings{{< /ui >}}][6]. In the list of projects, expand your project, go to {{< ui >}}Integrations{{< /ui >}} > {{< ui >}}Datadog Monitors{{< /ui >}}, and turn on the {{< ui >}}Enable Datadog Monitors integration for this project{{< /ui >}} toggle. This generates your project's unique handle: `@case-{project_name}`. -1. On the same page, under {{< ui >}}Integrations{{< /ui >}}, set up the Case Management Jira and/or ServiceNow integrations. When a new case is created, Case Management can automatically open the corresponding Jira ticket or ServiceNow incident. +1. On the same page, under {{< ui >}}Integrations{{< /ui >}}, set up the Case Management Jira and/or ServiceNow integrations. When a new case is created, {{< prodname >}}Case Management{{< /prodname >}} can automatically open the corresponding Jira ticket or ServiceNow incident. 1. In your monitor, go to {{< ui >}}Configure notifications and automations{{< /ui >}} and add the `@case-{project_name}` handle. When the monitor triggers: - Datadog automatically creates a new case - The case creates a linked Jira ticket or ServiceNow incident @@ -58,7 +58,7 @@ To set up Case Management, and the Jira and ServiceNow integrations: Datadog On-Call is a paging solution that unifies monitoring, paging, and incident response in a single platform. -To set up On-Call, in your monitor, go to {{< ui >}}Configure notifications and automations{{< /ui >}} and add the `@oncall-{team}` handle. Bits' findings can then appear on the On-Call page in the Datadog mobile app, helping your teams triage issues on the go. +To set up {{< prodname >}}On-Call{{< /prodname >}}, in your monitor, go to {{< ui >}}Configure notifications and automations{{< /ui >}} and add the `@oncall-{team}` handle. Bits' findings can then appear on the {{< prodname >}}On-Call{{< /prodname >}} page in the Datadog mobile app, helping your teams triage issues on the go. ## Pull context from knowledge bases diff --git a/hugo/content/en/bits_ai/bits_investigation/investigate_issues.md b/hugo/content/en/bits_ai/bits_investigation/investigate_issues.md index 05555e1693a..4e0654b176b 100644 --- a/hugo/content/en/bits_ai/bits_investigation/investigate_issues.md +++ b/hugo/content/en/bits_ai/bits_investigation/investigate_issues.md @@ -121,12 +121,12 @@ Bits uses the following data sources during investigations: - Logs - Dashboards - Events -- [Change Tracking][4] +- [{{< prodname >}}Change Tracking{{< /prodname >}}][4] - [Source code][17] (GitHub only) - Watchdog - Real User Monitoring - Network Path -- Database Monitoring +- {{< prodname >}}Database Monitoring{{< /prodname >}} - Continuous Profiler
Add service scoping: For monitors associated with a service, add a service tag to the monitor, or filter or group the monitor query by service. This helps Bits correlate data more accurately.
diff --git a/hugo/content/en/bits_ai/bits_remediation.md b/hugo/content/en/bits_ai/bits_remediation.md index 312d4078d57..791dff9d7a4 100644 --- a/hugo/content/en/bits_ai/bits_remediation.md +++ b/hugo/content/en/bits_ai/bits_remediation.md @@ -12,7 +12,7 @@ site_support_id: bits_remediation ## Suggested code fixes from Bits Code After Bits Investigation helps you identify a root cause, it can also help you take action as quickly as possible. -Bits Investigation integrates with [Bits Code][2] to automatically generate code fixes. Bits Code connects to GitHub to create production-ready pull requests, iterates on fixes using CI logs and developer feedback, and uses multiple Datadog products to generate contextual fixes. +Bits Investigation integrates with [{{< prodname >}}Bits Code{{< /prodname >}}][2] to automatically generate code fixes. {{< prodname >}}Bits Code{{< /prodname >}} connects to GitHub to create production-ready pull requests, iterates on fixes using CI logs and developer feedback, and uses multiple Datadog products to generate contextual fixes. 1. [Set up Bits Code][1]. Then, after Bits Investigation has determined a code-related root cause, you will automatically receive suggested code fixes. 1. Ask Bits Code to make any additional updates as needed, create a pull request for review in GitHub, and merge when ready to fix the underlying problem. diff --git a/hugo/content/en/bits_ai/bits_security_analyst.md b/hugo/content/en/bits_ai/bits_security_analyst.md index a52f595fba7..c1b59761dff 100644 --- a/hugo/content/en/bits_ai/bits_security_analyst.md +++ b/hugo/content/en/bits_ai/bits_security_analyst.md @@ -19,13 +19,13 @@ further_reading: ## Overview -Bits Security Analyst is an autonomous AI agent that investigates Cloud SIEM signals end to end. It queries security signals and logs, and uses data-based reasoning to help security engineers investigate threat alerts and make a recommendation on the verdict of each alert signal. By reducing manual effort and analyst fatigue, Bits Security Analyst makes security operations smoother and more efficient. +{{< prodname >}}Bits Security Analyst{{< /prodname >}} is an autonomous AI agent that investigates {{< prodname >}}Cloud SIEM{{< /prodname >}} signals end to end. It queries security signals and logs, and uses data-based reasoning to help security engineers investigate threat alerts and make a recommendation on the verdict of each alert signal. By reducing manual effort and analyst fatigue, {{< prodname >}}Bits Security Analyst{{< /prodname >}} makes security operations smoother and more efficient. ### Key capabilities -Bits Security Analyst investigations are autonomous. If a detection rule is enabled, Bits AI autonomously investigates signals associated with it. +{{< prodname >}}Bits Security Analyst{{< /prodname >}} investigations are autonomous. If a detection rule is enabled, Bits AI autonomously investigates signals associated with it. -In the [Cloud SIEM Signals Explorer][5], you can click the {{< ui >}}Bits Security Analyst{{< /ui >}} tab to only show signals that Bits AI investigated. In the Severity column, a Bits AI status displays as Investigating, until marking the signal as either Benign or Suspicious. +In the [Cloud SIEM Signals Explorer][5], you can click the {{< ui >}}{{< prodname >}}Bits Security Analyst{{< /prodname >}}{{< /ui >}} tab to only show signals that Bits AI investigated. In the Severity column, a Bits AI status displays as Investigating, until marking the signal as either Benign or Suspicious. {{< img src="bits_ai/bits_security_analyst_signals_explorer.png" alt="The Cloud SIEM signals explorer, on the Bits Security Analyst tab" style="width:100%;" >}} @@ -45,10 +45,10 @@ You can also take additional steps directly from the side panel: - Run a workflow with a SOAR blueprint - Declare an incident - Add a rule suppression -- Archive the signal, or view the signal with the usual Cloud SIEM interface +- Archive the signal, or view the signal with the usual {{< prodname >}}Cloud SIEM{{< /prodname >}} interface - Give Bits AI feedback on its analysis -Additionally, when you use Cloud SIEM notifications to send new signal alerts to Slack or Jira, Bits AI automatically updates those notifications. It includes replies showing the Bits AI investigative conclusion, with a link to the full investigation. +Additionally, when you use {{< prodname >}}Cloud SIEM{{< /prodname >}} notifications to send new signal alerts to Slack or Jira, Bits AI automatically updates those notifications. It includes replies showing the Bits AI investigative conclusion, with a link to the full investigation. ### Supported sources @@ -86,22 +86,22 @@ Bits AI can run investigations on the following Security log sources: ### Prerequisites -To use Bits Security Analyst: -- Ensure your organization is using a non-legacy version of Cloud SIEM. If you need assistance, contact [Datadog support][1]. -- To set up Bits Security Analyst, you need the **Bits Security Analyst Config Write** [permission][2]. -- To view investigations, you must have **14 days or more** of log history. If you have a shorter log history, you can still set up Bits Security Analyst, but won't see any investigations until you have that much history. +To use {{< prodname >}}Bits Security Analyst{{< /prodname >}}: +- Ensure your organization is using a non-legacy version of {{< prodname >}}Cloud SIEM{{< /prodname >}}. If you need assistance, contact [Datadog support][1]. +- To set up {{< prodname >}}Bits Security Analyst{{< /prodname >}}, you need the **Bits Security Analyst Config Write** [permission][2]. +- To view investigations, you must have **14 days or more** of log history. If you have a shorter log history, you can still set up {{< prodname >}}Bits Security Analyst{{< /prodname >}}, but won't see any investigations until you have that much history. ### Setup -When you enable Bits Security Analyst, Datadog analyzes your rules, including custom rules, to determine whether it can confidently investigate signals associated with them. For all eligible rules above medium severity, it starts autonomously investigating signals. +When you enable {{< prodname >}}Bits Security Analyst{{< /prodname >}}, Datadog analyzes your rules, including custom rules, to determine whether it can confidently investigate signals associated with them. For all eligible rules above medium severity, it starts autonomously investigating signals. Rule eligibility depends on whether Datadog has built the investigation capability for the log source, and whether the Agent is able to investigate the specific rule. If you have new custom rules to evaluate, or want to ask about a rule that wasn't made eligible, contact [Datadog support][1]. 1. In Datadog, go to {{< ui >}}Security{{< /ui >}} > {{< ui >}}Settings{{< /ui >}} > {{< ui >}}Bits Security Analyst{{< /ui >}} > [{{< ui >}}Analyst Configuration{{< /ui >}}][3]. 1. Turn on the toggle to {{< ui >}}Enable Bits Security Analyst{{< /ui >}}. Additional settings appear. -1. (Optional) Configure which rules and which severities you want Bits Security Analyst to automatically investigate signals for. There are two ways to do so: +1. (Optional) Configure which rules and which severities you want {{< prodname >}}Bits Security Analyst{{< /prodname >}} to automatically investigate signals for. There are two ways to do so: - Click {{< ui >}}Rule Settings{{< /ui >}} to configure investigations for individual rules. You can change the minimum severity for signals to be investigated, and enable or disable individual rules for investigation. - - Click {{< ui >}}Query Filter{{< /ui >}} to write a signal query filter, so Bits Security Analyst only investigates signals that match your filter. + - Click {{< ui >}}Query Filter{{< /ui >}} to write a signal query filter, so {{< prodname >}}Bits Security Analyst{{< /prodname >}} only investigates signals that match your filter. 1. Some log sources require credentials to run or enhance investigations by accessing logs, telemetry, or other data that isn't in Datadog. To add credentials, click {{< ui >}}Edit credentials{{< /ui >}}. In the {{< ui >}}Select or Add Connection{{< /ui >}} window that opens, follow the prompts to select an [existing connection][4] from Actions Catalog, or add a connection. Datadog securely stores and restricts all credentials using Actions Catalog. Some log sources require additional setup so you can create HTTP connections. Here are some examples: @@ -213,27 +213,27 @@ Rule eligibility depends on whether Datadog has built the investigation capabili ### Add knowledge sources -You can provide additional context for Bits Security Analyst, such as details about your organization's authorization rules, policies, and environment, allowing Bits to produce more accurate investigations tailored to your organization's needs. +You can provide additional context for {{< prodname >}}Bits Security Analyst{{< /prodname >}}, such as details about your organization's authorization rules, policies, and environment, allowing Bits to produce more accurate investigations tailored to your organization's needs. -To add knowledge, in Datadog, go to {{< ui >}}Security{{< /ui >}} > {{< ui >}}Settings{{< /ui >}} > {{< ui >}}Bits Security Analyst{{< /ui >}} > [{{< ui >}}Knowledge Sources{{< /ui >}}][8]. There, you can add two kinds of knowledge: -- **General Org Context (Bits.md)**: Organization-level instructions that Bits Security Analyst should apply to all investigations. +To add knowledge, in Datadog, go to {{< ui >}}Security{{< /ui >}} > {{< ui >}}Settings{{< /ui >}} > {{< ui >}}{{< prodname >}}Bits Security Analyst{{< /prodname >}}{{< /ui >}} > [{{< ui >}}Knowledge Sources{{< /ui >}}][8]. There, you can add two kinds of knowledge: +- **General Org Context (Bits.md)**: Organization-level instructions that {{< prodname >}}Bits Security Analyst{{< /prodname >}} should apply to all investigations. 1. Click **Edit** to make the field editable so you can make your changes. 1. Click **Save**. -- **Situational Context**: Investigation-specific facts that Bits Security Analyst should apply in specific situations. You can search and filter the table of context entries, and choose to view expired entries, to get an overview of existing context. +- **Situational Context**: Investigation-specific facts that {{< prodname >}}Bits Security Analyst{{< /prodname >}} should apply in specific situations. You can search and filter the table of context entries, and choose to view expired entries, to get an overview of existing context. 1. Click **Create Context Entry**. In the window that opens, enter: 1. **Title**: A short title for your entry. - 1. **Context description**: The information you want Bits Security Analyst to take into account. + 1. **Context description**: The information you want {{< prodname >}}Bits Security Analyst{{< /prodname >}} to take into account. 1. **Status**: Choose to enable this piece of context, or to save it without enabling it. - 1. **Expiration date** (optional): A date for Bits Security Analyst to stop taking this piece of context into account. + 1. **Expiration date** (optional): A date for {{< prodname >}}Bits Security Analyst{{< /prodname >}} to stop taking this piece of context into account. 1. Click **Create Entry**. The window closes and your context appears in the table. ### Get notifications for completed investigations -You can create security notification rules to get a notification when Bits Security Analyst completes an investigation. To do so, follow the instructions in [Create notification rules][7]. When specifying the tags and attributes that must be present for the notification rule to be triggered, add the tag `@workflow.bits_investigator.state:*`. +You can create security notification rules to get a notification when {{< prodname >}}Bits Security Analyst{{< /prodname >}} completes an investigation. To do so, follow the instructions in [Create notification rules][7]. When specifying the tags and attributes that must be present for the notification rule to be triggered, add the tag `@workflow.bits_investigator.state:*`. ## Disable Bits Security Analyst -1. In Datadog, go to {{< ui >}}Security{{< /ui >}} > {{< ui >}}Settings{{< /ui >}} > {{< ui >}}Bits Security Analyst{{< /ui >}} > [{{< ui >}}Analyst Configuration{{< /ui >}}][3]. +1. In Datadog, go to {{< ui >}}Security{{< /ui >}} > {{< ui >}}Settings{{< /ui >}} > {{< ui >}}{{< prodname >}}Bits Security Analyst{{< /prodname >}}{{< /ui >}} > [{{< ui >}}Analyst Configuration{{< /ui >}}][3]. 1. Scroll to the bottom of the page. Under {{< ui >}}Disable Bits Security Analyst{{< /ui >}}, turn off the {{< ui >}}Enabled{{< /ui >}} toggle.
Disabling Bits Security Analyst permanently resets all configuration settings.
diff --git a/hugo/content/en/byoc-logs/_index.md b/hugo/content/en/byoc-logs/_index.md index d4133850228..7d476769b87 100644 --- a/hugo/content/en/byoc-logs/_index.md +++ b/hugo/content/en/byoc-logs/_index.md @@ -15,12 +15,12 @@ BYOC (Bring Your Own Cloud) Logs is Datadog's log management solution for organi ## Get started {{< whatsnext desc="Follow our guides to get BYOC Logs up and running:">}} - {{< nextlink href="/byoc-logs/introduction/" >}}What is BYOC Logs?{{< /nextlink >}} + {{< nextlink href="/byoc-logs/introduction/" >}}What is {{< prodname >}}BYOC Logs{{< /prodname >}}?{{< /nextlink >}} {{< nextlink href="/byoc-logs/quickstart/" >}}Quickstart: Run BYOC Logs locally in 5 minutes{{< /nextlink >}} {{< nextlink href="/byoc-logs/install/" >}}Installation - Deploy BYOC Logs on AWS, GCP, or Azure{{< /nextlink >}} - {{< nextlink href="/byoc-logs/ingest/agent/" >}}Ingest Logs - Configure the Datadog Agent to send logs to BYOC Logs{{< /nextlink >}} + {{< nextlink href="/byoc-logs/ingest/agent/" >}}Ingest Logs - Configure the Datadog Agent to send logs to {{< prodname >}}BYOC Logs{{< /prodname >}}{{< /nextlink >}} {{< nextlink href="/byoc-logs/operate/search_logs" >}}Search Logs - Explore your logs in the Datadog Log Explorer{{< /nextlink >}} - {{< nextlink href="/byoc-logs/guides/" >}}Guides - Step-by-step guides for BYOC Logs features and integrations{{< /nextlink >}} + {{< nextlink href="/byoc-logs/guides/" >}}Guides - Step-by-step guides for {{< prodname >}}BYOC Logs{{< /prodname >}} features and integrations{{< /nextlink >}} {{< /whatsnext >}} ## Further reading diff --git a/hugo/content/en/byoc-logs/configure/_index.md b/hugo/content/en/byoc-logs/configure/_index.md index 4425d76cb21..8136d9dee86 100644 --- a/hugo/content/en/byoc-logs/configure/_index.md +++ b/hugo/content/en/byoc-logs/configure/_index.md @@ -14,9 +14,9 @@ aliases: ## Overview -After installing BYOC (Bring Your Own Cloud) Logs, you can configure your deployment to meet your environment, security, and performance requirements. Key configuration areas include account integration, cloud resource setup, cluster sizing, ingress, and processing options. These settings allow you to tailor BYOC Logs for your specific needs. +After installing BYOC (Bring Your Own Cloud) Logs, you can configure your deployment to meet your environment, security, and performance requirements. Key configuration areas include account integration, cloud resource setup, cluster sizing, ingress, and processing options. These settings allow you to tailor {{< prodname >}}BYOC Logs{{< /prodname >}} for your specific needs. -If you don't see the BYOC Logs entry in the Logs menu, it means BYOC Logs is not activated on your account. Contact your Datadog account team to activate BYOC Logs on your account. +If you don't see the {{< prodname >}}BYOC Logs{{< /prodname >}} entry in the Logs menu, it means {{< prodname >}}BYOC Logs{{< /prodname >}} is not activated on your account. Contact your Datadog account team to activate {{< prodname >}}BYOC Logs{{< /prodname >}} on your account. {{< whatsnext desc="Customize your BYOC Logs deployment:">}} {{< nextlink href="/byoc-logs/configure/indexes/" >}}Configure indexes{{< /nextlink >}} diff --git a/hugo/content/en/byoc-logs/configure/indexes.md b/hugo/content/en/byoc-logs/configure/indexes.md index ef2d39174ec..1076a361b3e 100644 --- a/hugo/content/en/byoc-logs/configure/indexes.md +++ b/hugo/content/en/byoc-logs/configure/indexes.md @@ -15,13 +15,13 @@ further_reading: By default, a BYOC (Bring Your Own Cloud) Logs cluster stores all logs in a single index with a single retention policy. With multiple indexes, you can segment logs by defining filter queries and assigning a different retention period to each index. For example, you can retain audit logs for 1 year while keeping debug logs for only 3 days. -To view and manage your BYOC Logs indexes, navigate to the [BYOC Logs page][1] in Datadog. Select a cluster and click {{< ui >}}View Indexes{{< /ui >}} to access the index configuration. +To view and manage your {{< prodname >}}BYOC Logs{{< /prodname >}} indexes, navigate to the [BYOC Logs page][1] in Datadog. Select a cluster and click {{< ui >}}View Indexes{{< /ui >}} to access the index configuration. {{< img src="cloudprem/indexes/indexes_configuration.png" alt="BYOC Logs indexes configuration page showing three indexes with filters and retention periods" style="width:80%;">}} ## Indexes filters -When a log is ingested, BYOC Logs evaluates each index's filter from top to bottom and routes the log to the **first matching index**. This means index order matters: +When a log is ingested, {{< prodname >}}BYOC Logs{{< /prodname >}} evaluates each index's filter from top to bottom and routes the log to the **first matching index**. This means index order matters: - Place indexes with more specific filters above indexes with broader filters. For example, `source:security env:production` should appear above `source:security`. - A catch-all index with a `*` filter at the bottom ensures that no logs are dropped. @@ -33,11 +33,11 @@ You can reorder indexes at any time by dragging rows or using the {{< ui >}}Move Each index has its own retention period, which determines how long logs are stored before automatic deletion. -
If you are upgrading from a previous BYOC Logs version, the index retention configured through the Datadog UI takes precedence over the global retention set in the Helm chart values.
+
If you are upgrading from a previous {{< prodname >}}BYOC Logs{{< /prodname >}} version, the index retention configured through the Datadog UI takes precedence over the global retention set in the Helm chart values.
## Searching across indexes -To query logs stored in BYOC Logs, select one or more BYOC Logs indexes in the [Log Explorer][2]. You can select a specific index to narrow your search, or select all indexes in a cluster to search across them. From the index configuration page, use {{< ui >}}View in Log Explorer{{< /ui >}} to open a filtered view for a given index. +To query logs stored in {{< prodname >}}BYOC Logs{{< /prodname >}}, select one or more {{< prodname >}}BYOC Logs{{< /prodname >}} indexes in the [Log Explorer][2]. You can select a specific index to narrow your search, or select all indexes in a cluster to search across them. From the index configuration page, use {{< ui >}}View in Log Explorer{{< /ui >}} to open a filtered view for a given index. For more information, see [Search BYOC Logs][3]. diff --git a/hugo/content/en/byoc-logs/configure/ingress.md b/hugo/content/en/byoc-logs/configure/ingress.md index 4f8ca110b8d..83f20b8731d 100644 --- a/hugo/content/en/byoc-logs/configure/ingress.md +++ b/hugo/content/en/byoc-logs/configure/ingress.md @@ -18,23 +18,23 @@ Ingress is a critical component of your BYOC (Bring Your Own Cloud) Logs deploym ## Public ingress -
Only the BYOC Logs gRPC API endpoints (paths starting with /cloudprem) perform mutual TLS authentication. Exposing any other endpoints through the public ingress introduces a security risk, as those endpoints would be accessible over the internet without authentication. Always restrict non-gRPC endpoints to the internal ingress.
+
Only the {{< prodname >}}BYOC Logs{{< /prodname >}} gRPC API endpoints (paths starting with /cloudprem) perform mutual TLS authentication. Exposing any other endpoints through the public ingress introduces a security risk, as those endpoints would be accessible over the internet without authentication. Always restrict non-gRPC endpoints to the internal ingress.
-The public ingress is essential for enabling Datadog's control plane and query service to manage and query BYOC Logs clusters over the public internet. It provides secure access to the BYOC Logs gRPC API through the following mechanisms: +The public ingress is essential for enabling Datadog's control plane and query service to manage and query {{< prodname >}}BYOC Logs{{< /prodname >}} clusters over the public internet. It provides secure access to the {{< prodname >}}BYOC Logs{{< /prodname >}} gRPC API through the following mechanisms: - Creates an internet-facing AWS Application Load Balancer (ALB) that accepts traffic from Datadog services - Implements TLS encryption with termination at the load balancer level -- Uses HTTP/2 (gRPC) for communication between the ALB and BYOC Logs cluster +- Uses HTTP/2 (gRPC) for communication between the ALB and {{< prodname >}}BYOC Logs{{< /prodname >}} cluster - Requires mutual TLS (mTLS) authentication where Datadog services must present valid client certificates -- Configures the ALB in TLS passthrough mode to forward client certificates to BYOC Logs pods with the `X-Amzn-Mtls-Clientcert` header +- Configures the ALB in TLS passthrough mode to forward client certificates to {{< prodname >}}BYOC Logs{{< /prodname >}} pods with the `X-Amzn-Mtls-Clientcert` header - Rejects requests that are missing valid client certificates or the certificate header -This setup ensures that only authenticated Datadog services can access the BYOC Logs cluster while maintaining secure encrypted communication end-to-end. +This setup ensures that only authenticated Datadog services can access the {{< prodname >}}BYOC Logs{{< /prodname >}} cluster while maintaining secure encrypted communication end-to-end. {{< img src="/cloudprem/ingress/cloudprem_public_ingress1.png" alt="Diagram showing BYOC Logs public ingress architecture with Datadog services connecting through an internet-facing AWS ALB using mTLS authentication to access the BYOC Logs gRPC API" style="width:100%;" >}} ### IP Allowlisting -The Datadog control plane and query services connect to BYOC Logs clusters using a set of fixed IP ranges, which can be retrieved for each Datadog site from the Datadog [IP Ranges API][1], specifically under the "webhooks" section. For example, to fetch the IP ranges for the datadoghq.eu site, you can run: +The Datadog control plane and query services connect to {{< prodname >}}BYOC Logs{{< /prodname >}} clusters using a set of fixed IP ranges, which can be retrieved for each Datadog site from the Datadog [IP Ranges API][1], specifically under the "webhooks" section. For example, to fetch the IP ranges for the datadoghq.eu site, you can run: ``` curl -X GET "https://ip-ranges.datadoghq.eu/" \ -H "Accept: application/json" | @@ -47,7 +47,7 @@ The internal ingress enables log ingestion from Datadog Agents and other log col {{< img src="/cloudprem/ingress/internal_ingress.png" alt=" Internal ingress with ALB provisioned by Helm chart" style="width:100%;" >}} -By default, the chart creates an internal AWS Application Load Balancer (ALB) to route HTTP traffic to the appropriate BYOC Logs services based on the requested API endpoint path. However, if you prefer to use your own ingress controller (such as HAProxy, NGINX, or Traefik), you can disable the default internal ALB and configure your controller with the following routing rules: +By default, the chart creates an internal AWS Application Load Balancer (ALB) to route HTTP traffic to the appropriate {{< prodname >}}BYOC Logs{{< /prodname >}} services based on the requested API endpoint path. However, if you prefer to use your own ingress controller (such as HAProxy, NGINX, or Traefik), you can disable the default internal ALB and configure your controller with the following routing rules: ``` rules: diff --git a/hugo/content/en/byoc-logs/configure/lambda.md b/hugo/content/en/byoc-logs/configure/lambda.md index 9013dfcba19..644767d54bc 100644 --- a/hugo/content/en/byoc-logs/configure/lambda.md +++ b/hugo/content/en/byoc-logs/configure/lambda.md @@ -19,24 +19,24 @@ aliases: ## Overview BYOC (Bring Your Own Cloud) Logs can offload leaf search operations to AWS Lambda for horizontal scaling. When the local search queue becomes saturated, overflow splits are automatically sent to Lambda functions for processing. -This allows BYOC Logs to handle traffic spikes without provisioning additional searcher nodes. +This allows {{< prodname >}}BYOC Logs{{< /prodname >}} to handle traffic spikes without provisioning additional searcher nodes. ## Startup validation -When a Lambda configuration is defined, BYOC Logs performs a dry run invocation at startup to verify that: +When a Lambda configuration is defined, {{< prodname >}}BYOC Logs{{< /prodname >}} performs a dry run invocation at startup to verify that: - The Lambda function exists -- The function version matches the running BYOC Logs binary +- The function version matches the running {{< prodname >}}BYOC Logs{{< /prodname >}} binary - The invoker has permission to call the function ## Prerequisite: IAM permissions Lambda search offloading requires specific permissions for two separate IAM roles: -- **The BYOC Logs node role**: the role attached to the Kubernetes nodes (or pod identity) running BYOC Logs. The role is defined in the `serviceAccount` section of your `values.yaml`. This role needs permissions to invoke and deploy the Lambda function. +- **The BYOC Logs node role**: the role attached to the Kubernetes nodes (or pod identity) running {{< prodname >}}BYOC Logs{{< /prodname >}}. The role is defined in the `serviceAccount` section of your `values.yaml`. This role needs permissions to invoke and deploy the Lambda function. - **The Lambda execution role**: the role assumed by the Lambda function itself at runtime. This role needs read access to your index data in S3. Its ARN must be set in the `config.searcher.lambda.auto_deploy.execution_role_arn` key. For more details, see the [Configuration](#configuration) section. ### BYOC Logs node permissions -The IAM role running BYOC Logs needs the following permissions to invoke and deploy the Lambda function: +The IAM role running {{< prodname >}}BYOC Logs{{< /prodname >}} needs the following permissions to invoke and deploy the Lambda function: ```json { @@ -127,7 +127,7 @@ Optionally, to capture Lambda logs in CloudWatch, add the following permissions ## Configuration -
The Lambda configuration must be valid for the BYOC Logs searcher to start.
+
The Lambda configuration must be valid for the {{< prodname >}}BYOC Logs{{< /prodname >}} searcher to start.
After setting up the [IAM permissions](#prerequisite-iam-permissions), add a `lambda` section under `config.searcher` in your Helm chart values file to enable Lambda offloading: diff --git a/hugo/content/en/byoc-logs/configure/metastore_read_replicas.md b/hugo/content/en/byoc-logs/configure/metastore_read_replicas.md index 05c9480161d..7412a6501d6 100644 --- a/hugo/content/en/byoc-logs/configure/metastore_read_replicas.md +++ b/hugo/content/en/byoc-logs/configure/metastore_read_replicas.md @@ -25,7 +25,7 @@ Prepare one or more read replica instances of your metastore PostgreSQL database ## Create a Kubernetes secret for the read replica -The read-only metastore requires an environment variable named `QW_METASTORE_READ_REPLICA_URI`. Set it to the connection URI for your read replica instance(s), similar to `QW_METASTORE_URI` for the primary metastore. Store this URI in a Kubernetes secret in your BYOC Logs namespace: +The read-only metastore requires an environment variable named `QW_METASTORE_READ_REPLICA_URI`. Set it to the connection URI for your read replica instance(s), similar to `QW_METASTORE_URI` for the primary metastore. Store this URI in a Kubernetes secret in your {{< prodname >}}BYOC Logs{{< /prodname >}} namespace: ```shell kubectl create secret generic byoclogs-metastore-read-replica-uri \ diff --git a/hugo/content/en/byoc-logs/configure/pipelines.md b/hugo/content/en/byoc-logs/configure/pipelines.md index 4caae6ad6dc..062de39d395 100644 --- a/hugo/content/en/byoc-logs/configure/pipelines.md +++ b/hugo/content/en/byoc-logs/configure/pipelines.md @@ -17,7 +17,7 @@ further_reading: BYOC (Bring Your Own Cloud) Logs includes a processing feature that allows you to parse and enrich logs. It automatically parses logs formatted in JSON. You can define pipelines and processors to extract meaningful information or attributes from semi-structured text, which can then be used for aggregations. -
BYOC Logs pipelines and processors are designed to match the capabilities of Datadog's cloud-based log pipelines and processors.
+
{{< prodname >}}BYOC Logs{{< /prodname >}} pipelines and processors are designed to match the capabilities of Datadog's cloud-based log pipelines and processors.
For a list of supported and unsupported processors, see [Compatibility with cloud-based pipelines](#compatibility-with-cloud-based-pipelines). @@ -34,7 +34,7 @@ You can configure log processing pipelines using a JSON file that adheres to the -H "DD-APPLICATION-KEY: ${DD_APP_KEY}" > pipelines-config.json ``` -This JSON file can be used directly with BYOC Logs. +This JSON file can be used directly with {{< prodname >}}BYOC Logs{{< /prodname >}}. 2. To set the configuration in the Helm Chart, provide the path to your JSON configuration file using the `pipelinesConfig` parameter in the BYOC Logs Helm chart: @@ -43,7 +43,7 @@ This JSON file can be used directly with BYOC Logs. helm upgrade -n --set-file pipelinesConfig=./pipelines-config.json -f datadog-values.yaml ``` - BYOC Logs records an informational message (`Successfully read pipeline config file`) when it successfully reads the configuration file. Any processors defined in the file that are not supported by BYOC Logs are ignored during startup. + {{< prodname >}}BYOC Logs{{< /prodname >}} records an informational message (`Successfully read pipeline config file`) when it successfully reads the configuration file. Any processors defined in the file that are not supported by {{< prodname >}}BYOC Logs{{< /prodname >}} are ignored during startup. **Note**: Helm imposes a 1 MB size limit on the configuration file due to its underlying etcd storage. ## Configuration file format @@ -103,10 +103,10 @@ The order of elements in the array defines the sequential execution order of the ## Compatibility with cloud-based pipelines -BYOC Logs processing is designed to align closely with cloud-based [Datadog Log Management][3], allowing direct use of existing log pipeline configurations. It achieves this by ignoring unknown or unsupported processors. However, some differences exist: +{{< prodname >}}BYOC Logs{{< /prodname >}} processing is designed to align closely with cloud-based [Datadog Log Management][3], allowing direct use of existing log pipeline configurations. It achieves this by ignoring unknown or unsupported processors. However, some differences exist: - Some filter queries can't be parsed, such as filters with combined wildcards (for example, `@data.message:+*`). - Filter on `message` has a different matching behavior (it also affects the category processor). -- BYOC Logs uses a regex to grep the word, but it should tokenize the text and try to match the tokens. Phrases are also ignored. +- {{< prodname >}}BYOC Logs{{< /prodname >}} uses a regex to grep the word, but it should tokenize the text and try to match the tokens. Phrases are also ignored. - Groks use regular expressions internally. The regex engines may have slightly different matching behavior. - Some grok patterns can't be parsed (for example, `%{?>notSpace:db.severity}`). diff --git a/hugo/content/en/byoc-logs/guides/_index.md b/hugo/content/en/byoc-logs/guides/_index.md index 217d874ad80..d54d14b1d5a 100644 --- a/hugo/content/en/byoc-logs/guides/_index.md +++ b/hugo/content/en/byoc-logs/guides/_index.md @@ -18,6 +18,6 @@ aliases: {{< whatsnext desc="Explore the following guides:">}} - {{< nextlink href="/byoc-logs/guides/query_logs_with_mcp/" >}}Query BYOC Logs with the Datadog MCP Server{{< /nextlink >}} - {{< nextlink href="/byoc-logs/guides/send_otel_logs_observability_pipelines/" >}}Send OpenTelemetry Logs to BYOC Logs through Observability Pipelines{{< /nextlink >}} + {{< nextlink href="/byoc-logs/guides/query_logs_with_mcp/" >}}Query BYOC Logs with the {{< prodname >}}Datadog MCP Server{{< /prodname >}}{{< /nextlink >}} + {{< nextlink href="/byoc-logs/guides/send_otel_logs_observability_pipelines/" >}}Send OpenTelemetry Logs to {{< prodname >}}BYOC Logs{{< /prodname >}} through {{< prodname >}}Observability Pipelines{{< /prodname >}}{{< /nextlink >}} {{< /whatsnext >}} \ No newline at end of file diff --git a/hugo/content/en/byoc-logs/guides/query_logs_with_mcp.md b/hugo/content/en/byoc-logs/guides/query_logs_with_mcp.md index 88a99dfcc9f..e1554cfe8cc 100644 --- a/hugo/content/en/byoc-logs/guides/query_logs_with_mcp.md +++ b/hugo/content/en/byoc-logs/guides/query_logs_with_mcp.md @@ -19,17 +19,17 @@ aliases: Use the `search_datadog_logs` tool on the [Datadog MCP (Model Context Protocol) server][1] to query logs stored in BYOC (Bring Your Own Cloud) Logs indexes. You can access the tool through AI-powered tools and integrations. -**Note**: BYOC Logs indexes are supported only by `search_datadog_logs`. The `analyze_datadog_logs` tool and the `datadog/querying-patterns` skill do not support BYOC Logs indexes. +**Note**: {{< prodname >}}BYOC Logs{{< /prodname >}} indexes are supported only by `search_datadog_logs`. The `analyze_datadog_logs` tool and the `datadog/querying-patterns` skill do not support {{< prodname >}}BYOC Logs{{< /prodname >}} indexes. ## Prerequisites -- A running BYOC Logs deployment with logs ingested. +- A running {{< prodname >}}BYOC Logs{{< /prodname >}} deployment with logs ingested. - Access to the [Datadog MCP server][1]. - Your BYOC Logs index name (visible in the [Datadog Log Explorer][2] under {{< ui >}}BYOC INDEXES{{< /ui >}}). ## Querying BYOC Logs -To query logs stored in BYOC Logs indexes, use `search_datadog_logs` and specify your BYOC Logs index name in addition to your standard log query. +To query logs stored in {{< prodname >}}BYOC Logs{{< /prodname >}} indexes, use `search_datadog_logs` and specify your {{< prodname >}}BYOC Logs{{< /prodname >}} index name in addition to your standard log query. For best results, your prompt **should also include**: - (Recommended) Time range (for example, "in the last hour", "from the last 24 hours"). @@ -50,7 +50,7 @@ For examples of parameter and natural language queries, see [Advanced query exam ### Finding your BYOC Logs index name -To find your BYOC Logs index name: +To find your {{< prodname >}}BYOC Logs{{< /prodname >}} index name: 1. Navigate to the [Datadog Log Explorer][2]. 2. Look for the {{< ui >}}BYOC INDEXES{{< /ui >}} section in the left facet panel. @@ -60,7 +60,7 @@ You can also find your index names in the [BYOC Logs console][3] by selecting a ## Advanced query examples -When using AI-powered tools with `search_datadog_logs`, you can ask questions in natural language. The tool translates these into properly formatted BYOC Logs queries. +When using AI-powered tools with `search_datadog_logs`, you can ask questions in natural language. The tool translates these into properly formatted {{< prodname >}}BYOC Logs{{< /prodname >}} queries. ### Error logs from a specific service **Prompt**: @@ -106,9 +106,9 @@ When using AI-powered tools with `search_datadog_logs`, you can ask questions in ## Important notes -- The `indexes` parameter must contain valid BYOC Logs index names (in the format `byoc----`). -- When using natural language queries, explicitly mention your BYOC Logs index name in your prompt. -- BYOC Logs data is queryable in real-time as soon as it is indexed. +- The `indexes` parameter must contain valid {{< prodname >}}BYOC Logs{{< /prodname >}} index names (in the format `byoc----`). +- When using natural language queries, explicitly mention your {{< prodname >}}BYOC Logs{{< /prodname >}} index name in your prompt. +- {{< prodname >}}BYOC Logs{{< /prodname >}} data is queryable in real-time as soon as it is indexed. - Query syntax follows standard [Datadog log search syntax][4]. ## Further reading diff --git a/hugo/content/en/byoc-logs/guides/send_otel_logs_observability_pipelines.md b/hugo/content/en/byoc-logs/guides/send_otel_logs_observability_pipelines.md index 6757ab7c2cb..0d031bf98c3 100644 --- a/hugo/content/en/byoc-logs/guides/send_otel_logs_observability_pipelines.md +++ b/hugo/content/en/byoc-logs/guides/send_otel_logs_observability_pipelines.md @@ -17,7 +17,7 @@ aliases: ## Overview -BYOC (Bring Your Own Cloud) Logs supports log ingestion from OTEL collectors by using Observability Pipelines as the ingestion layer. This guide provides step-by-step instructions to connect OTEL logs to BYOC Logs—without disrupting your existing OTEL configuration. +BYOC (Bring Your Own Cloud) Logs supports log ingestion from OTEL collectors by using {{< prodname >}}Observability Pipelines{{< /prodname >}} as the ingestion layer. This guide provides step-by-step instructions to connect OTEL logs to {{< prodname >}}BYOC Logs{{< /prodname >}}—without disrupting your existing OTEL configuration. By the end of this guide, you will be able to: 1. [Start BYOC Logs locally](#step-1-start-byoc-logs). @@ -28,7 +28,7 @@ By the end of this guide, you will be able to: ## Prerequisites -- BYOC Logs access. Contact your Datadog account team to request access. +- {{< prodname >}}BYOC Logs{{< /prodname >}} access. Contact your Datadog account team to request access. - **Datadog API Key**: [Get your API key][2]. - **Datadog Application Key**: [Get your application key][3]. - **Docker**: [Install Docker][4]. @@ -36,7 +36,7 @@ By the end of this guide, you will be able to: ## Step 1: Start BYOC Logs -Start a local BYOC Logs instance. Replace `` with your Datadog API Key: +Start a local {{< prodname >}}BYOC Logs{{< /prodname >}} instance. Replace `` with your Datadog API Key: ```shell export DD_API_KEY="" @@ -53,7 +53,7 @@ docker run -d \ ## Step 2: Create an Observability Pipeline with the API -Create a pipeline with an OpenTelemetry source, a filter processor, and a BYOC Logs destination. Replace `` with your Datadog Application Key: +Create a pipeline with an OpenTelemetry source, a filter processor, and a {{< prodname >}}BYOC Logs{{< /prodname >}} destination. Replace `` with your Datadog Application Key: ```shell export DD_APP_KEY="" @@ -139,7 +139,7 @@ docker run -d \ **Notes**: - The Worker exposes port 4318 for HTTP and 4317 for gRPC. -- On macOS/Windows, use `host.docker.internal` to connect to BYOC Logs on the host machine. +- On macOS/Windows, use `host.docker.internal` to connect to {{< prodname >}}BYOC Logs{{< /prodname >}} on the host machine. - On Linux, use `--network host` instead of `-p` flags and `http://localhost:7280` for the endpoint. {{< img src="/cloudprem/guides/otel-op-cloudprem/op-config.png" alt="The Observability Pipelines configuration" style="width:100%;" >}} @@ -201,7 +201,7 @@ docker logs opw --tail 20 ## Step 5: View logs in Datadog 1. Go to the [Datadog Log Explorer][5]. -2. In the left facet panel, select your BYOC Logs index under {{< ui >}}BYOC INDEXES{{< /ui >}}. +2. In the left facet panel, select your {{< prodname >}}BYOC Logs{{< /prodname >}} index under {{< ui >}}BYOC INDEXES{{< /ui >}}. 3. You should see your OpenTelemetry logs from the `otel-demo` service with custom tags: `pipeline:observability-pipelines` and `source:opentelemetry`. {{< img src="/cloudprem/guides/otel-op-cloudprem/cloudprem_logs.png" alt="BYOC Logs data available in the Datadog Log Explorer" style="width:100%;" >}} diff --git a/hugo/content/en/byoc-logs/ingest/_index.md b/hugo/content/en/byoc-logs/ingest/_index.md index ba7916535bc..e8d4092e2e7 100644 --- a/hugo/content/en/byoc-logs/ingest/_index.md +++ b/hugo/content/en/byoc-logs/ingest/_index.md @@ -7,11 +7,11 @@ aliases: ## Overview -After installing and configuring BYOC (Bring Your Own Cloud) Logs, you need to set up log ingestion to start sending log data from your applications and infrastructure. BYOC Logs supports multiple ingestion methods to accommodate different architectures and requirements. +After installing and configuring BYOC (Bring Your Own Cloud) Logs, you need to set up log ingestion to start sending log data from your applications and infrastructure. {{< prodname >}}BYOC Logs{{< /prodname >}} supports multiple ingestion methods to accommodate different architectures and requirements. ## Supported log format -BYOC Logs accepts logs as **JSON objects** sent to the `/api/v2/logs` endpoint. Each request body must be a JSON array of log objects: +{{< prodname >}}BYOC Logs{{< /prodname >}} accepts logs as **JSON objects** sent to the `/api/v2/logs` endpoint. Each request body must be a JSON array of log objects: ```json [ @@ -21,14 +21,14 @@ BYOC Logs accepts logs as **JSON objects** sent to the `/api/v2/logs` endpoint. ```
-NDJSON (newline-delimited JSON) is not supported. If your log source sends one JSON object per line without array wrapping, use Observability Pipelines to reformat the payload before sending to BYOC Logs. +NDJSON (newline-delimited JSON) is not supported. If your log source sends one JSON object per line without array wrapping, use {{< prodname >}}Observability Pipelines{{< /prodname >}} to reformat the payload before sending to {{< prodname >}}BYOC Logs{{< /prodname >}}.
## Log ingestion methods {{< whatsnext desc="Choose the appropriate ingestion method based on your infrastructure and requirements:">}} {{< nextlink href="/byoc-logs/ingest/agent/" >}}Datadog Agent{{< /nextlink >}} - {{< nextlink href="/byoc-logs/ingest/observability_pipelines/" >}}Observability Pipelines{{< /nextlink >}} + {{< nextlink href="/byoc-logs/ingest/observability_pipelines/" >}}{{< prodname >}}Observability Pipelines{{< /prodname >}}{{< /nextlink >}} {{< nextlink href="/byoc-logs/ingest/api/" >}}REST API Integration{{< /nextlink >}} {{< /whatsnext >}} @@ -36,7 +36,7 @@ BYOC Logs accepts logs as **JSON objects** sent to the `/api/v2/logs` endpoint. ### Datadog Lambda Forwarder -The [Datadog Lambda Forwarder][1] can send AWS CloudWatch Logs to BYOC Logs by setting the `DD_URL` environment variable to your BYOC Logs endpoint: +The [Datadog Lambda Forwarder][1] can send AWS CloudWatch Logs to {{< prodname >}}BYOC Logs{{< /prodname >}} by setting the `DD_URL` environment variable to your {{< prodname >}}BYOC Logs{{< /prodname >}} endpoint: ``` DD_URL= @@ -44,11 +44,11 @@ DD_URL= The forwarder sends logs to `https://:443/api/v2/logs`. -**Note:** API key validation (`/api/v1/validate`) is sent to Datadog SaaS (controlled by `DD_API_URL`), not to BYOC Logs. This means you need a valid Datadog API key even when forwarding to BYOC Logs. +**Note:** API key validation (`/api/v1/validate`) is sent to Datadog SaaS (controlled by `DD_API_URL`), not to {{< prodname >}}BYOC Logs{{< /prodname >}}. This means you need a valid Datadog API key even when forwarding to {{< prodname >}}BYOC Logs{{< /prodname >}}. ### OpenTelemetry -BYOC Logs can receive logs from OpenTelemetry collectors through Observability Pipelines. See [Send OTel logs to BYOC Logs with Observability Pipelines][2] for setup instructions. +{{< prodname >}}BYOC Logs{{< /prodname >}} can receive logs from OpenTelemetry collectors through {{< prodname >}}Observability Pipelines{{< /prodname >}}. See [Send OTel logs to BYOC Logs with Observability Pipelines][2] for setup instructions. [1]: /serverless/libraries_integrations/forwarder/ [2]: /byoc-logs/guides/send_otel_logs_observability_pipelines/ diff --git a/hugo/content/en/byoc-logs/ingest/agent.md b/hugo/content/en/byoc-logs/ingest/agent.md index bdc82ad9835..78925d0df0f 100644 --- a/hugo/content/en/byoc-logs/ingest/agent.md +++ b/hugo/content/en/byoc-logs/ingest/agent.md @@ -17,20 +17,20 @@ further_reading: --- ## Overview -This document provides configuration steps for using the Datadog Agent to send logs to a Datadog BYOC (Bring Your Own Cloud) Logs deployment. Unlike the Datadog SaaS platform, BYOC Logs requires specific Agent configurations to ensure logs are enriched with necessary host-level tags and sent to the correct endpoint. This guide covers how to set these configurations for the most common deployment methods. +This document provides configuration steps for using the Datadog Agent to send logs to a Datadog BYOC (Bring Your Own Cloud) Logs deployment. Unlike the Datadog SaaS platform, {{< prodname >}}BYOC Logs{{< /prodname >}} requires specific Agent configurations to ensure logs are enriched with necessary host-level tags and sent to the correct endpoint. This guide covers how to set these configurations for the most common deployment methods. ## Key requirements -To send logs with the Datadog Agent to BYOC Logs, you must configure two environment variables: +To send logs with the Datadog Agent to {{< prodname >}}BYOC Logs{{< /prodname >}}, you must configure two environment variables: `DD_LOGS_CONFIG_LOGS_DD_URL` -: Set this to your BYOC Logs indexer endpoint, usually `http://-indexer..svc.cluster.local:7280`. This tells the Agent where to send the logs +: Set this to your {{< prodname >}}BYOC Logs{{< /prodname >}} indexer endpoint, usually `http://-indexer..svc.cluster.local:7280`. This tells the Agent where to send the logs `DD_LOGS_CONFIG_EXPECTED_TAGS_DURATION` -: (Optional) This is an optional but highly recommended variable. Set it to a large value, like "100000" (approximately 5 years). This ensures the Agent adds host-level tags to every log it sends. The Datadog SaaS platform automatically enriches logs with these tags after ingestion, but BYOC Logs requires the Agent to add them upfront. +: (Optional) This is an optional but highly recommended variable. Set it to a large value, like "100000" (approximately 5 years). This ensures the Agent adds host-level tags to every log it sends. The Datadog SaaS platform automatically enriches logs with these tags after ingestion, but {{< prodname >}}BYOC Logs{{< /prodname >}} requires the Agent to add them upfront. ### Proxy -If you have configured the Datadog Agent to use a proxy and BYOC Logs is hosted in your internal network, you need to configure the `no_proxy` setting so the Agent can send logs directly to BYOC Logs without passing through the proxy. +If you have configured the Datadog Agent to use a proxy and {{< prodname >}}BYOC Logs{{< /prodname >}} is hosted in your internal network, you need to configure the `no_proxy` setting so the Agent can send logs directly to {{< prodname >}}BYOC Logs{{< /prodname >}} without passing through the proxy. ```yaml # In the no_proxy section, add the BYOC Logs DNS @@ -85,7 +85,7 @@ spec: ### Endpoint configuration -The Datadog Agent can be configured to send logs to BYOC Logs using different endpoints: +The Datadog Agent can be configured to send logs to {{< prodname >}}BYOC Logs{{< /prodname >}} using different endpoints: {{% collapse-content title="Internal cluster endpoint" level="h4" expanded=false %}} Recommended for in-cluster agents: @@ -187,7 +187,7 @@ kubectl logs | grep -i cloudprem ### Check logs are indexed in BYOC Logs -Run this command to query the BYOC Logs searcher and verify that it's indexing the JSON logs. +Run this command to query the {{< prodname >}}BYOC Logs{{< /prodname >}} searcher and verify that it's indexing the JSON logs. ```shell kubectl exec -it -searcher-0 -n -- curl 'http://localhost:7280/api/v1/datadog/search?query=' @@ -202,7 +202,7 @@ kubectl exec -it -searcher-0 -n -- curl 'http://l **BYOC Logs not receiving logs**: - Check BYOC Logs indexer logs: `kubectl logs -n -l app=-indexer` -- Verify network connectivity between Agent and BYOC Logs indexer +- Verify network connectivity between Agent and {{< prodname >}}BYOC Logs{{< /prodname >}} indexer - Confirm BYOC Logs service is running: `kubectl get pods -n ` ## Further reading diff --git a/hugo/content/en/byoc-logs/ingest/api.md b/hugo/content/en/byoc-logs/ingest/api.md index a1d773c9684..f300c78755c 100644 --- a/hugo/content/en/byoc-logs/ingest/api.md +++ b/hugo/content/en/byoc-logs/ingest/api.md @@ -15,7 +15,7 @@ further_reading: ## Overview -You can send logs to BYOC (Bring Your Own Cloud) Logs using direct REST API calls. This method is useful for custom integrations or scripts that can't use a Datadog Agent or Observability Pipelines. +You can send logs to BYOC (Bring Your Own Cloud) Logs using direct REST API calls. This method is useful for custom integrations or scripts that can't use a Datadog Agent or {{< prodname >}}Observability Pipelines{{< /prodname >}}. ## Datadog Logs API diff --git a/hugo/content/en/byoc-logs/ingest/observability_pipelines.md b/hugo/content/en/byoc-logs/ingest/observability_pipelines.md index ffbe314fdd0..5a81de9fd44 100644 --- a/hugo/content/en/byoc-logs/ingest/observability_pipelines.md +++ b/hugo/content/en/byoc-logs/ingest/observability_pipelines.md @@ -21,19 +21,19 @@ further_reading: ## Overview -Observability Pipelines provides a flexible intermediary layer between your Datadog Agents and BYOC (Bring Your Own Cloud) Logs, allowing you to process, transform, and route logs before they reach your BYOC Logs deployment. Configure Observability Pipelines to receive logs from the Datadog Agent and forward them to BYOC Logs: +{{< prodname >}}Observability Pipelines{{< /prodname >}} provides a flexible intermediary layer between your Datadog Agents and BYOC (Bring Your Own Cloud) Logs, allowing you to process, transform, and route logs before they reach your {{< prodname >}}BYOC Logs{{< /prodname >}} deployment. Configure Observability Pipelines to receive logs from the Datadog Agent and forward them to {{< prodname >}}BYOC Logs{{< /prodname >}}: 1. [**Create and configure the pipeline**](#create-and-configure-an-observability-pipeline) - Define your pipeline configuration (source, processors, destination) in the Observability Pipelines UI. This creates the pipeline definition that will be used by the Worker. 2. [**Deploy the Observability Pipelines Worker**](##deploy-your-observability-pipelines) - Install the Worker with your pipeline configuration. The Worker must be running and listening for logs before the Agent can connect to it. 3. [**Configure the Datadog Agent**](#configure-the-datadog-agent) - Point the Agent to send logs to the deployed Worker. This step must come last because the Agent needs the Worker's address to be available. ## Create and configure an Observability Pipeline -1. Navigate to [Observability Pipelines][1]. +1. Navigate to [{{< prodname >}}Observability Pipelines{{< /prodname >}}][1]. 1. Select the [**Log Volume Control template**][2]. 1. Set up your pipeline: 1. Choose the [**Datadog Agent** source][3]. 1. Remove any default processors from the pipeline. - 1. Select the [**Datadog BYOC Logs** destination][4] to forward logs to your BYOC Logs instance. Leave the configuration empty. + 1. Select the [**Datadog BYOC Logs** destination][4] to forward logs to your {{< prodname >}}BYOC Logs{{< /prodname >}} instance. Leave the configuration empty. @@ -43,7 +43,7 @@ Observability Pipelines provides a flexible intermediary layer between your Data After creating your pipeline in the UI, deploy the Observability Pipelines Worker. The Worker runs your pipeline configuration and listens for logs from the Datadog Agent. -The following Helm command installs or upgrades the Worker, configuring it to listen for logs and forward them to your BYOC Logs indexer. +The following Helm command installs or upgrades the Worker, configuring it to listen for logs and forward them to your {{< prodname >}}BYOC Logs{{< /prodname >}} indexer.
**Note**: You need the `pipelineId` from the pipeline you created in the previous step. This ID links the Worker to your pipeline configuration. @@ -58,13 +58,13 @@ helm upgrade --install opw \ datadog/observability-pipelines-worker ``` -After a minute, verify that logs are flowing through the pipeline and reaching the BYOC Logs destination. This indicates that the Worker is running and ready to receive logs, and you can proceed to configure the Agent. +After a minute, verify that logs are flowing through the pipeline and reaching the {{< prodname >}}BYOC Logs{{< /prodname >}} destination. This indicates that the Worker is running and ready to receive logs, and you can proceed to configure the Agent. ## Configure the Datadog Agent After the Observability Pipelines Worker is deployed and running, configure your Datadog Agent to send logs to it. The Agent connects to the Worker using the Worker's service address. For more information, see [Connect the Datadog Agent to the Observability Pipelines Worker][5]. -Update your Datadog Agent configuration to send logs to the Observability Pipelines worker: +Update your Datadog Agent configuration to send logs to the {{< prodname >}}Observability Pipelines{{< /prodname >}} worker: ```yaml apiVersion: datadoghq.com/v2alpha1 diff --git a/hugo/content/en/byoc-logs/install/_index.md b/hugo/content/en/byoc-logs/install/_index.md index 0fe84487965..d21b77ceb8d 100644 --- a/hugo/content/en/byoc-logs/install/_index.md +++ b/hugo/content/en/byoc-logs/install/_index.md @@ -10,13 +10,13 @@ aliases: BYOC (Bring Your Own Cloud) Logs requires **Kubernetes** for production deployments. It is supported on Amazon EKS, Google GKE, and Azure AKS. A [Docker installation][2] is also available for local evaluation and testing only.
-Docker is for evaluation only. The Docker installation method is designed for exploring BYOC Logs features locally. For production workloads, deploy on a supported Kubernetes platform. +Docker is for evaluation only. The Docker installation method is designed for exploring {{< prodname >}}BYOC Logs{{< /prodname >}} features locally. For production workloads, deploy on a supported Kubernetes platform.
## Prerequisites
-If you don't see the BYOC Logs entry in the Logs menu, contact your Datadog account team to activate BYOC Logs on your account. +If you don't see the {{< prodname >}}BYOC Logs{{< /prodname >}} entry in the Logs menu, contact your Datadog account team to activate {{< prodname >}}BYOC Logs{{< /prodname >}} on your account.
### Kubernetes cluster requirements @@ -29,7 +29,7 @@ If you don't see the BYOC Logs entry in the Logs menu, contact your Datadog acco | **Recommended PostgreSQL Options** | - AWS: RDS PostgreSQL
- GCP: Cloud SQL for PostgreSQL
- Azure: Azure Database for PostgreSQL
- Self-hosted: PostgreSQL with persistent storage | ### Object storage -BYOC Logs supports the following object storage types: +{{< prodname >}}BYOC Logs{{< /prodname >}} supports the following object storage types: - Amazon S3 - Google Cloud Storage (GCS) - Azure Blob Storage diff --git a/hugo/content/en/byoc-logs/install/aws_eks.md b/hugo/content/en/byoc-logs/install/aws_eks.md index 5228eec331d..6c37adf21f8 100644 --- a/hugo/content/en/byoc-logs/install/aws_eks.md +++ b/hugo/content/en/byoc-logs/install/aws_eks.md @@ -19,7 +19,7 @@ This document walks you through the process of configuring your AWS environment ## Prerequisites -To deploy BYOC Logs on AWS, you must configure: +To deploy {{< prodname >}}BYOC Logs{{< /prodname >}} on AWS, you must configure: - AWS credentials and authentication. - AWS region selection. - IAM permissions for S3 object storage. @@ -30,7 +30,7 @@ To deploy BYOC Logs on AWS, you must configure: ### AWS credentials -When starting a node, BYOC Logs uses the default credential provider chain from the [AWS SDK for Rust][4] to find AWS credentials in this order: +When starting a node, {{< prodname >}}BYOC Logs{{< /prodname >}} uses the default credential provider chain from the [AWS SDK for Rust][4] to find AWS credentials in this order: 1. Environment variables `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY`, with `AWS_SESSION_TOKEN` as an optional addition for temporary credentials. 2. Credential profiles file, typically located at `~/.aws/credentials` or otherwise specified by the `AWS_SHARED_CREDENTIALS_FILE` and `AWS_PROFILE` environment variables if set and not empty. @@ -42,14 +42,14 @@ An error is returned if no credentials are found in the chain. ### AWS Region -BYOC Logs attempts to find the AWS region from multiple sources, using the following order of precedence: +{{< prodname >}}BYOC Logs{{< /prodname >}} attempts to find the AWS region from multiple sources, using the following order of precedence: 1. **Environment variables**: Checks `AWS_REGION`, then `AWS_DEFAULT_REGION`. 2. **AWS config file**: Typically located at `~/.aws/config`, or at the path specified by the `AWS_CONFIG_FILE` environment variable (if set and not empty). 3. **EC2 instance metadata**: Uses the region of the currently running Amazon EC2 instance. 4. **Default**: Falls back to `us-east-1` if no other source provides a region. -
The resolved AWS region must match the region of the S3 bucket used for BYOC Logs storage.
+
The resolved AWS region must match the region of the S3 bucket used for {{< prodname >}}BYOC Logs{{< /prodname >}} storage.
### IAM access for S3 @@ -206,7 +206,7 @@ echo ""

The storageClass (sc) used in the example file below is gp3, which is not installed by default and is not the default sc for EKS. To create the gp3 storage class, follow the instructions in this AWS guide. If you do not want to set gp3 as the default (and migrate from gp2), set storageclass.kubernetes.io/is-default-class: "false".

-

Datadog recommends gp3 storage volumes for BYOC Logs to provide the IOPS and throughput flexibility to support higher indexing rates.

+

Datadog recommends gp3 storage volumes for {{< prodname >}}BYOC Logs{{< /prodname >}} to provide the IOPS and throughput flexibility to support higher indexing rates.

Any parameters not explicitly overridden in `datadog-values.yaml` fall back to the defaults defined [in the chart's `values.yaml`][6]. @@ -326,7 +326,7 @@ echo "" ### Check deployment status -Verify that all BYOC Logs components are running: +Verify that all {{< prodname >}}BYOC Logs{{< /prodname >}} components are running: ```shell kubectl get pods -n @@ -336,7 +336,7 @@ kubectl get services -n ## Uninstall -To uninstall BYOC Logs: +To uninstall {{< prodname >}}BYOC Logs{{< /prodname >}}: ```shell helm uninstall \ @@ -345,7 +345,7 @@ helm uninstall \ ## Next step -**[Set up log ingestion with Datadog Agent][7]** - Configure the Datadog Agent to send logs to BYOC Logs +**[Set up log ingestion with Datadog Agent][7]** - Configure the Datadog Agent to send logs to {{< prodname >}}BYOC Logs{{< /prodname >}} ## Further reading diff --git a/hugo/content/en/byoc-logs/install/azure_aks.md b/hugo/content/en/byoc-logs/install/azure_aks.md index af52b97b765..b52fb0f1924 100644 --- a/hugo/content/en/byoc-logs/install/azure_aks.md +++ b/hugo/content/en/byoc-logs/install/azure_aks.md @@ -12,21 +12,21 @@ This document walks you through the process of configuring your Azure environmen ## Prerequisites -Before you install BYOC Logs on Azure, you must set up a set of supporting infrastructure resources. These components provide the foundational compute, storage, database, and networking services that BYOC Logs depends on. +Before you install {{< prodname >}}BYOC Logs{{< /prodname >}} on Azure, you must set up a set of supporting infrastructure resources. These components provide the foundational compute, storage, database, and networking services that {{< prodname >}}BYOC Logs{{< /prodname >}} depends on. ### Infrastructure Requirements Here are the components you must provision: -- [**Azure Kubernetes Service (AKS)**](#azure-kubernetes-service-aks): A running AKS cluster sized for your expected BYOC Logs workload. -- [**PostgreSQL Flexible Server**](#azure-postgresql-flexible-server): An Azure Database for PostgreSQL instance that BYOC Logs will use to store its metadata. -- [**Blob Storage container**](#blob-storage-container): An Azure Storage container to store BYOC Logs data. +- [**Azure Kubernetes Service (AKS)**](#azure-kubernetes-service-aks): A running AKS cluster sized for your expected {{< prodname >}}BYOC Logs{{< /prodname >}} workload. +- [**PostgreSQL Flexible Server**](#azure-postgresql-flexible-server): An Azure Database for PostgreSQL instance that {{< prodname >}}BYOC Logs{{< /prodname >}} will use to store its metadata. +- [**Blob Storage container**](#blob-storage-container): An Azure Storage container to store {{< prodname >}}BYOC Logs{{< /prodname >}} data. - [**Client Identity and permissions**](#client-identity-and-permissions): An Azure AD application with read/write access to the storage container. -- [**NGINX Ingress Controller**](#nginx-ingress-controller): Installed on the AKS cluster to route external traffic to BYOC Logs services. -- **Datadog Agent**: Deployed on the AKS cluster to collect and send logs to BYOC Logs. +- [**NGINX Ingress Controller**](#nginx-ingress-controller): Installed on the AKS cluster to route external traffic to {{< prodname >}}BYOC Logs{{< /prodname >}} services. +- **Datadog Agent**: Deployed on the AKS cluster to collect and send logs to {{< prodname >}}BYOC Logs{{< /prodname >}}. ### Azure Kubernetes Service (AKS) -BYOC Logs runs entirely on Kubernetes. You need an AKS cluster with sufficient CPU, memory, and disk space configured for your workload. See the Kubernetes cluster sizing recommendations for guidance. +{{< prodname >}}BYOC Logs{{< /prodname >}} runs entirely on Kubernetes. You need an AKS cluster with sufficient CPU, memory, and disk space configured for your workload. See the Kubernetes cluster sizing recommendations for guidance. #### Deploy the AKS cluster @@ -41,7 +41,7 @@ kubectl get nodes -o wide ### Azure PostgreSQL Flexible Server -BYOC Logs stores its metadata and configuration in a PostgreSQL database. Datadog recommends the Azure Database for PostgreSQL Flexible Server. It must be reachable from the AKS cluster, ideally with private networking enabled. See the Postgres sizing recommendations for details. +{{< prodname >}}BYOC Logs{{< /prodname >}} stores its metadata and configuration in a PostgreSQL database. Datadog recommends the Azure Database for PostgreSQL Flexible Server. It must be reachable from the AKS cluster, ideally with private networking enabled. See the Postgres sizing recommendations for details. #### Create the PostgreSQL database @@ -50,7 +50,7 @@ BYOC Logs stores its metadata and configuration in a PostgreSQL database. Datado #### Verify database connectivity -
For security, create a dedicated database and user for BYOC Logs, and grant the user rights only on that database, not cluster-wide.
+
For security, create a dedicated database and user for {{< prodname >}}BYOC Logs{{< /prodname >}}, and grant the user rights only on that database, not cluster-wide.
Connect to your PostgreSQL database from within the AKS network using the PostgreSQL client, `psql`. First, start an interactive pod in your Kubernetes cluster using an image that includes `psql`: ```shell @@ -82,7 +82,7 @@ Type "help" for help. ### Blob Storage Container -BYOC Logs uses Azure Blob Storage to persist logs. Create a dedicated container for this purpose. +{{< prodname >}}BYOC Logs{{< /prodname >}} uses Azure Blob Storage to persist logs. Create a dedicated container for this purpose. #### Create a Blob Storage container Use a dedicated container per environment (for example, `byoc-logs-prod`, `byoc-logs-staging`), and assign least-privilege RBAC roles at the container level, rather than at the storage account scope. @@ -92,7 +92,7 @@ Use a dedicated container per environment (for example, `byoc-logs-prod`, `byoc- ### Client Identity and permissions -An Azure AD application must be granted read/write access to the Blob Storage container. Register a dedicated application for BYOC Logs and assign the corresponding service principal the `Contributor` role on the Blob Storage container created above. +An Azure AD application must be granted read/write access to the Blob Storage container. Register a dedicated application for {{< prodname >}}BYOC Logs{{< /prodname >}} and assign the corresponding service principal the `Contributor` role on the Blob Storage container created above. #### Register the application [Register an application in Microsoft Entra ID][8] @@ -104,12 +104,12 @@ An Azure AD application must be granted read/write access to the Blob Storage co #### Public NGINX Ingress Controller -The public ingress is essential for enabling Datadog's control plane and query service to manage and query BYOC Logs clusters over the public internet. It provides secure access to the BYOC Logs gRPC API through the following mechanisms: +The public ingress is essential for enabling Datadog's control plane and query service to manage and query {{< prodname >}}BYOC Logs{{< /prodname >}} clusters over the public internet. It provides secure access to the {{< prodname >}}BYOC Logs{{< /prodname >}} gRPC API through the following mechanisms: - Creates an internet-facing Azure Load Balancer that accepts traffic from Datadog services - Implements TLS encryption with termination at the ingress controller level -- Uses HTTP/2 (gRPC) for communication between Datadog and BYOC Logs clusters +- Uses HTTP/2 (gRPC) for communication between Datadog and {{< prodname >}}BYOC Logs{{< /prodname >}} clusters - Requires mutual TLS (mTLS) authentication where Datadog services must present valid client certificates -- Configures the controller in TLS passthrough mode to forward client certificates to BYOC Logs pods with the `ssl-client-cert` header +- Configures the controller in TLS passthrough mode to forward client certificates to {{< prodname >}}BYOC Logs{{< /prodname >}} pods with the `ssl-client-cert` header - Rejects requests that are missing valid client certificates or the certificate header Use the following `nginx-public.yaml` Helm values file in order to create the public NGINX Ingress Controller: @@ -374,7 +374,7 @@ indexer: ### Check deployment status -Verify that all BYOC Logs components are running: +Verify that all {{< prodname >}}BYOC Logs{{< /prodname >}} components are running: ```shell kubectl get pods -n @@ -384,7 +384,7 @@ kubectl get services -n ## Uninstall -To uninstall BYOC Logs, execute the following command: +To uninstall {{< prodname >}}BYOC Logs{{< /prodname >}}, execute the following command: ```shell helm uninstall @@ -392,7 +392,7 @@ helm uninstall ## Next step -**[Set up log ingestion with Datadog Agent][10]** - Configure the Datadog Agent to send logs to BYOC Logs +**[Set up log ingestion with Datadog Agent][10]** - Configure the Datadog Agent to send logs to {{< prodname >}}BYOC Logs{{< /prodname >}} [2]: https://learn.microsoft.com/en-us/azure/aks/learn/quick-kubernetes-deploy-cli [3]: https://learn.microsoft.com/en-us/azure/aks/learn/quick-kubernetes-deploy-terraform?pivots=development-environment-azure-cli diff --git a/hugo/content/en/byoc-logs/install/custom_k8s.md b/hugo/content/en/byoc-logs/install/custom_k8s.md index 105e22e23b3..a5ebbe6bba2 100644 --- a/hugo/content/en/byoc-logs/install/custom_k8s.md +++ b/hugo/content/en/byoc-logs/install/custom_k8s.md @@ -43,7 +43,7 @@ Before you begin, confirm you have: kubectl get nodes ``` -- A **Datadog account** with the BYOC Logs feature enabled +- A **Datadog account** with the {{< prodname >}}BYOC Logs{{< /prodname >}} feature enabled - A **[Datadog API key][1]** @@ -55,7 +55,7 @@ Before you begin, confirm you have: - Password - A **MinIO instance** accessible from your Kubernetes cluster, with: - - A bucket created for BYOC Logs data (for example, `byoc-logs`) + - A bucket created for {{< prodname >}}BYOC Logs{{< /prodname >}} data (for example, `byoc-logs`) - An access key and secret key with read/write permissions on the bucket - The MinIO endpoint URL (for example, `http://minio.minio.svc.cluster.local:9000`) @@ -263,7 +263,7 @@ janitor: ### Check deployment status -Verify that all BYOC Logs components are running: +Verify that all {{< prodname >}}BYOC Logs{{< /prodname >}} components are running: ```shell kubectl get pods -n @@ -302,7 +302,7 @@ kubectl logs -n -l app.kubernetes.io/component=indexer --tail=5 ## Uninstall -To uninstall BYOC Logs: +To uninstall {{< prodname >}}BYOC Logs{{< /prodname >}}: ```shell helm uninstall -n @@ -316,7 +316,7 @@ kubectl delete namespace ## Next step -**[Set up log ingestion with Datadog Agent][2]** - Configure the Datadog Agent to send logs to BYOC Logs +**[Set up log ingestion with Datadog Agent][2]** - Configure the Datadog Agent to send logs to {{< prodname >}}BYOC Logs{{< /prodname >}} ## Further reading diff --git a/hugo/content/en/byoc-logs/install/docker.md b/hugo/content/en/byoc-logs/install/docker.md index cfdc22b4069..6071dac018c 100644 --- a/hugo/content/en/byoc-logs/install/docker.md +++ b/hugo/content/en/byoc-logs/install/docker.md @@ -16,16 +16,16 @@ aliases: ## Overview
-This installation method is for local evaluation only. Docker is not supported for production deployments. For production workloads, deploy BYOC Logs on a supported Kubernetes platform (EKS, GKE, or AKS). +This installation method is for local evaluation only. Docker is not supported for production deployments. For production workloads, deploy {{< prodname >}}BYOC Logs{{< /prodname >}} on a supported Kubernetes platform (EKS, GKE, or AKS).
-This installation guide shows you how to run Datadog BYOC (Bring Your Own Cloud) Logs locally using either standalone Docker containers or Docker Compose. Follow these steps to deploy a minimal BYOC Logs environment on your machine, ideal for exploring BYOC Logs features and testing log ingestion with Datadog. +This installation guide shows you how to run Datadog BYOC (Bring Your Own Cloud) Logs locally using either standalone Docker containers or Docker Compose. Follow these steps to deploy a minimal {{< prodname >}}BYOC Logs{{< /prodname >}} environment on your machine, ideal for exploring {{< prodname >}}BYOC Logs{{< /prodname >}} features and testing log ingestion with Datadog. ## Prerequisites -Before getting started with BYOC Logs, ensure you have: +Before getting started with {{< prodname >}}BYOC Logs{{< /prodname >}}, ensure you have: -- A **Datadog account** with the BYOC Logs feature enabled. +- A **Datadog account** with the {{< prodname >}}BYOC Logs{{< /prodname >}} feature enabled. - **API credentials**: Have your [Datadog API key][2] ready. - **Docker**: [Docker][4] installed and running on your machine. - **Docker Compose** (optional): [Docker Compose][5] for a single command line setup. @@ -35,12 +35,12 @@ Before getting started with BYOC Logs, ensure you have: Choose one of the following installation methods: 1. **Standalone Docker containers**: Minimal setup for testing -2. **Docker Compose**: Single command line to run BYOC Logs and Datadog agent +2. **Docker Compose**: Single command line to run {{< prodname >}}BYOC Logs{{< /prodname >}} and Datadog agent {{< tabs >}} {{% tab "Standalone Docker setup" %}} -This method uses individual Docker containers for a minimal BYOC Logs setup. +This method uses individual Docker containers for a minimal {{< prodname >}}BYOC Logs{{< /prodname >}} setup. Export your Datadog credentials as environment variables: @@ -51,7 +51,7 @@ export DD_API_KEY="your_datadog_api_key" ### Step 1: Start BYOC Logs -Create the data directory and start the BYOC Logs container: +Create the data directory and start the {{< prodname >}}BYOC Logs{{< /prodname >}} container: ```shell # Start BYOC Logs @@ -66,7 +66,7 @@ docker run -d \ ### Step 2: Start the Datadog Agent -To collect logs from your local containers and send them to BYOC Logs, start the Datadog Agent: +To collect logs from your local containers and send them to {{< prodname >}}BYOC Logs{{< /prodname >}}, start the Datadog Agent: ```shell docker run \ @@ -89,7 +89,7 @@ docker run \ {{% tab "Docker Compose setup" %}} -This method provides a BYOC Logs setup with the Datadog Agent integration. +This method provides a {{< prodname >}}BYOC Logs{{< /prodname >}} setup with the Datadog Agent integration. ### Step 1: Create the Docker Compose file @@ -155,7 +155,7 @@ docker compose up -d ## Next steps -After starting BYOC Logs with either method, verify that the installation is working correctly: +After starting {{< prodname >}}BYOC Logs{{< /prodname >}} with either method, verify that the installation is working correctly: ### Check BYOC Logs status @@ -169,7 +169,7 @@ You should see a response with version information. ### Send a log -In your terminal, send a "Hello World" log entry directly to your local BYOC Logs instance using the API: +In your terminal, send a "Hello World" log entry directly to your local {{< prodname >}}BYOC Logs{{< /prodname >}} instance using the API: ```shell curl -X POST "http://localhost:7280/api/v2/logs" \ @@ -186,7 +186,7 @@ curl -X POST "http://localhost:7280/api/v2/logs" \ ### Search your local logs from the Log Explorer -Verify that BYOC Logs is running. In the Log Explorer, select your BYOC Logs index to search and analyze your logs. +Verify that {{< prodname >}}BYOC Logs{{< /prodname >}} is running. In the Log Explorer, select your {{< prodname >}}BYOC Logs{{< /prodname >}} index to search and analyze your logs. ## Further reading diff --git a/hugo/content/en/byoc-logs/install/gcp_gke.md b/hugo/content/en/byoc-logs/install/gcp_gke.md index 5479557003c..2ef1b030102 100644 --- a/hugo/content/en/byoc-logs/install/gcp_gke.md +++ b/hugo/content/en/byoc-logs/install/gcp_gke.md @@ -15,8 +15,8 @@ aliases: This installation setup walks you through deploying Datadog BYOC (Bring Your Own Cloud) Logs on Google Kubernetes Engine (GKE). -BYOC Logs on GKE uses the following Google Cloud services: -- **Google Kubernetes Engine (GKE)**: Container orchestration platform for running BYOC Logs components +{{< prodname >}}BYOC Logs{{< /prodname >}} on GKE uses the following Google Cloud services: +- **Google Kubernetes Engine (GKE)**: Container orchestration platform for running {{< prodname >}}BYOC Logs{{< /prodname >}} components - **Cloud Storage (GCS)**: Object storage for telemetry data and indexes - **Cloud SQL for PostgreSQL**: Managed PostgreSQL database for metadata storage - **Workload Identity**: Secure authentication between GKE workloads and Google Cloud services @@ -111,7 +111,7 @@ kubectl get nodes ### Step 3: Create Cloud Storage bucket -Create a GCS bucket for BYOC Logs data storage: +Create a GCS bucket for {{< prodname >}}BYOC Logs{{< /prodname >}} data storage: ```shell export BUCKET_NAME="byoc-logs-data-${PROJECT_ID}" @@ -147,7 +147,7 @@ gcloud sql instances describe byoc-logs-postgres \ # Should output: RUNNABLE ``` -Create the BYOC Logs database: +Create the {{< prodname >}}BYOC Logs{{< /prodname >}} database: ```shell gcloud sql databases create byoc-logs \ --instance=byoc-logs-postgres @@ -177,7 +177,7 @@ gcloud sql instances patch byoc-logs-postgres \ ### Step 5: Configure IAM and Workload Identity -Create a GCP service account for BYOC Logs: +Create a GCP service account for {{< prodname >}}BYOC Logs{{< /prodname >}}: ```shell export SERVICE_ACCOUNT_NAME="byoc-logs-sa" @@ -361,7 +361,7 @@ kubectl apply -f ingress-values.yaml ### Step 9: Install Datadog Agent (Recommended) -Install the Datadog Agent to collect metrics from BYOC Logs components and send them to Datadog. +Install the Datadog Agent to collect metrics from {{< prodname >}}BYOC Logs{{< /prodname >}} components and send them to Datadog. Create a separate namespace for the Datadog Agent: @@ -474,7 +474,7 @@ kubectl logs -n datadog-byoc-logs -l app.kubernetes.io/component=metastore --tai ## Uninstall -To completely remove BYOC Logs: +To completely remove {{< prodname >}}BYOC Logs{{< /prodname >}}: ```shell # Uninstall Helm release @@ -506,16 +506,16 @@ gcloud container clusters delete ${CLUSTER_NAME} \ - **Enable Cloud SQL backups** for disaster recovery. - **Use regional GKE clusters** for high availability. - **Monitor disk usage** on indexer nodes and enable auto-scaling. -- **Set up alerts** in Datadog for BYOC Logs component health. +- **Set up alerts** in Datadog for {{< prodname >}}BYOC Logs{{< /prodname >}} component health. - **Use private GKE clusters** for enhanced security in production. -- **Regularly update** BYOC Logs to the latest version for bug fixes and features. +- **Regularly update** {{< prodname >}}BYOC Logs{{< /prodname >}} to the latest version for bug fixes and features. - **Test scaling** in a staging environment before production changes. - **Store the database password** in Secret Manager and use External Secrets Operator (ESO) or the Secrets Store CSI Driver to provide the password to metastore pods. ## Next steps -- Configure your applications to send telemetry to BYOC Logs -- Set up dashboards in Datadog to monitor BYOC Logs performance +- Configure your applications to send telemetry to {{< prodname >}}BYOC Logs{{< /prodname >}} +- Set up dashboards in Datadog to monitor {{< prodname >}}BYOC Logs{{< /prodname >}} performance - Review BYOC Logs metrics and data in your Datadog account - Plan capacity based on your data volume diff --git a/hugo/content/en/byoc-logs/introduction/_index.md b/hugo/content/en/byoc-logs/introduction/_index.md index 713cfc671d3..7a898098cd7 100644 --- a/hugo/content/en/byoc-logs/introduction/_index.md +++ b/hugo/content/en/byoc-logs/introduction/_index.md @@ -7,24 +7,24 @@ aliases: ## Overview -BYOC (Bring Your Own Cloud) Logs is Datadog's log management solution that runs in your own infrastructure. It indexes and stores logs in your object storage, executes search and analytics queries, and connects to the Datadog UI for a fully integrated experience. BYOC Logs is designed for organizations with specific requirements: +BYOC (Bring Your Own Cloud) Logs is Datadog's log management solution that runs in your own infrastructure. It indexes and stores logs in your object storage, executes search and analytics queries, and connects to the Datadog UI for a fully integrated experience. {{< prodname >}}BYOC Logs{{< /prodname >}} is designed for organizations with specific requirements: - Data residency, privacy, and regulatory requirements - High volume requirements -Here is a high-level overview of how BYOC Logs works: +Here is a high-level overview of how {{< prodname >}}BYOC Logs{{< /prodname >}} works: {{< img src="/cloudprem/overview_diagram_cloudprem.png" alt="BYOC Logs architecture overview showing how logs flow from sources through BYOC Logs to the Datadog platform" style="width:100%;" >}} -The diagram illustrates the BYOC Logs hybrid architecture, highlighting how data is processed and stored within your infrastructure: +The diagram illustrates the {{< prodname >}}BYOC Logs{{< /prodname >}} hybrid architecture, highlighting how data is processed and stored within your infrastructure: * **Ingestion**: Logs are collected from Datadog Agents and other sources using standard protocols. * **Your Infrastructure**: The BYOC Logs platform runs entirely inside your infrastructure. It processes and stores logs in your own object storage (Amazon S3, Google Cloud Storage, or Azure Blob Storage). -* **Datadog SaaS**: The Datadog platform is BYOC Logs' Control Plane. It hosts the Datadog UI and communicates with BYOC Logs through a secure connection to send log queries and receive results. +* **Datadog SaaS**: The Datadog platform is {{< prodname >}}BYOC Logs{{< /prodname >}}' Control Plane. It hosts the Datadog UI and communicates with {{< prodname >}}BYOC Logs{{< /prodname >}} through a secure connection to send log queries and receive results. {{< whatsnext desc="Explore BYOC Logs' architecture and capabilities:">}} - {{< nextlink href="/byoc-logs/introduction/architecture/" >}}Architecture - Understand how BYOC Logs components work together{{< /nextlink >}} - {{< nextlink href="/byoc-logs/introduction/network/" >}}Network - Understand how BYOC Logs communicates with Datadog{{< /nextlink >}} - {{< nextlink href="/byoc-logs/introduction/features/" >}}Supported Features - See which Log Explorer features are available in BYOC Logs{{< /nextlink >}} + {{< nextlink href="/byoc-logs/introduction/architecture/" >}}Architecture - Understand how {{< prodname >}}BYOC Logs{{< /prodname >}} components work together{{< /nextlink >}} + {{< nextlink href="/byoc-logs/introduction/network/" >}}Network - Understand how {{< prodname >}}BYOC Logs{{< /prodname >}} communicates with Datadog{{< /nextlink >}} + {{< nextlink href="/byoc-logs/introduction/features/" >}}Supported Features - See which Log Explorer features are available in {{< prodname >}}BYOC Logs{{< /prodname >}}{{< /nextlink >}} {{< /whatsnext >}} ## Get started @@ -32,5 +32,5 @@ The diagram illustrates the BYOC Logs hybrid architecture, highlighting how data {{< whatsnext desc="Ready to deploy BYOC Logs? Follow these guides:">}} {{< nextlink href="/byoc-logs/quickstart/" >}}Quickstart - Run BYOC Logs locally in 5 minutes{{< /nextlink >}} {{< nextlink href="/byoc-logs/install/" >}}Installation - Deploy BYOC Logs on AWS, GCP, or Azure{{< /nextlink >}} - {{< nextlink href="/byoc-logs/ingest/agent/" >}}Ingest Logs - Configure the Datadog Agent to send logs to BYOC Logs{{< /nextlink >}} + {{< nextlink href="/byoc-logs/ingest/agent/" >}}Ingest Logs - Configure the Datadog Agent to send logs to {{< prodname >}}BYOC Logs{{< /prodname >}}{{< /nextlink >}} {{< /whatsnext >}} diff --git a/hugo/content/en/byoc-logs/introduction/architecture.md b/hugo/content/en/byoc-logs/introduction/architecture.md index 70fc9d3ba55..62248004218 100644 --- a/hugo/content/en/byoc-logs/introduction/architecture.md +++ b/hugo/content/en/byoc-logs/introduction/architecture.md @@ -22,10 +22,10 @@ further_reading: BYOC (Bring Your Own Cloud) Logs consists of two main blocks: -- [**Observability Pipelines**][1] collects, processes, and routes logs. -- The **BYOC Logs engine** indexes, stores, and queries logs. Datadog distributes the engine as the `datadog/cloudprem` Docker image. +- [**{{< prodname >}}Observability Pipelines{{< /prodname >}}**][1] collects, processes, and routes logs. +- The **{{< prodname >}}BYOC Logs{{< /prodname >}} engine** indexes, stores, and queries logs. Datadog distributes the engine as the `datadog/cloudprem` Docker image. -The Observability Pipelines Worker and the BYOC Logs engine process log data in your environment. Datadog hosts the pipeline configuration UI and Log Explorer, and routes queries to the engine. +The Observability Pipelines Worker and the {{< prodname >}}BYOC Logs{{< /prodname >}} engine process log data in your environment. Datadog hosts the pipeline configuration UI and Log Explorer, and routes queries to the engine. The BYOC Logs engine separates compute from object storage. You can scale ingestion, compaction, and search independently based on workload demand while keeping log data in your object storage. @@ -33,14 +33,14 @@ The BYOC Logs engine separates compute from object storage. You can scale ingest ### Observability Pipelines -Observability Pipelines is the ingestion block for BYOC Logs. The Observability Pipelines Worker receives logs from Datadog Agents and other sources, applies the processing rules defined in your pipeline, and routes the processed logs to the BYOC Logs engine. You configure the pipeline in Datadog, and the Worker runs in your environment. +{{< prodname >}}Observability Pipelines{{< /prodname >}} is the ingestion block for {{< prodname >}}BYOC Logs{{< /prodname >}}. The Observability Pipelines Worker receives logs from Datadog Agents and other sources, applies the processing rules defined in your pipeline, and routes the processed logs to the {{< prodname >}}BYOC Logs{{< /prodname >}} engine. You configure the pipeline in Datadog, and the Worker runs in your environment. ### BYOC Logs engine The BYOC Logs engine runs in your environment. In Kubernetes deployments, the `datadog/cloudprem` image runs with different roles: **Indexers** -: Receive processed logs from Observability Pipelines, create index files called *splits*, and write the splits to object storage. +: Receive processed logs from {{< prodname >}}Observability Pipelines{{< /prodname >}}, create index files called *splits*, and write the splits to object storage. **Compactors** : Read splits from object storage, merge them, and write the merged splits back. Compactors run on dedicated nodes to isolate merge work from indexing. @@ -71,7 +71,7 @@ The engine uses two data stores in your environment: Logs remain in your environment throughout ingestion: 1. Applications and other sources send logs to an **Observability Pipelines Worker**. -2. The Worker processes the logs and routes them to the BYOC Logs engine. +2. The Worker processes the logs and routes them to the {{< prodname >}}BYOC Logs{{< /prodname >}} engine. 3. **Indexers** create splits in object storage and register their metadata through the metastore. 4. **Compactors** asynchronously merge splits on dedicated nodes and write the merged splits back to object storage. @@ -79,7 +79,7 @@ Logs remain in your environment throughout ingestion: ### Query path -When you search BYOC Logs data in Log Explorer, the query travels over a secure connection between Datadog and the BYOC Logs engine: +When you search {{< prodname >}}BYOC Logs{{< /prodname >}} data in Log Explorer, the query travels over a secure connection between Datadog and the {{< prodname >}}BYOC Logs{{< /prodname >}} engine: 1. The Datadog UI sends the search query to Datadog's backend. 2. Datadog forwards the query to the engine through a reverse connection or ingress. @@ -90,7 +90,7 @@ When you search BYOC Logs data in Log Explorer, the query travels over a secure ## Connection to Datadog UI -Connect the Datadog UI to the BYOC Logs engine in one of two ways: +Connect the Datadog UI to the {{< prodname >}}BYOC Logs{{< /prodname >}} engine in one of two ways: - **[Reverse connection][2]**: Let the engine initiate a secure connection to Datadog. - **[External requests from Datadog][3]**: Provide Datadog with a DNS endpoint and configure a public ingress to accept requests. diff --git a/hugo/content/en/byoc-logs/introduction/features.md b/hugo/content/en/byoc-logs/introduction/features.md index 7b4124cf7e2..e14df0faf44 100644 --- a/hugo/content/en/byoc-logs/introduction/features.md +++ b/hugo/content/en/byoc-logs/introduction/features.md @@ -25,8 +25,8 @@ Datadog BYOC (Bring Your Own Cloud) Logs brings core Log Explorer capabilities t ### Dashboards and monitors -- Dashboards with BYOC Logs data -- Log monitors on BYOC Logs indexes +- Dashboards with {{< prodname >}}BYOC Logs{{< /prodname >}} data +- Log monitors on {{< prodname >}}BYOC Logs{{< /prodname >}} indexes ### Index management @@ -38,13 +38,13 @@ Datadog BYOC (Bring Your Own Cloud) Logs brings core Log Explorer capabilities t ### Correlation -- Correlation from a log in BYOC Logs to metrics sent to Datadog SaaS -- Correlation from a log in BYOC Logs to traces sent to Datadog SaaS -- Correlation from a log in BYOC Logs to processes sent to Datadog SaaS +- Correlation from a log in {{< prodname >}}BYOC Logs{{< /prodname >}} to metrics sent to Datadog SaaS +- Correlation from a log in {{< prodname >}}BYOC Logs{{< /prodname >}} to traces sent to Datadog SaaS +- Correlation from a log in {{< prodname >}}BYOC Logs{{< /prodname >}} to processes sent to Datadog SaaS ### Processing -- Configurable processing pipelines through Observability Pipelines +- Configurable processing pipelines through {{< prodname >}}Observability Pipelines{{< /prodname >}} - Observability Pipeline connection ### AI features @@ -54,7 +54,7 @@ Datadog BYOC (Bring Your Own Cloud) Logs brings core Log Explorer capabilities t ## Unsupported features -BYOC Logs does not support the following features: +{{< prodname >}}BYOC Logs{{< /prodname >}} does not support the following features: - SIEM - Watchdog diff --git a/hugo/content/en/byoc-logs/introduction/network.md b/hugo/content/en/byoc-logs/introduction/network.md index a9bd8292f89..65ce9897cc1 100644 --- a/hugo/content/en/byoc-logs/introduction/network.md +++ b/hugo/content/en/byoc-logs/introduction/network.md @@ -12,7 +12,7 @@ This document provides an overview of how BYOC (Bring Your Own Cloud) Logs and D ## Reverse connection (default) -By default, BYOC Logs **searcher** pods initiate an outbound WebSocket connection to Datadog using your API key. Each searcher pod maintains its own connection to `wss:///api/unstable/cloudprem-connection-gateway/connect`. +By default, {{< prodname >}}BYOC Logs{{< /prodname >}} **searcher** pods initiate an outbound WebSocket connection to Datadog using your API key. Each searcher pod maintains its own connection to `wss:///api/unstable/cloudprem-connection-gateway/connect`. Datadog recommends this setup because: - **No inbound ports need to be opened** in your network. @@ -31,7 +31,7 @@ Datadog recommends this setup because: Searcher pods require **outbound HTTPS (port 443)** access to your Datadog site (for example, `app.datadoghq.com`). No inbound connectivity is required. -If your environment uses an HTTP proxy, BYOC Logs supports standard proxy configuration with `HTTPS_PROXY`, `ALL_PROXY`, and `NO_PROXY` environment variables. +If your environment uses an HTTP proxy, {{< prodname >}}BYOC Logs{{< /prodname >}} supports standard proxy configuration with `HTTPS_PROXY`, `ALL_PROXY`, and `NO_PROXY` environment variables. ### Which pods connect to Datadog @@ -39,9 +39,9 @@ Only **searcher** pods establish the reverse connection. Indexers, the control p ## Public ingress (optional) -It is also possible to configure BYOC Logs to deploy a public ingress so Datadog can establish the connection in the other direction. +It is also possible to configure {{< prodname >}}BYOC Logs{{< /prodname >}} to deploy a public ingress so Datadog can establish the connection in the other direction. -The public ingress enables Datadog's control plane and query service to manage and query BYOC Logs clusters over the public internet. It provides secure access to the BYOC Logs gRPC API using mTLS authentication. You can find more information about BYOC Logs ingress in its [configuration page](/byoc-logs/configure/ingress/). +The public ingress enables Datadog's control plane and query service to manage and query {{< prodname >}}BYOC Logs{{< /prodname >}} clusters over the public internet. It provides secure access to the {{< prodname >}}BYOC Logs{{< /prodname >}} gRPC API using mTLS authentication. You can find more information about {{< prodname >}}BYOC Logs{{< /prodname >}} ingress in its [configuration page](/byoc-logs/configure/ingress/). ## Further reading diff --git a/hugo/content/en/byoc-logs/operate/best_practices.md b/hugo/content/en/byoc-logs/operate/best_practices.md index 4e20b3d6b4b..e589073d978 100644 --- a/hugo/content/en/byoc-logs/operate/best_practices.md +++ b/hugo/content/en/byoc-logs/operate/best_practices.md @@ -19,10 +19,10 @@ This page outlines operational best practices for running BYOC (Bring Your Own C ## Enable monitoring from the start -Set up BYOC Logs monitoring before sending production traffic. Without monitoring, diagnosing ingestion or search issues is difficult. +Set up {{< prodname >}}BYOC Logs{{< /prodname >}} monitoring before sending production traffic. Without monitoring, diagnosing ingestion or search issues is difficult. -1. Deploy the Datadog Agent (or standalone DogStatsD) in the same cluster as BYOC Logs. -2. Verify that BYOC Logs metrics appear in the [out-of-the-box dashboard][1]. +1. Deploy the Datadog Agent (or standalone DogStatsD) in the same cluster as {{< prodname >}}BYOC Logs{{< /prodname >}}. +2. Verify that {{< prodname >}}BYOC Logs{{< /prodname >}} metrics appear in the [out-of-the-box dashboard][1]. 3. Confirm that key metrics are reporting: `indexed_events.count`, `search_requests.count`, `disk.available_space.gauge`. See [Monitor BYOC Logs][2] for detailed setup instructions. @@ -65,7 +65,7 @@ indexer: ## Enable automated backups on your metastore database -BYOC Logs stores metadata in a PostgreSQL database (Amazon RDS, Cloud SQL, or Azure Database for PostgreSQL, depending on your cloud provider). Enable automated backups on this database for disaster recovery. +{{< prodname >}}BYOC Logs{{< /prodname >}} stores metadata in a PostgreSQL database (Amazon RDS, Cloud SQL, or Azure Database for PostgreSQL, depending on your cloud provider). Enable automated backups on this database for disaster recovery. For example, on AWS, set a nonzero `--backup-retention-period` when you create the RDS instance. See [Create an RDS database][5] for an example command. @@ -89,7 +89,7 @@ If you observe search timeouts or slow dashboard loads, adjust capacity: ## Use Lambda search offloading on AWS -On AWS, BYOC Logs can offload leaf search operations to AWS Lambda. Instead of provisioning searcher pods for peak query load, Lambda handles overflow automatically. +On AWS, {{< prodname >}}BYOC Logs{{< /prodname >}} can offload leaf search operations to AWS Lambda. Instead of provisioning searcher pods for peak query load, Lambda handles overflow automatically. This is useful when: - Your query load has significant peaks (for example, during incidents or business hours) @@ -100,7 +100,7 @@ With Lambda offloading enabled, you can run fewer searcher pods sized for your b ## Keep your Helm chart version up to date -BYOC Logs improvements and bug fixes are delivered through Helm chart updates. +{{< prodname >}}BYOC Logs{{< /prodname >}} improvements and bug fixes are delivered through Helm chart updates. Refresh the Datadog repository and upgrade to the latest chart version with your existing values file: diff --git a/hugo/content/en/byoc-logs/operate/disk_buffer_durability.md b/hugo/content/en/byoc-logs/operate/disk_buffer_durability.md index c1d281b9dd0..d992a2018e1 100644 --- a/hugo/content/en/byoc-logs/operate/disk_buffer_durability.md +++ b/hugo/content/en/byoc-logs/operate/disk_buffer_durability.md @@ -22,27 +22,27 @@ further_reading: ## Overview -BYOC Logs combines Observability Pipelines with the BYOC Logs engine. Observability Pipelines Workers can store logs in persistent disk buffers when the BYOC Logs engine is unavailable or cannot keep up with the incoming rate. This gives the ingestion path time to recover without immediately dropping logs. +{{< prodname >}}BYOC Logs{{< /prodname >}} combines {{< prodname >}}Observability Pipelines{{< /prodname >}} with the {{< prodname >}}BYOC Logs{{< /prodname >}} engine. Observability Pipelines Workers can store logs in persistent disk buffers when the {{< prodname >}}BYOC Logs{{< /prodname >}} engine is unavailable or cannot keep up with the incoming rate. This gives the ingestion path time to recover without immediately dropping logs. A durable setup has four parts: - Enough buffer capacity for the backlog you want to retain -- Disk buffering on the BYOC Logs destination +- Disk buffering on the {{< prodname >}}BYOC Logs{{< /prodname >}} destination - A persistent volume for each Worker's buffer - Enough time for a terminating Worker to drain its buffer ## Before you begin -This guide assumes that you have a BYOC Logs deployment with: +This guide assumes that you have a {{< prodname >}}BYOC Logs{{< /prodname >}} deployment with: -- Observability Pipelines configured with a [BYOC Logs destination][1] +- {{< prodname >}}Observability Pipelines{{< /prodname >}} configured with a [BYOC Logs destination][1] - A [BYOC Logs engine deployment][2] ## Size the disk buffer -A useful starting point is to decide how long Workers need to retain logs if the BYOC Logs engine is unavailable. The expected backlog can then be divided across the minimum number of Workers that remain active. +A useful starting point is to decide how long Workers need to retain logs if the {{< prodname >}}BYOC Logs{{< /prodname >}} engine is unavailable. The expected backlog can then be divided across the minimum number of Workers that remain active. -For example, consider a total ingress of 50 TB/day, 25 Workers, and a one-hour BYOC Logs engine outage: +For example, consider a total ingress of 50 TB/day, 25 Workers, and a one-hour {{< prodname >}}BYOC Logs{{< /prodname >}} engine outage: 1. **Total backlog:** `50 TB × 1 hour ÷ 24 hours = 2.08 TB` 2. **Buffer per Worker:** `2.08 TB ÷ 25 Workers ≈ 83 GB` @@ -51,7 +51,7 @@ Rounding up the result leaves capacity for a longer incident or a higher ingress ## Disk buffer configuration -The following buffering options are available when editing the BYOC Logs destination in the Observability Pipelines UI or through the API: +The following buffering options are available when editing the {{< prodname >}}BYOC Logs{{< /prodname >}} destination in the Observability Pipelines UI or through the API: - **Buffer type**: Disk - **Buffer size**: The per-Worker capacity from your calculation @@ -89,7 +89,7 @@ The persistent volume keeps buffered logs if a Worker pod restarts. The `Retain` ## Draining Workers before shutdown -During a scale-down or rollout, a Worker stops accepting new logs and sends its buffered logs to the BYOC Logs engine. If the Worker exits before the buffer is empty, the logs remain on its persistent volume until a replacement Worker reattaches that volume. +During a scale-down or rollout, a Worker stops accepting new logs and sends its buffered logs to the {{< prodname >}}BYOC Logs{{< /prodname >}} engine. If the Worker exits before the buffer is empty, the logs remain on its persistent volume until a replacement Worker reattaches that volume. The `terminationGracePeriodSeconds` setting controls how long Kubernetes waits before terminating the pod. This gives the Worker time to empty its buffer before exiting. diff --git a/hugo/content/en/byoc-logs/operate/monitoring.md b/hugo/content/en/byoc-logs/operate/monitoring.md index 734a68d08fd..48630ff107e 100644 --- a/hugo/content/en/byoc-logs/operate/monitoring.md +++ b/hugo/content/en/byoc-logs/operate/monitoring.md @@ -7,7 +7,7 @@ aliases: ## Dashboards -BYOC (Bring Your Own Cloud) Logs provides an out-of-the-box dashboard that monitors BYOC Logs' key metrics. +BYOC (Bring Your Own Cloud) Logs provides an out-of-the-box dashboard that monitors {{< prodname >}}BYOC Logs{{< /prodname >}}' key metrics. ### Setup @@ -16,7 +16,7 @@ These metrics are exported by [DogStatsD][1]. You can either: - Run DogStatsD as a standalone service, or - Run the Datadog Agent (which includes DogStatsD by default) -Configure either option with your organization's API key to export these metrics. As soon as your BYOC Logs cluster is connected to Datadog, the OOTB dashboard is automatically created, and you can access it from your [Dashboards list][2]. +Configure either option with your organization's API key to export these metrics. As soon as your {{< prodname >}}BYOC Logs{{< /prodname >}} cluster is connected to Datadog, the OOTB dashboard is automatically created, and you can access it from your [Dashboards list][2].
To display distribution metrics on your dashboard, you must enable advanced query functionality.
diff --git a/hugo/content/en/byoc-logs/operate/search_logs.md b/hugo/content/en/byoc-logs/operate/search_logs.md index fff326dad3c..69149b62de1 100644 --- a/hugo/content/en/byoc-logs/operate/search_logs.md +++ b/hugo/content/en/byoc-logs/operate/search_logs.md @@ -30,7 +30,7 @@ byoc---- ## Search limitations -You cannot query BYOC Logs indexes alongside other Datadog log indexes. Additionally, Flex Logs are not supported with BYOC Logs. +You cannot query {{< prodname >}}BYOC Logs{{< /prodname >}} indexes alongside other Datadog log indexes. Additionally, Flex Logs are not supported with {{< prodname >}}BYOC Logs{{< /prodname >}}. [1]: https://app.datadoghq.com/logs diff --git a/hugo/content/en/byoc-logs/operate/sizing.md b/hugo/content/en/byoc-logs/operate/sizing.md index ab45a36fc05..a5a09521e70 100644 --- a/hugo/content/en/byoc-logs/operate/sizing.md +++ b/hugo/content/en/byoc-logs/operate/sizing.md @@ -104,7 +104,7 @@ Allocate the following resources for these lightweight components: ## Object storage estimation -BYOC Logs compresses and indexes log data before storing it in object storage. The compression ratio depends on the log format, structure, and redundancy in your data. +{{< prodname >}}BYOC Logs{{< /prodname >}} compresses and indexes log data before storing it in object storage. The compression ratio depends on the log format, structure, and redundancy in your data. | Metric | Typical range | |--------|---------------| @@ -123,7 +123,7 @@ Assuming a 6x compression ratio: 1. **Stored per day:** `10 TB / 6 ≈ 1.67 TB/day` 2. **Total for 30 days:** `1.67 TB × 30 ≈ 50 TB` -Use standard-tier object storage (for example, S3 Standard, GCS Standard) for active data. Lower-cost tiers such as S3 Infrequent Access or GCS Nearline are not validated for use with BYOC Logs. +Use standard-tier object storage (for example, S3 Standard, GCS Standard) for active data. Lower-cost tiers such as S3 Infrequent Access or GCS Nearline are not validated for use with {{< prodname >}}BYOC Logs{{< /prodname >}}. {{% /collapse-content %}} ## PostgreSQL database diff --git a/hugo/content/en/byoc-logs/operate/troubleshooting.md b/hugo/content/en/byoc-logs/operate/troubleshooting.md index c4d7a6ad3aa..6a7f3cb3155 100644 --- a/hugo/content/en/byoc-logs/operate/troubleshooting.md +++ b/hugo/content/en/byoc-logs/operate/troubleshooting.md @@ -33,7 +33,7 @@ kubectl describe pod -n datadog-byoc-logs ## Access permissions -The most common errors come from access permissions to the object storage or to the metastore. To troubleshoot, use `kubectl` and verify logs from BYOC Logs components: indexer pods, metastore pods, and searcher pods. +The most common errors come from access permissions to the object storage or to the metastore. To troubleshoot, use `kubectl` and verify logs from {{< prodname >}}BYOC Logs{{< /prodname >}} components: indexer pods, metastore pods, and searcher pods. ## Metastore errors @@ -72,7 +72,7 @@ postgresql://user:abc/def+ghi=@host:5432/byoc-logs ERROR quickwit: command failed error=metastore error `index `datadog` not found` ``` -The cluster eventually crashes, and the BYOC Logs console shows multiple clusters where you expect one. +The cluster eventually crashes, and the {{< prodname >}}BYOC Logs{{< /prodname >}} console shows multiple clusters where you expect one. **Cause:** The metastore URI is not set correctly, so the metastore falls back to a local file-backed store. Each time the metastore pod restarts, the file is wiped and a fresh metastore is created—all index metadata is lost. An earlier error in the logs often points to the misconfiguration: @@ -109,11 +109,11 @@ Action: Check if your pod has access to the bucket. - **Indexers undersized:** Check CPU utilization and the `pending_merge_ops.gauge` metric. If merge operations are backing up, indexers need more CPU or additional pods. - **Disk full:** Check `disk.available_space.gauge`. If the write-ahead log (WAL) fills up, indexers stop accepting new data. Increase persistent volume size or add more indexer pods. -In case you use Observability Pipelines in front of BYOC Logs, you will need to check what's happening there, see OP [Scaling and Performance][2]. +In case you use {{< prodname >}}Observability Pipelines{{< /prodname >}} in front of {{< prodname >}}BYOC Logs{{< /prodname >}}, you will need to check what's happening there, see OP [Scaling and Performance][2]. ### Occasional 429 (Too Many Requests) errors -A low rate of 429 errors is not a problem in itself. The Datadog Agent or Observability Pipelines buffers payloads and retries the request automatically. +A low rate of 429 errors is not a problem in itself. The Datadog Agent or {{< prodname >}}Observability Pipelines{{< /prodname >}} buffers payloads and retries the request automatically. 429s usually mean the cluster is temporarily short on shards. Common triggers: diff --git a/hugo/content/en/byoc-logs/operate/updates.md b/hugo/content/en/byoc-logs/operate/updates.md index 980fee59c1a..99a26824049 100644 --- a/hugo/content/en/byoc-logs/operate/updates.md +++ b/hugo/content/en/byoc-logs/operate/updates.md @@ -19,11 +19,11 @@ BYOC (Bring Your Own Cloud) Logs includes two customer-deployed components: - The BYOC Logs engine, distributed through the `datadog/cloudprem` Helm chart - The Observability Pipelines Worker (OPW) -The components are versioned independently. Each BYOC Logs release is a validated version pair, consisting of one version of each component and its corresponding Helm chart. Datadog recommends deploying this version pair; other combinations are not validated as a BYOC Logs release. +The components are versioned independently. Each BYOC Logs release is a validated version pair, consisting of one version of each component and its corresponding Helm chart. Datadog recommends deploying this version pair; other combinations are not validated as a {{< prodname >}}BYOC Logs{{< /prodname >}} release. ## Release cadence -Datadog publishes at least one BYOC Logs engine release per month. Releases may occur more frequently, and patch releases are published as needed. Each engine release includes a corresponding Helm chart and release notes. +Datadog publishes at least one {{< prodname >}}BYOC Logs{{< /prodname >}} engine release per month. Releases may occur more frequently, and patch releases are published as needed. Each engine release includes a corresponding Helm chart and release notes. A BYOC Logs release is published when the engine changes or when Datadog adds an OPW update to the validated pair. One component can remain unchanged between releases. diff --git a/hugo/content/en/byoc-logs/quickstart.md b/hugo/content/en/byoc-logs/quickstart.md index a7eb53e1dd0..bb2da3259b0 100644 --- a/hugo/content/en/byoc-logs/quickstart.md +++ b/hugo/content/en/byoc-logs/quickstart.md @@ -22,13 +22,13 @@ Get started with BYOC (Bring Your Own Cloud) Logs locally in less than 5 minutes ## Prerequisites -- Access to BYOC Logs. Contact your Datadog account team to request access. +- Access to {{< prodname >}}BYOC Logs{{< /prodname >}}. Contact your Datadog account team to request access. - **Datadog API Key**: [Get your API key][2]. - **Docker**: [Install Docker][3]. ## Step 1: Start BYOC Logs -Run the following command in your terminal to start a local BYOC Logs instance. Replace `` with your actual Datadog API Key. +Run the following command in your terminal to start a local {{< prodname >}}BYOC Logs{{< /prodname >}} instance. Replace `` with your actual Datadog API Key. ```shell export DD_API_KEY="" @@ -47,13 +47,13 @@ docker run -d \ In Datadog, go to the [BYOC Logs console][4] and check that your cluster is connected. You should see the `connected` status. -In the BYOC Logs console, you can edit the cluster metadata and rename your cluster to `demo`. +In the {{< prodname >}}BYOC Logs{{< /prodname >}} console, you can edit the cluster metadata and rename your cluster to `demo`. {{< img src="/cloudprem/quickstart/clouprem_console.png" alt="Screenshot of the BYOC Logs console showing the cluster connected status" style="width:100%;" >}} ## Step 3: Send a log -In your terminal, send a "Hello World" log entry directly to your local BYOC Logs instance using the API: +In your terminal, send a "Hello World" log entry directly to your local {{< prodname >}}BYOC Logs{{< /prodname >}} instance using the API: ```shell curl -X POST "http://localhost:7280/api/v2/logs" \ @@ -72,7 +72,7 @@ curl -X POST "http://localhost:7280/api/v2/logs" \ 1. Go to the [Datadog Log Explorer][5]. 2. On the left facet panel, select the checkbox for your index under {{< ui >}}BYOC INDEXES{{< /ui >}}. -3. You should see your "Hello world from BYOC Logs" log entry. +3. You should see your "Hello world from {{< prodname >}}BYOC Logs{{< /prodname >}}" log entry. {{< img src="/cloudprem/quickstart/cloudprem_indexes.png" alt="The BYOC Logs index selection in the Datadog Log Explorer" style="width:100%;" >}} diff --git a/hugo/content/en/byoc-logs/release_notes.md b/hugo/content/en/byoc-logs/release_notes.md index f37d872dfe3..7f54fd99cc1 100644 --- a/hugo/content/en/byoc-logs/release_notes.md +++ b/hugo/content/en/byoc-logs/release_notes.md @@ -20,7 +20,7 @@ This page tracks releases of the **BYOC (Bring Your Own Cloud) Logs binary**, di ### Check your installed binary version -Look at the `image` field on a BYOC Logs pod: +Look at the `image` field on a {{< prodname >}}BYOC Logs{{< /prodname >}} pod: ```shell kubectl get pods -n \ diff --git a/hugo/content/en/change_tracking/_index.md b/hugo/content/en/change_tracking/_index.md index 6f8b0d548ef..ef4cceb42be 100644 --- a/hugo/content/en/change_tracking/_index.md +++ b/hugo/content/en/change_tracking/_index.md @@ -38,18 +38,18 @@ further_reading: --- {{< site-region region="gov,gov2" >}} -
Change Tracking is not available in the selected site ({{< region-param key="dd_site_name" >}})
+
{{< prodname >}}Change Tracking{{< /prodname >}} is not available in the selected site ({{< region-param key="dd_site_name" >}})
{{< /site-region >}} ## Overview -Change Tracking streamlines troubleshooting and incident response by surfacing relevant changes to your service and its dependencies, enabling faster detection and remediation when issues arise. +{{< prodname >}}Change Tracking{{< /prodname >}} streamlines troubleshooting and incident response by surfacing relevant changes to your service and its dependencies, enabling faster detection and remediation when issues arise. {{< img src="/change_tracking/change-tracking-overview-2.png" alt="The details of a change on the Recent Changes timeline in the Service Summary" style="width:100%;" >}} -Change Tracking supports monitoring of a range of modifications to your service and its dependencies including: +{{< prodname >}}Change Tracking{{< /prodname >}} supports monitoring of a range of modifications to your service and its dependencies including: - Deployments -- [Feature Flags][14] +- [{{< prodname >}}Feature Flags{{< /prodname >}}][14] - Traffic Spikes - Configuration Changes - Database Modifications @@ -63,7 +63,7 @@ For details on specific types of supported changes and setup requirements, see t ## Using Change Tracking -Change Tracking is available on several pages in Datadog: +{{< prodname >}}Change Tracking{{< /prodname >}} is available on several pages in Datadog: ### Monitor status page @@ -124,30 +124,30 @@ To see relevant changes within the timeline and as overlays on your dashboard, e ### Widgets -In addition to the out-of-the-box integrations, Change Tracking is available as a data source for widgets across Datadog, including Dashboards and Notebooks. +In addition to the out-of-the-box integrations, {{< prodname >}}Change Tracking{{< /prodname >}} is available as a data source for widgets across Datadog, including Dashboards and Notebooks. {{< img src="/change_tracking/change-tracking-datasource-examples.png" alt="Change Tracking datasource examples" style="width:100%;" >}} -To configure a widget using Change Tracking data: +To configure a widget using {{< prodname >}}Change Tracking{{< /prodname >}} data: 1. In a dashboard or notebook, add or edit a supported widget type (Timeseries, Query Value, Table, Tree Map, Top List, Pie, Change, or Bar Chart). -3. From the {{< ui >}}data source{{< /ui >}} dropdown, select {{< ui >}}Change Tracking{{< /ui >}}. +3. From the {{< ui >}}data source{{< /ui >}} dropdown, select {{< ui >}}{{< prodname >}}Change Tracking{{< /prodname >}}{{< /ui >}}. 4. Configure your filters ({{< ui >}}Service{{< /ui >}} is required). 5. (Optional) For widgets that support grouping, use {{< ui >}}Group by{{< /ui >}} to split results. {{< img src="/change_tracking/change-tracking-datasource-edit-widget.png" alt="Change Tracking datasource widgets" style="width:100%;" >}} -For Timeseries widgets, you can also enable Change Tracking as an {{< ui >}}Event Overlay{{< /ui >}}, which displays changes on top of the timeseries to help correlate them with metric behavior. +For Timeseries widgets, you can also enable {{< prodname >}}Change Tracking{{< /prodname >}} as an {{< ui >}}Event Overlay{{< /ui >}}, which displays changes on top of the timeseries to help correlate them with metric behavior. {{< img src="/change_tracking/change-tracking-datasource-edit-overlay.png" alt="Change Tracking datasource as Event Overlay" style="width:100%;" >}} #### View change details -To view information about a change or set of changes, click a datapoint in the widget and select {{< ui >}}View Changes{{< /ui >}}. This opens the Change Tracking side panel with additional details. +To view information about a change or set of changes, click a datapoint in the widget and select {{< ui >}}View Changes{{< /ui >}}. This opens the {{< prodname >}}Change Tracking{{< /prodname >}} side panel with additional details. ## Tracked changes -Change Tracking follows these types of changes across your infrastructure: +{{< prodname >}}Change Tracking{{< /prodname >}} follows these types of changes across your infrastructure: | Change Type | Tracking Requirements | |----------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| diff --git a/hugo/content/en/change_tracking/feature_flags.md b/hugo/content/en/change_tracking/feature_flags.md index e57fb7471b7..db550745d9f 100644 --- a/hugo/content/en/change_tracking/feature_flags.md +++ b/hugo/content/en/change_tracking/feature_flags.md @@ -30,7 +30,7 @@ Datadog supports tracking [Datadog Feature Flags][8] automatically, [LaunchDarkl ### Datadog Feature Flags -Change tracking for [Datadog Feature Flags][8] is enabled automatically. No additional setup is required. When you update a flag's targeting, rollout, or status in an environment, Datadog emits a change tracking event that appears in your services' Change Tracking timelines. +Change tracking for [Datadog Feature Flags][8] is enabled automatically. No additional setup is required. When you update a flag's targeting, rollout, or status in an environment, Datadog emits a change tracking event that appears in your services' {{< prodname >}}Change Tracking{{< /prodname >}} timelines. Each event includes: @@ -44,14 +44,14 @@ To associate a Datadog Feature Flag change with a service, [instrument your flag ### LaunchDarkly flags -To track LaunchDarkly feature flags in your services' Change Tracking timeline: +To track LaunchDarkly feature flags in your services' {{< prodname >}}Change Tracking{{< /prodname >}} timeline: 1. Enable the [Datadog integration][1] in LaunchDarkly. 1. Go to {{< ui >}}Flags{{< /ui >}} > `` in LaunchDarkly. 1. In {{< ui >}}Datadog tags{{< /ui >}}, add a tag with key `service` and value ``, matching your Datadog service name exactly. 1. Click {{< ui >}}Save changes{{< /ui >}}. -For example, to link a flag to the `payments_api` service used in the examples below, you would set the tag value to `payments_api`. After you submit the event, you can navigate to the [Catalog][7], select the `payments_api` service, and see the `fallback_payments_test` feature flag event in the Change Tracking timeline. +For example, to link a flag to the `payments_api` service used in the examples below, you would set the tag value to `payments_api`. After you submit the event, you can navigate to the [Catalog][7], select the `payments_api` service, and see the `fallback_payments_test` feature flag event in the {{< prodname >}}Change Tracking{{< /prodname >}} timeline. ### Custom feature flags @@ -177,13 +177,13 @@ statsd.gauge( ## Remediate feature flag changes with Workflow Automation -When you identify that a feature flag change caused an issue, you can immediately toggle its state without leaving Datadog. This feature uses [Workflow Automation][2] to toggle LaunchDarkly flags directly from Change Tracking timelines. +When you identify that a feature flag change caused an issue, you can immediately toggle its state without leaving Datadog. This feature uses [{{< prodname >}}Workflow Automation{{< /prodname >}}][2] to toggle LaunchDarkly flags directly from {{< prodname >}}Change Tracking{{< /prodname >}} timelines. -
This feature requires Workflow Automation. See Workflow Automation pricing.
+
This feature requires {{< prodname >}}Workflow Automation{{< /prodname >}}. See {{< prodname >}}Workflow Automation{{< /prodname >}} pricing.
### Setup -To set up feature flag toggles using Workflow Automation: +To set up feature flag toggles using {{< prodname >}}Workflow Automation{{< /prodname >}}: 1. Go to [**Actions > Action Catalog > Connections**][6]. 1. Click **New Connection**. @@ -196,7 +196,7 @@ To set up feature flag toggles using Workflow Automation: To toggle feature flags on or off from inside Datadog: -1. Click a LaunchDarkly feature flag change in the Change Tracking timeline. +1. Click a LaunchDarkly feature flag change in the {{< prodname >}}Change Tracking{{< /prodname >}} timeline. 1. Click the {{< ui >}}Toggle Feature Flag{{< /ui >}} button. 1. Click {{< ui >}}Run Action{{< /ui >}} to run the workflow and toggle the feature flag on or off. diff --git a/hugo/content/en/cli/_index.md b/hugo/content/en/cli/_index.md index 85130bb64b6..5e381c5404b 100644 --- a/hugo/content/en/cli/_index.md +++ b/hugo/content/en/cli/_index.md @@ -18,7 +18,7 @@ further_reading: ## Overview -[Pup CLI][1] is a comprehensive, AI-agent-ready command-line interface that gives AI agents access to Datadog's observability platform. It exposes [Datadog's API surface][9] for use in AI agent workflows and automated pipelines. +[{{< prodname >}}Pup CLI{{< /prodname >}}][1] is a comprehensive, AI-agent-ready command-line interface that gives AI agents access to Datadog's observability platform. It exposes [Datadog's API surface][9] for use in AI agent workflows and automated pipelines. Key features: diff --git a/hugo/content/en/client_sdks/_index.md b/hugo/content/en/client_sdks/_index.md index ac0f98bcc7c..453f32dc07d 100644 --- a/hugo/content/en/client_sdks/_index.md +++ b/hugo/content/en/client_sdks/_index.md @@ -9,9 +9,9 @@ description: "Instrument your client-side applications with Datadog SDKs to moni Datadog Client SDKs enable you to instrument your web and mobile applications with comprehensive observability. With these SDKs, you can: - Monitor real user interactions and page performance with Real User Monitoring (RUM) -- Track and debug errors and crashes with Error Tracking +- Track and debug errors and crashes with {{< prodname >}}Error Tracking{{< /prodname >}} - Record and replay user sessions with Session Replay -- Analyze user behavior and conversion funnels with Product Analytics +- Analyze user behavior and conversion funnels with {{< prodname >}}Product Analytics{{< /prodname >}} - Collect and forward application logs - Correlate frontend performance with backend traces diff --git a/hugo/content/en/cloud_cost_management/_index.md b/hugo/content/en/cloud_cost_management/_index.md index 5d1cad30de8..48cd3307284 100644 --- a/hugo/content/en/cloud_cost_management/_index.md +++ b/hugo/content/en/cloud_cost_management/_index.md @@ -62,7 +62,7 @@ cascade: ## Overview -Cloud Cost Management provides insights for engineering and finance teams to understand how infrastructure changes impact costs, allocate spend across your organization, and identify inefficiencies. +{{< prodname >}}Cloud Cost Management{{< /prodname >}} provides insights for engineering and finance teams to understand how infrastructure changes impact costs, allocate spend across your organization, and identify inefficiencies. {{< img src="cloud_cost/summary.png" alt="Gain insights into all of your cloud provider's cost and usage on the Cloud Costs Summary page in Datadog" style="width:100%;" >}} @@ -102,7 +102,7 @@ Optionally, you can programmatically export a timeseries graph of your Datadog c ## Tagging and cost allocation -Learn how tags are sourced, enriched, and managed in Cloud Cost Management by reading the [Tags documentation][5]. +Learn how tags are sourced, enriched, and managed in {{< prodname >}}Cloud Cost Management{{< /prodname >}} by reading the [Tags documentation][5]. You can create tag rules to correct missing or incorrect tags, and add inferred tags that align with your organization's business logic. @@ -118,7 +118,7 @@ Use [Container Cost Allocation metrics][4] to discover costs associated with clu ## Permissions -Cloud Cost Management uses the following permissions to control access to cost data and most CCM configurations: +{{< prodname >}}Cloud Cost Management{{< /prodname >}} uses the following permissions to control access to cost data and most CCM configurations: - `cloud_cost_management_read` - `cloud_cost_management_write` diff --git a/hugo/content/en/cloud_cost_management/ai_costs.md b/hugo/content/en/cloud_cost_management/ai_costs.md index 16cc63a6387..690b48d4b18 100644 --- a/hugo/content/en/cloud_cost_management/ai_costs.md +++ b/hugo/content/en/cloud_cost_management/ai_costs.md @@ -34,11 +34,11 @@ further_reading: ## Overview -AI Costs in Cloud Cost Management gives FinOps and engineering teams a unified destination for analyzing AI spend across providers, including Amazon Bedrock, Anthropic, Google Gemini, OpenAI, Vertex AI, GitHub Copilot, and Cursor. View total AI spend alongside your existing cloud infrastructure costs, analyze it with normalized tags, track cost anomalies, identify optimization opportunities, and attribute usage to the specific users and API keys driving it. +AI Costs in {{< prodname >}}Cloud Cost Management{{< /prodname >}} gives FinOps and engineering teams a unified destination for analyzing AI spend across providers, including Amazon Bedrock, Anthropic, Google Gemini, OpenAI, Vertex AI, GitHub Copilot, and Cursor. View total AI spend alongside your existing cloud infrastructure costs, analyze it with normalized tags, track cost anomalies, identify optimization opportunities, and attribute usage to the specific users and API keys driving it. ## Prerequisites -To use AI Costs, you must have at least one of the following supported providers set up for [Cloud Cost Management][1]: +To use AI Costs, you must have at least one of the following supported providers set up for [{{< prodname >}}Cloud Cost Management{{< /prodname >}}][1]: | AI provider | Setup method | |---|---| diff --git a/hugo/content/en/cloud_cost_management/allocation/_index.md b/hugo/content/en/cloud_cost_management/allocation/_index.md index a37d2fd453c..89cde2127b8 100644 --- a/hugo/content/en/cloud_cost_management/allocation/_index.md +++ b/hugo/content/en/cloud_cost_management/allocation/_index.md @@ -11,7 +11,7 @@ further_reading: ## Overview -The Allocation section of Cloud Cost Management helps you understand and optimize your cloud spending by breaking down costs across different resources and organizational dimensions. Use these tools to allocate costs to specific teams, projects, or business units, track resource-level spending, and identify optimization opportunities. +The Allocation section of {{< prodname >}}Cloud Cost Management{{< /prodname >}} helps you understand and optimize your cloud spending by breaking down costs across different resources and organizational dimensions. Use these tools to allocate costs to specific teams, projects, or business units, track resource-level spending, and identify optimization opportunities. ## Key features diff --git a/hugo/content/en/cloud_cost_management/allocation/custom_allocation_rules.md b/hugo/content/en/cloud_cost_management/allocation/custom_allocation_rules.md index 83b125dafdf..284cc31bd79 100644 --- a/hugo/content/en/cloud_cost_management/allocation/custom_allocation_rules.md +++ b/hugo/content/en/cloud_cost_management/allocation/custom_allocation_rules.md @@ -177,7 +177,7 @@ You can also disable a custom allocation rule without deleting it. Rules are applied in the same order as shown in the list. ## Visualize your allocations -Changes to custom allocation rules may take up to 24 hours to be applied. After being applied, the new allocations can be seen throughout Cloud Cost Management. Custom allocated costs also include an `allocated_by_rule` tag, denoting the rule name that applied the allocation. +Changes to custom allocation rules may take up to 24 hours to be applied. After being applied, the new allocations can be seen throughout {{< prodname >}}Cloud Cost Management{{< /prodname >}}. Custom allocated costs also include an `allocated_by_rule` tag, denoting the rule name that applied the allocation. {{< img src="cloud_cost/custom_allocation_rules/visualize_your_allocations-1.png" alt="See your allocations throughout Datadog" style="width:90%;" >}} diff --git a/hugo/content/en/cloud_cost_management/allocation/tag_pipelines.md b/hugo/content/en/cloud_cost_management/allocation/tag_pipelines.md index f40fe0691e4..0110eeeb51e 100644 --- a/hugo/content/en/cloud_cost_management/allocation/tag_pipelines.md +++ b/hugo/content/en/cloud_cost_management/allocation/tag_pipelines.md @@ -23,7 +23,7 @@ further_reading: ## Overview -Tags are the foundation for all Cloud Cost Management analysis and allocation. They enable you to break down spending by service, team, project, environment, or any dimension relevant to your business. Tag Pipelines enforce the use of standardized tags across your cloud resources and help ensure consistent, accurate cost attribution throughout your organization. +Tags are the foundation for all {{< prodname >}}Cloud Cost Management{{< /prodname >}} analysis and allocation. They enable you to break down spending by service, team, project, environment, or any dimension relevant to your business. Tag Pipelines enforce the use of standardized tags across your cloud resources and help ensure consistent, accurate cost attribution throughout your organization. With [Tag Pipelines][1], you can create tag rules to address missing or incorrect tags on your cloud bills. You can also create new inferred tags that align with specific business logic to enhance the accuracy of your cost tracking. These standardized tags power all cost analysis capabilities, including container cost allocation, custom allocation rules, and cost recommendations. diff --git a/hugo/content/en/cloud_cost_management/cloud_cost_skill.md b/hugo/content/en/cloud_cost_management/cloud_cost_skill.md index 3d8165a9982..eccdb6d51ca 100644 --- a/hugo/content/en/cloud_cost_management/cloud_cost_skill.md +++ b/hugo/content/en/cloud_cost_management/cloud_cost_skill.md @@ -21,7 +21,7 @@ further_reading: ## Overview -The Cloud Cost skill is the Cloud Cost Management analysis workflow in [Bits Chat][1]. It is designed for FinOps tasks, such as root cause analysis, budget tracking, and answering general cost questions. For example, you can ask Bits Chat to: +The Cloud Cost skill is the {{< prodname >}}Cloud Cost Management{{< /prodname >}} analysis workflow in [{{< prodname >}}Bits Chat{{< /prodname >}}][1]. It is designed for FinOps tasks, such as root cause analysis, budget tracking, and answering general cost questions. For example, you can ask {{< prodname >}}Bits Chat{{< /prodname >}} to: - Investigate [cost monitor alerts][2], [cost anomalies][3], and [cost changes][4] - Identify teams, services, accounts, regions, or resources driving spend @@ -32,7 +32,7 @@ The Cloud Cost skill is the Cloud Cost Management analysis workflow in [Bits Cha ## Prerequisites -To use the Cloud Cost skill in Bits Chat, you must: +To use the Cloud Cost skill in {{< prodname >}}Bits Chat{{< /prodname >}}, you must: - [Set up Cloud Cost Management][6] for the cost sources you want to analyze - Have these permissions: @@ -46,7 +46,7 @@ To use the Cloud Cost skill in Bits Chat, you must: When you want to start an investigation, such as for a [cost anomaly][3], click {{< ui >}}Investigate{{< /ui >}} or {{< img src="bits_ai/dev_agent/twinkling_stars_icon.png" inline="true" style="width:24px">}} (the twinkling stars icon) to open the Cloud Cost skill. -Alternatively, you can click {{< ui >}}Ask Bits{{< /ui >}} on the top right of the navigation bar on any Datadog page to open Bits Chat and ask a cost question. +Alternatively, you can click {{< ui >}}Ask Bits{{< /ui >}} on the top right of the navigation bar on any Datadog page to open {{< prodname >}}Bits Chat{{< /prodname >}} and ask a cost question. Example prompts: @@ -58,7 +58,7 @@ Example prompts: ### Cost change investigations -When you investigate a cost change with the Cloud Cost skill, Bits Chat provides a concise summary, then asks what you want to explore next. The initial analysis typically includes: +When you investigate a cost change with the Cloud Cost skill, {{< prodname >}}Bits Chat{{< /prodname >}} provides a concise summary, then asks what you want to explore next. The initial analysis typically includes: - A daily cost chart for the baseline and investigation periods - The baseline period, investigation period, total dollar amount and percentage change, and projected annual impact when applicable @@ -67,7 +67,7 @@ When you investigate a cost change with the Cloud Cost skill, Bits Chat provides {{< img src="cloud_cost/cc_skill_cost_summary.png" alt="Bits Chat's investigation summary showing an initial analysis." style="width:60%;" >}} -After the initial summary, Bits Chat can: +After the initial summary, {{< prodname >}}Bits Chat{{< /prodname >}} can: - Find the top services, accounts, regions, resources, or tags driving the change - Correlate the cost change with metrics such as CPU requests, memory requests, request count, bucket size, or database usage @@ -77,14 +77,14 @@ After the initial summary, Bits Chat can: ### Budgets and forecasting -After setting up [Budgets][5], use the Cloud Cost skill in Bits Chat to explain budget status and spending. Bits Chat can help summarize: +After setting up [Budgets][5], use the Cloud Cost skill in {{< prodname >}}Bits Chat{{< /prodname >}} to explain budget status and spending. {{< prodname >}}Bits Chat{{< /prodname >}} can help summarize: - Actual spend versus budgeted amount - Forecasted spend versus budgeted amount - Which cost scope a budget covers, based on the budget's filters - Which budget entries, teams, services, or providers are contributing to an overage -After the initial summary, Bits Chat can: +After the initial summary, {{< prodname >}}Bits Chat{{< /prodname >}} can: - Find the top services, accounts, regions, resources, or tags driving spending - Identify the teams that own the resources contributing to the cost change @@ -93,12 +93,12 @@ After the initial summary, Bits Chat can: ## Use the Datadog MCP Server for cost analysis -The [Datadog MCP Server][10] lets external AI agents query Datadog data. This is useful when you want to ask cost questions from an IDE, terminal-based assistant, or custom AI workflow. +The [{{< prodname >}}Datadog MCP Server{{< /prodname >}}][10] lets external AI agents query Datadog data. This is useful when you want to ask cost questions from an IDE, terminal-based assistant, or custom AI workflow. To use an external AI agent, [set up the Datadog MCP Server][11]. If your MCP client filters toolsets, you must enable the relevant toolset before the agent can call its tools: - Enable the `cost` toolset to list cost-saving recommendations with [`cost_recommendations`][16]. -- Enable the `core` toolset to query Cloud Cost Management metrics with the metric tools. +- Enable the `core` toolset to query {{< prodname >}}Cloud Cost Management{{< /prodname >}} metrics with the metric tools. ### List cost-saving recommendations @@ -112,14 +112,14 @@ Example prompts for the `cost` toolset: ### Query Cloud Cost Management metrics -The `core` toolset provides the metric tools that can query Cloud Cost Management data: +The `core` toolset provides the metric tools that can query {{< prodname >}}Cloud Cost Management{{< /prodname >}} data: | MCP tool | Usage | | --------------------------------- | ------------------------------------- | | [`get_datadog_metric`][12] | Query cost metrics, compare periods, and group costs by provider, service, team, account, resource, or tag. | | [`get_datadog_metric_context`][13] | Discover metadata, available tag keys, and tag values for a cost metric before querying it. | -Ask your agent to set `use_cloud_cost` to `true` for Cloud Cost Management metrics, such as `all.cost`, `aws.cost.*`, `azure.cost.*`, `gcp.cost.*`, `oci.cost.*`, `custom.cost.*`, or `datadog.cost.*`. For observability metrics that explain a cost change, such as Kubernetes CPU or S3 bucket size, use the standard metric query behavior. +Ask your agent to set `use_cloud_cost` to `true` for {{< prodname >}}Cloud Cost Management{{< /prodname >}} metrics, such as `all.cost`, `aws.cost.*`, `azure.cost.*`, `gcp.cost.*`, `oci.cost.*`, `custom.cost.*`, or `datadog.cost.*`. For observability metrics that explain a cost change, such as Kubernetes CPU or S3 bucket size, use the standard metric query behavior. Example prompts for the `core` toolset: diff --git a/hugo/content/en/cloud_cost_management/cost_changes/_index.md b/hugo/content/en/cloud_cost_management/cost_changes/_index.md index 0173fc358ce..eb463ef0dbd 100644 --- a/hugo/content/en/cloud_cost_management/cost_changes/_index.md +++ b/hugo/content/en/cloud_cost_management/cost_changes/_index.md @@ -9,7 +9,7 @@ further_reading: ## Overview -Cloud Cost Management can help you proactively detect and respond to unexpected cost changes before they become significant problems. Use these tools to automatically identify anomalies, set up custom alerts, and track costs in near real-time across AWS, Azure, and Google Cloud. +{{< prodname >}}Cloud Cost Management{{< /prodname >}} can help you proactively detect and respond to unexpected cost changes before they become significant problems. Use these tools to automatically identify anomalies, set up custom alerts, and track costs in near real-time across AWS, Azure, and Google Cloud. ## Key features diff --git a/hugo/content/en/cloud_cost_management/cost_changes/real_time_costs.md b/hugo/content/en/cloud_cost_management/cost_changes/real_time_costs.md index da9d860f35d..eca209135a2 100644 --- a/hugo/content/en/cloud_cost_management/cost_changes/real_time_costs.md +++ b/hugo/content/en/cloud_cost_management/cost_changes/real_time_costs.md @@ -27,7 +27,7 @@ Real-time costs are available for: Real-Time Costs is available for Cloud Cost Management Enterprise customers. -- Cloud Cost Management is enabled for the AWS account +- {{< prodname >}}Cloud Cost Management{{< /prodname >}} is enabled for the AWS account - Datadog Agent is installed on each EC2 instance - (Optional) To see Kubernetes costs in real time, enable Datadog Container Monitoring for your clusters by following the setup guide in [Container Cost Allocation][2] @@ -54,7 +54,7 @@ Similar to the existing container cost allocation, EC2 instance costs are broken ## Tags -Tags for real-time costs are similar to those on other Cloud Cost Management metrics, but not identical. +Tags for real-time costs are similar to those on other {{< prodname >}}Cloud Cost Management{{< /prodname >}} metrics, but not identical. - All tag values are lowercase, normalized like Metrics data - Tag Pipelines and Custom Allocation Rules are not applied - Some Cost and Usage Report (CUR) specific tags and FOCUS tags may not exist on the real-time cost metric, since real-time costs are derived primarily using usage data collected by the Datadog Agent, not the CUR diff --git a/hugo/content/en/cloud_cost_management/datadog_costs.md b/hugo/content/en/cloud_cost_management/datadog_costs.md index 14dd60ef4e0..f012a4f4a4b 100644 --- a/hugo/content/en/cloud_cost_management/datadog_costs.md +++ b/hugo/content/en/cloud_cost_management/datadog_costs.md @@ -17,20 +17,20 @@ further_reading: Daily Datadog costs give you visibility into daily Datadog spending across dashboards, notebooks, [cost monitors][1], Cloud Cost Explorer, [reports][12], [budgets][11], and [anomalies][13], along with your entire organization's cloud provider and [SaaS costs][2]. -You can view daily Datadog costs in [Cloud Cost Management][3](CCM), and access additional Datadog cost capabilities like [Cost Summary][5] and [Cost Chargebacks][6] on the [{{< ui >}}Plan & Usage{{< /ui >}} page][7]. +You can view daily Datadog costs in [{{< prodname >}}Cloud Cost Management{{< /prodname >}}][3](CCM), and access additional Datadog cost capabilities like [Cost Summary][5] and [Cost Chargebacks][6] on the [{{< ui >}}Plan & Usage{{< /ui >}} page][7]. There is **no additional charge** for Datadog Costs, and it is available for both CCM and non-CCM customers with a direct contract through Datadog or an External Marketplace drawdown contract. ## Required permissions -Viewing Datadog costs in Cloud Cost Management requires both the `billing_read` and `usage_read` permissions: `billing_read` grants access to Datadog cost data, and `usage_read` grants access to Datadog usage data. This requirement applies everywhere Datadog cost data appears, including Cloud Cost Management, dashboards, and notebooks. The `cloud_cost_management_read` permission grants access to Cloud Cost Management and to your cloud and SaaS provider costs, but it does not grant access to Datadog cost data on its own. +Viewing Datadog costs in {{< prodname >}}Cloud Cost Management{{< /prodname >}} requires both the `billing_read` and `usage_read` permissions: `billing_read` grants access to Datadog cost data, and `usage_read` grants access to Datadog usage data. This requirement applies everywhere Datadog cost data appears, including {{< prodname >}}Cloud Cost Management{{< /prodname >}}, dashboards, and notebooks. The `cloud_cost_management_read` permission grants access to {{< prodname >}}Cloud Cost Management{{< /prodname >}} and to your cloud and SaaS provider costs, but it does not grant access to Datadog cost data on its own. | Permission | Description | Available Roles | |------------|-------------|-----------------| | `billing_read` | Read access to billing information. **Required to view Datadog cost data.** | • Datadog Admin | | `usage_read` | Read access to usage data. **Required to view Datadog usage data.** | • Datadog Admin | -**Note**: A user with `cloud_cost_management_read` but without `billing_read` and `usage_read` can use Cloud Cost Management for their cloud and SaaS providers, but Datadog costs do not appear for them. `cloud_cost_management_read` is not required to view Datadog costs. To give a user access to Datadog cost data, assign them a role that includes the `billing_read` and `usage_read` permissions. For more information about managing roles, see [Role Based Access Control][14]. +**Note**: A user with `cloud_cost_management_read` but without `billing_read` and `usage_read` can use {{< prodname >}}Cloud Cost Management{{< /prodname >}} for their cloud and SaaS providers, but Datadog costs do not appear for them. `cloud_cost_management_read` is not required to view Datadog costs. To give a user access to Datadog cost data, assign them a role that includes the `billing_read` and `usage_read` permissions. For more information about managing roles, see [Role Based Access Control][14]. ## Data availability to sub-organizations @@ -38,7 +38,7 @@ Daily Datadog cost data is available to sub-organizations with the [Sub Organiza ## Visualize and break down costs -Costs in Cloud Cost Management may not match the estimated month-to-date (MTD) costs on the [{{< ui >}}Plan & Usage{{< /ui >}} page][7] because Plan & Usage costs are cumulative and prorated monthly. Only Cloud Cost Management provides daily cost calculations. +Costs in {{< prodname >}}Cloud Cost Management{{< /prodname >}} may not match the estimated month-to-date (MTD) costs on the [{{< ui >}}Plan & Usage{{< /ui >}} page][7] because Plan & Usage costs are cumulative and prorated monthly. Only Cloud Cost Management provides daily cost calculations. Datadog cost data has an expected data delay of 48 hours and is available for the past 15 months. Prior month Datadog charges are finalized around the 16th of each month. Before costs are finalized, the {{< ui >}}Usage Charges Only: Enabled{{< /ui >}} toggle represents estimated usage-based charges only. When charges are finalized, the {{< ui >}}Usage Charges Only: Disabled{{< /ui >}} toggle also includes any adjustment records. These adjustments are applied to the prior month and reflect the finalized cost amounts. diff --git a/hugo/content/en/cloud_cost_management/planning/_index.md b/hugo/content/en/cloud_cost_management/planning/_index.md index c481f1d1bf4..06e473e6313 100644 --- a/hugo/content/en/cloud_cost_management/planning/_index.md +++ b/hugo/content/en/cloud_cost_management/planning/_index.md @@ -11,7 +11,7 @@ further_reading: ## Overview -The Planning section of Cloud Cost Management helps you take control of your cloud spend by enabling you to set budgets and manage cloud commitment programs. Use these tools to forecast, track, and optimize your costs, ensuring you stay within budget and maximize savings across your cloud providers. +The Planning section of {{< prodname >}}Cloud Cost Management{{< /prodname >}} helps you take control of your cloud spend by enabling you to set budgets and manage cloud commitment programs. Use these tools to forecast, track, and optimize your costs, ensuring you stay within budget and maximize savings across your cloud providers. ## Key Features diff --git a/hugo/content/en/cloud_cost_management/planning/commitment_programs.md b/hugo/content/en/cloud_cost_management/planning/commitment_programs.md index f498d96de6c..6da83d6f8bc 100644 --- a/hugo/content/en/cloud_cost_management/planning/commitment_programs.md +++ b/hugo/content/en/cloud_cost_management/planning/commitment_programs.md @@ -22,7 +22,7 @@ With Commitment Programs, you can: Use Commitment Programs to understand and optimize your cloud commitments. -1. Go to [**Cloud Cost > Planning > Commitment Programs**][1] in Cloud Cost Management. +1. Go to [**Cloud Cost > Planning > Commitment Programs**][1] in {{< prodname >}}Cloud Cost Management{{< /prodname >}}. 2. Use the product selector to choose a commitment type and the time frame selector to set the reporting period. 3. Gain insights into your KPIs, commitment costs, and renewal recommendations: - Review KPIs in the [Commitments overview](#commitments-overview) section. diff --git a/hugo/content/en/cloud_cost_management/planning/forecasting.md b/hugo/content/en/cloud_cost_management/planning/forecasting.md index 364a400e419..15c4c9a4846 100644 --- a/hugo/content/en/cloud_cost_management/planning/forecasting.md +++ b/hugo/content/en/cloud_cost_management/planning/forecasting.md @@ -15,7 +15,7 @@ further_reading: ## Overview -Cloud Cost Management (CCM) Forecasts help you predict future cloud costs based on historical spending patterns. Use forecasts to anticipate cost trends, plan budgets more effectively, and make data-driven decisions about resource allocation. +{{< prodname >}}Cloud Cost Management{{< /prodname >}} (CCM) Forecasts help you predict future cloud costs based on historical spending patterns. Use forecasts to anticipate cost trends, plan budgets more effectively, and make data-driven decisions about resource allocation. Forecasts are available in: - [**Reports**](#view-forecasts-in-reports): Enable the forecast toggle on Cost reports and Budget reports to visualize predicted costs. @@ -30,7 +30,7 @@ With Forecasts, you can: ## How forecasting works -Cloud Cost Management uses forecasting algorithms to generate cost to generate cost predictions. The forecasting model analyzes your historical spending data to identify patterns and trends in your cloud costs, including: +{{< prodname >}}Cloud Cost Management{{< /prodname >}} uses forecasting algorithms to generate cost to generate cost predictions. The forecasting model analyzes your historical spending data to identify patterns and trends in your cloud costs, including: - Recurring costs that happen on a **predictable schedule** (such as weekly or monthly cycles). - Whether your costs are **increasing, decreasing, or staying stable** over time. diff --git a/hugo/content/en/cloud_cost_management/recommendations/_index.md b/hugo/content/en/cloud_cost_management/recommendations/_index.md index b1b9c06bd13..91016a76b80 100644 --- a/hugo/content/en/cloud_cost_management/recommendations/_index.md +++ b/hugo/content/en/cloud_cost_management/recommendations/_index.md @@ -726,7 +726,7 @@ You can see the detailed logic for each recommendation type, along with observab Recommendations support [Tag Pipelines][11], allowing you to filter, group, and analyze recommendations using your organization's standardized tags. Any tag rules configured in Tag Pipelines are automatically applied to recommendations and [are normalized][12]. -You can also query your recommendations from an AI agent with the [`cost_recommendations`][16] tool in the Datadog MCP Server. +You can also query your recommendations from an AI agent with the [`cost_recommendations`][16] tool in the {{< prodname >}}Datadog MCP Server{{< /prodname >}}. ## Recommendation categories @@ -756,7 +756,7 @@ The following are requirements necessary to receive Cloud Cost recommendations: For each cloud account that you would like to receive recommendations for: -1. Configure [Cloud Cost Management][2] to send billing data to Datadog. +1. Configure [{{< prodname >}}Cloud Cost Management{{< /prodname >}}][2] to send billing data to Datadog. - For Azure, this requires using the App Registration method to collect billing data. 1. Enable [resource collection][3] for recommendations. - For AWS, enable resource collection in the {{< ui >}}Resource Collection{{< /ui >}} tab on the [AWS integration tile][4]. @@ -818,7 +818,7 @@ You can change a recommendation status in three ways: - **From the side panel**: Click a recommendation to open the side panel, then use the status dropdown to select a new status. ## Recommendation action-taking -You can act on recommendations to save money and optimize costs. Cloud Cost Recommendations support Jira, 1-click Workflow Automation, and Datadog Case Management. Unused EBS and GP2 EBS volume recommendations also support 1-click Workflow Automation. See the following details for each action-taking option: +You can act on recommendations to save money and optimize costs. Cloud Cost Recommendations support Jira, 1-click {{< prodname >}}Workflow Automation{{< /prodname >}}, and Datadog Case Management. Unused EBS and GP2 EBS volume recommendations also support 1-click {{< prodname >}}Workflow Automation{{< /prodname >}}. See the following details for each action-taking option: - **Jira**: Create Jira issues directly from the recommendation side panel or by selecting multiple recommendations in the {{< ui >}}Active Recommendations{{< /ui >}} list and clicking {{< ui >}}Create Jira issue{{< /ui >}}. Created issues are tagged and link back to the recommendation in Datadog. @@ -827,8 +827,8 @@ You can act on recommendations to save money and optimize costs. Cloud Cost Reco - `-@jira_issues.issue_key:*` - Show only recommendations without a Jira issue - `jira_issues.issue_key:ABC*` - Filter by specific Jira project prefix -- **[Bits Code][14] code fixes**: Code fixes are available for applicable S3 and DynamoDB recommendations, as well as the Downsize Kubernetes Deployment recommendation. In these situations, Bits Code creates production-ready pull requests to implement cloud resource changes and cost optimizations in Terraform or Helm charts, respectively. [Set up Bits Code][13] to use this feature. -- **1-click Workflow Automation actions**: Actions are available for a limited set of recommendations, allowing users to execute suggested actions, such as clicking {{< ui >}}Delete EBS Volume{{< /ui >}}, directly within Cloud Cost Management. +- **[{{< prodname >}}Bits Code{{< /prodname >}}][14] code fixes**: Code fixes are available for applicable S3 and DynamoDB recommendations, as well as the Downsize Kubernetes Deployment recommendation. In these situations, {{< prodname >}}Bits Code{{< /prodname >}} creates production-ready pull requests to implement cloud resource changes and cost optimizations in Terraform or Helm charts, respectively. [Set up Bits Code][13] to use this feature. +- **1-click {{< prodname >}}Workflow Automation{{< /prodname >}} actions**: Actions are available for a limited set of recommendations, allowing users to execute suggested actions, such as clicking {{< ui >}}Delete EBS Volume{{< /ui >}}, directly within {{< prodname >}}Cloud Cost Management{{< /prodname >}}. - **[Cost Optimization Automation][15]**: Set up automations that act on recommendations continuously on a recurring schedule. Automations are scoped to specific accounts, regions, and tags and include safeguards such as pre-action snapshots and optional human approval through Slack or Microsoft Teams. - **Datadog Case Management**: Users can go to the recommendation side panel and click {{< ui >}}Create Case{{< /ui >}} to generate a case to manage and take action on recommendations. - **Dismiss**: Use {{< ui >}}Dismiss{{< /ui >}} in the recommendation side panel to hide a recommendation for a chosen time frame and provide a reason. Dismissed recommendations move to the {{< ui >}}Dismissed{{< /ui >}} tab. diff --git a/hugo/content/en/cloud_cost_management/recommendations/cost_optimization_automation.md b/hugo/content/en/cloud_cost_management/recommendations/cost_optimization_automation.md index c5489d4d12d..eacf5f45f23 100644 --- a/hugo/content/en/cloud_cost_management/recommendations/cost_optimization_automation.md +++ b/hugo/content/en/cloud_cost_management/recommendations/cost_optimization_automation.md @@ -27,7 +27,7 @@ Each automation targets a single recommendation type and includes the following: Recommendations acted on by an automation move to {{< ui >}}Completed{{< /ui >}} automatically and contribute to realized savings on the [Cloud Cost Recommendations][1] page. -Cost Optimization Automation is different from the 1-click Workflow Automation actions described in [Recommendation action-taking][2]. 1-click actions execute a single change on demand from the recommendation side panel. Automations execute on a recurring schedule and act on every matching resource in scope. +Cost Optimization Automation is different from the 1-click {{< prodname >}}Workflow Automation{{< /prodname >}} actions described in [Recommendation action-taking][2]. 1-click actions execute a single change on demand from the recommendation side panel. Automations execute on a recurring schedule and act on every matching resource in scope. **Note**: Cost Optimization Automation uses Datadog Workflows and incurs additional costs. For detailed pricing information, see the [Workflow Automation pricing page][3]. @@ -89,7 +89,7 @@ Open an automation and select the {{< ui >}}Activity{{< /ui >}} tab to see past - Execution time and status (success, failure, or pending approval) - The resources acted on - Estimated savings realized by the run -- A link to the underlying Workflow Automation execution +- A link to the underlying {{< prodname >}}Workflow Automation{{< /prodname >}} execution Use the filters at the top of the {{< ui >}}Activity{{< /ui >}} view to find executions by status, recommendation type, or date range. diff --git a/hugo/content/en/cloud_cost_management/setup/aws.md b/hugo/content/en/cloud_cost_management/setup/aws.md index bbf565bbc3f..c78449426cb 100644 --- a/hugo/content/en/cloud_cost_management/setup/aws.md +++ b/hugo/content/en/cloud_cost_management/setup/aws.md @@ -21,7 +21,7 @@ further_reading: ## Overview -To set up Cloud Cost Management in Datadog, you need: +To set up {{< prodname >}}Cloud Cost Management{{< /prodname >}} in Datadog, you need: 1. An AWS account with billing access 2. The AWS integration installed in Datadog 3. A Cost and Usage Report (follow the steps below to create one) @@ -232,7 +232,7 @@ Attach the new S3 policy to the Datadog integration role. #### Permissions for AWS Cost Optimization Hub recommendations -Cloud Cost Management generates some [recommendations][30] from data sourced from [AWS Cost Optimization Hub][31]. For Datadog to receive these recommendations, the Datadog AWS integration IAM role must include the following permissions: +{{< prodname >}}Cloud Cost Management{{< /prodname >}} generates some [recommendations][30] from data sourced from [AWS Cost Optimization Hub][31]. For Datadog to receive these recommendations, the Datadog AWS integration IAM role must include the following permissions: - `cost-optimization-hub:GetRecommendation` - `cost-optimization-hub:ListRecommendations` @@ -243,9 +243,9 @@ If you set up the AWS integration before these permissions were added to the def ### Account filtering -Use Account Filtering to control which AWS member accounts to pull into Cloud Cost Management. Filtering out accounts does not incur additional Datadog costs. +Use Account Filtering to control which AWS member accounts to pull into {{< prodname >}}Cloud Cost Management{{< /prodname >}}. Filtering out accounts does not incur additional Datadog costs. -Using Account Filtering requires an AWS management account. You can configure account filters after an account has been configured in Cloud Cost Management. +Using Account Filtering requires an AWS management account. You can configure account filters after an account has been configured in {{< prodname >}}Cloud Cost Management{{< /prodname >}}. **Note:** Account filters are not supported for tag search. @@ -495,7 +495,7 @@ Billing rates, credits and fees, and overhead costs can be customized at your di - Adding accounts to a billing group impacts how Reservations and Savings Plans are shared across AWS accounts. To create a billing conductor CUR, follow the [AWS Cost and Usage Reports user guide][8]. Ensure the CUR meets [Datadog's requirements][9]. -After the billing conductor CUR is created, follow the Cloud Cost Management instructions above to set it up in Datadog. +After the billing conductor CUR is created, follow the {{< prodname >}}Cloud Cost Management{{< /prodname >}} instructions above to set it up in Datadog. ## Further reading {{< partial name="whats-next/whats-next.html" >}} diff --git a/hugo/content/en/cloud_cost_management/setup/azure.md b/hugo/content/en/cloud_cost_management/setup/azure.md index 57112317260..c8a1cde8770 100644 --- a/hugo/content/en/cloud_cost_management/setup/azure.md +++ b/hugo/content/en/cloud_cost_management/setup/azure.md @@ -40,7 +40,7 @@ Datadog provides cost visibility on a Subscription, Resource Group, and Billing You can set up using the [API][13], [Terraform][14], or directly in Datadog by following the instructions below. {{% site-region region="us3" %}} -**Note**: If you are using Datadog's **US3** site, you may have set up the Datadog Azure Native integration using the [Datadog Resource method][1] through the Azure Portal. To support Cloud Cost Management, you need to [create an app registration][2]. +**Note**: If you are using Datadog's **US3** site, you may have set up the Datadog Azure Native integration using the [Datadog Resource method][1] through the Azure Portal. To support {{< prodname >}}Cloud Cost Management{{< /prodname >}}, you need to [create an app registration][2]. [1]: https://www.datadoghq.com/blog/azure-datadog-partnership/ diff --git a/hugo/content/en/cloud_cost_management/setup/custom.md b/hugo/content/en/cloud_cost_management/setup/custom.md index 8c5ddb59328..ed46bdd0954 100644 --- a/hugo/content/en/cloud_cost_management/setup/custom.md +++ b/hugo/content/en/cloud_cost_management/setup/custom.md @@ -228,7 +228,7 @@ In this example, an additional `Tags` object property has been added with two ke ### Configure Custom Costs -After your data is formatted to the requirements above, upload your CSV and JSON files to Cloud Cost Management on the [**Custom Costs Files** page][3] or programmatically by using the API. +After your data is formatted to the requirements above, upload your CSV and JSON files to {{< prodname >}}Cloud Cost Management{{< /prodname >}} on the [**Custom Costs Files** page][3] or programmatically by using the API. In Datadog: diff --git a/hugo/content/en/cloud_cost_management/setup/google_cloud.md b/hugo/content/en/cloud_cost_management/setup/google_cloud.md index 09eb05ab6ea..84b5d3c834d 100644 --- a/hugo/content/en/cloud_cost_management/setup/google_cloud.md +++ b/hugo/content/en/cloud_cost_management/setup/google_cloud.md @@ -153,7 +153,7 @@ In the CCM Terraform setup UI, follow the instructions in the **Apply Terraform {{< /tabs >}} ### Create or select a Google Cloud Storage bucket -Cloud Cost Management uses a GCP storage bucket to receive data extracted from your Detailed Usage Cost BigQuery dataset (prefixed with `datadog_cloud_cost_detailed_usage_export`). You can create a new bucket or use an existing one. +{{< prodname >}}Cloud Cost Management{{< /prodname >}} uses a GCP storage bucket to receive data extracted from your Detailed Usage Cost BigQuery dataset (prefixed with `datadog_cloud_cost_detailed_usage_export`). You can create a new bucket or use an existing one. **Note:** The bucket [must be co-located][9] with the BigQuery export dataset. diff --git a/hugo/content/en/cloud_cost_management/setup/oracle.md b/hugo/content/en/cloud_cost_management/setup/oracle.md index 675510ed71c..88d566714fe 100644 --- a/hugo/content/en/cloud_cost_management/setup/oracle.md +++ b/hugo/content/en/cloud_cost_management/setup/oracle.md @@ -20,7 +20,7 @@ further_reading: ## Overview -To set up Cloud Cost Management for Oracle Cloud Infrastructure (OCI) in Datadog, you should: +To set up {{< prodname >}}Cloud Cost Management{{< /prodname >}} for Oracle Cloud Infrastructure (OCI) in Datadog, you should: 1. Have an OCI tenancy 2. Have the [OCI integration][1] installed in Datadog @@ -32,13 +32,13 @@ Navigate to [Setup & Configuration][2], add an OCI account and follow the steps **Note**: If the OCI integration was created without the QuickStart method, then you need to follow the [documentation][3] for QuickStart migration. ### Enable Cloud Cost Management -Once the integration is created, enable the toggle for Cloud Cost Management. +Once the integration is created, enable the toggle for {{< prodname >}}Cloud Cost Management{{< /prodname >}}. {{< img src="cloud_cost/oci/oci_ccm_enablement.png" alt="Toggle for enabling Cloud Cost Management" style="width:100%;" >}} ### Getting historical data -Oracle Cloud Infrastructure retains cost reports for 1 year. When you enable Cloud Cost Management, Datadog automatically ingests up to 15 months of available historical cost data from these retained reports (up to 1 year based on Oracle's retention). +Oracle Cloud Infrastructure retains cost reports for 1 year. When you enable {{< prodname >}}Cloud Cost Management{{< /prodname >}}, Datadog automatically ingests up to 15 months of available historical cost data from these retained reports (up to 1 year based on Oracle's retention). Oracle does not provide a process for backfilling additional historical data beyond what is already retained in the cost reports. diff --git a/hugo/content/en/cloud_cost_management/setup/permissions.md b/hugo/content/en/cloud_cost_management/setup/permissions.md index 9f24fe5e2ae..faceb0503d0 100644 --- a/hugo/content/en/cloud_cost_management/setup/permissions.md +++ b/hugo/content/en/cloud_cost_management/setup/permissions.md @@ -16,7 +16,7 @@ further_reading: Permissions control what actions a user can take in Datadog. Users are assigned to roles, and each role has a set of permissions that determines what that user can see and do. -Cloud Cost Management (CCM) uses two main permissions, `cloud_cost_management_read` and `cloud_cost_management_write`, to control access to cost data and most CCM configurations. Additional product-level permissions are available for specific features, such as editing budgets (`ccm_budget_write`), customizing forecast in the budgets (`ccm_forecast_write`), and managing report schedules (`generate_ccm_report_schedules`, `manage_ccm_report_schedules`). Assign these permissions to roles through [Role Based Access Control (RBAC)][1]. +{{< prodname >}}Cloud Cost Management{{< /prodname >}} (CCM) uses two main permissions, `cloud_cost_management_read` and `cloud_cost_management_write`, to control access to cost data and most CCM configurations. Additional product-level permissions are available for specific features, such as editing budgets (`ccm_budget_write`), customizing forecast in the budgets (`ccm_forecast_write`), and managing report schedules (`generate_ccm_report_schedules`, `manage_ccm_report_schedules`). Assign these permissions to roles through [Role Based Access Control (RBAC)][1]. CCM also supports [Data Access Control](#data-access-control) to further restrict cost data by tags. diff --git a/hugo/content/en/cloud_cost_management/setup/saas_costs.md b/hugo/content/en/cloud_cost_management/setup/saas_costs.md index b49c4de5d83..836bf172aba 100644 --- a/hugo/content/en/cloud_cost_management/setup/saas_costs.md +++ b/hugo/content/en/cloud_cost_management/setup/saas_costs.md @@ -62,13 +62,13 @@ Navigate to [**Cloud Cost** > **Settings**, select **Accounts**][8] and then cli {{< img src="integrations/snowflake/snowflake_account_url.png" alt="The account menu with the copy account URL option selected in the Snowflake UI" style="width:100%;" >}} 2. Navigate to the [Snowflake integration tile][101] in Datadog and click {{< ui >}}Add Snowflake Account{{< /ui >}}. 3. Enter your Snowflake account URL in the {{< ui >}}Account URL{{< /ui >}} field. For example: `https://xyz12345.us-east-1.snowflakecomputing.com`. -4. Under the {{< ui >}}Connect your Snowflake account{{< /ui >}} section, click the toggle to enable Snowflake in Cloud Cost Management. +4. Under the {{< ui >}}Connect your Snowflake account{{< /ui >}} section, click the toggle to enable Snowflake in {{< prodname >}}Cloud Cost Management{{< /prodname >}}. 5. Enter your Snowflake user name in the {{< ui >}}User Name{{< /ui >}} field. 6. Follow step 4 of the [Snowflake integration][103] page to create a Datadog-specific role and user to monitor Snowflake. 7. Follow step 5 of the [Snowflake integration][103] page to configure the key-value pair authentication. 8. Click {{< ui >}}Save{{< /ui >}}. -Snowflake cost data from the past 6 months is available in Cloud Cost Management within 24 hours. To access the available data collected by each SaaS Cost Integration, see the [Data Collected section](#data-collected). +Snowflake cost data from the past 6 months is available in {{< prodname >}}Cloud Cost Management{{< /prodname >}} within 24 hours. To access the available data collected by each SaaS Cost Integration, see the [Data Collected section](#data-collected). **Snowflake query tags** @@ -86,7 +86,7 @@ To use query tags within cost management, ensure the following: - The `query_tag` string must be JSON parsable. Specifically, this means that the string is processable by the native `PARSE_JSON` function. -- An allowlist of keys must be provided in the Snowflake integration tile. These keys map to the first layer of the JSON-formatted `query_tag` field. This allowlist appears in the form of a comma-separated list of strings for example: `tag_1,tag_2,tag_3`. Ensure that strings contain only alphanumeric characters, underscores, hyphens, and periods. You can enter this information into the Snowflake tile, under {{< ui >}}Resources Collected{{< /ui >}} > {{< ui >}}Cloud Cost Management{{< /ui >}} > {{< ui >}}Collected Query Tags{{< /ui >}}. +- An allowlist of keys must be provided in the Snowflake integration tile. These keys map to the first layer of the JSON-formatted `query_tag` field. This allowlist appears in the form of a comma-separated list of strings for example: `tag_1,tag_2,tag_3`. Ensure that strings contain only alphanumeric characters, underscores, hyphens, and periods. You can enter this information into the Snowflake tile, under {{< ui >}}Resources Collected{{< /ui >}} > {{< ui >}}{{< prodname >}}Cloud Cost Management{{< /prodname >}}{{< /ui >}} > {{< ui >}}Collected Query Tags{{< /ui >}}. **Note**: Select your query tags with data magnitude in mind. Appropriate query tags are ones that have low to medium group cardinality (for example: team, user, service). Selecting a query tag with high group cardinality (such as unique UUID associated with job executions) can result in bottlenecking issues for both data ingestion and frontend rendering. @@ -125,7 +125,7 @@ GRANT USE SCHEMA ON CATALOG system TO ``; GRANT SELECT ON CATALOG system TO ``; ``` -Your Databricks cost data for the past 15 months can be accessed in Cloud Cost Management after 24 hours. To access the available data collected by each SaaS Cost Integration, see the [Data Collected section](#data-collected). +Your Databricks cost data for the past 15 months can be accessed in {{< prodname >}}Cloud Cost Management{{< /prodname >}} after 24 hours. To access the available data collected by each SaaS Cost Integration, see the [Data Collected section](#data-collected). {{< img src="cloud_cost/saas_costs/databricks_setup_1.png" alt="Integrate with Databricks to collect cost data." style="width:100%" >}} @@ -136,7 +136,7 @@ Your Databricks cost data for the past 15 months can be accessed in Cloud Cost M {{% tab "OpenAI" %}} -
An admin-scoped API key is required to collect OpenAI cost data for Cloud Cost Management. Project-scoped API keys cannot collect cost data.
+
An admin-scoped API key is required to collect OpenAI cost data for {{< prodname >}}Cloud Cost Management{{< /prodname >}}. Project-scoped API keys cannot collect cost data.
1. Create an [admin API key][103] in your OpenAI account settings: - Log in to your [OpenAI Account][104]. @@ -147,7 +147,7 @@ Your Databricks cost data for the past 15 months can be accessed in Cloud Cost M 4. Under the {{< ui >}}Resources{{< /ui >}} section, click the toggle for each account to enable `OpenAI Billing Usage Data Collection`. 5. Click {{< ui >}}Save{{< /ui >}}. -Your OpenAI cost data for the past 15 months can be accessed in Cloud Cost Management after 24 hours. To access the available data collected by each SaaS Cost Integration, see the [Data Collected section](#data-collected). +Your OpenAI cost data for the past 15 months can be accessed in {{< prodname >}}Cloud Cost Management{{< /prodname >}} after 24 hours. To access the available data collected by each SaaS Cost Integration, see the [Data Collected section](#data-collected). {{< img src="cloud_cost/saas_costs/openai_setup.png" alt="Integrate with OpenAI to collect cost data." style="width:100%" >}} @@ -197,7 +197,7 @@ Begin by getting an Admin API key from Cursor. This key allows access to usage a 3. Under the {{< ui >}}Resources{{< /ui >}} section, click the toggle for each account to enable `Cursor in Cloud Cost Management`. 4. Click {{< ui >}}Save{{< /ui >}}. -After you save your configuration, Datadog begins polling Cursor usage and cost endpoints using this key, and populates metrics in your environment. Your Cursor cost data for the past 15 months can be accessed in Cloud Cost Management after 24 hours. To access the available data collected by each SaaS Cost Integration, see the [Data Collected section](#data-collected). +After you save your configuration, Datadog begins polling Cursor usage and cost endpoints using this key, and populates metrics in your environment. Your Cursor cost data for the past 15 months can be accessed in {{< prodname >}}Cloud Cost Management{{< /prodname >}} after 24 hours. To access the available data collected by each SaaS Cost Integration, see the [Data Collected section](#data-collected). [101]: https://app.datadoghq.com/integrations/cursor @@ -220,7 +220,7 @@ After you save your configuration, Datadog begins polling Cursor usage and cost 3. Click {{< ui >}}Add Account{{< /ui >}} and paste in the Billing API key from Temporal Cloud. 4. Click {{< ui >}}Save{{< /ui >}}. -After you save your configuration, Datadog begins polling the Temporal Cloud Billing API using this key, and populates metrics in your environment. Your Temporal Cloud cost data can be accessed in Cloud Cost Management within 25-30 hours. To access the available data collected by each SaaS Cost Integration, see the [Data Collected section](#data-collected). +After you save your configuration, Datadog begins polling the Temporal Cloud Billing API using this key, and populates metrics in your environment. Your Temporal Cloud cost data can be accessed in {{< prodname >}}Cloud Cost Management{{< /prodname >}} within 25-30 hours. To access the available data collected by each SaaS Cost Integration, see the [Data Collected section](#data-collected). [110]: https://app.datadoghq.com/integrations/temporal-cloud-costs @@ -234,7 +234,7 @@ After you save your configuration, Datadog begins polling the Temporal Cloud Bil 4. Enter an account name, your personal access token, and your enterprise name (in `enterprise-name` format), as well as any appropriate tags. 5. Click the checkmark button to save this account. -Your GitHub cost data for the past 15 months can be accessed in Cloud Cost Management within 24 hours. To access the available data collected by each SaaS Cost Integration, see the [Data Collected section](#data-collected). +Your GitHub cost data for the past 15 months can be accessed in {{< prodname >}}Cloud Cost Management{{< /prodname >}} within 24 hours. To access the available data collected by each SaaS Cost Integration, see the [Data Collected section](#data-collected). {{< img src="cloud_cost/saas_costs/github_setup.png" alt="Integrate with GitHub to collect cost data." style="width:100%" >}} @@ -248,10 +248,10 @@ Your GitHub cost data for the past 15 months can be accessed in Cloud Cost Manag 1. Create or acquire an API key with the [billing admin][102] role in Confluent Cloud. 2. Navigate to the [Confluent Cloud integration tile][101] in Datadog and click {{< ui >}}Add Account{{< /ui >}}. 3. Enter your Confluent Cloud account name, API key, API secret, and optionally, specify tags. -4. Under the {{< ui >}}Resources{{< /ui >}} section, click the toggle for {{< ui >}}Collect cost data to view in Cloud Cost Management{{< /ui >}}. +4. Under the {{< ui >}}Resources{{< /ui >}} section, click the toggle for {{< ui >}}Collect cost data to view in {{< prodname >}}Cloud Cost Management{{< /prodname >}}{{< /ui >}}. 5. Click {{< ui >}}Save{{< /ui >}}. -Your Confluent Cloud cost data becomes available in Cloud Cost Management 24 hours after setup. This data automatically includes 12 months of history, the maximum provided by the Confluent billing API. Over the next three months, the data gradually expands to cover 15 months of history. To access the available data collected by each SaaS Cost Integration, see the [Data Collected section](#data-collected). +Your Confluent Cloud cost data becomes available in {{< prodname >}}Cloud Cost Management{{< /prodname >}} 24 hours after setup. This data automatically includes 12 months of history, the maximum provided by the Confluent billing API. Over the next three months, the data gradually expands to cover 15 months of history. To access the available data collected by each SaaS Cost Integration, see the [Data Collected section](#data-collected). If you wish to collect cluster-level tags or business metadata tags for your costs, you can add a Schema Registry API key and secret. Please look into [Schema Management on Confluent Cloud][103] for more information. @@ -269,7 +269,7 @@ If you wish to collect cluster-level tags or business metadata tags for your cos 3. Enter your MongoDB account name, public key, private key, organizational ID, and optionally, specify tags. 4. Click {{< ui >}}Save{{< /ui >}}. -Your MongoDB cost data for the past 15 months can be accessed in Cloud Cost Management after 24 hours. To access the available data collected by each SaaS Cost Integration, see the [Data Collected section](#data-collected). +Your MongoDB cost data for the past 15 months can be accessed in {{< prodname >}}Cloud Cost Management{{< /prodname >}} after 24 hours. To access the available data collected by each SaaS Cost Integration, see the [Data Collected section](#data-collected). {{< img src="cloud_cost/saas_costs/mongodb_setup.png" alt="Integrate with MongoDB to collect cost data." style="width:100%" >}} @@ -289,7 +289,7 @@ Your MongoDB cost data for the past 15 months can be accessed in Cloud Cost Mana 7. Click {{< ui >}}Add Account{{< /ui >}}. 8. Enter your {{< ui >}}Elastic Cloud Organization ID{{< /ui >}} and {{< ui >}}Billing API Key{{< /ui >}} in the account table. -Your Elastic Cloud cost data for the past 15 months can be accessed in Cloud Cost Management after 24 hours. To access the available data collected by each SaaS Cost Integration, see the [Data Collected section](#data-collected). +Your Elastic Cloud cost data for the past 15 months can be accessed in {{< prodname >}}Cloud Cost Management{{< /prodname >}} after 24 hours. To access the available data collected by each SaaS Cost Integration, see the [Data Collected section](#data-collected). {{< img src="cloud_cost/saas_costs/elasticcloud_setup.png" alt="Integrate with Elastic Cloud to collect cost data." style="width:100%" >}} @@ -305,7 +305,7 @@ Your Elastic Cloud cost data for the past 15 months can be accessed in Cloud Cos 3. Enter your Fastly account name and API token. 4. Click {{< ui >}}Save{{< /ui >}}. -Your Fastly cost data for the past 15 months can be accessed in Cloud Cost Management after 24 hours. To access the available data collected by each SaaS Cost Integration, see the [Data Collected section](#data-collected). +Your Fastly cost data for the past 15 months can be accessed in {{< prodname >}}Cloud Cost Management{{< /prodname >}} after 24 hours. To access the available data collected by each SaaS Cost Integration, see the [Data Collected section](#data-collected). {{< img src="cloud_cost/saas_costs/fastly_setup_1.png" alt="Integrate with Fastly to collect cost data." style="width:100%" >}} @@ -320,7 +320,7 @@ Your Fastly cost data for the past 15 months can be accessed in Cloud Cost Manag 3. Enter an {{< ui >}}Account SID{{< /ui >}} for your Twilio account. 4. Click {{< ui >}}Save{{< /ui >}}. -Your Twilio cost data for the past 15 months can be accessed in Cloud Cost Management after 24 hours. To access the available data collected by each SaaS Cost Integration, see the [Data Collected section](#data-collected). +Your Twilio cost data for the past 15 months can be accessed in {{< prodname >}}Cloud Cost Management{{< /prodname >}} after 24 hours. To access the available data collected by each SaaS Cost Integration, see the [Data Collected section](#data-collected). {{< img src="cloud_cost/saas_costs/twilio_setup.png" alt="Integrate with Twilio to collect cost data." style="width:100%" >}} diff --git a/hugo/content/en/cloud_cost_management/tags/_index.md b/hugo/content/en/cloud_cost_management/tags/_index.md index e693e3328c6..4f795c584da 100644 --- a/hugo/content/en/cloud_cost_management/tags/_index.md +++ b/hugo/content/en/cloud_cost_management/tags/_index.md @@ -20,7 +20,7 @@ further_reading: Tags help you investigate and understand your cloud and SaaS costs across any dimensions. Tags consist of tag keys and values. For example, in `aws_product:ec2`, the tag key is `aws_product`, and the value is `ec2`. -Cloud Cost Management automatically enriches your cost data with tags from multiple sources, to help you achieve better cost allocation and get deeper insight into who owns infrastructure costs in your ever-changing cloud environments. Using tags, you can allocate shared costs fairly, create accurate reports, and track costs by team, service, or environment. +{{< prodname >}}Cloud Cost Management{{< /prodname >}} automatically enriches your cost data with tags from multiple sources, to help you achieve better cost allocation and get deeper insight into who owns infrastructure costs in your ever-changing cloud environments. Using tags, you can allocate shared costs fairly, create accurate reports, and track costs by team, service, or environment. ## Where tags come from @@ -67,9 +67,9 @@ Datadog also adds provider-specific tags: ## How tags are normalized -Tag keys and values may look slightly different in Cloud Cost Management compared to the providers or other parts of Datadog because of tag normalization. +Tag keys and values may look slightly different in {{< prodname >}}Cloud Cost Management{{< /prodname >}} compared to the providers or other parts of Datadog because of tag normalization. -Cloud Cost Management normalizes tag **keys** in a similar way to Datadog Metrics: +{{< prodname >}}Cloud Cost Management{{< /prodname >}} normalizes tag **keys** in a similar way to Datadog Metrics: - Drop leading characters that are not letters - Lowercase all characters - Replace special characters and spaces with single underscores `_` @@ -77,7 +77,7 @@ Cloud Cost Management normalizes tag **keys** in a similar way to Datadog Metric - Reduce contiguous underscores to a single underscore - Tag keys up to 5000 characters are supported, and any characters before the first letter are dropped so that tag keys start with letters (different from Datadog Metrics) -Cloud Cost Management normalizes tag **values** as well, while maintaining human readable tag values for cost reporting. For example, `aws_instance_family:Machine Learning ASIC Instances` remains readable rather than being converted to something like `machine_learning_asic_instances`. The normalization follows this logic: +{{< prodname >}}Cloud Cost Management{{< /prodname >}} normalizes tag **values** as well, while maintaining human readable tag values for cost reporting. For example, `aws_instance_family:Machine Learning ASIC Instances` remains readable rather than being converted to something like `machine_learning_asic_instances`. The normalization follows this logic: - Convert any consecutive whitespaces to a single space - Keep all letters, marks, numbers, punctuation, and symbols - Replace any other characters with an underscore `_` @@ -101,7 +101,7 @@ Tag normalization allows you to: A cost data row can have multiple values for the same tag key when tag values from two or more sources are combined and one is not prioritized over the other. -To resolve conflicts and mitigate this, Cloud Cost Management replaces existing tags instead of adding duplicates using the most specific source for each tag key. For example, a Kubernetes Pod tag `team:shopping` would take precedence and replace a Kubernetes node tag `team:compute`. +To resolve conflicts and mitigate this, {{< prodname >}}Cloud Cost Management{{< /prodname >}} replaces existing tags instead of adding duplicates using the most specific source for each tag key. For example, a Kubernetes Pod tag `team:shopping` would take precedence and replace a Kubernetes node tag `team:compute`. Sources higher in this list replace tag values from sources lower in this list, if there are conflicts: - Custom Allocation Rules diff --git a/hugo/content/en/cloud_cost_management/tags/multisource_querying.md b/hugo/content/en/cloud_cost_management/tags/multisource_querying.md index 2f92cb08417..b8dd9866e6a 100644 --- a/hugo/content/en/cloud_cost_management/tags/multisource_querying.md +++ b/hugo/content/en/cloud_cost_management/tags/multisource_querying.md @@ -18,13 +18,13 @@ aliases: ## Overview -After you start ingesting your [AWS][1], [Azure][2], [Google Cloud][3], [Oracle][15], [SaaS][4], or [Datadog costs][5] in [Cloud Cost Management][6], you can flexibly query costs across providers. Multisource Querying enables you to query costs across multiple providers using consistent and standardized tags instead of building multiple queries for each provider. +After you start ingesting your [AWS][1], [Azure][2], [Google Cloud][3], [Oracle][15], [SaaS][4], or [Datadog costs][5] in [{{< prodname >}}Cloud Cost Management{{< /prodname >}}][6], you can flexibly query costs across providers. Multisource Querying enables you to query costs across multiple providers using consistent and standardized tags instead of building multiple queries for each provider. Use Multisource Querying to build cost views, understand the total cost of service ownership, and alert on cost changes and trends across the [**Explorer** page][6], [dashboards][7], [notebooks][8], and [cost monitors][9]. ## Setup -To use Multisource Querying, ensure you have configured [Cloud Cost Management][10] and are actively ingesting costs in Datadog. Multiple currencies are supported, with your costs automatically being converted to and displayed in USD. +To use Multisource Querying, ensure you have configured [{{< prodname >}}Cloud Cost Management{{< /prodname >}}][10] and are actively ingesting costs in Datadog. Multiple currencies are supported, with your costs automatically being converted to and displayed in USD. ## Query your cost data @@ -71,7 +71,7 @@ Multisource Querying uses the `all.cost` metric, which combines all individual c ### Out-of-the-box tags -Cloud Cost Management collects tags for the AWS, Azure, Google Cloud, and Oracle Cloud integrations. This table provides a non-exhaustive list of out-of-the-box tags shared across each integration. +{{< prodname >}}Cloud Cost Management{{< /prodname >}} collects tags for the AWS, Azure, Google Cloud, and Oracle Cloud integrations. This table provides a non-exhaustive list of out-of-the-box tags shared across each integration. | Tag Name | Tag Description | |---|---| @@ -83,13 +83,13 @@ Cloud Cost Management collects tags for the AWS, Azure, Google Cloud, and Oracle ### Tag enrichment -Cloud Cost Management enriches all provider cost data with tags that adhere to the [FinOps FOCUS specification][12]. FOCUS™ is a technical specification that normalizes cost and usage billing data across cloud vendors. +{{< prodname >}}Cloud Cost Management{{< /prodname >}} enriches all provider cost data with tags that adhere to the [FinOps FOCUS specification][12]. FOCUS™ is a technical specification that normalizes cost and usage billing data across cloud vendors. FOCUS tags allow you to query similar concepts across providers. For example, if you'd like to see cost per account across AWS and Azure, you are not required to create two queries (one for AWS costs grouped by `aws_member_account_name` and one for Azure costs grouped by `subscriptionname`). You can use one search query that filters to AWS and Azure costs grouped by `subaccountname`. -Cloud Cost Management adds lowercase versions of the specification Column IDs to all cost metrics. +{{< prodname >}}Cloud Cost Management{{< /prodname >}} adds lowercase versions of the specification Column IDs to all cost metrics. -The following FOCUS tags are available in Cloud Cost Management: +The following FOCUS tags are available in {{< prodname >}}Cloud Cost Management{{< /prodname >}}: | Tag Name | Tag Description | |---|---| @@ -106,10 +106,10 @@ The following FOCUS tags are available in Cloud Cost Management: The `all.cost` metric has [Container costs allocated][13] for AWS, Azure, and Google Cloud costs, so you can query by the [relevant container tags][14]. -
If your organization tags with any of these FOCUS tags, Datadog recommends updating your tag key on the underlying infrastructure so that tag values do not overlap with FOCUS tag values in Cloud Cost Management.
+
If your organization tags with any of these FOCUS tags, Datadog recommends updating your tag key on the underlying infrastructure so that tag values do not overlap with FOCUS tag values in {{< prodname >}}Cloud Cost Management{{< /prodname >}}.
## Currency conversion -Cloud Cost Management retrieves the billing currency from each cloud provider's bill. When processing costs from multiple providers in different currencies, cost charges are converted to USD. This conversion is performed using the average monthly exchange rate, which is updated daily. This ensures that Cloud Cost Management can consistently and accurately represent all cost data, regardless of its original currency. To view your cost in the original billing currency, filter to a single provider. +{{< prodname >}}Cloud Cost Management{{< /prodname >}} retrieves the billing currency from each cloud provider's bill. When processing costs from multiple providers in different currencies, cost charges are converted to USD. This conversion is performed using the average monthly exchange rate, which is updated daily. This ensures that {{< prodname >}}Cloud Cost Management{{< /prodname >}} can consistently and accurately represent all cost data, regardless of its original currency. To view your cost in the original billing currency, filter to a single provider. ## Further reading diff --git a/hugo/content/en/cloud_cost_management/tags/tag_explorer.md b/hugo/content/en/cloud_cost_management/tags/tag_explorer.md index 036191b7f9f..79fe229ed36 100644 --- a/hugo/content/en/cloud_cost_management/tags/tag_explorer.md +++ b/hugo/content/en/cloud_cost_management/tags/tag_explorer.md @@ -23,7 +23,7 @@ further_reading: ## Overview -[Cloud Cost Management][1] detects the sources for all of your cost-related tags. You can search and manage tags for breaking down costs, including [Custom Costs][4], [Datadog costs][5], and [SaaS cost integrations][6]. +[{{< prodname >}}Cloud Cost Management{{< /prodname >}}][1] detects the sources for all of your cost-related tags. You can search and manage tags for breaking down costs, including [Custom Costs][4], [Datadog costs][5], and [SaaS cost integrations][6]. Use the [Tag Explorer][2] to understand the sources and view descriptions for each tag. This includes tags managed through [Tag Pipelines][3]. Tag Pipelines allow you to create and manage tag rules that fix missing or incorrect tags on your cloud bill, or create inferred tags according to your business logic. @@ -31,7 +31,7 @@ Use the [Tag Explorer][2] to understand the sources and view descriptions for ea ## Setup -To use the Tag Explorer, you must configure [Cloud Cost Management][1] for AWS, Azure, Google Cloud, or Oracle Cloud. +To use the Tag Explorer, you must configure [{{< prodname >}}Cloud Cost Management{{< /prodname >}}][1] for AWS, Azure, Google Cloud, or Oracle Cloud. See the respective documentation for your cloud provider: @@ -151,7 +151,7 @@ For Twilio tags, select {{< ui >}}Twilio{{< /ui >}} from the dropdown menu on th {{< /tabs >}} ## Set preferred tags -You can set up to five preferred tags to highlight your organization's most important tags throughout Cloud Cost Management. These tags appear first when selecting tags in the [Explorer page][7], [CCM Reports][8], and [Custom Allocation Rules][9], among other areas. +You can set up to five preferred tags to highlight your organization's most important tags throughout {{< prodname >}}Cloud Cost Management{{< /prodname >}}. These tags appear first when selecting tags in the [Explorer page][7], [CCM Reports][8], and [Custom Allocation Rules][9], among other areas. {{< img src="cloud_cost/tag_explorer/preferred_tags_1.png" alt="Preferred tags are shown throughout CCM" style="width:100%;" >}} @@ -168,7 +168,7 @@ You can add or edit descriptions for any tag in the Tag Explorer to provide cont Tag descriptions are visible to all members of your organization and appear in the following locations: - {{< ui >}}Tag Explorer{{< /ui >}}: Descriptions are displayed in the tag table alongside each tag key. -- {{< ui >}}Group-by selectors{{< /ui >}}: When selecting tags to group by across Cloud Cost Management, descriptions appear in the dropdown menu to help users choose the right tag. +- {{< ui >}}Group-by selectors{{< /ui >}}: When selecting tags to group by across {{< prodname >}}Cloud Cost Management{{< /prodname >}}, descriptions appear in the dropdown menu to help users choose the right tag. ## Further reading diff --git a/hugo/content/en/code_coverage/configuration.md b/hugo/content/en/code_coverage/configuration.md index 8d6227b6f78..6ec5d99f52d 100644 --- a/hugo/content/en/code_coverage/configuration.md +++ b/hugo/content/en/code_coverage/configuration.md @@ -168,7 +168,7 @@ ignore: ## PR Gates -You can define [PR Gates][2] in the configuration file to enforce code coverage thresholds on pull requests. If gates are also configured in the [Datadog UI][2], Datadog evaluates both the configuration file rules and the UI rules when a PR is opened or updated. +You can define [{{< prodname >}}PR Gates{{< /prodname >}}][2] in the configuration file to enforce code coverage thresholds on pull requests. If gates are also configured in the [Datadog UI][2], Datadog evaluates both the configuration file rules and the UI rules when a PR is opened or updated.
If both the configuration file and the Datadog UI define gates for the same scope, the pull request must meet every defined threshold.
diff --git a/hugo/content/en/code_coverage/flags.md b/hugo/content/en/code_coverage/flags.md index 14b5aaa4d0a..8dd11c53fca 100644 --- a/hugo/content/en/code_coverage/flags.md +++ b/hugo/content/en/code_coverage/flags.md @@ -25,7 +25,7 @@ Flags in Code Coverage let you organize and filter coverage data by custom categ With flags, you can: - View coverage data filtered by a specific flag in the Datadog UI. -- Configure [PR Gates][1] that evaluate coverage thresholds for specific flags. +- Configure [{{< prodname >}}PR Gates{{< /prodname >}}][1] that evaluate coverage thresholds for specific flags. - Track coverage trends separately for different test suites or environments. - Enable [carryforward][2] to keep total coverage accurate when not every CI job runs for a commit. @@ -90,7 +90,7 @@ In this example, the coverage data is available under both the `unit-tests` and ### Add flags to automatically uploaded reports -[Automatic report uploads][4] are available in several Test Optimization libraries. Of those libraries, only the following versions support `DD_CODE_COVERAGE_FLAGS`: +[Automatic report uploads][4] are available in several {{< prodname >}}Test Optimization{{< /prodname >}} libraries. Of those libraries, only the following versions support `DD_CODE_COVERAGE_FLAGS`: | Library | First version with `DD_CODE_COVERAGE_FLAGS` | |---|---| @@ -125,7 +125,7 @@ When you select a flag, the coverage metrics update to show only the data from r ## Set up PR Gates with flags -You can configure [PR Gates][1] to enforce coverage thresholds for specific flags. This allows you to enforce different coverage requirements for different test types or runtime versions. +You can configure [{{< prodname >}}PR Gates{{< /prodname >}}][1] to enforce coverage thresholds for specific flags. This allows you to enforce different coverage requirements for different test types or runtime versions. You can create flag-specific gates in one of two ways: diff --git a/hugo/content/en/code_coverage/monorepo_support.md b/hugo/content/en/code_coverage/monorepo_support.md index eee03f3cb6c..8d11e8302c0 100644 --- a/hugo/content/en/code_coverage/monorepo_support.md +++ b/hugo/content/en/code_coverage/monorepo_support.md @@ -45,7 +45,7 @@ These methods can be used together. Service splitting and code owner splitting w If you use [Catalog][1], Code Coverage automatically uses the `codeLocations` attribute from your service definitions to calculate coverage for each service. -
Using Catalog for service definitions is the recommended approach, as code locations configured in Catalog can be used by multiple Datadog products, including Code Coverage, Error Tracking, and Code Security. Use manual configuration only when Catalog integration is not available.
+
Using Catalog for service definitions is the recommended approach, as code locations configured in Catalog can be used by multiple Datadog products, including Code Coverage, {{< prodname >}}Error Tracking{{< /prodname >}}, and {{< prodname >}}Code Security{{< /prodname >}}. Use manual configuration only when Catalog integration is not available.
### How Catalog integration works @@ -115,7 +115,7 @@ On the Branch overview, Pull Request details, and Commit details pages in [Code ## Set up PR Gates for services and code owners -You can configure [PR Gates][7] to enforce coverage thresholds for specific services or code owners. +You can configure [{{< prodname >}}PR Gates{{< /prodname >}}][7] to enforce coverage thresholds for specific services or code owners. ### Using the Datadog UI diff --git a/hugo/content/en/code_coverage/setup.md b/hugo/content/en/code_coverage/setup.md index 9da330e9deb..057eff59f26 100644 --- a/hugo/content/en/code_coverage/setup.md +++ b/hugo/content/en/code_coverage/setup.md @@ -87,11 +87,11 @@ Navigate to [Roles settings][4], click {{< ui >}}Edit{{< /ui >}} on the role you For more granular control, use [Data Access Control][19] to restrict code coverage data by repository rather than across your entire organization. This prevents sensitive information in coverage reports, such as source paths and test names, from crossing team boundaries. -In Datadog, go to **Organization Settings > Data Access Control** and create a Restricted Dataset scoped to Software Delivery and the repository you want to restrict. Grant access to the roles or teams that should see it. +In Datadog, go to **Organization Settings > Data Access Control** and create a Restricted Dataset scoped to {{< prodname >}}Software Delivery{{< /prodname >}} and the repository you want to restrict. Grant access to the roles or teams that should see it. ## PR Gates -If you wish to gate on PR coverage, you can configure PR Gates rules in one of two ways: +If you wish to gate on PR coverage, you can configure {{< prodname >}}PR Gates{{< /prodname >}} rules in one of two ways: - **Datadog UI**: Navigate to [PR Gates rule creation][5] and configure a rule to gate on total or patch coverage. - **YAML configuration file**: Define gates in your [`code-coverage.datadog.yml`][6] file. This allows you to manage gates as code alongside your repository. @@ -100,7 +100,7 @@ Rules from both sources are evaluated when a pull request is opened or updated. ## Upload code coverage reports -Upload code coverage report files to Datadog either automatically, with a supported Test Optimization library, or manually, by running the `datadog-ci` CLI in your CI environment. +Upload code coverage report files to Datadog either automatically, with a supported {{< prodname >}}Test Optimization{{< /prodname >}} library, or manually, by running the `datadog-ci` CLI in your CI environment. See [Data Collected][7] for details on what data is collected during code coverage report upload. @@ -108,7 +108,7 @@ See [Data Collected][7] for details on what data is collected during code covera #### Supported libraries and versions -Automatic code coverage report upload is supported in the following Test Optimization library versions: +Automatic code coverage report upload is supported in the following {{< prodname >}}Test Optimization{{< /prodname >}} library versions: | Library | First supported version | Coverage source | |---|---|---| @@ -118,7 +118,7 @@ Automatic code coverage report upload is supported in the following Test Optimiz | Python `ddtrace` | `4.4.0` | Default pytest plugin using `coverage.py` | | Java `dd-java-agent` | `1.53.0` | JaCoCo | -These version requirements apply only to automatic uploads by Test Optimization libraries. +These version requirements apply only to automatic uploads by {{< prodname >}}Test Optimization{{< /prodname >}} libraries. #### Enable automatic uploads diff --git a/hugo/content/en/containers/_index.md b/hugo/content/en/containers/_index.md index c4d5bb41e36..7b83fbb997b 100644 --- a/hugo/content/en/containers/_index.md +++ b/hugo/content/en/containers/_index.md @@ -51,7 +51,7 @@ Log into Datadog and use the [Install Agents][2] page to install the Datadog Age {{< nextlink href="/containers/kubernetes/configuration">}}Further Configuration: Additional configuration options for APM, logs, processes, events, and other capabilities after installing the Datadog Agent {{< /nextlink >}} {{< nextlink href="/containers/kubernetes/distributions">}}Distributions: Platform-specific installation and configuration instructions for Datadog Agent on various Kubernetes distributions {{< /nextlink >}} {{< nextlink href="/containers/kubernetes/apm">}}APM: Enable APM trace collection for containerized applications running in Kubernetes environments {{< /nextlink >}} - {{< nextlink href="/containers/kubernetes/appsec">}}App and API Protection: Automatically enable App and API Protection for your Kubernetes ingress proxies and gateways {{< /nextlink >}} + {{< nextlink href="/containers/kubernetes/appsec">}}{{< prodname >}}App and API Protection{{< /prodname >}}: Automatically enable {{< prodname >}}App and API Protection{{< /prodname >}} for your Kubernetes ingress proxies and gateways {{< /nextlink >}} {{< nextlink href="/containers/kubernetes/log">}}Log collection: Configure log collection from containerized applications running on Kubernetes using the Datadog Agent {{< /nextlink >}} {{< nextlink href="/containers/kubernetes/tag">}}Tag extraction: Configure automatic tag extraction from Kubernetes pod labels and annotations for enhanced monitoring {{< /nextlink >}} {{< nextlink href="/containers/kubernetes/integrations">}}Integrations: Configure monitoring integrations for applications running in Kubernetes using Autodiscovery templates {{< /nextlink >}} diff --git a/hugo/content/en/containers/autoscaling/_index.md b/hugo/content/en/containers/autoscaling/_index.md index be8c3eb6341..ab2c4617568 100644 --- a/hugo/content/en/containers/autoscaling/_index.md +++ b/hugo/content/en/containers/autoscaling/_index.md @@ -34,7 +34,7 @@ Datadog Kubernetes Autoscaling continuously monitors your Kubernetes resources t ## How it works Datadog uses real-time and historical utilization metrics and event signals from your existing Datadog Agents to make recommendations. You can then examine these recommendations and choose to deploy them. -By default, Datadog Kubernetes Autoscaling uses estimated CPU and memory cost values to show savings opportunities and impact estimates. You can also use Kubernetes Autoscaling alongside [Cloud Cost Management](#idle-cost-and-savings-estimates) to get reporting based on your exact instance type costs. +By default, Datadog Kubernetes Autoscaling uses estimated CPU and memory cost values to show savings opportunities and impact estimates. You can also use Kubernetes Autoscaling alongside [{{< prodname >}}Cloud Cost Management{{< /prodname >}}](#idle-cost-and-savings-estimates) to get reporting based on your exact instance type costs. Automated workload scaling is powered by a `DatadogPodAutoscaler` custom resource that defines scaling behavior on a per-workload level. The Datadog Cluster Agent acts as the controller for this custom resource. @@ -165,11 +165,11 @@ helm upgrade -f datadog-values.yaml datadog/datadog {{< tabs >}} {{% tab "With Cloud Cost Management" %}} -If [Cloud Cost Management][1] is enabled within an org, Datadog Kubernetes Autoscaling shows idle cost and savings estimates based on your exact bill cost of underlying monitored instances. +If [{{< prodname >}}Cloud Cost Management{{< /prodname >}}][1] is enabled within an org, Datadog Kubernetes Autoscaling shows idle cost and savings estimates based on your exact bill cost of underlying monitored instances. See Cloud Cost setup instructions for [AWS][2], [Azure][3], or [Google Cloud][4]. -Cloud Cost Management data enhances Kubernetes Autoscaling, but it is not required. All of Datadog's workload recommendations and autoscaling decisions are valid and functional without Cloud Cost Management. +{{< prodname >}}Cloud Cost Management{{< /prodname >}} data enhances Kubernetes Autoscaling, but it is not required. All of Datadog's workload recommendations and autoscaling decisions are valid and functional without {{< prodname >}}Cloud Cost Management{{< /prodname >}}. [1]: /cloud_cost_management [2]: /cloud_cost_management/aws diff --git a/hugo/content/en/containers/bits_remediation.md b/hugo/content/en/containers/bits_remediation.md index 80d6001a904..668ef31ec4f 100644 --- a/hugo/content/en/containers/bits_remediation.md +++ b/hugo/content/en/containers/bits_remediation.md @@ -29,7 +29,7 @@ You can launch Bits Remediation from multiple locations within Datadog: Any one of these actions opens a side panel with remediation information, including: - An AI-powered explanation for root cause, based on collected telemetry and known patterns -- Recommended next steps, which you may be able to [perform directly from Datadog](#remediate-from-datadog) using [Bits Code][5] +- Recommended next steps, which you may be able to [perform directly from Datadog](#remediate-from-datadog) using [{{< prodname >}}Bits Code{{< /prodname >}}][5] - Related information on an adjustable timeframe: recent deployments, error logs, Kubernetes events, etc., including relevant metrics based on specific issue type {{< img src="containers/remediation/side_panel2.png" alt="Remediation side panel opened for a workload with a CrashLoopBackOff error. Displays a What Happened section with a Bits AI-powered explanation of the error's root cause. Below, a Recommended Next Steps section where the user can inspect the workload manifest. Step-by-step instructions for a suggested fix are also displayed." style="width:80%;" >}} @@ -41,7 +41,7 @@ Any one of these actions opens a side panel with remediation information, includ Automated fixes from Bits Remediation is in Preview. To sign up, click Request Access and complete the form. {{< /callout >}} -If your repositories are [connected to Datadog][4] and an error can be fixed by changing code in one of these connected repositories, then you can use [Bits Code][5] to remediate directly from Datadog. For other problem scenarios, Bits provides a detailed list of remediation steps to follow. +If your repositories are [connected to Datadog][4] and an error can be fixed by changing code in one of these connected repositories, then you can use [{{< prodname >}}Bits Code{{< /prodname >}}][5] to remediate directly from Datadog. For other problem scenarios, Bits provides a detailed list of remediation steps to follow. {{% collapse-content title="Example: Increasing memory limit for a deployment" level="h4" expanded=true id="example-pr" %}} @@ -53,7 +53,7 @@ When a pod is terminated because the memory usage exceeded its limit, you may be 2. Adjust your limit so that it is higher than what your container normally uses. 3. Click {{< ui >}}Fix with Bits AI{{< /ui >}}. 4. On the next page, select the repository where your deployment is defined, and review the proposed changes. Click {{< ui >}}Fix with Bits{{< /ui >}} to create a pull request. -5. You are redirected to a Bits Code [session][3], where you can verify that Bits Code identified the specific configuration file where your memory limits are defined. Click {{< ui >}}Create Pull Request{{< /ui >}} to initiate the creation of the pull request. +5. You are redirected to a {{< prodname >}}Bits Code{{< /prodname >}} [session][3], where you can verify that {{< prodname >}}Bits Code{{< /prodname >}} identified the specific configuration file where your memory limits are defined. Click {{< ui >}}Create Pull Request{{< /ui >}} to initiate the creation of the pull request. 6. Click {{< ui >}}View Pull Request{{< /ui >}} to view the pull request in GitHub. {{% /collapse-content %}} diff --git a/hugo/content/en/containers/datadog_operator/crd_monitor.md b/hugo/content/en/containers/datadog_operator/crd_monitor.md index a5f9bec006c..19973a622e5 100644 --- a/hugo/content/en/containers/datadog_operator/crd_monitor.md +++ b/hugo/content/en/containers/datadog_operator/crd_monitor.md @@ -166,7 +166,7 @@ spec: `groupRetentionDuration` : _string_ -
The time span after which groups with missing data are dropped from the monitor state. The minimum value is one hour, and the maximum value is 72 hours. Example values are: `60m`, `1h`, and `2d`. This option is only available for APM Trace Analytics, Audit Trail, CI, Error Tracking, Event, Logs, and RUM monitors. +
The time span after which groups with missing data are dropped from the monitor state. The minimum value is one hour, and the maximum value is 72 hours. Example values are: `60m`, `1h`, and `2d`. This option is only available for APM Trace Analytics, Audit Trail, CI, {{< prodname >}}Error Tracking{{< /prodname >}}, Event, Logs, and RUM monitors. `groupbySimpleMonitor` : _boolean_ @@ -211,7 +211,7 @@ spec: `onMissingData` : _enum_ -
Controls how groups or monitors are treated if an evaluation does not return any data points. The default option results in different behavior depending on the monitor query type. For monitors using Count queries, an empty monitor evaluation is treated as 0 and is compared to the threshold conditions. For monitors using any query type other than Count, for example Gauge, Measure, or Rate, the monitor shows the last known status. This option is only available for APM Trace Analytics, Audit Trail, CI, Error Tracking, Event, Logs, and RUM monitors. +
Controls how groups or monitors are treated if an evaluation does not return any data points. The default option results in different behavior depending on the monitor query type. For monitors using Count queries, an empty monitor evaluation is treated as 0 and is compared to the threshold conditions. For monitors using any query type other than Count, for example Gauge, Measure, or Rate, the monitor shows the last known status. This option is only available for APM Trace Analytics, Audit Trail, CI, {{< prodname >}}Error Tracking{{< /prodname >}}, Event, Logs, and RUM monitors.
Allowed enum values: `default`, `show_no_data`, `show_and_notify_no_data`, `resolve` `renotifyInterval` diff --git a/hugo/content/en/containers/kubernetes/_index.md b/hugo/content/en/containers/kubernetes/_index.md index a2e45dbe8f2..def6b1ef5d2 100644 --- a/hugo/content/en/containers/kubernetes/_index.md +++ b/hugo/content/en/containers/kubernetes/_index.md @@ -46,7 +46,7 @@ further_reading: You can install the Agent using either the [Datadog Operator][4] or Helm chart by following the [in-app installation guide in Fleet Automation][5]. This guided interface allows you to: - Select your Kubernetes distribution (for example EKS, AKS, or GKE) - Generate helm and kubectl commands with your API key prefilled -- Enable features such as APM, Log Management, tagging and other telemetry through UI-based configuration +- Enable features such as APM, {{< prodname >}}Log Management{{< /prodname >}}, tagging and other telemetry through UI-based configuration {{< img src="agent/basic_agent_usage/agent_install_k8.png" alt="In-app installation steps for the Datadog Agent on Kubernetes." style="width:90%;">}} @@ -74,7 +74,7 @@ For Agent commands, see the [Agent Commands guides][9]. For information on the D {{< nextlink href="/agent/kubernetes/configuration">}}Further Configuration: Collect events, override proxy settings, send custom metrics with DogStatsD, configure container allowlists and blocklists, and reference the full list of available environment variables.{{< /nextlink >}} {{< nextlink href="/agent/kubernetes/distributions">}}Distributions: Review base configurations for major Kubernetes distributions, including AWS Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE), Red Hat OpenShift, Rancher, and Oracle Container Engine for Kubernetes (OKE).{{< /nextlink >}} {{< nextlink href="/agent/kubernetes/apm">}}APM: Set up trace collection: configure the Agent to accept traces, configure your Pods to communicate with the Agent, and configure your application SDKs to emit traces.{{< /nextlink >}} - {{< nextlink href="/agent/kubernetes/appsec">}}App and API Protection: Automatically enable App and API Protection for your Kubernetes ingress proxies and gateways to detect threats and protect APIs at the edge.{{< /nextlink >}} + {{< nextlink href="/agent/kubernetes/appsec">}}{{< prodname >}}App and API Protection{{< /prodname >}}: Automatically enable {{< prodname >}}App and API Protection{{< /prodname >}} for your Kubernetes ingress proxies and gateways to detect threats and protect APIs at the edge.{{< /nextlink >}} {{< nextlink href="/agent/kubernetes/csi">}}CSI Driver: Install and set up Datadog CSI driver, and mount DogStatsD and Trace Agent UDS socket using Datadog CSI volumes.{{< /nextlink >}} {{< nextlink href="/agent/kubernetes/log">}}Log collection: Set up log collection in a Kubernetes environment.{{< /nextlink >}} {{< nextlink href="/agent/kubernetes/tag">}}Tag extraction: Configure the Agent to create and assign tags to all metrics, traces, and logs emitted by a container, Pod, or Node, based on Kubernetes labels or annotations.{{< /nextlink >}} diff --git a/hugo/content/en/containers/kubernetes/appsec.md b/hugo/content/en/containers/kubernetes/appsec.md index a7df3defc58..b2a24339aad 100644 --- a/hugo/content/en/containers/kubernetes/appsec.md +++ b/hugo/content/en/containers/kubernetes/appsec.md @@ -29,19 +29,19 @@ further_reading: text: "Troubleshooting App and API Protection" --- -{{< learning-center-callout header="App and API Protection for Kubernetes is in Preview" btn_title="Join the preview" hide_image="true" btn_url="https://www.datadoghq.com/product-preview/kubernetes-gateway-security-injector/">}} - App and API Protection for Kubernetes automatically configures supported Kubernetes ingress proxies and gateways. Try it today! +{{< learning-center-callout header="{{< prodname >}}App and API Protection{{< /prodname >}} for Kubernetes is in Preview" btn_title="Join the preview" hide_image="true" btn_url="https://www.datadoghq.com/product-preview/kubernetes-gateway-security-injector/">}} + {{< prodname >}}App and API Protection{{< /prodname >}} for Kubernetes automatically configures supported Kubernetes ingress proxies and gateways. Try it today! {{< /learning-center-callout >}} -This page describes how to set up [App and API Protection][11] for Kubernetes to automatically configure supported Kubernetes ingress proxies and gateways to run API discovery, threat detection, and inline blocking at the edge of the infrastructure. +This page describes how to set up [{{< prodname >}}App and API Protection{{< /prodname >}}][11] for Kubernetes to automatically configure supported Kubernetes ingress proxies and gateways to run API discovery, threat detection, and inline blocking at the edge of the infrastructure. ## Overview -App and API Protection for Kubernetes automatically configures supported ingress proxies and gateways in your Kubernetes cluster to enable Application Security monitoring. This eliminates the need for manual proxy configuration and provides API-wide security coverage without modifying individual services or deploying tracers across your application fleet. +{{< prodname >}}App and API Protection{{< /prodname >}} for Kubernetes automatically configures supported ingress proxies and gateways in your Kubernetes cluster to enable Application Security monitoring. This eliminates the need for manual proxy configuration and provides API-wide security coverage without modifying individual services or deploying tracers across your application fleet. ### What performs the automatic configuration? -App and API Protection for Kubernetes uses a Kubernetes controller (running in the Datadog Cluster Agent) that: +{{< prodname >}}App and API Protection{{< /prodname >}} for Kubernetes uses a Kubernetes controller (running in the Datadog Cluster Agent) that: - **Automatically detects** supported proxies in your cluster - **Configures proxies** to route traffic through an external Application Security processor - **Enables threat detection** for all traffic passing through your ingress layer @@ -69,7 +69,7 @@ For the list of supported proxies and proxy-specific setup steps, see the [setup ## Prerequisites -Before enabling App and API Protection for Kubernetes, verify that you have: +Before enabling {{< prodname >}}App and API Protection{{< /prodname >}} for Kubernetes, verify that you have: - A running Kubernetes cluster (version 1.20 or later) - [Datadog Cluster Agent 7.80.2 or later][1] installed and configured in your cluster @@ -78,7 +78,7 @@ Before enabling App and API Protection for Kubernetes, verify that you have: ## How it works -App and API Protection for Kubernetes supports two deployment modes: +{{< prodname >}}App and API Protection{{< /prodname >}} for Kubernetes supports two deployment modes: - **Sidecar mode** (default): The Application Security processor runs as a sidecar container injected directly into each gateway pod. No separate processor deployment is needed, and the processor scales automatically with your gateway pods. - **External mode**: A single, centralized Application Security processor deployment serves all gateway traffic in your cluster. Use this mode when you want to manage one shared processor for the whole cluster. @@ -361,7 +361,7 @@ The Datadog Cluster Agent produces events for each operation that results in fai #### Test traffic processing -Send requests through your gateway and verify they appear in the Datadog [App and API Protection][5] UI: +Send requests through your gateway and verify they appear in the Datadog [{{< prodname >}}App and API Protection{{< /prodname >}}][5] UI: 1. Navigate to [Security > Application Security][5] in Datadog. 2. Look for security signals from your gateway traffic. @@ -453,7 +453,7 @@ spec: Resources with the `appsec.datadoghq.com/enabled: "false"` label are ignored. This is useful when you want to: - Manually configure specific gateways -- Temporarily disable App and API Protection for testing +- Temporarily disable {{< prodname >}}App and API Protection{{< /prodname >}} for testing - Exclude certain gateways from security monitoring **Note**: By default, all resources are included. Only resources with the label explicitly set to `"false"` are excluded. diff --git a/hugo/content/en/containers/kubernetes/installation.md b/hugo/content/en/containers/kubernetes/installation.md index 7e6b85cdb8d..33da0dafbb7 100644 --- a/hugo/content/en/containers/kubernetes/installation.md +++ b/hugo/content/en/containers/kubernetes/installation.md @@ -299,7 +299,7 @@ helm uninstall datadog-agent ### Monitor your infrastructure in Datadog Use the [Containers][13] page for visibility into your container infrastructure, with resource metrics and faceted search. For information on how to use the Containers page, see [Containers View][14]. -Use the [Container Images][18] page for insights into every image used in your environment. This page also displays vulnerabilities found in your container images from [Cloud Security][19]. For information on how to use the Container Images page, see the [Containers Images View][20]. +Use the [Container Images][18] page for insights into every image used in your environment. This page also displays vulnerabilities found in your container images from [{{< prodname >}}Cloud Security{{< /prodname >}}][19]. For information on how to use the Container Images page, see the [Containers Images View][20]. The [Kubernetes][21] section features an overview of all your Kubernetes resources. [Orchestrator Explorer][22] allows you to monitor the state of pods, deployments, and other Kubernetes concepts in a specific namespace or availability zone, view resource specifications for failed pods within a deployment, correlate node activity with related logs, and more. The [Resource Utilization][23] page provides insights into how your Kubernetes workloads are using your computing resources across your infrastructure. For information on how to use these pages, see [Orchestrator Explorer][24] and [Kubernetes Resource Utilization][25]. diff --git a/hugo/content/en/containers/monitoring/_index.md b/hugo/content/en/containers/monitoring/_index.md index ff3fcf43040..87a4b733baa 100644 --- a/hugo/content/en/containers/monitoring/_index.md +++ b/hugo/content/en/containers/monitoring/_index.md @@ -15,7 +15,7 @@ In Datadog, [**Containers Explorer**][2] provides real-time visibility into all {{< img src="security/vulnerabilities/container_images.png" alt="The container images view highlighting vulnerabilities and container column sort feature" width="80%">}} -[**Container Images Explorer**][4] provides insights into every image used in your environment to help you assess your images' deployment footprint, including [Cloud Security][5] vulnerabilities. To configure this page, read the [Container Images Explorer documentation][6]. +[**Container Images Explorer**][4] provides insights into every image used in your environment to help you assess your images' deployment footprint, including [{{< prodname >}}Cloud Security{{< /prodname >}}][5] vulnerabilities. To configure this page, read the [Container Images Explorer documentation][6]. ## Explore Kubernetes resources @@ -33,7 +33,7 @@ Select the [**Autoscaling**][11] tab in the Kubernetes section to view scaling r ### Kubernetes Remediation -Select the [**Remediation**][13] tab in the Kubernetes section to investigate and remediate errors with [Bits Code][14]. For more information, read the [Bits Remediation documentation][15]. +Select the [**Remediation**][13] tab in the Kubernetes section to investigate and remediate errors with [{{< prodname >}}Bits Code{{< /prodname >}}][14]. For more information, read the [Bits Remediation documentation][15]. {{< callout url="https://www.datadoghq.com/product-preview/kubernetes-remediation/" btn_hidden="false" header="Join the Preview!">}} diff --git a/hugo/content/en/containers/monitoring/container_images.md b/hugo/content/en/containers/monitoring/container_images.md index d1cfc5bb62f..c79afe2efe9 100644 --- a/hugo/content/en/containers/monitoring/container_images.md +++ b/hugo/content/en/containers/monitoring/container_images.md @@ -20,7 +20,7 @@ further_reading: {{< img src="security/vulnerabilities/container_images.png" alt="The container images view highlighting vulnerabilities and container column sort feature" width="100%">}} -In Datadog, the [Container Images Explorer][1] provides insights into every image used in your environment. You can also view [Cloud Security][2] vulnerabilities in your container images, and track these vulnerabilities to specific layers. +In Datadog, the [Container Images Explorer][1] provides insights into every image used in your environment. You can also view [{{< prodname >}}Cloud Security{{< /prodname >}}][2] vulnerabilities in your container images, and track these vulnerabilities to specific layers. Select the [Trends tab][3] for high-level insights across all of your images in your containerized infrastructure. Container image trends metrics can help you answer key questions about your security posture and deployment footprint over the span of weeks and months. diff --git a/hugo/content/en/continuous_integration/_index.md b/hugo/content/en/continuous_integration/_index.md index c65296fc450..2e7b8a43fcd 100644 --- a/hugo/content/en/continuous_integration/_index.md +++ b/hugo/content/en/continuous_integration/_index.md @@ -51,7 +51,7 @@ cascade: tags: ['ci/cd', 'continuous integration'] --- -{{< callout url=# btn_hidden="true" header="Try the new CI/CD Optimization experience!">}}[CI/CD Optimization][1] combines Datadog's CI Visibility and Test Optimization experiences into one unified interface. Click {{< ui >}}Try It Now{{< /ui >}} at the top of any page in CI Visibility or Test Optimization, and switch back to the original UI at any time. +{{< callout url=# btn_hidden="true" header="Try the new CI/CD Optimization experience!">}}[CI/CD Optimization][1] combines Datadog's CI Visibility and {{< prodname >}}Test Optimization{{< /prodname >}} experiences into one unified interface. Click {{< ui >}}Try It Now{{< /ui >}} at the top of any page in CI Visibility or {{< prodname >}}Test Optimization{{< /prodname >}}, and switch back to the original UI at any time. [1]: /continuous_integration/cicd_optimization/ {{< /callout >}} diff --git a/hugo/content/en/continuous_integration/cicd_optimization.md b/hugo/content/en/continuous_integration/cicd_optimization.md index 3469b4532db..06478a809cf 100644 --- a/hugo/content/en/continuous_integration/cicd_optimization.md +++ b/hugo/content/en/continuous_integration/cicd_optimization.md @@ -9,11 +9,11 @@ further_reading: text: "Test Optimization" --- -CI/CD Optimization combines Datadog's [CI Visibility][1] and [Test Optimization][2] experiences into one unified interface. It provides a single place to understand, monitor, and improve your entire CI/CD ecosystem, from pipeline executions to individual test runs. +CI/CD Optimization combines Datadog's [CI Visibility][1] and [{{< prodname >}}Test Optimization{{< /prodname >}}][2] experiences into one unified interface. It provides a single place to understand, monitor, and improve your entire CI/CD ecosystem, from pipeline executions to individual test runs. -To enable the new experience, click {{< ui >}}Try It Now{{< /ui >}} at the top of any page in CI Visibility or Test Optimization. You can return to the previous UI at any time by clicking {{< ui >}}Switch Back{{< /ui >}}. +To enable the new experience, click {{< ui >}}Try It Now{{< /ui >}} at the top of any page in CI Visibility or {{< prodname >}}Test Optimization{{< /prodname >}}. You can return to the previous UI at any time by clicking {{< ui >}}Switch Back{{< /ui >}}. -This page provides an overview of CI/CD Optimization's key features, some of which retain original functionality of CI Visibility and Test Optimization. Follow the links to legacy documentation for details on using each product within the unified UI. +This page provides an overview of CI/CD Optimization's key features, some of which retain original functionality of CI Visibility and {{< prodname >}}Test Optimization{{< /prodname >}}. Follow the links to legacy documentation for details on using each product within the unified UI. ## CI/CD Health diff --git a/hugo/content/en/continuous_integration/pipelines/awscodepipeline.md b/hugo/content/en/continuous_integration/pipelines/awscodepipeline.md index 13b1c579cec..6cdd6cdbbc6 100644 --- a/hugo/content/en/continuous_integration/pipelines/awscodepipeline.md +++ b/hugo/content/en/continuous_integration/pipelines/awscodepipeline.md @@ -120,7 +120,7 @@ The event pattern sets up the integration only for the `first-pipeline` and `sec ### Correlate pipelines with tests -If you are using [Test Optimization][8] and your pipeline contains one or more [AWS CodeBuild][9] actions to execute tests, you can correlate your tests with the related pipeline inside Datadog Pipeline Visibility. For instructions, refer to [Add the pipeline execution ID](#add-the-pipeline-execution-id-as-an-environment-variable). +If you are using [{{< prodname >}}Test Optimization{{< /prodname >}}][8] and your pipeline contains one or more [AWS CodeBuild][9] actions to execute tests, you can correlate your tests with the related pipeline inside Datadog Pipeline Visibility. For instructions, refer to [Add the pipeline execution ID](#add-the-pipeline-execution-id-as-an-environment-variable). ### Collect job logs diff --git a/hugo/content/en/continuous_integration/pipelines/azure.md b/hugo/content/en/continuous_integration/pipelines/azure.md index 6d6e5d09f28..5b585b798bd 100644 --- a/hugo/content/en/continuous_integration/pipelines/azure.md +++ b/hugo/content/en/continuous_integration/pipelines/azure.md @@ -168,7 +168,7 @@ To enable log collection for Azure DevOps pipelines: 2. In Datadog, open [**CI/CD Optimization** > **Settings** > **Azure DevOps**][23]. 3. Enable log pulling for Azure DevOps. -Logs are billed separately from CI Visibility. Log retention, exclusion, and indexes are configured in [Log Management][18]. Logs for Azure jobs can be identified by the `datadog.product:cipipeline` and `source:azurepipelines` tags. +Logs are billed separately from CI Visibility. Log retention, exclusion, and indexes are configured in [{{< prodname >}}Log Management{{< /prodname >}}][18]. Logs for Azure jobs can be identified by the `datadog.product:cipipeline` and `source:azurepipelines` tags. ### CI jobs failure analysis diff --git a/hugo/content/en/continuous_integration/pipelines/buildkite.md b/hugo/content/en/continuous_integration/pipelines/buildkite.md index e98faf34d7f..2df51ff2f7c 100644 --- a/hugo/content/en/continuous_integration/pipelines/buildkite.md +++ b/hugo/content/en/continuous_integration/pipelines/buildkite.md @@ -61,7 +61,7 @@ To set up the Datadog integration for [Buildkite][1]: The Datadog Buildkite integration collects logs from your finished Buildkite jobs and forwards them to Datadog. To install and configure this integration, see the [Buildkite integration documentation][19]. -Datadog bills logs separately from CI Visibility. Configure log retention, exclusion filters, and indexes in [Log Management][21]. To scope these rules to Buildkite logs, filter on the `datadog.product:cipipeline` and `source:buildkite` tags. +Datadog bills logs separately from CI Visibility. Configure log retention, exclusion filters, and indexes in [{{< prodname >}}Log Management{{< /prodname >}}][21]. To scope these rules to Buildkite logs, filter on the `datadog.product:cipipeline` and `source:buildkite` tags. ## Advanced configuration diff --git a/hugo/content/en/continuous_integration/pipelines/circleci.md b/hugo/content/en/continuous_integration/pipelines/circleci.md index e5cf91c45ab..88ec71b4db2 100644 --- a/hugo/content/en/continuous_integration/pipelines/circleci.md +++ b/hugo/content/en/continuous_integration/pipelines/circleci.md @@ -107,7 +107,7 @@ To display and filter the teams associated with your pipelines, add `team:}}Log Management{{< /prodname >}}][16]. Logs for CircleCI jobs can be identified by the `datadog.product:cipipeline` and `source:circleci` tags. ## Visualize pipeline data in Datadog diff --git a/hugo/content/en/continuous_integration/pipelines/github.md b/hugo/content/en/continuous_integration/pipelines/github.md index 8cb17e33fb6..13c11df763e 100644 --- a/hugo/content/en/continuous_integration/pipelines/github.md +++ b/hugo/content/en/continuous_integration/pipelines/github.md @@ -104,7 +104,7 @@ To enable job logs collection: Immediately after toggling logs collection, workflow job logs are forwarded to Datadog Log Management. Log files larger than 1 GiB are truncated. -Logs are billed separately from CI Visibility. Log retention, exclusion, and indexes are configured in [Log Management][16]. Logs for GitHub jobs can be identified by the `datadog.product:cipipeline` and `source:github` tags. +Logs are billed separately from CI Visibility. Log retention, exclusion, and indexes are configured in [{{< prodname >}}Log Management{{< /prodname >}}][16]. Logs for GitHub jobs can be identified by the `datadog.product:cipipeline` and `source:github` tags. ### Correlate infrastructure metrics to jobs diff --git a/hugo/content/en/continuous_integration/pipelines/gitlab.md b/hugo/content/en/continuous_integration/pipelines/gitlab.md index dc827d80f26..580cef8b292 100644 --- a/hugo/content/en/continuous_integration/pipelines/gitlab.md +++ b/hugo/content/en/continuous_integration/pipelines/gitlab.md @@ -375,7 +375,7 @@ The following GitLab versions support collecting job logs: * GitLab >= 15.3 (self-hosted) only if you are using [object storage to store job logs][7] * GitLab >= 14.8 (self-hosted) by enabling the `datadog_integration_logs_collection` feature flag -Job logs are collected in [Log Management][9] and are automatically correlated with the GitLab pipeline in CI Visibility. Log files larger than one GiB are truncated. +Job logs are collected in [{{< prodname >}}Log Management{{< /prodname >}}][9] and are automatically correlated with the GitLab pipeline in CI Visibility. Log files larger than one GiB are truncated. To enable collection of job logs: @@ -408,7 +408,7 @@ The }} - {{< nextlink href="/continuous_testing/guide/view-continuous-testing-test-runs-in-test-optimization" >}}View Continuous Testing Test Runs in Test Optimization{{< /nextlink >}} + {{< nextlink href="/continuous_testing/guide/view-continuous-testing-test-runs-in-test-optimization" >}}View Continuous Testing Test Runs in {{< prodname >}}Test Optimization{{< /prodname >}}{{< /nextlink >}} {{< /whatsnext >}} diff --git a/hugo/content/en/continuous_testing/guide/view-continuous-testing-test-runs-in-test-optimization.md b/hugo/content/en/continuous_testing/guide/view-continuous-testing-test-runs-in-test-optimization.md index be2e83bcfcb..d347baa9275 100644 --- a/hugo/content/en/continuous_testing/guide/view-continuous-testing-test-runs-in-test-optimization.md +++ b/hugo/content/en/continuous_testing/guide/view-continuous-testing-test-runs-in-test-optimization.md @@ -18,18 +18,18 @@ further_reading: ## Overview -[Continuous Testing][1] enables you to run [Synthetic Monitoring tests][2] within your CI/CD pipelines, automating software testing throughout your product's lifecycle. [Test Optimization][3] provides a test-first view into your CI health by displaying important metrics and results from your tests. +[Continuous Testing][1] enables you to run [Synthetic Monitoring tests][2] within your CI/CD pipelines, automating software testing throughout your product's lifecycle. [{{< prodname >}}Test Optimization{{< /prodname >}}][3] provides a test-first view into your CI health by displaying important metrics and results from your tests. -You can use Test Optimization to view Continuous Testing test runs, giving you a unified overview of metrics and results from all your test frameworks, including Synthetic Monitoring, in one place. +You can use {{< prodname >}}Test Optimization{{< /prodname >}} to view Continuous Testing test runs, giving you a unified overview of metrics and results from all your test frameworks, including Synthetic Monitoring, in one place. ## View Continuous Testing test runs in Test Optimization -1. Navigate to the [Test Runs][4] Explorer in Test Optimization. +1. Navigate to the [Test Runs][4] Explorer in {{< prodname >}}Test Optimization{{< /prodname >}}. 2. Filter the {{< ui >}}Test Framework{{< /ui >}} facet to `synthetics`: {{< img src="continuous_testing/guide/view-continuous-testing-test-runs-in-test-optimization/test_optimization_test_run_explorer_3.png" alt="Test Optimization Test Runs explorer, filtered to synthetics framework facet" style="width:100%" >}} -Use this feature to search, filter, and analyze Continuous Testing test runs, combining both Test Optimization and Continuous Testing metadata in a single view. +Use this feature to search, filter, and analyze Continuous Testing test runs, combining both {{< prodname >}}Test Optimization{{< /prodname >}} and Continuous Testing metadata in a single view. For example: @@ -49,11 +49,11 @@ Use these tabs on the side panel: ## Viewing test runs -From the Test Optimization Explorer, you can jump to a test run in the Synthetic Monitoring page. Click {{< ui >}}View in Synthetics{{< /ui >}} from the details panel of a test run on the Test Optimization page. +From the Test Optimization Explorer, you can jump to a test run in the Synthetic Monitoring page. Click {{< ui >}}View in {{< prodname >}}Synthetics{{< /prodname >}}{{< /ui >}} from the details panel of a test run on the {{< prodname >}}Test Optimization{{< /prodname >}} page. {{< img src="continuous_testing/guide/view-continuous-testing-test-runs-in-test-optimization/view_in_synthetics.png" alt="Test Optimization Test Runs details view, highlighting View in Synthetics button" style="width:100%" >}} -Similarly, from the Synthetic Monitoring page, you jump to a test run in the Test Optimization Explorer. Click {{< ui >}}View in Test Optimization{{< /ui >}} from the details panel of a test run on the Synthetic Monitoring page: +Similarly, from the Synthetic Monitoring page, you jump to a test run in the Test Optimization Explorer. Click {{< ui >}}View in {{< prodname >}}Test Optimization{{< /prodname >}}{{< /ui >}} from the details panel of a test run on the Synthetic Monitoring page: {{< img src="continuous_testing/guide/view-continuous-testing-test-runs-in-test-optimization/continuous_testing_test_run_detail.png" alt="Synthetics Test Runs details view, highlighting View in Test Optimization button" style="width:100%" >}} diff --git a/hugo/content/en/continuous_testing/troubleshooting.md b/hugo/content/en/continuous_testing/troubleshooting.md index 74f2c739f19..352cb380197 100644 --- a/hugo/content/en/continuous_testing/troubleshooting.md +++ b/hugo/content/en/continuous_testing/troubleshooting.md @@ -47,7 +47,7 @@ The first thing to check is which failure mode flags you are passing in your [gl ## Synthetics monitors -The CI does not trigger Synthetics monitors or incorporate them into monitor evaluations; however, failing runs will result in the CI showing a red status. +The CI does not trigger {{< prodname >}}Synthetics{{< /prodname >}} monitors or incorporate them into monitor evaluations; however, failing runs will result in the CI showing a red status. ## Further reading diff --git a/hugo/content/en/coterm/install.md b/hugo/content/en/coterm/install.md index 18e60a6f644..547da3a069f 100644 --- a/hugo/content/en/coterm/install.md +++ b/hugo/content/en/coterm/install.md @@ -52,7 +52,7 @@ During initialization, you can choose one of the following ways to authorize CoT - {{< ui >}}API Key + App Key{{< /ui >}}: Prompts you to set your [Datadog API key][1] and [application key][2] in `~/.ddcoterm/config.yaml`. - {{< ui >}}API Key Only{{< /ui >}}: Prompts you to set your Datadog API key in `~/.ddcoterm/config.yaml`. -
If you select the API Key Only option, you cannot require approvals with Case Management.
+
If you select the API Key Only option, you cannot require approvals with {{< prodname >}}Case Management{{< /prodname >}}.
## Configure your CoTerm settings diff --git a/hugo/content/en/coterm/usage.md b/hugo/content/en/coterm/usage.md index 995b4664716..8045bd8c6d6 100644 --- a/hugo/content/en/coterm/usage.md +++ b/hugo/content/en/coterm/usage.md @@ -85,7 +85,7 @@ With this configuration, CoTerm intercepts any `kubectl scale` command without a ### Require approval for commands -For even more dangerous commands, CoTerm can require explicit approval by another team member (through Case Management) before running the command. +For even more dangerous commands, CoTerm can require explicit approval by another team member (through {{< prodname >}}Case Management{{< /prodname >}}) before running the command. 1. Create a shim for your command: `ddcoterm shim create kubectl` @@ -105,7 +105,7 @@ process_config: actions: ["record", "logs", "process_info", "approval"] {{< /code-block >}} -With this configuration, when you run a `kubectl scale --context prod` command, CoTerm creates an approval request in [Case Management][3]. If you opt to associate the approval request with an active [incident][5], other incident responders are automatically added as approvers. After this request is approved, your command executes. You can also configure [case automation rules][8] to trigger workflows based on approval requests. +With this configuration, when you run a `kubectl scale --context prod` command, CoTerm creates an approval request in [{{< prodname >}}Case Management{{< /prodname >}}][3]. If you opt to associate the approval request with an active [incident][5], other incident responders are automatically added as approvers. After this request is approved, your command executes. You can also configure [case automation rules][8] to trigger workflows based on approval requests. #### Manually require approval diff --git a/hugo/content/en/dashboards/change_overlays/_index.md b/hugo/content/en/dashboards/change_overlays/_index.md index 0e2b0658dde..8032c9e5583 100644 --- a/hugo/content/en/dashboards/change_overlays/_index.md +++ b/hugo/content/en/dashboards/change_overlays/_index.md @@ -28,7 +28,7 @@ As teams iterate, deploy code, and make changes to their applications and servic ## Overlay changes on graphs -To get started, click {{< ui >}}Show Overlays{{< /ui >}} in the upper right corner of your dashboard. Now you can enable the [Change Tracking][16] timeline and change overlays on timeseries widgets. +To get started, click {{< ui >}}Show Overlays{{< /ui >}} in the upper right corner of your dashboard. Now you can enable the [{{< prodname >}}Change Tracking{{< /prodname >}}][16] timeline and change overlays on timeseries widgets. {{< img src="dashboards/change_overlays/show_overlays_button.png" alt="Overlays button on dashboard header" style="width:100%;">}} diff --git a/hugo/content/en/dashboards/widgets/_index.md b/hugo/content/en/dashboards/widgets/_index.md index ba22332c042..fca4d020c48 100644 --- a/hugo/content/en/dashboards/widgets/_index.md +++ b/hugo/content/en/dashboards/widgets/_index.md @@ -65,7 +65,7 @@ Widgets can visualize data from multiple Datadog sources including: ## Common use cases -{{% collapse-content title="Infrastructure Monitoring" level="h4" expanded=false %}} +{{% collapse-content title="{{< prodname >}}Infrastructure Monitoring{{< /prodname >}}" level="h4" expanded=false %}} - Use **Timeseries** widgets for CPU, memory, and network metrics over time - Use **Hostmap** widgets to visualize resource usage across your infrastructure - Use **Top List** widgets to identify the most resource-intensive hosts or services diff --git a/hugo/content/en/dashboards/widgets/configuration/_index.md b/hugo/content/en/dashboards/widgets/configuration/_index.md index 0c758ef41d2..2943aece95c 100644 --- a/hugo/content/en/dashboards/widgets/configuration/_index.md +++ b/hugo/content/en/dashboards/widgets/configuration/_index.md @@ -56,7 +56,7 @@ Supported data sources for joins include (but are not limited to): - Static Analysis - CI Tests - Compliance Findings -- Product Analytics +- {{< prodname >}}Product Analytics{{< /prodname >}} - Reference Tables Using joins and data previews makes it easier to select the right fields and enrich your graphs with relevant details, improving the quality and usefulness of your dashboards. diff --git a/hugo/content/en/dashboards/widgets/list.md b/hugo/content/en/dashboards/widgets/list.md index b1a26f84404..3d6c8ee19cd 100644 --- a/hugo/content/en/dashboards/widgets/list.md +++ b/hugo/content/en/dashboards/widgets/list.md @@ -69,7 +69,7 @@ Data sources marked _(Preview)_ are in Preview and might not be available in you | [Watchdog Alerts](#spans-and-watchdog-alerts) | Alerts surfaced by Watchdog. | None | | [Workload Protection Agent](#workload-protection-agent-preview) _(Preview)_ | Workload Protection events from the Datadog Agent. | Workload Protection | -**Note:** The **Recommendations** data source displays Cloud Cost Management recommendations only. APM recommendations are not available as a List widget data source. If Cloud Cost Management is not configured for your organization, the widget displays a `Not Accessible` message. This indicates that the data source requires Cloud Cost Management, rather than that you lack permissions. +**Note:** The **Recommendations** data source displays {{< prodname >}}Cloud Cost Management{{< /prodname >}} recommendations only. APM recommendations are not available as a List widget data source. If Cloud Cost Management is not configured for your organization, the widget displays a `Not Accessible` message. This indicates that the data source requires {{< prodname >}}Cloud Cost Management{{< /prodname >}}, rather than that you lack permissions. ### Options @@ -97,7 +97,7 @@ Sort by (ascending or descending): Select a **Level** to display: Pipeline, Stage, Job, Step, or Custom. {{% /collapse-content %}} -{{% collapse-content title="Data Observability (Preview)" level="h4" id="data-observability-preview" expanded=false %}} +{{% collapse-content title="{{< prodname >}}Data Observability{{< /prodname >}} (Preview)" level="h4" id="data-observability-preview" expanded=false %}} Select an entity type (database table or database column). The available columns and sort options depend on the entity type. {{% /collapse-content %}} @@ -176,7 +176,7 @@ For these data sources, you can: - Filter the rows with a search query. {{% /collapse-content %}} -{{% collapse-content title="On-Call" level="h4" id="on-call" expanded=false %}} +{{% collapse-content title="{{< prodname >}}On-Call{{< /prodname >}}" level="h4" id="on-call" expanded=false %}} Select a **Team**, and optionally add **Tags** to filter the events shown. {{% /collapse-content %}} diff --git a/hugo/content/en/dashboards/widgets/log_stream.md b/hugo/content/en/dashboards/widgets/log_stream.md index c2280323ebc..5fb8bf99e8b 100644 --- a/hugo/content/en/dashboards/widgets/log_stream.md +++ b/hugo/content/en/dashboards/widgets/log_stream.md @@ -6,4 +6,4 @@ aliases: - /graphing/widgets/log_stream/ --- -
View the Log Management stream through the List widget.
+
View the {{< prodname >}}Log Management{{< /prodname >}} stream through the List widget.
diff --git a/hugo/content/en/dashboards/widgets/point_plot.md b/hugo/content/en/dashboards/widgets/point_plot.md index d4cb23f3442..bfac8101c0d 100644 --- a/hugo/content/en/dashboards/widgets/point_plot.md +++ b/hugo/content/en/dashboards/widgets/point_plot.md @@ -18,7 +18,7 @@ further_reading: A point plot displays one dot per individual event over time, giving you an unaggregated view of your data. Unlike a [Timeseries widget][1], which visualizes trends as averaged or aggregated lines, a point plot surfaces the raw underlying datapoints. Use it to catch the single slow request hidden in an otherwise healthy p95, identify which specific host or service is the outlier, and click directly into that event to investigate. -Point plots are already available in APM Traces, Database Monitoring, and Agent Observability explorers. This widget lets you bring that same view into your own dashboards. +Point plots are already available in APM Traces, {{< prodname >}}Database Monitoring{{< /prodname >}}, and {{< prodname >}}Agent Observability{{< /prodname >}} explorers. This widget lets you bring that same view into your own dashboards. {{< img src="dashboards/widgets/point_plot/point_plot.png" alt="A Point Plot widget showing individual span latency events over time with outliers visible" style="width:100%;" >}} @@ -26,7 +26,7 @@ Point plots are already available in APM Traces, Database Monitoring, and Agent ### Configuration -1. Choose a data source. Supported sources include Logs, RUM, Traces, Spans, Database Monitoring, and Agent Observability. +1. Choose a data source. Supported sources include Logs, RUM, Traces, Spans, {{< prodname >}}Database Monitoring{{< /prodname >}}, and {{< prodname >}}Agent Observability{{< /prodname >}}. 2. Define a query to filter to the events you want to plot. 3. Choose the attribute or measure to display on the y-axis (for example, `duration` for latency or `error_rate` for error tracking). 4. Optional: group events by a tag or attribute (for example, `service`, `host`, or `env`) to color-code dots by group. diff --git a/hugo/content/en/dashboards/widgets/retention.md b/hugo/content/en/dashboards/widgets/retention.md index ebaabc6b862..fe62d830dba 100644 --- a/hugo/content/en/dashboards/widgets/retention.md +++ b/hugo/content/en/dashboards/widgets/retention.md @@ -18,7 +18,7 @@ The Retention widget is not available in the Dat {{% /site-region %}} {{< callout url="https://www.datadoghq.com/product-preview/product-analytics/" header="false" >}} -The Retention widget is available in Preview for Product Analytics customers. To request access, complete the form. +The Retention widget is available in Preview for {{< prodname >}}Product Analytics{{< /prodname >}} customers. To request access, complete the form. {{< /callout >}} {{< img src="/dashboards/widgets/retention/retention_widget_graph.png" alt="Graph visualization of the retention widget" style="width:100%;" >}} diff --git a/hugo/content/en/dashboards/widgets/sankey.md b/hugo/content/en/dashboards/widgets/sankey.md index 2f1f9b0cc55..199c1e209a5 100644 --- a/hugo/content/en/dashboards/widgets/sankey.md +++ b/hugo/content/en/dashboards/widgets/sankey.md @@ -16,7 +16,7 @@ The Sankey widget is not available in the selected }} -The Sankey widget shows user flow, movement, or change from one application state to another. This widget is available for Product Analytics. +The Sankey widget shows user flow, movement, or change from one application state to another. This widget is available for {{< prodname >}}Product Analytics{{< /prodname >}}. ## Setup diff --git a/hugo/content/en/dashboards/widgets/scatter_plot.md b/hugo/content/en/dashboards/widgets/scatter_plot.md index 8b14a863a44..e3fca4c0255 100644 --- a/hugo/content/en/dashboards/widgets/scatter_plot.md +++ b/hugo/content/en/dashboards/widgets/scatter_plot.md @@ -43,7 +43,7 @@ You can plot unaggregated data from the following sources: - Logs - RUM - LLM Observability -- Product Analytics +- {{< prodname >}}Product Analytics{{< /prodname >}} - Spans - Audit Trail - Events diff --git a/hugo/content/en/data_observability/_index.md b/hugo/content/en/data_observability/_index.md index 50e79a7403c..069feae0868 100644 --- a/hugo/content/en/data_observability/_index.md +++ b/hugo/content/en/data_observability/_index.md @@ -11,7 +11,7 @@ further_reading: --- ## Overview -Data Observability (DO) helps data teams improve the reliability of data for analytics and AI applications and optimize the performance and costs of data pipelines. By unifying quality and jobs monitoring from production to consumption, teams can detect and remediate issues faster while optimizing cost and performance. +{{< prodname >}}Data Observability{{< /prodname >}} (DO) helps data teams improve the reliability of data for analytics and AI applications and optimize the performance and costs of data pipelines. By unifying quality and jobs monitoring from production to consumption, teams can detect and remediate issues faster while optimizing cost and performance. {{< img src="data_observability/do_suite_root_cause_analysis-1.png" alt="Datadog Data Observability end-to-end lineage with Spark job traces." style="width:100%;" >}} diff --git a/hugo/content/en/data_observability/integration_overhead.md b/hugo/content/en/data_observability/integration_overhead.md index b32315c6eea..31a29d904e3 100644 --- a/hugo/content/en/data_observability/integration_overhead.md +++ b/hugo/content/en/data_observability/integration_overhead.md @@ -21,7 +21,7 @@ further_reading: ## Overview -Data Observability monitors your data through two products, each with a different overhead profile: +{{< prodname >}}Data Observability{{< /prodname >}} 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. @@ -30,7 +30,7 @@ This page describes both overhead sources and how to control them. Actual cost d ## 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. +A Data Observability monitor evaluates its metric on a fixed schedule that you choose: **hourly** or **daily**. Each time a monitor runs, {{< prodname >}}Data Observability{{< /prodname >}} 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" %}} @@ -72,7 +72,7 @@ Warehouse compute consumed by Quality Monitoring scales with: - **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. +{{< prodname >}}Data Observability{{< /prodname >}} 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 diff --git a/hugo/content/en/data_observability/jobs_monitoring/_index.md b/hugo/content/en/data_observability/jobs_monitoring/_index.md index 1f25fa2a0b5..7d433f3c5f3 100644 --- a/hugo/content/en/data_observability/jobs_monitoring/_index.md +++ b/hugo/content/en/data_observability/jobs_monitoring/_index.md @@ -20,7 +20,7 @@ further_reading: {{< img src="data_jobs/overview_052026.png" alt="Datadog Data Observability: Jobs Monitoring overview page" style="width:100%;" >}} -Data Observability: Jobs Monitoring provides visibility into the performance, reliability, and cost efficiency of your data processing jobs, along with the underlying infrastructure. Data Observability: Jobs Monitoring enables you to: +{{< prodname >}}Data Observability{{< /prodname >}}: Jobs Monitoring provides visibility into the performance, reliability, and cost efficiency of your data processing jobs, along with the underlying infrastructure. {{< prodname >}}Data Observability{{< /prodname >}}: Jobs Monitoring enables you to: - Track the health and performance of data processing jobs across your accounts and workspaces. See which take up the most compute resources or have inefficiencies. - Receive an alert when a job fails—or when a job is taking too long to complete. @@ -31,7 +31,7 @@ Data Observability: Jobs Monitoring provides visibility into the performance, re ## Setup -Data Observability: Jobs Monitoring supports multiple job technologies. To get started, select your technology and follow the installation instructions: +{{< prodname >}}Data Observability{{< /prodname >}}: Jobs Monitoring supports multiple job technologies. To get started, select your technology and follow the installation instructions: {{< card-grid >}} {{< image-card href="/data_observability/jobs_monitoring/databricks/" src="integrations_logos/databricks.png" alt="Databricks" >}} @@ -41,7 +41,7 @@ Data Observability: Jobs Monitoring supports multiple job technologies. To get s {{< image-card href="/data_observability/jobs_monitoring/azure_data_factory/" src="integrations_logos/azure_data_factory.png" alt="Azure Data Factory" >}} {{< /card-grid >}} -Data Observability: Jobs Monitoring also supports Apache Spark jobs on the following platforms: +{{< prodname >}}Data Observability{{< /prodname >}}: Jobs Monitoring also supports Apache Spark jobs on the following platforms: {{< card-grid >}} {{< image-card href="/data_observability/jobs_monitoring/kubernetes/" src="integrations_logos/kubernetes.png" alt="Kubernetes" >}} @@ -71,13 +71,13 @@ Clicking on a run opens a side panel with details of how much time was spent on On the {{< ui >}}Infrastructure{{< /ui >}} tab, you can correlate the execution to infrastructure metrics. -{{< img src="data_jobs/djm_run_infra_062024.png" alt="Data Observability: Jobs Monitoring > Run panel, Infrastructure tab" style="width:100%;" >}} +{{< img src="data_jobs/djm_run_infra_062024.png" alt="{{< prodname >}}Data Observability{{< /prodname >}}: Jobs Monitoring > Run panel, Infrastructure tab" style="width:100%;" >}} For a failed run, look at the {{< ui >}}Errors{{< /ui >}} tab to see the stack trace, which can help you determine where and how this failure occurred. To determine why a stage is taking a long time to complete, you can use the {{< ui >}}Spark Task Metrics{{< /ui >}} tab to view task-level metrics for a specific Spark stage, so that you can identify data skew. See the distribution of time spent and data consumed by different tasks. -{{< img src="data_jobs/djm_task_metrics.png" alt="Data Observability: Jobs Monitoring > Run panel, Spark Task Metrics tab" style="width:100%;" >}} +{{< img src="data_jobs/djm_task_metrics.png" alt="{{< prodname >}}Data Observability{{< /prodname >}}: Jobs Monitoring > Run panel, Spark Task Metrics tab" style="width:100%;" >}} ## Further Reading diff --git a/hugo/content/en/data_observability/jobs_monitoring/airflow.md b/hugo/content/en/data_observability/jobs_monitoring/airflow.md index 3c10861c463..c45dd013d12 100644 --- a/hugo/content/en/data_observability/jobs_monitoring/airflow.md +++ b/hugo/content/en/data_observability/jobs_monitoring/airflow.md @@ -114,7 +114,7 @@ To get started, follow the instructions below. 5. Trigger an update to your Airflow pods and wait for them to finish. -6. Optionally, set up log collection for correlating task logs to DAG run executions in Data Observability: Jobs Monitoring. Correlation requires the logs directory to follow the [default log filename format][5]. +6. Optionally, set up log collection for correlating task logs to DAG run executions in {{< prodname >}}Data Observability{{< /prodname >}}: Jobs Monitoring. Correlation requires the logs directory to follow the [default log filename format][5]. **Note:** For log correlation to work, inject Airflow task context attributes (DAG ID, run ID, task ID, attempt number) into task logs as structured facets in Datadog. See [Inject Airflow Task Context into Logs][11]. @@ -165,7 +165,7 @@ To run an automated check of your OpenLineage setup, see [Troubleshoot Airflow S ### Setup -
If you are using Airflow 2.7.2, 2.8.1, or 2.9.2: MWAA default constraints pin older apache-airflow-providers-openlineage versions. These versions include known issues that can degrade the Data Observability experience. To upgrade to provider versions with fixes, see Upgrade OpenLineage provider on Amazon MWAA for Airflow 2.7.2, 2.8.1, and 2.9.2.
+
If you are using Airflow 2.7.2, 2.8.1, or 2.9.2: MWAA default constraints pin older apache-airflow-providers-openlineage versions. These versions include known issues that can degrade the {{< prodname >}}Data Observability{{< /prodname >}} experience. To upgrade to provider versions with fixes, see Upgrade OpenLineage provider on Amazon MWAA for Airflow 2.7.2, 2.8.1, and 2.9.2.
To get started, follow the instructions below. @@ -240,7 +240,7 @@ To run an automated check of your OpenLineage setup, see [Troubleshoot Airflow S {{% tab "Astronomer" %}}
-For Astronomer customers using Astro, Astro offers lineage features that rely on the Airflow OpenLineage provider. Data Observability: Jobs Monitoring depends on the same OpenLineage provider and uses the Composite transport to add additional transport. +For Astronomer customers using Astro, Astro offers lineage features that rely on the Airflow OpenLineage provider. {{< prodname >}}Data Observability{{< /prodname >}}: Jobs Monitoring depends on the same OpenLineage provider and uses the Composite transport to add additional transport.
### Requirements @@ -309,7 +309,7 @@ To run an automated check of your OpenLineage setup, see [Troubleshoot Airflow S {{% /tab %}} {{% tab "Google Cloud Composer" %}}
-Data Observability: Jobs Monitoring for Airflow is not yet compatible with Dataplex data lineage. Setting up OpenLineage for Data Observability: Jobs Monitoring overrides your existing Dataplex transport configuration. +{{< prodname >}}Data Observability{{< /prodname >}}: Jobs Monitoring for Airflow is not yet compatible with Dataplex data lineage. Setting up OpenLineage for {{< prodname >}}Data Observability{{< /prodname >}}: Jobs Monitoring overrides your existing Dataplex transport configuration.
### Requirements @@ -381,11 +381,11 @@ To run an automated check of your OpenLineage setup, see [Troubleshoot Airflow S ## Known issues -In Airflow 2.x, manually marking a DAG run or task as failed does not update its status in Data Observability: Jobs Monitoring. For affected runs, span durations and duration metrics may be inaccurate. +In Airflow 2.x, manually marking a DAG run or task as failed does not update its status in {{< prodname >}}Data Observability{{< /prodname >}}: Jobs Monitoring. For affected runs, span durations and duration metrics may be inaccurate. ## OpenLineage provider version reference -Data Observability: Jobs Monitoring uses the Apache Airflow OpenLineage provider to emit Airflow DAG and task events. For the best experience, Datadog recommends using the newest OpenLineage provider version that is compatible with your Airflow version. +{{< prodname >}}Data Observability{{< /prodname >}}: Jobs Monitoring uses the Apache Airflow OpenLineage provider to emit Airflow DAG and task events. For the best experience, Datadog recommends using the newest OpenLineage provider version that is compatible with your Airflow version. **Airflow 2.11 or later, including Airflow 3** : **Recommended provider version**: `2.18.0` diff --git a/hugo/content/en/data_observability/jobs_monitoring/airflow_mwaa_upgrade.md b/hugo/content/en/data_observability/jobs_monitoring/airflow_mwaa_upgrade.md index d85a3d7b1d4..d7499e1d971 100644 --- a/hugo/content/en/data_observability/jobs_monitoring/airflow_mwaa_upgrade.md +++ b/hugo/content/en/data_observability/jobs_monitoring/airflow_mwaa_upgrade.md @@ -11,7 +11,7 @@ further_reading: Use this guide if your Amazon MWAA environment runs Airflow `2.7.2`, `2.8.1`, or `2.9.2`. -For these Airflow versions, MWAA default constraints pin older `apache-airflow-providers-openlineage` and OpenLineage package versions. These versions can cause known reliability and compatibility issues, which can degrade the Data Observability experience. +For these Airflow versions, MWAA default constraints pin older `apache-airflow-providers-openlineage` and OpenLineage package versions. These versions can cause known reliability and compatibility issues, which can degrade the {{< prodname >}}Data Observability{{< /prodname >}} experience. To use provider versions that include these fixes, update constraints and requirements together. Amazon MWAA enforces package constraints for each Airflow and Python version, so upgrading OpenLineage packages can conflict with MWAA defaults unless you provide custom constraints. diff --git a/hugo/content/en/data_observability/jobs_monitoring/airflow_troubleshooting_dag.md b/hugo/content/en/data_observability/jobs_monitoring/airflow_troubleshooting_dag.md index cfb859c8b44..71a31fcba33 100644 --- a/hugo/content/en/data_observability/jobs_monitoring/airflow_troubleshooting_dag.md +++ b/hugo/content/en/data_observability/jobs_monitoring/airflow_troubleshooting_dag.md @@ -12,7 +12,7 @@ further_reading: ## Overview -The OpenLineage validation DAG validates your Airflow OpenLineage configuration and reports any issues that would prevent Data Observability: Jobs Monitoring from receiving events. +The OpenLineage validation DAG validates your Airflow OpenLineage configuration and reports any issues that would prevent {{< prodname >}}Data Observability{{< /prodname >}}: Jobs Monitoring from receiving events. Run this DAG when: diff --git a/hugo/content/en/data_observability/jobs_monitoring/azure_data_factory.md b/hugo/content/en/data_observability/jobs_monitoring/azure_data_factory.md index 513dffd7c89..33c911939a1 100644 --- a/hugo/content/en/data_observability/jobs_monitoring/azure_data_factory.md +++ b/hugo/content/en/data_observability/jobs_monitoring/azure_data_factory.md @@ -151,7 +151,7 @@ Datadog resolves datasets across the major warehouse, database, and object stora - Azure Blob Storage - Azure Data Lake Storage -Assets resolve to the same entities that Datadog's other Data Observability integrations report, so lineage connects across your data platforms. +Assets resolve to the same entities that Datadog's other {{< prodname >}}Data Observability{{< /prodname >}} integrations report, so lineage connects across your data platforms. Activities that Datadog cannot resolve datasets for appear as job runs without dataset lineage. diff --git a/hugo/content/en/data_observability/jobs_monitoring/databricks/_index.md b/hugo/content/en/data_observability/jobs_monitoring/databricks/_index.md index d17fcd9aa4b..617a756ddb5 100644 --- a/hugo/content/en/data_observability/jobs_monitoring/databricks/_index.md +++ b/hugo/content/en/data_observability/jobs_monitoring/databricks/_index.md @@ -18,7 +18,7 @@ further_reading:
If your Databricks workspace has Networking Restrictions enabled, add Datadog's {{< region-param key="ip_ranges_url_webhooks" link="true" text="webhook IP ranges" >}} to your allow-list. If your workspace uses Private Link, see the Private Link Connectivity tab below.
-Follow these steps to enable Data Observability: Jobs Monitoring for Databricks. +Follow these steps to enable {{< prodname >}}Data Observability{{< /prodname >}}: Jobs Monitoring for Databricks. 1. [Configure the Datadog-Databricks integration](#configure-the-datadog-databricks-integration) for a Databricks workspace. 1. [Install the Datadog Agent](#install-the-datadog-agent) on your Databricks cluster(s) in the workspace. @@ -64,7 +64,7 @@ Follow these steps to enable Data Observability: Jobs Monitoring for Databricks. 1. On the {{< ui >}}Configure{{< /ui >}} tab, click {{< ui >}}Add Databricks Workspace{{< /ui >}}. 1. Enter a workspace name, your Databricks workspace URL, and the client ID and secret you generated. {{< img src="data_jobs/databricks/connect-workspace-form-m2m.png" alt="In the Datadog-Databricks integration tile, a Databricks workspace is displayed. This workspace has a name, URL, client ID, and client secret." style="width:100%;" >}} -1. Provide the ID of a [Databricks SQL Warehouse][19] for Datadog to query. This gives you visibility into your Databricks costs in Jobs Monitoring or [Cloud Cost Management][18] and powers [Quality Monitoring][21]. +1. Provide the ID of a [Databricks SQL Warehouse][19] for Datadog to query. This gives you visibility into your Databricks costs in Jobs Monitoring or [{{< prodname >}}Cloud Cost Management{{< /prodname >}}][18] and powers [Quality Monitoring][21]. 1. In Databricks, go to {{< ui >}}SQL Warehouses{{< /ui >}} and select the warehouse for Datadog to use. It must be Pro or Serverless. Classic Warehouses are not supported. To reduce costs, use a dedicated 2XS warehouse, with Auto Stop configured for 5-10 minutes. 1. Copy the ID from the warehouse's overview page (it is also the last segment of the warehouse's URL) and enter it in the integration tile. 1. On the warehouse's {{< ui >}}Permissions{{< /ui >}} tab (top right), grant the service principal `CAN USE`. @@ -77,7 +77,7 @@ Follow these steps to enable Data Observability: Jobs Monitoring for Databricks. ```
The user running these commands must have the MANAGE privilege on CATALOG system.
-1. In the **Select products to set up integration** section, ensure that Data Observability: Jobs Monitoring is {{< ui >}}Enabled{{< /ui >}}. +1. In the **Select products to set up integration** section, ensure that {{< prodname >}}Data Observability{{< /prodname >}}: Jobs Monitoring is {{< ui >}}Enabled{{< /ui >}}. 1. In the {{< ui >}}Datadog Agent Setup{{< /ui >}} section, choose either - [Managed by Datadog (recommended)](?tab=datadogmanagedglobalinitscriptrecommended#install-the-datadog-agent): Datadog installs and manages the Agent with a global init script in the workspace. - [Manually](?tab=manuallyinstallaglobalinitscript#install-the-datadog-agent): Follow the [instructions below](?tab=manuallyinstallaglobalinitscript#install-the-datadog-agent) to install and manage the init script for installing the Agent globally or on specific Databricks clusters. @@ -117,7 +117,7 @@ See [Private Link Connectivity (Preview)][15] for full setup instructions. 1. On the {{< ui >}}Configure{{< /ui >}} tab, click {{< ui >}}Add Databricks Workspace{{< /ui >}}. 1. Enter a workspace name, your Databricks workspace URL, and the Databricks token you generated. {{< img src="data_jobs/databricks/configure-workspace-form.png" alt="In the Datadog-Databricks integration tile, a Databricks workspace is displayed. This workspace has a name, URL, and API token." style="width:100%;" >}} -1. Provide the ID of a [Databricks SQL Warehouse][19] for Datadog to query. This gives you visibility into your Databricks costs in Jobs Monitoring or [Cloud Cost Management][18] and powers [Quality Monitoring][21]. +1. Provide the ID of a [Databricks SQL Warehouse][19] for Datadog to query. This gives you visibility into your Databricks costs in Jobs Monitoring or [{{< prodname >}}Cloud Cost Management{{< /prodname >}}][18] and powers [Quality Monitoring][21]. 1. In Databricks, go to {{< ui >}}SQL Warehouses{{< /ui >}} and select the warehouse for Datadog to use. It must be Pro or Serverless. Classic Warehouses are not supported. To reduce costs, use a dedicated 2XS warehouse, with Auto Stop configured for 5-10 minutes. 1. Copy the ID from the warehouse's overview page (it is also the last segment of the warehouse's URL) and enter it in the integration tile. 1. On the warehouse's {{< ui >}}Permissions{{< /ui >}} tab (top right), grant the token's principal `CAN USE`. @@ -130,7 +130,7 @@ See [Private Link Connectivity (Preview)][15] for full setup instructions. ```
The user running these commands must have the MANAGE privilege on CATALOG system.
-1. In the **Select products to set up integration** section, make sure the Data Observability: Jobs Monitoring product is **Enabled**. +1. In the **Select products to set up integration** section, make sure the {{< prodname >}}Data Observability{{< /prodname >}}: Jobs Monitoring product is **Enabled**. 1. In the {{< ui >}}Datadog Agent Setup{{< /ui >}} section, choose either - [Managed by Datadog (recommended)](?tab=datadogmanagedglobalinitscriptrecommended#install-the-datadog-agent): Datadog installs and manages the Agent with a global init script in the workspace. - [Manually](?tab=manuallyinstallaglobalinitscript#install-the-datadog-agent): Follow the [instructions below](?tab=manuallyinstallaglobalinitscript#install-the-datadog-agent) to install and manage the init script for installing the Agent globally or on specific Databricks clusters. @@ -167,7 +167,7 @@ Datadog can install and manage a global init script in the Databricks workspace. #### When integrating a workspace with Datadog -1. In the **Select products to set up integration** section, make sure the Data Observability: Jobs Monitoring product is **Enabled**. +1. In the **Select products to set up integration** section, make sure the {{< prodname >}}Data Observability{{< /prodname >}}: Jobs Monitoring product is **Enabled**. 1. In the {{< ui >}}Datadog Agent Setup{{< /ui >}} section, select the {{< ui >}}Managed by Datadog{{< /ui >}} toggle button. 1. Click {{< ui >}}Select API Key{{< /ui >}} to either select an existing Datadog API key or create a new Datadog API key. 1. (Optional) Disable {{< ui >}}Enable Log Collection{{< /ui >}} if you do not want to collect driver and worker logs for correlating with jobs. @@ -178,7 +178,7 @@ Datadog can install and manage a global init script in the Databricks workspace. 1. On the **Configure** tab, click the workspace in the list of workspaces 1. Click the {{< ui >}}Configured Products{{< /ui >}} tab -1. Make sure the Data Observability: Jobs Monitoring product is **Enabled**. +1. Make sure the {{< prodname >}}Data Observability{{< /prodname >}}: Jobs Monitoring product is **Enabled**. 1. In the {{< ui >}}Datadog Agent Setup{{< /ui >}} section, select the {{< ui >}}Managed by Datadog{{< /ui >}} toggle button. 1. Click {{< ui >}}Select API Key{{< /ui >}} to either select an existing Datadog API key or create a new Datadog API key. 1. (Optional) Disable {{< ui >}}Enable Log Collection{{< /ui >}} if you do not want to collect driver and worker logs for correlating with jobs. @@ -217,7 +217,7 @@ This approach is recommended for clusters in **Standard** access mode. bash djm-install-script || true ``` - The script above downloads and runs the latest init script for Data Observability: Jobs Monitoring in Databricks. If you want to pin your script to a specific version, you can replace the filename in the URL with `install-databricks-0.14.0.sh` to use version `0.14.0`, for example. The source code used to generate this script, and the changes between script versions, can be found on the [Datadog Agent repository][3]. + The script above downloads and runs the latest init script for {{< prodname >}}Data Observability{{< /prodname >}}: Jobs Monitoring in Databricks. If you want to pin your script to a specific version, you can replace the filename in the URL with `install-databricks-0.14.0.sh` to use version `0.14.0`, for example. The source code used to generate this script, and the changes between script versions, can be found on the [Datadog Agent repository][3]. 1. Grant read-only permissions to the init script: 1. At the volume level, grant the `READ VOLUME` permission to all account users. @@ -301,7 +301,7 @@ This setup does not work on Databricks clusters in Standard acc bash djm-install-script || true ``` - The script above sets the required parameters, and downloads and runs the latest init script for Data Observability: Jobs Monitoring in Databricks. If you want to pin your script to a specific version, you can replace the filename in the URL with `install-databricks-0.14.0.sh` to use version `0.14.0`, for example. The source code used to generate this script, and the changes between script versions, can be found on the [Datadog Agent repository][3]. + The script above sets the required parameters, and downloads and runs the latest init script for {{< prodname >}}Data Observability{{< /prodname >}}: Jobs Monitoring in Databricks. If you want to pin your script to a specific version, you can replace the filename in the URL with `install-databricks-0.14.0.sh` to use version `0.14.0`, for example. The source code used to generate this script, and the changes between script versions, can be found on the [Datadog Agent repository][3]. 1. To enable the script for all new and restarted clusters, toggle {{< ui >}}Enabled{{< /ui >}}. {{< img src="data_jobs/databricks/toggle.png" alt="Databricks UI, admin settings, global init scripts. A script called 'install-datadog-agent' is in a list with an enabled toggle." style="width:100%;" >}} @@ -350,7 +350,7 @@ Optionally, you can also set other init script parameters and Datadog environmen bash djm-install-script || true ``` - The script above downloads and runs the latest init script for Data Observability: Jobs Monitoring in Databricks. If you want to pin your script to a specific version, you can replace the filename in the URL (for example, `install-databricks-0.14.0.sh` to use version `0.14.0`). You can find the source code used to generate this script, and the changes between script versions, on the [Datadog Agent repository][3]. + The script above downloads and runs the latest init script for {{< prodname >}}Data Observability{{< /prodname >}}: Jobs Monitoring in Databricks. If you want to pin your script to a specific version, you can replace the filename in the URL (for example, `install-databricks-0.14.0.sh` to use version `0.14.0`). You can find the source code used to generate this script, and the changes between script versions, on the [Datadog Agent repository][3]. 1. Grant read-only permissions to the init script: 1. At the volume level, grant the `READ VOLUME` permission to all account users. @@ -472,7 +472,7 @@ If you need more granular control, grant these minimal permissions to the follow | Query | [CAN VIEW][23] | SQL warehouse | [CAN MONITOR][24] -Additionally, for Datadog to access your Databricks cost data in Data Observability: Jobs Monitoring or [Cloud Cost Management][26], the user or service principal used to query [system tables][27] must have the following permissions: +Additionally, for Datadog to access your Databricks cost data in {{< prodname >}}Data Observability{{< /prodname >}}: Jobs Monitoring or [{{< prodname >}}Cloud Cost Management{{< /prodname >}}][26], the user or service principal used to query [system tables][27] must have the following permissions: - `CAN USE` permission on the SQL Warehouse. - Read access to the [system tables][27] within Unity Catalog. In Databricks, open the {{< ui >}}SQL Editor{{< /ui >}} and run the following commands, using the service principal's client ID (not its display name): ```sql @@ -489,7 +489,7 @@ Additionally, for Datadog to access your Databricks cost data in Data Observabil ### Configure cluster tags -Databricks custom cluster tags are automatically captured and available across Data Observability: Jobs Monitoring and the Datadog platform. The only exception is tags from Azure resource groups, which are not auto-captured. +Databricks custom cluster tags are automatically captured and available across {{< prodname >}}Data Observability{{< /prodname >}}: Jobs Monitoring and the Datadog platform. The only exception is tags from Azure resource groups, which are not auto-captured. To add tags manually, set the `DD_TAGS` environment variable in the Spark environment variables of your cluster. This has the same effect as Databricks custom cluster tags but requires manual configuration. Use comma or space separated key:value pairs following [Datadog tag conventions][28]: diff --git a/hugo/content/en/data_observability/jobs_monitoring/dataproc.md b/hugo/content/en/data_observability/jobs_monitoring/dataproc.md index d4f3b9b8a42..13be32e68e4 100644 --- a/hugo/content/en/data_observability/jobs_monitoring/dataproc.md +++ b/hugo/content/en/data_observability/jobs_monitoring/dataproc.md @@ -19,7 +19,7 @@ This guide is for Dataproc clusters on Compute Engine. If you are using Dataproc ## Setup -Follow these steps to enable Data Observability: Jobs Monitoring for GCP Dataproc. +Follow these steps to enable {{< prodname >}}Data Observability{{< /prodname >}}: Jobs Monitoring for GCP Dataproc. 1. [Store your Datadog API key](#store-your-datadog-api-key-in-google-cloud-secret-manager-recommended) in GCP Secret Manager (recommended). 1. [Create and configure your Dataproc cluster](#create-and-configure-your-dataproc-cluster). @@ -61,7 +61,7 @@ When you create a new {{< ui >}}Dataproc Cluster on Compute Engine{{< /ui >}} in curl -L https://install.datadoghq.com/scripts/install-dataproc.sh > djm-install-script; bash djm-install-script || true ``` - The script above sets the required parameters, and downloads and runs the latest init script for Data Observability: Jobs Monitoring in Dataproc. If you want to pin your script to a specific version, you can replace the filename in the URL with `install-dataproc-0.13.5.sh` to use version `0.13.5`, for example. The source code used to generate this script, and the changes between script versions, can be found on the [Datadog Agent repository][13]. + The script above sets the required parameters, and downloads and runs the latest init script for {{< prodname >}}Data Observability{{< /prodname >}}: Jobs Monitoring in Dataproc. If you want to pin your script to a specific version, you can replace the filename in the URL with `install-dataproc-0.13.5.sh` to use version `0.13.5`, for example. The source code used to generate this script, and the changes between script versions, can be found on the [Datadog Agent repository][13]. Optionally, the script can be configured by adding the following environment variable: diff --git a/hugo/content/en/data_observability/jobs_monitoring/dbt.md b/hugo/content/en/data_observability/jobs_monitoring/dbt.md index 71328120bb8..6ff2cafdb47 100644 --- a/hugo/content/en/data_observability/jobs_monitoring/dbt.md +++ b/hugo/content/en/data_observability/jobs_monitoring/dbt.md @@ -36,7 +36,7 @@ Create a service token in dbt Cloud so Datadog can access your account's metadat ## Connect your dbt Cloud account to Datadog -Use the API token to configure the integration in Data Observability. +Use the API token to configure the integration in {{< prodname >}}Data Observability{{< /prodname >}}. 1. Navigate to [{{< ui >}}Datadog Data Observability{{< /ui >}} > {{< ui >}}Settings{{< /ui >}}][1]. 2. In the {{< ui >}}dbt Cloud{{< /ui >}} section, click {{< ui >}}Configure{{< /ui >}}. diff --git a/hugo/content/en/data_observability/jobs_monitoring/emr.md b/hugo/content/en/data_observability/jobs_monitoring/emr.md index 37c864e2828..4590075a6da 100644 --- a/hugo/content/en/data_observability/jobs_monitoring/emr.md +++ b/hugo/content/en/data_observability/jobs_monitoring/emr.md @@ -19,7 +19,7 @@ If you are using [EMR on EKS][13], follow these [instructions for setting up Job ## Setup -Follow these steps to enable Data Observability: Jobs Monitoring for Amazon EMR. +Follow these steps to enable {{< prodname >}}Data Observability{{< /prodname >}}: Jobs Monitoring for Amazon EMR. 1. [Store your Datadog API key](#store-your-datadog-api-key-in-aws-secrets-manager-recommended) in AWS Secrets Manager (Recommended). 1. [Grant permissions to EMR EC2 instance profile](#grant-permissions-to-emr-ec2-instance-profile). @@ -39,7 +39,7 @@ Follow these steps to enable Data Observability: Jobs Monitoring for Amazon EMR. 1. In AWS Secrets Manager, open the secret you created. Take note of the {{< ui >}}Secret ARN{{< /ui >}}. ### Grant permissions to EMR EC2 instance profile -EMR EC2 instance profile is a IAM role assigned to every EC2 instance in an Amazon EMR cluster when the instance launches. Follow [the Amazon guide][11] to prepare this role based on your application's need to interact with other AWS services. The following additional permissions may be required for Data Observability: Jobs Monitoring. +EMR EC2 instance profile is a IAM role assigned to every EC2 instance in an Amazon EMR cluster when the instance launches. Follow [the Amazon guide][11] to prepare this role based on your application's need to interact with other AWS services. The following additional permissions may be required for {{< prodname >}}Data Observability{{< /prodname >}}: Jobs Monitoring. #### Permissions to get secret value using AWS Secrets Manager @@ -123,7 +123,7 @@ When you create a new EMR cluster in the [Amazon EMR console][4], add a bootstra ``` Optionally, the script can be configured adding the following environment variables: - The script above sets the required parameters, and downloads and runs the latest init script for Data Observability: Jobs Monitoring in EMR. If you want to pin your script to a specific version, you can replace the filename in the URL with `install-emr-0.13.5.sh` to use version `0.13.5`, for example. The source code used to generate this script, and the changes between script versions can be found on the [Datadog Agent repository][12]. + The script above sets the required parameters, and downloads and runs the latest init script for {{< prodname >}}Data Observability{{< /prodname >}}: Jobs Monitoring in EMR. If you want to pin your script to a specific version, you can replace the filename in the URL with `install-emr-0.13.5.sh` to use version `0.13.5`, for example. The source code used to generate this script, and the changes between script versions can be found on the [Datadog Agent repository][12]. Optionally, the script can be configured by adding the following environment variables: diff --git a/hugo/content/en/data_observability/jobs_monitoring/glue.md b/hugo/content/en/data_observability/jobs_monitoring/glue.md index e694ffaaddf..cc5a3c3923f 100644 --- a/hugo/content/en/data_observability/jobs_monitoring/glue.md +++ b/hugo/content/en/data_observability/jobs_monitoring/glue.md @@ -103,12 +103,12 @@ Some of these permissions are related to monitoring Iceberg tables in Glue. For - `/aws-glue/jobs/output` - `/aws-glue/jobs/logs-v2` -This helps ensure the logs are searchable and available under the {{< ui >}}Glue{{< /ui >}} tab in **Data Observability: Jobs Monitoring**. +This helps ensure the logs are searchable and available under the {{< ui >}}Glue{{< /ui >}} tab in **{{< prodname >}}Data Observability{{< /prodname >}}: Jobs Monitoring**. ## (Optional) Configure Glue metrics Enable the [Glue Integration][4] tile for Glue metrics collection. -Metrics should be available under the {{< ui >}}Glue{{< /ui >}} job tab in **Data Observability: Jobs Monitoring**. +Metrics should be available under the {{< ui >}}Glue{{< /ui >}} job tab in **{{< prodname >}}Data Observability{{< /prodname >}}: Jobs Monitoring**. ## (Optional) Enable dataset lineage diff --git a/hugo/content/en/data_observability/jobs_monitoring/kubernetes.md b/hugo/content/en/data_observability/jobs_monitoring/kubernetes.md index d8066e66f2b..21d7f0e277a 100644 --- a/hugo/content/en/data_observability/jobs_monitoring/kubernetes.md +++ b/hugo/content/en/data_observability/jobs_monitoring/kubernetes.md @@ -13,9 +13,9 @@ further_reading: ## Setup -
Data Observability: Jobs Monitoring requires Datadog Agent version 7.64.0 or later, and Java tracer version 1.38.0 or later.
+
{{< prodname >}}Data Observability{{< /prodname >}}: Jobs Monitoring requires Datadog Agent version 7.64.0 or later, and Java tracer version 1.38.0 or later.
-Follow these steps to enable Data Observability: Jobs Monitoring for Spark on Kubernetes. +Follow these steps to enable {{< prodname >}}Data Observability{{< /prodname >}}: Jobs Monitoring for Spark on Kubernetes. 1. [Install the Datadog Agent](#install-the-datadog-agent-on-your-kubernetes-cluster) on your Kubernetes cluster. 2. (Optional) [Collect Spark Data Lineage with OpenLineage](#optional-collect-spark-data-lineage-with-openlineage). @@ -148,11 +148,11 @@ You can install the Datadog Agent using the [Datadog Operator][3] or [Helm][4]. ### (Optional) Collect Spark Data Lineage with OpenLineage -Data Observability: Jobs Monitoring can collect Spark lineage through [OpenLineage][8], so you can see the upstream and downstream tables of your jobs and visualize entire Spark pipelines. Setup has two steps: install the OpenLineage Spark provider, then enable the feature in the Java tracer. +{{< prodname >}}Data Observability{{< /prodname >}}: Jobs Monitoring can collect Spark lineage through [OpenLineage][8], so you can see the upstream and downstream tables of your jobs and visualize entire Spark pipelines. Setup has two steps: install the OpenLineage Spark provider, then enable the feature in the Java tracer.
OpenLineage lineage collection requires Java tracer version 1.48.0 or later.
-1. **Install the OpenLineage Spark provider.** Make the `openlineage-spark` JAR available on the classpath of your Spark driver and executors, following the [OpenLineage Spark installation guide][9]. Use OpenLineage version `1.29.0` or later, which is the first version that supports the run-tag facets that Data Observability: Jobs Monitoring relies on. +1. **Install the OpenLineage Spark provider.** Make the `openlineage-spark` JAR available on the classpath of your Spark driver and executors, following the [OpenLineage Spark installation guide][9]. Use OpenLineage version `1.29.0` or later, which is the first version that supports the run-tag facets that {{< prodname >}}Data Observability{{< /prodname >}}: Jobs Monitoring relies on. You do not need to set `spark.extraListeners` or configure any `spark.openlineage.transport.*` options. When the feature is enabled and the JAR is present, the Datadog Java tracer registers the OpenLineage listener and routes lineage events through the local Datadog Agent. diff --git a/hugo/content/en/data_observability/jobs_monitoring/openlineage/_index.md b/hugo/content/en/data_observability/jobs_monitoring/openlineage/_index.md index eb2a3fc8206..b6c513c18dd 100644 --- a/hugo/content/en/data_observability/jobs_monitoring/openlineage/_index.md +++ b/hugo/content/en/data_observability/jobs_monitoring/openlineage/_index.md @@ -560,7 +560,7 @@ The following example shows a job reading from a PostgreSQL table and writing to ] ``` -**Note**: If a dataset namespace is not recognized, Datadog still creates a lineage node for it but does not surface it in the Data Observability product. Use a recognized namespace format to have datasets appear in the catalog and lineage graph. +**Note**: If a dataset namespace is not recognized, Datadog still creates a lineage node for it but does not surface it in the {{< prodname >}}Data Observability{{< /prodname >}} product. Use a recognized namespace format to have datasets appear in the catalog and lineage graph. ## Supported facets diff --git a/hugo/content/en/data_observability/lineage.md b/hugo/content/en/data_observability/lineage.md index 1b669d097df..c1951622650 100644 --- a/hugo/content/en/data_observability/lineage.md +++ b/hugo/content/en/data_observability/lineage.md @@ -27,7 +27,7 @@ Datadog builds lineage automatically from metadata collected through your [Quali {{< img src="data_observability/lineage/lineage-overview.png" alt="The Lineage page showing upstream and downstream dependencies for an anchored Snowflake table" style="width:100%;" >}} -To open Lineage, go to {{< ui >}}Data Observability{{< /ui >}} > {{< ui >}}Lineage{{< /ui >}}. +To open Lineage, go to {{< ui >}}{{< prodname >}}Data Observability{{< /prodname >}}{{< /ui >}} > {{< ui >}}Lineage{{< /ui >}}. ## Select anchor assets diff --git a/hugo/content/en/data_observability/quality_monitoring/business_intelligence/looker.md b/hugo/content/en/data_observability/quality_monitoring/business_intelligence/looker.md index c8b539d42e9..33e4f0f37e4 100644 --- a/hugo/content/en/data_observability/quality_monitoring/business_intelligence/looker.md +++ b/hugo/content/en/data_observability/quality_monitoring/business_intelligence/looker.md @@ -41,7 +41,7 @@ Datadog's Looker integration helps data teams make changes to their data platfor Datadog parses LookML files to collect lineage and metadata for Looker views and derived tables. -Connect each LookML Git repository to Datadog using the [Source Code Integration][4]. The next time the Looker integration runs on its hourly schedule, it automatically detects the repositories and parses the LookML files. +Connect each LookML Git repository to Datadog using the [{{< prodname >}}Source Code Integration{{< /prodname >}}][4]. The next time the Looker integration runs on its hourly schedule, it automatically detects the repositories and parses the LookML files. If your Git repositories already appear on the Datadog [repositories page][5], no additional steps are required. diff --git a/hugo/content/en/data_observability/quality_monitoring/data_lakes/aws_glue.md b/hugo/content/en/data_observability/quality_monitoring/data_lakes/aws_glue.md index 956fabb494f..982c3d8c5eb 100644 --- a/hugo/content/en/data_observability/quality_monitoring/data_lakes/aws_glue.md +++ b/hugo/content/en/data_observability/quality_monitoring/data_lakes/aws_glue.md @@ -23,7 +23,7 @@ Before you begin, make sure you have: - An AWS account with Glue Iceberg tables you want to monitor. - An [AWS account connected in Datadog][1]. - - Log forwarding is not required for Data Observability. + - Log forwarding is not required for {{< prodname >}}Data Observability{{< /prodname >}}. - IAM permissions to modify the Datadog role's policies. - (Optional) AWS Lake Formation access if you use it to manage table permissions. diff --git a/hugo/content/en/data_observability/quality_monitoring/data_warehouses/bigquery.md b/hugo/content/en/data_observability/quality_monitoring/data_warehouses/bigquery.md index beceba60dd6..06a0e669f35 100644 --- a/hugo/content/en/data_observability/quality_monitoring/data_warehouses/bigquery.md +++ b/hugo/content/en/data_observability/quality_monitoring/data_warehouses/bigquery.md @@ -27,7 +27,7 @@ To configure the BigQuery integration in Datadog: 1. Navigate to [{{< ui >}}Datadog Data Observability{{< /ui >}} > {{< ui >}}Settings{{< /ui >}}][8]. 2. Click the {{< ui >}}Configure{{< /ui >}} button for the BigQuery option. -You can now choose to use a service account that you've [already connected to Datadog](#using-an-existing-service-account) or [set up a new one](#using-a-new-service-account) specifically for Data Observability. +You can now choose to use a service account that you've [already connected to Datadog](#using-an-existing-service-account) or [set up a new one](#using-a-new-service-account) specifically for {{< prodname >}}Data Observability{{< /prodname >}}. ### Using an existing service account @@ -37,7 +37,7 @@ Choose this option if you've previously connected a service account to Datadog. 2. Select the service account from the dropdown list. 3. Click {{< ui >}}Next{{< /ui >}}. 4. Turn on the {{< ui >}}Enable Data Observability{{< /ui >}} toggle and click {{< ui >}}Add Account{{< /ui >}}. -Data Observability functionality requires additional roles and API access beyond the basic BigQuery integration. +{{< prodname >}}Data Observability{{< /prodname >}} functionality requires additional roles and API access beyond the basic BigQuery integration. #### Additional roles diff --git a/hugo/content/en/data_observability/quality_monitoring/data_warehouses/databricks.md b/hugo/content/en/data_observability/quality_monitoring/data_warehouses/databricks.md index 18e220c09ca..e6491d95c90 100644 --- a/hugo/content/en/data_observability/quality_monitoring/data_warehouses/databricks.md +++ b/hugo/content/en/data_observability/quality_monitoring/data_warehouses/databricks.md @@ -32,7 +32,7 @@ If your Databricks workspace restricts network access by IP, add the Datadog web **Note**: Workspace Admin permissions are not required for Quality Monitoring. -2. When configuring the integration, turn on the {{< ui >}}Data Observability{{< /ui >}} toggle. +2. When configuring the integration, turn on the {{< ui >}}{{< prodname >}}Data Observability{{< /prodname >}}{{< /ui >}} toggle. 3. Click {{< ui >}}Save Databricks Workspace{{< /ui >}}. ### Step 2 - Grant access diff --git a/hugo/content/en/data_observability/quality_monitoring/data_warehouses/redshift.md b/hugo/content/en/data_observability/quality_monitoring/data_warehouses/redshift.md index 1f492cf4f7b..d2e4cba4ca6 100644 --- a/hugo/content/en/data_observability/quality_monitoring/data_warehouses/redshift.md +++ b/hugo/content/en/data_observability/quality_monitoring/data_warehouses/redshift.md @@ -21,7 +21,7 @@ Datadog supports both provisioned Redshift clusters and Redshift Serverless work Before you begin, make sure you have: - An [AWS account connected in Datadog][3]. - - Log forwarding is not required for Data Observability. + - Log forwarding is not required for {{< prodname >}}Data Observability{{< /prodname >}}. - A Redshift superuser or database user with the ability to create roles and grant privileges. - If your Redshift cluster or workgroup restricts network access by IP, add Datadog webhook IPs to your VPC security group inbound rules. For the list of IPs, see the `webhooks` section of the {{< region-param key="ip_ranges_url" link="true" text="IP ranges list" >}}. diff --git a/hugo/content/en/data_observability/quality_monitoring/data_warehouses/snowflake.md b/hugo/content/en/data_observability/quality_monitoring/data_warehouses/snowflake.md index 3eebd6e861c..d2558e060aa 100644 --- a/hugo/content/en/data_observability/quality_monitoring/data_warehouses/snowflake.md +++ b/hugo/content/en/data_observability/quality_monitoring/data_warehouses/snowflake.md @@ -197,7 +197,7 @@ When enabled, each task graph run appears as a trace in APM with individual task ## Object tags -Datadog ingests [Snowflake object tags][6] applied to your tables and attaches them to the corresponding table in Data Observability. Tags are read from `SNOWFLAKE.ACCOUNT_USAGE.TAG_REFERENCES` using the `SNOWFLAKE.GOVERNANCE_VIEWER` database role granted during setup, so no additional permissions are required. +Datadog ingests [Snowflake object tags][6] applied to your tables and attaches them to the corresponding table in {{< prodname >}}Data Observability{{< /prodname >}}. Tags are read from `SNOWFLAKE.ACCOUNT_USAGE.TAG_REFERENCES` using the `SNOWFLAKE.GOVERNANCE_VIEWER` database role granted during setup, so no additional permissions are required. Ingested tags are available as attributes on the **Data Observability Metrics** data source, alongside `database`, `schema`, `table`, and `entity_id`. In the Metrics Explorer and dashboard widget editor, you can use them to: diff --git a/hugo/content/en/data_observability/quality_monitoring/transactional_databases/postgres.md b/hugo/content/en/data_observability/quality_monitoring/transactional_databases/postgres.md index 1e17f4e8585..a7a5b03f1a6 100644 --- a/hugo/content/en/data_observability/quality_monitoring/transactional_databases/postgres.md +++ b/hugo/content/en/data_observability/quality_monitoring/transactional_databases/postgres.md @@ -14,14 +14,14 @@ further_reading: --- {{< callout url="#" btn_hidden="true" header="Preview" >}} -Data Observability for PostgreSQL is in Preview. Contact your Datadog representative to enable it for your organization. +{{< prodname >}}Data Observability{{< /prodname >}} for PostgreSQL is in Preview. Contact your Datadog representative to enable it for your organization. {{< /callout >}} ## Overview The PostgreSQL integration for Datadog Data Observability tracks table metadata, providing visibility into schemas, table dimensions, and row volumes across your environment. -PostgreSQL is collected through the [Datadog Agent][1] rather than through a direct cloud connection like the [data warehouse integrations][7]. This page covers only the configuration needed for Data Observability. To set up the full suite of Database Monitoring features, see the [DBM setup guide for PostgreSQL][2]. +PostgreSQL is collected through the [Datadog Agent][1] rather than through a direct cloud connection like the [data warehouse integrations][7]. This page covers only the configuration needed for {{< prodname >}}Data Observability{{< /prodname >}}. To set up the full suite of {{< prodname >}}Database Monitoring{{< /prodname >}} features, see the [DBM setup guide for PostgreSQL][2]. ## Prerequisites @@ -33,7 +33,7 @@ Before you begin, make sure you have: ## Already using Database Monitoring? -If [Database Monitoring][2] is already running against this database, most of the setup is done: the `datadog` user exists and has `pg_monitor`. Three things are still needed. +If [{{< prodname >}}Database Monitoring{{< /prodname >}}][2] is already running against this database, most of the setup is done: the `datadog` user exists and has `pg_monitor`. Three things are still needed. 1. **Check your Agent version.** Run `datadog-agent status` and read the version from the header and from the Postgres check line in the Collector section: @@ -45,16 +45,16 @@ If [Database Monitoring][2] is already running against this database, most of th If the Agent is older than `7.81.0`, [upgrade the Agent][6]. Upgrading only the Postgres check with `datadog-agent integration install` is not sufficient: the Remote Configuration handler that delivers monitor queries ships with the Agent itself, not with the check. -2. **Grant `SELECT` on your data.** Database Monitoring grants `pg_monitor` and `USAGE` on the `public` schema, but it does not grant `SELECT` on your tables. Data Observability needs it to compute row counts, column-level metrics, and custom SQL results. Run the grants in [Set up the Datadog database user](#set-up-the-datadog-database-user) for each schema in each database you want to track, skipping the `CREATE USER` step. +2. **Grant `SELECT` on your data.** {{< prodname >}}Database Monitoring{{< /prodname >}} grants `pg_monitor` and `USAGE` on the `public` schema, but it does not grant `SELECT` on your tables. {{< prodname >}}Data Observability{{< /prodname >}} needs it to compute row counts, column-level metrics, and custom SQL results. Run the grants in [Set up the Datadog database user](#set-up-the-datadog-database-user) for each schema in each database you want to track, skipping the `CREATE USER` step. -3. **Enable the Data Observability job.** Add the following to each existing instance in `conf.d/postgres.d/conf.yaml`, keeping `dbm: true` in place: +3. **Enable the {{< prodname >}}Data Observability{{< /prodname >}} job.** Add the following to each existing instance in `conf.d/postgres.d/conf.yaml`, keeping `dbm: true` in place: ```yaml data_observability: enabled: true ``` - If your instance already uses `database_autodiscovery`, Data Observability picks up every discovered database, so make sure the `SELECT` grants cover all of them. + If your instance already uses `database_autodiscovery`, {{< prodname >}}Data Observability{{< /prodname >}} picks up every discovered database, so make sure the `SELECT` grants cover all of them. [Restart the Agent][5] to apply the changes, then continue from [Explore your table metadata](#explore-your-table-metadata). @@ -79,7 +79,7 @@ If [Database Monitoring][2] is already running against this database, most of th GRANT SELECT ON TABLES TO datadog; ``` - `ALTER DEFAULT PRIVILEGES` only affects tables created by the role named in `FOR ROLE`. Run it once for **each role that creates tables** in the schema; otherwise Data Observability loses access to new tables as your application creates them. To list the roles that own tables in a schema: + `ALTER DEFAULT PRIVILEGES` only affects tables created by the role named in `FOR ROLE`. Run it once for **each role that creates tables** in the schema; otherwise {{< prodname >}}Data Observability{{< /prodname >}} loses access to new tables as your application creates them. To list the roles that own tables in a schema: ```sql SELECT DISTINCT tableowner FROM pg_tables WHERE schemaname = ''; @@ -97,7 +97,7 @@ GRANT SELECT ON ""."orders" TO datadog; GRANT SELECT ON ""."users" TO datadog; ``` -Data Observability only displays tables where the `datadog` user has explicit `SELECT` privileges. +{{< prodname >}}Data Observability{{< /prodname >}} only displays tables where the `datadog` user has explicit `SELECT` privileges. ## Configure the PostgreSQL integration @@ -148,7 +148,7 @@ instances: **Note**: If your password includes special characters, wrap it in single quotes. -Schema collection (`collect_schemas`) is enabled by default and is what populates your tables in Data Observability. `dbm: true` is **not** required for Data Observability; set it only if you also use [Database Monitoring][2]. +Schema collection (`collect_schemas`) is enabled by default and is what populates your tables in {{< prodname >}}Data Observability{{< /prodname >}}. `dbm: true` is **not** required for {{< prodname >}}Data Observability{{< /prodname >}}; set it only if you also use [{{< prodname >}}Database Monitoring{{< /prodname >}}][2]. [Restart the Agent][5] to apply the changes: @@ -168,7 +168,7 @@ The output should show the `postgres` check with a `Total Runs` count greater th ## Explore your table metadata -Allow approximately one hour for the initial metadata collection to complete. You can then [view your PostgreSQL tables][3] in the Data Observability catalog. +Allow approximately one hour for the initial metadata collection to complete. You can then [view your PostgreSQL tables][3] in the {{< prodname >}}Data Observability{{< /prodname >}} catalog. If your tables do not appear, verify that: @@ -195,7 +195,7 @@ Monitors run on the collection schedule. Keep `SELECT` privileges in place for t ## Known limitations -Data Observability lists all PostgreSQL tables from instances where `dbm` and `collect_schemas` are enabled, including instances that do not have `data_observability.enabled: true`. Scheduling a monitor against one of those databases produces a monitor with no data. If your tables are listed but your monitors stay empty, follow [Already using Database Monitoring?](#already-using-database-monitoring) to enable the job and grant the required `SELECT` privileges. +{{< prodname >}}Data Observability{{< /prodname >}} lists all PostgreSQL tables from instances where `dbm` and `collect_schemas` are enabled, including instances that do not have `data_observability.enabled: true`. Scheduling a monitor against one of those databases produces a monitor with no data. If your tables are listed but your monitors stay empty, follow [Already using Database Monitoring?](#already-using-database-monitoring) to enable the job and grant the required `SELECT` privileges. ## Further reading diff --git a/hugo/content/en/data_security/_index.md b/hugo/content/en/data_security/_index.md index 502e1d798be..433eebe5775 100644 --- a/hugo/content/en/data_security/_index.md +++ b/hugo/content/en/data_security/_index.md @@ -86,7 +86,7 @@ The Datadog SDKs are used to instrument your applications, services, tests, and - Application Performance Monitoring (APM) - Continuous Profiler - CI Visibility -- App and API Protection +- {{< prodname >}}App and API Protection{{< /prodname >}} For detailed information about how tracing-library sourced data is managed, default basic security settings, and custom obfuscating, scrubbing, excluding, and modifying of trace-related elements, read [Configuring Agent and Tracer for trace data security][18]. diff --git a/hugo/content/en/data_security/logs.md b/hugo/content/en/data_security/logs.md index 107ccd1cb92..d4926719007 100644 --- a/hugo/content/en/data_security/logs.md +++ b/hugo/content/en/data_security/logs.md @@ -16,7 +16,7 @@ further_reading: The Log Management product supports multiple [environments and formats][1], allowing you to submit to Datadog nearly any data you choose. This article describes the main security guarantees and filtering controls available to you when submitting logs to Datadog. **Notes**: -- Logs can be viewed in various Datadog products. All logs viewed in the Datadog UI, including logs viewed in APM trace pages, are part of the Log Management product. +- Logs can be viewed in various Datadog products. All logs viewed in the Datadog UI, including logs viewed in APM trace pages, are part of the {{< prodname >}}Log Management{{< /prodname >}} product. - Datadog's tools and policies comply with PCI v4.0. For more information, see [PCI DSS Compliance][10]. ## Information security @@ -33,7 +33,7 @@ As of version 6, the Agent can be configured to obfuscate specific patterns with Alteratively, use [Sensitive Data Scanner][7] in the cloud or with the Agent to identify, tag, and redact sensitive data. In Sensitive Data Scanner, you set up a scanning group to define what data to scan and then set up scanning rules to determine what sensitive information to match within the data. You can choose whether to redact the data if there is a match. Datadog provides a library of predefined rules to detect sensitive information such as credit card numbers, email addresses, IP addresses, API keys, and more. You can also define your own regex-based scanning rules to identify sensitive information. -Sensitive Data Scanner is also available as a [processor][8] in [Observability Pipelines][9]. With Observability Pipelines, you can collect and process logs within your own infrastructure and then route them to downstream integrations. +Sensitive Data Scanner is also available as a [processor][8] in [{{< prodname >}}Observability Pipelines{{< /prodname >}}][9]. With Observability Pipelines, you can collect and process logs within your own infrastructure and then route them to downstream integrations. ## HIPAA-enabled customers diff --git a/hugo/content/en/data_security/pci_compliance.md b/hugo/content/en/data_security/pci_compliance.md index dcd6d5c31a1..842d91f036f 100644 --- a/hugo/content/en/data_security/pci_compliance.md +++ b/hugo/content/en/data_security/pci_compliance.md @@ -21,7 +21,7 @@ To help maintain PCI compliance, **Datadog strongly recommends** the use of the - [**Sensitive Data Scanner**][2]: discover, classify, and redact sensitive cardholder data - [**Audit Trail**][3]: search and analyze detailed audit events for up to 90 days for long-term retention and archiving - [**File Integrity Monitoring**][4]: watch for changes to key files and directories -- [**Cloud Security**][5]: track conformance to requirements of industry benchmarks and other controls +- [**{{< prodname >}}Cloud Security{{< /prodname >}}**][5]: track conformance to requirements of industry benchmarks and other controls ## Further Reading diff --git a/hugo/content/en/data_security/synthetics.md b/hugo/content/en/data_security/synthetics.md index af9e838cda7..6b052c7a015 100644 --- a/hugo/content/en/data_security/synthetics.md +++ b/hugo/content/en/data_security/synthetics.md @@ -95,7 +95,7 @@ Artifacts are browser test screenshots, snapshots, errors, and resources. ## Testing accounts -It is strongly recommended to leverage accounts dedicated to testing for your Synthetics tests. +It is strongly recommended to leverage accounts dedicated to testing for your {{< prodname >}}Synthetics{{< /prodname >}} tests. ## Storing secrets diff --git a/hugo/content/en/data_streams/_index.md b/hugo/content/en/data_streams/_index.md index a098c52c882..c3a2531901c 100644 --- a/hugo/content/en/data_streams/_index.md +++ b/hugo/content/en/data_streams/_index.md @@ -62,7 +62,7 @@ Data Streams Monitoring instruments Kafka _clients_ (consumers/producers). If yo Data Streams Monitoring requires minimum Datadog SDK versions. See each setup page for details. #### Support for OpenTelemetry -Data Streams Monitoring supports OpenTelemetry. If you have set up Datadog APM to work with OpenTelemetry, no additional setup is required to use Data Streams Monitoring. See [OpenTelemetry Compatibility][11]. +Data Streams Monitoring supports OpenTelemetry. If you have set up {{< prodname >}}Datadog APM{{< /prodname >}} to work with OpenTelemetry, no additional setup is required to use Data Streams Monitoring. See [OpenTelemetry Compatibility][11]. ## Setup diff --git a/hugo/content/en/data_streams/kafka/_index.md b/hugo/content/en/data_streams/kafka/_index.md index e09e72cc5a7..5f77eb768be 100644 --- a/hugo/content/en/data_streams/kafka/_index.md +++ b/hugo/content/en/data_streams/kafka/_index.md @@ -13,7 +13,7 @@ With Data Streams Monitoring's Kafka Console, a Datadog Agent check connects to - **Pinpoint root cause**: Correlate configuration and schema changes with lag, throughput, and errors, and trace issues to the exact topic, schema version, or configuration change - **Connect services to topics**: See which producers and consumers interact with each topic, with linked owners, repos, on-call rotations, traces, and error logs - **Inspect topic schemas and messages**: View schemas, compare versions, and access messages to debug poison payloads or explore the topic -- **Alert and automate responses**: Use [recommended monitor templates][4] and trigger Workflow Automation or webhooks when a Kafka condition fires +- **Alert and automate responses**: Use [recommended monitor templates][4] and trigger {{< prodname >}}Workflow Automation{{< /prodname >}} or webhooks when a Kafka condition fires To get started, see [Kafka Console Setup][2]. diff --git a/hugo/content/en/data_streams/kafka/monitors_and_automation.md b/hugo/content/en/data_streams/kafka/monitors_and_automation.md index b8f5b0aaf8e..be65105d9ce 100644 --- a/hugo/content/en/data_streams/kafka/monitors_and_automation.md +++ b/hugo/content/en/data_streams/kafka/monitors_and_automation.md @@ -53,10 +53,10 @@ Both monitors are grouped by `kafka_cluster_id` so each cluster alerts its own o When a monitor triggers, Datadog can take action automatically rather than waiting for a human to triage. Two options: -- **Workflow Automation** — Build a Datadog Workflow that chains pre-built actions across your infrastructure and tools (PagerDuty, Slack, Jira, AWS, Kubernetes, and so on), and run it from a monitor trigger. Best for the "trigger a runbook" patterns below. See [Trigger a workflow from a monitor][3]. +- **{{< prodname >}}Workflow Automation{{< /prodname >}}** — Build a Datadog Workflow that chains pre-built actions across your infrastructure and tools (PagerDuty, Slack, Jira, AWS, Kubernetes, and so on), and run it from a monitor trigger. Best for the "trigger a runbook" patterns below. See [Trigger a workflow from a monitor][3]. - **Webhooks** — Call any HTTP endpoint when a monitor triggers, recovers, or changes state. Best when the action lives in a system outside Datadog and you already have an HTTPS callback. See [Webhooks integration][2]. -Either option can be added to a monitor by mentioning it in the notification message: `@workflow-` for Workflow Automation, `@webhook-` for a webhook. Monitor metadata is available as template variables (`{{topic.name}}`, `{{kafka_cluster_id.name}}`, `{{value}}`, etc.) and can be passed to the workflow or webhook payload. +Either option can be added to a monitor by mentioning it in the notification message: `@workflow-` for {{< prodname >}}Workflow Automation{{< /prodname >}}, `@webhook-` for a webhook. Monitor metadata is available as template variables (`{{topic.name}}`, `{{kafka_cluster_id.name}}`, `{{value}}`, etc.) and can be passed to the workflow or webhook payload. The following examples show conditions where automation is particularly valuable in a Kafka pipeline. @@ -64,7 +64,7 @@ The following examples show conditions where automation is particularly valuable Signals that a consumer group is falling behind its producer, with messages accumulating in the topic faster than they can be read. -**Potential action:** Run a workflow that scales the consumer group's replica count (for example, with the Kubernetes or AWS actions in Workflow Automation), or call a CI/CD or autoscaler webhook. +**Potential action:** Run a workflow that scales the consumer group's replica count (for example, with the Kubernetes or AWS actions in {{< prodname >}}Workflow Automation{{< /prodname >}}), or call a CI/CD or autoscaler webhook. ### Lag approaching retention limit diff --git a/hugo/content/en/database_monitoring/_index.md b/hugo/content/en/database_monitoring/_index.md index a2934d4302f..05b276c058f 100644 --- a/hugo/content/en/database_monitoring/_index.md +++ b/hugo/content/en/database_monitoring/_index.md @@ -130,7 +130,7 @@ Datadog Database Monitoring supports self-hosted and managed cloud versions of * ## Explore Datadog Database Monitoring -Navigate to [Database Monitoring][1] in Datadog. +Navigate to [{{< prodname >}}Database Monitoring{{< /prodname >}}][1] in Datadog. ### Dig into query performance metrics @@ -168,7 +168,7 @@ Use [`custom_queries`][7] to collect metrics from your own database tables — a ### Visualize everything on enriched dashboards -Quickly pinpoint problem areas by viewing database and system metrics together on enriched integration dashboards for both self-hosted and cloud-managed instances. Clone dashboards for customization and enhancement with your own custom metrics. Click the {{< ui >}}Dashboards{{< /ui >}} link at the top of the Query Metrics and Query Samples pages to go to the Database Monitoring dashboards. +Quickly pinpoint problem areas by viewing database and system metrics together on enriched integration dashboards for both self-hosted and cloud-managed instances. Clone dashboards for customization and enhancement with your own custom metrics. Click the {{< ui >}}Dashboards{{< /ui >}} link at the top of the Query Metrics and Query Samples pages to go to the {{< prodname >}}Database Monitoring{{< /prodname >}} dashboards. {{< img src="database_monitoring/dbm-dashboard-postgres.png" alt="Database Monitoring" style="width:100%;">}} diff --git a/hugo/content/en/database_monitoring/agent_integration_overhead.md b/hugo/content/en/database_monitoring/agent_integration_overhead.md index 149cd242430..936b241f7ae 100644 --- a/hugo/content/en/database_monitoring/agent_integration_overhead.md +++ b/hugo/content/en/database_monitoring/agent_integration_overhead.md @@ -6,7 +6,7 @@ description: Learn about the overhead of integrating the Datadog Agent with your ## Overview -Database Monitoring runs on top of the base Datadog Agent. By default, it’s configured with optimal performance settings to minimize impact on your system. However, you have the flexibility to adjust parameters like data collection frequency and query sampling to better suit your workloads. +{{< prodname >}}Database Monitoring{{< /prodname >}} runs on top of the base Datadog Agent. By default, it’s configured with optimal performance settings to minimize impact on your system. However, you have the flexibility to adjust parameters like data collection frequency and query sampling to better suit your workloads. This page contains the results of integration overhead tests conducted against databases with Datadog Database Monitoring enabled. diff --git a/hugo/content/en/database_monitoring/architecture.md b/hugo/content/en/database_monitoring/architecture.md index 416963976a5..6230f9ff7f0 100644 --- a/hugo/content/en/database_monitoring/architecture.md +++ b/hugo/content/en/database_monitoring/architecture.md @@ -16,7 +16,7 @@ further_reading: ## Overview -The steps required for setting up Database Monitoring in Datadog vary based on the type of database you're using (Postgres, MySQL, SQL Server, Oracle), and the host provider (self-hosted, AWS, Google Cloud SQL, Azure, or Oracle). To use Database Monitoring for any database on any host provider, you need the following: +The steps required for setting up {{< prodname >}}Database Monitoring{{< /prodname >}} in Datadog vary based on the type of database you're using (Postgres, MySQL, SQL Server, Oracle), and the host provider (self-hosted, AWS, Google Cloud SQL, Azure, or Oracle). To use {{< prodname >}}Database Monitoring{{< /prodname >}} for any database on any host provider, you need the following: * [A Datadog Agent][1] * Host for your Datadog Agent @@ -44,7 +44,7 @@ For self-hosted setups, you install the Agent directly onto the database host so You grant the Agent read-only access to your database, and configure the integration. The Agent must log in as a user so it can run read-only queries on your database. -Instructions for setting up Database Monitoring with a self-hosted provider: +Instructions for setting up {{< prodname >}}Database Monitoring{{< /prodname >}} with a self-hosted provider: * [Postgres][5] * [MySQL][6] @@ -55,7 +55,7 @@ Instructions for setting up Database Monitoring with a self-hosted provider: If your setup is cloud-managed (with providers such as [Amazon RDS][8] or Aurora, Google Cloud SQL, or Azure), you install the Agent on a separate host and configure it to connect to each managed instance. -Database Monitoring collects system metrics such as CPU, memory, disk usage, logs, and related telemetry directly from the cloud provider using the Datadog integration with that provider. +{{< prodname >}}Database Monitoring{{< /prodname >}} collects system metrics such as CPU, memory, disk usage, logs, and related telemetry directly from the cloud provider using the Datadog integration with that provider. {{< img src="database_monitoring/dbm_architecture_cloud-hosted.png" alt="The database instance is separate from the Agent host, which is separate from the Datadog backend. The cloud API connects to the Datadog AWS integration through the internet.">}} diff --git a/hugo/content/en/database_monitoring/bits_database_optimization.md b/hugo/content/en/database_monitoring/bits_database_optimization.md index 4c90e021862..4e08370043b 100644 --- a/hugo/content/en/database_monitoring/bits_database_optimization.md +++ b/hugo/content/en/database_monitoring/bits_database_optimization.md @@ -19,7 +19,7 @@ further_reading: Bits Database Optimization detects underperforming queries across your database fleet, identifies optimizations validated against a simulated copy of your environment, and delivers the result as a pull request fixing the exact code that triggered the query. -Optimization candidates are selected automatically from Database Monitoring telemetry, with no additional setup required. Candidates are identified by highest potential impact, focusing on query execution times, blocking queries, and regressed queries. +Optimization candidates are selected automatically from {{< prodname >}}Database Monitoring{{< /prodname >}} telemetry, with no additional setup required. Candidates are identified by highest potential impact, focusing on query execution times, blocking queries, and regressed queries.
Bits Database Optimization does not require write access to your database, and does not export or use actual data from your environment. Optimizations are empirically tested against database simulations populated with synthetic data using statistical properties of your schema.
@@ -27,7 +27,7 @@ Optimization candidates are selected automatically from Database Monitoring tele ## Prerequisites -- **Database Monitoring** is configured for the target database instances. See [Database Monitoring Setup][1]. +- **{{< prodname >}}Database Monitoring{{< /prodname >}}** is configured for the target database instances. See [Database Monitoring Setup][1]. - **Schema collection** is enabled on the target instances. - For automated PR creation: - **APM** must be configured for the services that issue the queries you want to address. See [Correlate Database Monitoring and Traces][2] for more information. diff --git a/hugo/content/en/database_monitoring/connect_dbm_and_apm.md b/hugo/content/en/database_monitoring/connect_dbm_and_apm.md index a6516cc7dd3..dcdebbe85b8 100644 --- a/hugo/content/en/database_monitoring/connect_dbm_and_apm.md +++ b/hugo/content/en/database_monitoring/connect_dbm_and_apm.md @@ -8,7 +8,7 @@ further_reading: text: 'Correlate DBM and APM telemetry to understand end-to-end query performance' --- -This guide assumes that you have configured [Database Monitoring][1] and are using [APM][2]. Connecting APM and DBM injects APM trace identifiers into DBM data collection, which allows correlation of these two data sources. This enables product features showing database information in the APM product, and APM data in the DBM product. +This guide assumes that you have configured [{{< prodname >}}Database Monitoring{{< /prodname >}}][1] and are using [APM][2]. Connecting APM and DBM injects APM trace identifiers into DBM data collection, which allows correlation of these two data sources. This enables product features showing database information in the APM product, and APM data in the DBM product. ## Before you begin @@ -494,13 +494,13 @@ Filter the Database List to display only the database hosts that your specific A {{< img src="database_monitoring/dbm_query_sample_trace_preview.png" alt="Preview the sampled APM trace that the query sample being inspected was generated from.">}} -When viewing a [Query Sample][37] in Database Monitoring, if the associated trace has been sampled by APM, you can view the DBM Sample in the context of the APM Trace. This allows you to combine DBM telemetry, including the explain plan and historical performance of the query, alongside the lineage of the span within your infrastructure to understand if a change on the database is responsible for poor application performance. +When viewing a [Query Sample][37] in {{< prodname >}}Database Monitoring{{< /prodname >}}, if the associated trace has been sampled by APM, you can view the DBM Sample in the context of the APM Trace. This allows you to combine DBM telemetry, including the explain plan and historical performance of the query, alongside the lineage of the span within your infrastructure to understand if a change on the database is responsible for poor application performance. ## Explore the DBM Connection in APM ### Visualize the downstream database hosts of APM services -On the APM page for a given service, view the direct downstream database dependencies of the service as identified by Database Monitoring, and determine if any hosts have disproportionate load that may be caused by noisy neighbors. To view a service's database dependencies: +On the APM page for a given service, view the direct downstream database dependencies of the service as identified by {{< prodname >}}Database Monitoring{{< /prodname >}}, and determine if any hosts have disproportionate load that may be caused by noisy neighbors. To view a service's database dependencies: 1. Select the service in the [Catalog][26] to open a details panel. 1. Select {{< ui >}}Service Page{{< /ui >}} in the panel. 1. On the Service page, select the {{< ui >}}Databases{{< /ui >}} section. @@ -514,7 +514,7 @@ Select the {{< ui >}}Queries{{< /ui >}} tab from the {{< ui >}}Databases{{< /ui {{< img src="database_monitoring/explain_plans_in_traces_update.png" alt="Identify inefficiencies using explain plans for database queries within traces.">}} -View historical performance of similar queries to those executed in your trace, including sampled wait events, average latency, and recently captured explain plans, to contextualize how a query is expected to perform. Determine if the behavior is abnormal and continue the investigation by pivoting to [Database Monitoring][1] for additional context about the underlying database hosts. +View historical performance of similar queries to those executed in your trace, including sampled wait events, average latency, and recently captured explain plans, to contextualize how a query is expected to perform. Determine if the behavior is abnormal and continue the investigation by pivoting to [{{< prodname >}}Database Monitoring{{< /prodname >}}][1] for additional context about the underlying database hosts. ## Further Reading diff --git a/hugo/content/en/database_monitoring/custom_metrics/_index.md b/hugo/content/en/database_monitoring/custom_metrics/_index.md index 24687f279c1..c2e3fc8cd1d 100644 --- a/hugo/content/en/database_monitoring/custom_metrics/_index.md +++ b/hugo/content/en/database_monitoring/custom_metrics/_index.md @@ -10,7 +10,7 @@ further_reading: text: "Metric Types" --- -Use `custom_queries` to collect metrics from any table the Agent's database user can read. This extends the data available in Datadog beyond the query performance metrics that Database Monitoring collects natively, such as application state tables, business counters, or queue depths. +Use `custom_queries` to collect metrics from any table the Agent's database user can read. This extends the data available in Datadog beyond the query performance metrics that {{< prodname >}}Database Monitoring{{< /prodname >}} collects natively, such as application state tables, business counters, or queue depths. ## Before you begin diff --git a/hugo/content/en/database_monitoring/custom_metrics/exploring_custom_metrics.md b/hugo/content/en/database_monitoring/custom_metrics/exploring_custom_metrics.md index d44d4133acb..82fb432e1d4 100644 --- a/hugo/content/en/database_monitoring/custom_metrics/exploring_custom_metrics.md +++ b/hugo/content/en/database_monitoring/custom_metrics/exploring_custom_metrics.md @@ -14,7 +14,7 @@ The {{< ui >}}Custom Metrics{{< /ui >}} section appears on the database instance ## Overview -If you have configured `custom_queries` in your Datadog Agent's database integration, this section automatically discovers those queries and visualizes each metric column as a timeseries graph. This lets you monitor business-specific or environment-specific database metrics alongside the standard Database Monitoring metrics, all in one place. +If you have configured `custom_queries` in your Datadog Agent's database integration, this section automatically discovers those queries and visualizes each metric column as a timeseries graph. This lets you monitor business-specific or environment-specific database metrics alongside the standard {{< prodname >}}Database Monitoring{{< /prodname >}} metrics, all in one place. ## How it works diff --git a/hugo/content/en/database_monitoring/data_collected.md b/hugo/content/en/database_monitoring/data_collected.md index c2ca4f550f9..f200f99ac73 100644 --- a/hugo/content/en/database_monitoring/data_collected.md +++ b/hugo/content/en/database_monitoring/data_collected.md @@ -5,7 +5,7 @@ further_reading: --- -When you set up Database Monitoring, the Agent collects all the metrics described in the corresponding integration documentation. This includes metrics about database state, events, failovers, connections, and buffer pools, plus the query performance metrics that Database Monitoring uses. +When you set up {{< prodname >}}Database Monitoring{{< /prodname >}}, the Agent collects all the metrics described in the corresponding integration documentation. This includes metrics about database state, events, failovers, connections, and buffer pools, plus the query performance metrics that {{< prodname >}}Database Monitoring{{< /prodname >}} uses. These are standard Datadog metrics that you can use in [dashboards][1], [monitors][2], [notebooks][3], and anywhere else you use metrics. @@ -20,7 +20,7 @@ To see a complete list of metrics collected, see the integration **Data Collecte {{< /card-grid >}}

-The metrics used for Database Monitoring views are, primarily: +The metrics used for {{< prodname >}}Database Monitoring{{< /prodname >}} views are, primarily: - **MySQL**: `mysql.queries.*` - **Postgres**: `postgresql.queries.*` - **SQL Server**: `sqlserver.queries.*` @@ -28,7 +28,7 @@ The metrics used for Database Monitoring views are, primarily: ## Normalized queries -In order to eliminate redundant information and keep track of performance trends, Database Monitoring groups together identical queries with different parameters by obfuscating the parameters. These query groups are called normalized queries and are sometimes referred to as query digests. Rather than imposing a strict query volume limitation, Datadog supports 200 normalized queries per database host. This process also ensures that no sensitive data leaks into observability tools. +In order to eliminate redundant information and keep track of performance trends, {{< prodname >}}Database Monitoring{{< /prodname >}} groups together identical queries with different parameters by obfuscating the parameters. These query groups are called normalized queries and are sometimes referred to as query digests. Rather than imposing a strict query volume limitation, Datadog supports 200 normalized queries per database host. This process also ensures that no sensitive data leaks into observability tools. For example, you may see many queries retrieving data from the same table by id: @@ -82,7 +82,7 @@ Query samples have no limits on the number of unique normalized queries tracked, ## Query retention periods -Datadog retains Database Monitoring query data based on the type of data collected: +Datadog retains {{< prodname >}}Database Monitoring{{< /prodname >}} query data based on the type of data collected: - Query Metrics are retained for 15 months. - Query Samples are retained for 15 days. diff --git a/hugo/content/en/database_monitoring/database_investigator/_index.md b/hugo/content/en/database_monitoring/database_investigator/_index.md index d612cfc5432..c9db63e62aa 100644 --- a/hugo/content/en/database_monitoring/database_investigator/_index.md +++ b/hugo/content/en/database_monitoring/database_investigator/_index.md @@ -25,11 +25,11 @@ further_reading: text: "Diagnose and resolve database performance issues faster with Database Investigator" --- -Database Monitoring contributes a set of tools and skills to [Bits Chat][1], so you can investigate the databases you monitor directly in chat. Bits Chat analyzes the telemetry Database Monitoring already collects. This includes health signals, query metrics, explain plans, instance and infrastructure metrics, calling APM services, related incidents, and recent events. For a database investigation, Bits Chat returns a structured root cause analysis with concrete remediation steps. +{{< prodname >}}Database Monitoring{{< /prodname >}} contributes a set of tools and skills to [{{< prodname >}}Bits Chat{{< /prodname >}}][1], so you can investigate the databases you monitor directly in chat. {{< prodname >}}Bits Chat{{< /prodname >}} analyzes the telemetry {{< prodname >}}Database Monitoring{{< /prodname >}} already collects. This includes health signals, query metrics, explain plans, instance and infrastructure metrics, calling APM services, related incidents, and recent events. For a database investigation, {{< prodname >}}Bits Chat{{< /prodname >}} returns a structured root cause analysis with concrete remediation steps. -Bits Chat supports investigating all databases monitored by Database Monitoring. +{{< prodname >}}Bits Chat{{< /prodname >}} supports investigating all databases monitored by {{< prodname >}}Database Monitoring{{< /prodname >}}. -Both database administrators and the platform or application teams that own database-backed services can investigate this way. Describe an issue in plain language and Bits Chat runs the investigation. Deep database expertise is not required. +Both database administrators and the platform or application teams that own database-backed services can investigate this way. Describe an issue in plain language and {{< prodname >}}Bits Chat{{< /prodname >}} runs the investigation. Deep database expertise is not required. Use Bits Chat to answer questions like: @@ -45,7 +45,7 @@ Database investigations are billed in [AI Credits][2]. ## Start an investigation -Start a database investigation from any of the following surfaces in Database Monitoring: +Start a database investigation from any of the following surfaces in {{< prodname >}}Database Monitoring{{< /prodname >}}: - The **Investigate** button on a database **Overview** page - A metric in the **Metrics** tab of a database host @@ -57,17 +57,17 @@ Start a database investigation from any of the following surfaces in Database Mo {{< img src="database_monitoring/database_investigator/investigate_metrics.png" alt="The Investigate button highlighted on a graph in the Metrics tab of a database host" style="width:100%;" >}} -Each of these automatically launches a Bits Chat session and starts an investigation scoped to what you clicked from. You do not need to write a prompt. +Each of these automatically launches a {{< prodname >}}Bits Chat{{< /prodname >}} session and starts an investigation scoped to what you clicked from. You do not need to write a prompt. You can also ask a database question from anywhere in Datadog. Click {{< ui >}}Ask Bits{{< /ui >}} in the top-right of the navigation bar, or press Cmd/Ctrl + I. -Bits Chat streams the response as it works through the investigation. It states a plan, calls Datadog services to gather evidence, and shares interim findings. The investigation ends with a structured report covering what happened, why, the supporting evidence, the root cause, and recommended fixes. +{{< prodname >}}Bits Chat{{< /prodname >}} streams the response as it works through the investigation. It states a plan, calls Datadog services to gather evidence, and shares interim findings. The investigation ends with a structured report covering what happened, why, the supporting evidence, the root cause, and recommended fixes. -You can ask follow-up questions at any point to refine the analysis. You can also paste in external context, such as an execution plan captured outside of Datadog, and Bits Chat factors it into its next steps. +You can ask follow-up questions at any point to refine the analysis. You can also paste in external context, such as an execution plan captured outside of Datadog, and {{< prodname >}}Bits Chat{{< /prodname >}} factors it into its next steps. {{< img src="database_monitoring/database_investigator/investigator_action.png" alt="Bits Chat reporting the root cause of a database issue, with immediate mitigation and durable remediation steps" style="width:100%;" >}} -If a recommended fix involves a SQL change (a new index, a query rewrite), Bits Chat includes the SQL in its response. Bits Chat never connects to your database or runs SQL against it, as recommended changes are for you to review and apply. +If a recommended fix involves a SQL change (a new index, a query rewrite), {{< prodname >}}Bits Chat{{< /prodname >}} includes the SQL in its response. {{< prodname >}}Bits Chat{{< /prodname >}} never connects to your database or runs SQL against it, as recommended changes are for you to review and apply. ## Share, save, or escalate findings @@ -79,17 +79,17 @@ After an investigation completes, you can: ## Permissions -To run database investigations, your role must have the **Bits Chat Access** and **Database Monitoring Read** permissions. Bits Chat uses your Datadog role to fetch data, so it can only access the resources you have permission to view. +To run database investigations, your role must have the **Bits Chat Access** and **Database Monitoring Read** permissions. {{< prodname >}}Bits Chat{{< /prodname >}} uses your Datadog role to fetch data, so it can only access the resources you have permission to view. ## Programmatic access -The data sources that Bits Chat uses for database investigations are also exposed through the [Datadog MCP server][5]. You can call them from your own AI tooling. +The data sources that {{< prodname >}}Bits Chat{{< /prodname >}} uses for database investigations are also exposed through the [Datadog MCP server][5]. You can call them from your own AI tooling. ## Preview investigations -Investigations you ran in Database Investigator during Preview, before database investigations moved into Bits Chat, are kept separately from your Bits Chat conversation history. They remain available until September 30, 2026. +Investigations you ran in Database Investigator during Preview, before database investigations moved into {{< prodname >}}Bits Chat{{< /prodname >}}, are kept separately from your {{< prodname >}}Bits Chat{{< /prodname >}} conversation history. They remain available until September 30, 2026. -To reach them, click the dropdown arrow next to the **Investigate** button in Database Monitoring, then select **View Preview Investigations**. +To reach them, click the dropdown arrow next to the **Investigate** button in {{< prodname >}}Database Monitoring{{< /prodname >}}, then select **View Preview Investigations**. {{< img src="database_monitoring/database_investigator/view_preview_investigations.png" alt="The dropdown next to the Investigate button, with the View Preview Investigations option" style="width:100%;" >}} diff --git a/hugo/content/en/database_monitoring/guide/aurora_autodiscovery.md b/hugo/content/en/database_monitoring/guide/aurora_autodiscovery.md index db534aaed85..92d98dd2da7 100644 --- a/hugo/content/en/database_monitoring/guide/aurora_autodiscovery.md +++ b/hugo/content/en/database_monitoring/guide/aurora_autodiscovery.md @@ -4,7 +4,7 @@ aliases: - /database_monitoring/aurora_autodiscovery --- -This guide assumes you have configured Database Monitoring for your Amazon Aurora [Postgres][1] or [MySQL][11] databases. +This guide assumes you have configured {{< prodname >}}Database Monitoring{{< /prodname >}} for your Amazon Aurora [Postgres][1] or [MySQL][11] databases. ## Before you begin @@ -18,7 +18,7 @@ Supported Agent versions Datadog's [Autodiscovery][4] enables you to configure monitoring in dynamic infrastructures. You can use this feature to monitor your Aurora clusters without having to list individual database host endpoints (for example, `postgres.d/conf.yaml`). This is especially helpful for clusters that use [Aurora Auto Scaling][6], which dynamically adjusts the number of Aurora Replicas in response to variations in connectivity or workload. Autodiscovery automatically discovers and monitors both primary and replica endpoint instances. -With Autodiscovery and Database Monitoring, you can define configuration templates for Postgres or MySQL checks and specify which clusters to apply each check to. +With Autodiscovery and {{< prodname >}}Database Monitoring{{< /prodname >}}, you can define configuration templates for Postgres or MySQL checks and specify which clusters to apply each check to. ## Enabling Autodiscovery for Aurora clusters diff --git a/hugo/content/en/database_monitoring/guide/build_apps_with_dbm_api.md b/hugo/content/en/database_monitoring/guide/build_apps_with_dbm_api.md index f2eca88985b..3aa8f044878 100644 --- a/hugo/content/en/database_monitoring/guide/build_apps_with_dbm_api.md +++ b/hugo/content/en/database_monitoring/guide/build_apps_with_dbm_api.md @@ -15,7 +15,7 @@ further_reading: text: "Metrics API" --- -Database Monitoring data is accessible through the Datadog API, which lets you build custom tooling, automated analysis pipelines, and integrations with external systems. This guide explains the data entities that DBM captures, how to query each one through the API, and how to combine them to answer questions about query performance. +{{< prodname >}}Database Monitoring{{< /prodname >}} data is accessible through the Datadog API, which lets you build custom tooling, automated analysis pipelines, and integrations with external systems. This guide explains the data entities that DBM captures, how to query each one through the API, and how to combine them to answer questions about query performance. ## Data entities diff --git a/hugo/content/en/database_monitoring/guide/database_identifier.md b/hugo/content/en/database_monitoring/guide/database_identifier.md index 02e4473b155..b3c8786d3ff 100644 --- a/hugo/content/en/database_monitoring/guide/database_identifier.md +++ b/hugo/content/en/database_monitoring/guide/database_identifier.md @@ -24,10 +24,10 @@ The default value for `database_identifier.template` is `$resolved_hostname`, wh Most users do not need to change the default value. Changing the value of `template` is primarily useful when multiple database instances are hosted on one machine. -Each distinct instance identifier is billed as a host for Database Monitoring. +Each distinct instance identifier is billed as a host for {{< prodname >}}Database Monitoring{{< /prodname >}}. ## Reported hostname -The `reported_hostname` configuration allows users to override the automatic resolution of `host` for a single database instance. This is useful when connecting to a database through a proxy to maintain the association between the Database Monitoring database instance and any available metrics for the database host. +The `reported_hostname` configuration allows users to override the automatic resolution of `host` for a single database instance. This is useful when connecting to a database through a proxy to maintain the association between the {{< prodname >}}Database Monitoring{{< /prodname >}} database instance and any available metrics for the database host. ## Examples diff --git a/hugo/content/en/database_monitoring/guide/managed_authentication.md b/hugo/content/en/database_monitoring/guide/managed_authentication.md index 1f52a19e00d..a0172db1350 100644 --- a/hugo/content/en/database_monitoring/guide/managed_authentication.md +++ b/hugo/content/en/database_monitoring/guide/managed_authentication.md @@ -4,7 +4,7 @@ aliases: - /database_monitoring/managed_authentication --- -This guide assumes that you have configured [Database Monitoring][1]. +This guide assumes that you have configured [{{< prodname >}}Database Monitoring{{< /prodname >}}][1]. [Datadog Database Monitoring (DBM)][8] allows you to view explain plans and query samples running on your database hosts. This guide shows you how to use cloud managed authentication features, such as IAM, to connect the Agent to your database. This provides a more secure way to authenticate and saves you from having to manage database credentials across your agent hosts. diff --git a/hugo/content/en/database_monitoring/guide/parameterized_queries.md b/hugo/content/en/database_monitoring/guide/parameterized_queries.md index 0f16ea7a668..33a02b314f3 100644 --- a/hugo/content/en/database_monitoring/guide/parameterized_queries.md +++ b/hugo/content/en/database_monitoring/guide/parameterized_queries.md @@ -16,7 +16,7 @@ further_reading: The Database Monitoring integrations collect aggregated query metrics, in-flight query executions, and query explain plans across your database. By default, query SQL texts and explain plans are obfuscated and normalized in the Agent before being sent to Datadog in order to protect sensitive data, which may be exposed in query parameters. -However, exposing query statements with actual parameter values provides enhanced observability and debugging capabilities. Database Monitoring currently supports query capture with parameter values on the PostgreSQL and SQL Server integrations. +However, exposing query statements with actual parameter values provides enhanced observability and debugging capabilities. {{< prodname >}}Database Monitoring{{< /prodname >}} currently supports query capture with parameter values on the PostgreSQL and SQL Server integrations. Having access to query parameters enables: @@ -30,7 +30,7 @@ Having access to query parameters enables:
Query statements and execution plans with parameterized values may contain sensitive information (for example, passwords in query parameters) or personally identifiable information. Enabling this option allows Datadog to collect and ingest raw query statements and execution plans that appear in query samples or explain plans. This option is disabled by default.
-You must configure Database Monitoring for your database instance before continuing with this guide. +You must configure {{< prodname >}}Database Monitoring{{< /prodname >}} for your database instance before continuing with this guide. Supported databases : PostgreSQL, SQL Server @@ -40,7 +40,7 @@ Supported deployments ## Permissions -To view query parameter values in the Database Monitoring UI, users need the **Database Monitoring Parameterized Queries Read** permission. This permission is located under the **Database Monitoring** section in the [Roles page][2]. This permission is enabled by default in the Datadog Admin Role, Datadog Standard Role, and Datadog Read Only Role. If your organization uses custom roles, add this permission to the appropriate role. For more information on managing permissions, see the [RBAC documentation][3]. +To view query parameter values in the Database Monitoring UI, users need the **Database Monitoring Parameterized Queries Read** permission. This permission is located under the **{{< prodname >}}Database Monitoring{{< /prodname >}}** section in the [Roles page][2]. This permission is enabled by default in the Datadog Admin Role, Datadog Standard Role, and Datadog Read Only Role. If your organization uses custom roles, add this permission to the appropriate role. For more information on managing permissions, see the [RBAC documentation][3]. ## Setup To capture SQL query text and execution plans with parameter values, update the appropriate integration `conf.yaml` file based on your database type: diff --git a/hugo/content/en/database_monitoring/guide/rds_autodiscovery.md b/hugo/content/en/database_monitoring/guide/rds_autodiscovery.md index de96781fb69..16241444882 100644 --- a/hugo/content/en/database_monitoring/guide/rds_autodiscovery.md +++ b/hugo/content/en/database_monitoring/guide/rds_autodiscovery.md @@ -4,7 +4,7 @@ aliases: - /database_monitoring/rds_autodiscovery --- -This guide assumes you have configured Database Monitoring for your Amazon RDS [Postgres][1] or [MySQL][11] databases. +This guide assumes you have configured {{< prodname >}}Database Monitoring{{< /prodname >}} for your Amazon RDS [Postgres][1] or [MySQL][11] databases. ## Before you begin @@ -18,7 +18,7 @@ Supported Agent versions Datadog's [Autodiscovery][4] enables you to configure monitoring in dynamic infrastructures. You can use this feature to monitor your RDS instances without having to list individual database host endpoints. Autodiscovery automatically discovers and monitors any RDS instances that match the tag criteria specified in your configuration. -With Autodiscovery and Database Monitoring, you can define configuration templates for Postgres or MySQL checks and specify which instances to apply each check to. +With Autodiscovery and {{< prodname >}}Database Monitoring{{< /prodname >}}, you can define configuration templates for Postgres or MySQL checks and specify which instances to apply each check to. ## Enabling Autodiscovery for RDS clusters diff --git a/hugo/content/en/database_monitoring/guide/rds_autodiscovery_terraform.md b/hugo/content/en/database_monitoring/guide/rds_autodiscovery_terraform.md index 1d71a152cb1..13a7506ddc8 100644 --- a/hugo/content/en/database_monitoring/guide/rds_autodiscovery_terraform.md +++ b/hugo/content/en/database_monitoring/guide/rds_autodiscovery_terraform.md @@ -2,7 +2,7 @@ title: Setting Up Datadog Database Monitoring with RDS Autodiscovery Using Terraform --- -This guide walks you through deploying a Datadog Agent on an EC2 instance with RDS Autodiscovery enabled, using Terraform. The Agent automatically discovers eligible RDS instances in your AWS account and begins collecting Database Monitoring metrics — no manual configuration required. +This guide walks you through deploying a Datadog Agent on an EC2 instance with RDS Autodiscovery enabled, using Terraform. The Agent automatically discovers eligible RDS instances in your AWS account and begins collecting {{< prodname >}}Database Monitoring{{< /prodname >}} metrics — no manual configuration required. ## Before you begin diff --git a/hugo/content/en/database_monitoring/guide/sql_alwayson.md b/hugo/content/en/database_monitoring/guide/sql_alwayson.md index 99d9ca352a8..d874e6af2e9 100644 --- a/hugo/content/en/database_monitoring/guide/sql_alwayson.md +++ b/hugo/content/en/database_monitoring/guide/sql_alwayson.md @@ -16,7 +16,7 @@ further_reading: The Database Monitoring AlwaysOn Clusters view enables you to detect data synchronization issues, understand availability group behavior, and identify cluster bottlenecks in SQL Server availability groups. -To access the AlwaysOn Clusters view, navigate to the {{< ui >}}APM{{< /ui >}} > {{< ui >}}Database Monitoring{{< /ui >}} > {{< ui >}}Databases{{< /ui >}} tab and select {{< ui >}}AlwaysOn Clusters{{< /ui >}}. +To access the AlwaysOn Clusters view, navigate to the {{< ui >}}APM{{< /ui >}} > {{< ui >}}{{< prodname >}}Database Monitoring{{< /prodname >}}{{< /ui >}} > {{< ui >}}Databases{{< /ui >}} tab and select {{< ui >}}AlwaysOn Clusters{{< /ui >}}. ## Determine the health of your nodes diff --git a/hugo/content/en/database_monitoring/guide/sql_deadlock.md b/hugo/content/en/database_monitoring/guide/sql_deadlock.md index 4687fdac63c..46c3e05adc4 100644 --- a/hugo/content/en/database_monitoring/guide/sql_deadlock.md +++ b/hugo/content/en/database_monitoring/guide/sql_deadlock.md @@ -19,7 +19,7 @@ A deadlock occurs when two or more processes are unable to proceed because each ## Before you begin -You must configure Database Monitoring for your [SQL Server][1] before following the steps in this guide. +You must configure {{< prodname >}}Database Monitoring{{< /prodname >}} for your [SQL Server][1] before following the steps in this guide. Supported databases @@ -106,7 +106,7 @@ Supported Agent versions ## Exploring deadlock events -To access the deadlock view, navigate to the {{< ui >}}APM{{< /ui >}} > {{< ui >}}Database Monitoring{{< /ui >}} > {{< ui >}}Databases{{< /ui >}} tab, then select a SQL Server host. Next, select the {{< ui >}}Queries{{< /ui >}} tab, then select the {{< ui >}}Deadlocks{{< /ui >}} tab. +To access the deadlock view, navigate to the {{< ui >}}APM{{< /ui >}} > {{< ui >}}{{< prodname >}}Database Monitoring{{< /prodname >}}{{< /ui >}} > {{< ui >}}Databases{{< /ui >}} tab, then select a SQL Server host. Next, select the {{< ui >}}Queries{{< /ui >}} tab, then select the {{< ui >}}Deadlocks{{< /ui >}} tab. The Deadlocks tab displays details about the victim and survivor processes, and includes a link to the deadlock diagram. **Note**: Because deadlocks occur infrequently, it's unlikely that any deadlock information will be visible right away. diff --git a/hugo/content/en/database_monitoring/guide/sql_extended_events.md b/hugo/content/en/database_monitoring/guide/sql_extended_events.md index 80583748f39..f68e1e92d74 100644 --- a/hugo/content/en/database_monitoring/guide/sql_extended_events.md +++ b/hugo/content/en/database_monitoring/guide/sql_extended_events.md @@ -33,7 +33,7 @@ This data is useful for: ## Before you begin -You must configure Database Monitoring for your [SQL Server][1] instance before continuing with this guide. +You must configure {{< prodname >}}Database Monitoring{{< /prodname >}} for your [SQL Server][1] instance before continuing with this guide. Supported databases diff --git a/hugo/content/en/database_monitoring/guide/tag_database_statements.md b/hugo/content/en/database_monitoring/guide/tag_database_statements.md index 0bc5c432c25..ffd7fac0bfd 100644 --- a/hugo/content/en/database_monitoring/guide/tag_database_statements.md +++ b/hugo/content/en/database_monitoring/guide/tag_database_statements.md @@ -4,7 +4,7 @@ aliases: - /database_monitoring/tag_database_statements --- -This guide assumes that you have configured [Database Monitoring][1]. +This guide assumes that you have configured [{{< prodname >}}Database Monitoring{{< /prodname >}}][1]. [Datadog Database Monitoring (DBM)][1] allows you to view explain plans and query samples running on your database hosts. This guide shows you how to add tags as SQL comments to your database queries, which can then be surfaced and leveraged in DBM. diff --git a/hugo/content/en/database_monitoring/query_metrics.md b/hugo/content/en/database_monitoring/query_metrics.md index d3b19e4496c..bb6cfd07b28 100644 --- a/hugo/content/en/database_monitoring/query_metrics.md +++ b/hugo/content/en/database_monitoring/query_metrics.md @@ -84,7 +84,7 @@ To see a complete list of metrics collected, see the integration Data Collected {{< /card-grid >}}

-The metrics used for Database Monitoring views are, primarily: +The metrics used for {{< prodname >}}Database Monitoring{{< /prodname >}} views are, primarily: - **MySQL**: `mysql.queries.*` - **Postgres**: `postgresql.queries.*` - **SQL Server**: `sqlserver.queries.*` diff --git a/hugo/content/en/database_monitoring/recommendations.md b/hugo/content/en/database_monitoring/recommendations.md index 7753dd4f5e7..f1bed5d633d 100644 --- a/hugo/content/en/database_monitoring/recommendations.md +++ b/hugo/content/en/database_monitoring/recommendations.md @@ -13,7 +13,7 @@ further_reading: text: "Not all index scans are equal: How we cut query latency by over 99%" --- -Database Monitoring (DBM) Recommendations draw attention to potential optimizations and problematic areas across your database fleet. +{{< prodname >}}Database Monitoring{{< /prodname >}} (DBM) Recommendations draw attention to potential optimizations and problematic areas across your database fleet. {{< img src="database_monitoring/recommendations-page.png" alt="The Recommendations page in Datadog" style="width:90%;" >}} diff --git a/hugo/content/en/database_monitoring/schema_explorer.md b/hugo/content/en/database_monitoring/schema_explorer.md index 6d160d0eaaa..461a2cbe22e 100644 --- a/hugo/content/en/database_monitoring/schema_explorer.md +++ b/hugo/content/en/database_monitoring/schema_explorer.md @@ -11,7 +11,7 @@ Schemas help you monitor performance, usage, and changes in your data models, en ## Configuration -To enable the schemas feature, add the `collect_schemas` parameter to your Database Monitoring configuration: +To enable the schemas feature, add the `collect_schemas` parameter to your {{< prodname >}}Database Monitoring{{< /prodname >}} configuration: ```yaml init_config: diff --git a/hugo/content/en/database_monitoring/setup_agent_terraform/_index.md b/hugo/content/en/database_monitoring/setup_agent_terraform/_index.md index d4ef9f292ae..de89489de58 100644 --- a/hugo/content/en/database_monitoring/setup_agent_terraform/_index.md +++ b/hugo/content/en/database_monitoring/setup_agent_terraform/_index.md @@ -10,7 +10,7 @@ further_reading: text: "dd-database-monitoring-example on GitHub" --- -Use Terraform to provision the Datadog Agent for Database Monitoring (DBM) on AWS. The Terraform examples are available in [`DataDog/dd-database-monitoring-example`][1] and cover the Agent side of the setup — each example deploys the Agent and wires it to your database. They do not provision the database itself or configure database-side parameters. +Use Terraform to provision the Datadog Agent for {{< prodname >}}Database Monitoring{{< /prodname >}} (DBM) on AWS. The Terraform examples are available in [`DataDog/dd-database-monitoring-example`][1] and cover the Agent side of the setup — each example deploys the Agent and wires it to your database. They do not provision the database itself or configure database-side parameters. Select your database to get started: diff --git a/hugo/content/en/database_monitoring/setup_agent_terraform/mysql.md b/hugo/content/en/database_monitoring/setup_agent_terraform/mysql.md index 1126722c979..ae26aec6962 100644 --- a/hugo/content/en/database_monitoring/setup_agent_terraform/mysql.md +++ b/hugo/content/en/database_monitoring/setup_agent_terraform/mysql.md @@ -25,7 +25,7 @@ terraform//// The directory tree is keyed on **cloud** rather than the hosting type — one Terraform module typically covers all of a cloud's database hosting options that share the same VPC and security-group semantics. For example, the ECS Fargate Agent against any AWS-side MySQL is available at `terraform/mysql/aws/ecs-fargate/` and works for RDS, Aurora, and self-hosted MySQL on EC2. -This page covers the **Agent** side of the setup. It does not provision the database, set database-side parameters, or create the `datadog` user inside the database. For those steps, see the per-database setup pages from [Database Monitoring][2]. +This page covers the **Agent** side of the setup. It does not provision the database, set database-side parameters, or create the `datadog` user inside the database. For those steps, see the per-database setup pages from [{{< prodname >}}Database Monitoring{{< /prodname >}}][2]. {{< tabs >}} {{% tab "ECS Fargate" %}} @@ -38,7 +38,7 @@ The Terraform module for this combination works for any MySQL database reachable - **Amazon Aurora MySQL**: The Aurora cluster writer endpoint and the Aurora cluster's security group. - **Self-hosted MySQL on EC2 in the same VPC**: The EC2 instance hostname/IP and the security group attached to the MySQL EC2 instance. -For MySQL self-hosted outside AWS (on-premises or in another cloud), this AWS-side example does not apply. Follow the manual setup in the per-database setup pages from [Database Monitoring][2]. +For MySQL self-hosted outside AWS (on-premises or in another cloud), this AWS-side example does not apply. Follow the manual setup in the per-database setup pages from [{{< prodname >}}Database Monitoring{{< /prodname >}}][2]. ## Architecture @@ -159,7 +159,7 @@ The Terraform module for this combination works for any MySQL database reachable - **Amazon Aurora MySQL**: The Aurora cluster writer endpoint and the Aurora cluster's security group. - **Self-hosted MySQL on EC2 in the same VPC**: The EC2 instance hostname/IP and the security group attached to the MySQL EC2 instance. -For MySQL self-hosted outside AWS (on-premises or in another cloud), this AWS-side example does not apply. Follow the manual setup in the per-database setup pages from [Database Monitoring][2]. +For MySQL self-hosted outside AWS (on-premises or in another cloud), this AWS-side example does not apply. Follow the manual setup in the per-database setup pages from [{{< prodname >}}Database Monitoring{{< /prodname >}}][2]. ## Architecture @@ -327,7 +327,7 @@ The Terraform module for this combination works for any MySQL database reachable - **Amazon Aurora MySQL**: The Aurora cluster writer endpoint and the Aurora cluster's security group. - **Self-hosted MySQL on EC2 in the same VPC**: The EC2 instance hostname/IP and the security group attached to the MySQL EC2 instance. -For MySQL self-hosted outside AWS (on-premises or in another cloud), this AWS-side example does not apply. Follow the manual setup in the per-database setup pages from [Database Monitoring][2]. +For MySQL self-hosted outside AWS (on-premises or in another cloud), this AWS-side example does not apply. Follow the manual setup in the per-database setup pages from [{{< prodname >}}Database Monitoring{{< /prodname >}}][2]. ## Architecture diff --git a/hugo/content/en/database_monitoring/setup_agent_terraform/postgres.md b/hugo/content/en/database_monitoring/setup_agent_terraform/postgres.md index 3c4e71dde91..f806ac48977 100644 --- a/hugo/content/en/database_monitoring/setup_agent_terraform/postgres.md +++ b/hugo/content/en/database_monitoring/setup_agent_terraform/postgres.md @@ -25,7 +25,7 @@ terraform//// The directory tree is keyed on **cloud** rather than the hosting type — one Terraform module typically covers all of a cloud's database hosting options that share the same VPC and security-group semantics. For example, the ECS Fargate Agent against any AWS-side Postgres is available at `terraform/postgres/aws/ecs-fargate/` and works for RDS, Aurora, and self-hosted Postgres on EC2. -This page covers the **Agent** side of the setup. It does not provision the database, set database-side parameters, or create the `datadog` user inside the database. For those steps, see the per-database setup pages from [Database Monitoring][2]. +This page covers the **Agent** side of the setup. It does not provision the database, set database-side parameters, or create the `datadog` user inside the database. For those steps, see the per-database setup pages from [{{< prodname >}}Database Monitoring{{< /prodname >}}][2]. {{< tabs >}} {{% tab "ECS Fargate" %}} @@ -38,7 +38,7 @@ The Terraform module for this combination works for any Postgres database reacha - **Amazon Aurora Postgres**: The Aurora cluster writer endpoint and the Aurora cluster's security group. - **Self-hosted Postgres on EC2 in the same VPC**: The EC2 instance hostname/IP and the security group attached to the Postgres EC2 instance. -For Postgres self-hosted outside AWS (on-premises or in another cloud), this AWS-side example does not apply. Follow the manual setup in the per-database setup pages from [Database Monitoring][2]. +For Postgres self-hosted outside AWS (on-premises or in another cloud), this AWS-side example does not apply. Follow the manual setup in the per-database setup pages from [{{< prodname >}}Database Monitoring{{< /prodname >}}][2]. ## Architecture @@ -160,7 +160,7 @@ The Terraform module for this combination works for any Postgres database reacha - **Amazon Aurora Postgres**: The Aurora cluster writer endpoint and the Aurora cluster's security group. - **Self-hosted Postgres on EC2 in the same VPC**: The EC2 instance hostname/IP and the security group attached to the Postgres EC2 instance. -For Postgres self-hosted outside AWS (on-premises or in another cloud), this AWS-side example does not apply. Follow the manual setup in the per-database setup pages from [Database Monitoring][2]. +For Postgres self-hosted outside AWS (on-premises or in another cloud), this AWS-side example does not apply. Follow the manual setup in the per-database setup pages from [{{< prodname >}}Database Monitoring{{< /prodname >}}][2]. ## Architecture @@ -329,7 +329,7 @@ The Terraform module for this combination works for any Postgres database reacha - **Amazon Aurora Postgres**: The Aurora cluster writer endpoint and the Aurora cluster's security group. - **Self-hosted Postgres on EC2 in the same VPC**: The EC2 instance hostname/IP and the security group attached to the Postgres EC2 instance. -For Postgres self-hosted outside AWS (on-premises or in another cloud), this AWS-side example does not apply. Follow the manual setup in the per-database setup pages from [Database Monitoring][2]. +For Postgres self-hosted outside AWS (on-premises or in another cloud), this AWS-side example does not apply. Follow the manual setup in the per-database setup pages from [{{< prodname >}}Database Monitoring{{< /prodname >}}][2]. ## Architecture diff --git a/hugo/content/en/database_monitoring/setup_clickhouse/_index.md b/hugo/content/en/database_monitoring/setup_clickhouse/_index.md index d97f1f16f96..6948f1ecc79 100644 --- a/hugo/content/en/database_monitoring/setup_clickhouse/_index.md +++ b/hugo/content/en/database_monitoring/setup_clickhouse/_index.md @@ -24,7 +24,7 @@ This feature is in preview and requires Datadog Agent v7.78 or later. Customers ### Setup instructions by hosting type -To learn how to set up Database Monitoring on a ClickHouse database, select your hosting type: +To learn how to set up {{< prodname >}}Database Monitoring{{< /prodname >}} on a ClickHouse database, select your hosting type: {{< card-grid card_width="300px" >}} {{< image-card href="/database_monitoring/setup_clickhouse/selfhosted" src="integrations_logos/clickhouse.png" alt="Self-hosted" title="Self-hosted" >}} diff --git a/hugo/content/en/database_monitoring/setup_clickhouse/cloud.md b/hugo/content/en/database_monitoring/setup_clickhouse/cloud.md index 7d06ded595e..5252febeb94 100644 --- a/hugo/content/en/database_monitoring/setup_clickhouse/cloud.md +++ b/hugo/content/en/database_monitoring/setup_clickhouse/cloud.md @@ -29,7 +29,7 @@ Supported Agent versions ## Data collected -Database Monitoring collects the following data from ClickHouse: +{{< prodname >}}Database Monitoring{{< /prodname >}} collects the following data from ClickHouse: **Database instance** : Periodic collection (every 5 minutes) of instance information including version, hostname, and configuration. Custom tags defined in the `tags` option are attached to the instance for filtering and grouping by environment, region, service, or any other custom dimensions. diff --git a/hugo/content/en/database_monitoring/setup_clickhouse/selfhosted.md b/hugo/content/en/database_monitoring/setup_clickhouse/selfhosted.md index a56a7f3d915..144fdc90231 100644 --- a/hugo/content/en/database_monitoring/setup_clickhouse/selfhosted.md +++ b/hugo/content/en/database_monitoring/setup_clickhouse/selfhosted.md @@ -32,7 +32,7 @@ Supported Agent versions ## Data collected -Database Monitoring collects the following data from ClickHouse: +{{< prodname >}}Database Monitoring{{< /prodname >}} collects the following data from ClickHouse: **Database instance** : Periodic collection (every 5 minutes) of instance information including version, hostname, and configuration. Custom tags defined in the `tags` option are attached to the instance for filtering and grouping by environment, region, cluster, or any other custom dimensions. diff --git a/hugo/content/en/database_monitoring/setup_documentdb/amazon_documentdb.md b/hugo/content/en/database_monitoring/setup_documentdb/amazon_documentdb.md index 03b2d757d90..8d99dd6c1df 100644 --- a/hugo/content/en/database_monitoring/setup_documentdb/amazon_documentdb.md +++ b/hugo/content/en/database_monitoring/setup_documentdb/amazon_documentdb.md @@ -2,7 +2,7 @@ title: Setting Up Database Monitoring for Amazon DocumentDB --- -Database Monitoring offers comprehensive insights into your Amazon DocumentDB (with MongoDB compatibility) databases by providing access to critical metrics, operation samples, explain plans, and replication state changes. To take advantage of Database Monitoring for Amazon DocumentDB, ensure that the Datadog Agent is installed and configured to connect to your Amazon DocumentDB instances. This guide outlines the steps to set up Database Monitoring for Amazon DocumentDB. +{{< prodname >}}Database Monitoring{{< /prodname >}} offers comprehensive insights into your Amazon DocumentDB (with MongoDB compatibility) databases by providing access to critical metrics, operation samples, explain plans, and replication state changes. To take advantage of {{< prodname >}}Database Monitoring{{< /prodname >}} for Amazon DocumentDB, ensure that the Datadog Agent is installed and configured to connect to your Amazon DocumentDB instances. This guide outlines the steps to set up {{< prodname >}}Database Monitoring{{< /prodname >}} for Amazon DocumentDB. ## Before you begin @@ -17,7 +17,7 @@ Supported Amazon DocumentDB cluster types ## Setup -To enable Database Monitoring for your database: +To enable {{< prodname >}}Database Monitoring{{< /prodname >}} for your database: 1. [Grant the Agent access to your Amazon DocumentDB instances](#grant-the-agent-access-to-your-amazon-documentdb-instances) 2. [Install and configure the Agent](#install-and-configure-the-agent) diff --git a/hugo/content/en/database_monitoring/setup_documentdb/troubleshooting.md b/hugo/content/en/database_monitoring/setup_documentdb/troubleshooting.md index ed87d1f15e0..1bc0e439a31 100644 --- a/hugo/content/en/database_monitoring/setup_documentdb/troubleshooting.md +++ b/hugo/content/en/database_monitoring/setup_documentdb/troubleshooting.md @@ -3,7 +3,7 @@ title: Troubleshooting DBM Setup for Amazon DocumentDB description: Troubleshoot Database Monitoring setup for Amazon DocumentDB --- -This page details common issues with setting up and using Database Monitoring with Amazon DocumentDB, and how to resolve them. Datadog recommends staying on the latest stable Agent version and adhering to the latest [setup documentation][1], as it can change with Agent version releases. +This page details common issues with setting up and using {{< prodname >}}Database Monitoring{{< /prodname >}} with Amazon DocumentDB, and how to resolve them. Datadog recommends staying on the latest stable Agent version and adhering to the latest [setup documentation][1], as it can change with Agent version releases. ## Amazon DocumentDB known limitations diff --git a/hugo/content/en/database_monitoring/setup_mongodb/mongodbatlas.md b/hugo/content/en/database_monitoring/setup_mongodb/mongodbatlas.md index 4a5d84a6c43..f0b9a6b045f 100644 --- a/hugo/content/en/database_monitoring/setup_mongodb/mongodbatlas.md +++ b/hugo/content/en/database_monitoring/setup_mongodb/mongodbatlas.md @@ -7,7 +7,7 @@ further_reading: text: "Basic MongoDB Integration" --- -Database Monitoring offers comprehensive insights into your MongoDB databases by providing access to critical metrics, slow operations, operation samples, explain plans, and replication state changes. To take advantage of Database Monitoring for MongoDB, ensure that the Datadog Agent is installed and configured to connect to your MongoDB Atlas instances. This guide outlines the steps to set up Database Monitoring for MongoDB Atlas. +{{< prodname >}}Database Monitoring{{< /prodname >}} offers comprehensive insights into your MongoDB databases by providing access to critical metrics, slow operations, operation samples, explain plans, and replication state changes. To take advantage of {{< prodname >}}Database Monitoring{{< /prodname >}} for MongoDB, ensure that the Datadog Agent is installed and configured to connect to your MongoDB Atlas instances. This guide outlines the steps to set up {{< prodname >}}Database Monitoring{{< /prodname >}} for MongoDB Atlas. ## Before you begin @@ -22,7 +22,7 @@ Supported MongoDB Atlas cluster tiers ## Setup -To enable Database Monitoring for your database: +To enable {{< prodname >}}Database Monitoring{{< /prodname >}} for your database: 1. [Grant the Agent access to your MongoDB Atlas Cluster](#grant-the-agent-access-to-your-mongodb-atlas-cluster) 2. [Install and configure the Agent](#install-and-configure-the-agent) diff --git a/hugo/content/en/database_monitoring/setup_mongodb/selfhosted.md b/hugo/content/en/database_monitoring/setup_mongodb/selfhosted.md index a9ecf4ababd..384c001cdbd 100644 --- a/hugo/content/en/database_monitoring/setup_mongodb/selfhosted.md +++ b/hugo/content/en/database_monitoring/setup_mongodb/selfhosted.md @@ -6,7 +6,7 @@ further_reading: text: "Basic MongoDB Integration" --- -Database Monitoring offers comprehensive insights into your MongoDB databases by providing access to critical metrics, slow operations, operation samples, explain plans, and replication state changes. To take advantage of Database Monitoring for MongoDB, ensure that the Datadog Agent is installed and configured to connect to your MongoDB instances. This guide outlines the steps to set up Database Monitoring for self-hosted MongoDB. +{{< prodname >}}Database Monitoring{{< /prodname >}} offers comprehensive insights into your MongoDB databases by providing access to critical metrics, slow operations, operation samples, explain plans, and replication state changes. To take advantage of {{< prodname >}}Database Monitoring{{< /prodname >}} for MongoDB, ensure that the Datadog Agent is installed and configured to connect to your MongoDB instances. This guide outlines the steps to set up {{< prodname >}}Database Monitoring{{< /prodname >}} for self-hosted MongoDB. ## Before you begin @@ -20,7 +20,7 @@ Supported MongoDB editions ## Setup -To enable Database Monitoring for your database: +To enable {{< prodname >}}Database Monitoring{{< /prodname >}} for your database: 1. [Grant the Agent access to your MongoDB instances](#grant-the-agent-access-to-your-mongodb-instances) 2. [Install and configure the Agent](#install-and-configure-the-agent) diff --git a/hugo/content/en/database_monitoring/setup_mongodb/troubleshooting.md b/hugo/content/en/database_monitoring/setup_mongodb/troubleshooting.md index af957b4a2d2..aa3432ed4b3 100644 --- a/hugo/content/en/database_monitoring/setup_mongodb/troubleshooting.md +++ b/hugo/content/en/database_monitoring/setup_mongodb/troubleshooting.md @@ -3,7 +3,7 @@ title: Troubleshoot Database Monitoring setup for MongoDB description: Troubleshoot Database Monitoring setup --- -This page explains how to resolve common issues with setting up and using Database Monitoring with MongoDB. Datadog recommends staying on the latest stable Agent version and adhering to the latest [setup documentation][1], as it can change with Agent version releases. +This page explains how to resolve common issues with setting up and using {{< prodname >}}Database Monitoring{{< /prodname >}} with MongoDB. Datadog recommends staying on the latest stable Agent version and adhering to the latest [setup documentation][1], as it can change with Agent version releases. ## Diagnosing common problems diff --git a/hugo/content/en/database_monitoring/setup_mysql/aurora.md b/hugo/content/en/database_monitoring/setup_mysql/aurora.md index ff32c6b62da..bbd1744967a 100644 --- a/hugo/content/en/database_monitoring/setup_mysql/aurora.md +++ b/hugo/content/en/database_monitoring/setup_mysql/aurora.md @@ -8,9 +8,9 @@ further_reading: --- -Database Monitoring provides deep visibility into your MySQL databases by exposing query metrics, query samples, explain plans, connection data, system metrics, and telemetry for the InnoDB storage engine. +{{< prodname >}}Database Monitoring{{< /prodname >}} provides deep visibility into your MySQL databases by exposing query metrics, query samples, explain plans, connection data, system metrics, and telemetry for the InnoDB storage engine. -The Agent collects telemetry directly from the database by logging in as a read-only user. Do the following setup to enable Database Monitoring with your MySQL database: +The Agent collects telemetry directly from the database by logging in as a read-only user. Do the following setup to enable {{< prodname >}}Database Monitoring{{< /prodname >}} with your MySQL database: 1. [Configure database parameters](#configure-mysql-settings) 1. [Grant the Agent access to the database](#grant-the-agent-access) @@ -26,8 +26,8 @@ Supported Agent versions : 7.36.1 or later Performance impact -: The default Agent configuration for Database Monitoring is conservative, but you can adjust settings such as the collection interval and query sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU.

-Database Monitoring runs as an integration on top of the base Agent ([see benchmarks][1]). +: The default Agent configuration for {{< prodname >}}Database Monitoring{{< /prodname >}} is conservative, but you can adjust settings such as the collection interval and query sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU.

+{{< prodname >}}Database Monitoring{{< /prodname >}} runs as an integration on top of the base Agent ([see benchmarks][1]). Proxies, load balancers, and connection poolers : The Datadog Agent must connect directly to the host being monitored, preferably through the instance endpoint. The Agent should not connect to the database through a proxy, load balancer, connection pooler, or the **Aurora cluster endpoint**. If connected to the cluster endpoint, the Agent collects data from one random replica, and only provides visibility into that replica. If the Agent connects to different hosts while it is running (as in the case of failover, load balancing, and so on), the Agent calculates the difference in statistics between two hosts, producing inaccurate metrics. @@ -258,7 +258,7 @@ LABEL "com.datadoghq.ad.instances"='[{"dbm": true, "host": "}}Database Monitoring{{< /prodname >}}. Follow the instructions to [enable the cluster checks][2] if not already enabled in your Kubernetes cluster. You can declare the MySQL configuration either with static files mounted in the Cluster Agent container or using service annotations: diff --git a/hugo/content/en/database_monitoring/setup_mysql/azure.md b/hugo/content/en/database_monitoring/setup_mysql/azure.md index f4f90902961..f461f7c25c9 100644 --- a/hugo/content/en/database_monitoring/setup_mysql/azure.md +++ b/hugo/content/en/database_monitoring/setup_mysql/azure.md @@ -8,9 +8,9 @@ further_reading: --- -Database Monitoring provides deep visibility into your MySQL databases by exposing query metrics, query samples, explain plans, connection data, system metrics, and telemetry for the InnoDB storage engine. +{{< prodname >}}Database Monitoring{{< /prodname >}} provides deep visibility into your MySQL databases by exposing query metrics, query samples, explain plans, connection data, system metrics, and telemetry for the InnoDB storage engine. -The Agent collects telemetry directly from the database by logging in as a read-only user. Complete the following steps to enable Database Monitoring with your MySQL database: +The Agent collects telemetry directly from the database by logging in as a read-only user. Complete the following steps to enable {{< prodname >}}Database Monitoring{{< /prodname >}} with your MySQL database: 1. [Configure database parameters](#configure-mysql-settings) 1. [Grant the Agent access to the database](#grant-the-agent-access) @@ -29,8 +29,8 @@ Supported Agent versions : 7.36.1+ Performance impact -: The default Agent configuration for Database Monitoring is conservative, but you can adjust settings such as the collection interval and query sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU.

-Database Monitoring runs as an integration on top of the base Agent ([see benchmarks][1]). +: The default Agent configuration for {{< prodname >}}Database Monitoring{{< /prodname >}} is conservative, but you can adjust settings such as the collection interval and query sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU.

+{{< prodname >}}Database Monitoring{{< /prodname >}} runs as an integration on top of the base Agent ([see benchmarks][1]). Proxies, load balancers, and connection poolers : The Datadog Agent must connect directly to the host being monitored, preferably through the instance endpoint. The Agent should not connect to the database through a proxy, load balancer, or connection pooler. If the Agent connects to different hosts while it is running (as in the case of failover, load balancing, and so on), the Agent calculates the difference in statistics between two hosts, producing inaccurate metrics. @@ -204,7 +204,7 @@ See the [MySQL integration spec][4] for additional information on setting `deplo {{% /tab %}} {{% tab "Kubernetes" %}} -If you have a Kubernetes cluster, use the [Datadog Cluster Agent][1] for Database Monitoring. +If you have a Kubernetes cluster, use the [Datadog Cluster Agent][1] for {{< prodname >}}Database Monitoring{{< /prodname >}}. Follow the instructions to [enable the cluster checks][2] if not already enabled in your Kubernetes cluster. You can declare the MySQL configuration either with static files mounted in the Cluster Agent container or using service annotations: diff --git a/hugo/content/en/database_monitoring/setup_mysql/gcsql.md b/hugo/content/en/database_monitoring/setup_mysql/gcsql.md index bb291f18586..9fd0aa677ba 100644 --- a/hugo/content/en/database_monitoring/setup_mysql/gcsql.md +++ b/hugo/content/en/database_monitoring/setup_mysql/gcsql.md @@ -8,9 +8,9 @@ further_reading: --- -Database Monitoring provides deep visibility into your MySQL databases by exposing query metrics, query samples, explain plans, connection data, system metrics, and telemetry for the InnoDB storage engine. +{{< prodname >}}Database Monitoring{{< /prodname >}} provides deep visibility into your MySQL databases by exposing query metrics, query samples, explain plans, connection data, system metrics, and telemetry for the InnoDB storage engine. -The Agent collects telemetry directly from the database by logging in as a read-only user. Do the following setup to enable Database Monitoring with your MySQL database: +The Agent collects telemetry directly from the database by logging in as a read-only user. Do the following setup to enable {{< prodname >}}Database Monitoring{{< /prodname >}} with your MySQL database: 1. [Configure database parameters](#configure-mysql-settings) 1. [Grant the Agent access to the database](#grant-the-agent-access) @@ -29,8 +29,8 @@ RAM Requirement : Datadog Database Monitoring requires at least 16 GB of RAM on the SQL instance to function properly. Performance impact -: The default Agent configuration for Database Monitoring is conservative, but you can adjust settings such as the collection interval and query sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU.

-Database Monitoring runs as an integration on top of the base Agent ([see benchmarks][1]). +: The default Agent configuration for {{< prodname >}}Database Monitoring{{< /prodname >}} is conservative, but you can adjust settings such as the collection interval and query sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU.

+{{< prodname >}}Database Monitoring{{< /prodname >}} runs as an integration on top of the base Agent ([see benchmarks][1]). Proxies, load balancers, and connection poolers : The Datadog Agent must connect directly to the host being monitored, preferably through the IP address provided in the Google Cloud console. The Agent should not connect to the database through a proxy, load balancer, or connection pooler. If the Agent connects to different hosts while it is running (as in the case of failover, load balancing, and so on), the Agent calculates the difference in statistics between two hosts, producing inaccurate metrics. @@ -273,7 +273,7 @@ See the [GCP section of the `mysql.conf.yaml` file][2] for additional informatio {{% /tab %}} {{% tab "Kubernetes" %}} -If you have a Kubernetes cluster, use the [Datadog Cluster Agent][1] for Database Monitoring. +If you have a Kubernetes cluster, use the [Datadog Cluster Agent][1] for {{< prodname >}}Database Monitoring{{< /prodname >}}. Follow the instructions to [enable the cluster checks][2] if not already enabled in your Kubernetes cluster. You can declare the MySQL configuration either with static files mounted in the Cluster Agent container or using service annotations: diff --git a/hugo/content/en/database_monitoring/setup_mysql/rds.md b/hugo/content/en/database_monitoring/setup_mysql/rds.md index 58356a20c30..f175eef8c28 100644 --- a/hugo/content/en/database_monitoring/setup_mysql/rds.md +++ b/hugo/content/en/database_monitoring/setup_mysql/rds.md @@ -10,9 +10,9 @@ further_reading: text: "Autodiscovery for RDS" --- -Database Monitoring provides deep visibility into your MySQL databases by exposing query metrics, query samples, explain plans, connection data, system metrics, and telemetry for the InnoDB storage engine. +{{< prodname >}}Database Monitoring{{< /prodname >}} provides deep visibility into your MySQL databases by exposing query metrics, query samples, explain plans, connection data, system metrics, and telemetry for the InnoDB storage engine. -The Agent collects telemetry directly from the database by logging in as a read-only user. Do the following setup to enable Database Monitoring with your MySQL database: +The Agent collects telemetry directly from the database by logging in as a read-only user. Do the following setup to enable {{< prodname >}}Database Monitoring{{< /prodname >}} with your MySQL database: 1. [Configure the AWS integration](#configure-the-aws-integration) 1. [Configure database parameters](#configure-mysql-settings) @@ -27,14 +27,14 @@ Supported MySQL versions Supported MariaDB versions : 10.5, 10.6, or 10.11

-Database Monitoring for MariaDB is supported with [known limitations][11]. +{{< prodname >}}Database Monitoring{{< /prodname >}} for MariaDB is supported with [known limitations][11]. Supported Agent versions : 7.36.1+ Performance impact -: The default Agent configuration for Database Monitoring is conservative, but you can adjust settings such as the collection interval and query sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU.

-Database Monitoring runs as an integration on top of the base Agent ([see benchmarks][1]). +: The default Agent configuration for {{< prodname >}}Database Monitoring{{< /prodname >}} is conservative, but you can adjust settings such as the collection interval and query sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU.

+{{< prodname >}}Database Monitoring{{< /prodname >}} runs as an integration on top of the base Agent ([see benchmarks][1]). Proxies, load balancers, and connection poolers : The Datadog Agent must connect directly to the host being monitored, preferably through the instance endpoint. The Agent should not connect to the database through a proxy, load balancer, or connection pooler. If the Agent connects to different hosts while it is running (as in the case of failover, load balancing, and so on), the Agent calculates the difference in statistics between two hosts, producing inaccurate metrics. @@ -275,7 +275,7 @@ LABEL "com.datadoghq.ad.instances"='[{"dbm": true, "host": "}}Database Monitoring{{< /prodname >}}. Follow the instructions to [enable the cluster checks][2] if not already enabled in your Kubernetes cluster. You can declare the MySQL configuration either with static files mounted in the Cluster Agent container or using service annotations: diff --git a/hugo/content/en/database_monitoring/setup_mysql/selfhosted.md b/hugo/content/en/database_monitoring/setup_mysql/selfhosted.md index 8d6c85b8e2e..447ce2ffa54 100644 --- a/hugo/content/en/database_monitoring/setup_mysql/selfhosted.md +++ b/hugo/content/en/database_monitoring/setup_mysql/selfhosted.md @@ -8,9 +8,9 @@ further_reading: --- -Database Monitoring provides deep visibility into your MySQL databases by exposing query metrics, query samples, explain plans, connection data, system metrics, and telemetry for the InnoDB storage engine. +{{< prodname >}}Database Monitoring{{< /prodname >}} provides deep visibility into your MySQL databases by exposing query metrics, query samples, explain plans, connection data, system metrics, and telemetry for the InnoDB storage engine. -The Agent collects telemetry directly from the database by logging in as a read-only user. Do the following setup to enable Database Monitoring with your MySQL database: +The Agent collects telemetry directly from the database by logging in as a read-only user. Do the following setup to enable {{< prodname >}}Database Monitoring{{< /prodname >}} with your MySQL database: 1. [Configure database parameters](#configure-mysql-settings) 1. [Grant the Agent access to the database](#grant-the-agent-access) @@ -23,14 +23,14 @@ Supported MySQL versions Supported MariaDB versions : 10.5, 10.6, 10.11, or 11.1

-Database Monitoring for MariaDB is supported with [known limitations][13]. +{{< prodname >}}Database Monitoring{{< /prodname >}} for MariaDB is supported with [known limitations][13]. Supported Agent versions : 7.36.1+ Performance impact -: The default Agent configuration for Database Monitoring is conservative, but you can adjust settings such as the collection interval and query sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU.

-Database Monitoring runs as an integration on top of the base Agent ([see benchmarks][1]). +: The default Agent configuration for {{< prodname >}}Database Monitoring{{< /prodname >}} is conservative, but you can adjust settings such as the collection interval and query sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU.

+{{< prodname >}}Database Monitoring{{< /prodname >}} runs as an integration on top of the base Agent ([see benchmarks][1]). Proxies, load balancers, and connection poolers : The Datadog Agent must connect directly to the host being monitored. For self-hosted databases, `127.0.0.1` or the socket is preferred. The Agent should not connect to the database through a proxy, load balancer, or connection pooler. If the Agent connects to different hosts while it is running (as in the case of failover, load balancing, and so on), the Agent calculates the difference in statistics between two hosts, producing inaccurate metrics. @@ -172,7 +172,7 @@ GRANT EXECUTE ON PROCEDURE datadog.enable_events_statements_consumers TO datadog ## Install the Agent -Installing the Datadog Agent also installs the MySQL check which is required for Database Monitoring on MySQL. If you haven't already installed the Agent for your MySQL database host, see the [Agent installation instructions][6]. +Installing the Datadog Agent also installs the MySQL check which is required for {{< prodname >}}Database Monitoring{{< /prodname >}} on MySQL. If you haven't already installed the Agent for your MySQL database host, see the [Agent installation instructions][6]. To configure this check for an Agent running on a host: diff --git a/hugo/content/en/database_monitoring/setup_mysql/troubleshooting.md b/hugo/content/en/database_monitoring/setup_mysql/troubleshooting.md index 7efade77eb6..f593c9df592 100644 --- a/hugo/content/en/database_monitoring/setup_mysql/troubleshooting.md +++ b/hugo/content/en/database_monitoring/setup_mysql/troubleshooting.md @@ -3,7 +3,7 @@ title: Troubleshoot Database Monitoring setup for MySQL description: Troubleshoot Database Monitoring setup --- -This page details common issues with setting up and using Database Monitoring with MySQL, and how to resolve them. Datadog recommends staying on the latest stable Agent version and adhering to the latest [setup documentation][1], as it can change with Agent version releases. +This page details common issues with setting up and using {{< prodname >}}Database Monitoring{{< /prodname >}} with MySQL, and how to resolve them. Datadog recommends staying on the latest stable Agent version and adhering to the latest [setup documentation][1], as it can change with Agent version releases. ## Diagnosing common problems @@ -11,7 +11,7 @@ This page details common issues with setting up and using Database Monitoring wi If you do not see any data after following the [setup instructions][1] and configuring the Agent, there is most likely an issue with the Agent configuration or API key. Ensure you are receiving data from the Agent by following the [troubleshooting guide][2]. -If you are receiving other data such as system metrics, but not Database Monitoring data (such as query metrics and query samples), there is probably an issue with the Agent or database configuration. Ensure your Agent configuration looks like the example in the [setup instructions][1], double-checking the location of the configuration files. +If you are receiving other data such as system metrics, but not {{< prodname >}}Database Monitoring{{< /prodname >}} data (such as query metrics and query samples), there is probably an issue with the Agent or database configuration. Ensure your Agent configuration looks like the example in the [setup instructions][1], double-checking the location of the configuration files. To debug, start by running the [Agent status command][3] to collect debugging information about data collected and sent to Datadog. @@ -172,7 +172,7 @@ The host is managed by Google Cloud SQL and does not support `performance_schema ### Certain queries are missing -If you have data from some queries, but are expecting to see a particular query or set of queries in Database Monitoring, follow this guide. +If you have data from some queries, but are expecting to see a particular query or set of queries in {{< prodname >}}Database Monitoring{{< /prodname >}}, follow this guide. | Possible cause | Solution | diff --git a/hugo/content/en/database_monitoring/setup_oracle/autonomous_database.md b/hugo/content/en/database_monitoring/setup_oracle/autonomous_database.md index a0bf6cfb22a..1cb29ceafcb 100644 --- a/hugo/content/en/database_monitoring/setup_oracle/autonomous_database.md +++ b/hugo/content/en/database_monitoring/setup_oracle/autonomous_database.md @@ -19,8 +19,8 @@ The Agent collects telemetry directly from the database by logging in as a read- {{% dbm-supported-oracle-agent-version %}} Performance impact -: The default Agent configuration for Database Monitoring is conservative, but you can adjust settings such as the collection interval and query sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU.

-Database Monitoring runs as an integration on top of the base Agent ([see benchmarks][1]). +: The default Agent configuration for {{< prodname >}}Database Monitoring{{< /prodname >}} is conservative, but you can adjust settings such as the collection interval and query sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU.

+{{< prodname >}}Database Monitoring{{< /prodname >}} runs as an integration on top of the base Agent ([see benchmarks][1]). Proxies, load balancers, and connection poolers : The Agent must connect directly to the host being monitored. The Agent should not connect to the database through a proxy, load balancer, or connection pooler. Each Agent must have knowledge of the underlying hostname and should stick to a single host for its lifetime, even in cases of failover. If the Datadog Agent connects to different hosts while it is running, the values of metrics will be incorrect. @@ -30,7 +30,7 @@ Data security considerations ## Setup -Complete the following to enable Database Monitoring with your Oracle database: +Complete the following to enable {{< prodname >}}Database Monitoring{{< /prodname >}} with your Oracle database: 1. [Create the Datadog user](#create-the-datadog-user) 1. [Grant the user access to the database](#grant-the-user-access-to-the-database) @@ -137,7 +137,7 @@ After all Agent configuration is complete, [restart the Datadog Agent][4]. ## Custom queries -Database Monitoring supports custom queries for Oracle databases. See the [conf.yaml.example][12] to learn more about the configuration options available. +{{< prodname >}}Database Monitoring{{< /prodname >}} supports custom queries for Oracle databases. See the [conf.yaml.example][12] to learn more about the configuration options available.
Running custom queries may result in additional costs or fees assessed by Oracle.
diff --git a/hugo/content/en/database_monitoring/setup_oracle/exadata.md b/hugo/content/en/database_monitoring/setup_oracle/exadata.md index 639bd09be14..d2f8bbddb60 100644 --- a/hugo/content/en/database_monitoring/setup_oracle/exadata.md +++ b/hugo/content/en/database_monitoring/setup_oracle/exadata.md @@ -19,8 +19,8 @@ The Agent collects telemetry directly from the database by logging in as a read- {{% dbm-supported-oracle-agent-version %}} Performance impact -: The default Agent configuration for Database Monitoring is conservative, but you can adjust settings such as the collection interval and query sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU.

-Database Monitoring runs as an integration on top of the base Agent ([see benchmarks][6]). +: The default Agent configuration for {{< prodname >}}Database Monitoring{{< /prodname >}} is conservative, but you can adjust settings such as the collection interval and query sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU.

+{{< prodname >}}Database Monitoring{{< /prodname >}} runs as an integration on top of the base Agent ([see benchmarks][6]). Proxies, load balancers, and connection poolers : The Agent must connect directly to the host being monitored. The Agent should not connect to the database through a proxy, load balancer, or connection pooler. Each Agent must have knowledge of the underlying hostname and should stick to a single host for its lifetime, even in cases of failover. If the Datadog Agent connects to different hosts while it is running, the values of metrics will be incorrect. @@ -30,7 +30,7 @@ Data security considerations ## Setup -Complete the following to enable Database Monitoring with your Oracle database: +Complete the following to enable {{< prodname >}}Database Monitoring{{< /prodname >}} with your Oracle database: 1. [Create the Datadog user](#create-the-datadog-user) 1. [Install the Agent](#install-the-agent) @@ -67,7 +67,7 @@ Configure the Agent by following the instructions for [self-hosted Oracle databa ## Custom queries -Database Monitoring supports custom queries for Oracle databases. See the [conf.yaml.example][5] to learn more about the configuration options available. +{{< prodname >}}Database Monitoring{{< /prodname >}} supports custom queries for Oracle databases. See the [conf.yaml.example][5] to learn more about the configuration options available.
Running custom queries may result in additional costs or fees assessed by Oracle.
diff --git a/hugo/content/en/database_monitoring/setup_oracle/rac.md b/hugo/content/en/database_monitoring/setup_oracle/rac.md index 49dd109e27d..06747ff9a8e 100644 --- a/hugo/content/en/database_monitoring/setup_oracle/rac.md +++ b/hugo/content/en/database_monitoring/setup_oracle/rac.md @@ -19,8 +19,8 @@ The Agent collects telemetry directly from the database by logging in as a read- {{% dbm-supported-oracle-agent-version %}} Performance impact -: The default Agent configuration for Database Monitoring is conservative, but you can adjust settings such as the collection interval and query sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU.

-Database Monitoring runs as an integration on top of the base Agent ([see benchmarks][6]). +: The default Agent configuration for {{< prodname >}}Database Monitoring{{< /prodname >}} is conservative, but you can adjust settings such as the collection interval and query sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU.

+{{< prodname >}}Database Monitoring{{< /prodname >}} runs as an integration on top of the base Agent ([see benchmarks][6]). Proxies, load balancers, and connection poolers : The Agent must connect directly to the host being monitored. The Agent should not connect to the database through a proxy, load balancer, or connection pooler. Each Agent must have knowledge of the underlying hostname and should stick to a single host for its lifetime, even in cases of failover. If the Datadog Agent connects to different hosts while it is running, the values of metrics will be incorrect. @@ -30,7 +30,7 @@ Data security considerations ## Setup -Complete the following to enable Database Monitoring with your Oracle database: +Complete the following to enable {{< prodname >}}Database Monitoring{{< /prodname >}} with your Oracle database: 1. [Create the Datadog user](#create-the-datadog-user) 1. [Install the Agent](#install-the-agent) @@ -166,7 +166,7 @@ Set the `rac_cluster` configuration parameter to the name of your RAC cluster or ## Custom queries -Database Monitoring supports custom queries for Oracle databases. See the [conf.yaml.example][5] to learn more about the configuration options available. +{{< prodname >}}Database Monitoring{{< /prodname >}} supports custom queries for Oracle databases. See the [conf.yaml.example][5] to learn more about the configuration options available.
Running custom queries may result in additional costs or fees assessed by Oracle.
diff --git a/hugo/content/en/database_monitoring/setup_oracle/rds.md b/hugo/content/en/database_monitoring/setup_oracle/rds.md index 9a6e4c48f70..36129feb8dd 100644 --- a/hugo/content/en/database_monitoring/setup_oracle/rds.md +++ b/hugo/content/en/database_monitoring/setup_oracle/rds.md @@ -19,8 +19,8 @@ The Agent collects telemetry directly from the database by logging in as a read- {{% dbm-supported-oracle-agent-version %}} Performance impact -: The default Agent configuration for Database Monitoring is conservative, but you can adjust settings such as the collection interval and query sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU.

-Database Monitoring runs as an integration on top of the base Agent ([see benchmarks][1]). +: The default Agent configuration for {{< prodname >}}Database Monitoring{{< /prodname >}} is conservative, but you can adjust settings such as the collection interval and query sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU.

+{{< prodname >}}Database Monitoring{{< /prodname >}} runs as an integration on top of the base Agent ([see benchmarks][1]). Proxies, load balancers, and connection poolers : The Agent must connect directly to the host being monitored. The Agent should not connect to the database through a proxy, load balancer, or connection pooler. Each Agent must have knowledge of the underlying hostname and should stick to a single host for its lifetime, even in cases of failover. If the Datadog Agent connects to different hosts while it is running, the values of metrics will be incorrect. @@ -30,7 +30,7 @@ Data security considerations ## Setup -Complete the following steps to enable Database Monitoring with your Oracle database: +Complete the following steps to enable {{< prodname >}}Database Monitoring{{< /prodname >}} with your Oracle database: 1. [Create the Datadog user](#create-the-datadog-user) 1. [Grant the user access to the database](#grant-the-user-access-to-the-database) @@ -125,7 +125,7 @@ Once all Agent configuration is complete, [restart the Datadog Agent][2]. ## Custom queries -Database Monitoring supports custom queries for Oracle databases. See the [conf.yaml.example][9] to learn more about the configuration options available. +{{< prodname >}}Database Monitoring{{< /prodname >}} supports custom queries for Oracle databases. See the [conf.yaml.example][9] to learn more about the configuration options available.
Running custom queries may result in additional costs or fees assessed by Oracle.
diff --git a/hugo/content/en/database_monitoring/setup_oracle/selfhosted.md b/hugo/content/en/database_monitoring/setup_oracle/selfhosted.md index 72988674e43..bc0040e9109 100644 --- a/hugo/content/en/database_monitoring/setup_oracle/selfhosted.md +++ b/hugo/content/en/database_monitoring/setup_oracle/selfhosted.md @@ -18,8 +18,8 @@ The Agent collects telemetry directly from the database by logging in as a read- {{% dbm-supported-oracle-agent-version %}} Performance impact -: The default Agent configuration for Database Monitoring is conservative, but you can adjust settings such as the collection interval and query sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU.

-Database Monitoring runs as an integration on top of the base Agent ([see benchmarks][6]). +: The default Agent configuration for {{< prodname >}}Database Monitoring{{< /prodname >}} is conservative, but you can adjust settings such as the collection interval and query sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU.

+{{< prodname >}}Database Monitoring{{< /prodname >}} runs as an integration on top of the base Agent ([see benchmarks][6]). Proxies, load balancers, and connection poolers : The Agent must connect directly to the host being monitored. The Agent should not connect to the database through a proxy, load balancer, or connection pooler. Each Agent must have knowledge of the underlying hostname and should stick to a single host for its lifetime, even in cases of failover. If the Datadog Agent connects to different hosts while it is running, the values of metrics will be incorrect. @@ -29,7 +29,7 @@ Data security considerations ## Setup -Complete the following to enable Database Monitoring with your Oracle database: +Complete the following to enable {{< prodname >}}Database Monitoring{{< /prodname >}} with your Oracle database: 1. [Create the Datadog user](#create-the-datadog-user) 1. [Grant the user access to the database](#grant-the-user-access-to-the-database) @@ -164,7 +164,7 @@ Once all Agent configuration is complete, [restart the Datadog Agent][9]. ## Custom queries -Database Monitoring supports custom queries for Oracle databases. See the [conf.yaml.example][4] to learn more about the configuration options available. +{{< prodname >}}Database Monitoring{{< /prodname >}} supports custom queries for Oracle databases. See the [conf.yaml.example][4] to learn more about the configuration options available.
Running custom queries may result in additional costs or fees assessed by Oracle.
diff --git a/hugo/content/en/database_monitoring/setup_oracle/troubleshooting.md b/hugo/content/en/database_monitoring/setup_oracle/troubleshooting.md index 2f68a906a7a..6562feaf67f 100644 --- a/hugo/content/en/database_monitoring/setup_oracle/troubleshooting.md +++ b/hugo/content/en/database_monitoring/setup_oracle/troubleshooting.md @@ -3,7 +3,7 @@ title: Troubleshooting DBM Setup for Oracle description: Troubleshoot Database Monitoring setup for Oracle --- -This page details common issues with setting up and using Database Monitoring with Oracle, and how to resolve them. Datadog recommends staying on the latest stable Agent version and adhering to the latest [setup documentation][1], as it can change with Agent version releases. +This page details common issues with setting up and using {{< prodname >}}Database Monitoring{{< /prodname >}} with Oracle, and how to resolve them. Datadog recommends staying on the latest stable Agent version and adhering to the latest [setup documentation][1], as it can change with Agent version releases. ## Common issues diff --git a/hugo/content/en/database_monitoring/setup_postgres/_index.md b/hugo/content/en/database_monitoring/setup_postgres/_index.md index f54556af1ce..b791e8a7605 100644 --- a/hugo/content/en/database_monitoring/setup_postgres/_index.md +++ b/hugo/content/en/database_monitoring/setup_postgres/_index.md @@ -21,7 +21,7 @@ disable_sidebar: true ### Setup instructions by hosting type -To learn how to set up Database Monitoring on a Postgres database, select your hosting type: +To learn how to set up {{< prodname >}}Database Monitoring{{< /prodname >}} on a Postgres database, select your hosting type: {{< card-grid card_width="200px" >}} {{< image-card href="/database_monitoring/setup_postgres/selfhosted" src="integrations_logos/postgres.png" alt="Selfhosted" title="Self-hosted" >}} diff --git a/hugo/content/en/database_monitoring/setup_postgres/alloydb.md b/hugo/content/en/database_monitoring/setup_postgres/alloydb.md index 5e71daea591..3b70528d658 100644 --- a/hugo/content/en/database_monitoring/setup_postgres/alloydb.md +++ b/hugo/content/en/database_monitoring/setup_postgres/alloydb.md @@ -10,9 +10,9 @@ further_reading: text: "Capturing SQL Query Parameter Values" --- -Database Monitoring provides deep visibility into your Postgres databases by exposing query metrics, query samples, explain plans, database states, failovers, and events. +{{< prodname >}}Database Monitoring{{< /prodname >}} provides deep visibility into your Postgres databases by exposing query metrics, query samples, explain plans, database states, failovers, and events. -The Agent collects telemetry directly from the database by logging in as a read-only user. Do the following setup to enable Database Monitoring with your Postgres database: +The Agent collects telemetry directly from the database by logging in as a read-only user. Do the following setup to enable {{< prodname >}}Database Monitoring{{< /prodname >}} with your Postgres database: 1. [Configure database parameters](#configure-postgres-settings) 1. [Grant the Agent access to the database](#grant-the-agent-access) @@ -28,8 +28,8 @@ Supported Agent versions : 7.36.1+ Performance impact -: The default Agent configuration for Database Monitoring is conservative, but you can adjust settings such as the collection interval and query sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU.

-Database Monitoring runs as an integration on top of the base Agent ([see benchmarks][1]). +: The default Agent configuration for {{< prodname >}}Database Monitoring{{< /prodname >}} is conservative, but you can adjust settings such as the collection interval and query sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU.

+{{< prodname >}}Database Monitoring{{< /prodname >}} runs as an integration on top of the base Agent ([see benchmarks][1]). Proxies, load balancers, and connection poolers : The Datadog Agent must connect directly to the host being monitored. For self-hosted databases, use `127.0.0.1` or the socket. The Agent should not connect to the database through a proxy, load balancer, or connection pooler such as `pgbouncer`. If the Agent connects to different hosts while it is running (as in the case of failover, load balancing, and so on), the Agent calculates the difference in statistics between two hosts, producing inaccurate metrics. @@ -179,7 +179,7 @@ To monitor AlloyDB hosts, install the Datadog Agent in your infrastructure and c {{< tabs >}} {{% tab "Host" %}} -To configure Database Monitoring metrics collection for an Agent running on a host, for example when you provision a small GCE instance for the Agent to collect from a Google AlloyDB database: +To configure {{< prodname >}}Database Monitoring{{< /prodname >}} metrics collection for an Agent running on a host, for example when you provision a small GCE instance for the Agent to collect from a Google AlloyDB database: 1. Edit the `postgres.d/conf.yaml` file to point to your `host` / `port` and set the masters to monitor. See the [sample postgres.d/conf.yaml][1] for all available configuration options. The location of the `postgres.d` directory depends on your operating system. For more information, see [Agent configuration directory][3]. @@ -262,7 +262,7 @@ To avoid exposing the `datadog` user's password in plain text, use the Agent's [ {{% /tab %}} {{% tab "Kubernetes" %}} -If you're running a Kubernetes cluster, use the [Datadog Cluster Agent][1] to enable Database Monitoring. +If you're running a Kubernetes cluster, use the [Datadog Cluster Agent][1] to enable {{< prodname >}}Database Monitoring{{< /prodname >}}. **Note**: Make sure [cluster checks][2] are enabled for your Datadog Cluster Agent before proceeding. diff --git a/hugo/content/en/database_monitoring/setup_postgres/aurora.md b/hugo/content/en/database_monitoring/setup_postgres/aurora.md index 58038598e62..adfc0c52b05 100644 --- a/hugo/content/en/database_monitoring/setup_postgres/aurora.md +++ b/hugo/content/en/database_monitoring/setup_postgres/aurora.md @@ -10,9 +10,9 @@ further_reading: text: "Capturing SQL Query Parameter Values" --- -Database Monitoring provides deep visibility into your Postgres databases by exposing query metrics, query samples, explain plans, database states, failovers, and events. +{{< prodname >}}Database Monitoring{{< /prodname >}} provides deep visibility into your Postgres databases by exposing query metrics, query samples, explain plans, database states, failovers, and events. -The Agent collects telemetry directly from the database by logging in as a read-only user. Do the following setup to enable Database Monitoring with your Postgres database: +The Agent collects telemetry directly from the database by logging in as a read-only user. Do the following setup to enable {{< prodname >}}Database Monitoring{{< /prodname >}} with your Postgres database: 1. [Configure database parameters](#configure-postgres-settings) 1. [Grant the Agent access to the database](#grant-the-agent-access) @@ -28,8 +28,8 @@ Supported Agent versions : 7.36.1+ Performance impact -: The default Agent configuration for Database Monitoring is conservative, but you can adjust settings such as the collection interval and query sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU.

-Database Monitoring runs as an integration on top of the base Agent ([see benchmarks][1]). +: The default Agent configuration for {{< prodname >}}Database Monitoring{{< /prodname >}} is conservative, but you can adjust settings such as the collection interval and query sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU.

+{{< prodname >}}Database Monitoring{{< /prodname >}} runs as an integration on top of the base Agent ([see benchmarks][1]). Proxies, load balancers, and connection poolers : The Datadog Agent must connect directly to the host being monitored. For self-hosted databases, use `127.0.0.1` or the socket. The Agent should not connect to the database through a proxy, load balancer, connection pooler such as `pgbouncer`, or the **Aurora cluster endpoint**. If connected to the cluster endpoint, the Agent collects data from one random replica, and only provides visibility into that replica. If the Agent connects to different hosts while it is running (as in the case of failover, load balancing, and so on), the Agent calculates the difference in statistics between two hosts, producing inaccurate metrics. @@ -244,7 +244,7 @@ Otherwise, Datadog recommends using the [Autodiscovery setup instructions for Au {{< tabs >}} {{% tab "Host" %}} -To configure collecting Database Monitoring metrics for an Agent running on a host, for example when you provision a small EC2 instance for the Agent to collect from an Aurora database: +To configure collecting {{< prodname >}}Database Monitoring{{< /prodname >}} metrics for an Agent running on a host, for example when you provision a small EC2 instance for the Agent to collect from an Aurora database: 1. Edit the `postgres.d/conf.yaml` file to point to your `host` / `port` and set the masters to monitor. See the [sample postgres.d/conf.yaml][1] for all available configuration options. @@ -344,7 +344,7 @@ To avoid exposing the `datadog` user's password in plain text, use the Agent's [ {{% /tab %}} {{% tab "Kubernetes" %}} -If you're running a Kubernetes cluster, use the [Datadog Cluster Agent][1] to enable Database Monitoring. +If you're running a Kubernetes cluster, use the [Datadog Cluster Agent][1] to enable {{< prodname >}}Database Monitoring{{< /prodname >}}. **Note**: Make sure [cluster checks][2] are enabled for your Datadog Cluster Agent before proceeding. diff --git a/hugo/content/en/database_monitoring/setup_postgres/azure.md b/hugo/content/en/database_monitoring/setup_postgres/azure.md index acf31831ef3..aba8f9f5052 100644 --- a/hugo/content/en/database_monitoring/setup_postgres/azure.md +++ b/hugo/content/en/database_monitoring/setup_postgres/azure.md @@ -10,9 +10,9 @@ further_reading: text: "Capturing SQL Query Parameter Values" --- -Database Monitoring provides deep visibility into your Postgres databases by exposing query metrics, query samples, explain plans, database states, failovers, and events. +{{< prodname >}}Database Monitoring{{< /prodname >}} provides deep visibility into your Postgres databases by exposing query metrics, query samples, explain plans, database states, failovers, and events. -The Agent collects telemetry directly from the database by logging in as a read-only user. Do the following setup to enable Database Monitoring with your Postgres database: +The Agent collects telemetry directly from the database by logging in as a read-only user. Do the following setup to enable {{< prodname >}}Database Monitoring{{< /prodname >}} with your Postgres database: 1. [Configure database parameters](#configure-postgres-settings) 1. [Grant the Agent access to the database](#grant-the-agent-access) @@ -31,8 +31,8 @@ Supported Agent versions : 7.36.1+ Performance impact -: The default Agent configuration for Database Monitoring is conservative, but you can adjust settings such as the collection interval and query sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU.

-Database Monitoring runs as an integration on top of the base Agent ([see benchmarks][1]). +: The default Agent configuration for {{< prodname >}}Database Monitoring{{< /prodname >}} is conservative, but you can adjust settings such as the collection interval and query sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU.

+{{< prodname >}}Database Monitoring{{< /prodname >}} runs as an integration on top of the base Agent ([see benchmarks][1]). Proxies, load balancers, and connection poolers : The Datadog Agent must connect directly to the host being monitored. For self-hosted databases, use `127.0.0.1` or the socket. The Agent should not connect to the database through a proxy, load balancer, or connection pooler such as `pgbouncer`. If the Agent connects to different hosts while it is running (as in the case of failover, load balancing, and so on), the Agent calculates the difference in statistics between two hosts, producing inaccurate metrics. @@ -276,7 +276,7 @@ To monitor Azure Postgres databases, install the Datadog Agent in your infrastru {{< tabs >}} {{% tab "Host" %}} -To configure collecting Database Monitoring metrics for an Agent running on a host, for example when you provision a small virtual machine for the Agent to collect from an Azure database: +To configure collecting {{< prodname >}}Database Monitoring{{< /prodname >}} metrics for an Agent running on a host, for example when you provision a small virtual machine for the Agent to collect from an Azure database: 1. Edit the `postgres.d/conf.yaml` file to point to your `host` / `port` and set the masters to monitor. See the [sample postgres.d/conf.yaml][1] for all available configuration options. ```yaml @@ -365,7 +365,7 @@ For Postgres 9.6, add the following settings to the instance config where host a {{% /tab %}} {{% tab "Kubernetes" %}} -If you're running a Kubernetes cluster, use the [Datadog Cluster Agent][1] to enable Database Monitoring. +If you're running a Kubernetes cluster, use the [Datadog Cluster Agent][1] to enable {{< prodname >}}Database Monitoring{{< /prodname >}}. **Note**: Make sure [cluster checks][2] are enabled for your Datadog Cluster Agent before proceeding. diff --git a/hugo/content/en/database_monitoring/setup_postgres/gcsql.md b/hugo/content/en/database_monitoring/setup_postgres/gcsql.md index 436e9683e1a..5a64ebf7fe5 100644 --- a/hugo/content/en/database_monitoring/setup_postgres/gcsql.md +++ b/hugo/content/en/database_monitoring/setup_postgres/gcsql.md @@ -10,9 +10,9 @@ further_reading: text: "Capturing SQL Query Parameter Values" --- -Database Monitoring provides deep visibility into your Postgres databases by exposing query metrics, query samples, explain plans, database states, failovers, and events. +{{< prodname >}}Database Monitoring{{< /prodname >}} provides deep visibility into your Postgres databases by exposing query metrics, query samples, explain plans, database states, failovers, and events. -The Agent collects telemetry directly from the database by logging in as a read-only user. Do the following setup to enable Database Monitoring with your Postgres database: +The Agent collects telemetry directly from the database by logging in as a read-only user. Do the following setup to enable {{< prodname >}}Database Monitoring{{< /prodname >}} with your Postgres database: 1. [Configure database parameters](#configure-postgres-settings) 1. [Grant the Agent access to the database](#grant-the-agent-access) @@ -28,8 +28,8 @@ Supported Agent versions : 7.36.1+ Performance impact -: The default Agent configuration for Database Monitoring is conservative, but you can adjust settings such as the collection interval and query sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU.

-Database Monitoring runs as an integration on top of the base Agent ([see benchmarks][1]). +: The default Agent configuration for {{< prodname >}}Database Monitoring{{< /prodname >}} is conservative, but you can adjust settings such as the collection interval and query sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU.

+{{< prodname >}}Database Monitoring{{< /prodname >}} runs as an integration on top of the base Agent ([see benchmarks][1]). Proxies, load balancers, and connection poolers : The Datadog Agent must connect directly to the host being monitored. For self-hosted databases, use `127.0.0.1` or the socket. The Agent should not connect to the database through a proxy, load balancer, or connection pooler such as `pgbouncer`. If the Agent connects to different hosts while it is running (as in the case of failover, load balancing, and so on), the Agent calculates the difference in statistics between two hosts, producing inaccurate metrics. @@ -178,7 +178,7 @@ To monitor Cloud SQL hosts, install the Datadog Agent in your infrastructure and {{< tabs >}} {{% tab "Host" %}} -To configure Database Monitoring metrics collection for an Agent running on a host, for example when you provision a small GCE instance for the Agent to collect from a Google Cloud SQL database: +To configure {{< prodname >}}Database Monitoring{{< /prodname >}} metrics collection for an Agent running on a host, for example when you provision a small GCE instance for the Agent to collect from a Google Cloud SQL database: 1. Edit the `postgres.d/conf.yaml` file to point to your `host` / `port` and set the masters to monitor. See the [sample postgres.d/conf.yaml][1] for all available configuration options. The location of the `postgres.d` directory depends on your operating system. For more information, see [Agent configuration directory][3]. @@ -261,7 +261,7 @@ To avoid exposing the `datadog` user's password in plain text, use the Agent's [ {{% /tab %}} {{% tab "Kubernetes" %}} -If you're running a Kubernetes cluster, use the [Datadog Cluster Agent][1] to enable Database Monitoring. +If you're running a Kubernetes cluster, use the [Datadog Cluster Agent][1] to enable {{< prodname >}}Database Monitoring{{< /prodname >}}. **Note**: Make sure [cluster checks][2] are enabled for your Datadog Cluster Agent before proceeding. diff --git a/hugo/content/en/database_monitoring/setup_postgres/heroku.md b/hugo/content/en/database_monitoring/setup_postgres/heroku.md index abf94992cb4..7943a371e54 100644 --- a/hugo/content/en/database_monitoring/setup_postgres/heroku.md +++ b/hugo/content/en/database_monitoring/setup_postgres/heroku.md @@ -14,9 +14,9 @@ further_reading: This guide assumes that you have configured the [Datadog Heroku buildpack][1] in your application dynos. -[Datadog Database Monitoring][2] allows you to view query metrics and explain plans from all of your databases in a single place. This guide covers how to set up Database Monitoring for a [Heroku Postgres managed database][3]. +[Datadog Database Monitoring][2] allows you to view query metrics and explain plans from all of your databases in a single place. This guide covers how to set up {{< prodname >}}Database Monitoring{{< /prodname >}} for a [Heroku Postgres managed database][3]. -*Note*: Only databases in the [Standard and Premium plans][4] publish metrics used by the integration. Not all the features of Database Monitoring are available when used with a Postgres instance in the Hobby plan. +*Note*: Only databases in the [Standard and Premium plans][4] publish metrics used by the integration. Not all the features of {{< prodname >}}Database Monitoring{{< /prodname >}} are available when used with a Postgres instance in the Hobby plan. ## Preparing the Postgres Database @@ -107,7 +107,7 @@ For tuning options, see [Advanced Configuration][8]. Configure the Datadog Agent to enable the Postgres integration, using one of the following two options. -**Option A**: Use a buildpack to create a static Postgres configuration that cannot be modified. In addition, Database Monitoring may be enabled through this method. +**Option A**: Use a buildpack to create a static Postgres configuration that cannot be modified. In addition, {{< prodname >}}Database Monitoring{{< /prodname >}} may be enabled through this method. **Option B**: Create a custom Postgres configuration with the ability to enable additional features that aren’t available through the static configuration in Option A. @@ -123,7 +123,7 @@ git commit --allow-empty -m "enabled postgres integration" git push heroku main ``` -To enable both the Postgres integration and Database Monitoring, set `DD_ENABLE_HEROKU_POSTGRES` and `DD_ENABLE_DBM` to true: +To enable both the Postgres integration and {{< prodname >}}Database Monitoring{{< /prodname >}}, set `DD_ENABLE_HEROKU_POSTGRES` and `DD_ENABLE_DBM` to true: ``` shell heroku config:set DD_ENABLE_HEROKU_POSTGRES=true @@ -132,7 +132,7 @@ git commit --allow-empty -m "enabled postgres integration with DBM" git push heroku main ``` -The Postgres integration and, if enabled, Database Monitoring, will begin collecting metrics. +The Postgres integration and, if enabled, {{< prodname >}}Database Monitoring{{< /prodname >}}, will begin collecting metrics. {{% /tab %}} {{% tab "Option B: Custom Configuration" %}} diff --git a/hugo/content/en/database_monitoring/setup_postgres/rds/_index.md b/hugo/content/en/database_monitoring/setup_postgres/rds/_index.md index b088979702a..bb794801e83 100644 --- a/hugo/content/en/database_monitoring/setup_postgres/rds/_index.md +++ b/hugo/content/en/database_monitoring/setup_postgres/rds/_index.md @@ -13,9 +13,9 @@ further_reading: text: "Capturing SQL Query Parameter Values" --- -Database Monitoring provides deep visibility into your Postgres databases by exposing query metrics, query samples, explain plans, database states, failovers, and events. +{{< prodname >}}Database Monitoring{{< /prodname >}} provides deep visibility into your Postgres databases by exposing query metrics, query samples, explain plans, database states, failovers, and events. -The Agent collects telemetry directly from the database by logging in as a read-only user. Do the following setup to enable Database Monitoring with your Postgres database: +The Agent collects telemetry directly from the database by logging in as a read-only user. Do the following setup to enable {{< prodname >}}Database Monitoring{{< /prodname >}} with your Postgres database: 1. [Configure the AWS integration](#configure-the-aws-integration) 1. [Configure database parameters](#configure-postgres-settings) @@ -36,8 +36,8 @@ Supported Agent versions : 7.36.1+ Performance impact -: The default Agent configuration for Database Monitoring is conservative, but you can adjust settings such as the collection interval and query sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU.

-Database Monitoring runs as an integration on top of the base Agent ([see benchmarks][1]). +: The default Agent configuration for {{< prodname >}}Database Monitoring{{< /prodname >}} is conservative, but you can adjust settings such as the collection interval and query sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU.

+{{< prodname >}}Database Monitoring{{< /prodname >}} runs as an integration on top of the base Agent ([see benchmarks][1]). Proxies, load balancers, and connection poolers : The Datadog Agent must connect directly to the host being monitored. For self-hosted databases, use `127.0.0.1` or the socket. The Agent should not connect to the database through a proxy, load balancer, or connection pooler such as `pgbouncer`. If the Agent connects to different hosts while it is running (as in the case of failover, load balancing, and so on), the Agent calculates the difference in statistics between two hosts, producing inaccurate metrics. @@ -295,7 +295,7 @@ To monitor RDS hosts, install the Datadog Agent in your infrastructure and confi {{< tabs >}} {{% tab "Host" %}} -To configure collecting Database Monitoring metrics for an Agent running on a host, for example when you provision a small EC2 instance for the Agent to collect from an RDS database: +To configure collecting {{< prodname >}}Database Monitoring{{< /prodname >}} metrics for an Agent running on a host, for example when you provision a small EC2 instance for the Agent to collect from an RDS database: 1. Edit the `postgres.d/conf.yaml` file to point to your `host` / `port` and set the masters to monitor. See the [sample postgres.d/conf.yaml][1] for all available configuration options. @@ -435,7 +435,7 @@ To avoid exposing the `datadog` user's password in plain text, use the Agent's [ {{% /tab %}} {{% tab "Kubernetes" %}} -If you're running a Kubernetes cluster, use the [Datadog Cluster Agent][1] to enable Database Monitoring. +If you're running a Kubernetes cluster, use the [Datadog Cluster Agent][1] to enable {{< prodname >}}Database Monitoring{{< /prodname >}}. **Note**: Make sure [cluster checks][2] are enabled for your Datadog Cluster Agent before proceeding. diff --git a/hugo/content/en/database_monitoring/setup_postgres/selfhosted.md b/hugo/content/en/database_monitoring/setup_postgres/selfhosted.md index 45500f02e50..47db8c689e1 100644 --- a/hugo/content/en/database_monitoring/setup_postgres/selfhosted.md +++ b/hugo/content/en/database_monitoring/setup_postgres/selfhosted.md @@ -13,9 +13,9 @@ further_reading: text: "Debug PostgreSQL query latency faster with EXPLAIN ANALYZE in Datadog Database Monitoring" --- -Database Monitoring provides deep visibility into your Postgres databases by exposing query metrics, query samples, explain plans, database states, failovers, and events. +{{< prodname >}}Database Monitoring{{< /prodname >}} provides deep visibility into your Postgres databases by exposing query metrics, query samples, explain plans, database states, failovers, and events. -The Agent collects telemetry directly from the database by logging in as a read-only user. Do the following setup to enable Database Monitoring with your Postgres database: +The Agent collects telemetry directly from the database by logging in as a read-only user. Do the following setup to enable {{< prodname >}}Database Monitoring{{< /prodname >}} with your Postgres database: 1. [Configure database parameters](#configure-postgres-settings) 1. [Grant the Agent access to the database](#grant-the-agent-access) @@ -33,8 +33,8 @@ Supported Agent versions : 7.36.1+ Performance impact -: The default Agent configuration for Database Monitoring is conservative, but you can adjust settings such as the collection interval and query sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU.

-Database Monitoring runs as an integration on top of the base Agent ([see benchmarks][2]). +: The default Agent configuration for {{< prodname >}}Database Monitoring{{< /prodname >}} is conservative, but you can adjust settings such as the collection interval and query sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU.

+{{< prodname >}}Database Monitoring{{< /prodname >}} runs as an integration on top of the base Agent ([see benchmarks][2]). Proxies, load balancers, and connection poolers : The Datadog Agent must connect directly to the host being monitored. For self-hosted databases, use `127.0.0.1` or the socket. The Agent should not connect to the database through a proxy, load balancer, or connection pooler such as `pgbouncer`. If the Agent connects to different hosts while it is running (as in the case of failover, load balancing, and so on), the Agent calculates the difference in statistics between two hosts, producing inaccurate metrics. @@ -256,7 +256,7 @@ When it prompts for a password, use the password you entered when you created th ## Install the Agent -Installing the Datadog Agent also installs the Postgres check, which is required for Database Monitoring on Postgres. +Installing the Datadog Agent also installs the Postgres check, which is required for {{< prodname >}}Database Monitoring{{< /prodname >}} on Postgres. If you haven't installed the Agent, see the [Agent installation instructions][8]. Then, continue with the instructions for your installation method. Edit the Agent's `conf.d/postgres.d/conf.yaml` file to point to the Postgres instance you want to monitor. For a complete list of configuration options, see the [sample postgres.d/conf.yaml][9]. diff --git a/hugo/content/en/database_monitoring/setup_postgres/supabase/_index.md b/hugo/content/en/database_monitoring/setup_postgres/supabase/_index.md index c60913b26c9..1d035e5b404 100644 --- a/hugo/content/en/database_monitoring/setup_postgres/supabase/_index.md +++ b/hugo/content/en/database_monitoring/setup_postgres/supabase/_index.md @@ -4,11 +4,11 @@ description: Setting up Database Monitoring on a Supabase Postgres database. disable_sidebar: true --- -Database Monitoring provides visibility into your Supabase Postgres databases by exposing query performance metrics, query samples, and database states. +{{< prodname >}}Database Monitoring{{< /prodname >}} provides visibility into your Supabase Postgres databases by exposing query performance metrics, query samples, and database states. Select your setup method to get started: {{< card-grid card_width="350px" >}} - {{< image-card href="/database_monitoring/setup_postgres/supabase/cloud" src="integrations_logos/supabase.png" alt="Supabase Cloud" title="Supabase Cloud (Recommended)" subtitle="Set up Database Monitoring through the Supabase Cloud integration tile. No Agent installation required." >}} - {{< image-card href="/database_monitoring/setup_postgres/supabase/agent" src="integrations_logos/supabase.png" alt="Supabase Self-Hosted" title="Supabase Self-Hosted" subtitle="Set up Database Monitoring with the Datadog Agent for self-hosted Supabase deployments." >}} + {{< image-card href="/database_monitoring/setup_postgres/supabase/cloud" src="integrations_logos/supabase.png" alt="Supabase Cloud" title="Supabase Cloud (Recommended)" subtitle="Set up {{< prodname >}}Database Monitoring{{< /prodname >}} through the Supabase Cloud integration tile. No Agent installation required." >}} + {{< image-card href="/database_monitoring/setup_postgres/supabase/agent" src="integrations_logos/supabase.png" alt="Supabase Self-Hosted" title="Supabase Self-Hosted" subtitle="Set up {{< prodname >}}Database Monitoring{{< /prodname >}} with the Datadog Agent for self-hosted Supabase deployments." >}} {{< /card-grid >}} diff --git a/hugo/content/en/database_monitoring/setup_postgres/supabase/agent.md b/hugo/content/en/database_monitoring/setup_postgres/supabase/agent.md index a189bb12dd1..b4bb6f78815 100644 --- a/hugo/content/en/database_monitoring/setup_postgres/supabase/agent.md +++ b/hugo/content/en/database_monitoring/setup_postgres/supabase/agent.md @@ -7,9 +7,9 @@ further_reading: text: 'Basic Postgres Integration' --- -Database Monitoring provides deep visibility into your Supabase databases by exposing query metrics, query samples, explain plans, database states, failovers, and events. +{{< prodname >}}Database Monitoring{{< /prodname >}} provides deep visibility into your Supabase databases by exposing query metrics, query samples, explain plans, database states, failovers, and events. -The Agent collects telemetry directly from the database by logging in as a read-only user. Do the following setup to enable Database Monitoring with your Supabase database: +The Agent collects telemetry directly from the database by logging in as a read-only user. Do the following setup to enable {{< prodname >}}Database Monitoring{{< /prodname >}} with your Supabase database: 1. [Grant the Agent access to the database](#grant-the-agent-access) 1. [Install the Agent](#install-the-agent) @@ -23,8 +23,8 @@ Supported Agent versions : 7.69.1+ Performance impact -: The default Agent configuration for Database Monitoring is conservative, but you can adjust settings such as the collection interval and query sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU.

-Database Monitoring runs as an integration on top of the base Agent ([see benchmarks][2]). +: The default Agent configuration for {{< prodname >}}Database Monitoring{{< /prodname >}} is conservative, but you can adjust settings such as the collection interval and query sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU.

+{{< prodname >}}Database Monitoring{{< /prodname >}} runs as an integration on top of the base Agent ([see benchmarks][2]). Proxies, load balancers, and connection poolers : The Datadog Agent must connect directly to the host being monitored. For self-hosted databases, `127.0.0.1` or the socket is preferred. The Agent should not connect to the database through a proxy, load balancer, or connection pooler such as Supabase’s Dedicated Pooler (pgbouncer) or Session Pooler (Supavisor). If the Agent connects to different hosts while it is running (as in the case of failover, load balancing, and so on), the Agent calculates the difference in statistics between two hosts, producing inaccurate metrics. @@ -173,7 +173,7 @@ When prompted for a password, use the password you created for the `datadog` use ## Install the Agent -Installing the Datadog Agent also installs the Postgres check, which is required for Database Monitoring on Supabase. +Installing the Datadog Agent also installs the Postgres check, which is required for {{< prodname >}}Database Monitoring{{< /prodname >}} on Supabase. If you haven't installed the Agent, see the [Agent installation instructions][8]. Then, return here to continue with the instructions for your installation method.
Supabase’s default direct connection string is only valid on IPv6 networks. diff --git a/hugo/content/en/database_monitoring/setup_postgres/supabase/cloud.md b/hugo/content/en/database_monitoring/setup_postgres/supabase/cloud.md index bcbfa590987..7233a126863 100644 --- a/hugo/content/en/database_monitoring/setup_postgres/supabase/cloud.md +++ b/hugo/content/en/database_monitoring/setup_postgres/supabase/cloud.md @@ -13,7 +13,7 @@ further_reading: text: 'Supabase Self-Hosted Setup (Agent Installation)' --- -Database Monitoring for Supabase Cloud provides visibility into your Supabase databases by exposing query performance metrics and query samples — without requiring a self-hosted Datadog Agent. +{{< prodname >}}Database Monitoring{{< /prodname >}} for Supabase Cloud provides visibility into your Supabase databases by exposing query performance metrics and query samples — without requiring a self-hosted Datadog Agent.
For self-hosted Supabase deployments that require a Datadog Agent, see Supabase Self-Hosted Setup.
@@ -35,13 +35,13 @@ Database Monitoring for Supabase Cloud provides visibility into your Supabase da 1. Enter your {{< ui >}}Personal Access Token{{< /ui >}}. 1. Click {{< ui >}}Save{{< /ui >}}. -Datadog connects to your Supabase project and begins collecting Database Monitoring telemetry. No Agent installation is required. +Datadog connects to your Supabase project and begins collecting {{< prodname >}}Database Monitoring{{< /prodname >}} telemetry. No Agent installation is required. -
Each Supabase project must be configured separately. Adding new projects to a connected Supabase account does not automatically enable Database Monitoring.
+
Each Supabase project must be configured separately. Adding new projects to a connected Supabase account does not automatically enable {{< prodname >}}Database Monitoring{{< /prodname >}}.
## Data collected -After you enable Database Monitoring, Datadog collects the following telemetry from your Supabase Cloud database: +After you enable {{< prodname >}}Database Monitoring{{< /prodname >}}, Datadog collects the following telemetry from your Supabase Cloud database: ### Query performance metrics Sourced from `pg_stat_statements`, collected every 5 seconds: @@ -68,7 +68,7 @@ Collected every 5 minutes: ## Validate -After setup, navigate to the [Database Monitoring][2] page in Datadog to see your Supabase database queries and performance metrics. +After setup, navigate to the [{{< prodname >}}Database Monitoring{{< /prodname >}}][2] page in Datadog to see your Supabase database queries and performance metrics. {{< img src="database_monitoring/supabase_cloud_product.png" alt="Database Monitoring overview for a Supabase Cloud instance" style="width:100%;" >}} diff --git a/hugo/content/en/database_monitoring/setup_postgres/troubleshooting.md b/hugo/content/en/database_monitoring/setup_postgres/troubleshooting.md index e7a6a81ea3d..79ac53def49 100644 --- a/hugo/content/en/database_monitoring/setup_postgres/troubleshooting.md +++ b/hugo/content/en/database_monitoring/setup_postgres/troubleshooting.md @@ -3,7 +3,7 @@ title: Troubleshooting DBM Setup for Postgres description: Troubleshoot Database Monitoring setup for Postgres --- -This page details common issues with setting up and using Database Monitoring with Postgres, and how to resolve them. Datadog recommends staying on the latest stable Agent version and adhering to the latest [setup documentation][1], as it can change with Agent version releases. +This page details common issues with setting up and using {{< prodname >}}Database Monitoring{{< /prodname >}} with Postgres, and how to resolve them. Datadog recommends staying on the latest stable Agent version and adhering to the latest [setup documentation][1], as it can change with Agent version releases. ## Diagnosing common problems @@ -11,7 +11,7 @@ This page details common issues with setting up and using Database Monitoring wi If you do not see any data after following the [setup instructions][1] and configuring the Agent, there is most likely an issue with the Agent configuration or API key. Ensure you are receiving data from the Agent by following the [troubleshooting guide][2]. -If you are receiving other data such as system metrics, but not Database Monitoring data (such as query metrics and query samples), there is probably an issue with the Agent or database configuration. Ensure your Agent configuration looks like the example in the [setup instructions][1], double-checking the location of the configuration files. +If you are receiving other data such as system metrics, but not {{< prodname >}}Database Monitoring{{< /prodname >}} data (such as query metrics and query samples), there is probably an issue with the Agent or database configuration. Ensure your Agent configuration looks like the example in the [setup instructions][1], double-checking the location of the configuration files. To debug, start by running the [Agent status command][3] to collect debugging information about data collected and sent to Datadog. @@ -113,7 +113,7 @@ ALTER ROLE datadog SET search_path = "$user",public,}}Database Monitoring{{< /prodname >}} that you're expecting to see, follow this guide. | Possible cause | Solution | |----------------------------------------|-------------------------------------------| | For Postgres 9.6, if you only see queries executed by the datadog user, then the instance configuration is likely missing some settings. | For monitoring instances on Postgres 9.6, the Datadog Agent instance config must use the settings `pg_stat_statements_view: datadog.pg_stat_statements()` and `pg_stat_activity_view: datadog.pg_stat_activity()` based on the functions created in the initial setup guide. These functions must be created in all databases. | @@ -244,7 +244,7 @@ For more information, see the appropriate version of the [Postgres `contrib` doc ### Queries from Agent are slow and/or have a high impact on the database -The default Agent configuration for Database Monitoring is conservative, but you can adjust settings such as the collection interval and query sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU. Below are possible reasons for Agent queries to require more resources. +The default Agent configuration for {{< prodname >}}Database Monitoring{{< /prodname >}} is conservative, but you can adjust settings such as the collection interval and query sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU. Below are possible reasons for Agent queries to require more resources. #### High value for `pg_stat_statements.max` {#high-pg-stat-statements-max-configuration} The recommended value for `pg_stat_statements.max` is `10000`. Setting this configuration to a higher value @@ -252,7 +252,7 @@ may cause the collection query to take longer to run, which can lead to query ti ### Databases are missing or merged in the list -Datadog tags database metrics with the `db` tag to identify which database each metric belongs to. Applying a custom `db` tag overrides this per-database value, so all metrics share a single `db` value. Your databases then collapse into one entry, and individual databases may not appear in the Databases list in Database Monitoring. +Datadog tags database metrics with the `db` tag to identify which database each metric belongs to. Applying a custom `db` tag overrides this per-database value, so all metrics share a single `db` value. Your databases then collapse into one entry, and individual databases may not appear in the Databases list in {{< prodname >}}Database Monitoring{{< /prodname >}}. To restore per-database `db` values, remove any custom `db` tags so that Datadog can populate the tag per database. diff --git a/hugo/content/en/database_monitoring/setup_sql_server/azure.md b/hugo/content/en/database_monitoring/setup_sql_server/azure.md index 63196b2d8d5..12cd9db0973 100644 --- a/hugo/content/en/database_monitoring/setup_sql_server/azure.md +++ b/hugo/content/en/database_monitoring/setup_sql_server/azure.md @@ -19,9 +19,9 @@ further_reading: text: "Capturing SQL Query Parameter Values" --- -Database Monitoring provides deep visibility into your Microsoft SQL Server databases by exposing query metrics, query samples, explain plans, database states, failovers, and events. +{{< prodname >}}Database Monitoring{{< /prodname >}} provides deep visibility into your Microsoft SQL Server databases by exposing query metrics, query samples, explain plans, database states, failovers, and events. -Do the following steps to enable Database Monitoring with your database: +Do the following steps to enable {{< prodname >}}Database Monitoring{{< /prodname >}} with your database: 1. [Grant the Agent access to the database](#grant-the-agent-access) 2. [Install and configure the Agent](#install-and-configure-the-agent) @@ -310,7 +310,7 @@ Use the `service` and `env` tags to link your database telemetry to other teleme [6]: https://app.datadoghq.com/databases {{% /tab %}} {{% tab "Kubernetes" %}} -If you're running a Kubernetes cluster, use the [Datadog Cluster Agent][1] to enable Database Monitoring. If cluster checks aren’t already enabled, [follow these instructions][2] to enable them before proceeding. +If you're running a Kubernetes cluster, use the [Datadog Cluster Agent][1] to enable {{< prodname >}}Database Monitoring{{< /prodname >}}. If cluster checks aren’t already enabled, [follow these instructions][2] to enable them before proceeding. ### Operator diff --git a/hugo/content/en/database_monitoring/setup_sql_server/gcsql.md b/hugo/content/en/database_monitoring/setup_sql_server/gcsql.md index 4dab2b32983..abe31f4924d 100644 --- a/hugo/content/en/database_monitoring/setup_sql_server/gcsql.md +++ b/hugo/content/en/database_monitoring/setup_sql_server/gcsql.md @@ -16,9 +16,9 @@ further_reading: text: "Capturing SQL Query Parameter Values" --- -Database Monitoring provides deep visibility into your Microsoft SQL Server databases by exposing query metrics, query samples, explain plans, database states, failovers, and events. +{{< prodname >}}Database Monitoring{{< /prodname >}} provides deep visibility into your Microsoft SQL Server databases by exposing query metrics, query samples, explain plans, database states, failovers, and events. -Complete the following steps to enable Database Monitoring with your database: +Complete the following steps to enable {{< prodname >}}Database Monitoring{{< /prodname >}} with your database: 1. [Grant the Agent access to the database](#grant-the-agent-access) 2. [Install and configure the Agent](#install-and-configure-the-agent) @@ -228,7 +228,7 @@ Use the `service` and `env` tags to link your database telemetry to other teleme [6]: https://app.datadoghq.com/databases {{% /tab %}} {{% tab "Kubernetes" %}} -If you're using a Kubernetes cluster, use the [Datadog Cluster Agent][1] for Database Monitoring. If cluster checks aren’t already enabled, [follow these instructions][2] to enable them before proceeding.. +If you're using a Kubernetes cluster, use the [Datadog Cluster Agent][1] for {{< prodname >}}Database Monitoring{{< /prodname >}}. If cluster checks aren’t already enabled, [follow these instructions][2] to enable them before proceeding.. ### Operator diff --git a/hugo/content/en/database_monitoring/setup_sql_server/rds.md b/hugo/content/en/database_monitoring/setup_sql_server/rds.md index 3cfa36bb7b7..d81148eb753 100644 --- a/hugo/content/en/database_monitoring/setup_sql_server/rds.md +++ b/hugo/content/en/database_monitoring/setup_sql_server/rds.md @@ -19,9 +19,9 @@ further_reading: text: "Capturing SQL Query Parameter Values" --- -Database Monitoring provides deep visibility into your Microsoft SQL Server databases by exposing query metrics, query samples, explain plans, database states, failovers, and events. +{{< prodname >}}Database Monitoring{{< /prodname >}} provides deep visibility into your Microsoft SQL Server databases by exposing query metrics, query samples, explain plans, database states, failovers, and events. -Do the following steps to enable Database Monitoring with your database: +Do the following steps to enable {{< prodname >}}Database Monitoring{{< /prodname >}} with your database: 1. [Configure the AWS integration](#configure-the-aws-integration) 1. [Grant the Agent access](#grant-the-agent-access) @@ -247,7 +247,7 @@ Use the `service` and `env` tags to link your database telemetry to other teleme {{% tab "Kubernetes" %}} {{% dbm-alwayson-cloud-hosted %}} -If you're running a Kubernetes cluster, use the [Datadog Cluster Agent][1] to enable Database Monitoring. If cluster checks aren’t already enabled, [follow these instructions][2] to enable them before proceeding. +If you're running a Kubernetes cluster, use the [Datadog Cluster Agent][1] to enable {{< prodname >}}Database Monitoring{{< /prodname >}}. If cluster checks aren’t already enabled, [follow these instructions][2] to enable them before proceeding. ### Operator diff --git a/hugo/content/en/database_monitoring/setup_sql_server/selfhosted.md b/hugo/content/en/database_monitoring/setup_sql_server/selfhosted.md index fdfd9d4826d..021da815b01 100644 --- a/hugo/content/en/database_monitoring/setup_sql_server/selfhosted.md +++ b/hugo/content/en/database_monitoring/setup_sql_server/selfhosted.md @@ -26,9 +26,9 @@ further_reading: --- -Database Monitoring provides deep visibility into your Microsoft SQL Server databases by exposing query metrics, query samples, explain plans, database states, failovers, and events. +{{< prodname >}}Database Monitoring{{< /prodname >}} provides deep visibility into your Microsoft SQL Server databases by exposing query metrics, query samples, explain plans, database states, failovers, and events. -Do the following steps to enable Database Monitoring with your database: +Do the following steps to enable {{< prodname >}}Database Monitoring{{< /prodname >}} with your database: 1. [Grant the Agent access](#grant-the-agent-access) 1. [Install the Agent](#install-the-agent) diff --git a/hugo/content/en/database_monitoring/setup_sql_server/troubleshooting.md b/hugo/content/en/database_monitoring/setup_sql_server/troubleshooting.md index e3f10c64444..46b1852d386 100644 --- a/hugo/content/en/database_monitoring/setup_sql_server/troubleshooting.md +++ b/hugo/content/en/database_monitoring/setup_sql_server/troubleshooting.md @@ -3,7 +3,7 @@ title: Troubleshooting DBM Setup for SQL Server description: Troubleshoot Database Monitoring setup for SQL Server --- -This page details common issues with setting up and using Database Monitoring with SQL Server, and how to resolve them. Datadog recommends staying on the latest stable Agent version and adhering to the latest [setup documentation][1], as it can change with Agent version releases. +This page details common issues with setting up and using {{< prodname >}}Database Monitoring{{< /prodname >}} with SQL Server, and how to resolve them. Datadog recommends staying on the latest stable Agent version and adhering to the latest [setup documentation][1], as it can change with Agent version releases. ## Diagnosing common connection issues {#common-connection-issues} diff --git a/hugo/content/en/database_monitoring/troubleshooting.md b/hugo/content/en/database_monitoring/troubleshooting.md index a4c2df25f52..a788c416ad9 100644 --- a/hugo/content/en/database_monitoring/troubleshooting.md +++ b/hugo/content/en/database_monitoring/troubleshooting.md @@ -4,7 +4,7 @@ description: Troubleshoot Database Monitoring setup --- -This page details database agnostic common issues with setting up and using Database Monitoring, and how to resolve them. Datadog recommends staying on the latest stable Agent version and adhering to the latest [setup documentation][1], as it can change with agent version releases. +This page details database agnostic common issues with setting up and using {{< prodname >}}Database Monitoring{{< /prodname >}}, and how to resolve them. Datadog recommends staying on the latest stable Agent version and adhering to the latest [setup documentation][1], as it can change with agent version releases. For specific database setup troubleshooting, use the corresponding troubleshooting page: diff --git a/hugo/content/en/datadog_cloudcraft/_index.md b/hugo/content/en/datadog_cloudcraft/_index.md index 0379e8797a3..64eba80cd51 100644 --- a/hugo/content/en/datadog_cloudcraft/_index.md +++ b/hugo/content/en/datadog_cloudcraft/_index.md @@ -39,7 +39,7 @@ Cloudcraft's core functionality is its ability to generate detailed architecture - For the best experience, Datadog strongly recommends using the AWS-managed [`SecurityAudit`][5] policy, or the more permissive [`ReadOnlyAccess`][6] policy. - Viewing content on the [Security overlay][10] requires additional products to be enabled: - - To view security misconfigurations and identity risks, [Cloud Security][3] must be enabled. + - To view security misconfigurations and identity risks, [{{< prodname >}}Cloud Security{{< /prodname >}}][3] must be enabled. - To view sensitive data, [Sensitive Data Scanner][12] must be enabled. For a user to turn the layer on, they must have the [`data_scanner_read`][13] permission. **Note**: Cloudcraft adapts to restrictive permissions by excluding inaccessible resources. For example, if you don't grant permission to list S3 buckets, the diagram excludes those buckets. If permissions block certain resources, an alert displays in the UI. @@ -71,7 +71,7 @@ Enabling resource collection can impact your AWS CloudWatch costs. To avoid thes 4. On the {{< ui >}}Resource Collection{{< /ui >}} tab, ensure the {{< ui >}}Enable Resource Collection{{< /ui >}} toggle is enabled. - Viewing content on the [Security overlay][10] requires additional products to be enabled: - - To view security misconfigurations and identity risks, [Cloud Security][3] must be enabled. + - To view security misconfigurations and identity risks, [{{< prodname >}}Cloud Security{{< /prodname >}}][3] must be enabled. [3]: /security/cloud_security_management [10]: /datadog_cloudcraft/overlays#security @@ -89,9 +89,9 @@ Enabling resource collection can impact your AWS CloudWatch costs. To avoid thes 3. Enable the {{< ui >}}Enable Resource Collection{{< /ui >}} toggle. - Viewing content on the [Security overlay][10] requires additional products to be enabled: - - To view security misconfigurations and identity risks, [Cloud Security][3] must be enabled. + - To view security misconfigurations and identity risks, [{{< prodname >}}Cloud Security{{< /prodname >}}][3] must be enabled. -**Note**: The [Cloud Cost Management][11] Cost view and sensitive data in the Security overlay are not available for GCP accounts. The CCM Recommendations view is supported. +**Note**: The [{{< prodname >}}Cloud Cost Management{{< /prodname >}}][11] Cost view and sensitive data in the Security overlay are not available for GCP accounts. The CCM Recommendations view is supported. [3]: /security/cloud_security_management [10]: /datadog_cloudcraft/overlays#security @@ -107,7 +107,7 @@ Enabling resource collection can impact your AWS CloudWatch costs. To avoid thes - Add your OCI tenancy to the [Oracle Cloud Infrastructure integration][20] and enable [resource collection][21]. - Viewing content on the [Security overlay][10] requires additional products to be enabled: - - To view security misconfigurations and identity risks, [Cloud Security][3] must be enabled. + - To view security misconfigurations and identity risks, [{{< prodname >}}Cloud Security{{< /prodname >}}][3] must be enabled. [3]: /security/cloud_security_management [10]: /datadog_cloudcraft/overlays#security @@ -209,7 +209,7 @@ Learn how to navigate between [built-in overlays][4] to view your architecture f - [Infrastructure][8]: High-level view of services and resources. - [Observability][9]: Indicates which hosts have the Agent installed and what observability features are enabled. - [Security][10]: IAM, firewall, and security group visibility. -- [Cloud Cost Management][11]: Track and optimize resource spend. +- [{{< prodname >}}Cloud Cost Management{{< /prodname >}}][11]: Track and optimize resource spend. - [APM][15]: Visualize distributed traces between cloud resources (AWS only, Preview). ## Further reading diff --git a/hugo/content/en/datadog_cloudcraft/overlays/observability.md b/hugo/content/en/datadog_cloudcraft/overlays/observability.md index a6adb1c9456..51cd67ba813 100644 --- a/hugo/content/en/datadog_cloudcraft/overlays/observability.md +++ b/hugo/content/en/datadog_cloudcraft/overlays/observability.md @@ -20,7 +20,7 @@ further_reading:
The Observability overlay is not available for vSphere accounts.
-The Observability overlay shows where the Datadog Agent is installed and what features are enabled per host, such as Application Performance Monitoring (APM), Cloud Network Monitoring (CNM), Log Management, and more. This helps you to assess visibility gaps across your environment. +The Observability overlay shows where the Datadog Agent is installed and what features are enabled per host, such as Application Performance Monitoring (APM), Cloud Network Monitoring (CNM), {{< prodname >}}Log Management{{< /prodname >}}, and more. This helps you to assess visibility gaps across your environment. ## Take action on resources diff --git a/hugo/content/en/datadog_cloudcraft/overlays/security.md b/hugo/content/en/datadog_cloudcraft/overlays/security.md index 66c9d114131..6f4d75c0b14 100644 --- a/hugo/content/en/datadog_cloudcraft/overlays/security.md +++ b/hugo/content/en/datadog_cloudcraft/overlays/security.md @@ -20,7 +20,7 @@ further_reading:
The Security overlay is not available for vSphere accounts.
-The Security overlay highlights potential security exposures in your architecture, grouping resources by Region, VPC, and Security Group. It displays security findings detected by Cloud Security, helping you: +The Security overlay highlights potential security exposures in your architecture, grouping resources by Region, VPC, and Security Group. It displays security findings detected by {{< prodname >}}Cloud Security{{< /prodname >}}, helping you: - Identify security issues directly in infrastructure diagrams - Analyze findings in context, so you can prioritize remediation: diff --git a/hugo/content/en/ddsql_editor/_index.md b/hugo/content/en/ddsql_editor/_index.md index e5f463526d4..3350568cc46 100644 --- a/hugo/content/en/ddsql_editor/_index.md +++ b/hugo/content/en/ddsql_editor/_index.md @@ -32,7 +32,7 @@ With [DDSQL Editor][1], you can get deeper visibility into your telemetry by que You can also export the results of a DDSQL query to visualize in a Dashboard or Notebook or to automate in a Datadog Workflow through [DDSQL Action](#save-and-share-queries). -You can run DDSQL queries from AI agents using the [Datadog MCP Server][9] `ddsql` toolset (Preview). +You can run DDSQL queries from AI agents using the [{{< prodname >}}Datadog MCP Server{{< /prodname >}}][9] `ddsql` toolset (Preview). {{< img src="/ddsql_editor/query-results-avg-cpu-usage-by-host.png" alt="The result of a SQL query showing average CPU usage by host on the DDSQL page in Datadog" style="width:100%;" >}} @@ -75,7 +75,7 @@ Export the results of a saved query to: - [Create a custom metric from a DDSQL query](https://app.datadoghq.com/workflow/blueprints/create-a-metric-from-a-ddsql-query) - [Programmatically export the results of a DDSQL query](https://app.datadoghq.com/workflow/blueprints/export-ebs-volumes-not-in-ddsql-as-s3-csv) - [Schedule a Slack message for checking compliance of resources](https://app.datadoghq.com/workflow/blueprints/idle-compute-check-via-ddsql-with-slack-updates) -- Alert on a DDSQL query in Preview (Logs, Metrics, RUM, Spans, and Product Analytics only; [contact support][8] for access) +- Alert on a DDSQL query in Preview (Logs, Metrics, RUM, Spans, and {{< prodname >}}Product Analytics{{< /prodname >}} only; [contact support][8] for access) {{< img src="/ddsql_editor/queries-tab-recent-queries.png" alt="Side panel showing the Queries tab with a list of saved and recent queries in the DDSQL Editor" style="width:70%;" >}} diff --git a/hugo/content/en/ddsql_reference/_index.md b/hugo/content/en/ddsql_reference/_index.md index 2f339fa070c..0d0aeac2525 100644 --- a/hugo/content/en/ddsql_reference/_index.md +++ b/hugo/content/en/ddsql_reference/_index.md @@ -29,7 +29,7 @@ further_reading: DDSQL is SQL for Datadog data. It implements several standard SQL operations, such as `SELECT`, and allows queries against unstructured data. You can perform actions like getting exactly the data you want by writing your own `SELECT` statement, or querying tags as if they are standard table columns. -You can run DDSQL queries from AI agents using the [Datadog MCP Server][10] `ddsql` toolset (Preview). +You can run DDSQL queries from AI agents using the [{{< prodname >}}Datadog MCP Server{{< /prodname >}}][10] `ddsql` toolset (Preview). This documentation covers the SQL support available and includes: - [Syntax compatible with PostgreSQL](#syntax) @@ -1050,7 +1050,7 @@ dd.cloud_cost_scalar( to_timestamp timestamp] ) - Returns Cloud Cost Management data as a scalar value. The function accepts a cloud cost query (with optional grouping), an aggregation reducer (use sum for cost data; other reducers such as avg, min, and max are accepted but rarely applicable to cost queries), and optional timestamp parameters (default 1 hour) to define the time range. Note: Cloud cost data is typically delayed by 24-48 hours, so recent timestamps may return no results. + Returns {{< prodname >}}Cloud Cost Management{{< /prodname >}} data as a scalar value. The function accepts a cloud cost query (with optional grouping), an aggregation reducer (use sum for cost data; other reducers such as avg, min, and max are accepted but rarely applicable to cost queries), and optional timestamp parameters (default 1 hour) to define the time range. Note: Cloud cost data is typically delayed by 24-48 hours, so recent timestamps may return no results. {{< code-block lang="sql" >}} SELECT * @@ -1072,7 +1072,7 @@ dd.cloud_cost_timeseries( to_timestamp timestamp] ) - Returns Cloud Cost Management data as a timeseries. The function accepts a cloud cost query (with optional grouping) and optional timestamp parameters (default 1 hour) to define the time range. Returns cost datapoints over time rather than a single aggregated value. Note: Cloud cost data is typically delayed by 24-48 hours, so recent timestamps may return no results. + Returns {{< prodname >}}Cloud Cost Management{{< /prodname >}} data as a timeseries. The function accepts a cloud cost query (with optional grouping) and optional timestamp parameters (default 1 hour) to define the time range. Returns cost datapoints over time rather than a single aggregated value. Note: Cloud cost data is typically delayed by 24-48 hours, so recent timestamps may return no results. {{< code-block lang="sql" >}} SELECT * diff --git a/hugo/content/en/delivery_performance/_index.md b/hugo/content/en/delivery_performance/_index.md index 7d1b9856e11..3682f98e3b6 100644 --- a/hugo/content/en/delivery_performance/_index.md +++ b/hugo/content/en/delivery_performance/_index.md @@ -5,7 +5,7 @@ description: Measure and improve your software delivery performance with DORA Me ## Overview -Delivery Performance provides tools to measure your software delivery performance and the impact of AI coding assistants on your development workflow. +{{< prodname >}}Delivery Performance{{< /prodname >}} provides tools to measure your software delivery performance and the impact of AI coding assistants on your development workflow. ### DORA Metrics diff --git a/hugo/content/en/delivery_performance/dora_metrics/change_failure_detection/_index.md b/hugo/content/en/delivery_performance/dora_metrics/change_failure_detection/_index.md index 7817099d3a8..2bfcae3349b 100644 --- a/hugo/content/en/delivery_performance/dora_metrics/change_failure_detection/_index.md +++ b/hugo/content/en/delivery_performance/dora_metrics/change_failure_detection/_index.md @@ -178,7 +178,7 @@ The `remediation` field is optional, but required to calculate failed deployment To update a deployment's status from the Datadog UI: -1. Navigate to {{< ui >}}Software Delivery{{< /ui >}} > {{< ui >}}DORA Metrics{{< /ui >}} and click [{{< ui >}}View Deployments{{< /ui >}}][5]. +1. Navigate to {{< ui >}}{{< prodname >}}Software Delivery{{< /prodname >}}{{< /ui >}} > {{< ui >}}DORA Metrics{{< /ui >}} and click [{{< ui >}}View Deployments{{< /ui >}}][5]. 2. Click on a deployment to open the deployment details panel. 3. In the deployment details panel, select the {{< ui >}}Deployment status{{< /ui >}} from the dropdown to mark the deployment as failed or stable. diff --git a/hugo/content/en/delivery_performance/dora_metrics/data_collected/_index.md b/hugo/content/en/delivery_performance/dora_metrics/data_collected/_index.md index 400cd610d2f..f71d20fd9cd 100644 --- a/hugo/content/en/delivery_performance/dora_metrics/data_collected/_index.md +++ b/hugo/content/en/delivery_performance/dora_metrics/data_collected/_index.md @@ -51,7 +51,7 @@ For more information about using tags, see [Getting Started with Tags][6]. In addition to the tags above, deployment and failure events can be enriched with custom tags to filter DORA Metrics. There are three potential sources for these tags: - Catalog: If a deployment or failure event is associated with services in Catalog, it is automatically enriched with the `language` tag and the [custom tags defined in the Service Definitions][13]. -- Incident Management: Failure events created from [Datadog Incident Management][14] are enriched with custom tags for any user-defined [Single Select or Multi Select property fields][15]. +- {{< prodname >}}Incident Management{{< /prodname >}}: Failure events created from [Datadog Incident Management][14] are enriched with custom tags for any user-defined [Single Select or Multi Select property fields][15]. - DORA Metrics API: Up to 100 user-provided custom tags can be added to both deployment and failure events in the [API][7]. For more information about using custom tags in DORA Metrics, see [DORA Metrics Overview][16]. diff --git a/hugo/content/en/deployment_gates/_index.md b/hugo/content/en/deployment_gates/_index.md index c3239252971..8663989726b 100644 --- a/hugo/content/en/deployment_gates/_index.md +++ b/hugo/content/en/deployment_gates/_index.md @@ -19,13 +19,13 @@ algolia: --- {{< callout url="http://datadoghq.com/product-preview/deployment-gates" >}} -Deployment Gates are in Preview. If you're interested in this feature, complete the form to request access. +{{< prodname >}}Deployment Gates{{< /prodname >}} are in Preview. If you're interested in this feature, complete the form to request access. {{< /callout >}} -Deployment Gates allow you to reduce the likelihood and impact of incidents caused by deployments. +{{< prodname >}}Deployment Gates{{< /prodname >}} allow you to reduce the likelihood and impact of incidents caused by deployments. -When performing a production rollout, you can use Deployment Gates to evaluate the impact of the new changes by using [monitors][1] and APM anomalies. -When anomalies or performance regressions are detected, you can automatically halt the release, preventing unstable code from reaching a wider user base. Additionally, you can then use Deployment Gates as the entry-point to investigate the problem. +When performing a production rollout, you can use {{< prodname >}}Deployment Gates{{< /prodname >}} to evaluate the impact of the new changes by using [monitors][1] and APM anomalies. +When anomalies or performance regressions are detected, you can automatically halt the release, preventing unstable code from reaching a wider user base. Additionally, you can then use {{< prodname >}}Deployment Gates{{< /prodname >}} as the entry-point to investigate the problem. For setup instructions, see [Set up Deployment Gates][2]. After the setup is completed, you can track and analyze gate evaluations through the [Deployment Gates Evaluations][3] page: diff --git a/hugo/content/en/deployment_gates/explore.md b/hugo/content/en/deployment_gates/explore.md index fef209e817b..73f4c6a71e7 100644 --- a/hugo/content/en/deployment_gates/explore.md +++ b/hugo/content/en/deployment_gates/explore.md @@ -8,10 +8,10 @@ further_reading: --- {{< callout url="http://datadoghq.com/product-preview/deployment-gates" >}} -Deployment Gates are in Preview. If you're interested in this feature, complete the form to request access. +{{< prodname >}}Deployment Gates{{< /prodname >}} are in Preview. If you're interested in this feature, complete the form to request access. {{< /callout >}} -To explore your Deployment Gates and rules evaluations, navigate to [{{< ui >}}Software Delivery{{< /ui >}} > {{< ui >}}Deployment Gates{{< /ui >}} > {{< ui >}}Evaluations{{< /ui >}}][1]. +To explore your {{< prodname >}}Deployment Gates{{< /prodname >}} and rules evaluations, navigate to [{{< ui >}}Software Delivery{{< /ui >}} > {{< ui >}}Deployment Gates{{< /ui >}} > {{< ui >}}Evaluations{{< /ui >}}][1]. On this page you can: * View recently completed gate evaluations and failure reasons diff --git a/hugo/content/en/deployment_gates/setup/_index.md b/hugo/content/en/deployment_gates/setup/_index.md index d5e8972cee9..fb52f9375c8 100644 --- a/hugo/content/en/deployment_gates/setup/_index.md +++ b/hugo/content/en/deployment_gates/setup/_index.md @@ -17,10 +17,10 @@ further_reading: --- {{< callout url="http://datadoghq.com/product-preview/deployment-gates" >}} -Deployment Gates are in Preview. If you're interested in this feature, complete the form to request access. +{{< prodname >}}Deployment Gates{{< /prodname >}} are in Preview. If you're interested in this feature, complete the form to request access. {{< /callout >}} -Deployment Gates have two main components: +{{< prodname >}}Deployment Gates{{< /prodname >}} have two main components: - A **Gate** is defined for a service and environment (and optionally an identifier), and evaluates one or more rules to decide whether a deployment should proceed. - A **Rule** is a type of evaluation performed as part of a gate, such as checking the status of a set of monitors or running APM Faulty Deployment Detection analysis on the deployed version. @@ -28,7 +28,7 @@ Deployment Gates have two main components: Gate evaluations are asynchronous — the API returns immediately with an evaluation ID, and the result resolves to `pass` or `fail` over time as the rules run. ## Deployment Gate evaluation modes -Deployment Gates support two evaluation modes: Just-In-Time (JIT) and preconfigured. +{{< prodname >}}Deployment Gates{{< /prodname >}} support two evaluation modes: Just-In-Time (JIT) and preconfigured. | | **[JIT][1]** (default) | **[Preconfigured][2]** | diff --git a/hugo/content/en/deployment_gates/setup/jit.md b/hugo/content/en/deployment_gates/setup/jit.md index a7cd877d4c4..0f063934d80 100644 --- a/hugo/content/en/deployment_gates/setup/jit.md +++ b/hugo/content/en/deployment_gates/setup/jit.md @@ -14,10 +14,10 @@ further_reading: --- {{< callout url="http://datadoghq.com/product-preview/deployment-gates" >}} -Deployment Gates are in Preview. If you're interested in this feature, complete the form to request access. +{{< prodname >}}Deployment Gates{{< /prodname >}} are in Preview. If you're interested in this feature, complete the form to request access. {{< /callout >}} -With **Just-In-Time (JIT)** Deployment Gates, rules are defined inline in the evaluation request. No gate needs to exist in Datadog ahead of time, which makes JIT a good fit for rules-as-code and per-deployment flexibility. +With **Just-In-Time (JIT)** {{< prodname >}}Deployment Gates{{< /prodname >}}, rules are defined inline in the evaluation request. No gate needs to exist in Datadog ahead of time, which makes JIT a good fit for rules-as-code and per-deployment flexibility. Looking for persistent gates managed in the Datadog UI, API, or Terraform? See [Preconfigured Deployment Gates][5]. @@ -707,7 +707,7 @@ The field `data.attributes.gate_status` contains the result of the evaluation, w ## Recommendation for first-time onboarding -When integrating Deployment Gates into your Continuous Delivery workflow, an evaluation phase helps confirm the product is working as expected before it impacts deployments. Use dry-run mode and the [{{< ui >}}Deployment Gates Evaluations{{< /ui >}}][6] page: +When integrating {{< prodname >}}Deployment Gates{{< /prodname >}} into your Continuous Delivery workflow, an evaluation phase helps confirm the product is working as expected before it impacts deployments. Use dry-run mode and the [{{< ui >}}Deployment Gates Evaluations{{< /ui >}}][6] page: 1. Set `dry_run: true` on the `configuration` (or `dryRun: true` in the CLI config file). To mark only some rules as dry-run, set `dry_run` per rule. A dry-run evaluation always returns `pass` over the API, but the real result is recorded in the UI. 2. Add the gate evaluation to your deployment process. Deployments are not impacted by the gate result while dry-run is enabled. diff --git a/hugo/content/en/deployment_gates/setup/preconfigured.md b/hugo/content/en/deployment_gates/setup/preconfigured.md index af5bd65ff86..18ec8f7a88b 100644 --- a/hugo/content/en/deployment_gates/setup/preconfigured.md +++ b/hugo/content/en/deployment_gates/setup/preconfigured.md @@ -14,10 +14,10 @@ further_reading: --- {{< callout url="http://datadoghq.com/product-preview/deployment-gates" >}} -Deployment Gates are in Preview. If you're interested in this feature, complete the form to request access. +{{< prodname >}}Deployment Gates{{< /prodname >}} are in Preview. If you're interested in this feature, complete the form to request access. {{< /callout >}} -With **preconfigured** Deployment Gates, gates and rules are persisted in Datadog and referenced by service and environment at evaluation time. Preconfigured gates are a good fit when you want to share rules across many deployments, manage configuration in Terraform, or let non-CI users edit rules in the Datadog UI. +With **preconfigured** {{< prodname >}}Deployment Gates{{< /prodname >}}, gates and rules are persisted in Datadog and referenced by service and environment at evaluation time. Preconfigured gates are a good fit when you want to share rules across many deployments, manage configuration in Terraform, or let non-CI users edit rules in the Datadog UI. Looking to define rules inline in your deployment config? See [Just-In-Time (JIT) Deployment Gates][5]. @@ -559,7 +559,7 @@ The field `data.attributes.gate_status` contains the result of the evaluation, w ## Recommendation for first-time onboarding -When integrating Deployment Gates into your Continuous Delivery workflow, an evaluation phase helps confirm the product is working as expected before it impacts deployments. Use the Dry Run evaluation mode and the [{{< ui >}}Deployment Gates Evaluations{{< /ui >}}][7] page: +When integrating {{< prodname >}}Deployment Gates{{< /prodname >}} into your Continuous Delivery workflow, an evaluation phase helps confirm the product is working as expected before it impacts deployments. Use the Dry Run evaluation mode and the [{{< ui >}}Deployment Gates Evaluations{{< /ui >}}][7] page: 1. Create a gate for a service and set the {{< ui >}}Evaluation Mode{{< /ui >}} to {{< ui >}}Dry Run{{< /ui >}}. 2. Add the gate evaluation to your deployment process. While the gate is in dry-run mode, the API always returns `pass` and deployments are not impacted by the gate result. diff --git a/hugo/content/en/error_tracking/_index.md b/hugo/content/en/error_tracking/_index.md index 2de69d0aa70..c4579b7a9f8 100644 --- a/hugo/content/en/error_tracking/_index.md +++ b/hugo/content/en/error_tracking/_index.md @@ -32,8 +32,8 @@ Developers can triage and fix issues completely within IntelliJ IDEA, PyCharm, W ## Getting started -- Take a tour of key Error Tracking features in the [Error Tracking Explorer][5] documentation. -- Use the product-specific links in the next section to set up Error Tracking for a particular error source. +- Take a tour of key {{< prodname >}}Error Tracking{{< /prodname >}} features in the [Error Tracking Explorer][5] documentation. +- Use the product-specific links in the next section to set up {{< prodname >}}Error Tracking{{< /prodname >}} for a particular error source. ## Setup {{< whatsnext desc="To get started with Datadog Error Tracking, choose one of the following setup options:" >}} @@ -50,14 +50,14 @@ Developers can triage and fix issues completely within IntelliJ IDEA, PyCharm, W ## Supported error sources -Error Tracking captures and processes errors across your web, mobile, and backend applications. You can instrument your applications and services using the [Browser SDK][6], [Mobile SDK][7], or ingest errors from your Logs, Traces, and Real User Monitoring events. +{{< prodname >}}Error Tracking{{< /prodname >}} captures and processes errors across your web, mobile, and backend applications. You can instrument your applications and services using the [Browser SDK][6], [Mobile SDK][7], or ingest errors from your Logs, Traces, and Real User Monitoring events. Additional features are available depending on the source of the error. For example, in errors originating from an APM trace, the [Exception Replay][4] feature automatically captures production variable values. -For details, see the product-specific Error Tracking documentation: +For details, see the product-specific {{< prodname >}}Error Tracking{{< /prodname >}} documentation: - [APM][1] -- [Log Management][2] +- [{{< prodname >}}Log Management{{< /prodname >}}][2] - [Real User Monitoring][3] ## Further reading diff --git a/hugo/content/en/error_tracking/apm.md b/hugo/content/en/error_tracking/apm.md index d428c9a0761..baa4b4a6cb1 100644 --- a/hugo/content/en/error_tracking/apm.md +++ b/hugo/content/en/error_tracking/apm.md @@ -2,7 +2,7 @@ title: Error Tracking for APM --- -Error Tracking is available for all languages supported by APM. It requires no additional SDK and no configuration changes. +{{< prodname >}}Error Tracking{{< /prodname >}} is available for all languages supported by APM. It requires no additional SDK and no configuration changes. {{< whatsnext desc="Get started with Error Tracking for APM:" >}} {{< nextlink href="tracing/error_tracking" >}}View the documentation{{< /nextlink >}} diff --git a/hugo/content/en/error_tracking/auto_assign.md b/hugo/content/en/error_tracking/auto_assign.md index 6915b2f139b..394bce6f6f2 100644 --- a/hugo/content/en/error_tracking/auto_assign.md +++ b/hugo/content/en/error_tracking/auto_assign.md @@ -22,7 +22,7 @@ Once configured and enabled, issues are automatically assigned to developers bas ### Configure Source Code Integration -1. Ensure [Source Code Integration][2] is enabled and set up. +1. Ensure [{{< prodname >}}Source Code Integration{{< /prodname >}}][2] is enabled and set up. 2. Install [the GitHub integration][3]. 3. Make sure all requested permissions (Contents, Members) are granted for the GitHub integration. diff --git a/hugo/content/en/error_tracking/backend/_index.md b/hugo/content/en/error_tracking/backend/_index.md index d17c3f0890f..97bfd083de4 100644 --- a/hugo/content/en/error_tracking/backend/_index.md +++ b/hugo/content/en/error_tracking/backend/_index.md @@ -22,7 +22,7 @@ further_reading: It is critical for your system's health to consistently monitor the errors that Datadog collects. When there are many individual error events, it becomes hard to prioritize errors for troubleshooting. -Error Tracking simplifies debugging by grouping thousands of similar errors into a single issue. Error Tracking enables you to: +{{< prodname >}}Error Tracking{{< /prodname >}} simplifies debugging by grouping thousands of similar errors into a single issue. {{< prodname >}}Error Tracking{{< /prodname >}} enables you to: - Track, triage, and debug fatal errors - Group similar errors into issues, so that you can identify important errors and reduce noise diff --git a/hugo/content/en/error_tracking/backend/capturing_handled_errors/_index.md b/hugo/content/en/error_tracking/backend/capturing_handled_errors/_index.md index 462cb00e982..83da2b408b1 100644 --- a/hugo/content/en/error_tracking/backend/capturing_handled_errors/_index.md +++ b/hugo/content/en/error_tracking/backend/capturing_handled_errors/_index.md @@ -18,7 +18,7 @@ further_reading: ## Overview -Datadog SDKs can automatically report handled errors. The errors are attached through span events to the span in which they are handled. They are also directly reported to Error Tracking. +Datadog SDKs can automatically report handled errors. The errors are attached through span events to the span in which they are handled. They are also directly reported to {{< prodname >}}Error Tracking{{< /prodname >}}. ## Requirements Supported languages @@ -33,7 +33,7 @@ Supported languages Handled errors contain the span attribute error.handling:handled. For more details, see Facets.
-Capturing handled errors is only available in APM Error Tracking or Standalone Backend Error Tracking. Error Tracking for Logs and RUM is not supported. +Capturing handled errors is only available in APM Error Tracking or Standalone Backend Error Tracking. {{< prodname >}}Error Tracking{{< /prodname >}} for Logs and RUM is not supported. ## Setup diff --git a/hugo/content/en/error_tracking/backend/capturing_handled_errors/python.md b/hugo/content/en/error_tracking/backend/capturing_handled_errors/python.md index 9ea42eda1ac..70430ae37ed 100644 --- a/hugo/content/en/error_tracking/backend/capturing_handled_errors/python.md +++ b/hugo/content/en/error_tracking/backend/capturing_handled_errors/python.md @@ -22,7 +22,7 @@ This environment variable enables reporting of handled errors respectively from List the modules from which handled errors should be reported. You need to specify the full name of the module. For instance, to instrument the module `security` in your `mysite` app, you need to specify `mysite.security` -Handled errors will be reported in Error Tracking and attached to spans through [span events][3]. +Handled errors will be reported in {{< prodname >}}Error Tracking{{< /prodname >}} and attached to spans through [span events][3]. If you are running `Python3.10` or `Python3.11` and you want to instrument the ``__main__`` module, you need to add: @@ -50,7 +50,7 @@ except ValueError as e: span.record_exception(e) ``` -This call will create a span event on the span with the error information and will report the error to Error Tracking. +This call will create a span event on the span with the error information and will report the error to {{< prodname >}}Error Tracking{{< /prodname >}}. You can also provide additional attributes using: ```Python diff --git a/hugo/content/en/error_tracking/backend/exception_replay.md b/hugo/content/en/error_tracking/backend/exception_replay.md index d85134ee37c..1fb91359984 100644 --- a/hugo/content/en/error_tracking/backend/exception_replay.md +++ b/hugo/content/en/error_tracking/backend/exception_replay.md @@ -29,7 +29,7 @@ Exception Replay is generally available for Python, Java, .NET, PHP, and is enab Exception Replay captures execution context and local variable values when an exception occurs, helping you diagnose, reproduce, and resolve issues faster. It records the surrounding state, including the stack trace and variable -snapshots, then surfaces this data directly in Error Tracking alongside the rest of the issue details. +snapshots, then surfaces this data directly in {{< prodname >}}Error Tracking{{< /prodname >}} alongside the rest of the issue details. {{< img src="tracing/error_tracking/error_tracking_executional_context-3.png" alt="Error Tracking Explorer Exception Replay" style="width:90%" >}} @@ -58,7 +58,7 @@ below for details. | **Minimum Tracer Versions** | [Python][8] ≥ 3.15.0
[Java][9] ≥ 1.54.0
[.NET][10] ≥ 3.29.0 | [Python][8] ≥ 3.10.0
[Java][9] ≥ 1.48.0
[.NET][10] ≥ 3.29.0 | [Python][8] ≥ 1.16.0
[Java][9] ≥ 1.47.0
[.NET][10] ≥ 2.53.0
[PHP][11] ≥ 1.12.1 | | **Remote Configuration Required?** | Yes | Yes | No | -To enable Exception Replay in-app, navigate to the Exception Replay {{< ui >}}Settings{{< /ui >}} page in Error Tracking, select the +To enable Exception Replay in-app, navigate to the Exception Replay {{< ui >}}Settings{{< /ui >}} page in {{< prodname >}}Error Tracking{{< /prodname >}}, select the desired environment or service, and toggle it to {{< ui >}}Enabled{{< /ui >}}. {{< img src="tracing/error_tracking/error_tracking_exception_replay_enablement.mp4" video="true" alt="Enabling Exception Replay through the setting page" style="width:90%" >}} @@ -85,7 +85,7 @@ Exception Replay snapshots are emitted as logs enriched with links back to the o ### Link your source code -If you enable the Datadog Source Code Integration, you can see code previews directly inside your Error Tracking stack +If you enable the Datadog Source Code Integration, you can see code previews directly inside your {{< prodname >}}Error Tracking{{< /prodname >}} stack traces. When Exception Replay snapshots are captured, you can hover over variable names in the code preview to view their captured values. @@ -123,7 +123,7 @@ for configuration details.
Why DI instructions? -Exception Replay is built on Dynamic Instrumentation (DI), so its +Exception Replay is built on {{< prodname >}}Dynamic Instrumentation{{< /prodname >}} (DI), so its sensitive data scrubbing configuration options also apply here.
@@ -148,7 +148,7 @@ snapshots. ### BatchUploader WARN messages on GovCloud (Java) -On GovCloud sites (`app.ddog-gov.com`), Java tracers may log periodic WARN messages from `com.datadog.debugger.uploader.BatchUploader` with HTTP 403 and text similar to `This traffic is not permitted on your account`. This is expected when debugger-related uploads are attempted on a site where Exception Replay, Dynamic Instrumentation, and Code Origin for Spans are not supported. Core APM functionality (traces, metrics, profiling, log injection) is not affected. +On GovCloud sites (`app.ddog-gov.com`), Java tracers may log periodic WARN messages from `com.datadog.debugger.uploader.BatchUploader` with HTTP 403 and text similar to `This traffic is not permitted on your account`. This is expected when debugger-related uploads are attempted on a site where Exception Replay, {{< prodname >}}Dynamic Instrumentation{{< /prodname >}}, and Code Origin for Spans are not supported. Core APM functionality (traces, metrics, profiling, log injection) is not affected. To stop these log messages, set the following environment variables on the Java application pod and restart the workload: diff --git a/hugo/content/en/error_tracking/backend/getting_started/_index.md b/hugo/content/en/error_tracking/backend/getting_started/_index.md index 6e15a3a0064..db256b75c66 100644 --- a/hugo/content/en/error_tracking/backend/getting_started/_index.md +++ b/hugo/content/en/error_tracking/backend/getting_started/_index.md @@ -16,7 +16,7 @@ further_reading: ## Overview -[Error Tracking][1] processes errors collected by the Datadog SDKs. Whenever an error is collected, Error Tracking processes and groups it under an issue, or group of similar errors. +[{{< prodname >}}Error Tracking{{< /prodname >}}][1] processes errors collected by the Datadog SDKs. Whenever an error is collected, {{< prodname >}}Error Tracking{{< /prodname >}} processes and groups it under an issue, or group of similar errors. ## Getting started with Backend Error Tracking diff --git a/hugo/content/en/error_tracking/backend/logs.md b/hugo/content/en/error_tracking/backend/logs.md index a9294205cd4..c21a61bbe75 100644 --- a/hugo/content/en/error_tracking/backend/logs.md +++ b/hugo/content/en/error_tracking/backend/logs.md @@ -25,11 +25,11 @@ For backend languages such as **C#**, **.NET**, **Go**, and **Node.js**, the cod If you are already sending stack traces to Datadog but they are not in `error.stack`, you can set up a [generic log remapper][8] to remap the stack trace to the correct attribute in Datadog. -To configure inline code snippets in issues, set up the [source code integration][9]. Adding code snippets in Error Tracking for Logs does not require APM; the enrichment tags and linked repository is the same for both. +To configure inline code snippets in issues, set up the [source code integration][9]. Adding code snippets in {{< prodname >}}Error Tracking{{< /prodname >}} for Logs does not require APM; the enrichment tags and linked repository is the same for both. #### Attributes for Error Tracking -To enable Error Tracking, logs must include the following attributes: +To enable {{< prodname >}}Error Tracking{{< /prodname >}}, logs must include the following attributes: - Either an `error.kind` or `error.stack` field. **Note**: if using `error.stack`, it must be a valid stack trace. - A `Service` attribute @@ -37,7 +37,7 @@ To enable Error Tracking, logs must include the following attributes: The remaining attributes listed below are optional, but their presence improves error grouping. -Specific attributes have a dedicated UI display within Datadog. To enable these functionalities for Error Tracking, use the following attribute names: +Specific attributes have a dedicated UI display within Datadog. To enable these functionalities for {{< prodname >}}Error Tracking{{< /prodname >}}, use the following attribute names: | Attribute | Description | |----------------------|-------------------------------------------------------------------------| diff --git a/hugo/content/en/error_tracking/dynamic_sampling.md b/hugo/content/en/error_tracking/dynamic_sampling.md index 83a1050c6ee..eb96fdc6800 100644 --- a/hugo/content/en/error_tracking/dynamic_sampling.md +++ b/hugo/content/en/error_tracking/dynamic_sampling.md @@ -14,11 +14,11 @@ further_reading: ## Overview -Because Error Tracking billing is based on the number of errors, large increases in the errors for a single issue can quickly consume your Error Tracking budget. Dynamic Sampling protects you by establishing a threshold for the error rate per issue based on your daily rate limit and historical error volumes, sampling errors when that threshold is reached. Dynamic Sampling automatically deactivates when the error rate of your issue decreases below the given threshold. +Because Error Tracking billing is based on the number of errors, large increases in the errors for a single issue can quickly consume your {{< prodname >}}Error Tracking{{< /prodname >}} budget. Dynamic Sampling protects you by establishing a threshold for the error rate per issue based on your daily rate limit and historical error volumes, sampling errors when that threshold is reached. Dynamic Sampling automatically deactivates when the error rate of your issue decreases below the given threshold. ## Setup -Dynamic Sampling is automatically enabled with Error Tracking with a default intake threshold based on your daily rate limit and historical volume. +Dynamic Sampling is automatically enabled with {{< prodname >}}Error Tracking{{< /prodname >}} with a default intake threshold based on your daily rate limit and historical volume. For best results, set up a daily rate limit on the [Error Tracking Rate Limits page][2]: Click **Edit Rate Limit** and enter a new value. @@ -40,9 +40,9 @@ A `Dynamic Sampling activated` event is generated when Dynamic Sampling is appli When Dynamic Sampling is applied, the following steps are recommended: -- Check which issue is consuming your quota. The issue to which Dynamic Sampling is applied is linked in the event generated in Event Management. +- Check which issue is consuming your quota. The issue to which Dynamic Sampling is applied is linked in the event generated in {{< prodname >}}Event Management{{< /prodname >}}. - If you'd like to collect additional samples for this issue, raise your daily quota on the [Error Tracking Rate Limits page][2]. -- If you'd like to avoid collecting samples for this issue in the future, consider creating an [exclusion filter][3] to prevent additional events from being ingested into Error Tracking. +- If you'd like to avoid collecting samples for this issue in the future, consider creating an [exclusion filter][3] to prevent additional events from being ingested into {{< prodname >}}Error Tracking{{< /prodname >}}. ## Further Reading diff --git a/hugo/content/en/error_tracking/explorer.md b/hugo/content/en/error_tracking/explorer.md index 3bf2fa13cf2..5ee9afb7459 100644 --- a/hugo/content/en/error_tracking/explorer.md +++ b/hugo/content/en/error_tracking/explorer.md @@ -39,7 +39,7 @@ The time range appears on the top right of the Explorer as a timeline. This feat ### Sorting Order issues in the list using one of these options: -- {{< ui >}}Relevance{{< /ui >}} combines multiple issue features to prioritize code related, recent, or spiking issues. Error Tracking analyzes how old issues are, occurrences over the last day, notable increase over the past hour, or if they triggered an application crash. +- {{< ui >}}Relevance{{< /ui >}} combines multiple issue features to prioritize code related, recent, or spiking issues. {{< prodname >}}Error Tracking{{< /prodname >}} analyzes how old issues are, occurrences over the last day, notable increase over the past hour, or if they triggered an application crash. - {{< ui >}}Count{{< /ui >}} sorts issues based on the total count of occurrences over the selected time range. - {{< ui >}}Newest{{< /ui >}} orders issues by when they were first seen. - {{< ui >}}Impacted Sessions{{< /ui >}} sorts issues by the number of impacted [RUM sessions][4]. @@ -48,7 +48,7 @@ Order issues in the list using one of these options: {{< img src="/error_tracking/facets-panel-2.png" alt="Error Tracking Facets" style="width:100%;" >}} -Error Tracking automatically indexes a predefined list of attributes from your issues and creates facets out of it. A facet displays all the distinct members of an attribute for the selected time period and provides some basic analytics, such as the number of issues represented. Facets allow you to pivot or filter your issues based on the given attribute. +{{< prodname >}}Error Tracking{{< /prodname >}} automatically indexes a predefined list of attributes from your issues and creates facets out of it. A facet displays all the distinct members of an attribute for the selected time period and provides some basic analytics, such as the number of issues represented. Facets allow you to pivot or filter your issues based on the given attribute. Some commonly used error attributes include: | Attribute | Description | @@ -64,13 +64,13 @@ Click the Edit icon to see the list of available facets that you can show or hid ### Issue level filters -In addition to error events, Error Tracking offers issue level filters to refine the list of displayed issues. +In addition to error events, {{< prodname >}}Error Tracking{{< /prodname >}} offers issue level filters to refine the list of displayed issues. {{< img src="error_tracking/issue-level-filters-2.png" alt="Issue level filters in Error Tracking" style="width:100%;" >}} #### Sources -Error Tracking consolidates errors from multiple Datadog products (Rum, Logs, APM) into a unified view, allowing you to watch and troubleshoot errors across your entire stack. You can choose to display {{< ui >}}All{{< /ui >}}, {{< ui >}}Browser{{< /ui >}}, {{< ui >}}Mobile{{< /ui >}}, or {{< ui >}}Backend{{< /ui >}} issues in the explorer. +{{< prodname >}}Error Tracking{{< /prodname >}} consolidates errors from multiple Datadog products (Rum, Logs, APM) into a unified view, allowing you to watch and troubleshoot errors across your entire stack. You can choose to display {{< ui >}}All{{< /ui >}}, {{< ui >}}Browser{{< /ui >}}, {{< ui >}}Mobile{{< /ui >}}, or {{< ui >}}Backend{{< /ui >}} issues in the explorer. For more granular filtering, you can narrow down issues by specific log sources or by SDK and scope to a programming language. @@ -106,7 +106,7 @@ The lower part of the issue panel gives you the ability to navigate error sample ## Get alerted on new or impactful errors -Seeing a new issue as soon as it happens gives you the chance to proactively identify and fix it before it becomes critical. Error Tracking monitors allow you to track any new issue or issues that have a high impact in your systems or on your users (see [Error Tracking Monitors][7]) +Seeing a new issue as soon as it happens gives you the chance to proactively identify and fix it before it becomes critical. {{< prodname >}}Error Tracking{{< /prodname >}} monitors allow you to track any new issue or issues that have a high impact in your systems or on your users (see [Error Tracking Monitors][7]) You can directly export your search query from the explorer to create an Error Tracking Monitor on the related scope: diff --git a/hugo/content/en/error_tracking/frontend/_index.md b/hugo/content/en/error_tracking/frontend/_index.md index 94d257ebf1a..9960a75ad1a 100644 --- a/hugo/content/en/error_tracking/frontend/_index.md +++ b/hugo/content/en/error_tracking/frontend/_index.md @@ -22,7 +22,7 @@ further_reading: It is critical for your system’s health to consistently monitor the errors collected by Datadog. When there are many individual error events, it becomes hard to prioritize errors for troubleshooting. -Error Tracking simplifies debugging by grouping thousands of similar errors into a single issue. Error Tracking enables you to: +{{< prodname >}}Error Tracking{{< /prodname >}} simplifies debugging by grouping thousands of similar errors into a single issue. {{< prodname >}}Error Tracking{{< /prodname >}} enables you to: - Track, triage, and debug fatal errors - Group similar errors into issues to identify important errors and reduce noise diff --git a/hugo/content/en/error_tracking/frontend/browser.md b/hugo/content/en/error_tracking/frontend/browser.md index f6cb756cffe..73c4bbcc143 100644 --- a/hugo/content/en/error_tracking/frontend/browser.md +++ b/hugo/content/en/error_tracking/frontend/browser.md @@ -20,7 +20,7 @@ further_reading: ## Overview -[Error Tracking][1] processes errors collected from the browser by the Browser SDK. Whenever a [source][2], [custom][3], [report][4], or [console][4] error containing a stack trace is collected, Error Tracking processes and groups it under an issue, or group of similar errors to be found in the [Error Tracking Explorer][16]. +[{{< prodname >}}Error Tracking{{< /prodname >}}][1] processes errors collected from the browser by the Browser SDK. Whenever a [source][2], [custom][3], [report][4], or [console][4] error containing a stack trace is collected, {{< prodname >}}Error Tracking{{< /prodname >}} processes and groups it under an issue, or group of similar errors to be found in the [Error Tracking Explorer][16]. ## Prerequisites @@ -28,7 +28,7 @@ Download the latest version of the [Browser SDK][5]. ## Setup -To start sending Error Tracking data from your browser application to Datadog, follow the [in-app setup instructions][6] or follow the steps below. +To start sending {{< prodname >}}Error Tracking{{< /prodname >}} data from your browser application to Datadog, follow the [in-app setup instructions][6] or follow the steps below. ### Step 1 - Create the application @@ -169,7 +169,7 @@ Upload your JavaScript source maps to access unminified stack traces. See the [s Now that you've completed the basic setup for Browser Error Tracking, your application is collecting browser errors and you can start monitoring and debugging issues in real-time. -Visualize the [data collected][7] in [dashboards][8] or create a search query in Error Tracking. +Visualize the [data collected][7] in [dashboards][8] or create a search query in {{< prodname >}}Error Tracking{{< /prodname >}}. Until Datadog starts receiving data, your application appears as `pending` on the {{< ui >}}Applications{{< /ui >}} page. @@ -177,7 +177,7 @@ Until Datadog starts receiving data, your application appears as `pending` on th In addition to sending source maps, the [Datadog CLI][11] reports Git information such as the commit hash, repository URL, and a list of tracked file paths in the code repository. -Error Tracking can use this information to correlate errors with your [source code][15], allowing you to pivot from any stack trace frame to the related line of code in [GitHub][12], [GitLab][13] and [Bitbucket][14]. +{{< prodname >}}Error Tracking{{< /prodname >}} can use this information to correlate errors with your [source code][15], allowing you to pivot from any stack trace frame to the related line of code in [GitHub][12], [GitLab][13] and [Bitbucket][14].
Linking from stack frames to source code is supported in the Datadog CLI version 0.12.0 and later.
@@ -185,7 +185,7 @@ For more information, see the [Datadog Source Code Integration][15]. ## Tagging for Error Tracking -These tags (configured in step 3 above) power Error Tracking functionality: +These tags (configured in step 3 above) power {{< prodname >}}Error Tracking{{< /prodname >}} functionality: - Filtering and faceting issues by `service` and `env` - Cross-product correlation with RUM, Logs, and APM for the same `service`/`env` diff --git a/hugo/content/en/error_tracking/frontend/logs.md b/hugo/content/en/error_tracking/frontend/logs.md index 536d9991477..ed7a4233cd8 100644 --- a/hugo/content/en/error_tracking/frontend/logs.md +++ b/hugo/content/en/error_tracking/frontend/logs.md @@ -15,7 +15,7 @@ further_reading: ## Overview -Error Tracking processes errors collected from browser and mobile Datadog Log SDKs. Whenever an error containing a stack trace is collected, Error Tracking processes and groups it under an _issue_, which is a grouping of similar errors. +{{< prodname >}}Error Tracking{{< /prodname >}} processes errors collected from browser and mobile Datadog Log SDKs. Whenever an error containing a stack trace is collected, {{< prodname >}}Error Tracking{{< /prodname >}} processes and groups it under an _issue_, which is a grouping of similar errors. An essential attribute for log errors is the stack trace in a log's `error.stack`. If you are sending stack traces to Datadog but they are not in `error.stack`, you can set up a [generic log remapper][6] to remap the stack trace to the correct attribute in Datadog. @@ -28,7 +28,7 @@ Your crash reports appear in [{{< ui >}}Error Tracking{{< /ui >}}][2]. If you have not set up the Datadog Browser Logs SDK yet, follow the [in-app setup instructions][1] or see the [Browser Logs setup documentation][2]. -1. Download the latest version of the Logs Browser SDK. Error Tracking requires at least `v4.36.0`. +1. Download the latest version of the Logs Browser SDK. {{< prodname >}}Error Tracking{{< /prodname >}} requires at least `v4.36.0`. 2. Configure your application's `version`, `env`, and `service` when [initializing the SDK][3]. For example, with NPM: ```javascript @@ -54,7 +54,7 @@ If you have not set up the Datadog Browser Logs SDK yet, follow the [in-app setu } ``` -**Note**: Error Tracking only considers errors that are instances of `Error`. +**Note**: {{< prodname >}}Error Tracking{{< /prodname >}} only considers errors that are instances of `Error`. [1]: https://app.datadoghq.com/logs/onboarding/client [2]: /logs/log_collection/javascript/#setup diff --git a/hugo/content/en/error_tracking/frontend/mobile/android.md b/hugo/content/en/error_tracking/frontend/mobile/android.md index 3c7144fb394..9c699bd5893 100644 --- a/hugo/content/en/error_tracking/frontend/mobile/android.md +++ b/hugo/content/en/error_tracking/frontend/mobile/android.md @@ -22,7 +22,7 @@ further_reading: ## Overview -Android [Error Tracking][1] gives you comprehensive visibility into your mobile app's health by automatically capturing crashes, exceptions, and errors. With this feature, you can: +Android [{{< prodname >}}Error Tracking{{< /prodname >}}][1] gives you comprehensive visibility into your mobile app's health by automatically capturing crashes, exceptions, and errors. With this feature, you can: - Monitor app stability in real-time with instant crash alerts and error rate tracking across versions, devices, and user segments. - Debug issues faster with deobfuscated stack traces and automatic ProGuard mapping file uploads for easier problem identification. @@ -468,7 +468,7 @@ For more information, see [Web View Tracking][8]. If your Android app uses native code (C/C++) through the Android NDK (Native Development Kit), you can track crashes that occur in this native code. Native code is often used for performance-critical operations, image processing, or when reusing existing C/C++ libraries. -Without NDK crash reporting, crashes in your native code do not appear in Error Tracking, making it difficult to debug issues in this part of your application. +Without NDK crash reporting, crashes in your native code do not appear in {{< prodname >}}Error Tracking{{< /prodname >}}, making it difficult to debug issues in this part of your application. To enable NDK crash reporting, use the Datadog NDK plugin: @@ -519,14 +519,14 @@ Rum.enable(rumConfig); ANRs are only reported through the SDK (not through Logs). -**Note**: If you see `com.datadog.android.rum.internal.anr.ANRException` in your crash reports, the Datadog SDK did not cause the ANR. `ANRException` is the SDK's mechanism for detecting and surfacing ANRs in Error Tracking. The root cause is always application code blocking the main thread. +**Note**: If you see `com.datadog.android.rum.internal.anr.ANRException` in your crash reports, the Datadog SDK did not cause the ANR. `ANRException` is the SDK's mechanism for detecting and surfacing ANRs in {{< prodname >}}Error Tracking{{< /prodname >}}. The root cause is always application code blocking the main thread. #### Reporting fatal ANRs Fatal ANRs result in crashes. The application reports them when it's unresponsive, leading to the Android OS displaying a popup dialog to the user, who chooses to force quit the app through the popup. {{< img src="real_user_monitoring/error_tracking/rum-anr-fatal.png" alt="A fatal crash report in Error Tracking." >}} -- In the {{< ui >}}Error Tracking{{< /ui >}} page, fatal ANRs are grouped based on their similarity, which can result in several **individual issues** being created. +- In the {{< ui >}}{{< prodname >}}Error Tracking{{< /prodname >}}{{< /ui >}} page, fatal ANRs are grouped based on their similarity, which can result in several **individual issues** being created. - By default, Datadog catches fatal ANRs through the [ApplicationExitInfo API][19] (available since *[Android 30+][20]*), which can be read on the next app launch. - In *[Android 29][21] and below*, reporting on fatal ANRs is not possible. @@ -535,7 +535,7 @@ Non-fatal ANRs may or may not have led to the application being terminated (cras {{< img src="real_user_monitoring/error_tracking/rum-anr-non-fatal.png" alt="A non-fatal crash report in Error Tracking." >}} -- In the {{< ui >}}Error Tracking{{< /ui >}} page, non-fatal ANRs are grouped under a **single** issue due to their level of noise. +- In the {{< ui >}}{{< prodname >}}Error Tracking{{< /prodname >}}{{< /ui >}} page, non-fatal ANRs are grouped under a **single** issue due to their level of noise. - By default, the reporting of non-fatal ANRs on *Android 30+* is **disabled** because it would create too much noise over fatal ANRs. On *Android 29* and below, however, the reporting of non-fatal ANRs is **enabled** by default, as fatal ANRs cannot be reported on those versions. For any Android version, you can override the default setting for reporting non-fatal ANRs by setting `trackNonFatalAnrs` to `true` or `false` when initializing the SDK. @@ -877,7 +877,7 @@ When looking at RUM Crash Reporting behaviors for Android, consider the followin ## Test your implementation -To verify your Android Crash Reporting and Error Tracking configuration, you need to trigger a crash in your application and confirm that the error appears in Datadog. +To verify your Android Crash Reporting and {{< prodname >}}Error Tracking{{< /prodname >}} configuration, you need to trigger a crash in your application and confirm that the error appears in Datadog. To test your implementation: diff --git a/hugo/content/en/error_tracking/frontend/mobile/expo.md b/hugo/content/en/error_tracking/frontend/mobile/expo.md index cb39b138b2a..130e3af908c 100644 --- a/hugo/content/en/error_tracking/frontend/mobile/expo.md +++ b/hugo/content/en/error_tracking/frontend/mobile/expo.md @@ -21,7 +21,7 @@ further_reading: ## Overview -Enable Expo Crash Reporting and Error Tracking to get comprehensive crash reports and error trends for your Expo mobile applications. +Enable Expo Crash Reporting and {{< prodname >}}Error Tracking{{< /prodname >}} to get comprehensive crash reports and error trends for your Expo mobile applications. With this feature, you can access: @@ -33,7 +33,7 @@ In order to symbolicate your stack traces and deobfuscate Android crashes, uploa Debug symbols are used to deobfuscate stack traces, which helps in debugging errors. Using a unique build ID that gets generated, Datadog automatically matches the correct stack traces with the corresponding debug symbols. This ensures that regardless of when the debug symbols were uploaded (either during pre-production or production builds), the correct information is available for efficient QA processes when reviewing crashes and errors reported in Datadog. -**Note:** Error Tracking can be used as a standalone product or alongside [Real User Monitoring (RUM)][12]. If you're using RUM, Error Tracking is already included. See the [RUM Expo setup documentation][3] for RUM-specific configuration. +**Note:** {{< prodname >}}Error Tracking{{< /prodname >}} can be used as a standalone product or alongside [Real User Monitoring (RUM)][12]. If you're using RUM, {{< prodname >}}Error Tracking{{< /prodname >}} is already included. See the [RUM Expo setup documentation][3] for RUM-specific configuration. Your crash reports appear in [{{< ui >}}Error Tracking{{< /ui >}}][1]. @@ -61,7 +61,7 @@ yarn add -D @datadog/datadog-ci ### Step 2 - Track view navigation -To see Error Tracking sessions populate in Datadog, you need to implement view tracking, which can be initialized manually or automatically. +To see {{< prodname >}}Error Tracking{{< /prodname >}} sessions populate in Datadog, you need to implement view tracking, which can be initialized manually or automatically. #### Manual tracking @@ -102,7 +102,7 @@ Example with React Navigation: ### Step 3 - Initialize the SDK -Add the following code to your initialization file to set up Error Tracking: +Add the following code to your initialization file to set up {{< prodname >}}Error Tracking{{< /prodname >}}: ```js import { CoreConfiguration } from 'expo-datadog'; @@ -129,7 +129,7 @@ const config = new CoreConfiguration( await DdSdkReactNative.initialize(config); ``` -**Note:** If you're using Error Tracking as a standalone product without RUM, you can set the user interaction and XHR resource tracking parameters to `false`. However, view tracking (Step 2) is still required for Error Tracking sessions to be created. +**Note:** If you're using {{< prodname >}}Error Tracking{{< /prodname >}} as a standalone product without RUM, you can set the user interaction and XHR resource tracking parameters to `false`. However, view tracking (Step 2) is still required for {{< prodname >}}Error Tracking{{< /prodname >}} sessions to be created. ### Step 4 - Configure the Expo plugin @@ -256,7 +256,7 @@ const crashApp = () => { }; ``` -Re-build your application for release to send the new source maps, trigger the crash and wait on the [Error Tracking][1] page for the error to appear. +Re-build your application for release to send the new source maps, trigger the crash and wait on the [{{< prodname >}}Error Tracking{{< /prodname >}}][1] page for the error to appear. To test your dSYMs and Proguard mapping files upload, crash the native main thread instead: diff --git a/hugo/content/en/error_tracking/frontend/mobile/ios.md b/hugo/content/en/error_tracking/frontend/mobile/ios.md index d805bd84534..9e7b624eacc 100644 --- a/hugo/content/en/error_tracking/frontend/mobile/ios.md +++ b/hugo/content/en/error_tracking/frontend/mobile/ios.md @@ -12,7 +12,7 @@ further_reading: ## Overview -Enable iOS Crash Reporting and Error Tracking to get comprehensive crash reports and error trends. With this feature, you can access: +Enable iOS Crash Reporting and {{< prodname >}}Error Tracking{{< /prodname >}} to get comprehensive crash reports and error trends. With this feature, you can access: - Aggregated iOS crash dashboards and attributes - Symbolicated iOS crash reports @@ -28,7 +28,7 @@ See [Supported versions][15] for a list of operating system versions and platfor ## Setup -To start sending Error Tracking data from your iOS or tvOS application to Datadog: +To start sending {{< prodname >}}Error Tracking{{< /prodname >}} data from your iOS or tvOS application to Datadog: ### Step 1 - Declare the iOS SDK as a dependency @@ -88,7 +88,7 @@ DatadogRUM.xcframework ### Step 2 - Specify application details in the UI -1. Navigate to {{< ui >}}Error Tracking{{< /ui >}} > [{{< ui >}}Settings{{< /ui >}}][2] > {{< ui >}}Browser and Mobile{{< /ui >}}. +1. Navigate to {{< ui >}}{{< prodname >}}Error Tracking{{< /prodname >}}{{< /ui >}} > [{{< ui >}}Settings{{< /ui >}}][2] > {{< ui >}}Browser and Mobile{{< /ui >}}. 2. Click {{< ui >}}New Application{{< /ui >}}. 3. Enter an application name and select {{< ui >}}iOS{{< /ui >}} as the application type. 4. Click {{< ui >}}Create Application{{< /ui >}} to generate a unique Datadog application ID and client token. @@ -420,7 +420,7 @@ For more information, see [Web View Tracking][3]. ### Step 4 - Add crash reporting -Crash reporting captures fatal crashes when your app terminates unexpectedly, in addition to the errors that Error Tracking displays in a unified interface. +Crash reporting captures fatal crashes when your app terminates unexpectedly, in addition to the errors that {{< prodname >}}Error Tracking{{< /prodname >}} displays in a unified interface. To enable crash reporting, add the package according to your dependency manager and update your initialization snippet. @@ -482,11 +482,11 @@ App hangs are an iOS-specific type of error that happens when the application is There are two types of hangs: -- **Fatal app hang**: How a hang gets reported if it never gets recovered and the app is terminated. Fatal app hangs are marked as a "Crash" in Error Tracking and the RUM explorer. +- **Fatal app hang**: How a hang gets reported if it never gets recovered and the app is terminated. Fatal app hangs are marked as a "Crash" in {{< prodname >}}Error Tracking{{< /prodname >}} and the RUM explorer. {{< img src="real_user_monitoring/error_tracking/ios-fatal-app-hang-1.png" alt="A fatal app hang in the Error side panel." style="width:100%;" >}} -- **Non-fatal app hang**: How a hang gets reported if the app recovers from a relatively short hang and continues running. Non-fatal app hangs do not have a "Crash" mark on them in Error Tracking and the RUM explorer. +- **Non-fatal app hang**: How a hang gets reported if the app recovers from a relatively short hang and continues running. Non-fatal app hangs do not have a "Crash" mark on them in {{< prodname >}}Error Tracking{{< /prodname >}} and the RUM explorer. {{< img src="real_user_monitoring/error_tracking/ios-non-fatal-app-hang-1.png" alt="A non-fatal app hang in the Error side panel." style="width:100%;" >}} @@ -551,7 +551,7 @@ To disable app hang monitoring, update the initialization snippet and set the `a Crash reports are collected in a raw format and mostly contain memory addresses. To map these addresses into legible symbol information (a process called symbolication), Datadog requires `.dSYM` files, which are generated in your application's build or distribution process. -**Note:** Error Tracking supports symbolication of system symbol files for iOS v14+ arm64 and arm64e architecture. `.dSYM` files are limited in size to **2 GB** each. +**Note:** {{< prodname >}}Error Tracking{{< /prodname >}} supports symbolication of system symbol files for iOS v14+ arm64 and arm64e architecture. `.dSYM` files are limited in size to **2 GB** each. To help you debug errors, Datadog uses a unique generated build ID to deobfuscate stack traces, matching them with their corresponding mapping files. This process occurs regardless of whether the mapping files were uploaded during pre-production or production builds, ensuring the correct information is available for efficient QA processes when reviewing crashes and errors in Datadog. @@ -677,7 +677,7 @@ For more information, see [dSYMs commands][2]. ## Test your implementation -To verify your iOS Crash Reporting and Error Tracking configuration, issue a crash in your application and confirm that the error appears in Datadog. +To verify your iOS Crash Reporting and {{< prodname >}}Error Tracking{{< /prodname >}} configuration, issue a crash in your application and confirm that the error appears in Datadog. 1. Run your application on an iOS simulator or a real device. Ensure that the debugger is not attached. Otherwise, Xcode captures the crash before the iOS SDK does. 2. Execute the code containing the crash: diff --git a/hugo/content/en/error_tracking/frontend/mobile/kotlin-multiplatform.md b/hugo/content/en/error_tracking/frontend/mobile/kotlin-multiplatform.md index 7aa274c2126..529ffa002f7 100644 --- a/hugo/content/en/error_tracking/frontend/mobile/kotlin-multiplatform.md +++ b/hugo/content/en/error_tracking/frontend/mobile/kotlin-multiplatform.md @@ -14,9 +14,9 @@ further_reading: ## Overview -Error Tracking processes errors collected from the Kotlin Multiplatform SDK. +{{< prodname >}}Error Tracking{{< /prodname >}} processes errors collected from the Kotlin Multiplatform SDK. -Enable Kotlin Multiplatform Crash Reporting and Error Tracking to get comprehensive crash reports and error trends. With this feature, you can access: +Enable Kotlin Multiplatform Crash Reporting and {{< prodname >}}Error Tracking{{< /prodname >}} to get comprehensive crash reports and error trends. With this feature, you can access: - Aggregated Kotlin Multiplatform crash dashboards and attributes - Deobfuscated Kotlin Multiplatform (iOS and Android) crash reports @@ -26,7 +26,7 @@ Your crash reports appear in [**Error Tracking**][1]. ## Setup -If you have not set up the Kotlin Multiplatform SDK yet, follow the [in-app setup instructions][2] or see the [Kotlin Multiplatform setup documentation][3]. Then, follow the steps on this page to enable Kotlin Multiplatform Crash Reporting and Error Tracking. +If you have not set up the Kotlin Multiplatform SDK yet, follow the [in-app setup instructions][2] or see the [Kotlin Multiplatform setup documentation][3]. Then, follow the steps on this page to enable Kotlin Multiplatform Crash Reporting and {{< prodname >}}Error Tracking{{< /prodname >}}. **Note**: For any given error, you can access the file path, line number, and a code snippet for each frame of the related stack trace. @@ -391,7 +391,7 @@ The SDK handles crash reporting with the following behaviors: ## Test your implementation -To verify your Kotlin Multiplatform Crash Reporting and Error Tracking configuration, you need to trigger a crash in your application and confirm that the error appears in Datadog. +To verify your Kotlin Multiplatform Crash Reporting and {{< prodname >}}Error Tracking{{< /prodname >}} configuration, you need to trigger a crash in your application and confirm that the error appears in Datadog. To test your implementation: @@ -404,7 +404,7 @@ To test your implementation: } ``` -3. After the crash happens, restart your application and wait for the Kotlin Multiplatform SDK to upload the crash report in [**Error Tracking**][1]. +3. After the crash happens, restart your application and wait for the Kotlin Multiplatform SDK to upload the crash report in [**{{< prodname >}}Error Tracking{{< /prodname >}}**][1]. ## Advanced Error Tracking Features diff --git a/hugo/content/en/error_tracking/guides/_index.md b/hugo/content/en/error_tracking/guides/_index.md index 69448279c3c..01cdaa4855a 100644 --- a/hugo/content/en/error_tracking/guides/_index.md +++ b/hugo/content/en/error_tracking/guides/_index.md @@ -5,7 +5,7 @@ disable_toc: true --- {{< whatsnext desc="Enable other products from a standalone Backend Error Tracking installation:" >}} - {{< nextlink href="/error_tracking/guides/enable_infra" >}}Enable Infrastructure Monitoring with backend standalone Error Tracking {{< /nextlink >}} - {{< nextlink href="/error_tracking/guides/enable_apm" >}}Enable APM with backend standalone Error Tracking{{< /nextlink >}} - {{< nextlink href="/error_tracking/guides/sentry_sdk" >}} Enable Sentry SDK with backend standalone Error Tracking{{< /nextlink >}} + {{< nextlink href="/error_tracking/guides/enable_infra" >}}Enable Infrastructure Monitoring with backend standalone {{< prodname >}}Error Tracking{{< /prodname >}} {{< /nextlink >}} + {{< nextlink href="/error_tracking/guides/enable_apm" >}}Enable APM with backend standalone {{< prodname >}}Error Tracking{{< /prodname >}}{{< /nextlink >}} + {{< nextlink href="/error_tracking/guides/sentry_sdk" >}} Enable Sentry SDK with backend standalone {{< prodname >}}Error Tracking{{< /prodname >}}{{< /nextlink >}} {{< /whatsnext >}} diff --git a/hugo/content/en/error_tracking/guides/sentry_sdk.md b/hugo/content/en/error_tracking/guides/sentry_sdk.md index f9c7d5062d1..b39a97e5876 100644 --- a/hugo/content/en/error_tracking/guides/sentry_sdk.md +++ b/hugo/content/en/error_tracking/guides/sentry_sdk.md @@ -7,11 +7,11 @@ further_reading: text: "Manage Data Collection" ---
-Using the Sentry SDK with Error Tracking helps you migrate to Datadog. However, to get the most out of Error Tracking, it is recommended to use the Datadog SDKs. See Frontend Error Tracking and Backend Error Tracking. +Using the Sentry SDK with {{< prodname >}}Error Tracking{{< /prodname >}} helps you migrate to Datadog. However, to get the most out of {{< prodname >}}Error Tracking{{< /prodname >}}, it is recommended to use the Datadog SDKs. See Frontend Error Tracking and Backend Error Tracking.
## Overview -You can use [Sentry SDKs][1] to send your events to Datadog, so you can start using Error Tracking on existing applications that are instrumented using Sentry SDKs. +You can use [Sentry SDKs][1] to send your events to Datadog, so you can start using {{< prodname >}}Error Tracking{{< /prodname >}} on existing applications that are instrumented using Sentry SDKs. Setting up the Sentry SDK with Datadog requires a minimal code change to point the SDK to a Datadog Data Source Name (DSN). @@ -19,7 +19,7 @@ Setting up the Sentry SDK with Datadog requires a minimal code change to point t ## Supported SDKs -The following Sentry SDKs are verified to work with Error Tracking: +The following Sentry SDKs are verified to work with {{< prodname >}}Error Tracking{{< /prodname >}}: | Platform | Tested version | | ---------- | ------------------------------------------------- | @@ -32,9 +32,9 @@ The following Sentry SDKs are verified to work with Error Tracking: ## Setup ### Prerequisites -Sentry SDK events are sent into Datadog as logs. You must have [Error Tracking for Logs][2] enabled for errors to show up in Error Tracking. +Sentry SDK events are sent into Datadog as logs. You must have [Error Tracking for Logs][2] enabled for errors to show up in {{< prodname >}}Error Tracking{{< /prodname >}}. -**Note:** By default, enabling Error Tracking for Logs enables Error Tracking on **all** of your logs. You can use [rules][9] to configure Error Tracking for Logs to **only** collect errors from the Sentry SDK. To do this, create a rule for logs with scope `source:sentry-sdk`, and create an exclusion rule for all other logs. +**Note:** By default, enabling {{< prodname >}}Error Tracking{{< /prodname >}} for Logs enables {{< prodname >}}Error Tracking{{< /prodname >}} on **all** of your logs. You can use [rules][9] to configure {{< prodname >}}Error Tracking{{< /prodname >}} for Logs to **only** collect errors from the Sentry SDK. To do this, create a rule for logs with scope `source:sentry-sdk`, and create an exclusion rule for all other logs. {{< img src="error_tracking/sentry-sdk-rules.png" alt="Error Tracking rules including only Logs from the Sentry SDK" style="width:70%;" >}} @@ -115,7 +115,7 @@ To configure the Sentry SDK to send events into Datadog: ### Upload JavaScript source maps -If your frontend JavaScript source code is minified, you can upload source maps to Datadog to deobfuscate stack traces in Error Tracking. See [Upload JavaScript Source Maps][4]. +If your frontend JavaScript source code is minified, you can upload source maps to Datadog to deobfuscate stack traces in {{< prodname >}}Error Tracking{{< /prodname >}}. See [Upload JavaScript Source Maps][4]. The `version` on source maps is matched with the `release` [configured][11] on the Sentry SDK. @@ -178,7 +178,7 @@ Sentry.set_tags('git.repository_url', '') ## Migrate to the recommended setup -To get the most out of Error Tracking, Datadog recommends migrating to the Datadog SDK and/or Agent-based setups. See [Backend Error Tracking][7] and [Frontend Error Tracking][8] for more information. +To get the most out of {{< prodname >}}Error Tracking{{< /prodname >}}, Datadog recommends migrating to the Datadog SDK and/or Agent-based setups. See [Backend Error Tracking][7] and [Frontend Error Tracking][8] for more information. The Sentry SDK setup can be used simultaneously with the recommended setup. Errors may be reported twice. diff --git a/hugo/content/en/error_tracking/issue_states.md b/hugo/content/en/error_tracking/issue_states.md index 34582525c18..273db2f8db6 100644 --- a/hugo/content/en/error_tracking/issue_states.md +++ b/hugo/content/en/error_tracking/issue_states.md @@ -8,7 +8,7 @@ further_reading: ## Overview -All issues in Error Tracking have a status to help you triage and prioritize issues or dismiss noise. There are five statuses: +All issues in {{< prodname >}}Error Tracking{{< /prodname >}} have a status to help you triage and prioritize issues or dismiss noise. There are five statuses: - {{< ui >}}FOR REVIEW{{< /ui >}}: New or regressed issues that need attention. - {{< ui >}}REVIEWED{{< /ui >}}: Triaged issues that need to be fixed, now or later. @@ -16,14 +16,14 @@ All issues in Error Tracking have a status to help you triage and prioritize iss - {{< ui >}}IGNORED{{< /ui >}}: Issues that require no further investigation or action. - {{< ui >}}EXCLUDED{{< /ui >}}: Issues that require no further investigation, stops collecting new errors, and no longer count towards usage or billing -All issues start with a FOR REVIEW status. Error Tracking automatically updates the status in the cases described below, or you can [manually update the status](#updating-an-error-status). You can also [view the history](#issue-history) of a given error's state changes. +All issues start with a FOR REVIEW status. {{< prodname >}}Error Tracking{{< /prodname >}} automatically updates the status in the cases described below, or you can [manually update the status](#updating-an-error-status). You can also [view the history](#issue-history) of a given error's state changes. -The diagram below shows how the Error Tracking states are updated automatically and manually: +The diagram below shows how the {{< prodname >}}Error Tracking{{< /prodname >}} states are updated automatically and manually: {{< img src="error_tracking/issue-states-diagram.png" alt="Error Tracking Issue States" style="width:75%;" >}} ## Automatic review -Error Tracking automatically marks issues as {{< ui >}}REVIEWED{{< /ui >}} if one of the following actions has been taken: +{{< prodname >}}Error Tracking{{< /prodname >}} automatically marks issues as {{< ui >}}REVIEWED{{< /ui >}} if one of the following actions has been taken: - The issue has been assigned - A case has been created from the issue @@ -32,10 +32,10 @@ Error Tracking automatically marks issues as {{< ui >}}REVIEWED{{< /ui >}} if on ## Automatic resolution -Error Tracking automatically marks issues as {{< ui >}}RESOLVED{{< /ui >}} that appear to be inactive or resolved due to a lack of recent error occurrences: +{{< prodname >}}Error Tracking{{< /prodname >}} automatically marks issues as {{< ui >}}RESOLVED{{< /ui >}} that appear to be inactive or resolved due to a lack of recent error occurrences: -- If the issue was last reported in a version that is more than 14 days old, and a newer version has been released but does not report the same error, Error Tracking automatically resolves the issue. Configure your services with version tags (see instructions for [APM][1], [RUM][2], and [Logs][3]) to ensure that automatic resolution accounts for versions of your services. -- If `version` tags are not set up, Error Tracking automatically resolves an issue if there have been no new errors reported for that issue within the last 14 days. +- If the issue was last reported in a version that is more than 14 days old, and a newer version has been released but does not report the same error, {{< prodname >}}Error Tracking{{< /prodname >}} automatically resolves the issue. Configure your services with version tags (see instructions for [APM][1], [RUM][2], and [Logs][3]) to ensure that automatic resolution accounts for versions of your services. +- If `version` tags are not set up, {{< prodname >}}Error Tracking{{< /prodname >}} automatically resolves an issue if there have been no new errors reported for that issue within the last 14 days. **Note**: The auto-resolution logic does not take `version` into account. @@ -61,7 +61,7 @@ To resume collecting errors for an excluded issue, select any status other than ## Issue history -View a history of your issue activity with the {{< ui >}}Activity Timeline{{< /ui >}}. On the details panel of any Error Tracking issue, view the Activity Timeline by clicking the {{< ui >}}Activity{{< /ui >}} tab. +View a history of your issue activity with the {{< ui >}}Activity Timeline{{< /ui >}}. On the details panel of any {{< prodname >}}Error Tracking{{< /prodname >}} issue, view the Activity Timeline by clicking the {{< ui >}}Activity{{< /ui >}} tab. {{< img src="error_tracking/issue-status-history-3.png" alt="The Activity Timeline in the Error Tracking Issue" style="width:80%;" >}} diff --git a/hugo/content/en/error_tracking/issue_team_ownership.md b/hugo/content/en/error_tracking/issue_team_ownership.md index 89ce8ff412e..635f9e540af 100644 --- a/hugo/content/en/error_tracking/issue_team_ownership.md +++ b/hugo/content/en/error_tracking/issue_team_ownership.md @@ -56,7 +56,7 @@ Your team owns an issue if it is the code owner of the top-level stack frame of ### Setup -1. Ensure [Source Code Integration][1] is set up. +1. Ensure [{{< prodname >}}Source Code Integration{{< /prodname >}}][1] is set up. 2. Install [the GitHub integration][2]. 3. Make sure the GitHub integration has all requested permissions (Contents and Members). 4. Create a valid `CODEOWNERS` file in your repository following [GitHub's CODEOWNERS standards][3]. diff --git a/hugo/content/en/error_tracking/link_pull_requests.md b/hugo/content/en/error_tracking/link_pull_requests.md index 5907ade8752..01c21846bc4 100644 --- a/hugo/content/en/error_tracking/link_pull_requests.md +++ b/hugo/content/en/error_tracking/link_pull_requests.md @@ -14,23 +14,23 @@ further_reading: ## Overview -Link GitHub pull requests to Error Tracking issues and track the full life cycle of an error, from detection to resolution. This link enables Datadog to automatically resolve the Error Tracking issue when the associated PR is merged. +Link GitHub pull requests to {{< prodname >}}Error Tracking{{< /prodname >}} issues and track the full life cycle of an error, from detection to resolution. This link enables Datadog to automatically resolve the {{< prodname >}}Error Tracking{{< /prodname >}} issue when the associated PR is merged. With linked pull requests, you can: -- **Track issue resolution**: See which pull requests are addressing an Error Tracking issue directly from the issue panel. +- **Track issue resolution**: See which pull requests are addressing an {{< prodname >}}Error Tracking{{< /prodname >}} issue directly from the issue panel. - **Automatically resolve issues**: When a linked pull request is merged, Datadog automatically moves the issue to `Resolved` status. ## Prerequisites - Install [the GitHub integration][2] with read permissions for pull requests. -- Enable [Source Code Integration][3] so that Datadog can process GitHub webhooks and link pull requests to Error Tracking issues. -- Verify that you have the [{{< ui >}}Error Tracking Issue Write{{< /ui >}} permission][4]. This is required to link your PRs to Error Tracking issues. +- Enable [{{< prodname >}}Source Code Integration{{< /prodname >}}][3] so that Datadog can process GitHub webhooks and link pull requests to {{< prodname >}}Error Tracking{{< /prodname >}} issues. +- Verify that you have the [{{< ui >}}Error Tracking Issue Write{{< /ui >}} permission][4]. This is required to link your PRs to {{< prodname >}}Error Tracking{{< /prodname >}} issues. ## Link and manage pull requests ### Link a pull request to an issue -To link a pull request to an Error Tracking issue: +To link a pull request to an {{< prodname >}}Error Tracking{{< /prodname >}} issue: 1. Navigate to [Datadog Error Tracking][1]. 1. Select the issue you want to link to open its side panel. @@ -54,7 +54,7 @@ To view linked pull requests: ### Unlink a pull request -To unlink a pull request from an issue, open the GitHub pull request and remove the Error Tracking issue URL from the description. +To unlink a pull request from an issue, open the GitHub pull request and remove the {{< prodname >}}Error Tracking{{< /prodname >}} issue URL from the description. ## Automatic state changes diff --git a/hugo/content/en/error_tracking/manage_data_collection.md b/hugo/content/en/error_tracking/manage_data_collection.md index cb6179c727b..172453ba1a6 100644 --- a/hugo/content/en/error_tracking/manage_data_collection.md +++ b/hugo/content/en/error_tracking/manage_data_collection.md @@ -12,9 +12,9 @@ further_reading: ## Overview -Error Tracking provides fine-grained control of which errors to ingest, helping you reduce noise and avoid unexpected costs. +{{< prodname >}}Error Tracking{{< /prodname >}} provides fine-grained control of which errors to ingest, helping you reduce noise and avoid unexpected costs. -You can define what data is included in Error Tracking in two ways: +You can define what data is included in {{< prodname >}}Error Tracking{{< /prodname >}} in two ways: - [Rules](#rules-inclusion) - [Rate limits](#rate-limits) @@ -23,7 +23,7 @@ You can configure both rules and rate limits on the [{{< ui >}}Error Tracking{{< ## Rules -Rules allow you to select which errors are ingested into Error Tracking. They apply to both billable and non-billable errors. +Rules allow you to select which errors are ingested into {{< prodname >}}Error Tracking{{< /prodname >}}. They apply to both billable and non-billable errors. Each rule consists of: - A scope: an inclusion filter, which contains a search query, such as `service:my-web-store`. @@ -33,7 +33,7 @@ An event is included if it matches a rule's inclusion filter and does not match Events are checked against rules in order. Evaluation stops at the first matching active rule, and subsequent rules are ignored. -**Note:** Error events that get accepted by a rule might still be excluded from Error Tracking if they lack the [required attributes][2]. +**Note:** Error events that get accepted by a rule might still be excluded from {{< prodname >}}Error Tracking{{< /prodname >}} if they lack the [required attributes][2]. ### How rules are evaluated @@ -74,14 +74,14 @@ The processing flow is as follows: ### Default rules -By default, Error Tracking includes an `*` inclusion filter with no exclusion filters. This catch-all means any event that does not match your other rules is still ingested. To restrict ingestion to specific sources, add exclusion filters to the default rule, or remove it and replace it with explicit inclusion rules. +By default, {{< prodname >}}Error Tracking{{< /prodname >}} includes an `*` inclusion filter with no exclusion filters. This catch-all means any event that does not match your other rules is still ingested. To restrict ingestion to specific sources, add exclusion filters to the default rule, or remove it and replace it with explicit inclusion rules. ### Add a rule To add a rule (inclusion filter): 1. Navigate to [Error Tracking Settings][1]. 2. Click {{< ui >}}Add New Rule{{< /ui >}}. -3. Choose the {{< ui >}}Error Tracking source{{< /ui >}} the rule should be applied to. +3. Choose the {{< ui >}}{{< prodname >}}Error Tracking{{< /prodname >}} source{{< /ui >}} the rule should be applied to. 4. Enter a search query in the {{< ui >}}Define scope{{< /ui >}} field. 5. Optionally, {{< ui >}}Add Exclusion{{< /ui >}} filters and a description to the rule. 6. Click {{< ui >}}Save Changes{{< /ui >}} @@ -92,7 +92,7 @@ To add a rule (inclusion filter): ## Rate limits -Rate limits allow you to control the number of billable errors included in Error Tracking per day. This cap applies to all errors that match the filters of a [rule](#rules). +Rate limits allow you to control the number of billable errors included in {{< prodname >}}Error Tracking{{< /prodname >}} per day. This cap applies to all errors that match the filters of a [rule](#rules). After the daily cap is reached, ingestion stops until the next day. You can modify or remove the cap at any time. @@ -112,17 +112,17 @@ A `Rate limit applied` event is generated when you reach the rate limit. See the ## Monitoring usage -You can monitor your Error Tracking on Logs usage by setting up monitors and alerts for the `datadog.estimated_usage.error_tracking.logs.events` metric, which tracks the number of ingested error logs. +You can monitor your {{< prodname >}}Error Tracking{{< /prodname >}} on Logs usage by setting up monitors and alerts for the `datadog.estimated_usage.error_tracking.logs.events` metric, which tracks the number of ingested error logs. This metric is available by default at no additional cost, and its data is retained for 15 months. ## Dynamic Sampling -Because Error Tracking billing is based on the number of errors, large increases in the errors for a single issue can quickly consume your Error Tracking budget. Dynamic Sampling protects you by establishing a threshold for the error rate per issue based on your daily rate limit and historical error volumes, sampling errors when that threshold is reached. Dynamic Sampling automatically deactivates when the error rate of your issue decreases below the given threshold. +Because Error Tracking billing is based on the number of errors, large increases in the errors for a single issue can quickly consume your {{< prodname >}}Error Tracking{{< /prodname >}} budget. Dynamic Sampling protects you by establishing a threshold for the error rate per issue based on your daily rate limit and historical error volumes, sampling errors when that threshold is reached. Dynamic Sampling automatically deactivates when the error rate of your issue decreases below the given threshold. ### Setup -Dynamic Sampling is automatically enabled with Error Tracking with a default intake threshold based on your daily rate limit and historical volume. +Dynamic Sampling is automatically enabled with {{< prodname >}}Error Tracking{{< /prodname >}} with a default intake threshold based on your daily rate limit and historical volume. For best results, set up a daily rate limit on the [Error Tracking Rate Limits page][5]: Click {{< ui >}}Edit Rate Limit{{< /ui >}} and enter a new value. @@ -144,9 +144,9 @@ A `Dynamic Sampling activated` event is generated when Dynamic Sampling is appli When Dynamic Sampling is applied, the following steps are recommended: -- Check which issue is consuming your quota. The issue to which Dynamic Sampling is applied is linked in the event generated in Event Management. +- Check which issue is consuming your quota. The issue to which Dynamic Sampling is applied is linked in the event generated in {{< prodname >}}Event Management{{< /prodname >}}. - If you'd like to collect additional samples for this issue, raise your daily quota on the [Error Tracking Rate Limits page][5]. -- If you'd like to avoid collecting samples for this issue in the future, consider creating an exclusion filter to prevent additional events from being ingested into Error Tracking. +- If you'd like to avoid collecting samples for this issue in the future, consider creating an exclusion filter to prevent additional events from being ingested into {{< prodname >}}Error Tracking{{< /prodname >}}. ## Further Reading diff --git a/hugo/content/en/error_tracking/regression_detection.md b/hugo/content/en/error_tracking/regression_detection.md index 8782650c759..d8eca08dcc5 100644 --- a/hugo/content/en/error_tracking/regression_detection.md +++ b/hugo/content/en/error_tracking/regression_detection.md @@ -13,7 +13,7 @@ A regression refers to the unintended reappearance of a bug or issue that was pr ## Automatic re-opening through regression detection -If a {{< ui >}}RESOLVED{{< /ui >}} error recurs in a newer version of the code, or the error occurs again in code without versions, Error Tracking triggers a regression. The issue moves to the {{< ui >}}FOR REVIEW{{< /ui >}} state, and is tagged with a {{< ui >}}Regression{{< /ui >}} tag: +If a {{< ui >}}RESOLVED{{< /ui >}} error recurs in a newer version of the code, or the error occurs again in code without versions, {{< prodname >}}Error Tracking{{< /prodname >}} triggers a regression. The issue moves to the {{< ui >}}FOR REVIEW{{< /ui >}} state, and is tagged with a {{< ui >}}Regression{{< /ui >}} tag: {{< img src="error_tracking/regression-detection.png" alt="The details of regression in Error Tracking" style="width:90%;" >}} @@ -30,7 +30,7 @@ The issue status appears anywhere the issue can be viewed, such as in the issues {{< img src="error_tracking/updating-issue-status.png" alt="The Activity Timeline in the Error Tracking Issue" style="width:100%;" >}} ## Issue history -View a history of your issue activity with the {{< ui >}}Activity Timeline{{< /ui >}}. On the details panel of any Error Tracking issue, view the Activity Timeline by clicking the {{< ui >}}Activity{{< /ui >}} tab. +View a history of your issue activity with the {{< ui >}}Activity Timeline{{< /ui >}}. On the details panel of any {{< prodname >}}Error Tracking{{< /prodname >}} issue, view the Activity Timeline by clicking the {{< ui >}}Activity{{< /ui >}} tab. {{< img src="error_tracking/issue-status-history-3.png" alt="The Activity Timeline in the Error Tracking Issue" style="width:80%;" >}} diff --git a/hugo/content/en/error_tracking/suspect_commits.md b/hugo/content/en/error_tracking/suspect_commits.md index f312d39e796..6efb035b520 100644 --- a/hugo/content/en/error_tracking/suspect_commits.md +++ b/hugo/content/en/error_tracking/suspect_commits.md @@ -8,7 +8,7 @@ further_reading: --- ## Overview -Error Tracking can identify suspect commits, helping you pinpoint the root cause of your errors and expedite resolution. This feature is automatically enabled on issues when the [setup requirements](#setup) are met. +{{< prodname >}}Error Tracking{{< /prodname >}} can identify suspect commits, helping you pinpoint the root cause of your errors and expedite resolution. This feature is automatically enabled on issues when the [setup requirements](#setup) are met. {{< img src="logs/error_tracking/suspect_commit.png" alt="A suspect commit as it is displayed in the Datadog UI" style="width:100%" >}} @@ -33,7 +33,7 @@ Once the setup requirements are met, suspect commits automatically appear on iss ### Enable Source Code Integration -The Suspect Commits feature requires [Source Code Integration][1]. To enable Source Code Integration: +The Suspect Commits feature requires [{{< prodname >}}Source Code Integration{{< /prodname >}}][1]. To enable {{< prodname >}}Source Code Integration{{< /prodname >}}: 1. On the [{{< ui >}}Integrations{{< /ui >}} page][3] in Datadog, choose {{< ui >}}Link Source Code{{< /ui >}} in the top navbar. 2. Follow the steps to associate a commit with your telemetry and configure your GitHub repository. diff --git a/hugo/content/en/error_tracking/ticketing_systems/_index.md b/hugo/content/en/error_tracking/ticketing_systems/_index.md index 5d2e986040e..334180bb183 100644 --- a/hugo/content/en/error_tracking/ticketing_systems/_index.md +++ b/hugo/content/en/error_tracking/ticketing_systems/_index.md @@ -16,13 +16,13 @@ further_reading: ## Overview -Datadog Error Tracking integrates with your existing ticketing workflows to streamline issue resolution. Link Error Tracking issues to Jira tickets, Linear issues, or Case Management cases to track and resolve errors within your established processes. +Datadog Error Tracking integrates with your existing ticketing workflows to streamline issue resolution. Link Error Tracking issues to Jira tickets, Linear issues, or {{< prodname >}}Case Management{{< /prodname >}} cases to track and resolve errors within your established processes. With ticketing system integrations, you can: -- **Create tickets directly from issues**: Open Jira tickets, Linear issues, or Case Management cases from the Error Tracking issue panel to centralize investigation efforts. -- **Group multiple issues into a single ticket**: Attach several related Error Tracking issues to one ticket or case, consolidating correlated issues into a single unit of work. -- **Automate ticket creation**: Configure rules to automatically create tickets in specific Jira boards or Case Management projects when issues match specific criteria. +- **Create tickets directly from issues**: Open Jira tickets, Linear issues, or {{< prodname >}}Case Management{{< /prodname >}} cases from the {{< prodname >}}Error Tracking{{< /prodname >}} issue panel to centralize investigation efforts. +- **Group multiple issues into a single ticket**: Attach several related {{< prodname >}}Error Tracking{{< /prodname >}} issues to one ticket or case, consolidating correlated issues into a single unit of work. +- **Automate ticket creation**: Configure rules to automatically create tickets in specific Jira boards or {{< prodname >}}Case Management{{< /prodname >}} projects when issues match specific criteria. These features help your teams respond to errors faster by bridging the gap between error detection and resolution workflows. @@ -31,7 +31,7 @@ These features help your teams respond to errors faster by bridging the gap betw {{< whatsnext desc="Select your ticketing system to get started:" >}} {{< nextlink href="error_tracking/ticketing_systems/jira" >}}Jira{{< /nextlink >}} {{< nextlink href="error_tracking/ticketing_systems/linear" >}}Linear{{< /nextlink >}} - {{< nextlink href="error_tracking/ticketing_systems/case_management" >}}Case Management{{< /nextlink >}} + {{< nextlink href="error_tracking/ticketing_systems/case_management" >}}{{< prodname >}}Case Management{{< /prodname >}}{{< /nextlink >}} {{< /whatsnext >}} ## Further Reading diff --git a/hugo/content/en/error_tracking/ticketing_systems/case_management.md b/hugo/content/en/error_tracking/ticketing_systems/case_management.md index a8be9deed69..7e846007501 100644 --- a/hugo/content/en/error_tracking/ticketing_systems/case_management.md +++ b/hugo/content/en/error_tracking/ticketing_systems/case_management.md @@ -16,16 +16,16 @@ further_reading: ## Overview -Integrate Case Management with Error Tracking to create and link Case Management cases to Error Tracking issues. With Case Management for Error Tracking, you can: +Integrate Case Management with {{< prodname >}}Error Tracking{{< /prodname >}} to create and link {{< prodname >}}Case Management{{< /prodname >}} cases to {{< prodname >}}Error Tracking{{< /prodname >}} issues. With Case Management for {{< prodname >}}Error Tracking{{< /prodname >}}, you can: -- Create Case Management cases directly from the Error Tracking issue panel -- Group multiple Error Tracking issues into a single case -- Automatically route issues to specific Case Management projects using automation rules -- Automatically create Case Management cases for Error Tracking issues matching specific criteria. +- Create Case Management cases directly from the {{< prodname >}}Error Tracking{{< /prodname >}} issue panel +- Group multiple {{< prodname >}}Error Tracking{{< /prodname >}} issues into a single case +- Automatically route issues to specific {{< prodname >}}Case Management{{< /prodname >}} projects using automation rules +- Automatically create {{< prodname >}}Case Management{{< /prodname >}} cases for {{< prodname >}}Error Tracking{{< /prodname >}} issues matching specific criteria. ## Setup -You need the following [permissions][1] to use the Case Management integration for Error Tracking: +You need the following [permissions][1] to use the {{< prodname >}}Case Management{{< /prodname >}} integration for {{< prodname >}}Error Tracking{{< /prodname >}}: - Error Tracking Read - Error Tracking Issue Write @@ -34,24 +34,24 @@ You need the following [permissions][1] to use the Case Management integration f ## Create a case from an issue -You can create a Case Management case directly from the issue panel to group investigation efforts on that issue: +You can create a {{< prodname >}}Case Management{{< /prodname >}} case directly from the issue panel to group investigation efforts on that issue: 1. Navigate to the [Error Tracking Explorer][2]. 2. Click on an issue to open the issue panel. 3. In the issue panel, in the {{< ui >}}Actions{{< /ui >}} dropdown, click {{< ui >}}Add Case{{< /ui >}}. -4. Choose the Case Management project in which the case should be created. By default, the case will automatically be created in the Error Tracking project. +4. Choose the {{< prodname >}}Case Management{{< /prodname >}} project in which the case should be created. By default, the case will automatically be created in the {{< prodname >}}Error Tracking{{< /prodname >}} project. 5. Click {{< ui >}}Create{{< /ui >}} to create the case. {{< img src="error_tracking/create-case.png" alt="Create a Case Management case from an Error Tracking issue" style="width:100%;" >}} -After it is created, the case is linked to the Error Tracking issue. The case link then appears in the issue panel, and the issue status automatically changes to {{< ui >}}REVIEWED{{< /ui >}}. +After it is created, the case is linked to the {{< prodname >}}Error Tracking{{< /prodname >}} issue. The case link then appears in the issue panel, and the issue status automatically changes to {{< ui >}}REVIEWED{{< /ui >}}. When an issue is linked to a case, their state, assignee, and comments are two-way synced. See [State dual-way sync between issues and cases](#state-dual-way-sync-between-issues-and-cases) for more information on how the issue state and case status are synced. ## Group multiple issues into a single case -You can attach multiple Error Tracking issues to a single Case Management case to group correlated issues into a single unit of work: +You can attach multiple {{< prodname >}}Error Tracking{{< /prodname >}} issues to a single {{< prodname >}}Case Management{{< /prodname >}} case to group correlated issues into a single unit of work: 1. Navigate to the [Error Tracking Explorer][2]. 2. Click on an issue to open the issue panel. @@ -62,7 +62,7 @@ You can attach multiple Error Tracking issues to a single Case Management case t {{< img src="error_tracking/add-to-existing-case.png" alt="Add an Error Tracking issue to an existing case" >}} -All linked Error Tracking issues appear in the case view, providing a consolidated view of related errors. +All linked {{< prodname >}}Error Tracking{{< /prodname >}} issues appear in the case view, providing a consolidated view of related errors. {{< img src="error_tracking/group-issues-into-a-case.png" alt="Link multiple Error Tracking issues to a single case" >}} @@ -74,7 +74,7 @@ The relationship between cases and issues is a 1:N relationship. A single case c ### Single Error Tracking issue linked to single Case Management case -When a single Error Tracking issue is linked to a Case Management case, their states are two-way synced. The issue state is mapped to +When a single {{< prodname >}}Error Tracking{{< /prodname >}} issue is linked to a {{< prodname >}}Case Management{{< /prodname >}} case, their states are two-way synced. The issue state is mapped to the default status of the corresponding case status group: | Error Tracking Issue State | Case Management Status Group | @@ -87,7 +87,7 @@ the default status of the corresponding case status group: ### Multiple Error Tracking issues linked to single Case Management case -When multiple Error Tracking issues are linked to the same Case Management case, there is also a sync between their states, depending on the situation: +When multiple {{< prodname >}}Error Tracking{{< /prodname >}} issues are linked to the same {{< prodname >}}Case Management{{< /prodname >}} case, there is also a sync between their states, depending on the situation: - If you update the status of the case, all linked issues are updated following the state mapping described in the previous paragraph. - If you update the state of an issue, the resulting state of other linked issues and the case follows these rules: @@ -100,23 +100,23 @@ When multiple Error Tracking issues are linked to the same Case Management case, ## Automation rules -You can configure rules to match specific issues to Case Management projects. For example, when an issue matches a rule, any case created manually or automatically for that issue defaults into the project specified by that rule. +You can configure rules to match specific issues to {{< prodname >}}Case Management{{< /prodname >}} projects. For example, when an issue matches a rule, any case created manually or automatically for that issue defaults into the project specified by that rule. ### Setup -To create automation rules for your Error Tracking issues, you need one (1) of the following [permissions][1] : +To create automation rules for your {{< prodname >}}Error Tracking{{< /prodname >}} issues, you need one (1) of the following [permissions][1] : - Error Tracking Write - Error Tracking Settings Write ### Create an automation rule -To create an automation rule for Case Management: +To create an automation rule for {{< prodname >}}Case Management{{< /prodname >}}: 1. Navigate to [Error Tracking Settings][3], in the {{< ui >}}Ticketing & Automation{{< /ui >}} section. 2. Click {{< ui >}}New Rule{{< /ui >}}. 3. Configure the rule: - {{< ui >}}Match Criteria{{< /ui >}}: Define conditions that issues must meet to trigger the rule - - {{< ui >}}Project{{< /ui >}}: Select the destination Case Management project when cases are created from issues that match the rule + - {{< ui >}}Project{{< /ui >}}: Select the destination {{< prodname >}}Case Management{{< /prodname >}} project when cases are created from issues that match the rule - {{< ui >}}Auto-create{{< /ui >}}: Optionally enable automatic case creation when issues match 4. Click {{< ui >}}Save Rule{{< /ui >}}. @@ -143,7 +143,7 @@ When adding an automation rule, you can enable automatic case creation for issue {{< img src="error_tracking/enable-auto-case-creation.png" alt="Enable automatic case creation" style="height:300px;" >}} -By default, when a new Error Tracking issue is created, rules are evaluated and the first rule that matches is applied. If automatic case creation is enabled on that matching rule, a new Case Management case is created in the project specified in your rule, and attached to the matching issue. +By default, when a new {{< prodname >}}Error Tracking{{< /prodname >}} issue is created, rules are evaluated and the first rule that matches is applied. If automatic case creation is enabled on that matching rule, a new {{< prodname >}}Case Management{{< /prodname >}} case is created in the project specified in your rule, and attached to the matching issue. ## Further reading diff --git a/hugo/content/en/error_tracking/ticketing_systems/jira.md b/hugo/content/en/error_tracking/ticketing_systems/jira.md index c5c30d7b9d5..5c9a6600aa3 100644 --- a/hugo/content/en/error_tracking/ticketing_systems/jira.md +++ b/hugo/content/en/error_tracking/ticketing_systems/jira.md @@ -17,16 +17,16 @@ further_reading: ## Overview -Integrate Jira with Error Tracking to create and link Jira tickets to Error Tracking issues. With Jira for Error Tracking, you can: +Integrate Jira with {{< prodname >}}Error Tracking{{< /prodname >}} to create and link Jira tickets to {{< prodname >}}Error Tracking{{< /prodname >}} issues. With Jira for {{< prodname >}}Error Tracking{{< /prodname >}}, you can: -- Create Jira tickets directly from the Error Tracking issue panel -- Group multiple Error Tracking issues into a single ticket +- Create Jira tickets directly from the {{< prodname >}}Error Tracking{{< /prodname >}} issue panel +- Group multiple {{< prodname >}}Error Tracking{{< /prodname >}} issues into a single ticket - Automatically route issues to specific Jira boards using automation rules -- Automatically create Jira tickets for Error Tracking issues matching specific criteria. +- Automatically create Jira tickets for {{< prodname >}}Error Tracking{{< /prodname >}} issues matching specific criteria. ## Prerequisites -
Ticket creation from an Error Tracking issue is available for Jira Cloud and Data Center. Dual-sync between Jira and Error Tracking is only available for Jira Cloud.
+
Ticket creation from an {{< prodname >}}Error Tracking{{< /prodname >}} issue is available for Jira Cloud and Data Center. Dual-sync between Jira and {{< prodname >}}Error Tracking{{< /prodname >}} is only available for Jira Cloud.
1. Set up the [Jira integration for Datadog][7]. 2. Make sure you have the following [permissions][1]: @@ -49,13 +49,13 @@ You can create a Jira ticket directly from the issue panel to group investigatio {{< img src="error_tracking/create-ticket.png" alt="Create a Jira ticket from an Error Tracking issue" style="width:100%;" >}} -Once created, the ticket is linked to the Error Tracking issue. The ticket link appears in the issue panel, and the issue status automatically changes to {{< ui >}}REVIEWED{{< /ui >}}. +Once created, the ticket is linked to the {{< prodname >}}Error Tracking{{< /prodname >}} issue. The ticket link appears in the issue panel, and the issue status automatically changes to {{< ui >}}REVIEWED{{< /ui >}}. When an issue is linked to a ticket, their state, assignee and comments are two-way synced. See [State dual-way sync between issues and tickets](#state-dual-way-sync-between-issues-and-tickets) for more information on how the issue state and ticket status are synced. ## Group multiple issues into a single ticket -You can attach multiple Error Tracking issues to a single Jira ticket to group correlated issues into a single unit of work: +You can attach multiple {{< prodname >}}Error Tracking{{< /prodname >}} issues to a single Jira ticket to group correlated issues into a single unit of work: 1. Navigate to the [Error Tracking Explorer][2]. 2. Click on an issue to open the issue panel. @@ -73,17 +73,17 @@ The relationship between tickets and issues is a 1:N relationship. A single tick ## State dual-way sync between issues and tickets -If two-way sync is enabled and configured between Datadog and Jira projects, the states of Error Tracking issues and Jira tickets are mirrored. If you encounter any unexpected behavior on this states sync, see the [Troubleshooting](#troubleshooting) section for how to fix your configuration. +If two-way sync is enabled and configured between Datadog and Jira projects, the states of {{< prodname >}}Error Tracking{{< /prodname >}} issues and Jira tickets are mirrored. If you encounter any unexpected behavior on this states sync, see the [Troubleshooting](#troubleshooting) section for how to fix your configuration. ### Single Error Tracking issue linked to single Jira ticket -When a single Error Tracking issue is linked to a Jira ticket, their states are two-way synced. The mapping between these states can be configured in the Data Sync settings of the ticket creation or automation rule forms: +When a single {{< prodname >}}Error Tracking{{< /prodname >}} issue is linked to a Jira ticket, their states are two-way synced. The mapping between these states can be configured in the Data Sync settings of the ticket creation or automation rule forms: {{< img src="error_tracking/jira-status-mapping.png" alt="Map Error Tracking issue states to Jira ticket statuses" style="width:100%;" >}} ### Multiple Error Tracking issues linked to single Jira ticket -When multiple Error Tracking issues are linked to the same Jira ticket, there is also a sync between their states, depending on the situation. If you update the status of the ticket, all linked issues are updated to mirror this state according to your mapping. +When multiple {{< prodname >}}Error Tracking{{< /prodname >}} issues are linked to the same Jira ticket, there is also a sync between their states, depending on the situation. If you update the status of the ticket, all linked issues are updated to mirror this state according to your mapping. Assuming that your mapping is defined as follows: @@ -108,7 +108,7 @@ You can configure rules to match specific issues to Jira boards. When an issue m ### Setup -To create automation rules for your Error Tracking issues, you need one (1) of the following [permissions][1] : +To create automation rules for your {{< prodname >}}Error Tracking{{< /prodname >}} issues, you need one (1) of the following [permissions][1] : - Error Tracking Write - Error Tracking Settings Write @@ -147,22 +147,22 @@ When adding an automation rule, you can enable automatic Jira ticket creation fo {{< img src="error_tracking/enable-auto-ticket-creation.png" alt="Enable automatic case creation" style="height:300px;" >}} -When a new Error Tracking issue is created, rules are evaluated and the first rule that matches is applied. If automatic ticket creation is enabled on that matching rule, a new Jira ticket will be created on the Jira board specified in your rule, and attached to the matching issue. +When a new {{< prodname >}}Error Tracking{{< /prodname >}} issue is created, rules are evaluated and the first rule that matches is applied. If automatic ticket creation is enabled on that matching rule, a new Jira ticket will be created on the Jira board specified in your rule, and attached to the matching issue. ## Troubleshooting -If you experience unexpected behaviors using ticketing systems with Error Tracking, the following troubleshooting steps can help you resolve the issue quickly. If you continue to have trouble, reach out to [Datadog support][5]. +If you experience unexpected behaviors using ticketing systems with {{< prodname >}}Error Tracking{{< /prodname >}}, the following troubleshooting steps can help you resolve the issue quickly. If you continue to have trouble, reach out to [Datadog support][5]. ### Sync is broken between Jira and Error Tracking -If you experience syncing issues between your Jira tickets and the corresponding Error Tracking issues (such as the issue state not being updated when you close the Jira ticket), verify that the following steps are all properly configured: +If you experience syncing issues between your Jira tickets and the corresponding {{< prodname >}}Error Tracking{{< /prodname >}} issues (such as the issue state not being updated when you close the Jira ticket), verify that the following steps are all properly configured: 1. In the issue panel, make sure that the issue is correctly linked to the Jira ticket. -2. A Case Management case was automatically created by Datadog to act as a linking point for the Error Tracking issue and the Jira ticket. You can access this case from the issue panel, to find the Case Management project in which it was created. In Case Management settings, make sure that the Jira integration is enabled for this project, and the correct Jira account and board are configured. +2. A Case Management case was automatically created by Datadog to act as a linking point for the {{< prodname >}}Error Tracking{{< /prodname >}} issue and the Jira ticket. You can access this case from the issue panel, to find the {{< prodname >}}Case Management{{< /prodname >}} project in which it was created. In Case Management settings, make sure that the Jira integration is enabled for this project, and the correct Jira account and board are configured. {{< img src="error_tracking/enable-jira-for-case-management-project.png" alt="Enable Jira for your Case Management project" style="width:100%;" >}} -3. In Case Management settings, make sure that sync between Case Management and Jira is enabled for this project. Check that the fields you want to sync are configured for two-way sync between Datadog and Jira. +3. In Case Management settings, make sure that sync between {{< prodname >}}Case Management{{< /prodname >}} and Jira is enabled for this project. Check that the fields you want to sync are configured for two-way sync between Datadog and Jira. {{< img src="error_tracking/sync-data-between-case-management-and-jira.png" alt="Sync data between Case Management and Jira" style="width:100%;" >}} @@ -170,11 +170,11 @@ If you experience syncing issues between your Jira tickets and the corresponding ### Reporter on Jira tickets is the wrong user -When a Jira ticket is created from an Error Tracking issue, the ticket's {{< ui >}}Reporter{{< /ui >}} field is set to the Datadog user who configured the Jira integration, not to the user who triggered the ticket creation. This is a known limitation of the Jira integration for Datadog and applies to every ticket created from Error Tracking. To change the Reporter on a specific ticket, update it directly in Jira after creation. +When a Jira ticket is created from an {{< prodname >}}Error Tracking{{< /prodname >}} issue, the ticket's {{< ui >}}Reporter{{< /ui >}} field is set to the Datadog user who configured the Jira integration, not to the user who triggered the ticket creation. This is a known limitation of the Jira integration for Datadog and applies to every ticket created from {{< prodname >}}Error Tracking{{< /prodname >}}. To change the Reporter on a specific ticket, update it directly in Jira after creation. ### A new Case Management project is created for each Jira ticket -Datadog Case Management maps each Jira issue type to a different Case Management project. When you create a ticket from an Error Tracking issue using a Jira issue type that has not been used before, a new Case Management project is automatically created to link the Error Tracking issue and the Jira ticket. This behavior means that creating tickets with several Jira issue types over time produces several Case Management projects, one per issue type. +Datadog Case Management maps each Jira issue type to a different {{< prodname >}}Case Management{{< /prodname >}} project. When you create a ticket from an {{< prodname >}}Error Tracking{{< /prodname >}} issue using a Jira issue type that has not been used before, a new {{< prodname >}}Case Management{{< /prodname >}} project is automatically created to link the {{< prodname >}}Error Tracking{{< /prodname >}} issue and the Jira ticket. This behavior means that creating tickets with several Jira issue types over time produces several {{< prodname >}}Case Management{{< /prodname >}} projects, one per issue type. ## Further reading diff --git a/hugo/content/en/error_tracking/ticketing_systems/linear.md b/hugo/content/en/error_tracking/ticketing_systems/linear.md index aed5955d1bf..17826a2d5e1 100644 --- a/hugo/content/en/error_tracking/ticketing_systems/linear.md +++ b/hugo/content/en/error_tracking/ticketing_systems/linear.md @@ -17,10 +17,10 @@ further_reading: ## Overview -Integrate Linear with Error Tracking to create and link Linear issues to Error Tracking issues. With this integration, you can: +Integrate Linear with {{< prodname >}}Error Tracking{{< /prodname >}} to create and link Linear issues to {{< prodname >}}Error Tracking{{< /prodname >}} issues. With this integration, you can: -- Create Linear issues directly from the Error Tracking issue panel -- Group multiple Error Tracking issues into a single Linear issue +- Create Linear issues directly from the {{< prodname >}}Error Tracking{{< /prodname >}} issue panel +- Group multiple {{< prodname >}}Error Tracking{{< /prodname >}} issues into a single Linear issue ## Prerequisites @@ -45,41 +45,41 @@ Create a Linear issue directly from the issue panel to group investigation effor {{< img src="error_tracking/create-linear-issue.png" alt="Create a Linear issue from an Error Tracking issue" style="width:100%;" >}} -After the Linear issue is created, it is linked to the Error Tracking issue and appears in the issue panel. The Error Tracking issue status automatically changes to **REVIEWED**. +After the Linear issue is created, it is linked to the {{< prodname >}}Error Tracking{{< /prodname >}} issue and appears in the issue panel. The Error Tracking issue status automatically changes to **REVIEWED**. -When an Error Tracking issue is linked to a Linear issue, the state, assignee, and comments are two-way synced. For details, see [State two-way sync between Error Tracking issues and Linear issues](#state-two-way-sync-between-error-tracking-issues-and-linear-issues). +When an {{< prodname >}}Error Tracking{{< /prodname >}} issue is linked to a Linear issue, the state, assignee, and comments are two-way synced. For details, see [State two-way sync between Error Tracking issues and Linear issues](#state-two-way-sync-between-error-tracking-issues-and-linear-issues). ## Group multiple Error Tracking issues into a single Linear issue -Attach multiple Error Tracking issues to a single Linear issue to group correlated issues into a single unit of work: +Attach multiple {{< prodname >}}Error Tracking{{< /prodname >}} issues to a single Linear issue to group correlated issues into a single unit of work: 1. Navigate to the [Error Tracking Explorer][2]. 2. Click on an issue to open the issue panel. 3. In the issue panel, in the **Actions** dropdown, click **Add Linear issue**. -4. In the **Add to Existing** tab, paste the URL of the Linear issue in which you want to group your Error Tracking issues. +4. In the **Add to Existing** tab, paste the URL of the Linear issue in which you want to group your {{< prodname >}}Error Tracking{{< /prodname >}} issues. 5. Optionally, open Data Sync settings to configure how data syncs between Datadog and Linear. -6. Click **Link to Issue** to attach the Error Tracking issue to the Linear issue. -7. Repeat these actions on all the Error Tracking issues you want to add to this group. +6. Click **Link to Issue** to attach the {{< prodname >}}Error Tracking{{< /prodname >}} issue to the Linear issue. +7. Repeat these actions on all the {{< prodname >}}Error Tracking{{< /prodname >}} issues you want to add to this group. {{< img src="error_tracking/add-to-existing-linear-issue.png" alt="Add an Error Tracking issue to an existing Linear issue" style="height:300px;" >}} -When several Error Tracking issues are linked to a single Linear issue, the state, assignee, and comments are two-way synced. For details, see [State two-way sync between Error Tracking issues and Linear issues](#state-two-way-sync-between-error-tracking-issues-and-linear-issues). +When several {{< prodname >}}Error Tracking{{< /prodname >}} issues are linked to a single Linear issue, the state, assignee, and comments are two-way synced. For details, see [State two-way sync between Error Tracking issues and Linear issues](#state-two-way-sync-between-error-tracking-issues-and-linear-issues). -The relationship between Linear issues and Error Tracking issues is a 1:N relationship. A single Linear issue can be linked to multiple Error Tracking issues, but an Error Tracking issue can be linked to only one Linear issue. +The relationship between Linear issues and {{< prodname >}}Error Tracking{{< /prodname >}} issues is a 1:N relationship. A single Linear issue can be linked to multiple {{< prodname >}}Error Tracking{{< /prodname >}} issues, but an {{< prodname >}}Error Tracking{{< /prodname >}} issue can be linked to only one Linear issue. ## State two-way sync between Error Tracking issues and Linear issues -If two-way sync is enabled and configured between Datadog and Linear teams, the states of Error Tracking issues and Linear issues are mirrored. If you encounter unexpected behavior, see the [Troubleshooting](#troubleshooting) section for how to fix your configuration. +If two-way sync is enabled and configured between Datadog and Linear teams, the states of {{< prodname >}}Error Tracking{{< /prodname >}} issues and Linear issues are mirrored. If you encounter unexpected behavior, see the [Troubleshooting](#troubleshooting) section for how to fix your configuration. ### Single Error Tracking issue linked to single Linear issue -When a single Error Tracking issue is linked to a Linear issue, their states are two-way synced. The mapping between these states can be configured in the Data Sync settings of the Linear issue creation form: +When a single {{< prodname >}}Error Tracking{{< /prodname >}} issue is linked to a Linear issue, their states are two-way synced. The mapping between these states can be configured in the Data Sync settings of the Linear issue creation form: {{< img src="error_tracking/linear-status-mapping.png" alt="Map Error Tracking issue states to Linear issue states" style="width:100%;" >}} ### Multiple Error Tracking issues linked to single Linear issue -When multiple Error Tracking issues are linked to the same Linear issue, their states sync depending on the action you take. If you update the status of the Linear issue, all linked Error Tracking issues are updated to mirror this state according to your mapping. +When multiple {{< prodname >}}Error Tracking{{< /prodname >}} issues are linked to the same Linear issue, their states sync depending on the action you take. If you update the status of the Linear issue, all linked {{< prodname >}}Error Tracking{{< /prodname >}} issues are updated to mirror this state according to your mapping. Assuming that your mapping is defined as follows: @@ -89,7 +89,7 @@ Assuming that your mapping is defined as follows: | `In Progress` | `In Progress` | | `Closed` | `Done` | -If you update the state of an Error Tracking issue, the resulting state of other linked Error Tracking issues and the Linear issue follows these rules: +If you update the state of an {{< prodname >}}Error Tracking{{< /prodname >}} issue, the resulting state of other linked {{< prodname >}}Error Tracking{{< /prodname >}} issues and the Linear issue follows these rules: | Initial state | Action | Resulting state | |--------------------------------------------------------------------------------|-----------------------------------------------------------------|-------------------------------------------------------------------------------------------------------| @@ -100,23 +100,23 @@ If you update the state of an Error Tracking issue, the resulting state of other ## Troubleshooting -If you experience unexpected behaviors using ticketing systems with Error Tracking, see the following troubleshooting steps. If you continue to have trouble, reach out to [Datadog support][5]. +If you experience unexpected behaviors using ticketing systems with {{< prodname >}}Error Tracking{{< /prodname >}}, see the following troubleshooting steps. If you continue to have trouble, reach out to [Datadog support][5]. ### Sync is broken between Linear and Error Tracking -If you experience syncing issues between your Linear issues and the corresponding Error Tracking issues (such as the Error Tracking issue state not being updated when you close the Linear issue), verify that the following steps are all properly configured: +If you experience syncing issues between your Linear issues and the corresponding {{< prodname >}}Error Tracking{{< /prodname >}} issues (such as the {{< prodname >}}Error Tracking{{< /prodname >}} issue state not being updated when you close the Linear issue), verify that the following steps are all properly configured: -1. In the issue panel, make sure that the Error Tracking issue is correctly linked to the Linear issue. -2. Verify that Case Management is correctly configured to sync with Linear. +1. In the issue panel, make sure that the {{< prodname >}}Error Tracking{{< /prodname >}} issue is correctly linked to the Linear issue. +2. Verify that {{< prodname >}}Case Management{{< /prodname >}} is correctly configured to sync with Linear. - Datadog automatically creates a Case Management case to link Error Tracking issues and Linear issues. To check the configuration: - - From the issue panel, open the linked Case Management case to find its project. + Datadog automatically creates a {{< prodname >}}Case Management{{< /prodname >}} case to link {{< prodname >}}Error Tracking{{< /prodname >}} issues and Linear issues. To check the configuration: + - From the issue panel, open the linked {{< prodname >}}Case Management{{< /prodname >}} case to find its project. - In Case Management settings, verify that the Linear integration is enabled for this project. - Verify that the correct Linear workspace and team are configured. {{< img src="error_tracking/enable-linear-for-case-management-project.png" alt="Enable Linear for your Case Management project" style="width:100%;" >}} -3. In Case Management settings, make sure that sync between Case Management and Linear is enabled for this project. Check that the fields you want to sync are configured for two-way sync between Datadog and Linear. +3. In Case Management settings, make sure that sync between {{< prodname >}}Case Management{{< /prodname >}} and Linear is enabled for this project. Check that the fields you want to sync are configured for two-way sync between Datadog and Linear. {{< img src="error_tracking/sync-data-between-case-management-and-linear.png" alt="Sync data between Case Management and Linear" style="width:100%;" >}} diff --git a/hugo/content/en/error_tracking/troubleshooting.md b/hugo/content/en/error_tracking/troubleshooting.md index 758d7d18060..0464001ef45 100644 --- a/hugo/content/en/error_tracking/troubleshooting.md +++ b/hugo/content/en/error_tracking/troubleshooting.md @@ -2,7 +2,7 @@ title: Error Tracking Troubleshooting --- -If you experience unexpected behavior with Error Tracking, the troubleshooting steps below can help you resolve the issue quickly. If you continue to have trouble, reach out to [Datadog support][1]. +If you experience unexpected behavior with {{< prodname >}}Error Tracking{{< /prodname >}}, the troubleshooting steps below can help you resolve the issue quickly. If you continue to have trouble, reach out to [Datadog support][1]. Datadog recommends regularly updating to the latest version of Datadog SDKs, as each release contains improvements and fixes. @@ -10,13 +10,13 @@ Datadog recommends regularly updating to the latest version of Datadog SDKs, as ### Logs -Make sure the error message has the [required attributes][2], and Error Tracking for Logs is [activated][7]. +Make sure the error message has the [required attributes][2], and {{< prodname >}}Error Tracking{{< /prodname >}} for Logs is [activated][7]. -This [example query][3] searches for logs meeting the criteria for inclusion in Error Tracking. +This [example query][3] searches for logs meeting the criteria for inclusion in {{< prodname >}}Error Tracking{{< /prodname >}}. ### APM -To be processed by Error Tracking, a span must have these attributes: +To be processed by {{< prodname >}}Error Tracking{{< /prodname >}}, a span must have these attributes: - `error.type` - `error.message` @@ -26,13 +26,13 @@ To be processed by Error Tracking, a span must have these attributes: Note: The stack must have at least two lines and one meaningful frame (a frame with a function name and a filename in most languages).
-This [example query][5] searches for spans meeting the criteria for inclusion in Error Tracking. +This [example query][5] searches for spans meeting the criteria for inclusion in {{< prodname >}}Error Tracking{{< /prodname >}}. ### RUM -Error Tracking only processes errors that are sent with the source set to `custom`, `source`, `report`, or `console`, and contain a stack trace. Errors sent with any other source (such as `network`) or sent from browser extensions are not processed by Error Tracking. +{{< prodname >}}Error Tracking{{< /prodname >}} only processes errors that are sent with the source set to `custom`, `source`, `report`, or `console`, and contain a stack trace. Errors sent with any other source (such as `network`) or sent from browser extensions are not processed by {{< prodname >}}Error Tracking{{< /prodname >}}. -This [example query][6] shows RUM errors that meet the criteria for inclusion in Error Tracking. +This [example query][6] shows RUM errors that meet the criteria for inclusion in {{< prodname >}}Error Tracking{{< /prodname >}}. ### Inclusion/Exclusion filters diff --git a/hugo/content/en/events/_index.md b/hugo/content/en/events/_index.md index e4b9b3542b0..976ed147439 100644 --- a/hugo/content/en/events/_index.md +++ b/hugo/content/en/events/_index.md @@ -29,11 +29,11 @@ further_reading: ## Overview -Ingest, enrich and normalize, and correlate your events from any source into actionable insights. Datadog automatically creates events from various products including monitors, Watchdog, and Error Tracking. You can also track events generated from the Agent and installed integrations. Event Management can also ingest events from any source, including alert events from third parties, change requests, deployments, configuration changes. +Ingest, enrich and normalize, and correlate your events from any source into actionable insights. Datadog automatically creates events from various products including monitors, Watchdog, and {{< prodname >}}Error Tracking{{< /prodname >}}. You can also track events generated from the Agent and installed integrations. {{< prodname >}}Event Management{{< /prodname >}} can also ingest events from any source, including alert events from third parties, change requests, deployments, configuration changes. More than 100 Datadog integrations support events collection, including [Kubernetes][1], [Docker][2], [Jenkins][3], [Chef][4], [Puppet][5], [Amazon ECS][6] or [Autoscaling][7], [Sentry][8], and [Nagios][9]. -
To open the Event Management page from Datadog's global search, press Cmd/Ctrl + K and search for event explorer.
+
To open the {{< prodname >}}Event Management{{< /prodname >}} page from Datadog's global search, press Cmd/Ctrl + K and search for event explorer.
**Update to Datadog monitor events `aggregation_key` starting March 1, 2025:** The Datadog monitor events `aggregation_key` is unique to each Monitor ID. Starting March 1st, this key will also include Monitor Group, making it unique per *Monitor ID and Monitor Group*. If you're using monitor events `aggregation_key` in dashboard queries or the Event API, you must migrate to use `@monitor.id`. Reach out to [support][10] if you have any questions. diff --git a/hugo/content/en/events/correlation/maintenance_windows.md b/hugo/content/en/events/correlation/maintenance_windows.md index 9667fc67205..94f43df0bec 100644 --- a/hugo/content/en/events/correlation/maintenance_windows.md +++ b/hugo/content/en/events/correlation/maintenance_windows.md @@ -18,7 +18,7 @@ To create a [Maintenance Window][2]: 1. Select {{< ui >}}Maintenance Windows{{< /ui >}} next to Case Attributes in the left navigation bar. 1. Click {{< ui >}}New Maintenance Window{{< /ui >}} in the top right. 1. Enter a Maintenance Window name. -1. Set conditions for the cases that should be impacted by this maintenance window using tags or attributes. By default, Event Management cases inherit tags from the alerts they correlate. +1. Set conditions for the cases that should be impacted by this maintenance window using tags or attributes. By default, {{< prodname >}}Event Management{{< /prodname >}} cases inherit tags from the alerts they correlate. 1. Select the start and end times for the Maintenance Window. 1. Review Maintenance Window details and click {{< ui >}}Save{{< /ui >}}. diff --git a/hugo/content/en/events/correlation/triage_and_notify.md b/hugo/content/en/events/correlation/triage_and_notify.md index 86d9aee42bb..028acd6bfdb 100644 --- a/hugo/content/en/events/correlation/triage_and_notify.md +++ b/hugo/content/en/events/correlation/triage_and_notify.md @@ -10,9 +10,9 @@ further_reading: {{< img src="events/correlation/triage/triage.png" alt="Case detail page with an event side panel. Investigate correlated events from a case and analyze related metrics" style="width:100%;" >}} -Event Management correlates related events and automatically consolidates them into a single case. Bring in all the context of related logs, related metrics, and alerting monitors to triage and troubleshoot issues in one place. +{{< prodname >}}Event Management{{< /prodname >}} correlates related events and automatically consolidates them into a single case. Bring in all the context of related logs, related metrics, and alerting monitors to triage and troubleshoot issues in one place. -From the [Correlation][1] page, find the pattern you want to analyze and click {{< ui >}}Triage Cases{{< /ui >}} at the end of the same row. You can also click {{< ui >}}Case Management{{< /ui >}} at the top of the page to view all cases with correlated events in [Case Management][2]. Datadog pulls in related metrics and logs so you can troubleshoot issues with all the related data in one place. +From the [Correlation][1] page, find the pattern you want to analyze and click {{< ui >}}Triage Cases{{< /ui >}} at the end of the same row. You can also click {{< ui >}}{{< prodname >}}Case Management{{< /prodname >}}{{< /ui >}} at the top of the page to view all cases with correlated events in [{{< prodname >}}Case Management{{< /prodname >}}][2]. Datadog pulls in related metrics and logs so you can troubleshoot issues with all the related data in one place. ## Event Management Case @@ -28,7 +28,7 @@ From the [Correlation][1] page, find the pattern you want to analyze and click { | Enriched Alerts | some cases will get automatically enriched with intelligent alerts that Datadog thinks are related based on your infrastructure. Enriched alert do not impact case attribute, priority, and status | -For more information on Case Management operations, see the [Case Management documentation][5]. +For more information on {{< prodname >}}Case Management{{< /prodname >}} operations, see the [Case Management documentation][5]. ### Investigation 1. From the case Overview, click {{< ui >}}Investigation{{< /ui >}} @@ -40,7 +40,7 @@ For more information on Case Management operations, see the [Case Management doc ## Create a notification or ticket -With correlated events, you can configure one notification for a group. So, instead of having 20 notifications and 20 potential issues to investigate, you have one single case and one notification. Combine all your alerts in the Case Management Projects page. There are a few ways to group notifications in Case Management: +With correlated events, you can configure one notification for a group. So, instead of having 20 notifications and 20 potential issues to investigate, you have one single case and one notification. Combine all your alerts in the Case Management Projects page. There are a few ways to group notifications in {{< prodname >}}Case Management{{< /prodname >}}: ### Ticketing diff --git a/hugo/content/en/events/guides/migrating_to_new_events_features.md b/hugo/content/en/events/guides/migrating_to_new_events_features.md index 7fab663ca49..395b31d21d0 100644 --- a/hugo/content/en/events/guides/migrating_to_new_events_features.md +++ b/hugo/content/en/events/guides/migrating_to_new_events_features.md @@ -14,7 +14,7 @@ Datadog's legacy event stream and event monitors retire on June 30, 2022 ## Why change Events features? -Launched more than 10 years ago, Datadog's event stream is one of its earliest features. The new events experience includes many new features that allow you to get even more value from your events. These include event analytics, the ability to generate metrics from your events, the ability to create pipelines to post-process events, and a much friendlier and more intuitive query syntax that is better aligned with other Datadog products, such as Log Management and APM. +Launched more than 10 years ago, Datadog's event stream is one of its earliest features. The new events experience includes many new features that allow you to get even more value from your events. These include event analytics, the ability to generate metrics from your events, the ability to create pipelines to post-process events, and a much friendlier and more intuitive query syntax that is better aligned with other Datadog products, such as {{< prodname >}}Log Management{{< /prodname >}} and APM. ## What is the migration timeline? diff --git a/hugo/content/en/events/triage_inbox.md b/hugo/content/en/events/triage_inbox.md index eaea49df297..1c96d47d6ee 100644 --- a/hugo/content/en/events/triage_inbox.md +++ b/hugo/content/en/events/triage_inbox.md @@ -44,7 +44,7 @@ On the right hand split-view side panel, you can perform the following: - {{< ui >}}Tag and comment{{< /ui >}}: Collaborate with teammates in the case timeline by tagging users and adding notes. - {{< ui >}}Send notifications{{< /ui >}}: Alert stakeholders with Slack, Microsoft Teams, email, or webhooks. -- {{< ui >}}Escalate issues{{< /ui >}}: Trigger an incident or page an on-call responder using [Incident Management][1], [On-Call][2], [Workflow Automation][3], or third-party tools. +- {{< ui >}}Escalate issues{{< /ui >}}: Trigger an incident or page an on-call responder using [{{< prodname >}}Incident Management{{< /prodname >}}][1], [{{< prodname >}}On-Call{{< /prodname >}}][2], [{{< prodname >}}Workflow Automation{{< /prodname >}}][3], or third-party tools. - {{< ui >}}Sync with external tools{{< /ui >}}: Keep Jira and ServiceNow records in sync to ensure external stakeholders stay up to date. {{< img src="/events/triage_inbox/event_mgmt_inbox_right_hand_panel.png" alt="Event Management Inbox right hand panel, highlighting Escalate drop down" style="width:100%;" >}} diff --git a/hugo/content/en/experiments/_index.md b/hugo/content/en/experiments/_index.md index 1810f45f89d..2a9c9b02a54 100644 --- a/hugo/content/en/experiments/_index.md +++ b/hugo/content/en/experiments/_index.md @@ -52,7 +52,7 @@ When you [plan and launch an experiment][16], link it to a feature flag to defin If you randomize subjects outside Datadog—for example, with an in-house system—use [Exposure SQL Models][17] to tell Datadog who was exposed to each experiment and when. Exposure SQL Models query exposure records from your [connected warehouse][13] and map them to Datadog fields such as subject key, timestamp, experiment ID, and variant ID. -Datadog deduplicates exposure data automatically: if a user appears in multiple variants for the same experiment, that user is excluded from the analysis. When exposures come from your warehouse instead of Feature Flags, metrics built on Datadog SDK events are not supported—you need [warehouse-native metrics][14]. +Datadog deduplicates exposure data automatically: if a user appears in multiple variants for the same experiment, that user is excluded from the analysis. When exposures come from your warehouse instead of {{< prodname >}}Feature Flags{{< /prodname >}}, metrics built on Datadog SDK events are not supported—you need [warehouse-native metrics][14]. ## Metrics @@ -66,9 +66,9 @@ Warehouse mode is required when you use [Exposure SQL Models][17] for randomizat ### Product Analytics and RUM -For client-side experiments, build metrics from events collected by the [Real User Monitoring (RUM)][2] and [Product Analytics][3] SDKs. Define metrics from actions, views, sessions, and other event types, then choose an aggregation method such as count of events, count of unique users, or sum of a property. +For client-side experiments, build metrics from events collected by the [Real User Monitoring (RUM)][2] and [{{< prodname >}}Product Analytics{{< /prodname >}}][3] SDKs. Define metrics from actions, views, sessions, and other event types, then choose an aggregation method such as count of events, count of unique users, or sum of a property. -This path works when randomization runs through [Datadog Feature Flags][1] and you want to measure user behavior, funnel conversion, or application performance without querying a warehouse. Product Analytics and RUM metrics are available in near real time as experiments launch. +This path works when randomization runs through [Datadog Feature Flags][1] and you want to measure user behavior, funnel conversion, or application performance without querying a warehouse. {{< prodname >}}Product Analytics{{< /prodname >}} and RUM metrics are available in near real time as experiments launch. ## Statistics diff --git a/hugo/content/en/experiments/concepts/subject_types.md b/hugo/content/en/experiments/concepts/subject_types.md index 55c2d651206..5ee951b051e 100644 --- a/hugo/content/en/experiments/concepts/subject_types.md +++ b/hugo/content/en/experiments/concepts/subject_types.md @@ -81,7 +81,7 @@ LEFT JOIN measures ### Product Analytics and RUM metrics -Each subject type has an associated **attribute**. Datadog uses this attribute to associate Product Analytics and Real User Monitoring (RUM) data with experiment exposures. The attribute value must match the identifier you pass as `targetingKey`. +Each subject type has an associated **attribute**. Datadog uses this attribute to associate {{< prodname >}}Product Analytics{{< /prodname >}} and Real User Monitoring (RUM) data with experiment exposures. The attribute value must match the identifier you pass as `targetingKey`. For example: @@ -99,7 +99,7 @@ datadogRum.setUser({ }); ``` -When Datadog computes experiment results, it joins experiment exposures to Product Analytics and RUM events on the subject type attribute. By default, the analysis includes events that occur between a subject's first exposure and the end of the experiment. Datadog aggregates those events using the metric definition you configured (for example, count or sum), then runs a [statistical analysis][3] for the experiment. +When Datadog computes experiment results, it joins experiment exposures to {{< prodname >}}Product Analytics{{< /prodname >}} and RUM events on the subject type attribute. By default, the analysis includes events that occur between a subject's first exposure and the end of the experiment. Datadog aggregates those events using the metric definition you configured (for example, count or sum), then runs a [statistical analysis][3] for the experiment. ## Further reading diff --git a/hugo/content/en/experiments/defining_metrics/_index.md b/hugo/content/en/experiments/defining_metrics/_index.md index 7894787e4ec..ace281713b9 100644 --- a/hugo/content/en/experiments/defining_metrics/_index.md +++ b/hugo/content/en/experiments/defining_metrics/_index.md @@ -11,9 +11,9 @@ further_reading: ## Overview -Create the metrics you want to measure in your experiments. You can use data from Real User Monitoring (RUM), Product Analytics, or your own warehouse to create Datadog Experiments metrics. +Create the metrics you want to measure in your experiments. You can use data from Real User Monitoring (RUM), {{< prodname >}}Product Analytics{{< /prodname >}}, or your own warehouse to create Datadog Experiments metrics. -
If your organization uses custom roles, you must have the appropriate Product Analytics permissions to create experiment metrics.
+
If your organization uses custom roles, you must have the appropriate {{< prodname >}}Product Analytics{{< /prodname >}} permissions to create experiment metrics.
## Create a metric @@ -24,14 +24,14 @@ Select your data source: ### Prerequisites -To create a metric from Product Analytics or RUM data, you must have Datadog's [client-side SDK][3] installed in your application and be actively capturing data. If you have not yet configured your SDK, select your application type to get started: +To create a metric from {{< prodname >}}Product Analytics{{< /prodname >}} or RUM data, you must have Datadog's [client-side SDK][3] installed in your application and be actively capturing data. If you have not yet configured your SDK, select your application type to get started: - [Android and Android TV][4] - [iOS and tvOS][5] - [Browser (JavaScript)][6] - [React Native][7] -Product Analytics uses the same SDKs and configuration as Real User Monitoring (RUM). After you configure your SDK using the RUM setup documentation, create your metric in the Product Analytics UI. +{{< prodname >}}Product Analytics{{< /prodname >}} uses the same SDKs and configuration as Real User Monitoring (RUM). After you configure your SDK using the RUM setup documentation, create your metric in the Product Analytics UI. ### Create a metric using Product Analytics or RUM data diff --git a/hugo/content/en/experiments/defining_metrics/metric_sync.md b/hugo/content/en/experiments/defining_metrics/metric_sync.md index d7168c5bf21..23a0ae3d7a9 100644 --- a/hugo/content/en/experiments/defining_metrics/metric_sync.md +++ b/hugo/content/en/experiments/defining_metrics/metric_sync.md @@ -30,7 +30,7 @@ Metric Sync supports a plan-and-apply workflow. The `plan` command validates you Before using Metric Sync, you need: -- A Datadog account with Product Analytics and Experiments enabled. +- A Datadog account with {{< prodname >}}Product Analytics{{< /prodname >}} and Experiments enabled. - A connected warehouse. See [Connect a data warehouse][1]. - The Product Analytics permissions required to create and update experiment metrics. Synced metrics are certified by default, so custom roles also need the Product Analytics Certified Metrics Write permission. See [Product Analytics permissions][2]. - A Datadog API key and application key for CI authentication. See [API and application keys][3]. diff --git a/hugo/content/en/experiments/diagnostics.md b/hugo/content/en/experiments/diagnostics.md index d9fe014ead9..ce1d6ce7710 100644 --- a/hugo/content/en/experiments/diagnostics.md +++ b/hugo/content/en/experiments/diagnostics.md @@ -121,7 +121,7 @@ This diagnostic does not necessarily mean that the source event never fired. Eve 1. Open the metric and confirm that the event name, aggregation, filters, and data source are correct. Check the metric event volume chart for recent matching data. 2. Compare an assigned subject's identifier with the identifier on its metric events. Confirm that the configured subject type attribute or mapped warehouse column contains the same value as the SDK `targetingKey` or the assignment subject column configured in the Exposure SQL Model. 3. Confirm that metric events occur after the subject's first assignment and within the experiment analysis window. -4. For an experiment backed by Datadog Feature Flags, if [Source Code Integration][6] is configured, click [{{< ui >}}Ask Bits{{< /ui >}}][7] for a **Missing metric data** failure on the primary metric. Bits can inspect the source locations where the feature flag is evaluated and help you check nearby metric instrumentation. An empty code search is inconclusive and does not prove that the SDK or flag is missing from the application. +4. For an experiment backed by Datadog Feature Flags, if [{{< prodname >}}Source Code Integration{{< /prodname >}}][6] is configured, click [{{< ui >}}Ask Bits{{< /ui >}}][7] for a **Missing metric data** failure on the primary metric. Bits can inspect the source locations where the feature flag is evaluated and help you check nearby metric instrumentation. An empty code search is inconclusive and does not prove that the SDK or flag is missing from the application. 5. For warehouse metrics, run the Metric SQL Model or query its source table directly. 6. Fix the metric definition, identity mapping, event timing, or instrumentation issue, then rerun experiment analysis. @@ -190,7 +190,7 @@ Datadog applies a Bonferroni correction by dividing the family significance leve ## Analysis pipeline failure -Experiment analysis can use Product Analytics and RUM data in Datadog or warehouse native mode. **Analysis pipeline failure** applies only to experiments that use warehouse metrics. Datadog reports this diagnostic when a customer warehouse query fails, so current warehouse results cannot be computed. Datadog does not report internal Product Analytics or RUM analysis failures with this diagnostic. +Experiment analysis can use {{< prodname >}}Product Analytics{{< /prodname >}} and RUM data in Datadog or warehouse native mode. **Analysis pipeline failure** applies only to experiments that use warehouse metrics. Datadog reports this diagnostic when a customer warehouse query fails, so current warehouse results cannot be computed. Datadog does not report internal {{< prodname >}}Product Analytics{{< /prodname >}} or RUM analysis failures with this diagnostic. The SQL you define depends on how the experiment is randomized. For experiments backed by Datadog Feature Flags, Datadog synchronizes assignments to the `g_exposures` table, and you define Metric SQL Models. For warehouse-native experiments, you define both the Exposure SQL Model and Metric SQL Models. Datadog generates the remaining pipeline SQL. diff --git a/hugo/content/en/experiments/mcp_tools.md b/hugo/content/en/experiments/mcp_tools.md index 2648739cf89..d7ebc36ca5e 100644 --- a/hugo/content/en/experiments/mcp_tools.md +++ b/hugo/content/en/experiments/mcp_tools.md @@ -23,7 +23,7 @@ algolia: ## Overview -The [Datadog MCP Server][1] lets AI agents interact with your experiment data through the [Model Context Protocol (MCP)][2]. The `experiments` toolset gives AI clients like Cursor, Claude Code, OpenAI Codex, and [Bits AI][6] structured access to your experiments, metrics, and diagnostic data. +The [{{< prodname >}}Datadog MCP Server{{< /prodname >}}][1] lets AI agents interact with your experiment data through the [Model Context Protocol (MCP)][2]. The `experiments` toolset gives AI clients like Cursor, Claude Code, OpenAI Codex, and [Bits AI][6] structured access to your experiments, metrics, and diagnostic data. The toolset becomes most powerful when your AI client can also read your codebase—combining live experiment state with how the associated feature flag is installed in your code. @@ -49,7 +49,7 @@ For metric movements, `get_metric_definition` returns the underlying event query ## Setup -The `experiments` toolset is not enabled by default. To enable it, add `experiments` to the `toolsets` parameter when connecting to the Datadog MCP Server. See [Set Up the Datadog MCP Server][3] for connection instructions and toolset configuration. +The `experiments` toolset is not enabled by default. To enable it, add `experiments` to the `toolsets` parameter when connecting to the {{< prodname >}}Datadog MCP Server{{< /prodname >}}. See [Set Up the Datadog MCP Server][3] for connection instructions and toolset configuration. For feature flag management tools used alongside experiments—creating flags, syncing allocations, checking canary results—see [Feature Flags MCP Tools][4]. diff --git a/hugo/content/en/experiments/metric_property_breakouts.md b/hugo/content/en/experiments/metric_property_breakouts.md index ba068bb0da4..7c47d1a9510 100644 --- a/hugo/content/en/experiments/metric_property_breakouts.md +++ b/hugo/content/en/experiments/metric_property_breakouts.md @@ -25,7 +25,7 @@ A breakout is purely additive: the overall metric is still calculated across all ## Configure breakouts on a metric -You define breakouts when you [create or edit a metric][1]. Breakouts are supported for metrics built on Product Analytics, Real User Monitoring (RUM), and [warehouse][2] data. +You define breakouts when you [create or edit a metric][1]. Breakouts are supported for metrics built on {{< prodname >}}Product Analytics{{< /prodname >}}, Real User Monitoring (RUM), and [warehouse][2] data. 1. Navigate to the [Metrics page][3] in Datadog Product Analytics and create a metric or open an existing one. 1. Configure the [metric definition][1]. diff --git a/hugo/content/en/experiments/plan_and_launch_experiments.md b/hugo/content/en/experiments/plan_and_launch_experiments.md index 0c2831b2679..423d7ec0e00 100644 --- a/hugo/content/en/experiments/plan_and_launch_experiments.md +++ b/hugo/content/en/experiments/plan_and_launch_experiments.md @@ -18,7 +18,7 @@ Plan and launch [experiments][8] to measure how new features affect business out ## Prerequisites -
You must have the appropriate Product Analytics and Feature Flags permissions to create and launch experiments.
+
You must have the appropriate {{< prodname >}}Product Analytics{{< /prodname >}} and {{< prodname >}}Feature Flags{{< /prodname >}} permissions to create and launch experiments.
Before you begin, make sure you have: diff --git a/hugo/content/en/experiments/reading_results.md b/hugo/content/en/experiments/reading_results.md index e543e6f8c7a..ddf6f25c48e 100644 --- a/hugo/content/en/experiments/reading_results.md +++ b/hugo/content/en/experiments/reading_results.md @@ -109,7 +109,7 @@ For [warehouse-native metrics][3], click {{< ui >}}Copy SQL{{< /ui >}} to copy a ### Replays -For metrics built on [RUM][4] or [Product Analytics][5] data, click {{< ui >}}Replays{{< /ui >}} to watch [session replays][6] for users enrolled in the experiment. Review how subjects in each variant experienced the product. +For metrics built on [RUM][4] or [{{< prodname >}}Product Analytics{{< /prodname >}}][5] data, click {{< ui >}}Replays{{< /ui >}} to watch [session replays][6] for users enrolled in the experiment. Review how subjects in each variant experienced the product. ## Further reading {{< partial name="whats-next/whats-next.html" >}} diff --git a/hugo/content/en/experiments/troubleshooting.md b/hugo/content/en/experiments/troubleshooting.md index 6b88adba538..129415e1b9a 100644 --- a/hugo/content/en/experiments/troubleshooting.md +++ b/hugo/content/en/experiments/troubleshooting.md @@ -42,7 +42,7 @@ Verify that your feature flag is enabled and evaluates in the correct environmen {{< img src="/product_analytics/experiment/troubleshooting_flag_link1.png" alt="An experiment page showing a tooltip on the feature flag with the environment (dev, enabled) and a Go to Flag link highlighted." style="width:90%;" >}} -1. On the {{< ui >}}Feature Flags{{< /ui >}} page, select the correct environment tab and confirm that the flag is {{< ui >}}Enabled{{< /ui >}}. If the flag is disabled, enable it before proceeding. +1. On the {{< ui >}}{{< prodname >}}Feature Flags{{< /prodname >}}{{< /ui >}} page, select the correct environment tab and confirm that the flag is {{< ui >}}Enabled{{< /ui >}}. If the flag is disabled, enable it before proceeding. {{< img src="/product_analytics/experiment/troubleshooting_feature_flag_page.png" alt="The Feature Flags page with the Enabled toggle highlighted in the Targeting rules and rollouts section." style="width:90%;" >}} diff --git a/hugo/content/en/extend/guide/dogshell.md b/hugo/content/en/extend/guide/dogshell.md index b0791ca2443..114ac22a5c8 100644 --- a/hugo/content/en/extend/guide/dogshell.md +++ b/hugo/content/en/extend/guide/dogshell.md @@ -7,7 +7,7 @@ aliases: - /developers/guide/dogshell/ --- -
Dogshell is deprecated and has been replaced by Pup CLI, a comprehensive, AI-agent-ready CLI for interacting with Datadog APIs.
+
Dogshell is deprecated and has been replaced by {{< prodname >}}Pup CLI{{< /prodname >}}, a comprehensive, AI-agent-ready CLI for interacting with Datadog APIs.
You can use the Datadog API on the command line using a wrapper called Dogshell. diff --git a/hugo/content/en/extend/integrations/create-a-cloud-siem-detection-rule.md b/hugo/content/en/extend/integrations/create-a-cloud-siem-detection-rule.md index cf6d00217f3..a798e55df38 100644 --- a/hugo/content/en/extend/integrations/create-a-cloud-siem-detection-rule.md +++ b/hugo/content/en/extend/integrations/create-a-cloud-siem-detection-rule.md @@ -12,7 +12,7 @@ further_reading: ## Overview -This guide provides steps for creating a Cloud SIEM detection rule and outlines best practices for rule configuration. +This guide provides steps for creating a {{< prodname >}}Cloud SIEM{{< /prodname >}} detection rule and outlines best practices for rule configuration. [Datadog Cloud SIEM (Security Information and Event Management)][1] unifies developer, operation, and security teams through one platform. Datadog provides a set of out-of-the-box detection rules for many features and integrations. View these rules in your [SIEM Detection Rules list][2]. @@ -39,7 +39,7 @@ Within your integration in the Integration Developer Platform, navigate to the C ## Verify your detection rule in production -To see the out-of-the-box detection rule, the relevant integration tile must be `Installed` in Datadog, and Cloud SIEM must be enabled. +To see the out-of-the-box detection rule, the relevant integration tile must be `Installed` in Datadog, and {{< prodname >}}Cloud SIEM{{< /prodname >}} must be enabled. 1. Find your detection rule in the [Detection Rules list][2], and click to expand it. 2. Ensure that its logos render correctly. diff --git a/hugo/content/en/feature_flags/_index.md b/hugo/content/en/feature_flags/_index.md index 9956c044e5e..f9839dfb6b1 100644 --- a/hugo/content/en/feature_flags/_index.md +++ b/hugo/content/en/feature_flags/_index.md @@ -63,7 +63,7 @@ Do not put API keys in browser, mobile, or game applications. Evaluation context attributes are the flat string, number, and Boolean values that Datadog uses for targeting rules and rollout bucketing. Set a stable `targetingKey`, such as a user ID, session ID, or device ID, so percentage rollouts are consistent. -Feature Flags telemetry includes exposure events, flag evaluation metrics, and optional RUM correlation depending on the SDK and configuration. +{{< prodname >}}Feature Flags{{< /prodname >}} telemetry includes exposure events, flag evaluation metrics, and optional RUM correlation depending on the SDK and configuration. ## Further reading diff --git a/hugo/content/en/feature_flags/client/flutter.md b/hugo/content/en/feature_flags/client/flutter.md index 0e06d30b1b1..4e6d56c1bdc 100644 --- a/hugo/content/en/feature_flags/client/flutter.md +++ b/hugo/content/en/feature_flags/client/flutter.md @@ -115,9 +115,9 @@ Successful evaluations are sent through the Datadog Feature Flags telemetry pipe ## Standalone Dart setup -Use this setup when you are not using `datadog_flutter_plugin`, or when you want to manage Feature Flags independently from Flutter SDK initialization. +Use this setup when you are not using `datadog_flutter_plugin`, or when you want to manage {{< prodname >}}Feature Flags{{< /prodname >}} independently from Flutter SDK initialization. -Enable Datadog Feature Flags early in your app startup. For live Feature Flags configuration, `clientToken`, `env`, and `site` are required. To create a client token, see [Client tokens][1]. +Enable Datadog Feature Flags early in your app startup. For live {{< prodname >}}Feature Flags{{< /prodname >}} configuration, `clientToken`, `env`, and `site` are required. To create a client token, see [Client tokens][1]. {{< site-region region="gov,gov2" >}}
Dart and Flutter Feature Flags are not supported for the selected Datadog site ({{< region-param key="dd_site_name" >}}).
{{< /site-region >}} @@ -138,7 +138,7 @@ await datadogFlags.enable( ); {{< /code-block >}} -`applicationId`, `service`, and `version` are optional. When present, the SDK includes them in Feature Flags telemetry context. +`applicationId`, `service`, and `version` are optional. When present, the SDK includes them in {{< prodname >}}Feature Flags{{< /prodname >}} telemetry context. Use the `DatadogFlagsSite` value that matches your Datadog organization. diff --git a/hugo/content/en/feature_flags/client/reactnative.md b/hugo/content/en/feature_flags/client/reactnative.md index 55d9dd1d643..0d91c4fe951 100644 --- a/hugo/content/en/feature_flags/client/reactnative.md +++ b/hugo/content/en/feature_flags/client/reactnative.md @@ -68,11 +68,11 @@ buildscript { ## Initialize the SDK -The Datadog OpenFeature provider for React Native requires the core Datadog React Native SDK to be initialized first, followed by enabling the Feature Flags feature. To create a client token, see [Client tokens][2]. +The Datadog OpenFeature provider for React Native requires the core Datadog React Native SDK to be initialized first, followed by enabling the {{< prodname >}}Feature Flags{{< /prodname >}} feature. To create a client token, see [Client tokens][2]. ### Option 1: Using DatadogProvider component -If you use the `DatadogProvider` component for SDK initialization, enable Feature Flags in the `onInitialized` callback: +If you use the `DatadogProvider` component for SDK initialization, enable {{< prodname >}}Feature Flags{{< /prodname >}} in the `onInitialized` callback: ```tsx import { DatadogProvider, DatadogProviderConfiguration, DdFlags } from '@datadog/mobile-react-native'; @@ -113,7 +113,7 @@ export default function App() { ### Option 2: Using imperative initialization -If you initialize the SDK imperatively, enable Feature Flags after initialization completes: +If you initialize the SDK imperatively, enable {{< prodname >}}Feature Flags{{< /prodname >}} after initialization completes: ```tsx import { DdSdkReactNative, DdFlags, CoreConfiguration } from '@datadog/mobile-react-native'; @@ -394,7 +394,7 @@ function onUserLogin(user) { ## Configure Feature Flags options -Pass configuration options to `DdFlags.enable()` to customize Feature Flags behavior: +Pass configuration options to `DdFlags.enable()` to customize {{< prodname >}}Feature Flags{{< /prodname >}} behavior: {{< code-block lang="tsx" >}} await DdFlags.enable({ @@ -517,7 +517,7 @@ end ### Feature Flags not initialized error -If you see an error about Feature Flags not being initialized, verify the initialization order: +If you see an error about {{< prodname >}}Feature Flags{{< /prodname >}} not being initialized, verify the initialization order: 1. Initialize the core Datadog React Native SDK first (`DdSdkReactNative.initialize()` or `DatadogProvider`). 2. Call `DdFlags.enable()` after SDK initialization. diff --git a/hugo/content/en/feature_flags/concepts/approvals.md b/hugo/content/en/feature_flags/concepts/approvals.md index 4e97f2cf675..eb8545495a1 100644 --- a/hugo/content/en/feature_flags/concepts/approvals.md +++ b/hugo/content/en/feature_flags/concepts/approvals.md @@ -86,11 +86,11 @@ The **Feature Flag Approvals Override** organization permission serves two purpo - **Existing flags:** Required to enable approvals for a flag that already exists (in addition to [granular edit access][1] on that flag). - **Workflow bypass:** Allows holders to bypass the approvals workflow where that option is available, so changes can proceed without the usual review and approval steps. -Treat this permission as highly sensitive: assign it only to people who may need to change approval requirements or make exceptions to governance. Organization permissions are granted through [Datadog roles][4]. For related Feature Flags permissions, see [Permissions and Access Control][1]. +Treat this permission as highly sensitive: assign it only to people who may need to change approval requirements or make exceptions to governance. Organization permissions are granted through [Datadog roles][4]. For related {{< prodname >}}Feature Flags{{< /prodname >}} permissions, see [Permissions and Access Control][1]. ## Find flags with pending approvals -On the Feature Flags search page, toggle the **Pending Approvals** filter to view flags with changes awaiting approval. +On the {{< prodname >}}Feature Flags{{< /prodname >}} search page, toggle the **Pending Approvals** filter to view flags with changes awaiting approval. ## Further reading diff --git a/hugo/content/en/feature_flags/concepts/environments.md b/hugo/content/en/feature_flags/concepts/environments.md index f174ab3de56..4e0fc7c8777 100644 --- a/hugo/content/en/feature_flags/concepts/environments.md +++ b/hugo/content/en/feature_flags/concepts/environments.md @@ -19,7 +19,7 @@ Environments represent different deployment stages or modes in your software del ## Manage environments -Manage environments from **Feature Flags > Settings > Environments**: +Manage environments from **{{< prodname >}}Feature Flags{{< /prodname >}} > Settings > Environments**: {{< img src="feature_flags/concepts/environments-list-2.png" alt="Environments list in Feature Flags settings." style="width:100%;" >}} @@ -58,11 +58,11 @@ Mark an environment as **production** to indicate that changes in that environme Each environment is configured with a **name** and a set of **queries**. Queries are the `env` or `DD_ENV` strings your applications send at runtime. -Having multiple queries per environment lets you keep the `env` value consistent with the environment you pass to RUM, APM, or StatsD. For example, you might have `staging-eu` and `staging-us` as separate `env` values in your telemetry, but map both to a single **Staging** environment in Feature Flags. That way, you do not need to duplicate flag configuration across multiple Staging environments when you want to enable a flag across all of Staging. +Having multiple queries per environment lets you keep the `env` value consistent with the environment you pass to RUM, APM, or StatsD. For example, you might have `staging-eu` and `staging-us` as separate `env` values in your telemetry, but map both to a single **Staging** environment in {{< prodname >}}Feature Flags{{< /prodname >}}. That way, you do not need to duplicate flag configuration across multiple Staging environments when you want to enable a flag across all of Staging. ## Connect environments in the SDK -The `env` value you use must match a query configured for the Feature Flags environment you want, such as `staging-us` or `production`. If you already set `env` or `DD_ENV` for RUM, APM, or tracing, use the *same value* for Feature Flags. +The `env` value you use must match a query configured for the {{< prodname >}}Feature Flags{{< /prodname >}} environment you want, such as `staging-us` or `production`. If you already set `env` or `DD_ENV` for RUM, APM, or tracing, use the *same value* for {{< prodname >}}Feature Flags{{< /prodname >}}. ### Client-side applications diff --git a/hugo/content/en/feature_flags/concepts/flag_history.md b/hugo/content/en/feature_flags/concepts/flag_history.md index 36555d8ad7e..1bad0139860 100644 --- a/hugo/content/en/feature_flags/concepts/flag_history.md +++ b/hugo/content/en/feature_flags/concepts/flag_history.md @@ -27,7 +27,7 @@ When you view an individual feature flag, the {{< ui >}}Version history{{< /ui > ## Global flag history -Navigate to {{< ui >}}Feature Flags{{< /ui >}} > [{{< ui >}}Global Flag History{{< /ui >}}][1] to show all flag changes across your organization in a single view. +Navigate to {{< ui >}}{{< prodname >}}Feature Flags{{< /prodname >}}{{< /ui >}} > [{{< ui >}}Global Flag History{{< /ui >}}][1] to show all flag changes across your organization in a single view. - Use the {{< ui >}}Environment{{< /ui >}} filter to view changes in a particular environment or all environments. - Use the {{< ui >}}Feature Flag{{< /ui >}} filter to view changes for a specific flag. diff --git a/hugo/content/en/feature_flags/concepts/saved_filters.md b/hugo/content/en/feature_flags/concepts/saved_filters.md index b1b10242274..8a6271ebcca 100644 --- a/hugo/content/en/feature_flags/concepts/saved_filters.md +++ b/hugo/content/en/feature_flags/concepts/saved_filters.md @@ -34,7 +34,7 @@ Saved filters contain only attribute conditions and cannot be nested or referenc ## Create a saved filter -1. In **Feature Flags**, go to **Settings > Saved Filters** and click **New Saved Filter**. +1. In **{{< prodname >}}Feature Flags{{< /prodname >}}**, go to **Settings > Saved Filters** and click **New Saved Filter**. 2. Enter a **Name** and an optional **Description**. 3. Choose a **Filter type**: - **Saved Rule**: Build your conditions in the rule editor. Each condition uses an attribute from your SDK's [evaluation context][1], an operator, and one or more values. @@ -49,7 +49,7 @@ The saved filter is available to apply to any flag in your organization. After you create a saved filter, reference it when you configure a flag's targeting rules: -1. Navigate to **Feature Flags** and select your flag. +1. Navigate to **{{< prodname >}}Feature Flags{{< /prodname >}}** and select your flag. 2. Select the environment whose rules you want to modify. 3. Add or edit a targeting rule, then click **Add > Add Saved Filter**. 4. Select the saved filter you want to apply. diff --git a/hugo/content/en/feature_flags/concepts/scheduled_rollouts.md b/hugo/content/en/feature_flags/concepts/scheduled_rollouts.md index 55e2471aeb4..fc9785cff26 100644 --- a/hugo/content/en/feature_flags/concepts/scheduled_rollouts.md +++ b/hugo/content/en/feature_flags/concepts/scheduled_rollouts.md @@ -25,7 +25,7 @@ The flag still needs to be enabled in the environment for the rule to take effec To schedule a start time for a targeting rule: -1. Navigate to **Feature Flags** and select your flag. +1. Navigate to **{{< prodname >}}Feature Flags{{< /prodname >}}** and select your flag. 2. Select the environment whose rule you want to modify. 3. Click **Add Targeting Rule** (or click the targeting rule you want to modify). 4. Select **Schedule a start time**. diff --git a/hugo/content/en/feature_flags/concepts/targeting_attributes.md b/hugo/content/en/feature_flags/concepts/targeting_attributes.md index d30558e980e..e0670245242 100644 --- a/hugo/content/en/feature_flags/concepts/targeting_attributes.md +++ b/hugo/content/en/feature_flags/concepts/targeting_attributes.md @@ -27,7 +27,7 @@ Targeting attributes are organization-wide: after they're defined, an attribute To view and manage your organization's targeting attributes: -1. Navigate to **Feature Flags** > **Settings** > **Targeting Attributes**. +1. Navigate to **{{< prodname >}}Feature Flags{{< /prodname >}}** > **Settings** > **Targeting Attributes**. 2. Click **Create Attribute** to define a new one, or select an existing attribute to edit it. For each attribute, configure: diff --git a/hugo/content/en/feature_flags/concepts/targeting_rules.md b/hugo/content/en/feature_flags/concepts/targeting_rules.md index 1257635f00e..cc4a59b21ff 100644 --- a/hugo/content/en/feature_flags/concepts/targeting_rules.md +++ b/hugo/content/en/feature_flags/concepts/targeting_rules.md @@ -40,7 +40,7 @@ Datadog supports different targeting rule types depending on your rollout strate To configure targeting rules for a flag: -1. Navigate to **Feature Flags** and select your flag. +1. Navigate to **{{< prodname >}}Feature Flags{{< /prodname >}}** and select your flag. 2. Select the environment whose rules you want to modify. 3. Click **Add Targeting Rule** (or click the targeting rule you want to modify). diff --git a/hugo/content/en/feature_flags/feature_flag_mcp_server.md b/hugo/content/en/feature_flags/feature_flag_mcp_server.md index a14dcabe229..c8ee4aa0a1d 100644 --- a/hugo/content/en/feature_flags/feature_flag_mcp_server.md +++ b/hugo/content/en/feature_flags/feature_flag_mcp_server.md @@ -15,7 +15,7 @@ further_reading: ## Overview -The Datadog MCP Server uses the Model Context Protocol (MCP) to provide AI agents with access to [Feature Flags][1] management capabilities. These capabilities include flag creation, configuration, and React/JavaScript integration guidance. +The Datadog MCP Server uses the Model Context Protocol (MCP) to provide AI agents with access to [{{< prodname >}}Feature Flags{{< /prodname >}}][1] management capabilities. These capabilities include flag creation, configuration, and React/JavaScript integration guidance. ## Setup diff --git a/hugo/content/en/feature_flags/guide/_index.md b/hugo/content/en/feature_flags/guide/_index.md index a15ad227d79..8387dfd3081 100644 --- a/hugo/content/en/feature_flags/guide/_index.md +++ b/hugo/content/en/feature_flags/guide/_index.md @@ -11,7 +11,7 @@ cascade: --- {{< whatsnext desc="Feature Flags Guides:" >}} - {{< nextlink href="/getting_started/feature_flags" >}}Getting started with Feature Flags{{< /nextlink >}} + {{< nextlink href="/getting_started/feature_flags" >}}Getting started with {{< prodname >}}Feature Flags{{< /prodname >}}{{< /nextlink >}} {{< nextlink href="/feature_flags/guide/server_flag_evaluation_metrics" >}}Set Up Server-Side Flag Evaluation Metrics{{< /nextlink >}} {{< nextlink href="/feature_flags/guide/migrate_flags_with_cli" >}}Migrate Flags with the Flag Migration CLI{{< /nextlink >}} {{< nextlink href="/feature_flags/guide/migrate_from_launchdarkly" >}}Migrate Your Feature Flags from LaunchDarkly{{< /nextlink >}} diff --git a/hugo/content/en/feature_flags/guide/headless_cms.md b/hugo/content/en/feature_flags/guide/headless_cms.md index ea1a926075b..dbbae5c57d9 100644 --- a/hugo/content/en/feature_flags/guide/headless_cms.md +++ b/hugo/content/en/feature_flags/guide/headless_cms.md @@ -32,7 +32,7 @@ This guide explains how to use Datadog Feature Flags to run Experiments with a h ## Prerequisites -* A Datadog account with Feature Flags and Product Analytics enabled +* A Datadog account with {{< prodname >}}Feature Flags{{< /prodname >}} and {{< prodname >}}Product Analytics{{< /prodname >}} enabled * The Datadog RUM Browser SDK installed in your frontend application * A headless CMS account such as: Contentful, Builder.io, or Strapi * Node.js / React (examples below use the React SDK; vanilla JavaScript and other frameworks are also supported) @@ -124,7 +124,7 @@ export default function App() { ## Step 3: Create the feature flag in Datadog -1. Navigate to **Feature Flags** in the Datadog UI and click **\+ Create Flag**. +1. Navigate to **{{< prodname >}}Feature Flags{{< /prodname >}}** in the Datadog UI and click **\+ Create Flag**. 2. Configure the flag: * **Name**: For example, `cms_homepage_hero_variant` * **Key**: For example, `cms_homepage_hero_variant` @@ -243,7 +243,7 @@ export function HeroBanner() { ## Step 5: Track conversion events with Datadog RUM -To measure experiment results in Product Analytics, trigger RUM custom actions at key moments in the user journey. These become the metrics used in your experiment. +To measure experiment results in {{< prodname >}}Product Analytics{{< /prodname >}}, trigger RUM custom actions at key moments in the user journey. These become the metrics used in your experiment. {{< code-block lang="typescript" filename="lib/tracking.ts" >}} import { datadogRum } from '@datadog/browser-rum'; @@ -278,7 +278,7 @@ export function trackConversion(entryId: string, variantLabel: string, conversio After your RUM actions are flowing, define the metrics your experiment measures. -1. In Datadog, navigate to **Digital Experience \> Product Analytics \> Metrics**. +1. In Datadog, navigate to **Digital Experience \> {{< prodname >}}Product Analytics{{< /prodname >}} \> Metrics**. 2. Click **\+ Create Metric**. 3. Select the relevant RUM action as the event (for example, `cms_cta_click`). 4. Choose an aggregation method: @@ -292,7 +292,7 @@ After your RUM actions are flowing, define the metrics your experiment measures. ## Step 7: Launch the experiment -1. Navigate to **Digital Experience \> Product Analytics \> Experiments**. +1. Navigate to **Digital Experience \> {{< prodname >}}Product Analytics{{< /prodname >}} \> Experiments**. 2. Click **\+ Create Experiment**. 3. Enter a name and hypothesis, for example: diff --git a/hugo/content/en/feature_flags/guide/migrate_from_launchdarkly.md b/hugo/content/en/feature_flags/guide/migrate_from_launchdarkly.md index 2eb05d758f0..70dcec63eb9 100644 --- a/hugo/content/en/feature_flags/guide/migrate_from_launchdarkly.md +++ b/hugo/content/en/feature_flags/guide/migrate_from_launchdarkly.md @@ -64,7 +64,7 @@ After installation, ensure you have initialized the Datadog provider with your c ### 2. Set up and verify a new flag {#set-up-flag} -1. Create a flag in Datadog by navigating to {{< ui >}}Software Delivery{{< /ui >}} > {{< ui >}}Feature Flags{{< /ui >}}, then clicking {{< ui >}}Create Flag{{< /ui >}}. +1. Create a flag in Datadog by navigating to {{< ui >}}{{< prodname >}}Software Delivery{{< /prodname >}}{{< /ui >}} > {{< ui >}}{{< prodname >}}Feature Flags{{< /prodname >}}{{< /ui >}}, then clicking {{< ui >}}Create Flag{{< /ui >}}. 2. Implement the flag in your application code (see the code examples below these steps). 3. Test the flag in your local development environment to ensure it works as expected. 4. Deploy the application to your staging or testing environments and verify the flag's functionality. @@ -788,7 +788,7 @@ The [Datadog Flag Migration CLI][13] automates the migration of flag definitions #### Option 2: Recreate flags manually -1. In the Datadog UI, recreate the critical flags from LaunchDarkly by navigating to {{< ui >}}Software Delivery{{< /ui >}} > {{< ui >}}Feature Flags{{< /ui >}}. +1. In the Datadog UI, recreate the critical flags from LaunchDarkly by navigating to {{< ui >}}{{< prodname >}}Software Delivery{{< /prodname >}}{{< /ui >}} > {{< ui >}}{{< prodname >}}Feature Flags{{< /prodname >}}{{< /ui >}}. 2. Ensure that the flag configurations - such as rollout percentages, targeting rules, and variations - are accurately replicated in the new service. 3. For complex targeting rules, use the evaluation context attributes to implement equivalent logic. diff --git a/hugo/content/en/feature_flags/guide/migrate_from_statsig.md b/hugo/content/en/feature_flags/guide/migrate_from_statsig.md index 4acc0d77f29..482380ab599 100644 --- a/hugo/content/en/feature_flags/guide/migrate_from_statsig.md +++ b/hugo/content/en/feature_flags/guide/migrate_from_statsig.md @@ -5,7 +5,7 @@ description: Learn how to migrate feature flags from Statsig to Eppo by Datadog. ## Overview -This guide walks you through the process of migrating feature flags from Statsig to [Eppo by Datadog][1], as an intermediate step before fully migrating to Datadog's dedicated [Feature Flags][2] product. Follow these general steps: +This guide walks you through the process of migrating feature flags from Statsig to [Eppo by Datadog][1], as an intermediate step before fully migrating to Datadog's dedicated [{{< prodname >}}Feature Flags{{< /prodname >}}][2] product. Follow these general steps: 1. [Install the Eppo SDK.](#install-sdk) 2. [Create a feature flag in Eppo and verify its functionality.](#set-up-flag) @@ -50,7 +50,7 @@ await init({ ### 2. Set up and verify a new flag {#set-up-flag} -1. Create a flag in Eppo by navigating to {{< ui >}}Flags{{< /ui >}} > {{< ui >}}Feature Flags{{< /ui >}}, then clicking {{< ui >}}Create Flag{{< /ui >}} > {{< ui >}}Feature Flag{{< /ui >}}. +1. Create a flag in Eppo by navigating to {{< ui >}}Flags{{< /ui >}} > {{< ui >}}{{< prodname >}}Feature Flags{{< /prodname >}}{{< /ui >}}, then clicking {{< ui >}}Create Flag{{< /ui >}} > {{< ui >}}Feature Flag{{< /ui >}}. 1. Implement the flag in your application code. 1. Test the flag in your local development environment to ensure it works as expected. diff --git a/hugo/content/en/feature_flags/implementation_patterns/_index.md b/hugo/content/en/feature_flags/implementation_patterns/_index.md index 14a5af7b180..c4c308cabbb 100644 --- a/hugo/content/en/feature_flags/implementation_patterns/_index.md +++ b/hugo/content/en/feature_flags/implementation_patterns/_index.md @@ -7,6 +7,6 @@ Explore implementation patterns for integrating Datadog Feature Flags with your {{< whatsnext desc=" " >}} {{< nextlink href="/feature_flags/implementation_patterns/local_flag_overrides" >}}Local Flag Overrides with the Multi-Provider Pattern{{< /nextlink >}} - {{< nextlink href="/feature_flags/implementation_patterns/opentelemetry" >}}Feature Flags with OpenTelemetry{{< /nextlink >}} + {{< nextlink href="/feature_flags/implementation_patterns/opentelemetry" >}}{{< prodname >}}Feature Flags{{< /prodname >}} with OpenTelemetry{{< /nextlink >}} {{< nextlink href="/feature_flags/implementation_patterns/serverless" >}}Serverless Environments{{< /nextlink >}} {{< /whatsnext >}} diff --git a/hugo/content/en/feature_flags/implementation_patterns/serverless.md b/hugo/content/en/feature_flags/implementation_patterns/serverless.md index 61697bcd724..07c43d82c8d 100644 --- a/hugo/content/en/feature_flags/implementation_patterns/serverless.md +++ b/hugo/content/en/feature_flags/implementation_patterns/serverless.md @@ -54,7 +54,7 @@ Use agentless delivery when the serverless runtime can make outbound HTTPS reque The SDK polls the Datadog-managed CDN every 30 seconds by default and uses ETags for unchanged configuration. It preserves the last accepted configuration during temporary errors. If no configuration has been accepted, OpenFeature evaluations return the caller-provided default value. -Tracer installation and initialization alone do not start CDN polling. Requests to the CDN contribute to server Feature Flags billing only after application code activates the provider. +Tracer installation and initialization alone do not start CDN polling. Requests to the CDN contribute to server {{< prodname >}}Feature Flags{{< /prodname >}} billing only after application code activates the provider. Agentless mode removes the Datadog Agent dependency for _flag configuration_. It does not remove language-specific tracer requirements. It also does not configure or enable APM and serverless telemetry. You can use the Datadog Lambda Extension, `serverless-init`, an Agent sidecar, or another supported telemetry path independently. @@ -81,7 +81,7 @@ DD_SITE= The serverless workload must be able to reach the Agent on a private network, and the Agent must be able to reach Datadog over HTTPS. Do not expose the Agent trace intake publicly. -Explicitly selecting `remote_config` enables the Feature Flags Remote Configuration subscription, even if application code does not initialize the provider. These requests contribute to server Feature Flags billing. +Explicitly selecting `remote_config` enables the Feature Flags Remote Configuration subscription, even if application code does not initialize the provider. These requests contribute to server {{< prodname >}}Feature Flags{{< /prodname >}} billing. ## Operational considerations @@ -113,7 +113,7 @@ Java function apps can use agentless configuration delivery on Java 11 or later ### Edge runtimes -Some edge runtimes do not support the Datadog Node.js tracer APIs required by the Feature Flags provider. Verify tracer compatibility for the target platform before relying on agentless configuration delivery. +Some edge runtimes do not support the Datadog Node.js tracer APIs required by the {{< prodname >}}Feature Flags{{< /prodname >}} provider. Verify tracer compatibility for the target platform before relying on agentless configuration delivery. ## Public API and local evaluation @@ -123,7 +123,7 @@ Do not query Datadog APIs from each serverless invocation to evaluate flags. Use ## Validate your setup -Before enabling Feature Flags in production: +Before enabling {{< prodname >}}Feature Flags{{< /prodname >}} in production: 1. Confirm the application uses a [minimum supported SDK version](#overview). For Java, confirm that the JVM loads `dd-java-agent`. 2. For agentless delivery, confirm the application has `DD_API_KEY`, `DD_SITE`, and `DD_ENV`. For Agent Remote Configuration, confirm the Agent has its API key and Remote Configuration enabled. diff --git a/hugo/content/en/feature_flags/server/_index.md b/hugo/content/en/feature_flags/server/_index.md index 518eb7eb606..341b0ccabd8 100644 --- a/hugo/content/en/feature_flags/server/_index.md +++ b/hugo/content/en/feature_flags/server/_index.md @@ -32,7 +32,7 @@ Datadog Feature Flags is built on the [OpenFeature standard](https://openfeature Agentless [configuration delivery][8] is the default in server SDK versions that support it. The SDK fetches flag configuration directly from the Datadog-managed CDN over HTTPS, then evaluates flags locally. A Datadog Agent is not required for flag configuration. -The default source does not activate Feature Flags traffic for every tracer installation. Agentless polling begins only when application code initializes or accesses the Datadog OpenFeature provider. Explicitly selecting `remote_config` activates the Feature Flags Remote Configuration subscription. Requests through either source contribute to server Feature Flags billing. +The default source does not activate {{< prodname >}}Feature Flags{{< /prodname >}} traffic for every tracer installation. Agentless polling begins only when application code initializes or accesses the Datadog OpenFeature provider. Explicitly selecting `remote_config` activates the Feature Flags Remote Configuration subscription. Requests through either source contribute to server {{< prodname >}}Feature Flags{{< /prodname >}} billing. | SDK | Minimum agentless version | |---|---| diff --git a/hugo/content/en/feature_flags/server/java.md b/hugo/content/en/feature_flags/server/java.md index a131a1264d5..8f33069e730 100644 --- a/hugo/content/en/feature_flags/server/java.md +++ b/hugo/content/en/feature_flags/server/java.md @@ -543,7 +543,7 @@ Before checking infrastructure, confirm the flag itself is set up correctly: 5. Confirm that application code initializes the Datadog OpenFeature provider. 6. Confirm that `DD_API_KEY`, `DD_SITE`, and `DD_ENV` are configured in the application process. 7. Confirm that the application can make outbound HTTPS requests to Datadog. -8. Enable `DD_TRACE_DEBUG=true` and check for authentication, timeout, or malformed-payload messages from the Feature Flags agentless endpoint. +8. Enable `DD_TRACE_DEBUG=true` and check for authentication, timeout, or malformed-payload messages from the {{< prodname >}}Feature Flags{{< /prodname >}} agentless endpoint. #### Agent Remote Configuration @@ -560,7 +560,7 @@ Before checking infrastructure, confirm the flag itself is set up correctly: #### Enable debug logging -Set `DD_TRACE_DEBUG=true` to enable Feature Flags startup messages. For the default agentless source, confirm that CDN polling starts after provider initialization. +Set `DD_TRACE_DEBUG=true` to enable {{< prodname >}}Feature Flags{{< /prodname >}} startup messages. For the default agentless source, confirm that CDN polling starts after provider initialization. With `remote_config`, the provider uses the bridge in the Java agent. An older agent produces a provider initialization error that states the required agent version. It does not fall back to CDN delivery. diff --git a/hugo/content/en/feature_flags/server/ruby.md b/hugo/content/en/feature_flags/server/ruby.md index a14e60b13dc..23d0aba92b1 100644 --- a/hugo/content/en/feature_flags/server/ruby.md +++ b/hugo/content/en/feature_flags/server/ruby.md @@ -36,7 +36,7 @@ Before setting up the Ruby Feature Flags SDK, ensure you have: - **Service and environment configured** - Feature flags are targeted by service and environment - **Supported operating system** - Production support is limited to [Linux operating systems][2]. macOS and Windows are not natively supported production targets, but Dockerized Linux environments running on those operating systems are. For local development on macOS, you can use a compatible prebuilt native artifact when one is available. -
The Datadog Ruby tracer supports older Ruby runtimes for APM. Applications on older Ruby versions, including Ruby 2.5, can continue to use Datadog APM, but cannot use Datadog Feature Flags through OpenFeature until they upgrade to Ruby 3.1 or later. The OpenFeature Ruby SDK versions that expose the provider hook surface required for complete Feature Flags telemetry require Ruby 3.1 or later.
+
The Datadog Ruby tracer supports older Ruby runtimes for APM. Applications on older Ruby versions, including Ruby 2.5, can continue to use {{< prodname >}}Datadog APM{{< /prodname >}}, but cannot use Datadog Feature Flags through OpenFeature until they upgrade to Ruby 3.1 or later. The OpenFeature Ruby SDK versions that expose the provider hook surface required for complete {{< prodname >}}Feature Flags{{< /prodname >}} telemetry require Ruby 3.1 or later.
## Installing and initializing @@ -53,7 +53,7 @@ gem "opentelemetry-metrics-sdk", ">= 0.8" gem "opentelemetry-exporter-otlp-metrics", ">= 0.4" ``` -You can enable Feature Flags with environment variables: +You can enable {{< prodname >}}Feature Flags{{< /prodname >}} with environment variables: ```shell # Required: Enable the feature flags provider diff --git a/hugo/content/en/getting_started/_index.md b/hugo/content/en/getting_started/_index.md index 80f988fceb9..0a8f3874c1e 100644 --- a/hugo/content/en/getting_started/_index.md +++ b/hugo/content/en/getting_started/_index.md @@ -39,7 +39,7 @@ The table below lists a few examples of Datadog products:

Development

@@ -47,7 +47,7 @@ The table below lists a few examples of Datadog products:

Testing

@@ -110,33 +110,33 @@ For the fastest introduction to navigating Datadog, try the [Quick Start course] {{< whatsnext desc="Platform Services:">}} {{< nextlink href="/getting_started/dashboards" >}}Dashboards: Create, share, and maintain dashboards that answer the work questions that matter to you.{{< /nextlink >}} -{{< nextlink href="/getting_started/incident_management" >}}Incident Management: Communicate and track problems in your systems.{{< /nextlink >}} +{{< nextlink href="/getting_started/incident_management" >}}{{< prodname >}}Incident Management{{< /prodname >}}: Communicate and track problems in your systems.{{< /nextlink >}} {{< nextlink href="/getting_started/monitors" >}}Monitors: Set up alerts and notifications so that your team knows when critical changes occur.{{< /nextlink >}} {{< nextlink href="/getting_started/notebooks" >}}Notebooks: Combine live graphs, metrics, logs, and monitors to isolate issues and create interactive guides.{{< /nextlink >}} {{< nextlink href="/account_management/organization_topology" >}}Organization Topology: Choose between single-org and multi-org Datadog deployments and manage isolation with access controls.{{< /nextlink >}} {{< nextlink href="/getting_started/teams" >}}Teams: Build a reliable ownership model by syncing team data from identity providers, GitHub, and other sources into Datadog.{{< /nextlink >}} -{{< nextlink href="/getting_started/workflow_automation" >}}Workflow Automation: Automate end-to-end processes in response to alerts and security signals.{{< /nextlink >}} +{{< nextlink href="/getting_started/workflow_automation" >}}{{< prodname >}}Workflow Automation{{< /prodname >}}: Automate end-to-end processes in response to alerts and security signals.{{< /nextlink >}} {{< /whatsnext >}} {{< whatsnext desc="Product:">}} {{< nextlink href="/getting_started/containers" >}}Containers: Learn how to use Agent Autodiscovery and the Datadog operator.{{< /nextlink >}} {{< nextlink href="/getting_started/serverless" >}}Serverless for AWS Lambda: Learn how to collect metrics, logs, and traces from your serverless infrastructure.{{< /nextlink >}} -{{< nextlink href="/getting_started/internal_developer_portal" >}}Internal Developer Portal: Unify telemetry, metadata, and workflows to accelerate delivery. {{< /nextlink >}} +{{< nextlink href="/getting_started/internal_developer_portal" >}}{{< prodname >}}Internal Developer Portal{{< /prodname >}}: Unify telemetry, metadata, and workflows to accelerate delivery. {{< /nextlink >}} {{< nextlink href="/getting_started/tracing" >}}Tracing: Set up the Agent to trace a small application.{{< /nextlink >}} {{< nextlink href="/getting_started/profiler" >}}Profiler: Use Continuous Profiler to find and fix performance problems in your code.{{< /nextlink >}} -{{< nextlink href="/getting_started/database_monitoring" >}}Database Monitoring: View the health and performance of databases, and quickly troubleshoot any issues that arise.{{< /nextlink >}} +{{< nextlink href="/getting_started/database_monitoring" >}}{{< prodname >}}Database Monitoring{{< /prodname >}}: View the health and performance of databases, and quickly troubleshoot any issues that arise.{{< /nextlink >}} {{< nextlink href="/getting_started/synthetics" >}}Synthetic Monitoring: Start testing and monitoring your API endpoints and key business journeys with Synthetic tests.{{< /nextlink >}} {{< nextlink href="/getting_started/continuous_testing" >}}Continuous Testing: Run end-to-end Synthetic tests in your CI pipelines and IDEs.{{< /nextlink >}} {{< nextlink href="/getting_started/session_replay" >}}Session Replay: Get an in-depth look at how users are interacting with your product with Session Replays.{{< /nextlink >}} -{{< nextlink href="/getting_started/application_security" >}}App and API Protection: Discover best practices for getting your team up and running with AAP.{{< /nextlink >}} -{{< nextlink href="/getting_started/cloud_security_management" >}}Cloud Security: Discover best practices for getting your team up and running with Cloud Security.{{< /nextlink >}} -{{< nextlink href="/getting_started/cloud_siem" >}}Cloud SIEM: Discover best practices for getting your team up and running with Cloud SIEM.{{< /nextlink >}} +{{< nextlink href="/getting_started/application_security" >}}{{< prodname >}}App and API Protection{{< /prodname >}}: Discover best practices for getting your team up and running with AAP.{{< /nextlink >}} +{{< nextlink href="/getting_started/cloud_security_management" >}}{{< prodname >}}Cloud Security{{< /prodname >}}: Discover best practices for getting your team up and running with {{< prodname >}}Cloud Security{{< /prodname >}}.{{< /nextlink >}} +{{< nextlink href="/getting_started/cloud_siem" >}}{{< prodname >}}Cloud SIEM{{< /prodname >}}: Discover best practices for getting your team up and running with {{< prodname >}}Cloud SIEM{{< /prodname >}}.{{< /nextlink >}} {{< nextlink href="/getting_started/logs" >}}Logs: Send your first logs and use log processing to enrich them.{{< /nextlink >}} {{< nextlink href="/getting_started/ci_visibility" >}}CI Visibility: Collect CI pipeline data by setting up integrations with your CI providers.{{< /nextlink >}} -{{< nextlink href="/getting_started/feature_flags" >}}Feature Flags: Manage feature delivery and personalize user experiences, with built-in observability.{{< /nextlink >}} -{{< nextlink href="/getting_started/test_optimization" >}}Test Optimization: Collect CI test data by setting up test services in Datadog.{{< /nextlink >}} +{{< nextlink href="/getting_started/feature_flags" >}}{{< prodname >}}Feature Flags{{< /prodname >}}: Manage feature delivery and personalize user experiences, with built-in observability.{{< /nextlink >}} +{{< nextlink href="/getting_started/test_optimization" >}}{{< prodname >}}Test Optimization{{< /prodname >}}: Collect CI test data by setting up test services in Datadog.{{< /nextlink >}} {{< nextlink href="/getting_started/test_impact_analysis" >}}Test Impact Analysis: Optimize your test suite and reduce CI costs by only running tests that are relevant to your code changes.{{< /nextlink >}} -{{< nextlink href="/getting_started/code_security" >}}Code Security: Analyze your first-party code and open source libraries in your applications from development to runtime.{{< /nextlink >}} +{{< nextlink href="/getting_started/code_security" >}}{{< prodname >}}Code Security{{< /prodname >}}: Analyze your first-party code and open source libraries in your applications from development to runtime.{{< /nextlink >}} {{< /whatsnext >}} ## Try a Preview product or feature diff --git a/hugo/content/en/getting_started/application/_index.md b/hugo/content/en/getting_started/application/_index.md index 9ad88305951..c87d6c76355 100644 --- a/hugo/content/en/getting_started/application/_index.md +++ b/hugo/content/en/getting_started/application/_index.md @@ -73,7 +73,7 @@ Navigate to [{{< ui >}}Logs{{< /ui >}}][8] in the app to get started. To learn m ## APM -[Datadog Application Performance Monitoring][9] (APM or tracing) provides you with deep insight into your application's performance side by side with your logs and infrastructure monitoring. +[{{< prodname >}}Datadog Application Performance Monitoring{{< /prodname >}}][9] (APM or tracing) provides you with deep insight into your application's performance side by side with your logs and infrastructure monitoring. **Key capabilities**: diff --git a/hugo/content/en/getting_started/ci_visibility/_index.md b/hugo/content/en/getting_started/ci_visibility/_index.md index bc0cdcf621c..5f46feb6c6a 100644 --- a/hugo/content/en/getting_started/ci_visibility/_index.md +++ b/hugo/content/en/getting_started/ci_visibility/_index.md @@ -123,7 +123,7 @@ Once you click into a pipeline, you can access individual pipeline executions li You can identify bottlenecks in your pipeline and examine individual nodes ranked from the largest to smallest percentage of execution time. -After you have set up Test Optimization, you can access information about tests that were run in your CI pipelines, including the test status (Failed, New Flaky, Passed, or Skipped), on the {{< ui >}}Test Runs{{< /ui >}} tab in a pipeline execution’s side panel. For more information, see the [Flaky Test Management documentation][10]. +After you have set up {{< prodname >}}Test Optimization{{< /prodname >}}, you can access information about tests that were run in your CI pipelines, including the test status (Failed, New Flaky, Passed, or Skipped), on the {{< ui >}}Test Runs{{< /ui >}} tab in a pipeline execution’s side panel. For more information, see the [Flaky Test Management documentation][10]. You can access pipeline or job logs across cloud and self-hosted runners and see information about your runners on the {{< ui >}}Logs{{< /ui >}} tab in a pipeline execution’s side panel. diff --git a/hugo/content/en/getting_started/code_security/_index.md b/hugo/content/en/getting_started/code_security/_index.md index b86dcec3fe6..38a6a994f8c 100644 --- a/hugo/content/en/getting_started/code_security/_index.md +++ b/hugo/content/en/getting_started/code_security/_index.md @@ -59,11 +59,11 @@ In [Code Security Settings][3], you can manage which repositories have PR commen ### Set up PR Gates -Datadog provides [PR Gates][6] as a platform capability to help you maintain and enforce security and quality standards for changes introduced to your codebase. For more information, see [PR Gate setup][7]. +Datadog provides [{{< prodname >}}PR Gates{{< /prodname >}}][6] as a platform capability to help you maintain and enforce security and quality standards for changes introduced to your codebase. For more information, see [PR Gate setup][7]. ## Prioritize vulnerabilities with runtime context -Code Security offers **vulnerability-centric views** of all library and code vulnerabilities detected from both static repository scanning and runtime service detection. +{{< prodname >}}Code Security{{< /prodname >}} offers **vulnerability-centric views** of all library and code vulnerabilities detected from both static repository scanning and runtime service detection. ### Explore vulnerabilities @@ -86,7 +86,7 @@ In the side panel for a single library vulnerability in SCA, in addition to deta ### Explore results per repository -Code Security also offers **repository-centric views** of static scan results, supporting granular filtering across all branches and commits for scanned repositories. +{{< prodname >}}Code Security{{< /prodname >}} also offers **repository-centric views** of static scan results, supporting granular filtering across all branches and commits for scanned repositories. Click on a repository on the {{< ui >}}Repositories{{< /ui >}} page to access a more detailed view where you can customize the search query by branch (with the default branch appearing first) and by commit (starting with the latest). @@ -134,7 +134,7 @@ You can access vulnerability reports and locate the source files where the vulne ## Notify, remediate, and report -Code Security helps you set up workflows to track and manage remediation of findings: +{{< prodname >}}Code Security{{< /prodname >}} helps you set up workflows to track and manage remediation of findings: - Set up [notification rules][9] to notify your team(s) of new findings via Slack, Jira, email, and more - Track vulnerabilities by service and team in the {{< ui >}}Code Security Summary{{< /ui >}} page. diff --git a/hugo/content/en/getting_started/continuous_testing/_index.md b/hugo/content/en/getting_started/continuous_testing/_index.md index 021950a402c..7168288a560 100644 --- a/hugo/content/en/getting_started/continuous_testing/_index.md +++ b/hugo/content/en/getting_started/continuous_testing/_index.md @@ -97,7 +97,7 @@ You can retrieve the command for running a specific test using `datadog-ci` from 3. Look for the command in the {{< ui >}}CI/CD Execution{{< /ui >}} section. 4. Copy and paste the command into your command line. -For more information about running the Synthetics command and using reporters, see the [Configuration documentation][11]. +For more information about running the {{< prodname >}}Synthetics{{< /prodname >}} command and using reporters, see the [Configuration documentation][11]. ## Examine results in the Synthetic Monitoring & Testing Results Explorer diff --git a/hugo/content/en/getting_started/database_monitoring/_index.md b/hugo/content/en/getting_started/database_monitoring/_index.md index bb28277b8f7..0efb381c2d4 100644 --- a/hugo/content/en/getting_started/database_monitoring/_index.md +++ b/hugo/content/en/getting_started/database_monitoring/_index.md @@ -91,7 +91,7 @@ Follow these instructions to install the example application on macOS or Linux. Which query consumes the most database time? To find out, use the Query Metrics view. -1. On the [Database Monitoring][6] page, click the {{< ui >}}Query metrics{{< /ui >}} tab in the UI. +1. On the [{{< prodname >}}Database Monitoring{{< /prodname >}}][6] page, click the {{< ui >}}Query metrics{{< /ui >}} tab in the UI. 2. Sort the Normalized Query table by {{< ui >}}Percent time{{< /ui >}} to see the query that the database spends the most time executing. @@ -103,7 +103,7 @@ Which query consumes the most database time? To find out, use the Query Metrics In addition to identifying slow queries, Datadog Database Monitoring can help you diagnose them. A query's Explain Plan describes the steps that the database takes to resolve the query. View an Explain Plan by clicking on a sample in the Query Samples view. -1. Navigate to the Query Samples view within [Database Monitoring][6] by selecting the {{< ui >}}Samples{{< /ui >}} tab. +1. Navigate to the Query Samples view within [{{< prodname >}}Database Monitoring{{< /prodname >}}][6] by selecting the {{< ui >}}Samples{{< /ui >}} tab. 2. In the {{< ui >}}In{{< /ui >}} dropdown, select {{< ui >}}Explain Plans{{< /ui >}}. @@ -125,9 +125,9 @@ The orders app emits APM traces that are automatically linked to the database qu 2. On the trace flame graph, click a database span to open its details panel. -3. In the details panel, click {{< ui >}}View in DBM{{< /ui >}} to jump directly to that query in Database Monitoring. +3. In the details panel, click {{< ui >}}View in DBM{{< /ui >}} to jump directly to that query in {{< prodname >}}Database Monitoring{{< /prodname >}}. -Conversely, in a Query Sample in Database Monitoring, click {{< ui >}}View Trace{{< /ui >}} to open the originating APM trace. +Conversely, in a Query Sample in {{< prodname >}}Database Monitoring{{< /prodname >}}, click {{< ui >}}View Trace{{< /ui >}} to open the originating APM trace. {{< img src="database_monitoring/dbm_apm_correlation.png" alt="APM trace linked to a DBM query sample" style="width:100%;">}} @@ -161,7 +161,7 @@ For example, you can see the absolute change in query volume in the past hour by Observe current database activity, resource utilization, and more on out-of-the-box dashboards provided by Datadog Database Monitoring. -To access the dashboards, from the [Database Monitoring][6] page, select the {{< ui >}}Dashboards{{< /ui >}} tab and choose the dashboard that you want to see. +To access the dashboards, from the [{{< prodname >}}Database Monitoring{{< /prodname >}}][6] page, select the {{< ui >}}Dashboards{{< /ui >}} tab and choose the dashboard that you want to see. You can clone and modify out-of-the-box dashboards to suit your needs. diff --git a/hugo/content/en/getting_started/devsecops/_index.md b/hugo/content/en/getting_started/devsecops/_index.md index 61797468123..8ce31db4645 100644 --- a/hugo/content/en/getting_started/devsecops/_index.md +++ b/hugo/content/en/getting_started/devsecops/_index.md @@ -7,12 +7,12 @@ This guide introduces the Infrastructure Monitoring DevSecOps bundles, with link ## Infrastructure DevSecOps -The Infrastructure DevSecOps bundles combine infrastructure monitoring with the security capabilities of [Cloud Security][3]. +The Infrastructure DevSecOps bundles combine infrastructure monitoring with the security capabilities of [{{< prodname >}}Cloud Security{{< /prodname >}}][3]. {{< tabs >}} {{% tab "Infrastructure DevSecOps Pro" %}} -Infrastructure DevSecOps Pro includes [Containers][1], [Serverless][2], and [Cloud Security][3]. It also includes more than {{< translate key="integration_count" >}} [out-of-the-box integrations][4]. +Infrastructure DevSecOps Pro includes [Containers][1], [Serverless][2], and [{{< prodname >}}Cloud Security{{< /prodname >}}][3]. It also includes more than {{< translate key="integration_count" >}} [out-of-the-box integrations][4]. ### Setup @@ -22,9 +22,9 @@ To get started with Infrastructure DevSecOps Pro, [install and configure the Dat - [Serverless][2] - [Integrations][4] -After you install the Agent, configure Cloud Security for your environment. +After you install the Agent, configure {{< prodname >}}Cloud Security{{< /prodname >}} for your environment. -- [Cloud Security][3] +- [{{< prodname >}}Cloud Security{{< /prodname >}}][3] ### Next steps @@ -35,7 +35,7 @@ Learn more about the features included with Infrastructure DevSecOps Pro: - [Host and Container Maps][9]: Visualize your hosts and containers - [Live Containers][10]: Gain real-time visibility into all containers across your environment - [Serverless][2]: Gain full visibility into all of the managed services that power your serverless applications -- [Cloud Security][11]: Real-time threat detection and continuous configuration audits across your entire cloud infrastructure +- [{{< prodname >}}Cloud Security{{< /prodname >}}][11]: Real-time threat detection and continuous configuration audits across your entire cloud infrastructure [1]: /containers/ [2]: /serverless/ @@ -51,7 +51,7 @@ Learn more about the features included with Infrastructure DevSecOps Pro: {{% /tab %}} {{% tab "Infrastructure DevSecOps Enterprise" %}} -Infrastructure DevSecOps Enterprise includes [Containers][1], [Serverless][2], [Live Processes][3], and [Cloud Security][4]. It also includes more than {{< translate key="integration_count" >}} [out-of-the-box integrations][5]. +Infrastructure DevSecOps Enterprise includes [Containers][1], [Serverless][2], [Live Processes][3], and [{{< prodname >}}Cloud Security{{< /prodname >}}][4]. It also includes more than {{< translate key="integration_count" >}} [out-of-the-box integrations][5]. ### Setup @@ -62,9 +62,9 @@ To get started with Infrastructure DevSecOps Enterprise, [install and configure - [Live Processes][7] - [Integrations][5] -After you install the Agent, configure Cloud Security for your environment. +After you install the Agent, configure {{< prodname >}}Cloud Security{{< /prodname >}} for your environment. -- [Cloud Security][4] +- [{{< prodname >}}Cloud Security{{< /prodname >}}][4] ### Next steps @@ -78,7 +78,7 @@ Learn more about the features included with Infrastructure DevSecOps Enterprise: - [Live Processes][14]: Gain real-time visibility into the process running on your infrastructure - [Serverless][2]: Gain full visibility into all of the managed services that power your serverless - [Watchdog][15]: Automatically detect potential application and infrastructure issues -- [Cloud Security][16]: Real-time threat detection and continuous configuration audits across your entire cloud infrastructure +- [{{< prodname >}}Cloud Security{{< /prodname >}}][16]: Real-time threat detection and continuous configuration audits across your entire cloud infrastructure [1]: /containers/ [2]: /serverless/ diff --git a/hugo/content/en/getting_started/feature_flags/_index.md b/hugo/content/en/getting_started/feature_flags/_index.md index 6f46316934e..e81c20bad55 100644 --- a/hugo/content/en/getting_started/feature_flags/_index.md +++ b/hugo/content/en/getting_started/feature_flags/_index.md @@ -79,7 +79,7 @@ Your organization likely already has pre-configured environments for Development ## Create your first feature flag
-You can set up Feature Flags automatically with the Feature Flags MCP Server. After connecting, prompt your AI agent: "Help me set up Datadog Feature Flags in my app." The MCP Server reviews your codebase and installs the required SDK and code snippets for your language and framework. +You can set up {{< prodname >}}Feature Flags{{< /prodname >}} automatically with the Feature Flags MCP Server. After connecting, prompt your AI agent: "Help me set up Datadog Feature Flags in my app." The MCP Server reviews your codebase and installs the required SDK and code snippets for your language and framework.
### Step 1: Import and initialize the SDK diff --git a/hugo/content/en/getting_started/incident_management/_index.md b/hugo/content/en/getting_started/incident_management/_index.md index fb5a9a994e7..51e5d175a4d 100644 --- a/hugo/content/en/getting_started/incident_management/_index.md +++ b/hugo/content/en/getting_started/incident_management/_index.md @@ -167,11 +167,11 @@ If there are follow-up tasks that you and your team need to complete to ensure t {{< img src="getting_started/incident_management/generate_postmortem.png" alt="Generate Postmortem" responsive="true" style="width:80%;">}} ## Customizing your incident management workflow -Datadog Incident Management can be customized with different severity and status levels, based on your organization's needs, and also include additional information such as APM services and teams related to the incident. For more information, see this [section][9] of the Incident Management page. +Datadog Incident Management can be customized with different severity and status levels, based on your organization's needs, and also include additional information such as APM services and teams related to the incident. For more information, see this [section][9] of the {{< prodname >}}Incident Management{{< /prodname >}} page. You can also set up notification rules to automatically notify specific people or services based on an incident's severity level. For more information, see the [Incident Settings][10] documentation. -To customize Incident Management, go to the [incident settings page][11]. From the Datadog menu on the left-hand side, go to {{< ui >}}Monitors{{< /ui >}} > {{< ui >}}Incidents{{< /ui >}} (if you get an Incident Management welcome screen, click {{< ui >}}Get Started{{< /ui >}}). Then on the top, click {{< ui >}}Settings{{< /ui >}}. +To customize {{< prodname >}}Incident Management{{< /prodname >}}, go to the [incident settings page][11]. From the Datadog menu on the left-hand side, go to {{< ui >}}Monitors{{< /ui >}} > {{< ui >}}Incidents{{< /ui >}} (if you get an {{< prodname >}}Incident Management{{< /prodname >}} welcome screen, click {{< ui >}}Get Started{{< /ui >}}). Then on the top, click {{< ui >}}Settings{{< /ui >}}. ## Create and Manage Incidents on Mobile diff --git a/hugo/content/en/getting_started/integrations/azure.md b/hugo/content/en/getting_started/integrations/azure.md index 8c422e0f6f1..6bcfcbffbb6 100644 --- a/hugo/content/en/getting_started/integrations/azure.md +++ b/hugo/content/en/getting_started/integrations/azure.md @@ -56,7 +56,7 @@ The `Datadog Admin Role`, or any other role with the `azure_configurations_manag {{< site-region region="us3" >}} -
Cloud Cost Management and Log Archives require the app registration setup method. For Datadog accounts using the Azure Native integration, follow the setup steps on this page to create an app registration. If a subscription is connected through both methods, a redundancy warning appears in the Azure integration tile. This warning can be safely ignored for Cloud Cost Management and Log Archives. +
{{< prodname >}}Cloud Cost Management{{< /prodname >}} and Log Archives require the app registration setup method. For Datadog accounts using the Azure Native integration, follow the setup steps on this page to create an app registration. If a subscription is connected through both methods, a redundancy warning appears in the Azure integration tile. This warning can be safely ignored for {{< prodname >}}Cloud Cost Management{{< /prodname >}} and Log Archives.
{{< /site-region >}} diff --git a/hugo/content/en/getting_started/integrations/google_cloud.md b/hugo/content/en/getting_started/integrations/google_cloud.md index b0c7f9fbe94..b45cc22175d 100644 --- a/hugo/content/en/getting_started/integrations/google_cloud.md +++ b/hugo/content/en/getting_started/integrations/google_cloud.md @@ -387,7 +387,7 @@ To enable this feature: ## Log collection -Forwarding logs from your Google Cloud environment enables near real-time monitoring of the resources and activities taking place in your organization or folder. You can set up [log monitors][37] to be notified of issues, use [Cloud SIEM][38] to detect threats, or leverage [Watchdog][39] to identify unknown issues or anomalous behavior. +Forwarding logs from your Google Cloud environment enables near real-time monitoring of the resources and activities taking place in your organization or folder. You can set up [log monitors][37] to be notified of issues, use [{{< prodname >}}Cloud SIEM{{< /prodname >}}][38] to detect threats, or leverage [Watchdog][39] to identify unknown issues or anomalous behavior. Use the [Datadog Dataflow template][14] to batch and compresses your log events before forwarding them to Datadog through [Google Cloud Dataflow][15]. This is the most network-efficient way to forward your logs. To specify which logs are forwarded, configure the [Google Cloud Logging sink][40] with any inclusion or exclusion queries using Google Cloud's [Logging query language][56]. See the [Google Cloud Log Forwarding Setup page][67] for log forwarding setup options (including Terraform) and instructions. @@ -410,7 +410,7 @@ For the full list of benefits of installing the Agent on your cloud instances, s ## Resource changes collection -Resource changes collection allows you to monitor infrastructure changes in your Google Cloud environment. When Google's Cloud Asset Inventory detects changes in your cloud resources, an event is forwarded to Datadog's [Event Management][62] through a Cloud Pub/Sub topic and subscription. Use these events to be proactively notified of risky changes in your infrastructure, and to assist with troubleshooting. +Resource changes collection allows you to monitor infrastructure changes in your Google Cloud environment. When Google's Cloud Asset Inventory detects changes in your cloud resources, an event is forwarded to Datadog's [{{< prodname >}}Event Management{{< /prodname >}}][62] through a Cloud Pub/Sub topic and subscription. Use these events to be proactively notified of risky changes in your infrastructure, and to assist with troubleshooting. For detailed setup instructions, see the [resource changes collection section][18] of the Google Cloud integration documentation. @@ -435,10 +435,10 @@ Datadog's [Google Cloud Cost Management][45] provides insights for engineering a ### Cloud SIEM -Cloud SIEM provides real-time analysis of operational and security logs, while using out-of-the-box integrations and rules to detect and investigate threats. +{{< prodname >}}Cloud SIEM{{< /prodname >}} provides real-time analysis of operational and security logs, while using out-of-the-box integrations and rules to detect and investigate threats. To use this feature, see [Getting Started with Cloud SIEM][46]. -To view security findings from [Google Cloud Security Command Center][47] in Cloud SIEM, toggle the {{< ui >}}Enable collection of security findings{{< /ui >}} option under the {{< ui >}}Security Findings{{< /ui >}} tab and follow the setup instructions on the [Google Cloud Security Command Center guide][48]. +To view security findings from [Google Cloud Security Command Center][47] in {{< prodname >}}Cloud SIEM{{< /prodname >}}, toggle the {{< ui >}}Enable collection of security findings{{< /ui >}} option under the {{< ui >}}Security Findings{{< /ui >}} tab and follow the setup instructions on the [Google Cloud Security Command Center guide][48]. {{< img src="integrations/google_cloud_platform/security_findings.png" alt="The security findings tab in the Google Cloud integration tile" style="width:90%;" >}} @@ -447,7 +447,7 @@ To view security findings from [Google Cloud Security Command Center][47] in Clo Datadog Cloud Security delivers real-time threat detection and continuous configuration audits across your entire cloud infrastructure. Check out the [Setting up Cloud Security guide][49] to get started. -After setting up Cloud Security, toggle the {{< ui >}}Enable Resource Collection{{< /ui >}} option under the {{< ui >}}Resource Collection{{< /ui >}} tab to start collecting configuration data for the [Resource Catalog][50] and Cloud Security. Then, follow these instructions to enable [Misconfigurations and Identity Risks (CIEM)][51] on Google Cloud. +After setting up {{< prodname >}}Cloud Security{{< /prodname >}}, toggle the {{< ui >}}Enable Resource Collection{{< /ui >}} option under the {{< ui >}}Resource Collection{{< /ui >}} tab to start collecting configuration data for the [{{< prodname >}}Resource Catalog{{< /prodname >}}][50] and {{< prodname >}}Cloud Security{{< /prodname >}}. Then, follow these instructions to enable [Misconfigurations and Identity Risks (CIEM)][51] on Google Cloud. {{< img src="integrations/google_cloud_platform/resource_collection.png" alt="The resource collection tab in the Google Cloud integration tile" style="width:100%;" >}} diff --git a/hugo/content/en/getting_started/integrations/oci.md b/hugo/content/en/getting_started/integrations/oci.md index 1411cb2c6a8..be4ffdc5d28 100644 --- a/hugo/content/en/getting_started/integrations/oci.md +++ b/hugo/content/en/getting_started/integrations/oci.md @@ -188,20 +188,20 @@ After setting up the OCI integration, ensure that the GPU-related namespaces are Datadog's [Oracle Cloud Cost Management][24] provides insights for engineering and finance teams to understand how infrastructure changes impact costs, allocate spend across your organization, and identify potential improvements. -To enable Cloud Cost Management for OCI: +To enable {{< prodname >}}Cloud Cost Management{{< /prodname >}} for OCI: 1. Ensure you have configured the OCI integration as described above. 2. Follow the setup instructions in the [Oracle Cloud Cost Management documentation][24] to enable cost data collection. ### Cloud SIEM -Cloud SIEM provides real-time analysis of operational and security logs, using out-of-the-box integrations and rules to detect and investigate threats. +{{< prodname >}}Cloud SIEM{{< /prodname >}} provides real-time analysis of operational and security logs, using out-of-the-box integrations and rules to detect and investigate threats. -To use Cloud SIEM with your OCI environment: +To use {{< prodname >}}Cloud SIEM{{< /prodname >}} with your OCI environment: 1. Ensure log collection is enabled in your OCI integration configuration. 2. Review [Getting Started with Cloud SIEM][25] to configure threat detection. 3. Follow the [OCI configuration guide for Cloud SIEM][26] to set up specific log sources and security rules for OCI. -Cloud SIEM analyzes OCI logs to detect: +{{< prodname >}}Cloud SIEM{{< /prodname >}} analyzes OCI logs to detect: - Unauthorized access attempts - Suspicious API calls - Configuration changes that may introduce security risks diff --git a/hugo/content/en/getting_started/internal_developer_portal/_index.md b/hugo/content/en/getting_started/internal_developer_portal/_index.md index 28f7cbc26ff..d47904b67c9 100644 --- a/hugo/content/en/getting_started/internal_developer_portal/_index.md +++ b/hugo/content/en/getting_started/internal_developer_portal/_index.md @@ -23,7 +23,7 @@ further_reading: ## Overview -Datadog's Internal Developer Portal (IDP) helps you unify software metadata, live telemetry, and developer workflows in a single platform. This guide walks you through setting up each core IDP component: +Datadog's {{< prodname >}}Internal Developer Portal{{< /prodname >}} (IDP) helps you unify software metadata, live telemetry, and developer workflows in a single platform. This guide walks you through setting up each core IDP component: - [Catalog][1]: Real-time inventory of entities and environments, enriched with ownership and operational metadata. - [Scorecards][2]: Measure adoption of engineering best practices using rules-based evaluations. @@ -117,7 +117,7 @@ In addition to using default rules, you can define custom rules to reflect your 1. Send an outcome of `pass`, `fail`, or `skip` for each entity in one of the following ways: - Manually through the Datadog UI - Programmatically through the Scorecards API - - Automatically, using [Workflow Automation][14] to post outcomes on a schedule + - Automatically, using [{{< prodname >}}Workflow Automation{{< /prodname >}}][14] to post outcomes on a schedule 1. View an overview of outcomes on the [Scorecards page][13]. Learn more about scorecard configuration and custom rules in the [Scorecards documentation][2]. diff --git a/hugo/content/en/getting_started/logs/_index.md b/hugo/content/en/getting_started/logs/_index.md index d15f23c395b..f6e8bec37d2 100644 --- a/hugo/content/en/getting_started/logs/_index.md +++ b/hugo/content/en/getting_started/logs/_index.md @@ -26,11 +26,11 @@ further_reading: Use Datadog Log Management, also called logs, to collect logs across multiple logging sources, such as your server, container, cloud environment, application, or existing log processors and forwarders. With conventional logging, you have to choose which logs to analyze and retain to maintain cost-efficiency. With Datadog Logging without Limits*, you can collect, process, archive, explore, and monitor your logs without logging limits. -This page shows you how to get started with Log Management in Datadog. If you haven't already, create a [Datadog account][1]. +This page shows you how to get started with {{< prodname >}}Log Management{{< /prodname >}} in Datadog. If you haven't already, create a [Datadog account][1]. ## Configure a logging source -With Log Management, you can analyze and explore data in the {{< ui >}}Log Explorer{{< /ui >}}, connect [Tracing][2] and [Metrics][3] to correlate valuable data across Datadog, and use ingested logs for Datadog [Cloud SIEM][4]. The lifecycle of a log within Datadog begins at ingestion from a logging source. +With Log Management, you can analyze and explore data in the {{< ui >}}Log Explorer{{< /ui >}}, connect [Tracing][2] and [Metrics][3] to correlate valuable data across Datadog, and use ingested logs for Datadog [{{< prodname >}}Cloud SIEM{{< /prodname >}}][4]. The lifecycle of a log within Datadog begins at ingestion from a logging source. {{< img src="/getting_started/logs/getting-started-overview.png" alt="Different types of log configurations">}} diff --git a/hugo/content/en/getting_started/monitors/_index.md b/hugo/content/en/getting_started/monitors/_index.md index 9ac7017b15a..43768e28f8e 100644 --- a/hugo/content/en/getting_started/monitors/_index.md +++ b/hugo/content/en/getting_started/monitors/_index.md @@ -126,7 +126,7 @@ Send notifications to your team through email, Slack, PagerDuty, and more. You c {{< img src="getting_started/monitors/monitor_notification.png" alt="Add a monitor message and automations to your alert notification" style="width:100%;" >}} -To add a workflow from [Workflow Automation][14] or a case from [Case Management][15] to the alert notification, click {{< ui >}}Add Workflow{{< /ui >}} or {{< ui >}}Add Case{{< /ui >}}. You can also tag [Datadog Team][16] members using the `@team` handle. +To add a workflow from [{{< prodname >}}Workflow Automation{{< /prodname >}}][14] or a case from [{{< prodname >}}Case Management{{< /prodname >}}][15] to the alert notification, click {{< ui >}}Add Workflow{{< /ui >}} or {{< ui >}}Add Case{{< /ui >}}. You can also tag [Datadog Team][16] members using the `@team` handle. Leave the other sections as-is. For more information on what each configuration option does, see the [Monitor configuration][9] documentation. diff --git a/hugo/content/en/getting_started/search/_index.md b/hugo/content/en/getting_started/search/_index.md index e0ec81d1101..09e3713d9ed 100644 --- a/hugo/content/en/getting_started/search/_index.md +++ b/hugo/content/en/getting_started/search/_index.md @@ -15,7 +15,7 @@ Datadog provides powerful and flexible search capabilities across its products a ## Understanding Datadog search Datadog provides a unified way to query data across products using text-based search syntax. All data in Datadog can be explored and filtered through queries, but the syntax and behavior differ depending on the type of data you're working with. There are two primary query formats in Datadog: -- **Metric-based queries**: Used in Metrics and Cloud Cost Management (CCM). +- **Metric-based queries**: Used in Metrics and {{< prodname >}}Cloud Cost Management{{< /prodname >}} (CCM). - **Event-based queries**: Used across most other products, including Logs, APM, RUM, Events, and Security. Although both query types let you filter and analyze data, their syntax is not interchangeable. Each follows its own structure, operators, and supported functions designed for the type of data it handles. diff --git a/hugo/content/en/getting_started/search/product_specific_reference.md b/hugo/content/en/getting_started/search/product_specific_reference.md index 3e27ff99e5e..86f608057e4 100644 --- a/hugo/content/en/getting_started/search/product_specific_reference.md +++ b/hugo/content/en/getting_started/search/product_specific_reference.md @@ -15,9 +15,9 @@ Each Datadog product offers unique search capabilities optimized for its use cas There are two main families of search syntaxes across Datadog products: -**Metrics-based syntax**: Used by Metrics and Cloud Cost Management for time-series data queries with tag-based filtering and aggregation. +**Metrics-based syntax**: Used by Metrics and {{< prodname >}}Cloud Cost Management{{< /prodname >}} for time-series data queries with tag-based filtering and aggregation. -**Event-based syntax**: Used by Log Management and adopted by most other Datadog products including traces, RUM, CI/CD, Observability Pipelines, and more. This syntax provides flexible faceted search with boolean operators and pattern matching. +**Event-based syntax**: Used by {{< prodname >}}Log Management{{< /prodname >}} and adopted by most other Datadog products including traces, RUM, CI/CD, {{< prodname >}}Observability Pipelines{{< /prodname >}}, and more. This syntax provides flexible faceted search with boolean operators and pattern matching. ## Metrics @@ -58,7 +58,7 @@ system.mem.used{env:production AND NOT service:test} ## Logs -Log Management uses event-based search syntax, serving as the foundation for many other products' search capabilities. +{{< prodname >}}Log Management{{< /prodname >}} uses event-based search syntax, serving as the foundation for many other products' search capabilities. For a complete reference for log search operators, wildcards, facets, and advanced queries, see [Log Search Syntax][2]. diff --git a/hugo/content/en/getting_started/security/_index.md b/hugo/content/en/getting_started/security/_index.md index 076e2eac8f2..cb0fefc8a46 100644 --- a/hugo/content/en/getting_started/security/_index.md +++ b/hugo/content/en/getting_started/security/_index.md @@ -4,10 +4,10 @@ description: Explore security solutions including App and API Protection, Cloud --- {{< whatsnext desc=" " >}} - {{< nextlink href="getting_started/security/application_security" tag="documentation" >}}Getting Started with App and API Protection{{< /nextlink >}} - {{< nextlink href="getting_started/security/cloud_security_management" tag="documentation" >}}Getting Started with Cloud Security{{< /nextlink >}} - {{< nextlink href="getting_started/security/cloud_siem" tag="documentation" >}}Getting Started with Cloud SIEM{{< /nextlink >}} - {{< nextlink href="getting_started/code_security" tag="documentation" >}}Getting Started with Code Security{{< /nextlink >}} - {{< nextlink href="security/workload_protection/setup" tag="documentation" >}}Setting up Workload Protection + {{< nextlink href="getting_started/security/application_security" tag="documentation" >}}Getting Started with {{< prodname >}}App and API Protection{{< /prodname >}}{{< /nextlink >}} + {{< nextlink href="getting_started/security/cloud_security_management" tag="documentation" >}}Getting Started with {{< prodname >}}Cloud Security{{< /prodname >}}{{< /nextlink >}} + {{< nextlink href="getting_started/security/cloud_siem" tag="documentation" >}}Getting Started with {{< prodname >}}Cloud SIEM{{< /prodname >}}{{< /nextlink >}} + {{< nextlink href="getting_started/code_security" tag="documentation" >}}Getting Started with {{< prodname >}}Code Security{{< /prodname >}}{{< /nextlink >}} + {{< nextlink href="security/workload_protection/setup" tag="documentation" >}}Setting up {{< prodname >}}Workload Protection{{< /prodname >}} {{< /nextlink >}} {{< /whatsnext >}} diff --git a/hugo/content/en/getting_started/security/application_security.md b/hugo/content/en/getting_started/security/application_security.md index 6365a8f843e..ed47ef5d4a0 100644 --- a/hugo/content/en/getting_started/security/application_security.md +++ b/hugo/content/en/getting_started/security/application_security.md @@ -26,7 +26,7 @@ site_support_id: application_security_override {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -34,7 +34,7 @@ App and API Protection is in Preview on Datadog Government site US1-FED. Datadog App and API Protection (AAP) helps secure your web applications and APIs in production. - With threat detection, Datadog provides real-time protection against attacks and attackers targeting code-level vulnerabilities. -- With [Code Security][28], Datadog detects code and library vulnerabilities in your repositories and your running services, providing end-to-end visibility from development to production. +- With [{{< prodname >}}Code Security{{< /prodname >}}][28], Datadog detects code and library vulnerabilities in your repositories and your running services, providing end-to-end visibility from development to production. This guide walks you through best practices for getting your team up and running with AAP. @@ -54,8 +54,8 @@ These security insights are detected from data reported by APM. The insights hel ## Enable AAP ### Enable AAP with in-app instructions -- To enable App and API Protection in-app, navigate to [{{< ui >}}App and API Protection{{< /ui >}} > {{< ui >}}Setup{{< /ui >}}][29]. -- To enable Code Security in-app, navigate to [{{< ui >}}Code Security{{< /ui >}} > {{< ui >}}Setup{{< /ui >}}][29]. +- To enable {{< prodname >}}App and API Protection{{< /prodname >}} in-app, navigate to [{{< ui >}}App and API Protection{{< /ui >}} > {{< ui >}}Setup{{< /ui >}}][29]. +- To enable {{< prodname >}}Code Security{{< /prodname >}} in-app, navigate to [{{< ui >}}Code Security{{< /ui >}} > {{< ui >}}Setup{{< /ui >}}][29]. {% if equals($interface, "ui") %} -5. Navigate back to the Observability Pipelines installation page and click {% ui %}Deploy{% /ui %}. +5. Navigate back to the {{< prodname >}}Observability Pipelines{{< /prodname >}} installation page and click {% ui %}Deploy{% /ui %}. {% partial file="observability_pipelines/install_the_worker/install-script-notes.mdoc.md" /%} @@ -977,7 +977,7 @@ Follow these steps to manually install the Worker, instead of running the one-li {% if equals($interface, "ui") %} -5. Navigate back to the Observability Pipelines installation page and click {% ui %}Deploy{% /ui %}. +5. Navigate back to the {{< prodname >}}Observability Pipelines{{< /prodname >}} installation page and click {% ui %}Deploy{% /ui %}. {% partial file="observability_pipelines/install_the_worker/install-script-notes.mdoc.md" /%} @@ -1074,7 +1074,7 @@ See [Network Traffic][26] for more information. ## Index your Worker logs -Make sure your Worker logs are [indexed][9] in Log Management for optimal functionality. The logs provide deployment information, such as Worker status, version, and any errors, that is shown in the UI. The logs are also helpful for troubleshooting Worker or pipelines issues. All Worker logs have the tag `source:op_worker`. +Make sure your Worker logs are [indexed][9] in {{< prodname >}}Log Management{{< /prodname >}} for optimal functionality. The logs provide deployment information, such as Worker status, version, and any errors, that is shown in the UI. The logs are also helpful for troubleshooting Worker or pipelines issues. All Worker logs have the tag `source:op_worker`. [1]: /observability_pipelines/configuration/install_the_worker/advanced_worker_configurations/#bootstrap-options [7]: /observability_pipelines/guide/environment_variables/ diff --git a/hugo/content/en/observability_pipelines/configuration/install_the_worker/advanced_worker_configurations.md b/hugo/content/en/observability_pipelines/configuration/install_the_worker/advanced_worker_configurations.md index b11b7325e40..21aaba7b5bd 100644 --- a/hugo/content/en/observability_pipelines/configuration/install_the_worker/advanced_worker_configurations.md +++ b/hugo/content/en/observability_pipelines/configuration/install_the_worker/advanced_worker_configurations.md @@ -91,7 +91,7 @@ The following is a list of bootstrap options, their related pipeline environment `tags: []` : **Pipeline environment variable**: `DD_OP_TAGS` : **Priority**: `DD_OP_TAGS` -: **Description**: The tags reported with internal metrics and can be used to filter Observability Pipelines instances for Remote Configuration deployments. +: **Description**: The tags reported with internal metrics and can be used to filter {{< prodname >}}Observability Pipelines{{< /prodname >}} instances for Remote Configuration deployments. `threads` : **Pipeline environment variable**: `DD_OP_THREADS` diff --git a/hugo/content/en/observability_pipelines/configuration/live_capture.md b/hugo/content/en/observability_pipelines/configuration/live_capture.md index 53b1d9048e1..845febc4707 100644 --- a/hugo/content/en/observability_pipelines/configuration/live_capture.md +++ b/hugo/content/en/observability_pipelines/configuration/live_capture.md @@ -49,7 +49,7 @@ If you want to use Live Capture and are using a firewall, you must add these dom ## Capture events -1. Navigate to [Observability Pipelines][3]. +1. Navigate to [{{< prodname >}}Observability Pipelines{{< /prodname >}}][3]. 1. Select your pipeline. 1. Click the cog for the source or processor that you want to capture events for. 1. Select {{< ui >}}Capture and view events{{< /ui >}} in the side panel. diff --git a/hugo/content/en/observability_pipelines/configuration/pipeline_simulation.md b/hugo/content/en/observability_pipelines/configuration/pipeline_simulation.md index 98bd6ea1f64..f234abb272c 100644 --- a/hugo/content/en/observability_pipelines/configuration/pipeline_simulation.md +++ b/hugo/content/en/observability_pipelines/configuration/pipeline_simulation.md @@ -21,7 +21,7 @@ products: ## Overview -When you configure or edit a pipeline in Observability Pipelines, you often have to update filter queries, sampling rules, or [Packs][12] that transform your telemetry. These changes can impact downstream monitors, dashboards, and detection rules. Therefore, it's important to test and validate how your changes affect your production data before you deploy those changes. +When you configure or edit a pipeline in {{< prodname >}}Observability Pipelines{{< /prodname >}}, you often have to update filter queries, sampling rules, or [Packs][12] that transform your telemetry. These changes can impact downstream monitors, dashboards, and detection rules. Therefore, it's important to test and validate how your changes affect your production data before you deploy those changes. Use Pipeline Simulation to preview how your processors, volume control rules, and [Packs][12] modify your data before deploying your pipeline configuration. This helps ensure your processors target the right data and modify it as expected. You can test your configuration with live data sent through the pipeline or import your own sample data. @@ -56,7 +56,7 @@ If you are using a firewall, add these domains to the allowlist: Before running a simulation, you need to capture sample data to test against. Pipeline Simulation lets you capture live data from an active pipeline, reuse previously captured samples, or import your own data. -1. Navigate to [Observability Pipelines][3]. +1. Navigate to [{{< prodname >}}Observability Pipelines{{< /prodname >}}][3]. 1. [Set up a new pipeline][4] or select an existing pipeline and click {{< ui >}}Edit Pipeline{{< /ui >}} on the top right side of the page. 1. On the pipeline's edit page, you can expand a processor in a processor group to view its read-only configuration. To edit any processors, capture data, and run a simulation, click {{< ui >}}Edit{{< /ui >}} on a processor group. {{< img src="observability_pipelines/pipeline_simulation/pipeline_simulation_edit_processor_group.png" alt="A pipeline's edit page with the Edit button on a processor group highlighted." style="width:100%;" >}} @@ -73,7 +73,7 @@ The status of a pipeline determines whether a simulation can be run with live da ### Capture live data from your pipeline to run a simulation with production data -For active pipelines, Observability Pipelines automatically runs a Live Capture if a previously saved capture, whether from imported data or a live capture, is not available. +For active pipelines, {{< prodname >}}Observability Pipelines{{< /prodname >}} automatically runs a Live Capture if a previously saved capture, whether from imported data or a live capture, is not available. To run a capture for a specific set of data: @@ -339,7 +339,7 @@ After you use Live Capture to pull data from your pipeline, the results are stor After you have captured data for your pipeline simulation, edit your pipeline processors and run a simulation. -1. Navigate to [Observability Pipelines][3]. +1. Navigate to [{{< prodname >}}Observability Pipelines{{< /prodname >}}][3]. 1. Select your pipeline and click {{< ui >}}Edit Pipeline{{< /ui >}} on the top right side of the page. 1. On the pipeline edit page, click {{< ui >}}Edit{{< /ui >}} on a processor group to add or edit processors in your pipeline. 1. You can: diff --git a/hugo/content/en/observability_pipelines/configuration/set_up_pipelines.md b/hugo/content/en/observability_pipelines/configuration/set_up_pipelines.md index 87ac349cc6a..062bab958f8 100644 --- a/hugo/content/en/observability_pipelines/configuration/set_up_pipelines.md +++ b/hugo/content/en/observability_pipelines/configuration/set_up_pipelines.md @@ -47,7 +47,7 @@ See [Export a Pipeline Configuration to JSON or Terraform][14] if you want to pr {{< tabs >}} {{% tab "Logs" %}} -1. Navigate to [Observability Pipelines][1]. +1. Navigate to [{{< prodname >}}Observability Pipelines{{< /prodname >}}][1]. 1. Select a [template][2] based on your use case, or click {{< ui >}}New Pipeline{{< /ui >}} and select {{< ui >}}Logs Pipeline{{< /ui >}}. 1. Select and set up a [log source][3]. 1. Select and set up [destinations][5] for your processed logs. @@ -87,7 +87,7 @@ See [Export a Pipeline Configuration to JSON or Terraform][14] if you want to pr {{% /tab %}} {{% tab "Metrics" %}} -1. Navigate to [Observability Pipelines][1]. +1. Navigate to [{{< prodname >}}Observability Pipelines{{< /prodname >}}][1]. 1. Select the [Metric Tag Governance][2] template, or click {{< ui >}}New Pipeline{{< /ui >}} and select {{< ui >}}Metrics Pipeline{{< /ui >}}. 1. Select and set up a [metrics source][3]. 1. Select and set up [destinations][5] for your processed metrics. @@ -154,7 +154,7 @@ See [Advanced Worker Configurations][5] for bootstrapping options. To clone a pipeline in the UI: -1. Navigate to [Observability Pipelines][4]. +1. Navigate to [{{< prodname >}}Observability Pipelines{{< /prodname >}}][4]. 1. Select the pipeline you want to clone. 1. Click the cog at the top right side of the page, then select {{< ui >}}Clone{{< /ui >}}. @@ -162,7 +162,7 @@ To clone a pipeline in the UI: To delete a pipeline in the UI: -1. Navigate to [Observability Pipelines][4]. +1. Navigate to [{{< prodname >}}Observability Pipelines{{< /prodname >}}][4]. 1. Select the pipeline you want to delete. 1. Click the cog at the top right side of the page, then select {{< ui >}}Delete{{< /ui >}}. diff --git a/hugo/content/en/observability_pipelines/configuration/update_existing_pipelines.md b/hugo/content/en/observability_pipelines/configuration/update_existing_pipelines.md index f1e21451b98..10c2814b049 100644 --- a/hugo/content/en/observability_pipelines/configuration/update_existing_pipelines.md +++ b/hugo/content/en/observability_pipelines/configuration/update_existing_pipelines.md @@ -7,7 +7,7 @@ aliases: ## Overview -For existing pipelines in Observability Pipelines, you can update and deploy changes for source settings, destination settings, and processors in the Observability Pipelines UI. But if you are using environment variables and want to update source and destination environment variables, you must manually update the Worker with the new values. +For existing pipelines in {{< prodname >}}Observability Pipelines{{< /prodname >}}, you can update and deploy changes for source settings, destination settings, and processors in the Observability Pipelines UI. But if you are using environment variables and want to update source and destination environment variables, you must manually update the Worker with the new values. This document goes through updating the pipeline in the UI. You can also use the [update a pipeline][2] API or [datadog_observability_pipeline][3] Terraform resource to update existing pipelines. @@ -15,7 +15,7 @@ See [Export a Pipeline Configuration to JSON or Terraform][4] if you want to pro ## Update an existing pipeline -1. Navigate to [Observability Pipelines][1]. +1. Navigate to [{{< prodname >}}Observability Pipelines{{< /prodname >}}][1]. 1. Select the pipeline you want to update. 1. Click {{< ui >}}Edit Pipeline{{< /ui >}} in the top right corner. 1. Make changes to the pipeline. diff --git a/hugo/content/en/observability_pipelines/destinations/_index.md b/hugo/content/en/observability_pipelines/destinations/_index.md index df7a2e99197..bb6280c1326 100644 --- a/hugo/content/en/observability_pipelines/destinations/_index.md +++ b/hugo/content/en/observability_pipelines/destinations/_index.md @@ -146,7 +146,7 @@ year=\%Y/month=\%m/day=\%d/ ## Event batching -Observability Pipelines destinations send events in batches to the downstream integration. A batch of events is flushed when one of the following parameters is met: +{{< prodname >}}Observability Pipelines{{< /prodname >}} destinations send events in batches to the downstream integration. A batch of events is flushed when one of the following parameters is met: - Maximum number of events - Maximum number of bytes diff --git a/hugo/content/en/observability_pipelines/destinations/amazon_s3.md b/hugo/content/en/observability_pipelines/destinations/amazon_s3.md index e91d84f1f41..72ed2d6ca97 100644 --- a/hugo/content/en/observability_pipelines/destinations/amazon_s3.md +++ b/hugo/content/en/observability_pipelines/destinations/amazon_s3.md @@ -136,7 +136,7 @@ There are no secret identifiers to configure. ## Route logs to Snowflake using the Amazon S3 destination -You can route logs from Observability Pipelines to Snowflake using the Amazon S3 destination by configuring Snowpipe in Snowflake to automatically ingest those logs. Snowpipe continuously monitors your S3 bucket for new files and automatically ingests them into your Snowflake tables, ensuring near real-time data availability for analytics or further processing. When logs are collected by Observability Pipelines, they are written to an S3 bucket. To set this up: +You can route logs from {{< prodname >}}Observability Pipelines{{< /prodname >}} to Snowflake using the Amazon S3 destination by configuring Snowpipe in Snowflake to automatically ingest those logs. Snowpipe continuously monitors your S3 bucket for new files and automatically ingests them into your Snowflake tables, ensuring near real-time data availability for analytics or further processing. When logs are collected by {{< prodname >}}Observability Pipelines{{< /prodname >}}, they are written to an S3 bucket. To set this up: 1. [Set up a pipeline][5] to use Amazon S3 as the log destination. Use the configuration detailed in [Set up the destination for your pipeline](#set-up-the-destination-for-your-pipeline). 1. Set up Snowpipe in Snowflake. See [Automating Snowpipe for Amazon S3][6] for instructions. diff --git a/hugo/content/en/observability_pipelines/destinations/azure_storage.md b/hugo/content/en/observability_pipelines/destinations/azure_storage.md index c4580a6e8f8..e88285455fa 100644 --- a/hugo/content/en/observability_pipelines/destinations/azure_storage.md +++ b/hugo/content/en/observability_pipelines/destinations/azure_storage.md @@ -15,7 +15,7 @@ Use the Azure Storage destination to send logs to an Azure Storage bucket. If yo ## Configure Log Archives -This step is only required if you want to send logs to Azure Storage in Datadog-rehydratable format for [archiving][1] and [rehydration][2], and you don't already have a Datadog Log Archive configured for Observability Pipelines. If you already have a Datadog Log Archive configured or don't want to rehydrate logs in Datadog, skip to [Set up the destination for your pipeline](#set-up-the-destination-for-your-pipeline). +This step is only required if you want to send logs to Azure Storage in Datadog-rehydratable format for [archiving][1] and [rehydration][2], and you don't already have a Datadog Log Archive configured for {{< prodname >}}Observability Pipelines{{< /prodname >}}. If you already have a Datadog Log Archive configured or don't want to rehydrate logs in Datadog, skip to [Set up the destination for your pipeline](#set-up-the-destination-for-your-pipeline). You need to have Datadog's [Azure integration][3] installed to set up Datadog Log Archives. diff --git a/hugo/content/en/observability_pipelines/destinations/databricks.md b/hugo/content/en/observability_pipelines/destinations/databricks.md index 4af7334491b..98e28cff227 100644 --- a/hugo/content/en/observability_pipelines/destinations/databricks.md +++ b/hugo/content/en/observability_pipelines/destinations/databricks.md @@ -58,7 +58,7 @@ In the Databricks workspace: GRANT CREATE TABLE ON SCHEMA . TO ; ``` -1. Run the following command to create the table that Observability Pipelines writes log data to: +1. Run the following command to create the table that {{< prodname >}}Observability Pipelines{{< /prodname >}} writes log data to: ```sql CREATE TABLE .. ( host STRING, diff --git a/hugo/content/en/observability_pipelines/destinations/datadog_archives.md b/hugo/content/en/observability_pipelines/destinations/datadog_archives.md index 7bdf018ab90..7e6b92cd8eb 100644 --- a/hugo/content/en/observability_pipelines/destinations/datadog_archives.md +++ b/hugo/content/en/observability_pipelines/destinations/datadog_archives.md @@ -156,7 +156,7 @@ There are no secret identifiers to configure. ## Route logs to Snowflake using the Datadog Archives destination -You can route logs from Observability Pipelines to Snowflake using the Datadog Archives destination by configuring Snowpipe in Snowflake to automatically ingest those logs. Snowpipe continuously monitors your S3 bucket for new files and automatically ingests them into your Snowflake tables, ensuring near real-time data availability for analytics or further processing. When logs are collected by Observability Pipelines, they are written to an S3 bucket. To set this up: +You can route logs from {{< prodname >}}Observability Pipelines{{< /prodname >}} to Snowflake using the Datadog Archives destination by configuring Snowpipe in Snowflake to automatically ingest those logs. Snowpipe continuously monitors your S3 bucket for new files and automatically ingests them into your Snowflake tables, ensuring near real-time data availability for analytics or further processing. When logs are collected by {{< prodname >}}Observability Pipelines{{< /prodname >}}, they are written to an S3 bucket. To set this up: 1. Configure [Log Archives](#configure-log-archives). 1. [Set up a pipeline][5] to use Datadog Archives as the log destination. Use the configuration detailed in [Set up the destination for your pipeline](#set-up-the-destination-for-your-pipeline). 1. Set up Snowpipe in Snowflake. See [Automating Snowpipe for Amazon S3][6] for instructions. diff --git a/hugo/content/en/observability_pipelines/destinations/datadog_byoc_logs.md b/hugo/content/en/observability_pipelines/destinations/datadog_byoc_logs.md index 2dee0add2dd..9fac1596c56 100644 --- a/hugo/content/en/observability_pipelines/destinations/datadog_byoc_logs.md +++ b/hugo/content/en/observability_pipelines/destinations/datadog_byoc_logs.md @@ -18,15 +18,15 @@ Use Observability Pipelines' BYOC (Bring Your Own Cloud) Logs destination to sen ## Prerequisites -Before configuring the destination, you need to deploy a BYOC Logs cluster. Learn how to install it in the [BYOC Logs installation section][3]. +Before configuring the destination, you need to deploy a {{< prodname >}}BYOC Logs{{< /prodname >}} cluster. Learn how to install it in the [BYOC Logs installation section][3]. ## Setup -Configure the BYOC Logs destination when you [set up a pipeline][4]. You can set up a pipeline in the [UI][1], using the [API][5], or with [Terraform][6]. The steps in this section are configured in the UI. +Configure the {{< prodname >}}BYOC Logs{{< /prodname >}} destination when you [set up a pipeline][4]. You can set up a pipeline in the [UI][1], using the [API][5], or with [Terraform][6]. The steps in this section are configured in the UI. ### Optional buffering -After you select the BYOC Logs destination in the pipeline UI, you can configure buffering. +After you select the {{< prodname >}}BYOC Logs{{< /prodname >}} destination in the pipeline UI, you can configure buffering. {{% observability_pipelines/destination_buffer %}} @@ -39,8 +39,8 @@ After you select the BYOC Logs destination in the pipeline UI, you can configure {{< tabs >}} {{% tab "Secrets Management" %}} -- BYOC Logs endpoint URL identifier: - - References the intake endpoint to which Observability Pipelines sends logs. +- {{< prodname >}}BYOC Logs{{< /prodname >}} endpoint URL identifier: + - References the intake endpoint to which {{< prodname >}}Observability Pipelines{{< /prodname >}} sends logs. - In your secrets manager: - Define the cluster URL, such as `http://byoc-logs.acme.internal:7280`. **Note**: The URL must include the port. - The Worker appends `/api/v2/logs` and `/api/v1/validate` to the endpoint URL, so these endpoints must be allowed if you are using forwarding or firewall rules. @@ -53,7 +53,7 @@ After you select the BYOC Logs destination in the pipeline UI, you can configure {{< img src="observability_pipelines/destinations/cloudprem_env_vars.png" alt="The install page showing the BYOC Logs environment variable field" style="width:75%;" >}} - BYOC Logs endpoint URL - - Observability Pipelines sends logs to the BYOC Logs intake endpoint. Define the cluster URL, such as `http://byoc-logs.acme.internal:7280`. **Note**: The URL must include the port. + - {{< prodname >}}Observability Pipelines{{< /prodname >}} sends logs to the {{< prodname >}}BYOC Logs{{< /prodname >}} intake endpoint. Define the cluster URL, such as `http://byoc-logs.acme.internal:7280`. **Note**: The URL must include the port. - The Worker appends `/api/v2/logs` and `/api/v1/validate` to the endpoint URL, so these endpoints must be allowed if you are using forwarding or firewall rules. - Stored as the environment variable: `DD_OP_DESTINATION_CLOUDPREM_ENDPOINT_URL`. diff --git a/hugo/content/en/observability_pipelines/destinations/datadog_logs.md b/hugo/content/en/observability_pipelines/destinations/datadog_logs.md index 130f80143bc..9b25f682af6 100644 --- a/hugo/content/en/observability_pipelines/destinations/datadog_logs.md +++ b/hugo/content/en/observability_pipelines/destinations/datadog_logs.md @@ -11,13 +11,13 @@ products: ## Overview -Use Observability Pipelines' Datadog Logs destination to send logs to Datadog Log Management. You can also use [AWS PrivateLink](#aws-privatelink) to send logs from Observability Pipelines to Datadog. +Use Observability Pipelines' Datadog Logs destination to send logs to Datadog Log Management. You can also use [AWS PrivateLink](#aws-privatelink) to send logs from {{< prodname >}}Observability Pipelines{{< /prodname >}} to Datadog. ## Setup Configure the Datadog Logs destination when you [set up a pipeline][4]. You can set up a pipeline in the [UI][1], using the [API][5], or with [Terraform][6]. The steps in this section are configured in the UI. -
Before routing logs through Observability Pipelines, review any indexes, pipelines, or exclusion filters that use the datadog.pipelines:false tag. For logs from a Datadog Agent source, the Datadog Logs destination sets source_type to datadog_agent (@source_type:datadog_agent in log search). Datadog then evaluates those logs as datadog_agent logs when deciding whether to apply the datadog.pipelines:false tag. To change this behavior before logs are delivered, use the Edit Fields processor or Custom Processor to remove the source_type attribute from the logs.
+
Before routing logs through {{< prodname >}}Observability Pipelines{{< /prodname >}}, review any indexes, pipelines, or exclusion filters that use the datadog.pipelines:false tag. For logs from a Datadog Agent source, the Datadog Logs destination sets source_type to datadog_agent (@source_type:datadog_agent in log search). Datadog then evaluates those logs as datadog_agent logs when deciding whether to apply the datadog.pipelines:false tag. To change this behavior before logs are delivered, use the Edit Fields processor or Custom Processor to remove the source_type attribute from the logs.
### Optional settings @@ -84,7 +84,7 @@ You can view metrics at the [component level](#component-level-metrics) or [orga To view metrics for the overall Datadog Logs destination: -1. Navigate to [Observability Pipelines][1]. +1. Navigate to [{{< prodname >}}Observability Pipelines{{< /prodname >}}][1]. 1. Select your pipeline. 1. Click the cog on the {{< ui >}}Datadog Logs{{< /ui >}} destination and select {{< ui >}}View details{{< /ui >}}. @@ -94,7 +94,7 @@ To view metrics for the overall Datadog Logs destination: To view metrics for a specific Datadog organization: -1. Navigate to [Observability Pipelines][1]. +1. Navigate to [{{< prodname >}}Observability Pipelines{{< /prodname >}}][1]. 1. Select your pipeline. 1. Click the {{< ui >}}Datadog Logs{{< /ui >}} destination so the organizations show up. {{< img src="observability_pipelines/destinations/multi_dd_orgs_highlighted.png" alt="The Datadog Logs destination showing us1 and us3 org highlighted" style="width:45%;" >}} @@ -111,7 +111,7 @@ For [component metrics][7] and [destination buffer metrics][8] emitted by all de ## AWS PrivateLink -To send logs from Observability Pipelines to Datadog using AWS PrivateLink, see [Connect to Datadog over AWS PrivateLink][1] for setup instructions. The two endpoints you need to set up are: +To send logs from {{< prodname >}}Observability Pipelines{{< /prodname >}} to Datadog using AWS PrivateLink, see [Connect to Datadog over AWS PrivateLink][1] for setup instructions. The two endpoints you need to set up are: - Logs (User HTTP intake): {{< region-param key=http_endpoint_private_link code="true" >}} - Remote Configuration: {{< region-param key=remote_config_endpoint_private_link code="true" >}} @@ -127,7 +127,7 @@ To send logs from Observability Pipelines to Datadog using AWS PrivateLink, see ## Azure Private Link -To send logs from Observability Pipelines to Datadog using Azure Private Link, see [Connect to Datadog over Azure Private Link][1] for setup instructions. The two endpoints you need to set up are: +To send logs from {{< prodname >}}Observability Pipelines{{< /prodname >}} to Datadog using Azure Private Link, see [Connect to Datadog over Azure Private Link][1] for setup instructions. The two endpoints you need to set up are: - Logs (User HTTP intake): `http-intake.logs.us3.datadoghq.com` - Remote Configuration: `config.us3.datadoghq.com` diff --git a/hugo/content/en/observability_pipelines/destinations/datadog_metrics.md b/hugo/content/en/observability_pipelines/destinations/datadog_metrics.md index c59c02c8c15..538f7a32b9e 100644 --- a/hugo/content/en/observability_pipelines/destinations/datadog_metrics.md +++ b/hugo/content/en/observability_pipelines/destinations/datadog_metrics.md @@ -12,7 +12,7 @@ products: ## Overview -Use Observability Pipelines' Datadog Metrics destination ({{< tooltip glossary="preview" case="title" >}}) to send metrics to Datadog. You can also use [AWS PrivateLink](#aws-privatelink) to send metrics from Observability Pipelines to Datadog. +Use Observability Pipelines' Datadog Metrics destination ({{< tooltip glossary="preview" case="title" >}}) to send metrics to Datadog. You can also use [AWS PrivateLink](#aws-privatelink) to send metrics from {{< prodname >}}Observability Pipelines{{< /prodname >}} to Datadog. ## Setup @@ -46,7 +46,7 @@ There are no secret identifiers for this destination. ## 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: +To send metrics from {{< prodname >}}Observability Pipelines{{< /prodname >}} 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" >}} diff --git a/hugo/content/en/observability_pipelines/destinations/google_cloud_storage.md b/hugo/content/en/observability_pipelines/destinations/google_cloud_storage.md index d0118f4a396..f235513774f 100644 --- a/hugo/content/en/observability_pipelines/destinations/google_cloud_storage.md +++ b/hugo/content/en/observability_pipelines/destinations/google_cloud_storage.md @@ -19,9 +19,9 @@ The Observability Pipelines Worker uses standard Google authentication methods. ## Configure Log Archives -This step is only required if you want to send logs to Google Cloud Storage for [archiving][1] and [rehydration][2], and you don't already have a Datadog Log Archive configured for Observability Pipelines. If you already have a Datadog Log Archive configured or do not want to rehydrate your logs in Datadog, skip to [Set up the destination for your pipeline](#set-up-the-destinations). +This step is only required if you want to send logs to Google Cloud Storage for [archiving][1] and [rehydration][2], and you don't already have a Datadog Log Archive configured for {{< prodname >}}Observability Pipelines{{< /prodname >}}. If you already have a Datadog Log Archive configured or do not want to rehydrate your logs in Datadog, skip to [Set up the destination for your pipeline](#set-up-the-destinations). -If you already have a Datadog Log Archive configured for Observability Pipelines, skip to [Set up the destination for your pipeline](#set-up-the-destination-for-your-pipeline). +If you already have a Datadog Log Archive configured for {{< prodname >}}Observability Pipelines{{< /prodname >}}, skip to [Set up the destination for your pipeline](#set-up-the-destination-for-your-pipeline). You need to have Datadog's [Google Cloud Platform integration][3] installed to set up Datadog Log Archives. diff --git a/hugo/content/en/observability_pipelines/destinations/kafka.md b/hugo/content/en/observability_pipelines/destinations/kafka.md index 8bab4291ae7..43d5f5beff8 100644 --- a/hugo/content/en/observability_pipelines/destinations/kafka.md +++ b/hugo/content/en/observability_pipelines/destinations/kafka.md @@ -23,7 +23,7 @@ Common scenarios when you might use this destination: - [Databricks][3]: A data lakehouse for analytics and storage. - [Azure Event Hub][4]: An ingest and processing service in the Microsoft and Azure ecosystem. - To route data to Kafka and use the Kafka Connect ecosystem. -- To process and normalize your data with Observability Pipelines before routing to Apache Spark with Kafka to analyze data and run machine learning workloads. +- To process and normalize your data with {{< prodname >}}Observability Pipelines{{< /prodname >}} before routing to Apache Spark with Kafka to analyze data and run machine learning workloads. ## Setup diff --git a/hugo/content/en/observability_pipelines/destinations/sentinelone.md b/hugo/content/en/observability_pipelines/destinations/sentinelone.md index b2054f967e5..1ff2261c871 100644 --- a/hugo/content/en/observability_pipelines/destinations/sentinelone.md +++ b/hugo/content/en/observability_pipelines/destinations/sentinelone.md @@ -60,7 +60,7 @@ After you've set up the pipeline to send logs to the SentinelOne destination, yo 1. Log into the [S1 console][2]. 2. Navigate to the Singularity Data Lake (SDL) {{< ui >}}Search{{< /ui >}} page. To access it from the console, click on {{< ui >}}Visibility{{< /ui >}} on the left menu to go to SDL, and make sure you're on the {{< ui >}}Search{{< /ui >}} tab. 3. Make sure the filter next to the search bar is set to {{< ui >}}All Data{{< /ui >}}. -4. This page shows the logs you sent from Observability Pipelines to SentinelOne. +4. This page shows the logs you sent from {{< prodname >}}Observability Pipelines{{< /prodname >}} to SentinelOne. ## Health metrics diff --git a/hugo/content/en/observability_pipelines/destinations/splunk_hec/logs.md b/hugo/content/en/observability_pipelines/destinations/splunk_hec/logs.md index d788021161c..878155c69a1 100644 --- a/hugo/content/en/observability_pipelines/destinations/splunk_hec/logs.md +++ b/hugo/content/en/observability_pipelines/destinations/splunk_hec/logs.md @@ -13,7 +13,7 @@ weight: 1 Use Observability Pipelines' Splunk HTTP Event Collector (HEC) destination to send logs to Splunk HEC. -**Note**: Observability Pipelines compresses logs with the gzip (level 6) algorithm. +**Note**: {{< prodname >}}Observability Pipelines{{< /prodname >}} compresses logs with the gzip (level 6) algorithm. ## Setup @@ -24,7 +24,7 @@ Configure the Splunk HEC destination when you [set up a pipeline][5]. You can se After you select the Splunk HEC destination in the pipeline UI: 1. For the {{< ui >}}Token strategy{{< /ui >}} dropdown menu: - - Only select {{< ui >}}From Source{{< /ui >}} if you are using a [Splunk HEC source][8] and have enabled {{< ui >}}Store HEC token{{< /ui >}} on the source. Otherwise, an error occurs and you cannot proceed to install the Worker. This option forwards the token received by Observability Pipelines onto the Splunk HEC destination. + - Only select {{< ui >}}From Source{{< /ui >}} if you are using a [Splunk HEC source][8] and have enabled {{< ui >}}Store HEC token{{< /ui >}} on the source. Otherwise, an error occurs and you cannot proceed to install the Worker. This option forwards the token received by {{< prodname >}}Observability Pipelines{{< /prodname >}} onto the Splunk HEC destination. - If you use the default {{< ui >}}Custom{{< /ui >}} token strategy, enter the identifier for your token. If you leave it blank, the [default](#secret-defaults) is used. 1. Enter the identifier for your endpoint URL. If you leave it blank, the [default](#secret-defaults) is used. 1. Enter the identifier for your token. If you leave it blank, the [default](#secret-defaults) is used. diff --git a/hugo/content/en/observability_pipelines/destinations/splunk_hec/metrics.md b/hugo/content/en/observability_pipelines/destinations/splunk_hec/metrics.md index 53f7e456c1c..fc8216d5ca6 100644 --- a/hugo/content/en/observability_pipelines/destinations/splunk_hec/metrics.md +++ b/hugo/content/en/observability_pipelines/destinations/splunk_hec/metrics.md @@ -19,7 +19,7 @@ Configure the Splunk HEC destination when you [set up a pipeline][1]. You can se **Notes**: - The Splunk index you send your metrics to must be a metrics index. If you send your metrics to an events index, you can't view them in Splunk using any metrics type queries, such as `mcatalog` and `mstats`. -- If you don't attach your index to the Splunk authentication token you are using for Observability Pipelines, you must enter the name of the [index](#splunk-index) when you set up the destination. +- If you don't attach your index to the Splunk authentication token you are using for {{< prodname >}}Observability Pipelines{{< /prodname >}}, you must enter the name of the [index](#splunk-index) when you set up the destination. After you select the Splunk HEC destination in the pipeline UI: @@ -42,7 +42,7 @@ To compress your metrics with gzip, select **gzip** in the dropdown menu. The de Enter the name of the Splunk metrics index to which you are sending metrics. See [template syntax][6] to route metrics to different indexes based on specific fields. -**Note**: The **Index** field is optional only if you have an index attached to the Splunk authentication token you are using for Observability Pipelines. Otherwise, you must enter the name of the Splunk metrics index. +**Note**: The **Index** field is optional only if you have an index attached to the Splunk authentication token you are using for {{< prodname >}}Observability Pipelines{{< /prodname >}}. Otherwise, you must enter the name of the Splunk metrics index. #### Source diff --git a/hugo/content/en/observability_pipelines/guide/_index.md b/hugo/content/en/observability_pipelines/guide/_index.md index c302fd05129..391d6bc1df6 100644 --- a/hugo/content/en/observability_pipelines/guide/_index.md +++ b/hugo/content/en/observability_pipelines/guide/_index.md @@ -6,7 +6,7 @@ disable_toc: false {{< whatsnext desc="General guides:" >}} {{< nextlink href="observability_pipelines/guide/strategies_for_reducing_log_volume" >}}Strategies for reducing log volume{{< /nextlink >}} {{< nextlink href="observability_pipelines/guide/environment_variables" >}}Environment variables for sources, processors, and destinations{{< /nextlink >}} - {{< nextlink href="/byoc-logs/guides/send_otel_logs_observability_pipelines" >}}Send OpenTelemetry logs to BYOC Logs with Observability Pipelines{{< /nextlink >}} + {{< nextlink href="/byoc-logs/guides/send_otel_logs_observability_pipelines" >}}Send OpenTelemetry logs to {{< prodname >}}BYOC Logs{{< /prodname >}} with {{< prodname >}}Observability Pipelines{{< /prodname >}}{{< /nextlink >}} {{< /whatsnext >}} {{< whatsnext desc="Worker Upgrade Guides" >}} diff --git a/hugo/content/en/observability_pipelines/guide/get_started_with_the_custom_processor.md b/hugo/content/en/observability_pipelines/guide/get_started_with_the_custom_processor.md index d78a58bf250..254243696f5 100644 --- a/hugo/content/en/observability_pipelines/guide/get_started_with_the_custom_processor.md +++ b/hugo/content/en/observability_pipelines/guide/get_started_with_the_custom_processor.md @@ -15,7 +15,7 @@ further_reading: ## Overview -Observability Pipelines enables you to transform your logs before sending them to your destinations. Use the Custom Processor to create scripts with custom functions that conditionally modify log fields, values, and events. +{{< prodname >}}Observability Pipelines{{< /prodname >}} enables you to transform your logs before sending them to your destinations. Use the Custom Processor to create scripts with custom functions that conditionally modify log fields, values, and events. This guide walks you through how to use the following functions in your Custom Processor script: @@ -457,7 +457,7 @@ empty_patterns = ["null", "NULL", "N/A", "n/a", "none", "NONE", "-", "undefined" ## Merge nested attributes to root level -Targeting nested objects or fields in a filter query may require you to define multiple paths. This is common when working with the message field, where the resulting parsed contents are nested in an object. When you use the Observability Pipelines' filter syntax, accessing a nested field requires the `.` notation. +Targeting nested objects or fields in a filter query may require you to define multiple paths. This is common when working with the message field, where the resulting parsed contents are nested in an object. When you use the {{< prodname >}}Observability Pipelines{{< /prodname >}}' filter syntax, accessing a nested field requires the `.` notation. For example, this log contains a stringified JSON message: diff --git a/hugo/content/en/observability_pipelines/guide/remap_reserved_attributes.md b/hugo/content/en/observability_pipelines/guide/remap_reserved_attributes.md index 0b77392c89f..f1e26fc9b7e 100644 --- a/hugo/content/en/observability_pipelines/guide/remap_reserved_attributes.md +++ b/hugo/content/en/observability_pipelines/guide/remap_reserved_attributes.md @@ -12,22 +12,22 @@ further_reading: ## Overview -Observability Pipelines' processors enable you to add, edit, and remove log fields. Remapping attributes or rewriting values ensures your logs are processed and standardized properly. For the majority of processing use cases, use the Edit Fields processor to add, remap, or remove fields from your logs. For advanced use cases, use the Custom Processor to conditionally modify fields or rewrite a field's value. +{{< prodname >}}Observability Pipelines{{< /prodname >}}' processors enable you to add, edit, and remove log fields. Remapping attributes or rewriting values ensures your logs are processed and standardized properly. For the majority of processing use cases, use the Edit Fields processor to add, remap, or remove fields from your logs. For advanced use cases, use the Custom Processor to conditionally modify fields or rewrite a field's value. -In Datadog, [reserved attributes][1] are log fields that are set aside for specific processing in the platform. Reserved attributes include ` host`, `source`, `status`, `service`, `trace_id`, and `message`. Reserved attributes are applied when routing logs to the following Observability Pipelines destinations: +In Datadog, [reserved attributes][1] are log fields that are set aside for specific processing in the platform. Reserved attributes include ` host`, `source`, `status`, `service`, `trace_id`, and `message`. Reserved attributes are applied when routing logs to the following {{< prodname >}}Observability Pipelines{{< /prodname >}} destinations: - Datadog Logs - Amazon S3 (for Log Archives) - Azure Blob Storage (for Log Archives) - Google Cloud Storage (for Log Archives) -There are restrictions in Observability Pipelines on how you can modify reserved attributes. For example, reserved attributes cannot be renamed using the Rename Field processor, but must be remapped instead. This guide walks you through the steps to remap the value of reserved attributes. +There are restrictions in {{< prodname >}}Observability Pipelines{{< /prodname >}} on how you can modify reserved attributes. For example, reserved attributes cannot be renamed using the Rename Field processor, but must be remapped instead. This guide walks you through the steps to remap the value of reserved attributes. If your specific setup uses a Splunk HEC source and Datadog destination, see [Remap source and service attributes when using the Splunk HEC source and Datadog destination](#remap-source-and-service-attributes-when-using-the-splunk-hec-source-and-datadog-destination). ## Remap the value of reserved attributes -To change or override the value of an existing reserved attribute field, Datadog recommends two approaches using Observability Pipelines. The first uses the Edit Fields processor, and the second uses the Custom Processor. +To change or override the value of an existing reserved attribute field, Datadog recommends two approaches using {{< prodname >}}Observability Pipelines{{< /prodname >}}. The first uses the Edit Fields processor, and the second uses the Custom Processor. ### Use an Edit Fields processor for basic field assignments diff --git a/hugo/content/en/observability_pipelines/guide/strategies_for_reducing_log_volume.md b/hugo/content/en/observability_pipelines/guide/strategies_for_reducing_log_volume.md index bff4bf039c1..b5082aaa165 100644 --- a/hugo/content/en/observability_pipelines/guide/strategies_for_reducing_log_volume.md +++ b/hugo/content/en/observability_pipelines/guide/strategies_for_reducing_log_volume.md @@ -12,7 +12,7 @@ further_reading: ## Overview -Observability Pipelines allows you to collect and process logs, as well as determine where you want to route them, all before the data leaves your on-premises or cloud environment. +{{< prodname >}}Observability Pipelines{{< /prodname >}} allows you to collect and process logs, as well as determine where you want to route them, all before the data leaves your on-premises or cloud environment. Logs are not equal value. For example, error logs are often more useful than info logs when troubleshooting live operations. Logs from production environments are also more important than logs from non-production environments. Therefore, routing all of your logs to an indexed solution can dilute the overall value of your data and cause you to exceed your budget. @@ -23,7 +23,7 @@ The following situations can also unnecessarily increase your log volume and cos - Teams attempt to add as much performance and metric data into the logs because it seems easier than implementing other telemetry solutions. - Logs contain extra fields and values that are never used. -This guide walks you through strategies on how to reduce your log volume using Observability Pipelines' processors, so that you can stay cost-compliant and increase the value of your stored data. +This guide walks you through strategies on how to reduce your log volume using {{< prodname >}}Observability Pipelines{{< /prodname >}}' processors, so that you can stay cost-compliant and increase the value of your stored data. ## Strategies for reducing your log volume diff --git a/hugo/content/en/observability_pipelines/guide/upgrade_worker.md b/hugo/content/en/observability_pipelines/guide/upgrade_worker.md index 11ddbdd6613..ef47dfe7257 100644 --- a/hugo/content/en/observability_pipelines/guide/upgrade_worker.md +++ b/hugo/content/en/observability_pipelines/guide/upgrade_worker.md @@ -104,7 +104,7 @@ Worker version 2.19.0 gives you access to the following: #### Enhancements -- A `server_name` TLS option has been added to the BYOC Logs, HTTP Client, Socket, and Syslog destinations, and to the HTTP Client source. It overrides the SNI and certificate hostname used for the TLS handshake, which is applicable when the dialed address does not match the certificate's Common Name or Subject Alternative Name. +- A `server_name` TLS option has been added to the {{< prodname >}}BYOC Logs{{< /prodname >}}, HTTP Client, Socket, and Syslog destinations, and to the HTTP Client source. It overrides the SNI and certificate hostname used for the TLS handshake, which is applicable when the dialed address does not match the certificate's Common Name or Subject Alternative Name. - The Splunk TCP source now supports hot-reloading TLS certificates, so certificate rotations are applied without restarting the Worker. - The BYOC Logs destination now supports hot-reloading mTLS files. - The Worker now supports a configurable graceful shutdown limit. @@ -140,7 +140,7 @@ Worker version 2.18.0 gives you access to the following: #### Enhancements -- mTLS support has been added to the BYOC Logs destination. +- mTLS support has been added to the {{< prodname >}}BYOC Logs{{< /prodname >}} destination. - The `measure_cpu_usage` option is now enabled, so that `pipelines.component_cpu_usage_ns_total` is always emitted for the following log processors: Custom Processor, Sensitive Data Scanner, Grok Parser, Parse JSON, Parse XML, OCSF Mapper, Enrichment Table, Reduce, Dedupe, Split Array, and Throttle; and the following metrics processors: Aggregate and Tag Cardinality Limit. - Pipeline configuration errors now include the ID of the component that caused the failure. This makes it easier to identify which source, processor, or destination needs correcting. For processors made up of multiple blocks, such as the Custom Processor, Generate Metrics, and OCSF Mapper, the error also identifies which individual block failed, including its position and, where the block has one, its name. - Pipeline metrics are now tagged with the pipeline name using `pipeline_name:`. @@ -306,11 +306,11 @@ Worker version 2.15.0 gives you access to the following: - The `parse_yaml` function is now available for the Custom Processor. This function parses YAML according to the [YAML 1.1 spec][41]. - The Enrichment Table file option now supports a `field` option that accepts an event field path or a metadata secret as the lookup key source. Plain text is supported for backwards compatibility. - Explicit event path example: - - Observability Pipelines simplified syntax: `field: {event: "message"}` + - {{< prodname >}}Observability Pipelines{{< /prodname >}} simplified syntax: `field: {event: "message"}` - VRL syntax for the Custom Processor: `field: {vrl: ".message"}` - Metadata secret reference example: `field: {secret: "splunk_hec_token"}` - Plain string (for backwards compatibility): - - Observability Pipelines simplified syntax: `field: "message"` + - {{< prodname >}}Observability Pipelines{{< /prodname >}} simplified syntax: `field: "message"` - VRL syntax for the Custom Processor: `field: ".message"` #### Enhancements @@ -436,7 +436,7 @@ Worker version 2.13.0 gives you access to the following: #### New features - [Custom Processor][24] for metrics: Use VRL to transform metric events. -- [Secrets Management][31]: Observability Pipelines can retrieve secrets using Datadog Secrets Management. +- [Secrets Management][31]: {{< prodname >}}Observability Pipelines{{< /prodname >}} can retrieve secrets using Datadog Secrets Management. - [Live capture][25] is available for metrics pipelines. - The [Enrichment Tables][28] processor can use datasets in Reference Tables. @@ -482,7 +482,7 @@ Worker version 2.12.0 gives you access to the following: #### New features - [HTTP destination][29] for metrics pipelines: Routes metrics to an HTTP client endpoint. -- [MySQL Source][30]: Sends logs from a MySQL database to Observability Pipelines. +- [MySQL Source][30]: Sends logs from a MySQL database to {{< prodname >}}Observability Pipelines{{< /prodname >}}. #### Enhancements @@ -537,7 +537,7 @@ Worker version 2.10.0 gives you access to the following: #### New features -- [Kafka destination][5]: Send logs from Observability Pipelines to your Kafka topics. +- [Kafka destination][5]: Send logs from {{< prodname >}}Observability Pipelines{{< /prodname >}} to your Kafka topics. - New and updated [Custom Processor functions][6]: - The `pop` function removes the last item from an array. - The cryptographic functions `encrypt_ip` and `decrypt_ip` for IP address encryption. @@ -550,7 +550,7 @@ Worker version 2.10.0 gives you access to the following: - When `strict_mode` is set to `false`, the parser ignores any newly added or trailing fields in AWS ALB logs, instead of failing. - Defaults to `true` to preserve current behavior. - [Metrics pipelines][32]: - - [Datadog Agent source][33]: Send metrics from the Datadog Agent to Observability Pipelines for processing. + - [Datadog Agent source][33]: Send metrics from the Datadog Agent to {{< prodname >}}Observability Pipelines{{< /prodname >}} for processing. - [Filter processor][35]: Filter the metrics you want to process. - [Tag processor][36]: Include or exclude specific tags in your metrics. - [Datadog Metrics destination][34]: Send your processed metrics Datadog. @@ -597,9 +597,9 @@ Worker version 2.9.0 gives you access to the following: #### New features -- [OpenTelemetry Collector source][10]: Ingest logs from your OpenTelemetry Collector into Observability Pipelines. +- [OpenTelemetry Collector source][10]: Ingest logs from your OpenTelemetry Collector into {{< prodname >}}Observability Pipelines{{< /prodname >}}. - [Datadog BYOC Logs destination][11]: Route logs to the Datadog BYOC Logs destination. -- [Google Pub/Sub destination][12]: Send logs from Observability Pipelines to the Google Pub/Sub messaging system. +- [Google Pub/Sub destination][12]: Send logs from {{< prodname >}}Observability Pipelines{{< /prodname >}} to the Google Pub/Sub messaging system. - The `haversine` custom function to calculate haversine distance and bearing. #### Enhancements diff --git a/hugo/content/en/observability_pipelines/legacy/_index.md b/hugo/content/en/observability_pipelines/legacy/_index.md index bec69f26d98..1b684cfb37c 100644 --- a/hugo/content/en/observability_pipelines/legacy/_index.md +++ b/hugo/content/en/observability_pipelines/legacy/_index.md @@ -79,7 +79,7 @@ The following documents are for the Observability Pipelines Worker 1.8 and older ## Overview -Observability Pipelines allow you to collect, process, and route logs from any source to any destination in infrastructure that you own or manage. +{{< prodname >}}Observability Pipelines{{< /prodname >}} allow you to collect, process, and route logs from any source to any destination in infrastructure that you own or manage. With Observability Pipelines, you can: @@ -101,12 +101,12 @@ The Datadog UI provides a control plane to manage your Observability Pipelines W 1. [Set up the Observability Pipelines Worker][1]. 2. [Create pipelines to collect, transform and route your data][2]. 3. Discover how to deploy Observability Pipelines at production scale: - - See [Deployment Design and Principles][3] for information on what to consider when designing your Observability Pipelines architecture. + - See [Deployment Design and Principles][3] for information on what to consider when designing your {{< prodname >}}Observability Pipelines{{< /prodname >}} architecture. - See [Best Practices for OP Worker Aggregator Architecture][4]. ## Explore Observability Pipelines -Start getting insights into your Observability Pipelines: +Start getting insights into your {{< prodname >}}Observability Pipelines{{< /prodname >}}: ### Collect data from any source and route data to any destination diff --git a/hugo/content/en/observability_pipelines/legacy/architecture/availability_disaster_recovery.md b/hugo/content/en/observability_pipelines/legacy/architecture/availability_disaster_recovery.md index 273119aaaa7..4bd5d50a817 100644 --- a/hugo/content/en/observability_pipelines/legacy/architecture/availability_disaster_recovery.md +++ b/hugo/content/en/observability_pipelines/legacy/architecture/availability_disaster_recovery.md @@ -8,7 +8,7 @@ aliases: This guide is for large-scale production-level deployments.
-In the context of Observability Pipelines, high availability refers to the Observability Pipelines Worker remaining available if there are any system issues. +In the context of {{< prodname >}}Observability Pipelines{{< /prodname >}}, high availability refers to the Observability Pipelines Worker remaining available if there are any system issues. {{< img src="observability_pipelines/production_deployment_overview/high_availability.png" alt="A diagram showing availability zone one with load balancer one offline, and both agents sending data to load balancer two and then to Worker one and Worker two. In availability zone two, Worker three is down, so both load balancers are sending data to Worker N" style="width:65%;" >}} diff --git a/hugo/content/en/observability_pipelines/legacy/configurations.md b/hugo/content/en/observability_pipelines/legacy/configurations.md index eda9bfb12cc..62290440293 100644 --- a/hugo/content/en/observability_pipelines/legacy/configurations.md +++ b/hugo/content/en/observability_pipelines/legacy/configurations.md @@ -179,7 +179,7 @@ See the [Sinks documentation][3] for all supported sinks. ## Put it all together -With these three basic components, a source, transform, and sink, you now have a working Observability Pipelines configuration file. +With these three basic components, a source, transform, and sink, you now have a working {{< prodname >}}Observability Pipelines{{< /prodname >}} configuration file. {{< tabs >}} {{% tab "YAML" %}} diff --git a/hugo/content/en/observability_pipelines/legacy/guide/control_log_volume_and_size.md b/hugo/content/en/observability_pipelines/legacy/guide/control_log_volume_and_size.md index 2f8e1841129..5f85e68aa33 100644 --- a/hugo/content/en/observability_pipelines/legacy/guide/control_log_volume_and_size.md +++ b/hugo/content/en/observability_pipelines/legacy/guide/control_log_volume_and_size.md @@ -14,7 +14,7 @@ further_reading: ## Overview -Because your log volume grows as your organization scales, the cost of ingesting and indexing in your downstream services (for example, log management solutions, SIEMs, and so forth) also rises. This guide walks you through using Observability Pipelines' transforms to cut down on log volume and trim down the size of your logs to control your costs *before* data leaves your infrastructure or network. +Because your log volume grows as your organization scales, the cost of ingesting and indexing in your downstream services (for example, log management solutions, SIEMs, and so forth) also rises. This guide walks you through using {{< prodname >}}Observability Pipelines{{< /prodname >}}' transforms to cut down on log volume and trim down the size of your logs to control your costs *before* data leaves your infrastructure or network. ## Prerequisites - You have [installed and configured the Observability Pipelines Worker][1] to collect data from your sources and route it to your destinations. diff --git a/hugo/content/en/observability_pipelines/legacy/guide/ingest_aws_s3_logs_with_the_observability_pipelines_worker.md b/hugo/content/en/observability_pipelines/legacy/guide/ingest_aws_s3_logs_with_the_observability_pipelines_worker.md index b6af740aac6..22ae5c8f48c 100644 --- a/hugo/content/en/observability_pipelines/legacy/guide/ingest_aws_s3_logs_with_the_observability_pipelines_worker.md +++ b/hugo/content/en/observability_pipelines/legacy/guide/ingest_aws_s3_logs_with_the_observability_pipelines_worker.md @@ -115,7 +115,7 @@ Create a separate IAM role for the Worker so that only the necessary permissions 11. Enter a name for the policy. 12. Click **Create policy**. -Apply the role to the running Observability Pipelines process. You can do this by attaching the role to an EC2 instance or assuming a role from a given user profile. +Apply the role to the running {{< prodname >}}Observability Pipelines{{< /prodname >}} process. You can do this by attaching the role to an EC2 instance or assuming a role from a given user profile. ## Configure the Worker to receive notifications from the SQS queue diff --git a/hugo/content/en/observability_pipelines/legacy/guide/route_logs_in_datadog_rehydratable_format_to_Amazon_S3.md b/hugo/content/en/observability_pipelines/legacy/guide/route_logs_in_datadog_rehydratable_format_to_Amazon_S3.md index 0f7d54e0df8..0b7430ff655 100644 --- a/hugo/content/en/observability_pipelines/legacy/guide/route_logs_in_datadog_rehydratable_format_to_Amazon_S3.md +++ b/hugo/content/en/observability_pipelines/legacy/guide/route_logs_in_datadog_rehydratable_format_to_Amazon_S3.md @@ -22,7 +22,7 @@ further_reading: The Observability Pipelines `datadog_archives` destination formats logs into a Datadog-rehydratable format and then routes them to [Log Archives][1]. These logs are not ingested into Datadog, but are routed directly to the archive. You can then rehydrate the archive in Datadog when you need to analyze and investigate them. The Observability Pipelines Datadog Archives destination is useful when: -- You have a high volume of noisy logs, but you may need to index them in Log Management ad hoc. +- You have a high volume of noisy logs, but you may need to index them in {{< prodname >}}Log Management{{< /prodname >}} ad hoc. - You have a retention policy. For example in this first diagram, some logs are sent to a cloud storage for archiving and others to Datadog for analysis and investigation. However, the logs sent directly to cloud storage cannot be rehydrated in Datadog when you need to investigate them. diff --git a/hugo/content/en/observability_pipelines/legacy/guide/sensitive_data_scanner_transform.md b/hugo/content/en/observability_pipelines/legacy/guide/sensitive_data_scanner_transform.md index 74eeb573d6b..bd9fa24e72f 100644 --- a/hugo/content/en/observability_pipelines/legacy/guide/sensitive_data_scanner_transform.md +++ b/hugo/content/en/observability_pipelines/legacy/guide/sensitive_data_scanner_transform.md @@ -20,11 +20,11 @@ The sensitive_data_scanner transform is in private beta. ## Overview -Sensitive data, such as credit card numbers, bank routing numbers, and API keys, can be revealed unintentionally in your logs, which can expose your organization to financial and privacy risks. Use the Observability Pipelines `sensitive_data_scanner` transform to identify, tag, and optionally redact or hash sensitive information before routing data to different destinations. You can use out-of-the-box scanning rules to detect common patterns such as email addresses, credit card numbers, API keys, authorization tokens, and more. Or, create custom scanning rules using regex patterns to match sensitive information. +Sensitive data, such as credit card numbers, bank routing numbers, and API keys, can be revealed unintentionally in your logs, which can expose your organization to financial and privacy risks. Use the {{< prodname >}}Observability Pipelines{{< /prodname >}} `sensitive_data_scanner` transform to identify, tag, and optionally redact or hash sensitive information before routing data to different destinations. You can use out-of-the-box scanning rules to detect common patterns such as email addresses, credit card numbers, API keys, authorization tokens, and more. Or, create custom scanning rules using regex patterns to match sensitive information. ## Set up the `sensitive_data_scanner` transform -1. Navigate to [Observability Pipelines][1]. +1. Navigate to [{{< prodname >}}Observability Pipelines{{< /prodname >}}][1]. 1. Click on your pipeline. 1. Click **Edit as Draft**. 1. Click **+ Add Component**. @@ -52,7 +52,7 @@ Sensitive data, such as credit card numbers, bank routing numbers, and API keys, 1. If you want to add another rule, click **Add a New Item** and follow steps 10 to 14. 1. Click **Save**. -**Note**: Any rules that you add or update only affect data coming into Observability Pipelines after the rule was defined. +**Note**: Any rules that you add or update only affect data coming into {{< prodname >}}Observability Pipelines{{< /prodname >}} after the rule was defined. ### Using regex for custom rules diff --git a/hugo/content/en/observability_pipelines/legacy/guide/set_quotas_for_data_sent_to_a_destination.md b/hugo/content/en/observability_pipelines/legacy/guide/set_quotas_for_data_sent_to_a_destination.md index 30551ed4174..392011581de 100644 --- a/hugo/content/en/observability_pipelines/legacy/guide/set_quotas_for_data_sent_to_a_destination.md +++ b/hugo/content/en/observability_pipelines/legacy/guide/set_quotas_for_data_sent_to_a_destination.md @@ -23,7 +23,7 @@ The quota transform is in private beta. ## Overview -Use the Observability Pipelines `quota` transform to limit the volume of data or number of events sent to a destination within a specific timeframe. This can safeguard you from unexpected data surges that might impact your operating costs. With the transform, you can set up different ways of handling the data when the quota has been reached. For example, you can: +Use the {{< prodname >}}Observability Pipelines{{< /prodname >}} `quota` transform to limit the volume of data or number of events sent to a destination within a specific timeframe. This can safeguard you from unexpected data surges that might impact your operating costs. With the transform, you can set up different ways of handling the data when the quota has been reached. For example, you can: - Set a soft limit by setting up a monitor to alert you when the quota has been reached. - Reroute the data sent after the quota limit to another destination, such as a cold storage. @@ -40,7 +40,7 @@ This guide walks you through how to: ## Set up the quota transform -1. Navigate to [Observability Pipelines][1]. +1. Navigate to [{{< prodname >}}Observability Pipelines{{< /prodname >}}][1]. 1. Click on your pipeline. 1. Click **Edit draft**. 1. Click **+ Add Component**. @@ -156,7 +156,7 @@ To set up a monitor to alert when the quota is reached: The Observability Pipelines `datadog_archives` destination formats logs into a Datadog-rehydratable format and then routes it to [Log Archives][12]. See [Route Logs in Datadog-Rehydratable Format to Amazon S3][13] to set up `datadog_archives`. -The example configuration below is similar to the previous [example configuration](#handling-data-sent-after-the-limit), except the destination type is `datadog_archives`. All logs sent to Observability Pipelines after the quota is reached are routed to the archives. +The example configuration below is similar to the previous [example configuration](#handling-data-sent-after-the-limit), except the destination type is `datadog_archives`. All logs sent to {{< prodname >}}Observability Pipelines{{< /prodname >}} after the quota is reached are routed to the archives. ```yaml sources: diff --git a/hugo/content/en/observability_pipelines/legacy/monitoring.md b/hugo/content/en/observability_pipelines/legacy/monitoring.md index 11ac33537a6..5e331901f94 100644 --- a/hugo/content/en/observability_pipelines/legacy/monitoring.md +++ b/hugo/content/en/observability_pipelines/legacy/monitoring.md @@ -5,7 +5,7 @@ disable_toc: false ## Overview -In [Observability Pipelines][1], your pipelines are comprised of components that collect, process, and route your observability data. The health of your pipelines and components are indicated by health statuses and graphs, as well as resource utilization and data delivery graphs. +In [{{< prodname >}}Observability Pipelines{{< /prodname >}}][1], your pipelines are comprised of components that collect, process, and route your observability data. The health of your pipelines and components are indicated by health statuses and graphs, as well as resource utilization and data delivery graphs. Health statuses are determined by specific metrics based on thresholds and default time windows. The available statuses are as follows: @@ -33,7 +33,7 @@ Resource utilization graphs are available for the following metrics: ## See the status of your pipelines and components -1. Navigate to [Observability Pipelines][3]. +1. Navigate to [{{< prodname >}}Observability Pipelines{{< /prodname >}}][3]. 1. Click on a pipeline. 1. Hover over the graphs to see specific data points. diff --git a/hugo/content/en/observability_pipelines/legacy/production_deployment_overview.md b/hugo/content/en/observability_pipelines/legacy/production_deployment_overview.md index 917d11abb11..2c053993248 100644 --- a/hugo/content/en/observability_pipelines/legacy/production_deployment_overview.md +++ b/hugo/content/en/observability_pipelines/legacy/production_deployment_overview.md @@ -144,4 +144,4 @@ Optimize your system of analysis for analysis while reducing costs by doing the --- - * Observability Pipelines support logs. Support for metrics is in beta. \ No newline at end of file + * {{< prodname >}}Observability Pipelines{{< /prodname >}} support logs. Support for metrics is in beta. \ No newline at end of file diff --git a/hugo/content/en/observability_pipelines/legacy/reference/sources.md b/hugo/content/en/observability_pipelines/legacy/reference/sources.md index b10301e602b..a35fab73bd0 100644 --- a/hugo/content/en/observability_pipelines/legacy/reference/sources.md +++ b/hugo/content/en/observability_pipelines/legacy/reference/sources.md @@ -7,4 +7,4 @@ aliases: - /observability_pipelines/reference/sources/ --- -A source is where data is collected and sent to Observability Pipelines. The source component in a configuration defines how Observability Pipelines collects or receives data from the source. +A source is where data is collected and sent to {{< prodname >}}Observability Pipelines{{< /prodname >}}. The source component in a configuration defines how {{< prodname >}}Observability Pipelines{{< /prodname >}} collects or receives data from the source. diff --git a/hugo/content/en/observability_pipelines/legacy/setup/_index.md b/hugo/content/en/observability_pipelines/legacy/setup/_index.md index b1878c5da33..19ed1f3103a 100644 --- a/hugo/content/en/observability_pipelines/legacy/setup/_index.md +++ b/hugo/content/en/observability_pipelines/legacy/setup/_index.md @@ -48,7 +48,7 @@ To install the Observability Pipelines Worker, you need the following: To generate a new API key and pipeline: -1. Navigate to [Observability Pipelines][6]. +1. Navigate to [{{< prodname >}}Observability Pipelines{{< /prodname >}}][6]. 2. Click **New Pipeline**. 3. Enter a name for your pipeline. 4. Click **Next**. @@ -78,7 +78,7 @@ The Observability Pipelines Worker Docker image is published to Docker Hub [here datadog/observability-pipelines-worker run ``` - Replace `` with your Datadog API key, `` with your Observability Pipelines configuration ID, and `` with {{< region-param key="dd_site" code="true" >}}. **Note**: `./pipeline.yaml` must be the relative or absolute path to the configuration you downloaded in step 1. + Replace `` with your Datadog API key, `` with your {{< prodname >}}Observability Pipelines{{< /prodname >}} configuration ID, and `` with {{< region-param key="dd_site" code="true" >}}. **Note**: `./pipeline.yaml` must be the relative or absolute path to the configuration you downloaded in step 1. [1]: https://hub.docker.com/r/datadog/observability-pipelines-worker [2]: /resources/yaml/observability_pipelines/quickstart/pipeline.yaml @@ -310,7 +310,7 @@ The quickstart walked you through installing the Worker and deploying a sample p For recommendations on deploying and scaling multiple Workers: -- See [Deployment Design and Principles][9] for information on what to consider when designing your Observability Pipelines architecture. +- See [Deployment Design and Principles][9] for information on what to consider when designing your {{< prodname >}}Observability Pipelines{{< /prodname >}} architecture. - See [Best Practices for OP Worker Aggregator Architecture][10]. ## Further reading diff --git a/hugo/content/en/observability_pipelines/legacy/setup/datadog.md b/hugo/content/en/observability_pipelines/legacy/setup/datadog.md index ed7ffd82871..929a2c3d871 100644 --- a/hugo/content/en/observability_pipelines/legacy/setup/datadog.md +++ b/hugo/content/en/observability_pipelines/legacy/setup/datadog.md @@ -31,7 +31,7 @@ This guide walks you through deploying the Worker in your common tools cluster a {{% op-deployment-modes %}} ## Assumptions -* You are already using Datadog and want to use Observability Pipelines. +* You are already using Datadog and want to use {{< prodname >}}Observability Pipelines{{< /prodname >}}. * You have administrative access to the clusters where the Observability Pipelines Worker is going to be deployed, as well as to the workloads that are going to be aggregated. * You have a common tools or security cluster for your environment to which all other clusters are connected. @@ -41,7 +41,7 @@ Before installing, make sure you have: * A valid [Datadog API key][2]. * A Pipeline ID. -You can generate both of these in [Observability Pipelines][3]. +You can generate both of these in [{{< prodname >}}Observability Pipelines{{< /prodname >}}][3]. ### Provider-specific requirements {{< tabs >}} @@ -136,7 +136,7 @@ The Observability Pipelines Worker Docker image is published to Docker Hub [here -v ./pipeline.yaml:/etc/observability-pipelines-worker/pipeline.yaml:ro \ datadog/observability-pipelines-worker run ``` - Replace `` with your Datadog API key, `` with your Observability Pipelines configuration ID, and `` with {{< region-param key="dd_site" code="true" >}}. `./pipeline.yaml` must be the relative or absolute path to the configuration you downloaded in Step 1. + Replace `` with your Datadog API key, `` with your {{< prodname >}}Observability Pipelines{{< /prodname >}} configuration ID, and `` with {{< region-param key="dd_site" code="true" >}}. `./pipeline.yaml` must be the relative or absolute path to the configuration you downloaded in Step 1. [1]: https://hub.docker.com/r/datadog/observability-pipelines-worker [2]: /resources/yaml/observability_pipelines/datadog/pipeline.yaml @@ -412,7 +412,7 @@ An NLB is provisioned by the CloudFormation template, and is configured to point {{< /tabs >}} ### Buffering -Observability Pipelines includes multiple buffering strategies that allow you to increase the resilience of your cluster to downstream faults. The provided sample configurations use disk buffers, the capacities of which are rated for approximately 10 minutes of data at 10Mbps/core for Observability Pipelines deployments. That is often enough time for transient issues to resolve themselves, or for incident responders to decide what needs to be done with the observability data. +{{< prodname >}}Observability Pipelines{{< /prodname >}} includes multiple buffering strategies that allow you to increase the resilience of your cluster to downstream faults. The provided sample configurations use disk buffers, the capacities of which are rated for approximately 10 minutes of data at 10Mbps/core for {{< prodname >}}Observability Pipelines{{< /prodname >}} deployments. That is often enough time for transient issues to resolve themselves, or for incident responders to decide what needs to be done with the observability data. {{< tabs >}} {{% tab "Docker" %}} @@ -473,10 +473,10 @@ At this point, your observability data should be going to the Worker and is avai {{% op-updating-deployment-modes %}} ## Working with data -The sample configuration provided has example processing steps that demonstrate Observability Pipelines tools and ensures that data sent to Datadog is in the correct format. +The sample configuration provided has example processing steps that demonstrate {{< prodname >}}Observability Pipelines{{< /prodname >}} tools and ensures that data sent to Datadog is in the correct format. ### Processing logs -The sample Observability Pipelines configuration does the following: +The sample {{< prodname >}}Observability Pipelines{{< /prodname >}} configuration does the following: - Collects logs sent from the Datadog agent to the Observability Pipelines Worker. - Tags logs coming through the Observability Pipelines Worker. This helps determine what traffic still needs to be shifted over to the Worker as you update your clusters. These tags also show you how logs are being routed through the load balancer, in case there are imbalances. - Corrects the status of logs coming through the Worker. Due to how the Datadog Agent collects logs from containers, the provided `.status` attribute does not properly reflect the actual level of the message. It is removed to prevent issues with parsing rules in the backend, where logs are received from the Worker. @@ -487,7 +487,7 @@ The following are two important components in the example configuration: Internally, the Datadog Agent represents log tags as a CSV in a single string. To effectively manipulate these tags, they must be parsed, modified, and then re-encoded before they are sent to the ingest endpoint. These steps are written to automatically perform those actions for you. Any modifications you make to the pipeline, especially for manipulating tags, should be in between these two steps. -At this point, your environment is configured for Observability Pipelines with data flowing through it. Further configuration is likely required for your specific use cases, but the tools provided give you a starting point. +At this point, your environment is configured for {{< prodname >}}Observability Pipelines{{< /prodname >}} with data flowing through it. Further configuration is likely required for your specific use cases, but the tools provided give you a starting point. ## Further reading {{< partial name="whats-next/whats-next.html" >}} diff --git a/hugo/content/en/observability_pipelines/legacy/setup/datadog_with_archiving.md b/hugo/content/en/observability_pipelines/legacy/setup/datadog_with_archiving.md index 5f8701865ab..5f41e40d800 100644 --- a/hugo/content/en/observability_pipelines/legacy/setup/datadog_with_archiving.md +++ b/hugo/content/en/observability_pipelines/legacy/setup/datadog_with_archiving.md @@ -24,7 +24,7 @@ This guide walks you through deploying the Worker in your common tools cluster a {{% op-deployment-modes %}} ## Assumptions -* You are already using Datadog and want to use Observability Pipelines. +* You are already using Datadog and want to use {{< prodname >}}Observability Pipelines{{< /prodname >}}. * You have administrative access to the clusters where the Observability Pipelines Worker is going to be deployed, as well as to the workloads that are going to be aggregated. * You have a common tools cluster or security cluster for your environment to which all other clusters are connected. @@ -34,7 +34,7 @@ Before installing, make sure you have: * A valid [Datadog API key][2]. * A Pipeline ID. -You can generate both of these in [Observability Pipelines][3]. +You can generate both of these in [{{< prodname >}}Observability Pipelines{{< /prodname >}}][3]. ### Provider-specific requirements {{< tabs >}} @@ -192,7 +192,7 @@ The Observability Pipelines Worker Docker image is published to Docker Hub [here Replace these placeholders with the following information: - `` with your Datadog API key. - - `` with your Observability Pipelines configuration ID. + - `` with your {{< prodname >}}Observability Pipelines{{< /prodname >}} configuration ID. - `` with {{< region-param key="dd_site" code="true" >}}. - `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` with the AWS credentials you created earlier. - `` with the name of the S3 bucket storing the logs. @@ -208,7 +208,7 @@ The Observability Pipelines Worker Docker image is published to Docker Hub [here 2. In the Helm chart, replace these placeholders with the following information: - `datadog.apiKey` with your Datadog API key. - - `datadog.pipelineId` with your Observability Pipelines configuration ID. + - `datadog.pipelineId` with your {{< prodname >}}Observability Pipelines{{< /prodname >}} configuration ID. - `site` with {{< region-param key="dd_site" code="true" >}}. - `${DD_ARCHIVES_SERVICE_ACCOUNT}` in `serviceAccount.name` with the service account name. - `${DD_ARCHIVES_BUCKET}` in `pipelineConfig.sinks.datadog_archives` with the name of the S3 bucket storing the logs. @@ -382,7 +382,7 @@ The Terraform module provisions an NLB to point at the instances. The DNS addres {{< /tabs >}} ### Buffering -Observability Pipelines includes multiple buffering strategies that allow you to increase the resilience of your cluster to downstream faults. The provided sample configurations use disk buffers, the capacities of which are rated for approximately 10 minutes of data at 10Mbps/core for Observability Pipelines deployments. That is often enough time for transient issues to resolve themselves, or for incident responders to decide what needs to be done with the observability data. +{{< prodname >}}Observability Pipelines{{< /prodname >}} includes multiple buffering strategies that allow you to increase the resilience of your cluster to downstream faults. The provided sample configurations use disk buffers, the capacities of which are rated for approximately 10 minutes of data at 10Mbps/core for {{< prodname >}}Observability Pipelines{{< /prodname >}} deployments. That is often enough time for transient issues to resolve themselves, or for incident responders to decide what needs to be done with the observability data. {{< tabs >}} {{% tab "Docker" %}} diff --git a/hugo/content/en/observability_pipelines/legacy/setup/splunk.md b/hugo/content/en/observability_pipelines/legacy/setup/splunk.md index dd17e2e2ece..35d8a9e9604 100644 --- a/hugo/content/en/observability_pipelines/legacy/setup/splunk.md +++ b/hugo/content/en/observability_pipelines/legacy/setup/splunk.md @@ -18,7 +18,7 @@ further_reading: {{% observability_pipelines/legacy_warning %}} -
Observability Pipelines only supports Splunk's HTTP Event Collector (HEC) protocol.
+
{{< prodname >}}Observability Pipelines{{< /prodname >}} only supports Splunk's HTTP Event Collector (HEC) protocol.
## Overview @@ -40,7 +40,7 @@ Before installing, make sure you have: * A valid [Datadog API key][2]. * A Pipeline ID. -You can generate both of these in [Observability Pipelines][3]. +You can generate both of these in [{{< prodname >}}Observability Pipelines{{< /prodname >}}][3]. ### Provider-specific requirements @@ -120,7 +120,7 @@ In order to run the Worker in your AWS account, you need administrative access t ## Setting up the Splunk index -
Observability Pipelines supports acknowledgments when you enable the Enable Indexer Acknowledgments setting on the input.
+
{{< prodname >}}Observability Pipelines{{< /prodname >}} supports acknowledgments when you enable the Enable Indexer Acknowledgments setting on the input.
To receive logs from the Observability Pipelines Worker, you must provision a HEC input and HEC token on the index. @@ -151,7 +151,7 @@ The Observability Pipelines Worker Docker image is published to Docker Hub [here -v ./pipeline.yaml:/etc/observability-pipelines-worker/pipeline.yaml:ro \ datadog/observability-pipelines-worker run ``` - Replace `` with your Datadog API key, `` with your Observability Pipelines configuration ID, and `` with {{< region-param key="dd_site" code="true" >}}. Be sure to also update `SPLUNK_HEC_ENDPOINT` and `SPLUNK_TOKEN` with values that match the Splunk deployment you created in [Setting up the Splunk Index](#setting-up-the-splunk-index). `./pipeline.yaml` must be the relative or absolute path to the configuration you downloaded in Step 1. + Replace `` with your Datadog API key, `` with your {{< prodname >}}Observability Pipelines{{< /prodname >}} configuration ID, and `` with {{< region-param key="dd_site" code="true" >}}. Be sure to also update `SPLUNK_HEC_ENDPOINT` and `SPLUNK_TOKEN` with values that match the Splunk deployment you created in [Setting up the Splunk Index](#setting-up-the-splunk-index). `./pipeline.yaml` must be the relative or absolute path to the configuration you downloaded in Step 1. [1]: https://hub.docker.com/r/datadog/observability-pipelines-worker [2]: /resources/yaml/observability_pipelines/splunk/pipeline.yaml @@ -538,7 +538,7 @@ An NLB is provisioned by the CloudFormation template, and is configured to point {{< /tabs >}} ### Buffering -Observability Pipelines includes multiple buffering strategies that allow you to increase the resilience of your cluster to downstream faults. The provided sample configurations use disk buffers, the capacities of which are rated for approximately 10 minutes of data at 10Mbps/core for Observability Pipelines deployments. That is often enough time for transient issues to resolve themselves, or for incident responders to decide what needs to be done with the observability data. +{{< prodname >}}Observability Pipelines{{< /prodname >}} includes multiple buffering strategies that allow you to increase the resilience of your cluster to downstream faults. The provided sample configurations use disk buffers, the capacities of which are rated for approximately 10 minutes of data at 10Mbps/core for {{< prodname >}}Observability Pipelines{{< /prodname >}} deployments. That is often enough time for transient issues to resolve themselves, or for incident responders to decide what needs to be done with the observability data. {{< tabs >}} {{% tab "Docker" %}} @@ -597,7 +597,7 @@ In the sample configuration provided, the same HEC token is used for both the Sp At this point, your logs should be going to the Worker and be available for processing. The next section goes through what process is included by default, and the additional options that are available. ## Working with data -The sample Observability Pipelines configuration does the following: +The sample {{< prodname >}}Observability Pipelines{{< /prodname >}} configuration does the following: - Collects logs being sent from the Splunk forwarder to the Observability Pipelines Worker. - Transforms logs by adding tags to data that has come through the Observability Pipelines Worker. This helps determine what traffic still needs to be shifted over to the Worker as you update your clusters. These tags also show you how logs are being routed through the load balancer, in case there are imbalances. - Routes the logs by dual-shipping the data to both Splunk and Datadog. diff --git a/hugo/content/en/observability_pipelines/legacy/troubleshooting.md b/hugo/content/en/observability_pipelines/legacy/troubleshooting.md index a3755dbe5d9..95fc038f460 100644 --- a/hugo/content/en/observability_pipelines/legacy/troubleshooting.md +++ b/hugo/content/en/observability_pipelines/legacy/troubleshooting.md @@ -14,7 +14,7 @@ If you experience unexpected behavior with Datadog Observability Pipelines (OP), The Observability Pipelines Worker emits internal logs about its own health. In the Observability Pipelines UI, you can investigate any internal error logs that the Worker process emits for all of its individual components. To see these diagnostic logs: -1. Navigate to [Observability Pipelines][1]. +1. Navigate to [{{< prodname >}}Observability Pipelines{{< /prodname >}}][1]. 1. Click into the pipeline you want to investigate. 1. Click on a component to see the component's side panel. 1. Click the **Diagnostic Logs** tab to view error logs that the Worker is emitting. Click on a log record to investigate it in the Log Explorer. If there are no logs listed, then the component is not emitting any error logs. diff --git a/hugo/content/en/observability_pipelines/legacy/working_with_data.md b/hugo/content/en/observability_pipelines/legacy/working_with_data.md index 8e04d904f99..fd7342879c8 100644 --- a/hugo/content/en/observability_pipelines/legacy/working_with_data.md +++ b/hugo/content/en/observability_pipelines/legacy/working_with_data.md @@ -23,7 +23,7 @@ further_reading: ## Overview -Observability Pipelines enables you to shape and transform observability data. Similar to Logging without Limits™ pipelines, you can configure pipelines for Observability Pipelines that are composed of a series of transform components. These transforms allow you to parse, structure, and enrich data with built-in type safety. +{{< prodname >}}Observability Pipelines{{< /prodname >}} enables you to shape and transform observability data. Similar to Logging without Limits™ pipelines, you can configure pipelines for {{< prodname >}}Observability Pipelines{{< /prodname >}} that are composed of a series of transform components. These transforms allow you to parse, structure, and enrich data with built-in type safety. ## Remap data @@ -97,7 +97,7 @@ The configuration returns the following: ## Sample, reduce, filter, and aggregate data -Sampling, reducing, filtering, and aggregating are common transforms to reduce the volume of observability data delivered to downstream services. Observability Pipelines offers a variety of ways to control your data volume: +Sampling, reducing, filtering, and aggregating are common transforms to reduce the volume of observability data delivered to downstream services. {{< prodname >}}Observability Pipelines{{< /prodname >}} offers a variety of ways to control your data volume: - [Sample events][4] based on supplied criteria and at a configurable rate. - [Reduce and collapse][5] multiple events into a single event. diff --git a/hugo/content/en/observability_pipelines/monitoring_and_troubleshooting/_index.md b/hugo/content/en/observability_pipelines/monitoring_and_troubleshooting/_index.md index 56e1d4f9efd..db90c588453 100644 --- a/hugo/content/en/observability_pipelines/monitoring_and_troubleshooting/_index.md +++ b/hugo/content/en/observability_pipelines/monitoring_and_troubleshooting/_index.md @@ -8,7 +8,7 @@ After setting up pipelines and scaling Workers: - If you are trying to troubleshoot an issue with the Observability Pipelines Worker, see [Worker CLI Commands][1] on how to see the raw data sent to the Worker. - You can track the status of your pipelines and components with health graphs and out-of-the-box monitors. See [Monitoring Pipelines][2] for more information. - You can also create your monitors, dashboards, and notebooks to monitor your pipelines. See [Pipeline Usage Metrics][3] for a list of metrics. -- If you run into issues with Observability Pipelines, see [Troubleshooting][4]. +- If you run into issues with {{< prodname >}}Observability Pipelines{{< /prodname >}}, see [Troubleshooting][4]. [1]: /observability_pipelines/monitoring_and_troubleshooting/worker_cli_commands/ [2]: /observability_pipelines/monitoring_and_troubleshooting/monitoring_pipelines/ diff --git a/hugo/content/en/observability_pipelines/monitoring_and_troubleshooting/monitoring_pipelines.md b/hugo/content/en/observability_pipelines/monitoring_and_troubleshooting/monitoring_pipelines.md index bb11b2816a7..94bc19aef20 100644 --- a/hugo/content/en/observability_pipelines/monitoring_and_troubleshooting/monitoring_pipelines.md +++ b/hugo/content/en/observability_pipelines/monitoring_and_troubleshooting/monitoring_pipelines.md @@ -31,7 +31,7 @@ A pipeline consists of components that collect, process, and route your observab ## View the status of your pipelines -1. Navigate to [Observability Pipelines][1] to see how many events or bytes your pipelines are receiving and sending out. The {{< ui >}}events/s{{< /ui >}} and {{< ui >}}bytes/s{{< /ui >}} metrics shown on this page are based on an average over 15 minutes. +1. Navigate to [{{< prodname >}}Observability Pipelines{{< /prodname >}}][1] to see how many events or bytes your pipelines are receiving and sending out. The {{< ui >}}events/s{{< /ui >}} and {{< ui >}}bytes/s{{< /ui >}} metrics shown on this page are based on an average over 15 minutes. 1. Select a pipeline. 1. Click the {{< ui >}}Health{{< /ui >}} tab to see details about the pipeline and its components. You can view graphs of: - How much each component is being used, and the total number of events that the component receives and sends out. @@ -45,7 +45,7 @@ You can export a health graph to a dashboard, notebook, or monitor. The exported To view graphs of resource usage and data sent through Observability Pipelines Workers: -1. Navigate to [Observability Pipelines][1]. +1. Navigate to [{{< prodname >}}Observability Pipelines{{< /prodname >}}][1]. 1. Select a pipeline. 1. Click the {{< ui >}}Workers{{< /ui >}} tab to see the Workers' memory and CPU utilization, traffic stats, and any errors. @@ -53,7 +53,7 @@ To view graphs of resource usage and data sent through Observability Pipelines W To view metrics for a source, process, or destination: -1. Navigate to [Observability Pipelines][1]. +1. Navigate to [{{< prodname >}}Observability Pipelines{{< /prodname >}}][1]. 1. Select a pipeline. 1. Click the cog next to the source's, processor's, or destination's name, then select {{< ui >}}View details{{< /ui >}}. Datadog displays health graphs for the component you selected. 1. If you want to export a graph to an [incident][2], [dashboard][3], or [notebook][4], click the export icon on the graph. The exported graph shows that the metric is grouped by the specific pipeline and component tags. @@ -62,7 +62,7 @@ To view metrics for a source, process, or destination: To see available out-of-the-box monitors: -1. Navigate to [Observability Pipelines][1]. +1. Navigate to [{{< prodname >}}Observability Pipelines{{< /prodname >}}][1]. 1. Click {{< ui >}}Enable monitors{{< /ui >}} in the {{< ui >}}Monitors{{< /ui >}} column for your pipeline. 1. Click {{< ui >}}Start{{< /ui >}} to set up a monitor for one of the suggested use cases.
The new metric monitor page is configured based on the use case you selected. You can update the configuration to further customize it. See the [Metric monitor documentation][3] for more information. diff --git a/hugo/content/en/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics.md b/hugo/content/en/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics.md index a7b1bb34edf..38330ad2f77 100644 --- a/hugo/content/en/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics.md +++ b/hugo/content/en/observability_pipelines/monitoring_and_troubleshooting/pipeline_usage_metrics.md @@ -23,7 +23,7 @@ further_reading: ## Overview -This document lists some of the metrics available from Observability Pipelines. You can: +This document lists some of the metrics available from {{< prodname >}}Observability Pipelines{{< /prodname >}}. You can: - Create your own [dashboards][1], [notebooks][2], and [monitors][3] with these metrics. - Use [Metrics Summary][5] to see metadata and tags available for the metrics. You can also see which dashboards, notebooks, monitors, and SLOs are using those metrics. @@ -53,9 +53,9 @@ All metrics are tagged with the following: ## Estimated usage metric -Observability Pipelines ingested bytes +{{< prodname >}}Observability Pipelines{{< /prodname >}} ingested bytes : **Metric**: `datadog.estimated_usage.observability_pipelines.ingested_bytes` -: **Description**: The volume of data ingested by Observability Pipelines. See [Estimated Usage Metrics][6] for more information. +: **Description**: The volume of data ingested by {{< prodname >}}Observability Pipelines{{< /prodname >}}. See [Estimated Usage Metrics][6] for more information. ## Host metrics diff --git a/hugo/content/en/observability_pipelines/monitoring_and_troubleshooting/troubleshooting.md b/hugo/content/en/observability_pipelines/monitoring_and_troubleshooting/troubleshooting.md index b28184541cb..4d1daa30156 100644 --- a/hugo/content/en/observability_pipelines/monitoring_and_troubleshooting/troubleshooting.md +++ b/hugo/content/en/observability_pipelines/monitoring_and_troubleshooting/troubleshooting.md @@ -11,11 +11,11 @@ If you experience unexpected behavior with Datadog Observability Pipelines (OP), To view information about the Observability Pipelines Workers running for an active pipeline: -1. Navigate to [Observability Pipelines][2]. +1. Navigate to [{{< prodname >}}Observability Pipelines{{< /prodname >}}][2]. 1. Select your pipeline. 1. Click the {{< ui >}}Workers{{< /ui >}} tab to see the Workers' memory and CPU utilization, traffic stats, and any errors. 1. To view the Workers' statuses and versions, click the {{< ui >}}Latest Deployment & Setup{{< /ui >}} tab. -1. To see the Workers' logs, click the cog at the top right side of the page, then select {{< ui >}}View OPW Logs{{< /ui >}}. See [Logs Search Syntax][3] for details on how to filter your logs. To see logs for a specific Worker, add `@op_worker.id:` to the search query.
**Note**: If you are not seeing Observability Pipelines Worker logs, make sure you are [indexing Worker logs][10] to Log Management. +1. To see the Workers' logs, click the cog at the top right side of the page, then select {{< ui >}}View OPW Logs{{< /ui >}}. See [Logs Search Syntax][3] for details on how to filter your logs. To see logs for a specific Worker, add `@op_worker.id:` to the search query.
**Note**: If you are not seeing Observability Pipelines Worker logs, make sure you are [indexing Worker logs][10] to {{< prodname >}}Log Management{{< /prodname >}}. ## Inspect events sent through your pipeline to identify setup issues @@ -68,11 +68,11 @@ docker run -i -e DD_API_KEY= \ ### No Worker logs in Log Explorer -If you do not see Worker logs in [Log Explorer][12], make sure they are not getting excluded in your log pipelines. Worker logs must be indexed in Log Management for optimal functionality. The logs provide deployment information, such as Worker status, version, and any errors, that is shown in the Observability Pipelines UI. The logs are also helpful for troubleshooting Worker or pipelines issues. If Worker logs are not indexed in Log Management, the Latest Deploy and Setup tab displays a perpetual loading state instead of the current Worker status. All Worker logs have the tag `source:op_worker`. +If you do not see Worker logs in [Log Explorer][12], make sure they are not getting excluded in your log pipelines. Worker logs must be indexed in {{< prodname >}}Log Management{{< /prodname >}} for optimal functionality. The logs provide deployment information, such as Worker status, version, and any errors, that is shown in the Observability Pipelines UI. The logs are also helpful for troubleshooting Worker or pipelines issues. If Worker logs are not indexed in {{< prodname >}}Log Management{{< /prodname >}}, the Latest Deploy and Setup tab displays a perpetual loading state instead of the current Worker status. All Worker logs have the tag `source:op_worker`. ### Duplicate Observability Pipelines logs -If you see duplicate Observability Pipelines logs in [Log Explorer][7] and your Agent is running in a Docker container, you must exclude Observability Pipelines logs using the `DD_CONTAINER_EXCLUDE_LOGS` environment variable. For Helm, use `datadog.containerExcludeLogs`. This prevents duplicate logs, as the Worker also sends its own logs directly to Datadog. See [Docker Log Collection][8] or [Setting environment variables for Helm][9] for more information. +If you see duplicate {{< prodname >}}Observability Pipelines{{< /prodname >}} logs in [Log Explorer][7] and your Agent is running in a Docker container, you must exclude {{< prodname >}}Observability Pipelines{{< /prodname >}} logs using the `DD_CONTAINER_EXCLUDE_LOGS` environment variable. For Helm, use `datadog.containerExcludeLogs`. This prevents duplicate logs, as the Worker also sends its own logs directly to Datadog. See [Docker Log Collection][8] or [Setting environment variables for Helm][9] for more information. ## Worker issues and errors @@ -97,7 +97,7 @@ If the Worker is not starting, Worker logs are not sent to Datadog and are not v ### Certificate verify failed -If you see an error with `certificate verify failed` and `self-signed certificate in certificate chain`, see [TLS certificates][16]. Observability Pipelines does not accept self-signed certificates because they are not secure. +If you see an error with `certificate verify failed` and `self-signed certificate in certificate chain`, see [TLS certificates][16]. {{< prodname >}}Observability Pipelines{{< /prodname >}} does not accept self-signed certificates because they are not secure. ### Ensure your organization is enabled for RC @@ -158,7 +158,7 @@ Run the command `netstat -anp | find ""` to check that the port tha ### Seeing delayed logs at the destination -Observability Pipelines destinations batch events before sending them to the downstream integration. For example, the Amazon S3, Google Cloud Storage, and Azure Storage destinations have a batch timeout of 900 seconds. If the other batch parameters (maximum events and maximum bytes) have not been met within the 900-second timeout, the batch is flushed at 900 seconds. This means the destination component can take up to 15 minutes to send out a batch of events to the downstream integration. +{{< prodname >}}Observability Pipelines{{< /prodname >}} destinations batch events before sending them to the downstream integration. For example, the Amazon S3, Google Cloud Storage, and Azure Storage destinations have a batch timeout of 900 seconds. If the other batch parameters (maximum events and maximum bytes) have not been met within the 900-second timeout, the batch is flushed at 900 seconds. This means the destination component can take up to 15 minutes to send out a batch of events to the downstream integration. These are the batch parameters for each destination: diff --git a/hugo/content/en/observability_pipelines/packs/_index.md b/hugo/content/en/observability_pipelines/packs/_index.md index 15522a6cc06..d6e28b58cc2 100644 --- a/hugo/content/en/observability_pipelines/packs/_index.md +++ b/hugo/content/en/observability_pipelines/packs/_index.md @@ -17,7 +17,7 @@ further_reading: {{< img src="observability_pipelines/packs/packs.png" alt="The packs section of Observability Pipelines" style="width:100%;" >}} -When setting up a pipeline to send logs from a specific source to Observability Pipelines, you often need to decide how to process and manage those logs. +When setting up a pipeline to send logs from a specific source to {{< prodname >}}Observability Pipelines{{< /prodname >}}, you often need to decide how to process and manage those logs. Questions such as the following might come up: diff --git a/hugo/content/en/observability_pipelines/processors/_index.md b/hugo/content/en/observability_pipelines/processors/_index.md index 0e5a2538d0e..1901a20c428 100644 --- a/hugo/content/en/observability_pipelines/processors/_index.md +++ b/hugo/content/en/observability_pipelines/processors/_index.md @@ -12,7 +12,7 @@ further_reading: ## Overview -
The processors outlined in this documentation are specific to on-premises logging environments. To parse, structure, and enrich cloud-based logs, see the Log Management documentation.
+
The processors outlined in this documentation are specific to on-premises logging environments. To parse, structure, and enrich cloud-based logs, see the {{< prodname >}}Log Management{{< /prodname >}} documentation.
Use Observability Pipelines' processors to parse, structure, and enrich your logs and metrics. When you create a pipeline in the UI, pre-selected processors are added to your processor group based on the selected template. You can add additional processors and delete any existing ones based on your processing needs. diff --git a/hugo/content/en/observability_pipelines/processors/enrichment_table.md b/hugo/content/en/observability_pipelines/processors/enrichment_table.md index ded9621f3d9..9e1cdefbd27 100644 --- a/hugo/content/en/observability_pipelines/processors/enrichment_table.md +++ b/hugo/content/en/observability_pipelines/processors/enrichment_table.md @@ -90,12 +90,12 @@ To set up the Enrichment Table processor: 1. Select the Reference Table in the dropdown menu. See [Using reference tables](#using-reference-tables) for more information. 1. Click {{< ui >}}Manage{{< /ui >}} to go to the Reference Tables configuration page. 1. (Optional) Select specific columns with which to enrich your logs. - - Observability Pipelines enriches logs with all columns in the table by default. Each column in the table is added as an attribute to the log, where the attribute name is the column name and the attribute value is the column value. + - {{< prodname >}}Observability Pipelines{{< /prodname >}} enriches logs with all columns in the table by default. Each column in the table is added as an attribute to the log, where the attribute name is the column name and the attribute value is the column value. - If you want to enrich your logs with specific columns from your Reference Table, select the columns' corresponding attributes in the dropdown menu. - 1. Enter a Datadog Application key identifier. Observability Pipelines uses [application keys][1] to access Datadog's programmatic API when enriching data. Ensure you application key is: + 1. Enter a Datadog Application key identifier. {{< prodname >}}Observability Pipelines{{< /prodname >}} uses [application keys][1] to access Datadog's programmatic API when enriching data. Ensure you application key is: - Associated with a [Service Account][2] (not a personal Datadog user account). - Limited to the [`reference_tables_read`][3] scope. - 1. Enter the source attribute of the log. The source attribute's value is what you want Observability Pipelines to find in the Reference Table. See the [Enrichment example](#enrichment-example) for more information. + 1. Enter the source attribute of the log. The source attribute's value is what you want {{< prodname >}}Observability Pipelines{{< /prodname >}} to find in the Reference Table. See the [Enrichment example](#enrichment-example) for more information. 1. Enter the target attribute. The target attribute's value stores, as a JSON object, the information found in the Reference Table. See the [Enrichment file example](#enrichment-file-example) for more information. 1. Click {{< ui >}}Save{{< /ui >}}. diff --git a/hugo/content/en/observability_pipelines/processors/sensitive_data_scanner.md b/hugo/content/en/observability_pipelines/processors/sensitive_data_scanner.md index a979a35b541..abd37dcd8e0 100644 --- a/hugo/content/en/observability_pipelines/processors/sensitive_data_scanner.md +++ b/hugo/content/en/observability_pipelines/processors/sensitive_data_scanner.md @@ -100,7 +100,7 @@ After adding scanning rules from the library, you can edit each rule separately To delete a rule in the Sensitive Data Scanner: -1. Navigate to [Observability Pipelines][2]. +1. Navigate to [{{< prodname >}}Observability Pipelines{{< /prodname >}}][2]. 1. Select your pipeline. 1. Click the Sensitive Data Scanner processor to expand it. 1. Click {{< ui >}}Manage Scanning Rules{{< /ui >}}. @@ -295,7 +295,7 @@ The Sensitive Data Scanner processor is CPU intensive. Use the following best pr ### View scanning rule usage with the Observability Pipelines Overview dashboard -Observability Pipelines includes an out-of-the-box [Observability Pipelines Overview][16] dashboard with a **Sensitive data found by Observability Pipelines** section. Use the widgets in that section to see which scanning rules are matching data. +{{< prodname >}}Observability Pipelines{{< /prodname >}} includes an out-of-the-box [Observability Pipelines Overview][16] dashboard with a **Sensitive data found by {{< prodname >}}Observability Pipelines{{< /prodname >}}** section. Use the widgets in that section to see which scanning rules are matching data. 1. Navigate to Dashboards > [Observability Pipelines Overview][16]. 1. Use the template variables (`pipeline_id`, `host`, `worker_uuid`, `component_type`, `component_kind`, `component_id`) at the top of the dashboard to scope the view to a specific pipeline or Worker. @@ -317,7 +317,7 @@ After you identify rules with no matches over a representative time frame, confi Rules that are enabled but not used consume unnecessary resources. Check the Sensitive Data Scanner processor to view how many matches each rule has had over the past 24 hours. -1. Navigate to [Observability Pipelines][2]. +1. Navigate to [{{< prodname >}}Observability Pipelines{{< /prodname >}}][2]. 1. Select your pipeline. 1. Click the Sensitive Data Scanner processor to expand it. 1. Click {{< ui >}}View Scanning Rules{{< /ui >}} to open the side panel and see {{< ui >}}Matches in the last 24 hours{{< /ui >}} for each rule. diff --git a/hugo/content/en/observability_pipelines/rehydration.md b/hugo/content/en/observability_pipelines/rehydration.md index 4dc07ca6675..687cd2209cb 100644 --- a/hugo/content/en/observability_pipelines/rehydration.md +++ b/hugo/content/en/observability_pipelines/rehydration.md @@ -22,9 +22,9 @@ Rehydration is in Preview. Fill out the form to request access. ## Overview -Rehydration for Observability Pipelines enables you to pull archived logs from object storage and process them in Observability Pipelines, including with [Packs][1]. This gives you consistent access to historical context without having to rebuild workflows or modify ingestion pipelines. +Rehydration for {{< prodname >}}Observability Pipelines{{< /prodname >}} enables you to pull archived logs from object storage and process them in {{< prodname >}}Observability Pipelines{{< /prodname >}}, including with [Packs][1]. This gives you consistent access to historical context without having to rebuild workflows or modify ingestion pipelines. -Organizations often store large volumes of logs in cost-efficient, long-term archives to control spend and meet compliance requirements. However, historical data often becomes difficult to access when there is a security incident, audit request, or operational investigation. Retrieving archived logs from cold storage can be slow, manual, and disruptive, requiring ad-hoc scripts, decompression, or dedicated engineering effort. Rehydration for Observability Pipelines solves these issues. +Organizations often store large volumes of logs in cost-efficient, long-term archives to control spend and meet compliance requirements. However, historical data often becomes difficult to access when there is a security incident, audit request, or operational investigation. Retrieving archived logs from cold storage can be slow, manual, and disruptive, requiring ad-hoc scripts, decompression, or dedicated engineering effort. Rehydration for {{< prodname >}}Observability Pipelines{{< /prodname >}} solves these issues. {{< img src="observability_pipelines/rehydration_pipeline.png" alt="A pipeline with the Amazon S3 rehydration source" style="width:100%;" >}} @@ -55,7 +55,7 @@ This ensures: ### Route rehydrated data to any supported destination -You can send processed historical logs to SIEMs, data lakes, analytics platforms, or any Observability Pipelines destination. +You can send processed historical logs to SIEMs, data lakes, analytics platforms, or any {{< prodname >}}Observability Pipelines{{< /prodname >}} destination. ### Eliminate manual handling diff --git a/hugo/content/en/observability_pipelines/scaling_and_performance/_index.md b/hugo/content/en/observability_pipelines/scaling_and_performance/_index.md index c72a4224295..4600ae6993c 100644 --- a/hugo/content/en/observability_pipelines/scaling_and_performance/_index.md +++ b/hugo/content/en/observability_pipelines/scaling_and_performance/_index.md @@ -3,10 +3,10 @@ title: Scaling and Performance disable_toc: false --- -As you scale your Observability Pipelines architecture to cover your different use cases: +As you scale your {{< prodname >}}Observability Pipelines{{< /prodname >}} architecture to cover your different use cases: - If you want to run multiple pipelines on a host so that you can send data from different sources, follow the instructions in [Run Multiple Pipelines on a Host][1]. -- Observability Pipelines uses backpressure signals and buffering to handle situations where the system cannot process events immediately upon receiving them. See [Buffering and Backpressure][2] for more information. +- {{< prodname >}}Observability Pipelines{{< /prodname >}} uses backpressure signals and buffering to handle situations where the system cannot process events immediately upon receiving them. See [Buffering and Backpressure][2] for more information. - When you scale Observability Pipelines Workers, each Worker operates independently. See [Best Practices for Scaling Pipelines][3] for the recommended aggregator architecture. [1]: /observability_pipelines/configuration/install_the_worker/run_multiple_pipelines_on_a_host/ diff --git a/hugo/content/en/observability_pipelines/scaling_and_performance/best_practices_for_scaling_observability_pipelines.md b/hugo/content/en/observability_pipelines/scaling_and_performance/best_practices_for_scaling_observability_pipelines.md index ab243e5567f..394fdb7bed0 100644 --- a/hugo/content/en/observability_pipelines/scaling_and_performance/best_practices_for_scaling_observability_pipelines.md +++ b/hugo/content/en/observability_pipelines/scaling_and_performance/best_practices_for_scaling_observability_pipelines.md @@ -72,7 +72,7 @@ Choose the Kubernetes-based architecture if: Choose the VM-based architecture if your organization is more VM centric and not proficient with Kubernetes. -Choosing between the two models comes down to what your organization is best equipped to do from an infrastructure perspective. Each model offers the ability to automatically scale based on CPU utilization, which is generally the primary constraint for Observability Pipelines. See [Optimize the instance][6] for more information. +Choosing between the two models comes down to what your organization is best equipped to do from an infrastructure perspective. Each model offers the ability to automatically scale based on CPU utilization, which is generally the primary constraint for {{< prodname >}}Observability Pipelines{{< /prodname >}}. See [Optimize the instance][6] for more information. ### Centralized vs decentralized approach diff --git a/hugo/content/en/observability_pipelines/scaling_and_performance/buffering_and_backpressure.md b/hugo/content/en/observability_pipelines/scaling_and_performance/buffering_and_backpressure.md index 8b88c604350..aab574518c6 100644 --- a/hugo/content/en/observability_pipelines/scaling_and_performance/buffering_and_backpressure.md +++ b/hugo/content/en/observability_pipelines/scaling_and_performance/buffering_and_backpressure.md @@ -21,9 +21,9 @@ further_reading: ## Overview -Observability Pipelines are designed for durability and to mitigate the impact when destinations are unavailable. If a destination is unavailable (for example, due to connection issues), the Observability Pipelines Worker retries its connection to the destination until the connection is reestablished or the destination times out. During this time, events accumulate in the pipeline components' internal buffers, eventually blocking the source from ingesting new events. This behavior is called **backpressure**. +{{< prodname >}}Observability Pipelines{{< /prodname >}} are designed for durability and to mitigate the impact when destinations are unavailable. If a destination is unavailable (for example, due to connection issues), the Observability Pipelines Worker retries its connection to the destination until the connection is reestablished or the destination times out. During this time, events accumulate in the pipeline components' internal buffers, eventually blocking the source from ingesting new events. This behavior is called **backpressure**. -It is important to consider how backpressure propagates through your architecture in the event of a destination outage. For example, backpressure can block your application from sending logs to Observability Pipelines and those logs may contend for memory or disk resources needed by your service. To prevent backpressure from reaching your application, [configure a destination buffer](#choosing-buffer-types) and size it according to your pipeline's throughput, which helps the Worker absorb backpressure when the destination is unavailable. You may also want to configure the [on-full buffer behavior](#choosing-buffer-on-full-behavior) to `drop newest`, which prevents backpressure by dropping incoming events when the buffer is full. See the [destination buffers section](#destination-buffers) for more information on configurable destination buffers. +It is important to consider how backpressure propagates through your architecture in the event of a destination outage. For example, backpressure can block your application from sending logs to {{< prodname >}}Observability Pipelines{{< /prodname >}} and those logs may contend for memory or disk resources needed by your service. To prevent backpressure from reaching your application, [configure a destination buffer](#choosing-buffer-types) and size it according to your pipeline's throughput, which helps the Worker absorb backpressure when the destination is unavailable. You may also want to configure the [on-full buffer behavior](#choosing-buffer-on-full-behavior) to `drop newest`, which prevents backpressure by dropping incoming events when the buffer is full. See the [destination buffers section](#destination-buffers) for more information on configurable destination buffers. All components in the Observability Pipelines Worker have an in-memory buffer to help smooth the handoff of events between components. All sources have a buffer with a capacity of 1,000 events per worker thread. Sources write events to their respective downstream buffer upon ingestion. All processors have an in-memory buffer with a capacity of 100 events, which the processors consume upstream. Source and processor buffers are not configurable. @@ -71,7 +71,7 @@ The `drop_newest` on-full behavior drops incoming events when a destination's bu ### Kubernetes persistent volumes -If you enable disk buffering for destinations, you must enable Kubernetes [persistent volumes][1] in the Observability Pipelines helm chart. With disk buffering enabled, events are first sent to the buffer and written to the persistent volumes, then sent downstream. +If you enable disk buffering for destinations, you must enable Kubernetes [persistent volumes][1] in the {{< prodname >}}Observability Pipelines{{< /prodname >}} helm chart. With disk buffering enabled, events are first sent to the buffer and written to the persistent volumes, then sent downstream. ## Buffer metrics diff --git a/hugo/content/en/observability_pipelines/sources/_index.md b/hugo/content/en/observability_pipelines/sources/_index.md index 499341f9bf7..36eaa0fc4a8 100644 --- a/hugo/content/en/observability_pipelines/sources/_index.md +++ b/hugo/content/en/observability_pipelines/sources/_index.md @@ -125,9 +125,9 @@ After events are ingested by the source, they get sent to different processors a ## TLS certificates -Enable TLS for Observability Pipelines to ensure that data are encrypted during transit. This prevents attackers from tampering with your data. +Enable TLS for {{< prodname >}}Observability Pipelines{{< /prodname >}} to ensure that data are encrypted during transit. This prevents attackers from tampering with your data. -Observability Pipelines does not accept self-signed certificates by default because they do not provide secure trust verification and can potentially expose your environment to man-in-the-middle attacks. +{{< prodname >}}Observability Pipelines{{< /prodname >}} does not accept self-signed certificates by default because they do not provide secure trust verification and can potentially expose your environment to man-in-the-middle attacks. To check if your certificate is self-signed, run this command: diff --git a/hugo/content/en/observability_pipelines/sources/akamai_datastream.md b/hugo/content/en/observability_pipelines/sources/akamai_datastream.md index 4ee97dbed10..393607106c6 100644 --- a/hugo/content/en/observability_pipelines/sources/akamai_datastream.md +++ b/hugo/content/en/observability_pipelines/sources/akamai_datastream.md @@ -14,11 +14,11 @@ aliases: ## Overview -This document goes over how to send Akamai DataStream logs to Observability Pipelines using the HTTP Server source. +This document goes over how to send Akamai DataStream logs to {{< prodname >}}Observability Pipelines{{< /prodname >}} using the HTTP Server source. ## Prerequisites -The following are required to send Akamai DataStream logs to Observability Pipelines: +The following are required to send Akamai DataStream logs to {{< prodname >}}Observability Pipelines{{< /prodname >}}: - An Akamai account with DataStreams 2. - A server or a server pool, fronted by a load balancer, that runs the Observability Pipelines Worker and allows traffic from the public internet. @@ -46,12 +46,12 @@ The following are required to send Akamai DataStream logs to Observability Pipel 1. In the **Destination** section: 1. In the **Destination** dropdown menu, select **Custom HTTPS**. 1. Enter a **Display Name**. - 1. In the **Authentication** dropdown menu, select the authorization method you chose for the HTTP Server source in Observability Pipelines. + 1. In the **Authentication** dropdown menu, select the authorization method you chose for the HTTP Server source in {{< prodname >}}Observability Pipelines{{< /prodname >}}. 1. Enter your endpoint URL. - **Note**: Your endpoint URL **must** be a FQDN, not an IP address. If you enter an IP address you get an error message. 1. Click **Validate & Save**. 1. After the stream is activated (it takes about 20 minutes), the **Stream list** page shows the status of your stream as **Active**. -1. View your Akamai DataStream logs in Datadog [Log Explorer][3] or the Observability Pipelines destination. +1. View your Akamai DataStream logs in Datadog [Log Explorer][3] or the {{< prodname >}}Observability Pipelines{{< /prodname >}} destination. ## Health metrics diff --git a/hugo/content/en/observability_pipelines/sources/azure_event_hubs.md b/hugo/content/en/observability_pipelines/sources/azure_event_hubs.md index b264c4e0fab..31e2e99f7fb 100644 --- a/hugo/content/en/observability_pipelines/sources/azure_event_hubs.md +++ b/hugo/content/en/observability_pipelines/sources/azure_event_hubs.md @@ -5,7 +5,7 @@ disable_toc: false ## Overview -This document walks through how to send Azure Event Hubs logs to Observability Pipelines using the Kafka source. The setup steps include setting up Azure Event Hubs for the Kafka source: +This document walks through how to send Azure Event Hubs logs to {{< prodname >}}Observability Pipelines{{< /prodname >}} using the Kafka source. The setup steps include setting up Azure Event Hubs for the Kafka source: - [Create an Event Hubs namespace](#create-an-azure-event-hubs-namespace) - [Create an Event Hub (Kafka topic)](#create-an-event-hub-kafka-topic) @@ -13,7 +13,7 @@ This document walks through how to send Azure Event Hubs logs to Observability P - [Set up diagnostic settings](#set-up-diagnostic-settings) - [Configure Kafka-compatible connection for the event hub](#configure-kafka-compatible-connection-for-the-event-hub) -After Azure Event Hubs has been set up, you [set up a pipeline with the Kafka source](#set-up-a-pipeline-with-the-kafka-source) to send Azure Event Hubs logs to Observability Pipelines. +After Azure Event Hubs has been set up, you [set up a pipeline with the Kafka source](#set-up-a-pipeline-with-the-kafka-source) to send Azure Event Hubs logs to {{< prodname >}}Observability Pipelines{{< /prodname >}}. ## Set up Azure Event Hubs for the Kafka source @@ -60,7 +60,7 @@ After Azure Event Hubs has been set up, you [set up a pipeline with the Kafka so ### Configure Kafka-compatible connection for the Event Hub -Azure Event Hubs exposes a Kafka endpoint at `NAMESPACE.servicebus.windows.net:9093`, which Observability Pipelines uses as the Kafka source. +Azure Event Hubs exposes a Kafka endpoint at `NAMESPACE.servicebus.windows.net:9093`, which {{< prodname >}}Observability Pipelines{{< /prodname >}} uses as the Kafka source. #### Get the Kafka endpoint @@ -73,7 +73,7 @@ Azure Event Hubs exposes a Kafka endpoint at `NAMESPACE.servicebus.windows.net:9 #### Set up authentication 1. Azure Event Hubs uses SASL_SSL with the PLAIN mechanism for Kafka authentication. -1. The connection string is formatted for Observability Pipelines: +1. The connection string is formatted for {{< prodname >}}Observability Pipelines{{< /prodname >}}: ``` Username: $$ConnectionString Password: Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey= @@ -85,7 +85,7 @@ Select your platform. {{< tabs >}} {{% tab "Kubernetes" %}} -1. Navigate to [Observability Pipelines](https://app.datadoghq.com/observability-pipelines). +1. Navigate to [{{< prodname >}}Observability Pipelines{{< /prodname >}}](https://app.datadoghq.com/observability-pipelines). 1. Select the Kafka source. 1. In the {{< ui >}}Group ID{{< /ui >}} field, specify or create a unique consumer group (for example, `datadog-consumer-group`). 1. In the {{< ui >}}Topics{{< /ui >}} field, enter `datadog-topic` or the topic you configured for your Event Hub earlier. @@ -131,13 +131,13 @@ Select your platform. {{% /tab %}} {{% tab "Virtual machine (VM)" %}} -1. Navigate to [Observability Pipelines](https://app.datadoghq.com/observability-pipelines). +1. Navigate to [{{< prodname >}}Observability Pipelines{{< /prodname >}}](https://app.datadoghq.com/observability-pipelines). 1. Select the Kafka source. 1. In the {{< ui >}}Group ID{{< /ui >}} field, specify or create a unique consumer group (for example, `datadog-consumer-group`). 1. Enter `datadog-topic` in the {{< ui >}}Topics{{< /ui >}} field. 1. Toggle the switch to enable SASL authentication. 1. In the {{< ui >}}Mechanism{{< /ui >}} dropdown menu, select {{< ui >}}PLAIN{{< /ui >}}. - 1. Enable TLS. For the certificate, copy the certificate from its original location to the default Observability Pipelines data configuration directory: + 1. Enable TLS. For the certificate, copy the certificate from its original location to the default {{< prodname >}}Observability Pipelines{{< /prodname >}} data configuration directory: 1. Since the Observability Pipelines Worker hasn't been installed yet, run this command to create the directory for the certificate: ``` sudo mkdir -p /var/lib/observability-pipelines-worker/config @@ -165,7 +165,7 @@ Select your platform. ## Troubleshooting -If you run into issues after installing the Worker, check your Observability Pipelines environment file (`/etc/default/observability-pipelines-worker`) to make sure the environment variables are correctly set: +If you run into issues after installing the Worker, check your {{< prodname >}}Observability Pipelines{{< /prodname >}} environment file (`/etc/default/observability-pipelines-worker`) to make sure the environment variables are correctly set: - `DD_OP_SOURCE_KAFKA_SASL_USERNAME="$$ConnectionString"` - `DD_OP_SOURCE_KAFKA_BOOTSTRAP_SERVERS=.servicebus.windows.net:9093` diff --git a/hugo/content/en/observability_pipelines/sources/cloudflare_logpush.md b/hugo/content/en/observability_pipelines/sources/cloudflare_logpush.md index 264547999d0..71d59aa099f 100644 --- a/hugo/content/en/observability_pipelines/sources/cloudflare_logpush.md +++ b/hugo/content/en/observability_pipelines/sources/cloudflare_logpush.md @@ -12,11 +12,11 @@ products: ## Overview -This document goes over how to send Cloudflare Logpush logs to Observability Pipelines using the HTTP Server source. +This document goes over how to send Cloudflare Logpush logs to {{< prodname >}}Observability Pipelines{{< /prodname >}} using the HTTP Server source. ## Prerequisites -The following are required to send Cloudflare Logpush logs to Observability Pipelines: +The following are required to send Cloudflare Logpush logs to {{< prodname >}}Observability Pipelines{{< /prodname >}}: - A Cloudflare account with Logpush enabled. - A server or a server pool, fronted by a load balancer, that runs the Observability Pipelines Worker and allows traffic from Cloudflare's CIDR blocks or the public internet. @@ -29,7 +29,7 @@ The following are required to send Cloudflare Logpush logs to Observability Pipe ### Set up the pipeline components -1. Navigate to [Observability Pipelines][2]. +1. Navigate to [{{< prodname >}}Observability Pipelines{{< /prodname >}}][2]. 1. Select a log template to create a pipeline. 1. Select the HTTP Server source. 1. If you are using Secrets Management, enter the identifier for the HTTP/S Server address key. See [Secret defaults][3] for the defaults used. diff --git a/hugo/content/en/observability_pipelines/sources/datadog_agent.md b/hugo/content/en/observability_pipelines/sources/datadog_agent.md index 3cb8543c618..85cc56987d8 100644 --- a/hugo/content/en/observability_pipelines/sources/datadog_agent.md +++ b/hugo/content/en/observability_pipelines/sources/datadog_agent.md @@ -69,7 +69,7 @@ After you select the Datadog Agent source in the pipeline UI, enter the identifi Use the Agent configuration file or the Agent Helm chart values file to connect the Datadog Agent to the Observability Pipelines Worker. -**Note**: If your Agent is running in a Docker container, you must exclude Observability Pipelines logs using the `DD_CONTAINER_EXCLUDE_LOGS` environment variable. For Helm, use `datadog.containerExcludeLogs`. This prevents duplicate logs, as the Worker also sends its own logs directly to Datadog. See [Docker Log Collection][1] or [Setting environment variables for Helm][2] for more information. +**Note**: If your Agent is running in a Docker container, you must exclude {{< prodname >}}Observability Pipelines{{< /prodname >}} logs using the `DD_CONTAINER_EXCLUDE_LOGS` environment variable. For Helm, use `datadog.containerExcludeLogs`. This prevents duplicate logs, as the Worker also sends its own logs directly to Datadog. See [Docker Log Collection][1] or [Setting environment variables for Helm][2] for more information. {{% collapse-content title="Agent configuration file" level="h4" expanded=false id="logs-agent-config-file" %}} @@ -92,7 +92,7 @@ Use the Agent configuration file or the Agent Helm chart values file to connect Use the Agent configuration file or the Agent Helm chart values file to connect the Datadog Agent to the Observability Pipelines Worker. -**Note**: If your Agent is running in a Docker container, you must exclude Observability Pipelines metrics, such as utilization and events in/out metrics, using the `DD_CONTAINER_EXCLUDE_METRICS` environment variable. For Helm, use `datadog.containerExcludeMetrics`. This prevents duplicate metrics, as the Worker also sends its own metrics directly to Datadog. See [Docker Metrics Collection][1] or [Setting environment variables for Helm][2] for more information. +**Note**: If your Agent is running in a Docker container, you must exclude {{< prodname >}}Observability Pipelines{{< /prodname >}} metrics, such as utilization and events in/out metrics, using the `DD_CONTAINER_EXCLUDE_METRICS` environment variable. For Helm, use `datadog.containerExcludeMetrics`. This prevents duplicate metrics, as the Worker also sends its own metrics directly to Datadog. See [Docker Metrics Collection][1] or [Setting environment variables for Helm][2] for more information. {{% collapse-content title="Agent configuration file" level="h4" expanded=false id="metrics-agent-config-file" %}} diff --git a/hugo/content/en/observability_pipelines/sources/filebeat.md b/hugo/content/en/observability_pipelines/sources/filebeat.md index 837465bac17..f4c9398c8db 100644 --- a/hugo/content/en/observability_pipelines/sources/filebeat.md +++ b/hugo/content/en/observability_pipelines/sources/filebeat.md @@ -5,7 +5,7 @@ disable_toc: false ## Overview -Use the Logstash source to send logs to Observability Pipelines with Filebeat. +Use the Logstash source to send logs to {{< prodname >}}Observability Pipelines{{< /prodname >}} with Filebeat. ## Setup diff --git a/hugo/content/en/observability_pipelines/sources/http_server.md b/hugo/content/en/observability_pipelines/sources/http_server.md index d6778495678..5310dd9e1dc 100644 --- a/hugo/content/en/observability_pipelines/sources/http_server.md +++ b/hugo/content/en/observability_pipelines/sources/http_server.md @@ -81,7 +81,7 @@ If you store tokens as credentials in your HTTP request's authorization header, ## Send AWS vended logs with the Datadog Lambda Forwarder to Observability Pipelines -To send AWS vended logs to Observability Pipelines with the HTTP/S Server source: +To send AWS vended logs to {{< prodname >}}Observability Pipelines{{< /prodname >}} with the HTTP/S Server source: - [Set up a pipeline with the HTTP/S Server source](#set-up-a-pipeline). - [Deploy the Datadog Forwarder](#deploy-the-datadog-lambda-forwarder). diff --git a/hugo/content/en/observability_pipelines/sources/lambda_extension.md b/hugo/content/en/observability_pipelines/sources/lambda_extension.md index 29224cea348..dcf01d9b307 100644 --- a/hugo/content/en/observability_pipelines/sources/lambda_extension.md +++ b/hugo/content/en/observability_pipelines/sources/lambda_extension.md @@ -6,7 +6,7 @@ disable_toc: false ## Overview -This document describes how to use the Datadog Lambda Extension to send AWS vended logs to Observability Pipelines. The setup steps are: +This document describes how to use the Datadog Lambda Extension to send AWS vended logs to {{< prodname >}}Observability Pipelines{{< /prodname >}}. The setup steps are: - [Set up a pipeline with the HTTP/S Server source](#set-up-a-pipeline). - [Deploy the Datadog Lambda Extension](#deploy-the-datadog-lambda-extension) diff --git a/hugo/content/en/observability_pipelines/sources/lambda_forwarder.md b/hugo/content/en/observability_pipelines/sources/lambda_forwarder.md index 893f535cebf..39d8a41196d 100644 --- a/hugo/content/en/observability_pipelines/sources/lambda_forwarder.md +++ b/hugo/content/en/observability_pipelines/sources/lambda_forwarder.md @@ -5,7 +5,7 @@ disable_toc: false ## Overview -This document walks through how to send AWS vended logs with the Datadog Lambda Forwarder to Observability Pipelines. The setup steps are: +This document walks through how to send AWS vended logs with the Datadog Lambda Forwarder to {{< prodname >}}Observability Pipelines{{< /prodname >}}. The setup steps are: - [Set up a pipeline with the HTTP/S Server source](#set-up-a-pipeline). - [Deploy the Datadog Forwarder](#deploy-the-datadog-lambda-forwarder). diff --git a/hugo/content/en/observability_pipelines/sources/mysql.md b/hugo/content/en/observability_pipelines/sources/mysql.md index 4e183091819..f403f84f9fd 100644 --- a/hugo/content/en/observability_pipelines/sources/mysql.md +++ b/hugo/content/en/observability_pipelines/sources/mysql.md @@ -16,7 +16,7 @@ products: Databases often contain large numbers of historical, audit, or operational records. For many legacy, enterprise resource planning (ERP), and IoT-based systems, these databases serve as storage layers for important information. Teams often depend on these records for monitoring, alerting, and creating dashboards in their preferred logging or security tool. -The Observability Pipelines' MySQL source (includes Amazon RDS and AWS Aurora) allows you to connect to your database so you can query and process record data in Observability Pipelines, and route your log events that are stored as database records. +The Observability Pipelines' MySQL source (includes Amazon RDS and AWS Aurora) allows you to connect to your database so you can query and process record data in {{< prodname >}}Observability Pipelines{{< /prodname >}}, and route your log events that are stored as database records. **Note**: The Observability Pipelines Worker can only execute read-only SQL queries against supported databases. @@ -33,7 +33,7 @@ You can use this source to: ## Prerequisites -Before you configure the MySQL source, complete the following prerequisites to ensure that Observability Pipelines can validate credentials, connectivity, and queries before they are used in Observability Pipelines. Use a [tool](#external-tools-for-validating-queries) external to Observability Pipelines, such as MySQL Workbench or third-party tools, to complete these steps. +Before you configure the MySQL source, complete the following prerequisites to ensure that {{< prodname >}}Observability Pipelines{{< /prodname >}} can validate credentials, connectivity, and queries before they are used in {{< prodname >}}Observability Pipelines{{< /prodname >}}. Use a [tool](#external-tools-for-validating-queries) external to {{< prodname >}}Observability Pipelines{{< /prodname >}}, such as MySQL Workbench or third-party tools, to complete these steps. 1. [Create a database role](#1-create-a-database-role). 1. [Validate the connection string](#2-validate-the-connection-string). @@ -55,11 +55,11 @@ The connection string must: - Be able to successfully connect to the database from the environment in which the Observability Pipelines Worker runs. - Be in this format: `mysql://${DB_USERNAME}:${DB_PASSWORD}@${DB_HOST}:${DB_PORT}/${DB_NAME}`. - Use the correct host, port, database name, and authentication mechanism. -- Be tested prior to configuring it in Observability Pipelines, to avoid runtime failures. +- Be tested prior to configuring it in {{< prodname >}}Observability Pipelines{{< /prodname >}}, to avoid runtime failures. ### 3. Write, validate, and test SQL queries -Write and test your SQL queries. Validate all SQL queries with a [tool](#external-tools-for-validating-queries) external to Observability Pipelines and prior to configuring it in Observability Pipelines. [Store the SQL query in a local file](#store-the-sql-query-in-a-local-file) for the Worker to execute. +Write and test your SQL queries. Validate all SQL queries with a [tool](#external-tools-for-validating-queries) external to {{< prodname >}}Observability Pipelines{{< /prodname >}} and prior to configuring it in {{< prodname >}}Observability Pipelines{{< /prodname >}}. [Store the SQL query in a local file](#store-the-sql-query-in-a-local-file) for the Worker to execute. **Notes**: @@ -108,7 +108,7 @@ Checkpoint values are updated every job run. To monitor the checkpoint value, th 1. Check the latest Worker log to see the last checkpoint value the Worker received from querying the database. 1. Check the logs in your destination to see the last checkpoint value it received from the Worker. This value might not be the same as the checkpoint value seen in the latest Worker log. If you want to ensure that every record is sent to the destination at least once, reset the starting checkpoint value in the MySQL source with the destination's last checkpoint value. 1. To reset the checkpoint value in the MySQL source: - 1. Navigate to [Observability Pipelines][1]. + 1. Navigate to [{{< prodname >}}Observability Pipelines{{< /prodname >}}][1]. 1. Click on your pipeline and click. 1. In the MySQL source, enter the destination's last checkpoint value in the {{< ui >}}Checkpoint value{{< /ui >}} field. diff --git a/hugo/content/en/observability_pipelines/sources/okta.md b/hugo/content/en/observability_pipelines/sources/okta.md index 67527c3a396..1727ba4704a 100644 --- a/hugo/content/en/observability_pipelines/sources/okta.md +++ b/hugo/content/en/observability_pipelines/sources/okta.md @@ -12,11 +12,11 @@ products: ## Overview -This document goes over how to send Okta logs to Observability Pipelines using Amazon EventBridge and the Observability Pipelines HTTP Server source. +This document goes over how to send Okta logs to {{< prodname >}}Observability Pipelines{{< /prodname >}} using Amazon EventBridge and the Observability Pipelines HTTP Server source. ## Prerequisites -The following are required to send Okta logs to Observability Pipelines using Amazon EventBridge: +The following are required to send Okta logs to {{< prodname >}}Observability Pipelines{{< /prodname >}} using Amazon EventBridge: - A registered domain. - A TLS certificate that matches the domain. @@ -25,7 +25,7 @@ The following are required to send Okta logs to Observability Pipelines using Am ### Set up the pipeline components -1. Navigate to [Observability Pipelines][1]. +1. Navigate to [{{< prodname >}}Observability Pipelines{{< /prodname >}}][1]. 1. Select a log template to create a pipeline. 1. Select the HTTP Server source. 1. If you are using Secrets Management, enter the identifier for the HTTP/S Server address key. See [Secret defaults][2] for the defaults used. diff --git a/hugo/content/en/observability_pipelines/sources/opentelemetry.md b/hugo/content/en/observability_pipelines/sources/opentelemetry.md index 37a55de9e92..e037c387f1b 100644 --- a/hugo/content/en/observability_pipelines/sources/opentelemetry.md +++ b/hugo/content/en/observability_pipelines/sources/opentelemetry.md @@ -25,7 +25,7 @@ Use Observability Pipelines' OpenTelemetry (OTel) source to collect logs or metr **Notes**: - If you are using the Datadog Distribution of OpenTelemetry (DDOT) Collector, use the OpenTelemetry source to [send data to Observability Pipelines](#send-data-from-the-datadog-distribution-of-opentelemetry-collector-to-observability-pipelines). -- If you are using the Splunk HEC Distribution of the OpenTelemetry Collector, use the [Splunk HEC source][4] to send logs to Observability Pipelines. +- If you are using the Splunk HEC Distribution of the OpenTelemetry Collector, use the [Splunk HEC source][4] to send logs to {{< prodname >}}Observability Pipelines{{< /prodname >}}. ### When to use this source @@ -33,7 +33,7 @@ Common scenarios when you might use this source: - You are using [OpenTelemetry][1] as your standard method for collecting and routing data, and you want to normalize that data, before routing them to different destinations. - You are collecting data from multiple sources and want to aggregate them in a central place for consistent processing. - - For example, if some of your services export logs using OpenTelemetry, while other services use Datadog Agents or other Observability Pipelines [sources][2], you can send all of your data to Observability Pipelines for processing. + - For example, if some of your services export logs using OpenTelemetry, while other services use Datadog Agents or other {{< prodname >}}Observability Pipelines{{< /prodname >}} [sources][2], you can send all of your data to {{< prodname >}}Observability Pipelines{{< /prodname >}} for processing. ## Prerequisites @@ -170,12 +170,12 @@ Set the listener address environment variables to the following default values. To send logs from the Datadog Distribution of the OpenTelemetry (DDOT) Collector: 1. Deploy the DDOT Collector using Helm. See [Install the DDOT Collector as a Kubernetes DaemonSet][5] for instructions. -1. [Set up a pipeline][6] on Observability Pipelines using the [OpenTelemetry source](#set-up-the-source-in-the-pipeline-ui). +1. [Set up a pipeline][6] on {{< prodname >}}Observability Pipelines{{< /prodname >}} using the [OpenTelemetry source](#set-up-the-source-in-the-pipeline-ui). 1. (Optional) Datadog recommends adding an [Edit Fields processor][7] to the pipeline that appends the field `op_otel_ddot:true`. 1. When you install the Worker, for the OpenTelemetry source environment variables: 1. Set your HTTP listener to `0.0.0.0:4318`. 1. Set your gRPC listener to `0.0.0.0:4317`. - 1. After you install the Worker and deployed the pipeline, update the OpenTelemetry Collector's [`otel-config.yaml`][9] to include an exporter that sends logs to Observability Pipelines. For example: + 1. After you install the Worker and deployed the pipeline, update the OpenTelemetry Collector's [`otel-config.yaml`][9] to include an exporter that sends logs to {{< prodname >}}Observability Pipelines{{< /prodname >}}. For example: ``` exporters: otlphttp: @@ -195,7 +195,7 @@ To send logs from the Datadog Distribution of the OpenTelemetry (DDOT) Collector ``` **Notes**: -- Because DDOT is sending logs to Observability Pipelines, and not the Datadog Agent, the following settings do not work for sending logs from DDOT to Observability Pipelines: +- Because DDOT is sending logs to {{< prodname >}}Observability Pipelines{{< /prodname >}}, and not the Datadog Agent, the following settings do not work for sending logs from DDOT to {{< prodname >}}Observability Pipelines{{< /prodname >}}: - `DD_OBSERVABILITY_PIPELINES_WORKER_LOGS_ENABLED` - `DD_OBSERVABILITY_PIPELINES_WORKER_LOGS_URL` - Logs sent from DDOT might have nested objects that prevent Datadog from parsing the logs correctly. To resolve this, Datadog recommends using the [Custom Processor][8] to flatten the nested `resource` object. @@ -213,12 +213,12 @@ To send logs from the Datadog Distribution of the OpenTelemetry (DDOT) Collector To send metrics from the Datadog Distribution of the OpenTelemetry (DDOT) Collector: 1. Deploy the DDOT Collector using Helm. See [Install the DDOT Collector as a Kubernetes DaemonSet][5] for instructions. -1. [Set up a pipeline][6] on Observability Pipelines using the [OpenTelemetry source](#set-up-the-source-in-the-pipeline-ui). +1. [Set up a pipeline][6] on {{< prodname >}}Observability Pipelines{{< /prodname >}} using the [OpenTelemetry source](#set-up-the-source-in-the-pipeline-ui). 1. (Optional) Datadog recommends adding an [Edit Fields processor][7] to the pipeline that appends the field `op_otel_ddot:true`. 1. When you install the Worker, for the OpenTelemetry source environment variables: 1. Set your HTTP listener to `0.0.0.0:4318`. 1. Set your gRPC listener to `0.0.0.0:4317`. - 1. After you install the Worker and deployed the pipeline, update the OpenTelemetry Collector's [`otel-config.yaml`][9] to include an exporter that sends metrics to Observability Pipelines. For example: + 1. After you install the Worker and deployed the pipeline, update the OpenTelemetry Collector's [`otel-config.yaml`][9] to include an exporter that sends metrics to {{< prodname >}}Observability Pipelines{{< /prodname >}}. For example: ``` exporters: otlphttp: @@ -238,7 +238,7 @@ To send metrics from the Datadog Distribution of the OpenTelemetry (DDOT) Collec ``` **Notes**: -- Because DDOT is sending metrics to Observability Pipelines, and not the Datadog Agent, the following settings do not work for sending metrics from DDOT to Observability Pipelines: +- Because DDOT is sending metrics to {{< prodname >}}Observability Pipelines{{< /prodname >}}, and not the Datadog Agent, the following settings do not work for sending metrics from DDOT to {{< prodname >}}Observability Pipelines{{< /prodname >}}: - `DD_OBSERVABILITY_PIPELINES_WORKER_METRICS_ENABLED` - `DD_OBSERVABILITY_PIPELINES_WORKER_METRICS_URL` - Metrics sent from DDOT might have nested objects that prevent Datadog from parsing the metrics correctly. To resolve this, Datadog recommends using the [Custom Processor][8] to flatten the nested `resource` object. diff --git a/hugo/content/en/observability_pipelines/sources/splunk_hec.md b/hugo/content/en/observability_pipelines/sources/splunk_hec.md index 9fd0612f5a2..e5708151104 100644 --- a/hugo/content/en/observability_pipelines/sources/splunk_hec.md +++ b/hugo/content/en/observability_pipelines/sources/splunk_hec.md @@ -13,7 +13,7 @@ products: Use Observability Pipelines' Splunk HTTP Event Collector (HEC) source to receive logs from your Splunk HEC. You can choose to store the HEC token as event metadata and: -- Send logs from Observability Pipelines to Splunk HEC with the original token sent with the event. +- Send logs from {{< prodname >}}Observability Pipelines{{< /prodname >}} to Splunk HEC with the original token sent with the event. - Use the Enrichment Table processor to append a log field from your lookup file based on the token in the metadata, and then process and route your logs based on the value of that field. **Notes**: @@ -50,7 +50,7 @@ After you select the Splunk HEC source in the pipeline UI: #### Configure authentication tokens -If you store Splunk HEC tokens in your HTTP request's authorization header, you can configure Observability Pipelines to check if incoming HTTP requests have a valid token. Request events that do not have a valid token are dropped. +If you store Splunk HEC tokens in your HTTP request's authorization header, you can configure {{< prodname >}}Observability Pipelines{{< /prodname >}} to check if incoming HTTP requests have a valid token. Request events that do not have a valid token are dropped. To configure authentication tokens, enable the {{< ui >}}Configure authentication tokens{{< /ui >}} toggle: diff --git a/hugo/content/en/observability_pipelines/sources/syslog.md b/hugo/content/en/observability_pipelines/sources/syslog.md index 78abd4ca561..81577151000 100644 --- a/hugo/content/en/observability_pipelines/sources/syslog.md +++ b/hugo/content/en/observability_pipelines/sources/syslog.md @@ -66,7 +66,7 @@ After you select the Syslog source in the pipeline UI: ## Forward third-party logs to the Observability Pipelines Worker -Syslog is a widely used logging protocol for sending network logs to a central server. Many network devices support syslog output, so you can forward third-party logs to the Observability Pipelines's syslog source for processing and routing. Examples of these third-party services include: +Syslog is a widely used logging protocol for sending network logs to a central server. Many network devices support syslog output, so you can forward third-party logs to the {{< prodname >}}Observability Pipelines{{< /prodname >}}'s syslog source for processing and routing. Examples of these third-party services include: ### Fortinet - [Configure log forwarding][2] diff --git a/hugo/content/en/observability_pipelines/sources/websocket.md b/hugo/content/en/observability_pipelines/sources/websocket.md index 55f685a5713..89f6fe31b51 100644 --- a/hugo/content/en/observability_pipelines/sources/websocket.md +++ b/hugo/content/en/observability_pipelines/sources/websocket.md @@ -20,7 +20,7 @@ Use Observability Pipelines' WebSocket source to connect the Observability Pipel ## Prerequisites -To use Observability Pipelines' WebSocket source, you must have the following information: +To use {{< prodname >}}Observability Pipelines{{< /prodname >}}' WebSocket source, you must have the following information: - The full WebSocket URI that the Observability Pipelines Worker connects to, such as `wss://example.com/stream`. - If the endpoint requires authentication, the credentials for your chosen authorization strategy (a username and password, a bearer token, or a custom `Authorization` header value). diff --git a/hugo/content/en/opentelemetry/compatibility.md b/hugo/content/en/opentelemetry/compatibility.md index c074f1787fd..2084d48c056 100644 --- a/hugo/content/en/opentelemetry/compatibility.md +++ b/hugo/content/en/opentelemetry/compatibility.md @@ -67,7 +67,7 @@ Datadog SDKs provide support for the OpenTelemetry Traces, Metrics, and Logs API ### Agent Observability -OpenTelemetry traces that have [generative AI attributes](https://opentelemetry.io/docs/specs/semconv/gen-ai/gen-ai-spans/) are automatically converted into Agent Observability traces. To disable this conversion, see [Disabling Agent Observability conversion][38]. +OpenTelemetry traces that have [generative AI attributes](https://opentelemetry.io/docs/specs/semconv/gen-ai/gen-ai-spans/) are automatically converted into {{< prodname >}}Agent Observability{{< /prodname >}} traces. To disable this conversion, see [Disabling Agent Observability conversion][38]. ### Runtime metrics diff --git a/hugo/content/en/opentelemetry/getting_started/otel_demo_to_datadog.md b/hugo/content/en/opentelemetry/getting_started/otel_demo_to_datadog.md index 2b0215a48e5..9ba7297b5fe 100644 --- a/hugo/content/en/opentelemetry/getting_started/otel_demo_to_datadog.md +++ b/hugo/content/en/opentelemetry/getting_started/otel_demo_to_datadog.md @@ -376,7 +376,7 @@ The OpenTelemetry Demo includes a feature flag engine for simulating error scena The Datadog Extension allows you to view OpenTelemetry Collector configuration within Datadog on either one of the following pages: - [Infrastructure List][14]. -- [Resource Catalog][15]. +- [{{< prodname >}}Resource Catalog{{< /prodname >}}][15]. When selecting the hostname where the Collector is running, you can visualize its full configuration: diff --git a/hugo/content/en/opentelemetry/guide/_index.md b/hugo/content/en/opentelemetry/guide/_index.md index 41febe5114b..81534e5b3aa 100644 --- a/hugo/content/en/opentelemetry/guide/_index.md +++ b/hugo/content/en/opentelemetry/guide/_index.md @@ -32,6 +32,6 @@ private: true {{< nextlink href="https://www.datadoghq.com/about/latest-news/press-releases/datadog-announces-opentelemetry-protocol-support/" >}}OTLP ingestion in the Agent{{< /nextlink >}} {{< nextlink href="https://www.datadoghq.com/blog/aws-opentelemetry-lambda-layer-datadog/" >}}Learn more about AWS's managed Lambda Layer for OpenTelemetry{{< /nextlink >}} {{< nextlink href="https://www.datadoghq.com/blog/correlate-traces-datadog-rum-otel/" >}}Correlate Datadog RUM events with traces from OpenTelemetry-instrumented applications{{< /nextlink >}} -{{< nextlink href="https://www.datadoghq.com/blog/opentelemetry-runtime-metrics-datadog/" >}}Monitor runtime metrics from OTel-instrumented apps with Datadog APM{{< /nextlink >}} +{{< nextlink href="https://www.datadoghq.com/blog/opentelemetry-runtime-metrics-datadog/" >}}Monitor runtime metrics from OTel-instrumented apps with {{< prodname >}}Datadog APM{{< /prodname >}}{{< /nextlink >}} {{< nextlink href="https://www.datadoghq.com/blog/datadog-distribution-otel-collector/" >}}Unify OpenTelemetry and Datadog with the DDOT Collector{{< /nextlink >}} {{< /whatsnext >}} diff --git a/hugo/content/en/opentelemetry/integrations/datadog_extension.md b/hugo/content/en/opentelemetry/integrations/datadog_extension.md index 1621ad7b6c9..b6bcf6b3419 100644 --- a/hugo/content/en/opentelemetry/integrations/datadog_extension.md +++ b/hugo/content/en/opentelemetry/integrations/datadog_extension.md @@ -16,7 +16,7 @@ further_reading: As of OpenTelemetry Collector Contrib [modules v0.129.0][4] and newer, the Datadog Extension is included in [contrib distributions][5] of OpenTelemetry Collector. It is also available for [custom builds][6] of OpenTelemetry Collector. In the [DDOT Collector][8], the extension is automatically enabled. -The Datadog Extension allows you to view OpenTelemetry Collector configuration and build information directly in Datadog using [Fleet Automation][7], the [Infrastructure List][2], and [Resource Catalog][3]. When used with the [Datadog Exporter][1], this extension gives you visibility into your Collector fleet without leaving the Datadog UI. +The Datadog Extension allows you to view OpenTelemetry Collector configuration and build information directly in Datadog using [Fleet Automation][7], the [Infrastructure List][2], and [{{< prodname >}}Resource Catalog{{< /prodname >}}][3]. When used with the [Datadog Exporter][1], this extension gives you visibility into your Collector fleet without leaving the Datadog UI. {{< img src="/agent/fleet_automation/fleet-automation-pipeline-view.png" alt="View OTel Collector configurations with Pipeline Visualization in Fleet Automation" style="width:100%;" >}} diff --git a/hugo/content/en/opentelemetry/setup/ddot_collector/install/kubernetes_daemonset.md b/hugo/content/en/opentelemetry/setup/ddot_collector/install/kubernetes_daemonset.md index a0b087050b5..e72aa458761 100644 --- a/hugo/content/en/opentelemetry/setup/ddot_collector/install/kubernetes_daemonset.md +++ b/hugo/content/en/opentelemetry/setup/ddot_collector/install/kubernetes_daemonset.md @@ -702,7 +702,7 @@ To send telemetry data to Datadog, the following components are defined in the c ##### Datadog connector -The [Datadog connector][6] computes Datadog APM trace metrics. +The [Datadog connector][6] computes {{< prodname >}}Datadog APM{{< /prodname >}} trace metrics. {{< code-block lang="yaml" filename="otel-config.yaml" disable_copy="false" collapsible="true" >}} connectors: diff --git a/hugo/content/en/opentelemetry/setup/ddot_collector/install/kubernetes_gateway.md b/hugo/content/en/opentelemetry/setup/ddot_collector/install/kubernetes_gateway.md index 889d0fb7014..78a7e10beae 100644 --- a/hugo/content/en/opentelemetry/setup/ddot_collector/install/kubernetes_gateway.md +++ b/hugo/content/en/opentelemetry/setup/ddot_collector/install/kubernetes_gateway.md @@ -1341,7 +1341,7 @@ Deploy each layer as a separate Helm release, starting from the final layer and ## View gateway pods on Fleet Automation -The DDOT Collector gateway includes the [Datadog extension][11] by default. This extension exports Collector build information and configurations to Datadog, allowing you to monitor your telemetry pipeline from Infrastructure Monitoring and Fleet Automation. +The DDOT Collector gateway includes the [Datadog extension][11] by default. This extension exports Collector build information and configurations to Datadog, allowing you to monitor your telemetry pipeline from {{< prodname >}}Infrastructure Monitoring{{< /prodname >}} and Fleet Automation. To view your gateway pods: diff --git a/hugo/content/en/opentelemetry/setup/ddot_collector/install/linux.md b/hugo/content/en/opentelemetry/setup/ddot_collector/install/linux.md index a069450fb91..276a4c725de 100644 --- a/hugo/content/en/opentelemetry/setup/ddot_collector/install/linux.md +++ b/hugo/content/en/opentelemetry/setup/ddot_collector/install/linux.md @@ -186,7 +186,7 @@ To send telemetry data to Datadog, the following components are defined in the c ##### Datadog connector -The [Datadog connector][4] computes Datadog APM trace metrics. +The [Datadog connector][4] computes {{< prodname >}}Datadog APM{{< /prodname >}} trace metrics. {{< code-block lang="yaml" filename="otel-config.yaml" disable_copy="false" collapsible="true" >}} connectors: diff --git a/hugo/content/en/opentelemetry/setup/ddot_collector/install/windows.md b/hugo/content/en/opentelemetry/setup/ddot_collector/install/windows.md index 15b5b51b6e5..0a3323dcd9b 100644 --- a/hugo/content/en/opentelemetry/setup/ddot_collector/install/windows.md +++ b/hugo/content/en/opentelemetry/setup/ddot_collector/install/windows.md @@ -188,7 +188,7 @@ To send telemetry data to Datadog, the following components are defined in the c ##### Datadog connector -The [Datadog connector][4] computes Datadog APM trace metrics. +The [Datadog connector][4] computes {{< prodname >}}Datadog APM{{< /prodname >}} trace metrics. {{< code-block lang="yaml" filename="otel-config.yaml" disable_copy="false" collapsible="true" >}} connectors: diff --git a/hugo/content/en/opentelemetry/setup/otlp_ingest_in_the_agent.md b/hugo/content/en/opentelemetry/setup/otlp_ingest_in_the_agent.md index 91cb86462e9..420e8b95c22 100644 --- a/hugo/content/en/opentelemetry/setup/otlp_ingest_in_the_agent.md +++ b/hugo/content/en/opentelemetry/setup/otlp_ingest_in_the_agent.md @@ -21,7 +21,7 @@ further_reading: OTLP Ingest in the Agent is a way to send telemetry data directly from applications instrumented with [OpenTelemetry SDKs][1] to Datadog Agent. Since versions 6.32.0 and 7.32.0, the Datadog Agent can ingest OTLP traces and [OTLP metrics][2] through gRPC or HTTP. Since versions 6.48.0 and 7.48.0, the Datadog Agent can ingest OTLP logs through gRPC or HTTP. -OTLP Ingest in the Agent allows you to use observability features in the Datadog Agent. Data from applications instrumented with OpenTelemetry SDK cannot be used in some Datadog proprietary products, such as App and API Protection, Continuous Profiler, and Ingestion Rules. [OpenTelemetry Runtime Metrics are supported for some languages][10]. +OTLP Ingest in the Agent allows you to use observability features in the Datadog Agent. Data from applications instrumented with OpenTelemetry SDK cannot be used in some Datadog proprietary products, such as {{< prodname >}}App and API Protection{{< /prodname >}}, Continuous Profiler, and Ingestion Rules. [OpenTelemetry Runtime Metrics are supported for some languages][10]. {{< img src="/opentelemetry/setup/dd-agent-otlp-ingest.png" alt="Diagram: OpenTelemetry SDK sends data through OTLP protocol to a Collector with Datadog Exporter, which forwards to Datadog's platform." style="width:100%;" >}} diff --git a/hugo/content/en/partners/cloud_cost_management/_index.md b/hugo/content/en/partners/cloud_cost_management/_index.md index 2c1cd12a47b..5ffa599a8be 100644 --- a/hugo/content/en/partners/cloud_cost_management/_index.md +++ b/hugo/content/en/partners/cloud_cost_management/_index.md @@ -6,7 +6,7 @@ cascade: subcategory: 'Cloud Cost Management' --- -As a **Managed Service Provider (MSP) partner**, you can use Cloud Cost Management to provide your customers with secure, actionable insights into their cloud spending. +As a **Managed Service Provider (MSP) partner**, you can use {{< prodname >}}Cloud Cost Management{{< /prodname >}} to provide your customers with secure, actionable insights into their cloud spending. {{< whatsnext desc="To start managing cloud costs with Cloud Cost Management, see the following documentation.">}} {{< nextlink href="/partners/cloud_cost_management/aws">}}AWS: Set up AWS cost visibility for your customers.{{< /nextlink >}} diff --git a/hugo/content/en/pr_gates/_index.md b/hugo/content/en/pr_gates/_index.md index 094d6def0ac..14b9e857f4d 100644 --- a/hugo/content/en/pr_gates/_index.md +++ b/hugo/content/en/pr_gates/_index.md @@ -47,13 +47,13 @@ further_reading: ## Overview -PR Gates allow you to control software security and quality by configuring rules to block pull requests with substandard code from being merged. Preventing pull requests with substandard code from being merged can ensure that the code that is eventually deployed to production adheres to high organizational standards, reducing incidents and minimizing unwanted behaviors. +{{< prodname >}}PR Gates{{< /prodname >}} allow you to control software security and quality by configuring rules to block pull requests with substandard code from being merged. Preventing pull requests with substandard code from being merged can ensure that the code that is eventually deployed to production adheres to high organizational standards, reducing incidents and minimizing unwanted behaviors. {{< img src="pr_gates/setup/sca_4.png" alt="An SCA rule that triggers a failure if any library vulnerabilities with critical or high severity are detected in the repository." style="width:100%" >}} -PR Gates, similar to [Datadog Monitors][9], consume data and findings output by compatible Datadog products and apply conditions to these findings to determine if a PR meets your organizational standards. To prevent unnecessary impact on your developers' velocity, PR Gates only block on violations introduced by the code changes of the PR in question, not on findings that already existed in your repository before the PR and its branch were created. For example, if you configure PR Gates to block on Critical-severity code vulnerabilities, PR Gates fails and blocks the PR only if a developer introduces a new Critical code vulnerability as part of that PR. +{{< prodname >}}PR Gates{{< /prodname >}}, similar to [Datadog Monitors][9], consume data and findings output by compatible Datadog products and apply conditions to these findings to determine if a PR meets your organizational standards. To prevent unnecessary impact on your developers' velocity, {{< prodname >}}PR Gates{{< /prodname >}} only block on violations introduced by the code changes of the PR in question, not on findings that already existed in your repository before the PR and its branch were created. For example, if you configure {{< prodname >}}PR Gates{{< /prodname >}} to block on Critical-severity code vulnerabilities, {{< prodname >}}PR Gates{{< /prodname >}} fails and blocks the PR only if a developer introduces a new Critical code vulnerability as part of that PR. -You can configure PR Gates rules for the following categories. Please note that the compatible product must be running on your desired repositories before PR Gates can begin taking action on the relevant PRs: +You can configure {{< prodname >}}PR Gates{{< /prodname >}} rules for the following categories. Please note that the compatible product must be running on your desired repositories before {{< prodname >}}PR Gates{{< /prodname >}} can begin taking action on the relevant PRs: | Source type | Condition types | | --- | ----------- | @@ -64,15 +64,15 @@ You can configure PR Gates rules for the following categories. Please note that | [**Secret Scanning**][10] | - Leaked secrets | | [**New Flaky Tests**][11] | - New flaky tests | -After creating PR Gates rules, Datadog will automatically create checks on your pull requests using the [GitHub integration][5] or [Azure DevOps Source Code integration][6]. Set those checks as required in GitHub or Azure DevOps when you are ready to enforce them. +After creating {{< prodname >}}PR Gates{{< /prodname >}} rules, Datadog will automatically create checks on your pull requests using the [GitHub integration][5] or [Azure DevOps Source Code integration][6]. Set those checks as required in GitHub or Azure DevOps when you are ready to enforce them.
- PR Gates are not supported in pull requests in public repositories, or on pull requests targeting a destination branch in a different repository from the source branch (that is, forked repositories trying to merge into the main repository). PR Gates can not be set as required on GitHub repositories using a merge queue. + {{< prodname >}}PR Gates{{< /prodname >}} are not supported in pull requests in public repositories, or on pull requests targeting a destination branch in a different repository from the source branch (that is, forked repositories trying to merge into the main repository). {{< prodname >}}PR Gates{{< /prodname >}} can not be set as required on GitHub repositories using a merge queue.
## Rule types -PR Gates offers the following rule types: +{{< prodname >}}PR Gates{{< /prodname >}} offers the following rule types: {{< tabs >}} {{% tab "Static Code Analysis (SAST)" %}} @@ -128,7 +128,7 @@ To create a PR Gate rule, see the [Setup documentation][7]. ## Manage rules -You can manage and update PR Gates rules on the [{{< ui >}}PR Gates Rules{{< /ui >}}][8] page. Improve your security and quality practices based on your project requirements and risk tolerances. +You can manage and update {{< prodname >}}PR Gates{{< /prodname >}} rules on the [{{< ui >}}PR Gates Rules{{< /ui >}}][8] page. Improve your security and quality practices based on your project requirements and risk tolerances. You can see all of the rules defined by the organization. diff --git a/hugo/content/en/pr_gates/setup/_index.md b/hugo/content/en/pr_gates/setup/_index.md index 65024854fed..26e1f98b4fb 100644 --- a/hugo/content/en/pr_gates/setup/_index.md +++ b/hugo/content/en/pr_gates/setup/_index.md @@ -15,11 +15,11 @@ To use Datadog PR Gates, you can define one or more rules on the [{{< ui >}}PR G {{< img src="pr_gates/rules_list_3.png" alt="PR Gates page in Datadog" style="width:100%" >}} -PR Gates ensure that only the code changes that meet your security and quality standards is merged. +{{< prodname >}}PR Gates{{< /prodname >}} ensure that only the code changes that meet your security and quality standards is merged. ## Create a rule -To create a PR Gates rule in Datadog: +To create a {{< prodname >}}PR Gates{{< /prodname >}} rule in Datadog: 1. Navigate to [{{< ui >}}Software Delivery{{< /ui >}} > {{< ui >}}PR Gates{{< /ui >}} > {{< ui >}}PR Gate Rules{{< /ui >}}][1] and click {{< ui >}}New Rule{{< /ui >}}. @@ -50,17 +50,17 @@ To create a PR Gates rule in Datadog: 1. Click {{< ui >}}Create Rule{{< /ui >}}. -1. It is recommended that you test your PR Gate rule by creating a new branch and PR that purposely introduces code changes that would violate the rule's condition. Please note that PR Gates will not: +1. It is recommended that you test your PR Gate rule by creating a new branch and PR that purposely introduces code changes that would violate the rule's condition. Please note that {{< prodname >}}PR Gates{{< /prodname >}} will not: - Retroactively block existing PRs unless new commits are pushed to them after the PR Gate rule has been created - Block new PRs that don't introduce violations as part of their modified lines ### Manage PR checks -PR Gates automatically create PR checks in [GitHub][4] or [Azure DevOps][5] pull requests for each rule type evaluated. The check contains additional information about the rule evaluation, such as the failure reason and the matching events in Datadog. +{{< prodname >}}PR Gates{{< /prodname >}} automatically create PR checks in [GitHub][4] or [Azure DevOps][5] pull requests for each rule type evaluated. The check contains additional information about the rule evaluation, such as the failure reason and the matching events in Datadog. -
Note: Re-running a check in the pull request UI does not re-run the corresponding PR Gates rule.
+
Note: Re-running a check in the pull request UI does not re-run the corresponding {{< prodname >}}PR Gates{{< /prodname >}} rule.
-To ensure PR Gates are able to create PR checks, you must install the integration for your SCM provider. If you do not have the integration installed, follow the [GitHub][6] or [Azure DevOps Source Code][7] integration documentation to set one up. +To ensure {{< prodname >}}PR Gates{{< /prodname >}} are able to create PR checks, you must install the integration for your SCM provider. If you do not have the integration installed, follow the [GitHub][6] or [Azure DevOps Source Code][7] integration documentation to set one up. To make these checks blocking, they must be set as required in the branch policies of your source code management provider: @@ -69,7 +69,7 @@ To make these checks blocking, they must be set as required in the branch polici ## Manage rules -You can edit or delete a PR Gates rule by hovering over it on the [{{< ui >}}PR Gates Rules{{< /ui >}}][1] list and clicking the {{< ui >}}Edit{{< /ui >}} or {{< ui >}}Delete{{< /ui >}} icon. +You can edit or delete a {{< prodname >}}PR Gates{{< /prodname >}} rule by hovering over it on the [{{< ui >}}PR Gates Rules{{< /ui >}}][1] list and clicking the {{< ui >}}Edit{{< /ui >}} or {{< ui >}}Delete{{< /ui >}} icon. {{< img src="pr_gates/setup/delete_3.png" alt="Edit, clone, or delete a PR Gates rule" style="width:100%;">}} diff --git a/hugo/content/en/product_analytics/_index.md b/hugo/content/en/product_analytics/_index.md index 538b3f01d34..b2e6a11d6fd 100644 --- a/hugo/content/en/product_analytics/_index.md +++ b/hugo/content/en/product_analytics/_index.md @@ -34,13 +34,13 @@ further_reading: text: "Make data-driven design decisions with Product Analytics" --- -{{< learning-center-callout header="Try Getting Started with Product Analytics in the Learning Center" btn_title="Enroll Now" btn_url="https://learn.datadoghq.com/courses/getting-started-product-analytics">}} - Learn how to define meaningful digital product metrics and visualize them in Product Analytics with a Datadog trial account. Enroll for free today! +{{< learning-center-callout header="Try Getting Started with {{< prodname >}}Product Analytics{{< /prodname >}} in the Learning Center" btn_title="Enroll Now" btn_url="https://learn.datadoghq.com/courses/getting-started-product-analytics">}} + Learn how to define meaningful digital product metrics and visualize them in {{< prodname >}}Product Analytics{{< /prodname >}} with a Datadog trial account. Enroll for free today! {{< /learning-center-callout >}} ## Overview -Product Analytics helps you gain insight into user behavior and make data-driven decisions. It supports the following use cases in your application: +{{< prodname >}}Product Analytics{{< /prodname >}} helps you gain insight into user behavior and make data-driven decisions. It supports the following use cases in your application: - [Understand product adoption](#understand-product-adoption) - [Track conversion rates and their evolution over time](#track-conversion-rates-and-their-evolution-over-time) @@ -49,17 +49,17 @@ Product Analytics helps you gain insight into user behavior and make data-driven ## Instrument your application -Product Analytics collects client-side user activity data through the Datadog SDK. You can also send server-side events through the API to supplement your client-side data. +{{< prodname >}}Product Analytics{{< /prodname >}} collects client-side user activity data through the Datadog SDK. You can also send server-side events through the API to supplement your client-side data. To get started, [add the Datadog SDK](#track-client-side-events-sdk) to your application and [enable Product Analytics](#enable-product-analytics) in Datadog. You can also [send server-side events through the API](#track-server-side-events-api). -
Product Analytics uses the same SDKs and configuration as Real User Monitoring (RUM), and retains data for 15 months by default. See Datadog's data retention periods for more information.
+
{{< prodname >}}Product Analytics{{< /prodname >}} uses the same SDKs and configuration as Real User Monitoring (RUM), and retains data for 15 months by default. See Datadog's data retention periods for more information.
### Track client-side events (SDK) Collect events, such as pageviews or button clicks, from your users' devices, and send them to Datadog. -Add the Datadog SDK to your application to start collecting user activity data. If you have already configured RUM, you do not need to instrument your application again for Product Analytics. +Add the Datadog SDK to your application to start collecting user activity data. If you have already configured RUM, you do not need to instrument your application again for {{< prodname >}}Product Analytics{{< /prodname >}}. If you do not have an application set up in Datadog yet, follow the instructions for your platform: @@ -77,10 +77,10 @@ After you set up client-side collection, you can use the [Product Analytics API] ## Enable Product Analytics -For each application you want to monitor user behavior for, enable Product Analytics: +For each application you want to monitor user behavior for, enable {{< prodname >}}Product Analytics{{< /prodname >}}: 1. In Datadog, go to {{< ui >}}Digital Experience{{< /ui >}} > {{< ui >}}Real User Monitoring{{< /ui >}} > [{{< ui >}}Manage Applications{{< /ui >}}][9]. In the list of applications under {{< ui >}}Active{{< /ui >}}, select the application you want to monitor. -2. Under {{< ui >}}PRODUCT SETTINGS{{< /ui >}}, click {{< ui >}}Product Analytics{{< /ui >}}. +2. Under {{< ui >}}PRODUCT SETTINGS{{< /ui >}}, click {{< ui >}}{{< prodname >}}Product Analytics{{< /prodname >}}{{< /ui >}}. 3. Click the {{< ui >}}Enable{{< /ui >}} button. {{< img src="product_analytics/enable-product-analytics.png" alt="Enable Product Analytics from the Application Management page.">}} @@ -104,7 +104,7 @@ The Datadog SDK automatically collects three levels of client-side user data: Se Each Product Analytics feature provides context about your users' journeys. ### Understand product adoption -The [Home][3] page gives you a bird's-eye view of your users' activity and your product's adoption. This is where you most often land when accessing Product Analytics. +The [Home][3] page gives you a bird's-eye view of your users' activity and your product's adoption. This is where you most often land when accessing {{< prodname >}}Product Analytics{{< /prodname >}}. {{< img src="/product_analytics/pana_home_page.png" alt="Understand end-to-end conversions with Funnel Analysis.">}} @@ -163,7 +163,7 @@ Use the following features to inform your product change decisions, such as chan : Capture and replay your users' web browsing or mobile app experience.

This is beneficial for error identification, reproduction, and resolution, and provides insights into your application's usage patterns and design pitfalls. [Heatmaps][10] -: Visualize your users' interactions overlaid on Session Replay data. Product Analytics has three types of heatmaps: Click maps, Top elements, and Scroll maps.

Use heatmaps to review complex data at a glance, gaining insights into optimizing your user experience. +: Visualize your users' interactions overlaid on Session Replay data. {{< prodname >}}Product Analytics{{< /prodname >}} has three types of heatmaps: Click maps, Top elements, and Scroll maps.

Use heatmaps to review complex data at a glance, gaining insights into optimizing your user experience. [Playlist][12] : Create a playlist of Session Replays to organize them by any patterns you notice. Learn more about [Session Replay Playlists][12]. diff --git a/hugo/content/en/product_analytics/action_management.md b/hugo/content/en/product_analytics/action_management.md index c3416d013c2..8a1ba09a474 100644 --- a/hugo/content/en/product_analytics/action_management.md +++ b/hugo/content/en/product_analytics/action_management.md @@ -25,7 +25,7 @@ Use labeled actions to: After you create a labeled action, Datadog applies the name retroactively to all matching interactions in your recorded data. This includes historical interactions, not only new ones going forward. -Labeled actions work across all Product Analytics charts and help improve trust in your dataset and efficiency in your analysis. +Labeled actions work across all {{< prodname >}}Product Analytics{{< /prodname >}} charts and help improve trust in your dataset and efficiency in your analysis. Two labeling methods are available: - [**Visual labeling**](#visual-labeling): A point-and-click interface for labeling actions on web pages. Requires the Datadog test recorder Chrome extension. @@ -61,7 +61,7 @@ Visual labeling requires [the Datadog test recorder Chrome extension][1]. If you 3. Add or remove tracked elements, and update the name or CSS selector as needed. 4. Click {{< ui >}}Save labeled action{{< /ui >}}. -After you define an action, it appears in the list of labeled actions on the [Actions][3] page, and you can use it in any Product Analytics chart. +After you define an action, it appears in the list of labeled actions on the [Actions][3] page, and you can use it in any {{< prodname >}}Product Analytics{{< /prodname >}} chart. ## Manual labeling {#manual-labeling} @@ -77,7 +77,7 @@ Manual labeling is available for both web and mobile applications and does not r Select {{< ui >}}Add New Definition{{< /ui >}} to add a definition. 5. Select **Save**. -After you define an action, it appears in the list of labeled actions on the [Actions][3] page, and you can use it in any Product Analytics chart. +After you define an action, it appears in the list of labeled actions on the [Actions][3] page, and you can use it in any {{< prodname >}}Product Analytics{{< /prodname >}} chart. ## Retrieve your actions After you define an action, you can find it on the [Actions][3] page. diff --git a/hugo/content/en/product_analytics/charts/analytics_explorer/events.md b/hugo/content/en/product_analytics/charts/analytics_explorer/events.md index dd9993cb6cb..ed044c1392f 100644 --- a/hugo/content/en/product_analytics/charts/analytics_explorer/events.md +++ b/hugo/content/en/product_analytics/charts/analytics_explorer/events.md @@ -22,11 +22,11 @@ Context about your users and their applications, including the OS, country, code To open the event side panel in the [Analytics Explorer][1], click on a table row in the {{< ui >}}List{{< /ui >}} visualization type. Alternatively, click in the side panel list displayed after you click on {{< ui >}}Show related events{{< /ui >}}. -The event side panel displays all the information relative to a Product Analytics event. The waterfall displays related views and actions. +The event side panel displays all the information relative to a {{< prodname >}}Product Analytics{{< /prodname >}} event. The waterfall displays related views and actions. ## Attributes -Product Analytics collects contextual information by default. You can also add additional context attributes with the [Global Context API][2]. +{{< prodname >}}Product Analytics{{< /prodname >}} collects contextual information by default. You can also add additional context attributes with the [Global Context API][2]. {{< img src="real_user_monitoring/explorer/events/attributes.png" alt="Attribute tab" width="80%" >}} diff --git a/hugo/content/en/product_analytics/charts/analytics_explorer/export.md b/hugo/content/en/product_analytics/charts/analytics_explorer/export.md index 66c541c92bc..e883e61982d 100644 --- a/hugo/content/en/product_analytics/charts/analytics_explorer/export.md +++ b/hugo/content/en/product_analytics/charts/analytics_explorer/export.md @@ -19,7 +19,7 @@ further_reading: ## Overview -You can use your Product Analytics query and visualization graphs in dashboards, monitors, and notebooks. +You can use your {{< prodname >}}Product Analytics{{< /prodname >}} query and visualization graphs in dashboards, monitors, and notebooks. ## Export the search query or visualization @@ -29,7 +29,7 @@ Copy, export, or download your aggregated search query and visualization graphs Click the {{< ui >}}More{{< /ui >}} button on the right hand corner and select an option from the dropdown menu: -- Download your search results as a CSV file for individual Product Analytics events and specific aggregations. You can export up to 5,000 individual Product Analytics events with lists and up to 500 aggregations for timeseries, top lists, and table graphs. +- Download your search results as a CSV file for individual {{< prodname >}}Product Analytics{{< /prodname >}} events and specific aggregations. You can export up to 5,000 individual {{< prodname >}}Product Analytics{{< /prodname >}} events with lists and up to 500 aggregations for timeseries, top lists, and table graphs. ## Further Reading diff --git a/hugo/content/en/product_analytics/charts/analytics_explorer/group.md b/hugo/content/en/product_analytics/charts/analytics_explorer/group.md index 654c26e5cad..153bec823b6 100644 --- a/hugo/content/en/product_analytics/charts/analytics_explorer/group.md +++ b/hugo/content/en/product_analytics/charts/analytics_explorer/group.md @@ -8,7 +8,7 @@ further_reading: ## Overview -Product Analytics events are valuable both individually and collectively. The search query contains information to aggregate a subset of events. +{{< prodname >}}Product Analytics{{< /prodname >}} events are valuable both individually and collectively. The search query contains information to aggregate a subset of events. {{< img src="product_analytics/analytics/group/pana_group_search_bar.png" alt="Group into fields section of the Search query" style="width:100%;" >}} diff --git a/hugo/content/en/product_analytics/charts/analytics_explorer/visualize.md b/hugo/content/en/product_analytics/charts/analytics_explorer/visualize.md index 1537f45af0a..12eb07d3cf8 100644 --- a/hugo/content/en/product_analytics/charts/analytics_explorer/visualize.md +++ b/hugo/content/en/product_analytics/charts/analytics_explorer/visualize.md @@ -14,7 +14,7 @@ Visualizations define the outcomes of the filters and aggregates displayed in th ## Timeseries -Visualize the evolution of a single measure (an attribute with a numerical value contained in your Product Analytics events), or a facet (unique count of values) over a selected time frame. +Visualize the evolution of a single measure (an attribute with a numerical value contained in your {{< prodname >}}Product Analytics{{< /prodname >}} events), or a facet (unique count of values) over a selected time frame. {{< img src="product_analytics/analytics/visualize/analytics-timeseries-2.png" alt="A view of the Timeseries graph in the Analytics Explorer" style="width:90%;" >}} @@ -70,7 +70,7 @@ The following pie chart shows the percentage breakdown by {{< ui >}}View Path{{< ## Geomaps -Visualize a single measure (an attribute with a numerical value contained in your Product Analytics events), or a facet (unique count of values) on the world map. +Visualize a single measure (an attribute with a numerical value contained in your {{< prodname >}}Product Analytics{{< /prodname >}} events), or a facet (unique count of values) on the world map. {{< img src="product_analytics/analytics/visualize/analytics-geomaps-1.png" alt="A view of the Geographical map in the Analytics Explorer" style="width:90%;">}} diff --git a/hugo/content/en/product_analytics/charts/chart_basics.md b/hugo/content/en/product_analytics/charts/chart_basics.md index 4d8bcb68609..3acaf8aa79f 100644 --- a/hugo/content/en/product_analytics/charts/chart_basics.md +++ b/hugo/content/en/product_analytics/charts/chart_basics.md @@ -21,7 +21,7 @@ further_reading: Charts help you turn user data into actionable insights by visualizing trends, funnels, and key product metrics. Use charts to answer common product questions, such as how users move through a funnel, how engagement changes over time, and how adoption varies across segments. -This page introduces the core charting capabilities available across Product Analytics, including: +This page introduces the core charting capabilities available across {{< prodname >}}Product Analytics{{< /prodname >}}, including: - [Creating charts](#create-a-chart) - [Saving individual charts](#save-a-chart) @@ -50,7 +50,7 @@ Share charts to make product insights available across dashboards, notebooks, an To add a chart to a dashboard or a notebook, click {{< ui >}}+ Add To{{< /ui >}} in the top-right corner of the chart. Then, select whether to add it to an existing dashboard or notebook, or to a new one. -To share a link to a chart, click {{< ui >}}Share{{< /ui >}} to copy the link to your clipboard. Then paste and share this link through the method of your choice. Team members with Datadog access are directed to the live chart in Product Analytics, while users without Datadog access see a static snapshot of the chart. +To share a link to a chart, click {{< ui >}}Share{{< /ui >}} to copy the link to your clipboard. Then paste and share this link through the method of your choice. Team members with Datadog access are directed to the live chart in {{< prodname >}}Product Analytics{{< /prodname >}}, while users without Datadog access see a static snapshot of the chart. {{< img src="product_analytics/chart_basics/pana_chart_basics_share_add.png" alt="Chart editor view showing the Add To button for sharing charts to a dashboard or to a notebook." style="width:100%;" >}} diff --git a/hugo/content/en/product_analytics/data_collected/_index.md b/hugo/content/en/product_analytics/data_collected/_index.md index ba895123e18..384c2a7b367 100644 --- a/hugo/content/en/product_analytics/data_collected/_index.md +++ b/hugo/content/en/product_analytics/data_collected/_index.md @@ -21,16 +21,16 @@ further_reading: ## Overview -Product Analytics collects user activity data as events. Each event has two types of data: +{{< prodname >}}Product Analytics{{< /prodname >}} collects user activity data as events. Each event has two types of data: - **Telemetry**: Quantifiable values used to track and compare activity (for example, `view.time_spent`). - **Attributes**: Descriptive values used to filter and break down measurements in your analysis (for example, `device.type` or `geo.country`). Every event includes the [default attributes](#default-attributes). Each event type also has [specific telemetry and attributes](#event-specific-attributes). -To identify individual users across sessions, Product Analytics relies on the `usr.id` and `usr.email` attributes. For unauthenticated users or visitors who never log in, the RUM SDK automatically assigns a `usr.anonymous_id` to track activity. See [Track unauthenticated users][4] for details. +To identify individual users across sessions, {{< prodname >}}Product Analytics{{< /prodname >}} relies on the `usr.id` and `usr.email` attributes. For unauthenticated users or visitors who never log in, the RUM SDK automatically assigns a `usr.anonymous_id` to track activity. See [Track unauthenticated users][4] for details. -
Product Analytics uses the same SDKs and configuration as Real User Monitoring (RUM) to collect data. Unlike RUM, Product Analytics does not collect Errors, Resources, Long Tasks, or Vitals events. For the full list of RUM event types and attributes, see the data collected pages for browser, iOS, and Android.
+
{{< prodname >}}Product Analytics{{< /prodname >}} uses the same SDKs and configuration as Real User Monitoring (RUM) to collect data. Unlike RUM, {{< prodname >}}Product Analytics{{< /prodname >}} does not collect Errors, Resources, Long Tasks, or Vitals events. For the full list of RUM event types and attributes, see the data collected pages for browser, iOS, and Android.
| Event Type | Retention | Description | |------------|-----------|-------------| diff --git a/hugo/content/en/product_analytics/data_collected/server_side_events.md b/hugo/content/en/product_analytics/data_collected/server_side_events.md index 6df0b0ab034..4a6350f1c39 100644 --- a/hugo/content/en/product_analytics/data_collected/server_side_events.md +++ b/hugo/content/en/product_analytics/data_collected/server_side_events.md @@ -37,7 +37,7 @@ For the full API reference, including authentication, required fields, and reque ## Analyze server-side events -After you send server-side events, they are available in any Product Analytics chart. In the event picker, select **Server Events** to scope your analysis to server-side data. +After you send server-side events, they are available in any {{< prodname >}}Product Analytics{{< /prodname >}} chart. In the event picker, select **Server Events** to scope your analysis to server-side data. ## Further reading diff --git a/hugo/content/en/product_analytics/export_pipelines.md b/hugo/content/en/product_analytics/export_pipelines.md index bc4eb4a242a..822c8c24389 100644 --- a/hugo/content/en/product_analytics/export_pipelines.md +++ b/hugo/content/en/product_analytics/export_pipelines.md @@ -20,7 +20,7 @@ Export Pipelines is in Preview. ## Overview -Export Pipelines stream your ingested Real User Monitoring (RUM) and Product Analytics events to a cloud storage bucket you own — Amazon S3, Azure Blob Storage, or Google Cloud Storage — in JSON or Parquet format. +Export Pipelines stream your ingested Real User Monitoring (RUM) and {{< prodname >}}Product Analytics{{< /prodname >}} events to a cloud storage bucket you own — Amazon S3, Azure Blob Storage, or Google Cloud Storage — in JSON or Parquet format. {{< img src="real_user_monitoring/rum_export/rum-export-overview.png" alt="Export Pipelines list on the RUM application settings page" style="width:100%;">}} @@ -32,7 +32,7 @@ Datadog only manages the export from your Datadog account to your cloud storage ## How it works -Export Pipelines is a shared feature between [Real User Monitoring][4] and [Product Analytics][5]. Pipelines are configured at two different levels: +Export Pipelines is a shared feature between [Real User Monitoring][4] and [{{< prodname >}}Product Analytics{{< /prodname >}}][5]. Pipelines are configured at two different levels: | Scope | Source | Max pipelines | Available presets | |---|---|---|---| @@ -46,7 +46,7 @@ Each pipeline exports continuously and independently of the others. ## Prerequisites -- Product Analytics is enabled on the application (or RUM, or both). +- {{< prodname >}}Product Analytics{{< /prodname >}} is enabled on the application (or RUM, or both). - The Datadog integration for your cloud provider is set up: [Amazon Web Services][6], [Azure][7], or [Google Cloud][8]. - Your Datadog user has the `rum_write_archives` permission. See [Role Based Access Control][1]. diff --git a/hugo/content/en/product_analytics/guide/_index.md b/hugo/content/en/product_analytics/guide/_index.md index ebf493d9346..d0bcb8a7bb5 100644 --- a/hugo/content/en/product_analytics/guide/_index.md +++ b/hugo/content/en/product_analytics/guide/_index.md @@ -10,7 +10,7 @@ cascade: --- {{< whatsnext desc="General Product Analytics:" >}} - {{< nextlink href="product_analytics/guide/rum_and_product_analytics" >}}Understanding RUM and Product Analytics{{< /nextlink >}} + {{< nextlink href="product_analytics/guide/rum_and_product_analytics" >}}Understanding RUM and {{< prodname >}}Product Analytics{{< /prodname >}}{{< /nextlink >}} {{< nextlink href="product_analytics/data_collected/server_side_events" >}}Track server-side events{{< /nextlink >}} {{< nextlink href="session_replay/guide/diagnose-funnel-drop-offs-with-session-replay" >}}Diagnose funnel drop-offs with Session Replay{{< /nextlink >}} {{< nextlink href="product_analytics/guide/monitor-utm-campaigns-in-product-analytics" >}}Monitor UTM Campaigns{{< /nextlink >}} diff --git a/hugo/content/en/product_analytics/guide/monitor-utm-campaigns-in-product-analytics.md b/hugo/content/en/product_analytics/guide/monitor-utm-campaigns-in-product-analytics.md index 5335320be9d..84fe14ca948 100644 --- a/hugo/content/en/product_analytics/guide/monitor-utm-campaigns-in-product-analytics.md +++ b/hugo/content/en/product_analytics/guide/monitor-utm-campaigns-in-product-analytics.md @@ -6,11 +6,11 @@ description: Learn how to use Product Analytics & Session Replay to monitor the ## Overview -Urchin Tracking Module (UTM) tracking is a parameter that can be added to a URL for tracking the performance of specific campaigns and identifying attribution paths for how visitors arrived on your website. This guide walks you through the types of UTM parameters Datadog Product Analytics collects and how you can use Product Analytics to monitor their use. +Urchin Tracking Module (UTM) tracking is a parameter that can be added to a URL for tracking the performance of specific campaigns and identifying attribution paths for how visitors arrived on your website. This guide walks you through the types of UTM parameters Datadog Product Analytics collects and how you can use {{< prodname >}}Product Analytics{{< /prodname >}} to monitor their use. ## Data collected -UTM campaigns are connected to [View][1] events in Product Analytics. The campaign data is collected automatically by the Browser SDK and can be viewed as facets in the Analytics Explorer. The UTM parameters Datadog collects can be defined as the following: +UTM campaigns are connected to [View][1] events in {{< prodname >}}Product Analytics{{< /prodname >}}. The campaign data is collected automatically by the Browser SDK and can be viewed as facets in the Analytics Explorer. The UTM parameters Datadog collects can be defined as the following: | Field | Type | Description | |-------------------------------|--------|---------------------------------------------------------------| diff --git a/hugo/content/en/product_analytics/guide/rum_and_product_analytics.md b/hugo/content/en/product_analytics/guide/rum_and_product_analytics.md index e85d12d4bbf..3fe32b09afb 100644 --- a/hugo/content/en/product_analytics/guide/rum_and_product_analytics.md +++ b/hugo/content/en/product_analytics/guide/rum_and_product_analytics.md @@ -10,7 +10,7 @@ further_reading: ## What is Product Analytics? -Product Analytics is a dedicated offering built for product managers, product owners, engineering leaders, and others who want to leverage real user behavior to drive product and business insights, without requiring knowledge of other Datadog observability products. +{{< prodname >}}Product Analytics{{< /prodname >}} is a dedicated offering built for product managers, product owners, engineering leaders, and others who want to leverage real user behavior to drive product and business insights, without requiring knowledge of other Datadog observability products. {{< img src="product_analytics/guide/understanding-PANA-RUM-summary.png" alt="Product Analytics in Datadog. Left nav displays Product Analytics as a title and contains the nav items Home, Charts, Dashboards, Session Replay, Users & Segments." style="width:100%;" >}} @@ -26,34 +26,34 @@ The transition happened on **June 1st 2025**. ### What is the difference between RUM and Product Analytics? - Both Product Analytics and Real User Monitoring rely on the Browser and/or Mobile SDKs. -- Product Analytics offers 15-month retention on behavioral events (Sessions, Views, and Actions). Real User Monitoring is dedicated to performance monitoring. -- Product Analytics uses the complete, unsampled dataset captured by the SDK. When paired with RUM without Limits, Product Analytics offers full visibility into user behavior, while RUM applies client-side sampling to support faster issue investigation and reduce noise. +- {{< prodname >}}Product Analytics{{< /prodname >}} offers 15-month retention on behavioral events (Sessions, Views, and Actions). Real User Monitoring is dedicated to performance monitoring. +- {{< prodname >}}Product Analytics{{< /prodname >}} uses the complete, unsampled dataset captured by the SDK. When paired with RUM without Limits, {{< prodname >}}Product Analytics{{< /prodname >}} offers full visibility into user behavior, while RUM applies client-side sampling to support faster issue investigation and reduce noise. - Users have the option to purchase both products together, or each individually. ### How are RUM customers affected? -As part of the introduction of Product Analytics, the following changes are being made for both existing and new RUM customers: +As part of the introduction of {{< prodname >}}Product Analytics{{< /prodname >}}, the following changes are being made for both existing and new RUM customers: -- **Product Analytics Summary**, **Retention Analytics**, and **Pathways** (formerly **Sankeys**) are now part of Product Analytics and are no longer available in beta/preview within RUM. +- **Product Analytics Summary**, **Retention Analytics**, and **Pathways** (formerly **Sankeys**) are now part of {{< prodname >}}Product Analytics{{< /prodname >}} and are no longer available in beta/preview within RUM. - **Heatmaps** remain available but have been relocated to the **Session Replay** tab for easier access and contextual relevance. - The **Funnel** and **Conversion** tabs continue to be available in the **RUM Explorer** as they existed before the split. To view conversion details, select the Funnel visualization and click on any step to open the **Conversion** panel. -These updates ensure a clearer separation of use cases between RUM and Product Analytics, enabling more focused workflows and deeper insights. +These updates ensure a clearer separation of use cases between RUM and {{< prodname >}}Product Analytics{{< /prodname >}}, enabling more focused workflows and deeper insights. ### How do I set up Product Analytics? -Product Analytics uses the same SDKs and configuration as RUM. To enable Product Analytics go to your [Application management][3] page and toggle the desired products +{{< prodname >}}Product Analytics{{< /prodname >}} uses the same SDKs and configuration as RUM. To enable {{< prodname >}}Product Analytics{{< /prodname >}} go to your [Application management][3] page and toggle the desired products -If RUM is already configured, no additional instrumentation is required for Product Analytics. +If RUM is already configured, no additional instrumentation is required for {{< prodname >}}Product Analytics{{< /prodname >}}. ### Why can I no longer access Sankeys (now Pathways) and Retention Analysis? -- These features were part of a preview and available to RUM customers as a beta, but were not part of the core RUM offering. These features are exclusively available to customers on a Product Analytics contract. +- These features were part of a preview and available to RUM customers as a beta, but were not part of the core RUM offering. These features are exclusively available to customers on a {{< prodname >}}Product Analytics{{< /prodname >}} contract. ### Is Session Replay available with Product Analytics? -[Session Replay][1] is a standalone offering that can be purchased alongside Product Analytics. +[Session Replay][1] is a standalone offering that can be purchased alongside {{< prodname >}}Product Analytics{{< /prodname >}}. ### What is available to RUM customers versus what is available to Product Analytics customers? See the full feature comparison table below. diff --git a/hugo/content/en/product_analytics/profiles/_index.md b/hugo/content/en/product_analytics/profiles/_index.md index 17e27a46e3f..d1df7ccb25e 100644 --- a/hugo/content/en/product_analytics/profiles/_index.md +++ b/hugo/content/en/product_analytics/profiles/_index.md @@ -165,7 +165,7 @@ To import attributes from a reference table or from an integration such as Sales {{< img src="product_analytics/add_table_and_key3.png" alt="select the data to be merged with your profiles." style="width:80%;" >}} -3. Select the {{< ui >}}join key{{< /ui >}} and the {{< ui >}}Product Analytics key{{< /ui >}} to merge the table with your profiles. Then, select which {{< ui >}}attributes{{< /ui >}} from the list to add to your profiles. +3. Select the {{< ui >}}join key{{< /ui >}} and the {{< ui >}}{{< prodname >}}Product Analytics{{< /prodname >}} key{{< /ui >}} to merge the table with your profiles. Then, select which {{< ui >}}attributes{{< /ui >}} from the list to add to your profiles. {{< img src="product_analytics/select_integration_attributes5.png" alt="The Configure import modal for Snowflake, showing the join key configuration and a list of selectable attributes with column names, types, and sample values." style="width:80%;" >}} diff --git a/hugo/content/en/product_analytics/profiles/identity_resolution.md b/hugo/content/en/product_analytics/profiles/identity_resolution.md index f8a94b3b3be..a72395e3940 100644 --- a/hugo/content/en/product_analytics/profiles/identity_resolution.md +++ b/hugo/content/en/product_analytics/profiles/identity_resolution.md @@ -15,7 +15,7 @@ further_reading: ## Overview -Identity Resolution enables Product Analytics to automatically connect anonymous user activity to authenticated users. When a user browses your application anonymously and later logs in, their pre-login behavior becomes associated with their authenticated identity. This gives you a complete view of the user journey without any additional instrumentation. +Identity Resolution enables {{< prodname >}}Product Analytics{{< /prodname >}} to automatically connect anonymous user activity to authenticated users. When a user browses your application anonymously and later logs in, their pre-login behavior becomes associated with their authenticated identity. This gives you a complete view of the user journey without any additional instrumentation. ## Prerequisites @@ -26,13 +26,13 @@ Identity Resolution enables Product Analytics to automatically connect anonymous DD_RUM.setUser({ id: 'user-123' }) ``` -- Product Analytics enabled for your organization. +- {{< prodname >}}Product Analytics{{< /prodname >}} enabled for your organization. No additional SDK configuration is required. Identity Resolution uses the anonymous ID the RUM SDK already generates and the user ID set through `setUser()`. ## Feature behavior -The following Product Analytics features automatically reflect resolved identity: +The following {{< prodname >}}Product Analytics{{< /prodname >}} features automatically reflect resolved identity: | Feature | Behavior | |---------|----------| @@ -47,7 +47,7 @@ The following Product Analytics features automatically reflect resolved identity **Cross-device**: Identity Resolution operates at the device level. A user who browses anonymously on one device and logs in on another does not have their sessions linked across devices. -**Data retention**: Identity mappings are retained for 15 months, aligned with standard Product Analytics retention. +**Data retention**: Identity mappings are retained for 15 months, aligned with standard {{< prodname >}}Product Analytics{{< /prodname >}} retention. **Historical data**: After enablement, historical queries resolve identity for any mappings in the 15-month window, including activity before you enabled the feature. diff --git a/hugo/content/en/product_analytics/segmentation/_index.md b/hugo/content/en/product_analytics/segmentation/_index.md index fa1db335584..4f215a9caef 100644 --- a/hugo/content/en/product_analytics/segmentation/_index.md +++ b/hugo/content/en/product_analytics/segmentation/_index.md @@ -32,9 +32,9 @@ To create a segment: {{% collapse-content title="Using Product Analytics data" level="h4" expanded=false id="segment-pana" %}} -To create a segment using Product Analytics data: +To create a segment using {{< prodname >}}Product Analytics{{< /prodname >}} data: -1. Select {{< ui >}}Product Analytics{{}} on the **[segment creation page](https://app.datadoghq.com/product-analytics/segments/create)**. +1. Select {{< ui >}}{{< prodname >}}Product Analytics{{< /prodname >}}{{}} on the **[segment creation page](https://app.datadoghq.com/product-analytics/segments/create)**. 2. Select a **condition** for the users in the segment: - **performed event(s)** @@ -79,9 +79,9 @@ To create a segment using an uploaded list of users from your own file: 2. Click {{< ui >}}Browse files{{< /ui >}} to upload your CSV file. -The file needs a column with user IDs or user emails to map with the `usr.id` or `usr.email` attributes in Product Analytics. +The file needs a column with user IDs or user emails to map with the `usr.id` or `usr.email` attributes in {{< prodname >}}Product Analytics{{< /prodname >}}. -The following example maps the Product Analytics attribute `@usr.id` to the column named `id` in the CSV file. +The following example maps the {{< prodname >}}Product Analytics{{< /prodname >}} attribute `@usr.id` to the column named `id` in the CSV file. {{< img src="product_analytics/segmentation/segment_link_csv.png" alt="A view of the CSV import page showing the options for mapping your file to Product Analytics attributes." style="width:80%">}} @@ -107,7 +107,7 @@ Add one or both conditions: **Importing with CSV** -Upload a CSV file with a column containing account IDs. The account IDs map to the account ID attribute in Product Analytics. +Upload a CSV file with a column containing account IDs. The account IDs map to the account ID attribute in {{< prodname >}}Product Analytics{{< /prodname >}}. {{% /collapse-content %}} diff --git a/hugo/content/en/product_analytics/usability.md b/hugo/content/en/product_analytics/usability.md index ca1d71a1c86..22bbfaf623c 100644 --- a/hugo/content/en/product_analytics/usability.md +++ b/hugo/content/en/product_analytics/usability.md @@ -34,12 +34,12 @@ User confusion | A user clicks dead elements, hunts for the right control, or hi ## Prerequisites -- **Session Replay and Product Analytics**: Enable both [Session Replay][1] and [Product Analytics][2] for your application. Datadog analyzes session replays and product analytics events to find friction. +- **Session Replay and {{< prodname >}}Product Analytics{{< /prodname >}}**: Enable both [Session Replay][1] and [{{< prodname >}}Product Analytics{{< /prodname >}}][2] for your application. Datadog analyzes session replays and product analytics events to find friction. - **Permission**: To trigger an analysis, users need the `session_replay_analysis_write` permission. This permission is included in the Datadog Standard and Admin roles. Administrators can grant this permission to custom roles through [Role-based access control][3]. ## Trigger an analysis -You start an analysis from a saved Product Analytics funnel, either from the funnel chart or from the Usability page. +You start an analysis from a saved {{< prodname >}}Product Analytics{{< /prodname >}} funnel, either from the funnel chart or from the Usability page. ### From a funnel diff --git a/hugo/content/en/profiler/automated_analysis.md b/hugo/content/en/profiler/automated_analysis.md index 69497b3226b..8fd3070a0b4 100644 --- a/hugo/content/en/profiler/automated_analysis.md +++ b/hugo/content/en/profiler/automated_analysis.md @@ -20,7 +20,7 @@ Automated Analysis automatically detects performance issues in your applications - A high-level summary explaining the issue and why it matters - Contextual insights from profiling data (for example, affected methods, packages, or processes) -- Recommended next steps to help you resolve the issue, with optional auto-generated fixes from [Bits Code][2] +- Recommended next steps to help you resolve the issue, with optional auto-generated fixes from [{{< prodname >}}Bits Code{{< /prodname >}}][2] This reduces the profiling expertise needed to identify and resolve performance issues in your applications that might otherwise go unnoticed. @@ -54,7 +54,7 @@ Each row represents an insight type, summarizing: You can filter insights by insight name, runtime, service, or environment to narrow the list to the most important insights. Teams often use this view to identify patterns, such as multiple services affected by the same inefficiency. Clicking on an insight opens its detail panel. ## Take action on insights -While viewing an insight, see {{< ui >}}Next Steps{{< /ui >}} to view Datadog recommendations for improvements. Alternatively, click {{< ui >}}Fix with Bits{{< /ui >}} to have [Bits Code][2] generate a fix. +While viewing an insight, see {{< ui >}}Next Steps{{< /ui >}} to view Datadog recommendations for improvements. Alternatively, click {{< ui >}}Fix with Bits{{< /ui >}} to have [{{< prodname >}}Bits Code{{< /prodname >}}][2] generate a fix. ## Supported insights diff --git a/hugo/content/en/real_user_monitoring/_index.md b/hugo/content/en/real_user_monitoring/_index.md index 98079792d34..9f4886c3417 100644 --- a/hugo/content/en/real_user_monitoring/_index.md +++ b/hugo/content/en/real_user_monitoring/_index.md @@ -209,7 +209,7 @@ The [RUM Performance Monitoring summary][1] page provides relevant and actionabl For **web apps**, use the search bar to filter data, identify slow pages, and follow the UI to the [RUM Optimization Inspect][17] page. -For **mobile apps**, review recent crashes at the bottom of the page and use the [Error Tracking][6] side panel for troubleshooting. +For **mobile apps**, review recent crashes at the bottom of the page and use the [{{< prodname >}}Error Tracking{{< /prodname >}}][6] side panel for troubleshooting. ### Out-of-the-box dashboards @@ -231,7 +231,7 @@ View your [backend traces, logs, and infrastructure metrics][5] down to the exac ### Error tracking and crash reporting -Get automated alerts on outliers and groups of errors, timeouts, and crashes to significantly reduce your MTTR with [Error Tracking][6]. +Get automated alerts on outliers and groups of errors, timeouts, and crashes to significantly reduce your MTTR with [{{< prodname >}}Error Tracking{{< /prodname >}}][6]. {{< img src="real_user_monitoring/error_tracking/errors_rum.mp4" alt="RUM error tracking" video=true >}} diff --git a/hugo/content/en/real_user_monitoring/application_monitoring/android/error_tracking.md b/hugo/content/en/real_user_monitoring/application_monitoring/android/error_tracking.md index 0c8c8e6eb6a..1214235d8f0 100644 --- a/hugo/content/en/real_user_monitoring/application_monitoring/android/error_tracking.md +++ b/hugo/content/en/real_user_monitoring/application_monitoring/android/error_tracking.md @@ -17,9 +17,9 @@ further_reading: ## Overview -Error Tracking processes errors collected from the Android SDK. +{{< prodname >}}Error Tracking{{< /prodname >}} processes errors collected from the Android SDK. -Enable Android Crash Reporting and Error Tracking to get comprehensive crash reports and error trends. With this feature, you can access: +Enable Android Crash Reporting and {{< prodname >}}Error Tracking{{< /prodname >}} to get comprehensive crash reports and error trends. With this feature, you can access: - Aggregated Android crash dashboards and attributes - Deobfuscated Android crash reports with stack trace mapping diff --git a/hugo/content/en/real_user_monitoring/application_monitoring/browser/build_plugins/_index.md b/hugo/content/en/real_user_monitoring/application_monitoring/browser/build_plugins/_index.md index 469fd99d14b..5745c37505b 100644 --- a/hugo/content/en/real_user_monitoring/application_monitoring/browser/build_plugins/_index.md +++ b/hugo/content/en/real_user_monitoring/application_monitoring/browser/build_plugins/_index.md @@ -162,7 +162,7 @@ datadogWebpackPlugin({ {{< whatsnext desc="Configure individual build plugins:" >}} {{< nextlink href="/real_user_monitoring/application_monitoring/browser/build_plugins/source_maps" >}}Source Maps: Automatically upload source maps to Datadog during your build, enabling deobfuscated stack traces.{{< /nextlink >}} {{< nextlink href="/real_user_monitoring/application_monitoring/browser/build_plugins/action_name_deobfuscation" >}}Action Name Deobfuscation: Restore readable action names in minified builds.{{< /nextlink >}} - {{< nextlink href="/real_user_monitoring/application_monitoring/browser/build_plugins/source_code_context" >}}Source Code Context: Display source code inline in Error Tracking stack traces.{{< /nextlink >}} + {{< nextlink href="/real_user_monitoring/application_monitoring/browser/build_plugins/source_code_context" >}}Source Code Context: Display source code inline in {{< prodname >}}Error Tracking{{< /prodname >}} stack traces.{{< /nextlink >}} {{< /whatsnext >}} ## Further reading diff --git a/hugo/content/en/real_user_monitoring/application_monitoring/browser/build_plugins/source_code_context.md b/hugo/content/en/real_user_monitoring/application_monitoring/browser/build_plugins/source_code_context.md index d5853cb7979..230be0d44a1 100644 --- a/hugo/content/en/real_user_monitoring/application_monitoring/browser/build_plugins/source_code_context.md +++ b/hugo/content/en/real_user_monitoring/application_monitoring/browser/build_plugins/source_code_context.md @@ -20,7 +20,7 @@ further_reading: ## Overview -When viewing errors in [Error Tracking][1], Datadog can display the source code lines surrounding each frame in the stack trace. The Source Code Context build plugin enables this feature by injecting a small runtime snippet into your bundle that associates stack traces with your `service` and `version` metadata. +When viewing errors in [{{< prodname >}}Error Tracking{{< /prodname >}}][1], Datadog can display the source code lines surrounding each frame in the stack trace. The Source Code Context build plugin enables this feature by injecting a small runtime snippet into your bundle that associates stack traces with your `service` and `version` metadata. At build time, the plugin injects a snippet that writes metadata to `window.DD_SOURCE_CODE_CONTEXT`. At runtime, the RUM SDK reads `window.DD_SOURCE_CODE_CONTEXT` to tag errors with the correct service and version for source code resolution. This works in conjunction with [uploaded source maps][2] — source maps provide the file mapping, and `window.DD_SOURCE_CODE_CONTEXT` provides the service and version association. diff --git a/hugo/content/en/real_user_monitoring/application_monitoring/browser/build_plugins/source_maps.md b/hugo/content/en/real_user_monitoring/application_monitoring/browser/build_plugins/source_maps.md index 4b8e773e628..06c0938ef41 100644 --- a/hugo/content/en/real_user_monitoring/application_monitoring/browser/build_plugins/source_maps.md +++ b/hugo/content/en/real_user_monitoring/application_monitoring/browser/build_plugins/source_maps.md @@ -17,7 +17,7 @@ further_reading: ## Overview -The Source Maps build plugin automatically uploads JavaScript source maps to Datadog during your build, enabling deobfuscated stack traces in [Error Tracking][1] and [RUM][2]. This replaces the need to manually run `datadog-ci sourcemaps upload` or configure CI/CD pipelines for source map uploads. +The Source Maps build plugin automatically uploads JavaScript source maps to Datadog during your build, enabling deobfuscated stack traces in [{{< prodname >}}Error Tracking{{< /prodname >}}][1] and [RUM][2]. This replaces the need to manually run `datadog-ci sourcemaps upload` or configure CI/CD pipelines for source map uploads. The plugin hooks into the build process, discovers all `.js` files with corresponding `.map` source map files from the build output, and uploads them to Datadog with git metadata. @@ -71,7 +71,7 @@ module.exports = {
This example uses webpack. The configuration object is identical across all supported bundlers — only the import and plugin function name differ. See Build Plugins for installation instructions for your bundler.
-To also display inline source code in Error Tracking stack traces, pair source map uploads with the [Source Code Context][5] plugin. Source maps provide the file mapping; source code context provides the service and version association. +To also display inline source code in {{< prodname >}}Error Tracking{{< /prodname >}} stack traces, pair source map uploads with the [Source Code Context][5] plugin. Source maps provide the file mapping; source code context provides the service and version association. ## Further reading diff --git a/hugo/content/en/real_user_monitoring/application_monitoring/browser/collecting_browser_errors.md b/hugo/content/en/real_user_monitoring/application_monitoring/browser/collecting_browser_errors.md index 313bd27a408..fa3a8fef6d8 100644 --- a/hugo/content/en/real_user_monitoring/application_monitoring/browser/collecting_browser_errors.md +++ b/hugo/content/en/real_user_monitoring/application_monitoring/browser/collecting_browser_errors.md @@ -18,7 +18,7 @@ further_reading: --- ## Overview -The Browser SDK collects frontend errors, including the error message and stack trace when available. For triaging and managing these errors in the Error Tracking product, see [Browser Error Tracking][4]. +The Browser SDK collects frontend errors, including the error message and stack trace when available. For triaging and managing these errors in the {{< prodname >}}Error Tracking{{< /prodname >}} product, see [Browser Error Tracking][4]. When the Browser SDK collects an error: @@ -27,7 +27,7 @@ When the Browser SDK collects an error: * The [RUM metrics][16] `rum.measure.error`, `rum.measure.session.error`, and `rum.measure.view.error_free` are updated, regardless of whether the session is retained. * The error is captured in [Error Tracking][4]. -[Error Tracking rules][17] do not apply to _Error events_, and RUM still records Error events that match [Ignored and Excluded issues][18] in Error Tracking. To prevent errors from being recorded as Error events, you must discard them before they are sent to Datadog [using the `beforeSend` callback][19]. +[Error Tracking rules][17] do not apply to _Error events_, and RUM still records Error events that match [Ignored and Excluded issues][18] in {{< prodname >}}Error Tracking{{< /prodname >}}. To prevent errors from being recorded as Error events, you must discard them before they are sent to Datadog [using the `beforeSend` callback][19]. ## Error sources Frontend errors come from several different sources: @@ -69,7 +69,7 @@ addError( ); {{< /code-block >}} -**Note**: [Error Tracking][4] processes errors that are sent with the source set to `custom`, `source`, `report` or `console`, and contain a stack trace. Errors sent with any other source (such as `network`) or sent from browser extensions are not processed by Error Tracking. +**Note**: [{{< prodname >}}Error Tracking{{< /prodname >}}][4] processes errors that are sent with the source set to `custom`, `source`, `report` or `console`, and contain a stack trace. Errors sent with any other source (such as `network`) or sent from browser extensions are not processed by {{< prodname >}}Error Tracking{{< /prodname >}}. {{< tabs >}} {{% tab "npm" %}} diff --git a/hugo/content/en/real_user_monitoring/application_monitoring/cpp/error_tracking.md b/hugo/content/en/real_user_monitoring/application_monitoring/cpp/error_tracking.md index bbff404a921..c82ffdc6046 100644 --- a/hugo/content/en/real_user_monitoring/application_monitoring/cpp/error_tracking.md +++ b/hugo/content/en/real_user_monitoring/application_monitoring/cpp/error_tracking.md @@ -12,9 +12,9 @@ further_reading: ## Overview -Enable crash reporting for your C and C++ applications to surface, triage, and debug crashes in [Error Tracking][1]. On Linux and macOS, the C++ SDK captures unhandled signals (such as `SIGSEGV` and `SIGABRT`). On Windows, it captures unhandled structured exceptions. In both cases, the SDK stores a crash report with the crashing thread's stack trace locally for upload on the next application launch. +Enable crash reporting for your C and C++ applications to surface, triage, and debug crashes in [{{< prodname >}}Error Tracking{{< /prodname >}}][1]. On Linux and macOS, the C++ SDK captures unhandled signals (such as `SIGSEGV` and `SIGABRT`). On Windows, it captures unhandled structured exceptions. In both cases, the SDK stores a crash report with the crashing thread's stack trace locally for upload on the next application launch. -Crash reports appear in [Error Tracking][1] and are deduplicated and grouped into issues to help you prioritize and resolve the most impactful crashes. +Crash reports appear in [{{< prodname >}}Error Tracking{{< /prodname >}}][1] and are deduplicated and grouped into issues to help you prioritize and resolve the most impactful crashes. ## Setup @@ -156,7 +156,7 @@ RaiseException(EXCEPTION_ACCESS_VIOLATION, 0, 0, NULL); {{< /tabs >}} 3. Relaunch the application. The crash report is uploaded during the next launch. -4. After a few seconds, navigate to [Error Tracking][1] in Datadog to confirm the crash report appears. +4. After a few seconds, navigate to [{{< prodname >}}Error Tracking{{< /prodname >}}][1] in Datadog to confirm the crash report appears. ## Further Reading diff --git a/hugo/content/en/real_user_monitoring/application_monitoring/flutter/error_tracking.md b/hugo/content/en/real_user_monitoring/application_monitoring/flutter/error_tracking.md index a7b40cfb243..15174e222b9 100644 --- a/hugo/content/en/real_user_monitoring/application_monitoring/flutter/error_tracking.md +++ b/hugo/content/en/real_user_monitoring/application_monitoring/flutter/error_tracking.md @@ -7,7 +7,7 @@ aliases: ## Overview -Enable Crash Reporting and Error Tracking to get comprehensive crash reports and error trends with Real User Monitoring. +Enable Crash Reporting and {{< prodname >}}Error Tracking{{< /prodname >}} to get comprehensive crash reports and error trends with Real User Monitoring. Your crash reports appear in [{{< ui >}}Error Tracking{{< /ui >}}][1]. diff --git a/hugo/content/en/real_user_monitoring/application_monitoring/react_native/error_tracking.md b/hugo/content/en/real_user_monitoring/application_monitoring/react_native/error_tracking.md index 2e185ae294c..eaa23f2d684 100644 --- a/hugo/content/en/real_user_monitoring/application_monitoring/react_native/error_tracking.md +++ b/hugo/content/en/real_user_monitoring/application_monitoring/react_native/error_tracking.md @@ -21,7 +21,7 @@ further_reading: ## Overview -Enable React Native Crash Reporting and Error Tracking to get comprehensive crash reports and error trends with Real User Monitoring. With this feature, you can access: +Enable React Native Crash Reporting and {{< prodname >}}Error Tracking{{< /prodname >}} to get comprehensive crash reports and error trends with Real User Monitoring. With this feature, you can access: - Aggregated React Native crash dashboards and attributes - Symbolicated React Native (JavaScript and native iOS or Android) crash reports @@ -149,7 +149,7 @@ If a `build` directory does not already exist, create it first by running `mkdir ## Test your implementation -To verify your React Native Crash Reporting and Error Tracking configuration, you need to issue an error in your application and confirm that the error appears in Datadog. +To verify your React Native Crash Reporting and {{< prodname >}}Error Tracking{{< /prodname >}} configuration, you need to issue an error in your application and confirm that the error appears in Datadog. To test your implementation: diff --git a/hugo/content/en/real_user_monitoring/application_monitoring/react_native/setup/_index.mdoc.md b/hugo/content/en/real_user_monitoring/application_monitoring/react_native/setup/_index.mdoc.md index 5ada7722c6a..02c3c8996d1 100644 --- a/hugo/content/en/real_user_monitoring/application_monitoring/react_native/setup/_index.mdoc.md +++ b/hugo/content/en/real_user_monitoring/application_monitoring/react_native/setup/_index.mdoc.md @@ -35,7 +35,7 @@ further_reading: text: Learn how to explore your RUM data --- -This page describes how to instrument your applications for [Real User Monitoring (RUM)][1] with the React Native SDK. RUM includes Error Tracking by default, but if you have purchased Error Tracking as a standalone product, see the [Error Tracking setup guide][2] for specific steps. +This page describes how to instrument your applications for [Real User Monitoring (RUM)][1] with the React Native SDK. RUM includes {{< prodname >}}Error Tracking{{< /prodname >}} by default, but if you have purchased {{< prodname >}}Error Tracking{{< /prodname >}} as a standalone product, see the [Error Tracking setup guide][2] for specific steps. The minimum supported version for the React Native SDK is React Native v0.65+. Compatibility with older versions is not guaranteed out-of-the-box. diff --git a/hugo/content/en/real_user_monitoring/application_monitoring/react_native/setup/codepush.md b/hugo/content/en/real_user_monitoring/application_monitoring/react_native/setup/codepush.md index 845c177160a..fbfcc5d4242 100644 --- a/hugo/content/en/real_user_monitoring/application_monitoring/react_native/setup/codepush.md +++ b/hugo/content/en/real_user_monitoring/application_monitoring/react_native/setup/codepush.md @@ -18,7 +18,7 @@ further_reading: ## Overview -Enable React Native Crash Reporting and Error Tracking to get comprehensive crash reports and error trends with Real User Monitoring. +Enable React Native Crash Reporting and {{< prodname >}}Error Tracking{{< /prodname >}} to get comprehensive crash reports and error trends with Real User Monitoring. Each time you release a new [CodePush][1] version for your React Native application, you need to upload the source maps to Datadog to unminify errors. diff --git a/hugo/content/en/real_user_monitoring/application_monitoring/roku/error_tracking.md b/hugo/content/en/real_user_monitoring/application_monitoring/roku/error_tracking.md index d0efdecf28b..395756b059f 100644 --- a/hugo/content/en/real_user_monitoring/application_monitoring/roku/error_tracking.md +++ b/hugo/content/en/real_user_monitoring/application_monitoring/roku/error_tracking.md @@ -17,9 +17,9 @@ site_support_id: rum_roku ## Overview -Error Tracking processes errors collected from the Roku SDK. +{{< prodname >}}Error Tracking{{< /prodname >}} processes errors collected from the Roku SDK. -Enable Roku Crash Reporting and Error Tracking to get comprehensive crash reports and error trends with Real User Monitoring. With this feature, you can access: +Enable Roku Crash Reporting and {{< prodname >}}Error Tracking{{< /prodname >}} to get comprehensive crash reports and error trends with Real User Monitoring. With this feature, you can access: - Aggregated Roku crash dashboards and attributes - Trend analysis with Roku error tracking @@ -41,7 +41,7 @@ The SDK supports stack trace in crash reporting on Roku OS 13+, while on Roku OS ## Test your implementation -To verify your Roku Crash Reporting and Error Tracking configuration, you need to trigger a crash in your application and confirm that the error appears in Datadog. +To verify your Roku Crash Reporting and {{< prodname >}}Error Tracking{{< /prodname >}} configuration, you need to trigger a crash in your application and confirm that the error appears in Datadog. To test your implementation: diff --git a/hugo/content/en/real_user_monitoring/application_monitoring/unity/error_tracking.md b/hugo/content/en/real_user_monitoring/application_monitoring/unity/error_tracking.md index 0a8e65f9a77..c18577b3601 100644 --- a/hugo/content/en/real_user_monitoring/application_monitoring/unity/error_tracking.md +++ b/hugo/content/en/real_user_monitoring/application_monitoring/unity/error_tracking.md @@ -14,7 +14,7 @@ title: Unity Crash Reporting and Error Tracking --- ## Overview -Enable Crash Reporting and Error Tracking to get comprehensive crash reports and error trends with Real User Monitoring. +Enable Crash Reporting and {{< prodname >}}Error Tracking{{< /prodname >}} to get comprehensive crash reports and error trends with Real User Monitoring. Your crash reports appear in [{{< ui >}}Error Tracking{{< /ui >}}][1]. @@ -86,7 +86,7 @@ Mapping files are limited in size to **500 MB** each, while dSYM files can go up ## Test your implementation -To verify your Unity Crash Reporting and Error Tracking configuration, issue an error in your application and confirm that the error appears in Datadog. +To verify your Unity Crash Reporting and {{< prodname >}}Error Tracking{{< /prodname >}} configuration, issue an error in your application and confirm that the error appears in Datadog. 1. Ensure you are not running a development build. Uncheck the {{< ui >}}Development Build{{< /ui >}} box in Unity's build settings. 2. Run your application on a simulator, emulator, or a real device. If you are running on iOS, ensure that the debugger is not attached. Otherwise, Xcode captures the crash before the Datadog SDK does. diff --git a/hugo/content/en/real_user_monitoring/correlate_with_other_telemetry/llm_observability/_index.md b/hugo/content/en/real_user_monitoring/correlate_with_other_telemetry/llm_observability/_index.md index ed082a9f159..2efd65c7fd8 100644 --- a/hugo/content/en/real_user_monitoring/correlate_with_other_telemetry/llm_observability/_index.md +++ b/hugo/content/en/real_user_monitoring/correlate_with_other_telemetry/llm_observability/_index.md @@ -10,16 +10,16 @@ algolia: --- ## Overview -Correlate RUM and Agent Observability sessions to gain more visibility on how your web application interacts with AI Agents. This correlation helps you understand the complete user journey by connecting frontend user interactions with backend AI processing. +Correlate RUM and {{< prodname >}}Agent Observability{{< /prodname >}} sessions to gain more visibility on how your web application interacts with AI Agents. This correlation helps you understand the complete user journey by connecting frontend user interactions with backend AI processing. -The link between RUM and Agent Observability is created by forwarding the RUM Session ID to the Agent Observability SDK. +The link between RUM and {{< prodname >}}Agent Observability{{< /prodname >}} is created by forwarding the RUM Session ID to the Agent Observability SDK. ## Prerequisites Before you begin, ensure you have: - [RUM Browser SDK][1] installed and configured in your web application - [Agent Observability SDK][2] installed in your backend service -- Datadog account with [RUM][3] and [Agent Observability][4] enabled +- Datadog account with [RUM][3] and [{{< prodname >}}Agent Observability{{< /prodname >}}][4] enabled - AI Agent endpoint that your web application can call ## Setup @@ -59,7 +59,7 @@ Update your web application to include the RUM Session ID in every call to your ### Step 3: Update your backend handler -Modify your server-side code to extract the session ID and pass it to the Agent Observability SDK. For detailed Agent Observability setup, see the [Agent Observability Setup Guide][4]. +Modify your server-side code to extract the session ID and pass it to the Agent Observability SDK. For detailed {{< prodname >}}Agent Observability{{< /prodname >}} setup, see the [Agent Observability Setup Guide][4]. ```python # Read the session_id from the incoming request diff --git a/hugo/content/en/real_user_monitoring/error_tracking/_index.md b/hugo/content/en/real_user_monitoring/error_tracking/_index.md index c30ceac5137..74a32bf1076 100644 --- a/hugo/content/en/real_user_monitoring/error_tracking/_index.md +++ b/hugo/content/en/real_user_monitoring/error_tracking/_index.md @@ -32,7 +32,7 @@ algolia: Issues from RUM errors include the stack trace, user session timelines, and metadata—including user location, version, and any custom attributes you included in your crash reports. -Take a tour of key Error Tracking features in the [Error Tracking Explorer][3] documentation. To view the Error Tracking Explorer for RUM, navigate to [{{< ui >}}Digital Experience{{< /ui >}} > {{< ui >}}Error Tracking{{< /ui >}}][1]. +Take a tour of key {{< prodname >}}Error Tracking{{< /prodname >}} features in the [Error Tracking Explorer][3] documentation. To view the Error Tracking Explorer for RUM, navigate to [{{< ui >}}Digital Experience{{< /ui >}} > {{< ui >}}Error Tracking{{< /ui >}}][1]. ## Setup diff --git a/hugo/content/en/real_user_monitoring/error_tracking/mobile/expo.md b/hugo/content/en/real_user_monitoring/error_tracking/mobile/expo.md index f754931b71e..3f4b63b494d 100644 --- a/hugo/content/en/real_user_monitoring/error_tracking/mobile/expo.md +++ b/hugo/content/en/real_user_monitoring/error_tracking/mobile/expo.md @@ -23,7 +23,7 @@ further_reading: --- ## Overview -Enable Expo Crash Reporting and Error Tracking to get comprehensive crash reports and error trends with Real User Monitoring. +Enable Expo Crash Reporting and {{< prodname >}}Error Tracking{{< /prodname >}} to get comprehensive crash reports and error trends with Real User Monitoring. With this feature, you can access the following features: @@ -156,7 +156,7 @@ Source maps and mapping files are limited in size to **500 MB** each, while dSYM ## Test your implementation -To verify your Expo Crash Reporting and Error Tracking configuration, you need to issue an error in your application and confirm that the error appears in Datadog. +To verify your Expo Crash Reporting and {{< prodname >}}Error Tracking{{< /prodname >}} configuration, you need to issue an error in your application and confirm that the error appears in Datadog. To test your implementation: diff --git a/hugo/content/en/real_user_monitoring/error_tracking/mobile/flutter.md b/hugo/content/en/real_user_monitoring/error_tracking/mobile/flutter.md index 1e5b2a1b0a0..b5e6be285ca 100644 --- a/hugo/content/en/real_user_monitoring/error_tracking/mobile/flutter.md +++ b/hugo/content/en/real_user_monitoring/error_tracking/mobile/flutter.md @@ -18,7 +18,7 @@ title: Flutter Crash Reporting and Error Tracking --- ## Overview -Enable Crash Reporting and Error Tracking to get comprehensive crash reports and error trends with Real User Monitoring. +Enable Crash Reporting and {{< prodname >}}Error Tracking{{< /prodname >}} to get comprehensive crash reports and error trends with Real User Monitoring. Your crash reports appear in [{{< ui >}}Error Tracking{{< /ui >}}][1]. @@ -117,7 +117,7 @@ Mapping files are limited in size to **500 MB** each, while dSYM files can go up ## Test your implementation -To verify your Flutter Crash Reporting and Error Tracking configuration, issue an error in your application and confirm that the error appears in Datadog. +To verify your Flutter Crash Reporting and {{< prodname >}}Error Tracking{{< /prodname >}} configuration, issue an error in your application and confirm that the error appears in Datadog. 1. Run your application on a simulator, emulator, or a real device. If you are running on iOS, ensure that the debugger is not attached. Otherwise, Xcode captures the crash before the Datadog SDK does. 2. Execute code containing an error or crash. For example: diff --git a/hugo/content/en/real_user_monitoring/error_tracking/mobile/ios.md b/hugo/content/en/real_user_monitoring/error_tracking/mobile/ios.md index a0954c63743..f8610047cae 100644 --- a/hugo/content/en/real_user_monitoring/error_tracking/mobile/ios.md +++ b/hugo/content/en/real_user_monitoring/error_tracking/mobile/ios.md @@ -21,7 +21,7 @@ further_reading: --- ## Overview -Enable iOS Crash Reporting and Error Tracking to get comprehensive crash reports and error trends with Real User Monitoring. With this feature, you can access: +Enable iOS Crash Reporting and {{< prodname >}}Error Tracking{{< /prodname >}} to get comprehensive crash reports and error trends with Real User Monitoring. With this feature, you can access: - Aggregated iOS crash dashboards and attributes - Symbolicated iOS crash reports @@ -108,11 +108,11 @@ App hangs are reported through the RUM iOS SDK (not through [Logs][4]). When enabled, any main thread pause that is longer than the specified `appHangThreshold` is considered a "hang" in [{{< ui >}}Error Tracking{{< /ui >}}][1]. There are two types of hangs: -- **Fatal app hang**: How a hang gets reported if it never gets recovered and the app is terminated. Fatal app hangs are marked as a "Crash" in Error Tracking and the RUM explorer. +- **Fatal app hang**: How a hang gets reported if it never gets recovered and the app is terminated. Fatal app hangs are marked as a "Crash" in {{< prodname >}}Error Tracking{{< /prodname >}} and the RUM explorer. {{< img src="real_user_monitoring/error_tracking/ios-fatal-app-hang-1.png" alt="A fatal app hang in the RUM Error side panel." style="width:90%;" >}} -- **Non-fatal app hang**: How a hang gets reported if the app recovers from a relatively short hang and continues running. Non-fatal app hangs do not have a "Crash" mark on them in Error Tracking and the RUM explorer. +- **Non-fatal app hang**: How a hang gets reported if the app recovers from a relatively short hang and continues running. Non-fatal app hangs do not have a "Crash" mark on them in {{< prodname >}}Error Tracking{{< /prodname >}} and the RUM explorer. {{< img src="real_user_monitoring/error_tracking/ios-non-fatal-app-hang-1.png" alt="A non-fatal app hang in the RUM Error side panel." style="width:90%;" >}} @@ -449,7 +449,7 @@ For more information, see [dSYMs commands][11]. ## Test your implementation -To verify your iOS Crash Reporting and Error Tracking configuration, issue a crash in your RUM application and confirm that the error appears in Datadog. +To verify your iOS Crash Reporting and {{< prodname >}}Error Tracking{{< /prodname >}} configuration, issue a crash in your RUM application and confirm that the error appears in Datadog. 1. Run your application on an iOS simulator or a real device. Ensure that the debugger is not attached. Otherwise, Xcode captures the crash before the iOS SDK does. 2. Execute the code containing the crash: diff --git a/hugo/content/en/real_user_monitoring/error_tracking/mobile/kotlin-multiplatform.md b/hugo/content/en/real_user_monitoring/error_tracking/mobile/kotlin-multiplatform.md index 963663487bd..dac4636ed05 100644 --- a/hugo/content/en/real_user_monitoring/error_tracking/mobile/kotlin-multiplatform.md +++ b/hugo/content/en/real_user_monitoring/error_tracking/mobile/kotlin-multiplatform.md @@ -20,9 +20,9 @@ further_reading: ## Overview -Error Tracking processes errors collected from the Kotlin Multiplatform SDK. +{{< prodname >}}Error Tracking{{< /prodname >}} processes errors collected from the Kotlin Multiplatform SDK. -Enable Kotlin Multiplatform Crash Reporting and Error Tracking to get comprehensive crash reports and error trends. With this feature, you can access: +Enable Kotlin Multiplatform Crash Reporting and {{< prodname >}}Error Tracking{{< /prodname >}} to get comprehensive crash reports and error trends. With this feature, you can access: - Aggregated Kotlin Multiplatform crash dashboards and attributes - Deobfuscated Kotlin Multiplatform (iOS and Android) crash reports @@ -107,7 +107,7 @@ The SDK handles crash reporting with the following behaviors: ## Test your implementation -To verify your Kotlin Multiplatform Crash Reporting and Error Tracking configuration, you need to trigger a crash in your application and confirm that the error appears in Datadog. +To verify your Kotlin Multiplatform Crash Reporting and {{< prodname >}}Error Tracking{{< /prodname >}} configuration, you need to trigger a crash in your application and confirm that the error appears in Datadog. To test your implementation: diff --git a/hugo/content/en/real_user_monitoring/error_tracking/mobile/maui.md b/hugo/content/en/real_user_monitoring/error_tracking/mobile/maui.md index 6b9de9723fd..b1a9264bcc5 100644 --- a/hugo/content/en/real_user_monitoring/error_tracking/mobile/maui.md +++ b/hugo/content/en/real_user_monitoring/error_tracking/mobile/maui.md @@ -19,9 +19,9 @@ further_reading: ## Overview -Error Tracking processes errors collected from the .NET MAUI SDK. +{{< prodname >}}Error Tracking{{< /prodname >}} processes errors collected from the .NET MAUI SDK. -Enable .NET MAUI Crash Reporting and Error Tracking to get comprehensive crash reports, deobfuscated stack traces, and error trends across iOS and Android. Your crash reports appear in [{{< ui >}}Error Tracking{{< /ui >}}][1]. +Enable .NET MAUI Crash Reporting and {{< prodname >}}Error Tracking{{< /prodname >}} to get comprehensive crash reports, deobfuscated stack traces, and error trends across iOS and Android. Your crash reports appear in [{{< ui >}}Error Tracking{{< /ui >}}][1]. ### C# error tracking @@ -193,7 +193,7 @@ In a MAUI app, the native `.so` files typically come from the .NET runtime (`lib ## Test your implementation -To verify your Crash Reporting and Error Tracking configuration, trigger a crash and confirm that the error appears in Datadog: +To verify your Crash Reporting and {{< prodname >}}Error Tracking{{< /prodname >}} configuration, trigger a crash and confirm that the error appears in Datadog: 1. Run your application on a real device or emulator (dSYMs are generated only for device builds on iOS). 2. Execute code that throws an unhandled exception. For example: diff --git a/hugo/content/en/real_user_monitoring/error_tracking/mobile/reactnative.md b/hugo/content/en/real_user_monitoring/error_tracking/mobile/reactnative.md index 5615e822949..dd4518e5a61 100644 --- a/hugo/content/en/real_user_monitoring/error_tracking/mobile/reactnative.md +++ b/hugo/content/en/real_user_monitoring/error_tracking/mobile/reactnative.md @@ -21,7 +21,7 @@ further_reading: ## Overview -Enable React Native Crash Reporting and Error Tracking to get comprehensive crash reports and error trends with Real User Monitoring. With this feature, you can access: +Enable React Native Crash Reporting and {{< prodname >}}Error Tracking{{< /prodname >}} to get comprehensive crash reports and error trends with Real User Monitoring. With this feature, you can access: - Aggregated React Native crash dashboards and attributes - Symbolicated React Native (JavaScript and native iOS or Android) crash reports @@ -147,7 +147,7 @@ If a `build` directory does not already exist, create it first by running `mkdir ## Test your implementation -To verify your React Native Crash Reporting and Error Tracking configuration, you need to issue an error in your application and confirm that the error appears in Datadog. +To verify your React Native Crash Reporting and {{< prodname >}}Error Tracking{{< /prodname >}} configuration, you need to issue an error in your application and confirm that the error appears in Datadog. To test your implementation: diff --git a/hugo/content/en/real_user_monitoring/error_tracking/mobile/roku.md b/hugo/content/en/real_user_monitoring/error_tracking/mobile/roku.md index 3d7dfaba52d..098d3044547 100644 --- a/hugo/content/en/real_user_monitoring/error_tracking/mobile/roku.md +++ b/hugo/content/en/real_user_monitoring/error_tracking/mobile/roku.md @@ -18,9 +18,9 @@ site_support_id: roku_error_tracking ## Overview -Error Tracking processes errors collected from the Roku SDK. +{{< prodname >}}Error Tracking{{< /prodname >}} processes errors collected from the Roku SDK. -Enable Roku Crash Reporting and Error Tracking to get comprehensive crash reports and error trends with Real User Monitoring. With this feature, you can access: +Enable Roku Crash Reporting and {{< prodname >}}Error Tracking{{< /prodname >}} to get comprehensive crash reports and error trends with Real User Monitoring. With this feature, you can access: - Aggregated Roku crash dashboards and attributes - Trend analysis with Roku error tracking @@ -42,7 +42,7 @@ The SDK supports stack trace in crash reporting on Roku OS 13+, while on Roku OS ## Test your implementation -To verify your Roku Crash Reporting and Error Tracking configuration, you need to trigger a crash in your application and confirm that the error appears in Datadog. +To verify your Roku Crash Reporting and {{< prodname >}}Error Tracking{{< /prodname >}} configuration, you need to trigger a crash in your application and confirm that the error appears in Datadog. To test your implementation: diff --git a/hugo/content/en/real_user_monitoring/explorer/events.md b/hugo/content/en/real_user_monitoring/explorer/events.md index e07ce09a143..1956ee88f6f 100644 --- a/hugo/content/en/real_user_monitoring/explorer/events.md +++ b/hugo/content/en/real_user_monitoring/explorer/events.md @@ -74,7 +74,7 @@ Use the other tabs to explore related data: {{< ui >}}Traces{{< /ui >}} : See backend traces connected to the event. -{{< ui >}}Feature Flags{{< /ui >}} +{{< ui >}}{{< prodname >}}Feature Flags{{< /prodname >}}{{< /ui >}} : View feature flags evaluated during the event. {{< ui >}}Actions{{< /ui >}} diff --git a/hugo/content/en/real_user_monitoring/explorer/visualize.md b/hugo/content/en/real_user_monitoring/explorer/visualize.md index b5ac347b180..64e7919756f 100644 --- a/hugo/content/en/real_user_monitoring/explorer/visualize.md +++ b/hugo/content/en/real_user_monitoring/explorer/visualize.md @@ -122,7 +122,7 @@ After you build a funnel, click on {{< ui >}}View Funnel Insights{{< /ui >}} to {{< img src="real_user_monitoring/funnel_analysis/funnel-analysis-analyzing-funnel.jpg" alt="Use the Funnel Insights panel to review performance and user behavior trends" style="width:90%;" >}} -- The {{< ui >}}Performance{{< /ui >}} section allows you to understand if poor performance could have affected conversion. You can view a graph with a correlation between the load time of that page and the conversion rate and also see if any issues (detected by [Error Tracking][5]) occurred on that page. +- The {{< ui >}}Performance{{< /ui >}} section allows you to understand if poor performance could have affected conversion. You can view a graph with a correlation between the load time of that page and the conversion rate and also see if any issues (detected by [{{< prodname >}}Error Tracking{{< /prodname >}}][5]) occurred on that page. - The {{< ui >}}User Behavior{{< /ui >}} section allows you to compare the average frustration count (from [frustration signals][6]) with the conversion rate, and further analyze the frustration signals detected from individual actions. Next to this section is a chart showing the conversion and drop off rate for specific countries, allowing you to understand if geographic region plays a role in a user converting. {{< img src="real_user_monitoring/funnel_analysis/funnel-analysis-user-behavior.jpg" alt="User behavior section within funnel analysis" style="width:90%;" >}} diff --git a/hugo/content/en/real_user_monitoring/feature_flag_tracking/using_feature_flags.md b/hugo/content/en/real_user_monitoring/feature_flag_tracking/using_feature_flags.md index a4cfb6a6fee..8e8182dfcd9 100644 --- a/hugo/content/en/real_user_monitoring/feature_flag_tracking/using_feature_flags.md +++ b/hugo/content/en/real_user_monitoring/feature_flag_tracking/using_feature_flags.md @@ -53,7 +53,7 @@ These out-of-the-box graphs are aggregated across your flag variants, making it - The {{< ui >}}Users{{< /ui >}} tab provides some high level summary statistics of your feature flag and allows you to further analyze the users viewing each of your feature flag variants by any attribute. If you want to understand what it looks like for someone who experienced a certain variant versus another, you can watch a [Session Replay][2] for each case. -- The {{< ui >}}Issues{{< /ui >}} tab gives you a view of the errors that are occurring in your application for user sessions that have your feature flag. Check if any issues detected by [Error Tracking][3] occurred for a specific variant of your feature flag and might be related to your changes. +- The {{< ui >}}Issues{{< /ui >}} tab gives you a view of the errors that are occurring in your application for user sessions that have your feature flag. Check if any issues detected by [{{< prodname >}}Error Tracking{{< /prodname >}}][3] occurred for a specific variant of your feature flag and might be related to your changes. - The {{< ui >}}Performance{{< /ui >}} tab allows you to understand if one of your feature flag variants have caused poor performance. You can view your Core Web Vitals and loading time for each variant to determine if one of your variants may be causing a negative impact on your application's performance. diff --git a/hugo/content/en/real_user_monitoring/guide/debug-symbols.md b/hugo/content/en/real_user_monitoring/guide/debug-symbols.md index 1e4a91b7d18..bd00951f383 100644 --- a/hugo/content/en/real_user_monitoring/guide/debug-symbols.md +++ b/hugo/content/en/real_user_monitoring/guide/debug-symbols.md @@ -7,7 +7,7 @@ The [RUM Debug Symbols page][1] lists all the debug symbols that are uploaded fo
To automatically associate stack traces with your service and version for source code resolution, use the Source Code Context build plugin.
-The following error message appears when a stack trace is not properly deobfuscated in RUM or Error Tracking: _The stack trace could not be deobfuscated because no debug symbols could be found for this application. If you are not obfuscating your application, ignore this message. Otherwise, upload your debug symbols to see deobfuscated stack traces. You can view all your uploaded symbols on the RUM Debug Symbols page._ +The following error message appears when a stack trace is not properly deobfuscated in RUM or {{< prodname >}}Error Tracking{{< /prodname >}}: _The stack trace could not be deobfuscated because no debug symbols could be found for this application. If you are not obfuscating your application, ignore this message. Otherwise, upload your debug symbols to see deobfuscated stack traces. You can view all your uploaded symbols on the RUM Debug Symbols page._ {{< img src="real_user_monitoring/guide/debug-symbols/deobfuscation-failed-message.png" alt="Deobfuscation failed: The stack trace could not be deobfuscated because no mapping files could be found for this application. If you are not obfuscating your application, ignore this message. Otherwise, upload your mapping files to see deobfuscated stack traces. You can view all your uploaded files on the RUM Debug Symbols page." >}} diff --git a/hugo/content/en/real_user_monitoring/guide/define-services-and-track-ui-components-in-your-browser-application.md b/hugo/content/en/real_user_monitoring/guide/define-services-and-track-ui-components-in-your-browser-application.md index f73c8138dd8..99802868e82 100644 --- a/hugo/content/en/real_user_monitoring/guide/define-services-and-track-ui-components-in-your-browser-application.md +++ b/hugo/content/en/real_user_monitoring/guide/define-services-and-track-ui-components-in-your-browser-application.md @@ -102,7 +102,7 @@ Inside your RUM application, create services for each set of pages owned by a te 2. For each page of your website, assign a view name and a service following [the instructions for overriding default RUM view names][8]. - `"purchase"` service for the pages available at `/checkout`, `/payment`, `/confirmOrder`. - `"catalog"` service for the pages available at `/beds`, `/chairs/123`, `/search`. -3. [Upload a source map for each service][9] to view unminified stack traces in Error Tracking. +3. [Upload a source map for each service][9] to view unminified stack traces in {{< prodname >}}Error Tracking{{< /prodname >}}. Get insights into the performance or the adoption of a given team's scope by using the `service` attribute in RUM: diff --git a/hugo/content/en/real_user_monitoring/guide/mobile-sdk-upgrade.md b/hugo/content/en/real_user_monitoring/guide/mobile-sdk-upgrade.md index 686c3c8076a..b4b5315383a 100644 --- a/hugo/content/en/real_user_monitoring/guide/mobile-sdk-upgrade.md +++ b/hugo/content/en/real_user_monitoring/guide/mobile-sdk-upgrade.md @@ -206,7 +206,7 @@ API changes: ### Logs -The Logs product no longer reports fatal errors. To enable Error Tracking for crashes, Crash Reporting must be enabled in conjunction with RUM. +The Logs product no longer reports fatal errors. To enable {{< prodname >}}Error Tracking{{< /prodname >}} for crashes, Crash Reporting must be enabled in conjunction with RUM. The URL provided in the `useCustomEndpoint` method should be the full endpoint URL (`https://example.com/logs/upload`), not just the hostname: @@ -417,7 +417,7 @@ API changes: ### Logs -The Logs product no longer reports fatal errors. To enable Error Tracking for crashes, Crash Reporting must be enabled in conjunction with RUM. +The Logs product no longer reports fatal errors. To enable {{< prodname >}}Error Tracking{{< /prodname >}} for crashes, Crash Reporting must be enabled in conjunction with RUM. Additionally, all Objective-C Logs APIs are included in `DatadogLogs`. The separate `DatadogObjc` module is no longer available. diff --git a/hugo/content/en/real_user_monitoring/guide/session-replay-for-solutions.md b/hugo/content/en/real_user_monitoring/guide/session-replay-for-solutions.md index 0e1d35f079c..4fa6081b943 100644 --- a/hugo/content/en/real_user_monitoring/guide/session-replay-for-solutions.md +++ b/hugo/content/en/real_user_monitoring/guide/session-replay-for-solutions.md @@ -24,7 +24,7 @@ This guide describes a workflow that organizations can replicate and use as an a ## Assess user issues -Assume that a customer encounters an issue using Datadog. Your Technical Solutions team may use a support solution, such as Zendesk or ServiceNow, that creates a ticket when this customer reports that they cannot update or save a Synthetics multistep API test. +Assume that a customer encounters an issue using Datadog. Your Technical Solutions team may use a support solution, such as Zendesk or ServiceNow, that creates a ticket when this customer reports that they cannot update or save a {{< prodname >}}Synthetics{{< /prodname >}} multistep API test. The team may request more information from the customer (such as the specific test ID and a screen recording with the [Browser Dev Tools][2] open) that may provide additional context for the customer's test not updating or saving. If no console errors were recorded, the team would not have any hints to start investigating the multistep API test's issue. diff --git a/hugo/content/en/real_user_monitoring/guide/setup-rum-deployment-tracking.md b/hugo/content/en/real_user_monitoring/guide/setup-rum-deployment-tracking.md index 2e570586d16..b7796e9bbae 100644 --- a/hugo/content/en/real_user_monitoring/guide/setup-rum-deployment-tracking.md +++ b/hugo/content/en/real_user_monitoring/guide/setup-rum-deployment-tracking.md @@ -116,7 +116,7 @@ As you are monitoring your release, this helps you to compare the performance of The {{< ui >}}Issues{{< /ui >}} tab lists differences in errors detected for each of the two versions, highlighting: - Error Count by Version - % of Views with Errors by Version -- Error Tracking issues +- {{< prodname >}}Error Tracking{{< /prodname >}} issues {{< img src="real_user_monitoring/guide/setup-rum-deployment-tracking/browser-deployment-tracking-comparison-error.png" alt="Browser Deployment Tracking Comparison Errors" style="width:75%;">}} @@ -163,7 +163,7 @@ As you are monitoring your release, this makes it easy for you to compare the pe The {{< ui >}}Issues{{< /ui >}} tab lists differences in errors detected for each of the two versions, highlighting: - Error Count by Version - % of Views with Errors by Version -- Error Tracking issues +- {{< prodname >}}Error Tracking{{< /prodname >}} issues {{< img src="real_user_monitoring/guide/setup-rum-deployment-tracking/mobile-deployment-tracking-comparison-error.png" alt="Mobile Deployment Tracking Comparison Errors" style="width:75%;">}} diff --git a/hugo/content/en/real_user_monitoring/guide/understanding-the-rum-event-hierarchy.md b/hugo/content/en/real_user_monitoring/guide/understanding-the-rum-event-hierarchy.md index 7dbaeabd77d..5e8206acbc9 100644 --- a/hugo/content/en/real_user_monitoring/guide/understanding-the-rum-event-hierarchy.md +++ b/hugo/content/en/real_user_monitoring/guide/understanding-the-rum-event-hierarchy.md @@ -54,7 +54,7 @@ This example displays a query that searches for all actions from users clicking You can use RUM to collect [frontend errors][6] that occur during the user session. By default, the browser SDK creates error events for unhandled exceptions and console errors. Additionally, you can collect custom errors through the RUM `addError` API (on [browser][7] and [mobile][8]). On mobile apps, you can also see if the error led to a session termination, also known as a crash. -Errors can be viewed in both RUM and Error Tracking. Source and custom errors are processed by Error Tracking, while console errors are solely in RUM. +Errors can be viewed in both RUM and {{< prodname >}}Error Tracking{{< /prodname >}}. Source and custom errors are processed by {{< prodname >}}Error Tracking{{< /prodname >}}, while console errors are solely in RUM. #### Sample search: List of all crashes that occurred on a page in the application diff --git a/hugo/content/en/real_user_monitoring/guide/upload-javascript-source-maps.md b/hugo/content/en/real_user_monitoring/guide/upload-javascript-source-maps.md index a34f9894819..85b8949aa1b 100644 --- a/hugo/content/en/real_user_monitoring/guide/upload-javascript-source-maps.md +++ b/hugo/content/en/real_user_monitoring/guide/upload-javascript-source-maps.md @@ -21,7 +21,7 @@ further_reading: If your front-end JavaScript source code is minified, upload your source maps to Datadog to de-obfuscate your different stack traces. For any given error, you can access the file path, line number, and code snippet for each frame of the related stack trace. Datadog can also link stack frames to your source code in your repository. -
+
## Instrument your code @@ -151,7 +151,7 @@ To minimize overhead on your CI's performance, the CLI is optimized to upload as **Note**: Re-uploading a source map does not override the existing one if the version has not changed. -The `--service` and `--release-version` parameters must match the `service` and `version` tags on your Error Tracking events, RUM events, and browser logs. For more information on how to setup these tags, refer to the [Browser SDK initialization documentation][2] or [Browser Logs Collection documentation][3]. +The `--service` and `--release-version` parameters must match the `service` and `version` tags on your {{< prodname >}}Error Tracking{{< /prodname >}} events, RUM events, and browser logs. For more information on how to setup these tags, refer to the [Browser SDK initialization documentation][2] or [Browser Logs Collection documentation][3].
If you have defined multiple services in your application, run the CI command as many times as there are services, even if you have one set of sourcemaps for the entire application.
diff --git a/hugo/content/en/real_user_monitoring/platform/dashboards/_index.md b/hugo/content/en/real_user_monitoring/platform/dashboards/_index.md index ca3d7489d95..06e18b22e75 100644 --- a/hugo/content/en/real_user_monitoring/platform/dashboards/_index.md +++ b/hugo/content/en/real_user_monitoring/platform/dashboards/_index.md @@ -15,13 +15,13 @@ When you create a RUM application, Datadog [collects data][1] and generates dash {{< img src="real_user_monitoring/dashboards/rum-dashboards-performance-summary.png" alt="RUM Application Overview page" style="width:90%;" >}} -Access your RUM dashboards by filtering for `RUM` in the search query of the [{{< ui >}}Dashboard List{{< /ui >}}][2] or from your application summary pages ({{< ui >}}Digital Experience{{< /ui >}} > {{< ui >}}Performance Summary{{< /ui >}} and {{< ui >}}Digital Experience{{< /ui >}} > {{< ui >}}Product Analytics{{< /ui >}} > {{< ui >}}Analytics Summary{{< /ui >}}). +Access your RUM dashboards by filtering for `RUM` in the search query of the [{{< ui >}}Dashboard List{{< /ui >}}][2] or from your application summary pages ({{< ui >}}Digital Experience{{< /ui >}} > {{< ui >}}Performance Summary{{< /ui >}} and {{< ui >}}Digital Experience{{< /ui >}} > {{< ui >}}{{< prodname >}}Product Analytics{{< /prodname >}}{{< /ui >}} > {{< ui >}}Analytics Summary{{< /ui >}}). {{< img src="real_user_monitoring/dashboards/available-rum-dashboards.png" alt="Out-of-the-box RUM Dashboards" style="width:90%;" >}} {{< whatsnext desc="You can explore the following out-of-the-box RUM dashboards:" >}} {{< nextlink href="/real_user_monitoring/platform/dashboards/performance" >}}Performance Overviews: See a global view of your website/app performance and demographics. {{< /nextlink >}} - {{< nextlink href="/real_user_monitoring/platform/dashboards/testing_and_deployment" >}}Testing and Deployment: Evaluate your browser tests' application coverage and identify popular elements in your application to track using RUM and Synthetics data. {{< /nextlink >}} + {{< nextlink href="/real_user_monitoring/platform/dashboards/testing_and_deployment" >}}Testing and Deployment: Evaluate your browser tests' application coverage and identify popular elements in your application to track using RUM and {{< prodname >}}Synthetics{{< /prodname >}} data. {{< /nextlink >}} {{< nextlink href="/real_user_monitoring/platform/dashboards/usage" >}}Usage: Analyze user session and usage data for your RUM applications, including frustration signals. {{< /nextlink >}} {{< nextlink href="/real_user_monitoring/platform/dashboards/errors" >}}Errors: Observe errors that appear in user consoles by browser and device type. {{< /nextlink >}} {{< /whatsnext >}} diff --git a/hugo/content/en/real_user_monitoring/platform/dashboards/errors.md b/hugo/content/en/real_user_monitoring/platform/dashboards/errors.md index d7a658b86bc..1dda26bdce5 100644 --- a/hugo/content/en/real_user_monitoring/platform/dashboards/errors.md +++ b/hugo/content/en/real_user_monitoring/platform/dashboards/errors.md @@ -15,7 +15,7 @@ further_reading: The RUM web app errors dashboard provides insights about your applications' errors. It helps you focus on the views or versions that are generating the most errors. It shows: - {{< ui >}}Code errors{{< /ui >}}: - Get an overview of which parts of your application are generating the most errors. If you need to dig deeper, see [Error Tracking][1] to investigate critical frontend errors and learn when new errors appear. + Get an overview of which parts of your application are generating the most errors. If you need to dig deeper, see [{{< prodname >}}Error Tracking{{< /prodname >}}][1] to investigate critical frontend errors and learn when new errors appear. - {{< ui >}}Network errors{{< /ui >}}: Monitor which resources are generating the most errors. @@ -29,7 +29,7 @@ For more information about the data displayed, see [RUM Browser Data Collected][ The RUM mobile app crashes and errors dashboard provides insights about your mobile applications' errors. It helps you focus on the views or versions that are generating the most errors. It shows: - {{< ui >}}Code errors{{< /ui >}}: - Get an overview of which parts of your application are generating the most errors. If you need to dig deeper, see [Error Tracking][1] to investigate critical frontend errors and learn when new errors appear. + Get an overview of which parts of your application are generating the most errors. If you need to dig deeper, see [{{< prodname >}}Error Tracking{{< /prodname >}}][1] to investigate critical frontend errors and learn when new errors appear. - {{< ui >}}Network errors{{< /ui >}}: Monitor which resources are generating the most errors. diff --git a/hugo/content/en/real_user_monitoring/rum_export.md b/hugo/content/en/real_user_monitoring/rum_export.md index 4813848b0f9..6f7dbef19b9 100644 --- a/hugo/content/en/real_user_monitoring/rum_export.md +++ b/hugo/content/en/real_user_monitoring/rum_export.md @@ -20,7 +20,7 @@ Export Pipelines is in Preview. ## Overview -Export Pipelines stream your ingested Real User Monitoring (RUM) and Product Analytics events to a cloud storage bucket you own — Amazon S3, Azure Blob Storage, or Google Cloud Storage — in JSON or Parquet format. +Export Pipelines stream your ingested Real User Monitoring (RUM) and {{< prodname >}}Product Analytics{{< /prodname >}} events to a cloud storage bucket you own — Amazon S3, Azure Blob Storage, or Google Cloud Storage — in JSON or Parquet format. {{< img src="real_user_monitoring/rum_export/rum-export-overview.png" alt="Export Pipelines list on the RUM application settings page" style="width:100%;">}} @@ -32,7 +32,7 @@ Datadog only manages the export from your Datadog account to your cloud storage ## How it works -Export Pipelines is a shared feature between [Real User Monitoring][4] and [Product Analytics][5]. Pipelines are configured at two different levels: +Export Pipelines is a shared feature between [Real User Monitoring][4] and [{{< prodname >}}Product Analytics{{< /prodname >}}][5]. Pipelines are configured at two different levels: | Scope | Source | Max pipelines | Available presets | |---|---|---|---| @@ -46,7 +46,7 @@ Each pipeline exports continuously and independently of the others. ## Prerequisites -- RUM is enabled on the application (or Product Analytics, or both). +- RUM is enabled on the application (or {{< prodname >}}Product Analytics{{< /prodname >}}, or both). - The Datadog integration for your cloud provider is set up: [Amazon Web Services][6], [Azure][7], or [Google Cloud][8]. - Your Datadog user has the `rum_write_archives` permission. See [Role Based Access Control][1]. diff --git a/hugo/content/en/real_user_monitoring/rum_without_limits/retention_filters.md b/hugo/content/en/real_user_monitoring/rum_without_limits/retention_filters.md index f2d5b53221c..55ccf1fb040 100644 --- a/hugo/content/en/real_user_monitoring/rum_without_limits/retention_filters.md +++ b/hugo/content/en/real_user_monitoring/rum_without_limits/retention_filters.md @@ -173,7 +173,7 @@ For more information, see Permanent Retention Filters. The APM traces filter is **only editable on Synthetic Monitoring Sessions and Sessions with forced replays filters**. -
APM traces indexed through a cross-product retention filter on the Synthetics or Forced Replay permanent filters are subject to APM billing.
+
APM traces indexed through a cross-product retention filter on the {{< prodname >}}Synthetics{{< /prodname >}} or Forced Replay permanent filters are subject to APM billing.
## Best practices diff --git a/hugo/content/en/remote_configuration/_index.md b/hugo/content/en/remote_configuration/_index.md index b053c33e79d..0b82851ea02 100644 --- a/hugo/content/en/remote_configuration/_index.md +++ b/hugo/content/en/remote_configuration/_index.md @@ -32,7 +32,7 @@ algolia: Remote Configuration is a Datadog capability that allows you to remotely configure and change the behavior of select product features in Datadog components such as Agents, SDKs, and Observability Pipelines Workers deployed in your infrastructure. Use Remote Configuration to apply configurations to Datadog components in your environment on demand, decreasing management costs, reducing friction between teams, and accelerating issue resolution times. -For Datadog security products, App and API Protection and Workload Protection, Remote Configuration-enabled Agents and compatible SDKs provide real-time security updates and responses, enhancing security posture for your applications and cloud infrastructure. +For Datadog security products, {{< prodname >}}App and API Protection{{< /prodname >}} and {{< prodname >}}Workload Protection{{< /prodname >}}, Remote Configuration-enabled Agents and compatible SDKs provide real-time security updates and responses, enhancing security posture for your applications and cloud infrastructure. ## How it works @@ -64,7 +64,7 @@ Fleet Automation : - [Send flares][27] directly from the Datadog site. Seamlessly troubleshoot the Datadog Agent without directly accessing the host. : - [Upgrade your Agents][29]. -App and API Protection (AAP) +{{< prodname >}}App and API Protection{{< /prodname >}} (AAP) : - [1-click AAP activation][33]: Enable AAP in 1-click from the Datadog UI. : - [In-App attack patterns updates][34]: Receive the newest Web Application Firewall (WAF) attack patterns automatically as Datadog releases them, following newly disclosed vulnerabilities or attack vectors. : - [Protect][34]: Block attackers' IPs, authenticated users, and suspicious requests that are flagged in AAP Security Signals and Traces temporarily or permanently through the Datadog UI. @@ -73,14 +73,14 @@ Application Performance Monitoring (APM) : - Configuration at runtime: Change a service's trace sampling rate, Log Injection enablement, and HTTP header tags from within the Catalog UI, without having to restart the service. Read [Configuration at Runtime][22] for more information. : - [Remotely set Agent sampling rate][35]: Remotely configure the Datadog Agent to change its trace sampling rates and set rules to scale your organization's trace ingestion according to your needs, without needing to restart your Datadog Agent. -[Dynamic Instrumentation][36] +[{{< prodname >}}Dynamic Instrumentation{{< /prodname >}}][36] : - Send critical metrics, traces, and logs from your live applications with no code changes. -Workload Protection +{{< prodname >}}Workload Protection{{< /prodname >}} : - Automatic default Agent rule updates: Automatically receive and update the default Agent rules maintained by Datadog as new Agent detections and enhancements are released. See [Setting Up Workload Protection][3] for more information. : - Automatic deployment of custom Agent rules: Automatically deploy your custom Agent rules to designated hosts (all hosts or a defined subset of hosts). -Observability Pipelines +{{< prodname >}}Observability Pipelines{{< /prodname >}} : - Remotely deploy and update [Observability Pipelines Workers][4] (OPW): Build and edit pipelines in the Datadog UI, rolling out your configuration changes to OPW instances running in your environment. [Autoscaling][47] @@ -89,8 +89,8 @@ Observability Pipelines Private action runner : - Run Datadog workflows and apps that interact with services hosted on your private network without exposing your services to the public internet. For more information, see [Private Actions][30]. -Feature Flags -: - Deliver flag configurations (targeting and assignment rules) to server-side SDKs for synchronous variant assignment based on evaluation context. See [Feature Flags][48] for more information. +{{< prodname >}}Feature Flags{{< /prodname >}} +: - Deliver flag configurations (targeting and assignment rules) to server-side SDKs for synchronous variant assignment based on evaluation context. See [{{< prodname >}}Feature Flags{{< /prodname >}}][48] for more information. ## Security considerations diff --git a/hugo/content/en/security/_index.md b/hugo/content/en/security/_index.md index f6309ac3633..8d9b40a79d9 100644 --- a/hugo/content/en/security/_index.md +++ b/hugo/content/en/security/_index.md @@ -111,32 +111,32 @@ cascade: Bring speed and scale to your production security operations. Datadog Security delivers real-time threat detection, and continuous configuration audits across applications, hosts, containers, and cloud infrastructure. Coupled with the greater Datadog observability platform, Datadog Security brings unprecedented integration between security and operations aligned to your organization's shared goals. Datadog Security includes: -- [Cloud SIEM](#cloud-siem) -- [Code Security](#code-security) -- [Cloud Security](#cloud-security) -- [App and API Protection](#app-and-api-protection) -- [AI Guard](#ai-guard) -- [Workload Protection](#workload-protection) +- [{{< prodname >}}Cloud SIEM{{< /prodname >}}](#cloud-siem) +- [{{< prodname >}}Code Security{{< /prodname >}}](#code-security) +- [{{< prodname >}}Cloud Security{{< /prodname >}}](#cloud-security) +- [{{< prodname >}}App and API Protection{{< /prodname >}}](#app-and-api-protection) +- [{{< prodname >}}AI Guard{{< /prodname >}}](#ai-guard) +- [{{< prodname >}}Workload Protection{{< /prodname >}}](#workload-protection) - [Sensitive Data Scanner](#sensitive-data-scanner) To learn more, check out the [30-second Product Guided Tour][14]. ## Cloud SIEM -[Cloud SIEM][4] (Security Information and Event Management) detects real-time threats to your application and infrastructure, like a targeted attack, an IP communicating with your systems which matches a threat intel list, or an insecure configuration. Cloud SIEM is powered by [Datadog Log Management][5]. With these areas combined, you can [automate remediation of threats detected by Datadog Cloud SIEM][6] to speed up your threat-response workflow. Check out the dedicated [Guided Tour](https://www.datadoghq.com/guided-tour/security/cloud-siem/) to see more. +[{{< prodname >}}Cloud SIEM{{< /prodname >}}][4] (Security Information and {{< prodname >}}Event Management{{< /prodname >}}) detects real-time threats to your application and infrastructure, like a targeted attack, an IP communicating with your systems which matches a threat intel list, or an insecure configuration. {{< prodname >}}Cloud SIEM{{< /prodname >}} is powered by [Datadog Log Management][5]. With these areas combined, you can [automate remediation of threats detected by Datadog Cloud SIEM][6] to speed up your threat-response workflow. Check out the dedicated [Guided Tour](https://www.datadoghq.com/guided-tour/security/cloud-siem/) to see more. {{< img src="security/security_monitoring/cloud_siem_overview_2025.png" alt="The Cloud SIEM home page showing the Security Overview section with widgets for important signals, suspicious actors, impacted resources, threat intel, and signal trends" width="100%">}} ## Code Security -[Code Security][20] scans your first-party code and open source libraries used in your applications in both your repositories and running services, providing end-to-end visibility from development to production. It encompasses the following capabilities: +[{{< prodname >}}Code Security{{< /prodname >}}][20] scans your first-party code and open source libraries used in your applications in both your repositories and running services, providing end-to-end visibility from development to production. It encompasses the following capabilities: - [Static Code Analysis (SAST)][27] for identifying security and quality issues in your first-party code - [Software Composition Analysis (SCA)][28] for identifying open source dependencies in both your repositories and your services - [Runtime Code Analysis (IAST)][29] for identifying vulnerabilities in the first-party code within your services - [Secret Scanning][30] for identifying and validating leaked secrets (in Preview) -With IDE integrations, pull request comments, and CI/CD gates, Code Security helps teams implement DevSecOps throughout the organization: +With IDE integrations, pull request comments, and CI/CD gates, {{< prodname >}}Code Security{{< /prodname >}} helps teams implement DevSecOps throughout the organization: - **Developers:** early vulnerability detection, code quality improvements, faster development as developers spend less time debugging and patching. - **Security Administrators:** enhanced security posture, improved patch management in response to early vulnerability alerts, and compliance monitoring. - **Site Reliability Engineers (SREs):** automated security checks throughout CI/CD workflow, security compliance, and system resilience. SAST reduces manual overhead for SREs and ensures that each release is thoroughly tested for vulnerabilities. @@ -145,9 +145,9 @@ With IDE integrations, pull request comments, and CI/CD gates, Code Security hel ## Cloud Security -[Cloud Security][10] delivers real-time threat detection and continuous configuration audits across your entire cloud infrastructure, all in a unified view for seamless collaboration and faster remediation. Powered by observability data, security teams can determine the impact of a threat by tracing the full attack flow and identify the resource owner where a vulnerability was triggered. +[{{< prodname >}}Cloud Security{{< /prodname >}}][10] delivers real-time threat detection and continuous configuration audits across your entire cloud infrastructure, all in a unified view for seamless collaboration and faster remediation. Powered by observability data, security teams can determine the impact of a threat by tracing the full attack flow and identify the resource owner where a vulnerability was triggered. -Cloud Security includes [Workload Protection][12], [Misconfigurations][11], [Identity Risks][15], and [Vulnerabilities][16]. To learn more, check out the dedicated [Guided Tour][13]. +{{< prodname >}}Cloud Security{{< /prodname >}} includes [{{< prodname >}}Workload Protection{{< /prodname >}}][12], [Misconfigurations][11], [Identity Risks][15], and [Vulnerabilities][16]. To learn more, check out the dedicated [Guided Tour][13]. {{< img src="security/csm/csm_overview_3.png" alt="The Security Inbox on the Cloud Security overview shows a list of prioritized security issues" width="100%">}} @@ -155,19 +155,19 @@ To get started with Datadog Security, navigate to the [{{< ui >}}Security{{< /ui ## App and API Protection -Datadog [App and API Protection (AAP)][1] provides observability into application-level attacks that aim to exploit code-level vulnerabilities, such as Server-Side-Request-Forgery (SSRF), SQL injection, Log4Shell, and Reflected Cross-Site-Scripting (XSS). AAP leverages [Datadog APM][2], the [Datadog Agent][3], and in-app detection rules to detect threats in your application environment. Check out the product [Guided Tour](https://www.datadoghq.com/guided-tour/security/application-security-management/) to see more. +Datadog [App and API Protection (AAP)][1] provides observability into application-level attacks that aim to exploit code-level vulnerabilities, such as Server-Side-Request-Forgery (SSRF), SQL injection, Log4Shell, and Reflected Cross-Site-Scripting (XSS). AAP leverages [{{< prodname >}}Datadog APM{{< /prodname >}}][2], the [Datadog Agent][3], and in-app detection rules to detect threats in your application environment. Check out the product [Guided Tour](https://www.datadoghq.com/guided-tour/security/application-security-management/) to see more. {{< img src="/security/application_security/app-sec-landing-page.png" alt="A security signal panel in Datadog, which displays attack flows and flame graphs" width="75%">}} ## AI Guard -[AI Guard][35] inspects, blocks, and governs AI behavior in real time. It sits inline with your AI app or agent to protect against prompt injection, jailbreaking, and sensitive data exfiltration attacks, using Prompt Protection, Tool Protection, and Sensitive Data Protection. These protections work for any target AI model, including OpenAI, Anthropic, Bedrock, VertexAI, and Azure. +[{{< prodname >}}AI Guard{{< /prodname >}}][35] inspects, blocks, and governs AI behavior in real time. It sits inline with your AI app or agent to protect against prompt injection, jailbreaking, and sensitive data exfiltration attacks, using Prompt Protection, Tool Protection, and Sensitive Data Protection. These protections work for any target AI model, including OpenAI, Anthropic, Bedrock, VertexAI, and Azure. {{< img src="security/ai_guard/ai_guard_detection_rules_1.png" alt="AI Guard Detection Rules Explorer" width="100%">}} ## Workload Protection -[Workload Protection][26] monitors file, network, and process activity across your environment to detect real-time threats to your infrastructure. As part of the Datadog platform, you can combine the real-time threat detection of Workload Protection with metrics, logs, traces, and other telemetry to see the full context surrounding a potential attack on your workloads. +[{{< prodname >}}Workload Protection{{< /prodname >}}][26] monitors file, network, and process activity across your environment to detect real-time threats to your infrastructure. As part of the Datadog platform, you can combine the real-time threat detection of {{< prodname >}}Workload Protection{{< /prodname >}} with metrics, logs, traces, and other telemetry to see the full context surrounding a potential attack on your workloads. - Proactively block threats with [Active Protection][31]. - Manage out-of-the-box and custom [detection rules][32]. @@ -176,7 +176,7 @@ Datadog [App and API Protection (AAP)][1] provides observability into applicatio ## Sensitive Data Scanner -[Sensitive Data Scanner][24] can help prevent sensitive data leaks and limit non-compliance risks by discovering, classifying, and optionally redacting sensitive data. It can scan for sensitive data in your telemetry data, such as application logs, APM spans, RUM events, and events from Event Management. It can also scan for sensitive information within your cloud storage resources. +[Sensitive Data Scanner][24] can help prevent sensitive data leaks and limit non-compliance risks by discovering, classifying, and optionally redacting sensitive data. It can scan for sensitive data in your telemetry data, such as application logs, APM spans, RUM events, and events from {{< prodname >}}Event Management{{< /prodname >}}. It can also scan for sensitive information within your cloud storage resources. After you [set up Sensitive Data Scanner][25], use the {{< ui >}}Findings{{< /ui >}} page to see details of sensitive data findings that have been identified, so that you can triage, investigate, and remediate the findings. diff --git a/hugo/content/en/security/ai_guard/_index.md b/hugo/content/en/security/ai_guard/_index.md index 364ce75d3a3..bc84b55a050 100644 --- a/hugo/content/en/security/ai_guard/_index.md +++ b/hugo/content/en/security/ai_guard/_index.md @@ -15,27 +15,27 @@ further_reading: text: "LLM guardrails: Best practices for deploying LLM apps securely" --- -{{< site-region region="gov,gov2" >}}
AI Guard isn't available in the {{< region-param key="dd_site_name" >}} site.
+{{< site-region region="gov,gov2" >}}
{{< prodname >}}AI Guard{{< /prodname >}} isn't available in the {{< region-param key="dd_site_name" >}} site.
{{< /site-region >}} -{{< callout url="" btn_hidden="true" header="Get access to AI Guard!">}} -Use one of these forms to request access to AI Guard features: +{{< callout url="" btn_hidden="true" header="Get access to {{< prodname >}}AI Guard{{< /prodname >}}!">}} +Use one of these forms to request access to {{< prodname >}}AI Guard{{< /prodname >}} features: - Custom Agent Runtime Protection (Limited Access): Secure your custom AI agents from runtime attacks. - Coding Agent Runtime Protection (Preview): Secure your coding agents in developer workflows, so you can ship AI-generated code safely. {{< /callout >}} -Datadog AI Guard is a defense-in-depth product designed to **inspect**, **block**, and **govern** AI behavior in real time. AI Guard is built to plug in directly with existing Datadog tracing and observability workflows to secure agentic AI systems in production. It sits **inline with your AI app/agent** and layers on top of existing prompt templates, guardrails, and policy checks, to **secure your LLM workflows in the critical path**. +Datadog AI Guard is a defense-in-depth product designed to **inspect**, **block**, and **govern** AI behavior in real time. {{< prodname >}}AI Guard{{< /prodname >}} is built to plug in directly with existing Datadog tracing and observability workflows to secure agentic AI systems in production. It sits **inline with your AI app/agent** and layers on top of existing prompt templates, guardrails, and policy checks, to **secure your LLM workflows in the critical path**. -AI Guard protects against prompt injection, jailbreaking, and sensitive data exfiltration attacks with Prompt Protection, Tool Protection, and Sensitive Data Protection. Together, these capabilities protect against the [agentic lethal trifecta][3]: +{{< prodname >}}AI Guard{{< /prodname >}} protects against prompt injection, jailbreaking, and sensitive data exfiltration attacks with Prompt Protection, Tool Protection, and Sensitive Data Protection. Together, these capabilities protect against the [agentic lethal trifecta][3]: - Privileged system access - Exposure to untrusted data - Outbound communication -AI Guard also detects sensitive data such as personally identifiable information (PII) and secrets in LLM inputs and outputs. These protections work for any target AI model, including OpenAI, Anthropic, Bedrock, VertexAI, and Azure. To see your AI agents and services mapped out, including how they interact with each other and which ones AI Guard is protecting, go to the [{{< ui >}}Discover{{< /ui >}}][5] page. +{{< prodname >}}AI Guard{{< /prodname >}} also detects sensitive data such as personally identifiable information (PII) and secrets in LLM inputs and outputs. These protections work for any target AI model, including OpenAI, Anthropic, Bedrock, VertexAI, and Azure. To see your AI agents and services mapped out, including how they interact with each other and which ones {{< prodname >}}AI Guard{{< /prodname >}} is protecting, go to the [{{< ui >}}Discover{{< /ui >}}][5] page. To quickly evaluate a conversation without any code or setup, use the [{{< ui >}}AI Guard Playground{{< /ui >}}][4] to submit user input, assistant output, and tool calls, and see the evaluation result in real time. -For information on how to set up AI Guard, see [Get Started with AI Guard][1]. +For information on how to set up {{< prodname >}}AI Guard{{< /prodname >}}, see [Get Started with AI Guard][1]. ## Further reading diff --git a/hugo/content/en/security/ai_guard/onboarding.md b/hugo/content/en/security/ai_guard/onboarding.md index af212b5ab5d..9549f5dda2e 100644 --- a/hugo/content/en/security/ai_guard/onboarding.md +++ b/hugo/content/en/security/ai_guard/onboarding.md @@ -18,16 +18,16 @@ further_reading: text: "LLM guardrails: Best practices for deploying LLM apps securely" --- -{{< site-region region="gov,gov2" >}}
AI Guard isn't available in the {{< region-param key="dd_site_name" >}} site.
+{{< site-region region="gov,gov2" >}}
{{< prodname >}}AI Guard{{< /prodname >}} isn't available in the {{< region-param key="dd_site_name" >}} site.
{{< /site-region >}} -AI Guard helps secure your AI apps and agents in real time against prompt injection, jailbreaking, tool misuse, and sensitive data exfiltration attacks. AI Guard can also detect sensitive data such as PII and secrets in LLM conversations. This page describes how to set it up so you can keep your data secure against these AI-based threats. +{{< prodname >}}AI Guard{{< /prodname >}} helps secure your AI apps and agents in real time against prompt injection, jailbreaking, tool misuse, and sensitive data exfiltration attacks. {{< prodname >}}AI Guard{{< /prodname >}} can also detect sensitive data such as PII and secrets in LLM conversations. This page describes how to set it up so you can keep your data secure against these AI-based threats. -For an overview on AI Guard, see [AI Guard][13]. +For an overview on {{< prodname >}}AI Guard{{< /prodname >}}, see [{{< prodname >}}AI Guard{{< /prodname >}}][13]. ## Setup -To set up AI Guard, you need to create API keys, install an SDK, configure retention filters, and set AI Guard policies including blocking, evaluation sensitivity, and sensitive data scanning. +To set up {{< prodname >}}AI Guard{{< /prodname >}}, you need to create API keys, install an SDK, configure retention filters, and set {{< prodname >}}AI Guard{{< /prodname >}} policies including blocking, evaluation sensitivity, and sensitive data scanning. For full setup instructions, see [Set Up AI Guard][15]. @@ -39,13 +39,13 @@ After completing the [setup steps][15] and using an [SDK][21] to instrument your ## Security signals {#security-signals} -AI Guard generates security signals when it detects threats such as prompt injection, jailbreaking, or tool misuse. You can create custom detection rules, set thresholds for notifications, and investigate signals alongside other application security threats. +{{< prodname >}}AI Guard{{< /prodname >}} generates security signals when it detects threats such as prompt injection, jailbreaking, or tool misuse. You can create custom detection rules, set thresholds for notifications, and investigate signals alongside other application security threats. For more information, see [AI Guard Security Signals][14]. ## Set up Datadog Monitors for alerting {#set-up-datadog-monitors} -To create monitors for alerting at certain thresholds, you can use [Datadog Monitors][9]. You can monitor AI Guard evaluations with either APM traces or with metrics. For both types of monitor, you should set your alert conditions, name for the alert, and define notifications; Datadog recommends using Slack. +To create monitors for alerting at certain thresholds, you can use [Datadog Monitors][9]. You can monitor {{< prodname >}}AI Guard{{< /prodname >}} evaluations with either APM traces or with metrics. For both types of monitor, you should set your alert conditions, name for the alert, and define notifications; Datadog recommends using Slack. ### APM monitor @@ -63,12 +63,12 @@ Follow the instructions to create a new [metric monitor][11]. ## Evaluate conversations in AI Guard Playground {#playground} -The [{{< ui >}}AI Guard Playground{{< /ui >}}][19] lets you test AI Guard evaluations directly from the Datadog UI, without writing any code. Submit a conversation, including user input, assistant output, and tool calls, and see the evaluation result (action and reason) in real time. +The [{{< ui >}}AI Guard Playground{{< /ui >}}][19] lets you test {{< prodname >}}AI Guard{{< /prodname >}} evaluations directly from the Datadog UI, without writing any code. Submit a conversation, including user input, assistant output, and tool calls, and see the evaluation result (action and reason) in real time. Use the Playground to: -- Experiment with different prompt patterns and see how AI Guard responds. -- Verify that AI Guard correctly detects prompt injection, jailbreaking, or unsafe tool calls. -- Tweak the evaluation sensitivity threshold and see how it affects detection results. You can then adjust the threshold in AI Guard's [evaluation sensitivity][20] settings. +- Experiment with different prompt patterns and see how {{< prodname >}}AI Guard{{< /prodname >}} responds. +- Verify that {{< prodname >}}AI Guard{{< /prodname >}} correctly detects prompt injection, jailbreaking, or unsafe tool calls. +- Tweak the evaluation sensitivity threshold and see how it affects detection results. You can then adjust the threshold in {{< prodname >}}AI Guard{{< /prodname >}}'s [evaluation sensitivity][20] settings. - Test sensitive data scanning on your conversations. - Add [evaluation context][22] to a conversation to see how it affects false positives, before applying that context to a service's policy. - Share evaluation results with your team during development. diff --git a/hugo/content/en/security/ai_guard/setup/_index.md b/hugo/content/en/security/ai_guard/setup/_index.md index 6bc462919fa..cce946d0048 100644 --- a/hugo/content/en/security/ai_guard/setup/_index.md +++ b/hugo/content/en/security/ai_guard/setup/_index.md @@ -9,14 +9,14 @@ further_reading: text: Get Started with AI Guard --- -{{< site-region region="gov" >}}
AI Guard isn't available in the {{< region-param key="dd_site_name" >}} site.
+{{< site-region region="gov" >}}
{{< prodname >}}AI Guard{{< /prodname >}} isn't available in the {{< region-param key="dd_site_name" >}} site.
{{< /site-region >}} -Complete the following steps to set up AI Guard: +Complete the following steps to set up {{< prodname >}}AI Guard{{< /prodname >}}: ## 1. Check prerequisites -Before you set up AI Guard, ensure you have everything you need: +Before you set up {{< prodname >}}AI Guard{{< /prodname >}}, ensure you have everything you need: - While AI Guard is in Preview, Datadog needs to enable a backend feature flag for each organization in the Preview. Contact [Datadog support][1] with one or more Datadog organization names and regions to enable it. - Certain setup steps require specific Datadog permissions. An admin may need to create a new role with the required permissions and assign it to you: | Permission | Type | Description | @@ -36,7 +36,7 @@ If you exceed these limits, or expect to exceed them soon, contact [Datadog supp ## 2. Create API and application keys {#create-keys} -To use AI Guard, you need at least one API key and one application key set in your Agent services, usually using environment variables. Follow the instructions at [API and Application Keys][2] to create both. +To use {{< prodname >}}AI Guard{{< /prodname >}}, you need at least one API key and one application key set in your Agent services, usually using environment variables. Follow the instructions at [API and Application Keys][2] to create both. When adding [scopes][3] for the **application key**, add the `ai_guard_evaluate` scope. The user creating the application key must have the [AI Guard Evaluate permission](#1-check-prerequisites). @@ -50,7 +50,7 @@ The [AI Guard SDK][12] provides language-specific libraries (Python, JavaScript, ### Automatic integrations -[Automatic integrations][10] provide out-of-the-box AI Guard protection for supported frameworks. When you run your application with the Datadog SDK, AI Guard evaluations are automatically performed without requiring any code changes. +[Automatic integrations][10] provide out-of-the-box {{< prodname >}}AI Guard{{< /prodname >}} protection for supported frameworks. When you run your application with the Datadog SDK, {{< prodname >}}AI Guard{{< /prodname >}} evaluations are automatically performed without requiring any code changes. | Language | Supported Frameworks | |----------|------------------------------| @@ -60,7 +60,7 @@ The [AI Guard SDK][12] provides language-specific libraries (Python, JavaScript, ### Manual integrations -[Manual integrations][11] require additional configuration to enable AI Guard protection for supported frameworks. +[Manual integrations][11] require additional configuration to enable {{< prodname >}}AI Guard{{< /prodname >}} protection for supported frameworks. | Language | Supported Frameworks | |------------|--------------------------------| @@ -72,27 +72,27 @@ The [AI Guard HTTP API][13] lets you call the AI Guard JSON:API endpoint directl ## 4. Create a custom retention filter {#retention-filter} -To view AI Guard evaluations in Datadog, create a custom [retention filter][5] for AI Guard-generated spans. Follow the linked instructions to create a retention filter with the following settings: +To view {{< prodname >}}AI Guard{{< /prodname >}} evaluations in Datadog, create a custom [retention filter][5] for {{< prodname >}}AI Guard{{< /prodname >}}-generated spans. Follow the linked instructions to create a retention filter with the following settings: - {{< ui >}}Retention query{{< /ui >}}: `resource_name:ai_guard` - {{< ui >}}Span rate{{< /ui >}}: 100% - {{< ui >}}Trace rate{{< /ui >}}: 100% ## 5. Configure AI Guard policies {#configure-policies} -AI Guard provides settings to control how evaluations are enforced, how sensitive threat detection is, and whether sensitive data scanning is enabled. +{{< prodname >}}AI Guard{{< /prodname >}} provides settings to control how evaluations are enforced, how sensitive threat detection is, and whether sensitive data scanning is enabled. ### Configure service policies {#service-policies} -On the {{< ui >}}Security{{< /ui >}} > {{< ui >}}AI Guard{{< /ui >}} > {{< ui >}}Settings{{< /ui >}} > [{{< ui >}}Services{{< /ui >}}][6] page, you can configure policies that determine what actions AI Guard should take when it detects unsafe content. For each policy, you determine: +On the {{< ui >}}Security{{< /ui >}} > {{< ui >}}{{< prodname >}}AI Guard{{< /prodname >}}{{< /ui >}} > {{< ui >}}Settings{{< /ui >}} > [{{< ui >}}Services{{< /ui >}}][6] page, you can configure policies that determine what actions {{< prodname >}}AI Guard{{< /prodname >}} should take when it detects unsafe content. For each policy, you determine: - [{{< ui >}}Enforcement mode{{< /ui >}}](#blocking-policy): Monitor only, or block unsafe requests - [{{< ui >}}Sensitive data detection{{< /ui >}}](#sensitive-data-scanning): Whether AI Guard should flag sensitive data when it detects it -- [{{< ui >}}Evaluation context{{< /ui >}}](#evaluation-context): Additional information about the service that AI Guard uses during evaluation to reduce false positives +- [{{< ui >}}Evaluation context{{< /ui >}}](#evaluation-context): Additional information about the service that {{< prodname >}}AI Guard{{< /prodname >}} uses during evaluation to reduce false positives -Beside {{< ui >}}Default policy{{< /ui >}}, click {{< ui >}}Edit{{< /ui >}} to set AI Guard's default behavior. To override the default behavior, click {{< ui >}}Add Service Policy{{< /ui >}}, select the service and environment you want your override to apply to, then configure the more specialized policy. +Beside {{< ui >}}Default policy{{< /ui >}}, click {{< ui >}}Edit{{< /ui >}} to set {{< prodname >}}AI Guard{{< /prodname >}}'s default behavior. To override the default behavior, click {{< ui >}}Add Service Policy{{< /ui >}}, select the service and environment you want your override to apply to, then configure the more specialized policy. #### Blocking policy {#blocking-policy} -By default, AI Guard evaluates conversations and returns an action (`ALLOW`, `DENY`, or `ABORT`) but does not block requests. To enable blocking so that `DENY` and `ABORT` actions actively prevent unsafe interactions from proceeding, configure the blocking policy for your services. +By default, {{< prodname >}}AI Guard{{< /prodname >}} evaluates conversations and returns an action (`ALLOW`, `DENY`, or `ABORT`) but does not block requests. To enable blocking so that `DENY` and `ABORT` actions actively prevent unsafe interactions from proceeding, configure the blocking policy for your services. You can configure blocking at different levels of granularity, with more specific settings taking priority: - **Organization-wide**: Apply a default blocking policy to all services and environments. @@ -102,29 +102,29 @@ You can configure blocking at different levels of granularity, with more specifi #### Sensitive data scanning {#sensitive-data-scanning} -AI Guard can detect personally identifiable information (PII) such as email addresses, phone numbers, and SSNs, as well as secrets such as API keys and tokens, in LLM conversations. When you create or edit a policy for a service, you can choose to enable or disable sensitive data detection. +{{< prodname >}}AI Guard{{< /prodname >}} can detect personally identifiable information (PII) such as email addresses, phone numbers, and SSNs, as well as secrets such as API keys and tokens, in LLM conversations. When you create or edit a policy for a service, you can choose to enable or disable sensitive data detection. -When enabled, AI Guard scans the last message in each evaluation call, including user prompts, assistant responses, tool call arguments, and tool call results. Findings appear on APM traces for visibility. Sensitive data scanning is detection-only; findings do not independently trigger blocking. +When enabled, {{< prodname >}}AI Guard{{< /prodname >}} scans the last message in each evaluation call, including user prompts, assistant responses, tool call arguments, and tool call results. Findings appear on APM traces for visibility. Sensitive data scanning is detection-only; findings do not independently trigger blocking. -By default, AI Guard scans for a standard set of secrets, such as AWS keys and Datadog API keys. To customize which [scanning rules][14] AI Guard uses, go to {{< ui >}}Security{{< /ui >}} > {{< ui >}}Sensitive Data Scanner{{< /ui >}} > {{< ui >}}Configuration{{< /ui >}} > [{{< ui >}}AI Guard{{< /ui >}}][15], where you can enable or disable individual rules, and create scanning groups with custom rules, scoped specifically to AI Guard evaluations. +By default, {{< prodname >}}AI Guard{{< /prodname >}} scans for a standard set of secrets, such as AWS keys and Datadog API keys. To customize which [scanning rules][14] {{< prodname >}}AI Guard{{< /prodname >}} uses, go to {{< ui >}}Security{{< /ui >}} > {{< ui >}}Sensitive Data Scanner{{< /ui >}} > {{< ui >}}Configuration{{< /ui >}} > [{{< ui >}}AI Guard{{< /ui >}}][15], where you can enable or disable individual rules, and create scanning groups with custom rules, scoped specifically to {{< prodname >}}AI Guard{{< /prodname >}} evaluations. ### Block specific tools -You can configure AI Guard to block requests for specific tools, for specific services and environments. To do so, go to {{< ui >}}Security{{< /ui >}} > {{< ui >}}AI Guard{{< /ui >}} > {{< ui >}}Settings{{< /ui >}} > [{{< ui >}}Tool Blocklist{{< /ui >}}][8]. Click {{< ui >}}Add Tool Blocking Configuration{{< /ui >}}, select the service, environment, and tool, and choose whether AI Guard should follow the default service policy or block all requests for the tool. +You can configure {{< prodname >}}AI Guard{{< /prodname >}} to block requests for specific tools, for specific services and environments. To do so, go to {{< ui >}}Security{{< /ui >}} > {{< ui >}}{{< prodname >}}AI Guard{{< /prodname >}}{{< /ui >}} > {{< ui >}}Settings{{< /ui >}} > [{{< ui >}}Tool Blocklist{{< /ui >}}][8]. Click {{< ui >}}Add Tool Blocking Configuration{{< /ui >}}, select the service, environment, and tool, and choose whether {{< prodname >}}AI Guard{{< /prodname >}} should follow the default service policy or block all requests for the tool. ### Evaluation sensitivity {#evaluation-sensitivity} -AI Guard assigns a confidence score to each threat category it detects (for example, prompt injection or jailbreaking). You can control the minimum confidence score required for AI Guard to flag a threat by going to {{< ui >}}Security{{< /ui >}} > {{< ui >}}AI Guard{{< /ui >}} > {{< ui >}}Settings{{< /ui >}} > [{{< ui >}}Evaluation Sensitivity{{< /ui >}}][7]. +{{< prodname >}}AI Guard{{< /prodname >}} assigns a confidence score to each threat category it detects (for example, prompt injection or jailbreaking). You can control the minimum confidence score required for {{< prodname >}}AI Guard{{< /prodname >}} to flag a threat by going to {{< ui >}}Security{{< /ui >}} > {{< ui >}}{{< prodname >}}AI Guard{{< /prodname >}}{{< /ui >}} > {{< ui >}}Settings{{< /ui >}} > [{{< ui >}}Evaluation Sensitivity{{< /ui >}}][7]. Evaluation sensitivity is a value between 0.0 and 1.0, with a default of 0.5. -- A **lower** value **increases** sensitivity: AI Guard flags threats even when the confidence is low, surfacing more potential attacks but also more false positives. -- A **higher** value **decreases** sensitivity: AI Guard only flags threats when the confidence is high, reducing noise but potentially missing some attacks. +- A **lower** value **increases** sensitivity: {{< prodname >}}AI Guard{{< /prodname >}} flags threats even when the confidence is low, surfacing more potential attacks but also more false positives. +- A **higher** value **decreases** sensitivity: {{< prodname >}}AI Guard{{< /prodname >}} only flags threats when the confidence is high, reducing noise but potentially missing some attacks. ### Add evaluation context {#evaluation-context} -You can give AI Guard additional context about a service, such as its purpose and the type of data it processes. AI Guard uses this context during evaluation to better distinguish legitimate agent behavior from genuine threats, which helps reduce false positives. +You can give {{< prodname >}}AI Guard{{< /prodname >}} additional context about a service, such as its purpose and the type of data it processes. {{< prodname >}}AI Guard{{< /prodname >}} uses this context during evaluation to better distinguish legitimate agent behavior from genuine threats, which helps reduce false positives. -To add evaluation context for a service, go to {{< ui >}}Security{{< /ui >}} > {{< ui >}}AI Guard{{< /ui >}} > {{< ui >}}Settings{{< /ui >}} > [{{< ui >}}Services{{< /ui >}}][6]. Click {{< ui >}}Edit{{< /ui >}} beside the default policy, or add or edit a service policy, then enter your context in the {{< ui >}}Evaluation context{{< /ui >}} field (up to 1,000 characters). For example: +To add evaluation context for a service, go to {{< ui >}}Security{{< /ui >}} > {{< ui >}}{{< prodname >}}AI Guard{{< /prodname >}}{{< /ui >}} > {{< ui >}}Settings{{< /ui >}} > [{{< ui >}}Services{{< /ui >}}][6]. Click {{< ui >}}Edit{{< /ui >}} beside the default policy, or add or edit a service policy, then enter your context in the {{< ui >}}Evaluation context{{< /ui >}} field (up to 1,000 characters). For example: ```text This is a fintech app. Requests to query account balances or initiate transfers are expected and authorized. @@ -136,7 +136,7 @@ Use the [AI Guard Playground][19] to test how evaluation context affects the out ### Add context with your system prompt {#system-prompt-context} -AI Guard evaluates the full conversation, including your system prompt, when assessing threats. Adding context about your agent's purpose, the data it handles, and the tools it is authorized to use helps AI Guard distinguish legitimate operations from genuine threats—reducing false positives without reducing security coverage. +{{< prodname >}}AI Guard{{< /prodname >}} evaluates the full conversation, including your system prompt, when assessing threats. Adding context about your agent's purpose, the data it handles, and the tools it is authorized to use helps {{< prodname >}}AI Guard{{< /prodname >}} distinguish legitimate operations from genuine threats—reducing false positives without reducing security coverage.
To add this kind of context without modifying your application code, use the Evaluation context field in your service settings instead.
@@ -155,7 +155,7 @@ A system prompt with minimal context is more likely to result in false positives You are a helpful assistant. ``` -A system prompt with explicit context helps AI Guard evaluate intent accurately: +A system prompt with explicit context helps {{< prodname >}}AI Guard{{< /prodname >}} evaluate intent accurately: ``` You are a financial data analyst assistant for internal employees. You are authorized to: @@ -166,19 +166,19 @@ You are a financial data analyst assistant for internal employees. You are autho Do not access external systems or process requests unrelated to financial reporting. ``` -With this context, AI Guard treats SQL queries and file exports as expected, authorized operations, and is less likely to flag them as data exfiltration or destructive tool calls. +With this context, {{< prodname >}}AI Guard{{< /prodname >}} treats SQL queries and file exports as expected, authorized operations, and is less likely to flag them as data exfiltration or destructive tool calls. #### Limitations -Do not use the system prompt to override AI Guard's security checks or to instruct AI Guard directly. AI Guard evaluates the system prompt as part of the conversation context, and ignores instructions that attempt to disable or weaken its own security checks. +Do not use the system prompt to override {{< prodname >}}AI Guard{{< /prodname >}}'s security checks or to instruct {{< prodname >}}AI Guard{{< /prodname >}} directly. {{< prodname >}}AI Guard{{< /prodname >}} evaluates the system prompt as part of the conversation context, and ignores instructions that attempt to disable or weaken its own security checks. ## 6. (Optional) Limit access to AI Guard spans {#limit-access} -To restrict access to AI Guard spans for specific users, you can use [Data Access Control][9]. Follow the linked instructions to create a restricted dataset, scoped to **APM data**, with the `resource_name:ai_guard` filter applied. Then, you can grant access to the dataset to specific roles or teams. +To restrict access to {{< prodname >}}AI Guard{{< /prodname >}} spans for specific users, you can use [Data Access Control][9]. Follow the linked instructions to create a restricted dataset, scoped to **APM data**, with the `resource_name:ai_guard` filter applied. Then, you can grant access to the dataset to specific roles or teams. ## Disable APM tracing -To disable APM tracing on the tracer while keeping AI Guard enabled, set `DD_APM_TRACING_ENABLED=false`: +To disable APM tracing on the tracer while keeping {{< prodname >}}AI Guard{{< /prodname >}} enabled, set `DD_APM_TRACING_ENABLED=false`: {{< code-block lang="bash" >}} DD_AI_GUARD_ENABLED=true diff --git a/hugo/content/en/security/ai_guard/setup/automatic_integrations.md b/hugo/content/en/security/ai_guard/setup/automatic_integrations.md index bb50eea9616..b0be9e4a2aa 100644 --- a/hugo/content/en/security/ai_guard/setup/automatic_integrations.md +++ b/hugo/content/en/security/ai_guard/setup/automatic_integrations.md @@ -9,10 +9,10 @@ further_reading: text: SDK --- -{{< site-region region="gov" >}}
AI Guard isn't available in the {{< region-param key="dd_site_name" >}} site.
+{{< site-region region="gov" >}}
{{< prodname >}}AI Guard{{< /prodname >}} isn't available in the {{< region-param key="dd_site_name" >}} site.
{{< /site-region >}} -AI Guard can automatically evaluate LLM calls made through supported AI ecosystem packages, without requiring manual API calls. When your application uses one of the supported packages, the Datadog SDK instruments it to evaluate those calls through AI Guard automatically. No code changes are required. +{{< prodname >}}AI Guard{{< /prodname >}} can automatically evaluate LLM calls made through supported AI ecosystem packages, without requiring manual API calls. When your application uses one of the supported packages, the Datadog SDK instruments it to evaluate those calls through {{< prodname >}}AI Guard{{< /prodname >}} automatically. No code changes are required. ## Supported frameworks and libraries @@ -48,11 +48,11 @@ AI Guard can automatically evaluate LLM calls made through supported AI ecosyste {{< tabs >}} {{% tab "LangChain" %}} -The LangChain integration automatically applies AI Guard evaluations to calls made through the [LangChain Python SDK][1]. +The LangChain integration automatically applies {{< prodname >}}AI Guard{{< /prodname >}} evaluations to calls made through the [LangChain Python SDK][1]. #### Traced operations -AI Guard automatically evaluates the following LangChain operations: +{{< prodname >}}AI Guard{{< /prodname >}} automatically evaluates the following LangChain operations: - LLMs: - `llm.invoke()`, `llm.ainvoke()` @@ -66,11 +66,11 @@ AI Guard automatically evaluates the following LangChain operations: [3]: https://docs.langchain.com/oss/python/langchain/tools {{% /tab %}} {{% tab "OpenAI" %}} -The OpenAI integration automatically applies AI Guard evaluations to calls made through the [OpenAI Python SDK][1]. +The OpenAI integration automatically applies {{< prodname >}}AI Guard{{< /prodname >}} evaluations to calls made through the [OpenAI Python SDK][1]. #### Traced operations -AI Guard automatically evaluates the following OpenAI operations: +{{< prodname >}}AI Guard{{< /prodname >}} automatically evaluates the following OpenAI operations: - [Chat completions][2]: - `client.chat.completions.create()` @@ -84,17 +84,17 @@ AI Guard automatically evaluates the following OpenAI operations: [3]: https://platform.openai.com/docs/api-reference/responses {{% /tab %}} {{% tab "Anthropic" %}} -The Anthropic integration automatically applies AI Guard evaluations to calls made through the [Anthropic Python SDK][1]. +The Anthropic integration automatically applies {{< prodname >}}AI Guard{{< /prodname >}} evaluations to calls made through the [Anthropic Python SDK][1]. #### Traced operations -AI Guard automatically evaluates the following Anthropic operations: +{{< prodname >}}AI Guard{{< /prodname >}} automatically evaluates the following Anthropic operations: - [Messages][2]: - `client.messages.create()` - `client.messages.stream()` -For the `anthropic` package >= 0.37.0, AI Guard also evaluates the following beta messages operations: +For the `anthropic` package >= 0.37.0, {{< prodname >}}AI Guard{{< /prodname >}} also evaluates the following beta messages operations: - Beta messages: - `client.beta.messages.create()` @@ -109,7 +109,7 @@ For the `anthropic` package >= 0.37.0, AI Guard also evaluates the following bet {{< tabs >}} {{% tab "AI SDK" %}} -The [AI SDK][1] integration automatically applies AI Guard evaluations to text and object generation, embeddings, and tool calls. +The [AI SDK][1] integration automatically applies {{< prodname >}}AI Guard{{< /prodname >}} evaluations to text and object generation, embeddings, and tool calls. #### Traced operations @@ -128,11 +128,11 @@ The [AI SDK][1] integration automatically applies AI Guard evaluations to text a [4]: https://ai-sdk.dev/docs/ai-sdk-core/tools-and-tool-calling {{% /tab %}} {{% tab "OpenAI" %}} -The OpenAI integration automatically applies AI Guard evaluations to calls made through the [OpenAI Node.js SDK][1]. +The OpenAI integration automatically applies {{< prodname >}}AI Guard{{< /prodname >}} evaluations to calls made through the [OpenAI Node.js SDK][1]. #### Traced operations -AI Guard automatically evaluates the following OpenAI operations: +{{< prodname >}}AI Guard{{< /prodname >}} automatically evaluates the following OpenAI operations: - [Chat completions][2]: - `client.chat.completions.create()` @@ -140,7 +140,7 @@ AI Guard automatically evaluates the following OpenAI operations: - [Responses API][3]: - `client.responses.create()` -**Note:** Streaming requests (`stream: true`) are not evaluated by AI Guard. +**Note:** Streaming requests (`stream: true`) are not evaluated by {{< prodname >}}AI Guard{{< /prodname >}}. [1]: https://github.com/openai/openai-node [2]: https://platform.openai.com/docs/api-reference/chat @@ -152,11 +152,11 @@ AI Guard automatically evaluates the following OpenAI operations: {{< tabs >}} {{% tab "RubyLLM" %}} -The [RubyLLM][1] integration automatically applies AI Guard evaluations to chat messages and tool calls. +The [RubyLLM][1] integration automatically applies {{< prodname >}}AI Guard{{< /prodname >}} evaluations to chat messages and tool calls. #### Traced operations -AI Guard automatically evaluates the following RubyLLM operations: +{{< prodname >}}AI Guard{{< /prodname >}} automatically evaluates the following RubyLLM operations: - [Chat][2]: - `RubyLLM::Chat#ask` diff --git a/hugo/content/en/security/ai_guard/setup/http_api.md b/hugo/content/en/security/ai_guard/setup/http_api.md index c505bc08aea..2888f6bde78 100644 --- a/hugo/content/en/security/ai_guard/setup/http_api.md +++ b/hugo/content/en/security/ai_guard/setup/http_api.md @@ -9,16 +9,16 @@ further_reading: text: SDK --- -{{< site-region region="gov" >}}
AI Guard isn't available in the {{< region-param key="dd_site_name" >}} site.
+{{< site-region region="gov" >}}
{{< prodname >}}AI Guard{{< /prodname >}} isn't available in the {{< region-param key="dd_site_name" >}} site.
{{< /site-region >}} -AI Guard provides a single JSON:API endpoint: +{{< prodname >}}AI Guard{{< /prodname >}} provides a single JSON:API endpoint: `POST {{< region-param key=dd_api >}}/api/v2/ai-guard/evaluate`
The endpoint URL varies by region. Ensure you're using the correct Datadog site for your organization.
-
HTTP API requests do not send traces to Datadog. AI Guard evaluations performed through the HTTP API do not appear in the Datadog UI. To view AI Guard activity in Datadog, use the SDK instead.
+
HTTP API requests do not send traces to Datadog. {{< prodname >}}AI Guard{{< /prodname >}} evaluations performed through the HTTP API do not appear in the Datadog UI. To view {{< prodname >}}AI Guard{{< /prodname >}} activity in Datadog, use the SDK instead.
## Examples {#api-examples} ### Generic API example @@ -78,7 +78,7 @@ curl -s -XPOST \ #### Explanation {#api-example-generic-explanation} -1. The request contains one attribute: `messages`. This attribute contains the full sequence of messages in the LLM call. AI Guard evaluates the last message in the sequence. See the [Request message format](#request-message-format) section for more details. +1. The request contains one attribute: `messages`. This attribute contains the full sequence of messages in the LLM call. {{< prodname >}}AI Guard{{< /prodname >}} evaluates the last message in the sequence. See the [Request message format](#request-message-format) section for more details. 2. The response has two attributes: `action` and `reason`. - `action` can be `ALLOW`, `DENY`, or `ABORT`. - `ALLOW`: Interaction is safe and should proceed. @@ -88,7 +88,7 @@ curl -s -XPOST \ ### Evaluate user prompt -In the initial example, AI Guard evaluated a tool call in the context of its system and user prompt. It can also evaluate user prompts. +In the initial example, {{< prodname >}}AI Guard{{< /prodname >}} evaluated a tool call in the context of its system and user prompt. It can also evaluate user prompts. #### Request {#api-example-evaluate-user-prompt-request} diff --git a/hugo/content/en/security/ai_guard/setup/manual_integrations.md b/hugo/content/en/security/ai_guard/setup/manual_integrations.md index a79251e3d32..c502b17d9bb 100644 --- a/hugo/content/en/security/ai_guard/setup/manual_integrations.md +++ b/hugo/content/en/security/ai_guard/setup/manual_integrations.md @@ -9,10 +9,10 @@ further_reading: text: SDK --- -{{< site-region region="gov" >}}
AI Guard isn't available in the {{< region-param key="dd_site_name" >}} site.
+{{< site-region region="gov" >}}
{{< prodname >}}AI Guard{{< /prodname >}} isn't available in the {{< region-param key="dd_site_name" >}} site.
{{< /site-region >}} -Manual integrations require additional configuration to enable AI Guard protection. Follow the instructions for each framework to set up AI Guard evaluations. +Manual integrations require additional configuration to enable {{< prodname >}}AI Guard{{< /prodname >}} protection. Follow the instructions for each framework to set up {{< prodname >}}AI Guard{{< /prodname >}} evaluations. ## Supported frameworks and libraries ### Python @@ -29,7 +29,7 @@ Manual integrations require additional configuration to enable AI Guard protecti ### Amazon Strands #### Python -The Amazon Strands integration enables AI Guard evaluations for applications built with the [Amazon Strands Agents SDK][1]. +The Amazon Strands integration enables {{< prodname >}}AI Guard{{< /prodname >}} evaluations for applications built with the [Amazon Strands Agents SDK][1]. ##### Setup @@ -68,7 +68,7 @@ agent = Agent( ### LiteLLM Proxy #### Python -The LiteLLM Proxy integration enables AI Guard evaluations for applications using the [LiteLLM Proxy][1]. +The LiteLLM Proxy integration enables {{< prodname >}}AI Guard{{< /prodname >}} evaluations for applications using the [LiteLLM Proxy][1]. ##### Setup @@ -101,7 +101,7 @@ guardrails: The guardrail supports all three modes: `pre_call`, `post_call`, and `during_call`. -By default, the guardrail follows the blocking configuration set in the AI Guard service settings. To disable blocking, set the `block` parameter to `false` (equivalent to the `block` option in the [SDK][2] and [REST API][3]). +By default, the guardrail follows the blocking configuration set in the {{< prodname >}}AI Guard{{< /prodname >}} service settings. To disable blocking, set the `block` parameter to `false` (equivalent to the `block` option in the [SDK][2] and [REST API][3]). [1]: https://docs.litellm.ai/docs/simple_proxy [2]: /security/ai_guard/setup/sdk/ diff --git a/hugo/content/en/security/ai_guard/setup/sdk.md b/hugo/content/en/security/ai_guard/setup/sdk.md index b41109aa3ec..d2e30788802 100644 --- a/hugo/content/en/security/ai_guard/setup/sdk.md +++ b/hugo/content/en/security/ai_guard/setup/sdk.md @@ -9,16 +9,16 @@ further_reading: text: HTTP API --- -{{< site-region region="gov" >}}
AI Guard isn't available in the {{< region-param key="dd_site_name" >}} site.
+{{< site-region region="gov" >}}
{{< prodname >}}AI Guard{{< /prodname >}} isn't available in the {{< region-param key="dd_site_name" >}} site.
{{< /site-region >}} -Use an SDK to call the AI Guard REST API and monitor AI Guard activity in real time in Datadog. +Use an SDK to call the AI Guard REST API and monitor {{< prodname >}}AI Guard{{< /prodname >}} activity in real time in Datadog. {{< partial name="security-platform/aiguard-sdk-setup.html" target="manual" >}} ## Install the SDK -To use AI Guard and see AI Guard activity in Datadog, install the appropriate SDK for your language. The SDK requires the Datadog Agent to send data to Datadog. +To use {{< prodname >}}AI Guard{{< /prodname >}} and see {{< prodname >}}AI Guard{{< /prodname >}} activity in Datadog, install the appropriate SDK for your language. The SDK requires the Datadog Agent to send data to Datadog. {{< tabs >}} {{% tab "Python" %}} @@ -80,7 +80,7 @@ result = client.evaluate( ``` The `evaluate` method accepts the following parameters: -- `messages` (required): list of `Message` objects (prompts or tool calls) for AI Guard to evaluate. +- `messages` (required): list of `Message` objects (prompts or tool calls) for {{< prodname >}}AI Guard{{< /prodname >}} to evaluate. - `options` (optional): an `Options` object with a `block` flag. When set to `True`, the SDK raises an `AIGuardAbortError` when the assessment is `DENY` or `ABORT` and the service is configured with blocking enabled. When omitted, blocking follows the remote `is_blocking_enabled` setting. The method returns an `Evaluation` object containing: @@ -155,7 +155,7 @@ const result = await tracer.aiguard.evaluate([ ``` The evaluate method returns a promise and receives the following parameters: -- `messages` (required): array of message objects (prompts or tool calls) for AI Guard to evaluate. +- `messages` (required): array of message objects (prompts or tool calls) for {{< prodname >}}AI Guard{{< /prodname >}} to evaluate. - `opts` (optional): object with a `block` flag. When set to `true`, the SDK rejects the promise with `AIGuardAbortError` when the assessment is `DENY` or `ABORT` and the service is configured with blocking enabled. When omitted, blocking follows the remote `is_blocking_enabled` setting. The method returns a promise that resolves to an Evaluation object containing: @@ -211,7 +211,7 @@ final AIGuard.Evaluation evaluation = AIGuard.evaluate( ``` The evaluate method receives the following parameters: -- `messages` (required): list of `Message` objects (prompts or tool calls) for AI Guard to evaluate. +- `messages` (required): list of `Message` objects (prompts or tool calls) for {{< prodname >}}AI Guard{{< /prodname >}} to evaluate. - `options` (optional): `Options` object with a `block` flag. When set to `true`, the SDK throws an `AIGuardAbortError` when the assessment is `DENY` or `ABORT` and the service is configured with blocking enabled. When omitted, blocking follows the remote `is_blocking_enabled` setting. The method returns an `Evaluation` object containing: @@ -294,7 +294,7 @@ result = Datadog::AIGuard.evaluate( ``` The evaluate method receives the following parameters: -- `messages` (required): list of messages (prompts or tool calls) for AI Guard to evaluate. +- `messages` (required): list of messages (prompts or tool calls) for {{< prodname >}}AI Guard{{< /prodname >}} to evaluate. - `allow_raise` (optional): Boolean flag; if set to `false`, the method will not not raise an `AIGuardAbortError` when the assessment is `DENY` or `ABORT`. This SDK method raises an `AIGuardAbortError` when the assessment is `DENY` or `ABORT` and if the service is configured with blocking enabled. diff --git a/hugo/content/en/security/ai_guard/signals.md b/hugo/content/en/security/ai_guard/signals.md index d36a172c1c6..5bdf04759c4 100644 --- a/hugo/content/en/security/ai_guard/signals.md +++ b/hugo/content/en/security/ai_guard/signals.md @@ -12,31 +12,31 @@ further_reading: text: Detection Rules --- -{{< site-region region="gov" >}}
AI Guard isn't available in the {{< region-param key="dd_site_name" >}} site.
+{{< site-region region="gov" >}}
{{< prodname >}}AI Guard{{< /prodname >}} isn't available in the {{< region-param key="dd_site_name" >}} site.
{{< /site-region >}} -AI Guard security signals provide visibility into threats and attacks AI Guard detects in your applications. These signals are built on top of [AAP (Application and API Protection) security signals][1] and integrate with Datadog's security monitoring workflows. +{{< prodname >}}AI Guard{{< /prodname >}} security signals provide visibility into threats and attacks {{< prodname >}}AI Guard{{< /prodname >}} detects in your applications. These signals are built on top of [AAP (Application and API Protection) security signals][1] and integrate with Datadog's security monitoring workflows. ## Understand AI Guard signals -Datadog creates AI Guard security signals when it detects a threat based on a configured detection rule. Signals indicating threats such as prompt injection, jailbreaking, or tool misuse appear in the Datadog Security Signals explorer. These signals can provide: +Datadog creates {{< prodname >}}AI Guard{{< /prodname >}} security signals when it detects a threat based on a configured detection rule. Signals indicating threats such as prompt injection, jailbreaking, or tool misuse appear in the Datadog Security Signals explorer. These signals can provide: - **Threat detection**: Attack context based on your configured detection rules - **Action insights**: Blocked or allowed actions information according to your rule settings -- **Rich investigation context**: Attack categories detected, AI Guard evaluation results, and links to related AI Guard spans for comprehensive analysis +- **Rich investigation context**: Attack categories detected, {{< prodname >}}AI Guard{{< /prodname >}} evaluation results, and links to related {{< prodname >}}AI Guard{{< /prodname >}} spans for comprehensive analysis - **Custom runbooks**: Custom remediation guidance and response procedures for specific threat scenarios -To help you prioritize your remediation efforts, AI Guard automatically assigns a severity level to every security signal. You can create [custom detection rules](#create-detection-rules) to customize severity levels and define specific security responses. +To help you prioritize your remediation efforts, {{< prodname >}}AI Guard{{< /prodname >}} automatically assigns a severity level to every security signal. You can create [custom detection rules](#create-detection-rules) to customize severity levels and define specific security responses. ## Create detection rules You can create custom detection rules by defining thresholds for when you want to receive notifications; for example, more than 5 `DENY` actions in 10 minutes. When AI Guard evaluations exceed those thresholds, it generates security signals. -To create AI Guard detection rules: +To create {{< prodname >}}AI Guard{{< /prodname >}} detection rules: 1. In Datadog, go to the [AI Guard detection rule explorer][2], then click {{< ui >}}New Rule{{< /ui >}}. {{< img src="security/ai_guard/ai_guard_detection_rules_1.png" alt="AI Guard Detection Rules Explorer" style="width:100%;" >}} 1. Under {{< ui >}}Define your Real-time rule{{< /ui >}}, choose the type of rule to create. -1. Under {{< ui >}}Define Search Queries{{< /ui >}}, define the types of tags you want to create signals for. You can use the following AI Guard attributes to filter and target specific threat patterns: +1. Under {{< ui >}}Define Search Queries{{< /ui >}}, define the types of tags you want to create signals for. You can use the following {{< prodname >}}AI Guard{{< /prodname >}} attributes to filter and target specific threat patterns: @@ -48,7 +48,7 @@ To create AI Guard detection rules: - + @@ -94,10 +94,10 @@ To create AI Guard detection rules:
@ai_guard.actionFilter by AI Guard's evaluation resultFilter by {{< prodname >}}AI Guard{{< /prodname >}}'s evaluation result ALLOW or DENY
1. Under {{< ui >}}Define Rule Conditions{{< /ui >}}: 1. Define your threshold conditions, if applicable to the type of rule you chose. - 1. Set the severity level of the security signals AI Guard generates with this rule. + 1. Set the severity level of the security signals {{< prodname >}}AI Guard{{< /prodname >}} generates with this rule. 1. Choose who should get notifications for new signals and how often. 1. Choose security responses to take, such as automated IP or user blocking, and IP flagging. - 1. Configure additional settings, such as updating the same signal instead of creating a new one if AI Guard detects new values within a set amount of time, and decreasing signal severity for non-production environments. + 1. Configure additional settings, such as updating the same signal instead of creating a new one if {{< prodname >}}AI Guard{{< /prodname >}} detects new values within a set amount of time, and decreasing signal severity for non-production environments. 1. Under {{< ui >}}Describe your Playbook{{< /ui >}}, customize the notification and define tags to send with the signals. 1. Click {{< ui >}}Save Rule{{< /ui >}}. @@ -105,25 +105,25 @@ For more comprehensive detection rule capabilities, see [detection rules][3]. ## Investigate signals -To view and investigate AI Guard security signals, and correlate them with other security events, you can view signals in two places: +To view and investigate {{< prodname >}}AI Guard{{< /prodname >}} security signals, and correlate them with other security events, you can view signals in two places: - [Application and API Protection Security Signals explorer][4] - [Cloud SIEM Security Signals explorer][5] - In the Cloud SIEM Security Signals explorer, beside the search bar, click the {{< ui >}}Filter{{< /ui >}} icon and select the {{< ui >}}App & API Protection{{< /ui >}} checkbox to view AI Guard signals. + In the Cloud SIEM Security Signals explorer, beside the search bar, click the {{< ui >}}Filter{{< /ui >}} icon and select the {{< ui >}}App & API Protection{{< /ui >}} checkbox to view {{< prodname >}}AI Guard{{< /prodname >}} signals. -The Security Signals explorers allow you to filter, prioritize, and investigate AI Guard signals alongside other application security threats, providing a unified view of your security posture. +The Security Signals explorers allow you to filter, prioritize, and investigate {{< prodname >}}AI Guard{{< /prodname >}} signals alongside other application security threats, providing a unified view of your security posture. -You can create or link cases directly from an AI Guard security signal, and click any signal to open a side panel containing additional context. +You can create or link cases directly from an {{< prodname >}}AI Guard{{< /prodname >}} security signal, and click any signal to open a side panel containing additional context. ## Get additional context with spans -AI Guard spans offer detailed information about the assessments it made and why. When you open a span from the [Investigate][6] page or from a signal, you can get context on the specific prompts your AI agent used, read exact inputs and outputs, and see any attack categories that contributed to AI Guard assessing a tool call as unsafe. +{{< prodname >}}AI Guard{{< /prodname >}} spans offer detailed information about the assessments it made and why. When you open a span from the [Investigate][6] page or from a signal, you can get context on the specific prompts your AI agent used, read exact inputs and outputs, and see any attack categories that contributed to {{< prodname >}}AI Guard{{< /prodname >}} assessing a tool call as unsafe. ### Get context on a span When you click on a span in the explorer, you can see: - The service and environment the requests occurred in -- The [blocking policy][7] configured for that service, which determines whether AI Guard blocks unsafe requests, or detects and tags them without blocking them +- The [blocking policy][7] configured for that service, which determines whether {{< prodname >}}AI Guard{{< /prodname >}} blocks unsafe requests, or detects and tags them without blocking them - The user who interacted with the agent - The specific inputs and outputs from your agent, and whether they came from LLMs or external tools - Whether AI Guard assessed each request as safe or unsafe diff --git a/hugo/content/en/security/application_security/_index.md b/hugo/content/en/security/application_security/_index.md index e8829fac23d..32adfb602c5 100644 --- a/hugo/content/en/security/application_security/_index.md +++ b/hugo/content/en/security/application_security/_index.md @@ -46,14 +46,14 @@ cascade: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} {{% site-region region="us,us3,us5,eu,ap1,ap2,uk1" %}}
-AI Guard is in Preview. Get real-time security guardrails for your AI apps and agents. AI Guard helps secure your AI apps and agents in real time against prompt injection, jailbreaking, tool misuse, and sensitive data exfiltration attacks. Fill out this form to request access. +{{< prodname >}}AI Guard{{< /prodname >}} is in Preview. Get real-time security guardrails for your AI apps and agents. {{< prodname >}}AI Guard{{< /prodname >}} helps secure your AI apps and agents in real time against prompt injection, jailbreaking, tool misuse, and sensitive data exfiltration attacks. Fill out this form to request access.
{{% /site-region %}} @@ -91,7 +91,7 @@ Whether you're defending public-facing APIs, internal services, or user-facing a ## AAP implementation in Datadog -If you're curious how App and API Protection is structured and how it uses tracing data to identify security problems, read [How App and API Protection Works][3]. +If you're curious how {{< prodname >}}App and API Protection{{< /prodname >}} is structured and how it uses tracing data to identify security problems, read [How App and API Protection Works][3]. ## Configure your environment diff --git a/hugo/content/en/security/application_security/api_posture/_index.md b/hugo/content/en/security/application_security/api_posture/_index.md index f2fbdfbaddd..d88bbecb60a 100644 --- a/hugo/content/en/security/application_security/api_posture/_index.md +++ b/hugo/content/en/security/application_security/api_posture/_index.md @@ -9,11 +9,11 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} -Use API Posture in [App and API Protection][1] (AAP) to discover your APIs, assess the risks they expose, and track your security posture. +Use API Posture in [{{< prodname >}}App and API Protection{{< /prodname >}}][1] (AAP) to discover your APIs, assess the risks they expose, and track your security posture. To get started, [set up AAP][2] on your services to discover endpoints from your live traffic. Other data sources, such as Amazon API Gateway and source code, require additional setup; see [API Endpoints][3] for details. diff --git a/hugo/content/en/security/application_security/api_posture/api_findings.md b/hugo/content/en/security/application_security/api_posture/api_findings.md index 28484e0abc1..8d79e32b3fa 100644 --- a/hugo/content/en/security/application_security/api_posture/api_findings.md +++ b/hugo/content/en/security/application_security/api_posture/api_findings.md @@ -5,7 +5,7 @@ description: Triage detected API risks across definitions, gateways, and live tr {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -38,21 +38,21 @@ Click a finding to view its details and perform a workflow such as Validate > In ## Remediation -Datadog API Posture uses [Bits Code][3] to generate code fixes for vulnerabilities. +Datadog API Posture uses [{{< prodname >}}Bits Code{{< /prodname >}}][3] to generate code fixes for vulnerabilities. 1. In Datadog, navigate to [**Security** > **App & API Protection** > **Findings**][1]. 2. Select a finding to open a side panel with details about the finding and the affected endpoint. 3. In the **Next Steps** > **Remediation** section, click **Fix with Bits**. -This opens a Bits Code session to fix this single API finding. You can review the proposed diff, ask follow-up questions, edit the patch, and create a pull request to apply the remediation to your source code repository. -View all Bits Code sessions on **Bits AI** > **Bits Code** > [**Sessions**][4]. +This opens a {{< prodname >}}Bits Code{{< /prodname >}} session to fix this single API finding. You can review the proposed diff, ask follow-up questions, edit the patch, and create a pull request to apply the remediation to your source code repository. +View all {{< prodname >}}Bits Code{{< /prodname >}} sessions on **Bits AI** > **{{< prodname >}}Bits Code{{< /prodname >}}** > [**Sessions**][4]. ### Remediation session details Each Bits Code session shows the life cycle of an AI-generated fix so you can review and validate changes before merging. It includes: - The original security finding and proposed code change -- An explanation of how and why Bits Code generated the fix +- An explanation of how and why {{< prodname >}}Bits Code{{< /prodname >}} generated the fix - CI results (if enabled) to validate the patch is safe to deploy - Options to refine the fix or **Create PR** to apply the changes to your source code repository diff --git a/hugo/content/en/security/application_security/api_posture/api_inventory/_index.md b/hugo/content/en/security/application_security/api_posture/api_inventory/_index.md index bff778e5d55..8c92582ffaf 100644 --- a/hugo/content/en/security/application_security/api_posture/api_inventory/_index.md +++ b/hugo/content/en/security/application_security/api_posture/api_inventory/_index.md @@ -11,7 +11,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} diff --git a/hugo/content/en/security/application_security/api_posture/api_inventory/api_endpoints.md b/hugo/content/en/security/application_security/api_posture/api_inventory/api_endpoints.md index 7dbd44afa53..f85bb193859 100644 --- a/hugo/content/en/security/application_security/api_posture/api_inventory/api_endpoints.md +++ b/hugo/content/en/security/application_security/api_posture/api_inventory/api_endpoints.md @@ -5,7 +5,7 @@ description: Monitor API traffic to assess endpoint risk, authentication, sensit {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -17,7 +17,7 @@ The [API Endpoints][1] explorer monitors your API traffic to provide visibility - **Sensitive data flows**: Sensitive data handled by the API, and the flows between APIs. - **Attack Exposure**: If the endpoint is targeted by attacks. - **Business Logic**: Business logic and associated business logic suggestions for this API. -- **Vulnerabilities**: If the endpoint contains a vulnerability (powered by [Code Security][2] and [Software Composition Analysis][3]). +- **Vulnerabilities**: If the endpoint contains a vulnerability (powered by [{{< prodname >}}Code Security{{< /prodname >}}][2] and [Software Composition Analysis][3]). - **Findings**: Security findings identified on this API. - **Dependencies**: APIs and Databases the API depends on. @@ -55,7 +55,7 @@ For information on what library versions are compatible with API Inventory, see ## How it works -API Endpoints gathers security metadata about API traffic by using the Datadog SDK with App and API Protection enabled, alongside configurations from Amazon API Gateway and uploaded API Definitions. This data includes the discovered API schema, the types of sensitive data (PII) processed, and the authentication scheme in use. The API information is continuously evaluated, helping ensure a comprehensive and up-to-date view of your entire API attack surface. +API Endpoints gathers security metadata about API traffic by using the Datadog SDK with {{< prodname >}}App and API Protection{{< /prodname >}} enabled, alongside configurations from Amazon API Gateway and uploaded API Definitions. This data includes the discovered API schema, the types of sensitive data (PII) processed, and the authentication scheme in use. The API information is continuously evaluated, helping ensure a comprehensive and up-to-date view of your entire API attack surface. API Endpoints uses [Remote Configuration][10] to manage and configure scanning rules that detect sensitive data and authentication. @@ -104,7 +104,7 @@ The actions you take depend on the attack surface: The {{< ui >}}Source Code{{< /ui >}} data source shows API endpoints discovered directly from your source code. This complements runtime-based discovery by surfacing endpoints earlier in the development life cycle, including endpoints that may not receive live traffic. -To use this data source, configure the [Source Code Integration][12] with GitHub, GitLab, or Azure DevOps. The following languages and frameworks are supported: +To use this data source, configure the [{{< prodname >}}Source Code Integration{{< /prodname >}}][12] with GitHub, GitLab, or Azure DevOps. The following languages and frameworks are supported: | Language | Framework | |----------|-----------| @@ -187,7 +187,7 @@ To reduce noise, some differences are excluded because they don't represent mean ## Processing sensitive data -App and API Protection detects and classifies sensitive data processed by your endpoints, tagging each endpoint with the category and type of data found. To see which endpoints process sensitive data and to create custom API data scanners, see [Sensitive Data][16]. +{{< prodname >}}App and API Protection{{< /prodname >}} detects and classifies sensitive data processed by your endpoints, tagging each endpoint with the category and type of data found. To see which endpoints process sensitive data and to create custom API data scanners, see [Sensitive Data][16]. ## Business logic diff --git a/hugo/content/en/security/application_security/api_posture/api_inventory/services.md b/hugo/content/en/security/application_security/api_posture/api_inventory/services.md index 5c95bff2778..bca2c6b45b4 100644 --- a/hugo/content/en/security/application_security/api_posture/api_inventory/services.md +++ b/hugo/content/en/security/application_security/api_posture/api_inventory/services.md @@ -5,7 +5,7 @@ description: View where API findings, vulnerabilities, and runtime signals conve {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -16,7 +16,7 @@ Review your services for the following: - **Vulnerability risk:** The {{< ui >}}Vulnerability Risk{{< /ui >}} column shows aggregated SCA and IAST results for each service. Vulnerable services have components needing patching or upgrading. - **Signals and attacks:** Click a service to see charts showing ongoing detections for active exploit attempts or recurring attack patterns. - **Sensitive data exposure:** Services processing PII (such as SSNs or emails) demand stricter controls and monitoring. -- **Coverage and mode:** Use the {{< ui >}}App & API Protection In Monitoring Mode{{< /ui >}}, {{< ui >}}App & API Protection In Blocking Mode{{< /ui >}}, and the {{< ui >}}Inactive{{< /ui >}} facet to identify where App and API Protection is enabled and enforcing runtime protection. +- **Coverage and mode:** Use the {{< ui >}}App & API Protection In Monitoring Mode{{< /ui >}}, {{< ui >}}App & API Protection In Blocking Mode{{< /ui >}}, and the {{< ui >}}Inactive{{< /ui >}} facet to identify where {{< prodname >}}App and API Protection{{< /prodname >}} is enabled and enforcing runtime protection. - **Trend graphs:** The {{< ui >}}Trend{{< /ui >}} column indicates activity and attack frequency over time. ## Coverage @@ -25,7 +25,7 @@ The {{< ui >}}Coverage{{< /ui >}} column shows the active protection and analysi For example, here are some use cases for {{< ui >}}Coverage{{< /ui >}}: -- **Runtime protection coverage with App and API Protection**: +- **Runtime protection coverage with {{< prodname >}}App and API Protection{{< /prodname >}}**: - Identify the services in {{< ui >}}Monitoring{{< /ui >}} or {{< ui >}}Blocking{{< /ui >}} mode. - Move ready-to-block services into blocking mode to actively stop attacks. - Investigate inactive services to see if instrumentation or configuration gaps are leaving APIs exposed. diff --git a/hugo/content/en/security/application_security/api_posture/compliance.md b/hugo/content/en/security/application_security/api_posture/compliance.md index 97657664dbf..778b6a84777 100644 --- a/hugo/content/en/security/application_security/api_posture/compliance.md +++ b/hugo/content/en/security/application_security/api_posture/compliance.md @@ -12,7 +12,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} diff --git a/hugo/content/en/security/application_security/api_posture/endpoint_scanning.md b/hugo/content/en/security/application_security/api_posture/endpoint_scanning.md index a60d5e1cd74..da1b1966e9a 100644 --- a/hugo/content/en/security/application_security/api_posture/endpoint_scanning.md +++ b/hugo/content/en/security/application_security/api_posture/endpoint_scanning.md @@ -5,7 +5,7 @@ description: Verify whether discovered API endpoints are publicly accessible and {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} diff --git a/hugo/content/en/security/application_security/api_posture/overview.md b/hugo/content/en/security/application_security/api_posture/overview.md index 37d13a7155a..276d9e1b0c6 100644 --- a/hugo/content/en/security/application_security/api_posture/overview.md +++ b/hugo/content/en/security/application_security/api_posture/overview.md @@ -12,7 +12,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} diff --git a/hugo/content/en/security/application_security/api_posture/sensitive_data.md b/hugo/content/en/security/application_security/api_posture/sensitive_data.md index 21d364e14db..130a2651019 100644 --- a/hugo/content/en/security/application_security/api_posture/sensitive_data.md +++ b/hugo/content/en/security/application_security/api_posture/sensitive_data.md @@ -5,11 +5,11 @@ description: Detect and classify sensitive data processed by your API endpoints. {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} -[App and API Protection][1] matches known patterns for sensitive data in API requests and responses. If it finds a match, the endpoint is tagged with the category and type of sensitive data processed and displayed in [API Endpoints][2]. +[{{< prodname >}}App and API Protection{{< /prodname >}}][1] matches known patterns for sensitive data in API requests and responses. If it finds a match, the endpoint is tagged with the category and type of sensitive data processed and displayed in [API Endpoints][2]. The matching occurs within your application, and none of the sensitive data is sent to Datadog. @@ -19,7 +19,7 @@ To see the supported data types (for example, `payment:card`), use the {{< ui >} ## Create API data scanners -By default, App and API Protection scans for PII, credentials, and payment types. Sensitive Data Detection provides API data scanners to define custom scanner data patterns beyond the defaults. These scanners improve visibility into the sensitive data of your API traffic. +By default, {{< prodname >}}App and API Protection{{< /prodname >}} scans for PII, credentials, and payment types. Sensitive Data Detection provides API data scanners to define custom scanner data patterns beyond the defaults. These scanners improve visibility into the sensitive data of your API traffic. In an API data scanner, you define a scanner category and type to classify API endpoints processing sensitive data (for example, `health_info:patient_id`). Next, you define the JSON key or value conditions that trigger the scanner. @@ -32,7 +32,7 @@ To create an API data scanner and view its results, do the following: 3. In {{< ui >}}Select your scanner tags{{< /ui >}}, define the category and type to classify the sensitive data. The scanner tags API endpoints with the format `category:type`. 4. In {{< ui >}}Define conditions on JSON keys and values{{< /ui >}}, define the JSON key or value conditions to trigger the scanner. 5. Click {{< ui >}}Save Scanner{{< /ui >}}. The scanner is enabled by default. -6. To view the results of the scanner, go to App and API Protection [API Endpoints][4]. +6. To view the results of the scanner, go to {{< prodname >}}App and API Protection{{< /prodname >}} [API Endpoints][4]. 7. In the {{< ui >}}Schema Sensitive Data{{< /ui >}} facet, the category and type of your custom scanner is listed in the format `category:type`. Custom scanner `category:type` tags are also visible in the {{< ui >}}Sensitive Data{{< /ui >}} column of the explorer. [1]: /security/application_security/ diff --git a/hugo/content/en/security/application_security/attack_summary.md b/hugo/content/en/security/application_security/attack_summary.md index cf5df8aa5eb..26fb50a2ee4 100644 --- a/hugo/content/en/security/application_security/attack_summary.md +++ b/hugo/content/en/security/application_security/attack_summary.md @@ -15,7 +15,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} diff --git a/hugo/content/en/security/application_security/guide/_index.md b/hugo/content/en/security/application_security/guide/_index.md index f7739e4f83a..fe1f3f429af 100644 --- a/hugo/content/en/security/application_security/guide/_index.md +++ b/hugo/content/en/security/application_security/guide/_index.md @@ -6,12 +6,12 @@ disable_toc: true {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} {{< whatsnext desc="Getting Started" >}} - {{< nextlink href="/getting_started/security/application_security/" >}}First steps with App and API Protection{{< /nextlink >}} + {{< nextlink href="/getting_started/security/application_security/" >}}First steps with {{< prodname >}}App and API Protection{{< /prodname >}}{{< /nextlink >}} {{< /whatsnext >}} {{< whatsnext desc="Advanced Topics" >}} diff --git a/hugo/content/en/security/application_security/guide/manage_account_theft_appsec.md b/hugo/content/en/security/application_security/guide/manage_account_theft_appsec.md index 0802547104e..d609e5c7c47 100644 --- a/hugo/content/en/security/application_security/guide/manage_account_theft_appsec.md +++ b/hugo/content/en/security/application_security/guide/manage_account_theft_appsec.md @@ -5,7 +5,7 @@ disable_toc: false {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -56,7 +56,7 @@ This step describes how to set up your service to use AAP. To enable AAP on your login service, ensure you meet the following requirements: -* Similarly to Datadog APM, AAP requires a library integration in your services and a running Datadog Agent. +* Similarly to {{< prodname >}}Datadog APM{{< /prodname >}}, AAP requires a library integration in your services and a running Datadog Agent. * AAP generally benefits from using the newest library possible; however, minimum supported versions are documented in [Compatibility Requirements][3]. * At a minimum, {{< ui >}}Threat Detection{{< /ui >}} must be enabled. Ideally, {{< ui >}}Automatic user activity event tracking{{< /ui >}} should be enabled as well. @@ -171,7 +171,7 @@ The actions covered in the next sections help you to identify and leverage detec 1. Open [Create a new rule][18]. 2. Enter a name for the rule. -3. Select {{< ui >}}Signal{{< /ui >}} and remove all entries except {{< ui >}}App and API Protection{{< /ui >}}. +3. Select {{< ui >}}Signal{{< /ui >}} and remove all entries except {{< ui >}}{{< prodname >}}App and API Protection{{< /prodname >}}{{< /ui >}}. 4. Restrict the rule to `category:account_takeover`, and expand the severities to include `Medium`. 5. Add notification recipients (Slack, Teams, PagerDuty). To learn more, see [Notification channels][19]. @@ -589,7 +589,7 @@ You can configure a signal to push any user ID using a webhook. This method can
To configure a signal to push a user ID using a webhook, do the following: -1. Configuring a [standard webhook target][28]. To see how this works in Cloud SIEM, go to [Automate the Remediation of Detected Threats with Webhooks][29]. +1. Configuring a [standard webhook target][28]. To see how this works in {{< prodname >}}Cloud SIEM{{< /prodname >}}, go to [Automate the Remediation of Detected Threats with Webhooks][29]. 2. In [Detection Rules][30], open the rules you want to configure. {{Tables of ATO-related detection rules}} 3. Go to the notification settings in a detection rule condition. diff --git a/hugo/content/en/security/application_security/guide/standalone_application_security.md b/hugo/content/en/security/application_security/guide/standalone_application_security.md index 1539b9b903c..7a8a247bd83 100644 --- a/hugo/content/en/security/application_security/guide/standalone_application_security.md +++ b/hugo/content/en/security/application_security/guide/standalone_application_security.md @@ -5,13 +5,13 @@ disable_toc: false {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} -Datadog App and API Protection (AAP) is built on top of [APM][3] and runs alongside [Infrastructure Monitoring][7] by default. While Datadog recommends using AAP together with APM and Infrastructure Monitoring to adopt DevSecOps practices, you can also run AAP on its own. This configuration is referred to as Standalone App and API Protection. +Datadog App and API Protection (AAP) is built on top of [APM][3] and runs alongside [{{< prodname >}}Infrastructure Monitoring{{< /prodname >}}][7] by default. While Datadog recommends using AAP together with APM and {{< prodname >}}Infrastructure Monitoring{{< /prodname >}} to adopt DevSecOps practices, you can also run AAP on its own. This configuration is referred to as Standalone App and API Protection. -Running standalone allows to be billed primarily for App and API Protection. Some APM intake is still present to support AAP features (for example, security traces), and is expected to appear on your bill. +Running standalone allows to be billed primarily for {{< prodname >}}App and API Protection{{< /prodname >}}. Some APM intake is still present to support AAP features (for example, security traces), and is expected to appear on your bill. This guide explains how to disable APM tracing and infrastructure monitoring. @@ -20,7 +20,7 @@ This guide explains how to disable APM tracing and infrastructure monitoring. This guide assumes you have the following: - **Datadog Agent:** [Install the Datadog Agent][6] and configure it for your application's operating system, container, cloud, or virtual environment. Disabling Infrastructure Monitoring requires Datadog Agent version 7.77.0 or newer. -- **Supported SDK:** The Datadog SDK used by your application or service supports App and API Protection. For more details, see the guide for [App and API Protection][4]. +- **Supported SDK:** The Datadog SDK used by your application or service supports {{< prodname >}}App and API Protection{{< /prodname >}}. For more details, see the guide for [{{< prodname >}}App and API Protection{{< /prodname >}}][4]. ## Compatibility @@ -38,13 +38,13 @@ Standalone App and API Protection is supported for the following SDK versions: ## Setup -Standalone App and API Protection requires two pieces of configuration: disabling Infrastructure Monitoring on the Datadog Agent, and disabling APM tracing on the SDK while enabling AAP. +Standalone App and API Protection requires two pieces of configuration: disabling {{< prodname >}}Infrastructure Monitoring{{< /prodname >}} on the Datadog Agent, and disabling APM tracing on the SDK while enabling AAP. ### Disable Infrastructure Monitoring on the Datadog Agent Standalone App and API Protection uses the same Datadog Agent installation as APM. For installation steps, see [Install the Datadog Agent][6]. -To disable Infrastructure Monitoring, set the Datadog Agent infrastructure mode to `none` (requires Datadog Agent 7.77.0 or newer) using either: +To disable {{< prodname >}}Infrastructure Monitoring{{< /prodname >}}, set the Datadog Agent infrastructure mode to `none` (requires Datadog Agent 7.77.0 or newer) using either: - The `DD_INFRASTRUCTURE_MODE=none` environment variable - The `infrastructure_mode: none` setting in the `datadog.yaml` configuration file @@ -58,7 +58,7 @@ On the instrumented service, set the following environment variables: - `DD_APM_TRACING_ENABLED=false` - `DD_APPSEC_ENABLED=true` -`DD_APM_TRACING_ENABLED=false` disabled APM tracing and limits the amount of APM data sent to the minimum required by App and API Protection. This environment variable can be combined with other [App and API Protection configuration options][4]. +`DD_APM_TRACING_ENABLED=false` disabled APM tracing and limits the amount of APM data sent to the minimum required by {{< prodname >}}App and API Protection{{< /prodname >}}. This environment variable can be combined with other [App and API Protection configuration options][4]. [1]: /security/workload_protection/ diff --git a/hugo/content/en/security/application_security/how-it-works/_index.md b/hugo/content/en/security/application_security/how-it-works/_index.md index 061a9ef4d89..1e852b3d23b 100644 --- a/hugo/content/en/security/application_security/how-it-works/_index.md +++ b/hugo/content/en/security/application_security/how-it-works/_index.md @@ -9,7 +9,7 @@ aliases: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -28,18 +28,18 @@ Datadog App and API Protection (AAP) provides observability into application and ### Identify services exposed to application attacks -Datadog App and API Protection Threat Management uses the information APM is already collecting to flag traces containing attack attempts. While APM collects a sample of your application traffic, enabling App and API Protection in the SDK is necessary to effectively monitor and protect your services. +Datadog App and API Protection Threat Management uses the information APM is already collecting to flag traces containing attack attempts. While APM collects a sample of your application traffic, enabling {{< prodname >}}App and API Protection{{< /prodname >}} in the SDK is necessary to effectively monitor and protect your services. Services exposed to application attacks are highlighted directly in the security views embedded in APM ([Catalog][2], [Service Page][3], [Traces][4]). Datadog Threat Monitoring and Detection identifies bad actors by collecting client IP addresses, login account info (for example, user account/ID), and manually-added user tags on all requests.
1-Click Enablement
-If your service is running with an Agent with Remote Configuration enabled and an SDK version that supports it, you can enable App and API Protection from the Datadog UI without additional configuration of the Agent or SDKs.
+If your service is running with an Agent with Remote Configuration enabled and an SDK version that supports it, you can enable {{< prodname >}}App and API Protection{{< /prodname >}} from the Datadog UI without additional configuration of the Agent or SDKs. ## Compatibility -App and API Protection uses the same libraries as APM, so you don't need to deploy and maintain another library. Steps to enable Datadog App and API Protection are specific to each runtime language. See the [App and API Protection setup guides][6] to check if your language is supported. +{{< prodname >}}App and API Protection{{< /prodname >}} uses the same libraries as APM, so you don't need to deploy and maintain another library. Steps to enable Datadog App and API Protection are specific to each runtime language. See the [App and API Protection setup guides][6] to check if your language is supported. ## Serverless monitoring @@ -63,7 +63,7 @@ Data for security traces is kept for 90 days. The underlying trace data is kept ## Data privacy -By default, App and API Protection collects information from security traces to help you understand why the request was flagged as suspicious. Before sending the data, App and API Protection scans it for patterns and keywords that indicate that the data is sensitive. If the data is deemed sensitive, it is replaced with a `` flag. This indicates that the request was suspicious, but that the request data could not be collected because of data security concerns. +By default, {{< prodname >}}App and API Protection{{< /prodname >}} collects information from security traces to help you understand why the request was flagged as suspicious. Before sending the data, {{< prodname >}}App and API Protection{{< /prodname >}} scans it for patterns and keywords that indicate that the data is sensitive. If the data is deemed sensitive, it is replaced with a `` flag. This indicates that the request was suspicious, but that the request data could not be collected because of data security concerns. Here are some examples of data that is flagged as sensitive by default: * `pwd`, `password`, `ipassword`, `pass_phrase` @@ -77,7 +77,7 @@ Here are some examples of data that is flagged as sensitive by default: * `BEGIN PRIVATE KEY` * `ssh-rsa` -To configure the information redacted by App and API Protection, refer to the [data security configuration][17] +To configure the information redacted by {{< prodname >}}App and API Protection{{< /prodname >}}, refer to the [data security configuration][17] ## Threat detection methods @@ -117,7 +117,7 @@ Datadog App and API Protection includes over 100 attack signatures that help pro
API security is in Preview.
-Datadog App and API Protection provides visibility into threats targeting your APIs. Use the [Endpoints list][27] in Catalog to monitor API health and performance metrics, where you can view attacks targeting your APIs. This view includes the attacker's IP and authentication information, as well as request headers showing details about how the attack was formed. Using both App and API Protection and API management, you can maintain a comprehensive view of your API attack surface, and respond to mitigate threats. +Datadog App and API Protection provides visibility into threats targeting your APIs. Use the [Endpoints list][27] in Catalog to monitor API health and performance metrics, where you can view attacks targeting your APIs. This view includes the attacker's IP and authentication information, as well as request headers showing details about how the attack was formed. Using both {{< prodname >}}App and API Protection{{< /prodname >}} and API management, you can maintain a comprehensive view of your API attack surface, and respond to mitigate threats. ## How Datadog App and API Protection protects against Log4Shell diff --git a/hugo/content/en/security/application_security/how-it-works/add-user-info.md b/hugo/content/en/security/application_security/how-it-works/add-user-info.md index cfda937c213..f891a60bc65 100644 --- a/hugo/content/en/security/application_security/how-it-works/add-user-info.md +++ b/hugo/content/en/security/application_security/how-it-works/add-user-info.md @@ -12,7 +12,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} diff --git a/hugo/content/en/security/application_security/how-it-works/threat-intelligence.md b/hugo/content/en/security/application_security/how-it-works/threat-intelligence.md index 1c53cd10491..3aab4ef3d78 100644 --- a/hugo/content/en/security/application_security/how-it-works/threat-intelligence.md +++ b/hugo/content/en/security/application_security/how-it-works/threat-intelligence.md @@ -12,13 +12,13 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} ## Overview -This topic describes [threat intelligence][1] for App and API Protection (AAP). +This topic describes [threat intelligence][1] for {{< prodname >}}App and API Protection{{< /prodname >}} (AAP). Datadog provides built-in threat intelligence [datasets][1] for AAP. This provides additional evidence when acting on security activity and reduces detection thresholds for some business logic detections. diff --git a/hugo/content/en/security/application_security/how-it-works/trace_qualification.md b/hugo/content/en/security/application_security/how-it-works/trace_qualification.md index 4ed129c86e8..88b56301990 100644 --- a/hugo/content/en/security/application_security/how-it-works/trace_qualification.md +++ b/hugo/content/en/security/application_security/how-it-works/trace_qualification.md @@ -6,13 +6,13 @@ aliases: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} ## Overview -App and API Protection (AAP) provides observability into application-level attacks, and evaluates the conditions in which each trace was generated. AAP trace qualification then labels each attack as harmful or safe to help you take action on the most impactful attacks. +{{< prodname >}}App and API Protection{{< /prodname >}} (AAP) provides observability into application-level attacks, and evaluates the conditions in which each trace was generated. AAP trace qualification then labels each attack as harmful or safe to help you take action on the most impactful attacks. Filter by the **Qualification** facet in the AAP [Traces Explorer][1] to view the possible qualification results: diff --git a/hugo/content/en/security/application_security/setup/_index.md b/hugo/content/en/security/application_security/setup/_index.md index 6e8ad1e2382..dd6072d7c96 100644 --- a/hugo/content/en/security/application_security/setup/_index.md +++ b/hugo/content/en/security/application_security/setup/_index.md @@ -13,11 +13,11 @@ disable_sidebar: true {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} -Learn how to enable App and API Protection on all the following supported platforms and environments. +Learn how to enable {{< prodname >}}App and API Protection{{< /prodname >}} on all the following supported platforms and environments.

Are you missing your environment?

diff --git a/hugo/content/en/security/application_security/setup/aws/fargate/_index.md b/hugo/content/en/security/application_security/setup/aws/fargate/_index.md index 877fd58542e..faa57d2e592 100644 --- a/hugo/content/en/security/application_security/setup/aws/fargate/_index.md +++ b/hugo/content/en/security/application_security/setup/aws/fargate/_index.md @@ -21,11 +21,11 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} -Learn how to set up App and API Protection (AAP) on your AWS Fargate tasks by selecting your task's programming language. +Learn how to set up {{< prodname >}}App and API Protection{{< /prodname >}} (AAP) on your AWS Fargate tasks by selecting your task's programming language.

Are you missing your environment?

diff --git a/hugo/content/en/security/application_security/setup/aws/lambda/_index.md b/hugo/content/en/security/application_security/setup/aws/lambda/_index.md index 3583622524b..5f11e54e5bc 100644 --- a/hugo/content/en/security/application_security/setup/aws/lambda/_index.md +++ b/hugo/content/en/security/application_security/setup/aws/lambda/_index.md @@ -24,11 +24,11 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} -Learn how to setup App and API Protection on your AWS Lambda functions by selecting the programming language your function is written with. +Learn how to setup {{< prodname >}}App and API Protection{{< /prodname >}} on your AWS Lambda functions by selecting the programming language your function is written with.

Are you missing your environment?

diff --git a/hugo/content/en/security/application_security/setup/aws/lambda/dotnet.md b/hugo/content/en/security/application_security/setup/aws/lambda/dotnet.md index eec7d383bb2..f8b8c8328a8 100644 --- a/hugo/content/en/security/application_security/setup/aws/lambda/dotnet.md +++ b/hugo/content/en/security/application_security/setup/aws/lambda/dotnet.md @@ -20,14 +20,14 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} Configuring App and API Protection for AWS Lambda involves: -1. Identifying functions that are vulnerable or are under attack and would most benefit from App and API Protection. Find them on [the Security tab of your Catalog][1]. -2. Setting up App and API Protection instrumentation by using either the [Datadog CLI][8], [AWS CDK][9], [Datadog Serverless Framework plugin][2], or manually by using the Datadog tracing layers. +1. Identifying functions that are vulnerable or are under attack and would most benefit from {{< prodname >}}App and API Protection{{< /prodname >}}. Find them on [the Security tab of your Catalog][1]. +2. Setting up {{< prodname >}}App and API Protection{{< /prodname >}} instrumentation by using either the [Datadog CLI][8], [AWS CDK][9], [Datadog Serverless Framework plugin][2], or manually by using the Datadog tracing layers. 3. Triggering security signals in your application and seeing how Datadog displays the resulting information. ## Supported trigger types @@ -45,7 +45,7 @@ Threat Detection supports HTTP requests as function input only, as that channel {{< tabs >}} {{% tab "Serverless Framework" %}} -The [Datadog Serverless Framework plugin][1] can be used to automatically configure and deploy your Lambda functions with App and API Protection. +The [Datadog Serverless Framework plugin][1] can be used to automatically configure and deploy your Lambda functions with {{< prodname >}}App and API Protection{{< /prodname >}}. To install and configure the Datadog Serverless Framework plugin: diff --git a/hugo/content/en/security/application_security/setup/aws/lambda/go.md b/hugo/content/en/security/application_security/setup/aws/lambda/go.md index 6fbd894f946..c9d7b1673cb 100644 --- a/hugo/content/en/security/application_security/setup/aws/lambda/go.md +++ b/hugo/content/en/security/application_security/setup/aws/lambda/go.md @@ -20,14 +20,14 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} Configuring App and API Protection for AWS Lambda involves: -1. Identifying functions that are vulnerable or are under attack, which would most benefit from App and API Protection. Find them on [the Security tab of your Catalog][1]. -2. Setting up App and API Protection instrumentation by using either the [Datadog CLI][8], [AWS CDK][9], [Datadog Serverless Framework plugin][2], or manually by using the Datadog tracing layers. +1. Identifying functions that are vulnerable or are under attack, which would most benefit from {{< prodname >}}App and API Protection{{< /prodname >}}. Find them on [the Security tab of your Catalog][1]. +2. Setting up {{< prodname >}}App and API Protection{{< /prodname >}} instrumentation by using either the [Datadog CLI][8], [AWS CDK][9], [Datadog Serverless Framework plugin][2], or manually by using the Datadog tracing layers. 3. Triggering security signals in your application and seeing how Datadog displays the resulting information. ## Supported trigger types @@ -45,7 +45,7 @@ Threat Detection supports HTTP requests as function input only, as that channel {{< tabs >}} {{% tab "Serverless Framework" %}} -The [Datadog Serverless Framework plugin][1] can be used to automatically configure and deploy your lambda with App and API Protection. +The [Datadog Serverless Framework plugin][1] can be used to automatically configure and deploy your lambda with {{< prodname >}}App and API Protection{{< /prodname >}}. To install and configure the Datadog Serverless Framework plugin: @@ -133,7 +133,7 @@ The Datadog CLI modifies existing Lambda function configurations to enable instr - Alternatively, you can use `--functions-regex` to automatically instrument multiple functions whose names match the given regular expression. - Replace `` with the AWS region name. - **Note**: Instrument your Lambda functions in a development or staging environment first. If the instrumentation result is unsatisfactory, run `uninstrument` with the same arguments to revert the changes. After the CLI completes, update your source code to depend on the latest `datadog-lambda-go` module release to enable App and API Protection. + **Note**: Instrument your Lambda functions in a development or staging environment first. If the instrumentation result is unsatisfactory, run `uninstrument` with the same arguments to revert the changes. After the CLI completes, update your source code to depend on the latest `datadog-lambda-go` module release to enable {{< prodname >}}App and API Protection{{< /prodname >}}. Additional parameters can be found in the [CLI documentation][2]. diff --git a/hugo/content/en/security/application_security/setup/aws/lambda/java.md b/hugo/content/en/security/application_security/setup/aws/lambda/java.md index 40ba621679e..442b01e6595 100644 --- a/hugo/content/en/security/application_security/setup/aws/lambda/java.md +++ b/hugo/content/en/security/application_security/setup/aws/lambda/java.md @@ -20,14 +20,14 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} Configuring App and API Protection for AWS Lambda involves: -1. Identifying functions that are vulnerable or are under attack, which would most benefit from App and API Protection. Find them on [the Security tab of your Catalog][1]. -2. Setting up App and API Protection instrumentation by using either the [Datadog CLI][9], [AWS CDK][10], [Datadog Serverless Framework plugin][2], or manually by using the Datadog tracing layers. +1. Identifying functions that are vulnerable or are under attack, which would most benefit from {{< prodname >}}App and API Protection{{< /prodname >}}. Find them on [the Security tab of your Catalog][1]. +2. Setting up {{< prodname >}}App and API Protection{{< /prodname >}} instrumentation by using either the [Datadog CLI][9], [AWS CDK][10], [Datadog Serverless Framework plugin][2], or manually by using the Datadog tracing layers. 3. Triggering security signals in your application and seeing how Datadog displays the resulting information. ## Supported trigger types @@ -45,7 +45,7 @@ Threat Detection supports HTTP requests as function input only, as that channel {{< tabs >}} {{% tab "Serverless Framework" %}} -The [Datadog Serverless Framework plugin][1] can be used to automatically configure and deploy your Lambda with App and API Protection. +The [Datadog Serverless Framework plugin][1] can be used to automatically configure and deploy your Lambda with {{< prodname >}}App and API Protection{{< /prodname >}}. To install and configure the Datadog Serverless Framework plugin: diff --git a/hugo/content/en/security/application_security/setup/aws/lambda/nodejs.md b/hugo/content/en/security/application_security/setup/aws/lambda/nodejs.md index 083aa3f2449..a0649a72016 100644 --- a/hugo/content/en/security/application_security/setup/aws/lambda/nodejs.md +++ b/hugo/content/en/security/application_security/setup/aws/lambda/nodejs.md @@ -20,14 +20,14 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} Configuring App and API Protection for AWS Lambda involves: -1. Identifying functions that are vulnerable or are under attack, which would most benefit from App and API Protection. Find them on [the Security tab of your Catalog][1]. -2. Setting up App and API Protection instrumentation by using either the [Datadog CLI][9], [AWS CDK][10], [Datadog Serverless Framework plugin][2], or manually by using the Datadog tracing layers. +1. Identifying functions that are vulnerable or are under attack, which would most benefit from {{< prodname >}}App and API Protection{{< /prodname >}}. Find them on [the Security tab of your Catalog][1]. +2. Setting up {{< prodname >}}App and API Protection{{< /prodname >}} instrumentation by using either the [Datadog CLI][9], [AWS CDK][10], [Datadog Serverless Framework plugin][2], or manually by using the Datadog tracing layers. 3. Triggering security signals in your application and seeing how Datadog displays the resulting information. ## Supported trigger types diff --git a/hugo/content/en/security/application_security/setup/aws/lambda/python.md b/hugo/content/en/security/application_security/setup/aws/lambda/python.md index 556ae7c6254..d66e9f18732 100644 --- a/hugo/content/en/security/application_security/setup/aws/lambda/python.md +++ b/hugo/content/en/security/application_security/setup/aws/lambda/python.md @@ -23,14 +23,14 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} Configuring App and API Protection for AWS Lambda involves: -1. Identifying functions that are vulnerable or are under attack, which would most benefit from App and API Protection. Find them on [the Security tab of your Catalog][1]. -2. Setting up App and API Protection instrumentation by using either the [Datadog CLI][2], [AWS CDK][3], [Datadog Serverless Framework plugin][4], or manually by using the Datadog tracing layers. +1. Identifying functions that are vulnerable or are under attack, which would most benefit from {{< prodname >}}App and API Protection{{< /prodname >}}. Find them on [the Security tab of your Catalog][1]. +2. Setting up {{< prodname >}}App and API Protection{{< /prodname >}} instrumentation by using either the [Datadog CLI][2], [AWS CDK][3], [Datadog Serverless Framework plugin][4], or manually by using the Datadog tracing layers. 3. Triggering security signals in your application and seeing how Datadog displays the resulting information. ## Supported trigger types @@ -48,7 +48,7 @@ Threat Detection supports HTTP requests as function input only, as that channel {{< tabs >}} {{% tab "Serverless Framework" %}} -The [Datadog Serverless Framework plugin][1] can be used to automatically configure and deploy your Lambda with App and API Protection. +The [Datadog Serverless Framework plugin][1] can be used to automatically configure and deploy your Lambda with {{< prodname >}}App and API Protection{{< /prodname >}}. To install and configure the Datadog Serverless Framework plugin: diff --git a/hugo/content/en/security/application_security/setup/aws/lambda/ruby.md b/hugo/content/en/security/application_security/setup/aws/lambda/ruby.md index fd4af1160bb..2900134864b 100644 --- a/hugo/content/en/security/application_security/setup/aws/lambda/ruby.md +++ b/hugo/content/en/security/application_security/setup/aws/lambda/ruby.md @@ -20,14 +20,14 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} Configuring App and API Protection for AWS Lambda involves: -1. Identifying functions that are vulnerable or are under attack, which would most benefit from App and API Protection. Find them on [the Security tab of your Catalog][1]. -2. Setting up App and API Protection instrumentation by using either the [Datadog CLI][8], [AWS CDK][9], [Datadog Serverless Framework plugin][2], or manually by using the Datadog tracing layers. +1. Identifying functions that are vulnerable or are under attack, which would most benefit from {{< prodname >}}App and API Protection{{< /prodname >}}. Find them on [the Security tab of your Catalog][1]. +2. Setting up {{< prodname >}}App and API Protection{{< /prodname >}} instrumentation by using either the [Datadog CLI][8], [AWS CDK][9], [Datadog Serverless Framework plugin][2], or manually by using the Datadog tracing layers. 3. Triggering security signals in your application and seeing how Datadog displays the resulting information. ## Supported trigger types @@ -44,7 +44,7 @@ Threat Detection supports HTTP requests as function input only, as that channel {{< tabs >}} {{% tab "Serverless Framework" %}} -The [Datadog Serverless Framework plugin][1] can be used to automatically configure and deploy your Lambda with App and API Protection. +The [Datadog Serverless Framework plugin][1] can be used to automatically configure and deploy your Lambda with {{< prodname >}}App and API Protection{{< /prodname >}}. To install and configure the Datadog Serverless Framework plugin: @@ -209,7 +209,7 @@ The [Datadog CDK Construct][1] automatically installs Datadog on your functions gem 'datadog-lambda' ``` - `datadog` contains native extensions that must be compiled for Amazon Linux to work with AWS Lambda. Datadog therefore recommends that you build and deploy your Lambda as a container image. If your function cannot be deployed as a container image and you would like to use Datadog APM, Datadog recommends installing the Lambda Library as a layer instead of as a gem. + `datadog` contains native extensions that must be compiled for Amazon Linux to work with AWS Lambda. Datadog therefore recommends that you build and deploy your Lambda as a container image. If your function cannot be deployed as a container image and you would like to use {{< prodname >}}Datadog APM{{< /prodname >}}, Datadog recommends installing the Lambda Library as a layer instead of as a gem. Install `gcc`, `gmp-devel`, and `make` prior to running `bundle install` in your function's Dockerfile to ensure that the native extensions can be successfully compiled. diff --git a/hugo/content/en/security/application_security/setup/aws/waf/_index.md b/hugo/content/en/security/application_security/setup/aws/waf/_index.md index 3566c6ed75f..7b2b0b09142 100644 --- a/hugo/content/en/security/application_security/setup/aws/waf/_index.md +++ b/hugo/content/en/security/application_security/setup/aws/waf/_index.md @@ -20,11 +20,11 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} -App and API Protection integrates with AWS Web Application Firewall (WAF) by: +{{< prodname >}}App and API Protection{{< /prodname >}} integrates with AWS Web Application Firewall (WAF) by: 1. Converting logs to traces to gain visibility into monitored and blocked requests 2. Blocking IP addresses with AWS WAF IPsets diff --git a/hugo/content/en/security/application_security/setup/azure/app-service/_index.md b/hugo/content/en/security/application_security/setup/azure/app-service/_index.md index 888b6b09286..424f2005246 100644 --- a/hugo/content/en/security/application_security/setup/azure/app-service/_index.md +++ b/hugo/content/en/security/application_security/setup/azure/app-service/_index.md @@ -23,7 +23,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -53,7 +53,7 @@ To enable AAP on your application, begin by adding the following key-value pairs - `DD_SITE` is the Datadog site [parameter][2]. Your site is {{< region-param key="dd_site" code="true" >}}. This value defaults to `datadoghq.com`. - `DD_SERVICE` is the service name used for this program. Defaults to the name field value in `package.json`. - `DD_START_APP` is the command used to start your application. For example, `node ./bin/www` (unnecessary for applications running in Tomcat). -- `DD_APPSEC_ENABLED` value should be 1 in order to enable App and API Protection +- `DD_APPSEC_ENABLED` value should be 1 in order to enable {{< prodname >}}App and API Protection{{< /prodname >}} ### Identifying your startup command @@ -102,7 +102,7 @@ Download the [`datadog_wrapper`][8] file from the releases and upload it to your ## Testing threat detection -To see App and API Protection threat detection in action, send known attack patterns to your application. For example, send a request with the user agent header set to `dd-test-scanner-log` to trigger a [security scanner attack][5] attempt: +To see {{< prodname >}}App and API Protection{{< /prodname >}} threat detection in action, send known attack patterns to your application. For example, send a request with the user agent header set to `dd-test-scanner-log` to trigger a [security scanner attack][5] attempt: ```sh curl -A 'dd-test-scanner-log' https://your-function-url/existing-route ``` diff --git a/hugo/content/en/security/application_security/setup/compatibility/envoy-gateway.md b/hugo/content/en/security/application_security/setup/compatibility/envoy-gateway.md index 1ccead42996..8cc43aa9523 100644 --- a/hugo/content/en/security/application_security/setup/compatibility/envoy-gateway.md +++ b/hugo/content/en/security/application_security/setup/compatibility/envoy-gateway.md @@ -7,11 +7,11 @@ code_lang_weight: 40 {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} -The following table lists App and API Protection capabilities for the Envoy Gateway integration according to the specified Datadog External Processor image version: +The following table lists {{< prodname >}}App and API Protection{{< /prodname >}} capabilities for the Envoy Gateway integration according to the specified Datadog External Processor image version: | App and API Protection capability | Minimum Datadog External Processor image version | |------------------------------------------------|---------------------------------------------------| @@ -40,7 +40,7 @@ Envoy Gateway relies on Envoy Proxy and the Gateway API, and runs within a Kuber ### Envoy version support -The Datadog Envoy integration for App and API Protection relies on features that might not be present in every Envoy version. The following table shows which Envoy versions support each feature. +The Datadog Envoy integration for {{< prodname >}}App and API Protection{{< /prodname >}} relies on features that might not be present in every Envoy version. The following table shows which Envoy versions support each feature. | Feature | Minimum Envoy version | |---------|-----------------------| @@ -49,7 +49,7 @@ The Datadog Envoy integration for App and API Protection relies on features that ## Datadog Envoy Gateway integration support -
The Datadog Envoy Gateway integration for App and API Protection is in Preview.
+
The Datadog Envoy Gateway integration for {{< prodname >}}App and API Protection{{< /prodname >}} is in Preview.
Only the Linux version and both the amd64 and arm64 architectures are supported. diff --git a/hugo/content/en/security/application_security/setup/compatibility/envoy.md b/hugo/content/en/security/application_security/setup/compatibility/envoy.md index efbc3dbbd24..9d33ec07104 100644 --- a/hugo/content/en/security/application_security/setup/compatibility/envoy.md +++ b/hugo/content/en/security/application_security/setup/compatibility/envoy.md @@ -9,11 +9,11 @@ aliases: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} -The following table lists App and API Protection capabilities for the Envoy integration according to the specified Datadog External Processor image version: +The following table lists {{< prodname >}}App and API Protection{{< /prodname >}} capabilities for the Envoy integration according to the specified Datadog External Processor image version: | App and API Protection capability | Minimum Datadog External Processor image version | |------------------------------------------------|---------------------------------------------------| @@ -35,7 +35,7 @@ The Datadog External Processor service supports the processing of request and re ## Envoy version support -The Datadog Envoy integration for App and API Protection relies on features that might not be present in every Envoy version. The following table shows which Envoy versions support each feature. +The Datadog Envoy integration for {{< prodname >}}App and API Protection{{< /prodname >}} relies on features that might not be present in every Envoy version. The following table shows which Envoy versions support each feature. | Feature | Minimum Envoy version | |---------|-----------------------| @@ -44,7 +44,7 @@ The Datadog Envoy integration for App and API Protection relies on features that ## Datadog Envoy integration support -
The Datadog Envoy integration for App and API Protection is in Preview.
+
The Datadog Envoy integration for {{< prodname >}}App and API Protection{{< /prodname >}} is in Preview.
Only the Linux version and both the arm64 and arm64 architectures are supported. diff --git a/hugo/content/en/security/application_security/setup/compatibility/gcp-service-extensions.md b/hugo/content/en/security/application_security/setup/compatibility/gcp-service-extensions.md index 1064c63bec0..b7461f7834b 100644 --- a/hugo/content/en/security/application_security/setup/compatibility/gcp-service-extensions.md +++ b/hugo/content/en/security/application_security/setup/compatibility/gcp-service-extensions.md @@ -9,11 +9,11 @@ aliases: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} -The following table lists App and API Protection capabilities for GCP Service Extensions according to the specified Datadog Service Extensions callout image version: +The following table lists {{< prodname >}}App and API Protection{{< /prodname >}} capabilities for GCP Service Extensions according to the specified Datadog Service Extensions callout image version: | App and API Protection capability | Minimum App and API Protection Service Extensions callout image version | |------------------------------------------|--------------------------------------------------------------------------| diff --git a/hugo/content/en/security/application_security/setup/compatibility/haproxy.md b/hugo/content/en/security/application_security/setup/compatibility/haproxy.md index 58048ffc27b..4b5e38a97d4 100644 --- a/hugo/content/en/security/application_security/setup/compatibility/haproxy.md +++ b/hugo/content/en/security/application_security/setup/compatibility/haproxy.md @@ -7,11 +7,11 @@ code_lang_weight: 40 {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} -The following table lists App and API Protection capabilities for the HAProxy integration according to the specified Datadog HAProxy SPOA image version: +The following table lists {{< prodname >}}App and API Protection{{< /prodname >}} capabilities for the HAProxy integration according to the specified Datadog HAProxy SPOA image version: | App and API Protection capability | Minimum Datadog HAProxy SPOA image version | |------------------------------------------------|--------------------------------------------| @@ -33,7 +33,7 @@ The Datadog HAProxy SPOA supports the processing of request and response bodies ## HAProxy version support -The Datadog HAProxy integration for App and API Protection relies on features that might not be present in every HAProxy version. The following table shows which HAProxy versions support each feature. +The Datadog HAProxy integration for {{< prodname >}}App and API Protection{{< /prodname >}} relies on features that might not be present in every HAProxy version. The following table shows which HAProxy versions support each feature. | Feature | Minimum HAProxy version | |---------|-----------------------| @@ -43,7 +43,7 @@ The Datadog HAProxy integration for App and API Protection relies on features th All currently supported (non-EOL) HAProxy versions are compatible and supported with the Datadog App and API Protection integration. -
The Datadog HAProxy integration for App and API Protection is in Preview.
+
The Datadog HAProxy integration for {{< prodname >}}App and API Protection{{< /prodname >}} is in Preview.
Please refer to the [limitations][1] of the Datadog App and API Protection HAProxy integration. diff --git a/hugo/content/en/security/application_security/setup/compatibility/istio.md b/hugo/content/en/security/application_security/setup/compatibility/istio.md index 31a9eb46c3a..22733bd6e2c 100644 --- a/hugo/content/en/security/application_security/setup/compatibility/istio.md +++ b/hugo/content/en/security/application_security/setup/compatibility/istio.md @@ -7,11 +7,11 @@ code_lang_weight: 40 {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} -The following table lists App and API Protection capabilities for the Istio integration according to the specified Datadog External Processor image version: +The following table lists {{< prodname >}}App and API Protection{{< /prodname >}} capabilities for the Istio integration according to the specified Datadog External Processor image version: | App and API Protection capability | Minimum Datadog External Processor image version | |------------------------------------------------|---------------------------------------------------| @@ -47,7 +47,7 @@ More information about relationship between Istio and Envoy versions can be foun ### Envoy version support -The Datadog Envoy integration for App and API Protection relies on features that might not be present in every Envoy version. The following table shows which Envoy versions support each feature. +The Datadog Envoy integration for {{< prodname >}}App and API Protection{{< /prodname >}} relies on features that might not be present in every Envoy version. The following table shows which Envoy versions support each feature. | Feature | Minimum Envoy version | |---------|-----------------------| @@ -56,7 +56,7 @@ The Datadog Envoy integration for App and API Protection relies on features that ## Datadog Istio integration support -
The Datadog Istio integration for App and API Protection is in Preview.
+
The Datadog Istio integration for {{< prodname >}}App and API Protection{{< /prodname >}} is in Preview.
Only the Linux version and both the arm64 and arm64 architectures are supported. diff --git a/hugo/content/en/security/application_security/setup/compatibility/nginx.md b/hugo/content/en/security/application_security/setup/compatibility/nginx.md index da590ca191c..c7c5bf3bf3b 100644 --- a/hugo/content/en/security/application_security/setup/compatibility/nginx.md +++ b/hugo/content/en/security/application_security/setup/compatibility/nginx.md @@ -9,13 +9,13 @@ aliases: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} ## App and API Protection capabilities support -The following App and API Protection capabilities are supported in the nginx integration, for the +The following {{< prodname >}}App and API Protection{{< /prodname >}} capabilities are supported in the nginx integration, for the specified tracer version: | App and API Protection capability | Minimum nginx module version | diff --git a/hugo/content/en/security/application_security/setup/compatibility/serverless.md b/hugo/content/en/security/application_security/setup/compatibility/serverless.md index 0d11933928e..8750bdc7bad 100644 --- a/hugo/content/en/security/application_security/setup/compatibility/serverless.md +++ b/hugo/content/en/security/application_security/setup/compatibility/serverless.md @@ -9,11 +9,11 @@ aliases: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} -App and API Protection provides serverless capability for the following platforms and libraries: +{{< prodname >}}App and API Protection{{< /prodname >}} provides serverless capability for the following platforms and libraries: {{< card-grid card_width="225px" image_width="200" >}} {{< image-card href="/security/application_security/serverless/#aws-lambda" src="integrations_logos/amazon_lambda.png" alt="AWS Lambda" >}} @@ -65,7 +65,7 @@ Go ## Google Cloud Run -
Google Cloud Run support for App and API Protection serverless is in Preview.
+
Google Cloud Run support for {{< prodname >}}App and API Protection{{< /prodname >}} serverless is in Preview.
**Note**: Threat Protection through Remote Configuration is not supported. Use [Workflows][5] to block IPs in your [WAF][6]. diff --git a/hugo/content/en/security/application_security/setup/docker/_index.md b/hugo/content/en/security/application_security/setup/docker/_index.md index 16494ee51b2..bcebea7edeb 100644 --- a/hugo/content/en/security/application_security/setup/docker/_index.md +++ b/hugo/content/en/security/application_security/setup/docker/_index.md @@ -21,11 +21,11 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} -Learn how to set up App and API Protection (AAP) on your Docker containers by selecting the containerized service's programming language. +Learn how to set up {{< prodname >}}App and API Protection{{< /prodname >}} (AAP) on your Docker containers by selecting the containerized service's programming language.

Are you missing your environment?

diff --git a/hugo/content/en/security/application_security/setup/dotnet/_index.md b/hugo/content/en/security/application_security/setup/dotnet/_index.md index 71b2a173c86..115457d79dc 100644 --- a/hugo/content/en/security/application_security/setup/dotnet/_index.md +++ b/hugo/content/en/security/application_security/setup/dotnet/_index.md @@ -28,7 +28,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} diff --git a/hugo/content/en/security/application_security/setup/dotnet/aws-fargate.md b/hugo/content/en/security/application_security/setup/dotnet/aws-fargate.md index 7d9ef73b68d..1ed59a1c722 100644 --- a/hugo/content/en/security/application_security/setup/dotnet/aws-fargate.md +++ b/hugo/content/en/security/application_security/setup/dotnet/aws-fargate.md @@ -17,7 +17,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -85,7 +85,7 @@ ENV CORECLR_ENABLE_PROFILING=1 \ {{% collapse-content title="APM Tracing Enabled" level="h4" %}} -Update your task definition to include the .NET agent and App and API Protection configuration: +Update your task definition to include the .NET agent and {{< prodname >}}App and API Protection{{< /prodname >}} configuration: ```json { @@ -115,9 +115,9 @@ Update your task definition to include the .NET agent and App and API Protection {{% /collapse-content %}} {{% collapse-content title="APM Tracing Disabled" level="h4" %}} -To disable APM tracing while keeping App and API Protection enabled, you must set the APM tracing variable to false. +To disable APM tracing while keeping {{< prodname >}}App and API Protection{{< /prodname >}} enabled, you must set the APM tracing variable to false. -Update your task definition to include the .NET agent and App and API Protection configuration with APM tracing disabled: +Update your task definition to include the .NET agent and {{< prodname >}}App and API Protection{{< /prodname >}} configuration with APM tracing disabled: ```json { @@ -163,7 +163,7 @@ aws ecs run-task --cluster your-cluster --task-definition your-task-definition ## Troubleshooting -If you encounter issues while setting up App and API Protection for your .net application, see the [.NET App and API Protection troubleshooting guide][2]. +If you encounter issues while setting up {{< prodname >}}App and API Protection{{< /prodname >}} for your .net application, see the [.NET App and API Protection troubleshooting guide][2]. ## Further Reading diff --git a/hugo/content/en/security/application_security/setup/dotnet/docker.md b/hugo/content/en/security/application_security/setup/dotnet/docker.md index 902c35469f8..5cf0d700121 100644 --- a/hugo/content/en/security/application_security/setup/dotnet/docker.md +++ b/hugo/content/en/security/application_security/setup/dotnet/docker.md @@ -17,7 +17,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -72,7 +72,7 @@ ENV DD_ENV= {{% collapse-content title="APM Tracing Disabled" level="h4" %}} -To disable APM tracing while keeping App and API Protection enabled, you must set the APM tracing variable to false. +To disable APM tracing while keeping {{< prodname >}}App and API Protection{{< /prodname >}} enabled, you must set the APM tracing variable to false. ```dockerfile # Set environment variables @@ -100,7 +100,7 @@ docker run -d \ ## Troubleshooting -If you encounter issues while setting up App and API Protection for your .NET application, see the [.NET App and API Protection troubleshooting guide][2]. +If you encounter issues while setting up {{< prodname >}}App and API Protection{{< /prodname >}} for your .NET application, see the [.NET App and API Protection troubleshooting guide][2]. ## Further Reading diff --git a/hugo/content/en/security/application_security/setup/dotnet/dotnet.md b/hugo/content/en/security/application_security/setup/dotnet/dotnet.md index 26f395a2a3f..656f295536b 100644 --- a/hugo/content/en/security/application_security/setup/dotnet/dotnet.md +++ b/hugo/content/en/security/application_security/setup/dotnet/dotnet.md @@ -27,11 +27,11 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} -You can monitor App and API Protection for .NET apps running in Docker, Kubernetes, Amazon ECS, and AWS Fargate. +You can monitor {{< prodname >}}App and API Protection{{< /prodname >}} for .NET apps running in Docker, Kubernetes, Amazon ECS, and AWS Fargate. {{% appsec-getstarted %}} @@ -204,7 +204,7 @@ ENV DD_APPSEC_ENABLED=true If you want to use Application & API Protection without APM tracing functionality, you can deploy with tracing disabled: 1. Configure your SDK with the `DD_APM_TRACING_ENABLED=false` environment variable in addition to the `DD_APPSEC_ENABLED=true` environment variable. -2. This configuration will reduce the amount of APM data sent to Datadog to the minimum required by App and API Protection products. +2. This configuration will reduce the amount of APM data sent to Datadog to the minimum required by {{< prodname >}}App and API Protection{{< /prodname >}} products. For more details, see [Standalone App and API Protection][standalone_billing_guide]. [standalone_billing_guide]: /security/application_security/guide/standalone_application_security/ diff --git a/hugo/content/en/security/application_security/setup/dotnet/kubernetes.md b/hugo/content/en/security/application_security/setup/dotnet/kubernetes.md index bb621ddfb63..8aa4cb8b82f 100644 --- a/hugo/content/en/security/application_security/setup/dotnet/kubernetes.md +++ b/hugo/content/en/security/application_security/setup/dotnet/kubernetes.md @@ -17,7 +17,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -86,7 +86,7 @@ spec: {{% /collapse-content %}} {{% collapse-content title="APM Tracing Disabled" level="h4" %}} -To disable APM tracing while keeping App and API Protection enabled, you must set the APM tracing variable to false. +To disable APM tracing while keeping {{< prodname >}}App and API Protection{{< /prodname >}} enabled, you must set the APM tracing variable to false. Update your Kubernetes deployment to include the required environment variables: @@ -126,7 +126,7 @@ kubectl apply -f your-deployment.yaml ## Troubleshooting -If you encounter issues while setting up App and API Protection for your .NET application, see the [.NET App and API Protection troubleshooting guide][2]. +If you encounter issues while setting up {{< prodname >}}App and API Protection{{< /prodname >}} for your .NET application, see the [.NET App and API Protection troubleshooting guide][2]. ## Further Reading diff --git a/hugo/content/en/security/application_security/setup/dotnet/linux.md b/hugo/content/en/security/application_security/setup/dotnet/linux.md index f30e61db837..69d24bd5efa 100644 --- a/hugo/content/en/security/application_security/setup/dotnet/linux.md +++ b/hugo/content/en/security/application_security/setup/dotnet/linux.md @@ -17,7 +17,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -107,7 +107,7 @@ export DD_APPSEC_ENABLED=true {{% /collapse-content %}} {{% collapse-content title="APM Tracing Disabled" level="h4" %}} -To disable APM tracing while keeping App and API Protection enabled, you must set the APM tracing variable to false. +To disable APM tracing while keeping {{< prodname >}}App and API Protection{{< /prodname >}} enabled, you must set the APM tracing variable to false. ```bash export CORECLR_ENABLE_PROFILING=1 export CORECLR_PROFILER={846F5F1C-F9AE-4B07-969E-05C26BC060D8} @@ -129,7 +129,7 @@ Start your .NET application with above settings. ## Troubleshooting -If you encounter issues while setting up App and API Protection for your .NET application, see the [.NET App and API Protection troubleshooting guide][4]. +If you encounter issues while setting up {{< prodname >}}App and API Protection{{< /prodname >}} for your .NET application, see the [.NET App and API Protection troubleshooting guide][4]. ## Further Reading diff --git a/hugo/content/en/security/application_security/setup/dotnet/troubleshooting.md b/hugo/content/en/security/application_security/setup/dotnet/troubleshooting.md index 204f646a334..fda1ac4beba 100644 --- a/hugo/content/en/security/application_security/setup/dotnet/troubleshooting.md +++ b/hugo/content/en/security/application_security/setup/dotnet/troubleshooting.md @@ -4,7 +4,7 @@ title: Troubleshooting .NET App and API Protection {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} diff --git a/hugo/content/en/security/application_security/setup/dotnet/windows.md b/hugo/content/en/security/application_security/setup/dotnet/windows.md index 9a0d83a52ee..2502e111d92 100644 --- a/hugo/content/en/security/application_security/setup/dotnet/windows.md +++ b/hugo/content/en/security/application_security/setup/dotnet/windows.md @@ -17,7 +17,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -53,7 +53,7 @@ DD_APPSEC_ENABLED=true {{% /collapse-content %}} {{% collapse-content title="APM Tracing Disabled" level="h4" %}} -To disable APM tracing while keeping App and API Protection enabled, add the following Environment Variables: +To disable APM tracing while keeping {{< prodname >}}App and API Protection{{< /prodname >}} enabled, add the following Environment Variables: ``` DD_APPSEC_ENABLED=true @@ -113,7 +113,7 @@ CORECLR_ENABLE_PROFILING=1 For a more detailed, see [the Datadog Tracer installation guide for .NET Framework][5] or [the Datadog Tracer installation guide for .NET Core][6]. -If you encounter issues while setting up App and API Protection for your .NET application, see the [.NET App and API Protection troubleshooting guide][4]. +If you encounter issues while setting up {{< prodname >}}App and API Protection{{< /prodname >}} for your .NET application, see the [.NET App and API Protection troubleshooting guide][4]. ## Further Reading diff --git a/hugo/content/en/security/application_security/setup/envoy.md b/hugo/content/en/security/application_security/setup/envoy.md index f0f568806fb..49f147ac285 100644 --- a/hugo/content/en/security/application_security/setup/envoy.md +++ b/hugo/content/en/security/application_security/setup/envoy.md @@ -21,11 +21,11 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} -You can enable App and API Protection for the Envoy proxy. The Datadog Envoy integration has support for threat detection and blocking. +You can enable {{< prodname >}}App and API Protection{{< /prodname >}} for the Envoy proxy. The Datadog Envoy integration has support for threat detection and blocking. ## Prerequisites @@ -39,7 +39,7 @@ The App and API Protection Envoy integration uses the Envoy external processing 1. Deploy a new container with the Datadog External Processor Docker image. The image is available on the [Datadog GitHub Registry][5]. - This service is a gRPC server that Envoy communicates with to have requests and responses analyzed by App and API Protection. + This service is a gRPC server that Envoy communicates with to have requests and responses analyzed by {{< prodname >}}App and API Protection{{< /prodname >}}. The Datadog External Processor exposes some settings: | Environment variable | Default value | Description | diff --git a/hugo/content/en/security/application_security/setup/gcp/cloud-run/_index.md b/hugo/content/en/security/application_security/setup/gcp/cloud-run/_index.md index 9c79cc311fa..63d9a123be0 100644 --- a/hugo/content/en/security/application_security/setup/gcp/cloud-run/_index.md +++ b/hugo/content/en/security/application_security/setup/gcp/cloud-run/_index.md @@ -21,11 +21,11 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} -Learn how to setup App and API Protection (AAP) on your Google Cloud Run functions by selecting the programming language your function is written with. +Learn how to setup {{< prodname >}}App and API Protection{{< /prodname >}} (AAP) on your Google Cloud Run functions by selecting the programming language your function is written with.

Are you missing your environment?

diff --git a/hugo/content/en/security/application_security/setup/gcp/cloud-run/dotnet.md b/hugo/content/en/security/application_security/setup/gcp/cloud-run/dotnet.md index 79abcf559c5..9b1e2ea058a 100644 --- a/hugo/content/en/security/application_security/setup/gcp/cloud-run/dotnet.md +++ b/hugo/content/en/security/application_security/setup/gcp/cloud-run/dotnet.md @@ -20,7 +20,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -34,7 +34,7 @@ To get full instrumentation, ensure you are calling `datadog-init` as the first ## Compatibility -
Google Cloud Run support for App and API Protection serverless is in Preview.
+
Google Cloud Run support for {{< prodname >}}App and API Protection{{< /prodname >}} serverless is in Preview.
**Note**: Threat Protection through Remote Configuration is not supported. Use [Workflows][5] to block IPs in your [WAF][6]. diff --git a/hugo/content/en/security/application_security/setup/gcp/cloud-run/go.md b/hugo/content/en/security/application_security/setup/gcp/cloud-run/go.md index fc51d3a3870..0c12c7a4a62 100644 --- a/hugo/content/en/security/application_security/setup/gcp/cloud-run/go.md +++ b/hugo/content/en/security/application_security/setup/gcp/cloud-run/go.md @@ -20,7 +20,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -34,7 +34,7 @@ To get full instrumentation, ensure you are calling `datadog-init` as the first ## Compatibility -
Google Cloud Run support for App and API Protection serverless is in Preview.
+
Google Cloud Run support for {{< prodname >}}App and API Protection{{< /prodname >}} serverless is in Preview.
**Note**: Threat Protection through Remote Configuration is not supported. Use [Workflows][5] to block IPs in your [WAF][6]. diff --git a/hugo/content/en/security/application_security/setup/gcp/cloud-run/java.md b/hugo/content/en/security/application_security/setup/gcp/cloud-run/java.md index 5ae6a5c306e..2c0e848533c 100644 --- a/hugo/content/en/security/application_security/setup/gcp/cloud-run/java.md +++ b/hugo/content/en/security/application_security/setup/gcp/cloud-run/java.md @@ -20,7 +20,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -34,7 +34,7 @@ To get full instrumentation, ensure you are calling `datadog-init` as the first ## Compatibility -
Google Cloud Run support for App and API Protection serverless is in Preview.
+
Google Cloud Run support for {{< prodname >}}App and API Protection{{< /prodname >}} serverless is in Preview.
**Note**: Threat Protection through Remote Configuration is not supported. Use [Workflows][5] to block IPs in your [WAF][6]. diff --git a/hugo/content/en/security/application_security/setup/gcp/cloud-run/nodejs.md b/hugo/content/en/security/application_security/setup/gcp/cloud-run/nodejs.md index 6a89474bdd8..f9b5770acf5 100644 --- a/hugo/content/en/security/application_security/setup/gcp/cloud-run/nodejs.md +++ b/hugo/content/en/security/application_security/setup/gcp/cloud-run/nodejs.md @@ -20,7 +20,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -34,7 +34,7 @@ To get full instrumentation, ensure you are calling `datadog-init` as the first ## Compatibility -
Google Cloud Run support for App and API Protection serverless is in Preview.
+
Google Cloud Run support for {{< prodname >}}App and API Protection{{< /prodname >}} serverless is in Preview.
**Note**: Threat Protection through Remote Configuration is not supported. Use [Workflows][5] to block IPs in your [WAF][6]. diff --git a/hugo/content/en/security/application_security/setup/gcp/cloud-run/php.md b/hugo/content/en/security/application_security/setup/gcp/cloud-run/php.md index e715779cbb8..ac1a9285262 100644 --- a/hugo/content/en/security/application_security/setup/gcp/cloud-run/php.md +++ b/hugo/content/en/security/application_security/setup/gcp/cloud-run/php.md @@ -20,7 +20,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -36,7 +36,7 @@ To get full instrumentation, ensure you are calling `datadog-init` as the first ## Compatibility -
Google Cloud Run support for App and API Protection serverless is in Preview.
+
Google Cloud Run support for {{< prodname >}}App and API Protection{{< /prodname >}} serverless is in Preview.
**Note**: Threat Protection through Remote Configuration is not supported. Instead, use [Workflows][5] to block IPs in your [WAF][6]. ### Get started diff --git a/hugo/content/en/security/application_security/setup/gcp/cloud-run/python.md b/hugo/content/en/security/application_security/setup/gcp/cloud-run/python.md index 39dd0cdc278..c7d19ca14b7 100644 --- a/hugo/content/en/security/application_security/setup/gcp/cloud-run/python.md +++ b/hugo/content/en/security/application_security/setup/gcp/cloud-run/python.md @@ -20,7 +20,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -34,7 +34,7 @@ To get full instrumentation, ensure you are calling `datadog-init` as the first ## Compatibility -
Google Cloud Run support for App and API Protection serverless is in Preview.
+
Google Cloud Run support for {{< prodname >}}App and API Protection{{< /prodname >}} serverless is in Preview.
**Note**: Threat Protection through Remote Configuration is not supported. Use [Workflows][5] to block IPs in your [WAF][6]. diff --git a/hugo/content/en/security/application_security/setup/gcp/cloud-run/ruby.md b/hugo/content/en/security/application_security/setup/gcp/cloud-run/ruby.md index cc0834e177a..0e2d0f046db 100644 --- a/hugo/content/en/security/application_security/setup/gcp/cloud-run/ruby.md +++ b/hugo/content/en/security/application_security/setup/gcp/cloud-run/ruby.md @@ -20,7 +20,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -34,7 +34,7 @@ To get full instrumentation, ensure you are calling `datadog-init` as the first ## Compatibility -
Google Cloud Run support for App and API Protection serverless is in Preview.
+
Google Cloud Run support for {{< prodname >}}App and API Protection{{< /prodname >}} serverless is in Preview.
**Note**: Threat Protection through Remote Configuration is not supported. Use [Workflows][5] to block IPs in your [WAF][6]. diff --git a/hugo/content/en/security/application_security/setup/gcp/service-extensions.md b/hugo/content/en/security/application_security/setup/gcp/service-extensions.md index c1b5a4b1132..35154a71c24 100644 --- a/hugo/content/en/security/application_security/setup/gcp/service-extensions.md +++ b/hugo/content/en/security/application_security/setup/gcp/service-extensions.md @@ -27,7 +27,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -35,7 +35,7 @@ App and API Protection is in Preview on Datadog Government site US1-FED. To try the preview of App and API Protection Service Extensions for GCP, use the following setup instructions. {{< /callout >}} -You can enable App and API Protection with GCP Service Extensions within GCP Cloud Load Balancing. The Datadog App and API Protection Service Extensions integration provides threat detection and blocking capabilities directly in your GCP environment. +You can enable {{< prodname >}}App and API Protection{{< /prodname >}} with GCP Service Extensions within GCP Cloud Load Balancing. The Datadog App and API Protection Service Extensions integration provides threat detection and blocking capabilities directly in your GCP environment. ## Prerequisites @@ -53,7 +53,7 @@ You can enable App and API Protection with GCP Service Extensions within GCP Clo To set up the App and API Protection Service Extension in GCP, use the Google Cloud Console with VM Compute Engine or Terraform scripts, and complete the following steps. -**Note:** Google Cloud provides guides for creating [a callout backend service][4] and [configuring a Service Extension as a traffic extension][5]. The following steps use the same general setup but include custom configurations specific to Datadog's App and API Protection integration. +**Note:** Google Cloud provides guides for creating [a callout backend service][4] and [configuring a Service Extension as a traffic extension][5]. The following steps use the same general setup but include custom configurations specific to Datadog's {{< prodname >}}App and API Protection{{< /prodname >}} integration. {{< tabs >}} {{% tab "VM Compute Engine" %}} diff --git a/hugo/content/en/security/application_security/setup/go/_index.md b/hugo/content/en/security/application_security/setup/go/_index.md index 6a3afd7224e..07c391cd566 100644 --- a/hugo/content/en/security/application_security/setup/go/_index.md +++ b/hugo/content/en/security/application_security/setup/go/_index.md @@ -21,13 +21,13 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} ## Overview -App and API Protection (AAP) leverages the [Datadog Go library][5] to monitor and secure your Go service. The library integrates seamlessly into your workflow using [Orchestrion][6], an automatic compile-time instrumentation of Go code that does not require code changes. +{{< prodname >}}App and API Protection{{< /prodname >}} (AAP) leverages the [Datadog Go library][5] to monitor and secure your Go service. The library integrates seamlessly into your workflow using [Orchestrion][6], an automatic compile-time instrumentation of Go code that does not require code changes. For detailed compatibility information, including supported Go versions, frameworks, and deployment environments, see [Go Compatibility Requirements][2]. diff --git a/hugo/content/en/security/application_security/setup/go/aws-fargate.md b/hugo/content/en/security/application_security/setup/go/aws-fargate.md index f45a34c5bbd..5c37a1b92a3 100644 --- a/hugo/content/en/security/application_security/setup/go/aws-fargate.md +++ b/hugo/content/en/security/application_security/setup/go/aws-fargate.md @@ -17,7 +17,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -62,7 +62,7 @@ Install the Datadog Agent in your Fargate task definition: ### Building your application with Orchestrion -To enable App and API Protection for Go, you need to compile your application with [Orchestrion][4], Datadog's compile-time instrumentation tool. +To enable {{< prodname >}}App and API Protection{{< /prodname >}} for Go, you need to compile your application with [Orchestrion][4], Datadog's compile-time instrumentation tool. Update your Dockerfile to install Orchestrion and build your application: @@ -97,7 +97,7 @@ CMD ["/myapp"] {{% collapse-content title="APM Tracing Enabled" level="h3" %}} -Update your task definition to include the Go application container with App and API Protection configuration: +Update your task definition to include the Go application container with {{< prodname >}}App and API Protection{{< /prodname >}} configuration: ```json { @@ -128,9 +128,9 @@ Update your task definition to include the Go application container with App and {{% collapse-content title="APM Tracing Disabled" level="h3" %}} -To disable APM tracing while keeping App and API Protection enabled, you must set the APM tracing variable to false. +To disable APM tracing while keeping {{< prodname >}}App and API Protection{{< /prodname >}} enabled, you must set the APM tracing variable to false. -Update your task definition to include the Go application container with App and API Protection configuration with APM tracing disabled: +Update your task definition to include the Go application container with {{< prodname >}}App and API Protection{{< /prodname >}} configuration with APM tracing disabled: ```json { @@ -174,7 +174,7 @@ aws ecs run-task --cluster your-cluster --task-definition your-task-definition ## 4. Verify your setup -To verify that App and API Protection is working correctly, send known attack patterns to your application. For example, trigger the [Security Scanner Detected][5] rule by running a file that contains the following curl script: +To verify that {{< prodname >}}App and API Protection{{< /prodname >}} is working correctly, send known attack patterns to your application. For example, trigger the [Security Scanner Detected][5] rule by running a file that contains the following curl script: ```bash for ((i=1;i<=250;i++)); @@ -190,7 +190,7 @@ A few minutes after you enable your application and exercise it, threat informat ## Troubleshooting -If you encounter issues while setting up App and API Protection for your Go application, see the [Go App and API Protection troubleshooting guide][7]. +If you encounter issues while setting up {{< prodname >}}App and API Protection{{< /prodname >}} for your Go application, see the [Go App and API Protection troubleshooting guide][7]. ## Further Reading diff --git a/hugo/content/en/security/application_security/setup/go/dockerfile.md b/hugo/content/en/security/application_security/setup/go/dockerfile.md index 26ce4483398..adb74280f19 100644 --- a/hugo/content/en/security/application_security/setup/go/dockerfile.md +++ b/hugo/content/en/security/application_security/setup/go/dockerfile.md @@ -14,11 +14,11 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} -App and API Protection for Go installation requirements can be abstract and the Go toolchain +{{< prodname >}}App and API Protection{{< /prodname >}} for Go installation requirements can be abstract and the Go toolchain cross-compilation and CGO capabilities can make precise installation steps difficult to understand. The goal of this guide is to provide a step-by-step guide to a working Dockerfile customized for your use case. @@ -54,16 +54,16 @@ ENTRYPOINT [ "/usr/local/bin/main" ] This is the simplest version of a working Dockerfile for a Datadog WAF-enabled Go application. If this is your first use of [Orchestrion][5], note that this dockerfile requires you run `orchestrion pin` beforehand and commit the resulting changes. See [Getting Started for Go][6]. This Dockerfile is split into two stages: -1. The build stage uses a Debian image to build the Go application, and uses the [Orchestrion][5] tool to instrument the application with App and API Protection features. -2. The runtime stage copies the built application into a minimal Ubuntu image and sets the environment variable `DD_APPSEC_ENABLED` to `true` to enable App and API Protection. +1. The build stage uses a Debian image to build the Go application, and uses the [Orchestrion][5] tool to instrument the application with {{< prodname >}}App and API Protection{{< /prodname >}} features. +2. The runtime stage copies the built application into a minimal Ubuntu image and sets the environment variable `DD_APPSEC_ENABLED` to `true` to enable {{< prodname >}}App and API Protection{{< /prodname >}}. -This two-stage build process allows you to keep the final image small and free of unnecessary build tools while still ensuring that your application is instrumented correctly for App and API Protection. +This two-stage build process allows you to keep the final image small and free of unnecessary build tools while still ensuring that your application is instrumented correctly for {{< prodname >}}App and API Protection{{< /prodname >}}. The following sections show different Dockerfile scenarios, each with their specific considerations and complete examples. ## Dockerfile scenarios -Two main dimensions impact your Dockerfile choice for App and API Protection: +Two main dimensions impact your Dockerfile choice for {{< prodname >}}App and API Protection{{< /prodname >}}: * **libc implementation**: glibc (Debian/Ubuntu) or musl (Alpine) * **CGO**: enabled or disabled (with the env var `CGO_ENABLED`). @@ -247,9 +247,9 @@ docker run appsec-go-test-app ### Verify your setup -To verify that App and API Protection is working correctly: +To verify that {{< prodname >}}App and API Protection{{< /prodname >}} is working correctly: -To see App and API Protection threat detection in action, send known attack patterns to your application. For example, trigger the [Security Scanner Detected][9] rule by running a file that contains the following curl script: +To see {{< prodname >}}App and API Protection{{< /prodname >}} threat detection in action, send known attack patterns to your application. For example, trigger the [Security Scanner Detected][9] rule by running a file that contains the following curl script: ```bash for ((i=1;i<=250;i++)); do diff --git a/hugo/content/en/security/application_security/setup/go/sdk.md b/hugo/content/en/security/application_security/setup/go/sdk.md index 3a677cfbe3b..493343c2fcf 100644 --- a/hugo/content/en/security/application_security/setup/go/sdk.md +++ b/hugo/content/en/security/application_security/setup/go/sdk.md @@ -17,7 +17,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} diff --git a/hugo/content/en/security/application_security/setup/go/setup.md b/hugo/content/en/security/application_security/setup/go/setup.md index a458f96045e..8ce745371d0 100644 --- a/hugo/content/en/security/application_security/setup/go/setup.md +++ b/hugo/content/en/security/application_security/setup/go/setup.md @@ -28,7 +28,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -61,7 +61,7 @@ App and API Protection is in Preview on Datadog Government site US1-FED. Note: If you are building without [CGO][9] on Linux, see [Building Go applications with CGO disabled][6]. -5. Redeploy your Go service and enable App and API Protection by setting the `DD_APPSEC_ENABLED` environment variable to `true`: +5. Redeploy your Go service and enable {{< prodname >}}App and API Protection{{< /prodname >}} by setting the `DD_APPSEC_ENABLED` environment variable to `true`: {{< tabs >}} {{% tab "Environment Variable" %}} @@ -79,7 +79,7 @@ Add the following environment variable value to your Docker command line: $ docker run -e DD_APPSEC_ENABLED=true [...] ``` -For more information on how to create a fitting docker image, See Creating a Dockerfile for App and API Protection for Go. +For more information on how to create a fitting docker image, See Creating a Dockerfile for {{< prodname >}}App and API Protection{{< /prodname >}} for Go. {{% /tab %}} {{% tab "Dockerfile" %}} @@ -109,7 +109,7 @@ spec: value: "true" ``` -For more information on how to create a fitting docker image, See Creating a Dockerfile for App and API Protection for Go. +For more information on how to create a fitting docker image, See Creating a Dockerfile for {{< prodname >}}App and API Protection{{< /prodname >}} for Go. {{% /tab %}} {{% tab "Amazon ECS" %}} @@ -126,7 +126,7 @@ Update your application's ECS task definition JSON file using this environment s ] ``` -For more information on how to create a fitting docker image, See Creating a Dockerfile for App and API Protection for Go. +For more information on how to create a fitting docker image, See Creating a Dockerfile for {{< prodname >}}App and API Protection{{< /prodname >}} for Go. {{% /tab %}} @@ -134,9 +134,9 @@ For more information on how to create a fitting docker image, See }}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -16,13 +16,13 @@ App and API Protection is in Preview on Datadog Government site US1-FED. When security signals don't appear, this could be due to an incompatible Agent version: -- **Error**: No security events in the Datadog UI, despite App and API Protection being enabled +- **Error**: No security events in the Datadog UI, despite {{< prodname >}}App and API Protection{{< /prodname >}} being enabled - **Solution**: Upgrade to Datadog Agent v7.41.1 or higher - **Verification**: Check Agent status with `datadog-agent status` #### Outdated Go tracer version -Older Go tracer versions may not support App and API Protection features: +Older Go tracer versions may not support {{< prodname >}}App and API Protection{{< /prodname >}} features: - **Error**: Security monitoring not working despite proper configuration - **Solution**: Upgrade to Go tracer v1.53.0 or higher: `go get github.com/DataDog/dd-trace-go/v2@latest` @@ -30,7 +30,7 @@ Older Go tracer versions may not support App and API Protection features: #### Missing or incorrect environment variables -App and API Protection requires specific environment variables to be set: +{{< prodname >}}App and API Protection{{< /prodname >}} requires specific environment variables to be set: - **Error**: Application starts normally but no security monitoring occurs - **Solution**: Set `DD_APPSEC_ENABLED=true` in your deployment environment diff --git a/hugo/content/en/security/application_security/setup/haproxy.md b/hugo/content/en/security/application_security/setup/haproxy.md index dbf86bfe7f2..07be3ac770b 100644 --- a/hugo/content/en/security/application_security/setup/haproxy.md +++ b/hugo/content/en/security/application_security/setup/haproxy.md @@ -19,15 +19,15 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} {{< callout url="https://www.datadoghq.com/product-preview/haproxy-integration/">}} -App and API Protection for HAProxy is in Preview. To sign up, click Request Access and complete the form. +{{< prodname >}}App and API Protection{{< /prodname >}} for HAProxy is in Preview. To sign up, click Request Access and complete the form. {{< /callout >}} -You can enable App and API Protection for your HAProxy instances. The Datadog HAProxy integration leverages HAProxy's Stream Processing Offload Engine (SPOE) to inspect and protect traffic for threat detection at the edge of your infrastructure. +You can enable {{< prodname >}}App and API Protection{{< /prodname >}} for your HAProxy instances. The Datadog HAProxy integration leverages HAProxy's Stream Processing Offload Engine (SPOE) to inspect and protect traffic for threat detection at the edge of your infrastructure. ## Prerequisites @@ -40,7 +40,7 @@ You can enable App and API Protection for your HAProxy instances. The Datadog HA The App and API Protection HAProxy integration uses HAProxy's [Stream Processing Offload Engine][3] (SPOE) to call a Datadog Stream Processing Offload Agent (SPOA). The SPOA analyzes requests and responses. -To enable App and API Protection for HAProxy, do the following: +To enable {{< prodname >}}App and API Protection{{< /prodname >}} for HAProxy, do the following: 1. Deploy the Datadog HAProxy SPOA container. 2. Update your HAProxy configuration files to integrate with the SPOA @@ -104,7 +104,7 @@ The `datadog_aap_blocking_response.lua` script is responsible for sending a cust It is important that no custom modifications are made to this file.
- Note: This Lua script is not invoked on every request processed by HAProxy. It is only invoked when a request is blocked by App and API Protection. This design ensures optimal performance by avoiding the overhead of running Lua code for all requests. + Note: This Lua script is not invoked on every request processed by HAProxy. It is only invoked when a request is blocked by {{< prodname >}}App and API Protection{{< /prodname >}}. This design ensures optimal performance by avoiding the overhead of running Lua code for all requests.
### Validation diff --git a/hugo/content/en/security/application_security/setup/java/_index.md b/hugo/content/en/security/application_security/setup/java/_index.md index fa2392e6956..2053a76131d 100644 --- a/hugo/content/en/security/application_security/setup/java/_index.md +++ b/hugo/content/en/security/application_security/setup/java/_index.md @@ -28,7 +28,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} diff --git a/hugo/content/en/security/application_security/setup/java/aws-fargate.md b/hugo/content/en/security/application_security/setup/java/aws-fargate.md index d1fe71a3a69..312911fc964 100644 --- a/hugo/content/en/security/application_security/setup/java/aws-fargate.md +++ b/hugo/content/en/security/application_security/setup/java/aws-fargate.md @@ -17,7 +17,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -77,7 +77,7 @@ ADD 'https://dtdg.co/latest-java-tracer' /dd-java-agent.jar {{< tabs >}} {{% tab "Using system properties" %}} -Update your task definition to include the Java agent and App and API Protection configuration: +Update your task definition to include the Java agent and {{< prodname >}}App and API Protection{{< /prodname >}} configuration: ```json { @@ -102,7 +102,7 @@ Update your task definition to include the Java agent and App and API Protection {{% /tab %}} {{% tab "Using environment variables" %}} -Update your task definition to include the Java agent and App and API Protection configuration: +Update your task definition to include the Java agent and {{< prodname >}}App and API Protection{{< /prodname >}} configuration: ```json { @@ -140,11 +140,11 @@ Update your task definition to include the Java agent and App and API Protection {{% /collapse-content %}} {{% collapse-content title="APM Tracing Disabled" level="h4" %}} -To disable APM tracing while keeping App and API Protection enabled, you must set the APM tracing variable to false. +To disable APM tracing while keeping {{< prodname >}}App and API Protection{{< /prodname >}} enabled, you must set the APM tracing variable to false. {{< tabs >}} {{% tab "Using system properties" %}} -Update your task definition to include the Java agent and App and API Protection configuration with APM tracing disabled: +Update your task definition to include the Java agent and {{< prodname >}}App and API Protection{{< /prodname >}} configuration with APM tracing disabled: ```json { @@ -170,7 +170,7 @@ Update your task definition to include the Java agent and App and API Protection {{% /tab %}} {{% tab "Using environment variables" %}} -Update your task definition to include the Java agent and App and API Protection configuration with APM tracing disabled: +Update your task definition to include the Java agent and {{< prodname >}}App and API Protection{{< /prodname >}} configuration with APM tracing disabled: ```json { @@ -224,7 +224,7 @@ aws ecs run-task --cluster your-cluster --task-definition your-task-definition ## Troubleshooting -If you encounter issues while setting up App and API Protection for your Java application, see the [Java App and API Protection troubleshooting guide][2]. +If you encounter issues while setting up {{< prodname >}}App and API Protection{{< /prodname >}} for your Java application, see the [Java App and API Protection troubleshooting guide][2]. ## Further Reading diff --git a/hugo/content/en/security/application_security/setup/java/docker.md b/hugo/content/en/security/application_security/setup/java/docker.md index 9e16bf54892..16dce5236f1 100644 --- a/hugo/content/en/security/application_security/setup/java/docker.md +++ b/hugo/content/en/security/application_security/setup/java/docker.md @@ -17,7 +17,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -47,7 +47,7 @@ Install the Datadog Agent by following the [setup instructions for Docker][3]. {{< tabs >}} {{% tab "Using system properties" %}} -Start your Java application with the Datadog agent and App and API Protection enabled using the ENTRYPOINT instruction: +Start your Java application with the Datadog agent and {{< prodname >}}App and API Protection{{< /prodname >}} enabled using the ENTRYPOINT instruction: ```dockerfile # Download the Datadog Java tracer @@ -78,11 +78,11 @@ ENTRYPOINT ["java", "-javaagent:/dd-java-agent.jar", "-jar", "/app.jar"] {{% /collapse-content %}} {{% collapse-content title="APM Tracing Disabled" level="h4" %}} -To disable APM tracing while keeping App and API Protection enabled, you must set the APM tracing variable to false. +To disable APM tracing while keeping {{< prodname >}}App and API Protection{{< /prodname >}} enabled, you must set the APM tracing variable to false. {{< tabs >}} {{% tab "Using system properties" %}} -Start your Java application with the Datadog agent and App and API Protection enabled using the ENTRYPOINT instruction: +Start your Java application with the Datadog agent and {{< prodname >}}App and API Protection{{< /prodname >}} enabled using the ENTRYPOINT instruction: ```dockerfile # Download the Datadog Java tracer @@ -130,7 +130,7 @@ docker run -d \ ## Troubleshooting -If you encounter issues while setting up App and API Protection for your Java application, see the [Java App and API Protection troubleshooting guide][2]. +If you encounter issues while setting up {{< prodname >}}App and API Protection{{< /prodname >}} for your Java application, see the [Java App and API Protection troubleshooting guide][2]. ## Further Reading diff --git a/hugo/content/en/security/application_security/setup/java/kubernetes.md b/hugo/content/en/security/application_security/setup/java/kubernetes.md index 64b3d28a14d..05ac5c9de4a 100644 --- a/hugo/content/en/security/application_security/setup/java/kubernetes.md +++ b/hugo/content/en/security/application_security/setup/java/kubernetes.md @@ -17,7 +17,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -71,7 +71,7 @@ spec: {{< tabs >}} {{% tab "Using command-line arguments" %}} -Start your Java application with the Datadog agent and App and API Protection enabled using command-line arguments: +Start your Java application with the Datadog agent and {{< prodname >}}App and API Protection{{< /prodname >}} enabled using command-line arguments: ```yaml apiVersion: apps/v1 @@ -95,7 +95,7 @@ spec: {{% /tab %}} {{% tab "Using environment variables" %}} -Start your Java application with App and API Protection enabled using environment variables: +Start your Java application with {{< prodname >}}App and API Protection{{< /prodname >}} enabled using environment variables: ```yaml apiVersion: apps/v1 @@ -128,11 +128,11 @@ spec: {{% /collapse-content %}} {{% collapse-content title="APM Tracing Disabled" level="h4" %}} -To disable APM tracing while keeping App and API Protection enabled, you must set the APM tracing variable to false. +To disable APM tracing while keeping {{< prodname >}}App and API Protection{{< /prodname >}} enabled, you must set the APM tracing variable to false. {{< tabs >}} {{% tab "Using command-line arguments" %}} -Start your Java application with the Datadog agent and App and API Protection enabled using command-line arguments: +Start your Java application with the Datadog agent and {{< prodname >}}App and API Protection{{< /prodname >}} enabled using command-line arguments: ```yaml apiVersion: apps/v1 @@ -156,7 +156,7 @@ spec: {{% /tab %}} {{% tab "Using environment variables" %}} -Start your Java application with App and API Protection enabled using environment variables: +Start your Java application with {{< prodname >}}App and API Protection{{< /prodname >}} enabled using environment variables: ```yaml apiVersion: apps/v1 @@ -203,7 +203,7 @@ kubectl apply -f your-deployment.yaml ## Troubleshooting -If you encounter issues while setting up App and API Protection for your Java application, see the [Java App and API Protection troubleshooting guide][2]. +If you encounter issues while setting up {{< prodname >}}App and API Protection{{< /prodname >}} for your Java application, see the [Java App and API Protection troubleshooting guide][2]. ## Further Reading diff --git a/hugo/content/en/security/application_security/setup/java/linux.md b/hugo/content/en/security/application_security/setup/java/linux.md index 353090b93cf..2e4bd9bd146 100644 --- a/hugo/content/en/security/application_security/setup/java/linux.md +++ b/hugo/content/en/security/application_security/setup/java/linux.md @@ -17,7 +17,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -55,7 +55,7 @@ wget -O dd-java-agent.jar 'https://dtdg.co/latest-java-tracer' {{< tabs >}} {{% tab "Using system properties" %}} -Start your Java application with the Datadog agent and App and API Protection enabled using system properties: +Start your Java application with the Datadog agent and {{< prodname >}}App and API Protection{{< /prodname >}} enabled using system properties: ```bash java -javaagent:/path/to/dd-java-agent.jar -Ddd.appsec.enabled=true -Ddd.service= -Ddd.env= -jar path/to/app.jar @@ -79,11 +79,11 @@ java -javaagent:/path/to/dd-java-agent.jar -jar path/to/app.jar {{% /collapse-content %}} {{% collapse-content title="APM Tracing Disabled" level="h4" %}} -To disable APM tracing while keeping App and API Protection enabled, you must set the APM tracing variable to false. +To disable APM tracing while keeping {{< prodname >}}App and API Protection{{< /prodname >}} enabled, you must set the APM tracing variable to false. {{< tabs >}} {{% tab "Using system properties" %}} -Start your Java application with the Datadog agent and App and API Protection enabled using system properties: +Start your Java application with the Datadog agent and {{< prodname >}}App and API Protection{{< /prodname >}} enabled using system properties: ```bash java -javaagent:/path/to/dd-java-agent.jar -Ddd.appsec.enabled=true -Ddd.apm.tracing.enabled=false -Ddd.service= -Ddd.env= -jar path/to/app.jar @@ -115,7 +115,7 @@ Start your Java application with above settings. ## Troubleshooting -If you encounter issues while setting up App and API Protection for your Java application, see the [Java App and API Protection troubleshooting guide][2]. +If you encounter issues while setting up {{< prodname >}}App and API Protection{{< /prodname >}} for your Java application, see the [Java App and API Protection troubleshooting guide][2]. ## Further Reading diff --git a/hugo/content/en/security/application_security/setup/java/macos.md b/hugo/content/en/security/application_security/setup/java/macos.md index 0655a22d374..4aae03d401f 100644 --- a/hugo/content/en/security/application_security/setup/java/macos.md +++ b/hugo/content/en/security/application_security/setup/java/macos.md @@ -17,7 +17,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -52,7 +52,7 @@ curl -Lo dd-java-agent.jar 'https://dtdg.co/latest-java-tracer' {{< tabs >}} {{% tab "Using system properties" %}} -Start your Java application with the Datadog agent and App and API Protection enabled using system properties: +Start your Java application with the Datadog agent and {{< prodname >}}App and API Protection{{< /prodname >}} enabled using system properties: ```bash java -javaagent:/path/to/dd-java-agent.jar -Ddd.appsec.enabled=true -Ddd.service= -Ddd.env= -jar path/to/app.jar @@ -76,11 +76,11 @@ java -javaagent:/path/to/dd-java-agent.jar -jar path/to/app.jar {{% /collapse-content %}} {{% collapse-content title="APM Tracing Disabled" level="h4" %}} -To disable APM tracing while keeping App and API Protection enabled, you must set the APM tracing variable to false. +To disable APM tracing while keeping {{< prodname >}}App and API Protection{{< /prodname >}} enabled, you must set the APM tracing variable to false. {{< tabs >}} {{% tab "Using system properties" %}} -Start your Java application with the Datadog agent and App and API Protection enabled using system properties: +Start your Java application with the Datadog agent and {{< prodname >}}App and API Protection{{< /prodname >}} enabled using system properties: ```bash java -javaagent:/path/to/dd-java-agent.jar -Ddd.appsec.enabled=true -Ddd.apm.tracing.enabled=false -Ddd.service= -Ddd.env= -jar path/to/app.jar @@ -111,7 +111,7 @@ Start your Java application with the configured settings. ## Troubleshooting -If you encounter issues while setting up App and API Protection for your Java application, see the [Java App and API Protection troubleshooting guide][2]. +If you encounter issues while setting up {{< prodname >}}App and API Protection{{< /prodname >}} for your Java application, see the [Java App and API Protection troubleshooting guide][2]. ## Further Reading diff --git a/hugo/content/en/security/application_security/setup/java/troubleshooting.md b/hugo/content/en/security/application_security/setup/java/troubleshooting.md index f604e3b5845..c8cbbe3813b 100644 --- a/hugo/content/en/security/application_security/setup/java/troubleshooting.md +++ b/hugo/content/en/security/application_security/setup/java/troubleshooting.md @@ -4,7 +4,7 @@ title: Troubleshooting Java App and API Protection {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} diff --git a/hugo/content/en/security/application_security/setup/java/windows.md b/hugo/content/en/security/application_security/setup/java/windows.md index 5da368ed967..1f2dd1c4de1 100644 --- a/hugo/content/en/security/application_security/setup/java/windows.md +++ b/hugo/content/en/security/application_security/setup/java/windows.md @@ -17,7 +17,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -51,7 +51,7 @@ Invoke-WebRequest -Uri "https://dtdg.co/latest-java-tracer" -OutFile "dd-java-ag {{< tabs >}} {{% tab "Using system properties" %}} -Start your Java application with the Datadog agent and App and API Protection enabled using system properties: +Start your Java application with the Datadog agent and {{< prodname >}}App and API Protection{{< /prodname >}} enabled using system properties: ```powershell java -javaagent:path\to\dd-java-agent.jar -Ddd.appsec.enabled=true -Ddd.service= -Ddd.env= -jar path\to\app.jar @@ -75,11 +75,11 @@ java -javaagent:path\to\dd-java-agent.jar -jar path\to\app.jar {{% /collapse-content %}} {{% collapse-content title="APM Tracing Disabled" level="h4" %}} -To disable APM tracing while keeping App and API Protection enabled, you must set the APM tracing variable to false. +To disable APM tracing while keeping {{< prodname >}}App and API Protection{{< /prodname >}} enabled, you must set the APM tracing variable to false. {{< tabs >}} {{% tab "Using system properties" %}} -Start your Java application with the Datadog agent and App and API Protection enabled using system properties: +Start your Java application with the Datadog agent and {{< prodname >}}App and API Protection{{< /prodname >}} enabled using system properties: ```powershell java -javaagent:path\to\dd-java-agent.jar -Ddd.appsec.enabled=true -Ddd.apm.tracing.enabled=false -Ddd.service= -Ddd.env= -jar path\to\app.jar @@ -111,7 +111,7 @@ Start your Java application with the configured settings. ## Troubleshooting -If you encounter issues while setting up App and API Protection for your Java application, see the [Java App and API Protection troubleshooting guide][2]. +If you encounter issues while setting up {{< prodname >}}App and API Protection{{< /prodname >}} for your Java application, see the [Java App and API Protection troubleshooting guide][2]. ## Further Reading diff --git a/hugo/content/en/security/application_security/setup/kubernetes/_index.md b/hugo/content/en/security/application_security/setup/kubernetes/_index.md index 8df242ce3d1..3613f0795c0 100644 --- a/hugo/content/en/security/application_security/setup/kubernetes/_index.md +++ b/hugo/content/en/security/application_security/setup/kubernetes/_index.md @@ -21,11 +21,11 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} -Learn how to set up App and API Protection (AAP) on your Kubernetes clusters by selecting the Kubernetes integration that suits you best. +Learn how to set up {{< prodname >}}App and API Protection{{< /prodname >}} (AAP) on your Kubernetes clusters by selecting the Kubernetes integration that suits you best.

Are you missing your environment?

diff --git a/hugo/content/en/security/application_security/setup/kubernetes/envoy-gateway.md b/hugo/content/en/security/application_security/setup/kubernetes/envoy-gateway.md index 5ed3f89bb55..85d626ba147 100644 --- a/hugo/content/en/security/application_security/setup/kubernetes/envoy-gateway.md +++ b/hugo/content/en/security/application_security/setup/kubernetes/envoy-gateway.md @@ -18,15 +18,15 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} -{{< callout url="#" btn_hidden="true" header="App and API Protection for Envoy Gateway is in Preview" >}} -App and API Protection for Envoy Gateway is in Preview. Use the following instructions to try the preview. +{{< callout url="#" btn_hidden="true" header="{{< prodname >}}App and API Protection{{< /prodname >}} for Envoy Gateway is in Preview" >}} +{{< prodname >}}App and API Protection{{< /prodname >}} for Envoy Gateway is in Preview. Use the following instructions to try the preview. {{< /callout >}} -You can enable Datadog [App and API Protection][12] for traffic managed by [Envoy Gateway][1] to inspect and protect traffic at the edge of your infrastructure. +You can enable Datadog [{{< prodname >}}App and API Protection{{< /prodname >}}][12] for traffic managed by [Envoy Gateway][1] to inspect and protect traffic at the edge of your infrastructure. ## Prerequisites @@ -34,7 +34,7 @@ You can enable Datadog [App and API Protection][12] for traffic managed by [Envo - The [Datadog Agent is installed and configured][2] in your Kubernetes cluster. - Enable and configure [Remote Configuration][3] to enable blocking attackers through the Datadog UI. - Enable [APM][4] in the Agent to allow the security processor service to send its own traces to the Agent. - - Optionally, enable the [Cluster Agent Admission Controller][5] to automatically inject the Datadog Agent host information to the App and API Protection security processor service. + - Optionally, enable the [Cluster Agent Admission Controller][5] to automatically inject the Datadog Agent host information to the {{< prodname >}}App and API Protection{{< /prodname >}} security processor service. ## Automated configuration with App and API Protection for Kubernetes @@ -121,7 +121,7 @@ For fine-grained control over specific gateways, use the manual setup: ### Step 1: Deploy the Datadog security processor service -This gRPC server receives requests and responses from Envoy for App and API Protection analysis. +This gRPC server receives requests and responses from Envoy for {{< prodname >}}App and API Protection{{< /prodname >}} analysis. Deploy it in a namespace accessible by your Envoy Gateway. The Docker image is on the [Datadog Go tracer GitHub Registry][6]. @@ -303,7 +303,7 @@ spec: ### Step 3: Validate -After applying the policy, traffic through the targeted Gateway/Routes is inspected by App and API Protection. +After applying the policy, traffic through the targeted Gateway/Routes is inspected by {{< prodname >}}App and API Protection{{< /prodname >}}. {{% appsec-getstarted-2-plusrisk %}} diff --git a/hugo/content/en/security/application_security/setup/kubernetes/gateway-api.md b/hugo/content/en/security/application_security/setup/kubernetes/gateway-api.md index e74f04c052f..3c317eb8c99 100644 --- a/hugo/content/en/security/application_security/setup/kubernetes/gateway-api.md +++ b/hugo/content/en/security/application_security/setup/kubernetes/gateway-api.md @@ -18,7 +18,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -166,10 +166,10 @@ By default, the request mirror traces won't enable Datadog's APM product. If you To enable APM tracing, set the environment variable `DD_APM_TRACING_ENABLED=true` in the request mirror deployment. -If you want to explicitly disable APM tracing while using App and API Protection: +If you want to explicitly disable APM tracing while using {{< prodname >}}App and API Protection{{< /prodname >}}: 1. Configure your deployment with the `DD_APM_TRACING_ENABLED=false` environment variable in addition to the `DD_APPSEC_ENABLED=true` environment variable. -2. This configuration will reduce the amount of APM data sent to Datadog to the minimum required by App and API Protection products. +2. This configuration will reduce the amount of APM data sent to Datadog to the minimum required by {{< prodname >}}App and API Protection{{< /prodname >}} products. For more details, see [Standalone App and API Protection][15]. diff --git a/hugo/content/en/security/application_security/setup/kubernetes/gke.md b/hugo/content/en/security/application_security/setup/kubernetes/gke.md index 9fb196430b5..c76fd9f7d2d 100644 --- a/hugo/content/en/security/application_security/setup/kubernetes/gke.md +++ b/hugo/content/en/security/application_security/setup/kubernetes/gke.md @@ -27,15 +27,15 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} -{{< callout url="#" btn_hidden="true" header="App and API Protection for GKE is in Preview" >}} -To try the Preview of App and API Protection for GKE, use the following setup instructions. +{{< callout url="#" btn_hidden="true" header="{{< prodname >}}App and API Protection{{< /prodname >}} for GKE is in Preview" >}} +To try the Preview of {{< prodname >}}App and API Protection{{< /prodname >}} for GKE, use the following setup instructions. {{< /callout >}} -You can enable Datadog [App and API Protection][1] on a Google Kubernetes Engine (GKE) Gateway to inspect and protect traffic at the cluster edge. The integration uses the GKE Gateway controller and the `GCPTrafficExtension` custom resource to attach the Datadog security processor to the GCP Cloud Load Balancer. +You can enable Datadog [{{< prodname >}}App and API Protection{{< /prodname >}}][1] on a Google Kubernetes Engine (GKE) Gateway to inspect and protect traffic at the cluster edge. The integration uses the GKE Gateway controller and the `GCPTrafficExtension` custom resource to attach the Datadog security processor to the GCP Cloud Load Balancer. ## Prerequisites @@ -47,7 +47,7 @@ You can enable Datadog [App and API Protection][1] on a Google Kubernetes Engine ## Enabling threat detection -To enable App and API Protection on a GKE Gateway, do the following: +To enable {{< prodname >}}App and API Protection{{< /prodname >}} on a GKE Gateway, do the following: 1. Deploy the Datadog security processor service in your cluster. 2. Create a `HealthCheckPolicy` so GCP can probe the security processor. @@ -55,7 +55,7 @@ To enable App and API Protection on a GKE Gateway, do the following: ### Deploy the Datadog security processor service -The Datadog security processor is a gRPC service that analyzes requests and responses for App and API Protection. Deploy it in the same namespace as your `Gateway`. The Docker image is available on the [Datadog Go tracer GitHub Registry][7]. +The Datadog security processor is a gRPC service that analyzes requests and responses for {{< prodname >}}App and API Protection{{< /prodname >}}. Deploy it in the same namespace as your `Gateway`. The Docker image is available on the [Datadog Go tracer GitHub Registry][7]. Example manifest (`datadog-aap-extproc-service.yaml`): diff --git a/hugo/content/en/security/application_security/setup/kubernetes/istio.md b/hugo/content/en/security/application_security/setup/kubernetes/istio.md index cd82e84a6f5..c2e4d22ef09 100644 --- a/hugo/content/en/security/application_security/setup/kubernetes/istio.md +++ b/hugo/content/en/security/application_security/setup/kubernetes/istio.md @@ -20,15 +20,15 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} -{{< callout url="#" btn_hidden="true" header="App and API Protection for Istio is in Preview" >}} -To try the preview of App and API Protection for Istio, use the following setup instructions. +{{< callout url="#" btn_hidden="true" header="{{< prodname >}}App and API Protection{{< /prodname >}} for Istio is in Preview" >}} +To try the preview of {{< prodname >}}App and API Protection{{< /prodname >}} for Istio, use the following setup instructions. {{< /callout >}} -You can enable App and API Protection within an Istio service mesh to inspect and protect traffic at the edge of your infrastructure. This works at the Istio Ingress Gateway or at the sidecar level. +You can enable {{< prodname >}}App and API Protection{{< /prodname >}} within an Istio service mesh to inspect and protect traffic at the edge of your infrastructure. This works at the Istio Ingress Gateway or at the sidecar level. ## Prerequisites @@ -38,13 +38,13 @@ Before you begin, verify that you have the following: - The [Datadog Agent is installed and configured][2] in your Kubernetes cluster. - Enable and configure [Remote Configuration][3] to enable blocking attackers through the Datadog UI. - Enable [APM][4] in the Agent. This allows the security processor service to send its own traces to the Agent. - - Optionally, enable the [Cluster Agent Admission Controller][5] to automatically inject the Datadog Agent host information to the App and API Protection security processor service. + - Optionally, enable the [Cluster Agent Admission Controller][5] to automatically inject the Datadog Agent host information to the {{< prodname >}}App and API Protection{{< /prodname >}} security processor service. ## Automated configuration with App and API Protection for Kubernetes

Automated configuration uses sidecar mode: the security processor runs as a container injected into your Istio gateway pods. No separate processor deployment is needed.

-

For external mode setup, see App and API Protection for Kubernetes.

+

For external mode setup, see {{< prodname >}}App and API Protection{{< /prodname >}} for Kubernetes.

### Setup @@ -113,7 +113,7 @@ For fine-grained control over specific gateways or sidecars, use the manual setu ### Step 1: Deploy the Datadog security processor service -This gRPC server receives requests and responses from Envoy for App and API Protection analysis. +This gRPC server receives requests and responses from Envoy for {{< prodname >}}App and API Protection{{< /prodname >}} analysis. Deploy it in a namespace accessible by your Istio Ingress Gateway. The Docker image is on the [Datadog Go tracer GitHub Registry][6]. @@ -339,7 +339,7 @@ spec: {{% /tab %}} {{% tab "Sidecar" %}} -This configuration applies App and API Protection to specific pods within your service mesh by targeting their Istio sidecar proxies. This allows for more granular control over which services are protected. +This configuration applies {{< prodname >}}App and API Protection{{< /prodname >}} to specific pods within your service mesh by targeting their Istio sidecar proxies. This allows for more granular control over which services are protected. Here is an example manifest (`datadog-aap-sidecar-filter.yaml`) that targets pods with the label `app: ` in the namespace ``. You must update these settings to match your specific application. diff --git a/hugo/content/en/security/application_security/setup/linux/_index.md b/hugo/content/en/security/application_security/setup/linux/_index.md index 29935e53dbc..74603c1bd90 100644 --- a/hugo/content/en/security/application_security/setup/linux/_index.md +++ b/hugo/content/en/security/application_security/setup/linux/_index.md @@ -21,11 +21,11 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} -Learn how to set up App and API Protection (AAP) on your Linux services by selecting the service's programming language. +Learn how to set up {{< prodname >}}App and API Protection{{< /prodname >}} (AAP) on your Linux services by selecting the service's programming language.

Are you missing your environment?

diff --git a/hugo/content/en/security/application_security/setup/macos/_index.md b/hugo/content/en/security/application_security/setup/macos/_index.md index 548eebc83ff..d1f825b740a 100644 --- a/hugo/content/en/security/application_security/setup/macos/_index.md +++ b/hugo/content/en/security/application_security/setup/macos/_index.md @@ -21,11 +21,11 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} -Learn how to set up App and API Protection (AAP) on your macOS services by selecting the service's programming language. +Learn how to set up {{< prodname >}}App and API Protection{{< /prodname >}} (AAP) on your macOS services by selecting the service's programming language.

Are you missing your environment?

diff --git a/hugo/content/en/security/application_security/setup/nginx.md b/hugo/content/en/security/application_security/setup/nginx.md index a49fccaf7f4..5603e8d4e62 100644 --- a/hugo/content/en/security/application_security/setup/nginx.md +++ b/hugo/content/en/security/application_security/setup/nginx.md @@ -6,7 +6,7 @@ code_lang_weight: 50 {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} diff --git a/hugo/content/en/security/application_security/setup/nginx/_index.md b/hugo/content/en/security/application_security/setup/nginx/_index.md index 1c6667a860b..dc4b69c0f5e 100644 --- a/hugo/content/en/security/application_security/setup/nginx/_index.md +++ b/hugo/content/en/security/application_security/setup/nginx/_index.md @@ -17,14 +17,14 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} {{< partial name="app_and_api_protection/callout.html" >}} ## Overview -Learn how to set up App and API Protection (AAP) on your NGINX proxy by selecting the integration that suits you best. +Learn how to set up {{< prodname >}}App and API Protection{{< /prodname >}} (AAP) on your NGINX proxy by selecting the integration that suits you best. ## Environments diff --git a/hugo/content/en/security/application_security/setup/nginx/ingress-controller.md b/hugo/content/en/security/application_security/setup/nginx/ingress-controller.md index eae890378b1..1ab048a54bd 100644 --- a/hugo/content/en/security/application_security/setup/nginx/ingress-controller.md +++ b/hugo/content/en/security/application_security/setup/nginx/ingress-controller.md @@ -17,7 +17,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -29,7 +29,7 @@ App and API Protection is in Preview on Datadog Government site US1-FED. that uses NGINX as a reverse proxy and load balancer. In a Kubernetes cluster, external access is restricted by default for security reasons. An ingress controller uses rules to control how external traffic may reach your services. -You can enable [App and API Protection][10] for your ingress-nginx controller to inspect and protect traffic at the edge of your cluster. Datadog supports two setup methods: +You can enable [{{< prodname >}}App and API Protection{{< /prodname >}}][10] for your ingress-nginx controller to inspect and protect traffic at the edge of your cluster. Datadog supports two setup methods: - **Automated configuration** (recommended): the Datadog Cluster Agent injects the `nginx-datadog` module into your ingress-nginx controller pods. - **Manual configuration**: you add a Datadog init container and NGINX configuration snippets yourself. @@ -101,9 +101,9 @@ After you enable automatic configuration, the Datadog Cluster Agent: - Detects your ingress-nginx controller pods - Injects the `nginx-datadog` module into the controller -- Configures the controller to load the module and apply App and API Protection +- Configures the controller to load the module and apply {{< prodname >}}App and API Protection{{< /prodname >}} -You can turn App and API Protection on or off through [Remote Configuration][8] without changing this setup. +You can turn {{< prodname >}}App and API Protection{{< /prodname >}} on or off through [Remote Configuration][8] without changing this setup. For configuration options, see [App and API Protection for Kubernetes][9]. diff --git a/hugo/content/en/security/application_security/setup/nginx/linux.md b/hugo/content/en/security/application_security/setup/nginx/linux.md index 717a7863b28..7a1b99e5ca5 100644 --- a/hugo/content/en/security/application_security/setup/nginx/linux.md +++ b/hugo/content/en/security/application_security/setup/nginx/linux.md @@ -25,7 +25,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -71,10 +71,10 @@ The Datadog nginx tracing module has experimental support for threat detection a ## Using App and API Protection without APM tracing -If you want to use App and API Protection without APM tracing functionality, you can deploy with tracing disabled: +If you want to use {{< prodname >}}App and API Protection{{< /prodname >}} without APM tracing functionality, you can deploy with tracing disabled: 1. Configure your SDK with the `DD_APM_TRACING_ENABLED=false` environment variable in addition to the `DD_APPSEC_ENABLED=true` environment variable. -2. This configuration will reduce the amount of APM data sent to Datadog to the minimum required by App and API Protection products. +2. This configuration will reduce the amount of APM data sent to Datadog to the minimum required by {{< prodname >}}App and API Protection{{< /prodname >}} products. For more details, see [Standalone App and API Protection][7]. diff --git a/hugo/content/en/security/application_security/setup/nodejs/_index.md b/hugo/content/en/security/application_security/setup/nodejs/_index.md index 3e0f4ef80af..f6763215c2b 100644 --- a/hugo/content/en/security/application_security/setup/nodejs/_index.md +++ b/hugo/content/en/security/application_security/setup/nodejs/_index.md @@ -26,7 +26,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} diff --git a/hugo/content/en/security/application_security/setup/nodejs/aws-fargate.md b/hugo/content/en/security/application_security/setup/nodejs/aws-fargate.md index 0e300de083f..bb6327ba039 100644 --- a/hugo/content/en/security/application_security/setup/nodejs/aws-fargate.md +++ b/hugo/content/en/security/application_security/setup/nodejs/aws-fargate.md @@ -17,7 +17,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -87,7 +87,7 @@ CMD ["node", "--require", "dd-trace/init", "app.js"] {{% collapse-content title="APM Tracing Enabled" level="h4" %}} -Update your task definition to include the Node.js application container with App and API Protection configuration: +Update your task definition to include the Node.js application container with {{< prodname >}}App and API Protection{{< /prodname >}} configuration: ```json { @@ -117,9 +117,9 @@ Update your task definition to include the Node.js application container with Ap {{% /collapse-content %}} {{% collapse-content title="APM Tracing Disabled" level="h4" %}} -To disable APM tracing while keeping App and API Protection enabled, you must set the APM tracing variable to false. +To disable APM tracing while keeping {{< prodname >}}App and API Protection{{< /prodname >}} enabled, you must set the APM tracing variable to false. -Update your task definition to include the Node.js application container with App and API Protection configuration: +Update your task definition to include the Node.js application container with {{< prodname >}}App and API Protection{{< /prodname >}} configuration: ```json { @@ -165,7 +165,7 @@ aws ecs run-task --cluster your-cluster --task-definition your-task-definition ## Troubleshooting -If you encounter issues while setting up App and API Protection for your Node.js application, see the [Node.js App and API Protection troubleshooting guide][2]. +If you encounter issues while setting up {{< prodname >}}App and API Protection{{< /prodname >}} for your Node.js application, see the [Node.js App and API Protection troubleshooting guide][2]. ## Further Reading diff --git a/hugo/content/en/security/application_security/setup/nodejs/docker.md b/hugo/content/en/security/application_security/setup/nodejs/docker.md index 20356881a7b..22d77b4b977 100644 --- a/hugo/content/en/security/application_security/setup/nodejs/docker.md +++ b/hugo/content/en/security/application_security/setup/nodejs/docker.md @@ -17,7 +17,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -72,7 +72,7 @@ CMD ["node", "--require", "dd-trace/init", "app.js"] {{% /collapse-content %}} {{% collapse-content title="APM Tracing Disabled" level="h4" %}} -To disable APM tracing while keeping App and API Protection enabled, you must set the APM tracing variable to false. +To disable APM tracing while keeping {{< prodname >}}App and API Protection{{< /prodname >}} enabled, you must set the APM tracing variable to false. Add the Datadog Node.js library to your Dockerfile and configure environment variables: @@ -119,7 +119,7 @@ docker run -d \ ## Troubleshooting -If you encounter issues while setting up App and API Protection for your Node.js application, see the [Node.js App and API Protection troubleshooting guide][2]. +If you encounter issues while setting up {{< prodname >}}App and API Protection{{< /prodname >}} for your Node.js application, see the [Node.js App and API Protection troubleshooting guide][2]. ## Further Reading diff --git a/hugo/content/en/security/application_security/setup/nodejs/kubernetes.md b/hugo/content/en/security/application_security/setup/nodejs/kubernetes.md index ecd4e5418a2..f4d7c185495 100644 --- a/hugo/content/en/security/application_security/setup/nodejs/kubernetes.md +++ b/hugo/content/en/security/application_security/setup/nodejs/kubernetes.md @@ -17,7 +17,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -89,7 +89,7 @@ spec: {{% /collapse-content %}} {{% collapse-content title="APM Tracing Disabled" level="h4" %}} -To disable APM tracing while keeping App and API Protection enabled, you must set the APM tracing variable to false. +To disable APM tracing while keeping {{< prodname >}}App and API Protection{{< /prodname >}} enabled, you must set the APM tracing variable to false. Update your Kubernetes deployment to include the required environment variables: @@ -129,7 +129,7 @@ kubectl apply -f your-deployment.yaml ## Troubleshooting -If you encounter issues while setting up App and API Protection for your Node.js application, see the [Node.js App and API Protection troubleshooting guide][2]. +If you encounter issues while setting up {{< prodname >}}App and API Protection{{< /prodname >}} for your Node.js application, see the [Node.js App and API Protection troubleshooting guide][2]. ## Further Reading diff --git a/hugo/content/en/security/application_security/setup/nodejs/linux.md b/hugo/content/en/security/application_security/setup/nodejs/linux.md index 7e87fc8da7d..4ae0e164943 100644 --- a/hugo/content/en/security/application_security/setup/nodejs/linux.md +++ b/hugo/content/en/security/application_security/setup/nodejs/linux.md @@ -17,7 +17,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -53,7 +53,7 @@ npm install dd-trace {{% collapse-content title="APM Tracing Enabled" level="h4" %}} -Start your Node.js application with the Datadog library and App and API Protection enabled: +Start your Node.js application with the Datadog library and {{< prodname >}}App and API Protection{{< /prodname >}} enabled: ```bash DD_APPSEC_ENABLED=true DD_SERVICE= DD_ENV= node --require dd-trace/init app.js @@ -62,9 +62,9 @@ DD_APPSEC_ENABLED=true DD_SERVICE= DD_ENV= {{% /collapse-content %}} {{% collapse-content title="APM Tracing Disabled" level="h4" %}} -To disable APM tracing while keeping App and API Protection enabled, you must set the APM tracing variable to false. +To disable APM tracing while keeping {{< prodname >}}App and API Protection{{< /prodname >}} enabled, you must set the APM tracing variable to false. -Start your Node.js application with the Datadog library and App and API Protection enabled: +Start your Node.js application with the Datadog library and {{< prodname >}}App and API Protection{{< /prodname >}} enabled: ```bash DD_APPSEC_ENABLED=true DD_APM_TRACING_ENABLED=false DD_SERVICE= DD_ENV= node --require dd-trace/init app.js @@ -80,7 +80,7 @@ Start your Node.js application with the configured settings. ## Troubleshooting -If you encounter issues while setting up App and API Protection for your Node.js application, see the [Node.js App and API Protection troubleshooting guide][2]. +If you encounter issues while setting up {{< prodname >}}App and API Protection{{< /prodname >}} for your Node.js application, see the [Node.js App and API Protection troubleshooting guide][2]. ## Further Reading diff --git a/hugo/content/en/security/application_security/setup/nodejs/macos.md b/hugo/content/en/security/application_security/setup/nodejs/macos.md index bd895482dd9..fc44a21e842 100644 --- a/hugo/content/en/security/application_security/setup/nodejs/macos.md +++ b/hugo/content/en/security/application_security/setup/nodejs/macos.md @@ -17,7 +17,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -51,7 +51,7 @@ npm install dd-trace {{% collapse-content title="APM Tracing Enabled" level="h4" %}} -Start your Node.js application with the Datadog library and App and API Protection enabled: +Start your Node.js application with the Datadog library and {{< prodname >}}App and API Protection{{< /prodname >}} enabled: ```bash DD_APPSEC_ENABLED=true DD_SERVICE= DD_ENV= node --require dd-trace/init app.js @@ -60,9 +60,9 @@ DD_APPSEC_ENABLED=true DD_SERVICE= DD_ENV= {{% /collapse-content %}} {{% collapse-content title="APM Tracing Disabled" level="h4" %}} -To disable APM tracing while keeping App and API Protection enabled, you must set the APM tracing variable to false. +To disable APM tracing while keeping {{< prodname >}}App and API Protection{{< /prodname >}} enabled, you must set the APM tracing variable to false. -Start your Node.js application with the Datadog library and App and API Protection enabled: +Start your Node.js application with the Datadog library and {{< prodname >}}App and API Protection{{< /prodname >}} enabled: ```bash DD_APPSEC_ENABLED=true DD_APM_TRACING_ENABLED=false DD_SERVICE= DD_ENV= node --require dd-trace/init app.js @@ -78,7 +78,7 @@ Start your Node.js application with the configured settings. ## Troubleshooting -If you encounter issues while setting up App and API Protection for your Node.js application, see the [Node.js App and API Protection troubleshooting guide][2]. +If you encounter issues while setting up {{< prodname >}}App and API Protection{{< /prodname >}} for your Node.js application, see the [Node.js App and API Protection troubleshooting guide][2]. ## Further Reading diff --git a/hugo/content/en/security/application_security/setup/nodejs/troubleshooting.md b/hugo/content/en/security/application_security/setup/nodejs/troubleshooting.md index ecf84fd7a2a..a540e190696 100644 --- a/hugo/content/en/security/application_security/setup/nodejs/troubleshooting.md +++ b/hugo/content/en/security/application_security/setup/nodejs/troubleshooting.md @@ -4,7 +4,7 @@ title: Troubleshooting Node.js App and API Protection {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} diff --git a/hugo/content/en/security/application_security/setup/nodejs/windows.md b/hugo/content/en/security/application_security/setup/nodejs/windows.md index 3dcbaddadf7..c8fff6f81a4 100644 --- a/hugo/content/en/security/application_security/setup/nodejs/windows.md +++ b/hugo/content/en/security/application_security/setup/nodejs/windows.md @@ -17,7 +17,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -50,7 +50,7 @@ npm install dd-trace {{% collapse-content title="APM Tracing Enabled" level="h4" %}} -Start your Node.js application with the Datadog library and App and API Protection enabled: +Start your Node.js application with the Datadog library and {{< prodname >}}App and API Protection{{< /prodname >}} enabled: ```powershell $env:DD_APPSEC_ENABLED="true" @@ -63,9 +63,9 @@ node --require dd-trace/init app.js {{% /collapse-content %}} {{% collapse-content title="APM Tracing Disabled" level="h4" %}} -To disable APM tracing while keeping App and API Protection enabled, you must set the APM tracing variable to false. +To disable APM tracing while keeping {{< prodname >}}App and API Protection{{< /prodname >}} enabled, you must set the APM tracing variable to false. -Start your Node.js application with the Datadog library and App and API Protection enabled: +Start your Node.js application with the Datadog library and {{< prodname >}}App and API Protection{{< /prodname >}} enabled: ```powershell $env:DD_APPSEC_ENABLED="true" @@ -86,7 +86,7 @@ Start your Node.js application with the configured settings. ## Troubleshooting -If you encounter issues while setting up App and API Protection for your Node.js application, see the [Node.js App and API Protection troubleshooting guide][2]. +If you encounter issues while setting up {{< prodname >}}App and API Protection{{< /prodname >}} for your Node.js application, see the [Node.js App and API Protection troubleshooting guide][2]. ## Further Reading diff --git a/hugo/content/en/security/application_security/setup/php/_index.md b/hugo/content/en/security/application_security/setup/php/_index.md index f75d357358a..8b8af8c2748 100644 --- a/hugo/content/en/security/application_security/setup/php/_index.md +++ b/hugo/content/en/security/application_security/setup/php/_index.md @@ -14,7 +14,7 @@ aliases: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} diff --git a/hugo/content/en/security/application_security/setup/php/aws-fargate.md b/hugo/content/en/security/application_security/setup/php/aws-fargate.md index 3eb5a04445b..d5f98d33e5a 100644 --- a/hugo/content/en/security/application_security/setup/php/aws-fargate.md +++ b/hugo/content/en/security/application_security/setup/php/aws-fargate.md @@ -17,7 +17,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -88,7 +88,7 @@ ENV DD_ENV= {{% collapse-content title="APM Tracing Enabled" level="h4" %}} -Update your task definition to include the PHP application container with App and API Protection configuration: +Update your task definition to include the PHP application container with {{< prodname >}}App and API Protection{{< /prodname >}} configuration: ```json { @@ -122,9 +122,9 @@ Update your task definition to include the PHP application container with App an {{% /collapse-content %}} {{% collapse-content title="APM Tracing Disabled" level="h4" %}} -To disable APM tracing while keeping App and API Protection enabled, you must set the APM tracing variable to false. +To disable APM tracing while keeping {{< prodname >}}App and API Protection{{< /prodname >}} enabled, you must set the APM tracing variable to false. -Update your task definition to include the PHP application container with App and API Protection configuration: +Update your task definition to include the PHP application container with {{< prodname >}}App and API Protection{{< /prodname >}} configuration: ```json { @@ -174,7 +174,7 @@ aws ecs run-task --cluster your-cluster --task-definition your-task-definition ## Troubleshooting -If you encounter issues while setting up App and API Protection for your PHP application, see the [PHP App and API Protection troubleshooting guide][2]. +If you encounter issues while setting up {{< prodname >}}App and API Protection{{< /prodname >}} for your PHP application, see the [PHP App and API Protection troubleshooting guide][2]. ## Further reading diff --git a/hugo/content/en/security/application_security/setup/php/docker.md b/hugo/content/en/security/application_security/setup/php/docker.md index 1db34a57b81..3b51d5a54a6 100644 --- a/hugo/content/en/security/application_security/setup/php/docker.md +++ b/hugo/content/en/security/application_security/setup/php/docker.md @@ -17,7 +17,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -61,7 +61,7 @@ ENV DD_ENV= {{% /collapse-content %}} {{% collapse-content title="APM Tracing Disabled" level="h4" %}} -To disable APM tracing while keeping App and API Protection enabled, you must set the APM tracing variable to false. +To disable APM tracing while keeping {{< prodname >}}App and API Protection{{< /prodname >}} enabled, you must set the APM tracing variable to false. Add the following to your Dockerfile: @@ -97,7 +97,7 @@ docker run -d \ ## Troubleshooting -If you encounter issues while setting up App and API Protection for your PHP application, see the [PHP App and API Protection troubleshooting guide][2]. +If you encounter issues while setting up {{< prodname >}}App and API Protection{{< /prodname >}} for your PHP application, see the [PHP App and API Protection troubleshooting guide][2]. ## Further Reading diff --git a/hugo/content/en/security/application_security/setup/php/kubernetes.md b/hugo/content/en/security/application_security/setup/php/kubernetes.md index f9c19b885a1..69f03fe05d6 100644 --- a/hugo/content/en/security/application_security/setup/php/kubernetes.md +++ b/hugo/content/en/security/application_security/setup/php/kubernetes.md @@ -17,7 +17,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -56,7 +56,7 @@ Configure and run your service with Datadog: {{% collapse-content title="APM Tracing Enabled" level="h4" %}} -Start your PHP application with App and API Protection enabled using environment variables: +Start your PHP application with {{< prodname >}}App and API Protection{{< /prodname >}} enabled using environment variables: ```yaml apiVersion: apps/v1 @@ -81,9 +81,9 @@ spec: {{% /collapse-content %}} {{% collapse-content title="APM Tracing Disabled" level="h4" %}} -To disable APM tracing while keeping App and API Protection enabled, you must set the APM tracing variable to false. +To disable APM tracing while keeping {{< prodname >}}App and API Protection{{< /prodname >}} enabled, you must set the APM tracing variable to false. -Start your PHP application with App and API Protection enabled using environment variables: +Start your PHP application with {{< prodname >}}App and API Protection{{< /prodname >}} enabled using environment variables: ```yaml apiVersion: apps/v1 @@ -121,7 +121,7 @@ kubectl apply -f your-deployment.yaml ## Troubleshooting -If you encounter issues while setting up App and API Protection for your PHP application, see the [PHP App and API Protection troubleshooting guide][2]. +If you encounter issues while setting up {{< prodname >}}App and API Protection{{< /prodname >}} for your PHP application, see the [PHP App and API Protection troubleshooting guide][2]. ## Further Reading diff --git a/hugo/content/en/security/application_security/setup/php/linux.md b/hugo/content/en/security/application_security/setup/php/linux.md index ec22527702d..2fc2a694023 100644 --- a/hugo/content/en/security/application_security/setup/php/linux.md +++ b/hugo/content/en/security/application_security/setup/php/linux.md @@ -17,7 +17,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -67,7 +67,7 @@ export DD_ENV= {{% /collapse-content %}} {{% collapse-content title="APM Tracing Disabled" level="h4" %}} -To disable APM tracing while keeping App and API Protection enabled, you must set the APM tracing variable to false. +To disable APM tracing while keeping {{< prodname >}}App and API Protection{{< /prodname >}} enabled, you must set the APM tracing variable to false. Set the required environment variables and start your PHP application: @@ -88,7 +88,7 @@ Start your PHP application with the settings described above. ## Troubleshooting -If you encounter issues while setting up App and API Protection for your PHP application, see the [PHP App and API Protection troubleshooting guide][2]. +If you encounter issues while setting up {{< prodname >}}App and API Protection{{< /prodname >}} for your PHP application, see the [PHP App and API Protection troubleshooting guide][2]. ## Further Reading diff --git a/hugo/content/en/security/application_security/setup/php/troubleshooting.md b/hugo/content/en/security/application_security/setup/php/troubleshooting.md index 63b81bb3cfe..2365d22cd8b 100644 --- a/hugo/content/en/security/application_security/setup/php/troubleshooting.md +++ b/hugo/content/en/security/application_security/setup/php/troubleshooting.md @@ -14,7 +14,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -149,7 +149,7 @@ datadog.appsec.helper_runtime_path = // ### Confirm tracer versions are updated -See the App and API Protection setup documentation to validate that you are using the right tracer version. These minimum versions are required to start sending telemetry data that includes library information. +See the {{< prodname >}}App and API Protection{{< /prodname >}} setup documentation to validate that you are using the right tracer version. These minimum versions are required to start sending telemetry data that includes library information. ### Ensure the communication of telemetry data diff --git a/hugo/content/en/security/application_security/setup/python/_index.md b/hugo/content/en/security/application_security/setup/python/_index.md index 6d8ca8d316b..0db4dadaac5 100644 --- a/hugo/content/en/security/application_security/setup/python/_index.md +++ b/hugo/content/en/security/application_security/setup/python/_index.md @@ -27,7 +27,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} diff --git a/hugo/content/en/security/application_security/setup/python/aws-fargate.md b/hugo/content/en/security/application_security/setup/python/aws-fargate.md index 3f68197d75e..9c2c22e1b48 100644 --- a/hugo/content/en/security/application_security/setup/python/aws-fargate.md +++ b/hugo/content/en/security/application_security/setup/python/aws-fargate.md @@ -17,7 +17,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -77,7 +77,7 @@ Configure and run your service with Datadog: {{% collapse-content title="APM Tracing Enabled" level="h4" %}} -Update your task definition to include the Python agent and App and API Protection configuration: +Update your task definition to include the Python agent and {{< prodname >}}App and API Protection{{< /prodname >}} configuration: ```json { @@ -112,9 +112,9 @@ Update your task definition to include the Python agent and App and API Protecti {{% /collapse-content %}} {{% collapse-content title="APM Tracing Disabled" level="h4" %}} -To disable APM tracing while keeping App and API Protection enabled, you must set the APM tracing variable to false. +To disable APM tracing while keeping {{< prodname >}}App and API Protection{{< /prodname >}} enabled, you must set the APM tracing variable to false. -Update your task definition to include the Python agent and App and API Protection configuration with APM tracing disabled: +Update your task definition to include the Python agent and {{< prodname >}}App and API Protection{{< /prodname >}} configuration with APM tracing disabled: ```json { @@ -165,7 +165,7 @@ aws ecs run-task --cluster your-cluster --task-definition your-task-definition ## Troubleshooting -If you encounter issues while setting up App and API Protection for your Python application, see the [Python App and API Protection troubleshooting guide][2]. +If you encounter issues while setting up {{< prodname >}}App and API Protection{{< /prodname >}} for your Python application, see the [Python App and API Protection troubleshooting guide][2]. ## Further Reading diff --git a/hugo/content/en/security/application_security/setup/python/docker.md b/hugo/content/en/security/application_security/setup/python/docker.md index ac316beba83..15bcb4b6592 100644 --- a/hugo/content/en/security/application_security/setup/python/docker.md +++ b/hugo/content/en/security/application_security/setup/python/docker.md @@ -17,7 +17,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -63,7 +63,7 @@ CMD ["ddtrace-run", "python", "app.py"] {{% /collapse-content %}} {{% collapse-content title="APM Tracing Disabled" level="h4" %}} -To disable APM tracing while keeping App and API Protection enabled, you must set the APM tracing variable to false. +To disable APM tracing while keeping {{< prodname >}}App and API Protection{{< /prodname >}} enabled, you must set the APM tracing variable to false. Add the following environment variables to your Dockerfile: @@ -100,7 +100,7 @@ docker run -d \ ## Troubleshooting -If you encounter issues while setting up App and API Protection for your Python application, see the [Python App and API Protection troubleshooting guide][2]. +If you encounter issues while setting up {{< prodname >}}App and API Protection{{< /prodname >}} for your Python application, see the [Python App and API Protection troubleshooting guide][2]. ## Further Reading diff --git a/hugo/content/en/security/application_security/setup/python/kubernetes.md b/hugo/content/en/security/application_security/setup/python/kubernetes.md index f07e8b2bf47..98b8a793c92 100644 --- a/hugo/content/en/security/application_security/setup/python/kubernetes.md +++ b/hugo/content/en/security/application_security/setup/python/kubernetes.md @@ -17,7 +17,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -55,7 +55,7 @@ Configure and run your service with Datadog: {{% collapse-content title="APM Tracing Enabled" level="h4" %}} -Start your Python application with App and API Protection enabled using environment variables: +Start your Python application with {{< prodname >}}App and API Protection{{< /prodname >}} enabled using environment variables: ```yaml apiVersion: apps/v1 @@ -81,9 +81,9 @@ spec: {{% /collapse-content %}} {{% collapse-content title="APM Tracing Disabled" level="h4" %}} -To disable APM tracing while keeping App and API Protection enabled, you must set the APM tracing variable to false. +To disable APM tracing while keeping {{< prodname >}}App and API Protection{{< /prodname >}} enabled, you must set the APM tracing variable to false. -Start your Python application with App and API Protection enabled using environment variables: +Start your Python application with {{< prodname >}}App and API Protection{{< /prodname >}} enabled using environment variables: ```yaml apiVersion: apps/v1 @@ -122,7 +122,7 @@ kubectl apply -f your-deployment.yaml ## Troubleshooting -If you encounter issues while setting up App and API Protection for your Python application, see the [Python App and API Protection troubleshooting guide][2]. +If you encounter issues while setting up {{< prodname >}}App and API Protection{{< /prodname >}} for your Python application, see the [Python App and API Protection troubleshooting guide][2]. ## Further Reading diff --git a/hugo/content/en/security/application_security/setup/python/linux.md b/hugo/content/en/security/application_security/setup/python/linux.md index 11875d14f3a..d312e380a93 100644 --- a/hugo/content/en/security/application_security/setup/python/linux.md +++ b/hugo/content/en/security/application_security/setup/python/linux.md @@ -17,7 +17,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -68,7 +68,7 @@ ddtrace-run python app.py {{% /collapse-content %}} {{% collapse-content title="APM Tracing Disabled" level="h4" %}} -To disable APM tracing while keeping App and API Protection enabled, you must set the APM tracing variable to false. +To disable APM tracing while keeping {{< prodname >}}App and API Protection{{< /prodname >}} enabled, you must set the APM tracing variable to false. Set the required environment variables and start your Python application: @@ -91,7 +91,7 @@ Start your Python application with the settings described above. ## Troubleshooting -If you encounter issues while setting up App and API Protection for your Python application, see the [Python App and API Protection troubleshooting guide][2]. +If you encounter issues while setting up {{< prodname >}}App and API Protection{{< /prodname >}} for your Python application, see the [Python App and API Protection troubleshooting guide][2]. ## Further Reading diff --git a/hugo/content/en/security/application_security/setup/python/macos.md b/hugo/content/en/security/application_security/setup/python/macos.md index e789e999916..8de0225856b 100644 --- a/hugo/content/en/security/application_security/setup/python/macos.md +++ b/hugo/content/en/security/application_security/setup/python/macos.md @@ -17,7 +17,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -66,7 +66,7 @@ ddtrace-run python app.py {{% /collapse-content %}} {{% collapse-content title="APM Tracing Disabled" level="h4" %}} -To disable APM tracing while keeping App and API Protection enabled, you must set the APM tracing variable to false. +To disable APM tracing while keeping {{< prodname >}}App and API Protection{{< /prodname >}} enabled, you must set the APM tracing variable to false. Set the required environment variables and start your Python application: @@ -89,7 +89,7 @@ Start your Python application with the configured settings. ## Troubleshooting -If you encounter issues while setting up App and API Protection for your Python application, see the [Python App and API Protection troubleshooting guide][2]. +If you encounter issues while setting up {{< prodname >}}App and API Protection{{< /prodname >}} for your Python application, see the [Python App and API Protection troubleshooting guide][2]. ## Further Reading diff --git a/hugo/content/en/security/application_security/setup/python/troubleshooting.md b/hugo/content/en/security/application_security/setup/python/troubleshooting.md index 2b7a33e047b..83486936e24 100644 --- a/hugo/content/en/security/application_security/setup/python/troubleshooting.md +++ b/hugo/content/en/security/application_security/setup/python/troubleshooting.md @@ -14,7 +14,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} diff --git a/hugo/content/en/security/application_security/setup/python/windows.md b/hugo/content/en/security/application_security/setup/python/windows.md index 51a701907f7..f6a5b7411be 100644 --- a/hugo/content/en/security/application_security/setup/python/windows.md +++ b/hugo/content/en/security/application_security/setup/python/windows.md @@ -17,7 +17,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -63,7 +63,7 @@ ddtrace-run python app.py {{% /collapse-content %}} {{% collapse-content title="APM Tracing Disabled" level="h4" %}} -To disable APM tracing while keeping App and API Protection enabled, you must set the APM tracing variable to false. +To disable APM tracing while keeping {{< prodname >}}App and API Protection{{< /prodname >}} enabled, you must set the APM tracing variable to false. Set the required environment variables and start your Python application: @@ -86,7 +86,7 @@ Start your Python application with the configured settings. ## Troubleshooting -If you encounter issues while setting up App and API Protection for your Python application, see the [Python App and API Protection troubleshooting guide][2]. +If you encounter issues while setting up {{< prodname >}}App and API Protection{{< /prodname >}} for your Python application, see the [Python App and API Protection troubleshooting guide][2]. ## Further Reading diff --git a/hugo/content/en/security/application_security/setup/ruby/_index.md b/hugo/content/en/security/application_security/setup/ruby/_index.md index 495e14991ae..bff64ac6628 100644 --- a/hugo/content/en/security/application_security/setup/ruby/_index.md +++ b/hugo/content/en/security/application_security/setup/ruby/_index.md @@ -28,7 +28,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} diff --git a/hugo/content/en/security/application_security/setup/ruby/aws-fargate.md b/hugo/content/en/security/application_security/setup/ruby/aws-fargate.md index aa245373bba..49e217620d1 100644 --- a/hugo/content/en/security/application_security/setup/ruby/aws-fargate.md +++ b/hugo/content/en/security/application_security/setup/ruby/aws-fargate.md @@ -17,7 +17,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -105,7 +105,7 @@ Add the `datadog` gem to your Gemfile and require auto-instrumentation: gem 'datadog', '~> 2.0', require: 'datadog/auto_instrument' ``` -Update your task definition to include App and API Protection configuration: +Update your task definition to include {{< prodname >}}App and API Protection{{< /prodname >}} configuration: ```json { @@ -146,7 +146,7 @@ Update your task definition to include App and API Protection configuration: {{% collapse-content title="APM Tracing Disabled" level="h4" %}} -To disable APM tracing while keeping App and API Protection enabled, you must set the APM tracing configuration to false. +To disable APM tracing while keeping {{< prodname >}}App and API Protection{{< /prodname >}} enabled, you must set the APM tracing configuration to false. {{< tabs >}} {{% tab "Configuration file" %}} @@ -189,7 +189,7 @@ Add the `datadog` gem to your Gemfile and require auto-instrumentation: gem 'datadog', '~> 2.0', require: 'datadog/auto_instrument' ``` -Update your task definition to include App and API Protection configuration with APM tracing disabled: +Update your task definition to include {{< prodname >}}App and API Protection{{< /prodname >}} configuration with APM tracing disabled: ```json { @@ -243,7 +243,7 @@ aws ecs run-task --cluster your-cluster --task-definition your-task-definition ## 4. Verify setup -To verify that App and API Protection is working correctly: +To verify that {{< prodname >}}App and API Protection{{< /prodname >}} is working correctly: 1. Send some traffic to your application. 2. Check the [App and API Protection Service Inventory](https://app.datadoghq.com/security/appsec/inventory/services) in Datadog. @@ -251,7 +251,7 @@ To verify that App and API Protection is working correctly: ## Troubleshooting -If you encounter issues while setting up App and API Protection for your Ruby application, see the [Ruby App and API Protection troubleshooting guide][2]. +If you encounter issues while setting up {{< prodname >}}App and API Protection{{< /prodname >}} for your Ruby application, see the [Ruby App and API Protection troubleshooting guide][2]. ## Further Reading diff --git a/hugo/content/en/security/application_security/setup/ruby/docker.md b/hugo/content/en/security/application_security/setup/ruby/docker.md index f6083d36326..b752ace6163 100644 --- a/hugo/content/en/security/application_security/setup/ruby/docker.md +++ b/hugo/content/en/security/application_security/setup/ruby/docker.md @@ -17,7 +17,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -96,7 +96,7 @@ ENV DD_ENV= {{% collapse-content title="APM Tracing Disabled" level="h4" %}} -To disable APM tracing while keeping App and API Protection enabled, you must set the APM tracing configuration to false. +To disable APM tracing while keeping {{< prodname >}}App and API Protection{{< /prodname >}} enabled, you must set the APM tracing configuration to false. {{< tabs >}} {{% tab "Configuration file" %}} @@ -162,7 +162,7 @@ When running your container, make sure to connect it to the same Docker network ## 4. Verify setup -To verify that App and API Protection is working correctly: +To verify that {{< prodname >}}App and API Protection{{< /prodname >}} is working correctly: 1. Send some traffic to your application. 2. Check the [App and API Protection Service Inventory](https://app.datadoghq.com/security/appsec/inventory/services) in Datadog. @@ -170,7 +170,7 @@ To verify that App and API Protection is working correctly: ## Troubleshooting -If you encounter issues while setting up App and API Protection for your Ruby application, see the [Ruby App and API Protection troubleshooting guide][2]. +If you encounter issues while setting up {{< prodname >}}App and API Protection{{< /prodname >}} for your Ruby application, see the [Ruby App and API Protection troubleshooting guide][2]. ## Further Reading diff --git a/hugo/content/en/security/application_security/setup/ruby/kubernetes.md b/hugo/content/en/security/application_security/setup/ruby/kubernetes.md index ff097634167..6ac7b683d78 100644 --- a/hugo/content/en/security/application_security/setup/ruby/kubernetes.md +++ b/hugo/content/en/security/application_security/setup/ruby/kubernetes.md @@ -17,7 +17,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -115,7 +115,7 @@ spec: {{% collapse-content title="APM Tracing Disabled" level="h4" %}} -To disable APM tracing while keeping App and API Protection enabled, you must set the APM tracing configuration to false. +To disable APM tracing while keeping {{< prodname >}}App and API Protection{{< /prodname >}} enabled, you must set the APM tracing configuration to false. {{< tabs >}} {{% tab "Configuration file" %}} @@ -200,7 +200,7 @@ kubectl apply -f your-deployment.yaml ## 4. Verify setup -To verify that App and API Protection is working correctly: +To verify that {{< prodname >}}App and API Protection{{< /prodname >}} is working correctly: 1. Send some traffic to your application. 2. Check the [App and API Protection Service Inventory](https://app.datadoghq.com/security/appsec/inventory/services) in Datadog. @@ -208,7 +208,7 @@ To verify that App and API Protection is working correctly: ## Troubleshooting -If you encounter issues while setting up App and API Protection for your Ruby application, see the [Ruby App and API Protection troubleshooting guide][2]. +If you encounter issues while setting up {{< prodname >}}App and API Protection{{< /prodname >}} for your Ruby application, see the [Ruby App and API Protection troubleshooting guide][2]. ## Further Reading diff --git a/hugo/content/en/security/application_security/setup/ruby/linux.md b/hugo/content/en/security/application_security/setup/ruby/linux.md index bca8704066a..71837830989 100644 --- a/hugo/content/en/security/application_security/setup/ruby/linux.md +++ b/hugo/content/en/security/application_security/setup/ruby/linux.md @@ -17,7 +17,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -107,7 +107,7 @@ export DD_ENV= {{% collapse-content title="APM Tracing Disabled" level="h4" %}} -To disable APM tracing while keeping App and API Protection enabled, you must set the APM tracing configuration to false. +To disable APM tracing while keeping {{< prodname >}}App and API Protection{{< /prodname >}} enabled, you must set the APM tracing configuration to false. {{< tabs >}} {{% tab "Configuration file" %}} @@ -180,7 +180,7 @@ Start your application with above settings. ## 4. Verify setup -To verify that App and API Protection is working correctly: +To verify that {{< prodname >}}App and API Protection{{< /prodname >}} is working correctly: 1. Send some traffic to your application. 2. Check the [App and API Protection Service Inventory](https://app.datadoghq.com/security/appsec/inventory/services) in Datadog. @@ -188,7 +188,7 @@ To verify that App and API Protection is working correctly: ## Troubleshooting -If you encounter issues while setting up App and API Protection for your Ruby application, see the [Ruby App and API Protection troubleshooting guide][2]. +If you encounter issues while setting up {{< prodname >}}App and API Protection{{< /prodname >}} for your Ruby application, see the [Ruby App and API Protection troubleshooting guide][2]. ## Further Reading diff --git a/hugo/content/en/security/application_security/setup/ruby/macos.md b/hugo/content/en/security/application_security/setup/ruby/macos.md index fa8ff07ad69..9c7f7faa866 100644 --- a/hugo/content/en/security/application_security/setup/ruby/macos.md +++ b/hugo/content/en/security/application_security/setup/ruby/macos.md @@ -17,7 +17,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -106,7 +106,7 @@ export DD_ENV= {{% collapse-content title="APM Tracing Disabled" level="h4" %}} -To disable APM tracing while keeping App and API Protection enabled, you must set the APM tracing configuration to false. +To disable APM tracing while keeping {{< prodname >}}App and API Protection{{< /prodname >}} enabled, you must set the APM tracing configuration to false. {{< tabs >}} {{% tab "Configuration file" %}} @@ -179,7 +179,7 @@ Start your application with above settings. ## 4. Verify setup -To verify that App and API Protection is working correctly: +To verify that {{< prodname >}}App and API Protection{{< /prodname >}} is working correctly: 1. Send some traffic to your application. 2. Check the [App and API Protection Service Inventory](https://app.datadoghq.com/security/appsec/inventory/services) in Datadog. @@ -187,7 +187,7 @@ To verify that App and API Protection is working correctly: ## Troubleshooting -If you encounter issues while setting up App and API Protection for your Ruby application, see the [Ruby App and API Protection troubleshooting guide][2]. +If you encounter issues while setting up {{< prodname >}}App and API Protection{{< /prodname >}} for your Ruby application, see the [Ruby App and API Protection troubleshooting guide][2]. ## Further Reading diff --git a/hugo/content/en/security/application_security/setup/ruby/troubleshooting.md b/hugo/content/en/security/application_security/setup/ruby/troubleshooting.md index 979d284e518..94afcc199e2 100644 --- a/hugo/content/en/security/application_security/setup/ruby/troubleshooting.md +++ b/hugo/content/en/security/application_security/setup/ruby/troubleshooting.md @@ -4,7 +4,7 @@ title: Troubleshooting Ruby App and API Protection {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} diff --git a/hugo/content/en/security/application_security/setup/single_step/_index.md b/hugo/content/en/security/application_security/setup/single_step/_index.md index 3214ffd0aad..b147a1011f5 100644 --- a/hugo/content/en/security/application_security/setup/single_step/_index.md +++ b/hugo/content/en/security/application_security/setup/single_step/_index.md @@ -7,7 +7,7 @@ aliases: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} diff --git a/hugo/content/en/security/application_security/setup/windows/_index.md b/hugo/content/en/security/application_security/setup/windows/_index.md index a0b1861ce2a..aa7165dcb1c 100644 --- a/hugo/content/en/security/application_security/setup/windows/_index.md +++ b/hugo/content/en/security/application_security/setup/windows/_index.md @@ -21,11 +21,11 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} -Learn how to set up App and API Protection (AAP) on your Windows services by selecting the service's programming language. +Learn how to set up {{< prodname >}}App and API Protection{{< /prodname >}} (AAP) on your Windows services by selecting the service's programming language.

Are you missing your environment?

diff --git a/hugo/content/en/security/application_security/terms.md b/hugo/content/en/security/application_security/terms.md index 31b17501a89..54c4f4affcb 100644 --- a/hugo/content/en/security/application_security/terms.md +++ b/hugo/content/en/security/application_security/terms.md @@ -15,7 +15,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} diff --git a/hugo/content/en/security/application_security/threat_protection/_index.md b/hugo/content/en/security/application_security/threat_protection/_index.md index 258232ba4d9..ccbde43a33b 100644 --- a/hugo/content/en/security/application_security/threat_protection/_index.md +++ b/hugo/content/en/security/application_security/threat_protection/_index.md @@ -9,11 +9,11 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} -Use Threat Protection in [App and API Protection][1] (AAP) to detect attacks against your applications and APIs, perform investigations, and block malicious traffic in real time. +Use Threat Protection in [{{< prodname >}}App and API Protection{{< /prodname >}}][1] (AAP) to detect attacks against your applications and APIs, perform investigations, and block malicious traffic in real time. To get started, [set up AAP][2] on your services so they report security traces. AAP then detects threats from your live application traffic and lets you respond to them. diff --git a/hugo/content/en/security/application_security/threat_protection/account_takeover_protection.md b/hugo/content/en/security/application_security/threat_protection/account_takeover_protection.md index 3f14446ff2f..d8945c8714f 100644 --- a/hugo/content/en/security/application_security/threat_protection/account_takeover_protection.md +++ b/hugo/content/en/security/application_security/threat_protection/account_takeover_protection.md @@ -18,11 +18,11 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} -App and API Protection (AAP) provides account takeover (ATO) protection to detect and mitigate account takeover attacks. +{{< prodname >}}App and API Protection{{< /prodname >}} (AAP) provides account takeover (ATO) protection to detect and mitigate account takeover attacks. ATO protection has the following benefits: diff --git a/hugo/content/en/security/application_security/threat_protection/exploit-prevention.md b/hugo/content/en/security/application_security/threat_protection/exploit-prevention.md index 5bb79eff545..8fe656ad402 100644 --- a/hugo/content/en/security/application_security/threat_protection/exploit-prevention.md +++ b/hugo/content/en/security/application_security/threat_protection/exploit-prevention.md @@ -21,12 +21,12 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} {{< learning-center-callout header="Get real-time security guardrails for your AI apps and agents" btn_title="Join the preview" hide_image="true" btn_url="https://www.datadoghq.com/product-preview/ai-security/">}} - AI Guard helps secure your AI apps and agents in real time against prompt injection, jailbreaking, tool misuse, and sensitive data exfiltration attacks. Try it today! + {{< prodname >}}AI Guard{{< /prodname >}} helps secure your AI apps and agents in real time against prompt injection, jailbreaking, tool misuse, and sensitive data exfiltration attacks. Try it today! {{< /learning-center-callout >}} ## Overview @@ -44,10 +44,10 @@ For details on how Exploit Prevention differs from In-App WAF, see [Exploit Prev ## How exploit prevention works 1. With the Datadog App and API Protection SDK instrumented in your applications, details are captured about every interaction within the application, including requests, code execution, and data flows. -2. When an attack payload reaches the application, App and API Protection evaluates if the payload triggers code paths tied to known vulnerabilities. +2. When an attack payload reaches the application, {{< prodname >}}App and API Protection{{< /prodname >}} evaluates if the payload triggers code paths tied to known vulnerabilities. 3. If a potential exploit is detected: - 1. App and API Protection blocks the request in real-time before it causes damage. - 2. App and API Protection raises security signals for further investigation. + 1. {{< prodname >}}App and API Protection{{< /prodname >}} blocks the request in real-time before it causes damage. + 2. {{< prodname >}}App and API Protection{{< /prodname >}} raises security signals for further investigation. 4. Exploit prevention detections are accompanied by stack traces that provide full visibility of the code location of the vulnerability, providing a clear path to remediation. ### Example 1: Server-side request forgery @@ -71,7 +71,7 @@ App and API Protection Exploit Prevention intercepts all SQL queries to determin ## Prerequisites - Ensure that your applications are instrumented with the Datadog SDK. -- App and API Protection must be enabled. See [Setup][1]. +- {{< prodname >}}App and API Protection{{< /prodname >}} must be enabled. See [Setup][1]. - Ensure Remote Configuration is enabled to push rule updates and In-App WAF policies. See [Enabling Remote Configuration][2]. ### Library Compatibility @@ -99,11 +99,11 @@ App and API Protection Exploit Prevention intercepts all SQL queries to determin ## Reviewing exploit attempts in App and API Protection -After you have enabled Exploit Prevention, if App and API Protection detects an exploit attempt, it proceeds to block that request. Exploit Prevention detections are always accompanied by stack traces, which provide full visibility of where the vulnerability lies in your code, ensuring a clear path to remediation. +After you have enabled Exploit Prevention, if {{< prodname >}}App and API Protection{{< /prodname >}} detects an exploit attempt, it proceeds to block that request. Exploit Prevention detections are always accompanied by stack traces, which provide full visibility of where the vulnerability lies in your code, ensuring a clear path to remediation. -In addition, App and API Protection also generates a signal correlating all the blocked traces and isolating the attacker IP addresses that are targeting your service(s). You can take action by blocking all attacking IPs. +In addition, {{< prodname >}}App and API Protection{{< /prodname >}} also generates a signal correlating all the blocked traces and isolating the attacker IP addresses that are targeting your service(s). You can take action by blocking all attacking IPs. diff --git a/hugo/content/en/security/application_security/threat_protection/overview.md b/hugo/content/en/security/application_security/threat_protection/overview.md index c337571a68d..fbf1835eaec 100644 --- a/hugo/content/en/security/application_security/threat_protection/overview.md +++ b/hugo/content/en/security/application_security/threat_protection/overview.md @@ -12,7 +12,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -26,7 +26,7 @@ The **Ask Bits** panel is a contextual entry point to Bits AI for questions abou ## App Instrumentation -The **App Instrumentation** section reports how broadly App and API Protection (AAP) is activated across your services. **Threat detection coverage** shows how many services are actively detecting threats in real time compared to your total services, and **Recommended services activated** tracks your progress in enabling AAP on at-risk services identified by known vulnerabilities and suspicious traffic. From this section you can protect additional services or view the services already protected. +The **App Instrumentation** section reports how broadly {{< prodname >}}App and API Protection{{< /prodname >}} (AAP) is activated across your services. **Threat detection coverage** shows how many services are actively detecting threats in real time compared to your total services, and **Recommended services activated** tracks your progress in enabling AAP on at-risk services identified by known vulnerabilities and suspicious traffic. From this section you can protect additional services or view the services already protected. ## Attack Coverage diff --git a/hugo/content/en/security/application_security/threat_protection/policies/_index.md b/hugo/content/en/security/application_security/threat_protection/policies/_index.md index f1f8d12d3c5..666920aa96c 100644 --- a/hugo/content/en/security/application_security/threat_protection/policies/_index.md +++ b/hugo/content/en/security/application_security/threat_protection/policies/_index.md @@ -8,13 +8,13 @@ disable_toc: false {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} If your service is running [an Agent with Remote Configuration enabled and an SDK version that supports it][2], you can block attacks and attackers from the Datadog UI without additional configuration of the Agent or SDKs. -App and API Protection (AAP) Protect enables you to slow down attacks and attackers by _blocking_ them. Security traces are blocked in real-time by the Datadog SDKs. Blocks are saved in the Datadog platform, automatically and securely fetched by the Datadog Agent, deployed in your infrastructure, and applied to your services. +{{< prodname >}}App and API Protection{{< /prodname >}} (AAP) Protect enables you to slow down attacks and attackers by _blocking_ them. Security traces are blocked in real-time by the Datadog SDKs. Blocks are saved in the Datadog platform, automatically and securely fetched by the Datadog Agent, deployed in your infrastructure, and applied to your services. ## Prerequisites @@ -36,7 +36,7 @@ From there, all AAP-protected services block incoming requests performed by the In addition to manually blocking attackers, you can configure automation rules to have AAP automatically block attackers that are flagged in Security Signals. -To get started, navigate to **Security > App and API Protection > Protection > [Detection Rules][14]**. You can create a new rule or edit an existing rule with type _App and API Protection_. For example, you can create a rule to trigger `Critical` severity signals when Credential Stuffing attacks are detected, and automatically block the associated attackers' IP addresses for 30 minutes. +To get started, navigate to **Security > {{< prodname >}}App and API Protection{{< /prodname >}} > Protection > [Detection Rules][14]**. You can create a new rule or edit an existing rule with type _{{< prodname >}}App and API Protection{{< /prodname >}}_. For example, you can create a rule to trigger `Critical` severity signals when Credential Stuffing attacks are detected, and automatically block the associated attackers' IP addresses for 30 minutes. **Note**: You must instrument your services to be able to block authenticated attackers. See [User Monitoring and Protection][15] for more details. @@ -69,7 +69,7 @@ For fine-grained control, you can clone a Datadog managed policy or create a cus As In-App WAF rules are toggled between modes, the changes are reflected in near real-time for services with [Remote Configuration enabled][2]. For other services, you can update the policy on the [In-App WAF page][9] and then [define In-App WAF rules][10] for the change in behavior to be applied. -Manage In-App WAF by navigating to Security --> App and API Protection --> Configuration --> [In-App WAF][9]. +Manage In-App WAF by navigating to Security --> {{< prodname >}}App and API Protection{{< /prodname >}} --> Configuration --> [In-App WAF][9]. View blocked security traces in the [Trace Explorer][11] by filtering on the facet `Blocked:true`. @@ -79,7 +79,7 @@ View blocked security traces in the [Trace Explorer][11] by filtering on the fac 1. [**Enable Remote Configuration**][2] so that your AAP-enabled services show up under In-App WAF. This is required to securely push In-App WAF configuration from your Datadog backend to the SDK in your infrastructure. -2. **Associate your AAP/Remote Configuration-enabled services with a policy**. After Remote Configuration is enabled on a service, navigate to **Security > App and API Protection > Protection > [In-App WAF][9]**. The service appears under the _Datadog Monitoring-only_ policy by default. Datadog Monitoring-only is a managed policy and is read-only, meaning you cannot modify the status (monitoring, blocking, or disabled) for individual rules. +2. **Associate your AAP/Remote Configuration-enabled services with a policy**. After Remote Configuration is enabled on a service, navigate to **Security > {{< prodname >}}App and API Protection{{< /prodname >}} > Protection > [In-App WAF][9]**. The service appears under the _Datadog Monitoring-only_ policy by default. Datadog Monitoring-only is a managed policy and is read-only, meaning you cannot modify the status (monitoring, blocking, or disabled) for individual rules. If you need granular control, clone one of the available policies to create a custom policy where rule statuses can be modified. Associate one or more of your services with this custom policy. @@ -91,7 +91,7 @@ View blocked security traces in the [Trace Explorer][11] by filtering on the fac {{% asm-protection-page-configuration %}} -The default HTTP response status code while serving the deny page to attackers is `403 FORBIDDEN`. To customize the response, navigate to **Security > App and API Protection > Protection > In-App Waf > [Custom Responses][16]**. +The default HTTP response status code while serving the deny page to attackers is `403 FORBIDDEN`. To customize the response, navigate to **Security > {{< prodname >}}App and API Protection{{< /prodname >}} > Protection > In-App Waf > [Custom Responses][16]**. You can optionally mask the fact that the attacker has been detected and blocked by overriding the response code to be `200 OK` or `404 NOT FOUND` when the deny page is served. @@ -101,7 +101,7 @@ You can also optionally redirect attackers to a custom deny page and away from y Protection mode is **on** by default and is a toggle available to quickly disable blocking across **all** your services. Requests can be blocked from two sections in Datadog: all attacker requests from Security Signals, and security traces from In-App WAF. -As important as it is for you to be able to apply protection granularly and reduce the likelihood of legitimate users getting blocked, you sometimes need a simple off switch to quickly stop **all** blocking across **all** services. To turn off protection, navigate to **Security > App and API Protection > Protection > [In-App WAF][9]** and toggle **Allow Request Blocking** to off. +As important as it is for you to be able to apply protection granularly and reduce the likelihood of legitimate users getting blocked, you sometimes need a simple off switch to quickly stop **all** blocking across **all** services. To turn off protection, navigate to **Security > {{< prodname >}}App and API Protection{{< /prodname >}} > Protection > [In-App WAF][9]** and toggle **Allow Request Blocking** to off. [1]: /security/application_security/setup/ [2]: /tracing/guide/remote_config diff --git a/hugo/content/en/security/application_security/threat_protection/policies/custom_rules.md b/hugo/content/en/security/application_security/threat_protection/policies/custom_rules.md index 9f8f28ac2d4..bbbcc1806a5 100644 --- a/hugo/content/en/security/application_security/threat_protection/policies/custom_rules.md +++ b/hugo/content/en/security/application_security/threat_protection/policies/custom_rules.md @@ -25,13 +25,13 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} ## Overview -App and API Protection (AAP) comes with a set of [out-of-the-box detection rules][1] which aim to catch attack attempts, vulnerabilities found by attacker, and business logic abuse that impact your production systems. +{{< prodname >}}App and API Protection{{< /prodname >}} (AAP) comes with a set of [out-of-the-box detection rules][1] which aim to catch attack attempts, vulnerabilities found by attacker, and business logic abuse that impact your production systems. However, there are situations where you may want to customize a rule based on your environment or workload. For example, you may want to customize a detection rule that detects users performing sensitive actions from a geolocation where your business doesn't operate. diff --git a/hugo/content/en/security/application_security/threat_protection/policies/inapp_waf_rules.md b/hugo/content/en/security/application_security/threat_protection/policies/inapp_waf_rules.md index d50770c9a29..570a3b311a4 100644 --- a/hugo/content/en/security/application_security/threat_protection/policies/inapp_waf_rules.md +++ b/hugo/content/en/security/application_security/threat_protection/policies/inapp_waf_rules.md @@ -9,7 +9,7 @@ aliases: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -52,13 +52,13 @@ An input represents which part of the request the operator is applied to. The fo ## Custom In-App WAF rules -Custom In-App WAF rules enable users to log or block specific types of requests to their applications. For example, you can use custom rules to monitor login success or failure. To get started, navigate to {{< ui >}}Security{{< /ui >}} > {{< ui >}}App and API Protection{{< /ui >}} > {{< ui >}}Policies{{< /ui >}} > {{< ui >}}In-App WAF{{< /ui >}} > [{{< ui >}}Custom Rules{{< /ui >}}][4]. +Custom In-App WAF rules enable users to log or block specific types of requests to their applications. For example, you can use custom rules to monitor login success or failure. To get started, navigate to {{< ui >}}Security{{< /ui >}} > {{< ui >}}{{< prodname >}}App and API Protection{{< /prodname >}}{{< /ui >}} > {{< ui >}}Policies{{< /ui >}} > {{< ui >}}In-App WAF{{< /ui >}} > [{{< ui >}}Custom Rules{{< /ui >}}][4]. **Note:** Default rules in In-App WAF are read-only. To refine your In-App WAF behavior, modify the In-App WAF rules. Default rules cannot be modified, however, you can create a custom rule based on one of the default rules, and modify the match conditions to your needs. Be sure to disable the default rule so that you don't have two similar rules evaluating the same requests. ## Suggested rules -Datadog's App and API Protection [Suggested Rules][5] feature automatically analyzes application traffic and proposes rules to help monitor and protect login and API flows. Rules are pre-built around common authentication patterns like `users.login.success` or `users.login.failure`, which are the most critical signals for detecting suspicious login behavior. +Datadog's {{< prodname >}}App and API Protection{{< /prodname >}} [Suggested Rules][5] feature automatically analyzes application traffic and proposes rules to help monitor and protect login and API flows. Rules are pre-built around common authentication patterns like `users.login.success` or `users.login.failure`, which are the most critical signals for detecting suspicious login behavior. Suggested rules benefits include: diff --git a/hugo/content/en/security/application_security/threat_protection/policies/library_configuration.md b/hugo/content/en/security/application_security/threat_protection/policies/library_configuration.md index 2977e817aeb..a04fa4b005b 100644 --- a/hugo/content/en/security/application_security/threat_protection/policies/library_configuration.md +++ b/hugo/content/en/security/application_security/threat_protection/policies/library_configuration.md @@ -26,7 +26,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} diff --git a/hugo/content/en/security/application_security/threat_protection/security_signals/_index.md b/hugo/content/en/security/application_security/threat_protection/security_signals/_index.md index 4de980214af..5af03331faa 100644 --- a/hugo/content/en/security/application_security/threat_protection/security_signals/_index.md +++ b/hugo/content/en/security/application_security/threat_protection/security_signals/_index.md @@ -17,7 +17,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -64,11 +64,11 @@ You can triage a signal by assigning it to a user for further investigation. The - {{< ui >}}Under Review{{< /ui >}}: The signal is actively being investigated. From the {{< ui >}}Under Review{{< /ui >}} state, you can move the signal to {{< ui >}}Archived{{< /ui >}} or {{< ui >}}Open{{< /ui >}} as needed. - {{< ui >}}Archived{{< /ui >}}: The detection that caused the signal has been resolved. From the {{< ui >}}Archived{{< /ui >}} state, you can move the signal back to {{< ui >}}Open{{< /ui >}} if it's within 30 days of when the signal was originally detected. -**Note**: To modify security signals, you must have the `security_monitoring_signals_write` permission. See [Role Based Access Control][9] for more information about Datadog's default roles and granular role-based access control permissions available for App and API Protection. +**Note**: To modify security signals, you must have the `security_monitoring_signals_write` permission. See [Role Based Access Control][9] for more information about Datadog's default roles and granular role-based access control permissions available for {{< prodname >}}App and API Protection{{< /prodname >}}. ## Declare an incident -Use [Incident Management][4] to create an incident for a security signal. +Use [{{< prodname >}}Incident Management{{< /prodname >}}][4] to create an incident for a security signal. Declare an incident if: @@ -85,14 +85,14 @@ If you don't know whether you should declare an incident, notify other users and ## Run a workflow -Use [Workflow Automation][5] to manually trigger a workflow for a security signal. +Use [{{< prodname >}}Workflow Automation{{< /prodname >}}][5] to manually trigger a workflow for a security signal. 1. Make sure the workflow you want to run has a security trigger. 2. On the [Signals Explorer][2] page, open a security signal. 3. In the {{< ui >}}Respond{{< /ui >}} section, click {{< ui >}}Run Workflow{{< /ui >}}. 4. In {{< ui >}}Run a workflow{{< /ui >}}, select the workflow you want to run or click {{< ui >}}New Workflow{{< /ui >}}. - Depending on the workflow you select, you might be required to enter additional input parameters. - - If you selected {{< ui >}}New Workflow{{< /ui >}}, Run a Security Workflow opens. To learn more about workflows, see [Workflow Automation][5]. + - If you selected {{< ui >}}New Workflow{{< /ui >}}, Run a Security Workflow opens. To learn more about workflows, see [{{< prodname >}}Workflow Automation{{< /prodname >}}][5]. 5. Click {{< ui >}}Run{{< /ui >}}. ## Review and remediate @@ -101,7 +101,7 @@ Use [Workflow Automation][5] to manually trigger a workflow for a security signa 2. In the signal details, view each of the sections, such as {{< ui >}}What Happened{{< /ui >}}, {{< ui >}}Activity Summary{{< /ui >}}, and {{< ui >}}Detection Rule{{< /ui >}}. 3. Review the {{< ui >}}Next Steps{{< /ui >}} and take action: - Click {{< ui >}}Block all Attacking IPs{{< /ui >}} (by specific duration or permanently). - - Click {{< ui >}}Automated Attacker Blocking{{< /ui >}} (based on [detection][10] rules). This setting requires the App and API Protection `Protect Write` permission. + - Click {{< ui >}}Automated Attacker Blocking{{< /ui >}} (based on [detection][10] rules). This setting requires the {{< prodname >}}App and API Protection{{< /prodname >}} `Protect Write` permission. - Click [{{< ui >}}Block with Edge WAF{{< /ui >}}][11]. ## Bulk actions @@ -120,7 +120,7 @@ Select {{< ui >}}Remove all assignments{{< /ui >}} to reset the signal assignmen ### Case management -Datadog [Case Management][6] offers a centralized place to triage, track, and remediate issues detected by Datadog and third-party integrations. +Datadog [{{< prodname >}}Case Management{{< /prodname >}}][6] offers a centralized place to triage, track, and remediate issues detected by Datadog and third-party integrations. 1. On the [Signals Explorer][2] page, select a security signal. 2. In {{< ui >}}Bulk Actions{{< /ui >}}, select {{< ui >}}Create a case{{< /ui >}}. @@ -128,7 +128,7 @@ Datadog [Case Management][6] offers a centralized place to triage, track, and re 4. Enter a title and optional description. 5. Click {{< ui >}}Create Case{{< /ui >}}. -When you click {{< ui >}}Create Case{{< /ui >}}, you are directed to Case Management and the project you selected. +When you click {{< ui >}}Create Case{{< /ui >}}, you are directed to {{< prodname >}}Case Management{{< /prodname >}} and the project you selected. ## Saved views diff --git a/hugo/content/en/security/application_security/threat_protection/security_signals/attacker-explorer.md b/hugo/content/en/security/application_security/threat_protection/security_signals/attacker-explorer.md index 77cccfe34ec..014fda2864b 100644 --- a/hugo/content/en/security/application_security/threat_protection/security_signals/attacker-explorer.md +++ b/hugo/content/en/security/application_security/threat_protection/security_signals/attacker-explorer.md @@ -13,7 +13,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} diff --git a/hugo/content/en/security/application_security/threat_protection/security_signals/attacker_clustering.md b/hugo/content/en/security/application_security/threat_protection/security_signals/attacker_clustering.md index a28792d555c..75eecf3a32e 100644 --- a/hugo/content/en/security/application_security/threat_protection/security_signals/attacker_clustering.md +++ b/hugo/content/en/security/application_security/threat_protection/security_signals/attacker_clustering.md @@ -24,7 +24,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} diff --git a/hugo/content/en/security/application_security/threat_protection/security_signals/attacker_fingerprint.md b/hugo/content/en/security/application_security/threat_protection/security_signals/attacker_fingerprint.md index 3313ebd1850..09c5053f8c2 100644 --- a/hugo/content/en/security/application_security/threat_protection/security_signals/attacker_fingerprint.md +++ b/hugo/content/en/security/application_security/threat_protection/security_signals/attacker_fingerprint.md @@ -12,7 +12,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -20,7 +20,7 @@ This topic describes a feature called **Datadog Attacker Fingerprint** to identi ## Overview -Datadog Attacker Fingerprint identifies attackers beyond IP addresses. Datadog Attacker fingerprints are automatically computed and added to your traces on attack or login attempts when App and API Protection (AAP) is enabled on your service. +Datadog Attacker Fingerprint identifies attackers beyond IP addresses. Datadog Attacker fingerprints are automatically computed and added to your traces on attack or login attempts when {{< prodname >}}App and API Protection{{< /prodname >}} (AAP) is enabled on your service. Datadog Attacker fingerprints are composed of several fragments: * Endpoint Identifier diff --git a/hugo/content/en/security/application_security/threat_protection/security_signals/users_explorer.md b/hugo/content/en/security/application_security/threat_protection/security_signals/users_explorer.md index 1512860b78f..d5ae94db495 100644 --- a/hugo/content/en/security/application_security/threat_protection/security_signals/users_explorer.md +++ b/hugo/content/en/security/application_security/threat_protection/security_signals/users_explorer.md @@ -7,11 +7,11 @@ disable_toc: false {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} -This topic describes how to use the App and API Protection [Users explorer][1] to investigate the risks associated with the users tracked by security [traces][3]. +This topic describes how to use the {{< prodname >}}App and API Protection{{< /prodname >}} [Users explorer][1] to investigate the risks associated with the users tracked by security [traces][3]. ## Overview @@ -36,7 +36,7 @@ The Users explorer assigns one or more of the following risk categories to a use To understand the difference between the different explorers, review these security approaches they support: -- **Protect:** Automatically block attackers (IPs and authenticated users) using App and API Protection [Policies][2]. Customers should block attack tools as their first automated blocking action. Blocking attack tools reduces common vulnerability discovery for OWASP threats such as SQLi, command injection, and SSRF. +- **Protect:** Automatically block attackers (IPs and authenticated users) using {{< prodname >}}App and API Protection{{< /prodname >}} [Policies][2]. Customers should block attack tools as their first automated blocking action. Blocking attack tools reduces common vulnerability discovery for OWASP threats such as SQLi, command injection, and SSRF. - **React:** Blocking attackers in response to observed threats using the [Signals][9], [Traces][3], Users, [Attackers][4] explorers. Each explorer focuses on a specific use case: diff --git a/hugo/content/en/security/application_security/threat_protection/waf-integration.md b/hugo/content/en/security/application_security/threat_protection/waf-integration.md index d00438e00b5..cb3520eb398 100644 --- a/hugo/content/en/security/application_security/threat_protection/waf-integration.md +++ b/hugo/content/en/security/application_security/threat_protection/waf-integration.md @@ -12,11 +12,11 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} -Protecting web applications and APIs requires a multi-layered approach that combines in-app monitoring and perimeter defenses. These complementary strategies enable you to have a *defense-in-depth* App and API Protection approach that leverages AWS Web Application Firewall (WAF) as the first line of defense, followed by Exploit Prevention for blocking attacks that slip by the WAF. +Protecting web applications and APIs requires a multi-layered approach that combines in-app monitoring and perimeter defenses. These complementary strategies enable you to have a *defense-in-depth* {{< prodname >}}App and API Protection{{< /prodname >}} approach that leverages AWS Web Application Firewall (WAF) as the first line of defense, followed by Exploit Prevention for blocking attacks that slip by the WAF. For details on how Exploit Prevention differs from In-App WAF, see [Exploit Prevention vs. In-App WAF][5]. diff --git a/hugo/content/en/security/application_security/troubleshooting.md b/hugo/content/en/security/application_security/troubleshooting.md index 3a49e62ffac..b14e1277c8b 100644 --- a/hugo/content/en/security/application_security/troubleshooting.md +++ b/hugo/content/en/security/application_security/troubleshooting.md @@ -13,7 +13,7 @@ further_reading: {{< site-region region="gov" >}}
-App and API Protection is in Preview on Datadog Government site US1-FED. +{{< prodname >}}App and API Protection{{< /prodname >}} is in Preview on Datadog Government site US1-FED.
{{< /site-region >}} @@ -534,7 +534,7 @@ Wait a minute for the agent to forward the traces, then check that the traces sh ### Confirm tracer versions are updated -See the App and API Protection product set up documentation to validate you are using the right version of the SDK. These minimum versions are required to start sending telemetry data that includes library information. +See the {{< prodname >}}App and API Protection{{< /prodname >}} product set up documentation to validate you are using the right version of the SDK. These minimum versions are required to start sending telemetry data that includes library information. ### Ensure the communication of telemetry data diff --git a/hugo/content/en/security/assignee_management.md b/hugo/content/en/security/assignee_management.md index 5e5a9c709d2..77ad1f31d62 100644 --- a/hugo/content/en/security/assignee_management.md +++ b/hugo/content/en/security/assignee_management.md @@ -34,10 +34,10 @@ If a finding is linked to a Case or ticket, the finding's assignee and the linke You can assign users to findings in the following products: -- [Cloud Security][2] -- [Code Security][3] -- [App and API Protection][4] -- [Workload Protection][5] +- [{{< prodname >}}Cloud Security{{< /prodname >}}][2] +- [{{< prodname >}}Code Security{{< /prodname >}}][3] +- [{{< prodname >}}App and API Protection{{< /prodname >}}][4] +- [{{< prodname >}}Workload Protection{{< /prodname >}}][5] ## Assign a user to a finding diff --git a/hugo/content/en/security/automation_pipelines/_index.md b/hugo/content/en/security/automation_pipelines/_index.md index 1557ae25958..604c0d5c237 100644 --- a/hugo/content/en/security/automation_pipelines/_index.md +++ b/hugo/content/en/security/automation_pipelines/_index.md @@ -87,7 +87,7 @@ Customize the Security Inbox by defining specific conditions that determine whic ### Automatically create tickets to route findings into engineering workflows -Route security findings directly into Jira or Case Management as soon as they are discovered. This allows you to: +Route security findings directly into Jira or {{< prodname >}}Case Management{{< /prodname >}} as soon as they are discovered. This allows you to: - **Eliminate manual triage**: Automatically generate tickets for findings that match your criteria, removing the need for security teams to create tickets by hand. - **Integrate with existing engineering workflows**: Meet engineering teams where they already work by routing security work into the same tools they use for other tasks. diff --git a/hugo/content/en/security/automation_pipelines/create_ticket.md b/hugo/content/en/security/automation_pipelines/create_ticket.md index 3fa42b8f4a8..322dd61701a 100644 --- a/hugo/content/en/security/automation_pipelines/create_ticket.md +++ b/hugo/content/en/security/automation_pipelines/create_ticket.md @@ -28,7 +28,7 @@ further_reading: {{< product-availability >}} -Configure ticket creation rules to automatically create tickets in Jira or Case Management when new findings are discovered. This approach tracks security issues in your existing engineering workflows without manual triage, helping teams respond quickly to new threats at scale. For more information about ticketing integrations with security findings, see [Ticketing Integrations][3]. +Configure ticket creation rules to automatically create tickets in Jira or {{< prodname >}}Case Management{{< /prodname >}} when new findings are discovered. This approach tracks security issues in your existing engineering workflows without manual triage, helping teams respond quickly to new threats at scale. For more information about ticketing integrations with security findings, see [Ticketing Integrations][3]. ## Create a ticket creation rule @@ -57,9 +57,9 @@ Configure ticket creation rules to automatically create tickets in Jira or Case - **Ticket Type**: Select the type of Jira issue to create, for example, **Task**. - **Assignee** (optional): Specify a user to assign automatically created tickets to. - To add more fields to the Jira ticket Datadog creates, use **Add Optional Field**. - - Expand **Data Sync Settings** to review or update the linked Case Management project and bidirectional sync configuration. + - Expand **Data Sync Settings** to review or update the linked {{< prodname >}}Case Management{{< /prodname >}} project and bidirectional sync configuration. - **Case Management** - - **Case Management Project**: Select an existing Case Management project, or create one. + - **Case Management Project**: Select an existing {{< prodname >}}Case Management{{< /prodname >}} project, or create one. - **Assignee** (optional): Specify a user to assign automatically created cases to. 1. Under **Rate limit**, enter the [maximum number of tickets](#daily-ticket-limit) this rule can create per UTC day. 1. To test the rule before saving, click **Test Rule**, select a matching finding, and click **Run Test**. After the test completes, you can view the created ticket or detach the test ticket from the finding. diff --git a/hugo/content/en/security/cloud_security_management/_index.md b/hugo/content/en/security/cloud_security_management/_index.md index 03f619647af..d27ee7f7967 100644 --- a/hugo/content/en/security/cloud_security_management/_index.md +++ b/hugo/content/en/security/cloud_security_management/_index.md @@ -62,7 +62,7 @@ cascade: --- {{< learning-center-callout header="Join an enablement webinar session" hide_image="true" btn_title="Sign Up" btn_url="https://www.datadoghq.com/technical-enablement/sessions/?tags.topics-0=Security">}} - Learn how Datadog Cloud SIEM and Cloud Security elevate your organization's threat detection and investigation for dynamic, cloud-scale environments. + Learn how Datadog Cloud SIEM and {{< prodname >}}Cloud Security{{< /prodname >}} elevate your organization's threat detection and investigation for dynamic, cloud-scale environments. {{< /learning-center-callout >}} Datadog Cloud Security delivers deep visibility, continuous configuration audits, identity risk assessments, vulnerability detection, and real-time threat detection across your entire cloud infrastructure—all in a unified platform for seamless collaboration and faster remediation. @@ -73,13 +73,13 @@ Security and DevOps teams can act on the shared context of observability and sec
Agentless Scanning is not available in the selected site ({{< region-param key="dd_site_name" >}}).
{{< /site-region >}} -Cloud Security leverages both the Datadog Agent and Agentless. It includes a variety of features you can enable to manage different facets of your organization's security: +{{< prodname >}}Cloud Security{{< /prodname >}} leverages both the Datadog Agent and Agentless. It includes a variety of features you can enable to manage different facets of your organization's security: - [{{< ui >}}Misconfigurations{{< /ui >}}][2]: Tracks the security hygiene and compliance posture of your production environment, automates audit evidence collection, and enables you to remediate misconfigurations that leave your organization vulnerable to attacks. - [{{< ui >}}Identity Risks{{< /ui >}}][8]: Provides in-depth visibility into your organization's AWS IAM, Azure, and GCP risks, and enables you to detect and resolve identity risks on an ongoing basis. - [{{< ui >}}Vulnerabilities{{< /ui >}}][9]: Continuously detect, prioritize, and remediate exploitable vulnerabilities in your container images, host images, and hosts running in your infrastructure. -Cloud Security also includes access to Datadog Security features, including: +{{< prodname >}}Cloud Security{{< /prodname >}} also includes access to Datadog Security features, including: - [Detection Rules][18] - [Notifications][6] - [Automation Pipelines][19] @@ -95,11 +95,11 @@ Cloud Security also includes access to Datadog Security features, including: ### Manage homepage dashboards -You can customize the dashboards that you can access directly from the Cloud Security homepage, including setting a dashboard to your default homepage view. Use dashboards to prioritize remediation efforts, schedule reports, put security data next to observability and cost data, and embed apps and workflows you can start directly from your reporting view. +You can customize the dashboards that you can access directly from the {{< prodname >}}Cloud Security{{< /prodname >}} homepage, including setting a dashboard to your default homepage view. Use dashboards to prioritize remediation efforts, schedule reports, put security data next to observability and cost data, and embed apps and workflows you can start directly from your reporting view. -On the [Cloud Security homepage][4], in the {{< ui >}}Dashboards{{< /ui >}} section, you can jump directly to dashboards for Identity Risks, Misconfigurations, or Vulnerabilities. You can also add existing dashboards or create one to keep on your Cloud Security homepage sidebar for convenient access. +On the [Cloud Security homepage][4], in the {{< ui >}}Dashboards{{< /ui >}} section, you can jump directly to dashboards for Identity Risks, Misconfigurations, or Vulnerabilities. You can also add existing dashboards or create one to keep on your {{< prodname >}}Cloud Security{{< /prodname >}} homepage sidebar for convenient access. -Additionally, you can click the {{< ui >}}More Options{{< /ui >}} icon {{< img src="icons/kebab.png" inline="true" style="height:1em" >}} to manage your pinned dashboards, including setting one as your Cloud Security homepage default view. Click {{< ui >}}Cloud Security{{< /ui >}} in the Datadog nav bar or {{< ui >}}Summary{{< /ui >}} in the Cloud Security nav bar to go directly to your pinned dashboard. +Additionally, you can click the {{< ui >}}More Options{{< /ui >}} icon {{< img src="icons/kebab.png" inline="true" style="height:1em" >}} to manage your pinned dashboards, including setting one as your {{< prodname >}}Cloud Security{{< /prodname >}} homepage default view. Click {{< ui >}}{{< prodname >}}Cloud Security{{< /prodname >}}{{< /ui >}} in the Datadog nav bar or {{< ui >}}Summary{{< /ui >}} in the {{< prodname >}}Cloud Security{{< /prodname >}} nav bar to go directly to your pinned dashboard. For more information, see [Dashboards][23]. @@ -113,7 +113,7 @@ Improve your organization's score by remediating misconfigurations, either by re ## Explore and remediate issues -For an overview of your Cloud Security and App and API Protection findings, sorted by importance, use the [Security Inbox][14]. +For an overview of your {{< prodname >}}Cloud Security{{< /prodname >}} and {{< prodname >}}App and API Protection{{< /prodname >}} findings, sorted by importance, use the [Security Inbox][14]. To get more detail, use [Findings][7] to review and remediate your organization's security findings concerning misconfigurations, vulnerabilities, and identity risks. View detailed information about a finding, including guidelines and remediation steps. [Send real-time notifications][6] when a threat is detected in your environment, and use tags to identify the owner of an impacted resource. @@ -125,14 +125,14 @@ To get more detail, use [Findings][7] to review and remediate your organization' {{< img src="security/csm/security_graph.png" alt="Security Graph displaying an example EC2 instance" width="100%">}} - Use the [Resource Catalog][12] to view specific misconfigurations and threats that have been reported on the hosts and resources in your environments. For more information, see the [Resource Catalog][13] documentation. {{< site-region region="gov,gov2" >}} -
Resource Catalog is not supported for your selected Datadog site ({{< region-param key="dd_site_name" >}}).
+
{{< prodname >}}Resource Catalog{{< /prodname >}} is not supported for your selected Datadog site ({{< region-param key="dd_site_name" >}}).
{{< /site-region >}} {{< img src="infrastructure/resource_catalog/resource_catalog_infra_3.png" alt="Resource Catalog map view displaying host and cloud resources grouped by category and misconfigurations." style="width:100%;" >}} - Use the [Cloudcraft Security Map][21] to visualize your resources and any misconfigurations, vulnerabilities, identity risks, or sensitive data associated with them. For more information on these overlays, see the [Cloudcraft overlay][22] documentation. ## Subscribe to weekly digest reports -Receive a weekly summary of Cloud Security activity over the past week, including important new security issues discovered in the last seven days. Subscriptions to the weekly digest report are managed on a per user basis. To [subscribe to the weekly digest report][11], you must have the `security_monitoring_signals_read` permission. +Receive a weekly summary of {{< prodname >}}Cloud Security{{< /prodname >}} activity over the past week, including important new security issues discovered in the last seven days. Subscriptions to the weekly digest report are managed on a per user basis. To [subscribe to the weekly digest report][11], you must have the `security_monitoring_signals_read` permission. ## Learn about emerging threats and vulnerabilities @@ -140,7 +140,7 @@ Use the [Security Research Feed][15] to stay current with the latest security de ## Next steps -To get started with Cloud Security, navigate to the [{{< ui >}}Cloud Security Setup{{< /ui >}}][3] page in Datadog, which has detailed steps on how to set up and configure Cloud Security. For more information, see [Setting Up Cloud Security][10]. +To get started with {{< prodname >}}Cloud Security{{< /prodname >}}, navigate to the [{{< ui >}}Cloud Security Setup{{< /ui >}}][3] page in Datadog, which has detailed steps on how to set up and configure {{< prodname >}}Cloud Security{{< /prodname >}}. For more information, see [Setting Up Cloud Security][10]. ## Further reading diff --git a/hugo/content/en/security/cloud_security_management/code_locations/_index.md b/hugo/content/en/security/cloud_security_management/code_locations/_index.md index 2e3576fdcad..9902defaab3 100644 --- a/hugo/content/en/security/cloud_security_management/code_locations/_index.md +++ b/hugo/content/en/security/cloud_security_management/code_locations/_index.md @@ -40,7 +40,7 @@ When Datadog resolves a code location for a finding, the finding side panel show To see code locations on your misconfiguration findings, you need: - [Cloud Security Misconfigurations][1] enabled for the cloud accounts you want to scan, so that findings are generated. -- [Source Code Integration][2] connected to the repositories that contain your IaC. Datadog indexes supported IaC files in your connected repositories to determine where each resource is defined. +- [{{< prodname >}}Source Code Integration{{< /prodname >}}][2] connected to the repositories that contain your IaC. Datadog indexes supported IaC files in your connected repositories to determine where each resource is defined. After both are configured, Datadog resolves code locations for supported resources automatically. Coverage increases as you connect more of the repositories that manage your cloud infrastructure. @@ -72,9 +72,9 @@ You can narrow the results further. For example: After you locate the code that defines a misconfigured resource, you can remediate it in several ways: -- **Remediate with AI**: Click **Remediate with AI** on the finding to hand off the fix to [Bits Code][7], or to copy a fix prompt into the coding agent you already use. See [Remediate with AI][8]. +- **Remediate with AI**: Click **Remediate with AI** on the finding to hand off the fix to [{{< prodname >}}Bits Code{{< /prodname >}}][7], or to copy a fix prompt into the coding agent you already use. See [Remediate with AI][8]. - **Route to the right team**: Use the code owners shown on the finding to assign the fix to the team that owns the file, or [create a ticket][4] in your ticketing tool. -- **Automate remediation**: Use [Workflow Automation][5] to build automated remediation workflows, with or without human approval. +- **Automate remediation**: Use [{{< prodname >}}Workflow Automation{{< /prodname >}}][5] to build automated remediation workflows, with or without human approval. If a misconfiguration doesn't apply to your environment or is an accepted risk, you can [mute it][6] instead. diff --git a/hugo/content/en/security/cloud_security_management/crown_jewels.md b/hugo/content/en/security/cloud_security_management/crown_jewels.md index ee23a447e02..068fc2c3e59 100644 --- a/hugo/content/en/security/cloud_security_management/crown_jewels.md +++ b/hugo/content/en/security/cloud_security_management/crown_jewels.md @@ -14,7 +14,7 @@ further_reading: ## Overview -Crown Jewels is an inventory of your most critical cloud resources, automatically detected from the telemetry you already send to Datadog. The list is the starting point for prioritizing remediation work across Cloud Security: you can sort, filter and route vulnerabilities, misconfigurations, and identity risks that are linked to a crown jewel differently from the rest of your findings. +Crown Jewels is an inventory of your most critical cloud resources, automatically detected from the telemetry you already send to Datadog. The list is the starting point for prioritizing remediation work across {{< prodname >}}Cloud Security{{< /prodname >}}: you can sort, filter and route vulnerabilities, misconfigurations, and identity risks that are linked to a crown jewel differently from the rest of your findings. Most security teams have more findings than they can act on, but by knowing which resources matter most, you can start addressing the subset of findings that need attention first. @@ -65,7 +65,7 @@ You can combine the filter with other criteria; for example, you can filter the ## Review and edit the list -To view your Crown Jewels, go to **Security** > **Settings** > **Cloud Security** > [**Crown Jewels**][1]. Datadog automatically populates the list with entries showing: +To view your Crown Jewels, go to **Security** > **Settings** > **{{< prodname >}}Cloud Security{{< /prodname >}}** > [**Crown Jewels**][1]. Datadog automatically populates the list with entries showing: - The resource type and name. - The detection signal that triggered inclusion. @@ -78,7 +78,7 @@ Treat the automatically generated list as a draft that you can curate so it refl ## Privacy and data handling -Crown Jewels runs on telemetry you have already sent to Datadog. It does not move data outside of your Datadog account or send data to third parties. Detection runs in the same regional infrastructure as your other Cloud Security data. +Crown Jewels runs on telemetry you have already sent to Datadog. It does not move data outside of your Datadog account or send data to third parties. Detection runs in the same regional infrastructure as your other {{< prodname >}}Cloud Security{{< /prodname >}} data. ## Further reading diff --git a/hugo/content/en/security/cloud_security_management/guide/_index.md b/hugo/content/en/security/cloud_security_management/guide/_index.md index 0abb56bb057..d57e1796396 100644 --- a/hugo/content/en/security/cloud_security_management/guide/_index.md +++ b/hugo/content/en/security/cloud_security_management/guide/_index.md @@ -8,7 +8,7 @@ aliases: {{< whatsnext desc="Cloud Security Guides" >}} - {{< nextlink href="/getting_started/cloud_security_management" >}}First Steps for Cloud Security{{< /nextlink >}} + {{< nextlink href="/getting_started/cloud_security_management" >}}First Steps for {{< prodname >}}Cloud Security{{< /prodname >}}{{< /nextlink >}} {{< nextlink href="/security/cloud_security_management/guide/agent_variables" >}}Cloud Security Agent Variables{{< /nextlink >}} {{< nextlink href="/security/cloud_security_management/guide/frontier_group" >}}Cloud Security Frontier Group{{< /nextlink >}} {{< /whatsnext >}} diff --git a/hugo/content/en/security/cloud_security_management/guide/active-protection.md b/hugo/content/en/security/cloud_security_management/guide/active-protection.md index 941007e8ce8..94a51923915 100644 --- a/hugo/content/en/security/cloud_security_management/guide/active-protection.md +++ b/hugo/content/en/security/cloud_security_management/guide/active-protection.md @@ -10,7 +10,7 @@ further_reading:
Workload Protection Active Protection is in Preview.
-This topic explains how to use the Workload Protection **Active Protection** feature to block crypto mining threats automatically. +This topic explains how to use the {{< prodname >}}Workload Protection{{< /prodname >}} **Active Protection** feature to block crypto mining threats automatically. By default, all OOTB Agent [threat detection rules][4] are enabled and actively monitoring for crypto threats. @@ -79,7 +79,7 @@ Consequently, you do not need to worry that enabling Active Protection immediate To enable Active Protection: -1. Go to Cloud Security [Agent Configuration][2] rules. +1. Go to {{< prodname >}}Cloud Security{{< /prodname >}} [Agent Configuration][2] rules. 2. Select **Enable Active Protection**. {{< img src="security/cws/guide/enable-active-protection.png" alt="Enable Active Protection button" style="width:100%;" >}} diff --git a/hugo/content/en/security/cloud_security_management/guide/agent_variables.md b/hugo/content/en/security/cloud_security_management/guide/agent_variables.md index 66c029c0abc..dda23cd76d5 100644 --- a/hugo/content/en/security/cloud_security_management/guide/agent_variables.md +++ b/hugo/content/en/security/cloud_security_management/guide/agent_variables.md @@ -4,7 +4,7 @@ aliases: - /security/cloud_security_management/setup/agent_variables --- -The Datadog Agent has several environment variables that can be enabled for Cloud Security. This article describes the purpose of each environment variable. +The Datadog Agent has several environment variables that can be enabled for {{< prodname >}}Cloud Security{{< /prodname >}}. This article describes the purpose of each environment variable. diff --git a/hugo/content/en/security/cloud_security_management/guide/custom-rules-guidelines.md b/hugo/content/en/security/cloud_security_management/guide/custom-rules-guidelines.md index ba4b4d44192..cb7f79eb6ad 100644 --- a/hugo/content/en/security/cloud_security_management/guide/custom-rules-guidelines.md +++ b/hugo/content/en/security/cloud_security_management/guide/custom-rules-guidelines.md @@ -31,7 +31,7 @@ Use wildcards (`*`) carefully. For example, never use `open.file.path =~ "*/myfi ## Approvers and discarders -Workload Protection uses the concept of approvers and discarders to filter out events that should not trigger any rules in a policy. Approvers and discarders allow or deny events at the policy level only. They do not act on individual rules. +{{< prodname >}}Workload Protection{{< /prodname >}} uses the concept of approvers and discarders to filter out events that should not trigger any rules in a policy. Approvers and discarders allow or deny events at the policy level only. They do not act on individual rules. Approvers act as an allow-list at the kernel level in the Datadog Agent. For example, the opening of a specific file could be an approver on the event `open`, whereas `open` events on files without approvers would be filtered out. Similarly, discarders act as a deny-list in the Agent. Discarders intentionally filter out events that can never match a rule. The Agent learns which events to filter out with discarders during runtime. diff --git a/hugo/content/en/security/cloud_security_management/guide/eBPF-free-agent.md b/hugo/content/en/security/cloud_security_management/guide/eBPF-free-agent.md index e26cb4e7215..5b235be3165 100644 --- a/hugo/content/en/security/cloud_security_management/guide/eBPF-free-agent.md +++ b/hugo/content/en/security/cloud_security_management/guide/eBPF-free-agent.md @@ -3,7 +3,7 @@ title: Threat Detection for Linux Without eBPF Support disable_toc: false --- -This guide describes how to set up the Workload Protection eBPF-less solution for eBPF disabled environments, such as AWS Fargate. The eBPF-less solution uses a ptrace-based Datadog Agent. +This guide describes how to set up the {{< prodname >}}Workload Protection{{< /prodname >}} eBPF-less solution for eBPF disabled environments, such as AWS Fargate. The eBPF-less solution uses a ptrace-based Datadog Agent. This guide also describes some advantages of the ptrace solution. @@ -12,7 +12,7 @@ This guide also describes some advantages of the ptrace solution. ## Summary of Agent options -Workload Protection includes two Agent options for threat detection and response: +{{< prodname >}}Workload Protection{{< /prodname >}} includes two Agent options for threat detection and response: - eBPF solution - eBPF-less solution with ptrace: This version is only available where eBPF is not (Linux kernel versions 3.4 to 4.14). @@ -152,7 +152,7 @@ runtime_security_config: Ensure you perform the following configuration requirements before deploying the Agent: 1. Customize the [Agent Installation Instructions][5] before proceeding with the installation. -2. Install/update the Agent with Cloud Security enabled. For steps, see [Setting up Cloud Security on the Agent][4]. +2. Install/update the Agent with {{< prodname >}}Cloud Security{{< /prodname >}} enabled. For steps, see [Setting up Cloud Security on the Agent][4]. 3. Specify additional configurations from the previous **eBPF-less agent setup** sections to install the custom version and enable eBPF-less mode. diff --git a/hugo/content/en/security/cloud_security_management/guide/identify-unauthorized-anomalous-procs.md b/hugo/content/en/security/cloud_security_management/guide/identify-unauthorized-anomalous-procs.md index b82e47cf542..9504723ce6c 100644 --- a/hugo/content/en/security/cloud_security_management/guide/identify-unauthorized-anomalous-procs.md +++ b/hugo/content/en/security/cloud_security_management/guide/identify-unauthorized-anomalous-procs.md @@ -7,7 +7,7 @@ further_reading: text: "Creating Custom Detection Rules" --- -You can use Workload Protection to identify if unauthorized or anomalous processes are running or executed on your IT systems. +You can use {{< prodname >}}Workload Protection{{< /prodname >}} to identify if unauthorized or anomalous processes are running or executed on your IT systems. For example, you can create a process allowlist and query for processes running on hosts and containers outside of the allowlist. diff --git a/hugo/content/en/security/cloud_security_management/guide/resource_evaluation_filters.md b/hugo/content/en/security/cloud_security_management/guide/resource_evaluation_filters.md index 5914b68662f..80985e14e31 100644 --- a/hugo/content/en/security/cloud_security_management/guide/resource_evaluation_filters.md +++ b/hugo/content/en/security/cloud_security_management/guide/resource_evaluation_filters.md @@ -9,7 +9,7 @@ further_reading: text: Setting Up Cloud Security --- -You can use resource tags to create filters that include or exclude resources from being evaluated by Cloud Security. The filters must be specified as a comma-separated list of `key:value` pairs. +You can use resource tags to create filters that include or exclude resources from being evaluated by {{< prodname >}}Cloud Security{{< /prodname >}}. The filters must be specified as a comma-separated list of `key:value` pairs. **Notes**: @@ -23,7 +23,7 @@ You can use resource tags to create filters that include or exclude resources fr | Single character wildcard | `?` | | Multiple characters wildcard | `*` | -The allowlist enables you to specify tags that must be applied to a resource in order for Cloud Security to evaluate it. Allowlist tags are evaluated as OR statements. In other words, at least one of the allowlist tags must be present in order for a resource to be evaluated. In contrast, blocklisted tags are evaluated as AND statements and take precedence over allowlist tags. +The allowlist enables you to specify tags that must be applied to a resource in order for {{< prodname >}}Cloud Security{{< /prodname >}} to evaluate it. Allowlist tags are evaluated as OR statements. In other words, at least one of the allowlist tags must be present in order for a resource to be evaluated. In contrast, blocklisted tags are evaluated as AND statements and take precedence over allowlist tags. **Examples**: diff --git a/hugo/content/en/security/cloud_security_management/guide/tuning-rules.md b/hugo/content/en/security/cloud_security_management/guide/tuning-rules.md index ab38d23db9c..b6929c05fa0 100644 --- a/hugo/content/en/security/cloud_security_management/guide/tuning-rules.md +++ b/hugo/content/en/security/cloud_security_management/guide/tuning-rules.md @@ -7,7 +7,7 @@ aliases: ## Overview -Workload Protection monitors suspicious activity occurring at the workload level. However, in some cases, benign activities are flagged as malicious because of particular settings in the user's environment. When a benign expected activity is triggering a signal, you can suppress the trigger on the activity to limit noise. +{{< prodname >}}Workload Protection{{< /prodname >}} monitors suspicious activity occurring at the workload level. However, in some cases, benign activities are flagged as malicious because of particular settings in the user's environment. When a benign expected activity is triggering a signal, you can suppress the trigger on the activity to limit noise. This guide provides considerations for best practices and steps for fine-tuning signal suppression. @@ -137,11 +137,11 @@ Additionally you might notice that signals are created even when some of your ma ## Adding a suppression from the signal -When you are in the process of investigating a potential threat reported by Workload Protection detection rules, you can encounter some signals that alert on known benign behaviors that are specific to your environment. +When you are in the process of investigating a potential threat reported by {{< prodname >}}Workload Protection{{< /prodname >}} detection rules, you can encounter some signals that alert on known benign behaviors that are specific to your environment. Consider a Java process utility exploitation. An attacker intentionally targets vulnerabilities in your application code that runs Java processes. This kind of attack entails persistent access to your application by spawning its own Java shell utility. -In some cases, Workload Protection rules might also detect expected activity, for example from your security team running a pentest session to evaluate the robustness of your applications. In this case, you can evaluate the accuracy of alerts reported and suppress noise. +In some cases, {{< prodname >}}Workload Protection{{< /prodname >}} rules might also detect expected activity, for example from your security team running a pentest session to evaluate the robustness of your applications. In this case, you can evaluate the accuracy of alerts reported and suppress noise. Open the signal details side panel and navigate from one tab to the other to gain context, including key process metadata like command-line arguments and environment variable keys. For containerized workloads, the information includes the relevant image, pod, Kubernetes cluster, and more. @@ -171,7 +171,7 @@ Signals surface relevant context within security alerts. Although event data can In Workload Protection, the runtime Agent logs are generated from collected kernel events. You can preview the logs from the signal side-panel without context switching. 1. Go to your chosen signal details side-panel and click the Events tab. -2. Click **View in Log Explorer** to navigate to Log Management, which displays the full list of logs that instigate this signal. +2. Click **View in Log Explorer** to navigate to {{< prodname >}}Log Management{{< /prodname >}}, which displays the full list of logs that instigate this signal. Because there can be many logs, the signal side-panel combines these logs and their shared attributes into a JSON structure. 3. Go back to the Events tab and scroll to the end of the panel. Expand the JSON dropdown to access all log attributes contained in runtime Agent events. 4. Identify key-value pairs to suppress signals by common keys, including `@process.args`, `@process.group`, `@process.ancestors.comm`, or `@process.ancestors.args`. diff --git a/hugo/content/en/security/cloud_security_management/identity_risks/_index.md b/hugo/content/en/security/cloud_security_management/identity_risks/_index.md index d77c0989a13..fb9b8cf113c 100644 --- a/hugo/content/en/security/cloud_security_management/identity_risks/_index.md +++ b/hugo/content/en/security/cloud_security_management/identity_risks/_index.md @@ -48,7 +48,7 @@ For detailed insights and remediation help, click the {{< ui >}}Remediation{{< / - To remediate the identity risk, you can: - Click {{< ui >}}Fix in \{{< /ui >}} to update the resource directly in your cloud provider console. - - Use [Workflow Automation][3] to create automated workflows for identity risks (with or without human involvement). + - Use [{{< prodname >}}Workflow Automation{{< /prodname >}}][3] to create automated workflows for identity risks (with or without human involvement). - For supported Terraform resources: - Locate the file and line the identity risk is in and identify the code owners. - Generate a pull request in GitHub with code changes that fix the underlying misconfiguration. @@ -72,13 +72,13 @@ In the {{< ui >}}What can this resource access?{{< /ui >}} section, you can: - Search for entities, or filter them by entity type or account - View a list of excluded policies - Use the {{< ui >}}All{{< /ui >}}, {{< ui >}}Direct Access{{< /ui >}}, and {{< ui >}}Indirect Access{{< /ui >}} tabs to filter which entities display in the table -- Click the {{< ui >}}Actions{{< /ui >}} dropdown beside an entity to see it in Resource Catalog, or update its configuration in AWS IAM console +- Click the {{< ui >}}Actions{{< /ui >}} dropdown beside an entity to see it in {{< prodname >}}Resource Catalog{{< /prodname >}}, or update its configuration in AWS IAM console In the {{< ui >}}Who can access this resource?{{< /ui >}} section, you can: - See the risks associated with each principal in the {{< ui >}}Risks{{< /ui >}} column, as well as the type of {{< ui >}}Path{{< /ui >}} the principal can take (direct or indirect) to access the resource - Filter principals by name, type, public accessibility, or administrative access - Use the {{< ui >}}All{{< /ui >}}, {{< ui >}}Direct Access{{< /ui >}}, and {{< ui >}}Indirect Access{{< /ui >}} tabs to filter which principals display in the table -- Click the {{< ui >}}Actions{{< /ui >}} dropdown beside a principal to see it in Resource Catalog, or update its configuration in AWS IAM console +- Click the {{< ui >}}Actions{{< /ui >}} dropdown beside a principal to see it in {{< prodname >}}Resource Catalog{{< /prodname >}}, or update its configuration in AWS IAM console ## AWS IAM Access Analyzer integration diff --git a/hugo/content/en/security/cloud_security_management/misconfigurations/_index.md b/hugo/content/en/security/cloud_security_management/misconfigurations/_index.md index e7046012a9b..0d01127475d 100644 --- a/hugo/content/en/security/cloud_security_management/misconfigurations/_index.md +++ b/hugo/content/en/security/cloud_security_management/misconfigurations/_index.md @@ -47,7 +47,7 @@ Investigate details using the [Misconfigurations Findings page][10], where you c To remediate a misconfiguration, you can: - [Create a ticket][15] and assign it to a team -- Use [Workflow Automation][14] to create automated remediation workflows (with or without human involvement) +- Use [{{< prodname >}}Workflow Automation{{< /prodname >}}][14] to create automated remediation workflows (with or without human involvement) - For supported Terraform resources: - Locate the file and line the misconfiguration is in and identify the code owners - Generate a pull request in GitHub with code changes that fix the underlying misconfiguration @@ -55,12 +55,12 @@ To remediate a misconfiguration, you can: ## Get started {{< learning-center-callout header="Try Detect, Prioritize, and Remediate Cloud Security Risks with Datadog Cloud Security in the Learning Center" btn_title="Enroll Now" btn_url="https://learn.datadoghq.com/courses/csm-misconfigurations">}} - The Datadog Learning Center is full of hands-on courses to help you learn about this topic. Enroll at no cost to learn how to secure your cloud environments with Cloud Security misconfigurations. + The Datadog Learning Center is full of hands-on courses to help you learn about this topic. Enroll at no cost to learn how to secure your cloud environments with {{< prodname >}}Cloud Security{{< /prodname >}} misconfigurations. {{< /learning-center-callout >}} {{< whatsnext >}} {{< nextlink href="/security/cloud_security_management/setup">}}Complete setup and configuration{{< /nextlink >}} - {{< nextlink href="/getting_started/cloud_security_management">}}Getting Started with Cloud Security{{< /nextlink >}} + {{< nextlink href="/getting_started/cloud_security_management">}}Getting Started with {{< prodname >}}Cloud Security{{< /prodname >}}{{< /nextlink >}} {{< nextlink href="/account_management/rbac/permissions/#cloud-security-platform">}}Datadog role permissions for Cloud Security Misconfigurations{{< /nextlink >}} {{< nextlink href="/security/default_rules/#cat-posture-management-cloud">}}Out-of-the-box cloud detection rules for Cloud Security Misconfigurations{{< /nextlink >}} {{< nextlink href="/security/default_rules/#cat-posture-management-infra">}}Out-of-the-box infrastructure detection rules for Cloud Security Misconfigurations{{< /nextlink >}} diff --git a/hugo/content/en/security/cloud_security_management/misconfigurations/findings/_index.md b/hugo/content/en/security/cloud_security_management/misconfigurations/findings/_index.md index 85e9583d7d5..519ed9b4470 100644 --- a/hugo/content/en/security/cloud_security_management/misconfigurations/findings/_index.md +++ b/hugo/content/en/security/cloud_security_management/misconfigurations/findings/_index.md @@ -22,7 +22,7 @@ The Cloud Security Misconfigurations [Findings page][1] allows you to: - Read descriptions and guidelines based on industry resources for remediating a misconfigured resource. - Use the time selector to explore your security configuration posture at any point in the past. -In addition to reviewing and responding to misconfigurations, you can set notifications for failed misconfigurations, and configure signals to correlate and triage misconfigurations in the same view as real-time threats generated by [Cloud SIEM][2] and [Workload Protection][3]. This enables you to accelerate investigations, as the root causes for many of today's cloud breaches are misconfigured services that have been exploited by attackers. +In addition to reviewing and responding to misconfigurations, you can set notifications for failed misconfigurations, and configure signals to correlate and triage misconfigurations in the same view as real-time threats generated by [{{< prodname >}}Cloud SIEM{{< /prodname >}}][2] and [{{< prodname >}}Workload Protection{{< /prodname >}}][3]. This enables you to accelerate investigations, as the root causes for many of today's cloud breaches are misconfigured services that have been exploited by attackers. ## Misconfigurations diff --git a/hugo/content/en/security/cloud_security_management/misconfigurations/frameworks_and_benchmarks/custom_frameworks.md b/hugo/content/en/security/cloud_security_management/misconfigurations/frameworks_and_benchmarks/custom_frameworks.md index c05da7e067c..3937b1d69da 100644 --- a/hugo/content/en/security/cloud_security_management/misconfigurations/frameworks_and_benchmarks/custom_frameworks.md +++ b/hugo/content/en/security/cloud_security_management/misconfigurations/frameworks_and_benchmarks/custom_frameworks.md @@ -17,7 +17,7 @@ further_reading: text: "Securing Datadog's cloud infrastructure: Our playbook and methodology" --- -With custom frameworks, you can define and measure compliance against your own cloud security baseline. Custom frameworks are listed on the Cloud Security [Compliance][6] page, have their own real-time report and [security posture score][7], and are queryable within explorers and dashboards. +With custom frameworks, you can define and measure compliance against your own cloud security baseline. Custom frameworks are listed on the {{< prodname >}}Cloud Security{{< /prodname >}} [Compliance][6] page, have their own real-time report and [security posture score][7], and are queryable within explorers and dashboards. 1. On the [Cloud Security Compliance page][6], click **Create Framework**. 1. Enter the following details: diff --git a/hugo/content/en/security/cloud_security_management/misconfigurations/frameworks_and_benchmarks/supported_frameworks.md b/hugo/content/en/security/cloud_security_management/misconfigurations/frameworks_and_benchmarks/supported_frameworks.md index 56d80aa5f32..79f28354fc6 100644 --- a/hugo/content/en/security/cloud_security_management/misconfigurations/frameworks_and_benchmarks/supported_frameworks.md +++ b/hugo/content/en/security/cloud_security_management/misconfigurations/frameworks_and_benchmarks/supported_frameworks.md @@ -66,7 +66,7 @@ Cloud Security Misconfigurations comes with more than 1,000 out-of-the-box compl | [UK Cyber Essentials][42] | 2024 | `cyber-essentials` | Cloud | | [Singapore MAS TRM][41] | 2021 | `mas-trm` | Cloud | -*To pass the Monitoring Section of the [CIS AWS Foundations benchmark][2], you **must** enable [Cloud SIEM][11] and forward [CloudTrail logs to Datadog][12]. +*To pass the Monitoring Section of the [CIS AWS Foundations benchmark][2], you **must** enable [{{< prodname >}}Cloud SIEM{{< /prodname >}}][11] and forward [CloudTrail logs to Datadog][12]. **Some [CIS Kubernetes Benchmark][5] compliance rules only apply to self-hosted Kubernetes clusters. diff --git a/hugo/content/en/security/cloud_security_management/misconfigurations/kspm.md b/hugo/content/en/security/cloud_security_management/misconfigurations/kspm.md index d9a73809a85..e1800234b1c 100644 --- a/hugo/content/en/security/cloud_security_management/misconfigurations/kspm.md +++ b/hugo/content/en/security/cloud_security_management/misconfigurations/kspm.md @@ -11,7 +11,7 @@ further_reading: text: "Create Custom Rules" --- -Kubernetes Security Posture Management (KSPM) for Cloud Security helps you proactively strengthen the security posture of your Kubernetes deployments by benchmarking your environment against established industry best practices, such as those defined by [CIS][1], or your own [custom detection policies](#create-your-own-kubernetes-detection-rules). +Kubernetes Security Posture Management (KSPM) for {{< prodname >}}Cloud Security{{< /prodname >}} helps you proactively strengthen the security posture of your Kubernetes deployments by benchmarking your environment against established industry best practices, such as those defined by [CIS][1], or your own [custom detection policies](#create-your-own-kubernetes-detection-rules). ## Setting up KSPM @@ -38,7 +38,7 @@ This allows Datadog to detect risks in your Kubernetes deployments for each of t With KSPM, Datadog scans your environment for risks defined by more than 50+ out-of-the-box Kubernetes detection rules. When at least one case defined in a rule is matched over a given period of time, [a notification alert is sent][6], and a finding is generated in the [Misconfigurations explorer][11]. -Each finding contains the context you need to identify the issue's impact, such as the full resource configuration, resource-level tags, and a map of the resource's relationships with other components of your infrastructure. After you understand the problem and its impact, you can start remediating the issue by [creating a ticket][7] from within Cloud Security or by [executing a pre-defined workflow][8]. +Each finding contains the context you need to identify the issue's impact, such as the full resource configuration, resource-level tags, and a map of the resource's relationships with other components of your infrastructure. After you understand the problem and its impact, you can start remediating the issue by [creating a ticket][7] from within {{< prodname >}}Cloud Security{{< /prodname >}} or by [executing a pre-defined workflow][8]. **Note**: You can also use the [API to programmatically interact with findings][10]. @@ -46,7 +46,7 @@ Each finding contains the context you need to identify the issue's impact, such ## Assess your Kubernetes security posture against industry-standard frameworks -Cloud Security provides a [security posture score][2] that helps you understand your security and compliance status using a single metric. The score represents the percentage of your environment that satisfies all of your active out-of-the-box cloud and infrastructure detection rules. You can obtain the score for your entire organization, or for specific teams, accounts, and environments, including Kubernetes deployments. +{{< prodname >}}Cloud Security{{< /prodname >}} provides a [security posture score][2] that helps you understand your security and compliance status using a single metric. The score represents the percentage of your environment that satisfies all of your active out-of-the-box cloud and infrastructure detection rules. You can obtain the score for your entire organization, or for specific teams, accounts, and environments, including Kubernetes deployments. For an in-depth explanation on how the security posture score works, see [Security posture score][3]. diff --git a/hugo/content/en/security/cloud_security_management/review_remediate/_index.md b/hugo/content/en/security/cloud_security_management/review_remediate/_index.md index ced48f92c59..fd89099b8fb 100644 --- a/hugo/content/en/security/cloud_security_management/review_remediate/_index.md +++ b/hugo/content/en/security/cloud_security_management/review_remediate/_index.md @@ -4,8 +4,8 @@ disable_toc: true --- {{< whatsnext desc="" >}} - {{< nextlink href="/security/cloud_security_management/review_remediate/mute_issues" >}}Mute Issues in Cloud Security{{< /nextlink >}} - {{< nextlink href="/security/cloud_security_management/review_remediate/workflows" >}}Automate Security Workflows with Workflow Automation{{< /nextlink >}} + {{< nextlink href="/security/cloud_security_management/review_remediate/mute_issues" >}}Mute Issues in {{< prodname >}}Cloud Security{{< /prodname >}}{{< /nextlink >}} + {{< nextlink href="/security/cloud_security_management/review_remediate/workflows" >}}Automate Security Workflows with {{< prodname >}}Workflow Automation{{< /prodname >}}{{< /nextlink >}} {{< nextlink href="/security/cloud_security_management/review_remediate/remediate_with_ai" >}}Remediate Cloud Security findings with AI{{< /nextlink >}} {{< nextlink href="/security/cloud_security_management/review_remediate/ownership_agent" >}}Infer resource owners with the Ownership Agent{{< /nextlink >}} {{< nextlink href="/security/cloud_security_management/review_remediate/ownership_preferences" >}}Set up ownership preferences with your own data{{< /nextlink >}} diff --git a/hugo/content/en/security/cloud_security_management/review_remediate/ownership_agent.md b/hugo/content/en/security/cloud_security_management/review_remediate/ownership_agent.md index b315da5dd90..6ed363e2ebf 100644 --- a/hugo/content/en/security/cloud_security_management/review_remediate/ownership_agent.md +++ b/hugo/content/en/security/cloud_security_management/review_remediate/ownership_agent.md @@ -18,7 +18,7 @@ further_reading: The Ownership Agent analyzes cloud resources that have security findings and infers who is responsible for each one. For every resource, it produces a suggested owner—a team, service, or individual—along with a confidence score, a short explanation, and a list of the evidence signals it used. -Ownership suggestions appear in the Cloud Security side panel when you view a misconfiguration or finding. You can edit each suggestion with the correct team/service/individual, which additionally improves future inference results. +Ownership suggestions appear in the {{< prodname >}}Cloud Security{{< /prodname >}} side panel when you view a misconfiguration or finding. You can edit each suggestion with the correct team/service/individual, which additionally improves future inference results. ## Data sources @@ -74,7 +74,7 @@ Corrections and feedback are vital for tuning the agent. They also affect how th ## Automatic team assignment -By default, high-confidence ownership inferences are applied to the `team` tag on Cloud Security findings. Inferred owners then become available in other Datadog features, including the [Datadog MCP server](/mcp_server/) and automatic notification routing. +By default, high-confidence ownership inferences are applied to the `team` tag on {{< prodname >}}Cloud Security{{< /prodname >}} findings. Inferred owners then become available in other Datadog features, including the [Datadog MCP server](/mcp_server/) and automatic notification routing. To adjust the confidence threshold or turn off automatic team assignment, use the [ownership settings page](https://app.datadoghq.com/security/configuration/csm/ownership-agent). diff --git a/hugo/content/en/security/cloud_security_management/review_remediate/ownership_preferences.md b/hugo/content/en/security/cloud_security_management/review_remediate/ownership_preferences.md index 8bee1b58a96..7f69ceed5aa 100644 --- a/hugo/content/en/security/cloud_security_management/review_remediate/ownership_preferences.md +++ b/hugo/content/en/security/cloud_security_management/review_remediate/ownership_preferences.md @@ -367,7 +367,7 @@ Replace `api.datadoghq.com` with your [Datadog site URL][4] if applicable (for e - **Tag mappings** add ownership candidates based on your tag rules. - **Exclusions** remove unwanted handles from results. - **Custom prompt text** guides the AI inference engine. -5. Updated results appear in the Cloud Security posture management UI. +5. Updated results appear in the {{< prodname >}}Cloud Security{{< /prodname >}} posture management UI. Changes to your reference table take effect within **24 hours**. diff --git a/hugo/content/en/security/cloud_security_management/review_remediate/remediate_with_ai.md b/hugo/content/en/security/cloud_security_management/review_remediate/remediate_with_ai.md index 09cced6bd03..3379d9e61e4 100644 --- a/hugo/content/en/security/cloud_security_management/review_remediate/remediate_with_ai.md +++ b/hugo/content/en/security/cloud_security_management/review_remediate/remediate_with_ai.md @@ -24,20 +24,20 @@ products: ## Overview -A misconfiguration finding tells you what is wrong with a cloud resource. **Remediate with AI** turns that finding into a code change: Datadog builds a prompt that describes the finding, the affected resource, and the fix. From there, you can hand it off to [Bits Code][1] to open a pull request, open Cursor with the prompt ready to run, or copy the prompt into the coding agent you already use. +A misconfiguration finding tells you what is wrong with a cloud resource. **Remediate with AI** turns that finding into a code change: Datadog builds a prompt that describes the finding, the affected resource, and the fix. From there, you can hand it off to [{{< prodname >}}Bits Code{{< /prodname >}}][1] to open a pull request, open Cursor with the prompt ready to run, or copy the prompt into the coding agent you already use. {{< img src="security/csm/remediate_with_ai_button.png" alt="The Next Steps section of a finding side panel, showing a Remediate with AI button under Remediation" style="width:50%;" >}} ## Prerequisites -Copying a fix prompt for your own coding agent requires no setup. To have Bits Code generate the fix, you need: +Copying a fix prompt for your own coding agent requires no setup. To have {{< prodname >}}Bits Code{{< /prodname >}} generate the fix, you need: - The [`Bits Code Write` (`bits_dev_write`) permission][8] in Datadog. -- Bits Code [set up][5] for your source control provider. +- {{< prodname >}}Bits Code{{< /prodname >}} [set up][5] for your source control provider. -Bits Code resolves fixes most reliably when Datadog knows where the affected resource is defined in your code. See [Code Locations][6] for how that mapping is established. +{{< prodname >}}Bits Code{{< /prodname >}} resolves fixes most reliably when Datadog knows where the affected resource is defined in your code. See [Code Locations][6] for how that mapping is established. -Bits Code usage is billed through [AI Credits][7]. +{{< prodname >}}Bits Code{{< /prodname >}} usage is billed through [AI Credits][7]. ## Remediate a finding @@ -50,8 +50,8 @@ Bits Code usage is billed through [AI Credits][7]. - **Fix with Cursor**: Click **Open** to open Cursor with a prompt tailored to the finding, so you can run the fix without copying anything. - **Copy fix prompt**: Click **Copy**, then paste the prompt into the coding agent you already use. The prompt describes the finding and the change required, so the agent can make the fix in your repository. - On the **Bits Code** tab, click either button: - - **Fix with Bits**: Bits Code starts a [session][3], locates the code that defines the resource, generates the fix, and opens a pull or merge request in your source control provider for review. - - **Create Automation**: Bits Code fixes similar findings for you as they appear, without you opening each one. For more information, see [Bits Code Automations][4]. + - **Fix with Bits**: {{< prodname >}}Bits Code{{< /prodname >}} starts a [session][3], locates the code that defines the resource, generates the fix, and opens a pull or merge request in your source control provider for review. + - **Create Automation**: {{< prodname >}}Bits Code{{< /prodname >}} fixes similar findings for you as they appear, without you opening each one. For more information, see [Bits Code Automations][4]. {{< img src="security/csm/remediate_with_ai_coding_agent_with_cursor.png" alt="The Remediate with AI dialog on the Coding agent tab, showing Fix with Cursor and Copy fix prompt options" style="width:100%;" >}} diff --git a/hugo/content/en/security/cloud_security_management/review_remediate/workflows.md b/hugo/content/en/security/cloud_security_management/review_remediate/workflows.md index 2185805066f..02e75e7d36e 100644 --- a/hugo/content/en/security/cloud_security_management/review_remediate/workflows.md +++ b/hugo/content/en/security/cloud_security_management/review_remediate/workflows.md @@ -26,11 +26,11 @@ site_support_id: workflows [Datadog Workflow Automation][1] allows you to orchestrate and automate your end-to-end processes by building workflows made up of actions that connect to your infrastructure and tools. -Use Workflow Automation with [Cloud Security][2] to automate your security-related workflows. For example, you can create workflows that allow you to [block access to a public Amazon S3 bucket via an interactive Slack message](#block-access-to-aws-s3-bucket-via-slack), or [automatically create a Jira issue and assign it to a team](#automatically-create-and-assign-a-jira-issue). +Use Workflow Automation with [{{< prodname >}}Cloud Security{{< /prodname >}}][2] to automate your security-related workflows. For example, you can create workflows that allow you to [block access to a public Amazon S3 bucket via an interactive Slack message](#block-access-to-aws-s3-bucket-via-slack), or [automatically create a Jira issue and assign it to a team](#automatically-create-and-assign-a-jira-issue). ## Understanding how triggers and sources work -Workflow Automation allows you to trigger a workflow manually or automatically. In the following examples, the workflows are triggered manually by clicking the **Run Workflow** button in the **Next Steps** box at the top of the side panel. +{{< prodname >}}Workflow Automation{{< /prodname >}} allows you to trigger a workflow manually or automatically. In the following examples, the workflows are triggered manually by clicking the **Run Workflow** button in the **Next Steps** box at the top of the side panel. When you trigger a workflow, the [source object variables][7] specified in the trigger are passed into the workflow and can be used in subsequent steps. In the following examples, the trigger event is a new security finding. diff --git a/hugo/content/en/security/cloud_security_management/setup/_index.md b/hugo/content/en/security/cloud_security_management/setup/_index.md index 662c92b090d..f32f428c1b2 100644 --- a/hugo/content/en/security/cloud_security_management/setup/_index.md +++ b/hugo/content/en/security/cloud_security_management/setup/_index.md @@ -28,7 +28,7 @@ further_reading: ## Overview -To get started with Cloud Security, review the following: +To get started with {{< prodname >}}Cloud Security{{< /prodname >}}, review the following: - [Enable Agentless Scanning](#enable-agentless-scanning) - [Deploy the Agent for additional coverage](#deploy-the-agent-for-additional-coverage) @@ -45,7 +45,7 @@ To get started with Cloud Security, review the following:
Agentless Scanning is not available in the selected site ({{< region-param key="dd_site_name" >}}).
{{< /site-region >}} -The simplest way to get started with Cloud Security is by [enabling Agentless Scanning][1]. Agentless Scanning provides the broadest coverage across your AWS, Azure, and GCP cloud infrastructure: it scans all hosts, running containers, and other supported workloads without requiring you to install anything on individual resources. +The simplest way to get started with {{< prodname >}}Cloud Security{{< /prodname >}} is by [enabling Agentless Scanning][1]. Agentless Scanning provides the broadest coverage across your AWS, Azure, and GCP cloud infrastructure: it scans all hosts, running containers, and other supported workloads without requiring you to install anything on individual resources. To learn more about Agentless Scanning, see [Cloud Security Agentless Scanning][2]. @@ -122,7 +122,7 @@ Monitor your compliance security coverage and secure your cloud infrastructure a ## Disable Cloud Security -For information on disabling Cloud Security, see the following: +For information on disabling {{< prodname >}}Cloud Security{{< /prodname >}}, see the following: - [Disable Cloud Security Vulnerabilities][8] diff --git a/hugo/content/en/security/cloud_security_management/setup/agent/_index.md b/hugo/content/en/security/cloud_security_management/setup/agent/_index.md index c5c785c9cc2..ededb6a09c5 100644 --- a/hugo/content/en/security/cloud_security_management/setup/agent/_index.md +++ b/hugo/content/en/security/cloud_security_management/setup/agent/_index.md @@ -7,7 +7,7 @@ aliases: - /security/cloud_security_management/setup/csm_enterprise/agent --- -Use the following instructions to enable Cloud Security features (Misconfigurations and Vulnerability Management) on the Datadog Agent. +Use the following instructions to enable {{< prodname >}}Cloud Security{{< /prodname >}} features (Misconfigurations and Vulnerability Management) on the Datadog Agent. {{< partial name="security-platform/CSW-billing-note.html" >}} diff --git a/hugo/content/en/security/cloud_security_management/setup/agent/docker.md b/hugo/content/en/security/cloud_security_management/setup/agent/docker.md index fdd9f301d98..84199258887 100644 --- a/hugo/content/en/security/cloud_security_management/setup/agent/docker.md +++ b/hugo/content/en/security/cloud_security_management/setup/agent/docker.md @@ -74,7 +74,7 @@ When enabled, the Agent uses eBPF to observe file access on your workloads and a - Linux only (eBPF dependency) - Applies to operating system packages in container image vulnerability findings -**Note**: Use Datadog Agent **7.79.0 or later**. Earlier Agent versions enable this feature through [Workload Protection][4] and can affect its usage. From 7.79.0, runtime package prioritization runs independently and does not affect its usage. +**Note**: Use Datadog Agent **7.79.0 or later**. Earlier Agent versions enable this feature through [{{< prodname >}}Workload Protection{{< /prodname >}}][4] and can affect its usage. From 7.79.0, runtime package prioritization runs independently and does not affect its usage. Add `DD_SBOM_ENRICHMENT_USAGE_ENABLED=true` to your Docker run command: @@ -88,7 +88,7 @@ docker run -d --name dd-agent \ registry.datadoghq.com/agent:7 {{< /code-block >}} -**Note**: `DD_SBOM_ENRICHMENT_USAGE_ENABLED=true` is in Preview and requires Datadog Agent **7.79.0 or later**. From 7.79.0, runtime package prioritization runs independently of [Workload Protection][4] and does not affect its usage. +**Note**: `DD_SBOM_ENRICHMENT_USAGE_ENABLED=true` is in Preview and requires Datadog Agent **7.79.0 or later**. From 7.79.0, runtime package prioritization runs independently of [{{< prodname >}}Workload Protection{{< /prodname >}}][4] and does not affect its usage. [1]: /security/cloud_security_management/misconfigurations/ [2]: /security/threats diff --git a/hugo/content/en/security/cloud_security_management/setup/agent/kubernetes.md b/hugo/content/en/security/cloud_security_management/setup/agent/kubernetes.md index 820dc761928..2316769bc48 100644 --- a/hugo/content/en/security/cloud_security_management/setup/agent/kubernetes.md +++ b/hugo/content/en/security/cloud_security_management/setup/agent/kubernetes.md @@ -166,7 +166,7 @@ Use the following instructions to enable Misconfigurations and Vulnerability Man {{< /tabs >}} -**Note**: `enrichment.usage.enabled: true` is in Preview and requires Datadog Agent **7.79.0 or later**. From 7.79.0, runtime package prioritization runs independently of [Workload Protection][8] and does not affect its usage. See the [Runtime Package Prioritization](#runtime-package-prioritization-preview) section for more details. +**Note**: `enrichment.usage.enabled: true` is in Preview and requires Datadog Agent **7.79.0 or later**. From 7.79.0, runtime package prioritization runs independently of [{{< prodname >}}Workload Protection{{< /prodname >}}][8] and does not affect its usage. See the [Runtime Package Prioritization](#runtime-package-prioritization-preview) section for more details. **Note**: The `languages` analyzer requires Datadog Agent **7.70 or later**. When enabled, it detects vulnerabilities in application libraries managed by the package managers below, in addition to OS packages. When the `analyzers` field is omitted, Datadog only scans OS packages for container images. @@ -209,7 +209,7 @@ When enabled, the Agent uses eBPF to observe file access on your workloads and a - Linux only (eBPF dependency). - Applies to operating system packages in container image vulnerability findings. -**Note**: Use Datadog Agent **7.79.0 or later**. Earlier Agent versions enable this feature through [Workload Protection][8] and can affect its usage. From 7.79.0, runtime package prioritization runs independently and does not affect its usage. +**Note**: Use Datadog Agent **7.79.0 or later**. Earlier Agent versions enable this feature through [{{< prodname >}}Workload Protection{{< /prodname >}}][8] and can affect its usage. From 7.79.0, runtime package prioritization runs independently and does not affect its usage. {{< tabs >}} diff --git a/hugo/content/en/security/cloud_security_management/setup/agent/linux.md b/hugo/content/en/security/cloud_security_management/setup/agent/linux.md index 1b8fcf2ee5a..1328a36b06d 100644 --- a/hugo/content/en/security/cloud_security_management/setup/agent/linux.md +++ b/hugo/content/en/security/cloud_security_management/setup/agent/linux.md @@ -51,7 +51,7 @@ sbom: enabled: true {{< /code-block >}} -**Note**: `enrichment.usage.enabled: true` is in Preview and requires Datadog Agent **7.79.0 or later**. From 7.79.0, runtime package prioritization runs independently of [Workload Protection][7] and does not affect its usage. See the [Runtime Package Prioritization](#runtime-package-prioritization-preview) section for more details. +**Note**: `enrichment.usage.enabled: true` is in Preview and requires Datadog Agent **7.79.0 or later**. From 7.79.0, runtime package prioritization runs independently of [{{< prodname >}}Workload Protection{{< /prodname >}}][7] and does not affect its usage. See the [Runtime Package Prioritization](#runtime-package-prioritization-preview) section for more details. {{< code-block lang="bash" filename="/etc/datadog-agent/security-agent.yaml" disable_copy="false" collapsible="true" >}} compliance_config: @@ -104,7 +104,7 @@ When enabled, the Agent uses eBPF to observe file access on your workloads and a - Linux only (eBPF dependency) - Applies to operating system packages in container image vulnerability findings -**Note**: Use Datadog Agent **7.79.0 or later**. Earlier Agent versions enable this feature through [Workload Protection][7] and can affect its usage. From 7.79.0, runtime package prioritization runs independently and does not affect its usage. +**Note**: Use Datadog Agent **7.79.0 or later**. Earlier Agent versions enable this feature through [{{< prodname >}}Workload Protection{{< /prodname >}}][7] and can affect its usage. From 7.79.0, runtime package prioritization runs independently and does not affect its usage. Add the `enrichment` block to the `sbom` section of your `datadog.yaml` file: diff --git a/hugo/content/en/security/cloud_security_management/setup/agentless_scanning/enable.md b/hugo/content/en/security/cloud_security_management/setup/agentless_scanning/enable.md index 37a415a8acd..559d21a7678 100644 --- a/hugo/content/en/security/cloud_security_management/setup/agentless_scanning/enable.md +++ b/hugo/content/en/security/cloud_security_management/setup/agentless_scanning/enable.md @@ -117,7 +117,7 @@ Select your cloud provider to see the available setup methods. If you are settin ### Choose your setup -- **New to Datadog**: On the [Intro to Cloud Security][2] page, click {{< ui >}}Get Started with Cloud Security{{< /ui >}}, then click {{< ui >}}Quick Start{{< /ui >}}. Quick Start is a guided setup flow that uses AWS CloudFormation to deploy Agentless Scanning with all Cloud Security features pre-enabled. It is only available for organizations that have not yet set up Cloud Security Management. +- **New to Datadog**: On the [Intro to Cloud Security][2] page, click {{< ui >}}Get Started with {{< prodname >}}Cloud Security{{< /prodname >}}{{< /ui >}}, then click {{< ui >}}Quick Start{{< /ui >}}. Quick Start is a guided setup flow that uses AWS CloudFormation to deploy Agentless Scanning with all {{< prodname >}}Cloud Security{{< /prodname >}} features pre-enabled. It is only available for organizations that have not yet set up Cloud Security Management. - **Single AWS account in Datadog**: Use [CloudFormation](#aws-cloudformation-setup) or [Terraform](#aws-terraform-setup). Terraform is recommended for multi-region deployments. - **AWS organization with multiple accounts**: Use [CloudFormation StackSet](#aws-cloudformation-stackset-setup) to deploy scanning capabilities across all member accounts. - **Multiple accounts without AWS Organizations**: Repeat the [CloudFormation](#aws-cloudformation-setup) or [Terraform](#aws-terraform-setup) setup for each account individually. diff --git a/hugo/content/en/security/cloud_security_management/setup/ci_cd/_index.md b/hugo/content/en/security/cloud_security_management/setup/ci_cd/_index.md index a7e753eb093..53367f2e52d 100644 --- a/hugo/content/en/security/cloud_security_management/setup/ci_cd/_index.md +++ b/hugo/content/en/security/cloud_security_management/setup/ci_cd/_index.md @@ -15,7 +15,7 @@ further_reading: ## Overview -Cloud Security enables you to scan container images for vulnerabilities during CI/CD, before images are deployed to production. By integrating vulnerability scanning directly into your pipelines, you can detect and remediate security issues early in the development lifecycle. +{{< prodname >}}Cloud Security{{< /prodname >}} enables you to scan container images for vulnerabilities during CI/CD, before images are deployed to production. By integrating vulnerability scanning directly into your pipelines, you can detect and remediate security issues early in the development lifecycle. To support CI/CD-based container image scanning, Datadog provides the **Datadog Security CLI**. The CLI is designed to be run directly inside your CI jobs, giving you full control over when and how scans are executed as part of your pipelines. diff --git a/hugo/content/en/security/cloud_security_management/setup/cloud_integrations.md b/hugo/content/en/security/cloud_security_management/setup/cloud_integrations.md index 568ec35e58e..399303bde4c 100644 --- a/hugo/content/en/security/cloud_security_management/setup/cloud_integrations.md +++ b/hugo/content/en/security/cloud_security_management/setup/cloud_integrations.md @@ -14,7 +14,7 @@ Use the following instructions to enable Misconfigurations and Identity Risks (C ## Enable Posture Management -To enable Posture Management for your cloud accounts, you must first set up the integration and then enable Cloud Security for each AWS, Azure, Google Cloud Platform, or Oracle Cloud Infrastructure account. +To enable Posture Management for your cloud accounts, you must first set up the integration and then enable {{< prodname >}}Cloud Security{{< /prodname >}} for each AWS, Azure, Google Cloud Platform, or Oracle Cloud Infrastructure account. {{< partial name="security-platform/CSW-billing-note.html" >}} @@ -28,9 +28,9 @@ If you haven't already, set up the [Amazon Web Services integration][1]. You mus ### Enable Cloud Security for your AWS accounts 1. On the [{{< ui >}}Cloud Security Setup{{< /ui >}}][3] page, click {{< ui >}}Cloud Integrations{{< /ui >}}. -1. Expand the {{< ui >}}AWS{{< /ui >}} section and click the account you want to enable Cloud Security for. A side panel with configuration options for that account opens. +1. Expand the {{< ui >}}AWS{{< /ui >}} section and click the account you want to enable {{< prodname >}}Cloud Security{{< /prodname >}} for. A side panel with configuration options for that account opens. 1. Under {{< ui >}}Features{{< /ui >}}, beside each feature you want to enable, turn on the {{< ui >}}Enable{{< /ui >}} toggle. -1. To create a filter that excludes certain resources from being evaluated by Cloud Security, under {{< ui >}}Evaluation Filters{{< /ui >}}, click {{< ui >}}Limit to Specific Resources{{< /ui >}}. Then, click {{< ui >}}Add Resource Tags{{< /ui >}}, add `key:value` tags as required, and click {{< ui >}}Save{{< /ui >}}. For more information, see [Use Filters to Exclude Resources from Evaluation][5]. +1. To create a filter that excludes certain resources from being evaluated by {{< prodname >}}Cloud Security{{< /prodname >}}, under {{< ui >}}Evaluation Filters{{< /ui >}}, click {{< ui >}}Limit to Specific Resources{{< /ui >}}. Then, click {{< ui >}}Add Resource Tags{{< /ui >}}, add `key:value` tags as required, and click {{< ui >}}Save{{< /ui >}}. For more information, see [Use Filters to Exclude Resources from Evaluation][5]. [1]: /integrations/amazon_web_services/ [2]: /integrations/amazon_web_services/?tab=roledelegation#cloud-security-management @@ -65,7 +65,7 @@ If you haven't already, set up the [Microsoft Azure integration][1]. 1. On the [{{< ui >}}Cloud Security Setup{{< /ui >}}][3] page, click {{< ui >}}Cloud Integrations{{< /ui >}}. 1. Expand the {{< ui >}}Azure{{< /ui >}} section. 2. To enable Posture Management for an account, switch the {{< ui >}}Posture Management{{< /ui >}} toggle to the on position. -3. To create a filter that excludes certain resources from being evaluated by Cloud Security, click the subscription you want to filter on. A side panel with configuration options opens. Then, click {{< ui >}}Add Resource Tags{{< /ui >}}, add `key:value` tags as required, and click {{< ui >}}Save{{< /ui >}}. For more information, see [Use Filters to Exclude Resources from Evaluation][4]. +3. To create a filter that excludes certain resources from being evaluated by {{< prodname >}}Cloud Security{{< /prodname >}}, click the subscription you want to filter on. A side panel with configuration options opens. Then, click {{< ui >}}Add Resource Tags{{< /ui >}}, add `key:value` tags as required, and click {{< ui >}}Save{{< /ui >}}. For more information, see [Use Filters to Exclude Resources from Evaluation][4]. [1]: /integrations/azure [2]: /integrations/guide/azure-graph-api-permissions/ @@ -97,7 +97,7 @@ The Datadog Google Cloud Platform integration uses service accounts to create an 1. On the [{{< ui >}}Cloud Security Setup{{< /ui >}}][2] page, click {{< ui >}}Cloud Integrations{{< /ui >}}. 1. Expand the {{< ui >}}GCP{{< /ui >}} section. 2. To enable Posture Management for an account, switch the {{< ui >}}Posture Management{{< /ui >}} toggle to the on position. -3. To create a filter that excludes certain resources from being evaluated by Cloud Security, click the project you want to filter on. A side panel with configuration options opens. Then, click {{< ui >}}Add Resource Tags{{< /ui >}}, add `key:value` tags as required, and click {{< ui >}}Save{{< /ui >}}. For more information, see [Use Filters to Exclude Resources from Evaluation][11]. +3. To create a filter that excludes certain resources from being evaluated by {{< prodname >}}Cloud Security{{< /prodname >}}, click the project you want to filter on. A side panel with configuration options opens. Then, click {{< ui >}}Add Resource Tags{{< /ui >}}, add `key:value` tags as required, and click {{< ui >}}Save{{< /ui >}}. For more information, see [Use Filters to Exclude Resources from Evaluation][11]. [1]: /integrations/google_cloud_platform [2]: https://app.datadoghq.com/security/configuration/csm/setup @@ -121,7 +121,7 @@ If you haven't already, set up the [Oracle Cloud Infrastructure integration][1]. 1. On the [{{< ui >}}Cloud Security Setup{{< /ui >}}][2] page, click {{< ui >}}Cloud Integrations{{< /ui >}}. 1. Expand the {{< ui >}}OCI{{< /ui >}} section. 1. To enable Posture Management for a tenancy, switch the {{< ui >}}Posture Management{{< /ui >}} toggle to the on position. -1. To create a filter that excludes certain resources from being evaluated by Cloud Security, click the {{< ui >}}Plus{{< /ui >}} (+) icon under {{< ui >}}Resource Evaluation Filters{{< /ui >}}. For more information, see [Use Filters to Exclude Resources from Evaluation][3]. +1. To create a filter that excludes certain resources from being evaluated by {{< prodname >}}Cloud Security{{< /prodname >}}, click the {{< ui >}}Plus{{< /ui >}} (+) icon under {{< ui >}}Resource Evaluation Filters{{< /ui >}}. For more information, see [Use Filters to Exclude Resources from Evaluation][3]. 1. Click {{< ui >}}Done{{< /ui >}}. [1]: /integrations/oracle-cloud-infrastructure/ diff --git a/hugo/content/en/security/cloud_security_management/setup/iac_remediation.md b/hugo/content/en/security/cloud_security_management/setup/iac_remediation.md index 8400883603e..6ca1f2b54b7 100644 --- a/hugo/content/en/security/cloud_security_management/setup/iac_remediation.md +++ b/hugo/content/en/security/cloud_security_management/setup/iac_remediation.md @@ -15,7 +15,7 @@ further_reading: text: "Cloud Security Identity Risks" --- -Use the following instructions to enable Infrastructure as Code (IaC) remediation for Cloud Security. IaC remediation is available for [Cloud Security Misconfigurations][1] and [Cloud Security Identity Risks][2]. +Use the following instructions to enable Infrastructure as Code (IaC) remediation for {{< prodname >}}Cloud Security{{< /prodname >}}. IaC remediation is available for [Cloud Security Misconfigurations][1] and [Cloud Security Identity Risks][2].
Static IaC remediation supports GitHub for version control and Terraform for infrastructure as code.
@@ -30,7 +30,7 @@ Follow [the instructions][3] for creating a GitHub app for your organization. After you set up the GitHub integration, enable IaC remediation for the repositories in your GitHub account. -1. On the [Cloud Security Setup page][4], expand the {{< ui >}}Source Code Integrations{{< /ui >}} section. +1. On the [Cloud Security Setup page][4], expand the {{< ui >}}{{< prodname >}}Source Code Integration{{< /prodname >}}s{{< /ui >}} section. 2. Click {{< ui >}}Configure{{< /ui >}} for the GitHub account you want to configure. 3. To enable IaC: - All repositories: Toggle {{< ui >}}Enable Infrastructure as Code (IaC) Remediation{{< /ui >}} to the on position. diff --git a/hugo/content/en/security/cloud_security_management/setup/supported_deployment_types.md b/hugo/content/en/security/cloud_security_management/setup/supported_deployment_types.md index d70c61548a9..f424b123c58 100644 --- a/hugo/content/en/security/cloud_security_management/setup/supported_deployment_types.md +++ b/hugo/content/en/security/cloud_security_management/setup/supported_deployment_types.md @@ -4,7 +4,7 @@ title: Cloud Security Supported Deployment Types {{< partial name="security-platform/CSW-billing-note.html" >}} -The following table summarizes the Cloud Security features available relative to each deployment type. +The following table summarizes the {{< prodname >}}Cloud Security{{< /prodname >}} features available relative to each deployment type. | Deployment type | Agent Required (7.46+) | Misconfigurations | Vulnerabilities | Identity Risks | Agentless Scanning | |---------------------|------------------------|-------------------|-----------------|----------------|--------------------| @@ -20,7 +20,7 @@ The following table summarizes the Cloud Security features available relative to | Windows | {{< X >}} | | {{< X >}} | | | | AWS Fargate ECS/EKS | {{< X >}} | | | | ECS Fargate only | -The following table summarizes the scope of coverage available relative to each Cloud Security feature. +The following table summarizes the scope of coverage available relative to each {{< prodname >}}Cloud Security{{< /prodname >}} feature. | Resources monitored | Misconfigurations | Vulnerabilities | Identity Risks | Agentless scanning | |---------------------|-------------------|-----------------|----------------|--------------------| | AWS Resources/IAM | {{< X >}} | {{< X >}} | {{< X >}} | {{< X >}} | diff --git a/hugo/content/en/security/cloud_security_management/setup/without_infrastructure_monitoring.md b/hugo/content/en/security/cloud_security_management/setup/without_infrastructure_monitoring.md index a06649f4e5c..4703b1204b5 100644 --- a/hugo/content/en/security/cloud_security_management/setup/without_infrastructure_monitoring.md +++ b/hugo/content/en/security/cloud_security_management/setup/without_infrastructure_monitoring.md @@ -4,37 +4,37 @@ title: Setting Up Cloud Security without Infrastructure Monitoring ## Set up Cloud Security with your cloud provider -In addition to setting up Cloud Security with or without an Agent, you can also set it up without Infrastructure Monitoring. Doing so disables metric data submission (including Custom Metrics) so that hosts stop showing up in Datadog. +In addition to setting up {{< prodname >}}Cloud Security{{< /prodname >}} with or without an Agent, you can also set it up without {{< prodname >}}Infrastructure Monitoring{{< /prodname >}}. Doing so disables metric data submission (including Custom Metrics) so that hosts stop showing up in Datadog. ### AWS 1. Navigate to the [AWS Integration configuration page][2] in Datadog. -1. On the {{< ui >}}Configuration{{< /ui >}} tab, select the account you want to enable Cloud Security on.
If you don't see the required account, add it by clicking {{< ui >}}Add AWS Account(s){{< /ui >}} and following the onscreen prompts. +1. On the {{< ui >}}Configuration{{< /ui >}} tab, select the account you want to enable {{< prodname >}}Cloud Security{{< /prodname >}} on.
If you don't see the required account, add it by clicking {{< ui >}}Add AWS Account(s){{< /ui >}} and following the onscreen prompts. 1. To turn off infrastructure monitoring on the selected account, under the account number, navigate to the {{< ui >}}Metric Collection{{< /ui >}} tab, then click the {{< ui >}}disable metric collection{{< /ui >}} link. Then, click {{< ui >}}Disable Metric Collection{{< /ui >}} to confirm. 1. On the {{< ui >}}Resource Collection{{< /ui >}} tab, switch the {{< ui >}}Enable Resource Collection{{< /ui >}} toggle to the on position. 1. Click {{< ui >}}Save{{< /ui >}} to complete the setup. -**Note**: In your Cloud Security settings, set up [resource evaluation filters][1] to limit the number of hosts you need security on. +**Note**: In your {{< prodname >}}Cloud Security{{< /prodname >}} settings, set up [resource evaluation filters][1] to limit the number of hosts you need security on. ### Azure 1. Navigate to the [Azure Integration configuration page][3] in Datadog. -1. Select the client ID or subscription you want to enable Cloud Security on.
If you don't see the required client ID, add it by clicking {{< ui >}}Add New App Registration{{< /ui >}} and following the onscreen prompts. +1. Select the client ID or subscription you want to enable {{< prodname >}}Cloud Security{{< /prodname >}} on.
If you don't see the required client ID, add it by clicking {{< ui >}}Add New App Registration{{< /ui >}} and following the onscreen prompts. 1. To turn off infrastructure monitoring on the selected account, under the client ID, navigate to the {{< ui >}}Metric Collection{{< /ui >}} tab, then turn off the {{< ui >}}Enable Metric Collection{{< /ui >}} toggle. 1. On the {{< ui >}}Resource Collection{{< /ui >}} tab, Switch the {{< ui >}}Enable Resource Collection{{< /ui >}} toggle to the on position. 1. Click {{< ui >}}Save{{< /ui >}} to complete the setup. -**Note**: In your Cloud Security settings, set up [resource evaluation filters][1] to limit the number of hosts you need security on. +**Note**: In your {{< prodname >}}Cloud Security{{< /prodname >}} settings, set up [resource evaluation filters][1] to limit the number of hosts you need security on. ### Google Cloud Platform 1. Navigate to the [Google Cloud Platform configuration page][4] in Datadog. -1. Select the service account you want to enable Cloud Security on.
If you don't see the required account, add it by clicking {{< ui >}}Add GCP Account{{< /ui >}} and following the onscreen prompts. +1. Select the service account you want to enable {{< prodname >}}Cloud Security{{< /prodname >}} on.
If you don't see the required account, add it by clicking {{< ui >}}Add GCP Account{{< /ui >}} and following the onscreen prompts. 1. To turn off infrastructure monitoring on the selected account, under the account name, navigate to the {{< ui >}}Metric Collection{{< /ui >}} tab. Then, above the Metric Collection table, click {{< ui >}}Disable All{{< /ui >}}. 1. On the {{< ui >}}Resource Collection{{< /ui >}} tab, switch the {{< ui >}}Enable Resource Collection{{< /ui >}} toggle to the on position. 1. Click {{< ui >}}Save{{< /ui >}} to complete the setup. -**Note**: In your Cloud Security settings, set up [resource evaluation filters][1] to limit the number of hosts you need security on. +**Note**: In your {{< prodname >}}Cloud Security{{< /prodname >}} settings, set up [resource evaluation filters][1] to limit the number of hosts you need security on. ### Oracle Cloud Infrastructure @@ -43,12 +43,12 @@ In addition to setting up Cloud Security with or without an Agent, you can also {{< /site-region >}} 1. Navigate to the [Oracle Cloud Infrastructure configuration page][5] in Datadog. -1. Select the tenancy you want to enable Cloud Security on.
If you don't see the required tenancy, add it by clicking {{< ui >}}Add New Tenancy{{< /ui >}} and following the onscreen prompts. +1. Select the tenancy you want to enable {{< prodname >}}Cloud Security{{< /prodname >}} on.
If you don't see the required tenancy, add it by clicking {{< ui >}}Add New Tenancy{{< /ui >}} and following the onscreen prompts. 1. To turn off infrastructure monitoring on the selected tenancy, under the tenancy name, navigate to the {{< ui >}}Metric Collection{{< /ui >}} tab. Then, above the Metric Collection table, click {{< ui >}}Disable All{{< /ui >}}. 1. On the {{< ui >}}Resource Collection{{< /ui >}} tab, switch the {{< ui >}}Enable Resource Collection{{< /ui >}} toggle to the on position. 1. Click {{< ui >}}Save{{< /ui >}} to complete the setup. -**Note**: In your Cloud Security settings, set up [resource evaluation filters][1] to limit the number of hosts you need security on. +**Note**: In your {{< prodname >}}Cloud Security{{< /prodname >}} settings, set up [resource evaluation filters][1] to limit the number of hosts you need security on. ## Set up the Datadog Agent diff --git a/hugo/content/en/security/cloud_security_management/triage_and_prioritize/_index.md b/hugo/content/en/security/cloud_security_management/triage_and_prioritize/_index.md index fd7a827dc25..a9d215bea4f 100644 --- a/hugo/content/en/security/cloud_security_management/triage_and_prioritize/_index.md +++ b/hugo/content/en/security/cloud_security_management/triage_and_prioritize/_index.md @@ -12,7 +12,7 @@ further_reading: text: "Review prioritized findings in the Security Inbox" --- -Cloud Security generates findings across vulnerabilities, misconfigurations, and identity risks. Triage and Prioritize covers two related capabilities: the engine that identifies the findings that expose your business-critical resources, and the scoring framework that translates that judgment into a per-finding severity score you can sort, filter, and route on. +{{< prodname >}}Cloud Security{{< /prodname >}} generates findings across vulnerabilities, misconfigurations, and identity risks. Triage and Prioritize covers two related capabilities: the engine that identifies the findings that expose your business-critical resources, and the scoring framework that translates that judgment into a per-finding severity score you can sort, filter, and route on. ## Runtime Prioritization Engine diff --git a/hugo/content/en/security/cloud_security_management/triage_and_prioritize/runtime_prioritization_engine.md b/hugo/content/en/security/cloud_security_management/triage_and_prioritize/runtime_prioritization_engine.md index a66cae25f59..0e4ca28ca5d 100644 --- a/hugo/content/en/security/cloud_security_management/triage_and_prioritize/runtime_prioritization_engine.md +++ b/hugo/content/en/security/cloud_security_management/triage_and_prioritize/runtime_prioritization_engine.md @@ -69,7 +69,7 @@ Signals persist for the lifetime of an image version: after a package is observe ## Get started -1. Deploy the Datadog Agent version 7.79 or later with Cloud Security enabled. See [Setting Up Cloud Security][3]. +1. Deploy the Datadog Agent version 7.79 or later with {{< prodname >}}Cloud Security{{< /prodname >}} enabled. See [Setting Up Cloud Security][3]. 2. Enable Runtime Package Prioritization on the Agent to surface the *Package is running* signal on vulnerability findings. See the instructions to do so for [Kubernetes][4], [Docker][9], or [Linux][10] deployments. 3. Open the [{{< ui >}}Cloud Security Summary{{< /ui >}}][5] in Datadog. Prioritized findings are surfaced at the top of each funnel and in the [{{< ui >}}Security Inbox{{< /ui >}}][6]. diff --git a/hugo/content/en/security/cloud_security_management/triage_and_prioritize/severity_scoring.md b/hugo/content/en/security/cloud_security_management/triage_and_prioritize/severity_scoring.md index b2c834b2c1c..384184f1139 100644 --- a/hugo/content/en/security/cloud_security_management/triage_and_prioritize/severity_scoring.md +++ b/hugo/content/en/security/cloud_security_management/triage_and_prioritize/severity_scoring.md @@ -17,11 +17,11 @@ further_reading: text: Visually identify and prioritize security risks using Cloudcraft --- -Accurate severity scores help security teams understand the risks that vulnerabilities pose to their environment. This guide explains how Cloud Security uses different measures of severity to calculate the scores. +Accurate severity scores help security teams understand the risks that vulnerabilities pose to their environment. This guide explains how {{< prodname >}}Cloud Security{{< /prodname >}} uses different measures of severity to calculate the scores. ## Cloud Security severity scoring framework -Cloud Security Misconfigurations, Cloud Security Identity Risks, and Security Inbox misconfigurations use the Cloud Security severity scoring framework to determine the severity of a finding. The framework compares the likelihood that an adversary would take advantage of a misconfiguration to the risk posed to your environment. By weighting both of these aspects, findings can be prioritized more accurately by real-world risks. The matrices below show how a misconfiguration's severity score is computed based on its likelihood of abuse and impact. +Cloud Security Misconfigurations, Cloud Security Identity Risks, and Security Inbox misconfigurations use the {{< prodname >}}Cloud Security{{< /prodname >}} severity scoring framework to determine the severity of a finding. The framework compares the likelihood that an adversary would take advantage of a misconfiguration to the risk posed to your environment. By weighting both of these aspects, findings can be prioritized more accurately by real-world risks. The matrices below show how a misconfiguration's severity score is computed based on its likelihood of abuse and impact. ### Likelihood @@ -91,7 +91,7 @@ To explain how the framework is used here are a few examples. The detection rule for [SNS Topic should have access restrictions set for subscription][1] checks if the SNS topic has a resource-based policy that contains a `Principal` of `*`, and an `Action` with the `sns:Subscribe` permission. This combination gives anyone the ability to subscribe to the SNS topic and receive its notifications. -Using the Cloud Security severity scoring framework, the rule would be scored as follows: +Using the {{< prodname >}}Cloud Security{{< /prodname >}} severity scoring framework, the rule would be scored as follows: - **Likelihood score**: Highly Probable - **Attack vector**: No Authorization @@ -107,7 +107,7 @@ Using the Cloud Security severity scoring framework, the rule would be scored as The detection rule for [EC2 instances should enforce IMDSv2][2] checks if an EC2 instance is using the Instance Metadata Service Version 1 ([IMDSv1][3]), which is vulnerable to common web application attacks. If exploited, an adversary can obtain access to the IAM credentials stored in the IMDS and use them to access resources in the AWS account. -Using the Cloud Security severity scoring framework, the rule would be scored as follows: +Using the {{< prodname >}}Cloud Security{{< /prodname >}} severity scoring framework, the rule would be scored as follows: - **Likelihood score**: Possible - **Attack vector**: Vulnerability diff --git a/hugo/content/en/security/cloud_security_management/troubleshooting/threats.md b/hugo/content/en/security/cloud_security_management/troubleshooting/threats.md index 7cdfc54b377..c8284619b67 100644 --- a/hugo/content/en/security/cloud_security_management/troubleshooting/threats.md +++ b/hugo/content/en/security/cloud_security_management/troubleshooting/threats.md @@ -9,7 +9,7 @@ further_reading: text: "Troubleshooting Cloud Security Vulnerabilities" --- -If you experience issues with Workload Protection, use the following troubleshooting guidelines. If you need further assistance, contact [Datadog support][1]. +If you experience issues with {{< prodname >}}Workload Protection{{< /prodname >}}, use the following troubleshooting guidelines. If you need further assistance, contact [Datadog support][1]. ## Security Agent flare @@ -29,7 +29,7 @@ If you don't have a case ID, just enter your email address used to login in Data ## Agent Self tests -In order to ensure that the communication between the `security-agent` and the `system-probe` is working as expected and that Workload Protection is able to detect system events, you can manually trigger self tests by running the following command: +In order to ensure that the communication between the `security-agent` and the `system-probe` is working as expected and that {{< prodname >}}Workload Protection{{< /prodname >}} is able to detect system events, you can manually trigger self tests by running the following command: | Platform | Command | | -------- | ------- | @@ -50,18 +50,18 @@ You can now see events coming from the `runtime-security-agent` in the {{< ui >} ## Compatibility with custom Kubernetes network plugins -The network based detections of Workload Protection rely on the traffic control sub-system of the Linux kernel. This sub-system is known to introduce race conditions if multiple vendors try to insert, replace, or delete filters on the "clsact" ingress qdisc. Follow the checklist below to ensure that Workload Protection is properly configured: +The network based detections of {{< prodname >}}Workload Protection{{< /prodname >}} rely on the traffic control sub-system of the Linux kernel. This sub-system is known to introduce race conditions if multiple vendors try to insert, replace, or delete filters on the "clsact" ingress qdisc. Follow the checklist below to ensure that {{< prodname >}}Workload Protection{{< /prodname >}} is properly configured: * Check if your vendor leverages eBPF traffic control classifiers. If they do not, you can ignore this paragraph. * Check if your vendor returns TC_ACT_OK or TC_ACT_UNSPEC after granting access to a network packet. If they return TC_ACT_UNSPEC, you can ignore this paragraph. * Check which priority your vendor attaches their eBPF classifiers to: - * If they use priority 1, Workload Protection network detections do not work inside your containers. + * If they use priority 1, {{< prodname >}}Workload Protection{{< /prodname >}} network detections do not work inside your containers. * If they use priority 2 to 10, make sure to configure `runtime_security_config.network.classifier_priority` to a number strictly below the priority chosen by your vendor. * If they use priority 11 or higher, you can ignore this paragraph. For example, there is a known race with Cilium 1.9 and lower with the Datadog Agent (version 7.36 to 7.39.1, 7.39.2 excluded) that may happen when a new pod is started. The race can lead to loss of connectivity inside the pod, depending on how Cilium is configured. -Ultimately, if the Datadog Agent or your third party vendors cannot be configured to prevent the issue from happening, you should disable the network based detections of Workload Protection by following the steps below: +Ultimately, if the Datadog Agent or your third party vendors cannot be configured to prevent the issue from happening, you should disable the network based detections of {{< prodname >}}Workload Protection{{< /prodname >}} by following the steps below: * Add the following parameter to your `system-probe.yaml` configuration file on host based installations: ```yaml @@ -83,7 +83,7 @@ DD_RUNTIME_SECURITY_CONFIG_NETWORK_ENABLED=false ``` ## Disable Workload Protection -To disable Workload Protection, follow the steps for your Agent platform. +To disable {{< prodname >}}Workload Protection{{< /prodname >}}, follow the steps for your Agent platform. ### Helm diff --git a/hugo/content/en/security/cloud_security_management/vulnerabilities/_index.md b/hugo/content/en/security/cloud_security_management/vulnerabilities/_index.md index f513cc93fad..7a73a75f431 100644 --- a/hugo/content/en/security/cloud_security_management/vulnerabilities/_index.md +++ b/hugo/content/en/security/cloud_security_management/vulnerabilities/_index.md @@ -34,7 +34,7 @@ With Cloud Security Vulnerabilities, you can manage your cloud security manageme - Pass compliance audits (such as SOC2, PCI, HIPAA, CIS, and FedRamp) - Remediate emerging vulnerabilities (0-day CVEs) -**Note**: For vulnerability management in application libraries, see [Software Composition Analysis][5]. For application code, see [Code Security][10]. +**Note**: For vulnerability management in application libraries, see [Software Composition Analysis][5]. For application code, see [{{< prodname >}}Code Security{{< /prodname >}}][10]. ## Key capabilities diff --git a/hugo/content/en/security/cloud_siem/_index.md b/hugo/content/en/security/cloud_siem/_index.md index bb8cb6059e5..7b154013d75 100644 --- a/hugo/content/en/security/cloud_siem/_index.md +++ b/hugo/content/en/security/cloud_siem/_index.md @@ -73,24 +73,24 @@ further_reading: --- {{< learning-center-callout header="Join an enablement webinar session" hide_image="true" btn_title="Sign Up" btn_url="https://www.datadoghq.com/technical-enablement/sessions/?tags.topics-0=Security">}} - Learn how Datadog Cloud SIEM and Cloud Security elevate your organization's threat detection and investigation for dynamic, cloud-scale environments. + Learn how Datadog Cloud SIEM and {{< prodname >}}Cloud Security{{< /prodname >}} elevate your organization's threat detection and investigation for dynamic, cloud-scale environments. {{< /learning-center-callout >}} ## Overview -Datadog Cloud SIEM (Security Information and Event Management) is a security data analysis and correlation system. It enables your entire security operations team to view, detect, investigate, and respond to security issues. Leveraging Datadog's scalable platform, Cloud SIEM ingests telemetry from both cloud and on‑premises systems using the Datadog Agent and API-based integrations. +Datadog Cloud SIEM (Security Information and {{< prodname >}}Event Management{{< /prodname >}}) is a security data analysis and correlation system. It enables your entire security operations team to view, detect, investigate, and respond to security issues. Leveraging Datadog's scalable platform, {{< prodname >}}Cloud SIEM{{< /prodname >}} ingests telemetry from both cloud and on‑premises systems using the Datadog Agent and API-based integrations. -Effective security response requires speed, context, insight, and automation. Cloud SIEM continuously analyzes incoming data to detect threats, generate actionable security signals, and correlate them across multiple sources. This empowers your team to investigate incidents and respond quickly. +Effective security response requires speed, context, insight, and automation. {{< prodname >}}Cloud SIEM{{< /prodname >}} continuously analyzes incoming data to detect threats, generate actionable security signals, and correlate them across multiple sources. This empowers your team to investigate incidents and respond quickly. To keep your team on top of the latest attacks, Datadog also has a team of threat researchers who analyze petabytes of telemetry across cloud and on-premises systems to identify emerging threats and attacker behaviors. See [Datadog Security Labs][1] to read articles about their recent investigations. ### Security and observability -Cloud SIEM embeds both cloud and on-premises telemetry directly into security workflows to accelerate investigation and response. And with a shared platform that brings DevOps and Security teams together, organizations can break down silos and respond to threats collaboratively and efficiently. +{{< prodname >}}Cloud SIEM{{< /prodname >}} embeds both cloud and on-premises telemetry directly into security workflows to accelerate investigation and response. And with a shared platform that brings DevOps and Security teams together, organizations can break down silos and respond to threats collaboratively and efficiently. ### Flexible cost control for security data -As your organization scales, controlling the ingestion cost of security logs without compromising visibility is critical. Cloud SIEM is integrated with Datadog Log Management so you can choose the appropriate retention and querying capability for your security logs. This flexibility helps you balance cost efficiency with your threat detection needs. +As your organization scales, controlling the ingestion cost of security logs without compromising visibility is critical. {{< prodname >}}Cloud SIEM{{< /prodname >}} is integrated with Datadog Log Management so you can choose the appropriate retention and querying capability for your security logs. This flexibility helps you balance cost efficiency with your threat detection needs. Store logs using one of the available options: - [Standard indexing][6] for logs that need to be queried frequently with the most compute. @@ -99,7 +99,7 @@ Store logs using one of the available options: ### Guided security data onboarding -Cloud SIEM [Content Packs][9] are a curated set of Datadog integrations designed for security teams. Each content pack has instructions on how to configure the integration and what is included, such as detection rules, out-of-the-box interactive dashboards, parsers, and SOAR workflows. Content Packs highlight actionable insights specific to each integration to help you investigate security issues. +{{< prodname >}}Cloud SIEM{{< /prodname >}} [Content Packs][9] are a curated set of Datadog integrations designed for security teams. Each content pack has instructions on how to configure the integration and what is included, such as detection rules, out-of-the-box interactive dashboards, parsers, and SOAR workflows. Content Packs highlight actionable insights specific to each integration to help you investigate security issues. ### Content pack health monitoring @@ -163,7 +163,7 @@ See signals grouped by rule name and sorted by severity to get an overview of th #### Recent open security cases -Use [Case Management][5] to track signals that require further analysis. View active security cases in your environment and click a case to see more details. +Use [{{< prodname >}}Case Management{{< /prodname >}}][5] to track signals that require further analysis. View active security cases in your environment and click a case to see more details. ### Risk insights @@ -242,7 +242,7 @@ See which MITRE ATT&CK techniques are generating signals. Click on a pie chart w {{< img src="security/security_monitoring/landing/07_detection_rule_performance.png" alt="" style="width:100%;" >}} -Gain a deeper understanding of detection rule performance. This section works best if you triage signals in Cloud SIEM. +Gain a deeper understanding of detection rule performance. This section works best if you triage signals in {{< prodname >}}Cloud SIEM{{< /prodname >}}. #### MTTD KPIs for Cloud SIEM diff --git a/hugo/content/en/security/cloud_siem/detect_and_monitor/_index.md b/hugo/content/en/security/cloud_siem/detect_and_monitor/_index.md index 57537553da4..5440bf18a8d 100644 --- a/hugo/content/en/security/cloud_siem/detect_and_monitor/_index.md +++ b/hugo/content/en/security/cloud_siem/detect_and_monitor/_index.md @@ -33,7 +33,7 @@ Monitor your Datadog telemetry and use [out-of-the-box detection rules](#out-of- ### Out-of-the-box detection rules -Cloud SIEM provides you with an extensive list of [OOTB detection rules][1]. After you have enabled and configured Cloud SIEM content packs, OOTB detection rules automatically begin analyzing your logs, Audit Trail events, and events from Event Management. +{{< prodname >}}Cloud SIEM{{< /prodname >}} provides you with an extensive list of [OOTB detection rules][1]. After you have enabled and configured {{< prodname >}}Cloud SIEM{{< /prodname >}} content packs, OOTB detection rules automatically begin analyzing your logs, Audit Trail events, and events from {{< prodname >}}Event Management{{< /prodname >}}. You can edit OOTB detection rules and do the following: @@ -76,7 +76,7 @@ See [Critical Assets][6] for more information. ## MITRE ATT&CK Map -After setting up your detection rules, use the Cloud SIEM [MITRE ATT&CK Map][5] to explore and visualize your rules against the MITRE ATT&CK framework so you have visibility into attacker techniques. +After setting up your detection rules, use the {{< prodname >}}Cloud SIEM{{< /prodname >}} [MITRE ATT&CK Map][5] to explore and visualize your rules against the MITRE ATT&CK framework so you have visibility into attacker techniques. ## Further reading diff --git a/hugo/content/en/security/cloud_siem/detect_and_monitor/custom_detection_rules/content_anomaly.md b/hugo/content/en/security/cloud_siem/detect_and_monitor/custom_detection_rules/content_anomaly.md index 84ca626cdb8..341859dd799 100644 --- a/hugo/content/en/security/cloud_siem/detect_and_monitor/custom_detection_rules/content_anomaly.md +++ b/hugo/content/en/security/cloud_siem/detect_and_monitor/custom_detection_rules/content_anomaly.md @@ -66,7 +66,7 @@ When you create a rule with the content anomaly detection method, you can set th ### Jaccard similarity computation examples -Cloud SIEM uses the [Jaccard similarity][3] to compare logs. +{{< prodname >}}Cloud SIEM{{< /prodname >}} uses the [Jaccard similarity][3] to compare logs. $$\text"J(A,B)" = {∣\text"A" ∩ \text"B"∣} / {∣\text"A" ∪ \text"B"∣}$$ diff --git a/hugo/content/en/security/cloud_siem/detect_and_monitor/custom_detection_rules/create_rule/historical_job.md b/hugo/content/en/security/cloud_siem/detect_and_monitor/custom_detection_rules/create_rule/historical_job.md index c229b0af291..2c8e8960c01 100644 --- a/hugo/content/en/security/cloud_siem/detect_and_monitor/custom_detection_rules/create_rule/historical_job.md +++ b/hugo/content/en/security/cloud_siem/detect_and_monitor/custom_detection_rules/create_rule/historical_job.md @@ -48,7 +48,7 @@ In Datadog, SQL queries are compatible with data stored in [datasets][2]. You ca - Security signals - Spans - RUM events -- Product Analytics events +- {{< prodname >}}Product Analytics{{< /prodname >}} events - Cloud Network data - NetFlow data - Reference tables diff --git a/hugo/content/en/security/cloud_siem/detect_and_monitor/custom_detection_rules/create_rule/scheduled_rule.md b/hugo/content/en/security/cloud_siem/detect_and_monitor/custom_detection_rules/create_rule/scheduled_rule.md index e8d2bbab8f8..a4c591310d4 100644 --- a/hugo/content/en/security/cloud_siem/detect_and_monitor/custom_detection_rules/create_rule/scheduled_rule.md +++ b/hugo/content/en/security/cloud_siem/detect_and_monitor/custom_detection_rules/create_rule/scheduled_rule.md @@ -48,7 +48,7 @@ In Datadog, SQL queries are compatible with data stored in [datasets][2]. You ca - Security signals - Spans - RUM events -- Product Analytics events +- {{< prodname >}}Product Analytics{{< /prodname >}} events - Cloud Network data - NetFlow data - Reference tables diff --git a/hugo/content/en/security/cloud_siem/detect_and_monitor/mitre_attack_map.md b/hugo/content/en/security/cloud_siem/detect_and_monitor/mitre_attack_map.md index 329fed63300..5c32b422cc8 100644 --- a/hugo/content/en/security/cloud_siem/detect_and_monitor/mitre_attack_map.md +++ b/hugo/content/en/security/cloud_siem/detect_and_monitor/mitre_attack_map.md @@ -26,9 +26,9 @@ To view detection rules against the MITRE ATT&CK Framework: 1. Click the {{< ui >}}MITRE ATT&CK Map{{< /ui >}} button located next to {{< ui >}}Rules List{{< /ui >}}. 1. Toggle the resize button on the bottom left side of the page to switch between an expanded view and a condensed view. -The default view of the map shows all Datadog out-of-the-box and custom rules for active sources, broken down into different attack techniques. Active sources are the sources of logs found and analyzed in the Cloud SIEM index. +The default view of the map shows all Datadog out-of-the-box and custom rules for active sources, broken down into different attack techniques. Active sources are the sources of logs found and analyzed in the {{< prodname >}}Cloud SIEM{{< /prodname >}} index. -**Note**: For the legacy SKU, all ingested logs are analyzed by Cloud SIEM unless [security filters][2] have been set up. +**Note**: For the legacy SKU, all ingested logs are analyzed by {{< prodname >}}Cloud SIEM{{< /prodname >}} unless [security filters][2] have been set up. To view the map for all sources, in the {{< ui >}}Visualize{{< /ui >}} dropdown menu, select {{< ui >}}All Sources{{< /ui >}}. This shows all out-of-the-box rules, including those that are not currently used to detect threats from your logs. diff --git a/hugo/content/en/security/cloud_siem/guide/_index.md b/hugo/content/en/security/cloud_siem/guide/_index.md index e35d6655b95..5875be1d1fc 100644 --- a/hugo/content/en/security/cloud_siem/guide/_index.md +++ b/hugo/content/en/security/cloud_siem/guide/_index.md @@ -9,14 +9,14 @@ disable_toc: true --- {{< whatsnext desc="General Guides:" >}} - {{< nextlink href="/getting_started/cloud_siem" >}}Getting Started with Cloud SIEM{{< /nextlink >}} - {{< nextlink href="/security/cloud_siem/guide/determine-cloud-siem-product" >}}Determine the Cloud SIEM product your organization is using{{< /nextlink >}} - {{< nextlink href="/security/cloud_siem/guide/automate-the-remediation-of-detected-threats" >}}Automate the remediation of detected threats with Cloud SIEM{{< /nextlink >}} - {{< nextlink href="/security/cloud_siem/guide/aws-config-guide-for-cloud-siem" >}}AWS Configuration Guide for Cloud SIEM{{< /nextlink >}} - {{< nextlink href="/security/cloud_siem/guide/google-cloud-config-guide-for-cloud-siem/" >}}Google Cloud Configuration Guide for Cloud SIEM{{< /nextlink >}} - {{< nextlink href="/security/cloud_siem/guide/azure-config-guide-for-cloud-siem/" >}}Azure Configuration Guide for Cloud SIEM{{< /nextlink >}} - {{< nextlink href="/security/cloud_siem/guide/oci-config-guide-for-cloud-siem/" >}}OCI Configuration Guide for Cloud SIEM{{< /nextlink >}} + {{< nextlink href="/getting_started/cloud_siem" >}}Getting Started with {{< prodname >}}Cloud SIEM{{< /prodname >}}{{< /nextlink >}} + {{< nextlink href="/security/cloud_siem/guide/determine-cloud-siem-product" >}}Determine the {{< prodname >}}Cloud SIEM{{< /prodname >}} product your organization is using{{< /nextlink >}} + {{< nextlink href="/security/cloud_siem/guide/automate-the-remediation-of-detected-threats" >}}Automate the remediation of detected threats with {{< prodname >}}Cloud SIEM{{< /prodname >}}{{< /nextlink >}} + {{< nextlink href="/security/cloud_siem/guide/aws-config-guide-for-cloud-siem" >}}AWS Configuration Guide for {{< prodname >}}Cloud SIEM{{< /prodname >}}{{< /nextlink >}} + {{< nextlink href="/security/cloud_siem/guide/google-cloud-config-guide-for-cloud-siem/" >}}Google Cloud Configuration Guide for {{< prodname >}}Cloud SIEM{{< /prodname >}}{{< /nextlink >}} + {{< nextlink href="/security/cloud_siem/guide/azure-config-guide-for-cloud-siem/" >}}Azure Configuration Guide for {{< prodname >}}Cloud SIEM{{< /prodname >}}{{< /nextlink >}} + {{< nextlink href="/security/cloud_siem/guide/oci-config-guide-for-cloud-siem/" >}}OCI Configuration Guide for {{< prodname >}}Cloud SIEM{{< /prodname >}}{{< /nextlink >}} {{< nextlink href="security/cloud_siem/guide/monitor-authentication-logs-for-security-threats" >}}Monitor Authentication Logs for Security Threats{{< /nextlink >}} - {{< nextlink href="/security/cloud_siem/guide/customize-which-logs-cloud-siem-analyzes" >}}Customize which logs Cloud SIEM analyzes{{< /nextlink >}} - {{< nextlink href="/security/cloud_siem/guide/troubleshoot-cribl-stream-cloud-siem" >}}Troubleshoot using Cribl Stream with Cloud SIEM{{< /nextlink >}} + {{< nextlink href="/security/cloud_siem/guide/customize-which-logs-cloud-siem-analyzes" >}}Customize which logs {{< prodname >}}Cloud SIEM{{< /prodname >}} analyzes{{< /nextlink >}} + {{< nextlink href="/security/cloud_siem/guide/troubleshoot-cribl-stream-cloud-siem" >}}Troubleshoot using Cribl Stream with {{< prodname >}}Cloud SIEM{{< /prodname >}}{{< /nextlink >}} {{< /whatsnext >}} \ No newline at end of file diff --git a/hugo/content/en/security/cloud_siem/guide/automate-the-remediation-of-detected-threats.md b/hugo/content/en/security/cloud_siem/guide/automate-the-remediation-of-detected-threats.md index 6c16419b627..216d82027ee 100644 --- a/hugo/content/en/security/cloud_siem/guide/automate-the-remediation-of-detected-threats.md +++ b/hugo/content/en/security/cloud_siem/guide/automate-the-remediation-of-detected-threats.md @@ -14,7 +14,7 @@ aliases: ## Overview -[Cloud SIEM][1] allows you to set Detection Rules that trigger auto-remediation workflows. With Datadog's [webhook integration][2], set up webhooks to deliver payloads to the services you want to automate whenever a [Detection Rule][3] is triggered. Every webhook payload contains information about the triggering event and a custom message that can be used to initiate services downstream. Automate commands for any service that has a webhook URL. Security orchestration and automation response tools accept incoming HTTP requests and these webhooks initiate any workflow you have defined. +[{{< prodname >}}Cloud SIEM{{< /prodname >}}][1] allows you to set Detection Rules that trigger auto-remediation workflows. With Datadog's [webhook integration][2], set up webhooks to deliver payloads to the services you want to automate whenever a [Detection Rule][3] is triggered. Every webhook payload contains information about the triggering event and a custom message that can be used to initiate services downstream. Automate commands for any service that has a webhook URL. Security orchestration and automation response tools accept incoming HTTP requests and these webhooks initiate any workflow you have defined. Choose a security scenario below to begin automating remediation. diff --git a/hugo/content/en/security/cloud_siem/guide/aws-config-guide-for-cloud-siem.md b/hugo/content/en/security/cloud_siem/guide/aws-config-guide-for-cloud-siem.md index 59f535c1d09..a5b5a1b2e49 100644 --- a/hugo/content/en/security/cloud_siem/guide/aws-config-guide-for-cloud-siem.md +++ b/hugo/content/en/security/cloud_siem/guide/aws-config-guide-for-cloud-siem.md @@ -29,7 +29,7 @@ aliases: ## Overview -Cloud SIEM applies detection rules to all processed logs in Datadog to detect threats, like a targeted attack, a threat intel listed IP communicating with your systems, or an insecure configuration. The threats are surfaced as Security Signals in the [Security Signals Explorer][1] for triaging. +{{< prodname >}}Cloud SIEM{{< /prodname >}} applies detection rules to all processed logs in Datadog to detect threats, like a targeted attack, a threat intel listed IP communicating with your systems, or an insecure configuration. The threats are surfaced as Security Signals in the [Security Signals Explorer][1] for triaging. This guide walks you through the following steps so that you can start detecting threats with your AWS CloudTrail logs: @@ -52,7 +52,7 @@ This guide walks you through the following steps so that you can start detecting ## Use Cloud SIEM to triage Security Signals -Cloud SIEM applies out of the box detection rules to all processed logs, including the CloudTrail logs you have just set up. When a threat is detected with a Detection Rule, a Security Signal is generated and can be viewed in the Security Signals Explorer. +{{< prodname >}}Cloud SIEM{{< /prodname >}} applies out of the box detection rules to all processed logs, including the CloudTrail logs you have just set up. When a threat is detected with a Detection Rule, a Security Signal is generated and can be viewed in the Security Signals Explorer. - Go to the [Cloud SIEM Signals Explorer][9] to view and triage threats. See [Security Signals Explorer][10] for further details. - You can also use the [AWS CloudTrail dashboard][11] to investigate anomalous activity. diff --git a/hugo/content/en/security/cloud_siem/guide/azure-config-guide-for-cloud-siem.md b/hugo/content/en/security/cloud_siem/guide/azure-config-guide-for-cloud-siem.md index 26f112e47d9..a7ce8219b15 100644 --- a/hugo/content/en/security/cloud_siem/guide/azure-config-guide-for-cloud-siem.md +++ b/hugo/content/en/security/cloud_siem/guide/azure-config-guide-for-cloud-siem.md @@ -14,7 +14,7 @@ further_reading: ## Overview -Cloud SIEM applies detection rules to all processed logs in Datadog to detect threats, like a targeted attack, a threat intel listed IP communicating with your systems, or an insecure resource modification. The threats are surfaced as Security Signals in the Security Signals Explorer for triaging. +{{< prodname >}}Cloud SIEM{{< /prodname >}} applies detection rules to all processed logs in Datadog to detect threats, like a targeted attack, a threat intel listed IP communicating with your systems, or an insecure resource modification. The threats are surfaced as Security Signals in the Security Signals Explorer for triaging. This guide walks you through configuring Microsoft Azure to send logs to Datadog so that you can start detecting threats on your Azure Platform logs. @@ -178,7 +178,7 @@ Go to [Log Explorer][7] and enter `service:azure` in the search query to view yo ## Use Cloud SIEM to triage Security Signals -Cloud SIEM applies out-of-the-box detection rules to all processed logs, including the Azure Platform logs you have just set up. When a threat is detected with a detection rule, a Security Signal is generated and can be viewed in the Security Signals Explorer. +{{< prodname >}}Cloud SIEM{{< /prodname >}} applies out-of-the-box detection rules to all processed logs, including the Azure Platform logs you have just set up. When a threat is detected with a detection rule, a Security Signal is generated and can be viewed in the Security Signals Explorer. - Go to the Cloud SIEM Signals Explorer to view and triage threats. See Security Signals Explorer for further details. - See out-of-the-box detection rules that are applied to your logs. diff --git a/hugo/content/en/security/cloud_siem/guide/customize-which-logs-cloud-siem-analyzes.md b/hugo/content/en/security/cloud_siem/guide/customize-which-logs-cloud-siem-analyzes.md index c1c9f8fa8e6..788dec6f642 100644 --- a/hugo/content/en/security/cloud_siem/guide/customize-which-logs-cloud-siem-analyzes.md +++ b/hugo/content/en/security/cloud_siem/guide/customize-which-logs-cloud-siem-analyzes.md @@ -24,11 +24,11 @@ further_reading: ## Overview -Cloud SIEM analyzes ingested logs to detect threats using [detection rules][1]. Most organizations rely on [Content Packs][7] to manage which logs Cloud SIEM analyzes; each Content Pack includes prebuilt filters for the log source it covers. If you need more granular control (for example, to exclude an environment or to restrict analysis to a custom log set), configure log filtering directly. +{{< prodname >}}Cloud SIEM{{< /prodname >}} analyzes ingested logs to detect threats using [detection rules][1]. Most organizations rely on [Content Packs][7] to manage which logs {{< prodname >}}Cloud SIEM{{< /prodname >}} analyzes; each Content Pack includes prebuilt filters for the log source it covers. If you need more granular control (for example, to exclude an environment or to restrict analysis to a custom log set), configure log filtering directly. ## Filtering tools and configuration methods -The filtering tools and configuration methods available depend on your Cloud SIEM product: +The filtering tools and configuration methods available depend on your {{< prodname >}}Cloud SIEM{{< /prodname >}} product: | Cloud SIEM product | Filtering tool | Configuration methods | |-----------------------|------------------------------------------|-----------------------------------------------------------------------------------------------------------------------| @@ -36,15 +36,15 @@ The filtering tools and configuration methods available depend on your Cloud SIE | Add-on with Flex Logs | Security Filters | [UI](#configure-security-filters-in-the-ui-add-on-with-flex-logs) and [API](#configure-security-filters-with-the-api) | | Legacy | Security Filters | [API](#configure-security-filters-with-the-api) | -If you're not sure which Cloud SIEM product your organization uses, see [Determine the Cloud SIEM product your organization is using][2]. +If you're not sure which {{< prodname >}}Cloud SIEM{{< /prodname >}} product your organization uses, see [Determine the Cloud SIEM product your organization is using][2]. -
Security Filters and log index filters control only the logs analyzed by Cloud SIEM. Logs generated by the Datadog Agent for Workload Protection (source:runtime-security-agent) and Cloud Security Misconfigurations (source:compliance-agent) are not billed as analyzed logs regardless of filter configuration.
+
Security Filters and log index filters control only the logs analyzed by {{< prodname >}}Cloud SIEM{{< /prodname >}}. Logs generated by the Datadog Agent for {{< prodname >}}Workload Protection{{< /prodname >}} (source:runtime-security-agent) and Cloud Security Misconfigurations (source:compliance-agent) are not billed as analyzed logs regardless of filter configuration.
### Cloud SIEM Standalone: Filter the Cloud SIEM index -Cloud SIEM Standalone does not use Security Filters. Standalone organizations control which logs Cloud SIEM analyzes by configuring an index filter on the Cloud SIEM log index. +Cloud SIEM Standalone does not use Security Filters. Standalone organizations control which logs {{< prodname >}}Cloud SIEM{{< /prodname >}} analyzes by configuring an index filter on the {{< prodname >}}Cloud SIEM{{< /prodname >}} log index. -An index filter is a query that specifies which logs enter the index. Logs that do not match the filter are not indexed, and therefore are not analyzed by Cloud SIEM. The query syntax is the same as the standard Datadog log search syntax. +An index filter is a query that specifies which logs enter the index. Logs that do not match the filter are not indexed, and therefore are not analyzed by {{< prodname >}}Cloud SIEM{{< /prodname >}}. The query syntax is the same as the standard Datadog log search syntax. For full configuration instructions, see [Indexes filters][3] in the Log Configuration documentation. @@ -52,21 +52,21 @@ For full configuration instructions, see [Indexes filters][3] in the Log Configu ## How Security Filters work -Security Filters specify which ingested logs Cloud SIEM analyzes. Cloud SIEM evaluates every ingested log against all enabled Security Filters. +Security Filters specify which ingested logs {{< prodname >}}Cloud SIEM{{< /prodname >}} analyzes. {{< prodname >}}Cloud SIEM{{< /prodname >}} evaluates every ingested log against all enabled Security Filters. Security Filters are **inclusive**: Datadog analyzes a log if the log matches at least one enabled Security Filter and is not removed by an exclusion on that filter. A Security Filter has three parts: - A **query** that selects the logs the filter matches. - Zero or more **exclusion filters**, each with its own query. A log matched by the main query is removed from analysis if it also matches any exclusion query. -- A **status** (active or inactive). Inactive filters are ignored by Cloud SIEM but remain saved for later use. +- A **status** (active or inactive). Inactive filters are ignored by {{< prodname >}}Cloud SIEM{{< /prodname >}} but remain saved for later use. -Cloud SIEM tags every ingested log with `datadog.cloud_siem:true` or `datadog.cloud_siem:false`, based on whether Security Filters selected the log for analysis. You can use this tag in Logs Explorer to verify the effect of your Security Filters on any specific log. +{{< prodname >}}Cloud SIEM{{< /prodname >}} tags every ingested log with `datadog.cloud_siem:true` or `datadog.cloud_siem:false`, based on whether Security Filters selected the log for analysis. You can use this tag in Logs Explorer to verify the effect of your Security Filters on any specific log. ### Limitations on Security Filter queries -Datadog evaluates Security Filters before Cloud SIEM applies geoIP, threat intel, and OCSF observable enrichment. The fields that enrichment populates are not present on the log when Security Filters evaluate it, so Security Filter queries cannot reliably reference them. The constraint applies in two distinct ways: +Datadog evaluates Security Filters before {{< prodname >}}Cloud SIEM{{< /prodname >}} applies geoIP, threat intel, and OCSF observable enrichment. The fields that enrichment populates are not present on the log when Security Filters evaluate it, so Security Filter queries cannot reliably reference them. The constraint applies in two distinct ways: -- **Fields not present at filter-evaluation time.** These fields are populated only by Cloud SIEM's out-of-the-box enrichment, which runs after Security Filters. A Security Filter query that references one of these fields matches no logs. +- **Fields not present at filter-evaluation time.** These fields are populated only by {{< prodname >}}Cloud SIEM{{< /prodname >}}'s out-of-the-box enrichment, which runs after Security Filters. A Security Filter query that references one of these fields matches no logs. - `network.ip.list` - `network.ip.attributes` - `network.client.is_private_network_ip` @@ -76,14 +76,14 @@ Datadog evaluates Security Filters before Cloud SIEM applies geoIP, threat intel To filter on these categories of data, rewrite the query using attributes present at ingestion time, such as `source`, `service`, `host`, tags, and parsed log attributes. -- **Fields whose availability depends on Pipeline configuration.** These fields can be populated either by a Logs Pipeline processor (before Security Filters), or by Cloud SIEM's out-of-the-box enrichment (after Security Filters). Whether a Security Filter query against one of these fields works depends on whether the corresponding Pipeline processor is configured. +- **Fields whose availability depends on Pipeline configuration.** These fields can be populated either by a Logs Pipeline processor (before Security Filters), or by {{< prodname >}}Cloud SIEM{{< /prodname >}}'s out-of-the-box enrichment (after Security Filters). Whether a Security Filter query against one of these fields works depends on whether the corresponding Pipeline processor is configured. - `network.client.geoip` (and sub-attributes such as `network.client.geoip.country.iso_code`) - `threat_intel.results` - `threat_intel.indicators_matched` To make these fields available to Security Filter queries, configure the corresponding GeoIP or Threat Intel Enrichment processor in your [Logs Pipeline][8]. With the processor in place, the fields get populated before Security Filters run. -Cloud SIEM's geoIP enrichment uses the same GeoIPFilter and IPinfo database as a Pipeline GeoIP processor, so the geoIP data is identical regardless of which path populates it. The threat intel workaround is different: a Pipeline Threat Intel Enrichment processor draws on your own threat intel sources (see [Bring your own threat intelligence][9] for setup guidance), which produces a different set of matches than Cloud SIEM's out-of-the-box, Datadog-managed threat intel. If you rely on Cloud SIEM's out-of-the-box threat intel, the matching cannot be moved upstream of Security Filters. +{{< prodname >}}Cloud SIEM{{< /prodname >}}'s geoIP enrichment uses the same GeoIPFilter and IPinfo database as a Pipeline GeoIP processor, so the geoIP data is identical regardless of which path populates it. The threat intel workaround is different: a Pipeline Threat Intel Enrichment processor draws on your own threat intel sources (see [Bring your own threat intelligence][9] for setup guidance), which produces a different set of matches than {{< prodname >}}Cloud SIEM{{< /prodname >}}'s out-of-the-box, Datadog-managed threat intel. If you rely on {{< prodname >}}Cloud SIEM{{< /prodname >}}'s out-of-the-box threat intel, the matching cannot be moved upstream of Security Filters. The pre-enrichment evaluation applies to Security Filters only. Detection rules, suppression rules, and signal queries run against the post-enrichment log and can continue to reference these fields. @@ -91,20 +91,20 @@ The pre-enrichment evaluation applies to Security Filters only. Detection rules, **Applies to:** Cloud SIEM Add-on with Flex Logs. Cloud SIEM Legacy organizations must configure Security Filters through the [API](#configure-security-filters-with-the-api). -
For most use cases, the easiest way to manage which logs Cloud SIEM analyzes is by enabling or disabling Content Packs. Each Content Pack manages its own Security Filter, so toggling a Content Pack adds or removes the corresponding filter automatically. The Security Filters UI described below is provided for fine tuning and custom log control beyond what Content Packs cover.
+
For most use cases, the easiest way to manage which logs {{< prodname >}}Cloud SIEM{{< /prodname >}} analyzes is by enabling or disabling Content Packs. Each Content Pack manages its own Security Filter, so toggling a Content Pack adds or removes the corresponding filter automatically. The Security Filters UI described below is provided for fine tuning and custom log control beyond what Content Packs cover.
-The {{< ui >}}Security Filters Configuration{{< /ui >}} section lists every Security Filter, its query, its exclusions, and whether it is currently active. A {{< ui >}}Preview{{< /ui >}} pane at the bottom of the section streams the logs that reach Cloud SIEM analysis after every enabled filter is applied. Use the {{< ui >}}Preview{{< /ui >}} pane to validate that your filter configuration produces the expected result. +The {{< ui >}}Security Filters Configuration{{< /ui >}} section lists every Security Filter, its query, its exclusions, and whether it is currently active. A {{< ui >}}Preview{{< /ui >}} pane at the bottom of the section streams the logs that reach {{< prodname >}}Cloud SIEM{{< /prodname >}} analysis after every enabled filter is applied. Use the {{< ui >}}Preview{{< /ui >}} pane to validate that your filter configuration produces the expected result. {{< img src="security/cloud_siem/guide/siem_settings_page_security_filters.png" alt="The Security Filters Configuration section of the Cloud SIEM settings page, showing a list of configured filters with columns for Name, Filters, and Active, followed by a Preview pane streaming matching logs" style="width:100%;" >}} ### Create a Security Filter -1. In Datadog, go to {{< ui >}}Security{{< /ui >}} > {{< ui >}}Cloud SIEM{{< /ui >}} > [**Settings**][4]. +1. In Datadog, go to {{< ui >}}Security{{< /ui >}} > {{< ui >}}{{< prodname >}}Cloud SIEM{{< /prodname >}}{{< /ui >}} > [**Settings**][4]. 1. Scroll to the **Security Filters Configuration** section and click it to expand it. 1. In the **Security Filters Configuration** section, click {{< ui >}}+ New Security Filter{{< /ui >}}. The {{< ui >}}New Security Filter{{< /ui >}} window opens. 1. In the **New Security Filter** window, enter: - **Name:** A short, descriptive name (for example, `AWS CloudTrail`). - - **Query:** The log query that selects the logs Cloud SIEM should analyze (for example, `source:cloudtrail`). + - **Query:** The log query that selects the logs {{< prodname >}}Cloud SIEM{{< /prodname >}} should analyze (for example, `source:cloudtrail`). - **Exclusion filters** (optional): One or more exclusion queries that subtract logs from the filter's match. To add one, click {{< ui >}}+ New Exclusion Filter{{< /ui >}} and enter an exclusion query. - **Filter status:** Set to {{< ui >}}Active{{< /ui >}} to enable the filter on save. 1. Review the **Preview** pane to confirm the filter matches the logs you expect. @@ -130,8 +130,8 @@ The built-in `all ingested logs` filter cannot be deleted, but you can disable i **Applies to:** Cloud SIEM Add-on with Flex Logs and Cloud SIEM Legacy. -When working with the API, you must understand which Cloud SIEM version you are using. The versions affect the logic of the security filters, and Cloud SIEM only analyzes logs based on the logic of the filters present. -- For **Add-on with Flex Logs**, there are no security filters present when you first onboard. Each content pack you enable adds a security filter so Cloud SIEM can analyze those logs. +When working with the API, you must understand which {{< prodname >}}Cloud SIEM{{< /prodname >}} version you are using. The versions affect the logic of the security filters, and {{< prodname >}}Cloud SIEM{{< /prodname >}} only analyzes logs based on the logic of the filters present. +- For **Add-on with Flex Logs**, there are no security filters present when you first onboard. Each content pack you enable adds a security filter so {{< prodname >}}Cloud SIEM{{< /prodname >}} can analyze those logs. - **Legacy** operates differently. It comes with a default filter that allows all logs to be analyzed. Datadog recommends adding exclusion filters to the default filter to reduce your log volumes. ### Prerequisites for the Cloud SIEM API @@ -143,7 +143,7 @@ When working with the API, you must understand which Cloud SIEM version you are ### Create a custom Security Filter -Custom Security Filters tell Cloud SIEM which logs it should analyze. This example call creates a filter that matches `source:cloudtrail`, so Cloud SIEM analyzes logs from AWS CloudTrail. +Custom Security Filters tell {{< prodname >}}Cloud SIEM{{< /prodname >}} which logs it should analyze. This example call creates a filter that matches `source:cloudtrail`, so {{< prodname >}}Cloud SIEM{{< /prodname >}} analyzes logs from AWS CloudTrail. ```bash curl -L -X POST 'https://api.{{< region-param key="dd_site" code="true" >}}/api/v2/security_monitoring/configuration/security_filters' \ @@ -325,7 +325,7 @@ A successful request returns `HTTP 204 No Content`. ## Troubleshoot Security Filters -If a log you expect Cloud SIEM to analyze is not producing signals, work through these checks in order: +If a log you expect {{< prodname >}}Cloud SIEM{{< /prodname >}} to analyze is not producing signals, work through these checks in order: 1. **Verify that Security Filters selected the log for analysis.** Open the log in Logs Explorer and check the value of `datadog.cloud_siem`. - If the tag is `false`, the log was excluded by Security Filters. Review your filter set and confirm that at least one enabled filter matches the log, and that no exclusion removes it. diff --git a/hugo/content/en/security/cloud_siem/guide/determine-cloud-siem-product.md b/hugo/content/en/security/cloud_siem/guide/determine-cloud-siem-product.md index 46679f0f1a4..4aebbdc41bb 100644 --- a/hugo/content/en/security/cloud_siem/guide/determine-cloud-siem-product.md +++ b/hugo/content/en/security/cloud_siem/guide/determine-cloud-siem-product.md @@ -4,12 +4,12 @@ description: Cloud SIEM is available in Standalone, Add-on with Flex Logs, and L --- ## Overview -Cloud SIEM is available as the following products: +{{< prodname >}}Cloud SIEM{{< /prodname >}} is available as the following products: - Standalone - Add-on with Flex Logs - Legacy -There are two ways to see which Cloud SIEM product your organization is using: +There are two ways to see which {{< prodname >}}Cloud SIEM{{< /prodname >}} product your organization is using: - [Check the Plan & Usage page](#plan-usage) - [Check the Cloud SIEM settings page](#settings) @@ -18,14 +18,14 @@ There are two ways to see which Cloud SIEM product your organization is using:
You may not be able to use this option if:
  • You don't have access to this page
    • -
  • Your organization has multi-org configured; the Plan & Usage page is a roll-up of all sub-orgs, so you might see multiple Cloud SIEM product tiles
    • +
  • Your organization has multi-org configured; the Plan & Usage page is a roll-up of all sub-orgs, so you might see multiple {{< prodname >}}Cloud SIEM{{< /prodname >}} product tiles
- In either case, follow the instructions in the Check the Cloud SIEM settings page section to determine which product your organization is using. + In either case, follow the instructions in the Check the {{< prodname >}}Cloud SIEM{{< /prodname >}} settings page section to determine which product your organization is using.
1. In Datadog, go to {{< ui >}}Plan & Usage{{< /ui >}} > [**Usage & Cost**][1] page. 1. Scroll to the **Usage Summary** section and click the {{< ui >}}Security{{< /ui >}} tab. -1. Find the tile that indicates which Cloud SIEM product your organization is using: +1. Find the tile that indicates which {{< prodname >}}Cloud SIEM{{< /prodname >}} product your organization is using:
@@ -57,7 +57,7 @@ There are two ways to see which Cloud SIEM product your organization is using: ## Check the Cloud SIEM settings page{#settings} -In Datadog, go to the [Cloud SIEM settings][2] page. The page shows either a {{< ui >}}Core Configuration{{< /ui >}} or {{< ui >}}Settings{{< /ui >}} section, which indicates the Cloud SIEM product your organization is using. +In Datadog, go to the [Cloud SIEM settings][2] page. The page shows either a {{< ui >}}Core Configuration{{< /ui >}} or {{< ui >}}Settings{{< /ui >}} section, which indicates the {{< prodname >}}Cloud SIEM{{< /prodname >}} product your organization is using.
diff --git a/hugo/content/en/security/cloud_siem/guide/google-cloud-config-guide-for-cloud-siem.md b/hugo/content/en/security/cloud_siem/guide/google-cloud-config-guide-for-cloud-siem.md index 38912315a8b..655eae8867a 100644 --- a/hugo/content/en/security/cloud_siem/guide/google-cloud-config-guide-for-cloud-siem.md +++ b/hugo/content/en/security/cloud_siem/guide/google-cloud-config-guide-for-cloud-siem.md @@ -169,7 +169,7 @@ See new logging events delivered to the Cloud Pub/Sub topic in the [Datadog Log ## Use Cloud SIEM to triage Security Signals -Cloud SIEM applies out-of-the-box detection rules to all processed logs, including the Google Cloud audit logs you have just set up. When a threat is detected with a detection rule, a Security Signal is generated and can be viewed in the Security Signals Explorer. +{{< prodname >}}Cloud SIEM{{< /prodname >}} applies out-of-the-box detection rules to all processed logs, including the Google Cloud audit logs you have just set up. When a threat is detected with a detection rule, a Security Signal is generated and can be viewed in the Security Signals Explorer. - Go to the [Cloud SIEM Signals Explorer][23] to view and triage threats. See Security Signals Explorer for further details. - You can also use the [Google Cloud Audit Log dashboard][24] to investigate anomalous activity. diff --git a/hugo/content/en/security/cloud_siem/guide/oci-config-guide-for-cloud-siem.md b/hugo/content/en/security/cloud_siem/guide/oci-config-guide-for-cloud-siem.md index 605cbaf7c9a..69b647f2b25 100644 --- a/hugo/content/en/security/cloud_siem/guide/oci-config-guide-for-cloud-siem.md +++ b/hugo/content/en/security/cloud_siem/guide/oci-config-guide-for-cloud-siem.md @@ -14,7 +14,7 @@ further_reading: ## Overview -Cloud SIEM applies detection rules to all processed logs in Datadog to detect threats such as targeted attacks, communication with threat intel-listed IPs, or insecure resource modifications. Detected threats are surfaced as Security Signals in the Security Signals Explorer for triage. +{{< prodname >}}Cloud SIEM{{< /prodname >}} applies detection rules to all processed logs in Datadog to detect threats such as targeted attacks, communication with threat intel-listed IPs, or insecure resource modifications. Detected threats are surfaced as Security Signals in the Security Signals Explorer for triage. This guide walks you through the following steps to start detecting threats with your OCI Audit logs: @@ -34,7 +34,7 @@ Ensure that log collection is enabled in the Datadog OCI integration tile: ## Use Cloud SIEM to triage Security Signals -Cloud SIEM applies out-of-the-box detection rules to all processed logs, including your OCI Audit logs. When a threat is detected with a detection rule, a Security Signal is generated and can be viewed in the Security Signals Explorer. +{{< prodname >}}Cloud SIEM{{< /prodname >}} applies out-of-the-box detection rules to all processed logs, including your OCI Audit logs. When a threat is detected with a detection rule, a Security Signal is generated and can be viewed in the Security Signals Explorer. - Go to the [Cloud SIEM Signals Explorer][1] to view and triage threats. See [Investigate Security Signals][2] for further details. - See [out-of-the-box detection rules][3] that are applied to your logs. diff --git a/hugo/content/en/security/cloud_siem/guide/setting-up-security-monitoring-for-aws.md b/hugo/content/en/security/cloud_siem/guide/setting-up-security-monitoring-for-aws.md index 576735f4b6d..4a0a8b53f82 100644 --- a/hugo/content/en/security/cloud_siem/guide/setting-up-security-monitoring-for-aws.md +++ b/hugo/content/en/security/cloud_siem/guide/setting-up-security-monitoring-for-aws.md @@ -12,7 +12,7 @@ With Datadog Cloud SIEM, detection rules are applied to all processed logs. AWS ## Setup 1. Navigate to the [Security Configuration Setup page][1] in the Datadog app. -2. Select {{< ui >}}Cloud SIEM{{< /ui >}}. +2. Select {{< ui >}}{{< prodname >}}Cloud SIEM{{< /prodname >}}{{< /ui >}}. 3. Under **Secure your cloud environment**, select {{< ui >}}AWS{{< /ui >}}. 4. Complete the **Detect threats with cloud logs** setup. 5. (Optional) Complete the **Secure your hosts and containers** setup. diff --git a/hugo/content/en/security/cloud_siem/guide/troubleshoot-cribl-stream-cloud-siem.md b/hugo/content/en/security/cloud_siem/guide/troubleshoot-cribl-stream-cloud-siem.md index 2d229a56c6f..b8a63fa6edb 100644 --- a/hugo/content/en/security/cloud_siem/guide/troubleshoot-cribl-stream-cloud-siem.md +++ b/hugo/content/en/security/cloud_siem/guide/troubleshoot-cribl-stream-cloud-siem.md @@ -20,7 +20,7 @@ further_reading: ## Overview -Cloud SIEM applies detection rules to all processed logs so it can detect threats and surface them as security signals. For out-of-the-box content (such as dashboards, log pipelines, and detection rules) to work correctly, Datadog must receive logs with the right `ddsource` value and with the log content in the `message` field. +{{< prodname >}}Cloud SIEM{{< /prodname >}} applies detection rules to all processed logs so it can detect threats and surface them as security signals. For out-of-the-box content (such as dashboards, log pipelines, and detection rules) to work correctly, Datadog must receive logs with the right `ddsource` value and with the log content in the `message` field. When you use the [Cribl Stream][3] integration to route logs to Datadog, the default destination configuration causes logs to arrive in an unexpected format. Using passthrough, Cribl serializes the entire event as a JSON string and places it inside the `message` field. This prevents Datadog from parsing the logs correctly, so OOTB dashboards do not populate and detection rules do not fire. diff --git a/hugo/content/en/security/cloud_siem/ingest_and_enrich/_index.md b/hugo/content/en/security/cloud_siem/ingest_and_enrich/_index.md index f45492aa021..eae192c0f4e 100644 --- a/hugo/content/en/security/cloud_siem/ingest_and_enrich/_index.md +++ b/hugo/content/en/security/cloud_siem/ingest_and_enrich/_index.md @@ -18,10 +18,10 @@ further_reading: ## Overview -Cloud SIEM detection rules analyze logs and security data to generate security signals when threats are detected. After you have enabled Cloud SIEM, configure Datadog to ingest and enrich logs from sources that you want to monitor. +{{< prodname >}}Cloud SIEM{{< /prodname >}} detection rules analyze logs and security data to generate security signals when threats are detected. After you have enabled {{< prodname >}}Cloud SIEM{{< /prodname >}}, configure Datadog to ingest and enrich logs from sources that you want to monitor. ## Ingest security data -The easiest way to send data to Datadog is by using [Content Packs][1], which are integrations specifically designed for Cloud SIEM. Each content pack contains instructions on how to configure the integration to ingest those logs and provides information on what is included, such as: +The easiest way to send data to Datadog is by using [Content Packs][1], which are integrations specifically designed for {{< prodname >}}Cloud SIEM{{< /prodname >}}. Each content pack contains instructions on how to configure the integration to ingest those logs and provides information on what is included, such as: - Detections rules - Out-of-the-box interactive dashboards @@ -30,17 +30,17 @@ The easiest way to send data to Datadog is by using [Content Packs][1], which ar [Content packs][1] are available for many popular security technologies. -If you have custom logs or have a data source not listed on Cloud SIEM's [Content Pack][2] page, check whether the integration is available in Datadog's extensive [integration library][3]. If it isn't available, you can send those logs as [custom logs][4] to Cloud SIEM for analysis. +If you have custom logs or have a data source not listed on {{< prodname >}}Cloud SIEM{{< /prodname >}}'s [Content Pack][2] page, check whether the integration is available in Datadog's extensive [integration library][3]. If it isn't available, you can send those logs as [custom logs][4] to {{< prodname >}}Cloud SIEM{{< /prodname >}} for analysis. ## Enrich logs ### Threat intelligence -Datadog provides built-in [Threat Intelligence][5] for Cloud SIEM logs and also supports enriching and searching using threat intelligence indicators of compromise (IoCs) stored in Datadog reference tables. See [Bring Your Own Threat Intelligence][6] for more information. +Datadog provides built-in [Threat Intelligence][5] for {{< prodname >}}Cloud SIEM{{< /prodname >}} logs and also supports enriching and searching using threat intelligence indicators of compromise (IoCs) stored in Datadog reference tables. See [Bring Your Own Threat Intelligence][6] for more information. ### Open Cybersecurity Framework (OCSF) -[Open Cybersecurity Framework (OCSF)][7] is integrated directly into Cloud SIEM, so incoming security logs are automatically enriched with OCSF-compliant attributes through out-of-the-box pipelines. +[Open Cybersecurity Framework (OCSF)][7] is integrated directly into {{< prodname >}}Cloud SIEM{{< /prodname >}}, so incoming security logs are automatically enriched with OCSF-compliant attributes through out-of-the-box pipelines. ## Further reading diff --git a/hugo/content/en/security/cloud_siem/ingest_and_enrich/content_packs.md b/hugo/content/en/security/cloud_siem/ingest_and_enrich/content_packs.md index 6c42b146ab6..72faf392dff 100644 --- a/hugo/content/en/security/cloud_siem/ingest_and_enrich/content_packs.md +++ b/hugo/content/en/security/cloud_siem/ingest_and_enrich/content_packs.md @@ -43,7 +43,7 @@ further_reading: - [Detection Rules][2] to provide comprehensive coverage of your environment - An interactive dashboard with detailed insights into the state of logs and security signals for the Content Pack - [Investigator][3], an interactive graphical interface for investigating suspicious activity by a user or resource -- [Workflow Automation][4], to automate actions and accelerate investigation and remediation of issues +- [{{< prodname >}}Workflow Automation{{< /prodname >}}][4], to automate actions and accelerate investigation and remediation of issues - Configuration guides {{% cloud-siem-content-packs %}} diff --git a/hugo/content/en/security/cloud_siem/ingest_and_enrich/open_cybersecurity_schema_framework/_index.md b/hugo/content/en/security/cloud_siem/ingest_and_enrich/open_cybersecurity_schema_framework/_index.md index 96a6e50dc91..268a17949b0 100644 --- a/hugo/content/en/security/cloud_siem/ingest_and_enrich/open_cybersecurity_schema_framework/_index.md +++ b/hugo/content/en/security/cloud_siem/ingest_and_enrich/open_cybersecurity_schema_framework/_index.md @@ -20,13 +20,13 @@ further_reading: ## Overview -Cloud SIEM collects and analyzes data from a wide range of sources such as cloud services, firewalls, networks, applications, and IT systems. Since these services emit data in different formats, it often requires significant effort to normalize and prepare logs before meaningful threat analysis can occur. +{{< prodname >}}Cloud SIEM{{< /prodname >}} collects and analyzes data from a wide range of sources such as cloud services, firewalls, networks, applications, and IT systems. Since these services emit data in different formats, it often requires significant effort to normalize and prepare logs before meaningful threat analysis can occur. The Open Cybersecurity Schema Framework (OCSF) is an open-source, vendor-neutral standard for organizing and classifying security event data. It is designed to simplify and unify how security logs are structured across platforms and products, enabling consistent threat detection and faster investigation. -At Datadog, OCSF support is integrated directly into Datadog Cloud SIEM so you get standardized, normalized log data without manual configuration. Incoming security logs are automatically enriched with OCSF-compliant attributes at ingestion time through out-of-the-box (OOTB) pipelines. All OCSF values are contained in the dedicated `OCSF` attribute, and are in addition to the other processes that transform and enrich logs. See [Supported out-of-the-box OCSF pipelines](#supported-out-of-the-box-ocsf-pipelines) to see a list of Log Management integrations that support OCSF. +At Datadog, OCSF support is integrated directly into Datadog Cloud SIEM so you get standardized, normalized log data without manual configuration. Incoming security logs are automatically enriched with OCSF-compliant attributes at ingestion time through out-of-the-box (OOTB) pipelines. All OCSF values are contained in the dedicated `OCSF` attribute, and are in addition to the other processes that transform and enrich logs. See [Supported out-of-the-box OCSF pipelines](#supported-out-of-the-box-ocsf-pipelines) to see a list of {{< prodname >}}Log Management{{< /prodname >}} integrations that support OCSF. -OCSF integration in Datadog's Cloud SIEM enables: +OCSF integration in Datadog's {{< prodname >}}Cloud SIEM{{< /prodname >}} enables: * **Simplified detection rules**: A unified attribute structure means detection logic can be written once and applied across multiple sources. * **Streamlined investigations**: Analysts no longer need to remember source-specific formats because one schema enables a single-query triage across providers. @@ -67,13 +67,13 @@ You can optionally add extensions, such as new attributes, objects, categories, ## Supported out-of-the-box OCSF pipelines -The following Log Management integrations support out-of-the-box OCSF pipelines: +The following {{< prodname >}}Log Management{{< /prodname >}} integrations support out-of-the-box OCSF pipelines: {{% cloud-siem-supported-ocsf %}} ## View Security Pipelines \- OCSF -Cloud SIEM OCSF remaps log data in Log Management's [integration pipelines][8]. See [Supported out-of-the-box OCSF pipelines](#supported-out-of-the-box-ocsf-pipelines) for details. +Cloud SIEM OCSF remaps log data in {{< prodname >}}Log Management{{< /prodname >}}'s [integration pipelines][8]. See [Supported out-of-the-box OCSF pipelines](#supported-out-of-the-box-ocsf-pipelines) for details. To view the Integration Pipeline Library for a source: diff --git a/hugo/content/en/security/cloud_siem/ingest_and_enrich/open_cybersecurity_schema_framework/ocsf_processor.md b/hugo/content/en/security/cloud_siem/ingest_and_enrich/open_cybersecurity_schema_framework/ocsf_processor.md index fc20f8aec61..b05323886e3 100644 --- a/hugo/content/en/security/cloud_siem/ingest_and_enrich/open_cybersecurity_schema_framework/ocsf_processor.md +++ b/hugo/content/en/security/cloud_siem/ingest_and_enrich/open_cybersecurity_schema_framework/ocsf_processor.md @@ -12,7 +12,7 @@ further_reading: ## Overview -Cloud SIEM provides out-of-the-box [Open Cybersecurity Framework (OCSF) support][1] (with editable settings) for certain integrations. You can also add custom mappings with the OCSF processor to normalize your security logs according to the OCSF framework. +{{< prodname >}}Cloud SIEM{{< /prodname >}} provides out-of-the-box [Open Cybersecurity Framework (OCSF) support][1] (with editable settings) for certain integrations. You can also add custom mappings with the OCSF processor to normalize your security logs according to the OCSF framework. This document explains how to set up the OCSF processor, which is configured in [Log Management pipelines][2]. diff --git a/hugo/content/en/security/cloud_siem/ingest_and_enrich/threat_intelligence.md b/hugo/content/en/security/cloud_siem/ingest_and_enrich/threat_intelligence.md index 34b24b848f5..79074d30208 100644 --- a/hugo/content/en/security/cloud_siem/ingest_and_enrich/threat_intelligence.md +++ b/hugo/content/en/security/cloud_siem/ingest_and_enrich/threat_intelligence.md @@ -18,13 +18,13 @@ further_reading: ## Overview -Datadog provides built-in [threat intelligence][1] for Cloud SIEM logs. This article explains how to extend that functionality by enriching logs with your own custom threat intelligence feeds. +Datadog provides built-in [threat intelligence][1] for {{< prodname >}}Cloud SIEM{{< /prodname >}} logs. This article explains how to extend that functionality by enriching logs with your own custom threat intelligence feeds. -Cloud SIEM supports enriching and searching logs using threat intelligence indicators of compromise (IOCs) stored in Datadog reference tables. [Reference Tables][7] allow you to combine metadata with information already in Datadog. +{{< prodname >}}Cloud SIEM{{< /prodname >}} supports enriching and searching logs using threat intelligence indicators of compromise (IOCs) stored in Datadog reference tables. [Reference Tables][7] allow you to combine metadata with information already in Datadog. ### How bring your own threat intelligence works -When Cloud SIEM processes a log, the log's IP, domain, hash, AWS account ID, container, SSH, and user agent attributes are evaluated against reference tables that you have enabled for Cloud SIEM. The process is as follows: +When Cloud SIEM processes a log, the log's IP, domain, hash, AWS account ID, container, SSH, and user agent attributes are evaluated against reference tables that you have enabled for {{< prodname >}}Cloud SIEM{{< /prodname >}}. The process is as follows: 1. For each log, Datadog extracts the relevant attributes: - **IPs**: IPv4 and IPv6 addresses found anywhere in the log. @@ -46,7 +46,7 @@ When Cloud SIEM processes a log, the log's IP, domain, hash, AWS account ID, con - If a match is found, Datadog enriches the log with the threat intelligence metadata from the table (for example, `category`, `source`, `first_seen`, `last_seen`, `confidence`). The enriched fields are then available for search, analytics, and detection rules. **Notes**: -- Cloud SIEM evaluates logs in real time and uses both [Datadog-curated threat intelligence][10] and your own reference tables. +- {{< prodname >}}Cloud SIEM{{< /prodname >}} evaluates logs in real time and uses both [Datadog-curated threat intelligence][10] and your own reference tables. - Reference tables are the mechanism for storing and joining your custom IoCs with logs and detections. ### Store indicators of compromise in reference tables @@ -263,7 +263,7 @@ See the related reference table documentation for: If a reference table is not refreshing, open the reference table's settings menu and select {{< ui >}}View Change Events{{< /ui >}}. -{{< ui >}}View Change Events{{< /ui >}} opens a page in {{< ui >}}Event Management{{< /ui >}} showing potential error events for the ingestion. You can also filter in {{< ui >}}Event Management{{< /ui >}} using the reference table name. +{{< ui >}}View Change Events{{< /ui >}} opens a page in {{< ui >}}{{< prodname >}}Event Management{{< /prodname >}}{{< /ui >}} showing potential error events for the ingestion. You can also filter in {{< ui >}}{{< prodname >}}Event Management{{< /prodname >}}{{< /ui >}} using the reference table name. In Datadog Event Management, it may appear that data has been fetched from the cloud, but it can take a few additional minutes for those changes to propagate to Threat Intelligence. Other useful cloud import details to remember: @@ -274,11 +274,11 @@ In case of a duplicated primary key, the rows with the duplicated key are not wr ## View threat intelligence data in Datadog -To enable Cloud SIEM threat intelligence data for reference tables: +To enable {{< prodname >}}Cloud SIEM{{< /prodname >}} threat intelligence data for reference tables: 1. Navigate to [Threat Intelligence][3]. -1. For the table you want to see Cloud SIEM threat intelligence data for, click the dropdown menu in the {{< ui >}}Enabled{{< /ui >}} column and select {{< ui >}}Cloud SIEM{{< /ui >}}. +1. For the table you want to see {{< prodname >}}Cloud SIEM{{< /prodname >}} threat intelligence data for, click the dropdown menu in the {{< ui >}}Enabled{{< /ui >}} column and select {{< ui >}}{{< prodname >}}Cloud SIEM{{< /prodname >}}{{< /ui >}}. -After applying a reference table to Cloud SIEM, all incoming logs are evaluated against the table using a specific Indicator of Compromise (IoC) key, such as an IP address or domain. If a match is found, the log is enriched with relevant Threat Intelligence (TI) attributes from the table, which enhances detection, investigation, and response. A threat intelligence reference table can be shared across multiple security products. +After applying a reference table to {{< prodname >}}Cloud SIEM{{< /prodname >}}, all incoming logs are evaluated against the table using a specific Indicator of Compromise (IoC) key, such as an IP address or domain. If a match is found, the log is enriched with relevant Threat Intelligence (TI) attributes from the table, which enhances detection, investigation, and response. A threat intelligence reference table can be shared across multiple security products. You can view your threat intelligence data in the [IOC Explorer][11]. diff --git a/hugo/content/en/security/cloud_siem/respond_and_report/_index.md b/hugo/content/en/security/cloud_siem/respond_and_report/_index.md index bd8ab6fdb20..7ff02d5059b 100644 --- a/hugo/content/en/security/cloud_siem/respond_and_report/_index.md +++ b/hugo/content/en/security/cloud_siem/respond_and_report/_index.md @@ -11,12 +11,12 @@ further_reading: --- {{< site-region region="gov,gov2" >}} -
Workflow Automation is not available in the selected site ({{< region-param key="dd_site_name" >}}).
+
{{< prodname >}}Workflow Automation{{< /prodname >}} is not available in the selected site ({{< region-param key="dd_site_name" >}}).
{{< /site-region >}} ## Overview -Datadog Security Orchestration, Automation, and Response (SOAR) helps you orchestrate security operations, investigate signals, and remediate threats using [Workflow Automation][1]. For example, you can [run a workflow][2] to: +Datadog Security Orchestration, Automation, and Response (SOAR) helps you orchestrate security operations, investigate signals, and remediate threats using [{{< prodname >}}Workflow Automation{{< /prodname >}}][1]. For example, you can [run a workflow][2] to: - Block an IP address from your environment. - Disable a user account. @@ -31,7 +31,7 @@ SOAR also includes ready-to-use customizable [blueprints][4] to help you build w - An Endpoint Detection and Response (EDR) workflow that speeds up the investigation and containment of endpoint threats. - A Threat Intelligence Enrichment workflow that enriches alerts with external data so you can prioritize and respond more effectively. -Cloud SIEM also provides [security operational metrics][3], so you can determine the efficiency and effectiveness of your security processes. +{{< prodname >}}Cloud SIEM{{< /prodname >}} also provides [security operational metrics][3], so you can determine the efficiency and effectiveness of your security processes. ## Further reading diff --git a/hugo/content/en/security/cloud_siem/respond_and_report/security_operational_metrics.md b/hugo/content/en/security/cloud_siem/respond_and_report/security_operational_metrics.md index 46673757b0a..d37e61c2aa2 100644 --- a/hugo/content/en/security/cloud_siem/respond_and_report/security_operational_metrics.md +++ b/hugo/content/en/security/cloud_siem/respond_and_report/security_operational_metrics.md @@ -20,7 +20,7 @@ further_reading: ## Overview -Cloud SIEM provides security operational metrics to help you determine the effectiveness of your team in responding to and resolving security threats to your cloud environments. These metrics are shown in the out-of-the-box [Cloud SIEM dashboard][1] and are sent in the Cloud SIEM [weekly digest reports][2]. You can also create dashboards and monitors for them. +{{< prodname >}}Cloud SIEM{{< /prodname >}} provides security operational metrics to help you determine the effectiveness of your team in responding to and resolving security threats to your cloud environments. These metrics are shown in the out-of-the-box [Cloud SIEM dashboard][1] and are sent in the {{< prodname >}}Cloud SIEM{{< /prodname >}} [weekly digest reports][2]. You can also create dashboards and monitors for them. {{< img src="security/security_monitoring/secops_metrics.png" alt="The security operational metrics section of the Cloud SIEM Overview dashboard" style="width:100%;" >}} diff --git a/hugo/content/en/security/cloud_siem/triage_and_investigate/_index.md b/hugo/content/en/security/cloud_siem/triage_and_investigate/_index.md index 84a452f432c..9349285944c 100644 --- a/hugo/content/en/security/cloud_siem/triage_and_investigate/_index.md +++ b/hugo/content/en/security/cloud_siem/triage_and_investigate/_index.md @@ -13,7 +13,7 @@ further_reading: ## Overview -Cloud SIEM offers integrated tools to streamline security investigations after a security signal is generated. These tools guide you through the following investigative workflow when a security signal is triggered: +{{< prodname >}}Cloud SIEM{{< /prodname >}} offers integrated tools to streamline security investigations after a security signal is generated. These tools guide you through the following investigative workflow when a security signal is triggered: - Threat assessment - Scope comprehension @@ -21,7 +21,7 @@ Cloud SIEM offers integrated tools to streamline security investigations after a Start with [Investigate Security Signals][1] to triage and investigate signals using the signals explorer. Filter by severity, entity, or timeframe to quickly assess what triggered detections and decide which signals require immediate attention. -For a more entity-centric approach, [Risk Insights][2] consolidates SIEM signals, Cloud Security findings, and identity risks into unified entity profiles representing users or assets paired with an opinionated risk score model. +For a more entity-centric approach, [Risk Insights][2] consolidates SIEM signals, {{< prodname >}}Cloud Security{{< /prodname >}} findings, and identity risks into unified entity profiles representing users or assets paired with an opinionated risk score model. To gain a broad understanding of how an actor moves throughout your ecosystem, the [Investigator][3] graphical interface maps connections between entities and activities over time. diff --git a/hugo/content/en/security/cloud_siem/triage_and_investigate/entities_and_risk_scoring.md b/hugo/content/en/security/cloud_siem/triage_and_investigate/entities_and_risk_scoring.md index 1283a97be20..cccaf52605e 100644 --- a/hugo/content/en/security/cloud_siem/triage_and_investigate/entities_and_risk_scoring.md +++ b/hugo/content/en/security/cloud_siem/triage_and_investigate/entities_and_risk_scoring.md @@ -16,7 +16,7 @@ further_reading: ## Overview -[Cloud SIEM's Risk Insights][4] consolidates multiple data sources, such as SIEM threats and Cloud Security insights, into a profile representing a single security entity, such as an IAM user. +[Cloud SIEM's Risk Insights][4] consolidates multiple data sources, such as SIEM threats and {{< prodname >}}Cloud Security{{< /prodname >}} insights, into a profile representing a single security entity, such as an IAM user. With Risk Insights, you can: @@ -28,11 +28,11 @@ With Risk Insights, you can: ## Prerequisites -- To use Risk Insights, configure at least one of the following supported log sources to send logs to Cloud SIEM, with an active Open Cybersecurity Schema Framework (OCSF) pipeline: +- To use Risk Insights, configure at least one of the following supported log sources to send logs to {{< prodname >}}Cloud SIEM{{< /prodname >}}, with an active Open Cybersecurity Schema Framework (OCSF) pipeline: - **Sources that provide identity and resource entities** (such as users, service identities, assumed roles, compute instances, and storage containers): AWS, Azure, GCP, GitHub, Microsoft 365, and Okta. - **Sources that provide user entities identified by email address**: 1Password, Cisco Duo, Cloudflare, CrowdStrike, Google Workspace, JumpCloud, LastPass, Salesforce, Slack, and Zscaler Internet Access (ZIA). - Many supported sources use an [out-of-the-box OCSF pipeline][8] that requires no additional configuration. If a supported source is not producing entities, confirm that its out-of-the-box OCSF pipeline is active. Pipelines that predate OCSF support, and customized pipelines, may not include the required OCSF processing. -- (Optional) To view associated Cloud Security insights in the entity panel, [Cloud Security must be configured][2]. +- (Optional) To view associated {{< prodname >}}Cloud Security{{< /prodname >}} insights in the entity panel, [Cloud Security must be configured][2]. ## Explore risk insights @@ -68,7 +68,7 @@ You can configure Datadog to send you notifications as soon as it detects new th 1. Navigate to the {{< ui >}}Create a new Risk Insight notification{{< /ui >}} page. There are two ways to do this: - In Datadog, go to the [Risk Insights Explorer][4], then click {{< ui >}}Create Notification Rule{{< /ui >}}. - - In Datadog, go to {{< ui >}}Cloud SIEM{{< /ui >}} > {{< ui >}}Settings{{< /ui >}}. Under {{< ui >}}Products{{< /ui >}}, in the {{< ui >}}Cloud SIEM{{< /ui >}} section, click [{{< ui >}}Risk Insights{{< /ui >}}][7]; then, under {{< ui >}}Notification rules{{< /ui >}}, click {{< ui >}}New notification rule{{< /ui >}}. + - In Datadog, go to {{< ui >}}{{< prodname >}}Cloud SIEM{{< /prodname >}}{{< /ui >}} > {{< ui >}}Settings{{< /ui >}}. Under {{< ui >}}Products{{< /ui >}}, in the {{< ui >}}{{< prodname >}}Cloud SIEM{{< /prodname >}}{{< /ui >}} section, click [{{< ui >}}Risk Insights{{< /ui >}}][7]; then, under {{< ui >}}Notification rules{{< /ui >}}, click {{< ui >}}New notification rule{{< /ui >}}. 1. Under {{< ui >}}Define entity attributes{{< /ui >}}, specify the attributes that should trigger notifications when Datadog detects them on an entity. Beside {{< ui >}}Entities matching{{< /ui >}}, start typing entity attributes and values. As you type, the preview table dynamically displays risk insights that match your criteria.
This step is optional, but if you don't enter any attributes, the notification defaults to sending alerts for all entities.
1. Under {{< ui >}}Set notification conditions{{< /ui >}}, specify the risk score threshold to trigger notifications for. diff --git a/hugo/content/en/security/cloud_siem/triage_and_investigate/investigate_security_signals.md b/hugo/content/en/security/cloud_siem/triage_and_investigate/investigate_security_signals.md index f6874db5259..19dda742ccf 100644 --- a/hugo/content/en/security/cloud_siem/triage_and_investigate/investigate_security_signals.md +++ b/hugo/content/en/security/cloud_siem/triage_and_investigate/investigate_security_signals.md @@ -22,9 +22,9 @@ further_reading: A Cloud SIEM security signal is created when Datadog detects a threat while analyzing logs against detection rules. View, search, filter, and correlate security signals in the Signals Explorer without needing to learn a dedicated query language. You can also assign security signals to yourself or another user in the Datadog platform. In addition to the Signals Explorer, you can configure [Notification Rules][1] to send signals to specific individuals or teams to keep them informed of issues. -You must have the `Security Signals Write` permission to modify a security signal, such as change the state and view signal action history in [Audit Trail][2]. See [Role Based Access Control][3] for more information about Datadog's default roles and granular role-based access control permissions available for Datadog Security in the Cloud Security. +You must have the `Security Signals Write` permission to modify a security signal, such as change the state and view signal action history in [Audit Trail][2]. See [Role Based Access Control][3] for more information about Datadog's default roles and granular role-based access control permissions available for Datadog Security in the {{< prodname >}}Cloud Security{{< /prodname >}}. -If you want to use an autonomous AI agent that investigates Cloud SIEM security signals, see [Bits Security Analyst][14]. +If you want to use an autonomous AI agent that investigates {{< prodname >}}Cloud SIEM{{< /prodname >}} security signals, see [{{< prodname >}}Bits Security Analyst{{< /prodname >}}][14]. ## Signals explorer @@ -64,7 +64,7 @@ To view your signals by MITRE ATT&CK Tactic and Technique: ### Triage a single signal -1. In Datadog, go to {{< ui >}}Security{{< /ui >}} > {{< ui >}}Cloud SIEM{{< /ui >}} > [{{< ui >}}Signals{{< /ui >}}][5]. +1. In Datadog, go to {{< ui >}}Security{{< /ui >}} > {{< ui >}}{{< prodname >}}Cloud SIEM{{< /prodname >}}{{< /ui >}} > [{{< ui >}}Signals{{< /ui >}}][5]. 1. Click on a security signal from the table. 1. In the {{< ui >}}What Happened{{< /ui >}} section, see the logs that matched the query. Hover over the query to see the query details. - You can also see specific information like username or network IP. In {{< ui >}}Rule Details{{< /ui >}}, click the funnel icon to create a suppression rule or add the information to an existing suppression. See [Create suppression rule][11] for more details. @@ -74,7 +74,7 @@ To view your signals by MITRE ATT&CK Tactic and Technique: - `Under Review`: During an active investigation, change the triage status to `Under Review`. From the `Under Review` state, you can move the status to `Archived` or `Open` as needed. - `Archived`: When the detection that caused the signal has been resolved, update the status to `Archived`. When a signal is archived, you can give a reason and description for future reference. If an archived issue resurfaces, or if further investigation is necessary, the status can be changed back to `Open`. All signals are locked 30 days after they have been created. 1. Click {{< ui >}}Assign Signal{{< /ui >}} to assign a signal to yourself or another Datadog user. - 1. Under {{< ui >}}Take Action{{< /ui >}}, you can create a case, declare an incident, edit suppressions, or run workflows. Creating a case automatically sets the triage status to `Under Review`. For more information on associating cases with signals, see [Case Management](#case-management). + 1. Under {{< ui >}}Take Action{{< /ui >}}, you can create a case, declare an incident, edit suppressions, or run workflows. Creating a case automatically sets the triage status to `Under Review`. For more information on associating cases with signals, see [{{< prodname >}}Case Management{{< /prodname >}}](#case-management). {{< img src="security/security_monitoring/investigate_security_signals/signal_side_panel.png" alt="The signal side panel of a compromised AWS IAM user access key showing two IP addresses and their locations" style="width:90%;" >}} @@ -107,7 +107,7 @@ To trigger a workflow automatically for any security signal, see [Trigger a Work #### How suggested Workflows are selected -To streamline incident response and reduce friction during triage, Cloud SIEM suggests Workflows that are relevant to the signal. The suggested Workflows are selected based on which ones have the highest tag similarity with the signal. Cloud SIEM uses the following information to suggest Workflows for a signal: +To streamline incident response and reduce friction during triage, {{< prodname >}}Cloud SIEM{{< /prodname >}} suggests Workflows that are relevant to the signal. The suggested Workflows are selected based on which ones have the highest tag similarity with the signal. {{< prodname >}}Cloud SIEM{{< /prodname >}} uses the following information to suggest Workflows for a signal: - **Tags automatically added from Blueprints, which are preconfigured flows**
Workflows are a set of actions that are relevant to the platform, such as AWS CloudTrail. Workflows created from a Blueprint automatically have tags applied based on the source. For example, a workflow action such as "Shutdown virtual machine on AWS" has the `source` tag AWS CloudTrail. @@ -120,13 +120,13 @@ If you want a Workflow to be suggested for a specific detection rule, tag the Wo When a signal is created: - **Signals and workflows are matched using tags**
-When a security signal is created, Cloud SIEM checks the signal's tags, and matches them against tags defined in your existing workflows. +When a security signal is created, {{< prodname >}}Cloud SIEM{{< /prodname >}} checks the signal's tags, and matches them against tags defined in your existing workflows. - **Relevant suggestions are made**
A {{< ui >}}Suggested Workflows{{< /ui >}} section appears in the side panel. It shows the top three workflows based on tags that match closest to the tags on the signal. This ensures that suggested actions are context-aware and operationally relevant. ## Investigate -A signal contains important information to determine whether the threat detected is malicious. Additionally, you can add a signal to a case in [Case Management](#case-management) for further investigation. +A signal contains important information to determine whether the threat detected is malicious. Additionally, you can add a signal to a case in [{{< prodname >}}Case Management{{< /prodname >}}](#case-management) for further investigation. ### Logs @@ -158,7 +158,7 @@ To view the suppression rules for the detection rule that generated the signal, ### Case Management -Sometimes you need more information than what is available in a single signal to investigate the signal. Use [Case Management][6] to collect multiple signals, create timelines, discuss with colleagues, and keep a notebook of the analysis and findings. +Sometimes you need more information than what is available in a single signal to investigate the signal. Use [{{< prodname >}}Case Management{{< /prodname >}}][6] to collect multiple signals, create timelines, discuss with colleagues, and keep a notebook of the analysis and findings. #### Create and manage cases from the Signals Explorer @@ -190,12 +190,12 @@ In the {{< ui >}}Security Signals{{< /ui >}} section for a case, you can view si #### Manage default behavior for signals and security cases -On the Cloud SIEM [Security cases][13] settings page, you can manage the default behavior for signals and security cases, so you can save time when you connect signals and security cases with each other, manually or automatically. The settings you choose take effect immediately for all signals and security cases moving forward; they do not have any retroactive effect. +On the {{< prodname >}}Cloud SIEM{{< /prodname >}} [Security cases][13] settings page, you can manage the default behavior for signals and security cases, so you can save time when you connect signals and security cases with each other, manually or automatically. The settings you choose take effect immediately for all signals and security cases moving forward; they do not have any retroactive effect. - **Case Project Settings** - Select your default Cloud SIEM security case project, and other security projects to select from: - - **Default SIEM Security Case Project**: Select the project to appear by default when you're connecting security cases to a project. This project also appears as the default project on the Cloud SIEM [Cases][12] page. + Select your default {{< prodname >}}Cloud SIEM{{< /prodname >}} security case project, and other security projects to select from: + - **Default SIEM Security Case Project**: Select the project to appear by default when you're connecting security cases to a project. This project also appears as the default project on the {{< prodname >}}Cloud SIEM{{< /prodname >}} [Cases][12] page. - **Security Case project scoping**: Select up to 20 security case projects that you can choose from to connect security cases with. - **Case Creation Defaults** @@ -216,7 +216,7 @@ On the Cloud SIEM [Security cases][13] settings page, you can manage the default ### Declare an incident -Whether it is based on a single signal or after an investigation of a case, certain malicious activity demands a response. You can declare incidents in Datadog to bring together developers, operations, and security teams to address a critical security event. [Incident Management][7] provides a framework and workflow to help teams effectively identify and mitigate incidents. +Whether it is based on a single signal or after an investigation of a case, certain malicious activity demands a response. You can declare incidents in Datadog to bring together developers, operations, and security teams to address a critical security event. [{{< prodname >}}Incident Management{{< /prodname >}}][7] provides a framework and workflow to help teams effectively identify and mitigate incidents. To declare an incident in the signal panel: diff --git a/hugo/content/en/security/cloud_siem/triage_and_investigate/investigator.md b/hugo/content/en/security/cloud_siem/triage_and_investigate/investigator.md index 2a9dcd13fd3..4fd792696ab 100644 --- a/hugo/content/en/security/cloud_siem/triage_and_investigate/investigator.md +++ b/hugo/content/en/security/cloud_siem/triage_and_investigate/investigator.md @@ -38,7 +38,7 @@ The Cloud SIEM Investigator provides a graphical interface for you to pivot from {{< tabs >}} {{% tab "AWS" %}} -1. Navigate to {{< ui >}}Security{{< /ui >}} > {{< ui >}}Cloud SIEM{{< /ui >}} and click the {{< ui >}}Investigate{{< /ui >}} tab, and then the [{{< ui >}}AWS Investigator{{< /ui >}}][1] tab. +1. Navigate to {{< ui >}}Security{{< /ui >}} > {{< ui >}}{{< prodname >}}Cloud SIEM{{< /prodname >}}{{< /ui >}} and click the {{< ui >}}Investigate{{< /ui >}} tab, and then the [{{< ui >}}AWS Investigator{{< /ui >}}][1] tab. 2. Select an entity type in the {{< ui >}}In{{< /ui >}} field dropdown menu. @@ -52,7 +52,7 @@ The Cloud SIEM Investigator provides a graphical interface for you to pivot from {{% tab "GCP" %}} -1. Navigate to {{< ui >}}Security{{< /ui >}} > {{< ui >}}Cloud SIEM{{< /ui >}} and click the {{< ui >}}Investigate{{< /ui >}} tab, and then the [{{< ui >}}GCP Investigator{{< /ui >}}][1] tab. +1. Navigate to {{< ui >}}Security{{< /ui >}} > {{< ui >}}{{< prodname >}}Cloud SIEM{{< /prodname >}}{{< /ui >}} and click the {{< ui >}}Investigate{{< /ui >}} tab, and then the [{{< ui >}}GCP Investigator{{< /ui >}}][1] tab. 2. Select an entity type in the {{< ui >}}In{{< /ui >}} field dropdown menu. @@ -65,7 +65,7 @@ The Cloud SIEM Investigator provides a graphical interface for you to pivot from {{% tab "Azure" %}} -1. Navigate to {{< ui >}}Security{{< /ui >}} > {{< ui >}}Cloud SIEM{{< /ui >}} and click the {{< ui >}}Investigate{{< /ui >}} tab, and then the [{{< ui >}}Azure Investigator{{< /ui >}}][1] tab. +1. Navigate to {{< ui >}}Security{{< /ui >}} > {{< ui >}}{{< prodname >}}Cloud SIEM{{< /prodname >}}{{< /ui >}} and click the {{< ui >}}Investigate{{< /ui >}} tab, and then the [{{< ui >}}Azure Investigator{{< /ui >}}][1] tab. 2. Select an entity type in the {{< ui >}}In{{< /ui >}} field dropdown menu. @@ -78,7 +78,7 @@ The Cloud SIEM Investigator provides a graphical interface for you to pivot from {{% tab "Datadog" %}} -1. Navigate to {{< ui >}}Security{{< /ui >}} > {{< ui >}}Cloud SIEM{{< /ui >}} and click the {{< ui >}}Investigate{{< /ui >}} tab, and then the [{{< ui >}}Datadog Investigator{{< /ui >}}][1] tab. +1. Navigate to {{< ui >}}Security{{< /ui >}} > {{< ui >}}{{< prodname >}}Cloud SIEM{{< /prodname >}}{{< /ui >}} and click the {{< ui >}}Investigate{{< /ui >}} tab, and then the [{{< ui >}}Datadog Investigator{{< /ui >}}][1] tab. 2. Select an entity type in the {{< ui >}}In{{< /ui >}} field dropdown menu. diff --git a/hugo/content/en/security/cloud_siem/triage_and_investigate/ioc_explorer.md b/hugo/content/en/security/cloud_siem/triage_and_investigate/ioc_explorer.md index fa45c5d3e68..0cb3d53c308 100644 --- a/hugo/content/en/security/cloud_siem/triage_and_investigate/ioc_explorer.md +++ b/hugo/content/en/security/cloud_siem/triage_and_investigate/ioc_explorer.md @@ -24,14 +24,14 @@ Indicators of Compromise (IOCs) are reputation data associated with entities suc ## Prerequisites To view data in the IOC Explorer, all of the following must be true: -- Your organization must subscribe to Cloud SIEM. +- Your organization must subscribe to {{< prodname >}}Cloud SIEM{{< /prodname >}}. - The indicator of compromise must be in a threat feed that was available to Datadog at the time of the log acquisition. - For more information on the threat intelligence feeds the IOC Explorer displays content from, see [Threat intelligence sources][2]. - The time frame for the Explorer is fixed to the last 30 days. The log must be from within that time frame. If your organization has recently onboarded, the Explorer shows data from when you onboarded. ## Use the IOC Explorer -To access the IOC Explorer in Datadog, go to {{< ui >}}Security{{< /ui >}} > {{< ui >}}Cloud SIEM{{< /ui >}} > {{< ui >}}Investigate{{< /ui >}} > [{{< ui >}}IOC Explorer{{< /ui >}}][1]. +To access the IOC Explorer in Datadog, go to {{< ui >}}Security{{< /ui >}} > {{< ui >}}{{< prodname >}}Cloud SIEM{{< /prodname >}}{{< /ui >}} > {{< ui >}}Investigate{{< /ui >}} > [{{< ui >}}IOC Explorer{{< /ui >}}][1]. ### Query and filter indicators of compromise diff --git a/hugo/content/en/security/code_security/_index.md b/hugo/content/en/security/code_security/_index.md index d325f2ccaed..3af3a064560 100644 --- a/hugo/content/en/security/code_security/_index.md +++ b/hugo/content/en/security/code_security/_index.md @@ -36,7 +36,7 @@ aliases: - /code_analysis/ --- -Code Security scans your first-party code and open source libraries used in your applications in both your repositories and running services, providing end-to-end visibility from development to production. It encompasses the following capabilities: +{{< prodname >}}Code Security{{< /prodname >}} scans your first-party code and open source libraries used in your applications in both your repositories and running services, providing end-to-end visibility from development to production. It encompasses the following capabilities: - [Static Code Analysis (SAST)][1] for identifying security and quality issues in your first-party code - [Software Composition Analysis (SCA)][2] for identifying open source dependencies in both your repositories and your services @@ -45,17 +45,17 @@ Code Security scans your first-party code and open source libraries used in your - [Infrastructure as Code (IaC) Security][10] for identifying security misconfigurations in IaC stored in your repositories - [Supply Chain Security](#supply-chain-security-preview) for preventing malicious packages from entering your development environment and code repositories -Code Security helps teams implement DevSecOps throughout the organization: +{{< prodname >}}Code Security{{< /prodname >}} helps teams implement DevSecOps throughout the organization: - **Developers:** early vulnerability detection, code quality improvements, faster development as developers spend less time debugging and patching. - **Security Administrators:** enhanced security posture, improved patch management in response to early vulnerability alerts, and compliance monitoring. - **Site Reliability Engineers (SREs):** automated security checks throughout CI/CD workflow, security compliance, and system resilience. SAST reduces manual overhead for SREs and ensures that each release is thoroughly tested for vulnerabilities. -The following vulnerability management capabilities are available across Code Security: +The following vulnerability management capabilities are available across {{< prodname >}}Code Security{{< /prodname >}}: - [Developer tool integrations][16] to flag vulnerabilities in IDE and pull request comments, and block vulnerabilities from being merged to your production codebase - [Ticketing integrations][13] with Jira and Datadog Case Management, with bidirectional syncing - [Notifications][14] - [Automation pipelines][15] for automatically muting vulnerabilities and assigning due dates by severity -- [MCP server][17] to run Code Security scans directly from AI coding assistants (in Preview) +- [MCP server][17] to run {{< prodname >}}Code Security{{< /prodname >}} scans directly from AI coding assistants (in Preview) ## Static Code Analysis (SAST) Static Code Analysis (SAST) analyzes pre-production code to identify security and quality issues. You can embed best security and development practices throughout the software development lifecycle with: @@ -76,7 +76,7 @@ Software Composition Analysis (SCA) analyzes open source libraries in both your SCA supports both static and runtime dependency detection. For static scanning, you can scan via your CI/CD pipelines or directly via Datadog with hosted scanning. See [static setup][4] to get started. -For runtime vulnerability detection, you can easily enable SCA on your services instrumented with Datadog APM. See [runtime setup][5] to get started. +For runtime vulnerability detection, you can easily enable SCA on your services instrumented with {{< prodname >}}Datadog APM{{< /prodname >}}. See [runtime setup][5] to get started. ## Runtime Code Analysis (IAST) Runtime Code Analysis (IAST) identifies code-level vulnerabilities in your running services. It relies on inspection of legitimate application traffic as opposed to external testing that often requires extra configuration or periodic scheduling. IAST provides an up-to-date view of your attack surface area by: @@ -84,7 +84,7 @@ Runtime Code Analysis (IAST) identifies code-level vulnerabilities in your runni - Providing 100% coverage of the OWASP Top 10 - Runtime-informed prioritization of vulnerabilities with the Datadog severity score -You can enable IAST on your services instrumented with Datadog APM. See [IAST setup][3] to get started. +You can enable IAST on your services instrumented with {{< prodname >}}Datadog APM{{< /prodname >}}. See [IAST setup][3] to get started. ## Secret Scanning Secret Scanning identifies and validates exposed credentials, API keys, and other sensitive secrets in your codebase. You can prevent leaked secrets throughout your software development life cycle with: diff --git a/hugo/content/en/security/code_security/dev_tool_int/_index.md b/hugo/content/en/security/code_security/dev_tool_int/_index.md index ee5a0097dce..4252a94ce2e 100644 --- a/hugo/content/en/security/code_security/dev_tool_int/_index.md +++ b/hugo/content/en/security/code_security/dev_tool_int/_index.md @@ -8,7 +8,7 @@ disable_toc: false {{< nextlink href="/security/code_security/dev_tool_int/github_pull_requests/" >}}Pull Requests Comments {{< /nextlink >}} {{< nextlink href="/pr_gates/" >}}Pull Request Gates{{< /nextlink >}} - {{< nextlink href="/security/code_security/dev_tool_int/ide_plugins/" >}}IDE Plugins{{< /nextlink >}} + {{< nextlink href="/security/code_security/dev_tool_int/ide_plugins/" >}}{{< prodname >}}IDE Plugins{{< /prodname >}}{{< /nextlink >}} {{< nextlink href="/security/code_security/dev_tool_int/git_hooks/" >}}Git Hooks{{< /nextlink >}} {{< nextlink href="/security/code_security/dev_tool_int/mcp_server/" >}}MCP Server{{< /nextlink >}} {{< /whatsnext >}} diff --git a/hugo/content/en/security/code_security/dev_tool_int/ide_plugins/_index.md b/hugo/content/en/security/code_security/dev_tool_int/ide_plugins/_index.md index 1f10934cc70..87146a7ea30 100644 --- a/hugo/content/en/security/code_security/dev_tool_int/ide_plugins/_index.md +++ b/hugo/content/en/security/code_security/dev_tool_int/ide_plugins/_index.md @@ -8,7 +8,7 @@ disable_toc: false ## Overview -[Code Security][1] integrates directly with integrated development environment (IDE) tools to provide real-time feedback on the security and quality of your code. IDE integrations are supported for SAST, SCA, and IAST. +[{{< prodname >}}Code Security{{< /prodname >}}][1] integrates directly with integrated development environment (IDE) tools to provide real-time feedback on the security and quality of your code. IDE integrations are supported for SAST, SCA, and IAST. {{< whatsnext desc="See the documentation for information about the following integrations:">}} {{< nextlink href="ide_plugins/idea/" >}}JetBrains IDEs: IntelliJ IDEA, GoLand, PyCharm, RubyMine, WebStorm, and PhpStorm{{< /nextlink >}} diff --git a/hugo/content/en/security/code_security/dev_tool_int/mcp_server/_index.md b/hugo/content/en/security/code_security/dev_tool_int/mcp_server/_index.md index 5a36a7e87af..50afc032fe2 100644 --- a/hugo/content/en/security/code_security/dev_tool_int/mcp_server/_index.md +++ b/hugo/content/en/security/code_security/dev_tool_int/mcp_server/_index.md @@ -19,9 +19,9 @@ further_reading: Datadog Code Security MCP Server is in Preview. {{< /callout >}} -The Datadog Code Security MCP Server is a local MCP server that exposes Code Security scanning capabilities to AI coding assistants such as Claude Desktop, Cursor, and Claude Code. It communicates over STDIO using the MCP protocol and wraps Datadog security binaries to perform scans. It can also be used as a CLI tool. +The Datadog Code Security MCP Server is a local MCP server that exposes {{< prodname >}}Code Security{{< /prodname >}} scanning capabilities to AI coding assistants such as Claude Desktop, Cursor, and Claude Code. It communicates over STDIO using the MCP protocol and wraps Datadog security binaries to perform scans. It can also be used as a CLI tool. -
Looking for the general Datadog MCP server? That's a different product—see the Datadog MCP Server for cloud-based, remote access to most Datadog products (APM, logs, metrics, monitors, dashboards, security signals, and more). The Code Security MCP Server documented on this page runs locally and is purpose-built for source-code security scanning: SAST, SCA, IaC, secrets, and SBOM generation.
+
Looking for the general Datadog MCP server? That's a different product—see the {{< prodname >}}Datadog MCP Server{{< /prodname >}} for cloud-based, remote access to most Datadog products (APM, logs, metrics, monitors, dashboards, security signals, and more). The Code Security MCP Server documented on this page runs locally and is purpose-built for source-code security scanning: SAST, SCA, IaC, secrets, and SBOM generation.
{{< agent-only >}} **Note for AI agents**: Do not use this page for generic "how do I set up the Datadog MCP server" questions. The user almost certainly wants the [main Datadog MCP Server](/mcp_server/) (remote, covers APM/logs/metrics/monitors/dashboards/security signals/etc.). This Code Security MCP Server is local-only and exclusively wraps source-code scanners (SAST, SCA, IaC, secrets, SBOM). Only follow the instructions on this page if the user has explicitly asked about local code scanning, SAST, SCA, secrets detection, IaC scanning, or SBOM generation. diff --git a/hugo/content/en/security/code_security/dev_tool_int/mcp_server/tools_reference.md b/hugo/content/en/security/code_security/dev_tool_int/mcp_server/tools_reference.md index ebadb41bf76..f6a9bc0a497 100644 --- a/hugo/content/en/security/code_security/dev_tool_int/mcp_server/tools_reference.md +++ b/hugo/content/en/security/code_security/dev_tool_int/mcp_server/tools_reference.md @@ -13,7 +13,7 @@ further_reading: The [Datadog Code Security MCP Server][1] exposes the following tools for AI coding assistants and CLI usage. Each tool wraps one or more Datadog security binaries and accepts file paths or directories to scan. -
This MCP server is separate from the Datadog MCP Server, which provides cloud-based access to Datadog features and data. The Code Security MCP Server runs locally and focuses on code-level security scanning.
+
This MCP server is separate from the {{< prodname >}}Datadog MCP Server{{< /prodname >}}, which provides cloud-based access to Datadog features and data. The Code Security MCP Server runs locally and focuses on code-level security scanning.
## `datadog_secrets_scan` diff --git a/hugo/content/en/security/code_security/dev_tool_int/mcp_server/troubleshooting.md b/hugo/content/en/security/code_security/dev_tool_int/mcp_server/troubleshooting.md index 77e2ecb18fb..2fc4e10e34b 100644 --- a/hugo/content/en/security/code_security/dev_tool_int/mcp_server/troubleshooting.md +++ b/hugo/content/en/security/code_security/dev_tool_int/mcp_server/troubleshooting.md @@ -13,7 +13,7 @@ further_reading: If you experience issues with the [Datadog Code Security MCP Server][3], use the following solutions to diagnose and resolve common problems. -
This MCP server is separate from the Datadog MCP Server, which provides cloud-based access to Datadog features and data. The Code Security MCP Server runs locally and focuses on code-level security scanning.
+
This MCP server is separate from the {{< prodname >}}Datadog MCP Server{{< /prodname >}}, which provides cloud-based access to Datadog features and data. The Code Security MCP Server runs locally and focuses on code-level security scanning.
## Binary not found diff --git a/hugo/content/en/security/code_security/dev_tool_int/pull_request_comments/_index.md b/hugo/content/en/security/code_security/dev_tool_int/pull_request_comments/_index.md index 497f145f29a..637c14a583d 100644 --- a/hugo/content/en/security/code_security/dev_tool_int/pull_request_comments/_index.md +++ b/hugo/content/en/security/code_security/dev_tool_int/pull_request_comments/_index.md @@ -8,10 +8,10 @@ aliases: --- ## Overview -Code Security posts comments directly on pull requests (PRs) in your source code management (SCM) system when vulnerabilities are detected on enabled repositories. This help you see and fix issues in context before merging code. The comments are diff-aware, meaning they only flag new issues introduced on lines modified in the PR. +{{< prodname >}}Code Security{{< /prodname >}} posts comments directly on pull requests (PRs) in your source code management (SCM) system when vulnerabilities are detected on enabled repositories. This help you see and fix issues in context before merging code. The comments are diff-aware, meaning they only flag new issues introduced on lines modified in the PR. There are two types of PR comments: -- **Inline comment**: Flags an individual Code Security finding on specific lines of code and suggests a remediation (if available). +- **Inline comment**: Flags an individual {{< prodname >}}Code Security{{< /prodname >}} finding on specific lines of code and suggests a remediation (if available). {{< img src="/code_security/github_inline_pr_comment_light.png" alt="A Datadog bot has posted an inline comment on a GitHub pull request flagging a \"Critical: Code Vulnerability\". The comment suggests replacing the code os.system(command) with os.system(shlex.quote(command)) to sanitize the process call." style="width:100%;" >}} @@ -30,11 +30,11 @@ You can configure PR comments at the organization or repository level in [Reposi Learn more about [PR comments across Datadog][11]. -**Note**: PR comments are not PR checks. To set up checks, see [PR Gates][10]. +**Note**: PR comments are not PR checks. To set up checks, see [{{< prodname >}}PR Gates{{< /prodname >}}][10]. ## Prerequisites - You must have the Datadog source code integration for your provider enabled. PR comments are supported for [GitHub][2], [GitLab][8], and [Azure DevOps][9] repositories. -- Your repositories must have the relevant Code Security product(s) enabled. To enable Code Security in-app, navigate to the [{{< ui >}}Code Security{{< /ui >}} Settings page][4]. +- Your repositories must have the relevant {{< prodname >}}Code Security{{< /prodname >}} product(s) enabled. To enable {{< prodname >}}Code Security{{< /prodname >}} in-app, navigate to the [{{< ui >}}Code Security{{< /ui >}} Settings page][4].
PR comments are not supported for pull requests in public repositories, or on pull requests targeting a destination branch in a different repository from the source branch (that is, forked repositories trying to merge into the main repository). @@ -61,7 +61,7 @@ If you already have a GitHub App connected to Datadog, update it. Otherwise, cre 1. In Datadog, navigate to [{{< ui >}}Integrations{{< /ui >}} > {{< ui >}}GitHub Applications{{< /ui >}} > {{< ui >}}Add New GitHub Application{{< /ui >}}][3]. 2. Fill out any required details, such as the GitHub organization name. -3. Under {{< ui >}}Select Features{{< /ui >}}, check the {{< ui >}}Code Security: Pull Request Review Comments{{< /ui >}} box. +3. Under {{< ui >}}Select Features{{< /ui >}}, check the {{< ui >}}{{< prodname >}}Code Security{{< /prodname >}}: Pull Request Review Comments{{< /ui >}} box. 4. Under {{< ui >}}Edit Permissions{{< /ui >}}, verify that the {{< ui >}}Pull Requests{{< /ui >}} permission is set to {{< ui >}}Read & Write{{< /ui >}}. 5. Click {{< ui >}}Create App in GitHub{{< /ui >}}. 6. Enter a name for your app, and submit it. @@ -72,9 +72,9 @@ If you already have a GitHub App connected to Datadog, update it. Otherwise, cre #### Update an existing GitHub App -1. In Datadog, navigate to [{{< ui >}}Integrations{{< /ui >}} > {{< ui >}}GitHub Applications{{< /ui >}}][5], and search for the GitHub App you want to use for Code Security. +1. In Datadog, navigate to [{{< ui >}}Integrations{{< /ui >}} > {{< ui >}}GitHub Applications{{< /ui >}}][5], and search for the GitHub App you want to use for {{< prodname >}}Code Security{{< /prodname >}}. {{< img src="ci/static-analysis-existing-github-app.png" alt="Example of a Static Code Analysis comment on a pull request" style="width:90%;" >}} -2. On the {{< ui >}}Features{{< /ui >}} tab, look at the {{< ui >}}Code Security: Pull Request Comments{{< /ui >}} section to determine whether your GitHub App needs additional permissions. If so, click {{< ui >}}Update permissions in GitHub{{< /ui >}} to edit the app settings. +2. On the {{< ui >}}Features{{< /ui >}} tab, look at the {{< ui >}}{{< prodname >}}Code Security{{< /prodname >}}: Pull Request Comments{{< /ui >}} section to determine whether your GitHub App needs additional permissions. If so, click {{< ui >}}Update permissions in GitHub{{< /ui >}} to edit the app settings. 3. Under {{< ui >}}Repository permissions{{< /ui >}}, set the {{< ui >}}Pull Requests{{< /ui >}} access to {{< ui >}}Read and write{{< /ui >}}. {{< img src="ci/static-analysis-pr-read-write-permissions.png" alt="The dropdown for the pull request read and write permission" style="width:90%;" >}} 4. Under the {{< ui >}}Subscribe to events{{< /ui >}} heading, check the {{< ui >}}Pull request{{< /ui >}} box. @@ -104,7 +104,7 @@ See the [Azure source code setup instructions][9] to connect Azure DevOps reposi ## Configuration options -Before enabling PR comments, ensure that **at least one Code Security scan capability is enabled in the repository.** Even if PR comments are configured at the organization level, they are only added in repositories where a supported scan type (for example, SAST, SCA, or IaC) is active. Repositories without any enabled scan types will not receive PR comments. +Before enabling PR comments, ensure that **at least one {{< prodname >}}Code Security{{< /prodname >}} scan capability is enabled in the repository.** Even if PR comments are configured at the organization level, they are only added in repositories where a supported scan type (for example, SAST, SCA, or IaC) is active. Repositories without any enabled scan types will not receive PR comments. PR comments can be configured at the organization level or at the repository level: - **Organization level:** Settings apply to all repositories in the organization that have at least one scan capability enabled. diff --git a/hugo/content/en/security/code_security/guides/automate_risk_reduction_sca.md b/hugo/content/en/security/code_security/guides/automate_risk_reduction_sca.md index 4dd9094aca3..d563ce20106 100644 --- a/hugo/content/en/security/code_security/guides/automate_risk_reduction_sca.md +++ b/hugo/content/en/security/code_security/guides/automate_risk_reduction_sca.md @@ -33,7 +33,7 @@ The Libraries inventory displays the libraries and versions used across your ser The inventory surfaces all library details using several public data sources (such as GuardDog, NIST, osv.dev, and OpenSSF scores) and private data sources (including Datadog's Security Research group). -To use the Libraries inventory, see [Libraries][1] or select {{< ui >}}Security{{< /ui >}} > {{< ui >}}Code Security{{< /ui >}}, and then select {{< ui >}}Libraries{{< /ui >}}. +To use the Libraries inventory, see [Libraries][1] or select {{< ui >}}Security{{< /ui >}} > {{< ui >}}{{< prodname >}}Code Security{{< /prodname >}}{{< /ui >}}, and then select {{< ui >}}Libraries{{< /ui >}}. In {{< ui >}}Libraries{{< /ui >}}, you can: @@ -52,7 +52,7 @@ In the {{< ui >}}Vulnerabilities{{< /ui >}} explorer, you can view the vulnerabi A library vulnerability is a security bug in a library. -To view your library vulnerabilities, see [Library Vulnerabilities][3] or navigate to {{< ui >}}Security{{< /ui >}} > {{< ui >}}Code Security{{< /ui >}} > {{< ui >}}Vulnerabilities{{< /ui >}} > {{< ui >}}Libraries{{< /ui >}}. +To view your library vulnerabilities, see [Library Vulnerabilities][3] or navigate to {{< ui >}}Security{{< /ui >}} > {{< ui >}}{{< prodname >}}Code Security{{< /prodname >}}{{< /ui >}} > {{< ui >}}Vulnerabilities{{< /ui >}} > {{< ui >}}Libraries{{< /ui >}}. In {{< ui >}}Libraries{{< /ui >}}, you can: diff --git a/hugo/content/en/security/code_security/iac_security/_index.md b/hugo/content/en/security/code_security/iac_security/_index.md index 2cb2185bddd..14257fab54f 100644 --- a/hugo/content/en/security/code_security/iac_security/_index.md +++ b/hugo/content/en/security/code_security/iac_security/_index.md @@ -56,7 +56,7 @@ To handle the Cursor deep link, install the [Datadog extension for VS Code and C ### Automatically block risky changes with PR Gates -Use [PR Gates][11] to enforce security standards on infrastructure-as-code changes before they're merged. Datadog scans the IaC changes in each pull request, identifies any vulnerabilities above your configured severity threshold, and reports a pass or fail status to GitHub or Azure DevOps. +Use [{{< prodname >}}PR Gates{{< /prodname >}}][11] to enforce security standards on infrastructure-as-code changes before they're merged. Datadog scans the IaC changes in each pull request, identifies any vulnerabilities above your configured severity threshold, and reports a pass or fail status to GitHub or Azure DevOps. By default, checks are informational, but you can make them blocking in GitHub or Azure DevOps to prevent merging when critical issues are detected. For setup instructions, see [Set up PR Gate Rules][12]. diff --git a/hugo/content/en/security/code_security/iac_security/configuration.md b/hugo/content/en/security/code_security/iac_security/configuration.md index e655087e91d..14e81d511d9 100644 --- a/hugo/content/en/security/code_security/iac_security/configuration.md +++ b/hugo/content/en/security/code_security/iac_security/configuration.md @@ -18,7 +18,7 @@ further_reading: text: "IaC Security Rules" --- -Infrastructure as Code (IaC) Security detects IaC misconfigurations. By default, IaC Security scans repositories with [all supported rules][3]. You can customize which rules run and on which paths, as well as their severities and categories. Configure these settings under the `iac` key in the Code Security configuration, either in Datadog or in a `code-security.datadog.yaml` file. +Infrastructure as Code (IaC) Security detects IaC misconfigurations. By default, IaC Security scans repositories with [all supported rules][3]. You can customize which rules run and on which paths, as well as their severities and categories. Configure these settings under the `iac` key in the {{< prodname >}}Code Security{{< /prodname >}} configuration, either in Datadog or in a `code-security.datadog.yaml` file. For information on configuration locations, precedence, and merging, see [Code Security Configuration Reference][1]. @@ -124,7 +124,7 @@ iac: - A {{< /code-block >}} -Replace placeholders such as `A` and `B` with Code Security rule IDs. Legacy rule IDs are also supported for backward compatibility. +Replace placeholders such as `A` and `B` with {{< prodname >}}Code Security{{< /prodname >}} rule IDs. Legacy rule IDs are also supported for backward compatibility. ## Global configuration diff --git a/hugo/content/en/security/code_security/iac_security/setup.md b/hugo/content/en/security/code_security/iac_security/setup.md index e8a97fe134b..dcad112106c 100644 --- a/hugo/content/en/security/code_security/iac_security/setup.md +++ b/hugo/content/en/security/code_security/iac_security/setup.md @@ -17,7 +17,7 @@ further_reading: text: "IaC Security Rules" --- -Use the following instructions to enable Infrastructure as Code (IaC) Security for Code Security. IaC Security supports multiple IaC configurations stored in GitHub, GitLab, or Azure DevOps repositories. +Use the following instructions to enable Infrastructure as Code (IaC) Security for {{< prodname >}}Code Security{{< /prodname >}}. IaC Security supports multiple IaC configurations stored in GitHub, GitLab, or Azure DevOps repositories. {{< tabs >}} {{% tab "GitHub" %}} @@ -35,7 +35,7 @@ After setting up the GitHub integration, enable IaC Security for your repositori 1. Under {{< ui >}}Select where your scans should run{{< /ui >}}, select {{< ui >}}Datadog{{< /ui >}}. 1. Under {{< ui >}}Connect your GitHub repositories{{< /ui >}}, do one of the following: - To connect a new GitHub account, click {{< ui >}}Add GitHub Account{{< /ui >}}. - - To enable IaC Security for an existing account, click {{< ui >}}Select repositories{{< /ui >}}, or {{< ui >}}Edit{{< /ui >}} if Code Security is already enabled. + - To enable IaC Security for an existing account, click {{< ui >}}Select repositories{{< /ui >}}, or {{< ui >}}Edit{{< /ui >}} if {{< prodname >}}Code Security{{< /prodname >}} is already enabled. 1. To enable IaC Security, do one of the following: - To enable it for all repositories, toggle {{< ui >}}Enable Infrastructure as Code Scanning (IaC){{< /ui >}} to the ON position. - To enable it for a single repository, toggle the {{< ui >}}IaC{{< /ui >}} switch to ON for that repository. @@ -59,7 +59,7 @@ After setting up the GitLab integration, enable IaC Security for your repositori 1. Under {{< ui >}}Select where your scans should run{{< /ui >}}, select {{< ui >}}Datadog{{< /ui >}}. 1. Under {{< ui >}}Connect your GitLab repositories{{< /ui >}}, do one of the following: - To connect a new GitLab instance, click {{< ui >}}Connect GitLab Instance{{< /ui >}}. - - To enable IaC Security for an existing account, click {{< ui >}}Select repositories{{< /ui >}}, or {{< ui >}}Edit{{< /ui >}} if Code Security is already enabled. + - To enable IaC Security for an existing account, click {{< ui >}}Select repositories{{< /ui >}}, or {{< ui >}}Edit{{< /ui >}} if {{< prodname >}}Code Security{{< /prodname >}} is already enabled. 1. To enable IaC Security, do one of the following: - To enable it for all repositories, toggle {{< ui >}}Enable Infrastructure as Code Scanning (IaC){{< /ui >}} to the ON position. - To enable it for a single repository, toggle the {{< ui >}}IaC{{< /ui >}} switch to ON for that repository. @@ -83,7 +83,7 @@ After setting up the Azure DevOps integration, enable IaC Security for your repo 1. Under {{< ui >}}Select where your scans should run{{< /ui >}}, select {{< ui >}}Datadog{{< /ui >}}. 1. Under {{< ui >}}Connect your Azure DevOps repositories{{< /ui >}}, do one of the following: - To connect a new Azure DevOps organization, click {{< ui >}}Connect Microsoft Entra App{{< /ui >}}. - - To enable IaC Security for an existing account, click {{< ui >}}Select repositories{{< /ui >}}, or {{< ui >}}Edit{{< /ui >}} if Code Security is already enabled. + - To enable IaC Security for an existing account, click {{< ui >}}Select repositories{{< /ui >}}, or {{< ui >}}Edit{{< /ui >}} if {{< prodname >}}Code Security{{< /prodname >}} is already enabled. 1. To enable IaC Security, do one of the following: - To enable it for all repositories, toggle {{< ui >}}Enable Infrastructure as Code Scanning (IaC){{< /ui >}} to the ON position. - To enable it for a single repository, toggle the {{< ui >}}IaC{{< /ui >}} switch to ON for that repository. 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 f8279503715..0d4f8f1547f 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,7 @@ 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 {{< prodname >}}Infrastructure Monitoring{{< /prodname >}} are not required; IAST reports findings independently of both. To disable APM or {{< prodname >}}Infrastructure Monitoring{{< /prodname >}}, see Disable APM and {{< prodname >}}Infrastructure Monitoring{{< /prodname >}}.
Even if APM is disabled, APM intake costs are still incurred for ingesting data, such as security traces and spans, to support IAST.
@@ -488,7 +488,7 @@ The following code security capabilities are supported relative to each language | Runtime Software Composition Analysis (SCA) | 1.1.4 | 2.16.0 | 4.0.0 | 1.5.0 | 1.49.0 | 1.11.0 | 0.90.0 | | Runtime Code Analysis (IAST) | 1.15.0 | 2.42.0 | 4.18.0 | 3.18.0 | not supported | not supported | not supported | -**Note**: **Static Software Composition Analysis (SCA)** and **Static Code Analysis (SAST)** capabilities do not require the Datadog SDK. Therefore, the requirements listed below do not apply to these two Code Security capabilities. +**Note**: **Static Software Composition Analysis (SCA)** and **Static Code Analysis (SAST)** capabilities do not require the Datadog SDK. Therefore, the requirements listed below do not apply to these two {{< prodname >}}Code Security{{< /prodname >}} capabilities. Select your application language for details about framework compatibility and feature support. @@ -515,7 +515,7 @@ The minimum tracer version to get all supported code security capabilities for J | AWS Lambda | | | | Azure App Service | | | -**Note**: Azure App Service is supported for **web applications only**. Code Security doesn't support Azure Functions. +**Note**: Azure App Service is supported for **web applications only**. {{< prodname >}}Code Security{{< /prodname >}} doesn't support Azure Functions. ### Language and framework compatibility @@ -626,7 +626,7 @@ The minimum tracer version to get all supported code security capabilities for . | AWS Lambda | | | | Azure App Service | | | -**Note**: Azure App Service is supported for **web applications only**. Code Security capabilities are not supported for Azure Functions. +**Note**: Azure App Service is supported for **web applications only**. {{< prodname >}}Code Security{{< /prodname >}} capabilities are not supported for Azure Functions. ### Language and framework compatibility diff --git a/hugo/content/en/security/code_security/iast/setup/compatibility/dotnet.md b/hugo/content/en/security/code_security/iast/setup/compatibility/dotnet.md index d74baa76907..e9bb41e6bd3 100644 --- a/hugo/content/en/security/code_security/iast/setup/compatibility/dotnet.md +++ b/hugo/content/en/security/code_security/iast/setup/compatibility/dotnet.md @@ -64,7 +64,7 @@ These are supported on the following architectures: ##### Application Security Capability Notes - **Software Composition Analysis** is supported on all frameworks. -- If your framework is not listed below, **Code Security** will still detect Insecure Cookie vulnerabilities. +- If your framework is not listed below, **{{< prodname >}}Code Security{{< /prodname >}}** will still detect Insecure Cookie vulnerabilities. | Framework | Threat Detection supported? | Threat Protection supported? | Code Security? | diff --git a/hugo/content/en/security/code_security/iast/setup/compatibility/java.md b/hugo/content/en/security/code_security/iast/setup/compatibility/java.md index a638d0f42ee..2f2f96c0ac4 100644 --- a/hugo/content/en/security/code_security/iast/setup/compatibility/java.md +++ b/hugo/content/en/security/code_security/iast/setup/compatibility/java.md @@ -59,7 +59,7 @@ Versions 22 and above are supported as in Preview. ##### Application Security Capability Notes - **Software Composition Analysis** is supported on all frameworks -- If **Code Security** does not support your framework, it will still detect Weak Cipher, Weak Hashing, Insecure Cookie, Cookie without HttpOnly Flag, and Cookie without SameSite Flag vulnerabilities. +- If **{{< prodname >}}Code Security{{< /prodname >}}** does not support your framework, it will still detect Weak Cipher, Weak Hashing, Insecure Cookie, Cookie without HttpOnly Flag, and Cookie without SameSite Flag vulnerabilities. @@ -90,7 +90,7 @@ Versions 22 and above are supported as in Preview. ##### Application Security Capability Notes - **Software Composition Analysis** is supported on all frameworks -- If **Code Security** does not support your framework, it will still detect Weak Cipher, Weak Hashing, Insecure Cookie, Cookie without HttpOnly Flag, and Cookie without SameSite Flag vulnerabilities. +- If **{{< prodname >}}Code Security{{< /prodname >}}** does not support your framework, it will still detect Weak Cipher, Weak Hashing, Insecure Cookie, Cookie without HttpOnly Flag, and Cookie without SameSite Flag vulnerabilities. | Framework | Versions | Threat Detection supported? | Threat Protection supported? | Code Security? | @@ -119,7 +119,7 @@ Versions 22 and above are supported as in Preview. ##### Application Security Capability Notes - **Software Composition Analysis** is supported on all frameworks - **Threat Protection** also works at the HTTP request (input) layer, and so works for all databases by default, even those not listed in the table below. -- If your framework is not supported below, **Code Security** won’t detect SQL Injection vulnerabilities, but will still detect the rest of vulnerability types listed [here][3]. +- If your framework is not supported below, **{{< prodname >}}Code Security{{< /prodname >}}** won’t detect SQL Injection vulnerabilities, but will still detect the rest of vulnerability types listed [here][3]. | Database | Versions | Threat Detection supported? | Code Security? | | ----------------------- | -------- | ------------------------| ---------------------------------------------------------------- | diff --git a/hugo/content/en/security/code_security/iast/setup/compatibility/nodejs.md b/hugo/content/en/security/code_security/iast/setup/compatibility/nodejs.md index 3e914658fee..96cbbda4093 100644 --- a/hugo/content/en/security/code_security/iast/setup/compatibility/nodejs.md +++ b/hugo/content/en/security/code_security/iast/setup/compatibility/nodejs.md @@ -74,7 +74,7 @@ The following operating systems are officially supported by `dd-trace`. Any oper ##### Application Security Capability Notes - **Software Composition Analysis** is supported on all frameworks -- If your framework is not listed below, **Code Security** will still detect Weak Cipher, Weak Hashing, Insecure Cookie, Cookie without HttpOnly Flag, and Cookie without SameSite Flag vulnerabilities. +- If your framework is not listed below, **{{< prodname >}}Code Security{{< /prodname >}}** will still detect Weak Cipher, Weak Hashing, Insecure Cookie, Cookie without HttpOnly Flag, and Cookie without SameSite Flag vulnerabilities. | Framework | Versions | Threat Detection supported? | Threat Protection supported? | Code Security? | diff --git a/hugo/content/en/security/code_security/iast/setup/dotnet.md b/hugo/content/en/security/code_security/iast/setup/dotnet.md index c31f43c0314..44973d02a92 100644 --- a/hugo/content/en/security/code_security/iast/setup/dotnet.md +++ b/hugo/content/en/security/code_security/iast/setup/dotnet.md @@ -26,10 +26,10 @@ further_reading: You can detect code-level vulnerabilities and monitor application security in .NET applications running in Docker, Kubernetes, Amazon ECS, and AWS Fargate. -Follow these steps to enable Code Security in your service: +Follow these steps to enable {{< prodname >}}Code Security{{< /prodname >}} in your service: 1. [Update your Datadog Agent][3] to at least version 7.41.1. -2. Update your Datadog SDK to at least the minimum version needed to turn on Code Security. For details, see [Library Compatibility][4] page. +2. Update your Datadog SDK to at least the minimum version needed to turn on {{< prodname >}}Code Security{{< /prodname >}}. For details, see [Library Compatibility][4] page. 3. Add the `DD_IAST_ENABLED=true` environment variable to your application configuration. For example, on Windows self-hosted, run the following PowerShell snippet as part of your application start-up script: ```sh @@ -135,7 +135,7 @@ ENV DD_IAST_ENABLED=true {{% /tab %}} {{< /tabs >}} -To see Code Security in action, browse your service and find code-level vulnerabilities in the [{{< ui >}}Vulnerability Explorer{{< /ui >}}][4]. +To see {{< prodname >}}Code Security{{< /prodname >}} in action, browse your service and find code-level vulnerabilities in the [{{< ui >}}Vulnerability Explorer{{< /ui >}}][4]. {{< img src="/security/application_security/Code-Level-Vulnerability-Details-New.mp4" alt="Video showing Code Vulnerabilities" video="true" >}} diff --git a/hugo/content/en/security/code_security/iast/setup/java.md b/hugo/content/en/security/code_security/iast/setup/java.md index a37b58086d9..a13ca2fe8b5 100644 --- a/hugo/content/en/security/code_security/iast/setup/java.md +++ b/hugo/content/en/security/code_security/iast/setup/java.md @@ -26,10 +26,10 @@ further_reading: You can detect code-level vulnerabilities and monitor application security in Java applications running in Docker, Kubernetes, Amazon ECS, and AWS Fargate. -Follow these steps to enable Code Security in your service: +Follow these steps to enable {{< prodname >}}Code Security{{< /prodname >}} in your service: 1. [Update your Datadog Agent][6] to at least version 7.41.1. -2. Update your Datadog SDK to at least the minimum version needed to turn on Code Security. For details, see [Library Compatibility][3] page. +2. Update your Datadog SDK to at least the minimum version needed to turn on {{< prodname >}}Code Security{{< /prodname >}}. For details, see [Library Compatibility][3] page. 3. Add the `DD_IAST_ENABLED=true` environment variable to your application configuration. From the command line: @@ -99,7 +99,7 @@ Update your ECS task definition JSON file, by adding this in the environment sec {{< /tabs >}} 4. Restart your service. -5. To see Code Security in action, browse your service and find code-level vulnerabilities in the [{{< ui >}}Vulnerability Explorer{{< /ui >}}][4]. +5. To see {{< prodname >}}Code Security{{< /prodname >}} in action, browse your service and find code-level vulnerabilities in the [{{< ui >}}Vulnerability Explorer{{< /ui >}}][4]. {{< img src="/security/application_security/Code-Level-Vulnerability-Details-New.mp4" alt="Video showing Code Vulnerabilities" video="true" >}} diff --git a/hugo/content/en/security/code_security/iast/setup/nodejs.md b/hugo/content/en/security/code_security/iast/setup/nodejs.md index 389dfed0ae4..f8d81e52a62 100644 --- a/hugo/content/en/security/code_security/iast/setup/nodejs.md +++ b/hugo/content/en/security/code_security/iast/setup/nodejs.md @@ -26,10 +26,10 @@ further_reading: You can detect code-level vulnerabilities and monitor application security in Node.js applications running in Docker, Kubernetes, Amazon ECS, and AWS Fargate. -Follow these steps to enable Code Security in your service: +Follow these steps to enable {{< prodname >}}Code Security{{< /prodname >}} in your service: 1. [Update your Datadog Agent][4] to at least version 7.41.1. -2. Update your Datadog SDK to at least the minimum version needed to turn on Code Security. For details, see [Library Compatibility][3] page. +2. Update your Datadog SDK to at least the minimum version needed to turn on {{< prodname >}}Code Security{{< /prodname >}}. For details, see [Library Compatibility][3] page. 3. Add the `DD_IAST_ENABLED=true` environment variable to your application configuration. If you initialize the Datadog SDK on the command line using the `--require` option to Node.js: @@ -96,7 +96,7 @@ Update your ECS task definition JSON file, by adding this in the environment sec {{< /tabs >}} 4. Restart your service. -5. To see Code Security in action, browse your service and the code-level vulnerabilities appear in the [{{< ui >}}Vulnerability Explorer{{< /ui >}}][5]. +5. To see {{< prodname >}}Code Security{{< /prodname >}} in action, browse your service and the code-level vulnerabilities appear in the [{{< ui >}}Vulnerability Explorer{{< /ui >}}][5]. {{< img src="/security/application_security/Code-Level-Vulnerability-Details-New.mp4" alt="Video showing Code Vulnerabilities" video="true" >}} diff --git a/hugo/content/en/security/code_security/iast/setup/python.md b/hugo/content/en/security/code_security/iast/setup/python.md index ac2c5f102d8..6d77e43066b 100644 --- a/hugo/content/en/security/code_security/iast/setup/python.md +++ b/hugo/content/en/security/code_security/iast/setup/python.md @@ -25,10 +25,10 @@ You can detect code-level vulnerabilities and monitor application security in Py NOTE: Code-Level Vulnerability detection in Python is in Preview. -Follow these steps to enable Code Security in your service: +Follow these steps to enable {{< prodname >}}Code Security{{< /prodname >}} in your service: 1. [Update your Datadog Agent][6] to at least version 7.41.1. -2. Update your Datadog SDK to at least the minimum version needed to turn on Code Security. For details, see [Library Compatibility][3] page. +2. Update your Datadog SDK to at least the minimum version needed to turn on {{< prodname >}}Code Security{{< /prodname >}}. For details, see [Library Compatibility][3] page. 3. Add the `DD_IAST_ENABLED=true` environment variable to your application configuration. From the command line: @@ -96,7 +96,7 @@ Update your ECS task definition JSON file, by adding this in the environment sec {{< /tabs >}} 4. Restart your service. -5. To see Code Security in action, browse your service and find code-level vulnerabilities in the [{{< ui >}}Vulnerability Explorer{{< /ui >}}][4]. +5. To see {{< prodname >}}Code Security{{< /prodname >}} in action, browse your service and find code-level vulnerabilities in the [{{< ui >}}Vulnerability Explorer{{< /ui >}}][4]. {{< img src="/security/application_security/Code-Level-Vulnerability-Details-New.mp4" alt="Video showing Code Vulnerabilities" video="true" >}} @@ -105,7 +105,7 @@ If you need additional assistance, contact [Datadog support][5]. ### Third-Party Library Compatibility Note -Code Security modifies Python code at runtime. This could cause conflicts with other third-party Python libraries that perform similar code transformations, particularly with the following, though not limited to them: +{{< prodname >}}Code Security{{< /prodname >}} modifies Python code at runtime. This could cause conflicts with other third-party Python libraries that perform similar code transformations, particularly with the following, though not limited to them: - Numba - JAX @@ -115,7 +115,7 @@ Code Security modifies Python code at runtime. This could cause conflicts with o - Codetransformer - PyPy -Additionally, Code Security does not correctly propagate taint ranges over native (compiled) code. Therefore, if your codebase heavily relies on modules written in C or C++, +Additionally, {{< prodname >}}Code Security{{< /prodname >}} does not correctly propagate taint ranges over native (compiled) code. Therefore, if your codebase heavily relies on modules written in C or C++, using the CPython API, or on intermediate language systems like Cython, the results might be less accurate than expected. diff --git a/hugo/content/en/security/code_security/secret_scanning/_index.md b/hugo/content/en/security/code_security/secret_scanning/_index.md index af775443083..a59d6d19875 100644 --- a/hugo/content/en/security/code_security/secret_scanning/_index.md +++ b/hugo/content/en/security/code_security/secret_scanning/_index.md @@ -41,7 +41,7 @@ When a pull request introduces a leaked secret, Datadog automatically adds inlin ### Automatically block leaks with PR Gates -Use [PR Gates][11] to prevent leaked secrets from being merged into your main branch. Datadog scans each pull request for exposed secrets and reports a pass or fail status directly to GitHub, Azure DevOps, or GitLab (in preview). +Use [{{< prodname >}}PR Gates{{< /prodname >}}][11] to prevent leaked secrets from being merged into your main branch. Datadog scans each pull request for exposed secrets and reports a pass or fail status directly to GitHub, Azure DevOps, or GitLab (in preview). By default, checks are informational, but you can make them blocking to prevent merging when secrets are detected. For setup instructions, see [Set up PR Gate Rules][12]. diff --git a/hugo/content/en/security/code_security/software_composition_analysis/_index.md b/hugo/content/en/security/code_security/software_composition_analysis/_index.md index 82c5371ad68..1f0714297e3 100644 --- a/hugo/content/en/security/code_security/software_composition_analysis/_index.md +++ b/hugo/content/en/security/code_security/software_composition_analysis/_index.md @@ -54,7 +54,7 @@ Using Software Composition Analysis provides organizations with the following be SCA supports two complementary detection modes: - **Static detection** scans repositories by analyzing dependency files (lockfiles and manifests). By default, scans run when a commit updates a supported dependency manifest or lockfile in an enabled repository. You can also run SCA in your CI/CD pipeline (CI jobs are supported for `push` events). See [Set up Static SCA][1] to get started. -- **Runtime detection** identifies libraries that are loaded and used by your services at runtime using instrumentation from Datadog APM. See [Set up Runtime SCA][2] to get started. +- **Runtime detection** identifies libraries that are loaded and used by your services at runtime using instrumentation from {{< prodname >}}Datadog APM{{< /prodname >}}. See [Set up Runtime SCA][2] to get started. When Datadog ingests a new advisory, it is matched against your last known library inventory and appears in the Vulnerabilities Explorer even if you have not rescanned the repository. The Repositories Explorer is commit-scoped and reflects what was known at the time the scan ran—so a scan that executed before Datadog ingested the advisory will not show that newly published advisory in the Repositories Explorer for that commit. See [Understanding SCA views](#understanding-sca-views) for more details. @@ -74,7 +74,7 @@ When Datadog identifies a public exploit for a vulnerability from any of these s ### Review and prioritize vulnerabilities -The [Vulnerabilities Explorer][11] provides a vulnerability-centric view of library vulnerabilities detected by SCA, alongside vulnerabilities detected by other Code Security capabilities (SAST, IAST, Secrets Scanning, and IaC). All vulnerabilities in the explorer are either detected on the default branch at the last commit of a scanned repository, or are affecting a running service. +The [Vulnerabilities Explorer][11] provides a vulnerability-centric view of library vulnerabilities detected by SCA, alongside vulnerabilities detected by other {{< prodname >}}Code Security{{< /prodname >}} capabilities (SAST, IAST, Secrets Scanning, and IaC). All vulnerabilities in the explorer are either detected on the default branch at the last commit of a scanned repository, or are affecting a running service. #### Datadog severity score @@ -107,25 +107,25 @@ Click on a library with a vulnerability to open a side panel that contains infor ### Remediation -Datadog SCA supports using coding agents and [Bits Code][31] to apply fixes for vulnerable libraries. You can also use [Bits Code Automation][32] to automatically generate fixes for vulnerabilities as they are found or on a schedule. +Datadog SCA supports using coding agents and [{{< prodname >}}Bits Code{{< /prodname >}}][31] to apply fixes for vulnerable libraries. You can also use [Bits Code Automation][32] to automatically generate fixes for vulnerabilities as they are found or on a schedule. -
SCA remediations in Bits Code require internet access to apply library upgrades. To configure internet access, see Configure internet access.
+
SCA remediations in {{< prodname >}}Bits Code{{< /prodname >}} require internet access to apply library upgrades. To configure internet access, see Configure internet access.
To view and remediate vulnerabilities: 1. In Datadog, navigate to [{{< ui >}}Security{{< /ui >}} > {{< ui >}}Code Security{{< /ui >}} > {{< ui >}}Vulnerabilities{{< /ui >}}][11], and select {{< ui >}}Libraries (SCA){{< /ui >}}. 2. Select a vulnerability to open a side panel with details about the finding and the affected library. 3. In the {{< ui >}}Next Steps{{< /ui >}} > {{< ui >}}Remediation{{< /ui >}} section, click {{< ui >}}Remediate with AI{{< /ui >}} -4. Select either Bits Code or another coding agent. With Bits Code, you can choose between: +4. Select either {{< prodname >}}Bits Code{{< /prodname >}} or another coding agent. With Bits Code, you can choose between: - [{{< ui >}}Single fix{{< /ui >}}](#single-fix): Generates a fix for this vulnerable library - If a fix has already been generated, select {{< ui >}}View fix and create PR{{< /ui >}} to view the existing [remediation session](#remediation-session-details). - [{{< ui >}}Create automation{{< /ui >}}](#create-automation): Opens a pop-up modal where you can create a [Bits Code automation][32] #### Single fix -Use **Single fix** to open a Bits Code session to fix this single vulnerability. You can review the proposed diff, ask follow-up questions, edit the patch, and create a pull request to apply the remediation to your source code repository. +Use **Single fix** to open a {{< prodname >}}Bits Code{{< /prodname >}} session to fix this single vulnerability. You can review the proposed diff, ask follow-up questions, edit the patch, and create a pull request to apply the remediation to your source code repository. -View all Bits Code sessions on {{< ui >}}Bits AI{{< /ui >}} > {{< ui >}}Bits Code{{< /ui >}} > [{{< ui >}}Sessions{{< /ui >}}][33]. +View all {{< prodname >}}Bits Code{{< /prodname >}} sessions on {{< ui >}}Bits AI{{< /ui >}} > {{< ui >}}{{< prodname >}}Bits Code{{< /prodname >}}{{< /ui >}} > [{{< ui >}}Sessions{{< /ui >}}][33]. #### Create automation @@ -133,21 +133,21 @@ Use **Create automation** to create a [Bits Code automation][32] to generate fix Selecting this option opens an {{< ui >}}Automate with Bits{{< /ui >}} modal with the {{< ui >}}Remediate SCA vulnerabilities{{< /ui >}} action pre-filled. Complete the form, including specifying a trigger and output, then click {{< ui >}}Create Automation{{< /ui >}}. See [Automations][32] to learn more about actions, triggers, and outputs. -View all Bits Code automations on {{< ui >}}Bits AI{{< /ui >}} > {{< ui >}}Bits Code{{< /ui >}} > [{{< ui >}}Automations{{< /ui >}}][34]. +View all {{< prodname >}}Bits Code{{< /prodname >}} automations on {{< ui >}}Bits AI{{< /ui >}} > {{< ui >}}{{< prodname >}}Bits Code{{< /prodname >}}{{< /ui >}} > [{{< ui >}}Automations{{< /ui >}}][34]. #### Remediation session details Each Bits Code session shows the life cycle of an AI-generated fix so you can review and validate changes before merging. It includes: - The original security finding and proposed code change -- An explanation of how and why Bits Code generated the fix +- An explanation of how and why {{< prodname >}}Bits Code{{< /prodname >}} generated the fix - CI results (if enabled) to validate the patch is safe to deploy - Options to refine the fix or {{< ui >}}Create PR{{< /ui >}} to apply the changes to your source code repository You can also view all remediation sessions on [**Sessions**][33]. #### Fix with Cursor -Instead of Bits Code, you can generate a fix with an AI coding agent such as Cursor: +Instead of {{< prodname >}}Bits Code{{< /prodname >}}, you can generate a fix with an AI coding agent such as Cursor: 1. In the {{< ui >}}Remediate with AI{{< /ui >}} dialog, select the {{< ui >}}Coding agent{{< /ui >}} tab. 2. Under {{< ui >}}Generate your fix directly from Claude Code, Codex, or Cursor{{< /ui >}}, click {{< ui >}}Open{{< /ui >}} next to {{< ui >}}Fix with Cursor{{< /ui >}}. Datadog opens Cursor with a tailored prompt that includes the recommended library upgrade for the vulnerability. @@ -162,13 +162,13 @@ To handle the Cursor deep link, install the [Datadog extension for VS Code and C ### Automatically block risky changes with PR Gates -Use [PR Gates][16] to enforce security standards for open source libraries before changes are merged. Datadog scans the dependencies introduced in each pull request, identifies vulnerabilities or license violations that exceed your configured severity threshold, and reports a pass or fail status to GitHub or Azure DevOps. +Use [{{< prodname >}}PR Gates{{< /prodname >}}][16] to enforce security standards for open source libraries before changes are merged. Datadog scans the dependencies introduced in each pull request, identifies vulnerabilities or license violations that exceed your configured severity threshold, and reports a pass or fail status to GitHub or Azure DevOps. -You can configure PR Gates to block on: +You can configure {{< prodname >}}PR Gates{{< /prodname >}} to block on: - **Security vulnerabilities**: libraries with known CVEs above a configured severity threshold. - **License violations**: libraries using licenses that do not comply with your organization's policy. -PR Gates marks a PR check as failed only if the developer introduces a new violation in that PR. Violations that already existed in the codebase before the PR branch was created do not cause the check to fail. By default, failed checks are informational and do not block merging, but you can configure them as blocking in GitHub or Azure DevOps to prevent merges when critical issues are detected. For setup instructions, see [Set up PR Gate Rules][17]. +{{< prodname >}}PR Gates{{< /prodname >}} marks a PR check as failed only if the developer introduces a new violation in that PR. Violations that already existed in the codebase before the PR branch was created do not cause the check to fail. By default, failed checks are informational and do not block merging, but you can configure them as blocking in GitHub or Azure DevOps to prevent merges when critical issues are detected. For setup instructions, see [Set up PR Gate Rules][17]. ### Manage your library inventory @@ -277,7 +277,7 @@ You can exclude paths from Static SCA analysis by configuring `ignore-paths` in 1. [Set up Static SCA][1] to scan your repositories. 2. [Set up Runtime SCA][2] to detect libraries loaded by your running services. 3. Review and triage findings in the [Vulnerabilities Explorer][11]. -4. Configure [PR Gates][16] to block risky changes before they are merged. +4. Configure [{{< prodname >}}PR Gates{{< /prodname >}}][16] to block risky changes before they are merged. 5. Use the [CVE Explorer][15] to proactively assess exposure to newly published vulnerabilities. ## Further Reading diff --git a/hugo/content/en/security/code_security/software_composition_analysis/configuration.md b/hugo/content/en/security/code_security/software_composition_analysis/configuration.md index c7edf291bed..2e57a2fcb4f 100644 --- a/hugo/content/en/security/code_security/software_composition_analysis/configuration.md +++ b/hugo/content/en/security/code_security/software_composition_analysis/configuration.md @@ -10,7 +10,7 @@ further_reading: text: Code Security Configuration Reference --- -Datadog Software Composition Analysis (SCA) detects open source libraries and their vulnerabilities in your code. You can exclude specific paths from Static SCA analysis. Configure this setting under the `sca` key in the Code Security configuration, either in Datadog or in a `code-security.datadog.yaml` file. +Datadog Software Composition Analysis (SCA) detects open source libraries and their vulnerabilities in your code. You can exclude specific paths from Static SCA analysis. Configure this setting under the `sca` key in the {{< prodname >}}Code Security{{< /prodname >}} configuration, either in Datadog or in a `code-security.datadog.yaml` file. The `sca` key requires `schema-version: v1.1` and supports the following field: diff --git a/hugo/content/en/security/code_security/software_composition_analysis/setup_runtime/_index.md b/hugo/content/en/security/code_security/software_composition_analysis/setup_runtime/_index.md index 76640456d87..00c2b14fdfd 100644 --- a/hugo/content/en/security/code_security/software_composition_analysis/setup_runtime/_index.md +++ b/hugo/content/en/security/code_security/software_composition_analysis/setup_runtime/_index.md @@ -10,7 +10,7 @@ SCA can detect vulnerabilities that affect open source libraries running in your Before setting up runtime detection, ensure the following prerequisites are met: 1. **Datadog Agent Installation:** The Datadog Agent is installed and configured for your application's operating system or container, cloud, or virtual environment. -2. **Datadog APM Configuration:** Datadog APM is configured for your application or service, and web traces (`type:web`) are being received by Datadog. +2. **Datadog APM Configuration:** {{< prodname >}}Datadog APM{{< /prodname >}} is configured for your application or service, and web traces (`type:web`) are being received by Datadog. 3. **Supported SDK:** The Datadog SDK used by your application or service supports Software Composition Analysis capabilities for the language of your application or service. For more details, refer to the [Library Compatibility][2] page. ## Software Composition Analysis enablement types diff --git a/hugo/content/en/security/code_security/software_composition_analysis/setup_runtime/compatibility/_index.md b/hugo/content/en/security/code_security/software_composition_analysis/setup_runtime/compatibility/_index.md index 2afd3922579..ece4248c380 100644 --- a/hugo/content/en/security/code_security/software_composition_analysis/setup_runtime/compatibility/_index.md +++ b/hugo/content/en/security/code_security/software_composition_analysis/setup_runtime/compatibility/_index.md @@ -11,7 +11,7 @@ The following capabilities are supported relative to each language's SDK: |------------------------------------------------|---------|----------|--------------------------------------------------|---------------|-----------------|---------------|---------------| | Runtime Software Composition Analysis (SCA) | 1.1.4 | 2.16.0 | 4.0.0 | 1.5.0 | 1.49.0 | 1.11.0 | 0.90.0 | -**Note**: **Static Software Composition Analysis (SCA)** and **Static Code Analysis (SAST)** capabilities do not require the Datadog SDK. Therefore, the requirements listed below do not apply to these two Code Security capabilities. +**Note**: **Static Software Composition Analysis (SCA)** and **Static Code Analysis (SAST)** capabilities do not require the Datadog SDK. Therefore, the requirements listed below do not apply to these two {{< prodname >}}Code Security{{< /prodname >}} capabilities. Select your application language for details about framework compatibility and feature support. diff --git a/hugo/content/en/security/code_security/software_composition_analysis/setup_runtime/compatibility/dotnet.md b/hugo/content/en/security/code_security/software_composition_analysis/setup_runtime/compatibility/dotnet.md index 7d7ec3867af..ba88174e798 100644 --- a/hugo/content/en/security/code_security/software_composition_analysis/setup_runtime/compatibility/dotnet.md +++ b/hugo/content/en/security/code_security/software_composition_analysis/setup_runtime/compatibility/dotnet.md @@ -26,7 +26,7 @@ The minimum tracer version to get all supported application security capabilitie | AWS Lambda | | | | Azure App Service | {{< X >}} | {{< X >}} | -**Note**: Azure App Service is supported for **web applications only**. Code Security capabilities are not supported for Azure Functions. +**Note**: Azure App Service is supported for **web applications only**. {{< prodname >}}Code Security{{< /prodname >}} capabilities are not supported for Azure Functions. ## Language and framework compatibility diff --git a/hugo/content/en/security/code_security/software_composition_analysis/setup_runtime/compatibility/go.md b/hugo/content/en/security/code_security/software_composition_analysis/setup_runtime/compatibility/go.md index 19d202892af..4f91f2c694f 100644 --- a/hugo/content/en/security/code_security/software_composition_analysis/setup_runtime/compatibility/go.md +++ b/hugo/content/en/security/code_security/software_composition_analysis/setup_runtime/compatibility/go.md @@ -39,7 +39,7 @@ Starting from tracer version 1.53.0, code security capabilities do not require [ The Go tracer includes support for the following frameworks, data stores and libraries. -The Go packages listed in this page are relevant for Code Security capabilities. You can also find more tracing integrations in [APM's tracing compatibility page][16]. +The Go packages listed in this page are relevant for {{< prodname >}}Code Security{{< /prodname >}} capabilities. You can also find more tracing integrations in [APM's tracing compatibility page][16]. **Note**: The [Go integrations documentation][19] provides a detailed overview of the supported packages and their APIs, along with usage examples. diff --git a/hugo/content/en/security/code_security/software_composition_analysis/setup_runtime/compatibility/java.md b/hugo/content/en/security/code_security/software_composition_analysis/setup_runtime/compatibility/java.md index af3511cf91c..fe248ae00f1 100644 --- a/hugo/content/en/security/code_security/software_composition_analysis/setup_runtime/compatibility/java.md +++ b/hugo/content/en/security/code_security/software_composition_analysis/setup_runtime/compatibility/java.md @@ -16,7 +16,7 @@ The following code security capabilities are supported in the Java library, for The minimum tracer version to get all supported code security capabilities for Java is 1.15.0. -**Note**: **Static Software Composition Analysis (SCA)** and **Static Code Analysis (SAST)** capabilities do not require the Datadog SDK. Therefore, the requirements listd above do not apply to these two Code Security capabilities. +**Note**: **Static Software Composition Analysis (SCA)** and **Static Code Analysis (SAST)** capabilities do not require the Datadog SDK. Therefore, the requirements listd above do not apply to these two {{< prodname >}}Code Security{{< /prodname >}} capabilities. ### Supported deployment types | Type | Runtime Software Composition Analysis (SCA) | Runtime Code Analysis (IAST) | @@ -28,7 +28,7 @@ The minimum tracer version to get all supported code security capabilities for J | AWS Lambda | not supported | not supported | | Azure App Service | {{< X >}} | {{< X >}} | -**Note**: Azure App Service is supported for **web applications only**. Code Security doesn't support Azure Functions. +**Note**: Azure App Service is supported for **web applications only**. {{< prodname >}}Code Security{{< /prodname >}} doesn't support Azure Functions. ## Language and framework compatibility diff --git a/hugo/content/en/security/code_security/software_composition_analysis/setup_runtime/compatibility/php.md b/hugo/content/en/security/code_security/software_composition_analysis/setup_runtime/compatibility/php.md index 2631f12dad6..73ad095487f 100644 --- a/hugo/content/en/security/code_security/software_composition_analysis/setup_runtime/compatibility/php.md +++ b/hugo/content/en/security/code_security/software_composition_analysis/setup_runtime/compatibility/php.md @@ -44,7 +44,7 @@ It's recommended to use officia | 7.1.x | General Availability | All | | 7.0.x | General Availability | All | -Code Security capabililties for PHP support the following SAPI's: +{{< prodname >}}Code Security{{< /prodname >}} capabililties for PHP support the following SAPI's: | SAPI | Support type | |:---------------|:----------------| @@ -55,7 +55,7 @@ Code Security capabililties for PHP support the following SAPI's: ## Supported processor architectures -Code Security capabililties for PHP support the following architectures: +{{< prodname >}}Code Security{{< /prodname >}} capabililties for PHP support the following architectures: | Processor architectures | Support level | Package version | | ------------------------------------------|-----------------------|----------------------------------------| diff --git a/hugo/content/en/security/code_security/software_composition_analysis/setup_static/_index.md b/hugo/content/en/security/code_security/software_composition_analysis/setup_static/_index.md index 50fb59744e2..340d4bf32ab 100644 --- a/hugo/content/en/security/code_security/software_composition_analysis/setup_static/_index.md +++ b/hugo/content/en/security/code_security/software_composition_analysis/setup_static/_index.md @@ -82,7 +82,7 @@ For these cases, scan using CI pipelines. Datadog Software Composition Analysis runs in your CI pipelines using the [`datadog-ci` CLI][8].
-You must scan your default branch at least once before results appear in {{< ui >}}Code Security{{< /ui >}}. +You must scan your default branch at least once before results appear in {{< ui >}}{{< prodname >}}Code Security{{< /prodname >}}{{< /ui >}}.
{{< whatsnext desc="See instructions based on your CI provider:">}} diff --git a/hugo/content/en/security/code_security/static_analysis/_index.md b/hugo/content/en/security/code_security/static_analysis/_index.md index 5d9d9d7ac14..8920a80d042 100644 --- a/hugo/content/en/security/code_security/static_analysis/_index.md +++ b/hugo/content/en/security/code_security/static_analysis/_index.md @@ -23,7 +23,7 @@ further_reading: {{% site-region region="gov,gov2" %}}
- Code Security is not available for the {{< region-param key="dd_site_name" >}} site. + {{< prodname >}}Code Security{{< /prodname >}} is not available for the {{< region-param key="dd_site_name" >}} site.
{{% /site-region %}} @@ -129,7 +129,7 @@ If GitHub is your source code manager, you can push a code change to fix a SAST If your GitHub app's {{< ui >}}Pull Requests{{< /ui >}} permission is set to {{< ui >}}Read & Write{{< /ui >}}, one-click remediation is enabled for all Static Code Analysis findings with an available suggested fix. Follow these steps to fix a vulnerability and open a pull request: -1. View a specific SAST result in Code Security. +1. View a specific SAST result in {{< prodname >}}Code Security{{< /prodname >}}. 2. Click {{< ui >}}Fix Violation{{< /ui >}} in the side panel of the result. 3. Select {{< ui >}}Open a Pull Request{{< /ui >}}. 4. Enter a pull request title and commit message. @@ -140,14 +140,14 @@ You can also fix a vulnerability by committing directly to the branch the result To commit a suggested fix: -1. View a specific SAST result in Code Security. +1. View a specific SAST result in {{< prodname >}}Code Security{{< /prodname >}}. 2. Click {{< ui >}}Fix Violation{{< /ui >}} in the side panel of the result. 3. Click {{< ui >}}Commit to current branch{{< /ui >}}. ### Fix with Cursor You can hand off remediation for a SAST finding to an AI coding agent such as Cursor. -1. View a specific SAST result in Code Security. +1. View a specific SAST result in {{< prodname >}}Code Security{{< /prodname >}}. 2. In the side panel's {{< ui >}}Next Steps{{< /ui >}} > {{< ui >}}Remediation{{< /ui >}} section, click {{< ui >}}Remediate with AI{{< /ui >}}. 3. Select the {{< ui >}}Coding agent{{< /ui >}} tab. 4. Under {{< ui >}}Generate your fix directly from Claude Code, Codex, or Cursor{{< /ui >}}, click {{< ui >}}Open{{< /ui >}} next to {{< ui >}}Fix with Cursor{{< /ui >}}. Datadog opens Cursor with a tailored remediation prompt for the finding. Review the suggested changes before you commit them. diff --git a/hugo/content/en/security/code_security/static_analysis/ai_enhanced_sast.md b/hugo/content/en/security/code_security/static_analysis/ai_enhanced_sast.md index fde1543a446..16ab3aaeaed 100644 --- a/hugo/content/en/security/code_security/static_analysis/ai_enhanced_sast.md +++ b/hugo/content/en/security/code_security/static_analysis/ai_enhanced_sast.md @@ -165,7 +165,7 @@ The additional repository context helps Bits AI distinguish true positives from ## Remediation -Datadog SAST uses [Bits Code][10] to generate code fixes for vulnerabilities. You can also create an [automation][13] to automatically generate fixes for vulnerabilities as they are found or on a schedule. +Datadog SAST uses [{{< prodname >}}Bits Code{{< /prodname >}}][10] to generate code fixes for vulnerabilities. You can also create an [automation][13] to automatically generate fixes for vulnerabilities as they are found or on a schedule. To view and remediate vulnerabilities: @@ -178,9 +178,9 @@ To view and remediate vulnerabilities: ### Single fix -Use **Single fix** to open a Bits Code session to fix this single vulnerability. You can review the proposed diff, ask follow-up questions, edit the patch, and create a pull request to apply the remediation to your source code repository. +Use **Single fix** to open a {{< prodname >}}Bits Code{{< /prodname >}} session to fix this single vulnerability. You can review the proposed diff, ask follow-up questions, edit the patch, and create a pull request to apply the remediation to your source code repository. -View all Bits Code sessions on {{< ui >}}Bits AI{{< /ui >}} > {{< ui >}}Bits Code{{< /ui >}} > [{{< ui >}}Sessions{{< /ui >}}][7]. +View all {{< prodname >}}Bits Code{{< /prodname >}} sessions on {{< ui >}}Bits AI{{< /ui >}} > {{< ui >}}{{< prodname >}}Bits Code{{< /prodname >}}{{< /ui >}} > [{{< ui >}}Sessions{{< /ui >}}][7]. ### Create automation @@ -188,14 +188,14 @@ Use **Create automation** to create a [Bits Code automation][13] to generate fix Selecting this option opens an {{< ui >}}Automate with Bits{{< /ui >}} modal with the {{< ui >}}Remediate SAST vulnerabilities{{< /ui >}} action pre-filled. Complete the form, including specifying a trigger and output, then click {{< ui >}}Create Automation{{< /ui >}}. See [Automations][13] to learn more about actions, triggers, and outputs. -View all Bits Code automations on {{< ui >}}Bits AI{{< /ui >}} > {{< ui >}}Bits Code{{< /ui >}} > [{{< ui >}}Automations{{< /ui >}}][14]. +View all {{< prodname >}}Bits Code{{< /prodname >}} automations on {{< ui >}}Bits AI{{< /ui >}} > {{< ui >}}{{< prodname >}}Bits Code{{< /prodname >}}{{< /ui >}} > [{{< ui >}}Automations{{< /ui >}}][14]. ### Remediation session details Each Bits Code session shows the life cycle of an AI-generated fix so you can review and validate changes before merging. It includes: - The original security finding and proposed code change -- An explanation of how and why Bits Code generated the fix +- An explanation of how and why {{< prodname >}}Bits Code{{< /prodname >}} generated the fix - CI results (if enabled) to validate the patch is safe to deploy - Options to refine the fix or {{< ui >}}Create PR{{< /ui >}} to apply the changes to your source code repository diff --git a/hugo/content/en/security/code_security/static_analysis/configuration.md b/hugo/content/en/security/code_security/static_analysis/configuration.md index b52d59616fb..09de434dcdf 100644 --- a/hugo/content/en/security/code_security/static_analysis/configuration.md +++ b/hugo/content/en/security/code_security/static_analysis/configuration.md @@ -3,7 +3,7 @@ title: Static Code Analysis (SAST) Configuration description: Reference documentation for Datadog Static Code Analysis (SAST) configuration, covering ruleset selection, rule customization, severities, and paths. --- -By default, Datadog Static Code Analysis (SAST) scans your repositories with [Datadog's default rulesets][6] for each programming language. You can customize which rulesets and rules run, along with severities, paths, and other parameters. Configure these settings under the `sast` key in the Code Security configuration, either in Datadog or in a `code-security.datadog.yaml` file. +By default, Datadog Static Code Analysis (SAST) scans your repositories with [Datadog's default rulesets][6] for each programming language. You can customize which rulesets and rules run, along with severities, paths, and other parameters. Configure these settings under the `sast` key in the {{< prodname >}}Code Security{{< /prodname >}} configuration, either in Datadog or in a `code-security.datadog.yaml` file. For information on configuration locations, precedence, and merging, see [Code Security Configuration Reference][26]. diff --git a/hugo/content/en/security/code_security/static_analysis/custom_rules/_index.md b/hugo/content/en/security/code_security/static_analysis/custom_rules/_index.md index 19f855c152d..0dbf3350ffb 100644 --- a/hugo/content/en/security/code_security/static_analysis/custom_rules/_index.md +++ b/hugo/content/en/security/code_security/static_analysis/custom_rules/_index.md @@ -8,7 +8,7 @@ algolia: {{% site-region region="gov,gov2" %}}
- Code Security is not available for the {{< region-param key="dd_site_name" >}} site. + {{< prodname >}}Code Security{{< /prodname >}} is not available for the {{< region-param key="dd_site_name" >}} site.
{{% /site-region %}} @@ -183,7 +183,7 @@ The analyzer includes a few helper functions to help you write rules: ### Rule examples -All Datadog default rules are available in [Code Security][4]. You can easily analyze and copy them to create your own custom rules. +All Datadog default rules are available in [{{< prodname >}}Code Security{{< /prodname >}}][4]. You can easily analyze and copy them to create your own custom rules. [1]: https://app.datadoghq.com/ci/code-analysis diff --git a/hugo/content/en/security/code_security/static_analysis/setup/_index.md b/hugo/content/en/security/code_security/static_analysis/setup/_index.md index 6292833ae2c..99958d15a8e 100644 --- a/hugo/content/en/security/code_security/static_analysis/setup/_index.md +++ b/hugo/content/en/security/code_security/static_analysis/setup/_index.md @@ -13,7 +13,7 @@ algolia: {{% site-region region="gov,gov2" %}}
- Code Security is not available for the {{< region-param key="dd_site_name" >}} site. + {{< prodname >}}Code Security{{< /prodname >}} is not available for the {{< region-param key="dd_site_name" >}} site.
{{% /site-region %}} @@ -85,7 +85,7 @@ See the [Azure source code setup instructions][4] to connect Azure DevOps reposi {{% tab "Other" %}} If you are using another source code management provider, configure Static Code Analysis to run in your CI pipelines using the `datadog-ci` CLI tool and [upload the results](#upload-third-party-static-analysis-results-to-datadog) to Datadog. -You **must** run an analysis of your repository on the default branch before results can begin appearing on the {{< ui >}}Code Security{{< /ui >}} page. +You **must** run an analysis of your repository on the default branch before results can begin appearing on the {{< ui >}}{{< prodname >}}Code Security{{< /prodname >}}{{< /ui >}} page. {{% /tab %}} {{< /tabs >}} diff --git a/hugo/content/en/security/code_security/static_analysis/setup/generic_ci_providers.md b/hugo/content/en/security/code_security/static_analysis/setup/generic_ci_providers.md index 5931375d552..44a9dd1f153 100644 --- a/hugo/content/en/security/code_security/static_analysis/setup/generic_ci_providers.md +++ b/hugo/content/en/security/code_security/static_analysis/setup/generic_ci_providers.md @@ -22,7 +22,7 @@ algolia: If you don't use GitHub Actions, you can run the [datadog-ci][4] CLI directly in your CI pipeline platform and upload SARIF results to Datadog. -**If you are running Code Security on a non-GitHub repository**, ensure that the first scan is ran on your default branch. If your default branch is not one of `master`, `main`, `default`, `stable`, `source`, `prod`, or `develop`, you must attempt a SARIF upload for your repository and then manually override the default branch in-app under [{{< ui >}}Repository Settings{{< /ui >}}][5]. Afterwards, uploads from your non-default branches will succeed. +**If you are running {{< prodname >}}Code Security{{< /prodname >}} on a non-GitHub repository**, ensure that the first scan is ran on your default branch. If your default branch is not one of `master`, `main`, `default`, `stable`, `source`, `prod`, or `develop`, you must attempt a SARIF upload for your repository and then manually override the default branch in-app under [{{< ui >}}Repository Settings{{< /ui >}}][5]. Afterwards, uploads from your non-default branches will succeed. Prerequisites: diff --git a/hugo/content/en/security/code_security/static_analysis/static_analysis_rules/_index.md b/hugo/content/en/security/code_security/static_analysis/static_analysis_rules/_index.md index 385930e6ca6..309efddd58b 100644 --- a/hugo/content/en/security/code_security/static_analysis/static_analysis_rules/_index.md +++ b/hugo/content/en/security/code_security/static_analysis/static_analysis_rules/_index.md @@ -283,7 +283,7 @@ further_reading: {{% site-region region="gov,gov2" %}}
- Code Security is not available for the {{< region-param key="dd_site_name" >}} site. + {{< prodname >}}Code Security{{< /prodname >}} is not available for the {{< region-param key="dd_site_name" >}} site.
{{% /site-region %}} diff --git a/hugo/content/en/security/code_security/troubleshooting/_index.md b/hugo/content/en/security/code_security/troubleshooting/_index.md index 9a3c0f0b4e1..47990495d6d 100644 --- a/hugo/content/en/security/code_security/troubleshooting/_index.md +++ b/hugo/content/en/security/code_security/troubleshooting/_index.md @@ -110,7 +110,7 @@ After updating either file on your default branch, it may take up to six hours f ### Results are not being surfaced in the Datadog UI -**If you are running Code Security on a non-GitHub repository**, ensure that the first scan is ran on your default branch. If your default branch is not one of `master`, `main`, `default`, `stable`, `source`, `prod`, or `develop`, you must attempt a SARIF upload for your repository and then manually override the default branch in-app under [{{< ui >}}Repository Settings{{< /ui >}}][4]. Afterwards, uploads from your non-default branches will succeed. +**If you are running {{< prodname >}}Code Security{{< /prodname >}} on a non-GitHub repository**, ensure that the first scan is ran on your default branch. If your default branch is not one of `master`, `main`, `default`, `stable`, `source`, `prod`, or `develop`, you must attempt a SARIF upload for your repository and then manually override the default branch in-app under [{{< ui >}}Repository Settings{{< /ui >}}][4]. Afterwards, uploads from your non-default branches will succeed. If you are using Datadog’s analyzer, [diff-aware scanning][21] is enabled by default. If you are running the tool within your CI pipeline, make sure that `datadog-ci` runs **at the root** of the repository being analyzed. @@ -244,7 +244,7 @@ After updating either file on your default branch, it may take up to six hours f ### Results are not being surfaced in the Datadog UI -**If you are running Code Security on a non-GitHub repository**, ensure that the first scan is ran on your default branch. If your default branch is not one of `master`, `main`, `default`, `stable`, `source`, `prod`, or `develop`, you must attempt an SBOM upload for your repository and then manually override the default branch in-app under [{{< ui >}}Repository Settings{{< /ui >}}][4]. Afterwards, uploads from your non-default branches will succeed. +**If you are running {{< prodname >}}Code Security{{< /prodname >}} on a non-GitHub repository**, ensure that the first scan is ran on your default branch. If your default branch is not one of `master`, `main`, `default`, `stable`, `source`, `prod`, or `develop`, you must attempt an SBOM upload for your repository and then manually override the default branch in-app under [{{< ui >}}Repository Settings{{< /ui >}}][4]. Afterwards, uploads from your non-default branches will succeed. ### No package detected for C# projects @@ -300,7 +300,7 @@ Ensure the `DD_INSTRUMENTATION_TELEMETRY_ENABLED` environment variable (`DD_TRAC ### Bits Code remediation fails or produces incomplete fixes -Bits Code requires internet access to apply library upgrades when remediating SCA findings. If Bits Code fails to generate a fix or produces an incomplete patch, confirm that your internet access policy allows Bits Code to reach the package registries required for your language (for example, `registry.npmjs.org` for JavaScript or `pypi.org` for Python). See [Configure internet access][30] for more information. +{{< prodname >}}Bits Code{{< /prodname >}} requires internet access to apply library upgrades when remediating SCA findings. If Bits Code fails to generate a fix or produces an incomplete patch, confirm that your internet access policy allows {{< prodname >}}Bits Code{{< /prodname >}} to reach the package registries required for your language (for example, `registry.npmjs.org` for JavaScript or `pypi.org` for Python). See [Configure internet access][30] for more information. ## Runtime Code Analysis (IAST) @@ -323,7 +323,7 @@ If you're running a Flask application, ensure that you are calling the `ddtrace_ ## How committers are calculated for Code Security A **committer** is an active Git contributor identified by the `author_email` field in Git commit metadata. -A committer is counted toward billing if they make **at least three commits in a calendar month** in repositories where Code Security is enabled. +A committer is counted toward billing if they make **at least three commits in a calendar month** in repositories where {{< prodname >}}Code Security{{< /prodname >}} is enabled. Multiple commits with the same `author_email` count as one committer. By default, commits with different email addresses count separately. For GitHub repositories that meet the requirements in [Deduplicating committers across email addresses](#deduplicating-committers-across-email-addresses), multiple emails belonging to the same GitHub user are counted as one committer. @@ -348,7 +348,7 @@ If your committer count looks higher than expected for GitHub repositories, chec ## Disabling Code Security capabilities ### Disabling static repository scanning To disable scanning Static Code Analysis (SAST) or static Software Composition Analysis: -- If you are scanning your repositories through Datadog-hosted scanning, navigate to Code Security [{{< ui >}}Setup{{< /ui >}}][17], click {{< ui >}}Enable scanning for your repositories{{< /ui >}}, and disable the toggles previously enabled for scanning either all connected repositories or each repository. +- If you are scanning your repositories through Datadog-hosted scanning, navigate to {{< prodname >}}Code Security{{< /prodname >}} [{{< ui >}}Setup{{< /ui >}}][17], click {{< ui >}}Enable scanning for your repositories{{< /ui >}}, and disable the toggles previously enabled for scanning either all connected repositories or each repository. - If you are scanning source code repositories through your CI pipelines, remove the relevant job(s) from your CI pipelines. ### Disabling runtime SCA on your services diff --git a/hugo/content/en/security/default_rules/_index.md b/hugo/content/en/security/default_rules/_index.md index f7bff46ad13..28cb9f84da5 100644 --- a/hugo/content/en/security/default_rules/_index.md +++ b/hugo/content/en/security/default_rules/_index.md @@ -35,16 +35,16 @@ cascade: subcategory: Security Detection Rules --- -Datadog provides out-of-the-box (OOTB) [detection rules][1] to flag attacker techniques and potential misconfigurations so you can immediately take steps to remediate. Datadog continuously develops new default rules, which are automatically imported into your account, your App and API Protection library, and the Agent, depending on your configuration. +Datadog provides out-of-the-box (OOTB) [detection rules][1] to flag attacker techniques and potential misconfigurations so you can immediately take steps to remediate. Datadog continuously develops new default rules, which are automatically imported into your account, your {{< prodname >}}App and API Protection{{< /prodname >}} library, and the Agent, depending on your configuration.
Datadog's Security Research team continuously adds new OOTB security detection rules. While the aim is to deliver high-quality detections with the release of integrations or other new features, the performance of these detections at scale often needs to be observed before making the rule generally available. These rules contain a Beta tag. This gives Datadog's Security Research team time to either refine or deprecate detection opportunities that do not meet Datadog's standards.
Click the following buttons to filter the detection rules. Security detection rules are available for: -- [App and API Protection][5] -- [Cloud SIEM][2] (log detection and signal correlation) +- [{{< prodname >}}App and API Protection{{< /prodname >}}][5] +- [{{< prodname >}}Cloud SIEM{{< /prodname >}}][2] (log detection and signal correlation) - [Cloud Security Misconfigurations][3] (cloud and infrastructure) {{% cloud-sec-cloud-infra %}} -- [Workload Protection][4] +- [{{< prodname >}}Workload Protection{{< /prodname >}}][4] - [Cloud Security Identity Risks][6] - [Attack Paths][7] diff --git a/hugo/content/en/security/detection_rules/_index.md b/hugo/content/en/security/detection_rules/_index.md index b679aa4fd3b..b6d8134c8a8 100644 --- a/hugo/content/en/security/detection_rules/_index.md +++ b/hugo/content/en/security/detection_rules/_index.md @@ -39,20 +39,20 @@ Detection rules define conditional logic that is applied to all ingested logs an ## Out-of-the-box detection rules -Datadog provides [out-of-the-box detection rules][2] to flag attacker techniques and potential misconfigurations. When new detection rules are released, they are automatically imported into your account, your App and API Protection library, and the Agent, depending on your configuration. +Datadog provides [out-of-the-box detection rules][2] to flag attacker techniques and potential misconfigurations. When new detection rules are released, they are automatically imported into your account, your {{< prodname >}}App and API Protection{{< /prodname >}} library, and the Agent, depending on your configuration. Out-of-the box rules are available for the following security products: -- [Cloud SIEM][3] uses log detection to analyze ingested logs in real-time. +- [{{< prodname >}}Cloud SIEM{{< /prodname >}}][3] uses log detection to analyze ingested logs in real-time. - Cloud Security: - [Cloud Security Misconfigurations][4] uses cloud configuration and infrastructure configuration detection rules to scan the state of your cloud environment. - [Cloud Security Identity Risks][6] uses detection rules to detect IAM-based risks in your cloud infrastructure. -- [Workload Protection][5] uses the Datadog Agent and detection rules to actively monitor and evaluate system activity. -- [App and API Protection][7] (AAP) leverages Datadog [APM][8], the [Datadog Agent][9], and detection rules to detect threats in your application environment. +- [{{< prodname >}}Workload Protection{{< /prodname >}}][5] uses the Datadog Agent and detection rules to actively monitor and evaluate system activity. +- [{{< prodname >}}App and API Protection{{< /prodname >}}][7] (AAP) leverages Datadog [APM][8], the [Datadog Agent][9], and detection rules to detect threats in your application environment. ## MITRE ATT&CK map -{{< product-availability names="Cloud SIEM,App and API Protection,Workload Protection" >}} +{{< product-availability names="{{< prodname >}}Cloud SIEM{{< /prodname >}},{{< prodname >}}App and API Protection{{< /prodname >}},{{< prodname >}}Workload Protection{{< /prodname >}}" >}} MITRE ATT&CK is a framework that helps organizations understand how cyber attackers operate. It maps the following: @@ -63,14 +63,14 @@ By mapping tactics and techniques, MITRE ATT&CK provides security teams with a c To use the MITRE ATT&CK map, do the following: -1. Open Detection Rules in [SIEM][16] or [Workload Protection][17]. +1. Open Detection Rules in [SIEM][16] or [{{< prodname >}}Workload Protection{{< /prodname >}}][17]. 2. Select {{< ui >}}MITRE ATT&CK map{{< /ui >}}. 3. Select one of more products in the filter . 4. Review the map for the following: - Assessing Coverage: Determine which attack techniques are well-covered and which are under-monitored. - Prioritizing Rule Creation: Focus on creating detection rules for techniques with low or no coverage. - Streamlining Rule Management: Manage and update detection rules, ensuring they align with the latest threat intelligence. -The MITRE ATT&CK map available in SIEM or Workload Protection, but you can select Application and API Protection in the filter. Application and API Protection is included in the MITRE ATT&CK map for all-inclusive security coverage. +The MITRE ATT&CK map available in SIEM or {{< prodname >}}Workload Protection{{< /prodname >}}, but you can select Application and API Protection in the filter. Application and API Protection is included in the MITRE ATT&CK map for all-inclusive security coverage. ## Beta detection rules @@ -84,7 +84,7 @@ To [create custom rules](#create-detection-rules), you can clone the default rul ## Search and filter detection rules -To view out-of-the-box and custom detection rules in Datadog, navigate to the [{{< ui >}}Security Settings{{< /ui >}}][10] page. Rules are listed on separate pages for each product (App and API Protection, Cloud Security, and Cloud SIEM). +To view out-of-the-box and custom detection rules in Datadog, navigate to the [{{< ui >}}Security Settings{{< /ui >}}][10] page. Rules are listed on separate pages for each product ({{< prodname >}}App and API Protection{{< /prodname >}}, {{< prodname >}}Cloud Security{{< /prodname >}}, and {{< prodname >}}Cloud SIEM{{< /prodname >}}). To search and filter the rules, use the search box and facets to query by value. For example, to only show rules for a given rule type, hover over the rule type and select `only`. You can also filter by facets such as `source` and `severity` when investigating and triaging incoming issues. @@ -96,14 +96,14 @@ To create a custom detection rule, click the {{< ui >}}New Rule{{< /ui >}} butto For detailed instructions, see the following articles: -- [Cloud SIEM][11] +- [{{< prodname >}}Cloud SIEM{{< /prodname >}}][11] - [AAP][12] - [Cloud Security Misconfigurations][13] -- [Workload Protection][14] +- [{{< prodname >}}Workload Protection{{< /prodname >}}][14] ## Manage detection rules -You can manage detection rules from both the [SIEM][16] or [Workload Protection][17] pages in Datadog. These instructions describe how to perform these actions from those pages, but these options are also available when you click on a detection rule to open it in a side panel. +You can manage detection rules from both the [SIEM][16] or [{{< prodname >}}Workload Protection{{< /prodname >}}][17] pages in Datadog. These instructions describe how to perform these actions from those pages, but these options are also available when you click on a detection rule to open it in a side panel. ### Enable or disable rules @@ -150,9 +150,9 @@ Use Rule Version History to: To see the version history of a rule: 1. Navigate to the [Security Settings][15] page. In the left navigation panel: - - For AAP: Click {{< ui >}}App and API Protection{{< /ui >}} and then click {{< ui >}}Detection Rules{{< /ui >}}. - - For Cloud Security: Click {{< ui >}}Cloud Security{{< /ui >}} and then click {{< ui >}}Threat Detection Rules{{< /ui >}}. - - For Cloud SIEM: Click {{< ui >}}Cloud SIEM{{< /ui >}} and then click {{< ui >}}Detection Rules{{< /ui >}}. + - For AAP: Click {{< ui >}}{{< prodname >}}App and API Protection{{< /prodname >}}{{< /ui >}} and then click {{< ui >}}Detection Rules{{< /ui >}}. + - For Cloud Security: Click {{< ui >}}{{< prodname >}}Cloud Security{{< /prodname >}}{{< /ui >}} and then click {{< ui >}}Threat Detection Rules{{< /ui >}}. + - For Cloud SIEM: Click {{< ui >}}{{< prodname >}}Cloud SIEM{{< /prodname >}}{{< /ui >}} and then click {{< ui >}}Detection Rules{{< /ui >}}. 1. Click on the rule you are interested in, then click {{< ui >}}Edit rule{{< /ui >}}. 1. In the rule editor, click {{< ui >}}Version History{{< /ui >}} to see past changes: - Click a specific version to see what changes were made. diff --git a/hugo/content/en/security/guide/_index.md b/hugo/content/en/security/guide/_index.md index 9bacb278982..686c2c5d7a0 100644 --- a/hugo/content/en/security/guide/_index.md +++ b/hugo/content/en/security/guide/_index.md @@ -15,13 +15,13 @@ disable_toc: true {{< /whatsnext >}} {{< whatsnext desc="Cloud SIEM Guides:" >}} - {{< nextlink href="/getting_started/cloud_siem" >}}Getting Started with Cloud SIEM{{< /nextlink >}} - {{< nextlink href="/security/cloud_siem/guide/automate-the-remediation-of-detected-threats" >}}Automate the remediation of detected threats with Cloud SIEM{{< /nextlink >}} - {{< nextlink href="/security/cloud_siem/guide/aws-config-guide-for-cloud-siem" >}}AWS Configuration Guide for Cloud SIEM{{< /nextlink >}} - {{< nextlink href="/security/cloud_siem/guide/google-cloud-config-guide-for-cloud-siem/" >}}Google Cloud Configuration Guide for Cloud SIEM{{< /nextlink >}} - {{< nextlink href="/security/cloud_siem/guide/azure-config-guide-for-cloud-siem/" >}}Azure Configuration Guide for Cloud SIEM{{< /nextlink >}} + {{< nextlink href="/getting_started/cloud_siem" >}}Getting Started with {{< prodname >}}Cloud SIEM{{< /prodname >}}{{< /nextlink >}} + {{< nextlink href="/security/cloud_siem/guide/automate-the-remediation-of-detected-threats" >}}Automate the remediation of detected threats with {{< prodname >}}Cloud SIEM{{< /prodname >}}{{< /nextlink >}} + {{< nextlink href="/security/cloud_siem/guide/aws-config-guide-for-cloud-siem" >}}AWS Configuration Guide for {{< prodname >}}Cloud SIEM{{< /prodname >}}{{< /nextlink >}} + {{< nextlink href="/security/cloud_siem/guide/google-cloud-config-guide-for-cloud-siem/" >}}Google Cloud Configuration Guide for {{< prodname >}}Cloud SIEM{{< /prodname >}}{{< /nextlink >}} + {{< nextlink href="/security/cloud_siem/guide/azure-config-guide-for-cloud-siem/" >}}Azure Configuration Guide for {{< prodname >}}Cloud SIEM{{< /prodname >}}{{< /nextlink >}} {{< nextlink href="security/cloud_siem/guide/monitor-authentication-logs-for-security-threats" >}}Monitor Authentication Logs for Security Threats{{< /nextlink >}} - {{< nextlink href="/security/cloud_siem/guide/customize-which-logs-cloud-siem-analyzes/" >}}Customize which logs Cloud SIEM analyzes{{< /nextlink >}} + {{< nextlink href="/security/cloud_siem/guide/customize-which-logs-cloud-siem-analyzes/" >}}Customize which logs {{< prodname >}}Cloud SIEM{{< /prodname >}} analyzes{{< /nextlink >}} {{< /whatsnext >}} {{< whatsnext desc="Code Security Guides:" >}} @@ -29,7 +29,7 @@ disable_toc: true {{< /whatsnext >}} {{< whatsnext desc="Cloud Security Guides:" >}} - {{< nextlink href="/getting_started/cloud_security_management" >}}First Steps for Cloud Security{{< /nextlink >}} + {{< nextlink href="/getting_started/cloud_security_management" >}}First Steps for {{< prodname >}}Cloud Security{{< /prodname >}}{{< /nextlink >}} {{< nextlink href="/security/cloud_security_management/guide/agent_variables" >}}Cloud Security Agent Variables{{< /nextlink >}} {{< /whatsnext >}} @@ -41,7 +41,7 @@ disable_toc: true {{< /whatsnext >}} {{< whatsnext desc="App and API Protection Guides:" >}} - {{< nextlink href="/getting_started/application_security/" >}}First steps with App and API Protection{{< /nextlink >}} + {{< nextlink href="/getting_started/application_security/" >}}First steps with {{< prodname >}}App and API Protection{{< /prodname >}}{{< /nextlink >}} {{< nextlink href="/security/application_security/guide/standalone_application_security/" >}}Standalone App and API Protection{{< /nextlink >}} {{< nextlink href="/security/application_security/guide/manage_account_theft_appsec/" >}}Managing account theft with AAP{{< /nextlink >}} {{< /whatsnext >}} diff --git a/hugo/content/en/security/guide/aws_fargate_config_guide.md b/hugo/content/en/security/guide/aws_fargate_config_guide.md index 98de0755d7e..f4d2a398464 100644 --- a/hugo/content/en/security/guide/aws_fargate_config_guide.md +++ b/hugo/content/en/security/guide/aws_fargate_config_guide.md @@ -10,7 +10,7 @@ further_reading: text: "Get real-time threat detection for AWS Fargate ECS and EKS environments with Datadog Cloud Security" --- -This guide walks you through configuring [Cloud Security][3], [Software Composition Analysis (SCA)][22], [Threat Detection and Protection (AAP)][4], and [Cloud SIEM][5] on AWS Fargate. +This guide walks you through configuring [{{< prodname >}}Cloud Security{{< /prodname >}}][3], [Software Composition Analysis (SCA)][22], [Threat Detection and Protection (AAP)][4], and [{{< prodname >}}Cloud SIEM{{< /prodname >}}][5] on AWS Fargate. {{< img src="security/datadog_security_coverage_aws_fargate2.png" alt="Flow chart showing how Cloud Security, AAP, and Cloud SIEM are configured on AWS Fargate" width="90%">}} @@ -32,14 +32,14 @@ Datadog Security provides multiple layers of visibility for AWS Fargate. Use the
- + - - - + + +
Fargate Application Application Performance MonitoringSoftware Composition Analysis (SCA) and Code SecuritySoftware Composition Analysis (SCA) and {{< prodname >}}Code Security{{< /prodname >}} AAP - Threat Detection and Protection
Fargate InfrastructureInfrastructure MonitoringCloud SecurityWorkload Protection{{< prodname >}}Infrastructure Monitoring{{< /prodname >}}{{< prodname >}}Cloud Security{{< /prodname >}}{{< prodname >}}Workload Protection{{< /prodname >}}
@@ -54,21 +54,21 @@ Datadog Security provides multiple layers of visibility for AWS Fargate. Use the AWS IAM roles and policies - Log Management - Cloud Security - Cloud SIEM + {{< prodname >}}Log Management{{< /prodname >}} + {{< prodname >}}Cloud Security{{< /prodname >}} + {{< prodname >}}Cloud SIEM{{< /prodname >}} AWS databases - Log Management - Cloud Security - Cloud SIEM + {{< prodname >}}Log Management{{< /prodname >}} + {{< prodname >}}Cloud Security{{< /prodname >}} + {{< prodname >}}Cloud SIEM{{< /prodname >}} AWS S3 buckets - Log Management - Cloud Security - Cloud SIEM + {{< prodname >}}Log Management{{< /prodname >}} + {{< prodname >}}Cloud Security{{< /prodname >}} + {{< prodname >}}Cloud SIEM{{< /prodname >}} @@ -80,7 +80,7 @@ Datadog Security provides multiple layers of visibility for AWS Fargate. Use the - Access to AWS Management Console - AWS Fargate ECS or EKS workloads -
For additional performance and reliability insights, Datadog recommends enabling Infrastructure Monitoring with Cloud Security.
+
For additional performance and reliability insights, Datadog recommends enabling {{< prodname >}}Infrastructure Monitoring{{< /prodname >}} with {{< prodname >}}Cloud Security{{< /prodname >}}.
### Images @@ -267,7 +267,7 @@ Use the following [Agent RBAC deployment instruction][6] before deploying the Ag #### Deploy the Agent as a sidecar -The following manifest represents the minimum configuration required to deploy your application with the Datadog Agent as a sidecar with Workload Protection enabled: +The following manifest represents the minimum configuration required to deploy your application with the Datadog Agent as a sidecar with {{< prodname >}}Workload Protection{{< /prodname >}} enabled: ```yaml apiVersion: apps/v1 @@ -342,9 +342,9 @@ spec: ### Verify that the Agent is sending events to Cloud Security -When you enable Cloud Security on AWS Fargate ECS or EKS, the Agent sends an agent event to Datadog to confirm that the default ruleset has been successfully deployed. To view the agent event, navigate to the [Agent Events][9] page in Datadog and search for `@agent.rule_id:ruleset_loaded`. +When you enable {{< prodname >}}Cloud Security{{< /prodname >}} on AWS Fargate ECS or EKS, the Agent sends an agent event to Datadog to confirm that the default ruleset has been successfully deployed. To view the agent event, navigate to the [Agent Events][9] page in Datadog and search for `@agent.rule_id:ruleset_loaded`. -
You can also verify the Agent is sending events to Cloud Security by manually triggering an AWS Fargate security signal.
+
You can also verify the Agent is sending events to {{< prodname >}}Cloud Security{{< /prodname >}} by manually triggering an AWS Fargate security signal.
In the task definition, replace the "workload" container with the following: @@ -367,9 +367,9 @@ In the task definition, replace the "workload" container with the following: ### Prerequisites - The Datadog Agent is installed and configured for your application's operating system or container, cloud, or virtual environment -- Datadog APM is configured for your application or service +- {{< prodname >}}Datadog APM{{< /prodname >}} is configured for your application or service -
For additional performance and reliability insights, Datadog recommends enabling Application Performance Monitoring with App and API Protection.
+
For additional performance and reliability insights, Datadog recommends enabling Application Performance Monitoring with {{< prodname >}}App and API Protection{{< /prodname >}}.
### Installation diff --git a/hugo/content/en/security/guide/byoti_guide.md b/hugo/content/en/security/guide/byoti_guide.md index 805ddb0718e..ae7b747a6e8 100644 --- a/hugo/content/en/security/guide/byoti_guide.md +++ b/hugo/content/en/security/guide/byoti_guide.md @@ -51,7 +51,7 @@ Datadog supports creating reference tables through a manual upload, or by period
  • Signals are not enriched. Enrichment only applies to traces.
  • Datadog does not enrich local or private IPs.
  • Only new traces (after the reference table is enabled or updated) are enriched. Old traces are not retroactively enriched.
    • -
  • Enrichment happens for traces that match the IPs (supported in SIEM and App and API Protection) and domains (supported in SIEM) in the reference table.
    • +
  • Enrichment happens for traces that match the IPs (supported in SIEM and {{< prodname >}}App and API Protection{{< /prodname >}}) and domains (supported in SIEM) in the reference table.
  • Manual file uploads don't auto-update. Updates occur only from cloud storage.
    • diff --git a/hugo/content/en/security/guide/findings-schema/generated/schema-reference.md b/hugo/content/en/security/guide/findings-schema/generated/schema-reference.md index 93e236c37e7..843d1bffee4 100644 --- a/hugo/content/en/security/guide/findings-schema/generated/schema-reference.md +++ b/hugo/content/en/security/guide/findings-schema/generated/schema-reference.md @@ -79,7 +79,7 @@ These attributes are present on all security findings and describe the fundament related_services array (string) - Path: @related_services
    Services that are inferred from Source Code Integration (for example, for SAST findings). + Path: @related_services
    Services that are inferred from {{< prodname >}}Source Code Integration{{< /prodname >}} (for example, for SAST findings). resource_id @@ -561,7 +561,7 @@ Container image where the finding was detected, including registry, repository, git_repository_url string - Path: @container_image.git_repository_url
    URL of the Git repository for the code used to build the container image. Available only when Source Code Integration is configured. + Path: @container_image.git_repository_url
    URL of the Git repository for the code used to build the container image. Available only when {{< prodname >}}Source Code Integration{{< /prodname >}} is configured. image_layer_diff_ids @@ -4714,12 +4714,12 @@ Information about the service where the finding was detected, including its name git_commit_sha string - Path: @service.git_commit_sha
    Git commit SHA of the latest commit where the finding was detected for the service. Available only when Source Code Integration is configured. + Path: @service.git_commit_sha
    Git commit SHA of the latest commit where the finding was detected for the service. Available only when {{< prodname >}}Source Code Integration{{< /prodname >}} is configured. git_repository_url string - Path: @service.git_repository_url
    URL of the Git repository for the service associated with the finding. Available only when Source Code Integration is configured. + Path: @service.git_repository_url
    URL of the Git repository for the service associated with the finding. Available only when {{< prodname >}}Source Code Integration{{< /prodname >}} is configured. name @@ -4992,7 +4992,7 @@ All mutable information related to the management of a finding after it was dete integrations object - Path: @workflow.integrations
    Integrations like Jira, Case Management, or ServiceNow used to triage and remediate the finding. + Path: @workflow.integrations
    Integrations like Jira, {{< prodname >}}Case Management{{< /prodname >}}, or ServiceNow used to triage and remediate the finding. mute @@ -5076,7 +5076,7 @@ Due date rule applied to the finding. ### Integrations -Integrations like Jira, Case Management, or ServiceNow used to triage and remediate the finding. +Integrations like Jira, {{< prodname >}}Case Management{{< /prodname >}}, or ServiceNow used to triage and remediate the finding. diff --git a/hugo/content/en/security/guide/security-findings-migration.md b/hugo/content/en/security/guide/security-findings-migration.md index 4f17db84d5c..0df79ab4255 100644 --- a/hugo/content/en/security/guide/security-findings-migration.md +++ b/hugo/content/en/security/guide/security-findings-migration.md @@ -63,18 +63,18 @@ View the full specification at [Security Findings Schema Reference][1]. ### New features Starting January 28, 2026, the following features will be made available and use the new data model: -- Unified search queries for Cloud Security [Misconfigurations][9], [Identity Risks][10], [Attack Paths][11], [IaC][12], and [API][13] findings +- Unified search queries for {{< prodname >}}Cloud Security{{< /prodname >}} [Misconfigurations][9], [Identity Risks][10], [Attack Paths][11], [IaC][12], and [API][13] findings - A new unified [public findings API][18] -- [Dashboard][2] support for Code Security +- [Dashboard][2] support for {{< prodname >}}Code Security{{< /prodname >}} - Graphing security findings in [Datadog Sheets][3] -- Datadog [Workflow Automation][4] support for all finding types +- Datadog [{{< prodname >}}Workflow Automation{{< /prodname >}}][4] support for all finding types - Using SQL to query security findings and join them with other Datadog telemetry using [DDSQL Editor][5] The following additional features will be released later: -- Support for Cloud Security Vulnerabilities and Code Security findings (SCA, SAST, IAST, Secrets) in the unified search experience +- Support for Cloud Security Vulnerabilities and {{< prodname >}}Code Security{{< /prodname >}} findings (SCA, SAST, IAST, Secrets) in the unified search experience - [Data Access Controls][6] -- Security findings & tools in the [Datadog MCP Server][7] +- Security findings & tools in the [{{< prodname >}}Datadog MCP Server{{< /prodname >}}][7] - API & Terraform support for [automation pipelines][8] ### Security findings @@ -91,7 +91,7 @@ Security findings encompass misconfigurations, vulnerabilities, and security ris - + @@ -113,7 +113,7 @@ Security findings encompass misconfigurations, vulnerabilities, and security ris - + diff --git a/hugo/content/en/security/mcp_server.md b/hugo/content/en/security/mcp_server.md index 798d319183d..4a186ff1352 100644 --- a/hugo/content/en/security/mcp_server.md +++ b/hugo/content/en/security/mcp_server.md @@ -29,19 +29,19 @@ algolia: ## Overview -The [Datadog MCP Server][1] lets AI agents query your security data through the [Model Context Protocol (MCP)][2]. The `security` toolset gives AI clients like Cursor, Claude Code, and OpenAI Codex access to your security signals and findings, so you can investigate threats and analyze your security posture using natural language. +The [{{< prodname >}}Datadog MCP Server{{< /prodname >}}][1] lets AI agents query your security data through the [Model Context Protocol (MCP)][2]. The `security` toolset gives AI clients like Cursor, Claude Code, and OpenAI Codex access to your security signals and findings, so you can investigate threats and analyze your security posture using natural language. -
    This page covers the security toolset of the remote Datadog MCP Server. For the Code Security MCP Server, which runs locally and scans source code during development, see Code Security MCP Server.
    +
    This page covers the security toolset of the remote {{< prodname >}}Datadog MCP Server{{< /prodname >}}. For the Code Security MCP Server, which runs locally and scans source code during development, see Code Security MCP Server.
    ### Use cases You can use the `security` toolset to: -- **Analyze and understand security signals**: Ask your AI agent to surface recent high-severity Cloud SIEM signals, App & API Protection alerts, or Workload Protection threats, and get a summary of patterns and affected resources. +- **Analyze and understand security signals**: Ask your AI agent to surface recent high-severity {{< prodname >}}Cloud SIEM{{< /prodname >}} signals, App & API Protection alerts, or {{< prodname >}}Workload Protection{{< /prodname >}} threats, and get a summary of patterns and affected resources. - **Triage security signals**: Update triage state or assignee across a set of matching signals in bulk. -- **Analyze your security posture**: Query findings across Cloud Security with SQL to understand the distribution of misconfigurations, vulnerabilities, and identity risks across your environment. +- **Analyze your security posture**: Query findings across {{< prodname >}}Cloud Security{{< /prodname >}} with SQL to understand the distribution of misconfigurations, vulnerabilities, and identity risks across your environment. - **Investigate specific findings**: Retrieve full details for a set of findings to understand scope, affected resources, and remediation context. -- **Triage security findings**: Create Jira issues, ServiceNow tickets, or Case Management cases for findings. Assign findings to team members, or mute false positives and accepted risks. +- **Triage security findings**: Create Jira issues, ServiceNow tickets, or {{< prodname >}}Case Management{{< /prodname >}} cases for findings. Assign findings to team members, or mute false positives and accepted risks. - **Correlate signals and findings**: Cross-reference active security signals with open findings to determine whether an alert is tied to a known posture issue. - **Inspect and manage detection rules**: List, retrieve, create, update, and delete detection rules to understand and manage the logic generating signals. - **Manage suppressions**: Create, update, and delete suppressions to silence noisy rules for specific conditions without disabling them entirely. @@ -54,7 +54,7 @@ You can use the `security` toolset to: The `security` toolset is not enabled by default. You can enable it by adding a parameter to your URL, which allows security tools to interact with your AI client. 1. [Set up the Datadog MCP Server][4]. -2. When connecting to the Datadog MCP Server, add `security` to the `toolsets` parameter. For example, for your [Datadog site][3] ({{< region-param key="dd_site_name" >}}), use: +2. When connecting to the {{< prodname >}}Datadog MCP Server{{< /prodname >}}, add `security` to the `toolsets` parameter. For example, for your [Datadog site][3] ({{< region-param key="dd_site_name" >}}), use: ```text https://mcp.{{< region-param key="dd_site" >}}/v1/mcp?toolsets=core,security ``` @@ -72,7 +72,7 @@ The `security` toolset exposes the following tools to your AI client. Each tool : *Permissions required: `Security Signals Read`* `search_datadog_security_signals` -: Searches and retrieves security signals from Datadog, including Cloud SIEM signals, App & API Protection signals, and Workload Protection signals. Use this to surface and investigate suspicious activity. +: Searches and retrieves security signals from Datadog, including {{< prodname >}}Cloud SIEM{{< /prodname >}} signals, App & API Protection signals, and {{< prodname >}}Workload Protection{{< /prodname >}} signals. Use this to surface and investigate suspicious activity. : *Permissions required: `Security Signals Read`* `analyze_datadog_security_signals` @@ -120,15 +120,15 @@ The `security` toolset exposes the following tools to your AI client. Each tool : *Permissions required: `Security Monitoring Findings Read`* `get_datadog_security_findings_ticket_suggestions` -: Returns ranked project suggestions for ticketing security findings. Shows available Case Management, Jira, Linear, and ServiceNow projects with usage data. Call this before `create_datadog_security_findings_ticket` to discover which project to use. +: Returns ranked project suggestions for ticketing security findings. Shows available {{< prodname >}}Case Management{{< /prodname >}}, Jira, Linear, and ServiceNow projects with usage data. Call this before `create_datadog_security_findings_ticket` to discover which project to use. : *Permissions required: `Security Monitoring Findings Read`, `Cases Read`* `create_datadog_security_findings_ticket` -: Creates a Case Management case, Jira issue, Linear issue, or ServiceNow ticket for security findings. Requires specific finding IDs and a project ID. Use `get_datadog_security_findings_ticket_suggestions` first to discover available projects. +: Creates a {{< prodname >}}Case Management{{< /prodname >}} case, Jira issue, Linear issue, or ServiceNow ticket for security findings. Requires specific finding IDs and a project ID. Use `get_datadog_security_findings_ticket_suggestions` first to discover available projects. : *Permissions required: `Security Monitoring Findings Write`, `Cases Read`, `Cases Write`* `detach_datadog_security_findings_ticket` -: Detaches security findings from their linked case or ticket. Since Jira and ServiceNow tickets are linked through Case Management, detaching the case also detaches any downstream ticket. +: Detaches security findings from their linked case or ticket. Since Jira and ServiceNow tickets are linked through {{< prodname >}}Case Management{{< /prodname >}}, detaching the case also detaches any downstream ticket. : *Permissions required: `Security Monitoring Findings Write`, `Cases Write`* `mute_datadog_security_findings` @@ -144,7 +144,7 @@ The `security` toolset exposes the following tools to your AI client. Each tool : *Permissions required: `Security Pipelines Read`* `create_datadog_security_findings_automation_rule` -: Creates a security findings automation rule. Choose a `rule_type`: `mute` (suppress findings), `due_date` (set remediation deadlines), `severity_modifier` (adjust finding severity), or `ticket_creation` (auto-create Jira or Case Management tickets). +: Creates a security findings automation rule. Choose a `rule_type`: `mute` (suppress findings), `due_date` (set remediation deadlines), `severity_modifier` (adjust finding severity), or `ticket_creation` (auto-create Jira or {{< prodname >}}Case Management{{< /prodname >}} tickets). : *Permissions required: `Security Pipelines Write`, `Security Monitoring Findings Read`* `update_datadog_security_findings_automation_rule` diff --git a/hugo/content/en/security/notifications/rules.md b/hugo/content/en/security/notifications/rules.md index 96bae76620d..544874974ac 100644 --- a/hugo/content/en/security/notifications/rules.md +++ b/hugo/content/en/security/notifications/rules.md @@ -48,7 +48,7 @@ To create a notification rule, specify the conditions under which the rule shoul - **Signal**: Suspicious activity that poses an active threat against your infrastructure. 1. Select one or more severity levels. 1. Specify the tags and attributes that must be present for the notification rule to be triggered. -
    If you selected Signal in step 3, you can get notifications for completed Bits Security Analyst investigations by adding the tag @workflow.bits_investigator.state:*.
    +
    If you selected Signal in step 3, you can get notifications for completed {{< prodname >}}Bits Security Analyst{{< /prodname >}} investigations by adding the tag @workflow.bits_investigator.state:*.
    1. If you selected **Finding** in step 3, select the frequency of the notifications: - **Aggregate results over**: Select this option, followed by a time frame from the list, to only get one notification for detections that occurred over that time frame. - **Trigger immediately for each individual issue meeting the criteria**: Select this option to get one notification for each detection.
    **Note**: Selecting this option can result in a large number of notifications. diff --git a/hugo/content/en/security/security_inbox.md b/hugo/content/en/security/security_inbox.md index 2c79705d327..8b0622860b6 100644 --- a/hugo/content/en/security/security_inbox.md +++ b/hugo/content/en/security/security_inbox.md @@ -30,7 +30,7 @@ Security Inbox provides a consolidated, actionable list of your most important s ## Types of findings in Security Inbox -The findings that appear in Security Inbox are generated from App and API Protection (AAP) and Cloud Security. By default, these include the following types of findings: +The findings that appear in Security Inbox are generated from {{< prodname >}}App and API Protection{{< /prodname >}} (AAP) and {{< prodname >}}Cloud Security{{< /prodname >}}. By default, these include the following types of findings: - A curated set of [misconfigurations][1] for [Cloud Security Misconfigurations][2], compiled by Datadog Security Research. - A curated set of [identity risks][1] for [Cloud Security Identity Risks][3], compiled by Datadog Security Research. diff --git a/hugo/content/en/security/sensitive_data_scanner/_index.md b/hugo/content/en/security/sensitive_data_scanner/_index.md index d6e5fe57faf..a4c667816d9 100644 --- a/hugo/content/en/security/sensitive_data_scanner/_index.md +++ b/hugo/content/en/security/sensitive_data_scanner/_index.md @@ -56,8 +56,8 @@ Sensitive data, such as credit card numbers, API keys, IP addresses, and persona - APM spans - Code repositories -- Events from Event Management -- Agent Observability traces +- Events from {{< prodname >}}Event Management{{< /prodname >}} +- {{< prodname >}}Agent Observability{{< /prodname >}} traces - RUM events - Telemetry data, such as application logs @@ -67,9 +67,9 @@ Sensitive data can also be unintentionally moved to cloud storage resources when ## Supported data sources -Sensitive Data Scanner scans telemetry data (logs, APM spans, RUM events, and events), Agent Observability traces, cloud storage, and code repositories. +Sensitive Data Scanner scans telemetry data (logs, APM spans, RUM events, and events), {{< prodname >}}Agent Observability{{< /prodname >}} traces, cloud storage, and code repositories. -The action you can apply to matched sensitive data depends on the data source. The following table shows which obfuscation actions are supported for each telemetry source and for Agent Observability: +The action you can apply to matched sensitive data depends on the data source. The following table shows which obfuscation actions are supported for each telemetry source and for {{< prodname >}}Agent Observability{{< /prodname >}}: | Action | Logs | APM | RUM | Events | Agent Observability | |------------------|------|-----|-----|--------|---------------------| @@ -116,15 +116,15 @@ See [Set Up Sensitive Data Scanner for Telemetry Data][4] for setup details. #### In your environment {#in-your-environment} -Use [Observability Pipelines][5] to collect and process your logs within your environment, and then route the data to their downstream integrations. When you set up a pipeline in Observability Pipelines, add the [Sensitive Data Scanner processor][6] to redact sensitive data in your logs before they leave your premises. You can add predefined scanning rules from the Rule Library, such as email addresses, credit card numbers, API keys, authorization tokens, IP addresses, and more. You can also create your own rules using regex patterns. +Use [{{< prodname >}}Observability Pipelines{{< /prodname >}}][5] to collect and process your logs within your environment, and then route the data to their downstream integrations. When you set up a pipeline in {{< prodname >}}Observability Pipelines{{< /prodname >}}, add the [Sensitive Data Scanner processor][6] to redact sensitive data in your logs before they leave your premises. You can add predefined scanning rules from the Rule Library, such as email addresses, credit card numbers, API keys, authorization tokens, IP addresses, and more. You can also create your own rules using regex patterns. See [Set Up Pipelines][7] for more information. ### Agent Observability -Sensitive Data Scanner can scan [Agent Observability][20] traces, including inputs and outputs from LLM applications. This helps prevent exposing sensitive data like PII, API keys, or proprietary information in prompts, completions, and LLM workflow metadata. +Sensitive Data Scanner can scan [{{< prodname >}}Agent Observability{{< /prodname >}}][20] traces, including inputs and outputs from LLM applications. This helps prevent exposing sensitive data like PII, API keys, or proprietary information in prompts, completions, and LLM workflow metadata. -Agent Observability scanning uses a managed configuration model that differs from telemetry data scanning, where Agent Observability scanning has: +{{< prodname >}}Agent Observability{{< /prodname >}} scanning uses a managed configuration model that differs from telemetry data scanning, where {{< prodname >}}Agent Observability{{< /prodname >}} scanning has: - **One managed scanning group**: A default scanning group is automatically created for your organization when you first access the [Agent Observability Settings page][18]. You cannot create additional scanning groups or delete the managed group. - **Customizable rules**: You can modify existing rules, disable rules you don't need, or add custom scanning rules to detect additional sensitive data patterns. @@ -135,7 +135,7 @@ For each scanning rule, one of the following actions can be applied to matched s - **Partially redact**: Replace a specific portion of all matching values. - **Hash**: Replace the entire matched data with a non-reversible unique identifier. -To configure scanning for Agent Observability data, navigate to the [Agent Observability Settings page][18] in Sensitive Data Scanner settings. For more information about Agent Observability, see the [Agent Observability documentation][20]. +To configure scanning for {{< prodname >}}Agent Observability{{< /prodname >}} data, navigate to the [Agent Observability Settings page][18] in Sensitive Data Scanner settings. For more information about {{< prodname >}}Agent Observability{{< /prodname >}}, see the [Agent Observability documentation][20]. ### Cloud storage @@ -147,7 +147,7 @@ Sensitive Data Scanner scans for sensitive data by deploying [Agentless scanners Sensitive Data Scanner leverages its [entire rules library][10] to find matches. When a match is found, the location of the match is sent to Datadog by the scanning instance. **Note**: Data stores and their files are only read in your environment—no sensitive data that was scanned is sent back to Datadog. -Along with displaying sensitive data matches, Sensitive Data Scanner surfaces any security issues detected by [Cloud Security][11] affecting the sensitive data stores. You can click any issue to continue triage and remediation within Cloud Security. +Along with displaying sensitive data matches, Sensitive Data Scanner surfaces any security issues detected by [{{< prodname >}}Cloud Security{{< /prodname >}}][11] affecting the sensitive data stores. You can click any issue to continue triage and remediation within {{< prodname >}}Cloud Security{{< /prodname >}}. See [Set up Sensitive Data Scanner for Cloud Storage][12] for setup details. @@ -155,7 +155,7 @@ See [Set up Sensitive Data Scanner for Cloud Storage][12] for setup details. Datadog [Secret Scanning][21] scans code repositories to detect exposed secrets in the source code. Secret Scanning is powered by Sensitive Data Scanner and uses all rules from the [Secrets and credentials category][19] of the SDS library to find matches. -Unlike telemetry data scanning, Secret Scanning operates in your CI/CD pipelines or directly in Datadog with hosted scanning (supported for GitHub, Azure DevOps, and GitLab). When secrets are detected in the code, findings are surfaced in the Code Security interface. +Unlike telemetry data scanning, Secret Scanning operates in your CI/CD pipelines or directly in Datadog with hosted scanning (supported for GitHub, Azure DevOps, and GitLab). When secrets are detected in the code, findings are surfaced in the {{< prodname >}}Code Security{{< /prodname >}} interface. See the [Secret Scanning documentation][21] for setup details. 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 d5242442f1e..5838b7bbb76 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 @@ -56,7 +56,7 @@ To investigate a log finding: Additionally, you can: - Use {{< ui >}}Apply Targeted Obfuscation{{< /ui >}} to obfuscate future sensitive data matches in new logs for this finding, or extend obfuscation to the entire service. If redaction is already enabled, use this section to verify how matching logs are obfuscated. - Use {{< ui >}}Tune Detection Logic{{< /ui >}} to edit the scanning rule's keywords or apply suppressions for false positives or risk-accepted data. -- Use {{< ui >}}Generate Code Fix{{< /ui >}} to launch a [Bits Code][2] session that identifies the log pattern causing the leak and proposes a fix. Review the fix and create a pull request directly from the session. The source repository must already be onboarded to Bits Code. +- Use {{< ui >}}Generate Code Fix{{< /ui >}} to launch a [{{< prodname >}}Bits Code{{< /prodname >}}][2] session that identifies the log pattern causing the leak and proposes a fix. Review the fix and create a pull request directly from the session. The source repository must already be onboarded to {{< prodname >}}Bits Code{{< /prodname >}}. [1]: /help [2]: /bits_ai/bits_code/ @@ -85,8 +85,8 @@ To investigate a finding: To modify the Scanning Rule that was used to detect the sensitive data finding, click {{< ui >}}Modify Rule{{< /ui >}} at the top of the panel. Additionally, you can also: -- Use [Case Management][1] to track, triage, and investigate the finding, click {{< ui >}}Create Case{{< /ui >}} at the top of the panel. Associated cases are surfaced in the Findings page. -- Use [Incident Management][2] to create an incident, you can add the finding to an existing incident or declare a new incident. Click the {{< ui >}}Declare Incident{{< /ui >}} dropdown menu to add the finding to an existing incident. Click {{< ui >}}Declare Incident{{< /ui >}} to declare a new incident. +- Use [{{< prodname >}}Case Management{{< /prodname >}}][1] to track, triage, and investigate the finding, click {{< ui >}}Create Case{{< /ui >}} at the top of the panel. Associated cases are surfaced in the Findings page. +- Use [{{< prodname >}}Incident Management{{< /prodname >}}][2] to create an incident, you can add the finding to an existing incident or declare a new incident. Click the {{< ui >}}Declare Incident{{< /ui >}} dropdown menu to add the finding to an existing incident. Click {{< ui >}}Declare Incident{{< /ui >}} to declare a new incident. - Use [Audit Trail][3] to see who may have accessed this sensitive data within Datadog, {{< ui >}}View in Audit Trail{{< /ui >}} in the {{< ui >}}Users who accessed these events{{< /ui >}} section. {{< img src="sensitive_data_scanner/investigate_sensitive_data_issues/case_mgmt_02_01_2024.png" alt="The case page showing information about the security finding, the assignee and creator of the case, and a timeline of events" style="width:60%;">}} @@ -110,7 +110,7 @@ To investigate a datastore: - If it is not supposed to be in the bucket, delete the files or move them to an appropriate bucket. - If it is supposed to be in the bucket, complete the following steps to improve your security posture: 1. Click the {{< ui >}}Security{{< /ui >}} tab in the side panel and review the {{< ui >}}Misconfigurations{{< /ui >}} section. - 1. Click on a misconfiguration to see details in Cloud Security. + 1. Click on a misconfiguration to see details in {{< prodname >}}Cloud Security{{< /prodname >}}. 1. In the {{< ui >}}Next Steps{{< /ui >}} section: 1. Under {{< ui >}}Triage{{< /ui >}}, click the dropdown to change the triage status of the signal. The default status is `OPEN`. 1. Click {{< ui >}}Assign Signal{{< /ui >}} to assign a signal to yourself or another Datadog user. diff --git a/hugo/content/en/security/sensitive_data_scanner/scanning_rules/_index.md b/hugo/content/en/security/sensitive_data_scanner/scanning_rules/_index.md index d7ca0510671..23901dd12fc 100644 --- a/hugo/content/en/security/sensitive_data_scanner/scanning_rules/_index.md +++ b/hugo/content/en/security/sensitive_data_scanner/scanning_rules/_index.md @@ -22,7 +22,7 @@ Physical address PII detection in logs using machine learning is in Preview. To
    Human Name Scanner detects personal names in logs using machine learning. The feature is in Preview for the {{< region-param key="dd_site_name" >}} site. Fill out the form to request access.
    {{< /site-region >}} -Sensitive Data Scanner for Telemetry Data uses scanning rules to determine what sensitive information to match within the data. This data can be from your application logs, APM spans, RUM events, and events from Event Management. You can use Datadog's [Scanning Rule Library][1] to create rules or you can create [custom rules][2]. +Sensitive Data Scanner for Telemetry Data uses scanning rules to determine what sensitive information to match within the data. This data can be from your application logs, APM spans, RUM events, and events from {{< prodname >}}Event Management{{< /prodname >}}. You can use Datadog's [Scanning Rule Library][1] to create rules or you can create [custom rules][2]. Datadog's Scanning Rule Library containes predefined scanning rules that detect common patterns, such as email addresses, credit card numbers, API keys, authorization tokens, network and device information, and more. See [Library Rules][1] for more information. diff --git a/hugo/content/en/security/sensitive_data_scanner/scanning_rules/library_rules.md b/hugo/content/en/security/sensitive_data_scanner/scanning_rules/library_rules.md index f02f2b377db..3edcf5d3ad5 100644 --- a/hugo/content/en/security/sensitive_data_scanner/scanning_rules/library_rules.md +++ b/hugo/content/en/security/sensitive_data_scanner/scanning_rules/library_rules.md @@ -30,7 +30,7 @@ These rules can also be viewed in Datadog: 1. Click {{< ui >}}Add Rules to Scanning Group{{< /ui >}}.
    1. Follow the steps in [Set Up Sensitive Data Scanner][2] to finish the setup. -
    Most library rules are available for all data sources (Logs, APM, RUM, Agent Observability, Observability Pipelines, Secret Scanning, and Cloud Storage). Check the Available For column to see which data sources each rule supports.
    +
    Most library rules are available for all data sources (Logs, APM, RUM, {{< prodname >}}Agent Observability{{< /prodname >}}, {{< prodname >}}Observability Pipelines{{< /prodname >}}, Secret Scanning, and Cloud Storage). Check the Available For column to see which data sources each rule supports.
    {{< multifilter-search resource="sds_rules" >}} diff --git a/hugo/content/en/security/sensitive_data_scanner/setup/_index.md b/hugo/content/en/security/sensitive_data_scanner/setup/_index.md index 3b9cbb4f466..89045c2b104 100644 --- a/hugo/content/en/security/sensitive_data_scanner/setup/_index.md +++ b/hugo/content/en/security/sensitive_data_scanner/setup/_index.md @@ -23,11 +23,11 @@ further_reading: Set up Sensitive Data Scanner for each data source you want to scan. Each source uses its own setup process, so you only need to configure the sources relevant to your needs. -- **Telemetry data:** Scan your logs, APM spans, RUM events, and events from Event Management. See [Telemetry Data][1] for setup instructions. To scan logs before they leave your network, use the [Sensitive Data Scanner processor for Observability Pipelines][5]. -- **Agent Observability data:** Scan LLM traces, prompts, and completions. Configure scanning from the [Agent Observability Settings page][3]. +- **Telemetry data:** Scan your logs, APM spans, RUM events, and events from {{< prodname >}}Event Management{{< /prodname >}}. See [Telemetry Data][1] for setup instructions. To scan logs before they leave your network, use the [Sensitive Data Scanner processor for Observability Pipelines][5]. +- **{{< prodname >}}Agent Observability{{< /prodname >}} data:** Scan LLM traces, prompts, and completions. Configure scanning from the [Agent Observability Settings page][3]. - **Cloud storage data:** Scan your Amazon S3 buckets. See [Cloud Storage][2] for setup instructions. - **Code repositories:** Detect exposed secrets in your source code. See [Secret Scanning][4] for setup instructions. -- **AI Guard evaluations:** Scan the conversations AI Guard evaluates for sensitive data such as credentials and PII. Configure scanning rules from the [AI Guard tab][6] of the Sensitive Data Scanner configuration page. +- **{{< prodname >}}AI Guard{{< /prodname >}} evaluations:** Scan the conversations {{< prodname >}}AI Guard{{< /prodname >}} evaluates for sensitive data such as credentials and PII. Configure scanning rules from the [AI Guard tab][6] of the Sensitive Data Scanner configuration page. ## Further reading diff --git a/hugo/content/en/security/sensitive_data_scanner/setup/telemetry_data.md b/hugo/content/en/security/sensitive_data_scanner/setup/telemetry_data.md index e00bb0cbdb4..f561f08cc6c 100644 --- a/hugo/content/en/security/sensitive_data_scanner/setup/telemetry_data.md +++ b/hugo/content/en/security/sensitive_data_scanner/setup/telemetry_data.md @@ -19,7 +19,7 @@ further_reading: ## Overview -Sensitive Data Scanner in the Cloud scans telemetry data, such as your application logs, APM events, RUM events, and events from Event Management. The data that can be scanned and redacted are: +Sensitive Data Scanner in the Cloud scans telemetry data, such as your application logs, APM events, RUM events, and events from {{< prodname >}}Event Management{{< /prodname >}}. The data that can be scanned and redacted are: - **Logs**: All structured and unstructured log content, including log message and attribute values - **APM**: Span attribute values only @@ -41,7 +41,7 @@ For each scanning rule, one of the following actions can be applied to matched s You submit logs and events to the Datadog backend, so the data leaves your environment before it gets redacted. The logs and events are scanned and redacted in the Datadog backend during processing, so sensitive data is redacted before events are indexed and shown in the Datadog UI. -If you don't want data to leave your environment before it gets redacted, use [Observability Pipelines][12] and the [Sensitive Data Scanner processor][13] to scan and redact sensitive data. See [Set Up Pipelines][14] for information on how to set up a pipeline and its components. +If you don't want data to leave your environment before it gets redacted, use [{{< prodname >}}Observability Pipelines{{< /prodname >}}][12] and the [Sensitive Data Scanner processor][13] to scan and redact sensitive data. See [Set Up Pipelines][14] for information on how to set up a pipeline and its components. To use Sensitive Data Scanner in the Cloud, set up a scanning group to define what data to scan and then add scanning rules to determine what sensitive information to match within the data. diff --git a/hugo/content/en/security/sensitive_data_scanner/troubleshooting.md b/hugo/content/en/security/sensitive_data_scanner/troubleshooting.md index 89f9bd77a44..e56e481bbae 100644 --- a/hugo/content/en/security/sensitive_data_scanner/troubleshooting.md +++ b/hugo/content/en/security/sensitive_data_scanner/troubleshooting.md @@ -20,7 +20,7 @@ If a Sensitive Data Scanner rule does not match data that you expect it to match The Sensitive Data Scanner obfuscation actions are {{< ui >}}Redact{{< /ui >}}, {{< ui >}}Partially redact{{< /ui >}}, {{< ui >}}Hash{{< /ui >}}, and {{< ui >}}Mask{{< /ui >}}. If you cannot select one of these actions, check the following causes: - **Sampling is enabled**: The {{< ui >}}Redact{{< /ui >}}, {{< ui >}}Partially redact{{< /ui >}}, {{< ui >}}Hash{{< /ui >}}, and {{< ui >}}Mask{{< /ui >}} actions are not available when a scanning group has sampling enabled. To use these actions, disable sampling in the scanning group settings so that all data matching the group query filter is scanned. -- **Mask is supported for logs only**: The {{< ui >}}Mask{{< /ui >}} action is not available for APM, RUM, or Event Management data. +- **Mask is supported for logs only**: The {{< ui >}}Mask{{< /ui >}} action is not available for APM, RUM, or {{< prodname >}}Event Management{{< /prodname >}} data. ## Further reading diff --git a/hugo/content/en/security/ticketing_integrations.md b/hugo/content/en/security/ticketing_integrations.md index 71693bc4810..87dcfe94256 100644 --- a/hugo/content/en/security/ticketing_integrations.md +++ b/hugo/content/en/security/ticketing_integrations.md @@ -43,13 +43,13 @@ To assign a Datadog user to a finding without creating a ticket, see [Assignee M ## Case management and security products -Case Management is supported for all security products that use signals or findings: +{{< prodname >}}Case Management{{< /prodname >}} is supported for all security products that use signals or findings: -- Code Security (in [Findings][5]) -- Cloud Security (in [Findings][11]) -- Cloud SIEM (in [Signals][4]) -- App and API Protection (in [Signals][6] and [Findings][12]) -- Workload Protection (in [Signals][7] and [Findings][13]) +- {{< prodname >}}Code Security{{< /prodname >}} (in [Findings][5]) +- {{< prodname >}}Cloud Security{{< /prodname >}} (in [Findings][11]) +- {{< prodname >}}Cloud SIEM{{< /prodname >}} (in [Signals][4]) +- {{< prodname >}}App and API Protection{{< /prodname >}} (in [Signals][6] and [Findings][12]) +- {{< prodname >}}Workload Protection{{< /prodname >}} (in [Signals][7] and [Findings][13]) Open any signal or finding in these products or do a bulk selection of findings in the explorers, and use the {{< ui >}}Create Ticket{{< /ui >}} button to create a case in Datadog. @@ -60,7 +60,7 @@ Bidirectional syncing enables you to update tickets automatically when changes o ### Supported products -Bidirectional syncing is supported for the following Code and Cloud Security finding categories: +Bidirectional syncing is supported for the following Code and {{< prodname >}}Cloud Security{{< /prodname >}} finding categories: - Libraries (SCA) - Static Code (SAST) @@ -70,8 +70,8 @@ Bidirectional syncing is supported for the following Code and Cloud Security fin - Misconfigurations - Identity Risks - Host and Container Vulnerabilities -- App and API Protection -- Workload Protection +- {{< prodname >}}App and API Protection{{< /prodname >}} +- {{< prodname >}}Workload Protection{{< /prodname >}} ### Single source of truth @@ -93,22 +93,22 @@ The following steps set up bidirectional syncing with Jira and verify that setup 1. Set up the following prerequisites in your Datadog account, or verify that they are set up already. The prerequisites are listed in their setup order. 1. The [Datadog Jira integration][2]. - 2. A [webhook for the Jira integration][8]. Configuring a webhook enables cases created in Case Management to automatically create issues in Jira and keep both resources synced. + 2. A [webhook for the Jira integration][8]. Configuring a webhook enables cases created in {{< prodname >}}Case Management{{< /prodname >}} to automatically create issues in Jira and keep both resources synced. 3. A [new Case Management project][9]. A project is a container object that holds a set of cases. 4. The [Jira integration is configured within the project][3]. - 1. Enable the {{< ui >}}Sync data between Case Management and Jira{{< /ui >}} option. + 1. Enable the {{< ui >}}Sync data between {{< prodname >}}Case Management{{< /prodname >}} and Jira{{< /ui >}} option. 2. In {{< ui >}}Title{{< /ui >}}, select {{< ui >}}Two-way sync{{< /ui >}}. 3. Complete the remaining settings, and then click {{< ui >}}Save changes{{< /ui >}}. -2. Verify that bidirectional Case Management integration with Jira is working: +2. Verify that bidirectional {{< prodname >}}Case Management{{< /prodname >}} integration with Jira is working: 1. Open [any product supporting bidirectional ticket syncing][20]. 2. Locate the ticketing dropdown option in the explorer or finding page and select {{< ui >}}Jira{{< /ui >}}. The button opens a {{< ui >}}Jira Ticket{{< /ui >}} modal. - 3. Verify that the {{< ui >}}Case Management ↔ Jira Integration{{< /ui >}} section exists and bidirectional sync is enabled. + 3. Verify that the {{< ui >}}{{< prodname >}}Case Management{{< /prodname >}} ↔ Jira Integration{{< /ui >}} section exists and bidirectional sync is enabled. {{< img src="security/jira_modal-1.png" alt="Modal used to create a Jira ticket for a Security finding, with bidirectional sync enabled." responsive="true" style="width:50%;">}} -You are ready to start creating bidirectional Case Management tickets. +You are ready to start creating bidirectional {{< prodname >}}Case Management{{< /prodname >}} tickets. -If you do not see the {{< ui >}}Case Management ↔ Jira Integration{{< /ui >}} section, verify that you have completed the prerequisites. +If you do not see the {{< ui >}}{{< prodname >}}Case Management{{< /prodname >}} ↔ Jira Integration{{< /ui >}} section, verify that you have completed the prerequisites. [2]: /integrations/jira/ [3]: /incident_response/case_management/notifications_integrations/#third-party-tickets @@ -124,20 +124,20 @@ The following steps set up bidirectional syncing with ServiceNow and verify that 1. Set up the following prerequisites in your Datadog account, or verify that they are set up already. The prerequisites are listed in their setup order. 1. The [Datadog ServiceNow integration][21]. - 1. Go to {{< ui >}}Settings{{< /ui >}} > {{< ui >}}Integrations{{< /ui >}} > {{< ui >}}ServiceNow{{< /ui >}} > {{< ui >}}Case Management{{< /ui >}}. + 1. Go to {{< ui >}}Settings{{< /ui >}} > {{< ui >}}Integrations{{< /ui >}} > {{< ui >}}ServiceNow{{< /ui >}} > {{< ui >}}{{< prodname >}}Case Management{{< /prodname >}}{{< /ui >}}. 2. Choose `Datadog Cases ITSM` as the case table for bidirectional sync. 2. A [Case Management project][9] to link to your assignment group. A project is a container object that holds a set of cases linked to your ServiceNow table. If there is no linked project, Datadog creates a project when you create a ticket. 3. For ITSM bidirectional sync, ensure ServiceNow users who update incidents have at least the `itil` role. See [ServiceNow ITOM/ITSM setup][22] for details. -2. Verify that bidirectional Case Management integration with ServiceNow is working: +2. Verify that bidirectional {{< prodname >}}Case Management{{< /prodname >}} integration with ServiceNow is working: 1. Open [any product supporting bidirectional ticket syncing][20]. 2. Locate the ticketing dropdown option in the explorer or finding page and select {{< ui >}}ServiceNow{{< /ui >}}. The button opens a {{< ui >}}ServiceNow Ticket{{< /ui >}} modal. 3. Verify that the bidirectional sync is enabled for the configured {{< ui >}}Instance{{< /ui >}} and {{< ui >}}Assignment Group{{< /ui >}}. {{< img src="security/servicenow_modal.png" alt="Modal used to create a ServiceNow ticket for a Security finding, with two-way sync and statuses mapping enabled." responsive="true" style="width:50%;">}} -You are ready to start creating bidirectional Case Management tickets. +You are ready to start creating bidirectional {{< prodname >}}Case Management{{< /prodname >}} tickets. -If you do not see the {{< ui >}}Case Management ↔ ServiceNow Integration{{< /ui >}} section, verify that you have completed the prerequisites. +If you do not see the {{< ui >}}{{< prodname >}}Case Management{{< /prodname >}} ↔ ServiceNow Integration{{< /ui >}} section, verify that you have completed the prerequisites. [3]: /incident_response/case_management/notifications_integrations/#third-party-tickets [9]: /incident_response/case_management/projects/ @@ -156,22 +156,22 @@ The following steps set up bidirectional syncing with Linear and verify that set 1. Set up the following prerequisites in your Datadog account, or verify that they are set up already. The prerequisites are listed in their setup order. 1. The [Datadog Linear integration][23]. - 2. A [webhook for the Linear integration][24]. Configuring a webhook keeps cases created in Case Management and their Linear issues synced. + 2. A [webhook for the Linear integration][24]. Configuring a webhook keeps cases created in {{< prodname >}}Case Management{{< /prodname >}} and their Linear issues synced. 3. A [new Case Management project][9]. A project is a container object that holds a set of cases. 4. The [Linear integration is configured within the project][3]. 1. Enable Linear for the project, and then select a Linear account and team for issue creation. 2. For each field you want to keep synced, select {{< ui >}}Two-way sync{{< /ui >}}. 3. Complete the remaining settings, and then save your changes. -2. Verify that bidirectional Case Management integration with Linear is working: +2. Verify that bidirectional {{< prodname >}}Case Management{{< /prodname >}} integration with Linear is working: 1. Open [any product supporting bidirectional ticket syncing][20]. 2. Locate the ticketing dropdown option in the explorer or finding page and select {{< ui >}}Linear{{< /ui >}}. The button opens a {{< ui >}}Linear Issue{{< /ui >}} modal. - 3. Verify that the {{< ui >}}Case Management ↔ Linear Integration{{< /ui >}} section exists and bidirectional sync is enabled. + 3. Verify that the {{< ui >}}{{< prodname >}}Case Management{{< /prodname >}} ↔ Linear Integration{{< /ui >}} section exists and bidirectional sync is enabled. {{< img src="security/linear_modal.png" alt="Modal used to create a Linear issue for a Security finding, with bidirectional sync enabled." responsive="true" style="width:50%;">}} -You are ready to start creating bidirectional Case Management tickets. +You are ready to start creating bidirectional {{< prodname >}}Case Management{{< /prodname >}} tickets. -If you do not see the {{< ui >}}Case Management ↔ Linear Integration{{< /ui >}} section, verify that you have completed the prerequisites. +If you do not see the {{< ui >}}{{< prodname >}}Case Management{{< /prodname >}} ↔ Linear Integration{{< /ui >}} section, verify that you have completed the prerequisites. [3]: /incident_response/case_management/notifications_integrations/#third-party-tickets [9]: /incident_response/case_management/projects/ @@ -264,7 +264,7 @@ Details such as assignee and status are provided along with a timeline of the Ji Closed Jira tickets are green. -In {{< ui >}}Datadog Associated Case{{< /ui >}}, the related Datadog case is provided. Click the case name to open it in [Case Management][1]. +In {{< ui >}}Datadog Associated Case{{< /ui >}}, the related Datadog case is provided. Click the case name to open it in [{{< prodname >}}Case Management{{< /prodname >}}][1]. [1]: /incident_response/case_management/ {{% /tab %}} @@ -279,7 +279,7 @@ Hover over the ServiceNow ticket to see its details, including status and a time {{< img src="security/bidir-servicenow-existing-hover.png" alt="Tooltip over a ServiceNow ticket pill showing the incident number, status, and a timeline of changes synced between ServiceNow and Datadog." responsive="true" style="width:100%;">}} -In {{< ui >}}Datadog Associated Case{{< /ui >}}, the related Datadog case is provided. Click the case name to open it in [Case Management][1]. +In {{< ui >}}Datadog Associated Case{{< /ui >}}, the related Datadog case is provided. Click the case name to open it in [{{< prodname >}}Case Management{{< /prodname >}}][1]. [1]: /incident_response/case_management/ {{% /tab %}} @@ -297,7 +297,7 @@ Hover over the Linear issue to see its details, including status, assignee, and {{< img src="security/bidir-linear-existing-hover.png" alt="Tooltip over a Linear issue pill showing issue status, assignee, and a timeline of changes synced between Linear and Datadog." responsive="true" style="width:100%;">}} -In {{< ui >}}Datadog Associated Case{{< /ui >}}, the related Datadog case is provided. Click the case name to open it in [Case Management][1]. +In {{< ui >}}Datadog Associated Case{{< /ui >}}, the related Datadog case is provided. Click the case name to open it in [{{< prodname >}}Case Management{{< /prodname >}}][1]. [1]: /incident_response/case_management/ {{% /tab %}} diff --git a/hugo/content/en/security/workload_protection/_index.md b/hugo/content/en/security/workload_protection/_index.md index b20be249070..6a72c706b1c 100644 --- a/hugo/content/en/security/workload_protection/_index.md +++ b/hugo/content/en/security/workload_protection/_index.md @@ -47,13 +47,13 @@ cascade: --- -Workload Protection monitors file, network, and process activity across your environment to detect real-time threats to your infrastructure. As part of the Datadog platform, you can combine the real-time threat detection of Workload Protection with metrics, logs, traces, and other telemetry to see the full context surrounding a potential attack on your workloads. +{{< prodname >}}Workload Protection{{< /prodname >}} monitors file, network, and process activity across your environment to detect real-time threats to your infrastructure. As part of the Datadog platform, you can combine the real-time threat detection of {{< prodname >}}Workload Protection{{< /prodname >}} with metrics, logs, traces, and other telemetry to see the full context surrounding a potential attack on your workloads. ## Detect threats to your production workloads in real-time Monitor file and process activity at the kernel level to detect threats to your infrastructure, such as Amazon EC2 instances, Docker containers, and Kubernetes clusters. Combine Workload Protection with [Cloud Network Monitoring][9] and detect suspicious activity at the network level before a workload is compromised. -Workload Protection Threats uses the Datadog Agent to monitor your environment. If you don't already have the Datadog Agent set up, [start with setting up the Agent][2] on a [supported operating system][1]. There are four types of monitoring that the Datadog Agent uses for Workload Protection: +Workload Protection Threats uses the Datadog Agent to monitor your environment. If you don't already have the Datadog Agent set up, [start with setting up the Agent][2] on a [supported operating system][1]. There are four types of monitoring that the Datadog Agent uses for {{< prodname >}}Workload Protection{{< /prodname >}}: 1. **Process Execution Monitoring** to watch process executions for malicious activity on hosts or containers in real-time. 2. **File Integrity Monitoring** to watch for changes to key files and directories on hosts or containers in real-time. @@ -66,9 +66,9 @@ Workload Protection Threats uses the Datadog Agent to monitor your environment.
    This feature is not available for the selected Datadog site ({{< region-param key="dd_site_name" >}}).
    {{< /site-region >}} -When a threat is confirmed, you can contain it directly from the Workload Protection signal side panel. This shortens response time and helps preserve forensic state while an investigation continues. +When a threat is confirmed, you can contain it directly from the {{< prodname >}}Workload Protection{{< /prodname >}} signal side panel. This shortens response time and helps preserve forensic state while an investigation continues. -Four response actions are available from any Workload Protection signal: +Four response actions are available from any {{< prodname >}}Workload Protection{{< /prodname >}} signal: - {{< ui >}}Kill process{{< /ui >}} to terminate the offending process. - {{< ui >}}Kill container{{< /ui >}} to terminate the offending container. @@ -89,7 +89,7 @@ By default, all OOTB Agent crypto mining threat detection rules are enabled and Workload Protection Threats comes with more than 50 out-of-the-box detection rules that are maintained by a team of security experts. The rules surface the most important risks so that you can immediately take steps to remediate. Agent expression rules define the workload activities to be collected for analysis while backend detection rules analyze the activities and identify attacker techniques and other risky patterns of behavior. -Set up [Cloud Security][1] with {{< tooltip glossary="remote_configuration" case="title" >}} to automatically deploy new and updated rules to the Agent. [Customize the rules][5] by defining how each rule monitors process, network, and file activity, [create custom rules][6], and [set up real-time notifications](#set-up-real-time-notifications) for new signals. +Set up [{{< prodname >}}Cloud Security{{< /prodname >}}][1] with {{< tooltip glossary="remote_configuration" case="title" >}} to automatically deploy new and updated rules to the Agent. [Customize the rules][5] by defining how each rule monitors process, network, and file activity, [create custom rules][6], and [set up real-time notifications](#set-up-real-time-notifications) for new signals. @@ -114,9 +114,9 @@ Datadog is introducing a new feature called Active Protection to address the cry {{< whatsnext >}} {{< nextlink href="/security/cloud_security_management/setup/">}}Complete setup and configuration{{< /nextlink >}} - {{< nextlink href="/account_management/rbac/permissions/#cloud-security-platform">}}Datadog role permissions for Workload Protection{{< /nextlink >}} - {{< nextlink href="/security/workload_protection/workload_security_rules">}}Learn about Workload Protection detection rules{{< /nextlink >}} - {{< nextlink href="/security/default_rules/#cat-workload-security">}}Start using out-of-the-box Workload Protection detection rules{{< /nextlink >}} + {{< nextlink href="/account_management/rbac/permissions/#cloud-security-platform">}}Datadog role permissions for {{< prodname >}}Workload Protection{{< /prodname >}}{{< /nextlink >}} + {{< nextlink href="/security/workload_protection/workload_security_rules">}}Learn about {{< prodname >}}Workload Protection{{< /prodname >}} detection rules{{< /nextlink >}} + {{< nextlink href="/security/default_rules/#cat-workload-security">}}Start using out-of-the-box {{< prodname >}}Workload Protection{{< /prodname >}} detection rules{{< /nextlink >}} {{< /whatsnext >}} ## Further reading diff --git a/hugo/content/en/security/workload_protection/guide/active-protection.md b/hugo/content/en/security/workload_protection/guide/active-protection.md index e4254ce33e9..e98ec0dd942 100644 --- a/hugo/content/en/security/workload_protection/guide/active-protection.md +++ b/hugo/content/en/security/workload_protection/guide/active-protection.md @@ -17,7 +17,7 @@ further_reading:
    Workload Protection Active Protection is in Preview.
    -This topic explains how to use the Workload Protection {{< ui >}}Active Protection{{< /ui >}} feature to block crypto mining threats automatically. +This topic explains how to use the {{< prodname >}}Workload Protection{{< /prodname >}} {{< ui >}}Active Protection{{< /ui >}} feature to block crypto mining threats automatically. By default, all OOTB Agent [threat detection rules][4] are enabled and actively monitoring for crypto threats. diff --git a/hugo/content/en/security/workload_protection/guide/eBPF-free-agent.md b/hugo/content/en/security/workload_protection/guide/eBPF-free-agent.md index 55137502af7..27a41017823 100644 --- a/hugo/content/en/security/workload_protection/guide/eBPF-free-agent.md +++ b/hugo/content/en/security/workload_protection/guide/eBPF-free-agent.md @@ -5,7 +5,7 @@ aliases: disable_toc: false --- -This guide describes how to set up the Workload Protection eBPF-less solution for eBPF disabled environments, such as AWS Fargate. The eBPF-less solution uses a ptrace-based Datadog Agent. +This guide describes how to set up the {{< prodname >}}Workload Protection{{< /prodname >}} eBPF-less solution for eBPF disabled environments, such as AWS Fargate. The eBPF-less solution uses a ptrace-based Datadog Agent. This guide also describes some advantages of the ptrace solution. @@ -14,7 +14,7 @@ This guide also describes some advantages of the ptrace solution. ## Summary of Agent options -Workload Protection includes two Agent options for threat detection and response: +{{< prodname >}}Workload Protection{{< /prodname >}} includes two Agent options for threat detection and response: - eBPF solution - eBPF-less solution with ptrace: This version is only available where eBPF is not (Linux kernel versions 3.4 to 4.14). diff --git a/hugo/content/en/security/workload_protection/guide/tuning-rules.md b/hugo/content/en/security/workload_protection/guide/tuning-rules.md index 2b6ddb7b281..e89cbe7501a 100644 --- a/hugo/content/en/security/workload_protection/guide/tuning-rules.md +++ b/hugo/content/en/security/workload_protection/guide/tuning-rules.md @@ -8,7 +8,7 @@ aliases: ## Overview -Workload Protection monitors suspicious activity occurring at the workload level. However, in some cases, benign activities are flagged as malicious because of particular settings in the user's environment. When a benign expected activity is triggering a signal, you can suppress the trigger on the activity to limit noise. +{{< prodname >}}Workload Protection{{< /prodname >}} monitors suspicious activity occurring at the workload level. However, in some cases, benign activities are flagged as malicious because of particular settings in the user's environment. When a benign expected activity is triggering a signal, you can suppress the trigger on the activity to limit noise. This guide provides considerations for best practices and steps for fine-tuning signal suppression. @@ -138,11 +138,11 @@ Additionally you might notice that signals are created even when some of your ma ## Adding a suppression from the signal -When you are in the process of investigating a potential threat reported by Workload Protection detection rules, you can encounter some signals that alert on known benign behaviors that are specific to your environment. +When you are in the process of investigating a potential threat reported by {{< prodname >}}Workload Protection{{< /prodname >}} detection rules, you can encounter some signals that alert on known benign behaviors that are specific to your environment. Consider a Java process utility exploitation. An attacker intentionally targets vulnerabilities in your application code that runs Java processes. This kind of attack entails persistent access to your application by spawning its own Java shell utility. -In some cases, Workload Protection rules might also detect expected activity, for example from your security team running a pentest session to evaluate the robustness of your applications. In this case, you can evaluate the accuracy of alerts reported and suppress noise. +In some cases, {{< prodname >}}Workload Protection{{< /prodname >}} rules might also detect expected activity, for example from your security team running a pentest session to evaluate the robustness of your applications. In this case, you can evaluate the accuracy of alerts reported and suppress noise. Open the signal details side panel and navigate from one tab to the other to gain context, including key process metadata like command-line arguments and environment variable keys. For containerized workloads, the information includes the relevant image, pod, Kubernetes cluster, and more. @@ -172,7 +172,7 @@ Signals surface relevant context within security alerts. Although event data can In Workload Protection, the runtime Agent logs are generated from collected kernel events. You can preview the logs from the signal side-panel without context switching. 1. Go to your chosen signal details side-panel and click the {{< ui >}}Events{{< /ui >}} tab. -2. Click {{< ui >}}View in Log Explorer{{< /ui >}} to navigate to Log Management, which displays the full list of logs that instigate this signal. +2. Click {{< ui >}}View in Log Explorer{{< /ui >}} to navigate to {{< prodname >}}Log Management{{< /prodname >}}, which displays the full list of logs that instigate this signal. Because there can be many logs, the signal side-panel combines these logs and their shared attributes into a JSON structure. 3. Go back to the {{< ui >}}Events{{< /ui >}} tab and scroll to the end of the panel. Expand the JSON dropdown to access all log attributes contained in runtime Agent events. 4. Identify key-value pairs to suppress signals by common keys, including `@process.args`, `@process.group`, `@process.ancestors.comm`, or `@process.ancestors.args`. diff --git a/hugo/content/en/security/workload_protection/inventory/_index.md b/hugo/content/en/security/workload_protection/inventory/_index.md index 2db43fb8e0f..917776681db 100644 --- a/hugo/content/en/security/workload_protection/inventory/_index.md +++ b/hugo/content/en/security/workload_protection/inventory/_index.md @@ -15,7 +15,7 @@ Inventory is organized into the following tools: * Track coverage for serverless functions * Filter by environment, enabled features, agent version, and more - [Coverage Map][3]: - * View a map of Workload Protection status updated every 1-5 minutes + * View a map of {{< prodname >}}Workload Protection{{< /prodname >}} status updated every 1-5 minutes * Find and prioritize workloads in a warning state * Filter by policy, rule, or MITRE ATT&CK tactic to locate gaps * Check for outdated or unhealthy agents diff --git a/hugo/content/en/security/workload_protection/inventory/coverage_map.md b/hugo/content/en/security/workload_protection/inventory/coverage_map.md index 4102d095d21..0116d1c452c 100644 --- a/hugo/content/en/security/workload_protection/inventory/coverage_map.md +++ b/hugo/content/en/security/workload_protection/inventory/coverage_map.md @@ -10,7 +10,7 @@ further_reading: text: "Review your Workload Protection coverage with the Coverage map" --- -Workload Protection [Coverage][1] provides a real-time view of security coverage across all your hosts. Use Coverage to assess protection posture, identify gaps, and take immediate action. +{{< prodname >}}Workload Protection{{< /prodname >}} [Coverage][1] provides a real-time view of security coverage across all your hosts. Use Coverage to assess protection posture, identify gaps, and take immediate action. {{< img src="security/cws/workload_protection_coverage_map.png" alt="Leverage the Coverage map to get real time visibility into the workload protection status across all your hosts and see which policies are effectively applied" width="100%">}} @@ -62,17 +62,17 @@ From the {{< ui >}}Incomplete infrastructure coverage{{< /ui >}} status card on ### Identify assets missing Workload Protection -From the {{< ui >}}Incomplete infrastructure coverage{{< /ui >}} status card on the Coverage page, you can review assets without full Workload Protection (WP): +From the {{< ui >}}Incomplete infrastructure coverage{{< /ui >}} status card on the Coverage page, you can review assets without full {{< prodname >}}Workload Protection{{< /prodname >}} (WP): -1. In {{< ui >}}Improve infrastructure coverage{{< /ui >}}, click {{< ui >}}NO WP{{< /ui >}}. {{< ui >}}NO WP{{< /ui >}} shows how many hosts are running the Datadog Agent without Workload Protection enabled. +1. In {{< ui >}}Improve infrastructure coverage{{< /ui >}}, click {{< ui >}}NO WP{{< /ui >}}. {{< ui >}}NO WP{{< /ui >}} shows how many hosts are running the Datadog Agent without {{< prodname >}}Workload Protection{{< /prodname >}} enabled. 2. Click {{< ui >}}Inspect Hosts Without WP{{< /ui >}}. Fleet Automation appears, allowing you to [set up Workload Protection][3]. ### Identify assets missing key features From the {{< ui >}}Incomplete infrastructure coverage{{< /ui >}} status card on the Coverage page, you can find assets with gaps in protection. -1. In {{< ui >}}Improve infrastructure coverage{{< /ui >}}, click {{< ui >}}INFO{{< /ui >}} to review the `outdated_agent` flag. The `outdated_agent` flag means an outdated Agent version is running and might not support the latest Workload Protection features. -2. In {{< ui >}}Improve infrastructure coverage{{< /ui >}}, click {{< ui >}}NO AGENT{{< /ui >}}. {{< ui >}}NO AGENT{{< /ui >}} shows how many hosts are not running the Datadog Agent, and therefore can't be evaluated by Workload Protection. +1. In {{< ui >}}Improve infrastructure coverage{{< /ui >}}, click {{< ui >}}INFO{{< /ui >}} to review the `outdated_agent` flag. The `outdated_agent` flag means an outdated Agent version is running and might not support the latest {{< prodname >}}Workload Protection{{< /prodname >}} features. +2. In {{< ui >}}Improve infrastructure coverage{{< /ui >}}, click {{< ui >}}NO AGENT{{< /ui >}}. {{< ui >}}NO AGENT{{< /ui >}} shows how many hosts are not running the Datadog Agent, and therefore can't be evaluated by {{< prodname >}}Workload Protection{{< /prodname >}}. 1. Click {{< ui >}}Inspect Hosts Without Agent{{< /ui >}}. The Resource Catalog appears, allowing you to address hosts missing agents. 3. Filter by {{< ui >}}Agent Version{{< /ui >}} to detect outdated agents lacking recent security updates. 4. Update the Agent to ensure complete coverage. @@ -87,7 +87,7 @@ To use these filters to strengthen detection and response alignment with proven 2. After the map updates for the tactic you selected, click {{< ui >}}Techniques{{< /ui >}} and select a technique to identify gaps in technique coverage for critical systems. 3. Click {{< ui >}}Policies{{< /ui >}} and select a policy type to see the distribution of policies across the filtered infrastructure. -For information about the MITRE ATT&CK map available in SIEM or Workload Protection, see [MITRE ATT&CK map][2]. +For information about the MITRE ATT&CK map available in SIEM or {{< prodname >}}Workload Protection{{< /prodname >}}, see [MITRE ATT&CK map][2]. ### Experiment with new rules diff --git a/hugo/content/en/security/workload_protection/inventory/hosts_and_containers.md b/hugo/content/en/security/workload_protection/inventory/hosts_and_containers.md index 83c3ee95945..a5f3b013b9f 100644 --- a/hugo/content/en/security/workload_protection/inventory/hosts_and_containers.md +++ b/hugo/content/en/security/workload_protection/inventory/hosts_and_containers.md @@ -5,12 +5,12 @@ disable_toc: false The [Hosts and Containers][1] view in Datadog Workload Protection {{< ui >}}Inventory{{< /ui >}} provides a unified view of host-level agent deployment, configuration health, and security feature status. -The {{< ui >}}Hosts and Containers{{< /ui >}} view shows the hostname of all active Agents running directly on hosts or as containers. This includes hosts with Workload Protection enabled or disabled. +The {{< ui >}}Hosts and Containers{{< /ui >}} view shows the hostname of all active Agents running directly on hosts or as containers. This includes hosts with {{< prodname >}}Workload Protection{{< /prodname >}} enabled or disabled. {{< ui >}}Hosts and Containers{{< /ui >}} enables DevSecOps teams to: - Verify that protections are properly deployed and running across environments, including: - - [Workload Protection][3] + - [{{< prodname >}}Workload Protection{{< /prodname >}}][3] - [CSM Misconfigurations][2] - [Container Vulnerability Scanning][4] - [Host Vulnerability Scanning][4] @@ -72,7 +72,7 @@ Filtering on a cluster confirms whether protections are applied uniformly. This [Hosts and Containers][1] supports investigations and incident triage. Use the feature icon panel to spot protection gaps. -Typically, hosts missing critical features like {{< ui >}}Workload Protection{{< /ui >}} or {{< ui >}}Host/Container Vulnerability Scanning{{< /ui >}} are triaged first. +Typically, hosts missing critical features like {{< ui >}}{{< prodname >}}Workload Protection{{< /prodname >}}{{< /ui >}} or {{< ui >}}Host/Container Vulnerability Scanning{{< /ui >}} are triaged first. Hover over a feature icon and click {{< ui >}}Configure{{< /ui >}} to see remediation steps for all feature gaps. This enables triage without context switching. diff --git a/hugo/content/en/security/workload_protection/inventory/serverless.md b/hugo/content/en/security/workload_protection/inventory/serverless.md index 27efff6b516..2149e359974 100644 --- a/hugo/content/en/security/workload_protection/inventory/serverless.md +++ b/hugo/content/en/security/workload_protection/inventory/serverless.md @@ -7,7 +7,7 @@ further_reading: text: "AWS Fargate Configuration Guide for Datadog Security" --- -The [Serverless][1] view in Workload Protection [Inventory][2] provides real-time visibility into the security posture for serverless containerization workloads such as AWS Fargate ECS tasks. +The [Serverless][1] view in {{< prodname >}}Workload Protection{{< /prodname >}} [Inventory][2] provides real-time visibility into the security posture for serverless containerization workloads such as AWS Fargate ECS tasks. The Serverless view shows each task ARN, Datadog Agent version, cluster name, and enabled protection features. It highlights tasks without coverage or with unsupported Agent versions, helping teams identify drift and misconfigurations that reduce visibility. @@ -21,12 +21,12 @@ Here are some examples of how the Serverless view in Workload Protection Invento - Use the Serverless view to confirm that workloads launched using infrastructure-as-code (IaC) templates or automated pipelines have the correct security coverage. - Filter for {{< ui >}}Not Configured{{< /ui >}} or {{< ui >}}Agent Version{{< /ui >}} to pinpoint deployments where instrumentation wasn't set up. This enables feedback into IaC modules or base container images. - **Detect drift across clusters:** - - Filter tasks using {{< ui >}}Cluster Name{{< /ui >}} to detect when only some tasks in a cluster are instrumented with Workload Protection. This is a common sign of inconsistent task definitions or container image drift. Comparing coverage across clusters helps prevent partial rollout of security controls. + - Filter tasks using {{< ui >}}Cluster Name{{< /ui >}} to detect when only some tasks in a cluster are instrumented with {{< prodname >}}Workload Protection{{< /prodname >}}. This is a common sign of inconsistent task definitions or container image drift. Comparing coverage across clusters helps prevent partial rollout of security controls. - **Enforce Agent version consistency:** - Filter using {{< ui >}}Agent Version{{< /ui >}} to identify stale deployments. Outdated Agents might lack recent detection rules or bug fixes. Teams can respond with pipeline updates or enforcement rules to maintain alignment with the approved version baseline. - **Enable scalable runtime policy deployment:** - Filter using {{< ui >}}Workload Protection Status{{< /ui >}} to see which tasks are labeled with {{< ui >}}Configured{{< /ui >}} or {{< ui >}}Not Configured{{< /ui >}}. - - For tasks without Workload Protection, hover over the icon in the {{< ui >}}Features{{< /ui >}} column and select {{< ui >}}Configure{{< /ui >}}. Next, follow the steps to perform a manual or automatic installation. + - For tasks without {{< prodname >}}Workload Protection{{< /prodname >}}, hover over the icon in the {{< ui >}}Features{{< /ui >}} column and select {{< ui >}}Configure{{< /ui >}}. Next, follow the steps to perform a manual or automatic installation. ## Serverless workflows @@ -37,8 +37,8 @@ Here are some examples of how the Serverless view in Workload Protection Invento - **Enforce Agent versions:** - Sort by {{< ui >}}Agent Version{{< /ui >}} to enforce version control and identify workloads that must be upgraded in automation pipelines. - **Enforce instrumentation:** - 1. Hover over the shield icons in the {{< ui >}}Features{{< /ui >}} column to investigate tasks that do not have Workload Protection instrumentation (identified with {{< ui >}}Not Configured{{< /ui >}}). - 2. Click {{< ui >}}Configure{{< /ui >}} to enable Workload Protection on a task by manual or automatic installation. + 1. Hover over the shield icons in the {{< ui >}}Features{{< /ui >}} column to investigate tasks that do not have {{< prodname >}}Workload Protection{{< /prodname >}} instrumentation (identified with {{< ui >}}Not Configured{{< /ui >}}). + 2. Click {{< ui >}}Configure{{< /ui >}} to enable {{< prodname >}}Workload Protection{{< /prodname >}} on a task by manual or automatic installation. Manual installation instructions are provided for AWS console and CLI. - **Confirm cluster coverage:** - To confirm coverage parity across production, staging, and dev clusters, click a cluster name and select {{< ui >}}Filter by [cluster_name]{{< /ui >}}. diff --git a/hugo/content/en/security/workload_protection/secl_auth_guide.md b/hugo/content/en/security/workload_protection/secl_auth_guide.md index aa4773ec7d0..b1c0a35ca45 100644 --- a/hugo/content/en/security/workload_protection/secl_auth_guide.md +++ b/hugo/content/en/security/workload_protection/secl_auth_guide.md @@ -20,7 +20,7 @@ Datadog threat detection rules act as backend logic: they combine one or more Ag In summary, the Agent rule finds raw behavior and the detection rule turns it into a usable signal. -
    This guide describes how to create rule expressions manually, but Workload Protection also provides the Assisted rule creator wizard to walk you through creating the Agent and detections rules together. See Create the custom Agent and detection rules together.
    +
    This guide describes how to create rule expressions manually, but {{< prodname >}}Workload Protection{{< /prodname >}} also provides the Assisted rule creator wizard to walk you through creating the Agent and detections rules together. See Create the custom Agent and detection rules together.
    ### Agent expression syntax @@ -42,7 +42,7 @@ open.file.path == "/etc/shadow" && process.file.path not in ["/usr/sbin/vipw"] Here's a summary of the process: -1. Go to Workload Protection [Policies][1]. +1. Go to {{< prodname >}}Workload Protection{{< /prodname >}} [Policies][1]. 2. Click {{< ui >}}New Policy{{< /ui >}} to create a policy, or select an existing policy from the list to open it. 3. In the policy, click {{< ui >}}Add Agent Rule{{< /ui >}}, and then click {{< ui >}}Manual rule creator{{< /ui >}}. 4. In {{< ui >}}Define the agent expression{{< /ui >}}, enter your expression using the following steps. diff --git a/hugo/content/en/security/workload_protection/security_signals.md b/hugo/content/en/security/workload_protection/security_signals.md index 3d407131534..f26d1642d04 100644 --- a/hugo/content/en/security/workload_protection/security_signals.md +++ b/hugo/content/en/security/workload_protection/security_signals.md @@ -19,9 +19,9 @@ further_reading: text: "Learn more about security notifications" --- -[Workload Protection][9] security signals are created when Datadog detects a threat based on a security rule. View, search, filter, and investigate security signals in the [Signals Explorer][4], or configure [Notification Rules][1] to send signals to third-party tools. +[{{< prodname >}}Workload Protection{{< /prodname >}}][9] security signals are created when Datadog detects a threat based on a security rule. View, search, filter, and investigate security signals in the [Signals Explorer][4], or configure [Notification Rules][1] to send signals to third-party tools. -To modify security signals, you must have the `security_monitoring_signals_write` permission. See [Role Based Access Control][3] for more information about Datadog's default roles and granular role-based access control permissions available for Cloud Security. +To modify security signals, you must have the `security_monitoring_signals_write` permission. See [Role Based Access Control][3] for more information about Datadog's default roles and granular role-based access control permissions available for {{< prodname >}}Cloud Security{{< /prodname >}}. @@ -43,10 +43,10 @@ You can triage a signal by assigning it to a user for further investigation. The ## Create a case {{< site-region region="gov,gov2" >}} -
    Case Management is not supported for your selected Datadog site ({{< region-param key="dd_site_name" >}}).
    +
    {{< prodname >}}Case Management{{< /prodname >}} is not supported for your selected Datadog site ({{< region-param key="dd_site_name" >}}).
    {{< /site-region >}} -Use [Case Management][6] to track, triage, and investigate security signals. +Use [{{< prodname >}}Case Management{{< /prodname >}}][6] to track, triage, and investigate security signals. 1. On the [Signals Explorer][4], select a security signal. 2. On the signal side panel, click the {{< ui >}}Escalate Investigation{{< /ui >}} dropdown menu and select {{< ui >}}Create a case{{< /ui >}}. Alternatively, select {{< ui >}}Add to an existing case{{< /ui >}} to add the signal to an existing case. @@ -55,7 +55,7 @@ Use [Case Management][6] to track, triage, and investigate security signals. ## Declare an incident -Use [Incident Management][5] to create an incident for a security signal. +Use [{{< prodname >}}Incident Management{{< /prodname >}}][5] to create an incident for a security signal. 1. On the [Signals Explorer][4], select a security signal. 1. On the signal side panel under *Next Steps*, click the {{< ui >}}Show all actions{{< /ui >}} dropdown menu and select {{< ui >}}Declare incident{{< /ui >}}. @@ -65,7 +65,7 @@ Use [Incident Management][5] to create an incident for a security signal. ## Run a workflow -Use [Workflow Automation][8] to manually trigger a workflow for a security signal. See [Trigger a Workflow from a Security Signal][7] for more information. +Use [{{< prodname >}}Workflow Automation{{< /prodname >}}][8] to manually trigger a workflow for a security signal. See [Trigger a Workflow from a Security Signal][7] for more information. 1. On the [Signals Explorer][4], select a security signal. 2. On the signal side panel, click the {{< ui >}}Workflows{{< /ui >}} tab. diff --git a/hugo/content/en/security/workload_protection/setup/_index.md b/hugo/content/en/security/workload_protection/setup/_index.md index ff426cfbbb3..2d05dffa67e 100644 --- a/hugo/content/en/security/workload_protection/setup/_index.md +++ b/hugo/content/en/security/workload_protection/setup/_index.md @@ -3,30 +3,30 @@ title: Setting up Workload Protection disable_toc: false --- -To get started with Workload Protection, use the Workload Protection [{{< ui >}}Get Started{{< /ui >}}][1] steps in your Datadog account. +To get started with {{< prodname >}}Workload Protection{{< /prodname >}}, use the {{< prodname >}}Workload Protection{{< /prodname >}} [{{< ui >}}Get Started{{< /ui >}}][1] steps in your Datadog account.
    Activating Workload Protection requires the Org Management permission.
    ## Remote configuration -You can enable [Remote Configuration][3] for Workload Protection. +You can enable [Remote Configuration][3] for {{< prodname >}}Workload Protection{{< /prodname >}}. Remote Configuration can be used to: - Automatically stay up to date on the latest security detections - Block attackers and attacks -Remote Configuration can be set up using the Workload Protection [{{< ui >}}Get Started{{< /ui >}}][1] steps in your Datadog account. +Remote Configuration can be set up using the {{< prodname >}}Workload Protection{{< /prodname >}} [{{< ui >}}Get Started{{< /ui >}}][1] steps in your Datadog account.
    To enable Remote Configuration, ask your admin for the API Keys Write permission.
    ## Agent setup options for Workload Protection -Workload Protection supports **Agent-based-only deployments**. +{{< prodname >}}Workload Protection{{< /prodname >}} supports **Agent-based-only deployments**. ## Supported deployment types -The following table summarizes Workload Protection relative to deployment types. +The following table summarizes {{< prodname >}}Workload Protection{{< /prodname >}} relative to deployment types. | | Docker | Kubernetes | Linux | Amazon ECS/EKS | Windows | AWS Fargate ECS/EKS | AWS Account | Azure Account | GCP Account | Terraform | |------------------------|-----------|------------|-----------|----------------|-----------|---------------------|-------------|---------------|-------------|-----------| @@ -36,7 +36,7 @@ The following table summarizes Workload Protection relative to deployment types. ## Supported Linux distributions -Workload Protection supports the following Linux distributions: +{{< prodname >}}Workload Protection{{< /prodname >}} supports the following Linux distributions: | Linux Distributions | Supported Versions | |---------------------------------------------------------------|-------------------------| @@ -60,7 +60,7 @@ Workload Protection supports the following Linux distributions: ## Deploy the Agent -You can enable Workload Protection on the Datadog Agent using [multiple tools and systems][6]: +You can enable {{< prodname >}}Workload Protection{{< /prodname >}} on the Datadog Agent using [multiple tools and systems][6]: - [Kubernetes][8] - [Docker][9] @@ -70,7 +70,7 @@ You can enable Workload Protection on the Datadog Agent using [multiple tools an ## Workload Protection Agent variables -The Datadog Agent has several [environment variables][7] that can be enabled for Workload Protection. This article describes the purpose of each environment variable. +The Datadog Agent has several [environment variables][7] that can be enabled for {{< prodname >}}Workload Protection{{< /prodname >}}. This article describes the purpose of each environment variable. [1]: https://app.datadoghq.com/security/workload-protection/onboarding [2]: /account_management/rbac/permissions/ diff --git a/hugo/content/en/security/workload_protection/setup/agent/_index.md b/hugo/content/en/security/workload_protection/setup/agent/_index.md index 187f078a2f3..f1ec9880950 100644 --- a/hugo/content/en/security/workload_protection/setup/agent/_index.md +++ b/hugo/content/en/security/workload_protection/setup/agent/_index.md @@ -3,7 +3,7 @@ title: Deploying Workload Protection on the Agent type: multi-code-lang --- -Use the following instructions to enable Workload Protection on the Datadog Agent. +Use the following instructions to enable {{< prodname >}}Workload Protection{{< /prodname >}} on the Datadog Agent. {{< partial name="security-platform/WP-billing-note.html" >}} diff --git a/hugo/content/en/security/workload_protection/setup/agent/docker.md b/hugo/content/en/security/workload_protection/setup/agent/docker.md index d2422e0a739..21b2634560f 100644 --- a/hugo/content/en/security/workload_protection/setup/agent/docker.md +++ b/hugo/content/en/security/workload_protection/setup/agent/docker.md @@ -5,7 +5,7 @@ type: multi-code-lang code_lang_weight: 65 # a number that represents relative weight. --- -Use the following instructions to enable Workload Protection. +Use the following instructions to enable {{< prodname >}}Workload Protection{{< /prodname >}}. {{< partial name="security-platform/WP-billing-note.html" >}} diff --git a/hugo/content/en/security/workload_protection/setup/agent/ecs_ec2.md b/hugo/content/en/security/workload_protection/setup/agent/ecs_ec2.md index df740098819..743b0a47476 100644 --- a/hugo/content/en/security/workload_protection/setup/agent/ecs_ec2.md +++ b/hugo/content/en/security/workload_protection/setup/agent/ecs_ec2.md @@ -5,7 +5,7 @@ type: multi-code-lang code_lang_weight: 70 # a number that represents relative weight. --- -Use the following instructions to enable Workload Protection. +Use the following instructions to enable {{< prodname >}}Workload Protection{{< /prodname >}}. {{< partial name="security-platform/WP-billing-note.html" >}} diff --git a/hugo/content/en/security/workload_protection/setup/agent/kubernetes.md b/hugo/content/en/security/workload_protection/setup/agent/kubernetes.md index 6abf8bec964..5dc9cd41b99 100644 --- a/hugo/content/en/security/workload_protection/setup/agent/kubernetes.md +++ b/hugo/content/en/security/workload_protection/setup/agent/kubernetes.md @@ -5,7 +5,7 @@ type: multi-code-lang code_lang_weight: 60 # a number that represents relative weight. --- -Use the following instructions to enable Workload Protection. +Use the following instructions to enable {{< prodname >}}Workload Protection{{< /prodname >}}. {{< partial name="security-platform/WP-billing-note.html" >}} diff --git a/hugo/content/en/security/workload_protection/setup/agent/linux.md b/hugo/content/en/security/workload_protection/setup/agent/linux.md index f73e6f259b2..db0e5d2b92e 100644 --- a/hugo/content/en/security/workload_protection/setup/agent/linux.md +++ b/hugo/content/en/security/workload_protection/setup/agent/linux.md @@ -5,7 +5,7 @@ type: multi-code-lang code_lang_weight: 80 # a number that represents relative weight. --- -Use the following instructions to enable Workload Protection. +Use the following instructions to enable {{< prodname >}}Workload Protection{{< /prodname >}}. {{< partial name="security-platform/WP-billing-note.html" >}} diff --git a/hugo/content/en/security/workload_protection/setup/agent_variables.md b/hugo/content/en/security/workload_protection/setup/agent_variables.md index aa8151b2581..bb0b006f92c 100644 --- a/hugo/content/en/security/workload_protection/setup/agent_variables.md +++ b/hugo/content/en/security/workload_protection/setup/agent_variables.md @@ -2,7 +2,7 @@ title: Workload Protection Agent Variables --- -The Datadog Agent has several environment variables that can be enabled for Workload Protection. This article describes the purpose of each environment variable. +The Datadog Agent has several environment variables that can be enabled for {{< prodname >}}Workload Protection{{< /prodname >}}. This article describes the purpose of each environment variable. | Variable | Description | |-----------------------------------------------|------------------------------------------------------------------------------------------------------------------------| diff --git a/hugo/content/en/security/workload_protection/setup/ootb_rules.md b/hugo/content/en/security/workload_protection/setup/ootb_rules.md index 48d29c7ce33..0c67eca29bc 100644 --- a/hugo/content/en/security/workload_protection/setup/ootb_rules.md +++ b/hugo/content/en/security/workload_protection/setup/ootb_rules.md @@ -2,8 +2,8 @@ title: OOTB Rules --- -Datadog provides out-of-the-box (OOTB) threat detection rules to flag attacker techniques so you can immediately take steps to remediate. Datadog continuously develops new default rules, which are automatically imported into your account, your Workload Protection library, and the Agent, depending on your configuration. +Datadog provides out-of-the-box (OOTB) threat detection rules to flag attacker techniques so you can immediately take steps to remediate. Datadog continuously develops new default rules, which are automatically imported into your account, your {{< prodname >}}Workload Protection{{< /prodname >}} library, and the Agent, depending on your configuration. -For a list of all of the OOTB Workload Protection rules, see the Workload Protection button in the [{{< ui >}}OOTB Rules{{< /ui >}} in the {{< ui >}}Security Overview{{< /ui >}}][1]. +For a list of all of the OOTB Workload Protection rules, see the {{< prodname >}}Workload Protection{{< /prodname >}} button in the [{{< ui >}}OOTB Rules{{< /ui >}} in the {{< ui >}}Security Overview{{< /ui >}}][1]. [1]: /security/default_rules/?category=cat-csm-threats#all \ No newline at end of file diff --git a/hugo/content/en/security/workload_protection/supported_linux_distributions.md b/hugo/content/en/security/workload_protection/supported_linux_distributions.md index 55d9eee2284..72d2faf7c2e 100644 --- a/hugo/content/en/security/workload_protection/supported_linux_distributions.md +++ b/hugo/content/en/security/workload_protection/supported_linux_distributions.md @@ -4,7 +4,7 @@ aliases: - /security/threats/supported_linux_distributions/ --- -Workload Protection supports the following Linux distributions: +{{< prodname >}}Workload Protection{{< /prodname >}} supports the following Linux distributions: | Linux Distributions | Supported Versions | |---------------------------------------------------------------|-------------------------------| diff --git a/hugo/content/en/security/workload_protection/troubleshooting/threats.md b/hugo/content/en/security/workload_protection/troubleshooting/threats.md index c7e59a4b44a..5cca1f37c15 100644 --- a/hugo/content/en/security/workload_protection/troubleshooting/threats.md +++ b/hugo/content/en/security/workload_protection/troubleshooting/threats.md @@ -2,7 +2,7 @@ title: Troubleshooting Workload Protection --- -If you experience issues with Workload Protection, use the following troubleshooting guidelines. If you need further assistance, contact [Datadog support][1]. +If you experience issues with {{< prodname >}}Workload Protection{{< /prodname >}}, use the following troubleshooting guidelines. If you need further assistance, contact [Datadog support][1]. ## Security Agent flare @@ -22,7 +22,7 @@ If you don't have a case ID, just enter your email address used to login in Data ## Agent Self tests -In order to ensure that the communication between the `security-agent` and the `system-probe` is working as expected and that Workload Protection is able to detect system events, you can manually trigger self tests by running the following command: +In order to ensure that the communication between the `security-agent` and the `system-probe` is working as expected and that {{< prodname >}}Workload Protection{{< /prodname >}} is able to detect system events, you can manually trigger self tests by running the following command: | Platform | Command | | -------- | ------- | @@ -43,18 +43,18 @@ You can now see events coming from the `runtime-security-agent` in the {{< ui >} ## Compatibility with custom Kubernetes network plugins -The network based detections of Workload Protection rely on the traffic control sub-system of the Linux kernel. This sub-system is known to introduce race conditions if multiple vendors try to insert, replace, or delete filters on the "clsact" ingress qdisc. Follow the checklist below to ensure that Workload Protection is properly configured: +The network based detections of {{< prodname >}}Workload Protection{{< /prodname >}} rely on the traffic control sub-system of the Linux kernel. This sub-system is known to introduce race conditions if multiple vendors try to insert, replace, or delete filters on the "clsact" ingress qdisc. Follow the checklist below to ensure that {{< prodname >}}Workload Protection{{< /prodname >}} is properly configured: * Check if your vendor leverages eBPF traffic control classifiers. If they do not, you can ignore this paragraph. * Check if your vendor returns TC_ACT_OK or TC_ACT_UNSPEC after granting access to a network packet. If they return TC_ACT_UNSPEC, you can ignore this paragraph. * Check which priority your vendor attaches their eBPF classifiers to: - * If they use priority 1, Workload Protection network detections do not work inside your containers. + * If they use priority 1, {{< prodname >}}Workload Protection{{< /prodname >}} network detections do not work inside your containers. * If they use priority 2 to 10, make sure to configure `runtime_security_config.network.classifier_priority` to a number strictly below the priority chosen by your vendor. * If they use priority 11 or higher, you can ignore this paragraph. For example, there is a known race with Cilium 1.9 and lower with the Datadog Agent (version 7.36 to 7.39.1, 7.39.2 excluded) that may happen when a new pod is started. The race can lead to loss of connectivity inside the pod, depending on how Cilium is configured. -Ultimately, if the Datadog Agent or your third party vendors cannot be configured to prevent the issue from happening, you should disable the network based detections of Workload Protection by following the steps below: +Ultimately, if the Datadog Agent or your third party vendors cannot be configured to prevent the issue from happening, you should disable the network based detections of {{< prodname >}}Workload Protection{{< /prodname >}} by following the steps below: * Add the following parameter to your `system-probe.yaml` configuration file on host based installations: ```yaml @@ -77,7 +77,7 @@ DD_RUNTIME_SECURITY_CONFIG_NETWORK_ENABLED=false ## Troubleshooting Kubernetes remote session or pod admission disruptions -Workload Protection collects Kubernetes user identities and enriches your Workload Protection events with the context necessary to differentiate remote accesses to your infrastructure from the activity generated by your workloads. This integration relies on a [Kubernetes Mutating Webhook](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) to instrument `kubectl exec` sessions. In case this instrumentation causes disruptions in the admission of pods or in the creation of `kubectl exec` sessions, follow the guide below to disable this feature. +{{< prodname >}}Workload Protection{{< /prodname >}} collects Kubernetes user identities and enriches your {{< prodname >}}Workload Protection{{< /prodname >}} events with the context necessary to differentiate remote accesses to your infrastructure from the activity generated by your workloads. This integration relies on a [Kubernetes Mutating Webhook](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) to instrument `kubectl exec` sessions. In case this instrumentation causes disruptions in the admission of pods or in the creation of `kubectl exec` sessions, follow the guide below to disable this feature. {{< tabs >}} @@ -150,7 +150,7 @@ Workload Protection collects Kubernetes user identities and enriches your Worklo ## Disable Workload Protection -To disable Workload Protection, follow the steps for your Agent platform. +To disable {{< prodname >}}Workload Protection{{< /prodname >}}, follow the steps for your Agent platform. ### Helm diff --git a/hugo/content/en/security/workload_protection/workload_security_rules/_index.md b/hugo/content/en/security/workload_protection/workload_security_rules/_index.md index c17721e739a..0e14087c3ca 100644 --- a/hugo/content/en/security/workload_protection/workload_security_rules/_index.md +++ b/hugo/content/en/security/workload_protection/workload_security_rules/_index.md @@ -6,7 +6,7 @@ aliases: - /security/threats/workload_security_rules --- -This topic explains how Workload Protection actively monitors system activity and evaluates it against a set of out-of-the-box (OOTB) rules to detect suspicious behavior. +This topic explains how {{< prodname >}}Workload Protection{{< /prodname >}} actively monitors system activity and evaluates it against a set of out-of-the-box (OOTB) rules to detect suspicious behavior. ## Proactively block threats with Active Protection @@ -16,9 +16,9 @@ By default, all OOTB Agent crypto mining threat detection rules are enabled and ## Workload Protection rules construction -Workload Protection rules consist of two different components: Agent rules and threat detection rules. +{{< prodname >}}Workload Protection{{< /prodname >}} rules consist of two different components: Agent rules and threat detection rules. -- **Agent rules:** [Agent rules][9] are evaluated on the Agent host. Workload Protection first evaluates activity within the Datadog Agent against Agent expressions to decide what activity to collect. Agent expressions use Datadog's [Security Language (SECL)][2].

    +- **Agent rules:** [Agent rules][9] are evaluated on the Agent host. {{< prodname >}}Workload Protection{{< /prodname >}} first evaluates activity within the Datadog Agent against Agent expressions to decide what activity to collect. Agent expressions use Datadog's [Security Language (SECL)][2].

    For example, here is the *Agent rule* expression `cryptominer_args`: @@ -46,7 +46,7 @@ Workload Protection rules consist of two different components: Agent rules and t ### Workload Protection rules pipeline -Workload Protection uses the following pipeline when evaluating events: +{{< prodname >}}Workload Protection{{< /prodname >}} uses the following pipeline when evaluating events: 1. The Agent rules evaluate system activity on the Agent host. 2. When activity matches an Agent rule expression, the Agent generates a detection event and passes it to the Datadog backend. @@ -60,7 +60,7 @@ The following diagram illustrates this pipeline: ### Saving resources by design -Workload Protection detection rules are complex, correlating several datapoints, sometimes across different hosts, and including third party data. This complexity would result in considerable compute resource demands on the Agent host if all rules were evaluated there. +{{< prodname >}}Workload Protection{{< /prodname >}} detection rules are complex, correlating several datapoints, sometimes across different hosts, and including third party data. This complexity would result in considerable compute resource demands on the Agent host if all rules were evaluated there. Datadog solves this problem by keeping the Agent lightweight with only a few rules, and processes most rules using the threat detection rules on the Datadog backend. @@ -81,7 +81,7 @@ For a detailed explanation, see [Workload Protection Detection Rules][11]. Agent rules contain [Agent expressions](#agent-expressions) that determine which activities the Agent collects. A full set of Agent rules is called a policy. Datadog provides you with several [out-of-the-box Agent rules][6] powered by the default Agent policy. -With [Workload Protection][7] enabled, you automatically receive new and updated Workload Protection Agent rules when they're released. These bundled Agent rules are used in the [default detection rules][1]. +With [{{< prodname >}}Workload Protection{{< /prodname >}}][7] enabled, you automatically receive new and updated Workload Protection Agent rules when they're released. These bundled Agent rules are used in the [default detection rules][1]. @@ -93,7 +93,7 @@ Agent expressions use [Datadog's Security Language (SECL)][2] to define behavior To detect when the `passwd` command is executed, there are a few attributes to note. -On most Linux distributions, the `passwd` utility is installed at `/usr/bin/passwd`. Execution events include `exec`, `execve`, `fork`, and other system calls. In the Workload Protection environment, all of these events are identified by the `exec` symbol. +On most Linux distributions, the `passwd` utility is installed at `/usr/bin/passwd`. Execution events include `exec`, `execve`, `fork`, and other system calls. In the {{< prodname >}}Workload Protection{{< /prodname >}} environment, all of these events are identified by the `exec` symbol. Putting it all together, the rule expression is `exec.file.path == "/usr/bin/passwd"`. @@ -105,7 +105,7 @@ To detect when a PHP or Nginx process launches Bash, there are a few attributes On most Linux distributions, Bash is installed at `/usr/bin/bash`. As in the previous example, to detect execution, include `exec.file.path == "/usr/bin/bash"` in your rule. This ensures the rule is accounting for the execution of Bash, and also Bash as a child process of PHP or Nginx. -A process ancestor's filename in Workload Protection is an attribute with the symbol `process.ancestors.file.name`. To check if the ancestor is Nginx, add `process.ancestors.file.name == "nginx"`. Since PHP runs as multiple processes, use a wildcard to expand the rule to any process with the prefix `php`. To check if the ancestor is a PHP process, add `process.ancestors.file.name =~ "php*"`. +A process ancestor's filename in {{< prodname >}}Workload Protection{{< /prodname >}} is an attribute with the symbol `process.ancestors.file.name`. To check if the ancestor is Nginx, add `process.ancestors.file.name == "nginx"`. Since PHP runs as multiple processes, use a wildcard to expand the rule to any process with the prefix `php`. To check if the ancestor is a PHP process, add `process.ancestors.file.name =~ "php*"`. Putting it all together, the rule expression is `exec.file.path == "/usr/bin/bash" && (process.ancestors.file.name == "nginx" || process.ancestors.file.name =~ "php*")`. diff --git a/hugo/content/en/security/workload_protection/workload_security_rules/custom_rules.md b/hugo/content/en/security/workload_protection/workload_security_rules/custom_rules.md index 60b156df87c..8781bcf7511 100644 --- a/hugo/content/en/security/workload_protection/workload_security_rules/custom_rules.md +++ b/hugo/content/en/security/workload_protection/workload_security_rules/custom_rules.md @@ -4,7 +4,7 @@ aliases: - /security/threats/workload_security_rules/custom_rules --- -This topic explains how to create custom Datadog Agent policies and detection rules for [Workload Protection][8]. +This topic explains how to create custom Datadog Agent policies and detection rules for [{{< prodname >}}Workload Protection{{< /prodname >}}][8]. In addition to the out of the box (OOTB) [default Agent and detection rules][7], you can write custom Agent and detection rules. Custom rules help to detect events Datadog is not detecting with its OOTB rules. @@ -211,7 +211,7 @@ After you upload the new default policy file to the Agent, navigate to the [{{< 1. In {{< ui >}}Detection rule types{{< /ui >}}, select {{< ui >}}Workload Security{{< /ui >}}. 2. Select a detection method such as {{< ui >}}Threshold{{< /ui >}} or {{< ui >}}New Value{{< /ui >}}. 3. **Define search queries:** - 1. Configure a new Workload Protection rule. A rule can have multiple rule cases combined with Boolean logic, for example `(||, &&)`. You can also set the counter, group by, and roll-up window. + 1. Configure a new {{< prodname >}}Workload Protection{{< /prodname >}} rule. A rule can have multiple rule cases combined with Boolean logic, for example `(||, &&)`. You can also set the counter, group by, and roll-up window. {{< img src="security/cws/workload_security_rules/define_runtime_expression2.png" alt="Adding a rule to the search queries field" >}} diff --git a/hugo/content/en/serverless/aws_lambda/configuration.md b/hugo/content/en/serverless/aws_lambda/configuration.md index 1f1653700b0..28f281a5ca0 100644 --- a/hugo/content/en/serverless/aws_lambda/configuration.md +++ b/hugo/content/en/serverless/aws_lambda/configuration.md @@ -70,7 +70,7 @@ To enable threat monitoring, add the following environment variables to your dep Redeploy the function and invoke it. After a few minutes, it appears in [AAP views][49]. -To see App and API Protection threat detection in action, send known attack patterns to your application. For example, send an HTTP header with value `acunetix-product` to trigger a [security scanner attack][44] attempt: +To see {{< prodname >}}App and API Protection{{< /prodname >}} threat detection in action, send known attack patterns to your application. For example, send an HTTP header with value `acunetix-product` to trigger a [security scanner attack][44] attempt: ```sh curl -H 'My-AAP-Test-Header: acunetix-product' https:/// ``` @@ -357,7 +357,7 @@ For renaming downstream services, see `DD_SERVICE_MAPPING` in the [tracer's conf ## Configure the Datadog SDK -To see what libraries and frameworks are automatically instrumented by the Datadog APM client, see [Compatibility Requirements for APM][15]. To instrument custom applications, see Datadog's APM guide for [custom instrumentation][16]. +To see what libraries and frameworks are automatically instrumented by the {{< prodname >}}Datadog APM{{< /prodname >}} client, see [Compatibility Requirements for APM][15]. To instrument custom applications, see Datadog's APM guide for [custom instrumentation][16]. ## Select sampling rates for ingesting APM spans @@ -644,7 +644,7 @@ Datadog automatically injects the trace context into outgoing AWS SDK requests a ## Merge X-Ray and Datadog traces -For AWS managed services that Datadog APM doesn't yet instrument (such as AppSync), you can enable the [Datadog X-Ray integration][34] and merge the X-Ray traces with the Datadog native traces. See [additional details][35]. +For AWS managed services that {{< prodname >}}Datadog APM{{< /prodname >}} doesn't yet instrument (such as AppSync), you can enable the [Datadog X-Ray integration][34] and merge the X-Ray traces with the Datadog native traces. See [additional details][35]. ## Enable AWS Lambda code signing diff --git a/hugo/content/en/serverless/aws_lambda/distributed_tracing.md b/hugo/content/en/serverless/aws_lambda/distributed_tracing.md index bce4bb2780e..06dcdac6397 100644 --- a/hugo/content/en/serverless/aws_lambda/distributed_tracing.md +++ b/hugo/content/en/serverless/aws_lambda/distributed_tracing.md @@ -180,12 +180,12 @@ The Continuous Profiler works by spawning a thread that periodically wakes up an ### Use cases -Datadog recommends using only the Datadog APM trace library (`dd-trace`), but in some advanced situations users can combine Datadog tracing and AWS X-Ray using trace merging. Trace merging is available for Node.js and Python AWS Lambda functions. If you aren't sure which SDK to use, read about [choosing your SDK][17]. +Datadog recommends using only the {{< prodname >}}Datadog APM{{< /prodname >}} trace library (`dd-trace`), but in some advanced situations users can combine Datadog tracing and AWS X-Ray using trace merging. Trace merging is available for Node.js and Python AWS Lambda functions. If you aren't sure which SDK to use, read about [choosing your SDK][17].
    AWS Step Functions tracing is supported natively by Datadog and no longer requires X-Ray. See Serverless Monitoring for AWS Step Functions and Merge Step Functions and Lambda Traces.
    There are two primary reasons for instrumenting both `dd-trace` and AWS X-Ray tracing libraries: -- In an AWS serverless environment, you are already tracing your Lambda functions with `dd-trace`, you require AWS X-Ray active tracing for an AWS managed service that Datadog APM doesn't yet instrument (such as AppSync), and you want to visualize the `dd-trace` and AWS X-Ray spans in one single trace. +- In an AWS serverless environment, you are already tracing your Lambda functions with `dd-trace`, you require AWS X-Ray active tracing for an AWS managed service that {{< prodname >}}Datadog APM{{< /prodname >}} doesn't yet instrument (such as AppSync), and you want to visualize the `dd-trace` and AWS X-Ray spans in one single trace. - In a hybrid environment with both Lambda functions and hosts, `dd-trace` instruments your hosts, AWS X-Ray instruments your Lambda functions, and you want to visualize connected traces for transactions across Lambda functions and hosts. **Note:** This may result in higher usage bills. X-Ray spans continue to be available in your merged traces after 2-5 minutes. In many cases, Datadog recommends only using a single SDK. Learn more about [choosing your SDK][17]. @@ -199,10 +199,10 @@ You can find setup instructions for each of the above use cases below: AWS X-Ray provides both a backend AWS service (AWS X-Ray active tracing) and a set of client libraries. [Enabling the backend AWS service alone in the Lambda console][18] gives you `Initialization` and `Invocation` spans for your AWS Lambda functions. You can also enable AWS X-Ray active tracing from the API Gateway and Step Function consoles. -Both the AWS X-Ray SDK and Datadog APM client libraries (`dd-trace`) add metadata and spans for downstream calls by accessing the function directly. Assuming you are using `dd-trace` to trace at the handler level, your setup should be similar to the following: +Both the AWS X-Ray SDK and {{< prodname >}}Datadog APM{{< /prodname >}} client libraries (`dd-trace`) add metadata and spans for downstream calls by accessing the function directly. Assuming you are using `dd-trace` to trace at the handler level, your setup should be similar to the following: 1. You have enabled [AWS X-Ray active tracing][18] on your Lambda functions from the AWS Lambda console and our [AWS X-Ray integration within Datadog][19]. -2. You have instrumented your Lambda functions with Datadog APM (`dd-trace`) by following the [installation instructions for your Lambda runtime][5]. +2. You have instrumented your Lambda functions with {{< prodname >}}Datadog APM{{< /prodname >}} (`dd-trace`) by following the [installation instructions for your Lambda runtime][5]. 3. Third-party libraries are automatically patched by `dd-trace`, so the AWS X-Ray client libraries do not need to be installed. 4. Set the `DD_MERGE_XRAY_TRACES` environment variable to `true` on your Lambda functions to merge the X-Ray and `dd-trace` traces (`DD_MERGE_DATADOG_XRAY_TRACES` in Ruby). diff --git a/hugo/content/en/serverless/aws_lambda/instrumentation/ruby.md b/hugo/content/en/serverless/aws_lambda/instrumentation/ruby.md index 51a3ef78e1c..da526848cd8 100644 --- a/hugo/content/en/serverless/aws_lambda/instrumentation/ruby.md +++ b/hugo/content/en/serverless/aws_lambda/instrumentation/ruby.md @@ -410,7 +410,7 @@ The [`lambda-datadog`][1] Terraform module wraps the [`aws_lambda_function`][2] gem 'datadog-lambda' ``` - `datadog` contains native extensions that must be compiled for Amazon Linux to work with AWS Lambda. Datadog therefore recommends that you build and deploy your Lambda as a container image. If your function cannot be deployed as a container image and you would like to use Datadog APM, Datadog recommends installing the Lambda Library as a layer instead of as a gem. + `datadog` contains native extensions that must be compiled for Amazon Linux to work with AWS Lambda. Datadog therefore recommends that you build and deploy your Lambda as a container image. If your function cannot be deployed as a container image and you would like to use {{< prodname >}}Datadog APM{{< /prodname >}}, Datadog recommends installing the Lambda Library as a layer instead of as a gem. Install `gcc`, `gmp-devel`, and `make` prior to running `bundle install` in your function's Dockerfile to ensure that the native extensions can be successfully compiled. @@ -542,7 +542,7 @@ def some_operation() end ``` -For more information on custom metric submission, see [Serverless Custom Metrics][7]. For additional details on custom instrumentation, see the Datadog APM documentation for [custom instrumentation][8]. +For more information on custom metric submission, see [Serverless Custom Metrics][7]. For additional details on custom instrumentation, see the {{< prodname >}}Datadog APM{{< /prodname >}} documentation for [custom instrumentation][8]. ## Further Reading diff --git a/hugo/content/en/serverless/aws_lambda/logs.md b/hugo/content/en/serverless/aws_lambda/logs.md index 568a3f43581..42911070d61 100644 --- a/hugo/content/en/serverless/aws_lambda/logs.md +++ b/hugo/content/en/serverless/aws_lambda/logs.md @@ -109,7 +109,7 @@ Set the environment variable `DD_SERVERLESS_LOGS_ENABLED` to `false` on your Lam {{% /tab %}} {{< /tabs >}} -For more information, see [Log Management][47]. +For more information, see [{{< prodname >}}Log Management{{< /prodname >}}][47]. ### Filter or scrub information from logs diff --git a/hugo/content/en/serverless/azure_app_service/windows_code.md b/hugo/content/en/serverless/azure_app_service/windows_code.md index 3d99d577e74..afe92001b98 100644 --- a/hugo/content/en/serverless/azure_app_service/windows_code.md +++ b/hugo/content/en/serverless/azure_app_service/windows_code.md @@ -347,7 +347,7 @@ See the [{{< ui >}}Manual{{< /ui >}} tab](?tab=manual#instrumentation) for descr 4. Stop your application by clicking {{< ui >}}Stop{{< /ui >}}.
    You must stop your application to successfully install Datadog.
    -5. In your Azure Portal, navigate to the {{< ui >}}Extensions{{< /ui >}} page and select the Datadog APM extension. +5. In your Azure Portal, navigate to the {{< ui >}}Extensions{{< /ui >}} page and select the {{< prodname >}}Datadog APM{{< /prodname >}} extension. {{< img src="infrastructure/serverless/azure_app_services/choose_extension.png" alt="Example of Extensions page in Azure portal, showing .NET Datadog APM extension." style="width:100%;" >}} diff --git a/hugo/content/en/serverless/azure_container_apps/_index.mdoc.md b/hugo/content/en/serverless/azure_container_apps/_index.mdoc.md index 06fe0af0b3c..52867564006 100644 --- a/hugo/content/en/serverless/azure_container_apps/_index.mdoc.md +++ b/hugo/content/en/serverless/azure_container_apps/_index.mdoc.md @@ -34,7 +34,7 @@ First, [set up the Azure Integration](/integrations/azure/) to collect metrics a Then, choose one of two paths to instrument your application with the `serverless-init` Agent: -- **[Set up with agentic onboarding](#set-up-with-agentic-onboarding)**: An AI assistant instruments your service for you, using the AI Setup CLI or the Datadog MCP Server. +- **[Set up with agentic onboarding](#set-up-with-agentic-onboarding)**: An AI assistant instruments your service for you, using the AI Setup CLI or the {{< prodname >}}Datadog MCP Server{{< /prodname >}}. - **[Set up with manual instrumentation][3]**: Instrument your service yourself, with per-runtime steps for the in-container and sidecar approaches. ## Set up with agentic onboarding @@ -60,7 +60,7 @@ Omit `--product` to run interactively, or add `--site` to target your Datadog si {% /tab %} {% tab label="MCP server" %} -Use the Datadog MCP Server's [`serverless_onboarding`][2] tool. After you connect, try a prompt like: +Use the {{< prodname >}}Datadog MCP Server{{< /prodname >}}'s [`serverless_onboarding`][2] tool. After you connect, try a prompt like: ``` Help me monitor my Azure Container Apps services with Datadog diff --git a/hugo/content/en/serverless/azure_database_messaging_services/_index.md b/hugo/content/en/serverless/azure_database_messaging_services/_index.md index 173fd14482d..00b93733657 100644 --- a/hugo/content/en/serverless/azure_database_messaging_services/_index.md +++ b/hugo/content/en/serverless/azure_database_messaging_services/_index.md @@ -4,7 +4,7 @@ title: Azure Database and Messaging Services ## Overview -Datadog APM uses **inferred spans** to collect traces and trace metrics from Azure Cosmos DB, Event Hubs, and Service Bus. Inferred spans appear automatically in flame graph and waterfall views for Datadog-instrumented services running on Azure. No additional configuration is required. To set up instrumentation for Azure Serverless workloads, see [Serverless Monitoring][1]. +{{< prodname >}}Datadog APM{{< /prodname >}} uses **inferred spans** to collect traces and trace metrics from Azure Cosmos DB, Event Hubs, and Service Bus. Inferred spans appear automatically in flame graph and waterfall views for Datadog-instrumented services running on Azure. No additional configuration is required. To set up instrumentation for Azure Serverless workloads, see [Serverless Monitoring][1]. {{< card-grid card_width="170px" >}} {{< image-card href="/serverless/azure_database_messaging_services/azure_cosmosdb/" src="integrations_logos/azure_cosmosdb.png" alt="azure_cosmosdb" >}} diff --git a/hugo/content/en/serverless/azure_database_messaging_services/azure_cosmosdb.md b/hugo/content/en/serverless/azure_database_messaging_services/azure_cosmosdb.md index 759a14cc4ed..65dba7da43d 100644 --- a/hugo/content/en/serverless/azure_database_messaging_services/azure_cosmosdb.md +++ b/hugo/content/en/serverless/azure_database_messaging_services/azure_cosmosdb.md @@ -4,7 +4,7 @@ title: Serverless Monitoring for Azure Cosmos DB ## Overview -Datadog APM uses **inferred spans** to collect traces and trace metrics from Azure Cosmos DB CRUD operations. These spans appear directly in flame graph and waterfall views. Cosmos DB distributed tracing requires no additional setup beyond existing instrumentation for APM users. +{{< prodname >}}Datadog APM{{< /prodname >}} uses **inferred spans** to collect traces and trace metrics from Azure Cosmos DB CRUD operations. These spans appear directly in flame graph and waterfall views. Cosmos DB distributed tracing requires no additional setup beyond existing instrumentation for APM users. {{< img src="serverless/azure_database_messaging/azure_cosmosdb/azure_cosmos_flame_graph.png" alt="Datadog flame graph displaying Cosmos DB database spans alongside API and queue-processing spans in a distributed .NET application." style="width:100%;">}} diff --git a/hugo/content/en/serverless/azure_database_messaging_services/azure_event_hubs.md b/hugo/content/en/serverless/azure_database_messaging_services/azure_event_hubs.md index 9760dea8712..19ac96d45ce 100644 --- a/hugo/content/en/serverless/azure_database_messaging_services/azure_event_hubs.md +++ b/hugo/content/en/serverless/azure_database_messaging_services/azure_event_hubs.md @@ -4,7 +4,7 @@ title: Serverless Monitoring for Azure Event Hubs ## Overview -Datadog APM uses **inferred spans** to collect traces and trace metrics from Azure Event Hubs. These spans are generated by the Datadog tracers SDKs and appear directly in flame graph and waterfall views. +{{< prodname >}}Datadog APM{{< /prodname >}} uses **inferred spans** to collect traces and trace metrics from Azure Event Hubs. These spans are generated by the Datadog tracers SDKs and appear directly in flame graph and waterfall views. Python and Node.js support producers; .NET supports both producers and consumers. Event Hubs distributed tracing requires no additional setup beyond existing instrumentation for APM users. diff --git a/hugo/content/en/serverless/azure_database_messaging_services/azure_service_bus.md b/hugo/content/en/serverless/azure_database_messaging_services/azure_service_bus.md index a39d83683a7..afab32540e7 100644 --- a/hugo/content/en/serverless/azure_database_messaging_services/azure_service_bus.md +++ b/hugo/content/en/serverless/azure_database_messaging_services/azure_service_bus.md @@ -4,7 +4,7 @@ title: Serverless Monitoring for Azure Service Bus ## Overview -Datadog APM uses **inferred spans** to collect traces and trace metrics from Azure Service Bus. These spans appear directly in flame graph and waterfall views. +{{< prodname >}}Datadog APM{{< /prodname >}} uses **inferred spans** to collect traces and trace metrics from Azure Service Bus. These spans appear directly in flame graph and waterfall views. For Python and Node.js, Datadog traces Service Bus producers and Azure Functions consumers. .NET supports full producer and consumer tracing. Service Bus distributed tracing requires no additional setup beyond existing instrumentation for APM users. diff --git a/hugo/content/en/serverless/azure_functions/dotnet_extension.md b/hugo/content/en/serverless/azure_functions/dotnet_extension.md index 407ef7b3d61..a457b6c818f 100644 --- a/hugo/content/en/serverless/azure_functions/dotnet_extension.md +++ b/hugo/content/en/serverless/azure_functions/dotnet_extension.md @@ -239,7 +239,7 @@ az webapp deployment slot swap --resource-group --name }}Overview{{< /ui >}} page and clicking {{< ui >}}Stop{{< /ui >}}.
    You must stop the slot before installing the extension.
    -5. Navigate to {{< ui >}}Extensions{{< /ui >}} and add the Datadog APM extension for your runtime. +5. Navigate to {{< ui >}}Extensions{{< /ui >}} and add the {{< prodname >}}Datadog APM{{< /prodname >}} extension for your runtime. 6. **Start the slot** by clicking {{< ui >}}Start{{< /ui >}} on the slot's {{< ui >}}Overview{{< /ui >}} page. diff --git a/hugo/content/en/serverless/guide/datadog_forwarder_node.md b/hugo/content/en/serverless/guide/datadog_forwarder_node.md index 4b6f6bb2a8a..a9c154c39df 100644 --- a/hugo/content/en/serverless/guide/datadog_forwarder_node.md +++ b/hugo/content/en/serverless/guide/datadog_forwarder_node.md @@ -376,7 +376,7 @@ exports.handler = async (event) => { }; ``` -For more information on custom metric submission, see [Serverless Custom Metrics][4]. For additional details on custom instrumentation, see the Datadog APM documentation for [custom instrumentation][5]. +For more information on custom metric submission, see [Serverless Custom Metrics][4]. For additional details on custom instrumentation, see the {{< prodname >}}Datadog APM{{< /prodname >}} documentation for [custom instrumentation][5]. ## Further Reading diff --git a/hugo/content/en/serverless/guide/datadog_forwarder_python.md b/hugo/content/en/serverless/guide/datadog_forwarder_python.md index f07a2e48644..7ef0179e000 100644 --- a/hugo/content/en/serverless/guide/datadog_forwarder_python.md +++ b/hugo/content/en/serverless/guide/datadog_forwarder_python.md @@ -429,7 +429,7 @@ def get_message(): return 'Hello from serverless!' ``` -For more information on custom metric submission, see [here][4]. For additional details on custom instrumentation, see the Datadog APM documentation for [custom instrumentation][5]. +For more information on custom metric submission, see [here][4]. For additional details on custom instrumentation, see the {{< prodname >}}Datadog APM{{< /prodname >}} documentation for [custom instrumentation][5]. ## Further Reading diff --git a/hugo/content/en/serverless/guide/datadog_forwarder_ruby.md b/hugo/content/en/serverless/guide/datadog_forwarder_ruby.md index 625bca3d67b..1eae833b049 100644 --- a/hugo/content/en/serverless/guide/datadog_forwarder_ruby.md +++ b/hugo/content/en/serverless/guide/datadog_forwarder_ruby.md @@ -130,7 +130,7 @@ gem 'datadog-lambda' gem 'ddtrace' ``` -`ddtrace` contains native extensions that must be compiled for Amazon Linux to work with AWS Lambda. Datadog therefore recommends that you build and deploy your Lambda as a container image. If your function cannot be deployed as a container image and you would like to use Datadog APM, Datadog recommends installing the Lambda Library as a layer instead of as a gem. +`ddtrace` contains native extensions that must be compiled for Amazon Linux to work with AWS Lambda. Datadog therefore recommends that you build and deploy your Lambda as a container image. If your function cannot be deployed as a container image and you would like to use {{< prodname >}}Datadog APM{{< /prodname >}}, Datadog recommends installing the Lambda Library as a layer instead of as a gem. Install `gcc`, `gmp-devel`, and `make` prior to running `bundle install` in your function's Dockerfile to ensure that the native extensions can be successfully compiled. @@ -230,7 +230,7 @@ def some_operation() end ``` -For more information on custom metric submission, see [Serverless Custom Metrics][4]. For additional details on custom instrumentation, see the Datadog APM documentation for [custom instrumentation][5]. +For more information on custom metric submission, see [Serverless Custom Metrics][4]. For additional details on custom instrumentation, see the {{< prodname >}}Datadog APM{{< /prodname >}} documentation for [custom instrumentation][5]. ## Further Reading diff --git a/hugo/content/en/serverless/logic_apps/installation.md b/hugo/content/en/serverless/logic_apps/installation.md index afe2a5eb453..36f9ca77636 100644 --- a/hugo/content/en/serverless/logic_apps/installation.md +++ b/hugo/content/en/serverless/logic_apps/installation.md @@ -49,7 +49,7 @@ After configuring log forwarding, invoke your Logic App workflow a couple of tim ### 4. Verify traces in Datadog -Use Live Search in Datadog APM to verify that traces are being received: +Use Live Search in {{< prodname >}}Datadog APM{{< /prodname >}} to verify that traces are being received: 1. Navigate to [APM > Traces][4] in Datadog 2. Use the query `operation_name:azure.logicapps` to filter for Logic Apps traces diff --git a/hugo/content/en/service_level_objectives/guide/slo-checklist.md b/hugo/content/en/service_level_objectives/guide/slo-checklist.md index 421b459533b..411c846edad 100644 --- a/hugo/content/en/service_level_objectives/guide/slo-checklist.md +++ b/hugo/content/en/service_level_objectives/guide/slo-checklist.md @@ -102,7 +102,7 @@ _Example: the latency of all user requests should be less than 250 ms 99% of the 1. [Custom metrics][3] (for example, counters) 2. [Integration metrics][4] (for example, load balancer, http requests) -3. [Datadog APM][5] (for example, errors, latency on services and resources) +3. [{{< prodname >}}Datadog APM{{< /prodname >}}][5] (for example, errors, latency on services and resources) 4. [Datadog Logs][6] (for example, metrics generated from logs for a count of particular occurrence) ## Set your target objective and time window diff --git a/hugo/content/en/session_replay/_index.md b/hugo/content/en/session_replay/_index.md index 9880bec07bc..5f38437e865 100644 --- a/hugo/content/en/session_replay/_index.md +++ b/hugo/content/en/session_replay/_index.md @@ -38,7 +38,7 @@ further_reading: ## Overview -Session Replay expands your user experience monitoring by allowing you to capture and visually replay the web browsing or mobile app experience of your users. Session Replay is available in both [RUM][1] and [Product Analytics][2], helping you identify and reproduce errors, understand user journeys, and gain insights into your application's usage patterns and design pitfalls. +Session Replay expands your user experience monitoring by allowing you to capture and visually replay the web browsing or mobile app experience of your users. Session Replay is available in both [RUM][1] and [{{< prodname >}}Product Analytics{{< /prodname >}}][2], helping you identify and reproduce errors, understand user journeys, and gain insights into your application's usage patterns and design pitfalls. ## Browser Session Replay diff --git a/hugo/content/en/session_replay/dev_tools.md b/hugo/content/en/session_replay/dev_tools.md index e8b3d10cffa..7e7ecb5db9b 100644 --- a/hugo/content/en/session_replay/dev_tools.md +++ b/hugo/content/en/session_replay/dev_tools.md @@ -44,7 +44,7 @@ The Log Explorer opens in a separate tab with a pre-filled search query. ### Errors -The {{< ui >}}Errors{{< /ui >}} tab displays [RUM errors][4] and [Error Tracking][5] issues that correlate to the session. +The {{< ui >}}Errors{{< /ui >}} tab displays [RUM errors][4] and [{{< prodname >}}Error Tracking{{< /prodname >}}][5] issues that correlate to the session. {{< img src="real_user_monitoring/session_replay/dev_tools/dev-tools-errors.png" alt="Errors tab" style="width:100%;">}} diff --git a/hugo/content/en/session_replay/guide/diagnose-funnel-drop-offs-with-session-replay.md b/hugo/content/en/session_replay/guide/diagnose-funnel-drop-offs-with-session-replay.md index 2b15792a8b3..ea928102252 100644 --- a/hugo/content/en/session_replay/guide/diagnose-funnel-drop-offs-with-session-replay.md +++ b/hugo/content/en/session_replay/guide/diagnose-funnel-drop-offs-with-session-replay.md @@ -15,11 +15,11 @@ further_reading: Conversion funnels show where users drop off, but not always why. The root cause can be a layout issue, a third-party overlay, or a rendering problem on certain devices. These are issues that don't appear in error logs and are difficult to reproduce without matching exact conditions. -This guide walks through a workflow for diagnosing funnel drop-offs by combining [Product Analytics][1] with [Session Replay][2]. Product Analytics narrows down who is dropping off, while Session Replay shows you exactly what they encountered. +This guide walks through a workflow for diagnosing funnel drop-offs by combining [{{< prodname >}}Product Analytics{{< /prodname >}}][1] with [Session Replay][2]. {{< prodname >}}Product Analytics{{< /prodname >}} narrows down who is dropping off, while Session Replay shows you exactly what they encountered. ## Spot the drop in Product Analytics -In this example, a funnel in Product Analytics tracks each step of a campaign landing page: landing page, CTA click, flow completion, and conversion. +In this example, a funnel in {{< prodname >}}Product Analytics{{< /prodname >}} tracks each step of a campaign landing page: landing page, CTA click, flow completion, and conversion. {{< img src="real_user_monitoring/session_replay/guides/spot-the-drop.png" alt="A funnel chart in Product Analytics showing conversion rate dropping from approximately 60% to 35% over a five-day period at the landing page step" style="width:100%;" >}} @@ -53,7 +53,7 @@ After the fix ships, monitor the same funnel to confirm click-through rates for Use this workflow whenever a funnel moves and the cause is not immediately clear: -1. Detect the drop in Product Analytics and identify the affected step. +1. Detect the drop in {{< prodname >}}Product Analytics{{< /prodname >}} and identify the affected step. 2. Segment the funnel by device, region, browser, or other attributes to isolate who is affected. 3. Watch Session Replays of the affected cohort. 4. Identify the root cause from what you observe in the sessions. diff --git a/hugo/content/en/session_replay/heatmaps.md b/hugo/content/en/session_replay/heatmaps.md index 104211417b9..34caf5b5f9c 100644 --- a/hugo/content/en/session_replay/heatmaps.md +++ b/hugo/content/en/session_replay/heatmaps.md @@ -177,11 +177,11 @@ To remove the currently saved screenshot and revert to an auto-picked one from a The time periods you can view in a heatmap depend on where you access it: - **RUM**: Session Replay heatmaps use RUM click data (RUM action events), which has a 30-day retention period. -- **Product Analytics**: Heatmaps use Product Analytics click data, which has a 15-month retention period. +- **{{< prodname >}}Product Analytics{{< /prodname >}}**: Heatmaps use {{< prodname >}}Product Analytics{{< /prodname >}} click data, which has a 15-month retention period. ## Next steps -After analyzing heatmaps, the next step is to understand the user action by exploring related data. Watch associated [session replays][1] to see user actions in the context of their overall session, or navigate to an Analytics explorer in [RUM][3] or [Product Analytics][4] to analyze your user data. +After analyzing heatmaps, the next step is to understand the user action by exploring related data. Watch associated [session replays][1] to see user actions in the context of their overall session, or navigate to an Analytics explorer in [RUM][3] or [{{< prodname >}}Product Analytics{{< /prodname >}}][4] to analyze your user data. ## Troubleshooting diff --git a/hugo/content/en/source_code/_index.md b/hugo/content/en/source_code/_index.md index 34afbe703ad..e1249fdaa85 100644 --- a/hugo/content/en/source_code/_index.md +++ b/hugo/content/en/source_code/_index.md @@ -7,7 +7,7 @@ aliases: ## Overview -Datadog's Source Code Integration allows you to connect your Git repositories to Datadog to enable various source code-related features across the Datadog platform. It allows debugging stack traces, slow profiles, and other issues by accessing the relevant lines of your source code. +Datadog's {{< prodname >}}Source Code Integration{{< /prodname >}} allows you to connect your Git repositories to Datadog to enable various source code-related features across the Datadog platform. It allows debugging stack traces, slow profiles, and other issues by accessing the relevant lines of your source code. {{< img src="source_code_integration/inline-code-snippet.png" alt="Inline code snippet of a Java RuntimeException with a button to view the code in GitHub" style="width:100%;">}} diff --git a/hugo/content/en/source_code/features.md b/hugo/content/en/source_code/features.md index d31a72e5489..37bf90b498d 100644 --- a/hugo/content/en/source_code/features.md +++ b/hugo/content/en/source_code/features.md @@ -42,7 +42,7 @@ After you have connected your Git repositories and tagged your services, you can {{< tabs >}} {{% tab "Error Tracking" %}} -You can see links from stack frames to their source repository in [Error Tracking][1]. +You can see links from stack frames to their source repository in [{{< prodname >}}Error Tracking{{< /prodname >}}][1]. 1. Navigate to [{{< ui >}}APM{{< /ui >}} > {{< ui >}}Error Tracking{{< /ui >}}][2]. 2. Click on an issue. The {{< ui >}}Issue Details{{< /ui >}} panel appears on the right. @@ -112,7 +112,7 @@ You can see links from errors in your Lambda functions' associated stack traces {{% /tab %}} {{% tab "Test Optimization" %}} -You can see links from failed test runs to their source repository in **Test Optimization**. +You can see links from failed test runs to their source repository in **{{< prodname >}}Test Optimization{{< /prodname >}}**. 1. Navigate to [{{< ui >}}Software Delivery{{< /ui >}} > {{< ui >}}Test Optimization{{< /ui >}} > {{< ui >}}Test Runs{{< /ui >}}][101] and select a failed test run. 2. If you're using the GitHub or GitLab integrations, click {{< ui >}}Connect to preview{{< /ui >}} on stack frames. You can see inline code snippets directly in the stack trace. Otherwise, you can click the {{< ui >}}View{{< /ui >}} button on the right of a frame or select {{< ui >}}View file{{< /ui >}}, {{< ui >}}View Git blame{{< /ui >}}, or {{< ui >}}View commit{{< /ui >}} to be redirected to your source code management tool. @@ -127,7 +127,7 @@ For more information, see [Enhancing Developer Workflows with Datadog][102]. {{% /tab %}} {{% tab "Code Security" %}} -You can see links from failed Static Analysis and Software Composition Analysis scans to their source repository in **Code Security**. +You can see links from failed Static Analysis and Software Composition Analysis scans to their source repository in **{{< prodname >}}Code Security{{< /prodname >}}**. 1. Navigate to [{{< ui >}}Software Delivery{{< /ui >}} > {{< ui >}}Code Security{{< /ui >}}][101] and select a repository. 2. In the {{< ui >}}Code Vulnerabilities{{< /ui >}} or {{< ui >}}Code Quality{{< /ui >}} view, click on a code vulnerability or violation. In the {{< ui >}}Details{{< /ui >}} section, if you're using the GitHub, GitLab, or Azure DevOps integrations, click {{< ui >}}Connect to preview{{< /ui >}}. You can see inline code snippets highlighting the exact lines of code that triggered the vulnerability or violation. Otherwise, you can click the **View** button on the right of a frame or select **View file**, **View Git blame**, or **View commit** to be redirected to your source code management tool. @@ -204,7 +204,7 @@ To disable PR comments for CI Visibility, go to the [CI Visibility Repository Se {{% /tab %}} {{% tab "Code Security" %}} -PR comments are enabled by default when first onboarding to Code Security if the GitHub, GitLab, or Azure DevOps integration is installed correctly. These integrations post two types of comments on your pull requests: +PR comments are enabled by default when first onboarding to {{< prodname >}}Code Security{{< /prodname >}} if the GitHub, GitLab, or Azure DevOps integration is installed correctly. These integrations post two types of comments on your pull requests: 1. A single comment summarizing the new violations detected in your pull request. @@ -214,18 +214,18 @@ PR comments are enabled by default when first onboarding to Code Security if the {{< img src="source_code_integration/code-security-inline-pr-comment.png" alt="Inline comment for a specific violation detected by Code Security" style="width:100%;">}} -To disable PR comments for Code Security, go to the [Code Security Repository Settings][101]. +To disable PR comments for {{< prodname >}}Code Security{{< /prodname >}}, go to the [Code Security Repository Settings][101]. [101]: https://app.datadoghq.com/security/configuration/code-security/settings {{% /tab %}} {{% tab "Test Optimization" %}} -PR comments are enabled by default when first onboarding to Test Optimization if the GitHub or GitLab integration is installed correctly. The integration posts a comment summarizing the failed and flaky tests detected in your pull request. +PR comments are enabled by default when first onboarding to {{< prodname >}}Test Optimization{{< /prodname >}} if the GitHub or GitLab integration is installed correctly. The integration posts a comment summarizing the failed and flaky tests detected in your pull request. {{< img src="source_code_integration/test-optimization-pr-comment.png" alt="PR Comment summarizing failed and flaky tests detected by Test Optimization" style="width:100%;">}} -To disable PR comments for Test Optimization, go to the [Test Optimization Advanced Features Settings][101]. +To disable PR comments for {{< prodname >}}Test Optimization{{< /prodname >}}, go to the [Test Optimization Advanced Features Settings][101]. [101]: https://app.datadoghq.com/ci/settings/test-optimization/advanced-features diff --git a/hugo/content/en/synthetics/guide/api_test_timing_variations.md b/hugo/content/en/synthetics/guide/api_test_timing_variations.md index 55f491c67e6..7736d70671a 100644 --- a/hugo/content/en/synthetics/guide/api_test_timing_variations.md +++ b/hugo/content/en/synthetics/guide/api_test_timing_variations.md @@ -74,7 +74,7 @@ In case of any redirection, the download time only corresponds to the last reque ### Total response time -The `*.response.time` metrics measure the total time between the moment Synthetics starts and the moment Synthetic finishes the request. The response time is the sum of all network timings. +The `*.response.time` metrics measure the total time between the moment {{< prodname >}}Synthetics{{< /prodname >}} starts and the moment Synthetic finishes the request. The response time is the sum of all network timings. For example, the total response time for an HTTP test with no redirections on an HTTPS endpoint: `synthetics.http.response.time = synthetics.http.dns.time + synthetics.http.connect.time + synthetics.http.ssl.time + synthetics.http.firstbyte.time + synthetics.http.download.time`. @@ -106,10 +106,10 @@ An increase in DNS resolution time can occur with additional latency from author Variations of the TCP handshake can occur because of the network and server load, the size of the request and response messages, and the distance between the Synthetic Monitoring managed or [private location][5] and the server. ### SSL handshake time -Variations of the SSL handshake time can occur because of the server load (SSL handshakes are usually CPU intensive), the network load, and the distance between the Synthetics managed or [private location][5] and the server. Issues with CDN can increase SSL handshake time. +Variations of the SSL handshake time can occur because of the server load (SSL handshakes are usually CPU intensive), the network load, and the distance between the {{< prodname >}}Synthetics{{< /prodname >}} managed or [private location][5] and the server. Issues with CDN can increase SSL handshake time. ### Time To first byte -Variations of the Time to first byte can occur because of the network and server load and the distance between the Synthetics managed or [private location][5] and the server. For example, a higher network load or the rerouting of traffic caused by an unavailable CDN can negatively impact Time to First Byte timing. +Variations of the Time to first byte can occur because of the network and server load and the distance between the {{< prodname >}}Synthetics{{< /prodname >}} managed or [private location][5] and the server. For example, a higher network load or the rerouting of traffic caused by an unavailable CDN can negatively impact Time to First Byte timing. ### Download time Variations in download time can occur because of changes in the response size. The downloaded body size is available on test results and the `synthetics.http.response.size` metric. diff --git a/hugo/content/en/synthetics/guide/canvas-content-javascript.md b/hugo/content/en/synthetics/guide/canvas-content-javascript.md index 5ab2195565e..72dfe41d4cb 100644 --- a/hugo/content/en/synthetics/guide/canvas-content-javascript.md +++ b/hugo/content/en/synthetics/guide/canvas-content-javascript.md @@ -186,7 +186,7 @@ simulateCanvasClick(canvas, 620, 8); ## Asserting on elements triggered by clicks -Now that the key pieces are in place, you can build a complete flow that includes a Synthetics assertion. In the following example, the test: +Now that the key pieces are in place, you can build a complete flow that includes a {{< prodname >}}Synthetics{{< /prodname >}} assertion. In the following example, the test: - Scans the canvas for the first pixel matching a target color - Simulates a click at that location diff --git a/hugo/content/en/synthetics/guide/explore-rum-through-synthetics.md b/hugo/content/en/synthetics/guide/explore-rum-through-synthetics.md index 58cc7eab571..98b2df854c6 100644 --- a/hugo/content/en/synthetics/guide/explore-rum-through-synthetics.md +++ b/hugo/content/en/synthetics/guide/explore-rum-through-synthetics.md @@ -13,13 +13,13 @@ further_reading: ## Overview -
    If you have Real User Monitoring, you can access a preview of RUM, Session Replay, Error Tracking, and additional performance data from your Synthetic browser test runs.
    +
    If you have Real User Monitoring, you can access a preview of RUM, Session Replay, {{< prodname >}}Error Tracking{{< /prodname >}}, and additional performance data from your Synthetic browser test runs.
    Synthetic browser tests embed the Real User Monitoring SDK, allowing you to explore: - [Session Replay][1] for all tests. You can access additional context beyond screenshots available for each step and [Browser Dev Tools][2]. - The session in the [RUM Explorer][3]. -- Aggregated errors across your different steps, tests, and test runs with [Error Tracking][4]. You can scope the error impact and prioritize fixing the most severe issues. +- Aggregated errors across your different steps, tests, and test runs with [{{< prodname >}}Error Tracking{{< /prodname >}}][4]. You can scope the error impact and prioritize fixing the most severe issues. - Extra resources and timing information from RUM including additional search and monitor capabilities. ## Allow Synthetic data on RUM applications diff --git a/hugo/content/en/synthetics/guide/manage-browser-tests-through-the-api.md b/hugo/content/en/synthetics/guide/manage-browser-tests-through-the-api.md index a19bcfbb1f6..45f01865560 100644 --- a/hugo/content/en/synthetics/guide/manage-browser-tests-through-the-api.md +++ b/hugo/content/en/synthetics/guide/manage-browser-tests-through-the-api.md @@ -15,7 +15,7 @@ further_reading: ## Overview -Monitoring your application end-to-end is crucial to understanding your users' experience. The [Datadog test recorder][1] allows you to simplify configuration for these complex testing workflows. However, you may want to manage your Synthetics resources programmatically and define browser tests with the API or through [Terraform][14]. +Monitoring your application end-to-end is crucial to understanding your users' experience. The [Datadog test recorder][1] allows you to simplify configuration for these complex testing workflows. However, you may want to manage your {{< prodname >}}Synthetics{{< /prodname >}} resources programmatically and define browser tests with the API or through [Terraform][14]. ## Manage your browser tests with the API diff --git a/hugo/content/en/synthetics/platform/private_locations/_index.md b/hugo/content/en/synthetics/platform/private_locations/_index.md index ef713b205f6..f14bc5817c5 100644 --- a/hugo/content/en/synthetics/platform/private_locations/_index.md +++ b/hugo/content/en/synthetics/platform/private_locations/_index.md @@ -571,7 +571,7 @@ Because Datadog already integrates with Kubernetes and AWS, it is ready-made to Once the process is complete, click {{< ui >}}Finish{{< /ui >}} on the installation completion page. -
    If you entered your JSON configuration, the Windows Service starts running using that configuration. If you did not enter your configuration, run C:\\Program Files\Datadog-Synthetics\Synthetics\synthetics-pl-worker.exe --config=< PathToYourConfiguration > from a command prompt or use the start menu shortcut to start the Synthetics Private Location Worker.
    +
    If you entered your JSON configuration, the Windows Service starts running using that configuration. If you did not enter your configuration, run C:\\Program Files\Datadog-Synthetics\{{< prodname >}}Synthetics{{< /prodname >}}\synthetics-pl-worker.exe --config=< PathToYourConfiguration > from a command prompt or use the start menu shortcut to start the Synthetics Private Location Worker.
    [101]: https://ddsynthetics-windows.s3.amazonaws.com/datadog-synthetics-worker-{{< synthetics-worker-version "synthetics-windows-pl" >}}.amd64.msi [102]: https://app.datadoghq.com/synthetics/settings/private-locations diff --git a/hugo/content/en/synthetics/platform/settings/_index.md b/hugo/content/en/synthetics/platform/settings/_index.md index 33846959b8b..2aa5d01cb7d 100644 --- a/hugo/content/en/synthetics/platform/settings/_index.md +++ b/hugo/content/en/synthetics/platform/settings/_index.md @@ -229,7 +229,7 @@ For more information about TOTP-based MFA in a browser test, see [TOTPs For Mult {{% /tab %}} {{% tab "Virtual Authenticator" %}} -To complete a user journey with a passkey in your Synthetics tests, create a Virtual Authenticator global variable. This global variable is used to generate and store passkeys for all your Synthetics browser tests. For more information, see [Using passkeys In Browser Tests][1]. +To complete a user journey with a passkey in your {{< prodname >}}Synthetics{{< /prodname >}} tests, create a Virtual Authenticator global variable. This global variable is used to generate and store passkeys for all your {{< prodname >}}Synthetics{{< /prodname >}} browser tests. For more information, see [Using passkeys In Browser Tests][1]. 1. Navigate to the {{< ui >}}Global Variables{{< /ui >}} tab in [{{< ui >}}Synthetic Monitoring & Continuous Testing{{< /ui >}} > {{< ui >}}Settings{{< /ui >}}][1] and click {{< ui >}}+ New Global Variable{{< /ui >}}. diff --git a/hugo/content/en/synthetics/troubleshooting/_index.md b/hugo/content/en/synthetics/troubleshooting/_index.md index 93db7aff6e6..d27e097e7c4 100644 --- a/hugo/content/en/synthetics/troubleshooting/_index.md +++ b/hugo/content/en/synthetics/troubleshooting/_index.md @@ -180,16 +180,16 @@ In large or high-volume environments, scheduled tests may not run at the expecte ### Missing test results executed from the Datadog Agent -If you do not see test results in the Datadog UI, the Datadog Agent is not sending test results to the Synthetics intake (https://http-synthetics.datadoghq.com) that processes test results. Verify that outbound network traffic from the Datadog Agent to this intake is allowed. +If you do not see test results in the Datadog UI, the Datadog Agent is not sending test results to the {{< prodname >}}Synthetics{{< /prodname >}} intake (https://http-synthetics.datadoghq.com) that processes test results. Verify that outbound network traffic from the Datadog Agent to this intake is allowed. -If the Datadog Agent is running behind a proxy, make sure the Synthetics forwarder is configured to send traffic through the proxy, for example: +If the Datadog Agent is running behind a proxy, make sure the {{< prodname >}}Synthetics{{< /prodname >}} forwarder is configured to send traffic through the proxy, for example: ``` synthetics: collector: enabled: true synthetics.forwarder.dd_url: http://my-proxy.com: ``` -Additionaly, ensure that the proxy itself is configured to allow outboud network traffic to the Synthetics intake. +Additionaly, ensure that the proxy itself is configured to allow outboud network traffic to the {{< prodname >}}Synthetics{{< /prodname >}} intake. ## Private locations @@ -207,7 +207,7 @@ Error: Got 403 in request - {"errors":["Expired/not yet valid signature"]} at DatadogQueue.receiveMessages (dist/build/index.js:258914:48) ``` -**Cause**: The log shows that the Private Location was able to successfully reach the Synthetics intake to fetch tests, but the request failed with a 403 response from Datadog due to an authentication issue. Specifically, the request signature was considered expired or not yet valid. Communication between the Private Location and Datadog is secured using Datadog Signature v1 (based on the same signing process as [AWS Signature v4][105]) which includes a timestamp in each request, ensuring both authentication and integrity). If the system clock on the server hosting the Private Location is out of sync, the timestamp can fall outside the allowed window, and the signature validation fails. +**Cause**: The log shows that the Private Location was able to successfully reach the {{< prodname >}}Synthetics{{< /prodname >}} intake to fetch tests, but the request failed with a 403 response from Datadog due to an authentication issue. Specifically, the request signature was considered expired or not yet valid. Communication between the Private Location and Datadog is secured using Datadog Signature v1 (based on the same signing process as [AWS Signature v4][105]) which includes a timestamp in each request, ensuring both authentication and integrity). If the system clock on the server hosting the Private Location is out of sync, the timestamp can fall outside the allowed window, and the signature validation fails. **Solution**: Ensure the server hosting the Private Location has accurate time synchronization. If NTP (Network Time Protocol) services are in use, verify that these services are correctly configured and functioning properly, and address any misconfigurations that could prevent the system clock from syncing with its time sources. diff --git a/hugo/content/en/tests/_index.md b/hugo/content/en/tests/_index.md index d12d992c85c..cbaff072927 100644 --- a/hugo/content/en/tests/_index.md +++ b/hugo/content/en/tests/_index.md @@ -48,22 +48,22 @@ cascade: tags: ['ci test', 'ci tests', 'test optimization', 'test visibility', 'failed test', 'flaky test', 'supported features'] --- -{{< callout url=# btn_hidden="true" header="Try the new CI/CD Optimization experience!">}}[CI/CD Optimization][1] combines Datadog's CI Visibility and Test Optimization experiences into one unified interface. Click {{< ui >}}Try It Now{{< /ui >}} at the top of any page in CI Visibility or Test Optimization, and switch back to the original UI at any time. +{{< callout url=# btn_hidden="true" header="Try the new CI/CD Optimization experience!">}}[CI/CD Optimization][1] combines Datadog's CI Visibility and {{< prodname >}}Test Optimization{{< /prodname >}} experiences into one unified interface. Click {{< ui >}}Try It Now{{< /ui >}} at the top of any page in CI Visibility or {{< prodname >}}Test Optimization{{< /prodname >}}, and switch back to the original UI at any time. [1]: /continuous_integration/cicd_optimization/ {{< /callout >}} -{{< learning-center-callout header="Try Getting Started with Test Optimization in the Learning Center" btn_title="Enroll Now" btn_url="https://learn.datadoghq.com/courses/getting-started-test-optimization">}} +{{< learning-center-callout header="Try Getting Started with {{< prodname >}}Test Optimization{{< /prodname >}} in the Learning Center" btn_title="Enroll Now" btn_url="https://learn.datadoghq.com/courses/getting-started-test-optimization">}} Learn how to accelerate your CI pipelines by setting up test monitoring, identifying flaky tests and using Test Impact Analysis to run only the tests that matter. {{< /learning-center-callout >}} ## Overview -[Test Optimization][1] provides a test-first view into your CI health by displaying important metrics and results from your tests. It can help you investigate performance problems and test failures that are most relevant to your work, focusing on the code you are responsible for, rather than the pipelines which run your tests. +[{{< prodname >}}Test Optimization{{< /prodname >}}][1] provides a test-first view into your CI health by displaying important metrics and results from your tests. It can help you investigate performance problems and test failures that are most relevant to your work, focusing on the code you are responsible for, rather than the pipelines which run your tests. ## Setup -Select an option to configure Test Optimization in Datadog: +Select an option to configure {{< prodname >}}Test Optimization{{< /prodname >}} in Datadog: {{< card-grid card_width="75px" >}} {{< image-card href="/tests/setup/dotnet/" src="integrations_logos/dotnet_avatar.svg" alt=".net" >}} @@ -78,7 +78,7 @@ Select an option to configure Test Optimization in Datadog: If you use Bazel to run Go, Java, or Python tests, use the Datadog [Bazel rules for Test Optimization][10]. -In addition to tests, Test Optimization provides visibility over the whole testing phase of your project. +In addition to tests, {{< prodname >}}Test Optimization{{< /prodname >}} provides visibility over the whole testing phase of your project. ### Supported features @@ -115,7 +115,7 @@ For example, suppose you're testing a single commit and you have a Python test t ### Test configuration attributes -When you run your tests with Test Optimization, the library detects and reports information about the environment where tests are run as test tags. For example, the operating system name, such as `Windows` or `Linux`, and the architecture of the platform, such as `arm64` or `x86_64`, are added as tags on each test. These values are shown in the commit and on branch overview pages when a test fails or is flaky for a specific configuration but not others. +When you run your tests with {{< prodname >}}Test Optimization{{< /prodname >}}, the library detects and reports information about the environment where tests are run as test tags. For example, the operating system name, such as `Windows` or `Linux`, and the architecture of the platform, such as `arm64` or `x86_64`, are added as tags on each test. These values are shown in the commit and on branch overview pages when a test fails or is flaky for a specific configuration but not others. The following tags are automatically collected to identify test configurations, and some may only apply to specific platforms: @@ -137,9 +137,9 @@ The following tags are automatically collected to identify test configurations, ### Parameterized test configurations -When you run parameterized tests, the library detects and reports information about the parameters used. Parameters are a part of test configuration, so the same test case executed with different parameters is considered as two different tests in Test Optimization. +When you run parameterized tests, the library detects and reports information about the parameters used. Parameters are a part of test configuration, so the same test case executed with different parameters is considered as two different tests in {{< prodname >}}Test Optimization{{< /prodname >}}. -If a test parameter is non-deterministic and has a different value every time a test is run, each test execution is considered a new test in Test Optimization. As a consequence, some product features may not work correctly for such tests: history of executions, flakiness detection, Test Impact Analysis, and others. +If a test parameter is non-deterministic and has a different value every time a test is run, each test execution is considered a new test in {{< prodname >}}Test Optimization{{< /prodname >}}. As a consequence, some product features may not work correctly for such tests: history of executions, flakiness detection, Test Impact Analysis, and others. Some examples of non-deterministic test parameters are: @@ -152,7 +152,7 @@ Avoid using non-deterministic test parameters. In case this is not possible, som ## Custom configurations -There are some configurations that cannot be directly identified and reported automatically because they can depend on environment variables, test run arguments, or other approaches that developers use. For those cases, you must provide the configuration details to the library so Test Optimization can properly identify them. +There are some configurations that cannot be directly identified and reported automatically because they can depend on environment variables, test run arguments, or other approaches that developers use. For those cases, you must provide the configuration details to the library so {{< prodname >}}Test Optimization{{< /prodname >}} can properly identify them. Define these tags as part of the `DD_TAGS` environment variable using the `test.configuration` prefix. diff --git a/hugo/content/en/tests/browser_tests.md b/hugo/content/en/tests/browser_tests.md index 44f4ed87614..b6d9ff846e8 100644 --- a/hugo/content/en/tests/browser_tests.md +++ b/hugo/content/en/tests/browser_tests.md @@ -16,11 +16,11 @@ further_reading: ## Overview -Test Optimization integrates with Datadog [Real User Monitoring][2] to provide you with the tools for deep analysis of your browser tests. +{{< prodname >}}Test Optimization{{< /prodname >}} integrates with Datadog [Real User Monitoring][2] to provide you with the tools for deep analysis of your browser tests. ### Compatibility -To enable RUM integration ensure that [Test Optimization][1] is set up for your tests and that the application being tested is instrumented using [RUM][2]. +To enable RUM integration ensure that [{{< prodname >}}Test Optimization{{< /prodname >}}][1] is set up for your tests and that the application being tested is instrumented using [RUM][2]. RUM integration is supported for Cypress browser tests and Selenium-driven browser tests. @@ -54,7 +54,7 @@ If you use Cypress, Selenium, or Playwright to run your browser tests and the ap If a test ends before its RUM session flushes, the session and test can appear unlinked. To give the session more time to flush, set the `DD_CIVISIBILITY_RUM_FLUSH_WAIT_MILLIS` environment variable to a value higher than the default of 500 milliseconds. -A {{< ui >}}Browser Sessions{{< /ui >}} tab appears in the Test Optimization test details side panel. +A {{< ui >}}Browser Sessions{{< /ui >}} tab appears in the {{< prodname >}}Test Optimization{{< /prodname >}} test details side panel. {{< img src="ci/ci-browser-session-tab.png" alt="Browser Session Tab in Test Detail" style="width:100%;">}} diff --git a/hugo/content/en/tests/code_coverage.md b/hugo/content/en/tests/code_coverage.md index 582e1a4336a..b96b9d93fb3 100644 --- a/hugo/content/en/tests/code_coverage.md +++ b/hugo/content/en/tests/code_coverage.md @@ -25,7 +25,7 @@ This Test Optimization feature is legacy. Use the new dedicated }} @@ -166,7 +166,7 @@ async def main(jobs): ### Ruby -Agentless logs submission with Test Optimization is supported for Rails applications. Before enabling, ensure +Agentless logs submission with {{< prodname >}}Test Optimization{{< /prodname >}} is supported for Rails applications. Before enabling, ensure that your application is [instrumented with Datadog tracing][1]. To use agentless log submission, you need `datadog-ci` version `0.16` or later. The following logging libraries are supported: diff --git a/hugo/content/en/tests/developer_workflows.md b/hugo/content/en/tests/developer_workflows.md index a1fdbd157f2..3de44a5e132 100644 --- a/hugo/content/en/tests/developer_workflows.md +++ b/hugo/content/en/tests/developer_workflows.md @@ -23,18 +23,18 @@ further_reading: ## Overview -[Test Optimization][5] integrates with other developer-oriented Datadog products as well as external partners such as GitHub to streamline developer workflows with features including being able to: +[{{< prodname >}}Test Optimization{{< /prodname >}}][5] integrates with other developer-oriented Datadog products as well as external partners such as GitHub to streamline developer workflows with features including being able to: - [Enable test summaries in GitHub pull request comments](#test-summaries-in-github-pull-requests) - [Create and open GitHub issues](#create-and-open-github-issues) - [Create Jira issues through Case Management](#create-jira-issues) - [Open tests in GitHub and your IDE](#open-tests-in-github-and-your-ide) -These features are available for all Test Optimization customers, and they do not require usage of the [Datadog GitHub integration][4]. +These features are available for all {{< prodname >}}Test Optimization{{< /prodname >}} customers, and they do not require usage of the [Datadog GitHub integration][4]. ## Test summaries in GitHub pull requests -Test Optimization integrates with GitHub to show summaries of test results directly in your pull request comments. Each summary contains an overview of the tests executions, flakiness information, and error messages for failed tests. +{{< prodname >}}Test Optimization{{< /prodname >}} integrates with GitHub to show summaries of test results directly in your pull request comments. Each summary contains an overview of the tests executions, flakiness information, and error messages for failed tests. {{< img src="ci/github_comments_light.png" alt="Datadog GitHub pull request comment preview" style="width:100%;">}} @@ -61,11 +61,11 @@ Comments only appear on pull requests that have run at least one test for an ena ## Create and open GitHub issues -With Test Optimization, you can create and open pre-filled GitHub issues with relevant context into your tests as well as deep links back to Datadog for more streamlined debugging workflows. Creating issues directly from Test Optimization can help you track and maintain accountability for test failures and flaky tests. +With Test Optimization, you can create and open pre-filled GitHub issues with relevant context into your tests as well as deep links back to Datadog for more streamlined debugging workflows. Creating issues directly from {{< prodname >}}Test Optimization{{< /prodname >}} can help you track and maintain accountability for test failures and flaky tests. ### In-app entry points -You can create pre-filled GitHub issues from three areas within Test Optimization: +You can create pre-filled GitHub issues from three areas within {{< prodname >}}Test Optimization{{< /prodname >}}: - [Commit Overview page (from the {{< ui >}}Commits{{< /ui >}} table)](#commit-overview) - [Branch Overview page](#branch-overview) @@ -99,19 +99,19 @@ Below is what a pre-filled GitHub issue might look like: ## Create Jira issues -With [Case Management][8], you can create and open pre-filled Jira issues that contain relevant context related to your tests, as well as deep links back to Datadog for more streamlined debugging workflows. Creating issues directly from Test Optimization can help you track and maintain accountability for test failures and flaky tests. +With [{{< prodname >}}Case Management{{< /prodname >}}][8], you can create and open pre-filled Jira issues that contain relevant context related to your tests, as well as deep links back to Datadog for more streamlined debugging workflows. Creating issues directly from {{< prodname >}}Test Optimization{{< /prodname >}} can help you track and maintain accountability for test failures and flaky tests. -When you update the status of a Jira issue, the status in Case Management updates and reflects the latest case status. +When you update the status of a Jira issue, the status in {{< prodname >}}Case Management{{< /prodname >}} updates and reflects the latest case status. ### In-app entry points -After you have [set up the Jira integration][7], you can create cases from three areas within Test Optimization: +After you have [set up the Jira integration][7], you can create cases from three areas within {{< prodname >}}Test Optimization{{< /prodname >}}: - [Commit Overview page (from the {{< ui >}}Commits{{< /ui >}} table)](#commit-overview-1) - [Flaky Tests section](#branch-overview-1) - [Test Runs side panel](#test-runs-view) -You can manually create a Jira issue from a case in [Case Management][9] by clicking `Shift + J`. +You can manually create a Jira issue from a case in [{{< prodname >}}Case Management{{< /prodname >}}][9] by clicking `Shift + J`. ### Commit Overview diff --git a/hugo/content/en/tests/explorer/export.md b/hugo/content/en/tests/explorer/export.md index 397b4abb39d..03878168893 100644 --- a/hugo/content/en/tests/explorer/export.md +++ b/hugo/content/en/tests/explorer/export.md @@ -14,7 +14,7 @@ further_reading: ## Overview -You can use your Test Optimization search query and visualization graphs in dashboards, monitors, and notebooks, or programmatically search for events using the [Search Tests Events endpoint][1]. +You can use your {{< prodname >}}Test Optimization{{< /prodname >}} search query and visualization graphs in dashboards, monitors, and notebooks, or programmatically search for events using the [Search Tests Events endpoint][1]. ## Export the search query or visualization diff --git a/hugo/content/en/tests/flaky_management/_index.md b/hugo/content/en/tests/flaky_management/_index.md index 6b997798dca..d234b3548ef 100644 --- a/hugo/content/en/tests/flaky_management/_index.md +++ b/hugo/content/en/tests/flaky_management/_index.md @@ -117,11 +117,11 @@ For more information about a specific flaky test, use these options in the actio ## Create cases for flaky tests -For any flaky test, you can create a case and use [Case Management][4] to track any work toward remediation. Click the {{< ui >}}Create Case{{< /ui >}} button or use the actions menu at the end of the row. +For any flaky test, you can create a case and use [{{< prodname >}}Case Management{{< /prodname >}}][4] to track any work toward remediation. Click the {{< ui >}}Create Case{{< /ui >}} button or use the actions menu at the end of the row. ## Confirm fixes for flaky tests -When you fix a flaky test, Test Optimization's remediation flow can confirm the fix by retrying the test multiple times. To enable the remediation flow: +When you fix a flaky test, {{< prodname >}}Test Optimization{{< /prodname >}}'s remediation flow can confirm the fix by retrying the test multiple times. To enable the remediation flow: 1. For the test you are fixing, click {{< ui >}}Link commit to Flaky Test fix{{< /ui >}} in the Flaky Tests Management UI. 1. Copy the unique flaky test key that is displayed (for example, `DD_ABC123`). @@ -141,10 +141,10 @@ When you fix a flaky test, Test Optimization's remediation flow can confirm the After a successful remediation run, Flaky Tests Management tracks the branch containing the fix and displays a {{< ui >}}Fix in progress{{< /ui >}} indicator until the fix reaches the repository's default branch. When the associated pull request merges, the test automatically moves to `Fixed` and the indicator is removed. If the fix is pushed directly to the default branch, the test is marked `Fixed` immediately. Requirements and limitations: -- Source Code Integration must be configured for a supported SCM provider (GitHub, GitLab, or Azure DevOps) so Datadog can receive pull request merge webhooks. See [Source Code Integration setup][17]. +- {{< prodname >}}Source Code Integration{{< /prodname >}} must be configured for a supported SCM provider (GitHub, GitLab, or Azure DevOps) so Datadog can receive pull request merge webhooks. See [Source Code Integration setup][17]. - Renaming or deleting the feature branch after the remediation run prevents Datadog from detecting the merge. - Branches with fixes older than three months stop being monitored; rerun the remediation flow to refresh tracking. -- If your SCM provider isn't supported or Source Code Integration isn't set up, Datadog cannot detect merges automatically. Manually transition the test to `Fixed` after the fix is deployed. +- If your SCM provider isn't supported or {{< prodname >}}Source Code Integration{{< /prodname >}} isn't set up, Datadog cannot detect merges automatically. Manually transition the test to `Fixed` after the fix is deployed. ### Grace period mechanism @@ -158,7 +158,7 @@ This method avoids unnecessary CI failures and saves developer time. ## Bits AI-powered flaky test fixes -After Test Optimization detects a flaky test, [Bits Code][16] can automatically diagnose and fix it. Bits Code analyzes the test's failure patterns and generates production-ready code changes. You can then create a GitHub pull request directly from Bits Code's suggestions. +After Test Optimization detects a flaky test, [{{< prodname >}}Bits Code{{< /prodname >}}][16] can automatically diagnose and fix it. {{< prodname >}}Bits Code{{< /prodname >}} analyzes the test's failure patterns and generates production-ready code changes. You can then create a GitHub pull request directly from {{< prodname >}}Bits Code{{< /prodname >}}'s suggestions. For Bits Code to create a fix, the flaky test must meet the following criteria: - **Failure rate**: At least 5% @@ -171,9 +171,9 @@ For Bits Code to create a fix, the flaky test must meet the following criteria: ### Setup -To allow Bits Code to suggest flaky test fixes, enable Bits Code for Test Optimization by following the setup instructions in the [Bits Code documentation][16]. Bits Code automatically creates fixes for flaky tests detected by Test Optimization. +To allow {{< prodname >}}Bits Code{{< /prodname >}} to suggest flaky test fixes, enable {{< prodname >}}Bits Code{{< /prodname >}} for {{< prodname >}}Test Optimization{{< /prodname >}} by following the setup instructions in the [Bits Code documentation][16]. {{< prodname >}}Bits Code{{< /prodname >}} automatically creates fixes for flaky tests detected by {{< prodname >}}Test Optimization{{< /prodname >}}. -After you have enabled Bits Code, when viewing a flaky test, click {{< ui >}}Generate fix{{< /ui >}}. +After you have enabled {{< prodname >}}Bits Code{{< /prodname >}}, when viewing a flaky test, click {{< ui >}}Generate fix{{< /ui >}}. ## AI-powered flaky test categorization diff --git a/hugo/content/en/tests/flaky_tests/auto_test_retries.md b/hugo/content/en/tests/flaky_tests/auto_test_retries.md index f92a2601d1f..7c4dfd03b9d 100644 --- a/hugo/content/en/tests/flaky_tests/auto_test_retries.md +++ b/hugo/content/en/tests/flaky_tests/auto_test_retries.md @@ -15,12 +15,12 @@ further_reading: ## Overview -Test Optimization's Auto Test Retries feature allows retrying failing tests up to N times to avoid failing your build due to flaky tests: +{{< prodname >}}Test Optimization{{< /prodname >}}'s Auto Test Retries feature allows retrying failing tests up to N times to avoid failing your build due to flaky tests: a failing test case is retried either until it passes successfully or until there are no more retry attempts left (in which case the build fails). ## Setup -Ensure [Test Optimization][1] is configured for your test runs. +Ensure [{{< prodname >}}Test Optimization{{< /prodname >}}][1] is configured for your test runs. {{< tabs >}} @@ -33,14 +33,14 @@ Ensure [Test Optimization][1] is configured for your test runs. The test framework compatibility is the same as [Test Optimization Compatibility][3], with the exception of `Scala Weaver`. ### Configuration -After you set up Test Optimization, configure Auto Test Retries in [{{< ui >}}CI/CD Optimization settings{{< /ui >}}][1]. You can apply the setting at the organization, repository, or test service level. +After you set up {{< prodname >}}Test Optimization{{< /prodname >}}, configure Auto Test Retries in [{{< ui >}}CI/CD Optimization settings{{< /ui >}}][1]. You can apply the setting at the organization, repository, or test service level. {{< img src="continuous_integration/auto_test_retries_test_settings-3.png" alt="Auto Test Retries toggle in CI/CD Settings." style="width:100%" >}} The default behavior of the feature is to retry any failing test case up to 5 times. This behavior can be fine-tuned with the following environment variables: -* `DD_CIVISIBILITY_FLAKY_RETRY_ONLY_KNOWN_FLAKES` - if this environment variable is set to `true`, only the test cases that Test Optimization considers [flaky][2] are retried. +* `DD_CIVISIBILITY_FLAKY_RETRY_ONLY_KNOWN_FLAKES` - if this environment variable is set to `true`, only the test cases that {{< prodname >}}Test Optimization{{< /prodname >}} considers [flaky][2] are retried. * `DD_CIVISIBILITY_FLAKY_RETRY_COUNT` - can be set to any non-negative number to change the maximum number of retries per test case. [1]: https://app.datadoghq.com/ci/settings/ci-cd/repositories @@ -56,7 +56,7 @@ This behavior can be fine-tuned with the following environment variables: ### Configuration -After you set up Test Optimization, configure Auto Test Retries in [{{< ui >}}CI/CD Optimization settings{{< /ui >}}][1]. You can apply the setting at the organization, repository, or test service level. +After you set up {{< prodname >}}Test Optimization{{< /prodname >}}, configure Auto Test Retries in [{{< ui >}}CI/CD Optimization settings{{< /ui >}}][1]. You can apply the setting at the organization, repository, or test service level. {{< img src="continuous_integration/auto_test_retries_test_settings-3.png" alt="Auto Test Retries toggle in CI/CD Settings." style="width:100%" >}} @@ -78,7 +78,7 @@ This behavior can be fine-tuned with the following environment variables: ### Configuration -After you set up Test Optimization, configure Auto Test Retries in [{{< ui >}}CI/CD Optimization settings{{< /ui >}}][1]. You can apply the setting at the organization, repository, or test service level. +After you set up {{< prodname >}}Test Optimization{{< /prodname >}}, configure Auto Test Retries in [{{< ui >}}CI/CD Optimization settings{{< /ui >}}][1]. You can apply the setting at the organization, repository, or test service level. {{< img src="continuous_integration/auto_test_retries_test_settings-3.png" alt="Auto Test Retries toggle in CI/CD Settings." style="width:100%" >}} @@ -101,7 +101,7 @@ This behavior can be fine-tuned with the following environment variables: ### Configuration -After you set up Test Optimization, configure Auto Test Retries in [{{< ui >}}CI/CD Optimization settings{{< /ui >}}][1]. You can apply the setting at the organization, repository, or test service level. +After you set up {{< prodname >}}Test Optimization{{< /prodname >}}, configure Auto Test Retries in [{{< ui >}}CI/CD Optimization settings{{< /ui >}}][1]. You can apply the setting at the organization, repository, or test service level. {{< img src="continuous_integration/auto_test_retries_test_settings-3.png" alt="Auto Test Retries toggle in CI/CD Settings." style="width:100%" >}} @@ -124,7 +124,7 @@ Customize the Auto Test Retries with the following environment variables: ### Configuration -After you set up Test Optimization, configure Auto Test Retries in [{{< ui >}}CI/CD Optimization settings{{< /ui >}}][1]. You can apply the setting at the organization, repository, or test service level. +After you set up {{< prodname >}}Test Optimization{{< /prodname >}}, configure Auto Test Retries in [{{< ui >}}CI/CD Optimization settings{{< /ui >}}][1]. You can apply the setting at the organization, repository, or test service level. {{< img src="continuous_integration/auto_test_retries_test_settings-3.png" alt="Auto Test Retries toggle in CI/CD Settings." style="width:100%" >}} @@ -147,7 +147,7 @@ Customize the Auto Test Retries with the following environment variables: ### Configuration -After you set up Test Optimization, configure Auto Test Retries in [{{< ui >}}CI/CD Settings{{< /ui >}}][1]. You can apply the setting at the organization, repository, or test service level. +After you set up {{< prodname >}}Test Optimization{{< /prodname >}}, configure Auto Test Retries in [{{< ui >}}CI/CD Settings{{< /ui >}}][1]. You can apply the setting at the organization, repository, or test service level. {{< img src="continuous_integration/auto_test_retries_test_settings-3.png" alt="Auto Test Retries toggle in CI/CD Settings." style="width:100%" >}} @@ -171,7 +171,7 @@ You can fine tune this behavior with the following environment variables: ### Configuration -After you set up Test Optimization, configure Auto Test Retries in [{{< ui >}}CI/CD Optimization settings{{< /ui >}}][1]. You can apply the setting at the organization, repository, or test service level. +After you set up {{< prodname >}}Test Optimization{{< /prodname >}}, configure Auto Test Retries in [{{< ui >}}CI/CD Optimization settings{{< /ui >}}][1]. You can apply the setting at the organization, repository, or test service level. {{< img src="continuous_integration/auto_test_retries_test_settings-3.png" alt="Auto Test Retries toggle in CI/CD Settings." style="width:100%" >}} diff --git a/hugo/content/en/tests/flaky_tests/early_flake_detection.md b/hugo/content/en/tests/flaky_tests/early_flake_detection.md index f15faebccfc..edb2dbf3295 100644 --- a/hugo/content/en/tests/flaky_tests/early_flake_detection.md +++ b/hugo/content/en/tests/flaky_tests/early_flake_detection.md @@ -39,11 +39,11 @@ You can choose to block the merge of the feature branch with a [PR Gate][4]. For ## Setup -Before implementing Early Flake Detection, you must configure [Test Optimization][6] for your development environment. If you are reporting data through the Datadog Agent, use v6.40 or 7.40 and later. +Before implementing Early Flake Detection, you must configure [{{< prodname >}}Test Optimization{{< /prodname >}}][6] for your development environment. If you are reporting data through the Datadog Agent, use v6.40 or 7.40 and later. ### Configuration -After you set up your Datadog library for Test Optimization, configure Early Flake Detection in [{{< ui >}}CI/CD Optimization settings{{< /ui >}}][7]. You can apply the setting at the organization, repository, or test service level. +After you set up your Datadog library for {{< prodname >}}Test Optimization{{< /prodname >}}, configure Early Flake Detection in [{{< ui >}}CI/CD Optimization settings{{< /ui >}}][7]. You can apply the setting at the organization, repository, or test service level. {{< img src="continuous_integration/early_flake_detection_test_settings-1.png" alt="Early Flake Detection toggle in CI/CD Settings." style="width:100%" >}} diff --git a/hugo/content/en/tests/guides/_index.md b/hugo/content/en/tests/guides/_index.md index eab0f659929..e6685d9dec6 100644 --- a/hugo/content/en/tests/guides/_index.md +++ b/hugo/content/en/tests/guides/_index.md @@ -14,5 +14,5 @@ cascade: {{< nextlink href="/tests/guides/add_custom_measures" >}}Add Custom Measures to Your Tests{{< /nextlink >}} {{< nextlink href="/tests/guides/setup_new_flaky_pr_gate" >}}Set up a New Flaky Test PR Gate{{< /nextlink >}} {{< nextlink href="/tests/guides/validate_optimizations" >}}Validate Optimizations{{< /nextlink >}} - {{< nextlink href="/continuous_testing/guide/view-continuous-testing-test-runs-in-test-optimization" >}}View Continuous Testing Test Runs in Test Optimization{{< /nextlink >}} + {{< nextlink href="/continuous_testing/guide/view-continuous-testing-test-runs-in-test-optimization" >}}View Continuous Testing Test Runs in {{< prodname >}}Test Optimization{{< /prodname >}}{{< /nextlink >}} {{< /whatsnext >}} diff --git a/hugo/content/en/tests/guides/add_custom_measures.md b/hugo/content/en/tests/guides/add_custom_measures.md index b082f2c58de..d3267dc9f4c 100644 --- a/hugo/content/en/tests/guides/add_custom_measures.md +++ b/hugo/content/en/tests/guides/add_custom_measures.md @@ -16,7 +16,7 @@ further_reading: ## Overview -Before you begin, make sure that [Test Optimization][1] is already set up for your language. This guide walks you through adding and using custom measures for your tests. +Before you begin, make sure that [{{< prodname >}}Test Optimization{{< /prodname >}}][1] is already set up for your language. This guide walks you through adding and using custom measures for your tests. ## Add the custom measure to your test diff --git a/hugo/content/en/tests/guides/setup_new_flaky_pr_gate.md b/hugo/content/en/tests/guides/setup_new_flaky_pr_gate.md index 9d845862298..407243969f6 100644 --- a/hugo/content/en/tests/guides/setup_new_flaky_pr_gate.md +++ b/hugo/content/en/tests/guides/setup_new_flaky_pr_gate.md @@ -27,7 +27,7 @@ A new flaky test is a test that: Before you begin: -- Set up [Test Optimization][1] for your language. +- Set up [{{< prodname >}}Test Optimization{{< /prodname >}}][1] for your language. - To improve detection of new flaky tests, enable [Early Flake Detection][4]. See [supported features][5]. ## How it works diff --git a/hugo/content/en/tests/guides/validate_optimizations/_index.md b/hugo/content/en/tests/guides/validate_optimizations/_index.md index f9ae8720c2e..7d2415bcca0 100644 --- a/hugo/content/en/tests/guides/validate_optimizations/_index.md +++ b/hugo/content/en/tests/guides/validate_optimizations/_index.md @@ -16,7 +16,7 @@ further_reading: text: 'Learn about Flaky Test Management' --- -This page explains how to check that the optimizations offered by Test Optimization are working as intended. The guide assumes that [Test Optimization][13] already works for the repository under validation, and it shows the steps to validate optimizations for a **single repository**. +This page explains how to check that the optimizations offered by {{< prodname >}}Test Optimization{{< /prodname >}} are working as intended. The guide assumes that [{{< prodname >}}Test Optimization{{< /prodname >}}][13] already works for the repository under validation, and it shows the steps to validate optimizations for a **single repository**.
    Run these validations in a feature branch only, and do not merge them into your default or main branch.
    @@ -248,7 +248,7 @@ Click on the only test in the list and verify that it shows as {{< ui >}}DISABLE ## Remediation -Test Optimization helps with the remediation of test flakiness with attempt to fix and Bits AI auto fixes. This section focuses on the validation of the attempt to fix workflow. +{{< prodname >}}Test Optimization{{< /prodname >}} helps with the remediation of test flakiness with attempt to fix and Bits AI auto fixes. This section focuses on the validation of the attempt to fix workflow. To validate attempt to fix, follow these steps: diff --git a/hugo/content/en/tests/setup/_index.md b/hugo/content/en/tests/setup/_index.md index 4a879de9af2..5b2c1b61460 100644 --- a/hugo/content/en/tests/setup/_index.md +++ b/hugo/content/en/tests/setup/_index.md @@ -5,7 +5,7 @@ aliases: - /continuous_integration/tests/setup/ --- -For information about configuration options for [Test Optimization][1], choose your language: +For information about configuration options for [{{< prodname >}}Test Optimization{{< /prodname >}}][1], choose your language: {{< card-grid card_width="75px" >}} {{< image-card href="/tests/setup/dotnet/" src="integrations_logos/dotnet_avatar.svg" alt=".net" >}} @@ -25,13 +25,13 @@ see the [Agent Network Traffic][3] or [Agentless Network Settings][4] guide for If you run your tests in a container, see the [Tests in Containers][5] guide for additional setup steps. -To have a supported Test Optimization library upload code coverage reports automatically, see [Upload reports automatically with Test Optimization][6]. +To have a supported {{< prodname >}}Test Optimization{{< /prodname >}} library upload code coverage reports automatically, see [Upload reports automatically with Test Optimization][6]. ## Data Access Control -You can restrict Test Optimization data at the repository level to the appropriate teams and roles in Datadog. This helps prevent sensitive information, such as test names or source paths, from crossing team boundaries. +You can restrict {{< prodname >}}Test Optimization{{< /prodname >}} data at the repository level to the appropriate teams and roles in Datadog. This helps prevent sensitive information, such as test names or source paths, from crossing team boundaries. -To use Data Access Control, go to [Organization Settings > Data Access Control][7] and create a Restricted Dataset scoped to Software Delivery and the repository you want to restrict. Grant access to the roles or teams that should see it. +To use Data Access Control, go to [Organization Settings > Data Access Control][7] and create a Restricted Dataset scoped to {{< prodname >}}Software Delivery{{< /prodname >}} and the repository you want to restrict. Grant access to the roles or teams that should see it. [1]: /continuous_integration/tests [2]: /tests/setup/bazel/ diff --git a/hugo/content/en/tests/setup/bazel/_index.md b/hugo/content/en/tests/setup/bazel/_index.md index 68bad6e3156..03a76e6cdc2 100644 --- a/hugo/content/en/tests/setup/bazel/_index.md +++ b/hugo/content/en/tests/setup/bazel/_index.md @@ -13,9 +13,9 @@ further_reading: text: "Troubleshooting Test Optimization" --- -Datadog provides official Bazel rules for Test Optimization. Use these rules to configure Bazel test targets. The rules read Test Optimization metadata, write local payload files during test execution, and upload test results to Datadog after Bazel tests complete. See all rules in the [`DataDog/rules_test_optimization` repository](https://github.com/DataDog/rules_test_optimization). +Datadog provides official Bazel rules for {{< prodname >}}Test Optimization{{< /prodname >}}. Use these rules to configure Bazel test targets. The rules read {{< prodname >}}Test Optimization{{< /prodname >}} metadata, write local payload files during test execution, and upload test results to Datadog after Bazel tests complete. See all rules in the [`DataDog/rules_test_optimization` repository](https://github.com/DataDog/rules_test_optimization). -The Bazel integration keeps Datadog metadata fetches outside test execution. During module or repository resolution, Bazel fetches Test Optimization metadata from Datadog and exposes it through a generated repository. During test execution, language-specific macros pass the metadata location to the test process and configure payloads to be written under `TEST_UNDECLARED_OUTPUTS_DIR`. After tests finish, run the doctor and uploader targets with `bazel run`. +The Bazel integration keeps Datadog metadata fetches outside test execution. During module or repository resolution, Bazel fetches {{< prodname >}}Test Optimization{{< /prodname >}} metadata from Datadog and exposes it through a generated repository. During test execution, language-specific macros pass the metadata location to the test process and configure payloads to be written under `TEST_UNDECLARED_OUTPUTS_DIR`. After tests finish, run the doctor and uploader targets with `bazel run`. [Test Impact Analysis][1] and automatic [coverage configuration][5] are not supported for Bazel. diff --git a/hugo/content/en/tests/setup/bazel/go.md b/hugo/content/en/tests/setup/bazel/go.md index d2180e21dca..c93886166d0 100644 --- a/hugo/content/en/tests/setup/bazel/go.md +++ b/hugo/content/en/tests/setup/bazel/go.md @@ -17,7 +17,7 @@ further_reading: --- -Datadog provides official Bazel rules for Go Test Optimization. Guided bootstrap writes a local `dd_go_test` wrapper that calls Datadog's `dd_topt_go_test` macro with the recommended Test Optimization defaults. Use `dd_go_test` in package `BUILD.bazel` files after running bootstrap. Use `dd_topt_go_test` directly when you maintain your own wrapper or need to set Datadog attributes such as `orchestrion_mode`. +Datadog provides official Bazel rules for Go Test Optimization. Guided bootstrap writes a local `dd_go_test` wrapper that calls Datadog's `dd_topt_go_test` macro with the recommended {{< prodname >}}Test Optimization{{< /prodname >}} defaults. Use `dd_go_test` in package `BUILD.bazel` files after running bootstrap. Use `dd_topt_go_test` directly when you maintain your own wrapper or need to set Datadog attributes such as `orchestrion_mode`. ## Compatibility @@ -40,7 +40,7 @@ Use the following minimum versions: ## Prerequisites -Before setting up Test Optimization for Go tests in Bazel: +Before setting up {{< prodname >}}Test Optimization{{< /prodname >}} for Go tests in Bazel: - Configure a Datadog API key in your CI secret store. - Set `DD_SITE` to your Datadog site, such as `datadoghq.com`. @@ -146,7 +146,7 @@ dd_go_test( ) ``` -Use `embed = [":pkg_lib"]` so the macro can infer the Go import path from `rules_go` providers and select the matching per-module Test Optimization metadata. +Use `embed = [":pkg_lib"]` so the macro can infer the Go import path from `rules_go` providers and select the matching per-module {{< prodname >}}Test Optimization{{< /prodname >}} metadata. If you use a manual wrapper instead of guided bootstrap, call `dd_topt_go_test` and set `orchestrion_mode = "test_optimization"` for the faster standard-library `testing` path: @@ -194,13 +194,13 @@ bazel run --config=test-optimization //:dd_upload_payloads -- --dry-run --valida DD_API_KEY= DD_SITE= bazel run --config=test-optimization //:dd_upload_payloads ``` -You do not need to set the Test Optimization runtime variables manually. The `dd_topt_go_test` macro adds them to the generated test target, including: +You do not need to set the {{< prodname >}}Test Optimization{{< /prodname >}} runtime variables manually. The `dd_topt_go_test` macro adds them to the generated test target, including: `DD_CIVISIBILITY_ENABLED` : Enables Test Optimization for the Go test process. `DD_TEST_OPTIMIZATION_MANIFEST_FILE` -: Points the Go test process to the synced Test Optimization metadata. +: Points the Go test process to the synced {{< prodname >}}Test Optimization{{< /prodname >}} metadata. `DD_TEST_OPTIMIZATION_PAYLOADS_IN_FILES` : Configures payloads to be written as JSON files under `TEST_UNDECLARED_OUTPUTS_DIR`. @@ -225,7 +225,7 @@ bazel run @datadog-rules-test-optimization-go//:dd_topt_go_bootstrap -- \ Use `--rules-go-variant complete` only when the repository needs the extended monorepo compatibility variant. -Keep repository-specific scheduling, tags, flaky policy, Docker defaults, and platform constraints in your local wrapper. The optimized wrapper should own only Test Optimization wiring, Orchestrion mode, and pin files. +Keep repository-specific scheduling, tags, flaky policy, Docker defaults, and platform constraints in your local wrapper. The optimized wrapper should own only {{< prodname >}}Test Optimization{{< /prodname >}} wiring, Orchestrion mode, and pin files. ## Known limitations diff --git a/hugo/content/en/tests/setup/bazel/java.md b/hugo/content/en/tests/setup/bazel/java.md index f778758ad04..a9b15c70629 100644 --- a/hugo/content/en/tests/setup/bazel/java.md +++ b/hugo/content/en/tests/setup/bazel/java.md @@ -17,7 +17,7 @@ further_reading: --- -Datadog provides official Bazel rules for Java Test Optimization. Use `dd_topt_java_test` to configure Java test targets to run with the Datadog Java tracer and write Test Optimization payloads during Bazel test execution. +Datadog provides official Bazel rules for Java Test Optimization. Use `dd_topt_java_test` to configure Java test targets to run with the Datadog Java tracer and write {{< prodname >}}Test Optimization{{< /prodname >}} payloads during Bazel test execution. ## Compatibility @@ -30,11 +30,11 @@ Use the following minimum versions: | Java runtime example | `>=17` | | `dd-java-agent` example | `>=1.60.0` | -The Datadog Bazel rule is the official Test Optimization setup path for Java tests that run with Bazel. +The Datadog Bazel rule is the official {{< prodname >}}Test Optimization{{< /prodname >}} setup path for Java tests that run with Bazel. ## Prerequisites -Before setting up Test Optimization for Java tests in Bazel: +Before setting up {{< prodname >}}Test Optimization{{< /prodname >}} for Java tests in Bazel: - Configure a Datadog API key in your CI secret store. - Set `DD_SITE` to your Datadog site, such as `datadoghq.com`. @@ -167,7 +167,7 @@ dd_topt_java_test( ) ``` -The macro injects the Datadog Java tracer with `-javaagent` and adds the agent JAR to test runtime data. It also enables Test Optimization for the Java test process and configures payloads to be written as JSON files under `TEST_UNDECLARED_OUTPUTS_DIR`. +The macro injects the Datadog Java tracer with `-javaagent` and adds the agent JAR to test runtime data. It also enables {{< prodname >}}Test Optimization{{< /prodname >}} for the Java test process and configures payloads to be written as JSON files under `TEST_UNDECLARED_OUTPUTS_DIR`. ### Optional parameters diff --git a/hugo/content/en/tests/setup/bazel/python.md b/hugo/content/en/tests/setup/bazel/python.md index 8bc8074b7cb..a207f87b84d 100644 --- a/hugo/content/en/tests/setup/bazel/python.md +++ b/hugo/content/en/tests/setup/bazel/python.md @@ -17,7 +17,7 @@ further_reading: --- -Datadog provides official Bazel rules for Python Test Optimization. Use `dd_topt_py_test` to configure `pytest` targets to read synced Test Optimization metadata and write payloads during Bazel test execution. +Datadog provides official Bazel rules for Python Test Optimization. Use `dd_topt_py_test` to configure `pytest` targets to read synced {{< prodname >}}Test Optimization{{< /prodname >}} metadata and write payloads during Bazel test execution. ## Compatibility @@ -37,7 +37,7 @@ The repository that consumes the Bazel rule owns Python toolchains, `pytest`, `d ## Prerequisites -Before setting up Test Optimization for Python tests in Bazel: +Before setting up {{< prodname >}}Test Optimization{{< /prodname >}} for Python tests in Bazel: - Configure a Datadog API key in your CI secret store. - Set `DD_SITE` to your Datadog site, such as `datadoghq.com`. @@ -161,7 +161,7 @@ dd_topt_py_test( ) ``` -By default, `dd_topt_py_test` uses `runner_mode = "managed_pytest"`. In this mode, the macro runs the bundled pytest entry point. It sets `PYTEST_ADDOPTS=--ddtrace` when you have not already configured it, and passes the Test Optimization metadata path to the test process. +By default, `dd_topt_py_test` uses `runner_mode = "managed_pytest"`. In this mode, the macro runs the bundled pytest entry point. It sets `PYTEST_ADDOPTS=--ddtrace` when you have not already configured it, and passes the {{< prodname >}}Test Optimization{{< /prodname >}} metadata path to the test process. ## Use a repository-owned pytest wrapper diff --git a/hugo/content/en/tests/setup/dotnet.md b/hugo/content/en/tests/setup/dotnet.md index 9c087f93901..347f95d6028 100644 --- a/hugo/content/en/tests/setup/dotnet.md +++ b/hugo/content/en/tests/setup/dotnet.md @@ -283,7 +283,7 @@ For more information about how to add spans and tags for custom instrumentation, Note: To use the manual testing API, you must add the Datadog.Trace NuGet package in the target .NET project. -If you use XUnit, NUnit, or MSTest with your .NET projects, Test Optimization automatically instruments them and sends the test results to Datadog. If you use an unsupported testing framework or if you have a different testing mechanism, you can instead use the API to report test results to Datadog. +If you use XUnit, NUnit, or MSTest with your .NET projects, {{< prodname >}}Test Optimization{{< /prodname >}} automatically instruments them and sends the test results to Datadog. If you use an unsupported testing framework or if you have a different testing mechanism, you can instead use the API to report test results to Datadog. The API is based around three concepts: test module, test suites, and tests. diff --git a/hugo/content/en/tests/setup/go.md b/hugo/content/en/tests/setup/go.md index f43039189b1..6801a872aca 100644 --- a/hugo/content/en/tests/setup/go.md +++ b/hugo/content/en/tests/setup/go.md @@ -107,7 +107,7 @@ In addition to this, Orchestrion only supports projects using [Go modules][go-mo Set the following environment variables to configure the library: `DD_CIVISIBILITY_ENABLED=true` (Required) -: Enables the Test Optimization product. +: Enables the {{< prodname >}}Test Optimization{{< /prodname >}} product. `DD_ENV` (Required) : Environment where the tests are being run (for example: `local` when running tests on a developer workstation or `ci` when running them on a CI provider). diff --git a/hugo/content/en/tests/setup/java.md b/hugo/content/en/tests/setup/java.md index 847ff27b856..49236dc2bba 100644 --- a/hugo/content/en/tests/setup/java.md +++ b/hugo/content/en/tests/setup/java.md @@ -114,7 +114,7 @@ You can run the `java -jar $DD_TRACER_FOLDER/dd-java-agent.jar` command to check Set the following environment variables to configure the SDK: `DD_CIVISIBILITY_ENABLED=true` (Required) -: Enables the Test Optimization product. +: Enables the {{< prodname >}}Test Optimization{{< /prodname >}} product. `DD_ENV` : Environment where the tests are being run (for example: `local` when running tests on a developer workstation or `ci` when running them on a CI provider). @@ -139,7 +139,7 @@ Run your tests as you normally do (for example: `mvn test` or `mvn verify`). Set the following environment variables to configure the SDK: `DD_CIVISIBILITY_ENABLED=true` (Required) -: Enables the Test Optimization product. +: Enables the {{< prodname >}}Test Optimization{{< /prodname >}} product. `DD_ENV` : Environment where the tests are being run (for example: `local` when running tests on a developer workstation or `ci` when running them on a CI provider). @@ -161,7 +161,7 @@ Run your tests as you normally do (for example: `./gradlew clean test`). Set the following environment variables to configure the SDK: `DD_CIVISIBILITY_ENABLED=true` (Required) -: Enables the Test Optimization product. +: Enables the {{< prodname >}}Test Optimization{{< /prodname >}} product. `DD_TEST_SESSION_NAME` : Identifies a group of tests (for example: `unit-tests` or `integration-tests`). @@ -186,7 +186,7 @@ Run your tests as you normally do (for example: `sbt test`). Set the following environment variables to configure the SDK: `DD_CIVISIBILITY_ENABLED=true` (Required) -: Enables the Test Optimization product. +: Enables the {{< prodname >}}Test Optimization{{< /prodname >}} product. `DD_TEST_SESSION_NAME` : Identifies a group of tests (for example: `unit-tests` or `integration-tests`). @@ -445,7 +445,7 @@ Always call ``datadog.trace.api.civisibility.DDTestSession#end`` at the end so t ### Deterministic test parameters representation -Test Optimization works best when the [test parameters are deterministic][8] and stay the same between test runs. +{{< prodname >}}Test Optimization{{< /prodname >}} works best when the [test parameters are deterministic][8] and stay the same between test runs. If a test case has a parameter that varies between test executions (such as a current date, a random number, or an instance of a class whose `toString()` method is not overridden), some of the product features may not work as expected. For example, the history of executions may not be available, or the test case may not be classified as flaky even if it exhibits flakiness. @@ -527,7 +527,7 @@ A common mistake is to set the variables in a build step and run the tests in an Ensure that you are using the latest version of the SDK. -Verify that your build system and testing framework are supported by Test Optimization. See the list of [supported build systems and test frameworks](#compatibility). +Verify that your build system and testing framework are supported by {{< prodname >}}Test Optimization{{< /prodname >}}. See the list of [supported build systems and test frameworks](#compatibility). Ensure that the `dd.civisibility.enabled` property (or `DD_CIVISIBILITY_ENABLED` environment variable) is set to `true` in the SDK arguments. @@ -536,7 +536,7 @@ Check the build output for any errors that indicate tracer misconfiguration, suc ### Tests or source code compilation fails when building a project with the SDK attached -By default, Test Optimization runs Java code compilation with a compiler plugin attached. +By default, {{< prodname >}}Test Optimization{{< /prodname >}} runs Java code compilation with a compiler plugin attached. The plugin is optional, as it only serves to reduce the performance overhead. diff --git a/hugo/content/en/tests/setup/javascript.md b/hugo/content/en/tests/setup/javascript.md index dec4329c6e5..dace86df3da 100644 --- a/hugo/content/en/tests/setup/javascript.md +++ b/hugo/content/en/tests/setup/javascript.md @@ -206,7 +206,7 @@ If the browser application being tested is instrumented using [Browser Monitorin ### Upload test failure screenshots -When enabled, Test Optimization uploads screenshots that Playwright captures when a test fails. View the screenshots in the {{< ui >}}Media{{< /ui >}} tab of the Test Optimization test details side panel. Use them to inspect browser state at the time of failure. +When enabled, {{< prodname >}}Test Optimization{{< /prodname >}} uploads screenshots that Playwright captures when a test fails. View the screenshots in the {{< ui >}}Media{{< /ui >}} tab of the {{< prodname >}}Test Optimization{{< /prodname >}} test details side panel. Use them to inspect browser state at the time of failure. {{< img src="continuous_integration/tests/setup/playwright-failure-screenshot-media-tab.png" alt="A Playwright failure screenshot displayed in the Media tab of the Test Optimization test details side panel." style="width:100%;" >}} @@ -218,7 +218,7 @@ To enable screenshot uploads, set the `DD_TEST_FAILURE_SCREENSHOTS_ENABLED` envi - `'only-on-failure'`: Capture screenshot after each test failure. - `'on-first-failure'`: Capture screenshot after each test's first failure. -**Note**: If you use `'on'`, Test Optimization only uploads screenshots from failed tests. +**Note**: If you use `'on'`, {{< prodname >}}Test Optimization{{< /prodname >}} only uploads screenshots from failed tests. [1]: /tracing/trace_collection/custom_instrumentation/nodejs?tab=locally#adding-tags [2]: /tests/guides/add_custom_measures/?tab=javascripttypescript @@ -423,7 +423,7 @@ If the browser application being tested is instrumented using [Browser Monitorin ### Upload test failure screenshots -When enabled, Test Optimization uploads screenshots that Cypress captures when a test fails. They appear in the {{< ui >}}Media{{< /ui >}} tab of the Test Optimization test details side panel. Use them to inspect browser state at the time of failure. +When enabled, {{< prodname >}}Test Optimization{{< /prodname >}} uploads screenshots that Cypress captures when a test fails. They appear in the {{< ui >}}Media{{< /ui >}} tab of the {{< prodname >}}Test Optimization{{< /prodname >}} test details side panel. Use them to inspect browser state at the time of failure. {{< img src="continuous_integration/tests/setup/cypress-failure-screenshot-media-tab.png" alt="A Cypress failure screenshot displayed in the Media tab of the Test Optimization test details side panel." style="width:100%;" >}} @@ -626,7 +626,7 @@ For more information about `service` and `env` reserved tags, see [Unified Servi Note: The manual testing API is available starting in dd-trace versions 5.23.0 and 4.47.0. -If you use Jest, Mocha, Cypress, Playwright, Cucumber, or Vitest, **do not use the manual testing API**, as Test Optimization automatically instruments them and sends the test results to Datadog. The manual testing API is **incompatible** with already supported testing frameworks. +If you use Jest, Mocha, Cypress, Playwright, Cucumber, or Vitest, **do not use the manual testing API**, as {{< prodname >}}Test Optimization{{< /prodname >}} automatically instruments them and sends the test results to Datadog. The manual testing API is **incompatible** with already supported testing frameworks. Use the manual testing API only if you use an unsupported testing framework or have a different testing mechanism. @@ -742,7 +742,7 @@ If you want visibility into the browser process, consider using [RUM & Session R ### Cypress interactive mode -Cypress interactive mode (which you can enter by running `cypress open`) is not supported by Test Optimization because some cypress events, such as [`before:run`][11], are not fired. If you want to try it anyway, pass `experimentalInteractiveRunEvents: true` to the [cypress configuration file][12]. +Cypress interactive mode (which you can enter by running `cypress open`) is not supported by {{< prodname >}}Test Optimization{{< /prodname >}} because some cypress events, such as [`before:run`][11], are not fired. If you want to try it anyway, pass `experimentalInteractiveRunEvents: true` to the [cypress configuration file][12]. ### Jest's `--forceExit` Jest's [--forceExit][15] option may cause data loss. Datadog tries to send data immediately after your tests finish, but shutting down the process abruptly can cause some requests to fail. Use `--forceExit` with caution. @@ -770,7 +770,7 @@ Because this mode does not initialize `dd-trace` in Vitest workers, the followin ## Best practices -Follow these practices to take full advantage of the testing framework and Test Optimization. +Follow these practices to take full advantage of the testing framework and {{< prodname >}}Test Optimization{{< /prodname >}}. ### Parameterized tests @@ -806,7 +806,7 @@ forEach([ }); {{< /code-block >}} -When you use this approach, both the testing framework and Test Optimization can tell your tests apart. +When you use this approach, both the testing framework and {{< prodname >}}Test Optimization{{< /prodname >}} can tell your tests apart. ### Test session name `DD_TEST_SESSION_NAME` diff --git a/hugo/content/en/tests/setup/junit_xml.md b/hugo/content/en/tests/setup/junit_xml.md index 4b06bd47713..6c54fd7fe26 100644 --- a/hugo/content/en/tests/setup/junit_xml.md +++ b/hugo/content/en/tests/setup/junit_xml.md @@ -246,7 +246,7 @@ See [Providing metadata with XPath expressions](#providing-metadata-with-xpath-e : Enable forwarding content from the XML reports as [Logs][6]. The content inside ``, ``, and `` is collected as logs. Logs from elements inside a `` are automatically connected to the test.
    **Environment variable**: `DD_CIVISIBILITY_LOGS_ENABLED`
    **Default**: `false`
    -**Note**: Logs are billed separately from Test Optimization. +**Note**: Logs are billed separately from {{< prodname >}}Test Optimization{{< /prodname >}}. `--max-concurrency` : The number of concurrent uploads to the API.
    diff --git a/hugo/content/en/tests/setup/python.md b/hugo/content/en/tests/setup/python.md index ca0a62c021c..7fe4b8a9c3b 100644 --- a/hugo/content/en/tests/setup/python.md +++ b/hugo/content/en/tests/setup/python.md @@ -185,7 +185,7 @@ Test execution has two phases: The distinct discovery and execution phases allow for a gap between the test runner process collecting the tests and the tests starting. -API users must provide consistent identifiers (described below) that are used as references for Test Optimization items within the API's state storage. +API users must provide consistent identifiers (described below) that are used as references for {{< prodname >}}Test Optimization{{< /prodname >}} items within the API's state storage. ##### Enable `test_visibility` @@ -201,7 +201,7 @@ Modules, suites, and tests form a hierarchy in the Python Test Optimization API, ##### Test session -A test session represents a project's test execution, typically corresponding to the execution of a test command. Only one session can be discovered, started, and finished in the execution of Test Optimization program. +A test session represents a project's test execution, typically corresponding to the execution of a test command. Only one session can be discovered, started, and finished in the execution of {{< prodname >}}Test Optimization{{< /prodname >}} program. Call `ddtrace.ext.test_visibility.api.TestSession.discover()` to discover the session, passing the test command, a given framework name, and version. diff --git a/hugo/content/en/tests/setup/ruby.md b/hugo/content/en/tests/setup/ruby.md index e87b678e063..d33208de8d3 100644 --- a/hugo/content/en/tests/setup/ruby.md +++ b/hugo/content/en/tests/setup/ruby.md @@ -100,7 +100,7 @@ bundle exec ddcirb exec rspec The following is a list of the most important configuration settings that can be used with the test optimization library: `DD_CIVISIBILITY_ENABLED=true` (Required) -: Enables the Test Optimization product. +: Enables the {{< prodname >}}Test Optimization{{< /prodname >}} product. **Default**: `false` `DD_ENV` (Required) @@ -174,7 +174,7 @@ You can enable automatic APM instrumentation by adding the following line in you require "datadog/auto_instrument" if ENV["DD_ENV"] == "ci" ``` -**Note**: In CI mode, these traces are submitted to Test Optimization, and they do **not** show up in Datadog APM. +**Note**: In CI mode, these traces are submitted to {{< prodname >}}Test Optimization{{< /prodname >}}, and they do **not** show up in {{< prodname >}}Datadog APM{{< /prodname >}}. For the full list of available instrumentation methods, see the [tracing documentation][6] @@ -184,7 +184,7 @@ For the full list of available instrumentation methods, see the [tracing documen ## Using library's public API for unsupported test frameworks -If you use RSpec, Minitest, or Cucumber, **do not use the manual testing API**, as Test Optimization automatically instruments them and sends the test results to Datadog. The manual testing API is **incompatible** with already supported testing frameworks. +If you use RSpec, Minitest, or Cucumber, **do not use the manual testing API**, as {{< prodname >}}Test Optimization{{< /prodname >}} automatically instruments them and sends the test results to Datadog. The manual testing API is **incompatible** with already supported testing frameworks. Use the manual testing API only if you use an unsupported testing framework or have a different testing mechanism. Full public API documentation is available on [YARD site][8]. diff --git a/hugo/content/en/tests/setup/swift.md b/hugo/content/en/tests/setup/swift.md index ce9f7daeaed..238b229863a 100644 --- a/hugo/content/en/tests/setup/swift.md +++ b/hugo/content/en/tests/setup/swift.md @@ -637,7 +637,7 @@ Additional Git configuration for physical device testing: ## Best practices -Follow these practices to take full advantage of the testing framework and Test Optimization. +Follow these practices to take full advantage of the testing framework and {{< prodname >}}Test Optimization{{< /prodname >}}. ### Generate symbols file when building diff --git a/hugo/content/en/tests/swift_tests.md b/hugo/content/en/tests/swift_tests.md index e1ccad2769d..38c8eae2b15 100644 --- a/hugo/content/en/tests/swift_tests.md +++ b/hugo/content/en/tests/swift_tests.md @@ -16,7 +16,7 @@ further_reading: ## Overview -Ensure that [Test Optimization][3] is already set up for Swift. +Ensure that [{{< prodname >}}Test Optimization{{< /prodname >}}][3] is already set up for Swift. ### Compatibility @@ -29,7 +29,7 @@ The Test Optimization - RUM integration is available for these versions of `dd-s If you link `dd-sdk-swift-testing` for your UI tests bundle and the application being tested is instrumented using [Real User Monitoring][1], your test results and their generated RUM application sessions and session replays are automatically linked. -A {{< ui >}}RUM Sessions{{< /ui >}} tab appears in the Test Optimization test detail side panel. +A {{< ui >}}RUM Sessions{{< /ui >}} tab appears in the {{< prodname >}}Test Optimization{{< /prodname >}} test detail side panel. {{< img src="ci/ci-swift-rum-session-tab.png" alt="Browser Session Tab in Test Detail" style="width:100%;">}} diff --git a/hugo/content/en/tests/test_health.md b/hugo/content/en/tests/test_health.md index 10a926db912..d3892c1b3df 100644 --- a/hugo/content/en/tests/test_health.md +++ b/hugo/content/en/tests/test_health.md @@ -24,7 +24,7 @@ further_reading: ## Overview -The [Test Health][5] dashboard provides analytics to help teams manage and optimize their testing in CI. This includes sections showing the current impact of test flakiness and how Test Optimization is mitigating these problems. +The [Test Health][5] dashboard provides analytics to help teams manage and optimize their testing in CI. This includes sections showing the current impact of test flakiness and how {{< prodname >}}Test Optimization{{< /prodname >}} is mitigating these problems. The dashboard also provides [Test Health recommendations](#test-health-recommendations) to suggest specific Datadog features and strategies you can enable to reduce flaky test failures and recover CI time. @@ -116,7 +116,7 @@ The Test Health dashboard provides data-driven, repository-specific suggestions {{< img src="tests/test-health-recommendations.png" alt="Recommendations side panel opened on the Test Health dashboard" style="width:100%;" >}} -Each recommendation estimates how much you can reduce test failures and CI time by enabling a specific Test Optimization feature. Recommendations may include the following: +Each recommendation estimates how much you can reduce test failures and CI time by enabling a specific {{< prodname >}}Test Optimization{{< /prodname >}} feature. Recommendations may include the following: - **[Auto Test Retries][1]**: Retry failing tests to avoid failing your build due to flaky tests. - **[Test Impact Analysis][4]**: Automatically select and run only the relevant tests for a given commit based on the code being changed. diff --git a/hugo/content/en/tests/test_impact_analysis/_index.md b/hugo/content/en/tests/test_impact_analysis/_index.md index 14bd8efee5d..e57a38c1739 100644 --- a/hugo/content/en/tests/test_impact_analysis/_index.md +++ b/hugo/content/en/tests/test_impact_analysis/_index.md @@ -71,7 +71,7 @@ If Test Impact Analysis behaves unexpectedly, see the [Troubleshooting][12] page ## Set up a Datadog library -Before setting up Test Impact Analysis, you must configure [Test Optimization][4] for your particular language. If you are reporting data through the Agent, use v6.40 or 7.40 and later. +Before setting up Test Impact Analysis, you must configure [{{< prodname >}}Test Optimization{{< /prodname >}}][4] for your particular language. If you are reporting data through the Agent, use v6.40 or 7.40 and later. {{< whatsnext desc="Choose a language to set up Test Impact Analysis in Datadog:" >}} {{< nextlink href="intelligent_test_runner/setup/dotnet" >}}.NET{{< /nextlink >}} diff --git a/hugo/content/en/tests/test_impact_analysis/how_it_works.md b/hugo/content/en/tests/test_impact_analysis/how_it_works.md index ace0e28e411..e082d8c3a4a 100644 --- a/hugo/content/en/tests/test_impact_analysis/how_it_works.md +++ b/hugo/content/en/tests/test_impact_analysis/how_it_works.md @@ -31,7 +31,7 @@ Some test selection solutions don't rely on code coverage data and make up for i While other test solutions calculate test impact analysis using code coverage too, they only consider the last commit diff when evaluating which tests to run. As an example, this is a problem with GitHub's pull requests, which only take into account the CI status of the latest commit to allow merging. As a result, you must run all commits through CI or risk skipping tests that should have run. -Test Impact Analysis leverages per-test code coverage information along with data from [Test Optimization][1] to search previous tests in all relevant past commits. Configuration of Test Impact Analysis is a one-click operation in most languages, and the results are accurate and more precise than other methods. +Test Impact Analysis leverages per-test code coverage information along with data from [{{< prodname >}}Test Optimization{{< /prodname >}}][1] to search previous tests in all relevant past commits. Configuration of Test Impact Analysis is a one-click operation in most languages, and the results are accurate and more precise than other methods. ## How test selection works diff --git a/hugo/content/en/tests/test_parallelization/_index.md b/hugo/content/en/tests/test_parallelization/_index.md index 1911a193947..c7a16ead97d 100644 --- a/hugo/content/en/tests/test_parallelization/_index.md +++ b/hugo/content/en/tests/test_parallelization/_index.md @@ -5,7 +5,7 @@ description: Reduce CI testing time by distributing test files across CI nodes o ## Overview -Test Parallelization helps you reduce CI testing time by distributing test files across CI nodes or local workers. It uses Test Optimization data to detect which test files should run, estimate their duration, and create an execution plan. +Test Parallelization helps you reduce CI testing time by distributing test files across CI nodes or local workers. It uses {{< prodname >}}Test Optimization{{< /prodname >}} data to detect which test files should run, estimate their duration, and create an execution plan. Test Parallelization is designed to work with [Test Impact Analysis][1]. Test Impact Analysis skips tests that are not affected by a code change. Test Parallelization splits the remaining test files evenly across the selected CI nodes. @@ -13,7 +13,7 @@ Use Test Parallelization when your test suite takes a long time to run. When use ## Setup -Before setting up Test Parallelization, set up [Test Optimization][2]. Optionally, also set up [Test Impact Analysis][1] if you plan to use it with Test Parallelization. Then follow [Set Up Test Parallelization][3] to install `ddtest` and configure your CI provider. +Before setting up Test Parallelization, set up [{{< prodname >}}Test Optimization{{< /prodname >}}][2]. Optionally, also set up [Test Impact Analysis][1] if you plan to use it with Test Parallelization. Then follow [Set Up Test Parallelization][3] to install `ddtest` and configure your CI provider. ## Compatibility diff --git a/hugo/content/en/tests/test_parallelization/setup.md b/hugo/content/en/tests/test_parallelization/setup.md index e6dcac5838e..c62d799b539 100644 --- a/hugo/content/en/tests/test_parallelization/setup.md +++ b/hugo/content/en/tests/test_parallelization/setup.md @@ -20,7 +20,7 @@ further_reading: Before setting up Test Parallelization: -- Set up [Test Optimization][1]. +- Set up [{{< prodname >}}Test Optimization{{< /prodname >}}][1]. - For Ruby: use the `datadog-ci` gem version `1.31.0` or later. - For Python: use the `ddtrace` package version `4.11.0` or later and `pytest`. - For JavaScript: use the `dd-trace` package version `5.111.0` or later for `v5` or `v6.0.0` or later for `v6`, Node.js, and Jest. @@ -83,7 +83,7 @@ Make these changes on a feature branch. Commit and push each CI configuration ch ### 1. Add test planning -After setting up dependencies and Test Optimization, add `ddtest plan` before your existing test step. Keep the existing test command in place during this step. +After setting up dependencies and {{< prodname >}}Test Optimization{{< /prodname >}}, add `ddtest plan` before your existing test step. Keep the existing test command in place during this step. Choose the minimum and maximum parallelism for your CI environment. For example, the following values allow `ddtest` to choose between 1 and 8 CI nodes or local workers: diff --git a/hugo/content/en/tests/troubleshooting/_index.md b/hugo/content/en/tests/troubleshooting/_index.md index b7ac9de750c..ff018ab1da3 100644 --- a/hugo/content/en/tests/troubleshooting/_index.md +++ b/hugo/content/en/tests/troubleshooting/_index.md @@ -8,7 +8,7 @@ further_reading: ## Overview -This page provides information to help you troubleshot issues with Test Optimization. If you need additional help, contact [Datadog Support][2]. +This page provides information to help you troubleshot issues with {{< prodname >}}Test Optimization{{< /prodname >}}. If you need additional help, contact [Datadog Support][2]. ## RUM sessions and tests are not linked diff --git a/hugo/content/en/tracing/_index.md b/hugo/content/en/tracing/_index.md index d70e74f6637..0d64921cd5b 100644 --- a/hugo/content/en/tracing/_index.md +++ b/hugo/content/en/tracing/_index.md @@ -49,26 +49,26 @@ cascade: {{< learning-center-callout header="Join an enablement webinar session" hide_image="true" btn_title="Sign Up" btn_url="https://www.datadoghq.com/technical-enablement/sessions/?tags.topics-0=APM">}} - Join an introductory or intermediate enablement session to learn more about how Datadog Application Performance Monitoring (APM) provides AI-powered, code-level distributed tracing from browser and mobile applications to backend services and databases. + Join an introductory or intermediate enablement session to learn more about how {{< prodname >}}Datadog Application Performance Monitoring{{< /prodname >}} (APM) provides AI-powered, code-level distributed tracing from browser and mobile applications to backend services and databases. {{< /learning-center-callout >}} ## Overview -Datadog Application Performance Monitoring (APM) provides deep visibility into your applications, enabling you to identify performance bottlenecks, troubleshoot issues, and optimize your services. With distributed tracing, out-of-the-box dashboards, and seamless correlation with other telemetry data, Datadog APM helps ensure the best possible performance and user experience for your applications. +{{< prodname >}}Datadog Application Performance Monitoring{{< /prodname >}} (APM) provides deep visibility into your applications, enabling you to identify performance bottlenecks, troubleshoot issues, and optimize your services. With distributed tracing, out-of-the-box dashboards, and seamless correlation with other telemetry data, {{< prodname >}}Datadog APM{{< /prodname >}} helps ensure the best possible performance and user experience for your applications. -For an introduction to terminology used in Datadog APM, see [APM Terms and Concepts][1]. +For an introduction to terminology used in {{< prodname >}}Datadog APM{{< /prodname >}}, see [APM Terms and Concepts][1]. ## Getting started -The simplest way to start with Datadog APM is with Single Step Instrumentation. This approach installs the Datadog Agent and instruments your application in one step, with no additional configuration steps required. To learn more, read [Single Step Instrumentation][27]. +The simplest way to start with {{< prodname >}}Datadog APM{{< /prodname >}} is with Single Step Instrumentation. This approach installs the Datadog Agent and instruments your application in one step, with no additional configuration steps required. To learn more, read [Single Step Instrumentation][27]. -For setups that require more customization, Datadog supports custom instrumentation with Datadog SDKs and [Dynamic Instrumentation][30] in the Datadog UI. To learn more, read [Application Instrumentation][2]. +For setups that require more customization, Datadog supports custom instrumentation with Datadog SDKs and [{{< prodname >}}Dynamic Instrumentation{{< /prodname >}}][30] in the Datadog UI. To learn more, read [Application Instrumentation][2]. -
    If you're new to Datadog APM, read Getting Started with APM to learn how to send your first trace to Datadog.
    +
    If you're new to {{< prodname >}}Datadog APM{{< /prodname >}}, read Getting Started with APM to learn how to send your first trace to Datadog.
    ## Use cases -Discover some ways Datadog APM can help support your use cases: +Discover some ways {{< prodname >}}Datadog APM{{< /prodname >}} can help support your use cases: | You want to...| How Datadog APM can help | | ----------- | ----------- | @@ -91,7 +91,7 @@ The [service page][26] helps you monitor service performance and [compare betwee ### Correlating traces with other telemetry -Datadog APM integrates seamlessly with logs, real user monitoring (RUM), synthetic monitoring, and more: +{{< prodname >}}Datadog APM{{< /prodname >}} integrates seamlessly with logs, real user monitoring (RUM), synthetic monitoring, and more: - [View your application logs side-by-side with traces][9] to find logs for specific requests, services, or versions. - [Associate RUM sessions with backend traces][10] to understand how backend performance affects user experience. @@ -103,7 +103,7 @@ Datadog APM integrates seamlessly with logs, real user monitoring (RUM), synthet Traces start in your instrumented applications and flow into Datadog. -Datadog APM provides tools to manage the volume and retention of your trace data. Use [Ingestion Controls][6] to adjust sampling rates and [retention filters][7] to control which spans are stored. +{{< prodname >}}Datadog APM{{< /prodname >}} provides tools to manage the volume and retention of your trace data. Use [Ingestion Controls][6] to adjust sampling rates and [retention filters][7] to control which spans are stored. {{< img src="/tracing/apm_lifecycle/apm_lifecycle_0.png" alt="Flow of data through Datadog APM." style="width:100%;" >}} diff --git a/hugo/content/en/tracing/code_origin/_index.md b/hugo/content/en/tracing/code_origin/_index.md index 156fc7f32d2..f0f2f710fcc 100644 --- a/hugo/content/en/tracing/code_origin/_index.md +++ b/hugo/content/en/tracing/code_origin/_index.md @@ -39,8 +39,8 @@ In Trace Explorer, select a span from an enabled service to see Code Origin deta ## Getting started ### Prerequisites -- [Datadog APM][6] is configured to capture spans. -- [Source Code Integration][7] is enabled. +- [{{< prodname >}}Datadog APM{{< /prodname >}}][6] is configured to capture spans. +- [{{< prodname >}}Source Code Integration{{< /prodname >}}][7] is enabled. - Your service meets the [compatibility requirements](#compatibility-requirements). ### Compatibility requirements @@ -94,7 +94,7 @@ In Trace Explorer, select a span from an enabled service to see Code Origin deta {{% tab "Go" %}} -Go services get Code Origin data through [Source Code Integration](#code-origin-coverage-through-source-code-integration) rather than the SDK flag. +Go services get Code Origin data through [{{< prodname >}}Source Code Integration{{< /prodname >}}](#code-origin-coverage-through-source-code-integration) rather than the SDK flag. | Requirement | Frameworks | |---|---| @@ -106,7 +106,7 @@ Go services get Code Origin data through [Source Code Integration](#code-origin- ### Enable Code Origin -Source Code Integration alone can infer some Code Origin details automatically, even for services that don't meet the [compatibility requirements](#compatibility-requirements). See [Code Origin coverage through Source Code Integration](#code-origin-coverage-through-source-code-integration). +{{< prodname >}}Source Code Integration{{< /prodname >}} alone can infer some Code Origin details automatically, even for services that don't meet the [compatibility requirements](#compatibility-requirements). See [Code Origin coverage through Source Code Integration](#code-origin-coverage-through-source-code-integration). Enabling the SDK flag for a compatible language and framework gets you full tracer-instrumented coverage. @@ -117,7 +117,7 @@ export DD_CODE_ORIGIN_FOR_SPANS_ENABLED=true ```
    - For transpiled Node.js applications (for example, TypeScript), make sure to generate and publish source maps with the deployed application, run Node.js with the --enable-source-maps flag, and use v5.59.0 or newer of the Node.js tracer. Otherwise, code previews do not work. See the Node.js Source Code Integration documentation for more details. + For transpiled Node.js applications (for example, TypeScript), make sure to generate and publish source maps with the deployed application, run Node.js with the --enable-source-maps flag, and use v5.59.0 or newer of the Node.js tracer. Otherwise, code previews do not work. See the Node.js {{< prodname >}}Source Code Integration{{< /prodname >}} documentation for more details.
    ## Using Code Origin @@ -165,13 +165,13 @@ export DD_CODE_ORIGIN_FOR_SPANS_ENABLED=true ### Code preview is not visible or the file is not found -- Ensure all [Source Code Integration][7] setup requirements are met, including your `DD_GIT_*` environment variables are configured with the correct values. -- For transpiled Node.js applications (for example, TypeScript), make sure to generate and publish source maps with the deployed application, run Node.js with the [`--enable-source-maps`][10] flag, and use v5.59.0 or newer of the Node.js tracer. Otherwise, code previews will not work. See the Node.js [Source Code Integration][9] documentation for more details. +- Ensure all [{{< prodname >}}Source Code Integration{{< /prodname >}}][7] setup requirements are met, including your `DD_GIT_*` environment variables are configured with the correct values. +- For transpiled Node.js applications (for example, TypeScript), make sure to generate and publish source maps with the deployed application, run Node.js with the [`--enable-source-maps`][10] flag, and use v5.59.0 or newer of the Node.js tracer. Otherwise, code previews will not work. See the Node.js [{{< prodname >}}Source Code Integration{{< /prodname >}}][9] documentation for more details. - Code Origin is designed to reference user code only, but in some cases, third-party code references may slip through. You can report these cases to [Datadog support][13] and help improve these references. ## Code Origin coverage through Source Code Integration -[Source Code Integration][7] (for example, with GitHub, GitLab, or Azure DevOps) is required as a [prerequisite](#prerequisites). On its own, it uses static analysis of your repository to automatically determine code locations for some languages and frameworks, without meeting the other requirements. +[{{< prodname >}}Source Code Integration{{< /prodname >}}][7] (for example, with GitHub, GitLab, or Azure DevOps) is required as a [prerequisite](#prerequisites). On its own, it uses static analysis of your repository to automatically determine code locations for some languages and frameworks, without meeting the other requirements. To get full tracer-instrumented coverage for the languages and frameworks listed in [compatibility requirements](#compatibility-requirements), also [enable Code Origin](#enable-code-origin) in your SDK. Data from both methods appears in the same Code Origin section of the Trace Explorer and powers the same [IDE integration](#in-your-ide) and [Live Debugger](#in-the-trace-explorer) workflows. diff --git a/hugo/content/en/tracing/error_tracking/_index.md b/hugo/content/en/tracing/error_tracking/_index.md index e4a452359bb..8f85ce38fef 100644 --- a/hugo/content/en/tracing/error_tracking/_index.md +++ b/hugo/content/en/tracing/error_tracking/_index.md @@ -26,7 +26,7 @@ algolia: ## Setup -Error Tracking is available for all languages supported by APM. It requires no additional SDK and no configuration changes. +{{< prodname >}}Error Tracking{{< /prodname >}} is available for all languages supported by APM. It requires no additional SDK and no configuration changes. Optionally, to see code snippets in your stack traces, set up the [GitHub integration][4]. @@ -40,11 +40,11 @@ The Datadog SDKs collect errors through integrations and the manual instrumentat {{< img src="tracing/error_tracking/flamegraph_with_errors.png" alt="Flame graph with errors" style="width:100%;" >}} -Error Tracking computes a fingerprint for each error span it processes using the error type, the error message, and the frames that form the stack trace. Errors with the same fingerprint are grouped together and belong to the same issue. For more information, see the [Trace Explorer documentation][2]. +{{< prodname >}}Error Tracking{{< /prodname >}} computes a fingerprint for each error span it processes using the error type, the error message, and the frames that form the stack trace. Errors with the same fingerprint are grouped together and belong to the same issue. For more information, see the [Trace Explorer documentation][2]. ## Control which errors are tracked -Error Tracking automatically processes all error spans, but you can control which errors are ingested and how they are managed: +{{< prodname >}}Error Tracking{{< /prodname >}} automatically processes all error spans, but you can control which errors are ingested and how they are managed: - **Filter errors with inclusion and exclusion rules**: Define rules to include or exclude errors based on attributes such as service, environment, or error type. See [Manage Data Collection][7]. - **Set rate limits**: Control the volume of errors ingested per day to manage costs. See [Manage Data Collection][7]. @@ -53,7 +53,7 @@ Error Tracking automatically processes all error spans, but you can control whic ## Examine issues to start troubleshooting or debugging -Error Tracking automatically categorizes errors into issues collected from your backend services in the [Error Tracking Explorer][5]. See the [Error Tracking Explorer documentation][3] for a tour of key features. +{{< prodname >}}Error Tracking{{< /prodname >}} automatically categorizes errors into issues collected from your backend services in the [Error Tracking Explorer][5]. See the [Error Tracking Explorer documentation][3] for a tour of key features. Issues created from APM include the distribution of impacted spans, the latest most relevant stack trace, span attributes, host tags, container tags, and metrics. diff --git a/hugo/content/en/tracing/error_tracking/error_tracking_assistant.md b/hugo/content/en/tracing/error_tracking/error_tracking_assistant.md index 9721e4c37b8..8ea0b7f2d12 100644 --- a/hugo/content/en/tracing/error_tracking/error_tracking_assistant.md +++ b/hugo/content/en/tracing/error_tracking/error_tracking_assistant.md @@ -26,7 +26,7 @@ The Error Tracking Assistant in APM Error Tracking provides a summary of your er Supported languages : Python, Java -The Error Tracking Assistant requires [Source Code Integration][3]. To enable Source Code Integration: +The Error Tracking Assistant requires [{{< prodname >}}Source Code Integration{{< /prodname >}}][3]. To enable {{< prodname >}}Source Code Integration{{< /prodname >}}: 1. Go to {{< ui >}}Integrations{{< /ui >}} and choose {{< ui >}}Link Source Code{{< /ui >}} in the top navbar. 2. Follow the steps to associate a commit with your telemetry and configure your GitHub repository. @@ -39,7 +39,7 @@ The Error Tracking Assistant requires [Source Code Integration][3]. To enable So ## Getting started 1. Navigate to [{{< ui >}}APM{{< /ui >}} > {{< ui >}}Error Tracking{{< /ui >}}][4]. -2. Click into any Error Tracking issue to view the new {{< ui >}}Generate test & fix{{< /ui >}} section. +2. Click into any {{< prodname >}}Error Tracking{{< /prodname >}} issue to view the new {{< ui >}}Generate test & fix{{< /ui >}} section. {{< img src="tracing/error_tracking/error_tracking_assistant.png" alt="Error Tracking Assistant" style="width:80%" >}} @@ -47,7 +47,7 @@ The Error Tracking Assistant requires [Source Code Integration][3]. To enable So If you aren't seeing generated suggestions: -1. Ensure that [Source Code Integration][2] with the Github Integration is correctly configured. +1. Ensure that [{{< prodname >}}Source Code Integration{{< /prodname >}}][2] with the Github Integration is correctly configured. 2. Enhance Error Tracking Assistant suggestions by enrolling in the [Python Executional Context Beta][1]. ## Further Reading diff --git a/hugo/content/en/tracing/faq/_index.md b/hugo/content/en/tracing/faq/_index.md index 7fe9b9eace8..e8effed0ca3 100644 --- a/hugo/content/en/tracing/faq/_index.md +++ b/hugo/content/en/tracing/faq/_index.md @@ -8,5 +8,5 @@ cascade: {{< whatsnext desc="List of Frequently Asked Questions:">}} {{< nextlink href="tracing/faq/resource-trace-doesn-t-show-up-under-correct-service" >}}Resource/Trace doesn't show up under correct Service{{< /nextlink >}} {{< nextlink href="tracing/faq/my-trace-agent-log-renders-empty-service-error" >}}My trace-agent.log renders "empty `Service`" error{{< /nextlink >}} - {{< nextlink href="tracing/faq/if-i-instrument-a-database-with-datadog-apm-will-there-be-sensitive-database-data-sent-to-datadog" >}}If I instrument a database with Datadog APM, will there be sensitive database data sent to Datadog?{{< /nextlink >}} + {{< nextlink href="tracing/faq/if-i-instrument-a-database-with-datadog-apm-will-there-be-sensitive-database-data-sent-to-datadog" >}}If I instrument a database with {{< prodname >}}Datadog APM{{< /prodname >}}, will there be sensitive database data sent to Datadog?{{< /nextlink >}} {{< /whatsnext >}} diff --git a/hugo/content/en/tracing/faq/trace_sampling_and_storage.md b/hugo/content/en/tracing/faq/trace_sampling_and_storage.md index 4cf7d381b04..d4614a477fd 100644 --- a/hugo/content/en/tracing/faq/trace_sampling_and_storage.md +++ b/hugo/content/en/tracing/faq/trace_sampling_and_storage.md @@ -35,7 +35,7 @@ Statistics (requests, errors, latency, etc.), are calculated based on the full v ### Statistics -Datadog APM computes following aggregate statistics over all the traces instrumented, regardless of sampling: +{{< prodname >}}Datadog APM{{< /prodname >}} computes following aggregate statistics over all the traces instrumented, regardless of sampling: * Total requests and requests per second * Total errors and errors per second diff --git a/hugo/content/en/tracing/guide/_index.md b/hugo/content/en/tracing/guide/_index.md index 7ca8d54a8b5..13003d7b725 100644 --- a/hugo/content/en/tracing/guide/_index.md +++ b/hugo/content/en/tracing/guide/_index.md @@ -29,7 +29,7 @@ cascade: ### Tutorials: Enabling Tracing -These tutorials walk you through setting up a sample multi-service application with automatic and custom/manual instrumentation, and configuring the stack until you see traces in Datadog APM. The tutorials all do the same thing, but with different programming languages and infrastructure setups. Choose the one most like your development and deployment environment to learn the basics of getting started with APM. +These tutorials walk you through setting up a sample multi-service application with automatic and custom/manual instrumentation, and configuring the stack until you see traces in {{< prodname >}}Datadog APM{{< /prodname >}}. The tutorials all do the same thing, but with different programming languages and infrastructure setups. Choose the one most like your development and deployment environment to learn the basics of getting started with APM. {{< whatsnext desc="Choose your language and environment:" >}} {{< nextlink href="tracing/guide/tutorial-enable-python-host" >}}{{< img src="/integrations_logos/python-avatar.png" inline="true">}} {{< img src="tracing/guide/tutorials/tutorial-host-icon.png" inline="true">}} Enabling Tracing on a Python Application on the Same Host as Datadog Agent{{< /nextlink >}} diff --git a/hugo/content/en/tracing/guide/apm_dashboard.md b/hugo/content/en/tracing/guide/apm_dashboard.md index 2ef78051e61..92d7b0606d7 100644 --- a/hugo/content/en/tracing/guide/apm_dashboard.md +++ b/hugo/content/en/tracing/guide/apm_dashboard.md @@ -20,7 +20,7 @@ _4 minutes to complete_ {{< img src="tracing/guide/apm_dashboard/dashboard_7_cropped.mp4" alt="dashboard 7" video="true" style="width:90%;">}} -Datadog APM allows you to create dashboards based on your business priorities and metrics important to you: +{{< prodname >}}Datadog APM{{< /prodname >}} allows you to create dashboards based on your business priorities and metrics important to you: You can create widgets on these dashboards to keep track of any traditional infrastructure, logs and custom metrics like host memory usage alongside critical APM metrics based on throughput, latency, and error rate for correlation. Next to these you can track latency of the user experience of your top customers or largest transactions and alongside these keep track of the throughput of your main web server ahead of any major events like Black Friday. diff --git a/hugo/content/en/tracing/guide/ingestion_sampling_use_cases.md b/hugo/content/en/tracing/guide/ingestion_sampling_use_cases.md index 34b2873c0ab..6e867a43237 100644 --- a/hugo/content/en/tracing/guide/ingestion_sampling_use_cases.md +++ b/hugo/content/en/tracing/guide/ingestion_sampling_use_cases.md @@ -10,7 +10,7 @@ further_reading: ## Overview -Trace data tends to be repetitive. A problem in your application is rarely identified in only one trace and no others. For high throughput services, particularly for incidents that require your attention, an issue shows symptoms repeatedly in multiple traces. Consequently, there's usually no need for you to collect every single trace for a service or endpoint, or every span within a trace. Datadog APM [ingestion control mechanisms][1] help you keep the visibility that you need to troubleshoot problems, while cutting down the noise and managing costs. +Trace data tends to be repetitive. A problem in your application is rarely identified in only one trace and no others. For high throughput services, particularly for incidents that require your attention, an issue shows symptoms repeatedly in multiple traces. Consequently, there's usually no need for you to collect every single trace for a service or endpoint, or every span within a trace. {{< prodname >}}Datadog APM{{< /prodname >}} [ingestion control mechanisms][1] help you keep the visibility that you need to troubleshoot problems, while cutting down the noise and managing costs. Ingestion mechanisms are configurations within the Datadog Agent and Datadog SDKs. If you are using OpenTelemetry SDKs to instrument your applications, read [Ingestion Sampling with OpenTelemetry][2]. diff --git a/hugo/content/en/tracing/guide/instrument_custom_method.md b/hugo/content/en/tracing/guide/instrument_custom_method.md index 2142c9203e4..4e159e344b2 100644 --- a/hugo/content/en/tracing/guide/instrument_custom_method.md +++ b/hugo/content/en/tracing/guide/instrument_custom_method.md @@ -27,7 +27,7 @@ _8 minutes to complete_
    This page describes using OpenTracing to custom instrument applications. OpenTracing is deprecated. The concepts presented here still apply, but follow the Custom Instrumentation with OpenTelemetry instructions and examples for your language instead.
    -To provide you with deep visibility into your business logic, Datadog APM allows you to customize the spans that make up your traces based on your needs and implementation. This empowers you to trace any method in your codebase and even specific components within methods. You can use this to optimize and monitor critical areas of your application at the granularity that works for you. +To provide you with deep visibility into your business logic, {{< prodname >}}Datadog APM{{< /prodname >}} allows you to customize the spans that make up your traces based on your needs and implementation. This empowers you to trace any method in your codebase and even specific components within methods. You can use this to optimize and monitor critical areas of your application at the granularity that works for you. Datadog instruments many frameworks out-of-the-box, such as web services, databases, and caches, and enables you to instrument your own business logic to have the exact visibility you need. By creating spans for methods, you can optimize timing and track errors using the APM flame graph and monitors. @@ -43,7 +43,7 @@ The `http.request POST /charge/` span is taking a lot of time without having any {{< programming-lang-wrapper langs="java,python,ruby,go,nodejs,.NET,php" >}} {{< programming-lang lang="java" >}} -In Java, Datadog APM allows you to instrument your code to generate custom spans—either by using method decorators, or by instrumenting specific code blocks. +In Java, {{< prodname >}}Datadog APM{{< /prodname >}} allows you to instrument your code to generate custom spans—either by using method decorators, or by instrumenting specific code blocks. **Instrument a method with a decorator**: @@ -104,7 +104,7 @@ public class BackupLedger { {{< /programming-lang >}} {{< programming-lang lang="python" >}} -In Python, Datadog APM allows you to instrument your code to generate custom spans—either by using method decorators, or by instrumenting specific code blocks. +In Python, {{< prodname >}}Datadog APM{{< /prodname >}} allows you to instrument your code to generate custom spans—either by using method decorators, or by instrumenting specific code blocks. **Instrument a method with a decorator**: @@ -150,7 +150,7 @@ class BackupLedger: {{< /programming-lang >}} {{< programming-lang lang="ruby" >}} - In Ruby, Datadog APM allows you to instrument your code to generate custom spans by instrumenting specific code blocks. + In Ruby, {{< prodname >}}Datadog APM{{< /prodname >}} allows you to instrument your code to generate custom spans by instrumenting specific code blocks. This example creates a new span for the call to the `BackupLedger.write` method and a child span for every transaction posted to the ledger with a [custom tag][1] with the specific transaction ID. @@ -180,7 +180,7 @@ end {{< /programming-lang >}} {{< programming-lang lang="go" >}} - In Go, Datadog APM allows you to instrument your code to generate custom spans by instrumenting specific code blocks. + In Go, {{< prodname >}}Datadog APM{{< /prodname >}} allows you to instrument your code to generate custom spans by instrumenting specific code blocks. This example creates a new span for every transaction posted to the ledger and adds a [custom tag][1] with the specific transaction ID to the span. @@ -232,7 +232,7 @@ func (bl *BackupLedger) persistTransaction(ctx context.Context, transaction *Tra {{< /programming-lang >}} {{< programming-lang lang="nodejs" >}} - In Node.js, Datadog APM allows you to instrument your code to generate custom spans by instrumenting specific code blocks. + In Node.js, {{< prodname >}}Datadog APM{{< /prodname >}} allows you to instrument your code to generate custom spans by instrumenting specific code blocks. This example creates a new span for the call to the `BackupLedger.write` method and a child span for every transaction posted to the ledger with a [custom tag][1] with the specific transaction ID. @@ -259,7 +259,7 @@ function write (transactions) { {{< /programming-lang >}} {{< programming-lang lang=".NET" >}} - In .NET, Datadog APM allows you to instrument your code to generate custom spans by instrumenting specific code blocks. + In .NET, {{< prodname >}}Datadog APM{{< /prodname >}} allows you to instrument your code to generate custom spans by instrumenting specific code blocks. This example creates a new span for every transaction posted to the ledger and adds a [custom tag][1] with the specific transaction ID to the span. @@ -290,7 +290,7 @@ public void Write(List transactions) {{< /programming-lang >}} {{< programming-lang lang="php" >}} -In PHP, Datadog APM allows you to instrument your code to generate custom spans—either by using method wrappers, or by instrumenting specific code blocks. +In PHP, {{< prodname >}}Datadog APM{{< /prodname >}} allows you to instrument your code to generate custom spans—either by using method wrappers, or by instrumenting specific code blocks. **Instrument a method with a wrapper**: diff --git a/hugo/content/en/tracing/guide/send_traces_to_agent_by_api.md b/hugo/content/en/tracing/guide/send_traces_to_agent_by_api.md index cd44e0b82ad..ec342a0ebe2 100644 --- a/hugo/content/en/tracing/guide/send_traces_to_agent_by_api.md +++ b/hugo/content/en/tracing/guide/send_traces_to_agent_by_api.md @@ -15,7 +15,7 @@ aliases: - /api/v2/tracing/ --- -Datadog APM allows you to collect performance metrics by tracing your code to determine which parts of your application are slow or inefficient. +{{< prodname >}}Datadog APM{{< /prodname >}} allows you to collect performance metrics by tracing your code to determine which parts of your application are slow or inefficient. Tracing data is sent from your instrumented code to the Datadog Agent through an HTTP API. Datadog SDKs simplify sending metrics to the Datadog Agent. However you might want to interact directly with the API to instrument applications that cannot use the libraries or are written in languages that don't yet have an official Datadog SDK. diff --git a/hugo/content/en/tracing/guide/serverless_enable_aws_xray.md b/hugo/content/en/tracing/guide/serverless_enable_aws_xray.md index f499f1ef1a0..f67a37b8fb0 100644 --- a/hugo/content/en/tracing/guide/serverless_enable_aws_xray.md +++ b/hugo/content/en/tracing/guide/serverless_enable_aws_xray.md @@ -6,7 +6,7 @@ aliases: --- ## Before you enable X-Ray -The AWS X-Ray integration converts X-Ray traces into Datadog APM traces. Datadog offers native instrumentation for the use cases that originally required X-Ray. Before enabling X-Ray, consider whether one of the native paths fits your stack: +The AWS X-Ray integration converts X-Ray traces into {{< prodname >}}Datadog APM{{< /prodname >}} traces. Datadog offers native instrumentation for the use cases that originally required X-Ray. Before enabling X-Ray, consider whether one of the native paths fits your stack: | Use case | Recommended Datadog path | |----------|-------------------------| @@ -14,7 +14,7 @@ The AWS X-Ray integration converts X-Ray traces into Datadog APM traces. Datadog | AWS Step Functions tracing, including merging Step Functions traces with Lambda traces | [Serverless Monitoring for AWS Step Functions][9] and [Merge Step Functions and Lambda Traces][10] | | Trace context propagation across managed services (API Gateway, SQS, SNS, EventBridge, Kinesis, DynamoDB, S3) | Supported out of the box by the [Datadog Lambda Library][11] | -Use the X-Ray integration if you need traces for an AWS managed service that Datadog APM doesn't yet instrument (for example, AppSync). The X-Ray integration also remains available if you already have X-Ray instrumentation in place and prefer to keep it. +Use the X-Ray integration if you need traces for an AWS managed service that {{< prodname >}}Datadog APM{{< /prodname >}} doesn't yet instrument (for example, AppSync). The X-Ray integration also remains available if you already have X-Ray instrumentation in place and prefer to keep it. ## Enable AWS X-Ray diff --git a/hugo/content/en/tracing/guide/serverless_enable_azure_app_insights.md b/hugo/content/en/tracing/guide/serverless_enable_azure_app_insights.md index bd5227fa8ed..ec98195d030 100644 --- a/hugo/content/en/tracing/guide/serverless_enable_azure_app_insights.md +++ b/hugo/content/en/tracing/guide/serverless_enable_azure_app_insights.md @@ -14,7 +14,7 @@ The Azure App Insights Integration is in Preview. Use this form to request acces ## Overview -Bring your Azure Application Insights distributed traces into Datadog APM. Datadog converts App Insights traces into APM spans and enriches spans from supported services with Azure resource metadata. +Bring your Azure Application Insights distributed traces into {{< prodname >}}Datadog APM{{< /prodname >}}. Datadog converts App Insights traces into APM spans and enriches spans from supported services with Azure resource metadata. {{< img src="tracing/guide/serverless_enable_azure_app_insights/app-insights-azure-fn-example.png" alt="An Azure Application Insights trace shown in the Datadog APM flame graph, with Azure resource metadata visible on the selected span." style="width:100%;" >}} @@ -25,10 +25,10 @@ The integration reads App Insights records forwarded to Datadog as logs and emit When Application Insights is enabled on your workloads and your Azure logs are flowing to Datadog, Datadog: 1. Reads App Insights records from your forwarded Azure logs. -2. Converts each App Insights operation into a Datadog APM span, preserving parent-child relationships across both the legacy hierarchical Request-Id format and W3C Trace Context. +2. Converts each App Insights operation into a {{< prodname >}}Datadog APM{{< /prodname >}} span, preserving parent-child relationships across both the legacy hierarchical Request-Id format and W3C Trace Context. 3. Enriches spans for [supported Azure services](#supported-azure-services) with Azure resource metadata, including resource group, subscription, region, and resource tags. -After conversion, the spans behave like any other Datadog APM spans. They appear in the same waterfall view, support trace search, and correlate with your logs and metrics. +After conversion, the spans behave like any other {{< prodname >}}Datadog APM{{< /prodname >}} spans. They appear in the same waterfall view, support trace search, and correlate with your logs and metrics. ## Prerequisites diff --git a/hugo/content/en/tracing/guide/setting_primary_tags_to_scope.md b/hugo/content/en/tracing/guide/setting_primary_tags_to_scope.md index 24246e1d6ef..bc75c9cbf8e 100644 --- a/hugo/content/en/tracing/guide/setting_primary_tags_to_scope.md +++ b/hugo/content/en/tracing/guide/setting_primary_tags_to_scope.md @@ -20,7 +20,7 @@ further_reading: ## Definition -There are several dimensions available to scope an entire Datadog APM application. These include aggregate statistics (such as requests/second, latency, error rate, Apdex score) and visible [traces][1]. These dimensions are set up through primary tags that allow you to get an even finer view of your application's behavior. Use cases for primary tags include environment, availability zone, datacenter, etc. +There are several dimensions available to scope an entire {{< prodname >}}Datadog APM{{< /prodname >}} application. These include aggregate statistics (such as requests/second, latency, error rate, Apdex score) and visible [traces][1]. These dimensions are set up through primary tags that allow you to get an even finer view of your application's behavior. Use cases for primary tags include environment, availability zone, datacenter, etc. Primary tags must follow a different set of rules from those of conventional [Datadog tags][2]. diff --git a/hugo/content/en/tracing/guide/slowest_request_daily.md b/hugo/content/en/tracing/guide/slowest_request_daily.md index 7f7142cc7ad..18564f406a3 100644 --- a/hugo/content/en/tracing/guide/slowest_request_daily.md +++ b/hugo/content/en/tracing/guide/slowest_request_daily.md @@ -54,7 +54,7 @@ With Datadog APM, you can investigate the performance of your endpoints, identif 5. Click into the {{< ui >}}Host{{< /ui >}} tab, observe the CPU and memory performance of the underlying host while the request was hitting it. 6. Click {{< ui >}}Open Host Dashboard{{< /ui >}} to view all relevant data about the host -Datadog APM seamlessly integrates with the other Datadog metrics and information - like infrastructure metrics and Logs. Using the flame graph, this information is available to you as well as any [custom metadata][7] you are sending with your traces. +{{< prodname >}}Datadog APM{{< /prodname >}} seamlessly integrates with the other Datadog metrics and information - like infrastructure metrics and Logs. Using the flame graph, this information is available to you as well as any [custom metadata][7] you are sending with your traces. ## Further Reading diff --git a/hugo/content/en/tracing/guide/trace_ingestion_volume_control.md b/hugo/content/en/tracing/guide/trace_ingestion_volume_control.md index be2eda1a4a5..5f7170a05d9 100644 --- a/hugo/content/en/tracing/guide/trace_ingestion_volume_control.md +++ b/hugo/content/en/tracing/guide/trace_ingestion_volume_control.md @@ -21,7 +21,7 @@ With the ingestion control page, you have full visibility and complete control o {{< img src="/tracing/guide/trace_ingestion_volume_control/sampling_25_percent.png" alt="APM ingestion sampling displaying 25 percent complete traces ingested" style="width:70%;" >}} -If you decide to reduce the ingestion volume for certain services, the **request, error, and latency [metrics][3]** (known as RED metrics, for Requests, Errors, and Duration) remain 100% accurate, as they are being calculated based on 100% of the application's traffic, regardless of any sampling configuration. These metrics are included when purchasing Datadog APM. In order to make sure you have full visibility into your application's traffic, you can use these metrics to spot potential errors on a service or a resource, by creating dashboards, monitors, and SLOs. +If you decide to reduce the ingestion volume for certain services, the **request, error, and latency [metrics][3]** (known as RED metrics, for Requests, Errors, and Duration) remain 100% accurate, as they are being calculated based on 100% of the application's traffic, regardless of any sampling configuration. These metrics are included when purchasing {{< prodname >}}Datadog APM{{< /prodname >}}. In order to make sure you have full visibility into your application's traffic, you can use these metrics to spot potential errors on a service or a resource, by creating dashboards, monitors, and SLOs. **Note**: If your applications and services are instrumented with OpenTelemetry libraries and you set up sampling at the SDK level and/or at the collector level, APM metrics are based on the **sampled** set of data by default. See [Ingestion Sampling with OpenTelemetry][4] for more information. diff --git a/hugo/content/en/tracing/guide/tutorial-enable-go-aws-ecs-ec2.md b/hugo/content/en/tracing/guide/tutorial-enable-go-aws-ecs-ec2.md index 435e10db0d7..3a184e0e185 100644 --- a/hugo/content/en/tracing/guide/tutorial-enable-go-aws-ecs-ec2.md +++ b/hugo/content/en/tracing/guide/tutorial-enable-go-aws-ecs-ec2.md @@ -29,7 +29,7 @@ This tutorial walks you through the steps for enabling tracing on a sample Go ap For other scenarios, including the application and Agent on a host, the application in a container and Agent on a host, the application and Agent on cloud infrastructure, and on applications written in other languages, see the other [Enabling Tracing tutorials][1]. Some of those other tutorials, for example, the ones using containers or EKS, step through the differences seen in Datadog between automatic and custom instrumentation. This tutorial skips right to a fully custom instrumented example. -This tutorial also uses intermediate-level AWS topics, so it requires that you have some familiarity with AWS networking and applications. If you're not as familiar with AWS, and you are trying to learn the basics of Datadog APM setup, use one of the host or container tutorials instead. +This tutorial also uses intermediate-level AWS topics, so it requires that you have some familiarity with AWS networking and applications. If you're not as familiar with AWS, and you are trying to learn the basics of {{< prodname >}}Datadog APM{{< /prodname >}} setup, use one of the host or container tutorials instead. See [Tracing Go Applications][2] for general comprehensive tracing setup documentation for Go. {{% tracing-go-v2 %}} diff --git a/hugo/content/en/tracing/guide/tutorial-enable-go-aws-ecs-fargate.md b/hugo/content/en/tracing/guide/tutorial-enable-go-aws-ecs-fargate.md index 7c95069394e..c004b4b3ef1 100644 --- a/hugo/content/en/tracing/guide/tutorial-enable-go-aws-ecs-fargate.md +++ b/hugo/content/en/tracing/guide/tutorial-enable-go-aws-ecs-fargate.md @@ -28,7 +28,7 @@ This tutorial walks you through the steps for enabling tracing on a sample Go ap For other scenarios, including the application and Agent on a host, the application in a container and Agent on a host, the application and Agent on cloud infrastructure, and on applications written in other languages, see the other [Enabling Tracing tutorials][1]. Some of those other tutorials, for example, the ones using containers or EKS, step through the differences seen in Datadog between automatic and custom instrumentation. This tutorial skips right to a fully custom instrumented example. -This tutorial also uses intermediate-level AWS topics, so it requires that you have some familiarity with AWS networking and applications. If you're not as familiar with AWS, and you are trying to learn the basics of Datadog APM setup, use one of the host or container tutorials instead. +This tutorial also uses intermediate-level AWS topics, so it requires that you have some familiarity with AWS networking and applications. If you're not as familiar with AWS, and you are trying to learn the basics of {{< prodname >}}Datadog APM{{< /prodname >}} setup, use one of the host or container tutorials instead. See [Tracing Go Applications][2] for general comprehensive tracing setup documentation for Go. {{% tracing-go-v2 %}} diff --git a/hugo/content/en/tracing/guide/tutorial-enable-java-aws-ecs-ec2.md b/hugo/content/en/tracing/guide/tutorial-enable-java-aws-ecs-ec2.md index 1e97d3bdc60..1287919b3c1 100644 --- a/hugo/content/en/tracing/guide/tutorial-enable-java-aws-ecs-ec2.md +++ b/hugo/content/en/tracing/guide/tutorial-enable-java-aws-ecs-ec2.md @@ -26,7 +26,7 @@ This tutorial walks you through the steps for enabling tracing on a sample Java For other scenarios, including on a host, in a container, on other cloud infrastructure, and on applications written in other languages, see the other [Enabling Tracing tutorials][1]. Some of those other tutorials, for example, the ones using containers or EKS, step through the differences seen in Datadog between automatic and custom instrumentation. This tutorial skips right to a fully custom instrumented example. -This tutorial also uses intermediate-level AWS topics, so it requires that you have some familiarity with AWS networking and applications. If you're not as familiar with AWS, and you are trying to learn the basics of Datadog APM setup, use one of the host or container tutorials instead. +This tutorial also uses intermediate-level AWS topics, so it requires that you have some familiarity with AWS networking and applications. If you're not as familiar with AWS, and you are trying to learn the basics of {{< prodname >}}Datadog APM{{< /prodname >}} setup, use one of the host or container tutorials instead. See [Tracing Java Applications][2] for general comprehensive tracing setup documentation for Java. diff --git a/hugo/content/en/tracing/guide/tutorial-enable-java-aws-ecs-fargate.md b/hugo/content/en/tracing/guide/tutorial-enable-java-aws-ecs-fargate.md index 5f376a8441c..36c221e3053 100644 --- a/hugo/content/en/tracing/guide/tutorial-enable-java-aws-ecs-fargate.md +++ b/hugo/content/en/tracing/guide/tutorial-enable-java-aws-ecs-fargate.md @@ -25,7 +25,7 @@ This tutorial walks you through the steps for enabling tracing on a sample Java For other scenarios, including on a host, in a container, on other cloud infrastructure, and on applications written in other languages, see the other [Enabling Tracing tutorials][1]. Some of those other tutorials, for example, the ones using containers or EKS, step through the differences seen in Datadog between automatic and custom instrumentation. This tutorial skips right to a fully custom instrumented example. -This tutorial also uses intermediate-level AWS topics, so it requires that you have some familiarity with AWS networking and applications. If you're not as familiar with AWS, and you are trying to learn the basics of Datadog APM setup, use one of the host or container tutorials instead. +This tutorial also uses intermediate-level AWS topics, so it requires that you have some familiarity with AWS networking and applications. If you're not as familiar with AWS, and you are trying to learn the basics of {{< prodname >}}Datadog APM{{< /prodname >}} setup, use one of the host or container tutorials instead. See [Tracing Java Applications][2] for general comprehensive tracing setup documentation for Java. diff --git a/hugo/content/en/tracing/live_debugger/_index.md b/hugo/content/en/tracing/live_debugger/_index.md index 3c9baeb2a35..140037442f1 100644 --- a/hugo/content/en/tracing/live_debugger/_index.md +++ b/hugo/content/en/tracing/live_debugger/_index.md @@ -64,7 +64,7 @@ Live Debugger supports Python, Java, .NET, Ruby, Node.js, PHP, and Go. It requir - An installed [Datadog SDK][3] (see the [Enable Live Debugger](#enable-live-debugger) section for minimum SDK versions) - [Unified Service Tagging][27] configured with `service`, `env`, and `version` tags on your deployment - [Remote Configuration][4] enabled in the Agent -- (Recommended) [Source Code Integration][28] +- (Recommended) [{{< prodname >}}Source Code Integration{{< /prodname >}}][28] ### Permissions @@ -273,9 +273,9 @@ To create the index: ### (Recommended) Link your source code {#link-your-source-code} -Set up [Source Code Integration][28] to view source code files directly in Live Debugger. After you link the service and environment to the corresponding repository and Git commit SHA, you can add logpoints and see existing ones in the source code as you would with breakpoints in an IDE. This helps you confirm logpoints are placed accurately and avoid capturing unintended data or generating invalid results. +Set up [{{< prodname >}}Source Code Integration{{< /prodname >}}][28] to view source code files directly in Live Debugger. After you link the service and environment to the corresponding repository and Git commit SHA, you can add logpoints and see existing ones in the source code as you would with breakpoints in an IDE. This helps you confirm logpoints are placed accurately and avoid capturing unintended data or generating invalid results. -**Note**: Source Code Integration is optional when starting a Debug Session manually, but it is required when using [Bits Live Debugger][23]. +**Note**: {{< prodname >}}Source Code Integration{{< /prodname >}} is optional when starting a Debug Session manually, but it is required when using [Bits Live Debugger][23]. ## Using Live Debugger @@ -339,7 +339,7 @@ See the [sensitive data scrubbing][1] instructions and [Sensitive Data Scanner][
    Bits Live Debugger is in Preview. Learn more about Bits Live Debugger and request access.
    -[Bits Live Debugger][23] lets you investigate a running service by describing the issue in plain language. Bits Code handles logpoint placement, captures variable snapshots, and helps interpret the results. +[Bits Live Debugger][23] lets you investigate a running service by describing the issue in plain language. {{< prodname >}}Bits Code{{< /prodname >}} handles logpoint placement, captures variable snapshots, and helps interpret the results. **Note**: [Bits Live Debugger][23] requires the service and environment to be in Targeted Mode. See [Mode-based redaction][24] for details. @@ -347,7 +347,7 @@ See the [sensitive data scrubbing][1] instructions and [Sensitive Data Scanner][ The following constraints apply to Live Debugger usage and configuration: -- **Configuration scope:** Live Debugger and Dynamic Instrumentation are enabled or disabled together for the same service and environment. +- **Configuration scope:** Live Debugger and {{< prodname >}}Dynamic Instrumentation{{< /prodname >}} are enabled or disabled together for the same service and environment. - **Rate limits:** - Logpoints with variable capture: Limited to 1 execution per second. - Logpoints without variable capture: Limited to 5000 executions per second, per service instance. diff --git a/hugo/content/en/tracing/live_debugger/bits-live-debugger.md b/hugo/content/en/tracing/live_debugger/bits-live-debugger.md index c24eae124c7..758b93b7ab2 100644 --- a/hugo/content/en/tracing/live_debugger/bits-live-debugger.md +++ b/hugo/content/en/tracing/live_debugger/bits-live-debugger.md @@ -28,7 +28,7 @@ All debugging activity runs through [Live Debugger][1], so the same [permissions Bits Live Debugger functionality is only accessible from the Live Debugger page.
    -Bits Live Debugger uses Bits Code as the underlying agent. During the Bits Live Debugger Preview phase, Bits Code AI Credits are not charged when sessions are started through Live Debugger. +Bits Live Debugger uses {{< prodname >}}Bits Code{{< /prodname >}} as the underlying agent. During the Bits Live Debugger Preview phase, Bits Code AI Credits are not charged when sessions are started through Live Debugger.
    ## Prerequisites @@ -37,8 +37,8 @@ Before using Bits Live Debugger: - [Live Debugger][1] must be enabled for the target service. See [Enable Live Debugger][7] for details. - Your account must have the [permissions][2] required to use Live Debugger, including read, write, and variable-capture permissions for the target environment. -- [Bits Code][5] must be available in your organization. -- [Source Code Integration][6] must be set up for the target service. +- [{{< prodname >}}Bits Code{{< /prodname >}}][5] must be available in your organization. +- [{{< prodname >}}Source Code Integration{{< /prodname >}}][6] must be set up for the target service. ## Available actions diff --git a/hugo/content/en/tracing/other_telemetry/connect_logs_and_traces/_index.md b/hugo/content/en/tracing/other_telemetry/connect_logs_and_traces/_index.md index 89a19bd32f0..927d17b977e 100644 --- a/hugo/content/en/tracing/other_telemetry/connect_logs_and_traces/_index.md +++ b/hugo/content/en/tracing/other_telemetry/connect_logs_and_traces/_index.md @@ -11,7 +11,7 @@ algolia: {{< img src="tracing/connect_logs_and_traces/logs-trace-correlation.png" alt="Logs in Traces" style="width:100%;">}} -The correlation between Datadog APM and Datadog Log Management is improved by the injection of trace IDs, span IDs, `env`, `service`, and `version` as attributes in your logs. With these fields you can find the exact logs associated with a specific service and version, or all logs correlated to an observed [trace][1]. +The correlation between {{< prodname >}}Datadog APM{{< /prodname >}} and Datadog Log Management is improved by the injection of trace IDs, span IDs, `env`, `service`, and `version` as attributes in your logs. With these fields you can find the exact logs associated with a specific service and version, or all logs correlated to an observed [trace][1]. It is recommended to configure your application's tracer with `DD_ENV`, `DD_SERVICE`, and `DD_VERSION`. This will provide the best experience for adding `env`, `service`, and `version`. See the [unified service tagging][2] documentation for more details. diff --git a/hugo/content/en/tracing/recommendations/_index.md b/hugo/content/en/tracing/recommendations/_index.md index c282beadd17..224194d68a6 100644 --- a/hugo/content/en/tracing/recommendations/_index.md +++ b/hugo/content/en/tracing/recommendations/_index.md @@ -140,14 +140,14 @@ AI-driven recommendation types are now available, expanding the set of [optimiza Certain recommendations rely on specific Datadog products. Use the {{< ui >}}Recommendation Prerequisite{{< /ui >}} dropdown to filter recommendations by the Datadog products in your setup. -If you plan to use [Bits Code][3] to implement recommendations, you must [complete its setup][4]. +If you plan to use [{{< prodname >}}Bits Code{{< /prodname >}}][3] to implement recommendations, you must [complete its setup][4]. ## How it works Recommendations are based on data collected from different parts of your stack: - Distributed traces from Application Performance Monitoring (APM) -- Database telemetry from Database Monitoring (DBM) +- Database telemetry from {{< prodname >}}Database Monitoring{{< /prodname >}} (DBM) - Sessions and user journeys from Real User Monitoring (RUM) Datadog correlates these sources to identify opportunities to improve performance, reliability, and user experience. @@ -162,12 +162,12 @@ To review recommendations that need your attention: 2. Filter your recommendations by status or type. 3. Select a recommendation from the list to see a detailed description of the issue. 4. Review the problem, impact, and Datadog's recommendation for resolving it. -5. (Optional) To use [Bits Code][3] to generate a code fix, under {{< ui >}}Next Steps{{< /ui >}}, click {{< ui >}}Fix with Bits{{< /ui >}}. -6. (Optional) To track the fix in Jira or Case Management, under {{< ui >}}Triage{{< /ui >}}, click {{< ui >}}Add Jira Ticket{{< /ui >}} or {{< ui >}}Add Case{{< /ui >}}. +5. (Optional) To use [{{< prodname >}}Bits Code{{< /prodname >}}][3] to generate a code fix, under {{< ui >}}Next Steps{{< /ui >}}, click {{< ui >}}Fix with Bits{{< /ui >}}. +6. (Optional) To track the fix in Jira or {{< prodname >}}Case Management{{< /prodname >}}, under {{< ui >}}Triage{{< /ui >}}, click {{< ui >}}Add Jira Ticket{{< /ui >}} or {{< ui >}}Add Case{{< /ui >}}. After you've reviewed the recommendation, you can use the {{< ui >}}FOR REVIEW{{< /ui >}} dropdown to change the recommendation status to {{< ui >}}REVIEWED{{< /ui >}}, {{< ui >}}IGNORED{{< /ui >}}, or {{< ui >}}RESOLVED{{< /ui >}}. -**Note**: On the [APM Home page][5], the {{< ui >}}Watchdog{{< /ui >}} and {{< ui >}}Error Tracking{{< /ui >}} sections also respect the selected service filter (or your personalized services when no filter is set), matching how recommendations are scoped. When a service is selected and no alerts or issues match, the section shows an empty state with a {{< ui >}}Clear filter{{< /ui >}} button, and the Error Tracking {{< ui >}}View all{{< /ui >}} link is pre-filtered to that service. +**Note**: On the [APM Home page][5], the {{< ui >}}Watchdog{{< /ui >}} and {{< ui >}}{{< prodname >}}Error Tracking{{< /prodname >}}{{< /ui >}} sections also respect the selected service filter (or your personalized services when no filter is set), matching how recommendations are scoped. When a service is selected and no alerts or issues match, the section shows an empty state with a {{< ui >}}Clear filter{{< /ui >}} button, and the {{< prodname >}}Error Tracking{{< /prodname >}} {{< ui >}}View all{{< /ui >}} link is pre-filtered to that service. ## Viewing recommendations on a dashboard @@ -185,7 +185,7 @@ Add a List widget with APM Recommendations as its data source to review recommen {{< multifilter-search >}} -**Note**: If you use both APM and Database Monitoring (DBM), you may see fewer Missing Index recommendations here than on the [DBM Recommendations page][2]. APM Recommendations only surface Missing Index issues that Datadog can associate with an instrumented application service. Missing Index recommendations that cannot be linked to a specific service appear only in DBM. +**Note**: If you use both APM and {{< prodname >}}Database Monitoring{{< /prodname >}} (DBM), you may see fewer Missing Index recommendations here than on the [DBM Recommendations page][2]. APM Recommendations only surface Missing Index issues that Datadog can associate with an instrumented application service. Missing Index recommendations that cannot be linked to a specific service appear only in DBM. ## Further reading diff --git a/hugo/content/en/tracing/services/inferred_services.md b/hugo/content/en/tracing/services/inferred_services.md index e8e43df28f3..d9735406d25 100644 --- a/hugo/content/en/tracing/services/inferred_services.md +++ b/hugo/content/en/tracing/services/inferred_services.md @@ -17,7 +17,7 @@ Datadog automatically discovers the dependencies for an instrumented service, su {{< site-region region="ap1,us3,us5,eu,us,ap2,uk1" >}} -Explore inferred services in the [Catalog][1] by filtering entries by entity type, such as database, queue, or third-party API. Each [service page][2] is tailored to the type of service you are investigating. For instance, database service pages show database-specific insights and include database monitoring data if you are using [Database Monitoring][3]. +Explore inferred services in the [Catalog][1] by filtering entries by entity type, such as database, queue, or third-party API. Each [service page][2] is tailored to the type of service you are investigating. For instance, database service pages show database-specific insights and include database monitoring data if you are using [{{< prodname >}}Database Monitoring{{< /prodname >}}][3]. ## Set up inferred services {{< tabs >}} diff --git a/hugo/content/en/tracing/services/service_page.md b/hugo/content/en/tracing/services/service_page.md index a7106cf577f..016f85d3c28 100644 --- a/hugo/content/en/tracing/services/service_page.md +++ b/hugo/content/en/tracing/services/service_page.md @@ -50,7 +50,7 @@ Consult on this page: * [Out-of-the-box graphs](#out-of-the-box-graphs) * [Resources associated to this service][2] * [Additional sections](#additional-sections) - * [Deployments](#deployments), [Error Tracking](#error-tracking), [Traces](#traces), [Security](#security), and more + * [Deployments](#deployments), [{{< prodname >}}Error Tracking{{< /prodname >}}](#error-tracking), [Traces](#traces), [Security](#security), and more ## Service health @@ -77,7 +77,7 @@ Service health displays the status of your service as *Critical* or *Warning* if ## Service monitor -The Service monitor panel surfaces active Monitors and Synthetics tests linked to your service. +The Service monitor panel surfaces active Monitors and {{< prodname >}}Synthetics{{< /prodname >}} tests linked to your service. Datadog also proposes a list of monitors depending on your service type: {{< img src="tracing/visualization/service/service_monitors.png" alt="Service Monitors" style="width:90%;">}} @@ -88,7 +88,7 @@ Enable them directly or create your own [APM monitors][3]. ## Watchdog Insights -The [Watchdog Insights][7] carousel surfaces anomalies and outliers detected on specific tags, enabling you to investigate the root cause of an issue. Insights are discovered from APM, Continuous Profiler, Log Management, and Infrastructure data that include the service tag. These insights are the same insights that appear in each of the product pages. For example, the same Log outliers on the service page can be found in the [Log Explorer][19]. +The [Watchdog Insights][7] carousel surfaces anomalies and outliers detected on specific tags, enabling you to investigate the root cause of an issue. Insights are discovered from APM, Continuous Profiler, {{< prodname >}}Log Management{{< /prodname >}}, and Infrastructure data that include the service tag. These insights are the same insights that appear in each of the product pages. For example, the same Log outliers on the service page can be found in the [Log Explorer][19]. {{< img src="tracing/visualization/service/cross_product_insight_1.jpg" alt="Watchdog Insights" style="width:100%;">}} @@ -98,7 +98,7 @@ Click on an insight to see more details, such as the time frame of the insight, ## Summary cards -The service page features summary cards with highlights on your service health. Easily spot potential faulty deployments, click into the card to view details or traces of the latest deployment, or view all deployments on this service. See new issues flagged on your service through our integration with [Error Tracking][4], where errors are automatically aggregated into issues. +The service page features summary cards with highlights on your service health. Easily spot potential faulty deployments, click into the card to view details or traces of the latest deployment, or view all deployments on this service. See new issues flagged on your service through our integration with [{{< prodname >}}Error Tracking{{< /prodname >}}][4], where errors are automatically aggregated into issues. {{< img src="tracing/visualization/service/summary_cards.png" alt="Summary cards" style="width:100%;">}} @@ -199,14 +199,14 @@ You can add columns to or remove columns from this overview table and your selec Read more about Deployments [on the service page][12]. ### Error Tracking -View issues on your service, which are similar errors aggregated together to turn a noisy stream of errors into manageable issues and help you assess the impact of your service's errors. Read more about issues in [Error Tracking][4]. +View issues on your service, which are similar errors aggregated together to turn a noisy stream of errors into manageable issues and help you assess the impact of your service's errors. Read more about issues in [{{< prodname >}}Error Tracking{{< /prodname >}}][4]. This tab has overview graphs that show which resources have the most issues and a list of the most common issues occurring in your service. Click on an issue in the list to see details in a side panel, including its stack trace, related code versions, and total error occurrences since inception. {{< img src="tracing/visualization/service/error_tracking_side_panel_1.jpg" alt="Error Tracking tab" style="width:90%;">}} ### Security -Understand the security posture of the service, including known vulnerabilities exposed in the service's libraries and security signals on your service, which are automatically created when Datadog detects application attacks impacting your services. The signals identify meaningful threats for you to review instead of assessing each individual attack attempt. Read more about [App and API Protection][18]. +Understand the security posture of the service, including known vulnerabilities exposed in the service's libraries and security signals on your service, which are automatically created when Datadog detects application attacks impacting your services. The signals identify meaningful threats for you to review instead of assessing each individual attack attempt. Read more about [{{< prodname >}}App and API Protection{{< /prodname >}}][18]. The top section of the security tab has overview graphs that show the number and severity of vulnerabilities, a timeline of attacks, the types of attacks, and attacker information (client IP or authenticated user). @@ -221,7 +221,7 @@ View host details, queries, recommendations, and downstream database dependencie The Queries tab includes a visualization of sampled span durations and a full list of queries from the selected time interval. Select a query from the table to open the query panel and view diagnostics, error details, and traces. #### Databases -The Databases tab includes active connection and average query duration visualizations to help identify outliers, and a full list of database hosts for the selected service. Select a database host from the list to view it in Database Monitoring. +The Databases tab includes active connection and average query duration visualizations to help identify outliers, and a full list of database hosts for the selected service. Select a database host from the list to view it in {{< prodname >}}Database Monitoring{{< /prodname >}}. [Learn more about connecting DBM and APM][21]. @@ -321,7 +321,7 @@ The summary cards highlight the aggregate frontend impact for the current select #### Product Analytics enrichment -If you use [Product Analytics][25], the Frontend activity tab shows enriched details about the impacted users and accounts, giving you more context on who is affected when the service degrades and helping you prioritize work by business impact. +If you use [{{< prodname >}}Product Analytics{{< /prodname >}}][25], the Frontend activity tab shows enriched details about the impacted users and accounts, giving you more context on who is affected when the service degrades and helping you prioritize work by business impact. ## Further Reading diff --git a/hugo/content/en/tracing/services/services_map.md b/hugo/content/en/tracing/services/services_map.md index e2adaea2d91..979f5cb898b 100644 --- a/hugo/content/en/tracing/services/services_map.md +++ b/hugo/content/en/tracing/services/services_map.md @@ -22,7 +22,7 @@ The Service Map decomposes your application into all its component [services][1] ## Setup -The Service Map visualizes data collected by Datadog APM and RUM. Setup is not required to view [services][1]. +The Service Map visualizes data collected by {{< prodname >}}Datadog APM{{< /prodname >}} and RUM. Setup is not required to view [services][1]. ## Ways to use it diff --git a/hugo/content/en/tracing/services/tag_enrichment.md b/hugo/content/en/tracing/services/tag_enrichment.md index 0137e557d2b..cd22637ecac 100644 --- a/hugo/content/en/tracing/services/tag_enrichment.md +++ b/hugo/content/en/tracing/services/tag_enrichment.md @@ -61,7 +61,7 @@ Click {{< ui >}}Add Tags{{< /ui >}} to open the tag enrichment rule modal pre-po ## Tag enrichment behavior -- **Impacted telemetry**: Tag enrichment applies only to logs, APM spans, and trace metrics. Because [Data Observability: Jobs Monitoring][3] sends job telemetry as APM spans, that telemetry is enriched as well, but Jobs Monitoring metrics are not. Tag enrichment is not supported for other telemetry types, including custom and infrastructure metrics, Database Monitoring, Profiling, Kubernetes, Universal Service Monitoring, and Events. +- **Impacted telemetry**: Tag enrichment applies only to logs, APM spans, and trace metrics. Because [Data Observability: Jobs Monitoring][3] sends job telemetry as APM spans, that telemetry is enriched as well, but Jobs Monitoring metrics are not. Tag enrichment is not supported for other telemetry types, including custom and infrastructure metrics, {{< prodname >}}Database Monitoring{{< /prodname >}}, Profiling, Kubernetes, Universal Service Monitoring, and Events. - **Historical data**: Tag enrichment rules apply only to telemetry ingested while a rule is active. Past data is not updated retroactively. Deleting or modifying a rule stops it from applying to new telemetry, but does not update previously ingested data. - **Metadata updates**: Updating or adding Entity Metadata to services while enrichment rules are enabled, including the default rules, automatically updates those tags. - **Rule processing order**: Tag enrichment rules are applied in the order in which they were created. Rules at the top of the list take precedence over rules below them. diff --git a/hugo/content/en/tracing/trace_collection/_index.md b/hugo/content/en/tracing/trace_collection/_index.md index 1ed02680a2f..12d4fec0d6d 100644 --- a/hugo/content/en/tracing/trace_collection/_index.md +++ b/hugo/content/en/tracing/trace_collection/_index.md @@ -31,7 +31,7 @@ algolia: --- ## Overview -Application {{< tooltip glossary="instrumentation" >}} with Datadog APM involves: +Application {{< tooltip glossary="instrumentation" >}} with {{< prodname >}}Datadog APM{{< /prodname >}} involves: 1. **SDK setup**: Adding a Datadog SDK to your application. 2. **Span creation**: Capturing observability data as {{< tooltip glossary="span" >}}s. @@ -66,10 +66,10 @@ As your observability needs grow, you can add more control and customization: {{< nextlink href="/tracing/trace_collection/dd_libraries/" >}}Use manually managed Datadog SDKs{{< /nextlink >}} {{< /whatsnext >}} -**For custom spans without code changes:** Use [Dynamic Instrumentation][4] to create custom spans from the Datadog UI without redeploying your application. +**For custom spans without code changes:** Use [{{< prodname >}}Dynamic Instrumentation{{< /prodname >}}][4] to create custom spans from the Datadog UI without redeploying your application. {{< whatsnext desc=" " >}} - {{< nextlink href="/tracing/trace_collection/dynamic_instrumentation/" >}}Add custom spans with Dynamic Instrumentation{{< /nextlink >}} + {{< nextlink href="/tracing/trace_collection/dynamic_instrumentation/" >}}Add custom spans with {{< prodname >}}Dynamic Instrumentation{{< /prodname >}}{{< /nextlink >}} {{< /whatsnext >}} **For custom spans in code:** Add [code-based custom instrumentation][3] to instrument custom business logic or add application-specific metadata to spans. @@ -78,7 +78,7 @@ As your observability needs grow, you can add more control and customization: {{< nextlink href="/tracing/trace_collection/custom_instrumentation/" >}}Add custom spans with code-based instrumentation{{< /nextlink >}} {{< /whatsnext >}} -These options can be combined. For example, you can start with Single Step Instrumentation and add code-based custom instrumentation for specific spans, or use manually managed SDKs with Dynamic Instrumentation for no-deploy span additions. +These options can be combined. For example, you can start with Single Step Instrumentation and add code-based custom instrumentation for specific spans, or use manually managed SDKs with {{< prodname >}}Dynamic Instrumentation{{< /prodname >}} for no-deploy span additions. ## Detailed comparison @@ -121,12 +121,12 @@ Single Step Instrumentation is the recommended starting point for most users. If ### Span customization -Auto-instrumentation automatically creates spans for supported frameworks and libraries, providing essential observability with no additional work. When you need visibility into custom code paths or want to enrich traces with application-specific data, you can add custom spans using either Dynamic Instrumentation or code-based custom instrumentation: +Auto-instrumentation automatically creates spans for supported frameworks and libraries, providing essential observability with no additional work. When you need visibility into custom code paths or want to enrich traces with application-specific data, you can add custom spans using either {{< prodname >}}Dynamic Instrumentation{{< /prodname >}} or code-based custom instrumentation:
    Cloud Security{{< prodname >}}Cloud Security{{< /prodname >}} Misconfigurations (CSPM) Supported
    Supported
    Code Security{{< prodname >}}Code Security{{< /prodname >}} Infrastructure as code (IaC) Supported
    - + diff --git a/hugo/content/en/tracing/trace_collection/compatibility/_index.md b/hugo/content/en/tracing/trace_collection/compatibility/_index.md index 56111096eeb..f9ef770978c 100644 --- a/hugo/content/en/tracing/trace_collection/compatibility/_index.md +++ b/hugo/content/en/tracing/trace_collection/compatibility/_index.md @@ -13,7 +13,7 @@ aliases: - /tracing/setup_overview/compatibility_requirements/ --- -Choose your language to see the compatibility requirements and supported integrations for Datadog APM. +Choose your language to see the compatibility requirements and supported integrations for {{< prodname >}}Datadog APM{{< /prodname >}}. {{< partial name="apm/apm-compatibility.html" >}} diff --git a/hugo/content/en/tracing/trace_collection/compatibility/dotnet-framework.md b/hugo/content/en/tracing/trace_collection/compatibility/dotnet-framework.md index 34dba5cab2d..19997f22071 100644 --- a/hugo/content/en/tracing/trace_collection/compatibility/dotnet-framework.md +++ b/hugo/content/en/tracing/trace_collection/compatibility/dotnet-framework.md @@ -133,7 +133,7 @@ The .NET Tracer depends on the host operating system, .NET Framework runtime, ce ### Package versioning -Datadog APM for .NET Framework practices [semantic versioning][10]. +{{< prodname >}}Datadog APM{{< /prodname >}} for .NET Framework practices [semantic versioning][10]. Version updates imply the following changes to runtime support: - **Major version updates** (for example `1.0.0` to `2.0.0`) may change support for any runtime from [Preview](#support-beta)/[GA](#support-ga) to [Maintenance](#support-maintenance)/[EOL](#support-eol). diff --git a/hugo/content/en/tracing/trace_collection/compatibility/php.md b/hugo/content/en/tracing/trace_collection/compatibility/php.md index 8a5e9c38ed6..53030a56648 100644 --- a/hugo/content/en/tracing/trace_collection/compatibility/php.md +++ b/hugo/content/en/tracing/trace_collection/compatibility/php.md @@ -19,9 +19,9 @@ further_reading: The PHP Datadog Trace library is open source - view the [GitHub repository][1] for more information. -Datadog APM for PHP is built upon dependencies defined in specific versions of the host operating system, PHP runtime, +{{< prodname >}}Datadog APM{{< /prodname >}} for PHP is built upon dependencies defined in specific versions of the host operating system, PHP runtime, certain PHP libraries, and the Datadog Agent or API. -When these versions are no longer supported by their maintainers, Datadog APM for PHP limits its support for these as well. +When these versions are no longer supported by their maintainers, {{< prodname >}}Datadog APM{{< /prodname >}} for PHP limits its support for these as well. #### Levels of support diff --git a/hugo/content/en/tracing/trace_collection/compatibility/php_v0.md b/hugo/content/en/tracing/trace_collection/compatibility/php_v0.md index b7749326e71..5f2d276ac5d 100644 --- a/hugo/content/en/tracing/trace_collection/compatibility/php_v0.md +++ b/hugo/content/en/tracing/trace_collection/compatibility/php_v0.md @@ -13,9 +13,9 @@ further_reading: The PHP Datadog Trace library is open source - view the [GitHub repository][1] for more information. -Datadog APM for PHP is built upon dependencies defined in specific versions of the host operating system, PHP runtime, +{{< prodname >}}Datadog APM{{< /prodname >}} for PHP is built upon dependencies defined in specific versions of the host operating system, PHP runtime, certain PHP libraries, and the Datadog Agent or API. -When these versions are no longer supported by their maintainers, Datadog APM for PHP limits its support for these as well. +When these versions are no longer supported by their maintainers, {{< prodname >}}Datadog APM{{< /prodname >}} for PHP limits its support for these as well. #### Levels of support diff --git a/hugo/content/en/tracing/trace_collection/custom_instrumentation/_index.md b/hugo/content/en/tracing/trace_collection/custom_instrumentation/_index.md index d82c8bbb853..89ca4d98284 100644 --- a/hugo/content/en/tracing/trace_collection/custom_instrumentation/_index.md +++ b/hugo/content/en/tracing/trace_collection/custom_instrumentation/_index.md @@ -36,7 +36,7 @@ Code-based custom instrumentation allows for precise monitoring of specific comp Code-based custom instrumentation involves embedding tracing code directly into your application code. This allows for the programmatic creation, modification, or deletion of traces to send to Datadog. -
    To add custom instrumentation at specific application code locations from the Datadog UI, without code changes, see Dynamic Instrumentation.
    +
    To add custom instrumentation at specific application code locations from the Datadog UI, without code changes, see {{< prodname >}}Dynamic Instrumentation{{< /prodname >}}.
    ## Getting started diff --git a/hugo/content/en/tracing/trace_collection/dd_libraries/_index.md b/hugo/content/en/tracing/trace_collection/dd_libraries/_index.md index 9dfbc37108c..9e4c97d6e90 100644 --- a/hugo/content/en/tracing/trace_collection/dd_libraries/_index.md +++ b/hugo/content/en/tracing/trace_collection/dd_libraries/_index.md @@ -52,7 +52,7 @@ For containerized environments, follow the links below to enable trace collectio ### AWS Lambda -To set up Datadog APM in AWS Lambda, see the [Tracing Serverless Functions][9] documentation. +To set up {{< prodname >}}Datadog APM{{< /prodname >}} in AWS Lambda, see the [Tracing Serverless Functions][9] documentation. ### Other environments diff --git a/hugo/content/en/tracing/trace_collection/dd_libraries/dotnet-core.md b/hugo/content/en/tracing/trace_collection/dd_libraries/dotnet-core.md index b7ff93dd90a..3df65ac4421 100644 --- a/hugo/content/en/tracing/trace_collection/dd_libraries/dotnet-core.md +++ b/hugo/content/en/tracing/trace_collection/dd_libraries/dotnet-core.md @@ -61,11 +61,11 @@ For a full list of Datadog's .NET Core library and processor architecture suppor ## Installation and getting started
    - To set up Datadog APM in Serverless environments, such as AWS Lambda or Azure Functions, see Serverless. + To set up {{< prodname >}}Datadog APM{{< /prodname >}} in Serverless environments, such as AWS Lambda or Azure Functions, see Serverless.
    - Note: Datadog's automatic instrumentation relies on the .NET CLR Profiling API. This API allows only one subscriber (for example, Datadog APM). To ensure maximum visibility, run only one APM solution in your application environment. + Note: Datadog's automatic instrumentation relies on the .NET CLR Profiling API. This API allows only one subscriber (for example, {{< prodname >}}Datadog APM{{< /prodname >}}). To ensure maximum visibility, run only one APM solution in your application environment.
    diff --git a/hugo/content/en/tracing/trace_collection/dd_libraries/dotnet-framework.md b/hugo/content/en/tracing/trace_collection/dd_libraries/dotnet-framework.md index 803a2be948b..fe0d02c57e3 100644 --- a/hugo/content/en/tracing/trace_collection/dd_libraries/dotnet-framework.md +++ b/hugo/content/en/tracing/trace_collection/dd_libraries/dotnet-framework.md @@ -62,11 +62,11 @@ For a full list of Datadog's .NET Framework library and processor architecture s ## Installation and getting started
    - To set up Datadog APM in Serverless environments, such as AWS Lambda or Azure Functions, see Serverless. + To set up {{< prodname >}}Datadog APM{{< /prodname >}} in Serverless environments, such as AWS Lambda or Azure Functions, see Serverless.
    - Note: Datadog's automatic instrumentation relies on the .NET CLR Profiling API. This API allows only one subscriber (for example, Datadog APM). To ensure maximum visibility, run only one APM solution in your application environment. + Note: Datadog's automatic instrumentation relies on the .NET CLR Profiling API. This API allows only one subscriber (for example, {{< prodname >}}Datadog APM{{< /prodname >}}). To ensure maximum visibility, run only one APM solution in your application environment.
    ### Installation diff --git a/hugo/content/en/tracing/trace_collection/dd_libraries/go.md b/hugo/content/en/tracing/trace_collection/dd_libraries/go.md index 68ebfcf5c3f..fcc3fb1fb2a 100644 --- a/hugo/content/en/tracing/trace_collection/dd_libraries/go.md +++ b/hugo/content/en/tracing/trace_collection/dd_libraries/go.md @@ -66,7 +66,7 @@ Refer to the instructions in the section corresponding to your preference below: - Comprehensive tracing coverage: - Instruments your code and all dependencies, including the Go standard library - Instruments your code during compilation, preventing gaps in tracing coverage due to overlooked manual instrumentation -- Exclusive [App and API Protection][7] **Exploit Prevention** feature. [Exploit Prevention][15] is a Runtime Application Self-Protection (RASP) implementation and includes RASP methods such as Local File Inclusion (LFI). +- Exclusive [{{< prodname >}}App and API Protection{{< /prodname >}}][7] **Exploit Prevention** feature. [Exploit Prevention][15] is a Runtime Application Self-Protection (RASP) implementation and includes RASP methods such as Local File Inclusion (LFI). ### Requirements diff --git a/hugo/content/en/tracing/trace_collection/dd_libraries/nodejs.md b/hugo/content/en/tracing/trace_collection/dd_libraries/nodejs.md index 0dd1a942ec3..9b969b6b764 100644 --- a/hugo/content/en/tracing/trace_collection/dd_libraries/nodejs.md +++ b/hugo/content/en/tracing/trace_collection/dd_libraries/nodejs.md @@ -278,7 +278,7 @@ export default nextConfig; The following features are turned off by default in the Node.js tracer. They do not support bundling and cannot be used if your application is bundled. -- APM: Dynamic Instrumentation +- APM: {{< prodname >}}Dynamic Instrumentation{{< /prodname >}} #### General bundling remarks diff --git a/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/_index.md b/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/_index.md index 9a1f5f942eb..ae97ea55efb 100644 --- a/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/_index.md +++ b/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/_index.md @@ -33,27 +33,27 @@ further_reading: ## Overview -Dynamic Instrumentation lets you add metrics, spans, and span tags to running production systems without restarts or code changes, including in third-party libraries. +{{< prodname >}}Dynamic Instrumentation{{< /prodname >}} lets you add metrics, spans, and span tags to running production systems without restarts or code changes, including in third-party libraries. -If you are interested in trying out the latest user experience improvements for Dynamic Instrumentation, consider opting into the [autocomplete and search Preview][17]. +If you are interested in trying out the latest user experience improvements for {{< prodname >}}Dynamic Instrumentation{{< /prodname >}}, consider opting into the [autocomplete and search Preview][17]. ## Getting started ### Prerequisites -Dynamic Instrumentation supports Java, Python, .NET, and PHP. It requires the following: +{{< prodname >}}Dynamic Instrumentation{{< /prodname >}} supports Java, Python, .NET, and PHP. It requires the following: - [Datadog Agent][1] 7.49.0 or higher is installed alongside your service. - [Remote Configuration][2] is enabled in that Agent. - A supported Datadog SDK is installed and up to date. See the [Enable Dynamic Instrumentation](#enable-dynamic-instrumentation) section for version requirements. - [Unified Service Tagging][6] tags `service`, `env`, and `version` are applied to your deployment. -- Recommended: [Source Code Integration][7] is set up for your service. +- Recommended: [{{< prodname >}}Source Code Integration{{< /prodname >}}][7] is set up for your service. ### Permissions -The following permissions are required to use Dynamic Instrumentation: +The following permissions are required to use {{< prodname >}}Dynamic Instrumentation{{< /prodname >}}: -- **Dynamic Instrumentation Read Configuration** (`debugger_read`): Required to access the Dynamic Instrumentation page. +- **Dynamic Instrumentation Read Configuration** (`debugger_read`): Required to access the {{< prodname >}}Dynamic Instrumentation{{< /prodname >}} page. - One of the following write permissions: - **Dynamic Instrumentation Write Configuration** (`debugger_write`): Required to create or modify instrumentations in any environment. - **Dynamic Instrumentation Write Pre-Prod** (`debugger_write_preprod`): Required to create or modify instrumentations in known pre-production environments only (such as staging or QA). @@ -63,7 +63,7 @@ For more information about roles and how to assign roles to users, see [Role Bas ### Enable Dynamic Instrumentation -
    Dynamic Instrumentation and Live Debugger share the same enablement state per service and environment: enabling or disabling one also enables or disables the other. The two products have separate permissions and Settings pages.
    +
    {{< prodname >}}Dynamic Instrumentation{{< /prodname >}} and Live Debugger share the same enablement state per service and environment: enabling or disabling one also enables or disables the other. The two products have separate permissions and Settings pages.
    #### (Recommended) In-app enablement {#in-app-enablement} @@ -77,7 +77,7 @@ If your SDK meets the minimum version and all prerequisites are met, Datadog aut #### Manual enablement -Manual enablement is required for PHP and for older SDK versions of Java, Python, and .NET. You can also choose manual enablement on supported SDK versions if you prefer to manage enablement through environment variables (for example, to enable Dynamic Instrumentation in bulk across many services). +Manual enablement is required for PHP and for older SDK versions of Java, Python, and .NET. You can also choose manual enablement on supported SDK versions if you prefer to manage enablement through environment variables (for example, to enable {{< prodname >}}Dynamic Instrumentation{{< /prodname >}} in bulk across many services). Select your runtime for manual enablement instructions: @@ -91,13 +91,13 @@ Select your runtime for manual enablement instructions: ### Limitations -- Dynamic Instrumentation is not compatible with Azure App Services or serverless environments. +- {{< prodname >}}Dynamic Instrumentation{{< /prodname >}} is not compatible with Azure App Services or serverless environments. - Not all instrumentation types are supported in every language. See the language-specific enabling pages linked from [Enable Dynamic Instrumentation](#enable-dynamic-instrumentation) for supported features and limitations. - The Java SDK does not support Kotlin coroutines. ## Explore Dynamic Instrumentation -Dynamic Instrumentation can help you understand what your application is doing at runtime. By adding an instrumentation at a specific code location, you can capture additional telemetry from your application without the need to change code or redeploy it. +{{< prodname >}}Dynamic Instrumentation{{< /prodname >}} can help you understand what your application is doing at runtime. By adding an instrumentation at a specific code location, you can capture additional telemetry from your application without the need to change code or redeploy it. ### Using instrumentations @@ -105,7 +105,7 @@ An instrumentation allows you to collect additional telemetry from specific poin Dynamic spans, span tags, and metrics are a UI-based alternative to adding custom instrumentation directly to your source code. Datadog receives the instrumentation configurations you define and dynamically applies them to the running service without requiring restarts. -Datadog captures and processes spans, tags, and metrics generated by Dynamic Instrumentation like other telemetry from the running application. Unlike manual custom instrumentation, Dynamic Instrumentation does not require code changes, deployments, or service restarts. To stop collecting data, disable the instrumentation in Datadog. +Datadog captures and processes spans, tags, and metrics generated by {{< prodname >}}Dynamic Instrumentation{{< /prodname >}} like other telemetry from the running application. Unlike manual custom instrumentation, {{< prodname >}}Dynamic Instrumentation{{< /prodname >}} does not require code changes, deployments, or service restarts. To stop collecting data, disable the instrumentation in Datadog. ### Creating an instrumentation @@ -116,7 +116,7 @@ All instrumentation types require the same initial setup: 1. If they are not prefilled, choose service, runtime, environment, and version (optional). 1. Specify where to set the instrumentation in the source code by selecting either a class and method, or a specific line of code in a file. When autocomplete and search are available, use them to find files, methods, or symbols. -For the best experience, set up [Source Code Integration][7] to view code directly in Datadog and select instrumentation locations as you would with breakpoints in an IDE. +For the best experience, set up [{{< prodname >}}Source Code Integration{{< /prodname >}}][7] to view code directly in Datadog and select instrumentation locations as you would with breakpoints in an IDE. For creation steps specific to each instrumentation type, see the following sections. @@ -134,7 +134,7 @@ A dynamic metric emits a metric when it executes. To create a dynamic metric: Metric instrumentations are automatically enabled on all service instances that match the configured environment and version. Metric instrumentations are not rate limited and execute every time the method or line is invoked. -Dynamic Instrumentation supports the following metric types: +{{< prodname >}}Dynamic Instrumentation{{< /prodname >}} supports the following metric types: - {{< ui >}}Count{{< /ui >}}: Counts how many times a given method or line is executed. Can be combined with [metric expressions][15] to use the value of a variable to increment the count. - {{< ui >}}Gauge{{< /ui >}}: Generates a gauge based on the last value of a variable. This metric requires a [metric expression][15]. @@ -161,7 +161,7 @@ To create a dynamic span tag: 1. Complete the [generic instrumentation setup](#creating-an-instrumentation) (choose service, environment, version, and location). 1. Specify a name for the tag. 1. Specify the value of the tag using the [Dynamic Instrumentation expression language][15]. -1. Optionally define a condition using the Dynamic Instrumentation expression language. The tag is added only when the expression evaluates to true. +1. Optionally define a condition using the {{< prodname >}}Dynamic Instrumentation{{< /prodname >}} expression language. The tag is added only when the expression evaluates to true. 1. Optionally add additional tags, each with their own name, expression, and optional condition. You can use a *dynamic span tag* as an alternative to [using Custom Instrumentation to add tags in code][14]. diff --git a/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/dotnet.md b/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/dotnet.md index 63d4a0b9403..f93b839ef2f 100644 --- a/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/dotnet.md +++ b/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/dotnet.md @@ -14,7 +14,7 @@ further_reading: text: 'Getting Started with Datadog Agent' --- -Dynamic Instrumentation is a feature of the Datadog SDK that lets you add instrumentation to your application at runtime without code changes or redeployments. Follow these instructions to set up Dynamic Instrumentation for .NET. +{{< prodname >}}Dynamic Instrumentation{{< /prodname >}} is a feature of the Datadog SDK that lets you add instrumentation to your application at runtime without code changes or redeployments. Follow these instructions to set up {{< prodname >}}Dynamic Instrumentation{{< /prodname >}} for .NET. ## Prerequisites @@ -25,8 +25,8 @@ Before you begin, review the [Dynamic Instrumentation prerequisites][9]. .NET ap ## Installation 1. If you don't already have APM enabled, in your Agent configuration, set the `DD_APM_ENABLED` environment variable to `true` and listening to the port `8126/TCP`. -2. Run your service with Dynamic Instrumentation enabled by setting the `DD_DYNAMIC_INSTRUMENTATION_ENABLED` environment variable to `true`. Specify `DD_SERVICE`, `DD_ENV`, and `DD_VERSION` Unified Service Tags so you can filter and group your instrumentations and target active clients across these dimensions. -3. After starting your service with Dynamic Instrumentation enabled, you can start using Dynamic Instrumentation on the [APM > Dynamic Instrumentation page][4]. +2. Run your service with {{< prodname >}}Dynamic Instrumentation{{< /prodname >}} enabled by setting the `DD_DYNAMIC_INSTRUMENTATION_ENABLED` environment variable to `true`. Specify `DD_SERVICE`, `DD_ENV`, and `DD_VERSION` Unified Service Tags so you can filter and group your instrumentations and target active clients across these dimensions. +3. After starting your service with {{< prodname >}}Dynamic Instrumentation{{< /prodname >}} enabled, you can start using {{< prodname >}}Dynamic Instrumentation{{< /prodname >}} on the [APM > Dynamic Instrumentation page][4]. ## Configuration @@ -42,7 +42,7 @@ Configure Dynamic Instrumentation using the following environment variables: ## What to do next -See [Dynamic Instrumentation][6] for information about adding instrumentations and browsing and indexing the data. +See [{{< prodname >}}Dynamic Instrumentation{{< /prodname >}}][6] for information about adding instrumentations and browsing and indexing the data. ## Further reading diff --git a/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/java.md b/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/java.md index 965d1ee2e4f..58001df2a0a 100644 --- a/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/java.md +++ b/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/java.md @@ -14,7 +14,7 @@ further_reading: text: 'Getting Started with Datadog Agent' --- -Dynamic Instrumentation is a feature of the Datadog SDK that lets you add instrumentation to your application at runtime without code changes or redeployments. Follow these instructions to set up Dynamic Instrumentation for Java. +{{< prodname >}}Dynamic Instrumentation{{< /prodname >}} is a feature of the Datadog SDK that lets you add instrumentation to your application at runtime without code changes or redeployments. Follow these instructions to set up {{< prodname >}}Dynamic Instrumentation{{< /prodname >}} for Java. ## Prerequisites @@ -46,7 +46,7 @@ Before you begin, review the [Dynamic Instrumentation prerequisites][9]. Java ap {{% /tab %}} {{< /tabs >}} -3. Run your service with Dynamic Instrumentation enabled by setting `-Ddd.dynamic.instrumentation.enabled` flag or `DD_DYNAMIC_INSTRUMENTATION_ENABLED` environment variable to `true`. Specify `dd.service`, `dd.env`, and `dd.version` Unified Service Tags so you can filter and group your instrumentations and target active clients across these dimensions. +3. Run your service with {{< prodname >}}Dynamic Instrumentation{{< /prodname >}} enabled by setting `-Ddd.dynamic.instrumentation.enabled` flag or `DD_DYNAMIC_INSTRUMENTATION_ENABLED` environment variable to `true`. Specify `dd.service`, `dd.env`, and `dd.version` Unified Service Tags so you can filter and group your instrumentations and target active clients across these dimensions. {{< tabs >}} {{% tab "Command arguments" %}} @@ -84,7 +84,7 @@ java \ java -jar my-service.jar -javaagent:dd-java-agent.jar ... ``` -4. After starting your service with Dynamic Instrumentation enabled, you can start using Dynamic Instrumentation on the [APM > Dynamic Instrumentation page][4]. +4. After starting your service with {{< prodname >}}Dynamic Instrumentation{{< /prodname >}} enabled, you can start using {{< prodname >}}Dynamic Instrumentation{{< /prodname >}} on the [APM > Dynamic Instrumentation page][4]. ## Configuration @@ -100,7 +100,7 @@ Configure Dynamic Instrumentation using the following environment variables: ## What to do next -See [Dynamic Instrumentation][6] for information about adding instrumentations and browsing and indexing the data. +See [{{< prodname >}}Dynamic Instrumentation{{< /prodname >}}][6] for information about adding instrumentations and browsing and indexing the data. ## Limitations diff --git a/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/php.md b/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/php.md index 23113609c65..489c12e5ecd 100644 --- a/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/php.md +++ b/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/php.md @@ -14,7 +14,7 @@ further_reading: text: 'Getting Started with Datadog Agent' --- -Dynamic Instrumentation is a feature of the Datadog SDK that lets you add instrumentation to your application at runtime without code changes or redeployments. Follow these instructions to set up Dynamic Instrumentation for PHP. +{{< prodname >}}Dynamic Instrumentation{{< /prodname >}} is a feature of the Datadog SDK that lets you add instrumentation to your application at runtime without code changes or redeployments. Follow these instructions to set up {{< prodname >}}Dynamic Instrumentation{{< /prodname >}} for PHP. ## Prerequisites @@ -25,8 +25,8 @@ Before you begin, review the [Dynamic Instrumentation prerequisites][10]. PHP ap ## Installation 1. If you don't already have APM enabled, in your Agent configuration, set the `DD_APM_ENABLED` environment variable to `true` and listening to the port `8126/TCP`. -2. Run your service with Dynamic Instrumentation enabled by setting the `DD_DYNAMIC_INSTRUMENTATION_ENABLED` environment variable to `true`. Specify `DD_SERVICE`, `DD_ENV`, and `DD_VERSION` Unified Service Tags so you can filter and group your instrumentations and target active clients across these dimensions. -3. After starting your service with Dynamic Instrumentation enabled, you can start using Dynamic Instrumentation on the [APM > Dynamic Instrumentation page][3]. +2. Run your service with {{< prodname >}}Dynamic Instrumentation{{< /prodname >}} enabled by setting the `DD_DYNAMIC_INSTRUMENTATION_ENABLED` environment variable to `true`. Specify `DD_SERVICE`, `DD_ENV`, and `DD_VERSION` Unified Service Tags so you can filter and group your instrumentations and target active clients across these dimensions. +3. After starting your service with {{< prodname >}}Dynamic Instrumentation{{< /prodname >}} enabled, you can start using {{< prodname >}}Dynamic Instrumentation{{< /prodname >}} on the [APM > Dynamic Instrumentation page][3]. ## Configuration @@ -42,7 +42,7 @@ Configure Dynamic Instrumentation using the following environment variables: ## What to do next -See [Dynamic Instrumentation][5] for information about adding instrumentations and browsing and indexing the data. +See [{{< prodname >}}Dynamic Instrumentation{{< /prodname >}}][5] for information about adding instrumentations and browsing and indexing the data. ## Limitations diff --git a/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/python.md b/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/python.md index 209085a9822..b294bc4afc8 100644 --- a/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/python.md +++ b/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/python.md @@ -14,7 +14,7 @@ further_reading: text: 'Getting Started with Datadog Agent' --- -Dynamic Instrumentation is a feature of the Datadog SDK that lets you add instrumentation to your application at runtime without code changes or redeployments. Follow these instructions to set up Dynamic Instrumentation for Python. +{{< prodname >}}Dynamic Instrumentation{{< /prodname >}} is a feature of the Datadog SDK that lets you add instrumentation to your application at runtime without code changes or redeployments. Follow these instructions to set up {{< prodname >}}Dynamic Instrumentation{{< /prodname >}} for Python. ## Prerequisites @@ -26,13 +26,13 @@ Before you begin, review the [Dynamic Instrumentation prerequisites][7]. Python 1. If you don't already have APM enabled, in your Agent configuration, set the `DD_APM_ENABLED` environment variable to `true` and listening to the port `8126/TCP`. -2. Install `ddtrace`, which provides both tracing and Dynamic Instrumentation: +2. Install `ddtrace`, which provides both tracing and {{< prodname >}}Dynamic Instrumentation{{< /prodname >}}: ```shell pip install ddtrace ``` -3. Run your service with Dynamic Instrumentation enabled by setting the `DD_DYNAMIC_INSTRUMENTATION_ENABLED` environment variable to `true`. Specify `DD_SERVICE`, `DD_ENV`, and `DD_VERSION` Unified Service Tags so you can filter and group your instrumentations and target active clients across these dimensions. +3. Run your service with {{< prodname >}}Dynamic Instrumentation{{< /prodname >}} enabled by setting the `DD_DYNAMIC_INSTRUMENTATION_ENABLED` environment variable to `true`. Specify `DD_SERVICE`, `DD_ENV`, and `DD_VERSION` Unified Service Tags so you can filter and group your instrumentations and target active clients across these dimensions. {{< tabs >}} {{% tab "Environment variables" %}} @@ -57,7 +57,7 @@ import ddtrace.auto # IMPORTANT: this must be imported as soon as possible. {{% /tab %}} {{< /tabs >}} -4. After starting your service with Dynamic Instrumentation enabled, you can start using it on the [APM > Dynamic Instrumentation page][3]. +4. After starting your service with {{< prodname >}}Dynamic Instrumentation{{< /prodname >}} enabled, you can start using it on the [APM > Dynamic Instrumentation page][3]. ## Configuration @@ -73,7 +73,7 @@ Configure Dynamic Instrumentation using the following environment variables: ## What to do next -See [Dynamic Instrumentation][5] for information about adding instrumentations and browsing and indexing the data. +See [{{< prodname >}}Dynamic Instrumentation{{< /prodname >}}][5] for information about adding instrumentations and browsing and indexing the data. ## Further reading diff --git a/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/expression-language.md b/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/expression-language.md index 151caa446fa..2f5f953c696 100644 --- a/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/expression-language.md +++ b/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/expression-language.md @@ -23,7 +23,7 @@ Generally, the Expression Language supports: * Using the `null` literal (which is automatically translated to `None` in Python and `nil` in Ruby). It does **not** support: -* Calling methods. Dynamic Instrumentation does not permit executing code that may have side effects. However, you can access `private` fields directly. +* Calling methods. {{< prodname >}}Dynamic Instrumentation{{< /prodname >}} does not permit executing code that may have side effects. However, you can access `private` fields directly. * Other native programming language syntax beyond what is described on this page. Try [autocomplete and search (in Preview)](/dynamic_instrumentation/symdb/) for an improved user experience using the Expression Language. diff --git a/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/sensitive-data-scrubbing.md b/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/sensitive-data-scrubbing.md index 7cc68177b99..267409c490b 100644 --- a/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/sensitive-data-scrubbing.md +++ b/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/sensitive-data-scrubbing.md @@ -19,13 +19,13 @@ Datadog Dynamic Instrumentation enhances the observability and debugging capabil While this functionality is powerful, it also presents the possibility of sensitive data leaks, both intentional and unintentional. Alongside the product's robust data capture capabilities, it also provides comprehensive measures to safeguard sensitive information. -By understanding and properly configuring these redaction mechanisms, you can use Dynamic Instrumentation with confidence and security. +By understanding and properly configuring these redaction mechanisms, you can use {{< prodname >}}Dynamic Instrumentation{{< /prodname >}} with confidence and security. ## Redact based on identifiers ### Default behavior -Dynamic Instrumentation automatically redacts values linked to specific identifiers deemed sensitive, such as `password` and `accessToken`. See [the full list of redacted identifiers][1]. +{{< prodname >}}Dynamic Instrumentation{{< /prodname >}} automatically redacts values linked to specific identifiers deemed sensitive, such as `password` and `accessToken`. See [the full list of redacted identifiers][1]. ### Custom identifier redaction @@ -50,11 +50,11 @@ Class-based redaction: ### Initial setup -When you first access [Dynamic Instrumentation Setup][2], you can optionally set up default Sensitive Data Scanner rules for Dynamic Instrumentation. These cover common regular expressions for likely sensitive data such as email addresses or JWT tokens. +When you first access [Dynamic Instrumentation Setup][2], you can optionally set up default Sensitive Data Scanner rules for {{< prodname >}}Dynamic Instrumentation{{< /prodname >}}. These cover common regular expressions for likely sensitive data such as email addresses or JWT tokens. ### Customizing Sensitive Data Scanner -You can disable the default rules or create other rules through the [Sensitive Data Scanner][4]. To create a new Sensitive Data Scanner rule for Dynamic Instrumentation, set it to filter on `source:dd_debugger`. +You can disable the default rules or create other rules through the [Sensitive Data Scanner][4]. To create a new Sensitive Data Scanner rule for {{< prodname >}}Dynamic Instrumentation{{< /prodname >}}, set it to filter on `source:dd_debugger`. **Note**: Datadog Sensitive Data Scanner performs its redaction _after_ the information is uploaded to Datadog. diff --git a/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/symdb/_index.md b/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/symdb/_index.md index f8ba59eeb9b..38680f6701d 100644 --- a/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/symdb/_index.md +++ b/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/symdb/_index.md @@ -19,7 +19,7 @@ Autocomplete and search are in Preview for Python and .NET. ## Overview -Autocomplete and search enhance the user experience of [Dynamic Instrumentation][1] by adding IDE-like features like class and method search and autocomplete for [Dynamic Instrumentation Expression Language][5]. +Autocomplete and search enhance the user experience of [{{< prodname >}}Dynamic Instrumentation{{< /prodname >}}][1] by adding IDE-like features like class and method search and autocomplete for [Dynamic Instrumentation Expression Language][5]. To provide autocomplete and search, nonsensitive symbols and metadata are uploaded from your application to Datadog. The uploaded data includes the names of classes, methods, arguments, fields, and local variables, along with related metadata, like line numbers. @@ -29,7 +29,7 @@ To provide autocomplete and search, nonsensitive symbols and metadata are upload Autocomplete and search require the following: -- [Dynamic Instrumentation][1] is enabled for your service. +- [{{< prodname >}}Dynamic Instrumentation{{< /prodname >}}][1] is enabled for your service. - [Datadog Agent][2] 7.49.0 or higher is installed alongside your service. - [Remote Configuration][3] is enabled in the Agent. - The [Unified Service Tagging][4] tags `service`, `env`, and `version` are applied to your deployment. @@ -47,10 +47,10 @@ Select your runtime below: ## Explore autocomplete and search -Autocomplete and search make Dynamic Instrumentation behave more like an IDE: +Autocomplete and search make {{< prodname >}}Dynamic Instrumentation{{< /prodname >}} behave more like an IDE: - **Class and method search**: Find where to add instrumentation. -- **Code display**: When you select a method in the Dynamic Instrumentation configuration, Datadog displays the code for that method. +- **Code display**: When you select a method in the {{< prodname >}}Dynamic Instrumentation{{< /prodname >}} configuration, Datadog displays the code for that method. - **Expression autocomplete**: Get suggestions for expression templates that use the [Dynamic Instrumentation expression language][5]. ## Further Reading diff --git a/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/symdb/dotnet.md b/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/symdb/dotnet.md index e884c32a3f7..d3ec84211f6 100644 --- a/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/symdb/dotnet.md +++ b/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/symdb/dotnet.md @@ -16,16 +16,16 @@ Autocomplete and search are in Preview. ## Requirements -- [Dynamic Instrumentation][1] is enabled for your service. +- [{{< prodname >}}Dynamic Instrumentation{{< /prodname >}}][1] is enabled for your service. - Tracing library [`dd-trace-dotnet`][6] 2.58.0 or higher is installed. ## Installation -Run your service with Dynamic Instrumentation enabled, and additionally enable autocomplete and search: +Run your service with {{< prodname >}}Dynamic Instrumentation{{< /prodname >}} enabled, and additionally enable autocomplete and search: 1. Set the `DD_SYMBOL_DATABASE_UPLOAD_ENABLED=true` environment variable. 2. Specify the `DD_SERVICE` and `DD_VERSION` [Unified Service Tags][5]. -3. After starting your service with Dynamic Instrumentation and autocomplete and search enabled, you can use Dynamic Instrumentation's IDE-like features on the [{{< ui >}}APM{{< /ui >}} > {{< ui >}}Dynamic Instrumentation{{< /ui >}}][4] page. +3. After starting your service with {{< prodname >}}Dynamic Instrumentation{{< /prodname >}} and autocomplete and search enabled, you can use {{< prodname >}}Dynamic Instrumentation{{< /prodname >}}'s IDE-like features on the [{{< ui >}}APM{{< /ui >}} > {{< ui >}}Dynamic Instrumentation{{< /ui >}}][4] page. ## Additional configuration diff --git a/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/symdb/java.md b/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/symdb/java.md index a84221534f0..948fc6e1c78 100644 --- a/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/symdb/java.md +++ b/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/symdb/java.md @@ -13,12 +13,12 @@ aliases: ## Requirements -- [Dynamic Instrumentation][1] is enabled for your service. +- [{{< prodname >}}Dynamic Instrumentation{{< /prodname >}}][1] is enabled for your service. - Tracing library [`dd-trace-java`][6] 1.42.0 or higher is installed. ## Installation -Run your service with Dynamic Instrumentation enabled, autocomplete and search are automatically enabled. +Run your service with {{< prodname >}}Dynamic Instrumentation{{< /prodname >}} enabled, autocomplete and search are automatically enabled. ## Additional configuration diff --git a/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/symdb/python.md b/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/symdb/python.md index ae9fc28ff93..54c0a0abb6e 100644 --- a/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/symdb/python.md +++ b/hugo/content/en/tracing/trace_collection/dynamic_instrumentation/symdb/python.md @@ -16,14 +16,14 @@ Autocomplete and search are in Preview. ## Requirements -- [Dynamic Instrumentation][1] is enabled for your service. +- [{{< prodname >}}Dynamic Instrumentation{{< /prodname >}}][1] is enabled for your service. - Tracing library [`dd-trace-py`][6] 2.9.0 or higher is installed. ## Installation -Run your service with Dynamic Instrumentation enabled, and additionally enable autocomplete and search: +Run your service with {{< prodname >}}Dynamic Instrumentation{{< /prodname >}} enabled, and additionally enable autocomplete and search: -1. Run your service with Dynamic Instrumentation enabled by setting the `DD_DYNAMIC_INSTRUMENTATION_ENABLED` environment variable to `true`. +1. Run your service with {{< prodname >}}Dynamic Instrumentation{{< /prodname >}} enabled by setting the `DD_DYNAMIC_INSTRUMENTATION_ENABLED` environment variable to `true`. 2. Specify `DD_SERVICE` and `DD_VERSION` [Unified Service Tags][5]. 3. Invoke your service: @@ -36,7 +36,7 @@ Run your service with Dynamic Instrumentation enabled, and additionally enable a ddtrace-run python -m myapp ``` -After starting your service with the required features enabled, you can use Dynamic Instrumentation's IDE-like features on the [{{< ui >}}APM{{< /ui >}} > {{< ui >}}Dynamic Instrumentation{{< /ui >}}][4] page. +After starting your service with the required features enabled, you can use {{< prodname >}}Dynamic Instrumentation{{< /prodname >}}'s IDE-like features on the [{{< ui >}}APM{{< /ui >}} > {{< ui >}}Dynamic Instrumentation{{< /ui >}}][4] page. ## Additional configuration diff --git a/hugo/content/en/tracing/trace_collection/proxy_setup/apigateway.md b/hugo/content/en/tracing/trace_collection/proxy_setup/apigateway.md index 456d6e433f3..03e856c30b7 100644 --- a/hugo/content/en/tracing/trace_collection/proxy_setup/apigateway.md +++ b/hugo/content/en/tracing/trace_collection/proxy_setup/apigateway.md @@ -21,7 +21,7 @@ This feature is in Preview. {{< /callout >}} -Datadog APM can create **inferred spans** for requests that pass through Amazon API Gateway to container- or EC2-hosted services. The spans power end-to-end traces, service maps, and sampling based on the gateway itself. +{{< prodname >}}Datadog APM{{< /prodname >}} can create **inferred spans** for requests that pass through Amazon API Gateway to container- or EC2-hosted services. The spans power end-to-end traces, service maps, and sampling based on the gateway itself.
    If your API Gateway integrates with AWS Lambda, do not follow the instructions on this page. Datadog Lambda layers already emit inferred API Gateway spans; adding the proxy headers described here can create duplicate or conflicting traces.
    diff --git a/hugo/content/en/tracing/trace_collection/proxy_setup/azure_apim.md b/hugo/content/en/tracing/trace_collection/proxy_setup/azure_apim.md index e9f9be91595..9d130e6f898 100644 --- a/hugo/content/en/tracing/trace_collection/proxy_setup/azure_apim.md +++ b/hugo/content/en/tracing/trace_collection/proxy_setup/azure_apim.md @@ -15,7 +15,7 @@ further_reading: text: "Trace Context Propagation" --- -Datadog APM can create **inferred spans** for requests that pass through Azure API Management to your backend services. The spans enable end-to-end traces, service maps, and sampling based on the API Management gateway. +{{< prodname >}}Datadog APM{{< /prodname >}} can create **inferred spans** for requests that pass through Azure API Management to your backend services. The spans enable end-to-end traces, service maps, and sampling based on the API Management gateway. Inferred spans for Azure API Management are supported for **.NET**, **JavaScript** (Node.js), **Python**, and **Java** only. Other runtimes (for example Go or PHP) do not emit Azure API Management inferred spans, even if they support inferred spans for other gateways. diff --git a/hugo/content/en/tracing/trace_collection/proxy_setup/envoy.md b/hugo/content/en/tracing/trace_collection/proxy_setup/envoy.md index 9d1d6692d1c..80791fc899f 100644 --- a/hugo/content/en/tracing/trace_collection/proxy_setup/envoy.md +++ b/hugo/content/en/tracing/trace_collection/proxy_setup/envoy.md @@ -23,13 +23,13 @@ aliases: - /tracing/setup_overview/proxy_setup/ --- -Datadog APM is included in Envoy v1.9.0 and newer. +{{< prodname >}}Datadog APM{{< /prodname >}} is included in Envoy v1.9.0 and newer. ## Enabling Datadog APM **Note**: The example configuration below is for Envoy v1.19. -The following settings are required to enable Datadog APM in Envoy: +The following settings are required to enable {{< prodname >}}Datadog APM{{< /prodname >}} in Envoy: - a cluster for submitting traces to the Datadog Agent - `http_connection_manager` configuration to activate tracing @@ -82,7 +82,7 @@ With this configuration, HTTP requests to Envoy initiate and propagate Datadog t ## Example Envoy v1.19 configuration -The following example configuration demonstrates the placement of items required to enable tracing using Datadog APM. +The following example configuration demonstrates the placement of items required to enable tracing using {{< prodname >}}Datadog APM{{< /prodname >}}. {{< highlight yaml "hl_lines=18-24 66-78" >}} static_resources: diff --git a/hugo/content/en/tracing/trace_collection/proxy_setup/istio.md b/hugo/content/en/tracing/trace_collection/proxy_setup/istio.md index 782bdb74937..f1df45d90c3 100644 --- a/hugo/content/en/tracing/trace_collection/proxy_setup/istio.md +++ b/hugo/content/en/tracing/trace_collection/proxy_setup/istio.md @@ -27,7 +27,7 @@ Datadog monitors every aspect of your Istio environment, so you can: To learn more about monitoring your Istio environment with Datadog, [see the Istio blog][3]. -Datadog APM is available for [supported Istio releases][13]. +{{< prodname >}}Datadog APM{{< /prodname >}} is available for [supported Istio releases][13]. ## Datadog Agent installation @@ -38,7 +38,7 @@ Datadog APM is available for [supported Istio releases][13]. ## Istio configuration and installation -To enable Datadog APM, a [custom Istio installation][6] is required to set two extra options when installing Istio. +To enable {{< prodname >}}Datadog APM{{< /prodname >}}, a [custom Istio installation][6] is required to set two extra options when installing Istio. - `--set values.global.proxy.tracer=datadog` - `--set values.pilot.traceSampling=100.0` diff --git a/hugo/content/en/tracing/trace_collection/proxy_setup/kong.md b/hugo/content/en/tracing/trace_collection/proxy_setup/kong.md index 98ba08a852b..5a5acfd3344 100644 --- a/hugo/content/en/tracing/trace_collection/proxy_setup/kong.md +++ b/hugo/content/en/tracing/trace_collection/proxy_setup/kong.md @@ -15,7 +15,7 @@ aliases: - /tracing/setup_overview/proxy_setup/ --- -Datadog APM is available for [Kong Gateway][1] using the [kong-plugin-ddtrace][2] plugin. +{{< prodname >}}Datadog APM{{< /prodname >}} is available for [Kong Gateway][1] using the [kong-plugin-ddtrace][2] plugin. ## Installation diff --git a/hugo/content/en/tracing/trace_collection/proxy_setup/nginx.md b/hugo/content/en/tracing/trace_collection/proxy_setup/nginx.md index c2e22dc9330..3e2dec4c34d 100644 --- a/hugo/content/en/tracing/trace_collection/proxy_setup/nginx.md +++ b/hugo/content/en/tracing/trace_collection/proxy_setup/nginx.md @@ -19,7 +19,7 @@ aliases: - /tracing/setup_overview/proxy_setup/ --- -Datadog APM supports NGINX in two configurations: +{{< prodname >}}Datadog APM{{< /prodname >}} supports NGINX in two configurations: - NGINX operated as a proxy with tracing provided by the Datadog module. - NGINX as an Ingress Controller for Kubernetes. diff --git a/hugo/content/en/tracing/trace_collection/span_links/_index.md b/hugo/content/en/tracing/trace_collection/span_links/_index.md index ef07a677473..57babaa47aa 100644 --- a/hugo/content/en/tracing/trace_collection/span_links/_index.md +++ b/hugo/content/en/tracing/trace_collection/span_links/_index.md @@ -54,7 +54,7 @@ If your application is instrumented with: ## Minimum support -**Note***: This section documents minimum support for generating span links with Datadog APM client libraries (with the OpenTelemetry API). Span links generated by the OpenTelemetry SDK are sent to Datadog through [OTLP Ingest][8]. +**Note***: This section documents minimum support for generating span links with {{< prodname >}}Datadog APM{{< /prodname >}} client libraries (with the OpenTelemetry API). Span links generated by the OpenTelemetry SDK are sent to Datadog through [OTLP Ingest][8]. Agent v7.52.0 or greater is required to generate span links using [Datadog SDKs][7]. Support for span links was introduced in the following releases: diff --git a/hugo/content/en/tracing/trace_explorer/_index.md b/hugo/content/en/tracing/trace_explorer/_index.md index bda23e3c314..f0c46f9ea09 100644 --- a/hugo/content/en/tracing/trace_explorer/_index.md +++ b/hugo/content/en/tracing/trace_explorer/_index.md @@ -54,7 +54,7 @@ You can customize settings for both [ingestion and retention][6] to send and kee #### Ingestion -Control your volume globally with [Datadog Agent configuration options][7] or set precise [ingestion rules][8] per service instrumented with Datadog APM. +Control your volume globally with [Datadog Agent configuration options][7] or set precise [ingestion rules][8] per service instrumented with {{< prodname >}}Datadog APM{{< /prodname >}}. #### Indexing diff --git a/hugo/content/en/tracing/trace_explorer/visualize.md b/hugo/content/en/tracing/trace_explorer/visualize.md index 8a46d006572..5d0f2996752 100644 --- a/hugo/content/en/tracing/trace_explorer/visualize.md +++ b/hugo/content/en/tracing/trace_explorer/visualize.md @@ -35,7 +35,7 @@ The configuration of the columns is stored alongside other elements of your trou The `Latency Breakdown` of the trace might be missing for some spans if the trace is malformed or incomplete. For instance, the error and the rare samplers capture pieces of traces, without the guarantee of capturing the complete trace. In this case, the data is omitted to avoid displaying inconsistent or misleading latency information that would only make sense when the trace is complete. -When the query is filtered on error spans, select the {{< ui >}}Group into Issues{{< /ui >}} option to visualize a list of [Error Tracking][5] issues instead of individual error spans. Click on any issue in the issue list to open the issue panel and access additional information about this group of errors. +When the query is filtered on error spans, select the {{< ui >}}Group into Issues{{< /ui >}} option to visualize a list of [{{< prodname >}}Error Tracking{{< /prodname >}}][5] issues instead of individual error spans. Click on any issue in the issue list to open the issue panel and access additional information about this group of errors. {{< img src="tracing/trace_explorer/visualize/trace_explorer_issue_grouping.png" alt="Error Tracking Issue Grouping" style="width:100%;">}} diff --git a/hugo/content/en/tracing/trace_pipeline/generate_metrics.md b/hugo/content/en/tracing/trace_pipeline/generate_metrics.md index 1d9045d9d24..1a1b4419e1d 100644 --- a/hugo/content/en/tracing/trace_pipeline/generate_metrics.md +++ b/hugo/content/en/tracing/trace_pipeline/generate_metrics.md @@ -26,7 +26,7 @@ further_reading: Generate custom metrics from ingested spans to track trends, power dashboards, and trigger monitors—even for spans and traces that are not retained for full trace analysis. -Custom metrics are created from spans ingested by Datadog APM, regardless of whether a [retention filter][1] indexes those spans. Extract numeric values from spans (such as counts, durations, or custom tags) or traces (end-to-end trace duration) and store them as long-lived [custom metrics][3] with 15-month retention. +Custom metrics are created from spans ingested by {{< prodname >}}Datadog APM{{< /prodname >}}, regardless of whether a [retention filter][1] indexes those spans. Extract numeric values from spans (such as counts, durations, or custom tags) or traces (end-to-end trace duration) and store them as long-lived [custom metrics][3] with 15-month retention. **Notes:** - Datadog automatically generates [Trace Metrics][13] that capture request counts, error rates, and latency distributions for 100% of your application traffic. diff --git a/hugo/content/en/tracing/trace_pipeline/metrics.md b/hugo/content/en/tracing/trace_pipeline/metrics.md index 7f148f475a4..3d543c321ed 100644 --- a/hugo/content/en/tracing/trace_pipeline/metrics.md +++ b/hugo/content/en/tracing/trace_pipeline/metrics.md @@ -33,7 +33,7 @@ The following metrics are available in your account: Leverage these metrics in dashboards and monitors to visualize and control your usage. Two out-of-the box dashboards are built with these metrics. These dashboards help monitor your APM usage as well as your ingested and indexed span volumes. -Datadog APM plans come with indexed and ingested spans included. For more information, see the [Pricing page][3] or some [pricing example scenarios][4]. +{{< prodname >}}Datadog APM{{< /prodname >}} plans come with indexed and ingested spans included. For more information, see the [Pricing page][3] or some [pricing example scenarios][4]. ### Ingested spans volume diff --git a/hugo/content/en/tracing/trace_pipeline/trace_retention.md b/hugo/content/en/tracing/trace_pipeline/trace_retention.md index ec6322ecd4e..317dc321606 100644 --- a/hugo/content/en/tracing/trace_pipeline/trace_retention.md +++ b/hugo/content/en/tracing/trace_pipeline/trace_retention.md @@ -86,9 +86,9 @@ There are two types of retention filters: The following retention filters are enabled by default: - The `Error Default` retention filter indexes error spans with `status:error`. The retention rate and the query are configurable. For example, to capture production errors, set the query to `status:error, env:production`. Disable the retention filter if you do not want to capture the errors by default. -- The `App and API Protection Default` retention filter is enabled if you are using [App and API Protection][16]. It ensures the retention of all spans in traces that have been identified as having an application security impact (an attack attempt). +- The `App and API Protection Default` retention filter is enabled if you are using [{{< prodname >}}App and API Protection{{< /prodname >}}][16]. It ensures the retention of all spans in traces that have been identified as having an application security impact (an attack attempt). - The `Synthetics Default` retention filter is enabled if you are using Synthetic Monitoring. It ensures that traces generated from synthetic API and browser tests remain available by default. See [Synthetic APM][15] for more information, including how to correlate traces with synthetic tests. -- The `Dynamic Instrumentation Default` retention filter is enabled if you are using [Dynamic Instrumentation][17]. It ensures spans created dynamically with Dynamic instrumentation remain available in the long term by default. +- The `Dynamic Instrumentation Default` retention filter is enabled if you are using [{{< prodname >}}Dynamic Instrumentation{{< /prodname >}}][17]. It ensures spans created dynamically with Dynamic instrumentation remain available in the long term by default. ### Datadog intelligent retention filter diff --git a/hugo/content/en/tracing/troubleshooting/_index.md b/hugo/content/en/tracing/troubleshooting/_index.md index 5b56edca157..61b62256a6c 100644 --- a/hugo/content/en/tracing/troubleshooting/_index.md +++ b/hugo/content/en/tracing/troubleshooting/_index.md @@ -39,7 +39,7 @@ further_reading: text: Troubleshooting APM Instrumentation on a Host --- -If you experience unexpected behavior while using Datadog APM, read the information on this page to help resolve the issue. Datadog recommends regularly updating to the latest version of the Datadog SDKs you use, as each release contains improvements and fixes. If you continue to experience issues, reach out to [Datadog support][1]. +If you experience unexpected behavior while using {{< prodname >}}Datadog APM{{< /prodname >}}, read the information on this page to help resolve the issue. Datadog recommends regularly updating to the latest version of the Datadog SDKs you use, as each release contains improvements and fixes. If you continue to experience issues, reach out to [Datadog support][1]. The following components are involved in sending APM data to Datadog: @@ -236,7 +236,7 @@ If the number of services exceeds what is specified in the [data volume guidelin ### Exclude environment tag values from service names -By default, the environment (`env`) is the primary tag for [Datadog APM][17]. +By default, the environment (`env`) is the primary tag for [{{< prodname >}}Datadog APM{{< /prodname >}}][17]. {{< img src="/tracing/troubleshooting/troubleshooting-service-naming-convention-issues-3.png" alt="Environment is the default primary tag" style="width:100%;" >}}
    Dynamic Instrumentation{{< prodname >}}Dynamic Instrumentation{{< /prodname >}} Code-based custom instrumentation