ロードバランシング分析では、次のことができます。
- トラフィックの流れを評価する
- プール内エンドポイントの健全性ステータスを確認する
- プールとプール健全性の変化を時系列で確認する
ロードバランサーの Overview メトリクスを見るには、Traffic > Load Balancing Analytics を開きます。
これらのメトリクスは、ロードバランサー内の特定プールへルーティングされたリクエスト数を示します。次の判断に役立ちます。
- プールの追加や削除の影響を評価する
- 新しいプールを作るタイミングを決める
- ピーク時の需要と将来のインフラ要件を計画する
特定のプール、時間、リージョン、エンドポイントでフィルターを追加できます。
Latency メトリクスはインタラクティブな地図を表示し、Unhealthy または Slow のプールがあるリージョンを見つけやすくします。
ロードバランサーのレイテンシ情報を見るには、Traffic > Load Balancing Analytics > Latency を開きます。
Logs は、エンドポイントのステータス変更と、それがロードバランシングプールへ与える影響の履歴です。Load Balancing が記録するのは、エンドポイントのステータスが healthy から unhealthy へ、またはその逆へ変わったイベントだけです。
プールに Monitor Group が接続されている場合、記録される各ヘルスイベントには monitors フィールドが含まれます。
このフィールドは、グループ内の各モニターとその結果を列挙し、どのモニターがステータス変更に寄与したかを確認しやすくします。
イベントの例（抜粋）:
{
"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
}
]
}
]
}この例では、次の点がわかります。
- 各オリジンには、接続されたグループ内の全モニターを列挙する
monitors配列があります。 must_be_healthyとmonitoring_onlyなどのフィールドは、オリジン全体の健全性判定における各モニターの役割を示します。healthyとfailure_reasonフィールドは、個々のモニターチェックの成功または失敗を示します。
ダッシュボードでログを見るには、Traffic > Load Balancing Analytics を開きます。
より柔軟に扱うには、GraphQL Analytics API からロードバランシングのメトリクスを直接取得します。
次のサンプルクエリから始めてください。
プールごとのリクエスト数
このクエリは、Cloudflare のグローバルネットワーク上の各ロケーションから、各プールが受け取ったリクエスト数を示します。
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"
}
},
...
]
}
]
}
}
}データセンターごとのリクエスト数
このクエリは、特定のデータセンター（例: シンガポール、SIN）から、特定のロードバランサー内の各プールへのモニターリクエストについて、重み付きラウンドトリップ時間（RTT）の測定値（avgRttMs）を示します。
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"
},
...
]
}
]
}
}
}