FAQs

This guide answers commonly asked questions about using the Akamai Distribution of the OpenTelemetry Collector for Akamai Cloud Pulse (the collector), including metrics collection, data availability, and expected behavior.

Why am I seeing a message indicating that no metric data was found / no data points were available?

This is expected behavior and means that no data points are available for the requested metric for the query time range. This doesn’t necessarily indicate a collection failure or configuration problem. For more information, see Understanding missing metrics.

Why do Object Storage metrics disappear?

Object Storage metrics are activity-driven. Metrics are only recorded when activity occurs during a polling interval, such as a GET, PUT, DELETE, or LIST operation.

If no operations occur on the bucket during a polling interval, no metrics are recorded for that interval. As a result, gaps in Object Storage metrics are normal and expected. They don’t indicate a collector failure or configuration problem.

Metrics reappear once activity occurs on a bucket and the next polling cycle completes.

If you’re seeing persistent gaps, verify that bucket operations are occurring and the collector is running continuously during the period you want to observe.

Why am I receiving HTTP 429 errors?

An HTTP 429 error means that the rate limit for metrics API operations has been exceeded.

Common causes include:

• Request volume. Each metric query generates an API request. If you’re collecting many metrics across multiple services with a short polling interval (polling_interval), the total number of requests can increase quickly and exceed the per-minute rate limit. For example, a single Object Storage service block containing 300 entity IDs requires 12 backend calls because Object Storage supports a maximum of 25 entity IDs per API call. With 10 such service blocks and a one-minute polling interval, the collector generates 120 requests per minute, which exceeds a typical rate limit of 100 requests per minute.
• Inefficient request batching. If the collector sends individual API requests for each metric in each service instead of batching requests, request volume can increase significantly. Instead of polling data for individual entities, you may want to poll them in bulk to reduce total request count.
• Concurrent requests. A collector that uses concurrent worker pools to fetch metrics in parallel can inadvertently generate bursts of requests within a short period of time. This can trigger rate limits even when the average request rate remains within the allowed limit. Reducing thread pool concurrency using thread_pool_size can help smooth request volume.
• Personal access token (PAT) limits. Metrics-related API operations are limited to 100 requests per minute, per service, per user. All requests made using PATs that belong to the same user share the same rate limit bucket. If you’ve received HTTP 429 errors, check how many requests are being made per minute and whether they’re all attributed to the same user. Consider using PATs associated with different users under the same Akamai Cloud account to distribute requests across multiple rate limit buckets.

For additional guidance, see API rate limits and request batching.

Can I avoid HTTP 429 errors by using multiple personal access tokens (PATs) belonging to the same user?

No, creating multiple personal access tokens (PATs) for the same user won’t help avoid HTTP 429 errors.

Metrics-related API operations are limited to 100 requests per minute, per service, per user. This limit is applied at the user level, not the token level. All PATs belonging to the same user share a single rate limit bucket, regardless of how many tokens exist. Using multiple PATs from the same user still counts towards the same rate limit.

If you’re hitting rate limits and need additional throughput, consider using PATs associated with different users under the same Akamai Cloud account. Each user has a separate rate limit bucket, so distributing requests across multiple users can increase the aggregate request rate without triggering HTTP 429 errors.

Why doesn’t increasing polling frequency increase data freshness?

The polling interval (polling_interval) controls how often the collector queries the API. It doesn’t control how often the backend collects data from the underlying service.

The backend collects metric data according to its own scrape cadence for each metric type. New metric data becomes available according to the backend scrape cadence, not the collector polling interval.

Increasing the polling frequency beyond the backend scrape cadence won’t produce fresher data. Instead, the collector will receive the same data point multiple times or receive empty responses between backend collection cycles.

Increasing the polling frequency also increases request volume and can raise the risk of hitting API rate limits.

To avoid unnecessary requests, set polling_interval to match or be a reasonable multiple of the backend scrape cadence for the metrics you‘re collecting. Refer to the metric’s scrape_intervalin the API response.

For more information, see API rate limits and request batching.

Why are some metrics hourly while others are minute-level?

Different metrics have different backend scrape cadences depending on the nature of the data and the cost of collecting it. This is determined by the backend, not the collector configuration. For example, compute and network metrics, such as CPU usage, memory utilization, and bytes transferred, are typically scraped at minute-level granularity because they change frequently and benefit from fine-grained visibility.

Storage and billing-related metrics, such as total bytes stored, snapshot counts, or capacity utilization, are often scraped hourly because they change more slowly. Aggregating them more frequently adds cost without meaningful additional insight.

If you query a metric at a finer granularity than its backend scrape cadence, the response will contain only one data point per scrape cycle. For example, querying an hourly metric at one-minute resolution will return data only once per hour.

This is expected.

Before configuring polling_interval and query_delay, check the API documentation for the scrape_interval of each metric you’re collecting.

Why do my metrics appear delayed?

Two factors contribute to metrics delays: ingestion latency and query delay.

• Ingestion latency. After the backend collects metric data, the data must move through the ingestion pipeline before it becomes available to query. This process introduces a small delay, typically a few seconds to a couple of minutes, depending on the metric type and backend load. Data queried immediately after a backend scrape cycle may not yet be available.

• Query delay. Query delay (query_delay) is a configuration parameter that tells the collector to shift its query window backward in time by a fixed offset. It’s designed to account for ingestion latency by querying data only after the backend has had time to process it. For example, if query_delay is set to two minutes, a query that runs at 12:10 will fetch data for the window ending at 12:08. This helps ensure that the data is available before the collector queries it.

  If your metrics appear more delayed than expected, check whether query_delay is set higher than necessary. Reducing query_delaycan bring data closer to real time, but keep in mind that setting it too low may result in missing or incomplete data.