「译文」使用 Prometheus 和 Grafana 实现 SLO

本文涉及的产品
可观测可视化 Grafana 版,10个用户账号 1个月
简介: 「译文」使用 Prometheus 和 Grafana 实现 SLO

👉️URL: https://engineering.bitnami.com/articles/implementing-slos-using-prometheus.html

📝Author:

JuanJo Ciarlante 发表 于 2018 年 10 月 4 日

在线服务应旨在提供符合业务需求的服务可用性。这个过程的一个关键部分应该涉及组织中的不同团队,例如,从业务开发团队到工程团队。

为了验证服务如何符合这些目标,应该可以定义具有可衡量的「阈值」,例如,「服务必须在 99.9% 的时间内可用」,这反过来应该符合用户的期望和业务连续性。

SLA、SLO、SLI

已经有很多关于主题的文章:

如果您不熟悉这些术语,我强烈建议您先阅读 Google 的 SRE 书中关于服务级别目标 的文章 。

总之:

  • SLA:服务等级协议
  • 您承诺向用户提供何种服务,如果您无法满足,可能会受到处罚。
  • 示例:“99.5%”可用性。
  • 关键词:合同
  • SLO:服务等级目标
  • 您在内部设置的目标,推动您的测量阈值(例如,在仪表板和警报上)。通常,它应该比您的 SLA 更严格。
  • 示例:“99.9%”可用性(所谓的“三个 9”)。
  • 关键词:阈值
  • SLI:服务等级指标
  • 您实际测量的内容,以断言您的 SLO 是否符合 / 偏离目标。
  • 示例:错误率、延迟
  • 关键词:指标

SLO 正当时

那么 99% 可用性是什么意思呢?- 这 不是 1% 的错误率(失败的 HTTP 响应百分比), 而是 在预定义的时间段内服务可用的时间百分比。

SLO grafana 仪表板截图

在上面的仪表板中,该服务在 1 小时内的错误率超过 0.1%(y 轴为 0.001)(错误尖峰顶部的红色小水平段),从而提供 99.4% 的 7 天的可用性:

SLO 公式示例

此结果的一个关键因素是您选择衡量可用性的时间跨度(在上例中为 7 天)。较短的时间段通常用作所涉及的工程团队(例如,SRE 和 SWE)的检查点,以跟踪服务的运行情况,而较长的时间段通常用于组织 / 更广泛的团队的审查目的。

例如,如果您设置了99.9%SLO,则服务可以关闭的总时间如下:

  • 30 天内:43 分钟(3/4 小时)
  • 90 天内:129 分钟(约 2 小时)

另一个微不足道的“数字事实”是向 SLO 添加额外的 9 具有明显的指数影响。请参阅以下总时间跨度为 1 年的 时间段:

  • 2 个 9: 99%: 5250min (87hrs or 3.64days)
  • 3 个 9: 99.9%: 525min (8.7hrs)
  • 4 个 9: 99.99%: 52.5min
  • 5 个 9:99.999%5 分钟

输入错误预算(ERROR BUDGETS)

服务可以关闭的允许时间的上述数字可以被认为是 错误预算(error budget),您可以在以下事件中消耗它:

  • 计划中的维护
  • 失败的升级
  • 意外中断

实际结果是,上述任何一项都会消耗您的服务的 错误预算,例如,意外中断可能会耗尽它,以至于在该时间段内阻止进一步的维护工作。

SLI 关键词是 指标

从上面可以清楚地看出,我们必须有服务指标来告诉我们服务何时被认为(不)可用。有几种方法可以解决这个问题:

  • RED : Rate(比率), Errors(错误), Duration(时长) - 由 @tom_wilkie 引入
  • USE : Utilization(利用率), Saturation(饱和度), and Errors(错误) - 由 @brendangregg 引入

SLO 实施示例

让我们举一个具体的例子,遵循 RED 方法(因为我们已经拥有的指标更适合这种方法):通过通常用于监控目的的工具,创建警报和仪表板以支持 Kubernetes API 的目标 SLO:PrometheusGrafana

此外,我们将使用 jsonnet 来构建我们的规则和仪表板文件,利用现有的 library helpers。

本文不解释如何在您的服务超出阈值时发出信号,而是重点介绍如何 记录 服务处于此条件下 的时间

本文的其余部分将重点介绍创建 Prometheus 规则以根据特定指标 (SLI) 的阈值捕获“SLO 超时”。

定义 SLO 目标和指标阈值

让我们定义一个简单的目标:

  • SLO : 99%,来自以下内容:
  • SLI
  • 错误率低于 1%
  • 90 百分位数 (90th percentile)的请求的延迟低于 200ms

将规范写为 jsonnet:

slo:: {
  target: 0.99,
  error_ratio_threshold: 0.01,
  latency_percentile: 90,
  latency_threshold: 200,
},
JSONNET

查找 SLI

Kubernetes API 公开了几个我们可以用作 SLI 的指标,在短时间内(这里我们选择 5 分钟,这个数字应该是抓取间隔的几倍)使用 Prometheus 函数 rate()

  • apiserver_request_count: 按verb, code, 计算所有请求resource,例如获取最近 5 分钟的总错误率:
sum(rate(apiserver_request_count{code=~"5.."}[5m]))
 /
sum(rate(apiserver_request_count[5m]))
PROMQL
  • 上面的公式会丢弃所有指标标签(例如,http 的 verb, code)。如果要保留一些标签,则需要执行类似于以下操作:
sum by (verb, code) (rate(apiserver_request_count{code=~"5.."}[5m]))
  / ignoring (verb, code) group_left
sum (rate(apiserver_request_count[5m]))
PROMQL
  • apiserver_request_latencies_bucket:不同 verb 的延迟直方图。例如,要获得以毫秒为单位的第 90 个延迟百分位数:(注意le “小于或等于”标签是特殊的,因为它设置了直方图桶间隔):
histogram_quantile (
  0.90,
  sum by (le, verb, instance)(
    rate(apiserver_request_latencies_bucket[5m])
  )
) / 1e3
PROMQL

了解更多信息:

编写 Prometheus 规则以记录所选的 SLI

PromQL 是一个非常强大的语言,但截至 2018 年 10 月,它还不支持嵌套子查询的范围(详见普罗米修斯问题 1227),我们需要一个功能,能够计算 time ratioerror ratiolatency

此外,作为一种良好的做法,为了降低 查询时 Prometheus 资源的使用,建议始终将 记录规则(recording rules) 添加到预先计算的表达式中,例如sum(rate(...))

作为如何执行此操作的示例,以下记录规则集是从我们的 bitnami-labs/kubernetes-grafana-dashboards 存储库构建的,以捕获上述内容time ratio

  • 创建一个新 kubernetes:job_verb_code_instance:apiserver_requests:rate5m 指标来记录 请求率
record: kubernetes:job_verb_code_instance:apiserver_requests:rate5m
expr: |
  sum by(job, verb, code, instance) (rate(apiserver_request_count[5m]))
YAML
  • 使用上述指标,为 请求比率(超过总数)创建一个新的kubernetes:job_verb_code_instance:apiserver_requests:ratio_rate5m
record: kubernetes:job_verb_code_instance:apiserver_requests:ratio_rate5m
expr: |
  kubernetes:job_verb_code_instance:apiserver_requests:rate5m
    / ignoring(verb, code) group_left()
  sum by(job, instance) (
    kubernetes:job_verb_code_instance:apiserver_requests:rate5m
  )
YAML
  • 使用上述比率指标(基于每个 http 的 codeverb),创建一个新指标来捕获 错误率
record: kubernetes:job:apiserver_request_errors:ratio_rate5m
expr: |
  sum by(job) (
    kubernetes:job_verb_code_instance:apiserver_requests:ratio_rate5m
      {code=~"5..",verb=~"GET|POST|DELETE|PATCH"}
  )
YAML
  • 使用上述错误率(以及其他类似创建过去 5 分钟内记录的第 90 个百分位延迟kubernetes::job:apiserver_latency:pctl90rate5m,为简单起见未在上面显示),最后创建一个布尔指标来记录我们的 SLO 违例:
record: kubernetes::job:slo_kube_api_ok
expr: |
  kubernetes:job:apiserver_request_errors:ratio_rate5m < bool 0.01
    *
  kubernetes::job:apiserver_latency:pctl90rate5m < bool 200
YAML

编写 Prometheus 警报规则

上述 kubernetes::job:slo_kube_api_ok 最终指标对于仪表板和考虑 SLO 合规性非常有用,但我们应该报警上述哪个指标正在推动 SLO,如下面的 Prometheus 警报规则所示:

  • 高 API 错误率警报:
alert: KubeAPIErrorRatioHigh
expr: |
  sum by(instance) (
    kubernetes:job_verb_code_instance:apiserver_requests:ratio_rate5m
      {code=~"5..",verb=~"GET|POST|DELETE|PATCH"}
  ) > 0.01
for: 5m
YAML
  • 高 API 延迟警报
alert: KubeAPILatencyHigh
expr: |
  max by(instance) (
    kubernetes:job_verb_instance:apiserver_latency:pctl90rate5m
      {verb=~"GET|POST|DELETE|PATCH"}
  ) > 200
for: 5m
YAML

请注意,Prometheus 规则取自已显示的 jsonnet 输出,可在 bitnami-labs/kubernetes-grafana-dashboards 中找到,阈值分别从 $.slo.error_ratio_threshold$.slo.latency_threshold 评估。

以编程方式创建 Grafana 仪表板

创建 Grafana 仪表板通常是通过与 UI 交互来完成的。这对于简单和 / 或“标准”仪表板(例如,从 https://grafana.com/dashboards 下载)很好 ,但如果您想实施最佳 devops 实践,尤其是对于 gitops 工作流,则会变得很麻烦。

社区正在通过各种努力解决这个问题,例如用于 jsonnetpythonJavascript的 Grafana 库。鉴于我们的 jsonnet 实现,我们选择了 grafonnet-lib

使用 jsonnet 设置我们的 SLO 阈值和编码我们的 Prometheus 规则的一个非常有用的结果是,我们可以重用这些来构建我们的 Grafana 仪表板,而无需复制和粘贴它们。

例如:

  • $.slo.error_ratio_threshold在我们的 Grafana 仪表板中引用来设置 Grafana 图形面板的 thresholds 属性,就像我们上面为我们的 Prometheus 警报规则所做的那样。
  • 通过参考 jsonnet 摘录创建的 Prometheus 记录规则,请注意metric.rules.requests_ratiorate_job_verb_code.record 用法(而不是逐字记录'kubernetes:job_verb_code_instance:apiserver_requests:ratio_rate5m'):
// Graph showing all requests ratios
req_ratio: $.grafana.common {
  title: 'API requests ratios',
  formula: metric.rules.requests_ratiorate_job_verb_code.record,
  legend: '{{ verb }} - {{ code }}',
},
JSONNET

您可以在 dash-kubeapi.jsonnet 阅读我们的实现,以下是生成的仪表板的屏幕截图:

SLO Grafana 仪表板屏幕截图

把这一切放在一起

我们在 bitnami-labs/kubernetes-grafana-dashboards 文件夹下的 bitnami-labs/kubernetes-grafana-dashboards 存储库中实现了上述 jsonnet 想法。

我们构建的 Prometheus 规则和 Grafana 仪表板文件是从 jsonnet 源生成的,如下所示:

SLO jsonnet 工作流程

  • spec-kubeapi.jsonnet:尽可能多的纯数据 规范(阈值、规则和仪表板公式)

自从我们开始这个项目以来,社区已经创建了许多其他有用的 Prometheus 规则。查看 srecon17_americas_slides_wilkinson.pdf 了解更多信息。如果我们不得不从头开始,我们可能会将 kubernetes-mixinjsonnet-bundler 一起使用。


相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
云原生实践公开课
课程大纲 开篇:如何学习并实践云原生技术 基础篇: 5 步上手 Kubernetes 进阶篇:生产环境下的 K8s 实践 相关的阿里云产品:容器服务&nbsp;ACK 容器服务&nbsp;Kubernetes&nbsp;版(简称&nbsp;ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情:&nbsp;https://www.aliyun.com/product/kubernetes
相关文章
|
2月前
|
存储 Prometheus Cloud Native
「译文」Grafana Loki 简要指南:关于标签您需要了解的一切
「译文」Grafana Loki 简要指南:关于标签您需要了解的一切
|
2月前
|
存储 Prometheus Kubernetes
「译文」通过 Relabel 减少 Prometheus 指标的使用量
「译文」通过 Relabel 减少 Prometheus 指标的使用量
|
2月前
|
存储 Prometheus Kubernetes
「译文」Prometheus 中的 relabel 是如何工作的?
「译文」Prometheus 中的 relabel 是如何工作的?
|
3月前
|
Prometheus Cloud Native Java
微服务框架(二十三)Prometheus + Grafana 安装、配置及使用
此系列文章将会描述Java框架Spring Boot、服务治理框架Dubbo、应用容器引擎Docker,及使用Spring Boot集成Dubbo、Mybatis等开源框架,其中穿插着Spring Boot中日志切面等技术的实现,然后通过gitlab-CI以持续集成为Docker镜像。 本文为Prometheus + Grafana 安装、配置及使用 本系列文章中所使用的框架版本为Spring ...
|
2月前
|
存储 Prometheus Cloud Native
Grafana 系列 - 统一展示 -2-Prometheus 数据源
Grafana 系列 - 统一展示 -2-Prometheus 数据源
|
2月前
|
JSON Prometheus Cloud Native
Grafana 系列 - 统一展示 -3-Prometheus 仪表板
Grafana 系列 - 统一展示 -3-Prometheus 仪表板
|
2月前
|
Prometheus 监控 Cloud Native
使用 Prometheus 配置 SLO 监控和告警
使用 Prometheus 配置 SLO 监控和告警
|
2月前
|
Prometheus Cloud Native
「译文」如何使用 PromQL join 来更有效地查询大规模的 Prometheus 指标
「译文」如何使用 PromQL join 来更有效地查询大规模的 Prometheus 指标
|
2月前
|
存储 Prometheus Cloud Native
「译文」Prometheus 查询语言 PromQL 简介
「译文」Prometheus 查询语言 PromQL 简介
|
3月前
|
编解码 Prometheus 运维
Prometheus 的监控方法论
【1月更文挑战第24天】