在ASM中为应用服务启用SLO(1):服务等级目标SLO概览

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
简介: 服务等级目标 (SLO) 提供了一种形式化的方式来描述、衡量和监控微服务应用程序的性能、质量和可靠性。SLO 为应用开发和平台团队、运维团队提供了一个共享的质量基准,作为衡量服务水平质量以及持续改进的参考。SLO 由一个或多个服务等级指标 (SLI) 组成。使用 SLI 组合定义的 SLO 允许团队以更精确和相关的方式描述服务健康状况。阿里云服务网格ASM提供了开箱即用的基于服务等级目标SLO的监控和告警能力,用于监控应用服务之间调用的延迟和错误率特征。

服务等级指标(Service Level Indicator, SLI)是衡量服务健康状况的指标。服务等级目标 (Service Level Objectives, SLO) 是指服务等级的目标值或值范围,由服务等级指标 (SLI) 衡量。这意味着定义SLO 主要是为工作负载提供合理正确的SLI。


服务等级目标 (SLO) 提供了一种形式化的方式来描述、衡量和监控微服务应用程序的性能、质量和可靠性。SLO 为应用开发和平台团队、运维团队提供了一个共享的质量基准,作为衡量服务水平质量以及持续改进的参考。SLO 由一个或多个服务等级指标 (SLI) 组成。使用 SLI 组合定义的 SLO 允许团队以更精确和相关的方式描述服务健康状况。

比如以下SLO:

  • 每分钟平均qps > 100k/s
  • 99% 访问延迟 < 500ms
  • 99% 每分钟带宽 > 200MB/s


阿里云服务网格ASM提供了开箱即用的基于服务等级目标SLO的监控和告警能力,用于监控应用服务之间调用的延迟和错误率特征。


系列文章:

在ASM中为应用服务启用SLO(1):服务等级目标SLO概览

https://developer.aliyun.com/article/1114965

在ASM中为应用服务启用SLO(2):服务网格中的SLO定义

https://developer.aliyun.com/article/1115135

在ASM中为应用服务启用SLO(3):使用ASM定义应用服务级SLO

https://developer.aliyun.com/article/1115152

在ASM中为应用服务启用SLO(4):导入生成的规则到Prometheus中执行SLO

https://developer.aliyun.com/article/1115171

在ASM中为应用服务启用SLO(5):使用Grafana查看SLO

https://developer.aliyun.com/article/1115187


SLI 类型和合规目标

阿里云服务网格ASM支持以下类型的服务等级指标:

  • 服务可用性服务成功响应的时间比例, 对应的SLI插件类型为availability,http响应码为429以及以5xx(以5开头的状态码)会被判断为不可用。
  • 延迟时间:服务返回请求的响应所需的时间(以毫秒为单位), 对应的SLI插件类型为lantency,用户可自定义延迟上限,高于上限的响应会被判断为不合格。


除了定义服务等级指标之外, 您还需要定义希望从服务中实现的合规目标。一般来说,SLO 不应高于用户必要或有意义的内容。例如,如果您的用户无法分辨服务的延迟时间是 200 毫秒还是 600 毫秒,请使用更高的值作为 SLO 中的延迟时间阈值。

设置合规目标时,也需要考虑服务的最终用户要求。不同的应用服务所需的目标也会不同, 主要取决于客户对应用服务本身的实际可用性诉求。例如,有些非关键业务系统的目标可用性为 99%(每年大约 3 天的停机时间), 而关键服务的系统可能需要 99.999% 的可用性(每年约 5 分钟的停机时间)。

合规期

除了为 SLI 定义目标之外,SLO 还指定衡量 SLI 的时间段。例如,某一天内的 99% 可用性与一个月内的 99% 可用性不同。第一个 SLO 不允许 14 分钟以上的连续停机时间(24 小时 * 1%),而第二个 SLO 允许连续停机时间长达约 7 小时(30 天 * 1%)。


为简化定义, 目前支持的时间段有:7、14、28、30天。


错误预算

另一个重要的监控概念是错误预算。SLO 的错误预算表示服务在不违反SLO的情况下还能够承受的故障余量。因此,错误预算可以表示为 (1 - SLO)

例如, 定义如下:

  • SLI 错误:请求状态代码 >= 500
  • 期限:30天
  • SLO:99.9%
  • 错误预算:(100%-99.9%) = 0.1%
  • 30 天内的总请求数:10000
  • 允许的错误请求数:(10000 * 0.1%) = 10

如需要满足SLO的要求,每 30 天最多允许的错误请求数为10个。通过错误预算,可以帮助用户更好地规划和管理任务。例如需要部署一个新版本,如果错误预算即将消耗殆尽,则不宜在此时进行更新这样的有风险的操作;而当合规期即将结束,错误预算充足时,进行更新违反SLO的概率较低。

错误预算将会按照滚动窗口进行更新,滚动窗口时间跨度和合规期相同。错误预算≥0表示滚动窗口内SLO合规,而错误预算<0表示滚动窗口内SLO不合规。


燃烧率

燃烧率是错误预算的消耗速度。燃烧率等于当前错误率和期望的最大错误率的比值。假设合规期为30天:

  • 燃烧率为1意味着如果维持当前的错误率,整个合规期将消耗100%的错误预算(30天消耗全部错误预算)
  • 燃烧率为2意味着如果维持当前的错误率,整个合规期将消耗200%的错误预算(15天消耗全部错误预算)
  • 燃烧率为60意味着如果维持当前的错误率,整个合规期将消耗6000%的错误预算(12个小时消耗全部错误预算)

燃烧率越高意味着故障越严重,燃烧率对应制定告警规则至关重要,告警规则将基于燃烧率来触发告警。

告警规则


告警规则能够根据故障的严重程度,在故障发生时及时的发出不同等级的提醒,以在错误预算被过多消耗之前及时响应。

阿里云服务网格ASM基于多窗口多燃烧率告警策略来生成告警规则,适用于大多数场景。多燃烧率策略下,短时间内的高故障率和低故障率但是持续时间较长的故障才能触发告警,避免不必要的告警分散运维人员精力从而错过真正关键的问题。多窗口则能够在计算一段时间的故障率时同时设置一个短时间窗口,当短窗口内的故障率低于阈值时结束告警,保证当故障得到处理后,告警能够及时解除。

以设置30天的SLO为例,当1小时内错误预算消耗2%(即该小时内错误率高于阈值的14.4倍)或6小时内消耗5%(阈值的6倍)时会触发一个page级别告警;1天内错误预算消耗10%(阈值的3倍)或3天内错误预算消耗10%(阈值)时会触发一个ticket级别的告警。短窗口设置为1/12。假设在3天内错误率保持为阈值的两倍,在第三天故障解除,短窗口能够使得6小时后告警解除,否则告警会继续持续3天,即使期间没有任何故障发生。

相关文章
|
3月前
|
运维 Kubernetes 安全
利用服务网格实现全链路mTLS(一):在入口网关上提供mTLS服务
阿里云服务网格(Service Mesh,简称ASM)提供了一个全托管式的服务网格平台,兼容Istio开源服务网格,用于简化服务治理,包括流量管理和拆分、安全认证及网格可观测性,有效减轻开发运维负担。ASM支持通过mTLS提供服务,要求客户端提供证书以增强安全性。本文介绍如何在ASM入口网关上配置mTLS服务并通过授权策略实现特定用户的访问限制。首先需部署ASM实例和ACK集群,并开启sidecar自动注入。接着,在集群中部署入口网关和httpbin应用,并生成mTLS通信所需的根证书、服务器证书及客户端证书。最后,配置网关上的mTLS监听并设置授权策略,以限制特定客户端对特定路径的访问。
131 2
|
3月前
|
Prometheus Kubernetes 监控
打造无缝灾备新境界:运用服务网格ASM,将集群外服务无缝融入集群内服务,铸就高可用性坚盾!
【8月更文挑战第2天】随着微服务架构的应用,服务的高可用性变得至关重要。服务网格如阿里巴巴的ASM提供流量管理、服务发现等功能,支撑高可靠服务系统。本文介绍如何利用ASM实现集群外服务作为集群内服务的灾备方案,确保服务连续性。先决条件包括已部署ASM的Kubernetes集群环境及内外部的关键服务副本。通过定义服务条目、配置虚拟服务和目的地规则,可实现自动或手动故障转移。借助ASM的流量管理能力,确保服务高可用性和业务连续性。
52 10
|
3月前
|
Kubernetes 安全 数据安全/隐私保护
利用服务网格实现全链路mTLS(二):通过出口网关访问外部mTLS服务
阿里云服务网格(Service Mesh,简称ASM)提供了一个全托管式的服务网格平台,兼容Istio开源服务网格,简化服务治理,包括流量管理、服务间通信安全及网格可观测性。ASM出口网关统一管理网格内的出口流量,实现全链路加密通信与精细访问控制。本文介绍如何配置ASM出口网关以管理出口流量并发起mTLS通信,涉及配置ServiceEntry、创建出口网关、设置虚拟服务及目标规则等步骤,最终实现安全可控的mTLS服务访问。
149 3
|
3月前
|
Perl
如何利用服务网格ASM使用集群外服务做集群内服务的灾备
本文档指导您如何配置阿里云服务网格(ASM)以实现在多集群环境下,服务间的优先访问及故障转移策略。
114 2
|
6月前
|
存储 机器学习/深度学习 负载均衡
模型服务网格:云原生下的模型服务管理
模型服务网格:云原生下的模型服务管理
78528 11
模型服务网格:云原生下的模型服务管理
|
监控 安全 大数据
阿里服务的ASM、MSE和ARMS都有其各自的应用场景
阿里服务的ASM、MSE和ARMS都有其各自的应用场景
429 39
|
安全 数据安全/隐私保护 开发者
实现安全的服务通信:探索如何使用服务网格来确保服务间的安全通信
实现安全的服务通信:探索如何使用服务网格来确保服务间的安全通信
117 0
|
测试技术 Serverless
使用ASM管理Knative服务(5):在Knative on ASM中基于流量灰度发布服务
Knative on ASM提供了基于流量的灰度发布能力。当创建Knative服务时,Knative会自动为服务创建第一个修订版本Revision。此后当Knative服务的配置发生变化时,Knative都会创建一个新的修订版本。通过修改流量发往不同修订版本的分配比例,即可实现灰度发布功能。本文介绍如何在Knative on ASM中基于流量灰度发布服务。
242 0
使用ASM管理Knative服务(5):在Knative on ASM中基于流量灰度发布服务
|
自然语言处理 运维 监控
《云原生架构容器&微服务优秀案例集》——01 互联网——站酷 基于 ASM 解决多语言技术栈下服务管理难题,实现运维提效
《云原生架构容器&微服务优秀案例集》——01 互联网——站酷 基于 ASM 解决多语言技术栈下服务管理难题,实现运维提效
239 0
|
算法 Serverless 测试技术
使用ASM管理Knative服务(6):基于流量请求数实现服务自动扩缩容
Knative on ASM中提供了开箱即用、基于流量请求的自动扩缩容KPA(Knative Pod Autoscaler)功能。本文介绍如何基于流量请求数实现服务自动扩缩容。
7851 0
使用ASM管理Knative服务(6):基于流量请求数实现服务自动扩缩容