Skip to main content

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 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.
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.
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 that re-encodes to Datadog.

​
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: 
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.
1

Open the OpenTelemetry collector panel

In MCP Manager, go to Logs → Integrations and find the OpenTelemetry collector panel.
2

Enter the collector URL

In Collector URL, paste your site’s OTLP logs endpoint, for example https://otlp.datadoghq.com/v1/logs for US1.
3

Add the dd-api-key request header

Under Request headers, add one header:
  • Field name: dd-api-key
  • Field value: your Datadog API key
4

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 4: Verify logs are flowing

Trigger an MCP call through a gateway (a tools/list call is enough), then check 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

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.
The URL path is wrong. MCP Manager appends nothing, so the URL must end in /v1/logs on your site’s OTLP host.
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 and let the collector export to Datadog, or confirm JSON support with Datadog.
From any machine with outbound HTTPS access:
terminal
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.

​
Further reading

Honeycomb

The next per-vendor guide — US/EU endpoints and the x-honeycomb-team key.

Export to SIEM

What MCP Manager sends, how forwarding behaves, and general troubleshooting.

Self-hosted Collector

Re-encode JSON to protobuf and forward to Datadog from your own collector.

​
External sources

Datadog OTLP intake overview

The agentless intake and the per-site host selector for your exact endpoint.

Datadog OTLP logs intake

The /v1/logs path, the dd-api-key header, and the protobuf-exporter examples.

Datadog API and Application keys

Where keys live and the API-key-vs-Application-key distinction.

OTLP specification

The protocol spec, including the success and partial-success response contract.