负载均衡器监控浪涌队列长度

Posted 2023-03-04

【中文标题】负载均衡器监控浪涌队列长度

【英文标题】：Load Balancer Monitoring Surge Queue Length

【发布时间】：2017-12-14 12:21:47

【问题描述】：

谁能解释一下我的 AWS 负载均衡器发生了什么？

我看到指标 Surge Queue Length 有两条线以累积的方式“一起”增长：

从文档中，它说这是负载均衡器上要由后端（EC2 实例）处理的请求队列，并且我发现的所有故障排除建议都指向后端的性能问题，但是在我的情况下，实例是健康的（CPU、内存、磁盘 i/o 等。一切都很好）。

此负载均衡器属于只有一个实例的 Elastic Beanstalk 工作线程环境。而且每次部署新版本时，似乎 Surge Queue Length 都会被清除。

任何人都可以解释为什么即使我的后端实例很好，这个累积队列还在增长吗？为什么在我部署时会清除它？

【参考方案1】：

即使后端的 EC2 实例看起来很健康（CPU、内存、磁盘等），它也可能在处理 ELB 发送的请求方面落后。如果（在我的情况下）EC2 在带有 Docker 的 Elastic Beanstalk 环境下运行，则可能会发生这种情况，其中 EC2 实例只能运行一个 Docker 容器。在这种情况下，运行应用程序的 Docker 容器无法处理所有传入请求，但由于它位于隔离环境（容器）内，因此无法使用 EC2 实例中的所有可用资源。

就我而言，即使我的 EC2 实例报告它们正在使用 5% 的 CPU，我也必须在 Autoscaling Group（位于 ELB 后面）内扩展我的 EC2 实例。扩大规模后（CPU 利用率下降到 1%），我的性能问题消失了。

希望对你有帮助

【讨论】：

好的，我没有运行 docker，但它可能是 Puma 限制了资源使用。这两条“点线”长在一起的解释是什么？

@JonathasHortense AWS ELB 是一个黑盒，我不为 Amazon/AWS 工作。我的猜测是这两行点对应两个ELB服务器。由于请求处理落后，可能是两个 ELB 服务器可能具有不同级别的 Surge Queue Length。为什么我认为 ELB 有两台服务器？ 1. 如果你在 ELB DNS 上进行 nslookup，你会得到两条 A 记录（两个 IP） 2. 一台服务器不会提供冗余 3. 三台或更多台服务器需要跨 ELB 服务器进行更复杂的负载平衡（谁去负载均衡器？）

有道理。感谢您的帮助。