没有任何日志条目的AWS ALB返回502

Question

我们在ALB后面使用在AWS ECS中运行的节点js后端服务器。然后，我们有了带有调用ALB的代理lambda的AWS API网关。它已经在生产环境中运行了几个月，几天前突然间，我们开始从某些API调用中看到502错误。

我已经检查了代理lambda日志，以查看502是从ALB返回的。但是，当我检查节点应用程序日志时，没有失败的请求，实际上在这些时间戳下似乎没有请求到达应用程序。然后，我在ALB上启用了访问日志，该日志仅显示200/201响应-完全没有5xx。我现在对下一步该怎么看感到困惑。是什么导致我的ALB返回502而又没有出现在ALB访问日志中？导致请求无法到达ECS中的节点应用程序的原因是什么？是否有人对下一步要检查的日志或查明错误的方法有任何想法？ ECS中的某些层会引起这些症状吗？我在Docker容器中看不到任何错误或任何东西。

这似乎是突然发生的，在一段时间内最多有50个失败的请求，然后持续了好几个小时。

Answer 1

可能是由于多种原因。以下内容可能适用于您-

负载均衡器在尝试时从目标接收到TCP RST 建立连接。

负载均衡器收到来自目标的意外响应， 例如“ ICMP目标不可达（主机不可达）” 尝试建立连接。检查是否允许流量 从负载均衡器子网到目标端口上的目标。

目标使用TCP RST或TCP FIN关闭连接，而 负载平衡器对目标有未解决的请求。检查是否 目标的保持活动持续时间短于空闲超时 负载均衡器的值。

目标响应格式不正确或包含未包含的HTTP标头 有效。

负载均衡器遇到SSL握手错误或SSL握手 连接到目标时超时（10秒）。

reference docs

Answer 2

事实证明这是我的容器应用程序中的内存泄漏。直到崩溃，每个请求的RAM使用量都会增加。那时，ECS和ALB花费了一段时间，因此一堆请求被路由到该死实例。 该问题已通过修复泄漏得以解决，但我希望更好地内置对ECS / cloudwatch中内存使用率过高的警报的支持，并使用触发器来优雅地替换内存使用率过高的实例。似乎我必须从头开始构建它。