背景：
我们正在运行一个单页面应用程序，该应用程序通过 nginx 提供服务，并带有运行 Express 的 Node js (v12.10) 后端。它通过 ECS 作为容器运行，目前我们正在运行三个 t3a 介质作为容器实例，其中每个 API 和 Web 服务在这些实例上运行 6 个副本。我们使用 ALB 来处理请求的负载平衡/路由。我们跨 3 个可用区运行三个子网，负载均衡器与所有三个可用区关联，实例也分布在这 3 个可用区。
问题：
我们正在尝试找出前端和后端出现的一些间歇性 502 错误的根本原因。我已经下载了 ALB 访问日志，所有这些请求的有趣之处在于它们都显示以下内容。- request_processing_time：0.000 - target_processing_time：0.000（有时为 0.001 或最多 0.004） - response_processing_time：-1
在发生这些错误时，我可以看到有可用的健康目标。
现在我知道有些人遇到过这样的问题，服务器端的 keepAlive 时间比 ALB 端的要短，因此连接被强制关闭，然后 ALB 会尝试重用（这符合故障排除指南）在 AWS 上）。然而，当查看我们后端的 keepAlive 时间时，它们设置为比当前 ALB 高一倍。此外，请求本身可以通过 chrome 开发工具重播，并且成功（我不确定这是否是检查格式错误的请求的有效方法，这似乎是合理的）。
我对这个领域非常陌生，如果有人对在哪里查看或运行什么样的测试有一些建议可以帮助我查明这个问题，我将不胜感激。我在某些端点上运行了一些负载测试并重复了 502 错误，但是重负载下的错误与我在日志中看到的间歇性错误不同，因为 target_processing_time 相当高，所以在我看来，这完全是另一个问题。在这个阶段，我想了解显示 target_processing_time 基本上为零的错误。