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

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

Симптом

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

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

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

HTTP/1.1 502 Bad Gateway

Ответ будет включать следующее сообщение об ошибке:

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

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

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

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

  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 .

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

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

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

Разрешение

Убедитесь, что свойство таймаута поддержания активности всегда меньше в операционной системе, где работает Edge Microgateway, по сравнению со значением на внутреннем сервере.

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

Лучшая практика

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

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

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

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