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

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

Симптом

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

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

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

HTTP/1.1 502 Bad Gateway

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

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

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

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

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

Причина: превышение времени ожидания при установлении соединения TLS/SSL.

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

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

Диагноз

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

Исследование результатов сеанса трассировки

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

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

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

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

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

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

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

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

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

Если вы используете Apigee Edge Private Cloud, выполните следующие шаги, чтобы определить причину ошибки подтверждения соединения. На этом шаге изучите файл журнала обработчика сообщений для получения соответствующей информации. Если вы используете 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» .

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

Дополнительные диагностические шаги для пользователей частного и публичного облака Edge

Для более точного определения проблемы можно использовать инструмент 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-рукопожатие успешно завершается в первых 3 пакетах.

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

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

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

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

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

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

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

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

Разрешение

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

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

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

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

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

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