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

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

Симптом

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

Код состояния 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. Вам необходимо иметь атрибуты SSLInfo с флагами ClientAuthEnabled , Keystore , KeyAlias ​​и Truststore , установленными соответствующим образом, как показано ниже:

      <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 произошла, когда процессор сообщений пытается прочитать ответ от внутреннего сервера. Это исключение указывает на конец файла (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 исключение в процессоре сообщений.
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 или процессоре сообщений со значением, большим или равным тайм-ауту вышестоящего внутреннего сервера, может возникнуть следующее состояние гонки. То есть, если процессор сообщений не получает никаких данных до тех пор, пока не приблизится к пороговому значению тайм-аута поддержания активности внутреннего сервера, то запрос поступает и отправляется на внутренний сервер с использованием существующего соединения. Это может привести к 502 Bad Gateway из-за неожиданной ошибки EOF, как описано ниже:

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

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

Диагностика

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 секунд для свойства тайм-аута поддержания активности.

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>

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

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

Разрешение

Убедитесь, что свойство тайм-аута поддержания активности всегда меньше в Apigee (в компоненте API-прокси и процессоре сообщений) по сравнению со значением на внутреннем сервере.

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

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

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

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

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

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

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

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

• Название организации
• Имя среды
• Имя 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 собранные на процессорах сообщений или внутреннем сервере (или на обоих) в момент возникновения ошибки.