> 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/collect-data/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](/collect-data/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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.groundcover.com/collect-data/data-sources/datadog/shipping-from-the-datadog-agent.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.