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

# Shipping from the DataDog Agent

## Overview

groundcover supports ingestion of data from the DataDog agent, you have two options:

1. **Dual Shipping** - continue using DataDog normally while ingesting your traces and metrics in groundcover.
2. **Single Shipping** - Send from the DataDog agent to groundcover exclusively.

### When to use this feature

This feature is mostly used in two scenarios:

1. Evaluation of groundcover - showcasing all data available in the groundcover platform while maintaining your existing stack. In this case you likely need the **dual shipping** method.
2. Post evaluation of groundcover - as you turn off other solutions. Also, for supporting teams migrating from DataDog SDKs to open source standards like OpenTelemetry. You can work on the new SDKs while still using the old ones, and even compare them side-by-side in the platform.

### What data will be received in groundcover?

1. Traces - allowing you to use the DataDog distributed traces generated by your applications
2. APM metrics - allowing you to use DataDog APM metrics (e.g `trace.`) common in monitors and dashboards
3. Custom metrics - sent by your applications using DogStatsD

### About Sampling

No sampling is done when data is sent from the DataDog agent.

## Setting up the Datadog Agent

### Kubernetes

The recommended method to Dual Ship data in Kubernetes is by sending it to groundcover components inside the cluster

* Traces and APM will be forwarded to the `groundcover-sensor` service
* Custom metrics will be forwarded to the `groundcover-sensor` service

#### Configuring the DataDog Kubernetes/Host Agent

Add the following to the DataDog agent configuration:

{% hint style="success" %}
Leave `groundcover-nokeyneeded` as is - do not replace with a real API key
{% endhint %}

#### Dual Shipping

```yaml
datadog:  
  env:
    - name: "DD_APM_ADDITIONAL_ENDPOINTS"
      value: "{\"http://groundcover-sensor.groundcover.svc.cluster.local:8126\": [\"groundcover-nokeyneeded\"]}"
    - name: "DD_ADDITIONAL_ENDPOINTS"
      value: "{\"http://groundcover-sensor.groundcover.svc.cluster.local:8126/datadog\": [\"groundcover-nokeyneeded\"]}"
```

#### Single Shipping

```yaml
datadog:  
  env:
    - name: "DD_APM_DD_URL"
      value: "http://groundcover-sensor.groundcover.svc.cluster.local:8126"
    - name: "DD_DD_URL"
      value: "http://groundcover-sensor.groundcover.svc.cluster.local:8126/datadog"
    - name: "DD_API_KEY"
      value: "groundcover-nokeyneeded"
```

### Non-Kubernetes

#### Get your BYOC site endpoint

Find your BYOC endpoint in the [ingestion keys tab](https://app.groundcover.com/settings?selectedTab=ingestion-keys).

#### Create an ingestion key

See how in the [ingestion key docs](/use-groundcover/remote-access-and-apis/ingestion-keys.md).

#### Configuring the DataDog Non-Kubernetes Agent

Add the following to the DataDog agent configuration:

{% hint style="success" %}
Don't forget to replace "{groundcover-ingestion-key}" with the real ingestion key created.
{% endhint %}

#### Dual Shipping

```bash
DD_APM_ADDITIONAL_ENDPOINTS='{\"https://{BYOC_ENDPOINT}\": [\"{groundcover-ingestion-key}\"]}'
DD_ADDITIONAL_ENDPOINTS='{\"https://{BYOC_ENDPOINT}/datadog\": [\"{groundcover-ingestion-key}\"]}'
```

#### Single Shipping

```bash
DD_APM_DD_URL='https://{BYOC_ENDPOINT}'
DD_DD_URL='https://{BYOC_ENDPOINT}/datadog'
DD_API_KEY='{groundcover-ingestion-key}'
```


---

# 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.groundcover.com/integrations/data-sources/datadog/shipping-from-the-datadog-agent.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.