如何使用client_disconnected_before_any_response调试失败的请求

jäv*_*ävi 13 kubernetes google-kubernetes-engine google-cloud-networking kubernetes-ingress

我们有一个由kubernetes ingress创建的HTTP(s)Load Balancer,它指向由运行nginx和Ruby on Rails的pod组成的后端.

看一下负载均衡器日志,我们检测到越来越多的请求,响应代码为0statusDetails= client_disconnected_before_any_response.

我们试图理解为什么会发生这种情况,但我们没有找到任何相关的东西.nginx访问或错误日志中没有任何内容.

这种情况发生在从GET到POST的多种请求中.

我们还怀疑有时尽管请求记录了该错误,但请求实际上是传递给后端的.例如,我们看到了PG :: UniqueViolation错误,因为在我们的注册终端中,两次发送了令人满意的注册请求到后端.

任何形式的帮助将不胜感激.谢谢!


 更新1

这里要求的入口资源的yaml文件:


 更新2

我已经创建了一个基于日志的Stackdriver度量标准,用于计算出现此行为的请求数.这是图表:

图表

大峰大致匹配这些kubernetes事件的时间戳:

事件

完整错误: Readiness probe failed: Get http://10.48.1.28:80/health_check: net/http: request canceled (Client.Timeout exceeded while awaiting headers)"

因此有时候后端后面的pod的准备探测失败了,但并非总是如此.

这是readinessProbe的定义

readinessProbe:
  failureThreshold: 3
  httpGet:
    httpHeaders:
    - name: X-Forwarded-Proto
      value: https
    - name: Host
      value: [redacted]
    path: /health_check
    port: 80
    scheme: HTTP
  initialDelaySeconds: 1
  periodSeconds: 30
  successThreshold: 1
  timeoutSeconds: 5
Run Code Online (Sandbox Code Playgroud)

Dan*_*iel 1

响应代码为 0 且 statusDetails = client_disconnected_before_any_response 表示客户端在负载均衡器能够根据此GCP 文档提供响应之前关闭了连接。

调查它为什么没有及时响应,原因之一可能是nginx 和 GCP 负载均衡器的keepalive 超时之间的差异,即使这很可能会提供由502 Bad Gateway 竞争条件引起的 backend_connection_filled_before_data_sent_to_client 。

为了确保后端响应请求并查看是否需要多长时间,您可以重复此过程几次(因为您仍然得到一些有效的响应):

卷曲响应时间

$curl -w "@curl.txt" -o /dev/null -s IP_HERE

curl.txt内容(先创建并保存该文件):

   time_namelookup:  %{time_namelookup}\n
      time_connect:  %{time_connect}\n
   time_appconnect:  %{time_appconnect}\n
  time_pretransfer:  %{time_pretransfer}\n
     time_redirect:  %{time_redirect}\n
time_starttransfer:  %{time_starttransfer}\n
                ----------\n
        time_total:  %{time_total}\n
Run Code Online (Sandbox Code Playgroud)

如果是这种情况,请检查任何类型循环的注册端点代码,例如您提到的 PG::UniqueViolation 错误。