> ## Documentation Index
> Fetch the complete documentation index at: https://otel.fyi/llms.txt
> Use this file to discover all available pages before exploring further.

# Datadog

> OpenTelemetry exporter for Datadog

# Datadog Exporter

![Status](https://img.shields.io/badge/status-beta-yellow)

**Available in:** `contrib`

**Maintainers:** [@mx-psi](https://github.com/mx-psi), [@dineshg13](https://github.com/dineshg13), [@liustanley](https://github.com/liustanley), [@songy23](https://github.com/songy23), [@mackjmr](https://github.com/mackjmr), [@jade-guiton-dd](https://github.com/jade-guiton-dd), [@IbraheemA](https://github.com/IbraheemA)

**Source:** [opentelemetry-collector-contrib](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/datadogexporter)

## Supported Telemetry

![Logs](https://img.shields.io/badge/logs-beta-blue) ![Metrics](https://img.shields.io/badge/metrics-beta-green) ![Traces](https://img.shields.io/badge/traces-beta-orange)

## Overview

> Please review the Collector's [security documentation](https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/security-best-practices.md), which contains recommendations on securing sensitive information such as the API key required by this exporter.

> The Datadog Exporter now skips APM stats computation by default. It is recommended to only use the [Datadog Connector](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/connector/datadogconnector) in order to compute APM stats.
> To temporarily revert to the previous behavior, disable the `exporter.datadogexporter.DisableAPMStats` feature gate. Example: `otelcol --config=config.yaml --feature-gates=-exporter.datadogexporter.DisableAPMStats`

Find the full configs of Datadog exporter and their usage in [collector.yaml](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/datadogexporter/examples/collector.yaml). More example configs can be found in the [official documentation](https://docs.datadoghq.com/opentelemetry/setup/collector_exporter/).

## FAQs

### Why am I getting errors 413 - Request Entity Too Large, how do I fix it?

This error indicates the payload size sent by the Datadog exporter exceeds the size limit (see previous examples [https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/16834](https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/16834), [https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/17566](https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/17566)).

This is usually caused by the pipeline batching too many telemetry data before sending to the Datadog API intake. To fix that, prefer using the Datadog exporter `sending_queue::batch` section instead of the batch processor:

```yaml theme={null}
exporters:
  datadog:
    api:
      key: ${env:DD_API_KEY}
    sending_queue:
      batch:
        min_size: 10
        max_size: 100
        flush_timeout: 10s
```

If you are using the batch processor instead, try lowering `send_batch_size` and `send_batch_max_size` in your config. You might want to have a separate batch processor dedicated for datadog exporter if other exporters expect a larger batch size, e.g.

```
processors:
  batch:  # To be used by other exporters
    timeout: 1s
    # Default value for send_batch_size is 8192
  batch/datadog:
    send_batch_max_size: 100
    send_batch_size: 10
    timeout: 10s
...
service:
  pipelines:
    metrics:
      receivers: ...
      processors: [batch/datadog]
      exporters: [datadog]
```

The exact values for `send_batch_size` and `send_batch_max_size` depends on your specific workload. Also note that, Datadog intake has different payload size limits for the 3 signal types:

* Trace intake: 3.2MB
* Log intake: [https://docs.datadoghq.com/api/latest/logs/](https://docs.datadoghq.com/api/latest/logs/)
* Metrics V2 intake: [https://docs.datadoghq.com/api/latest/metrics/#submit-metrics](https://docs.datadoghq.com/api/latest/metrics/#submit-metrics)

### Fall back to the Zorkian metric client with feature gate

Support for Zorkian is now deprecated, please use the metrics export serializer. See [https://github.com/open-telemetry/opentelemetry-collector-contrib/releases/tag/v0.122.0](https://github.com/open-telemetry/opentelemetry-collector-contrib/releases/tag/v0.122.0) and #37930 for more info about Metrics Export Serializer.

### Remap OTel’s service.name attribute to service for logs

**NOTE** this workaround is only needed when feature gate `exporter.datadogexporter.UseLogsAgentExporter` is disabled. This feature gate is enabled by default starting v0.108.0.

For Datadog Exporter versions 0.83.0 - v0.107.0, the `service` field of OTel logs is populated as [OTel semantic convention](https://opentelemetry.io/docs/specs/semconv/resource/#service) `service.name`. However, `service.name` is not one of the default [service attributes](https://docs.datadoghq.com/logs/log_configuration/pipelines/?tab=service#service-attribute) in Datadog’s log preprocessing.

To get the service field correctly populated in your logs, you can specify service.name to be the source of a log’s service by setting a [log service remapper processor](https://docs.datadoghq.com/logs/log_configuration/pipelines/?tab=service#service-attribute).

[beta]: https://github.com/open-telemetry/opentelemetry-collector#beta

[alpha]: https://github.com/open-telemetry/opentelemetry-collector#alpha

[contrib]: https://github.com/open-telemetry/opentelemetry-collector-releases/tree/main/distributions/otelcol-contrib

[AWS]: https://aws-otel.github.io/docs/partners/datadog

### How to add custom log source

In order to add a custom source to your OTLP logs, set resource attribute `datadog.log.source`. This feature requires `exporter.datadogexporter.UseLogsAgentExporter` feature flag to be enabled (now enabled by default).

Example:

```
processors:
  transform/logs:
    log_statements:
      - context: resource
        statements:
          - set(attributes["datadog.log.source"], "otel")
```

### My Collector K8s pod is getting rebooted on startup when I don't manually set a hostname under `exporters::datadog::hostname`

This is due to a bug with underlying hostname detection blocking the `health_check` extension from responding to liveness/readiness probes on startup. To fix, either set `hostname_detection_timeout` to be less than the pod/daemonset `livenessProbe: failureThreshold * periodSeconds` so that the timeout for hostname detection on startup takes less time than the control plane waits before restarting the pod, or leave `hostname_detection_timeout` at the default `25s` value and double-check the `livenessProbe` and `readinessProbe` settings and ensure that the control plane will in fact wait long enough for startup to complete before restarting the pod.

Hostname detection is currently required to initialize the Datadog Exporter, unless a hostname is specified manually under `hostname`.

## Configuration

### Example Configuration

```yaml theme={null}
datadog/api:
  hostname: customhostname
  api:
    key: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    site: datadoghq.eu
    fail_on_invalid_key: true

  traces:
    span_name_remappings:
      "old_name1": "new_name1"
      "old_name2": "new_name2"
    span_name_as_resource_name: true
    trace_buffer: 10

datadog/api2:
  hostname: customhostname

  host_metadata:
    tags: [example:tag]

  api:
    key: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    site: datadoghq.eu

  metrics:
    endpoint: https://api.datadoghq.test

  traces:
    span_name_remappings:
      "old_name3": "new_name3"
      "old_name4": "new_name4"
    endpoint: https://trace.agent.datadoghq.test

  logs:
    endpoint: https://http-intake.logs.datadoghq.test

datadog/default:
  api:
    key: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
```

***

*Last generated: 2026-07-06*