502 Bad Gateway Unexpected EOF

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

Symptom

Клиентское приложение получает код статуса 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. Получите определение целевого сервера, используя вызов Edge Management API:
   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 или закроет подключение. В результате в Message Processor появляется ошибка 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. Проверьте журналы Message Processor (/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) или потока.

   То есть Message Processor отправил запрос к 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] сразу после того, как Message Processor отправляет запрос на сервер бэкэнда.

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

   Образец tcpdump, взятый при возникновении 502 Bad Gateway Error (UnexpectedEOFAtTarget)

   

6. В выходных данных TCPDump вы заметите следующую последовательность событий:
   1. В пакете 985 Message Processor отправляет запрос к API на бэкенд-сервер.
   2. В пакете 986 внутренний сервер сразу же отправляет ответ [FIN,ACK].
   3. В пакете 987 Message Processor отправляет ответ [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-подключение, что снижает задержку. Продолжительность, в течение которой соединение должно поддерживаться, определяется с помощью свойства keep alive timeout (keepalive.timeout.millis).

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

По умолчанию для прокси API, развернутых в Message Processor в Apigee, задано время ожидания активности 60s, если не переопределено. Если данные от 60s не поступают, Apigee закрывает подключение к внутреннему серверу. Внутренний сервер также поддерживает тайм-аут keep-alive, и по его истечении закрывает соединение с процессором сообщений.

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

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

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

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

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

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

1. Если вы пользователь общедоступного облака:
   1. Используйте инструмент мониторинга API или трассировки (как описано в разделе Общие шаги диагностики) и убедитесь, что у вас заданы следующие настройки:
      • Код ошибки: messaging.adaptors.http.flow.UnexpectedEOFAtTarget
      • Источник ошибки: target
   2. Подробнее об использовании tcpdump…
2. Если вы используете частное облако:
   1. Используйте инструмент трассировки или журналы доступа NGINX, чтобы определить идентификатор сообщения, код ошибки и источник ошибки 502.
   2. Найдите идентификатор сообщения в журнале Message Processor
      (/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 в приведенном выше сообщении об ошибке указывает, что Message Processor повторно использовал это подключение примерно семь раз, а атрибут bytesWritten=159 – что Message Processor отправил на бэкенд-сервер полезную нагрузку запроса размером 159 байт. Однако при возникновении ошибки EOF было получено ноль байтов.

   6. Это означает, что Message Processor несколько раз использовал одно и то же подключение, и в этот раз он отправил данные, но вскоре после этого получил 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), инициируя закрытие соединения.

   В этом примере одно и то же подключение дважды успешно использовалось, но при третьем запросе бэкенд-сервер инициирует закрытие подключения, в то время как Message Processor ожидает данные от бэкенд-сервера. Это означает, что время ожидания активности на бэкенд-сервере, скорее всего, меньше или равно значению, заданному в прокси-сервере API. Чтобы проверить это, ознакомьтесь с разделом Сравнение времени ожидания Keep-Alive в Apigee и на сервере бэкэнда.

Сравнение времени ожидания keep-alive в Apigee и на внутреннем сервере

1. По умолчанию Apigee использует для свойства keep alive timeout значение 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>

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

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

Разрешение

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

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

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

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

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

1. Время ожидания клиента должно быть меньше времени ожидания пограничного маршрутизатора.
2. Время ожидания сообщения keep-alive для маршрутизатора Edge должно быть меньше, чем для Message Processor.
3. Время ожидания активности Message Processor должно быть меньше времени ожидания активности целевого сервера.
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, собранные на процессорах сообщений или внутреннем сервере, или на обоих, когда произошла ошибка.