我们的负载均衡器为某些请求返回502错误。它只占总请求的百分比非常低,我们每小时有大约36000个请求,每小时大约有40个错误,因此只有0.01%的请求会返回错误。
发生错误时实例是健康的,我们已将此转发规则添加到负载均衡器的防火墙:130.211.0.0/22 tcp:1-5000适用于所有目标
这不是一个非常严重的问题,因为应用程序容忍这样的错误,但我想知道为什么给它们。
任何帮助都会被贬低。
发布于 2018-10-19 14:32:57
我有一个问题w / 502s在重新创建负载均衡器和后端配置后无法解释。我为非托管实例重新创建了我的后端和实例组,这似乎解决了我的问题。我无法在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超时来修复它。看到这篇优秀的博文:
发布于 2018-10-19 15:44:40
似乎没有一个简单的解决方案。
正如Mike Fotinakis在这篇博客中解释的那样(感谢您对此信息JasonG :)):
事实证明,Google Cloud HTTP(S)负载均衡器与NGINX的默认保持有效超时为65秒之间存在竞争条件。在负载均衡器尝试重新连接另一个HTTP请求的同时,可能会达到NGINX超时,这会中断连接并导致来自负载均衡器的502 Bad Gateway响应。
在我的情况下,我正在使用Apache与mpm_prefork模块。建议的解决方案是将连接keepalive超时增加到650s,但这是不可能的,因为每个连接都会打开一个新进程(因此这会浪费很多资源)。
更新: 似乎在官方负载均衡器文档页面上有一些关于此问题的新文档(搜索“超时和重试”):https://cloud.google.com/compute/docs/load-balancing/http/
他们建议在两种情况下都将KeepAliveTimeout值设置为620(Apache和Nginx)。
https://stackoverflow.com/questions/-100002944
复制相似问题