Как отлаживать неудачные запросы с client_disconnected_before_any_response - PullRequest
Новая
       47

Как отлаживать неудачные запросы с client_disconnected_before_any_response

0 голосов
/ 10 сентября 2018

У нас есть HTTP (s) Load Balancer , созданный входом kubernetes, который указывает на бэкэнд, образованный набором модулей, запускающих nginx и Ruby on Rails.

Взглянув на журналы балансировки нагрузки, мы обнаружили растущее число запросов с кодом ответа 0 и statusDetails = client_disconnected_before_any_response.

Мы пытаемся понять, почему это произошло, но мы не нашли ничего подходящего. В журналах доступа или ошибок nginx ничего нет.

Это происходит для нескольких типов запросов, от GET до POST.

Мы также подозреваем, что иногда, несмотря на то, что запрос регистрируется с этой ошибкой, запросы фактически передаются бэкэнду. Например, мы видим ошибки PG :: UniqueViolation из-за того, что идентичные запросы на регистрацию дважды отправляются на сервер в нашей конечной точке регистрации.

Буду признателен за любую помощь. Спасибо!

ОБНОВЛЕНИЕ 1

По запросу вот файл yaml для входного ресурса:

ОБНОВЛЕНИЕ 2

Я создал метрику Stackdriver на основе журнала, чтобы подсчитать количество запросов, которые представляют это поведение. Вот диаграмма:

chart

Большие пики приблизительно соответствуют отметке времени для этих событий kubernetes:

events

Полная ошибка: Readiness probe failed: Get http://10.48.1.28:80/health_check: net/http: request canceled (Client.Timeout exceeded while awaiting headers)"

Так что иногда кажется, что проверка готовности стручков за бэкэндом не удается, но не всегда.

Вот определение готовностиProbe 

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

1 Ответ

0 голосов
/ 12 сентября 2018

Код ответа 0 и statusDetails = client_disconnected_before_any_response означает, что клиент закрыл соединение до того, как балансировщик нагрузки сможет предоставить ответ согласно этой документации GCP .

Изучение того, почему оно не отвечало вовремя, одной из причин может быть разница между тайм-аутами активности активности от nginx и балансировщиком нагрузки GCP, даже если это наиболее похоже на backend_connection_closed_before_data_sent_to_client, вызванное 502 состояние гонки Bad Gateway .

Чтобы убедиться, что бэкэнд отвечает на запрос, и чтобы узнать, сколько времени это займет, вы можете повторить этот процесс пару раз (поскольку вы все еще получаете некоторые действительные ответы):

время отклика скручивания

$ 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

Если это так, просмотрите код регистрации конечной точки для любого типа цикла, например ошибок PG :: UniqueViolation, о которых вы упоминали.

...