diff --git a/hugo/content/en/opentelemetry/instrument/dd_sdks/instrumentation_libraries.md b/hugo/content/en/opentelemetry/instrument/dd_sdks/instrumentation_libraries.md index 1c8b5fb7934..10f15bc9584 100644 --- a/hugo/content/en/opentelemetry/instrument/dd_sdks/instrumentation_libraries.md +++ b/hugo/content/en/opentelemetry/instrument/dd_sdks/instrumentation_libraries.md @@ -201,7 +201,7 @@ To use OpenTelemetry integrations with the Datadog Go SDK, perform the following ## Example -The following is an example instrumenting the `net/http` library with the Datadog Tracer and OpenTelemetry's `net/http` integration: +The following is an example instrumenting the `net/http` library with the Datadog SDK and OpenTelemetry's `net/http` integration: ```go import ( diff --git a/hugo/content/en/opentelemetry/instrument/dd_sdks/otlp_trace_export.md b/hugo/content/en/opentelemetry/instrument/dd_sdks/otlp_trace_export.md index d0d1e2eff6a..2c931062239 100644 --- a/hugo/content/en/opentelemetry/instrument/dd_sdks/otlp_trace_export.md +++ b/hugo/content/en/opentelemetry/instrument/dd_sdks/otlp_trace_export.md @@ -72,7 +72,7 @@ DD_TRACE_OTEL_ENABLED=true By default, traces are sent to `http://localhost:4318/v1/traces`. -To send traces to a different endpoint, set `OTEL_EXPORTER_OTLP_ENDPOINT` or the trace-specific `OTEL_EXPORTER_OTLP_TRACES_ENDPOINT`. See the [OTLP Exporter Configuration][4] documentation for details. +To send traces to a receiver at a different address, set `OTEL_EXPORTER_OTLP_ENDPOINT` or the trace-specific `OTEL_EXPORTER_OTLP_TRACES_ENDPOINT`. See the [OTLP Exporter Configuration][4] documentation for details. ## Verify diff --git a/hugo/content/en/opentelemetry/integrations/host_metrics.md b/hugo/content/en/opentelemetry/integrations/host_metrics.md index 7ce90a22117..b193414b523 100644 --- a/hugo/content/en/opentelemetry/integrations/host_metrics.md +++ b/hugo/content/en/opentelemetry/integrations/host_metrics.md @@ -12,7 +12,7 @@ further_reading: {{< img src="/opentelemetry/collector_exporter/host_metrics.png" alt="OpenTelemetry host metrics dashboard" style="width:100%;" >}} -
The host metrics receiver is only required for the standalone OpenTelemetry Collector. If you are using the DDOT Collector, the Datadog Agent already collects host metrics.
+
If you run the DDOT Collector with the Datadog Agent, you don't need the host metrics receiver. The Agent already collects host metrics.
To collect system metrics such as CPU, disk, and memory usage, enable the [host metrics receiver][1] in your Collector. diff --git a/hugo/content/en/opentelemetry/migrate/ddot_collector.md b/hugo/content/en/opentelemetry/migrate/ddot_collector.md index 825331eb47f..c35a0aa081f 100644 --- a/hugo/content/en/opentelemetry/migrate/ddot_collector.md +++ b/hugo/content/en/opentelemetry/migrate/ddot_collector.md @@ -12,7 +12,7 @@ further_reading: text: "Install the Datadog Distribution of OTel Collector" --- -If you are already using a standalone OpenTelemetry (OTel) Collector for your OTel-instrumented applications, you can migrate to the Datadog Distribution of OpenTelemetry (DDOT) Collector. The DDOT Collector allows you to leverage Datadog's enhanced capabilities, including optimized configurations, seamless integrations, and additional features tailored for the Datadog ecosystem. +If you already use the upstream OpenTelemetry (OTel) Collector for your OTel-instrumented applications, you can migrate to the Datadog Distribution of OpenTelemetry (DDOT) Collector. The DDOT Collector lets you use Datadog's enhanced capabilities, including optimized configurations, integrations, and additional features tailored for the Datadog ecosystem. To migrate to the DDOT Collector, you need to install the Datadog Agent and configure your applications to report the telemetry data. @@ -40,7 +40,7 @@ Before you begin, review your configuration to see if your existing config is su 1. If your setup uses components not included in the Agent by default, follow [Use Custom OpenTelemetry Components with Datadog Agent][4]. 1. If your configuration uses `span_name_as_resource_name` or `span_name_remappings`, review the [New Operation Name Mappings guide][11]. The DDOT Collector enables these new mappings by default. -
The default configuration settings in Datadog's embedded collector may differ from the standard OpenTelemetry Collector configuration defaults. This can affect behavior of components like the filelogreceiver. Review the configuration closely when migrating from a standalone collector.
+
The default configuration settings in Datadog's embedded collector may differ from the standard OpenTelemetry Collector configuration defaults. This can affect behavior of components like the filelogreceiver. Review the configuration closely when migrating from the upstream Collector.
### Example configuration @@ -253,7 +253,7 @@ datadog: ## Configure your application -To configure your existing application to use Datadog Agent instead of standalone Collector, ensure that the correct OTLP endpoint hostname is used. The Datadog Agent with DDOT Collector deployed as a DaemonSet, so the current host needs to be targeted. +To send telemetry from your existing application to the Datadog Agent instead of the upstream Collector, set the correct OTLP endpoint hostname. The Datadog Agent with the DDOT Collector runs as a DaemonSet, so your application needs to target the current host. 1. Go to your application's Deployment manifest file (`deployment.yaml`). 1. Add following environment variables to configure the OTLP endpoint: @@ -274,7 +274,7 @@ env: ### Operation name mapping differences -If you previously used `span_name_as_resource_name` or `span_name_remappings` configurations in your standalone Collector, you need to adapt your configuration. +If you previously used `span_name_as_resource_name` or `span_name_remappings` configurations in your upstream Collector, you need to adapt your configuration. 1. Remove these configurations from your Datadog Exporter and Connector settings. 2. Enable the `enable_operation_and_resource_name_logic_v2` feature flag in your Agent configuration. @@ -332,9 +332,9 @@ After configuring your application, verify that data is flowing correctly to Dat ``` 1. Confirm that telemetry data is being received in your Datadog account. Check logs, traces and metrics to ensure correct data collection and correlation. -## Uninstall standalone Collector +## Uninstall the upstream Collector -After you've confirmed that all data is being collected correctly in Datadog, you can remove the standalone OpenTelemetry Collector: +After you've confirmed that all data is being collected correctly in Datadog, you can remove the upstream OpenTelemetry Collector: 1. Ensure all required data is being collected and displayed in Datadog. 1. Uninstall the open source OpenTelemetry Collector from your environment: diff --git a/hugo/content/en/opentelemetry/migrate/migrate_operation_names.md b/hugo/content/en/opentelemetry/migrate/migrate_operation_names.md index 514801d8c36..95dc88223d2 100644 --- a/hugo/content/en/opentelemetry/migrate/migrate_operation_names.md +++ b/hugo/content/en/opentelemetry/migrate/migrate_operation_names.md @@ -25,7 +25,7 @@ The `enable_operation_and_resource_name_logic_v2` feature flag controls this new - **Datadog Distribution of OpenTelemetry (DDOT) Collector**: Datadog Agent v7.65+ - **OpenTelemetry Collector**: OTel Collector v0.126.0+ -- **OTel to Datadog Agent (OTLP)**: Datadog Agent v7.66+ +- **OTLP Ingest in the Agent**: Datadog Agent v7.66+ If you are using an earlier version and want to use the new logic without upgrading, you can [explicitly enable the new logic](#enabling-the-new-logic-opt-in). diff --git a/hugo/content/en/opentelemetry/setup/collector_exporter/_index.md b/hugo/content/en/opentelemetry/setup/collector_exporter/_index.md index 40344aa32cf..799f59b8db7 100644 --- a/hugo/content/en/opentelemetry/setup/collector_exporter/_index.md +++ b/hugo/content/en/opentelemetry/setup/collector_exporter/_index.md @@ -37,7 +37,7 @@ further_reading: Send traces, metrics, and logs to Datadog using the OpenTelemetry Collector. The configurations on this page are tested with the OpenTelemetry Collector Contrib distribution v0.154.0 and use an OTLP-based telemetry pipeline with the following key components: - **OTLP HTTP exporter**: Sends telemetry to Datadog's OTLP intake endpoints. -- **Span metrics connector**: Generates RED (Rate, Error, Duration) metrics from trace data to power APM features such as the Service Catalog and Service Page. +- **Span metrics connector**: Generates RED (Rate, Error, Duration) metrics from trace data to power APM features such as the Catalog and Service Page. - **Resource detection processor**: Detects host and cloud resource attributes, which Datadog uses for hostname resolution and tagging. - **Datadog extension**: Reports the Collector's configuration to Datadog for Fleet Automation. It does not export telemetry data. @@ -926,7 +926,7 @@ After your application sends telemetry to the Collector, verify that data appear ### Span metrics connector -The `span_metrics` connector generates RED metrics from trace data. These metrics power APM features including the Service Catalog, Service Page, and Resource Page. The connector is configured with dimensions that enable Datadog to compute host tags, peer services, and operation names from your traces. +The `span_metrics` connector generates RED metrics from trace data. These metrics power APM features including the Catalog, Service Page, and Resource Page. The connector is configured with dimensions that enable Datadog to compute host tags, peer services, and operation names from your traces. Each environment-specific configuration in [Configure and deploy the Collector](#2-configure-and-deploy-the-collector) includes the complete `span_metrics` connector block. Retain all of its dimensions when adapting the configuration so Datadog can derive the required host tags, peer services, operation names, and resource names. diff --git a/hugo/content/en/opentelemetry/setup/otlp_ingest_in_the_agent.md b/hugo/content/en/opentelemetry/setup/otlp_ingest_in_the_agent.md index dbd4871a5ae..5a5c9020bfc 100644 --- a/hugo/content/en/opentelemetry/setup/otlp_ingest_in_the_agent.md +++ b/hugo/content/en/opentelemetry/setup/otlp_ingest_in_the_agent.md @@ -25,8 +25,6 @@ OTLP Ingest in the Agent allows you to use observability features in the Datadog {{< img src="/opentelemetry/setup/dd-agent-otlp-ingest.png" alt="Diagram: OpenTelemetry SDK sends data through OTLP to the Datadog Agent, which forwards it to Datadog." style="width:100%;" >}} -
To see which Datadog features are supported with this setup, see the feature compatibility table under OTel to Datadog Agent (OTLP).
- ## Initial setup To get started, you first [instrument your application][3] with OpenTelemetry SDKs. Then, export the telemetry data in OTLP format to the Datadog Agent. Configuring this varies depending on the kind of infrastructure your service is deployed on, as described on the page below. Although the aim is to be compatible with the latest OTLP version, the OTLP Ingest in the Agent is not compatible with all OTLP versions. The versions of OTLP that are compatible with the Datadog Agent are those that are also supported by the OTLP receiver in the OpenTelemetry Collector. To verify the exact versions supported, check the `go.opentelemetry.io/collector` version in the Agent `go.mod` file. diff --git a/hugo/content/en/opentelemetry/troubleshooting.md b/hugo/content/en/opentelemetry/troubleshooting.md index de3d3aabcb5..9e8efbb7c9c 100644 --- a/hugo/content/en/opentelemetry/troubleshooting.md +++ b/hugo/content/en/opentelemetry/troubleshooting.md @@ -293,6 +293,19 @@ To verify the configuration: 1. Check the raw trace data to confirm that container IDs and tags are properly translated into Datadog format (for example, `container.id` should become `container_id`). 2. Verify that container metadata appears on the Containers page. +## Services or trace metrics are missing in APM + +**Symptom**: Traces arrive in Datadog, but services don't appear in the Catalog or on service pages, or trace metrics such as request rate, errors, and latency are missing. + +**Cause**: Datadog didn't receive trace metrics for the traces, or the traces don't identify their service and environment. + +**Resolution**: Check the item that matches your setup: + +- **Upstream OpenTelemetry Collector**: Add the `span_metrics` connector to your traces pipeline. It generates the trace metrics that power the Catalog and service pages. See [Span metrics connector][10]. +- **Datadog Exporter**: Add the Datadog Connector to your traces pipeline to calculate trace metrics. See [Datadog Exporter and Connector][11]. +- **Direct OTLP ingest**: Datadog doesn't compute trace metrics by default for traces sent to the OTLP traces intake endpoint. Add the `compute_stats=true` header to your exporter configuration. See [Traces endpoint][12]. +- **All setups**: Set the `service.name` and `deployment.environment.name` resource attributes. Without `service.name`, OpenTelemetry SDKs report a default name such as `unknown_service`. See [Unified service tagging][13]. + ## Missing metrics in Catalog and dashboards **Symptom**: Metrics are not appearing in the Catalog and dashboards despite being properly collected. @@ -350,3 +363,7 @@ features: [7]: https://github.com/DataDog/datadog-agent/tree/main/comp/otelcol/otlp/components/processor/infraattributesprocessor#readme [8]: https://pkg.go.dev/go.opentelemetry.io/otel/sdk/resource#WithContainerID [9]: /opentelemetry/config/hostname_tagging/#hostname-recommendations +[10]: /opentelemetry/setup/collector_exporter/#span-metrics-connector +[11]: /opentelemetry/setup/collector_exporter/datadog_exporter/ +[12]: /opentelemetry/setup/otlp_ingest/traces/ +[13]: /opentelemetry/correlate/#prerequisite-unified-service-tagging