Datadog OTLP Intake Endpoint
このページは日本語には対応しておりません。随時翻訳に取り組んでいます。
翻訳に関してご質問やご意見ございましたら、
お気軽にご連絡ください。
Overview
For production workloads, Datadog recommends sending OpenTelemetry data through a Datadog Agent or OpenTelemetry Collector with the Datadog Exporter. These components provide metadata enrichment, signal normalization, and centralized sampling.
You can also send data from an OpenTelemetry Collector without Datadog-specific components. This experience is
in Preview.
Use the direct OTLP intake endpoints on this page when deploying a Collector or Agent is not feasible. Examples include serverless functions, managed platforms that export telemetry on your behalf, and environments with strict resource constraints.
Your setup depends on where your telemetry is coming from. Check the Managed platforms list first; if your platform has a dedicated endpoint, use it. Otherwise, use the serverless or signal-specific pages.
| If your telemetry comes from… | Start here |
|---|
| A managed platform (Cloudflare, Vercel, Heroku, Netlify, Modal, and others) | Managed platforms |
| A serverless environment sending traces (Lambda, ECS Fargate, Azure Functions, Cloud Run, GKE Autopilot) | Serverless |
| Your own app, host, or container | Logs, Metrics, or Traces |
See also: Instrumenting for Agent Observability.
Intake limits
Datadog enforces a maximum payload size per request on each OTLP intake endpoint. Requests that exceed the limit are rejected with an HTTP 413 Request Entity Too Large response. If you receive a 413, reduce the export batch size or flush more frequently so each request stays under the limit.
| Signal | Endpoint path | Maximum payload size |
|---|
| Metrics | /v1/metrics | 512 KiB (compressed) |
| Logs | /v1/logs | 5.1 MiB (uncompressed) |
| Traces | /v1/traces | 15 MiB (uncompressed) |
Further reading