共计 6185 个字符，预计需要花费 16 分钟才能阅读完成。
客座文章最后由 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 微信公众号。
