Datadog supports a variety of open standards, including OpenTracing and OpenTelemetry. Each of the following languages has support for sending Open Tracing data to Datadog. They all also have support for sending OpenTelemetry data to Datadog via the OpenTelemetry Collector Datadog exporter. Additionally, Python, Ruby, and NodeJS have dedicated OpenTelemetry Datadog span exporters, which export traces from OpenTelemetry tracing clients to a Datadog Agent.
Click your language to see instructions for setting up OpenTracing or language-specific OpenTelemetry exporters. See below for setting up the OpenTelemetry Collector Datadog exporter:
The OpenTelemetry Collector is a vendor-agnostic separate agent process for collecting and exporting telemetry data emitted by many processes. Datadog has an exporter available within the OpenTelemetry Collector to receive traces and metrics data from the OpenTelemetry SDKs, and to forward the data on to Datadog (without the Datadog Agent). It works with all supported languages.
You can deploy the OpenTelemetry Collector via any of the supported methods, and configure it by adding a
datadog exporter to your OpenTelemetry configuration YAML file along with your Datadog API key:
datadog: api: key: "<API key>"
To send the data to the Datadog EU site, also set the
datadog: api: key: "<API key>" site: datadoghq.eu
On each OpenTelemetry-instrumented application, set the resource attributes
service.version using the language’s SDK. As a fall-back, you can also configure hostname (optionally), environment, service name, and service version at the collector level for unified service tagging by following the example configuration file. If you don’t specify the hostname explicitly, the exporter attempts to get an automatic default by checking the following sources in order, falling back to the next one if the current one is unavailable or invalid:
The OpenTelemetry Collector is configured by adding a pipeline to your
otel-collector-configuration.yml file. Supply the relative path to this configuration file when you start the collector by passing it in via the
--config=<path/to/configuration_file> command line argument. For examples of supplying a configuration file, see the OpenTelemetry Collector documentation.
The exporter assumes you have a pipeline that uses the
datadog exporter, and includes a batch processor configured with the following:
10s(10 seconds). A batch representing 10 seconds of traces is a constraint of Datadog’s API Intake for Trace Related Statistics.
timeoutsetting, trace related metrics including
.durationfor different services and service resources will be inaccurate over periods of time.
Here is an example trace pipeline configured with an
batch processor, and
receivers: otlp: processors: batch: timeout: 10s exporters: datadog/api: hostname: customhostname env: prod service: myservice version: myversion tags: - example:tag api: key: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa site: datadoghq.eu service: pipelines: traces: receivers: [otlp] processors: [batch] exporters: [datadog/api]
To see more information and additional examples of how you might configure your collector, see the OpenTelemetry Collector configuration documentation.