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

# Datadog

> How to forward MCP Manager logs to Datadog over OpenTelemetry: the per-site OTLP logs endpoint, the dd-api-key header, and the JSON-vs-protobuf caveat to verify before relying on it.

Datadog offers an agentless OTLP intake, so MCP Manager can send logs directly to Datadog's per-site OTLP/HTTP endpoint over HTTPS without running the Datadog Agent or an OpenTelemetry Collector.

This guide covers the Datadog-specific details. For what MCP Manager sends, how forwarding behaves, who can configure it, and general troubleshooting, see [Export to SIEM](/enterprise/export-to-siem).

<Info>
  Configuring log forwarding requires the **Manage OpenTelemetry collector** capability and an Enterprise plan that includes the OpenTelemetry integration. If you do not see the **Logging → Integrations** panel, see [Who can set up log export](/enterprise/export-to-siem#who-can-set-up-log-export).
</Info>

<Warning>
  MCP Manager sends OTLP/HTTP log records **JSON-encoded**. Datadog's OTLP **logs** intake documentation and examples use the OTLP HTTP **Protobuf** exporter, and JSON acceptance for the logs endpoint is not guaranteed. **Test delivery before relying on it** (Step 4). If records are rejected with a `400`, your backend likely requires protobuf — in that case, route MCP Manager through a [self-hosted OpenTelemetry Collector](/enterprise/export-to-siem/self-hosted-collector) that re-encodes to Datadog.
</Warning>

## What you'll need

* A **Datadog account**, and the **site** your organization is on (US1, US3, US5, EU, AP1, AP2, and so on).
* A Datadog **API key** (an ingest key), **not** an Application key.
* Access to MCP Manager with the **Manage OpenTelemetry collector** capability.

## Step 1: Determine your collector URL

Datadog's OTLP intake host is **per-site**, and the logs path is `/v1/logs` on port `443`. For the US1 site the endpoint is:

```text theme={null}
https://otlp.datadoghq.com/v1/logs
```

Datadog renders the correct host for your site (US1, US3, US5, EU, AP1, AP2, and the FedRAMP sites) dynamically in its documentation. Use the site selector on Datadog's OTLP intake docs to get your exact host rather than guessing — a host that belongs to the wrong site returns `403 Forbidden`. Append `/v1/logs` to that host; MCP Manager appends nothing itself.

## Step 2: Create an API key

In Datadog, go to **Organization Settings → API Keys** and create or copy an **API key**. This is an ingest key, distinct from an **Application key** (which is used for the Datadog API and will not work for OTLP ingestion).

## Step 3: Connect MCP Manager to Datadog

Datadog authenticates with a custom **`dd-api-key`** header rather than the standard `Authorization` header. Because MCP Manager's **Request headers** field is an open key/value list, you add `dd-api-key` directly.

<Steps>
  <Step title="Open the OpenTelemetry collector panel">
    In MCP Manager, go to [Logs → Integrations](https://app.mcpmanager.ai/settings/logging/integrations) and find the **OpenTelemetry collector** panel.
  </Step>

  <Step title="Enter the collector URL">
    In **Logs collector URL**, paste your site's OTLP logs endpoint, for example `https://otlp.datadoghq.com/v1/logs` for US1. (To also export traces, set **Traces collector URL** to the matching `/v1/traces` endpoint; this guide covers logs.)
  </Step>

  <Step title="Add the dd-api-key request header">
    Under **Request headers**, add one header:

    * **Field name:** `dd-api-key`
    * **Field value:** your Datadog API key
  </Step>

  <Step title="Save the configuration">
    Select **Save**. MCP Manager stores the configuration and encrypts the header value. Saving confirms storage only — it does not confirm delivery.
  </Step>
</Steps>

## Step 4: Verify logs are flowing

Trigger an MCP call through a gateway (a `tools/list` call is enough), then check [Alerts](https://app.mcpmanager.ai/settings/alerts) in MCP Manager for a **"Failed to export telemetry logs to OTEL collector"** alert. For Datadog:

* **`403 Forbidden`** — the endpoint host is wrong for your organization's site, or the API key is invalid.
* **`404 Not Found`** — the URL path is wrong (missing `/v1/logs`).
* **`400 Bad Request`** — the payload was rejected, which can mean the logs intake did not accept the JSON encoding (see the caveat above).

When logs arrive, find them in Datadog's **Logs Explorer**. The OTLP `service.name` resource attribute maps to Datadog's `service` facet, so filter on the `service.name` shown in MCP Manager's **Filter your logs by** panel.

## Troubleshooting

<AccordionGroup>
  <Accordion title="Export is failing with 403">
    A `403` on the Datadog intake means the endpoint URL is wrong for your organization's site, or the key is bad. Confirm your site with the Datadog site selector and use that exact host, and confirm you used an **API key** (not an Application key) that belongs to the right account.
  </Accordion>

  <Accordion title="Export is failing with 404">
    The URL path is wrong. MCP Manager appends nothing, so the URL must end in `/v1/logs` on your site's OTLP host.
  </Accordion>

  <Accordion title="Export is failing with 400 (payload rejected)">
    Datadog's OTLP logs intake documents the HTTP/Protobuf exporter, and MCP Manager sends OTLP/HTTP **JSON**. A `400` rejecting the payload can mean the logs intake did not accept JSON. Route MCP Manager through a [self-hosted OpenTelemetry Collector](/enterprise/export-to-siem/self-hosted-collector) and let the collector export to Datadog, or confirm JSON support with Datadog.
  </Accordion>

  <Accordion title="Test the connection manually">
    From any machine with outbound HTTPS access:

    ```bash terminal theme={null}
    curl -v -X POST "https://otlp.datadoghq.com/v1/logs" \
      -H "dd-api-key: <your-api-key>" \
      -H "Content-Type: application/json" \
      -d '{}'
    ```

    A `2xx` or a `400` rejecting only the empty body means the site host and key are valid; `403` means the site host is wrong or the key is bad; `404` means the path is wrong.
  </Accordion>
</AccordionGroup>

## Further reading

<CardGroup cols={2}>
  <Card title="Honeycomb" icon="table-cells-large" href="/enterprise/export-to-siem/honeycomb">
    The next per-vendor guide — US/EU endpoints and the x-honeycomb-team key.
  </Card>

  <Card title="Export to SIEM" icon="tower-broadcast" href="/enterprise/export-to-siem">
    What MCP Manager sends, how forwarding behaves, and general troubleshooting.
  </Card>

  <Card title="Self-hosted Collector" icon="server" href="/enterprise/export-to-siem/self-hosted-collector">
    Re-encode JSON to protobuf and forward to Datadog from your own collector.
  </Card>
</CardGroup>

## External sources

<CardGroup cols={2}>
  <Card title="Datadog OTLP intake overview" icon="arrow-up-right-from-square" href="https://docs.datadoghq.com/opentelemetry/setup/otlp_ingest/">
    The agentless intake and the per-site host selector for your exact endpoint.
  </Card>

  <Card title="Datadog OTLP logs intake" icon="arrow-up-right-from-square" href="https://docs.datadoghq.com/opentelemetry/setup/otlp_ingest/logs/">
    The `/v1/logs` path, the `dd-api-key` header, and the protobuf-exporter examples.
  </Card>

  <Card title="Datadog API and Application keys" icon="arrow-up-right-from-square" href="https://docs.datadoghq.com/account_management/api-app-keys/">
    Where keys live and the API-key-vs-Application-key distinction.
  </Card>

  <Card title="OTLP specification" icon="arrow-up-right-from-square" href="https://opentelemetry.io/docs/specs/otlp/">
    The protocol spec, including the success and partial-success response contract.
  </Card>
</CardGroup>