我们使用在 ALB 后面的 AWS ECS 中运行的 node js 后端服务器。然后，我们有 AWS API 网关和调用 ALB 的代理 lambda。这已经在生产环境中运行了几个月，几天前突然我们开始看到来自一些 API 调用的 502 错误。
我检查了代理 lambda 日志以查看 502 是从 ALB 返回的。但是，当我检查我的节点应用程序日志时，没有失败的请求，实际上在这些时间戳似乎没有请求到达应用程序。然后我在 ALB 上启用了访问日志，它只显示 200/201 响应 - 没有 5xx。我现在有点困惑下一步该往哪里看。什么会导致我的 ALB 返回 502 而 ALB 访问日志中不存在此错误？什么可能导致请求无法到达我在 ECS 中的节点应用程序？有谁知道接下来要检查哪些日志或如何查明错误？ECS 中的某些层会导致这些症状吗？我在我的 docker 容器或任何东西中看不到任何错误。
它似乎是突然发生的，在一段时间内多达 50 个失败的请求，然后在几个小时内一切正常。
结果证明这是我的容器应用程序中的内存泄漏。RAM 使用量随着每个请求而增长，直到崩溃。那时 ECS 和 ALB 需要一段时间才能做出反应，所以一堆请求被路由到了死实例。该问题已通过修复泄漏得到解决，但我希望更好地内置对来自 ECS/cloudwatch 的高内存使用警报的支持，并使用触发器优雅地替换高使用率的实例。似乎我必须从头开始构建它。
这可能是由于多种原因。以下内容可能适用于您——
负载均衡器在尝试建立连接时收到来自目标的 TCP RST。
负载均衡器在尝试建立连接时收到来自目标的意外响应，例如“ICMP Destination unreachable (Host unreachable)”。检查是否允许从负载均衡器子网到目标端口上的目标的流量。
当负载均衡器对目标有未完成的请求时，目标关闭了使用 TCP RST 或 TCP FIN 的连接。检查target的keep-alive时长是否小于负载均衡器的idle timeout值。
目标响应格式错误或包含无效的 HTTP 标头。
负载均衡器在连接到目标时遇到 SSL 握手错误或 SSL 握手超时（10 秒）。