使用 Elastic Cloud 托管 OTLP 端点时出现 429 错误

通过 Elastic Cloud 托管 OTLP 端点 (mOTLP) 发送遥测数据时，您可能会遇到 HTTP 429 Too Many Requests 错误。这表明您的摄取速率暂时超过了为您的 Elastic Cloud 项目配置的速率或突发限制。

此问题可能发生在 Elastic Cloud Serverless 和 Elastic Cloud Hosted (ECH) 环境中。

症状

您可能会在 EDOT Collector 输出或 SDK 日志中注意到类似以下的日志消息

		{
  "code": 8,
  "message": "error exporting items, request to <ingest endpoint> responded with HTTP Status Code 429"
}
		
	

有时，您可能还会注意到 Collector 内部遥测中的警告或背压指标增加。例如，队列长度或发送失败计数。

原因

429 状态意味着发送到托管 OTLP 端点的请求速率已超过允许的阈值。这可能由多种原因导致

您的遥测管道发送数据的速度超过了允许的摄取速率。
即使您的持续速率在限制范围内，遥测数据的突发流量也超过了短期突发限制。

确切的限制因部署类型、订阅和当前配置而异。有关详细信息，请参阅 mOTLP 参考文档中的速率限制 (Rate limiting) 部分。
在 Elastic Cloud Hosted 中，您的部署的 Elasticsearch 容量可能无法满足当前的摄取速率（即容量不足）。
在 Elastic Cloud Serverless 中，速率限制不应由 Elasticsearch 容量引起，因为平台会自动扩展摄取容量。如果您怀疑存在扩展问题，请联系 Elastic 支持。
多个 Collector 或 SDK 在没有负载均衡或退避机制的情况下同时发送数据。

解决方法

要解决 429 错误，请确定瓶颈是由摄取限制还是 Elasticsearch 容量引起的。

扩展您的部署或请求更高的限制

如果您已确认摄取配置稳定但仍然遇到 429 错误

Elastic Cloud Serverless：联系 Elastic 支持以请求提高摄取限制。
Elastic Cloud Hosted (ECH)：通过扩展或调整部署大小来增加您的 Elasticsearch 容量

扩展后，监控您的摄取指标以验证已接受请求的速率是否增加，并且不再出现 429 响应。

降低摄取速率或启用背压

通过在 EDOT Collector 或 SDK 配置中启用批处理和重试机制来降低遥测导出速率。例如

		processors:
  batch:
    send_batch_size: 1000
    timeout: 5s

exporters:
  otlp:
    retry_on_failure:
      enabled: true
      initial_interval: 1s
      max_interval: 30s
      max_elapsed_time: 300s
		
	

这些设置有助于平滑流量峰值，并在收到速率限制响应后自动重试失败的导出。

启用重试逻辑和队列

为了最大限度地减少临时限流期间的数据丢失，请配置您的导出器以使用发送队列和重试逻辑。例如

		exporters:
  otlp:
    sending_queue:
      enabled: true
      num_consumers: 10
      queue_size: 1000
    retry_on_failure:
      enabled: true
		
	

这确保了 Collector 在等待摄取端点从限流中恢复时能在本地缓冲数据。有关导出失败和队列配置的更多信息，请参阅发送遥测数据时的导出失败 (Export failures when sending telemetry data)。

最佳实践

为防止 429 错误并保持可靠的遥测数据流，请实施以下最佳实践

监控内部 Collector 指标（例如 otelcol_exporter_send_failed 和 otelcol_exporter_queue_capacity），以便及早发现背压。
将遥测负载均匀分布在多个 Collector 上，而不是通过单个实例发送所有数据。
在可能的情况下，启用批处理和压缩以减小有效载荷大小。
保持重试和退避间隔保守，以避免在临时限流后使端点过载。