本文將介紹 SLO API 中用於表示服務和 SLO 的結構,並將這些結構對應至「服務監控概念」中一般說明的概念。
SLO API 可用來設定服務等級目標 (SLO),監控服務的健康狀態。
服務監控會在 Monitoring API 中新增下列資源:
如要瞭解如何叫用 API,請參閱「使用 API」。
服務
服務是由 Service
物件表示。這個物件包含下列欄位:
- 名稱:這個服務的完整資源名稱
- 顯示名稱:用於控制台元件的標籤
- 其中一種
BasicService
類型的結構。 - 系統提供的遙測設定物件
如要定義基本服務,請指定服務類型,並提供一組描述服務的服務專屬標籤:
{ "serviceType": string, "serviceLabels": { string: string, ... } }
以下各節提供每種服務的範例。
基本服務類型
本節提供以 BasicService
型別為基礎的服務定義範例,其中 serviceType
欄位的值為下列其中一項:
APP_ENGINE
CLOUD_ENDPOINTS
CLUSTER_ISTIO
ISTIO_CANONICAL_SERVICE
CLOUD_RUN
這些服務類型都會使用 BasicSli
服務水準指標。
App Engine
{ "displayName": "DISPLAY_NAME", "basicService": { "serviceType": "APP_ENGINE", "serviceLabels": { "module_id": "MODULE_ID" }, }, }
Cloud Endpoints
{ "displayName": "DISPLAY_NAME", "basicService": { "serviceType": "CLOUD_ENDPOINTS", "serviceLabels": { "service": "SERVICE" }, }, }
叢集 Istio
{ "displayName": "DISPLAY_NAME", "basicService": { "serviceType": "CLUSTER_ISTIO", "serviceLabels": { "location": "LOCATION", "cluster_name": "CLUSTER_NAME", "service_namespace": "SERVICE_NAMESPACE", "service_name": "SERVICE_NAME" }, }, }
Istio 標準服務
{ "displayName": "DISPLAY_NAME", "basicService": { "serviceType": "ISTIO_CANONICAL_SERVICE", "serviceLabels": { "mesh_uid": "MESH_UID", "canonical_service_namespace": "CANONICAL_SERVICE_NAMESPACE", "canonical_service": "CANONICAL_SERVICE" }, }, }
Cloud Run
{ "displayName": "DISPLAY_NAME", "basicService": { "serviceType": "CLOUD_RUN", "serviceLabels": { "service_name": "SERVICE_NAME", "location": "LOCATION" }, }, }
基本 GKE 服務類型
本節包含以 BasicService
型別為基礎建構的 GKE 服務定義範例,其中 serviceType
欄位的值為下列其中一項:
GKE_NAMESPACE
GKE_WORKLOAD
GKE_SERVICE
您必須為這些服務類型定義服務水準指標。無法使用BasicSli
服務水準指標。詳情請參閱「服務水準指標」。
GKE 命名空間
{ "displayName": "DISPLAY_NAME", "basicService": { "serviceType": "GKE_NAMESPACE", "serviceLabels": { "project_id": "PROJECT_ID", "location": "LOCATION", "cluster_name": "CLUSTER_NAME", "namespace_name": "NAMESPACE_NAME" } }, }
GKE 工作負載
{ "displayName": "DISPLAY_NAME", "basicService": { "serviceType": "GKE_WORKLOAD", "serviceLabels": { "project_id": "PROJECT_ID", "location": "LOCATION", "cluster_name": "CLUSTER_NAME", "namespace_name": "NAMESPACE_NAME", "top_level_controller_type": "TOPLEVEL_CONTROLLER_TYPE", "top_level_controller_name": "TOPLEVEL_CONTROLLER_NAME", } }, }
GKE 服務
{ "displayName": "DISPLAY_NAME", "basicService": { "serviceType": "GKE_SERVICE", "serviceLabels": { "project_id": "PROJECT_ID", "location": "LOCATION", "cluster_name": "CLUSTER_NAME", "namespace_name": "NAMESPACE_NAME", "service_name": "SERVICE_NAME" } }, }
自訂服務
如果沒有適合的基本服務類型,可以建立自訂服務。自訂服務如下所示:
{ "displayName": "DISPLAY_NAME", "custom": {} }
您必須為這些服務類型定義服務水準指標。無法使用BasicSli
服務水準指標。詳情請參閱「服務水準指標」。
服務水準指標
服務水準指標 (SLI) 可用來評估服務的效能。 服務水準指標是以服務擷取的指標為依據。SLI 的確切定義取決於用做指標指標的指標類型,但通常是可接受的結果與總結果之間的比較。
SLI 是以 ServiceLevelIndicator
物件表示。這個物件是統稱三種支援的 SLI 類型:
系統會自動為
BasicService
服務類型的執行個體建立基本 SLI。這類服務水準指標說明請參閱「服務等級目標」;這類指標以BasicSli
物件表示,並用於評估可用性或延遲。以要求為準的服務水準指標,可用於計算代表可接受服務的事件。如要瞭解如何使用這類 SLI,請參閱「以要求為準的服務等級目標」;這類 SLI 會以
RequestBasedSli
物件表示。以時間範圍為依據的 SLI,可用於計算符合良好條件的時間範圍。如要瞭解如何使用這類 SLI,請參閱「以視窗為準的服務等級目標」;這類 SLI 以
WindowsBasedSli
物件表示。
舉例來說,以下顯示基本可用性 SLI:
{ "basicSli": { "availability": {}, "location": [ "us-central1-c" ] } }
以要求為依據的 SLI 結構
以要求為準的 SLI 是以指標為準,可將服務單位計為特定結果與總數的比率。舉例來說,如果您使用計算要求的指標,可以建立傳回成功的要求數與要求總數的比率。
建立以要求為準的 SLI 有兩種方式:
TimeSeriesRatio
,當良好服務與服務總數的比率是從兩個時間序列計算而來,且這些時間序列的值具有DELTA
或CUMULATIVE
的指標類型時。- 做為
DistributionCut
,當時間序列的值類型為DISTRIBUTION
,且值具有DELTA
或CUMULATIVE
的指標種類時。「良好服務」值是指落入指定範圍內直方圖值區的項目數量,而「總計」是指分布圖中所有值的數量。
以下顯示使用時間序列比率的 SLI 的 JSON 表示法:
{ "requestBased": { "goodTotalRatio": { "totalServiceFilter": "resource.type=https_lb_rule metric.type="loadbalancing.googleapis.com/https/request_count"", "goodServiceFilter": "resource.type=https_lb_rule metric.type="loadbalancing.googleapis.com/https/request_count" metric.label.response_code_class=200", } } }
這個比率中的時間序列是由受監控的資源類型和指標類型配對所識別:
- 資源:
https_lb_rule
- 指標類型:
loadbalancing.googleapis.com/https/request_count
totalServiceFilter
的值是由指標和資源類型組合表示。goodServiceFilter
的值由相同組合表示,但其中有些標籤具有特定值;在本例中,response_code_class
標籤的值為 200
。
篩選器之間的比例會計算傳回 2xx HTTP 狀態的要求數,占要求總數的比例。
以下顯示使用分配項的 SLI 的 JSON 表示法:
{ "requestBased": { "distribution_cut": { "distribution_filter": "resource.type=https_lb_rule metric.type="loadbalancing.googleapis.com/https/backend_latencies" metric.label.response_code_class=200", "range": { "min": "-Infinity", "max": 500.0 } } } }
時間序列的識別依據為受控資源類型、指標類型和指標標籤值:
- 資源:
https_lb_rule
- 指標類型:
loadbalancing.googleapis.com/https/backend_latencies
- 標籤值組合:
response_code_class
=200
range
欄位會指定視為良好的延遲時間範圍。
這項 SLI 會計算延遲時間低於 500 毫秒的 2xx 類別回應,在所有 200 類別回應中所占的比率。
時間範圍式 SLI 的結構
以時間範圍為依據的 SLI 會計算服務品質良好的時間範圍。判斷服務品質的標準是服務水準指標定義的一部分。
所有以時間範圍為準的 SLI 都包含時間範圍,即 60 至 86,400 秒 (1 天)。
您可以透過兩種方式,為以時間範圍為依據的 SLI 指定良好服務條件:
- 建立篩選器字串 (如「監控篩選器」所述),傳回含有布林值的時間序列。如果該時間範圍的值為
true
,則該時間範圍良好。這個篩選器稱為goodBadMetricFilter
。 建立
PerformanceThreshold
物件,代表可接受的效能門檻。這個物件會指定為goodTotalRatioThreshold
的值。PerformanceThreshold
物件會指定門檻值和效能服務水準指標。如果效能 SLI 的值達到或超過門檻值,該時間範圍就會計為良好。您可以透過兩種方式指定效能 SLI:
- 做為
basicPerformanceSli
欄位中的BasicSli
物件。 - 做為
performance
欄位中的RequestBasedSli
物件。如果您使用以要求為準的 SLI,則 SLI 的指標類型必須為DELTA
或CUMULATIVE
。您無法在以要求為準的 SLI 中使用GAUGE
指標。
- 做為
下列 JSON 代表以基本可用性 SLI 的效能門檻為基礎建構的 Windows SLI:
{ "windowsBased": { "goodTotalRatioThreshold": { "threshold": 0.9, "basicSliPerformance": { "availability": {}, "location": [ "us-central1-c" ] } }, "windowPeriod": "300s" } }
這項 SLI 將良好效能定義為可用性達到 90% 以上的 5 分鐘時間範圍。基本 SLI 的結構如「服務水準指標」一文所示。
您也可以在時間範圍式 SLI 中嵌入依要求為基礎的 SLI。如要進一步瞭解內嵌結構,請參閱以要求為準的 SLI 結構。
服務等級目標
服務等級目標 (SLO) 是以 ServiceLevelObjective
物件表示。這個物件包含下列欄位:
- 名稱
- 顯示名稱
- 目標 SLI;內嵌的
ServiceLevelIndicator
物件 - SLI 的成效目標
- SLI 的評估時間範圍
以下顯示 SLO 的 JSON 表示法,其中使用基本可用性 SLI 做為 serviceLevelIndicator
欄位的值:
{ "name": "projects/PROJECT_NUMBER/services/PROJECT_ID-zone-us-central1-c-csm-main-default-currencyservice/serviceLevelObjectives/3kavNVTtTMuzL7KcXAxqCQ", "serviceLevelIndicator": { "basicSli": { "availability": {}, "location": [ "us-central1-c" ] } }, "goal": 0.98, "calendarPeriod": "WEEK", "displayName": "98% Availability in Calendar Week" }
這項 SLO 將效能目標設為一週內 98% 的可用性。