> For the complete documentation index, see [llms.txt](https://docs.bindplane.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bindplane.com/integrations/destinations/datadog.md).

# Datadog

The Datadog destination sends logs, metrics, and traces to [Datadog](https://docs.datadoghq.com/) using the OpenTelemetry Collector Datadog exporter. Telemetry is delivered to the Datadog intake for the configured Datadog site, authenticated with a Datadog API key.

### Supported Telemetry Types

| Platform | Metrics | Logs | Traces |
| -------- | ------- | ---- | ------ |
| Linux    | ✓       | ✓    | ✓      |
| Windows  | ✓       | ✓    | ✓      |
| macOS    | ✓       | ✓    | ✓      |

### Prerequisites

* A Datadog account and the [Datadog site](https://docs.datadoghq.com/getting_started/site/) your organization is on (for example, US1, EU1).
* A Datadog [API key](https://docs.datadoghq.com/account_management/api-app-keys/) with permission to submit telemetry.
* Outbound network access from the collector to the Datadog intake for your site.

### Configuration

<figure><img src="/files/5wcPDuWMZ8aciCRjPI7C" alt="Bindplane docs - Datadog - image 1"><figcaption></figcaption></figure>

#### General

| Parameter | Type   | Default | Description                                                                                           |
| --------- | ------ | ------- | ----------------------------------------------------------------------------------------------------- |
| Site      | Enum   | `US1`   | Required. The Datadog site to send telemetry to. One of `US1`, `US3`, `US5`, `EU1`, `US1-FED`, `AP1`. |
| API Key   | String |         | Required. Sensitive. The Datadog API key used for authentication.                                     |

#### Advanced

| Parameter     | Type    | Default | Description                                                                             |
| ------------- | ------- | ------- | --------------------------------------------------------------------------------------- |
| Drop Raw Copy | Boolean | `true`  | Logs only. When enabled, drops the raw copy of the log stored in `log.record.original`. |

#### Retry on Failure

| Parameter               | Type    | Default | Description                                                                                                                           |
| ----------------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| Enable Retry on Failure | Boolean | `true`  | Attempt to resend telemetry data that has failed to be transmitted to the destination.                                                |
| Initial interval        | Integer | `5`     | Time (in seconds) to wait after the first failure before retrying. Applies when retry on failure is enabled.                          |
| Max interval            | Integer | `30`    | The upper bound (in seconds) on backoff. Applies when retry on failure is enabled.                                                    |
| Max elapsed time        | Integer | `300`   | Maximum time (in seconds) spent trying to send a batch, to avoid a never-ending retry loop. Applies when retry on failure is enabled. |

#### Sending Queue

| Parameter                 | Type      | Default | Description                                                                                                                                                                          |
| ------------------------- | --------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Enable Sending Queue      | Boolean   | `true`  | Buffer telemetry data temporarily before sending to help ensure data is not lost during a temporary network outage.                                                                  |
| Number of Consumers       | Integer   | `10`    | Number of consumers that dequeue batches. Applies when the sending queue is enabled.                                                                                                 |
| Queue Size                | Integer   | `5000`  | Maximum number of batches kept in memory before dropping. Applies when the sending queue is enabled.                                                                                 |
| Enable Persistent Queuing | Boolean   | `true`  | Buffer telemetry data to disk before sending to help ensure data is not lost during network outages or collector restarts. Applies when the sending queue is enabled.                |
| Persistent Queue Storage  | Extension |         | Required. The storage to use for the persistent queue. Applies when the sending queue and persistent queue are enabled. Defaults to file storage under the collector home directory. |

### Example Configuration

#### Standalone Destination

```yaml
apiVersion: bindplane.observiq.com/v1
kind: Destination
metadata:
  id: datadog
  name: datadog
spec:
  type: datadog
  parameters:
    - name: site
      value: 'US1'
    - name: api_key
      value: '<your-datadog-api-key>'
    - name: retry_on_failure_enabled
      value: 'true'
    - name: sending_queue_enabled
      value: 'true'
    - name: persistent_queue_enabled
      value: 'true'
```

### Configuration Tips

#### Selecting the correct site

* Set `site` to match the [Datadog site](https://docs.datadoghq.com/getting_started/site/) your organization is on. Sending to the wrong site causes authentication failures because the API key is scoped to a single site.
* US Government (FedRAMP) organizations should use `US1-FED`.

#### Protecting the API key

* The `api_key` parameter is sensitive. Treat it as a secret and avoid checking it into source control. Use Bindplane secret handling or environment substitution where possible.

#### Reliable delivery

* Leave the sending queue and persistent queue enabled for production deployments so telemetry survives temporary network outages and collector restarts.
* Persistent queuing requires a storage extension. The default writes to a file storage directory under the collector home; review the [persistent queue documentation](https://docs.bindplane.com/configuration/bindplane-otel-collector/persistent-queue) if you need a different storage backend.

### Troubleshooting

**Symptom:** Telemetry is rejected with authentication or 403 errors. **Solution:** Confirm the `api_key` is valid and that `site` matches the Datadog site the key belongs to. API keys are scoped to a single site, so a US1 key sent to EU1 will be rejected.

**Symptom:** No data appears in Datadog and the collector logs export timeouts. **Solution:** Verify outbound network access from the collector to the Datadog intake for the configured site. Confirm any proxy or firewall allows HTTPS egress to Datadog.

**Symptom:** Logs contain an unwanted raw copy of the original record. **Solution:** Enable `drop_raw_copy` to remove the `log.record.original` attribute before logs are sent to Datadog.

### Related Resources

* [Datadog sites](https://docs.datadoghq.com/getting_started/site/)
* [Datadog API and application keys](https://docs.datadoghq.com/account_management/api-app-keys/)
* [Persistent queue configuration](https://docs.bindplane.com/configuration/bindplane-otel-collector/persistent-queue)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.bindplane.com/integrations/destinations/datadog.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.