要求與回應服務

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

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

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

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

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

Cloud Endpoints

Cloud Endpoints 是一項 API 管理服務。您可以透過這個服務，使用現有 API 並公開，同時進行驗證、配額設定和監控。

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

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

可用性 SLI

Cloud Endpoints 會使用 api 受監控資源類型和服務執行階段 api/request_count 指標類型，將指標資料寫入 Cloud Monitoring，您可以透過 response_code 指標標籤進行篩選，計算「良好」和「總」要求數。

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

"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，如下列範例所示。

以下服務等級目標範例預期專案中 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"
}

以下服務等級目標範例預期，在過去一小時內，有 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 可觀測性，請參閱下列內容：

可用性 SLI

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

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

"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% 的要求總延遲時間介於 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 是一種可靈活擴充的函式即服務，採用即付即用模式，可執行程式碼，不必管理任何基礎架構。許多架構模式都會使用函式，例如處理事件、自動化，以及處理 HTTP/S 要求。

如要瞭解 Cloud Run 函式觀測功能，請參閱下列文章：

可用性 SLI

Cloud Run Functions 會使用 cloud_function 受監控資源類型和 function/execution_time 指標類型，將指標資料寫入 Cloud Monitoring。您可以使用 status 指標標籤篩選資料，計算「良好」和「總」執行次數。

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

"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 Functions 會使用 cloud_function 受監控資源類型和 function/execution_times 指標類型，將指標資料寫入 Cloud Monitoring。資料是函式執行時間的分布情形，單位為奈秒。" 如要明確評估所有執行作業或僅成功執行作業的延遲時間，可以使用 status 篩選資料。

您可以使用 DistributionCut 結構表示以要求為基礎的延遲 SLI。以下範例 SLO 預期在每小時的滾動期間內，所有 Cloud Run 函式執行的總延遲時間，有 99% 介於 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，請參閱下列資源：

可用性 SLI

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

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

"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。以下服務等級目標範例預期，在每小時的滾動期間內，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 是開放原始碼服務網格，可讓您連結、保護、控制及觀察服務。您可以在 GKE 上安裝 Istio，方法是透過外掛程式 (Cloud Service Mesh)，或是從開放原始碼專案安裝。在這兩種情況下，Istio 都會提供優異的遙測功能，包括網格管理的各項服務的流量、錯誤和延遲時間資訊。

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

可用性 SLI

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

您可以使用 response_code 指標標籤篩選資料，計算「良好」和「總」請求數。您也可以使用 destination_service_name 指標標籤，計算特定服務的要求數。

如要為 Istio 服務網格管理的 GKE 服務，表示以要求為準的可用性 SLI，請為良好要求與總要求建立 TimeSeriesRatio 結構，如下列範例所示：

"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 the

您可以透過 DistributionCut 結構，為 Istio 服務網格管理的 GKE 服務，表示以要求為準的延遲 SLI。以下範例 SLO 預期在過去一小時內，服務的所有要求中，有 99% 的總延遲時間介於 0 到 100 毫秒之間：frontend

{
  "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"
}