502 Bad Gateway - Socket hang up

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

Symptom

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

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

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

HTTP/1.1 502 Bad Gateway

В ответе будет следующее сообщение об ошибке: 

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

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

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

Распространенные этапы диагностики

  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], включающее имя хоста и порт целевого сервера во втором элементе. В этом примере это X.X.X.X: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. По этому значению можно искать в журналах, чтобы определить, как часто возникает проблема.

Причина: неправильно настроенный тайм-аут keep-alive

диагностика;

  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. Однако это не удается, поскольку сервер уже инициировал закрытие соединения. В ответ на него в пакете 262441 возвращается RST.

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

Сравнение тайм-аутов keep-alive

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

Разрешение

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

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

Рекомендации

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

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

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

    edgemicro:
  keep_alive_timeout: 65000
  2. Время ожидания сообщения keep-alive операционной системы Edge Microgateway должно быть меньше, чем время ожидания сообщения keep-alive целевого сервера.
  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. Загрузите этот файл целиком для затронутой организации и среды.