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