使用Prometheus和Linkerd建立Kubernetes服务水平目标(SLO)的指南

Donald 2020/11/17 16:25:28

客座文章最初由Kevin LeimkuhLer在Buoyant的博客上发布有了服务网格,SLO就容易多了在本教程中,你将学习如何使用Prometheus(一个开源时间序列数据库)和Linkerd(一个开源超轻服务网格)在Kubernetes上轻松创建服务运行状况SLO。你将看到如何使用服务网格解决SLO中最困…

客座文章最初由Kevin LeimkuhLer在Buoyant的博客上发布

有了服务网格,SLO就容易多了

在本教程中,你将学习如何使用Prometheus(一个开源时间序列数据库)和Linkerd(一个开源超轻服务网格)在Kubernetes上轻松创建服务运行状况SLO。你将看到如何使用服务网格解决SLO中最困难的部分之一:为你想要度量的东西获得一致的度量标准。

但在我们开始之前,让我们先深入了解一下为什么SLO和Kubernetes会携手并进。

Kubernetes和服务网格的一个SLO案例

SLO,或者服务级别目标(service level objective),最近已经成为描述应用程序可靠性的流行工具。正如谷歌SRE书中所描述的,SLO是应用程序开发人员和SRE团队明确捕获应用程序风险容忍度的一种方法,通过定义可接受的失败级别,然后根据该决策做出风险vs回报的决策。

对于平台所有者,他们较少关注应用程序,更多关注底层平台,SLO还有另一个用途:它们提供了一种方法,可以了解平台上运行的服务的健康状况,而无需了解任何有关其运营历史的信息。这在Kubernetes中特别有用,在Kubernetes中,你可能在几十个集群中运行数百或数千个服务。你不需要了解每个服务的操作上下文,而可以使用SLO作为获得上下文无关判断的一种方法。(参见SLO vs Kubernetes指标)。

令人高兴的是,在Kubernetes上获得服务运行状况方面的SLO比你想象的要容易得多。这是因为SLO最难的部分之一是获得一致的、统一的度量,而这正是服务网格所做的!例如,Linkerd为你所有的服务提供了一个统一的、一致的黄金度量层--成功率、延迟、请求量--并且不需要任何配置。有了Linkerd的指标在手,获得基本的服务运行状况SLO就可以归结为做一些计算。

(当然,服务网格并不是SLO的完整解决方案,因为它不能捕获应用程序特定指标之类的东西。但对于常见的服务运行状况度量,如成功率和延迟,至少可以通过提取服务网格数据轻松构建服务运行状况SLO。)

让我们用一个演示用例来动手吧。

用Linkerd和Prometheus计算SLO

在本教程中,我们将看到如何为在Kubernetes上运行的gRPC服务设置一个滚动窗口的基本成功率SLO。当然,我们这里使用的技术同样适用于不同类型的指标和SLO。

首先,让我们回顾一下Linkerd如何捕捉它的黄金指标。当Linkerd被添加到服务中时,它会自动记录对服务pod的任何HTTP和gRPC调用。它记录这些调用的响应类和延迟,并将它们聚合到Prometheus的一个内部实例中。这个Prometheus实例为Linkerd的仪表板和CLI提供动力,并包含所有网格服务的观察黄金指标

因此,为了达到我们的目标,我们需要将存储在Linkerd的Prometheus中的成功率指标转换为SLO。

安装:访问Kubernetes集群并安装Linkerd CLI

让我们从最基本的开始。我们假设你有一个运行的Kubernetes集群和一个指向它的kubectl命令。在本节中,我们将带你完成Linkerd入门指南的简化版,以在这个集群上安装Linkerd和一个演示应用程序。

首先,安装Linkerd CLI:

curl -sL https://run.linkerd.io/install | sh
export PATH=$PATH:$HOME/.linkerd2/bin

(或者,直接从Linkerd发布页面下载。)

验证你的Kubernetes集群能够处理Linkerd;安装Linkerd;并验证安装:

linkerd check --pre
linkerd install | kubectl apply -f -
linkerd check

最后,安装我们将要使用的“Emojivoto”演示应用程序:

curl -sL https://run.linkerd.io/emojivoto.yml 
 | linkerd inject - 
 | kubectl apply -f -

此时,我们已经准备好获得一些实际的指标了。但首先,让我们谈谈SLO中最重要的数字:错误预算(error budge)。

错误预算

错误预算可以说是SLO中最重要的部分。但它到底是什么,我们如何得到它?

让我们从一个例子开始。假设在过去7天内,你已经决定你的服务必须有80%的成功率。这是我们的SLO。我们可以将这个语句分解为三个基本组件:一个服务水平指示器(SLI),这是我们的度量;目标,也就是我们的门槛;还有时间窗口。在这种情况下:

SLI:服务成功率

目标:80%

时间窗口:7天

这个SLO意味着在7天滚动周期内20%的请求可能会失败,而我们并不认为这是一个问题。因此,我们的错误预算仅仅是衡量我们在一段时间内“消耗”了20%中的多少。

例如,如果我们在过去7天内成功地提供了所有响应的100%,那么我们的错误预算将保持100%—没有任何响应失败。另一方面,如果我们在过去7天成功地服务了80%的响应,那么我们就有0%的错误预算剩余。如果我们在这段时间内提供了少于80%的成功回应,我们的错误预算就会是负的,我们就违反了SLO。

错误预算由下式计算:

Error budget = 1-[(1-compliance)/(1-objective)]

compliance是在时间窗口内测量的SLI。因此,为了计算你的错误预算,我们在时间窗口内测量SLI(计算compliance),并将其与目标进行比较。

用Prometheus计算错误预算

好,回到键盘上来。让我们访问在Linkerd控制平面中的Prometheus实例,我们在上一步中通过一个port-forward安装了它:

# Get the name of the prometheus pod
$ kubectl -n linkerd get pods
NAME                                      READY   STATUS    RESTARTS   AGE
..
linkerd-prometheus-54dd7dd977-zrgqw       2/2     Running   0          16h

用PODNAME表示pod的名称,我们现在可以这样做:

kubectl -n linkerd port-forward linkerd-prometheus-PODNAME 9090:9090

现在我们可以打开localhost:9090并开始试验Prometheus的查询语言PromQL。


Prometheus仪表板

本教程不需要完全掌握语法知识,但是浏览示例熟悉一下肯定会有帮助!

构建Prometheus的查询

在上面的例子中,100%和80%的响应是成功的--这是我们在这段时间内的compliance数字。让我们先用Prometheus查询来计算这个数字。对于我们的服务,我们将使用Emojivoto的投票服务,它作为Emojivoto命名空间中的部署资源。

首先,让我们看看总共有多少对投票部署的响应:

查询:

response_total{deployment="voting", direction="inbound", namespace="emojivoto"}

结果:

response_total{classification="success",deployment="voting",direction="inbound",namespace="emojivoto",..} 46499
response_total{classification="failure",deployment="voting",direction="inbound",namespace="emojivoto",..} 8652

在这里我们看到两个结果,因为指标是由一个标签值分开的,它们的不同之处是:classification(分类)。我们有46499个成功的响应和8652个失败的响应。

在此基础上,通过添加classification="success"标签和[7d]时间范围,我们可以看到过去7天每个时间戳上成功响应的数量:

查询:

response_total{deployment="voting", classification="success", direction="inbound", namespace="emojivoto"}[7d]

这个查询的响应很大,但是我们可以使用increase()和sum() PromQL函数来简化它,通过标签分组来区分不同的值:

查询:

sum(increase(response_total{deployment="voting", classification="success", direction="inbound", namespace="emojivoto"}[7d])) by (namespace, deployment, classification, tls)

结果:

{classification="success",deployment="voting",namespace="emojivoto",tls="true"} 26445.68142198795

这意味着在过去7天里,通过投票部署已经有大约26445个成功的响应(小数来自increase()计算的机制)。

使用这个,我们现在可以通过将这个数字除以响应总数来计算我们的compliance--只需删除classification="success"标签:

查询:

sum(increase(response_total{deployment="voting", classification="success", direction="inbound", namespace="emojivoto"}[7d])) by (namespace, deployment, classification, tls) / ignoring(classification) sum(increase(response_total{deployment="voting", direction="inbound", namespace="emojivoto"}[7d])) by (namespace, deployment, tls)

结果:

{deployment="voting",namespace="emojivoto",tls="true"} 0.846113068695625

我们发现,在过去7天内,84.61%的响应都是成功的。

计算错误预算

我们使用核心查询来计算剩余的错误预算。现在我们只需要把它们代入上面的公式:

Error budget = 1-[(1-compliance)/(1-objective)]

插入我们80%(0.8)的目标(objective):

查询:

1 - ((1 - (sum(increase(response_total{deployment="voting", classification="success", direction="inbound", namespace="emojivoto"}[7d])) by (namespace, deployment, classification, tls)) / ignoring(classification) sum(increase(response_total{deployment="voting", direction="inbound", namespace="emojivoto"}[7d])) by (namespace, deployment, tls)) / (1 - .80))

结果:

{deployment="voting",namespace="emojivoto",tls="true"} 0.2312188519042635

在我们的例子中,投票部署还有23.12%的错误预算。

祝贺你,你已经成功地计算了你的第一个错误预算!

用Grafana捕捉结果

数字很好,但花哨的图表呢?你是幸运的。Linkerd安装了一个Grafana实例,我们可以通过Linkerd的仪表板在本地访问它。

首先,通过运行Linkerd dashboard命令加载Linkerd的仪表板。

现在,让我们通过单击相应的Grafana徽标来查看emojivoto命名空间的Grafana仪表板。


Linkerd仪表盘与Grafana集成

向下滚动到deploy/voting,我们可以看到黄金指标面板:成功率、请求率和延迟。让我们为剩余的错误预算添加一个面板。


Linkerd在Grafana仪表板上

为了保持简单,让我们添加面板标题7-day error budget (success rate),并在PromQL查询框中添加上面的最终查询。

应用结果,你现在应该有一个面板来跟踪投票部署的剩余错误预算!


Grafana与Linkerd指标显示错误预算。

进一步

有很多方法可以调整上面使用的查询以适应特定的用例。

现在我们有了一个跟踪服务错误预算的图表,我们可以使用额外的PromQL函数(如rate())来跟踪服务的错误预算消耗率。

如果你想以不同的方式查看你的预算,请尝试更改数据的可视化。在这里,我选择了测量和添加阈值来指示我是否应该关注。


7天错误预算(成功率)与测量。

要跟踪emojivoto命名空间中所有服务的剩余错误预算,只需删除deployment="voting"标签。请记住,这将假设命名空间中的所有服务都有相同的80%目标。


所有服务的7天错误预算(成功率)。

从SLO到可操作的观察性

你已经根据Linkerd的黄金度量标准制定了服务运行状况的SLO,计算了错误预算,并用Grafana绘制了它们的图表。祝贺你,你正在使用SLO!

下一步是什么呢?

遗憾的是,即使有了所有这些,要真正使用SLO仍然需要做很多工作。你需要为你平台上的每个相关服务一致地计算它们;你需要把它们交到组织中其他需要了解它们的人手中;当错误预算开始迅速下降时,你需要能够采取行动。如果没有这些部分,你的SLO将只是一个空数字。

在Buoyant,我们是SLO的巨大信徒,尤其是Kubernetes。这也是我们创建Dive的部分原因,它允许你通过点击一个按钮来设置SLO。Dive构建在Linkerd之上,并使用相同的指标来自动跟踪集群上运行的所有服务。Dive还提供了很棒的可共享仪表盘,你可以将其发送给团队的其他成员,允许你预测何时会违反你的SLO,以及许多其他有趣的东西。

Dive仪表板显示SLO遵从性和错误预算的7天窗口。

无论你最终是使用Dive进行Linkerd服务的健康SLO,还是坚持我们上面概述的Prometheus和Grafana方法,我们都祝你在SLO旅程中好运!

点击阅读网站原文。


CNCF (Cloud Native Computing Foundation)成立于2015年12月,隶属于Linux  Foundation,是非营利性组织。
CNCF(云原生计算基金会)致力于培育和维护一个厂商中立的开源生态系统,来推广云原生技术。我们通过将最前沿的模式民主化,让这些创新为大众所用。扫描二维码关注CNCF微信公众号。
image

随时随地学软件编程-关注百度小程序和微信小程序
关于找一找教程网

本站文章仅代表作者观点,不代表本站立场,所有文章非营利性免费分享。
本站提供了软件编程、网站开发技术、服务器运维、人工智能等等IT技术文章,希望广大程序员努力学习,让我们用科技改变世界。
[使用Prometheus和Linkerd建立Kubernetes服务水平目标(SLO)的指南]http://www.zyiz.net/tech/detail-149074.html

上一篇:5 款顶级 Kubernetes 日志监控工具

下一篇:Kubernetes笔记(五):了解Pod(容器组)

赞(0)

共有 条评论 网友评论

验证码: 看不清楚?
    关注微信小程序
    程序员编程王-随时随地学编程

    扫描二维码或查找【程序员编程王】

    可以随时随地学编程啦!

    技术文章导航 更多>
    扫一扫关注最新编程教程