502 Bad Gateway - зависание сокета

Вы просматриваете документацию Apigee Edge .
Перейдите в документацию Apigee X.info

Симптом

Клиентское приложение получает в ответ на вызовы API в Edge Microgateway HTTP-статус 502 Bad Gateway с кодом ECONNRESET .

Сообщение об ошибке

Клиент увидит следующий код ответа:

HTTP/1.1 502 Bad Gateway

В ответе будет содержаться следующее сообщение об ошибке:

{"message":"socket hang up","code":"ECONNRESET"}

Возможные причины

Причина Описание Инструкции по устранению неполадок, применимые для
Неправильно настроенный таймаут поддержания соединения. Неправильно настроены тайм-ауты Keep-alive между Edge Microgateway и целевым сервером. Пользователи публичных и частных облачных сервисов на периферии сети
Целевой сервер преждевременно закрывает соединение. Целевой сервер преждевременно закрывает соединение, пока Edge Microgateway отправляет полезную нагрузку запроса. Пользователи публичных и частных облачных сервисов на периферии сети

Общие этапы диагностики

  1. Проверьте журналы Edge Microgateway: 
    /var/tmp/edgemicro-`hostname`-*.log
  2. Выполните поиск, чтобы проверить наличие ошибок 502 с кодом ECONNRESET за определенный период времени (если проблема возникала ранее) или наличие запросов, которые по-прежнему завершаются с ошибкой 502 . 
    2021-06-23T03:52:24.110Z [error][0:8000][3][myorg][test]
[emg_badtarget/flakey/hangup][][][6b089a00-d3d6-11eb-95aa-911f1ee6c684]
[microgateway-core][][GET][502][socket hang up][ECONNRESET][]
  3. Если уровень логирования установлен на warn или info , то во втором элементе также появится сообщение [warn] , содержащее имя хоста и порт целевого сервера. В этом примере это XXXX:8080 , и это можно использовать позже для захвата tcpdump .
    2021-06-23T03:52:24.109Z
[warn][X.X.X.X:8080][3][myorg][test][emg_badtarget/flakey/hangup]
[][][6b089a00-d3d6-11eb-95aa-911f1ee6c684][plugins-middleware]
[targetRequest error][GET][][socket hang up][ECONNRESET][395]
  4. Код ошибки [socket hang up][ECONNRESET] указывает на то, что целевой сервер разорвал соединение с Edge Microgateway. Чтобы определить частоту возникновения этой ошибки, можно посмотреть журналы.

Причина: Неправильно настроенный таймаут поддержания соединения.

Диагноз

  1. Выполните действия, описанные в разделе «Общие шаги диагностики» , и проверьте, возникла ли у вас ошибка [socket hang up][ECONNRESET] .

  2. Если да, то проведите дальнейшее расследование с помощью tcpdump , как описано ниже:

Использование tcpdump

  1. Для захвата tcpdump между Edge Microgateway и бэкэнд-сервером в операционной системе хоста Edge Microgateway используйте следующую команду: 
    tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
  2. Проанализируйте полученный с помощью tcpdump файл:

    Пример вывода команды tcpdump: ( см. увеличенное изображение )

    В приведенном выше примере tcpdump вы можете увидеть следующее:

    1. В пакете 250288 клиент отправляет POST запрос.
    2. В пакете 250371 сервер отвечает кодом 200 OK .
    3. В пакете 250559 клиент отправляет ACK.
    4. В пакете 250560 сервер отправляет сообщение Continuation .
    5. В пакете 250561 клиент отправляет ACK.
    6. В пакете 262436 сервер отправляет клиенту FIN, ACK инициирующее закрытие соединения. Обратите внимание, что это происходит примерно через пять секунд после предыдущего пакета ( 250561 ).
    7. В пакете 262441 клиент отправляет еще один POST запрос. Однако он терпит неудачу, поскольку сервер уже инициировал закрытие соединения. В ответ он отправляет RST в пакете 262441 .

    В этом примере одно и то же соединение было успешно использовано повторно как минимум один раз, но при последнем запросе сервер инициирует закрытие соединения через пять секунд простоя, что совпадает с моментом отправки клиентом нового запроса. Это говорит о том, что таймаут keep-alive на бэкэнд-сервере, скорее всего, короче или равен значению, установленному на клиенте. Для проверки этого см. раздел «Сравнение таймаутов keep-alive на Edge Microgateway и бэкэнд-сервере» .

Сравните тайм-ауты поддержания соединения.

  1. В Edge Microgateway нет специального параметра таймаута поддержания соединения. Он определяется операционной системой, в которой он работает. Распространенные примеры — Windows, Linux и контейнеры Docker.
  2. Возможно, это настраивается в операционной системе. Обратитесь к системному администратору. По умолчанию в операционных системах Linux время ожидания соединения составляет два часа.
  3. Далее проверьте параметр keep-alive timeout, настроенный на вашем бэкэнд-сервере. Допустим, на вашем бэкэнд-сервере установлено значение 10 секунд.
  4. Если вы обнаружите, что значение параметра keep-alive timeout в операционной системе превышает значение параметра keep-alive timeout на бэкэнд-сервере, как в приведенном выше примере, то это и является причиной ошибок 502 .

Разрешение

Убедитесь, что значение параметра keep-alive timeout всегда меньше в операционной системе, где работает Edge Microgateway, по сравнению с тем, что установлено на бэкэнд-сервере.

  1. Определите значение, установленное для таймаута keep-alive на бэкэнд-сервере.
  2. Настройте соответствующее значение для свойства keep-alive timeout в операционной системе таким образом, чтобы значение свойства keep-alive timeout было ниже значения, установленного на бэкэнд-сервере, используя шаги, применимые к вашей операционной системе.

Передовая практика

Настоятельно рекомендуется, чтобы компоненты нижестоящего уровня всегда имели меньший пороговый уровень ожидания "поддержания соединения", чем настроенный на вышестоящих серверах, во избежание подобных состояний гонки и ошибок 502 Для каждого нижестоящего узла пороговое значение должно быть меньше, чем для каждого вышестоящего узла. В Edge Microgateway рекомендуется использовать следующие рекомендации:

  1. Время ожидания соединения (keep-alive timeout) в клиентском приложении или балансировщике нагрузки должно быть меньше, чем время ожидания соединения (keep-alive timeout) в Edge Microgateway.

    Чтобы настроить таймаут keep-alive на Edge Microgateway, добавьте значение keep_alive_timeout в файл ~/.edgemicro/org-env-config.yaml .

    edgemicro:
  keep_alive_timeout: 65000
  2. В операционной системе Edge Microgateway время ожидания соединения (keep-alive timeout) должно быть меньше времени ожидания соединения целевого сервера (keep-alive timeout).
  3. Если перед Edge Microgateway или за ним находятся другие узлы, следует применять то же правило. Ответственность за закрытие соединения с вышестоящим клиентом всегда должна лежать на нижестоящем клиенте.

Причина: Целевой сервер преждевременно закрывает соединение.

Диагноз

  1. Выполните действия, описанные в разделе «Общие шаги диагностики» , и проверьте, возникла ли у вас ошибка [socket hang up][ECONNRESET] .
  2. Если да, то проведите дальнейшее расследование с помощью tcpdump , как описано ниже.

    Сообщение об ошибке [targetRequest error][GET][] [socket hang up][ECONNRESET] в приведенном выше примере указывает на то, что эта ошибка произошла во время отправки запроса Edge Microgateway на бэкэнд (целевой) сервер. То есть Edge Microgateway отправил API-запрос на бэкэнд-сервер и ожидал ответа. Однако бэкэнд-сервер внезапно разорвал соединение до того, как Edge Microgateway получил ответ.

  3. Проверьте журналы вашего бэкэнд-сервера и посмотрите, нет ли там ошибок или информации, которые могли привести к внезапному разрыву соединения. Если вы обнаружите какие-либо ошибки или информацию, перейдите в раздел «Решение» и устраните проблему соответствующим образом на вашем бэкэнд-сервере.
  4. Если вы не обнаружили ошибок или информации на своем бэкэнд-сервере, соберите вывод tcpdump на сервере Edge Microgateway: 
    tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
  5. Проанализируйте полученный с помощью tcpdump файл:

    Пример вывода команды tcpdump: ( см. увеличенное изображение )

    В приведенном выше примере tcpdump вы можете увидеть следующее:

    1. В пакете 4 Edge Microgateway отправил GET запрос на целевой сервер.
    2. В пакете 5 целевой сервер ответил ACK , подтвердив получение запроса.
    3. Однако в пакете 6 вместо ответа целевым сервером отправляется FIN, ACK инициирующий закрытие соединения.
    4. Начиная с пакетов 7 , соединение разрывается взаимно. Поскольку соединение было разорвано до отправки ответа, Edge Microgateway вернет клиенту ошибку HTTP 502 .
    5. Обратите внимание, что метка времени пакета 8 , 2021-06-23T03:52:24.110Z соответствует метке времени, когда ошибка была зарегистрирована в журналах Edge Microgateway. Метки времени в файлах журналов и в tcpdump часто можно использовать для сопоставления ошибок с фактическими пакетами.

    Разрешение

    Устраните проблему на бэкэнд-сервере.

    Если проблема сохраняется и вам нужна помощь в устранении 502 Bad Gateway Error , или вы подозреваете, что проблема связана с Edge Microgateway, перейдите к разделу «Необходимо собрать диагностическую информацию» .

    Необходимо собрать диагностическую информацию.

    Если проблема сохраняется даже после выполнения вышеуказанных инструкций, соберите следующую диагностическую информацию и обратитесь в службу поддержки Apigee Edge :

    • Файлы журналов : папка по умолчанию — /var/tmp , но её можно изменить в основном файле config.yaml ( logging > dir parameter ). Рекомендуется изменить log > level на info перед отправкой файлов журналов в службу поддержки Apigee.
    • Файл конфигурации : Основная конфигурация Edge Microgateway находится в YAML-файле в папке Edge Microgateway по умолчанию, $HOME/.edgemicro . Существует файл конфигурации по умолчанию под названием default.yaml , а также по одному файлу для каждой среды: ORG - ENV -config.yaml . Пожалуйста, загрузите этот файл полностью для затронутой организации и среды.