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

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

Симптом

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

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

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

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

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

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

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

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

    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, в котором указано вышеупомянутое свойство. Например, если для io.timeout.millis в прокси API установлено значение 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. Если время ожидания маршрутизатора истекает раньше процессора сообщений, вы увидите статус 504 в журналах доступа NGINX для конкретного запроса API, а message id от процессора сообщений будет установлен как - . Это связано с тем, что маршрутизатор не получил никакого ответа от процессора сообщений в течение периода ожидания, установленного на маршрутизаторе.

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

  3. В приведенном выше примере обратите внимание на статус 504 в NGINX, идентификатор сообщения от процессора сообщений - и общее прошедшее время — 57,001 секунды. Это связано с тем, что время ожидания маршрутизатора истекло через 57,001 секунды, и мы не получили никакого ответа от процессора сообщений.
  4. В этом случае вы увидите исключения Broken Pipe в журналах процессора сообщений ( /opt/apigee/var/log/edge-message-processor/logs/system.log). 
    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. Если время ожидания клиентского приложения истечет до того, как оно получит ответ от маршрутизатора, оно закроет соединение с маршрутизатором. В этой ситуации вы увидите код состояния 499 в журналах доступа NGINX для конкретного запроса API.

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

  2. В приведенном выше примере обратите внимание, что статус 499 на NGINX и общее прошедшее время составляет 50,001 секунды. Это означает, что время ожидания клиента истекло через 50,001 секунды.
  3. В этом случае вы увидите исключения Broken Pipe в журналах процессора сообщений ( /opt/apigee/var/log/edge-message-processor/logs/system.log).
    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. Обратите внимание: в этом случае вы можете увидеть успешный ответ в файле Trace.
    1. Тайм-аут маршрутизатора/клиента истекает, поскольку процессор сообщений не отвечает в течение указанного периода тайм-аута на маршрутизаторе/клиенте (в зависимости от того, какой из них имеет наименьший период тайм-аута). Однако процессор сообщений продолжает обрабатывать запрос и может завершиться успешно.
    2. Кроме того, значение HTTPTransport.io.timeout.millis , установленное в процессоре сообщений, срабатывает только в том случае, если процессор сообщений взаимодействует с внутренним сервером HTTP/HTTPS. Другими словами, этот тайм-аут не сработает, если какая-либо политика (кроме политики ServiceCallout) в прокси-сервере API занимает много времени.
  4. После возникновения ошибки проверьте конкретный запрос с наибольшим затраченным временем .
  5. Проверьте прошедшее время на каждом этапе и запишите этап, на который было потрачено больше всего времени.
  6. Если вы наблюдаете самое продолжительное время в любой из политик, кроме политики вызова службы, это означает, что Edge требуется много времени для обработки запроса.
  7. Вот пример трассировки пользовательского интерфейса, показывающий очень большое время, затраченное на политику JavaScript:

  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 превышает определенный порог.