If you are collecting traces from a containerized app (your Agent and app running in separate containers), as an alternative to the following instructions, you can automatically inject the tracing library into your application. Read Injecting Libraries for instructions.
+If you are collecting traces from a containerized app (your Agent and app running in separate containers), as an alternative to the following instructions, you can automatically inject the SDK into your application. Read Injecting Libraries for instructions.
## Tracing from the host
@@ -225,7 +225,7 @@ Where your `If your application uses
+context_info for instrumentation, the APM tracer overwrites it.If your application uses
- The instrumentation executes a `SET context_info` command when the client issues a query, which makes an additional round-trip to the database.
- Prerequisites:
@@ -377,7 +377,7 @@ Enable the database monitoring propagation feature by setting the following envi
{{% tab "PHP" %}}
context_info for instrumentation, the Datadog SDK overwrites it.
-This feature requires the tracer extension to be enabled for your PHP service.
+This feature requires the SDK extension to be enabled for your PHP service.
Follow the [PHP tracing instructions][1] to install the automatic instrumentation package and enable tracing for your service.
@@ -399,7 +399,7 @@ Install or update [dd-trace-js][1] to a version greater than `3.17.0` (or `2.30.
npm install dd-trace@^3.17.0
```
-Update your code to import and initialize the tracer:
+Update your code to import and initialize the SDK:
```javascript
// This line must come before importing any instrumented module.
const tracer = require('dd-trace').init();
@@ -411,7 +411,7 @@ Enable the database monitoring propagation feature using one of the following me
DD_DBM_PROPAGATION_MODE=full
```
-* Set the tracer to use the `dbmPropagationMode` option (default: `ENV['DD_DBM_PROPAGATION_MODE']`):
+* Set the SDK to use the `dbmPropagationMode` option (default: `ENV['DD_DBM_PROPAGATION_MODE']`):
```javascript
const tracer = require('dd-trace').init({ dbmPropagationMode: 'full' })
```
diff --git a/content/en/ddsql_reference/ddsql_preview/ddsql_use_cases.md b/content/en/ddsql_reference/ddsql_preview/ddsql_use_cases.md
index c4f718bcdb4..a7375108604 100644
--- a/content/en/ddsql_reference/ddsql_preview/ddsql_use_cases.md
+++ b/content/en/ddsql_reference/ddsql_preview/ddsql_use_cases.md
@@ -42,7 +42,7 @@ WHERE
ORDER BY lib.newer_versions_number DESC
{{< /code-block >}}
-### List services running an old version of the tracer
+### List services running an old version of the SDK
{{< code-block lang="sql" disable_copy="false">}}
SELECT *
diff --git a/content/en/error_tracking/backend/capturing_handled_errors/_index.md b/content/en/error_tracking/backend/capturing_handled_errors/_index.md
index 6b9e2f287b6..4847b83c9d8 100644
--- a/content/en/error_tracking/backend/capturing_handled_errors/_index.md
+++ b/content/en/error_tracking/backend/capturing_handled_errors/_index.md
@@ -18,7 +18,7 @@ further_reading:
## Overview
-Datadog tracing libraries 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 Error Tracking.
## Requirements
Supported languages
@@ -37,7 +37,7 @@ Capturing handled errors is only available in APM Error Tracking or Standalone B
## Setup
-Set up your application to capture handled errors using one of the following official Datadog tracing libraries:
+Set up your application to capture handled errors using one of the following official Datadog SDKs:
{{< partial name="error_tracking/error-tracking-handled-errors.html" >}}
diff --git a/content/en/error_tracking/backend/capturing_handled_errors/python.md b/content/en/error_tracking/backend/capturing_handled_errors/python.md index 785cc370afc..9ea42eda1ac 100644 --- a/content/en/error_tracking/backend/capturing_handled_errors/python.md +++ b/content/en/error_tracking/backend/capturing_handled_errors/python.md @@ -10,7 +10,7 @@ This feature is available on `Python3.10+` and `ddtrace 3.8.0+`. ## Getting started -Before you begin, make sure you've already [installed and configured the Agent][1]. You also need to [add the tracing library][2] directly in the application to instrument it. +Before you begin, make sure you've already [installed and configured the Agent][1]. You also need to [add the SDK][2] directly in the application to instrument it. ### Automatic instrumentation diff --git a/content/en/error_tracking/backend/capturing_handled_errors/ruby.md b/content/en/error_tracking/backend/capturing_handled_errors/ruby.md index fe9213dd4eb..2ad9c8bb03b 100644 --- a/content/en/error_tracking/backend/capturing_handled_errors/ruby.md +++ b/content/en/error_tracking/backend/capturing_handled_errors/ruby.md @@ -13,7 +13,7 @@ You must be running: ## Getting started -Before you begin, make sure you've already [installed and configured the Agent][1]. You also need to [add the tracing library][2] directly in the application to instrument it. +Before you begin, make sure you've already [installed and configured the Agent][1]. You also need to [add the SDK][2] directly in the application to instrument it. ### Automatic instrumentation diff --git a/content/en/error_tracking/backend/getting_started/_index.md b/content/en/error_tracking/backend/getting_started/_index.md index 821db2ff3e2..6e15a3a0064 100644 --- a/content/en/error_tracking/backend/getting_started/_index.md +++ b/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 Tracing Libraries. Whenever an error is collected, Error Tracking processes and groups it under an issue, or group of similar errors. +[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. ## Getting started with Backend Error Tracking diff --git a/content/en/error_tracking/backend/getting_started/dd_libraries.md b/content/en/error_tracking/backend/getting_started/dd_libraries.md index 65702a5af3d..63d6a332e5a 100644 --- a/content/en/error_tracking/backend/getting_started/dd_libraries.md +++ b/content/en/error_tracking/backend/getting_started/dd_libraries.md @@ -1,5 +1,5 @@ --- -title: Install Backend Error Tracking Using Datadog Tracing Libraries +title: Install Backend Error Tracking Using Datadog SDKs aliases: - /error_tracking/standalone_backend/getting_started/dd_libraries further_reading: @@ -20,7 +20,7 @@ further_reading: To instrument your application with Datadog libraries: 1. [Install and configure the Agent](#install-and-configure-the-agent). -2. [Add the Datadog tracing library to your code](#instrument-your-application). +2. [Add the Datadog SDK to your code](#instrument-your-application). ## Install and configure the Agent @@ -98,7 +98,7 @@ datadog: ## Instrument your application -Follow the relevant [documentation][4] to set up your application to send traces using one of the official Datadog tracing libraries. +Follow the relevant [documentation][4] to set up your application to send traces using one of the official Datadog SDKs. Follow the [OpenTelemetry API guide][5] for your application language to manually send errors through span events. ## Further Reading diff --git a/content/en/error_tracking/guides/enable_apm.md b/content/en/error_tracking/guides/enable_apm.md index 41a973a15bd..a05ea361d4e 100644 --- a/content/en/error_tracking/guides/enable_apm.md +++ b/content/en/error_tracking/guides/enable_apm.md @@ -40,7 +40,7 @@ For a Datadog agent installed using the one-line installation command: 3. [Restart the Agent][3]. {{< /collapse-content >}} -{{< collapse-content title="Using Datadog tracing libraries" level="h5" >}} +{{< collapse-content title="Using Datadog SDKs" level="h5" >}} For a Datadog agent configured manually for Backend Error Tracking: 1. Open the [datadog.yaml configuration file][2]. diff --git a/content/en/error_tracking/guides/enable_infra.md b/content/en/error_tracking/guides/enable_infra.md index 5765e20102f..d7250a4b414 100644 --- a/content/en/error_tracking/guides/enable_infra.md +++ b/content/en/error_tracking/guides/enable_infra.md @@ -38,7 +38,7 @@ For a Datadog agent installed using the one-line installation command: 3. [Restart the Agent][3]. {{< /collapse-content >}} -{{< collapse-content title="Using Datadog tracing libraries" level="h5" >}} +{{< collapse-content title="Using Datadog SDKs" level="h5" >}} For a Datadog agent configured manually for Backend Error Tracking: 1. Open the [datadog.yaml configuration file][2]. diff --git a/content/en/error_tracking/troubleshooting.md b/content/en/error_tracking/troubleshooting.md index 2cb84ffcdb9..5f42a30c33c 100644 --- a/content/en/error_tracking/troubleshooting.md +++ b/content/en/error_tracking/troubleshooting.md @@ -4,7 +4,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]. -Datadog recommends regularly updating to the latest version of the Datadog tracing libraries, mobile SDKs, and web SDKs, as each release contains improvements and fixes. +Datadog recommends regularly updating to the latest version of the Datadog SDKs, mobile SDKs, and web SDKs, as each release contains improvements and fixes. ## Errors are not found in Error Tracking diff --git a/content/en/extend/guide/data-collection-resolution.md b/content/en/extend/guide/data-collection-resolution.md index 171c3ed6729..8ead56ffe50 100644 --- a/content/en/extend/guide/data-collection-resolution.md +++ b/content/en/extend/guide/data-collection-resolution.md @@ -15,12 +15,12 @@ Find below a summary of Datadog data [collection][1] and [resolution][2]. See in | Product category | Source | Collection Methods | Collection interval | Minimum Resolution | |-------------------------------------|-----------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------|-----------------------------------| -| APM | Profiles | Datadog Agent + tracing library | 60 seconds | 60 seconds | -| APM | Profile metrics | Datadog Agent + tracing library | 60 seconds | 60 seconds | -| APM | Services/resources statistics and span summaries | Datadog Agent + tracing library | 10 seconds | 10 seconds | -| APM | Indexed spans | Datadog Agent + tracing library | 10 seconds | 1 millisecond | -| APM | Trace metrics (unsampled) | Datadog Agent + tracing library | 10 seconds | 1 second | -| ASM | Suspicious requests | Datadog Agent + tracing library | 10 seconds | 1 millisecond | +| APM | Profiles | Datadog Agent + SDK | 60 seconds | 60 seconds | +| APM | Profile metrics | Datadog Agent + SDK | 60 seconds | 60 seconds | +| APM | Services/resources statistics and span summaries | Datadog Agent + SDK | 10 seconds | 10 seconds | +| APM | Indexed spans | Datadog Agent + SDK | 10 seconds | 1 millisecond | +| APM | Trace metrics (unsampled) | Datadog Agent + SDK | 10 seconds | 1 second | +| ASM | Suspicious requests | Datadog Agent + SDK | 10 seconds | 1 millisecond | | Audit Trail | Datadog audit events | Datadog usage activity | n/a | 1 second | | CI Visibility | Pipeline, Stage, Job, Step, Command span | Webhooks, Datadog Agent + plugin | Data source-dependent | 1 millisecond | | CD Visibility | Deployment execution | Webhooks, Datadog Agent + plugin | Data source-dependent | 1 millisecond | @@ -65,7 +65,7 @@ Find below a summary of Datadog data [collection][1] and [resolution][2]. See in | Synthetic Monitoring | Browser Test results | Datadog Synthetic Monitoring application | User-defined | 5 minutes | | Synthetic Monitoring | Batches | Datadog Synthetic Monitoring application (through calls to the [Synthetics trigger API endpoint][6] or to the [Synthetics CI CLI][7]) | Depending on calls to the [Synthetics trigger API endpoint][6] or to the [Synthetics CI CLI][7] | n/a | | Test Optimization | Flaky test | Test Optimization Test spans | Data source-dependent | 1 millisecond | -| Test Optimization | Test span | Datadog Agent + tracing library | 60 seconds | 1 millisecond | +| Test Optimization | Test span | Datadog Agent + SDK | 60 seconds | 1 millisecond | | USM | RED metrics | Datadog Agent | 30 seconds | 30 second | ## Further reading diff --git a/content/en/extend/guide/unified-tagging-advanced-usage.md b/content/en/extend/guide/unified-tagging-advanced-usage.md index 1fceabe0e26..6ce765074fe 100644 --- a/content/en/extend/guide/unified-tagging-advanced-usage.md +++ b/content/en/extend/guide/unified-tagging-advanced-usage.md @@ -64,7 +64,7 @@ tags.datadoghq.com/
Java Feature Flags support is experimental and requires enabling an experimental flag in the tracer. See the Configuration section for details.
+Java Feature Flags support is experimental and requires enabling an experimental flag in the SDK. See the Configuration section for details.
## Overview
This page describes how to instrument a Java application with the Datadog Feature Flags SDK. Datadog feature flags provide a unified way to remotely control feature availability in your app, experiment safely, and deliver new experiences with confidence.
-The Java SDK integrates feature flags directly into the Datadog APM tracer and implements the [OpenFeature](https://openfeature.dev/) standard for maximum flexibility and compatibility.
+The Java SDK integrates feature flags directly into the Datadog SDK and implements the [OpenFeature](https://openfeature.dev/) standard for maximum flexibility and compatibility.
-If you're using Datadog APM and your application already has the Datadog Java tracer and Remote Configuration enabled, skip to Initialize the OpenFeature provider. You only need to add the OpenFeature dependencies and initialize the provider.
+If you're using Datadog APM and your application already has the Datadog Java SDK and Remote Configuration enabled, skip to Initialize the OpenFeature provider. You only need to add the OpenFeature dependencies and initialize the provider.
## Compatibility requirements
The Datadog Feature Flags SDK for Java requires:
- **Java 11 or higher**
-- **Datadog Java APM Tracer**: Version **1.57.0** or later
+- **Datadog Java SDK**: Version **1.57.0** or later
- **OpenFeature SDK**: Version **1.18.2** or later
- **Datadog Agent**: Version **7.x or later** with [Remote Configuration][1] enabled
- **Datadog API Key**: Required for Remote Configuration
@@ -37,7 +37,7 @@ Before you begin, make sure you've already [installed and configured the Agent](
## Installation
-Feature flagging is integrated into the Datadog Java APM tracer. You need the tracer JAR and the OpenFeature SDK dependencies.
+Feature flagging is integrated into the Datadog Java Datadog SDK. You need the SDK JAR and the OpenFeature SDK dependencies.
{{< tabs >}}
{{% tab "Gradle (Groovy)" %}}
@@ -110,14 +110,14 @@ api_key: Feature flagging requires both
### Add the Java tracer to the JVM
-For instructions on how to add the `-javaagent` argument to your application server or framework, see [Add the Java Tracer to the JVM](/tracing/trace_collection/automatic_instrumentation/dd_libraries/java/#add-the-java-tracer-to-the-jvm).
+For instructions on how to add the `-javaagent` argument to your application server or framework, see [Add the Java SDK to the JVM](/tracing/trace_collection/automatic_instrumentation/dd_libraries/java/#add-the-java-sdk-to-the-jvm).
Make sure to include the feature flagging configuration flags:
- `-Ddd.remote.config.enabled=true`
@@ -168,7 +168,7 @@ Make sure to include the feature flagging configuration flags:
## Initialize the OpenFeature provider
-Initialize the Datadog OpenFeature provider in your application startup code. The provider connects to the feature flagging system running in the Datadog tracer.
+Initialize the Datadog OpenFeature provider in your application startup code. The provider connects to the feature flagging system running in the Datadog SDK.
{{< code-block lang="java" >}}
import dev.openfeature.sdk.OpenFeatureAPI;
diff --git a/content/en/feature_flags/server/nodejs.md b/content/en/feature_flags/server/nodejs.md
index d1af9f8fc1b..da1e2ef542e 100644
--- a/content/en/feature_flags/server/nodejs.md
+++ b/content/en/feature_flags/server/nodejs.md
@@ -15,14 +15,14 @@ further_reading:
## Overview
-This page describes how to instrument your Node.js application with the Datadog Feature Flags SDK. The Node.js SDK integrates with [OpenFeature][2], an open standard for feature flag management, and uses the Datadog tracer's Remote Configuration to receive flag updates in real time.
+This page describes how to instrument your Node.js application with the Datadog Feature Flags SDK. The Node.js SDK integrates with [OpenFeature][2], an open standard for feature flag management, and uses the Datadog SDK's Remote Configuration to receive flag updates in real time.
## Prerequisites
Before setting up the Node.js Feature Flags SDK, ensure you have:
- **Datadog Agent** with [Remote Configuration](/agent/remote_config/) enabled. See [Agent Configuration](/feature_flags/server#agent-configuration) for details.
-- **Datadog Node.js tracer** `dd-trace` version 5.80.0 or later
+- **Datadog Node.js SDK** `dd-trace` version 5.80.0 or later
- **@openfeature/server-sdk** version ~1.20.0
## Installing and initializing
diff --git a/content/en/feature_flags/server/python.md b/content/en/feature_flags/server/python.md
index 86d1245cf2d..daf41223d88 100644
--- a/content/en/feature_flags/server/python.md
+++ b/content/en/feature_flags/server/python.md
@@ -12,7 +12,7 @@ further_reading:
## Overview
-This page describes how to instrument your Python application with the Datadog Feature Flags SDK. The Python SDK integrates with [OpenFeature][1], an open standard for feature flag management, and uses the Datadog tracer's Remote Configuration to receive flag updates in real time.
+This page describes how to instrument your Python application with the Datadog Feature Flags SDK. The Python SDK integrates with [OpenFeature][1], an open standard for feature flag management, and uses the Datadog SDK's Remote Configuration to receive flag updates in real time.
This guide explains how to install and enable the SDK, create an OpenFeature client, and evaluate feature flags in your application.
@@ -21,7 +21,7 @@ This guide explains how to install and enable the SDK, create an OpenFeature cli
Before setting up the Python Feature Flags SDK, ensure you have:
- **Datadog Agent** with [Remote Configuration][2] enabled
-- **Datadog Python tracer** `ddtrace` version 3.19.0 or later
+- **Datadog Python SDK** `ddtrace` version 3.19.0 or later
- **OpenFeature Python SDK** `openfeature-sdk` version 0.5.0 or later
Set the following environment variables:
@@ -37,7 +37,7 @@ export DD_ENV=DD_REMOTE_CONFIG_ENABLED=true and DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED=true. Without the experimental flag, the feature flagging system does not start and the Provider returns the programmatic default.Starting v2.14.0, you don't need to set
+ CORECLR_PROFILER or COR_PROFILER if you installed the tracer using the MSI.Starting v2.14.0, you don't need to set
**With the Registry Editor:**
@@ -297,9 +297,9 @@ To install the .NET Profiler per-webapp:
{{% /tab %}}
{{% tab "Windows services" %}}
-3. Set needed environment variables to configure and enable Profiler. To enable the Profiler for your service, it is required to set the `DD_PROFILING_ENABLED` environment variable in the Registry key associated to the service. If the profiler is running alone (the tracer is deactivated), you can optionally add the `DD_SERVICE`, `DD_ENV` and `DD_VERSION` environment variables.
+3. Set needed environment variables to configure and enable Profiler. To enable the Profiler for your service, it is required to set the `DD_PROFILING_ENABLED` environment variable in the Registry key associated to the service. If the profiler is running alone (the SDK is deactivated), you can optionally add the `DD_SERVICE`, `DD_ENV` and `DD_VERSION` environment variables.
- CORECLR_PROFILER or COR_PROFILER if you installed the SDK using the MSI.Starting v2.14.0, you don't need to set
+ CORECLR_PROFILER or COR_PROFILER if you installed the tracer using the MSI.Starting v2.14.0, you don't need to set
**With the Registry Editor:**
@@ -370,9 +370,9 @@ To install the .NET Profiler per-webapp:
{{% tab "Windows Standalone applications" %}}
- CORECLR_PROFILER or COR_PROFILER if you installed the SDK using the MSI.Starting v2.14.0, you don't need to set
+ CORECLR_PROFILER or COR_PROFILER if you installed the tracer using the MSI.Starting v2.14.0, you don't need to set
-3. Set needed environment variables to configure and enable Profiler for a non-service application, such as console, ASP.NET (Core), Windows Forms, or WPF. To enable the Profiler for Standalone applications, it is required to set the `DD_PROFILING_ENABLED` environment variable. If the profiler is running alone (the tracer is deactivated), you can optionally set the `DD_SERVICE`, `DD_ENV` and `DD_VERSION` environment variables. The recommended approach is to create a batch file that sets these and starts the application, and run your application using the batch file.
+3. Set needed environment variables to configure and enable Profiler for a non-service application, such as console, ASP.NET (Core), Windows Forms, or WPF. To enable the Profiler for Standalone applications, it is required to set the `DD_PROFILING_ENABLED` environment variable. If the profiler is running alone (the SDK is deactivated), you can optionally set the `DD_SERVICE`, `DD_ENV` and `DD_VERSION` environment variables. The recommended approach is to create a batch file that sets these and starts the application, and run your application using the batch file.
For .NET Core and .NET 5+:
```cmd
diff --git a/content/en/profiler/enabling/full_host.md b/content/en/profiler/enabling/full_host.md
index 89edaf06855..cf0a7300bd2 100644
--- a/content/en/profiler/enabling/full_host.md
+++ b/content/en/profiler/enabling/full_host.md
@@ -17,7 +17,7 @@ The Full-Host Profiler is an eBPF-based profiling solution built on OpenTelemetr
The Full-Host Profiler is particularly valuable for:
-- Profiling open source software components that aren't instrumented with Datadog's tracing libraries.
+- Profiling open source software components that aren't instrumented with Datadog SDKs.
- Analyzing performance across multi-language processes and runtimes.
## Requirements
diff --git a/content/en/profiler/enabling/go.md b/content/en/profiler/enabling/go.md
index ed0800e91c1..b95308e07c5 100644
--- a/content/en/profiler/enabling/go.md
+++ b/content/en/profiler/enabling/go.md
@@ -17,7 +17,7 @@ aliases:
- /tracing/profiler/enabling/go/
---
-The profiler is shipped within Datadog tracing libraries. If you are already using [APM to collect traces][1] for your application, you can skip installing the library and go directly to enabling the profiler.
+The profiler is shipped within Datadog SDKs. If you are already using [APM to collect traces][1] for your application, you can skip installing the library and go directly to enabling the profiler.
## Requirements
diff --git a/content/en/profiler/enabling/graalvm.md b/content/en/profiler/enabling/graalvm.md
index 7065b044355..3eb88804aed 100644
--- a/content/en/profiler/enabling/graalvm.md
+++ b/content/en/profiler/enabling/graalvm.md
@@ -36,7 +36,7 @@ Available profile types
## Installation
-### 1. Build your native image with the Datadog tracer
+### 1. Build your native image with the Datadog SDK
Follow the [Tracer Setup Instructions][3] to build your GraalVM native image with the Datadog Java Profiler instrumentation.
diff --git a/content/en/profiler/enabling/java.md b/content/en/profiler/enabling/java.md
index 857ec6e1edd..b71d32bccc2 100644
--- a/content/en/profiler/enabling/java.md
+++ b/content/en/profiler/enabling/java.md
@@ -17,7 +17,7 @@ aliases:
- /tracing/profiler/enabling/java/
---
-The profiler is shipped within Datadog tracing libraries. If you are already using [APM to collect traces][1] for your application, you can skip installing the library and go directly to enabling the profiler.
+The profiler is shipped within Datadog SDKs. If you are already using [APM to collect traces][1] for your application, you can skip installing the library and go directly to enabling the profiler.
## Requirements
diff --git a/content/en/profiler/enabling/nodejs.md b/content/en/profiler/enabling/nodejs.md
index 9c19d5194d6..1f04cf848a6 100644
--- a/content/en/profiler/enabling/nodejs.md
+++ b/content/en/profiler/enabling/nodejs.md
@@ -17,7 +17,7 @@ aliases:
- /tracing/profiler/enabling/nodejs/
---
-The profiler is shipped within Datadog tracing libraries. If you are already using [APM to collect traces][1] for your application, you can skip installing the library and go directly to enabling the profiler.
+The profiler is shipped within Datadog SDKs. If you are already using [APM to collect traces][1] for your application, you can skip installing the library and go directly to enabling the profiler.
## Requirements
@@ -49,7 +49,7 @@ export DD_SERVICE=my-web-app
export DD_VERSION=1.0.3
```
-**Note**: If you're already using Datadog APM, you are already calling `init` and don't need to do so again. If you are not, ensure the tracer and the profiler are loaded together:
+**Note**: If you're already using Datadog APM, you are already calling `init` and don't need to do so again. If you are not, ensure the SDK and the profiler are loaded together:
```node
node -r dd-trace/init app.js
@@ -67,7 +67,7 @@ const tracer = require('dd-trace').init({
})
```
-**Note**: If you're already using Datadog APM, you are already calling `init` and don't need to do so again. If you are not, ensure the tracer and the profiler are loaded together:
+**Note**: If you're already using Datadog APM, you are already calling `init` and don't need to do so again. If you are not, ensure the SDK and the profiler are loaded together:
```node
const tracer = require('dd-trace/init')
diff --git a/content/en/profiler/enabling/php.md b/content/en/profiler/enabling/php.md
index 47df489ad9c..89cbe788058 100644
--- a/content/en/profiler/enabling/php.md
+++ b/content/en/profiler/enabling/php.md
@@ -76,7 +76,7 @@ To begin profiling applications:
https://github.com/DataDog/dd-trace-php/releases/latest/download/datadog-setup.php
```
-3. Run the installer to install both the tracer and profiler. This script is interactive and asks which of the detected PHP locations it should install to. At the end of the script, it outputs the non-interactive version of the command arguments for future use.
+3. Run the installer to install both the SDK and profiler. This script is interactive and asks which of the detected PHP locations it should install to. At the end of the script, it outputs the non-interactive version of the command arguments for future use.
```shell
php datadog-setup.php --enable-profiling --php-bin=all
diff --git a/content/en/profiler/enabling/python.md b/content/en/profiler/enabling/python.md
index f9a19f8509d..f2e370f3bd8 100644
--- a/content/en/profiler/enabling/python.md
+++ b/content/en/profiler/enabling/python.md
@@ -17,14 +17,14 @@ aliases:
- /tracing/profiler/enabling/python/
---
-The profiler is shipped within Datadog tracing libraries. If you are already using [APM to collect traces][1] for your application, you can skip installing the library and go directly to enabling the profiler.
+The profiler is shipped within Datadog SDKs. If you are already using [APM to collect traces][1] for your application, you can skip installing the library and go directly to enabling the profiler.
## Requirements
To use profiling, ensure the following requirements are met:
-- Enable profiling through the Datadog tracing library. Using the latest stable release is recommended.
-- Verify your Python and tracing library versions are compatible by reviewing the [Python Compatibility Requirements][17].
-**Note**: Some features depend on newer Python versions than the minimum required version for the tracing library. For more details, read [Profile Types][8].
+- Enable profiling through the Datadog SDK. Using the latest stable release is recommended.
+- Verify your Python and SDK versions are compatible by reviewing the [Python Compatibility Requirements][17].
+**Note**: Some features depend on newer Python versions than the minimum required version for the SDK. For more details, read [Profile Types][8].
For a summary of the minimum and recommended runtime and tracer versions across all languages, read [Supported Language and Tracer Versions][14].
diff --git a/content/en/profiler/enabling/ruby.md b/content/en/profiler/enabling/ruby.md
index 06fc69c43fa..3cfec542b98 100644
--- a/content/en/profiler/enabling/ruby.md
+++ b/content/en/profiler/enabling/ruby.md
@@ -20,7 +20,7 @@ aliases:
- /tracing/profiler/enabling/ruby/
---
-The profiler is shipped within Datadog tracing libraries. If you are already using [APM to collect traces][1] for your application, you can skip installing the library and go directly to enabling the profiler.
+The profiler is shipped within Datadog SDKs. If you are already using [APM to collect traces][1] for your application, you can skip installing the library and go directly to enabling the profiler.
## Requirements
diff --git a/content/en/profiler/enabling/ssi.md b/content/en/profiler/enabling/ssi.md
index 24c3113d46c..d6034f17842 100644
--- a/content/en/profiler/enabling/ssi.md
+++ b/content/en/profiler/enabling/ssi.md
@@ -19,7 +19,7 @@ version of Continuous Profiler with SSI works for host, container, and Kubernete
Continuous Profiler with SSI can be enabled for the following languages:
-| Language | Tracer library version |
+| Language | SDK version |
|--------------------|------------------------|
| Java | 1.37.0+ |
| .NET (x86_64 only) | 3.3.1+ |
@@ -37,7 +37,7 @@ Continuous Profiler can be enabled as part of the SSI setup by following these s
{{% tab "Host and container" %}}
1. Go to the [Agent Installation Page][2] and select one of Linux platforms or Docker.
-1. Toggle the "Enable APM Instrumentation" switch. (If there is no switch, the platform is not supported by SSI.) Toggling the switch adds the `DD_APM_INSTRUMENTATION_ENABLED=` environment variable to the installation command, configuring the installed agent to inject the tracer library into processes.
+1. Toggle the "Enable APM Instrumentation" switch. (If there is no switch, the platform is not supported by SSI.) Toggling the switch adds the `DD_APM_INSTRUMENTATION_ENABLED=` environment variable to the installation command, configuring the installed agent to inject the SDK into processes.
1. Copy the installation command into a text editor.
1. Add `DD_PROFILING_ENABLED=auto` as an additional environment variable after `DD_APM_INSTRUMENTATION_ENABLED` in the copied command. This turns on automatic profiler enablement for any new process worth profiling.
1. Proceed with the rest of the installation instructions, using the modified installation command.
diff --git a/content/en/profiler/enabling/supported_versions.md b/content/en/profiler/enabling/supported_versions.md
index c154d62593a..0d106dbfcc5 100644
--- a/content/en/profiler/enabling/supported_versions.md
+++ b/content/en/profiler/enabling/supported_versions.md
@@ -9,11 +9,11 @@ further_reading:
The following tables summarize the features available for each language runtime.
- **Minimum versions** are required to access at least one feature. If you have an earlier version, profiling is not available.
-- **Feature-complete versions** give you access to **all** supported features. It's usually best if you update to the latest version of all tracing libraries.
+- **Feature-complete versions** give you access to **all** supported features. It's usually best if you update to the latest version of all SDKs.
CORECLR_PROFILER or COR_PROFILER if you installed the SDK using the MSI.For more details, click the language heading in any table to go that language's setup page.
-## Runtime and tracing library versions
+## Runtime and SDK versions
To use the Datadog Profiler, use at least the minimum versions summarized in the following table. For specific profile type availability by version, see [Profile types](#profile-types).
@@ -21,11 +21,11 @@ To use the Datadog Profiler, use at least the minimum versions summarized in the
|-----------------------------------|:------------:|:----------------:|:-------------:|:--------------:|:-------------:|:-----------------------------------------------------------------------:|:-------------:|:---------------:|
| Minimum runtime version | [JDK 8+][17] | Python 2.7+ | [previous major Go release][21] | Ruby 2.5+ | Node.js 18+ | .NET Core 2.1+, .NET 5+, .NET Framework 4.6.1+ | PHP 7.1+ | |
| Feature-complete runtime version | [JDK 11+][17] | Python 3.6+ | [latest major Go release][21] | Ruby 3.2+ | Node.js 18+ | .NET 7+ | PHP 8.0+ | |
-| Feature-complete tracing library version | [latest][9] | [latest][10] | [latest][11] | [latest][12] | [latest][13] | [latest][14] | [latest][15] | [latest][16] |
+| Feature-complete SDK version | [latest][9] | [latest][10] | [latest][11] | [latest][12] | [latest][13] | [latest][14] | [latest][15] | [latest][16] |
## Profile types
-The following table shows profile type availability by language. For optimal performance and access to all features, Datadog recommends using the latest version of the tracing library for your language. If a specific runtime version isn't indicated, the profile type is available with the minimum runtime version listed in the [Runtime and tracing library versions](#runtime-and-tracing-library-versions).
+The following table shows profile type availability by language. For optimal performance and access to all features, Datadog recommends using the latest version of the SDK for your language. If a specific runtime version isn't indicated, the profile type is available with the minimum runtime version listed in the [Runtime and SDK versions](#runtime-and-sdk-versions).
| | [Java][1] | [Python][2] | [Go][3] | [Ruby][4] | [Node.js][5] | [.NET][6] | [PHP][7] | [Rust/C/C++][8] |
@@ -40,7 +40,7 @@ The following table shows profile type availability by language. For optimal per
## Other features
-The following table outlines additional profiling features by language. For full functionality and best performance, Datadog recommends using the latest version of your language's tracing library. If a specific runtime version isn't indicated, the feature is available with the minimum runtime version listed in the [Runtime and tracing library versions](#runtime-and-tracing-library-versions).
+The following table outlines additional profiling features by language. For full functionality and best performance, Datadog recommends using the latest version of your language's SDK. If a specific runtime version isn't indicated, the feature is available with the minimum runtime version listed in the [Runtime and SDK versions](#runtime-and-sdk-versions).
| | [Java][1] | [Python][2] | [Go][3] | [Ruby][4] | [Node.js][5] | [.NET][6] | [PHP][7] | [Rust/C/C++][8] |
|-----------------------------------|:-------:|:-------:|:------------:|:------:|:---------:|:-------:|:------:|:----------:|
diff --git a/content/en/profiler/profiler_troubleshooting/java.md b/content/en/profiler/profiler_troubleshooting/java.md
index 026969aa90b..96fde88c0ef 100644
--- a/content/en/profiler/profiler_troubleshooting/java.md
+++ b/content/en/profiler/profiler_troubleshooting/java.md
@@ -303,7 +303,7 @@ java -javaagent:dd-java-agent.jar -Ddd.profiling.enabled=true -Ddd.profiling.ddp
The Datadog exception profiler has a small footprint and overhead under normal conditions. If a lot of exceptions are created and thrown, it can cause significant overhead for the profiler. This can happen when you use exceptions for control flow. If you have an unusually high exception rate, turn off exception profiling temporarily until you fix the cause.
-To disable exception profiling, start the tracer with the `-Ddd.integration.throwables.enabled=false` JVM setting.
+To disable exception profiling, start the SDK with the `-Ddd.integration.throwables.enabled=false` JVM setting.
Note: Turn this setting back on after you've returned to a more typical rate of exceptions.
diff --git a/content/en/profiler/profiler_troubleshooting/nodejs.md b/content/en/profiler/profiler_troubleshooting/nodejs.md
index 9dca0c80a48..d15ba3d454d 100644
--- a/content/en/profiler/profiler_troubleshooting/nodejs.md
+++ b/content/en/profiler/profiler_troubleshooting/nodejs.md
@@ -24,7 +24,7 @@ The profiler might fail to find its native component. In this situation, your ap
Error: No native build was found for runtime=node abi=109 platform=linuxglibc arch=x64
```
-If you are using a bundler such as esbuild or webpack, which is used by frameworks such as Next.js, see [Bundling with the Node.js tracer][3]. The Datadog tracer and profiler have special requirements when used with bundlers.
+If you are using a bundler such as esbuild or webpack, which is used by frameworks such as Next.js, see [Bundling with the Node.js tracer][3]. The Datadog SDK and profiler have special requirements when used with bundlers.
Node versions available through package managers may sometimes incorrectly report their ABI (Application Binary Interface) version. For example, Ubuntu Linux 24.04.01 LTS includes a Node 18 package that incorrectly reports its ABI version as 109, instead of the correct version, 108, for Node 18.
diff --git a/content/en/real_user_monitoring/application_monitoring/android/advanced_configuration.md b/content/en/real_user_monitoring/application_monitoring/android/advanced_configuration.md
index c35a35573df..6fa05c1409b 100644
--- a/content/en/real_user_monitoring/application_monitoring/android/advanced_configuration.md
+++ b/content/en/real_user_monitoring/application_monitoring/android/advanced_configuration.md
@@ -271,7 +271,7 @@ Widgets are not automatically tracked with the SDK. To send UI interactions from
You can use the following methods in `Configuration.Builder` when creating the Datadog configuration to initialize the library:
`setFirstPartyHosts()`
-: Defines hosts that have tracing enabled and have RUM resources categorized as `first-party`. **Note**: If you define custom tracing header types in the Datadog configuration and are using a tracer registered with `GlobalTracer`, make sure the same tracing header types are set for the tracer in use.
+: Defines hosts that have tracing enabled and have RUM resources categorized as `first-party`. **Note**: If you define custom tracing header types in the Datadog configuration and are using an SDK registered with `GlobalTracer`, make sure the same tracing header types are set for the SDK in use.
`useSite(DatadogSite)`
: Switches target data to EU1, US1, US3, US5, US1_FED, AP1 and AP2 sites.
diff --git a/content/en/real_user_monitoring/application_monitoring/browser/setup/server/java.md b/content/en/real_user_monitoring/application_monitoring/browser/setup/server/java.md
index 2c678e14656..fdeb3e759de 100644
--- a/content/en/real_user_monitoring/application_monitoring/browser/setup/server/java.md
+++ b/content/en/real_user_monitoring/application_monitoring/browser/setup/server/java.md
@@ -85,7 +85,7 @@ Use manual configuration if you prefer to set up RUM Browser monitoring independ
### Enable RUM instrumentation on the Java SDK
-RUM Instrumentation for Java web application servers can be configured using the usual Java SDK configuration methods. For more information, see [Configuring the Java SDK Library][4].
+RUM Instrumentation for Java web application servers can be configured using the usual Java SDK configuration methods. For more information, see [Configuring the Java SDK][4].
RUM SDK injection is disabled by default. Enable it by exporting the following environment variables:
diff --git a/content/en/real_user_monitoring/correlate_with_other_telemetry/apm/_index.md b/content/en/real_user_monitoring/correlate_with_other_telemetry/apm/_index.md
index 136b1ecb8f3..1d3a513ece0 100644
--- a/content/en/real_user_monitoring/correlate_with_other_telemetry/apm/_index.md
+++ b/content/en/real_user_monitoring/correlate_with_other_telemetry/apm/_index.md
@@ -143,7 +143,7 @@ To start sending just your iOS application's traces to Datadog, see [iOS Trace C
{{< img src="real_user_monitoring/connect_rum_and_traces/traceContextInjection_all-2.png" alt="traceContextInjection set to all" style="width:90%;">}}
- - When `traceContextInjection` is set to `sampled`, **20%** of backend traces are kept. For the remaining **80%**, the browser SDK **does not inject** a sampling decision. The decision is made on the server side and is based on the tracing library head-based sampling [configuration][2]. In the example below, the backend sample rate is set to 40%, and therefore 32% of the remaining backend traces are kept.
+ - When `traceContextInjection` is set to `sampled`, **20%** of backend traces are kept. For the remaining **80%**, the browser SDK **does not inject** a sampling decision. The decision is made on the server side and is based on the SDK head-based sampling [configuration][2]. In the example below, the backend sample rate is set to 40%, and therefore 32% of the remaining backend traces are kept.
{{< img src="real_user_monitoring/connect_rum_and_traces/traceContextInjection_sampled-3.png" alt="traceContextInjection set to sampled" style="width:90%;">}}
@@ -193,7 +193,7 @@ To start sending just your iOS application's traces to Datadog, see [iOS Trace C
**Note**:
* `traceSampler` **does not** impact RUM sessions sampling. Only backend traces are sampled out.
-* If you define custom tracing header types in the Datadog configuration and are using a tracer registered with `GlobalTracer`, make sure the same tracing header types are set for the tracer in use.
+* If you define custom tracing header types in the Datadog configuration and are using an SDK registered with `GlobalTracer`, make sure the same tracing header types are set for the SDK in use.
[1]: /real_user_monitoring/android/
[2]: /tracing/trace_collection/dd_libraries/android/?tab=kotlin
diff --git a/content/en/real_user_monitoring/guide/best-practices-tracing-native-ios-android-apps.md b/content/en/real_user_monitoring/guide/best-practices-tracing-native-ios-android-apps.md
index 9fce3052852..47f144550de 100644
--- a/content/en/real_user_monitoring/guide/best-practices-tracing-native-ios-android-apps.md
+++ b/content/en/real_user_monitoring/guide/best-practices-tracing-native-ios-android-apps.md
@@ -149,7 +149,7 @@ The following sampling rate parameters control different aspects of data collect
| Parameter | Description | Example |
|--------------------------------------------------------|---------------------------------------------------------------------------------|--------------------------|
-| `Trace.Configuration.sampleRate` | Controls the percentage of manually instrumented spans collected by the tracer. | `50` = 50% of spans |
+| `Trace.Configuration.sampleRate` | Controls the percentage of manually instrumented spans collected by the SDK. | `50` = 50% of spans |
| `urlSessionTracking.firstPartyHostsTracing.sampleRate` | Controls the percentage of network requests traced for first-party hosts. | `100` = 100% of requests |
**Note**: `RUM.sessionSampleRate` controls RUM session sampling and does not affect trace sampling rates. When using the Trace SDK independently of RUM, trace sampling is controlled only by the parameters listed above.
@@ -159,8 +159,8 @@ The following sampling rate parameters control different aspects of data collect
| Parameter | Description | Example |
|----------------------------------------------|---------------------------------------------------------------------------------------------------------------------------|--------------------------|
-| `OtelTracerProvider.Builder.setSampleRate()` | OpenTelemetry approach (**recommended**). Controls the percentage of manually instrumented spans collected by the tracer. | `50` = 50% of spans |
-| `DatadogTracerBuilder.withSampleRate` | Datadog API approach. Controls the percentage of manually instrumented spans collected by the tracer. | `50` = 50% of spans |
+| `OtelTracerProvider.Builder.setSampleRate()` | OpenTelemetry approach (**recommended**). Controls the percentage of manually instrumented spans collected by the SDK. | `50` = 50% of spans |
+| `DatadogTracerBuilder.withSampleRate` | Datadog API approach. Controls the percentage of manually instrumented spans collected by the SDK. | `50` = 50% of spans |
| `DatadogInterceptor.Builder.setTraceSampler` | Controls the percentage of network requests traced for first-party hosts. | `100` = 100% of requests |
**Note**: `RUM.sessionSampleRate` controls RUM session sampling and does not affect trace sampling rates. When using the Trace SDK independently of RUM, trace sampling is controlled only by the parameters listed above.
diff --git a/content/en/real_user_monitoring/guide/mobile-sdk-upgrade.md b/content/en/real_user_monitoring/guide/mobile-sdk-upgrade.md
index 177e946253f..c9e88c931a0 100644
--- a/content/en/real_user_monitoring/guide/mobile-sdk-upgrade.md
+++ b/content/en/real_user_monitoring/guide/mobile-sdk-upgrade.md
@@ -260,7 +260,7 @@ GlobalOpenTelemetry.set(
)
```
-To access the tracer object for manual (custom) tracing, use `io.opentelemetry.api.GlobalOpenTelemetry.get()` instead of `io.opentracing.util.GlobalTracer.get()`.
+To access the SDK object for manual (custom) tracing, use `io.opentelemetry.api.GlobalOpenTelemetry.get()` instead of `io.opentracing.util.GlobalTracer.get()`.
For example:
```kotlin
val tracer: Tracer = GlobalOpenTelemetry
@@ -298,7 +298,7 @@ GlobalDatadogTracer.registerIfAbsent(
)
```
-For manual (custom) tracing use `com.datadog.android.trace.GlobalDatadogTracer.get()` instead of `io.opentracing.util.GlobalTracer.get()` to access the tracer object.
+For manual (custom) tracing use `com.datadog.android.trace.GlobalDatadogTracer.get()` instead of `io.opentracing.util.GlobalTracer.get()` to access the SDK object.
For example:
```kotlin
val tracer = GlobalDatadogTracer.get()
@@ -1053,7 +1053,7 @@ To dynamically adjust sampling, provide your own implementation of the `com.data
### `dd-sdk-android-ktx` module removal
-To improve granularity for the Datadog SDK libraries used, the `dd-sdk-android-ktx` module is removed. The code is distributed between the other modules to provide extension methods for both RUM and Trace features.
+To improve granularity for the Datadog SDKs used, the `dd-sdk-android-ktx` module is removed. The code is distributed between the other modules to provide extension methods for both RUM and Trace features.
| `1.x` | '2.0' | Module name |
|-------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------|-----------------------------------|
diff --git a/content/en/real_user_monitoring/rum_without_limits/_index.md b/content/en/real_user_monitoring/rum_without_limits/_index.md
index 1ef3472292e..6d88e30eb2b 100644
--- a/content/en/real_user_monitoring/rum_without_limits/_index.md
+++ b/content/en/real_user_monitoring/rum_without_limits/_index.md
@@ -43,7 +43,7 @@ To get started with RUM without Limits for new applications, at the [instrumenta
3. For applications with the [APM integration enabled][3], configure the percentage of sessions for which you want to make sure APM backend traces are ingested with `traceSampleRate` (browser), `traceSampler` (Android), or `sampleRate` (iOS).
-4. Enable `traceContextInjection: sampled` to allow backend tracing libraries to make their own sampling decisions for sessions where the RUM SDK decides not to keep the trace.
+4. Enable `traceContextInjection: sampled` to allow backend SDKs to make their own sampling decisions for sessions where the RUM SDK decides not to keep the trace.
## Compatibility
@@ -47,11 +47,11 @@ Datadog App and API Protection uses processes already contained in the Agent and
When APM is enabled, the Datadog library generates distributed traces. Datadog App and API Protection flags security activity in traces by using known attack patterns. Correlation between the attack patterns and the execution context provided by the distributed trace triggers security signals based on detection rules.
-{{< img src="security/application_security/How_Appsec_Works_June2023.png" alt="A diagram illustrates that the Datadog tracer library operates at the application service level and sends traces to the Datadog backend. The Datadog backend flags actionable security signals and sends a notification to the relevant application, such as PagerDuty, Jira or Slack." >}}
+{{< img src="security/application_security/How_Appsec_Works_June2023.png" alt="A diagram illustrates that the Datadog SDK operates at the application service level and sends traces to the Datadog backend. The Datadog backend flags actionable security signals and sends a notification to the relevant application, such as PagerDuty, Jira or Slack." >}}
## Data sampling and retention
-In the tracing library, Datadog App and API Protection collects all traces that include security data. A default [retention filter][9] ensures the retention of all security-related traces in the Datadog platform.
+In the SDK, Datadog App and API Protection collects all traces that include security data. A default [retention filter][9] ensures the retention of all security-related traces in the Datadog platform.
Data for security traces is kept for 90 days. The underlying trace data is kept for 15 days.
@@ -77,7 +77,7 @@ To configure the information redacted by App and API Protection, refer to the [d
Datadog uses multiple pattern sources, including the [OWASP ModSecurity Core Rule Set][12] to detect known threats and vulnerabilities in HTTP requests. When an HTTP request matches one of [the OOTB detection rules][13], a security signal is generated in Datadog.
-**Automatic Threat Patterns Updates:** If your service is running with [an Agent with Remote Configuration enabled and a tracing library version that supports it][26] , the threat patterns being used to monitor your service are automatically updated whenever Datadog publishes updates.
+**Automatic Threat Patterns Updates:** If your service is running with [an Agent with Remote Configuration enabled and an SDK version that supports it][26] , the threat patterns being used to monitor your service are automatically updated whenever Datadog publishes updates.
Security Signals are automatically created when Datadog detects meaningful attacks targeting your production services. It provides you with visibility on the attackers and the targeted services. You can set custom detection rules with thresholds to determine which attacks you want to be notified about.
diff --git a/content/en/security/application_security/how-it-works/add-user-info.md b/content/en/security/application_security/how-it-works/add-user-info.md
index a05209472b7..2f583d89cff 100644
--- a/content/en/security/application_security/how-it-works/add-user-info.md
+++ b/content/en/security/application_security/how-it-works/add-user-info.md
@@ -29,7 +29,7 @@ The custom user activity for which out-of-the-box detection rules are available
## Adding authenticated user information to traces and enabling user blocking capability
Steps 1, 3, and 4 may impact your APM traces ingestion. To ensure that ingested span volumes remain stable, configure the
@@ -80,7 +80,7 @@ After:
If you've increased `sessionSampleRate`, you might increase the number of ingested APM spans since the RUM SDK has the ability to override the sampling decisions of backend traces to make the correlation.
-To alleviate this, set `traceSampleRate` to a percentage below 100% (to the previously set `sessionSampleRate`) and set `traceContextInjection: sampled` to allow backend tracing libraries to make their own sampling decisions for sessions where the RUM SDK decides not to keep the trace.
+To alleviate this, set `traceSampleRate` to a percentage below 100% (to the previously set `sessionSampleRate`) and set `traceContextInjection: sampled` to allow backend SDKs to make their own sampling decisions for sessions where the RUM SDK decides not to keep the trace.
#### Step 3: Create retention filters
diff --git a/content/en/remote_configuration/_index.md b/content/en/remote_configuration/_index.md
index b87c24d2e56..852ab3d194f 100644
--- a/content/en/remote_configuration/_index.md
+++ b/content/en/remote_configuration/_index.md
@@ -1,6 +1,6 @@
---
title: Remote Configuration
-description: "Remotely configure and change behavior of Datadog components like Agents, tracing libraries, and Observability Pipelines Workers deployed in your infrastructure."
+description: "Remotely configure and change behavior of Datadog components like Agents, SDKs, and Observability Pipelines Workers deployed in your infrastructure."
aliases:
- /agent/guide/how_rc_works
- /agent/guide/how_remote_config_works
@@ -27,9 +27,9 @@ algolia:
## Overview
-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, tracing libraries, 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.
+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 tracing libraries provide real-time security updates and responses, enhancing security posture for your applications and cloud infrastructure.
+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.
## How it works
diff --git a/content/en/security/ai_guard/onboarding.md b/content/en/security/ai_guard/onboarding.md
index a3cd1b8977e..126ef025ee2 100644
--- a/content/en/security/ai_guard/onboarding.md
+++ b/content/en/security/ai_guard/onboarding.md
@@ -49,9 +49,9 @@ Datadog SDKs use the [Datadog Agent][4] to send AI Guard data to Datadog. The Ag
If you don't use the Datadog Agent, the AI Guard evaluator API still works, but you can't see AI Guard traces in Datadog.
-### 4. Install the tracer library {#install-tracer}
+### 4. Install the SDK {#install-tracer}
-To use AI Guard with the SDK and see AI Guard activity in Datadog, install the appropriate tracer library for your language. The tracer library requires the Datadog Agent to send data to Datadog.
+To use AI Guard with the SDK 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.
{{< tabs >}}
{{% tab "Python" %}}
@@ -70,7 +70,7 @@ npm install dd-trace@^5.69.0
{{% /tab %}}
{{% tab "Java" %}}
-Install dd-trace-java v1.54.0 or later. Follow the [Java installation instructions][1] to add the tracer to your application.
+Install dd-trace-java v1.54.0 or later. Follow the [Java installation instructions][1] to add the SDK to your application.
[1]: /tracing/trace_collection/automatic_instrumentation/dd_libraries/java/
{{% /tab %}}
diff --git a/content/en/security/application_security/api-inventory/_index.md b/content/en/security/application_security/api-inventory/_index.md
index 260f9308cad..9e6d041a81f 100644
--- a/content/en/security/application_security/api-inventory/_index.md
+++ b/content/en/security/application_security/api-inventory/_index.md
@@ -77,7 +77,7 @@ For information on what library versions are compatible with API Security Invent
### How it works
-API Endpoints gathers security metadata about API traffic by leveraging the Datadog tracing library 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, ensuring a comprehensive and up-to-date view of your entire API attack surface.
+API Endpoints gathers security metadata about API traffic by leveraging 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, ensuring a comprehensive and up-to-date view of your entire API attack surface.
API Endpoints uses [Remote Configuration][1] to manage and configure scanning rules that detect sensitive data and authentication.
diff --git a/content/en/security/application_security/exploit-prevention.md b/content/en/security/application_security/exploit-prevention.md
index dd09fd2683f..8f63a3f23de 100644
--- a/content/en/security/application_security/exploit-prevention.md
+++ b/content/en/security/application_security/exploit-prevention.md
@@ -28,7 +28,7 @@ Use App and API Protection's **Exploit Prevention** to protect your critical app
With App and API Protection's context-aware capabilities, you can gain a deep understanding of application logic, data flow, and state.
-Combine telemetry from the Datadog tracer with predefined heuristics to detect and block exploits with higher accuracy, ensuring legitimate traffic remains unaffected.
+Combine telemetry from the Datadog SDK with predefined heuristics to detect and block exploits with higher accuracy, ensuring legitimate traffic remains unaffected.
This is powered by Runtime Application Self Protection (RASP), which allows you to detect and prevent attacks in real time.
@@ -36,7 +36,7 @@ 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 tracing library instrumented in your applications, details are captured about every interaction within the application, including requests, code execution, and data flows.
+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.
3. If a potential exploit is detected:
1. App and API Protection blocks the request in real-time before it causes damage.
@@ -63,7 +63,7 @@ App and API Protection Exploit Prevention intercepts all SQL queries to determin
## Prerequisites
-- Ensure that your applications are instrumented with the Datadog tracer.
+- Ensure that your applications are instrumented with the Datadog SDK.
- App and API Protection 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].
diff --git a/content/en/security/application_security/guide/manage_account_theft_appsec.md b/content/en/security/application_security/guide/manage_account_theft_appsec.md
index 8563cca53a3..721535a701f 100644
--- a/content/en/security/application_security/guide/manage_account_theft_appsec.md
+++ b/content/en/security/application_security/guide/manage_account_theft_appsec.md
@@ -65,7 +65,7 @@ To enable AAP using a new deployment, use the `APPSEC_ENABLED` environment varia
When you see traces from your service in [AAP Traces][6], move to [Step 1.3: Validating login information is automatically collected](#step-1.3:-validating-login-information-is-automatically-collected).
-For more detailed instructions on using a new deployment, see [Enabling AAP Threat Detection using Datadog Tracing Libraries][7].
+For more detailed instructions on using a new deployment, see [Enabling AAP Threat Detection using Datadog SDKs][7].
### Step 1.3: Validating login information is automatically collected
@@ -182,7 +182,7 @@ In microservice environments, services are generally reached by internal hosts r
* Source IPs (`@http.client_ip`) are varied and public IPs.
* **Problem:** If login attempts are coming from a few IPs only, this might be a proxy that you can't block without risking availability.
- * **Solution:** Forward the client IP of the initial request through a HTTP header, such as `X-Forwarded-For`. You can use a custom header for [better security][22] and configure the tracer to read it using the `DD_TRACE_CLIENT_IP_HEADER` environment variable.
+ * **Solution:** Forward the client IP of the initial request through a HTTP header, such as `X-Forwarded-For`. You can use a custom header for [better security][22] and configure the SDK to read it using the `DD_TRACE_CLIENT_IP_HEADER` environment variable.
* The user agent (`@http.user_agent`) is consistent with the expected traffic (web browser, mobile app, etc.)
* **Problem:** The user agent could be replaced by the user agent in the calling microservice network library.
* **Solution:** Use the client user agent when calling subsequent services.
diff --git a/content/en/security/application_security/guide/standalone_application_security.md b/content/en/security/application_security/guide/standalone_application_security.md
index 081c923b650..fa8070de67c 100644
--- a/content/en/security/application_security/guide/standalone_application_security.md
+++ b/content/en/security/application_security/guide/standalone_application_security.md
@@ -10,11 +10,11 @@ Datadog AAP is built on top of [APM][3]. While Datadog recommends using AAP with
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.
-- **Supported Tracing Library:** The Datadog Tracing Library 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 App and API Protection. For more details, see the guide for [App and API Protection][4].
## Compatibility
-Standalone App and API Protection is supported for the following tracing library versions:
+Standalone App and API Protection is supported for the following SDK versions:
| Language | Version |
| -------- | ------- |
@@ -29,7 +29,7 @@ Standalone App and API Protection is supported for the following tracing library
## Setup
-Set up the Datadog Agent using the standard method for APM or App and API Protection setup, but set up the Tracing Library by adding the `DD_APM_TRACING_ENABLED=false` environment variable to the service that runs the Tracing Library.
+Set up the Datadog Agent using the standard method for APM or App and API Protection setup, but set up the SDK by adding the `DD_APM_TRACING_ENABLED=false` environment variable to the service that runs the SDK.
This environment variable will reduce the amount of APM data sent to Datadog to the minimum required by App and API Protection products. The environment variable can then be combined with environment variables to enable App and API Protection.
diff --git a/content/en/security/application_security/how-it-works/_index.md b/content/en/security/application_security/how-it-works/_index.md
index 8a86a97f7a8..bd8a9edf294 100644
--- a/content/en/security/application_security/how-it-works/_index.md
+++ b/content/en/security/application_security/how-it-works/_index.md
@@ -22,14 +22,14 @@ 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 tracing library 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 App and API Protection 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 ([Software 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.
traceSampleRate to the previously configured sessionSampleRate. For instance, if you used to have sessionSampleRate set to 10% and you bump it to 100% for RUM without Limits, decrease the traceSampleRate from 100% to 10% accordingly to ingest the same amount of traces.1-Click Enablement
-If your service is running with an Agent with Remote Configuration enabled and a tracing library version that supports it, you can enable App and API Protection from the Datadog UI without additional configuration of the Agent or tracing libraries.
+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 a tracing library version that supports it, you can enable App and API Protection from the Datadog UI without additional configuration of the Agent or tracing libraries.
-Automated Detection of User Activity: Datadog Tracing Libraries attempt to detect and report user activity events automatically. For more information, see Disabling automatic user activity event tracking.
+Automated Detection of User Activity: Datadog SDKs attempt to detect and report user activity events automatically. For more information, see Disabling automatic user activity event tracking.
You can [add custom tags to your root span][3], or use the instrumentation functions described below.
@@ -1118,7 +1118,7 @@ Once saved, the rule is deployed to instances of the service that have Remote Co
## Automatic user activity event tracking
-When AAP is enabled, Datadog Tracing Libraries attempt to detect user activity events automatically.
+When AAP is enabled, Datadog SDKs attempt to detect user activity events automatically.
The events that can be automatically detected are:
@@ -1162,7 +1162,7 @@ For example, `DD_APPSEC_AUTO_USER_INSTRUMENTATION_MODE=anon`.
The following modes are deprecated:
-- `safe` mode: The trace library does not include any PII information on the events metadata. The tracer library tries to collect the user ID, and only if the user ID is a valid [GUID][10]
+- `safe` mode: The trace library does not include any PII information on the events metadata. The SDK tries to collect the user ID, and only if the user ID is a valid [GUID][10]
- `extended` mode: The trace library tries to collect the user ID, and the user email. In this mode, Datadog does not check the type for the user ID to be a GUID. The trace library reports whatever value can be extracted from the event.
**Note**: There could be cases in which the trace library won't be able to extract any information from the user event. The event would be reported with empty metadata. In those cases, use the [SDK](#adding-business-logic-information-login-success-login-failure-any-business-logic-to-traces) to manually instrument the user events.
@@ -1171,7 +1171,7 @@ The following modes are deprecated:
To disable automated user activity detection through your [AAP Software Catalog][14], change the automatic tracking mode environment variable `DD_APPSEC_AUTO_USER_INSTRUMENTATION_MODE` to `disabled` on the service you want to deactivate. All modes only affect automated instrumentation and require [Remote Configuration][15] to be enabled.
-For manual configuration, you can set the environment variable `DD_APPSEC_AUTOMATED_USER_EVENTS_TRACKING_ENABLED` to `false` on your service and restart it. This must be set on the application hosting the Datadog Tracing Library, and not on the Datadog Agent.
+For manual configuration, you can set the environment variable `DD_APPSEC_AUTOMATED_USER_EVENTS_TRACKING_ENABLED` to `false` on your service and restart it. This must be set on the application hosting the Datadog SDK, and not on the Datadog Agent.
[3]: /tracing/trace_collection/custom_instrumentation/
[4]: /security/default_rules/bl-rate-limiting/
diff --git a/content/en/security/application_security/policies/_index.md b/content/en/security/application_security/policies/_index.md
index df13e718cb2..9c6b4bd5b78 100644
--- a/content/en/security/application_security/policies/_index.md
+++ b/content/en/security/application_security/policies/_index.md
@@ -5,9 +5,9 @@ aliases:
disable_toc: false
---
-If your service is running [an Agent with Remote Configuration enabled and a tracing library version that supports it][2], you can block attacks and attackers from the Datadog UI without additional configuration of the Agent or tracing libraries.
+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 tracing libraries. Blocks are saved in the Datadog platform, automatically and securely fetched by the Datadog Agent, deployed in your infrastructure, and applied to your services.
+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.
## Prerequisites
@@ -16,7 +16,7 @@ To use protection capabilities with your service:
- [Update your Datadog Agent][3] to at least version 7.41.1.
- [Enable AAP][1].
- [Enable Remote Configuration][2].
-- Update your tracing library to at least the minimum version needed to turn on protection. For details, see the AAP capabilities support section of [Compatibility][12] for your service's language.
+- Update your SDK to at least the minimum version needed to turn on protection. For details, see the AAP capabilities support section of [Compatibility][12] for your service's language.
- If you plan to use authenticated user blocking, [add user information to traces][4].
## Blocking attackers (IPs and authenticated users)
@@ -70,7 +70,7 @@ View blocked security traces in the [Trace Explorer][11] by filtering on the fac
### Configure In-App WAF
-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 tracing library in your infrastructure.
+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.
diff --git a/content/en/security/application_security/policies/custom_rules.md b/content/en/security/application_security/policies/custom_rules.md
index aeca48ee080..b5a4996d7ce 100644
--- a/content/en/security/application_security/policies/custom_rules.md
+++ b/content/en/security/application_security/policies/custom_rules.md
@@ -36,7 +36,7 @@ In these situations, a custom detection rule can be created to exclude such even
AAP offers out of the box rules to detect business logic abuse (for example, resetting a password through brute force). Those rules require [adding business logic information to traces][7].
-Recent Datadog Tracing Libraries attempt to detect and send user login and signup events automatically without needing to modify the code. If needed, you can [opt out of the automatic user activity event tracking][8].
+Recent Datadog SDKs attempt to detect and send user login and signup events automatically without needing to modify the code. If needed, you can [opt out of the automatic user activity event tracking][8].
You can filter the rules, and identify which business logic to start tracking. Additionally, you can use these rules as a blueprint to create custom rules based on your own business logic.
diff --git a/content/en/security/application_security/policies/inapp_waf_rules.md b/content/en/security/application_security/policies/inapp_waf_rules.md
index 016851fa2ee..68c8e1b16b2 100644
--- a/content/en/security/application_security/policies/inapp_waf_rules.md
+++ b/content/en/security/application_security/policies/inapp_waf_rules.md
@@ -8,11 +8,11 @@ aliases:
## Overview
-With App and API Protection (AAP) enabled, the Datadog tracing library actively monitors all web services and API requests for suspicious security activity.
+With App and API Protection (AAP) enabled, the Datadog SDK actively monitors all web services and API requests for suspicious security activity.
-An _In-App WAF rule_ specifies conditions on the incoming request to define what the library considers suspicious. The Datadog tracing library includes hundreds of out-of-the-box AAP In-App WAF rules, which are used to display security traces in the trace explorer and in the default signal rules.
+An _In-App WAF rule_ specifies conditions on the incoming request to define what the library considers suspicious. The Datadog SDK includes hundreds of out-of-the-box AAP In-App WAF rules, which are used to display security traces in the trace explorer and in the default signal rules.
-You can add to the In-App WAF rules without upgrading the tracing library.
+You can add to the In-App WAF rules without upgrading the SDK.
## Structure of an AAP In-App WAF rule
diff --git a/content/en/security/application_security/policies/library_configuration.md b/content/en/security/application_security/policies/library_configuration.md
index 03acd34d92d..b51d8a6d8de 100644
--- a/content/en/security/application_security/policies/library_configuration.md
+++ b/content/en/security/application_security/policies/library_configuration.md
@@ -32,7 +32,7 @@ AAP automatically attempts to resolve `http.client_ip` from several well-known h
Many critical attacks are performed by authenticated users who can access your most sensitive endpoints. To identify bad actors that are generating suspicious security activity, add user information to traces by instrumenting your services with the standardized user tags. You can add custom tags to your root span, or use instrumentation functions.
-The Datadog Tracing Library attempts to detect user login and signup events when compatible authentication frameworks are in use, and AAP is enabled.
+The Datadog SDK attempts to detect user login and signup events when compatible authentication frameworks are in use, and AAP is enabled.
Read [Tracking User Activity][1] for more information on how to manually track user activity, or [see how to opt out][7] of the automatic tracking.
diff --git a/content/en/security/application_security/security_signals/attacker_clustering.md b/content/en/security/application_security/security_signals/attacker_clustering.md
index 6c6dd509d06..b3098e5992f 100644
--- a/content/en/security/application_security/security_signals/attacker_clustering.md
+++ b/content/en/security/application_security/security_signals/attacker_clustering.md
@@ -57,7 +57,7 @@ When the attacker attributes are identified, they are displayed on the signal si
### Custom HTTP request headers
-If you want to use custom HTTP request headers for attacker clustering, they must be added under the path `@http.request.headers` in your traces. You can add custom headers to your traces by configuring the tracer with the `DD_TRACE_REQUEST_HEADER_TAGS` environment variable. For more information about this configuration, see [Configure the Datadog Tracing Library][5].
+If you want to use custom HTTP request headers for attacker clustering, they must be added under the path `@http.request.headers` in your traces. You can add custom headers to your traces by configuring the SDK with the `DD_TRACE_REQUEST_HEADER_TAGS` environment variable. For more information about this configuration, see [Configure the Datadog SDK][5].
## Attacker clustering mechanism
diff --git a/content/en/security/application_security/setup/aws/lambda/java.md b/content/en/security/application_security/setup/aws/lambda/java.md
index b961c11da10..e002c44e9f6 100644
--- a/content/en/security/application_security/setup/aws/lambda/java.md
+++ b/content/en/security/application_security/setup/aws/lambda/java.md
@@ -168,7 +168,7 @@ The [Datadog CDK Construct][1] automatically installs Datadog on your functions
{{% /tab %}}
{{% tab "Custom" %}}
-1. Install the Datadog tracer by configuring the layer ARN that matches your deployment. Replace `
- If you are having issues installing the Tracer library check the [Tracer Installation guide][5]
+ If you are having issues installing the SDK check the [Tracer Installation guide][5]
*Note on version:* replace ** with the latest three component version of the library (ej: 3.21.0)
diff --git a/content/en/security/application_security/setup/dotnet/windows.md b/content/en/security/application_security/setup/dotnet/windows.md
index abe43141abc..4072f420469 100644
--- a/content/en/security/application_security/setup/dotnet/windows.md
+++ b/content/en/security/application_security/setup/dotnet/windows.md
@@ -23,7 +23,7 @@ further_reading:
- .NET application
- Administrator privileges for some configuration steps
- Your Datadog API key
-- Datadog .NET tracing library (see version requirements [here][1])
+- Datadog .NET SDK (see version requirements [here][1])
## 1. Installing the Datadog Agent
diff --git a/content/en/security/application_security/setup/envoy.md b/content/en/security/application_security/setup/envoy.md
index 1aec0850b8a..0c327c14070 100644
--- a/content/en/security/application_security/setup/envoy.md
+++ b/content/en/security/application_security/setup/envoy.md
@@ -150,10 +150,10 @@ The App and API Protection Envoy integration uses the Envoy external processing
## Datadog Go Tracer and Envoy integration
-The External Processor is built on top of the [Datadog Go Tracer][6] and inherits all of its environment variables. See [Configuring the Go Tracing Library][7] and [App and API Protection Library Configuration][8].
+The External Processor is built on top of the [Datadog Go Tracer][6] and inherits all of its environment variables. See [Configuring the Go SDK][7] and [App and API Protection Library Configuration][8].
- Note: As the Datadog External Processor is built on top of the Datadog Go Tracer, it generally follows the same release process as the tracer, and its Docker images are tagged with the corresponding tracer version (for example,
## Limitations
diff --git a/content/en/security/application_security/setup/gcp/cloud-run/dotnet.md b/content/en/security/application_security/setup/gcp/cloud-run/dotnet.md
index 47a027fcba6..93617eef5bb 100644
--- a/content/en/security/application_security/setup/gcp/cloud-run/dotnet.md
+++ b/content/en/security/application_security/setup/gcp/cloud-run/dotnet.md
@@ -58,7 +58,7 @@ CMD ["dotnet", "helloworld.dll"]
COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
```
-2. Copy the Datadog .NET tracer into your Docker image.
+2. Copy the Datadog .NET SDK into your Docker image.
```dockerfile
# For arm64 use datadog-dotnet-apm-2.57.0.arm64.tar.gz
# For alpine use datadog-dotnet-apm-2.57.0-musl.tar.gz
@@ -67,7 +67,7 @@ CMD ["dotnet", "helloworld.dll"]
RUN mkdir -p /dd_tracer/dotnet/ && tar -xzvf /tmp/datadog-dotnet-apm.tar.gz -C /dd_tracer/dotnet/ && rm /tmp/datadog-dotnet-apm.tar.gz
```
- If you install the Datadog tracer library directly in your application, as outlined in the [manual tracer instrumentation instructions][1], omit this step.
+ If you install the Datadog SDK directly in your application, as outlined in the [manual tracer instrumentation instructions][1], omit this step.
3. (Optional) Add Datadog tags.
```dockerfile
diff --git a/content/en/security/application_security/setup/gcp/cloud-run/java.md b/content/en/security/application_security/setup/gcp/cloud-run/java.md
index e41b7c8dbd0..848a4f52659 100644
--- a/content/en/security/application_security/setup/gcp/cloud-run/java.md
+++ b/content/en/security/application_security/setup/gcp/cloud-run/java.md
@@ -53,11 +53,11 @@ CMD ["./mvnw", "spring-boot:run"]
COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
```
-2. Add the Datadog Java tracer to your Docker image.
+2. Add the Datadog Java SDK to your Docker image.
```dockerfile
ADD 'https://dtdg.co/latest-java-tracer' /dd_tracer/java/dd-java-agent.jar
```
- If you install the Datadog tracer library directly in your application, as outlined in the [manual tracer instrumentation instructions][1], omit this step.
+ If you install the Datadog SDK directly in your application, as outlined in the [manual tracer instrumentation instructions][1], omit this step.
3. (Optional) Add Datadog tags.
```dockerfile
diff --git a/content/en/security/application_security/setup/gcp/cloud-run/nodejs.md b/content/en/security/application_security/setup/gcp/cloud-run/nodejs.md
index cca5ba64d37..05c2d221f52 100644
--- a/content/en/security/application_security/setup/gcp/cloud-run/nodejs.md
+++ b/content/en/security/application_security/setup/gcp/cloud-run/nodejs.md
@@ -55,13 +55,13 @@ CMD ["/nodejs/bin/node", "/path/to/your/app.js"]
COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
```
-2. Copy the Datadog Node.js tracer into your Docker image.
+2. Copy the Datadog Node.js SDK into your Docker image.
```dockerfile
RUN npm install --prefix /dd_tracer/node dd-trace --save
```
- If you install the Datadog tracer library directly in your application, as outlined in the [manual tracer instrumentation instructions][1], omit this step.
+ If you install the Datadog SDK directly in your application, as outlined in the [manual tracer instrumentation instructions][1], omit this step.
3. (Optional) Add Datadog tags.
diff --git a/content/en/security/application_security/setup/gcp/cloud-run/php.md b/content/en/security/application_security/setup/gcp/cloud-run/php.md
index 469757b2562..cd4104f0ca0 100644
--- a/content/en/security/application_security/setup/gcp/cloud-run/php.md
+++ b/content/en/security/application_security/setup/gcp/cloud-run/php.md
@@ -66,12 +66,12 @@ CMD php-fpm; nginx -g daemon off;
COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
```
-2. Copy and install the Datadog PHP tracer.
+2. Copy and install the Datadog PHP SDK.
```dockerfile
ADD https://github.com/DataDog/dd-trace-php/releases/latest/download/datadog-setup.php /datadog-setup.php
RUN php /datadog-setup.php --php-bin=all
```
- If you install the Datadog tracer library directly in your application, as outlined in the [manual tracer instrumentation instructions][1], omit this step.
+ If you install the Datadog SDK directly in your application, as outlined in the [manual tracer instrumentation instructions][1], omit this step.
3. (Optional) Add Datadog tags.
```dockerfile
diff --git a/content/en/security/application_security/setup/gcp/cloud-run/python.md b/content/en/security/application_security/setup/gcp/cloud-run/python.md
index d7e1aa2f8c7..d4e8b8eb510 100644
--- a/content/en/security/application_security/setup/gcp/cloud-run/python.md
+++ b/content/en/security/application_security/setup/gcp/cloud-run/python.md
@@ -53,11 +53,11 @@ CMD ["/dd_tracer/python/bin/ddtrace-run", "python", "app.py"]
COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
```
-2. Install the Datadog Python tracer.
+2. Install the Datadog Python SDK.
```dockerfile
RUN pip install --target /dd_tracer/python/ ddtrace
```
- If you install the Datadog tracer library directly in your application, as outlined in the [manual tracer instrumentation instructions][1], omit this step.
+ If you install the Datadog SDK directly in your application, as outlined in the [manual tracer instrumentation instructions][1], omit this step.
3. (Optional) Add Datadog tags.
```dockerfile
diff --git a/content/en/security/application_security/setup/gcp/service-extensions.md b/content/en/security/application_security/setup/gcp/service-extensions.md
index 9f3db119e03..bdfd2cc7703 100644
--- a/content/en/security/application_security/setup/gcp/service-extensions.md
+++ b/content/en/security/application_security/setup/gcp/service-extensions.md
@@ -498,10 +498,10 @@ Configure the container to send traces to your Datadog Agent using the following
| `DD_AGENT_HOST` | `localhost` | Hostname or IP of your Datadog Agent. |
| `DD_TRACE_AGENT_PORT` | `8126` | Port of the Datadog Agent for trace collection. |
-The App and API Protection GCP Service Extensions integration is built on top of the [Datadog Go Tracer][6] and inherits all of its environment variables. See [Configuring the Go Tracing Library][7] and [App and API Protection Library Configuration][8].
+The App and API Protection GCP Service Extensions integration is built on top of the [Datadog Go Tracer][6] and inherits all of its environment variables. See [Configuring the Go SDK][7] and [App and API Protection Library Configuration][8].
v2.2.2). In some cases, early release versions might be published between official tracer releases, and these images are tagged with a suffix such as -docker.1.
+ Note: As the Datadog External Processor is built on top of the Datadog Go Tracer, it generally follows the same release process as the SDK, and its Docker images are tagged with the corresponding tracer version (for example, v2.2.2). In some cases, early release versions might be published between official tracer releases, and these images are tagged with a suffix such as -docker.1.
- Note: As the App and API Protection GCP Service Extensions integration is built on top of the Datadog Go Tracer, it generally follows the same release process as the tracer, and its Docker images are tagged with the corresponding tracer version (for example,
## Limitations
diff --git a/content/en/security/application_security/setup/go/aws-fargate.md b/content/en/security/application_security/setup/go/aws-fargate.md
index 9274d0c02e5..9d327f58554 100644
--- a/content/en/security/application_security/setup/go/aws-fargate.md
+++ b/content/en/security/application_security/setup/go/aws-fargate.md
@@ -19,7 +19,7 @@ further_reading:
- AWS Fargate environment
- Go application containerized with Docker
- - Instrumented with the Datadog Go tracing library (see [version requirements][3])
+ - Instrumented with the Datadog Go SDK (see [version requirements][3])
- AWS CLI configured with appropriate permissions
- Your Datadog API key
diff --git a/content/en/security/application_security/setup/go/setup.md b/content/en/security/application_security/setup/go/setup.md
index cab542c881b..d6ff3845e38 100644
--- a/content/en/security/application_security/setup/go/setup.md
+++ b/content/en/security/application_security/setup/go/setup.md
@@ -157,7 +157,7 @@ If you are building your Go application without [CGO][9], you can still enable A
### Building with Bazel
If you are using Bazel and [rules_go][12] to build your Go application, [Orchestrion][7] is not compatible with Bazel.
-Instead, you can use the [Datadog Go Tracer library][11] to instrument your application manually.
+Instead, you can use the [Datadog Go SDK][11] to instrument your application manually.
App and API Protection relies on [purego][13] to support its C++ biddings to DataDog's WAF, which requires special attention inside the `repositories.bzl` generated by Gazelle. Under the `go_repository` rule for `com_github_ebitengine_purego`,
you need to add the `build_directives` attribute with the `gazelle:build_tags cgo` directive. For example:
@@ -179,7 +179,7 @@ you need to add the `build_directives` attribute with the `gazelle:build_tags cg
If you want to use App and API Protection without APM tracing functionality, you can deploy with tracing disabled:
-1. Configure your tracing library with the `DD_APM_TRACING_ENABLED=false` environment variable in addition to the `DD_APPSEC_ENABLED=true` environment variable. This configuration reduces the amount of APM data sent to Datadog to the minimum required by App and API Protection products.
+1. Configure your SDK with the `DD_APM_TRACING_ENABLED=false` environment variable in addition to the `DD_APPSEC_ENABLED=true` environment variable. This configuration reduces the amount of APM data sent to Datadog to the minimum required by App and API Protection products.
For more details, see [Standalone App and API Protection][8].
diff --git a/content/en/security/application_security/setup/go/troubleshooting.md b/content/en/security/application_security/setup/go/troubleshooting.md
index 1db36d4693e..aa67f9ad2e1 100644
--- a/content/en/security/application_security/setup/go/troubleshooting.md
+++ b/content/en/security/application_security/setup/go/troubleshooting.md
@@ -110,7 +110,7 @@ For detailed examples and best practices, see the [Building your Go application
If you're using Bazel with [rules_go][5], Orchestrion is not compatible with it. Instead:
-1. **Use manual instrumentation**: Follow the [manual instrumentation guide][6] with the Datadog Go Tracer library
+1. **Use manual instrumentation**: Follow the [manual instrumentation guide][6] with the Datadog Go SDK
For complete Bazel setup instructions, see the [Building with Bazel section][7] in the setup guide.
diff --git a/content/en/security/application_security/setup/haproxy.md b/content/en/security/application_security/setup/haproxy.md
index 15479d46435..5b283dadebb 100644
--- a/content/en/security/application_security/setup/haproxy.md
+++ b/content/en/security/application_security/setup/haproxy.md
@@ -128,10 +128,10 @@ Configure the SPOA to send traces to your Datadog Agent using the following envi
### Datadog Go Tracer and HAProxy integration
-The HAProxy integration is built on top of the [Datadog Go Tracer][5] and inherits all of its environment variables. See [Configuring the Go Tracing Library][6] and [App and API Protection Library Configuration][7].
+The HAProxy integration is built on top of the [Datadog Go Tracer][5] and inherits all of its environment variables. See [Configuring the Go SDK][6] and [App and API Protection Library Configuration][7].
v2.2.2). In some cases, early release versions might be published between official tracer releases, and these images are tagged with a suffix such as -docker.1.
+ Note: As the App and API Protection GCP Service Extensions integration is built on top of the Datadog Go Tracer, it generally follows the same release process as the SDK, and its Docker images are tagged with the corresponding tracer version (for example, v2.2.2). In some cases, early release versions might be published between official tracer releases, and these images are tagged with a suffix such as -docker.1.
- Note: As the Datadog SPOA is built on top of the Datadog Go Tracer, it generally follows the same release process as the tracer, and its Docker images are tagged with the corresponding tracer version (for example,
v2.4.0). In some cases, early release versions might be published between official tracer releases, and these images are tagged with a suffix such as -docker.1.
+ Note: As the Datadog SPOA is built on top of the Datadog Go Tracer, it generally follows the same release process as the SDK, and its Docker images are tagged with the corresponding tracer version (for example, v2.4.0). In some cases, early release versions might be published between official tracer releases, and these images are tagged with a suffix such as -docker.1.
## Keeping your configuration up to date diff --git a/content/en/security/application_security/setup/java/aws-fargate.md b/content/en/security/application_security/setup/java/aws-fargate.md index 8b34be740ae..65c0f61b7c2 100644 --- a/content/en/security/application_security/setup/java/aws-fargate.md +++ b/content/en/security/application_security/setup/java/aws-fargate.md @@ -23,7 +23,7 @@ further_reading: - Java application containerized with Docker - AWS CLI configured with appropriate permissions - Your Datadog API key -- Datadog Java tracing library (see [version requirements][1]) +- Datadog Java SDK (see [version requirements][1]) ## 1. Installing the Datadog Agent diff --git a/content/en/security/application_security/setup/java/compatibility.md b/content/en/security/application_security/setup/java/compatibility.md index 404bb0ab57f..2494c9eb6c7 100644 --- a/content/en/security/application_security/setup/java/compatibility.md +++ b/content/en/security/application_security/setup/java/compatibility.md @@ -37,9 +37,9 @@ Threat Detection is supported for the following deployment types: ### Supported Java versions -The Datadog Java Tracing library is open source. View the [GitHub repository][2] for more information. +The Datadog Java SDK is open source. View the [GitHub repository][2] for more information. -The Datadog Java Tracing Library supports Java 8 and newer versions. For optimal performance and feature support, we recommend using the latest LTS version of Java. +The Datadog Java SDK supports Java 8 and newer versions. For optimal performance and feature support, we recommend using the latest LTS version of Java. You must be running Datadog Agent v7.41.1+ for App and API Protection features. diff --git a/content/en/security/application_security/setup/java/docker.md b/content/en/security/application_security/setup/java/docker.md index bcf21eda27f..86535141600 100644 --- a/content/en/security/application_security/setup/java/docker.md +++ b/content/en/security/application_security/setup/java/docker.md @@ -23,7 +23,7 @@ further_reading: - Docker installed on your host - Java application containerized with Docker - Your Datadog API key -- Datadog Java tracing library (see version requirements [here][1]) +- Datadog Java SDK (see version requirements [here][1]) ## 1. Installing the Datadog Agent @@ -43,7 +43,7 @@ Install the Datadog Agent by following the [setup instructions for Docker][3]. Start your Java application with the Datadog agent and App and API Protection enabled using the ENTRYPOINT instruction: ```dockerfile -# Download the Datadog Java tracer +# Download the Datadog Java SDK ADD 'https://dtdg.co/latest-java-tracer' /dd-java-agent.jar ENTRYPOINT ["java", "-javaagent:/dd-java-agent.jar", "-Ddd.appsec.enabled=true", "-Ddd.service=
- Note: As the Datadog External Processor is built on top of the Datadog Go Tracer, it generally follows the same release process as the tracer, and its Docker images are tagged with the corresponding tracer version (for example,
### Step 2: Configure an EnvoyExtensionPolicy
diff --git a/content/en/security/application_security/setup/kubernetes/gateway-api.md b/content/en/security/application_security/setup/kubernetes/gateway-api.md
index 16f7c6ee850..ace5c6606cf 100644
--- a/content/en/security/application_security/setup/kubernetes/gateway-api.md
+++ b/content/en/security/application_security/setup/kubernetes/gateway-api.md
@@ -149,10 +149,10 @@ spec:
## Datadog Go Tracer and Gateway API integration
v2.2.2). In some cases, early release versions might be published between official tracer releases, and these images are tagged with a suffix such as -docker.1.
+ Note: As the Datadog External Processor is built on top of the Datadog Go Tracer, it generally follows the same release process as the SDK, and its Docker images are tagged with the corresponding tracer version (for example, v2.2.2). In some cases, early release versions might be published between official tracer releases, and these images are tagged with a suffix such as -docker.1.
- The AAP Gateway API integration is built on top of the Datadog Go Tracer. It follows the same release process as the tracer, and its Docker images are tagged with the corresponding tracer version.
+ The AAP Gateway API integration is built on top of the Datadog Go Tracer. It follows the same release process as the SDK, and its Docker images are tagged with the corresponding tracer version.
-The Gateway API integration uses the [Datadog Go Tracer][6] and inherits all environment variables from the tracer. You can find more information in [Configuring the Go Tracing Library][7] and [AAP Library Configuration][8].
+The Gateway API integration uses the [Datadog Go Tracer][6] and inherits all environment variables from the SDK. You can find more information in [Configuring the Go SDK][7] and [AAP Library Configuration][8].
## Enabling APM tracing
diff --git a/content/en/security/application_security/setup/kubernetes/istio.md b/content/en/security/application_security/setup/kubernetes/istio.md
index 152a9a080f1..b28db44d2bb 100644
--- a/content/en/security/application_security/setup/kubernetes/istio.md
+++ b/content/en/security/application_security/setup/kubernetes/istio.md
@@ -127,7 +127,7 @@ This service is a gRPC server that Envoy communicates with to have requests and
Create a Kubernetes Deployment and Service for the Datadog External Processor. It's recommended to deploy this service in a namespace accessible by your Istio Ingress Gateway.
-The Datadog External Processor Docker image is available on the [Datadog Go tracer GitHub Registry][6].
+The Datadog External Processor Docker image is available on the [Datadog Go SDK GitHub Registry][6].
Here is an example manifest (`datadog-aap-extproc-service.yaml`):
@@ -218,10 +218,10 @@ Configure the connection from the external processor to the Datadog Agent using
| `DD_AGENT_HOST` | `localhost` | Hostname or IP of your Datadog Agent. |
| `DD_TRACE_AGENT_PORT` | `8126` | Port of the Datadog Agent for trace collection. |
-The External Processor is built on top of the [Datadog Go Tracer][7] and inherits all of its environment variables. See [Configuring the Go Tracing Library][8] and [App and API Protection Library Configuration][9].
+The External Processor is built on top of the [Datadog Go Tracer][7] and inherits all of its environment variables. See [Configuring the Go SDK][8] and [App and API Protection Library Configuration][9].
- Note: As the Datadog External Processor is built on top of the Datadog Go Tracer, it generally follows the same release process as the tracer, and its Docker images are tagged with the corresponding tracer version (for example,
### Step 2: Configure an EnvoyFilter
diff --git a/content/en/security/application_security/setup/nginx/linux.md b/content/en/security/application_security/setup/nginx/linux.md
index a9cf91fe6f5..61024ad42cb 100644
--- a/content/en/security/application_security/setup/nginx/linux.md
+++ b/content/en/security/application_security/setup/nginx/linux.md
@@ -35,7 +35,7 @@ The Datadog nginx tracing module has experimental support for threat detection a
`--with-threads` in the output, you will need to rebuild nginx with this flag
enabled. For more information on how to build nginx from sources, see the
[nginx documentation][3].
-2. Update your nginx tracing library module to at least version 1.2.0. Visit
+2. Update your nginx SDK module to at least version 1.2.0. Visit
the [GitHub releases page][2] and select the artifact named according to the
pattern `ngx_http_datadog_module-appsec-v2.2.2). In some cases, early release versions might be published between official tracer releases, and these images are tagged with a suffix such as -docker.1.
+ Note: As the Datadog External Processor is built on top of the Datadog Go Tracer, it generally follows the same release process as the SDK, and its Docker images are tagged with the corresponding tracer version (for example, v2.2.2). In some cases, early release versions might be published between official tracer releases, and these images are tagged with a suffix such as -docker.1.
Datadog strongly encourages you to always use the last stable release of the tracer.
+Datadog strongly encourages you to always use the last stable release of the SDK.
Threat Protection requires enabling [Remote Configuration][2], which is included in the listed minimum tracer version.
diff --git a/content/en/security/application_security/setup/python/docker.md b/content/en/security/application_security/setup/python/docker.md
index 755a7b5b766..6581e03def6 100644
--- a/content/en/security/application_security/setup/python/docker.md
+++ b/content/en/security/application_security/setup/python/docker.md
@@ -23,7 +23,7 @@ further_reading:
- Docker installed on your host
- Python application containerized with Docker
- Your Datadog API key
-- Datadog Python tracing library (see [version requirements][1])
+- Datadog Python SDK (see [version requirements][1])
## 1. Installing the Datadog Agent
@@ -41,7 +41,7 @@ Install the Datadog Agent by following the [setup instructions for Docker](/agen
Add the following environment variables to your Dockerfile:
```dockerfile
-# Install the Datadog Python tracing library
+# Install the Datadog Python SDK
RUN pip install ddtrace
# Set environment variables
@@ -61,7 +61,7 @@ To disable APM tracing while keeping App and API Protection enabled, you must se
Add the following environment variables to your Dockerfile:
```dockerfile
-# Install the Datadog Python tracing library
+# Install the Datadog Python SDK
RUN pip install ddtrace
# Set environment variables
diff --git a/content/en/security/application_security/setup/python/kubernetes.md b/content/en/security/application_security/setup/python/kubernetes.md
index b614ce0364c..41de466b56e 100644
--- a/content/en/security/application_security/setup/python/kubernetes.md
+++ b/content/en/security/application_security/setup/python/kubernetes.md
@@ -25,7 +25,7 @@ further_reading:
- kubectl configured to access your cluster
- Helm (recommended for Agent installation)
- Your Datadog API key
-- Datadog Python tracing library (see [version requirements][1])
+- Datadog Python SDK (see [version requirements][1])
## 1. Installing the Datadog Agent
@@ -38,7 +38,7 @@ Install the Datadog Agent by following the [setup instructions for Kubernetes](/
### Manually enabling App and API Protection monitoring
-Install the Datadog Python tracing library using an init container or in your application's Dockerfile:
+Install the Datadog Python SDK using an init container or in your application's Dockerfile:
```dockerfile
RUN pip install ddtrace
diff --git a/content/en/security/application_security/setup/python/linux.md b/content/en/security/application_security/setup/python/linux.md
index 20f346fc915..89e842afc7f 100644
--- a/content/en/security/application_security/setup/python/linux.md
+++ b/content/en/security/application_security/setup/python/linux.md
@@ -25,7 +25,7 @@ further_reading:
- Root or sudo privileges
- Systemd (for service management)
- Your Datadog API key
-- Datadog Python tracing library (see [version requirements][1])
+- Datadog Python SDK (see [version requirements][1])
## 1. Installing the Datadog Agent
@@ -38,7 +38,7 @@ Install the Datadog Agent by following the [setup instructions for Linux hosts](
### Manually enabling App and API Protection monitoring
-Install the Datadog Python tracing library:
+Install the Datadog Python SDK:
```bash
pip install ddtrace
diff --git a/content/en/security/application_security/setup/python/macos.md b/content/en/security/application_security/setup/python/macos.md
index bf0a46746f7..e6592553dcc 100644
--- a/content/en/security/application_security/setup/python/macos.md
+++ b/content/en/security/application_security/setup/python/macos.md
@@ -23,7 +23,7 @@ further_reading:
- Homebrew (recommended for Agent installation)
- Administrator privileges for some configuration steps
- Your Datadog API key
-- Datadog Python tracing library (see [version requirements][1])
+- Datadog Python SDK (see [version requirements][1])
## 1. Installing the Datadog Agent
@@ -36,7 +36,7 @@ Install the Datadog Agent by following the [setup instructions for macOS](/agent
### Manually enabling App and API Protection monitoring
-Install the Datadog Python tracing library:
+Install the Datadog Python SDK:
```bash
pip install ddtrace
diff --git a/content/en/security/application_security/setup/python/windows.md b/content/en/security/application_security/setup/python/windows.md
index cd77b0ae6cb..5a09b54054d 100644
--- a/content/en/security/application_security/setup/python/windows.md
+++ b/content/en/security/application_security/setup/python/windows.md
@@ -22,7 +22,7 @@ further_reading:
- Python application
- Administrator privileges for some configuration steps
- Your Datadog API key
-- Datadog Python tracing library (see [version requirements][1])
+- Datadog Python SDK (see [version requirements][1])
## 1. Installing the Datadog Agent
@@ -35,7 +35,7 @@ Install the Datadog Agent by following the [setup instructions for Windows](/age
### Manually enabling App and API Protection monitoring
-Install the Datadog Python tracing library:
+Install the Datadog Python SDK:
```powershell
pip install ddtrace
diff --git a/content/en/security/application_security/setup/ruby/aws-fargate.md b/content/en/security/application_security/setup/ruby/aws-fargate.md
index 226e3b04088..8ffd1749549 100644
--- a/content/en/security/application_security/setup/ruby/aws-fargate.md
+++ b/content/en/security/application_security/setup/ruby/aws-fargate.md
@@ -23,7 +23,7 @@ further_reading:
- Ruby application containerized with Docker
- AWS CLI configured with appropriate permissions
- Your Datadog API key
-- Datadog Ruby tracing library (see [version requirements][1])
+- Datadog Ruby SDK (see [version requirements][1])
## 1. Installing the Datadog Agent
diff --git a/content/en/security/application_security/setup/ruby/compatibility.md b/content/en/security/application_security/setup/ruby/compatibility.md
index 2a3bf258189..ddc0d4c7b71 100644
--- a/content/en/security/application_security/setup/ruby/compatibility.md
+++ b/content/en/security/application_security/setup/ruby/compatibility.md
@@ -33,7 +33,7 @@ The minimum tracer version to get all supported App and API Protection capabilit
### Supported Ruby interpreters
-The Datadog Ruby Tracing library is open source. View the [GitHub repository][1] for more information.
+The Datadog Ruby SDK is open source. View the [GitHub repository][1] for more information.
- MRI versions 2.5 to 3.5
- JRuby versions 9.2.21.0+ and 9.4
diff --git a/content/en/security/application_security/setup/ruby/docker.md b/content/en/security/application_security/setup/ruby/docker.md
index 4a49ce98e34..2a0a164b6f9 100644
--- a/content/en/security/application_security/setup/ruby/docker.md
+++ b/content/en/security/application_security/setup/ruby/docker.md
@@ -24,7 +24,7 @@ further_reading:
- Docker installed on your host
- Ruby application containerized with Docker
- Your Datadog API key
-- Datadog Ruby tracing library (see [version requirements][1])
+- Datadog Ruby SDK (see [version requirements][1])
## 1. Installing the Datadog Agent
diff --git a/content/en/security/application_security/setup/ruby/kubernetes.md b/content/en/security/application_security/setup/ruby/kubernetes.md
index 0b9b24f3fa0..35f17502df8 100644
--- a/content/en/security/application_security/setup/ruby/kubernetes.md
+++ b/content/en/security/application_security/setup/ruby/kubernetes.md
@@ -26,7 +26,7 @@ further_reading:
- kubectl configured to access your cluster
- Helm (recommended for Agent installation)
- Your Datadog API key
-- Datadog Ruby tracing library (see [version requirements][1])
+- Datadog Ruby SDK (see [version requirements][1])
## 1. Installing the Datadog Agent
diff --git a/content/en/security/application_security/setup/ruby/linux.md b/content/en/security/application_security/setup/ruby/linux.md
index e489a815caf..5d77df009d6 100644
--- a/content/en/security/application_security/setup/ruby/linux.md
+++ b/content/en/security/application_security/setup/ruby/linux.md
@@ -25,7 +25,7 @@ further_reading:
- Ruby application
- Root or sudo privileges
- Your Datadog API key
-- Datadog Ruby tracing library (see [version requirements][1])
+- Datadog Ruby SDK (see [version requirements][1])
## 1. Installing the Datadog Agent
diff --git a/content/en/security/application_security/setup/ruby/macos.md b/content/en/security/application_security/setup/ruby/macos.md
index f408f7b3cb9..5373e850065 100644
--- a/content/en/security/application_security/setup/ruby/macos.md
+++ b/content/en/security/application_security/setup/ruby/macos.md
@@ -24,7 +24,7 @@ further_reading:
- Homebrew (recommended for Agent installation)
- Administrator privileges for some configuration steps
- Your Datadog API key
-- Datadog Ruby tracing library (see [version requirements][1])
+- Datadog Ruby SDK (see [version requirements][1])
## 1. Installing the Datadog Agent
diff --git a/content/en/security/application_security/setup/ruby/troubleshooting.md b/content/en/security/application_security/setup/ruby/troubleshooting.md
index 4a67f50621c..4be23b42e8a 100644
--- a/content/en/security/application_security/setup/ruby/troubleshooting.md
+++ b/content/en/security/application_security/setup/ruby/troubleshooting.md
@@ -37,7 +37,7 @@ title: Troubleshooting Ruby App and API Protection
2. High memory usage:
- Adjust Agent resource limits if needed.
-If you suspect performance issues with the Ruby tracer, please create an issue in the [Datadog Ruby tracer GitHub repository][4] with details about your environment and the issue you're facing.
+If you suspect performance issues with the Ruby tracer, please create an issue in the [Datadog Ruby SDK GitHub repository][4] with details about your environment and the issue you're facing.
### Still having issues?
diff --git a/content/en/security/application_security/setup/single_step/_index.md b/content/en/security/application_security/setup/single_step/_index.md
index 1d7082a8c1a..98f30aa47a0 100644
--- a/content/en/security/application_security/setup/single_step/_index.md
+++ b/content/en/security/application_security/setup/single_step/_index.md
@@ -39,7 +39,7 @@ For an Ubuntu host:
You can also optionally configure the following:
@@ -50,7 +50,7 @@ For an Ubuntu host:
**Note:** To configure single-step for AAP threat protection, add the environment variable `DD_APPSEC_ENABLED=true` to your one-line installation command.
-### Specifying tracing library versions {#lib-linux}
+### Specifying SDK versions {#lib-linux}
By default, enabling APM on your server installs support for Java, Python, Node.js, and .NET Core services. If you only have services implemented in some of these languages, set `DD_APM_INSTRUMENTATION_LIBRARIES` in your one-line installation command:
@@ -58,7 +58,7 @@ By default, enabling APM on your server installs support for Java, Python, Node.
DD_APM_INSTRUMENTATION_LIBRARIES="java:1.25.0,python" DD_API_KEY=
You can also optionally configure the following:
3. Restart the Docker containers.
4. [Explore the performance observability of your services in Datadog][6].
-### Specifying tracing library versions {#lib-docker}
+### Specifying SDK versions {#lib-docker}
By default, enabling APM on your server installs support for Java, Python, Node.js, and .NET services. If you only have services implemented in some of these languages, set `DD_APM_INSTRUMENTATION_LIBRARIES` when running the installation script.
-For example, to install support for only v1.25.0 of the Java tracing library and the latest Python tracing library, add the following to the installation command:
+For example, to install support for only v1.25.0 of the Java SDK and the latest Python SDK, add the following to the installation command:
```shell
DD_APM_INSTRUMENTATION_LIBRARIES="java:1.25.0,python" DD_APM_INSTRUMENTATION_ENABLED=docker DD_NO_AGENT_INSTALL=true DD_APPSEC_ENABLED=true bash -c "$(curl -L https://install.datadoghq.com/scripts/install_script_agent7.sh)"
```
-You can optionally provide a version number for the tracing library by placing a colon after the language name and specifying the tracing library version. If you don't specify a version, it defaults to the latest version. Language names are comma-separated.
+You can optionally provide a version number for the SDK by placing a colon after the language name and specifying the SDK version. If you don't specify a version, it defaults to the latest version. Language names are comma-separated.
Supported languages include:
@@ -142,7 +142,7 @@ Supported languages include:
- Ruby (`ruby`)
- PHP (`php`)
-**Note**: For the Node.js tracing library, different versions of Node.js are compatible with different versions of the Node.js tracing library. See [DataDog/dd-trace-js: JavaScript APM Tracer][7] for more information.
+**Note**: For the Node.js SDK, different versions of Node.js are compatible with different versions of the Node.js SDK. See [DataDog/dd-trace-js: JavaScript APM Tracer][7] for more information.
### Tagging observability data by environment {#env-docker}
diff --git a/content/en/security/application_security/terms.md b/content/en/security/application_security/terms.md
index 8bf083b6b33..e6d55897888 100644
--- a/content/en/security/application_security/terms.md
+++ b/content/en/security/application_security/terms.md
@@ -21,7 +21,7 @@ attack attempt
: Which security rule was triggered by the trace.
Datadog library
-: _also_ tracer, tracing library
+: _also_ tracer, SDK
: A programming language-specific library embedded in web applications. Datadog App and API Protection uses the library to monitor and protect. APM uses the same library to instrument code for tracing telemetry.
detection rule
diff --git a/content/en/security/application_security/troubleshooting.md b/content/en/security/application_security/troubleshooting.md
index 929bd61db70..37e636aea93 100644
--- a/content/en/security/application_security/troubleshooting.md
+++ b/content/en/security/application_security/troubleshooting.md
@@ -225,7 +225,7 @@ For Node.js, the HTTP integration is required.
For Ruby, the [Rack][2] integration is required. Ruby tracer version `1.0.0` or higher is also required. See information on [migrating from 0.x to 1.x][3].
-**Note:** Rack can be manually added or automatically added with the [Rails][4] or [Sinatra][5] integration. If manually added, the tracer middleware must appear before the security middleware in the Rack stack.
+**Note:** Rack can be manually added or automatically added with the [Rails][4] or [Sinatra][5] integration. If manually added, the SDK middleware must appear before the security middleware in the Rack stack.
[2]: /tracing/trace_collection/dd_libraries/ruby/#rack
[3]: https://github.com/DataDog/dd-trace-rb/blob/master/docs/UpgradeGuide.md#from-0x-to-10
@@ -248,7 +248,7 @@ framework you're using, such as the Django or Flask integration.
- Check the details of the running Agent at this address `http://- AAP relies on the tracer, so if you don't see traces, then the tracer might not be working. See [APM Troubleshooting][5]. +2. Confirm that the SDK is working by looking for relevant traces on the APM dashboard.
+ AAP relies on the SDK, so if you don't see traces, then the SDK might not be working. See [APM Troubleshooting][5]. 3. In your application directory, run the command `npm explore @datadog/native-appsec -- npm run install` and restart your app. 1. If `@datadog/native-appsec` is not found, then the installation is incorrect. 1. If `@datadog/native-appsec` is found when starting your application, add the command to your runtime start script. - 1. If the tracer still does not work, you might be running an unsupported runtime. + 1. If the SDK still does not work, you might be running an unsupported runtime. 4. To enable logs, add the following environment variables: ``` DD_TRACE_DEBUG=1 @@ -416,9 +416,9 @@ If you don't see AAP threat information in the [Trace and Signals Explorer][1] f If this log is not present, AAP is not running. -2. Is the tracer working? Can you see relevant traces on the APM dashboard? +2. Is the SDK working? Can you see relevant traces on the APM dashboard? - AAP relies on the tracer. If you don't see traces, then the tracer might not be working. See [APM Troubleshooting][2]. + AAP relies on the SDK. If you don't see traces, then the SDK might not be working. See [APM Troubleshooting][2]. [1]: https://app.datadoghq.com/security/appsec/ @@ -450,7 +450,7 @@ If you do not see those logs, check the following: - If the correct AAP environment variables are set for your application process. - The latest gem version is installed. -- The tracer is configured correctly and sending APM traces to your APM dashboard. +- The SDK is configured correctly and sending APM traces to your APM dashboard. #### Is AAP called for each HTTP request? @@ -489,7 +489,7 @@ D, [2021-12-14T22:39:53.268820 #106051] DEBUG -- ddtrace: [ddtrace] (ddtrace/lib ``` If you don't see those logs, check that another upstream security system is not filtering out the requests or altering them based on the test header value. -#### Is the tracer sending traces with security data? +#### Is the SDK sending traces with security data? AAP data is sent with APM traces. To confirm that AAP correctly detects and inserts security data into traces, trigger a [test attack](#send-a-test-attack-to-your-application), and look for these tracer logs: ``` @@ -540,7 +540,7 @@ AAP data is sent with APM traces. See [APM troubleshooting][4] to [confirm APM s ### Confirm tracer versions are updated -See the App and API Protection product set up documentation to validate you you are using the right version of the tracer. These minimum versions are required to start sending telemetry data that includes library information. +See the App and API Protection product set up documentation to validate you 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/content/en/security/code_security/iast/_index.md b/content/en/security/code_security/iast/_index.md index 379eabd02c3..3da0b18073b 100644 --- a/content/en/security/code_security/iast/_index.md +++ b/content/en/security/code_security/iast/_index.md @@ -59,10 +59,10 @@ For a list of supported services, see the [Library Compatibility Requirements][5 | Low | Session Rewriting | SESSION_REWRITING | TRUE | FALSE | FALSE | FALSE | ## How IAST detects vulnerabilities -Datadog Runtime Code Analysis (IAST) utilizes the same tracing libraries as Datadog APM, enabling it to monitor live application traffic and detect code-level vulnerabilities in real time. It follows this process: +Datadog Runtime Code Analysis (IAST) utilizes the same SDKs as Datadog APM, enabling it to monitor live application traffic and detect code-level vulnerabilities in real time. It follows this process: - **Tracking data sources:**: IAST observes data entering your application from external sources such as request URLs, bodies, or headers. These inputs are tagged and monitored throughout their lifecycle. -- **Analyzing data flow**: The Datadog tracing library tracks how the input data moves through the application—even if it's transformed, split, or combined. This allows IAST to understand if and how the original input reaches sensitive parts of the code. +- **Analyzing data flow**: The Datadog SDK tracks how the input data moves through the application—even if it's transformed, split, or combined. This allows IAST to understand if and how the original input reaches sensitive parts of the code. - **Identifying vulnerable points**: IAST detects code locations where user-controlled inputs are used in potentially insecure ways—for example, in SQL queries, dynamic code execution, or HTML rendering. - **Confirming the vulnerability**: A vulnerability is only reported when IAST can confirm that tainted input reaches a vulnerable point in the code. This approach minimizes false positives and ensures that findings are actionable. @@ -122,7 +122,7 @@ If a vulnerability that was previously closed is detected again within the follo ## Enable Runtime Code Analysis (IAST) -To enable IAST, configure the [Datadog Tracing Library][9]. Detailed instructions for both methods can be found in the [**Security > Code Security > Settings**][10] section. +To enable IAST, configure the [Datadog SDK][9]. Detailed instructions for both methods can be found in the [**Security > Code Security > Settings**][10] section. If you need additional help, contact [Datadog support][11]. diff --git a/content/en/security/code_security/iast/security_controls/_index.md b/content/en/security/code_security/iast/security_controls/_index.md index 17c1bcc9526..c39ea596ed4 100644 --- a/content/en/security/code_security/iast/security_controls/_index.md +++ b/content/en/security/code_security/iast/security_controls/_index.md @@ -65,7 +65,7 @@ The injection-related vulnerabilities are: ## Compatibility requirements -This feature is available starting from the following versions of each language's tracing library: +This feature is available starting from the following versions of each language's SDK: * **Java**: 1.45.0+ * **.NET**: 3.10.0+ diff --git a/content/en/security/code_security/iast/setup/_index.md b/content/en/security/code_security/iast/setup/_index.md index 3e5f3acbf61..5bcf33fe87d 100644 --- a/content/en/security/code_security/iast/setup/_index.md +++ b/content/en/security/code_security/iast/setup/_index.md @@ -11,9 +11,9 @@ aliases: Before setting up Runtime Code Analysis (IAST), 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. **Supported Tracing Library:** The Datadog Tracing Library 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. +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. -## Using Datadog Tracing Libraries +## Using Datadog SDKs Select your application language for details on how to enable Runtime Code Analysis (IAST) for your language and infrastructure types. @@ -25,7 +25,7 @@ You can detect code-level vulnerabilities and monitor application security in Ja Follow these steps to enable Runtime Code Analysis (IAST) in your service: 1. [Update your Datadog Agent][6] to at least version 7.41.1. -2. Update your Datadog Tracing Library to at least the minimum version needed to turn on Runtime Code Analysis (IAST). For details, see the **Compatibility Requirements** below. +2. Update your Datadog SDK to at least the minimum version needed to turn on Runtime Code Analysis (IAST). For details, see the **Compatibility Requirements** below. 3. Add the `DD_IAST_ENABLED=true` environment variable to your application configuration. From the command line: @@ -131,7 +131,7 @@ You can detect code-level vulnerabilities and monitor application security in .N Follow these steps to enable Runtime Code Analysis (IAST) in your service: 1. [Update your Datadog Agent][3] to at least version 7.41.1. -2. Update your Datadog Tracing Library to at least the minimum version needed to turn on Runtime Code Analysis (IAST). For details, see the **Compatibility Requirements** below. +2. Update your Datadog SDK to at least the minimum version needed to turn on Runtime Code Analysis (IAST). For details, see the **Compatibility Requirements** below. 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 @@ -259,10 +259,10 @@ You can detect code-level vulnerabilities and monitor application security in No Follow these steps to enable Runtime Code Analysis (IAST) in your service: 1. [Update your Datadog Agent][4] to at least version 7.41.1. -2. Update your Datadog Tracing Library to at least the minimum version needed to turn on Runtime Code Analysis (IAST). For details, see the **Compatibility Requirements** below. +2. Update your Datadog SDK to at least the minimum version needed to turn on Runtime Code Analysis (IAST). For details, see the **Compatibility Requirements** below. 3. Add the `DD_IAST_ENABLED=true` environment variable to your application configuration. - If you initialize the APM library on the command line using the `--require` option to Node.js: + If you initialize the Datadog SDK on the command line using the `--require` option to Node.js: ```shell node --require dd-trace/init app.js @@ -346,7 +346,7 @@ You can detect code-level vulnerabilities and monitor application security in Py Follow these steps to enable Runtime Code Analysis (IAST) in your service: 1. [Update your Datadog Agent][6] to at least version 7.41.1. -2. Update your Datadog Tracing Library to at least the minimum version needed to turn on Runtime Code Analysis (IAST). For details, see the **Compatibility Requirements** below. +2. Update your Datadog SDK to at least the minimum version needed to turn on Runtime Code Analysis (IAST). For details, see the **Compatibility Requirements** below. 3. Add the `DD_IAST_ENABLED=true` environment variable to your application configuration. From the command line: @@ -454,14 +454,14 @@ If you need additional assistance, contact [Datadog support][5]. ## Compatibility Requirements -The following code security capabilities are supported relative to each language's tracing library: +The following code security capabilities are supported relative to each language's SDK: | Code Security capability | Java | .NET | Node.js | Python | Go | Ruby | PHP | |-----------------------------------------------|---------|----------|------------|-------------|----------------|---------------|---------------| | 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 Datadog's tracing library. 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 Code Security capabilities. Select your application language for details about framework compatibility and feature support. diff --git a/content/en/security/code_security/iast/setup/compatibility/_index.md b/content/en/security/code_security/iast/setup/compatibility/_index.md index 0c485e2a7ad..376898fba4f 100644 --- a/content/en/security/code_security/iast/setup/compatibility/_index.md +++ b/content/en/security/code_security/iast/setup/compatibility/_index.md @@ -10,7 +10,7 @@ further_reading: text: "How App and API Protection Works in Datadog" --- -The following capabilities are supported relative to each language's tracing library: +The following capabilities are supported relative to each language's SDK: | Capability | Java | .NET | Node.js | Python | Go | Ruby | PHP | |-----------------------------------------------|---------|----------|----------------|---------------|-----------------|---------------|---------------| diff --git a/content/en/security/code_security/iast/setup/dotnet.md b/content/en/security/code_security/iast/setup/dotnet.md index db137c99c2d..e9530f1222a 100644 --- a/content/en/security/code_security/iast/setup/dotnet.md +++ b/content/en/security/code_security/iast/setup/dotnet.md @@ -29,7 +29,7 @@ You can detect code-level vulnerabilities and monitor application security in .N Follow these steps to enable Code Security in your service: 1. [Update your Datadog Agent][3] to at least version 7.41.1. -2. Update your Datadog Tracing Library 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 Code Security. 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 diff --git a/content/en/security/code_security/iast/setup/java.md b/content/en/security/code_security/iast/setup/java.md index 4823fda57fe..7782e6b2a20 100644 --- a/content/en/security/code_security/iast/setup/java.md +++ b/content/en/security/code_security/iast/setup/java.md @@ -29,7 +29,7 @@ You can detect code-level vulnerabilities and monitor application security in Ja Follow these steps to enable Code Security in your service: 1. [Update your Datadog Agent][6] to at least version 7.41.1. -2. Update your Datadog Tracing Library 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 Code Security. For details, see [Library Compatibility][3] page. 3. Add the `DD_IAST_ENABLED=true` environment variable to your application configuration. From the command line: diff --git a/content/en/security/code_security/iast/setup/nodejs.md b/content/en/security/code_security/iast/setup/nodejs.md index b8dab1afded..3a79ea383a2 100644 --- a/content/en/security/code_security/iast/setup/nodejs.md +++ b/content/en/security/code_security/iast/setup/nodejs.md @@ -29,10 +29,10 @@ You can detect code-level vulnerabilities and monitor application security in No Follow these steps to enable Code Security in your service: 1. [Update your Datadog Agent][4] to at least version 7.41.1. -2. Update your Datadog Tracing Library 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 Code Security. For details, see [Library Compatibility][3] page. 3. Add the `DD_IAST_ENABLED=true` environment variable to your application configuration. - If you initialize the APM library on the command line using the `--require` option to Node.js: + If you initialize the Datadog SDK on the command line using the `--require` option to Node.js: ```shell node --require dd-trace/init app.js @@ -137,7 +137,7 @@ To enable IAST during bundling, set the `DD_IAST_ENABLED` environment variable: DD_IAST_ENABLED=true node esbuild/esbuilder.js ``` -Because the tracer uses native modules, you must list them in `external` and ship a `node_modules` directory alongside the bundled app. Native modules used by `dd-trace` are published under the `@datadog/*` scope. +Because the SDK uses native modules, you must list them in `external` and ship a `node_modules` directory alongside the bundled app. Native modules used by `dd-trace` are published under the `@datadog/*` scope. To generate a minimal `node_modules` directory that contains only the required native modules and their dependencies: diff --git a/content/en/security/code_security/iast/setup/python.md b/content/en/security/code_security/iast/setup/python.md index 61783f2feaf..797ec5a00cb 100644 --- a/content/en/security/code_security/iast/setup/python.md +++ b/content/en/security/code_security/iast/setup/python.md @@ -28,7 +28,7 @@ NOTE: Code-Level Vulnerability detection in Python is in Preview. Follow these steps to enable Code Security in your service: 1. [Update your Datadog Agent][6] to at least version 7.41.1. -2. Update your Datadog Tracing Library 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 Code Security. For details, see [Library Compatibility][3] page. 3. Add the `DD_IAST_ENABLED=true` environment variable to your application configuration. From the command line: diff --git a/content/en/security/code_security/software_composition_analysis/library_inventory.md b/content/en/security/code_security/software_composition_analysis/library_inventory.md index d9cb7a4f7ac..48809ecbd03 100644 --- a/content/en/security/code_security/software_composition_analysis/library_inventory.md +++ b/content/en/security/code_security/software_composition_analysis/library_inventory.md @@ -27,7 +27,7 @@ Static data updates on every repository scan. The **Runtime** view lists only the libraries actively used by your services in production or other monitored environments, as detected by **Runtime SCA**. -Runtime SCA observes loaded dependencies through the Datadog tracing library, enabling you to: +Runtime SCA observes loaded dependencies through the Datadog SDK, enabling you to: * Prioritize vulnerabilities in libraries that are actually executed * Reduce noise by filtering out unused dependencies diff --git a/content/en/security/code_security/software_composition_analysis/setup_runtime/_index.md b/content/en/security/code_security/software_composition_analysis/setup_runtime/_index.md index da27b091273..286c7c0c218 100644 --- a/content/en/security/code_security/software_composition_analysis/setup_runtime/_index.md +++ b/content/en/security/code_security/software_composition_analysis/setup_runtime/_index.md @@ -11,7 +11,7 @@ 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. -3. **Supported Tracing Library:** The Datadog Tracing Library 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 for each AAP product. +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 for each AAP product. ## Software Composition Analysis enablement types @@ -24,9 +24,9 @@ You can enable runtime Software Composition Analysis (SCA) in-app through [**Sec 3. Check the services where you want to identify library vulnerabilities, and select **Bulk Actions**. 4. Click **Activate Runtime Software Composition Analysis (SCA)**. -### Datadog tracing library configuration +### Datadog SDK configuration -Add an environment variable or a new argument to your Datadog Tracing Library configuration. +Add an environment variable or a new argument to your Datadog SDK configuration. By following these steps, you will successfully set up Software Composition Analysis for your application, ensuring comprehensive monitoring and identification of vulnerabilities in open source libraries used by your applications or services. diff --git a/content/en/security/code_security/software_composition_analysis/setup_runtime/compatibility/_index.md b/content/en/security/code_security/software_composition_analysis/setup_runtime/compatibility/_index.md index 8abae5559d3..29d5aa4e8b2 100644 --- a/content/en/security/code_security/software_composition_analysis/setup_runtime/compatibility/_index.md +++ b/content/en/security/code_security/software_composition_analysis/setup_runtime/compatibility/_index.md @@ -5,13 +5,13 @@ aliases: - /security/application_security/software_composition_analysis/setup/compatibility/ --- -The following capabilities are supported relative to each language's tracing library: +The following capabilities are supported relative to each language's SDK: | Code Security Capability | Java | .NET | Node.js | Python | Go | Ruby | PHP | |------------------------------------------------|---------|----------|--------------------------------------------------|---------------|-----------------|---------------|---------------| | 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 Datadog's tracing library. 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 Code Security capabilities. Select your application language for details about framework compatibility and feature support. diff --git a/content/en/security/code_security/software_composition_analysis/setup_runtime/compatibility/go.md b/content/en/security/code_security/software_composition_analysis/setup_runtime/compatibility/go.md index 66aeca8345b..19d202892af 100644 --- a/content/en/security/code_security/software_composition_analysis/setup_runtime/compatibility/go.md +++ b/content/en/security/code_security/software_composition_analysis/setup_runtime/compatibility/go.md @@ -27,9 +27,9 @@ The following code security capabilities are supported in the Go library, for th ### Supported Go versions -The Datadog Go Tracing library is open source. View the [GitHub repository][2] for more information. +The Datadog Go SDK is open source. View the [GitHub repository][2] for more information. -The Datadog Go Tracing Library has a [version support policy][3] defined for Go versions. The two latest releases of Go are fully supported, while the third newest release is considered in [maintenance][4]. Older versions may function, but no support is provided by default. For special requests, [contact support][5]. +The Datadog Go SDK has a [version support policy][3] defined for Go versions. The two latest releases of Go are fully supported, while the third newest release is considered in [maintenance][4]. Older versions may function, but no support is provided by default. For special requests, [contact support][5]. You must be running Datadog Agent v5.21.1+ diff --git a/content/en/security/code_security/software_composition_analysis/setup_runtime/compatibility/java.md b/content/en/security/code_security/software_composition_analysis/setup_runtime/compatibility/java.md index 25cc7e17fb3..af3511cf91c 100644 --- a/content/en/security/code_security/software_composition_analysis/setup_runtime/compatibility/java.md +++ b/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 Datadog's tracing library. 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 Code Security capabilities. ### Supported deployment types | Type | Runtime Software Composition Analysis (SCA) | Runtime Code Analysis (IAST) | diff --git a/content/en/security/code_security/troubleshooting/_index.md b/content/en/security/code_security/troubleshooting/_index.md index 23293cb5923..fb77a8c7616 100644 --- a/content/en/security/code_security/troubleshooting/_index.md +++ b/content/en/security/code_security/troubleshooting/_index.md @@ -203,7 +203,7 @@ Runtime application security data is sent with APM traces. See [APM troubleshoot ### Confirm tracer versions are updated -See the Application Security product set up documentation to validate you you are using the right version of the tracer. These minimum versions are required to start sending telemetry data that includes library information. +See the Application Security product set up documentation to validate you 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/content/en/serverless/_index.md b/content/en/serverless/_index.md index 9e261c056b8..b79bbfa7127 100644 --- a/content/en/serverless/_index.md +++ b/content/en/serverless/_index.md @@ -50,7 +50,7 @@ Datadog provides solutions for monitoring [AWS Lambda](#aws-lambda), [Azure App You can send [custom metrics][4] from a Lambda function by generating metrics from logs and traces, using the Datadog Lambda Extension, or using the Datadog Forwarder Lambda. -With [Distributed Tracing][5], you can connect your serverless traces to metrics for a context-rich picture of your application's performance. The Datadog Python, Node.js, Ruby, Go, Java, and .NET tracing libraries support distributed tracing for AWS Lambda. +With [Distributed Tracing][5], you can connect your serverless traces to metrics for a context-rich picture of your application's performance. The Datadog Python, Node.js, Ruby, Go, Java, and .NET SDKs support distributed tracing for AWS Lambda. [Deployment Tracking][6] helps you to correlate serverless code, configuration, and deployment changes with metrics, traces, and logs from your functions for real-time insight into how these changes may affect the health and performance of your applications. diff --git a/content/en/serverless/aws_lambda/configuration.md b/content/en/serverless/aws_lambda/configuration.md index 0e6e9a20075..64db25f46a8 100644 --- a/content/en/serverless/aws_lambda/configuration.md +++ b/content/en/serverless/aws_lambda/configuration.md @@ -23,7 +23,7 @@ First, [install][1] Datadog Serverless Monitoring to begin collecting metrics, t - [Connect telemetry using tags](#connect-telemetry-using-tags) - [Collect the request and response payloads](#collect-the-request-and-response-payloads) - [Collect traces from non-Lambda resources](#collect-traces-from-non-lambda-resources) -- [Configure the Datadog tracer](#configure-the-datadog-tracer) +- [Configure the Datadog SDK](#configure-the-datadog-sdk) - [Select sampling rates for ingesting APM spans](#select-sampling-rates-for-ingesting-apm-spans) - [Filter or scrub sensitive information from traces](#filter-or-scrub-sensitive-information-from-traces) - [Enable/disable trace collection](#enabledisable-trace-collection) @@ -350,7 +350,7 @@ For a more granular approach, use these service-specific identifiers: For renaming downstream services, see `DD_SERVICE_MAPPING` in the [tracer's config documentation][45]. -## Configure the Datadog tracer +## 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]. @@ -715,9 +715,9 @@ Not all Lambda emulators support the AWS Lambda Telemetry API. To test your Lamb ## Instrument AWS Lambda with the OpenTelemetry API -The Datadog tracing library, which is included in the Datadog Lambda Extension upon installation, accepts the spans and traces generated by OpenTelemetry-instrumented code, processes the telemetry, and sends it to Datadog. +The Datadog SDK, which is included in the Datadog Lambda Extension upon installation, accepts the spans and traces generated by OpenTelemetry-instrumented code, processes the telemetry, and sends it to Datadog. -You can use this approach if, for example, your code has already been instrumented with the OpenTelemetry API. You may also use this approach if you want to instrument using vendor-agnostic code with the OpenTelemetry API while still gaining the benefits of using the Datadog tracing libraries. +You can use this approach if, for example, your code has already been instrumented with the OpenTelemetry API. You may also use this approach if you want to instrument using vendor-agnostic code with the OpenTelemetry API while still gaining the benefits of using the Datadog SDKs. To instrument AWS Lambda with the OpenTelemetry API, set the environment variable `DD_TRACE_OTEL_ENABLED` to `true`. See [Custom instrumentation with the OpenTelemetry API][48] for more details. @@ -763,7 +763,7 @@ export DD_BOTOCORE_DYNAMODB_TABLE_PRIMARY_KEYS='{ {{% /tab %}} {{< /tabs >}} -This enables DynamoDB `PutItem` calls to be instrumented with span pointers. Many DynamoDB API calls do not include the item's primary key fields as separate values, so they need to be provided to the tracer separately. The configuration above is structured as a dictionary (`dict`) or object keyed by the table names as strings (`str`). Each value is the set of primary key field names (as strings) for the associated table. The set can have exactly one or two elements, depending on the table's primary key schema. +This enables DynamoDB `PutItem` calls to be instrumented with span pointers. Many DynamoDB API calls do not include the item's primary key fields as separate values, so they need to be provided to the SDK separately. The configuration above is structured as a dictionary (`dict`) or object keyed by the table names as strings (`str`). Each value is the set of primary key field names (as strings) for the associated table. The set can have exactly one or two elements, depending on the table's primary key schema. ## Visualize and model AWS services by resource name diff --git a/content/en/serverless/aws_lambda/distributed_tracing.md b/content/en/serverless/aws_lambda/distributed_tracing.md index 2303cd72c4b..d54d3135592 100644 --- a/content/en/serverless/aws_lambda/distributed_tracing.md +++ b/content/en/serverless/aws_lambda/distributed_tracing.md @@ -32,13 +32,13 @@ further_reading: By connecting your serverless traces to metrics, Datadog provides a context-rich picture of your application's performance, allowing you to better troubleshoot performance issues given the distributed nature of serverless applications. -The Datadog Python, Node.js, Ruby, Go, Java, and .NET tracing libraries support distributed tracing for AWS Lambda. +The Datadog Python, Node.js, Ruby, Go, Java, and .NET SDKs support distributed tracing for AWS Lambda. ## Send traces from your serverless application {{< img src="serverless/serverless_tracing_installation_instructions.png" alt="Architecture diagram for tracing AWS Lambda with Datadog" >}} -The Datadog Python, Node.js, Ruby, Go, Java, and .NET tracing libraries support distributed tracing for AWS Lambda. You can install the tracer using the [installation instructions][5]. +The Datadog Python, Node.js, Ruby, Go, Java, and .NET SDKs support distributed tracing for AWS Lambda. You can install the SDK using the [installation instructions][5]. ### Runtime recommendations @@ -46,7 +46,7 @@ The Datadog Python, Node.js, Ruby, Go, Java, and .NET tracing libraries support #### Python and Node.js -The Datadog Lambda Library and tracing libraries for Python and Node.js support: +The Datadog Lambda Library and SDKs for Python and Node.js support: - Automatic correlation of Lambda logs and traces with trace ID and tag injection. - Installation without any code changes using Serverless Framework, AWS SAM and AWS CDK integrations. - Tracing HTTP requests invoking downstream Lambda functions or containers. @@ -64,50 +64,50 @@ The Datadog Lambda Library and tracing libraries for Python and Node.js support: - Step Functions - Tracing dozens of additional out-of-the-box [Python][3] and [Node.js][4] libraries. -For Python and Node.js serverless applications, Datadog recommends you [install Datadog's tracing libraries][5]. +For Python and Node.js serverless applications, Datadog recommends you [install Datadog SDKs][5]. *Looking to trace through serverless resources not listed above? [Open a feature request][7].* #### Ruby -The Datadog Lambda Library and tracing libraries for Ruby support: +The Datadog Lambda Library and SDKs for Ruby support: - Automatic correlation of Lambda logs and traces with trace ID and tag injection. - Tracing HTTP requests invoking downstream Lambda functions or containers. - Tracing dozens of additional out-of-the-box [Ruby][8] libraries. -You can trace your serverless functions in Datadog with [Datadog's tracing libraries][5]. +You can trace your serverless functions in Datadog with [Datadog SDKs][5]. *Looking to trace through serverless resources not listed above? [Open a feature request][7].* #### Go -The Datadog Lambda Library and tracing libraries for Go support: +The Datadog Lambda Library and SDKs for Go support: - Manual correlation of Lambda logs and traces with trace ID and tag injection. - Tracing HTTP requests invoking downstream Lambda functions or containers. - Tracing dozens of additional out-of-the-box [Go][9] libraries. -For Go serverless applications, Datadog recommends installing [Datadog's tracing libraries][5]. +For Go serverless applications, Datadog recommends installing [Datadog SDKs][5]. *Looking to trace through serverless resources not listed above? [Open a feature request][7].* #### Java -The Datadog Lambda Library and tracing libraries for Java support: +The Datadog Lambda Library and SDKs for Java support: - Correlation of Lambda logs and traces with trace ID and tag injection. See [Connecting Java logs and traces][10] for more details. - Tracing HTTP requests invoking downstream Lambda functions or containers. - Tracing dozens of additional out-of-the-box [Java][11] libraries. -For Java serverless applications, Datadog recommends [installing Datadog's tracing libraries][5]. +For Java serverless applications, Datadog recommends [installing Datadog SDKs][5]. -*Have feedback on the Datadog's tracing libraries for Java Lambda functions? Make sure to check out discussions going on in the [#serverless][12] channel in the [Datadog Slack community][13].* +*Have feedback on the Datadog SDKs for Java Lambda functions? Make sure to check out discussions going on in the [#serverless][12] channel in the [Datadog Slack community][13].* #### .NET -The tracing library for .NET supports: +The SDK for .NET supports: - Tracing HTTP requests invoking downstream Lambda functions or containers. - Tracing dozens of additional out-of-the-box [.NET][14] libraries. -For .NET serverless applications, Datadog recommends [installing Datadog's tracing libraries][5]. +For .NET serverless applications, Datadog recommends [installing Datadog SDKs][5]. Learn more about [tracing through .NET Azure serverless applications][15]. @@ -154,7 +154,7 @@ For [S3 Change Notifications][28], Span Auto-linking supports the following oper ## Hybrid environments -If you have installed Datadog's tracing libraries (`dd-trace`) on both your Lambda functions and hosts, your traces automatically show you the complete picture of requests that cross infrastructure boundaries, whether it be AWS Lambda, containers, on-prem hosts, or managed services. +If you have installed Datadog SDKs (`dd-trace`) on both your Lambda functions and hosts, your traces automatically show you the complete picture of requests that cross infrastructure boundaries, whether it be AWS Lambda, containers, on-prem hosts, or managed services. If `dd-trace` is installed on your hosts with the Datadog Agent, and your serverless functions are traced with AWS X-Ray, trace merging is required to see a single, connected trace across your infrastructure. See the [Serverless Trace Merging][6] documentation to learn more about merging traces from `dd-trace` and AWS X-Ray. @@ -170,13 +170,13 @@ 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 tracing library to use, read about [choosing your tracing library][17]. +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]. 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 AWS managed services such as AppSync and Step Functions, 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 tracing library. Learn more about [choosing your tracing library][17]. +**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]. You can find setup instructions for each of the above use cases below: @@ -196,8 +196,8 @@ Both the AWS X-Ray SDK and Datadog APM client libraries (`dd-trace`) add metadat ### Tracing across AWS Lambda and hosts -#### Context propagation with the Datadog tracing libraries -If you have installed Datadog's tracing libraries (`dd-trace`) on both your Lambda functions and hosts, your traces will automatically show you the complete picture of requests that cross infrastructure boundaries, whether it be AWS Lambda, containers, on-prem hosts, or managed services. +#### Context propagation with the Datadog SDKs +If you have installed Datadog SDKs (`dd-trace`) on both your Lambda functions and hosts, your traces will automatically show you the complete picture of requests that cross infrastructure boundaries, whether it be AWS Lambda, containers, on-prem hosts, or managed services. #### Context propagation with the X-Ray integration If `dd-trace` is installed on your hosts with the Datadog Agent, and your Node.js or Python serverless functions are traced with AWS X-Ray, your setup should be similar to the following: @@ -217,7 +217,7 @@ Then, for X-Ray and Datadog APM traces to appear in the same flame graph, all se ### Required setup -Additional instrumentation is sometimes required to see a single, connected trace in Node and Python serverless applications asynchronously triggering Lambda functions. If you are just getting started with monitoring serverless applications in Datadog, [follow our main installation steps][21] and [read this page on choosing your tracing library][22]. Once you are sending traces from your Lambda functions to Datadog using the [Datadog Lambda Library][23], you may want to follow these steps to connect traces between two Lambda functions in cases such as: +Additional instrumentation is sometimes required to see a single, connected trace in Node and Python serverless applications asynchronously triggering Lambda functions. If you are just getting started with monitoring serverless applications in Datadog, [follow our main installation steps][21] and [read this page on choosing your SDK][22]. Once you are sending traces from your Lambda functions to Datadog using the [Datadog Lambda Library][23], you may want to follow these steps to connect traces between two Lambda functions in cases such as: - Triggering Lambda functions via Step Functions - Invoking Lambda functions via non-HTTP protocols such as MQTT diff --git a/content/en/serverless/aws_lambda/instrumentation/_index.md b/content/en/serverless/aws_lambda/instrumentation/_index.md index 0b10ee3d71c..b5ff73e4243 100644 --- a/content/en/serverless/aws_lambda/instrumentation/_index.md +++ b/content/en/serverless/aws_lambda/instrumentation/_index.md @@ -15,7 +15,7 @@ further_reading: ## Overview -Instrument your AWS Lambda applications with a Datadog Lambda Extension to collect traces, enhanced metrics, and custom metrics. The Datadog Lambda Extension is analogous to using the Datadog Agent and Datadog tracing libraries for host-based infrastructure and applications. +Instrument your AWS Lambda applications with a Datadog Lambda Extension to collect traces, enhanced metrics, and custom metrics. The Datadog Lambda Extension is analogous to using the Datadog Agent and Datadog SDKs for host-based infrastructure and applications. {{< img src="serverless/serverless_tracing_installation_instructions.png" alt="A diagram that shows how Datadog receives telemetry from your instrumented AWS Lambda application. Your Lambda application, instrumented with a Datadog Lambda Library, sends logs, traces, enhanced metrics, and custom metrics to the Datadog Lambda Extension, which then pushes this data to Datadog." style="width:100%;" >}} diff --git a/content/en/serverless/aws_lambda/instrumentation/dotnet.md b/content/en/serverless/aws_lambda/instrumentation/dotnet.md index fc60b675d47..03f4fb9cc24 100644 --- a/content/en/serverless/aws_lambda/instrumentation/dotnet.md +++ b/content/en/serverless/aws_lambda/instrumentation/dotnet.md @@ -319,7 +319,7 @@ module "lambda-datadog" { ## Add custom spans -When using the [Datadog Lambda tracing layer for .NET][9], ensure that a second version of the .NET tracer is not also packaged with your application code. Add the `ExcludeAssets` instruction to ensure this extra tracer is excluded. +When using the [Datadog Lambda tracing layer for .NET][9], ensure that a second version of the .NET SDK is not also packaged with your application code. Add the `ExcludeAssets` instruction to ensure this extra tracer is excluded. ```xml
-Path to the directory containing the .NET tracing libraries.
+Path to the directory containing the Datadog .NET SDK.
`CORECLR_ENABLE_PROFILING` : **Value**: `1`
@@ -484,7 +484,7 @@ To enable the Continuous Profiler, set the environment variable `DD_PROFILING_EN ## Troubleshooting -If you are not receiving traces or custom metric data as expected, enable agent debug logging by setting `DD_LOG_LEVEL` in the sidecar configuration options. For tracer debugging set `DD_TRACE_DEBUG` to true. This generates logs additional debug logs for the sidecar and tracing library. +If you are not receiving traces or custom metric data as expected, enable agent debug logging by setting `DD_LOG_LEVEL` in the sidecar configuration options. For tracer debugging set `DD_TRACE_DEBUG` to true. This generates logs additional debug logs for the sidecar and SDK. Be sure to enable **App Service logs** to receive debugging logs. diff --git a/content/en/serverless/azure_app_service/linux_container.md b/content/en/serverless/azure_app_service/linux_container.md index 003d5ffde54..01e6cfb8726 100644 --- a/content/en/serverless/azure_app_service/linux_container.md +++ b/content/en/serverless/azure_app_service/linux_container.md @@ -35,7 +35,7 @@ If you haven't already, install the [Datadog-Azure integration][3] to collect me Instrument your main application with the `dd-trace-js` library. See [Tracing Node.js applications][101] for instructions. #### Metrics -Custom metrics are also collected through the tracer. See the [code examples][102]. +Custom metrics are also collected through the SDK. See the [code examples][102]. #### Logs The Datadog sidecar uses file tailing to collect logs. Datadog recommends writing application logs to `/home/LogFiles/` because this directory is persisted across restarts. @@ -54,7 +54,7 @@ To set up logging in your application, see [Node.js Log Collection][103]. To set Instrument your main application with the `dd-trace-py` library. See [Tracing Python applications][201] for instructions. #### Metrics -Custom metrics are also collected through the tracer. See the [code examples][202]. +Custom metrics are also collected through the SDK. See the [code examples][202]. #### Logs The Datadog sidecar uses file tailing to collect logs. Datadog recommends writing application logs to `/home/LogFiles/` because this directory is persisted across restarts. @@ -73,7 +73,7 @@ To set up logging in your application, see [Node.js Log Collection][203]. To set Instrument your main application with the `dd-trace-java` library. See [Tracing Java applications][301] for instructions. #### Metrics -Custom metrics are also collected through the tracer. See the [code examples][302]. +Custom metrics are also collected through the SDK. See the [code examples][302]. #### Logs The Datadog sidecar uses file tailing to collect logs. Datadog recommends writing application logs to `/home/LogFiles/` because this directory is persisted across restarts. @@ -91,7 +91,7 @@ To set up logging in your application, see [Node.js Log Collection][303]. To set #### Tracing Instrument your main application with the `dd-trace-dotnet` library. -1. Add the following lines to the Dockerfile for your main application. This installs and configures the Datadog tracer within your application container. +1. Add the following lines to the Dockerfile for your main application. This installs and configures the Datadog SDK within your application container. {{< code-block lang="dockerfile" >}} RUN mkdir -p /datadog/tracer RUN mkdir -p /home/LogFiles/dotnet @@ -140,7 +140,7 @@ ENTRYPOINT ["dotnet", "
A sample application is available on GitHub.
-1. **Install the Datadog .NET tracer** in your Dockerfile.
+1. **Install the Datadog .NET SDK** in your Dockerfile.
Because GitHub requests are rate limited, you must pass a GitHub token saved in the environment variable `GITHUB_TOKEN` as a [Docker build secret][1] `--secret id=github-token,env=GITHUB_TOKEN`.
diff --git a/content/en/serverless/google_cloud_run/containers/in_container/go.md b/content/en/serverless/google_cloud_run/containers/in_container/go.md
index 96aabb85a20..8cc7e91784d 100644
--- a/content/en/serverless/google_cloud_run/containers/in_container/go.md
+++ b/content/en/serverless/google_cloud_run/containers/in_container/go.md
@@ -18,15 +18,15 @@ further_reading:
A sample application is available on GitHub.
-1. **Install the Datadog Go tracer**.
+1. **Install the Datadog Go SDK**.
- 1. In your main application, add the tracing library from `dd-trace-go`.
+ 1. In your main application, add the SDK from `dd-trace-go`.
{{< code-block lang="shell" disable_copy="false" >}}
go get github.com/DataDog/dd-trace-go/v2/ddtrace/tracer
{{< /code-block >}}
- 2. Add the following to your application code to initialize the tracer:
+ 2. Add the following to your application code to initialize the SDK:
{{< code-block lang="go" disable_copy="false" >}}
tracer.Start()
defer tracer.Stop()
diff --git a/content/en/serverless/google_cloud_run/containers/in_container/java.md b/content/en/serverless/google_cloud_run/containers/in_container/java.md
index dc42a428a0e..2691938d45f 100644
--- a/content/en/serverless/google_cloud_run/containers/in_container/java.md
+++ b/content/en/serverless/google_cloud_run/containers/in_container/java.md
@@ -18,16 +18,16 @@ further_reading:
A sample application is available on GitHub.
-1. **Install the Datadog Java tracer**.
+1. **Install the Datadog Java SDK**.
- 1. Add the Datadog Java tracer to your Dockerfile:
+ 1. Add the Datadog Java SDK to your Dockerfile:
{{< code-block lang="dockerfile" filename="Dockerfile" disable_copy="false" collapsible="true" >}}
ADD 'https://dtdg.co/latest-java-tracer' agent.jar
ENV JAVA_TOOL_OPTIONS="-javaagent:agent.jar"
{{< /code-block >}}
- 2. Add the tracer artifacts.
+ 2. Add the SDK artifacts.
{{< tabs >}}
{{% tab "Maven" %}}
{{< code-block lang="xml" disable_copy="false" >}}
diff --git a/content/en/serverless/google_cloud_run/containers/in_container/nodejs.md b/content/en/serverless/google_cloud_run/containers/in_container/nodejs.md
index 1fa6d0ce518..bff6d73a43c 100644
--- a/content/en/serverless/google_cloud_run/containers/in_container/nodejs.md
+++ b/content/en/serverless/google_cloud_run/containers/in_container/nodejs.md
@@ -18,7 +18,7 @@ further_reading:
A sample application is available on GitHub.
-1. **Install the Datadog Node.js tracer**.
+1. **Install the Datadog Node.js SDK**.
1. In your main application, install the `dd-trace` package.
diff --git a/content/en/serverless/google_cloud_run/containers/in_container/php.md b/content/en/serverless/google_cloud_run/containers/in_container/php.md
index 651c2a28bc3..a5f69a6ee28 100644
--- a/content/en/serverless/google_cloud_run/containers/in_container/php.md
+++ b/content/en/serverless/google_cloud_run/containers/in_container/php.md
@@ -18,7 +18,7 @@ further_reading:
A sample application is available on GitHub.
-1. **Install the Datadog PHP tracer** in your Dockerfile.
+1. **Install the Datadog PHP SDK** in your Dockerfile.
{{< code-block lang="dockerfile" filename="Dockerfile" disable_copy="false" collapsible="true" >}}
RUN curl -LO https://github.com/DataDog/dd-trace-php/releases/latest/download/datadog-setup.php \
diff --git a/content/en/serverless/google_cloud_run/containers/in_container/python.md b/content/en/serverless/google_cloud_run/containers/in_container/python.md
index 7c2f791c6f5..0620c511d5f 100644
--- a/content/en/serverless/google_cloud_run/containers/in_container/python.md
+++ b/content/en/serverless/google_cloud_run/containers/in_container/python.md
@@ -18,14 +18,14 @@ further_reading:
A sample application is available on GitHub.
-1. **Install the Datadog Python tracer**.
+1. **Install the Datadog Python SDK**.
Add `ddtrace` to your `requirements.txt` or `pyproject.toml`. You can find the latest version on [PyPI][1]:
{{< code-block lang="text" filename="requirements.txt" disable_copy="false" collapsible="true" >}}
ddtrace==A sample application is available on GitHub.
-1. **Install the Datadog Ruby tracer**.
+1. **Install the Datadog Ruby SDK**.
Add the `datadog` gem to your Gemfile:
{{< code-block lang="gemfile" disable_copy="false" >}}
@@ -26,7 +26,7 @@ source 'https://rubygems.org'
gem 'datadog'
{{< /code-block >}}
- See [Tracing Ruby applications][1] for additional information on how to configure the tracer and enable auto instrumentation.
+ See [Tracing Ruby applications][1] for additional information on how to configure the SDK and enable auto instrumentation.
2. **Install serverless-init**.
diff --git a/content/en/serverless/google_cloud_run/containers/sidecar/dotnet.md b/content/en/serverless/google_cloud_run/containers/sidecar/dotnet.md
index 045a9bb6d8c..24fe7304324 100644
--- a/content/en/serverless/google_cloud_run/containers/sidecar/dotnet.md
+++ b/content/en/serverless/google_cloud_run/containers/sidecar/dotnet.md
@@ -16,7 +16,7 @@ further_reading:
## Setup
-1. **Install the Datadog .NET tracer** in your Dockerfile.
+1. **Install the Datadog .NET SDK** in your Dockerfile.
{{< tabs >}}
{{% tab "Standard Linux (glibc)" %}}
diff --git a/content/en/serverless/google_cloud_run/containers/sidecar/go.md b/content/en/serverless/google_cloud_run/containers/sidecar/go.md
index 8389283f16b..c7512d52d03 100644
--- a/content/en/serverless/google_cloud_run/containers/sidecar/go.md
+++ b/content/en/serverless/google_cloud_run/containers/sidecar/go.md
@@ -16,15 +16,15 @@ further_reading:
## Setup
-1. **Install the Datadog Go tracer**.
+1. **Install the Datadog Go SDK**.
- 1. In your main application, add the tracing library from `dd-trace-go`.
+ 1. In your main application, add the SDK from `dd-trace-go`.
{{< code-block lang="shell" disable_copy="false" >}}
go get github.com/DataDog/dd-trace-go/v2/ddtrace/tracer
{{< /code-block >}}
- 2. Add the following to your application code to initialize the tracer:
+ 2. Add the following to your application code to initialize the SDK:
{{< code-block lang="go" disable_copy="false" >}}
tracer.Start()
defer tracer.Stop()
diff --git a/content/en/serverless/google_cloud_run/containers/sidecar/java.md b/content/en/serverless/google_cloud_run/containers/sidecar/java.md
index 9eb0cfe6598..6a672182382 100644
--- a/content/en/serverless/google_cloud_run/containers/sidecar/java.md
+++ b/content/en/serverless/google_cloud_run/containers/sidecar/java.md
@@ -16,16 +16,16 @@ further_reading:
## Setup
-1. **Install the Datadog Java tracer**.
+1. **Install the Datadog Java SDK**.
- 1. Add the Datadog Java tracer to your Dockerfile:
+ 1. Add the Datadog Java SDK to your Dockerfile:
{{< code-block lang="dockerfile" filename="Dockerfile" disable_copy="false" collapsible="true" >}}
ADD 'https://dtdg.co/latest-java-tracer' agent.jar
ENV JAVA_TOOL_OPTIONS="-javaagent:agent.jar"
{{< /code-block >}}
- 2. Add the tracer artifacts.
+ 2. Add the SDK artifacts.
{{< tabs >}}
{{% tab "Maven" %}}
{{< code-block lang="xml" disable_copy="false" >}}
diff --git a/content/en/serverless/google_cloud_run/containers/sidecar/nodejs.md b/content/en/serverless/google_cloud_run/containers/sidecar/nodejs.md
index 46d270cabb6..dc9c7cc94f8 100644
--- a/content/en/serverless/google_cloud_run/containers/sidecar/nodejs.md
+++ b/content/en/serverless/google_cloud_run/containers/sidecar/nodejs.md
@@ -16,7 +16,7 @@ further_reading:
## Setup
-1. **Install the Datadog Node.js tracer**.
+1. **Install the Datadog Node.js SDK**.
1. In your main application, install the `dd-trace` package.
diff --git a/content/en/serverless/google_cloud_run/containers/sidecar/php.md b/content/en/serverless/google_cloud_run/containers/sidecar/php.md
index e74d2a8beb9..bfd87c5d08f 100644
--- a/content/en/serverless/google_cloud_run/containers/sidecar/php.md
+++ b/content/en/serverless/google_cloud_run/containers/sidecar/php.md
@@ -16,7 +16,7 @@ further_reading:
## Setup
-1. **Install the Datadog PHP tracer** in your Dockerfile.
+1. **Install the Datadog PHP SDK** in your Dockerfile.
{{< code-block lang="dockerfile" filename="Dockerfile" disable_copy="false" collapsible="true" >}}
RUN curl -LO https://github.com/DataDog/dd-trace-php/releases/latest/download/datadog-setup.php \
diff --git a/content/en/serverless/google_cloud_run/containers/sidecar/python.md b/content/en/serverless/google_cloud_run/containers/sidecar/python.md
index fb7650967ad..30d59a94e85 100644
--- a/content/en/serverless/google_cloud_run/containers/sidecar/python.md
+++ b/content/en/serverless/google_cloud_run/containers/sidecar/python.md
@@ -16,14 +16,14 @@ further_reading:
## Setup
-1. **Install the Datadog Python tracer**.
+1. **Install the Datadog Python SDK**.
Add `ddtrace` to your `requirements.txt` or `pyproject.toml`. You can find the latest version on [PyPI][1]:
{{< code-block lang="text" filename="requirements.txt" disable_copy="false" collapsible="true" >}}
ddtrace==
-Tracers always initiate traffic to Datadog. Sessions are never initiated from Datadog back to the tracers.
+Tracers always initiate traffic to Datadog. Sessions are never initiated from Datadog back to the SDKs.
## Destinations
-The network endpoints accessed by the tracers are dependent on the Datadog site.
+The network endpoints accessed by the SDKs are dependent on the Datadog site.
To see destinations based on your [Datadog site][1], click the `DATADOG SITE` selector on the right.
The following HTTP endpoints must be accessible from the host where your tests are executed:
diff --git a/content/en/tests/setup/dotnet.md b/content/en/tests/setup/dotnet.md
index 68bc21f34e3..1e1d4fff105 100644
--- a/content/en/tests/setup/dotnet.md
+++ b/content/en/tests/setup/dotnet.md
@@ -210,7 +210,7 @@ When code coverage is available, the Datadog Tracer (v2.31.0 or later) reports i
If you are using [Coverlet][10] to compute your code coverage, indicate the path to the report file in the `DD_CIVISIBILITY_EXTERNAL_CODE_COVERAGE_PATH` environment variable when running `dd-trace`. The report file must be in the OpenCover or Cobertura formats. Alternatively, you can enable the Datadog Tracer's built-in code coverage calculation with the `DD_CIVISIBILITY_CODE_COVERAGE_ENABLED=true` environment variable.
-**Note**: When using Test Impact Analysis, the tracer's built-in code coverage is enabled by default.
+**Note**: When using Test Impact Analysis, the SDK's built-in code coverage is enabled by default.
You can see the evolution of the test coverage in the **Coverage** tab of a test session.
diff --git a/content/en/tests/setup/java.md b/content/en/tests/setup/java.md
index adcfb878ee3..b596bde7475 100644
--- a/content/en/tests/setup/java.md
+++ b/content/en/tests/setup/java.md
@@ -77,11 +77,11 @@ Configuring the Datadog Java Tracer varies depending on your CI provider.
{{% /tab %}}
{{< /tabs >}}
-### Downloading tracer library
+### Downloading SDK
-You only need to download the tracer library once for each server.
+You only need to download the SDK once for each server.
-If the tracer library is already available locally on the server, you can proceed directly to running the tests.
+If the SDK is already available locally on the server, you can proceed directly to running the tests.
Declare `DD_TRACER_FOLDER` variable with the path to the folder where you want to store the downloaded tracer JAR:
@@ -89,20 +89,20 @@ Declare `DD_TRACER_FOLDER` variable with the path to the folder where you want t
export DD_TRACER_FOLDER=... // e.g. ~/.datadog
{{< /code-block >}}
-Run the command below to download the tracer JAR to the specified folder:
+Run the command below to download the SDK JAR to the specified folder:
{{< code-block lang="shell" >}}
wget -O $DD_TRACER_FOLDER/dd-java-agent.jar 'https://dtdg.co/latest-java-tracer'
{{< /code-block >}}
-You can run the `java -jar $DD_TRACER_FOLDER/dd-java-agent.jar` command to check the version of the tracer library.
+You can run the `java -jar $DD_TRACER_FOLDER/dd-java-agent.jar` command to check the version of the SDK.
### Running your tests
{{< tabs >}}
{{% tab "Maven" %}}
-Set the following environment variables to configure the tracer:
+Set the following environment variables to configure the SDK:
`DD_CIVISIBILITY_ENABLED=true` (Required)
: Enables the Test Optimization product.
@@ -117,7 +117,7 @@ Set the following environment variables to configure the tracer:
: Path to the folder where the downloaded Java Tracer is located.
`MAVEN_OPTS=-javaagent:$DD_TRACER_FOLDER/dd-java-agent.jar` (Required)
-: Injects the tracer into the Maven build process.
+: Injects the SDK into the Maven build process.
`DD_TEST_SESSION_NAME`
: Identifies a group of tests (for example: `unit-tests` or `integration-tests`).
@@ -127,7 +127,7 @@ Run your tests as you normally do (for example: `mvn test` or `mvn verify`).
{{% /tab %}}
{{% tab "Gradle" %}}
-Set the following environment variables to configure the tracer:
+Set the following environment variables to configure the SDK:
`DD_CIVISIBILITY_ENABLED=true` (Required)
: Enables the Test Optimization product.
@@ -142,14 +142,14 @@ Set the following environment variables to configure the tracer:
: Path to the folder where the downloaded Java Tracer is located.
`GRADLE_OPTS=-javaagent:$DD_TRACER_FOLDER/dd-java-agent.jar` (Required)
-: Injects the tracer into the Gradle launcher process.
+: Injects the SDK into the Gradle launcher process.
Run your tests as you normally do (for example: `./gradlew clean test`).
{{% /tab %}}
{{% tab "SBT" %}}
-Set the following environment variables to configure the tracer:
+Set the following environment variables to configure the SDK:
`DD_CIVISIBILITY_ENABLED=true` (Required)
: Enables the Test Optimization product.
@@ -167,14 +167,14 @@ Set the following environment variables to configure the tracer:
: Path to the folder where the downloaded Java Tracer is located.
`SBT_OPTS=-javaagent:$DD_TRACER_FOLDER/dd-java-agent.jar` (Required)
-: Injects the tracer into the JVMs that execute your tests.
+: Injects the SDK into the JVMs that execute your tests.
Run your tests as you normally do (for example: `sbt test`).
{{% /tab %}}
{{% tab "Other" %}}
-Set the following environment variables to configure the tracer:
+Set the following environment variables to configure the SDK:
`DD_CIVISIBILITY_ENABLED=true` (Required)
: Enables the Test Optimization product.
@@ -192,7 +192,7 @@ Set the following environment variables to configure the tracer:
: Path to the folder where the downloaded Java Tracer is located.
`JAVA_TOOL_OPTIONS=-javaagent:$DD_TRACER_FOLDER/dd-java-agent.jar` (Required)
-: Injects the tracer into the JVMs that execute your tests.
+: Injects the SDK into the JVMs that execute your tests.
Run your tests as you normally do.
@@ -203,7 +203,7 @@ Run your tests as you normally do.
Default configuration values work well in most cases.
-However, if there is a need to fine-tune the tracer's behavior, [Datadog Tracer configuration][3] options can be used.
+However, if there is a need to fine-tune the SDK's behavior, [Datadog Tracer configuration][3] options can be used.
### Collecting Git metadata
@@ -211,7 +211,7 @@ However, if there is a need to fine-tune the tracer's behavior, [Datadog Tracer
## Extensions
-The tracer exposes a set of APIs that can be used to extend its functionality programmatically.
+The SDK exposes a set of APIs that can be used to extend its functionality programmatically.
### Adding custom tags to tests
@@ -509,23 +509,23 @@ Datadog recommends using `DD_TEST_SESSION_NAME` if your test commands vary betwe
## Troubleshooting
-### The tests are not appearing in Datadog after enabling Test Optimization in the tracer
+### The tests are not appearing in Datadog after enabling Test Optimization in the SDK
-Verify that the tracer is injected into your build process by examining your build's logs.
+Verify that the SDK is injected into your build process by examining your build's logs.
If the injection is successful, you can see a line containing `DATADOG TRACER CONFIGURATION`.
-If the line is not there, make sure that the environment variables used to inject and configure the tracer are available to the build process.
+If the line is not there, make sure that the environment variables used to inject and configure the SDK are available to the build process.
A common mistake is to set the variables in a build step and run the tests in another build step. This approach may not work if the variables are not propagated between build steps.
-Ensure that you are using the latest version of the tracer.
+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).
-Ensure that the `dd.civisibility.enabled` property (or `DD_CIVISIBILITY_ENABLED` environment variable) is set to `true` in the tracer arguments.
+Ensure that the `dd.civisibility.enabled` property (or `DD_CIVISIBILITY_ENABLED` environment variable) is set to `true` in the SDK arguments.
Try running your build with tracer debug logging enabled by setting the `DD_TRACE_DEBUG` environment variable to `true`.
Check the build output for any errors that indicate tracer misconfiguration, such as an unset `DD_API_KEY` environment variable.
-### Tests or source code compilation fails when building a project with the tracer attached
+### 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.
@@ -545,11 +545,11 @@ If this is the case, you can disable plugin injection by adding `dd.civisibility
The plugin is optional, as it only serves to reduce the performance overhead.
-### Tests fail when building a project with the tracer attached
+### Tests fail when building a project with the SDK attached
-In some cases attaching the tracer can break tests, especially if they run asserts on the internal state of the JVM or instances of third-party libraries' classes.
+In some cases attaching the SDK can break tests, especially if they run asserts on the internal state of the JVM or instances of third-party libraries' classes.
-While the best approach is such cases is to update the tests, there is also a quicker option of disabling the tracer's third-party library integrations.
+While the best approach is such cases is to update the tests, there is also a quicker option of disabling the SDK's third-party library integrations.
The integrations provide additional insights into what happens in the tested code and are especially useful in integration tests, to monitor things like HTTP requests or database calls.
They are enabled by default.
diff --git a/content/en/tests/setup/javascript.md b/content/en/tests/setup/javascript.md
index 1983798bdf4..033ca4851cc 100644
--- a/content/en/tests/setup/javascript.md
+++ b/content/en/tests/setup/javascript.md
@@ -599,7 +599,7 @@ For more information, see [Code Coverage][6].
## Configuration settings
-The following is a list of the most important configuration settings that can be used with the tracer.
+The following is a list of the most important configuration settings that can be used with the SDK.
`test_session.name`
: Use it to identify a group of tests, such as `integration-tests`, `unit-tests` or `smoke-tests`.diff --git a/content/en/tests/setup/junit_xml.md b/content/en/tests/setup/junit_xml.md index 34566473359..6f3e5c0a297 100644 --- a/content/en/tests/setup/junit_xml.md +++ b/content/en/tests/setup/junit_xml.md @@ -27,11 +27,11 @@ further_reading: JUnit test report files are XML files that contain test execution information, such as test and suite names, pass or fail status, duration, and sometimes error logs. Although introduced by the [JUnit][1] testing framework, many other popular frameworks are able to output results using this format. -If your testing framework can generate JUnit XML test reports, you can use these as a lightweight alternative to [instrumenting your tests natively][2] using Datadog tracers. Test results imported from JUnit XML reports appear alongside test data reported by tracers. +If your testing framework can generate JUnit XML test reports, you can use these as a lightweight alternative to [instrumenting your tests natively][2] using Datadog SDKs. Test results imported from JUnit XML reports appear alongside test data reported by tracers. ## Compatibility -Supported Datadog tracing library: +Supported Datadog SDK: | Datadog Library | Version | |---|---| diff --git a/content/en/tests/setup/python.md b/content/en/tests/setup/python.md index 605e3adc08b..63762ef73d3 100644 --- a/content/en/tests/setup/python.md +++ b/content/en/tests/setup/python.md @@ -171,7 +171,7 @@ For additional configurations, see [Configuration Settings][1].
The Test Optimization manual testing API is in beta and subject to change.
-As of version `2.13.0`, the [Datadog Python tracer][1] provides the Test Optimization API (`ddtrace.ext.test_visibility`) to submit test optimization results as needed.
+As of version `2.13.0`, the [Datadog Python SDK][1] provides the Test Optimization API (`ddtrace.ext.test_visibility`) to submit test optimization results as needed.
#### API execution
@@ -378,7 +378,7 @@ For additional configurations, see [Configuration Settings][2].
## Configuration settings
-The following is a list of the most important configuration settings that can be used with the tracer, either in code or using environment variables:
+The following is a list of the most important configuration settings that can be used with the SDK, either in code or using environment variables:
`DD_TEST_SESSION_NAME`
: Identifies a group of tests, such as `integration-tests`, `unit-tests` or `smoke-tests`.diff --git a/content/en/tests/troubleshooting/_index.md b/content/en/tests/troubleshooting/_index.md index 6e9629535ca..804d8cad1a9 100644 --- a/content/en/tests/troubleshooting/_index.md +++ b/content/en/tests/troubleshooting/_index.md @@ -14,8 +14,8 @@ This page provides information to help you troubleshot issues with Test Optimiza 1. Go to the [**Tests**][3] page for the language you're instrumenting and check that the testing framework you are using is supported in the **Compatibility** section. 2. Check if you see any test results in the [**Test Runs**][4] section. If you do see results there, but not in [**Test Health**][5] when viewing the repositories list or an individual repository, Git information is missing. See [Data appears in Test Runs but not Test Health](#data-appears-in-test-runs-but-not-test-health) to troubleshoot it. -3. If you are reporting the data through the Datadog Agent, make sure there is [network connectivity][15] from your test-running host to the Agent's host and port. Run your tests with the appropriate Agent hostname set in the `DD_AGENT_HOST` and the appropriate port in `DD_TRACE_AGENT_PORT` environment variables. You can activate [debug mode][6] in the tracer to verify connectivity to the Agent. -4. If you are reporting the data directly to Datadog ("Agentless mode"), make sure there is [network connectivity][16] from the test-running hosts to Datadog's hosts. You can activate [debug mode][6] in the tracer to verify connectivity to Datadog. +3. If you are reporting the data through the Datadog Agent, make sure there is [network connectivity][15] from your test-running host to the Agent's host and port. Run your tests with the appropriate Agent hostname set in the `DD_AGENT_HOST` and the appropriate port in `DD_TRACE_AGENT_PORT` environment variables. You can activate [debug mode][6] in the SDK to verify connectivity to the Agent. +4. If you are reporting the data directly to Datadog ("Agentless mode"), make sure there is [network connectivity][16] from the test-running hosts to Datadog's hosts. You can activate [debug mode][6] in the SDK to verify connectivity to Datadog. 5. If you still don't see any results, [contact Support][2] for troubleshooting help. ## You are uploading JUnit test reports with `datadog-ci` but some or all tests are missing @@ -29,7 +29,7 @@ The following aspects make a JUnit test report incorrect: If you can see test results data in the **Test Runs** tab, but not in **Test Health** when viewing the repositories list or an individual repository, Git metadata (repository, commit, or branch) is probably missing. To confirm this is the case, open a test execution in the [**Test Runs**][4] section, and check that there is no `git.repository_url`, `git.commit.sha`, or `git.branch`. If these tags are not populated, nothing shows in repository sections of the [**Test Health**][5] page. -1. Tracers first use the environment variables, if any, set by the CI provider to collect Git information. See [Running tests inside a container][7] for a list of environment variables that the tracer attempts to read for each supported CI provider. At a minimum, this populates the repository, commit hash, and branch information. +1. Tracers first use the environment variables, if any, set by the CI provider to collect Git information. See [Running tests inside a container][7] for a list of environment variables that the SDK attempts to read for each supported CI provider. At a minimum, this populates the repository, commit hash, and branch information. 2. Next, tracers fetch Git metadata using the local `.git` folder, if present, by executing `git` commands. This populates all Git metadata fields, including commit message, author, and committer information. Ensure the `.git` folder is present and the `git` binary is installed and in `$PATH`. This information is used to populate attributes not detected in the previous step. 3. You can also provide Git information manually using environment variables, which override information detected by any of the previous steps. @@ -84,7 +84,7 @@ If you can see test results data in the **Test Runs** tab, but not in **Test Hea ### The total test time is empty If you cannot see the total test time, it is likely that test suite level visibility is not enabled. To confirm, check if your language supports test suite level visibility in [Supported features][14]. If test suite level visibility is supported, update your tracer to the latest version. -If you still don't see the total time after updating the tracer version, contact [Datadog support][2] for help. +If you still don't see the total time after updating the SDK version, contact [Datadog support][2] for help. ### The total test time is different than expected diff --git a/content/en/tracing/_index.md b/content/en/tracing/_index.md index bd0111bfbf9..bdf1be3303f 100644 --- a/content/en/tracing/_index.md +++ b/content/en/tracing/_index.md @@ -66,7 +66,7 @@ For an introduction to terminology used in Datadog APM, see [APM Terms and Conce 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]. -For setups that require more customization, Datadog supports custom instrumentation with Datadog tracing libraries 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 [Dynamic Instrumentation][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.
diff --git a/content/en/tracing/code_origin/_index.md b/content/en/tracing/code_origin/_index.md
index 8487e9670fc..849f09f367e 100644
--- a/content/en/tracing/code_origin/_index.md
+++ b/content/en/tracing/code_origin/_index.md
@@ -50,7 +50,7 @@ In Trace Explorer, select a span from an enabled service to see Code Origin deta
{{% tab "Java" %}}
-| Tracing Library Version | Frameworks |
+| SDK Version | Frameworks |
|---|---|
| 1.47.0+ | Spring Boot/Data, gRPC servers, Micronaut 4, Kafka consumers |
@@ -60,7 +60,7 @@ In Trace Explorer, select a span from an enabled service to see Code Origin deta
{{% tab "Python" %}}
-| Tracing Library Version | Frameworks |
+| SDK Version | Frameworks |
|---|---|
| 2.15.0+ | Django, Flask, Starlette, and derivatives |
@@ -68,7 +68,7 @@ In Trace Explorer, select a span from an enabled service to see Code Origin deta
{{% tab "Node.js" %}}
-| Tracing Library Version | Frameworks |
+| SDK Version | Frameworks |
|---|---|
| 4.49.0+ | Fastify |
| 5.54.0+ | Express |
@@ -79,7 +79,7 @@ In Trace Explorer, select a span from an enabled service to see Code Origin deta
{{% tab ".NET" %}}
-| Tracing Library Version | Frameworks |
+| SDK Version | Frameworks |
|---|---|
| 3.15.0+ | ASP.NET, ASP.NET Core |
@@ -87,7 +87,7 @@ In Trace Explorer, select a span from an enabled service to see Code Origin deta
{{% tab "PHP" %}}
-| Tracing Library Version | Frameworks |
+| SDK Version | Frameworks |
|---|---|
| 1.11.0+ | All supported web frameworks |
@@ -144,7 +144,7 @@ export DD_CODE_ORIGIN_FOR_SPANS_ENABLED=true
### Code Origin section is missing
-- Verify Code Origin is [enabled](#enable-code-origin) in your tracing library configuration.
+- Verify Code Origin is [enabled](#enable-code-origin) in your SDK configuration.
- Confirm that your service meets all [compatibility requirements](#compatibility-requirements) (that is, service language, supported frameworks, and minimum tracer version).
- For most services, Code Origin data is captured for [service entry spans][12] only. You can filter to "Service Entry Spans" in the [APM Trace Explorer][1].
diff --git a/content/en/tracing/configure_data_security/_index.md b/content/en/tracing/configure_data_security/_index.md
index 9b0118a544c..3f2934bd522 100644
--- a/content/en/tracing/configure_data_security/_index.md
+++ b/content/en/tracing/configure_data_security/_index.md
@@ -16,15 +16,15 @@ further_reading:
---
## Overview
-Datadog tracing libraries collect data from an instrumented application. That data is sent to Datadog as traces and it may contain sensitive data such as personally identifiable information (PII). If you are ingesting sensitive data as traces into Datadog, remediations can be added at ingestion with [Sensitive Data Scanner][12]. You can also configure the Datadog Agent or the tracing library to remediate sensitive data at collection before traces are sent to Datadog. Datadog's tools and policies comply with PCI v4.0. For more information, see [PCI DSS Compliance][14].
+Datadog SDKs collect data from an instrumented application. That data is sent to Datadog as traces and it may contain sensitive data such as personally identifiable information (PII). If you are ingesting sensitive data as traces into Datadog, remediations can be added at ingestion with [Sensitive Data Scanner][12]. You can also configure the Datadog Agent or the SDK to remediate sensitive data at collection before traces are sent to Datadog. Datadog's tools and policies comply with PCI v4.0. For more information, see [PCI DSS Compliance][14].
If the configurations described here do not cover your compliance requirements, reach out to [the Datadog support team][1].
### Personal information in trace data
-Datadog's APM tracing libraries collect relevant observability data about your applications. Because these libraries collect hundreds of unique attributes in trace data, this page describes categories of data, with a focus on attributes that may contain personal information about your employees and end-users.
+Datadog's Datadog SDKs collect relevant observability data about your applications. Because these libraries collect hundreds of unique attributes in trace data, this page describes categories of data, with a focus on attributes that may contain personal information about your employees and end-users.
-The table below describes the personal data categories collected by the automatic instrumentation provided by the tracing libraries, with some common examples listed.
+The table below describes the personal data categories collected by the automatic instrumentation provided by the SDKs, with some common examples listed.
| Category | Description |
|:--------------------|:-----------------------------------------------------------------------------------------------------------------------|
@@ -38,7 +38,7 @@ The table below describes the personal data categories collected by the automati
| URI userinfo | The userinfo subcomponent of the URI that may contain the user name. |
| Login ID | Can include an account/user ID, name, or email address. |
-The table below describes the default behavior of each language tracing library with regard to whether a data category is collected and whether it is obfuscated by default.
+The table below describes the default behavior of each language SDK with regard to whether a data category is collected and whether it is obfuscated by default.
{{% tabs %}}
@@ -245,7 +245,7 @@ The table below describes the default behavior of each language tracing library
{{% /tabs %}}
-If you use Datadog App and API Protection (AAP), the tracing libraries collect HTTP request data to help you understand the nature of a security trace. Datadog AAP automatically redacts certain data, and you can configure your own detection rules. Learn more about these defaults and configuration options in the Datadog AAP [data privacy][13] documentation.
+If you use Datadog App and API Protection (AAP), the SDKs collect HTTP request data to help you understand the nature of a security trace. Datadog AAP automatically redacts certain data, and you can configure your own detection rules. Learn more about these defaults and configuration options in the Datadog AAP [data privacy][13] documentation.
## Agent
@@ -636,7 +636,7 @@ If you are running in a containerized environment, set `DD_APM_IGNORE_RESOURCES`
### HTTP
-Datadog is standardizing [span tag semantics][3] across tracing libraries. Information from HTTP requests are added as span tags prefixed with `http.`. The libraries have the following configuration options to control sensitive data collected in HTTP spans.
+Datadog is standardizing [span tag semantics][3] across SDKs. Information from HTTP requests are added as span tags prefixed with `http.`. The libraries have the following configuration options to control sensitive data collected in HTTP spans.
#### Redact query strings
@@ -654,7 +654,7 @@ DD_TRACE_HEADER_TAGS=CASE-insensitive-Header:my-tag-name,User-ID:userId,My-Heade
### Processing
-Some tracing libraries provide an interface for processing spans to manually modify or remove sensitive data collected in traces:
+Some SDKs provide an interface for processing spans to manually modify or remove sensitive data collected in traces:
* Java: [TraceInterceptor interface][9]
* Ruby: [Processing Pipeline][10]
@@ -670,7 +670,7 @@ Instrumentation telemetry is not available for the {{< region-param key="dd_site
{{< /site-region >}}
-Datadog may gather environmental and diagnostic information about your tracing libraries for processing; this may include information about the host running an application, operating system, programming language and runtime, APM integrations used, and application dependencies. Additionally, Datadog may collect information such as diagnostic logs, crash dumps with obfuscated stack traces, and various system performance metrics.
+Datadog may gather environmental and diagnostic information about your SDKs for processing; this may include information about the host running an application, operating system, programming language and runtime, APM integrations used, and application dependencies. Additionally, Datadog may collect information such as diagnostic logs, crash dumps with obfuscated stack traces, and various system performance metrics.
You can disable this telemetry collection using either of these settings:
diff --git a/content/en/tracing/error_tracking/_index.md b/content/en/tracing/error_tracking/_index.md
index 15a37969cd0..e4a452359bb 100644
--- a/content/en/tracing/error_tracking/_index.md
+++ b/content/en/tracing/error_tracking/_index.md
@@ -36,7 +36,7 @@ To get started with configuring your repository, see the [Source Code Integratio
## Use span attributes to track error spans
-The Datadog tracers collect errors through integrations and the manual instrumentation of your backend services' source code. An error span must contain the `error.stack`, `error.message`, and `error.type` [span attributes][1] and belong to a complete trace to be tracked. If an error is reported multiple times within a service, only the top-most error is kept.
+The Datadog SDKs collect errors through integrations and the manual instrumentation of your backend services' source code. An error span must contain the `error.stack`, `error.message`, and `error.type` [span attributes][1] and belong to a complete trace to be tracked. If an error is reported multiple times within a service, only the top-most error is kept.
{{< img src="tracing/error_tracking/flamegraph_with_errors.png" alt="Flame graph with errors" style="width:100%;" >}}
diff --git a/content/en/tracing/faq/app_analytics_agent_configuration.md b/content/en/tracing/faq/app_analytics_agent_configuration.md
index 994a34cfaf3..eca61505c64 100644
--- a/content/en/tracing/faq/app_analytics_agent_configuration.md
+++ b/content/en/tracing/faq/app_analytics_agent_configuration.md
@@ -14,7 +14,7 @@ Migrate to Trace Retention and Ingestion
[App Analytics][1] is used to filter APM data by user-defined tags such as `customer_id`, `error_type`, or `app_name` to help troubleshoot and filter your requests. To enable it, either:
-* Configure your APM tracer to emit the relevant analytics from your services—either [automatically][2] or [manually][3].
+* Configure your Datadog SDK to emit the relevant analytics from your services—either [automatically][2] or [manually][3].
* Configure the Datadog Agent to emit the relevant analytics from your services (instructions below).
**Note**: To enable App Analytics with the Agent, [services][1] must be already flowing into Datadog.
diff --git a/content/en/tracing/glossary/_index.md b/content/en/tracing/glossary/_index.md
index 7ff98b0085d..6ddcdf14488 100644
--- a/content/en/tracing/glossary/_index.md
+++ b/content/en/tracing/glossary/_index.md
@@ -102,7 +102,7 @@ For more information, see the [propagating the trace context][27] for your appli
Instrumentation is the process of adding code to your application to capture and report observability data to Datadog, such as traces, metrics, and logs. Datadog provides instrumentation libraries for various programming languages and frameworks.
-You can automatically instrument your application when you install the Datadog Agent with [Single Step Instrumentation][24] or when you [manually add Datadog tracing libraries][25] to your code.
+You can automatically instrument your application when you install the Datadog Agent with [Single Step Instrumentation][24] or when you [manually add Datadog SDKs][25] to your code.
You can use custom instrumentation by embedding tracing code directly into your application code. This allows you to programmatically create, modify, or delete traces to send to Datadog.
diff --git a/content/en/tracing/guide/agent_tracer_hostnames.md b/content/en/tracing/guide/agent_tracer_hostnames.md
index 287e02ec458..88e4e4090bc 100644
--- a/content/en/tracing/guide/agent_tracer_hostnames.md
+++ b/content/en/tracing/guide/agent_tracer_hostnames.md
@@ -10,7 +10,7 @@ In Datadog APM, the `host` tag correlates spans and traces to infrastructure mon
## Datadog Agent vs. Tracer hostname
-The **Agent host** is the host on which the Datadog Agent is running. The **Tracer host** is the host on which the application instrumented with the tracing library is running.
+The **Agent host** is the host on which the Datadog Agent is running. The **Tracer host** is the host on which the application instrumented with the SDK is running.
The Agent host and the Tracer host may differ based on how you deploy the Datadog Agent on your infrastructure:
diff --git a/content/en/tracing/guide/aws_payload_tagging.md b/content/en/tracing/guide/aws_payload_tagging.md
index 55c0a2dbfc9..bef70bed307 100644
--- a/content/en/tracing/guide/aws_payload_tagging.md
+++ b/content/en/tracing/guide/aws_payload_tagging.md
@@ -46,7 +46,7 @@ aws.request.body.Message.Arr.0: a
aws.request.body.Message.Arr.1: b
```
-The tracers are configured to match JSON data nested inside JSON documents, which is a common pattern with SQS payloads.
+The SDKs are configured to match JSON data nested inside JSON documents, which is a common pattern with SQS payloads.
## General configuration
@@ -74,7 +74,7 @@ The value `all` indicates that the entire body is used to generate tags. See [Pr
It's expected that many of these payloads contain *personally identifiable information* (PII).
-To protect sensitive information, the tracers replace common PII fields with `'redacted'` (such as phone numbers in SNS). **Note**: You can't disable the default redactions.
+To protect sensitive information, the SDKs replace common PII fields with `'redacted'` (such as phone numbers in SNS). **Note**: You can't disable the default redactions.
You can specify additional fields to redact using [JSONPath][1] syntax in the environment variables. For example:
diff --git a/content/en/tracing/guide/base_service.md b/content/en/tracing/guide/base_service.md
index acbc334b2e6..0778e95037e 100644
--- a/content/en/tracing/guide/base_service.md
+++ b/content/en/tracing/guide/base_service.md
@@ -24,7 +24,7 @@ This page explains [**integration overrides**](#integration-override) and [**ser
You can manually set the service name on spans. This gives you visibility into specific components of the service, such as shared libraries and middleware layers. These types of overrides are referred to as **service overrides**.
### Integration overrides
-Datadog tracing libraries automatically set different service names on client spans to represent databases, queues, or third-party dependencies in integrations. These types of overrides are referred to as **integration overrides**. With inferred entities, **integration overrides are not necessary to represent dependencies**, and may pollute service lists and maps. For instructions on how to remove integration overrides, see [Integration Override Removal][2].
+Datadog SDKs automatically set different service names on client spans to represent databases, queues, or third-party dependencies in integrations. These types of overrides are referred to as **integration overrides**. With inferred entities, **integration overrides are not necessary to represent dependencies**, and may pollute service lists and maps. For instructions on how to remove integration overrides, see [Integration Override Removal][2].
## Visualizations
Integration overrides and service overrides are represented similarly in APM.
diff --git a/content/en/tracing/guide/ignoring_apm_resources.md b/content/en/tracing/guide/ignoring_apm_resources.md
index 2c26604a117..eb4d63ea761 100644
--- a/content/en/tracing/guide/ignoring_apm_resources.md
+++ b/content/en/tracing/guide/ignoring_apm_resources.md
@@ -256,7 +256,7 @@ DD_APM_IGNORE_RESOURCES="(GET|POST) /healthcheck,API::NotesController#index"
Consider a trace that contains calls to `/api/healthcheck` that you don't want traces from:
-{{< img src="tracing/guide/ignoring_apm_resources/ignoreresources.png" alt="Flame graph of a resource you want the tracer to ignore" style="width:90%;">}}
+{{< img src="tracing/guide/ignoring_apm_resources/ignoreresources.png" alt="Flame graph of a resource you want the SDK to ignore" style="width:90%;">}}
Take note of the resource name of the global root span.
@@ -481,7 +481,7 @@ class CustomFilter(TraceFilter):
return None # Drop the trace
return trace # Keep the trace
-# Configure the tracer with your custom filter
+# Configure the SDK with your custom filter
tracer.configure(trace_processors=[CustomFilter(r'http://.*/healthcheck$')])
```
@@ -508,7 +508,7 @@ tracer.use('http', {
//import http
```
-The tracer configuration for the integration must come before that instrumented module is imported.
+The SDK configuration for the integration must come before that instrumented module is imported.
[1]: https://datadoghq.dev/dd-trace-js/interfaces/export_.plugins.connect.html#blocklist
{{< /programming-lang >}}
diff --git a/content/en/tracing/guide/ingestion_sampling_use_cases.md b/content/en/tracing/guide/ingestion_sampling_use_cases.md
index 6e84eef0f89..777f16b90d5 100644
--- a/content/en/tracing/guide/ingestion_sampling_use_cases.md
+++ b/content/en/tracing/guide/ingestion_sampling_use_cases.md
@@ -12,7 +12,7 @@ further_reading:
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.
-Ingestion mechanisms are configurations within the Datadog Agent and Datadog tracing libraries. If you are using OpenTelemetry SDKs to instrument your applications, read [Ingestion Sampling with OpenTelemetry][2].
+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].
This guide helps you understand when and how to use ingestion control configurations depending on the main use cases you might encounter. It covers:
@@ -29,9 +29,9 @@ To identify which ingestion mechanisms are currently used in your Datadog enviro
The table gives insights on ingested volumes *by service*. The Configuration column provides a first indication of the current set up. It shows:
- `AUTOMATIC` if the sampling rate calculated in the Datadog Agent is applied to the traces that start from the service. Read more about the specifics of [Datadog Agent ingestion logic][5].
-- `CONFIGURED` if a custom trace sampling rate configured in the tracing library is applied to the traces that start from the service.
+- `CONFIGURED` if a custom trace sampling rate configured in the SDK is applied to the traces that start from the service.
-Click on services to see details about what sampling decision makers (for example Agent or tracing library, rules or sample rates) are used for each service, as well as what [ingestion sampling mechanisms][1] are leveraged for ingested spans' services.
+Click on services to see details about what sampling decision makers (for example Agent or SDK, rules or sample rates) are used for each service, as well as what [ingestion sampling mechanisms][1] are leveraged for ingested spans' services.
{{< img src="/tracing/guide/ingestion_sampling_use_cases/service-ingestion-summary.png" alt="Service Ingestion Summary" style="width:90%;" >}}
@@ -73,7 +73,7 @@ If some services and requests are critical to your business, you want higher vis
#### Solution: Sampling rules
-By default, sampling rates are calculated to target 10 traces per second per Datadog Agent. You can override the default calculated sampling rate by configuring [sampling rules][6] in the tracing library.
+By default, sampling rates are calculated to target 10 traces per second per Datadog Agent. You can override the default calculated sampling rate by configuring [sampling rules][6] in the SDK.
You can configure sampling rules by service. For traces that start from the rule's specified service, the defined percentage sampling rate is applied instead of the Agent's default sampling rate.
@@ -101,7 +101,7 @@ In addition to head-based sampled traces, you can increase the error sampling ra
**Notes:**
- Distributed pieces of the trace chunks might not be ingested as the sampling happens locally at the Datadog Agent level.
-- Starting with **Datadog Agent 6/7.41.0 and higher**, `DD_APM_FEATURES=error_rare_sample_tracer_drop` can be set to include spans dropped by tracing library rules or `manual.drop`. More details can be found in the [Error traces section of the Ingestion Mechanisms doc][9].
+- Starting with **Datadog Agent 6/7.41.0 and higher**, `DD_APM_FEATURES=error_rare_sample_tracer_drop` can be set to include spans dropped by SDK rules or `manual.drop`. More details can be found in the [Error traces section of the Ingestion Mechanisms doc][9].
#### Configuring error sampling
diff --git a/content/en/tracing/guide/init_resource_calc.md b/content/en/tracing/guide/init_resource_calc.md
index 599f64213d0..63eac43d0b2 100644
--- a/content/en/tracing/guide/init_resource_calc.md
+++ b/content/en/tracing/guide/init_resource_calc.md
@@ -6,7 +6,7 @@ disable_toc: false
### Overview
-Starting in Agent [v7.60+][1], Datadog uses dynamic resource calculation for init containers that inject tracing libraries. Instead of using fixed values, the init containers temporarily request all available CPU and memory for the pod, without affecting how the pod is scheduled. (Prior to v7.60, init containers used conservative defaults: `50m` for CPU and `20Mi` for memory.)
+Starting in Agent [v7.60+][1], Datadog uses dynamic resource calculation for init containers that inject SDKs. Instead of using fixed values, the init containers temporarily request all available CPU and memory for the pod, without affecting how the pod is scheduled. (Prior to v7.60, init containers used conservative defaults: `50m` for CPU and `20Mi` for memory.)
This behavior improves tracer startup reliability while respecting Kubernetes scheduling rules. Since init containers run sequentially and exit before application containers start, they don't compete for runtime resources.
diff --git a/content/en/tracing/guide/injectors.md b/content/en/tracing/guide/injectors.md
index 751a4a9881b..13c906fa253 100644
--- a/content/en/tracing/guide/injectors.md
+++ b/content/en/tracing/guide/injectors.md
@@ -33,7 +33,7 @@ In Kubernetes environments, injection is handled by the Datadog Admission Contro
1. Evaluates whether the pod should be instrumented based on configured selectors (such as namespaces, labels, or specific pod properties).
1. Mutates the pod spec to:
- - Add init containers to download injector and tracer libraries
+ - Add init containers to download injector and SDKs
- Set environment variables (like `LD_PRELOAD`)
- Mount volumes to persist injected libraries
diff --git a/content/en/tracing/guide/local_sdk_injection.md b/content/en/tracing/guide/local_sdk_injection.md
index dd5b56a7bd9..60c4437a529 100644
--- a/content/en/tracing/guide/local_sdk_injection.md
+++ b/content/en/tracing/guide/local_sdk_injection.md
@@ -5,9 +5,9 @@ disable_toc: false
## Overview
-Use the [Datadog Admission Controller][1] to inject APM tracer libraries into Kubernetes workloads using pod-level annotations and labels.
+Use the [Datadog Admission Controller][1] to inject Datadog SDKs into Kubernetes workloads using pod-level annotations and labels.
-The Datadog Agent uses the Kubernetes Admission Controller to intercept pod creation requests and inject an init container that installs the tracer library before the application starts. This method provides a manual, pod-level alternative to [Single Step Instrumentation (SSI)][2], which uses Helm or the Datadog Operator to configure instrumentation across your cluster.
+The Datadog Agent uses the Kubernetes Admission Controller to intercept pod creation requests and inject an init container that installs the SDK before the application starts. This method provides a manual, pod-level alternative to [Single Step Instrumentation (SSI)][2], which uses Helm or the Datadog Operator to configure instrumentation across your cluster.
Use this guide if:
- You want to test library injection on a small number of services before rolling out SSI cluster-wide.
@@ -91,7 +91,7 @@ spec:
- # (...)
```
-To view available library versions, see the tracer repositories for each language:
+To view available library versions, see the SDK repositories for each language:
- [Java][4]
- [Node.js][5]
- [Python][6]
diff --git a/content/en/tracing/guide/orchestrion_dockerfile.md b/content/en/tracing/guide/orchestrion_dockerfile.md
index 325e179ad78..6cb068181a4 100644
--- a/content/en/tracing/guide/orchestrion_dockerfile.md
+++ b/content/en/tracing/guide/orchestrion_dockerfile.md
@@ -6,7 +6,7 @@ further_reading:
text: "Tracing Go Applications"
- link: "https://docs.datadoghq.com/tracing/trace_collection/library_config/go/"
tag: "Documentation"
- text: "Configuring the Go Tracing Library"
+ text: "Configuring the Go SDK"
- link: "/tracing/troubleshooting/go_compile_time/"
tag: "Documentation"
text: "Troubleshooting Go Compile-Time Instrumentation"
diff --git a/content/en/tracing/guide/remote_config.md b/content/en/tracing/guide/remote_config.md
index 5de9e6f0d67..504ffe687a8 100644
--- a/content/en/tracing/guide/remote_config.md
+++ b/content/en/tracing/guide/remote_config.md
@@ -1,18 +1,18 @@
---
title: Setting up Remote Configuration for Tracing
-description: Learn how to set up and use Remote Configuration to dynamically manage tracing library settings without restarting applications.
+description: Learn how to set up and use Remote Configuration to dynamically manage SDK settings without restarting applications.
further_reading:
- link: "remote_configuration"
tag: "Documentation"
text: "Remote Configuration"
---
-This guide covers setting up and using Remote Configuration with your tracing libraries. For more information on how Remote Configuration works, see [Remote Configuration][1].
+This guide covers setting up and using Remote Configuration with your SDKs. For more information on how Remote Configuration works, see [Remote Configuration][1].
## Prerequisites
- [Datadog Agent][2] 7.47.0 or higher installed on your hosts or containers.
-- Upgrade your tracing libraries to a Remote Configuration-compatible version. For more information, see the [Supported configuration options][7] section.
+- Upgrade your SDKs to a Remote Configuration-compatible version. For more information, see the [Supported configuration options][7] section.
- Ensure your RBAC permissions include [`org_management`][3], so you can enable Remote Configuration for your organization.
- Ensure your RBAC permissions include [`api_keys_write`][4], so you can create a new API key with the Remote Configuration capability, or add the capability to an existing API key. Contact your organization's Datadog administrator to update your permissions if you don't have it. A key with this capability allows you to authenticate and authorize your Agent to use Remote Configuration.
- Ensure you have the `APM Remote Configuration Read` and `APM Remote Configuration Write` [permissions][3].
@@ -26,22 +26,22 @@ This guide covers setting up and using Remote Configuration with your tracing li
{{
}}
1. Restart your Agent.
-## Review Remote Configuration status of tracing libraries
+## Review Remote Configuration status of SDKs
-You can gain visibility into the Remote Configuration status of your Tracer libraries through the [Remote Configuration UI][5].
+You can gain visibility into the Remote Configuration status of your SDKs through the [Remote Configuration UI][5].
-The following table describes the meaning of each tracing library status:
+The following table describes the meaning of each SDK status:
- | Tracing library Status| Description |
+ | SDK Status| Description |
|------------------|--------------------------------------------------|
- | CONNECTED | The tracing library is successfully connected to the Remote Configuration service through the associated Agent. This is the optimal state you want your tracing library to be in for Remote Configuration. |
- | UNAUTHORIZED | The tracing library is associated with an Agent which doesn't have `APM Remote Configuration Read` permission on its API key. To fix the issue, you need to enable Remote Configuration capability on the API Key used by the Agent associated with the tracing library.|
- | CONNECTION ERROR | The tracing library deployed in your environment is associated with an Agent that has `remote_config.enabled` set to true in its `datadog.yaml` configuration file, however, the Agent cannot be found in the Remote Configuration service. The most likely cause of this is that the associated Agent is unable to reach Remote Configuration [endpoints][6]. To fix the issue, you need to allow outbound HTTPS access to Remote Configuration endpoints from your environment.
- | DISABLED | The tracing library deployed in your environment is associated with an Agent that has `remote_config.enabled` set to false in its `datadog.yaml` configuration file. This could be set deliberately or mistakenly. To enable Remote Configuration on the associated Agent, set `remote_config.enabled` to true. |
- | NOT CONNECTED | The tracing library cannot be found in the Remote Configuration service and is associated with an Agent that could have `remote_config.enabled` set to true or false in its `datadog.yaml` configuration file. Check your local Agent configuration or your proxy settings.|
- | UNSUPPORTED AGENT | The tracing library is associated with an Agent which is not Remote Configuration capable. To fix this issue, update the associated Agent software to the latest available version. |
- | NOT DETECTED | The tracing library does not support Remote Configuration. To fix this issue, update the tracing library software to the latest available version. |
- | UNKNOWN | The tracing library status is unknown, and it can't be determined if an Agent is associated with the tracing library. For example, this could be because the Agent is deployed on a fully managed serverless container service like AWS Fargate. |
+ | CONNECTED | The SDK is successfully connected to the Remote Configuration service through the associated Agent. This is the optimal state you want your SDK to be in for Remote Configuration. |
+ | UNAUTHORIZED | The SDK is associated with an Agent which doesn't have `APM Remote Configuration Read` permission on its API key. To fix the issue, you need to enable Remote Configuration capability on the API Key used by the Agent associated with the SDK.|
+ | CONNECTION ERROR | The SDK deployed in your environment is associated with an Agent that has `remote_config.enabled` set to true in its `datadog.yaml` configuration file, however, the Agent cannot be found in the Remote Configuration service. The most likely cause of this is that the associated Agent is unable to reach Remote Configuration [endpoints][6]. To fix the issue, you need to allow outbound HTTPS access to Remote Configuration endpoints from your environment.
+ | DISABLED | The SDK deployed in your environment is associated with an Agent that has `remote_config.enabled` set to false in its `datadog.yaml` configuration file. This could be set deliberately or mistakenly. To enable Remote Configuration on the associated Agent, set `remote_config.enabled` to true. |
+ | NOT CONNECTED | The SDK cannot be found in the Remote Configuration service and is associated with an Agent that could have `remote_config.enabled` set to true or false in its `datadog.yaml` configuration file. Check your local Agent configuration or your proxy settings.|
+ | UNSUPPORTED AGENT | The SDK is associated with an Agent which is not Remote Configuration capable. To fix this issue, update the associated Agent software to the latest available version. |
+ | NOT DETECTED | The SDK does not support Remote Configuration. To fix this issue, update the SDK software to the latest available version. |
+ | UNKNOWN | The SDK status is unknown, and it can't be determined if an Agent is associated with the SDK. For example, this could be because the Agent is deployed on a fully managed serverless container service like AWS Fargate. |
## Opting out of Remote Configuration for Fleet Automation
diff --git a/content/en/tracing/guide/resource_based_sampling.md b/content/en/tracing/guide/resource_based_sampling.md
index 50dec3d77f7..b0cce542f06 100644
--- a/content/en/tracing/guide/resource_based_sampling.md
+++ b/content/en/tracing/guide/resource_based_sampling.md
@@ -25,7 +25,7 @@ Remote configuration allows you to dynamically set ingestion [sampling rates by
### Tracing library version
-Find below the minimum tracing library version required for the feature:
+Find below the minimum SDK version required for the feature:
Language | Minimum version required
----------|--------------------------
@@ -47,7 +47,7 @@ To see configured sampling rates by resource, navigate to the Ingestion controls
- The `Ingested bytes` column surfaces the ingested bytes from spans of the service and resource, while the `Downstream bytes` column surfaces the ingested bytes from spans where the sampling decision is made starting from that service and resource, including bytes from downstream services in the call chain.
- The `Configuration` column surfaces where the resource sampling rate is being applied from:
- `Automatic` if the [default head-based sampling mechanism][8] from the Agent applies.
- - `Local Configured` if a [sampling rule][7] was set locally in the tracing library.
+ - `Local Configured` if a [sampling rule][7] was set locally in the SDK.
- `Remote Configured` if a remote sampling rule was set from the Datadog UI. To learn how to configure sampling rules from the Ingestion Control page, read the section on [remotely configuring sampling rules](#remotely-configure-sampling-rules-for-the-service).
## Remotely configure sampling rules for the service
diff --git a/content/en/tracing/guide/send_traces_to_agent_by_api.md b/content/en/tracing/guide/send_traces_to_agent_by_api.md
index c041d6175de..cd44e0b82ad 100644
--- a/content/en/tracing/guide/send_traces_to_agent_by_api.md
+++ b/content/en/tracing/guide/send_traces_to_agent_by_api.md
@@ -17,7 +17,7 @@ aliases:
Datadog APM 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 tracing libraries 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 tracing library.
+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.
The tracing API is an Agent API rather than a service side API. Submit your traces to the `http://localhost:8126/v0.3/traces` local endpoint so your Agent can forward them to Datadog.
@@ -43,7 +43,7 @@ and each span is a dictionary with a `trace_id`, `span_id`, `resource` and so on
### Model
-Datadog tracing libraries support both 64-bit and 128-bit trace IDs. Read Span and Trace ID formats to learn more.
+Datadog SDKs support both 64-bit and 128-bit trace IDs. Read Span and Trace ID formats to learn more.
| Field | Type | Description |
|------------|---------|---------------------------------------|
diff --git a/content/en/tracing/guide/serverless_enable_aws_xray.md b/content/en/tracing/guide/serverless_enable_aws_xray.md
index 4686d772bac..e450584bb02 100644
--- a/content/en/tracing/guide/serverless_enable_aws_xray.md
+++ b/content/en/tracing/guide/serverless_enable_aws_xray.md
@@ -28,7 +28,7 @@ The `BatchGetTraces` permission is used to return the full traces. The `GetTrace
To get the most out of the AWS X-Ray integration:
- Enable it on your Lambda functions and API Gateways, either using the Serverless Framework plugin or manually; and
-- Install the tracing libraries in your Lambda functions.
+- Install the SDKs in your Lambda functions.
#### [Recommended] Datadog Serverless Framework plugin
@@ -61,7 +61,7 @@ Install the library, import it into your Lambda projects, and patch the services
{{< programming-lang lang="nodejs" >}}
-Install the X-Ray tracing library:
+Install the X-Ray SDK:
```bash
@@ -110,7 +110,7 @@ For further configuration, creating subsegments, and recording annotations, see
{{< programming-lang lang="python" >}}
-Install the X-Ray tracing library:
+Install the X-Ray SDK:
```bash
pip install aws-xray-sdk
diff --git a/content/en/tracing/guide/setting_primary_tags_to_scope.md b/content/en/tracing/guide/setting_primary_tags_to_scope.md
index 2cb3e34eb3a..cdac21f87bf 100644
--- a/content/en/tracing/guide/setting_primary_tags_to_scope.md
+++ b/content/en/tracing/guide/setting_primary_tags_to_scope.md
@@ -32,11 +32,11 @@ The default and mandatory primary tag is the environment your traces are collect
#### Tracer environment
-Datadog recommends having the tracer set `env`. It also allows for greater flexibility because the definition of `env` lives within the actual runtime of the service.
+Datadog recommends having the SDK set `env`. It also allows for greater flexibility because the definition of `env` lives within the actual runtime of the service.
-If `DD_ENV` is exposed to your service's process, the tracer will use it automatically. See [Unified Service Tagging][3] to learn about setting `DD_ENV` and other standard service environment variables.
+If `DD_ENV` is exposed to your service's process, the SDK will use it automatically. See [Unified Service Tagging][3] to learn about setting `DD_ENV` and other standard service environment variables.
-You may also manually set `env` as a global tag for the tracer in code. See [assigning tags in APM][4] for more information.
+You may also manually set `env` as a global tag for the SDK in code. See [assigning tags in APM][4] for more information.
#### Agent environment
@@ -78,9 +78,9 @@ Go to the [APM Settings][6] page to define, change, or remove your primary tags.
* Only organization administrators have access to this page.
* Changes may take up to two hours to be reflected in the UI.
-* The tracer always adds `resource`, `name`, and `service` tags to spans. Datadog recommends never adding these as host level tags to avoid confusion.
+* The SDK always adds `resource`, `name`, and `service` tags to spans. Datadog recommends never adding these as host level tags to avoid confusion.
* The additional primary tags support up to 100 unique values per tag. See [APM data volume guidelines][9] for details.
-* Additional primary tags can be host or container tags. Span-level tags added by the tracer cannot be used as primary tags.
+* Additional primary tags can be host or container tags. Span-level tags added by the SDK cannot be used as primary tags.
If you change a previously set primary tag, be aware of the following:
diff --git a/content/en/tracing/guide/setting_up_APM_with_cpp.md b/content/en/tracing/guide/setting_up_APM_with_cpp.md
index 2a8204d6e1b..3cbaccffaa3 100644
--- a/content/en/tracing/guide/setting_up_APM_with_cpp.md
+++ b/content/en/tracing/guide/setting_up_APM_with_cpp.md
@@ -1,6 +1,6 @@
---
title: Setting Up APM with C++
-description: Learn how to set up APM and distributed tracing for C++ applications using Datadog tracing libraries and instrumentation.
+description: Learn how to set up APM and distributed tracing for C++ applications using Datadog SDKs and instrumentation.
further_reading:
- link: "/tracing/trace_collection/dd_libraries/cpp/"
@@ -97,7 +97,7 @@ int main(int argc, char* argv[]) {
}
```
-This creates a tracer that generates two spans, a parent span `span_a` and a child span `span_b`, and tags them.
+This creates an SDK that generates two spans, a parent span `span_a` and a child span `span_b`, and tags them.
Then, compile and link against `libdd_trace_cpp` with:
diff --git a/content/en/tracing/guide/setting_up_apm_with_kubernetes_service.md b/content/en/tracing/guide/setting_up_apm_with_kubernetes_service.md
index 17ee2e963b7..164938032dc 100644
--- a/content/en/tracing/guide/setting_up_apm_with_kubernetes_service.md
+++ b/content/en/tracing/guide/setting_up_apm_with_kubernetes_service.md
@@ -13,7 +13,7 @@ further_reading:
## Overview
-In Kubernetes, Datadog tracers can send data to the Datadog Agent in three ways: Unix Domain Socket (UDS), host IP, or a Kubernetes service. Each option ensures that when an application pod sends APM data, the data arrives at a Datadog Agent pod on the same node. This strategy is meant to properly balance traffic and ensure the correct tagging of your data. Datadog recommends that you use UDS to send data.
+In Kubernetes, Datadog SDKs can send data to the Datadog Agent in three ways: Unix Domain Socket (UDS), host IP, or a Kubernetes service. Each option ensures that when an application pod sends APM data, the data arrives at a Datadog Agent pod on the same node. This strategy is meant to properly balance traffic and ensure the correct tagging of your data. Datadog recommends that you use UDS to send data.
However, if the `hostPath` volumes required for UDS (and the `hostPort` ports required for using host IP) are not available, you can use a Kubernetes service as an alternative option.
diff --git a/content/en/tracing/guide/span_and_trace_id_format.md b/content/en/tracing/guide/span_and_trace_id_format.md
index ca3743e2885..656f80cef76 100644
--- a/content/en/tracing/guide/span_and_trace_id_format.md
+++ b/content/en/tracing/guide/span_and_trace_id_format.md
@@ -1,6 +1,6 @@
---
title: Trace and Span ID Formats
-description: Guide on valid trace and span ID formats supported by Datadog tracing libraries and how they correlate with logs.
+description: Guide on valid trace and span ID formats supported by Datadog SDKs and how they correlate with logs.
aliases:
- /tracing/faq/span_and_trace_id_format/
@@ -12,14 +12,14 @@ further_reading:
---
{{< jqmath-vanilla >}}
-This page details Datadog tracing library support for trace and {{< tooltip glossary="span id" >}}s.
+This page details Datadog SDK support for trace and {{< tooltip glossary="span id" >}}s.
-- **Generated IDs**: By default, all tracing libraries generate 128-bit trace IDs and 64-bit span IDs.
+- **Generated IDs**: By default, all SDKs generate 128-bit trace IDs and 64-bit span IDs.
- **Accepted IDs**: Datadog accepts 128-bit or 64-bit trace IDs, and 64-bit span IDs.
## 128-bit trace IDs
-128-bit trace IDs are generated and accepted by default in the latest versions of Datadog tracing libraries:
+128-bit trace IDs are generated and accepted by default in the latest versions of Datadog SDKs:
- [Node.js][1]
- [Java][2]
diff --git a/content/en/tracing/guide/trace_ingestion_volume_control.md b/content/en/tracing/guide/trace_ingestion_volume_control.md
index 12b89bbf69e..a6ba41a0fbe 100644
--- a/content/en/tracing/guide/trace_ingestion_volume_control.md
+++ b/content/en/tracing/guide/trace_ingestion_volume_control.md
@@ -10,7 +10,7 @@ further_reading:
## Overview
-The [Ingestion control page][1] provides granular visibility into the ingestion configuration for all services, in the agent and in the tracing libraries. All [Ingestion Mechanisms][2] are publicly documented and configurable.
+The [Ingestion control page][1] provides granular visibility into the ingestion configuration for all services, in the agent and in the SDKs. All [Ingestion Mechanisms][2] are publicly documented and configurable.
With the ingestion control page, you have full visibility and complete control of your span volume. Consequently, you are be able to:
- Ingest the data that is most relevant to your business and your observability goals.
@@ -43,7 +43,7 @@ Count-based [**Trace analytics**][6] monitors are impacted as well. Check if you
## Assess your services' ingestion configuration
-To assess the current state of applications' instrumentation, leverage the [Trace Ingestion Control page][1] that provides detailed information on agent and tracing library configuration.
+To assess the current state of applications' instrumentation, leverage the [Trace Ingestion Control page][1] that provides detailed information on agent and SDK configuration.
### Understanding if you are within your monthly ingestion allocation
@@ -79,7 +79,7 @@ The **Configuration** column tells you whether or not your services are configur
To reduce the ingestion volume at the Agent level, configure `DD_APM_TARGET_TPS` (set to `10` by default) to reduce the share of head-based sampling volume. Read more about the [default sampling mechanism][7].
-**Note**: This configuration option only goes into effect when using **Datadog tracing libraries**. If the OTLP Ingest in the Agent collects data from applications instrumented with OpenTelemetry, modifying `DD_APM_TARGET_TPS` does not change sampling rates that are applied in tracing libraries.
+**Note**: This configuration option only goes into effect when using **Datadog SDKs**. If the OTLP Ingest in the Agent collects data from applications instrumented with OpenTelemetry, modifying `DD_APM_TARGET_TPS` does not change sampling rates that are applied in SDKs.
Additionally, to reduce the volume of [error][9] and [rare][10] traces:
- Configure `DD_APM_ERROR_TPS` to reduce the share of error sampling.
@@ -91,7 +91,7 @@ By configuring sampling rates for a few high-throughput services, most of the "e
Click on a service to view the **Service Ingestion Summary**. Look at the **Ingestion reasons breakdown** in the side panel, which gives an overview of the share of ingestion volume attributed to each mechanism.
-If the main reason for most of the ingestion volume is head-based sampling (`auto` or `rule`), the volume can be configured by setting a sampling rule at the tracing library level.
+If the main reason for most of the ingestion volume is head-based sampling (`auto` or `rule`), the volume can be configured by setting a sampling rule at the SDK level.
Click the **Manage Ingestion Rate** button to configure a sampling rate for the service. Select the service language and the ingestion sampling rate you want to apply.
@@ -112,11 +112,11 @@ _Know which ingestion mechanisms are responsible for most of the ingestion volum
The default mechanism to sample traces is head-based sampling. The decision whether to sample a trace or not is taken at the beginning of its lifecycle, and propagated downstream in the context of the requests in order to ensure that you can always view and analyze complete traces.
-Head-based sampling is configurable in the tracing libraries or from the Datadog Agent:
+Head-based sampling is configurable in the SDKs or from the Datadog Agent:
| ingestion reason | Where | Ingestion Mechanism Description | Default |
|--------------------|-------------------|-----------------------|---------|
-| `auto` | [Agent](#globally-configure-the-ingestion-sampling-rate-at-the-agent-level) | The Datadog Agent distributes sampling rates to tracing libraries. | 10 traces per second per Agent |
+| `auto` | [Agent](#globally-configure-the-ingestion-sampling-rate-at-the-agent-level) | The Datadog Agent distributes sampling rates to SDKs. | 10 traces per second per Agent |
| `rule` | [Tracing Libraries](#independently-configure-the-ingestion-sampling-rate-for-services-at-the-library-level) | The libraries' defined sampling percentage for specific services. | null |
diff --git a/content/en/tracing/guide/tutorial-enable-go-aws-ecs-ec2.md b/content/en/tracing/guide/tutorial-enable-go-aws-ecs-ec2.md
index a244bf6ef7b..d97df14fc24 100644
--- a/content/en/tracing/guide/tutorial-enable-go-aws-ecs-ec2.md
+++ b/content/en/tracing/guide/tutorial-enable-go-aws-ecs-ec2.md
@@ -5,10 +5,10 @@ description: Step-by-step tutorial to enable distributed tracing for a Go applic
further_reading:
- link: /tracing/trace_collection/library_config/go/
tag: Documentation
- text: Additional tracing library configuration options
+ text: Additional SDK configuration options
- link: /tracing/trace_collection/dd_libraries/go/
tag: Documentation
- text: Detailed tracing library setup instructions
+ text: Detailed SDK setup instructions
- link: /tracing/trace_collection/compatibility/go/
tag: Documentation
text: Supported Go frameworks for automatic instrumentation
@@ -106,7 +106,7 @@ Your application (without tracing enabled) is containerized and available for EC
### Deploy the application
-Start the application and send some requests without tracing. After you've seen how the application works, you'll instrument it using the tracing library and Datadog Agent.
+Start the application and send some requests without tracing. After you've seen how the application works, you'll instrument it using the SDK and Datadog Agent.
To start, use a Terraform script to deploy to Amazon ECS:
diff --git a/content/en/tracing/guide/tutorial-enable-go-aws-ecs-fargate.md b/content/en/tracing/guide/tutorial-enable-go-aws-ecs-fargate.md
index e17c6dde50d..e57311f84a0 100644
--- a/content/en/tracing/guide/tutorial-enable-go-aws-ecs-fargate.md
+++ b/content/en/tracing/guide/tutorial-enable-go-aws-ecs-fargate.md
@@ -4,10 +4,10 @@ title: Tutorial - Enabling Tracing for a Go Application on Amazon ECS with Farga
further_reading:
- link: /tracing/trace_collection/library_config/go/
tag: "Documentation"
- text: Additional tracing library configuration options
+ text: Additional SDK configuration options
- link: /tracing/trace_collection/dd_libraries/go/
tag: "Documentation"
- text: Detailed tracing library setup instructions
+ text: Detailed SDK setup instructions
- link: /tracing/trace_collection/compatibility/go/
tag: "Documentation"
text: Supported Go frameworks for automatic instrumentation
@@ -107,7 +107,7 @@ Your application (without tracing enabled) is containerized and available for EC
### Deploy the application
-Start the application and send some requests without tracing. After you've seen how the application works, you'll instrument it using the tracing library and Datadog Agent.
+Start the application and send some requests without tracing. After you've seen how the application works, you'll instrument it using the SDK and Datadog Agent.
To start, use a Terraform script to deploy to Amazon ECS:
diff --git a/content/en/tracing/guide/tutorial-enable-go-containers.md b/content/en/tracing/guide/tutorial-enable-go-containers.md
index 7fbc3a6b035..5527c570842 100644
--- a/content/en/tracing/guide/tutorial-enable-go-containers.md
+++ b/content/en/tracing/guide/tutorial-enable-go-containers.md
@@ -5,10 +5,10 @@ description: Step-by-step tutorial to enable distributed tracing for a Go applic
further_reading:
- link: /tracing/trace_collection/library_config/go/
tag: "Documentation"
- text: Additional tracing library configuration options
+ text: Additional SDK configuration options
- link: /tracing/trace_collection/dd_libraries/go/
tag: "Documentation"
- text: Detailed tracing library setup instructions
+ text: Detailed SDK setup instructions
- link: /tracing/trace_collection/compatibility/go/
tag: "Documentation"
text: Supported Go frameworks for automatic instrumentation
@@ -185,7 +185,7 @@ Add the Datadog Agent in the services section of your `all-docker-compose.yaml`
## Launch the containers to explore automatic instrumentation
-Now that the Tracing Library is installed, spin up your application containers and start receiving traces. Run the following commands:
+Now that the SDK is installed, spin up your application containers and start receiving traces. Run the following commands:
{{< code-block lang="shell" >}}
docker-compose -f all-docker-compose.yaml build
@@ -235,7 +235,7 @@ A `GET /notes` trace looks something like this:
## Tracing configuration
-You can configure the tracing library to add tags to the telemetry it sends to Datadog. Tags help group, filter, and display data meaningfully in dashboards and graphs. To add tags, specify environment variables when running the application. The project `Makefile` includes the environment variables `DD_ENV`, `DD_SERVICE`, and `DD_VERSION`, which are set to enable [Unified Service Tagging][17]:
+You can configure the SDK to add tags to the telemetry it sends to Datadog. Tags help group, filter, and display data meaningfully in dashboards and graphs. To add tags, specify environment variables when running the application. The project `Makefile` includes the environment variables `DD_ENV`, `DD_SERVICE`, and `DD_VERSION`, which are set to enable [Unified Service Tagging][17]:
{{< code-block lang="go" filename="docker/all-docker-compose.yaml" disable_copy="true" >}}
environment:
@@ -244,9 +244,9 @@ environment:
- DD_APM_NON_LOCAL_TRAFFIC=true
{{< /code-block >}}
-For more information on available configuration options, see [Configuring the Go Tracing Library][14].
+For more information on available configuration options, see [Configuring the Go SDK][14].
-### Use automatic tracing libraries
+### Use automatic SDKs
Datadog has several fully supported libraries for Go that allow for automatic tracing when implemented in the code. In the `cmd/notes/main.go` file, you can see the `go-chi`, `sql`, and `http` libraries being aliased to the corresponding Datadog libraries: `chitrace`, `sqltrace`, and `httptrace` respectively:
diff --git a/content/en/tracing/guide/tutorial-enable-go-host.md b/content/en/tracing/guide/tutorial-enable-go-host.md
index 24cec9c869d..e71cd738ae7 100644
--- a/content/en/tracing/guide/tutorial-enable-go-host.md
+++ b/content/en/tracing/guide/tutorial-enable-go-host.md
@@ -5,10 +5,10 @@ description: Step-by-step tutorial to enable distributed tracing for a Go applic
further_reading:
- link: /tracing/trace_collection/library_config/go/
tag: "Documentation"
- text: Additional tracing library configuration options
+ text: Additional SDK configuration options
- link: /tracing/trace_collection/dd_libraries/go/
tag: "Documentation"
- text: Detailed tracing library setup instructions
+ text: Detailed SDK setup instructions
- link: /tracing/trace_collection/compatibility/go/
tag: "Documentation"
text: Supported Go frameworks for automatic instrumentation
@@ -105,7 +105,7 @@ Next, install the Go tracer. From your `apm-tutorial-golang` directory, run:
go get github.com/DataDog/dd-trace-go/v2/ddtrace
{{< /code-block >}}
-Now that the tracing library has been added to `go.mod`, enable tracing support.
+Now that the SDK has been added to `go.mod`, enable tracing support.
Uncomment the following imports in `apm-tutorial-golang/cmd/notes/main.go`:
{{< code-block lang="go" filename="cmd/notes/main.go" >}}
@@ -203,7 +203,7 @@ A `GET /notes` trace looks something like this:
## Tracing configuration
-You can configure the tracing library to add tags to the telemetry it sends to Datadog. Tags help group, filter, and display data meaningfully in dashboards and graphs. To add tags, specify environment variables when running the application. The project `Makefile` includes the environment variables `DD_ENV`, `DD_SERVICE`, and `DD_VERSION`, which are set to enable [Unified Service Tagging][17]:
+You can configure the SDK to add tags to the telemetry it sends to Datadog. Tags help group, filter, and display data meaningfully in dashboards and graphs. To add tags, specify environment variables when running the application. The project `Makefile` includes the environment variables `DD_ENV`, `DD_SERVICE`, and `DD_VERSION`, which are set to enable [Unified Service Tagging][17]:
{{< code-block lang="go" filename="Makefile" disable_copy="true" collapsible="true" >}}
run: build
@@ -212,9 +212,9 @@ run: build
The
-For more information on available configuration options, see [Configuring the Go Tracing Library][14].
+For more information on available configuration options, see [Configuring the Go SDK][14].
-### Use automatic tracing libraries
+### Use automatic SDKs
Datadog has several fully supported libraries for Go that allow for automatic tracing when implemented in the code. In the `cmd/notes/main.go` file, you can see the `go-chi`, `sql`, and `http` libraries being aliased to the corresponding Datadog libraries: `chitrace`, `sqltrace`, and `httptrace` respectively:
diff --git a/content/en/tracing/guide/tutorial-enable-java-admission-controller.md b/content/en/tracing/guide/tutorial-enable-java-admission-controller.md
index 2fdd834c650..495ede55865 100644
--- a/content/en/tracing/guide/tutorial-enable-java-admission-controller.md
+++ b/content/en/tracing/guide/tutorial-enable-java-admission-controller.md
@@ -4,10 +4,10 @@ title: Tutorial - Enabling Tracing for a Java Application with the Admission Con
further_reading:
- link: /tracing/trace_collection/library_config/java/
tag: "Documentation"
- text: Additional tracing library configuration options
+ text: Additional SDK configuration options
- link: /tracing/trace_collection/dd_libraries/java/
tag: "Documentation"
- text: Detailed tracing library setup instructions
+ text: Detailed SDK setup instructions
- link: /tracing/trace_collection/compatibility/java/
tag: "Documentation"
text: Supported Java frameworks for automatic instrumentation
@@ -95,7 +95,7 @@ After you have your application working, instrument it using the Datadog Admissi
3. [Annotate][7] your pod for library injection.
4. [Label][8] your pod to instruct the Datadog Admission controller to mutate the pod.
-There's no need to add the tracing library because it's automatically injected. You don't need to redeploy your app yet. This section of the tutorial steps you through the process of adding Datadog variables and deploying a new image or version of your app.
+There's no need to add the SDK because it's automatically injected. You don't need to redeploy your app yet. This section of the tutorial steps you through the process of adding Datadog variables and deploying a new image or version of your app.
1. From the `k8s` subdirectory, use the following command to install the Datadog Cluster Agent, specifying the `values-with-lib-inj.yaml` config file and your [Datadog API key](/account_management/api-app-keys/):
{{< code-block lang="shell" >}}
@@ -122,7 +122,7 @@ labels:
tags.datadoghq.com/service: "springfront"
tags.datadoghq.com/version: "12"{{< /code-block >}}
-4. Configure the Datadog Admission Controller to inject a Java tracing library to the app container by adding the following annotation to the pod:
+4. Configure the Datadog Admission Controller to inject a Java SDK to the app container by adding the following annotation to the pod:
{{< code-block lang="yaml" >}}
annotations:
admission.datadoghq.com/java-lib.version: "Makefile also sets the DD_TRACE_SAMPLE_RATE environment variable to 1, which represents a 100% sample rate. A 100% sample rate ensures that all requests to the notes service are sent to the Datadog backend for analysis and display for the purposes of this tutorial. In an actual production or high-volume environment, you wouldn't specify this high of a rate. Setting a high sample rate with this variable in the application overrides the Agent configuration and results in a very large volume of data being sent to Datadog. For most use cases, allow the Agent to automatically determine the sampling rate.-**Description**: Sets the host address for the tracing library's metric submission. Can be a hostname or an IP address. +**Description**: Sets the host address for the SDK's metric submission. Can be a hostname or an IP address. `DD_DOGSTATSD_PORT` : **Default**: `8125`
-**Description**: Sets the port for the tracing library's metric submission. +**Description**: Sets the port for the SDK's metric submission. #### Code-based configuration diff --git a/content/en/tracing/other_telemetry/connect_logs_and_traces/dotnet.md b/content/en/tracing/other_telemetry/connect_logs_and_traces/dotnet.md index b7d7527e343..8ebf71c55c7 100644 --- a/content/en/tracing/other_telemetry/connect_logs_and_traces/dotnet.md +++ b/content/en/tracing/other_telemetry/connect_logs_and_traces/dotnet.md @@ -227,7 +227,7 @@ If you prefer to manually correlate your traces with your logs, you can add corr | Required key | Description | | -------------- | -------------------------------------------- | - | `dd.env` | Globally configures the `env` for the tracer. Defaults to `""` if not set. | + | `dd.env` | Globally configures the `env` for the SDK. Defaults to `""` if not set. | | `dd.service` | Globally configures the root service name. Defaults to the name of the application or IIS site name if not set. | | `dd.version` | Globally configures `version` for the service. Defaults to `""` if not set. | | `dd.trace_id` | Active trace ID (represented as a 64-bit decimal number) during the log statement. Defaults to `0` if no trace. | diff --git a/content/en/tracing/other_telemetry/connect_logs_and_traces/java.md b/content/en/tracing/other_telemetry/connect_logs_and_traces/java.md index 95a9404b803..b1a236495bd 100644 --- a/content/en/tracing/other_telemetry/connect_logs_and_traces/java.md +++ b/content/en/tracing/other_telemetry/connect_logs_and_traces/java.md @@ -128,7 +128,7 @@ implementation("com.datadoghq:dd-trace-api:LATEST_VERSION") {{% /tab %}} {{< /tabs >}} -Replace `LATEST_VERSION` with the same version as your Datadog Java tracer (`dd-java-agent`). +Replace `LATEST_VERSION` with the same version as your Datadog Java SDK (`dd-java-agent`). After you add the dependency, use `CorrelationIdentifier.getTraceId()` and `CorrelationIdentifier.getSpanId()` to retrieve and inject the IDs into your logging context, as shown in the following examples. diff --git a/content/en/tracing/other_telemetry/connect_logs_and_traces/nodejs.md b/content/en/tracing/other_telemetry/connect_logs_and_traces/nodejs.md index fed6791c3cc..7a2978be321 100644 --- a/content/en/tracing/other_telemetry/connect_logs_and_traces/nodejs.md +++ b/content/en/tracing/other_telemetry/connect_logs_and_traces/nodejs.md @@ -25,7 +25,7 @@ further_reading: Enables automatic trace ID injection for `bunyan`, `paperplane`, `pino`, and `winston` when structured application loggers are used. -For older tracer versions injection can be enabled the environment variable `DD_LOGS_INJECTION=true` or by configuring the tracer directly: +For older tracer versions injection can be enabled the environment variable `DD_LOGS_INJECTION=true` or by configuring the SDK directly: ```javascript // This line must come before importing the logger. diff --git a/content/en/tracing/other_telemetry/connect_logs_and_traces/opentelemetry.md b/content/en/tracing/other_telemetry/connect_logs_and_traces/opentelemetry.md index 9ddc0f06f67..5d378d87498 100644 --- a/content/en/tracing/other_telemetry/connect_logs_and_traces/opentelemetry.md +++ b/content/en/tracing/other_telemetry/connect_logs_and_traces/opentelemetry.md @@ -320,7 +320,7 @@ This approach works with any logging library or language. The key requirements a If you collect logs directly with the Datadog Agent (without sending them through the OpenTelemetry Collector), you must ensure the trace IDs are present in your logs. -- **Trace ID format**: Datadog automatically detects the `dd.trace_id` and `dd.span_id` convention used by Datadog's tracing libraries, as well as the OpenTelemetry standards `trace_id` and `span_id`. See [OpenTelemetry Compatibility docs][6] for details on the standard. +- **Trace ID format**: Datadog automatically detects the `dd.trace_id` and `dd.span_id` convention used by Datadog SDKs, as well as the OpenTelemetry standards `trace_id` and `span_id`. See [OpenTelemetry Compatibility docs][6] for details on the standard.
If your logging instrumentation uses a different attribute name for your trace/span IDs, you must ensure the attribute is added to the Preprocessing for JSON logs configuration so it is recognized as a valid Trace ID.
diff --git a/content/en/tracing/services/inferred_services.md b/content/en/tracing/services/inferred_services.md
index 6c04565a8cb..1476b27679d 100644
--- a/content/en/tracing/services/inferred_services.md
+++ b/content/en/tracing/services/inferred_services.md
@@ -162,7 +162,7 @@ If the highest priority tag, such as `peer.db.name`, is not captured as part of
With inferred services, service dependencies are automatically detected from existing span attributes. As a result, changing service names (using the `service` tag) is not required to identify these dependencies.
-Enable `DD_TRACE_REMOVE_INTEGRATION_SERVICE_NAMES_ENABLED` to ensure no Datadog integration sets service names that are different from the default global service name. This also improves how service-to-service connections and inferred services are represented in Datadog visualizations, across all supported tracing library languages and integrations.
+Enable `DD_TRACE_REMOVE_INTEGRATION_SERVICE_NAMES_ENABLED` to ensure no Datadog integration sets service names that are different from the default global service name. This also improves how service-to-service connections and inferred services are represented in Datadog visualizations, across all supported SDK languages and integrations.
Enabling this option may impact existing APM metrics, custom span metrics, trace analytics, retention filters, sensitive data scans, monitors, dashboards, or notebooks that reference the old service names. Update these assets to use the global default service tag (
diff --git a/content/en/tracing/services/service_remapping_rules.md b/content/en/tracing/services/service_remapping_rules.md
index 1ac2dd8a456..b7ce11b6fec 100644
--- a/content/en/tracing/services/service_remapping_rules.md
+++ b/content/en/tracing/services/service_remapping_rules.md
@@ -20,7 +20,7 @@ You must have the `apm_service_renaming_write` permission to create remapping ru
### Tracer version requirements
-You can create service remapping rules only for services instrumented with supported tracer versions. If a service is reporting from an older tracer version, upgrade the tracer before creating remapping rules for that service.
+You can create service remapping rules only for services instrumented with supported tracer versions. If a service is reporting from an older tracer version, upgrade the SDK before creating remapping rules for that service.
| Language | Minimum supported tracer version |
|------------|----------------------------------|
diff --git a/content/en/tracing/trace_collection/automatic_instrumentation/dd_libraries/migrate/python/v3.md b/content/en/tracing/trace_collection/automatic_instrumentation/dd_libraries/migrate/python/v3.md
index 2bbbce16524..918fdae9118 100644
--- a/content/en/tracing/trace_collection/automatic_instrumentation/dd_libraries/migrate/python/v3.md
+++ b/content/en/tracing/trace_collection/automatic_instrumentation/dd_libraries/migrate/python/v3.md
@@ -112,7 +112,7 @@ pip install --upgrade ddtrace
#### Python 3.13 compatibility
-Full support for Python 3.13 is in active development. While the core tracing library is compatible, some integrations may not be fully tested or supported in the latest version.
+Full support for Python 3.13 is in active development. While the core SDK is compatible, some integrations may not be fully tested or supported in the latest version.
For the most current compatibility details for a specific integration, see the library's [latest release notes][19].
diff --git a/content/en/tracing/trace_collection/automatic_instrumentation/dd_libraries/migrate/python/v4.md b/content/en/tracing/trace_collection/automatic_instrumentation/dd_libraries/migrate/python/v4.md
index 8e00d8b566d..ec231397f7a 100644
--- a/content/en/tracing/trace_collection/automatic_instrumentation/dd_libraries/migrate/python/v4.md
+++ b/content/en/tracing/trace_collection/automatic_instrumentation/dd_libraries/migrate/python/v4.md
@@ -108,7 +108,7 @@ The following methods enforce stricter typing:
`DD_DJANGO_TRACING_MINIMAL` defaults to `true`.
- **Impact:** Django ORM, cache, and template instrumentation are disabled by default. This reduces performance overhead and eliminates duplicate spans, as underlying libraries (such as `psycopg`, `redis`, `jinja2`) are instrumented by their own integrations.
-- **Database Spans:** When `DD_DJANGO_INSTRUMENT_DATABASES=true` (default `false`), the tracer merges Django-specific tags into the driver spans rather than creating separate spans.
+- **Database Spans:** When `DD_DJANGO_INSTRUMENT_DATABASES=true` (default `false`), the SDK merges Django-specific tags into the driver spans rather than creating separate spans.
- **Restoration:** To restore full Django instrumentation, set `DD_DJANGO_TRACING_MINIMAL=false`.
#### OpenAI
diff --git a/content/en/tracing/trace_collection/compatibility/_index.md b/content/en/tracing/trace_collection/compatibility/_index.md
index 5b424a6ad3c..c28cb8d7788 100644
--- a/content/en/tracing/trace_collection/compatibility/_index.md
+++ b/content/en/tracing/trace_collection/compatibility/_index.md
@@ -1,11 +1,11 @@
---
title: Compatibility Requirements
-description: View compatibility requirements for Datadog tracing libraries including supported languages, frameworks, and runtime versions.
+description: View compatibility requirements for Datadog SDKs including supported languages, frameworks, and runtime versions.
type: multi-code-lang
further_reading:
- link: "/tracing/trace_collection/"
tag: "Documentation"
- text: "Add the tracing library to your application"
+ text: "Add the SDK to your application"
aliases:
- /tracing/compatibility
- /tracing/compatibility_requirements
diff --git a/content/en/tracing/trace_collection/compatibility/dotnet-framework.md b/content/en/tracing/trace_collection/compatibility/dotnet-framework.md
index 1bd5493cc57..4ee6c4253cb 100644
--- a/content/en/tracing/trace_collection/compatibility/dotnet-framework.md
+++ b/content/en/tracing/trace_collection/compatibility/dotnet-framework.md
@@ -41,7 +41,7 @@ The .NET Tracer supports automatic and custom instrumentation on the following .
Additional information can be found in [Microsoft's .NET Framework Lifecycle Policy][4] and in [.NET runtime support policy](#net-runtime-support-policy).
-service:<DD_SERVICE>).When deciding which tracer version to use for an automatic instrumentation, use the .NET Framework version installed on the application server. For example, if you compile your application to target .NET Framework 4.5.1, but the application runs on a server that has .NET Framework 4.8 installed, use the latest version of the tracer. To determine which version of .NET Framework is installed on a machine, follow the guidance provided by Microsoft.
+
The tracer supports the following Next.js features:
Note: Next.js is under heavy active development, and it is not uncommon for patch releases to break compatibility with dd-trace. Test automations alert Datadog to these issues, but it can often take a few days to fix compatibility with the latest Next.js release. | +| [next][18] | `>=10.2` | Fully supported | See note on [Complex framework usage](#complex-framework-usage).
The SDK supports the following Next.js features:
Note: Next.js is under heavy active development, and it is not uncommon for patch releases to break compatibility with dd-trace. Test automations alert Datadog to these issues, but it can often take a few days to fix compatibility with the latest Next.js release. | | [paperplane][19] | `>=2.3` | Fully supported | Not supported in [serverless-mode][20]. | | [restify][21] | `>=3` | Fully supported | | @@ -116,9 +116,9 @@ For details about how to how to toggle and configure plugins, check out the [API Some modern complex Node.js frameworks, such as Next.js and Nest.js, provide their own entry-point into an application. For example, instead of running `node app.js`, you may need to run `next start`. In these cases, the entry point is a file that ships in the framework package, not a local application file (`app.js`). -Loading the Datadog tracer early in your application code isn't effective because the framework could have already loaded modules that should be instrumented. +Loading the Datadog SDK early in your application code isn't effective because the framework could have already loaded modules that should be instrumented. -To load the tracer before the framework, use one of the following methods: +To load the SDK before the framework, use one of the following methods: Prefix all commands you run with an environment variable: @@ -229,7 +229,7 @@ The [JavaScript and TypeScript Tests][66] page contains a list of instrumented t ### Known transitive package compatibility -While the Datadog tracer doesn't provide direct support for modules listed here, they are known to work, as they depend on modules that the tracer does instrument. +While the Datadog SDK doesn't provide direct support for modules listed here, they are known to work, as they depend on modules that the SDK does instrument. | Module | Notes | | ---------------- | -------------------------------------------- | diff --git a/content/en/tracing/trace_collection/compatibility/php.md b/content/en/tracing/trace_collection/compatibility/php.md index 767d0dc1cec..3f567d77b4f 100644 --- a/content/en/tracing/trace_collection/compatibility/php.md +++ b/content/en/tracing/trace_collection/compatibility/php.md @@ -122,7 +122,7 @@ The following table enumerates some of the frameworks and versions Datadog succe | Zend Framework | 1.12, 1.21 | All supported PHP versions | Framework-level instrumentation | | Zend Framework | 2.x | All supported PHP versions | Generic web tracing | -Note that even if you don't see your web framework in this list, it is supported out of the box with the latest release of the tracer. +Note that even if you don't see your web framework in this list, it is supported out of the box with the latest release of the SDK. Datadog is continuously adding more support for in-depth tracing for PHP web-frameworks. To request support for additional span metadata and framework internals, contact our awesome [support team][3]. @@ -181,7 +181,7 @@ To request support for additional libraries, contact our awesome [support team][ Datadog supports tracing forked processes using [pcntl][7]. When a call to `pcntl_fork` is detected, a dedicated span is created, and the forked process is instrumented. This can be disabled with `DD_TRACE_FORKED_PROCESS`. Refer to the [library configuration page][9] for more details. -If the application invokes `pcntl_unshare(CLONE_NEWUSER);` and the tracer is installed, the application fatally crashes. This happens because `unshare` with `CLONE_NEWUSER` requires the process [not to be threaded][8], while the PHP tracer uses a separate thread to send traces to the Datadog Agent without blocking the main process. +If the application invokes `pcntl_unshare(CLONE_NEWUSER);` and the SDK is installed, the application fatally crashes. This happens because `unshare` with `CLONE_NEWUSER` requires the process [not to be threaded][8], while the PHP tracer uses a separate thread to send traces to the Datadog Agent without blocking the main process. ## Further Reading diff --git a/content/en/tracing/trace_collection/compatibility/php_v0.md b/content/en/tracing/trace_collection/compatibility/php_v0.md index d7a55ecac68..b7749326e71 100644 --- a/content/en/tracing/trace_collection/compatibility/php_v0.md +++ b/content/en/tracing/trace_collection/compatibility/php_v0.md @@ -112,7 +112,7 @@ The following table enumerates some of the frameworks and versions Datadog succe | Zend Framework | 1.12, 1.21 | All supported PHP versions | Framework-level instrumentation | | Zend Framework | 2.x | All supported PHP versions | Generic web tracing | -Note that even if you don't see your web framework in this list, it is supported out of the box with the latest release of the tracer. +Note that even if you don't see your web framework in this list, it is supported out of the box with the latest release of the SDK. Datadog is continuously adding more support for in-depth tracing for PHP web-frameworks. To request support for additional span metadata and framework internals, contact our awesome [support team][3]. @@ -175,7 +175,7 @@ Instrumenting [generators][6] is not supported on PHP 5 and PHP 7. Datadog supports tracing forked processes using [pcntl][7]. When a call to `pcntl_fork` is detected, a dedicated span is created, and the forked process is instrumented. This can be disabled with `DD_TRACE_FORKED_PROCESS`. Refer to the [library configuration page][9] for more details. -If the application invokes `pcntl_unshare(CLONE_NEWUSER);` and the tracer is installed, the application fatally crashes. This happens because `unshare` with `CLONE_NEWUSER` requires the process [not to be threaded][8], while the PHP tracer uses a separate thread to send traces to the Datadog Agent without blocking the main process. +If the application invokes `pcntl_unshare(CLONE_NEWUSER);` and the SDK is installed, the application fatally crashes. This happens because `unshare` with `CLONE_NEWUSER` requires the process [not to be threaded][8], while the PHP tracer uses a separate thread to send traces to the Datadog Agent without blocking the main process. ## Further Reading diff --git a/content/en/tracing/trace_collection/custom_instrumentation/_index.md b/content/en/tracing/trace_collection/custom_instrumentation/_index.md index 62e553c251d..82456a9e5a6 100644 --- a/content/en/tracing/trace_collection/custom_instrumentation/_index.md +++ b/content/en/tracing/trace_collection/custom_instrumentation/_index.md @@ -29,7 +29,7 @@ algolia: ## Overview -Code-based custom instrumentation allows for precise monitoring of specific components in your application. It allows you to capture observability data from in-house code or complex functions that aren't captured by automatic instrumentation. Automatic instrumentation includes [Single Step Instrumentation][5] or using [Datadog tracing libraries][6]. +Code-based custom instrumentation allows for precise monitoring of specific components in your application. It allows you to capture observability data from in-house code or complex functions that aren't captured by automatic instrumentation. Automatic instrumentation includes [Single Step Instrumentation][5] or using [Datadog SDKs][6]. 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. @@ -44,7 +44,7 @@ Follow the relevant documentation for your custom instrumentation approach to le {{< tabs >}} {{% tab "OpenTelemetry API (Recommended)" %}} -Datadog tracing libraries provide an implementation of the OpenTelemetry API for instrumenting your code. This means you can maintain vendor-neutral instrumentation of all your services, while still taking advantage of Datadog's native implementation, features, and products. You can configure it to generate Datadog-style spans and traces to be processed by the Datadog tracing library for your language, and send those to Datadog. +Datadog SDKs provide an implementation of the OpenTelemetry API for instrumenting your code. This means you can maintain vendor-neutral instrumentation of all your services, while still taking advantage of Datadog's native implementation, features, and products. You can configure it to generate Datadog-style spans and traces to be processed by the Datadog SDK for your language, and send those to Datadog. {{< partial name="apm/apm-otel-instrumentation-custom.html" >}} diff --git a/content/en/tracing/trace_collection/custom_instrumentation/client-side/android/dd-api.md b/content/en/tracing/trace_collection/custom_instrumentation/client-side/android/dd-api.md index 2acea23a67b..b1346ebf5d0 100644 --- a/content/en/tracing/trace_collection/custom_instrumentation/client-side/android/dd-api.md +++ b/content/en/tracing/trace_collection/custom_instrumentation/client-side/android/dd-api.md @@ -16,7 +16,7 @@ further_reading: --- Send [traces][1] to Datadog from your Android applications with [Datadog's -`dd-sdk-android-trace` client-side tracing library][2] and leverage the following features: +`dd-sdk-android-trace` client-side SDK][2] and leverage the following features: * Create custom [spans][3] for operations in your application. * Add `context` and extra custom attributes to each span sent. @@ -815,7 +815,7 @@ Request request = OkHttpRequestExtKt **Note**: * If you use multiple Interceptors, this one must be called first. -* If you define custom tracing header types in the Datadog configuration and are using a tracer +* If you define custom tracing header types in the Datadog configuration and are using an SDK registered with `GlobalDatadogTracer`, make sure the same tracing header types are set for the tracer in use. diff --git a/content/en/tracing/trace_collection/custom_instrumentation/client-side/android/otel.md b/content/en/tracing/trace_collection/custom_instrumentation/client-side/android/otel.md index b425dc72982..9c3054d841e 100644 --- a/content/en/tracing/trace_collection/custom_instrumentation/client-side/android/otel.md +++ b/content/en/tracing/trace_collection/custom_instrumentation/client-side/android/otel.md @@ -356,7 +356,7 @@ Trace.enable(traceConfig); {{% /tab %}} {{< /tabs >}} -4. Datadog tracer implements the [OpenTelemetry standard][18]. Create `OtelTracerProvider` and register `OpenTelemetrySdk` in `GlobalOpenTelemetry` in your `onCreate()` method: +4. Datadog SDK implements the [OpenTelemetry standard][18]. Create `OtelTracerProvider` and register `OpenTelemetrySdk` in `GlobalOpenTelemetry` in your `onCreate()` method: {{< tabs >}} {{% tab "Kotlin" %}} @@ -374,7 +374,7 @@ GlobalOpenTelemetry.set(object : OpenTelemetry { return ContextPropagators.noop() } }) -// and later on if you want to access the tracer +// and later on if you want to access the SDK val tracer = GlobalOpenTelemetry.get().getTracer(instrumentationName = "")
```
{{% /tab %}}
@@ -395,7 +395,7 @@ GlobalOpenTelemetry.set(new OpenTelemetry() {
return ContextPropagators.noop();
}
});
-// and later on if you want to access the tracer
+// and later on if you want to access the SDK
final Tracer tracer = GlobalOpenTelemetry.get().getTracer("");
```
{{% /tab %}}
@@ -403,7 +403,7 @@ final Tracer tracer = GlobalOpenTelemetry.get().getTracer("}}
-3. Datadog tracer implements the [Open Telemetry standard][13]. Enable the Datadog tracer, register the tracer provider, and get the tracer instance:
+3. Datadog SDK implements the [Open Telemetry standard][13]. Enable the Datadog SDK, register the SDK provider, and get the SDK instance:
{{< tabs >}}
{{% tab "Swift" %}}
diff --git a/content/en/tracing/trace_collection/custom_instrumentation/go/migration.md b/content/en/tracing/trace_collection/custom_instrumentation/go/migration.md
index 9d34397c1d2..8d06241aaed 100644
--- a/content/en/tracing/trace_collection/custom_instrumentation/go/migration.md
+++ b/content/en/tracing/trace_collection/custom_instrumentation/go/migration.md
@@ -11,7 +11,7 @@ further_reading:
## Overview
-The Go tracer v2 introduces API improvements, better performance, and enhanced compatibility with modern Go practices. It represents the latest stable version of Datadog's Go tracing library.
+The Go tracer v2 introduces API improvements, better performance, and enhanced compatibility with modern Go practices. It represents the latest stable version of Datadog's Go SDK.
## Compatibility
@@ -236,7 +236,7 @@ ddtrace.Start(ddtrace.WithService("my-service"))
```
#### WithDogstatsdAddress
-`tracer.WithDogstatsdAddress` has been renamed to `tracer.WithDogstatsdAddr`. Use this option to specify a different DogStatsD address when starting the tracer.
+`tracer.WithDogstatsdAddress` has been renamed to `tracer.WithDogstatsdAddr`. Use this option to specify a different DogStatsD address when starting the SDK.
v1:
```go
diff --git a/content/en/tracing/trace_collection/custom_instrumentation/opentracing/android.md b/content/en/tracing/trace_collection/custom_instrumentation/opentracing/android.md
index 2845b706c20..c8e352bd90a 100644
--- a/content/en/tracing/trace_collection/custom_instrumentation/opentracing/android.md
+++ b/content/en/tracing/trace_collection/custom_instrumentation/opentracing/android.md
@@ -13,7 +13,7 @@ further_reading:
text: Explore your services, resources, and traces
title: Tracing Android Applications
---
-(tracer);
- // Use the tracer with OpenTracing.GlobalTracer.Instance
+ // Use the SDK with OpenTracing.GlobalTracer.Instance
GlobalTracer.Register(tracer);
}
```
diff --git a/content/en/tracing/trace_collection/custom_instrumentation/opentracing/java.md b/content/en/tracing/trace_collection/custom_instrumentation/opentracing/java.md
index 70c692a47f6..bcd93019b8f 100644
--- a/content/en/tracing/trace_collection/custom_instrumentation/opentracing/java.md
+++ b/content/en/tracing/trace_collection/custom_instrumentation/opentracing/java.md
@@ -11,7 +11,7 @@ code_lang_weight: 0
---
-")
my_operation()
```
-The tracer can now be used like in any other OpenTracing application. See [opentracing.io][1] for OpenTracing Python usage.
+The SDK can now be used like in any other OpenTracing application. See [opentracing.io][1] for OpenTracing Python usage.
[1]: https://opentracing.io/guides/python/
diff --git a/content/en/tracing/trace_collection/custom_instrumentation/opentracing/ruby.md b/content/en/tracing/trace_collection/custom_instrumentation/opentracing/ruby.md
index 0ae4c1b6f67..1abafcf4df7 100644
--- a/content/en/tracing/trace_collection/custom_instrumentation/opentracing/ruby.md
+++ b/content/en/tracing/trace_collection/custom_instrumentation/opentracing/ruby.md
@@ -10,13 +10,13 @@ type: multi-code-lang
code_lang_weight: 20
---
-
-To instrument an application written in a language that does not have official library support, see the list of [community tracing libraries][1]. +To instrument an application written in a language that does not have official library support, see the list of [community SDKs][1]. [1]: /extend/community/libraries/#apm-tracing-client-libraries diff --git a/content/en/tracing/trace_collection/dd_libraries/android.md b/content/en/tracing/trace_collection/dd_libraries/android.md index b57c491f69a..46649bdd920 100644 --- a/content/en/tracing/trace_collection/dd_libraries/android.md +++ b/content/en/tracing/trace_collection/dd_libraries/android.md @@ -16,7 +16,7 @@ further_reading: text: Explore your services, resources, and traces title: Tracing Android Applications --- -Send [traces][1] to Datadog from your Android applications with [Datadog's `dd-sdk-android-trace` client-side tracing library][2] and leverage the following features: +Send [traces][1] to Datadog from your Android applications with [Datadog's `dd-sdk-android-trace` client-side SDK][2] and leverage the following features: * Create custom [spans][3] for operations in your application. * Add `context` and extra custom attributes to each span sent. @@ -820,7 +820,7 @@ Request request = OkHttpRequestExtKt **Note**: * If you use multiple Interceptors, this one must be called first. -* If you define custom tracing header types in the Datadog configuration and are using a tracer registered with `GlobalDatadogTracer`, make sure the same tracing header types are set for the tracer in use. +* If you define custom tracing header types in the Datadog configuration and are using an SDK registered with `GlobalDatadogTracer`, make sure the same tracing header types are set for the SDK in use. ### Cronet diff --git a/content/en/tracing/trace_collection/dd_libraries/cpp.md b/content/en/tracing/trace_collection/dd_libraries/cpp.md index 4a2a799a999..8b30b96d4bb 100644 --- a/content/en/tracing/trace_collection/dd_libraries/cpp.md +++ b/content/en/tracing/trace_collection/dd_libraries/cpp.md @@ -28,7 +28,7 @@ further_reading:
## Compatibility requirements
-The C++ tracing library requires C++17 toolchain to build. For a full list of Datadog's tracing library compatiblity requirements and processor architecture support, visit the [Compatibility Requirements][3] page.
+The C++ SDK requires C++17 toolchain to build. For a full list of the Datadog SDK compatiblity requirements and processor architecture support, visit the [Compatibility Requirements][3] page.
## Getting started
Before you begin, make sure you have already [installed and configured the Agent][6].
@@ -36,7 +36,7 @@ Before you begin, make sure you have already [installed and configured the Agent
## Instrument your application
Here is an example application that can be used for testing `dd-trace-cpp`.
-This application creates a tracer instance with the default settings and generates a trace with two spans, which is reported under the service name `my-service`.
+This application creates an SDK instance with the default settings and generates a trace with two spans, which is reported under the service name `my-service`.
```cpp
// tracer_example.cpp
@@ -192,7 +192,7 @@ DATADOG TRACER CONFIGURATION - {"collector":{"config":{"event_scheduler":{"type"
## Configuration
-If needed, configure the tracing library to send application performance telemetry data as you require, including setting up Unified Service Tagging. Read [Library Configuration][5] for details.
+If needed, configure the SDK to send application performance telemetry data as you require, including setting up Unified Service Tagging. Read [Library Configuration][5] for details.
## Further Reading
diff --git a/content/en/tracing/trace_collection/dd_libraries/dotnet-core.md b/content/en/tracing/trace_collection/dd_libraries/dotnet-core.md
index 7a252e763d4..4398acb9d9e 100644
--- a/content/en/tracing/trace_collection/dd_libraries/dotnet-core.md
+++ b/content/en/tracing/trace_collection/dd_libraries/dotnet-core.md
@@ -73,13 +73,13 @@ For a full list of Datadog's .NET Core library and processor architecture suppor
Before you begin, make sure you've already [installed and configured the Agent][12].
-1. [Install the tracer.](#install-the-tracer)
-2. [Enable the tracer for your service.](#enable-the-tracer-for-your-service)
+1. [Install the SDK.](#install-the-sdk)
+2. [Enable the SDK for your service.](#enable-the-sdk-for-your-service)
3. [View your live data.](#view-your-live-data)
-### Install the tracer
+### Install the SDK
-After you install and configure your Datadog Agent, the next step is to add the tracing library directly in the application to instrument it. Read more about [compatibility information][1].
+After you install and configure your Datadog Agent, the next step is to add the SDK directly in the application to instrument it. Read more about [compatibility information][1].
You can install the Datadog .NET Tracer machine-wide so that all services on the machine are instrumented, or you can install it on a per-application basis to allow developers to manage the instrumentation through the application's dependencies. To see machine-wide installation instructions, click the Windows or Linux tab. To see per-application installation instructions, click the NuGet tab.
@@ -122,7 +122,7 @@ To install the .NET Tracer machine-wide:
To install the .NET Tracer in chiseled or distroless Docker images (without a shell), use the following Dockerfile commands:
-- Use `ADD` to put the tracer files in the container.
+- Use `ADD` to put the SDK files in the container.
- Use `COPY --chown=$APP_UID` with an empty folder as source to create the logs path.
For example, in your Dockerfile:
@@ -150,7 +150,7 @@ To install the .NET Tracer per-application:
{{< /tabs >}}
-### Enable the tracer for your service
+### Enable the SDK for your service
To enable the .NET Tracer for your service, set the required environment variables and restart the application.
@@ -177,7 +177,7 @@ For information about the different methods for setting environment variables, s
```
When deciding which tracer version to use for an automatic instrumentation, use the .NET Framework version installed on the application server. For example, if you compile your application to target .NET Framework 4.5.1, but the application runs on a server that has .NET Framework 4.8 installed, use the latest version of the SDK. To determine which version of .NET Framework is installed on a machine, follow the guidance provided by Microsoft.
## Supported operating systems
diff --git a/content/en/tracing/trace_collection/compatibility/go.md b/content/en/tracing/trace_collection/compatibility/go.md
index fcbdfea67b5..3eef2f371fb 100644
--- a/content/en/tracing/trace_collection/compatibility/go.md
+++ b/content/en/tracing/trace_collection/compatibility/go.md
@@ -24,7 +24,7 @@ The Go Datadog Trace Library has a [version support policy][2] defined for Go ve
- Datadog Agent v5.21.1+.
- Instrument your application before configuring integrations using one of the following methods:
* [Automatically at compile time using `orchestrion`][78]
- * [Manually add and initialize the Datadog Go tracer][77]
+ * [Manually add and initialize the Datadog Go SDK][77]
### Go Tracer support
diff --git a/content/en/tracing/trace_collection/compatibility/java.md b/content/en/tracing/trace_collection/compatibility/java.md
index dc0e2ccb825..9efcdf6abb6 100644
--- a/content/en/tracing/trace_collection/compatibility/java.md
+++ b/content/en/tracing/trace_collection/compatibility/java.md
@@ -179,7 +179,7 @@ Don't see your desired web frameworks? Datadog is continually adding additional
| Spring SessionAwareMessageListener | 3.1+ | Fully Supported | `spring-jms-3.1` |
| Spring WebClient | 5.0+ | Fully Supported | `spring-webflux`, `spring-webflux-client` |
-**Kafka Note**: Datadog's Kafka integration works with Kafka version `0.11+`, which supports the Header API. This API is used to inject and extract trace context. If you are running a mixed version environment, the Kafka broker can incorrectly report the newer version of Kafka. This causes an issue when the tracer tries to inject headers that are not supported by the local producer. Additionally, older consumers are unable to consume the message because of the presence of headers. To prevent these issues, if you are running a mixed version Kafka environment with versions older than 0.11, disable context propagation with the environment variable: `DD_KAFKA_CLIENT_PROPAGATION_ENABLED=false`.
+**Kafka Note**: Datadog's Kafka integration works with Kafka version `0.11+`, which supports the Header API. This API is used to inject and extract trace context. If you are running a mixed version environment, the Kafka broker can incorrectly report the newer version of Kafka. This causes an issue when the SDK tries to inject headers that are not supported by the local producer. Additionally, older consumers are unable to consume the message because of the presence of headers. To prevent these issues, if you are running a mixed version Kafka environment with versions older than 0.11, disable context propagation with the environment variable: `DD_KAFKA_CLIENT_PROPAGATION_ENABLED=false`.
**JMS Note**: Datadog's JMS integration automatically adds and reads message object properties `x__dash__datadog__dash__trace__dash__id` and `x__dash__datadog__dash__parent__dash__id` to maintain context propagation between consumer and producer services.
@@ -297,7 +297,7 @@ Integrations can be enabled or disabled individually (overriding the default abo
- Running the Java tracer in Bitbucket is not supported.
- Loading multiple Java Agents that perform APM/tracing functions is not a recommended or supported configuration.
-- When running the tracer with Java 24+, you may see warnings related to JNI native access. Suppress these warnings by adding the `--enable-native-access=ALL-UNNAMED` flag. See [JEP 472][13] for more information.
+- When running the SDK with Java 24+, you may see warnings related to JNI native access. Suppress these warnings by adding the `--enable-native-access=ALL-UNNAMED` flag. See [JEP 472][13] for more information.
## Ahead-of-time (AOT) class loading & linking support
@@ -308,18 +308,18 @@ To improve startup time, Ahead-of-time (AOT) class loading & linking makes appli
Use:
- Java 25 or later
-- [Datadog Java tracer][1] 1.57.0 or later
+- [Datadog Java SDK][1] 1.57.0 or later
### Setup
-To set up AOT class loading & linking for APM, add the Datadog Java tracer during the training run:
+To set up AOT class loading & linking for APM, add the Datadog Java SDK during the training run:
```shell
java -javaagent:/path/to/dd-java-agent.jar -XX:AOTCacheOutput=app.aot -jar App.jar
```
#### Usage
-During production, add the same Datadog Java tracer along with the previously cached training data:
+During production, add the same Datadog Java SDK along with the previously cached training data:
```shell
java -javaagent:/path/to/dd-java-agent.jar -XX:AOTCache=app.aot -jar App.jar
```
@@ -327,32 +327,32 @@ java -javaagent:/path/to/dd-java-agent.jar -XX:AOTCache=app.aot -jar App.jar
You can view traces using the [Trace Explorer][9].
{{% collapse-content title="Troubleshooting" level="h4" %}}
-##### Not attaching the Datadog Java tracer during the training run
+##### Not attaching the Datadog Java SDK during the training run
-If you see this warning in production, it means the Datadog Java tracer wasn't attached during training:
+If you see this warning in production, it means the Datadog Java SDK wasn't attached during training:
```
Mismatched values for property jdk.module.addmods: java.instrument specified during runtime but not during dump time
```
-The JVM cannot then use the AOT cache to improve startup time. The solution is to attach the tracer during training.
+The JVM cannot then use the AOT cache to improve startup time. The solution is to attach the SDK during training.
{{% /collapse-content %}}
## GraalVM Native Image support
-GraalVM Native Image is a technology that allows you to compile Java applications into native executables. The Datadog Java tracer supports GraalVM Native Image. This allows you to compile your applications into native executables while still benefiting from the tracing capabilities offered by the library.
+GraalVM Native Image is a technology that allows you to compile Java applications into native executables. The Datadog Java SDK supports GraalVM Native Image. This allows you to compile your applications into native executables while still benefiting from the tracing capabilities offered by the library.
### Requirements
Use:
- [GraalVM JDK 21 or JDK 25][7]
-- [Datadog Java tracer][1]
+- [Datadog Java SDK][1]
### Setup
{{< tabs >}}
{{% tab "GraalVM" %}}
-To set up the Datadog Java tracer with GraalVM Native Image, follow these steps:
+To set up the Datadog Java SDK with GraalVM Native Image, follow these steps:
1. Instrument your application, following the steps described on [Tracing Java Applications][6].
2. When you build a native executable with the `native-image` command, add the `-J-javaagent:/path/to/dd-java-agent.jar` argument. For example:
@@ -367,7 +367,7 @@ To set up the Datadog Java tracer with GraalVM Native Image, follow these steps:
{{% /tab %}}
{{% tab "Quarkus Native" %}}
-To set up the Datadog Java tracer with Quarkus Native, follow these steps:
+To set up the Datadog Java SDK with Quarkus Native, follow these steps:
1. Instrument your application, following the steps described in [Tracing Java Applications][6].
2. When you build a native executable, use the `quarkus.native.additional-build-args` property. For example:
@@ -382,7 +382,7 @@ To set up the Datadog Java tracer with Quarkus Native, follow these steps:
{{% /tab %}}
{{% tab "Spring Native" %}}
-To set up the Datadog Java tracer with Spring Native, follow these steps:
+To set up the Datadog Java SDK with Spring Native, follow these steps:
1. Instrument your application, following the steps described on [Tracing Java Applications][6].
2. For Spring Native builds based on Buildpacks, enable the [Paketo Buildpack for Datadog][8] using `BP_DATADOG_ENABLED=true`.
@@ -499,7 +499,7 @@ The solution is to explicitly set the `BP_NATIVE_IMAGE` environment variable to
```
-##### Problem activating Datadog tracer
+##### Problem activating Datadog SDK
You might encounter initialization errors if your tracer configuration relies on Unix Domain Sockets (UDS), which are not supported in native images:
diff --git a/content/en/tracing/trace_collection/compatibility/nodejs.md b/content/en/tracing/trace_collection/compatibility/nodejs.md
index e9bb56df091..78c00c29495 100644
--- a/content/en/tracing/trace_collection/compatibility/nodejs.md
+++ b/content/en/tracing/trace_collection/compatibility/nodejs.md
@@ -16,7 +16,7 @@ further_reading:
### Versioning
-Versioning of the Datadog Node.js tracing library follows [semver][1]. When a new major version is released it becomes the primary release line, where all new features, bug fixes and security patches land. Here's an outline of what constitutes each type of semver change:
+Versioning of the Datadog Node.js SDK follows [semver][1]. When a new major version is released it becomes the primary release line, where all new features, bug fixes and security patches land. Here's an outline of what constitutes each type of semver change:
| Major | Minor | Patch |
|---------------------------------|-------------------------------------------------------------------------|----------------------|
@@ -108,7 +108,7 @@ For details about how to how to toggle and configure plugins, check out the [API
| [koa][13] | `>=2` | Fully supported | |
| [microgateway-core][14] | `>=2.1` | Fully supported | Core library for Apigee Edge. Support for the [edgemicro][15] CLI requires static patching using [@datadog/cli][16]. |
| [moleculer][17] | `>=0.14` | Fully supported | |
-| [next][18] | `>=10.2` | Fully supported | See note on [Complex framework usage](#complex-framework-usage).The tracer supports the following Next.js features:
- Standalone (`output: 'standalone'`)
- App Router
- Middleware: Not traced, use tracer versions `4.18.0` and `3.39.0` or higher for best experience.
Note: Next.js is under heavy active development, and it is not uncommon for patch releases to break compatibility with dd-trace. Test automations alert Datadog to these issues, but it can often take a few days to fix compatibility with the latest Next.js release. | +| [next][18] | `>=10.2` | Fully supported | See note on [Complex framework usage](#complex-framework-usage).
The SDK supports the following Next.js features:
- Standalone (`output: 'standalone'`)
- App Router
- Middleware: Not traced, use tracer versions `4.18.0` and `3.39.0` or higher for best experience.
Note: Next.js is under heavy active development, and it is not uncommon for patch releases to break compatibility with dd-trace. Test automations alert Datadog to these issues, but it can often take a few days to fix compatibility with the latest Next.js release. | | [paperplane][19] | `>=2.3` | Fully supported | Not supported in [serverless-mode][20]. | | [restify][21] | `>=3` | Fully supported | | @@ -116,9 +116,9 @@ For details about how to how to toggle and configure plugins, check out the [API Some modern complex Node.js frameworks, such as Next.js and Nest.js, provide their own entry-point into an application. For example, instead of running `node app.js`, you may need to run `next start`. In these cases, the entry point is a file that ships in the framework package, not a local application file (`app.js`). -Loading the Datadog tracer early in your application code isn't effective because the framework could have already loaded modules that should be instrumented. +Loading the Datadog SDK early in your application code isn't effective because the framework could have already loaded modules that should be instrumented. -To load the tracer before the framework, use one of the following methods: +To load the SDK before the framework, use one of the following methods: Prefix all commands you run with an environment variable: @@ -229,7 +229,7 @@ The [JavaScript and TypeScript Tests][66] page contains a list of instrumented t ### Known transitive package compatibility -While the Datadog tracer doesn't provide direct support for modules listed here, they are known to work, as they depend on modules that the tracer does instrument. +While the Datadog SDK doesn't provide direct support for modules listed here, they are known to work, as they depend on modules that the SDK does instrument. | Module | Notes | | ---------------- | -------------------------------------------- | diff --git a/content/en/tracing/trace_collection/compatibility/php.md b/content/en/tracing/trace_collection/compatibility/php.md index 767d0dc1cec..3f567d77b4f 100644 --- a/content/en/tracing/trace_collection/compatibility/php.md +++ b/content/en/tracing/trace_collection/compatibility/php.md @@ -122,7 +122,7 @@ The following table enumerates some of the frameworks and versions Datadog succe | Zend Framework | 1.12, 1.21 | All supported PHP versions | Framework-level instrumentation | | Zend Framework | 2.x | All supported PHP versions | Generic web tracing | -Note that even if you don't see your web framework in this list, it is supported out of the box with the latest release of the tracer. +Note that even if you don't see your web framework in this list, it is supported out of the box with the latest release of the SDK. Datadog is continuously adding more support for in-depth tracing for PHP web-frameworks. To request support for additional span metadata and framework internals, contact our awesome [support team][3]. @@ -181,7 +181,7 @@ To request support for additional libraries, contact our awesome [support team][ Datadog supports tracing forked processes using [pcntl][7]. When a call to `pcntl_fork` is detected, a dedicated span is created, and the forked process is instrumented. This can be disabled with `DD_TRACE_FORKED_PROCESS`. Refer to the [library configuration page][9] for more details. -If the application invokes `pcntl_unshare(CLONE_NEWUSER);` and the tracer is installed, the application fatally crashes. This happens because `unshare` with `CLONE_NEWUSER` requires the process [not to be threaded][8], while the PHP tracer uses a separate thread to send traces to the Datadog Agent without blocking the main process. +If the application invokes `pcntl_unshare(CLONE_NEWUSER);` and the SDK is installed, the application fatally crashes. This happens because `unshare` with `CLONE_NEWUSER` requires the process [not to be threaded][8], while the PHP tracer uses a separate thread to send traces to the Datadog Agent without blocking the main process. ## Further Reading diff --git a/content/en/tracing/trace_collection/compatibility/php_v0.md b/content/en/tracing/trace_collection/compatibility/php_v0.md index d7a55ecac68..b7749326e71 100644 --- a/content/en/tracing/trace_collection/compatibility/php_v0.md +++ b/content/en/tracing/trace_collection/compatibility/php_v0.md @@ -112,7 +112,7 @@ The following table enumerates some of the frameworks and versions Datadog succe | Zend Framework | 1.12, 1.21 | All supported PHP versions | Framework-level instrumentation | | Zend Framework | 2.x | All supported PHP versions | Generic web tracing | -Note that even if you don't see your web framework in this list, it is supported out of the box with the latest release of the tracer. +Note that even if you don't see your web framework in this list, it is supported out of the box with the latest release of the SDK. Datadog is continuously adding more support for in-depth tracing for PHP web-frameworks. To request support for additional span metadata and framework internals, contact our awesome [support team][3]. @@ -175,7 +175,7 @@ Instrumenting [generators][6] is not supported on PHP 5 and PHP 7. Datadog supports tracing forked processes using [pcntl][7]. When a call to `pcntl_fork` is detected, a dedicated span is created, and the forked process is instrumented. This can be disabled with `DD_TRACE_FORKED_PROCESS`. Refer to the [library configuration page][9] for more details. -If the application invokes `pcntl_unshare(CLONE_NEWUSER);` and the tracer is installed, the application fatally crashes. This happens because `unshare` with `CLONE_NEWUSER` requires the process [not to be threaded][8], while the PHP tracer uses a separate thread to send traces to the Datadog Agent without blocking the main process. +If the application invokes `pcntl_unshare(CLONE_NEWUSER);` and the SDK is installed, the application fatally crashes. This happens because `unshare` with `CLONE_NEWUSER` requires the process [not to be threaded][8], while the PHP tracer uses a separate thread to send traces to the Datadog Agent without blocking the main process. ## Further Reading diff --git a/content/en/tracing/trace_collection/custom_instrumentation/_index.md b/content/en/tracing/trace_collection/custom_instrumentation/_index.md index 62e553c251d..82456a9e5a6 100644 --- a/content/en/tracing/trace_collection/custom_instrumentation/_index.md +++ b/content/en/tracing/trace_collection/custom_instrumentation/_index.md @@ -29,7 +29,7 @@ algolia: ## Overview -Code-based custom instrumentation allows for precise monitoring of specific components in your application. It allows you to capture observability data from in-house code or complex functions that aren't captured by automatic instrumentation. Automatic instrumentation includes [Single Step Instrumentation][5] or using [Datadog tracing libraries][6]. +Code-based custom instrumentation allows for precise monitoring of specific components in your application. It allows you to capture observability data from in-house code or complex functions that aren't captured by automatic instrumentation. Automatic instrumentation includes [Single Step Instrumentation][5] or using [Datadog SDKs][6]. 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. @@ -44,7 +44,7 @@ Follow the relevant documentation for your custom instrumentation approach to le {{< tabs >}} {{% tab "OpenTelemetry API (Recommended)" %}} -Datadog tracing libraries provide an implementation of the OpenTelemetry API for instrumenting your code. This means you can maintain vendor-neutral instrumentation of all your services, while still taking advantage of Datadog's native implementation, features, and products. You can configure it to generate Datadog-style spans and traces to be processed by the Datadog tracing library for your language, and send those to Datadog. +Datadog SDKs provide an implementation of the OpenTelemetry API for instrumenting your code. This means you can maintain vendor-neutral instrumentation of all your services, while still taking advantage of Datadog's native implementation, features, and products. You can configure it to generate Datadog-style spans and traces to be processed by the Datadog SDK for your language, and send those to Datadog. {{< partial name="apm/apm-otel-instrumentation-custom.html" >}} diff --git a/content/en/tracing/trace_collection/custom_instrumentation/client-side/android/dd-api.md b/content/en/tracing/trace_collection/custom_instrumentation/client-side/android/dd-api.md index 2acea23a67b..b1346ebf5d0 100644 --- a/content/en/tracing/trace_collection/custom_instrumentation/client-side/android/dd-api.md +++ b/content/en/tracing/trace_collection/custom_instrumentation/client-side/android/dd-api.md @@ -16,7 +16,7 @@ further_reading: --- Send [traces][1] to Datadog from your Android applications with [Datadog's -`dd-sdk-android-trace` client-side tracing library][2] and leverage the following features: +`dd-sdk-android-trace` client-side SDK][2] and leverage the following features: * Create custom [spans][3] for operations in your application. * Add `context` and extra custom attributes to each span sent. @@ -815,7 +815,7 @@ Request request = OkHttpRequestExtKt **Note**: * If you use multiple Interceptors, this one must be called first. -* If you define custom tracing header types in the Datadog configuration and are using a tracer +* If you define custom tracing header types in the Datadog configuration and are using an SDK registered with `GlobalDatadogTracer`, make sure the same tracing header types are set for the tracer in use. diff --git a/content/en/tracing/trace_collection/custom_instrumentation/client-side/android/otel.md b/content/en/tracing/trace_collection/custom_instrumentation/client-side/android/otel.md index b425dc72982..9c3054d841e 100644 --- a/content/en/tracing/trace_collection/custom_instrumentation/client-side/android/otel.md +++ b/content/en/tracing/trace_collection/custom_instrumentation/client-side/android/otel.md @@ -356,7 +356,7 @@ Trace.enable(traceConfig); {{% /tab %}} {{< /tabs >}} -4. Datadog tracer implements the [OpenTelemetry standard][18]. Create `OtelTracerProvider` and register `OpenTelemetrySdk` in `GlobalOpenTelemetry` in your `onCreate()` method: +4. Datadog SDK implements the [OpenTelemetry standard][18]. Create `OtelTracerProvider` and register `OpenTelemetrySdk` in `GlobalOpenTelemetry` in your `onCreate()` method: {{< tabs >}} {{% tab "Kotlin" %}} @@ -374,7 +374,7 @@ GlobalOpenTelemetry.set(object : OpenTelemetry { return ContextPropagators.noop() } }) -// and later on if you want to access the tracer +// and later on if you want to access the SDK val tracer = GlobalOpenTelemetry.get().getTracer(instrumentationName = "
OpenTracing support is based on a deprecated specification. If you want to instrument your code with an open spec, use OpenTelemetry instead. Try processing data from OpenTelemetry instrumentation in Datadog Tracing Libraries.
+OpenTracing support is based on a deprecated specification. If you want to instrument your code with an open spec, use OpenTelemetry instead. Try processing data from OpenTelemetry instrumentation in Datadog SDKs.
Datadog integrates with the [OpenTracing API][1].
## Setup
@@ -813,7 +813,7 @@ Request request = OkHttpRequestExtKt
**Note**:
* If you use multiple Interceptors, this one must be called first.
-* If you define custom tracing header types in the Datadog configuration and are using a tracer registered with `GlobalTracer`, make sure the same tracing header types are set for the tracer in use.
+* If you define custom tracing header types in the Datadog configuration and are using an SDK registered with `GlobalTracer`, make sure the same tracing header types are set for the SDK in use.
### RxJava
diff --git a/content/en/tracing/trace_collection/custom_instrumentation/opentracing/dotnet.md b/content/en/tracing/trace_collection/custom_instrumentation/opentracing/dotnet.md
index db3447a5344..fe61abaed79 100644
--- a/content/en/tracing/trace_collection/custom_instrumentation/opentracing/dotnet.md
+++ b/content/en/tracing/trace_collection/custom_instrumentation/opentracing/dotnet.md
@@ -13,7 +13,7 @@ further_reading:
text: 'Propagating trace context'
---
-OpenTracing support is based on a deprecated specification. If you want to instrument your code with an open spec, use OpenTelemetry instead. Try processing data from OpenTelemetry instrumentation in Datadog Tracing Libraries.
+OpenTracing support is based on a deprecated specification. If you want to instrument your code with an open spec, use OpenTelemetry instead. Try processing data from OpenTelemetry instrumentation in Datadog SDKs.
For more details and information, view the [OpenTracing API][1].
@@ -33,10 +33,10 @@ public void ConfigureServices(IServiceCollection services)
// Create an OpenTracing ITracer with the default setting
OpenTracing.ITracer tracer = OpenTracingTracerFactory.CreateTracer();
- // Use the tracer with ASP.NET Core dependency injection
+ // Use the SDK with ASP.NET Core dependency injection
services.AddSingletonOpenTracing support is based on a deprecated specification. If you want to instrument your code with an open spec, use OpenTelemetry instead. Try processing data from OpenTelemetry instrumentation in Datadog Tracing Libraries.
+OpenTracing support is based on a deprecated specification. If you want to instrument your code with an open spec, use OpenTelemetry instead. Try processing data from OpenTelemetry instrumentation in Datadog SDKs.
Datadog integrates with the [OpenTracing API][1].
diff --git a/content/en/tracing/trace_collection/custom_instrumentation/opentracing/nodejs.md b/content/en/tracing/trace_collection/custom_instrumentation/opentracing/nodejs.md
index 2c622d64920..272f7683190 100644
--- a/content/en/tracing/trace_collection/custom_instrumentation/opentracing/nodejs.md
+++ b/content/en/tracing/trace_collection/custom_instrumentation/opentracing/nodejs.md
@@ -11,7 +11,7 @@ code_lang_weight: 40
---
-OpenTracing support is based on a deprecated specification. If you want to instrument your code with an open spec, use OpenTelemetry instead. Try processing data from OpenTelemetry instrumentation in Datadog Tracing Libraries.
+OpenTracing support is based on a deprecated specification. If you want to instrument your code with an open spec, use OpenTelemetry instead. Try processing data from OpenTelemetry instrumentation in Datadog SDKs.
OpenTracing support is included in the `dd-trace` package.
@@ -22,11 +22,11 @@ const opentracing = require('opentracing')
opentracing.initGlobalTracer(tracer)
```
-Use the tracer like in any other OpenTracing application.
+Use the SDK like in any other OpenTracing application.
The following tags are available to override Datadog specific options:
-* `service.name`: The service name to be used for the span. The service name from the tracer will be used if this is not provided.
+* `service.name`: The service name to be used for the span. The service name from the SDK will be used if this is not provided.
* `resource.name`: The resource name to be used for the span. The operation name will be used if this is not provided.
* `span.type`: The span type to be used for the span. Will fallback to `custom` if not provided.
diff --git a/content/en/tracing/trace_collection/custom_instrumentation/opentracing/python.md b/content/en/tracing/trace_collection/custom_instrumentation/opentracing/python.md
index 96b52ba15e7..ca9ffb259f1 100644
--- a/content/en/tracing/trace_collection/custom_instrumentation/opentracing/python.md
+++ b/content/en/tracing/trace_collection/custom_instrumentation/opentracing/python.md
@@ -10,7 +10,7 @@ type: multi-code-lang
code_lang_weight: 10
---
-OpenTracing support is based on a deprecated specification. If you want to instrument your code with an open spec, use OpenTelemetry instead. Try processing data from OpenTelemetry instrumentation in Datadog Tracing Libraries.
+OpenTracing support is based on a deprecated specification. If you want to instrument your code with an open spec, use OpenTelemetry instead. Try processing data from OpenTelemetry instrumentation in Datadog SDKs.
OpenTracing support is included in the `ddtrace` package. Use `pip` to install the required `opentracing` package:
@@ -18,7 +18,7 @@ OpenTracing support is included in the `ddtrace` package. Use `pip` to install t
pip install ddtrace[opentracing]
```
-The OpenTracing convention for initializing a tracer is to define an initialization method that configures and instantiates a new tracer and overwrites the global `opentracing.tracer` reference:
+The OpenTracing convention for initializing an SDK is to define an initialization method that configures and instantiates a new tracer and overwrites the global `opentracing.tracer` reference:
```python
import time
@@ -44,7 +44,7 @@ init_tracer("OpenTracing support is based on a deprecated specification. If you want to instrument your code with an open spec, use OpenTelemetry instead. Try processing data from OpenTelemetry instrumentation in Datadog Tracing Libraries.
+OpenTracing support is based on a deprecated specification. If you want to instrument your code with an open spec, use OpenTelemetry instead. Try processing data from OpenTelemetry instrumentation in Datadog SDKs.
To set up Datadog with OpenTracing, see the Ruby [Quickstart for OpenTracing][1] for details.
-## Configuring Datadog tracer settings
+## Configuring Datadog SDK settings
-The underlying Datadog tracer can be configured by passing options (which match `Datadog::Tracer`) when configuring the global tracer:
+The underlying Datadog SDK can be configured by passing options (which match `Datadog::Tracer`) when configuring the global tracer:
```ruby
# Where `options` is a Hash of options provided to Datadog::Tracer
diff --git a/content/en/tracing/trace_collection/custom_instrumentation/server-side/_index.mdoc.md b/content/en/tracing/trace_collection/custom_instrumentation/server-side/_index.mdoc.md
index 68a736203aa..c3f9ada461d 100644
--- a/content/en/tracing/trace_collection/custom_instrumentation/server-side/_index.mdoc.md
+++ b/content/en/tracing/trace_collection/custom_instrumentation/server-side/_index.mdoc.md
@@ -152,7 +152,7 @@ Elixir does not support the Datadog API. Select **OpenTelemetry** from the API d
{% if equals($prog_lang, "elixir") %}
-Datadog does not provide an Elixir tracing library. To send traces to Datadog, use the [OpenTelemetry SDK for Elixir][8].
+Datadog does not provide an Elixir SDK. To send traces to Datadog, use the [OpenTelemetry SDK for Elixir][8].
{% /if %}
diff --git a/content/en/tracing/trace_collection/dd_libraries/_index.md b/content/en/tracing/trace_collection/dd_libraries/_index.md
index 957949d9f59..94666cd9f85 100644
--- a/content/en/tracing/trace_collection/dd_libraries/_index.md
+++ b/content/en/tracing/trace_collection/dd_libraries/_index.md
@@ -1,5 +1,5 @@
---
-title: Add the Datadog Tracing Library
+title: Add the Datadog SDK
aliases:
- /tracing/languages
- /tracing/setup_overview/setup/undefined
@@ -12,7 +12,7 @@ aliases:
To automatically instrument your application with Datadog libraries:
1. [Install and configure the Agent](#install-and-configure-the-agent).
-2. [Add the Datadog tracing library to your code](#instrument-your-application).
+2. [Add the Datadog SDK to your code](#instrument-your-application).
## Install and configure the Agent
@@ -59,13 +59,13 @@ For other environments, see the [Integrations][14] documentation for that enviro
## Instrument your application
-Set up your application to send [traces][2] using one of the following official Datadog tracing libraries:
+Set up your application to send [traces][2] using one of the following official Datadog SDKs:
{{< partial name="apm/apm-languages.html" >}}
-To instrument an application written in a language that does not have official library support, see the list of [community tracing libraries][1]. +To instrument an application written in a language that does not have official library support, see the list of [community SDKs][1]. [1]: /extend/community/libraries/#apm-tracing-client-libraries diff --git a/content/en/tracing/trace_collection/dd_libraries/android.md b/content/en/tracing/trace_collection/dd_libraries/android.md index b57c491f69a..46649bdd920 100644 --- a/content/en/tracing/trace_collection/dd_libraries/android.md +++ b/content/en/tracing/trace_collection/dd_libraries/android.md @@ -16,7 +16,7 @@ further_reading: text: Explore your services, resources, and traces title: Tracing Android Applications --- -Send [traces][1] to Datadog from your Android applications with [Datadog's `dd-sdk-android-trace` client-side tracing library][2] and leverage the following features: +Send [traces][1] to Datadog from your Android applications with [Datadog's `dd-sdk-android-trace` client-side SDK][2] and leverage the following features: * Create custom [spans][3] for operations in your application. * Add `context` and extra custom attributes to each span sent. @@ -820,7 +820,7 @@ Request request = OkHttpRequestExtKt **Note**: * If you use multiple Interceptors, this one must be called first. -* If you define custom tracing header types in the Datadog configuration and are using a tracer registered with `GlobalDatadogTracer`, make sure the same tracing header types are set for the tracer in use. +* If you define custom tracing header types in the Datadog configuration and are using an SDK registered with `GlobalDatadogTracer`, make sure the same tracing header types are set for the SDK in use. ### Cronet diff --git a/content/en/tracing/trace_collection/dd_libraries/cpp.md b/content/en/tracing/trace_collection/dd_libraries/cpp.md index 4a2a799a999..8b30b96d4bb 100644 --- a/content/en/tracing/trace_collection/dd_libraries/cpp.md +++ b/content/en/tracing/trace_collection/dd_libraries/cpp.md @@ -28,7 +28,7 @@ further_reading:
- Note: Always use the commands above to completely stop and restart IIS to enable the tracer. Avoid using the IIS Manager GUI application or
@@ -230,7 +230,7 @@ After enabling the .NET Tracer for your service:
## Configuration
-If needed, configure the tracing library to send application performance telemetry data as you require, including setting up Unified Service Tagging. Read [Library Configuration][4] for details.
+If needed, configure the SDK to send application performance telemetry data as you require, including setting up Unified Service Tagging. Read [Library Configuration][4] for details.
## Custom instrumentation
@@ -281,7 +281,7 @@ For more information on adding spans and tags for custom instrumentation, see th
## Configuring process environment variables
-To attach automatic instrumentation to your service, you must set the required environment variables before starting the application. See [Enable the tracer for your service](#enable-the-tracer-for-your-service) section to identify which environment variables to set based on your .NET Tracer installation method and follow the examples below to correctly set the environment variables based on the environment of your instrumented service.
+To attach automatic instrumentation to your service, you must set the required environment variables before starting the application. See [Enable the SDK for your service](#enable-the-sdk-for-your-service) section to identify which environment variables to set based on your .NET Tracer installation method and follow the examples below to correctly set the environment variables based on the environment of your instrumented service.
### Windows
diff --git a/content/en/tracing/trace_collection/dd_libraries/dotnet-framework.md b/content/en/tracing/trace_collection/dd_libraries/dotnet-framework.md
index 90dbd1009a3..eed424e8de7 100644
--- a/content/en/tracing/trace_collection/dd_libraries/dotnet-framework.md
+++ b/content/en/tracing/trace_collection/dd_libraries/dotnet-framework.md
@@ -73,13 +73,13 @@ For a full list of Datadog's .NET Framework library and processor architecture s
Before you begin, make sure you've already [installed and configured the Agent][12].
-1. [Install the tracer.](#install-the-tracer)
-3. [Enable the tracer for your service.](#enable-the-tracer-for-your-service)
+1. [Install the SDK.](#install-the-sdk)
+3. [Enable the SDK for your service.](#enable-the-sdk-for-your-service)
4. [View your live data.](#view-your-live-data)
-### Install the tracer
+### Install the SDK
-After you install and configure your Datadog Agent, the next step is to add the tracing library directly in the application to instrument it. Read more about [compatibility information][1].
+After you install and configure your Datadog Agent, the next step is to add the SDK directly in the application to instrument it. Read more about [compatibility information][1].
Install the Datadog .NET Tracer machine-wide so that all services on the machine are instrumented or on a per-application basis, so developers can manage the instrumentation through the application's dependencies. To see machine-wide installation instructions, click the Windows tab. To see per-application installation instructions, click the NuGet tab.
@@ -114,7 +114,7 @@ To install the .NET Tracer per-application:
{{< /tabs >}}
-### Enable the tracer for your service
+### Enable the SDK for your service
To enable the .NET Tracer for your service, set the required environment variables and restart the application.
@@ -137,7 +137,7 @@ For information about the different methods for setting environment variables, s
```
iisreset.exe.
+ Note: Always use the commands above to completely stop and restart IIS to enable the SDK. Avoid using the IIS Manager GUI application or iisreset.exe.
- Note: Always use the commands above to completely stop and restart IIS to enable the tracer. Avoid using the IIS Manager GUI application or
@@ -180,7 +180,7 @@ After enabling the .NET Tracer for your service:
## Configuration
-If needed, configure the tracing library to send application performance telemetry data, including setting up Unified Service Tagging. Read [Library Configuration][4] for details.
+If needed, configure the SDK to send application performance telemetry data, including setting up Unified Service Tagging. Read [Library Configuration][4] for details.
## Custom instrumentation
@@ -218,7 +218,7 @@ For more information on adding spans and tags for custom instrumentation, see th
## Configuring process environment variables
-To attach automatic instrumentation to your service, set the required environment variables before starting the application. See [Enable the tracer for your service](#enable-the-tracer-for-your-service) section to identify which environment variables to set based on your .NET Tracer installation method and follow the examples below to correctly set the environment variables based on the environment of your instrumented service.
+To attach automatic instrumentation to your service, set the required environment variables before starting the application. See [Enable the SDK for your service](#enable-the-sdk-for-your-service) section to identify which environment variables to set based on your .NET Tracer installation method and follow the examples below to correctly set the environment variables based on the environment of your instrumented service.
iisreset.exe.
+ Note: Always use the commands above to completely stop and restart IIS to enable the SDK. Avoid using the IIS Manager GUI application or iisreset.exe.
Note: The .NET runtime tries to load the .NET library into any .NET process that is started with these environment variables set. You should limit instrumentation to only the applications that need to be instrumented. Don't set these environment variables globally as this causes all .NET processes on the host to be instrumented.
diff --git a/content/en/tracing/trace_collection/dd_libraries/go.md b/content/en/tracing/trace_collection/dd_libraries/go.md
index 30d313d334e..9a36dc65f0c 100644
--- a/content/en/tracing/trace_collection/dd_libraries/go.md
+++ b/content/en/tracing/trace_collection/dd_libraries/go.md
@@ -14,13 +14,13 @@ code_lang_weight: 20
further_reading:
- link: "https://github.com/DataDog/dd-trace-go/tree/v1"
tag: "Source Code"
- text: "Tracer library source code"
+ text: "SDK source code"
- link: "https://pkg.go.dev/github.com/DataDog/dd-trace-go/v2/ddtrace"
tag: "External Site"
- text: "Tracer library API documentation"
+ text: "SDK API documentation"
- link: "https://pkg.go.dev/github.com/DataDog/dd-trace-go/v2/ddtrace"
tag: "External Site"
- text: "Tracer library API documentation for v2"
+ text: "SDK API documentation for v2"
- link: https://github.com/DataDog/orchestrion
tag: "Source Code"
text: "Orchestrion source code"
@@ -226,9 +226,9 @@ func excluded() {
Some of the instrumentation performed by `orchestrion` is done callee-side (or library-side), meaning the integration is added directly within the dependency itself. In such cases, it is not possible to locally opt out of such integrations.
-#### Use the tracing library
+#### Use the SDK
-You can use the [tracing library][4] in your Orchestrion-built application. This is useful for instrumenting frameworks not yet supported by Orchestrion. However, be aware that this may result in duplicated trace spans in the future as Orchestrion support expands. Review the [release notes][11] when updating your `orchestrion` dependency to stay informed about new features and adjust your manual instrumentation as necessary.
+You can use the [SDK][4] in your Orchestrion-built application. This is useful for instrumenting frameworks not yet supported by Orchestrion. However, be aware that this may result in duplicated trace spans in the future as Orchestrion support expands. Review the [release notes][11] when updating your `orchestrion` dependency to stay informed about new features and adjust your manual instrumentation as necessary.
#### Use the continuous profiler
@@ -244,7 +244,7 @@ or if you want to reduce the number of transitive dependencies for integrations
By default, Orchestrion imports `github.com/DataDog/dd-trace-go/orchestrion/all/v2`,
which imports every library for which there is an Orchestrion integration.
You can replace this import with imports of only the integrations you want to use.
-See [the tracer source code][17] for the list of supported integrations.
+See [the SDK source code][17] for the list of supported integrations.
**Note**: If you choose to import specific integrations, you must manually update `orchestrion.tool.go` each time you want to add a new integration.
@@ -274,9 +274,9 @@ To troubleshoot builds that `orchestrion` manages, see [Troubleshooting Go Compi
{{% tab "Manual instrumentation" %}}
-### Add the tracer library to your application
+### Add the SDK to your application
-First, import and start the tracer in your code following the [Library Configuration][3] documentation. Refer to the [API documentation][6] (or the [API documentation v1][4]) for configuration instructions and details about using the API.
+First, import and start the SDK in your code following the [Library Configuration][3] documentation. Refer to the [API documentation][6] (or the [API documentation v1][4]) for configuration instructions and details about using the API.
### Activate Go integrations to create spans
diff --git a/content/en/tracing/trace_collection/dd_libraries/ios.md b/content/en/tracing/trace_collection/dd_libraries/ios.md
index da5efd485e6..36b5d6610f9 100644
--- a/content/en/tracing/trace_collection/dd_libraries/ios.md
+++ b/content/en/tracing/trace_collection/dd_libraries/ios.md
@@ -16,7 +16,7 @@ further_reading:
tag: Documentation
text: Explore your services, resources, and traces
---
-Send [traces][1] to Datadog from your iOS applications with [Datadog's `dd-sdk-ios` client-side tracing library][2] and leverage the following features:
+Send [traces][1] to Datadog from your iOS applications with [Datadog's `dd-sdk-ios` client-side SDK][2] and leverage the following features:
* Create custom [spans][3] for various operations in your app.
* Send logs for each span individually.
@@ -304,7 +304,7 @@ DDDatadog.verbosityLevel = DDSDKVerbosityLevelDebug;
```
{{% /tab %}}
{{< /tabs >}}
-3. Datadog tracer implements both [OpenTracing][8] and [OpenTelemetry][12] standards. Configure and enable the shared an OpenTracing `Tracer` as `Tracer.shared()`:
+3. Datadog SDK implements both [OpenTracing][8] and [OpenTelemetry][12] standards. Configure and enable the shared an OpenTracing `Tracer` as `Tracer.shared()`:
{{< tabs >}}
{{% tab "Swift" %}}
```swift
diff --git a/content/en/tracing/trace_collection/dd_libraries/java.md b/content/en/tracing/trace_collection/dd_libraries/java.md
index 6314fcb8475..f1a3d20cf27 100644
--- a/content/en/tracing/trace_collection/dd_libraries/java.md
+++ b/content/en/tracing/trace_collection/dd_libraries/java.md
@@ -31,7 +31,7 @@ Before you begin, make sure you've already [installed and configured the Agent][
### Instrument your application
-After you install and configure your Datadog Agent, the next step is to add the tracing library directly in the application to instrument it. Read more about [compatibility information][1].
+After you install and configure your Datadog Agent, the next step is to add the SDK directly in the application to instrument it. Read more about [compatibility information][1].
To begin tracing your applications:
@@ -67,7 +67,7 @@ To begin tracing your applications:
```
**Note**: If you have a strong need to reduce the size of your image and omit modules, you can use the [`jdeps`][19] command to identify dependencies. However, required modules can change over time, so do this at your own risk.
- **Note**: When running the tracer with Java 24+, you may see warnings related to JNI native access. Suppress these warnings by adding the `--enable-native-access=ALL-UNNAMED` flag. See [JEP 472][23] for more details.
+ **Note**: When running the SDK with Java 24+, you may see warnings related to JNI native access. Suppress these warnings by adding the `--enable-native-access=ALL-UNNAMED` flag. See [JEP 472][23] for more details.
Enabling profiling may impact your bill depending on your APM bundle. See the pricing page for more information.
@@ -84,7 +84,7 @@ To begin tracing your applications:
Additional [configuration options](#configuration) are described below.
-### Add the Java Tracer to the JVM
+### Add the Java SDK to the JVM
Use the documentation for your application server to figure out the right way to pass in `-javaagent` and other JVM arguments. Here are instructions for some commonly used frameworks:
@@ -216,7 +216,7 @@ Instrumentation may come from auto-instrumentation, the OpenTracing API, or a mi
## Configuration
-If needed, configure the tracing library to send application performance telemetry data as you require, including setting up Unified Service Tagging. Read [Library Configuration][9] for details.
+If needed, configure the SDK to send application performance telemetry data as you require, including setting up Unified Service Tagging. Read [Library Configuration][9] for details.
### Remote configuration
diff --git a/content/en/tracing/trace_collection/dd_libraries/nodejs.md b/content/en/tracing/trace_collection/dd_libraries/nodejs.md
index b7157ed30cd..7b630837ac8 100644
--- a/content/en/tracing/trace_collection/dd_libraries/nodejs.md
+++ b/content/en/tracing/trace_collection/dd_libraries/nodejs.md
@@ -33,33 +33,33 @@ The latest Node.js Tracer supports Node.js versions `>=18`. For a full list of D
## Getting started
-Before you begin, make sure you've already [installed and configured the Agent][13]. Then, complete the following steps to add the Datadog tracing library to your Node.js application to instrument it.
+Before you begin, make sure you've already [installed and configured the Agent][13]. Then, complete the following steps to add the Datadog SDK to your Node.js application to instrument it.
-### Install the Datadog tracing library
+### Install the Datadog SDK
-To install the Datadog tracing library using npm for Node.js 18+, run:
+To install the Datadog SDK using npm for Node.js 18+, run:
```shell
npm install dd-trace --save
```
-To install the Datadog tracing library (version 4.x of `dd-trace`) for end-of-life Node.js version 16, run:
+To install the Datadog SDK (version 4.x of `dd-trace`) for end-of-life Node.js version 16, run:
```shell
npm install dd-trace@latest-node16
```
For more information on Datadog's distribution tags and Node.js runtime version support, see the [Compatibility Requirements][1] page.
If you are upgrading from a previous major version of the library (0.x, 1.x, 2.x, 3.x or 4.x) to another major version, read the [Migration Guide][5] to assess any breaking changes.
-### Import and initialize the tracer
+### Import and initialize the SDK
-Import and initialize the tracer either in code or with command line arguments. The Node.js tracing library needs to be imported and initialized **before** any other module.
+Import and initialize the SDK either in code or with command line arguments. The Node.js SDK needs to be imported and initialized **before** any other module.
With frameworks like Next.js and Nest.js you must either provide an environment variable or add an additional Node.js flag. See Complex framework usage for more information.
-After you have completed setup, if you are not receiving complete traces, including missing URL routes for web requests, or disconnected or missing spans, **confirm the tracer has been imported and initialized correctly**. The tracing library being initialized first is necessary for the tracer to properly patch all of the required libraries for automatic instrumentation.
+After you have completed setup, if you are not receiving complete traces, including missing URL routes for web requests, or disconnected or missing spans, **confirm the SDK has been imported and initialized correctly**. The SDK being initialized first is necessary for the SDK to properly patch all of the required libraries for automatic instrumentation.
-When using a transpiler such as TypeScript, Webpack, Babel, or others, import and initialize the tracer library in an external file and then import that file as a whole when building your application.
+When using a transpiler such as TypeScript, Webpack, Babel, or others, import and initialize the SDK in an external file and then import that file as a whole when building your application.
-#### Option 1: Add the tracer in code
+#### Option 1: Add the SDK in code
##### JavaScript
@@ -74,7 +74,7 @@ const tracer = require('dd-trace').init();
##### TypeScript and bundlers
-For TypeScript and bundlers that support ECMAScript Module syntax, initialize the tracer in a separate file to maintain correct load order.
+For TypeScript and bundlers that support ECMAScript Module syntax, initialize the SDK in a separate file to maintain correct load order.
```typescript
// server.ts
@@ -94,24 +94,24 @@ initializes in one step.
import 'dd-trace/init';
```
-#### Option 2: Add the tracer with command line arguments
+#### Option 2: Add the SDK with command line arguments
-Use the `--require` option to Node.js to load and initialize the tracer in one step.
+Use the `--require` option to Node.js to load and initialize the SDK in one step.
```sh
node --require dd-trace/init app.js
```
-**Note:** This approach requires using environment variables for all configuration of the tracer.
+**Note:** This approach requires using environment variables for all configuration of the SDK.
#### ESM applications only: Import the loader
-ECMAScript Modules (ESM) applications require an _additional_ command line argument. Add this argument regardless of how the tracer is otherwise imported and initialized:
+ECMAScript Modules (ESM) applications require an _additional_ command line argument. Add this argument regardless of how the SDK is otherwise imported and initialized:
- **Node.js < v20.6:** `--loader dd-trace/loader-hook.mjs`
- **Node.js >= v20.6:** `--import dd-trace/register.js`
-For example, in Node.js 22, if initializing the tracer using option one from above, you would start it like this:
+For example, in Node.js 22, if initializing the SDK using option one from above, you would start it like this:
```sh
node --import dd-trace/register.js app.js
@@ -233,7 +233,7 @@ The following features are turned off by default in the Node.js tracer. They do
#### General bundling remarks
-**Note**: Due to the usage of native modules in the tracer, which are compiled C++ code, (usually ending with a `.node` file extension), you need to add entries to your `external` list. Currently native modules used in the Node.js tracer live inside of `@datadog` prefixed packages. This will also require that you ship a `node_modules/` directory alongside your bundled application. You don't need to ship your entire `node_modules/` directory as it would contain many superfluous packages that should be contained in your bundle.
+**Note**: Due to the usage of native modules in the SDK, which are compiled C++ code, (usually ending with a `.node` file extension), you need to add entries to your `external` list. Currently native modules used in the Node.js tracer live inside of `@datadog` prefixed packages. This will also require that you ship a `node_modules/` directory alongside your bundled application. You don't need to ship your entire `node_modules/` directory as it would contain many superfluous packages that should be contained in your bundle.
To generate a smaller `node_modules/` directory with only the required native modules, (and their dependencies) you can first determine the versions of packages that you need, then create a temporary directory to install them into, and copy the resulting `node_modules/` directory from it. For example:
@@ -257,7 +257,7 @@ At this stage you should be able to deploy your bundle, (which is your applicati
## Configuration
-If needed, configure the tracing library to send application performance telemetry data as you require, including setting up Unified Service Tagging. Read [Library Configuration][4] for details.
+If needed, configure the SDK to send application performance telemetry data as you require, including setting up Unified Service Tagging. Read [Library Configuration][4] for details.
Read [tracer settings][3] for a list of initialization options.
diff --git a/content/en/tracing/trace_collection/dd_libraries/php.md b/content/en/tracing/trace_collection/dd_libraries/php.md
index ab60f3b4b86..8c4f85954d7 100644
--- a/content/en/tracing/trace_collection/dd_libraries/php.md
+++ b/content/en/tracing/trace_collection/dd_libraries/php.md
@@ -90,7 +90,7 @@ If the PHP CLI binary is built as NTS (non thread-safe), while Apache uses a ZTS
SELinux:
-If the httpd SELinux policies are configured on the host, functionality of the tracer may be limited, unless writing and executing temporary files is explicitly allowed in SELinux configuration:
+If the httpd SELinux policies are configured on the host, functionality of the SDK may be limited, unless writing and executing temporary files is explicitly allowed in SELinux configuration:
`allow httpd_t httpd_tmpfs_t:file { execute execute_no_trans };`
@@ -111,7 +111,7 @@ Automatic instrumentation captures:
## Configuration
-If needed, configure the tracing library to send application performance telemetry data as you require, including setting up Unified Service Tagging. Read [Library Configuration][6] for details.
+If needed, configure the SDK to send application performance telemetry data as you require, including setting up Unified Service Tagging. Read [Library Configuration][6] for details.
To control trace ingestion by service or resource (including using wildcards in resource names), see [Control trace ingestion with resource-based sampling][15].
diff --git a/content/en/tracing/trace_collection/dd_libraries/python.md b/content/en/tracing/trace_collection/dd_libraries/python.md
index 9baa54539b0..9b24ebae997 100644
--- a/content/en/tracing/trace_collection/dd_libraries/python.md
+++ b/content/en/tracing/trace_collection/dd_libraries/python.md
@@ -34,9 +34,9 @@ Before you begin, make sure you've already [installed and configured the Agent][
### Instrument your application
-After you install and configure your Datadog Agent, the next step is to add the tracing library directly in the application to instrument it. Read more about [compatibility information][1].
+After you install and configure your Datadog Agent, the next step is to add the SDK directly in the application to instrument it. Read more about [compatibility information][1].
-To begin tracing applications written in Python, install the Datadog Tracing library, `ddtrace`, using pip:
+To begin tracing applications written in Python, install the Datadog SDK, `ddtrace`, using pip:
```python
pip install ddtrace
@@ -56,11 +56,11 @@ For example, if your application is started with `python app.py` then:
ddtrace-run python app.py
```
-Once you've finished setup and are running the tracer with your application, you can run `ddtrace-run --info` to check that configurations are working as expected. Note that the output from this command does not reflect configuration changes made during runtime in code.
+Once you've finished setup and are running the SDK with your application, you can run `ddtrace-run --info` to check that configurations are working as expected. Note that the output from this command does not reflect configuration changes made during runtime in code.
## Configuration
-The tracing library can be configured through environment variables. This is the recommended approach for setting the Agent host, port, and other settings.
+The SDK can be configured through environment variables. This is the recommended approach for setting the Agent host, port, and other settings.
For a comprehensive list of configuration options, including Unified Service Tagging, see the [Library Configuration][3] documentation.
diff --git a/content/en/tracing/trace_collection/dynamic_instrumentation/_index.md b/content/en/tracing/trace_collection/dynamic_instrumentation/_index.md
index 3c815160809..af37c220ec0 100644
--- a/content/en/tracing/trace_collection/dynamic_instrumentation/_index.md
+++ b/content/en/tracing/trace_collection/dynamic_instrumentation/_index.md
@@ -45,7 +45,7 @@ Dynamic Instrumentation requires the following:
- [Datadog Agent][1] 7.49.0 or higher is installed alongside your service (7.73.0 or higher for Go).
- [Remote Configuration][2] is enabled in that Agent.
-- A supported Datadog tracing library is installed and up to date. See the [language-specific setup instructions](#enable-dynamic-instrumentation) for version requirements.
+- A supported Datadog SDK is installed and up to date. See the [language-specific setup instructions](#enable-dynamic-instrumentation) for version requirements.
- [Unified Service Tagging][6] tags `service`, `env`, and `version` are applied to your deployment.
- Recommended: [Autocomplete and search (in Preview)][17] are enabled.
- Recommended: [Source Code Integration][7] is set up for your service.
@@ -85,7 +85,7 @@ For more detailed instructions, select your runtime below:
- Dynamic Instrumentation is not compatible with Azure App Services or serverless environments.
- Not all probe types are supported in every language. See the [language-specific setup instructions](#enable-dynamic-instrumentation) for supported features and limitations.
-- The Java tracer library does not support Kotlin coroutines.
+- The Java SDK does not support Kotlin coroutines.
## Explore Dynamic Instrumentation
diff --git a/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/_index.md b/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/_index.md
index c68a57115eb..d8c51ef8255 100644
--- a/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/_index.md
+++ b/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/_index.md
@@ -12,7 +12,7 @@ further_reading:
text: 'Getting Started with Datadog Agent'
---
-Dynamic Instrumentation is a feature of supporting Datadog tracing libraries. If you are already using [APM to collect traces][1] for your application, ensure your tracing library is up-to-date and then enable Dynamic Instrumentation for your application.
+Dynamic Instrumentation is a feature of supporting Datadog SDKs. If you are already using [APM to collect traces][1] for your application, ensure your SDK is up-to-date and then enable Dynamic Instrumentation for your application.
Select your runtime below to learn how to enable Dynamic Instrumentation for your application:
diff --git a/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/dotnet.md b/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/dotnet.md
index b0004e24d5b..63d4a0b9403 100644
--- a/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/dotnet.md
+++ b/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/dotnet.md
@@ -14,13 +14,13 @@ further_reading:
text: 'Getting Started with Datadog Agent'
---
-Dynamic Instrumentation is a feature of the Datadog tracing library 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.
+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.
## Prerequisites
Before you begin, review the [Dynamic Instrumentation prerequisites][9]. .NET applications also require:
-- .NET tracing library version 2.54.0 or higher. See the installation instructions for [.NET Framework][2] or [.NET Core][3].
+- .NET SDK version 2.54.0 or higher. See the installation instructions for [.NET Framework][2] or [.NET Core][3].
## Installation
diff --git a/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/go.md b/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/go.md
index 041205cf01a..9e0fe73b35d 100644
--- a/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/go.md
+++ b/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/go.md
@@ -15,14 +15,14 @@ further_reading:
{{< partial name="dynamic_instrumentation/beta-callout.html" language="Go" limitations_anchor="unsupported-features" >}}
-Dynamic Instrumentation is a feature of the Datadog tracing library that lets you add instrumentation to your application at runtime without code changes or redeployments. Follow these instructions to set up Dynamic Instrumentation for Go.
+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 Go.
## Prerequisites
Before you begin, review the [Dynamic Instrumentation prerequisites][9]. Go applications also require:
- [Datadog Agent][6] version 7.73.0 or higher, running on the same host as your application.
-- Go tracing library version 1.74.6 or higher (major version 1), or version 2.2.3 or higher (major version 2). See the [installation instructions][2] for setup details.
+- Go SDK version 1.74.6 or higher (major version 1), or version 2.2.3 or higher (major version 2). See the [installation instructions][2] for setup details.
- Linux kernel version 5.17 or higher.
## Installation
@@ -61,7 +61,7 @@ datadog:
{{% /tab %}}
{{< /tabs >}}
-### Application (tracing library)
+### Application (SDK)
1. Run your service with Dynamic Instrumentation enabled by setting the following environment variable:
diff --git a/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/java.md b/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/java.md
index 65df45f95b4..965d1ee2e4f 100644
--- a/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/java.md
+++ b/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 tracing library 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.
+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.
## Prerequisites
diff --git a/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/nodejs.md b/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/nodejs.md
index d12f442eabd..9321e586566 100644
--- a/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/nodejs.md
+++ b/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/nodejs.md
@@ -14,7 +14,7 @@ further_reading:
text: 'Getting Started with Datadog Agent'
---
-Dynamic Instrumentation is a feature of the Datadog tracing library that lets you add instrumentation to your application at runtime without code changes or redeployments. Follow these instructions to set up Dynamic Instrumentation for Node.js.
+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 Node.js.
## Prerequisites
diff --git a/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/php.md b/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/php.md
index 61e77a63777..5d4d9a7c937 100644
--- a/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/php.md
+++ b/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/php.md
@@ -16,7 +16,7 @@ further_reading:
{{< partial name="dynamic_instrumentation/beta-callout.html" language="PHP" limitations_anchor="unsupported-features" >}}
-Dynamic Instrumentation is a feature of the Datadog tracing library 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.
+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.
## Prerequisites
diff --git a/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/python.md b/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/python.md
index 2781d6ceec2..92d1bfae26b 100644
--- a/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/python.md
+++ b/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 tracing library 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.
+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.
## Prerequisites
diff --git a/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/ruby.md b/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/ruby.md
index 442a1884c75..d2148afb6ea 100644
--- a/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/ruby.md
+++ b/content/en/tracing/trace_collection/dynamic_instrumentation/enabling/ruby.md
@@ -16,7 +16,7 @@ further_reading:
{{< partial name="dynamic_instrumentation/beta-callout.html" language="Ruby" limitations_anchor="unsupported-features" >}}
-Dynamic Instrumentation is a feature of the Datadog tracing library that lets you add instrumentation to your application at runtime without code changes or redeployments. Follow these instructions to set up Dynamic Instrumentation for Ruby.
+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 Ruby.
## Prerequisites
@@ -88,10 +88,10 @@ If your code uses instance variables with these names, rename them to use Dynami
Dynamic Instrumentation tracks code as it loads. For line probes to work correctly:
-- Files must be loaded **after** the Datadog tracer initializes
-- Code loaded before the tracer starts cannot be instrumented with line probes
+- Files must be loaded **after** the Datadog SDK initializes
+- Code loaded before the SDK starts cannot be instrumented with line probes
- Method probes can still work for classes defined before tracking starts
-- Best practice: Ensure the tracer initializes early in your application boot process
+- Best practice: Ensure the SDK initializes early in your application boot process
## Supported features
diff --git a/content/en/tracing/trace_collection/library_config/_index.md b/content/en/tracing/trace_collection/library_config/_index.md
index 6bc3661ddd9..250ab2ad55f 100644
--- a/content/en/tracing/trace_collection/library_config/_index.md
+++ b/content/en/tracing/trace_collection/library_config/_index.md
@@ -1,6 +1,6 @@
---
-title: Configure the Datadog Tracing Library
-description: Configure Datadog tracing libraries with environment variables, runtime settings, and language-specific options for optimal APM performance.
+title: Configure the Datadog SDK
+description: Configure Datadog SDKs with environment variables, runtime settings, and language-specific options for optimal APM performance.
type: multi-code-lang
---
@@ -14,7 +14,7 @@ For configuration options specific to your programming language, choose your lan
-To instrument an application written in a language that does not yet have official library support, see the list of [community tracing libraries][1]. +To instrument an application written in a language that does not yet have official library support, see the list of [community SDKs][1]. ## Common configuration options The following configuration options behave consistently across the latest versions of all Datadog SDKs, unless otherwise noted: @@ -24,7 +24,7 @@ The following configuration options behave consistently across the latest versio `DD_TRACE_AGENT_URL` : **Default**: `http://localhost:8126`
**Supported Input**: A string representing an HTTP or UDS url
-**Description**: The URL for connecting the tracer to the Datadog agent. Valid URL schemas include `http://` and `unix://` (UNIX Domain Sockets). This value takes precedence over `DD_AGENT_HOST` and `DD_TRACE_AGENT_PORT` if set. +**Description**: The URL for connecting the SDK to the Datadog agent. Valid URL schemas include `http://` and `unix://` (UNIX Domain Sockets). This value takes precedence over `DD_AGENT_HOST` and `DD_TRACE_AGENT_PORT` if set. `DD_DOGSTATSD_PORT` : **Default**: `8125`
@@ -54,7 +54,7 @@ The following configuration options behave consistently across the latest versio `DD_ENV` : **Default**: `null`
**Supported Input**: A string representing an application environment name (for example, `prod`, `dev`)
-**Description**: Adds an environment tag to all spans generated by the tracer instance. +**Description**: Adds an environment tag to all spans generated by the SDK instance. `DD_TAGS` : **Default**: `null`
@@ -109,13 +109,13 @@ The following configuration options behave consistently across the latest versio `DD_TRACE_SAMPLE_RATE` -: **Default**: `-1`. If unset, the tracer defers to the Datadog Agent to control sample rate.
+: **Default**: `-1`. If unset, the SDK defers to the Datadog Agent to control sample rate.
**Supported Input**: A number between 0.0 and 1.0, inclusive.
**Caveats**: This variable is deprecated in favor of `DD_TRACE_SAMPLING_RULES`, which provides more flexible and granular sampling control.
**Description**: Controls the trace ingestion sample rate between the Datadog Agent and the backend. Must be a number between 0.0 and 1.0, where 1.0 means all traces are sent to the backend and 0.0 means none are sent. This is precise up to 6 digits, applies globally to all traces, and does not support per-service or per-operation targeting. `DD_TRACE_SAMPLING_RULES` -: **Default**: `null`. If unset or no rules match, the tracer defers to the Datadog Agent to dynamically adjust sample rate across traces.
+: **Default**: `null`. If unset or no rules match, the SDK defers to the Datadog Agent to dynamically adjust sample rate across traces.
**Supported Input**: A JSON array of [user-defined rules][6].
**Description**: Enables fine-grained control over trace ingestion, allowing you to target specific services, operations, resources, or tagged traces. Defined by a JSON array of objects, where each object must include a `sample_rate` between 0.0 and 1.0 (inclusive), and can optionally include fields such as `service`, `name`, `resource`, `tags`, and `max_per_second`. Objects are evaluated in the order listed; the first matching object determines the trace's sample rate. For more information, see [Ingestion Mechanisms][4].
**Examples**:
diff --git a/content/en/tracing/trace_collection/library_config/cpp.md b/content/en/tracing/trace_collection/library_config/cpp.md index f278e69c91d..67abd2356c9 100644 --- a/content/en/tracing/trace_collection/library_config/cpp.md +++ b/content/en/tracing/trace_collection/library_config/cpp.md @@ -1,5 +1,5 @@ --- -title: Configuring the C++ Tracing Library +title: Configuring the C++ SDK code_lang: cpp type: multi-code-lang code_lang_weight: 50 @@ -15,14 +15,14 @@ further_reading: text: "Propagating trace context" --- -After you set up the tracing library with your code and configure the Agent to collect APM data, optionally configure the tracing library as desired, including setting up [Unified Service Tagging][1]. +After you set up the SDK with your code and configure the Agent to collect APM data, optionally configure the SDK as desired, including setting up [Unified Service Tagging][1]. {{% apm-config-visibility %}} It is recommended to use `DD_SERVICE`, `DD_ENV`, and `DD_VERSION` to set `env`, `service` and `version` for your services. Refer to the [Unified Service Tagging][1] docummentation recommendations on which value to set for environment variables. ## Environment variables -To configure the tracer using environment variables, set the variables before launching the instrumented application. +To configure the SDK using environment variables, set the variables before launching the instrumented application. ### Unified service tagging @@ -80,18 +80,18 @@ Adds the `hostname` tag with the result of `gethostname`. `DD_TRACE_STARTUP_LOGS` : **Since**: 0.1.0
**Default**: `true`
-Log the tracer configuration once the tracer is fully initialized.
+Log the SDK configuration once the SDK is fully initialized.
`DD_TRACE_128_BIT_TRACEID_GENERATION_ENABLED` : **Since**: 0.1.6
**Default**: `true`
-If `true`, the tracer will generate 128-bit trace IDs.
-If `false`, the tracer will generate legacy 64-bit trace IDs. +If `true`, the SDK will generate 128-bit trace IDs.
+If `false`, the SDK will generate legacy 64-bit trace IDs. `DD_REMOTE_CONFIGURATION_ENABLED` : **Since**: 0.2.0
**Default**: `true`
-Enable the capability that allows to remotely configure and change the behavior of the tracer.
+Enable the capability that allows to remotely configure and change the behavior of the SDK.
When `false` this feature is disabled.
For more information, see [Remote Configuration][5]. diff --git a/content/en/tracing/trace_collection/library_config/dotnet-core.md b/content/en/tracing/trace_collection/library_config/dotnet-core.md index 3af5a506723..4ef475516f3 100644 --- a/content/en/tracing/trace_collection/library_config/dotnet-core.md +++ b/content/en/tracing/trace_collection/library_config/dotnet-core.md @@ -1,5 +1,5 @@ --- -title: Configuring the .NET Core Tracing Library +title: Configuring the .NET Core SDK code_lang: dotnet-core type: multi-code-lang code_lang_weight: 60 @@ -36,7 +36,7 @@ further_reading: text: "OpenTelemetry Environment Variable Configurations" --- -After you set up the tracing library with your code and configure the Agent to collect APM data, optionally configure the tracing library as desired, including setting up [Unified Service Tagging][4]. +After you set up the SDK with your code and configure the Agent to collect APM data, optionally configure the SDK as desired, including setting up [Unified Service Tagging][4]. {{% apm-config-visibility %}} @@ -48,14 +48,14 @@ You can set configuration settings in the .NET Tracer with any of the following {{% tab "Environment variables" %}} -To configure the tracer using environment variables, set the variables before launching the instrumented application. To learn how to set environment variables in different environments, see [Configuring process environment variables][1]. +To configure the SDK using environment variables, set the variables before launching the instrumented application. To learn how to set environment variables in different environments, see [Configuring process environment variables][1]. [1]: /tracing/trace_collection/dd_libraries/dotnet-core/#configuring-process-environment-variables {{% /tab %}} {{% tab "Code" %}} -To configure the tracer in application code, create a `TracerSettings` instance from the default configuration sources. Set properties on this `TracerSettings` instance before calling `Tracer.Configure()`. For example: +To configure the SDK in application code, create a `TracerSettings` instance from the default configuration sources. Set properties on this `TracerSettings` instance before calling `Tracer.Configure()`. For example:
-To instrument an application written in a language that does not yet have official library support, see the list of [community tracing libraries][1]. +To instrument an application written in a language that does not yet have official library support, see the list of [community SDKs][1]. ## Common configuration options The following configuration options behave consistently across the latest versions of all Datadog SDKs, unless otherwise noted: @@ -24,7 +24,7 @@ The following configuration options behave consistently across the latest versio `DD_TRACE_AGENT_URL` : **Default**: `http://localhost:8126`
**Supported Input**: A string representing an HTTP or UDS url
-**Description**: The URL for connecting the tracer to the Datadog agent. Valid URL schemas include `http://` and `unix://` (UNIX Domain Sockets). This value takes precedence over `DD_AGENT_HOST` and `DD_TRACE_AGENT_PORT` if set. +**Description**: The URL for connecting the SDK to the Datadog agent. Valid URL schemas include `http://` and `unix://` (UNIX Domain Sockets). This value takes precedence over `DD_AGENT_HOST` and `DD_TRACE_AGENT_PORT` if set. `DD_DOGSTATSD_PORT` : **Default**: `8125`
@@ -54,7 +54,7 @@ The following configuration options behave consistently across the latest versio `DD_ENV` : **Default**: `null`
**Supported Input**: A string representing an application environment name (for example, `prod`, `dev`)
-**Description**: Adds an environment tag to all spans generated by the tracer instance. +**Description**: Adds an environment tag to all spans generated by the SDK instance. `DD_TAGS` : **Default**: `null`
@@ -109,13 +109,13 @@ The following configuration options behave consistently across the latest versio `DD_TRACE_SAMPLE_RATE` -: **Default**: `-1`. If unset, the tracer defers to the Datadog Agent to control sample rate.
+: **Default**: `-1`. If unset, the SDK defers to the Datadog Agent to control sample rate.
**Supported Input**: A number between 0.0 and 1.0, inclusive.
**Caveats**: This variable is deprecated in favor of `DD_TRACE_SAMPLING_RULES`, which provides more flexible and granular sampling control.
**Description**: Controls the trace ingestion sample rate between the Datadog Agent and the backend. Must be a number between 0.0 and 1.0, where 1.0 means all traces are sent to the backend and 0.0 means none are sent. This is precise up to 6 digits, applies globally to all traces, and does not support per-service or per-operation targeting. `DD_TRACE_SAMPLING_RULES` -: **Default**: `null`. If unset or no rules match, the tracer defers to the Datadog Agent to dynamically adjust sample rate across traces.
+: **Default**: `null`. If unset or no rules match, the SDK defers to the Datadog Agent to dynamically adjust sample rate across traces.
**Supported Input**: A JSON array of [user-defined rules][6].
**Description**: Enables fine-grained control over trace ingestion, allowing you to target specific services, operations, resources, or tagged traces. Defined by a JSON array of objects, where each object must include a `sample_rate` between 0.0 and 1.0 (inclusive), and can optionally include fields such as `service`, `name`, `resource`, `tags`, and `max_per_second`. Objects are evaluated in the order listed; the first matching object determines the trace's sample rate. For more information, see [Ingestion Mechanisms][4].
**Examples**:
diff --git a/content/en/tracing/trace_collection/library_config/cpp.md b/content/en/tracing/trace_collection/library_config/cpp.md index f278e69c91d..67abd2356c9 100644 --- a/content/en/tracing/trace_collection/library_config/cpp.md +++ b/content/en/tracing/trace_collection/library_config/cpp.md @@ -1,5 +1,5 @@ --- -title: Configuring the C++ Tracing Library +title: Configuring the C++ SDK code_lang: cpp type: multi-code-lang code_lang_weight: 50 @@ -15,14 +15,14 @@ further_reading: text: "Propagating trace context" --- -After you set up the tracing library with your code and configure the Agent to collect APM data, optionally configure the tracing library as desired, including setting up [Unified Service Tagging][1]. +After you set up the SDK with your code and configure the Agent to collect APM data, optionally configure the SDK as desired, including setting up [Unified Service Tagging][1]. {{% apm-config-visibility %}} It is recommended to use `DD_SERVICE`, `DD_ENV`, and `DD_VERSION` to set `env`, `service` and `version` for your services. Refer to the [Unified Service Tagging][1] docummentation recommendations on which value to set for environment variables. ## Environment variables -To configure the tracer using environment variables, set the variables before launching the instrumented application. +To configure the SDK using environment variables, set the variables before launching the instrumented application. ### Unified service tagging @@ -80,18 +80,18 @@ Adds the `hostname` tag with the result of `gethostname`. `DD_TRACE_STARTUP_LOGS` : **Since**: 0.1.0
**Default**: `true`
-Log the tracer configuration once the tracer is fully initialized.
+Log the SDK configuration once the SDK is fully initialized.
`DD_TRACE_128_BIT_TRACEID_GENERATION_ENABLED` : **Since**: 0.1.6
**Default**: `true`
-If `true`, the tracer will generate 128-bit trace IDs.
-If `false`, the tracer will generate legacy 64-bit trace IDs. +If `true`, the SDK will generate 128-bit trace IDs.
+If `false`, the SDK will generate legacy 64-bit trace IDs. `DD_REMOTE_CONFIGURATION_ENABLED` : **Since**: 0.2.0
**Default**: `true`
-Enable the capability that allows to remotely configure and change the behavior of the tracer.
+Enable the capability that allows to remotely configure and change the behavior of the SDK.
When `false` this feature is disabled.
For more information, see [Remote Configuration][5]. diff --git a/content/en/tracing/trace_collection/library_config/dotnet-core.md b/content/en/tracing/trace_collection/library_config/dotnet-core.md index 3af5a506723..4ef475516f3 100644 --- a/content/en/tracing/trace_collection/library_config/dotnet-core.md +++ b/content/en/tracing/trace_collection/library_config/dotnet-core.md @@ -1,5 +1,5 @@ --- -title: Configuring the .NET Core Tracing Library +title: Configuring the .NET Core SDK code_lang: dotnet-core type: multi-code-lang code_lang_weight: 60 @@ -36,7 +36,7 @@ further_reading: text: "OpenTelemetry Environment Variable Configurations" --- -After you set up the tracing library with your code and configure the Agent to collect APM data, optionally configure the tracing library as desired, including setting up [Unified Service Tagging][4]. +After you set up the SDK with your code and configure the Agent to collect APM data, optionally configure the SDK as desired, including setting up [Unified Service Tagging][4]. {{% apm-config-visibility %}} @@ -48,14 +48,14 @@ You can set configuration settings in the .NET Tracer with any of the following {{% tab "Environment variables" %}} -To configure the tracer using environment variables, set the variables before launching the instrumented application. To learn how to set environment variables in different environments, see [Configuring process environment variables][1]. +To configure the SDK using environment variables, set the variables before launching the instrumented application. To learn how to set environment variables in different environments, see [Configuring process environment variables][1]. [1]: /tracing/trace_collection/dd_libraries/dotnet-core/#configuring-process-environment-variables {{% /tab %}} {{% tab "Code" %}} -To configure the tracer in application code, create a `TracerSettings` instance from the default configuration sources. Set properties on this `TracerSettings` instance before calling `Tracer.Configure()`. For example: +To configure the SDK in application code, create a `TracerSettings` instance from the default configuration sources. Set properties on this `TracerSettings` instance before calling `Tracer.Configure()`. For example:
Settings must be set on
+: During the SDK's startup, this configuration uses the SDK's current log directory to delete log files the same age and older than the given number of days. Added in version 2.19.0.
**Default**: `32` `DD_TRACE_LOGGING_RATE` diff --git a/content/en/tracing/trace_collection/library_config/dotnet-framework.md b/content/en/tracing/trace_collection/library_config/dotnet-framework.md index 798e8b156cf..5b58586bb26 100644 --- a/content/en/tracing/trace_collection/library_config/dotnet-framework.md +++ b/content/en/tracing/trace_collection/library_config/dotnet-framework.md @@ -1,5 +1,5 @@ --- -title: Configuring the .NET Framework Tracing Library +title: Configuring the .NET Framework SDK code_lang: dotnet-framework type: multi-code-lang code_lang_weight: 70 @@ -39,7 +39,7 @@ further_reading: text: "OpenTelemetry Environment Variable Configurations" --- -After you set up the tracing library with your code and configure the Agent to collect APM data, optionally configure the tracing library as desired, including setting up [Unified Service Tagging][4]. +After you set up the SDK with your code and configure the Agent to collect APM data, optionally configure the SDK as desired, including setting up [Unified Service Tagging][4]. {{% apm-config-visibility %}} @@ -51,7 +51,7 @@ You can set configuration settings in the .NET Tracer with any of the following {{% tab "Environment variables" %}} -To configure the tracer using environment variables, set the variables before launching the instrumented application. To learn how to set environment variables in different environments, see [Configuring process environment variables][1]. +To configure the SDK using environment variables, set the variables before launching the instrumented application. To learn how to set environment variables in different environments, see [Configuring process environment variables][1]. [1]: /tracing/trace_collection/dd_libraries/dotnet-framework/#configuring-process-environment-variables @@ -251,7 +251,7 @@ Available since version `2.42.0` **Default**: `%ProgramData%\Datadog .NET Tracer\logs\` `DD_TRACE_LOGFILE_RETENTION_DAYS` -: During the tracer's startup, this configuration uses the tracer's current log directory to delete log files the same age and older than the given number of days. Added in version 2.19.0.
+: During the SDK's startup, this configuration uses the SDK's current log directory to delete log files the same age and older than the given number of days. Added in version 2.19.0.
**Default**: `32` `DD_TRACE_LOGGING_RATE` diff --git a/content/en/tracing/trace_collection/library_config/go.md b/content/en/tracing/trace_collection/library_config/go.md index 71fee9757c2..1a56a8b8e39 100644 --- a/content/en/tracing/trace_collection/library_config/go.md +++ b/content/en/tracing/trace_collection/library_config/go.md @@ -1,5 +1,5 @@ --- -title: Configuring the Go Tracing Library +title: Configuring the Go SDK code_lang: go type: multi-code-lang code_lang_weight: 20 @@ -24,7 +24,7 @@ further_reading: text: "OpenTelemetry Environment Variable Configurations" --- -After you [set up the tracing library with your code, configure the Agent to collect APM data, and activate the Go integration][1], start the tracer and configure the library as desired. {{% tracing-go-v2 %}} +After you [set up the SDK with your code, configure the Agent to collect APM data, and activate the Go integration][1], start the SDK and configure the library as desired. {{% tracing-go-v2 %}} {{% apm-config-visibility %}} @@ -32,7 +32,7 @@ Datadog recommends using `DD_ENV`, `DD_SERVICE`, and `DD_VERSION` to set `env`, Read the [Unified Service Tagging][2] documentation for recommendations on how to configure these environment variables. These variables are available for versions 1.24.0+ of the Go tracer. -You may also elect to provide `env`, `service`, and `version` through the tracer's API: +You may also elect to provide `env`, `service`, and `version` through the SDK's API: ```go package main @@ -48,12 +48,12 @@ func main() { tracer.WithServiceVersion("abc123"), ) - // When the tracer is stopped, it will flush everything it has to the Datadog Agent before quitting. + // When the SDK is stopped, it will flush everything it has to the Datadog Agent before quitting. // Make sure this line stays in your main function. defer tracer.Stop() // If you expect your application to be shut down by SIGTERM (for example, a container in Kubernetes), - // you might want to listen for that signal and explicitly stop the tracer to ensure no data is lost + // you might want to listen for that signal and explicitly stop the SDK to ensure no data is lost sigChan := make(chan os.Signal, 1) signal.Notify(sigChan, syscall.SIGTERM) go func() { @@ -101,7 +101,7 @@ Enable startup configuration and the diagnostic log. `DD_TRACE_DEBUG` : **Default**: `false`
-Enable debug logging in the tracer. +Enable debug logging in the SDK. `DD_SERVICE_MAPPING` : **Default**: `null`
@@ -163,7 +163,7 @@ Configures trace header injection and extraction style. See [Propagating Go Trac ## Configure APM environment name -The [APM environment name][7] may be configured [in the Agent][8] or using the [WithEnv][20] start option of the tracer. +The [APM environment name][7] may be configured [in the Agent][8] or using the [WithEnv][20] start option of the SDK. ## Further reading diff --git a/content/en/tracing/trace_collection/library_config/java.md b/content/en/tracing/trace_collection/library_config/java.md index 79b91d70472..8f42080961c 100644 --- a/content/en/tracing/trace_collection/library_config/java.md +++ b/content/en/tracing/trace_collection/library_config/java.md @@ -1,5 +1,5 @@ --- -title: Configuring the Java Tracing Library +title: Configuring the Java SDK code_lang: java type: multi-code-lang code_lang_weight: 0 @@ -18,7 +18,7 @@ further_reading: text: "OpenTelemetry Environment Variable Configurations" --- -After you set up the tracing library with your code and configure the Agent to collect APM data, optionally configure the tracing library as desired, including setting up [Unified Service Tagging][1]. +After you set up the SDK with your code and configure the Agent to collect APM data, optionally configure the SDK as desired, including setting up [Unified Service Tagging][1]. {{% apm-config-visibility %}} @@ -150,7 +150,7 @@ List of class/interface and methods to trace. Similar to adding `@Trace`, but wi : **Environment Variable**: `DD_TRACE_CLASSES_EXCLUDE`
**Default**: `null`
**Example**: `package.ClassName,package.ClassName$Nested,package.Foo*,package.other.*`
-A list of fully qualified classes (that may end with a wildcard to denote a prefix) which will be ignored (not modified) by the tracer. Must use the jvm internal representation for names (eg package.ClassName$Nested and not package.ClassName.Nested) +A list of fully qualified classes (that may end with a wildcard to denote a prefix) which will be ignored (not modified) by the SDK. Must use the jvm internal representation for names (eg package.ClassName$Nested and not package.ClassName.Nested) `dd.trace.partial.flush.min.spans` : **Environment Variable**: `DD_TRACE_PARTIAL_FLUSH_MIN_SPANS`
@@ -213,7 +213,7 @@ When `true`, debug mode for the Datadog Java Tracer is enabled. `datadog.slf4j.simpleLogger.jsonEnabled` : **Environment Variable**: Not available
**Default**: `false`
-When `true`, Datadog Java tracer logs are written in JSON. Available for versions 1.48.0+.
+When `true`, Datadog Java SDK logs are written in JSON. Available for versions 1.48.0+.
**Note**: This setting is specific to the embedded SLF4J simple logger and does not support environment variables. `dd.log.format.json` is the preferred configuration option. `dd.trace.servlet.principal.enabled` @@ -264,12 +264,12 @@ By default, HTTP 404 responses use "404" as the span resource name. When `false` `dd.trace.128.bit.traceid.generation.enabled` : **Environment Variable**: `DD_TRACE_128_BIT_TRACEID_GENERATION_ENABLED`
**Default**: `true`
-When `true`, the tracer generates 128 bit Trace IDs, and encodes Trace IDs as 32 lowercase hexadecimal characters with zero padding. +When `true`, the SDK generates 128 bit Trace IDs, and encodes Trace IDs as 32 lowercase hexadecimal characters with zero padding. `dd.trace.128.bit.traceid.logging.enabled` : **Environment Variable**: `DD_TRACE_128_BIT_TRACEID_LOGGING_ENABLED`
**Default**: `false`
-When `true`, the tracer will inject 128 bit Trace IDs as 32 lowercase hexadecimal characters with zero padding, and 64 bit Trace IDs as decimal numbers. Otherwise, the tracer always injects Trace IDs as decimal numbers. +When `true`, the SDK will inject 128 bit Trace IDs as 32 lowercase hexadecimal characters with zero padding, and 64 bit Trace IDs as decimal numbers. Otherwise, the SDK always injects Trace IDs as decimal numbers. `dd.trace.otel.enabled` : **Environment Variable**: `DD_TRACE_OTEL_ENABLED`
@@ -320,7 +320,7 @@ Hostname for where to send traces to. If using a containerized environment, conf `dd.instrumentation.telemetry.enabled` : **Environment Variable**: `DD_INSTRUMENTATION_TELEMETRY_ENABLED`
**Default**: `true`
-When `true`, the tracer collects [telemetry data][8]. Available for versions 0.104+. Defaults to `true` for versions 0.115+. +When `true`, the SDK collects [telemetry data][8]. Available for versions 0.104+. Defaults to `true` for versions 0.115+. ### Databases @@ -474,7 +474,7 @@ See how to disable integrations in the [integrations][13] compatibility section. `dd.integration.opentracing.enabled` : **Environment Variable**: `DD_INTEGRATION_OPENTRACING_ENABLED`
**Default**: `true`
-By default the tracing client detects if a GlobalTracer is being loaded and dynamically registers a tracer into it. By turning this to false, this removes any tracer dependency on OpenTracing. +By default the tracing client detects if a GlobalTracer is being loaded and dynamically registers an SDK into it. By turning this to false, this removes any tracer dependency on OpenTracing. `dd.hystrix.tags.enabled` : **Environment Variable**: `DD_HYSTRIX_TAGS_ENABLED`
diff --git a/content/en/tracing/trace_collection/library_config/nodejs.md b/content/en/tracing/trace_collection/library_config/nodejs.md index 96b9885d69b..720798f36d0 100644 --- a/content/en/tracing/trace_collection/library_config/nodejs.md +++ b/content/en/tracing/trace_collection/library_config/nodejs.md @@ -1,5 +1,5 @@ --- -title: Configuring the Node.js Tracing Library +title: Configuring the Node.js SDK code_lang: nodejs type: multi-code-lang code_lang_weight: 30 @@ -24,7 +24,7 @@ further_reading: text: "OpenTelemetry Environment Variable Configurations" --- -After you set up the tracing library with your code and configure the Agent to collect APM data, optionally configure the tracing library as desired, including setting up [Unified Service Tagging][1]. +After you set up the SDK with your code and configure the Agent to collect APM data, optionally configure the SDK as desired, including setting up [Unified Service Tagging][1]. {{% apm-config-visibility %}} @@ -60,7 +60,7 @@ See also [DD_APM_TRACING_ENABLED][16]. `DD_TRACE_DEBUG` : **Configuration**: N/A
**Default**: `false`
-Enable debug logging in the tracer. +Enable debug logging in the SDK. `DD_TRACING_ENABLED` : **Configuration**: N/A
@@ -89,7 +89,7 @@ Provide service names for each plugin. Accepts comma separated `plugin:service-n Flush Interval : **Configuration**: `flushInterval`
**Default**: `2000`
-Interval in milliseconds at which the tracer submits traces to the Agent. +Interval in milliseconds at which the SDK submits traces to the Agent. `DD_TRACE_PARTIAL_FLUSH_MIN_SPANS` : **Configuration**: `flushMinSpans`
@@ -135,7 +135,7 @@ Points to a JSON file that contains the span sampling rules. `DD_SPAN_SAMPLING_R : **Configuration**: N/A
**Default**: N/A
**Example**: `DD_TRACE_DISABLED_PLUGINS=express,dns`
-A comma-separated string of integration names automatically disabled when the tracer is initialized. +A comma-separated string of integration names automatically disabled when the SDK is initialized. Experimental Features : **Configuration**: `experimental`
@@ -175,22 +175,22 @@ Set global tags that are applied to all spans and runtime metrics. When passed a `DD_TRACE_AGENT_URL` : **Configuration**: `url`
**Default**: `http://localhost:8126`
-The URL of the Trace Agent that the tracer submits to. Takes priority over hostname and port, if set. If the [Agent configuration][13] sets `receiver_port` or `DD_APM_RECEIVER_PORT` to something other than the default `8126`, then `DD_TRACE_AGENT_PORT` or `DD_TRACE_AGENT_URL` must match it. Supports Unix Domain Sockets in combination with the `apm_config.receiver_socket` in your `datadog.yaml` file, or the `DD_APM_RECEIVER_SOCKET` environment variable. +The URL of the Trace Agent that the SDK submits to. Takes priority over hostname and port, if set. If the [Agent configuration][13] sets `receiver_port` or `DD_APM_RECEIVER_PORT` to something other than the default `8126`, then `DD_TRACE_AGENT_PORT` or `DD_TRACE_AGENT_URL` must match it. Supports Unix Domain Sockets in combination with the `apm_config.receiver_socket` in your `datadog.yaml` file, or the `DD_APM_RECEIVER_SOCKET` environment variable. `DD_TRACE_AGENT_HOSTNAME` : **Configuration**: `hostname`
**Default**: `localhost`
-The address of the Agent that the tracer submits to. +The address of the Agent that the SDK submits to. `DD_TRACE_AGENT_PORT` : **Configuration**: `port`
**Default**: `8126`
-The port of the Trace Agent that the tracer submits to. If the [Agent configuration][13] sets `receiver_port` or `DD_APM_RECEIVER_PORT` to something other than the default `8126`, then `DD_TRACE_AGENT_PORT` or `DD_TRACE_AGENT_URL` must match it. +The port of the Trace Agent that the SDK submits to. If the [Agent configuration][13] sets `receiver_port` or `DD_APM_RECEIVER_PORT` to something other than the default `8126`, then `DD_TRACE_AGENT_PORT` or `DD_TRACE_AGENT_URL` must match it. `DD_DOGSTATSD_PORT` : **Configuration**: `dogstatsd.port`
**Default**: `8125`
-The port of the DogStatsD Agent that metrics are submitted to. If the [Agent configuration][13] sets `dogstatsd_port` or `DD_DOGSTATSD_PORT` to something other than the default `8125`, then this tracing library `DD_DOGSTATSD_PORT` must match it. +The port of the DogStatsD Agent that metrics are submitted to. If the [Agent configuration][13] sets `dogstatsd_port` or `DD_DOGSTATSD_PORT` to something other than the default `8125`, then this SDK `DD_DOGSTATSD_PORT` must match it. `DD_REMOTE_CONFIG_POLL_INTERVAL_SECONDS` : **Configuration**: `remoteConfig.pollInterval`
@@ -241,7 +241,7 @@ Enable automatic injection of trace IDs in logs for supported logging libraries. `DD_TRACE_LOG_LEVEL` : **Configuration**: `logLevel`
**Default**: `debug`
-A string for the minimum log level for the tracer to use when debug logging is enabled, for example, `error`, `debug`. +A string for the minimum log level for the SDK to use when debug logging is enabled, for example, `error`, `debug`. ### OpenTelemetry diff --git a/content/en/tracing/trace_collection/library_config/php.md b/content/en/tracing/trace_collection/library_config/php.md index 0cdb95642e9..e507fc251f3 100644 --- a/content/en/tracing/trace_collection/library_config/php.md +++ b/content/en/tracing/trace_collection/library_config/php.md @@ -1,5 +1,5 @@ --- -title: Configuring the PHP Tracing Library +title: Configuring the PHP SDK code_lang: php type: multi-code-lang code_lang_weight: 40 @@ -24,7 +24,7 @@ further_reading: text: "OpenTelemetry Environment Variable Configurations" --- -After you set up the tracing library with your code and configure the Agent to collect APM data, optionally configure the tracing library as desired, including setting up [Unified Service Tagging][1]. +After you set up the SDK with your code and configure the Agent to collect APM data, optionally configure the SDK as desired, including setting up [Unified Service Tagging][1]. {{% apm-config-visibility %}} @@ -115,7 +115,7 @@ The default app name. `DD_TRACE_ENABLED` : **INI**: `datadog.trace.enabled`
**Default**: `1`
-Enable the tracer globally.
+Enable the SDK globally.
See also [DD_APM_TRACING_ENABLED][21]. `DD_PRIORITY_SAMPLING` @@ -131,7 +131,7 @@ Change the default name of an APM integration. Rename one or more integrations a `DD_TRACE_128_BIT_TRACEID_GENERATION_ENABLED` : **INI**: `datadog.trace.128_bit_traceid_generation_enabled`
**Default**: `true`
-When true, the tracer generates 128 bit Trace IDs, and encodes Trace IDs as 32 lowercase hexadecimal characters with zero padding. +When true, the SDK generates 128 bit Trace IDs, and encodes Trace IDs as 32 lowercase hexadecimal characters with zero padding. `DD_TRACE_128_BIT_TRACEID_LOGGING_ENABLED` : **INI**: `datadog.trace.128_bit_traceid_logging_enabled`
@@ -143,7 +143,7 @@ When true, the trace ID is printed as a full 128-bit trace ID in hexadecimal for `DD_TRACE_HEALTH_METRICS_ENABLED` : **INI**: `datadog.trace_health_metrics_enabled`
**Default**: `false`
-When enabled, the tracer sends stats to DogStatsD. In addition, where `sigaction` is available at build time, the tracer sends uncaught exception metrics upon segfaults. +When enabled, the SDK sends stats to DogStatsD. In addition, where `sigaction` is available at build time, the SDK sends uncaught exception metrics upon segfaults. `DD_TRACE_AGENT_CONNECT_TIMEOUT` : **INI**: `datadog.trace.agent_connect_timeout`
@@ -168,7 +168,7 @@ The Agent URL; takes precedence over `DD_AGENT_HOST` and `DD_TRACE_AGENT_PORT`. `DD_TRACE_AUTO_FLUSH_ENABLED` : **INI**: `datadog.trace.auto_flush_enabled`
**Default**: `0` (`1` in CLI environment)
-Automatically flush the tracer when all the spans are closed; set to `1` in conjunction with `DD_TRACE_GENERATE_ROOT_SPAN=0` to trace [long-running processes][14]. +Automatically flush the SDK when all the spans are closed; set to `1` in conjunction with `DD_TRACE_GENERATE_ROOT_SPAN=0` to trace [long-running processes][14]. `DD_TRACE_CLI_ENABLED` : **INI**: `datadog.trace.cli_enabled`
@@ -344,7 +344,7 @@ The Agent host name. `DD_AUTOFINISH_SPANS` : **INI**: `datadog.autofinish_spans`
**Default**: `0`
-Whether spans are automatically finished when the tracer is flushed. +Whether spans are automatically finished when the SDK is flushed. `DD_DISTRIBUTED_TRACING` : **INI**: `datadog.distributed_tracing`
@@ -478,7 +478,7 @@ Set the profiler's log level. Acceptable values are `off`, `error`, `warn`, `inf ### Trace context propagation -Read [Trace Context Propagation][11] for information about configuring the PHP tracing library to extract and inject headers for propagating distributed trace context. +Read [Trace Context Propagation][11] for information about configuring the PHP SDK to extract and inject headers for propagating distributed trace context. `DD_TRACE_PROPAGATION_STYLE_INJECT` : **INI**: `datadog.trace.propagation_style_inject`
diff --git a/content/en/tracing/trace_collection/library_config/python.md b/content/en/tracing/trace_collection/library_config/python.md index 4a1d78b6059..29077c2a2bb 100644 --- a/content/en/tracing/trace_collection/library_config/python.md +++ b/content/en/tracing/trace_collection/library_config/python.md @@ -1,5 +1,5 @@ --- -title: Configuring the Python Tracing Library +title: Configuring the Python SDK code_lang: python type: multi-code-lang code_lang_weight: 20 @@ -24,7 +24,7 @@ further_reading: text: "OpenTelemetry Environment Variable Configurations" --- -After you set up the tracing library with your code and configure the Agent to collect APM data, optionally configure the tracing library as desired, including setting up [Unified Service Tagging][1]. +After you set up the SDK with your code and configure the Agent to collect APM data, optionally configure the SDK as desired, including setting up [Unified Service Tagging][1]. {{% apm-config-visibility %}} @@ -52,7 +52,7 @@ See also [DD_APM_TRACING_ENABLED][15]. `DD_TRACE_DEBUG` : **Default**: `false`
-Enable debug logging in the tracer. +Enable debug logging in the SDK. `DD_SERVICE_MAPPING` : Define service name mappings to allow renaming services in traces, for example: `postgres:postgresql,defaultdb:postgresql`. Available in version 0.47+. @@ -65,7 +65,7 @@ Enable debug logging in the tracer. Comma-separated list of header names that are reported on the root span as tags. For example, `DD_TRACE_HEADER_TAGS="User-Agent:http.user_agent,Referer:http.referer,Content-Type:http.content_type,Etag:http.etag"`. `DD_TRACE_AGENT_URL` -: The URL of the Trace Agent that the tracer submits to. If set, this takes priority over hostname and port. Supports Unix Domain Sockets (UDS) in combination with the `apm_config.receiver_socket` configuration in your `datadog.yaml` file or the `DD_APM_RECEIVER_SOCKET` environment variable set on the Datadog Agent. For example, `DD_TRACE_AGENT_URL=http://localhost:8126` for HTTP URL and `DD_TRACE_AGENT_URL=unix:///var/run/datadog/apm.socket` for UDS. If the [Agent configuration][13] sets `receiver_port` or `DD_APM_RECEIVER_PORT` to something other than the default `8126`, then `DD_AGENT_PORT` or `DD_TRACE_AGENT_URL` must match it. +: The URL of the Trace Agent that the SDK submits to. If set, this takes priority over hostname and port. Supports Unix Domain Sockets (UDS) in combination with the `apm_config.receiver_socket` configuration in your `datadog.yaml` file or the `DD_APM_RECEIVER_SOCKET` environment variable set on the Datadog Agent. For example, `DD_TRACE_AGENT_URL=http://localhost:8126` for HTTP URL and `DD_TRACE_AGENT_URL=unix:///var/run/datadog/apm.socket` for UDS. If the [Agent configuration][13] sets `receiver_port` or `DD_APM_RECEIVER_PORT` to something other than the default `8126`, then `DD_AGENT_PORT` or `DD_TRACE_AGENT_URL` must match it. ## Agent @@ -84,7 +84,7 @@ Override the address of the trace Agent host that the default tracer attempts to Overrides the port that the default tracer submit traces to. If the [Agent configuration][13] sets `receiver_port` or `DD_APM_RECEIVER_PORT` to something other than the default `8126`, then `DD_AGENT_PORT` or `DD_TRACE_AGENT_URL` must match it. `DD_DOGSTATSD_URL` -: The URL used to connect to the Datadog Agent for DogStatsD metrics. If set, this takes priority over hostname and port. Supports Unix Domain Sockets (UDS) in combination with the `dogstatsd_socket` configuration in your `datadog.yaml` file or the `DD_DOGSTATSD_SOCKET` environment variable set on the Datadog Agent. For example, `DD_DOGSTATSD_URL=udp://localhost:8126` for UDP URL and `DD_DOGSTATSD_URL=unix:///var/run/datadog/dsd.socket` for UDS. If the [Agent configuration][13] sets `dogstatsd_port` or `DD_DOGSTATSD_PORT` to something other than the default `8125`, then this tracing library `DD_DOGSTATSD_URL` or `DD_DOGSTATSD_PORT` must match it. +: The URL used to connect to the Datadog Agent for DogStatsD metrics. If set, this takes priority over hostname and port. Supports Unix Domain Sockets (UDS) in combination with the `dogstatsd_socket` configuration in your `datadog.yaml` file or the `DD_DOGSTATSD_SOCKET` environment variable set on the Datadog Agent. For example, `DD_DOGSTATSD_URL=udp://localhost:8126` for UDP URL and `DD_DOGSTATSD_URL=unix:///var/run/datadog/dsd.socket` for UDS. If the [Agent configuration][13] sets `dogstatsd_port` or `DD_DOGSTATSD_PORT` to something other than the default `8125`, then this SDK `DD_DOGSTATSD_URL` or `DD_DOGSTATSD_PORT` must match it. `DD_DOGSTATSD_HOST` : **Default**: `localhost`
@@ -92,7 +92,7 @@ Override the address of the trace Agent host that the default tracer attempts to `DD_DOGSTATSD_PORT` : **Default**: `8125`
-Override the port that the default tracer submits DogStatsD metrics to. If the [Agent configuration][13] sets `dogstatsd_port` or `DD_DOGSTATSD_PORT` to something other than the default `8125`, then this tracing library `DD_DOGSTATSD_PORT` or `DD_DOGSTATSD_URL` must match it. +Override the port that the default tracer submits DogStatsD metrics to. If the [Agent configuration][13] sets `dogstatsd_port` or `DD_DOGSTATSD_PORT` to something other than the default `8125`, then this SDK `DD_DOGSTATSD_PORT` or `DD_DOGSTATSD_URL` must match it. ## Logs diff --git a/content/en/tracing/trace_collection/library_config/ruby.md b/content/en/tracing/trace_collection/library_config/ruby.md index 0803bee89c3..19fd7fb99fc 100644 --- a/content/en/tracing/trace_collection/library_config/ruby.md +++ b/content/en/tracing/trace_collection/library_config/ruby.md @@ -1,5 +1,5 @@ --- -title: Configuring the Ruby Tracing Library +title: Configuring the Ruby SDK code_lang: ruby type: multi-code-lang code_lang_weight: 30 @@ -15,11 +15,11 @@ further_reading: text: "OpenTelemetry Environment Variable Configurations" --- -After you set up the tracing library with your code and configure the Agent to collect APM data, optionally configure the tracing library as desired, including setting up [Unified Service Tagging][1]. +After you set up the SDK with your code and configure the Agent to collect APM data, optionally configure the SDK as desired, including setting up [Unified Service Tagging][1]. {{% apm-config-visibility %}} -For information about configuring the Ruby tracing library, see [Additional Ruby configuration][2]. +For information about configuring the Ruby SDK, see [Additional Ruby configuration][2]. ## Further Reading diff --git a/content/en/tracing/trace_collection/library_config/rust.md b/content/en/tracing/trace_collection/library_config/rust.md index 036137d163b..4189dd88dfd 100644 --- a/content/en/tracing/trace_collection/library_config/rust.md +++ b/content/en/tracing/trace_collection/library_config/rust.md @@ -1,5 +1,5 @@ --- -title: Configuring the Rust Tracing Library +title: Configuring the Rust SDK code_lang: rust type: multi-code-lang code_lang_weight: 80 @@ -109,7 +109,7 @@ It is recommended to use `DD_ENV`, `DD_SERVICE`, and `DD_VERSION` to set `env`, `DD_LOG_LEVEL` : **Default**: `ERROR`
-: Sets the internal log level for the tracer. Valid values: `DEBUG`, `INFO`, `WARN`, `ERROR`. +: Sets the internal log level for the SDK. Valid values: `DEBUG`, `INFO`, `WARN`, `ERROR`. ## Sampling diff --git a/content/en/tracing/trace_collection/runtime_config/_index.md b/content/en/tracing/trace_collection/runtime_config/_index.md index dc9f045ff8f..485db72d924 100644 --- a/content/en/tracing/trace_collection/runtime_config/_index.md +++ b/content/en/tracing/trace_collection/runtime_config/_index.md @@ -9,7 +9,7 @@ further_reading: ## Overview -Configuration at runtime lets you modify APM library configuration from the Datadog UI, without needing to restart your application or service. You don't need to wait for a new deployment or code change to update your configuration. Instead, update it right away with configuration at runtime. +Configuration at runtime lets you modify Datadog SDK configuration from the Datadog UI, without needing to restart your application or service. You don't need to wait for a new deployment or code change to update your configuration. Instead, update it right away with configuration at runtime. {{< img src="/tracing/runtime_config/runtime-config-nav.mp4" alt="Walk through Software Catalog to use configuration at runtime." video="true" style="width:100%;">}} diff --git a/content/en/tracing/trace_collection/single-step-apm/docker.md b/content/en/tracing/trace_collection/single-step-apm/docker.md index e4c8acf0c30..3729c5501a8 100644 --- a/content/en/tracing/trace_collection/single-step-apm/docker.md +++ b/content/en/tracing/trace_collection/single-step-apm/docker.md @@ -33,7 +33,7 @@ To enable APM in a Docker Linux container: ## Set SDK tracer versions -By default, Single Step Instrumentation installs the latest major versions of Datadog APM SDKs. Minor version updates are applied automatically when they become available. +By default, Single Step Instrumentation installs the latest major versions of Datadog SDKs. Minor version updates are applied automatically when they become available. You may want to customize SDK versions based on your application's language version or specific environment requirements. You can control the major and minor versions used by customizing library versions during setup. diff --git a/content/en/tracing/trace_collection/single-step-apm/kubernetes.md b/content/en/tracing/trace_collection/single-step-apm/kubernetes.md index b77aa017467..3bfd37d81fe 100644 --- a/content/en/tracing/trace_collection/single-step-apm/kubernetes.md +++ b/content/en/tracing/trace_collection/single-step-apm/kubernetes.md @@ -19,7 +19,7 @@ further_reading: ## Overview -In a Kubernetes environment, use Single Step Instrumentation (SSI) for APM to install the Datadog Agent and [instrument][3] your applications with the Datadog APM SDKs in one step. +In a Kubernetes environment, use Single Step Instrumentation (SSI) for APM to install the Datadog Agent and [instrument][3] your applications with the Datadog SDKs in one step. ## Requirements @@ -171,8 +171,8 @@ Each target block has the following keys: | `name` | The name of the target block. This has no effect on monitoring state and is used only as metadata. | | `namespaceSelector` | The namespace(s) to instrument. Specify using one or more of:
- `matchNames`: A list of one or more namespace name(s).
- `matchLabels`: A list of one or more label(s) defined in `{key,value}` pairs.
- `matchExpressions`: A list of namespace selector requirements.
Namespaces must meet all criteria to match. For more details, see the [Kubernetes selector documentation][10].| | `podSelector` | The pod(s) to instrument. Specify using one or more of:
- `matchLabels`: A list of one or more label(s) defined in `{key,value}` pairs.
- `matchExpressions`: A list of pod selector requirements.
Pods must meet all criteria to match. For more details, see the [Kubernetes selector documentation][10]. | -| `ddTraceVersions` | The [Datadog APM SDK][9] version to use for each language. | -| `ddTraceConfigs` | APM SDK configs that allow setting Unified Service Tags, enabling Datadog products beyond tracing, and customizing other APM settings. [See full list of options][8]. | +| `ddTraceVersions` | The [Datadog SDK][9] version to use for each language. | +| `ddTraceConfigs` | Datadog SDK configs that allow setting Unified Service Tags, enabling Datadog products beyond tracing, and customizing other APM settings. [See full list of options][8]. | The file you need to configure depends on how you enabled Single Step Instrumentation: - If you enabled SSI with Datadog Operator, edit `datadog-agent.yaml`. @@ -189,7 +189,7 @@ Review the following examples demonstrating how to select specific services: This configuration: - enables APM for all namespaces except the `jenkins` namespace. - **Note**: use `enabledNamespaces` to disable for all namespaces except those listed. -- instructs Datadog to instrument the Java applications with the default Java APM SDK and Python applications with `v.3.1.0` of the Python APM SDK. +- instructs Datadog to instrument the Java applications with the default Java SDK and Python applications with `v.3.1.0` of the Python SDK. {{< highlight yaml "hl_lines=4-10" >}} apm: @@ -212,11 +212,11 @@ This configuration creates two targets blocks: - The first block (named `login-service_namespace`): - enables APM for services in the namespace `login-service`. - - instructs Datadog to instrument services in this namespace with the default version of the Java APM SDK. + - instructs Datadog to instrument services in this namespace with the default version of the Java SDK. - sets environment variable `DD_PROFILING_ENABLED` for this target group - The second block (named `billing-service_apps`) - enables APM for services in the namespace(s) with label `app:billing-service`. - - instructs Datadog to instrument this set of services with `v3.1.0` of the Python APM SDK. + - instructs Datadog to instrument this set of services with `v3.1.0` of the Python SDK. {{< highlight yaml "hl_lines=4-28" >}} apm: @@ -394,16 +394,16 @@ To disable instrumentation for specific namespaces, add `disabledNamespaces` con {{< /collapse-content >}} -#### Specify tracing library versions +#### Specify SDK versions -
TracerSettings before creating the Tracer. Changes made to TracerSettings properties after the Tracer is created are ignored.
@@ -83,7 +83,7 @@ Tracer.Configure(settings);
{{% tab "JSON file" %}}
-To configure the tracer using a JSON file, create `datadog.json` in the instrumented application's directory. The root JSON object must be an object with a key-value pair for each setting. For example:
+To configure the SDK using a JSON file, create `datadog.json` in the instrumented application's directory. The root JSON object must be an object with a key-value pair for each setting. For example:
```json
{
@@ -234,7 +234,7 @@ Available since version `2.42.0`
**Default**: `%ProgramData%\Datadog .NET Tracer\logs\` on Windows, `/var/log/datadog/dotnet` on Linux
`DD_TRACE_LOGFILE_RETENTION_DAYS`
-: During the tracer's startup, this configuration uses the tracer's current log directory to delete log files the same age and older than the given number of days. Added in version 2.19.0. +: During the SDK's startup, this configuration uses the SDK's current log directory to delete log files the same age and older than the given number of days. Added in version 2.19.0.
**Default**: `32` `DD_TRACE_LOGGING_RATE` diff --git a/content/en/tracing/trace_collection/library_config/dotnet-framework.md b/content/en/tracing/trace_collection/library_config/dotnet-framework.md index 798e8b156cf..5b58586bb26 100644 --- a/content/en/tracing/trace_collection/library_config/dotnet-framework.md +++ b/content/en/tracing/trace_collection/library_config/dotnet-framework.md @@ -1,5 +1,5 @@ --- -title: Configuring the .NET Framework Tracing Library +title: Configuring the .NET Framework SDK code_lang: dotnet-framework type: multi-code-lang code_lang_weight: 70 @@ -39,7 +39,7 @@ further_reading: text: "OpenTelemetry Environment Variable Configurations" --- -After you set up the tracing library with your code and configure the Agent to collect APM data, optionally configure the tracing library as desired, including setting up [Unified Service Tagging][4]. +After you set up the SDK with your code and configure the Agent to collect APM data, optionally configure the SDK as desired, including setting up [Unified Service Tagging][4]. {{% apm-config-visibility %}} @@ -51,7 +51,7 @@ You can set configuration settings in the .NET Tracer with any of the following {{% tab "Environment variables" %}} -To configure the tracer using environment variables, set the variables before launching the instrumented application. To learn how to set environment variables in different environments, see [Configuring process environment variables][1]. +To configure the SDK using environment variables, set the variables before launching the instrumented application. To learn how to set environment variables in different environments, see [Configuring process environment variables][1]. [1]: /tracing/trace_collection/dd_libraries/dotnet-framework/#configuring-process-environment-variables @@ -251,7 +251,7 @@ Available since version `2.42.0` **Default**: `%ProgramData%\Datadog .NET Tracer\logs\` `DD_TRACE_LOGFILE_RETENTION_DAYS` -: During the tracer's startup, this configuration uses the tracer's current log directory to delete log files the same age and older than the given number of days. Added in version 2.19.0.
+: During the SDK's startup, this configuration uses the SDK's current log directory to delete log files the same age and older than the given number of days. Added in version 2.19.0.
**Default**: `32` `DD_TRACE_LOGGING_RATE` diff --git a/content/en/tracing/trace_collection/library_config/go.md b/content/en/tracing/trace_collection/library_config/go.md index 71fee9757c2..1a56a8b8e39 100644 --- a/content/en/tracing/trace_collection/library_config/go.md +++ b/content/en/tracing/trace_collection/library_config/go.md @@ -1,5 +1,5 @@ --- -title: Configuring the Go Tracing Library +title: Configuring the Go SDK code_lang: go type: multi-code-lang code_lang_weight: 20 @@ -24,7 +24,7 @@ further_reading: text: "OpenTelemetry Environment Variable Configurations" --- -After you [set up the tracing library with your code, configure the Agent to collect APM data, and activate the Go integration][1], start the tracer and configure the library as desired. {{% tracing-go-v2 %}} +After you [set up the SDK with your code, configure the Agent to collect APM data, and activate the Go integration][1], start the SDK and configure the library as desired. {{% tracing-go-v2 %}} {{% apm-config-visibility %}} @@ -32,7 +32,7 @@ Datadog recommends using `DD_ENV`, `DD_SERVICE`, and `DD_VERSION` to set `env`, Read the [Unified Service Tagging][2] documentation for recommendations on how to configure these environment variables. These variables are available for versions 1.24.0+ of the Go tracer. -You may also elect to provide `env`, `service`, and `version` through the tracer's API: +You may also elect to provide `env`, `service`, and `version` through the SDK's API: ```go package main @@ -48,12 +48,12 @@ func main() { tracer.WithServiceVersion("abc123"), ) - // When the tracer is stopped, it will flush everything it has to the Datadog Agent before quitting. + // When the SDK is stopped, it will flush everything it has to the Datadog Agent before quitting. // Make sure this line stays in your main function. defer tracer.Stop() // If you expect your application to be shut down by SIGTERM (for example, a container in Kubernetes), - // you might want to listen for that signal and explicitly stop the tracer to ensure no data is lost + // you might want to listen for that signal and explicitly stop the SDK to ensure no data is lost sigChan := make(chan os.Signal, 1) signal.Notify(sigChan, syscall.SIGTERM) go func() { @@ -101,7 +101,7 @@ Enable startup configuration and the diagnostic log. `DD_TRACE_DEBUG` : **Default**: `false`
-Enable debug logging in the tracer. +Enable debug logging in the SDK. `DD_SERVICE_MAPPING` : **Default**: `null`
@@ -163,7 +163,7 @@ Configures trace header injection and extraction style. See [Propagating Go Trac ## Configure APM environment name -The [APM environment name][7] may be configured [in the Agent][8] or using the [WithEnv][20] start option of the tracer. +The [APM environment name][7] may be configured [in the Agent][8] or using the [WithEnv][20] start option of the SDK. ## Further reading diff --git a/content/en/tracing/trace_collection/library_config/java.md b/content/en/tracing/trace_collection/library_config/java.md index 79b91d70472..8f42080961c 100644 --- a/content/en/tracing/trace_collection/library_config/java.md +++ b/content/en/tracing/trace_collection/library_config/java.md @@ -1,5 +1,5 @@ --- -title: Configuring the Java Tracing Library +title: Configuring the Java SDK code_lang: java type: multi-code-lang code_lang_weight: 0 @@ -18,7 +18,7 @@ further_reading: text: "OpenTelemetry Environment Variable Configurations" --- -After you set up the tracing library with your code and configure the Agent to collect APM data, optionally configure the tracing library as desired, including setting up [Unified Service Tagging][1]. +After you set up the SDK with your code and configure the Agent to collect APM data, optionally configure the SDK as desired, including setting up [Unified Service Tagging][1]. {{% apm-config-visibility %}} @@ -150,7 +150,7 @@ List of class/interface and methods to trace. Similar to adding `@Trace`, but wi : **Environment Variable**: `DD_TRACE_CLASSES_EXCLUDE`
**Default**: `null`
**Example**: `package.ClassName,package.ClassName$Nested,package.Foo*,package.other.*`
-A list of fully qualified classes (that may end with a wildcard to denote a prefix) which will be ignored (not modified) by the tracer. Must use the jvm internal representation for names (eg package.ClassName$Nested and not package.ClassName.Nested) +A list of fully qualified classes (that may end with a wildcard to denote a prefix) which will be ignored (not modified) by the SDK. Must use the jvm internal representation for names (eg package.ClassName$Nested and not package.ClassName.Nested) `dd.trace.partial.flush.min.spans` : **Environment Variable**: `DD_TRACE_PARTIAL_FLUSH_MIN_SPANS`
@@ -213,7 +213,7 @@ When `true`, debug mode for the Datadog Java Tracer is enabled. `datadog.slf4j.simpleLogger.jsonEnabled` : **Environment Variable**: Not available
**Default**: `false`
-When `true`, Datadog Java tracer logs are written in JSON. Available for versions 1.48.0+.
+When `true`, Datadog Java SDK logs are written in JSON. Available for versions 1.48.0+.
**Note**: This setting is specific to the embedded SLF4J simple logger and does not support environment variables. `dd.log.format.json` is the preferred configuration option. `dd.trace.servlet.principal.enabled` @@ -264,12 +264,12 @@ By default, HTTP 404 responses use "404" as the span resource name. When `false` `dd.trace.128.bit.traceid.generation.enabled` : **Environment Variable**: `DD_TRACE_128_BIT_TRACEID_GENERATION_ENABLED`
**Default**: `true`
-When `true`, the tracer generates 128 bit Trace IDs, and encodes Trace IDs as 32 lowercase hexadecimal characters with zero padding. +When `true`, the SDK generates 128 bit Trace IDs, and encodes Trace IDs as 32 lowercase hexadecimal characters with zero padding. `dd.trace.128.bit.traceid.logging.enabled` : **Environment Variable**: `DD_TRACE_128_BIT_TRACEID_LOGGING_ENABLED`
**Default**: `false`
-When `true`, the tracer will inject 128 bit Trace IDs as 32 lowercase hexadecimal characters with zero padding, and 64 bit Trace IDs as decimal numbers. Otherwise, the tracer always injects Trace IDs as decimal numbers. +When `true`, the SDK will inject 128 bit Trace IDs as 32 lowercase hexadecimal characters with zero padding, and 64 bit Trace IDs as decimal numbers. Otherwise, the SDK always injects Trace IDs as decimal numbers. `dd.trace.otel.enabled` : **Environment Variable**: `DD_TRACE_OTEL_ENABLED`
@@ -320,7 +320,7 @@ Hostname for where to send traces to. If using a containerized environment, conf `dd.instrumentation.telemetry.enabled` : **Environment Variable**: `DD_INSTRUMENTATION_TELEMETRY_ENABLED`
**Default**: `true`
-When `true`, the tracer collects [telemetry data][8]. Available for versions 0.104+. Defaults to `true` for versions 0.115+. +When `true`, the SDK collects [telemetry data][8]. Available for versions 0.104+. Defaults to `true` for versions 0.115+. ### Databases @@ -474,7 +474,7 @@ See how to disable integrations in the [integrations][13] compatibility section. `dd.integration.opentracing.enabled` : **Environment Variable**: `DD_INTEGRATION_OPENTRACING_ENABLED`
**Default**: `true`
-By default the tracing client detects if a GlobalTracer is being loaded and dynamically registers a tracer into it. By turning this to false, this removes any tracer dependency on OpenTracing. +By default the tracing client detects if a GlobalTracer is being loaded and dynamically registers an SDK into it. By turning this to false, this removes any tracer dependency on OpenTracing. `dd.hystrix.tags.enabled` : **Environment Variable**: `DD_HYSTRIX_TAGS_ENABLED`
diff --git a/content/en/tracing/trace_collection/library_config/nodejs.md b/content/en/tracing/trace_collection/library_config/nodejs.md index 96b9885d69b..720798f36d0 100644 --- a/content/en/tracing/trace_collection/library_config/nodejs.md +++ b/content/en/tracing/trace_collection/library_config/nodejs.md @@ -1,5 +1,5 @@ --- -title: Configuring the Node.js Tracing Library +title: Configuring the Node.js SDK code_lang: nodejs type: multi-code-lang code_lang_weight: 30 @@ -24,7 +24,7 @@ further_reading: text: "OpenTelemetry Environment Variable Configurations" --- -After you set up the tracing library with your code and configure the Agent to collect APM data, optionally configure the tracing library as desired, including setting up [Unified Service Tagging][1]. +After you set up the SDK with your code and configure the Agent to collect APM data, optionally configure the SDK as desired, including setting up [Unified Service Tagging][1]. {{% apm-config-visibility %}} @@ -60,7 +60,7 @@ See also [DD_APM_TRACING_ENABLED][16]. `DD_TRACE_DEBUG` : **Configuration**: N/A
**Default**: `false`
-Enable debug logging in the tracer. +Enable debug logging in the SDK. `DD_TRACING_ENABLED` : **Configuration**: N/A
@@ -89,7 +89,7 @@ Provide service names for each plugin. Accepts comma separated `plugin:service-n Flush Interval : **Configuration**: `flushInterval`
**Default**: `2000`
-Interval in milliseconds at which the tracer submits traces to the Agent. +Interval in milliseconds at which the SDK submits traces to the Agent. `DD_TRACE_PARTIAL_FLUSH_MIN_SPANS` : **Configuration**: `flushMinSpans`
@@ -135,7 +135,7 @@ Points to a JSON file that contains the span sampling rules. `DD_SPAN_SAMPLING_R : **Configuration**: N/A
**Default**: N/A
**Example**: `DD_TRACE_DISABLED_PLUGINS=express,dns`
-A comma-separated string of integration names automatically disabled when the tracer is initialized. +A comma-separated string of integration names automatically disabled when the SDK is initialized. Experimental Features : **Configuration**: `experimental`
@@ -175,22 +175,22 @@ Set global tags that are applied to all spans and runtime metrics. When passed a `DD_TRACE_AGENT_URL` : **Configuration**: `url`
**Default**: `http://localhost:8126`
-The URL of the Trace Agent that the tracer submits to. Takes priority over hostname and port, if set. If the [Agent configuration][13] sets `receiver_port` or `DD_APM_RECEIVER_PORT` to something other than the default `8126`, then `DD_TRACE_AGENT_PORT` or `DD_TRACE_AGENT_URL` must match it. Supports Unix Domain Sockets in combination with the `apm_config.receiver_socket` in your `datadog.yaml` file, or the `DD_APM_RECEIVER_SOCKET` environment variable. +The URL of the Trace Agent that the SDK submits to. Takes priority over hostname and port, if set. If the [Agent configuration][13] sets `receiver_port` or `DD_APM_RECEIVER_PORT` to something other than the default `8126`, then `DD_TRACE_AGENT_PORT` or `DD_TRACE_AGENT_URL` must match it. Supports Unix Domain Sockets in combination with the `apm_config.receiver_socket` in your `datadog.yaml` file, or the `DD_APM_RECEIVER_SOCKET` environment variable. `DD_TRACE_AGENT_HOSTNAME` : **Configuration**: `hostname`
**Default**: `localhost`
-The address of the Agent that the tracer submits to. +The address of the Agent that the SDK submits to. `DD_TRACE_AGENT_PORT` : **Configuration**: `port`
**Default**: `8126`
-The port of the Trace Agent that the tracer submits to. If the [Agent configuration][13] sets `receiver_port` or `DD_APM_RECEIVER_PORT` to something other than the default `8126`, then `DD_TRACE_AGENT_PORT` or `DD_TRACE_AGENT_URL` must match it. +The port of the Trace Agent that the SDK submits to. If the [Agent configuration][13] sets `receiver_port` or `DD_APM_RECEIVER_PORT` to something other than the default `8126`, then `DD_TRACE_AGENT_PORT` or `DD_TRACE_AGENT_URL` must match it. `DD_DOGSTATSD_PORT` : **Configuration**: `dogstatsd.port`
**Default**: `8125`
-The port of the DogStatsD Agent that metrics are submitted to. If the [Agent configuration][13] sets `dogstatsd_port` or `DD_DOGSTATSD_PORT` to something other than the default `8125`, then this tracing library `DD_DOGSTATSD_PORT` must match it. +The port of the DogStatsD Agent that metrics are submitted to. If the [Agent configuration][13] sets `dogstatsd_port` or `DD_DOGSTATSD_PORT` to something other than the default `8125`, then this SDK `DD_DOGSTATSD_PORT` must match it. `DD_REMOTE_CONFIG_POLL_INTERVAL_SECONDS` : **Configuration**: `remoteConfig.pollInterval`
@@ -241,7 +241,7 @@ Enable automatic injection of trace IDs in logs for supported logging libraries. `DD_TRACE_LOG_LEVEL` : **Configuration**: `logLevel`
**Default**: `debug`
-A string for the minimum log level for the tracer to use when debug logging is enabled, for example, `error`, `debug`. +A string for the minimum log level for the SDK to use when debug logging is enabled, for example, `error`, `debug`. ### OpenTelemetry diff --git a/content/en/tracing/trace_collection/library_config/php.md b/content/en/tracing/trace_collection/library_config/php.md index 0cdb95642e9..e507fc251f3 100644 --- a/content/en/tracing/trace_collection/library_config/php.md +++ b/content/en/tracing/trace_collection/library_config/php.md @@ -1,5 +1,5 @@ --- -title: Configuring the PHP Tracing Library +title: Configuring the PHP SDK code_lang: php type: multi-code-lang code_lang_weight: 40 @@ -24,7 +24,7 @@ further_reading: text: "OpenTelemetry Environment Variable Configurations" --- -After you set up the tracing library with your code and configure the Agent to collect APM data, optionally configure the tracing library as desired, including setting up [Unified Service Tagging][1]. +After you set up the SDK with your code and configure the Agent to collect APM data, optionally configure the SDK as desired, including setting up [Unified Service Tagging][1]. {{% apm-config-visibility %}} @@ -115,7 +115,7 @@ The default app name. `DD_TRACE_ENABLED` : **INI**: `datadog.trace.enabled`
**Default**: `1`
-Enable the tracer globally.
+Enable the SDK globally.
See also [DD_APM_TRACING_ENABLED][21]. `DD_PRIORITY_SAMPLING` @@ -131,7 +131,7 @@ Change the default name of an APM integration. Rename one or more integrations a `DD_TRACE_128_BIT_TRACEID_GENERATION_ENABLED` : **INI**: `datadog.trace.128_bit_traceid_generation_enabled`
**Default**: `true`
-When true, the tracer generates 128 bit Trace IDs, and encodes Trace IDs as 32 lowercase hexadecimal characters with zero padding. +When true, the SDK generates 128 bit Trace IDs, and encodes Trace IDs as 32 lowercase hexadecimal characters with zero padding. `DD_TRACE_128_BIT_TRACEID_LOGGING_ENABLED` : **INI**: `datadog.trace.128_bit_traceid_logging_enabled`
@@ -143,7 +143,7 @@ When true, the trace ID is printed as a full 128-bit trace ID in hexadecimal for `DD_TRACE_HEALTH_METRICS_ENABLED` : **INI**: `datadog.trace_health_metrics_enabled`
**Default**: `false`
-When enabled, the tracer sends stats to DogStatsD. In addition, where `sigaction` is available at build time, the tracer sends uncaught exception metrics upon segfaults. +When enabled, the SDK sends stats to DogStatsD. In addition, where `sigaction` is available at build time, the SDK sends uncaught exception metrics upon segfaults. `DD_TRACE_AGENT_CONNECT_TIMEOUT` : **INI**: `datadog.trace.agent_connect_timeout`
@@ -168,7 +168,7 @@ The Agent URL; takes precedence over `DD_AGENT_HOST` and `DD_TRACE_AGENT_PORT`. `DD_TRACE_AUTO_FLUSH_ENABLED` : **INI**: `datadog.trace.auto_flush_enabled`
**Default**: `0` (`1` in CLI environment)
-Automatically flush the tracer when all the spans are closed; set to `1` in conjunction with `DD_TRACE_GENERATE_ROOT_SPAN=0` to trace [long-running processes][14]. +Automatically flush the SDK when all the spans are closed; set to `1` in conjunction with `DD_TRACE_GENERATE_ROOT_SPAN=0` to trace [long-running processes][14]. `DD_TRACE_CLI_ENABLED` : **INI**: `datadog.trace.cli_enabled`
@@ -344,7 +344,7 @@ The Agent host name. `DD_AUTOFINISH_SPANS` : **INI**: `datadog.autofinish_spans`
**Default**: `0`
-Whether spans are automatically finished when the tracer is flushed. +Whether spans are automatically finished when the SDK is flushed. `DD_DISTRIBUTED_TRACING` : **INI**: `datadog.distributed_tracing`
@@ -478,7 +478,7 @@ Set the profiler's log level. Acceptable values are `off`, `error`, `warn`, `inf ### Trace context propagation -Read [Trace Context Propagation][11] for information about configuring the PHP tracing library to extract and inject headers for propagating distributed trace context. +Read [Trace Context Propagation][11] for information about configuring the PHP SDK to extract and inject headers for propagating distributed trace context. `DD_TRACE_PROPAGATION_STYLE_INJECT` : **INI**: `datadog.trace.propagation_style_inject`
diff --git a/content/en/tracing/trace_collection/library_config/python.md b/content/en/tracing/trace_collection/library_config/python.md index 4a1d78b6059..29077c2a2bb 100644 --- a/content/en/tracing/trace_collection/library_config/python.md +++ b/content/en/tracing/trace_collection/library_config/python.md @@ -1,5 +1,5 @@ --- -title: Configuring the Python Tracing Library +title: Configuring the Python SDK code_lang: python type: multi-code-lang code_lang_weight: 20 @@ -24,7 +24,7 @@ further_reading: text: "OpenTelemetry Environment Variable Configurations" --- -After you set up the tracing library with your code and configure the Agent to collect APM data, optionally configure the tracing library as desired, including setting up [Unified Service Tagging][1]. +After you set up the SDK with your code and configure the Agent to collect APM data, optionally configure the SDK as desired, including setting up [Unified Service Tagging][1]. {{% apm-config-visibility %}} @@ -52,7 +52,7 @@ See also [DD_APM_TRACING_ENABLED][15]. `DD_TRACE_DEBUG` : **Default**: `false`
-Enable debug logging in the tracer. +Enable debug logging in the SDK. `DD_SERVICE_MAPPING` : Define service name mappings to allow renaming services in traces, for example: `postgres:postgresql,defaultdb:postgresql`. Available in version 0.47+. @@ -65,7 +65,7 @@ Enable debug logging in the tracer. Comma-separated list of header names that are reported on the root span as tags. For example, `DD_TRACE_HEADER_TAGS="User-Agent:http.user_agent,Referer:http.referer,Content-Type:http.content_type,Etag:http.etag"`. `DD_TRACE_AGENT_URL` -: The URL of the Trace Agent that the tracer submits to. If set, this takes priority over hostname and port. Supports Unix Domain Sockets (UDS) in combination with the `apm_config.receiver_socket` configuration in your `datadog.yaml` file or the `DD_APM_RECEIVER_SOCKET` environment variable set on the Datadog Agent. For example, `DD_TRACE_AGENT_URL=http://localhost:8126` for HTTP URL and `DD_TRACE_AGENT_URL=unix:///var/run/datadog/apm.socket` for UDS. If the [Agent configuration][13] sets `receiver_port` or `DD_APM_RECEIVER_PORT` to something other than the default `8126`, then `DD_AGENT_PORT` or `DD_TRACE_AGENT_URL` must match it. +: The URL of the Trace Agent that the SDK submits to. If set, this takes priority over hostname and port. Supports Unix Domain Sockets (UDS) in combination with the `apm_config.receiver_socket` configuration in your `datadog.yaml` file or the `DD_APM_RECEIVER_SOCKET` environment variable set on the Datadog Agent. For example, `DD_TRACE_AGENT_URL=http://localhost:8126` for HTTP URL and `DD_TRACE_AGENT_URL=unix:///var/run/datadog/apm.socket` for UDS. If the [Agent configuration][13] sets `receiver_port` or `DD_APM_RECEIVER_PORT` to something other than the default `8126`, then `DD_AGENT_PORT` or `DD_TRACE_AGENT_URL` must match it. ## Agent @@ -84,7 +84,7 @@ Override the address of the trace Agent host that the default tracer attempts to Overrides the port that the default tracer submit traces to. If the [Agent configuration][13] sets `receiver_port` or `DD_APM_RECEIVER_PORT` to something other than the default `8126`, then `DD_AGENT_PORT` or `DD_TRACE_AGENT_URL` must match it. `DD_DOGSTATSD_URL` -: The URL used to connect to the Datadog Agent for DogStatsD metrics. If set, this takes priority over hostname and port. Supports Unix Domain Sockets (UDS) in combination with the `dogstatsd_socket` configuration in your `datadog.yaml` file or the `DD_DOGSTATSD_SOCKET` environment variable set on the Datadog Agent. For example, `DD_DOGSTATSD_URL=udp://localhost:8126` for UDP URL and `DD_DOGSTATSD_URL=unix:///var/run/datadog/dsd.socket` for UDS. If the [Agent configuration][13] sets `dogstatsd_port` or `DD_DOGSTATSD_PORT` to something other than the default `8125`, then this tracing library `DD_DOGSTATSD_URL` or `DD_DOGSTATSD_PORT` must match it. +: The URL used to connect to the Datadog Agent for DogStatsD metrics. If set, this takes priority over hostname and port. Supports Unix Domain Sockets (UDS) in combination with the `dogstatsd_socket` configuration in your `datadog.yaml` file or the `DD_DOGSTATSD_SOCKET` environment variable set on the Datadog Agent. For example, `DD_DOGSTATSD_URL=udp://localhost:8126` for UDP URL and `DD_DOGSTATSD_URL=unix:///var/run/datadog/dsd.socket` for UDS. If the [Agent configuration][13] sets `dogstatsd_port` or `DD_DOGSTATSD_PORT` to something other than the default `8125`, then this SDK `DD_DOGSTATSD_URL` or `DD_DOGSTATSD_PORT` must match it. `DD_DOGSTATSD_HOST` : **Default**: `localhost`
@@ -92,7 +92,7 @@ Override the address of the trace Agent host that the default tracer attempts to `DD_DOGSTATSD_PORT` : **Default**: `8125`
-Override the port that the default tracer submits DogStatsD metrics to. If the [Agent configuration][13] sets `dogstatsd_port` or `DD_DOGSTATSD_PORT` to something other than the default `8125`, then this tracing library `DD_DOGSTATSD_PORT` or `DD_DOGSTATSD_URL` must match it. +Override the port that the default tracer submits DogStatsD metrics to. If the [Agent configuration][13] sets `dogstatsd_port` or `DD_DOGSTATSD_PORT` to something other than the default `8125`, then this SDK `DD_DOGSTATSD_PORT` or `DD_DOGSTATSD_URL` must match it. ## Logs diff --git a/content/en/tracing/trace_collection/library_config/ruby.md b/content/en/tracing/trace_collection/library_config/ruby.md index 0803bee89c3..19fd7fb99fc 100644 --- a/content/en/tracing/trace_collection/library_config/ruby.md +++ b/content/en/tracing/trace_collection/library_config/ruby.md @@ -1,5 +1,5 @@ --- -title: Configuring the Ruby Tracing Library +title: Configuring the Ruby SDK code_lang: ruby type: multi-code-lang code_lang_weight: 30 @@ -15,11 +15,11 @@ further_reading: text: "OpenTelemetry Environment Variable Configurations" --- -After you set up the tracing library with your code and configure the Agent to collect APM data, optionally configure the tracing library as desired, including setting up [Unified Service Tagging][1]. +After you set up the SDK with your code and configure the Agent to collect APM data, optionally configure the SDK as desired, including setting up [Unified Service Tagging][1]. {{% apm-config-visibility %}} -For information about configuring the Ruby tracing library, see [Additional Ruby configuration][2]. +For information about configuring the Ruby SDK, see [Additional Ruby configuration][2]. ## Further Reading diff --git a/content/en/tracing/trace_collection/library_config/rust.md b/content/en/tracing/trace_collection/library_config/rust.md index 036137d163b..4189dd88dfd 100644 --- a/content/en/tracing/trace_collection/library_config/rust.md +++ b/content/en/tracing/trace_collection/library_config/rust.md @@ -1,5 +1,5 @@ --- -title: Configuring the Rust Tracing Library +title: Configuring the Rust SDK code_lang: rust type: multi-code-lang code_lang_weight: 80 @@ -109,7 +109,7 @@ It is recommended to use `DD_ENV`, `DD_SERVICE`, and `DD_VERSION` to set `env`, `DD_LOG_LEVEL` : **Default**: `ERROR`
-: Sets the internal log level for the tracer. Valid values: `DEBUG`, `INFO`, `WARN`, `ERROR`. +: Sets the internal log level for the SDK. Valid values: `DEBUG`, `INFO`, `WARN`, `ERROR`. ## Sampling diff --git a/content/en/tracing/trace_collection/runtime_config/_index.md b/content/en/tracing/trace_collection/runtime_config/_index.md index dc9f045ff8f..485db72d924 100644 --- a/content/en/tracing/trace_collection/runtime_config/_index.md +++ b/content/en/tracing/trace_collection/runtime_config/_index.md @@ -9,7 +9,7 @@ further_reading: ## Overview -Configuration at runtime lets you modify APM library configuration from the Datadog UI, without needing to restart your application or service. You don't need to wait for a new deployment or code change to update your configuration. Instead, update it right away with configuration at runtime. +Configuration at runtime lets you modify Datadog SDK configuration from the Datadog UI, without needing to restart your application or service. You don't need to wait for a new deployment or code change to update your configuration. Instead, update it right away with configuration at runtime. {{< img src="/tracing/runtime_config/runtime-config-nav.mp4" alt="Walk through Software Catalog to use configuration at runtime." video="true" style="width:100%;">}} diff --git a/content/en/tracing/trace_collection/single-step-apm/docker.md b/content/en/tracing/trace_collection/single-step-apm/docker.md index e4c8acf0c30..3729c5501a8 100644 --- a/content/en/tracing/trace_collection/single-step-apm/docker.md +++ b/content/en/tracing/trace_collection/single-step-apm/docker.md @@ -33,7 +33,7 @@ To enable APM in a Docker Linux container: ## Set SDK tracer versions -By default, Single Step Instrumentation installs the latest major versions of Datadog APM SDKs. Minor version updates are applied automatically when they become available. +By default, Single Step Instrumentation installs the latest major versions of Datadog SDKs. Minor version updates are applied automatically when they become available. You may want to customize SDK versions based on your application's language version or specific environment requirements. You can control the major and minor versions used by customizing library versions during setup. diff --git a/content/en/tracing/trace_collection/single-step-apm/kubernetes.md b/content/en/tracing/trace_collection/single-step-apm/kubernetes.md index b77aa017467..3bfd37d81fe 100644 --- a/content/en/tracing/trace_collection/single-step-apm/kubernetes.md +++ b/content/en/tracing/trace_collection/single-step-apm/kubernetes.md @@ -19,7 +19,7 @@ further_reading: ## Overview -In a Kubernetes environment, use Single Step Instrumentation (SSI) for APM to install the Datadog Agent and [instrument][3] your applications with the Datadog APM SDKs in one step. +In a Kubernetes environment, use Single Step Instrumentation (SSI) for APM to install the Datadog Agent and [instrument][3] your applications with the Datadog SDKs in one step. ## Requirements @@ -171,8 +171,8 @@ Each target block has the following keys: | `name` | The name of the target block. This has no effect on monitoring state and is used only as metadata. | | `namespaceSelector` | The namespace(s) to instrument. Specify using one or more of:
- `matchNames`: A list of one or more namespace name(s).
- `matchLabels`: A list of one or more label(s) defined in `{key,value}` pairs.
- `matchExpressions`: A list of namespace selector requirements.
Namespaces must meet all criteria to match. For more details, see the [Kubernetes selector documentation][10].| | `podSelector` | The pod(s) to instrument. Specify using one or more of:
- `matchLabels`: A list of one or more label(s) defined in `{key,value}` pairs.
- `matchExpressions`: A list of pod selector requirements.
Pods must meet all criteria to match. For more details, see the [Kubernetes selector documentation][10]. | -| `ddTraceVersions` | The [Datadog APM SDK][9] version to use for each language. | -| `ddTraceConfigs` | APM SDK configs that allow setting Unified Service Tags, enabling Datadog products beyond tracing, and customizing other APM settings. [See full list of options][8]. | +| `ddTraceVersions` | The [Datadog SDK][9] version to use for each language. | +| `ddTraceConfigs` | Datadog SDK configs that allow setting Unified Service Tags, enabling Datadog products beyond tracing, and customizing other APM settings. [See full list of options][8]. | The file you need to configure depends on how you enabled Single Step Instrumentation: - If you enabled SSI with Datadog Operator, edit `datadog-agent.yaml`. @@ -189,7 +189,7 @@ Review the following examples demonstrating how to select specific services: This configuration: - enables APM for all namespaces except the `jenkins` namespace. - **Note**: use `enabledNamespaces` to disable for all namespaces except those listed. -- instructs Datadog to instrument the Java applications with the default Java APM SDK and Python applications with `v.3.1.0` of the Python APM SDK. +- instructs Datadog to instrument the Java applications with the default Java SDK and Python applications with `v.3.1.0` of the Python SDK. {{< highlight yaml "hl_lines=4-10" >}} apm: @@ -212,11 +212,11 @@ This configuration creates two targets blocks: - The first block (named `login-service_namespace`): - enables APM for services in the namespace `login-service`. - - instructs Datadog to instrument services in this namespace with the default version of the Java APM SDK. + - instructs Datadog to instrument services in this namespace with the default version of the Java SDK. - sets environment variable `DD_PROFILING_ENABLED` for this target group - The second block (named `billing-service_apps`) - enables APM for services in the namespace(s) with label `app:billing-service`. - - instructs Datadog to instrument this set of services with `v3.1.0` of the Python APM SDK. + - instructs Datadog to instrument this set of services with `v3.1.0` of the Python SDK. {{< highlight yaml "hl_lines=4-28" >}} apm: @@ -394,16 +394,16 @@ To disable instrumentation for specific namespaces, add `disabledNamespaces` con {{< /collapse-content >}} -#### Specify tracing library versions +#### Specify SDK versions -
Starting with Datadog Cluster Agent v7.52.0+, you can automatically instrument a subset of your applications, based on the tracing libraries you specify.
+Starting with Datadog Cluster Agent v7.52.0+, you can automatically instrument a subset of your applications, based on the SDKs you specify.
-Specify Datadog tracing libraries and their versions to automatically instrument applications written in those languages. You can configure this in two ways, which are applied in the following order of precedence:
+Specify Datadog SDKs and their versions to automatically instrument applications written in those languages. You can configure this in two ways, which are applied in the following order of precedence:
1. [Specify at the service level](#specify-at-the-service-level), or
2. [Specify at the cluster level](#specify-at-the-cluster-level).
-**Default**: If you don't specify any library versions, applications written in supported languages are automatically instrumented using the latest tracing library versions.
+**Default**: If you don't specify any library versions, applications written in supported languages are automatically instrumented using the latest SDK versions.
##### Specify at the service level
@@ -514,7 +514,7 @@ Datadog publishes instrumentation libraries images on gcr.io, Docker Hub, and Am
The `DD_ADMISSION_CONTROLLER_AUTO_INSTRUMENTATION_CONTAINER_REGISTRY` environment variable in the Datadog Cluster Agent configuration specifies the registry used by the Admission Controller. The default value is `gcr.io/datadoghq`.
-You can pull the tracing library from a different registry by changing it to `docker.io/datadog`, `public.ecr.aws/datadog`, or another URL if you are hosting the images in a local container registry.
+You can pull the SDK from a different registry by changing it to `docker.io/datadog`, `public.ecr.aws/datadog`, or another URL if you are hosting the images in a local container registry.
For instructions on changing your container registry, see [Changing Your Container Registry][33].
@@ -724,11 +724,11 @@ See [workload selection][4] for additional examples.
{{% /collapse-content %}}
-{{% collapse-content title="Control which APM SDKs are loaded" level="h3" expanded=false id="id-for-anchoring" %}}
+{{% collapse-content title="Control which Datadog SDKs are loaded" level="h3" expanded=false id="id-for-anchoring" %}}
-Use `ddTraceVersions` in your Agent Helm config to control both the language and the version of the APM SDK. This prevents unnecessary SDKs from being downloaded, which minimizes init-container footprint, reduces image size, and allows for more deliberate tracer upgrades (for example, to meet compliance requirements or simplify debugging).
+Use `ddTraceVersions` in your Agent Helm config to control both the language and the version of the Datadog SDK. This prevents unnecessary SDKs from being downloaded, which minimizes init-container footprint, reduces image size, and allows for more deliberate tracer upgrades (for example, to meet compliance requirements or simplify debugging).
-#### Example: Specify a Java APM SDK for a namespace
+#### Example: Specify a Java SDK for a namespace
Only Java applications run in the `login-service` namespace. To avoid downloading other SDKs, configure the Agent to target that namespace and inject only the Java SDK version 1.48.2.
diff --git a/content/en/tracing/trace_collection/single-step-apm/linux.md b/content/en/tracing/trace_collection/single-step-apm/linux.md
index 80a6aa7af21..5e6fcced71b 100644
--- a/content/en/tracing/trace_collection/single-step-apm/linux.md
+++ b/content/en/tracing/trace_collection/single-step-apm/linux.md
@@ -33,7 +33,7 @@ To enable APM on a Linux host:
## Set SDK tracer versions
-By default, Single Step Instrumentation installs the latest versions of Datadog APM SDKs.
+By default, Single Step Instrumentation installs the latest versions of Datadog SDKs.
You may want to choose specific SDK versions for compatibility with your application's language version or specific environment requirements.
diff --git a/content/en/tracing/trace_collection/single-step-apm/troubleshooting.md b/content/en/tracing/trace_collection/single-step-apm/troubleshooting.md
index 5b351d12e74..841336dbccd 100644
--- a/content/en/tracing/trace_collection/single-step-apm/troubleshooting.md
+++ b/content/en/tracing/trace_collection/single-step-apm/troubleshooting.md
@@ -13,7 +13,7 @@ further_reading:
## Overview
-Single Step Instrumentation (SSI) helps instrument applications by automatically loading application processes with the Datadog APM SDKs. SSI works for applications running on Linux hosts, in container environments such as Kubernetes and Docker, and for .NET applications served by Windows IIS—without requiring changes to application dependencies or images. If you encounter issues enabling APM with SSI, use this guide to troubleshoot and resolve common problems. For further assistance, contact [Datadog Support][1].
+Single Step Instrumentation (SSI) helps instrument applications by automatically loading application processes with the Datadog SDKs. SSI works for applications running on Linux hosts, in container environments such as Kubernetes and Docker, and for .NET applications served by Windows IIS—without requiring changes to application dependencies or images. If you encounter issues enabling APM with SSI, use this guide to troubleshoot and resolve common problems. For further assistance, contact [Datadog Support][1].
## Troubleshooting methods
@@ -89,7 +89,7 @@ To enable debug logs:
{{< code-block lang="yaml" disable_copy="true" collapsible="true" >}}
env:
- - name: DD_TRACE_DEBUG # debug logging for the tracer
+ - name: DD_TRACE_DEBUG # debug logging for the SDK
value: "true"
- name: DD_APM_INSTRUMENTATION_DEBUG # debug logging for the injector
value: "true"
@@ -103,7 +103,7 @@ There are several configuration mechanisms that can block or alter injection beh
### Storage requirements
-SSI downloads language tracing libraries and an injector package onto each host. The amount of disk space required depends on the number of languages in use and the number of pods being instrumented. A rough estimate is:
+SSI downloads language SDKs and an injector package onto each host. The amount of disk space required depends on the number of languages in use and the number of pods being instrumented. A rough estimate is:
[sum of the language library sizes]
@@ -169,7 +169,7 @@ The value should be a JSON string that applies the necessary security context to
### Custom instrumentation
-Custom instrumentation still requires you to import the tracing library. Configuration variables like .NET's `DD_TRACE_METHODS` remain available for defining custom spans.
+Custom instrumentation still requires you to import the SDK. Configuration variables like .NET's `DD_TRACE_METHODS` remain available for defining custom spans.
## Environment-specific troubleshooting
@@ -300,7 +300,7 @@ SSI does not inject into applications that already use a `-javaagent` option or
### Ruby
-Ruby injection modifies the `Gemfile` to add the Datadog tracing library. If injection support is later removed, the application may fail to start due to the missing dependency.
+Ruby injection modifies the `Gemfile` to add the Datadog SDK. If injection support is later removed, the application may fail to start due to the missing dependency.
To resolve this, restore the original `Gemfile`. If you still want to use APM after removing injection, run `bundle install` to download the gem.
diff --git a/content/en/tracing/trace_collection/span_links/_index.md b/content/en/tracing/trace_collection/span_links/_index.md
index 0e49f5d77d3..ef07a677473 100644
--- a/content/en/tracing/trace_collection/span_links/_index.md
+++ b/content/en/tracing/trace_collection/span_links/_index.md
@@ -56,9 +56,9 @@ If your application is instrumented with:
**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].
-Agent v7.52.0 or greater is required to generate span links using [Datadog tracing libraries][7]. Support for span links was introduced in the following releases:
+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:
-| Language | Minimum tracing library version |
+| Language | Minimum SDK version |
|-----------|---------------------------------|
| C++/Proxy | Not yet supported |
| Go | 1.61.0 |
diff --git a/content/en/tracing/trace_collection/trace_context_propagation/_index.md b/content/en/tracing/trace_collection/trace_context_propagation/_index.md
index 9aa3c7684fe..064279f1574 100644
--- a/content/en/tracing/trace_collection/trace_context_propagation/_index.md
+++ b/content/en/tracing/trace_collection/trace_context_propagation/_index.md
@@ -23,7 +23,7 @@ further_reading:
text: 'Interoperability of OpenTelemetry API and Datadog instrumented traces'
---
-Trace Context propagation is the mechanism of passing tracing information like Trace ID, Span ID, and sampling decisions from one part of a distributed application to another. This enables all traces (and additional telemetry) in a request to be correlated. When automatic instrumentation is enabled, trace context propagation is handled automatically by the APM SDK.
+Trace Context propagation is the mechanism of passing tracing information like Trace ID, Span ID, and sampling decisions from one part of a distributed application to another. This enables all traces (and additional telemetry) in a request to be correlated. When automatic instrumentation is enabled, trace context propagation is handled automatically by the Datadog SDK.
By default, the Datadog SDK extracts and injects distributed tracing headers using the following formats:
@@ -311,7 +311,7 @@ This function's optional argument accepts an array of injection style names. It
{{% collapse-content title="RabbitMQ" level="h4" %}}
-The PHP APM SDK supports automatic tracing of the `php-amqplib/php-amqplib` library (version 0.87.0+). However, in some cases, your distributed trace may be disconnected. For example, when reading messages from a distributed queue using the `basic_get` method outside an existing trace, you need to add a custom trace around the `basic_get` call and corresponding message processing:
+The PHP SDK supports automatic tracing of the `php-amqplib/php-amqplib` library (version 0.87.0+). However, in some cases, your distributed trace may be disconnected. For example, when reading messages from a distributed queue using the `basic_get` method outside an existing trace, you need to add a custom trace around the `basic_get` call and corresponding message processing:
```php
// Create a surrounding trace
diff --git a/content/en/tracing/trace_collection/trace_context_propagation/ruby_v1.md b/content/en/tracing/trace_collection/trace_context_propagation/ruby_v1.md
index 06a71590806..ee518b677c0 100644
--- a/content/en/tracing/trace_collection/trace_context_propagation/ruby_v1.md
+++ b/content/en/tracing/trace_collection/trace_context_propagation/ruby_v1.md
@@ -13,7 +13,7 @@ further_reading:
### Headers extraction and injection
-Datadog APM tracer supports [B3][6] and [W3C Trace Context][7] header extraction and injection for distributed tracing.
+Datadog SDK supports [B3][6] and [W3C Trace Context][7] header extraction and injection for distributed tracing.
Distributed headers injection and extraction is controlled by configuring injection and extraction styles. The following styles are supported:
@@ -51,7 +51,7 @@ Datadog.configure do |c|
end
```
-For more information about trace context propagation configuration, read [the Distributed Tracing section][1] in the Ruby Tracing Library Configuration docs.
+For more information about trace context propagation configuration, read [the Distributed Tracing section][1] in the Ruby SDK Configuration docs.
## Further Reading
diff --git a/content/en/tracing/trace_collection/tracing_naming_convention/_index.md b/content/en/tracing/trace_collection/tracing_naming_convention/_index.md
index 0fdd784494b..8e52e905c6d 100644
--- a/content/en/tracing/trace_collection/tracing_naming_convention/_index.md
+++ b/content/en/tracing/trace_collection/tracing_naming_convention/_index.md
@@ -14,7 +14,7 @@ further_reading:
## Overview
-[Datadog tracing libraries][1] provide out-of-the-box support for instrumenting a variety of libraries.
+[Datadog SDKs][1] provide out-of-the-box support for instrumenting a variety of libraries.
These instrumentations generate spans to represent logical units of work in distributed systems.
Each span consists of [span tags][2] to provide additional information on the unit of work happening in the system. Naming conventions describe the name and content that can be used in span events.
diff --git a/content/en/tracing/trace_explorer/span_tags_attributes.md b/content/en/tracing/trace_explorer/span_tags_attributes.md
index 7c9c0917e34..aed21ccc8af 100644
--- a/content/en/tracing/trace_explorer/span_tags_attributes.md
+++ b/content/en/tracing/trace_explorer/span_tags_attributes.md
@@ -25,7 +25,7 @@ Reserved attributes are a subset of span attributes that are present on every sp
### Span attributes
-Span attributes are the content of your span. These are collected out-of-the-box in tracing libraries using automatic instrumentation, manually using custom instrumentation, or remapped in the Datadog backend based on source attributes (see [peer attributes][11], remapped from some source attributes). To search on a specific span attribute, you must prepend an `@` character at the beginning of the attribute key.
+Span attributes are the content of your span. These are collected out-of-the-box in SDKs using automatic instrumentation, manually using custom instrumentation, or remapped in the Datadog backend based on source attributes (see [peer attributes][11], remapped from some source attributes). To search on a specific span attribute, you must prepend an `@` character at the beginning of the attribute key.
For instance, to find spans representing calls to a `users` table from a postgres database, use the following query: `@peer.db.name:users @peer.db.system:postgres`.
diff --git a/content/en/tracing/trace_pipeline/adaptive_sampling.md b/content/en/tracing/trace_pipeline/adaptive_sampling.md
index 792d24d1031..36e8c3bcff4 100644
--- a/content/en/tracing/trace_pipeline/adaptive_sampling.md
+++ b/content/en/tracing/trace_pipeline/adaptive_sampling.md
@@ -35,7 +35,7 @@ To configure services to use adaptive sampling, follow the instructions listed b
### Tracing library versions
-The following table lists minimum tracing library versions required for adaptive sampling:
+The following table lists minimum SDK versions required for adaptive sampling:
| Language | Minimum version required |
|-------------|--------------------------|
@@ -109,7 +109,7 @@ That monthly target volume is recomputed every 30 minutes.
{{< img src="/tracing/guide/adaptive_sampling/volume_based_target_setting.png" alt="Volume based target setting" style="width:100%;">}}
If you are configuring the first service to adaptive sampling, ensure that the ingestion volume target is `>0`. For subsequent services, you should increase the allocated budget after the new service is onboarded to account for the new volume.
- The configured budget is only allocated to services enrolled in adaptive sampling. It does not include ingested volume from services not enrolled in adaptive sampling, local sampling rules, or other sampling mechanisms configured locally in the Agent or tracing libraries.
+ The configured budget is only allocated to services enrolled in adaptive sampling. It does not include ingested volume from services not enrolled in adaptive sampling, local sampling rules, or other sampling mechanisms configured locally in the Agent or SDKs.
## Configure adaptive sampling for a service
@@ -130,7 +130,7 @@ The table includes:
- **Downstream bytes**: Ingested bytes from spans where the sampling decision starts from that service and resource, including downstream services.
- **Configuration**: Source of the resource sampling rate:
- `AUTOMATIC`: [Default head-based sampling mechanism][8] from the Agent.
- - `CONFIGURED LOCAL`: [Sampling rule][7] set locally in the tracing library.
+ - `CONFIGURED LOCAL`: [Sampling rule][7] set locally in the SDK.
- `CONFIGURED REMOTE`: Remote sampling rule set from the Datadog UI.
- `ADAPTIVE REMOTE`: Adaptive sampling rules set by Datadog.
diff --git a/content/en/tracing/trace_pipeline/ingestion_controls.md b/content/en/tracing/trace_pipeline/ingestion_controls.md
index fe3337fa024..351036d6840 100644
--- a/content/en/tracing/trace_pipeline/ingestion_controls.md
+++ b/content/en/tracing/trace_pipeline/ingestion_controls.md
@@ -60,7 +60,7 @@ Traffic Breakdown
: A detailed breakdown of traffic sampled and unsampled for traces starting from the service. See [Traffic breakdown](#traffic-breakdown) for more information.
Ingestion Configuration
-: Shows `Automatic` if the [default head-based sampling mechanism][4] from the Agent applies. If the ingestion was configured with [trace sampling rules][8], the service is marked as `Configured`; a `Local` label is set when the sampling rule is applied from configuration in the tracing library, a `Remote` label is set when the sampling rule is applied remotely, from the UI. For more information about configuring ingestion for a service, read about [changing the default ingestion rate](#configure-the-service-ingestion-rate).
+: Shows `Automatic` if the [default head-based sampling mechanism][4] from the Agent applies. If the ingestion was configured with [trace sampling rules][8], the service is marked as `Configured`; a `Local` label is set when the sampling rule is applied from configuration in the SDK, a `Remote` label is set when the sampling rule is applied remotely, from the UI. For more information about configuring ingestion for a service, read about [changing the default ingestion rate](#configure-the-service-ingestion-rate).
Infrastructure
: Hosts, containers, and functions on which the service is running.
@@ -86,7 +86,7 @@ The breakdown is composed of the following parts:
1. By default, the [Agent automatically sets a sampling rate][4] on services, depending on service traffic.
2. The service is configured to ingest a certain percentage of traces using [sampling rules][8].
-- **Complete traces dropped by the tracer rate limiter** (orange): When you choose to manually set the service ingestion rate as a percentage with trace sampling rules, a rate limiter is automatically enabled, set to 100 traces per second by default. See the [rate limiter][8] documentation to change this rate.
+- **Complete traces dropped by the SDK rate limiter** (orange): When you choose to manually set the service ingestion rate as a percentage with trace sampling rules, a rate limiter is automatically enabled, set to 100 traces per second by default. See the [rate limiter][8] documentation to change this rate.
- **Traces dropped due to the Agent CPU or RAM limit** (red): This mechanism may drop spans and create incomplete traces. To fix this, increase the CPU and memory allocation for the infrastructure that the Agent runs on.
@@ -105,7 +105,7 @@ The table lists the applied sampling rates by resource of the service.
- The `Ingested bytes` column surfaces the ingested bytes from spans of the service and resource, while the `Downstream bytes` column surfaces the ingested bytes from spans where the sampling decision is made starting from that service and resource, including bytes from downstream services in the call chain.
- The `Configuration` column surfaces where the resource sampling rate is being applied from:
- `Automatic` if the [default head-based sampling mechanism][4] from the Agent applies.
- - `Local Configured` if a [sampling rule][8] was set locally in the tracing library.
+ - `Local Configured` if a [sampling rule][8] was set locally in the SDK.
- `Remote Configured` if a remote sampling rule was set from the Datadog UI. To learn how to configure sampling rules from the Ingestion Control page, read the section on [remotely configuring sampling rules](#configure-the-service-ingestion-rates-by-resource).
**Note**: If the service is not making sampling decisions, the service's resources will be collapsed under the `Resources not making sampling decisions` row.
@@ -120,11 +120,11 @@ If most of your service ingestion volume is due to decisions taken by upstream s
For further investigations, use the [APM Trace - Estimated Usage Dashboard][12], which provides global ingestion information as well as breakdown graphs by `service`, `env` and `ingestion reason`.
-#### Agent and tracing library versions
+#### Agent and SDK versions
-See the **Datadog Agent and tracing library versions** your service is using. Compare the versions in use to the latest released versions to make sure you are running recent and up-to-date Agents and libraries.
+See the **Datadog Agent and SDK versions** your service is using. Compare the versions in use to the latest released versions to make sure you are running recent and up-to-date Agents and libraries.
-{{< img src="tracing/trace_indexing_and_ingestion/agent_tracer_version.png" style="width:90%;" alt="Agent and tracing library versions" >}}
+{{< img src="tracing/trace_indexing_and_ingestion/agent_tracer_version.png" style="width:90%;" alt="Agent and SDK versions" >}}
### Managing services' sampling rates
@@ -142,7 +142,7 @@ Using **Remote Configuration** for service ingestion rates has specific requirem
- [Remote Configuration][3] enabled for your Agent.
- `APM Remote Configuration Write` [permissions][20]. If you don't have these permissions, ask your Datadog admin to update your permissions from your organization settings.
-Find below the minimum tracing library version required for the feature:
+Find below the minimum SDK version required for the feature:
| Language | Minimum version required |
|----------|--------------------------|
diff --git a/content/en/tracing/trace_pipeline/ingestion_mechanisms.md b/content/en/tracing/trace_pipeline/ingestion_mechanisms.md
index eeaa6b0dbe8..3814331ec31 100644
--- a/content/en/tracing/trace_pipeline/ingestion_mechanisms.md
+++ b/content/en/tracing/trace_pipeline/ingestion_mechanisms.md
@@ -1,6 +1,6 @@
---
title: Ingestion Mechanisms
-description: "Overview of the mechanisms in the tracer and the Agent that control trace ingestion."
+description: "Overview of the mechanisms in the SDK and the Agent that control trace ingestion."
aliases:
- /tracing/trace_ingestion/mechanisms
further_reading:
@@ -21,7 +21,7 @@ further_reading:
{{< img src="tracing/apm_lifecycle/ingestion_sampling_rules.png" style="width:100%; background:none; border:none; box-shadow:none;" alt="Ingestion Sampling Rules" >}}
-Multiple mechanisms are responsible for choosing if spans generated by your applications are sent to Datadog (_ingested_). The logic behind these mechanisms lie in the [tracing libraries][1] and in the Datadog Agent. Depending on the configuration, all or some the traffic generated by instrumented services is ingested.
+Multiple mechanisms are responsible for choosing if spans generated by your applications are sent to Datadog (_ingested_). The logic behind these mechanisms lie in the [SDKs][1] and in the Datadog Agent. Depending on the configuration, all or some the traffic generated by instrumented services is ingested.
To each span ingested, there is attached a unique **ingestion reason** referring to one of the mechanisms described in this page. [Usage metrics][2] `datadog.estimated_usage.apm.ingested_bytes` and `datadog.estimated_usage.apm.ingested_spans` are tagged by `ingestion_reason`.
@@ -37,12 +37,12 @@ Because the decision is made at the beginning of the trace and then conveyed to
You can set sampling rates for head-based sampling in two places:
- At the **[Agent](#in-the-agent)** level (default)
-- At the **[Tracing Library](#in-tracing-libraries-user-defined-rules)** level: any tracing library mechanism overrides the Agent setup.
+- At the **[SDK](#in-tracing-libraries-user-defined-rules)** level: any SDK mechanism overrides the Agent setup.
### In the Agent
`ingestion_reason: auto`
-The Datadog Agent continuously sends sampling rates to tracing libraries to apply at the root of traces. The Agent adjusts rates to achieve a target of overall ten traces per second, distributed to services depending on the traffic.
+The Datadog Agent continuously sends sampling rates to SDKs to apply at the root of traces. The Agent adjusts rates to achieve a target of overall ten traces per second, distributed to services depending on the traffic.
For instance, if service `A` has more traffic than service `B`, the Agent might vary the sampling rate for `A` such that `A` keeps no more than seven traces per second, and similarly adjust the sampling rate for `B` such that `B` keeps no more than three traces per second, for a total of 10 traces per second.
@@ -59,15 +59,15 @@ Set Agent's target traces-per-second in its main configuration file (`datadog.ya
```
**Notes**:
-- The traces-per-second sampling rate set in the Agent only applies to Datadog tracing libraries. It has no effect on other tracing libraries such as OpenTelemetry SDKs.
+- The traces-per-second sampling rate set in the Agent only applies to Datadog SDKs. It has no effect on other SDKs such as OpenTelemetry SDKs.
- The target is not a fixed value. In reality, it fluctuates depending on traffic spikes and other factors.
All the spans from a trace sampled using the Datadog Agent [automatically computed sampling rates](#in-the-agent) are tagged with the ingestion reason `auto`. The `ingestion_reason` tag is also set on [usage metrics][2]. Services using the Datadog Agent default mechanism are labeled as `Automatic` in the [Ingestion Control Page][5] Configuration column.
-### In tracing libraries: user-defined rules
+### In SDKs: user-defined rules
`ingestion_reason: rule`
-For more granular control, use tracing library sampling configuration options:
+For more granular control, use SDK sampling configuration options:
- Set a specific **sampling rate to apply to the root of the trace**, by service, and/or resource name, overriding the Agent's [default mechanism](#in-the-agent).
- Set a **rate limit** on the number of ingested traces per second. The default rate limit is 100 traces per second per service instance (when using the Agent [default mechanism](#in-the-agent), the rate limiter is ignored).
@@ -105,7 +105,7 @@ Configure a rate limit by setting the environment variable `DD_TRACE_RATE_LIMIT`
**Note**: The use of `DD_TRACE_SAMPLE_RATE` is deprecated. Use `DD_TRACE_SAMPLING_RULES` instead. For instance, if you already set `DD_TRACE_SAMPLE_RATE` to `0.1`, set `DD_TRACE_SAMPLING_RULES` to `[{"sample_rate":0.1}]` instead.
-Read more about sampling controls in the [Java tracing library documentation][2].
+Read more about sampling controls in the [Java SDK documentation][2].
[1]: /tracing/guide/resource_based_sampling
[2]: /tracing/trace_collection/dd_libraries/java
@@ -133,7 +133,7 @@ Configure a rate limit by setting the environment variable `DD_TRACE_RATE_LIMIT`
**Note**: The use of `DD_TRACE_SAMPLE_RATE` is deprecated. Use `DD_TRACE_SAMPLING_RULES` instead. For instance, if you already set `DD_TRACE_SAMPLE_RATE` to `0.1`, set `DD_TRACE_SAMPLING_RULES` to `[{"sample_rate":0.1}]` instead.
-Read more about sampling controls in the [Python tracing library documentation][2].
+Read more about sampling controls in the [Python SDK documentation][2].
[1]: https://github.com/DataDog/dd-trace-py/releases/tag/v2.8.0
[2]: /tracing/trace_collection/dd_libraries/python
@@ -160,7 +160,7 @@ export DD_TRACE_SAMPLING_RULES='[{"service": "my-service", "sample_rate": 0.5}]'
Configure a rate limit by setting the environment variable `DD_TRACE_RATE_LIMIT` to a number of traces per second per service instance. If no `DD_TRACE_RATE_LIMIT` value is set, a limit of 100 traces per second is applied.
-Read more about sampling controls in the [Ruby tracing library documentation][1].
+Read more about sampling controls in the [Ruby SDK documentation][1].
[1]: /tracing/trace_collection/dd_libraries/ruby#sampling
{{% /tab %}}
@@ -187,7 +187,7 @@ Configure a rate limit by setting the environment variable `DD_TRACE_RATE_LIMIT`
**Note**: The use of `DD_TRACE_SAMPLE_RATE` is deprecated. Use `DD_TRACE_SAMPLING_RULES` instead. For instance, if you already set `DD_TRACE_SAMPLE_RATE` to `0.1`, set `DD_TRACE_SAMPLING_RULES` to `[{"sample_rate":0.1}]` instead.
-Read more about sampling controls in the [Go tracing library documentation][1].
+Read more about sampling controls in the [Go SDK documentation][1].
[1]: /tracing/trace_collection/dd_libraries/go
[2]: https://github.com/DataDog/dd-trace-go/releases/tag/v1.60.0
@@ -223,7 +223,7 @@ tracer.init({
Configure a rate limit by setting the environment variable `DD_TRACE_RATE_LIMIT` to a number of traces per second per service instance. If no `DD_TRACE_RATE_LIMIT` value is set, a limit of 100 traces per second is applied.
-Read more about sampling controls in the [Node.js tracing library documentation][1].
+Read more about sampling controls in the [Node.js SDK documentation][1].
[1]: /tracing/trace_collection/dd_libraries/nodejs
{{% /tab %}}
@@ -247,7 +247,7 @@ export DD_TRACE_SAMPLE_RATE=0.1
export DD_TRACE_SAMPLING_RULES='[{"service": "my-service", "resource":"GET /checkout", "sample_rate": 1},{"service": "my-service", "sample_rate": 0.2}]'
```
-Read more about sampling controls in the [PHP tracing library documentation][1].
+Read more about sampling controls in the [PHP SDK documentation][1].
[1]: /tracing/trace_collection/dd_libraries/php
{{% /tab %}}
@@ -299,7 +299,7 @@ $env:DD_TRACE_SAMPLING_RULES='[{"service": "my-service", "sample_rate": 0.5}]'
Configure a rate limit by setting the environment variable `DD_TRACE_RATE_LIMIT` to a number of traces per second per service instance. If no `DD_TRACE_RATE_LIMIT` value is set, a limit of 100 traces per second is applied.
-Read more about sampling controls in the [.NET tracing library documentation][1].\
+Read more about sampling controls in the [.NET SDK documentation][1].\
Read more about [configuring environment variables for .NET][2].
[1]: /tracing/trace_collection/automatic_instrumentation/dd_libraries/dotnet-core
@@ -307,7 +307,7 @@ Read more about [configuring environment variables for .NET][2].
{{% /tab %}}
{{< /tabs >}}
-**Note**: All the spans from a trace sampled using a tracing library configuration are tagged with the ingestion reason `rule`. Services configured with user-defined sampling rules are marked as `Configured` in the [Ingestion Control Page][5] Configuration column.
+**Note**: All the spans from a trace sampled using an SDK configuration are tagged with the ingestion reason `rule`. Services configured with user-defined sampling rules are marked as `Configured` in the [Ingestion Control Page][5] Configuration column.
## Error and rare traces
@@ -334,7 +334,7 @@ With Agent version 7.33 and forward, you can configure the error sampler in the
**Notes**:
1. Set the parameter to `0` to disable the error sampler.
2. The error sampler captures local traces with error spans at the Agent level. If the trace is distributed, there is no guarantee that the complete trace is sent to Datadog.
-3. By default, spans dropped by tracing library rules or custom logic such as `manual.drop` are **excluded** under the error sampler.
+3. By default, spans dropped by SDK rules or custom logic such as `manual.drop` are **excluded** under the error sampler.
#### Datadog Agent 7.42.0 and higher
@@ -342,7 +342,7 @@ The error sampling is remotely configurable if you're using the Agent version [7
#### Datadog Agent 6/7.41.0 and higher
-To override the default behavior so that spans dropped by the tracing library rules or custom logic such as `manual.drop` are **included** by the error sampler, enable the feature with: `DD_APM_FEATURES=error_rare_sample_tracer_drop` in the Datadog Agent (or the dedicated Trace Agent container within the Datadog Agent pod in Kubernetes).
+To override the default behavior so that spans dropped by the SDK rules or custom logic such as `manual.drop` are **included** by the error sampler, enable the feature with: `DD_APM_FEATURES=error_rare_sample_tracer_drop` in the Datadog Agent (or the dedicated Trace Agent container within the Datadog Agent pod in Kubernetes).
#### Datadog Agent 6/7.33 to 6/7.40.x
@@ -365,7 +365,7 @@ The rare sampling rate is remotely configurable if you're using the Agent versio
By default, the rare sampler is **not enabled**.
-**Note**: When **enabled**, spans dropped by tracing library rules or custom logic such as `manual.drop` are **excluded** under this sampler.
+**Note**: When **enabled**, spans dropped by SDK rules or custom logic such as `manual.drop` are **excluded** under this sampler.
To configure the rare sampler, update the `apm_config.enable_rare_sampler` setting in the Agent main configuration file (`datadog.yaml`) or with the environment variable `DD_APM_ENABLE_RARE_SAMPLER`:
@@ -374,7 +374,7 @@ To configure the rare sampler, update the `apm_config.enable_rare_sampler` setti
@env DD_APM_ENABLE_RARE_SAMPLER - boolean - optional - default: false
```
-To evaluate spans dropped by tracing library rules or custom logic such as `manual.drop`,
+To evaluate spans dropped by SDK rules or custom logic such as `manual.drop`,
enable the feature with: `DD_APM_FEATURES=error_rare_sample_tracer_drop` in the Trace Agent.
@@ -382,7 +382,7 @@ To evaluate spans dropped by tracing library rules or custom logic such as `manu
By default, the rare sampler is enabled.
-**Note**: When **enabled**, spans dropped by tracing library rules or custom logic such as `manual.drop` **are excluded** under this sampler. To include these spans in this logic, upgrade to Datadog Agent 6.41.0/7.41.0 or higher.
+**Note**: When **enabled**, spans dropped by SDK rules or custom logic such as `manual.drop` **are excluded** under this sampler. To include these spans in this logic, upgrade to Datadog Agent 6.41.0/7.41.0 or higher.
To change the default rare sampler settings, update the `apm_config.disable_rare_sampler` setting in the Agent main configuration file (`datadog.yaml`) or with the environment variable `DD_APM_DISABLE_RARE_SAMPLER`:
@@ -394,7 +394,7 @@ To change the default rare sampler settings, update the `apm_config.disable_rare
## Force keep and drop
`ingestion_reason: manual`
-The head-based sampling mechanism can be overridden at the tracing library level. For example, if you need to monitor a critical transaction, you can force the associated trace to be kept. On the other hand, for unnecessary or repetitive information like health checks, you can force the trace to be dropped.
+The head-based sampling mechanism can be overridden at the SDK level. For example, if you need to monitor a critical transaction, you can force the associated trace to be kept. On the other hand, for unnecessary or repetitive information like health checks, you can force the trace to be dropped.
- Set Manual Keep on a span to indicate that it and all child spans should be ingested. The resulting trace might appear incomplete in the UI if the span in question is not the root span of the trace.
@@ -694,7 +694,7 @@ Manual trace keeping should happen before context propagation. If it is kept aft
## Single spans
`ingestion_reason: single_span`
-If you need to sample a specific span, but don't need the full trace to be available, tracing libraries allow you to set a sampling rate to be configured for a single span.
+If you need to sample a specific span, but don't need the full trace to be available, SDKs allow you to set a sampling rate to be configured for a single span.
For example, if you are building [metrics from spans][6] to monitor specific services, you can configure span sampling rules to ensure that these metrics are based on 100% of the application traffic, without having to ingest 100% of traces for all the requests flowing through the service.
@@ -704,7 +704,7 @@ This feature is available for Datadog Agent v[7.40.0][19]+.
{{< tabs >}}
{{% tab "Java" %}}
-Starting in tracing library [version 1.7.0][1], for Java applications, set by-service and by-operation name **span** sampling rules with the `DD_SPAN_SAMPLING_RULES` environment variable.
+Starting in SDK [version 1.7.0][1], for Java applications, set by-service and by-operation name **span** sampling rules with the `DD_SPAN_SAMPLING_RULES` environment variable.
For example, to collect 100% of the spans from the service named `my-service`, for the operation `http.request`, up to 50 spans per second:
@@ -712,7 +712,7 @@ For example, to collect 100% of the spans from the service named `my-service`, f
@env DD_SPAN_SAMPLING_RULES=[{"service": "my-service", "name": "http.request", "sample_rate":1.0, "max_per_second": 50}]
```
-Read more about sampling controls in the [Java tracing library documentation][2].
+Read more about sampling controls in the [Java SDK documentation][2].
[1]: https://github.com/DataDog/dd-trace-java/releases/tag/v1.7.0
[2]: /tracing/trace_collection/dd_libraries/java
@@ -727,7 +727,7 @@ For example, to collect `100%` of the spans from the service named `my-service`,
```
-Read more about sampling controls in the [Python tracing library documentation][2].
+Read more about sampling controls in the [Python SDK documentation][2].
[1]: https://github.com/DataDog/dd-trace-py/releases/tag/v1.4.0
[2]: /tracing/trace_collection/dd_libraries/python
@@ -741,7 +741,7 @@ For example, to collect `100%` of the spans from the service named `my-service`,
@env DD_SPAN_SAMPLING_RULES=[{"service": "my-service", "name": "http.request", "sample_rate":1.0, "max_per_second": 50}]
```
-Read more about sampling controls in the [Ruby tracing library documentation][2].
+Read more about sampling controls in the [Ruby SDK documentation][2].
[1]: https://github.com/DataDog/dd-trace-rb/releases/tag/v1.5.0
[2]: /tracing/trace_collection/dd_libraries/ruby#sampling
@@ -762,7 +762,7 @@ For example, to collect `100%` of the spans from the service for the resource `P
@env DD_SPAN_SAMPLING_RULES=[{"resource": "POST /api/create_issue", "tags": { "priority":"high" }, "sample_rate":1.0}]
```
-Read more about sampling controls in the [Go tracing library documentation][2].
+Read more about sampling controls in the [Go SDK documentation][2].
[1]: https://github.com/DataDog/dd-trace-go/releases/tag/v1.41.0
[2]: /tracing/trace_collection/dd_libraries/go
@@ -777,7 +777,7 @@ For example, to collect `100%` of the spans from the service named `my-service`,
@env DD_SPAN_SAMPLING_RULES=[{"service": "my-service", "name": "http.request", "sample_rate":1.0, "max_per_second": 50}]
```
-Read more about sampling controls in the [Node.js tracing library documentation][1].
+Read more about sampling controls in the [Node.js SDK documentation][1].
[1]: /tracing/trace_collection/dd_libraries/nodejs
{{% /tab %}}
@@ -790,7 +790,7 @@ For example, to collect `100%` of the spans from the service named `my-service`,
@env DD_SPAN_SAMPLING_RULES=[{"service": "my-service", "name": "http.request", "sample_rate":1.0, "max_per_second": 50}]
```
-Read more about sampling controls in the [PHP tracing library documentation][2].
+Read more about sampling controls in the [PHP SDK documentation][2].
[1]: https://github.com/DataDog/dd-trace-php/releases/tag/0.77.0
[2]: /tracing/trace_collection/dd_libraries/php
@@ -821,7 +821,7 @@ $env:DD_SPAN_SAMPLING_RULES='[{"service": "my-service", "name": "http.request",
}
```
-Read more about sampling controls in the [.NET tracing library documentation][2].
+Read more about sampling controls in the [.NET SDK documentation][2].
[1]: https://github.com/DataDog/dd-trace-dotnet/releases/tag/v2.18.0
[2]: /tracing/trace_collection/dd_libraries/dotnet-core
@@ -863,8 +863,8 @@ Some additional ingestion reasons are attributed to spans that are generated by
| Product | Ingestion Reason | Ingestion Mechanism Description |
|------------|-------------------------------------|---------------------------------|
-| Serverless | `lambda` and `xray` | Your traces received from the [Serverless applications][14] traced with Datadog Tracing Libraries or the AWS X-Ray integration. |
-| App and API Protection | `appsec` | Traces ingested from Datadog tracing libraries and flagged by [AAP][15] as a threat. |
+| Serverless | `lambda` and `xray` | Your traces received from the [Serverless applications][14] traced with Datadog SDKs or the AWS X-Ray integration. |
+| App and API Protection | `appsec` | Traces ingested from Datadog SDKs and flagged by [AAP][15] as a threat. |
| Data Observability: Jobs Monitoring | `data_jobs` | Traces ingested from the Datadog Java Tracer Spark integration or the Databricks integration. |
## Ingestion mechanisms in OpenTelemetry
diff --git a/content/en/tracing/trace_pipeline/metrics.md b/content/en/tracing/trace_pipeline/metrics.md
index 38c95fb8b0c..4d5d472ed5e 100644
--- a/content/en/tracing/trace_pipeline/metrics.md
+++ b/content/en/tracing/trace_pipeline/metrics.md
@@ -45,7 +45,7 @@ The following metrics are associated with ingested spans usage:
To control usage, use `datadog.estimated_usage.apm.ingested_bytes`. Ingestion is metered by volume, not by the number of spans or traces. This metric is tagged with `env`, `service`, and`sampling_service`. These tags help identify which environments and services contribute to the ingestion volume. For more information about the `sampling_service` dimension, read [What is the sampling service?](#what-is-the-sampling-service).
-This metric is also tagged by `ingestion_reason`, reflecting which [ingestion mechanisms][5] are responsible for sending spans to Datadog. These mechanisms are nested in the tracing libraries of the Datadog Agent. For more information about this dimension, see the [Ingestion Reasons dashboard][6].
+This metric is also tagged by `ingestion_reason`, reflecting which [ingestion mechanisms][5] are responsible for sending spans to Datadog. These mechanisms are nested in the SDKs of the Datadog Agent. For more information about this dimension, see the [Ingestion Reasons dashboard][6].
The `datadog.estimated_usage.apm.ingested_traces` metric measures the number of requests sampled per second, and only counts traces sampled by [head-based sampling][7]. This metric is also tagged by `env` and `service` so you can spot which services are starting the most traces.
@@ -78,7 +78,7 @@ In this dashboard, you can find information about:
## APM Ingestion Reasons dashboard
-The [APM Ingestion Reasons dashboard][6] provides insights on each source of ingestion volume. Each ingestion usage metric is tagged with an `ingestion_reason` dimension, so you can see which configuration options (Datadog Agent configuration or tracing library configuration) and products (such as RUM or Synthetic Testing) are generating the most APM data.
+The [APM Ingestion Reasons dashboard][6] provides insights on each source of ingestion volume. Each ingestion usage metric is tagged with an `ingestion_reason` dimension, so you can see which configuration options (Datadog Agent configuration or SDK configuration) and products (such as RUM or Synthetic Testing) are generating the most APM data.
{{< img src="tracing/trace_indexing_and_ingestion/usage_metrics/dashboard_ingestion_reasons.png" style="width:100%;" alt="APM Ingestion Reasons Dashboard" >}}
diff --git a/content/en/tracing/troubleshooting/_index.md b/content/en/tracing/troubleshooting/_index.md
index a8fcb50021b..651e2e6af62 100644
--- a/content/en/tracing/troubleshooting/_index.md
+++ b/content/en/tracing/troubleshooting/_index.md
@@ -12,10 +12,10 @@ further_reading:
text: "Connection Errors"
- link: "/tracing/troubleshooting/tracer_startup_logs/"
tag: "Documentation"
- text: "Datadog tracer startup logs"
+ text: "Datadog SDK startup logs"
- link: "/tracing/troubleshooting/tracer_debug_logs/"
tag: "Documentation"
- text: "Datadog tracer debug logs"
+ text: "Datadog SDK debug logs"
- link: "/tracing/troubleshooting/agent_apm_metrics/"
tag: "Documentation"
text: "APM metrics sent by the Datadog Agent"
@@ -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 tracing libraries 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 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].
The following components are involved in sending APM data to Datadog:
@@ -104,7 +104,7 @@ You can use [Inferred Service dependencies (Preview)][30]. Inferred external API
Or, you can merge the service names using an environment variable such as `DD_SERVICE_MAPPING` or `DD_TRACE_SERVICE_MAPPING`, depending on the language.
-For more information, see [Configure the Datadog Tracing Library][27] or choose your language here:
+For more information, see [Configure the Datadog SDK][27] or choose your language here:
{{< tabs >}}
{{% tab "Java" %}}
@@ -300,11 +300,11 @@ There are several configuration options available to scrub sensitive data or dis
## Debugging and logging
-This section explains how to use debug and startup logs to identify and resolve issues with your Datadog tracer.
+This section explains how to use debug and startup logs to identify and resolve issues with your Datadog SDK.
{{% collapse-content title="Debug logs" level="h4" %}}
-To capture full details on the Datadog tracer, enable debug mode on your tracer by using the `DD_TRACE_DEBUG` environment variable. You might enable it for your own investigation or if Datadog support has recommended it for triage purposes. However, be sure to disable debug logging when you are finished testing to avoid the logging overhead it introduces.
+To capture full details on the Datadog SDK, enable debug mode on your tracer by using the `DD_TRACE_DEBUG` environment variable. You might enable it for your own investigation or if Datadog support has recommended it for triage purposes. However, be sure to disable debug logging when you are finished testing to avoid the logging overhead it introduces.
These logs can surface instrumentation errors or integration-specific errors. For details on enabling and capturing these debug logs, see the [debug mode troubleshooting page][5].
@@ -312,7 +312,7 @@ These logs can surface instrumentation errors or integration-specific errors. Fo
{{% collapse-content title="Startup logs" level="h4" %}}
-During startup, Datadog tracing libraries emit logs that reflect the configurations applied in a JSON object, as well as any errors encountered, including if the Agent can be reached in languages where this is possible. Some languages require these startup logs to be enabled with the environment variable `DD_TRACE_STARTUP_LOGS=true`. For more information, see the [Startup logs][3].
+During startup, Datadog SDKs emit logs that reflect the configurations applied in a JSON object, as well as any errors encountered, including if the Agent can be reached in languages where this is possible. Some languages require these startup logs to be enabled with the environment variable `DD_TRACE_STARTUP_LOGS=true`. For more information, see the [Startup logs][3].
{{% /collapse-content %}}
@@ -332,11 +332,11 @@ When you open a [support ticket][1], the Datadog support team may ask for the fo
1. **Links to a trace or screenshots of the issue**: This helps reproduce your issues for troubleshooting purposes.
-2. **Tracer startup logs**: Startup logs help identify tracer misconfiguration or communication issues between the tracer and the Datadog Agent. By comparing the tracer's configuration with the application or container settings, support teams can pinpoint improperly applied settings.
+2. **Tracer startup logs**: Startup logs help identify tracer misconfiguration or communication issues between the SDK and the Datadog Agent. By comparing the SDK's configuration with the application or container settings, support teams can pinpoint improperly applied settings.
3. **Tracer debug logs**: Tracer debug logs provide deeper insights than startup logs, revealing:
- Proper integration instrumentation during application traffic flow
- - Contents of spans created by the tracer
+ - Contents of spans created by the SDK
- Connection errors when sending spans to the Agent
4. **Datadog Agent flare**: [Datadog Agent flares][12] enable you to see what is happening within the Datadog Agent, for example, if traces are being rejected or malformed. This does not help if traces are not reaching the Datadog Agent, but does help identify the source of an issue, or any metric discrepancies.
@@ -345,7 +345,7 @@ When you open a [support ticket][1], the Datadog support team may ask for the fo
6. **Custom tracing code**: Custom instrumentation, configuration, and adding span tags can significantly impact trace visualizations in Datadog.
-7. **Version information**: Knowing what language, framework, Datadog Agent, and Datadog tracer versions you are using allows Support to verify [Compatibility Requirements][15], check for known issues, or recommend a version upgrades. For example:
+7. **Version information**: Knowing what language, framework, Datadog Agent, and Datadog SDK versions you are using allows Support to verify [Compatibility Requirements][15], check for known issues, or recommend a version upgrades. For example:
{{% /collapse-content %}}
diff --git a/content/en/tracing/troubleshooting/connection_errors.md b/content/en/tracing/troubleshooting/connection_errors.md
index f77b180365a..f2e93fc867d 100644
--- a/content/en/tracing/troubleshooting/connection_errors.md
+++ b/content/en/tracing/troubleshooting/connection_errors.md
@@ -1,11 +1,11 @@
---
title: APM Connection Errors
-description: Diagnose and resolve connection errors between tracing libraries and the Datadog Agent in various deployment environments.
+description: Diagnose and resolve connection errors between SDKs and the Datadog Agent in various deployment environments.
aliases:
- /tracing/faq/why-am-i-getting-errno-111-connection-refused-errors-in-my-application-logs/
---
-If the application with the tracing library cannot reach the Datadog Agent, look for connection errors in the [tracer startup logs][1] or [tracer debug logs][2], which can be found with your application logs.
+If the application with the SDK cannot reach the Datadog Agent, look for connection errors in the [tracer startup logs][1] or [tracer debug logs][2], which can be found with your application logs.
## Errors that indicate an APM Connection problem
@@ -172,11 +172,11 @@ APM Agent
```
## Troubleshooting the connection problem
-Whether it's the tracing library or the Datadog Agent displaying the error, there are a few ways to troubleshoot.
+Whether it's the SDK or the Datadog Agent displaying the error, there are a few ways to troubleshoot.
### Host-based setups
-If your application and the Datadog Agent are not containerized, the application with the tracing library should be trying to send traces to `localhost:8126` or `127.0.0.1:8126`, because that is where the Datadog Agent is listening.
+If your application and the Datadog Agent are not containerized, the application with the SDK should be trying to send traces to `localhost:8126` or `127.0.0.1:8126`, because that is where the Datadog Agent is listening.
If the Datadog Agent shows that APM is not listening, check for port conflicts with port 8126, which is what the APM component of the Datadog Agent uses by default.
@@ -205,7 +205,7 @@ If this command fails, your container cannot access the Agent. Refer to the foll
A great place to get started is the [APM in-app setup documentation][6].
-#### Review where your tracing library is trying to send traces
+#### Review where your SDK is trying to send traces
Using the error logs listed above for each language, check to see where your traces are being directed.
@@ -225,7 +225,7 @@ See the table below for example setups. Some require setting up additional netwo
**Note about web servers**: If the `agent_url` section in the [tracer startup logs][1] has a mismatch against the `DD_AGENT_HOST` environment variable that was passed in, review how environment variables are cascaded for that specific server. For example, in PHP, there's an additional setting to ensure that [Apache][18] or [Nginx][19] pick up the `DD_AGENT_HOST` environment variable correctly.
-If your tracing library is sending traces correctly based on your setup, then proceed to the next step.
+If your SDK is sending traces correctly based on your setup, then proceed to the next step.
#### Review your Datadog Agent status and configuration
diff --git a/content/en/tracing/troubleshooting/correlated-logs-not-showing-up-in-the-trace-id-panel.md b/content/en/tracing/troubleshooting/correlated-logs-not-showing-up-in-the-trace-id-panel.md
index 81601989fd7..ff6d3173788 100644
--- a/content/en/tracing/troubleshooting/correlated-logs-not-showing-up-in-the-trace-id-panel.md
+++ b/content/en/tracing/troubleshooting/correlated-logs-not-showing-up-in-the-trace-id-panel.md
@@ -48,7 +48,7 @@ If the **Log** section is empty for the `trace_id` option, ensure you have a sta
{{< tabs >}}
{{% tab "JSON logs" %}}
- For JSON logs, Step 1 and 2 are automatic. The tracer injects the [trace][1] and [span][2] IDs into the logs, which are automatically remapped by the [reserved attribute remappers][3].
+ For JSON logs, Step 1 and 2 are automatic. The SDK injects the [trace][1] and [span][2] IDs into the logs, which are automatically remapped by the [reserved attribute remappers][3].
If this process is not working as expected, ensure the logs attribute's name containing the trace ID is `dd.trace_id` and verify that the attribute is correctly set in the [reserved attributes'][4] Trace ID section.
diff --git a/content/en/tracing/troubleshooting/dotnet_diagnostic_tool.md b/content/en/tracing/troubleshooting/dotnet_diagnostic_tool.md
index 31bb4813a6c..253dff0c761 100644
--- a/content/en/tracing/troubleshooting/dotnet_diagnostic_tool.md
+++ b/content/en/tracing/troubleshooting/dotnet_diagnostic_tool.md
@@ -5,13 +5,13 @@ description: Use the dd-dotnet diagnostic tool to troubleshoot .NET tracing setu
If your application does not produce traces as expected after installing the .NET tracer, run the diagnostic tool `dd-dotnet` described on this page for basic troubleshooting. It can help you determine issues with your setup, such as missing environment variables, incomplete installation, or an unreachable Agent.
-The diagnostic tool `dd-dotnet` is bundled with the tracing library starting with version 2.42.0. It is located in the tracing library's installation folder, and automatically added to the system `PATH` to be invoked from anywhere.
+The diagnostic tool `dd-dotnet` is bundled with the SDK starting with version 2.42.0. It is located in the SDK's installation folder, and automatically added to the system `PATH` to be invoked from anywhere.
## Installing `dd-trace`
-**This section is for versions of the tracer older than 2.42.0.**
+**This section is for versions of the SDK older than 2.42.0.**
-Older versions of the tracer did not include the `dd-dotnet` tool. You can install the `dd-trace` tool instead. Its features and syntax are similar to `dd-dotnet`.
+Older versions of the SDK did not include the `dd-dotnet` tool. You can install the `dd-trace` tool instead. Its features and syntax are similar to `dd-dotnet`.
You can install `dd-trace` in one of the following ways:
@@ -55,7 +55,7 @@ Process name: SimpleApp
Target process is running with .NET Core
1. Checking Modules Needed so the Tracer Loads:
[SUCCESS]: The native library version 2.42.0.0 is loaded into the process.
- [SUCCESS]: The tracer version 2.42.0.0 is loaded into the process.
+ [SUCCESS]: The SDK version 2.42.0.0 is loaded into the process.
2. Checking DD_DOTNET_TRACER_HOME and related configuration value:
[SUCCESS]: DD_DOTNET_TRACER_HOME is set to 'C:\git\dd-trace-dotnet-2\shared\bin\monitoring-home\win-x64\..' and the
directory was found correctly.
@@ -95,7 +95,7 @@ Process name: SimpleApp
Target process is running with .NET Core
1. Checking Modules Needed so the Tracer Loads:
[WARNING]: The native loader library is not loaded into the process
- [WARNING]: The native tracer library is not loaded into the process
+ [WARNING]: The native SDK is not loaded into the process
[WARNING]: Tracer is not loaded into the process
2. Checking DD_DOTNET_TRACER_HOME and related configuration value:
[WARNING]: DD_DOTNET_TRACER_HOME is set to 'C:\Program Files\Datadog\.NET Tracer\' but the directory does not exist.
@@ -111,7 +111,7 @@ Tracer\win-x64\Datadog.Trace.ClrProfiler.Native.dll but the file is missing or y
[FAILURE]: The environment variable CORECLR_ENABLE_PROFILING should be set to '1' (current value: not set)
6. Checking if process tracing configuration matches Installer or Bundler:
Installer/MSI related documentation:
-https://docs.datadoghq.com/tracing/trace_collection/dd_libraries/dotnet-core/?tab=windows#install-the-tracer
+https://docs.datadoghq.com/tracing/trace_collection/dd_libraries/dotnet-core/?tab=windows#install-the-sdk
[FAILURE]: Unable to find Datadog .NET Tracer program, make sure the tracer has been properly installed with the MSI.
[WARNING]: The registry key SOFTWARE\Classes\CLSID\{846F5F1C-F9AE-4B07-969E-05C26BC060D8}\InprocServer32 is missing. If
using the MSI, make sure the installation was completed correctly try to repair/reinstall it.
@@ -159,7 +159,7 @@ Inspecting worker process 39852
Target process is running with .NET Framework
1. Checking Modules Needed so the Tracer Loads:
[SUCCESS]: The native library version 2.42.0.0 is loaded into the process.
- [SUCCESS]: The tracer version 2.42.0.0 is loaded into the process.
+ [SUCCESS]: The SDK version 2.42.0.0 is loaded into the process.
2. Checking DD_DOTNET_TRACER_HOME and related configuration value:
[SUCCESS]: DD_DOTNET_TRACER_HOME is set to 'C:\Program Files\Datadog\.NET Tracer\' and the directory was found
correctly.
@@ -199,7 +199,7 @@ Inspecting worker process 35152
Target process is running with .NET Framework
1. Checking Modules Needed so the Tracer Loads:
[SUCCESS]: The native library version 2.42.0.0 is loaded into the process.
- [SUCCESS]: The tracer version 2.42.0.0 is loaded into the process.
+ [SUCCESS]: The SDK version 2.42.0.0 is loaded into the process.
2. Checking DD_DOTNET_TRACER_HOME and related configuration value:
[SUCCESS]: DD_DOTNET_TRACER_HOME is set to 'C:\Program Files\Datadog\.NET Tracer\' and the directory was found
correctly.
@@ -224,7 +224,7 @@ Detected agent url: http://127.0.0.1:8126/. Note: this url may be incorrect if y
configuration file.
Connecting to Agent at endpoint http://127.0.0.1:8126/ using HTTP
Detected agent version 7.48.0
- [FAILURE]: The Datadog.Trace assembly could not be found in the GAC. Make sure the tracer has been properly installed
+ [FAILURE]: The Datadog.Trace assembly could not be found in the GAC. Make sure the SDK has been properly installed
with the MSI.
```
diff --git a/content/en/tracing/troubleshooting/quantization.md b/content/en/tracing/troubleshooting/quantization.md
index 45c174c3b66..94fb75ffc39 100644
--- a/content/en/tracing/troubleshooting/quantization.md
+++ b/content/en/tracing/troubleshooting/quantization.md
@@ -10,7 +10,7 @@ further_reading:
text: Replace tags in spans
- link: /tracing/trace_collection/library_config/
tag: Documentation
- text: Tracing Library Configuration
+ text: SDK Configuration
---
## Overview
@@ -48,7 +48,7 @@ To search for these spans in trace search, the query is `resource_name:"SELECT ?
### In-code instrumentation
-If your application runs in an agentless setup or if you prefer to make instrumentation changes more directly in your code, see [the tracer documentation of your application's runtime][3] for information on how to create custom configuration for span names and resource names.
+If your application runs in an agentless setup or if you prefer to make instrumentation changes more directly in your code, see [the SDK documentation of your application's runtime][3] for information on how to create custom configuration for span names and resource names.
### Agent configuration
@@ -82,7 +82,7 @@ Some tracers provide options to customize resource name generation directly:
The Java tracer allows customization of HTTP resource names with the `dd.trace.http.server.path-resource-name-mapping` option, which maps HTTP request paths to custom resource names using Ant-style patterns.
-For more information, read [Configuring the Java Tracing Library][4]
+For more information, read [Configuring the Java SDK][4]
[4]: /tracing/trace_collection/library_config/java/#traces
@@ -96,7 +96,7 @@ The PHP tracer provides several options for URI normalization:
- `DD_TRACE_RESOURCE_URI_MAPPING_INCOMING` normalizes resource naming for incoming requests
- `DD_TRACE_RESOURCE_URI_MAPPING_OUTGOING` normalizes resource naming for outgoing requests
-For more information, read [Configuring the PHP Tracing Library][5]
+For more information, read [Configuring the PHP SDK][5]
[5]: /tracing/trace_collection/library_config/php/#traces
diff --git a/content/en/tracing/troubleshooting/tracer_debug_logs.md b/content/en/tracing/troubleshooting/tracer_debug_logs.md
index 4d9e6007d60..7a3a1f33a87 100644
--- a/content/en/tracing/troubleshooting/tracer_debug_logs.md
+++ b/content/en/tracing/troubleshooting/tracer_debug_logs.md
@@ -1,6 +1,6 @@
---
title: Tracer Debug Logs
-description: Enable and collect debug logs from APM tracers to troubleshoot configuration and connectivity issues.
+description: Enable and collect debug logs from Datadog SDKs to troubleshoot configuration and connectivity issues.
further_reading:
- link: "/tracing/troubleshooting/connection_errors/"
tag: "Documentation"
@@ -64,7 +64,7 @@ Since version `1.58.0`, you can use the `DD_LOG_FORMAT_JSON` environment variabl
{{< programming-lang lang="python" >}}
-The steps for enabling debug mode in the Datadog Python Tracer depends on the version of the tracer your application is using. Choose the scenario that applies:
+The steps for enabling debug mode in the Datadog Python Tracer depends on the version of the SDK your application is using. Choose the scenario that applies:
### Scenario 1: ddtrace version 2.x and higher
@@ -133,7 +133,7 @@ By default, all logs are processed by the default Ruby logger. When using Rails,
Datadog client log messages are marked with `[ddtrace]`, so you can isolate them from other messages.
-You can override the default logger and replace it with a custom one by using the tracer's `log` attribute:
+You can override the default logger and replace it with a custom one by using the SDK's `log` attribute:
```ruby
f = File.new(".log", "w+") # Log messages should go there
@@ -197,11 +197,11 @@ func main() {
To enable debug mode for the Datadog Node.js Tracer, use the environment variable `DD_TRACE_DEBUG=true`.
-**Note:** For versions below 2.X, debug mode could be enabled programmatically inside the tracer initialization but this is no longer supported.
+**Note:** For versions below 2.X, debug mode could be enabled programmatically inside the SDK initialization but this is no longer supported.
**Application Logs**
-In debug mode the tracer will log debug information to `console.log()` and errors to `console.error()`. You can change this behavior by passing a custom logger to the tracer. The logger should contain `debug()` and `error()` methods that can handle messages and errors, respectively.
+In debug mode the SDK will log debug information to `console.log()` and errors to `console.error()`. You can change this behavior by passing a custom logger to the SDK. The logger should contain `debug()` and `error()` methods that can handle messages and errors, respectively.
For example:
@@ -222,11 +222,11 @@ const tracer = require('dd-trace').init({
Then check the Agent logs to see if there is more info about your issue:
-* If the trace was sent to the Agent properly, you should see `Response from the Agent: OK` log entries. This indicates that the tracer is working properly, so the problem may be with the Agent itself. Refer to the [Agent troubleshooting guide][1] for more information.
+* If the trace was sent to the Agent properly, you should see `Response from the Agent: OK` log entries. This indicates that the SDK is working properly, so the problem may be with the Agent itself. Refer to the [Agent troubleshooting guide][1] for more information.
* If an error was reported by the Agent (or the Agent could not be reached), you will see `Error from the Agent` log entries. In this case, validate your network configuration to ensure the Agent can be reached. If you are confident the network is functional and that the error is coming from the Agent, refer to the [Agent troubleshooting guide][1].
-If neither of these log entries is present, then no request was sent to the Agent, which means that the tracer is not instrumenting your application. In this case, [contact Datadog support][2] and provide the relevant log entries with [a flare][3].
+If neither of these log entries is present, then no request was sent to the Agent, which means that the SDK is not instrumenting your application. In this case, [contact Datadog support][2] and provide the relevant log entries with [a flare][3].
For more tracer settings, check out the [API documentation][4].
@@ -260,7 +260,7 @@ Logs files are saved in the following directories by default. Use the `DD_TRACE_
**Note:**: On Linux, you must create the logs directory before you enabled debug mode.
-Since version `2.19.0`, you can use the `DD_TRACE_LOGFILE_RETENTION_DAYS` setting to configure the tracer to delete log files from the current logging directory on startup. The tracer deletes log files the same age and older than the given number of days, with a default value of `32`.
+Since version `2.19.0`, you can use the `DD_TRACE_LOGFILE_RETENTION_DAYS` setting to configure the SDK to delete log files from the current logging directory on startup. The SDK deletes log files the same age and older than the given number of days, with a default value of `32`.
For more details on how to configure the .NET Tracer, see the [Configuration][2] section.
@@ -275,7 +275,7 @@ There are two types of logs that are created in these paths:
{{< programming-lang lang="php" >}}
-To enable debug mode for the Datadog PHP Tracer, set the environment variable `DD_TRACE_DEBUG=true`. See the PHP [configuration docs][1] for details about how and when this environment variable value should be set in order to be properly handled by the tracer.
+To enable debug mode for the Datadog PHP Tracer, set the environment variable `DD_TRACE_DEBUG=true`. See the PHP [configuration docs][1] for details about how and when this environment variable value should be set in order to be properly handled by the SDK.
There are two options to route debug tracer logs to a file.
@@ -288,7 +288,7 @@ With dd-trace-php 0.98.0+, you can specify a path to a log file for certain debu
- **INI**: `datadog.trace.log_file`
**Notes**:
- - For details about where to set `DD_TRACE_LOG_FILE`, review [Configuring the PHP Tracing Library][2].
+ - For details about where to set `DD_TRACE_LOG_FILE`, review [Configuring the PHP SDK][2].
- If `DD_TRACE_LOG_FILE` is not specified, logs go to the default PHP error location (See **Option 2** for more details).
**Option 2:**
@@ -321,14 +321,14 @@ cmake --install .build
## Review debug logs
-When debug mode for your tracer is enabled, tracer-specific log messages report how the tracer was initialized and whether traces were sent to the Agent. Debug logs are stored in a separate path depending on your logging configuration. If you enable application-level tracer information, debug logs are also sent in the flare for [supported languages](#prerequisites). The following log examples show what might appear in your log file.
+When debug mode for your tracer is enabled, tracer-specific log messages report how the SDK was initialized and whether traces were sent to the Agent. Debug logs are stored in a separate path depending on your logging configuration. If you enable application-level tracer information, debug logs are also sent in the flare for [supported languages](#prerequisites). The following log examples show what might appear in your log file.
If there are errors that you don't understand, or if traces are reported as flushed to Datadog but you cannot see them in the Datadog UI, [contact Datadog support][1] and provide the relevant log entries with [a flare][2].
{{< programming-lang-wrapper langs="java,python,ruby,go,nodejs,.NET,php" >}}
{{< programming-lang lang="java" >}}
-**Intialization log for the tracer:**
+**Intialization log for the SDK:**
```java
[main] DEBUG datadog.trace.agent.ot.DDTracer - Using config: Config(runtimeId=, serviceName=, traceEnabled=true, writerType=DDAgentWriter, agentHost=, agentPort=8126, agentUnixDomainSocket=null, prioritySamplingEnabled=true, traceResolverEnabled=true, serviceMapping={}, globalTags={env=none}, spanTags={}, jmxTags={}, excludedClasses=[], headerTags={}, httpServerErrorStatuses=[512, 513, 514, 515, 516, 517, 518, 519, 520, 521, 522, 523, 524, 525, 526, 527, 528, 529, 530, 531, 532, 533, 534, 535, 536, 537, 538, 539, 540, 541, 542, 543, 544, 545, 546, 547, 548, 549, 550, 551, 552, 553, 554, 555, 556, 557, 558, 559, 560, 561, 562, 563, 564, 565, 566, 567, 568, 569, 570, 571, 572, 573, 574, 575, 576, 577, 578, 579, 580, 581, 582, 583, 584, 585, 586, 587, 588, 589, 590, 591, 592, 593, 594, 595, 596, 597, 598, 599, 500, 501, 502, 503, 504, 505, 506, 507, 508, 509, 510, 511], httpClientErrorStatuses=[400, 401, 402, 403, 404, 405, 406, 407, 408, 409, 410, 411, 412, 413, 414, 415, 416, 417, 418, 419, 420, 421, 422, 423, 424, 425, 426, 427, 428, 429, 430, 431, 432, 433, 434, 435, 436, 437, 438, 439, 440, 441, 442, 443, 444, 445, 446, 447, 448, 449, 450, 451, 452, 453, 454, 455, 456, 457, 458, 459, 460, 461, 462, 463, 464, 465, 466, 467, 468, 469, 470, 471, 472, 473, 474, 475, 476, 477, 478, 479, 480, 481, 482, 483, 484, 485, 486, 487, 488, 489, 490, 491, 492, 493, 494, 495, 496, 497, 498, 499], httpClientSplitByDomain=false, partialFlushMinSpans=1000, runtimeContextFieldInjection=true, propagationStylesToExtract=[DATADOG], propagationStylesToInject=[DATADOG], jmxFetchEnabled=true, jmxFetchMetricsConfigs=[], jmxFetchCheckPeriod=null, jmxFetchRefreshBeansPeriod=null, jmxFetchStatsdHost=null, jmxFetchStatsdPort=8125, logsInjectionEnabled=false, reportHostName=false)
diff --git a/content/en/tracing/troubleshooting/tracer_startup_logs.md b/content/en/tracing/troubleshooting/tracer_startup_logs.md
index a41ad4d0fca..0c483b224c2 100644
--- a/content/en/tracing/troubleshooting/tracer_startup_logs.md
+++ b/content/en/tracing/troubleshooting/tracer_startup_logs.md
@@ -14,7 +14,7 @@ Some languages log to a separate file depending on language conventions and the
`CONFIGURATION` logs are a JSON formatted representation of settings applied to your tracer. In languages where an Agent connectivity check is performed, the configuration JSON will also include an `agent_error` key, which indicates whether the Agent is reachable.
-`DIAGNOSTICS` or `ERROR` log entries, in the languages that produce them, happen when the tracer encounters an error during application startup. If you see `DIAGNOSTICS` or `ERROR` log lines, confirm from the indicated log that settings and configurations are applied correctly.
+`DIAGNOSTICS` or `ERROR` log entries, in the languages that produce them, happen when the SDK encounters an error during application startup. If you see `DIAGNOSTICS` or `ERROR` log lines, confirm from the indicated log that settings and configurations are applied correctly.
If you do not see logs at all, ensure that your application logs are not silenced and that your log level is at least `INFO` where applicable.
@@ -29,7 +29,7 @@ If you do not see logs at all, ensure that your application logs are not silence
**Diagnostics:**
-The Java tracer does not output Diagnostics logs. For this check, run the tracer in [debug mode][1].
+The Java tracer does not output Diagnostics logs. For this check, run the SDK in [debug mode][1].
[1]: /tracing/troubleshooting/tracer_debug_logs/
@@ -49,7 +49,7 @@ Log files are saved in the following directories by default. Use the `DD_TRACE_L
**Note:** On Linux, you must create the logs directory before you enable debug mode.
-Since version `2.19.0`, you can use the `DD_TRACE_LOGFILE_RETENTION_DAYS` setting to configure the tracer to delete log files from the current logging directory on startup. The tracer deletes log files the same age and older than the given number of days, with a default value of `32`.
+Since version `2.19.0`, you can use the `DD_TRACE_LOGFILE_RETENTION_DAYS` setting to configure the SDK to delete log files from the current logging directory on startup. The SDK deletes log files the same age and older than the given number of days, with a default value of `32`.
- `dotnet-tracer-managed-{processName}-{timestamp}.log` contains the configuration logs.
@@ -127,7 +127,7 @@ ddtrace.disable => Off => Off
**Configuration:**
-If the tracer is in [DEBUG mode][1], the startup logs will appear in the `error_log` once per process on the first request.
+If the SDK is in [DEBUG mode][1], the startup logs will appear in the `error_log` once per process on the first request.
```text
DATADOG TRACER CONFIGURATION - {"agent_error":"Couldn't connect to server","ddtrace.request_init_hook_reachable":false,"date":"2020-07-01T17:42:50Z","os_name":"Linux 49b1cb4bdd12 4.19.76-linuxkit #1 SMP Tue May 26 11:42:35 UTC 2020 x86_64","os_version":"4.19.76-linuxkit","version":"1.0.0-nightly","lang":"php","lang_version":"7.4.5","env":null,"enabled":true,"service":null,"enabled_cli":false,"agent_url":"https://localhost:8126","debug":false,"analytics_enabled":false,"sample_rate":1.000000,"sampling_rules":null,"tags":null,"service_mapping":null,"distributed_tracing_enabled":true,"priority_sampling_enabled":true,"dd_version":null,"architecture":"x86_64","sapi":"cgi-fcgi","ddtrace.request_init_hook":null,"open_basedir_configured":false,"uri_fragment_regex":null,"uri_mapping_incoming":null,"uri_mapping_outgoing":null,"auto_flush_enabled":false,"generate_root_span":true,"http_client_split_by_domain":false,"measure_compile_time":true,"report_hostname_on_root_span":false,"traced_internal_functions":null,"auto_prepend_file_configured":false,"integrations_disabled":null,"enabled_from_env":true,"opcache.file_cache":null}
@@ -135,7 +135,7 @@ DATADOG TRACER CONFIGURATION - {"agent_error":"Couldn't connect to server","ddtr
**Diagnostics:**
-Failed diagnostics for the PHP tracer print in the `error_log` if the tracer is in [DEBUG mode][1].
+Failed diagnostics for the PHP tracer print in the `error_log` if the SDK is in [DEBUG mode][1].
```text
DATADOG TRACER DIAGNOSTICS - agent_error: Couldn't connect to server
@@ -174,7 +174,7 @@ The Go Tracer prints one of two possible diagnostic lines, one for when the Agen
{{< /programming-lang >}}
{{< programming-lang lang="nodejs" >}}
-Startup logs are disabled by default starting in version 2.x of the tracer. They can be enabled using the environment variable `DD_TRACE_STARTUP_LOGS=true`.
+Startup logs are disabled by default starting in version 2.x of the SDK. They can be enabled using the environment variable `DD_TRACE_STARTUP_LOGS=true`.
**Configuration:**
@@ -250,7 +250,7 @@ export DD_TRACE_STARTUP_LOGS=true
### Output
-When startup logs are enabled, the tracer outputs configuration and diagnostic information.
+When startup logs are enabled, the SDK outputs configuration and diagnostic information.
**Configuration:**
@@ -283,14 +283,14 @@ W, [2020-07-08T21:19:05.765994 #143] WARN -- ddtrace: [ddtrace] DATADOG ERROR -
**Diagnostics:**
-For C++, there are no `DATADOG TRACER DIAGNOSTICS` lines output to the tracer logs. However, if the Agent is not reachable, errors appear in your application logs. In Envoy there is an increase in the metrics `tracing.datadog.reports_failed` and `tracing.datadog.reports_dropped`.
+For C++, there are no `DATADOG TRACER DIAGNOSTICS` lines output to the SDK logs. However, if the Agent is not reachable, errors appear in your application logs. In Envoy there is an increase in the metrics `tracing.datadog.reports_failed` and `tracing.datadog.reports_dropped`.
{{< /programming-lang >}}
{{< /programming-lang-wrapper >}}
## Connection errors
-If your application or startup logs contain `DIAGNOSTICS` errors or messages that the Agent cannot be reached or connected to (varying depending on your language), it means the tracer is unable to send traces to the Datadog Agent.
+If your application or startup logs contain `DIAGNOSTICS` errors or messages that the Agent cannot be reached or connected to (varying depending on your language), it means the SDK is unable to send traces to the Datadog Agent.
If you have these errors, check that your Agent is set up to receive traces for [ECS][1], [Kubernetes][2], [Docker][3] or [any other option][4], or [contact support][5] to review your tracer and Agent configuration.
@@ -298,7 +298,7 @@ See [Connection Errors][6] for information about errors indicating that your ins
## Configuration settings
-If your logs contain only `CONFIGURATION` lines, a useful troubleshooting step is to confirm that the settings output by the tracer match the settings from your deployment and configuration of the Datadog Tracer. Additionally, if you are not seeing specific traces in Datadog, review the [Compatibility Requirements][7] section of the documentation to confirm these integrations are supported.
+If your logs contain only `CONFIGURATION` lines, a useful troubleshooting step is to confirm that the settings output by the SDK match the settings from your deployment and configuration of the Datadog Tracer. Additionally, if you are not seeing specific traces in Datadog, review the [Compatibility Requirements][7] section of the documentation to confirm these integrations are supported.
If an integration you are using is not supported, or you want a fresh pair of eyes on your configuration output to understand why traces are not appearing as expected in Datadog, [contact support][5] who can help you diagnose and create a Feature Request for a new integration.
diff --git a/content/en/universal_service_monitoring/setup.md b/content/en/universal_service_monitoring/setup.md
index 06d04980820..863c1403a55 100644
--- a/content/en/universal_service_monitoring/setup.md
+++ b/content/en/universal_service_monitoring/setup.md
@@ -41,7 +41,7 @@ Additional protocols and traffic encryption methods are in