504 Gateway Timeout

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

Symptom

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

Код статуса HTTP 504 Gateway Timeout указывает на то, что клиент не получил своевременный ответ от Edge Gateway или внутреннего сервера во время выполнения 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 может произойти тайм-аут.

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

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

В Edge ошибка 504 Gateway Timeout обычно возникает по следующим причинам:

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

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

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

  1. Время ожидания ответа от бэкенд-сервера Message Processor истекло.
  2. Время ожидания маршрутизатора истекает до того, как Message Processor или сервер бэкенда отвечает.
  3. Время ожидания ответа от маршрутизатора, Message Processor или внутреннего сервера истекло.

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

Сценарий 1 Время ожидания Message Processor истекло до того, как ответил бэкенд-сервер

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

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

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

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

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

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

В приведенной выше трассировке Message Processor превышает время ожидания через 55 002 мс, поскольку бэкенд-сервер не отвечает.

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

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

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

    Пример журнала Message Processor с ошибкой Gateway Timeout Error

    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

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

    Как контролируется время ожидания в Message Processor?

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

Разрешение

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

Сценарий 2. Время ожидания ответа от маршрутизатора истекло до того, как Message Processor или бэкенд-сервер ответил

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

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

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

    Время ожидания на маршрутизаторе Время ожидания Message Processor истекло Время ожидания в прокси-сервере API
    57 секунд 55 секунд 120 секунд

    Однако в API Proxy для параметра 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 секунд в Message Processor переопределяется значением 120 секунд, заданным в прокси API. Таким образом, значение времени ожидания для Message Processor этого прокси-сервера API составит 120 секунд.

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

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

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

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

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

  3. В приведенном выше примере обратите внимание на статус 504 в NGINX, идентификатор сообщения от процессора сообщений - и общее затраченное время 57, 001 секунды. Это связано с тем, что время ожидания маршрутизатора истекло через 57,001 секунды, а мы не получили ответа от Message Processor.
  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>

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

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

Разрешение

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

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

      Тайм-аут на клиенте > Тайм-аут на маршрутизаторе > Тайм-аут на процессоре сообщений > Тайм-аут в прокси API
  2. Если это сервер NodeJS, выполните следующие действия:
    1. Проверьте, обращается ли код NodeJS к другим серверным частям и не слишком ли долго возвращается ответ. Проверьте, почему серверы обработки запросов работают медленнее, и устраните проблему.
    2. Проверьте, не наблюдается ли высокая загрузка ЦП или использование памяти у Message Processor:
      1. Если какой-либо Message Processor использует много ресурсов ЦП, создайте три дампа потоков каждые 30 секунд, используя следующую команду: 
        JAVA_HOME/bin/jstack -l PID > FILENAME
      2. Если какой-либо обработчик сообщений использует много памяти, создайте дамп кучи с помощью следующей команды: 
        sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
      3. Перезапустите Message Processor, используя приведенную ниже команду. Это должно снизить нагрузку на ЦП и память: 
        /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)), чтобы помочь специалистам определить причину высокого использования ЦП или памяти.

Check This: How is timeout controlled for NodeJS backend servers on Message Processor

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

Сценарий 3. Время ожидания ответа от маршрутизатора, Message Processor или внутреннего сервера истекло до того, как это произошло в клиентском приложении

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

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

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

    Время ожидания на стороне клиента Время ожидания на маршрутизаторе Время ожидания Message Processor истекло
    50 секунд 57 секунд 55 секунд

    В этом случае общее время, доступное для получения ответа на запрос к API через Edge, составляет не более 50 секунд. Сюда входит время, затраченное на отправку запроса к API, его обработку Edge (маршрутизатором, Message Processor), отправку на бэкенд-сервер (если применимо), обработку запроса бэкендом и отправку ответа, обработку ответа 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. 
    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. Когда время ожидания маршрутизатора истекает, он закрывает подключение к Message Processor. Когда Message Processor завершает обработку, он пытается записать ответ в маршрутизатор. Поскольку подключение к маршрутизатору уже закрыто, идентификатор Broken Pipe exception будет получен Message Processor.
  5. Это исключение ожидаемо при описанных выше обстоятельствах. Таким образом, фактическая причина ошибки 504 Gateway Timeout по-прежнему заключается в том, что серверу требуется много времени на ответ, и вам нужно устранить эту проблему.

Разрешение

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

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

      Тайм-аут на клиенте > Тайм-аут на маршрутизаторе > Тайм-аут на процессоре сообщений > Тайм-аут в прокси API
  2. Если вы используете серверную часть на основе NodeJS, выполните следующие действия:
    1. Проверьте, обращается ли код NodeJS к другим серверным частям и не занимает ли ответ от них слишком много времени. Проверьте, почему внутренние серверы работают медленнее.
    2. Проверьте, не наблюдается ли высокая загруженность процессора или памяти у процессоров сообщений:
      1. Если Message Processor сильно загружен, создайте три дампа потоков с интервалом в 30 секунд, используя следующую команду: 
        JAVA_HOME/bin/jstack -l PID > FILENAME
      2. Если процессор сообщений использует слишком много памяти, создайте дамп кучи с помощью следующей команды: 
        sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
      3. Перезапустите Message Processor, используя приведенную ниже команду. Это должно снизить нагрузку на ЦП и память: 
        /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. Если у вас несколько маршрутизаторов, повторите описанные выше действия для каждого из них.

Message Processor

  1. Создайте файл /opt/apigee/customer/application/message-processor.properties на компьютере Message Processor, если он ещё не существует.
  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. Перезапустите Message Processor: 
    /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. Время ожидания маршрутизатора или клиента истекло, поскольку Message Processor не ответил в течение заданного времени ожидания на маршрутизаторе или клиенте (выбирается наименьшее значение). Однако Message Processor продолжает обрабатывать запрос и может успешно завершить его.
    2. Кроме того, значение HTTPTransport.io.timeout.millis, заданное в Message Processor, активируется только в том случае, если Message Processor взаимодействует с бэкенд-сервером HTTP/HTTPS. Другими словами, это время ожидания не будет активировано, если какое-либо правило (кроме правила ServiceCallout) в прокси-сервере API выполняется слишком долго.
  4. После того как произойдет ошибка, изучите запрос с самым долгим временем выполнения.
  5. Проверьте время, затраченное на каждом этапе, и запишите, на каком этапе было потрачено больше всего времени.
  6. Если вы наблюдаете самое большое прошедшее время в любом из правил, кроме правила Service Callout, это означает, что Edge требуется много времени для обработки запроса.
  7. Ниже приведен пример трассировки интерфейса, в котором показано очень большое время, затраченное на правила JavaScript.

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

Разрешение

  1. Проверьте, не нарушает ли сайт правила, на которые долго реагирует система, и нет ли на нем пользовательского кода, который может долго обрабатываться. Если такой код есть, попробуйте исправить или оптимизировать его.
  2. Если в вашем коде нет ничего, что могло бы привести к увеличению времени обработки, проверьте, не наблюдается ли повышенное использование ресурсов процессора или памяти в процессорах сообщений:
    1. Если какой-либо Message Processor использует много ресурсов ЦП, создайте три дампа потоков каждые 30 секунд, используя следующую команду: 
      JAVA_HOME/bin/jstack -l PID > FILENAME
    2. Если какой-либо обработчик сообщений потребляет много памяти, создайте дамп кучи с помощью следующей команды: 
      sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
    3. Перезапустите Message Processor, используя приведенную ниже команду. Это должно снизить нагрузку на ЦП и память. 
      /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 Monitoring

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

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