Resource Monitoring tracks bandwidth, traffic, cache performance, and HTTP status codes for your accelerated domain names — broken down by the region or carrier of client IP addresses. Use it to identify traffic trends, diagnose origin errors, and optimize CDN configurations.
How it works
Resource Monitoring collects data based on the region or carrier of client IP addresses, not CDN points of presence (POPs). This means the data reflects where your end users are located, which differs from billing data (based on POP locations).
All six metrics support filtering by domain name, region, and carrier. Two of them also support filtering by protocol (HTTP, HTTPS, QUIC, IPv4, and IPv6).
Metrics
Metric | What it shows | Protocol filter |
Data Transfer/Bandwidth of Requests | Bandwidth and traffic for accelerated domain names | Supported (HTTP, HTTPS, QUIC, IPv4, IPv6) |
Back-to-origin Data Transfer/Bandwidth | Bandwidth and traffic consumed when CDN POPs fetch from the origin server due to cache misses | Not supported |
Number of Requests | Total requests and queries per second (QPS) for accelerated domain names | Supported (HTTP, HTTPS, QUIC, IPv4, IPv6) |
Hit Rate | Byte hit ratio and request hit ratio for accelerated domain names | Not supported |
HTTPCODE | HTTP status code distribution for edge responses (2xx, 3xx, 4xx, 5xx) | Not supported |
HTTP Status Codes to Back-to-origin Requests | HTTP status code distribution for origin-fetch responses (2xx, 3xx, 4xx, 5xx) | Not supported |
Metric definitions
Data Transfer/Bandwidth of Requests
Displays the bandwidth and traffic of accelerated domain names.
Related APIs: Query bandwidth by protocol | Query usage by day
Back-to-origin Data Transfer/Bandwidth
Back-to-origin bandwidth: Network bandwidth consumed when a CDN POP requests a resource from the origin server because the content is not cached locally.
Back-to-origin traffic: Data volume transferred from the origin server to CDN POPs for the same reason.
Related APIs: Query back-to-origin bandwidth | Query back-to-origin traffic
Number of Requests
Requests: Total number of requests within the selected time granularity period. For example, at 5-minute granularity, this is the total count for each 5-minute window.
QPS (queries per second): Average number of requests per second within the selected time window.
Related API: Query QPS by protocol
Hit Rate
Byte hit ratio: Percentage of bytes served directly from CDN cache, calculated as
(Total bytes served by CDN POPs to users - Total bytes served by origin server to CDN POPs) / Total bytes served by CDN POPs to users.Hit rate: Byte hit ratio across all requests (HTTP and HTTPS) within the selected period.
HTTPS hit rate: Byte hit ratio for HTTPS requests only.
Related APIs: Query byte hit ratio | Query request hit ratio
HTTPCODE (edge response)
Distributes requests by HTTP status code returned by the CDN edge node:
2xx Success: The CDN node processed the request and returned the resource or a confirmation.
4xx Client Error: The CDN node rejected the request because it was invalid (for example, insufficient permissions). Modify the client request and retry.
5xx Server Error: An internal error occurred on the CDN node (for example, the node was overloaded). Check your origin server configuration, such as its network settings.
For status code descriptions and solutions, see HTTP status codes.
Related API: Query HTTP status codes by protocol
HTTP Status Codes to Back-to-origin Requests (origin-fetch response)
Distributes origin-fetch requests by HTTP status code returned by the origin server:
4xx Client Error: The origin server rejected the request because it was invalid (for example, the resource does not exist). Modify the client request or adjust the accelerated domain name configuration, then retry.
5xx Server Error: An internal error occurred on the origin server (for example, the server was overloaded). Check your origin server configuration and load.
For status code descriptions and solutions, see HTTP status codes.
Related API: Query back-to-origin HTTP status codes
Data granularity and retention
The available time granularity, maximum query span, historical data retention, and data latency differ depending on whether you query from the console or via API.
Console
Granularity | Max time range per query | Historical data available | Data latency |
5 minutes | 3 days | 90 days | 15 minutes |
1 hour | 31 days | 90 days | 4 hours |
1 day | 90 days | 90 days | 4:00 AM the next day |
API
Granularity | Max time range per query | Historical data available | Data latency |
5 minutes | 3 days | 93 days | 15 minutes |
1 hour | 31 days | 186 days | 4 hours |
1 day | 366 days | 366 days | 4:00 AM the next day |
The API retains significantly more historical data than the console — up to 186 days for hourly data and 366 days for daily data, compared to 90 days for both in the console.
Usage notes
Monitoring data vs. billing data: Resource Monitoring is based on client IP regions and carriers. Billing is based on traffic and bandwidth at CDN POPs in each billing region. The two datasets use different statistical methods, so the numbers may not match. Use the charts in Resource Monitoring to track bandwidth trends, not to reconcile billing. To query metering data that corresponds to your bills, see Usage overview.
Monitoring data vs. log data: Traffic data from Resource Monitoring (and usage queries) is typically 1.1 times the traffic calculated from CDN logs. For details, see Why does traffic data differ between monitoring queries, usage queries, and log analysis?
Choosing between monitoring features
Alibaba Cloud CDN provides three data features. The table below shows when to use each one.
Feature | Data source | Filter dimensions | Time granularity | Best for |
Resource Monitoring | Client IP addresses | Region, carrier, protocol | 5 min / 1 hr / 1 day | Historical trend analysis; protocol-level breakdown |
Real-time Monitoring | Client IP addresses | Region, carrier | 1 minute | Near-real-time troubleshooting (data latency ~5 min) |
Usage | CDN POPs | Billing region (such as Chinese mainland, Asia Pacific 1, and North America) | Varies | Reconciling traffic with billing statements |
Differences between Resource Monitoring and Real-time Monitoring:
Latency: Real-time Monitoring data is available within ~5 minutes. Resource Monitoring data at 5-minute granularity is available within ~15 minutes.
Granularity: Real-time Monitoring supports 1-minute granularity. Resource Monitoring's finest granularity is 5 minutes.
Protocol breakdown: Resource Monitoring supports filtering by HTTP, HTTPS, QUIC, IPv4, and IPv6. Real-time Monitoring does not.
For more information, see Real-time Monitoring and Query resource usage.
Query resource monitoring data
Log on to the CDN console.
In the left navigation pane, choose Analytics > Resource Monitoring.
Select a metric, domain names, region, carrier, and time range, then click Search. The dashboard displays charts and data tables for the selected metric and conditions.
What's next
Real-time Monitoring — View near-real-time CDN metrics at 1-minute granularity.
Usage overview — Review metering data that aligns with your billing statements.
HTTP status codes — Troubleshoot 4xx and 5xx errors.