Join us from October 8-10 in New York City to learn the latest tips, trends, and news about GraphQL Federation and API platform engineering.Join us for GraphQL Summit 2024 in NYC
Docs
Start for Free

Datadog exporter (via OTLP)

Configure the Datadog exporter for tracing


Enable and configure the Datadog exporter for tracing in the or .

For general tracing configuration, refer to Router Tracing Configuration.

OTLP configuration

OpenTelemetry protocol (OTLP) is the recommended protocol for transmitting telemetry, including traces, to Datadog.

To setup traces to Datadog via OTLP, you must do the following:

  • Modify the default configuration of the Datadog Agent to accept OTLP traces from the .
  • Configure the router to send traces to the configured Datadog Agent.

Datadog Agent configuration

To configure the Datadog Agent, add OTLP configuration to your datadog.yaml. For example:

datadog.yaml
otlp_config:
receiver:
protocols:
grpc:
endpoint: <dd-agent-ip>:4317

For additional Datadog Agent configuration details, review Datadog's Enabling OTLP Ingestion on the Datadog Agent documentation.

Router configuration

To configure the router, enable the OTLP exporter and set endpoint: <datadog-agent-endpoint>. For example:

router.yaml
telemetry:
exporters:
tracing:
common:
# Configured to forward 10 percent of spans from the Datadog Agent to Datadog. Experiment to find a value that is good for you.
preview_datadog_agent_sampling: true
sampler: 0.1
otlp:
enabled: true
# Optional endpoint, either 'default' or a URL (Defaults to http://127.0.0.1:4317)
endpoint: "${env.DATADOG_AGENT_HOST}:4317"
# Optional batch processor setting, this will enable the batch processor to send concurrent requests in a high load scenario.
batch_processor:
max_concurrent_exports: 100

Adjusting the sampler controls the sampling decisions that the router makes on its own and decreases the rate at which you sample. Your sample rate can have a direct impact on your Datadog bill.

NOTE

If you see warning messages from the router regarding the batch span processor, you may need to adjust your batch_processor settings in your exporter config to match the volume of spans being created in a router instance. This applies to both OTLP and the Datadog native exporters.

Enabling Datadog Agent sampling

The Datadog APM view relies on traces to generate metrics. For these metrics to be accurate, all requests must be sampled and sent to the Datadog agent. To prevent all traces from being sent to Datadog, in your router you must set preview_datadog_agent_sampling to true and adjust the sampler to the desired percentage of traces to be sent to Datadog.

router.yaml
telemetry:
exporters:
tracing:
common:
# Configured to forward 10 percent of spans from the Datadog Agent to Datadog. Experiment to find a value that is good for you.
sampler: 0.1
preview_datadog_agent_sampling: true

NOTE

- The router doesn't support [`in-agent` ingestion control](https://docs.datadoghq.com/tracing/trace_pipeline/ingestion_mechanisms/?tab=java#in-the-agent). - Configuring `traces_per_second` in the Datadog Agent will not dynamically adjust the router's sampling rate to meet the target rate.
  • Using preview_datadog_agent_sampling will send all spans to the Datadog Agent. This will have an impact on the resource usage and performance of both the router and Datadog Agent.

Enabling log correlation

To enable Datadog log correlation, you must configure dd.trace_id to appear on the router span:

router.yaml
telemetry:
instrumentation:
spans:
mode: spec_compliant
router:
attributes:
dd.trace_id: true

Your JSON formatted log messages will automatically output dd.trace_id on each log message if dd.trace_id was detected on the router span.

Datadog native configuration

⚠️ CAUTION

Native Datadog tracing is not part of the OpenTelemetry spec, and given that Datadog supports OTLP we will be deprecating native Datadog tracing in the future. Use OTLP configuration instead.

The router can be configured to connect to either the native, default Datadog agent address or a URL:

router.yaml
telemetry:
exporters:
tracing:
common:
# Configured to forward 10 percent of spans from the Datadog Agent to Datadog. Experiment to find a value that is good for you.
preview_datadog_agent_sampling: true
sampler: 0.1
datadog:
enabled: true
# Optional endpoint, either 'default' or a URL (Defaults to http://127.0.0.1:8126)
endpoint: "http://${env.DATADOG_AGENT_HOST}:8126"
# Optional batch processor setting, this will enable the batch processor to send concurrent requests in a high load scenario.
batch_processor:
max_concurrent_exports: 100
# Enable graphql.operation.name attribute on supergraph spans.
instrumentation:
spans:
mode: spec_compliant
supergraph:
attributes:
graphql.operation.name: true

NOTE

Depending on the volume of spans being created in a router instance, it will be necessary to adjust the batch_processor settings in your exporter config. This applies to both OTLP and the Datadog native exporter.

enabled

Set to true to enable the Datadog exporter. Defaults to false.

enable_span_mapping (default: true)

There are some incompatibilities between Datadog and OpenTelemetry, the Datadog exporter might not provide meaningful contextual information in the exported spans. To fix this, you can configure the router to perform a mapping for the span name and the span resource name.

router.yaml
telemetry:
exporters:
tracing:
datadog:
enabled: true
enable_span_mapping: true

With enable_span_mapping: true, the router performs the following mapping:

  1. Use the OpenTelemetry span name to set the Datadog span .
  2. Use the OpenTelemetry span attributes to set the Datadog span resource name.

Example trace

For example, assume a client sends a MyQuery to the router. The router's sends a query to my-subgraph-name and creates the following trace:

| apollo_router request |
| apollo_router router |
| apollo_router supergraph |
| apollo_router query_planning | apollo_router execution |
| apollo_router fetch |
| apollo_router subgraph |
| apollo_router subgraph_request |

As you can see, there is no clear information about the name of the query, the name of the subgraph, and the name of the query sent to the subgraph.

Instead, when enable_span_mapping is set to true the following trace will be created:

| request /graphql |
| router /graphql |
| supergraph MyQuery |
| query_planning MyQuery | execution |
| fetch fetch |
| subgraph my-subgraph-name |
| subgraph_request MyQuery__my-subgraph-name__0 |

fixed_span_names (default: true)

When fixed_span_names: true, the apollo router to use the original span names instead of the dynamic ones as described by OTel semantic conventions.

router.yaml
telemetry:
exporters:
tracing:
datadog:
enabled: true
fixed_span_names: true

This will allow you to have a finite list of in Datadog on the APM view.

resource_mapping

When set, resource_mapping allows you to specify which attribute to use in the Datadog APM and Trace view. The default resource mappings are:

OpenTelemetry Span NameDatadog Span Operation Name
requesthttp.route
routerhttp.route
supergraphgraphql.operation.name
query_planninggraphql.operation.name
subgraphsubgraph.name
subgraph_requestgraphql.operation.name
http_requesthttp.route

You may override these mappings by specifying the resource_mapping configuration:

router.yaml
telemetry:
exporters:
tracing:
datadog:
enabled: true
resource_mapping:
# Use `my.span.attribute` as the resource name for the `router` span
router: "my.span.attribute"
instrumentation:
spans:
router:
attributes:
# Add a custom attribute to the `router` span
my.span.attribute:
request_header: x-custom-header

If you have introduced a new span in a custom build of the you can enable resource mapping for it by adding it to the resource_mapping configuration.

span_metrics

When set, span_metrics allows you to specify which spans will show span metrics in the Datadog APM and Trace view. By default, span metrics are enabled for:

  • request
  • router
  • supergraph
  • subgraph
  • subgraph_request
  • http_request
  • query_planning
  • execution
  • query_parsing

You may override these defaults by specifying span_metrics configuration:

The following will disable span metrics for the span.

router.yaml
telemetry:
exporters:
tracing:
datadog:
enabled: true
span_metrics:
# Disable span metrics for supergraph
supergraph: false
# Enable span metrics for my_custom_span
my_custom_span: true

If you have introduced a new span in a custom build of the Router you can enable span metrics for it by adding it to the span_metrics configuration.

batch_processor

All exporters support configuration of a batch span processor with batch_processor.

You must tune your batch_processor configuration if you see any of the following messages in your logs:

  • OpenTelemetry trace error occurred: cannot send span to the batch span processor because the channel is full

  • OpenTelemetry metrics error occurred: cannot send span to the batch span processor because the channel is full

The exact settings depend on the bandwidth available for you to send data to your application peformance monitor (APM) and the bandwidth configuration of your APM. Expect to tune these settings over time as your application changes.

telemetry:
exporters:
tracing:
datadog:
batch_processor:
max_export_batch_size: 512
max_concurrent_exports: 1
max_export_timeout: 30s
max_queue_size: 2048
scheduled_delay: 5s

batch_processor configuration reference

AttributeDefaultDescription
scheduled_delay5sThe delay in seconds from receiving the first span to sending the batch.
max_concurrent_exports1The maximum number of overlapping export requests.
max_export_batch_size512The number of spans to include in a batch. May be limited by maximum message size limits.
max_export_timeout30sThe timeout in seconds for sending spans before dropping the data.
max_queue_size2048The maximum number of spans to be buffered before dropping span data.

Datadog native configuration reference

AttributeDefaultDescription
enabledfalseEnable the OTLP exporter.
enable_span_mappingfalseIf span mapping should be used.
endpointhttp://localhost:8126/v0.4/tracesThe endpoint to send spans to.
batch_processorThe batch processor settings.
resource_mappingSee configA map of span names to attribute names.
span_metricsSee configA map of span names to boolean.

Sampler configuration

When using Datadog to gain insight into your router's performance, you need to decide whether to use the Datadog APM view or rely on OTLP metrics. The Datadog APM view is driven by traces. In order for this view to be accurate, all requests must be sampled and sent to the Datadog Agent.

Tracing is expensive both in terms of APM costs and router performance, so you typically will want to set the sampler to sample at low rates in production environments. This, however, impacts the APM view, which will show only a small percentage of traces.

To mitigate this, you can use Datadog Agent sampling mode, where all traces are sent to the Datadog Agent but only a percentage of them are forwarded to Datadog. This keeps the APM view accurate while lowering costs. Note that the router will incur a performance cost of having an effective sample rate of 100%.

Use the following guidelines on how to configure the sampler and preview_datadog_agent_sampling to get the desired behavior:

I want the APM view to show metrics for 100% of traffic, and I am OK with the performance impact on the router.

Set preview_datadog_agent_sampling to true and adjust the sampler to the desired percentage of traces to be sent to Datadog.

router.yaml
telemetry:
exporters:
tracing:
common:
# All requests will be traced and sent to the Datadog agent.
# Only 10 percent of spans will be forwarded from the Datadog agent to Datadog.
preview_datadog_agent_sampling: true
sampler: 0.1

I want the Datadog Agent to be in control of the percentage of traces sent to Datadog.

Use the Datadog Agent's probabalistic_sampling option sampler and set the sampler to always_on to allow the agent to control the sampling rate.

Router config:

router.yaml
telemetry:
exporters:
tracing:
common:
# All requests will be traced and sent to the Datadog agent.
sampler: always_on

Datadog agent config:

otlp_config:
traces:
probabilistic_sampling:
# Only 10 percent of spans will be forwarded to Datadog
sampling_percentage: 10

I want the best performance from the router and I'm not concerned with the APM view. I use metrics and traces to monitor my application.

Set the sample to a low value to reduce the number of traces sent to Datadog. Leave preview_datadog_agent_sampling to false.

router.yaml
telemetry:
exporters:
tracing:
common:
# Only 10 percent of requests will be traced and sent to the Datadog agent. The APM view will only show a subset of total request data but the Router will perform better.
sampler: 0.1
preview_datadog_agent_sampling: false

sampler (default: always_on)

The sampler configuration allows you to control the sampling decisions that the router will make on its own and decrease the rate at which you sample, which can have a direct impact on your Datadog bill.

router.yaml
telemetry:
exporters:
tracing:
common:
# Only 10 percent of spans will be forwarded to the Datadog agent. Experiment to find a value that is good for you!
sampler: 0.1

If you are using the Datadog APM viw then you should set preview_datadog_agent_sampling to true and adjust the sampler to the desired percentage of traces to be sent to Datadog.

preview_datadog_agent_sampling (default: false)

The Datadog APM view relies on traces to generate metrics. For this to be accurate 100% of requests must be sampled and sent to the Datadog agent. To prevent ALL traces from then being sent to Datadog, you must set preview_datadog_agent_sampling to true and adjust the sampler to the desired percentage of traces to be sent to Datadog.

router.yaml
telemetry:
exporters:
tracing:
common:
# Only 10 percent of spans will be forwarded from the Datadog agent to Datadog. Experiment to find a value that is good for you!
preview_datadog_agent_sampling: true
sampler: 0.1

Using preview_datadog_agent_sampling will send all spans to the Datadog Agent, but only the percentage of traces configured by the sampler will be forwarded to Datadog. This means that your APM view will be accurate, but it will incur performance and resource usage costs for both the router and Datadog Agent to send and receive all spans.

If your use case allows your APM view to show only a subset of traces, then you can set preview_datadog_agent_sampling to false. You should alternatively rely on OTLP metrics to gain insight into the router's performance.

NOTE

- The router doesn't support [`in-agent` ingestion control](https://docs.datadoghq.com/tracing/trace_pipeline/ingestion_mechanisms/?tab=java#in-the-agent). - Configuring `traces_per_second` in the Datadog Agent will not dynamically adjust the router's sampling rate to meet the target rate.
Previous
Configuration
Next
Dynatrace
Rate articleRateEdit on GitHubEditForumsDiscord

© 2024 Apollo Graph Inc., d/b/a Apollo GraphQL.

Privacy Policy

Company