乐趣区

关于prometheus:如何配置-SLO

前言

无论是对外提供 IaaS PaaS SaaS 的云公司,还是提供信息技术服务的乙方公司,亦或是金融 制作等各行各业的数据中心、运维部门,咱们的一个十分重要的合同承诺或考核评估指标就是:SLA(即:Service-Level Agreement 服务等级协定)。

而真正落地实现 SLA 的精确测量,最广为人知的就是 Google 的 SRE 实践。

Google SRE SLO & SLA

在 Google,会明确辨别 SLO 和服务等级协定(SLA)。SLA 通常波及向服务用户承诺,即服务可用性 SLO 应在特定时间段内达到特定级别。如果不这样做,就会导致某种惩办。这可能是客户为该期间领取的服务订阅费的局部退款,或者收费增加的额定订阅工夫。SLO 不达标会挫伤到服务团队,因而他们将致力留在 SLO 内。如果您要向客户收取费用,则可能须要 SLA。

SLA 中的可用性 SLO 通常比外部可用性 SLO 更宽松。这能够用可用性数字示意:例如,一个月内可用性 SLO 为 99.9%,外部可用性 SLO 为 99.95%。或者,SLA 可能仅指定形成外部 SLO 的指标的子集。

如果 SLA 中的 SLO 与外部 SLO 不同(简直总是如此),则监控必须显式测量 SLO 达标状况。您心愿可能查看零碎在 SLA 日程期间的可用性,并疾速查看它是否仿佛有脱离 SLO 的危险。

您还须要对合规性进行精确测量,通常来自 Metrics、Tracing、Logging 剖析。因为咱们对付费客户有一组额定的任务(如 SLA 中所述),因而咱们须要将从他们那里收到的查问与其余查问离开进行度量。这是建设 SLA 的另一个益处 — 这是确定流量优先级的明确办法。

定义 SLA 的可用性 SLO 时,请留神将哪些查问视为非法查问。例如,如果客户因为公布了其挪动客户端的谬误版本而超出配额,则能够思考从 SLA 中排除所有 ” 超出配额 ” 的响应代码。

SLI

SLI 是通过认真定义的测量指标,它依据不同零碎特点确定要测量什么。

常见的 SLI 有:

  • 性能

    • 响应工夫 (latency)
    • 吞吐量 (throughput)
    • 申请量 (qps)
    • 实效性 (freshness)
  • 可用性

    • 运行工夫 (uptime)
    • 故障工夫 / 频率
    • 可靠性
  • 品质

    • 准确性 (accuracy)
    • 正确性 (correctness)
    • 完整性 (completeness)
    • 覆盖率 (coverage)
    • 相关性 (relevance)
  • 外部指标

    • 队列长度 (queue length)
    • 内存占用 (RAM usage)
  • 因素人

    • 响应工夫 (time to response)
    • 修复工夫 (time to fix)
    • 修复率 (fraction fixed)

SLO

SLO(服务等级指标)指定了服务所提供性能的一种冀望状态,服务提供者用它来指定零碎的预期状态。SLO 里不会提到,如果指标达不到会怎么样。

SLO 是用 SLI 来形容的,个别形容为:
比方以下 SLO:

  • 每分钟均匀 qps > 100 k/s
  • 99% 拜访提早 < 500ms
  • 99% 每分钟带宽 > 200MB/s

设置 SLO 时的指标依赖于零碎的不同状态(conditions),依据不同状态设置不同的 SLO:

总 SLO = service1.SLO1 weight1 + service2.SLO2 weight2 + …

为什么要有 SLO,设置 SLO 的益处是什么呢?

  • 对于客户而言,是可预期的服务质量,能够简化客户端的零碎设计
  • 对于服务提供者而言

    • 可预期的服务质量
    • 更好的取舍老本 / 收益
    • 更好的危险管制(当资源受限的时候)
    • 故障时更快的反馈,采取正确措施

SLA

 SLA = SLO + 结果

小结

  • SLI:服务等级指标,通过认真定义的测量指标
  • SLO:服务等级指标,总 SLO = service1.SLO1 weight1 + service2.SLO2 weight2 + …
  • SLA: 服务等级协定, SLA = SLO + 结果

如何配置 SLO

私有云常见 SLO

常见于通过 解决申请的服务或 API 提供的服务(如:对象存储 或 API 网关)

  • 错误率 (error rate) 计算的是服务返回给用户的 error 总数
  • 如果错误率大于 X%(如 0.5%),就算是服务 down 了,开始计算 downtime
  • 如果错误率继续超过 Y(如 5)分钟,这个 downtime 就会被计算在内
  • 间断性的小于 Y 分钟的 downtime 是不被计算在内的。

前端 Web 或 APP

前端用户体验 Apdex 指标

如果有前端 js 探针监控,或拨测监控,那么能够用前端用户体验 Apdex 作为 SLO。

Apdex 定义了一个性能规范,将应用程序用户分为三个组:

  • 称心、
  • 可容忍(个别)
  • 丧气(不称心)。

例如,作为前端应用程序的 SLO,您能够指定心愿 90% 的用户 Apdex 都是 称心

如,My WebApp Apdex 公式如下:

100% * (apps.web.actionCount.category:filter(eq(Apdex category,SATISFIED)):splitBy("My WebApp")) / (apps.web.actionCount.category:splitBy("My WebApp"))

前端 APP 无解体(Crash)用户率指标

掂量手机 App (iOS 和 Android) 的可用性和可靠性的最重要指标之一是 无解体用户率。指的是没有解体的状况下关上并应用挪动 APP 的用户百分比。

因而,公式示例如下:

apps.other.crashFreeUsersRate.os:splitBy("My mobile app")

拨测可用性指标

拨测可用性 SLO 示意拨测处于可用状态下的工夫百分比,或者,胜利拨测占执行的总测试数的百分比。

因而,公式示例为:

(synthetic.browser.availability.location.total:splitBy("My WebApp"))

后端利用 或 Service

根本的 SLO – 调用成功率指标

成功率 = 胜利的申请调用次数 / 总的申请调用次数

如:My service 的 成功率:

100% * (service.requestCount.successCount:splitBy("My service"))/(service.requestCount.totalCount:splitBy("My service"))

那么,如果 My service 的要害 API 或申请须要计量,就可能是上面的公式:

(100%)*(service.keyRequest.successCount:splitBy(type("SERVICE_API") AND entityId("POST /login")))/(service.keyRequest.totalCount:splitBy(type("SERVICE_API") AND entityId("POST /login")))

ℹ️ 提醒:

胜利 的申请最简略的一种形式是:http 状态码为 2xx 或 3xx 的申请即视为胜利。

还有一种,申请执行过程中没有抛出谬误(日志或异样)的申请视为胜利。

服务性能指标

重点在于 性能

服务性能 SLO 示意「fast」服务调用占服务调用总数的百分比,其中「fast」应用自定义条件定义。例如:

  • fast:0 – 3s 内实现服务调用()
  • normal:3 – 5s 内实现服务调用
  • slow:5s 以上实现服务调用或超时

ℹ️ 提醒:

当然,上边的 3s 也不应该是拍脑袋想的,而应该是例如基于过来一个月零碎失常运行时 99% 百分位数的响应工夫。

公式示例为:

(service:fastRequests:splitBy("My WebApp")) / (service:totalRequests:splitBy("My WebApp"))

后端数据库

数据库可用性或读可用性指标

错误率:是在给定的一小时距离内,DB 的失败 SQL 执行次数除以总 SQL 执行次数。

读错误率:是在给定的一小时距离内,DB 的失败查问 SQL 执行次数除以总 SQL 执行次数。

公式示例为:

可用性 % = 100% - Average DB Error Rate

或:

读可用性 % = 100% - Average DB Read Error Rate

吞吐量指标

  • 吞吐量失败的申请:是指申请尚未超过给定 DB 吞吐量,却被 DB 吞吐量限度,导致错误码
  • 吞吐量错误率:是在给定的一小时距离内,给定 DB 的吞吐量失败申请总数除以总申请数。

那么,公式示例为:

吞吐量指标 % = 100% - 均匀吞吐量错误率

一致性指标

SLI 为:

一致性违规率 :是指在给定的 DB 中,在给定的一小时距离内,对所选的一致性级别(按总申请数划分) 执行一致性保障时无奈发送的胜利申请。

提早指标

  • P99 提早:计算出的一段时间内的测试 SQL(如select 1 from dual) 执行工夫的 99% 百分位响应工夫。
  • 延迟时间和:是指在应用程序提交的 SQL 胜利申请导致 P99 提早大于或等于 10ms 的一个小时距离的总数。

那么,示例公式为:

提早指标 % = 100% - 总的延迟时间和的次数 / (DB 总应用工夫 /1H)

如:过来 1 个月,总的延迟时间和的次数为 50 次,分母为:30 * 24 / 1 = 720

那么:提早指标 % = 100% - 50 / 720 ≈ 93%

MQ 类

音讯成功率指标

就是胜利的音讯除以 MQ 接管的总音讯。

公式示例为:

(100)*((mq.rabbitmq.queue.requests.successful:splitBy("payment"))/mq.rabbitmq.queue.requests.incoming:splitBy("payment")))

Host 类

UPTIME 指标

例如,每小时失常运行工夫百分比 = 100% – 单个 Host 实例处于不可用状态的总工夫(没有超过多长时间才算不可用一说)百分比

不可用的定义能够是:

  • 该 Host 实例没有网络连接
  • 该 Host 实例 无奈执行读写 IO,且 IO 在队列中挂起。即 IO hang。

K8S 类

K8S 类是一类综合零碎,须要思考如下指标

  • API Server 成功率指标
  • 计算指标
  • 存储指标
  • 网络指标

存储类

可用性(Availability)指标

大抵也是相似上边的可用性指标。

数据持久性(Durability)指标

这个通常十分高,比方:99.999999999%

能够简略粗犷认为:只有有数据失落的状况,就是没达到目标。

典型案例就是腾讯的那次。

网络类

可用性指标

以 NAT 网关为例:

单实例服务不可用分钟数:当某一分钟内,NAT 网关实例出方向所有数据包都被 NAT 网关抛弃时,则视为该分钟内该 NAT 网关实例服务不可用。在一个服务周期内 NAT 网关实例不可用分钟数之和即服务不可用分钟数。

总结

能够依据不同的档次、组件设定不同的 SLO。

SLO 的监测是须要监控工具的反对。

罕用的 SLO 包含:

  • 可用性(Availability)指标
  • 成功率(Success Rate)指标
  • 提早 (Latency) 指标
  • 运行工夫 (Uptime) 指标
  • 数据持久性(Durability)指标

EOF

退出移动版