关于prometheus:如何配置-SLO

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

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

在 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 有：

性能
- 响应工夫 (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 是用 SLI 来形容的，个别形容为：
比方以下 SLO：

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

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

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

为什么要有 SLO，设置 SLO 的益处是什么呢？

对于客户而言，是可预期的服务质量，能够简化客户端的零碎设计
对于服务提供者而言
- 可预期的服务质量
- 更好的取舍老本 / 收益
- 更好的危险管制(当资源受限的时候)
- 故障时更快的反馈，采取正确措施

 SLA = SLO + 结果

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

常见于通过解决申请的服务或 API 提供的服务（如：对象存储或 API 网关）

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

如果有前端 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 (iOS 和 Android) 的可用性和可靠性的最重要指标之一是 无解体用户率。指的是没有解体的状况下关上并应用挪动 APP 的用户百分比。

因而，公式示例如下：

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

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

因而，公式示例为：

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

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

如：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 接管的总音讯。

公式示例为：

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

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

不可用的定义能够是：

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

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

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

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

这个通常十分高，比方：99.999999999%

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

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

以 NAT 网关为例：

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

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

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

罕用的 SLO 包含：

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

EOF

关于prometheus:如何配置-SLO

前言

Google SRE SLO & SLA

SLI

SLO

SLA

小结

如何配置 SLO

私有云常见 SLO

前端 Web 或 APP

前端用户体验 Apdex 指标

前端 APP 无解体（Crash）用户率指标

拨测可用性指标

后端利用或 Service

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

服务性能指标

后端数据库

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

吞吐量指标

一致性指标

提早指标

MQ 类

音讯成功率指标

Host 类

UPTIME 指标

K8S 类

存储类

可用性（Availability）指标

数据持久性（Durability）指标

网络类

可用性指标

总结

前言

Google SRE SLO & SLA

SLI

SLO

SLA

小结

如何配置 SLO

私有云常见 SLO

前端 Web 或 APP

前端用户体验 Apdex 指标

前端 APP 无解体（Crash）用户率指标

拨测可用性指标

后端利用 或 Service

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

服务性能指标

后端数据库

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

吞吐量指标

一致性指标

提早指标

MQ 类

音讯成功率指标

Host 类

UPTIME 指标

K8S 类

存储类

可用性（Availability）指标

数据持久性（Durability）指标

网络类

可用性指标

总结

后端利用或 Service