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

要求與回應服務

要求-回應服務是指客戶明確要求服務執行某項工作，並等待該工作順利完成。這類服務最常見的例子包括：

使用者可透過瀏覽器直接與之互動的網頁應用程式。
行動應用程式，包括使用者手機上的用戶端應用程式，以及用戶端互動的 API 後端。
由其他服務 (而非人類使用者) 使用的 API 後端。

對於所有這些服務，常見的做法是先從可用性 (評估成功要求的比率) 和延遲時間 (評估在時間門檻內完成的要求比率) 的 SLI 著手。如要進一步瞭解可用性和延遲 SLI，請參閱「服務監控的概念」。

您可以使用 TimeSeriesRatio 結構定義良好要求與要求總數的比率，藉此表達以要求為準的可用性 SLI。您可以決定如何篩選指標，並使用可用的標籤來判斷「良好」或「有效」的偏好設定。

您可以使用 DistributionCut 結構體，表示以要求為基礎的延遲 SLI。

Cloud Endpoints

Cloud Endpoints 是用於管理 API 的服務。您可以使用現有的 API，並透過驗證、配額和監控功能公開該 API。

Endpoints 會在 gRPC 應用程式伺服器前端實作為 Proxy。透過在 Proxy 中評估指標，您就能在所有後端都無法使用且使用者看到錯誤時，正確處理此情況。Endpoints 會將資料寫入以 serviceruntime.googleapis.com 為前置字元的指標類型。

如要瞭解詳情，請參考下列資源：

Cloud Endpoints 說明文件。
serviceruntime.googleapis.com 指標類型清單。

可用性服務水準協議

Cloud Endpoints 會使用 api 受控資源類型和服務執行階段 api/request_count 指標類型，將指標資料寫入 Cloud Monitoring，您可以使用 response_code 指標標籤來計算「good」和「total」要求，藉此篩選資料。

您可以建立良好要求與要求總數的 TimeSeriesRatio 結構，藉此表示以要求為基礎的可用性 SLI，如以下範例所示：

"serviceLevelIndicator": {
  "requestBased": {
    "goodTotalRatio": {
      "totalServiceFilter":
        "metric.type=\"serviceruntime.googleapis.com/api/request_count\"
         resource.type=\"api\"
         metric.label.\"response_code_class\"!=\"4xx\"",
      "goodServiceFilter":
        "metric.type=\"serviceruntime.googleapis.com/api/request_count\"
         resource.type=\"api\"
         (metric.label.\"response_code_class\"=\"1xx\"" OR
          metric.label.\"response_code_class\"=\"2xx\""),
    }
  }
}

延遲時間 SLI

Cloud Endpoints 會使用下列主要指標類型擷取延遲時間：

api/request_latencies：非串流要求的延遲時間分布 (以秒為單位)。當整體使用者體驗是主要重點時，請使用此選項。
api/request_latencies_backend：非串流要求的後端延遲時間分布情形，以秒為單位。使用此方法直接評估後端延遲時間。
api/request_latencies_overhead：非串流要求的請求延遲時間分布情形，不含後端。用於評估 Endpoints Proxy 所造成的額外負擔。

請注意，總要求延遲時間是後端和額外延遲時間的總和：

request_latencies = request_latencies_backend + request_latencies_overhead

Endpoints 會使用 api 受控資源類型和其中一個要求延遲指標類型，將指標資料寫入 Cloud Monitoring。這些指標類型都不會提供 response_code 或 response_code_class 標籤，因此會回報所有要求的延遲時間。

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

下列服務等級目標範例預期，在 1 小時的滾動期間，專案中 99% 的要求總延遲時間會落在 0 到 100 毫秒之間：

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"serviceruntime.googleapis.com/ap/request_latencies\"
           resource.type=\"api\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.99,
  "rollingPeriod": "3600s",
  "displayName": "99% requests under 100 ms"
}

在下列服務等級目標範例中，系統預期在 1 小時滾動期間，98% 的要求後端延遲時間介於 0 和 100 毫秒之間：

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"serviceruntime.googleapis.com/api/backend_latencies\"
           resource.type=\"api\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.98,
  "rollingPeriod": "3600s",
  "displayName": "98% requests under 100 ms"
}

Cloud Run

Cloud Run 是一個全代管運算平台，可快速安全地部署容器化應用程式並進行資源調度。這項服務旨在讓您省去所有基礎架構管理作業，方法是透過自動從零向上或向下調整資源配置，近乎即時回應流量變化，並只針對您使用的確切資源收費。

如要進一步瞭解 Cloud Run 的可觀測性，請參閱以下資源：

Cloud Run 說明文件。
run.googleapis.com 指標類型清單。

可用性服務水準協議

Cloud Run 會使用 cloud_run_revision 受控資源類型和 request_count 指標類型，將指標資料寫入 Cloud Monitoring。您可以使用 response_code 或 response_code_class 指標標籤來計算「成功」和「總計」要求，藉此篩選資料。

您可以建立良好要求與要求總數的 TimeSeriesRatio 結構，藉此表示以要求為基礎的可用性 SLI，如以下範例所示：

"serviceLevelIndicator": {
  "requestBased": {
    "goodTotalRatio": {
      "totalServiceFilter":
        "metric.type=\"run.googleapis.com/request_count\"
         resource.type=\"cloud_run_revision\"
         metric.label.\"response_code_class\"!=\"4xx\"",
      "goodServiceFilter":
        "metric.type=\"run.googleapis.com/request_count\"
         resource.type=\"cloud_run_revision\"
         (metric.label.\"response_code_class\"=\"1xx\"" OR
          metric.label.\"response_code_class\"=\"2xx\""),
     }
  }
}

延遲時間 SLI

為評估延遲時間，Cloud Run 會使用 cloud_run_revision 受控資源類型和 request_latencies 指標類型，將指標資料寫入 Cloud Monitoring。這項資料是要求傳送至修訂版本的延遲時間分布情形 (以毫秒為單位)。如果您需要明確評估所有要求或僅成功要求的延遲時間，可以使用 response_code 或 response_code_class 指標標籤篩選資料。

您可以使用 DistributionCut 結構體，表示以要求為基礎的延遲 SLI。在以下服務等級目標範例中，系統預期 99% 的要求在 1 小時滾動期間的總延遲時間介於 0 至 100 毫秒之間：

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"run.googleapis.com/request_latencies\"
           resource.type=\"cloud_run_revision"",
        "range": {
           "min": 0,
           "max": 100
        }
      }
    }
  },
  "goal": 0.99,
  "rollingPeriod": "3600s",
  "displayName": "99% requests under 100 ms"
}

Cloud Run 函式

Cloud Run functions 是可靈活擴充的函式即服務 (FaaS) 即付即用服務，可讓您執行程式碼，完全不必管理任何基礎架構。許多架構模式都會使用函式，用於處理事件、自動化及提供 HTTP/S 要求等作業。

如要瞭解 Cloud Run 函式的觀測能力，請參閱以下資訊：

Cloud Run 函式說明文件。
run.googleapis.com 指標類型清單。

可用性服務水準協議

Cloud Run 函式會使用 cloud_function 受控資源類型和 function/execution_time 指標類型，將指標資料寫入 Cloud Monitoring。您可以使用 status 指標標籤來計算「成功」和「總計」執行次數，藉此篩選資料。

您可以建立良好要求與要求總數的 TimeSeriesRatio 結構，藉此表示以要求為基礎的可用性 SLI，如以下範例所示：

"serviceLevelIndicator": {
  "requestBased": {
    "goodTotalRatio": {
      "totalServiceFilter":
        "metric.type=\"cloudfunctions.googleapis.com/function/execution_count\"
         resource.type=\"cloud_function\"",
      "goodServiceFilter":
        "metric.type=\"cloudfunctions.googleapis.com/function/execution_count\"
         resource.type=\"cloud_function\
         metric.label.\"status\"=\"ok\"",
     }
  }
}

延遲時間 SLI

為了評估延遲時間，Cloud Run 函式會使用 cloud_function 受控資源類型和 function/execution_times 指標類型，將指標資料寫入 Cloud Monitoring。這項資料是函式執行時間的分布，以奈秒為單位。如果您需要明確評估所有執行作業的延遲時間，或只評估成功執行作業的延遲時間，可以使用 status 篩選資料。

您可以使用 DistributionCut 結構體，表示以要求為基礎的延遲 SLI。在以下 SLO 範例中，我們預期在 1 小時滾動期間，99% 的 Cloud Run 函式執行作業總延遲時間會落在 0 到 100 毫秒之間：

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"cloudfunctions.googleapis.com/function/execution_times\"
           resource.type=\"cloud_function\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.99,
  "rollingPeriod": "3600s",
  "displayName": "99% requests under 100 ms"
}

App Engine

App Engine 提供全代管的無伺服器平台，可用於建構及執行應用程式。您可以選擇標準或彈性環境。詳情請參閱「選擇 App Engine 環境」。

如要進一步瞭解 App Engine，請參閱下列資源：

App Engine 說明文件。
appengine.googleapis.com 指標類型清單。

可用性服務水準協議

App Engine 會使用 gae_app 受控資源類型和 http/server/response_count 指標類型，將指標資料寫入 Cloud Monitoring。您可以使用 response_code 指標標籤來計算「good」和「total」回應，藉此篩選資料。

您可以建立 TimeSeriesRatio 結構，針對良好要求與要求總數，表達 App Engine 的以要求為準可用性 SLI，如以下範例所示：

"serviceLevelIndicator": {
  "requestBased": {
    "goodTotalRatio": {
      "totalServiceFilter":
        "metric.type=\"appengine.googleapis.com/http/server/response_count\"
         resource.type=\"gae_app\"
         metric.label.\"response_code\">\"499\"
         metric.label.\"response_code\"<\"399\"",
      "goodServiceFilter":
        "metric.type=\"appengine.googleapis.com/http/server/response_count\"
         resource.type=\"gae_app\"
         metric.label.\"response_code\"<\"299\"",
     }
  }
}

延遲時間 SLI

為評估延遲時間，App Engine 會使用 gae_app 受控資源類型和 http/server/response_latencies 指標類型，將指標資料寫入 Cloud Monitoring。您可以使用 response_code 指標標籤來計算「成功」和「總計」執行次數，藉此篩選資料。

您可以使用 DistributionCut 結構，為 App Engine 表示以要求為基礎的延遲 SLI。在以下服務等級目標範例中，我們預期在 1 小時的滾動期間內，99% 的要求總延遲時間會落在 0 到 100 毫秒之間：

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"appengine.googleapis.com/http/server/response_latencies\"
           resource.type=\"gae_app\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.99,
  "rollingPeriod": "3600s",
  "displayName": "99% requests under 100 ms"
}

GKE 和 Istio

Google Kubernetes Engine (GKE) 是 Google 的安全代管式 Kubernetes 服務，支援四種自動調整資源配置方法和多叢集架構。Istio 是開放原始碼服務網格，可讓您連結、保護、控制及觀察服務。您可以將 Istio 安裝在 GKE 上，做為附加元件 (Cloud Service Mesh)，也可以由使用者從開放原始碼專案安裝。無論是哪種情況，Istio 都會提供出色的遙測資料，包括網格管理的每項服務的流量、錯誤和延遲時間資訊。

如需 Istio 指標的完整清單，請參閱 istio.io 指標類型。

可用性服務水準協議

Istio 會使用 service/server/request_count 指標類型和下列任一受控資源類型，將指標資料寫入 Cloud Monitoring：

您可以使用 response_code 指標標籤來計算「good」和「total」要求，藉此篩選資料。您也可以使用 destination_service_name 指標標籤來計算特定服務的要求。

您可以為在由 Istio 服務網格管理的 GKE 上執行的服務，針對總要求建立 TimeSeriesRatio 結構，以便表示要求為準的 SLI，如以下範例所示：

"serviceLevelIndicator": {
  "requestBased": {
    "goodTotalRatio": {
      "totalServiceFilter":
        "metric.type=\"istio.io/service/server/request_count\"
         resource.type=\"k8s_container\"
         metric.label.\"destination_service_name\"=\"frontend\"",
      "goodServiceFilter":
        "metric.type=\istio.io/server/response_count\"
         resource.type=\"k8s_container\"
         metric.label.\"destination_service_name\"=\"frontend\"
         metric.label.\"response_code\"<\"299\"",
    }
  }
}

延遲時間 SLI

為了評估延遲時間，Istio 會使用 service/server/response_latencies 指標類型和下列任一受控資源類型，將指標資料寫入 Cloud Monitoring：

您可以使用 response_code 指標標籤來計算 "good" and "total" requests. You can also use thedestination_service_name` 指標標籤，藉此計算特定服務的要求。

您可以使用 DistributionCut 結構，為在由 Istio 服務網格管理的 GKE 上執行的服務，表達以要求為基礎的延遲 SLI。以下是 SLO 範例，預期在 1 小時的滾動期間內，99% 的 frontend 服務要求總延遲時間介於 0 至 100 毫秒之間：

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"istio.io/server/response_latencies\"
           resource.type=\"k8s_container\"
           metric.label.\"destination_service_name\"=\"frontend\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.99,
  "rollingPeriod": "3600s",
  "displayName": "99% requests under 100 ms"
}

要求與回應服務 透過集合功能整理內容 你可以依據偏好儲存及分類內容。

Cloud Endpoints

可用性服務水準協議

延遲時間 SLI

Cloud Run

可用性服務水準協議

延遲時間 SLI

Cloud Run 函式

可用性服務水準協議

延遲時間 SLI

App Engine

可用性服務水準協議

延遲時間 SLI

GKE 和 Istio

可用性服務水準協議

延遲時間 SLI

要求與回應服務