Real-time monitoring gives you 1-minute granularity data on CDN traffic, bandwidth, and origin fetch status — with a data latency as low as 5 minutes. Use it to detect traffic spikes, track cache efficiency, and identify HTTP errors as they happen.
How it works
All real-time monitoring data is collected based on client IP addresses. Each IP address maps to a specific region or carrier, so you can filter monitoring data by region, carrier, or both.
Because billing is calculated based on traffic and bandwidth measured at CDN points of presence (POPs) — not client IPs — monitoring figures and billing figures use different statistical methods and may not match. For metering data that corresponds to your bills, see Usage overview.
Metrics
Real-time monitoring tracks three groups of metrics. For each group, select a domain name, region, carrier, and time range to view the data.
Requests
Bandwidth, traffic, request count, and queries per second (QPS) for your accelerated domain names.
| Metric | Description |
|---|---|
| Bandwidth | The bandwidth consumed by client requests at the specified time |
| Traffic | The cumulative data volume transferred to clients |
| Requests | The total number of requests received by CDN POPs |
| QPS | The number of requests processed per second |
Related API operations:
Back-to-origin routing
Back-to-origin bandwidth and back-to-origin traffic for your accelerated domain names. These metrics show how much data CDN fetches from your origin server — a sustained increase may indicate a drop in cache hit ratio.
| Metric | Description |
|---|---|
| Back-to-origin bandwidth | The bandwidth consumed when CDN POPs fetch content from your origin server |
| Back-to-origin traffic | The cumulative data volume fetched from your origin server by CDN POPs |
Related API operations:
Cache hit ratio and HTTP status codes
Request hit ratio, byte hit ratio, and the breakdown of 2xx, 3xx, 4xx, and 5xx HTTP status codes for your accelerated domain names.
| Metric | Description |
|---|---|
| Request hit ratio | The percentage of requests served from the CDN cache without fetching from origin |
| Byte hit ratio | The percentage of response bytes served from the CDN cache |
| HTTP status codes | The count of responses in each status code range (2xx, 3xx, 4xx, 5xx) |
Edge response status codes:
2xx Success: The POP successfully processed the client request and returned the resource or a confirmation.
4xx Client error: The POP could not process the request because the request is invalid — for example, insufficient permissions. Modify the client request and try again.
5xx Server error: An internal error occurred on the POP while processing the request — for example, the POP may be overloaded. Check your origin server configuration, such as its network settings.
For a full list of status codes and recommended actions, see HTTP status codes.
Related API operations:
Query limits
The maximum time range per query, data latency, and historical data availability vary by time granularity and whether you query via the console or API.
Console
| Time granularity | Maximum time range per query | Historical data available | Data latency |
|---|---|---|---|
| 1 minute | 1 hour | 7 days | 5 minutes |
| 5 minutes | 3 days | 7 days | 15 minutes |
API
| Time granularity | Maximum time range per query | Historical data available | Data latency |
|---|---|---|---|
| 1 minute | 1 hour | 7 days | 5 minutes |
| 5 minutes | 3 days | 93 days | 15 minutes |
| 1 hour | 31 days | 186 days | 4 hours |
Monitoring traffic vs. log-calculated traffic
Traffic data queried through monitoring or usage features in the console (or via API) is typically 1.1 times the traffic data calculated from CDN logs. This difference is expected — monitoring and usage queries account for protocol overhead that raw log data does not capture. For more information, see Why is there a discrepancy between traffic data from monitoring queries, usage queries, and log analysis?
Choose the right monitoring feature
Alibaba Cloud CDN provides three ways to query monitoring and usage data. The right choice depends on the time granularity you need and how you want to filter results.
| Feature | Data collection basis | Filter dimensions | Minimum granularity | Minimum data latency |
|---|---|---|---|---|
| Real-time Monitoring | Client IP address | Region, carrier | 1 minute | ~5 minutes |
| Resource Monitoring | Client IP address | Region, carrier, protocol layer (HTTP, HTTPS, QUIC, IPv4, IPv6) | 5 minutes | ~15 minutes |
| Usage | CDN POPs | Billing region (e.g., Chinese mainland, Asia Pacific 1, North America) | — | — |
Use Real-time Monitoring when you need the fastest view of current traffic behavior — for example, to catch a traffic spike or confirm that a configuration change is taking effect.
Use Resource Monitoring when you need to analyze traffic by protocol layer, or query historical data beyond 7 days. For more information, see Resource Monitoring.
Use Usage when you need data that maps directly to your bill — queried by billing region. For more information, see Query resource usage.
View real-time monitoring data
Log on to the Alibaba Cloud CDN console.
In the left navigation pane, choose Monitoring & Usage Analytics > Real-time Monitoring.
On the Real-time Monitoring page, select a metric and set query conditions (domain name, region, carrier, time range), then click Search.
The page displays line charts for the selected metric. Data reflects the previous minute and covers up to the last 7 days.
What's next
To query usage data for billing reconciliation, see Usage overview.
To analyze traffic by protocol layer or query longer historical ranges, see Resource Monitoring.
For a description of HTTP status codes and troubleshooting guidance, see HTTP status codes.