Akamai Cloud Pulse is a next-generation monitoring solution that provides updated metrics and alerting capabilities for Linodes. To differentiate between the two options in this guide, the existing features are referred to as legacy monitoring. During the transition period, both solutions remain available, and you can switch between them when viewing and querying metrics.

This guide describes the benefits of the new monitoring experience, provides a detailed comparison between the two solutions, and outlines the actions you may need to take to prepare for the transition.

Benefits of Akamai Cloud Pulse metrics and alerts

Akamai Cloud Pulse provides expanded monitoring capabilities that offer several advantages over legacy monitoring. These benefits are described below.

Overall

• Supports metrics and alerts across multiple Akamai cloud services, such as Managed Databases, Object Storage, Block Storage, LKE Enterprise (metrics only) and Log delivery.
• Provides both contextual and centralized monitoring of Linodes. You can continue to view metrics and manage alerts in the context of an individual Linode, or you can use the new centralized dashboard to monitor metrics and manage alerts across multiple Linodes.

Metrics

• Uses a modernized architecture based on OpenTelemetry and the VictoriaMetrics time-series database (TSDB), which replaces the file-based round-robin database (RRD) architecture used by legacy monitoring.
• Allows you to query metrics using structured JSON payloads with aggregate functions and filters, which provides more control over how you query and aggregate metric data.
• Normalizes CPU usage across all vCPUs to a 0-100% range. Normalizing usage makes it easier to interpret and compare values across Linodes with different numbers of vCPUs.

Alerts

• Provides more granular control over your alerts. You can configure alerts at the account, region, or entity level and use custom dimensions, grouping, and priority definitions (high, medium, low) to tailor alert behavior to your monitoring requirements.
• Detects alert conditions more quickly. Akamai Cloud Pulse typically detects a threshold breach within five minutes after the evaluation criteria are met, compared with 30–60 minutes for legacy alerts.
• Provides additional notification options. You can customize who receives alerts to help reduce "alert fatigue." Akamai Cloud Pulse alerts support webhooks and expanded user roles, which help you to direct notifications to the most appropriate recipients.

Detailed comparison

See tables in the dedicated Metrics and Alerts tabs that summarize the key differences between legacy and Akamai Cloud Pulse monitoring. These differences include how metrics are calculated, represented, and queried, and how alerts are configured and evaluated.

📘

Legacy vs. Akamai Cloud Pulse values differences

During the transition period, while both the legacy monitoring solution and Akamai Cloud Pulse are active, you may observe slight differences in values that each system displays. This is typically limited to the first reporting period after a Linode starts. Once a second reporting period (5 minutes) passes, values between the two solutions will align.

This temporary difference is due to Akamai Cloud Pulse’s lower latency and faster data aggregation, which provides closer to real-time experiance than the legacy solution.

Prepare to transition to Akamai Cloud Pulse

Depending on how you use legacy monitoring, you may need to make some updates before transitioning to Akamai Cloud Pulse. These may include updating existing API workflows and automated monitoring scripts or adjusting your alerts thresholds.

Update your API workflows and scripts

If you use the legacy monitoring API to query metrics and configure alerts, update your API workflows and monitoring scripts before moving them to Akamai Cloud Pulse.

Key differences

Account for the following breaking changes when updating your integrations for the Akamai Cloud Pulse:

• Request Method and Body: The legacy API uses a simple GET request that returns all available metrics at once. Akamai Cloud Pulse uses a POST request where you explicitly define which metrics you want, with a JSON body defining the aggregate_function (for example, min, max, avg).
• Timestamps: Akamai Cloud Pulse returns timestamps in seconds, for example, 1771832400. Legacy monitoring returns the exact same timestamps in milliseconds, for example, 1771832400000.
• CPU and Network Units: The Legacy CPU usage calculation is unnormalized (often >100%), and network traffic is reported in bits per second (b/s). Akamai Cloud Pulse normalizes the CPU usage (0–100%) and uses kilobits per second (kbps).

Workflow examples

To map your legacy API workflows to Akamai Cloud Pulse API workflows and explore new formats, see the dedicated guides for metrics and alerts:

• Linodes and metrics workflows
• Linodes and alerts workflows

Update your alert thresholds

Akamai Cloud Pulse normalizes CPU usage across all vCPUs to a 0-100% range, while legacy monitoring sums CPU usage across individual vCPUs. If you configured CPU alerts in legacy monitoring, review and update the thresholds when configuring the corresponding Akamai Cloud Pulse alerts.
In particular, thresholds greater than 100% in legacy monitoring can’t be used in the new alerts because CPU usage is now normalized to a maximum of 100%.

Example: If you configured a legacy monitoring alert based on 50% CPU usage across four vCPUs, the equivalent CPU usage in Akamai Cloud Pulse is 50%:

• Legacy monitoring: 4 vCPUs x 50% CPU usage = 200% CPU usage. The alert threshold is 200%
• Akamai Cloud Pulse: (4 vCPUs x 50% CPU usage) ÷ 4 vCPUs = 50% CPU usage. Configure the corresponding alert threshold at 50%.

Alerts with thresholds greater than 100% will not trigger in Akamai Cloud Pulse.