> 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/sending-directly-from-instrumented-services.md).

# Sending Directly from Instrumented Services

## Overview

groundcover supports ingestion of data directly from DataDog SDKs, allowing you to continue using your existing DataDog instrumentation without sending it to DataDog itself.

### Why would you use SDK Redirection?

This method is recommended when you want to leverage your existing SDKs - we know how much work it is adding these - without the need to run a DataDog agent or send the generated data to DataDog.

### What data will be received in groundcover?

1. Traces - allowing you to use the DataDog distributed traces generated by your applications
2. Custom metrics - sent by your applications using DogStatsD

{% hint style="info" %}
Sending custom metrics directly from the SDK is currently only supported for Kubernetes
{% endhint %}

### Traces Sampling in Kubernetes

{% hint style="info" %}
This part is only relevant for Kubernetes setups. Data sent from from non-kubernetes envs is not sampled.
{% endhint %}

groundcover automatically performs sampling for traces sent from DataDog SDKs to the sensors in kubernetes clusters.

{% hint style="success" %}
The default sampling rate is 5%
{% endhint %}

To configure sampling, the relevant values can be used:

```yaml
agent:
  sensor:
    apmIngestor:
      dataDog:
        samplingRatio: 0.05
```

The `samplingRatio` field is a fraction in the range 0-1. For example, 0.1 means 10% of the incoming traces will be sampled and stored in groundcover.

#### Configuring 100% Sampling Ratio (No Sampling)

Use the values below to disable sampling and ingest 100% of the incoming traces.

```yaml
agent:
  sensor:
    apmIngestor:
      dataDog:
        samplingRatio: 1
```

## Setting up Shipping from the Application

### Kubernetes

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

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

#### Configuring the Instrumented Application

Add the following to the application environment variables:

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

```yaml
datadog:  
  env:
    - name: "DD_TRACE_AGENT_URL"
      value: "http://groundcover-sensor.groundcover.svc.cluster.local:8126"
    - name: "DD_DOGSTATSD_URL"
      value: "udp://groundcover-sensor.groundcover.svc.cluster.local:8125"
```

### Standalone Hosts

{% hint style="info" %}
Sending custom metrics directly from the SDK is currently only supported for Kubernetes
{% endhint %}

The recommended method to Dual Ship data from standalone hosts is by sending it do the groundcover sensor deployed on the host.

### Deploy the groundcover sensor

Follow these steps to deploy groundcover sensor on your host:

[Connect Linux hosts](/getting-started/installation-and-updating/connect-linux-hosts.md)

#### Configuring the DataDog Agent

Add the following to the service environment variables:

```bash
DD_TRACE_AGENT_URL="https://localhost:8126"
```


---

# 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/sending-directly-from-instrumented-services.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.