详解如何使用Istio监控基于容器的服务

作者｜FredMoyer译者｜无明我们应该监控服务，而不是容器。服务是长期存活的实体，而容器不是。我们应该记录分布而不是聚合，不过要能够从这些分布中生成聚合。运营容器化的基础设施带来了一系列新的挑战。我们需要增强容器、评估API端点的性能以及识别出基础设施中的有害部分。Istio服务网格可在不修改代码的情况下实现API增强，并且不会带来服务延迟。

上图描绘了服务网格的架构。Istio为每项服务运行一个Envoy边车代理。Envoy代理通过GRPC调用将入站请求转发至IstioMixer服务。然后，Mixer应用流量管理规则来聚合遥测元素。Mixer是Istio的大脑。运维人员可以通过编写YAML文件来指定Envoy如何重定向流量，还可以指定将哪些遥测元素推送到监控系统和观测系统。

上面截图中以红色圈起来的部分是我们想要的组件。左上角是每秒操作请求速率，右上角是每秒失败请求数，底下是响应时间。现在让我们来仔细看看圈出的那几个指标：

这个截图显示了仪表盘的速率组件。我们统计返回200响应码的请求数，并绘制成图形。

Istio仪表盘为返回5xx错误码的响应做了类似的操作。在上面的截图中，可以看到，它按照摄入控制器或应用程序产品页的错误来区分错误。

这个截图显示了请求持续时间，提供了丰富的有关服务健康状况的信息。这些数据由Prometheus监控系统提供，因此我们可以看到请求时间百分位，包括中位数、90th、95th和99th这些百分位。这些百分位为我们提供了有关服务执行情况的全面指示。但是，这种方法也存在一些缺陷。在活动不是很活跃的时候，由于样本数量有限，这些百分位可能会大幅偏离，给我们带来误导。

上面是以微秒为单位显示服务延迟数据的一个直方图。样本数量位于Y轴上，样本值（微秒级延迟）位于X轴上。

可以看到，现在有平均值、50th百分位（也称为中位数）和90th百分位。90th百分位是指90％样本低于该值。现在回到之前的SLI示例，如果按照这种格式来显示延迟数据，就可以通过将直方图合并在一起来获得5分钟的数据视图，然后计算出该分布的90th百分位，从而得到服务的SLI。如果它低于1,000毫秒，就达到了我们的目标。

这个直方图显示了两种不同模式的分布。左边的模式表示快速响应，可能是因为使用了缓存，而右边的表示从磁盘上读取数据再做出响应。仅使用四个百分位来衡量延迟几乎不可能辨别这种分布。可见，百分位会隐藏掉一些复杂性。现在让我们来看看具有两种以上模式的分布：

这个分布至少有四种模式。如果我们在全分布上运行数学运算，可以找到20多种模式。那么我们需要记录多少个百分位才能获得一个近似于上面这样的延迟分布呢？又比如下面这个分布呢？

由很多服务组成的复杂系统将生成无法用百分位准确表示的延迟分布，我们必须记录整个延迟分布才能完整地表示它。这就是为什么要将数据的完整分布放在直方图中，并根据实际需要计算出百分位，而不只是保存几个百分位。这种直方图显示了固定时间窗口上的分布。我们可以存储多个分布，以了解它随时间变化的情况，如下所示：

这是一个热图，代表一组随时间变化的直方图。想象一下，这个热图中的每一列都有一个单独的条形图，用颜色来表示每个bin的高度。这是一个集群（包含10个负载均衡器）响应延迟在Grafana中的可视化。我们因此能够深入了解整个集群一周之内的行为，这里包含了100万个数据样本。这里的中位数大约在500微秒左右，以红色条形表示。

上面是另一种类型的热图，其中使用饱和度表示每个bin的“高度”（块颜色越深表示越“饱和”）。此外，这次我们在热图上重叠了随时间变化的百分位。百分位是可靠的度量指标，而且非常有用，但它们本身并不能发挥这种作用。我们可以看到90以上的百分位将如何随着延迟分布向上移动而增加。让我们来看看这些时间段分布图，看看是否可以生成比样本仪表盘包含更多信息的东西：

上面的截图是修改后的RED仪表盘，显示了基于分布的延迟数据。左下角显示了固定时间窗口的延迟直方图。在它的右边，我们使用热图将分布分解成更小的时间窗口。利用RED仪表盘的布局，我们只需要借助几个信息面板就可以全面了解我们的服务是如何运作的。这个仪表盘是使用Grafana实现的，后台使用了IRONdb时间序列数据库，该数据库在本地存储延迟数据，用于构建对数线性直方图。

对于速率面板，我们的SLI可能会保持最低水平的每秒请求数，每秒错误数也可能保持在某个值之下。正如我们之前研究过的SLI，我们可能希望整个服务的99th百分位在固定时间窗口内保持一定的延迟。我们可以借助这些直方图来设置有意义的SLI。现在我们还有很多工作要做，而且可以更好地审查我们的数据。

在上面的截图中，我们已经在热图上圈出了速度变慢的部分。增加的延迟分布足以告诉我们速度变慢了。图中的线表示受影响的请求总数随时间变化的情况。在这个例子中，有400万个请求达不到我们的SLI。右边的两处速度变慢不是很明显，因为它们的幅度较小，但每处都有200万个请求达不到SLI。我们可以继续进行这类数学分析，因为数据被存储为分布，而不只是聚合的百分位。

上面的可视化显示了延迟分布随时间变化的情况，包括低于25毫秒的请求数、25毫秒到100毫秒的请求数、100毫秒到250毫秒的请求数、250毫秒到1000毫秒的请求数以及超过1000毫秒的请求数。它们按照颜色进行分组，绿色表示快速请求，红色表示慢请求。这种可视化告诉了我们什么？