客座文章最后由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 | shexport PATH=$PATH:$HOME/.linkerd2/bin（或者，间接从Linkerd发布页面下载。）
验证你的Kubernetes集群可能解决Linkerd；装置Linkerd；并验证装置：
linkerd check --prelinkerd 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 podsNAME 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",..} 46499response_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微信公众号。