本頁面由 Cloud Translation API 翻譯而成。

使用 Cloud Load Balancing 指標

本頁面將回顧 Cloud Load Balancing 提供的負載平衡器類型，並說明如何將這些負載平衡器公開的 Cloud Monitoring 指標做為 SLI。

Cloud Load Balancing 服務通常是託管於 Google Cloud的應用程式第一個進入點。系統會自動為負載平衡器進行儀表化，提供負載平衡器公開的 Google Cloud 服務流量、可用性和延遲時間資訊；因此，負載平衡器通常是絕佳的 SLI 指標來源，不需要應用程式儀表化。

開始時，您可以選擇將可用性和延遲做為可靠性的主要維度，並建立 SLI 和 SLO 來評估及監控這些維度。本頁提供實作範例。

詳情請參閱下列說明：

可用性 SLI 和 SLO

對於非 UDP 應用程式，最適合使用以要求為準的可用性 SLI，因為服務互動會清楚對應至要求。

如要表示以要求為準的可用性 SLI，請使用 TimeSeriesRatio 結構設定良好要求與要求總數的比率，如下列可用性範例所示。如要取得偏好的「良好」或「有效」判定結果，請使用可用標籤篩選指標。

外部第 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 成功狀態回應碼的項目，可以這樣編寫「良好」的篩選器：

"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 受控資源類型和指標類型，將指標資料寫入 Monitoring，並以 loadbalancing.googleapis.com 為前置字元。與可用性服務水準目標最相關的指標類型是 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指標，都不適合做為可用性服務水準指標。

如要為這些負載平衡器建立可用性 SLI，請建立自訂或記錄指標。詳情請參閱「使用自訂指標」或「使用記錄指標」。

延遲時間 SLI 和 SLO

對於要求/回應應用程式，撰寫延遲 SLO 的方式有兩種：

以要求為準的服務等級目標。
時間範圍式服務等級目標。

以要求為依據的延遲時間服務等級目標

以要求為依據的服務等級目標會套用延遲門檻，並計算在指定評估時間範圍內，完成要求時延遲低於門檻的要求所占比例。以要求為準的服務等級目標範例：「在 1 小時的滾動時間範圍內，99% 的要求會在 100 毫秒內完成」。

您可以使用 DistributionCut 結構表示以要求為準的延遲 SLI，如下列延遲範例所示。

單一要求型 SLO 無法同時擷取一般效能和使用者體驗的退化情形，因為「尾部」或最慢的要求會看到回應時間越來越長。一般效能的 SLO 無法協助瞭解尾端延遲。如要瞭解尾部延遲，請參閱《網站穩定性工程》的第 6 章「監控分散式系統」中的「尾部問題處理」一節。

如要減輕這項限制的影響，您可以編寫第二個服務等級目標，專門著重於尾端延遲，例如「在 1 小時的滾動時間範圍內，99.9% 的要求會在 1000 毫秒內完成」。這兩項 SLO 結合後，可擷取一般使用者體驗和尾端延遲的衰退情形。

以時間範圍為準的延遲時間服務等級目標

以時間範圍為依據的 SLO 會定義測量時間範圍的良好條件，並計算「良好」間隔與間隔總數的比率。時間範圍式服務等級目標的範例如下：「在 28 天的滾動時間範圍內，至少 99% 的一分鐘時間範圍內，第 95 百分位數延遲指標小於 100 毫秒」：

「良好」的測量週期是指一分鐘內 95% 的要求延遲時間低於 100 毫秒。
合規程度的衡量標準是這類「良好」期間的比例。如果這個分數在合規期間內至少為 0.99，即表示服務符合規定。

如果可用的原始指標是延遲時間百分位數，您就必須使用時間範圍式服務等級目標，也就是符合下列兩項條件時：

資料會依時間間隔分類 (例如一分鐘間隔)。
資料會以百分位數群組表示 (例如 p50、p90、p95、p99)。

這類資料的每個百分位數群組，都代表將資料群組劃分為高於和低於該百分位數的時間。舉例來說，如果間隔為一分鐘，且 p95 延遲時間指標為 89 毫秒，表示該服務在一分鐘內，回應 95% 要求的時間為 89 毫秒或更短。

外部應用程式負載平衡器

外部應用程式負載平衡器會使用下列主要指標類型來擷取延遲時間：

https/total_latencies：延遲時間分布情形，計算方式為從 Proxy 收到要求，到 Proxy 在最後一個回應位元組上從用戶端收到 ACK。如果整體使用者體驗是首要考量，請使用這個選項。
https/backend_latencies：延遲時間分布情形，計算方式為從 Proxy 將要求傳送至後端，到 Proxy 從後端接收回應的最後一個位元組。用於測量負載平衡器後方特定後端服務流量的延遲時間。

這些指標會針對 https_lb_rule 受監控資源類型寫入。

總延遲時間

這個 SLO 範例預期在每小時的滾動週期內，有 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"
}

後端延遲時間

在這個服務等級目標範例中，我們預期在過去一小時內，對「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 受監控資源類型寫入。

總延遲時間

這個 SLO 範例預期在過去一小時內，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"
}

這個 SLO 範例預期在每小時的滾動期間內，99% 的要求總延遲時間會介於 0 到 100 毫秒之間。

後端延遲時間

這個服務等級目標範例預期，在過去一小時內，對「my-internal-backend」後端目標發出的要求中，有 98% 的延遲時間介於 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 資源寫入。

這個 SLO 範例預期在過去一小時內，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 資源寫入。

這個 SLO 範例預期在過去一小時內，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"
}

使用 Cloud Load Balancing 指標 透過集合功能整理內容 你可以依據偏好儲存及分類內容。

可用性 SLI 和 SLO

外部第 7 層 (HTTP/S) 負載平衡器

內部第 7 層 (HTTP/S) 負載平衡器

第 3 層 (TCP) 負載平衡器

延遲時間 SLI 和 SLO

以要求為依據的延遲時間服務等級目標

以時間範圍為準的延遲時間服務等級目標

外部應用程式負載平衡器

總延遲時間

後端延遲時間

內部應用程式負載平衡器

總延遲時間

後端延遲時間

外部第 3 層 (TCP) 負載平衡器

內部第 3 層 (TCP) 負載平衡器

使用 Cloud Load Balancing 指標