Запросы API не фиксируются в пользовательском интерфейсе Edge

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

Симптом

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

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

При возникновении этой проблемы в пользовательском интерфейсе Edge не будут отображаться сообщения об ошибках.

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

В следующей таблице показаны возможные причины сбоя при захвате запросов API в Edge UI Trace.

Причина: запросы не обрабатываются процессором сообщений.

Диагностика

Чтобы захватить запрос API в сеансе трассировки, запрос API должен быть обработан процессором сообщений компонента Edge. Существует несколько причин, по которым запрос API может не быть зафиксирован в транзакции трассировки.

Например, если запрос API не достигает Apigee Edge, происходит сбой в точке входа в Edge (т. е. маршрутизатор) или происходит сбой до того, как он будет обработан процессором сообщений, то трассировка не может быть захвачена. Каждый из этих сценариев описан более подробно ниже.

Сценарий 1. Запросы не доходят до Apigee Edge.

• Причина

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

  curl https://hostName:port/apiProxyBasePath/requestPath
  

  curl: (6) Could not resolve host: hostName
  

• Разрешение

  Вы можете проверить конфигурацию DNS с помощью следующей команды:

  dig hostName

  Проверить сетевое соединение можно с помощью следующей команды:

  telnet hostName port

Сценарий 2: запросы на Edge Router Apigee не выполняются.

• Причина

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

  Received fatal alert: handshake_failure
  

  HTTP/1.1 400 Bad Request
  

  Вы также можете увидеть ошибку сертификата SSL.

• Разрешение

  Обратитесь к следующим руководствам по устранению и устранению этих проблем:

  Сбои установления связи TLS/SSL

  400 Неверный запрос — ошибка SSL-сертификата

Сценарий 3: Запросы не могут быть обработаны процессором сообщений.

• Причина

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

  HTTP/1.1 404 Not Found
  

  {
    "fault":{
      "faultstring":"Unable to identify proxy for host: default and url: \/apiProxyBasePath/requestPath",
      "detail":{
        "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
      }
    }
  }
  
  

• Разрешение

  Обратитесь к этому сборнику правил, чтобы устранить и решить эту проблему: 404 Невозможно определить прокси-сервер для хоста .

Причина: прокси-сервер API не найден в дереве классификации.

Диагностика

Если процессор сообщений не может найти прокси-сервер API в своем дереве классификации, то любые запросы API к этому конкретному прокси-серверу не будут отображаться в сеансах трассировки в пользовательском интерфейсе Edge.

Выполните следующие действия, чтобы определить, так ли это:

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

   curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions
   

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

   Приведенная выше команда выведет список развернутых ревизий. Например, если развернута версия 12, вы увидите следующий вывод:

   [ "12" ]
   

   Если вы не сталкиваетесь с периодическими ошибками HTTP 404, вы, скорее всего, увидите, что развернута конкретная версия.

2. Прочтите дерево классификации и проверьте наличие имени прокси-сервера API с помощью следующей команды:

   curl -i http://localhost:8082/v1/classification/tree | grep apiName
   

3. Повторите шаги 1 и 2 для каждого процессора сообщений. Если данное имя прокси-сервера API отсутствует в дереве классификации любого из процессоров сообщений, следуйте приведенному ниже решению.

Разрешение

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

1. Войдите на каждый из хостов процессора сообщений, у которых отсутствует определенный прокси-сервер API в дереве классификации, и используйте команду ниже, чтобы перезапустить процессор сообщений:

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
   

2. После перезапуска используйте команду ниже, чтобы дождаться, пока она станет активной:

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor wait_for_ready
   

3. Когда процессор сообщений будет готов, проверьте доступность прокси-сервера API с помощью следующей команды:

   curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions
   

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

   Приведенная выше команда выведет список развернутых ревизий. Например, если развернута версия 12, вы увидите следующий вывод:

   [ "12" ]
   

   Если вы не сталкиваетесь с периодическими ошибками HTTP 404, вы, скорее всего, увидите, что развернута конкретная версия.

4. Прочтите дерево классификации и проверьте существование имени прокси-сервера API, используя следующую команду:

   curl -i http://localhost:8082/v1/classification/tree | grep apiName
   

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

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

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

curl -v management-server-host:8080/v1/runtime/organizations/orgName/environments/envName/apis/apiProxyName/revisions/revisionNumber/debugsessions -u user

/opt/apigee/var/log/edge-management-server/logs/system.log

/opt/apigee/var/log/edge-message-processor/logs/system.log

telnet MessageProcessor_IP 8082

nc -vz MessageProcessor_IP 8082

netstat -an > netstat.txt

curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions

curl -i http://localhost:8082/v1/classification/tree