本頁面將介紹 Cloud Load Balancing 提供的負載平衡器類型，並說明如何使用這些負載平衡器提供的 Cloud Monitoring 指標做為服務水準指標 (SLI)。
Cloud Load Balancing 服務通常會為在 Google Cloud中代管的應用程式提供第一個進入點。負載平衡器會自動進行檢測，提供公開的 Google Cloud 服務流量、可用性和延遲資訊；因此，負載平衡器通常是 SLI 指標的絕佳來源，無須應用程式檢測即可。
剛開始時，您可以將可用性和延遲時間做為可靠度的重點維度，並建立 SLI 和 SLO，以便評估及發出這些維度的警示。本頁面提供實作範例。
如需更多資訊，請參閱下列資源：
可用性服務水準指標和服務等級目標
對於非 UDP 應用程式，以要求為準的可用性 SLI 最為合適，因為服務互動會清楚對應至要求。
您可以使用 TimeSeriesRatio 結構，設定有效要求與總要求的比率，藉此表示以要求為依據的可用性 SLI，如以下可用性範例所示。如要判斷「良好」或「有效」的偏好設定，請使用指標的可用標籤進行篩選。
外部第 7 層 (HTTP/S) 負載平衡器
HTTP/S 負載平衡器可用於公開透過 HTTP/S 存取的應用程式，並將流量分配給位於多個區域的資源。
外部應用程式負載平衡器會使用 https_lb_rule 受控資源類型和前置字串 loadbalancing.googleapis.com 的指標類型，將指標資料寫入 Monitoring。與可用性 SLO 最相關的指標類型是 https/request_count，您可以使用 response_code_class 指標標籤進行篩選。
如果您選擇不將導致 4xx 錯誤回應代碼的請求視為「有效」，因為這些請求可能表示用戶端錯誤，而非服務或應用程式錯誤，您可以為「總計」編寫篩選器，如下所示：
"totalServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/request_count\"
resource.type=\"https_lb_rule\"
resource.label.\"url_map_name\"=\"my-app-lb\"
metric.label.\"response_code_class\"!=\"400\"",
您也需要決定如何計算「良好」要求。舉例來說，如果您選擇只計算傳回 200 OK 成功狀態回應碼的資料，可以為「good」編寫篩選器，如下所示：
"goodServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/request_count\"
resource.type=\"https_lb_rule\"
resource.label.\"url_map_name\"=\"my-app-lb\"
metric.label.\"response_code_class\"=\"200\"",
接著，您可以以這種方式表達以要求為基礎的 SLI：
"serviceLevelIndicator": {
"requestBased": {
"goodTotalRatio": {
"totalServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/request_count\"
resource.type=\"https_lb_rule\"
resource.label.\"url_map_name\"=\"my-app-lb\"
metric.label.\"response_code_class\"!=\"400\"",
"goodServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/request_count\"
resource.type=\"https_lb_rule\"
resource.label.\"url_map_name\"=\"my-app-lb\"
metric.label.\"response_code_class\"=\"200\"",
}
}
},
如果應用程式由多個後端提供流量，您可以選擇為特定後端定義 SLI。如要為特定後端建立可用性 SLI，請在篩選器中使用 https/backend_request_count 指標搭配 backend_target_name 資源標籤，如以下範例所示：
"serviceLevelIndicator": {
"requestBased": {
"goodTotalRatio": {
"totalServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/backend_request_count\"
resource.type=\"https_lb_rule\"
resource.label.\"url_map_name\"=\"my-app-lb\"
resource.label.\"backend_target_name\"=\"my-app-backend\"
metric.label.\"response_code_class\"!=\"400\"",
"goodServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/backend_request_count\"
resource.type=\"https_lb_rule\" resource.label.\"url_map_name\"=\"my-app-lb\"
resource.label.\"backend_target_name\"=\"my-app-backend\"
metric.label.\"response_code_class\"=\"200\"",
}
}
}
內部第 7 層 (HTTP/S) 負載平衡器
內部應用程式負載平衡器會使用 internal_http_lb_rule 受控資源類型和前置字 loadbalancing.googleapis.com 的指標類型，將指標資料寫入 Monitoring。與可用性服務水準目標最相關的指標類型是 https/internal_request_count，您可以使用 response_code_class 指標標籤進行篩選。
以下為以要求為依據的可用性 SLI 範例：
"serviceLevelIndicator": {
"requestBased": {
"goodTotalRatio": {
"totalServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/internal/request_count\"
resource.type=\"internal_http_lb_rule\"
resource.label.\"url_map_name\"=\"my-internal-lb\"
metric.label.\"response_code_class\"!=\"400\"",
"goodServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/internal/request_count\"
resource.type=\"internal_http_lb_rule\"
resource.label.\"url_map_name\"=\"my-internal-lb\"
metric.label.\"response_code_class\"=\"200\"",
}
}
},
第 3 層 (TCP) 負載平衡器
TCP 負載平衡器不會提供要求指標，因為使用這些負載平衡器的應用程式可能不會以要求-回應模型為基礎。這些負載平衡器提供的 loadbalancing.googleapis.com 指標都無法提供良好的可用性服務水準協議。
如要為這些負載平衡器建立可用性服務等級目標，您必須建立自訂指標或記錄指標。詳情請參閱「使用自訂指標」或「使用記錄指標」。
延遲時間服務水準指標和服務等級目標
對於要求-回應應用程式，有兩種方式可以編寫延遲 SLO：
- 以要求為準的服務等級目標。
- 以時間範圍式服務等級目標為準。
以要求為基礎的延遲時間服務等級目標
以要求為依據的服務等級目標會套用延遲門檻，並計算在特定遵循時間範圍內，完成時間低於門檻的請求所占的比例。以要求為基礎的服務等級目標範例為「99% 的要求會在 1 小時滾動期間內 100 毫秒內完成」。
您可以使用 DistributionCut 結構表示以要求為依據的延遲 SLI，如以下延遲範例所示。
單一以要求為準的 SLO 無法同時擷取一般效能和使用者體驗的劣化情形，其中「尾端」或最慢的要求，回應時間會越來越長。一般效能的 SLO 不支援瞭解尾端延遲時間。如要瞭解尾端延遲時間，請參閱 《網站穩定性工程》第 6 章「監控分散式系統」中的「Worrying About Your Tail」(尾端問題處理) 一節。
為減輕這項限制，您可以編寫第二個服務等級目標，專注於尾端延遲時間，例如「99.9% 的要求會在 1 小時滾動期間內於 1000 毫秒內完成」。這兩項 SLO 的組合可捕捉一般使用者體驗和尾端延遲時間的降級情形。
以時間範圍為準的延遲時間服務等級目標
以時間範圍為依據的服務水準指標會定義測量時間範圍的良好條件，並計算「良好」間隔與間隔總數的比率。以時間範圍式服務等級目標為例，假設在 28 天滾動式時間範圍內，至少 99% 的一分鐘時間範圍內，95 百分位數延遲指標低於 100 毫秒：
- 「良好」的評估期間是指 95% 的請求延遲時間低於 100 毫秒的一分鐘時間間隔。
- 評估合規性的指標是這些「良好」期間的比例。如果這項分數在遵循期內的計算結果至少為 0.99，則表示服務符合規定。
如果您使用的原始指標是延遲百分比，也就是下列兩個條件同時成立時，就必須使用時間範圍式服務等級目標：
- 資料會分割為時間區間 (例如一分鐘間隔)。
- 資料以百分位數群組表示 (例如 p50、p90、p95、p99)。
對於這類資料，每個百分位數群組都會指出將資料群組劃分為高於或低於該百分位數的時間。舉例來說，如果 1 分鐘間隔的 p95 延遲時間指標為 89 毫秒，表示在該分鐘內，服務在 89 毫秒內回應 95% 的要求。
外部應用程式負載平衡器
外部應用程式負載平衡器會使用下列主要指標類型擷取延遲：
https/total_latencies：從 Proxy 接收要求，到 Proxy 在最後一個回應位元組上從用戶端接收 ACK 所計算的延遲時間分布情形。當整體使用者體驗是主要重點時，請使用此選項。https/backend_latencies：從 Proxy 將要求傳送至後端，到 Proxy 從後端接收回應的最後一個位元組所計算的延遲時間分布情形。用於評估負載平衡器後方提供流量的特定後端延遲時間。
這些指標會針對 https_lb_rule 受控資源類型寫入。
總延遲時間
這個範例 SLO 預期在 1 小時滾動期間，99% 的要求總延遲時間介於 0 至 100 毫秒之間：
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/https/total_latencies\"
resource.type=\"https_lb_rule\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}
後端延遲時間
這個範例 SLO 預期，在滾動一小時期間內，針對「my-app-backend」後端目標的 98% 要求，延遲時間介於 0 到 100 毫秒之間：
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/https/backend_latencies\"
resource.type=\"https_lb_rule\"
resource.label.\"backend_target_name\"=\"my-app-backend\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.98,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}
內部應用程式負載平衡器
內部應用程式負載平衡器會使用兩種主要指標類型擷取延遲時間：
https/internal/total_latencies：從 Proxy 接收要求到 Proxy 從用戶端接收最後回應位元組的 ACK 所計算的延遲時間分布情形。當整體使用者體驗是首要考量時，請使用此選項。https/internal/backend_latencies：從 Proxy 將要求傳送至後端，到 Proxy 從後端接收回應的最後一個位元組所計算的延遲時間分布情形。用於評估負載平衡器後方提供流量的特定後端延遲時間。
這些指標會針對 internal_http_lb_rule 受控資源類型寫入。
總延遲時間
這個範例服務等級目標預期，在 1 小時滾動期間，99% 的要求總延遲時間介於 0 至 100 毫秒之間：
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/https/internal/total_latencies\"
resource.type=\"internal_http_lb_rule\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}
這個範例的服務等級目標預期，在 1 小時的滾動期間內，99% 的要求總延遲時間介於 0 到 100 毫秒之間。
後端延遲時間
這個範例的服務等級目標預期，在滾動式一小時期間內，98% 的「my-internal-backend」後端目標要求延遲時間介於 0 至 100 毫秒之間：
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/https/internal/backend_latencies\"
resource.type=\"https_lb_rule\"
resource.label.\"backend_target_name\"=\"my-internal-backend\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.98,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}
外部第 3 層 (TCP) 負載平衡器
外部 TCP 負載平衡器使用單一指標類型 l3/external/rtt_latencies，可記錄外部負載平衡器流量透過 TCP 連線測量的往返時間分布情形。
這項指標會針對 tcp_lb_rule 資源寫入。
這個範例服務等級目標預期，在 1 小時滾動期間，99% 的要求總延遲時間介於 0 至 100 毫秒之間：
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/l3/external/rtt_latencies\"
resource.type=\"tcp_lb_rule\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}
內部第 3 層 (TCP) 負載平衡器
內部 TCP 負載平衡器使用單一指標類型 l3/internal/rtt_latencies，記錄內部負載平衡器流量透過 TCP 連線測量的往返時間分布情形。
這項指標會針對 internal_tcp_lb_rule 資源寫入。
這個範例服務等級目標預期，在 1 小時滾動期間，99% 的要求總延遲時間介於 0 到 100 毫秒之間：
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/l3/internal/rtt_latencies\"
resource.type=\"internal_tcp_lb_rule\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}