AWS LoadBalancer target_processing_time 随机高

Question

我目前遇到一个非常具有挑战性的问题，我真的不知道在哪里调试。

TLDR：NodeJS 需要一段时间才能处理来自 AWS ALB 的某些调用。

基础设施

当前的基础设施是标准的：我们有一个nodeJS（express）应用程序，在EC2实例（后面）和S3（前面）上运行，所有这些都在AWS上。 流量通过 Cloudfront 提供服务，然后通过 LoadBalancer 重定向到 3 个 EC2 实例（t3.small 和 t3.medium 现货实例，运行 ClearLinux）。

发生了什么

对于某些请求（可以是任何请求，不是特定于请求的），我注意到 target_processing_time （从负载均衡器将请求发送到目标到目标开始发送响应标头所花费的总时间。 来自 AWS 文档）超长（例如超过 3 或 4 秒）。

但是，路线本身很快！如果我检查 NodeJS 日志，与往常一样，调用大约需要 200 毫秒或更短的时间。基本上，调用只需要一段时间才能被节点处理，但是一旦处理完毕就正常了。

目前调查：

听起来 EC2 存在容量问题，但我无法确定到底发生了什么。

• 该问题并非在特定时间出现。
• 任何路由都会出现此问题（我用一个简单的 python 脚本重现了它，在 404 路由上运行 GET，超过 100 个调用，发生了 3 次）
• 服务器的CPU很好，低于50％（如果超过50％无论如何都有ASG）。
• 内存没问题。
• Journalctl 日志没有显示任何内容（我检查过：

  journalctl -p warning..emerg

  ）
• AWS Support 没有提供太多帮助，只是提到它与后端服务器有关。
• 这个问题已经存在至少几周了。但不知道什么时候
• 节点应用程序有相当多的中间件。我认为在控制器实际处理之前，这可能是一些缓慢的处理，但经过一些测试，NodeJS（至少是 Express）中间件处理时间包含在我们的记录器持续时间中。
• 我也尝试过将服务器数量从3台增加到4台，并没有太大变化。

我现在没有主意了。您对在哪里恢复调试有任何线索或建议吗？

谢谢！

Answer 1

你发现问题了吗？我遇到了非常相似的事情，尽管使用的是 ECS，而不是 EC2。