本页面介绍 Cloud Load Balancing 提供的负载平衡器类型，并介绍如何将 Cloud Load Balancing 公开的 Cloud Monitoring 指标用作 SLI。
Cloud Load Balancing 服务通常会为 Google Cloud 中托管的应用提供第一个入口点。负载平衡器会自动进行插桩，从而提供有关它们所公开的 Google Cloud 服务的流量、可用性和延迟时间的信息；因此，负载平衡器通常充当出色的 SLI 指标来源，而无需应用插桩。
开始使用时，您可以选择重点将可用性和延迟时间作为可靠性的主要维度，并创建 SLI 和 SLO 来测量这些维度并发出提醒。本页面提供了实现示例。
如需了解详情，请参阅以下内容：
可用性 SLI 和 SLO
对于非 UDP 应用，基于请求的可用性 SLI 是最合适的，因为服务交互与请求完全对应。
您可以通过使用 TimeSeriesRatio 结构设置正常请求数与请求总数的比率来表示基于请求的可用性 SLI，如以下可用性示例所示。如需获得“正常”或“有效”最佳确定结果，您可以使用可用标签过滤指标。
外部第 7 层 (HTTP/S) 负载均衡器
HTTP/S 负载均衡器用于公开通过 HTTP/S 访问的应用，以及将流量分配到位于多个区域的资源。
外部应用负载均衡器使用 https_lb_rule 受监控的资源类型和前缀为 loadbalancing.googleapis.com 的指标类型将指标数据写入 Monitoring。与可用性 SLO 最相关的指标类型是 https/request_count，您可以使用 response_code_class 指标标签对其进行过滤。
如果您选择不将导致 4xx 错误响应代码的请求计为“有效”请求（原因是这些请求可能指示客户端错误，而不是服务或应用错误），则可以针对请求“总数”编写如下所示的过滤条件：
"totalServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/request_count\"
resource.type=\"https_lb_rule\"
resource.label.\"url_map_name\"=\"my-app-lb\"
metric.label.\"response_code_class\"!=\"400\"",
您还需要确定如何统计“正常”请求数。 例如，如果您选择仅统计返回 200 OK 成功状态响应代码的请求数，则可以针对“正常”请求编写如下所示的过滤条件：
"goodServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/request_count\"
resource.type=\"https_lb_rule\"
resource.label.\"url_map_name\"=\"my-app-lb\"
metric.label.\"response_code_class\"=\"200\"",
然后，您可以如下所示表示基于请求的 SLI：
"serviceLevelIndicator": {
"requestBased": {
"goodTotalRatio": {
"totalServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/request_count\"
resource.type=\"https_lb_rule\"
resource.label.\"url_map_name\"=\"my-app-lb\"
metric.label.\"response_code_class\"!=\"400\"",
"goodServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/request_count\"
resource.type=\"https_lb_rule\"
resource.label.\"url_map_name\"=\"my-app-lb\"
metric.label.\"response_code_class\"=\"200\"",
}
}
},
对于由多个后端提供流量的应用，您可以选择为特定后端定义 SLI。要为特定后端创建可用性 SLI，请在过滤条件中使用 https/backend_request_count 指标和 backend_target_name 资源标签，如以下示例所示：
"serviceLevelIndicator": {
"requestBased": {
"goodTotalRatio": {
"totalServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/backend_request_count\"
resource.type=\"https_lb_rule\"
resource.label.\"url_map_name\"=\"my-app-lb\"
resource.label.\"backend_target_name\"=\"my-app-backend\"
metric.label.\"response_code_class\"!=\"400\"",
"goodServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/backend_request_count\"
resource.type=\"https_lb_rule\" resource.label.\"url_map_name\"=\"my-app-lb\"
resource.label.\"backend_target_name\"=\"my-app-backend\"
metric.label.\"response_code_class\"=\"200\"",
}
}
}
内部第 7 层 (HTTP/S) 负载均衡器
内部应用负载均衡器使用 internal_http_lb_rule 受监控的资源类型和前缀为 loadbalancing.googleapis.com 的指标类型将指标数据写入 Monitoring。与可用性 SLO 最相关的指标类型是 https/internal_request_count，您可以使用 response_code_class 指标标签对其进行过滤。
下面展示了一个基于请求的可用性 SLI 的示例：
"serviceLevelIndicator": {
"requestBased": {
"goodTotalRatio": {
"totalServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/internal/request_count\"
resource.type=\"internal_http_lb_rule\"
resource.label.\"url_map_name\"=\"my-internal-lb\"
metric.label.\"response_code_class\"!=\"400\"",
"goodServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/internal/request_count\"
resource.type=\"internal_http_lb_rule\"
resource.label.\"url_map_name\"=\"my-internal-lb\"
metric.label.\"response_code_class\"=\"200\"",
}
}
},
第 3 层 (TCP) 负载均衡器
TCP 负载均衡器不提供请求指标，因为使用请求指标的应用可能并非基于请求响应模型。这些负载均衡器提供的所有 loadbalancing.googleapis.com 指标均不适合良好的可用性 SLI。
如需为这些负载均衡器创建可用性 SLI，您必须创建自定义指标或基于日志的指标。如需了解详情，请参阅使用自定义指标或使用基于日志的指标。
延迟时间 SLI 和 SLO
对于请求响应应用，您可以通过以下两种方式编写延迟时间 SLO：
- 按照基于请求的 SLO。
- 按照基于时间段的 SLO。
基于请求的延迟时间 SLO
基于请求的 SLO 会应用延迟时间阈值，并计算给定合规期内完成时间低于阈值的请求所占比例。基于请求的 SLO 的一个示例是“在一个滚动的一小时时间段内，99% 的请求在 100 毫秒内完成”。
您可以通过使用 DistributionCut 结构来表示基于请求的延迟时间 SLI，如以下延迟时间示例所示。
单个基于请求的 SLO 无法捕获典型的性能和用户体验降低，因此“尾”请求或速度最慢的请求会导致响应时间越来越长。典型性能的 SLO 不支持理解尾延迟时间。如需了解尾延迟时间，请参阅站点可靠性工程的第 6 章：监控分布式系统中的“担心您的尾延迟时间”部分。
为了缓解此限制的影响，您可以再编写一个 SLO，专门侧重于尾延迟时间，例如“在一个滚动的一小时时间段内，99.9% 的请求不到 1000 毫秒完成”。同时使用两个 SLO 可捕获典型用户体验和尾延迟时间的降低。
基于时间段的延迟时间 SLO
基于时间段的 SLO 为测量时间段定义良好标准，并计算“良好”时间间隔与间隔总数的比率。基于时间段的 SLO 的示例是“在一个 28 天的滚动时间段内，在一分钟时间段至少 99% 的时间内，第 95 百分位延迟时间指标不到 100 毫秒”：
- 一个“良好”的测量周期为一分钟，其中 95% 的请求的延迟时间不到 100 毫秒。
- 合规性的测量是指此“良好”周期所占的比例。在合规期内，如果此比例至少为 0.99，则该服务合规。
如果您可以使用的原始指标是延迟时间百分位，则必须使用基于时间段的 SLO；也就是说，当同时满足以下两个条件时：
- 数据归于不同的时间段（例如，归于 1 分钟的时间间隔）。
- 数据以百分位组（例如 p50、p90、p95、p99）表示。
对于这种类型的数据，每个百分位组指明了高于和低于相应百分位划分数据组的时间。例如，p95 延迟时间指标为 89 毫秒的一分钟时间间隔表示服务在一分钟内响应 95% 的请求的时间为 89 毫秒或更少。
外部应用负载均衡器
外部应用负载均衡器使用以下主要指标类型来捕获延迟时间：
https/total_latencies：从代理收到请求开始到代理在最后一个响应字节上从客户端收到 ACK 为止计算的延迟时间分布。当注重整体用户体验时使用此指标。https/backend_latencies：从代理将请求发送到后端到代理从后端接收到响应的最后一个字节开始计算延迟时间的分布。用于测量在负载均衡器之后提供流量的特定后端的延迟时间。
这些指标是针对 https_lb_rule 受监控的资源类型编写的。
总延迟时间
此示例 SLO 预计在一个滚动的一小时周期内，99% 请求的总延迟时间介于 0 到 100 毫秒之间。
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/https/total_latencies\"
resource.type=\"https_lb_rule\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}
后端延迟时间
此示例 SLO 预计在一个滚动的一小时周期内，98% 针对“my-app-backend”后端目标的请求的总延迟时间介于 0 到 100 毫秒之间。
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/https/backend_latencies\"
resource.type=\"https_lb_rule\"
resource.label.\"backend_target_name\"=\"my-app-backend\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.98,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}
内部应用负载均衡器
内部应用负载均衡器使用以下两种主要指标类型来捕获延迟时间：
https/internal/total_latencies：从代理收到请求开始到代理在最后一个响应字节上从客户端收到 ACK 为止计算的延迟时间分布。当注重整体用户体验时使用此指标。https/internal/backend_latencies：从代理将请求发送到后端到代理从后端接收到响应的最后一个字节开始计算延迟时间的分布。用于测量在负载均衡器之后提供流量的特定后端的延迟时间。
这些指标是针对 internal_http_lb_rule 受监控的资源类型编写的。
总延迟时间
此示例 SLO 预计在一个滚动的一小时周期内，99% 请求的总延迟时间介于 0 到 100 毫秒之间：
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/https/internal/total_latencies\"
resource.type=\"internal_http_lb_rule\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}
此示例 SLO 预计在一个滚动的一小时周期内，99% 请求的总延迟时间介于 0 到 100 毫秒之间。
后端延迟时间
此示例 SLO 预计在一个滚动的一小时周期内，98% 针对“my-internal-backend”后端目标的请求的总延迟时间介于 0 到 100 毫秒之间。
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/https/internal/backend_latencies\"
resource.type=\"https_lb_rule\"
resource.label.\"backend_target_name\"=\"my-internal-backend\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.98,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}
外部第 3 层 (TCP) 负载均衡器
外部 TCP 负载平衡器使用单个指标类型 l3/external/rtt_latencies，该指标类型记录在外部负载平衡器流中通过 TCP 连接测量的往返时间分布。
此指标是针对 tcp_lb_rule 资源编写的。
此示例 SLO 预计在一个滚动的一小时周期内，99% 请求的总延迟时间介于 0 到 100 毫秒之间：
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/l3/external/rtt_latencies\"
resource.type=\"tcp_lb_rule\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}
内部第 3 层 (TCP) 负载均衡器
内部 TCP 负载平衡器使用单个指标类型 l3/internal/rtt_latencies，该指标类型记录在内部负载平衡器流中通过 TCP 连接测量的往返时间分布。
此指标是针对 internal_tcp_lb_rule 资源编写的。
此示例 SLO 预计在一个滚动的一小时周期内，99% 请求的总延迟时间介于 0 到 100 毫秒之间：
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/l3/internal/rtt_latencies\"
resource.type=\"internal_tcp_lb_rule\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}