Document OTLP intake limits and clarify host metadata defaults (#37936)

* Document OTLP intake limits and clarify host metadata defaults

* Reconcile per-signal payload limits with OTLP endpoints summary

* Address review: link to per-endpoint limits, reconcile host metadata opt-in

Author: brett0000FF

content/en/opentelemetry/mapping/host_metadata.md

@@ -15,15 +15,19 @@ This feature is in Preview. If you have any feedback, contact <a href="/help/">D
 
 ## Overview
 
-The Datadog exporter supports sending system information about your hosts to Datadog, which you can see in the [Infrastructure List][6]. You can send this information in OTLP through the ['Resource' field][1] as part of any of the existing signals. This is supported under any [deployment pattern][9] including gateway deploys.
+The Datadog Exporter collects host metadata and sends it to Datadog by default, where you can see it in the [Infrastructure List][6]. For most deployments, such as running the Collector as an agent on each host, host information is populated automatically and you do not need to follow the configuration on this page.
 
-<div class="alert alert-danger">Only metadata sent through the Datadog Exporter will populate the Infrastructure Host List. Metadata sent using the direct OTLP ingest endpoint does not support this feature.</div>
+<div class="alert alert-info">The manual configuration described on this page is primarily for <a href="https://opentelemetry.io/docs/collector/deployment/gateway/">gateway deployments</a>, where the Collector that exports to Datadog runs separately from the hosts it reports on. In these setups, explicitly tag your resources so that the correct host metadata reaches Datadog. If you run the Collector as an agent on each host, host metadata is collected by default and you can skip this configuration.</div>
+
+The Datadog Exporter supports sending system information about your hosts to Datadog. You can send this information in OTLP through the ['Resource' field][1] as part of any of the existing signals. This is supported under any [deployment pattern][9] including gateway deploys.
+
+<div class="alert alert-danger">Only metadata sent through the Datadog Exporter populates the Infrastructure Host List. Metadata sent using the direct OTLP ingest endpoint does not support this feature.</div>
 
 Datadog uses [OpenTelemetry semantic conventions][2] to recognize system information about your hosts. Follow the instructions for [setting up for host metrics][3] to send the necessary metrics and resource attributes to Datadog. Alternatively, you can manually send this information in the way that best fits your infrastructure.
 
 ## Opting in to the feature
 
-To use this feature, set the `datadog.host.use_as_metadata` resource attribute to `true` in all OTLP payloads that contain information about hosts.
+For gateway deployments, or to manually control which resources are used for host metadata, set the `datadog.host.use_as_metadata` resource attribute to `true` in all OTLP payloads that contain information about hosts.
 
 Resources populate the infrastructure list information if they have a [host-identifying attribute][10] and the `datadog.host.use_as_metadata` attribute set to `true`.
 

content/en/opentelemetry/setup/collector_exporter/oss_setup.md

@@ -161,7 +161,6 @@ exporters:
   # Send telemetry to Datadog's OTLP intake endpoints
   otlp_http:
     endpoint: https://otlp.${env:DD_SITE}
-    metrics_endpoint: https://otlp.${env:DD_SITE}/api/v2/otlpmetrics
     headers:
       dd-api-key: ${env:DD_API_KEY}
       # Send resource attributes and scope metadata as metric tags
@@ -347,7 +346,6 @@ exporters:
   # Send telemetry to Datadog's OTLP intake endpoints
   otlp_http:
     endpoint: https://otlp.${env:DD_SITE}
-    metrics_endpoint: https://otlp.${env:DD_SITE}/api/v2/otlpmetrics
     headers:
       dd-api-key: ${env:DD_API_KEY}
       # Send resource attributes and scope metadata as metric tags
@@ -575,7 +573,6 @@ exporters:
   # Send telemetry to Datadog's OTLP intake endpoints
   otlp_http:
     endpoint: https://otlp.${env:DD_SITE}
-    metrics_endpoint: https://otlp.${env:DD_SITE}/api/v2/otlpmetrics
     headers:
       dd-api-key: ${env:DD_API_KEY}
       # Send resource attributes and scope metadata as metric tags
@@ -758,7 +755,7 @@ For a complete list of dimensions included in the recommended configuration, inc
 
 The `otlp_http` exporter sends telemetry data to Datadog's OTLP intake endpoints. Key configuration details:
 
-- **Endpoint**: `https://otlp.<YOUR_DD_SITE>` for traces and logs, `https://otlp.<YOUR_DD_SITE>/api/v2/otlpmetrics` for metrics.
+- **Endpoint**: `https://otlp.<YOUR_DD_SITE>` for traces, logs, and metrics.
 - **Compression**: `zstd` is recommended for reduced bandwidth usage. When using `zstd`, set `compression_params.level` explicitly, because the default uses the lowest compression level.
 
 #### `dd-otel-metric-config` header {#dd-otel-metric-config-header}
@@ -801,6 +798,16 @@ The `cumulativetodelta` processor converts cumulative metrics to delta temporali
 
 The configuration sends the Collector's own metrics back to its local OTLP receiver (`http://localhost:4318`). This routes the Collector's internal metrics through its own pipelines so they are enriched with resource attributes before being exported to Datadog.
 
+## OTLP intake limits
+
+Datadog enforces the following limits when ingesting OTLP data. Data that exceeds a limit is rejected or dropped as noted.
+
+**Payload size**
+: Each intake endpoint enforces a maximum payload size per request. Requests above the limit are rejected with an `HTTP 413 Request Entity Too Large` response. If you receive a 413, reduce the batch size or flush more frequently so each request stays under the limit. For the payload size limit of each endpoint, see [Intake limits][8].
+
+**Histogram bucket count**
+: Each histogram datapoint is validated on ingestion, with a maximum per-bucket count (the number of observations in any single bucket) of 2,147,483,647 (2<sup>31</sup> − 1). If any bucket exceeds this, the entire datapoint is dropped.
+
 ## Further reading
 
 {{< partial name="whats-next/whats-next.html" >}}
@@ -812,4 +819,5 @@ The configuration sends the Collector's own metrics back to its local OTLP recei
 [5]: https://github.com/DataDog/opentelemetry-examples/tree/experimental-oss-config/configurations/opentelemetry-collector
 [6]: /opentelemetry/guide/otlp_delta_temporality/
 [7]: /opentelemetry/compatibility/
+[8]: /opentelemetry/setup/otlp_ingest/#intake-limits
 [100]: https://github.com/open-telemetry/opentelemetry-collector-releases/releases/latest

content/en/opentelemetry/setup/otlp_ingest/_index.md

@@ -31,6 +31,16 @@ Your setup depends on where your telemetry is coming from. Check the [Managed pl
 
 See also: [Instrumenting for Agent Observability][5].
 
+## 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
 
 {{< partial name="whats-next/whats-next.html" >}}

content/en/opentelemetry/setup/otlp_ingest/metrics.md

@@ -255,7 +255,7 @@ If you receive a `403 Forbidden` error when sending metrics to the Datadog OTLP
 
 ### Error: 413 Request Entity Too Large
 
-If you receive a `413 Request Entity Too Large` error when sending metrics to the Datadog OTLP metrics intake endpoint, it indicates that the payload size sent by the OTLP exporter exceeds the Datadog metrics intake endpoint's limit of 500KB for uncompressed payloads, or 5MB for compressed payloads after decompression.
+If you receive a `413 Request Entity Too Large` error when sending metrics to the Datadog OTLP metrics intake endpoint, it indicates that the payload size sent by the OTLP exporter exceeds the Datadog metrics intake endpoint's limit of 512 KiB (compressed).
 
 This error usually occurs when the OpenTelemetry SDK batches too much telemetry data in a single request payload.
 

content/en/opentelemetry/setup/otlp_ingest/traces.md

@@ -187,7 +187,7 @@ If you receive a `403 Forbidden` error when sending traces to the Datadog OTLP t
 
 ### Error: 413 Request Entity Too Large
 
-If you receive a `413 Request Entity Too Large` error when sending traces to the Datadog OTLP traces intake endpoint, it indicates that the payload size sent by the OTLP exporter exceeds the Datadog traces intake endpoint's limit of 3.2MB.
+If you receive a `413 Request Entity Too Large` error when sending traces to the Datadog OTLP traces intake endpoint, it indicates that the payload size sent by the OTLP exporter exceeds the Datadog traces intake endpoint's limit of 15 MiB (uncompressed).
 
 This error usually occurs when the OpenTelemetry SDK batches too much telemetry data in a single request payload.
 
@@ -200,7 +200,7 @@ CopyBatchSpanProcessor batchSpanProcessor =
         .setMaxExportBatchSize(10)  // Default is 512
         .build();
 ```
-Adjust the `setMaxExportBatchSize` value according to your needs. A smaller value results in more frequent exports with smaller payloads, reducing the likelihood of exceeding the 3.2MB limit.
+Adjust the `setMaxExportBatchSize` value according to your needs. A smaller value results in more frequent exports with smaller payloads, reducing the likelihood of exceeding the 15 MiB limit.
 
 ### Warning: "traces export: failed … 202 Accepted" in Go