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

本文最后更新于:2024年7月24日 晚上

👉️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:

1
2
3
4
5
6
slo:: {
target: 0.99,
error_ratio_threshold: 0.01,
latency_percentile: 90,
latency_threshold: 200,
},

查找 SLI

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

  • apiserver_request_count: 按verb, code, 计算所有请求resource,例如获取最近 5 分钟的总错误率:

    1
    2
    3
    sum(rate(apiserver_request_count{code=~"5.."}[5m]))
    /
    sum(rate(apiserver_request_count[5m]))
  • 上面的公式会丢弃所有指标标签(例如,http 的 verb, code)。如果要保留一些标签,则需要执行类似于以下操作:

    1
    2
    3
    sum by (verb, code) (rate(apiserver_request_count{code=~"5.."}[5m]))
    / ignoring (verb, code) group_left
    sum (rate(apiserver_request_count[5m]))
  • apiserver_request_latencies_bucket:不同 verb 的延迟直方图。例如,要获得以毫秒为单位的第 90 个延迟百分位数:(注意le “小于或等于”标签是特殊的,因为它设置了直方图桶间隔):

    1
    2
    3
    4
    5
    6
    histogram_quantile (
    0.90,
    sum by (le, verb, instance)(
    rate(apiserver_request_latencies_bucket[5m])
    )
    ) / 1e3

了解更多信息:

编写 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 指标来记录 请求率

    1
    2
    3
    record: kubernetes:job_verb_code_instance:apiserver_requests:rate5m
    expr: |
    sum by(job, verb, code, instance) (rate(apiserver_request_count[5m]))
  • 使用上述指标,为 请求比率(超过总数)创建一个新的kubernetes:job_verb_code_instance:apiserver_requests:ratio_rate5m

    1
    2
    3
    4
    5
    6
    7
    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
    )
  • 使用上述比率指标(基于每个 http 的 codeverb),创建一个新指标来捕获 错误率

    1
    2
    3
    4
    5
    6
    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"}
    )
  • 使用上述错误率(以及其他类似创建过去 5 分钟内记录的第 90 个百分位延迟kubernetes::job:apiserver_latency:pctl90rate5m,为简单起见未在上面显示),最后创建一个布尔指标来记录我们的 SLO 违例:

    1
    2
    3
    4
    5
    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

编写 Prometheus 警报规则

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

  • 高 API 错误率警报:

    1
    2
    3
    4
    5
    6
    7
    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
  • 高 API 延迟警报

    1
    2
    3
    4
    5
    6
    7
    alert: KubeAPILatencyHigh
    expr: |
    max by(instance) (
    kubernetes:job_verb_instance:apiserver_latency:pctl90rate5m
    {verb=~"GET|POST|DELETE|PATCH"}
    ) > 200
    for: 5m

请注意,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'):

    1
    2
    3
    4
    5
    6
    // 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 }}',
    },

您可以在 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 一起使用。


「译文」使用 Prometheus 和 Grafana 实现 SLO
https://ewhisper.cn/posts/42659/
作者
东风微鸣
发布于
2021年12月13日
许可协议