Ошибка 504 Время ответа сервера истекло

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

Симптом

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

Код состояния HTTP - 504 Gateway Timeout указывает на то, что клиент не получил своевременный ответ от пограничного шлюза или бэкэнд-сервера во время выполнения API-запроса.

Сообщения об ошибках

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

HTTP/1.1 504 Gateway Timeout

В некоторых случаях также может отображаться следующее сообщение об ошибке:

{
   "fault": {
      "faultstring": "Gateway Timeout",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.GatewayTimeout"
       }
    }
}

Что вызывает тайм-ауты шлюза?

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

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

В таблице ниже приведена более подробная информация о случаях возникновения таймаутов в Edge:

Произошло превышение времени ожидания Подробности
Произошло превышение времени ожидания в обработчике сообщений.
  • Серверная часть не отвечает обработчику сообщений в течение указанного в обработчике сообщений периода ожидания.
  • Процессор сообщений выдает ошибку тайм-аута и отправляет маршрутизатору ответ со статусом 504 Gateway Timeout .
На маршрутизаторе происходит таймаут.
  • Обработчик сообщений не отвечает маршрутизатору в течение указанного на маршрутизаторе периода ожидания.
  • Маршрутизатор выдает ошибку тайм-аута и отправляет клиентскому приложению ответ со статусом 504 Gateway Timeout .
В клиентском приложении происходит таймаут.
  • Маршрутизатор не отвечает клиентскому приложению в течение указанного на маршрутизаторе периода ожидания.
  • Клиентское приложение выдает ошибку таймаута и завершает ответ с кодом 504 Gateway Timeout для конечного пользователя.

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

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

Причина Подробности Приведены шаги для
Медленный сервер бэкэнда Сервер, обрабатывающий API-запрос, работает слишком медленно из-за высокой нагрузки или низкой производительности. Пользователи публичных и частных облаков
Медленная обработка запросов API со стороны Edge. Edge долго обрабатывает запросы к API из-за высокой нагрузки или низкой производительности.

Медленный сервер бэкэнда

Если серверная часть работает очень медленно или обрабатывает запрос API слишком долго, вы получите ошибку 504 Gateway Timeout . Как пояснялось в предыдущем разделе, таймаут может произойти в одном из следующих случаев:

  1. Сообщения обработчика истекают по таймауту до того, как серверная часть ответит.
  2. Маршрутизатор выдает ошибку тайм-аута до того, как обработчик сообщений/бэкэнд-сервер ответит.
  3. Клиентское приложение выдает ошибку тайм-аута до того, как маршрутизатор/обработчик сообщений/бэкэнд-сервер ответит.

В следующих разделах описано, как диагностировать и устранить проблему в каждом из этих сценариев.

Сценарий №1: Процессор обработки сообщений выдает ошибку тайм-аута до того, как серверная часть ответит.

Диагноз

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

Процедура №1. Использование трассировки.

Если проблема сохраняется (по-прежнему возникают ошибки 504 ), выполните следующие действия:

  1. Проверьте работу затронутого API в пользовательском интерфейсе Edge. Либо дождитесь возникновения ошибки, либо, если у вас есть вызов API, выполните несколько вызовов API и воспроизведите ошибку 504 Gateway Timeout .
  2. После возникновения ошибки изучите конкретный запрос, в котором отображается код ответа 504 .
  3. Проверьте прошедшее время на каждом этапе и отметьте этап, на который было потрачено больше всего времени.
  4. Если ошибка с наибольшим задержкой возникает сразу после одного из следующих этапов, это указывает на медленную работу бэкэнд-сервера или на длительное время обработки запроса:
    • Запрос отправлен на целевой сервер.
    • Политика вызова сервисной службы

Ниже приведён пример трассировки, показывающий, что серверная часть не ответила даже через 55 секунд, что привело к ошибке 504 Gateway Timeout :

В приведенном выше примере трассировки процесс обработки сообщений завершается по истечении 55002 мс, поскольку серверная часть не отвечает.

Процедура №2. Использование журналов обработчика сообщений.

  1. Проверьте журнал обработчика сообщений ( /opt/apigee/var/log/edge-message-processor/logs/system.log )

  2. Если для конкретного запроса к API-прокси в определенный момент времени вы обнаружите ошибки Gateway Timeout и onTimeoutRead , это означает, что у обработчика сообщений истекло время ожидания.

    Пример журнала обработки сообщений, показывающий ошибку «Тайм-аут шлюза».

    2015-09-29 20:16:54,340 org:myorg env:staging api:profiles rev:13 NIOThread@1
ERROR ADAPTORS.HTTP.FLOW - AbstractResponseListener.onException() :
AbstractResponseListener.onError(HTTPResponse@4d898cf1, Gateway
Timeout)
2015-09-29 20:16:57,361 org:myorg env:staging api:profileNewsletters rev:8
NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onTimeout() :
SSLClientChannel[C:XX.XX.XX.XX:443 Remote
host:192.168.38.54:38302]@120171 useCount=2 bytesRead=0
bytesWritten=824 age=55458ms lastIO=55000ms .onTimeoutRead

    В приведенном выше журнале обработки сообщений вы видите, что серверная часть с IP-адресом XX.XX.XX.XX не ответила даже через 55 секунд ( lastIO=55000ms ). В результате процессор обработки сообщений выдал ошибку тайм-аута 504 Gateway Timeout .

    Посмотрите: Как контролируется время ожидания в обработчике сообщений?

    • Как контролируется таймаут в обработчике сообщений? Обычно для обработчиков сообщений устанавливается значение таймаута по умолчанию , равное 55 секундам, с помощью свойства HTTPTransport.io.timeout.millis . Это значение таймаута применяется ко всем API-прокси, принадлежащим организации, обслуживаемой этим обработчиком сообщений.
      • Если серверная часть не отвечает в течение 55 секунд, то процессор сообщений истекает по таймауту и ​​отправляет клиенту ошибку 504 Gateway Timeout .
    • Значение таймаута, указанное в обработчике сообщений, может быть переопределено свойством io.timeout.millis , указанным в API-прокси. Это значение таймаута применяется к конкретному API-прокси, в котором указано вышеупомянутое свойство. Например, если в API-прокси установлено значение io.timeout.millis равное 10 секундам, то для этого конкретного API-прокси будет использоваться значение таймаута 10 секунд.
      • Если серверная часть не отвечает в течение 10 секунд для конкретного API-прокси, то обработчик сообщений истекает по таймауту и ​​отправляет клиенту ошибку 504 Gateway Timeout .

Разрешение

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

Сценарий №2 — Маршрутизатор выдает ошибку тайм-аута до того, как обработчик сообщений/бэкэнд-сервер ответит.

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

  • Значение тайм-аута, установленное на маршрутизаторе, короче значения тайм-аута, установленного на обработчике сообщений. Например, предположим, что тайм-аут на маршрутизаторе составляет 50 секунд, а на обработчике сообщений — 55 секунд.
    Тайм-аут на маршрутизаторе Истекло время ожидания в обработчике сообщений
    50 секунд 55 секунд
  • Значение таймаута в обработчике сообщений переопределяется более высоким значением таймаута с помощью свойства io.timeout.millis , заданного в конфигурации целевой конечной точки API-прокси:

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

    Тайм-аут на маршрутизаторе Истекло время ожидания в обработчике сообщений Истекло время ожидания в API-прокси.
    57 секунд 55 секунд 120 секунд

    Однако в API-прокси параметр io.timeout.millis установлен на 120 секунд:

    <HTTPTargetConnection>
     <Properties>
          <Property name="io.timeout.millis">120000</Property>
      </Properties>
      <URL>http://www.apigee.com</URL>
</HTTPTargetConnection>

    В таком случае обработчик сообщений не завершит работу по истечении 55 секунд, даже если его значение тайм-аута (55 секунд) меньше значения тайм-аута маршрутизатора (57 секунд). Это происходит потому, что значение тайм-аута в 55 секунд для обработчика сообщений переопределяется значением в 120 секунд, установленным в API-прокси. Таким образом, значение тайм-аута обработчика сообщений для этого конкретного API-прокси будет равно 120 секундам.

    Поскольку маршрутизатор имеет меньшее значение таймаута (57 секунд) по сравнению со 120 секундами, установленными в API-прокси, маршрутизатор выдаст ошибку таймаута, если серверная часть не ответит в течение 57 секунд.

Диагноз

  1. Проверьте журнал доступа NGINX ( /opt/apigee/var/log/edge-router/nginx/ ORG ~ ENV . PORT# _access_log )

  2. Если маршрутизатор выдает ошибку тайм-аута до обработки сообщений обработчиком сообщений, то в журналах доступа NGINX для конкретного запроса API вы увидите статус 504 , а message id от обработчика сообщений будет установлен как - . Это происходит потому, что маршрутизатор не получил ответа от обработчика сообщений в течение установленного на маршрутизаторе периода ожидания.

    Пример записи в журнале NGINX, показывающей ошибку 504 из-за истечения времени ожидания маршрутизатора.

  3. В приведенном выше примере обратите внимание на статус 504 на NGINX, идентификатор сообщения от обработчика сообщений - , а общее прошедшее время составляет 57,001 секунды. Это произошло потому, что маршрутизатор прервал соединение через 57,001 секунды, и мы не получили никакого ответа от обработчика сообщений.
  4. В этом случае в журналах обработчика сообщений ( /opt/apigee/var/log/edge-message-processor/logs/system.log). вы увидите исключения Broken Pipe . 
    2017-06-09 00:00:25,886 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-mp01-18869-23151-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel(ClientChannel[A:XX.XX.XX.XX:8998 Remote host:YY.YY.YY.YY:51400]@23751 useCount=1 bytesRead=0 bytesWritten=486 age=330465ms  lastIO=0ms )
2017-06-09 00:00:25,887  org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-mp01-18869-23151-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace:
java.io.IOException: Broken pipe
        at com.apigee.nio.channels.ClientOutputChannel.writePending(ClientOutputChannel.java:51) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.onWrite(OutputChannel.java:116) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.write(OutputChannel.java:81) ~[nio-1.0.0.jar:na]
         … <snipped>

Эта ошибка отображается потому, что после истечения таймаута маршрутизатор закрывает соединение с обработчиком сообщений. Когда обработчик сообщений завершает свою обработку, он пытается отправить ответ маршрутизатору. Поскольку соединение с маршрутизатором уже закрыто, в обработчике сообщений возникает Broken Pipe exception .

Это исключение ожидается при обстоятельствах, описанных выше. Таким образом, фактической причиной ошибки 504 Gateway Timeout по-прежнему является задержка ответа со стороны бэкэнд-сервера, и вам необходимо решить эту проблему.

Разрешение

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

      Идея: Установить значение тайм-аута для различных компонентов в следующем порядке:

      Тайм-аут на стороне клиента > Тайм-аут на стороне маршрутизатора > Тайм-аут на стороне обработчика сообщений > Тайм-аут в API-прокси

  2. Если это серверная часть на NodeJS, то:
    1. Проверьте, обращается ли код NodeJS к каким-либо другим бэкэнд-серверам и не затягивается ли получение ответа. Выясните причину задержки со стороны бэкэнд-серверов и устраните проблему соответствующим образом.
    2. Проверьте, не наблюдается ли высокая загрузка ЦП или памяти в процессорах обработки сообщений:
      1. Если какой-либо обработчик сообщений испытывает высокую загрузку ЦП, создавайте три дампа потоков каждые 30 секунд, используя следующую команду: 
        JAVA_HOME/bin/jstack -l PID > FILENAME
      2. Если какой-либо обработчик сообщений испытывает высокую нагрузку на память, создайте дамп кучи, используя следующую команду: 
        sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
      3. Перезапустите обработчик сообщений, используя приведенную ниже команду. Это должно снизить нагрузку на процессор и память: 
        /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
      4. Отслеживайте вызовы API, чтобы убедиться, что проблема по-прежнему существует.
      5. Обратитесь в службу поддержки Apigee Edge и предоставьте дампы потоков, дамп кучи и журналы обработчика сообщений ( /opt/apigee/var/log/edge-message-processor/logs/system.log) , чтобы помочь в расследовании причин высокой загрузки ЦП/памяти.

Посмотрите это: Как контролируется таймаут на бэкенд-серверах NodeJS в обработчике сообщений?

  • Сервер NodeJS работает в рамках процесса JVM обработчика сообщений. Значение таймаута для серверов NodeJS контролируется свойством http.request.timeout.seconds в файле nodejs.properties . По умолчанию это свойство установлено на 0, то есть таймаут отключен для всех API-прокси, принадлежащих организации, обслуживаемой этим обработчиком сообщений. Таким образом, даже если сервер NodeJS работает слишком долго, обработчик сообщений не выдаст ошибку таймаута.
  • Однако, если серверная часть NodeJS работает слишком долго, и время выполнения запроса к API превышает 57 секунд, то маршрутизатор выдаст ошибку таймаута и отправит клиенту ошибку 504 Gateway Timeout .

Сценарий №3 — Клиентское приложение выдает ошибку тайм-аута до того, как маршрутизатор/обработчик сообщений/бэкэнд-сервер ответит.

Ошибка 504 Gateway Timeout может возникнуть, если клиентское приложение завершит работу по истечении времени ожидания до того, как серверная часть ответит. Такая ситуация может произойти, если:

  1. Значение тайм-аута, установленное в клиентском приложении, ниже значения тайм-аута, установленного в маршрутизаторе и обработчике сообщений:

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

    Истекло время ожидания на стороне клиента. Тайм-аут на маршрутизаторе Истекло время ожидания в обработчике сообщений
    50 секунд 57 секунд 55 секунд

    В этом случае общее время, доступное для получения ответа на API-запрос через Edge, составляет <= 50 секунд. Это включает время, затраченное на выполнение API-запроса, обработку запроса Edge (маршрутизатор, обработчик сообщений), отправку запроса на бэкэнд-сервер (если применимо), обработку запроса бэкэндом и отправку ответа, обработку ответа Edge и, наконец, отправку его обратно клиенту.

    Если маршрутизатор не ответит клиенту в течение 50 секунд, то произойдет таймаут, и соединение с маршрутизатором будет разорвано. Клиент получит код ответа 504 .

    В результате NGINX установит код состояния 499 , указывающий на то, что клиент закрыл соединение.

Диагноз

  1. Если клиентское приложение истекает по таймауту до получения ответа от маршрутизатора, оно разрывает соединение с маршрутизатором. В этой ситуации в журналах доступа NGINX для конкретного запроса API будет отображаться код состояния 499.

    Пример записи в журнале NGINX с кодом состояния 499.

  2. В приведенном выше примере обратите внимание, что статус 499 на NGINX и общее прошедшее время составляют 50,001 секунды. Это указывает на то, что клиент прервал соединение через 50,001 секунды.
  3. В этом случае в журналах обработчика сообщений ( /opt/apigee/var/log/edge-message-processor/logs/system.log). вы увидите исключения типа Broken Pipe Exception".
    2017-06-09 00:00:25,886 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-1-11193-11467656-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel(ClientChannel[A:XX.XX.XX.XX:8998 Remote host:YY.YY.YY.YY:51400]@23751 useCount=1 bytesRead=0 bytesWritten=486 age=330465ms  lastIO=0ms )
2017-06-09 00:00:25,887  org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-1-11193-11467656-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace:
java.io.IOException: Broken pipe
        at com.apigee.nio.channels.ClientOutputChannel.writePending(ClientOutputChannel.java:51) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.onWrite(OutputChannel.java:116) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.write(OutputChannel.java:81) ~[nio-1.0.0.jar:na]
         … <snipped>
  4. После истечения таймаута маршрутизатор закрывает соединение с обработчиком сообщений. Когда обработчик сообщений завершает свою обработку, он пытается отправить ответ маршрутизатору. Поскольку соединение с маршрутизатором уже закрыто, в обработчике сообщений возникает Broken Pipe exception .
  5. В описанных выше обстоятельствах такое исключение ожидаемо. Таким образом, фактическая причина ошибки 504 Gateway Timeout по-прежнему заключается в том, что серверная часть долго отвечает, и вам необходимо решить эту проблему.

Разрешение

  1. Если это ваш собственный сервер бэкэнда, то:
    1. Проверьте серверную часть, чтобы выяснить, почему выполнение запроса занимает более 57 секунд, и посмотрите, можно ли это исправить/оптимизировать для более быстрого ответа.
    2. Если исправить/оптимизировать серверную часть невозможно или известно, что серверная часть будет работать долго, увеличьте значение таймаута на маршрутизаторе и в обработчике сообщений .

      Идея: Установить значение тайм-аута для различных компонентов в следующем порядке:

      Тайм-аут на стороне клиента > Тайм-аут на стороне маршрутизатора > Тайм-аут на стороне обработчика сообщений > Тайм-аут в API-прокси

  2. Если это бэкенд на NodeJS, то:
    1. Проверьте, обращается ли код NodeJS к каким-либо другим бэкэнд-серверам и не занимает ли это слишком много времени для возврата результата. Выясните, почему эти бэкэнд-серверы работают дольше.
    2. Проверьте, не наблюдается ли высокая загрузка ЦП или памяти в процессорах обработки сообщений:
      1. Если процессор сообщений испытывает высокую загрузку ЦП, создавайте три дампа потоков каждые 30 секунд, используя следующую команду: 
        JAVA_HOME/bin/jstack -l PID > FILENAME
      2. Если обработчик сообщений испытывает высокую нагрузку на память, создайте дамп кучи, используя следующую команду: 
        sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
      3. Перезапустите обработчик сообщений, используя приведенную ниже команду. Это должно снизить нагрузку на процессор и память: 
        /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
      4. Отслеживайте вызовы API, чтобы убедиться, что проблема по-прежнему существует.
      5. Обратитесь в службу поддержки Apigee Edge и предоставьте дампы потоков, дамп кучи и журналы обработчика сообщений ( /opt/apigee/var/log/edge-message-processor/logs/system.log) , чтобы помочь им выяснить причину высокой загрузки ЦП/памяти.

Увеличьте значение тайм-аута на маршрутизаторе и процессоре сообщений.

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

Маршрутизатор 

chown apigee:apigee /opt/apigee/customer/application/router.properties
  1. Если файл /opt/apigee/customer/application/router.properties еще не существует, создайте его на компьютере с маршрутизатором.
  2. Добавьте в этот файл следующую строку:
    conf_load_balancing_load.balancing.driver.proxy.read.timeout=TIME_IN_SECONDS

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

    conf_load_balancing_load.balancing.driver.proxy.read.timeout=120
  3. Убедитесь, что владельцем этого файла является пользователь apigee:
  4. Перезагрузите маршрутизатор: 
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart
  5. Если у вас несколько маршрутизаторов, повторите описанные выше шаги на всех маршрутизаторах.

Обработчик сообщений

  1. Если файл /opt/apigee/customer/application/message-processor.properties еще не существует, создайте его на машине, где находится обработчик сообщений.
  2. Добавьте в этот файл следующую строку:
    conf_http_HTTPTransport.io.timeout.millis=TIME_IN_MILLISECONDS

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

    conf_http_HTTPTransport.io.timeout.millis=120000
  3. Убедитесь, что владельцем этого файла является пользователь apigee: 
    chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
  4. Перезапустите обработчик сообщений: 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  5. Если у вас несколько обработчиков сообщений, повторите описанные выше шаги для всех обработчиков сообщений.

Идея: Установить значение тайм-аута для различных компонентов в следующем порядке:

Тайм-аут на стороне клиента > Тайм-аут на стороне маршрутизатора > Тайм-аут на стороне обработчика сообщений > Тайм-аут в API-прокси

Медленная обработка запросов API со стороны Edge.

Если Edge работает очень медленно и/или обрабатывает API-запросы слишком долго, вы получите ошибку 504 Gateway Timeout .

Диагноз

  1. Отследите затронутый API в пользовательском интерфейсе Edge.
  2. Либо дождитесь возникновения ошибки, либо, если у вас есть вызов API, выполните несколько вызовов API и воспроизведите ошибку 504 Gateway Timeout .
  3. Обратите внимание, что в этом случае в трассировке вы можете увидеть успешный ответ.
    1. Маршрутизатор/клиент выдает ошибку тайм-аута, поскольку обработчик сообщений не отвечает в течение указанного периода ожидания на маршрутизаторе/клиенте (в зависимости от того, у какого из них наименьший период ожидания). Однако обработчик сообщений продолжает обработку запроса и может успешно завершить его.
    2. Кроме того, значение HTTPTransport.io.timeout.millis установленное в обработчике сообщений, срабатывает только в том случае, если обработчик сообщений взаимодействует с бэкэнд-сервером HTTP/HTTPS. Другими словами, этот таймаут не будет срабатывать, если выполнение какой-либо политики (кроме политики ServiceCallout) в API Proxy занимает слишком много времени.
  4. После возникновения ошибки изучите конкретный запрос с наибольшим временем выполнения .
  5. Проверьте прошедшее время на каждом этапе и отметьте этап, на который было затрачено больше всего времени.
  6. Если вы наблюдаете самое длительное время обработки запроса в любой из политик, кроме политики Service Callout, это указывает на то, что Edge обрабатывает запрос слишком долго.
  7. Вот пример трассировки пользовательского интерфейса, демонстрирующий очень большое время выполнения команды JavaScript Policy:

  8. В приведенном выше примере вы заметите, что выполнение политики JavaScript занимает аномально много времени — около 245 секунд.

Разрешение

  1. Проверьте, не является ли политика слишком долго отвечающей и не содержит ли она какой-либо пользовательский код, обработка которого может занять много времени. Если такой код есть, попробуйте его исправить/оптимизировать.
  2. Если нет пользовательского кода, который мог бы вызывать длительное время обработки, проверьте, не испытывают ли обработчики сообщений высокую нагрузку на ЦП или память:
    1. Если какой-либо обработчик сообщений испытывает высокую загрузку ЦП, создавайте три дампа потоков каждые 30 секунд, используя следующую команду: 
      JAVA_HOME/bin/jstack -l PID > FILENAME
    2. Если какой-либо обработчик сообщений демонстрирует высокую загрузку памяти, создайте дамп кучи, используя следующую команду: 
      sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
    3. Перезапустите обработчик сообщений, используя приведенную ниже команду. Это должно снизить нагрузку на процессор и память. 
      /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
    4. Проследите за вызовами API и подтвердите, сохраняется ли проблема.
    5. Обратитесь в службу поддержки Apigee Edge и предоставьте дампы потоков, дамп кучи и журналы обработчика сообщений ( /opt/apigee/var/log/edge-message-processor/logs/system.log) , чтобы помочь им выяснить причину высокой загрузки ЦП/памяти.

Диагностика проблем с помощью мониторинга API.

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

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