502 Bad Gateway Неожиданный EOF

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

Симптом

В ответ на вызовы API клиентское приложение получает HTTP-статус 502 с сообщением Bad Gateway .

Код состояния HTTP 502 означает, что клиент не получает действительный ответ от серверной части, которая должна была бы фактически выполнить запрос.

Сообщения об ошибках

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

HTTP/1.1 502 Bad Gateway

Кроме того, вы можете увидеть следующее сообщение об ошибке:

{
   "fault": {
      "faultstring": "Unexpected EOF at target",
      "detail": {
           "errorcode": "messaging.adaptors.http.UnexpectedEOFAtTarget"
       }
    }
}

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

Одной из типичных причин ошибки 502 Bad Gateway Error является ошибка Unexpected EOF , которая может быть вызвана следующими причинами:

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

Для диагностики ошибки можно использовать любой из следующих методов:

• Мониторинг API
• инструмент трассировки
• Журналы доступа NGINX

Причина: Неправильно настроенный целевой сервер

Целевой сервер некорректно настроен для поддержки TLS/SSL-соединений.

Диагноз

1. Используйте мониторинг API , инструмент трассировки или журналы доступа NGINX , чтобы определить идентификатор сообщения, код ошибки и источник ошибки 502 .
2. Включите трассировку в пользовательском интерфейсе для затронутого API.
3. Если в трассировке неудачного запроса к API отображается следующее:
   1. Ошибка 502 Bad Gateway появляется сразу после начала запроса к целевому потоку.
   2. error.class отображает messaging.adaptors.http.UnexpectedEOF.

      В таком случае весьма вероятно, что эта проблема вызвана неправильной конфигурацией целевого сервера.

4. Получите определение целевого сервера, используя вызов API управления Edge:
   1. Если вы являетесь пользователем публичного облака , используйте этот API:

      curl -v https://api.enterprise.apigee.com/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>

   2. Если вы используете частное облако , воспользуйтесь этим API:

      curl -v http://<management-server-host>:<port #>/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>

      Пример некорректного определения TargetServer :

      <TargetServer  name="target1">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
      </TargetServer >

5. Приведенное на иллюстрации определение TargetServer является примером одной из типичных ошибок конфигурации, которая объясняется следующим образом:

   Предположим, что целевой сервер mocktarget.apigee.net настроен на прием защищенных (HTTPS) соединений на порту 443 Однако, если вы посмотрите на определение целевого сервера, вы увидите, что там нет других атрибутов/флагов, указывающих на то, что он предназначен для защищенных соединений. Это приводит к тому, что Edge обрабатывает запросы API, направляемые на конкретный целевой сервер, как HTTP-запросы (незащищенные) . Поэтому Edge не будет инициировать процесс SSL-рукопожатия с этим целевым сервером.

   Поскольку целевой сервер настроен на прием только HTTPS (SSL) запросов по порту 443 , он отклонит запрос от Edge или закроет соединение. В результате обработчик сообщений получит ошибку UnexpectedEOFAtTarget . Обработчик сообщений отправит клиенту ответ с кодом 502 Bad Gateway .

Разрешение

Всегда убедитесь, что целевой сервер правильно настроен в соответствии с вашими требованиями.

В приведенном выше примере, если вы хотите отправлять запросы на защищенный (HTTPS/SSL) целевой сервер, вам необходимо включить атрибуты SSLInfo с флагом enabled , установленным в true . Хотя добавление атрибутов SSLInfo для целевого сервера допускается в самом определении целевой конечной точки, рекомендуется добавлять атрибуты SSLInfo как часть определения целевого сервера, чтобы избежать путаницы.

1. Если серверная часть требует односторонней SSL-связи , то:
   1. Необходимо включить TLS/SSL в определении TargetServer , добавив атрибуты SSLInfo , в которых флаг enabled установлен в значение true, как показано ниже:

      <TargetServer name="mocktarget">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
        <SSLInfo>
            <Enabled>true</Enabled>
        </SSLInfo>
      </TargetServer>

   2. Если вы хотите проверить сертификат целевого сервера в Edge, то нам также необходимо добавить хранилище доверенных сертификатов (содержащее сертификат целевого сервера), как показано ниже:

      <TargetServer  name="mocktarget">
          <Host>mocktarget.apigee.net</Host>
          <Port>443</Port>
          <IsEnabled>true</IsEnabled>
          <SSLInfo>
              <Ciphers/>
              <ClientAuthEnabled>false</ClientAuthEnabled>
              <Enabled>true</Enabled>
              <IgnoreValidationErrors>false</IgnoreValidationErrors>
              <Protocols/>
              <TrustStore>mocktarget-truststore</TrustStore>
          </SSLInfo>
      </TargetServer>

2. Если серверная часть требует двусторонней SSL-связи , то:
   1. Необходимо правильно установить флаги ClientAuthEnabled , Keystore , KeyAlias ​​и Truststore для атрибутов SSLInfo , как показано ниже:

      <TargetServer  name="mocktarget">
           <IsEnabled>true</IsEnabled>
           <Host>www.example.com</Host>
           <Port>443</Port>
           <SSLInfo>
               <Ciphers/>
               <ClientAuthEnabled>true</ClientAuthEnabled>
               <Enabled>true</Enabled>
               <IgnoreValidationErrors>false</IgnoreValidationErrors>
               <KeyAlias>keystore-alias</KeyAlias>
               <KeyStore>keystore-name</KeyStore>
               <Protocols/>
               <TrustStore>truststore-name</TrustStore>
           </SSLInfo>
        </TargetServer >

Ссылки

Балансировка нагрузки между серверными бэкэндами

Причина: ошибка EOFException на бэкэнд-сервере.

Серверная часть может внезапно отправить сообщение EOF (конец файла).

Диагноз

1. Используйте мониторинг API , инструмент трассировки или журналы доступа NGINX , чтобы определить идентификатор сообщения, код ошибки и источник ошибки 502 .
2. Проверьте журналы обработчика сообщений ( /opt/apigee/var/log/edge-message-processor/logs/system.log ) и найдите там сообщения типа eof unexpected для конкретного API или, если у вас есть уникальный messageid для запроса API, вы можете выполнить поиск.

   Пример трассировки стека исключений из журнала обработчика сообщений.

   "message": "org:myorg env:test api:api-v1 rev:10 messageid:rrt-1-14707-63403485-19 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() : SSLClientChannel[C:193.35.250.192:8443 Remote host:0.0.0.0:50100]@459069 useCount=6 bytesRead=0 bytesWritten=755 age=40107ms lastIO=12832ms .onExceptionRead exception: {}
   java.io.EOFException: eof unexpected
   at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45) ~[nio-1.0.0.jar:na]
   at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103) ~[nio-1.0.0.jar:na]
   at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:79) ~[http-1.0.0.jar:na]
   at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51) [nio-1.0.0.jar:na]
   at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:123) [nio-1.0.0.jar:na]"

   В приведенном выше примере видно, что при попытке обработчика сообщений прочитать ответ от бэкэнда произошла ошибка java.io.EOFException: eof unexpected error occurred. Это исключение указывает на неожиданное достижение конца файла (EOF) или конца потока.

   То есть, обработчик сообщений отправил API-запрос на бэкэнд-сервер и ожидал или читал ответ. Однако бэкэнд-сервер внезапно разорвал соединение до того, как обработчик сообщений получил ответ или смог прочитать его полностью.

3. Проверьте журналы вашего бэкэнд-сервера и посмотрите, нет ли там ошибок или информации, которые могли бы привести к внезапному разрыву соединения. Если вы обнаружите какие-либо ошибки/информацию, перейдите в раздел «Решение» и исправьте проблему соответствующим образом на вашем бэкэнд-сервере.
4. Если вы не обнаружите никаких ошибок или информации на вашем бэкэнд-сервере, соберите вывод tcpdump на обработчиках сообщений:
   1. Если ваш сервер бэкэнда имеет один IP-адрес, используйте следующую команду:

      tcpdump -i any -s 0 host IP_ADDRESS -w FILE_NAME

   2. Если ваш сервер бэкэнда имеет несколько IP-адресов, используйте следующую команду:

      tcpdump -i any -s 0 host HOSTNAME -w FILE_NAME

      Как правило, эта ошибка возникает из-за того, что серверная часть отвечает сообщением [FIN,ACK] сразу после того, как обработчик сообщений отправляет запрос на серверную часть.

5. Рассмотрим следующий пример tcpdump .

   Пример tcpdump полученного при возникновении 502 Bad Gateway Error ( UnexpectedEOFAtTarget ).

   

6. Из вывода TCPDump вы заметите следующую последовательность событий:
   1. В пакете 985 обработчик сообщений отправляет API-запрос на бэкэнд-сервер.
   2. В пакете 986 серверная часть немедленно отвечает сообщением [FIN,ACK] .
   3. В пакете 987 обработчик сообщений отправляет на серверную часть ответ [FIN,ACK] .
   4. В конечном итоге соединения замыкаются с [ACK] и [RST] с обеих сторон.
   5. Поскольку серверная часть отправляет [FIN,ACK] , возникает исключение java.io.EOFException: eof unexpected exception в обработчике сообщений.
7. Это может произойти из-за проблем с сетью на бэкэнд-сервере. Обратитесь к вашей команде по эксплуатации сети для дальнейшего расследования этой проблемы.

Разрешение

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

Если проблема сохраняется и вам нужна помощь в устранении ошибки 502 Bad Gateway Error , или вы подозреваете, что проблема связана с Edge, обратитесь в службу поддержки Apigee Edge .

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

Прежде чем диагностировать причину ошибок 502 , пожалуйста, ознакомьтесь со следующими понятиями.

Постоянные связи в Apigee

По умолчанию Apigee (в соответствии со стандартом HTTP/1.1) использует постоянные соединения при обмене данными с целевым бэкэнд-сервером. Постоянные соединения могут повысить производительность, позволяя повторно использовать уже установленное TCP-соединение и (при необходимости) TLS/SSL-соединение, что снижает накладные расходы на задержку. Продолжительность, в течение которой соединение должно оставаться постоянным, контролируется свойством keepalive timeout ( keepalive.timeout.millis ).

Как серверная часть, так и обработчик сообщений Apigee используют таймауты поддержания соединения для сохранения открытых связей друг с другом. Как только в течение этого времени не поступают данные, серверная часть или обработчик сообщений могут закрыть соединение друг с другом.

Для API-прокси, развернутых в обработчике сообщений Apigee, по умолчанию установлено время ожидания соединения 60s если оно не изменено. Если в течение 60s не поступают данные, Apigee закроет соединение с бэкэнд-сервером. Бэкэнд-сервер также будет поддерживать время ожидания соединения, и по истечении этого времени он закроет соединение с обработчиком сообщений.

Последствия неправильной настройки таймаута поддержания соединения

Если в Apigee или на бэкэнд-сервере установлены некорректные таймауты поддержания соединения, это приводит к состоянию гонки, в результате которого бэкэнд-сервер отправляет неожиданное сообщение End Of File (FIN) в ответ на запрос ресурса.

Например, если в API-прокси или обработчике сообщений задано значение таймаута keep-alive, большее или равное таймауту вышестоящего бэкэнд-сервера, может возникнуть следующая ситуация гонки. То есть, если обработчик сообщений не получает никаких данных до тех пор, пока не приблизится к пороговому значению таймаута keep-alive бэкэнд-сервера, то запрос поступает и отправляется на бэкэнд-сервер, используя существующее соединение. Это может привести к ошибке 502 Bad Gateway из-за неожиданного конца файла, как описано ниже:

1. Допустим, время ожидания "keep alive" на процессоре сообщений и на бэкэнд-сервере установлено на 60 секунд, и новый запрос не поступает до тех пор, пока не пройдет 59 секунд после обработки предыдущего запроса конкретным процессором сообщений.
2. Обработчик сообщений обрабатывает запрос, поступивший на 59-й секунде, используя существующее соединение (поскольку время ожидания подтверждения соединения еще не истекло), и отправляет запрос на бэкэнд-сервер.
3. Однако, прежде чем запрос достигнет серверной части, на этом сервере уже будет превышен пороговый уровень таймаута поддержания соединения.
4. Запрос обработчика сообщений на получение ресурса находится в процессе обработки, но серверная часть пытается закрыть соединение, отправляя обработчику сообщений пакет FIN .
5. Пока обработчик сообщений ожидает получения данных, он получает неожиданное FIN , и соединение разрывается.
6. Это приводит к Unexpected EOF , и впоследствии обработчик сообщений возвращает клиенту ошибку 502 .

В данном случае мы обнаружили, что ошибка 502 возникла из-за того, что на процессоре сообщений и на бэкэнд-сервере было установлено одинаковое значение таймаута keep-alive — 60 секунд. Аналогичная проблема может возникнуть и в том случае, если на процессоре сообщений установлено большее значение таймаута keep-alive, чем на бэкэнд-сервере.

Диагноз

1. Если вы являетесь пользователем публичного облака :
   1. Используйте инструмент мониторинга API или трассировки (как описано в разделе «Общие шаги диагностики ») и убедитесь, что у вас установлены обе следующие настройки:
      • Код ошибки: messaging.adaptors.http.flow.UnexpectedEOFAtTarget
      • Источник неисправности: target
   2. Для дальнейшего анализа перейдите к разделу «Использование tcpdump» .
2. Если вы используете частное облако :
   1. Используйте инструмент трассировки или журналы доступа NGINX , чтобы определить идентификатор сообщения, код ошибки и источник ошибки 502 .
   2. Найдите идентификатор сообщения в журнале обработчика сообщений.
      ( /opt/apigee/var/log/edge-message-processor/logs/system.log ).
   3. Вы увидите сообщение java.io.EOFEXception: eof unexpected , как показано ниже:

      2020-11-22 14:42:39,917 org:myorg env:prod api:myproxy rev:1 messageid:myorg-opdk-dc1-node2-17812-56001-1  NIOThread@1 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() :  ClientChannel[Connected: Remote:51.254.225.9:80 Local:10.154.0.61:35326]@12972 useCount=7 bytesRead=0 bytesWritten=159 age=7872ms  lastIO=479ms  isOpen=true.onExceptionRead exception: {}
              java.io.EOFException: eof unexpected
              at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45)
              at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103)
              at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:80)
              at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51)
              at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:220)

   4. Ошибка java.io.EOFException: eof unexpected указывает на то, что обработчик сообщений получил EOF пока ожидал ответа от бэкэнд-сервера.
   5. Атрибут useCount=7 в приведенном выше сообщении об ошибке указывает на то, что обработчик сообщений повторно использовал это соединение около семи раз, а атрибут bytesWritten=159 указывает на то, что обработчик сообщений отправил запрос размером 159 байт на серверную часть. Однако он получил обратно ноль байтов, когда неожиданно возник EOF .

   6. Это показывает, что обработчик сообщений повторно использовал одно и то же соединение несколько раз, и в этот раз он отправил данные, но вскоре после этого получил сообщение EOF конец файла) до того, как были получены какие-либо данные. Это означает, что существует высокая вероятность того, что время ожидания соединения на бэкэнд-сервере короче или равно времени ожидания, установленному в API-прокси.

      Дальнейшее расследование можно провести с помощью программы tcpdump , как описано ниже.

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

1. Для захвата tcpdump на бэкэнд-сервере используйте следующую команду:

   tcpdump -i any -s 0 host MP_IP_Address -w File_Name

2. Проанализируйте полученный с помощью tcpdump файл:

   Вот пример вывода команды tcpdump:

   

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

   1. В пакете 5992, серверная часть получила GET запрос.
   2. В пакете 6064 он отвечает кодом 200 OK.
   3. В пакете 6084 серверная часть получила еще один GET запрос.
   4. В пакете 6154 он отвечает кодом 200 OK .
   5. В пакете 6228 серверная часть получила третий GET запрос.
   6. На этот раз серверная часть возвращает FIN, ACK обработчику сообщений (пакет 6285 ), инициируя закрытие соединения.

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

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

1. По умолчанию Apigee использует значение 60 секунд для свойства keep alive timeout.

2. Однако возможно, что вы переопределили значение по умолчанию в API-прокси. Вы можете проверить это, изучив конкретное определение TargetEndpoint в неисправном API-прокси, выдающем ошибки 502 .

   Пример конфигурации TargetEndpoint:

   <TargetEndpoint name="default">
     <HTTPTargetConnection>
       <URL>https://mocktarget.apigee.net/json</URL>
       <Properties>
         <Property name="keepalive.timeout.millis">30000</Property>
       </Properties>
     </HTTPTargetConnection>
   </TargetEndpoint>

   В приведенном выше примере свойство keep alive timeout переопределено значением 30 секунд ( 30000 миллисекунд).

3. Далее проверьте параметр keep alive timeout, настроенный на вашем бэкэнд-сервере. Допустим, на вашем бэкэнд-сервере установлено значение 25 seconds .
4. Если вы обнаружите, что значение свойства keep alive timeout в Apigee превышает значение этого же свойства на бэкэнд-сервере, как в приведенном выше примере, то это и является причиной ошибок 502 .

Разрешение

Убедитесь, что значение параметра keep alive timeout в Apigee (в компоненте API Proxy and Message Processor) всегда меньше, чем на бэкэнд-сервере.

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

Если проблема сохраняется, перейдите к разделу «Необходимо собрать диагностическую информацию» .

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

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

1. Время ожидания соединения с клиентом должно быть меньше времени ожидания соединения с пограничным маршрутизатором.
2. Время ожидания соединения на пограничном маршрутизаторе должно быть меньше времени ожидания соединения на процессоре сообщений.
3. Время ожидания соединения в обработчике сообщений должно быть меньше времени ожидания соединения на целевом сервере.
4. Если перед Apigee или за ним находятся другие узлы, следует применять то же правило. Ответственность за закрытие соединения с вышестоящим клиентом всегда должна лежать на нижестоящем клиенте.

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

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

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

• Название организации
• Название среды
• Имя API-прокси
• Выполните команду curl для воспроизведения ошибки 502
• Файл трассировки, содержащий запросы с ошибкой 502 Bad Gateway - Unexpected EOF
• Если ошибки 502 в настоящее время не возникают, укажите период времени с информацией о часовом поясе, когда ошибки 502 возникали в прошлом.

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

• Полное сообщение об ошибке, полученное для неудачных запросов.
• Название организации, имя среды и имя API-прокси, для которых наблюдаются ошибки 502
• Пакет API-прокси
• Файл трассировки, содержащий запросы с ошибкой 502 Bad Gateway - Unexpected EOF
• Журналы доступа NGINX
  /opt/apigee/var/log/edge-router/nginx/ ORG ~ ENV . PORT# _access_log
• Журналы обработчика сообщений
  /opt/apigee/var/log/edge-message-processor/logs/system.log
• Период времени с указанием часового пояса, когда возникали ошибки 502
• Tcpdumps собирались на процессорах сообщений или на бэкэнд-сервере, или на обоих одновременно в момент возникновения ошибки.