502 Ошибка тайм-аута неверного шлюза

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

Симптом

Клиентское приложение получает ошибку 502 Bad Gateway . Процессор сообщений возвращает эту ошибку клиентскому приложению, если оно не получает ответа от внутреннего сервера.

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

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

HTTP/1.1 502 Bad Gateway

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

{
 "fault": {
    "faultstring":"Bad Gateway",
    "detail":{
        "errorcode":"messaging.adaptors.http.flow.BadGateway"
    }
 }
}

Возможная причина

Возможная причина этой проблемы указана в следующей таблице:

Причина Описание Действия по устранению неполадок можно выполнить,
Тайм-аут установления связи TLS/SSL Во время установления связи TLS/SSL между процессором сообщений и внутренним сервером происходит тайм-аут. Пользователи Edge частного и публичного облака

Причина: тайм-аут установления связи TLS/SSL.

В Apigee Edge вы можете настроить соединение TLS/SSL с внутренним сервером, чтобы включить связь TLS между пограничным процессором сообщений и внутренним сервером.

Подтверждение TLS/SSL включает в себя несколько этапов. Эта ошибка обычно возникает, когда истекает время установления связи TLS/SSL между процессором сообщений и внутренним сервером.

Диагностика

В этом разделе объясняется, как правильно диагностировать тайм-аут подтверждения TLS/SSL. Приведены инструкции для Edge Private Cloud и Public Cloud.

Изучите выходные данные сеанса трассировки

Следующие шаги объясняют, как выполнить предварительную диагностику проблемы с помощью инструмента Apigee Edge Trace.

  1. В пользовательском интерфейсе Edge включите сеанс трассировки для затронутого прокси-сервера API.

  2. Если трассировка неудачного запроса API показывает следующее, вероятно, произошла ошибка тайм-аута установления связи TLS/SSL. Вероятная причина ошибки заключается в том, что брандмауэр внутреннего сервера блокирует трафик от Apigee.

    1. Определите, возникает ли ошибка 502 Bad Gateway через 55 секунд , что является периодом ожидания по умолчанию, установленным в процессоре сообщений. Если вы видите, что ошибка произошла через 55 секунд, это говорит о том, что вероятной причиной проблемы был тайм-аут.
    2. Определите, указывает ли ошибка на неисправность: messages.adaptors.http.BadGateway . Опять же, эта ошибка обычно указывает на истечение времени ожидания.

    3. Если вы используете Edge Private Cloud , обратите внимание на значение поля X-Apigee.Message-ID в выходных данных трассировки, как показано ниже. Пользователь частного облака может использовать это значение идентификатора для дальнейшего устранения неполадок, как описано ниже.

      1. Щелкните значок «Записанные данные аналитики» в пути трассировки:

      2. Прокрутите вниз и обратите внимание на значение поля X-Apigee.Message-ID .

Чтобы убедиться, что тайм-аут установления связи TLS/SSL стал причиной ошибки, выполните действия, описанные в следующих разделах, в зависимости от того, находитесь ли вы в общедоступном или частном облаке.

Дополнительные действия по диагностике только для пользователей Edge Private Cloud

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

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

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

      telnet BackendServer-IPaddress 443

    2. Если внутренний сервер разрешает несколько IP-адресов, используйте имя хоста внутреннего сервера в команде telnet, как показано ниже:

      telnet BackendServer-HostName 443

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

    Если команда telnet не удалась, вам необходимо вместе со своей сетевой командой проверить соединение между обработчиком сообщений и внутренним сервером.

  2. Проверьте файл журнала процессора сообщений на наличие признаков сбоя квитирования. Откройте файл:

    /opt/apigee/var/log/edge-message-processor/system.log

    и найдите уникальный идентификатор сообщения (значение X-Apigee.Message-ID , найденное в файле трассировки). Определите, видите ли вы сообщение об ошибке установления связи, связанное с идентификатором сообщения, как показано ниже:

    org:xxx env:xxx api:xxx rev:x messageid:<MESSAGE_ID> NIOThread@1 ERROR HTTP.CLIENT -
HTTPClient$Context.handshakeTimeout() : SSLClientChannel[Connected: Remote:X.X.X.X:443
Local:X.X.X.X]@739028 useCount=1 bytesRead=0 bytesWritten=0 age=55221ms lastIO=55221ms
isOpen=true handshake timeout

Если вы видите эту ошибку в файле журнала обработчика сообщений, продолжайте дальнейшее расследование. Перейдите к разделу «Дальнейшие действия по диагностике для пользователей Edge Private и Public Cloud» .

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

Дальнейшие действия по диагностике для пользователей Edge Private и Public Cloud

Чтобы дополнительно определить проблему, вы можете использовать инструмент tcpdump для анализа пакетов TCP/IP, чтобы подтвердить, произошел ли тайм-аут во время установления связи TLS/SSL.

  1. Если вы являетесь пользователем частного облака , вы можете перехватывать пакеты TCP/IP на внутреннем сервере или в процессоре сообщений. Предпочтительно перехватывать их на внутреннем сервере, поскольку пакеты расшифровываются на внутреннем сервере.
  2. Если вы являетесь пользователем общедоступного облака , у вас нет доступа к процессору сообщений; однако перехват пакетов TCP/IP на внутреннем сервере может помочь выявить проблему.

  3. Решив, где захватывать пакеты TCP/IP, используйте следующую команду tcpdump для захвата пакетов TCP/IP.

    tcpdump -i any -s 0 host <IP address> -w <File name>

    • Если вы принимаете пакеты TCP/IP на внутреннем сервере, используйте общедоступный IP-адрес процессора сообщений в команде tcpdump . Справку по использованию команды для проверки трафика внутреннего сервера см. в разделе tcpdump .

    • Если вы принимаете пакеты TCP/IP на процессоре сообщений, используйте общедоступный IP-адрес внутреннего сервера в команде tcpdump . Справку по использованию команды для проверки трафика процессора сообщений см. в разделе tcpdump .

    • Если для внутреннего сервера/процессора сообщений имеется несколько IP-адресов, вам нужно попробовать использовать другую команду tcpdump . Обратитесь к tcpdump для получения дополнительной информации об этом инструменте и других вариантах этой команды.

  4. Проанализируйте пакеты TCP/IP с помощью инструмента Wireshark или аналогичного инструмента. На следующем снимке экрана показаны пакеты TCP/IP в Wireshark.

  5. Обратите внимание на выходные данные Wireshark, что трехстороннее TCP-квитирование успешно завершается в первых трех пакетах.

  6. Затем процессор сообщений отправляет сообщение «Client Hello» в пакете №4.

  7. Поскольку подтверждение от внутреннего сервера отсутствует, процессор сообщений повторно передает сообщение «Client Hello» несколько раз в пакетах 5, 6 и 7 после ожидания заранее определенного интервала времени.

  8. Когда процессор сообщений не получает никакого подтверждения после трех повторных попыток, он отправляет сообщение FIN, ACK на внутренний сервер, чтобы указать, что он закрывает соединение.

  9. Как показано в примере сеанса Wireshark, соединение с серверной частью установлено успешно (шаг № 1), однако время ожидания SSL-подтверждения истекло, поскольку внутренний сервер не ответил.

Если вы выполнили действия по устранению неполадок, описанные в этом руководстве, и определили, что тайм-аут вызвал ошибку подтверждения TLS/SSL, перейдите в раздел «Решение» .

Использование мониторинга API для выявления проблемы

Мониторинг API позволяет быстро изолировать проблемные области для диагностики ошибок, проблем с производительностью и задержкой, а также их источников, таких как приложения для разработчиков, прокси-серверы API, целевые серверные части или платформа API.

Ознакомьтесь с примером сценария , который демонстрирует, как устранять проблемы 5xx с вашими API с помощью мониторинга API. Например, вы можете настроить оповещение, которое будет уведомляться, когда количество ошибок messages.adaptors.http.BadGateway превышает определенный порог.

Разрешение

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

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

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

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

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

  1. Если вы являетесь пользователем Public Cloud, предоставьте следующую информацию:
    1. Название организации
    2. Имя среды
    3. Имя прокси API
    4. Завершите команду Curl, чтобы воспроизвести ошибку.
    5. Файл трассировки, показывающий ошибку
    6. Пакеты TCP/IP, перехваченные на внутреннем сервере
  2. Если вы являетесь пользователем частного облака, предоставьте следующую информацию:
    1. Обнаружено полное сообщение об ошибке
    2. Пакет API-прокси
    3. Файл трассировки, показывающий ошибку
    4. Журналы процессора сообщений /opt/apigee/var/log/edge-message-processor/logs/system.log
    5. Пакеты TCP/IP, захватываемые внутренним сервером или процессором сообщений.
  3. Подробная информация о том, какие разделы этого руководства вы пробовали, а также любые другие сведения, которые помогут нам ускорить решение этой проблемы.