Запросы к API, не зарегистрированные в интерфейсе Edge

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

Symptom

На изображении ниже показано, что запросы API не регистрируются в интерфейсе Edge при запуске сеанса трассировки.

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

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

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

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

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

Диагностика

Чтобы запрос к API был записан в сеанс трассировки, он должен быть обработан компонентом Edge Message Processor. Запрос к API может не быть зарегистрирован в транзакции трассировки по нескольким причинам.

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

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

• Причина

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

  Received fatal alert: handshake_failure
  

  HTTP/1.1 400 Bad Request
  

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

• Разрешение

  Чтобы устранить эти проблемы, ознакомьтесь со следующими руководствами:

  Сбои при подтверждении TLS/SSL

  400 Bad Request - SSL Certificate Error (Неверный запрос – ошибка сертификата SSL)

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

• Причина

  В этом случае Apigee Message Processor не может найти прокси 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 Unable to identify proxy for host (404 Не удается определить прокси-сервер для хоста).

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

Диагностика

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

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

1. Войдите в каждый из Message Processor и проверьте, развернута ли в соответствующей среде Message Processor нужная версия запрошенного 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 для каждого Message Processor. Если указанное имя прокси-сервера API отсутствует в дереве классификации любого из процессоров сообщений, выполните описанные ниже действия.

Разрешение

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

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

   /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. Когда Message Processor будет готов, проверьте доступность прокси-сервера 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