GCP HTTP 负载平衡中的一些 502 错误答案

【问题标题】：Some 502 errors in GCP HTTP Load BalancingGCP HTTP 负载平衡中的一些 502 错误
【发布时间】：2017-05-09 09:02:10
【问题描述】：

我们的负载均衡器针对某些请求返回 502 错误。这只是总请求的一个非常低的百分比，我们每小时大约有 36000 个请求和大约 40 个错误，因此只有 0.01% 的请求返回错误。

发生错误时实例处于健康状态，我们已将此转发规则添加到负载均衡器的防火墙：130.211.0.0/22 tcp:1-5000 适用于所有目标

这不是一个非常严重的问题，因为应用程序可以容忍此类错误，但我想知道为什么会出现这些错误。

我们将不胜感激。

【问题讨论】：

【解决方案1】：

在重新创建负载平衡器和后端配置后，我遇到了一个无法解释的 502 问题。我为非托管实例重新创建了我的后端和实例组，这似乎解决了我的问题。我无法在 GCP 中的配置中发现任何问题 :(

但我有更多错误 - 1/10。有负载平衡器日志会告诉您原因是什么，文档会解释原因。

例如我的是： jsonPayload: { statusDetails: "failed_to_pick_backend" @type: "type.googleapis.com/google.cloud.loadbalancing.type.LoadBal‌ancerLogEntry" }

如果您使用的是 nginx 并且它在 POSTS 上并且错误报告为“backend_connection_closed_before_data_sent_to_client”，则可以通过更改您的 nginx 超时来修复它。请参阅这篇出色的博文：

【讨论】：

我使用的是 Apache，但是是的，错误出现在 POST 请求上，错误是“backend_connection_closed_before_data_sent_to_client”。我把Apache的KeepAliveTimeout配置改成65秒，问题就解决了。感谢您对 JasonG 的帮助！ :)
错误似乎更少，但仍在发生。我会在几个小时后检查一下。
我认为你需要超时时间超过 600 秒。
"要修复这个竞争条件，设置“keepalive_timeout 650;”在 nginx 中，这样您的超时时间就会比 GCP HTTP(S) 负载均衡器中的 600 秒超时时间长。这会导致负载均衡器成为关闭空闲连接的一方，而不是 nginx，它修复了竞争条件！（这是不是 100% 准确描述关闭 TCP 连接的工作原理，但在这里就足够了）。”
现在是 2019 年，这正是我们的 App Engine Flex 实例上正在发生的事情。

【解决方案2】：

似乎没有简单的解决方案。

正如 Mike Fotinakis 在 this blog 中解释的那样（感谢 JasonG 提供的信息 :)）：

事实证明，Google Cloud HTTP(S) 负载均衡器和 NGINX 的默认保持活动超时 65 秒之间存在竞争条件。 NGINX 超时可能在负载均衡器尝试将连接重新用于另一个 HTTP 请求的同时达到，这会中断连接并导致负载均衡器发出 502 Bad Gateway 响应。

在我的例子中，我将 Apache 与 mpm_prefork 模块一起使用。提出的解决方案是将连接的keepalive超时时间增加到650s，但这是不可能的，因为每个连接都会打开一个新进程（这样会造成很大的资源浪费）。

更新：
官方负载均衡器文档页面上似乎有一些关于这个问题的新文档（搜索“超时和重试”）：https://cloud.google.com/compute/docs/load-balancing/http/

他们建议在两种情况下（Apache 和 Nginx）都将 KeepAliveTimeout 值设置为 620。

【讨论】：