请求响应服务

请求响应服务是指客户通过该服务明确要求服务执行一些工作并等待该工作成功完成。此类服务最常见的示例包括：

• 真人用户使用浏览器直接与之交互的 Web 应用。
• 移动应用，由用户手机上的客户端应用以及客户端与之交互的 API 后端组成。
• 由其他服务（而非真人用户）使用的 API 后端。

对于所有这些服务，常见的方法是从可用性（衡量成功请求的比率）和延迟时间（测量在某个时间阈值内完成的请求的比率）SLI 开始。如需详细了解可用性和延迟时间 SLI，请参阅服务监控的概念。

您可以通过使用 TimeSeriesRatio 结构设置正常请求数与请求总数的比率来表示基于请求的可用性 SLI。可以使用可用标签获得“正常”或“有效”首选确定结果，从而决定如何过滤指标。

您可以使用 DistributionCut 结构来表示基于请求的延迟时间 SLI。

注意：其中一些示例中的过滤条件字符串已经过换行处理，以提高可读性。

Cloud Endpoints

Cloud Endpoints 是一项用于管理 API 的服务。此服务允许您使用现有 API，并通过身份验证、配额和监控等方式进行公开。

Endpoints 作为 gRPC 应用服务器前面的代理实现。通过在该代理上衡量指标，您可以在所有后端不可用且用户看到错误时正确处理这种情况。Endpoints 会将数据写入以前缀 serviceruntime.googleapis.com 开头的指标类型。

详情请参阅以下内容：

• Cloud Endpoints 相关文档。
• serviceruntime.googleapis.com 指标类型的列表。

可用性 SLI

Cloud Endpoints 使用 api 监控的资源类型和服务运行时 api/request_count 指标类型将指标数据写入 Cloud Monitoring，您可以使用 response_code 指标标签统计“正常”请求数和请求“总数”来过滤这些指标数据。

您可以通过为正常请求数与请求总数创建 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 代理产生的开销。

请注意，请求总延迟时间是后端和开销延迟时间的总和：

request_latencies = request_latencies_backend + request_latencies_overhead

Endpoints 使用 api 受监控的资源类型和以下请求延迟时间指标类型之一，将指标数据写入 Cloud Monitoring。这些指标类型均不提供 response_code 或 response_code_class 标签。因此，它们会报告所有请求的延迟时间。

您可以通过使用 DistributionCut 结构来表示基于请求的延迟时间 SLI，如以下示例所示。

以下示例 SLO 预计，在项目的所有请求中，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": "98% requests under 100 ms"
}

以下示例 SLO 预计在一个滚动的一小时周期内，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 指标类型的列表。

可用性 SLI

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。以下示例 SLO 预计在一个滚动的一小时周期内，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": "98% requests under 100 ms"
}

Cloud Functions

Cloud Functions 是一个可扩缩的函数即服务产品，随用随付，无需管理任何基础架构即可运行代码。Functions 用于多种架构模式，可执行事件处理、自动化以及处理 HTTP/HTTPS 请求等操作。

如需了解 Cloud Functions 可观测性，请参阅以下内容：

• Cloud Functions 相关文档。
• run.googleapis.com 指标类型的列表。

可用性 SLI

Cloud Functions 使用 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 Functions 使用 cloud_function 受监控的资源类型和 function/execution_times 指标类型将指标数据写入 Cloud Monitoring。数据是函数执行时间分布（以纳秒为单位）。如果您需要明确衡量所有执行或仅成功执行的延迟时间，则可以使用 status 来过滤数据。

您可以使用 DistributionCut 结构来表示基于请求的延迟时间 SLI。以下示例 SLO 预计，在所有 Cloud Functions 执行中，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": "98% requests under 100 ms"
}

App Engine

App Engine 提供了全代管式无服务器平台来构建和运行应用。您可以选择两种环境，即标准环境或柔性环境；如需了解详情，请参阅选择 App Engine 环境。

如需详细了解 App Engine，请参阅以下内容：

• App Engine 相关文档。
• appengine.googleapis.com 指标类型的列表。

可用性 SLI

App Engine 使用 gae_app 受监控的资源类型和 http/server/response_count 指标类型将指标数据写入 Cloud Monitoring。您可以使用 response_code 指标标签统计“正常”响应次数和响应“总数”来过滤数据。

您可以通过为正常请求数与请求总数创建 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。以下示例 SLO 预计，在所有请求中，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": "98% requests under 100 ms"
}

GKE 和 Istio

Google Kubernetes Engine (GKE) 是 Google 提供的安全的代管式 Kubernetes 服务，支持四向自动扩缩和多集群。 Istio 是一种开源服务网格，可用于连接、保护、控制和观察服务。Istio 可以作为插件安装在 GKE 上 (Anthos Service Mesh)，也可以由开源项目中的用户安装。在这两种情况下，Istio 都提供出色的遥测，包括与网格管理的每项服务的流量、错误和延迟时间相关的信息。

如需查看 Istio 指标的完整列表，请参阅 istio.io 指标类型。

可用性 SLI

Istio 使用 service/server/request_count 指标类型和以下某个受监控的资源类型将指标数据写入 Cloud Monitoring：

• gce_instance
• istio_canonical_service
• k8s_container

您可以使用 response_code 指标标签统计“正常”请求数和请求“总数”来过滤数据。您还可以使用 destination_service_name 指标标签来统计特定服务的请求数。

您可以通过为正常请求数与请求总数创建 TimeSeriesRatio 结构，为在 Istio 服务网格管理的 GKE 上运行的服务表示基于请求的可用性 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：

• gce_instance
• istio_canonical_service
• k8s_container

您可以使用 response_code 指标标签统计 "good" and "total" requests. You can also use the 来过滤数据。您还可以使用“destination_service_name”统计特定服务的请求数来过滤数据。

您可以使用 DistributionCut 结构，为在 Istio 服务网格管理的 GKE 上运行的服务表示基于请求的延迟时间 SLI。以下示例 SLO 预计，在对 frontend 服务的所有请求中，99% 的请求在一个滚动的一小时周期内的总延迟时间介于 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": "98% requests under 100 ms"
}