504 Gateway timeout — тайм-аут маршрутизатора

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

Симптом

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

Этот ответ об ошибке указывает на то, что клиент не получил своевременный ответ от Apigee Edge или внутреннего сервера во время выполнения вызова API.

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

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

HTTP/1.1 504 Gateway Time-out

При вызове такого прокси с помощью cURL или веб-браузера вы можете получить следующую ошибку:

<!DOCTYPE html>
<html>
<head>
<title>Error</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>An error occurred.</h1>
<p>Sorry, the page you are looking for is currently unavailable.<br/>
Please try again later.</p>
</body>
</html>

Что вызывает таймауты?

Типичный путь запроса API через платформу Edge — Клиент > Маршрутизатор > Обработчик сообщений > Внутренний сервер, как показано на следующем рисунке:

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

В этом сборнике описывается, как устранить и устранить ошибку 504 , возникающую при истечении времени ожидания маршрутизатора.

Тайм-аут на маршрутизаторе

Тайм-аут по умолчанию, настроенный на маршрутизаторах в Apigee Edge, составляет 57 секунд. Это максимальное время, в течение которого прокси-сервер API может выполняться с момента получения запроса API на Edge до момента отправки ответа обратно, включая ответ серверной части и все выполняемые политики. Тайм-аут по умолчанию можно переопределить на маршрутизаторах/виртуальных хостах, как описано в разделе «Настройка тайм-аута ввода-вывода на маршрутизаторах» .

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

В Edge типичными причинами ошибки 504 Gateway Timeout вызванной тайм-аутом маршрутизатора, являются:

Причина Описание Инструкции по устранению неполадок применимы для
Неправильная настройка тайм-аута на маршрутизаторе. Это происходит, если маршрутизатор настроен с неправильным периодом ожидания ввода-вывода. Пользователи Edge Public и Private Cloud

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

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

  • API-мониторинг
  • Журналы доступа NGINX

API-мониторинг

Чтобы диагностировать ошибку с помощью мониторинга API:

  1. Перейдите на страницу Анализ > Мониторинг API > Расследование .
  2. Отфильтруйте ошибки 5xx и выберите таймфрейм.
  3. Постройте график кода состояния в зависимости от времени .

  4. Щелкните конкретную ячейку, показывающую ошибки 504 , чтобы просмотреть более подробную информацию и просмотреть журналы об этих ошибках, как показано ниже:

    Пример, показывающий ошибки 504

  5. На правой панели нажмите « Просмотреть журналы» .

    В окне «Журналы трафика» обратите внимание на следующие сведения о некоторых ошибках 504 :

    • Запрос: предоставляет метод запроса и URI, используемые для совершения вызовов.
    • Время ответа : показывает общее время, затраченное на запрос.

    В приведенном выше примере

    • Запрос указывает на GET /test-timeout .
    • Время отклика составляет 57.001 секунды. Это указывает на то, что у маршрутизатора истекло время ожидания, прежде чем процессор сообщений смог ответить, поскольку значение очень близко к значению времени ожидания ввода-вывода по умолчанию, установленному на маршрутизаторе, которое составляет 57 секунд.

    Вы также можете получить все журналы с помощью API журналов GET для мониторинга API. Например, запросив журналы для org , env , timeRange и status , вы сможете загрузить все журналы для транзакций, в которых у клиента истекло время ожидания.

    Поскольку мониторинг API устанавливает для прокси-сервера значение - (не установлено) для этих ошибок 504 , вы можете использовать API ( API журналов ), чтобы получить связанный прокси-сервер для виртуального хоста и пути.

    Например :

    curl "https://apimonitoring.enterprise.apigee.com/logs/apiproxies?org=ORG&env=ENV&select=https
  6. Просмотрите время ответа на наличие дополнительных ошибок 504 и проверьте, является ли время ответа постоянным (значение тайм-аута ввода-вывода, установленное на маршрутизаторе, равное 57 секундам) для всех ошибок 504 .

Журналы доступа NGINX

Чтобы диагностировать ошибку с помощью журналов доступа NGINX:

  1. Проверьте журналы доступа NGINX:
    /opt/apigee/var/log/edge-router/nginx/ ORG ~ ENV . PORT# _access_log
  2. Выполните поиск, чтобы узнать, возникли ли какие-либо ошибки 504 в течение определенного периода времени (если проблема возникла в прошлом) или есть ли какие-либо запросы, которые по-прежнему завершаются с ошибкой 504 .
  3. Обратите внимание на следующую информацию для некоторых ошибок 504 :
    • Время ответа
    • Запрос URI

    В этом примере мы видим следующую информацию:

    • Время запроса: 57.001 секунды. Это означает, что время ожидания маршрутизатора истекло через 57,001 секунды.

    • Запрос: GET /test-timeout
    • Псевдоним хоста : myorg-test.apigee.net .

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

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

  5. Определите прокси-сервер API, для которого был сделан запрос, используя базовый путь в поле «Запрос» .

Причина: Неправильная конфигурация тайм-аута на маршрутизаторе.

Диагностика

  1. Определите, вызваны ли ошибки 504 тем, что у маршрутизатора истекло время ожидания, прежде чем процессор сообщений смог ответить. Вы можете сделать это, проверив, совпадает ли время ответа в API-мониторинге/ время запроса в маршрутизаторе (оба поля представляют одну и ту же информацию, но называются разными именами) и тайм-аут ввода-вывода, настроенный на маршрутизаторе/виртуальном устройстве. хост и поля «Источник сбоя» , «Прокси-сервер сбоя» и «Код сбоя» настроены - использование журналов мониторинга API или доступа NGINX, как описано в разделе «Общие шаги диагностики» .

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

    Вы можете сделать это, выполнив действия, описанные в этом разделе.

Проверка тайм-аута ввода-вывода на виртуальных хостах

Пограничный интерфейс

Чтобы проверить тайм-аут виртуального хоста с помощью пользовательского интерфейса Edge, выполните следующие действия:

  1. Войдите в пользовательский интерфейс Edge.
  2. Перейдите в «Администратор» > «Виртуальные хосты» .
  3. Выберите конкретную среду , в которой возникла проблема с тайм-аутом.
  4. Выберите конкретный виртуальный хост, для которого вы хотите проверить значение тайм-аута ввода-вывода.
  5. В разделе «Свойства» просмотрите значение «Таймаут чтения прокси» в секундах.

    В приведенном выше примере время ожидания чтения прокси настроено на значение 120 . Это означает, что тайм-аут ввода-вывода, настроенный на этом виртуальном хосте, составляет 120 секунд.

API управления

Вы также можете проверить тайм-аут чтения прокси-сервера, используя следующие API управления:

  1. Выполните API получения виртуального хоста , чтобы получить конфигурацию virtualhost , как показано ниже:

    Пользователь публичного облака

    curl -v -X GET https://api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/virtualhosts/VIRTUALHOST_NAME -u USERNAME

    Пользователь частного облака

    curl -v -X GET http://MANAGEMENT_SERVER_HOST:PORT#/v1/organizations/ORGANIZATION_NAME/environments/v/virtualhosts/VIRTUALHOST_NAME -u USERNAME

    Где:

    ORGANIZATION_NAME — название организации.

    ENVIRONMENT_NAME — имя среды.

    VIRTUALHOST_NAME — имя виртуального хоста.

  2. Проверьте значение, настроенное для свойства proxy_read_timeout

    Пример определения виртуального хоста

    {
  "hostAliases": [
    "api.myCompany,com",
  ],
  "interfaces": [],
  "listenOptions": [],
  "name": "secure",
  "port": "443",
  "retryOptions": [],
  "properties": {
    "property": [
      {
        "name": "proxy_read_timeout",
        "value": "120"
      }
    ]
  },
  "sSLInfo": {
    "ciphers": [],
    "clientAuthEnabled": "false",
    "enabled": "true",
    "ignoreValidationErrors": false,
    "keyAlias": "myCompanyKeyAlias",
    "keyStore": "ref://myCompanyKeystoreref",
    "protocols": []
  },
  "useBuiltInFreeTrialCert": false
}

    В приведенном выше примере proxy_read_timeout настроен со значением 120 . Это означает, что тайм-аут ввода-вывода, настроенный на этом виртуальном хосте, составляет 120 секунд.

Проверка тайм-аута ввода-вывода в файле router.properties

  1. Войдите в систему маршрутизатора.
  2. Найдите свойство proxy_read_timeout в каталоге /opt/nginx/conf.d и проверьте, установлено ли для него новое значение следующим образом: 
    grep -ri "proxy_read_timeout" /opt/nginx/conf.d

  3. Проверьте значение, установленное для свойства proxy_read_timeout в конкретном файле конфигурации виртуального хоста.

    Пример результата команды grep

    /opt/nginx/conf.d/0-default.conf:proxy_read_timeout 57;
/opt/nginx/conf.d/0-edge-health.conf:proxy_read_timeout 1s;

    Обратите внимание, что в приведенном выше примере для свойства proxy_read_timeout установлено новое значение 57 в 0-default.conf который является файлом конфигурации для виртуального хоста по умолчанию. Это означает, что на маршрутизаторе для виртуального хоста по умолчанию тайм-аут ввода-вывода настроен на 57 секунд. Если у вас несколько виртуальных хостов, вы увидите эту информацию для каждого из них. Получите значение proxy_read_timeout для конкретного виртуального хоста, который вы использовали для выполнения вызовов API, которые завершились с ошибкой 504 .

Проверка тайм-аута ввода-вывода в прокси-сервере API

Тайм-аут ввода-вывода можно просмотреть следующим образом:

  • Целевая конечная точка прокси API
  • Политика ServiceCallout для прокси API
Просмотр тайм-аута ввода-вывода в целевой конечной точке прокси API
  1. В пользовательском интерфейсе Edge выберите конкретный прокси-сервер API, в котором вы хотите просмотреть значение тайм-аута ввода-вывода.
  2. Выберите конкретную целевую конечную точку, которую вы хотите проверить.
  3. См. свойство io.timeout.millis с соответствующим значением в элементе <HTTPTargetConnection> в конфигурации TargetEndpoint .

    Например, тайм-аут ввода-вывода в следующем коде установлен на 120 секунд:

    <Properties>
  <Property name="io.timeout.millis">120000</Property>
</Properties>
Просмотр тайм-аута ввода-вывода в политике ServiceCallout прокси-сервера API
  1. В пользовательском интерфейсе Edge выберите конкретный прокси-сервер API, в котором вы хотите просмотреть новое значение тайм-аута ввода-вывода для политики ServiceCallout.
  2. Выберите конкретную политику ServiceCallout, которую вы хотите проверить.

  3. См. элемент <Timeout> с соответствующим значением в конфигурации <ServiceCallout> .

    Например, время ожидания ввода-вывода следующего кода составит 120 секунд: 

    <Timeout>120000</Timeout>

Проверка тайм-аута ввода-вывода на процессорах сообщений

  1. Войдите в систему процессора сообщений.

  2. Найдите свойство HTTPTransport.io.timeout.millis в каталоге /opt/apigee/edge-message-processor/conf используя следующую команду: 

    grep -ri "HTTPTransport.io.timeout.millis" /opt/apigee/edge-message-processor/conf

    Пример вывода 

    /opt/apigee/edge-message-processor/conf/http.properties:HTTPTransport.io.timeout.millis=55000
  3. Обратите внимание, что в приведенном выше примере вывода свойству HTTPTransport.io.timeout.millis присвоено значение 55000 в http.properties . Это означает, что тайм-аут ввода-вывода успешно настроен на процессоре сообщений и составляет 55 секунд.

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

Запишите значения, установленные для всех слоев, как показано в таблице ниже:

Таймаут на маршрутизаторе (секунды) Таймаут на виртуальном хосте (секунды) Тайм-аут процессора сообщений (секунды) Тайм-аут прокси-сервера API (секунды)
57 - 55 120

В этом примере

  • На маршрутизаторе настроено значение по умолчанию 57 секунд.
  • Значение таймаута не установлено на конкретном виртуальном хосте. Это означает, что будет использоваться значение по умолчанию 57 секунд, настроенное на самом маршрутизаторе.
  • В процессоре сообщений настроено значение по умолчанию — 55 секунд.
  • Однако для конкретного прокси-сервера API настроено значение 120 секунд.

Обратите внимание, что более высокое значение тайм-аута настроено только на прокси-сервере API, но маршрутизатор по-прежнему настроен на 57 секунд. Следовательно, время ожидания маршрутизатора составляет 57 секунд, в то время как процессор сообщений/серверная часть все еще обрабатывает ваш запрос. Это приводит к тому, что маршрутизатор возвращает клиентскому приложению ошибку 504 Gateway Timeout .

Разрешение

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

  1. Обратитесь к рекомендациям по настройке тайм-аута ввода-вывода , чтобы понять, какие значения тайм-аута следует устанавливать для различных компонентов, участвующих в потоке запросов API через Apigee Edge.
  2. В приведенном выше примере, если вы убедитесь, что необходимо установить более высокое значение тайм-аута, поскольку внутреннему серверу требуется больше времени, и вы увеличили значение тайм-аута процессора сообщений до 120 секунд, тогда установите более высокое значение тайм-аута. Например : 123 seconds на маршрутизаторе. Чтобы избежать влияния на все прокси-серверы API из-за нового значения тайм-аута, установите значение 123 seconds только на конкретном виртуальном хосте , который используется в конкретном прокси-сервере API.
  3. Следуйте инструкциям в разделе «Настройка тайм-аута ввода-вывода на маршрутизаторах», чтобы установить тайм-аут на виртуальном хосте.