容器扩展的艺术： 监控

扩展容器不仅仅是在服务前面放置一个代理然后走开。 扩展不仅仅是分布，在快节奏的容器世界中，需要五种不同的功能来确保扩展：重试，断路器，发现，分发和监控。

在这篇有关容器扩展艺术的文章中，我们将深入探讨监控。

监控

监控。 在这个时代，一切似乎都在倾听和/或观察着我们的一切，从我们开车的速度到我们冰箱里的东西，“倾听”这个词让很多人感到不快。 我们可以——而且经常——使用“可见性”这个词来代替，但这种语义上的诡辩并不能改变我们正在做的事情——我们正在密切观察。

有关规模的一切都依赖于监控；了解分配请求的资源的状态。 由于资源崩溃或最近关闭而向“死区”发送请求就像是转向一条没有出口的死胡同。 这太浪费时间了。

监控有多种形式。 在网络层有ping的“我可以联系你吗”监控。 有对 TCP 连接的“你在家吗”监控。 还有 HTTP 请求“您是否开门”。 然后还有“你喝咖啡了吗”的监控，用于确定服务是否正确应答。

除了检查服务的运行状况和执行情况之外，还进行性能监控。 如果您根据响应时间分配请求，那么服务的响应速度有多快至关重要。 性能的突然变化可能表明存在问题，这意味着也需要监控具有历史意义的数据。

有主动监控（让我给你发送一个真实的请求！），综合监控（让我给你发送一个假装的请求），以及被动监控（我只是坐在这里观察真实请求会发生什么）。 每种方法都有优点和缺点，并且都是有效的监控方法。 关键是代理能够确定状态——它启动了吗？它关闭了吗？它是否与 Elvis 一起离开了大楼？

可达性、可用性和性能都是监控的方面，并且对于确保可扩展性是必要的。 这意味着它不仅仅是监控，还要确保负载均衡代理具有关于它可能定向请求的每个资源的状态的最新信息。

如果您考虑容器的性质以及将其与基于微服务的架构配对的倾向，您会发现监控很快就会变成一场噩梦。 这是因为容器环境内最流行的负载均衡模型是前向（和侧车）代理。 两者都要求每个节点了解它可能需要发送请求的每个资源的健康状况。 这意味着监控几乎所有资源。

你可以想象，对于一个给定的资源来说，耗费自己有限的资源来响应十五或二十个前向代理的状态并不是很有效。 在这种模型下，监控对性能和容量都有明显的负面影响，这使得扩展更加困难。

监控从未对规模产生像容器那样显著的影响。

然而，正如上文所述，这一点至关重要，因为如果可以避免的话，我们不想在“死胡同”资源上浪费时间。

必要的监控的挑战是服务网格作为容器环境中未来规模模型继续获得青睐（和关注）的原因之一。

因为监控不是可选的，但它也不应该成为一种负担。