The Akamai Distribution of the OpenTelemetry Collector for Akamai Cloud Pulse (the collector) is subject to API constraints that affect metrics collection behavior, request throughput, and collector configuration. Understanding these limits can help you avoid HTTP 429 (Too Many Requests) responses and optimize metrics collection.

Metrics-related API requests are limited to 100 requests per minute, per service, per user. The following sections describe how various factors affect API rate limit consumption.

PATs and API rate limits

Rate limits are enforced at the user account level, not the personal access token (PAT) level. Creating multiple PATs for the same user account does not increase the available request capacity or bypass rate limits.

For deployments requiring higher throughput, such as large scale or multi-region metrics collection, consider distributing metric collection across multiple PATs belonging to different users within the same account.

Use a PAT with the explicit read scope required for the service being monitored. For example, Object Storage metrics require an object_storage:read scope. Avoid combining PATs meant for different service types in an unsupported way.

Entity limits and request batching

Metrics requests are subject to service-specific entity limits. Each service supports a maximum number of entities per request.

Additionally,

• Cross-region queries are not supported within a single API request.
• Each API request can include a maximum of 5 metrics.

When a request exceeds the supported entity limit, the collector automatically splits the request into multiple backend API calls. Each backend API call counts towards the metrics-related API request rate limit of 100 requests per minute.

Rate limit consumption

Because the collector batches entities automatically, a single polling cycle can generate multiple backend API calls. Each backend API call counts toward the API rate limit of 100 requests per minute.

For example, if a request includes 306 Managed Database entities in a single region, and the Managed Databases limit is 100 entities per request, the collector automatically splits the request into four backend API calls for that polling cycle.

306 ÷ 100 = 3.06

A partial result requires an additional API call, so the number of calls rounds up to four requests, total.
As the number of monitored entities increases, a single polling cycle may generate additional backend API calls, which can increase API rate limit consumption. Understanding how requests are split and counted is important when configuring polling intervals and thread pool sizes to avoid HTTP 429 errors.