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

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

Симптом

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

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

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

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

В таблице ниже показаны возможные причины сбоя при перехвате API-запросов в Edge UI Trace:

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

Диагноз

Для того чтобы запрос 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: Запросы не выполняются на маршрутизаторе Apigee Edge Router.

• Причина

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

  Received fatal alert: handshake_failure
  

  HTTP/1.1 400 Bad Request
  

  Также может появиться ошибка SSL-сертификата.

• Разрешение

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

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

  Ошибка 400 Bad Request - SSL Certificate Error

Сценарий 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