作者：Fred Moyer
译者：殷龙飞
运营容器化基础设施带来了一系列新的挑战。您需要对容器进行测试，评估您的 API 端点性能，并确定您的基础架构中的不良的组件。Istio 服务网格可在不更改代码的情况下实现 API 的检测，并且可以自由的设置服务延迟。但是，你如何理解所有这些数据？用数学的方式，对，就是这样。
Circonus 是 Istio 的第一个第三方适配器。在 之前的文章中，我们讨论了第一个用于监视基于 Istio 的服务的 Istio社区适配器。这篇文章将对此进行扩展。我们将解释如何全面了解您的 Kubernetes 基础设施。我们还将解释如何为基于容器的基础架构增加 Istio 服务网格实现。
Istio 概述
Istio 是 Kubernetes 的服务网格，这意味着它负责所有服务之间的通信和协调，就像网络路由软件为 TCP/IP 流量所做的一样。除了 Kubernetes 之外，Istio 还可以与基于 Docker 和 Consul 的服务进行交互。它与 LinkerD 相似，它已经存在了一段时间。
Istio 是由 Google，IBM，思科和 Lyft 的 Envoy 开发的开源项目。该项目已经有一年的历史了，而 Istio 已经进入了大规模生产环境。在这篇文章发布时，当前版本为 0.8。
那么，Istio 如何融入Kubernetes 生态系统？Kubernetes 充当数据层，Istio 充当控制层。Kubernetes 承载应用程序流量，处理容器编排，部署和扩展。Istio 路由应用程序流量，处理策略执行，流量管理和负载均衡。它还处理遥测联合，如指标，日志和跟踪。Istio 是基于容器的基础设施的交叉防护装置和报告部分。
上图显示了服务网格体系结构。Istio 为每项服务使用了一个 envoy sidecar proxy。Envoy 通过 GRPC 调用代理到 Istio Mixer 服务的入站请求。然后，Mixer 应用流量管理规则，并联合请求遥测。Mixer 是 Istio 的大脑。运维人员可以编写 YAML 文件来控制 Envoy 如何重定向流量。他们还可以指定监测信息推送和可观测性系统的遥测技术。可以在运行时根据需要应用规则，而无需重新启动任何 Istio 组件。
Istio 支持多种适配器将数据发送到各种监控工具。包括普罗米修斯，Circonus 或 Statsd。您也可以同时启用Zipkin 和 Jaeger 追踪。而且，您可以把可视化所涉及的服务生成图形。
Istio 易于部署。回想起来，大约7到8个月之前，您必须通过一系列 kubectl 命令将 Istio 安装到 Kubernetes 群集上。你今天仍然可以。但是现在，您只需在 Google Cloud platform，只需点击几下鼠标即可部署启用了 Istio 的Kubernetes 群集，其中包括监视，跟踪和示例应用程序。您可以很快运行起来，然后使用 istioctl 命令开始玩乐。
另一个好处是我们可以从服务中收集数据，而不需要开发人员对他们的服务进行测试以提供数据。这有很多好处。它减少了维护。它消除了代码中的失败点。它提供了供应商不可知的接口，这减少了供应商绑定的机会。
借助 Istio，我们可以部署不同版本的服务并加权它们之间的流量。Istio 本身使用多个不同的 pods 来操作，如下所示：
> kubectl get pods -n istio-system
NAME READY STATUS RESTARTS AGE
istio-ca-797dfb66c5 1/1 Running 0 2m
istio-ingress-84f75844c4 1/1 Running 0 2m
istio-egress-29a16321d3 1/1 Running 0 2m
istio-mixer-9bf85fc68 3/3 Running 0 2m
istio-pilot-575679c565 2/2 Running 0 2m
grafana-182346ba12 2/2 Running 0 2m
prometheus-837521fe34 2/2 Running 0 2m
Istio 不完全是轻量级的。Istio 的强大功能和灵活性来源于一些运维成本。但是，如果您的应用程序中包含多个微服务，那么您的应用程序容器将很快超过系统配置的容器。
服务级别目标
这个服务级别目标的简要概述将为我们如何衡量我们的服务健康状况奠定基础。服务级别协议（SLA）的概念已经存在了至少十年。但就在最近，与服务级别目标（SLO）和服务级别指标（SLI）相关的在线内容数量迅速增加。
除了著名的 Google SRE书以外，两本关于 SLO 的新书即将发布。“站点可靠性工作手册”有关于 SLO 的专门章节，Seeking SRE 有关于由 Circonus 创始人兼首席执行官 Theo Schlossnagle 定义 SLO 目标的章节。我们还建议观看Seth Vargo 和 Liz Fong Jones 的 YouTube 视频 “SLI，SLO，SLA，哦，我的！”，以深入了解 SLI，SLO 和 SLA 之间的差异。
总结一下：SLI 驱动 SLO，通知 SLA。
服务级别指标（SLI）是衡量服务健康状况的指标。例如，我可以有一个 SLI，它表示在过去 5 分钟内，我的第95 个百分点的主页请求延迟应小于 300 毫秒。
服务级别目标（SLO）是 SLI 的目标或指标。我们采用 SLI，并扩展其范围以量化我们期望我们的服务在战略时间间隔内执行的情况。使用前面例子中的 SLI，我们可以说，我们希望满足 SLI 为后续年份窗口的 99.9％ 设置的标准。
服务级别协议（SLA）是企业与客户之间的协议，定义了未能满足 SLO 的后果。一般来说，您的 SLA 所依据的SLO 将比您的内部 SLO 更宽松，因为我们希望我们的内部面向的目标比我们的外部目标更为严格。
RED 仪表板
SLI 的哪些组合最适合量化主机和服务健康？在过去几年中，出现了一些新兴的标准。最高标准是 USE 方法，RED方法和 Google SRE 手册中讨论的“四个金色信号”。
Brendan Gregg 介绍了USE 方法，该方法旨在根据利用率，饱和度和错误指标量化系统主机的健康状况。对于像CPU 这样的产品，我们可以为用户，系统和闲置百分比使用常见的利用率指标。我们可以使用平均负载量和运行队列进行饱和度的判定。UNIX perf 分析器是测量 CPU 错误事件的好工具。
Tom Wilkie 几年前介绍了 RED方法。用 RED。我们监控请求率，请求错误和请求持续时间。Google SRE 手册讨论了如何使用延迟，流量，错误和饱和度指标。这些“ 四个金色信号 ”以服务健康为目标，与 RED 方法类似，但他添加了饱和度指标。在实践中，可能难以量化服务饱和度。
那么，我们如何监控容器？容器是短期实体。直接监视它们以辨别我们的服务健康状况会出现许多复杂的问题，例如高基数问题。综合监控这些容器的服务输出会更容易和更有效。如果服务是健康的，我们不在乎一个容器是异常。有可能我们的编排框架无论如何都会收获这个容器，并用新的框架取而代之。
让我们考虑如何最好地将 Istio 的 SLI 作为 RED 仪表板的一部分进行集成。为了组成我们的 RED 仪表板，我们来看看 Istio 提供的遥测记录：
- 请求按响应代码计数
- 请求时长
- 请求大小
- 响应大小
- 连接收到的字节
- 连接发送字节
- 连接时间
- 基于模板的元数据（度量标签）
Istio 提供了有关它收到的请求，产生响应的延迟和连接级别数据的几个指标。请注意上面列表中的前两项; 我们希望将它们包含在我们的 RED 仪表板中。
Istio 还赋予我们添加度量标签的能力，这就是所谓的尺寸。因此，我们可以通过主机，集群等来分解遥测 。我们可以通过获取请求计数的一阶导数来获得每秒请求的速率。我们可以通过请求不成功的请求计数的派生来获得错误率。Istio 还向我们提供每个请求的请求延迟，因此我们可以记录每个服务请求完成的时间。
另外，Istio 为我们提供了一个 Grafana 仪表板，它包含我们想要的部分：
我们想要的组件在上面的屏幕截图中以红色圈起来。我们在左上角的每秒操作请求率，右上角的每秒失败请求数，以及底部的响应时间图。这张图上还有其他几个指标，但让我们仔细看看我们圈出的那些指标：
以上屏幕截图显示了仪表板的速率组件。这非常简单。我们计算返回 200 响应代码的请求数，并绘制一段时间内的速率图。
Istio 仪表板为返回 5xx 错误代码的响应做了类似的操作。在上面的屏幕截图中，您可以看到它如何通过 ingress controller 或应用程序产品页面本身的错误来分解错误。
该屏幕截图显示了请求持续时间图。此图是关于我们服务的健康状况的最丰富信息。这些数据由普罗米修斯监测系统提供，因此我们可以看到请求时间百分点，包括中位数，第90,95和第99百分位。
这些百分比为我们提供了服务如何执行的全面指示。但是，这种方法存在一些值得研究的缺陷。在低活动期间，由于样本数量有限，这些百分位数可能会大幅偏离。这可能会误导您关于这些情况下的系统性能。我们来看看这种方法可能出现的其他问题：
持续问题：
- 百分位数是固定时间窗口上的聚合指标。
- 集群健康无法重新汇总百分位数。
- 百分位不能被平均（这是一个常见的错误）。
- 这种方法存储的聚合是输出，而不是输入。
- 用这种方法测量集群 SLI 是很困难的。
百分位数通常比平均数提供更深的洞察力，因为它们用多个数据点而不是一个数据点来表示数值范围。但是像平均值一样，百分位数是一个汇总指标。它们是针对固定数据集在固定时间窗口上计算的。如果我们计算一个集群成员的持续时间百分比，我们不能将其与另一个集群成员合并，以获得整个集群的聚合性能指标。
普遍的误解是百分位可以被平均; 除非产生它们的分布几乎相同的极少数情况除外。如果你只有百分位，而不是源数据，你不知道可能是这种情况。这是一个鸡和鸡蛋的问题。
这也意味着，如果您仅针对单个集群成员衡量基于百分比的性能，则由于缺乏可合并性而无法为整个服务设置服务级别指示符。
由于在固定的时间窗口内只有4个延迟数据点，因此我们设置有意义的 SLI（以及因此，有意义的 SLO ）的能力在此处受到限制。因此，当您使用基于百分位的持续时间指标进行工作时，您必须问自己，您的 SLI 是否真的有很好的 SLI。通过使用数学来确定 SLI，我们可以做得更好，从而全面了解我们的服务的性能和健康状况。
直方图计量数据
以上是使用直方图以微秒为单位显示服务延迟数据的可视化。样本数量位于 Y 轴上，样本值（在本例中为微秒等待时间）位于 X 轴上。这是我们在 Circonus 开发的开源直方图。（请参阅 C 和 Golang 中的开源代码，或者在此处阅读有关直方图的更多信息。）还有一些开源的直方图实现，如 Ted Dunning 的 t-消化直方图和 HDR 直方图。
Envoy 项目最近采用了 Circonus 的对数线性直方图库的 C 实现。这使得 envoy 数据可以作为分布来收集。他们在实施中发现了一个非常小的错误，Circonus 非常乐意修复。这就是开源的美妙之处，由于有更多的人可以查看代码，更多的人可以发现问题，并修正问题，那么随着时间的推移代码将会越来越好。
直方图可合并。只要边界相同，任何两个或更多的直方图可以合并。这意味着我们可以将此分布与其他分布结合起来。可合并度量对于监视和可观察性非常有用。它们允许我们合并来自类似资源的输出，例如服务成员，并获得总体服务指标。
如上图所示，此对数线性直方图包含每个幂为 10 的 90 个容器。您可以看到100,000个到1M个之间的90个容器。在每个 10 的功率下，箱尺寸增加 10 倍。这使得我们能够以高相对精度记录各种各样的值，而不需要提前知道数据分布。让我们看看当我们覆盖一些百分点时，这看起来像什么：
现在您可以看到我们的平均水平，第50百分位（也称为中位数）和第 90 百分位。第 90 百分位是 90％ 样本低于该值的值。
考虑我们之前的示例 SLI。通过以此格式显示延迟数据，我们可以通过将直方图合并为一个 5 分钟的数据视图，然后计算该分布的第 90 百分位数值，轻松计算服务的 SLI。如果它少于1,000毫秒，我们达到了我们的目标。
上面截图中的 RED 仪表盘持续时间图有四个百分点，第50,90,95和99个。我们也可以覆盖这些分布的百分位数。即使没有数据，我们也可以看到请求分布可能看起来很粗糙的形式，但是这会做出很多假设。要看到基于几个百分点的假设如何误导，我们来看看具有其他模式的分布：
该直方图显示具有两种不同模式的分布。最左边的模式可能是由于缓存服务而产生的快速响应，以及来自磁盘的正确模式。仅仅使用四个百分点来衡量延迟就几乎不可能辨别出这样的分布。这给了我们一个百分点可以掩盖的复杂性的感觉。考虑具有两种以上模式的分配：
此分布至少有四种可见模式。如果我们对全分布进行数学运算，我们会在这里找到 20 多种模式。您需要记录几个百分位以接近上面的延迟分布？关于下面的发行版怎么样？
由许多服务组成的复杂系统将生成无法用百分位准确表示的延迟分布。您必须记录整个延迟分布才能充分表示它。这是将数据的完整分布存储在直方图中并根据需要计算百分位数的优选原因之一，而不是仅存储几个百分点。
这种直方图可视化显示了固定时间窗口上的分布。我们可以存储多个发行版，以了解它随时间变化的情况，如下所示：
这是一个热图，它代表一组随时间变化的直方图。想象一下，这个热图中的每一列都有一个从上面看的单独的条形图，颜色用于指示每个垃圾箱的高度。这是来自 10 个负载均衡器集群的响应延迟的 grafana 可视化。这使我们能够深入了解整个集群的系统行为，一周之内就有超过100万个数据样本。这里的中位数大约在 500 微秒左右，以红色带表示。
以上是另一种类型的热图。此处，饱和度用于指示每个容器的“高度”（较暗的色块更“饱满”）。此外，这次我们在热图上覆盖了一段时间内的百分比计算。百分位数是健壮的度量标准，非常有用，但不是它们自己。我们可以在这里看到，随着延迟分布向上移动，90％ 以上的百分位数如何增加。
让我们来看看这些基于分布的持续时间图，看看我们是否可以生成比样本 Istio 仪表板更多的信息：
上面的屏幕截图是修改后的 RED 仪表板，显示基于分布的延迟数据。在左下角，我们显示了一个固定时间窗口上的延迟直方图。在它的右边，我们使用热图将分布分解成更小的时间窗口。利用 RED 仪表板的布局，我们可以通过几个小组信息全面了解我们的服务是如何运作的。这个特定的仪表板是使用 Grafana 实现的，它使用 IRONdb时间序列数据库服务，该数据库本地存储等待时间数据作为对数线性直方图。
我们可以进一步扩展这个 RED 仪表板，并将 SLI 覆盖到图表上：
对于速率面板，我们的 SLI 可能会保持每秒最低水平的请求。对于速率面板，我们的 SLI 可能会保持每秒一定数量的错误。正如我们之前研究过持续时间 SLIs，我们可能希望我们的整个服务的第 99 个百分点由多个窗格组成，以在固定窗口内保持一定的延迟。使用存储为直方图的 Istio 遥测技术可以让我们设置这些有意义的服务范围的 SLI。现在我们还有很多工作要做，而且我们可以更好地审问我们的数据（见下文）。
提出正确的问题
所以现在我们已经把这些部分放在一起，并看到了如何使用 Istio 从我们的服务中获取有意义的数据，让我们看看我们可以回答哪些问题。
我们都喜欢能够解决技术问题，但不是每个人都有同样的重点。业务人员想回答关于业务如何的问题。您需要能够回答以业务为中心的问题。让我们来看看我们已经组装的工具集，并将这些功能与业务提出 SRE 的几个问题对齐：
示例问题：
- 在大促销推广后，有多少用户在周二的速度降低中生气？
- 我们是否在我们的购物结帐服务中超额配置或者配置不足？
考虑第一个例子。每个人都经历了一次巨大的速度降低。比方说，市场推广做得很大，流量增加了，运行速度降低了，用户抱怨网站速度缓慢。我们如何量化每个人的速度有多慢？有多少用户生气了？比方说，市场营销部门想知道这一点，以便他们可以向受影响的用户发送 10％ 的折扣电子邮件，同时也希望避免同样问题的再次发生。让我们制作一个 SLI，并假设用户注意到放缓并且在请求花费超过 500 毫秒时生气。我们如何计算有多少用户对这个500毫秒的 SLI 感到愤怒？
首先，我们需要将请求延迟记录为分发。然后我们可以将它们绘制成热图。我们可以使用分布数据来计算超过500ms SLI 的请求的百分比，方法是使用逆百分比。我们将这个答案乘以该时间窗口中的请求总数，并随时间积分。然后我们可以绘制覆盖在热图上的结果：
在此屏幕截图中，我们已经圈出了发生速度降低的热图的一部分。增加的延迟分布是相当缓慢的指示。图中的线表示受到一段时间影响的请求总数。
在这个例子中，我们设法错过了 400 万个请求的 SLI。哎呦。不明显的是右边的两个额外减速，因为它们幅度较小。每个这些花费我们额外 200 万 SLI 违规。哎哟。
我们可以进行这些类型的数学分析，因为我们将数据存储为分布，而不是像百分位数之类的聚合。
我们来考虑另一个常见问题。我的服务是否置备或配置过度？
答案通常“视情况而定”。根据一天中的时间和一周的日子，负载会有所不同，除了因特殊事件而变化之外。那是在我们甚至考虑系统在负载下的行为之前。让我们把一些数学工作，并使用延迟带来可视化我们的系统如何执行：
上面的可视化显示延迟分布随着时间的推移被延迟带分解。这里的频段显示 25ms 到 100ms，100-250ms，250-1000 和 1000ms 以下的请求数。颜色按照绿色显示的快速请求分组，以减慢以红色显示的请求。
这种可视化告诉我们什么？它表明，对我们的服务的请求非常迅速地开始，然后几分钟后快速请求的百分比就会下降，大约 10 分钟后请求的缓慢百分比就会增加。这种模式重复了两次交通会话。那告诉我们关于配置的是什么？它表明，最初服务过度供应，但随后在 10-20 分钟的过程中供应不足。听起来像是自动缩放的好选择。
我们也可以将这种类型的可视化添加到我们的 RED 仪表板。这种类型的数据对业务利益相关者来说非常好 而且它不需要大量的技术知识投资来了解对业务的影响。
结论
我们应该监视服务，而不是容器。服务是长期存在的实体，容器不是。您的用户不关心您的容器如何执行，他们关心您的服务如何执行。
你应该记录分布而不是聚合。但是，那么你应该从这些分布产生你的聚合。聚集体是非常有价值的信息来源。但它们无法合并，因此它们不适合进行统计分析。
Istio 免费提供了很多东西。您不必使用代码来编写。您无需从头开始构建高质量的应用程序框架。
使用数学提出并回答有关您的服务的问题，这对业务很重要。就是这一切，对吧？当我们通过回答企业价值观的问题使系统可靠时，我们实现了组织的目标。