Analytics
import { Details } from "~/components";
Using load balancing analytics, you can:
- Evaluate traffic flow.
- Assess the health status of endpoints in your pools.
- Review changes in pools and pool health over time.
:::note
Load balancing analytics are only available to customers on paid plans (Pro, Business, and Enterprise).
:::
Dashboard Analytics
Overview metrics
To view Overview metrics for your load balancer, go to Traffic > Load Balancing Analytics.
These metrics show the number of requests routed to specific pools within a load balancer, helping you:
- Evaluate the effects of adding or removing a pool.
- Decide when to create new pools.
- Plan for peak traffic demands and future infrastructure needs.
Add additional filters for specific pools, times, regions, and endpoints.
:::note
Load balancing requests are the number of uncached requests made by your load balancer. By default, Cloudflare caches resolved IP addresses for up to five seconds.
:::
Latency
Latency metrics show an interactive map, helping you identify regions with Unhealthy or Slow pools.
To view latency information for your load balancer, go to Traffic > Load Balancing Analytics > Latency.
Logs
Logs provide a history of all endpoint status changes and how they affect your load balancing pools. Load Balancing only logs events that represent a status change for an endpoint, from healthy to unhealthy or vice versa.
When a Monitor Group is attached to a pool, each logged health event includes the monitors field.
This field lists the individual monitors within the group and their results, making it easier to see which monitor contributed to a status change.
Example event (truncated):
{
"id": <id>,
"timestamp": "2025-09-22 19:22:00",
"pool": {
"id": "<id>",
"name": "example-monitor-group-test-pool-us",
"healthy": true,
"changed": false,
"minimum_origins": 1
},
"origins": [
{
"name": "origin-a",
"ip": "192.0.2.10",
"enabled": true,
"healthy": true,
"failure_reason": "No failures",
"response_code": 200,
"monitors": [
{
"id": "<id>",
"healthy": true,
"failure_reason": "No failures",
"response_code": 200,
"must_be_healthy": true,
"monitoring_only": false
},
{
"id": "<id>",
"healthy": true,
"failure_reason": "No failures",
"response_code": 200,
"must_be_healthy": true,
"monitoring_only": false
},
{
"id": "<id>",
"healthy": false,
"failure_reason": "HTTP timeout occurred",
"must_be_healthy": false,
"monitoring_only": true
}
]
},
{
"name": "origin-b",
"ip": "198.51.100.25",
"enabled": true,
"healthy": false,
"failure_reason": "TCP connection failed",
"changed": true,
"monitors": [
{
"id": "<id>",
"healthy": false,
"failure_reason": "TCP connection failed",
"must_be_healthy": true,
"monitoring_only": false
},
{
"id": "<id>",
"healthy": true,
"failure_reason": "No failures",
"response_code": 200,
"must_be_healthy": true,
"monitoring_only": false
},
{
"id": "<id>",
"healthy": false,
"failure_reason": "HTTP timeout occurred",
"must_be_healthy": false,
"monitoring_only": true
}
]
}
]
}
In this example:
- Each origin includes a
monitorsarray listing all monitors within the attached group. - Fields such as
must_be_healthyand monitoring_onlyindicate each monitor's role in determining the origin's overall health. - The
healthyandfailure_reasonfields show which individual monitor checks succeeded or failed.
To access logs in the dashboard, go to Traffic > Load Balancing Analytics.
GraphQL Analytics
For more flexibility, get load balancing metrics directly from the GraphQL Analytics API.
Get started with a sample query:
This query shows the number of requests each pool receives from each location in Cloudflare's global network.
query RequestsPerPool($zoneTag: string, $start: Time, $end: Time) {
viewer {
zones(filter: { zoneTag: $zoneTag }) {
loadBalancingRequestsAdaptiveGroups(
limit: 100
filter: {
datetime_geq: $start
datetime_leq: $end
lbName: "lb.example.com"
}
orderBy: [datetimeFifteenMinutes_DESC]
) {
count
dimensions {
datetimeFifteenMinutes
coloCode
selectedPoolName
}
}
}
}
}
{
"data": {
"viewer": {
"zones": [
{
"loadBalancingRequestsAdaptiveGroups": [
{
"count": 4,
"dimensions": {
"coloCode": "IAD",
"datetimeFifteenMinutes": "2021-06-26T00:45:00Z",
"selectedPoolName": "us-east"
}
},
...
]
}
]
}
}
}
This query shows the weighted, round-trip time (RTT) measurement (avgRttMs) for monitor requests from a specific data center (for example, Singapore or SIN) to each pool in a specific load balancer.
:::caution
Note that avgRttMs refers to the round-trip time that is measured by the monitors and used in steering decisions. avgRttMs is different from the raw RTT for individual requests that reach the Cloudflare network.
:::
query RequestsPerDataCenter($zoneTag: string, $start: Time, $end: Time) {
viewer {
zones(filter: { zoneTag: $zoneTag }) {
loadBalancingRequestsAdaptive(
limit: 100
filter: {
datetime_geq: $start
datetime_leq: $end
lbName: "lb.example.com"
coloCode: "SIN"
}
orderBy: [datetime_DESC]
) {
selectedPoolName
pools {
poolName
healthy
healthCheckEnabled
avgRttMs
}
}
}
}
}
{
"data": {
"viewer": {
"zones": [
{
"loadBalancingRequestsAdaptive": [
{
"pools": [
{
"avgRttMs": 67,
"healthCheckEnabled": 1,
"healthy": 1,
"poolName": "asia-ne"
},
{
"avgRttMs": 156,
"healthCheckEnabled": 1,
"healthy": 1,
"poolName": "us-east_and_asia-ne"
},
{
"avgRttMs": 237,
"healthCheckEnabled": 1,
"healthy": 1,
"poolName": "us-east"
},
],
"selectedPoolName": "asia-ne"
},
...
]
}
]
}
}
}
谢谢你的反馈!