API で構築する

このドキュメントでは、SLO API でサービスと SLO を表すために使用される構文、およびサービス モニタリングのコンセプトに記載されるコンセプト全般に関連付けて説明します。

SLO API は、サービスの状態のモニタリングに使用できるサービスレベル目標(SLO)を設定するために使用されます。

Service Monitoring は、Monitoring API に次のリソースを追加します。

API の呼び出しについては、API の操作をご覧ください。

サービス

サービスは、Service オブジェクトで表示されます。このオブジェクトには次のフィールドが含まれます。

  • 名前: サービスの完全修飾リソース名。
  • 表示名: コンソール コンポーネントで使用するラベル
  • サービスタイプの構造。サポートされているサービスタイプは次のとおりです。
    • App Engine サービス
    • Google Kubernetes Engine の Istio サービス
    • さまざまな GKE サービス
    • Cloud Run サービス
    • カスタム サービス
  • テレメトリー構成オブジェクト(自動検出された一部のサービス用)

API を使用して明示的に作成するサービスタイプは、ユーザー指定のサービスまたはカスタム サービスのみです。これらのサービスは、次のいずれかの埋め込み構造に対応しています。

ユーザー指定の Cloud Run サービスの JSON 表現は次のとおりです。

{
  "name": "projects/PROJECT_NUMBER/services/B7LOmd7YQtGY_Hao8UoLDA",
  "displayName": "test-cloudrun-service",
  "cloudRun": {
    "serviceName": "test-cloudrun-service",
    "location": "us-central1"
  }
}

Anthos Service Mesh、Google Kubernetes Engine 上の Istio、App Engine サービスは、環境に基づいて自動的に作成されます。手動では作成しません。たとえば、Istio サービスの JSON 表現は次のようになります。

{
  "name": "projects/Google Cloud project/services/PROJECT_ID-zone-us-central1-c-csm-main-default-currencyservice",
  "displayName": "PROJECT_ID/us-central1-c/csm-main/default/currencyservice",
  "clusterIstio": {
    "location": "us-central1-c",
    "clusterName": "csm-main",
    "serviceNamespace": "default",
    "serviceName": "currencyservice"
  },
  "telemetry": {
    "resourceName": "//container.googleapis.com/projects/PROJECT_ID/zones/us-central1-c/clusters/csm-main/k8s/namespaces/default/services/currencyservice"
  }
}

サービスレベル指標

サービスレベル指標(SLI)は、サービスのパフォーマンスの指標を提供します。SLI は、サービスによって取得された指標に基づいています。SLI の定義は、インジケーター指標として使用する指標の種類によって異なりますが、一般的には、良い結果と結果総数の比率が使用されます。

SLI は、ServiceLevelIndicator オブジェクトで表現されます。このオブジェクトでは、サポートされている次の 3 種類の SLI がまとめて参照されます。

  • 基本 SLI。既知のサービスタイプに対して自動的に作成されます。このタイプの SLI については、サービスレベル目標をご覧ください。BasicSli オブジェクトで表現され、可用性やレイテンシを測定できます。

  • リクエスト ベースの SLI。イベントの回数によって受け入れ可能なサービスを表現する際に使用できます。このタイプの SLI の使用については、リクエスト ベースの SLO をご覧ください。RequestBasedSli オブジェクトで表現されます。

  • ウィンドウ ベースの SLI。「良好さ」の基準を満たす測定間隔をカウントするために使用できます。このタイプの SLI の使用については、ウィンドウ ベースの SLO をご覧ください。WindowsBasedSli オブジェクトで表現されます。

たとえば、基本的な可用性 SLI には次のものがあります。

{
  "basicSli": {
    "availability": {},
    "location": [
      "us-central1-c"
    ]
  }
}

リクエスト ベースの SLI の構成

リクエスト ベースの SLI は、サービスの基本単位をカウントして、特定の結果と合計の結果の比率として表す指標に基づいています。たとえば、リクエストをカウントする指標を使用する場合、成功したリクエストの数とリクエストの総数の比率を算出できます。

リクエスト ベースの SLI を作成するには、次の 2 つの方法があります。

  • TimeSeriesRatio として作成する。サービス総数に対する良好なサービスの比率が、指標の値が DELTA または CUMULATIVE となる 2 つの時系列から計算されます。
  • DistributionCut として作成する。値の型が DISTRIBUTION で、指標の値の種類が DELTA または CUMULATIVE となる時系列の場合に使用します。good-service の値は指定された範囲内のヒストグラム バケットに含まれるアイテムの数、total の値は分布内のすべての値の総数です。

以下に、時系列の比率を使用する 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 は、200 番台のレスポンスの総レイテンシに対する、500 番未満の 2xx クラス レスポンスのレイテンシの比率を計算します。

ウィンドウ ベースの SLI の構成

ウィンドウ ベースの SLI は、提供されたサービスが良好とみなされる時間ウィンドウをカウントします。サービスの良好さの度合いを判断するための条件は、SLI の中で定義されます。

ウィンドウ ベースの SLI には必ず 60~86,400 秒(1 日)の範囲内のウィンドウ期間が含まれます。

ウィンドウ ベースの SLI に良好なサービスの基準を指定する方法には、次の 2 つがあります。

  • モニタリング フィルタで説明している、ブール値を持つ時系列を返すフィルタ文字列を作成します。ウィンドウの値が true の場合、そのウィンドウは良好です。このフィルタは goodBadMetricFilter と呼ばれます。
  • パフォーマンスの許容範囲のしきい値を表す PerformanceThreshold オブジェクトを作成します。このオブジェクトは、goodTotalRatioThreshold の値として指定します。

    PerformanceThreshold オブジェクトは、しきい値とパフォーマンス SLI を指定します。パフォーマンス SLI の値がしきい値以上になる場合、その時間ウィンドウは良好と判定されます。

    パフォーマンス SLI を指定する方法には、次の 2 つの方法があります。

    • basicPerformanceSli フィールドに、BasicSli オブジェクトとして指定する。
    • performance フィールドに、RequestBasedSli オブジェクトとして指定する。

基本的な可用性 SLI のパフォーマンスしきい値に基づいて作成された、ウィンドウ ベース SLI の JSON 表現の例を次に示します。

{
  "windowsBased": {
     "goodTotalRatioThreshold": {
       "threshold": 0.9,
       "basicSliPerformance": {
         "availability": {},
         "location": [
           "us-central1-c"
         ]
       }
     },
     "windowPeriod": "300s"
   }
}

この SLI は、可用性が 90% 以上になる 5 分間のウィンドウを良好なパフォーマンスとして指定しています。基本的な SLI の構造については、サービスレベル指標をご覧ください。

リクエスト ベースの SLI をウィンドウ ベースの SLI に埋め込むこともできます。埋め込み構造の詳細については、リクエスト ベースの SLI の構成をご覧ください。

サービスレベル目標

サービスレベル目標(SLO)は、ServiceLevelObjective オブジェクトで表現します。このオブジェクトには次のフィールドが含まれます。

次の例は、serviceLevelIndicator フィールドの値として基本的な可用性 SLI が指定された SLO の JSON 表現を示しています。

{
   "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 では、パフォーマンス目標は「1 週間の可用性が 98%」と設定されています。